Sorry for not responding sooner.
From this message, I'll separate the thread for each particular issue.
>>>>> On Fri, 28 Feb 2003 00:46:37 +0000,
>>>>> Ole Troan <[EMAIL PROTECTED]> said:
>> 1. Issues about the preferred and valid lifetimes were not fully
>> addressed. I've not seen consensus on this in the dhc-wg ML.
>> Please re-check the thread entitled "PD lifetimes" that started on
>> Thu, 23 Jan 2003 19:18:57 +0900.
> what specifically are you referring to here? in my opinion we reached
> consensus that:
> - both preferred and valid lifetimes are needed
> - prefixes or addresses derived from the prefix MUST not be used
> beyond the valid lifetime
These two are okay.
> - adding P and V bits to specify if a prefix advertised in an RA
> should use a fixed lifetime or a real time lifetime, is not needed
> as it does not seem to add value or solve any specific problem.
I'm not yet fully convinced on this, particularly about the P bit.
The motivation of having the preferred lifetime should be to allow the
delegating router to control smooth renumbering. In a renumbering
phase, the preferred (and valid) lifetime in RA at a downstream link
should be decreasing in real time. But it is not clear to me how the
preferred lifetime in RA is decreasing. The PD draft just says:
A
requesting router MAY use the preferred lifetime specified in the
IA_PD Prefix option.
(Section 11.1 of prefix-delegation-02)
What does "use" mean here? If it means the requesting router copies
the PD pltime to the RA pltime, the latter won't decrease. If this
has the same meaning as that for the valid lifetime:
the requesting router MUST
set the valid lifetime in those advertisements to be no later than
the valid lifetime specified in the IA_PD Prefix option.
(just before the sentence cited above)
why not just use the same phrase?
I also requested that the default value of the valid lifetime in a PD
prefix option be larger than AdvValidLifetime (see the "summary" part
of the message). At least I've not seen a "consensus" to reject the
request. Erik rather seemed to share my motivation according to the
discussion after the attached message below.
Furthermore, I still have a concern about the difference between the
role of prefix pltime and that of address pltime (I have repeatedly
tried to point it out, but perhaps I was not clear enough). The
former is a kind of an optional parameter, while the latter is a
mandatory one:
A
requesting router MAY use the preferred lifetime specified in the
IA_PD Prefix option.
(Section 11.1 of prefix-delegation-02)
In a message sent by a server to a
client, the client MUST use the values in the preferred and valid
lifetime fields for the preferred and valid lifetimes.
(Section 22.6. of dhc-dhcpv6-28)
Note the former uses a MAY but the latter uses a MUST.
Despite the difference on the requirement level, the PD draft has
(almost) exactly the same recommendation about the relationship
between T1/T2 and pltime as that of the DHCPv6 draft:
Recommended values for T1
and T2 are .5 and .8 times the shortest preferred lifetime of the
prefixes in the IA_PD, respectively.
(Section 8 of prefix-delegation-02)
Recommended values for T1 and T2 are .5 and .8 times the
shortest preferred lifetime of the addresses in the IA, respectively.
(Section 22.4 of dhc-dhcpv6-28)
The recommendation of DHCPv6 seems reasonable, since the client MUST
use the preferred lifetime in the IA. In the PD case, however, the
requesting router (i.e. the client) MAY "NOT" use the preferred
lifetimes in the IA_PD, which makes the recommendation less
reasonable.
Now I have a concrete proposal.
- add a special value for the PD preferred lifetime which means
the requesting router can choose the RA preferred lifetime. 0
would be a reasonable value for this.
- change the default value of the PD preferred lifetime to the
special value.
- change the requesting router behavior on the received preferred
lifetime to:
(if the preferred lifetime in IA_PD is not the special value)
the requesting router MUST
set the preferred lifetime in those advertisements to be no later than
the preferred lifetime specified in the IA_PD Prefix option.
- change the recommendation on the T1/T2 values so that they are
based on the valid lifetimes, e.g.:
Recommended values for T1
and T2 are .5 and .8 times the shortest valid lifetime of the
prefixes in the IA_PD, respectively.
- (assuming the change on the recommendation) choose the default
value of the PD valid lifetime so that the RA valid lifetime won't
decrease as long as Renew/Reply exchanges succeed. 5 times the
AdvValidLifetime would be a good candidate.
- (optional) it may also make the intention clearer if we could
change the field name of PD valid and preferred lifetimes to,
e.g., "lease-time" and "adv-preferred-lifetime", respectively.
With this proposal, the typical (default) operation will be like this:
(assuming 0 as the "special value" for the PD preferred lifetime)
- the delegating router suggests a following parameters for each
prefix:
AdvValidLifetime * 5 (150 days) as the valid lifetime
0 as the preferred lifetime
and T1/T2 be 75/120 days.
- before T2 expires, the requesting router can use any value for RA
valid lifetime not larger than 30 days (AdvValidLifetime). In
particular, it can use the constant value of AdvValidLifetime.
- similarly, the requesting router can use any value for RA
preferred lifetime not larger than RA valid lifetime until T2
expires. In particular, it can use the constant value of
AdvPreferredLifetime.
When the delegating side wants to initiate a renumbering, the
delegating router will specify a positive (but finite) value as PD
preferred lifetime. Then the succeeding RA preferred lifetime will
decrement in real time.
I strongly believe the proposed change makes the specification clearer
in terms of the intended usage of PD (comparing to that of address
assignment). Also, the proposed change does not require a large
change on the actual behavior on the current draft; it just changes
the default value of the lifetime field, and introduces a minor change
about the relationship between PD lifetimes and RA lifetimes. Thus, I
don't think the change affects early implementations much.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--- Begin Message ---
>>>>> On Sat, 25 Jan 2003 06:46:26 +0100 (CET),
>>>>> Erik Nordmark <[EMAIL PROTECTED]> said:
> 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?
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
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
_______________________________________________
dhcwg mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/dhcwg
--- End Message ---
