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

[Rémi Després <[e-mail]>]

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: [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 | ? | ? |
>> 
>> 				...
>> 
>> 
>> 
>> 
>> 
>> 
>