draft-ietf-6lo-minimal-fragment-14.txt   draft-ietf-6lo-minimal-fragment-15.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: 10 September 2020 Cisco Systems Expires: 24 September 2020 Cisco Systems
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
9 March 2020 23 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-14 draft-ietf-6lo-minimal-fragment-15
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 10 September 2020. This Internet-Draft will expire on 24 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 35 skipping to change at page 2, line 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
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 6LoWPAN network, an IP packet is expected to be
at every hop at the 6LoWPAN sublayer, pushed to Layer 3 to be routed, reassembled at each intermediate hop, uncompressed, pushed to Layer 3
and then fragmented again if the next hop is another similar 6LoWPAN to be routed, and then compressed and fragmented again. This draft
link. This draft introduces an alternate approach called 6LoWPAN introduces an alternate approach called 6LoWPAN Fragment Forwarding
Fragment Forwarding (6FF) whereby an intermediate node forwards a (6FF) whereby an intermediate node forwards a fragment (or the bulk
fragment (or the bulk thereof, MTU permitting) without reassembling thereof, MTU permitting) without reassembling if the next hop is a
if the next hop is a similar 6LoWPAN link. The routing decision is similar 6LoWPAN link. The routing decision is made on the first
made on the first fragment, which has the IPv6 routing information. fragment of the datagram, 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. reassembly.
This specification provides a generic overview of 6FF, 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
skipping to change at page 6, line 23 skipping to change at page 6, line 23
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 fragment it receives first is not the first fragment. 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
There are at least 2 limitations to doing per-hop fragmentation and There are at least 2 limitations to doing per-hop fragmentation and
skipping to change at page 11, line 11 skipping to change at page 11, line 11
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
also possible but can be avoided. The Datagram_Tag SHOULD be also possible but can be avoided. The Datagram_Tag SHOULD be
assigned pseudo-randomly in order to defeat such attacks. A assigned pseudo-randomly in order to defeat such attacks. A
larger size of the Datagram_Tag makes the guessing more difficult larger size of the Datagram_Tag makes the guessing more difficult
and reduces the chances of an accidental reuse while the original and reduces the chances of an accidental reuse while the original
packet is still in flight, at the expense of more space in each packet is still in flight, at the expense of more space in each
frame. frame. Attacks based on predictable fragment identification
values are also possible but can be avoided. The Datagram_Tag
SHOULD be assigned pseudo-randomly in order to reduce the risk of
such attacks. Nonetheless, some level of risk remains that an
attacker 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 (NIDS) leverages * Evasion of Network Intrusion Detection Systems (NIDS) leverages
ambiguity in the reassembly of the fragment. This attack makes ambiguity in the reassembly of the fragment. This attack makes
little sense in the context of this specification since the little sense in the context of this specification since the
fragmentation happens within the LLN, meaning that the intruder fragmentation happens within the LLN, meaning that the intruder
should already be inside to perform the attack. NDIS systems should already be inside to perform the attack. NDIS systems
would probably not be installed within the LLN either, but rather would probably not be installed within the LLN either, but rather
at a boittleneck at the exterior edge of the network. at a boittleneck at the exterior edge of the network.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 13, line 7 skipping to change at page 13, line 10
[FRAG-ILE] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., [FRAG-ILE] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O.,
and F. Gont, "IP Fragmentation Considered Fragile", Work and F. Gont, "IP Fragmentation Considered Fragile", Work
in Progress, Internet-Draft, draft-ietf-intarea-frag- in Progress, Internet-Draft, draft-ietf-intarea-frag-
fragile-17, 30 September 2019, fragile-17, 30 September 2019,
<https://tools.ietf.org/html/draft-ietf-intarea-frag- <https://tools.ietf.org/html/draft-ietf-intarea-frag-
fragile-17>. fragile-17>.
[LWIG-VRB] Bormann, C. and T. Watteyne, "Virtual reassembly buffers [LWIG-VRB] Bormann, C. and T. Watteyne, "Virtual reassembly buffers
in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf- in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf-
lwig-6lowpan-virtual-reassembly-01, 11 March 2019, lwig-6lowpan-virtual-reassembly-02, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-lwig-6lowpan- <https://tools.ietf.org/html/draft-ietf-lwig-6lowpan-
virtual-reassembly-01>. virtual-reassembly-02>.
[FRAG-RECOV] [FRAG-RECOV]
Thubert, P., "6LoWPAN Selective Fragment Recovery", Work Thubert, P., "6LoWPAN Selective Fragment Recovery", Work
in Progress, Internet-Draft, draft-ietf-6lo-fragment- in Progress, Internet-Draft, draft-ietf-6lo-fragment-
recovery-13, 18 February 2020, recovery-20, 20 March 2020, <https://tools.ietf.org/html/
<https://tools.ietf.org/html/draft-ietf-6lo-fragment- draft-ietf-6lo-fragment-recovery-20>.
recovery-13>.
[ARTICLE] Tanaka, Y., Minet, P., and T. Watteyne, "6LoWPAN Fragment [ARTICLE] Tanaka, Y., Minet, P., and T. Watteyne, "6LoWPAN Fragment
Forwarding", IEEE Communications Standards Magazine , Forwarding", IEEE Communications Standards Magazine ,
2019. 2019.
Authors' Addresses Authors' Addresses
Thomas Watteyne (editor) Thomas Watteyne (editor)
Analog Devices Analog Devices
32990 Alvarado-Niles Road, Suite 910 32990 Alvarado-Niles Road, Suite 910
 End of changes. 11 change blocks. 
20 lines changed or deleted 25 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/