2013-01-29 18:28, Ole Troan <[email protected]> :
...
>>> I still think we need to answer the question Brian raised.
>>> should the interface-id have any encoded meaning?
>>
>> That will not be done overnight. I've been thinking about it and
>> have some ideas about how to write a discussion draft, but it is
>> unfortuante to make the 4rd work queue behind us. Is there any risk
>> in doing as Rémi suggested?
>
> it depends on what the expected meaning of a reservation is.
> should all implementations treat the reserved part of the interface-id as
> martian,
No.
> and prohibit a user from configuring it for another purpose than 4rd?
Already done since, today, no RFC4291 unicast address may have u=g=1 (a point
confirmed during the discussion).
>
> or is it just a 'suggestion' for interface-id's that the 4rd mechanism can
> use, and the operator
> deploying it will make sure there are no conflicts?
>
> one of my concerns is that continuing to add the interface-id bits, is the
> opposite direction of where
> I want us to go.
Unless you want to modify RFC4291 without backward compatibility, I don't see
why using an unused IID range having u=1 could be harmful.
("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").
> I wouldn't object to non-normative language in 4rd suggesting a interface-id
> to use, without
> creating any expectation that new or existing IPv6 implementations have to
> change.
On this, we agree: the fact that 4rd needs no change of existing IPv6
implementations that don't support is key.
The RFC that is needed to reserve a 4rd IID-range despite its being
experimental is, in my understanding, the natural place to make this clear.
> that said, 4rd will work perfectly well _without_ this reservation, so I
> don't buy the argument that
> we're holding up the 4rd work.
As explained in various ways several times, reserving a currently unused IID
range ensure that, when 4rd is activated in customer site, no renumbering of
any RFC-compliant link or host is necessary. Without that, 4rd wouldn't be up
to its objectives.
regards,
RD
>
> cheers,
> Ole
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
