idnits 2.17.1 draft-xue-dhc-dynamic-gre-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 198 has weird spacing: '...---with x.x.x...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 4, 2014) is 3583 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: 'RFC2131' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 385, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-dhc-option-guidelines' is defined on line 394, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1701 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Xue 3 Internet-Draft D. Guo 4 Intended status: Standards Track Huawei 5 Expires: January 5, 2015 July 4, 2014 7 Dynamic Stateless GRE Tunnel 8 draft-xue-dhc-dynamic-gre-02 10 Abstract 12 Generic Routing Encapsulation (GRE) is regarded as a popular 13 encapsulation tunnel technology because of simpleness and easy 14 implementation. When a node tries to encapsulate the user traffic in 15 a GRE tunnel, it needs to first obtain the IP address of the 16 destination node which need to decapsulate the GRE packets. In 17 practice, the GRE tunnel destination IP address may be manually 18 configured. This configuration introduces efficiency issues for 19 operators, especially, in the scenarios where there are a large 20 number entities need to deploy GRE tunnels. This work proposes an 21 approach to configure the GRE information dynamiclly. 23 Requirements Language 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in [RFC2119] 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 5, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 4. Dynamic GRE Tunnel . . . . . . . . . . . . . . . . . . . . . 4 67 5. DHCP Option Definition . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 71 7.2. Informative References . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 Generic Routing Encapsulation (GRE) [RFC1701][RFC2784] is widely 77 deployed in the operators' networks. When a node tries to 78 encapuslate the user traffic in a GRE tunnel, it needs to first 79 obtain the IP address of the destination node which can decapsulate 80 the GRE packets. 82 In practice, the decapsulation node IP address of GRE may be manually 83 configured. This configuration introduces efficiency issues for 84 operators, espeically, in the scenarios where there are large amount 85 of GRE tunnels needed. This work describes a case about large amount 86 of GRE tunnels deployment required and proposes a solution which 87 extends Dynamic Host Configuration Protocol (DHCP) so as to enable to 88 configure the GRE destination node IP address dynamically. 90 2. Terminology 92 The following terminologies are used in this document. 94 Access Controller (AC) 96 The network entity that provides Wireless Termination Point (WTP) 97 access to the network infrastructure in the data plane, control 98 plane, management plane, or a combination therein. 100 Customer Premises Equipment (CPE) 102 The CPE equipment is the box that a provider may distribute to the 103 customers, which could be Home Gateway (HG), Cable Modem (CM), etc. 104 When CPE is using DHCP to obtain network address, CPE is acting as 105 "DHCP Client" 107 Network Facing Equipment (NPE) 109 The NPE is the device to be deployed with the signalling and control 110 functions. It is kind of Service Gateway. 112 User Equipment (UE) 114 The UE is the a device of the customers, which could be PC or Mobile 115 Phone. 117 User Facing Equipment (UPE) 119 The UPE is the device to make forwarding decisions at the ingress of 120 the provider network, which could be Cable Modem Termination Systems 121 (CMTS). UPE is the "DHCP Server" or "DHCP relay agent" in DHCP 122 framework. 124 Wireless Termination Point (WTP) 126 The physical or logical network entity that contains an RF antenna 127 and wireless physical layer (PHY) to transmit and receive station 128 traffic for wireless access networks. 130 3. Use Case 132 Wireless Local Area Network (WLAN) has emerged as an important access 133 technology for service operators. Some operators deploy a large 134 number of WTPs in the specific environments with the dense crowd. In 135 this scenario, WTPs are preferred to be managed and controlled in a 136 centralized location by AC. The traffic of WTPs are generally 137 handled on the access router of the network, which is a different 138 node from AC. This architecture can avoid the overload for traffic 139 management on the AC. This motivates the need for the WTP to support 140 some tunnel encapsulation technologies to the Access Router. GRE is 141 one of the preferred tunnel solution, because of simple and easy 142 deployment reasons. 144 Currently, several tunnel mechanisms have been standardized, for 145 example Layer Two Tunneling Protocol version 3 (L2TPv3) [RFC3931]. 146 L2TPv3 supports IP/UDP encapsulation and fulfills the tunnel 147 requirements. However, as a multi-layers encapsulation protocol, 148 L2TPv3 has to carry multiple protocol headers per data packet. It is 149 complicated and costly, mostly used for Virtual Private Network 150 (VPN). Most CPE devices are too simple to be a L2TPv3 initiator. 152 An illustration of WLAN network is shown in figure 1. When WTP tries 153 to encapsulate the user traffic in a GRE tunnel, it needs to first 154 obtain the Access Router (AR) IP address. In practice, this IP 155 address is usually deployed on WTP manually, which introduces 156 efficiency issues for operators. Especially, a large number of WTPs 157 are deployed with the dense crowd. 159 CAPWAP +--------+ 160 ++========+ AC | 161 // +--------+ 162 // 163 +-----+// DATA Tunnel (GRE) +--------------+ 164 | WTP |===========================| Access Router| 165 +-----+ +--------------+ 167 Figure 1: WLAN Illustration 169 4. Dynamic GRE Tunnel 171 This work proposes an automatic solution which extends Dynamic Host 172 Configuration Protocol (DHCP) so as to configure the GRE destination 173 IP address. Due to successful IP address configuration, GRE tunnel 174 can be setup dynamically. 176 Figure 2 illustrates the procedure for dynamic GRE tunnel in WLAN 177 network. The WTP, AR in the picture are respectively the CPE and 178 NPE. 180 / \ IPv4-x.x.x.x IPv4-y.y.y.y / \ 181 / \ +-------+ +-------+ +-------+ / \ 182 | | | | | | | | | | 183 | UE +-----+ CPE +-------+ DHCP +------+ NPE +------+Internet 184 \ / | | | | | | \ / 185 \ / +-------+ +-------+ +-------+ \ / 186 DHCP Client DHCP Server 187 | | | | 188 | |DHCPv4 Request | | 189 | Preliminary + -------------> | 190 | Phase | | | 191 | (Discovery) | DHCPv4 Reply | | 192 | + <-------------| | 193 | | with y.y.y.y | | 194 | 195 | | | 196 | *-------------------------------* 197 |--------------+----User Packet-in-GRE-Encap.->| 198 | Establishment*----with x.x.x.x -------------* 199 | Phase | / \ 200 | | | Tunnel Client | 201 | | \ List Config. / 202 | | | 203 | Keepalive *-------------------------------* 204 | Phase |<-------Keepalive Packet------>| 205 | *-------------------------------* 207 Figure 2: Dynamic GRE Tunnel in WLAN Network 209 At Preliminary Phase, the CPE as one endpoint of GRE tunnel, may get 210 information of NPE by the DHCP approach. CPE sends the DHCP request 211 to initiate a IPv4 address request. When a DHCP server replies the 212 CPE request message, the NPE information can be carried in a DHCP 213 reply message via DHCP options. Thus CPE configures the NPE address 214 y.y.y.y and tunnel parameter of GRE tunnel, such as GRE key etc if 215 they are carried in the DHCP message. For load sharing or single- 216 point failure recovery purposes, a DHCP reply message may carry 217 information of more than one NPEs. 219 Consequently, NPE can discover CPE via the received GRE encapsulated 220 packet from CPE. Then the GRE tunnel information, such as IP address 221 of CPE as source address is checked and restored as destination of 222 GRE tunnel on NPE side. Generally, CPE can encapsulate UE's first 223 packet with GRE, no matter data packet or control packet. For 224 example, during a User Equipment (UE) subscriber attached initiates 225 the DHCP procedure for an inner address, CPE should encapsulated this 226 DHCP message via GRE. 228 When NPE receives the packet with GRE encapsulation, it should look 229 up the outer source IP of the packet in its tunnel client list. If 230 it is a new client, the NPE adds source IP into the tunnel client 231 list, decapsulates GRE header and deals with the packet encapsulated 232 by GRE. 234 There could be a keepalive mechanism for GRE tunnel between CPE and 235 NPE. If there is neither keepalive packet nor data packet when the 236 deployed timer expires, the NPE will tear down the tunnel and 237 releases resource 239 5. DHCP Option Definition 241 As introduced above, The DHCPv4 GRE Discovery (GD) Option is defined, 242 when CPE wants to obtain an NPE address in IPv4 network. This Option 243 is carried in DHCPv4. 245 The DHCPv4 GD Option is structured as follows: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Code | Len | Ver |Reserved |Protocol Type | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | cont. | NPE address | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | cont. | 255 +---------------+ 257 DHCPv4 GRE Discovery Option 259 Code: TBD1 261 Len: The length of value field. If there are several instance for 262 multiple NPE address considering redundancy, the length should be 263 Len1 + Len2 + ... + Len n +Len of sub option in octets. 265 Ver: The Version Number field which is contained in GRE header, 266 defined in [RFC2784]. 268 Reserved: This field is reserved for future use. A receiver MUST 269 discard a packet where this field is non-zero. These bits MUST be 270 sent as zero and MUST be ignored on receipt. 272 Protocol Type: The Protocol Type field contains the protocol type of 273 the payload packet. This field is defined in [RFC2784]. 275 NPE Address: IPv4 address of NPE, the endpoint of GRE tunnel. 277 Sub-Option (Optional): DHCPv4 GRE Key Suboption is structured in TLV 278 style shown as follows. 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Type = 1 | Len = 4 | GRE Key | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | GRE Key (cont.) | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 DHCPv4 GRE Key Suboption 290 Based on requirement defined in [RFC2784] [RFC2890], GRE Key 291 Suboption is used in this document to configure the complementary 292 tunnel information. GRE Key is generated from [RFC2890]. If the 293 client receives the GRE Key suboption, the key MUST be inserted into 294 the GRE encapsulation header. It is used for identifying extra 295 context information about the received payload. The payload packets 296 without the correspondent GRE Key or with an unmatched GRE Key will 297 be silently dropped. 299 Code 1 for GRE Key Suboption. 301 Len (1 octet): The total octets of the suboption value field. 303 Suboption Value : GRE Key according definition in [RFC2890]. 305 The DHCPv6 GRE Discovery (GD) Option is mainly used when CPE wants to 306 obtain an NPE address in IPv6 network. This option is carried in 307 DHCPv6. According to [I-D.ietf-dhc-option-guidelines]The DHCPv6 GD 308 Option is structured as follows. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Code | Len | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Ver |Reserved | Protocol Type | NPE IPv6 Add | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 . NPE IPv6 Address (cont.) . 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | cont. | 320 +-+-+-+-+-+-+-+-+ 322 DHCPv6 GRE Discovery Option 324 Code: TBD2 326 Len: The length of the option value. 328 Ver: The Version Number field which is contained in GRE header, 329 defined in [RFC2784]. 331 Reserved: This field is reserved for future use. A receiver MUST 332 discard a packet where this field is non-zero. These bits MUST be 333 sent as zero and MUST be ignored on receipt. 335 Protocol Type: The Protocol Type field contains the protocol type of 336 the payload packet. This field is defined in [RFC2784]. 338 NPE Address: IPv6 address of NPE, the endpoint of GRE tunnel. 340 Based on requirement defined in [RFC2784] [RFC2890], DHCPv6 GRE Key 341 Option is used in this document to configure the complementary tunnel 342 information. Optionally, the DHCPv6 GRE Key Option is encapsulated 343 in DHCPv6 GRE Discovery Option. It is structured in TLV style shown 344 as follows. 346 0 1 2 3 347 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 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Code | Len = 4 | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | GRE Key | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 DHCPv6 GRE Key Option 356 Code 1 for DHCPv6 GRE Key Option: TBD3 357 Len (1 octet): The total octets of the option value field. 359 Option Value : GRE Key according definition in [RFC2890]. 361 6. IANA Considerations 363 TBD 365 7. References 367 7.1. Normative References 369 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 370 Routing Encapsulation (GRE)", RFC 1701, October 1994. 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 375 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 376 2131, March 1997. 378 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 379 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 380 March 2000. 382 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 383 RFC 2890, September 2000. 385 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 386 and M. Carney, "Dynamic Host Configuration Protocol for 387 IPv6 (DHCPv6)", RFC 3315, July 2003. 389 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 390 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 392 7.2. Informative References 394 [I-D.ietf-dhc-option-guidelines] 395 Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 396 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 397 draft-ietf-dhc-option-guidelines-17 (work in progress), 398 January 2014. 400 Authors' Addresses 401 Li Xue 402 Huawei 403 No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,HaiDian District 404 Beijing 100095 405 China 407 Email: xueli@huawei.com 409 Dayong Guo 410 Huawei 411 No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,HaiDian District 412 Beijing 100095 413 China 415 Email: guoseu@huawei.com