Hello Remi, On 20 July 2011 15:06, Rémi Després <[email protected]> wrote: > > 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.
Well, what it is, and what it looks like is *an IPv6 address* and it is valid, and it is in the 4V6 prefix, so I don't quite see what is the issue you're making out. Are you perhaps thinking of a prefix as being a single 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. As per items 1, 2 and 3 above; the CPE does NOT need to make the distinction you make out. If packets are sent to that address, they get passed to NAT44. Hosts behind the CPE or apps on the CPE will not use/bind to that address. Regards, Woj. > > 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 > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
