rtadvd(8) and deprecated prefixes

[Eugene M. Kim]

Jinmei-san,

Thank you for the response.

What I wonder is how one would define the "typical, default" case.
Although RFC 2461/2462 does not say much about it, I am having a hard
time seeing in which case it would be beneficial to advertise deprecated
prefixes as preferred by default.

On the other hand, it does break the case where automated, or
configuration-free, router renumbering is used in combination with a
gradual renumbering procedure, e.g. one described in RFC 4192, which was
in fact what I was trying to put into test on my home router :-p.  If
the router were instructed to wait until completion of all sessions
using the old prefix before removing it (RFC 4192, sections 2.6.2 and
2.7), it might have to wait indefinitely as hosts keep creating new
connections because the hosts never see the old prefix as deprecated;
even if the router were instructed to remove the prefix after a planned
grace period, there would be much more hard communication failures
stemming from broken connections because of the apparent lack of grace
period (from hosts' POV).

For these reasons, I believe it is more sensible to define it "typical"
for a router to advertise a prefix as deprecated (i.e. with zero pltime)
if it sees the prefix is deprecated on the interface.

I understand that it is your decision whether the above is an obscure
corner case worth little/no support from rtadvd because you are the
author ^_^.  However RFC 4192 was the (only) v6ops document that I could
find about gradual renumbering, so I think it is more than a corner case
and is actually worth supporting.

Regards,
Eugene

P.S. While you are on this topic: What problems did the current rrenum
code have so that it had to be disabled?  I am interested in improving
it back into a usable state...

JINMEI Tatuya / 神明達哉 wrote:
> I'm pretty sure different people have different opinions on this
> matter, but I personally think we should not try to "fix" it.
>
> This feature originally intended to make rtadvd as much
> configuration-free as possible in the most typical cases, that is, all
> addresses on the router is configured by hand and the associated
> prefixes are advertised with the default parameters defined in
> RFC2461.  This is because why rtadvd does not allow the administrator
> to specify just prefix lifetimes while letting the daemon get the
> prefixes from the kernel.  So, treating a prefix lifetime of 0
> separately is at least against the original design policy (believe me,
> I'm confident because it's me who implemented this:-)
>
> Also, once we open the Pandora's box, we'll encounter all other
> non-default issues that beg customized behavior or require detailed
> considerations on corner cases.  One example is to allow the user to
> specify the lifetimes (without specifying prefixes).  We might also
> want to have rtadvd follow decreasing lifetimes in real time.  Others
> may want to restrict the advertised prefixes to some subset of ones
> retrieved from the routing table, etc, etc.
>
> So, (again) I'd personally keep the current feature and requires the
> administrator to configure the router explicitly to handle any
> non-default cases.  (If we agree on that) we may have to note in the
> man page about the implementation policy, though.
>
> 					JINMEI, Tatuya
> 					Communication Platform Lab.
> 					Corporate R&D Center, Toshiba Corp.
> 					jinmei at isl.rdc.toshiba.co.jp
>