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

[Wojciech Dec <[e-mail]>]

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

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

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
> of documents).
>

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

-Woj.


>
> 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.htmland 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.htmland other posts.Please add
>>>
>>>  | 17 | Handle ICMP (RFC6145) | Y | n/a | ? | ? |
>>>
>>>  ...
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Softwires mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/softwires
>>>
>>>
>>
>>
>
>