idnits 2.17.00 (12 Aug 2021) /tmp/idnits5908/draft-vasavada-l2tpext-es-svctype-00.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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 4) being 62 lines 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. ** The abstract seems to contain references ([L2TPST], [RFC1661], [L2TPDS], [RFC2661], [ESP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (July 2001) is 7615 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: 'TBD' is mentioned on line 103, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TPST' -- Possible downref: Non-RFC (?) normative reference: ref. 'ESP' -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TPDS' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Nishit Vasavada 2 INTERNET DRAFT Amber Networks, Inc. 4 July 2001 6 Encapsulation Services Protocol Service Type for L2TP 7 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 2. Abstract 32 The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard 33 method for tunneling PPP [RFC1661] packets. In accordance with the 34 L2TP Service Type specification [L2TPST], this document provides a 35 solution for transporting Encapsulation Services Protocol (ESP) [ESP] 36 over L2TP. It uses [L2TPDS] for providing DS support to the L2TP 37 control and ESP packets. 39 3. Specification of Requirements 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC 2119 [RFC2119]. 45 4. Introduction 47 The Layer Two Tunneling Protocol (L2TP) [RFC2661] provides a standard 48 method for tunneling PPP [RFC1661] packets. The L2TP Service Type 49 [L2TPST] allows layer 1 and layer 2 traffic to be tunneled through an 50 L2TP tunnel. 52 This document presents a solution to carry the ESP traffic over the 53 IP network through the features offered by L2TP and the Service Type 54 attribute. 56 It talks about the use of [RFC2661] and [L2TPST] for setting up an 57 L2TP tunnel and session containing ESP traffic, and use of [L2TPDS] 58 for signaling DS values for the L2TP control and payload traffic. It 59 also introduces a new AVP - End-Identifier - to convey the end 60 identifiers to the peer. 62 5. ESP Service Type 64 An ESP Service Type value of [TBD] MUST be used. The encoding of the 65 Service Type AVP remains as specified in [L2TPST]. 67 6. Tunnel Establishment 69 The basic tunnel establishment procedures defined in [RFC2661] and 70 [L2TPST] are followed. Following are additional requirements: 72 6.1. Service Capabilities 74 For supporting ESP in a tunnel, the ESP Service Type value [TBD] MUST 75 be included in the Service Capabilities List AVP. 77 [L2TPST] allows multiple services to be carried in different sessions 78 inside a single L2TP tunnel. However, ESP requires that if a tunnel 79 were to carry ESP traffic, all sessions within the tunnel be carrying 80 ESP sessions. To accommodate this requirement, if ESP is present in 81 the Service Capabilities AVP, the sender MUST NOT put any other 82 service type in the Service Capabilities AVP. If a service other 83 than ESP is also present in the Service Capabilities AVP carrying ESP 84 service type, and if the receiving L2TP peer supports ESP, it 85 MUST tear down the tunnel. 87 Since ESP is the exclusive service on ESP such a tunnel (i.e., PPP is 88 not supported on this tunnel), the M-bit of Service Capabilities AVP 89 MUST be set. 91 6.2 Control Connection DS (CCDS) AVP 93 If a DS value is made available to L2TP for the tunnel, L2TP MUST use 94 this AVP. 96 7. Session Establishment 98 The basic call establishment procedures defined in [RFC2661] and 99 [L2TPST] remain unchanged. 101 7.1. Service Type AVP 103 The ESP Service Type value [TBD] MUST be used in the Service Type AVP 104 of an ICRQ or OCRQ of each session within the tunnel. 106 7.2. Session DS (SDS) AVP 108 If a DS value is made available to L2TP for the tunnel, L2TP MUST use 109 this AVP and use the same value as that for the CCDS AVP while 110 setting up the tunnel. 112 7.3. End-Identifier AVP (ICRQ, OCRQ) 114 ES needs to convey the end-identifiers on both sides to the remote 115 side while setting up a session. We introduce a new AVP - 116 End-Identifier AVP - for this purpose. 118 The End-Identifier AVP is encoded as follows: 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 |1|H| rsvd | Length | 4741 | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | 1 | Attribute Value... 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 [until Length is reached]... | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 Vendor ID = 4741 for Amber Networks 131 Attribute = 1 133 The attribute value contains interface and other optional information 134 depending on the access link type that ESP is encapsulating. For 135 example, if the ESP is carrying FR payload, the additional 136 information would DLCI numbers on both ends. No additional 137 information is present for TDM circuits. 139 The attribute value may be a simple ASCII string. For example, a 140 source interface serial 1/1 and DLCI 100, and a destination interface 141 serial 1/1 with DLCI 200 could be represented as "serial 1/1 DLCI 142 100, serial 1/1 DLCI 200". The format of the information contained 143 in this AVP should be agreed on by the administrators at the two L2TP 144 peers. 146 When employing the End-Identifier AVP for this purpose, the AVP is 147 mandatory (the M-bit MUST be set to 1). The AVP MAY be hidden (the 148 H-bit set to 0 or 1). 150 7.2. ESP Payload Message Format 152 The L2TP payload header format defined in [RFC2661] remains unchanged 153 while carrying data for an ESP session. Entire ESP PDU will be 154 carried. 156 The encapsulated ESP PDU looks like this: 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Tunnel ID | Session ID | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Ns (opt) | Nr (opt) | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Offset Size (opt) | Offset pad... (opt) 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | ES Header 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | ES control message/Payload... 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 As is true for the PPP traffic carried by L2TP, the frame size should 181 consider the MTU and the additional headers to avoid IP 182 fragmentation. 184 8. Effects on Standard AVPs 186 If ESP PDUs are being tunneled in accordance with this document, 187 the following Call Management AVPs MAY be ignored: 189 Bearer Type 190 Framing Type 191 Called Number 192 Calling Number 193 Sub-Address 194 Initial Received LCP CONFREQ 195 Last Sent LCP CONFREQ 196 Last Received LCP CONFREQ 197 Proxy Authen Type 198 Proxy Authen Name 199 Proxy Authen Challenge 200 Proxy Authen ID 201 Proxy Authen Response 202 ACCM 204 9. Security Considerations 206 All the underlying L2TP Security considerations remain, though no 207 'new' ones are introduced? 209 10. IANA Considerations 211 Need to obtain a value for ES Service Type from IANA. 213 11. Acknowledgments 215 Many thanks to Harisankar Mallath for helping in reviewing this 216 draft. 218 12. References 220 [RFC2661] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", RFC 221 2661, February 1999. 223 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 224 RFC 1661, July 1994. 226 [L2TPST] McPherson D., Nanji S., "L2TP Service Type", Work in 227 Progress, April 2001. 229 [ESP] Vasavada, N., "ESP: Encapsulation Services Protocol", Work in 230 Progress, July 2001. 232 [L2TPDS] Calhoun, P., et. al., "L2TP Differentiated Services 233 Extension", Work in Progress, March 2001. 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", RFC 2119, March 1997. 238 14. Author's Address 240 Nishit Vasavada 241 Amber Networks, Inc. 242 48664 Milmont Drive 243 Fremont, CA 94538 244 Phone: +1 510.687.5200 245 Email: nishit@ambernetworks.com