Yes. I am aware of it. The RA prefix is a legitimate one, and accepted by the linux box. The problem is that it seems to hold on to it for at least 15s or more seconds after it had expired. --- On Thu, 11/13/08, Jeff Haran <jharan@xxxxxxxxxxx> wrote: > From: Jeff Haran <jharan@xxxxxxxxxxx> > Subject: RE: Linux still keep the expired prefix 15 seconds after its expiration > To: "Wendy Lai" <weiwen_lai@xxxxxxxxx>, linux-net@xxxxxxxxxxxxxxx > Date: Thursday, November 13, 2008, 10:59 PM > > -----Original Message----- > > From: linux-net-owner@xxxxxxxxxxxxxxx > > [mailto:linux-net-owner@xxxxxxxxxxxxxxx] On Behalf Of > Wendy Lai > > Sent: Thursday, November 13, 2008 2:42 PM > > To: linux-net@xxxxxxxxxxxxxxx > > Subject: Linux still keep the expired prefix 15 > seconds after > > its expiration > > > > We have observed a behavior on our linux 2.6.20 box > where the > > ipv6 address cannot be released 15 seconds after the > prefix > > had expired. I have verified that addrconf_verify > properly > > called ipv6_del_addr at the time of expiration. > However, i am > > suspecting that the reference count of the address was > not 0. > > Does anyone know of this problem? What could be > possibly > > holding on to the address? > > > > This linux box is connected to a router on an isolated > network. > > > > Thanks, > > Weiwen > > I assume you are aware of the security driven rules in RFC > 2462 about rejecting prefixes with lifetimes that are much > shorter than the remaining lifetime on the prefix. Just in > case: > > From RFC 2462, section 5.5.3.e: > > 2) If the StoredLifetime is less than or equal to 2 > hours and the > received Lifetime is less than or equal to > StoredLifetime, > ignore the prefix, ... > > If you are already aware of this, my apologies, but if not, > this rule might be what's getting in the way of your > testing, though I can't explain how that jibes with > ipv6_del_addr() being called. > > Jeff Haran -- To unsubscribe from this list: send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
