| < draft-ietf-6lo-minimal-fragment-08.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: 2 August 2020 Cisco Systems | Expires: 24 September 2020 Cisco Systems | |||
| C. Bormann | C. Bormann | |||
| Universitaet Bremen TZI | Universitaet Bremen TZI | |||
| 30 January 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-08 | draft-ietf-6lo-minimal-fragment-15 | |||
| Abstract | Abstract | |||
| This document introduces the capability to forward 6LoWPAN fragments. | This document provides generic rules to enable the forwarding of | |||
| This method reduces the latency and increases end-to-end reliability | 6LoWPAN fragment over a route-over network. Forwarding fragments can | |||
| in route-over forwarding. It is the companion to using virtual | improve both the end-to-end latency and reliability, and reduce the | |||
| reassembly buffers which is a pure implementation technique. | buffer requirements in intermediate nodes; it may be implemented | |||
| using RFC 4944 and virtual reassembly buffers. | ||||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| 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 2 August 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 15 ¶ | skipping to change at page 2, line 15 ¶ | |||
| provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Simplified BSD License. | |||
| Table of Contents | Table of Contents | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.2. Referenced Work . . . . . . . . . . . . . . . . . . . . . 3 | 2.2. Referenced Work . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.3. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3. Overview of 6LoWPAN Fragmentation . . . . . . . . . . . . . . 4 | 3. Overview of 6LoWPAN Fragmentation . . . . . . . . . . . . . . 4 | |||
| 4. Limits of Per-Hop Fragmentation and Reassembly . . . . . . . 6 | 4. Limitations of Per-Hop Fragmentation and Reassembly . . . . . 6 | |||
| 4.1. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.2. Memory Management and Reliability . . . . . . . . . . . . 6 | 4.2. Memory Management and Reliability . . . . . . . . . . . . 6 | |||
| 5. Forwarding Fragments . . . . . . . . . . . . . . . . . . . . 7 | 5. Forwarding Fragments . . . . . . . . . . . . . . . . . . . . 7 | |||
| 6. Virtual Reassembly Buffer (VRB) Implementation . . . . . . . 9 | 6. Virtual Reassembly Buffer (VRB) Implementation . . . . . . . 9 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 | 10. Normative References . . . . . . . . . . . . . . . . . . . . 11 | |||
| 11. Informative References . . . . . . . . . . . . . . . . . . . 11 | 11. Informative References . . . . . . . . . . . . . . . . . . . 12 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 1. Introduction | 1. Introduction | |||
| The original 6LoWPAN fragmentation is defined in [RFC4944] and it is | The original 6LoWPAN fragmentation is defined in [RFC4944] for use | |||
| implicitly defined for use over a single IP hop through possibly | over a single Layer 3 hop, though possibly multiple Layer 2 hops in a | |||
| multiple Layer-2 (mesh-under) hops in a meshed 6LoWPAN Network. | mesh-under network, and was not modified by the [RFC6282] update. | |||
| Although [RFC6282] updates [RFC4944], it does not redefine 6LoWPAN | 6LoWPAN operations including fragmentation depend on a Link-Layer | |||
| fragmentation. | security that prevents any rogue access to the network. | |||
| This means that over a Layer-3 (route-over) network, an IP packet is | In a route-over 6LoWPAN network, an IP packet is expected to be | |||
| expected to be reassembled at every hop at the 6LoWPAN sublayer, | reassembled at each intermediate hop, uncompressed, pushed to Layer 3 | |||
| pushed to Layer-3 to be routed, and then fragmented again if the next | to be routed, and then compressed and fragmented again. This draft | |||
| hop is another similar 6LoWPAN link. This draft introduces an | introduces an alternate approach called 6LoWPAN Fragment Forwarding | |||
| alternate approach called 6LoWPAN Fragment Forwarding (FF) whereby an | (6FF) whereby an intermediate node forwards a fragment (or the bulk | |||
| intermediate node forwards a fragment as soon as it is received if | thereof, MTU permitting) without reassembling if the next hop is a | |||
| the next hop is a similar 6LoWPAN link. The routing decision is made | similar 6LoWPAN link. The routing decision is made on the first | |||
| on the first fragment, which has all 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. It may | streamlined operations, less buffer bloat and lower latency. But it | |||
| be wasteful if some fragments are missing after the first one since | may be wasteful when fragments are missing, leading to locked | |||
| the first fragment will still continue till the 6LoWPAN endpoint that | resources and low throughput, and it may be misused to the point that | |||
| will attempt to perform the reassembly, and may be misused to the | the end-to-end latency of one packet falls behind that of per-hop | |||
| point that performances fall behind that of per-hop recomposition. | reassembly. | |||
| 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 conserving the message formats defined in [RFC4944]. | 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. Terminology | |||
| 2.1. BCP 14 | 2.1. BCP 14 | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119][RFC8174] when, and only when, they appear in all | 14 [RFC2119][RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2.2. Referenced Work | 2.2. Referenced Work | |||
| Past experience with fragmentation has shown that misassociated or | Past experience with fragmentation, e.g., as described in "IPv4 | |||
| lost fragments can lead to poor network behavior and, occasionally, | Reassembly Errors at High Data Rates" [RFC4963] and references | |||
| trouble at application layer. The reader is encouraged to read "IPv4 | therein, has shown that mis-associated or lost fragments can lead to | |||
| Reassembly Errors at High Data Rates" [RFC4963] and follow the | poor network behavior and, occasionally, trouble at the application | |||
| references for more information. That experience led to the | layer. That experience led to the definition of the "Path MTU | |||
| definition of "Path MTU discovery" [RFC8201] (PMTUD) protocol that | discovery" [RFC8201] (PMTUD) protocol that limits fragmentation over | |||
| limits fragmentation over the Internet. | the Internet. | |||
| "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security | "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security | |||
| threats that are linked to using IP fragmentation. The 6LoWPAN | threats that are linked to using IP fragmentation. The 6LoWPAN | |||
| fragmentation takes place underneath, but some issues described there | fragmentation takes place underneath the IP Layer, but some issues | |||
| may still apply to 6LoWPAN fragments. | 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 | Readers are expected to be familiar with all the terms and concepts | |||
| that are discussed in "IPv6 over Low-Power Wireless Personal Area | that are discussed in "IPv6 over Low-Power Wireless Personal Area | |||
| Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and | Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and | |||
| Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 | Goals" [RFC4919] and "Transmission of IPv6 Packets over IEEE 802.15.4 | |||
| Networks" [RFC4944]. | Networks" [RFC4944]. | |||
| Quoting the "Multiprotocol Label Switching (MPLS) Architecture" | "Multiprotocol Label Switching (MPLS) Architecture" [RFC3031] says | |||
| [RFC3031]: with MPLS, 'packets are "labeled" before they are | that with MPLS, 'packets are "labeled" before they are forwarded.' | |||
| forwarded'. At subsequent hops, there is no further analysis of the | It goes on to say, "At subsequent hops, there is no further analysis | |||
| packet's network layer header. Rather, the label is used as an index | of the packet's network layer header. Rather, the label is used as | |||
| into a table which specifies the next hop, and a new label". The | an index into a table which specifies the next hop, and a new label". | |||
| MPLS technique is leveraged in the present specification to forward | The MPLS technique is leveraged in the present specification to | |||
| fragments that actually do not have a network layer header, since the | forward fragments that actually do not have a network layer header, | |||
| 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 nodes in charge of generating or expanding a | 6LoWPAN Fragment Forwarding endpoints: The 6FF endpoints are the | |||
| 6LoWPAN header from/to a full IPv6 packet. The 6LoWPAN endpoints | first and last nodes in an unbroken string of 6LoWPAN Fragment | |||
| are the points where fragmentation and reassembly take place. | Forwarding nodes. They are also the only points where 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. The datagram_size is expressed in a unit | before it is fragmented. | |||
| that depends on the MAC layer technology, by default a byte. | ||||
| 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 MAC address of the | the Layer 2 sender. Associated with the Link-Layer address of the | |||
| sender, this becomes a globally unique identifier for the | sender, this becomes a globally unique identifier for the datagram | |||
| datagram. | within the duration of its transmission. | |||
| fragment_offset: The offset of a particular fragment of a datagram | Fragment_Offset: The offset of a fragment of a datagram in its | |||
| in its Compressed Form. The fragment_offset is expressed in a | Compressed Form. | |||
| unit that depends on the MAC layer technology and is by default a | ||||
| byte. | ||||
| 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 are neither A nor B. | 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 6FF and the 6LoWPAN compression endpoints. | ||||
| +---+ +---+ | +---+ +---+ | |||
| ... ---| A |-------------------->| B |--- ... | ... ---| A |-------------------->| B |--- ... | |||
| +---+ +---+ | +---+ +---+ | |||
| # (frag. 5) | # (frag. 5) | |||
| 123456789 123456789 | 123456789 123456789 | |||
| +---------+ +---------+ | +---------+ +---------+ | |||
| | # ###| |### # | | | # ###| |### # | | |||
| +---------+ +---------+ | +---------+ +---------+ | |||
| outgoing incoming | outgoing incoming | |||
| fragmentation reassembly | fragmentation reassembly | |||
| buffer buffer | buffer buffer | |||
| Figure 1: Fragmentation at node A, reassembly at node B. | Figure 1: Fragmentation at node A, reassembly at node B. | |||
| Node A starts by compacting the IPv6 packet using the header | Typically, Node A starts with an uncompressed packet and compacts the | |||
| compression mechanism defined in [RFC6282]. If the resulting 6LoWPAN | IPv6 packet using the header compression mechanism defined in | |||
| packet does not fit into a single Link-Layer frame, node A's 6LoWPAN | [RFC6282]. If the resulting 6LoWPAN packet does not fit into a | |||
| sublayer cuts it into multiple 6LoWPAN fragments, which it transmits | single Link-Layer frame, node A's 6LoWPAN sublayer cuts it into | |||
| as separate Link-Layer frames to node B. Node B's 6LoWPAN sublayer | multiple 6LoWPAN fragments, which it transmits as separate Link-Layer | |||
| reassembles these fragments, inflates the compressed header fields | frames to node B. Node B's 6LoWPAN sublayer reassembles these | |||
| back to the original IPv6 header, and hands over the full IPv6 packet | fragments, inflates the compressed header fields back to the original | |||
| to its IPv6 layer. | 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 | In Figure 1, a packet forwarded by node A to node B is cut into nine | |||
| fragments, numbered 1 to 9 as follows: | fragments, numbered 1 to 9 as follows: | |||
| * Each fragment is represented by the '#' symbol. | * Each fragment is represented by the '#' symbol. | |||
| * Node A has sent fragments 1, 2, 3, 5, 6 to node B. | * Node A has sent fragments 1, 2, 3, 5, 6 to node B. | |||
| * Node B has received fragments 1, 2, 3, 6 from node A. | * Node B has received fragments 1, 2, 3, 6 from node A. | |||
| * Fragment 5 is still being transmitted at the link layer from node | * Fragment 5 is still being transmitted at the link layer from node | |||
| A to node B. | A to node B. | |||
| The reassembly buffer for 6LoWPAN is indexed in node B by: | 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) | * 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 | * 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- | |||
| Layer addresses of the frame that carries it and the datagram_tag | Layer addresses of the frame that carries it and the Datagram_Tag | |||
| 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 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. Limits of Per-Hop Fragmentation and Reassembly | 4. Limitations of Per-Hop Fragmentation and Reassembly | |||
| There are at least 2 limits to doing per-hop fragmentation and | There are at least 2 limitations to doing per-hop fragmentation and | |||
| reassembly. See [ARTICLE] for detailed simulation results on both | reassembly. See [ARTICLE] for detailed simulation results on both | |||
| limits. | limitations. | |||
| 4.1. Latency | 4.1. Latency | |||
| When reassembling, a node needs to wait for all the fragments to be | When reassembling, a node needs to wait for all the fragments to be | |||
| received before being able to generate the IPv6 packet, and possibly | received before being able to reform the IPv6 packet, and possibly | |||
| forward it to the next hop. This repeats at every hop. | forward it to the next hop. This repeats at every hop. | |||
| This may result in increased end-to-end latency compared to a case | This may result in increased end-to-end latency compared to a case | |||
| where each fragment is forwarded without per-hop reassembly. | where each fragment is forwarded without per-hop reassembly. | |||
| 4.2. Memory Management and Reliability | 4.2. Memory Management and Reliability | |||
| Constrained nodes have limited memory. Assuming a reassembly buffer | Constrained nodes have limited memory. Assuming a reassembly buffer | |||
| for a 6LoWPAN MTU of 1280 bytes as defined in section 4 of [RFC4944], | 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. | typical nodes only have enough memory for 1-3 reassembly buffers. | |||
| skipping to change at page 7, line 33 ¶ | skipping to change at page 7, line 33 ¶ | |||
| When nodes A, B and C concurrently send fragmented packets, all 3 | When nodes A, B and C concurrently send fragmented packets, all 3 | |||
| reassembly buffers in node E are occupied. If, at that moment, node | 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 | D also sends a fragmented packet, node E has no option but to drop | |||
| one of the packets, lowering end-to-end reliability. | one of the packets, lowering end-to-end reliability. | |||
| 5. Forwarding Fragments | 5. Forwarding Fragments | |||
| A 6LoWPAN Fragment Forwarding technique makes the routing decision on | A 6LoWPAN Fragment Forwarding technique makes the routing decision on | |||
| the first fragment, which is always the one with the IPv6 address of | the first fragment, which is always the one with the IPv6 address of | |||
| the destination. Upon a first fragment, a forwarding node (e.g. node | the destination. Upon receiving a first fragment, a forwarding node | |||
| B in a A->B->C sequence) that does fragment forwarding MUST attempt | (e.g. node B in a A->B->C sequence) that does fragment forwarding | |||
| to create a state and forward the fragment. This is an atomic | MUST attempt to create a state and forward the fragment. This is an | |||
| operation, and if the first fragment cannot be forwarded then the | atomic operation, and if the first fragment cannot be forwarded then | |||
| state MUST be removed. | the state MUST be removed. | |||
| Since the datagram_tag is uniquely associated to the source Link- | Since the Datagram_Tag is uniquely associated to the source Link- | |||
| Layer address of the fragment, the forwarding node MUST assign a new | 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 | Datagram_Tag from its own namespace for the next hop and rewrite the | |||
| fragment header of each fragment with that datagram_tag. | fragment header of each fragment with that Datagram_Tag. | |||
| When a forwarding node receives a fragment other than a first | When a forwarding node receives a fragment other than a first | |||
| 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. | |||
| A node that has not received the first fragment cannot forward the | A node that has not received the first fragment cannot forward the | |||
| next fragments. This means that if node B receives a fragment, node | next fragments. This means that if node B receives a fragment, node | |||
| A was in possession of the first fragment at some point. In order to | A was in possession of the first fragment at some point. To keep the | |||
| keep the operation simple, it makes sense to be consistent with | operation simple and consistent with [RFC4944], the first fragment | |||
| [RFC4944] and enforce that the first fragment is always sent first. | MUST always be sent first. When that is done, if node B receives a | |||
| When that is done, if node B receives a fragment that is not the | fragment that is not the first and for which it has no state, then | |||
| first and for which it has no state, then node B treats this as an | node B treats it as an error and refrains from creating a state or | |||
| error and refrain from creating a state or attempting to forward. | attempting to forward. This also means that node A should perform | |||
| This also means that node A should perform all its possible retries | all its possible retries on the first fragment before it attempts to | |||
| on the first fragment before it attempts to send the next fragments, | send the next fragments, and that it should abort the datagram and | |||
| and that it should abort the datagram and release its state if it | release its state if it fails to send the first fragment. | |||
| 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 in parallel | 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. If | the next fragment at the same time as node B forwards the previous | |||
| node C forwards the previous fragment to a node D at the same time | fragment to a node C down the path then node B will miss it. If node | |||
| and on the same frequency as node A sends the next fragment to node | C forwards the previous fragment to a node D at the same time and on | |||
| B, this may result in a hidden terminal problem at B whereby the | the same frequency as node A sends the next fragment to node B, this | |||
| transmission from C interferes with that from A unbeknownst of node | may result in a hidden terminal problem. In that case, the | |||
| A. It results that consecutive fragments must be reasonably spaced | transmission from C interferes at node B with that from A unbeknownst | |||
| in order to avoid the 2 forms of collision described above. A node | of node A. Consecutive fragments of a same datagram MUST be | |||
| that has multiple packets or fragments to send via different next-hop | separated with an inter-frame gap that allows one fragment to | |||
| routers may interleave the messages in order to alleviate those | progress beyond the next hop and beyond the interference domain | |||
| effects. | 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 | 6. Virtual Reassembly Buffer (VRB) Implementation | |||
| Virtual Reassembly Buffer (VRB) is the implementation technique | The Virtual Reassembly Buffer (VRB) [LWIG-VRB] is a particular | |||
| described in [LWIG-VRB] in which a forwarder does not reassemble each | incarnation of a 6LoWPAN Fragment Forwarding that can be implemented | |||
| packet in its entirety before forwarding it. | without a change to [RFC4944]. | |||
| VRB overcomes the limits listed in Section 4. Nodes do not wait for | VRB overcomes the limitations listed in Section 4. Nodes do not wait | |||
| the last fragment before forwarding, reducing end-to-end latency. | for the last fragment before forwarding, reducing end-to-end latency. | |||
| Similarly, the memory footprint of VRB is just the VRB table, | Similarly, the memory footprint of VRB is just the VRB table, | |||
| reducing the packet drop probability significantly. | reducing the packet drop probability significantly. | |||
| There are, however, limits: | There are other caveats, however: | |||
| Non-zero Packet Drop Probability: The abstract data in a VRB table | Non-zero Packet Drop Probability: The abstract data in a VRB table | |||
| entry contains at a minimum the Link-Layer address of the | entry contains at a minimum the Link-Layer address of the | |||
| predecessor and that of the successor, the datagram_tag used by | predecessor and that of the successor, the Datagram_Tag used by | |||
| the predecessor and the local datagram_tag that this node will | 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 | 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 | last fragment that may not have fit within MTU and that will be | |||
| prepended to the next fragment. This yields a small footprint | prepended to the next fragment. This yields a small footprint | |||
| that is 2 orders of magnitude smaller compared to needing a | that is 2 orders of magnitude smaller compared to needing a | |||
| 1280-byte reassembly buffer for each packet. Yet, the size of the | 1280-byte reassembly buffer for each packet. Yet, the size of the | |||
| VRB table necessarily remains finite. In the extreme case where a | VRB table necessarily remains finite. In the extreme case where a | |||
| node is required to concurrently forward more packets that it has | node is required to concurrently forward more packets that it has | |||
| entries in its VRB table, packets are dropped. | entries in its VRB table, packets are dropped. | |||
| No Fragment Recovery: There is no mechanism in VRB for the node that | No Fragment Recovery: There is no mechanism in VRB for the node that | |||
| reassembles a packet to request a single missing fragment. | reassembles a packet to request a single missing fragment. | |||
| Dropping a fragment requires the whole packet to be resent. This | Dropping a fragment requires the whole packet to be resent. This | |||
| causes unnecessary traffic, as fragments are forwarded even when | causes unnecessary traffic, as fragments are forwarded even when | |||
| the destination node can never construct the original IPv6 packet. | the destination node can never construct the original IPv6 packet. | |||
| No Per-Fragment Routing: All subsequent fragments follow the same | No Per-Fragment Routing: All subsequent fragments follow the same | |||
| sequence of hops from the source to the destination node as the | sequence of hops from the source to the destination node as the | |||
| first fragment, because the IP header is required to route the | first fragment, because the IP header is required in order to | |||
| fragment and is only present in the first fragment. A side effect | route the fragment and is only present in the first fragment. A | |||
| is that the first fragment must always be forwarded first. | side effect is that the first fragment must always be forwarded | |||
| first. | ||||
| The severity and occurrence of these limits depends on the Link-Layer | The severity and occurrence of these caveats depends on the Link- | |||
| used. Whether these limits 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 limits are present and not acceptable for the application, | If the caveats are present and not acceptable for the application, | |||
| future specifications may define new protocols to overcome these | alternative specifications may define new protocols to overcome them. | |||
| limits. One example is [FRAG-RECOV] which defines a protocol which | One example is [FRAG-RECOV] which specifies a 6LoWPAN Fragment | |||
| allows fragment recovery. | Forwarding technique that allows the end-to-end fragment recovery | |||
| between the 6LoWPAN FF endpoints. | ||||
| 7. Security Considerations | 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 | Secure joining and the Link-Layer security that it sets up protects | |||
| against those attacks from network outsiders. | against those attacks from network outsiders. | |||
| "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security | "IP Fragmentation Considered Fragile" [FRAG-ILE] discusses security | |||
| threats that are linked to using IP fragmentation. The 6LoWPAN | threats and other caveats that are linked to using IP fragmentation. | |||
| fragmentation takes place underneath, but some issues described there | The 6LoWPAN fragmentation takes place underneath the IP Layer, but | |||
| may still apply to 6LoWPAN fragments. | some issues described there may still apply to 6LoWPAN fragments. | |||
| * Overlapping fragment attacks are possible with 6LoWPAN fragments | * Overlapping fragment attacks are possible with 6LoWPAN fragments | |||
| but there is no known firewall operation that would work on | but there is no known firewall operation that would work on | |||
| 6LoWPAN fragments at the time of this writing, so the exposure is | 6LoWPAN fragments at the time of this writing, so the exposure is | |||
| limited. An implementation of a firewall SHOULD NOT forward | limited. An implementation of a firewall SHOULD NOT forward | |||
| fragments but recompose the IP packet, check it in the | fragments but instead should recompose the IP packet, check it in | |||
| uncompressed form, and then forward it again as fragments if | the u ncompressed form, and then forward it again as fragments if | |||
| necessary. | 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 | * 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 that old VRBs are | keep the number of VRBs within capacity, and ensure that old VRBs | |||
| protected by a timer of a reasonable duration for the technology | are protected by a timer of a reasonable duration for the | |||
| 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. | assigned pseudo-randomly in order to defeat 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. 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 sounds | ambiguity in the reassembly of the fragment. This attack makes | |||
| difficult and mostly useless in a 6LoWPAN network since the | little sense in the context of this specification since the | |||
| fragmentation is not end-to-end. | fragmentation happens within the LLN, meaning that the intruder | |||
| should already be inside to perform the attack. NDIS systems | ||||
| would probably not be installed within the LLN either, but rather | ||||
| at a boittleneck at the exterior edge of the network. | ||||
| 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 Georgies | 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 | |||
| Joerg Ott who helped through the IESG steps. | Roman Danyliw, Barry Leiba, Murray Kucherawy, Derrell Piper, Sarah | |||
| Banks, Joerg Ott, Francesca Palombini, Mirja Kuhlewind, Eric Vyncke, | ||||
| and especially Benjamin Kaduk for their constructive reviews through | ||||
| 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, | |||
| May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
| [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, | |||
| "Transmission of IPv6 Packets over IEEE 802.15.4 | "Transmission of IPv6 Packets over IEEE 802.15.4 | |||
| Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, | |||
| <https://www.rfc-editor.org/info/rfc4944>. | <https://www.rfc-editor.org/info/rfc4944>. | |||
| [LWIG-VRB] Bormann, C. and T. Watteyne, "Virtual reassembly buffers | ||||
| in 6LoWPAN", Work in Progress, Internet-Draft, draft-ietf- | ||||
| lwig-6lowpan-virtual-reassembly-01, 11 March 2019, | ||||
| <https://tools.ietf.org/html/draft-ietf-lwig-6lowpan- | ||||
| virtual-reassembly-01>. | ||||
| [FRAG-RECOV] | ||||
| Thubert, P., "6LoWPAN Selective Fragment Recovery", Work | ||||
| in Progress, Internet-Draft, draft-ietf-6lo-fragment- | ||||
| recovery-08, 28 November 2019, | ||||
| <https://tools.ietf.org/html/draft-ietf-6lo-fragment- | ||||
| recovery-08>. | ||||
| 11. Informative References | ||||
| [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 | [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 | |||
| over Low-Power Wireless Personal Area Networks (6LoWPANs): | over Low-Power Wireless Personal Area Networks (6LoWPANs): | |||
| Overview, Assumptions, Problem Statement, and Goals", | Overview, Assumptions, Problem Statement, and Goals", | |||
| RFC 4919, DOI 10.17487/RFC4919, August 2007, | RFC 4919, DOI 10.17487/RFC4919, August 2007, | |||
| <https://www.rfc-editor.org/info/rfc4919>. | <https://www.rfc-editor.org/info/rfc4919>. | |||
| 11. Informative References | ||||
| [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly | [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly | |||
| Errors at High Data Rates", RFC 4963, | Errors at High Data Rates", RFC 4963, | |||
| DOI 10.17487/RFC4963, July 2007, | DOI 10.17487/RFC4963, July 2007, | |||
| <https://www.rfc-editor.org/info/rfc4963>. | <https://www.rfc-editor.org/info/rfc4963>. | |||
| [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol | |||
| Label Switching Architecture", RFC 3031, | Label Switching Architecture", RFC 3031, | |||
| DOI 10.17487/RFC3031, January 2001, | DOI 10.17487/RFC3031, January 2001, | |||
| <https://www.rfc-editor.org/info/rfc3031>. | <https://www.rfc-editor.org/info/rfc3031>. | |||
| skipping to change at page 12, line 41 ¶ | skipping to change at page 13, line 8 ¶ | |||
| DOI 10.17487/RFC6550, March 2012, | DOI 10.17487/RFC6550, March 2012, | |||
| <https://www.rfc-editor.org/info/rfc6550>. | <https://www.rfc-editor.org/info/rfc6550>. | |||
| [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 | ||||
| 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>. | ||||
| [FRAG-RECOV] | ||||
| Thubert, P., "6LoWPAN Selective Fragment Recovery", Work | ||||
| in Progress, Internet-Draft, draft-ietf-6lo-fragment- | ||||
| recovery-20, 20 March 2020, <https://tools.ietf.org/html/ | ||||
| draft-ietf-6lo-fragment-recovery-20>. | ||||
| [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 | |||
| Union City, CA 94587 | Union City, CA 94587 | |||
| End of changes. 62 change blocks. | ||||
| 177 lines changed or deleted | 211 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||