Re: [dhcwg] Dual-stack hosts using DHCP (was Re: [dhcwg] draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt)

Hi Ralph,

Ralph Droms wrote:
> <wg_chair>
> In the interest of forward movement, I would like the WG to pick up the
> conversation about dual-stack issues around the two specific drafts
> draft-ietf-dhc-dhcpv6-opt-sntp-00 and 
> draft-ietf-dhc-dhcpv6-opt-nisconfig-05.
> </wg_chair>

I've not read these deeply, but perhaps I can contribute
for the wider context.

> <wg_member>
> After re-reading draft-ietf-dhc-dual-stack-00 and considering the 
> discussion
> of dual-stack issues at the WG meeting in Seoul, I find myself in agreement
> with kre's analysis (included below).
> 
> Fundamentally, there is a problem here that rightfully belongs in the
> administrative or management policy in the host itself.  A host
> may receive configuration information from a variety of sources: PPP,
> RAs (IPv6), well-known addresses for services, SLP, DNS SRV RRS, DHCP,
> manual configuration, etc.  The host itself may be connected to multiple
> physical interfaces or multiple logical interfaces (e.g., VPN).

I'd guess that part of this is what's motivating the work on
DNAv4 and DNAv6, where the host is essentially trying to
determine what's authoritative configuration for basic
connectivity.

Eventually, we may see some ideas about IPv4 and IPv6
interoperation in DNA heading in the same direction, so I'm
interested in seeing how things pan out here.

> I can imagine constructing multiple plausible scenarios in which
> the host would use configuration information from multiple
> sources in different ways.  And, looking at the problem from the
> DHCP point of view, there is no way for the DHCP server to
> determine how the host is configured, and, therefore no way
> for the DHCP server to determine the right way to deliver
> the configuration information to the host.
> 
> Therefore, it seems to me the right thing to do is for the
> various sources of configuration information to operate
> independently, allowing the host to make any decisions about
> integrating the information from the various sources.

It's been said before, but I'd guess that the security
associations for IPv4 and IPv6 based configuration information
may (in general) be difficult to reconcile here too.

I'd guess that the role of joining the v4/v6 configuration
systems together is principally to limit signalling.
At this stage, I don't know if there's a compelling
idea otherwise.

This may be a real driver for hosts on wireless access networks
though.

> In the case of DHCP, I think the right thing to do is to
> keep DHCPv4 and DHCPv6 separate, so the host treats information from
> DHCPv4 and DHCPv6 as arriving from different sources, and makes its
> own decisions about how to integrate the information.

Perhaps this isn't entirely in agreement with what you
stated above.

I'd guess that a host which is capable of both IPv4 and
IPv6 configuration could explicitly request version
specific information on either configuration path.

This could potentially be a host decision, based on
logic above either DHCPv4 or DHCPv6.

As kre says, this may not be something which can just be
written up yet, since it presupposes co-ordination of
the procedures which isn't available in either protocol
yet, or may be done more fruitfully in general, rather than
just for DHC or even DNA.

> In the case of draft-ietf-dhc-dhcpv6-opt-sntp-00 and
> draft-ietf-dhc-dhcpv6-opt-nisconfig-05, the right thing to do would
> be to carry only IPv6 address in these options, leaving the
> decision about how to use those addresses up to the
> receiving host.
> </wg_member>

I'd guess that's right at the moment, but
it may be worth looking at the host based mechanisms
to co-ordinate these things:

Whether there's a need to combine the DHCPv4/v6, or
even a more general need to co-ordinate further
configuration signalling may affect how this is
done.

Greg

> - Ralph
> 
> At 06:11 PM 2/11/2004 +0700, Robert Elz wrote:
> 
>>     Date:        Tue, 10 Feb 2004 08:10:23 -0800
>>     From:        Harald Tveit Alvestrand <harald@alvestrand.no>
>>     Message-ID:  <2015037.1076400623@localhost>
>>
>>   | Apologies - just because I think you're wrong is no excuse for 
>> snapping at
>>   | you.
>>
>> No apologies needed, at least not for me - the message I replied to
>> wasn't directed (specifically) at me.   In any case, I didn't view your
>> comment as in any way objectionable, just farcical...
>>
>>   | I still think you're wrong.
>>
>> I fully understand your point of view.   And I certainly agree,
>> getting different config info from different sources is a problem,
>> and one that it would be nice to have a clean solution to.
>>
>> But I don't think you can really expect DHCP to suddenly provide it,
>> or not in the context of the DHCPv6 NIS configuration option in
>> any case.
>>
>> The problem is much broader than that - there are many more sources
>> of config info than just N interfaces each providing host config
>> information via DHCP.
>>
>> Config info is also available via well known addresses (ie: SNTP could
>> be using the well known multicast address, instead of a particular 
>> server)
>> or via SLP, or perhaps even DNS SRV records, or ...
>>
>> Any and all of that might conflict with any other of it.   What a host
>> should do in circumstances like those isn't easy to specify.
>>
>> DHCP on the other hand has been as it is now since day 1 - it gets config
>> info about an interface, and throws in all kinds of host configuration
>> at the same time - naturally leading to (potentially) multiple different
>> configs being received.   DHCPv4 is like that, DHCPv6 isn't any 
>> different.
>> Altering that would be a major project, and NIS configuration just isn't
>> important enough to embark upon that!
>>
>> kre
>>
>> ps: I haven't read today's list traffic yet (the last message I saw
>> was my own - the one full of typos).
> 
> 
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg