Network Working Group Danny McPherson INTERNET DRAFT Amber Networks, Inc. Category: Internet Draft Suhail Nanji Title: draft-ietf-l2tpext-svctype-01.txt Redback Networks, Inc. Date: April 2001 L2TP Service Type <draft-ietf-l2tpext-svctype-01.txt> 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 2. Abstract The Layer Two Tunneling Protocol (L2TP) [RFC 2661] provides a standard method for tunneling PPP [RFC 1661] packets. This document describes an extension to L2TP which provides a mechanism to support tunneling of additional payload types over individual sessions within an L2TP tunnel. These extensions provide added functionality which is optional and preserves backwards compatibility. McPherson, Nanji [Page 1]
INTERNET DRAFT April 2001 3. Specification of Requirements 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 [RFC 2119]. 4. Introduction The Layer Two Tunneling Protocol defines a mechanism for tunneling PPP PDUs only. This document describes an extension which enables L2TP to support additional payload types. This extension allows sessions to carry different payloads within the same tunnel. The normal operation of L2TP is not modified if the attributes described below are not implemented. 5. Tunnel Establishment The basic tunnel establishment procedures defined in [RFC 2661] are unchanged. The only addition is that of a new AVP, the Service Capabilities List AVP, which is used for indicating which payload type(s) are supported on sessions of this tunnel. 5.1. Service Capabilities List (SCCRP, SCCRQ) The Service Capabilities List AVP is encoded as Vendor ID 311, and the Attribute Value is the 16-bit quantity 999 (the ID 311 reflects Microsoft, it should be changed to 0 and an official Attribute Value chosen should this specification advance on as standards track). The Value is a list of supported Service Types. The AVP has the following format: Vendor ID = 311 Attribute = 999 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 | 311 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 999 | Service Type 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | Service Type N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McPherson, Nanji [Page 2]
INTERNET DRAFT April 2001 The AVP MUST be present if the sender can place calls employing the Service Type when requested. Presence of a given Service Type is not a guarantee that a given call will be placed by the sender if requested, just that the capability to terminate the indicated Service Type(s) exists. The AVP MAY be hidden (the H-bit may be 0 or 1). The Length (before hiding) of this AVP MUST be 8 octets with one Service Type specified, plus 2 octets for each additional Service Type. The Service Type and Service Capabilities AVPs described in this document provide the base mechanisms for other PDUs other than PPP to be tunneled via L2TP. In order to facilitate this in a backwards compatible manner, the M-bit MUST NOT be set on the Service Capabilities AVP unless RFC 2661 PPP tunneling is NOT supported. Thus, if RFC 2661 PPP tunneling is NOT supported by a particular implementation (or disallowed by configuration or policy), the M-bit MUST be set on the Service Capabilities AVP in order to ensure that an implementation unaware of Service Types other than PPP and/or requiring a Service Type for PPP tunneling would disallow establishment of the L2TP tunnel. If the sessions on this tunnel MUST use the Service Type AVP, then the M-bit MUST be set to 1 for the Service Capabiliites List AVP. This mode of operation explicitly eliminates backwards comptability with PPP payload sessions which do not employ the Service Type AVP. In this mode, sessions carrying a PPP payload MUST use the PPP Service Type AVP value detailed below. If the sessions on this tunnel MAY use the Service Type AVP, the the M-bit MUST be set to 0 for the Service Capabilities List AVP. This mode of operation maintains backwards comptability with PPP payload sessions which do not employ the Service Type AVP. In this mode, sessions carrying a PPP payload MAY use the PPP Service Type AVP value detailed below. If a LAC or LNS requires use of the Service Type AVP for every session and it receives a Service Capabilities List AVP without the M-bit set to 0, then the tunnel MUST be torn down. If a LAC or LNS does not support the Service Type Extensions AVPs and it receives a Service Capabilities List AVP with the M-bit set to 1, then a tunnel MUST be torn down. McPherson, Nanji [Page 3]
INTERNET DRAFT April 2001 6. Session Establishment The basic call establishment procedures defined in [RFC 2661] are unchanged. A new AVP for indicating the payload type the session will support is defined. 6.1. Service Type (ICRQ, OCRQ) The Service Type AVP encodes the Service Type for the incoming or outgoing call. In order to retain backwards compatibility with [RFC 2661], if the Service Type attribute is not present, then the session MUST carry a PPP payload. If the Service Capabilities List AVP had only the PPP Service Type, then the PPP Service Type AVP MUST be used for all sessions. An LNS MUST NOT send an OCRQ with a Service Type AVP specifying a value not advertised in the Service Capabilities List AVP received from the LAC. Similarly, an LAC MUST NOT send an ICRQ with a Service Type AVP specifying a value not advertised in the Service Capabilities List AVP received from the LNS. If a Service Type AVP is received (in an ICRQ or OCRQ) and it contains a value that has not been advertised for the tunnel in the Services Capabilities List AVP, then the session MUST be torn down. The value of this attribute is one of the supported Service Types. The Service Type AVP is encoded as Vendor ID 311, and the Attribute Value is the 16-bit quantity 998 (the ID 311 reflects Microsoft, it should be changed to 0 and an official Attribute Value chosen if this specification advances on as standards track). The Service Type AVP MUST be located immediately following the Message Type AVP (unless it is hidden, in which case the Random Vector AVP will precede it). The Service Type value is represented by a 16-bit quantity of the range 0-65535. Assignment of values within this range are defined in the "Service Type AVP Values" section. Vendor ID = 311 Attribute = 998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|H|0|0|0|0| Length | 311 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 998 | Service Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ McPherson, Nanji [Page 4]
INTERNET DRAFT April 2001 The AVP MAY be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 8. 6.2. Service Type AVP Values The range of potential Service Type values is 0-65535. This document defines one of those values for PPP as defined in [RFC 2661]. Service Type AVP Values Payload Type Value Reserved 0 (zero) PPP 1 FCFS 2-65534 Reserved 65535 See Section "IANA Considerations" for additional information on Service Type AVP values. 7. Migration to Standard Attributes It is intended that both the Service Capabilities List and Service Type attributes will be migrated to standard attributes. As a result, the AVPs outlined in this draft would have a Vendor ID value of 0 and standard Attribute Values. Furthermore, it is intended the drafts "L2TP Circuit Emulation Services Extension" and "Ethernet Encapsulation Extensions to L2TP" will be deprecated. 8. IANA Considerations The Service Type AVP namespace will be registered and maintained by IANA as follows: o Values 0 and 65535 are reserved. o Value 1 is reserved for PPP payloads. o Values between 2 and 65534 are to be assigned by IANA, using the "Specification Required" policy listed below [RFC 2434]. McPherson, Nanji [Page 5]
INTERNET DRAFT April 2001 8.1. Specification Requirements for New Service Types To define a new Service Type for a payload other than PPP,a new RFC MUST be drafted which MUST: o Identify any new L2TP AVPs or control messases necessary for the establishment, maintenance, and teardown of the non-PPP session. o Identify which AVPs must be present (new or existing) in each existing or new control message with a given service type. o Identify any existing AVPs which have a new or revised meaning for a given Service Type beyond that defined in RFC2661. 9. Security Considerations This extension to L2TP does not changes the inherent security of L2TP, nor does it introduce new security issues. 10. Acknowledgements Thanks to W. Mark Townsley of Cisco Systems, Bill Palter of Redback Networks, and Nishit Vasavada and Andy Koscinski of Amber Networks. Copious amounts of text were stolen from the L2TP [RFC 2661]. Special thanks to Glen Zorn for suggesting to use Microsoft's Vendor ID for the new AVPs in the interim. 11. References [RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC2661, August 1999. [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations section in RFCs", BCP 26, RFC 2434, October 1998. McPherson, Nanji [Page 6]
INTERNET DRAFT April 2001 12. Authors' Address Danny McPherson Amber Networks, Inc. 48664 Milmont Drive Fremont, CA 94538 Phone: +510 687-5200 Email: danny@ambernetworks.com Suhail Nanji Redback Networks, Inc. 350 Holger Way San Jose, CA 95134-1362 Phone: +1 408 571 5413 Email: suhail@redback.com McPherson, Nanji [Page 7]
