On 26 March 2012 13:34, Rémi Després <[email protected]> wrote:
> > Le 2012-03-26 à 11:08, Wojciech Dec a écrit : > > 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. > > > Are you saying that, when original IPv4 packets have null UDP > checksums, MAP-T would REQUIRE CEs and BRs to recompute UDP checksums of > complete packets? > This would certainly prevent packets containing fragments to be forwarded > on the fly, and would therefore have performance implication. > The fragmented packet case is not what I'm referring to, but rather, the case where regular unfragmented IPv4 UDP checksum 0 packets are sent. As per rfc6145, the checksum recalculation of such packets is allowed. > > In any case, this is not specified yet (one more open issue of the MAP set > of documents). > There doesn't seem to be a need to do that as it's already specified in rfc6145. -Woj. > > RD > > > > -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.htmland >>> 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.htmland >>> 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
