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=1 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.
>> 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=1 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.
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.
>> 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=0, 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?
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
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
