Subject: Francis's INput at the Design Meeting

From: Jim Bound <[email-masked]>
Date: Sun, 17 Sep 2000 23:01:19 -0400

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

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

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.

If you don't have access to an IPv6 stateless address conf
implementation I am sure Francis's code can be viewed as I think its
public domain.

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.

regards,
/jim

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Sep 2000 21:44:45 -0700

> 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.   :'}

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

> IPv6 implementors as possbile.

What's an ND Daemon?

> Not that its a good idea but if we don't support IPv6 first in every

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 12:01:47 -0400

>similar uses to DHCPv4, keeping the name the same makes more sense.

DHCP name is fine with me I just wanted Francis's input discussed like
yours, mine, and ralphs I really don't care what the name is and I don't
think my customers do.  But dhcpv6 is not dhcpv4 and IPv6 has enough
parts that make it completely different.

>What's an ND Daemon?

Neighbor Discovery Daemon.  Processes Ipv6 stateless parts and will know
if dhcpv6 should be started.

>ones.   That's what we're trying to do here, right?

Yes and that good protocol is IPv6 stateless not dhcpv4 as the model.

regards,
/jim

---

From: Thomas Narten <[email-masked]>
Date: Mon, 18 Sep 2000 14:41:52 -0400

> Address Configuration for IPv6 (SACv6).

The above title wouldn't seem to be consistent with DHCP being used to
send configuration parameters other than addresses (e.g., server
addresses, time zone info, etc.).

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Mon, 18 Sep 2000 07:46:51 -0400

>Address Configuration for IPv6 (SACv6).

I had thought about making a similar observation, given that the current 
draft is not trying to reuse DHCPv4 technology.  However, we have a spec to 
get out, as quickly as possible, and diving into a discussion about 
renaming will, in my opinion, slow down the work on the spec.

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Mon, 18 Sep 2000 21:45:10 -0400

>renaming will, in my opinion, slow down the work on the spec.

I agree and as Thomas pointed out the above only means addresses.
No discussion on name changes I have ever seen is fast.

regards,
/jim

---

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

=> but is this really the job of DHCPv6? As soon as a node gets some
not too local addresses it can use any service discovery protocol.
IMHO it is not a good idea to overload DHCPv6 with secondary config
tasks, ie. DHCPv6 should only manage addresses, DNS and security
(security because of IPsec usage of destination addresses for SAs,
DNS because we have no good lightweight/zeroconf DNS tools today).

[email-masked]

PS: a part of DHCPv6 complexity, for instance relays or reconfigure, has
no meaning if DHCPv6 is used for service discovery or parameter
distribution. I don't ask to split DHCPv6 in two protocols because
in fact service discovery and parameter distribution protocols already
exist, they just don't work well with off-link nodes without routable
addresses.

---

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

>DNS because we have no good lightweight/zeroconf DNS tools today).

In theory, I agree with you.  In practice, we've waited a *long* time
for a discovery protocol in the current protocol suite.  Do we
have any confidence that we'll have a discovery protocol specified
and deployed to take ove that role from DHCPv6?

- Ralph

---

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

In theory, I agree with you.  In practice, we've waited a *long* time
   for a discovery protocol in the current protocol suite.  Do we
   have any confidence that we'll have a discovery protocol specified
   and deployed to take over that role from DHCPv6?
   
=> we should try to split on a paper the address management part
of DHCPv6 and the general discovery part. I believe two different
protocols won't be really larger than the current multi-purpose one,
and if we look at current issues it is clear most of them belong to only
one of the two parts. Again the situation of IPv4 is different, in IPv6
we already have a form of autoconfig then it is reasonable to use
DHCPv6 only for the discovery part but in this case why to use relays,
...
The real question is what is the faster way from today: throw away
the discovery part in order to get the stateful autoconf ASAP (IPv6
way :-) or the recycle again and again the multi-purpose thing until
we get something useable (DHC/current way :-).

Regards

PS: I propose to start with a simple example, for instance NIS server
discovery: if the NIS server is not on-link then we can assume the node
has already a not-too-local address (or it won't be able to reach the
NIS server) then the relay function should be garbage collected.
The information is not releasable (:-) and can be got several time then
a multicast request / unicast (multiple) reply works (remove solicit/
advertisement). The reconfigure function has no more critical too...
This gives a far simpler protocol!