Le 19 juil. 2011 à 21:18, Tetsuya Murakami a écrit : > Hi Remi, > > In terms of 4via6 translation, 4via6 CE can process the received IPv6 packets > if the IPv6 destination address is the tunnel end-point address which is > assigned to that 4via6 CE and also the IPv6 source address is the > IPv4-embedded IPv6 address which is defined in RFC6052. If these condition of > IPv6 source and destination address is not matched, 4via6 CE can process the > received IPv6 packets as the normal IPv6 packet.
Then if CE A sends an IPv6 packet to CE B, it will be processed there as a received IPv4 packet. Right? (Please, see also my answer to Gang.) Regards, RD > So, I don't think there is no issue which you raised. > > Thanks, > Tetsuya Murakami > > On 2011/07/19, at 9:53, GangChen wrote: > >> 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 > > _______________________________________________ > Softwires mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/softwires _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
