idnits 2.17.1 draft-jiang-intarea-dynamic-gre-01.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 202 has weird spacing: '...---with x.x.x...' -- The document date (November 24, 2015) is 3076 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-12) exists of draft-ietf-opsawg-capwap-alt-tunnel-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Jiang, Ed. 3 Internet-Draft D. Guo 4 Intended status: Standards Track Huawei Technologies Co., Ltd 5 Expires: May 27, 2016 L. Xue 6 November 24, 2015 8 Dynamic GRE Tunnel 9 draft-jiang-intarea-dynamic-gre-01 11 Abstract 13 Generic Routing Encapsulation (GRE) is regarded as a popular 14 encapsulation tunnel technology. When a node tries to encapsulate 15 the user traffic in GRE, it needs the IP address of the destination 16 node which decapsulates the GRE packets. In practice, the GRE tunnel 17 destination IP addresses are mainly configured manually. This 18 configuration mechanism causes efficiency issues for operators. This 19 document proposes an approach to configure the GRE information 20 dynamically. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 27, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language and Terminology . . . . . . . . . . . . 3 58 3. GRE Use Case - WLAN Network . . . . . . . . . . . . . . . . . 3 59 4. Dynamic GRE Tunnel Overview . . . . . . . . . . . . . . . . . 4 60 5. DHCP Options Definition . . . . . . . . . . . . . . . . . . . 6 61 5.1. DHCPv4 GRE Discovery Option . . . . . . . . . . . . . . . 6 62 5.2. DHCPv4 GRE Information Option . . . . . . . . . . . . . . 6 63 5.3. DHCPv6 GRE Discovery Option . . . . . . . . . . . . . . . 7 64 5.4. DHCPv6 GRE Information Option . . . . . . . . . . . . . . 8 65 6. DHCP/DHCPv6 server and client behaviors . . . . . . . . . . . 8 66 6.1. DHCP Server Behavior . . . . . . . . . . . . . . . . . . 8 67 6.2. DHCP Client Behavior . . . . . . . . . . . . . . . . . . 9 68 6.3. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 9 69 6.4. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 9 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 74 9.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Generic Routing Encapsulation (GRE, [RFC1701], [RFC2784]) is widely 80 deployed in the operators' networks. When a node tries to 81 encapsulate the user traffic in a GRE tunnel, it needs the IP address 82 of the destination node which decapsulates the GRE packets. 84 In practice, the GRE tunnel destination IP addresses are mainly 85 configured manually on the nodes. This configuration mechanism 86 causes efficiency issues for operators. As an example, when GRE 87 tunneling is used in the access network, there may a large amount of 88 configuration needed at the access side. Also, the configuration is 89 rigid. It may cause more issues in renumbering scenarios. 91 This document introduces a use case requiring the deployment of a 92 large amount of GRE tunnels, which motivates a dynamic approach. 93 This document proposes a solution to enable the dynamic discovery of 94 the GRE decapsulation device using Dynamic Host Configuration 95 Protocol (DHCP). 97 2. Requirements Language and Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in 102 [RFC2119] when they appear in ALL CAPS. When these words are not in 103 ALL CAPS (such as "should" or "Should"), they have their usual 104 English meanings, and are not to be interpreted as [RFC2119] key 105 words. 107 Access Controller (AC) The network entity that provides Wireless 108 Termination Point (WTP) access to the network infrastructure in 109 the data plane, control plane, management plane, or a combination 110 therein. 112 Customer Premises Equipment (CPE) The box that a provider may 113 distribute to the customers. When CPE is using DHCP to obtain 114 network address, CPE is acting as "DHCP Client". 116 Wireless Termination Point (WTP) The physical or logical network 117 entity that contains an RF antenna and wireless physical layer 118 (PHY) to transmit and receive station traffic for wireless access 119 networks. 121 3. GRE Use Case - WLAN Network 123 Wireless Local Area Network (WLAN) has emerged as an important access 124 technology for service operators. A typical WLAN network contains a 125 large number of WTPs, centrally managed and controlled by the Access 126 Controller (AC). It is desirable to distribute customer data frames 127 to an endpoint through an Access Router (AR) different from the AC. 128 GRE encapsulation can be used between a WTP and an AR as one of the 129 optional tunneling technologies shown in 130 [I-D.ietf-opsawg-capwap-alt-tunnel] 132 An illustration of a WLAN network is shown in Figure 1. In order for 133 a WTP to encapsulate the user traffic in a GRE tunnel, it needs to 134 know the Access Router (AR) IP address. This IP address is usually 135 configured on WTPs manually. An AC may dynamically configure the WTP 136 with the AR address via extended CAPWAP message elements (see 137 [I-D.ietf-opsawg-capwap-alt-tunnel]). 139 CAPWAP +--------+ 140 ++========+ AC | 141 // +--------+ 142 // 143 +-----+// DATA Tunnel (GRE) +--------------+ 144 | WTP |===========================| Access Router| 145 +-----+ +--------------+ 147 Figure 1: GRE Use Case - WLAN Network 1 149 However, this approach does not apply to a WLAN network where the 150 CAPWAP protocol is not deployed, as the network shown in Figure 2. 151 In fact, it is quite common for operators to have their own private 152 control plane between the WTP and the AC rather than CAPWAP. 154 Private Control +--------+ 155 ++========+ AC | 156 // +--------+ 157 // 158 +-----+// DATA Tunnel (GRE) +--------------+ 159 | WTP |===========================| Access Router| 160 +-----+ +--------------+ 162 Figure 2: GRE Use Case - WLAN Network 2 164 Moreover, there are also WLAN deployments without AC, as in the fat 165 WTPs scenario (see Figure 3). A general approach to resolve this 166 problem is desirable. 168 +-----+ DATA Tunnel (GRE) +--------------+ 169 | WTP |===========================| Access Router| 170 +-----+ +--------------+ 172 Figure 3: GRE Use Case - WLAN Network 3 174 4. Dynamic GRE Tunnel Overview 176 The DHCP options defined in Section 5 enable an automated way to 177 inform the GRE encapsulator with the GRE destination IP address. 178 Additionally, some other GRE tunnel information may be provided. In 179 this way, a GRE tunnel can be setup dynamically. 181 Figure 4 illustrates the procedure to set up a dynamic GRE tunnel in 182 the network (only in IPv4 network scenario). 184 / \ IPv4-x.x.x.x IPv4-y.y.y.y / \ 185 / \ +-------+ +-------+ +-------+ / \ 186 | | | | | | | | | | 187 | Host +------+ CPE +-------+ DHCP +------+ AR +------+Internet 188 \ / | | | Server| | | \ / 189 \ / +-------+ +-------+ +-------+ \ / 190 DHCP Client DHCP Server 191 | | | | 192 | | DHCPREQUEST | | 193 | (1) + ------------->| | 194 | | | | 195 | | DHCPACK | | 196 | + <-------------| | 197 | | with y.y.y.y and | 198 |information (optional) | 199 | | | 200 | *-------------------------------* 201 |<-User Packet->+<---User Packet-in-GRE-Encap.->| 202 | (2) *----with x.x.x.x -------------* 203 | | / \ 204 | | | Tunnel Client | 205 | | \ List Config. / 206 | | | 207 | *-------------------------------* 208 | (3) |<-------Keepalive Packet------>| 209 | *-------------------------------* 211 Figure 4: Dynamic GRE Tunnel 213 The steps to set up a GRE tunnel between the CPE and the AR are as 214 follows: 216 1. The CPE, as one endpoint of GRE tunnel, sends the DHCPREQUEST 217 message to the DHCP server to acquire the AR access. The GRE 218 DHCP Option should be included in Parameter List Option, as 219 defined in Section 6.2. When the DHCP server receives this 220 request, it replies to the CPE the DHCPACK message, containing 221 the AR address and the tunnel information if needed. 223 2. The CPE can encapsulate the upstream packets from the hosts 224 within GRE tunnel packets. Generally, upstream packets are 225 either data packets or control packets. When the AR gets an 226 encapsulated GRE tunnel packet, the AR checks whether there is an 227 existing GRE tunnel with the CPE. If this is a new endpoint 228 without GRE record, the AR should add this CPE into the tunnel 229 client list. This would be mainly used for the correspondent 230 downstream packets. 232 3. A keepalive mechanism may be required for a GRE tunnel between 233 the CPE and the AR. If there is neither keepalive packet nor 234 data packet, when a keepalive timer expires, the AR or the CPE 235 will tear down the tunnel and release resources. 237 5. DHCP Options Definition 239 This section defines the new DHCPv4 and DHCPv6 options that support 240 the Dynamic stateless GRE tunnel. 242 5.1. DHCPv4 GRE Discovery Option 244 The DHCPv4 GRE Discovery option provides to a GRE encapsulator a list 245 of one or more IPv4 addresses of a GRE decapsulator. According to 246 [RFC2131], the DHCPv4 GRE Discovery Option is structured as shown in 247 Figure 5. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Option Code | Option Len | AR IPv4 Address | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | AR IPv4 Address | AR IPv4 Address (optional) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 5: DHCPv4 GRE Discovery Option 259 option-code OPTION_V4_GRE_DISCOVERY (TBA1). 261 option-len 4 + 4*n (in octets). 263 AR IPv4 Address AR IPv4 address, an endpoint of GRE tunnel. More than 264 one AR IPv4 addresses may be provided for redundancy 265 reasons. The default priority of the listed AR IPv4 266 addresses may be from highest to lowest. 268 5.2. DHCPv4 GRE Information Option 270 The DHCPv4 GRE Information option provides a list of the GRE 271 information as defined in and [RFC2784][RFC2890]. The GRE 272 information may include the key. According to [RFC2131], the DHCPv4 273 GRE Information Option is structured as shown in Figure 6. 275 0 1 2 3 276 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 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 | Option Code | Option Len | GRE Key | 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 | GRE Key (cont.) | Reserved | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 Figure 6: DHCPv4 GRE Information Option 285 option-code OPTION_V4_GRE_INFO (TBA2). 287 option-len 6 (in octets). 289 GRE Key The Key field contains a four octet number which is 290 inserted by the GRE encapsulator according to [RFC2890]. 292 Reserved This field is reserved for future use. These bits MUST 293 be sent as zero and MUST be ignored on receipt. 295 5.3. DHCPv6 GRE Discovery Option 297 The DHCPv6 GRE Discovery option provides to a GRE encapsulator a list 298 of one or more IPv6 addresses of a GRE decapsulator. According to 299 [RFC7227], the DHCPv6 GRE Discovery Option is structured as shown in 300 Figure 7. 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Option Code | Option Len | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 . AR IPv6 Address . 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 . AR IPv6 Address (Optional) . 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 Figure 7: DHCPv6 GRE Discovery Option 314 option-code OPTION_V6_GRE_DISCOVERY (TBA3). 316 option-len 16 + 16*n (in octets). 318 AR IPv4 Address AR IPv64 address(es), an endpoint of GRE tunnel. 319 More than one AR IPv6 addresses may be provided for 320 redundancy reasons. The default priority of the listed 321 AR IPv6 addresses may be from highest to lowest. 323 5.4. DHCPv6 GRE Information Option 325 The DHCPv6 GRE Information option provides a list of the GRE 326 information as defined in and [RFC2784][RFC2890]. The GRE 327 information may include the key. 329 According to [RFC7227], the DHCPv6 GRE Information Option is 330 structured as shown in Figure 8. 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Option Code | Option Len | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | GRE Key | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Reserved | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 8: DHCPv6 GRE Information Option 344 option-code OPTION_V6_GRE_INFO (TBA4). 346 option-len 8 (in octets). 348 GRE Key The Key field contains a four octet number which is 349 inserted by the GRE encapsulator according to [RFC2890]. 351 Reserved This field is reserved for future use. These bits MUST 352 be sent as zero and MUST be ignored on receipt. 354 6. DHCP/DHCPv6 server and client behaviors 356 This section defines the DHCP/DHCPv6 server and client behaviors 357 during the procedure of configure GRE options. 359 6.1. DHCP Server Behavior 361 Section 3.5 of [RFC2131] describes how a DHCP client and server 362 negotiate configuration values using the Parameter List (55) option 363 [RFC2132]. By default, a server will not reply with a GRE option if 364 the client has not explicitly enumerated one in its Parameter List 365 option. 367 6.2. DHCP Client Behavior 369 A WTP/CPE acting as DHCP client will request DHCP GRE configuration 370 parameters from the DHCP server located in the IPv4 network. Such a 371 client MUST request the DHCP GRE option(s) that it is configured for 372 in Parameter List option in its DHCPDISCOVER, DHCPREQUEST, or 373 DHCPINFORM messages. 375 The client SHOULD use the received GRE destination address and 376 information to establish GRE tunnels. 378 6.3. DHCPv6 Server Behavior 380 Section 17.2.2 of [RFC3315] describes how a DHCPv6 client and server 381 negotiate configuration values using the Option Request (6) 382 Option[RFC3315]. By default, a server will not reply with a GRE 383 option if the client has not explicitly enumerated one in its ORO. 385 6.4. DHCPv6 Client Behavior 387 A WTP/CPE acting as DHCPv6 client will request DHCPv6 GRE 388 configuration parameters from the DHCPv6 server located in the IPv6 389 network. Such a client MUST request the GRE option(s) that it is 390 configured for in its ORO in SOLICIT, REQUEST, RENEW, REBIND or 391 INFORMATION-REQUEST messages. 393 The client SHOULD use the received GRE destination address and 394 information to establish GRE tunnels. 396 7. Security Considerations 398 Section 23 of [RFC3315] discusses DHCPv6-related security issues. As 399 with all DHCPv6-derived configuration state, it is possible that 400 configuration is actually being delivered by a third party (Man In 401 The Middle). As such, there is no basis on which access over the 402 stateless GRE tunnel can be trusted. Therefore, the stateless GRE 403 tunnel should not bypass any security mechanisms such as IP firewalls 404 or user authentication. 406 8. IANA Considerations 408 This document defines two new DHCPv4 [RFC2131] options. The IANA is 409 requested to assign values for these four options from the DHCPv4 410 Option Codes table of the DHCPv4 Parameters registry maintained in 411 http://www.iana.org/assignments/bootp-dhcp-parameters. The four 412 options are: 414 The GRE Discovery Option (TBA1), described in Section 5.1. 416 The GRE Information Option (TBA2), described in Section 5.2. 418 This document defines three new DHCPv6 [RFC3315] options. The IANA 419 is requested to assign values for these three options from the DHCPv6 420 Option Codes table of the DHCPv6 Parameters registry maintained in 421 http://www.iana.org/assignments/dhcpv6-parameters. The three options 422 are: 424 The GRE Discovery Option (TBA3), described in Section 5.3. 426 The GRE Information Option (TBA4), described in described in 427 Section 5.4. 429 9. References 431 9.1. Normative References 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", BCP 14, RFC 2119, 435 DOI 10.17487/RFC2119, March 1997, 436 . 438 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 439 RFC 2131, DOI 10.17487/RFC2131, March 1997, 440 . 442 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 443 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 444 . 446 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 447 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 448 DOI 10.17487/RFC2784, March 2000, 449 . 451 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 452 RFC 2890, DOI 10.17487/RFC2890, September 2000, 453 . 455 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 456 C., and M. Carney, "Dynamic Host Configuration Protocol 457 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 458 2003, . 460 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 461 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 462 BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, 463 . 465 9.2. Informative References 467 [I-D.ietf-opsawg-capwap-alt-tunnel] 468 Zhang, R., Cao, Z., Hui, D., Pazhyannur, R., Gundavelli, 469 S., Xue, L., and J. You, "Alternate Tunnel Encapsulation 470 for Data Frames in CAPWAP", draft-ietf-opsawg-capwap-alt- 471 tunnel-06 (work in progress), October 2015. 473 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 474 Routing Encapsulation (GRE)", RFC 1701, 475 DOI 10.17487/RFC1701, October 1994, 476 . 478 Authors' Addresses 480 Sheng Jiang (editor) 481 Huawei Technologies Co., Ltd 482 Q14, Huawei Campus, No.156 Beiqing Road 483 Hai-Dian District, Beijing, 100095 484 CN 486 Email: jiangsheng@huawei.com 488 Dayong Guo 489 Huawei Technologies Co., Ltd 490 Q14, Huawei Campus, No.156 Beiqing Road, Hai-Dian District 491 Beijing, 100095 492 China 494 Email: guoseu@huawei.com 496 Li Xue 498 Email: xueli_jas@163.com