With the checksum re-computed, as per the rfc6145 option, translated IPv6 packets would get the right checksum. With 4rd-u so far I see no such option.
-Woj. On 23 March 2012 14:55, Rémi Després <[email protected]> wrote: > 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
