Dave, one quick question below.
On 2012/02/11, at 11:41, Dave Thaler wrote: > 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. So, you are suggesting to map ULAs(fc00::/7) to site-local scope also for unicast ? Then, I don't see how the former case can be solved by this fix. The ULAs should be chosen for both src and dst addresses, if they have smaller scope than global addresses, right ? Or, are you suggesting to map only ULAs that is in the same prefix to site-local scope ? Best regards, > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
