draft-ietf-6lo-minimal-fragment-13.txt   draft-ietf-6lo-minimal-fragment-14.txt 
6lo T. Watteyne, Ed. 6lo T. Watteyne, Ed.
Internet-Draft Analog Devices Internet-Draft Analog Devices
Intended status: Standards Track P. Thubert, Ed. Intended status: Standards Track P. Thubert, Ed.
Expires: 6 September 2020 Cisco Systems Expires: 10 September 2020 Cisco Systems
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
5 March 2020 9 March 2020
On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network
draft-ietf-6lo-minimal-fragment-13 draft-ietf-6lo-minimal-fragment-14
Abstract Abstract
This document provides generic rules to enable the forwarding of This document provides generic rules to enable the forwarding of
6LoWPAN fragment over a route-over network. Forwarding fragments can 6LoWPAN fragment over a route-over network. Forwarding fragments can
improve both the end-to-end latency and reliability, and reduce the improve both the end-to-end latency and reliability, and reduce the
buffer requirements in intermediate nodes; it may be implemented buffer requirements in intermediate nodes; it may be implemented
using RFC 4944 and virtual reassembly buffers. using RFC 4944 and virtual reassembly buffers.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 6 September 2020. This Internet-Draft will expire on 10 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 39 skipping to change at page 2, line 39
The original 6LoWPAN fragmentation is defined in [RFC4944] for use The original 6LoWPAN fragmentation is defined in [RFC4944] for use
over a single Layer 3 hop, though possibly multiple Layer 2 hops in a over a single Layer 3 hop, though possibly multiple Layer 2 hops in a
mesh-under network, and was not modified by the [RFC6282] update. mesh-under network, and was not modified by the [RFC6282] update.
6LoWPAN operations including fragmentation depend on a Link-Layer 6LoWPAN operations including fragmentation depend on a Link-Layer
security that prevents any rogue access to the network. security that prevents any rogue access to the network.
In a route-over network, an IP packet is expected to be reassembled In a route-over network, an IP packet is expected to be reassembled
at every hop at the 6LoWPAN sublayer, pushed to Layer 3 to be routed, at every hop at the 6LoWPAN sublayer, pushed to Layer 3 to be routed,
and then fragmented again if the next hop is another similar 6LoWPAN and then fragmented again if the next hop is another similar 6LoWPAN
link. This draft introduces an alternate approach called 6LoWPAN link. This draft introduces an alternate approach called 6LoWPAN
Fragment Forwarding (FF) whereby an intermediate node forwards a Fragment Forwarding (6FF) whereby an intermediate node forwards a
fragment (or the bulk thereof, MTU permitting) without reassembling fragment (or the bulk thereof, MTU permitting) without reassembling
if the next hop is a similar 6LoWPAN link. The routing decision is if the next hop is a similar 6LoWPAN link. The routing decision is
made on the first fragment, which has the IPv6 routing information. made on the first fragment, which has the IPv6 routing information.
The first fragment is forwarded immediately and a state is stored to The first fragment is forwarded immediately and a state is stored to
enable forwarding the next fragments along the same path. enable forwarding the next fragments along the same path.
Done right, 6LoWPAN Fragment Forwarding techniques lead to more Done right, 6LoWPAN Fragment Forwarding techniques lead to more
streamlined operations, less buffer bloat and lower latency. But it streamlined operations, less buffer bloat and lower latency. But it
may be wasteful when fragments are missing, leading to locked may be wasteful when fragments are missing, leading to locked
resources and low throughput, and it may be misused to the point that 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 the end-to-end latency of one packet falls behind that of per-hop
recomposition. recomposition.
This specification provides a generic overview of FF, discusses This specification provides a generic overview of 6FF, discusses
advantages and caveats, and introduces a particular 6LoWPAN Fragment advantages and caveats, and introduces a particular 6LoWPAN Fragment
Forwarding technique called Virtual Reassembly Buffer that can be Forwarding technique called Virtual Reassembly Buffer that can be
used while retaining the message formats defined in [RFC4944]. Basic used while retaining the message formats defined in [RFC4944]. Basic
recommendations such as the insertion of an inter-frame gap between recommendations such as the insertion of an inter-frame gap between
fragments are provided to avoid the most typical caveats. fragments are provided to avoid the most typical caveats.
2. Terminology 2. Terminology
2.1. BCP 14 2.1. BCP 14
skipping to change at page 4, line 9 skipping to change at page 4, line 9
of the packet's network layer header. Rather, the label is used as 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". an index into a table which specifies the next hop, and a new label".
The MPLS technique is leveraged in the present specification to The MPLS technique is leveraged in the present specification to
forward fragments that actually do not have a network layer header, forward fragments that actually do not have a network layer header,
since the fragmentation occurs below IP. since the fragmentation occurs below IP.
2.3. New Terms 2.3. New Terms
This specification uses the following terms: This specification uses the following terms:
6LoWPAN endpoints: The 6LoWPAN endpoints are the first and last 6LoWPAN Fragment Forwarding endpoints: The 6FF endpoints are the
nodes in an unbroken string of 6LoWPAN fragment forwarding nodes. first and last nodes in an unbroken string of 6LoWPAN Fragment
They are in charge of generating or expanding a 6LoWPAN header Forwarding nodes. They are also the only points where the
from/to a full IPv6 packet. They are also the only points where fragmentation and reassembly operations take place.
the fragmentation and reassembly operations take place.
Compressed Form: This specification uses the generic term Compressed Compressed Form: This specification uses the generic term Compressed
Form to refer to the format of a datagram after the action of Form to refer to the format of a datagram after the action of
[RFC6282] and possibly [RFC8138] for RPL [RFC6550] artifacts. [RFC6282] and possibly [RFC8138] for RPL [RFC6550] artifacts.
datagram_size: The size of the datagram in its Compressed Form Datagram_Size: The size of the datagram in its Compressed Form
before it is fragmented. before it is fragmented.
Datagram_Tag: An identifier of a datagram that is locally unique to Datagram_Tag: An identifier of a datagram that is locally unique to
the Layer 2 sender. Associated with the Link-Layer address of the the Layer 2 sender. Associated with the Link-Layer address of the
sender, this becomes a globally unique identifier for the datagram sender, this becomes a globally unique identifier for the datagram
within the duration of its transmission. within the duration of its transmission.
fragment_offset: The offset of a fragment of a datagram in its Fragment_Offset: The offset of a fragment of a datagram in its
Compressed Form. Compressed Form.
3. Overview of 6LoWPAN Fragmentation 3. Overview of 6LoWPAN Fragmentation
We use Figure 1 to illustrate 6LoWPAN fragmentation. We assume node We use Figure 1 to illustrate 6LoWPAN fragmentation. We assume node
A forwards a packet to node B, possibly as part of a multi-hop route A forwards a packet to node B, possibly as part of a multi-hop route
between IPv6 source and destination nodes which may be neither A nor between 6LoWPAN Fragment Forwarding endpoints which may be neither A
B, though 6LoWPAN may compress the IP header better when they are. nor B, though 6LoWPAN may compress the IP header better when they are
both the 6FF and the 6LoWPAN compression endpoints.
+---+ +---+ +---+ +---+
... ---| A |-------------------->| B |--- ... ... ---| A |-------------------->| B |--- ...
+---+ +---+ +---+ +---+
# (frag. 5) # (frag. 5)
123456789 123456789 123456789 123456789
+---------+ +---------+ +---------+ +---------+
| # ###| |### # | | # ###| |### # |
+---------+ +---------+ +---------+ +---------+
skipping to change at page 5, line 40 skipping to change at page 5, line 40
* the Datagram_Tag chosen by node A for this fragmented datagram * the Datagram_Tag chosen by node A for this fragmented datagram
Because it may be hard for node B to correlate all possible Link- Because it may be hard for node B to correlate all possible Link-
Layer addresses that node A may use (e.g., short vs. long addresses), Layer addresses that node A may use (e.g., short vs. long addresses),
node A must use the same Link-Layer address to send all the fragments node A must use the same Link-Layer address to send all the fragments
of the same datagram to node B. of the same datagram to node B.
Conceptually, the reassembly buffer in node B contains: Conceptually, the reassembly buffer in node B contains:
* a Datagram_Tag as received in the incoming fragments, associated * a Datagram_Tag as received in the incoming fragments, associated
to Link-Layer address of node A for which the received to the interface and the Link-Layer address of node A for which
Datagram_Tag is unique, the received Datagram_Tag is unique,
* the actual packet data from the fragments received so far, in a * the actual packet data from the fragments received so far, in a
form that makes it possible to detect when the whole packet has form that makes it possible to detect when the whole packet has
been received and can be processed or forwarded, been received and can be processed or forwarded,
* a state indicating the fragments already received, * a state indicating the fragments already received,
* a datagram_size, * a Datagram_Size,
* a timer that allows discarding a partially reassembled packet * a timer that allows discarding a partially reassembled packet
after some timeout. after some timeout.
A fragmentation header is added to each fragment; it indicates what A fragmentation header is added to each fragment; it indicates what
portion of the packet that fragment corresponds to. Section 5.3 of portion of the packet that fragment corresponds to. Section 5.3 of
[RFC4944] defines the format of the header for the first and [RFC4944] defines the format of the header for the first and
subsequent fragments. All fragments are tagged with a 16-bit subsequent fragments. All fragments are tagged with a 16-bit
"Datagram_Tag", used to identify which packet each fragment belongs "Datagram_Tag", used to identify which packet each fragment belongs
to. Each datagram can be uniquely identified by the sender Link- to. Each datagram can be uniquely identified by the sender Link-
skipping to change at page 6, line 22 skipping to change at page 6, line 22
that the sender allocated for this datagram. [RFC4944] also mandates that the sender allocated for this datagram. [RFC4944] also mandates
that the first fragment is sent first and with a particular format that the first fragment is sent first and with a particular format
that is different than that of the next fragments. Each fragment but that is different than that of the next fragments. Each fragment but
the first one can be identified within its datagram by the datagram- the first one can be identified within its datagram by the datagram-
offset. offset.
Node B's typical behavior, per [RFC4944], is as follows. Upon Node B's typical behavior, per [RFC4944], is as follows. Upon
receiving a fragment from node A with a Datagram_Tag previously receiving a fragment from node A with a Datagram_Tag previously
unseen from node A, node B allocates a buffer large enough to hold 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 the entire packet. The length of the packet is indicated in each
fragment (the datagram_size field), so node B can allocate the buffer fragment (the Datagram_Size field), so node B can allocate the buffer
even if the first fragment it receives is not fragment 1. As even if the first fragment it receives is not fragment 1. As
fragments come in, node B fills the buffer. When all fragments have fragments come in, node B fills the buffer. When all fragments have
been received, node B inflates the compressed header fields into an been received, node B inflates the compressed header fields into an
IPv6 header, and hands the resulting IPv6 packet to the IPv6 layer IPv6 header, and hands the resulting IPv6 packet to the IPv6 layer
which performs the route lookup. This behavior typically results in which performs the route lookup. This behavior typically results in
per-hop fragmentation and reassembly. That is, the packet is fully per-hop fragmentation and reassembly. That is, the packet is fully
reassembled, then (re)fragmented, at every hop. reassembled, then (re)fragmented, at every hop.
4. Limitations of Per-Hop Fragmentation and Reassembly 4. Limitations of Per-Hop Fragmentation and Reassembly
skipping to change at page 8, line 6 skipping to change at page 8, line 6
fragment, it MUST look up state based on the source Link-Layer fragment, it MUST look up state based on the source Link-Layer
address and the Datagram_Tag in the received fragment. If no such address and the Datagram_Tag in the received fragment. If no such
state is found, the fragment MUST be dropped; otherwise the fragment state is found, the fragment MUST be dropped; otherwise the fragment
MUST be forwarded using the information in the state found. MUST be forwarded using the information in the state found.
Compared to Section 3, the conceptual reassembly buffer in node B now Compared to Section 3, the conceptual reassembly buffer in node B now
contains, assuming that node B is neither the source nor the final contains, assuming that node B is neither the source nor the final
destination: destination:
* a Datagram_Tag as received in the incoming fragments, associated * a Datagram_Tag as received in the incoming fragments, associated
to Link-Layer address of node A for which the received to the interface and the Link-Layer address of node A for which
Datagram_Tag is unique, the received Datagram_Tag is unique
* the Link-Layer address that node B uses as source to forward the * the Link-Layer address that node B uses as source to forward the
fragments fragments
* the Link-Layer address of the next hop C that is resolved on the * the interface and the Link-Layer address of the next hop C that is
first fragment resolved on the first fragment
* a Datagram_Tag that node B uniquely allocated for this datagram * a Datagram_Tag that node B uniquely allocated for this datagram
and that is used when forwarding the fragments of the 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 buffer for the remainder of a previous fragment left to be sent,
* a timer that allows discarding the stale FF state after some * a timer that allows discarding the stale FF state after some
timeout. The duration of the timer should be longer than that timeout. The duration of the timer should be longer than that
which covers the reassembly at the receiving end point. which covers the reassembly at the receiving end point.
skipping to change at page 8, line 36 skipping to change at page 8, line 36
A was in possession of the first fragment at some point. To keep the A was in possession of the first fragment at some point. To keep the
operation simple and consistent with [RFC4944], the first fragment operation simple and consistent with [RFC4944], the first fragment
MUST always be sent first. When that is done, if node B receives a 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 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 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 attempting to forward. This also means that node A should perform
all its possible retries on the first fragment before it attempts to all its possible retries on the first fragment before it attempts to
send the next fragments, and that it should abort the datagram and send the next fragments, and that it should abort the datagram and
release its state if it fails to send the first fragment. release its state if it fails to send the first fragment.
One benefit of Fragment Forwarding is that the memory that is used to Fragment forwarding obviates some of the benefits of the 6LoWPAN
store the packet is now distributed along the path, which limits the header compression [RFC6282] in intermediate hops. In return, the
buffer bloat effect. Multiple fragments may progress simultaneously memory used to store the packet is distributed along the path, which
along the network as long as they do not interfere. An associated limits the buffer bloat effect. Multiple fragments may progress
caveat is that on a half duplex radio, if node A sends the next simultaneously along the network as long as they do not interfere.
fragment at the same time as node B forwards the previous fragment to An associated caveat is that on a half duplex radio, if node A sends
a node C down the path then node B will miss the next fragment from the next fragment at the same time as node B forwards the previous
node A. If node C forwards the previous fragment to a node D at the fragment to a node C down the path then node B will miss it. If node
same time and on the same frequency as node A sends the next fragment C forwards the previous fragment to a node D at the same time and on
to node B, this may result in a hidden terminal problem. In that the same frequency as node A sends the next fragment to node B, this
case, the transmission from C interferes at node B with that from A may result in a hidden terminal problem. In that case, the
unbeknownst of node A. Consecutive fragments of a same datagram MUST transmission from C interferes at node B with that from A unbeknownst
be separated with an inter-frame gap that allows one fragment to of 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 progress beyond the next hop and beyond the interference domain
before the next shows up. This can be achieved by interleaving before the next shows up. This can be achieved by interleaving
packets or fragments sent via different next-hop routers. packets or fragments sent via different next-hop routers.
6. Virtual Reassembly Buffer (VRB) Implementation 6. Virtual Reassembly Buffer (VRB) Implementation
The Virtual Reassembly Buffer (VRB) [LWIG-VRB] is a particular The Virtual Reassembly Buffer (VRB) [LWIG-VRB] is a particular
incarnation of a 6LoWPAN Fragment Forwarding that can be implemented incarnation of a 6LoWPAN Fragment Forwarding that can be implemented
without a change to [RFC4944]. without a change to [RFC4944].
skipping to change at page 9, line 52 skipping to change at page 9, line 52
first. first.
The severity and occurrence of these caveats depends on the Link- The severity and occurrence of these caveats depends on the Link-
Layer used. Whether they are acceptable depends entirely on the Layer used. Whether they are acceptable depends entirely on the
requirements the application places on the network. requirements the application places on the network.
If the caveats are present and not acceptable for the application, If the caveats are present and not acceptable for the application,
alternative specifications may define new protocols to overcome them. alternative specifications may define new protocols to overcome them.
One example is [FRAG-RECOV] which specifies a 6LoWPAN Fragment One example is [FRAG-RECOV] which specifies a 6LoWPAN Fragment
Forwarding technique that allows the end-to-end fragment recovery Forwarding technique that allows the end-to-end fragment recovery
between the 6LoWPAN endpoints. between the 6LoWPAN FF endpoints.
7. Security Considerations 7. Security Considerations
An attacker can perform a Denial-of-Service (DoS) attack on a node An attacker can perform a Denial-of-Service (DoS) attack on a node
implementing VRB by generating a large number of bogus "fragment 1" implementing VRB by generating a large number of bogus "fragment 1"
fragments without sending subsequent fragments. This causes the VRB fragments without sending subsequent fragments. This causes the VRB
table to fill up. Note that the VRB does not need to remember the 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 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 the last fragment that could not fit in it. It is expected that an
implementation protects itself to keep the number of VRBs within implementation protects itself to keep the number of VRBs within
skipping to change at page 10, line 42 skipping to change at page 10, line 42
contain the same payload. The firewall MUST drop the whole packet contain the same payload. The firewall MUST drop the whole packet
if overlapping fragments are encountered that result in different if overlapping fragments are encountered that result in different
data at the same offset. data at the same offset.
* Resource exhaustion attacks are certainly possible and a sensitive * Resource exhaustion attacks are certainly possible and a sensitive
issue in a constrained network. An attacker can perform a Denial- issue in a constrained network. An attacker can perform a Denial-
of-Service (DoS) attack on a node implementing VRB by generating a of-Service (DoS) attack on a node implementing VRB by generating a
large number of bogus first fragments without sending subsequent large number of bogus first fragments without sending subsequent
fragments. This causes the VRB table to fill up. When hop-by-hop 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 reassembly is used, the same attack can be more damaging if the
node allocates a full datagram_size for each bogus first fragment. node allocates a full Datagram_Size for each bogus first fragment.
With the VRB, the attack can be performed remotely on all nodes 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 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 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 far but only possibly a few octets from the last fragment that
could not fit in it. An implementation MUST protect itself to could not fit in it. An implementation MUST protect itself to
keep the number of VRBs within capacity, and ensure that old VRBs keep the number of VRBs within capacity, and ensure that old VRBs
are protected by a timer of a reasonable duration for the are protected by a timer of a reasonable duration for the
technology and destroyed upon timeout. technology and destroyed upon timeout.
* Attacks based on predictable fragment identification values are * Attacks based on predictable fragment identification values are
skipping to change at page 11, line 31 skipping to change at page 11, line 31
8. IANA Considerations 8. IANA Considerations
No requests to IANA are made by this document. No requests to IANA are made by this document.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Carles Gomez Montenegro, Yasuyuki The authors would like to thank Carles Gomez Montenegro, Yasuyuki
Tanaka, Ines Robles and Dave Thaler for their in-depth review of this Tanaka, Ines Robles and Dave Thaler for their in-depth review of this
document and improvement suggestions. Also many thanks to Georgios document and improvement suggestions. Also many thanks to Georgios
Papadopoulos and Dominique Barthel for their own reviews, and to Papadopoulos and Dominique Barthel for their own reviews, and to
Roman Danyliw, Barry Leiba, Derrell Piper, Sarah Banks, Joerg Ott, Roman Danyliw, Barry Leiba, Murray Kucherawy, Derrell Piper, Sarah
Francesca Palombini, Mirja Kuhlewind, Eric Vyncke, and especially Banks, Joerg Ott, Francesca Palombini, Mirja Kuhlewind, Eric Vyncke,
Benjamin Kaduk for their constructive reviews through the IETF last and especially Benjamin Kaduk for their constructive reviews through
call and IESG process. the IETF last call and IESG process.
10. Normative References 10. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
 End of changes. 19 change blocks. 
42 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/