(Hmm, I thought I sent this via the issue tracker, but I seem to have
failed...so I'm resending it my local mailer).
I've just noticed another minor issue on RFC2462.
In short, the issue is it's not clear in RFC2462 whether we should
check the advertised prefix length when updating the lifetimes of an
existing address.
RFC2462 has the following organization in Section 5.5.3:
For each Prefix-Information option in the Router Advertisement:
a) Check for the Autonomous flag
b) Ignore the link-local prefix
c) Check for the case of preferred lifetime > valid lifetime
d) If the prefix advertised does not match the prefix of an address
already in the list, check if the advertised prefix length is
valid for the receiving interface (i.e. the prefix length must
be 128 - N where N is the length of the interface identifiers
on that link), and if valid, make a new address from the prefix.
e) If the prefix advertised does match the prefix of an address
already in the list, update the lifetimes of the address
(without checking the prefix length)
It seems to me that this specification allows (e.g.,) the prefix
"::/0" to update the lifetimes all existing addresses (which may even
include link-local addresses), since ::/0 matches any addresses.
Is this the intended behavior? I believe not, and if not, shouldn't
the specification be clearer to avoid this case? I believe it should.
Assuming I'm correct for both the questions, I'd like to propose to
revise the logic in Section 5.5.3 as follows:
a) Check for the Autonomous flag
b) Ignore the link-local prefix
c) Check for the case of preferred lifetime > valid lifetime
d) Check if the prefix length is valid for the receiving interface.
If it is not valid, ignore the prefix.
e) If the prefix advertised does not match the prefix of an address
already in the list, make a new address from the prefix
f) If the prefix advertised does match the prefix of an address
already in the list, update the lifetimes of the address
Comments?
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
