Remi,
>>>> 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).
apologies for being a little flippant.
but that point isn't confirmed.
actually I'm using that space:
otroan@ubuntu:~/src/as$ ifconfig lo
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: 2001:db8::ffff:0:0:1/64 Scope:Global
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:354 errors:0 dropped:0 overruns:0 frame:0
TX packets:354 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:44161 (44.1 KB) TX bytes:44161 (44.1 KB)
otroan@ubuntu:~/src/as$ sudo ip addr add 2001:db8:0000:0000:FFFF::1/64 dev lo
>> 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").
yes, that technology is called ILNP. it does not require globally unique
interface identifiers.
which in any case would have required some sort of registry.
>> 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.
my argument is that you don't need a reservation.
>> 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.
if we agree that the interface-id is just 64bits of nothingness, then there is
no such thing as an unused IID space.
pick whatever you like for the 4rd IID, but your protocol needs to deal with
collisions.
cheers,
Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
