Subject: [Dhcpv6bis] [dhcpv6bis] #126 (XML 3315): What the client should do with existing bindings when it restarts the server discovery

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Wed, 22 Oct 2014 19:48:16 -0000

#126: What the client should do with existing bindings when it restarts the
server discovery

 During the review of the https://datatracker.ietf.org/doc/draft-ietf-dhc-
 dhcpv6-stateful-issues/ draft Jinmei raised a point that it is unclear
 what the server should do with existing bindings when it has moved to a
 new link and received !NotOnLink status from the server and should start
 the DHCP server discovery process.

 http://www.ietf.org/mail-archive/web/dhcwg/current/msg15974.html

 The example given in this thread is wrong, because when the client has
 both IA_NA and IA_PD it will not send a Confirm, but will use Rebind and
 include both IA_NA and IA_PD in this Rebind message. The server doesn't
 send !NotOnLink status in response to a Rebind.

 However, the point about "what the server should do with valid bindings it
 is currently using when it is supposed to, or may, restart the server
 discovery process" is still valid. This is because there are other places
 in the RFC3315 where it is indicated that client must or may restart the
 server discovery process, e.g. when the Request / Reply exchange fails or
 when the server sends !NotOnLink in response to a Request message.

 The stateful issues draft proposes that clients should keep single state
 machine and single session to manage (request, renew etc.) all bindings.
 In this case, when the client restarts the server discovery because of a
 failure in one binding, the client will need to drop all valid bindings
 and re-acquire them together with the binding for which the failure
 occurred. In this scenario, if the same server responds to client's
 Solicit, it is likely that this server will check for the existing leases
 for this client and will offer all valid leases that it currently has
 associated with the client. As a result, the client should end-up using
 the same leases, and should be able to obtain a replacement for the
 binding for which it had failed prior to Solicit. However, sending Solicit
 for the valid leases effectively means that the client stops using
 bindings which are valid. It is also possible that the server will
 allocate different addresses/prefixes than those that the client has. This
 may or may not be a problem.

 The RFC3315bis should be more specific about all this.

-- 
-------------------------------+-------------------------------------------
 Reporter:                     |      Owner:
  [email-masked]         |     Status:  new
     Type:  task               |  Milestone:  B moderate, apply after merge
 Priority:  P3 major           |   Keywords:
Component:  XML 3315           |
-------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/126>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>