Subject: Detailed review of Significance of IPv6 Interface Identifiers

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Aug 2013 04:43:37 -0300

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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Aug 2013 09:27:47 +1200

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

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

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

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

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

> draft-ietf-6man-stable-privacy-addresses).

It's true (see above comment on fuzzy text).

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

> semantics for u/g... but without any explicit motivation for doing so.

That's also orthogonal IMHO. Separate thread?

Thanks again,

    Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 14 Aug 2013 22:56:14 +0000

> provide two more bits of entropy rather than giving them fixed values.)

Good grief. If the bits don't mean anything - and they never did, since nobody ever interpreted them except in IETF dancing-on-heads-of-pins discussions - could we simply say that they are as random in value as any of the other bits in the IID are?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Aug 2013 15:32:02 +1200

> Good grief. If the bits don't mean anything - and they never did, since nobody ever interpreted them except in IETF dancing-on-heads-of-pins discussions - could we simply say that they are as rando…

Yes, I believe future IID formats could do that. We can try to make that
clear in the next version.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Aug 2013 12:35:03 +0900

> Good grief. If the bits don't mean anything - and they never did,
> since nobody ever interpreted them except in IETF
> dancing-on-heads-of-pins discussions - could we simply say that they
> are as random in value as any of the other bits in the IID are?

uh, the effective semantics of these two paragraphs are the same

two more bits of entropy == as random in value as any of the other bits in the IID

randy