On Forwarding 6LoWPAN Fragments over a Multi-Hop IPv6 Network
RFC 8930
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
Show full document text