| < 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||