Re: Detailed review of Significance of IPv6 Interface Identifiers

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

I know that a couple of people wanted the extra details suggested by Ray
below. However, the explanation that I got from the 802.1 liaison
(see my previous message) seems to me to make the details unimportant.

Regards
   Brian

On 04/09/2013 00:37, Ray Hunter wrote:
>> 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?
>> ------------------------------------------------------------------------
> 
>