4 ms·

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

> 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 flaw can be argued to be in the products' implementation of the standard or the standard itself. I do argue for the flaw to be in the standard because the standard doesn't do what it's name suggests: standardize. Instead it has balkanized (not on its own of course, but by allowing implementers too much of a choice and too few hard rules, too much SHOULD instead of MUST). There is a cycle in many enterprises where someone asks "could we implement IPv6?". Then things like these come up, everybody looks at discussions like ours where there are pie-in-the-sky arguments about "you could just pick the right software/hardware" and "you could change it like that". The conclusion will inevitably be: IPv6 isn't there yet, because it's too much work for little benefit. Too many changes in existing processes, too much risk. Then the IPv6 topic is dead again, maybe for two or three years until someone asks again. This has been going on for almost 20 years now. If you have ever been wondering why enterprises usually don't do IPv6, there is your reason. The braindamage that is DHCPv6 along with the false claims of "if you want 'enterprise' and 'managed networks' you need DHCPv6" is a large part of it. I have no idea how things would get any better, however, DHCPv6 is recognizably a dead end.
    - boomlinde 6y ago
      > The flaw can be argued to be in the products' implementation of the standard or the standard itself. I do argue for the flaw to be in the standard because the standard doesn't do what it's name suggests: standardize. Instead it has balkanized (not on its own of course, but by allowing implementers too much of a choice and too few hard rules, too much SHOULD instead of MUST). So you call people out for their shoddy products until the SHOULDs are practically adopted as MUSTs. Is there a legitimate reason for some network appliance with any form of persistent storage that you can write to once or more to use different DUIDs through its lifetime? Nope. If it does it's badly implemented. Do burn-in, just like you do with MAC and print the DUID on the box, just like you do with MAC. How you achieve that is no concern of the DHCPv6 protocol, just as how the MAC address is derived or whether it's printed on the box is no concern of the DHCP (v4) protocol. Perhaps one can say that there is a lack of standardization in the area of human friendly physical machine to address mapping. DHCPv6 and DHCP (v4) are not those standards. Instead we have the ad-hoc practice of printing MAC address stickers which could just as easily be the ad-hoc practice of printing DUID stickers if not for an apparent complete lack of imagination on the implementers' part. > The conclusion will inevitably be: IPv6 isn't there yet, because it's too much work for little benefit. Too many changes in existing processes, too much risk. Of course if there is little benefit to you, replacing your existing infrastructure and processes is going to be a high relative cost. This is true of any new technology, especially for an enterprise where existing infrastructure and processes were not exactly conjured in a day.

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 flaw can be argued to be in the products' implementation of the standard or the standard itself. I do argue for the flaw to be in the standard because the standard doesn't do what it's name suggests: standardize. Instead it has balkanized (not on its own of course, but by allowing implementers too much of a choice and too few hard rules, too much SHOULD instead of MUST). There is a cycle in many enterprises where someone asks "could we implement IPv6?". Then things like these come up, everybody looks at discussions like ours where there are pie-in-the-sky arguments about "you could just pick the right software/hardware" and "you could change it like that". The conclusion will inevitably be: IPv6 isn't there yet, because it's too much work for little benefit. Too many changes in existing processes, too much risk. Then the IPv6 topic is dead again, maybe for two or three years until someone asks again. This has been going on for almost 20 years now. If you have ever been wondering why enterprises usually don't do IPv6, there is your reason. The braindamage that is DHCPv6 along with the false claims of "if you want 'enterprise' and 'managed networks' you need DHCPv6" is a large part of it. I have no idea how things would get any better, however, DHCPv6 is recognizably a dead end.
  - boomlinde 6y ago
    > The flaw can be argued to be in the products' implementation of the standard or the standard itself. I do argue for the flaw to be in the standard because the standard doesn't do what it's name suggests: standardize. Instead it has balkanized (not on its own of course, but by allowing implementers too much of a choice and too few hard rules, too much SHOULD instead of MUST). So you call people out for their shoddy products until the SHOULDs are practically adopted as MUSTs. Is there a legitimate reason for some network appliance with any form of persistent storage that you can write to once or more to use different DUIDs through its lifetime? Nope. If it does it's badly implemented. Do burn-in, just like you do with MAC and print the DUID on the box, just like you do with MAC. How you achieve that is no concern of the DHCPv6 protocol, just as how the MAC address is derived or whether it's printed on the box is no concern of the DHCP (v4) protocol. Perhaps one can say that there is a lack of standardization in the area of human friendly physical machine to address mapping. DHCPv6 and DHCP (v4) are not those standards. Instead we have the ad-hoc practice of printing MAC address stickers which could just as easily be the ad-hoc practice of printing DUID stickers if not for an apparent complete lack of imagination on the implementers' part. > The conclusion will inevitably be: IPv6 isn't there yet, because it's too much work for little benefit. Too many changes in existing processes, too much risk. Of course if there is little benefit to you, replacing your existing infrastructure and processes is going to be a high relative cost. This is true of any new technology, especially for an enterprise where existing infrastructure and processes were not exactly conjured in a day.