Hi Washam,

Please see below.

Le 21 août 2011 à 08:01, Washam Fan a écrit :

> Hi Remi,
> 
> Please see inline.
> 
>>> 7. in example a in section 6, how come a mapping rule responding to 2
>>> cpe ipv6 prefix length? cpe will get confused when it did forwarding.
>> 
>> CPE prefix lengths may be different. (It is the Domain prefix length that is 
>> given in the rule.)
>> This is key to be able to assign port sets of different sizes (including 
>> 64K) to different customers (at least when the CPE-cascade option isn't 
>> necessary).
> 
> Yes. But my concern was, for example, a CPE has the below mapping
> rule, cited from the draft:
>   +--------------------+--------------------+-------------------------+
>   | Domain IPv4 prefix | Domain IPv6 prefix | AFTR IPv6 subnet (e.g.) |
>   +--------------------+--------------------+-------------------------+
>   |     192.32../12    |    2001:db0::/28   | 2001:db0:aaaa:aaaa::/64 |
>   +--------------------+--------------------+-------------------------+
> 
> when the CPE forwards a IPv4 packet whose destincation address is
> within 192.32../12, how the CPE know it will use /48 CE prefix or /52
> CE prefix? Or the mapping rule implies the CPE should use the same CE
> preifx length as its own delegated prefix?

Ah, I think I better understand your question now.

The SRC CPE _doesn't need to know_ the length of the DST CPE IPv6 prefix length.
If this DST length is 48, the DST IPv6 /64 can contain port-derived bits that 
have no effect on the route toward this CPE. (It is reachable at its /48, 
irrespective of bits beyond the /48). 
The DST CPE simply makes NO USE of these extra bits (except possibly to check  
their consistency with the L4 payload).

Does this answer you question?

In any case, I believe that a later version of the draft should contain an 
explanation of that kind, preferably more detailed.
I will work on that.

Thanks for your question.
RD


 

> 
> THanks,
> washam

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

Reply via email to