Re: Node Requirements: Elevating DHCPv6 from MAY to SHOULD

[Mohacsi Janos <[e-mail]>]

On Tue, 31 May 2011, Markus Hanauska wrote:

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

The impact of changes can be quite substantial.

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


Agree. Adding DHCPv6 support to an existing IPv6 capable implementation 
might be possible.

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

I disagree with introduction of another flags. This requires substantial 
changes in the codes.... Which will take ages....

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

We need M/O bits to give some sort of consistency. But nothing prevent a 
host to use DHCPv6 and SLAAC address and static in the same time.

I have to disagree with your suggested ordering.

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

Nothing prevent you the suggest an draft document for multicast or anycast 
resolving DNS. There is environment where SLAAC more acceptable - e.g. 
less adminisration, and there is environment where DHCPv6 is the only way 
to operate.


Best Regards,
 		Janos Mohacsi