IPv6 autoconf addresses with changing RAs...

[JINMEI Tatuya /神明達哉]

>>>>> On Sun, 2 Nov 2003 15:03:24 +0100 (CET), 
>>>>> Barry Bouwsma <freebsd-misuser at remove-NOSPAM-to-reply.NOSPAM.dyndns.dk> said:

> I have one IPv6 machine behind a second, which second machine for
> historical reasons has an IPv6 prefix/address that occasionally changes.
> After this happens, the first host-only machine receives an additional
> autoconf IPv6 address, but it still retains the old (now obsolete) IPv6
> autoconf address it had learned from this same router.  The machines are
> running kernels RELENG_4 from late-September-ish.  Userland varies horribly.

> What I want to happen, is that when the new IPv6 address is autoconf'ed,
> the old one should disappear from the interface.  (I've been too impatient
> to watch if it disappears after time, during which time I cannot reach
> the router's new address or the default route, as the old prefix which
> it had is no longer present thanks to my hacked scripts.  If I manually
> delete the original IPv6 address, it seems that things work.)

Does the following behavior of rtadvd(8) help you?

     Similarly, when an interface direct route is deleted, rtadvd will start
     advertising the prefixes with zero valid and preferred lifetimes to help
     the receiving hosts switch to a new prefix when renumbering.  Note, how-
     ever, that the zero valid lifetime cannot invalidate the autoconfigured
     addresses at a receiving host immediately.  According to the specifica-
     tion, the host will retain the address for a certain period, which will
     typically be two hours.  The zero lifetimes rather intend to make the
     address deprecated, indicating that a new non-deprecated address should
     be used as the source address of a new connection.  This behavior will
     last for two hours.  Then rtadvd will completely remove the prefix from
     the advertising list, and succeeding advertisements will not contain the
     prefix information.

At least rtadvd contained in FreeBSD 4.8R seem to support this
behavior.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei at isl.rdc.toshiba.co.jp