idnits 2.17.1 draft-bormann-intarea-alfi-03.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([WEI], [RFC4821]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2013) is 4058 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-bormann-6lowpan-roadmap-03 == Outdated reference: A later version (-21) exists of draft-ietf-core-block-10 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-13 == Outdated reference: A later version (-07) exists of draft-ietf-lwig-terminology-01 == Outdated reference: A later version (-03) exists of draft-mariager-6lowpan-v6over-dect-ule-02 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Intarea Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track March 10, 2013 5 Expires: September 11, 2013 7 Adaptation Layer Fragmentation Indication 8 draft-bormann-intarea-alfi-03 10 Abstract 12 IPv6 defines a minimum MTU of 1280 bytes. Many link layers are more 13 limited in the maximum size of packets they can communicate. In 14 order to enable the transport of IP packets that are too large for 15 these link layers, typically their IP adaptation layers define a 16 segmentation or fragmentation scheme to transport an IP packet in a 17 sequence of multiple link layer packets. 19 Often, adaption layer fragmentation schemes reduce some performance 20 metric, such as the packet delivery probability. Application or 21 transport protocols may be able to reduce the maximum size of packets 22 they send, e.g. by transport layer segmentation or choice of 23 application layer data object size, which may have less of a 24 performance impact. It would therefore be desirable for them to know 25 about any adaptation layer fragmentation that is going on, so they 26 can choose packet sizes that minimize adaptation layer fragmentation. 28 At the IP layer, fragmentation can be detected using a number of 29 mechanisms used in Packetization Layer Path MTU Discovery [RFC4821]. 30 However, adaptation layer fragmentation schemes are often designed to 31 be "transparent", i.e. there is no way at higher layers to find out 32 whether they had to be employed (except maybe by elaborate 33 measurement schemes targeting one of the impacted performance 34 metrics; this approach does not appear to be viable) [WEI]. 36 The present specification defines a mechanism for IPv6 adaptation 37 layers to indicate the presence of adaptation layer fragmentation on 38 one or more hops on the path from an IP sender to an IP receiver, and 39 to provide an indication of preferred (smaller) packet sizes on these 40 hops. 42 The main objective of this version of the draft is to present a 43 complete design in order to be able to gauge the complexity of the 44 approach against the gains to be expected from implementing it. 46 Comments are appreciated and should go to the intarea@ietf.org 47 mailing list. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at http://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on September 11, 2013. 66 Copyright Notice 68 Copyright (c) 2013 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 85 2. Objectives and Considerations . . . . . . . . . . . . . . . . 3 86 3. The ALFI option . . . . . . . . . . . . . . . . . . . . . . . 4 87 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 6 88 4.1. Should this be done at all? . . . . . . . . . . . . . . . 6 89 4.2. Is this the right way to do it? . . . . . . . . . . . . . 6 90 5. Another way of doing it . . . . . . . . . . . . . . . . . . . 6 91 5.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 93 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 94 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 95 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 96 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 97 9.2. Informative References . . . . . . . . . . . . . . . . . 8 98 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 100 1. Introduction 102 (To be written - for now please read the Abstract.) 104 1.1. Terminology 106 The following terms are used in this specification: 108 ALF: Adaptation Layer Fragmentation. 110 MUALTU: Maximum Unfragmented Adaptation Layer Transmission Unit, 111 i.e. the largest piece of IPv6 packet (measured in bytes) that 112 can be transferred by the adaptation layers on the path without 113 invoking ALF. 115 IFMUALTU: Initial-Fragment MUALTU, the MUALTU for the initial 116 adaptation layer fragment of an IP packet. 118 FFMUALTU: Following-Fragment MUALTU, the estimated minimum MUALTU 119 for all but the initial adaptation layer fragments of an IP 120 packet. 122 ALFI: Adaptation Layer Fragmentation Indication, i.e. indication 123 that ALF was performed on a packet. 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119] when they 128 appear in ALL CAPS. These words may also appear in this document in 129 lower case as plain English words, absent their normative meanings. 131 The term "byte" is used in its now customary sense as a synonym for 132 "octet". 134 2. Objectives and Considerations 136 This draft is shaped by the requirements of 6LoWPAN networks 137 [I-D.bormann-6lowpan-roadmap], including variants such as Bluetooth/ 138 Low Energy [I-D.ietf-6lowpan-btle] or DECT/ULE 139 [I-D.mariager-6lowpan-v6over-dect-ule]. However, it should be 140 beneficial with any adaptation layer that requires the use of ALF. 142 One important consideration for ALFI is that the ALF scheme may not 143 be able to provide a consistent MUALTU. E.g., header compression may 144 cause variable overheads, and initial and following fragments are 145 likely to cause different MUALTUs. Header compression may be 146 dependent on the specific characteristics of the packets employed, so 147 indications will be most accurate if they can be made on the basis of 148 actual packets as they are intended to be transferred. (E.g., for a 149 6LoWPAN with a physical layer maximum packet size of 127 bytes, the 150 specific combination of MAC layer overheads, adaptation layer 151 overheads, and header compression gains can turn the actual initial 152 fragment size number into anything roughly between 70 and 160 bytes. 153 Note that this is more than a factor of two, making it difficult to 154 just guess a good MUALTU.) 156 Therefore, ALFI provides the ability to equip packets with a probe 157 that collects any information for adaptation layer fragmentation that 158 may be available on the path. 160 Note that probing for MUALTUs is likely to change the MUALTU. 161 Implementations SHOULD attempt to indicate a MUALTU for an equivalent 162 non-probe packet, i.e. the packet under consideration with the ALFI 163 option (and its hop-by-hop header, if applicable) removed. If that 164 is not possible, implementations SHOULD err towards indicating 165 smaller MUALTUs, within reason. 167 Obviously, not all nodes will immediately implement ALFI. ALFI just 168 "fails ignorant" (but see below). 170 An adaptation layer instance may want to manipulate ALFI for other 171 reasons than to indicate ALF (which would be somewhat comparable to 172 the widespread practive of TCP "MSS clamping"). (In particular, as 173 long as it can be expected that some other nodes on the path don't 174 have ALFI yet, a border router such as a 6LBR [RFC6775] may want to 175 provide some ALFI guessing.) 177 Generally speaking, ALFI can be used as a mechanism to indicate any 178 significant, step function degradation of some performance metric 179 based on packet size. However, as the mechanism can only collect a 180 single value for the entire path (i.e., one IFMUALTU and one 181 FFMUALTU), the performance degradation indicated SHOULD be 182 significant. In other words, ALFI indications SHOULD NOT be set for 183 segmentation implementations where segmentation causes limited 184 performance impact. E.g., AAL5 implementations SHOULD NOT set ALFI. 186 3. The ALFI option 188 The ALFI option is an IPv6 option in the sense of section 4.2 of 189 [RFC2460]. It is only used in the hop-by-hop header. 191 The option type identifier is chosen to select the following behavior 192 as detailed in section 4.2 of [RFC2460]: 194 o 00 - skip over this option and continue processing the header 195 (this enables the "fail-ignorant" backwards compatibility 196 behavior) 198 o 1 - Option Data may change en-route (the option is used to record 199 information en-route) 201 . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 . |0 0 1 x x x x x| 4 | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Initial-Fragment MUALTU | Following-Fragment MUALTU | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 Figure 1 209 In IFMUALTU and FFMUALTU, the value zero represents infinity. All 210 other values are unsigned integers in network byte order, 211 representing a MUALTU in bytes. 213 The originator of a packet MAY, for occasional probing, insert an 214 ALFI option into packets where it can choose the packet size and the 215 performance metrics of which are important to the application. 217 When generating the IP packet, the originator sets Initial-Fragment 218 MUALTU (IFMUALTU) and Following-Fragment MUALTU (FFMUALTU) to zero. 219 (Its own adaptation layer can then already update them as described 220 in the following paragraphs before the packet even leaves the 221 originator.) 223 Each instance of an adaptation layer that employs ALF and that 224 implements this specification computes its own estimate of IFMUALTU 225 and FFMUALTU for the type of packet that has this option, ignoring 226 the option itself and, if the option was the only option in the hop- 227 by-hop header, the hop-by-hop header. For each estimate, if it is 228 below the value of the respective field encoded in the option (where 229 zero represents infinity), the instance updates the field to the 230 estimate. 232 The receiver of the packet relays the information in the ALFI option 233 to the transport layer and/or application. 235 (TBD: How to ship this information through the IPv6 socket interface 236 [RFC3493] [RFC3542]. Constrained implementations won't have this 237 specific problem.) 239 The receiving transport layer and/or application can then make this 240 information available back to the peer instance, which enables the 241 latter to choose IPv6 packet sizes of IFMUALTU or lower, or, if this 242 cannot be achieved, at least below IFMUALTU+n*FFMUALTU for a small n. 243 For instance, in CoAP [I-D.ietf-core-coap], the receiver of an ALFI 244 probe from a server can use the Block2 option [I-D.ietf-core-block] 245 to negotiate a block size for further messages in a block-wise 246 transfer accordingly. 248 4. Discussion 250 The discussion of this proposal should center around two questions. 252 4.1. Should this be done at all? 254 I.e., can't we just live with the inefficiency? 256 In ATM or DVB, the inefficiency caused by not knowing about 257 adaptation layer fragmentation was limited. In constrained node 258 networks [I-D.ietf-lwig-terminology], the issue becomes more urgent. 259 One reason is that there the packet delivery rate is lower. There 260 also is more variability in the actual values of the MUALTUs. 262 On the other hand, it is likely that one of the ends of a path that 263 traverses a constrained node network is embedded in this constrained 264 node network, so it may be able to make an educated guess for the 265 path MUALTUs. 267 4.2. Is this the right way to do it? 269 IPv6 hop-by-hop options seem to be seriously challenged in the 270 greater Internet. Unfortunately, they are the only way to collect 271 this kind of information on every hop. Quick-Start [RFC4782] uses 272 them in a similar way, but within what is mostly a controlled 273 environment, where it is easier to make sure the option is indeed 274 processed and not damaged. Many constrained node networks can also 275 be considered relatively controlled networks. However, the 276 corresponding node may be in the greater Internet, and it may neither 277 be able to emit a hop-by-hop option in such a way that it arrives at 278 the edge of the constrained node network nor be able to receive 279 information that has been collected on the way out of a constrained 280 node network. 282 This may be remedied by assigning the constrained node network border 283 router (e.g., a 6LBR) a specific role in this protocol. This needs 284 further discussion. 286 5. Another way of doing it 288 Given the questionable usability of the IPv6 hop-by-hop option, 289 another approach is to rely on the increasing on-path inspection 290 capabilities of modern routers. ALFI probes are sent as UDP packets, 291 with a 20-byte payload as depicted in Figure 2: 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | 0x24680000 | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | 0x2112A442 | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | parity | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | random | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Initial-Fragment MUALTU | Following-Fragment MUALTU | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 2: A STUN-line UDP payload 307 The parity field is computed to make the 32-bit XOR of all five words 308 zero (even parity). The random field is filled with a suitable 309 pseudorandom number (with no requirement for cryptographic quality). 310 All parameters of the IP and UDP header are chosen as for the data 311 flow for which the MUALTU values are needed. 313 A router that implements ALFI needs to detect transiting UDP packets 314 that match the structure of the ALFI probe. When updating the 315 values, both the parity field in the ALFI payload and the UDP 316 checksum need to be updated as well. 318 5.1. Discussion 320 Carrying ALFI probes in UDP data packets enables correspondent nodes 321 on general purpose operating systems to send and receive these probes 322 without any special interface such as that defined in [RFC3542]. 324 For best quality of the header compression performance prediction, 325 ALFI probes are required to look very similar to the actual data 326 packets. This means this approach only works with protocols using 327 UDP payloads. For use with CoAP [I-D.ietf-core-coap], this is not a 328 problem. 330 The application protocol must be able to ignore packets that look 331 like ALFO probes. Again, for use with CoAP [I-D.ietf-core-coap], 332 this is not a problem. (The design might be refined to enable 333 interoperability with other protocols as desired.) 334 This approach routes around the damage done to the hop-by-hop header 335 by creating damage to the data transparency of the Internet. The 336 conditions under which this is an acceptable trade-off must be 337 carefully evaluated. 339 6. IANA Considerations 341 IANA needs to allocate an IPv6 option number for the ALFI option, 342 "Destination Options and Hop-by-Hop Options" registry in "Internet 343 Protocol Version 6 (IPv6) Parameters", with act=00 and chg=1 (i.e., 344 similar to the Quick-Start option [RFC4782]). 346 For the STUN-related approach described in {#hack}, the message type 347 0b10_010_011_1000 = 0x938 should be reserved in the STUN Methods 348 Registry. 350 7. Security Considerations 352 It is hard to like hop-by-hop options from a security point of view. 354 (This section will certainly grow as additional security 355 considerations beyond those listed in the base specifications become 356 known.) 358 8. Acknowledgements 360 Peter van der Stok prompted the author to finally write up this 361 protocol, a couple of years after the need for it had been shown in 362 [WEI]. He then also provided a number of editorial comments that 363 improved the document. 365 9. References 367 9.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 373 6 (IPv6) Specification", RFC 2460, December 1998. 375 9.2. Informative References 377 [I-D.bormann-6lowpan-roadmap] 378 Bormann, C., "6LoWPAN Roadmap and Implementation Guide", 379 draft-bormann-6lowpan-roadmap-03 (work in progress), 380 October 2012. 382 [I-D.ietf-6lowpan-btle] 383 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 384 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 385 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 386 (work in progress), February 2013. 388 [I-D.ietf-core-block] 389 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 390 draft-ietf-core-block-10 (work in progress), October 2012. 392 [I-D.ietf-core-coap] 393 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 394 "Constrained Application Protocol (CoAP)", draft-ietf- 395 core-coap-13 (work in progress), December 2012. 397 [I-D.ietf-lwig-terminology] 398 Bormann, C. and M. Ersue, "Terminology for Constrained 399 Node Networks", draft-ietf-lwig-terminology-01 (work in 400 progress), February 2013. 402 [I-D.mariager-6lowpan-v6over-dect-ule] 403 Mariager, P. and J. Petersen, "Transmission of IPv6 404 Packets over DECT Ultra Low Energy", draft-mariager- 405 6lowpan-v6over-dect-ule-02 (work in progress), May 2012. 407 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 408 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 409 3493, February 2003. 411 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 412 "Advanced Sockets Application Program Interface (API) for 413 IPv6", RFC 3542, May 2003. 415 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 416 Start for TCP and IP", RFC 4782, January 2007. 418 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 419 Discovery", RFC 4821, March 2007. 421 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 422 "Neighbor Discovery Optimization for IPv6 over Low-Power 423 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 424 November 2012. 426 [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded 427 Internet", ISBN 9780470747995, 2009. 429 Author's Address 431 Carsten Bormann 432 Universitaet Bremen TZI 433 Postfach 330440 434 Bremen D-28359 435 Germany 437 Phone: +49-421-218-63921 438 Email: cabo@tzi.org