Network Working Group S. Jiang, Ed. Internet-Draft D. Guo Intended status: Standards Track Huawei Technologies Co., Ltd Expires: November 27, 2015 L. Xue May 26, 2015 Dynamic GRE Tunnel draft-jiang-intarea-dynamic-gre-00 Abstract Generic Routing Encapsulation (GRE) is regarded as a popular encapsulation tunnel technology. When a node tries to encapsulate the user traffic in GRE, it needs the IP address of the destination node which decapsulates the GRE packets. In practice, the GRE tunnel destination IP addresses are mainly configured manually. This configuration mechanism causes efficiency issues for operators. This document proposes an approach to configure the GRE information dynamically. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 27, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Jiang, et al. Expires November 27, 2015 [Page 1] Internet-Draft Dynamic GRE May 2015 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language and Terminology . . . . . . . . . . . . 3 3. GRE Use Case - WLAN Network . . . . . . . . . . . . . . . . . 3 4. Dynamic GRE Tunnel Overview . . . . . . . . . . . . . . . . . 4 5. DHCP Options Definition . . . . . . . . . . . . . . . . . . . 6 5.1. DHCPv4 GRE Discovery Option . . . . . . . . . . . . . . . 6 5.2. DHCPv4 GRE Information Option . . . . . . . . . . . . . . 6 5.3. DHCPv6 GRE Discovery Option . . . . . . . . . . . . . . . 7 5.4. DHCPv6 GRE Information Option . . . . . . . . . . . . . . 8 6. DHCP/DHCPv6 server and client behaviors . . . . . . . . . . . 8 6.1. DHCP Server Behavior . . . . . . . . . . . . . . . . . . 8 6.2. DHCP Client Behavior . . . . . . . . . . . . . . . . . . 9 6.3. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . 9 6.4. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Generic Routing Encapsulation (GRE, [RFC1701], [RFC2784]) is widely deployed in the operators' networks. When a node tries to encapsulate the user traffic in a GRE tunnel, it needs the IP address of the destination node which decapsulates the GRE packets. In practice, the GRE tunnel destination IP addresses are mainly configured manually on the nodes. This configuration mechanism causes efficiency issues for operators. As an example, when GRE tunneling is used in the access network, there may a large amount of configuration needed at the access side. Also, the configuration is rigid. It may cause more issues in renumbering scenarios. This document introduces a use case requiring the deployment of a large amount of GRE tunnels, which motivates a dynamic approach. This document proposes a solution to enable the dynamic discovery of the GRE decapsulation device using Dynamic Host Configuration Protocol (DHCP). Jiang, et al. Expires November 27, 2015 [Page 2] Internet-Draft Dynamic GRE May 2015 2. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS. When these words are not in ALL CAPS (such as "should" or "Should"), they have their usual English meanings, and are not to be interpreted as [RFC2119] key words. Access Controller (AC) The network entity that provides Wireless Termination Point (WTP) access to the network infrastructure in the data plane, control plane, management plane, or a combination therein. Customer Premises Equipment (CPE) The box that a provider may distribute to the customers. When CPE is using DHCP to obtain network address, CPE is acting as "DHCP Client". Wireless Termination Point (WTP) The physical or logical network entity that contains an RF antenna and wireless physical layer (PHY) to transmit and receive station traffic for wireless access networks. 3. GRE Use Case - WLAN Network Wireless Local Area Network (WLAN) has emerged as an important access technology for service operators. A typical WLAN network contains a large number of WTPs, centrally managed and controlled by the Access Controller (AC). It is desirable to distribute customer data frames to an endpoint through an Access Router (AR) different from the AC. GRE encapsulation can be used between a WTP and an AR as one of the optional tunneling technologies shown in [I-D.ietf-opsawg-capwap-alt-tunnel] An illustration of a WLAN network is shown in Figure 1. In order for a WTP to encapsulate the user traffic in a GRE tunnel, it needs to know the Access Router (AR) IP address. This IP address is usually configured on WTPs manually. An AC may dynamically configure the WTP with the AR address via extended CAPWAP message elements (see [I-D.ietf-opsawg-capwap-alt-tunnel]). Jiang, et al. Expires November 27, 2015 [Page 3] Internet-Draft Dynamic GRE May 2015 CAPWAP +--------+ ++========+ AC | // +--------+ // +-----+// DATA Tunnel (GRE) +--------------+ | WTP |===========================| Access Router| +-----+ +--------------+ Figure 1: GRE Use Case - WLAN Network 1 However, this approach does not apply to a WLAN network where the CAPWAP protocol is not deployed, as the network shown in Figure 2. In fact, it is quite common for operators to have their own private control plane between the WTP and the AC rather than CAPWAP. Private Control +--------+ ++========+ AC | // +--------+ // +-----+// DATA Tunnel (GRE) +--------------+ | WTP |===========================| Access Router| +-----+ +--------------+ Figure 2: GRE Use Case - WLAN Network 2 Moreover, there are also WLAN deployments without AC, as in the fat WTPs scenario (see Figure 3). A general approach to resolve this problem is desirable. +-----+ DATA Tunnel (GRE) +--------------+ | WTP |===========================| Access Router| +-----+ +--------------+ Figure 3: GRE Use Case - WLAN Network 3 4. Dynamic GRE Tunnel Overview The DHCP options defined in Section 5 enable an automated way to inform the GRE encapsulator with the GRE destination IP address. Additionally, some other GRE tunnel information may be provided. In this way, a GRE tunnel can be setup dynamically. Figure 4 illustrates the procedure to set up a dynamic GRE tunnel in the network (only in IPv4 netweork scenario). Jiang, et al. Expires November 27, 2015 [Page 4] Internet-Draft Dynamic GRE May 2015 / \ IPv4-x.x.x.x IPv4-y.y.y.y / \ / \ +-------+ +-------+ +-------+ / \ | | | | | | | | | | | Host +------+ CPE +-------+ DHCP +------+ AR +------+Internet \ / | | | Server| | | \ / \ / +-------+ +-------+ +-------+ \ / DHCP Client DHCP Server | | | | | | DHCPREQUEST | | | (1) + ------------->| | | | | | | | DHCPACK | | | + <-------------| | | | with y.y.y.y and | |information (optional) | | | | | *-------------------------------* |<-User Packet->+<---User Packet-in-GRE-Encap.->| | (2) *----with x.x.x.x -------------* | | / \ | | | Tunnel Client | | | \ List Config. / | | | | *-------------------------------* | (3) |<-------Keepalive Packet------>| | *-------------------------------* Figure 4: Dynamic GRE Tunnel The steps to set up a GRE tunnel between the CPE and the AR are as follows: 1. The CPE, as one endpoint of GRE tunnel, sends the DHCPREQUEST message to the DHCP server to acquire the AR access. The GRE DHCP Option should be included in Parameter List Option, as defined in Section 6.2. When the DHCP server receives this request, it replies to the CPE the DHCPACK message, containing the AR address and the tunnel information if needed. 2. The CPE can encapsulate the upstream packets from the hosts within GRE tunnel packets. Generally, upstream packets are either data packets or control packets. When the AR gets an encapsulated GRE tunnel packet, the AR checks whether there is an existing GRE tunnel with the CPE. If this is a new endpoint without GRE record, the AR should add this CPE into the tunnel client list. This would be mainly used for the correspondent downstream packets. Jiang, et al. Expires November 27, 2015 [Page 5] Internet-Draft Dynamic GRE May 2015 3. A keepalive mechanism may be required for a GRE tunnel between the CPE and the AR. If there is neither keepalive packet nor data packet, when a keepalive timer expires, the AR or the CPE will tear down the tunnel and release resources. 5. DHCP Options Definition This section defines the new DHCPv4 and DHCPv6 options that support the Dynamic stateless GRE tunnel. 5.1. DHCPv4 GRE Discovery Option The DHCPv4 GRE Discovery option provides to a GRE encapsulator a list of one or more IPv4 addresses of a GRE decapsulator. According to [RFC2131], the DHCPv4 GRE Discovery Option is structured as shown in Figure 5. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Option Len | AR IPv4 Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AR IPv4 Address | AR IPv4 Address (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: DHCPv4 GRE Discovery Option option-code OPTION_V4_GRE_DISCOVERY (TBA1). option-len 4 + 4*n (in octets). AR IPv4 Address AR IPv4 address, an endpoint of GRE tunnel. More than one AR IPv4 addresses may be provided for redundancy reasons. The default priority of the listed AR IPv4 addresses may be from highest to lowest. 5.2. DHCPv4 GRE Information Option The DHCPv4 GRE Information option provides a list of the GRE information as defined in and [RFC2784][RFC2890]. The GRE information may include the key. According to [RFC2131], the DHCPv4 GRE Information Option is structured as shown in Figure 6. Jiang, et al. Expires November 27, 2015 [Page 6] Internet-Draft Dynamic GRE May 2015 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Option Len | GRE Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GRE Key (cont.) | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: DHCPv4 GRE Information Option option-code OPTION_V4_GRE_INFO (TBA2). option-len 6 (in octets). GRE Key The Key field contains a four octet number which is inserted by the GRE encapsulator according to [RFC2890]. Reserved This field is reserved for future use. These bits MUST be sent as zero and MUST be ignored on receipt. 5.3. DHCPv6 GRE Discovery Option The DHCPv6 GRE Discovery option provides to a GRE encapsulator a list of one or more IPv6 addresses of a GRE decapsulator. According to [RFC7227], the DHCPv6 GRE Discovery Option is structured as shown in Figure 7. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Option Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . AR IPv6 Address . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . AR IPv6 Address (Optional) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: DHCPv6 GRE Discovery Option option-code OPTION_V6_GRE_DISCOVERY (TBA3). option-len 16 + 16*n (in octets). AR IPv4 Address AR IPv64 address(es), an endpoint of GRE tunnel. More than one AR IPv6 addresses may be provided for redundancy reasons. The default priority of the listed AR IPv6 addresses may be from highest to lowest. Jiang, et al. Expires November 27, 2015 [Page 7] Internet-Draft Dynamic GRE May 2015 5.4. DHCPv6 GRE Information Option The DHCPv6 GRE Information option provides a list of the GRE information as defined in and [RFC2784][RFC2890]. The GRE information may include the key. According to [RFC7227], the DHCPv6 GRE Information Option is structured as shown in Figure 8. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Code | Option Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GRE Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: DHCPv6 GRE Information Option option-code OPTION_V6_GRE_INFO (TBA4). option-len 8 (in octets). GRE Key The Key field contains a four octet number which is inserted by the GRE encapsulator according to [RFC2890]. Reserved This field is reserved for future use. These bits MUST be sent as zero and MUST be ignored on receipt. 6. DHCP/DHCPv6 server and client behaviors This section defines the DHCP/DHCPv6 server and client behaviors during the procedure of configure GRE options. 6.1. DHCP Server Behavior Section 3.5 of [RFC2131] describes how a DHCP client and server negotiate configuration values using the Parameter List (55) option [RFC2132]. By default, a server will not reply with a GRE option if the client has not explicitly enumerated one in its Parameter List option. Jiang, et al. Expires November 27, 2015 [Page 8] Internet-Draft Dynamic GRE May 2015 6.2. DHCP Client Behavior A WTP/CPE acting as DHCP client will request DHCP GRE configuration parameters from the DHCP server located in the IPv4 network. Such a client MUST request the DHCP GRE option(s) that it is configured for in Parameter List option in its DHCPDISCOVER, DHCPREQUEST, or DHCPINFORM messages. The client SHOULD use the received GRE destination address and information to establish GRE tunnels. 6.3. DHCPv6 Server Behavior Section 17.2.2 of [RFC3315] describes how a DHCPv6 client and server negotiate configuration values using the Option Request (6) Option[RFC3315]. By default, a server will not reply with a GRE option if the client has not explicitly enumerated one in its ORO. 6.4. DHCPv6 Client Behavior A WTP/CPE acting as DHCPv6 client will request DHCPv6 GRE configuration parameters from the DHCPv6 server located in the IPv6 network. Such a client MUST request the GRE option(s) that it is configured for in its ORO in SOLICIT, REQUEST, RENEW, REBIND or INFORMATION-REQUEST messages. The client SHOULD use the received GRE destination address and information to establish GRE tunnels. 7. Security Considerations Section 23 of [RFC3315] discusses DHCPv6-related security issues. As with all DHCPv6-derived configuration state, it is possible that configuration is actually being delivered by a third party (Man In The Middle). As such, there is no basis on which access over the stateless GRE tunnel can be trusted. Therefore, the stateless GRE tunnel should not bypass any security mechanisms such as IP firewalls or user authentication. 8. IANA Considerations This document defines two new DHCPv4 [RFC2131] options. The IANA is requested to assign values for these four options from the DHCPv4 Option Codes table of the DHCPv4 Parameters registry maintained in http://www.iana.org/assignments/bootp-dhcp-parameters. The four options are: The GRE Discovery Option (TBA1), described in Section 5.1. Jiang, et al. Expires November 27, 2015 [Page 9] Internet-Draft Dynamic GRE May 2015 The GRE Information Option (TBA2), described in Section 5.2. This document defines three new DHCPv6 [RFC3315] options. The IANA is requested to assign values for these three options from the DHCPv6 Option Codes table of the DHCPv6 Parameters registry maintained in http://www.iana.org/assignments/dhcpv6-parameters. The three options are: The GRE Discovery Option (TBA3), described in Section 5.3. The GRE Information Option (TBA4), described in described in Section 5.4. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, May 2014. 9.2. Informative References [I-D.ietf-opsawg-capwap-alt-tunnel] Zhang, R., Cao, Z., Deng, H., Pazhyannur, R., Gundavelli, S., and L. Xue, "Alternate Tunnel Encapsulation for Data Frames in CAPWAP", draft-ietf-opsawg-capwap-alt-tunnel-05 (work in progress), April 2015. Jiang, et al. Expires November 27, 2015 [Page 10] Internet-Draft Dynamic GRE May 2015 [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. Authors' Addresses Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 CN Email: jiangsheng@huawei.com Dayong Guo Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road, Hai-Dian District Beijing, 100095 China Email: guoseu@huawei.com Li Xue Email: xueli_jas@163.com Jiang, et al. Expires November 27, 2015 [Page 11]