4 ms·
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 d
by 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 agoIt usually isn't "my product" but whatever somebody has bought and wants to bring onto the network.
- boomlinde 6y agoThat 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 agoThe "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 agoI 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.
- rwmj 6y agoThis 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.
- corty 6y agoWell, 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.