Subject: RE: [rfc2461bis issue 246] preferred lifetime > valid lifetime

From: "Soliman Hesham" <[email-masked]>
Date: Fri, 16 Jul 2004 22:22:14 -0400

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

=> Ok, but you said that 6 months after the text was added :) 
The concensus back then was to add the current text. If you 
want we can revisit the issue before LC.

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

=> There is one issue here: These restrictions are specified in the context
of the _advertised_ information on the wire. I'm sure that there are many 
different ways of configuring both fields. The requirement is that _whenever_
sending_this_on_the_wire_ the preferred liftime must not be larger than
valid lifetime. This is independent of how people configure fields or 
implement their storage.

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

=> B. is what's implied already since we're talking about protocol
fields. When we define protocol fields it is clear that the definitions are 
in the context of communication over the wire.

Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 21 Jul 2004 20:50:30 +0900

>>>>> On Fri, 16 Jul 2004 22:22:14 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

> want we can revisit the issue before LC.

I apologize for the late comment (I also know this is a minor nitpick,
so I won't be too much vocal on this).  However, I could not see the
discussion log (to the consensus) at the issue tracker page for this
issue, so I raised it at this timing.

> valid lifetime. This is independent of how people configure fields or 

But AdvPreferredLifetime and AdvValidLifetime are "Router
Configuration Variables", which are "conceptual variables to be
configured by system management" (from Section 6.2.1).  So, IMO,
just specifying a requirement between AdvPreferredLifetime and
AdvValidLifetime does not necessarily make a requirement on the wire
content.

At the same time, however, I admit Section 6.2.3 appears to say these
variables are also the wire content:

                - In the Valid Lifetime field: the entry's
                  AdvValidLifetime.

                - In the Preferred Lifetime field: the entry's
                  AdvPreferredLifetime.

In that sense,

> in the context of communication over the wire.

I tend to agree on this interpretation.  I'd still add a note for the
AdvPreferredLifetime like this:

                             Default: 604800 seconds (7 days), fixed
                             (i.e., stays the same in consecutive
                             advertisements). This value MUST NOT be
                             larger than AdvValidLifetime. (Note that
                             the condition may change at a future
                             point in time when AdvValidLifetime
                             decreases in real time.)

(Again, I know this is a minor corner case.  So I won't strongly argue
for the additional note)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]