[...] >> 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.
please no. this makes for unstable addresses. addresses != routing. >> 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. a host should verify that its address is valid triggered by an L2 event. I think we need some new work with regards to 'flash renumbering'. cheers, Ole >> 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[ >> ] [email protected] 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/homenet > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
