summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4349.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4349.txt')
-rw-r--r--doc/rfc/rfc4349.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc4349.txt b/doc/rfc/rfc4349.txt
new file mode 100644
index 0000000..77b11b7
--- /dev/null
+++ b/doc/rfc/rfc4349.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group C. Pignataro
+Request for Comments: 4349 M. Townsley
+Category: Standards Track Cisco Systems
+ February 2006
+
+
+ High-Level Data Link Control (HDLC) Frames
+ over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)
+
+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
+
+ The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a
+ protocol for tunneling a variety of data link protocols over IP
+ networks. This document describes the specifics of how to tunnel
+ High-Level Data Link Control (HDLC) frames over L2TPv3.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro & Townsley Standards Track [Page 1]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 1.1. Abbreviations ..............................................2
+ 1.2. Specification of Requirements ..............................3
+ 2. Control Connection Establishment ................................3
+ 3. HDLC Link Status Notification and Session Establishment .........3
+ 3.1. L2TPv3 Session Establishment ...............................3
+ 3.2. L2TPv3 Session Teardown ....................................5
+ 3.3. L2TPv3 Session Maintenance .................................5
+ 3.4. Use of Circuit Status AVP for HDLC .........................6
+ 4. Encapsulation ...................................................6
+ 4.1. Data Packet Encapsulation ..................................6
+ 4.2. Data Packet Sequencing .....................................7
+ 4.3. MTU Considerations .........................................7
+ 5. Applicability Statement .........................................8
+ 6. Security Considerations .........................................9
+ 7. IANA Considerations .............................................9
+ 7.1. Pseudowire Type ............................................9
+ 7.2. Result Code AVP Values .....................................9
+ 8. Acknowledgements ................................................9
+ 9. References .....................................................10
+ 9.1. Normative References ......................................10
+ 9.2. Informative References ....................................10
+
+1. Introduction
+
+ [RFC3931] defines a base protocol for Layer 2 Tunneling over IP
+ networks. This document defines the specifics necessary for
+ tunneling HDLC Frames over L2TPv3. Such emulated circuits are
+ referred to as HDLC Pseudowires (HDLCPWs).
+
+ Protocol specifics defined in this document for L2TPv3 HDLCPWs
+ include those necessary for simple point-to-point (e.g., between two
+ L2TPv3 nodes) frame encapsulation, and for simple interface up and
+ interface down notifications.
+
+ The reader is expected to be very familiar with the terminology and
+ protocol constructs defined in [RFC3931].
+
+1.1 Abbreviations
+
+ HDLC High-Level Data Link Control
+ HDLCPW HDLC Pseudowire
+ LAC L2TP Access Concentrator (see [RFC3931])
+ LCCE L2TP Control Connection Endpoint (see [RFC3931])
+ PW Pseudowire
+
+
+
+
+Pignataro & Townsley Standards Track [Page 2]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+1.2. Specification of Requirements
+
+ In this document, several words are used to signify the requirements
+ of the specification. These words are often capitalized. 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].
+
+2. Control Connection Establishment
+
+ In order to tunnel an HDLC link over IP using L2TPv3, an L2TPv3
+ Control Connection MUST first be established as described in
+ [RFC3931]. The L2TPv3 SCCRQ Control Message and corresponding SCCRP
+ Control Message MUST include the HDLC Pseudowire Type of 0x0006 (see
+ Section 7, "IANA Considerations"), in the Pseudowire Capabilities
+ List as defined in 5.4.3 of [RFC3931]. This identifies the control
+ connection as able to establish L2TP sessions to support HDLC
+ Pseudowires (HDLCPWs).
+
+ An LCCE MUST be able to uniquely identify itself in the SCCRQ and
+ SCCRP messages via a globally unique value. By default, this is
+ advertised via the structured Router ID AVP [RFC3931], though the
+ unstructured Hostname AVP [RFC3931] MAY be used to identify LCCEs as
+ well.
+
+3. HDLC Link Status Notification and Session Establishment
+
+ This section specifies how the status of an HDLC interface is
+ reported between two LCCEs, and the associated L2TP session creation
+ and deletion that occurs.
+
+3.1. L2TPv3 Session Establishment
+
+ Associating an HDLC serial interface with a PW and its transition to
+ "Ready" or "Up" results in the establishment of an L2TP session via
+ the standard three-way handshake described in Section 3.4.1 of
+ [RFC3931]. For purposes of this discussion, the action of locally
+ associating an interface running HDLC with a PW by local
+ configuration or otherwise is referred to as "provisioning" the HDLC
+ interface. The transition of the interface to "ready" or "up" will
+ be referred to as the interface becoming ACTIVE. The transition of
+ the interface to "not-ready" or "down" will be referred to as the
+ interface becoming INACTIVE.
+
+
+
+
+
+
+
+
+Pignataro & Townsley Standards Track [Page 3]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+ An LCCE MAY initiate the session immediately upon association with an
+ HDLC interface or wait until the interface becomes ACTIVE before
+ attempting to establish an L2TP session. Waiting until the interface
+ transitions to ACTIVE may be preferred, as it delays allocation of
+ resources until absolutely necessary.
+
+ The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931],
+ Attribute Type 68, MUST be present in the ICRQ messages and MUST
+ include the Pseudowire Type of 0x0006 for HDLCPWs.
+
+ The Circuit Status AVP (see Section 3.4) MUST be present in the ICRQ
+ and ICRP messages and MAY be present in the SLI message for HDLCPWs.
+
+ Following is an example of the L2TP messages exchanged for an HDLCPW
+ that is initiated after an HDLC interface is provisioned and becomes
+ ACTIVE.
+
+ LCCE (LAC) A LCCE (LAC) B
+ ------------------ ------------------
+ HDLC Interface Provisioned
+ HDLC Interface Provisioned
+ HDLC Interface ACTIVE
+
+ ICRQ (status = 0x03) ---->
+
+ HDLC Interface ACTIVE
+
+ <---- ICRP (status = 0x03)
+
+ L2TP session established,
+ OK to send data into tunnel
+
+ ICCN ----->
+ L2TP session established,
+ OK to send data into tunnel
+
+ In the example above, an ICRQ is sent after the interface is
+ provisioned and becomes ACTIVE. The Circuit Status AVP indicates
+ that this link is ACTIVE and New (0x03). The Remote End ID AVP
+ [RFC3931] MUST be present in the ICRQ in order to identify the HDLC
+ link (together with the identity of the LCCE itself as defined in
+ Section 2) with which to associate the L2TP session. The Remote End
+ ID AVP defined in [RFC3931] is of opaque form and variable length,
+ though one MUST at a minimum support use of an unstructured four-
+ octet value that is known to both LCCEs (either by direct
+ configuration, or some other means). The exact method of how this
+ value is configured, retrieved, discovered, or otherwise determined
+ at each LCCE is outside the scope of this document.
+
+
+
+Pignataro & Townsley Standards Track [Page 4]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+ As with the ICRQ, the ICRP is sent only after the associated HDLC
+ interface transitions to ACTIVE as well. If LCCE B had not been
+ provisioned for the interface identified in the ICRQ, a CDN would
+ have been immediately returned indicating that the associated link
+ was not provisioned or available at this LCCE. LCCE A SHOULD then
+ exhibit a periodic retry mechanism. If so, the period and maximum
+ number of retries MUST be configurable.
+
+ An Implementation MAY send an ICRQ or ICRP before an HDLC interface
+ is ACTIVE, as long as the Circuit Status AVP reflects that the link
+ is INACTIVE and an SLI is sent when the HDLC interface becomes ACTIVE
+ (see Section 3.3).
+
+ The ICCN is the final stage in the session establishment, confirming
+ the receipt of the ICRP with acceptable parameters to allow
+ bidirectional traffic.
+
+3.2. L2TPv3 Session Teardown
+
+ In the event a link is removed (unprovisioned) at either LCCE, the
+ associated L2TP session MUST be torn down via the CDN message defined
+ in Section 3.4.3 of [RFC3931].
+
+ General Result Codes regarding L2TP session establishment are defined
+ in [RFC3931]. Additional HDLC result codes are defined as follows:
+
+ 20 - HDLC Link was deleted permanently (no longer provisioned)
+ 21 - HDLC Link has been INACTIVE for an extended period of time
+
+3.3. L2TPv3 Session Maintenance
+
+ HDLCPWs over L2TP make use of the Set Link Info (SLI) control message
+ defined in [RFC3931] to signal HDLC link status notifications between
+ PEs. The SLI message is a single message that is sent over the L2TP
+ control channel, signaling the interface state change.
+
+ The SLI message MUST be sent any time there is a status change of any
+ values identified in the Circuit Status AVP. The only exceptions to
+ this are the initial ICRQ, ICRP, and CDN messages, which establish
+ and teardown the L2TP session itself. The SLI message may be sent
+ from either PE at any time after the first ICRQ is sent (and perhaps
+ before an ICRP is received, requiring the peer to perform a reverse
+ Session ID lookup).
+
+ All sessions established by a given control connection utilize the
+ L2TP Hello facility defined in Section 4.4 of [RFC3931] for session
+ keepalive. This gives all sessions basic dead peer and path
+ detection between PEs.
+
+
+
+Pignataro & Townsley Standards Track [Page 5]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+3.4. Use of Circuit Status AVP for HDLC
+
+ HDLC reports Circuit Status with the Circuit Status AVP defined in
+ [RFC3931], Attribute Type 71. For reference, this AVP is shown
+ below:
+
+ 0 1
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Reserved |N|A|
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ The Value is a 16-bit mask with the two least significant bits
+ defined and the remaining bits reserved for future use. Reserved
+ bits MUST be set to 0 when sending, and ignored upon receipt.
+
+ The N (New) bit SHOULD be set to one (1) if the Circuit Status
+ indication is for a new HDLC circuit; to zero (0) otherwise.
+
+ The A (Active) bit indicates whether the HDLC interface is ACTIVE (1)
+ or INACTIVE (0).
+
+4. Encapsulation
+
+4.1. Data Packet Encapsulation
+
+ HDLCPWs use the default encapsulations defined in [RFC3931] for
+ demultiplexing, sequencing, and flags. The HDLCPW Type over L2TP is
+ intended to operate in an "interface to interface" or "port to port"
+ fashion, passing all HDLC data and control PDUs over the PW. The
+ HDLC PDU is stripped of flags and trailing FCS, bit/byte unstuffing
+ is performed, and the remaining data, including the address, control,
+ and protocol fields, is transported over the PW.
+
+ Since all packets are passed in a largely transparent manner over the
+ HDLCPW, any protocol that has HDLC-like framing may utilize the
+ HDLCPW mode, including PPP, Frame-Relay ("port to port" Frame-Relay
+ transport), X.25 (LAPB), etc. In such cases, the negotiations and
+ signaling of the specific protocols transported over the HDLCPW take
+ place between the Remote Systems. A non-exhaustive list of examples
+ and considerations of this transparent nature include:
+
+ o When the HDLCPW transports Point-to-Point Protocol (PPP)
+ traffic, PPP negotiations (Link Control Protocol, optional
+ authentication, and Network Control Protocols) are performed
+ between Remote Systems, and LCCEs do not participate in these
+ negotiations.
+
+
+
+
+Pignataro & Townsley Standards Track [Page 6]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+ o When the HDLCPW transports Frame-Relay traffic, PVC status
+ management procedures (Local Management Interface) take place
+ between Remote Systems, and LCCEs do not participate in LMI.
+ Additionally, individual Frame-Relay virtual-circuits are not
+ visible to the LCCEs, and the FECN, BECN, and DE bits are
+ transported transparently.
+
+ o When the HDLCPW transports X.25 (LAPB) traffic, LCCEs do not
+ function as either LAPB DCE or DTE devices.
+
+ On the other hand, exceptions include cases where direct access to
+ the HDLC interface is required, or modes that operate on the flags,
+ FCS, or bit/byte unstuffing that is performed before sending the HDLC
+ PDU over the PW. An example of this is PPP ACCM negotiation.
+
+4.2. Data Packet Sequencing
+
+ Data Packet Sequencing MAY be enabled for HDLCPWs. The sequencing
+ mechanisms described in Section 4.6.1 of [RFC3931] MUST be used for
+ signaling sequencing support. HDLCPWs over L2TP MUST request the
+ presence of the L2TPv3 Default L2-Specific Sublayer defined in
+ Section 4.6 of [RFC3931] when sequencing is enabled, and MAY request
+ its presence at all times.
+
+4.3. MTU Considerations
+
+ With L2TPv3 as the tunneling protocol, the packet resulting from the
+ encapsulation is N bytes longer than the HDLC frame without the flags
+ or FCS. The value of N depends on the following fields:
+
+ L2TP Session Header:
+ Flags, Ver, Res 4 octets (L2TPv3 over UDP only)
+ Session ID 4 octets
+ Cookie Size 0, 4, or 8 octets
+ L2-Specific Sublayer 0 or 4 octets (i.e., using sequencing)
+
+ Hence the range for N in octets is:
+
+ N = 4-16, L2TPv3 data messages are over IP;
+ N = 16-28, L2TPv3 data messages are over UDP;
+ (N does not include the IP header.)
+
+ The MTU and fragmentation implications resulting from this are
+ discussed in Section 4.1.4 of [RFC3931].
+
+
+
+
+
+
+
+Pignataro & Townsley Standards Track [Page 7]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+5. Applicability Statement
+
+ HDLC Pseudowires support a "port to port" or "interface to interface"
+ deployment model operating in a point-to-point fashion. In addition
+ to the transport of HDLC frames, a natural application of HDLCPWs
+ allows for the transport of any protocol using an HDLC-like framing.
+
+ The HDLCPW emulation over a packet-switched network (PSN) has the
+ following characteristics in relationship to the native service:
+
+ o HDLC data and control fields are transported transparently (see
+ Section 4.1). The specific negotiations and signaling of the
+ protocol being transported are performed between Remote Systems
+ transparently, and the LCCE does not participate in them.
+
+ o The trailing FCS (Frame Check Sequence) containing a CRC (Cyclic
+ Redundancy Check) is stripped at the ingress LCCE and not
+ transported over HDLCPWs. It is therefore regenerated at the
+ egress LCCE (see Section 4.1). This means that the FCS may not
+ accurately reflect errors on the end-to-end HDLC link. Errors
+ or corruption introduced in the HDLCPW payload during
+ encapsulation or transit across the packet-switched network may
+ not be detected. This lack of integrity-check transparency may
+ not be of concern if it is known that the inner payloads or
+ upper protocols transported perform their own error and
+ integrity checking. To allow for payload integrity-checking
+ transparency on HDLCPWs using L2TP over IP or L2TP over UDP/IP,
+ the L2TPv3 session can utilize IPSec as specified in Section
+ 4.1.3 of [RFC3931].
+
+ o HDLC link status notification is provided using the Circuit
+ Status AVP in the SLI message (see Section 3.4).
+
+ o The length of the resulting L2TPv3 packet is longer than the
+ encapsulated HDLC frame without flags and FCS (see Section 4.3),
+ with resulting MTU and fragmentation implications discussed in
+ Section 4.1.4 of [RFC3931].
+
+ o The packet-switched network may reorder, duplicate, or silently
+ drop packets. Sequencing may be enabled in the HDLCPW for some
+ or all packets to detect lost, duplicate, or out-of-order
+ packets on a per-session basis (see Section 4.2).
+
+ o The faithfulness of an HDLCPW may be increased by leveraging
+ Quality of Service features of the LCCEs and the underlying PSN.
+
+
+
+
+
+
+Pignataro & Townsley Standards Track [Page 8]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+6. Security Considerations
+
+ HDLC over L2TPv3 is subject to the security considerations defined in
+ [RFC3931]. Beyond the considerations when carrying other data link
+ types, there are no additional considerations specific to carrying
+ HDLC.
+
+7. IANA Considerations
+
+7.1. Pseudowire Type
+
+ The signaling mechanisms defined in this document rely upon the
+ allocation of an HDLC Pseudowire Type (see Pseudowire Capabilities
+ List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in
+ 10.6 of [RFC3931]) by the IANA (number space created as part of
+ publication of [RFC3931]). The HDLC Pseudowire Type is defined in
+ Section 2 of this specification:
+
+ L2TPv3 Pseudowire Types
+ -----------------------
+
+ 0x0006 - HDLC Pseudowire Type
+
+7.2. Result Code AVP Values
+
+ This number space is managed by IANA as described in section 2.3 of
+ [BCP0068]. Two new L2TP Result Codes for the CDN message appear in
+ Section 3.2. The following is a summary:
+
+ Result Code AVP (Attribute Type 1) Values
+ -----------------------------------------
+
+ 20 - HDLC Link was deleted permanently (no longer provisioned)
+ 21 - HDLC Link has been INACTIVE for an extended period of time
+
+8. Acknowledgements
+
+ Thanks to Sudhir Rustogi and George Wilkie for valuable input. Maria
+ Alice Dos Santos provided helpful review and comment. Many thanks to
+ Mark Lewis for providing review and clarifying comments during IETF
+ Last Call.
+
+
+
+
+
+
+
+
+
+
+Pignataro & Townsley Standards Track [Page 9]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+9. References
+
+9.1. Normative References
+
+ [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
+ Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+9.2. Informative References
+
+ [BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP)
+ Internet Assigned Numbers Authority (IANA) Considerations
+ Update", BCP 68, RFC 3438, December 2002.
+
+Authors' Addresses
+
+ Carlos Pignataro
+ Cisco Systems
+ 7025 Kit Creek Road
+ PO Box 14987
+ Research Triangle Park, NC 27709
+
+ EMail: cpignata@cisco.com
+
+
+ W. Mark Townsley
+ Cisco Systems
+ 7025 Kit Creek Road
+ PO Box 14987
+ Research Triangle Park, NC 27709
+
+ EMail: mark@townsley.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Pignataro & Townsley Standards Track [Page 10]
+
+RFC 4349 HDLC Frames over L2TPv3 February 2006
+
+
+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).
+
+
+
+
+
+
+
+Pignataro & Townsley Standards Track [Page 11]
+