Jen,
Le 07/11/2019 à 10:02, Alexandre Petrescu a écrit :
Le 06/11/2019 à 21:08, Jen Linkova a écrit :
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',
Sounds reasonable text resolution, I agree.
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...
I do not know.
On one hand, I fully agree: RFC6275 does not formally update RFC4861:
there is no "Updates:" tag in its front page. In that sense one might
think about requesting an Errata for adding such a tag, in the DMM WG.
On another hand, while working with implementation I never cared to
check whether the RFC formally updates one another. The software _had_
to be updated, yes, but not cared about the RFC because once it's an RFC
one can hardly touch on it.
Alex
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.
Ok.
And with respect to the question of how many members in a set must be
equal in order to declare consistency? All of them?
Alex
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
