Subject: Re: [Dhcpv6bis] [dhcpv6bis] #114 (XML 3315): Clarify what 'hints' means?

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Mon, 29 Jun 2015 01:46:58 -0000

#114: Clarify what 'hints' means?

Comment (by [email-masked]):

 From: tianxiang li [mailto:[email-masked]]
 Sent: Monday, June 08, 2015 11:36 PM
 To: Bernie Volz (volz)
 Subject: suggestions on DHCPv6 hint issue ticket#114

 Dear Bernie:

 I have some suggestions regarding the hint issue you mentioned in 3315bis
 ticket#114, I hope it helps.
 (http://trac.tools.ietf.org/group/dhcpv6bis/ticket/114)

 1) if a server already has addresses from previous interactions with the
 client that don't match those requested in a Solicit, should the server
 discard what it had in favor of the requested ones?

 The server should try to honor what the client is requesting in the
 Solicit despite having addresses from previous interactions with the
 client, as it is what the client prefers to have at the time being. This
 is usually after client reboot or reconfiguration, where the client
 prefers addresses different from before. For prefix delegation, if a
 client is requesting a /60 in the Solicit, the server should try to honor
 this hint, even though it provided the client with a /64 during previous
 interactions.

 If the client has already been allocated a /64 and suddenly requires a /60
 due to configuration changes, then it should send a Solicit with different
 IAID requesting for the /60. If the client is able to get a /60 right
 away, then it should stop using the /64 afterwards. If the client is not
 able to get the /60, then it should continue using the /64, while
 Soliciting for the /60.

 This is the case when the client configuration changes and requires a
 different prefix.

 2) If a client wanted a /60 but got a /64, how does server know 'later'
 that the client still would prefer a /60? On a Solicit/... this is clear
 because client will just include the prefix hint with /60. But on a Renew
 or Rebind, should the client include the /60 hint?

 If the client requested a /60 but got a /64, then during Renew/Rebind, the
 client should request for the /60 while extending the lifetime of the /64.
 The client could include two IA_PD options in the Renew message, one with
 the currently delegated /64 prefix as the hint, and the other with the
 newly requested /60 prefix length as the hint.

 If the server is able to provide the /60 due to server configuration
 changes or because another client stops using it, then it should provide
 the /60 to the client, while giving the /64 a shorter lifetime. This way,
 the client won’t have to deprecate the /64 right away. If the server is
 still unable to provide the client with a /60 during Renew then it should
 just extend the lifetime of the /64.

 This is the case when the server configuration changes and is able to
 provide the requested prefix during later interactions with the client.

 3) If client sends a hint for a /60 but server can only provide a /64.
 Now, client sends RENEWs and it if only send /64, should server have
 remembered it originally requested a /60 to potentially assign it a new
 prefix if it should become available? Perhaps the guideline here is that
 servers MAY want to remember the received hint and POSSIBLY re-evaluate
 what they are providing the client?

 I don’t think it’s necessary for the server to remember what the client
 requested before. The client should remember the hint it sent before, and
 continue requesting for the hint during Renew if it was not honored by the
 server during Solicit.

-- 
----------------------------+--------------------------------------------
 Reporter:  [email-masked]  |       Owner:  [email-masked]
     Type:  task            |      Status:  new
 Priority:  P1 blocker      |   Milestone:  B moderate, apply after merge
Component:  XML 3315        |  Resolution:
 Keywords:                  |    Due Date:
----------------------------+--------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/group/dhcpv6bis/ticket/114#comment:6>
dhcpv6bis <http://tools.ietf.org/group/dhcpv6bis/>