Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt

[Ted Lemon <[e-mail]>]

On Feb 9, 2004, at 10:19 PM, Margaret Wasserman wrote:
> What if the protocols are not different between v4 and v6?  I don't 
> know much
> about NIS, but the DNS and SNTP protocols (for example) are not 
> different
> between IPv4 and IPv6, nor are most other application protocols.

If we accept Harald's idea that the client should get its configuration 
from the DHCPv6 server and not the DHCPv6 server, then I think the 
simplest rule is to say that if the DHCPv6 server sends IPv4 addresses 
for a service expressed as IPv6 addresses, then those addresses are the 
ones that the DHCP client should prefer, and it should discard any 
addresses it receives for the same service through DHCPv4.

For the same service means what it says.   DNS is the same service 
whether the transport is IPv4 or IPv6.   By which I mean, the payload 
being sent over the transport is the same in either case - all that 
differs is the transport.  Generally speaking, the application ought 
not to know - the DHCP client should take care of it.

What I think maybe you're really pointing out here is that this 
requires (a) that we specify which service options refer to the same 
service between DHCPv4 and DHCPv6 and that (b) dual-stack V4+V6 hosts 
need to have their DHCPv4 and DHCPv6 clients communicating in some 
probably unspecifiable way, and (c) applications need to get this 
information from the DHCP clients using some API that hasn't been 
defined.

What we have done in the past (with DHCPv4) is to not specify these 
things, and leave them to the implementor.   So the DHCPv4 client on a 
Unix machine typically does things like run route(1) to set up routes 
and hack /etc/resolv.conf to set up name service, and most of the 
options are never actually used.

We have talked about specifying an API, and I think this is actually a 
good idea (not everyone agrees, of course!).   We shied away from 
specifying it in RFC3315 because we knew that if we tried, it would 
never get out the door.

Maybe we need to do that sooner rather than later.


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