4 ms·

> Addresses are assigned not based on MAC addresses like in DHCPv4, but based on UUIDs. > Whether the UUID is per host, hardware, boot or phase of the moon or

> Addresses are assigned not based on MAC addresses like in DHCPv4, but based on UUIDs. > Whether the UUID is per host, hardware, boot or phase of the moon or just random is essentially random Should we fault the protocol for its implementations failing to satisfy what I think are very clear MUSTs and SHOULDs in RFC3315? A DUID is used by anything that wants to be uniquely identified as a DHCP client or server. The basis of the assignment must not matter to either the server or client and the value should be treated as opaque. It should not change over time if at all possible. It could be based on a MAC address (as DUID-LL or DUID-LLT) but it shouldn't matter to anyone consuming the DUID, because they MUST NOT be interpreted and only ever be compared for equality. A unique DUID should simply be considered as a unique client. I don't know what about these requirements is so fundamentally hard that "DHCPv6 is broken" because of it. Plain DHCP essentially has the same limitation in that there is no guarantee that a client will consistently use the same link layer address.

corty 6y ago
The non-interpretation-requirement makes DUIDs useless. If I must not compare it to a MAC address, I can't identify the IPv4 address assigned to the same host. I can't identify the box with the MAC address printed on. "It should not change over time" has been trumped by "it's impossible to implement privacy without changing it". Those things make DHCPv6 as useless as SLAAC: I can't look up a corresponding v4 address and I can't predict what DUID/IAID a new device will use, or rather what v6 address it will get.
- boomlinde 6y ago
  > The non-interpretation-requirement makes DUIDs useless. If I must not compare it to a MAC address, I can't identify the IPv4 address assigned to the same host. You don't need to interpret a DUID. You can take a MAC address and generate a DUID-LL from it according to RFC 3315, then look for that in the DHCP traffic without ever interpreting DUIDs by simple equality comparison, while simultaneously scanning the DHCP (v4) traffic for the MAC you derived the DUID from. And if the thing you're looking for is not using DUID-LL, you're just as screwed as if your IPv4 product is randomizing its MAC address.
  - corty 6y ago
    But that is not really "treating the DUID as opaque", is it? Also, there is still the problem of forcing devices into DUID-LL mode which is neither the default nor common. This requires manual configuration which is very bad for any large-scale use case.
    - boomlinde 6y ago
      > But that is not really "treating the DUID as opaque", is it? Yes it is. Nowhere in this process do I need to take an existing DUID and treat it as anything other than an arbitrary sequence of bytes to be compared to another arbitrary sequence of bytes. > Also, there is still the problem of forcing devices into DUID-LL mode which is neither the default nor common. So maybe your use-case simply isn't common, perhaps because there are numerous ways to solve it that don't involve relying on ideal behavior in both DHCP v4 and v6 servers and clients. Take RFC 6939 for example, or just plain hostname based name assignments.
      - corty 6y ago
        And how do I get the initial hostname? Is it unique? Will it even be set? The hostname field is optional ;)
        boomlinde 6y ago
        > Will it even be set? The hostname field is optional ;) Then of course, so is printing a barcode sticker representing the MAC address of the box you're installing. The basis for any solution that is going to let you install hundreds of hosts comfortably is the manufacturer going out of their way to support that, regardless of whether you're using plain DHCP or DHCPv6.

corty 6y ago

The non-interpretation-requirement makes DUIDs useless. If I must not compare it to a MAC address, I can't identify the IPv4 address assigned to the same host. I can't identify the box with the MAC address printed on. "It should not change over time" has been trumped by "it's impossible to implement privacy without changing it". Those things make DHCPv6 as useless as SLAAC: I can't look up a corresponding v4 address and I can't predict what DUID/IAID a new device will use, or rather what v6 address it will get.

boomlinde 6y ago
> The non-interpretation-requirement makes DUIDs useless. If I must not compare it to a MAC address, I can't identify the IPv4 address assigned to the same host. You don't need to interpret a DUID. You can take a MAC address and generate a DUID-LL from it according to RFC 3315, then look for that in the DHCP traffic without ever interpreting DUIDs by simple equality comparison, while simultaneously scanning the DHCP (v4) traffic for the MAC you derived the DUID from. And if the thing you're looking for is not using DUID-LL, you're just as screwed as if your IPv4 product is randomizing its MAC address.
- corty 6y ago
  But that is not really "treating the DUID as opaque", is it? Also, there is still the problem of forcing devices into DUID-LL mode which is neither the default nor common. This requires manual configuration which is very bad for any large-scale use case.
  - boomlinde 6y ago
    > But that is not really "treating the DUID as opaque", is it? Yes it is. Nowhere in this process do I need to take an existing DUID and treat it as anything other than an arbitrary sequence of bytes to be compared to another arbitrary sequence of bytes. > Also, there is still the problem of forcing devices into DUID-LL mode which is neither the default nor common. So maybe your use-case simply isn't common, perhaps because there are numerous ways to solve it that don't involve relying on ideal behavior in both DHCP v4 and v6 servers and clients. Take RFC 6939 for example, or just plain hostname based name assignments.
    - corty 6y ago
      And how do I get the initial hostname? Is it unique? Will it even be set? The hostname field is optional ;)
      - boomlinde 6y ago
        > Will it even be set? The hostname field is optional ;) Then of course, so is printing a barcode sticker representing the MAC address of the box you're installing. The basis for any solution that is going to let you install hundreds of hosts comfortably is the manufacturer going out of their way to support that, regardless of whether you're using plain DHCP or DHCPv6.