IPv6 Deployment for the LAN

Wed Oct 21 20:56:39 UTC 2009

On Oct 21, 2009, at 1:05 PM, Iljitsch van Beijnum wrote:

> 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?
>
Bigger address space -- The only real improvement in IPv6.

> 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.
>
I agree that DHCPv6 should be fixed, but, fixing it should include  
adding the ability to
assign routing information.

> 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.
>
Yes and no. RA giving out DNS information and a pointer might help,  
but, it
doesn't solve everything.  There is functionality provided by DHCPv4  
today
that is not available in DHCPv6, RA, or SLAAC or any combination.  This
must get resolved. It is an impediment to IPv6 adoption in the real  
world.

The other features and improvements are all well and good if they work  
and
they don't prevent the protocol from being accepted and/or deployed in  
the
real world.  With less than two years of remaining IANA IPv4 free  
pool, I think
it is far more important that we get a deployable protocol with bigger  
addresses
than one which contains a bunch of other features that aren't  
universally
regarded as an improvement at the cost of existing functionality that  
has
demand from real network operators.

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

Nobody is proposing taking RA away from networks that want to use it.   
We're
proposing making it an option to assign router information in DHCPv6.

So, given that the question isnt' taking away what you want, can we  
please
now add capabilities that many people actually need?

Owen