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.
>
> 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.
this might be off topic. but I disagree with you. it is the property of using
stable globally unique identifiers to generate the interface-id that adds
stability. see the draft on stable-privacy-addresses for another example (one
which sets u=0).
given that no implementation uses the u-flag, it is hard to see what value it
adds.
>>>> 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.
>
> 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=1.
all implementations do validate uniqueness also for EUI-64 addresses. if you
read the rest of RFC4862 that should be quite clear.
> Anyway, even with your interpretation, this isn't against adding a new
> reserved IID range to those of RFC5453.
correct.
>>>> 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?
>
> 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.
> 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.
there appears to be quite a lot of pushback in 6man against the use of u/g bits
as specified in the 4rd draft.
do I understand you correctly, that you now want to withdraw that proposal, and
instead propose to make 2^48 interface-ids reserved for 4rd?
if so, I'm happy to have the discussion on the merit of that proposal here. I
think the working group would benefit though, to hear
from you what problem you are actually trying to solve.
Best regards,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
