idnits 2.17.1 draft-xue-dhc-dynamic-gre-03.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 305 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 (October 24, 2014) is 3472 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) ** Downref: Normative reference to an Informational RFC: RFC 1701 == Outdated reference: A later version (-12) exists of draft-ietf-opsawg-capwap-alt-tunnel-03 Summary: 2 errors (**), 0 flaws (~~), 4 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: April 27, 2015 October 24, 2014 7 Dynamic Stateless GRE Tunnel 8 draft-xue-dhc-dynamic-gre-03 10 Abstract 12 Generic Routing Encapsulation (GRE) is regarded as a popular 13 encapsulation tunnel technology. When a node tries to encapsulate 14 the user traffic in GRE, it needs the IP address of the destination 15 node which decapsulates the GRE packets. In practice, the GRE tunnel 16 destination IP address may be manually configured. This 17 configuration may introduce efficiency issues for operators. This 18 work proposes an approach to configure the GRE information 19 dynamically. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119] 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 27, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. GRE Use Case - WLAN Network . . . . . . . . . . . . . . . . . 3 64 4. DHCP Options Definition . . . . . . . . . . . . . . . . . . . 4 65 4.1. GRE Discovery DHCPv4 Option . . . . . . . . . . . . . . . 4 66 4.2. GRE Information DHCPv4 Option . . . . . . . . . . . . . . 5 67 4.3. GRE Discovery DHCPv6 Option . . . . . . . . . . . . . . . 5 68 4.4. GRE Information DHCPv6 Option . . . . . . . . . . . . . . 6 69 5. Dynamic GRE Tunnel . . . . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 73 7.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 Generic Routing Encapsulation (GRE, see [RFC1701] and [RFC2784]) is 79 widely deployed in the operators' networks. When a node tries to 80 encapsulate the user traffic in a GRE tunnel, it needs the IP address 81 of the destination node which can decapsulate the GRE packets. In 82 practice, the manual configuration happens on the nodes. This may 83 introduce efficiency issues for operators. As an example, if GRE 84 tunneling is used in the access network, there may a large amount of 85 configuration needed at the access side. This specification 86 introduces a use case requiring the deployment of a large amount of 87 GRE tunnels, which motivates a dynamic approach. The specification 88 proposes a solution to enable the dynamic discovery of the GRE 89 decapsulation device through use of a Dynamic Host Configuration 90 Protocol (DHCP) option. 92 2. Terminology 94 The following terms are used in this document: 96 Access Controller (AC): The network entity that provides Wireless 97 Termination Point (WTP) access to the network infrastructure in 98 the data plane, control plane, management plane, or a combination 99 therein. 101 Customer Premises Equipment (CPE): The box that a provider may 102 distribute to the customers. When CPE is using DHCP to obtain 103 network address, CPE is acting as "DHCP Client". 105 Wireless Termination Point (WTP): The physical or logical network 106 entity that contains an RF antenna and wireless physical layer 107 (PHY) to transmit and receive station traffic for wireless access 108 networks. 110 3. GRE Use Case - WLAN Network 112 Wireless Local Area Network (WLAN) has emerged as an important access 113 technology for service operators. A typical WLAN network contains a 114 large number of WTPs, centrally managed and controlled by the Access 115 Controller (AC). It is desirable to distribute customer data frames 116 to an endpoint through an Access Router (AR) different from the AC. 117 GRE encapsulation can be used between a WTP and an AR as one of the 118 optional tunneling technologies shown in 119 [I-D.ietf-opsawg-capwap-alt-tunnel]. 121 An illustration of a WLAN network is shown in Figure 1. In order for 122 a WTP to encapsulate the user traffic in a GRE tunnel, it needs to 123 know the Access Router (AR) IP address. This IP address is usually 124 deployed on WTPs manually, which may introduce efficiency issues for 125 operators. An AC may dynamically configure the WTP with the AR 126 address via extended CAPWAP message elements (see 127 [I-D.ietf-opsawg-capwap-alt-tunnel]). However, this approach does 128 not apply to a WLAN network where the CAPWAP protocol is not 129 deployed, as the network shown in Figure 2. In fact, it is quite 130 common for operators to have their own private control plane between 131 the WTP and the AC rather than CAPWAP. Moreover, there are also WLAN 132 deployments without AC, as in the FAT WTPs scenario (see Figure 3). 133 A general approach to resolve this problem is desirable. 135 CAPWAP +--------+ 136 ++========+ AC | 137 // +--------+ 138 // 139 +-----+// DATA Tunnel (GRE) +--------------+ 140 | WTP |===========================| Access Router| 141 +-----+ +--------------+ 143 Figure 1: GRE Use Case - WLAN Network 1 145 Private Control +--------+ 146 ++========+ AC | 147 // +--------+ 148 // 149 +-----+// DATA Tunnel (GRE) +--------------+ 150 | WTP |===========================| Access Router| 151 +-----+ +--------------+ 153 Figure 2: GRE Use Case - WLAN Network 2 155 +-----+ DATA Tunnel (GRE) +--------------+ 156 | WTP |===========================| Access Router| 157 +-----+ +--------------+ 159 Figure 3: GRE Use Case - WLAN Network 3 161 4. DHCP Options Definition 163 4.1. GRE Discovery DHCPv4 Option 165 The GRE Discovery DHCPv4 option provides to a GRE encapsulator a list 166 of one or more IPv4 addresses of a GRE decapsulator. According to 167 [RFC2131], the GRE Discovery DHCPv4 Option is structured as shown in 168 Figure 4. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Option Code | Option Len | AR IPv4 Address | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | AR IPv4 Address | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 4: GRE Discovery DHCPv4 Option 180 Code: TBD 182 Len: 4 184 AR IPv4 Address: AR IPv4 address, an endpoint of GRE tunnel. More 185 than one AR IPv4 addresses may be provided for redundancy reasons. 186 The default priority of the listed AR IPv4 addresses may be from 187 highest to lowest. 189 4.2. GRE Information DHCPv4 Option 191 The GRE Information DHCPv4 option provides a list of the GRE 192 information as defined in and [RFC2784][RFC2890]. The GRE 193 information may include the key. 195 According to [RFC2131], the GRE Information DHCPv4 Option is 196 structured as shown in Figure 5. 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Option Code | Option Len | GRE Key | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | GRE Key (cont.) | Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 5: GRE Information DHCPv4 Option 208 Code: TBD 210 Len: 6 212 GRE Key: The Key field contains a four octet number which is inserted 213 by the GRE encapsulator according to [RFC2890]. 215 Reserved: This field is reserved for future use. These bits MUST be 216 sent as zero and MUST be ignored on receipt. 218 4.3. GRE Discovery DHCPv6 Option 220 The GRE Discovery DHCPv6 option provides to a GRE encapsulator a list 221 of one or more IPv6 addresses of a GRE decapsulator. According to 222 [RFC7227], the GRE Discovery DHCPv6 Option is structured as shown in 223 Figure 6. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Option Code | Option Len | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 . AR IPv6 Address . 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 . AR IPv6 Address (Optional) . 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 6: DHCPv6 GRE Discovery Option 237 Code: TBD 239 Len: >=16 241 AR IPv6 Address: AR IPv6 address, an endpoint of GRE tunnel. More 242 than one AR IPv6 addresses may be provided for redundancy reasons. 243 The default priority of the listed AR IPv6 addresses may be from 244 highest to the lowest. 246 4.4. GRE Information DHCPv6 Option 248 The GRE Information DHCPv6 option provides a list of the GRE 249 information as defined in and [RFC2784][RFC2890]. The GRE 250 information may include the key. 252 According to [RFC7227], the GRE Information DHCPv6 Option is 253 structured as shown in Figure 7. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Option Code | Option Len | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | GRE Key | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Reserved | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 7: GRE Information DHCPv6 Option 267 Code: TBD 269 Len: 8 271 GRE Key: The Key field contains a four octet number which is inserted 272 by the GRE encapsulator according to [RFC2890]. 274 Reserved: This field is reserved for future use. These bits MUST be 275 sent as zero and MUST be ignored on receipt. 277 5. Dynamic GRE Tunnel 279 The DHCP options defined in Section 4 enable an automated way to 280 inform the GRE encapsulator with the GRE destination IP address. 281 Additionally, some other GRE tunnel information may be provided. In 282 this way, a GRE tunnel can be setup dynamically. 284 Figure 8 illustrates the procedure to set up a dynamic GRE tunnel in 285 the network. 287 / \ IPv4-x.x.x.x IPv4-y.y.y.y / \ 288 / \ +-------+ +-------+ +-------+ / \ 289 | | | | | | | | | | 290 | Host +-----+ CPE +-------+ DHCP +------+ AR +------+Internet 291 \ / | | | Server| | | \ / 292 \ / +-------+ +-------+ +-------+ \ / 293 DHCP Client DHCP Server 294 | | | | 295 | |DHCPv4 Request | | 296 | (1) + ------------->| | 297 | | | | 298 | | DHCPv4 Reply | | 299 | + <-------------| | 300 | | with y.y.y.y and information | 301 | (optional) | 302 | | | 303 | *-------------------------------* 304 |--------------+----User Packet-in-GRE-Encap.->| 305 | (2) *----with x.x.x.x -------------* 306 | | / \ 307 | | | Tunnel Client | 308 | | \ List Config. / 309 | | | 310 | *-------------------------------* 311 | (3) |<-------Keepalive Packet------>| 312 | *-------------------------------* 314 Figure 8: Dynamic GRE Tunnel 316 The steps to set up a GRE tunnel between the CPE and the AR are as 317 follows: 319 1. The CPE, as one endpoint of GRE tunnel, sends the DHCP request 320 message to the DHCP server to acquire the AR access. The GRE 321 Discovery DHCP Option should be included, with AR IPv4 address 322 set to zero. When the DHCP server receives this request, it 323 replies to the CPE the DHCP Reply message, containing the AR 324 address and the tunnel information if needed. 326 2. The CPE can encapsulate the upstream packets from the hosts 327 within GRE packets. Generally, upstream packets are either data 328 packets or control packets. When the AR gets an encapsulated GRE 329 packet, the AR checks whether there is an existing GRE tunnel 330 with the CPE. If this is a new endpoint without GRE record, the 331 AR should add this CPE into the tunnel client list. 333 3. A keepalive mechanism may be required for a GRE tunnel between 334 the CPE and the AR. If there is neither keepalive packet nor 335 data packet, when a keepalive timer expires, the AR or the CPE 336 will tear down the tunnel and release resources. 338 6. IANA Considerations 340 TBD 342 7. References 344 7.1. Normative References 346 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 347 Routing Encapsulation (GRE)", RFC 1701, October 1994. 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 353 2131, March 1997. 355 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 356 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 357 March 2000. 359 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 360 RFC 2890, September 2000. 362 [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and 363 S. Krishnan, "Guidelines for Creating New DHCPv6 Options", 364 BCP 187, RFC 7227, May 2014. 366 7.2. Informative References 368 [I-D.ietf-opsawg-capwap-alt-tunnel] 369 Zhang, R., Cao, Z., Deng, H., Pazhyannur, R., Gundavelli, 370 S., and L. Xue, "Alternate Tunnel Encapsulation for Data 371 Frames in CAPWAP", draft-ietf-opsawg-capwap-alt-tunnel-03 372 (work in progress), September 2014. 374 Authors' Addresses 376 Li Xue 377 Huawei 378 No. 156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan 379 Beijing, Haidian District 100095 380 China 382 Email: xueli@huawei.com 384 Dayong Guo 385 Huawei 386 No. 156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan 387 Beijing, Haidian District 100095 388 China 390 Email: guoseu@huawei.com