Date: Tue, 06 Feb 2007 13:38:41 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@isl.rdc.toshiba.co.jp> To: "Eugene M. Kim" <freebsd.org@ab.ote.we.lv> Cc: net@freebsd.org Subject: Re: rtadvd(8) and deprecated prefixes Message-ID: <y7vlkjb7ve6.wl%jinmei@isl.rdc.toshiba.co.jp> In-Reply-To: <45C7D251.8060004@ab.ote.we.lv> References: <45C7D251.8060004@ab.ote.we.lv>
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> On Mon, 05 Feb 2007 16:56:49 -0800, >>>>> "Eugene M. Kim" <freebsd.org@ab.ote.we.lv> said: > Note that the two automatically configured addresses on em0 are still > preferred, while the prefix 2001:470:1f01:3222::/64 is deprecated on the > router. > I believe rtadvd(8) should advertise deprecated on-link prefixes with > pltime of 0, but I still wanted to know what other people think about > this before working on actual code. So, here is the question: Is this > really something to be fixed? 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@isl.rdc.toshiba.co.jp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?y7vlkjb7ve6.wl%jinmei>