Le 19 juil. 2011 à 18:53, GangChen a écrit :

> Hello Remi,
> 
> I guess 4V6 CE need to recognize whether received IPv6 prefix is CE
> IPv6 prefix, which is used to generate a shared IPv4 address.

You apparently assume that the receiving CE has two IPv6 prefixes, with one 
reserved for shared IPv4 addresses.
This is possible but, AFAIK, isn't required in 4V6T (and isn't needed in 4V6E).

If 4V6T CE's would be required to have two IPv6 prefixes (or as a minimum two 
different addresses), this would become an operational constraint to be 
considered when comparing the two solutions.

Regards,
RD
  
> Then, it
> should be no problem to distinguish native IPv6 or an IPv6 address CE
> should translated.
> 
> Gang
> 
> 2011/7/19, Rémi Després <[email protected]>:
>> Hi, all,
>> 
>> 1.
>> The translation-based stateless solution for IPv4 via IPv6 described in
>> draft-murakami-softwire-4v6-translation-00 seems to have a significant
>> limitation:
>> - When a 4V6T customer-edge node receives a packet from a CE of the same
>> 4V6T domain, it doesn't know whether it must treat it as a native IPv6
>> packet from this CE or as an IPv4 packet that this CE has translated.
>> 
>> 
>>        <-- 4V6T domain -->   <-- IPv4 Internet --
>> 
>> (A) 4V6T CE |---->----.
>>                      |
>>                      V---- 4v6T-BR --- - - -
>>                      |
>> (B) 4V6T CE |----<----'
>>        <= v4 or v6 ??
>> 
>> For instance, if the IPv4 address of (B) is shared, (B) doesn't know whether
>> received packets must go to its internal NAT44, or be treated a real IPv6
>> packet.
>> (Sending to the NAT44 packets whose ports are currently bound in the NAT44
>> wouldn't be satisfactory: all ports may be used in IPv6).
>> 
>> 2.
>> Note that this problem doesn't apply to the encapsulation-based stateless
>> solution (4V6E):
>> - A 4V6E CE treats a received IPv6 packet as containing an IPv4 packet if,
>> and only if, its Next header is IP-in-IP, and the encapsulated packet is
>> IPv4. There is no ambiguity.
>> 
>> => Unless something is wrong in the above, or a palliative is devised,
>> consideration of this should be added to the comparative analysis of 4V6T
>> and 4V6E solutions (draft-dec-stateless-4v6).
>> 
>> 
>> Regards,
>> 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


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

Reply via email to