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.
7. IANA Considerations
This document does not define any new registries for IANA to
maintain.
Note that [IANA] has already allocated the Fragmentation Indicator
interface parameter, so no further IANA action is required.
This document requires IANA to assign new values for registries
already managed by IANA (see Sections 7.1 and 7.2) and two reserved
bits in an existing header (see Section 7.3).
7.1. Control Message Attribute Value Pairs (AVPs)
Two additional AVP Attributes are specified in Sections 5.3 and 5.4.
They are required to be defined by IANA as described in Section 2.2
of [BCP0068].
Control Message Attribute Value Pairs
-------------------------------------
94 - Maximum Receive Unit (MRU) AVP
95 - Maximum Reassembled Receive Unit (MRRU) AVP
7.2. Default L2-Specific Sublayer Bits
This registry was created as part of the publication of [L2TPv3].
This document defines two reserved bits in the Default L2-Specific
Sublayer in Section 5.5, which may be assigned by IETF Consensus
[RFC2434]. They are required to be assigned by IANA.
Default L2-Specific Sublayer bits - per [L2TPv3]
---------------------------------
Bit 2 - B (Fragmentation) bit
Bit 3 - E (Fragmentation) bit
7.3. Leading Bits of the L2TPv2 Message Header
This document requires definition of two reserved bits in the L2TPv2
[L2TPv2] header. Locations are noted by the "B" and "E" bits in
Section 5.6.
Leading Bits of the L2TPv2 Message Header - per [L2TPv2, L2TPv3]
-----------------------------------------
Bit 8 - B (Fragmentation) bit
Bit 9 - E (Fragmentation) bit
8. Acknowledgements
The authors wish to thank Eric Rosen and Carlos Pignataro, both of
Cisco Systems, for their review of this document.
9. Normative References
[Control-Word] Bryant, S., Swallow, G., Martini, L., and D.
McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3)
Control Word for Use over an MPLS PSN", RFC 4385,
February 2006.
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to
Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[LABELSTACK] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005.
[MLPPP] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC
1990, August 1996.
[MPLS-Control] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April
2006.
[PATHMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC
1191, November 1990.
[PATHMTUv6] McCann, J., Deering, S., and J. Mogul, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
10. Informative References
[Architecture] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
Internet Assigned Numbers Authority (IANA)
Considerations Update", BCP 68, RFC 3438, December
2002.
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport
(FAST)", af-fbatm-0151.000, July 2000.
[FRF.12] Frame Relay Forum, "Frame Relay Fragmentation
Implementation Agreement", FRF.12, December 1997.
[IPFRAG-SEC] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering", RFC 1858,
October 1995.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny
Fragment Attack (RFC 1858)", RFC 3128, June 2001.
Appendix A. Relationship between This Document and RFC 1990
The fragmentation of large packets into smaller units for
transmission is not new. One fragmentation and reassembly method was
defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was also
adopted for both Frame Relay [FRF.12] and ATM [FAST] network
technology. This document adopts the RFC 1990 fragmentation and
reassembly procedures as well, with some distinct modifications
described in this appendix. Familiarity with RFC 1990 is assumed.
RFC 1990 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.
RFC 1990 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 [MLPPP]):
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: RFC 1990 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 RFC 1990 sequence number formats described above,
relying instead on the sequence number that already exists in the
PWE3 header.
RFC 1990 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 4 and 5
define these locations for PWE3 MPLS [Control-Word], L2TPv2 [L2TPv2],
and L2TPv3 [L2TPv3] tunneling protocols.
Authors’ Addresses
Andrew G. Malis
Tellabs
1415 West Diehl Road
Naperville, IL 60563
EMail: Andy.Malis@tellabs.com
W. Mark Townsley
Cisco Systems
7025 Kit Creek Road
PO Box 14987
Research Triangle Park, NC 27709
EMail: mark@townsley.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, 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 BCP 78 and BCP 79.
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
http://www.ietf.org/ipr.
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
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).