Re: [dhcwg] Re: PD lifetimes

[Erik Nordmark <[e-mail]>]

> IMO, per-prefix (valid) lifetime (with T1/T2), along with some default
> rules of conversion, are enough for the ISP to suggest or control
> lifetime parameters on downstream links.  

If you only have the valid lifetime (plus T1 and T2) then it isn't
possible for the ISP to drive the renumbering since the ISP can't deprecate
a prefix - the site would have to do the deprecation by twiddling something
in the router.

Thus AFACT if you want to allow the site to delegate renumbering to the ISP
using PD you need (optional) valid and preferred lifetimes per prefix.

> Also, we need to note the difference on the role of valid/preferred
> lifetimes (in DHCPv6 messages) between the PD case and the address
> assignment case.  In the context of this current thread, the DHCPv6
> lifetimes (particularly the preferred one) are just informational
> parameters for PD.  On the other hand, the DHCPv6 lifetimes are
> essential parameters for address assignment.  In fact, there is no
> value meaning "any" for the lifetimes in DHCPv6 messages from the
> server to the client.

Maybe I'm misunderstanding but I don't see that much difference between
DHCP address assignment and prefix assignment. If the DHCP server provides
a lifetime for the allocation then after that lifetime expires (assuming
no successful renew) the address/prefix might no longer work.

This still allows the DHCP client to use a shorter lifetime for the 
address/prefix than the server stated, but, for both address and prefix
assignment, using a longer lifetime than the server provided is risky.


> > If you add the P and V bits, then wouldn't the decrement behavior be
> > controlled by those bits?
> 
> Yes.  I guess I was not clear, but I was talking about the "default"
> behavior in the bullet 2 above.  That is, the P and V bits should be
> off (not decrementing) by default.

Agreed.

> > I'm assuming that if those bits indicate that the lifetimes should not
> > decrement in real time, then we need to specify what should happen when
> > renew/reply fails. A reasonable approach would be to switch to decrementing
> > in real time at that point in time.
> 
> This might make sense, but please let me make it sure.  Suppose that
> we have been delegated a prefix P/48 with
>   valid lifetime: 1000sec
>   V: off
>   preferred lifetime: 500sec
>   P: off
>   T1: 250sec
>   T2: 400sec
> 
> Then we first advertise (say) P:1/64 on a downstream link, with fixed
> lifetime values: 1000 and 500 sec, respectively.  After 250 sec later,
> we start renew/rebind exchanges, if the exchange fails (after 400secs
> since we have been delegated), we need to start decrementing the RA
> lifetimes.  From which values should we start?  1000 and 500 secs just
> before?  600 and 100 secs, considering the period we have spent?  Or
> others?

Good question.

The 2 hour rule for stateless addrconf means that decrementing the valid
lifetime faster than real time below the 2 hour limit will be ignored
by the hosts.

Thus I think starting at 1000 and 500 secs makes sense plus documenting
that the server should be configured taking T2 into account when determining
the max time the prefix will be used.
Thus in this example  the server thought it was ok for the prefix to be
used for 1000+400 secs after it handed it out.

Alternatively, the DHCP client should always decrement the lifetimes in
real time i.e. the RAs will contain decrementing prefix lifetimes
until the renew when the lifetimes would jump back up again.

> Yes, I am (sorry if I was not clear).  To be more precise and
> concrete, suppose that we are delegated a prefix with the valid
> lifetime VL at time T.  Then if we advertise a downstream prefix (in
> an RA) at time T + n(sec), the valid lifetime in the RA must not be
> larger than VL - n, unless the delegated prefix is renewed.

That fits what I called "alternatively" above, and in that case you don't
need the P and V bits.
That might be the simplest approach. But you still need a preferred lifetime
in PD (with the same deprecating lifetime) in order to enable the case when
ISP takes care of renumbering.

  Erik

_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg