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 On 04/09/2013 00:37, Ray Hunter wrote: >> Brian E Carpenter <mailto:brian.e.carpen...@gmail.com> >> 2 September 2013 22:18 >> On 02/09/2013 17:55, Ray Hunter wrote: >>>> Brian E Carpenter <mailto:brian.e.carpen...@gmail.com> >>>> 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? >> ------------------------------------------------------------------------ > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------