Le 30 sept. 2011 à 19:20, Ole Troan a écrit :

> Remi,
> 
>>>>> 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).
> 
> that's a property that was highly speculative 15 years ago when it was 
> specified and a property that has never been verified.
> but, let me turn the question around. what are the requirements for a 
> globally unique interface-id? how is it going to be used?
> both for encapsulation and translation?

In both cases, the CE node can recognize 4rd packets, and process them as such, 
without preempting any IID value that might be a legitimate value for a host 
behind the CE.

> is it expected that routers have to make forwarding decisions on an 
> interface-id?

No.
Ordinary routers are concerned with IIDs only on destination links but here, 
like with 6to4 and 6rd, there is no last link where the IID is exploited.

RD




> 
> cheers,
> Ole

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to