Subject: Fragmentation Header text

From: Bob Hinden <[email-masked]>
Date: Fri, 23 Oct 2015 14:35:34 -0700

Hi,

Thinking about a better way to describe how to fragment in rfc2460bis.

The current text uses the term “Unfragmentable Headers”, defined as:

    The Unfragmentable Headers consists of the IPv6 header plus any
    extension headers that must be processed by nodes en route to the
    destination, that is, all headers up to and including the Routing
    header if present, else the Hop-by-Hop Options header if present,
    else no extension headers.

The problem with this term is that it overlaps with including these headers, extension headers, and the upper layer header in the first fragment.  We don’t want to fragment these headers either.  They are all unfragmentable.

One alternative would to use the term “Per-Fragment Headers”.  That is the headers that are included in every fragment.

The text would look something like this:

   The initial, large, unfragmented packet is referred to as the
   "original packet", and it is considered to consist of three parts, as
   illustrated:

   original packet:

   +------------------+-------------------------+---//----------------+
   |  Per-Fragment    | Extention & Upper-Layer |   Fragmentable      |
   |    Headers       |       Headers           |      Part           |
   +------------------+-------------------------+---//----------------+

      The Per-Fragment Headers consists of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

      The Ext Hdrs are all other extension headers that are not included
      in the Unfragmentable headers part of the packet.  For this
      purpose, the Encapsulating Security Payload (ESP) is not
      considered an extension headers.  The Upper-Layer Header is the
      first upper-layer header that is not an IPv6 extension header.
      Examples of upper-layer headers include TCP, UDP, IPv4, IPv6,
      ICMPv6, and as noted ESP.

      The Fragmentable Part consists of the rest of the packet after the
      upper-layer header or after any header (i.e., initial IPv6 header
      or extension header) that contains a Next Header value of No Next
      Header.

   The Fragmentable Part of the original packet is divided into
   fragments, each, except possibly the last ("rightmost") one, being an
   integer multiple of 8 octets long.  The fragments are transmitted in
   separate "fragment packets" as illustrated:

   original packet:

   +-----------------+-----------------+--------+--------+-//-+--------+
   |  Per-Fragment   |Ext & Upper-Layer|  first | second |    |  last  |
   |    Headers      |    Headers      |fragment|fragment|....|fragment|
   +-----------------+-----------------+--------+--------+-//-+--------+

   fragment packets:

   +------------------+---------+-------------------+----------+
   |  Per-Fragment    |Fragment | Ext & Upper-Layer |  first   |
   |    Headers       | Header  |   Headers         | fragment |
   +------------------+---------+-------------------+----------+

   +------------------+--------+-------------------------------+
   |  Per-Fragment    |Fragment|    second                     |
   |    Headers       | Header |   fragment                    |
   +------------------+--------+-------------------------------+
                         o
                         o
                         o
   +------------------+--------+----------+
   |  Per-Fragment    |Fragment|   last   |
   |    Headers       | Header | fragment |
   +------------------+--------+----------+

Please let me know what you think.

Thanks,
Bob

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 24 Oct 2015 11:47:00 +0000

Thanks for this Bob. I think it adds a lot of clarity. 

My only suggestion would be to indicate whether the Fragmentable piece itself may be an IP packet in case of tunneling.
Or should we make it unfragmentable down to the inner header?
This would allow firewalls to look at the inner packet in the first fragment.

Cheers,

Pascal

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Bob Hinden
> Sent: vendredi 23 octobre 2015 23:36
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>
> Subject: Fragmentation Header text
> 
> Hi,
> 
> The problem with this term is that it overlaps with including these headers,
> extension headers, and the upper layer header in the first fragment.  We
> don’t want to fragment these headers either.  They are all unfragmentable.
> 
> One alternative would to use the term “Per-Fragment Headers”.  That is the
> headers that are included in every fragment.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 25 Oct 2015 08:23:46 +1300

On 24/10/2015 10:35, Bob Hinden wrote:
...
> One alternative would to use the term “Per-Fragment Headers”.  That is the headers that are included in every fragment.

Seems reasonable to me. Maybe add a note that they were previously
names “Unfragmentable Headers”.

   Brian

---

From: Bob Hinden <[email-masked]>
Date: Sat, 24 Oct 2015 21:18:23 -0700

> On Oct 24, 2015, at 12:23 PM, Brian E Carpenter <[email-masked]> wrote:
> 

That will be in the appendix listing changes from RFC2460.  My unpublished -01 draft says:

  01) Change terminology in Fragment header section from
      "Unfragmentable Headers" to "Per-Fragment Headers”.

Thanks,
Bob

---

From: Bob Hinden <[email-masked]>
Date: Mon, 26 Oct 2015 09:11:51 -0700

Pasca.

> On Oct 24, 2015, at 4:47 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 

Thanks, I think so too.

> This would allow firewalls to look at the inner packet in the first fragment.

The text includes an IP header in the definition of upper layer headers.  Do you mean an upper-layer header after a second IP header?

Assuming yes, I think one issue (beside going beyond the updating RFC), is why stop with one IP header.

Also, I am not sure it’s our job is to make it easier for Firewalls.  Further, many firewalls want to look at the whole datagram, not just the headers.  If we really want to make fragmentation easier for firewalls, we should deprecate fragmentation, so they can see the whole datagram.  That was proposed a year or two ago, and there wasn’t a lot of interest in the w.g.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Mon, 26 Oct 2015 13:08:25 -0700

Erik,

> On Oct 26, 2015, at 11:02 AM, Erik Nordmark <[email-masked]> wrote:
> 
> On 10/23/15 2:35 PM, Bob Hinden wrote:
>> Hi,
>> 
> My understanding is that RFC2460 does allow fragmenting them.
> For instance, if the sender wants to send IPv6 header plus 2kbyte Destination options header, plus TCP and payload, and the MTU is 1280, then the 2kbyte Destination options header will not appear in its entirety in the first fragment.
> 
> Is that no longer the case?

What you see is a byproduct of RFC7112 update to RFC2460.  That is, a host can’t create fragments if all of the headers including the upper-layer header don't fit into the first fragment.  It doesn’t say it that directly, but it is a consequence of requiring these headers in the first fragment.

> If it has changed, then it might have sense to introduce a term like "first fragment headers" to make it clearer what needs to be in the first fragment.

I had something like that in an earlier rough draft, but ended up removing it as it didn’t help too much.

The current Fragmentation Section (from unpublished draft -01) is included below.  Look at the text that describes the “original packet” through the text describing what is in the first fragment.  This seems clear to me.

> One detail below.
> With your proposed approach I think the "multiple of 8 is incorrect" since the upper-layer headers might not be a multiple of 8.
> What matters is that the fragment payload in all but the last fragment is a multiple of 8, thus for the first fragment "Ext & Upper-layer headers" plus first fragment needs to be a multiple of 8.

Thanks, that’s a good point.  Let me think about how to update the text.  Suggestions?

Bob

>   Erik

From unpublished draft-ietf-6man-rfc2460bis-01.txt
———

4.5.  Fragment Header

   The Fragment header is used by an IPv6 source to send a packet larger
   than would fit in the path MTU to its destination.  (Note: unlike
   IPv4, fragmentation in IPv6 is performed only by source nodes, not by
   routers along a packet's delivery path -- see section 5.)  The
   Fragment header is identified by a Next Header value of 44 in the
   immediately preceding header, and has the following format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  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 [IANA-PN].

      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.

Deering & Hinden         Expires April 26, 2016                [Page 14]
Internet-Draft             IPv6 Specification               October 2015

      Res                 2-bit reserved field.  Initialized to zero for
                          transmission; ignored on reception.

      M flag              1 = more fragments; 0 = last fragment.

      Identification      32 bits.  See description below.

   In order to send a packet that is too large to fit in the MTU of the
   path to its destination, a source node may divide the packet into
   fragments and send each fragment as a separate packet, to be
   reassembled at the receiver.

   For every packet that is to be fragmented, the source node generates
   an Identification value.  The Identification must be different than
   that of any other fragmented packet sent recently* with the same
   Source Address and Destination Address.  If a Routing header is
   present, the Destination Address of concern is that of the final
   destination.

      *  "recently" means within the maximum likely lifetime of a
         packet, including transit time from source to destination and
         time spent awaiting reassembly with other fragments of the same
         packet.  However, it is not required that a source node know
         the maximum packet lifetime.  Rather, it is assumed that the
         requirement can be met by maintaining the Identification value
         as a simple, 32-bit, "wrap-around" counter, incremented each
         time a packet must be fragmented.  It is an implementation
         choice whether to maintain a single counter for the node or
         multiple counters, e.g., one for each of the node's possible
         source addresses, or one for each active (source address,
         destination address) combination.

   original packet:

Deering & Hinden         Expires April 26, 2016                [Page 15]
Internet-Draft             IPv6 Specification               October 2015

      The Ext Hdrs are all other extension headers that are not included
      in the Per-Fragment headers part of the packet.  For this purpose,
      the Encapsulating Security Payload (ESP) is not considered an
      extension headers.  The Upper-Layer Header is the first upper-
      layer header that is not an IPv6 extension header.  Examples of
      upper-layer headers include TCP, UDP, IPv4, IPv6, ICMPv6, and as
      noted ESP.

   original packet:

   fragment packets:

   The first fragment packet is composed of:

Deering & Hinden         Expires April 26, 2016                [Page 16]
Internet-Draft             IPv6 Specification               October 2015

      (1) The Per-Fragment Headers of the original packet, with the
      Payload Length of the original IPv6 header changed to contain the
      length of this fragment packet only (excluding the length of the
      IPv6 header itself), and the Next Header field of the last header
      of the Per-Fragment Headers changed to 44.

      (2) A Fragment header containing:

         The Next Header value that identifies the first header after
         the Per-Fragment Headers of the original packet.

         A Fragment Offset containing the offset of the fragment, in
         8-octet units, relative to the start of the Fragmentable Part
         of the original packet.  The Fragment Offset of the first
         ("leftmost") fragment is 0.

         An M flag value of 1 as this is the first fragment.

         The Identification value generated for the original packet.

      (3) Extension Headers, if any, and the Upper-Layer header.  These
      headers must be in the first fragment.

      (4) The first fragment.

   The subsequent fragment packets are composed of:

      (1) The Per-Fragment Headers of the original packet, with the
      Payload Length of the original IPv6 header changed to contain the
      length of this fragment packet only (excluding the length of the
      IPv6 header itself), and the Next Header field of the last header
      of the Per-Fragment Headers changed to 44.

      (2) A Fragment header containing:

         The Next Header value that identifies the first header after
         the Per-Fragment Headers of the original packet.

         A Fragment Offset containing the offset of the fragment, in
         8-octet units, relative to the start of the Fragmentable part
         of the original packet.

         An M flag value of 0 if the fragment is the last ("rightmost")
         one, else an M flag value of 1.

Deering & Hinden         Expires April 26, 2016                [Page 17]
Internet-Draft             IPv6 Specification               October 2015

         The Identification value generated for the original packet.

      (3) The fragment itself.

   The lengths of the fragments must be chosen such that the resulting
   fragment packets fit within the MTU of the path to the packets'
   destination(s).

   Fragments must not be created that overlap with any other fragments
   created from the original packet.

   At the destination, fragment packets are reassembled into their
   original, unfragmented form, as illustrated:

   reassembled original packet:

   +---------------+-----------------+---------+--------+-//--+--------+
   | Per-Fragment|Ext & Upper-Layer|  first  | second |     | last   |
   |    Headers    |   Headers       |frag data|fragment|.....|fragment|
   +---------------+-----------------+---------+--------+-//--+--------+

   The following rules govern reassembly:

      An original packet is reassembled only from fragment packets that
      have the same Source Address, Destination Address, and Fragment
      Identification.

      The Per-Fragment Headers of the reassembled packet consists of all
      headers up to, but not including, the Fragment header of the first
      fragment packet (that is, the packet whose Fragment Offset is
      zero), with the following two changes:

         The Next Header field of the last header of the Per-Fragment
         Headers is obtained from the Next Header field of the first
         fragment's Fragment header.

         The Payload Length of the reassembled packet is computed from
         the length of the Per-Fragment Headers and the length and
         offset of the last fragment.  For example, a formula for
         computing the Payload Length of the reassembled original packet
         is:

            PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last

Deering & Hinden         Expires April 26, 2016                [Page 18]
Internet-Draft             IPv6 Specification               October 2015

            where
            PL.orig  =  Payload Length field of reassembled packet.
            PL.first =  Payload Length field of first fragment packet.
            FL.first =  length of fragment following Fragment header of
                        first fragment packet.
            FO.last  =  Fragment Offset field of Fragment header of last
                        fragment packet.
            FL.last  =  length of fragment following Fragment header of
                        last fragment packet.

         The Fragmentable Part of the reassembled packet is constructed
         from the fragments following the Fragment headers in each of
         the fragment packets.  The length of each fragment is computed
         by subtracting from the packet's Payload Length the length of
         the headers between the IPv6 header and fragment itself; its
         relative position in Fragmentable Part is computed from its
         Fragment Offset value.

         The Fragment header is not present in the final, reassembled
         packet.

         If any of the fragments being reassembled overlaps with any
         other fragments being reassembled for the same packet,
         reassembly of that packet must be abandoned and all the
         fragments that have been received for that packet must be
         discarded.

         If the fragment is a whole datagram (that is, both the Fragment
         Offset field and the M flag are zero), then it does not need
         any further reassembly and should be processed as a fully
         reassembled packet (i.e., updating Next Header, adjust Payload
         Length, removing the Fragmentation Header, etc.).  Any other
         fragments that match this packet (i.e., the same IPv6 Source
         Address, IPv6 Destination Address, and Fragment Identification)
         should be processed independently.

   The following error conditions may arise when reassembling fragmented
   packets:

      If insufficient fragments are received to complete reassembly of a
      packet within 60 seconds of the reception of the first-arriving
      fragment of that packet, reassembly of that packet must be
      abandoned and all the fragments that have been received for that
      packet must be discarded.  If the first fragment (i.e., the one
      with a Fragment Offset of zero) has been received, an ICMP Time
      Exceeded -- Fragment Reassembly Time Exceeded message should be
      sent to the source of that fragment.

Deering & Hinden         Expires April 26, 2016                [Page 19]
Internet-Draft             IPv6 Specification               October 2015

      If the length of a fragment, as derived from the fragment packet's
      Payload Length field, is not a multiple of 8 octets and the M flag
      of that fragment is 1, then that fragment must be discarded and an
      ICMP Parameter Problem, Code 0, message should be sent to the
      source of the fragment, pointing to the Payload Length field of
      the fragment packet.

      If the length and offset of a fragment are such that the Payload
      Length of the packet reassembled from that fragment would exceed
      65,535 octets, then that fragment must be discarded and an ICMP
      Parameter Problem, Code 0, message should be sent to the source of
      the fragment, pointing to the Fragment Offset field of the
      fragment packet.

      If the first fragment does not include all headers through an
      Upper-Layer header, then that fragment should be discarded and an
      ICMP Parameter Problem, Code 3, message should be sent to the
      source of the fragment, with the Pointer field set to zero.

   The following conditions are not expected to occur, but are not
   considered errors if they do:

      The number and content of the headers preceding the Fragment
      header of different fragments of the same original packet may
      differ.  Whatever headers are present, preceding the Fragment
      header in each fragment packet, are processed when the packets
      arrive, prior to queueing the fragments for reassembly.  Only
      those headers in the Offset zero fragment packet are retained in
      the reassembled packet.

      The Next Header values in the Fragment headers of different
      fragments of the same original packet may differ.  Only the value
      from the Offset zero fragment packet is used for reassembly.