IPv6 Deployment for the LAN

Iljitsch van Beijnum iljitsch at muada.com
Wed Oct 21 15:05:44 CDT 2009


On 21 okt 2009, at 21:50, David Conrad wrote:

> On Oct 21, 2009, at 12:46 PM, Iljitsch van Beijnum wrote:
>> On 18 okt 2009, at 10:03, Andy Davidson wrote:
>>> Support default-routing options for DHCPv6 !
>> This would be a big mistake. [...] It's time for this DHC stuff to  
>> reach its final resting place.

> I'm curious: are you anticipating IPv4 network operators are willing/ 
> interested/planning on redesigning/rebuilding their entire  
> provisioning and backend systems in order to support IPv6?

No. Hence the low IPv6 utilization.

Then again, if we remove all the improvements from IPv6 what's the  
point of adopting it?

The problem with DHCP is that it is an old answer to an even older  
question. Strangely, DHCPv6 is even worse in this regard than DCHPv4.  
Some protocol designers were clearly sleeping on the job there, or  
they were to busy getting in the way of those of us who wanted a non- 
DHCP way to configure DNS resolvers. Whathever the reason, DHCPv6 is  
riddled with a badly specified way to interact with manual  
configuration and stateless autoconfig, it lacks a prefix length  
option and it has two modes, where the server knows which mode should  
be used but the client has to guess the right one.

In this day and age it doesn't make an iota worth of sense to update  
binary protocols on two sides whenever there is something new to  
discover. What we need is a thing that gives us what we need to  
connect to the network (addresses, DNS servers) and then a pointer in  
the form of an HTTP or HTTPS URL for all other configuration.

Of course that's not going to happen but taking stuff away from IPv6  
that actually works (RA fate sharing) isn't going to solve the DHCPv6  
problems.




More information about the NANOG mailing list