[radvd-devel-l] DeprecatePrefix option

[Mark Smith]

Hi Pekka,

Sorry not to get back to you sooner.

On Wed, 9 Mar 2011 23:08:32 +0200 (EET)
Pekka Savola <pekkas at netcore.fi> wrote:

> On Wed, 9 Mar 2011, Mark Smith wrote:
> >              Upon shutdown, this option will cause radvd to deprecate
> >              the prefix by announcing it in the radvd  shutdown  RA
> >              with  a  zero preferred lifetime and a valid lifetime
> >              slightly greater than 2 hours. This will encourage
> >              end-nodes using this prefix to deprecate any associated
> >              addresses immediately. Note that  this option  should
> >              only be used when only one router is announcing the
> >              prefix onto the link, otherwise end- nodes will deprecate
> >              associated addresses despite the prefix still being valid
> >              for preferred use.
> 
> Have you tested this on two routers, how does a host really behave 
> when it gets zero preferred lifetime and a 2h valid lifetime -- and 
> subsequently, from another router, a higher lifetime?
> 
> I'd assume that the other router keeps advertising the longer 
> lifetime, and the hosts will continue to keep using the prefix, and 
> will also initiate new connections immediately after hearing back from 
> the other router.
> 

I hadn't tested it.

My thinking was that there would be a window between when one of the
router instances deprecated the prefix and the other one renewed it,
during which new outbound connections would fail, with this window
commonly being in the order of minutes, based on the default values for
MinRtrAdvInterval and MaxRtrAdvInterval. Certainly not a good user
experience when the prefix is actually not deprecated.

I've now found that the next section of RFC4861, 5.5.4, discusses
this situation. It seems that a deprecated prefix is considered to be a
last resort for source address selection if there are no other valid
prefixes, although it does say that the choice to use them may be up to
an application, and that an operating system can provide a mechanism to
disable it, although the mechanism should be disabled by default.

So it seems that there are two possibilities if one router deprecated
the prefix when two are announcing it -

o  if there is an alternative valid prefix, the end-host will start
using it for new source addresses. If the second router's
unsolicited RA "re-validates" the prefix, the end-host may or may not
return to using the revalidated prefix.

o  if there isn't a valid prefix, the end-host probably will continue
to use the deprecated prefix for source addresses, although this may
depend on the application or an underlying OS switch.

I don't think either of those situations are quite as bad as I
initially thought, although there are still some drawbacks. Due to
these drawbacks, I think I'd prefer to be conservative and default
deprecating of prefixes to off.

To put a bit more context behind this, my motives to add this option
were to allow radvd to support the deprecating prefix clause of the
simple IPv6 CPE draft -

http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-cpe-router-09

   L-13:  If the delegated prefix changes, i.e. the current prefix is
          replaced with a new prefix without any overlapping time
          period, then the IPv6 CE router MUST immediately advertise the
          old prefix with a preferred lifetime of 0 and a valid lifetime
          of 2 hours (which must be decremented in real time) in a
          Router Advertisement message.

Regards,
Mark.


> One reason for longer default lifetimes in v6 was that if a router 
> goes down for some time, internal connectivity using the addresses 
> still keeps working. This could be still be useful in limited scale, 
> e.g., enough time for the system to reboot, for example (10min). But 
> in practise, the lifetimes have decreased and this is probably no 
> longer a useful goal, given the drawbacks.
> 
> If this works reasonably out of the box, I wonder if the default 
> should be to enable this feature.
> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> -- 
> radvd-devel-l mailing list  :  radvd-devel-l at litech.org
> http://lists.litech.org/listinfo/radvd-devel-l