Subject: [dhcwg] RFC3633: REBIND/REPLY after the link has flapped

From: Dedecker Hans <[email-masked]>
Date: Mon, 25 Oct 2010 16:56:43 +0200

Hi all,

I need clarification regarding RFC3633 chapter 12.1 which states the following :
In some circumstances the requesting router may need verification
   that the delegating router still has a valid binding for the
   requesting router.  Examples of times when a requesting router may
   ask for such verification include:

   o  The requesting router reboots.

   o  The requesting router's upstream link flaps.

   o  The requesting router is physically disconnected from a wired
      connection.

Troan & Droms               Standards Track                    [Page 12]
RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003

   If such verification is needed the requesting router MUST initiate a
   Rebind/Reply message exchange as described in section 18.1.4,
   "Creation and Transmission of Rebind Messages" of RFC 3315, with the
   exception that the retransmission parameters should be set as for the
   Confirm message, described in section 18.1.2, "Creation and
   Transmission of Confirm Messages" of RFC 3315.  The requesting router
   includes any IA_PDs, along with prefixes associated with those IA_PDs
   in its Rebind message.

In the paragraph above a reference is made to RFC3315 section 18.1.4 and section 18.1.2 regarding the retransmission parameters.
RFC3315 section 18.1.4 states the following :
At time T2 for an IA (which will only be reached if the server to
   which the Renew message was sent at time T1 has not responded), the
   client initiates a Rebind/Reply message exchange with any available
   server.  The client includes an IA option with all addresses
   currently assigned to the IA in its Rebind message.

As RFC3633 states that the DHCPv6 client has to start a REBIND/REPLY message exchange and reading RFC3315 paragraph 18.1.4 it's not clear to me if the DHCPv6 client can immediately start a REBIND/REPLY message exchange after the upstream link has flapped or it has to wait for a time T2 before it starts sending the REBIND/REPLY message exchange in this case.
If the DHCPv6 client has to wait for a time T2 it can take days/months depending on the value of T2 before prefix delegation confirmation is received from the DHCPv6 server which is not an ideal situation.
As RFC3633 does not state explicitly that the DHCPv6 client can start immediately a REBIND/REPLY message exchange after the link has flapped it's open for interpretation ....

Thanks,
Hans

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 25 Oct 2010 20:52:55 -0500

Yes, the REBIND can be sent immediately, you would NOT wait until T2 as
the client needs to determine if the prefix is still valid. (Whether you
add a short random delay before sending the REBIND is probably the more
interesting question and I would recommend that this is done just in
case whatever caused the event took down other nodes that might be
connected through the same DHCP server - that way, the server isn't
slammed all at once).

-          Bernie

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dedecker Hans
Sent: Monday, October 25, 2010 10:57 AM
To: [email-masked]
Subject: [dhcwg] RFC3633: REBIND/REPLY after the link has flapped

Hi all,

I need clarification regarding RFC3633 chapter 12.1 which states the
following :

      connection.

   in its Rebind message.

In the paragraph above a reference is made to RFC3315 section 18.1.4 and
section 18.1.2 regarding the retransmission parameters.

As RFC3633 states that the DHCPv6 client has to start a REBIND/REPLY
message exchange and reading RFC3315 paragraph 18.1.4 it's not clear to
me if the DHCPv6 client can immediately start a REBIND/REPLY message
exchange after the upstream link has flapped or it has to wait for a
time T2 before it starts sending the REBIND/REPLY message exchange in
this case.

If the DHCPv6 client has to wait for a time T2 it can take days/months
depending on the value of T2 before prefix delegation confirmation is
received from the DHCPv6 server which is not an ideal situation.

As RFC3633 does not state explicitly that the DHCPv6 client can start
immediately a REBIND/REPLY message exchange after the link has flapped
it's open for interpretation ....

Thanks,

Hans