Hello Remi, Good question. Thankfully, this is not an issue as answered in Sections 5.4 and 5.5 (and briefly in 5.2) of draft-dec-stateless-4v6, since CPE A would not send non-v4 traffic (e.g. native IPv6 traffic) to CPE-B's 4V6 address.
Allow me to expand, along with giving some background 0. The IPv6 4V6 prefix assigned to the CPE is, say, a /64. The CPE thus may use the same /6r prefix to calculate the 4V6 address, using 4V6 domain parameters, as well as other IPv6 addresses in that prefix using SLAAC, say. As an example: When a suitable 4V6 /64 prefix is advertised in an RA, a 4V6 CPE will configure itself both a 4V6 interface address and a SLAAC address. A similar case applies when DHCP-PD is used. 1. ALL 4V6 systems, without distinction between translation or encapsulation mode, need to use the specific 4V6 IPv6 interface address for their stateless 4V6 function - no other address will do for stateless operation (BTW some may like to call the 4V6 interface a virtual interface). 2. In general, a 4V6 CPE working in translation mode will pass to NAT44 all traffic arriving on the IPv6 4V6 interface - while an encapsulating 4V6 system will pass to NAT44 all encapsulated IPv4 traffic arriving on the IPv6 4V6 interface. In both cases there are restrictions on what can be done on/with the 4V6 interface. Some implementation considerations come to the fore, such as the fact that 4V6 is intended to be a custom CPE function and not a user application on a generic host, ie The CPEs kernel typically needs to support 4V6, and all the above can be accomplished optimally. 3. Traffic originating from IPv6 hosts behind the CPE or sourced by IPv6 apps on the 4V6 CPE itself will use a non 4V6 address as their source address, but from the 4V6 prefix (or its subnet). Hence there is no ambiguity with handling any such IPv6 return traffic. Regards, Wojtek. On 19 July 2011 10:55, Rémi Després <[email protected]> wrote: > 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
