Le 20 juil. 2011 à 16:20, Wojciech Dec a écrit : >> ... >> 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,
That's what I meant: Although the 4V6 address was obtained neither with SLAAC nor with DHCPv6, it can't be distinguished from an ordinary SLAA-C of DHCPv6-obtained address. > 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? NO (?!) >> 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. AFAIK, this prohibits using the full CE-assigned IPv6 on the CE LAN side. Such a constraint isn't needed with "4V6 encapsulation". RD > 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
