Hi, Wojciech, Are you suggesting that T would work with IPv4 packets having UDP checksum = 0?
RFC6145 says that IPv4 packets with UDP checksum = 0 are either always discarded, or optionally discarded if not fragmented (with checksum recomputed if not discarded). I don't see: - how this would work with double translation - why anything should be added to U for checksum-less UDP (IPv6-only hosts don't support it anyway). Cheers, RD Le 2012-03-23 à 13:46, Wojciech Dec a écrit : > > > 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
