One typo below... > -----Original Message----- > From: Dave Thaler > Sent: Friday, February 10, 2012 6:42 PM > To: Dave Thaler; Chris Grundemann; Brian E Carpenter > Cc: Bob Hinden; Brian Haberman; [email protected] > Subject: RE: 6MAN WG Last Call: draft-ietf-6man-rfc3484-revise-05.txt > > 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).
Above was backwards, should be: I'd argue that (a) is the right answer. The -revise draft's proposal would instead result in (b). > 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 --------------------------------------------------------------------
