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

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

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