> I am well aware of this, but this doesn't explain why 4rd mapping rules > similar > to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 communication > (single translation) supported". > > > As said in RFC6219, CERNET hosts have their IPv6 addresses configured "via > manual configuration or stateful autoconfiguration via DHCPv6". > Hosts can therefore be assigned Interface IDs that have the 4rd-u format (with > V octet and CNP).
I see a tremendous value & advantage in standardizing a mechanism (such as MAP-T (aka dIVI)) that has been in production networks for ~2yrs. Cheers, Rajiv > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Rémi Després > Sent: Monday, March 19, 2012 9:22 AM > To: Xing Li > Cc: Softwires WG; Yong Cui; Ralph Droms (rdroms) > Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation > > Hi, Xing, > > I look forward to face to face discussions in Paris if we don't clarify > everything > before that (I will be busy on something else in the next 3 days). > > > Le 2012-03-18 à 23:39, Xing Li a écrit : > ... > > > > A key point is that 4rd doesn't prevent a 4rd-capable dual- > stack CE node, when it receives no 4rd mapping rule, to exercise single > translation. > Actually, I believe that using for this the BIH of RFC6535 is > both sufficient and recommendable. > Translated IPv4 packets, because they are sent from CE nodes > to DNS64 synthesized addresses, are appropriately routed to their > destinations. > (It can be via the NAT64-CGN if needed, or via more direct paths if possible.) > Anything missed? > > > Sorry, this is a misunderstanding. > Hint: Single translation and double translation are based on the same > mapping rule in the CERNET2 deployment. > > > > I am well aware of this, but this doesn't explain why 4rd mapping rules > similar > to those of CERNET2 wouldn't have, like MAP-T, "IPv4 to IPv6 communication > (single translation) supported". > > > As said in RFC6219, CERNET hosts have their IPv6 addresses configured "via > manual configuration or stateful autoconfiguration via DHCPv6". > Hosts can therefore be assigned Interface IDs that have the 4rd-u format (with > V octet and CNP). > > > Now, when both addresses happen to be checksum neutral, RFC6145 > translation doesn't modify L4 data, so that it doesn't matter whether the DS > node has used 4rd-u header mapping or single translation. > Thus, IPv6-only hosts can exchange packets with IPv4 applications of 4rd CE > nodes. > > > Regards, > RD > > > > > > > > > > > > > > > > Regards, > > xing > > > > > > Regards, > RD > > > > > > > Regards, > > xing > > > > > > Regards, > RD > > > > > > Le 2012-02-10 à 04:28, Xing Li a écrit : > ... | | | | | > > | 5 | IPv6 web > caches work for IPv4 | Y | N | Y | N | > | | packets > | | | | | > > suggest you rename to "IPv4 > to IPv6 communication (single translation) supported" > > > > (2) More clarification should be added > here. I am not sure 4rd-H can support single translation. > > (a) According to (1), 4rd-H does not > perform header translation defined by RFC6145. > > (b) In the softwire mailing list, it > seems > that 4rd-H cannot support single translation. See the thread containing > http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and > other posts. > > (c) If 4rd-H cannot support single > translation, then "IPv6 web caches work for IPv4 packets" requires special > configurations, it cannot do IPv6 web caches for non 4rd-H packets. > > > > ... > > > (5) I would like to see the details of > how 4rd-H handles ICMP and ICMP error messages. In the softwire mailing list > there were some discussions. See the thread containing > http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and > other posts. Please add > > > | 17 | Handle ICMP (RFC6145) | Y | > n/a | ? | ? | > > ... > > > > > > _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
