[dhcwg] draft-troan-dhc-dhcpv6-stateful-issues-00

["Bernie Volz (volz)" <[e-mail]>]

Ole submitted the draft-troan-dhc-dhcpv6-stateful-issues-00 draft just
before the Paris IETF DHC WG meeting and I presented the
http://www.ietf.org/proceedings/83/slides/slides-83-dhc-15.pdf slides at
that meeting.

 

Please look over the draft and slides as we are hoping to fast-track
these RFC 3315/3633 changes for the RFC 6204bis work.

 

In thinking about this some more since, I believe that encouraging use
of Renew (section 3.4 and "Confirm / Renew Handling" slide) is not the
best. This "Renew" was to follow the RFC 3633 (section 12.1)
requirements:

 

   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.

 

>From RFC 3315:

 

   The first Confirm message from the client on the interface MUST be

   delayed by a random amount of time between 0 and CNF_MAX_DELAY.  The

   client transmits the message according to section 14, using the

   following parameters:

 

      IRT   CNF_TIMEOUT

 

      MRT   CNF_MAX_RT

 

      MRC   0

 

      MRD   CNF_MAX_RD

 

   CNF_MAX_DELAY     1 sec   Max delay of first Confirm

   CNF_TIMEOUT       1 sec   Initial Confirm timeout

   CNF_MAX_RT        4 secs  Max Confirm timeout

   CNF_MAX_RD       10 secs  Max Confirm duration

 

Renew is effectively "unicast" to the server that granted the lease(s).
Thus:

1.       If the client has indeed moved to a new location, or

2.       If the client has not moved, but that server is down,

The client must always wait 10 seconds (CNF_MAX_RD) before transitioning
to sending Rebinds before it can hope to get any feedback (if there is
another server present). In many cases, perhaps other information (such
as receipt of RAs) might already indicate to the client whether it has
likely moved or not?

 

In these cases either using the Confirm or immediately starting with a
Rebind has a 10 second advantage.

 

Note also that Confirm has the other advantages outlined in the
presentation:

1.       It is clear what the client is attempting to do as it doesn't
overload the Renew/Rebind requests.

2.       It has significant less load on the server since the server
does not need to (potentially) extend lifetimes or otherwise record
anything about the client/server interaction with respect to these
leases (which eliminates any possibility of a write by the server which
is generally expensive - especially in a situation where lots of clients
might be doing this).

The one disadvantage to Confirm is that it provides no useful
information to any Relay Agent (CMTS in particular) that might be
wanting to gleam information from the transaction. There may also be
situations where the Confirm, if used, can't determine if the client has
or has not moved in which case the client will get no response to its
Confirm - RFC 3315, Section 18.1.2 then states the client SHOULD
continue to use the previously obtained information.

 

So what do others think? Do we not consider the 10 second delay to be
significant and worth addressing? Do we consider the additional server
cost of doing Renew/Rebind processing an issue?

 

-          Bernie