Subject: What is an IPv6 fragment?

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 22 Jun 2007 12:22:34 -0700

Hi,

I had raised this earlier in December 2005
http://www1.ietf.org/mail-archive/web/ipv6/current/msg06020.html .

The definition of IPv6 fragment is not clear.  Infact different
protocols assume it differently, example are IPsec and SIIT. I do not
have implementations to play with, however I feel we need to close
this issue along with other related issues, like tiny fragments. The
discussion there was:

"
Vishwas Manral wrote:

I have a doubt regarding the fragment header. Why do we need the M
flag in the "fragment header" at all for IPv6? Having the fragment
header itself would tell it's a fragment and would distinguish between
the first fragment and a non-fragment.

In IPv4 we did not have a fragment header, so the M flag was logical
to have for distinguishing the first and a non fragment.

That said; how should the case where we have the fragment header and
both the Fragment Offset and the M flag is 0 be treated?"

Thanks,
Vishwas

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Vlad Yasevich <[email-masked]>
Date: Fri, 22 Jun 2007 16:15:52 -0400

> this issue along with other related issues, like tiny fragments. The

Well,  SIIT doesn't provide definition for the IPv6 fragment.  It simply
adds some special cases to handling the fragment header under SIIT conditions.

> the first fragment and a non-fragment.

How do you tell the terminating fragment from a non-terminating one without
an M bit.

> both the Fragment Offset and the M flag is 0 be treated?"

Handle it as a self-terminating fragment, ie. you reassembly queue is
1 fragment long.  This simply follows the spec as written.

-vlad

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 22 Jun 2007 16:44:40 -0400

Hi Vishwas,
   I do not really see what the problem is. The M bit is required for 
two reasons

1) It is required for the length calculation of the final reassembled 
packet.
2) It is used for validity checking of fragment lengths (i.e. Non final 
fragments must be a multiple of 8 octets in length)

A fragment with offset 0 and M flag 0 is just treated as the ONLY 
fragment. No harm done.

Cheers
Suresh

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 22 Jun 2007 14:00:04 -0700

Hi Suresh/ Vlad,

For SIIT the fragment header is used to signal the ability to
fragment, it does not state it is a fragment itself.

> fragment. No harm don
But there are different policies for fragments, including some that
drop fragments. It is not the correct behavior, I feel the definition
of a fragment should be clarified.

Thanks,
Vishwas

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 25 Jun 2007 13:37:09 -0400

> fragment, it does not state it is a fragment itself.

First, this only happens when the IPv4 host does not support path mtu
discovery (DF bit is 0).  In this case, inserting a fragment header
at the translator in essence performs the fragmentation that was
requested by the sender.  I just so happens that in this case the
fragment might have offset and M flag set to 0.

> of a fragment should be clarified.

Now you are getting in policies outside of the definition.  The definition
does not have to encompass all eventual uses.  Otherwise we'll be updating
a lot more specs.

-vlad

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 25 Jun 2007 12:39:41 -0700

Hi Vlad,

Thanks a lot for your clarification, maybe I am unclear. I am
attaching a document I have attached, just have a look.

> fragment might have offset and M flag set to 0.
There are 2 sides of the problem. The first is that different
protocols use different definition of a fragment, which needs to be
clarified, because some assumption by a protocol may not work in many
cases due to the specification clarity. The second part is the use of
different policies for fragments.

The idea I am stating is that one spec uses the Fragment header to
just signal its ability to perform fragmentation, while others
specs(AH & ESP for one) clearly lay down a differnet way for
identifying an IPv6 fragment and its subsequent treatment. As there
are different policies for fragments, the signaling may not work in
many cases(no I am not talking about policies but the clarification of
the term Fragment - example a Fragment with M = 0 and Offset = 0
should be treated as a non fragmented packet). I do not see any
problem  in clarifying exactly what an IPv6 fragment is so that we can
have a consistent set of specs as well as implementations.

> does not have to encompass all eventual uses.  Otherwise we'll be updating
No, I am talking about specs too besides practical network scenarios.
If we see a problem in a spec I do not see a reason we should hesitate
in fixing the problems (and its not unprecedented either).

Thanks,
Vishwas

---

From: Vlad Yasevich <[email-masked]>
Date: Mon, 25 Jun 2007 16:07:55 -0400

Hi Vishwas

I think you are reading too much into this, thus the issue is confused.

Vishwas Manral wrote:
> just signal its ability to perform fragmentation,

No, it does in fact fragment the packets.  It just so happens that it may
result in a single fragment. The behavior here is not much different from
some node on path returning ICMP Too Big with MTU less the 1280.

The fragment is there to make translators work so that the translation
of the DF bit is not lost while the IPv4 packet is traversing an IPv6
network.

> while others

Ok, so are you concerned with what IPSec considers a fragment and how
individual IPSec policies treat those fragments?

> 
> 2. IPv6 Fragment
> 
>    The IPv6 specification [RFC2460] defines a fragment header as:
> 
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Next Header  |   Reserved    |      Fragment Offset    |Res|M|
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                         Identification                        |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>    Next Header          8-bit selector.  Identifies the initial header
>                         type of the Fragmentable Part of the original
>                         packet (defined below).  Uses the same values as
>                         the IPv4 Protocol field [RFC-1700 et seq.].
> 
>    Reserved             8-bit reserved field.  Initialized to zero for
>                         transmission; ignored on reception.
> 
>    Fragment Offset      13-bit unsigned integer.  The offset, in 8-octet
>                         units, of the data following this header,
>                         relative to the start of the Fragmentable Part
>                         of the original packet.
> 
>    Res                  2-bit reserved field.  Initialized to zero for
>                         transmission; ignored on reception.
> 
>    M flag               1 = more fragments; 0 = last fragment.
> 
>    Identification       32 bits is used for facilitating each fragment is 
>                         correctly reassembled at the receiver.
> 
>    An IPv6 fragment is defined to be an IPv6 packet, which contains the IPv6
>    Fragment header as described above, having either the More flag or the 
>    Fragment Offset set to have a non 0 value.

Well, that's not quite right, since the middle fragments will have both
a non-zero offset and More flag set.

What the statement from you draft implies is that one or the other may be omitted,
which is not the case.

> 
> 
> 
> 
> Manral, et al.         Expires December 25, 2007                    [Page 3]
>  
> Internet-Draft                 IPv6  Fragments                  June 2007
> 
> 
>    In turn if an IPv6 packet contains a fragment header, with both the More 
>    flag as well as the Fragment Offset fields set to, it is treated exactly 
>    like an IPv6 packet without the Fragment header.

This seems like a clarification that might be useful.

-vlad