Hi Remi, In terms of 4via6 translation, 4via6 CE can process the received IPv6 packets if the IPv6 destination address is the tunnel end-point address which is assigned to that 4via6 CE and also the IPv6 source address is the IPv4-embedded IPv6 address which is defined in RFC6052. If these condition of IPv6 source and destination address is not matched, 4via6 CE can process the received IPv6 packets as the normal IPv6 packet. So, I don't think there is no issue which you raised.
Thanks, Tetsuya Murakami On 2011/07/19, at 9:53, GangChen wrote: > 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. 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
