idnits 2.17.1 draft-ietf-pppext-l2tp-fr-01.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-23) 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. 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 39: '...nneling Protocol MUST be implemented o...' RFC 2119 keyword, line 66: '... o MUST, SHALL, or MANDATORY -...' RFC 2119 keyword, line 69: '... o SHOULD or RECOMMEND -- This...' RFC 2119 keyword, line 72: '... o MAY or OPTIONAL -- This ite...' RFC 2119 keyword, line 114: '...L2TP MUST be able to share a Frame Rel...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 63 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 (December 1998) is 9261 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) == Unused Reference: '7' is defined on line 259, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-12 -- 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. -------------------------------------------------------------------------------- 2 PPP Working Group Vipin Rawat, Rene Tio 3 INTERNET DRAFT Cisco Systems 4 Category: Internet Draft Rohit Verma 5 Title: draft-ietf-pppext-l2tp-fr-01.txt 3Com Corporation 6 Date: December 1998 8 Layer Two Tunneling Protocol (L2TP) over Frame Relay 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of 20 six months and may be updated, replaced, or obsoleted by 21 other documents at any time. It is inappropriate to use 22 Internet-Drafts as reference material or to cite them 23 other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please 26 check the ``1id-abstracts.txt'' listing contained in the 27 Internet-Drafts Shadow Directories on ftp.is.co.za 28 (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific 29 Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US 30 West Coast). Distribution of this memo is unlimited. 32 Abstract 34 Layer Two Tunneling Protocol describes a mechanism to 35 tunnel PPP sessions. The protocol has been designed to be 36 independent of the media it runs over. The base 37 specification describes how it should be implemented to 38 run over UDP and IP. This document describes how the Layer 39 Two Tunneling Protocol MUST be implemented over Frame 40 Relay PVCs and SVCs. 42 Applicability 44 This specification is intended for those implementations 45 which desire to use facilities which are defined for L2TP. 46 These capabilities require a point-to-point relationship 47 between peers, and are not designed for multi-point 48 relationships which is available in Frame Relay and other 49 NBMA environments. 51 1.0 Introduction 53 L2TP [1] defines a general purpose mechanism for tunneling 54 PPP over various media. By design, it insulates L2TP 55 operation from the details of the media over which it 56 operates. The base protocol specification illustrates how 57 L2TP may be used in IP environments. This draft specifies the 58 encapsulation of L2TP over native Frame Relay and addresses 59 relevant issues. 61 2.0 Conventions 63 The following language conventions are used in the items of 64 specification in this document: 66 o MUST, SHALL, or MANDATORY -- This item is an 67 absolute requirement of the specification. 69 o SHOULD or RECOMMEND -- This item should generally 70 be followed for all but exceptional circumstances. 72 o MAY or OPTIONAL -- This item is truly optional and 73 may be followed or ignored according to the needs of 74 the implementor. 76 3.0 Problem Space Overview 78 In this section we describe in high level terms the scope of 79 the problem being addressed. 81 Topology: 82 +-------+ +---------------+ | 83 | PSTN | | Frame Relay | | 84 User--| |----LAC ===| |=== LNS --+ LANs 85 | ISDN | | Cloud | | 86 +-------+ +---------------+ | 88 L2TP Access Concentrator (LAC) is a device attached to the 89 switched network fabric (e.g. PSTN or ISDN) or co-located 90 with a PPP end system capable of handling the L2TP protocol. 91 The LAC need only implement the media over which L2TP is to 92 operate to pass traffic to one or more LNS's. It may tunnel 93 any protocol carried within PPP. 95 L2TP Network Server (LNS) operates on any platform capable of 96 PPP termination. The LNS handles the server side of the L2TP 97 protocol. L2TP is connection-oriented. The LNS and LAC 98 maintain state for each user that is attached to an LAC. A 99 session is created when an end-to-end PPP connection is 100 attempted between a user and the LNS. The datagrams related 101 to a session are sent over the tunnel between the LAC and 102 LNS. A tunnel is defined by an LNS-LAC pair. The tunnel 103 carries PPP datagrams between the LAC and the LNS. 105 L2TP protocol operates at a level above the particular media 106 over which it is carried. However, some details of its 107 connection to media are required to permit interoperable 108 implementations. L2TP over IP/UDP is described in the base 109 draft [1]. Issues related to L2TP over Frame Relay are 110 addressed in later sections of this draft. 112 4.0 Encapsulation and Packet Format 114 L2TP MUST be able to share a Frame Relay virtual circuit (VC) 115 with other protocols carried over the same VC. The Frame 116 Relay header format for data packet needs to be defined to 117 identify the protocol being carried in the packets. The Frame 118 Relay network MAY NOT understand these formats. 120 All protocols over this circuit MUST encapsulate their 121 packets within a Q.922 frame. Additionally, frames MUST 122 contain information necessary to identify the protocol 123 carried within the frame relay Protocol Data Unit (PDU), thus 124 allowing the receiver to properly process the incoming 125 packet. 127 The frame format for L2TP is based on SNAP encapsulation as 128 defined in RFC 1490 [5] and FRF3.1 [2] . SNAP format uses 129 NLPID followed by Organizationally Unique Identifier and a 130 PID. 132 NLPID 134 The single octet identifier provides a mechanism to allow 135 easy protocol identification. For L2TP NLPID value 0x80 is 136 used which indicates the presence of SNAP header. 138 OUI & PID 140 The three-octet Organizationally Unique Identifier (OUI) 141 0x00-00-5E identifies IANA who administers the meaning of the 142 Protocol Identifier (PID) 0x0007. Together they identify a 143 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 0x0007 | 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 + Max L2TP Header 175 Size + Frame Relay header size (PPP header size is the 176 protocol field size plus HDLC framing bytes, which is 177 required by L2TP). 1500 + 64 is RECOMMENDED for default PPP 178 default MRU of 1500 to avoid packet discards on the Frame 179 Relay interface. The means to ensure these MTU settings are 180 left to implementation. 182 6.0 QOS Issues 184 In general, QoS mechanisms can be roughly provided for with 185 proprietary mechanisms localized within the LAC or LNS. 186 Interworking issues with various QoS implementations is 187 therefore at this time left as a topic for future study. 189 7.0 Frame Relay and L2TP Interaction 191 In case of Frame Relay SVCs, connection setup will be 192 triggered when L2TP tries to create a tunnel. Details of 193 triggering mechanism are left to implementation. There SHALL 194 NOT be any change in Frame Relay SVC signaling due to L2TP. 195 The endpoints of the L2TP tunnel MUST be identified by 196 X.121/E.164 addresses in case of Frame Relay SVC. These 197 addresses MAY be obtained as tunnel endpoints for a user as 198 defined in [3]. In case of PVCs, the Virtual Circuit to carry 199 L2TP traffic MAY be configured administratively. The 200 endpoints of the tunnel MUST be identified by DLCI, assigned 201 to the PVC at configuration time. This DLCI MAY be obtained 202 as tunnel endpoints for a user as defined in [3]. 204 There SHALL be no framing issues between PPP and Frame Relay. 205 PPP frames received by LAC from remote user are stripped of 206 CRC, link framing, and transparency bytes, encapsulated in 207 L2TP, and forwarded over Frame Relay tunnel. 209 8.0 Security Considerations 211 Frame Relay, being a circuit-switched media, is typically 212 less pervious to security attacks [6]. If such attacks 213 become prevalent, it may be desirable to implement additional 214 security mechanisms. 216 Currently there is no standard specification for Frame Relay 217 security. The Frame Relay Forum is working on a Frame Relay 218 Privacy Agreement [6] which specifies authentication, 219 encryption, and key exchange facilities. In light of this 220 work, the issue of security will be re-examined at a later 221 date to see if L2TP over Frame Relay specific protection 222 mechanisms are still required. Meanwhile, if stronger 223 security mechanisms is required, the use of IP as an 224 intermediate transport layer with IPsec for security is 225 RECOMMENDED. 227 9.0 Acknowledgments 229 Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com 230 Corporation) contributed to the editing of this document. 232 10.0 References 234 [1] Valencia et al., "Layer Two Tunneling Protocol - 235 L2TP", Internet draft (work in progress), draft-ietf- 236 pppext-l2tp-12.txt, Nov, 1998. 238 [2] Multiprotocol Encapsulation Implementation 239 Agreement, FRF.3.1 , Frame Relay Forum Technical 240 Committee, June 1995 242 [3] G. Zorn, D. Leifer, A. Rubens, J. Shriver. "RADIUS 243 Attributes for Tunnel Protocol Support." Internet draft 244 (work in progress), draft-ietf-radius-tunnel-auth-05.txt, 245 Microsoft, Ascend Communications, Shiva Corporation, 246 April 1998. 248 [4] Frame Relay Fragmentation Implemenation Agreement, 249 FRF.12, Frame Relay Forum Technical Committee, December 250 1997 252 [5] T. Bradley, C. Brown, A. Malis, "Multiprotocol 253 Interconnect over Frame Relay ", RFC 1490, July 1993 255 [6] B. Patel, B. Aboda. "Securing L2TP using IPSEC." 256 Internet draft (work in progress), draft-ietf-pppext- 257 l2tp-security-02.txt, Intel, Microsoft, May 1998 259 [7] Frame Relay Privacy Implementation Agreement, DRAFT, 260 Frame Relay Forum Technical Committee, June 1998 262 11.0 Author's Addresses 263 Vipin Rawat, Rene Tio 264 Cisco Systems 265 170 West Tasman Drive 266 San Jose CA 95134-1706 267 vrawat@cisco.com 268 rtio@cisco.com 270 Rohit Verma 271 3Com Corporation 272 1800 W. Central Road 273 Mount Prospect 274 Illinois 60056 275 Rohit_Verma@mw.3com.com