4623
PROPOSED STANDARD
Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly
Authors: A. Malis, M. Townsley
Date: August 2006
Area: int
Working Group: pwe3
Stream: IETF
Abstract
This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services. [STANDARDS-TRACK]
RFC 4623
PROPOSED STANDARD
Errata Exist
Network Working Group A. Malis
Request for Comments: 4623 Tellabs
Category: Standards Track M. Townsley
Cisco Systems
August 2006
<span class="h1">Pseudowire Emulation Edge-to-Edge (PWE3)</span>
<span class="h1">Fragmentation and Reassembly</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document defines a generalized method of performing
fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3)
protocols and services.
<span class="grey">Malis & Townsley Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
<a href="#section-2">2</a>. Conventions Used in This Document ...............................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Alternatives to PWE3 Fragmentation/Reassembly ...................<a href="#page-5">5</a>
<a href="#section-4">4</a>. PWE3 Fragmentation with MPLS ....................................<a href="#page-5">5</a>
<a href="#section-4.1">4.1</a>. Fragment Bit Locations for MPLS ............................<a href="#page-6">6</a>
<a href="#section-4.2">4.2</a>. Other Considerations .......................................<a href="#page-6">6</a>
<a href="#section-5">5</a>. PWE3 Fragmentation with L2TP ....................................<a href="#page-6">6</a>
<a href="#section-5.1">5.1</a>. PW-Specific Fragmentation vs. IP fragmentation .............<a href="#page-7">7</a>
<a href="#section-5.2">5.2</a>. Advertising Reassembly Support in L2TP .....................<a href="#page-7">7</a>
<a href="#section-5.3">5.3</a>. L2TP Maximum Receive Unit (MRU) AVP ........................<a href="#page-8">8</a>
<a href="#section-5.4">5.4</a>. L2TP Maximum Reassembled Receive Unit (MRRU) AVP ...........<a href="#page-8">8</a>
<a href="#section-5.5">5.5</a>. Fragment Bit Locations for L2TPv3 Encapsulation ............<a href="#page-9">9</a>
<a href="#section-5.6">5.6</a>. Fragment Bit Locations for L2TPv2 Encapsulation ............<a href="#page-9">9</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-10">10</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-10">10</a>
<a href="#section-7.1">7.1</a>. Control Message Attribute Value Pairs (AVPs) ..............<a href="#page-11">11</a>
<a href="#section-7.2">7.2</a>. Default L2-Specific Sublayer Bits .........................<a href="#page-11">11</a>
<a href="#section-7.3">7.3</a>. Leading Bits of the L2TPv2 Message Header .................<a href="#page-11">11</a>
<a href="#section-8">8</a>. Acknowledgements ...............................................<a href="#page-11">11</a>
<a href="#section-9">9</a>. Normative References ...........................................<a href="#page-12">12</a>
<a href="#section-10">10</a>. Informative References ........................................<a href="#page-12">12</a>
<a href="#appendix-A">Appendix A</a>. Relationship Between This Document and <a href="./rfc1990">RFC 1990</a> .......<a href="#page-14">14</a>
<span class="grey">Malis & Townsley Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Pseudowire Emulation Edge-to-Edge Architecture Document
[<a href="#ref-Architecture" title=""Pseudo Wire Emulation Edge- to-Edge (PWE3) Architecture"">Architecture</a>] defines a network reference model for PWE3:
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
Figure 1: PWE3 Network Reference Model
A Pseudowire (PW) payload is normally relayed across the PW as a
single IP or MPLS Packet Switched Network (PSN) Protocol Data Unit
(PDU). However, there are cases where the combined size of the
payload and its associated PWE3 and PSN headers may exceed the PSN
path Maximum Transmission Unit (MTU). When a packet exceeds the MTU
of a given network, fragmentation and reassembly will allow the
packet to traverse the network and reach its intended destination.
The purpose of this document is to define a generalized method of
performing fragmentation for use with all PWE3 protocols and
services. This method should be utilized only in cases where MTU-
management methods fail. Due to the increased processing overhead,
fragmentation and reassembly in core network devices should always be
considered something to avoid whenever possible.
The PWE3 fragmentation and reassembly domain is shown in Figure 2:
<span class="grey">Malis & Townsley Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
|<-------------- Emulated Service ---------------->|
| |<---Fragmentation Domain--->| |
| ||<------- Pseudowire ----->|| |
| || || |
| || |<-- PSN Tunnel -->| || |
| PW End VV V V VV PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
Figure 2: PWE3 Fragmentation/Reassembly Domain
Fragmentation takes place in the transmitting PE immediately prior to
PW encapsulation, and reassembly takes place in the receiving PE
immediately after PW decapsulation.
Since a sequence number is necessary for the fragmentation and
reassembly procedures, using the Sequence Number field on fragmented
packets is REQUIRED (see Sections <a href="#section-4.1">4.1</a> and <a href="#section-5.5">5.5</a> for the location of the
Sequence Number fields for MPLS and L2TPv3 encapsulations,
respectively). The order of operation is that first fragmentation is
performed, and then the resulting fragments are assigned sequential
sequence numbers.
Depending on the specific PWE3 encapsulation in use, the value 0 may
not be a part of the sequence number space, in which case its use for
fragmentation must follow this same rule: as the sequence number is
incremented, it skips zero and wraps from 65535 to 1. Conversely, if
the value 0 is part of the sequence space, then the same sequence
space is also used for fragmentation and reassembly.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <a href="./rfc2119">RFC 2119</a> [<a href="#ref-KEYWORDS" title=""Key words for use in RFCs to Indicate Requirement Levels"">KEYWORDS</a>].
<span class="grey">Malis & Townsley Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Alternatives to PWE3 Fragmentation/Reassembly</span>
Fragmentation and reassembly in network equipment generally requires
significantly greater resources than sending a packet as a single
unit. As such, fragmentation and reassembly should be avoided
whenever possible. Ideal solutions for avoiding fragmentation
include proper configuration and management of MTU sizes between the
Customer Edge (CE) router and Provider Edge (PE) router and across
the PSN, as well as adaptive measures that operate with the
originating host (e.g., [<a href="#ref-PATHMTU" title=""Path MTU discovery"">PATHMTU</a>], [<a href="#ref-PATHMTUv6" title=""Path MTU Discovery for IP version 6"">PATHMTUv6</a>]) to reduce the packet
sizes at the source.
In some cases, a PE may be able to fragment an IP version 4 (IPv4)
[<a href="./rfc791" title=""Internet Protocol"">RFC791</a>] packet before it enters a PW. For example, if the PE can
fragment and forward IPv4 packets with the DF bit clear in a manner
that is identical to an IPv4 router, it may fragment packets arriving
from a CE, forwarding the IPv4 fragments with associated framing for
that attachment circuit (AC) over the PW. Architecturally, the IPv4
fragmentation happens before reaching the PW, presenting multiple
frames to the PW to forward in the normal manner for that PWType.
Thus, this method is entirely transparent to the PW encapsulation and
to the remote end of the PW itself. Packet fragments are ultimately
reassembled on the destination IPv4 host in the normal way. IPv6
packets are not to be fragmented in this manner.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. PWE3 Fragmentation with MPLS</span>
When using the signaling procedures in [<a href="#ref-MPLS-Control" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">MPLS-Control</a>], there is a
Pseudowire Interface Parameter Sub-TLV type used to signal the use of
fragmentation when advertising a VC label [<a href="#ref-IANA" title=""IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"">IANA</a>]:
Parameter Length Description
0x09 4 Fragmentation indicator
The presence of this parameter in the VC FEC element indicates that
the receiver is able to reassemble fragments when the control word is
in use for the VC label being advertised. It does not obligate the
sender to use fragmentation; it is simply an indication that the
sender MAY use fragmentation. The sender MUST NOT use fragmentation
if this parameter is not present in the VC FEC element.
If [<a href="#ref-MPLS-Control" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">MPLS-Control</a>] signaling is not in use, then whether or not to use
fragmentation MUST be configured in the sender.
<span class="grey">Malis & Townsley Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Fragment Bit Locations for MPLS</span>
MPLS-based PWE3 uses the following control word format
[<a href="#ref-Control-Word" title=""Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN"">Control-Word</a>], with the B and E fragmentation bits identified in
position 8 and 9:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |B|E| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Preferred PW MPLS Control Word
The B and E bits are defined as follows:
BE
--
00 indicates that the entire (un-fragmented) payload is carried
in a single packet
01 indicates the packet carrying the first fragment
10 indicates the packet carrying the last fragment
11 indicates a packet carrying an intermediate fragment
See <a href="#appendix-A">Appendix A</a> for a discussion of the derivation of these values for
the B and E bits.
See <a href="#section-1">Section 1</a> for the description of the use of the Sequence Number
field.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Other Considerations</span>
Path MTU [<a href="#ref-PATHMTU" title=""Path MTU discovery"">PATHMTU</a>] [<a href="#ref-PATHMTUv6" title=""Path MTU Discovery for IP version 6"">PATHMTUv6</a>] may be used to dynamically determine
the maximum size for fragments. The application of path MTU to MPLS
is discussed in [<a href="#ref-LABELSTACK" title=""MPLS Label Stack Encoding"">LABELSTACK</a>]. The maximum size of the fragments may
also be configured. The signaled Interface MTU parameter in
[<a href="#ref-MPLS-Control" title=""Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)"">MPLS-Control</a>] SHOULD be used to set the maximum size of the
reassembly buffer for received packets to make optimal use of
reassembly buffer resources.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. PWE3 Fragmentation with L2TP</span>
This section defines the location of the B and E bits for L2TPv3
[<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>] and L2TPv2 [<a href="#ref-L2TPv2" title=""Layer Two Tunneling Protocol "">L2TPv2</a>] headers, as well as the signaling
mechanism for advertising MRU (Maximum Receive Unit) values and
support for fragmentation on a given PW. As IP is the most common
PSN used with L2TP, IP PSN fragmentation and reassembly is discussed
as well.
<span class="grey">Malis & Townsley Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. PW-Specific Fragmentation vs. IP fragmentation</span>
When proper MTU management across a network fails, IP PSN
fragmentation and reassembly may be used to accommodate MTU
mismatches between tunnel endpoints. If the overall traffic
requiring fragmentation and reassembly is very light, or there are
sufficient optimized mechanisms for IP PSN fragmentation and
reassembly available, IP PSN fragmentation and reassembly may be
sufficient.
When facing a large number of PW packets requiring fragmentation and
reassembly, a PW-specific method has properties that potentially
allow for more resource-friendly implementations. Specifically, the
ability to assign buffer usage on a per-PW basis and PW sequencing
may be utilized to gain advantage over a general mechanism applying
to all IP packets across all PWs. Further, PW fragmentation may be
more easily enabled in a selective manner for some or all PWs, rather
than enabling reassembly for all IP traffic arriving at a given node.
Deployments SHOULD avoid a situation that uses a combination of IP
PSN and PW fragmentation and reassembly on the same node. Such
operation clearly defeats the purpose behind the mechanism defined in
this document. This is especially important for L2TPv3 pseudowires,
since potentially fragmentation can take place in three different
places (the IP PSN, the PW, and the encapsulated payload). Care must
be taken to ensure that the MTU/MRU values are set and advertised
properly at each tunnel endpoint to avoid this. When fragmentation
is enabled within a given PW, the DF bit MUST be set on all L2TP over
IP packets for that PW.
L2TPv3 nodes SHOULD participate in Path MTU ([<a href="#ref-PATHMTU" title=""Path MTU discovery"">PATHMTU</a>], [<a href="#ref-PATHMTUv6" title=""Path MTU Discovery for IP version 6"">PATHMTUv6</a>])
for automatic adjustment of the PSN MTU. When the payload is IP,
Path MTU should be used at they payload level as well.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Advertising Reassembly Support in L2TP</span>
The constructs defined in this section for advertising fragmentation
support in L2TP are applicable to [<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>] and [<a href="#ref-L2TPv2" title=""Layer Two Tunneling Protocol "">L2TPv2</a>].
This document defines two new AVPs to advertise maximum receive unit
values and reassembly support. These AVPs MAY be present in the
Incoming-Call-Request (ICRQ), Incoming-Call-Reply (ICRP), Incoming-
Call-Connected (ICCN), Outgoing-Call-Request (OCRQ), Outgoing-Call-
Reply (OCRP), Outgoing-Call-Connected (OCCN), or Set-Link-Info (SLI)
messages. The most recent value received always takes precedence
over a previous value and MUST be dynamic over the life of the
<span class="grey">Malis & Townsley Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
session if received via the SLI message. One of the two new AVPs
(MRRU) is used to advertise that PWE3 reassembly is supported by the
sender of the AVP. Reassembly support MAY be unidirectional.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. L2TP Maximum Receive Unit (MRU) AVP</span>
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: L2TP Maximum Receive Unit (MRU) AVP
MRU (Maximum Receive Unit), attribute number 94, is the maximum size,
in octets, of a fragmented or complete PW frame, including L2TP
encapsulation, receivable by the side of the PW advertising this
value. The advertised MRU does NOT include the PSN header (i.e., the
IP and/or UDP header). This AVP does not imply that PWE3
fragmentation or reassembly is supported. If reassembly is not
enabled or unavailable, this AVP may be used alone to advertise the
MRU for a complete frame.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M)
bit for this AVP SHOULD be set to 0. The Length (before hiding) is
8. The Vendor ID is the IETF Vendor ID of 0.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. L2TP Maximum Reassembled Receive Unit (MRRU) AVP</span>
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: L2TP Maximum Reassembled Receive Unit (MRRU) AVP
MRRU (Maximum Reassembled Receive Unit AVP), attribute number 95, is
the maximum size, in octets, of a reassembled frame, including any PW
framing, but not including the L2TP encapsulation or L2-specific
sublayer. Presence of this AVP signifies the ability to receive PW
fragments and reassemble them. Packet fragments MUST NOT be sent by
a peer that has not received this AVP in a control message. If the
MRRU is present in a message, the MRU AVP MUST be present as well.
<span class="grey">Malis & Townsley Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
The MRRU SHOULD be used to set the maximum size of the reassembly
buffer for received packets to make optimal use of reassembly buffer
resources.
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M)
bit for this AVP SHOULD be set to 0. The Length (before hiding) is
8. The Vendor ID is the IETF Vendor ID of 0.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. Fragment Bit Locations for L2TPv3 Encapsulation</span>
The usage of the B and E bits is described in <a href="#section-4.1">Section 4.1</a>. For
L2TPv3 encapsulation, the B and E bits are defined as bits 2 and 3 in
the leading bits of the Default L2-Specific Sublayer (see <a href="#section-7">Section 7</a>).
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|B|E|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: B and E Bits Location in the Default L2-Specific Sublayer
The S (Sequence) bit is as defined in [<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>]. Location of the B
and E bits for PW-Types that use a variant L2 specific sublayer are
outside the scope of this document.
When fragmentation is used, an L2-Specific Sublayer with B and E bits
defined MUST be present in all data packets for a given session. The
presence and format of the L2-Specific Sublayer is advertised via the
L2-Specific Sublayer AVP, Attribute Type 69, defined in Section 5.4.4
of [<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>].
See <a href="#section-1">Section 1</a> for the description of the use of the Sequence Number
field.
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. Fragment Bit Locations for L2TPv2 Encapsulation</span>
The usage of the B and E bits is described in <a href="#section-4.1">Section 4.1</a>. For
L2TPv2 encapsulation, the B and E bits are defined as bits 8 and 9 in
the leading bits of the L2TPv2 header as depicted below (see <a href="#section-7">Section</a>
<a href="#section-7">7</a>).
<span class="grey">Malis & Townsley Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: B and E bits location in the L2TPv2 Message Header
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
As with any additional protocol construct, each level of complexity
adds the potential to exploit protocol and implementation errors.
Implementers should be especially careful of not tying up an
abundance of resources, even for the most pathological combination of
packet fragments that could be received. Beyond these issues of
general implementation quality, there are no known notable security
issues with using the mechanism defined in this document. It should
be pointed out that <a href="./rfc1990">RFC 1990</a>, on which this document is based, and
its derivatives have been widely implemented and extensively used in
the Internet and elsewhere.
[<a id="ref-IPFRAG-SEC">IPFRAG-SEC</a>] and [<a href="#ref-TINYFRAG" title=""Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)"">TINYFRAG</a>] describe potential network attacks
associated with IP fragmentation and reassembly. The issues
described in these documents attempt to bypass IP access controls by
sending various carefully formed "tiny fragments", or by exploiting
the IP offset field to cause fragments to overlap and rewrite
interesting portions of an IP packet after access checks have been
performed. The latter is not an issue with the PW-specific
fragmentation method described in this document, as there is no
offset field. However, implementations MUST be sure not to allow
more than one whole fragment to overwrite another in a reconstructed
frame. The former may be a concern if packet filtering and access
controls are being placed on tunneled frames within the PW
encapsulation. To circumvent any possible attacks in either case,
all filtering and access controls should be applied to the resulting
reconstructed frame rather than any PW fragments.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
This document does not define any new registries for IANA to
maintain.
Note that [<a href="#ref-IANA" title=""IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)"">IANA</a>] has already allocated the Fragmentation Indicator
interface parameter, so no further IANA action is required.
<span class="grey">Malis & Townsley Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
This document requires IANA to assign new values for registries
already managed by IANA (see Sections <a href="#section-7.1">7.1</a> and <a href="#section-7.2">7.2</a>) and two reserved
bits in an existing header (see <a href="#section-7.3">Section 7.3</a>).
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Control Message Attribute Value Pairs (AVPs)</span>
Two additional AVP Attributes are specified in Sections <a href="#section-5.3">5.3</a> and <a href="#section-5.4">5.4</a>.
They are required to be defined by IANA as described in <a href="https://www.rfc-editor.org/bcp/bcp0068#section-2.2">Section 2.2
of [BCP0068]</a>.
Control Message Attribute Value Pairs
-------------------------------------
94 - Maximum Receive Unit (MRU) AVP
95 - Maximum Reassembled Receive Unit (MRRU) AVP
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Default L2-Specific Sublayer Bits</span>
This registry was created as part of the publication of [<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>].
This document defines two reserved bits in the Default L2-Specific
Sublayer in <a href="#section-5.5">Section 5.5</a>, which may be assigned by IETF Consensus
[<a href="./rfc2434" title="">RFC2434</a>]. They are required to be assigned by IANA.
Default L2-Specific Sublayer bits - per [<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>]
---------------------------------
Bit 2 - B (Fragmentation) bit
Bit 3 - E (Fragmentation) bit
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Leading Bits of the L2TPv2 Message Header</span>
This document requires definition of two reserved bits in the L2TPv2
[<a href="#ref-L2TPv2" title=""Layer Two Tunneling Protocol "">L2TPv2</a>] header. Locations are noted by the "B" and "E" bits in
<a href="#section-5.6">Section 5.6</a>.
Leading Bits of the L2TPv2 Message Header - per [<a href="#ref-L2TPv2" title=""Layer Two Tunneling Protocol "">L2TPv2</a>, <a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>]
-----------------------------------------
Bit 8 - B (Fragmentation) bit
Bit 9 - E (Fragmentation) bit
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
The authors wish to thank Eric Rosen and Carlos Pignataro, both of
Cisco Systems, for their review of this document.
<span class="grey">Malis & Townsley Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Normative References</span>
[<a id="ref-Control-Word">Control-Word</a>] Bryant, S., Swallow, G., Martini, L., and D.
McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3)
Control Word for Use over an MPLS PSN", <a href="./rfc4385">RFC 4385</a>,
February 2006.
[<a id="ref-IANA">IANA</a>] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", <a href="https://www.rfc-editor.org/bcp/bcp116">BCP 116</a>, <a href="./rfc4446">RFC 4446</a>, April 2006.
[<a id="ref-KEYWORDS">KEYWORDS</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-LABELSTACK">LABELSTACK</a>] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", <a href="./rfc3032">RFC 3032</a>, January 2001.
[<a id="ref-L2TPv2">L2TPv2</a>] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", <a href="./rfc2661">RFC 2661</a>, August 1999.
[<a id="ref-L2TPv3">L2TPv3</a>] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", <a href="./rfc3931">RFC 3931</a>,
March 2005.
[<a id="ref-MLPPP">MLPPP</a>] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
Coradetti, "The PPP Multilink Protocol (MP)", <a href="./rfc1990">RFC</a>
<a href="./rfc1990">1990</a>, August 1996.
[<a id="ref-MPLS-Control">MPLS-Control</a>] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", <a href="./rfc4447">RFC 4447</a>, April
2006.
[<a id="ref-PATHMTU">PATHMTU</a>] Mogul, J. and S. Deering, "Path MTU discovery", <a href="./rfc1191">RFC</a>
<a href="./rfc1191">1191</a>, November 1990.
[<a id="ref-PATHMTUv6">PATHMTUv6</a>] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", <a href="./rfc1981">RFC 1981</a>, August 1996.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Informative References</span>
[<a id="ref-Architecture">Architecture</a>] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
to-Edge (PWE3) Architecture", <a href="./rfc3985">RFC 3985</a>, March 2005.
<span class="grey">Malis & Townsley Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
[<a id="ref-BCP0068">BCP0068</a>] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA)
Considerations Update", <a href="https://www.rfc-editor.org/bcp/bcp68">BCP 68</a>, <a href="./rfc3438">RFC 3438</a>, December
2002.
[<a id="ref-FAST">FAST</a>] ATM Forum, "Frame Based ATM over SONET/SDH Transport
(FAST)", af-fbatm-0151.000, July 2000.
[<a id="ref-FRF.12">FRF.12</a>] Frame Relay Forum, "Frame Relay Fragmentation
Implementation Agreement", FRF.12, December 1997.
[<a id="ref-IPFRAG-SEC">IPFRAG-SEC</a>] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", <a href="./rfc1858">RFC 1858</a>,
October 1995.
[<a id="ref-RFC2434">RFC2434</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", <a href="https://www.rfc-editor.org/bcp/bcp26">BCP 26</a>, <a href="./rfc2434">RFC</a>
<a href="./rfc2434">2434</a>, October 1998.
[<a id="ref-RFC791">RFC791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
September 1981.
[<a id="ref-TINYFRAG">TINYFRAG</a>] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (<a href="./rfc1858">RFC 1858</a>)", <a href="./rfc3128">RFC 3128</a>, June 2001.
<span class="grey">Malis & Townsley Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Relationship between This Document and <a href="./rfc1990">RFC 1990</a></span>
The fragmentation of large packets into smaller units for
transmission is not new. One fragmentation and reassembly method was
defined in <a href="./rfc1990">RFC 1990</a>, Multi-Link PPP [<a href="#ref-MLPPP" title=""The PPP Multilink Protocol (MP)"">MLPPP</a>]. This method was also
adopted for both Frame Relay [<a href="#ref-FRF.12" title=""Frame Relay Fragmentation Implementation Agreement"">FRF.12</a>] and ATM [<a href="#ref-FAST" title=""Frame Based ATM over SONET/SDH Transport (FAST)"">FAST</a>] network
technology. This document adopts the <a href="./rfc1990">RFC 1990</a> fragmentation and
reassembly procedures as well, with some distinct modifications
described in this appendix. Familiarity with <a href="./rfc1990">RFC 1990</a> is assumed.
<a href="./rfc1990">RFC 1990</a> was designed for use in environments where packet fragments
may arrive out of order due to their transmission on multiple
parallel links, specifying that buffering be used to place the
fragments in correct order. For PWE3, the ability to reorder
fragments prior to reassembly is OPTIONAL; receivers MAY choose to
drop frames when a lost fragment is detected. Thus, when the sequence
number on received fragments shows that a fragment has been skipped,
the partially reassembled packet MAY be dropped, or the receiver MAY
wish to wait for the fragment to arrive out of order. In the latter
case, a reassembly timer MUST be used to avoid locking up buffer
resources for too long a period.
Dropping out-of-order fragments on a given PW can provide a
considerable scalability advantage for network equipment performing
reassembly. If out-of-order fragments are a relatively rare event on
a given PW, throughput should not be adversely affected by this.
Note, however, if there are cases where fragments of a given frame
are received out-or-order in a consistent manner (e.g., a short
fragment is always switched ahead of a larger fragment), then
dropping out-of-order fragments will cause the fragmented frame never
to be received. This condition may result in an effective denial of
service to a higher-lever application. As such, implementations
fragmenting a PW frame MUST at the very least ensure that all
fragments are sent in order from their own egress point.
An implementation may also choose to allow reassembly of a limited
number of fragmented frames on a given PW, or across a set of PWs
with reassembly enabled. This allows for a more even distribution of
reassembly resources, reducing the chance that a single or small set
of PWs will exhaust all reassembly resources for a node. As with
dropping out-of-order fragments, there are perceivable cases where
this may also provide an effective denial of service. For example,
if fragments of multiple frames are consistently received before each
frame can be reconstructed in a set of limited PW reassembly buffers,
then a set of these fragmented frames will never be delivered.
<span class="grey">Malis & Townsley Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
<a href="./rfc1990">RFC 1990</a> headers use two bits that indicate the first and last
fragments in a frame, and a sequence number. The sequence number may
be either 12 or 24 bits in length (from [<a href="#ref-MLPPP" title=""The PPP Multilink Protocol (MP)"">MLPPP</a>]):
0 7 8 15
+-+-+-+-+-------+---------------+
|B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
+-+-+-+-+-+-+-+-+---------------+
|B|E|0|0|0|0|0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
Figure 6: <a href="./rfc1990">RFC 1990</a> Header Formats
PWE3 fragmentation takes advantage of existing PW sequence numbers
and control bit fields wherever possible, rather than defining a
separate header exclusively for the use of fragmentation. Thus, it
uses neither of the <a href="./rfc1990">RFC 1990</a> sequence number formats described above,
relying instead on the sequence number that already exists in the
PWE3 header.
<a href="./rfc1990">RFC 1990</a> defines two one-bit fields: a (B)eginning fragment bit and
an (E)nding fragment bit. The B bit is set to 1 on the first
fragment derived from a PPP packet and set to 0 for all other
fragments from the same PPP packet. The E bit is set to 1 on the
last fragment and set to 0 for all other fragments. A complete
unfragmented frame has both the B and E bits set to 1.
PWE3 fragmentation inverts the value of the B and E bits, while
retaining the operational concept of marking the beginning and ending
of a fragmented frame. Thus, for PW the B bit is set to 0 on the
first fragment derived from a PW frame and set to 1 for all other
fragments derived from the same frame. The E bit is set to 0 on the
last fragment and set to 1 for all other fragments. A complete
unfragmented frame has both the B and E bits set to 0. The
motivation behind this value inversion for the B and E bits is to
allow complete frames (and particularly, implementations that only
support complete frames) simply to leave the B and E bits in the
header set to 0.
In order to support fragmentation, the B and E bits MUST be defined
or identified for all PWE3 tunneling protocols. Sections <a href="#section-4">4</a> and <a href="#section-5">5</a>
define these locations for PWE3 MPLS [<a href="#ref-Control-Word" title=""Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN"">Control-Word</a>], L2TPv2 [<a href="#ref-L2TPv2" title=""Layer Two Tunneling Protocol "">L2TPv2</a>],
and L2TPv3 [<a href="#ref-L2TPv3" title=""Layer Two Tunneling Protocol - Version 3 (L2TPv3)"">L2TPv3</a>] tunneling protocols.
<span class="grey">Malis & Townsley Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
Authors' Addresses
Andrew G. Malis
Tellabs
1415 West Diehl Road
Naperville, IL 60563
EMail: [email protected]
W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: [email protected]
<span class="grey">Malis & Townsley Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc4623">RFC 4623</a> PWE3 Fragmentation and Reassembly August 2006</span>
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[email protected].
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Malis & Townsley Standards Track [Page 17]
Annotations
Select text to annotate