3 ms·

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

by 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.
- boomlinde 6y ago
  > 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. DUID-LL is link layer address based and if your link layer address is a burned-in MAC you can definitely just scan a barcode, generate a DUID-LL from it and look for that DUID in your DHCP traffic. Your product could use a run-time generated DUID-UUID or some other scheme that can't practically be printed on the product, but on the other hand a DHCP (v4) using product could randomize its link layer address on every boot to the same effect.
  - corty 6y ago
    It usually isn't "my product" but whatever somebody has bought and wants to bring onto the network.
    - boomlinde 6y ago
      That conclusion fundamentally invalidates your original conclusion, though. The problem isn't that "DHCPv6 is broken" but that you have a use case which a certain product someone wants to bring onto the network doesn't satisfy.
      - corty 6y ago
        The "product" is DHCPv6 and it doesn't solve the use case it is supposed to solve: managed networks and enterprises. As for random hardware and software products on the network: It would be nice for criteria like "proper IPv6 support" to be blockers, but they aren't for lack of choice. Almost no product out there has anything resembling proper IPv6 support. Just try some fresh deployment of anything in a IPv6-only network, I dare you :)
        Dagger2 6y ago
        I run my home desktop and many of my VMs as v6-only and almost everything works fine. There are a few things that have a problem (mostly games, for some reason), but not many. Though I could imagine "enterprise-grade" software, which often seems to be worse than open-source software, having similar problems.

by elp 6y ago

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.

boomlinde 6y ago
> 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. DUID-LL is link layer address based and if your link layer address is a burned-in MAC you can definitely just scan a barcode, generate a DUID-LL from it and look for that DUID in your DHCP traffic. Your product could use a run-time generated DUID-UUID or some other scheme that can't practically be printed on the product, but on the other hand a DHCP (v4) using product could randomize its link layer address on every boot to the same effect.
- corty 6y ago
  It usually isn't "my product" but whatever somebody has bought and wants to bring onto the network.
  - boomlinde 6y ago
    That conclusion fundamentally invalidates your original conclusion, though. The problem isn't that "DHCPv6 is broken" but that you have a use case which a certain product someone wants to bring onto the network doesn't satisfy.
    - corty 6y ago
      The "product" is DHCPv6 and it doesn't solve the use case it is supposed to solve: managed networks and enterprises. As for random hardware and software products on the network: It would be nice for criteria like "proper IPv6 support" to be blockers, but they aren't for lack of choice. Almost no product out there has anything resembling proper IPv6 support. Just try some fresh deployment of anything in a IPv6-only network, I dare you :)
      - Dagger2 6y ago
        I run my home desktop and many of my VMs as v6-only and almost everything works fine. There are a few things that have a problem (mostly games, for some reason), but not many. Though I could imagine "enterprise-grade" software, which often seems to be worse than open-source software, having similar problems.