Hi,

Am 06.02.2013 14:52, schrieb Rémi Després:
> As already said, the 4rd range only makes a first use of an existing
> RFC4291 provision: "The use of the universal/local bit in the
> Modified EUI-64 format identifier is to allow development of future
> technology that can take advantage of interface identifiers with
> universal scope."

As it turns out now, this assumption is probably no longer true.

> - Once more: existing implementations have NOTHING to do (as long as
> they don't add 4rd support). Expressed doubts on this should be
> justified by a detailed technical justification. If you have any,
> let's look at it.

I was talking more about implications on new/forthcoming/updated
implementations. Do they need to keep a list of reserved IIDs
and check against them? This seems to be a bad idea IMHO.
We have no clear rules for this yet.

> - The reserved range is a tool to AVOID conflicts. It isn't, like
> DAD, a tool to RESOLVE them when they occur.

That's exactly my point: what should future implementations
do in order to avoid such conflicts? In case that they are
not using 4rd, MUST they exclude this IID range?

Regards,
 Roland
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to