idnits 2.17.1 draft-ietf-pwe3-fragmentation-06.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 75. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 88. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 183: '... A PE MAY choose to fragment a pack...' RFC 2119 keyword, line 209: '... that the sender MAY use fragmentation...' RFC 2119 keyword, line 214: '... fragmentation MUST be provisioned i...' RFC 2119 keyword, line 255: '...eld on fragmented packets is REQUIRED....' RFC 2119 keyword, line 263: '... TRANS] SHOULD be used to set the m...' (18 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 (September 2004) is 7161 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) ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-arch (ref. 'Architecture') == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-14 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-atm-encap-06 == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-07 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-frame-relay-02 == Outdated reference: A later version (-05) exists of draft-ietf-pwe3-satop-01 == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-08 ** Obsolete normative reference: RFC 1981 (ref. 'PATHMTUv6') (Obsoleted by RFC 8201) Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Andrew G. Malis 2 Document: draft-ietf-pwe3-fragmentation-06.txt Tellabs 3 Expires: March 2004 W. Mark Townsley 4 Cisco Systems 5 September 2004 7 PWE3 Fragmentation and Reassembly 9 IPR Statement 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Status of this Memo 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than a "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Abstract 37 This document defines a generalized method of performing 38 fragmentation for use by PWE3 protocols and services. 40 Table of Contents 42 1. Intellectual Property Statement...............................2 43 2. Overview......................................................2 44 3. Alternatives to PWE3 Fragmentation/Reassembly.................4 45 4. PWE3 Fragmentation With MPLS..................................5 46 4.1 Fragment Bit Locations For MPLS...........................5 47 4.2 Other Considerations......................................6 48 5. PWE3 Fragmentation With L2TP..................................6 49 5.1 PW-specific Fragmentation vs. IP fragmentation............6 50 5.2 Advertising Reassembly Support in L2TP....................7 51 PWE3 Fragmentation and Reassembly September 2004 53 5.3 L2TP Maximum Receive Unit (MRU) AVP.......................7 54 5.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP..........8 55 5.5 Fragment Bit Locations For L2TPv3 Encapsulation...........8 56 5.6 Fragment Bit Locations for L2TPv2 Encapsulation...........9 57 6. Security Considerations.......................................9 58 7. IANA Considerations..........................................10 59 8. Acknowledgements.............................................10 60 9. Normative References.........................................10 61 10. Informative References......................................11 62 11. Full Copyright Statement....................................12 63 12. Authors' Addresses..........................................12 64 13. Appendix A: Relationship Between This Document and RFC 1990.12 66 1. Intellectual Property Statement 68 The IETF takes no position regarding the validity or scope of any 69 Intellectual Property Rights or other rights that might be claimed 70 to pertain to the implementation or use of the technology described 71 in this document or the extent to which any license under such 72 rights might or might not be available; nor does it represent that 73 it has made any independent effort to identify any such rights. 74 Information on the procedures with respect to rights in RFC 75 documents can be found in BCP 78 and BCP 79. 77 Copies of IPR disclosures made to the IETF Secretariat and any 78 assurances of licenses to be made available, or the result of an 79 attempt made to obtain a general license or permission for the use 80 of such proprietary rights by implementers or users of this can be 81 obtained from the IETF on-line IPR repository at 82 http://www.ietf.org/ipr. 84 The IETF invites any interested party to bring to its attention any 85 copyrights, patents or patent applications, or other proprietary 86 rights that may cover technology that may be required to implement 87 this standard. Please address the information to the IETF at ietf- 88 ipr@ietf.org. 90 2. Overview 92 The PWE3 Architecture Document [Architecture] defines a network 93 reference model for PWE3: 95 PWE3 Fragmentation and Reassembly September 2004 97 |<-------------- Emulated Service ---------------->| 98 | | 99 | |<------- Pseudo Wire ------>| | 100 | | | | 101 | | |<-- PSN Tunnel -->| | | 102 | PW End V V V V PW End | 103 V Service +----+ +----+ Service V 104 +-----+ | | PE1|==================| PE2| | +-----+ 105 | |----------|............PW1.............|----------| | 106 | CE1 | | | | | | | | CE2 | 107 | |----------|............PW2.............|----------| | 108 +-----+ ^ | | |==================| | | ^ +-----+ 109 ^ | +----+ +----+ | | ^ 110 | | Provider Edge 1 Provider Edge 2 | | 111 | | | | 112 Customer | | Customer 113 Edge 1 | | Edge 2 114 | | 115 | | 116 native service native service 118 Figure 1: PWE3 Network Reference Model 120 A Pseudo Wire (PW) payload is normally relayed across the PW as a 121 single PSN (IP or MPLS) PDU. However, there are cases where the 122 combined size of the payload and its associated PWE3 and PSN 123 headers may exceed the PSN path Maximum Transmission Unit (MTU). 124 When a packet exceeds the MTU of a given network, fragmentation and 125 reassembly will allow the packet to traverse the network and reach 126 its intended destination. 128 Fragmentation is also useful for real-time applications when the 129 payload to be transmitted in a PW, such as a low-speed TDM 130 multiframe structure, takes too much time to be encapsulated even 131 though it may fit within the PW MTU. In this case, the payload may 132 be fragmented for lower-latency transmission. 134 The purpose of this document is to define a generalized method of 135 performing fragmentation for use with all PWE3 protocols and 136 services. This method should be utilized only in cases where MTU- 137 management methods fail. Due to the increased processing overhead, 138 fragmentation and reassembly in core network devices should always 139 be considered something to avoid whenever possible. 141 The PWE3 fragmentation and reassembly domain is shown in Figure 2: 143 PWE3 Fragmentation and Reassembly September 2004 145 |<-------------- Emulated Service ---------------->| 146 | |<---Fragmentation Domain--->| | 147 | ||<------- Pseudo Wire ---->|| | 148 | || || | 149 | || |<-- PSN Tunnel -->| || | 150 | PW End VV V V VV PW End | 151 V Service +----+ +----+ Service V 152 +-----+ | | PE1|==================| PE2| | +-----+ 153 | |----------|............PW1.............|----------| | 154 | CE1 | | | | | | | | CE2 | 155 | |----------|............PW2.............|----------| | 156 +-----+ ^ | | |==================| | | ^ +-----+ 157 ^ | +----+ +----+ | | ^ 158 | | Provider Edge 1 Provider Edge 2 | | 159 | | | | 160 Customer | | Customer 161 Edge 1 | | Edge 2 162 | | 163 | | 164 native service native service 166 Figure 2: PWE3 Fragmentation/Reassembly Domain 168 Fragmentation takes place in the transmitting PE immediately prior 169 to PW insertion, and reassembly takes place in the receiving PE 170 immediately after PW extraction. 172 3. Alternatives to PWE3 Fragmentation/Reassembly 174 Fragmentation and reassembly in network equipment generally 175 requires significantly greater resources than sending a packet as a 176 single unit. As such, fragmentation and reassembly should be 177 avoided whenever possible. Ideal solutions for avoiding 178 fragmentation include proper configuration and management of MTU 179 sizes between the CE, PE and across the PSN, as well as adaptive 180 measures which operate with the originating host [e.g. [PATHMTU], 181 [PATHMTUv6]] to reduce the packet sizes at the source. 183 A PE MAY choose to fragment a packet before allowing it to enter a 184 PW. For example, if an IP packet arrives from a CE with an MTU 185 which will yield a PW packet which is greater than the PW MTU, the 186 PE may perform IP fragmentation on the packet. This effectively 187 creates two (or more) packets, each carrying an IP fragment, for 188 transport individually across the PW. The receiving PE is unaware 189 PWE3 Fragmentation and Reassembly September 2004 191 that the originating host did not perform the IP fragmentation, and 192 as such does not treat the PW packets in any special way. This 193 ultimately has the affect of placing the burden of fragmentation on 194 the PE, and reassembly on the IP destination host. 196 4. PWE3 Fragmentation With MPLS 198 When using the signaling procedures in [MPLS-TRANS], there is a 199 Virtual Circuit FEC element parameter ID used to signal the use of 200 fragmentation when advertising a VC label: 202 Parameter ID Length Description 203 0x09 2 Fragmentation indicator 205 The presence of this parameter ID in the VC FEC element indicates 206 that the receiver is able to reassemble fragments when the control 207 word is in use for the VC label being advertised. It does not 208 obligate the sender to use fragmentation; it is simply an 209 indication that the sender MAY use fragmentation. The sender MUST 210 NOT use fragmentation if this parameter ID is not present in the VC 211 FEC element. 213 If [MPLS-TRANS] signaling is not in use, then whether or not to use 214 fragmentation MUST be provisioned in the sender. 216 4.1 Fragment Bit Locations For MPLS 218 MPLS-based PWE3 [MPLS-ATM], [MPLS-Ethernet], [MPLS-FR], [MPLS- 219 SATOP] uses the following control word format, with the B and E 220 fragmentation bits identified in position 8 and 9: 222 0 1 2 3 223 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 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | Rsvd | Flags |B|E| Length | Sequence Number | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 Figure 3: MPLS PWE3 Control Word 230 PWE3 Fragmentation and Reassembly September 2004 232 The B and E bits are defined as follows: 234 BE 235 -- 236 00 indicates that the entire (un-fragmented) payload is carried 237 in a single packet 238 01 indicates the packet carrying the first fragment 239 10 indicates the packet carrying the last fragment 240 11 indicates a packet carrying an intermediate fragment 242 See Appendix A for a discussion of the derivation of these values 243 for the B and E bits. 245 The Sequence Number field is used as already specified in the above 246 encapsulation specifications. Specifically, depending on the 247 specific encapsulation in use, the value 0 may indicate that the 248 sequence number is not in use, in which case its use for 249 fragmentation must follow this same rule - as the sequence number 250 is incremented, it skips zero and wraps from 65535 to 1. 251 Conversely, if the value 0 is part of the sequence space (as in 252 [MPLS-SATOP]), then the same sequence space is also used for 253 fragmentation and reassembly. Since a sequence number is necessary 254 for the fragmentation and reassembly procedures, using the Sequence 255 Number field on fragmented packets is REQUIRED. 257 4.2 Other Considerations 259 Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine 260 the maximum size for fragments. The application of path MTU to MPLS 261 is discussed in [LABELSTACK]. The maximum size of the fragments may 262 also be provisioned. The signaled Interface MTU parameter in [MPLS- 263 TRANS] SHOULD be used to set the maximum size of the reassembly 264 buffer for received packets to make optimal use of reassembly 265 buffer resources. 267 5. PWE3 Fragmentation With L2TP 269 This section defines the location of the B and E bits for L2TPv3 270 [L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling 271 mechanism for advertising MRU (Maximum Receive Unit) values and 272 support for fragmentation on a given PW. As IP is the most common 273 PSN used with L2TP, IP fragmentation and reassembly is discussed as 274 well. 276 5.1 PW-specific Fragmentation vs. IP fragmentation 278 When proper MTU management across a network fails, IP fragmentation 279 and reassembly may be used to accommodate MTU mismatches between 280 PWE3 Fragmentation and Reassembly September 2004 282 tunnel endpoints. If the overall traffic requiring fragmentation 283 and reassembly is very light, or there are sufficient optimized 284 mechanisms for IP fragmentation and reassembly available, IP 285 fragmentation and reassembly may be sufficient. 287 When facing a large number of PW packets requiring fragmentation 288 and reassembly, a PW-specific method has properties that 289 potentially allow for more resource-friendly implementations. 290 Specifically, the ability to assign buffer usage on a per-PW basis 291 and PW sequencing may be utilized to gain advantage over a general 292 mechanism applying to all IP packets across all PWs. Further, PW 293 fragmentation may be more easily enabled in a selective manner for 294 some or all PWs, rather than enabling reassembly for all IP traffic 295 arriving at a given node. 297 Deployments MUST avoid a situation which relies upon a combination 298 of IP and PW fragmentation and reassembly on the same node. Such 299 operation clearly defeats the purpose behind the mechanism defined 300 in this document. Care must be taken to ensure that the MTU/MRU 301 values are set and advertised properly at each tunnel endpoint to 302 avoid this. When fragmentation is enabled within a given PW, the DF 303 bit MUST be set on all L2TP over IP packets for that PW. 305 L2TPv3 nodes SHOULD participate in Path MTU [PATHMTU], [PATHMTUv6] 306 for automatic adjustment of the PW MTU. 308 5.2 Advertising Reassembly Support in L2TP 310 The constructs defined in this section for advertising 311 fragmentation support in L2TP are applicable to [L2TPv3] and 312 [L2TPv2]. 314 This document defines two new AVPs to advertise maximum receive 315 unit values and reassembly support. These AVPs MAY be present in 316 the ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, or SLI messages. The most 317 recent value received always takes precedence over a previous 318 value, and MUST be dynamic over the life of the session if received 319 via the SLI message. One of the two new AVPs (MRRU) is used to 320 advertise that PWE3 reassembly is supported by the sender of the 321 AVP. Reassembly support MAY be unidirectional. 323 5.3 L2TP Maximum Receive Unit (MRU) AVP 325 0 1 326 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | MRU | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 PWE3 Fragmentation and Reassembly September 2004 332 MRU (Maximum Receive Unit), attribute number TBD1, is the maximum 333 size in octets of a fragmented or complete PW frame, including L2TP 334 encapsulation, receivable by the side of the PW advertising this 335 value. The advertised MRU does NOT include the PSN header (i.e. the 336 IP and/or UDP header). This AVP does not imply that PWE3 337 fragmentation or reassembly is supported. If reassembly is not 338 enabled or unavailable, this AVP may be used alone to advertise the 339 MRU for a complete frame. 341 All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, 342 and Vendor ID. This AVP may be hidden (the H bit may be 0 or 1). 343 The M bit for this AVP SHOULD be set to 0. The Length (before 344 hiding) is 8. The Vendor ID is the IETF Vendor ID of 0. 346 5.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP 348 0 1 349 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | MRRU | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 MRRU (Maximum Reassembled Receive Unit AVP), attribute number TBD2, 355 is the maximum size in octets of a reassembled frame, including any 356 PW framing, but not including the L2TP encapsulation or L2-specific 357 sublayer. Presence of this AVP signifies the ability to receive PW 358 fragments and reassemble them. Packet fragments MUST NOT be sent to 359 an implementation which has not received this value from its peer 360 in a control message. If the MRRU is present in a message, the MRU 361 AVP MUST be present as well. 363 All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, 364 and Vendor ID. This AVP may be hidden (the H bit may be 0 or 1). 365 The M bit for this AVP SHOULD be set to 0. The Length (before 366 hiding) is 8. The Vendor ID is the IETF Vendor ID of 0. 368 5.5 Fragment Bit Locations For L2TPv3 Encapsulation 370 The B and E bits are defined as bits 2 and 3 in the L2TPv3 default 371 L2-specific sublayer as depicted below, using the values defined in 372 section 3.1: 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 |x|S|B|E|x|x|x|x| Sequence Number | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 4: L2TPv3 over IP Header 382 PWE3 Fragmentation and Reassembly September 2004 384 The S bit is as defined in [L2TPv3]. Location of the B and E bits 385 for PW-Types which use a variant L2 specific sublayer are outside 386 the scope of this document. 388 Inclusion of the MRRU AVP in a control message suggests the need 389 for a control sublayer which includes sequence numbers and the B 390 and E bit fields. Thus, if reassembly support has been advertised, 391 and packet fragments are to be sent, then presence of this sublayer 392 and associated sequencing for all packet fragments MUST be enabled 393 as defined for the given PW-type. 395 5.6 Fragment Bit Locations for L2TPv2 Encapsulation 397 The B and E bits are defined as bits 8 and 9 for the L2TPv2 header 398 as depicted below (subject to IANA action), using the values 399 defined in section 3.1: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 |T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Tunnel ID | Session ID | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Ns (opt) | Nr (opt) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Offset Size (opt) | Offset pad... (opt) 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 Figure 5: L2TPv2 over UDP Header 415 6. Security Considerations 417 As with any additional protocol construct, each level of complexity 418 adds the potential to exploit protocol and implementation errors. 419 Implementers should be especially careful of not tying up an 420 abundance of resources, even for the most pathological combination 421 of packet fragments that could be received. Beyond these issues of 422 general implementation quality, there are no known notable security 423 issues with using the mechanism defined in this document. It 424 should be pointed out that RFC 1990, on which this document is 425 based, and its derivatives have been widely implemented and 426 extensively used in the Internet and elsewhere. 428 PWE3 Fragmentation and Reassembly September 2004 430 [IPFRAG-SEC] and [TINYFRAG] describe potential network attacks 431 associated with IP fragmentation and reassembly. The issues 432 described in these documents attempt to bypass IP access controls 433 by sending various carefully formed "tiny fragments", or by 434 exploiting the IP offset field to cause fragments to overlap and 435 rewrite interesting portions of an IP packet after access checks 436 have been performed. The latter is not an issue with the PW- 437 specific fragmentation method described in this document as there 438 is no offset field; However, implementations MUST be sure to not 439 allow more than one whole fragment to overwrite another in a 440 reconstructed frame. The former may be a concern if packet 441 filtering and access controls are being placed on tunneled frames 442 within the PW encapsulation. To circumvent any possible attacks in 443 either case, all filtering and access controls should be applied to 444 the resulting reconstructed frame rather than any PW fragments. 446 7. IANA Considerations 448 This document does not define any new values for IANA to maintain. 450 This document requires definition of two reserved bits in the 451 L2TPv2 [L2TPv2] header. Locations are noted by the "B" and "E" bits 452 in section 5.6. 454 This document requires IANA to assign two new L2TP "Control Message 455 Attribute Value Pairs" (TBD1 and TBD2 in this document). 457 8. Acknowledgements 459 Thanks to Eric Rosen for his review of this document. 461 9. Normative References 463 [Architecture] Bryant, S. et al, "PWE3 Architecture", draft-ietf- 464 pwe3-arch-07.txt, March 2004, work in progress 466 [LABELSTACK] Rosen, E. et al, "MPLS Label Stack Encoding", RFC 467 3032, January 2001 469 [L2TPv2] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer Two 470 Tunneling Protocol 'L2TP'", RFC 2661, June 1999 472 [L2TPv3] Lau, J. et al, "Layer Two Tunneling Protocol (Version 3) 473 'L2TPv3'", draft-ietf-l2tpext-l2tp-base-14.txt, June 2004, work 474 in progress 475 PWE3 Fragmentation and Reassembly September 2004 477 [MLPPP] Sklower, K. et al, "The PPP Multilink Protocol (MP)", RFC 478 1990, August 1996 480 [MPLS-ATM] Martini, L. et al, "Encapsulation Methods for Transport 481 of ATM Cells/Frame Over IP and MPLS Networks", draft-ietf-pwe3- 482 atm-encap-06.txt, July 2004, work in progress 484 [MPLS-Ethernet] Martini, L. et al, "Encapsulation Methods for 485 Transport of Ethernet Frames Over IP and MPLS Networks", draft- 486 ietf-pwe3-ethernet-encap-07.txt, July 2004, work in progress 488 [MPLS-FR] Martini, L. et al, "Frame Relay Encapsulation over 489 Pseudo-Wires", draft-ietf-pwe3-frame-relay-02.txt, February 490 2004, work in progress 492 [MPLS-SATOP] Vainshtein, A. et al, "Structure-Agnostic TDM over 493 Packet (SAToP)", draft-ietf-pwe3-satop-01.txt, December 2003, 494 work in progress 496 [MPLS-TRANS] Martini, L. et al, "Transport of Layer 2 Frames Over 497 MPLS", draft-ietf-pwe3-control-protocol-08.txt, July 2004, work 498 in progress 500 [PATHMTU] Mogul, J. C. et al, "Path MTU Discovery", RFC 1191, 501 November 1990 503 [PATHMTUv6] McCann, J. et al, "Path MTU Discovery for IP version 504 6", RFC 1981, August 1996 506 10. Informative References 508 [FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport 509 (FAST)", af-fbatm-0151.000, July 2000 511 [FRF.12] Frame Relay Forum, "Frame Relay Fragmentation 512 Implementation Agreement", FRF.12, December 1997 514 [IPFRAG-SEC] Ziemba, G., Reed, D., Traina, P., "Security 515 Considerations for IP Fragment Filtering", RFC 1858, October 516 1995 518 [TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny 519 Fragment Attack", RFC 3128, June 2001 520 PWE3 Fragmentation and Reassembly September 2004 522 11. Full Copyright Statement 524 Copyright (C) The Internet Society (2004). This document is 525 subject to the rights, licenses and restrictions contained in BCP 526 78 and except as set forth therein, the authors retain all their 527 rights. 529 This document and the information contained herein are provided on 530 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 531 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 532 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 533 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 534 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 535 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 536 PARTICULAR PURPOSE. 538 12. Authors' Addresses 540 Andrew G. Malis 541 Tellabs 542 90 Rio Robles Drive 543 San Jose, CA 95134 544 Email: Andy.Malis@tellabs.com 546 W. Mark Townsley 547 Cisco Systems 548 7025 Kit Creek Road 549 PO Box 14987 550 Research Triangle Park, NC 27709 551 Email: mark@townsley.net 553 13. Appendix A: Relationship Between This Document and RFC 1990 555 The fragmentation of large packets into smaller units for 556 transmission is not new. One fragmentation and reassembly method 557 was defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was 558 also adopted for both Frame Relay [FRF.12] and ATM [FAST] network 559 technology. This document adopts the RFC 1990 fragmentation and 560 reassembly procedures as well, with some distinct modifications 561 described in this appendix. Familiarity with RFC 1990 is assumed. 563 RFC 1990 was designed for use in environments where packet 564 fragments may arrive out of order due to their transmission on 565 multiple parallel links, specifying that buffering be used to place 566 the fragments in correct order. For PWE3, the ability to reorder 567 fragments prior to reassembly is OPTIONAL; receivers MAY choose to 568 drop frames when a lost fragment is detected. Thus, when the 569 PWE3 Fragmentation and Reassembly September 2004 571 sequence number on received fragments shows that a fragment has 572 been skipped, the partially reassembled packet MAY be dropped, or 573 the receiver MAY wish to wait for the fragment to arrive out of 574 order. In the latter case, a reassembly timer MUST be used to 575 avoid locking up buffer resources for too long a period. 577 Dropping out-of-order fragments on a given PW can provide a 578 considerable scalability advantage for network equipment performing 579 reassembly. If out-of-order fragments are a relatively rare event 580 on a given PW, throughput should not be adversely affected by this. 581 Note, however, if there are cases where fragments of a given frame 582 are received out-or-order in a consistent manner (e.g. a short 583 fragment is always switched ahead of a larger fragment) then 584 dropping out-of-order fragments will cause the fragmented frame to 585 never be received. This condition may result in an effective denial 586 of service to a higher-lever application. As such, implementations 587 fragmenting a PW frame MUST at the very least ensure that all 588 fragments are sent in order from their own egress point. 590 An implementation may also choose to allow reassembly of a limited 591 number of fragmented frames on a given PW, or across a set of PWs 592 with reassembly enabled. This allows for a more even distribution 593 of reassembly resources, reducing the chance of a single or small 594 set of PWs exhausting all reassembly resources for a node. As with 595 dropping out-of-order fragments, there are perceivable cases where 596 this may also provide an effective denial of service. For example, 597 if fragments of multiple frames are consistently received before 598 each frame can be reconstructed in a set of limited PW reassembly 599 buffers, then a set of these fragmented frames will never be 600 delivered. 602 RFC 1990 headers use two bits which indicate the first and last 603 fragments in a frame, and a sequence number. The sequence number 604 may be either 12 or 24 bits in length (from [MLPPP]): 606 0 7 8 15 607 +-+-+-+-+-------+---------------+ 608 |B|E|0|0| sequence number | 609 +-+-+-+-+-------+---------------+ 611 +-+-+-+-+-+-+-+-+---------------+ 612 |B|E|0|0|0|0|0|0|sequence number| 613 +-+-+-+-+-+-+-+-+---------------+ 614 | sequence number (L) | 615 +---------------+---------------+ 617 Figure 6: RFC 1990 Header Formats 619 PWE3 Fragmentation and Reassembly September 2004 621 PWE3 fragmentation takes advantage of existing PW sequence numbers 622 and control bit fields wherever possible, rather than defining a 623 separate header exclusively for the use of fragmentation. Thus, it 624 uses neither of the RFC 1990 sequence number formats described 625 above, relying instead on the sequence number that already exists 626 in the PWE3 header. 628 RFC 1990 defines a two one-bit fields, a (B)eginning fragment bit 629 and an (E)nding fragment bit. The B bit is set to 1 on the first 630 fragment derived from a PPP packet and set to 0 for all other 631 fragments from the same PPP packet. The E bit is set to 1 on the 632 last fragment and set to 0 for all other fragments. A complete 633 unfragmented frame has both the B and E bits set to 1. 635 PWE3 fragmentation inverts the value of the B and E bits, while 636 retaining the operational concept of marking the beginning and 637 ending of a fragmented frame. Thus, for PW the B bit is set to 0 on 638 the first fragment derived from a PW frame and set to 1 for all 639 other fragments derived from the same frame. The E bit is set to 0 640 on the last fragment and set to 1 for all other fragments. A 641 complete unfragmented frame has both the B and E bits set to 0. The 642 motivation behind this value inversion for the B and E bits is to 643 allow complete frames (and particularly, implementations that only 644 support complete frames) to simply leave the B and E bits in the 645 header set 0. 647 In order to support fragmentation, the B and E bits MUST be defined 648 or identified for all PWE3 tunneling protocols. Sections 3 and 4 649 define these locations for PWE3 MPLS [MPLS-TRANS], L2TPv2 [L2TPv2], 650 and L2TPv3 [L2TPv3] tunneling protocols.