4 ms·

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

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.
        boomlinde 6y ago
        > 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. So again, this happens when you're using products in an enterprise network that don't "fly in an enterprise network". Instead of addressing these products directly for what is obviously a flaw in their implementation that concerns you, you say that this is DHCPv6 at fault. If PXE and your OS don't offer defaults that would make them fly in an enterprise network, they're to blame. > This is totally different from home networks, where manual configuration is acceptable and usually easier. Regardless, when a host connects to my home network and starts talking DHCP, v6 or v4, it gets a name assignment corresponding to its hostname. Thanks the RFC 6939 option this could just as easily be based on the MAC address. Whether manual configuration would have been acceptable in my home network case is completely irrelevant to the point.

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.
      - boomlinde 6y ago
        > 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. So again, this happens when you're using products in an enterprise network that don't "fly in an enterprise network". Instead of addressing these products directly for what is obviously a flaw in their implementation that concerns you, you say that this is DHCPv6 at fault. If PXE and your OS don't offer defaults that would make them fly in an enterprise network, they're to blame. > This is totally different from home networks, where manual configuration is acceptable and usually easier. Regardless, when a host connects to my home network and starts talking DHCP, v6 or v4, it gets a name assignment corresponding to its hostname. Thanks the RFC 6939 option this could just as easily be based on the MAC address. Whether manual configuration would have been acceptable in my home network case is completely irrelevant to the point.