Re: Re: IIDs, u and g bits, and 4rd

[Ray Hunter <[e-mail]>]

Inline

Rémi Després wrote:
> 2012-12-20 20:29, Ole Troan <[e-mail]> :
>
>> Remi,
>>
>> [...]
>>
>>>> To make assertions about IP addresses based on the EUI-64 is to impose requirements that don't actually exist in IP. It's a little like saying that concrete MUST ("are required to") be grey because the rocks we use in it happen to be grey; no I can have concrete of other colors if I want.
>>> I do agree that, despite a rule exists in some RFC one can see configurations that don't comply with it. 
>>> Consequently, "intended to be globally unique" doesn't mean "guaranteed to be globally unique in real life", right.
>>>
>>> This isn't a reason, however, to abandon rules that proved to be useful. 
>>> AFAIK, the rule that IIDs having u=must (so far) only be based on global IEEE EUI-64 addresses is one of these useful rule not to be abandoned. 
>> how has it proved to be useful?
>> I'm not aware of any protocol or implementation using it.
>
> As already said, it facilitates address stability.
> This is so with OSes that, by default, base their IIDs on EUI-64 addresses of their link adapters.
>
>
>>>> The comment Brian is making refers to IP's requirements, which are that the IID used in a subnet by an interface must be unique within that subnet.
>>> This is a clear requirement, on which I think we all agree.
>>>
>>> It is worth noting here that satisfaction of this requirement DOES DEPEND in part on IIDs having u=being actually unique.
>>> (Reason is that RFC 4862 says (uppercase added) "IPv6 nodes are NOT required to validate that interface identifiers created with modified EUI-64 tokens with the "u" bit set to universal are unique".)
>> to be pedantic it is RFC4291 that says that.
>
> Right, the RFC number wasn't the right one.
> Thanks.
>  
>> the only thing it says is that an implementation does not have to validate that a interface-id is _globally_ unique (how could it?), it still
>> has to validate that an address created with that interface-id is unique.
>
> I find it very hard to interpret the above sentence the way you do.
> Since, as you rightly imply, there is no way locally to check _global_ uniqueness, this sentence is useful only if it means that it is uniqueness _on the link_ that is "not required to be validated" if u=
>
> Anyway, even with your interpretation, this isn't against adding a new reserved IID range to those of RFC5453.
>
>>>> If one has a physical machine with an interface that supports a dozen virtual machines, the requirement is not that all of the physical and virtual machines use IP addresses derived from the physical interface MAC address;
>>> Well understood.
>>>
>>>> the requirement is that they each have IIDs that are unique within the subnet. The obvious choice will be to use privacy addresses for the VMs, which will appear outside the physical machine as the one interface having that many IP addresses.
>>> Agreed.
>>> Since these IIDs will have u= this is neutral in the discussion on u=1 IIDs.
>>>
>>>
>>> AFAIK, no technical and/or operational consideration remains that would prevent the IANA registry on IIDs to be updated as follows (the 4rd range is that proposed by Brian). 
>> that's a different question than what was asked by the softwire.
>> is the question to the 6man WG now, "is it acceptable to reserve 2^48 interface-id's" using the RFC5453 registry?
>
> The basic question is whether reserving for 4rd a specific 8-bit IID is "compatible with the IPv6 addressing architecture" as currently specified.
> Besides some expressed FUD, which isn't illegitimate in face of anything new, no such conflict has been identified by those who checked carefully.
You may call it FUD, but could you please point the WG members to the
text in either the IPv6 addressing architecture (RFC4291) or SLAAC
(RFC4862)  that says that the g bit MUST be overridden to 0 before
creating an IID (and thus link-local and global IPv6 unicast addresses
when they are appended to a /64 prefix)?

It may be sensible, but where is it *defined* in an IETF standards track
RFC that automatic address generation based on an EUI-64 seed MUST NOT
use g=1?

I think we both agree that being able to guarantee unique addresses on a
link is pretty fundamental to correct operation of IPv6, especially
considering the 4rd proposal as documented in your published ID would
not appear to use DAD, and failing DAD in existing nodes currently
causes an interface to cease processing IPv6 packets.

The only text I can find is in the Ethernet specific encapsulation
(RFC2604) which states "The Interface Identifier [AARCH] for an Ethernet
interface is based on the EUI-64 identifier [EUI64] derived from the
interface's built-in 48-bit IEEE 802 address." And even then it's not
specific that if a manufacturer decided to burn in an EUI-48 into their
NIC with g=1 (e.g. for a technology that multicasts by default for
multi-channel television distribution) and this address is from within
their IEEE -assigned OUI space, whether that would be illegal for use
with IETF IPv6 standards.

Also not everything is Ethernet.

regards,
RayH 

> This would normally lead to a flat "yes it is compatible" but, during the discussion, it appeared that the proposed 8-bit prefix can advantageously be replaced by a longer prefix closer to an already reserved prefix, and this without any problem for 4rd. 
> A suggestion by 6man to change the proposed prefix value can therefore be constructive complement to the flat answer.
> I hope the WG will make this step forward.
>
> Regards,
> RD
>
>
>> cheers,
>> Ole
>>
>>
>>> The answer returned to Softwire can then be a request to change the 4rd draft accordingly.
>>>
>>> +-----------------------------------------+-------------------------+
>>> |        Interface Identifier Range       |       Description       |
>>> +-----------------------------------------+-------------------------+
>>> |           0000:0000:0000:0000           |  Subnet-Router Anycast  |
>>> |                                         |        [RFC4291]        |
>>> |                                         |                         |
>>> | FDFE:0000:0000:0000-FDFE:FFFF:FFFF:FFFF |   Reserved 4rd Unicast  |
>>> |                                         |    Addresses [RFCxxxx]  |
>>> |                                         |                         |
>>> | FDFF:FFFF:FFFF:FF80-FDFF:FFFF:FFFF:FFFF | Reserved Subnet Anycast |
>>> |                                         |    Addresses[RFC2526]   |
>>> +-----------------------------------------+-------------------------+
>> cheers,
>> Ole
>