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

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

In your previous mail you wrote:

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