On Wed, Nov 6, 2019 at 6:19 PM Alexandre Petrescu <alexandre.petrescu@xxxxxxxxx> wrote: > draft says: > > Scaled Lifetime field SHOULD by default be set to the lesser of 3 x > > MaxRtrAdvInterval divided by 8, or 8191 > > If MaxRtrAdvInterval is 1 (RFC6275 'Mobile IPv6', radvd.conf) then the > division wont work, so the 'lesser' wouldnt be computed. We can add the following text: 'if 3 x MaxRtrAdvInterval is less than 8 then the Scaled Lifetime field SHOULD by default be set to 1', On the side note: it looks to me that RFC6275 contradicts 'MUST' in RFC4861: RFC6275: "Routers supporting mobility SHOULD be able to be configured with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value.... MinRtrAdvInterval 0.03 seconds, MaxRtrAdvInterval 0.07 seconds" while RFC4861 states that "MaxRtrAdvInterval ..MUST be no less than 4 seconds" and "MinRtrAdvInterval...MUST MUST be no less than 3 seconds"). At the same time RFC6275 is not formally updates RFC4861.. > Then, by 'lifetime', in the cited text below and throughout the > document, one means the 'Scaled Lifetime' of this option, right? It actually does not matter, as zero Scaled lifetime means zero lifetime, and non-zero Scaled Lifetime means non-zero actual lifetime. > > Routers SHOULD check and compare the following information: > > > > o set of PREF64 with non-zero lifetime; > > > > o set of PREF64 with zero lifetime. > > Finally, for my curiosity, I wonder what kind of algorithm for checking > is consideredin each case. Is it a precise checking, or more relaxed? > For example, how does it compare a /96 to a /64 (with a precise checking > they cant match, but with a longest match checking they could); would an > absolute or a partial majority in the set be needed to win the check, etc. 2001:db8::/96 and 2001:db8::/64 are two different prefixes IMHO. 'Longest prefix match' etc applies when you are finding a prefix a particular IP address belongs to, not when you compare two prefixes. Also please note that it's just a check for configuration consistency within a LAN/PvD. > > > > Abstract > > > > > > This document specifies a Neighbor Discovery option to be used in > > Router Advertisements to communicate NAT64 prefixes to hosts. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > _______________________________________________ IETF-Announce mailing > > list IETF-Announce@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf-announce > > > > -- > last-call mailing list > last-call@xxxxxxxx > https://www.ietf.org/mailman/listinfo/last-call -- SY, Jen Linkova aka Furry -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
