idnits 2.17.1 draft-ietf-pppext-l2tp-fr-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-26) 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. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 38: '...nneling Protocol MUST be implemented o...' RFC 2119 keyword, line 65: '... o MUST, SHALL, or MANDATORY -...' RFC 2119 keyword, line 68: '... o SHOULD or RECOMMEND -- This...' RFC 2119 keyword, line 71: '... o MAY or OPTIONAL -- This ite...' RFC 2119 keyword, line 113: '...L2TP MUST be able to share a Frame Rel...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 62 has weird spacing: '...e items of...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: L2TP MUST be able to share a Frame Relay virtual circuit (VC) with other protocols carried over the same VC. The Frame Relay header format for data packet needs to be defined to identify the protocol being carried in the packets. The Frame Relay network MAY NOT understand these formats. == 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 (June 1998) is 9447 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) == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-11 -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-08) exists of draft-ietf-radius-tunnel-auth-05 ** Downref: Normative reference to an Informational draft: draft-ietf-radius-tunnel-auth (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1490 (ref. '5') (Obsoleted by RFC 2427) == Outdated reference: A later version (-05) exists of draft-ietf-pppext-l2tp-security-02 -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 12 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group Vipin Rawat, Rene Tio 2 INTERNET DRAFT Cisco Systems 3 Category: Internet Draft Rohit Verma 4 Title: draft-ietf-pppext-l2tp-fr-00.txt 3Com Corporation 5 Date: June 1998 7 Layer Two Tunneling Protocol (L2TP) over Frame Relay 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are 13 working documents of the Internet Engineering Task Force 14 (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as 16 Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by 20 other documents at any time. It is inappropriate to use 21 Internet-Drafts as reference material or to cite them 22 other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please 25 check the ``1id-abstracts.txt'' listing contained in the 26 Internet-Drafts Shadow Directories on ftp.is.co.za 27 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 28 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US 29 West Coast). Distribution of this memo is unlimited. 31 Abstract 33 Layer Two Tunneling Protocol describes a mechanism to 34 tunnel PPP sessions. The protocol has been designed to be 35 independent of the media it runs over. The base 36 specification describes how it should be implemented to 37 run over UDP and IP. This document describes how the 38 Layer Two Tunneling Protocol MUST be implemented over 39 Frame Relay PVCs and SVCs. 41 Applicability 43 This specification is intended for those implementations 44 which desire to use facilities which are defined for L2TP. 45 These capabilities require a point-to-point relationship 46 between peers, and are not designed for multi-point 47 relationships which is available in Frame Relay and other 48 NBMA environments. 50 1.0 Introduction 52 L2TP [1] defines a general purpose mechanism for tunneling 53 PPP over various media. By design, it insulates L2TP 54 operation from the details of the media over which it 55 operates. The base protocol specification illustrates how 56 L2TP may be used in IP environments. This draft specifies 57 the encapsulation of L2TP over native Frame Relay and 58 addresses relevant issues. 60 2.0 Conventions 62 The following language conventions are used in the items of 63 specification in this document: 65 o MUST, SHALL, or MANDATORY -- This item is an 66 absolute requirement of the specification. 68 o SHOULD or RECOMMEND -- This item should generally 69 be followed for all but exceptional circumstances. 71 o MAY or OPTIONAL -- This item is truly optional and 72 may be followed or ignored according to the needs of 73 the implementor. 75 3.0 Problem Space Overview 77 In this section we describe in high level terms the scope of 78 the problem being addressed. 80 Topology: 81 +-------+ +---------------+ | 82 | PSTN | | Frame Relay | | 83 User--| |----LAC ===| |=== LNS --+ LANs 84 | ISDN | | Cloud | | 85 +-------+ +---------------+ | 87 L2TP Access Concentrator (LAC) is a device attached to the 88 switched network fabric (e.g. PSTN or ISDN) or co-located 89 with a PPP end system capable of handling the L2TP protocol. 90 The LAC need only implement the media over which L2TP is to 91 operate to pass traffic to one or more LNS's. It may tunnel 92 any protocol carried within PPP. 94 L2TP Network Server (LNS) operates on any platform capable of 95 PPP termination. The LNS handles the server side of the L2TP 96 protocol. L2TP is connection-oriented. The LNS and LAC 97 maintain state for each user that is attached to an LAC. A 98 session is created when an end-to-end PPP connection is 99 attempted between a user and the LNS. The datagrams related 100 to a session are sent over the tunnel between the LAC and 101 LNS. A tunnel is defined by an LNS-LAC pair. The tunnel 102 carries PPP datagrams between the LAC and the LNS. 104 L2TP protocol operates at a level above the particular media 105 over which it is carried. However, some details of its 106 connection to media are required to permit interoperable 107 implementations. L2TP over IP/UDP is described in the base 108 draft [1]. Issues related to L2TP over Frame Relay are 109 addressed in later sections of this draft. 111 4.0 Encapsulation and Packet Format 113 L2TP MUST be able to share a Frame Relay virtual circuit (VC) 114 with other protocols carried over the same VC. The Frame 115 Relay header format for data packet needs to be defined to 116 identify the protocol being carried in the packets. The 117 Frame Relay network MAY NOT understand these formats. 119 All protocols over this circuit MUST encapsulate their 120 packets within a Q.922 frame. Additionally, frames MUST 121 contain information necessary to identify the protocol 122 carried within the frame relay Protocol Data Unit (PDU), thus 123 allowing the receiver to properly process the incoming 124 packet. 126 The frame format for L2TP is based on SNAP encapsulation as 127 defined in RFC 1490 [5] and FRF3.1 [2]. SNAP format uses 128 NLPID followed by Organizationally Unique Identifier and a 129 PID. 131 NLPID 133 The single octet identifier provides a mechanism to allow 134 easy protocol identification. For L2TP NLPID value 0x80 is 135 used which indicates the presence of SNAP header. 137 OUI & PID 139 The three-octet Organizationally Unique Identifier (OUI) 140 0x00-00-5E identifies IANA who administers the meaning of the 141 Protocol Identifier (PID) 0x??-?? (PID to be determined 142 pending application to IANA) which follows. Together they 143 identify a distinct protocol. 145 Format of L2TP frames encapsulated in Frame Relay is given in 146 Figure 1. 148 Octet 1 2 149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 1 | Q.922 Address | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 3 | Control 0x03 | pad 0 | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 5 | NLPID 0x80 | OUI 0x00 | 156 +-+-+-+-+-+-+-+-+ + 157 7 | OUI 0x00-5E | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 9 | PID 0x??-?? | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | | 162 | L2TP packet | 163 | | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | FCS | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1 Format for L2TP frames encapsulated in Frame Relay 169 5.0 MTU Considerations 171 FRF.12 [4] is the Frame Relay Fragmentation Implementation 172 Agreement. If fragmentation is not supported, the two Frame 173 Relay endpoints MUST support an MTU size of at least PPP 174 Max-Receive-Unit size + PPP header size + maximum L2TP Header 175 Size + Frame Relay header size. Note the PPP header includes 176 both the protocol field plus HDLC framing bytes, which is 177 required by L2TP. The means to co-ordinate the PPP MRU and 178 Frame Relay MTU are left to implementation. 180 6.0 QOS Issues 182 In general, QoS mechanisms can be roughly provided for with 183 proprietary mechanisms localized within the LAC or LNS. 184 Interworking issues with various QoS implementations is 185 therefore at this time left as a topic for future study. 187 7.0 Frame Relay and L2TP Interaction 189 In case of Frame Relay SVCs, connection setup will be 190 triggered when L2TP tries to create a tunnel. Details of 191 triggering mechanism are left to implementation. There SHALL 192 NOT be any change in Frame Relay SVC signaling due to L2TP. 193 The endpoints of the L2TP tunnel MUST be identified by 194 X.121/E.164 addresses in case of Frame Relay SVC. These 195 addresses MAY be obtained as tunnel endpoints for a user as 196 defined in [3]. In case of PVCs, the Virtual Circuit to 197 carry L2TP traffic MAY be configured administratively. The 198 endpoints of the tunnel MUST be identified by DLCI, assigned 199 to the PVC at configuration time. This DLCI MAY be obtained 200 as tunnel endpoints for a user as defined in [3]. 202 There SHALL be no framing issues between PPP and Frame Relay. 203 PPP frames received by LAC from remote user are stripped of 204 CRC, link framing, and transparency bytes, encapsulated in 205 L2TP, and forwarded over Frame Relay tunnel. 207 8.0 Security Considerations 209 Frame Relay, being a circuit-switched media, is typically 210 less pervious to security attacks [6]. If such attacks 211 become prevalent, it may be desirable to implement additional 212 security mechanisms. 214 Currently there is no standard specification for Frame Relay 215 security. The Frame Relay Forum is working on a Frame Relay 216 Privacy Agreement [7] which specifies authentication, 217 encryption, and key exchange facilities. In light of this 218 work, the issue of security will be re-examined at a later 219 date to see if L2TP over Frame Relay specific protection 220 mechanisms are still required. Meanwhile, if stronger 221 security mechanisms is required, the use of IP as an 222 intermediate transport layer with IPsec for security is 223 RECOMMENDED. 225 9.0 Acknowledgments 227 Ken Pierce (3Com Corporation), Matt Harper (3Com Corporation) 228 and Rick Dynarski (3Com Corporation) contributed to the 229 editing of this document. 231 10.0 References 233 [1] Valencia et al., "Layer Two Tunneling Protocol - 234 L2TP", Internet draft (work in progress), draft-ietf- 235 pppext-l2tp-11.txt, May, 1998. 237 [2] Multiprotocol Encapsulation Implementation 238 Agreement, FRF.3.1 , Frame Relay Forum Technical 239 Committee, June 1995 241 [3] G. Zorn, D. Leifer, A. Rubens, J. Shriver. "RADIUS 242 Attributes for Tunnel Protocol Support." Internet draft 243 (work in progress), draft-ietf-radius-tunnel-auth-05.txt, 244 Microsoft, Ascend Communications, Shiva Corporation, 245 April 1998. 247 [4] Frame Relay Fragmentation Implemenation Agreement, 248 FRF.12, Frame Relay Forum Technical Committee, December 249 1997 251 [5] T. Bradley, C. Brown, A. Malis, "Multiprotocol 252 Interconnect over Frame Relay ", RFC 1490, July 1993 254 [6] B. Patel, B. Aboda. "Securing L2TP using IPSEC." 255 Internet draft (work in progress), draft-ietf-pppext- 256 l2tp-security-02.txt, Intel, Microsoft, May 1998 258 [7] Frame Relay Privacy Implementation Agreement, DRAFT, 259 Frame Relay Forum Technical Committee, June 1998 261 11.0 Author's Addresses 262 Vipin Rawat, Rene Tio 263 Cisco Systems 264 170 West Tasman Drive 265 San Jose CA 95134-1706 266 vrawat@cisco.com 267 rtio@cisco.com 269 Rohit Verma 270 3Com Corporation 271 1800 W. Central Road 272 Mount Prospect 273 Illinois 60056 274 Rohit_Verma@mw.3com.com