Subject: Re: Discussion Item - Reconfiguration in DHCPv6 (Items 8, 9, 18 on Co nference Call Agenda)

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Sep 2000 19:47:45 -0700 (PDT)

Catching up on email ... somebody else might have already brought this up.

> I don't think multicast adds efficiency.  It only reduces the number of 
> messages by a constant factor (1/2 at best) and makes reliable 
> communication with clients significantly more difficult.  Security is also 
> a significant issue for multicast.

I agree that it doesn't add efficiency.
But in the case where the DHCP server isn't handing out addresses it might not
retain knowledge of all the clients. Being able to use multicast in that
case to tell all interested clients that there is an updated value to the foo
option, while still requiring O(n) packets, might be useful.

> We can always add multicast later...

Agreed.

   Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 20 Sep 2000 20:11:48 -0700 (PDT)

Ralph,

> In any event, multicast is intuitively appealing.  But the devil appears
> to be in the details.  I hope this summary is both concise and precise...

The summary captures the case when the server knows the addresses of 
all the clients it wants to reconfigure.
If the DHCP server doesn't hand out address to a set of clients
it might not want to track the identity of those clients that have only 
received "random" DHCP options/extensions. But the server might still
be interested in being able to use reconfigure to "update" those random
options.

Using multicast in that case has a different set of issues...

Presumably the DHCP server wants to reach all clients so that they all
get the new information (option content) and purge the old information.
But the server doesn't know the whole set of clients that it needs
to receive messages from.

RFC 2894 has a theoretical approach to this type of problem in section 8 for
those interested. But the high-level point is carried in the IESG
note in that RFC:
   This document defines mechanisms for informing a set of routers of
   renumbering operations they are to perform, including a mode of
   operation in environments in which the exact number of routers is
   unknown. Reliably informing all routers when the actual number of
   routers is unknown is a difficult problem. Implementation and
   operational experience will be needed to fully understand the
   applicabilty and scalability aspects of the mechanisms defined in
   this document when the number of routers is unknown.

So while it might be interesting to think about using multicast reconfigure
in this "reconfigure non-address information" case, it is a very hard
problem to do reliably.

  Erik

---

From: Bernie Volz <[email-masked]>
Date: Thu, 21 Sep 2000 20:50:05 -0400

>> We can always add multicast later...

I'm not sure I agree with this. But, it all depends on what you mean by
later. If you're saying not in this revision of the draft, OK. If you're
saying 3 years from now, I think that would be a bad and wrong assumption.
You'll have deployed clients (at least I'm assuming "this time" IPv6 will be
deployed relatively soon - 3 to 4 years ago we were assuming that). Changing
those clients won't come easy because you're assuming we can revise the spec
and they'll all start working - ha!

If no clients support multicast reconfigure, what reason is there for
servers to implement it or use it? If no servers implement or use it, why
build clients that will?

Perhaps I'm being too alarmist here, but I see this as a fairly fundamental
issue and it should be resolved now. I have NO problem in saying that
"clients MUST ignore multicast reconfigure messages unless those message are
authenticated in some manner that is still TBD (perhaps via IPsec, a server
authenticator, or some other means)." This is again somewhat of an issue
since clients will not use these packets until the authentication method is
specified.

- Bernie Volz

---

From: Ralph Droms <[email-masked]>
Date: Fri, 22 Sep 2000 16:06:00 -0400

At 08:50 PM 9/21/00 -0400, you wrote:
>later.

I'm of two minds about "later" - on the one hand, I recognize that,
based on our experience with DHCPv4, we need to get words in the
spec now if we're ever going to deploy multicast reconfigure; on
the other hand, we're already perilously close to slipping
the 9/30 pub date for the next rev of the draft.

- Ralph