hi Remi, On Wed, Jul 20, 2011 at 3:28 PM, Rémi Després <[email protected]>wrote:
> > 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.) > Jacni>: You mean the CE IPv6 prefix also serves the native IPv6 users on the LAN side, right? That's not yet been clearly stated, I just found in the 4rd draft, Introduction section, "On the "end-user-facing" (i.e., "LAN") side of a CE, IPv6 and IPv4 are implemented as for any native dual-stack service delivered by the SP. " Cheers, Jacni > > 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 >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
