Subject: Re: [dhcwg] Re: PD lifetimes

From: Erik Nordmark <[email-masked]>
Date: Mon, 3 Feb 2003 21:45:55 +0100 (CET)

> Yes, *if we want to allow the delegating router to have the ability to
> control the downstream valid and preferred lifetimes*. 

I agree that this "if" is a key question.

But what I don't understand is the semantics of any lifetime
if we decide that the delegating DHCP server should not be able to
control the prefix lifetimes, then what is the purpose of having any
lifetime in the prefix delegation option? Wouldn't it be sufficient to
just have T1/T2 in that case?

> Before going that further, however, I still think it is overkilling
> for the delegating router to have the ability to control the
> downstream lifetimes.  IMO, the requesting router (and the site's
> administrator) should be responsible for such parameters, with one
> trivial constraint: the site lifetimes must not be smaller than the
> lifetimes of each downstream link.

Yes, but the counter argument is for home sites that don't have
an administrator it might make sense to allow the ISP to be able to suggest
or control the lifetimes. Of course, managed sites might be able to override
the lifetimes.

>   1. the requesting router should also have the additional bits (like
>      P and V above),
>   2. (this may be controversial) the lifetimes in router advertisement
>      on each downstream link should be the same as the default of RFC
>      2461 (i.e. AdvValidLifetime and AdvPreferredLifetime, NOT
>      decreasing in real time), as long as Renew/Reply exchanges
>      succeed, and

If you add the P and V bits, then wouldn't the decrement behavior be
controlled by those bits?

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.

>   3. in any case, the valid lifetime of a prefix delegated by PD must
>      not be smaller than the valid lifetime in router advertisements
>      on any downstream link.

I don't understand this point. Did you inverse it?
Are you saying that the RA lifetimes must not exceed the PD lifetimes
that the router received?

   Erik

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 04 Feb 2003 16:46:11 +0900

>>>>> On Mon, 3 Feb 2003 21:45:55 +0100 (CET), 
>>>>> Erik Nordmark <[email-masked]> said:

> just have T1/T2 in that case?

It is, unless we do not want to control per-prefix lifetime in a
single IA_PD.  (If we remove the notion of per-prefix lifetime, then
we'd clarify the maximum retransmission duration (MRD) of Rebind for
IA_PD accordingly).

> or control the lifetimes. Of course, managed sites might be able to override

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.  

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.

Thus, if we introduce the lifetime parameters as a kind of optional
information for ISP to specify the lifetimes, we need to clarify which
parameters are essential and which ones are optional.

> 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.

> 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?

> that the router received?

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.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ole Troan <[email-masked]>
Date: Tue, 04 Feb 2003 23:17:36 +0000

> I have several comments about lifetimes of prefix delegation (PD).  In
> this message, I'm talking about
> draft-ietf-dhc-dhcpv6-opt-prefix-delegation-01.txt.
>
> 0. (I once discussed this point privately, but I could not help
>    raising this again.  Please forgive me for this repetition.)
>
> I cannot understand the reason why the prefix has the notion of
> the preferred lifetime, whose role is not clear.  The role of the
> valid lifetime is very clear; the period that the delegated site can
> use the prefix.  However, the preferred lifetime only controls a loose
> relationship with the preferred lifetime in router advertisements
> within the site, and roughly controls the T1/T2 values.
>
> It would be much simpler to have a single "lifetime" only, which
> controls T1 and T2, and loosely affects the RA lifetimes.

I believe this was brought up during the DHC meeting in Yokohama. the
main argument (coming from Thomas I think) for including the preferred
lifetime was to simplify renumbering. it also allows for more granular
control if PD is used in other contexts than the one specified in the
draft.

the draft specifies how a prefix is delegated but has intentionally
left unspecified (apart from suggesting some defaults) how it is to be
used within the site. the only requirement is that the valid lifetime
is adhered to, anything else can be configured in any way the local
administrator (if there is one) wants.

> In the following comments, however, I'll assume the current valid +
> preferred scheme.
>
> 1. Section 9 says
>
>      In a message sent by a delegating router the preferred and valid
>      lifetimes should be set to the values specified in section "Router
>      Configuration Variables" of RFC2461 [3], unless administratively
>      configured.
>
> Technically, the wording 'values specified in section "Router
> Configuration Variables"' is not clear, because the router
> configuration variables of RFC 2461 do not contain the valid and
> preferred lifetimes.  The intended variables should probably be
> AdvValidLifetime and AdvPreferredLifetime, respectively.  Even so,
> however, I still suspect these are appropriate values.
> AdvXXXLifetimes are for each end host (in a site), but the lifetimes
> given by PD affect the entire site.  In general (and IMO), the latter
> should be larger than the former.

section 6.2.1 of RFC2461 does indeed include AdvValidLifetime and
AdvPreferredLifetime, so I'm not sure what is not clear.

> Today, on typical IPv6 links, we see fixed values of the valid and
> preferred lifetimes in Router Advertisements, i.e., AdvValidLifetime
> and AdvPreferredLifetime.  However, according to the default values of
> the PD lifetimes and to the specified relationship between the PD
> lifetimes and RA lifetimes described in the last paragraph of Section
> 11.1, it is highly possible to see smaller RA lifetimes than the
> current typical cases.  Moreover, if the requesting router simply uses
> the PD valid (or preferred) lifetime for the RA valid (or preferred)
> lifetime, we'll see the RA lifetime being decremented.
>
> I believe the default values of PD lifetimes should keep the default
> values of RA lifetimes in the typical configuration.  Thus, I would
> recommend the following values:
>
> The default value for the PD preferred lifetime is
> (5 / 4) * AdvPreferredLifetime.
> The default value for the PD valid lifetime can be an arbitrary value,
> but should not be smaller than AdvValidLifetime + PD preferred lifetime.
>
> The rationale of the default is that we won't see "abnormal" RA
> lifetimes unless the requesting router fails renew/reply exchanges and
> starts rebinding, assuming that "T2" for the prefix is (equal to or
> smaller than) the PD preferred lifetime * 0.8.

I don't see decrementing lifetimes in RA's as abnormal, nor do I see
the benefit of advertising fixed values in RA's. there is nothing
prohibiting an requesting router implementation to use fixed values,
as long as it behaves correctly when the PD valid lifetime < RA
lifetime.

> 2. Section 9 also says
>
>    In a message sent by a delegating router to a requesting router, the
>    requesting router MUST use the value in the valid lifetime field and
>    MAY use the value in the preferred lifetime field.
>
> This sentence is not clear to me.  Where and how does the requesting
> router "use" the lifetimes?  This ambiguity also makes the term "MUST"
> and "MAY" unclear.  Perhaps the sentence intends to specify the
> relationship between RA lifetimes and PD lifetimes described in
> Section 11.1, but I cannot be sure without any reference.

agree, should be clarified.

/ot

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 05 Feb 2003 18:00:07 +0900

>>>>> On Tue, 04 Feb 2003 23:17:36 +0000, 
>>>>> Ole Troan <[email-masked]> said:

>> raising this again.  Please forgive me for this repetition.)

(snip)

> control if PD is used in other contexts than the one specified in the

Okay, according to the discussion in this thread, it seems that I'm in
the minority on this.  So, I'm okay to keep the preferred lifetime in
the PD specification.

> administrator (if there is one) wants.

As I said in a separate message, this approach treats the preferred
lifetime as (a kind of) optional information, while the preferred
lifetime takes an essential role in address assignment.  In the PD
spec, the valid and preferred lifetimes are sometimes essential and
sometimes informational, which make me confused:

- the PD valid lifetime specifies the "lease duration" of the site
  prefix.  (this is essential)
- the PD valid lifetime also specifies the upper bound of the RA valid
  lifetime.  (this is a bit strong, but still informational)
- the PD preferred lifetime controls the (recommended) default values
  of T1 and T2.  (this is essential)
- the PD preferred lifetime specifies a suggestion of the RA preferred
  lifetime.  (this is informational)

Thus, it would most make sense to me if the essential and
informational parts are clearly separated.  For example,

- we have three parameters for a prefix; lease duration, valid
  lifetime, and preferred lifetime.  we also have T1 and T2 for an IA_PD.
- the lease duration is an essential information, which specifies the
  "lifetime of the site prefix" and must be specified in Reply
  messages.  It also controls the default value of T1 and T2.
- the valid and preferred lifetimes are informational, which may or
  may not be (concretely) specified in Reply messages.  If specified,
  those values mean the suggested values of the RA lifetimes.
- there are of course some trivial relationship between the
  parameters.  For instance, the valid and preferred lifetimes must
  not be larger than the lease duration.

(we may need additional bits for the valid and preferred lifetimes as
Erik suggested, but I omitted the additional bits here for simplicity.)

Doesn't this make much sense?

> AdvPreferredLifetime, so I'm not sure what is not clear.

My point is that the text should be like this:

  In a message sent by a delegating router the preferred and valid
  lifetimes should be set to AdvValidLifetime and
  AdvPreferredLifetime, respectively, as specified in section "Router
  Configuration Variables" of RFC2461 [3], unless administratively
  configured.

(though I'd like larger default value as I said below.)

>> recommend the following values:

(snip)

> as long as it behaves correctly when the PD valid lifetime < RA

Regarding this point, please refer to the succeeding discussion in
this thread.  However, if we clarified the essential and informational
parameters (see above), this part might not be an issue.

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 5 Feb 2003 14:56:15 +0100 (CET)

> 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.

> value meaning "any" for the lifetimes in DHCPv6 messages from the

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.

> off (not decrementing) by default.

Agreed.

> before?  600 and 100 secs, considering the period we have spent?  Or

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.

> 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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 06 Feb 2003 02:21:54 +0900

>>>>> On Wed, 5 Feb 2003 14:56:15 +0100 (CET), 

> using PD you need (optional) valid and preferred lifetimes per prefix.

As I replied to Ole, I'm now okay to have the preferred lifetime in

> assignment, using a longer lifetime than the server provided is risky.

Absolutely.  I did not say that the client (requesting router) should
be able to use longer RA lifetimes than the server (delegating router)
provided.  Perhaps my point is clearer in a related message in
response to Ole (attached below).

> used for 1000+400 secs after it handed it out.

But doesn't this change the semantics of the Valid lifetime?  Are you
saying the real "lease duration" should be valid lifetime plus T2 (if
so, what if T2 is 0, which specifies the client to choose the value)?

> That fits what I called "alternatively" above, and in that case you don't

The restriction above is not that strict.  The client can use a fixed
RA valid lifetime which is much smaller than the PD valid lifetime.
This is because I prefer a larger default value for the PD valid
lifetime.

					JINMEI, Tatuya

Subject: Re: [dhcwg] Re: PD lifetimes
From: JINMEI Tatuya / 神明達哉<[email-masked]>
To: Ole Troan <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Wed, 05 Feb 2003 18:00:07 +0900

(snip)

(snip)

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 6 Feb 2003 19:53:48 +0100 (CET)

> This is because I prefer a larger default value for the PD valid

Ah - sorry for not understanding that the first time around.

That makes sense. Means we don't need P and V flags, right?

And the document could say that if the PD lifetimes exceed the RFC 2461
defaults the router should use those defaults, otherwise it should use the PD
lifetimes and decrement them in real time.

  Erik