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

From: Bernie Volz <[email-masked]>
Date: Fri, 1 Sep 2000 09:51:55 -0400

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

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

Let's start the discussion. As we did not set a deadline at the conference
call, other than stating a week, and given the Labor Day holiday, I'd like
to conclude this discussion by end of day Friday, September 8.

- Bernie Volz
  IPWorks, Inc.

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 00:56:25 -0400

Bernie,

>    same thing could also go for Reconfigure-init to some extent.

Not a problem for reconfigure-init either.

But more important question.  

#1 Did the reconfigurexxxx come initially from the server?  
#2 Or can the relay send this without any prodding by the server?

I think net admins I know running DHCPv4 would not be happy having to
manage relays to do reconfigures at all.  So I question #2 is useful to
the market.

Also for #2 the server has no way of identifying the trans ID for 
reconfigure to know a client responded and we don't want the relay doing
this as then it must keep state.

>    find a DHCP server with can allocate addresses on the new subnet?

As long as the client uses the reconfigure trans-id from the reconfigure
init.  But if the client has a globally reachable address (or of
sufficient scope) this is uncessary as I see it.  

Can you expound on why allocating a new subnet?  I would not think the
server reconfigure-init should reach the client if it could not do this?

>18. Simplify reconfiguration; Use DHCPv4-style reconfiguration

Why is DHCPv4-Style more simple?  Can you expound on what the changes
would be for the list from what is done in DHCPv6 at this point to how
it would look as dhcpv4 does it?  

For example I think we need the archtype of reconfigure and
reconfigure-init as a architectural model.  reconfigure for mobile nodes
as optimization and reconfigure-init for general purpose which is
similar to dhcpv4 reconfigure option.

>notify). But multicasting opens up significant security issues.

We cannot not assume multicast for reconfigure in IPv6.  We may want
health warnings.  But I need to hear on the list what does this all mean
from your perspective comparing the two so we can have that discussion
to reach resolution.

>to conclude this discussion by end of day Friday, September 8.

I don't think that will happen we have to have some discussion on this
one.

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Thu, 07 Sep 2000 23:44:07 -0400

Hi Bernie,

I have been thinking about this a lot and know very well what is needed
for IPv6 deployment.

I think we MUST permit Reconfigure and Reconfigure-Init with Multicast
to support site renumbering operations where stateless address
configuration is not used by the site.  It will permit a dhcpv6 server
to tell clients come get your new prefix NOW.  And in the response begin
the deprecation of old addresses.    

regards,
/jim