idnits 2.17.1 draft-ietf-l2tpext-l2tp-ppp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1976. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1987. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1994. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2000. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 10, 2008) is 5768 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.Q931.1998' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2TPEXT Working Group C. Pignataro, Ed. 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track July 10, 2008 5 Expires: January 11, 2009 7 PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3) 8 draft-ietf-l2tpext-l2tp-ppp-08 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 11, 2009. 35 Abstract 37 This document describes the use of "version 3" of Layer Two Tunneling 38 Protocol (L2TPv3) to tunnel Point-to-Point Protocol (PPP) packets. 39 This document defines the control protocol and encapsulation 40 specifics for tunneling PPP over L2TPv3, and is a companion document 41 to the L2TPv3 base specification. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 47 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 48 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . . 6 50 2. Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 3. Control Channel Specifics for PPP . . . . . . . . . . . . . . 7 53 3.1. Control Connection Establishment . . . . . . . . . . . . . 7 54 3.2. Session Establishment . . . . . . . . . . . . . . . . . . 7 55 3.3. Session Maintenance . . . . . . . . . . . . . . . . . . . 8 57 4. Data Channel Specifics for PPP . . . . . . . . . . . . . . . . 9 58 4.1. L2-Specific Sublayer . . . . . . . . . . . . . . . . . . . 10 59 4.2. Offset Padding . . . . . . . . . . . . . . . . . . . . . . 10 60 4.3. Forwarding PPP Frames . . . . . . . . . . . . . . . . . . 11 62 5. AVP Description . . . . . . . . . . . . . . . . . . . . . . . 12 63 5.1. PPP-Specific AVPs . . . . . . . . . . . . . . . . . . . . 12 64 5.1.1. Control Connection Management AVPs . . . . . . . . . . 13 65 5.1.1.1. Framing Capabilities (SCCRP, SCCRQ) . . . . . . . 13 66 5.1.1.2. Bearer Capabilities (SCCRP, SCCRQ) . . . . . . . . 13 67 5.1.1.3. Offset Capability (SCCRP, SCCRQ) . . . . . . . . . 14 68 5.1.2. Session Management AVPs . . . . . . . . . . . . . . . 15 69 5.1.2.1. Bearer Type (ICRQ, OCRQ) . . . . . . . . . . . . . 15 70 5.1.2.2. Framing Type (ICCN, OCCN, OCRQ) . . . . . . . . . 16 71 5.1.2.3. Called Number (ICRQ, OCRQ) . . . . . . . . . . . . 16 72 5.1.2.4. Calling Number (ICRQ) . . . . . . . . . . . . . . 17 73 5.1.2.5. Called Sub-Address (ICRQ, OCRQ) . . . . . . . . . 18 74 5.1.2.6. Calling Sub-Address (ICRQ) . . . . . . . . . . . . 18 75 5.1.2.7. Q.931 Cause Code (CDN) . . . . . . . . . . . . . . 19 76 5.1.2.8. Private Group ID (ICCN) . . . . . . . . . . . . . 19 77 5.1.2.9. Offset Size (ICRQ, ICRP, ORCQ, OCRP) . . . . . . . 20 78 5.1.2.10. Tx Minimum Speed (OCRQ) . . . . . . . . . . . . . 21 79 5.1.2.11. Tx Maximum Speed (OCRQ) . . . . . . . . . . . . . 22 80 5.1.2.12. Rx Minimum Speed (OCRQ) . . . . . . . . . . . . . 23 81 5.1.2.13. Rx Maximum Speed (OCRQ) . . . . . . . . . . . . . 23 82 5.1.3. Proxy LCP and Authentication AVPs . . . . . . . . . . 24 83 5.1.3.1. Initial Received LCP CONFREQ (ICCN) . . . . . . . 24 84 5.1.3.2. Last Sent LCP CONFREQ (ICCN) . . . . . . . . . . . 25 85 5.1.3.3. Last Received LCP CONFREQ (ICCN) . . . . . . . . . 25 86 5.1.3.4. Proxy Authen Type (ICCN) . . . . . . . . . . . . . 26 87 5.1.3.5. Proxy Authen Name (ICCN) . . . . . . . . . . . . . 27 88 5.1.3.6. Proxy Authen Challenge (ICCN) . . . . . . . . . . 27 89 5.1.3.7. Proxy Authen ID (ICCN) . . . . . . . . . . . . . . 28 90 5.1.3.8. Proxy Authen Response (ICCN) . . . . . . . . . . . 28 92 5.1.4. Session Status AVPs . . . . . . . . . . . . . . . . . 29 93 5.1.4.1. PPP Circuit Errors (WEN) . . . . . . . . . . . . . 29 94 5.1.4.2. ACCM (SLI) . . . . . . . . . . . . . . . . . . . . 30 95 5.2. Service Type Independent AVPs . . . . . . . . . . . . . . 30 96 5.2.1. Session Management AVPs . . . . . . . . . . . . . . . 31 97 5.2.1.1. Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, 98 OCCN) . . . . . . . . . . . . . . . . . . . . . . 31 99 5.2.1.2. Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, 100 OCCN, SLI) . . . . . . . . . . . . . . . . . . . . 31 101 5.2.1.3. Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, 102 OCRP, OCCN) . . . . . . . . . . . . . . . . . . . 32 103 5.2.1.4. Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, 104 OCRP, OCCN) . . . . . . . . . . . . . . . . . . . 32 106 6. Data Channel Sequencing . . . . . . . . . . . . . . . . . . . 33 107 6.1. Sequence Numbers . . . . . . . . . . . . . . . . . . . . . 33 108 6.2. Data Channel Sequencing over Specific Media . . . . . . . 34 110 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 112 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 113 8.1. AVP Attributes . . . . . . . . . . . . . . . . . . . . . . 36 114 8.2. Pseudowire Type . . . . . . . . . . . . . . . . . . . . . 36 115 8.3. Result Code AVP Values . . . . . . . . . . . . . . . . . . 37 116 8.4. Bearer Capabilities and Bearer Type . . . . . . . . . . . 37 117 8.5. Framing Capabilities and Framing Type . . . . . . . . . . 37 118 8.6. Proxy Authen Type AVP Values . . . . . . . . . . . . . . . 37 120 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 121 9.1. Proxy PPP Authentication . . . . . . . . . . . . . . . . . 38 123 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 124 10.1. Normative References . . . . . . . . . . . . . . . . . . . 38 125 10.2. Informative References . . . . . . . . . . . . . . . . . . 39 127 Appendix A. Revision History . . . . . . . . . . . . . . . . . . 40 129 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43 130 Intellectual Property and Copyright Statements . . . . . . . . . . 44 132 1. Introduction 134 The Point-to-Point Protocol (PPP) [RFC1661] is a data link layer 135 protocol that provides a standard method for carrying multiprotocol 136 packets across point-to-point links. It is the most commonly used 137 protocol to provide remote access over various access media such as 138 dial-up POTS, ISDN, ADSL, ATM SVC (Switched Virtual Circuit) or PVC 139 (Permanent Virtual Circuit) based access [RFC3301], etc. 141 Typically, a user obtains a Layer 2 (L2) connection to a Network 142 Access Server (NAS) using one of a number of access techniques (e.g., 143 dial-up POTS, ISDN, ADSL, ATM access, etc.), and then runs PPP over 144 that connection. In such a configuration, the L2 termination point 145 and PPP session endpoint reside on the same physical device (i.e., 146 the NAS). 148 Tunneling protocols, such as the Layer Two Tunneling Protocol - 149 Version 3 (L2TPv3) defined in [RFC3931], provide a dynamic mechanism 150 for extending PPP by allowing the L2 and PPP endpoints to reside on 151 different devices that are interconnected by a packet switched 152 network (PSN), for example over IP. This separation allows the 153 actual processing of PPP packets to be divorced from the termination 154 of the L2 circuit. 156 L2TPv3 can also be used as the control protocol and for data 157 encapsulation in the creation of Pseudowires (PWs) to transport PPP 158 frames over an IP or other packet-based network. A PPP Pseudowire 159 (PPPPW) emulates a single PPP link between exactly two endpoints. 161 This document defines the specific mechanisms for the tunneling of 162 PPP using L2TPv3. 164 This is a companion document to be read in conjunction with 165 [RFC3931]. A large part of this document is derived from [RFC2661], 166 which describes the L2TP protocol signaling as well as the 167 encapsulation method to tunnel PPP sessions. This document is a 168 result of the rewriting of [RFC2661] to separate the base L2TP 169 protocol from the PPP tunneling details. 171 1.1. Terminology 173 This document uses terminology defined in Section 1.3 of [RFC3931]. 174 Additional terminology is defined here. 176 Called Number 178 The telephone number dialed by a caller to reach the receiver of 179 the call. 181 Calling Number 183 The telephone number of the caller. 185 CHAP 187 Challenge Handshake Authentication Protocol [RFC1994], a point-to- 188 point cryptographic challenge/response authentication protocol in 189 which the cleartext password is not passed over the line. 191 DSLAM 193 Digital Subscriber Line (DSL) Access Module. A network device 194 used in the deployment of DSL services. This is typically a 195 concentrator of individual DSL lines located in a central office 196 (CO) or local exchange. 198 ISDN 200 Integrated Services Digital Network. 202 Network Access Server (NAS) 204 A device providing local network access to users across a remote 205 access network, such as the PSTN. 207 Packet Switched Network (PSN) 209 A network that uses packet switching technology for data delivery. 210 For L2TPv3, this layer is principally IP. Other examples include 211 MPLS, Frame Relay, and ATM. See also [RFC3985]. 213 POTS 215 Plain Old Telephone Service. 217 Pseudowire (PW) 219 An emulated circuit as it traverses a PSN. See also [RFC3985]. 220 There is one Pseudowire per L2TP Session. 222 PPPPW 224 PPP Pseudowire. 226 1.2. Requirements Language 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in [RFC2119]. 232 1.3. Contributing Authors 234 This document is a result of the combined effort of several 235 individuals. The following are the authors that contributed to this 236 document: 238 Ignacio Goyret 239 Jed Lau 240 Gurdeep Singh Pall 241 Bill Palter 242 Allan Rubens 243 W. Mark Townsley 244 Andrew J. Valencia 245 Madhvi Verma 246 Glen Zorn 247 Carlos Pignataro 249 2. Topology 251 PPP tunneling can be deployed in all of the different tunneling 252 models specified in Section 2 of [RFC3931]. Traditionally, it is 253 most commonly deployed for access applications in the LAC-LNS 254 reference model. The LAC physically terminates the L2 connection and 255 tunnels the PPP packets across a packet-based network (i.e., IP 256 network) to the LNS. The LNS then terminates the logical PPP 257 connection. The L2 service extends between Remote System and LNS, 258 and the emulated service extends between LAC and LNS (see Section 2 259 of [RFC3931]). The session establishment can be driven by the LAC 260 (an incoming call) or the LNS (an outgoing call). 262 In the LNS-LNS reference model, both the emulated service and L2 263 service extend between the two LNS devices. A software package on a 264 host which runs L2TP natively and acts as an LNS is often referred to 265 as a "LAC Client" [RFC2661]. 267 More recently, in the symmetric LAC-LAC reference model, the emulated 268 service extends between LACs while the L2 service extends between 269 remote systems. In the most basic form, the LAC acts as a cross- 270 connect between a PPP interface to a remote system and an L2TP 271 session, and forwards PPP traffic from the remote system to the peer 272 LAC using L2TP and vice versa. This model typically involves 273 symmetric establishment: Either side of the connection may initiate a 274 session at any time, or simultaneously (utilizing the tie breaking 275 mechanism defined in Section 5.4.4. of [RFC3931]). 277 3. Control Channel Specifics for PPP 279 The following sections highlight Control Connection and Session 280 management details in the context of PPP over L2TPv3. This includes 281 AVPs that need special attention for PPP over L2TPv3 or that differ 282 from [RFC2661]. 284 3.1. Control Connection Establishment 286 In order to tunnel PPP over L2TPv3, an L2TPv3 Control Connection MUST 287 first be established as described in Section 3.3 of [RFC3931]. 289 The L2TPv3 SCCRQ Control Message and corresponding SCCRP Control 290 Message MUST include the "PPP Pseudowire Type" of 0x0007 (See 291 Section 8.2), in the Pseudowire Capabilities List AVP, Attribute Type 292 62, as defined in Section 5.4.3 of [RFC3931]. This identifies the 293 Control Connection as being able to establish PPP L2TPv3 sessions. 295 During Control Connection Establishment, LCCEs are identified either 296 by the Host Name AVP, Attribute Type 7, the Router ID AVP, Attribute 297 Type 60, or a combination of the two. See Section 3.3 of [RFC3931] 298 that describes the LCCE identity. 300 The Assigned Control Connection ID defined in Section 5.4.3 of 301 [RFC3931], Attribute Type 61, is the L2TPv3 analogous to the Assigned 302 Tunnel ID in L2TPv2. The Control Connection Tie Breaker AVP defined 303 in Section 5.4.3 of [RFC3931], Attribute Type 5, is used to choose a 304 single Control Connection when two LCCEs request a Control Connection 305 simultaneously. 307 3.2. Session Establishment 309 The following signaling elements are needed for session 310 establishment: 312 The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931], 313 Attribute Type 68, MUST be present in the ICRQ and OCRQ messages and 314 MUST include the PPP PW Type of 0x0007. 316 The Remote End ID AVP, Attribute Type 66, binds the L2TP session to a 317 given PPP circuit, and MUST be present in ICRQ messages in the LAC- 318 LAC cross-connect application (see Section 2(b) of [RFC3931]). In 319 this case, an implementation MUST support a Remote End ID of an 320 unstructured four-octet value that is known to both LCCEs (either by 321 manual configuration of some other means outside of the scope of this 322 document). 324 The Circuit Status AVP, Attribute Type 71, MUST be included in ICRQ, 325 ICRP, OCRQ and OCRP messages. The N (New) bit of the Circuit Status 326 AVP MUST be set to 1 in these messages indicating a new circuit, and 327 the A (Active) bit is set to 0 (INACTIVE) or 1 (ACTIVE) reflecting 328 the operational circuit status underneath PPP. This AVP is further 329 described in the context of PPP over L2TPv3 in Section 5.2.1.2. 331 The Local Session ID AVP, Attribute Type 63, is analogous to the 332 Assigned Session ID in L2TPv2. The Remote Session ID AVP, Attribute 333 Type 64, echoes the value of the Local Session ID AVP received, and 334 MUST be present in all session-level control messages. Additionally, 335 when using the Remote End ID AVP, the Session Tie Breaker AVP, 336 Attribute Type 5, is used to break session-level ties (detected by 337 comparing both the peer's identity as described in Section 3.1 and 338 the value of the Remote End ID AVP). 340 3.3. Session Maintenance 342 When PPP is tunneled through L2TP, a session control message, Set- 343 Link-Info (SLI), is used to send PPP-specific link level information 344 between LCCEs. 346 The SLI is sent by the LNS to the LAC to set any PPP-negotiated 347 options. It is sent after the last LCP CONFACK is received in case 348 of PPP LCP renegotiations, or after the ICCN message with PPP Last 349 CONFREQ AVPs is received when proxy LCP is accepted. This AVP 350 contains any relevant link level parameters of which the LAC may need 351 to be aware (e.g., ACCM info). If there is no relevant information 352 to be sent in the SLI, then the sending of this message MAY be 353 omitted. Since LCP may be renegotiated at any time, an SLI may be 354 sent at any time during the life of the call. For this reason, the 355 LAC MUST be able to update its internal call information and behavior 356 on an active session. Furthermore, if there are packets in queue at 357 the LAC when an SLI is received, these must be flushed before 358 applying the SLI information to the link. 360 If the PPP session at the LNS renegotiates LCP during the call, an 361 SLI MUST be sent to the LAC to return link level information to the 362 initial default values while the negotiation occurs. However, if the 363 last SLI sent was already set to default values or no SLI was sent at 364 all, this step MAY be omitted. 366 The SLI MAY be sent from a LAC to indicate a change in the circuit 367 status underneath PPP. 369 The following AVPs MUST be present in the SLI: 371 Message Type 373 This AVP is described in [RFC3931]. In the SLI, the value of this 374 attribute is 16. 376 The following AVP MAY be present in the SLI: 378 ACCM 380 This AVP is described in Section 5.1.4.2. 382 Circuit Status 384 In SLI messages, the N (New) bit of the Circuit Status AVP MUST be 385 set to 0 indicating that the status is for an existing circuit. 386 This AVP is described in Section 5.2.1.2. 388 4. Data Channel Specifics for PPP 390 This section describes the encapsulation mechanism for forwarding PPP 391 frames over the L2TPv3 data channel. 393 The general format for tunneling PPP frames over L2TPv3 is as 394 follows: 396 0 1 2 3 397 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 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | L2TP Session Header | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Default L2-Specific Sublayer (Optional) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 |Offset Pad (Variable, Optional)| | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 405 | | 406 ~ PPP Frames ~ 407 | | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Figure 1: PPP over L2TPv3 encapsulation 412 The header format for the PPP over L2TPv3 data messages consists of 413 an L2TP Session Header (see Section 4.1 of [RFC3931]) followed by the 414 optional Default L2-specific Sublayer, an optional variable-length 415 Offset Padding and then the Tunnel Payload (PPP Frames). 417 This document decouples the L2-Specific Sublayer intermediary 418 function (see Section 4.1) from the Offset padding function (see 419 Section 4.2), making them independent from each other. Because those 420 two fields perform orthogonal functions, separating them enables 421 their independent request and existence (i.e., only the Offset 422 Padding field can be requested and present when no functions of the 423 L2-Specific Sublayer such as sequencing are needed). It also 424 simplifies moving the request of the Offset Size downstream to the 425 LCCE receiver of the data packet (see Section 4.2 and Offset Size AVP 426 in Section 5.1.2.9), in a similar fashion as requesting the presence 427 and format of the L2-Specific Sublayer (with the L2-Specific Sublayer 428 AVP) or the size and value of the Cookie (with the Assigned Cookie 429 AVP). The Offset Size request is conditioned by the upstream's LCCE 430 capability (see Section 4.2). 432 4.1. L2-Specific Sublayer 434 This section defines the usage and specifics of an L2-Specific 435 Sublayer for PPP over L2TPv3. When an intermediary L2-Specific 436 Sublayer is needed or desired to support features such as sequencing, 437 PPP over L2TPv3 uses the Default L2-Specific Sublayer defined in 438 Section 4.6 of [RFC3931]. 440 The usage of the Default L2-Specific Sublayer is OPTIONAL. However 441 if an L2-Specific Sublayer is requested, it MUST be the Default one. 442 Its presence is requested by a peer during session negotiation using 443 the L2-Specific Sublayer Type AVP, Attribute Type 69, with a value of 444 1. If the AVP is not received, it is assumed that there is no 445 sublayer present. 447 4.2. Offset Padding 449 The optional Offset Padding field MAY be included containing offset 450 padding before the tunneled PPP frame. This field can be used to 451 provide alignment of the data carried in PPP to longword size 452 boundaries for performance reasons, but increases the size of the 453 L2TPv3 packet. The Offset Padding field follows the Default L2- 454 Specific Sublayer if present or the L2TPv3 Session Header otherwise. 455 For a given L2TPv3 Session and direction, all Data Messages have the 456 same Offset Padding Size. 458 During Control Connection establishment, an LCCE advertises the 459 maximum Offset Padding size that it is willing to insert, if 460 requested at Session establishment, for all the associated Sessions 461 within that Control Connection. This capability advertisement is 462 performed using the Offset Capability AVP (see Section 5.1.1.3), and 463 allows the sender of L2TP data messages (i.e., the upstream LCCE) to 464 have control over the offset size. 466 The number of octets past the L2TPv3 Session Header or optional L2- 467 Specific Sublayer if present at which the payload data is expected to 468 start (i.e., the size of the Offset Padding field) is signaled during 469 Session establishment using the Offset Size AVP (see 470 Section 5.1.2.9). When an LCCE agrees to support a requested Offset 471 Size during session establishment, it MUST send all data packets 472 including an Offset Padding of that agreed size. The size of the 473 Offset Padding field MAY be different in both directions of the 474 session. An Offset Size of zero signaled during session 475 establishment indicates no offset. The maximum offset value that may 476 be requested by a peer during session negotiation is limited by the 477 offset capability value advertised during control connection 478 establishment. An offset capability of zero advertised during 479 control connection establishment indicates that no offset padding can 480 be requested on sessions within the control connection. 482 Actual data within the Offset Padding field is undefined, and MUST be 483 ignored on receipt. 485 4.3. Forwarding PPP Frames 487 PPP tunneling via L2TPv3 utilizes both the Control Connection for 488 session management and the base L2TPv3 encapsulation for 489 demultiplexing to tunnel the PPP frames. Both of these mechanisms 490 are defined in [RFC3931]. 492 After L2TP control channel establishment (see [RFC3931], and 493 Section 3.1 and Section 3.2 of this document for details on Control 494 Connection and Session establishment), PPP frames are tunneled. 496 The PPP frames from the remote system are received at the LAC, 497 stripped of CRC, link framing, and transparency bytes, encapsulated 498 with the L2TPv3 data header (see [RFC3931]) followed by the optional 499 Default L2-Specific Sublayer (see Section 4.1) and optional Offset 500 Padding (see Section 4.2) fields, and forwarded over the session. 501 When using PPP in HDLC framing (See [RFC1662]) the PPP frame is 502 stripped of HDLC header (HDLC Address and Control Fields or ACF), 503 flags and trailing FCS. The remaining data, including the protocol 504 field, is transported over the L2TPv3 session. The LNS then receives 505 the L2TPv3 packet and processes the encapsulated PPP frame as if it 506 were received on a local PPP interface. The LNS receives the PPP 507 frame over the L2TP session without the HDLC Address and Control 508 Fields. All framing operations (e.g., CRC, character escaping, etc.) 509 are handled by the LAC. If the LNS wishes to support Address-and- 510 Control-Field-Compression (ACFC) [RFC1661], it MUST support the "LCP 511 Options From LNS to LAC" extensions defined in Section 2.3 of 512 [RFC3437]. The LAC needs to learn the negotiated ACFC settings to 513 know whether the ACF needs to be re-inserted on output towards the 514 remote system. 516 When encapsulating the PPP frame in L2TPv3, both the LAC and the LNS 517 MUST always include the PPP Protocol ID field along with the PPP 518 frame. They SHOULD NOT include the HDLC Address and Control Fields 519 (ACF). An LCCE SHOULD strip off the ACF before encapsulating the PPP 520 frames in L2TP and forwarding them over the PPPPW session. The 521 reception and transmission of the HDLC header on a PPP Attachment 522 Circuit (AC) is media specific. If the LAC is providing L2TPv3 523 transport for a PPP AC that requires HDLC Address and Control Fields, 524 then this information SHOULD be stripped before transmitting the 525 packet into the L2TPv3 session. Similarly, for a PPP AC that 526 requires the HDLC header, the LAC MUST check the presence of the ACF 527 and, if ACF is not present, prepend it to packets received from the 528 L2TPv3 session before transmitting them out of the AC. While the 529 sender SHOULD omit and not send the HDLC Address and Control Fields, 530 a receiver MUST allow the HDLC Address and Control Fields to be 531 present in a received packet, for robustness reasons. 533 It is worth noting that if an implementation wishes to receive the 534 space equivalent to the HDLC Address and Control Fields in the 535 tunneled PPP frame, it can request a two-octet offset padding with 536 the Offset Size AVP if it received the Offset Capability of at least 537 two from the peer during control connection establishment. 539 5. AVP Description 541 The base L2TPv3 specification [RFC3931] describes the use of service 542 type specific Attribute Value Pairs (AVPs). These AVPs are specific 543 to the L2 payload carried by the L2TPv3 sessions. This section 544 provides a description of all PPP-specific AVPs. It also provides 545 additional PPP-specific information about certain other service- 546 independent AVPs when PPP is tunneled by L2TPv3. 548 Following the name of each AVP is a list indicating the message types 549 that utilize each AVP. These message types are described in the base 550 L2TPv3 specification [RFC3931]. After each AVP title follows a short 551 description of the purpose of the AVP, a detail (including a graphic) 552 of the format for the Attribute Value, and any additional information 553 needed for proper use of the AVP. 555 5.1. PPP-Specific AVPs 556 5.1.1. Control Connection Management AVPs 558 The AVPs described in this section are included in the Control 559 Connection messages. 561 5.1.1.1. Framing Capabilities (SCCRP, SCCRQ) 563 The Framing Capabilities AVP, Attribute Type 3, provides the peer 564 with an indication of the types of PPP framing that will be supported 565 for outgoing call requests. 567 The Attribute Value field for this AVP has the following format: 569 0 1 2 3 570 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 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Reserved for future framing type definitions |A|S| 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 The Attribute Value field is a 32-bit mask, with two bits defined. 576 If bit A is set, asynchronous framing is supported. If bit S is set, 577 synchronous framing is supported. 579 The framing capabilities defined in this AVP refer only to the 580 physical interfaces available for dialout usage on an LAC. An LNS 581 MUST NOT send an OCRQ with a Framing Type AVP specifying a value not 582 advertised in this AVP. Presence of this message is not a guarantee 583 that a given outgoing call will be placed by the sender if requested, 584 just that the physical capability exists. 586 It is RECOMMENDED that an implementation includes all the Framing 587 Capabilities that its software module supports rather than conveying 588 its physical interface capabilities at the time of Control Connection 589 establishment. This way, a shut down and re-establishment of the 590 Control Connection is prevented if new physical interface 591 capabilities are added to the LCCE. This step pushes the capability 592 check to the Session establishment phase. The same recommendation 593 applies to the Bearer Capabilities. 595 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 596 AVP MUST be set to 1. The Length (before hiding) is 10. 598 5.1.1.2. Bearer Capabilities (SCCRP, SCCRQ) 600 The Bearer Capabilities AVP, Attribute Type 4, provides the peer with 601 an indication of the bearer device types supported by the hardware 602 interfaces of the sender for outgoing calls. 604 The Attribute Value field for this AVP has the following format: 606 0 1 2 3 607 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 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Reserved for future bearer type definitions |V|B|A|D| 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 This is a 32-bit mask, with four bits defined. If bit A is set, 613 analog access is supported. If bit D is set, digital access is 614 supported. If bit B is set, broadband access is supported (ATM). If 615 bit V is set, virtual access is supported. (Virtual access refers to 616 access in which there is no physical point-to-point link.) 618 The bearer capabilities defined in this AVP refer only to the 619 physical interfaces available for dialout usage on an LAC. An LNS 620 MUST NOT send an OCRQ with a Bearer Type AVP specifying a value not 621 advertised in this AVP. 623 This AVP MUST be present if the sender can place outgoing calls when 624 requested. Presence of this message is not a guarantee that a given 625 outgoing call will be placed by the sender if requested, just that 626 the physical capability exists. 628 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 629 AVP MUST be set to 1. The Length (before hiding) is 10. 631 5.1.1.3. Offset Capability (SCCRP, SCCRQ) 633 The Offset Capability AVP, Attribute Type AVP-TBD-1, indicates the 634 size in octets of the Offset Padding field the sender of this AVP is 635 willing and capable to insert, if requested at Session establishment. 636 The Offset Capability AVP sets the maximum value that an LCCE peer 637 can request in the Offset Size AVP for a session within this control 638 connection (see Section 4.2), allowing the sender of L2TP data 639 messages (i.e., the upstream LCCE) to have control over the offset 640 size. 642 The Attribute Value field for this AVP has the following format: 644 0 1 645 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | Offset Capability | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 The Offset Capability is a 2-octet unsigned integer. If absent, the 651 peer MUST assume a value of zero, which implies that the peer MUST 652 NOT request Offset Padding (i.e., MUST NOT send the Offset Size AVP 653 for sessions within this control connection). 655 A missing Offset Capability AVP or an Offset Capability AVP with a 656 value of zero indicates that the Offset Size AVP cannot be sent by 657 the peer LCCE. If this AVP is received and has a value other than 658 zero, the receiving LCCE can request an Offset Padding using the 659 Offset Size AVP up to the value indicated in this AVP. 661 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 662 AVP MUST be set to 1. The Length (before hiding) of this AVP is 8. 664 5.1.2. Session Management AVPs 666 This section describes Session (i.e., Call) Management AVPs. 668 5.1.2.1. Bearer Type (ICRQ, OCRQ) 670 The Bearer Type AVP, Attribute Type 18, encodes the bearer type for 671 the incoming or outgoing call. 673 The Attribute Value field for this AVP has the following format: 675 0 1 2 3 676 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 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Reserved for future Bearer Types |V|B|A|D| 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 The Bearer Type is a 32-bit bit mask indicating the bearer capability 682 of the call (ICRQ) or required for the call (OCRQ). Bit A refers to 683 an analog channel. Bit D refers to a digital channel. Bit B refers 684 to broadband access. Bit V (virtual) refers to a channel for which 685 there is no physical point-to-point link. 687 Bits set in the Bearer Type AVP in an OCRQ message indicate the 688 bearer type(s) on which an outgoing call may be placed. If more than 689 one bit is set, the LAC may choose the bearer type with which to 690 place the call. If no bits are set, any type of available channel 691 may be used. 693 Bits in the Value field of this AVP MUST only be set by the LNS for 694 an OCRQ if the same bit was set in the Bearer Capabilities AVP 695 received from the LAC during Control Connection establishment. 697 Bits set in the Bearer Type AVP in an ICRQ message indicate the 698 bearer type on which an incoming call was received at the LAC. If no 699 bits are set in an ICRQ, then it is assumed that the bearer type was 700 indeterminable. 702 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 703 AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. 705 5.1.2.2. Framing Type (ICCN, OCCN, OCRQ) 707 The Framing Type AVP, Attribute Type 19, encodes the framing type for 708 the incoming or outgoing call. 710 The Attribute Value field for this AVP has the following format: 712 0 1 2 3 713 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 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Reserved for future Framing Types |A|S| 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 The Framing Type is a 32-bit mask, which indicates the type of PPP 719 framing requested for an OCRQ, or the type of PPP framing negotiated 720 for an OCCN or ICCN. 722 Bit A indicates asynchronous framing. Bit S indicates synchronous 723 framing. For an OCRQ, both may be set, indicating that the LAC may 724 decide the type of framing to be used. 726 For an ICCN, only one framing type bit may be set. The framing type 727 SHOULD be used as an indication to PPP on the LNS as to what link 728 options to use for LCP negotiation [RFC1662]. For example, if the A 729 bit is not set in the Framing Type AVP in an ICCN message and an ACCM 730 LCP option is requested by the PPP client, then the LNS should try to 731 respond with no bits set in the ACCM mask, since the LAC will not 732 likely perform async mapping on a non-async interface. 734 Bits in the Value field of this AVP MUST only be set by the LNS for 735 an OCRQ if it was set in the Framing Capabilities AVP received from 736 the LAC during Control Connection establishment. 738 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 739 AVP MUST be set to 1. The Length (before hiding) of this AVP is 10. 741 5.1.2.3. Called Number (ICRQ, OCRQ) 743 The Called Number AVP, Attribute Type 21, encodes the telephone 744 number to be called for an OCRQ, and the called number for an ICRQ. 746 The Attribute Value field for this AVP has the following format: 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Called Number... (arbitrary number of octets) 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 The Called Number is an ASCII string. Contact between the 755 administrator of the LAC and the LNS may be necessary to coordinate 756 interpretation of the value needed in this AVP. Additionally, other 757 Called Number encodings MAY be defined to be interpreted in the 758 context of the Bearer Type in use for the specific call. An example 759 of alternate encoding is defined in [RFC3301]. Newly defined 760 alternate encodings qualified by the Bearer Type SHOULD use ASCII 761 encoding of the value, although the value of this AVP is binary 762 encoded when the B bit is set in the Bearer Type AVP [RFC3301]. 764 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 765 AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 766 plus the length of the Called Number. 768 5.1.2.4. Calling Number (ICRQ) 770 The Calling Number AVP, Attribute Type 22, encodes the originating 771 number for the incoming call. 773 The Attribute Value field for this AVP has the following format: 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Calling Number... (arbitrary number of octets) 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 The Calling Number is an ASCII string. Contact between the 782 administrator of the LAC and the LNS may be necessary to coordinate 783 interpretation of the value in this AVP. Additionally, other Calling 784 Number encodings MAY be defined to be interpreted in the context of 785 the Bearer Type in use for the specific call. An example of 786 alternate encoding is defined in [RFC3301]. Newly defined alternate 787 encodings qualified by the Bearer Type SHOULD use ASCII encoding of 788 the value, although the value of this AVP is binary encoded when the 789 B bit is set in the Bearer Type AVP [RFC3301]. 791 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 792 AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 793 plus the length of the Calling Number. 795 5.1.2.5. Called Sub-Address (ICRQ, OCRQ) 797 The Called Sub-Address AVP, Attribute Type 23, encodes additional 798 called party dialing information. For instance, it can be used by 799 the LNS to encode the ISDN sub-address information for an outgoing 800 call request. 802 The Attribute Value field for this AVP has the following format: 804 0 1 2 3 805 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 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | Called Sub-Address ... (arbitrary number of octets) 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 The Called Sub-Address is an ASCII string. Contact between the 811 administrator of the LAC and the LNS may be necessary to coordinate 812 interpretation of the value in this AVP. Additionally, other Called 813 Sub-Address encodings MAY be defined to be interpreted in the context 814 of the Bearer Type in use for the specific call. An example of 815 alternate encoding is defined in [RFC3301]. Newly defined alternate 816 encodings qualified by the Bearer Type SHOULD use ASCII encoding of 817 the value, although the value of this AVP is binary encoded when the 818 B bit is set in the Bearer Type AVP [RFC3301]. 820 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 821 AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 822 plus the length of the Called Sub-Address. 824 5.1.2.6. Calling Sub-Address (ICRQ) 826 The Calling Sub-Address AVP, Attribute Type 44, encodes additional 827 calling party information. For instance, it can be used by the LAC 828 to encode the ISDN sub-address information for an incoming call 829 request. 831 The Attribute Value field for this AVP has the following format: 833 0 1 2 3 834 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 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Calling Sub-Address ... (arbitrary number of octets) 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 The Calling Sub-Address is an ASCII string. Contact between the 840 administrator of the LAC and the LNS may be necessary to coordinate 841 interpretation of the value in this AVP. Additionally, other Calling 842 Sub-Address encodings MAY be defined to be interpreted in the context 843 of the Bearer Type in use for the specific call. An example of 844 alternate encoding is defined in [RFC3301]. Newly defined alternate 845 encodings qualified by the Bearer Type SHOULD use ASCII encoding of 846 the value, although the value of this AVP is binary encoded when the 847 B bit is set in the Bearer Type AVP [RFC3301]. 849 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 850 AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 851 plus the length of the Calling Sub-Address. 853 5.1.2.7. Q.931 Cause Code (CDN) 855 The Q.931 Cause Code AVP, Attribute Type 12, is used to give 856 additional information in case of unsolicited call disconnection. 858 The Attribute Value field for this AVP has the following format: 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Cause Code | Cause Msg | Advisory Msg... 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 The Cause Code field is the returned Q.931 cause code, and the Cause 867 Msg field is the returned Q.931 message code (e.g., DISCONNECT) 868 associated with the cause code. Both values are returned in their 869 native ITU encodings [ITU.Q931.1998]. Additionally, the Cause Code 870 field can carry Cause Codes specific to ATM signaling messages as 871 described in [RFC3301]. The Cause code should be interpreted 872 relative to the Bearer Type in use for the specific call. An 873 additional ASCII text Advisory Message may also be included (presence 874 indicated by the AVP Length) to further explain the reason for 875 disconnecting. 877 This AVP MUST NOT be hidden (the H bit MUST be 0). The M bit for 878 this AVP MUST be set to 1. The Length of this AVP is 9, plus the 879 size of the Advisory Message. 881 5.1.2.8. Private Group ID (ICCN) 883 The Private Group ID AVP, Attribute Type 37, is used by the LAC to 884 indicate that this call is to be associated with a particular 885 customer group. 887 The Attribute Value field for this AVP has the following format: 889 0 1 2 3 890 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 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Private Group ID ... (arbitrary number of octets) 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 895 The Private Group ID is a string of octets of arbitrary length. 897 The LNS MAY treat the PPP session as well as network traffic through 898 this session in a special manner determined by the peer. For 899 example, if the LNS is individually connected to several private 900 networks using unregistered addresses, this AVP may be included by 901 the LAC to indicate that a given call should be associated with one 902 of the private networks. 904 The Private Group ID is an ASCII string. Contact between the 905 administrator of the LAC and the LNS may be necessary to coordinate 906 interpretation of the value of this AVP. 908 The LNS MAY treat the PPP session as well as network traffic through 909 this session in a special manner determined by the Private Group ID 910 value. The Private Group ID defines the particular characteristics 911 of the selected group. For example, the LNS could interpret this AVP 912 to route traffic from this session to a particular interface or 913 private network. 915 A LAC MAY determine the Private Group ID from an AAA (Authentication, 916 Authorization and Accounting) protocol response response, local 917 configuration, or some other source. 919 This AVP may be hidden (the H-bit MAY be 1 or 0). The M-bit for this 920 AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 921 plus the length of the Private Group ID. 923 5.1.2.9. Offset Size (ICRQ, ICRP, ORCQ, OCRP) 925 The Offset Size AVP, Attribute Type AVP-TBD-2, indicates the size in 926 octets of the Offset Padding field the sender of this AVP requires on 927 all incoming data packets for this L2TP session. It allows an LCCE 928 to request the peer includes an Offset Padding in all data messages 929 (see Section 4.2), and is conditioned to the value received in the 930 Offset Capability AVP. 932 The Attribute Value field for this AVP has the following format: 934 0 1 935 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 | Offset Size | 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 The Offset Size is a 2-octet unsigned integer. The maximum value for 941 the Offset Size is the value that the peer LCCE advertised in the 942 Offset Capability AVP during control connection establishment. If 943 this AVP is absent, the peer MUST assume a value of zero. 945 A missing Offset Size AVP or an Offset Size AVP with a value of zero 946 indicates that the Offset Padding field should not be present in any 947 data packets sent to the LCCE sending this AVP. If this AVP is 948 received and has a value other than zero (and less than or equal to 949 the received Offset Capability AVP for the control connection), the 950 receiving LCCE MUST include an Offset Padding of the requested size 951 in its outgoing data messages. 953 If the LCCE receiving this AVP has not advertised an Offset 954 Capability AVP, if the requested size is greater than the value 955 advertised in the Offset Capability AVP, or if the LCCE receiving 956 this AVP is not capable, configured or willing to include an Offset 957 Padding field of the requested size, the LCCE MUST reject the session 958 via a CDN message with the following General Result Code: 960 RC-TBD1: Session not established due to unsupported Offset Size 962 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 963 AVP MUST be set to 1. The Length (before hiding) of this AVP is 8. 965 5.1.2.10. Tx Minimum Speed (OCRQ) 967 The Tx Minimum Speed AVP, Attribute Type AVP-TBD-3, encodes the 968 lowest acceptable line speed for this call over a dial-up or ATM 969 access network. This is the lowest acceptable line speed in the 970 transmit direction (i.e. the direction from the LAC to the user). 972 The Attribute Value field for this AVP has the following format: 974 0 1 2 3 975 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 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Tx Minimum Speed in bps... 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 ...Tx Minimum Speed in bps (64 bits) | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 The Tx Minimum Speed BPS is an 8-octet value indicating the speed in 983 bits per second. This speed is the minimum line speed (for example, 984 modem connect speed) in the transmit direction. When the optional Rx 985 Minimum Speed AVP is NOT present, then symmetric transmission is 986 implied, with both minimum receive and transmit bit-rates equal to 987 the Tx Minimum Speed BPS. 989 The Minimum BPS AVP, Attribute Type 16, MUST NOT be used in PPP over 990 L2TPv3 signaling. 992 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 993 AVP MUST be set to 1. The Length (before hiding) of this AVP is 14. 995 5.1.2.11. Tx Maximum Speed (OCRQ) 997 The Tx Maximum Speed AVP, Attribute Type AVP-TBD-4, encodes the 998 highest acceptable line speed for this call in the transmit direction 999 (i.e. from LAC to the user). 1001 The Attribute Value field for this AVP has the following format: 1003 0 1 2 3 1004 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 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Tx Maximum Speed in bps... 1007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1008 ...Tx Maximum Speed in bps (64 bits) | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 The Tx Maximum Speed BPS is an 8-octet value indicating the speed in 1012 bits per second. This speed is the maximum line speed (for example, 1013 modem connect speed) in the transmit direction. When the optional Rx 1014 Maximum Speed AVP is NOT present, then symmetric transmission is 1015 implied, with both maximum receive and transmit bit-rates equal to 1016 the Tx Maximum Speed BPS. 1018 The Maximum BPS AVP, Attribute Type 17, MUST NOT be used in PPP over 1019 L2TPv3 signaling. 1021 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1022 AVP MUST be set to 1. The Length (before hiding) of this AVP is 14. 1024 5.1.2.12. Rx Minimum Speed (OCRQ) 1026 The Rx Minimum Speed AVP, Attribute Type AVP-TBD-5, encodes the 1027 lowest acceptable line speed for this call in the receive direction 1028 (i.e., data flowing from the remote system to the LAC), for cases 1029 where asymmetric transmission may be required. 1031 The Attribute Value field for this AVP has the following format: 1033 0 1 2 3 1034 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 1035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1036 | Rx Minimum Speed in bps... 1037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1038 ...Rx Minimum Speed in bps (64 bits) | 1039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1041 The Rx Minimum Speed BPS is an 8-octet value indicating the speed in 1042 bits per second. This speed is the minimum line speed (for example, 1043 modem connect speed) in the receive direction. Presence of this AVP 1044 implies that the connection speed may be asymmetric with respect to 1045 the Tx Minimum Speed BPS. 1047 The Rx Minimum BPS AVP, Attribute Type 40, MUST NOT be used in PPP 1048 over L2TPv3 signaling. 1050 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1051 AVP MUST be set to 0. The Length (before hiding) of this AVP is 14. 1053 5.1.2.13. Rx Maximum Speed (OCRQ) 1055 The Rx Maximum Speed AVP, Attribute Type AVP-TBD-6, encodes the 1056 highest acceptable line speed for this call in the receive direction 1057 (i.e., data flowing from the remote system to the LAC), for cases 1058 where asymmetric transmission may be required. 1060 The Attribute Value field for this AVP has the following format: 1062 0 1 2 3 1063 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 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | Rx Maximum Speed in bps... 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 ...Rx Maximum Speed in bps (64 bits) | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 The Rx Maximum Speed BPS is an 8-octet value indicating the speed in 1071 bits per second. This speed is the maximum line speed (for example, 1072 modem connect speed) in the receive direction. Presence of this AVP 1073 implies that the connection speed may be asymmetric with respect to 1074 the Tx Maximum Speed BPS. 1076 The Rx Maximum BPS AVP, Attribute Type 41, MUST NOT be used in PPP 1077 over L2TPv3 signaling. 1079 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1080 AVP MUST be set to 0. The Length (before hiding) of this AVP is 14. 1082 5.1.3. Proxy LCP and Authentication AVPs 1084 The LAC may have answered the call and negotiated LCP with the remote 1085 system, perhaps in order to establish the system's apparent identity. 1086 In this case, these AVPs may be included to indicate, first, the link 1087 properties the remote system initially requested, and second, the 1088 properties the remote system and LAC ultimately negotiated. In 1089 addition, the authentication information can be sent by the LAC by 1090 including the proxy authentication AVPs. This information may be 1091 used to initiate the PPP LCP and authentication states on the LNS, 1092 allowing PPP to continue without renegotiation of LCP. Note that the 1093 LNS policy may be to enter an additional round of LCP negotiation 1094 and/or authentication if the LAC is not trusted. 1096 5.1.3.1. Initial Received LCP CONFREQ (ICCN) 1098 In the Initial Received LCP CONFREQ AVP, Attribute Type 26, the LAC 1099 provides the LNS with the Initial CONFREQ received by the LAC from 1100 the PPP Peer. 1102 The Attribute Value field for this AVP has the following format: 1104 0 1 2 3 1105 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 1106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1107 | LCP CONFREQ... (arbitrary number of octets) 1108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 The LCP CONFREQ is a copy of the body of the initial CONFREQ 1111 received, starting at the first option within the body of the LCP 1112 message. 1114 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1115 AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 1116 plus the length of the CONFREQ. 1118 5.1.3.2. Last Sent LCP CONFREQ (ICCN) 1120 The Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the LNS 1121 with the Last CONFREQ sent by the LAC to the PPP Peer. 1123 The Attribute Value field for this AVP has the following format: 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | LCP CONFREQ... (arbitrary number of octets) 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 The LCP CONFREQ is a copy of the body of the final CONFREQ sent to 1132 the client to complete LCP negotiation, starting at the first option 1133 within the body of the LCP message. 1135 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1136 AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 1137 plus the length of the CONFREQ. 1139 5.1.3.3. Last Received LCP CONFREQ (ICCN) 1141 The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the 1142 LNS with the Last CONFREQ received by the LAC from the PPP Peer. 1144 The Attribute Value field for this AVP has the following format: 1146 0 1 2 3 1147 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 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | LCP CONFREQ... (arbitrary number of octets) 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 The LCP CONFREQ is a copy of the body of the final CONFREQ received 1153 from the client to complete LCP negotiation, starting at the first 1154 option within the body of the LCP message. 1156 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1157 AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 1158 plus the length of the CONFREQ. 1160 5.1.3.4. Proxy Authen Type (ICCN) 1162 The Proxy Authen Type AVP, Attribute Type 29, indicates the type of 1163 authentication that was performed for this call by the LAC, if any. 1165 The Attribute Value field for this AVP has the following format: 1167 0 1 1168 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Authen Type | 1171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 Authen Type is a 2-octet unsigned integer. 1175 Defined Authen Type values are maintained by IANA. Currently defined 1176 values, which are referenced in upcoming AVP definitions, are: 1178 0 - Reserved 1180 1 - Textual username/password exchange 1182 2 - PPP CHAP 1184 3 - PPP PAP 1186 4 - No authentication 1188 5 - Microsoft CHAP Version 1 (MSCHAPv1) 1190 This AVP MUST be present if proxy authentication is to be utilized. 1191 If it is not present, then it is assumed that this peer cannot 1192 perform proxy authentication. In this case, a restart of the 1193 authentication phase at the LNS is required if the client has already 1194 entered this phase with the LAC (which may be determined by the 1195 presence of the Proxy LCP AVP). 1197 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1198 AVP MUST be set to 0. The Length (before hiding) of this AVP is 8. 1200 Associated AVPs for each type of authentication follow. 1202 5.1.3.5. Proxy Authen Name (ICCN) 1204 The Proxy Authen Name AVP, Attribute Type 30, specifies the name of 1205 the authenticating client when using proxy authentication. 1207 The Attribute Value field for this AVP has the following format: 1209 0 1 2 3 1210 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 1211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1212 | Authen Name... (arbitrary number of octets) 1213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 Authen Name is a string of octets of arbitrary length. It contains 1216 the name specified in the client's authentication response. 1218 This AVP MUST be present in messages containing a Proxy Authen Type 1219 AVP with an Authen Type of 1, 2, 3 or 5. It may be desirable to 1220 employ AVP hiding for obscuring the cleartext name. 1222 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1223 AVP MUST be set to 0. The Length (before hiding) is 6 plus the 1224 length of the cleartext name. 1226 5.1.3.6. Proxy Authen Challenge (ICCN) 1228 The Proxy Authen Challenge AVP, Attribute Type 31, specifies the 1229 challenge sent by the LAC to the PPP Peer when using proxy 1230 authentication. 1232 The Attribute Value field for this AVP has the following format: 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Challenge... (arbitrary number of octets) 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 The Challenge is a string of one or more octets. 1242 This AVP MUST be present for Proxy Authen Types 2 and 5. The 1243 Challenge field contains the CHAP challenge presented to the client 1244 by the LAC. 1246 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1247 AVP MUST be set to 0. The Length (before hiding) of this AVP is 6, 1248 plus the length of the Challenge. 1250 5.1.3.7. Proxy Authen ID (ICCN) 1252 The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value of 1253 the PPP Authentication that was started between the LAC and the PPP 1254 Peer when proxy authentication is being used. 1256 The Attribute Value field for this AVP has the following format: 1258 0 1 1259 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1261 | Reserved | ID | 1262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 ID is a 2-octet unsigned integer. The most significant octet MUST be 1265 0. 1267 The Proxy Authen ID AVP MUST be present for Proxy Authen Types 2, 3 1268 and 5. For 2 and 5, the ID field contains the byte ID value 1269 presented to the client by the LAC in its Challenge. For 3, it is 1270 the Identifier value of the Authenticate-Request. 1272 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1273 AVP MUST be set to 0. The Length (before hiding) of this AVP is 8. 1275 5.1.3.8. Proxy Authen Response (ICCN) 1277 The Proxy Authen Response AVP, Attribute Type 33, specifies the PPP 1278 Authentication response received by the LAC from the PPP Peer, when 1279 proxy authentication is used. 1281 The Attribute Value field for this AVP has the following format: 1283 0 1 2 3 1284 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 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Response... (arbitrary number of octets) 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 The Response is a string of octets. 1291 This AVP MUST be present for Proxy Authen Types 1, 2, 3 and 5. The 1292 Response field contains the client's response to the challenge. For 1293 Proxy Authen Types 2 and 5, this field contains the response value 1294 received by the LAC. For 1 and 3, it contains the cleartext password 1295 received from the client by the LAC. In the case of cleartext 1296 passwords, AVP hiding is recommended. 1298 This AVP may be hidden (the H bit may be 0 or 1). The M bit for this 1299 AVP MUST be set to 0. The Length (before hiding) of this AVP is 6 1300 plus the length of the Response. 1302 5.1.4. Session Status AVPs 1304 5.1.4.1. PPP Circuit Errors (WEN) 1306 The PPP Circuit Errors AVP, Attribute Type AVP-TBD-7, conveys PPP 1307 specific circuit error information to the peer, and complements the 1308 Circuit Errors AVP, Attribute Type 34. 1310 The Attribute Value field for this AVP has the following format: 1312 0 1 2 3 1313 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 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Reserved | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 | CRC Errors | 1318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 | Framing Errors | 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 The following fields are defined: 1324 Reserved: 1325 Two octets of Reserved data is present (providing longword 1326 alignment within the AVP of the following values). Reserved data 1327 MUST be zero on sending and ignored upon receipt. 1329 CRC Errors: 1330 Number of PPP frames received with CRC errors since the session 1331 was established. 1333 Framing Errors: 1334 Number of improperly framed PPP packets received. 1336 This AVP may be hidden (the H bit MAY be 1 or 0). The M bit for this 1337 AVP SHOULD be set to 0. The Length of (before hiding) this AVP is 1338 16. 1340 5.1.4.2. ACCM (SLI) 1342 The ACCM AVP, Attribute Type 35, is used by the LNS to inform the LAC 1343 of the ACCM negotiated with the PPP Peer by the LNS. 1345 The Attribute Value field for this AVP has the following format: 1347 0 1 2 3 1348 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 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Reserved | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | Send ACCM | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | Receive ACCM | 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 The Send ACCM and Receive ACCM fields are 4-octet values preceded by 1358 a 2-octet reserved quantity. The Reserved field provides longword 1359 alignment within the AVP of the Send and Receive ACCM values, and 1360 MUST be zero on sending and ignored upon receipt. The Send ACCM 1361 value should be used by the LAC to process packets it sends on the 1362 connection. The Receive ACCM value should be used by the LAC to 1363 process incoming packets on the connection. The default values used 1364 by the LAC for both these fields are 0xFFFFFFFF. The LAC should 1365 honor these fields unless it has specific configuration information 1366 to indicate that the requested mask must be modified to permit 1367 operation. 1369 This AVP may be hidden (the H bit MAY be 1 or 0). The M bit for this 1370 AVP MUST be set to 1. The Length of this AVP is 16. 1372 5.2. Service Type Independent AVPs 1374 The base L2TPv3 specification [RFC3931] gives a detailed description 1375 of these AVPs. However, the AVP values described in [RFC3931] should 1376 be interpreted differently for different service type payloads 1377 carried by L2TPv3. This section describes the AVP values in the 1378 context of the PPP Pseudowire Type. This section should be read in 1379 conjunction with the relevant sections from [RFC3931]. 1381 5.2.1. Session Management AVPs 1383 This section describes Session (i.e., Call) Management service type 1384 independent AVPs. 1386 5.2.1.1. Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 1388 The Data Sequencing AVP, Attribute Type 70, indicates that the sender 1389 requires some or all of the data packets that it receives to be 1390 sequenced. 1392 The Data Sequencing AVP contains a 2-octet unsigned integer value, 1393 Data Sequencing Level, that indicates the degree of incoming data 1394 traffic that the sender of this AVP wishes to be marked with sequence 1395 numbers. 1397 For PPP over L2TPv3 session establishment, Data sequencing may only 1398 be requested when the Default L2-Specific Sublayer is present to 1399 provide sequence numbers. If sequencing is requested without 1400 requesting the Default L2-Specific Sublayer in the L2-Specific 1401 Sublayer AVP, the session MUST be disconnected with a Result Code of 1402 15 (see Section 5.4.2) of [RFC3931]. 1404 The Data Sequencing AVP is defined in Section 5.4.4 of [RFC3931]. 1405 The Sequencing Required AVP, Attribute Type 39, MUST NOT be used in 1406 PPP over L2TPv3 signaling. 1408 5.2.1.2. Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI) 1410 The Circuit Status AVP, Attribute Type 71, indicates the initial 1411 status of or a status change in the call to which the session is 1412 bound. 1414 The Circuit Status AVP contains a 2-octet bitmask with two bits 1415 currently defined: The A (Active) bit and the N (New) bit. 1417 For PPP over L2TPv3 session establishment, this AVP MUST be included 1418 in ICRQ, ICRP, OCRQ and OCRP messages, and MAY be included in ICCN, 1419 OCCN and SLI messages. In ICRQ, ICRP, OCRQ and OCRP messages, the N 1420 (New) bit MUST be set to 1 to indicate a new circuit. 1422 In SLI messages, the Circuit Status AVP MAY be sent to advertise a 1423 change to Inactive to indicate that the call is down without tearing 1424 down the entire session. In this case, all data traffic for that 1425 session MUST cease (or not begin) in the direction towards the sender 1426 of the Circuit Status AVP and data traffic from the sender of the SLI 1427 message with Inactive Circuit Status MUST be ignored. If the 1428 receiver of the SLI message with the Inactive indication is unable to 1429 stop data traffic, it MUST tear down the session with a CDN message. 1430 When the call comes back up, a new SLI message is used to re- 1431 advertise the subsequent Active state, the LNS MUST renegotiate PPP, 1432 and data traffic MUST continue (or start) upon successful 1433 renegotiation. 1435 If a session is started with an initial status of Inactive, the 1436 Circuit Status AVP MUST be sent in an SLI when the circuit becomes 1437 Active. 1439 The Circuit Status AVP is defined in Section 5.4.5 of [RFC3931]. 1441 5.2.1.3. Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 1443 The Tx Connect Speed AVP, Attribute Type 74, contains the speed of 1444 the facility chosen for the connection attempt. 1446 The Tx Connect Speed AVP contains an 8-octet value, Tx Connect Speed 1447 BPS, that indicates the speed in bits per second. A value of zero 1448 indicates that the speed is indeterminable or that there is no 1449 physical point-to-point link. 1451 When the optional Rx Connect Speed AVP is present, the value in this 1452 AVP represents the transmit connect speed from the perspective of the 1453 LAC (i.e., data flowing from the LAC to the remote system). When the 1454 optional Rx Connect Speed AVP is NOT present, the connection speed 1455 between the remote system and LAC is assumed to be symmetric and is 1456 represented by the single value in this AVP. 1458 The Tx Connect Speed AVP is defined in Section 5.4.4 of [RFC3931]. 1459 The (Tx) Connect Speed BPS AVP, Attribute Type 24, MUST NOT be used 1460 in PPP over L2TPv3 signaling. 1462 5.2.1.4. Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN) 1464 The Rx Connect Speed AVP, Attribute Type 75, represents the receive 1465 connect speed of the connection from the perspective of the LAC 1466 (i.e., data flowing from the remote system to the LAC). 1468 The Rx Connect Speed AVP contains an 8-octet value, Rx Connect Speed 1469 BPS, that indicates the speed in bits per second. A value of zero 1470 indicates that the speed is indeterminable or that there is no 1471 physical point-to-point link. 1473 Presence of this AVP implies that the connection speed may be 1474 asymmetric with respect to the transmit connect speed given in the Tx 1475 Connect Speed AVP. 1477 The Rx Connect Speed AVP is defined in Section 5.4.4 of [RFC3931]. 1478 The Rx Connect Speed BPS AVP, Attribute Type 38, MUST NOT be used in 1479 PPP over L2TPv3 signaling. 1481 6. Data Channel Sequencing 1483 The general procedures for sequencing data packets are defined in 1484 Section 4.6.1 of the base L2TPv3 specification [RFC3931]. 1485 Additionally, Appendix C of [RFC3931] provides sequence number 1486 processing considerations. 1488 This section describes the method for using sequence numbers on the 1489 L2TPv3 data plane carrying PPP frames. It also provides guidelines 1490 on when to use these sequence numbers. 1492 6.1. Sequence Numbers 1494 The Sequence Number field defined in the Default L2-Specific Sublayer 1495 header allows an LCCE to convey sequence information to a peer. 1496 Unlike the L2TPv3 control plane, the L2TPv3 data plane carrying PPP 1497 frames does not use sequencing to retransmit lost data messages. 1498 Rather, sequencing may be used to detect lost packets and/or restore 1499 the original sequence of packets that may have been reordered during 1500 traversal of the packet network. 1502 The sequence number begins at 0, which is a valid sequence number. 1503 Each subsequent message is sent with the next increment of the 1504 sequence number. The sequence number is thus a free-running counter 1505 represented modulo 2^24. The sequence number in the header of a 1506 received message is considered less than or equal to the last 1507 received number if its value lies in the range of the last received 1508 number and the preceding (2^23 - 1) values, inclusive. For example, 1509 if the last received sequence number was 15, then messages with 1510 sequence numbers 0 through 15, as well as 8388624 through 16777215, 1511 would be considered less than or equal. 1513 When desired, sequencing may be enabled on some or all packets by 1514 using the S bit and Sequence Number field defined in the L2-Specific 1515 Sublayer (see Section 4.1). For a given L2TPv3 session, each LCCE is 1516 responsible for communicating to its peer the level of sequencing 1517 support that it requires of data packets that it receives using the 1518 Data Sequencing AVP in Section 5.2.1.1. Mechanisms to advertise this 1519 information during session negotiation are provided (see Data 1520 Sequencing AVP in Section 5.4.4). 1522 6.2. Data Channel Sequencing over Specific Media 1524 When PPP frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP 1525 data channel to the PPP client, this link has the characteristic of 1526 being able to reorder or silently drop packets. Reordering may break 1527 non-IP protocols being carried by PPP, especially LAN-centric ones 1528 such as bridging. Silent dropping of packets may break protocols 1529 that assume per-packet indication of error, such as TCP header 1530 compression. 1532 If any protocol being transported by PPP over these L2TP data 1533 channels cannot tolerate reordering, sequencing may be turned on by 1534 using the sequence number field in the L2-Specific Sublayer header. 1535 The sequence dependency characteristics of individual protocols are 1536 outside the scope of this document. 1538 Allowing packets to be dropped silently is perhaps more problematic 1539 with some protocols. If PPP reliable delivery [RFC1663] is enabled, 1540 no upper PPP protocol will encounter lost packets. If sequence 1541 numbers are enabled, L2TP can detect the packet loss. In the case of 1542 an LNS, the PPP and L2TP stacks are both present within the LNS, and 1543 packet loss signaling may occur precisely as if a packet was received 1544 with a CRC error. Where the LAC and PPP stack are co-resident, this 1545 technique also applies. Where the LAC and PPP client are physically 1546 distinct, the analogous signaling MAY be accomplished by sending a 1547 packet with a CRC error to the PPP client. Note that this would 1548 greatly increase the complexity of debugging client line problems, 1549 since the client statistics could not distinguish between true media 1550 errors and LAC-initiated ones. Further, this technique is not 1551 possible on all hardware. 1553 If VJ compression is used, and neither PPP reliable delivery nor 1554 sequence numbers are enabled, each lost packet results in a 1 in 2^16 1555 chance of a TCP segment being forwarded with incorrect contents 1556 [RFC1144]. Where the combination of the packet loss rate with this 1557 statistical exposure is unacceptable, TCP header compression SHOULD 1558 NOT be used. 1560 In general, it is wise to remember that the L2TP-over-IP as well as 1561 the L2TP-over-UDP/IP transports are unreliable transport media. As 1562 with any PPP medium that is subject to loss, care should be taken 1563 when using protocols that are particularly loss-sensitive. Such 1564 protocols include compression and encryption protocols that employ 1565 history. 1567 7. Acknowledgements 1569 The L2TP rewrite team for splitting RFC2661 into the base and 1570 companion PPP specifications consisted of Ignacio Goyret, Jed Lau, 1571 Bill Palter, Mark Townsley, and Madhvi Verma. 1573 This document was based upon RFC2661, for which a number of people 1574 provided valuable input and effort: 1576 The basic concept for L2TP and many of its protocol constructs 1577 were adopted from L2F [RFC2341] and PPTP [RFC2637]. Authors of 1578 these are A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. 1579 Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. 1581 Dory Leifer made valuable refinements to the protocol definition 1582 of L2TP and contributed to the editing of early drafts leading to 1583 [RFC2661]. 1585 Steve Cobb and Evan Caves redesigned the state machine tables. 1587 Barney Wolff provided a great deal of design input on the endpoint 1588 authentication mechanism. 1590 John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege, 1591 Terry Johnson, Dory Leifer, and Rich Shea provided valuable input 1592 and review at the 43rd IETF in Orlando, FL., which led to 1593 improvement of the overall readability and clarity of [RFC2661]. 1595 Thomas Narten provided a great deal of critical review, formatting, 1596 and wrote the initial IANA Considerations section. 1598 Bill Storer, Madhvi Verma, Skip Booth and Maria Alice Dos Santos 1599 provided thorough reviews, most helpful input and many valuable 1600 comments and suggestions for the newer versions of the document. 1602 Later, Mahesh Kelkar provided a healthy review of this document. Y 1603 Prasad provided input and comments on the handling of the offset 1604 padding. Alfred Hoenes provided many editorial suggestions that 1605 improved the text. 1607 8. IANA Considerations 1609 This document defines "magic" numbers to be maintained by the IANA. 1610 The Layer Two Tunneling Protocol "L2TP" Name Spaces are reachable 1611 from [IANA.l2tp-parameters]. 1613 Section 8.1 through Section 8.6 are registrations of new L2TP values 1614 for registries already managed by IANA, and in some cases, 1615 description of the assignment policy for those registries. 1617 8.1. AVP Attributes 1619 As defined in [RFC3931], AVPs contain Vendor ID, Attribute, and Value 1620 fields. For a Vendor ID value of 0, IANA will maintain a registry of 1621 assigned Attributes for the PPP-specific AVPs described in Section 5, 1622 and in some cases, values for those attributes. Seven new AVPs need 1623 assignment by IANA as described in Section 2.2 of [RFC3438]. 1625 A summary of the new AVPs follows: 1627 Control Message Attribute Value Pairs 1629 Attribute 1630 Type Description 1631 --------- ------------------ 1632 AVP-TBD-1 Offset Capability AVP 1633 AVP-TBD-2 Offset Size AVP 1634 AVP-TBD-3 Tx Minimum Speed AVP 1635 AVP-TBD-4 Tx Maximum Speed AVP 1636 AVP-TBD-5 Rx Minimum Speed AVP 1637 AVP-TBD-6 Rx Maximum Speed AVP 1638 AVP-TBD-7 PPP Circuit Errors 1640 Additionally, IANA is requested to rename the Sub-Address AVP, 1641 Attribute Type 23, to "Called Sub-Address AVP". 1643 8.2. Pseudowire Type 1645 The signaling mechanisms defined in this document rely upon the 1646 allocation of the following Pseudowire Type (see Pseudowire 1647 Capabilities List as defined in Section 5.4.3 of [RFC3931], and 1648 L2TPv3 Pseudowire Types in Section 10.6 of [RFC3931]) by the IANA. 1649 The number space is already created as part of the publication of 1650 [RFC3931]. The PPP Pseudowire Type is defined in Section 3.1 of this 1651 specification: 1653 L2TPv3 Pseudowire Types 1654 ----------------------- 1656 0x0007 PPP Pseudowire Type 1658 8.3. Result Code AVP Values 1660 A new L2TP Result Code for the CDN message appears in Section 5.1.2.9 1661 which need assignment by IANA as described in Section 2.3 of 1662 [RFC3438]. 1664 Result Code AVP (Attribute Type 1) Values 1665 ----------------------------------------- 1667 Defined Result Code values for the CDN message are: 1669 RC-TBD1: Session not established due to unsupported Offset 1670 Size 1672 8.4. Bearer Capabilities and Bearer Type 1674 The Bearer Capabilities AVP and Bearer Type AVP (defined in 1675 Section 5.1.1.2 and Section 5.1.2.1 respectively) both contain a 32- 1676 bit bitmask called Bearer Field, which is maintained by IANA. 1678 There is one new bitfield value allocated for this specification: 1680 Value Meaning 1681 0x00000008 V-bit (Virtual access) 1683 Additional bits should only be assigned via Standards Action 1684 [RFC5226]. 1686 8.5. Framing Capabilities and Framing Type 1688 The Framing Capabilities AVP and Framing Type AVP (defined in 1689 Section 5.1.1.1 and Section 5.1.2.2 respectively) both contain a 32- 1690 bit bitmask, Framing Field, maintained by IANA. Additional bits 1691 should only be assigned via Standards Action [RFC5226]. 1693 8.6. Proxy Authen Type AVP Values 1695 The Proxy Authen Type AVP (Attribute Type 29) has an associated value 1696 maintained by IANA. Values 0-5 are currently defined, the remaining 1697 values are available for assignment upon Expert Review [RFC5226]. 1699 9. Security Considerations 1701 PPP over L2TPv3 is subject to the security considerations defined in 1703 [RFC3931]. Specifically, Control Connection Endpoint and Message 1704 Security mechanisms are provided in Section 4.3 and Section 5.4.1 of 1705 [RFC3931]. Data Packet Level Security is described in Section 8.2 of 1706 [RFC3931]. When running over L2TP-over-IP or L2TP-over-UDP/IP, IPsec 1707 can provide packet-level security via ESP and/or AH, as described in 1708 Section 4.1.3 of [RFC3931]. Additional security considerations 1709 specific to carrying PPP frames over L2TPv3 are described in the 1710 following section. 1712 9.1. Proxy PPP Authentication 1714 L2TP defines Proxy LCP and Authentication AVPs that MAY be exchanged 1715 during session establishment to provide forwarding of PPP LCP and 1716 authentication information obtained at the LAC to the LNS for 1717 validation (see Section 5.1.3). This authentication information may 1718 be used to initiate the PPP authentication states on the LNS, 1719 allowing PPP to continue without renegotiation. This implies a 1720 direct trust relationship of the LAC on behalf of the LNS. If the 1721 LAC is not trusted, the LNS policy may mandate to enter an additional 1722 round of LCP negotiation and/or authentication. Therefore, if the 1723 LNS chooses to implement proxy authentication, it MUST be able to be 1724 turned off by configuration, requiring a new round of PPP 1725 authentication initiated by the LNS (which may or may not include a 1726 new round of LCP negotiation). 1728 10. References 1730 10.1. Normative References 1732 [ITU.Q931.1998] 1733 "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN 1734 User - Network Interface Layer 3 Specification for Basic 1735 Call Control", ISO Standard 9594-1, May 1998. 1737 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1738 RFC 1661, July 1994. 1740 [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662, 1741 July 1994. 1743 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1744 Protocol (CHAP)", RFC 1994, August 1996. 1746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1747 Requirement Levels", BCP 14, RFC 2119, March 1997. 1749 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1750 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1751 RFC 2661, August 1999. 1753 [RFC3301] T'Joens, Y., Crivellari, P., and B. Sales, "Layer Two 1754 Tunnelling Protocol (L2TP): ATM access network 1755 extensions", RFC 3301, June 2002. 1757 [RFC3437] Palter, W. and W. Townsley, "Layer-Two Tunneling Protocol 1758 Extensions for PPP Link Control Protocol Negotiation", 1759 RFC 3437, December 2002. 1761 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1762 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1764 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1765 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1766 May 2008. 1768 10.2. Informative References 1770 [IANA.l2tp-parameters] 1771 Internet Assigned Numbers Authority, "Layer Two Tunneling 1772 Protocol "L2TP"", April 2007, 1773 . 1775 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 1776 serial links", RFC 1144, February 1990. 1778 [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, 1779 July 1994. 1781 [RFC2341] Valencia, A., Littlewood, M., and T. Kolar, "Cisco Layer 1782 Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998. 1784 [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, 1785 W., and G. Zorn, "Point-to-Point Tunneling Protocol", 1786 RFC 2637, July 1999. 1788 [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 1789 Internet Assigned Numbers Authority (IANA) Considerations 1790 Update", BCP 68, RFC 3438, December 2002. 1792 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to- 1793 Edge (PWE3) Architecture", RFC 3985, March 2005. 1795 Appendix A. Revision History 1797 [Note to RFC Editor: please remove this entire appendix, and the 1798 corresponding entries in the table of contents, prior to 1799 publication.] 1801 Changes between -07 and -08: 1803 o Added section elements to all the AVPs in Section 5, and include 1804 them in the TOC. Updated citations to all these subsections. 1806 o Multiple editorial fixes and enhancements from Alfred Hoenes. 1808 o Miscelaneous updates in the Called/Calling Number/Sub-Address and 1809 Private Group ID from Ignacio Goyret. 1811 o IANA instructions to rename the Sub-Address AVP to "Called Sub- 1812 Address AVP". 1814 o Updated reference from RFC2434 to [RFC5226]. 1816 Changes between -06 and -07: 1818 o Refresh document about to expire, no content changes. 1820 Changes between -05 and -06: 1822 o Added an Offset Capability AVP at tunnel establishment, to allow 1823 an LCCE advertise the maximum Offset Padding size that it is 1824 willing to insert if requested. This is described in Section 4.2 1825 and Section 5.1.1.3. 1827 o Small clarifications regarding the Offset Size on Section 4 and 1828 Section 5.1.2.9. 1830 o Clarified handing of the ACF in Section 4.3, which resulted in 1831 normatively referencing [RFC3437]. 1833 o Added reference and corresponding citation to IANA's l2tp- 1834 parameters. 1836 Changes between -04 and -05: 1838 o Refresh revision, only rev++, date and boiler changes from new 1839 xml2rfc.tcl version. 1841 Changes between -03 and -04: 1843 o Fixed assorted editorial and typographical errors. 1845 o Moved Section 1.2 and Section 1.3, new acronym in Section 1.1. 1847 o Added a final sentence in Section 2. 1849 o Added clarification regarding the presence of the Rx Minimum| 1850 Maximum|Connect Speed AVPs. 1852 o Change in Section 8.2 and Section 8.2 to match IANA's page format. 1854 o Source changes for strict XML. 1856 Changes between -02 and -03: 1858 o Fixed PPP acronym in the Abstract. 1860 o Added PPP Circuit Errors AVP in Section 5.1.4.1 with the two PPP- 1861 specific fields removed from the Circuit Errors AVP 34 in 1862 [RFC3931]. 1864 o Redraw ACCM AVP figure in Section 5.1.4.2 and added Reserved field 1865 explanation. 1867 Changes between -01 and -02: 1869 o Updated title and title abbrev to reflect L2TPv3. 1871 o Updated abstract, introduction and topology sections. 1873 o Added contributing authors and editors. 1875 o Added Section 3.1 and Section 3.2, turned Section 3 into 1876 Section 3.3. Added the "PPP PW Type" in Section 3.1. 1878 o Added Figure 1 in Section 4. 1880 o Decoupled the L2-Specific Sublayer from the Offset Padding in 1881 Section 4.1, and added new Offset Padding in Section 4.2. 1883 o Removed the HDLC Address and Control fields from the encapsulation 1884 in Section 4.3. 1886 o Changed Section 5.1.2 and Section 5.1.4 title, substituting Call 1887 for Session. 1889 o Updated Bearer Capabilities AVP in Section 5.1.1.2 and Bearer Type 1890 AVP in Section 5.1.2.1 with the existing bit B (broadband access) 1891 in bit 30 and moved bit V (virtual access) to bit 29. 1893 o Substituted ICRQ for ICCN in the Framing Type AVP description in 1894 Section 5.1.2.2. 1896 o Added a note for Called Number AVP, Calling Number AVP and Sub- 1897 Address AVP to interpret the encoding in the context of the Bearer 1898 Type in use for the specific call in Section 5.1.2. 1900 o Added Calling Sub-Address AVP (ICRQ) Type 44 in Section 5.1.2.6. 1902 o Added a note to the Q.931 Cause Code AVP to interpret the Cause 1903 Code relative to the Bearer Type in Section 5.1.2.7. 1905 o Replaced Sequencing Required AVP Type 39 in Section 5.2.1.1 with 1906 the Data Sequencing AVP Type 70 defined in [RFC3931], and moved it 1907 to Section 5.2.1.1. 1909 o Added Private Group ID AVP existing in [RFC2661] to 1910 Section 5.1.2.8. 1912 o Added new Offset Size AVP in Section 5.1.2.9. 1914 o Listed only currently assigned enumerations of "Defined Authen 1915 Type values" for Proxy Authen Type AVP in Section 5.1.3.4 and 1916 Section 8.6, and pointed to Section 8.6. 1918 o Added Circuit Status AVP usage in Section 5.2.1.2, Section 3.2 and 1919 Section 3.3. 1921 o Added short reference in Section 5.2.1.3 and Section 5.2.1.4 to 1922 8-octet Tx/Rx Connect Speed AVPs, Type 74 and 75 defined in 1923 [RFC3931], instead of 4-octet Types 24 and 38. 1925 o Moved Minimum BPS and Maximum BPS from Section 5.2 to 1926 Section 5.1.2 because not defined in [RFC3931], and changed them 1927 to new 8-octet value AVPs renaming them to Tx Minimum Speed and Tx 1928 Maximum Speed respectively in Section 5.1.2 and Section 8.1. 1930 o Added 8-octet Rx Minimum Speed and Rx Maximum Speed in 1931 Section 5.1.2 and Section 8.1. 1933 o Added general sequencing procedures note from [RFC3931] in 1934 Section 6 as well as updated Section 6.1 with 24-bit Sequence 1935 Number and usage of Data Sequencing AVP. 1937 o Added small paragraph to the IANA Considerations generic section 1938 about existing vs. new registries. 1940 o Added Section 8.2 and Section 8.3 with IANA Considerations for 1941 Pseudowire Type and Result Code AVP Values. 1943 o Regrouped, updated and added the new value from -01 in IANA 1944 Considerations Section 8.4 (Bearer Capabilities and Bearer Type) 1945 and Section 8.5 (Framing Capabilities and Framing Type). 1947 o Added Security Considerations Section. 1949 o Updated References and split them into Normative and Informative. 1951 Author's Address 1953 Carlos Pignataro (editor) 1954 Cisco Systems, Inc. 1955 7200 Kit Creek Road 1956 PO Box 14987 1957 Research Triangle Park, NC 27709 1958 USA 1960 Email: cpignata@cisco.com 1962 Full Copyright Statement 1964 Copyright (C) The IETF Trust (2008). 1966 This document is subject to the rights, licenses and restrictions 1967 contained in BCP 78, and except as set forth therein, the authors 1968 retain all their rights. 1970 This document and the information contained herein are provided on an 1971 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1972 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1973 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1974 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1975 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1976 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1978 Intellectual Property 1980 The IETF takes no position regarding the validity or scope of any 1981 Intellectual Property Rights or other rights that might be claimed to 1982 pertain to the implementation or use of the technology described in 1983 this document or the extent to which any license under such rights 1984 might or might not be available; nor does it represent that it has 1985 made any independent effort to identify any such rights. Information 1986 on the procedures with respect to rights in RFC documents can be 1987 found in BCP 78 and BCP 79. 1989 Copies of IPR disclosures made to the IETF Secretariat and any 1990 assurances of licenses to be made available, or the result of an 1991 attempt made to obtain a general license or permission for the use of 1992 such proprietary rights by implementers or users of this 1993 specification can be obtained from the IETF on-line IPR repository at 1994 http://www.ietf.org/ipr. 1996 The IETF invites any interested party to bring to its attention any 1997 copyrights, patents or patent applications, or other proprietary 1998 rights that may cover technology that may be required to implement 1999 this standard. Please address the information to the IETF at 2000 ietf-ipr@ietf.org.