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

From: Ralph Droms <[email-masked]>
Date: Fri, 15 Sep 2000 09:29:27 -0400

At 09:51 AM 9/1/00 -0400, you wrote:
>During the DHCPv6 conference call on Thursday, August 31st, I was assigned
>the "responsibility" of coming to a resolution on reconfiguration in DHCPv6
>(items 8, 9, and 18 on Ralph's compiled list):

We might need to answer these out of order - if the answer to 18 is 
"DHCPv4-style unicast only", then the answer to 8 will be at least limited 
to the Reconfigure-init message.

>8. Allow Reconfigure and Reconfigure-reply messages to be sent via a
>     relay to client's which do not have such reachable IP addresses, in
>     order to inform them of changes in non-releasable resources?  The
>     same thing could also go for Reconfigure-init to some extent.
>
>9. Might a client send a Solicit in response to a Reconfigure-init?
>     What if the topology changes such that this is necessary in order
>     find a DHCP server with can allocate addresses on the new subnet?
>
>18. Simplify reconfiguration; Use DHCPv4-style reconfiguration
>
>I believe the general consensus was a desire to use the DHCPv4-style
>reconfiguration (unicast from server to client).

I agree.

>  However, there is also a
>desire to accommondate multicasting as for major network reconfiguration
>events, unicasting may inefficient (if there are 1000's of clients to
>notify). But multicasting opens up significant security issues.

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.

We can always add multicast later...

- Ralph

---

From: Jim Bound <[email-masked]>
Date: Fri, 15 Sep 2000 16:39:31 -0400

>>reconfiguration (unicast from server to client).

But we did not discuss pro's and con's in the design meeting or have
rigorous debate and we don't have consensus on the mailing list yet.
Consensus was achieved without any discussion as that was the mind set for
the design meeting.

I also believe we MUST support multicast for existing IPv6 deployment
and for Dynamic Renumbering with DHCPv6.  Otherwise we have not done the
basics.

>a significant issue for multicast.

I don't agree.  It is far more efficient to send a multicast from a
server than 1000 unicast messages that is why IPv6 bases much of its
protocol on multicast.  

Can you state why you think it is difficult for implementation to do
this I don't think it is.

>We can always add multicast later...

But we need Multicast now, today.

I would like to hear what others think too?

regards,
/jim

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Sep 2000 14:24:34 -0700

> But we need Multicast now, today.

On an intuitive level I agree with you on this, Jim.   I don't
understand what the objection is to multicast.   Can someone concisely
summarize what the problems are with implementing multicast
reconfigure?

Thanks!

			       _MelloN_

---

From: "Ralph E. Droms" <[email-masked]>
Date: Sun, 17 Sep 2000 00:06:13 -0400 (EDT)

> summarize what the problems are with implementing multicast

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

Using multicast for Reconfigure-init, triggering clients to send a Solicit
message, only saves 1/5 of the total messages; i.e., the multicast
Reconfigure-init causes each client to initiate a four-message exchange
with the server.  If each client has a server to contact (either its
initial server or the server that generated the Reconfigure-init or some
other server specified in the Reconfigure-init message),then each client
might be able to use a two-message exchange.  In that case, multicast
would save 1/3 of the total messages.

Simple multicast does not scale well.  A multicast Reconfigure-init would
cause a flood of messages to be sent to the server.  This problem can be
ameliorated with the use of randomization on the part of clients, or by
use of different multicast addresses for different groups of clients.
Either of these solutions adds complexity to the multicast specification.

Finally, authentication is a problem.  The multicasting server must be
able to authenticate itself to all of the clients, using a single
authenticator value in the Reconfigure-init message.  I don't believe
we've addressed this problem in any of the proposals for multicast-based
reconfigure.

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Sep 2000 12:37:37 -0700

> to be in the details.  I hope this summary is both concise and precise...

Yup.   The authentication problem kills it.   Thanks for delving into
that.   Based on what you've said, I think we should scrap multicast
for now.   :'(

			       _MelloN_

---

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

>would save 1/3 of the total messages.

1/3 of bandwidth is pretty good though on a network.  But there is
another benefit besides bandwidth coservation but performance.  If an
admin must trigger an emergency renumbering event or a military
field operation wants to notify 2000 wireless clients of a parameter
then this is where Multicast is also far more efficient and will perform
far better than 2000 unicast messages.  The server can be configured
quite large with multiple interfaces and processors to handle such
returned traffic and its done today with many server applications with
such a load (not necessarily multicast).  

>Either of these solutions adds complexity to the multicast specification.

I don't believe it does not scale?  Unless you believe that multicast
does not scale as a general technology as some do?  I believe multicast
is far superior to unicast for many operations.  But the complexity I
don't see at all.  This is from dhcpv6-15 and I don't believe it to be
complex at all?

!12.4.2. Time out and retransmission of Reconfigure messages
!
!
!   The server waits RECREP_MSG_TIMEOUT milliseconds, collecting
!   Reconfigure-reply messages.  If all the expected Reconfigure-reply
!   messages are received, then the reconfigure process is successful.
!   If some or all of the expected Reconfigure-reply messages are not
!   received, then the server retransmits the Reconfigure, and doubles
!   the RECREP_MSG_TIMEOUT value, and waits again.  The server continues
!  this process until all Reconfigure-reply messages are received or
!   REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time
!  the server SHOULD abort the reconfigure process.  The server SHOULD
!   log the result of the reconfigure process.
!
!
!   Default and initial values for RECREP_MSG_TIMEOUT and
!   REC_MSG_ATTEMPTS are documented in section 3.5.

>we've addressed this problem in any of the proposals for multicast-based

Reconfigure only works if the client has a global address.
In that case IPsec can be used with a generic Authentication key for
reconfigure each client can have for this purpose.

We can also recommend that Reconfigure multicast should only be used on 
an Intranet until security ramifications across the Internet are better
understood.

regards,
/jim

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Mon, 18 Sep 2000 06:23:25 -0400

At 10:23 PM 9/17/00 -0400, Jim Bound wrote:

>1/3 of bandwidth is pretty good though on a network.

The computer scientist in me says 1/3 is only a constant factor and doesn't 
contribute to scalability...

>does not scale as a general technology as some do?

I would hesitate to apply the observation that "multicast scales as a 
general technology" to this specific case without working through the 
details.  I think there is question about whether reliable multicast scales...

As to the complexity of multicast reconfigure, I still believe the devil is 
in the details.  The text you cited in 12.4.2, for example, does not 
address the question of how a client responds to a retransmitted 
reconfigure message.  Does the client try to detect retransmitted 
reconfigure messages?  If so, does the client respond only to the first 
reconfigure message and ignore retransmitted reconfigure messages?  Suppose 
the client's reconfigure-reply message is lost - how does the client know 
that it should respond to a retransmitted reconfigure message?

These problems could be solved with a mixed multicast/unicast strategy - 
multicast the first reconfigure message and unicast any retransmitted 
reconfigure messages.  For this to work, the client behavior should, I 
think, be specified to be "respond to every reconfigure regardless of 
whether it has been retransmitted".

- Ralph

---

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

>contribute to scalability...

OK.  Sounds like discussion over a beverage but I see your point.

>details.  I think there is question about whether reliable multicast scales...

OK.  As a comment I am convinced multicast is good and the whole world
should be using it and I even read Steve Deering's Phd Thesis while
drinking good wine :----)...

>that it should respond to a retransmitted reconfigure message?

Yep.  The scenarios we used to have got dropped in the last draft.

The client should only respond to the first multicast for X time then we
have to let them respond again when X ends.  This will provide some
scalability for the reconfigure-init. 

>whether it has been retransmitted".

That would work and quite elegant really (nice idea).  It also
eliminates what I said above.  It also addresses my main reason for the
feature to tell clients to listen up in real network emergency type
situation or serious changes need to be done site or Intranet wide.

My fear on this one is if we don't put it in now I fear it will never
get in too.

regards,
/jim

---

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.

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

> 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