Subject: [dhcwg] PD lifetimes

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 23 Jan 2003 19:18:57 +0900

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.

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.

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.

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.

					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: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2003 20:15:10 -0500

0. The preferred lifetime is there for the case in which the DR and RR have 
agreed to let the DR control the lifetimes on the links downstream from the RR.

1. In response to your first comment, suppose we change the paragraph in 
question to:

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

If I understand your second comment correctly, following the PD spec will 
result in the valid lifetimes in the RAs on the downstream links from the 
RR grow smaller over time, so as not to exceed the valid lifetime for the 
prefix in the IA_PD, until the RR sends a Renew to extend the valid 
lifetime on the prefix.  Did I get that right?  Is this situation a problem 
for the hosts on the downstream links and should we try to fix the problem?

2. Proposed clarification for the sentence in question:

    The requesting router MUST select the value of AdvValidLifetime
    assigned to any prefixes subnetted from a delegated prefix to be
    less than the preferred lifetime in the prefix option for that
    delegated prefix.  The requesting router MAY use the preferred
    lifetime in the prefix option for a delegated prefix as the value
    of AdvPreferredLifetime for a prefix subnetted from that delegated
    prefix, if the requesting router chooses to allow the delegating
    router to control that value.  Otherwise, the requesting router
    chooses a value of AdvPreferredLifetime for the subnetted prefix
    that is less than the value of AdvValidLifetime for that prefix.

- Ralph

At 07:18 PM 1/23/2003 +0900, JINMEI Tatuya /

---

From: Jun Xie <[email-masked]>
Date: Thu, 23 Jan 2003 20:09:07 -0800

At 08:15 PM 1/23/03 -0500, Ralph Droms wrote:
[...]
>    less than the preferred lifetime in the prefix option for that
                          ^^^^^^^^^^^^^^^
I think you mean valid lifetime here?

-Jun

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Jan 2003 23:40:05 -0500

Yes ... thanks!

- Ralph

---

From: Erik Nordmark <[email-masked]>
Date: Sat, 25 Jan 2003 06:46:26 +0100 (CET)

> agreed to let the DR control the lifetimes on the links downstream from the

But there are two possible uses of this that need slightly
different behavior:
1. The DHCP server is suggesting that the RAs sent by the router have a valid
   and preferred lifetime of X and Y respectively, that do not decrement over
   time. 
   This is a useful mode when no renumbering is imminent but you want to
   control the lifetimes so that you know how quickly you can renumber.

2. The DHCP server is in the process of renumbering the site thus it
   it telling the router to send RAs with lifetimes that decrement over time
   so that they will reach zero X and Y seconds, respectively, after the DHCP
   reply was sent from the server.
   This is useful when renumbering is in progress - a new prefix has been
   introduced and the old prefix is counting down its lifetime.

Note that RFC 2461 has this ability in its conceptual router variables
e.g.
                        AdvValidLifetime
                             The value to be placed in the Valid
                             Lifetime in the Prefix Information
                             option, in seconds.  The designated value
                             of all 1's (0xffffffff) represents
                             infinity.  Implementations MUST allow
                             AdvValidLifetime to be specified in two
                             ways:

                               - a time that decrements in real time,
                                 that is, one that will result in a
                                 Lifetime of zero at the specified
                                 time in the future, or

                               - a fixed time that stays the same in
                                 consecutive advertisements.
and similar text for AdvPreferredLifetime.

Presumably the PD draft could do this as well by having a bit (or two)
indicating wheter the lifetime(s) should decrement in real time or be
constant.

Would that make sense?

  Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 26 Jan 2003 17:40:08 +0900

>>>>> On Thu, 23 Jan 2003 20:15:10 -0500, 
>>>>> Ralph Droms <[email-masked]> said:

> lifetime on the prefix.  Did I get that right?

Yes.

> Is this situation a problem 

Honestly, this won't be a "problem" in practice, since
AdvValidLifetime and AdvPreferredLifetime are large enough.  In
theory, however, the current default lifetimes specified in the PD
draft changes the condition about stability of prefix lifetimes for
downstream hosts.  

According to the default values of RFC 2461, an autoconfigured address
for a host is valid unless the host misses router advertisements for
AdvValidLifetime (I ignore the advertisement interval for simplicity).
According to the current PD spec, however, a host can receive a prefix
with the valid lifetime being L = (AdvValidLifetime - .5 *
AdvPreferredLifetime).  Thus, if the host misses succeeding router
advertisements for L seconds, the corresponding address will be
invalidated, even if the renew/reply exchange between RR and DR
succeeded (and continued to succeeding).

Perhaps I'm a stickler, but I'd like to ensure the same stability from
the downstream hosts' point of view, as long as the renew/reply
exchange succeeds at the PD side.

>     less than the valid lifetime in the prefix option for that

(I corrected a typo in the citation above)

Then are you suggesting to keep the constant value of AdvValidLifetime
after receiving a Reply (to Request) and before trying a Renew/Reply
exchange?  If so, I don't think this is a good idea.  We must ensure
the invariant that the "site" valid lifetime given by PD must be equal
to or larger than the valid lifetime (in router advertisements) for
the prefix of each downstream link.

I'll switch to Erik's message for further discussion.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sun, 26 Jan 2003 18:14:39 +0900

>>>>> On Sat, 25 Jan 2003 06:46:26 +0100 (CET), 
>>>>> Erik Nordmark <[email-masked]> said:

> Would that make sense?

Yes, *if we want to allow the delegating router to have the ability to
control the downstream valid and preferred lifetimes*.  Actually, RFC
2894 (Router Renumbering for IPv6) has a similar notation:

   V           A 1-bit flag indicating that the valid lifetime of the
               New Prefix MUST be effectively decremented in real time.

   P           A 1-bit flag indicating that the preferred lifetime of
               the New Prefix MUST be effectively decremented in real
               time.
(Section 3.2.1.2)

The current PD draft implicitly assumes the (not-yet-introduced)
additional flags are on, while these bits are off in the current
typical cases.

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.

In summary,

I first would like to make a consensus if we need to allow the
requesting router to have the ability to control the downstream
lifetimes.  As I said above, I'm negative on this.

If our consensus is to allow the delegating router to have the
ability, it's okay.  Then,

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

Note that, as a consequence of 2 and 3, the default value of the valid
lifetime in a PD prefix option must be larger than AdvValidLifetime.

					JINMEI, Tatuya