From owner-freebsd-net@FreeBSD.ORG Tue Feb 6 21:29:49 2007 Return-Path: X-Original-To: net@freebsd.org Delivered-To: freebsd-net@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 97D3C16A402 for ; Tue, 6 Feb 2007 21:29:49 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from mx1.nttmcl.com (mx1.nttmcl.com [216.69.64.132]) by mx1.freebsd.org (Postfix) with ESMTP id 65A1A13C4A8 for ; Tue, 6 Feb 2007 21:29:49 +0000 (UTC) (envelope-from freebsd.org@ab.ote.we.lv) Received: from [216.69.70.37] (ramen.nttmcl.com [216.69.70.37]) by mx1.nttmcl.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id l16LTisA027827; Tue, 6 Feb 2007 13:29:46 -0800 Message-ID: <45C8F348.8000708@ab.ote.we.lv> Date: Tue, 06 Feb 2007 13:29:44 -0800 From: "Eugene M. Kim" User-Agent: Thunderbird 1.5.0.8 (X11/20061130) MIME-Version: 1.0 To: =?UTF-8?B?SklOTUVJIFRhdHV5YSAvIOelnuaYjumBlOWTiQ==?= References: <45C7D251.8060004@ab.ote.we.lv> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on mx1.nttmcl.com Cc: net@freebsd.org Subject: Re: rtadvd(8) and deprecated prefixes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2007 21:29:49 -0000 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@isl.rdc.toshiba.co.jp >