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, and the MAP too.


>> 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. 

cheers,
--satoru

> 
> Regards,
> RD
> 
> 
> 
>> they can provision each CE individually, and also they are capable to 
>> distribute the default mapping rule since they should install it into the 
>> CEs. In that situation, what's the motivation of why the operator want to 
>> provision with only default mapping rule?
>> 
>> cheers,
>> --satoru
>> 
>>> For this to work, the 4rd-U draft has a bit that, in the hub&spoke case, 
>>> differs between CE-to-BR and BR-to-CE directions. Thus, packets sent to a 
>>> CE take different routes depending on whether sent by a CE or a BR.
>>> 
>>> I don't see how the equivalent could work with the MAP documents you edited.
>>> Is it that such a use case is out of scope for MAP?
>>> Or did I miss something?
>>> 
>>> Cheers,
>>> RD
>>> 
>>> _______________________________________________
>>> Softwires mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/softwires
>> 
> 

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

Reply via email to