Le 2013-01-30 à 14:34, Ole Troan <otr...@employees.org> a écrit :
> 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.
Your apologies are welcome (see below).
> 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
Independently of the above details, address 2001:db8::ffff:0:0:1 isn't an
RFC4269-compliant address! (My sentence was only about RFC4269 addresses.)
Incidentally:
- Note that the particular IID of this address has no conflict with the
proposed 4rd IID range. It can coexist without any risk.
- Why don't you ask for reserving this IID for your particular application?
This would eliminate the risk of someone else taking the same for another
manual configuration (i.e. one that DAD doesn't repair).
>>> 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.
ILNP, which has u=0.
Out of 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.
>
> 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.
We don't agree that what is in RFC 4291 should be ignored.
> pick whatever you like for the 4rd IID, but your protocol needs to deal with
> collisions.
Not AFAIK, but since 4rd is intended to be experimental, this will be verified
anyway.
If you have identified a detailed configuration which would suffer from
collisions, I hope you will submit it to Softwire for the 6 4rd-draft authors
to look at it.
Let me wonder when you will stop introducing in 6man new arguments against 4rd
operation.
RD
>
> cheers,
> Ole
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
