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

From: Ralph Droms <[email-masked]>
Date: Tue, 10 Oct 2000 17:08:46 -0400

Issue: We raised several issues in the area of reconfiguration.  My notes 
are a little unclear about where we had agreement during the design team 
phone call.  In any event, let me try to summarize what I've been able to 
extract from the mailing list discussion:

YES     18. Simplify reconfiguration; Use DHCPv4-style reconfiguration

My notes from the phone call show agreement during the phone call for 
incorporating DHCPv4-style reconfiguration in DHCpv6.  There was one 
dissenting opinion during the mailing list discussion.  I read consensus as 
incorporating DHCPv4-style reconfiguration as a baseline, with the 
possibility of including additional functions such as use of multicast.

         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?

I didn't see much discussion of these two items and I don't see that we 
have consensus on resolution.

BERNIE  -  Implement multicast reconfigure?

I read consensus for support of multicast reconfigure.

TBD: Consensus on issues 8 and 9; detailed design for multicast reconfigure.

---

From: Jim Bound <[email-masked]>
Date: Tue, 10 Oct 2000 23:20:56 -0400

can someone from dhcpv4 folks compare/contrast dhcpv4 reconfigure with
reconfigure-init?

Also is dhcpv4 using ERE as dhcpv6 reconfigure-init?

thanks
/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 16 Oct 2000 00:37:24 -0400

>From Jim Bound

I went and did this myself.

draft-ietf-dhc-pv4-reconfigure-01.txt

The FORCERENEW is on the surface like the DHCPRECONFIGURE-INIT except the
dhcpv6 one permits multicast which I think we should in some form.

But there is now ERE concept with DHCPRECONFIGURE-INIT too.

Also it appears to me the core design purpose is a bit different and
goals.  The FORCERENEW is basically to tell the client to come get a new
lease.  The DHCPCONFIGURE-INT also can provide a hint to the client via the
ERE come get ERE:X. Where X is an extension type.  

Also FORCERENEW forces the client into the RENEW state.  In DHCPv6 we
don't have states but in our case the DHCPRECONFIGURE-INIT may not be telling
the client to RENEW or to do a DHCPREQUEST with IA and Address
Extension.

It could be come get a new TCP_KEEPALIVE, or POSIX-TIMEZONE variable, or
DNS SERVER record.  Or as we are working in ngtrans right now come get a
new IPv4-Mapped address for the Dual Stack Transition Method (DSTM).
http://ietf.org/internet-drafts/draft-ietf-ngtrans-dstm-02.txt
The actual format for the ERE and Extension is defined above.

I would like to hear from folks on the above as I think we are in
agreement we need DHCPRECONFIGURE-INIT but the issue is DHCPRECONFIGURE
and DHCPRECONFIGUREREPLY?   I feel the ERE mechanism for DHCPRECONFIGURE-INIT
is very important to IPv6 and I would like to hear why anyone thinks it
is not or if you agree with me.

regards,
/jim