idnits 2.17.1 draft-ietf-lwig-6lowpan-virtual-reassembly-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 09, 2020) is 1508 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-6lo-minimal-fragment-14 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Informational T. Watteyne 5 Expires: September 10, 2020 Analog Devices 6 March 09, 2020 8 Virtual reassembly buffers in 6LoWPAN 9 draft-ietf-lwig-6lowpan-virtual-reassembly-02 11 Abstract 13 When employing adaptation layer fragmentation in 6LoWPAN, it may be 14 beneficial for a forwarder not to have to reassemble each packet in 15 its entirety before forwarding it. 17 This has been always possible with the original fragmentation design 18 of RFC 4944. Apart from a brief mention of the way to do this in 19 Section 2.5.2 of the 6LoWPAN book, this has not been extensively 20 described in the literature. The present document attempts to fill 21 that gap. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on September 10, 2020. 40 Copyright Notice 42 Copyright (c) 2020 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Reassembly buffers . . . . . . . . . . . . . . . . . . . . . 3 59 3. Virtual reassembly . . . . . . . . . . . . . . . . . . . . . 3 60 4. Header compression . . . . . . . . . . . . . . . . . . . . . 4 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 62 6. Security considerations . . . . . . . . . . . . . . . . . . . 4 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 65 7.2. Informative References . . . . . . . . . . . . . . . . . 5 66 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 69 1. Introduction 71 6LoWPAN [RFC4944] is the seminal standard for the transmission of 72 IPv6 packets over IEEE 802.15.4 networks and has served as a 73 blueprint for a number of related standards addressing low-power 74 radios and other IoT connectivity solutions (the "6Lo suite"). 76 One of the problems that need to be solved to enable sending IPv6 77 packets over low-power radios is that some of these (including IEEE 78 802.15.4) do not support frames that are large enough to hold IPv6 79 packets of the minimum MTU (Maximum Transmission Unit) defined for 80 IPv6, 1280 bytes. This necessitates providing a fragmentation or 81 segmentation scheme in the IP adaptation layer for the radio. 83 When employing adaptation layer fragmentation on constrained-node 84 networks [RFC7228], it may be beneficial for a forwarder not to have 85 to reassemble each packet in its entirety before forwarding it. 87 This has been always possible with the original fragmentation design 88 of RFC 4944. Apart from a brief mention of the way to do this in 89 Section 2.5.2 of the 6LoWPAN book [BOOK], this has not been 90 extensively described in the literature. The present document 91 attempts to fill that gap. 93 [I-D.ietf-6lo-minimal-fragment] provides additional context and 94 discussion about handling fragment forwarding in the 6Lo standards 95 suite. 97 2. Reassembly buffers 99 An adaptation layer implementation for 6LoWPAN needs to perform 100 reassembly of every fragmented packet received in order to be able to 101 forward the packet (re-fragmenting it in the process). 103 A reassembly buffer for 6LoWPAN contains: 105 o datagram_size, 107 o datagram_tag and L2 sender and receiver addresses (to which the 108 datagram_tag is local), 110 o actual packet data from the fragments received so far, in a form 111 that makes it possible to detect when the whole packet has been 112 received and can be processed or forwarded, 114 o a timer that allows discarding the partial packet after a timeout. 116 This requires a reassembly buffer for each fragmented packet the 117 reception of which is in progress. Since the forwarder may be 118 receiving fragments for multiple packets concurrently (e.g., from 119 different senders), this means that multiple reassembly buffers are 120 needed, easily dominating the memory requirements in a 6LoWPAN 121 implementation. Worse, as this space may still be limited, any lack 122 of reassembly buffers may lead to an increased loss rate for 123 fragmented packets (which already have to cope with a higher compound 124 loss rate). 126 3. Virtual reassembly 128 To reduce the memory requirement for reassembly buffers, the 129 implementation may opt to not keep the actual packet data in the 130 reassembly buffer. Instead, it may attempt to send out the data for 131 a fragment in the form of a forwarded fragment, as soon as all 132 necessary information for that is available. Obviously, all 133 fragments need to be sent with the same outgoing address (otherwise a 134 full reassembly implementation would discard the fragments) and the 135 same datagram_tag. 137 To this end, the reassembly buffer now also stores, as soon as enough 138 of the packet is available to make a forwarding decision (i.e., as 139 soon as the first fragment has been received): 141 o L2 destination address used for forwarding, 143 o outgoing datagram_tag chosen for this packet. 145 A simple implementation may do away with any attempt to keep packet 146 data in the virtual reassembly buffer. It then has to discard all 147 non-first fragments for which a reassembly buffer is not already 148 available (penalizing reordering, which however may be rare). 150 Note that the decision to do local processing of a packet needs to be 151 taken with the first fragment - such packets of course do need to be 152 fully reassembled (unless transport and application also can cope 153 with fragments, which they rarely can in the presence of security). 155 4. Header compression 157 [RFC6282] defines the header compression format for 6LoWPAN. One 158 important impact of header compression is that the header is no 159 longer of a length that stays fixed during forwarding. In 160 particular, changes made by a forwarder may gain or lose the ability 161 to use a more highly compressed variant, changing the length of the 162 header in the packet. If the change increases the size, the maximum 163 frame size may be exceeded, leading to the need to re-fragment in the 164 forwarder. This is less of a problem with full reassembly, but with 165 virtual reassembly can lead to the need for sending an additional 166 frame for each packet. 168 The well-known approach to minimize the probability of this need is 169 for the original sender to put all slack in the frame sizes into the 170 _first_ packet, making this the smallest fragment and not the last 171 one as would be done in a naive implementation. (This also has other 172 consequences related to delivery probability, which are not discussed 173 here.) This makes sure an additional fragment only needs to be sent 174 if the header expansion during forwarding would have created an 175 additional fragment with full reassembly as well. 177 5. IANA Considerations 179 This document makes no requests of IANA. 181 6. Security considerations 183 There are many security considerations with using fragmentation in 184 the first place, even with adaptation layer fragmentation (which is 185 not accessible outside the range of that adaptation layer). Some of 186 the more specific ones are documented in 187 [I-D.ietf-6lo-minimal-fragment] and will not be duplicated here. 189 In general, sending on fragments early from a node will relieve the 190 node that is doing the forwarding, but put additional onus on the 191 next node. This may or may not be in favor of an attacker. 193 7. References 195 7.1. Normative References 197 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 198 "Transmission of IPv6 Packets over IEEE 802.15.4 199 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 200 . 202 7.2. Informative References 204 [BOOK] Shelby, Z. and C. Bormann, "6LoWPAN", John Wiley & Sons, 205 Ltd monograph, DOI 10.1002/9780470686218, November 2009. 207 [I-D.ietf-6lo-minimal-fragment] 208 Watteyne, T., Thubert, P., and C. Bormann, "On Forwarding 209 6LoWPAN Fragments over a Multihop IPv6 Network", draft- 210 ietf-6lo-minimal-fragment-14 (work in progress), March 211 2020. 213 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 214 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 215 DOI 10.17487/RFC6282, September 2011, 216 . 218 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 219 Constrained-Node Networks", RFC 7228, 220 DOI 10.17487/RFC7228, May 2014, 221 . 223 Acknowledgements 225 Many people have mentioned that it would be good to have a 226 description of virtual reassembly in 6LoWPAN. Finally, Thomas 227 Watteyne assembled a design team that intends to work on 6Lo 228 fragmentation. Writing up the present document has been motivated by 229 that work. 231 Authors' Addresses 233 Carsten Bormann 234 Universitaet Bremen TZI 235 Postfach 330440 236 Bremen D-28359 237 Germany 239 Phone: +49-421-218-63921 240 Email: cabo@tzi.org 241 Thomas Watteyne 242 Analog Devices 243 32990 Alvarado-Niles Road, Suite 910 244 Union City, CA 94587 245 USA 247 Email: thomas.watteyne@analog.com