idnits 2.17.1 draft-ietf-pppext-l2tp-link-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses 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 14 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), 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 (November 1998) is 9293 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) == Missing Reference: '15' is mentioned on line 93, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group W. Mark Townsley 2 INTERNET DRAFT Cisco Systems 3 Category: Internet Draft William L. Palter 4 Title: draft-ietf-pppext-l2tp-link-00.txt Network Alchemy 5 Date: November 1998 7 L2TP Link Extensions 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months. Internet-Drafts may be updated, replaced, or obsoleted by 18 other documents at any time. It is not appropriate to use Internet- 19 Drafts as reference material or to cite them other than as a 20 ``working draft'' or ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 24 Directories on ftp.ietf.org, nic.nordu.net, ftp.nisc.sri.com, or 25 munnari.oz.au. 27 Abstract 29 The physical separation of the LAC and LNS with L2TP[2] and logical 30 separation of the responsibilities of each with respect to negotiated 31 link parameters introduces a lack of awareness between the tunnel 32 endpoints that does not exist in a typical PPP dialup device. When 33 possible, Proxy LCP provides a manner in which to negotiate link 34 parameters at the LAC and communication of these in full to the LNS. 35 If these options can be made acceptable to the LNS, then there should 36 not be any insurmountable difficulty with regard to mismatch of link 37 expectations. However, given that there are instances where 38 negotiation of LCP[1] must take place at the LNS, some direction by 39 the LAC as to what parameters are acceptable, as well as some 40 communication from the LNS as to what parameters have been 41 negotiated, is desirable. 43 Table of Contents 45 1.0 Introduction 46 2.0 Communicating desired link parameters from the LAC to the LNS 47 2.1 LCP Want Options 48 2.2 LCP Allow Options 49 2.4 Communicating negotiated link parameters from the LNS to the LAC 51 1.0 Introduction 53 For the majority of topologies today, the Bearer Type, Bearer 54 Capabilities, Framing Type, ACCM, and Framing Capabilities AVPs 55 defined in the L2TP base specification communicate sufficient 56 information between the LAC and LNS for a typical analog or digital 57 dialup link with HDLC-like framing[3]. Defaults for PPP LCP options 58 such as MRU, ACFC and PFC are well understood for various bearer and 59 framing types and are utilized in the event that LCP negotiation by 60 the LNS must occur. 62 For some L2TP applications and, specifically, some PPP media types, 63 particular link capabilities and requirements may need to be sent 64 from the LAC to the LNS in order for the LNS to properly initialize 65 negotiation of LCP. Further, the LCP options negotiated may need to 66 be transmitted back to the LAC so that it may make allowances at the 67 physical link if necessary. 69 LCP options may be classified into roughly three different categories 70 with respect to their affect on L2TP; (1) options which affect 71 framing in a way that the LAC may need to know about or handle 72 specifically (e.g., ALT-FCS, ACCM, MRU), (2) options that are 73 transparent to the LAC (e.g., AUTH-TYPE), and (3) options that the 74 LAC may wish to influence because they are dependent on the media 75 type (ACFC, PFC). We are most concerned about options which fall into 76 category (1) and (3). 78 This document defines new AVPs to allow the LAC and the LNS to 79 communicate complete LCP information in order to react accordingly. 80 LCP option information is structured in the same way as the Proxy LCP 81 AVPs are in the base L2TP specification. This essentially involves 82 encapsulation of a PPP LCP Configure- Request or Configure-Ack packet 83 within an L2TP AVP. 85 1.1 Conventions 87 The following language conventions are used in the items of 88 specification in this document: 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in RFC 2119 [15]. 94 2.0 Communicating desired link parameters from the LAC to the LNS 96 The LAC may utilize the following AVPs within an ICCN or OCCN message 97 in order to influence the LNS to negotiate LCP in a specific manner. 98 If these AVPs are supported by the LNS, they should override any 99 suggestions for LCP options implied by all other AVPs received. 101 These AVPs may coexist with the Proxy AVPs defined in the base L2TP 102 specification. If Proxy AVPs are received, the LNS may choose to 103 accept these parameters, or renegotiate LCP with the options 104 suggested by these AVPs. If the LAC wishes to force negotiation of 105 LCP by the LNS, it should simply omit all Proxy AVPs during call 106 initialization. 108 By default, the AVPs defined in 2.1 and 2.2 are not mandatory (M-bit 109 is set to zero). However, if an LAC implementation needs to strongly 110 enforce adherence to the options defined within the AVPs, it MAY set 111 the M-bit to 1, thus forcing the LNS to discontinue the session if it 112 does not support this AVP. 114 If the AVPs in sections 2.1 and 2.2 are sent to the LNS, the LAC MUST 115 be prepared to accept the AVPs as defined in section 2.3. 117 2.1 LCP Want Options 119 0 1 2 3 120 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 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 |M|0|0|0|0|0| 6+LCP Confreq len | 9 | 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | 3 | LCP confreq... 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 This AVP contains a list of options that the LAC would like to see 128 negotiated by the LNS. In some cases this maps to a desired value 129 (e.g., MRU) and in some cases it maps to a specific option that is 130 desired to be enabled (e.g., ACFC). The LNS should use these 131 suggestions when building its initial Configure- Request. Presence of 132 this AVP is optional. 134 The following chart defines some of the more common LCP options that 135 may be included in this AVP with guidance of how to handle them at 136 the LAC and LNS. This table is provided for some of the more common 137 or problematic LCP options. It is not intended to be an exhaustive 138 representation of all LCP options available. 140 LCP Want Option LAC Action LNS Action 142 MRU LAC provides a LNS SHOULD begin negotiation 143 maximum value with this value. However, 144 it MAY reduce it if 145 necessary. 147 ACCM LAC Provides a mask LNS SHOULD begin negotiation 148 with this value. LNS may 149 add bit(s) while negotiating 151 PFC LAC provides PFC LNS SHOULD being negotiation 152 if it is desired on with this value. 153 the link type 154 (e.g. AHDLC) 156 ACFC LAC provides ACCOMP LNS SHOULD begin negotiation 157 if it is desired on with this value. 159 the link type 160 (e.g. AHDLC) 162 FCS-ALT LAC indicates required LNS SHOULD begin negotiation 163 values for the link with this value. Note 164 type that this value is of 165 no consequence to the LNS 166 as FCS is stripped at the 167 LAC, however some PPP 168 media types require this 169 option. 171 2.2 LCP Allow Options 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |M|0|0|0|0|0| 6+LCP Confack len | 9 | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | 3 | LCP confack... 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 This AVP contains a list of options that the LAC will allow to be 182 negotiated by the LNS. In some cases this maps to a maximum value 183 (e.g., MRU) and in others it maps to an option that is permitted by 184 the LAC (e.g., ACFC). If the option is not included here, it can be 185 assumed by the LNS that the LAC does not understand how to perform 186 that particular option at the link layer. This may or may not affect 187 operation of the tunneled session. Information in this AVP should be 188 utilized when building PPP Configure-Ack, Configure-Reject and 189 Configure-Nak messages. Presence of this AVP is optional. 191 The following chart defines some of the more common LCP options that 192 may be included in this AVP with guidance of how to handle them at 193 the LAC and LNS. This table is provided for illutration purposes for 194 some of the more common or problematic LCP options. It is not 195 intended to be an exhaustive representation of all LCP options 196 available. 198 LCP Allow Option LAC Action LNS Action 200 MRU LAC provides a LNS may accept reduction 201 maximum value of this value as requested 203 ACCM LAC Provides a mask LNS may accept bit(s) 204 defined here. Note that 205 if ACCM is missing it is 206 assumed that it is not 207 applicable to the link type 209 PFC LAC provides PFC LNS may accept PFC 210 if it is allowed on 211 the link type 212 (e.g. AHDLC) 214 ACFC LAC provides ACFC LNS may accept ACFC 215 if it is allowed on 216 the link type 217 (e.g. AHDLC) 219 FCS-ALT LAC indicates valid Negotiation this option 220 values for the link is of no consequence to the 221 type LNS as the FCS is stripped 222 at the LAC. However, the 223 LNS SHOULD only accept 224 FCS-ALT types listed here 225 (more than one value may be 226 present). 228 2.3 Communicating negotiated link parameters from the LNS to the LAC 230 There are no new AVPs defined for communication of negotiated 231 parameters from the LNS to the LAC. Instead, two AVPs that are 232 defined in the base L2TP specification are simply included in a new 233 location. 235 When LCP negotiation is complete by the LNS, a Set-Link-Info control 236 message may be sent with the the Last Sent LCP Confreq (IETF L2TP 237 Attribute 27) and Last Received LCP Confreq (IETF L2TP Attribute 28) 238 included in the list of AVPs. These AVPs should contain the last sent 239 and last received (with respect to the LNS) LCP packets. For AVP 240 format details, refer to the L2TP base specification. 242 If LCP negotiation occurs at the LNS and the new AVPs defined in 243 section 2.1 and 2.2 of this document are utilized, then a Set-Link- 244 Info control message MUST be sent on completion of the LCP 245 negotiation, and the Last Sent and Last Received LCP Confreq packets 246 MUST be included. 248 3.0 Contacts 250 W. Mark Townsley 251 Cisco Systems 252 7025 Kit Creek Road 253 PO Box 14987 254 Research Triangle Park, NC 27709 255 townsley@cisco.com 257 Bill Palter 258 Network Alchemy, Inc 259 1521.5 Pacific Ave 260 Santa Cruz, CA 95060 261 palter@zev.net 263 4.0 References 265 [1] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 266 07/21/1994 268 [2] A. Valencia, W. M. Townsley, W. Palter, et. al. "Layer Two Tunneling Protocol", 269 ''work in progress'', October 1998 271 [3] W. Simpson, "PPP in HDLC-like framing", RFC 1662, 272 07/21/1994