[radvd-devel-l] request for comments - DecreaseLifetimes option

[Mark Smith]

Hi,

On Mon, 28 Mar 2011 08:30:40 +0300 (EEST)
Pekka Savola <pekkas at netcore.fi> wrote:

> I will observe that I'm aware of only one RFC 4861 S 6.2 
> implementation that supports "lifetimes decreasing in real time" -- 
> rtadvd.  I have vague recollection of hearing about this in the 
> context of Solaris, but I can't check that.
> 
> So, this is not a very widely used feature and not mandated by 
> specifications.
> 

As I have also been previously not been aware of this, and
have been making recommendations to ADSL CPE vendors on how their IPv6
firmware should behave, I have previously confirmed with Ole Troan,
one of the authors of the DHCPv6-PD RFC (RFC3633), that this is what is
intended by the following text -

   If the requesting router assigns a delegated prefix to a link to
   which the router is attached, and begins to send router
   advertisements for the prefix on the link, 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.  A
   requesting router MAY use the preferred lifetime specified in the
   IA_PD Prefix option.


I queried this with Ole once I noticed that Cisco IOS does this on
it's LAN interface if you use DHCPv6-PD on the WAN interface (on an 871
series router running a fairly recent 12.3 release IIRC). 

I also have a Billion router with beta firmware which performs in this
manner (without my prompting). 

Regards,
Mark.

> 
> On Sun, 27 Mar 2011, Reuben Hawkins wrote:
> > On Thu, Mar 24, 2011 at 9:36 PM, Mark Smith <radvd at 02a76c927861ca7413a122f2a73a0d37.nosense.org> wrote:
> >       Hi,
> >
> >       This option is a bit more complicated than the last ones. It provides
> >       an option to have radvd decrease the preferred and valid lifetime
> >       values of specified prefixes over time. This would be used in
> >       conjunction with prefixes supplied by DHCPv6 based Prefix Delegation
> >       (DHCPv6-PD). The sequence of events would be as follows -
> >
> >       1. Initial DHCPv6-PD transaction takes place over a e.g. WAN interface
> >       of the router, and a delegated prefix e.g. a /56 is acquired, with e.g.
> >       a preferred lifetime of 14400 seconds and a valid lifetime of 86400
> >       seconds.
> >
> >       2. A /64 is taken from within the delegated prefix, for use on the LAN
> >       interface of the router.
> >
> >       3. A radvd configuration is built with to announce this prefix, with
> >       preferred and valid lifetimes of 14400 and 86400 seconds respectively,
> >       and a prefix DecreaseLifetimes option.
> >
> >       4. For each RA, either solicited or unsolicited, the preferred and
> >       valid lifetimes are decreased by the number of seconds since the last
> >       RA.
> >
> >       5. At time "T1" the DHCPv6-PD client will attempt to renew the
> >       delegated prefix. If the delegated prefix is renewed successfully, with
> >       the same preferred and valid lifetimes, the DHCPv6-PD client sends a
> >       USR1 signal to radvd. This causes radvd to reset the announced preferred
> >       and valid lifetimes back to the lifetime values specified in it's
> >       configuration file, and then continue to decrease them for each
> >       RA. If the delegated prefix either doesn't renew successfully, or has
> >       different preferred and valid lifetimes, then the DHCPv6-PD client will
> >       have to stop radvd, generate a new configuration for it and start it
> >       again.
> >
> >       6. If radvd never receives the USR1 signal, it will continue to
> >       decrease the lifetimes until the preferred lifetime reaches 0.
> >       After an announcement of the prefix with a 0 preferred lifetime, radvd
> >       then stops announcing that prefix. If it subsequently receives a USR1
> >       signal, it will then start announcing the prefix again, with the
> >       lifetimes starting back at the specified initial values.
> >
> >       I'm interested in comments on the following patch. If people are happy
> >       with the approach, I'll finish it off by e.g. adding manual page
> >       entries.
> >
> >       Attached and shown below, it should apply to cvs revision 1.115.
> > 
> >
> >       Thanks,
> >       Mark.
> > 
<snip>
> > 
> > 
> > Hi Mark,
> > 
> > I'm not too enthusiastic about this patch for a few reasons.  I don't like the idea of an advert being dependent on time. 
> > Although it's subtle, it makes debugging and/or reproducing a bug more difficult.  However, this is called for in section 6.2.1
> > of RFC 2461 under AdvPreferredLifetime and AdvValidLifetime.
> > 
> > As such, please continue to test this for a while.  Make sure it's working.  If there's no objections to committing this, I'll
> > commit it in a few weeks.
> > 
> > Thanks,
> > Reuben
> > 
> >
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings