I'm now working on an actual update to rfc3484 that would Obsolete
(not Update) it. I found a couple more technical issues in so doing.
I also now believe it's faster to do the replacement than it is to
fix a delta-based document.
1) -revise documented the issue with Rule 9 of section 6, but does not
mention the same issue with Rule 8 of section 5, nor does it suggest a fix.
The proposed change to section 6 rule 9 used a "Netmask()" which was not
defined and indeed the term "mask" is not used with IPv6, only prefix length.
Instead of taking the proposed change, I propose to instead change the
definition of CommonPrefixLen() in section 2.2 as follows:
OLD (RFC 3484):
We define the common prefix length CommonPrefixLen(A, B) of two
addresses A and B as the length of the longest prefix (looking at the
most significant, or leftmost, bits) that the two addresses have in
common. It ranges from 0 to 128.
NEW:
We define the common prefix length CommonPrefixLen(S, D) of a source
address S and a destination address D as the length of the longest
prefix (looking at the most significant, or leftmost, bits) that the
two addresses have in common, up to the length of S's prefix (i.e.,
the portion of the address not including the interface ID). For
example, CommonPrefixLen(fe80::1, fe80::2) is 64.
2) Should ULAs be treated as site-local scope for purpose of the scope rules?
Consider the following two cases.
Destination Address Sorting: which should be preferred by default:
a) a native IPv6 global destination address?
b) a non-native ULA destination address that isn't in the same
prefix as your own ULA (if any)?
I'd argue that (a) is the right answer. The -revise draft's proposal
would instead result in (b).
Source Address Sorting: which should be preferred by default when
sending to a site-local multicast address:
a) a deprecated ULA source address?
b) a non-deprecated link-local source address?
I'd argue that (b) is the right answer. The -revise draft's proposal
would instead result in (a).
As such, I believe the correct fix is not to put fc00::/7 into the policy
table, but instead to update section 3.1 to say that we map ULAs to
multicast site-local scope. The existing scope rules would then have
the effects I argue are the right answers above.
2) Was RFC 3484 in error when it said IPv4-translatable addresses
should be treated as always in the "preferred" state?
We now know a lot more about IPv4-translatable addresses than
we (or I, anyway) did when 3484 was written, and RFC 6145 is the
current reference. IPv4 translatable addresses are not necessarily
recognized as such by a host. A host might get one from say DHCPv6
without knowing it's one, and that would be considered fine and normal.
However, the statement about being in the "preferred" state is somewhere
between unimplementable, and incorrect because the host is supposed
to go through DAD, etc.
Proposed fix:
OLD (RFC 3484):
IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should
be treated as having "preferred" (in the RFC 2462 sense)
configuration status.
NEW:
IPv4-compatible, IPv4-mapped, and IPv4-converted addresses should
be treated as having "preferred" (in the RFC 4862 sense)
configuration status.
(An "IPv4-converted" address is not assigned to any interface, it's the
IPv6 representation of an IPv4 address assigned to someone's interface,
just like IPv4-mapped addresses except that IPv4-converted addresses
can appear on the wire. See RFC 6145 for details.)
-Dave
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
