Subject: RE: Francis's INput at the Design Meeting

From: Bernie Volz <[email-masked]>
Date: Mon, 18 Sep 2000 10:38:30 -0400

I'm for keeping the DHCPv6 name. Agreed that it is Stateful, but remember
that the V6 people didn't call it DHCP for a reason - they wanted to
potentially support any (multiple) stateful protocols/techniques.

This also could be included in Ralph's issue of what to call the message
names? If we're going to use the DHCPv4 names, why would we than want to
call is SAC? If we're not going to use the DHCPv4 names (which I am in favor
of), perhaps it is open to further discussion whether this should be DHCPv6
or SAC. But again I feel DHCPv6 is far better as it is based on DHCPv4 and
takes into account new features of IPv6.

ND Daemon is a Neighbor Discovery daemon, I suspect. I think Jim feels that
DHCPv6 (client side) is really part of the ND Daemon that handles all
addressing issues (whether stateful or not).

- Bernie Volz

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Monday, September 18, 2000 12:45 AM
To: DHCPv6 discussion list
Subject: Re: Francis's INput at the Design Meeting

> I want to state I am now thinking Francis's input at the meeting may
> make sense.  Maybe this should not even be called DHCP but Stateful
> Address Configuration for IPv6 (SACv6).

I can see where you're coming from, but this is kind of like saying
"let's call it toasted wheat crumbs instead of Grape Nuts" at this
point.   :'}

> Also I am far more concerned about integration with IPv6 Statless
> Addrconf than DHCPv4 as a DHCPv6 implementor?

Right, but what about your customers?   If you want to really
differentiate between DHCPv4 and DHCPv6 because there's some
important functional difference between the true, then confusing the
customers is probably a good thing, but if DHCPv6 is going to have
similar uses to DHCPv4, keeping the name the same makes more sense.

> How many dhcpv4 implementors have looked at the ND daemon to do
> stateless addrconf and the code?  We want to reuse much from that as
> IPv6 implementors as possbile.

What's an ND Daemon?

> Also it could be we have multiple views of Stateful addrconf too.
> Not that its a good idea but if we don't support IPv6 first in every
> manner that will happen.

I think ideally we should make it possible for people to get what they
want by layering on a good base protocol rather than inventing new
ones.   That's what we're trying to do here, right?

			       _MelloN_

---

From: Jim Bound <[email-masked]>
Date: Mon, 18 Sep 2000 11:51:50 -0400

good response bernie but mostly I feel francis's input was not discussed
or his issues from the con call and we need to keep this process open to
all input and francis went silent and is the only one on this list that
has written dhcpv6 code I am aware of except for me.  so I am trying to
entice him back to the discussion I think he got annoyed from the con
call.

thanks,
/jim

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Sep 2000 00:34:41 +0200

In your previous mail you wrote:

   I'm for keeping the DHCPv6 name.

=> the name doesn't really matter but:
 - IMHO it is important to understand DHCPv6 is more the statefull version
   of IPv6 autoconfiguration than the IPv6 version of DHCP, ie. it is
   supposed to add management to the existing stateless autoconf, not
   to do things which are exotic (for IPv6) or already done by other
   tools (like some service discovery).
 - formally the name DHCPv6 is wrong because it will apply to routers
   too (in fact, DHCPv6 is more useful for routers than for hosts because
   stateless autoconf works only for hosts). This point should be made
   clear in the new draft.

   ND Daemon is a Neighbor Discovery daemon, I suspect.

=> yes, ND is the nick name of Neighbor Discovery. Prefix discovery and
address autoconfiguration are two of the nine functions of ND.

   I think Jim feels that DHCPv6 (client side) is really part of the
   ND Daemon that handles all addressing issues (whether stateful or
   not).
   
=> the code managing the stateless autoconf must interoperate with
the DHCPv6 client. An easy way to do this is to manage both in an
user daemon.

Regards

[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Tue, 19 Sep 2000 18:12:03 -0700

>    tools (like some service discovery).

Can you tell me what you mean by "the stateful version of IPv6
autoconfiguration"?  How does that differ from what the -15 draft
of DHCPv6 does?

- Ralph

---

From: Francis Dupont <[email-masked]>
Date: Wed, 20 Sep 2000 19:41:22 +0200

autoconfiguration"?

=> according to RFC 2461 introduction:

(what is autoconfiguration)

   This document specifies the steps a host takes in deciding how to
   autoconfigure its interfaces in IP version 6. The autoconfiguration
   process includes creating a link-local address and verifying its
   uniqueness on a link, determining what information should be
   autoconfigured (addresses, other information, or both), and in the
   case of addresses, whether they should be obtained through the
   stateless mechanism, the stateful mechanism, or both.  This document
   defines the process for generating a link-local address, the process
   for generating site-local and global addresses via stateless address
   autoconfiguration, and the Duplicate Address Detection procedure. The
   details of autoconfiguration using the stateful protocol are
   specified elsewhere.

(what is the stateful autoconfiguration)

   In the stateful autoconfiguration model, hosts obtain interface
   addresses and/or configuration information and parameters from a
   server.  Servers maintain a database that keeps track of which
   addresses have been assigned to which hosts. The stateful
   autoconfiguration protocol allows hosts to obtain addresses, other
   configuration information or both from a server.  Stateless and
   stateful autoconfiguration complement each other. For example, a host
   can use stateless autoconfiguration to configure its own addresses,
   but use stateful autoconfiguration to obtain other information.
   Stateful autoconfiguration for IPv6 is the subject of future work
   [DHCPv6].

   How does that differ from what the -15 draft of DHCPv6 does?

=> my concern is about the "other informations". Some are critical
(security, DNS), some can be useful (NIS/NIS+/WINS server), some
are only ridiculous (weather schedule :-).

The current draft tries to be multi-purpose, IMHO this is a bad idea
because this makes DHCPv6 even more complex and not suitable for
a simple discovery mechanism.

Perhaps it is not the time to discuss about this (even if this issue
is a source of the incredible delay of DHCPv6) but I argue (and I'll
continue to argue) that the priority is the address configuration.

We already have the stateless autoconfiguration for years then:
 - we have the proof the discovery part is not (yet) critical
 - we have a lot of constraints on address configuration
   (ie. in some cases DHCPv6 should do the same thing than stateless
    autoconf with the "database that keeps track of which addresses
    have been assigned to which hosts" in (only) addition)

Regards