Le 20 juil. 2011 à 13:37, Wojciech Dec a écrit : > 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, > Woj. Thanks, Wojciech, for the explanation. Sec 5.5 indeed says "A 4V6 CE will have a "self configured" 4V6 IPv6 interface address, alongside any other SLAAC or DHCPv6 derived addresses, potentially from the same prefix." But it remains that the "self-configured" 4V6 address looks like a valid SLAAC or DHCPv6 assigned address. In my understanding, the problem is that a receiving CE cannot make the difference: - between a source 4V6 address coming from a 4v6 CE and one coming from a non-4V6 CE - between its CE 4V6 address and a real IPv6 destination starting with the assigned IPv6 prefix With "4V6 Encapsulation", making these differences is unnecessary, but with "4V6 Translation" a safe way to recognize IPv4 packets is AFAIK missing. Regards, RD > > > > On 19/07/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
