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

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

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


> 
> -Woj.
> 
> On 23 March 2012 14:55, Rémi Després <[e-mail]> 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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/softwires
>> 
>> 
> 
>