doc: Add RFC documents

1 files changed, 634 insertions, 0 deletions

diff --git a/doc/rfc/rfc8930.txt b/doc/rfc/rfc8930.txt
new file mode 100644
index 0000000..2833ec6
--- /dev/null
+++ b/doc/rfc/rfc8930.txt
@@ -0,0 +1,634 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                  T. Watteyne, Ed.
+Request for Comments: 8930                                Analog Devices
+Category: Standards Track                                P. Thubert, Ed.
+ISSN: 2070-1721                                            Cisco Systems
+                                                              C. Bormann
+                                                  Universität Bremen TZI
+                                                           November 2020
+
+
+     On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network
+
+Abstract
+
+   This document provides generic rules to enable the forwarding of an
+   IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) fragment
+   over a route-over network.  Forwarding fragments can improve both
+   end-to-end latency and reliability as well as reduce the buffer
+   requirements in intermediate nodes; it may be implemented using RFC
+   4944 and Virtual Reassembly Buffers (VRBs).
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8930.
+
+Copyright Notice
+
+   Copyright (c) 2020 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology
+     2.1.  Requirements Language
+     2.2.  Background
+     2.3.  New Terms
+   3.  Overview of 6LoWPAN Fragmentation
+   4.  Limitations of Per-Hop Fragmentation and Reassembly
+     4.1.  Latency
+     4.2.  Memory Management and Reliability
+   5.  Forwarding Fragments
+   6.  Virtual Reassembly Buffer (VRB) Implementation
+   7.  Security Considerations
+   8.  IANA Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgments
+   Authors' Addresses
+
+1.  Introduction
+
+   The original 6LoWPAN fragmentation is defined in [RFC4944] for use
+   over a single Layer 3 hop, though multiple Layer 2 hops in a mesh-
+   under network is also possible, and was not modified by the update in
+   [RFC6282]. 6LoWPAN operations including fragmentation depend on a
+   link-layer security that prevents any rogue access to the network.
+
+   In a route-over 6LoWPAN network, an IP packet is expected to be
+   reassembled at each intermediate hop, uncompressed, pushed to Layer 3
+   to be routed, and then compressed and fragmented again.  This
+   document introduces an alternate approach called 6LoWPAN Fragment
+   Forwarding (6LFF) whereby an intermediate node forwards a fragment
+   (or the bulk thereof, MTU permitting) without reassembling if the
+   next hop is a similar 6LoWPAN link.  The routing decision is made on
+   the first fragment of the datagram, which has the IPv6 routing
+   information.  The first fragment is forwarded immediately, and a
+   state is stored to enable forwarding the next fragments along the
+   same path.
+
+   Done right, 6LoWPAN Fragment Forwarding techniques lead to more
+   streamlined operations, less buffer bloat, and lower latency.  But it
+   may be wasteful when fragments are missing, leading to locked
+   resources and low throughput, and it may be misused to the point that
+   the end-to-end latency of one packet falls behind that of per-hop
+   reassembly.
+
+   This specification provides a generic overview of 6LFF, discusses
+   advantages and caveats, and introduces a particular 6LFF technique
+   called "Virtual Reassembly Buffer" (VRB) that can be used while
+   retaining the message formats defined in [RFC4944].  Basic
+   recommendations such as the insertion of an inter-frame gap between
+   fragments are provided to avoid the most typical caveats.
+
+2.  Terminology
+
+2.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.2.  Background
+
+   Past experience with fragmentation, e.g., as described in "IPv4
+   Reassembly Errors at High Data Rates" [RFC4963] and references
+   therein, has shown that misassociated or lost fragments can lead to
+   poor network behavior and, occasionally, trouble at the application
+   layer.  That experience led to the definition of the "Path MTU
+   Discovery for IP version 6" [RFC8201] protocol that limits
+   fragmentation over the Internet.
+
+   "IP Fragmentation Considered Fragile" [RFC8900] discusses security
+   threats that are linked to using IP fragmentation.  The 6LoWPAN
+   fragmentation takes place underneath the IP Layer, but some issues
+   described there may still apply to 6LoWPAN fragments (as discussed in
+   further details in Section 7).
+
+   Readers are expected to be familiar with all the terms and concepts
+   that are discussed in "IPv6 over Low-Power Wireless Personal Area
+   Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and
+   Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4
+   Networks" [RFC4944].
+
+   "Multiprotocol Label Switching Architecture" [RFC3031] states that
+   with MPLS,
+
+   |  packets are "labeled" before they are forwarded.  At subsequent
+   |  hops, there is no further analysis of the packet's network layer
+   |  header.  Rather, the label is used as an index into a table which
+   |  specifies the next hop, and a new label.
+
+   The MPLS technique is leveraged in the present specification to
+   forward fragments that actually do not have a network-layer header,
+   since the fragmentation occurs below IP.
+
+2.3.  New Terms
+
+   This specification uses the following terms:
+
+   6LoWPAN Fragment Forwarding Endpoints:  The 6LFF endpoints are the
+      first and last nodes in an unbroken string of 6LFF nodes.  They
+      are also the only points where the fragmentation and reassembly
+      operations take place.
+
+   Compressed Form:  This specification uses the generic term
+      "compressed form" to refer to the format of a datagram after the
+      action of [RFC6282] and possibly [RFC8138] for Routing Protocol
+      for Low-Power and Lossy Network (RPL) [RFC6550] artifacts.
+
+   Datagram_Size:  The size of the datagram in its compressed form
+      before it is fragmented.
+
+   Datagram_Tag:  An identifier of a datagram that is locally unique to
+      the Layer 2 sender.  Associated with the link-layer address of the
+      sender, this becomes a globally unique identifier for the datagram
+      within the duration of its transmission.
+
+   Fragment_Offset:  The offset of a fragment of a datagram in its
+      compressed form.
+
+3.  Overview of 6LoWPAN Fragmentation
+
+   Figure 1 illustrates 6LoWPAN fragmentation.  We assume node A
+   forwards a packet to node B, possibly as part of a multi-hop route
+   between 6LoWPAN Fragment Forwarding endpoints, which may be neither A
+   nor B, though 6LoWPAN may compress the IP header better when they are
+   both the 6LFF and the 6LoWPAN compression endpoints.
+
+                  +---+                     +---+
+           ... ---| A |-------------------->| B |--- ...
+                  +---+                     +---+
+                                 # (frag. 5)
+
+                123456789                 123456789
+               +---------+               +---------+
+               |   #  ###|               |###  #   |
+               +---------+               +---------+
+                  outgoing                incoming
+             fragmentation                reassembly
+                    buffer                buffer
+
+        Figure 1: Fragmentation at Node A, and Reassembly at Node B
+
+   Typically, node A starts with an uncompressed packet and compacts the
+   IPv6 packet using the header compression mechanism defined in
+   [RFC6282].  If the resulting 6LoWPAN packet does not fit into a
+   single link-layer frame, node A's 6LoWPAN sub-layer cuts it into
+   multiple 6LoWPAN fragments, which it transmits as separate link-layer
+   frames to node B.  Node B's 6LoWPAN sub-layer reassembles these
+   fragments, inflates the compressed header fields back to the original
+   IPv6 header, and hands over the full IPv6 packet to its IPv6 layer.
+
+   In Figure 1, a packet forwarded by node A to node B is cut into nine
+   fragments, numbered 1 to 9 as follows:
+
+   *  Each fragment is represented by the '#' symbol.
+
+   *  Node A has sent fragments 1, 2, 3, 5, and 6 to node B.
+
+   *  Node B has received fragments 1, 2, 3, and 6 from node A.
+
+   *  Fragment 5 is still being transmitted at the link layer from node
+      A to node B.
+
+   The reassembly buffer for 6LoWPAN is indexed in node B by:
+
+   *  a unique identifier of node A (e.g., node A's link-layer address).
+
+   *  the Datagram_Tag chosen by node A for this fragmented datagram.
+
+   Because it may be hard for node B to correlate all possible link-
+   layer addresses that node A may use (e.g., short versus long
+   addresses), node A must use the same link-layer address to send all
+   the fragments of the same datagram to node B.
+
+   Conceptually, the reassembly buffer in node B contains:
+
+   *  a Datagram_Tag as received in the incoming fragments, associated
+      with the interface and the link-layer address of node A for which
+      the received Datagram_Tag is unique,
+
+   *  the actual packet data from the fragments received so far, in a
+      form that makes it possible to detect when the whole packet has
+      been received and can be processed or forwarded,
+
+   *  a state indicating the fragments already received,
+
+   *  a Datagram_Size, and
+
+   *  a timer that allows discarding a partially reassembled packet
+      after some timeout.
+
+   A fragmentation header is added to each fragment; it indicates what
+   portion of the packet that fragment corresponds to.  Section 5.3 of
+   [RFC4944] defines the format of the header for the first and
+   subsequent fragments.  All fragments are tagged with a 16-bit
+   "Datagram_Tag", used to identify which packet each fragment belongs
+   to.  Each datagram can be uniquely identified by the sender link-
+   layer addresses of the frame that carries it and the Datagram_Tag
+   that the sender allocated for this datagram.  [RFC4944] also mandates
+   that the first fragment is sent first and with a particular format
+   that is different than that of the next fragments.  Each fragment
+   except for the first one can be identified within its datagram by the
+   datagram-offset.
+
+   Node B's typical behavior, per [RFC4944], is as follows.  Upon
+   receiving a fragment from node A with a Datagram_Tag previously
+   unseen from node A, node B allocates a buffer large enough to hold
+   the entire packet.  The length of the packet is indicated in each
+   fragment (the Datagram_Size field), so node B can allocate the buffer
+   even if the fragment it receives first is not the first fragment.  As
+   fragments come in, node B fills the buffer.  When all fragments have
+   been received, node B inflates the compressed header fields into an
+   IPv6 header and hands the resulting IPv6 packet to the IPv6 layer,
+   which performs the route lookup.  This behavior typically results in
+   per-hop fragmentation and reassembly.  That is, the packet is fully
+   reassembled, then (re-)fragmented, at every hop.
+
+4.  Limitations of Per-Hop Fragmentation and Reassembly
+
+   There are at least two limitations to doing per-hop fragmentation and
+   reassembly.  See [ARTICLE] for detailed simulation results on both
+   limitations.
+
+4.1.  Latency
+
+   When reassembling, a node needs to wait for all the fragments to be
+   received before being able to re-form the IPv6 packet and possibly
+   forwarding it to the next hop.  This repeats at every hop.
+
+   This may result in increased end-to-end latency compared to a case
+   where each fragment is forwarded without per-hop reassembly.
+
+4.2.  Memory Management and Reliability
+
+   Constrained nodes have limited memory.  Assuming a reassembly buffer
+   for a 6LoWPAN MTU of 1280 bytes as defined in Section 4 of [RFC4944],
+   typical nodes only have enough memory for 1-3 reassembly buffers.
+
+   To illustrate this, we use the topology from Figure 2, where nodes A,
+   B, C, and D all send packets through node E.  We further assume that
+   node E's memory can only hold 3 reassembly buffers.
+
+                  +---+       +---+
+          ... --->| A |------>| B |
+                  +---+       +---+\
+                                    \
+                                    +---+    +---+
+                                    | E |--->| F | ...
+                                    +---+    +---+
+                                    /
+                                   /
+                  +---+       +---+
+          ... --->| C |------>| D |
+                  +---+       +---+
+
+             Figure 2: Illustrating the Memory Management Issue
+
+   When nodes A, B, and C concurrently send fragmented packets, all
+   three reassembly buffers in node E are occupied.  If, at that moment,
+   node D also sends a fragmented packet, node E has no option but to
+   drop one of the packets, lowering end-to-end reliability.
+
+5.  Forwarding Fragments
+
+   A 6LoWPAN Fragment Forwarding technique makes the routing decision on
+   the first fragment, which is always the one with the IPv6 address of
+   the destination.  Upon receiving a first fragment, a forwarding node
+   (e.g., node B in an A->B->C sequence) that does fragment forwarding
+   MUST attempt to create a state and forward the fragment.  This is an
+   atomic operation, and if the first fragment cannot be forwarded, then
+   the state MUST be removed.
+
+   Since the Datagram_Tag is uniquely associated with the source link-
+   layer address of the fragment, the forwarding node MUST assign a new
+   Datagram_Tag from its own namespace for the next hop and rewrite the
+   fragment header of each fragment with that Datagram_Tag.
+
+   When a forwarding node receives a fragment other than a first
+   fragment, it MUST look up state based on the source link-layer
+   address and the Datagram_Tag in the received fragment.  If no such
+   state is found, the fragment MUST be dropped; otherwise, the fragment
+   MUST be forwarded using the information in the state found.
+
+   Compared to Section 3, the conceptual reassembly buffer in node B now
+   contains the following, assuming that node B is neither the source
+   nor the final destination:
+
+   *  a Datagram_Tag as received in the incoming fragments, associated
+      with the interface and the link-layer address of node A for which
+      the received Datagram_Tag is unique.
+
+   *  the link-layer address that node B uses as the source to forward
+      the fragments.
+
+   *  the interface and the link-layer address of the next-hop C that is
+      resolved on the first fragment.
+
+   *  a Datagram_Tag that node B uniquely allocated for this datagram
+      and that is used when forwarding the fragments of the datagram.
+
+   *  a buffer for the remainder of a previous fragment left to be sent.
+
+   *  a timer that allows discarding the stale 6LFF state after some
+      timeout.  The duration of the timer should be longer than that
+      which covers the reassembly at the receiving endpoint.
+
+   A node that has not received the first fragment cannot forward the
+   next fragments.  This means that if node B receives a fragment, node
+   A was in possession of the first fragment at some point.  To keep the
+   operation simple and consistent with [RFC4944], the first fragment
+   MUST always be sent first.  When that is done, if node B receives a
+   fragment that is not the first and for which it has no state, then
+   node B treats it as an error and refrains from creating a state or
+   attempting to forward.  This also means that node A should perform
+   all its possible retries on the first fragment before it attempts to
+   send the next fragments, and that it should abort the datagram and
+   release its state if it fails to send the first fragment.
+
+   Fragment forwarding obviates some of the benefits of the 6LoWPAN
+   header compression [RFC6282] in intermediate hops.  In return, the
+   memory used to store the packet is distributed along the path, which
+   limits the buffer-bloat effect.  Multiple fragments may progress
+   simultaneously along the network as long as they do not interfere.
+   An associated caveat is that on a half-duplex radio, if node A sends
+   the next fragment at the same time as node B forwards the previous
+   fragment to node C down the path, then node B will miss it.  If node
+   C forwards the previous fragment to node D at the same time and on
+   the same frequency as node A sends the next fragment to node B, this
+   may result in a hidden terminal problem.  In that case, the
+   transmission from node C interferes at node B with that from node A,
+   unbeknownst to node A.  Consecutive fragments of a same datagram MUST
+   be separated with an inter-frame gap that allows one fragment to
+   progress beyond the next hop and beyond the interference domain
+   before the next shows up.  This can be achieved by interleaving
+   packets or fragments sent via different next-hop routers.
+
+6.  Virtual Reassembly Buffer (VRB) Implementation
+
+   The VRB [LWIG-VRB] is a particular incarnation of a 6LFF that can be
+   implemented without a change to [RFC4944].
+
+   VRB overcomes the limitations listed in Section 4.  Nodes do not wait
+   for the last fragment before forwarding, reducing end-to-end latency.
+   Similarly, the memory footprint of VRB is just the VRB table,
+   reducing the packet drop probability significantly.
+
+   However, there are other caveats:
+
+   Non-zero Packet Drop Probability:  The abstract data in a VRB table
+      entry contains at a minimum the link-layer address of the
+      predecessor and the successor, the Datagram_Tag used by the
+      predecessor, and the local Datagram_Tag that this node will swap
+      with it.  The VRB may need to store a few octets from the last
+      fragment that may not have fit within MTU and that will be
+      prepended to the next fragment.  This yields a small footprint
+      that is 2 orders of magnitude smaller, compared to needing a
+      1280-byte reassembly buffer for each packet.  Yet, the size of the
+      VRB table necessarily remains finite.  In the extreme case where a
+      node is required to concurrently forward more packets than it has
+      entries in its VRB table, packets are dropped.
+
+   No Fragment Recovery:  There is no mechanism in VRB for the node that
+      reassembles a packet to request a single missing fragment.
+      Dropping a fragment requires the whole packet to be resent.  This
+      causes unnecessary traffic, as fragments are forwarded even when
+      the destination node can never construct the original IPv6 packet.
+
+   No Per-Fragment Routing:  All subsequent fragments follow the same
+      sequence of hops from the source to the destination node as the
+      first fragment, because the IP header is required in order to
+      route the fragment and is only present in the first fragment.  A
+      side effect is that the first fragment must always be forwarded
+      first.
+
+   The severity and occurrence of these caveats depend on the link layer
+   used.  Whether they are acceptable depends entirely on the
+   requirements the application places on the network.
+
+   If the caveats are present and not acceptable for the application,
+   alternative specifications may define new protocols to overcome them.
+   One example is [RFC8931], which specifies a 6LFF technique that
+   allows the end-to-end fragment recovery between the 6LFF endpoints.
+
+7.  Security Considerations
+
+   An attacker can perform a Denial-of-Service (DoS) attack on a node
+   implementing VRB by generating a large number of bogus "fragment 1"
+   fragments without sending subsequent fragments.  This causes the VRB
+   table to fill up.  Note that the VRB does not need to remember the
+   full datagram as received so far but only possibly a few octets from
+   the last fragment that could not fit in it.  It is expected that an
+   implementation protects itself to keep the number of VRBs within
+   capacity, and that old VRBs are protected by a timer of a reasonable
+   duration for the technology and destroyed upon timeout.
+
+   Secure joining and the link-layer security that it sets up protects
+   against those attacks from network outsiders.
+
+   "IP Fragmentation Considered Fragile" [RFC8900] discusses security
+   threats and other caveats that are linked to using IP fragmentation.
+   The 6LoWPAN fragmentation takes place underneath the IP Layer, but
+   some issues described there may still apply to 6LoWPAN fragments.
+
+   *  Overlapping fragment attacks are possible with 6LoWPAN fragments,
+      but there is no known firewall operation that would work on
+      6LoWPAN fragments at the time of this writing, so the exposure is
+      limited.  An implementation of a firewall SHOULD NOT forward
+      fragments but instead should recompose the IP packet, check it in
+      the uncompressed form, and then forward it again as fragments if
+      necessary.  Overlapping fragments are acceptable as long as they
+      contain the same payload.  The firewall MUST drop the whole packet
+      if overlapping fragments are encountered that result in different
+      data at the same offset.
+
+   *  Resource-exhaustion attacks are certainly possible and a sensitive
+      issue in a constrained network.  An attacker can perform a DoS
+      attack on a node implementing VRB by generating a large number of
+      bogus first fragments without sending subsequent fragments.  This
+      causes the VRB table to fill up.  When hop-by-hop reassembly is
+      used, the same attack can be more damaging if the node allocates a
+      full Datagram_Size for each bogus first fragment.  With the VRB,
+      the attack can be performed remotely on all nodes along a path,
+      but each node suffers a lesser hit.  This is because the VRB does
+      not need to remember the full datagram as received so far but only
+      possibly a few octets from the last fragment that could not fit in
+      it.  An implementation MUST protect itself to keep the number of
+      VRBs within capacity and to ensure that old VRBs are protected by
+      a timer of a reasonable duration for the technology and destroyed
+      upon timeout.
+
+   *  Attacks based on predictable fragment identification values are
+      also possible but can be avoided.  The Datagram_Tag SHOULD be
+      assigned pseudorandomly in order to reduce the risk of such
+      attacks.  A larger size of the Datagram_Tag makes the guessing
+      more difficult and reduces the chances of an accidental reuse
+      while the original packet is still in flight, at the expense of
+      more space in each frame.  Nonetheless, some level of risk remains
+      because an attacker that is able to authenticate to and send
+      traffic on the network can guess a valid Datagram_Tag value, since
+      there are only a limited number of possible values.
+
+   *  Evasion of Network Intrusion Detection Systems (NIDSs) leverages
+      ambiguity in the reassembly of the fragment.  This attack makes
+      little sense in the context of this specification since the
+      fragmentation happens within the Low-Power and Lossy Network
+      (LLN), meaning that the intruder should already be inside to
+      perform the attack.  NIDS systems would probably not be installed
+      within the LLN either but rather at a bottleneck at the exterior
+      edge of the network.
+
+8.  IANA Considerations
+
+   This document has no IANA actions.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
+              over Low-Power Wireless Personal Area Networks (6LoWPANs):
+              Overview, Assumptions, Problem Statement, and Goals",
+              RFC 4919, DOI 10.17487/RFC4919, August 2007,
+              <https://www.rfc-editor.org/info/rfc4919>.
+
+   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
+              "Transmission of IPv6 Packets over IEEE 802.15.4
+              Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
+              <https://www.rfc-editor.org/info/rfc4944>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+9.2.  Informative References
+
+   [ARTICLE]  Tanaka, Y., Minet, P., and T. Watteyne, "6LoWPAN Fragment
+              Forwarding", IEEE Communications Standards Magazine, Vol.
+              3, Issue 1, pp. 35-39, DOI 10.1109/MCOMSTD.2019.1800029,
+              March 2019,
+              <https://ieeexplore.ieee.org/abstract/document/8771317>.
+
+   [LWIG-VRB] Bormann, C. and T. Watteyne, "Virtual reassembly buffers
+              in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-
+              lwig-6lowpan-virtual-reassembly-02, 9 March 2020,
+              <https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-
+              virtual-reassembly-02>.
+
+   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+              Label Switching Architecture", RFC 3031,
+              DOI 10.17487/RFC3031, January 2001,
+              <https://www.rfc-editor.org/info/rfc3031>.
+
+   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
+              Errors at High Data Rates", RFC 4963,
+              DOI 10.17487/RFC4963, July 2007,
+              <https://www.rfc-editor.org/info/rfc4963>.
+
+   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
+              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
+              DOI 10.17487/RFC6282, September 2011,
+              <https://www.rfc-editor.org/info/rfc6282>.
+
+   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
+              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
+              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
+              Low-Power and Lossy Networks", RFC 6550,
+              DOI 10.17487/RFC6550, March 2012,
+              <https://www.rfc-editor.org/info/rfc6550>.
+
+   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
+              "IPv6 over Low-Power Wireless Personal Area Network
+              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
+              April 2017, <https://www.rfc-editor.org/info/rfc8138>.
+
+   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
+              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
+              DOI 10.17487/RFC8201, July 2017,
+              <https://www.rfc-editor.org/info/rfc8201>.
+
+   [RFC8900]  Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
+              and F. Gont, "IP Fragmentation Considered Fragile",
+              BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020,
+              <https://www.rfc-editor.org/info/rfc8900>.
+
+   [RFC8931]  Thubert, P., Ed., "IPv6 over Low-Power Wireless Personal
+              Area Network (6LoWPAN) Selective Fragment Recovery",
+              RFC 8931, DOI 10.17487/RFC8931, November 2020,
+              <https://www.rfc-editor.org/info/rfc8931>.
+
+Acknowledgments
+
+   The authors would like to thank Carles Gomez Montenegro, Yasuyuki
+   Tanaka, Ines Robles, and Dave Thaler for their in-depth review of
+   this document and suggestions for improvement.  Many thanks to
+   Georgios Papadopoulos and Dominique Barthel for their contributions
+   during the WG activities.  And many thanks as well to Roman Danyliw,
+   Barry Leiba, Murray Kucherawy, Derrell Piper, Sarah Banks, Joerg Ott,
+   Francesca Palombini, Mirja Kühlewind, Éric Vyncke, and especially
+   Benjamin Kaduk for their constructive reviews through the IETF last
+   call and IESG process.
+
+Authors' Addresses
+
+   Thomas Watteyne (editor)
+   Analog Devices
+   32990 Alvarado-Niles Road, Suite 910
+   Union City, CA 94587
+   United States of America
+
+   Email: thomas.watteyne@analog.com
+
+
+   Pascal Thubert (editor)
+   Cisco Systems, Inc
+   Building D
+   45 Allee des Ormes - BP1200
+   06254 Mougins - Sophia Antipolis
+   France
+
+   Phone: +33 497 23 26 34
+   Email: pthubert@cisco.com
+
+
+   Carsten Bormann
+   Universität Bremen TZI
+   Postfach 330440
+   D-28359 Bremen
+   Germany
+
+   Phone: +49-421-218-63921
+   Email: cabo@tzi.org