Re: [dhcwg] Dual stack issues

[Vijayabhaskar A K <[e-mail]>]

Christian

comments inline..

Christian Strauf wrote:

>Hi Vijay!
>
>I agree with Stig in his mail (Stig: could you be so kind a post your
>response to the list? tnx!) saying that we have fundamentally different
>views. Having DHCPv4 only convey v4 information and DHCPv6 only v6
>information is only one view. Another view is to regard DHCPv6 merely as
>means of transport. If I remember correctly, there's no statement in RFC
>3315 saying that you must only transport IPv6 information with DHCPv6.
>  
>
It  doesn't matter whether it can be done or not. The real need is 
important.. I couldn't see an actual problem here.

>Additionally, there are a number of paradigms in DHCPv6 that we miss in
>DHCPv4 in our day to day operations, e.g. going away from using MACs for
>per-host address assignment but instead use DUIDs/IAIDs etc.. I see a
>real gain of administrative comfort in using DHCPv6 for transporting
>IPv4 information.
>
>  
>
>>eg:- SLP. In this way the problem exists still. So, I guess the best way 
>>to deal with the issue, rather than duplicating dhcpv4 options, its good 
>>to refer as IPv4 mapped IPv6 addresses. But still I am not convinced 
>>    
>>
>There're cases where this is not desirable e.g. when using broadcast
>address options for IPv4 which only make sense as suboptions of
>OPTION_IAADDR_IPv4.
>  
>
Though I am saying that the IPv4 service parameters can be given as IPv4 
mapped IPv6 addresses, I really dont like the idea of doing it. With a 
proper configuration of DHCPv4 and DHCPv6 server, you can acheive 
whatever the dual stack host need. Here, all the DHCPv4 address 
configuration (other than service parameters) should be done by DHCPv4

>  
>
>>parameters. They should be disjoint list configured by an intelligent 
>>admin. Thats it.
>>    
>>
>Well, from an admin's point of view it's practical to only have to
>administrate DUIDs and IAIDs for dual-stack hosts, not MAC addresses as
>well.
>  
>
I guess some work is going on in this area. Rather than porting all the 
IPv4 configuration to  DHCPv6, backporting of just a single feature 
makes more sense.

>  
>
>>overloaded dhcpv6 client.I couldn't get a reason why there should be 
>>single dhcpclient. Am I missing something here?
>>    
>>
>The issues listed in draft-chown-dhc-dual-stack-00 can be solved by
>having such a single client. Putting aside whether this is a pure DHCPv6
>client that can request IPv4 information options or if it is a combined
>DHCPv4/-v6 client, it is an elegant solution to the problems outlined
>there.
>  
>
Let me go through the list.. I have listed my comments along with the 
text from draft-chown-dhc-dual-stack-00

>3.1 Handling multiple responses
>
>   The general question is how to handle configuration information that
>   may be gathered from multiple sources.   Where those sources are DHCP
>   and DHCPv6 servers (which may be two physical nodes or two servers
>   running on the same node) the client node needs to know whether to
>   use the most recent data, or whether to perform some merger or union
>   of the responses by certain rules.  A node may choose to ask a DHCPv6
>   server and only use a DHCP server if no response is received.
>
Its a configuration issue....

Make DHCPv6 to send IPv6 params and DHCPv4 to send IPv4 params. Always 
the client needs to combine the list.
                   

>Merging is possible, but is likely to be complex. 
>  
>
It is not at all complex when the lists are disjoint.

>A node configured manually to use an IPv6 DNS server via
>   such manual configuration may lose that configuration if it then uses
>   DHCP to obtain IPv4 settings if in a dual-stack environment; 
>
The problem exists even with your solution. Moreover, this is not 
protocol issue. The admin can define the order.

>3.2 Multiple interfaces
>
>Per interface settings can be complex because a client node needs to
>   know from which interface system settings like NTP server came from.
>   And it may not be apparent which setting should be used, if e.g. an
>   NTP server option is received on multiple interfaces, potentially
>   over different protocols.
>  
>
NTP server is not a per interface settings. It doesn't matter from which 
interface it came from. The router will take care where to forward if 
there is a NTP request for a particular server.

>3.3 DNS load balancing
>
>   In some cases it is preferable to list DNS server information in an
>   ordered way per node for load balancing, giving different responses
>   to different clients.   Responses from different DHCP and DHCPv6
>   servers may make such configuration problematic.
>
Here you need a mix up of ordering.. Use DHCPv6, since it can give IPv4 
addresses as IPv4 mapped IPv6 addresses.

>3.4 DNS search path issues

This falls in same category as the prev one. Do specify the search 
order, thats it.

>3.5 Administrative management
>
It could be termed as configuration issue.. Needed to be fixed this in 
administration rather than protocols.

>3.6 DHCP option variations
>
use DHCPv6, send IPv4 mapped IPv6 addresses.

I really couldn't see the difficulties in the configuration of dual 
stack nodes. Without the clear problem statement, I am not able to 
co-relate the solution you propose. May be, I am missing somethings. 
Comments are welcomed.

~ Vijay




>Cheers,
>Christian
>  
>


-- 
__________________________________________________________
Vijayabhaskar A K            Phone : [phone]
Hewlett Packard              Mobile: [phone]
Bangalore, India             Email : [e-mail]

Intellectuals solve problems: geniuses prevent them.
-Albert Einstein, physicist, Nobel laureate (1879-1955)
__________________________________________________________



_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg