DHCPv6-4.1.mumble

Sten Carlsen sten at s-carlsen.dk
Thu Jun 12 19:54:46 UTC 2008


This whole question is, I assume, centered around the transition from 
IPv4 to IPv6, how would you see this transition happening?

- Change overnight, one morning the network is IPv6.

- Enable IPv6 support to see which clients have functioning support and 
when all have switched in practise cut IPv4.

- Have IPv6 subsystems pop up on the network and let the clients move 
one at a time but move completely.


I would vote for some degree of slow transition and that means that some 
configuration service is needed that can give out consistent information 
for both systems for use in one PC.

As I see it we don't have the solution at this moment, dhcpd will give 
out EITHER IPv4 info OR IPv6 info. So you need to switch the whole 
network at one time or at least have each PC select will it be 100% IPv4 
or IPv6.

Does this look feasible to you?

Or what should be the plan.

David W. Hankins wrote:
> On Thu, Jun 12, 2008 at 06:22:18PM +0000, Evan Hunt wrote:
>   
>>> again: i think there are at least two advantages to IETF DHCP's
>>> approach of segregating IPv6 and IPv4 configuration state betwixt
>>> the two protocols - DHCPv4 and DHCPv6.
>>>       
>> Out of curiosity, what are these advatages?
>>     
>
> i mentioned fate-sharing; if your DHCPv4 server runs out of leases,
> the client is unlikely to receive the configuration (it is unlikely
> to try DHCPINFORM since that would actually be illegal without a
> valid IP address, and rather continue trying DHCPDISCOVER).  in this
> case, the client probably does have an ipv6 address, and so could
> easily speak to the IPv6 addresses of the nameservers were it so
> capable.  this fate-sharing is an advantage of the system, and it
> produces a clean symmetry in implementation for single-stack
> networks; no cross-dependancies to tear down later.
>
> i also mentioned simplicity.  if you additionally have 6-in-4 and/or
> 4-in-6 options, then you have doubled the complexity to implement a
> client.  it is hard enough to answer the question of what a client
> should do if it gets conflicting config from v4 and v6 (like domain
> search), you now also have to answer the question of what to do if the
> 6-in-4 config also conflicts with the 6-in-6, and prepare yourself for
> inconsistent choices among the vendors.  this seems like a linear
> doubling on the surface, but the effort to maintain and debug the
> software feels more exponential to me.
>
>   

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!" 



More information about the dhcp-users mailing list