Re: Detailed review of Significance of IPv6 Interface Identifiers

[Brian E Carpenter <[e-mail]>]

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
>>
>>
>