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

From: Xing Li <[email-masked]>
Date: Fri, 09 Mar 2012 15:17:08 +0800

Hi, Remi,

于 2012/2/10 18:23, Rémi Després 写道:
> Hi Xing,
> Good to have you coming in the (unfinished) technical analysis.
>
> I answered to Ole on his remarks, which you support, but not on 
> the following:
>
> You propose to have a line on "IPv4 to IPv6 communication (single 
> translation) supported", wit
>
> Let me therefore reiterate the wish to see an ISP use case, with its 
> Mapping rules, and with IPv6 prefixes of CEs that illustrate the 
> problem you see.

The CERNET2 is an IPv6-only core network. We provide stateless IPv4/IPv6 
translation between CERNET2 and the IPv4 core network (CERNET). The 
users can either use single translation directly, or add their own 
IPv4/IPv6 translor if double translation is required.

Is this answer your question?

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

---

From: Rémi Després <[email-masked]>
Date: Fri, 9 Mar 2012 14:39:59 +0100

Hi Xing,

Le 2012-03-09 à 08:17, Xing Li a écrit :

>> I answered to Ole on his remarks, which you support, but not on the following:
>> 
>> You propose to have a line on "IPv4 to IPv6 communication (single translation) supported", wit 

>> Let me therefore reiterate the wish to see an ISP use case, with its Mapping rules, and with IPv6 prefixes of CEs that illustrate the problem you see.
> 
> The CERNET2 is an IPv6-only core network. We provide stateless IPv4/IPv6 translation between CERNET2 and the IPv4 core network (CERNET). The users can either use single translation directly, or add their own IPv4/IPv6 translor if double translation is required. 
> 

Not quite, since neither example MAP-T Mapping rules nor assigned IPv6 prefixes are provided, but that may be sufficient so far.

 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?

Regards,
RD

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

---

From: Xing Li <[email-masked]>
Date: Mon, 19 Mar 2012 06:39:05 +0800

Hi, Remi,

于 2012/3/9 21:39, Rémi Després 写道:
>> The CERNET2 is an IPv6-only core network. We provide stateless 
>> IPv4/IPv6 translation between CERNET2 and the IPv4 core network 
>> (CERNET). The users can either use single translation directly, or 
>> add their own IPv4/IPv6 translor if double translation is required.
>>
> Not quite, since neither example MAP-T Mapping rules nor assigned IPv6 
> prefixes are provided, but that may be sufficient so far.
>
>  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.
>  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.

Regards,

xing

>>>> (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.
>>>
>>> ...
>>>
>>>> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.html and 
>>>> other posts.Please add
>>>>

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Mar 2012 14:22:16 +0100

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

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 19 Mar 2012 09:16:15 -0500

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

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: [email-masked] [mailto:[email-masked]] 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).
> 
> 
> 		 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.
> 		 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?
> 
> 
> 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".
> 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.
> 							  |    | 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
> 					(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
> other posts. Please add

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Mar 2012 15:37:25 +0100

Hi, Rajiv,

> 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

---

From: Xing Li <[email-masked]>
Date: Fri, 23 Mar 2012 09:54:53 +0800

Hi, Remi,

于 2012/3/19 21:22, Rémi Després 写道:
> 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).
>
>
>>>  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?
>>
> 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".
> 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.

Sorry, it still a misunderstanding. one BRM per CPE, or ONE IPv6 for host.

Regards,

xing

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 10:13:54 +0100

> Sorry, it still a misunderstanding. one BRM per CPE, or ONE IPv6 for host.

Let me ask again, then, for an example with its mapping rules and IPv4 prefixes.
We can then discuss with facts. Without that "IPv4 to IPv6 communication (single translation) supported" remains a claim, not a feature others can verify.

Thanks,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Fri, 23 Mar 2012 13:46:53 +0100

On 19 March 2012 14:22, Rémi Després <[email-masked]> 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).
>
>
> node, when it receives no 4rd mapping rule, to exercise single translation.
> 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?
>
>
> 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".
>
> 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.

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.

> (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
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Rémi Després <[email-masked]>
Date: Fri, 23 Mar 2012 14:55:05 +0100

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 :

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

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 26 Mar 2012 11:08:49 +0200

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.

-Woj.

On 23 March 2012 14:55, Rémi Després <[email-masked]> wrote:

> 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:
>> work for IPv4 packets" requires special configurations, it cannot do IPv6
>> web caches for non 4rd-H packets.
>>
>>
>>  ...
>>

---

From: Rémi Després <[email-masked]>
Date: Mon, 26 Mar 2012 13:34:42 +0200

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.

In any case, this is not specified yet (one more open issue of the MAP set of documents).

RD

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 26 Mar 2012 18:42:46 +0200

On 26 March 2012 13:34, Rémi Després <[email-masked]> wrote:

> 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

There doesn't seem to be a need to do that as it's already specified in
rfc6145.

-Woj.

>> 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
>>>
>>>
>>>
>>>
>>>
>>> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.htmland other posts.
>>>
>>> http://www.ietf.org/mail-archive/web/softwires/current/msg03324.htmland other posts.Please add
>>>

---

From: Rémi Després <[email-masked]>
Date: Mon, 26 Mar 2012 19:16:04 +0200

Le 2012-03-26 à 18:42, Wojciech Dec a écrit :

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

> 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