6 ms·

DHCPv6 is broken. 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

by corty 6y ago

DHCPv6 is broken. 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, making it totally useless for any kind of managed network. One might as well just go with the simpler alternative of using SLAAC. Any admin claiming DHCPv6 is somehow better for a managed network than the "anarchy" of SLAAC is deluding themselves. There are patches and extensions doing MAC address based assignments, but those are only sparsely supported in network hardware and software. For the configuration tasks that DHCP also is used for beyond address assignment, there are better alternatives like anycast, zeroconf and SLAAC extensions. The only thing that would make DHCP useful again in 2020 would be strong cryptographic authentication for devices, maybe tied in with 802.1x and MAC layer encryption. Therefore I think android is just ahead of the curve in getting rid of DHCPv6.

deleted 6y ago
[deleted]
spystath 6y ago
As long as the DUID does not change, though, is it really important how the DHCP address is mapped? MAC addresses can be spoofed, even randomised at every boot if one is so inclined. They are not any more unique as the DUID in the end of the day.
- corty 6y ago
  The MAC address can be obtained from the outside of the box of your system, so deployment is "scan the MAC barcode, register for autoinstall on boot, done". "Big enterprise" deployment for which one is supposed to need DHCPv6. Also, DHCPv4 still uses MAC addresses, if one uses dual stack as opposed to v6-only, one might want to correlate the v4- and v6-address given to a device.
  - boomlinde 6y ago
    In DHCPv6 it is perfectly fine to use MAC-based DUID-LL, though, if you want to support a "figure it out from the outside of the box" use case in your product. Just as someone can choose to use DUID-LLT or DUID-UUID in their DHCPv6 product, someone can not to print the MAC address and to randomize the MAC address on any basis in their DHCP (v4) product.
    - corty 6y ago
      Of course one could do those things. However, those things are uncommon, so one cannot rely on them working in most cases, making the whole situation painful and DHCPv6 useless. If it were just my one product, things would be fine. But reality consists of hundreds of hardware and software products by different vendors, from different ages, etc. With DHCPv4 I can rely on the mac address being used and forwarded in a DHCPv4 request and I can rely on the MAC address sticker to be present and accurate. And while it is possible for an operating system to randomise MAC addresses, it is uncommon enough. Most OSes also won't randomise MACs if the network "looks enterprisey" (e.g. uses WPA2-Enterprise) to them. DHCPv6 dropped the ball right at the start and is now unable to pick it up again. The reality of DHCPv6 implementations has developed into a thicket of opaqueness and uselessnes, which cannot be unravelled I fear.
      - boomlinde 6y ago
        > I can rely on the MAC address sticker to be present and accurate. That is not a property of the DHCP (v4) protocol. My argument isn't that the situation is messy; it's that DHCPv6 is not broken. The only extent to which anything you've said has supported that conclusion is that yes, it's as broken as plain DHCP. The use case you describe (consistent addressing based on MAC and simple correlation of IPv4 and IPv6 addresses) can be solved in numerous ways, for example using MAC derived name assignment or multicast DNS. It's solved in my home network, why isn't it in your enterprise network? Why make yourself dependent on what's printed on the box?
        corty 6y ago
        DHCPv6 is broken in that it allowed anything beyond DUID-LL to be used. DHCPv4 always relied on MAC addresses, so this works where DHCPv6 doesn't. DUID-LL in DHCPv6 usually doesn't work, except with special configuration, for which I have to boot, configure the PXE firmware (if it is even configurable) and the OS (which isn't even installed yet). This doesn't fly in an enterprise network, where I don't want to unpack, boot and manually configure each and every device. Ideally, I never open the box, scan some printed-on barcodes and pass it on to the future user of the new device. After unpacking and cabling, installation and setup is automatic. This is totally different from home networks, where manual configuration is acceptable and usually easier.
elp 6y ago
From RFC8415: DUID used by a client or server SHOULD NOT change over time if at all possible. Read the fine article. The reasons are mostly the same as DHCP on v4. The ability to assign a specific IP to a specific device for what ever reason: Adding reverse DNS, tracking given IP to specific device etc. It might not be useful against hostile actors (just like ipv4 DHCP) but its perfectly fine for everyone else. And the specific argument that "Using it might encourage nat on ipv6" is about as condescending as saying "Using your computer might encourage you to look at naughty pictures". Android is now the ONLY operating system that doesn't support this and in many ways is harming the uptake of IPV6 because of this. Not being able to use DHCPv6 for Android reduces the chances of an organisation using DHCPv6 for everything else which reduces the pressure on vendors to fix any DUID bugs.
- corty 6y ago
  The reasons are the same, agreed. However, the mechanisms DHCPv6 provides are broken beyond what DHCPv4 has historically provided: With DHCPv4, I can deploy a device by scanning the MAC address barcode and configure the autoinstall/autoconfiguration. With IPv6, I can't, the DUID and IAID is assigned on OS installation for the OS DHCPv6 client. The PXE DHCPv6 client will use a different set of DUID and IAID which sometimes, but not always will be based on the system GUID. Also, the system GUID will sometimes be printed on the packaging, often it won't. So the "enterprise unboxing" experience is atrocious with DHCPv6 anyways. For android devices things are similarly broken, there is no PXE, however, one can't correlate the IPv4 and IPv6 addresses for one device because the mac address as a shared identifier isn't usable in DHCPv6 in most cases anyways. Things could be fixed, but since historically the DHCPv6 standard has not included those fixes and just added them later as extensions, things look rather grim for boot firmware and network equipment. If you need a proper device identification that cannot be faked, you are out of luck in any case. Therefore my suggestion of a possible next-generation protocol that would also solve the problem of confirming device identity by proper cryptographic authentication. Also, DUID behaviour is not buggy, your own post cites DUID stability as "SHOULD NOT change". So all the changing DUIDs are conformant. The standards were broken from the beginning and it is too late to change them now.
  - 6y ago
boomlinde 6y ago
> 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.

by corty 6y ago

deleted 6y ago

[deleted]

spystath 6y ago

As long as the DUID does not change, though, is it really important how the DHCP address is mapped? MAC addresses can be spoofed, even randomised at every boot if one is so inclined. They are not any more unique as the DUID in the end of the day.

corty 6y ago
The MAC address can be obtained from the outside of the box of your system, so deployment is "scan the MAC barcode, register for autoinstall on boot, done". "Big enterprise" deployment for which one is supposed to need DHCPv6. Also, DHCPv4 still uses MAC addresses, if one uses dual stack as opposed to v6-only, one might want to correlate the v4- and v6-address given to a device.
- boomlinde 6y ago
  In DHCPv6 it is perfectly fine to use MAC-based DUID-LL, though, if you want to support a "figure it out from the outside of the box" use case in your product. Just as someone can choose to use DUID-LLT or DUID-UUID in their DHCPv6 product, someone can not to print the MAC address and to randomize the MAC address on any basis in their DHCP (v4) product.
  - corty 6y ago
    Of course one could do those things. However, those things are uncommon, so one cannot rely on them working in most cases, making the whole situation painful and DHCPv6 useless. If it were just my one product, things would be fine. But reality consists of hundreds of hardware and software products by different vendors, from different ages, etc. With DHCPv4 I can rely on the mac address being used and forwarded in a DHCPv4 request and I can rely on the MAC address sticker to be present and accurate. And while it is possible for an operating system to randomise MAC addresses, it is uncommon enough. Most OSes also won't randomise MACs if the network "looks enterprisey" (e.g. uses WPA2-Enterprise) to them. DHCPv6 dropped the ball right at the start and is now unable to pick it up again. The reality of DHCPv6 implementations has developed into a thicket of opaqueness and uselessnes, which cannot be unravelled I fear.
    - boomlinde 6y ago
      > I can rely on the MAC address sticker to be present and accurate. That is not a property of the DHCP (v4) protocol. My argument isn't that the situation is messy; it's that DHCPv6 is not broken. The only extent to which anything you've said has supported that conclusion is that yes, it's as broken as plain DHCP. The use case you describe (consistent addressing based on MAC and simple correlation of IPv4 and IPv6 addresses) can be solved in numerous ways, for example using MAC derived name assignment or multicast DNS. It's solved in my home network, why isn't it in your enterprise network? Why make yourself dependent on what's printed on the box?
      - corty 6y ago
        DHCPv6 is broken in that it allowed anything beyond DUID-LL to be used. DHCPv4 always relied on MAC addresses, so this works where DHCPv6 doesn't. DUID-LL in DHCPv6 usually doesn't work, except with special configuration, for which I have to boot, configure the PXE firmware (if it is even configurable) and the OS (which isn't even installed yet). This doesn't fly in an enterprise network, where I don't want to unpack, boot and manually configure each and every device. Ideally, I never open the box, scan some printed-on barcodes and pass it on to the future user of the new device. After unpacking and cabling, installation and setup is automatic. This is totally different from home networks, where manual configuration is acceptable and usually easier.

elp 6y ago

From RFC8415: DUID used by a client or server SHOULD NOT change over time if at all possible. Read the fine article. The reasons are mostly the same as DHCP on v4. The ability to assign a specific IP to a specific device for what ever reason: Adding reverse DNS, tracking given IP to specific device etc. It might not be useful against hostile actors (just like ipv4 DHCP) but its perfectly fine for everyone else. And the specific argument that "Using it might encourage nat on ipv6" is about as condescending as saying "Using your computer might encourage you to look at naughty pictures". Android is now the ONLY operating system that doesn't support this and in many ways is harming the uptake of IPV6 because of this. Not being able to use DHCPv6 for Android reduces the chances of an organisation using DHCPv6 for everything else which reduces the pressure on vendors to fix any DUID bugs.

corty 6y ago
The reasons are the same, agreed. However, the mechanisms DHCPv6 provides are broken beyond what DHCPv4 has historically provided: With DHCPv4, I can deploy a device by scanning the MAC address barcode and configure the autoinstall/autoconfiguration. With IPv6, I can't, the DUID and IAID is assigned on OS installation for the OS DHCPv6 client. The PXE DHCPv6 client will use a different set of DUID and IAID which sometimes, but not always will be based on the system GUID. Also, the system GUID will sometimes be printed on the packaging, often it won't. So the "enterprise unboxing" experience is atrocious with DHCPv6 anyways. For android devices things are similarly broken, there is no PXE, however, one can't correlate the IPv4 and IPv6 addresses for one device because the mac address as a shared identifier isn't usable in DHCPv6 in most cases anyways. Things could be fixed, but since historically the DHCPv6 standard has not included those fixes and just added them later as extensions, things look rather grim for boot firmware and network equipment. If you need a proper device identification that cannot be faked, you are out of luck in any case. Therefore my suggestion of a possible next-generation protocol that would also solve the problem of confirming device identity by proper cryptographic authentication. Also, DUID behaviour is not buggy, your own post cites DUID stability as "SHOULD NOT change". So all the changing DUIDs are conformant. The standards were broken from the beginning and it is too late to change them now.
- 6y ago

boomlinde 6y ago

> 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.