Re: [Softwires] 4rd Address Mapping - version-01

[xiaohong deng <[e-mail]>]

> Le 30 sept. 2011 à 01:58, Ole Troan a écrit :
>
>>>> in the general case there is no way to guarantee that a host doesn't
>>>> pick the same IID.
>>>
>>> Well, "no guarantee"...  unless a safe way of doing it is specified!
>>> And this is already the case with 4rd-addmapping-01.
>>> (If you would keep doubts after a careful check, please share your
>>> understanding.)
>>>
>>> The modified format discussed in Beijing with Xing Li, Congxiao Bao, and
>>> Wojciech Dec, to be documented soon, will have the same property.
>>
>> there are no guarantees, and no safe way of doing that.
>> there is no enforcement of global uniqueness of interface ids.
>> e.g. the use of longer than /64 prefixes, manual configuration.
>> you have a high probability of it being unique. and as long as it is only
>> used for pretty printing and troubleshooting, then do you care?
>
> Still, the Modified EUI-64 format of RFC 4291 has been designed to ensure
> unicity of these Universal-scope IIDs.
> True, a user can manually configure an EUI-64 IID that he shouldn't. The
> confusion that results is then his responsibility.
> The same applies if a host behind a 4rd CE configures a 4rd IID: it won't be
> reachable from the Internet.
>
> Possibility of misconfiguration MUST NOT be a reason to give up specifying
> formats that work in absence of misconfigurations (as done with the modified
> EUI-64 format of RFC 4291).

Exatly.  Isn't expecting things still working with misconfigurations a fantasy?

Cheers,
Xiaohong

>
>
>>>> and we'll have to specify how this would work with DAD and proxy ND. I'd
>>>> rather not.
>>>
>>>> left up to the implementor is my suggestion...
>>>
>>> No need for that (see above).
>
> Confirmed because of the above.
>
> Cheers,
> RD