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

[Ralph Droms <[e-mail]>]

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

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

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.

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>

- 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 <[e-mail]>
>     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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg