idnits 2.17.1 draft-ietf-pwe3-fragmentation-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 582. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 80. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 87. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 93. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 173: '...ented packets is REQUIRED (see section...' RFC 2119 keyword, line 200: '...processing (NSP) MAY choose to fragmen...' RFC 2119 keyword, line 226: '... the sender MAY use fragmentation. ...' RFC 2119 keyword, line 231: '...se fragmentation MUST be configured in...' RFC 2119 keyword, line 271: '... Control] SHOULD be used to set the...' (21 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2005) is 6699 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) == Missing Reference: 'BCP0068' is mentioned on line 476, but not defined == Missing Reference: 'RFC2434' is mentioned on line 490, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 1981 (ref. 'PATHMTUv6') (Obsoleted by RFC 8201) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Andrew G. Malis 3 Document: draft-ietf-pwe3-fragmentation-10.txt Tellabs 4 Expires: May 2006 W. Mark Townsley 5 Cisco Systems 6 November 2005 8 PWE3 Fragmentation and Reassembly 10 IPR Statement 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Status of this Memo 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet-Drafts 27 as reference material or to cite them other than as "work in 28 progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document defines a generalized method of performing 39 fragmentation for use by Pseudo Wire Emulation Edge to Edge (PWE3) 40 protocols and services. 42 Table of Contents 44 1. Intellectual Property Statement...............................2 45 2. Overview......................................................3 46 3. Alternatives to PWE3 Fragmentation/Reassembly.................5 47 4. PWE3 Fragmentation With MPLS..................................5 48 4.1 Fragment Bit Locations For MPLS...........................6 49 4.2 Other Considerations......................................6 50 5. PWE3 Fragmentation With L2TP..................................6 51 5.1 PW-specific Fragmentation vs. IP fragmentation............7 52 PWE3 Fragmentation and Reassembly November 2005 54 5.2 Advertising Reassembly Support in L2TP....................7 55 5.3 L2TP Maximum Receive Unit (MRU) AVP.......................8 56 5.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP..........8 57 5.5 Fragment Bit Locations For L2TPv3 Encapsulation...........9 58 5.6 Fragment Bit Locations for L2TPv2 Encapsulation...........9 59 6. Security Considerations.......................................9 60 7. IANA Considerations..........................................10 61 7.1 Control Message Attribute Value Pairs (AVPs).............10 62 7.2 Default L2-Specific Sublayer bits........................11 63 7.3 Leading Bits of the L2TPv2 Message Header................11 64 8. Acknowledgements.............................................11 65 9. Normative References.........................................11 66 10. Informative References......................................12 67 11. Full Copyright Statement....................................13 68 12. Authors' Addresses..........................................13 69 13. Appendix A: Relationship Between This Document and RFC 1990.13 71 1. Intellectual Property Statement 73 The IETF takes no position regarding the validity or scope of any 74 Intellectual Property Rights or other rights that might be claimed 75 to pertain to the implementation or use of the technology described 76 in this document or the extent to which any license under such 77 rights might or might not be available; nor does it represent that 78 it has made any independent effort to identify any such rights. 79 Information on the procedures with respect to rights in RFC 80 documents can be found in BCP 78 and BCP 79. 82 Copies of IPR disclosures made to the IETF Secretariat and any 83 assurances of licenses to be made available, or the result of an 84 attempt made to obtain a general license or permission for the use 85 of such proprietary rights by implementers or users of this 86 specification can be obtained from the IETF on-line IPR repository 87 at http://www.ietf.org/ipr. 89 The IETF invites any interested party to bring to its attention any 90 copyrights, patents or patent applications, or other proprietary 91 rights that may cover technology that may be required to implement 92 this standard. Please address the information to the IETF at ietf- 93 ipr@ietf.org. 95 PWE3 Fragmentation and Reassembly November 2005 97 2. Overview 99 The Pseudo Wire Emulation Edge to Edge Architecture Document 100 [Architecture] defines a network reference model for PWE3: 102 |<-------------- Emulated Service ---------------->| 103 | | 104 | |<------- Pseudo Wire ------>| | 105 | | | | 106 | | |<-- PSN Tunnel -->| | | 107 | PW End V V V V PW End | 108 V Service +----+ +----+ Service V 109 +-----+ | | PE1|==================| PE2| | +-----+ 110 | |----------|............PW1.............|----------| | 111 | CE1 | | | | | | | | CE2 | 112 | |----------|............PW2.............|----------| | 113 +-----+ ^ | | |==================| | | ^ +-----+ 114 ^ | +----+ +----+ | | ^ 115 | | Provider Edge 1 Provider Edge 2 | | 116 | | | | 117 Customer | | Customer 118 Edge 1 | | Edge 2 119 | | 120 | | 121 native service native service 123 Figure 1: PWE3 Network Reference Model 125 A Pseudo Wire (PW) payload is normally relayed across the PW as a 126 single IP or MPLS Packet Switched Network (PSN) Protocol Data Unit 127 (PDU). However, there are cases where the combined size of the 128 payload and its associated PWE3 and PSN headers may exceed the PSN 129 path Maximum Transmission Unit (MTU). When a packet exceeds the MTU 130 of a given network, fragmentation and reassembly will allow the 131 packet to traverse the network and reach its intended destination. 133 The purpose of this document is to define a generalized method of 134 performing fragmentation for use with all PWE3 protocols and 135 services. This method should be utilized only in cases where MTU- 136 management methods fail. Due to the increased processing overhead, 137 fragmentation and reassembly in core network devices should always 138 be considered something to avoid whenever possible. 140 PWE3 Fragmentation and Reassembly November 2005 142 The PWE3 fragmentation and reassembly domain is shown in Figure 2: 144 |<-------------- Emulated Service ---------------->| 145 | |<---Fragmentation Domain--->| | 146 | ||<------- Pseudo Wire ---->|| | 147 | || || | 148 | || |<-- PSN Tunnel -->| || | 149 | PW End VV V V VV PW End | 150 V Service +----+ +----+ Service V 151 +-----+ | | PE1|==================| PE2| | +-----+ 152 | |----------|............PW1.............|----------| | 153 | CE1 | | | | | | | | CE2 | 154 | |----------|............PW2.............|----------| | 155 +-----+ ^ | | |==================| | | ^ +-----+ 156 ^ | +----+ +----+ | | ^ 157 | | Provider Edge 1 Provider Edge 2 | | 158 | | | | 159 Customer | | Customer 160 Edge 1 | | Edge 2 161 | | 162 | | 163 native service native service 165 Figure 2: PWE3 Fragmentation/Reassembly Domain 167 Fragmentation takes place in the transmitting PE immediately prior 168 to PW encapsulation, and reassembly takes place in the receiving PE 169 immediately after PW decapsulation. 171 Since a sequence number is necessary for the fragmentation and 172 reassembly procedures, using the Sequence Number field on 173 fragmented packets is REQUIRED (see sections 4.1 and 5.5 for the 174 location of the Sequence Number fields for MPLS and L2TPv3 175 encapsulations respectively). The order of operation is that first 176 fragmentation is performed, and then the resulting fragments are 177 assigned sequential sequence numbers. 179 Depending on the specific PWE3 encapsulation in use, the value 0 180 may not be a part of the sequence number space, in which case its 181 use for fragmentation must follow this same rule - as the sequence 182 number is incremented, it skips zero and wraps from 65535 to 1. 183 Conversely, if the value 0 is part of the sequence space, then the 184 same sequence space is also used for fragmentation and reassembly. 186 PWE3 Fragmentation and Reassembly November 2005 188 3. Alternatives to PWE3 Fragmentation/Reassembly 190 Fragmentation and reassembly in network equipment generally 191 requires significantly greater resources than sending a packet as a 192 single unit. As such, fragmentation and reassembly should be 193 avoided whenever possible. Ideal solutions for avoiding 194 fragmentation include proper configuration and management of MTU 195 sizes between the Customer Edge (CE) router, Provider Edge (PE) 196 router, and across the PSN, as well as adaptive measures which 197 operate with the originating host [e.g. [PATHMTU], [PATHMTUv6]] to 198 reduce the packet sizes at the source. 200 A PE's native service processing (NSP) MAY choose to fragment a 201 packet before allowing it to enter a PW. For example, if an IP 202 packet arrives from a CE with an MTU which will yield a PW packet 203 which is greater than the PSN MTU, the PE NSP may perform IP 204 fragmentation on the packet, also replicating the L2 header for the 205 IP fragments. This effectively creates two (or more) packets, each 206 carrying an IP fragment preceded by an L2 header, for transport 207 individually across the PW. The receiving PE is unaware that the 208 originating host did not perform the IP fragmentation, and as such 209 does not treat the PW packets in any special way. This ultimately 210 has the affect of placing the burden of fragmentation on the PE 211 NSP, and reassembly on the IP destination host. 213 4. PWE3 Fragmentation With MPLS 215 When using the signaling procedures in [MPLS-Control], there is a 216 Pseudowire Interface Parameter Sub-TLV type used to signal the use 217 of fragmentation when advertising a VC label[IANA]: 219 Parameter Length Description 220 0x09 2 Fragmentation indicator 222 The presence of this parameter in the VC FEC element indicates that 223 the receiver is able to reassemble fragments when the control word 224 is in use for the VC label being advertised. It does not obligate 225 the sender to use fragmentation; it is simply an indication that 226 the sender MAY use fragmentation. The sender MUST NOT use 227 fragmentation if this parameter is not present in the VC FEC 228 element. 230 If [MPLS-Control] signaling is not in use, then whether or not to 231 use fragmentation MUST be configured in the sender. 233 PWE3 Fragmentation and Reassembly November 2005 235 4.1 Fragment Bit Locations For MPLS 237 MPLS-based PWE3 uses the following control word format [Control- 238 Word], with the B and E fragmentation bits identified in position 8 239 and 9: 241 0 1 2 3 242 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 |0 0 0 0| Flags |B|E| Length | Sequence Number | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 3: Preferred PW MPLS Control Word 249 The B and E bits are defined as follows: 251 BE 252 -- 253 00 indicates that the entire (un-fragmented) payload is carried 254 in a single packet 255 01 indicates the packet carrying the first fragment 256 10 indicates the packet carrying the last fragment 257 11 indicates a packet carrying an intermediate fragment 259 See Appendix A for a discussion of the derivation of these values 260 for the B and E bits. 262 See section 2 for the description of the use of the Sequence Number 263 field. 265 4.2 Other Considerations 267 Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine 268 the maximum size for fragments. The application of path MTU to MPLS 269 is discussed in [LABELSTACK]. The maximum size of the fragments may 270 also be configured. The signaled Interface MTU parameter in [MPLS- 271 Control] SHOULD be used to set the maximum size of the reassembly 272 buffer for received packets to make optimal use of reassembly 273 buffer resources. 275 5. PWE3 Fragmentation With L2TP 277 This section defines the location of the B and E bits for L2TPv3 278 [L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling 279 mechanism for advertising MRU (Maximum Receive Unit) values and 280 support for fragmentation on a given PW. As IP is the most common 281 PWE3 Fragmentation and Reassembly November 2005 283 PSN used with L2TP, IP PSN fragmentation and reassembly is 284 discussed as well. 286 5.1 PW-specific Fragmentation vs. IP fragmentation 288 When proper MTU management across a network fails, IP PSN 289 fragmentation and reassembly may be used to accommodate MTU 290 mismatches between tunnel endpoints. If the overall traffic 291 requiring fragmentation and reassembly is very light, or there are 292 sufficient optimized mechanisms for IP PSN fragmentation and 293 reassembly available, IP PSN fragmentation and reassembly may be 294 sufficient. 296 When facing a large number of PW packets requiring fragmentation 297 and reassembly, a PW-specific method has properties that 298 potentially allow for more resource-friendly implementations. 299 Specifically, the ability to assign buffer usage on a per-PW basis 300 and PW sequencing may be utilized to gain advantage over a general 301 mechanism applying to all IP packets across all PWs. Further, PW 302 fragmentation may be more easily enabled in a selective manner for 303 some or all PWs, rather than enabling reassembly for all IP traffic 304 arriving at a given node. 306 Deployments SHOULD avoid a situation which uses a combination of IP 307 PSN and PW fragmentation and reassembly on the same node. Such 308 operation clearly defeats the purpose behind the mechanism defined 309 in this document. This is especially important for L2TPv3 310 pseudowires, since potentially fragmentation can take place in 311 three different places (the IP PSN, the PW, and the encapsulated 312 payload). Care must be taken to ensure that the MTU/MRU values are 313 set and advertised properly at each tunnel endpoint to avoid this. 314 When fragmentation is enabled within a given PW, the DF bit MUST be 315 set on all L2TP over IP packets for that PW. 317 L2TPv3 nodes SHOULD participate in Path MTU [PATHMTU], [PATHMTUv6] 318 for automatic adjustment of the PSN MTU. When the payload is IP, 319 Path MTU should be used at they payload level as well. 321 5.2 Advertising Reassembly Support in L2TP 323 The constructs defined in this section for advertising 324 fragmentation support in L2TP are applicable to [L2TPv3] and 325 [L2TPv2]. 327 This document defines two new AVPs to advertise maximum receive 328 unit values and reassembly support. These AVPs MAY be present in 329 the ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, or SLI messages. The most 330 recent value received always takes precedence over a previous 331 value, and MUST be dynamic over the life of the session if received 332 PWE3 Fragmentation and Reassembly November 2005 334 via the SLI message. One of the two new AVPs (MRRU) is used to 335 advertise that PWE3 reassembly is supported by the sender of the 336 AVP. Reassembly support MAY be unidirectional. 338 5.3 L2TP Maximum Receive Unit (MRU) AVP 340 0 1 341 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | MRU | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 MRU (Maximum Receive Unit), attribute number TBD1, is the maximum 347 size in octets of a fragmented or complete PW frame, including L2TP 348 encapsulation, receivable by the side of the PW advertising this 349 value. The advertised MRU does NOT include the PSN header (i.e. the 350 IP and/or UDP header). This AVP does not imply that PWE3 351 fragmentation or reassembly is supported. If reassembly is not 352 enabled or unavailable, this AVP may be used alone to advertise the 353 MRU for a complete frame. 355 This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) 356 bit for this AVP SHOULD be set to 0. The Length (before hiding) is 357 8. The Vendor ID is the IETF Vendor ID of 0. 359 5.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP 361 0 1 362 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | MRRU | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 MRRU (Maximum Reassembled Receive Unit AVP), attribute number TBD2, 368 is the maximum size in octets of a reassembled frame, including any 369 PW framing, but not including the L2TP encapsulation or L2-specific 370 sublayer. Presence of this AVP signifies the ability to receive PW 371 fragments and reassemble them. Packet fragments MUST NOT be sent by 372 a peer which has not received this AVP in a control message. If the 373 MRRU is present in a message, the MRU AVP MUST be present as well. 375 The MRRU SHOULD be used to set the maximum size of the reassembly 376 buffer for received packets to make optimal use of reassembly 377 buffer resources. 379 This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) 380 bit for this AVP SHOULD be set to 0. The Length (before hiding) is 381 8. The Vendor ID is the IETF Vendor ID of 0. 383 PWE3 Fragmentation and Reassembly November 2005 385 5.5 Fragment Bit Locations For L2TPv3 Encapsulation 387 The usage of the B and E bits is described in Section 4.1. For 388 L2TPv3 encapsulation, the B and E bits are defined as bits 2 and 3 389 in the leading bits of the Default L2-Specific Sublayer (see 390 Section 7). 392 0 1 2 3 393 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 |x|S|B|E|x|x|x|x| Sequence Number | 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 Figure 4: B and E Bits Location in the Default L2-Specific Sublayer 400 The S (Sequence) bit is as defined in [L2TPv3]. Location of the B 401 and E bits for PW-Types which use a variant L2 specific sublayer 402 are outside the scope of this document. 404 When fragmentation is used, an L2-Specific Sublayer with B and E 405 bits defined MUST be present in all data packets for a given 406 session. The presence and format of the L2-Specific Sublayer is 407 advertised via the L2-Specific Sublayer AVP, Attribute Type 69, 408 defined in section 5.4.4 of [L2TPv3]. 410 See section 2 for the description of the use of the Sequence Number 411 field. 413 5.6 Fragment Bit Locations for L2TPv2 Encapsulation 415 The usage of the B and E bits is described in Section 4.1. For 416 L2TPv2 encapsulation, the B and E bits are defined as bits 8 and 9 417 in the leading bits of the L2TPv2 header as depicted below (see 418 Section 7). 420 0 1 2 3 421 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 |T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 5: B and E bits location in the L2TPv2 Message Header 428 6. Security Considerations 430 As with any additional protocol construct, each level of complexity 431 adds the potential to exploit protocol and implementation errors. 433 PWE3 Fragmentation and Reassembly November 2005 435 Implementers should be especially careful of not tying up an 436 abundance of resources, even for the most pathological combination 437 of packet fragments that could be received. Beyond these issues of 438 general implementation quality, there are no known notable security 439 issues with using the mechanism defined in this document. It 440 should be pointed out that RFC 1990, on which this document is 441 based, and its derivatives have been widely implemented and 442 extensively used in the Internet and elsewhere. 444 [IPFRAG-SEC] and [TINYFRAG] describe potential network attacks 445 associated with IP fragmentation and reassembly. The issues 446 described in these documents attempt to bypass IP access controls 447 by sending various carefully formed "tiny fragments", or by 448 exploiting the IP offset field to cause fragments to overlap and 449 rewrite interesting portions of an IP packet after access checks 450 have been performed. The latter is not an issue with the PW- 451 specific fragmentation method described in this document as there 452 is no offset field; However, implementations MUST be sure to not 453 allow more than one whole fragment to overwrite another in a 454 reconstructed frame. The former may be a concern if packet 455 filtering and access controls are being placed on tunneled frames 456 within the PW encapsulation. To circumvent any possible attacks in 457 either case, all filtering and access controls should be applied to 458 the resulting reconstructed frame rather than any PW fragments. 460 7. IANA Considerations 462 This document does not define any new registries for IANA to 463 maintain. 465 Note that [IANA] has already allocated the Fragmentation Indicator 466 interface parameter, so no further IANA action is required. 468 This document requires IANA to assign new values for registries 469 already managed by IANA (see Sections 7.1 and 7.2), and two 470 reserved bits in an existing header (see Section 7.3). 472 7.1 Control Message Attribute Value Pairs (AVPs) 474 Two additional AVP Attributes are specified in Section 5.3 and 475 Section 5.4. They are required to be defined by IANA as described 476 in Section 2.2 of [BCP0068]. 478 Control Message Attribute Value Pairs 479 ------------------------------------- 481 TBD1 - Maximum Receive Unit (MRU) AVP 482 TBD2 - Maximum Reassembled Receive Unit (MRRU) AVP 483 PWE3 Fragmentation and Reassembly November 2005 485 7.2 Default L2-Specific Sublayer bits 487 This registry was created as part of the publication of [L2TPv3]. 488 This document defines two reserved bits in the Default L2-Specific 489 Sublayer in Section 5.5, which may be assigned by IETF Consensus 490 [RFC2434]. They are required to be assigned by IANA. 492 Default L2-Specific Sublayer bits - per [L2TPv3] 493 --------------------------------- 495 Bit 2 - B (Fragmentation) bit 496 Bit 3 - E (Fragmentation) bit 498 7.3 Leading Bits of the L2TPv2 Message Header 500 This document requires definition of two reserved bits in the 501 L2TPv2 [L2TPv2] header. Locations are noted by the "B" and "E" bits 502 in section 5.6. 504 Leading Bits of the L2TPv2 Message Header 505 ----------------------------------------- 507 Bit 8 - B (Fragmentation) bit 508 Bit 9 - E (Fragmentation) bit 510 8. Acknowledgements 512 The authors wish to thank Eric Rosen and Carlos Pignataro, both of 513 Cisco Systems, for their review of this document. 515 9. Normative References 517 [Control-Word] Bryant, S. et al, "PWE3 Control Word for use over an 518 MPLS PSN", draft-ietf-pwe3-cw-06.txt, October 2005, work in 519 progress 521 [IANA] Martini, L. et al, "IANA Allocations for pseudo Wire Edge 522 to Edge Emulation (PWE3)", draft-ietf-pwe3-iana-allocation- 523 15.txt, November 2005, work in progress 525 [LABELSTACK] Rosen, E. et al, "MPLS Label Stack Encoding", RFC 526 3032, January 2001 528 [L2TPv2] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer Two 529 Tunneling Protocol 'L2TP'", RFC 2661, June 1999 530 PWE3 Fragmentation and Reassembly November 2005 532 [L2TPv3] Lau, J. et al, "Layer Two Tunneling Protocol - Version 533 3 (L2TPv3)", RFC 3931, March 2005. 535 [MLPPP] Sklower, K. et al, "The PPP Multilink Protocol (MP)", RFC 536 1990, August 1996 538 [MPLS-Control] Martini, L. et al, "Pseudowire Setup and Maintenance 539 using the Label Distribution Protocol", draft-ietf-pwe3- 540 control-protocol-17.txt, June 2005, work in progress 542 [PATHMTU] Mogul, J. C. et al, "Path MTU Discovery", RFC 1191, 543 November 1990 545 [PATHMTUv6] McCann, J. et al, "Path MTU Discovery for IP version 546 6", RFC 1981, August 1996 548 10. Informative References 550 [Architecture] Bryant, S. et al, "Pseudo Wire Emulation Edge-to- 551 Edge (PWE3) Architecture", RFC 3985, March 2005 553 [FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport 554 (FAST)", af-fbatm-0151.000, July 2000 556 [FRF.12] Frame Relay Forum, "Frame Relay Fragmentation 557 Implementation Agreement", FRF.12, December 1997 559 [IPFRAG-SEC] Ziemba, G., Reed, D., Traina, P., "Security 560 Considerations for IP Fragment Filtering", RFC 1858, October 561 1995 563 [TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny 564 Fragment Attack", RFC 3128, June 2001 565 PWE3 Fragmentation and Reassembly November 2005 567 11. Full Copyright Statement 569 Copyright (C) The Internet Society (2005). 571 This document is subject to the rights, licenses and restrictions 572 contained in BCP 78, and except as set forth therein, the authors 573 retain all their rights. 575 This document and the information contained herein are provided on 576 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 577 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 578 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 579 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 580 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 581 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 582 PARTICULAR PURPOSE. 584 12. Authors' Addresses 586 Andrew G. Malis 587 Tellabs 588 90 Rio Robles Drive 589 San Jose, CA 95134 590 Email: Andy.Malis@tellabs.com 592 W. Mark Townsley 593 Cisco Systems 594 7025 Kit Creek Road 595 PO Box 14987 596 Research Triangle Park, NC 27709 597 Email: mark@townsley.net 599 13. Appendix A: Relationship Between This Document and RFC 1990 601 The fragmentation of large packets into smaller units for 602 transmission is not new. One fragmentation and reassembly method 603 was defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was 604 also adopted for both Frame Relay [FRF.12] and ATM [FAST] network 605 technology. This document adopts the RFC 1990 fragmentation and 606 reassembly procedures as well, with some distinct modifications 607 described in this appendix. Familiarity with RFC 1990 is assumed. 609 RFC 1990 was designed for use in environments where packet 610 fragments may arrive out of order due to their transmission on 611 multiple parallel links, specifying that buffering be used to place 612 the fragments in correct order. For PWE3, the ability to reorder 613 fragments prior to reassembly is OPTIONAL; receivers MAY choose to 614 PWE3 Fragmentation and Reassembly November 2005 616 drop frames when a lost fragment is detected. Thus, when the 617 sequence number on received fragments shows that a fragment has 618 been skipped, the partially reassembled packet MAY be dropped, or 619 the receiver MAY wish to wait for the fragment to arrive out of 620 order. In the latter case, a reassembly timer MUST be used to 621 avoid locking up buffer resources for too long a period. 623 Dropping out-of-order fragments on a given PW can provide a 624 considerable scalability advantage for network equipment performing 625 reassembly. If out-of-order fragments are a relatively rare event 626 on a given PW, throughput should not be adversely affected by this. 627 Note, however, if there are cases where fragments of a given frame 628 are received out-or-order in a consistent manner (e.g. a short 629 fragment is always switched ahead of a larger fragment) then 630 dropping out-of-order fragments will cause the fragmented frame to 631 never be received. This condition may result in an effective denial 632 of service to a higher-lever application. As such, implementations 633 fragmenting a PW frame MUST at the very least ensure that all 634 fragments are sent in order from their own egress point. 636 An implementation may also choose to allow reassembly of a limited 637 number of fragmented frames on a given PW, or across a set of PWs 638 with reassembly enabled. This allows for a more even distribution 639 of reassembly resources, reducing the chance of a single or small 640 set of PWs exhausting all reassembly resources for a node. As with 641 dropping out-of-order fragments, there are perceivable cases where 642 this may also provide an effective denial of service. For example, 643 if fragments of multiple frames are consistently received before 644 each frame can be reconstructed in a set of limited PW reassembly 645 buffers, then a set of these fragmented frames will never be 646 delivered. 648 RFC 1990 headers use two bits which indicate the first and last 649 fragments in a frame, and a sequence number. The sequence number 650 may be either 12 or 24 bits in length (from [MLPPP]): 652 0 7 8 15 653 +-+-+-+-+-------+---------------+ 654 |B|E|0|0| sequence number | 655 +-+-+-+-+-------+---------------+ 657 +-+-+-+-+-+-+-+-+---------------+ 658 |B|E|0|0|0|0|0|0|sequence number| 659 +-+-+-+-+-+-+-+-+---------------+ 660 | sequence number (L) | 661 +---------------+---------------+ 663 Figure 6: RFC 1990 Header Formats 665 PWE3 Fragmentation and Reassembly November 2005 667 PWE3 fragmentation takes advantage of existing PW sequence numbers 668 and control bit fields wherever possible, rather than defining a 669 separate header exclusively for the use of fragmentation. Thus, it 670 uses neither of the RFC 1990 sequence number formats described 671 above, relying instead on the sequence number that already exists 672 in the PWE3 header. 674 RFC 1990 defines a two one-bit fields, a (B)eginning fragment bit 675 and an (E)nding fragment bit. The B bit is set to 1 on the first 676 fragment derived from a PPP packet and set to 0 for all other 677 fragments from the same PPP packet. The E bit is set to 1 on the 678 last fragment and set to 0 for all other fragments. A complete 679 unfragmented frame has both the B and E bits set to 1. 681 PWE3 fragmentation inverts the value of the B and E bits, while 682 retaining the operational concept of marking the beginning and 683 ending of a fragmented frame. Thus, for PW the B bit is set to 0 on 684 the first fragment derived from a PW frame and set to 1 for all 685 other fragments derived from the same frame. The E bit is set to 0 686 on the last fragment and set to 1 for all other fragments. A 687 complete unfragmented frame has both the B and E bits set to 0. The 688 motivation behind this value inversion for the B and E bits is to 689 allow complete frames (and particularly, implementations that only 690 support complete frames) to simply leave the B and E bits in the 691 header set 0. 693 In order to support fragmentation, the B and E bits MUST be defined 694 or identified for all PWE3 tunneling protocols. Sections 4 and 5 695 define these locations for PWE3 MPLS [Control-Word], L2TPv2 696 [L2TPv2], and L2TPv3 [L2TPv3] tunneling protocols.