Hi, Rajiv, Le 2012-03-19 à 15:16, Rajiv Asati (rajiva) a écrit :
> >> 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). > > I see a tremendous value & advantage in standardizing a mechanism (such as > MAP-T (aka dIVI)) that has been in production networks for ~2yrs. 4rd-u is very close to both 4rd-T and 4rd-E (built AFAIK in due knowledge of what they achieve). Its purpose is to makes possible a unified standard that supports not only use cases a la dIVI, but also those of MAP-E (or the reverse depending on one comes from). The real questions is then: - is one standard better than 2? - and if yes, which one is a best IETF choice: MAP-T only, MAP-E only, or 4rd-U only. Is seems you would prefer MAP-T only, but that's for the WG to find a consensus once informed about possible choices. See you next week, RD > > Cheers, > Rajiv > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On >> Behalf Of Rémi Després >> Sent: Monday, March 19, 2012 9:22 AM >> To: Xing Li >> Cc: Softwires WG; Yong Cui; Ralph Droms (rdroms) >> Subject: Re: [Softwires] MAP and 4rd - Relationship with Single translation >> >> 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. >> >> >> 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
