Re: [Softwires] MAP and 4rd - Relationship with Single translation

["Rajiv Asati (rajiva)" <[e-mail]>]

> 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. 

Cheers,
Rajiv

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 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 | ? | ? |
> 
> 				...
> 
> 
> 
> 
> 
>