Detailed review of Significance of IPv6 Interface Identifiers

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492