Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

[Markus Hanauska <[e-mail]>]

On 2011-05-31, at 12:35 , Philip Homburg wrote:

> The difference is that IPv4 has a model of one subnet per link.

Why do you think so? The computer I'm using right now has two IP addresses of different IP subnets on the same network interface (and I really mean the same layer 2 network, there are no VLANs in use). I think pretty much any operating system as of today allows for such a configuration.

> That's always that case if you want a configuration that is not mainstream:
> you either have to buy a more expensive product that has more configuration
> options or, in many cases, you can also use open source.

But don't you think it helps a lot to push a new technology to mainstream if it is possible to also use this technology without any expensive hardware or complicated configurations? My main argument was (and still is), that through a couple of tiny changes in the RFCs (only a couple of sentences) and equally small changes to implementations (5-10 lines of additional code), IPv6 could have been so much easier for everyone: Hardware vendors producing IPv6 hardware, software vendors writing IPv6 software, network administrators creating IPv6 networks, end users actually using IPv6. The negative impact would have been close to zero, the positive impact would have been big and maybe IPv6 would have been somewhat more mainstream as of today if people had considered some tiny things. The most important ones are:

1) A need for DHCPv6 right from the start and taking it into consideration everywhere SLAAC was taken into consideration. E.g. is this thread; DHCPv6 should have been "SHOULD" right from day one.

2) A better way to run SLAAC, SLAAC + Privacy Ext, DHCP and manual addressing all on the same link *AND* same prefix in such a way, that it is almost address conflict free without having to rely on ND to discover conflicts (since ND will fail for hosts currently offline, but with reserved addresses): Defining all addressing schemes in such a way, that they don't interfere with each other under "normal" operation conditions - of course MAC address conflicts are still possible, two nodes with SLAAC + Priv Ext may also collide (only ND can avoid that) and misconfiguration will always be possible; but I consider none of these as normal operation conditions). Only two flags in 64 bit node addresses would have been necessary for that.

3) No M/O bits in router advertise messages. Every interface can have a manually configured address, a DHCPv6 address, a SLAAC address, a SLAAC w/ Priv Ext and that for every prefix it is aware of. The order of preference for outgoing traffic is configurable, the default order is defined in any RFC (e.g. I would suggest manual, DHCP, SLAAC w/ Priv Ext, SLAAC).

4) Considering DNS right from the start, since DNS is almost critical for many networks as of today. If one of the IPv6 main design goal was to allow the majority of networks to operate without a DHCP server (and it looks as if it was, otherwise DHCPv6 would have been taken much more into account), something like RFC 6106 (former 5006) was missing way too long IMHO. Though I still fail to see the need for this RFC at all; I had rather said that for simple setups that don't provide DNS servers via DHCP, it would have been enough to have a well defined anycast or even multicast address for DNS servers (I don't know any real life network where DNS server addresses changes so frequently, that this wouldn't work well in practice).

Regards,
Markus