Hello,
I have a comment on issue 246 of rfc2461bis (preferred lifetime >
valid lifetime).
As far as I can see, the latest version of the draft
draft-soliman-ipv6-2461-bis-01.txt introduces two changes for the
issue:
1. Section 4.6.2 says:
Preferred Lifetime
32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent)
that addresses generated from the prefix via
stateless address autoconfiguration remain
preferred [ADDRCONF]. A value of all one bits
(0xffffffff) represents infinity. See [ADDRCONF].
---> Note that the value of this field MUST NOT exceed
---> the Valid Lifetime field to avoid preferring
---> addresses that are no longer valid.
2. Section 6.2.1 says:
AdvPrefixList
[...]
AdvPreferredLifetime
[...]
Default: 604800 seconds (7 days), fixed
(i.e., stays the same in consecutive
---> advertisements). This value MUST NOT be
---> larger than AdvValidLifetime.
As I said in a related discussion for rfc2462bis, the change in
Section 4.6.2 seems overspecification according to the original
consensus that led to the issue. See
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03034.html
for more details. As I mentioned in this message, I think the
restriction in Section 4.6.2 (the part marked with "---->") should be
removed.
Additionally, it is probably not enough to say "AdvPreferredLifetime
MUST NOT be larger than AdvValidLifetime", since either one or both of
the lifetimes can be configured so that it decrements in real
time. For example, consider the case where
AdvValidLifetime = 40000 (decrementing in real time)
AdvPreferredLifetime = 30000 (fixed time).
These configurations seem valid according to the specification.
However, the advertised valid lifetime would be smaller than the
advertised preferred lifetime about 10000 seconds later.
I see two resolutions to avoid this scenario:
A. if AdvValidLifetime decrements in real time, require
AdvPreferredLifetime decrement as well
B. require routers to ensure the valid lifetime be equal to or larger
than the preferred lifetime at sending time, regardless of the
values of AdvValidLifetime and AdvPreferredLifetime.
Option A would require additional text in Section 6.2.1. Option B
would require additional specification in Section 6.2.3.
I personally can live with either approach, but slightly prefer the
latter one, since it will provide maximum configuration flexibility.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
