summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3355.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3355.txt')
-rw-r--r--doc/rfc/rfc3355.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc3355.txt b/doc/rfc/rfc3355.txt
new file mode 100644
index 0000000..5b2afec
--- /dev/null
+++ b/doc/rfc/rfc3355.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group A. Singh
+Request for Comments: 3355 Motorola
+Category: Standards Track R. Turner
+ Paradyne
+ R. Tio
+ S. Nanji
+ Redback Networks
+ August 2002
+
+
+ Layer Two Tunnelling Protocol (L2TP)
+ Over ATM Adaptation Layer 5 (AAL5)
+
+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 (2002). All Rights Reserved.
+
+Abstract
+
+ The Layer Two Tunneling Protocol (L2TP) provides a standard method
+ for transporting the link layer of the Point-to-Point Protocol (PPP)
+ between a dial-up server and a Network Access Server, using a network
+ connection in lieu of a physical point-to-point connection. This
+ document describes the use of an Asynchronous Transfer Mode (ATM)
+ network for the underlying network connection. ATM User-Network
+ Interface (UNI) Signaling Specification Version 4.0 or Version 3.1
+ with ATM Adaptation Layer 5 (AAL5) are supported as interfaces to the
+ ATM network.
+
+Applicability
+
+ This specification is intended for implementations of L2TP that use
+ ATM to provide the communications link between the L2TP Access
+ Concentrator and the L2TP Network Server.
+
+
+
+
+
+
+
+
+
+Singh, et. al. Standards Track [Page 1]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+1. Introduction
+
+ The Point-to-Point Protocol (PPP) [RFC1661], is frequently used on
+ the link between a personal computer with a dial modem and a network
+ service provider, or NSP. The Layer Two Tunneling Protocol (L2TP)
+ [RFC2661] enables a dial-up server to provide access to a remote NSP
+ by extending the PPP connection through a tunnel in a network to
+ which both it and the NSP are directly connected. A "tunnel" is a
+ network layer connection between two nodes, used in the role of a
+ data link layer connection between those nodes, possibly as part of a
+ different network. In [RFC2661] the dial-up server is called an L2TP
+ Access Concentrator, or LAC. The remote device that provides access
+ to a network is called an L2TP Network Server, or LNS. L2TP uses a
+ packet delivery service to create a tunnel between the LAC and the
+ LNS. "L2TP is designed to be largely insulated from the details of
+ the media over which the tunnel is established; L2TP requires only
+ that the tunnel media provide packet oriented point-to-point
+ connectivity" [RFC2661]. An ATM network with AAL5 offers a suitable
+ form of packet oriented connection. This standard supplements
+ [RFC2661] by providing details specific to the use of AAL5 for a
+ point-to-point connection between LAC and LNS.
+
+2. Conventions
+
+ Requirements keywords 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
+ [RFC2119].
+
+ A list of acronyms used in this document is given at the end of the
+ document as Appendix A.
+
+3. AAL5 Layer Service Interface
+
+ L2TP treats the underlying ATM AAL5 layer service as a bit-
+ synchronous point-to-point link. In this context, the L2TP link
+ corresponds to an ATM AAL5 virtual circuit (VC). The VC MUST be
+ full-duplex, point to point, and it MAY be either dedicated (i.e.,
+ permanent, set up by provisioning) or switched (set up on demand.)
+
+ The AAL5 message mode service, in the non-assured mode of operation,
+ without the corrupted delivery option MUST be used.
+
+ Interface Format - The L2TP/AAL5 layer boundary presents an octet
+ service interface to the AAL5 layer. There is no provision for sub-
+ octets to be supplied or accepted.
+
+
+
+
+
+Singh, et. al. Standards Track [Page 2]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+3.1 Maximum Transfer Unit
+
+ Each L2TP PDU MUST be transported within a single AAL5 PDU.
+ Therefore the maximum transfer unit (MTU) of the AAL5 connection
+ constrains the MTU of the L2TP tunnel that uses the connection and
+ the MTU of all PPP connections that use the tunnel. ([RFC1661]
+ refers to this as Maximum Receive Unit, or MRU. In [SIG31], it is
+ the Forward and Backward Maximum CPCS-SDU Size.)
+
+ An implementation MUST support a PPP MRU of at least 1500 bytes.
+
+ An implementation SHOULD use a larger MTU than the minimum value
+ specified above. It is RECOMMENDED that an implementation support an
+ IP packet of at least 9180 bytes in the PPP PDU.
+
+3.2 Quality of Service
+
+ In order to provide a desired Quality of Service (QoS), and possibly
+ different qualities of service to different client connections, an
+ implementation MAY use more than one AAL5 connection between LAC and
+ LNS.
+
+ QoS mechanisms, such as Differentiated UBR [DUBR], that could involve
+ inverse multiplexing a tunnel across multiple VCs are for further
+ study. QoS mechanisms applicable to a single tunnel corresponding to
+ a single VC, are independent of the ATM transport and out of scope of
+ this document.
+
+3.3 ATM Connection Parameters
+
+ The L2TP layer does not impose any restrictions regarding
+ transmission rate or the underlying ATM layer traffic descriptor
+ parameters.
+
+ Specific traffic parameters MAY be set for a PVC connection by
+ agreement between the communicating parties. The caller MAY request
+ specific traffic parameters at the time an SVC connection is set up.
+
+ Autoconfiguration of end-systems for PVCs can be facilitated by the
+ use of the optional ILMI 4.0 extensions documented in [ILMIA]. This
+ provides comparable information to the IEs used for control plane
+ connection establishment.
+
+
+
+
+
+
+
+
+
+Singh, et. al. Standards Track [Page 3]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+4. Multi-Protocol Encapsulation
+
+ This specification uses the principles, terminology, and frame
+ structure described in "Multiprotocol Encapsulation over ATM
+ Adaptation Layer 5" [RFC2684]. The purpose of this specification is
+ not to reiterate what is already standardized in [RFC2684], but to
+ specify how the mechanisms described in [RFC2684] are to be used to
+ map L2TP onto an AAL5-based ATM network.
+
+ As specified in [RFC2684], L2TP PDUs shall be carried in the payload
+ field of Common Part Convergence Sublayer (CPCS) PDUs of AAL5, and
+ the Service Specific Convergence Sublayer (SSCS) of AAL5 shall be
+ empty.
+
+ Section 1 of [RFC2684] defines two mechanisms for identifying the
+ protocol encapsulated in the AAL5 PDU's payload field:
+
+ 1. Virtual circuit (VC) based multiplexing.
+ 2. Logical Link Control (LLC) encapsulation.
+
+ In the first mechanism, the payload's protocol type is implicitly
+ agreed to by the end points for each virtual circuit using
+ provisioning or control plane procedures. This mechanism will be
+ referred to as "VC-multiplexed L2TP".
+
+ In the second mechanism, the payload's protocol type is explicitly
+ identified in each AAL5 PDU by an IEEE 802.2 LLC header. This
+ mechanism will be referred to as "LLC encapsulated L2TP".
+
+ An L2TP implementation:
+
+ 1. MUST support LLC encapsulated L2TP on PVCs.
+ 2. MAY support LLC encapsulated L2TP on SVCs.
+ 3. MAY support VC-multiplexed L2TP on PVCs or SVCs.
+
+ When a PVC is used, the endpoints must be configured to use one of
+ the two encapsulation methods.
+
+ If an implementation supports SVCs, it MUST use the [Q.2931] Annex C
+ procedure to negotiate connection setup, encoding the Broadband Lower
+ Layer Interface (B-LLI) information element (IE) to signal either
+ VC-multiplexed L2TP or LLC encapsulated L2TP. The details of this
+ control plane procedure are described in section 7.
+
+ If an implementation is connecting through a Frame Relay/ATM FRF.8
+ [FRF8] service inter-working unit, then it MUST use LLC encapsulated
+ L2TP.
+
+
+
+
+Singh, et. al. Standards Track [Page 4]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+5. LLC Encapsulated L2TP over AAL5
+
+ When LLC encapsulation is used, the payload field of the AAL5 CPCS
+ PDU SHALL be encoded as shown in Figure 1. The pertinent fields in
+ that diagram are:
+
+ 1. IEEE 802.2 LLC header: Source and destination SAP of 0xAA
+ followed by a frame type of Un-numbered Information (value
+ 0x03). This LLC header indicates that an IEEE 802.1a SNAP
+ header follows [RFC2684].
+
+ 2. IEEE 802.1a SNAP Header: The three octet Organizationally
+ Unique Identifier (OUI) value of 0x00-00-5E identifies IANA
+ (Internet Assigned Numbers Authority.) The two octets Protocol
+ Identifier (PID) identifies L2TP as the encapsulated protocol.
+ The PID value is 0x0007.
+
+ 3. The L2TP PDU:
+
+ Figure 1 - LLC Encapsulated L2TP PDU
+
+ +-------------------------+ --------
+ | Destination SAP (0xAA) | ^
+ +-------------------------+ |
+ | Source SAP (0xAA) | LLC header
+ +-------------------------+ |
+ | Frame Type = UI (0x03) | V
+ +-------------------------+ --------
+ | OUI (0x00-00-5E)| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-| SNAP Header
+ | PID (0x00-07) | |
+ +-------------------------+ --------
+ | | |
+ | | L2TP PDU
+ | | |
+ +-------------------------+ --------
+
+ Note: The format of the overall AAL5 CPCS PDU is shown in the next
+ section.
+
+ The end points MAY be bi-laterally provisioned to send other LLC-
+ encapsulated protocols besides L2TP across the same virtual
+ connection.
+
+
+
+
+
+
+
+
+Singh, et. al. Standards Track [Page 5]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+6. Virtual Circuit Multiplexed L2TP over AAL5
+
+ VC-multiplexed L2TP over AAL5 is an alternative technique to LLC
+ encapsulated L2TP over AAL5. In this case, the L2TP PDU is the AAL5
+ payload without an LLC header. This is sometimes called "Null
+ encapsulation."
+
+ Figure 2 - AAL5 CPCS-PDU Format
+
+ +-------------------------------+ -------
+ | . | ^
+ | . | |
+ | CPCS-PDU payload | L2TP PDU
+ | up to 2^16 - 1 octets) | |
+ | . | V
+ +-------------------------------+ -------
+ | PAD ( 0 - 47 octets) |
+ +-------------------------------+ -------
+ | CPCS-UU (1 octet ) | ^
+ +-------------------------------+ |
+ | CPI (1 octet ) | |
+ +-------------------------------+CPCS-PDU Trailer
+ | Length (2 octets) | |
+ +-------------------------------| |
+ | CRC (4 octets) | V
+ +-------------------------------+ -------
+
+ The Common Part Convergence Sub-layer (CPCS) PDU payload field
+ contains user information up to 2^16 - 1 octets.
+
+ The PAD field pads the CPCS-PDU to fit exactly into the ATM cells
+ such that the last 48 octet cell payload created by the SAR sublayer
+ will have the CPCS-PDU Trailer right justified in the cell.
+
+ The CPCS-UU (User-to-User indication) field is used to transparently
+ transfer CPCS user to user information. The field has no function
+ under the multi-protocol ATM encapsulation and MAY be set to any
+ value.
+
+ The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to
+ 64 bits. Possible additional functions are for further study in
+ ITU-T. When only the 64 bit alignment function is used, this field
+ SHALL be coded as 0x00.
+
+ The Length field indicates the length, in octets, of the payload
+ field. The maximum value for the Length field is 65535 octets. A
+ Length field coded as 0x00 MAY be used for the abort function.
+
+
+
+
+Singh, et. al. Standards Track [Page 6]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+ The CRC field is computed over the entire CPCS-PDU except the CRC
+ field itself.
+
+ The CPCS-PDU payload SHALL consist of an L2TP PDU as defined in
+ [RFC2661].
+
+7. Out-of-Band Control Plane Signaling
+
+7.1 Connection Setup
+
+ An SVC connection can originate at either the LAC or the LNS. An
+ implementation that supports the use of SVCs MUST be able to both
+ originate and respond to SVC setup requests. Except for the B-LLI IE
+ specified below, all other IEs required for ATM User-Network
+ Interface (UNI) Signaling Specification Version 4.0 [SIG40] should be
+ encoded as per [RFC2331].
+
+ When originating an SVC AAL5 connection, the caller MUST request in
+ the SETUP message either VC-multiplexed L2TP, LLC encapsulated L2TP,
+ or both VC-multiplexed and LLC-encapsulated L2TP. The B-LLI IE SHALL
+ be used to specify the requested encapsulation method. When a caller
+ is offering both encapsulations, the two B-LLI IEs SHALL be encoded
+ within a Broadband Repeat Indicator information element in the order
+ of the sender's preference.
+
+ An implementation MUST be able to accept an incoming call that offers
+ LLC encapsulated L2TP in the caller's request. The called peer's
+ implementation MUST reject a call setup request that only offers an
+ encapsulation that it does not support. Implementations originating
+ a call offering both protocol encapsulation techniques MUST be able
+ to accept the use of either encapsulation techniques.
+
+ When originating an LLC encapsulated call that is to carry an L2TP
+ payload, the [Q.2931] B-LLI IE user information layer 2 protocol
+ field SHALL be encoded to select LAN Logical Link Control
+ (ISO/IEC8802-2) in octet 6. See [RFC2331] Appendix A for an example.
+
+ When originating a VC-multiplexed call that is to carry an L2TP
+ payload, the [Q.2931] B-LLI IE user information layer 2 protocol
+ field SHALL be encoded to select no layer 2 protocol in octet 6 and
+ layer 3 protocol field SHALL be encoded to select ISO/IEC TR 9577
+ [ISO9577] in octet 7. Furthermore, as per DSL Forum TR-037
+ [DSLF037], the extension octets specify VC-multiplexed L2TP by using
+ the SNAP IPI, followed by an OUI owned by IANA, followed by the PID
+ assigned by IANA for L2TP. Thus, the User Information layer 3
+ protocol field is encoded: 0B 80 00 00 5E 00 07. The AAL5 frame's
+
+
+
+
+
+Singh, et. al. Standards Track [Page 7]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+ payload field will always contain an L2TP PDU. The SNAP IPI is
+ employed only to use the IANA L2TP protocol value to specify the VC-
+ multiplexed PDU.
+
+ If the caller offers both encapsulation methods and the called peer
+ accepts the call, the called peer SHALL specify the encapsulation
+ method by including exactly one B-LLI IE in the Connect message.
+
+ If an SVC tunnel is reset in accordance with section 4.1 of
+ [RFC2661], both ends MUST clear the SVC. Any user sessions on the
+ tunnel will be terminated by the reset. Either end MAY attempt to
+ re-establish the tunnel upon receipt of a new request from a client.
+
+7.2 Connection Setup Failure
+
+ When a connection setup fails, the L2TP entity that attempted the
+ connection setup MAY consider the called entity unreachable until
+ notified that the unreachable entity is available. The conditions
+ under which an entity determines that another is unreachable and how
+ it determines that the other is available again are implementation
+ decisions.
+
+7.3 Connection Teardown
+
+ When there are no active sessions on an SVC tunnel, either end MAY
+ optionally clear the connection.
+
+8. Connection Failure
+
+ Upon notification that an AAL5 SVC connection has been cleared, an
+ Implementation SHALL tear down the tunnel and return the control
+ connection to the idle state.
+
+9. Security Considerations
+
+ The Layer Two Tunneling Protocol base specification [RFC2661]
+ discusses basic security issues regarding L2TP tunneling. It is
+ possible that the L2TP over AAL5 tunnel security may be compromised
+ by the attack of ATM transport network itself. The ATM Forum has
+ published a security framework [AFSEC1] and a security specification
+ [AFSEC2] that define procedures to guard against common threats to an
+ ATM transport network. Applications that require protection against
+ threats to an ATM switching network are encouraged to use
+ authentication headers, or encrypted payloads, and/or the ATM-layer
+ security services described in [AFSEC2].
+
+
+
+
+
+
+Singh, et. al. Standards Track [Page 8]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+10. Acknowledgments
+
+ This document draws heavily on material from: "PPP Over AAL5" (RFC
+ 2364) by George Gross, Manu Kaycee, Arthur Lin, Andrew Malis, and
+ John Stephens and an earlier document of L2TP over AAL5 by Nagraj
+ Arunkumar, Manu Kaycee, Tim Kwok, and Arthur Lin.
+
+ Special thanks to Mike Davison, Arthur Lin, John Stevens for making
+ significant contributions to the initial version of this document.
+
+ Special thanks to David Allan of Nortel for his invaluable review of
+ this document.
+
+ The security section of this document is based upon RFC 3337, "Class
+ Extensions for PPP over Asynchronous Transfer Mode Adaptation Layer 2
+ (AAL2)", by Bruce Thompson, Bruce Buffam and Thima Koren.
+
+11. References
+
+ [RFC2661] Townsley, W., Valencia, A., Rubens, A., Singh Pall, G.,
+ Zorn, G. and B. Palter, "Layer Two Tunneling Protocol
+ (L2TP)", RFC 2661, August 1999.
+
+ [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
+ STD 51, RFC 1661, July 1994.
+
+ [SIG31] The ATM Forum, "ATM User-Network Interface Specification
+ V3.1", af-uni-0010.002, 1994.
+
+ [ITU93] International Telecommunication Union, "B-ISDN ATM
+ Adaptation Layer (AAL) Specification", ITU-T Recommendation
+ I.363, March 1993.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
+ over ATM Adaptation Layer 5", RFC 2684, September 1999.
+
+ [Q.2931] International Telecommunication Union, "Broadband
+ Integrated Service Digital Network (B-ISDN) Digital
+ Subscriber Signaling System No.2 (DSS2) User Network
+ Interface Layer 3 Specification for Basic Call/Connection
+ Control", ITU-T Recommendation Q.2931, Feb. 1995.
+
+ [FRF8] The Frame Relay Forum, "Frame Relay/ATM PVC Service
+ Interworking Implementation Agreement", FRF.8, April 1995.
+
+
+
+
+Singh, et. al. Standards Track [Page 9]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+ [ISO9577] ISO/IEC DTR 9577.2, "Information technology -
+ Telecommunications and Information exchange between systems
+ - Protocol Identification in the network layer", 1995-08-
+ 16.
+
+ [RFC2331] Maher, M., "ATM Signaling Support for IP over ATM - UNI
+ Signaling 4.0 Update", RFC 2331, April 1998.
+
+ [DSLF037] DSL Forum Technical Report TR-037, "Auto-Configuration for
+ the Connection Between the DSL Broadband Network
+ Termination (B-NT) and the Network using ATM", March 2001.
+
+ [SIG40] ATM Forum, "ATM User-Network Interface (UNI) Signaling
+ Specification Version 4.0", af-sig-0061.000, finalized July
+ 1996; available at ftp://ftp.atmforum.com/pub.
+
+ [DUBR] ATM Forum, "Addendum to TM 4.1: Differentiated UBR", af-
+ tm-0149.000, finalized July, 2000; available at
+ ftp://ftp.atmforum.com/pub
+
+ [ILMIA] ATM Forum, "Addendum to the ILMI Auto-configuration
+ extension", af-nm-00165.000, April 2001.
+
+ [AFSEC1] The ATM Forum, "ATM Security Framework Version 1.0", af-
+ sec-0096.000, February 1998
+
+ [AFSEC2] The ATM Forum, "ATM Security Specification v1.1", af-sec-
+ 0100.002, March 2001
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singh, et. al. Standards Track [Page 10]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+Appendix A. Acronyms
+
+ AAL5 ATM Adaptation Layer Type 5
+
+ ATM Asynchronous Transfer Mode
+
+ B-LLI Broadband Low Layer Information
+
+ CPCS Common Part Convergence Sublayer
+
+ IANA Internet Assigned Numbers Authority
+
+ IE Information Element
+
+ L2TP Layer Two Tunneling Protocol
+
+ LAC L2TP Access Concentrator
+
+ LLC Logical Link Control
+
+ LNS L2TP Network Server
+
+ MTU Maximum Transfer Unit
+
+ MRU Maximum Receive Unit
+
+ NSP Network Service Provider
+
+ OUI Organizationally Unique Identifier
+
+ PDU Protocol Data Unit
+
+ PID Protocol Identifier
+
+ PPP Point-to-Point Protocol
+
+ PVC Permanent Virtual Circuit
+
+ SAP Service Access Point
+
+ SNAP Subnetwork Address Protocol
+
+ SVC Switched Virtual Circuit
+
+ VC Virtual Circuit
+
+
+
+
+
+
+Singh, et. al. Standards Track [Page 11]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+Authors' Addresses
+
+ Rollins Turner
+ Paradyne Corporation
+ 8545 126th Avenue North
+ Largo, FL 33773
+
+ EMail: rturner@eng.paradyne.com
+
+
+ Rene Tio
+ Redback Networks, Inc.
+ 300 Holger Way
+ San Jose, CA 95134
+
+ EMail: tor@redback.com
+
+
+ Ajoy Singh
+ Motorola
+ 1421 West Shure Dr,
+ Arlington Heights, IL 60004
+
+ EMail: asingh1@motorola.com
+
+
+ Suhail Nanji
+ Redback Networks, Inc.
+ 300 Holger Way
+ Sunnyvale, CA 95134
+
+ EMail: suhail@redback.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singh, et. al. Standards Track [Page 12]
+
+RFC 3355 L2TP Over AAL5 August 2002
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Singh, et. al. Standards Track [Page 13]
+