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
