Le 2012-03-26 à 18:42, Wojciech Dec a écrit : > > > 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,
I didn't write "fragmented" packet, just "complete" packet. CE or BR, to compute a checksum has to process the "complete"contents of the packet. This is by reference to what RFC6145 says, namely: "For UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero), the translator SHOULD provide a configuration function to allow: 1. Dropping the packet and generating a system management event that specifies at least the IP addresses and port numbers of the packet. 2. Calculating an IPv6 checksum and forwarding the packet (which has performance implications)." As regards, fragmented packets, RFC 6145 says: "Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant use in the Internet, and in general will not be translated by the IP/ICMP translator. However, when the translator is configured to forward the packet without a UDP checksum, the fragmented IPv4 UDP packets will be translated." => two questions: a) How do you see this to be configured if a particular configuration isn't imposed by the MAP-T specification? b) If fragmented packets are translated, isn't this as I said incompatible with packet forwarding on the fly (fragment per fragment)? > 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. Allowed, and therefore not mandatory. That's fuzziness in the specification. > 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. See above. With E or U, none of this is a concern. RD > > -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.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
