Re: Detailed review of Significance of IPv6 Interface Identifiers

[Ray Hunter <[e-mail]>]

> Brian E Carpenter <mailto:[e-mail]>
> 2 September 2013 22:18
> On 02/09/2013 17:55, Ray Hunter wrote:
>>> Brian E Carpenter <mailto:[e-mail]>
>>> 2 September 2013 03:38
>>> 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.
>> 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>
>
>> So any IETF standard that assumes a 1:1 relationship between IID and
>> IEEE LAN hardware is heading for trouble.
>
> Agreed - in what way does the draft imply anything else?
I agree on the conclusion and the meaning. But the reasoning is not
clear to me, nor particularly correct.
>
> (The words in RFC 4291 that we are obsoleting do seem to imply
> 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