Subject: Re: Fragmentation Header text

From: Bob Hinden <[email-masked]>
Date: Mon, 2 Nov 2015 18:47:07 +0900

Erik,

>> I am thinking of addressing the issues, by moving up the text (shown above) about the lengths fragments before the fragmentation procedure is described, and expand it to describe the error condition (the first fragment with all of the headers doesn’t fit), and that the whole fragment needs to be a multiple of eight bytes, instead of just the fragment part.  In the worst case of all of the headers end up at the MTU size.  In practice that’s unlikely.
>> 
>> I will take a cut at this and see how it looks.
> 
> OK
> 

My proposed changes to the text is:

   The Fragmentable Part of the original packet is divided into
   fragments.  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).  Each complete fragment, except possibly the
   last ("rightmost") one, being an integer multiple of 8 octets long.

This consolidated the text about size of fragments in one place.

and

      (3) Extension Headers, if any, and the Upper-Layer header.  These
      headers must be in the first fragment.  Note: This restricts the
      size of the headers through the Upper-Layer header to the MTU of
      the path to the packets' destinations(s).

This noted the restriction that the size of the headers in the first fragment.

Thanks,
Bob

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 29 Oct 2015 23:25:39 -0700

On 10/26/15 1:08 PM, Bob Hinden wrote:
>> 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,

It seems to me that it would be easiest to describe the constraint of 
which headers must be in the first fragment separately from the process 
of carving up the packets (into multiples of 8, and with per-fragment 
headers).

The reason for that is that if some of those headers don't fit in the 
packet, it is an error and the packet can't be sent, which is is a check 
compared to the fragment layout aspect.

Note that there is also an implicit check that all of the per-fragment 
headers fit in the MTU; don't know if the text currently makes that 
explicit. Might make sense to group that checks together with the first 
fragment check.

    Erik

>
> 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.
>
>     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
>
>
>
> Deering & Hinden         Expires April 26, 2016                [Page 15]
> Internet-Draft             IPv6 Specification               October 2015
>
>
>        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 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.
>
>        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.
>
>     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 |
>     +------------------+--------+----------+
>
>     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.
>
>        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.
>
>
>

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 2 Nov 2015 12:47:31 +0900

On 10/31/15 12:02 AM, Bob Hinden wrote:
> It does:
Bob,

That sentence doesn't say what happens when they don't fit.
But I don't know if we need to improve on that aspect of the text as 
part of this effort.

> I think it does this, it first describes the three parts of the original including which headers need to be there, then has the text for the first and subsequent packets.
>

OK

Thanks,
    Erik

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