Subject: [Dhcpv6bis] [dhcpv6bis] #131 (XML 3315): Confusion on T1/T2 times (option values vs client renew/rebind triggers)

From: "dhcpv6bis issue tracker" <[email-masked]>
Date: Tue, 23 Dec 2014 20:50:19 -0000

#131: Confusion on T1/T2 times (option values vs client renew/rebind triggers)

 In the WGLC for draft-ietf-dhc-dhcpv6-stateful-issues-09, it is apparent
 that there is some confusion as to T1/T2 times in RFC 3315.

 In my opinion there are really two sets of values. One is the T1/T2 values
 returned in the IA_NA and IA_PD options from a server. These values are
 used to generate T1/T2 values (times?) when a client will initiate a Renew
 or Rebind.  See ticket #71 regarding 0 times received from a server (but 0
 values would not be used by the client).

 When a client processes a Reply which provides IAs, it would determine the
 proper T1/T2 (either for a particular IA or for the 'renewal' of all
 bindings - per the stateful issues work). The T1/T2 used for
 renewal/rebinding processing are probably "times" (absolute - renew at
 10:36 on Jan 6, 2015 for example) and not relative values (as is the case
 for the T1/T2 fields in the IA_NA/IA_PD options).

 Anyway, we may want to look at clarify things some in RFC 3315bis. (That
 way, the Renew/Rebind text can avoid having to reference the T1/T2 times
 received in IA options from a server and can just say at the determined
 renewal/rebind time).

 Note also that the Infinity value is allowed for T1/T2 times and perhaps a
 server that will not renew a binding may want to make use of those (or the
 valid lifetime)? Some way to tell the client not to renew might be useful?

 One situation to consider is a renumbering situation where a client has an
 existing address on Prefix A and is given a second address on Prefix B.
 Prefix A's address will not be renewed (or not renewed at some point). The
 server would generally base the T1/T2 times on the Prefix B address
 lifetimes and not on Prefix A in this case. So, a client would obviously
 not want to determine something different using Prefix A lifetimes.

 One nasty situation would be as the remaining lifetimes on Prefix A's
 address get shorter and shorter to have more and more renewals!!

 Of course, not all servers may support this kind of configuration
 (especially as renumbering seems less likely these days).

-- 
----------------------------+----------------------------------
 Reporter:  [email-masked]  |      Owner:
     Type:  task            |     Status:  new
 Priority:  P1 blocker      |  Milestone:  C awaiting consensus
Component:  XML 3315        |   Keywords:
 Due Date:                  |
----------------------------+----------------------------------

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