PPP Working Group Richard Shea INTERNET DRAFT Nortel Networks Category: Internet Draft Title: draft-ietf-pppext-l2tpmsgext-00.txt Date: November 1998 Framework for L2TP Message Extensions Status of this Memo 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.'' 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 Layer Two Tunneling Protocol (L2TP) defines mechanisms for extensibility. The mechanisms provided are for Attribute-Value Pair (AVP) fields received in control messages to be set as Mandatory or not. This document specifies a mechanism whereby an L2TP implementation can signal its support of the set of L2TP extensions that it supports. This then allows the L2TP implementations to use extensions such as L2TP message types not defined in [1], the presence of existing AVPs in messages they are not currently defined to be in, and the definition of new AVPs that can be marked as Mandatory, beyond those defined in [1]. 1. Introduction In the L2TP protocol AVPs include a bit specifying whether or not the AVP is mandatory. To do this, a bit in the AVP called the M bit is used. If the M bit is set in a received AVP and the AVP is Shea expires May 1999 [Page 1] INTERNET DRAFT November 1998 unrecognized then the receiving implementation either tears down the tunnel or a call, depending on the value of the Call ID field in the control message. If the M bit is not set in a received AVP and the AVP is unrecognized then the receiving implementation ignores the AVP as if it hadn't appeared in the control message. Since the Message Type AVP found first in a control message must have the M bit set, an L2TP implementation cannot safely send a control message not defined in [1] without first determining that the peer will understand the message. A signaling mechanism must therefore be defined which allows this information to be known. There may also be the need for extensions of L2TP to define new AVPs that are defined to be sent with the M bit set. Again, this cannot be safely done unless the implementation first determines that the peer should be able to handle the AVP. In this case a signaling mechanism is required. Another behavior that can be enabled by the signaling of supported extensions is the presence of previously defined AVPs in control messages that they are not currently defined to be found in. By providing a predefined signaling mechanism future extensions can specify the use of AVPs with mandatory and optional AVPs defined and the use of message types not defined in [1]. This in turn should make extensions to L2TP easier to implement and operate under a common framework. This document does not attempt to limit the design of future extensions to the mechanisms defined within. The purpose is to provide a common framework for extensions that optionally add new message types and that require AVPs with the M bit set, but only if the both peers support the extension. For example, it is completely acceptable for an extension to specify the sending of a new AVP with the M bit set without knowing if the peer supports the option. In this case it would be understood that the nature of the extension is such that the desired behavior for a receiving peer that did not understand the new AVP would be to close the tunnel or the call as appropriate. 1.1 Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- This item is an absolute requirement of the specification. Shea expires May 1999 [Page 2] INTERNET DRAFT November 1998 o SHOULD or RECOMMEND -- This item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- This item is truly optional and may be followed or ignored according to the needs of the implementor. 1.2 Terminology This draft assumes the reader is knowledgable about terms found in [1]. 2. Protocol additions This document specifies the use of a new AVP called the Extensions AVP that can be sent in the Start-Control-Channel-Request (SCCRQ) and Start-Control-Channel-Reply (SCCRP) control messages. The purpose of this new AVP is to signal to the peer the extensions supported by the sending implementation. Extensions 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0| 6 + value len | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [TBD] | Bit string of supported +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ extensions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Extensions AVP encodes the L2TP extensions supported by the sending implementation. This AVP is not marked as Mandatory. The AVP itself is optional in the SCCRQ and SCCRP control messages. The value field of this AVP is a bit string of the supported options. The bits will be assigned to extensions starting with the most significant bit of the first octet of the value field. If the bit corresponding to an extension is set to one (1) the extension is supported by the sender. If the bit is set to zero (0) the extension is not supported by the sender. The value field can essentially be right-padded with zero bit values in order to make the number of octets making up the value field produce reasonable data alignment in the control message. It is expected that until more than 16 extensions are defined the value field will most commonly be 2 octets. Extensions Value Shea expires May 1999 [Page 3] INTERNET DRAFT November 1998 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |W| 0 (unassigned) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ W (Dynamic Data Window) Extension The most significant bit of the first byte of the Extensions AVP value field signals whether or not the L2TP dynamic data window adjustment [2] extension is supported. 3. Protocol Operation An L2TP implementation can signal the L2TP extensions it supports using the Extensions AVP. For the tunnel initiator this AVP MAY be sent in the SCCRQ. For the tunnel responder this AVP MAY be found in the SCCRP. The SCCRQ MUST NOT contain any AVPs that would require the peer to support a particular extension that would be signaled using the Extensions AVP. Depending on the requirements of the extension, AVPs NOT marked as Mandatory that are specific to a particular extension MAY be included in the SCCRQ. An implementation MUST NOT include an AVP in a control message that it is not previously defined to be included in, even if the AVP itself is previously defined, without first signaling the support of such an extension with the Extensions AVP. 4. Security Considerations Security is not addressed in this document. References [1] A. Valencia, et al, "Layer Two Tunneling Protocol", Work In Progress: draft-ietf-pppext-l2tp-12.txt, October 1998 [2] R. Shea, "L2TP Dynamic Data Window Adjustment", Work In Progress: draft-ietf-pppext-l2tpdwin-01.txt, November 1998 Author's Address Richard Shea Nortel Networks Shea expires May 1999 [Page 4] INTERNET DRAFT November 1998 125 Nagog Park Acton, Massachusetts 01720 rshea@BayNetworks.com Shea expires May 1999 [Page 5] INTERNET DRAFT November 1998