idnits 2.17.1 draft-ietf-l2tpext-svctype-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC1661], [RFC2661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- 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 (April 2001) is 8411 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) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Danny McPherson 2 INTERNET DRAFT Amber Networks, Inc. 3 Category: Internet Draft Suhail Nanji 4 Title: draft-ietf-l2tpext-svctype-01.txt Redback Networks, Inc. 5 Date: April 2001 7 L2TP Service Type 8 10 1. Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 2. Abstract 33 The Layer Two Tunneling Protocol (L2TP) [RFC 2661] provides a 34 standard method for tunneling PPP [RFC 1661] packets. This document 35 describes an extension to L2TP which provides a mechanism to support 36 tunneling of additional payload types over individual sessions within 37 an L2TP tunnel. These extensions provide added functionality which 38 is optional and preserves backwards compatibility. 40 3. Specification of Requirements 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 44 document are to be interpreted as described in [RFC 2119]. 46 4. Introduction 48 The Layer Two Tunneling Protocol defines a mechanism for tunneling 49 PPP PDUs only. This document describes an extension which enables 50 L2TP to support additional payload types. This extension allows 51 sessions to carry different payloads within the same tunnel. The 52 normal operation of L2TP is not modified if the attributes described 53 below are not implemented. 55 5. Tunnel Establishment 57 The basic tunnel establishment procedures defined in [RFC 2661] are 58 unchanged. The only addition is that of a new AVP, the Service 59 Capabilities List AVP, which is used for indicating which payload 60 type(s) are supported on sessions of this tunnel. 62 5.1. Service Capabilities List (SCCRP, SCCRQ) 64 The Service Capabilities List AVP is encoded as Vendor ID 311, and 65 the Attribute Value is the 16-bit quantity 999 (the ID 311 reflects 66 Microsoft, it should be changed to 0 and an official Attribute Value 67 chosen should this specification advance on as standards track). The 68 Value is a list of supported Service Types. 70 The AVP has the following format: 72 Vendor ID = 311 73 Attribute = 999 75 0 1 2 3 76 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 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 |M|H|0|0|0|0| Length | 311 | 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 | 999 | Service Type 0 | 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 82 | ... | Service Type N | 83 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 85 The AVP MUST be present if the sender can place calls employing the 86 Service Type when requested. Presence of a given Service Type is not 87 a guarantee that a given call will be placed by the sender if 88 requested, just that the capability to terminate the indicated 89 Service Type(s) exists. 91 The AVP MAY be hidden (the H-bit may be 0 or 1). The Length (before 92 hiding) of this AVP MUST be 8 octets with one Service Type specified, 93 plus 2 octets for each additional Service Type. 95 The Service Type and Service Capabilities AVPs described in this 96 document provide the base mechanisms for other PDUs other than PPP to 97 be tunneled via L2TP. In order to facilitate this in a backwards 98 compatible manner, the M-bit MUST NOT be set on the Service 99 Capabilities AVP unless RFC 2661 PPP tunneling is NOT supported. 100 Thus, if RFC 2661 PPP tunneling is NOT supported by a particular 101 implementation (or disallowed by configuration or policy), the M-bit 102 MUST be set on the Service Capabilities AVP in order to ensure that 103 an implementation unaware of Service Types other than PPP and/or 104 requiring a Service Type for PPP tunneling would disallow 105 establishment of the L2TP tunnel. 107 If the sessions on this tunnel MUST use the Service Type AVP, then 108 the M-bit MUST be set to 1 for the Service Capabiliites List AVP. 109 This mode of operation explicitly eliminates backwards comptability 110 with PPP payload sessions which do not employ the Service Type AVP. 111 In this mode, sessions carrying a PPP payload MUST use the PPP 112 Service Type AVP value detailed below. 114 If the sessions on this tunnel MAY use the Service Type AVP, the the 115 M-bit MUST be set to 0 for the Service Capabilities List AVP. This 116 mode of operation maintains backwards comptability with PPP payload 117 sessions which do not employ the Service Type AVP. In this mode, 118 sessions carrying a PPP payload MAY use the PPP Service Type AVP 119 value detailed below. 121 If a LAC or LNS requires use of the Service Type AVP for every 122 session and it receives a Service Capabilities List AVP without the 123 M-bit set to 0, then the tunnel MUST be torn down. If a LAC or LNS 124 does not support the Service Type Extensions AVPs and it receives a 125 Service Capabilities List AVP with the M-bit set to 1, then a tunnel 126 MUST be torn down. 128 6. Session Establishment 130 The basic call establishment procedures defined in [RFC 2661] are 131 unchanged. A new AVP for indicating the payload type the session 132 will support is defined. 134 6.1. Service Type (ICRQ, OCRQ) 136 The Service Type AVP encodes the Service Type for the incoming or 137 outgoing call. In order to retain backwards compatibility with [RFC 138 2661], if the Service Type attribute is not present, then the session 139 MUST carry a PPP payload. If the Service Capabilities List AVP had 140 only the PPP Service Type, then the PPP Service Type AVP MUST be used 141 for all sessions. 143 An LNS MUST NOT send an OCRQ with a Service Type AVP specifying a 144 value not advertised in the Service Capabilities List AVP received 145 from the LAC. Similarly, an LAC MUST NOT send an ICRQ with a Service 146 Type AVP specifying a value not advertised in the Service 147 Capabilities List AVP received from the LNS. If a Service Type AVP 148 is received (in an ICRQ or OCRQ) and it contains a value that has not 149 been advertised for the tunnel in the Services Capabilities List AVP, 150 then the session MUST be torn down. 152 The value of this attribute is one of the supported Service Types. 153 The Service Type AVP is encoded as Vendor ID 311, and the Attribute 154 Value is the 16-bit quantity 998 (the ID 311 reflects Microsoft, it 155 should be changed to 0 and an official Attribute Value chosen if this 156 specification advances on as standards track). The Service Type AVP 157 MUST be located immediately following the Message Type AVP (unless it 158 is hidden, in which case the Random Vector AVP will precede it). 160 The Service Type value is represented by a 16-bit quantity of the 161 range 0-65535. Assignment of values within this range are defined in 162 the "Service Type AVP Values" section. 164 Vendor ID = 311 165 Attribute = 998 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |1|H|0|0|0|0| Length | 311 | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | 998 | Service Type | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 The AVP MAY be hidden (the H-bit may be 0 or 1). The M-bit for this 176 AVP MUST be set to 1. The Length (before hiding) of this AVP is 8. 178 6.2. Service Type AVP Values 180 The range of potential Service Type values is 0-65535. This document 181 defines one of those values for PPP as defined in [RFC 2661]. 183 Service Type AVP Values 185 Payload Type Value 187 Reserved 0 (zero) 188 PPP 1 189 FCFS 2-65534 190 Reserved 65535 192 See Section "IANA Considerations" for additional information on 193 Service Type AVP values. 195 7. Migration to Standard Attributes 197 It is intended that both the Service Capabilities List and Service 198 Type attributes will be migrated to standard attributes. As a result, 199 the AVPs outlined in this draft would have a Vendor ID value of 0 and 200 standard Attribute Values. Furthermore, it is intended the drafts 201 "L2TP Circuit Emulation Services Extension" and "Ethernet 202 Encapsulation Extensions to L2TP" will be deprecated. 204 8. IANA Considerations 206 The Service Type AVP namespace will be registered and maintained by 207 IANA as follows: 209 o Values 0 and 65535 are reserved. 211 o Value 1 is reserved for PPP payloads. 213 o Values between 2 and 65534 are to be assigned by IANA, using 214 the "Specification Required" policy listed below [RFC 2434]. 216 8.1. Specification Requirements for New Service Types 218 To define a new Service Type for a payload other than PPP,a new RFC 219 MUST be drafted which MUST: 221 o Identify any new L2TP AVPs or control messases necessary for the 222 establishment, maintenance, and teardown of the non-PPP session. 224 o Identify which AVPs must be present (new or existing) in each 225 existing or new control message with a given service type. 227 o Identify any existing AVPs which have a new or revised meaning for 228 a given Service Type beyond that defined in RFC2661. 230 9. Security Considerations 232 This extension to L2TP does not changes the inherent security of L2TP, 233 nor does it introduce new security issues. 235 10. Acknowledgements 237 Thanks to W. Mark Townsley of Cisco Systems, Bill Palter of Redback 238 Networks, and Nishit Vasavada and Andy Koscinski of Amber Networks. 239 Copious amounts of text were stolen from the L2TP [RFC 2661]. 241 Special thanks to Glen Zorn for suggesting to use Microsoft's Vendor 242 ID for the new AVPs in the interim. 244 11. References 246 [RFC 2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, 247 B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC2661, 248 August 1999. 250 [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 251 51, RFC 1661, July 1994. 253 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 254 Requirement Levels", BCP 14, RFC 2119, March 1997. 256 [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 257 an IANA Considerations section in RFCs", BCP 26, RFC 258 2434, October 1998. 260 12. Authors' Address 262 Danny McPherson 263 Amber Networks, Inc. 264 48664 Milmont Drive 265 Fremont, CA 94538 266 Phone: +510 687-5200 267 Email: danny@ambernetworks.com 269 Suhail Nanji 270 Redback Networks, Inc. 271 350 Holger Way 272 San Jose, CA 95134-1362 273 Phone: +1 408 571 5413 274 Email: suhail@redback.com