On 19 March 2012 14:22, Rémi Després <[email protected]> wrote:
> 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. > If those packets are UDP checksum 0, the IPv6 host would either need to be customized, or something else would need to changed/configured on the 4rd-u CE specifically to get that to work for specific IPv6 destinations, while with MAP-t this would be transparent (and not require specific forwarding rules). -Woj. > > 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 > >
_______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
