Re: [BEHAVE] ICMPv6 fragment checksum calculation- draft-ietf-behave-v6v4-xlate-12

[Xing Li <[e-mail]>]

Hi,

Philip Matthews 写道:
> It is not clear to me that one can always assume that ICMP packets do
> not get fragmented. Besides the example below, large ICMP packets
> might also occur with the introduction of Multi-part ICMP messages
> [RFC 4884] and the proposed extensions for interface and next-hop
> identification (draft-atlas-icmp-unnumbered-09).

You are right, we cannot always assume that ICMP packets do not get
fragmented. However, these fragmented ICMP packets are not widely used
and have little meaning cross different address families. In addition,
it requires a lot of resources to process. Therefore, it is not worth to
translate them.

regards,

xing, congxiao
>
> - Philip
>
> On 2010-03-30, at 1:16 , Xing Li wrote:
>
>> Ramji Vaithianathan (rvaithia) 写道:
>>> Hi,
>>>
>>> Regarding IPv6 to IPv4 cases, the pkts don't get fragmented on the
>>> intermediate routers, however the end hosts can still fragment the
>>> packets. For example we sometimes do ping with large packet sizes -
>>> an IPv6 end host starts a ping with a large pkts size > path_mtu. In
>>> this case, the originating host fragments this ping (ICMPv6) packet,
>>> we will face the same checksum issue when translating it to ICMPv4
>>> ping packet. Basically ICMPv4 does not have pseudo header for
>>> checksum calculation so length field has to be removed from the
>>> original checksum field. Since the packet is fragmented, again the
>>> translator will have the same issue as in IPv4-->IPv6 case.
>>>
>>> This case may not be common except for the above example.
>>>
>>
>> thanks. this is a special case. we may also add a similar word in IPv6
>> to IPv4 direction.
>>
>> When a stateless translator receives fragmented ICMPv6 packet, the
>> translator SHOULD drop the packet.
>>
>> regards,
>>
>> xing
>>
>>
>>
>>> Thanks,
>>>
>>> Ramji
>>>
>>> -----Original Message-----
>>> From: [e-mail] <mailto:[e-mail]>
>>> [mailto:[e-mail]] On Behalf Of Xing Li
>>> Sent: Tuesday, March 30, 2010 5:30 AM
>>> To: Sujay M (sujm)
>>> Cc: Xing Li; [e-mail] <mailto:[e-mail]>
>>> Subject: Re: [BEHAVE] ICMPv6 fragment checksum calculation-
>>> draft-ietf-behave-v6v4-xlate-12
>>>
>>> Hi, Sujay
>>>
>>> Thanks for the comments.
>>>
>>> Sujay M (sujm) 写道:
>>>
>>>> Hi Folks,
>>>> I have a question on calcluting ICMPv6 checksum in case of fragmented
>>>> packets.
>>>> In case of ICMPv4, the checksum is the 16-bit ones's complement of the
>>>> one's complement sum of the ICMP message starting with the ICMP Type.
>>>> In case of ICMPv6, apart from the ICMP message, a pseudo-header is
>>>> also considered for checksum calculation. This pseudo header consists
>>>> of IP source/desntination address, next-header field and also the L4
>>>> Length (ICMP length in this case).
>>>> In case of V4->v6 translation, when a ICMPv4 packet is recieved by
>>>> translator, apart from translation, translator should re-calculate the
>>>> checksum using the pseudo-header values.
>>>> In ICMP header, there is no L4 length field. According to the IPv6
>>>> RFC, for protocols (such as ICMP) that do not carry their own length
>>>> information, the length used in the pseudo-header is the Payload
>>>> Length from the IPv6 header, minus the length of any extension headers
>>>> present between the IPv6 header and the upper-layer header.
>>>> So for calculation of checksum, pseudo-header length can be derieved
>>>> from IPv6 payload length field.
>>>> However in case of fragmented packets, the IP length would give the
>>>> length of the fragment and not the total ICMP length. Using this
>>>> length would result in wrong checksum calculation in ICMPv6.
>>>> The problem is on how to get the total ICMP length in case of
>>>> fragmented packets for checksum calculation. The translator is unaware
>>>> of number of fragments.
>>>>
>>>
>>> Correct.
>>>
>>>> One option is that translator waits for all fragments, calculate the
>>>> L4 length and calculate the checksum. But it would be too much of
>>>> processing in the translator.
>>>>
>>>
>>> This cannot done in the stateless xlate. A similar case happen for
>>> UDP with zero checksum field. The section 3.5 of the current xlate
>>> document
>>> reads:
>>>
>>> When a stateless translator receives the first fragment of a
>>> fragmented UDP IPv4 packet and the checksum field is zero, the
>>> translator SHOULD drop the packet and generate a system management
>>> event specifying at least the IP addresses and port numbers in the
>>> packet. When it receives fragments other than the first, it SHOULD
>>> silently drop the packet, since there is no port information to log.
>>>
>>> For stateful translator, the handling of fragmented UDP IPv4 packets
>>> with a zero checksum is discussed in
>>> [I-D.ietf-behave-v6v4-xlate-stateful] section 3.1.
>>>
>>> We think the process of fragmented ICMP is similar, except that the
>>> translator should not send the ICMP.
>>>
>>> When a stateless translator receives fragmented ICMP packet, the
>>> translator SHOULD drop the packet.
>>>
>>>
>>>> Similar problem would be there from V6 to v4 fragment translation
>>>> as well.
>>>>
>>> We believe it will not happen, since ICMPv6 should fit in 1280
>>> packet size and only end system can fragment packets.
>>>
>>>> Any suggestions on this would be very helpful.
>>>>
>>>
>>> Our experiments indicate that it is safe for translator to discard
>>> fragmented ICMP packets.
>>>
>>> Regards,
>>>
>>> xing, congxiao
>>>
>>>
>>>> Thanks
>>>> Regards
>>>> Sujay .m
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Behave mailing list
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/behave
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Behave mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/behave
>>>
>>>
>>>
>>
>> _______________________________________________
>> Behave mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/behave
>>
>