Le 2012-02-07 à 16:24, Satoru Matsushima a écrit :

> On 2012/02/07, at 16:10, Rémi Després wrote:
> 
>> 
>> Le 2012-02-07 à 15:26, Satoru Matsushima a écrit :
>> 
>>> On 2012/02/07, at 14:03, Rémi Després wrote:
>>> 
>>>> 
>>>> Le 2012-02-07 à 13:07, Satoru Matsushima a écrit :
>>>> 
>>>>> Hi Remi-san,
>>>>> 
>>>>> On 2012/02/07, at 11:13, Rémi Després wrote:
>>>>> 
>>>>>> Hello Ole, Tetsuya-san, Wojciech,
>>>>>> 
>>>>>> In a use case described in the 4rd-U draft (sec 5.3), an ISP replaces 
>>>>>> its dual-stack routing by IPv6-only routing.
>>>>>> For this, independently from the number of IPv4 prefixes it has to 
>>>>>> support, it uses only one mapping rule.
>>>>>> (By replacing each IPv4 route by an equivalent IPv6 route, it ensures 
>>>>>> that all customers keep their IPv4 addresses.)
>>>>>> 
>>>>> 
>>>>> I don't think that it could work as you explained in that section. For 
>>>>> example, the BR would need to check a received packet from a CE whether 
>>>>> it has correct source address in mapping rule or not. It means that the 
>>>>> BR must know all address mappings for CE between IPv4 addresses and IPv6 
>>>>> prefixes. Is it correct understanding?
>>>> 
>>>> Ingress filtering of the domain has checked that the IPv6 source starts 
>>>> with the delegated IPv6 prefix, a /112 which includes the IPv4 address. In 
>>>> the 4rd-E case, the BR checks that the source address in the IPv4 header 
>>>> matches that of the IPv6 address. There is therefore no need for the BR to 
>>>> know all IPv4 prefixes. At its IPv4 interface, all received packets start 
>>>> with one of them. At its IPv6 interface, all packets it receives have an 
>>>> embedded address that starts with one of these prefixes. 
>>>> 
>>> 
>>> It looks like that you treat default mapping rule as a basic mapping rule 
>>> to check source address consistency on the BR. It should work,
>> 
>> Yes, thanks.
>> 
>>> and the MAP too.
>> 
>> I don't see that.
>> The bit that, in 4rd-U hub&spoke, is changed for the CE-to-BR direction has 
>> been included precisely to support this case. 
>> Otherwise, packets sent by a CE to another CE would be routed directly to 
>> its destination, without a detour via a BR. 
>> 
> 
> I don't think so. I just mention BR behavior here.

Yes, but AFAIK the solution needs to involve CEs

> You mention CE behavior for whether the bit is set or not.

Yes, please see below.

> 
>> 
>>>>> I think that operators who already deploy such dual-stack network is 
>>>>> supposed that they have address mapping table,
>>>> 
>>>> I would rather suppose that ISPs that have added IPv6-prefix delegation, 
>>>> say /56s, to an existing IPv4 network did it without mixing their IPv6 
>>>> plan with their IPv4 prefixes.
>>>> I am ready, however, to look seriously at individual cases where choices 
>>>> were different.
>>> 
>>> Basically provision MAP CE is based on its delegated IPv6 prefix in 
>>> concept. It is opposed to your case but technically possible.
>> 
>> 
>>> Now I concern that it requires much complicated CE implementation.
>> 
>> All what is required is that CEs set an address bit if hub&spoke topology is 
>> required.
>> 
> 
> So how CE decide to set the bit, and when the CE figure it out?

The CE knows it must set this bit if, and only if, it received at 
initialization a Topology-variant parameter set to Hub&spoke (sec 4.1).
In this case, the CE sets bit 79 to 1 in IPv6 destination addresses of all 
packets it sends.

BTW, this bit should better, for clarity, be given a name, e.g. bit B meaning 
To-BR bit (or whatever better idea one could propose). I plan to do it in the 
next version.
  
RD



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

Reply via email to