On Oct 9, 2011, at 12:07 PM, Michael Richardson wrote: > > Fred, I've changed the subject, I hope to shed more light. > >>>>>> "Fred" == Fred Baker <f...@cisco.com> wrote: > Fred> But also, the notion of tying the lifetime of a prefix on the > Fred> LAN with the lifetime of the prefix grant seems > Fred> ill-considered. The purpose of the lifetime on the prefix > Fred> grant (RFC 3363) is to enable an upstream to not need to be > > I think you meant RFC3633 here right? (DHCP-PD)
yes; typo... > I think that we clarified in discussion that the lifetime of prefix > advertised was limited to be no more than the lifetime in the PD. > It could be much lower. Yes. One would hope that it would be on the order of two announcement cycles; allow for losing one RA announcement, but call foul if two are lost in succession. > Fred> asked every 30 seconds for something it wants to leave > Fred> unchanged for a long period of time and yet make "a long time" > Fred> not be "forever". That's reasonable. But in the case called > Fred> out here, it seems like the lifetime of the prefix in an RA > Fred> should be long enough that a host can miss an RA refresh and > Fred> not lose the address, and short enough that we don't have to > Fred> call in the national guard if someone trips over a cable or a > Fred> power supply goes spitzensparken. > > Fred> What do we need to do to change that RFC 4861 requirement? If > Fred> what is required is an Internet Draft in 6man (and I would > Fred> expect it is), I'd be willing to write that draft. Going back to my previous note, the issue was that Lorenzo stated that Linux (and he presumed all other implementations) - considered only the RA most recently received - developed an address in that prefix ONLY - used it until the prefix announcement expired. That is of course not per RFC 4861. 4861 instructs that an address is calculated in every prefix received and held for possible use until it expires. RFC 3484 goes on to give instructions about the choice among such addresses. Thomas, later in that thread, asserts that Linux' correct operation per RFC 4861 has been tested and shown in various certification tests including USG. At this point, I think the ball is in Lorenzo's court. If Linux in fact does something different (and therefore the certification is voided), that needs to be shown. > I'm trying to understand things here. > We have, I think four lifes times around a homenet: > 1) DHCPv6 PD > 2) Router Lifetime. > 3) Prefix Valid Lifetime > 4) Prefix Preferred Lifetime > > We expect #1 to be large, on the order of weeks in most cases, lowered > only to minutes in the cases where operators expect to move users around > (such as rebalancing the load on the CMTS). > > I expect the router lifetime to be on the order of minutes so that a > host stops using a route sooner. We could modify this more if a host > follows the rules of RFC4191 Type C. I'm unaware of any Linux machines > being Type C, and I haven't seen *BSD do this, although maybe OSX does. > > Except for being limited by #1, it seems that we want to have a > Preferred Lifetime rather low only in the multi-router case. > > Maybe the right answer is dynamic: as soon a router, see another LSA, > they lower their Preferred Lifetime so that if there is a chance to > survive a topology change, then the host has a better chance of doing so > without having the wrong address for that link for too long. > > I admit that I still don't really understand how I should set my valid > lifetimes. It seems that they can be quite high in general. > > -- > ] He who is tired of Weird Al is tired of life! | firewalls > [ > ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net > architect[ > ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device > driver[ > Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE> > then sign the petition. > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
