idnits 2.17.1 draft-ietf-pppext-l2tp-fr-02.txt: 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? == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == 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 6 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 40: '...nneling Protocol MUST be implemented o...' RFC 2119 keyword, line 67: '... o MUST, SHALL, or MANDATORY -...' RFC 2119 keyword, line 70: '... o SHOULD or RECOMMEND -- This...' RFC 2119 keyword, line 73: '... o MAY or OPTIONAL -- This ite...' RFC 2119 keyword, line 117: '... L2TP MUST be able to share a Frame ...' (13 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 265, 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: 9 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PPP Working Group Vipin Rawat 2 INTERNET DRAFT Cisco Systems, Inc. 3 Category: Internet Draft Rene Tio 4 Title: draft-ietf-pppext-l2tp-fr-02.txt Redback Networks, Inc. 5 Date: December 1998 Rohit Verma 6 3Com Corporation 8 Layer Two Tunneling Protocol (L2TP) over Frame Relay 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full 14 conformance with all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet 17 Engineering Task Force (IETF), its areas, and its working 18 groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or obsoleted by 23 other documents at any time. It is inappropriate to use 24 Internet- Drafts as reference material or to cite them 25 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 31 accessed at http://www.ietf.org/shadow.html. 33 Abstract 35 Layer Two Tunneling Protocol describes a mechanism to 36 tunnel PPP sessions. The protocol has been designed to be 37 independent of the media it runs over. The base 38 specification describes how it should be implemented to 39 run over UDP and IP. This document describes how the Layer 40 Two Tunneling Protocol MUST be implemented over Frame 41 Relay PVCs and SVCs. 43 Applicability 45 This specification is intended for those implementations 46 which desire to use facilities which are defined for L2TP. 47 These capabilities require a point-to-point relationship 48 between peers, and are not designed for multi-point 49 relationships which is available in Frame Relay and other 50 NBMA environments. 52 1.0 Introduction 54 L2TP [1] defines a general purpose mechanism for tunneling 55 PPP over various media. By design, it insulates L2TP 56 operation from the details of the media over which it 57 operates. The base protocol specification illustrates how 58 L2TP may be used in IP environments. This draft specifies 59 the encapsulation of L2TP over native Frame Relay and 60 addresses relevant issues. 62 2.0 Conventions 64 The following language conventions are used in the items 65 of specification in this document: 67 o MUST, SHALL, or MANDATORY -- This item is an 68 absolute requirement of the specification. 70 o SHOULD or RECOMMEND -- This item should generally 71 be followed for all but exceptional circumstances. 73 o MAY or OPTIONAL -- This item is truly optional and 74 may be followed or ignored according to the needs of 75 the implementor. 77 3.0 Problem Space Overview 79 In this section we describe in high level terms the scope 80 of the problem being addressed. 82 Topology: 83 +------+ +---------------+ | 84 | PSTN | | Frame Relay | | 85 User--| |----LAC ===| |=== LNS --+ LANs 86 | ISDN | | Cloud | | 87 +------+ +---------------+ | 89 L2TP Access Concentrator (LAC) is a device attached to the 90 switched network fabric (e.g. PSTN or ISDN) or co-located 91 with a PPP end system capable of handling the L2TP 92 protocol. The LAC need only implement the media over 93 which L2TP is to operate to pass traffic to one or more 94 LNS's. It may tunnel any protocol carried within PPP. 96 L2TP Network Server (LNS) operates on any platform capable 97 of PPP termination. The LNS handles the server side of 98 the L2TP protocol. L2TP is connection-oriented. The LNS 99 and LAC maintain state for each user that is attached to 100 an LAC. A session is created when an end-to-end PPP 101 connection is attempted between a user and the LNS. The 102 datagrams related to a session are sent over the tunnel 103 between the LAC and LNS. A tunnel is defined by an LNS- 104 LAC pair. The tunnel carries PPP datagrams between the 105 LAC and the LNS. 107 L2TP protocol operates at a level above the particular 108 media over which it is carried. However, some details of 109 its connection to media are required to permit 110 interoperable implementations. L2TP over IP/UDP is 111 described in the base draft [1]. Issues related to L2TP 112 over Frame Relay are addressed in later sections of this 113 draft. 115 4.0 Encapsulation and Packet Format 117 L2TP MUST be able to share a Frame Relay virtual circuit 118 (VC) with other protocols carried over the same VC. The 119 Frame Relay header format for data packet needs to be 120 defined to identify the protocol being carried in the 121 packets. The Frame Relay network MAY NOT understand these 122 formats. 124 All protocols over this circuit MUST encapsulate their 125 packets within a Q.922 frame. Additionally, frames MUST 126 contain information necessary to identify the protocol 127 carried within the frame relay Protocol Data Unit (PDU), 128 thus allowing the receiver to properly process the 129 incoming packet. 131 The frame format for L2TP is based on SNAP encapsulation 132 as defined in RFC 1490 [5] and FRF3.1 [2] . SNAP format 133 uses NLPID followed by Organizationally Unique Identifier 134 and a PID. 136 NLPID 138 The single octet identifier provides a mechanism to allow 139 easy protocol identification. For L2TP NLPID value 0x80 is 140 used which indicates the presence of SNAP header. 142 OUI & PID 144 The three-octet Organizationally Unique Identifier (OUI) 145 0x00-00-5E identifies IANA who administers the meaning of 146 the Protocol Identifier (PID) 0x0007. Together they 147 identify a distinct protocol. 149 Format of L2TP frames encapsulated in Frame Relay is given 150 in Figure 1. 152 Octet 1 2 153 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 1 | Q.922 Address | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 3 | Control 0x03 | pad 0 | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 5 | NLPID 0x80 | OUI 0x00 | 160 +-+-+-+-+-+-+-+-+ + 161 7 | OUI 0x00-5E | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 9 | PID 0x0007 | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | | 166 | L2TP packet | 167 | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | FCS | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1 Format for L2TP frames encapsulated in 172 Frame Relay 174 5.0 MTU Considerations 175 FRF.12 [4] is the Frame Relay Fragmentation Implementation 176 Agreement. If fragmentation is not supported, the two 177 Frame Relay endpoints MUST support an MTU size of at least 178 PPP Max-Receive-Unit size + PPP header size + Max L2TP 179 Header Size + Frame Relay header size (PPP header size is 180 the protocol field size plus HDLC framing bytes, which is 181 required by L2TP). 1500 + 64 is RECOMMENDED for default 182 PPP default MRU of 1500 to avoid packet discards on the 183 Frame Relay interface. The means to ensure these MTU 184 settings are left to implementation. 186 6.0 QOS Issues 188 In general, QoS mechanisms can be roughly provided for 189 with proprietary mechanisms localized within the LAC or 190 LNS. Interworking issues with various QoS implementations 191 is therefore at this time left as a topic for future 192 study. 194 7.0 Frame Relay and L2TP Interaction 196 In case of Frame Relay SVCs, connection setup will be 197 triggered when L2TP tries to create a tunnel. Details of 198 triggering mechanism are left to implementation. There 199 SHALL NOT be any change in Frame Relay SVC signaling due 200 to L2TP. The endpoints of the L2TP tunnel MUST be 201 identified by X.121/E.164 addresses in case of Frame Relay 202 SVC. These addresses MAY be obtained as tunnel endpoints 203 for a user as defined in [3]. In case of PVCs, the Virtual 204 Circuit to carry L2TP traffic MAY be configured 205 administratively. The endpoints of the tunnel MUST be 206 identified by DLCI, assigned to the PVC at configuration 207 time. This DLCI MAY be obtained as tunnel endpoints for a 208 user as defined in [3]. 210 There SHALL be no framing issues between PPP and Frame 211 Relay. PPP frames received by LAC from remote user are 212 stripped of CRC, link framing, and transparency bytes, 213 encapsulated in L2TP, and forwarded over Frame Relay 214 tunnel. 216 8.0 Security Considerations 218 Frame Relay, being a circuit-switched media, is typically 219 less pervious to security attacks [6]. If such attacks 220 become prevalent, it may be desirable to implement 221 additional security mechanisms. 223 Currently there is no standard specification for Frame 224 Relay security. The Frame Relay Forum is working on a 225 Frame Relay Privacy Agreement [6] which specifies 226 authentication, encryption, and key exchange facilities. 227 In light of this work, the issue of security will be re- 228 examined at a later date to see if L2TP over Frame Relay 229 specific protection mechanisms are still required. 230 Meanwhile, if stronger security mechanisms is required, 231 the use of IP as an intermediate transport layer with 232 IPsec for security is RECOMMENDED. 234 9.0 Acknowledgments 236 Ken Pierce (3Com Corporation) and (Rick Dynarski 3Com 237 Corporation) contributed to the editing of this document. 239 10.0 References 241 [1] Valencia et al., "Layer Two Tunneling Protocol 242 'L2TP'", Internet draft (work in progress), draft-ietf- 243 pppext-l2tp-12.txt, Nov, 1998. 245 [2] Multiprotocol Encapsulation Implementation Agreement, 246 FRF.3.1 , Frame Relay Forum Technical Committee, June 1995 248 [3] G. Zorn, D. Leifer, A. Rubens, J. Shriver. "RADIUS 249 Attributes for Tunnel Protocol Support." Internet draft 250 (work in progress), draft-ietf-radius-tunnel-auth-05.txt, 251 Microsoft, Ascend Communications, Shiva Corporation, 252 April 1998. 254 [4] Frame Relay Fragmentation Implemenation Agreement, 255 FRF.12, Frame Relay Forum Technical Committee, December 256 1997 258 [5] T. Bradley, C. Brown, A. Malis, "Multiprotocol 259 Interconnect over Frame Relay ", RFC 1490, July 1993 261 [6] B. Patel, B. Aboda. "Securing L2TP using IPSEC." 262 Internet draft (work in progress), draft-ietf-pppext-l2tp- 263 security-02.txt, Intel, Microsoft, May 1998 265 [7] Frame Relay Privacy Implementation Agreement, DRAFT, 266 Frame Relay Forum Technical Committee, June 1998 268 11.0 Author's Addresses 270 Vipin Rawat 271 Cisco Systems, Inc. 272 170 West Tasman Drive 273 San Jose CA 95134-1706 274 vrawat@cisco.com 276 Rene Tio 277 Redback Networks, Inc. 278 1389 Moffett Park Drive 279 Sunnyvale, CA 94089-1134 280 tor@cisco.com 282 Rohit Verma 283 3Com Corporation 284 1800 W. Central Road 285 Mount Prospect, IL 60056 286 Rohit_Verma@mw.3com.com