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

From: Ralph Droms <[email-masked]>
Date: Mon, 15 Mar 2004 18:06:19 -0500

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

---

From: Greg Daley <[email-masked]>
Date: Tue, 16 Mar 2004 14:49:15 +1100

Hi Ralph,

> draft-ietf-dhc-dhcpv6-opt-nisconfig-05.

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

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

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

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

> decision about how to use those addresses up to the

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

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 16 Mar 2004 08:29:47 -0500

Ralph, et al:

I fully agree with your "wg_member" comments. I too believe this is a
host issue and not a DHCP protocol issue.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ralph Droms
Sent: Monday, March 15, 2004 6:06 PM
To: [email-masked]
Subject: [dhcwg] Dual-stack hosts using DHCP (was Re: [dhcwg]
draft-ietf-dhc-dhcpv6-opt-nisconfig-05.txt)

<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:
>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.
>
>be using the well known multicast address, instead of a particular 
>server) or via SLP, or perhaps even DNS SRV records, or ...
>
>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
>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).

---

From: Tim Chown <[email-masked]>
Date: Tue, 16 Mar 2004 13:56:44 +0000

I think that's probably fair comment, but have not yet read all the mail
thread and IETF WG minutes.

I think there is an open question here for the dual-stack case.  In other
WGs, esp. v6ops, where such questions arise a discussion is held and then
documented (e.g. for dual-stack SMTP best practice).  If the result is that 
we decide it is a host issue, I think there is still value in documenting 
the issues and explaining why we came to a certain conclusion.

The problem of manual configurations "clashing" with DHCP is mentioned in
the draft.   That exists for v4 now of course, without dual-stack.  

This would also allow us to document what the issues are for the host in
handling the information it receives from DHCPv4 and DHCPv6 servers, 
if we assume best practice is to not carry IPv4 options in DHCPv6.

Consistency of information seems to be a pillar in the argument; and that
is a local administrative issue.   There are some cases where this may not
be possible, e.g. where the v4 and v6 provider is different, but these
may be fringe cases. 

Tim

---

From: Stig Venaas <[email-masked]>
Date: Wed, 17 Mar 2004 15:57:16 +0100

I agree that it may be possible to solve the issue on the host side,
leaving to the host to decide what information to use. However, I
still think it could be useful in some cases to learn IPv4 addresses
of services from a DHCPv6 server, simply to reduce amount of signalling
and not requiring DHCPv4 server. One simple, and I think pretty harmless,
solution could be to use IPv4-mapped IPv6 addresses.

If this is to be solved on the host, I wonder how I as an administrator
can make sure the right thing happens. Can we (IETF) at least do some
sort of bcp or guidelines? I think the guidelines may be just as
important for implementers of DHCP clients. For the administrator to do
something, there must be some knobs to turn or whatever.

Stig