Network Working Group W. Townsley
`Request for Comments: 2661 A. Valencia
`Category: Standards Track cisco Systems
` A. Rubens
` Ascend Communications
` G. Pall
` G. Zorn
` Microsoft Corporation
` B. Palter
` Redback Networks
` August 1999
`
` Layer Two Tunneling Protocol "L2TP"
`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 (1999). All Rights Reserved.
`Abstract
` This document describes the Layer Two Tunneling Protocol (L2TP). STD
` 51, RFC 1661 specifies multi-protocol access via PPP [RFC1661]. L2TP
` facilitates the tunneling of PPP packets across an intervening
` network in a way that is as transparent as possible to both end-users
` and applications.
`Table of Contents
` 1.0 Introduction.......................................... 3
` 1.1 Specification of Requirements......................... 4
` 1.2 Terminology........................................... 4
` 2.0 Topology.............................................. 8
` 3.0 Protocol Overview..................................... 9
` 3.1 L2TP Header Format.................................... 9
` 3.2 Control Message Types................................. 11
` 4.0 Control Message Attribute Value Pairs................. 12
` 4.1 AVP Format............................................ 13
` 4.2 Mandatory AVPs........................................ 14
` 4.3 Hiding of AVP Attribute Values........................ 14
`
`Townsley, et al. Standards Track [Page 1]
`RFC 2661 L2TP August 1999
`
` 4.4 AVP Summary........................................... 17
` 4.4.1 AVPs Applicable To All Control Messages.......... 17
` 4.4.2 Result and Error Codes........................... 18
` 4.4.3 Control Connection Management AVPs............... 20
` 4.4.4 Call Management AVPs............................. 27
` 4.4.5 Proxy LCP and Authentication AVPs................ 34
` 4.4.6 Call Status AVPs................................. 39
` 5.0 Protocol Operation.................................... 41
` 5.1 Control Connection Establishment...................... 41
` 5.1.1 Tunnel Authentication............................ 42
` 5.2 Session Establishment................................. 42
` 5.2.1 Incoming Call Establishment...................... 42
` 5.2.2 Outgoing Call Establishment...................... 43
` 5.3 Forwarding PPP Frames................................. 43
` 5.4 Using Sequence Numbers on the Data Channel............ 44
` 5.5 Keepalive (Hello)..................................... 44
` 5.6 Session Teardown...................................... 45
` 5.7 Control Connection Teardown........................... 45
` 5.8 Reliable Delivery of Control Messages................. 46
` 6.0 Control Connection Protocol Specification............. 48
`
`http://www.ietf.org/rfc/rfc2661[7/8/2011 8:28:12 PM]
`
`Petitioner RPX Corporation - Ex. 1038, p. 1
`
`

`

` 6.1 Start-Control-Connection-Request (SCCRQ).............. 48
` 6.2 Start-Control-Connection-Reply (SCCRP)................ 48
` 6.3 Start-Control-Connection-Connected (SCCCN)............ 49
` 6.4 Stop-Control-Connection-Notification (StopCCN)........ 49
` 6.5 Hello (HELLO)......................................... 49
` 6.6 Incoming-Call-Request (ICRQ).......................... 50
` 6.7 Incoming-Call-Reply (ICRP)............................ 51
` 6.8 Incoming-Call-Connected (ICCN)........................ 51
` 6.9 Outgoing-Call-Request (OCRQ).......................... 52
` 6.10 Outgoing-Call-Reply (OCRP)........................... 53
` 6.11 Outgoing-Call-Connected (OCCN)....................... 53
` 6.12 Call-Disconnect-Notify (CDN)......................... 53
` 6.13 WAN-Error-Notify (WEN)............................... 54
` 6.14 Set-Link-Info (SLI).................................. 54
` 7.0 Control Connection State Machines..................... 54
` 7.1 Control Connection Protocol Operation................. 55
` 7.2 Control Connection States............................. 56
` 7.2.1 Control Connection Establishment................. 56
` 7.3 Timing considerations................................. 58
` 7.4 Incoming calls........................................ 58
` 7.4.1 LAC Incoming Call States......................... 60
` 7.4.2 LNS Incoming Call States......................... 62
` 7.5 Outgoing calls........................................ 63
` 7.5.1 LAC Outgoing Call States......................... 64
` 7.5.2 LNS Outgoing Call States......................... 66
` 7.6 Tunnel Disconnection.................................. 67
` 8.0 L2TP Over Specific Media.............................. 67
` 8.1 L2TP over UDP/IP...................................... 68
`
`Townsley, et al. Standards Track [Page 2]
`RFC 2661 L2TP August 1999
`
` 8.2 IP.................................................... 69
` 9.0 Security Considerations............................... 69
` 9.1 Tunnel Endpoint Security.............................. 70
` 9.2 Packet Level Security................................. 70
` 9.3 End to End Security................................... 70
` 9.4 L2TP and IPsec........................................ 71
` 9.5 Proxy PPP Authentication.............................. 71
` 10.0 IANA Considerations.................................. 71
` 10.1 AVP Attributes....................................... 71
` 10.2 Message Type AVP Values.............................. 72
` 10.3 Result Code AVP Values............................... 72
` 10.3.1 Result Code Field Values........................ 72
` 10.3.2 Error Code Field Values......................... 72
` 10.4 Framing Capabilities & Bearer Capabilities........... 72
` 10.5 Proxy Authen Type AVP Values......................... 72
` 10.6 AVP Header Bits...................................... 73
` 11.0 References........................................... 73
` 12.0 Acknowledgments...................................... 74
` 13.0 Authors' Addresses................................... 75
` Appendix A: Control Channel Slow Start and Congestion
` Avoidance..................................... 76
` Appendix B: Control Message Examples...................... 77
` Appendix C: Intellectual Property Notice.................. 79
` Full Copyright Statement.................................. 80
`1.0 Introduction
` PPP [RFC1661] defines an encapsulation mechanism for transporting
` multiprotocol packets across layer 2 (L2) point-to-point links.
` Typically, a user obtains a L2 connection to a Network Access Server
` (NAS) using one of a number of techniques (e.g., dialup POTS, ISDN,
` ADSL, etc.) and then runs PPP over that connection. In such a
` configuration, the L2 termination point and PPP session endpoint
` reside on the same physical device (i.e., the NAS).
` L2TP extends the PPP model by allowing the L2 and PPP endpoints to
` reside on different devices interconnected by a packet-switched
` network. With L2TP, a user has an L2 connection to an access
` concentrator (e.g., modem bank, ADSL DSLAM, etc.), and the
` concentrator then tunnels individual PPP frames to the NAS. This
` allows the actual processing of PPP packets to be divorced from the
` termination of the L2 circuit.
` One obvious benefit of such a separation is that instead of requiring
` the L2 connection terminate at the NAS (which may require a
`
`http://www.ietf.org/rfc/rfc2661[7/8/2011 8:28:12 PM]
`
`Petitioner RPX Corporation - Ex. 1038, p. 2
`
`

`

` long-distance toll charge), the connection may terminate at a (local)
` circuit concentrator, which then extends the logical PPP session over
`
`Townsley, et al. Standards Track [Page 3]
`RFC 2661 L2TP August 1999
`
` a shared infrastructure such as frame relay circuit or the Internet.
` From the user's perspective, there is no functional difference between
` having the L2 circuit terminate in a NAS directly or using L2TP.
` L2TP may also solve the multilink hunt-group splitting problem.
` Multilink PPP [RFC1990] requires that all channels composing a
` multilink bundle be grouped at a single Network Access Server (NAS).
` Due to its ability to project a PPP session to a location other than
` the point at which it was physically received, L2TP can be used to
` make all channels terminate at a single NAS. This allows multilink
` operation even when the calls are spread across distinct physical
` NASs.
` This document defines the necessary control protocol for on-demand
` creation of tunnels between two nodes and the accompanying
` encapsulation for multiplexing multiple, tunneled PPP sessions.
`1.1 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 [RFC2119].
`1.2 Terminology
` Analog Channel
` A circuit-switched communication path which is intended to carry
` 3.1 kHz audio in each direction.
` Attribute Value Pair (AVP)
` The variable length concatenation of a unique Attribute
` (represented by an integer) and a Value containing the actual
` value identified by the attribute. Multiple AVPs make up Control
` Messages which are used in the establishment, maintenance, and
` teardown of tunnels.
` Call
` A connection (or attempted connection) between a Remote System and
` LAC. For example, a telephone call through the PSTN. A Call
` (Incoming or Outgoing) which is successfully established between a
` Remote System and LAC results in a corresponding L2TP Session
` within a previously established Tunnel between the LAC and LNS.
` (See also: Session, Incoming Call, Outgoing Call).
`
`Townsley, et al. Standards Track [Page 4]
`RFC 2661 L2TP August 1999
`
` Called Number
` An indication to the receiver of a call as to what telephone
` number the caller used to reach it.
` Calling Number
` An indication to the receiver of a call as to the telephone number
` of the caller.
` CHAP
` Challenge Handshake Authentication Protocol [RFC1994], a PPP
` cryptographic challenge/response authentication protocol in which
`
`http://www.ietf.org/rfc/rfc2661[7/8/2011 8:28:12 PM]
`
`Petitioner RPX Corporation - Ex. 1038, p. 3
`
`

`

` the cleartext password is not passed over the line.
` Control Connection
` A control connection operates in-band over a tunnel to control the
` establishment, release, and maintenance of sessions and of the
` tunnel itself.
` Control Messages
` Control messages are exchanged between LAC and LNS pairs,
` operating in-band within the tunnel protocol. Control messages
` govern aspects of the tunnel and sessions within the tunnel.
` Digital Channel
` A circuit-switched communication path which is intended to carry
` digital information in each direction.
` DSLAM
` Digital Subscriber Line (DSL) Access Module. A network device used
` in the deployment of DSL service. This is typically a concentrator
` of individual DSL lines located in a central office (CO) or local
` exchange.
` Incoming Call
` A Call received at an LAC to be tunneled to an LNS (see Call,
` Outgoing Call).
`
`Townsley, et al. Standards Track [Page 5]
`RFC 2661 L2TP August 1999
`
` L2TP Access Concentrator (LAC)
` A node that acts as one side of an L2TP tunnel endpoint and is a
` peer to the L2TP Network Server (LNS). The LAC sits between an
` LNS and a remote system and forwards packets to and from each.
` Packets sent from the LAC to the LNS requires tunneling with the
` L2TP protocol as defined in this document. The connection from
` the LAC to the remote system is either local (see: Client LAC) or
` a PPP link.
` L2TP Network Server (LNS)
` A node that acts as one side of an L2TP tunnel endpoint and is a
` peer to the L2TP Access Concentrator (LAC). The LNS is the
` logical termination point of a PPP session that is being tunneled
` from the remote system by the LAC.
` Management Domain (MD)
` A network or networks under the control of a single
` administration, policy or system. For example, an LNS's Management
` Domain might be the corporate network it serves. An LAC's
` Management Domain might be the Internet Service Provider that owns
` and manages it.
` Network Access Server (NAS)
` A device providing local network access to users across a remote
` access network such as the PSTN. An NAS may also serve as an LAC,
` LNS or both.
` Outgoing Call
` A Call placed by an LAC on behalf of an LNS (see Call, Incoming
` Call).
` Peer
` When used in context with L2TP, peer refers to either the LAC or
`
`http://www.ietf.org/rfc/rfc2661[7/8/2011 8:28:12 PM]
`
`Petitioner RPX Corporation - Ex. 1038, p. 4
`
`

`

` LNS. An LAC's Peer is an LNS and vice versa. When used in context
` with PPP, a peer is either side of the PPP connection.
` POTS
` Plain Old Telephone Service.
`
`Townsley, et al. Standards Track [Page 6]
`RFC 2661 L2TP August 1999
`
` Remote System
` An end-system or router attached to a remote access network (i.e.
` a PSTN), which is either the initiator or recipient of a call.
` Also referred to as a dial-up or virtual dial-up client.
` Session
` L2TP is connection-oriented. The LNS and LAC maintain state for
` each Call that is initiated or answered by an LAC. An L2TP Session
` is created between the LAC and LNS when an end-to-end PPP
` connection is established between a Remote System and the LNS.
` Datagrams related to the PPP connection are sent over the Tunnel
` between the LAC and LNS. There is a one to one relationship
` between established L2TP Sessions and their associated Calls. (See
` also: Call).
` Tunnel
` A Tunnel exists between a LAC-LNS pair. The Tunnel consists of a
` Control Connection and zero or more L2TP Sessions. The Tunnel
` carries encapsulated PPP datagrams and Control Messages between
` the LAC and the LNS.
` Zero-Length Body (ZLB) Message
` A control packet with only an L2TP header. ZLB messages are used
` for explicitly acknowledging packets on the reliable control
` channel.
`
`Townsley, et al. Standards Track [Page 7]
`RFC 2661 L2TP August 1999
`
`2.0 Topology
` The following diagram depicts a typical L2TP scenario. The goal is to
` tunnel PPP frames between the Remote System or LAC Client and an LNS
` located at a Home LAN.
` [Home LAN]
` [LAC Client]----------+ |
`
`http://www.ietf.org/rfc/rfc2661[7/8/2011 8:28:12 PM]
`
`Petitioner RPX Corporation - Ex. 1038, p. 5
`
`

`

` ____|_____ +--[Host]
` | | |
` [LAC]---------| Internet |-----[LNS]-----+
` | |__________| |
` _____|_____ :
` | |
` | PSTN |
` [Remote]--| Cloud |
` [System] | | [Home LAN]
` |___________| |
` | ______________ +---[Host]
` | | | |
` [LAC]-------| Frame Relay |---[LNS]-----+
` | or ATM Cloud | |
` |______________| :
` The Remote System initiates a PPP connection across the PSTN Cloud to
` an LAC. The LAC then tunnels the PPP connection across the Internet,
` Frame Relay, or ATM Cloud to an LNS whereby access to a Home LAN is
` obtained. The Remote System is provided addresses from the HOME LAN
` via PPP NCP negotiation. Authentication, Authorization and Accounting
` may be provided by the Home LAN's Management Domain as if the user
` were connected to a Network Access Server directly.
` A LAC Client (a Host which runs L2TP natively) may also participate
` in tunneling to the Home LAN without use of a separate LAC. In this
` case, the Host containing the LAC Client software already has a
` connection to the public Internet. A "virtual" PPP connection is then
` created and the local L2TP LAC Client software creates a tunnel to
` the LNS. As in the above case, Addressing, Authentication,
` Authorization and Accounting will be provided by the Home LAN's
` Management Domain.
`
`Townsley, et al. Standards Track [Page 8]
`RFC 2661 L2TP August 1999
`
`3.0 Protocol Overview
` L2TP utilizes two types of messages, control messages and data
` messages. Control messages are used in the establishment, maintenance
` and clearing of tunnels and calls. Data messages are used to
` encapsulate PPP frames being carried over the tunnel. Control
` messages utilize a reliable Control Channel within L2TP to guarantee
` delivery (see section 5.1 for details). Data messages are not
` retransmitted when packet loss occurs.
` +-------------------+
` | PPP Frames |
` +-------------------+ +-----------------------+
` | L2TP Data Messages| | L2TP Control Messages |
` +-------------------+ +-----------------------+
` | L2TP Data Channel | | L2TP Control Channel |
` | (unreliable) | | (reliable) |
` +------------------------------------------------+
` | Packet Transport (UDP, FR, ATM, etc.) |
` +------------------------------------------------+
` Figure 3.0 L2TP Protocol Structure
` Figure 3.0 depicts the relationship of PPP frames and Control
` Messages over the L2TP Control and Data Channels. PPP Frames are
` passed over an unreliable Data Channel encapsulated first by an L2TP
` header and then a Packet Transport such as UDP, Frame Relay, ATM,
` etc. Control messages are sent over a reliable L2TP Control Channel
` which transmits packets in-band over the same Packet Transport.
` Sequence numbers are required to be present in all control messages
` and are used to provide reliable delivery on the Control Channel.
` Data Messages may use sequence numbers to reorder packets and detect
`
`http://www.ietf.org/rfc/rfc2661[7/8/2011 8:28:12 PM]
`
`Petitioner RPX Corporation - Ex. 1038, p. 6
`
`

`

` lost packets.
` All values are placed into their respective fields and sent in
` network order (high order octets first).
`3.1 L2TP Header Format
` L2TP packets for the control channel and data channel share a common
` header format. In each case where a field is optional, its space does
` not exist in the message if the field is marked not present. Note
` that while optional on data messages, the Length, Ns, and Nr fields
` marked as optional below, are required to be present on all control
` messages.
`
`Townsley, et al. Standards Track [Page 9]
`RFC 2661 L2TP August 1999
`
` This header is formatted:
` 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
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Tunnel ID | Session ID |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Ns (opt) | Nr (opt) |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Offset Size (opt) | Offset pad... (opt)
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` Figure 3.1 L2TP Message Header
` The Type (T) bit indicates the type of message. It is set to 0 for a
` data message and 1 for a control message.
` If the Length (L) bit is 1, the Length field is present. This bit
` MUST be set to 1 for control messages.
` The x bits are reserved for future extensions. All reserved bits MUST
` be set to 0 on outgoing messages and ignored on incoming messages.
` If the Sequence (S) bit is set to 1 the Ns and Nr fields are present.
` The S bit MUST be set to 1 for control messages.
` If the Offset (O) bit is 1, the Offset Size field is present. The O
` bit MUST be set to 0 (zero) for control messages.
` If the Priority (P) bit is 1, this data message should receive
` preferential treatment in its local queuing and transmission. LCP
` echo requests used as a keepalive for the link, for instance, should
` generally be sent with this bit set to 1. Without it, a temporary
` interval of local congestion could result in interference with
` keepalive messages and unnecessary loss of the link. This feature is
` only for use with data messages. The P bit MUST be set to 0 for all
` control messages.
` Ver MUST be 2, indicating the version of the L2TP data message header
` described in this document. The value 1 is reserved to permit
` detection of L2F [RFC2341] packets should they arrive intermixed with
` L2TP packets. Packets received with an unknown Ver field MUST be
` discarded.
` The Length field indicates the total length of the message in octets.
`
`Townsley, et al. Standards Track [Page 10]
`RFC 2661 L2TP August 1999
`
` Tunnel ID indicates the identifier for the control connection. L2TP
` tunnels are named by identifiers that have local significance only.
`
`http://www.ietf.org/rfc/rfc2661[7/8/2011 8:28:12 PM]
`
`Petitioner RPX Corporation - Ex. 1038, p. 7
`
`

`

` That is, the same tunnel will be given different Tunnel IDs by each
` end of the tunnel. Tunnel ID in each message is that of the intended
` recipient, not the sender. Tunnel IDs are selected and exchanged as
` Assigned Tunnel ID AVPs during the creation of a tunnel.
` Session ID indicates the identifier for a session within a tunnel.
` L2TP sessions are named by identifiers that have local significance
` only. That is, the same session will be given different Session IDs
` by each end of the session. Session ID in each message is that of the
` intended recipient, not the sender. Session IDs are selected and
` exchanged as Assigned Session ID AVPs during the creation of a
` session.
` Ns indicates the sequence number for this data or control message,
` beginning at zero and incrementing by one (modulo 2**16) for each
` message sent. See Section 5.8 and 5.4 for more information on using
` this field.
` Nr indicates the sequence number expected in the next control message
` to be received. Thus, Nr is set to the Ns of the last in-order
` message received plus one (modulo 2**16). In data messages, Nr is
` reserved and, if present (as indicated by the S-bit), MUST be ignored
` upon receipt. See section 5.8 for more information on using this
` field in control messages.
` The Offset Size field, if present, specifies the number of octets
` past the L2TP header at which the payload data is expected to start.
` Actual data within the offset padding is undefined. If the offset
` field is present, the L2TP header ends after the last octet of the
` offset padding.
`3.2 Control Message Types
` The Message Type AVP (see section 4.4.1) defines the specific type of
` control message being sent. Recall from section 3.1 that this is only
` for control messages, that is, messages with the T-bit set to 1.
`
`Townsley, et al. Standards Track [Page 11]
`RFC 2661 L2TP August 1999
`
` This document defines the following control message types (see
` Section 6.1 through 6.14 for details on the construction and use of
` each message):
` Control Connection Management
` 0 (reserved)
` 1 (SCCRQ) Start-Control-Connection-Request
` 2 (SCCRP) Start-Control-Connection-Reply
` 3 (SCCCN) Start-Control-Connection-Connected
` 4 (StopCCN) Stop-Control-Connection-Notification
` 5 (reserved)
` 6 (HELLO) Hello
` Call Management
` 7 (OCRQ) Outgoing-Call-Request
` 8 (OCRP) Outgoing-Call-Reply
` 9 (OCCN) Outgoing-Call-Connected
` 10 (ICRQ) Incoming-Call-Request
` 11 (ICRP) Incoming-Call-Reply
` 12 (ICCN) Incoming-Call-Connected
` 13 (reserved)
` 14 (CDN) Call-Disconnect-Notify
` Error Reporting
`
`http://www.ietf.org/rfc/rfc2661[7/8/2011 8:28:12 PM]
`
`Petitioner RPX Corporation - Ex. 1038, p. 8
`
`

`

` 15 (WEN) WAN-Error-Notify
` PPP Session Control
` 16 (SLI) Set-Link-Info
`4.0 Control Message Attribute Value Pairs
` To maximize extensibility while still permitting interoperability, a
` uniform method for encoding message types and bodies is used
` throughout L2TP. This encoding will be termed AVP (Attribute-Value
` Pair) in the remainder of this document.
`
`Townsley, et al. Standards Track [Page 12]
`RFC 2661 L2TP August 1999
`
`4.1 AVP Format
` Each AVP is encoded as:
` 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| rsvd | Length | Vendor ID |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` | Attribute Type | Attribute Value...
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` [until Length is reached]... |
` +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
` The first six bits are a bit mask, describing the general attributes
` of the AVP.
` Two bits are defined in this document, the remaining are reserved for
` future extensions. Reserved bits MUST be set to 0. An AVP received
` with a reserved bit set to 1 MUST be treated as an unrecognized AVP.
` Mandatory (M) bit: Controls the behavior required of an
` implementation which receives an AVP which it does not recognize. If
` the M bit is set on an unrecognized AVP within a message associated
` with a particular session, the session associated with this message
` MUST be terminated. If the M bit is set on an unrecognized AVP within
` a message associated with the overall tunnel, the entire tunnel (and
` all sessions within) MUST be terminated. If the M bit is not set, an
` unrecognized AVP MUST be ignored. The control message must then
` continue to be processed as if the AVP had not been present.
` Hidden (H) bit: Identifies the hiding of data in the Attribute Value
` field of an AVP. This capability can be used to avoid the passing of
` sensitive data, such as user passwords, as cleartext in an AVP.
` Section 4.3 describes the procedure for performing AVP hiding.
` Length: Encodes the number of octets (including the Overall Length
` and bitmask fields) contained in this AVP. The Length may be
` calculated as 6 + the length of the Attribute Value field in octets.
` The field itself is 10 bits, permitting a maximum of 1023 octets of
` data in a single AVP. The minimum Length of an AVP is 6. If the
` length is 6, then the Attribute Value field is absent.
` Vendor ID: The IANA assigned "SMI Network Management Private
` Enterprise Codes" [RFC1700] value. The value 0, corresponding to
` IETF adopted attribute values, is used for all AVPs defined within
` this document. Any vendor wishing to implement their own L2TP
` extensions can use their own Vendor ID along with private Attribute
`
`Townsley, et al. Standards Track [Page 13]
`
`http://www.ietf.org/rfc/rfc2661[7/8/2011 8:28:12 PM]
`
`Petitioner RPX Corporation - Ex. 1038, p. 9
`
`

`

`RFC 2661 L2TP August 1999
`
` values, guaranteeing that they will not collide with any other
` vendor's extensions, nor with future IETF extensions. Note that there
` are 16 bits allocated for the Vendor ID, thus limiting this feature
` to the first 65,535 enterprises.
` Attribute Type: A 2 octet value with a unique interpretation across
` all AVPs defined under a given Vendor ID.
` Attribute Value: This is the actual value as indicated by the Vendor
` ID and Attribute Type. It follows immediately after the Attribute
` Type field, and runs for the remaining octets indicated in the Length
` (i.e., Length minus 6 octets of header). This field is absent if the
` Length is 6.
`4.2 Mandatory AVPs
` Receipt of an unknown AVP that has the M-bit set is catastrophic to
` the session or tunnel it is associated with. Thus, the M bit should
` only be defined for AVPs which are absolutely crucial to proper
` operation of the session or tunnel. Further, in the case where the
` LAC or LNS receives an unknown AVP with the M-bit set and shuts down
` the session or tunnel accordingly, it is the full responsibility of
` the peer sending the Mandatory AVP to accept fault for causing an
` non-interoperable situation. Before defining an AVP with the M-bit
` set, particularly a vendor-specific AVP, be sure that this is the
` intended consequence.
` When an adequate alternative exists to use of the M-bit, it should be
` utilized. For example, rather than simply sending an AVP with the M-
` bit set to determine if a specific extension exists, availability may
` be identified by sending an AVP in a request message and expecting a
` corresponding AVP in a reply message.
` Use of the M-bit with new AVPs (those not defined in this document)
` MUST provide the ability to configure the associated feature off,
` such that the AVP is either not sent, or sent with the M-bit not set.
`4.3 Hiding of AVP Attribute Values
` The H bit in the header of each AVP provides a mechanism to indicate
` to the receiving peer whether the contents of the AVP are hidden or
` present in cleartext. This feature can be used to hide sensitive
` control message data such as user passwords or user IDs.
` The H bit MUST only be set if a shared secret exists between the LAC
` and LNS. The shared secret is the same secret that is used for tunnel
` authentication (see Section 5.1.1). If the H bit is set in any
`
`Townsley, et al. Standards Track [Page 14]
`RFC 2661 L2TP August 1999
`
` AVP(s) in a given control message, a Random Vector AVP must also be
` present in the message and MUST precede the first AVP having an H bit
` of 1.
` Hiding an AVP value is done in several steps. The first step is to
` take the length and value fields of the original (cleartext) AVP and
` encode them into a Hidden AVP Subformat as follows:
` 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
`