Hacker News Reader

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.

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.

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

It usually isn't "my product" but whatever somebody has bought and wants to bring onto the network.

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.

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 :)

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.

This is all correct, but is it an argument for never supporting DHCPv6 as an alternative in Android for those who want it and are prepared to deal with the brokenness (assuming it's broken for them)?

Note personally I also use SLAAC on my network.

Well, most arguments in the original article for DHCPv6 in android are based on things that either do not apply to android or are better solved without DHCPv6:

- DNS search paths can be set with RFC8106 RA options

- Changing DNS servers can be done the same way via RA options or via Anycast addresses

- tracking IP-host-assignments are better done with 802.1x, MAC filters and ARPwatch/NDwatch (One might use DHCP snooping, but that is usually broken with DHCPv6, also in this case, the security is in the snooping and blocking part, not the DHCP part). Everything else is really easy to fake and therefore useless.

- WLC options are only relevant in the control network of your WIFI which shouldn't really be shared with any android device

- VoIP phones should be a separate ESSID/VLAN/network because of QoS and security anyways. Also, most VoIP equipment doesn't properly handle IPv6 anyways, Let alone IPv6-only.

The only arguments left are: hostname registration and "everybody else is doing DHCPv6". Those are not bad arguments, but maybe don't justify the added support complexity for the android devs.

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

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.

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

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.

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

And how do I get the initial hostname? Is it unique? Will it even be set? The hostname field is optional ;)

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

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.

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.

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.

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.

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

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.

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

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.

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

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

Even the operating systems, with persistent storage in the form of harddisks get this wrong: a DUID is reassigned on every reinstall, at least. MAC addresses are convenient since they are basically global serial numbers in the form of ROM, fuses or similar. Only later were MAC addresses generated on the device by a RNG. There is just no hope for the DUID situation to ever get better, meaning DHCPv6 will never get useful.

> 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

No, it isn't. There are technologies that are designed to be easy to migrate to newer versions. Usually one doesn't notice those, because of the lack of problems. E.g. going from Ethernet to WiFi is relatively simple because of the intentional huge similarities. Upgrading a HTTP server from 1.0 to 1.1 to 2 doesn't change a lot in your processes, although there are huge differences especially from 1.1 to 2. TLS 1.3 looks completely different from 1.2 on a protocol level, but it was designed with upgrades in mind. To an admin or end user, it is practically the same.

Other technologies, e.g. POP3 vs. IMAP or cloud-based vs. physical computing can easily run side-by-side.

IPv6 is lacking in both methods of migration. You can't transparently upgrade (which would be hard to accomplish because of the different addresses). And you can't run it side-by-side easily, because of problems like the lacking DHCPv4/DHCPv6 correspondence. I would argue that IPv6 would be much more of a success if designers had not purposefully ignored that.

You can run v4 and v6 side by side easily though -- they work pretty much the same way as each other, and that's the standard deployment model. From an end-user perspective, there is no difference: you go to Google, search for "facebook" or whatever and click on the first link. All of this happens over v6 in exactly the same manner as it does over v4.

As for v6 autoconf not working exactly the same as DHCPv4 does, it's not like they purposely ignored it. Remember that DHCPv4 was being standardized at about the same time IPv6 was, and it wasn't really ubiquitous until a good half a decade afterwards. The RFC for router advertisements in v4 was published two years before even DHCP was, and there were various other ways of doing autoconf. It's not reasonable to expect them to have known that DHCP would win.