idnits 2.17.1 draft-malis-pwe3-fragmentation-00.txt: -(255): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 137: '...y is OPTIONAL; receivers MAY choose to...' RFC 2119 keyword, line 140: '... reassembled packet MAY be dropped, or...' RFC 2119 keyword, line 141: '... the receiver MAY wish to wait for ...' RFC 2119 keyword, line 142: '...se, a reassembly timer MUST be used to...' RFC 2119 keyword, line 155: '...nting a PW frame MUST at the very leas...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (June 2002) is 7957 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FAST' -- Possible downref: Normative reference to a draft: ref. 'Framework' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-03 == Outdated reference: A later version (-01) exists of draft-martini-atm-encap-mpls-00 -- Possible downref: Normative reference to a draft: ref. 'MPLS-ATM' == Outdated reference: A later version (-01) exists of draft-martini-ethernet-encap-mpls-00 -- Possible downref: Normative reference to a draft: ref. 'MPLS-Ethernet' == Outdated reference: A later version (-01) exists of draft-martini-frame-encap-mpls-00 -- Possible downref: Normative reference to a draft: ref. 'MPLS-FR' == Outdated reference: A later version (-19) exists of draft-martini-l2circuit-trans-mpls-09 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. 'MPLS-TRANS') ** Obsolete normative reference: RFC 1981 (ref. 'PATHMTUv6') (Obsoleted by RFC 8201) ** Downref: Normative reference to an Informational RFC: RFC 1858 (ref. 'IPFRAG-SEC') ** Downref: Normative reference to an Informational RFC: RFC 3128 (ref. 'TINYFRAG') Summary: 7 errors (**), 0 flaws (~~), 7 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-malis-pwe3-fragmentation-00.txt Vivace Networks 4 Expires: December 2002 W. Mark Townsley 5 Cisco Systems 6 June 2002 8 PWE3 Fragmentation and Reassembly 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet-Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines a generalized method of performing 34 fragmentation for use by PWE3 protocols and services. 36 Table of Contents 38 1. Overview......................................................2 39 2. Fragmentation/Reassembly Specification........................3 40 3. PWE3 Fragmentation With MPLS..................................5 41 3.1 Fragment Bit Locations For MPLS...........................5 42 3.2 Other Considerations......................................6 43 4. PWE3 Fragmentation With L2TP..................................6 44 4.1 PW-specific Fragmentation vs. IP fragmentation............6 45 4.2 Advertising Reassembly Support in L2TP....................7 46 4.3 L2TP Maximum Receive Unit (MRU) AVP.......................7 47 4.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP..........8 48 4.5 Fragment Bit Locations For L2TPv3 Encapsulation...........8 49 4.6 Fragment Bit Locations for L2TPv2 Encapsulation...........9 50 5. Security Considerations.......................................9 51 6. IANA Considerations..........................................10 52 7. Acknowledgements.............................................10 53 8. References...................................................10 54 9. Authors' Addresses...........................................11 56 1. Overview 58 The PWE3 Framework Document [Framework] defines a network reference 59 model for PWE3: 61 |<------- Pseudo Wire ------>| 62 | |<-- PSN Tunnel -->| | 63 PW V V V V PW 64 End Service +----+ +----+ End Service 65 +-----+ | | PE1|==================| PE2| | +-----+ 66 | |----------|............PW1.............|----------| | 67 | CE1 | | | | | | | | CE2 | 68 | |----------|............PW2.............|----------| | 69 +-----+ | | |==================| | | +-----+ 70 Customer +----+ +----+ Customer 71 Edge 1 | Provider Edge 1 Provider Edge 2 | Edge 2 72 |<-------------- Emulated Service ---------------->| 74 Figure 1: PWE3 Network Reference Model 76 A Pseudo Wire (PW) payload is normally relayed across the PW as a 77 single PSN (IP or MPLS) PDU. However, there are cases where the 78 combined size of the payload and its associated PWE3 and PSN 79 headers may exceed the PSN path Maximum Transmission Unit (MTU). 80 When a packet exceeds the MTU of a given network, fragmentation and 81 reassembly will allow the packet to traverse the network and reach 82 its intended destination. 84 Fragmentation and reassembly in network equipment generally 85 requires significantly more resources than sending a packet as a 86 single unit. As such, fragmentation and reassembly should be 87 avoided whenever possible. Ideal solutions for avoiding 88 fragmentation include proper configuration and management of MTU 89 sizes between the CE, PE and across the PSN, as well as adaptive 90 measures which operate with the originating host [e.g. [PATHMTU], 91 [PATHMTUv6]] to reduce the packet sizes at the source. 93 The purpose of this document is to define a generalized method of 94 performing fragmentation for use with all PWE3 protocols and 95 services. This method should be utilized only in cases where MTU- 96 management methods fail. Due to the increased processing overhead, 97 fragmentation and reassembly in core network devices should always 98 be considered something to avoid whenever possible. 100 The PWE3 fragmentation and reassembly domain is shown in Figure 2: 102 Fragmentation/Reassembly Domain 103 | | 104 ||<------ Pseudo Wire ----->|| 105 || |<-- PSN Tunnel -->| || 106 PW VV V V VV PW 107 End Service +----+ +----+ End Service 108 +-----+ | | PE1|==================| PE2| | +-----+ 109 | |----------|............PW1.............|----------| | 110 | CE1 | | | | | | | | CE2 | 111 | |----------|............PW2.............|----------| | 112 +-----+ | | |==================| | | +-----+ 113 Customer +----+ +----+ | Customer 114 Edge 1 | Provider Edge 1 Provider Edge 2 | Edge 2 115 |<-------------- Emulated Service ---------------->| 117 Figure 2: PWE3 Fragmentation/Reassembly Domain 119 Fragmentation takes place in the PE prior to PW insertion, and 120 reassembly takes place in the PE after PW extraction. 122 2. Fragmentation/Reassembly Specification 124 The fragmentation of large packets into smaller units for 125 transmission is not new. One fragmentation and reassembly method 126 was defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was 127 also adopted for both Frame Relay [FRF.12] and ATM [FAST] network 128 technology. This document adopts the RFC 1990 fragmentation and 129 reassembly procedures as well, with some distinct modifications 130 described in this section. Familiarity with RFC 1990 is assumed 131 for the remainder of this document. 133 RFC 1990 was designed for use in environments where packet 134 fragments may arrive out of order due to their transmission on 135 multiple parallel links, specifying that buffering be used to place 136 the fragments in correct order. For PWE3, the ability to reorder 137 fragments prior to reassembly is OPTIONAL; receivers MAY choose to 138 drop frames when a lost fragment is detected. Thus, when the 139 sequence number on received fragments shows that a fragment has 140 been skipped, the partially reassembled packet MAY be dropped, or 141 the receiver MAY wish to wait for the fragment to arrive out of 142 order. In the latter case, a reassembly timer MUST be used to 143 avoid locking up buffer resources for too long a period. 145 Dropping out-of-order fragments on a given PW can provide a 146 considerable scalability advantage for network equipment performing 147 reassembly. If out-of-order fragments are a relatively rare event 148 on a given PW, throughput should not be adversely affected by this. 149 Note, however, if there are cases where fragments of a given frame 150 are received out-or-order in a consistent manner (e.g. a short 151 fragment is always switched ahead of a larger fragment) then 152 dropping out-of-order fragments will cause the fragmented frame to 153 never be received. This condition may result in an effective denial 154 of service to a higher-lever application. As such, implementations 155 fragmenting a PW frame MUST at the very least ensure that all 156 fragments are sent in order from their own egress point. 158 An implementation may also choose to allow reassembly of a limited 159 number of fragmented frames on a given PW, or across a set of PWs 160 with reassembly enabled. This allows for a more even distribution 161 of reassembly resources, reducing the chance of a single or small 162 set of PWs exhausting all reassembly resources for a node. As with 163 dropping out-of-order fragments, there are perceivable cases where 164 this may also provide an effective denial of service. For example, 165 if fragments of multiple frames are consistently received before 166 each frame can be reconstructed in a set of limited PW reassembly 167 buffers, then a set of these fragmented frames will never be 168 delivered. 170 RFC 1990 headers use two bits which indicate the first and last 171 fragments in a frame, and a sequence number. The sequence number 172 may be either 12 or 24 bits in length (from [MLPPP]): 174 0 7 8 15 175 +-+-+-+-+-------+---------------+ 176 |B|E|0|0| sequence number | 177 +-+-+-+-+-------+---------------+ 179 +-+-+-+-+-+-+-+-+---------------+ 180 |B|E|0|0|0|0|0|0|sequence number| 181 +-+-+-+-+-+-+-+-+---------------+ 182 | sequence number (L) | 183 +---------------+---------------+ 185 Figure 3: RFC 1990 Header Formats 187 PWE3 fragmentation takes advantage of existing PW sequence numbers 188 and control bit fields wherever possible, rather than defining a 189 separate header exclusively for the use of fragmentation. Thus, it 190 uses neither of the RFC 1990 sequence number formats described 191 above, relying instead on the sequence number that already exists 192 in the PWE3 header. 194 RFC 1990 defines a two one-bit fields, a (B)eginning fragment bit 195 and an (E)nding fragment bit. The B bit is set to 1 on the first 196 fragment derived from a PPP packet and set to 0 for all other 197 fragments from the same PPP packet. The E bit is set to 1 on the 198 last fragment and set to 0 for all other fragments. A complete 199 unfragmented frame has both the B and E bits set to 1. 201 PWE3 fragmentation inverts the value of the B and E bits, while 202 retaining the operational concept of marking the beginning and 203 ending of a fragmented frame. Thus, for PW the B bit is set to 0 on 204 the first fragment derived from a PW frame and set to 1 for all 205 other fragments derived from the same frame. The E bit is set to 0 206 on the last fragment and set to 1 for all other fragments. A 207 complete unfragmented frame has both the B and E bits set to 0. The 208 motivation behind this value inversion for the B and E bits is to 209 allow complete frames (and particularly, implementations that only 210 support complete frames) to simply leave the B and E bits in the 211 header set 0. 213 In order to support fragmentation, the B and E bits MUST be defined 214 or identified for all PWE3 tunneling protocols. Sections 4 and 5 215 define these locations for PWE3 MPLS [MPLS-TRANS], L2TPv2 [L2TPv2], 216 and L2TPv3 [L2TPv3] tunneling protocols. 218 3. PWE3 Fragmentation With MPLS 220 When using the signaling procedures in [MPLS-TRANS], there is a 221 Virtual Circuit FEC element parameter ID used to signal the use of 222 fragmentation when advertising a VC label: 224 Parameter ID Length Description 225 0x06 2 Fragmentation indicator 227 The presence of this parameter ID in the VC FEC element indicates 228 that the receiver is able to reassemble fragments when the control 229 word is in use for the VC label being advertised. It does not 230 obligate the sender to use fragmentation; it is simply an 231 indication that the sender MAY use fragmentation. The sender MUST 232 NOT use fragmentation if this parameter ID is not present in the VC 233 FEC element. 235 If [MPLS-TRANS] signaling is not in use, then whether or not to use 236 fragmentation MUST be provisioned in the sender. 238 3.1 Fragment Bit Locations For MPLS 240 MPLS-based PWE3 [MPLS-ATM], [MPLS-Ethernet], [MPLS-FR] uses the 241 following control word format, with the B and E fragmentation bits 242 identified in position 8 and 9: 244 0 1 2 3 245 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 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Rsvd | Flags |B|E| Length | Sequence Number | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 Figure 4: MPLS PWE3 Control Word 252 The Sequence Number is used as already specified in the above 253 protocol specifications. Specifically, since the value 0 indicates 254 that the sequence number is not in use, its use for fragmentation 255 must follow this same rule � as the sequence number is incremented, 256 it skips zero and wraps from 65535 to 1. Since a sequence number 257 is necessary for the RFC 1990 procedures, using the Sequence Number 258 field on fragmented packets is REQUIRED. 260 3.2 Other Considerations 262 Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine 263 the maximum size for fragments. The application of path MTU to MPLS 264 is discussed in [LABELSTACK]. The maximum size of the fragments may 265 also be provisioned. The signaled Interface MTU parameter in [MPLS- 266 TRANS] SHOULD be used to set the maximum size of the reassembly 267 buffer for received packets to make optimal use of reassembly 268 buffer resources. 270 4. PWE3 Fragmentation With L2TP 272 This section defines the location of the B and E bits for L2TPv3 273 [L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling 274 mechanism for advertising MRU (Maximum Receive Unit) values and 275 support for fragmentation on a given PW. As IP is the most common 276 PSN used with L2TP, IP fragmentation and reassembly is discussed as 277 well. 279 4.1 PW-specific Fragmentation vs. IP fragmentation 281 L2TPv3 recognizes that when it is used over IP networks, it may be 282 subject to IP fragmentation. The following is quoted from 283 [L2TPv3]: 285 IP fragmentation may occur as the L2TP packet travels over the 286 IP substrate. L2TP makes no special efforts defined in this 287 document to optimize this. 289 When proper MTU management across a network fails, IP fragmentation 290 and reassembly may be used to accommodate MTU mismatches between 291 tunnel endpoints. If the overall traffic requiring fragmentation 292 and reassembly is very light, or there are sufficient optimized 293 mechanisms for IP fragmentation and reassembly available, IP 294 fragmentation and reassembly may be sufficient and is allowed, 295 particularly if PW-specific fragmentation is unavailable. 297 When facing a large number of PW packets requiring fragmentation 298 and reassembly, a PW-specific method has properties that allow for 299 more resource-friendly implementations. Specifically, the ability 300 to assign buffer usage on a per-PW basis and per-PW sequencing may 301 be utilized to significant advantage over a general mechanism 302 applying to all IP packets equally. Further, PW fragmentation may 303 be easily enabled in a selective manner for some or all PWs, rather 304 than enabling reassembly for all IP traffic arriving at a given 305 node. 307 Deployments MUST avoid a situation which relies upon a combination 308 of IP and PW fragmentation and reassembly on the same node. Such 309 operation clearly defeats the purpose behind the mechanism defined 310 in this document. Care MUST be taken to ensure that the MTU/MRU 311 values are set and advertised properly at each tunnel endpoint to 312 avoid this. When fragmentation is enabled within a given PW, the DF 313 bit SHOULD be set on all L2TP over IP packets for that PW. IP-based 314 implementations SHOULD participate in Path MTU [PATHMTU], 315 [PATHMTUv6] for automatic adjustment of the PW MTU. 317 4.2 Advertising Reassembly Support in L2TP 319 The constructs defined in this section for advertising 320 fragmentation support in L2TP are applicable to L2TPv3 and L2TPv2. 322 This document defines 2 AVPs to advertise maximum receive unit 323 values and reassembly support. These AVPs MAY be present in the 324 ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, or SLI messages. The most 325 recent value received always takes precedence over a previous 326 value, and MUST be dynamic over the life of the session if received 327 via the SLI message. Reassembly support may be unidirectional. 329 4.3 L2TP Maximum Receive Unit (MRU) AVP 331 0 1 332 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | MRU | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 MRU (Maximum Receive Unit), attribute number TBD, is the maximum 338 size in octets of a fragmented or complete PW frame, including L2TP 339 encapsulation, receivable by the side of the PW advertising this 340 value. The advertised MRU does NOT include the PSN header (i.e. the 341 IP and/or UDP header). This AVP does NOT imply that fragmentation 342 or reassembly is supported. If reassembly is not enabled or 343 unavailable, this AVP may be used alone to advertise the MRU for a 344 complete frame. 346 All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, 347 and Vendor ID. This AVP may be hidden (the H bit may be 0 or 1). 348 The M bit for this AVP SHOULD be set to 0. The Length (before 349 hiding) is 8. The Vendor ID is the IETF Vendor ID of 0. 351 4.4 L2TP Maximum Reassembled Receive Unit (MRRU) AVP 353 0 1 354 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | MRRU | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 MRRU (Maximum Reassembled Receive Unit AVP), attribute number TBD, 360 is the maximum size in octets of a reassembled frame, including any 361 PW framing, but not including the L2TP encapsulation or L2-specific 362 sublayer. Presence of this AVP signifies the ability to receive PW 363 fragments and reassemble them. Packet fragments MUST NOT be sent to 364 an implementation which has not received this value from its peer 365 in a control message. If the MRRU is present in a message, the MRU 366 AVP MUST be present as well. 368 All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, 369 and Vendor ID. This AVP may be hidden (the H bit may be 0 or 1). 370 The M bit for this AVP SHOULD be set to 0. The Length (before 371 hiding) is 8. The Vendor ID is the IETF Vendor ID of 0. 373 4.5 Fragment Bit Locations For L2TPv3 Encapsulation 375 The B and E bits are defined as bits 2 and 3 in the L2TPv3 default 376 L2-specific sublayer as depicted below: 378 0 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 |P|S|B|E|x|x|x|x| Sequence Number | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 5: L2TPv3 over IP Header 386 Location of the B and E bits for PW-Types which use a variant L2- 387 specific sublayer are outside the scope of this document. 389 Inclusion of the MRRU AVP in a control message suggests the need 390 for a control sublayer which includes sequence numbers and the B 391 and E bit fields. Thus, if reassembly support has been advertised, 392 and packet fragments are to be sent, then presence of this sublayer 393 and associated sequencing for all packet fragments MUST be enabled 394 as defined for the given PW-type. 396 4.6 Fragment Bit Locations for L2TPv2 Encapsulation 398 The B and E bits are defined as bits 8 and 9 for the L2TPv2 header 399 as depicted below (subject to IANA action): 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 6: L2TPv2 over UDP Header 415 5. 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 and its derivatives have been 425 widely implemented and extensively used in the Internet and 426 elsewhere. 428 [IPFRAG-SEC] and [TINYFRAG] describe potential network attacks 429 associated with IP fragmentation and reassembly. The issues 430 described in these documents attempt to bypass IP access controls 431 by sending various carefully formed "tiny fragments," or by 432 exploiting the IP offset field to cause fragments to overlap and 433 rewrite interesting portions of an IP packet after access checks 434 have been performed. The latter is not an issue with the PW- 435 specific fragmentation method described in this document as there 436 is no offset field; However, implementations MUST be sure to not 437 allow more than one whole fragment to overwrite another in a 438 reconstructed frame. The former may be a concern if packet 439 filtering and access controls are being placed on tunneled frames 440 within the PW encapsulation. To circumvent any possible attacks in 441 either case, all filtering and access controls should be applied to 442 the resulting reconstructed frame rather than any PW fragments. 444 6. IANA Considerations 446 This document does not define any new values for IANA to maintain. 448 This document defines 2 previously reserved bits in the L2TPv2 449 [L2TPv2] header and is subject to IANA assignment. 451 This document requires IANA to assign 2 new L2TP "Control Message 452 Attribute Value Pairs." 454 7. Acknowledgements 456 Thanks to Eric Rosen for his review of this document. 458 8. References 460 [FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport 461 (FAST)", af-fbatm-0151.000, July 2000 463 [Framework] Pate, P. et al, "Framework for Pseudo Wire Emulation 464 Edge-to-Edge (PWE3)", draft-ietf-pwe3-framework-01.txt, June 465 2002, work in progress 467 [FRF.12] Frame Relay Forum, "Frame Relay Fragmentation 468 Implementation Agreement", FRF.12, December 1997 470 [LABELSTACK] Rosen, E. et al, "MPLS Label Stack Encoding", RFC 471 3032, January 2001 473 [L2TPv2] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer Two 474 Tunneling Protocol 'L2TP'", RFC 2661, June 1999 476 [L2TPv3] Lau, J. et al, "Layer Two Tunneling Protocol (Version 3) 477 'L2TPv3'", draft-ietf-l2tpext-l2tp-base-03.txt, June 2002, work 478 in progress 480 [MLPPP] Sklower, K. et al, "The PPP Multilink Protocol (MP)", RFC 481 1990, August 1996 483 [MPLS-ATM] Martini, L. et al, "Encapsulation Methods for Transport 484 of ATM Cells/Frame Over IP and MPLS Networks", draft-martini- 485 atm-encap-mpls-00.txt, April 2002, work in progress 487 [MPLS-Ethernet] Martini, L. et al, "Encapsulation Methods for 488 Transport of Ethernet Frames Over IP and MPLS Networks", draft- 489 martini-ethernet-encap-mpls-00.txt, April 2002, work in 490 progress 492 [MPLS-FR] Martini, L. et al, "Encapsulation Methods for Transport 493 of Frame-Relay Over IP and MPLS Networks", draft-martini-frame- 494 encap-mpls-00.txt, April 2002, work in progress 496 [MPLS-TRANS] Martini, L. et al, "Transport of Layer 2 Frames Over 497 MPLS", draft-martini-l2circuit-trans-mpls-09.txt, April 2002, 498 work 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 [IPFRAG-SEC] Ziemba, G., Reed, D., Traina, P., "Security 507 Considerations for IP Fragment Filtering", RFC 1858, October 508 1995 510 [TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny 511 Fragment Attack", RFC 3128, June 2001 513 9. Authors' Addresses 515 Andrew G. Malis 516 Vivace Networks, Inc. 517 2730 Orchard Parkway 518 San Jose, CA 95134 519 Email: Andy.Malis@vivacenetworks.com 521 W. Mark Townsley 522 Cisco Systems 523 7025 Kit Creek Road 524 PO Box 14987 525 Research Triangle Park, NC 27709 526 Email: mark@townsley.net