The stupidity of trying to "fix" DHCPv6

Owen DeLong owen at
Thu Jun 16 20:18:52 UTC 2011

On Jun 14, 2011, at 10:56 PM, Iljitsch van Beijnum wrote:

> On 15 jun 2011, at 7:33, Owen DeLong wrote:
>> Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS vendors to make changes
>> because experience has shown that they are more willing to do so than vertical software vendors.
>> As such, yes, I'd like to see some harmless extensions added to DHCPv6 that solve some real world
>> problems.
> BTW, as long as you're making harmless changes: not putting a hard line end just _after_ 80 characters would make your messages easier to read.

OK... Line endings removed per your request.

> As established before, all of this is not harmless and OS vendors (not sure what you're talking about with BIOS) aren't all that willing to make changes, at least not on short timescales.

It is harmless. Adding routing information options to DHCPv6 does not in any way harm existing implementations.
Adding the ability to simultaneously request DHCP information and RA is a tiny amount of additional traffic on
the network (thus also harmless).

When I talk about BIOS, I'm taking into account that some DHCP implementations are in the PXE for diskless
booting and installation processes, etc. Admittedly, I'm not sure how many BIOS contain IPv6 capability
for this as yet anyway, but, it is an area that must eventually get implemented.

> It seems to me that the easiest solution to work around broken IPv4-only software isn't messing with the IPv6 protocol stack, but to create an IPv4 overlay on top of IPv6 that seems like a big IPv4 broadcast domain despite going through IPv6 routers.
I'm not sure how you propose creating an IPv4 broadcast domain that isn't an iPv6 link. I mean the theory
sounds great, but, in practice, it seems rather far-fetched.

> Actually this would also be quite useful in hosting environments where it would be easy to give every IPv6 customer their own VLAN but the IPv4 subnets are entangled.

Indeed, if it were even remotely possible.


More information about the NANOG mailing list