PPP Working Group William L. Palter INTERNET DRAFT RedBack Networks Category: Internet Draft W. Mark Townsley Title: draft-ietf-l2tpext-link-00.txt Cisco Systems Date: December 1999 L2TP Link Extensions Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026." This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``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. To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract The physical separation of the LAC and LNS with L2TP[2] and logical separation of the responsibilities of each with respect to negotiated link parameters introduces a lack of awareness between the tunnel endpoints that does not exist in a typical PPP dialup device. When possible, Proxy LCP provides a manner in which to negotiate link parameters at the LAC and communication of these in full to the LNS. If these options can be made acceptable to the LNS, then there should not be any insurmountable difficulty with regard to mismatch of link expectations. However, given that there are instances where negotiation of LCP[1] must take place at the LNS, some direction by the LAC as to what parameters are acceptable, as well as some communication from the LNS as to what parameters have been negotiated, is desirable. Table of Contents 1.0 Introduction 2.0 Communicating desired link parameters from the LAC to the LNS 2.1 LCP Want Options 2.2 LCP Allow Options 2.4 Communicating negotiated link parameters from the LNS to the LAC Palter, Townsley expires June 2000 [Page 1] INTERNET DRAFT December 1999 1.0 Introduction For the majority of topologies today, the Bearer Type, Bearer Capabilities, Framing Type, ACCM, and Framing Capabilities AVPs defined in the L2TP base specification communicate sufficient information between the LAC and LNS for a typical analog or digital dialup link with HDLC-like framing[3]. Defaults for PPP LCP options such as MRU, ACFC and PFC are well understood for various bearer and framing types and are utilized in the event that LCP negotiation by the LNS must occur. For some L2TP applications and, specifically, some PPP media types, particular link capabilities and requirements may need to be sent from the LAC to the LNS in order for the LNS to properly initialize negotiation of LCP. Further, the LCP options negotiated may need to be transmitted back to the LAC so that it may make allowances at the physical link if necessary. LCP options may be classified into roughly three different categories with respect to their affect on L2TP; (1) options which affect framing in a way that the LAC may need to know about or handle specifically (e.g., ALT-FCS, ACCM, MRU), (2) options that are transparent to the LAC (e.g., AUTH-TYPE), and (3) options that the LAC may wish to influence because they are dependent on the media type (ACFC, PFC). We are most concerned about options which fall into category (1) and (3). This document defines new AVPs to allow the LAC and the LNS to communicate complete LCP information in order to react accordingly. LCP option information is structured in the same way as the Proxy LCP AVPs are in the base L2TP specification. This essentially involves encapsulation of a PPP LCP Configure- Request or Configure-Ack packet within an L2TP AVP. 1.1 Conventions The following language conventions are used in the items of specification in this document: 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 [15]. 2.0 Communicating desired link parameters from the LAC to the LNS The LAC may utilize the following AVPs within an ICCN or OCCN message in order to influence the LNS to negotiate LCP in a specific manner. If these AVPs are supported by the LNS, they should override any suggestions for LCP options implied by all other AVPs received. These AVPs may coexist with the Proxy AVPs defined in the base L2TP specification. If Proxy AVPs are received, the LNS may choose to accept these parameters, or renegotiate LCP with the options suggested by these AVPs. If the LAC wishes to force negotiation of Palter, Townsley expires June 2000 [Page 2] INTERNET DRAFT December 1999 LCP by the LNS, it should simply omit all Proxy AVPs during call initialization. By default, the AVPs defined in 2.1 and 2.2 are not mandatory (M-bit is set to zero). However, if an LAC implementation needs to strongly enforce adherence to the options defined within the AVPs, it MAY set the M-bit to 1, thus forcing the LNS to discontinue the session if it does not support this AVP. If the AVPs in sections 2.1 and 2.2 are sent to the LNS, the LAC MUST be prepared to accept the AVPs as defined in section 2.3. 2.1 LCP Want Options 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|0|0|0|0|0| 6+LCP Confreq len | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | LCP confreq... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP contains a list of options that the LAC would like to see negotiated by the LNS. In some cases this maps to a desired value (e.g., MRU) and in some cases it maps to a specific option that is desired to be enabled (e.g., ACFC). The LNS should use these suggestions when building its initial Configure- Request. Presence of this AVP is optional. The following chart defines some of the more common LCP options that may be included in this AVP with guidance of how to handle them at the LAC and LNS. This table is provided for some of the more common or problematic LCP options. It is not intended to be an exhaustive representation of all LCP options available. LCP Want Option LAC Action LNS Action MRU LAC provides a LNS SHOULD begin negotiation maximum value with this value. However, it MAY reduce it if necessary. ACCM LAC Provides a mask LNS SHOULD begin negotiation with this value. LNS may add bit(s) while negotiating PFC LAC provides PFC LNS SHOULD being negotiation if it is desired on with this value. the link type (e.g. AHDLC) ACFC LAC provides ACCOMP LNS SHOULD begin negotiation if it is desired on with this value. the link type Palter, Townsley expires June 2000 [Page 3] INTERNET DRAFT December 1999 (e.g. AHDLC) FCS-ALT LAC indicates required LNS SHOULD begin negotiation values for the link with this value. Note type that this value is of no consequence to the LNS as FCS is stripped at the LAC, however some PPP media types require this option. 2.2 LCP Allow Options 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|0|0|0|0|0| 6+LCP Confack len | 9 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | LCP confack... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP contains a list of options that the LAC will allow to be negotiated by the LNS. In some cases this maps to a maximum value (e.g., MRU) and in others it maps to an option that is permitted by the LAC (e.g., ACFC). If the option is not included here, it can be assumed by the LNS that the LAC does not understand how to perform that particular option at the link layer. This may or may not affect operation of the tunneled session. Information in this AVP should be utilized when building PPP Configure-Ack, Configure-Reject and Configure-Nak messages. Presence of this AVP is optional. The following chart defines some of the more common LCP options that may be included in this AVP with guidance of how to handle them at the LAC and LNS. This table is provided for illutration purposes for some of the more common or problematic LCP options. It is not intended to be an exhaustive representation of all LCP options available. LCP Allow Option LAC Action LNS Action MRU LAC provides a LNS may accept reduction maximum value of this value as requested ACCM LAC Provides a mask LNS may accept bit(s) defined here. Note that if ACCM is missing it is assumed that it is not applicable to the link type PFC LAC provides PFC LNS may accept PFC if it is allowed on the link type (e.g. AHDLC) Palter, Townsley expires June 2000 [Page 4] INTERNET DRAFT December 1999 ACFC LAC provides ACFC LNS may accept ACFC if it is allowed on the link type (e.g. AHDLC) FCS-ALT LAC indicates valid Negotiation this option values for the link is of no consequence to the type LNS as the FCS is stripped at the LAC. However, the LNS SHOULD only accept FCS-ALT types listed here (more than one value may be present). 2.3 Communicating negotiated link parameters from the LNS to the LAC There are no new AVPs defined for communication of negotiated parameters from the LNS to the LAC. Instead, two AVPs that are defined in the base L2TP specification are simply included in a new location. When LCP negotiation is complete by the LNS, a Set-Link-Info control message may be sent with the the Last Sent LCP Confreq (IETF L2TP Attribute 27) and Last Received LCP Confreq (IETF L2TP Attribute 28) included in the list of AVPs. These AVPs should contain the last sent and last received (with respect to the LNS) LCP packets. For AVP format details, refer to the L2TP base specification. If LCP negotiation occurs at the LNS and the new AVPs defined in section 2.1 and 2.2 of this document are utilized, then a Set-Link- Info control message MUST be sent on completion of the LCP negotiation, and the Last Sent and Last Received LCP Confreq packets MUST be included. 3.0 Contacts W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 townsley@cisco.com Bill Palter Redback Networks 1389 Moffett Park Drive Sunnyvale, CA 94089 palter.ietf@zev.net 4.0 References [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, Palter, Townsley expires June 2000 [Page 5] INTERNET DRAFT December 1999 07/21/1994 [2] A. Valencia, W. M. Townsley, W. Palter, et. al. "Layer Two Tunneling Protocol", RFC2661 [3] W. Simpson, "PPP in HDLC-like framing", RFC 1662, 07/21/1994 Palter, Townsley expires June 2000 [Page 6]