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

[Wojciech Dec <[e-mail]>]

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