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

From: "Sujay M (sujm)" <[email-masked]>
Date: Mon, 29 Mar 2010 16:04:24 +0530

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. 
 
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. 
 
Similar problem would be there from V6 to v4 fragment translation as
well. 
 
Any suggestions on this would be very helpful.

Thanks
Regards
Sujay .m

---

From: Xing Li <[email-masked]>
Date: Tue, 30 Mar 2010 08:00:14 +0800

Hi, Sujay

Thanks for the comments.

Sujay M (sujm) 写道:
> 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 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.
> 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 

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: "Ramji Vaithianathan (rvaithia)" <[email-masked]>
Date: Mon, 29 Mar 2010 17:41:23 -0700

Hi,

Thanks for the confirmation on this.  For UDP, checksum 0 case is well documented in the draft.  

Can we document the case involving fragmented ICMP packets as well?

Ramji 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xing Li
Sent: Tuesday, March 30, 2010 5:30 AM
To: Sujay M (sujm)
Cc: Xing Li; [email-masked]
Subject: Re: [BEHAVE] ICMPv6 fragment checksum calculation- draft-ietf-behave-v6v4-xlate-12

Hi, Sujay

Thanks for the comments.

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

Regards,

xing, congxiao

---

From: Xing Li <[email-masked]>
Date: Tue, 30 Mar 2010 08:45:18 +0800

> Can we document the case involving fragmented ICMP packets as well?

yes. we will include it in the next upload. xing

---

From: "Ramji Vaithianathan (rvaithia)" <[email-masked]>
Date: Mon, 29 Mar 2010 18:23:48 -0700

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,

Ramji 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xing Li
Sent: Tuesday, March 30, 2010 5:30 AM
To: Sujay M (sujm)
Cc: Xing Li; [email-masked]
Subject: Re: [BEHAVE] ICMPv6 fragment checksum calculation- draft-ietf-behave-v6v4-xlate-12

Hi, Sujay

Thanks for the comments.

Correct.

Regards,

xing, congxiao

---

From: Xing Li <[email-masked]>
Date: Tue, 30 Mar 2010 13:16:11 +0800

> 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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 30 Mar 2010 08:02:56 -0400

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

- Philip

---

From: Xing Li <[email-masked]>
Date: Wed, 31 Mar 2010 07:24:01 +0800

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
>>> 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.
>>>
>>> From: [email-masked] <mailto:[email-masked]>
>>> [mailto:[email-masked]] On Behalf Of Xing Li
>>> Cc: Xing Li; [email-masked] <mailto:[email-masked]>
>>> 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:
>>>
>>> We believe it will not happen, since ICMPv6 should fit in 1280
>>> packet size and only end system can fragment packets.
>>>
>>>> [email-masked] <mailto:[email-masked]>
>>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>