Ray, > So AFAICS the u/l restriction and uniqueness restriction is only > relevant when EUI64 is used in the context of specific LAN hardware, but > perhaps not all router interface hardware.
The phrasing in the draft looks completely compatible with that to me. > There's a specific IEEE contact (IEEE/RAC) who can clarify this when > referencing IEEE defined terms in other standards. > http://standards.ieee.org/about/bog/rac.html That's one for the IETF's liaison to handle. I will ask him (Eric Gray). Regards Brian Carpenter On 01/09/2013 21:33, Ray Hunter wrote: > inline > > Brian E Carpenter wrote: >> Hi Fernando, >> >> Thanks once again! We'll make corresponding updates in the next version. >> Just a few discussion points below: >> >> On 14/08/2013 19:43, Fernando Gont wrote: >> ... >>> * 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. >> 802.1 section 9.2.2 makes it clear that the U bit is intended to >> make the address universally unique: >> >> "The method that an assignee uses to ensure that no two of its devices carry >> the same address will, of course, >> depend on the assignment or manufacturing process, the nature of the >> organization, and the organization’s >> philosophy. However, the users of networks worldwide expect to have unique >> addresses. The ultimate >> responsibility for assuring that user expectations and requirements are met, >> therefore, lies with the >> organization offering such devices." > > I'd be careful on making that link if you pardon the pun. EUI64 != LAN > hardware address. > > See > > http://grouper.ieee.org/groups/msc/MSC200407/OnlineTutorialsD/EUI64.htm > http://standards.ieee.org/develop/regauth/tut/eui.pdf > > AFAIK 802.1 is a specific application of MAC-48 in LAN identifiers. Not > EUI48. Quote "The use of the MAC-48 identifier is obsolete". > > Quote "48-bit EUI-48 identifiers were originally created to serve as > network or media access control (MAC) addresses for local area networks > (LANs) by IEEE Project 802. Within this environment, EUI-48 identifiers > are intended to identify items of real physical equipment, parts of such > equipment, or functions that apply to many instances of physical > equipment. The use of 48-bit identifiers has been extended to serve as > protocol identifiers to identify protocol designs and design revisions > of protocols operating between instances of physical equipment, where > there are expected to be far fewer such protocols identified than there > are items of addressable physical equipment." > > AFAIK EUI64 has different/ less restrictions to EUI48 and certainly MAC-48. > > Quote: "Given the minimal probability of consuming all the EUI-64 > identifiers, the IEEE/RAC places minimal restrictions on their use > within standards. Their major use is to distinctively identify hardware > instances of devices. They may also be used for other purposes where a > unique identifier is desired. " > > So AFAICS the u/l restriction and uniqueness restriction is only > relevant when EUI64 is used in the context of specific LAN hardware, but > perhaps not all router interface hardware. > > There's a specific IEEE contact (IEEE/RAC) who can clarify this when > referencing IEEE defined terms in other standards. > http://standards.ieee.org/about/bog/rac.html > > I'd humbly suggest that we run this draft standard document by them. > >>> 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>. >> We have references to that and to >> http://enterpriseadmins.org/blog/scripting/virtual-machines-with-duplicate-mac-addresses >> commented out in the source file. In general the RFC Editor doesn't much like >> conference or blog URLs because they tend to disappear. >> >>> * 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). >> The argument is fuzzy and the sentence needs to be rewritten. >> >> (I would actually suggest that in a pseudo-random method, now that we >> are clear that the bits have no meaning, it would be best to use them to >> provide two more bits of entropy rather than giving them fixed values.) >> >> ... >>> * 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. >> Well, I believe we have broadened the scope a bit. What this text is trying >> to do is clarify the wording in 4291, which really is written as if >> Modified EUI-64 is the *only* kind of IID. >> >>> 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. >> No, because it only applies when EUI-64 is used. If we drop EUI-64 >> completely (which would amaze me) the words would be irrelevant but >> not harmful. >> >> So personally I don't think we should change this. >> >>> * 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). >> It's true (see above comment on fuzzy text). >> >>> 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. >> Actually we decided that the whole privacy issue was orthogonal, >> partly because there are several drafts and having a bunch of "work >> in progress" references is quite annoying to the reader. How about just >> adding a general comment that the method of IID generation has privacy >> implications but they are considered out of scope for the document? >> >>> * 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. >> That's also orthogonal IMHO. Separate thread? >> >> Thanks again, >> >> Brian >> >> > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
