Re: Detailed review of Significance of IPv6 Interface Identifiers

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

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

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