Subject: Re: Re: Detailed review of Significance of IPv6 Interface Identifiers

From: Ray Hunter <[email-masked]>
Date: Sun, 01 Sep 2013 11:33:21 +0200

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

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Sep 2013 13:38:19 +1200

Ray,

> perhaps not all router interface hardware.

The phrasing in the draft looks completely compatible with that to me.

> 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

---

From: Ray Hunter <[email-masked]>
Date: Mon, 02 Sep 2013 07:55:26 +0200

> Brian E Carpenter <mailto:[email-masked]>
> 2 September 2013 03:38
> Ray,
>

I'm not sure what the text is trying to say though.

AFAIK there are at least 3 legitimate operational cases where the 1:1
relationship between LAN hardware (MAC) and L3 interface break down.

1) Software emulation. Where a driver spoofs a host machine into
thinking it's talking to hardware when it isn't. e.g. VM. There is no
LAN hardware involved at all.

2) NIC teaming (IEEE 802.3ad draft v1, IEEE 802.1ax, LACP, proprietary).
Where a NIC Teaming solution multiplexing unit presents multiple
physical NICs as one NIC to the OS. The IID generated may NOT be related
to the hardware address of the underlying adapter(s). There may be one
MAC address and multiple IPs, or multiple IPs and one MAC address, or
multiple IPs and multiple MAC addresses.

3) Device on a stick. Where an expensive/ specialised device is
connected to the network using a single high speed interface for both
inbound and outbound traffic using e.g. VLAN trunking (IEEE 802.1Q,
proprietary) connected to an L2 switch fabric. The specialised device
then configures multiple L3 sub-interfaces on the trunk, all of which
have an identical MAC address. If these VLANs are then broken out onto
multiple physical connectors by the L2 switch fabric (perhaps physically
located in the same chassis), you end up with a device with duplicate
MAC addresses on multiple physical interfaces. This is not an error, and
is a common implementation technique used by multiple manufacturers AFAIK.

So any IETF standard that assumes a 1:1 relationship between IID and
IEEE LAN hardware is heading for trouble.
> Ray Hunter <mailto:[email-masked]>
> 1 September 2013 11:33
> inline
>
> Brian E Carpenter wrote:
>> Hi Fernando,
>>
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Sep 2013 08:18:22 +1200

> I'm not sure what the text is trying to say though.

Ray, are you asking for a change in the text? Please be specific.

<snip>

> IEEE LAN hardware is heading for trouble.

Agreed - in what way does the draft imply anything else?

(The words in RFC 4291 that we are obsoleting do seem to imply
a 1:1 relationship, but that's what the draft fixes.)

    Brian

---

From: Ray Hunter <[email-masked]>
Date: Tue, 03 Sep 2013 14:37:51 +0200

> 2 September 2013 22:18
I agree on the conclusion and the meaning. But the reasoning is not
clear to me, nor particularly correct.
> a 1:1 relationship, but that's what the draft fixes.)
Agreed
>     Brian
Original text:

/However, this has not so far proved to be the case.  Also, there is
   evidence from the field that despite the IEEE standard [IEEE802], MAC
   addresses with universal scope are sometime incorrectly assigned to
   multiple MAC interfaces.  Firstly, there are recurrent reports of
   manufacturers assigning the same MAC address to multiple devices.
   Secondly, significant re-use of the same virtual MAC address is
   reported in virtual machine environments.  Once transformed into IID
   format (with "u" = 1) these identifiers would purport to be
   universally unique but would in fact be ambiguous.  This has no known
   harmful effect as long as the replicated MAC addresses and IIDs are
   used on different layer 2 links.  If they are used on the same link,
   of course there will be a problem, very likely interfering with link-
   layer transmission.  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./

Proposed text:

/
However, the expected advantages or application of interface identifiers
with universal scope have not materialised.

There is also evidence from the field that MAC addresses are not as
unique as one might expect, where for example manufacturers have
erroneously allocated the same burned in address to multiple devices.

Furthermore, IEEE standards and operational practices have advanced
significantly since RFC4291 was published.

There are at least three use cases in wide-spread production where a
router or other operating system interface at layer 3 may not enjoy
direct access to LAN hardware on a 1:1 relationship so that it can
access a "burned in address" from the MAC layer to create a unique IID
per interface with universal scope (which seemed to be an underlying
assumption when RFC4291 was written):

- use of software drivers to spoof an operating system into thinking it
is talking to hardware, when in fact no LAN hardware is present e.g. LAN
interfaces on virtual machines. Significant re-use of the same virtual
MAC address has been reported in virtual machine environments. 

- use of an intermediate NIC teaming layer or Link Aggregation Group
that takes a number of underlying layer 2 links and presents them as a
single MAC interface to the client operating systems (IEEE 802.3ad draft
v1, IEEE 802.1ax LACP, proprietary). IEEE 802.1ax states that the MAC
address of the LAG MAY be an address of one of the underlying links in
the Link Aggregation Group, but this is not limited in any way in
implementations. LACP may also add and delete links from the Link
Aggregation Group dynamically, and it would seem counterintuitive that
the associated IID, and thus the IPv6 address, had to change every time
this happened, because the whole purpose of the LAG is to shield the OS
from such low level changes.

- "Router on a stick", or "firewall on a stick", where a specialist
device such as an inter-VLAN router or firewall is connected to a layer
2 switch fabric via a single high speed interface, and multiple sub
interfaces are defined at Layer 3, all of which share a common layer 2
MAC address. These sub interfaces may be transported as a VLAN trunk
(e.g. 802.1Q) into the layer 2 switch fabric, where the individual VLANs
may then be presented on different hardware interfaces, such that the
device may appear to source traffic on multiple physical interfaces
using the same layer 2 address.

Once transformed into IID
   format (with "u" = 1) these identifiers would purport to be
   universally unique but would in fact be ambiguous.  This has no known
   harmful effect as long as the replicated MAC addresses and IIDs are
   used on different layer 2 links.  If they are used on the same link,
   of course there will be a problem, very likely interfering with link-
   layer transmission.  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.
/

Does that help?

-- 
Regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Sep 2013 08:23:42 +1200

Ray,

OK, I see your point, but that seems like too much detail
to be useful for most readers. I'd be inclined to summarise
it considerably.

Regards
   Brian