Folks, I've volunteered to provide a detailed review of this document, in response to the 6man wg chairs' request.
Overall, I believe that this is a very useful document, and I support its publication as an RFC. However, I think it would be great if the technical comments below could be addressed before we ship it. **** Technical ***** * Abstract: > This document clarifies that those bits apply only to interface > identifiers that are derived from an IEEE link-layer address. It > updates RFC 4291 accordingly. This para seems confusing. -- not sure what "those bits only apply means" - for instance, given an address, it's not really possible to tell how the address was generated. That aside, the text would read better as "link-layer address, and updates RFC 4291 accordingly". * Section 1: > IPv6 unicast addresses consist of a subnet prefix followed by an > Interface Identifier (IID), the latter supposedly unique on the > links reached by routing to that prefix. The Addressing Architecture refers to Global Routing Prefix (GRP) and subnet ID -- so I'd probably tweak the text accordingly. Besides, the latter part of the sentence is a bit confusing -- why not just say that the IID, when combined with the GRP and subnet ID is supposed to result in a unique address? * Section 1: > > In an IID, this bit is in position 6, i.e., position 70 in the > complete IPv6 address. and: > In an IID, this bit is in position 7, i.e., position 71 in the > complete IPv6 address. Since you're referring to position numbers rather than bits.. do you start with position 0 or one? from left or right? (yes, {you, we} know that... the reader might not) * Section 2: > These cases illustrate that the statement quoted above from RFC 4291 > requiring "Modified EUI-64 format" is rather meaningless when > applied to forms of IID that are not in fact based on an underlying > EUI-64 address. I'm not sure I'd say "meaningless" -- i.e., all the cited examples implicitly follow RFC4291's assertion that e.g. an operator wouldn't set the u/g bits by mistake (because low-byte IIDs are typically used). I do agree, of course, that bothering everyone else according to *one* possible underlying link-layer technology doesn't make much sense. And of course in those cases such bits will have no significance. * Section 2: > > However, this has not so far proved to be the case. Also, there is > evidence from the field that IEEE MAC addresses with universal scope > are sometime incorrectly assigned to multiple MAC interfaces. I recall some folk mentioned that, from an IEEE std point of view, this is not incorrect. -- Just me relaying some comment (on v6ops?).. I don't recall of the top of my head of what the relevant IEEE std says. You might want to reference this presentation, which comments on duplicate MAC addresses: [HDMoore] HD Moore, "The Wild West", Louisville, Kentucky, U.S.A. September 25-29, 2012, <https://speakerdeck.com/hdm/derbycon-2012-the-wild-west>. * Section 3: > To the extent that each method of IID creation specifies the values > of the "u" and "g" bits, and that each new method is carefully > designed in the light of its predecessors, these bits tend to reduce > the chances of duplicate IIDs. Not sure what you mean. Do you mean that *if* each IID-generation method were to use a different combination of "ug", colisions between them would be avoided? If so, I'd argue that since there's no coordination of which combinations should be used for which method, that's unfeasible. For instance, traditional SLAAC uses all combinations (modulo "illegal/unused" combinations of ug). * Section 4: > > As mentioned above, Duplicate Address Detection (DAD) [RFC4862] is > able to detect any case where a collision of two IIDs on the same > link leads to a duplicated IPv6 address. The scope of DAD may be > extended to a set of links by a DAD proxy [RFC6957] or by Neighbor > Discovery Optimization [RFC6775]. Since DAD is mandatory for all > nodes, there will be no case in which an IID collision, however > unlikely it may be, is not detected. I have not experienced it myself, but I wouldn't be surprised if DAD were to fail on a wireless network. So I'd probably wouldn't say "there will be no case" (i.e., relax the text a bit). * Section 4: > It is out of scope of most existing specifications to define the > recovery action after a DAD failure, which is an implementation > issue. Me, I think that there's a gap in the specs in this respect. They specify an algorithm to follow, and algorithm to detect collisions, but no algorithm to recover (and, obviously, you cannot recover by reusing the same algorithm that led to the collision). Note: I don't expect changes in response to this comment (text is fine) -- just me thinking out loud. * Section 5: > The EUI-64 to IID transformation defined in the IPv6 addressing > architecture [RFC4291] MUST be used for all cases where an IPv6 IID > is derived from an IEEE MAC or EUI-64 address. With any other form > of link layer address, an equivalent transformation SHOULD be used. I'd remove this paragraph altogether. Here's my rationale: 1) You're just clarifying the u/g bits. *Which* method is used for generating addresses with SLAAC is kind of out of the scpe of this document. 2) If we end up deprecating IEE-MAC-based addresses (and it looks like we're heading there), this document will have to be updated, too. * Security Considerations: Since this document allows address generation methods to use the ug bits in any way they want, that allows for extra entropy when IIDs are generated in such a way that they are unpredictable (e.g., as in draft-ietf-6man-stable-privacy-addresses). Besides, and while *this* document does *not* introduce any new issues, you should probably briefly comment on the implications of EUI-64 based IIDs. Alissa's document and/or draft-ietf-opsec-ipv6-host-scanning and/or draft-ietf-6man-stable-privacy-addresses might be good references to include along with whatever text you craft on the subject. * Last, but not least.... Should we do anything about RFC2526? -- It currently requires specific semantics for u/g... but without any explicit motivation for doing so. **** Editorial **** * Abstract: > This document clarifies that the bits in an interface identifier have > no generic meaning and that the identifier should be treated as an > opaque value. Shouldn't this be "universal" rather than "generic"? * Section 5: > Specifications of other forms of 64-bit IID MUST specify how all 64 > bits are set, but need not treat the "u" and "g" bits in any special > way. A general semantic meaning for these bits MUST NOT be defined. > However, the method of generating IIDs for specific link types MAY > define some local significance for certain bits. > > In all cases, the bits in an IID have no general semantics; in other > words, they have opaque values. In fact, the whole IID value MUST be > viewed as an opaque bit string by third parties, except possibly in > the local context. Maybe "universal" is a better than "generic" and "general"? **** Nits **** * Section 1: > Thus the specification assumes that that the normal case is to > transform an Ethernet-style address into an IID, but in practice, > there are various methods of forming such an interface identifier. s/that that/that/ * Section 1 > Finally it updates RFC 4291 accordingly. Missing comma right after "Finally". * Section 2: > If not, the problem will be detected by duplicate address detection > [RFC4862], [RFC6775], but such an error can usually only be resolved > by human intervention. Please remove the comma between "[RFC4862]" and "[RFC6775]". * Section 2: > Additionally, the "u" and the "g" bits are both meaningless in the > format of an IPv6 multicast group ID [RFC3306], [RFC3307]. Please remove the comma between "[RFC3306]" and "[RFC3307]". Thanks! Cheers, -- Fernando Gont SI6 Networks e-mail: fg...@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------