Network Working Group L. Xue Internet-Draft D. Guo Intended status: Standards Track Huawei Expires: January 5, 2015 July 4, 2014 Dynamic Stateless GRE Tunnel draft-xue-dhc-dynamic-gre-02 Abstract Generic Routing Encapsulation (GRE) is regarded as a popular encapsulation tunnel technology because of simpleness and easy implementation. When a node tries to encapsulate the user traffic in a GRE tunnel, it needs to first obtain the IP address of the destination node which need to decapsulate the GRE packets. In practice, the GRE tunnel destination IP address may be manually configured. This configuration introduces efficiency issues for operators, especially, in the scenarios where there are a large number entities need to deploy GRE tunnels. This work proposes an approach to configure the GRE information dynamiclly. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 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 January 5, 2015. Xue & Guo Expires January 5, 2015 [Page 1] Internet-Draft Dynamic Stateless GRE July 2014 Copyright Notice Copyright (c) 2014 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 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Dynamic GRE Tunnel . . . . . . . . . . . . . . . . . . . . . 4 5. DHCP Option Definition . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction Generic Routing Encapsulation (GRE) [RFC1701][RFC2784] is widely deployed in the operators' networks. When a node tries to encapuslate the user traffic in a GRE tunnel, it needs to first obtain the IP address of the destination node which can decapsulate the GRE packets. In practice, the decapsulation node IP address of GRE may be manually configured. This configuration introduces efficiency issues for operators, espeically, in the scenarios where there are large amount of GRE tunnels needed. This work describes a case about large amount of GRE tunnels deployment required and proposes a solution which extends Dynamic Host Configuration Protocol (DHCP) so as to enable to configure the GRE destination node IP address dynamically. Xue & Guo Expires January 5, 2015 [Page 2] Internet-Draft Dynamic Stateless GRE July 2014 2. Terminology The following terminologies are used in this document. 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 CPE equipment is the box that a provider may distribute to the customers, which could be Home Gateway (HG), Cable Modem (CM), etc. When CPE is using DHCP to obtain network address, CPE is acting as "DHCP Client" Network Facing Equipment (NPE) The NPE is the device to be deployed with the signalling and control functions. It is kind of Service Gateway. User Equipment (UE) The UE is the a device of the customers, which could be PC or Mobile Phone. User Facing Equipment (UPE) The UPE is the device to make forwarding decisions at the ingress of the provider network, which could be Cable Modem Termination Systems (CMTS). UPE is the "DHCP Server" or "DHCP relay agent" in DHCP framework. 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. Use Case Wireless Local Area Network (WLAN) has emerged as an important access technology for service operators. Some operators deploy a large number of WTPs in the specific environments with the dense crowd. In this scenario, WTPs are preferred to be managed and controlled in a centralized location by AC. The traffic of WTPs are generally handled on the access router of the network, which is a different Xue & Guo Expires January 5, 2015 [Page 3] Internet-Draft Dynamic Stateless GRE July 2014 node from AC. This architecture can avoid the overload for traffic management on the AC. This motivates the need for the WTP to support some tunnel encapsulation technologies to the Access Router. GRE is one of the preferred tunnel solution, because of simple and easy deployment reasons. Currently, several tunnel mechanisms have been standardized, for example Layer Two Tunneling Protocol version 3 (L2TPv3) [RFC3931]. L2TPv3 supports IP/UDP encapsulation and fulfills the tunnel requirements. However, as a multi-layers encapsulation protocol, L2TPv3 has to carry multiple protocol headers per data packet. It is complicated and costly, mostly used for Virtual Private Network (VPN). Most CPE devices are too simple to be a L2TPv3 initiator. An illustration of WLAN network is shown in figure 1. When WTP tries to encapsulate the user traffic in a GRE tunnel, it needs to first obtain the Access Router (AR) IP address. In practice, this IP address is usually deployed on WTP manually, which introduces efficiency issues for operators. Especially, a large number of WTPs are deployed with the dense crowd. CAPWAP +--------+ ++========+ AC | // +--------+ // +-----+// DATA Tunnel (GRE) +--------------+ | WTP |===========================| Access Router| +-----+ +--------------+ Figure 1: WLAN Illustration 4. Dynamic GRE Tunnel This work proposes an automatic solution which extends Dynamic Host Configuration Protocol (DHCP) so as to configure the GRE destination IP address. Due to successful IP address configuration, GRE tunnel can be setup dynamically. Figure 2 illustrates the procedure for dynamic GRE tunnel in WLAN network. The WTP, AR in the picture are respectively the CPE and NPE. Xue & Guo Expires January 5, 2015 [Page 4] Internet-Draft Dynamic Stateless GRE July 2014 / \ IPv4-x.x.x.x IPv4-y.y.y.y / \ / \ +-------+ +-------+ +-------+ / \ | | | | | | | | | | | UE +-----+ CPE +-------+ DHCP +------+ NPE +------+Internet \ / | | | | | | \ / \ / +-------+ +-------+ +-------+ \ / DHCP Client DHCP Server | | | | | |DHCPv4 Request | | | Preliminary + -------------> | | Phase | | | | (Discovery) | DHCPv4 Reply | | | + <-------------| | | | with y.y.y.y | | | | | | | *-------------------------------* |--------------+----User Packet-in-GRE-Encap.->| | Establishment*----with x.x.x.x -------------* | Phase | / \ | | | Tunnel Client | | | \ List Config. / | | | | Keepalive *-------------------------------* | Phase |<-------Keepalive Packet------>| | *-------------------------------* Figure 2: Dynamic GRE Tunnel in WLAN Network At Preliminary Phase, the CPE as one endpoint of GRE tunnel, may get information of NPE by the DHCP approach. CPE sends the DHCP request to initiate a IPv4 address request. When a DHCP server replies the CPE request message, the NPE information can be carried in a DHCP reply message via DHCP options. Thus CPE configures the NPE address y.y.y.y and tunnel parameter of GRE tunnel, such as GRE key etc if they are carried in the DHCP message. For load sharing or single- point failure recovery purposes, a DHCP reply message may carry information of more than one NPEs. Consequently, NPE can discover CPE via the received GRE encapsulated packet from CPE. Then the GRE tunnel information, such as IP address of CPE as source address is checked and restored as destination of GRE tunnel on NPE side. Generally, CPE can encapsulate UE's first packet with GRE, no matter data packet or control packet. For example, during a User Equipment (UE) subscriber attached initiates the DHCP procedure for an inner address, CPE should encapsulated this DHCP message via GRE. Xue & Guo Expires January 5, 2015 [Page 5] Internet-Draft Dynamic Stateless GRE July 2014 When NPE receives the packet with GRE encapsulation, it should look up the outer source IP of the packet in its tunnel client list. If it is a new client, the NPE adds source IP into the tunnel client list, decapsulates GRE header and deals with the packet encapsulated by GRE. There could be a keepalive mechanism for GRE tunnel between CPE and NPE. If there is neither keepalive packet nor data packet when the deployed timer expires, the NPE will tear down the tunnel and releases resource 5. DHCP Option Definition As introduced above, The DHCPv4 GRE Discovery (GD) Option is defined, when CPE wants to obtain an NPE address in IPv4 network. This Option is carried in DHCPv4. The DHCPv4 GD Option is structured as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Len | Ver |Reserved |Protocol Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cont. | NPE address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cont. | +---------------+ DHCPv4 GRE Discovery Option Code: TBD1 Len: The length of value field. If there are several instance for multiple NPE address considering redundancy, the length should be Len1 + Len2 + ... + Len n +Len of sub option in octets. Ver: The Version Number field which is contained in GRE header, defined in [RFC2784]. Reserved: This field is reserved for future use. A receiver MUST discard a packet where this field is non-zero. These bits MUST be sent as zero and MUST be ignored on receipt. Protocol Type: The Protocol Type field contains the protocol type of the payload packet. This field is defined in [RFC2784]. Xue & Guo Expires January 5, 2015 [Page 6] Internet-Draft Dynamic Stateless GRE July 2014 NPE Address: IPv4 address of NPE, the endpoint of GRE tunnel. Sub-Option (Optional): DHCPv4 GRE Key Suboption is structured in TLV style shown as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Len = 4 | GRE Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GRE Key (cont.) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DHCPv4 GRE Key Suboption Based on requirement defined in [RFC2784] [RFC2890], GRE Key Suboption is used in this document to configure the complementary tunnel information. GRE Key is generated from [RFC2890]. If the client receives the GRE Key suboption, the key MUST be inserted into the GRE encapsulation header. It is used for identifying extra context information about the received payload. The payload packets without the correspondent GRE Key or with an unmatched GRE Key will be silently dropped. Code 1 for GRE Key Suboption. Len (1 octet): The total octets of the suboption value field. Suboption Value : GRE Key according definition in [RFC2890]. The DHCPv6 GRE Discovery (GD) Option is mainly used when CPE wants to obtain an NPE address in IPv6 network. This option is carried in DHCPv6. According to [I-D.ietf-dhc-option-guidelines]The DHCPv6 GD Option is structured as follows. Xue & Guo Expires January 5, 2015 [Page 7] Internet-Draft Dynamic Stateless GRE July 2014 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ver |Reserved | Protocol Type | NPE IPv6 Add | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . NPE IPv6 Address (cont.) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cont. | +-+-+-+-+-+-+-+-+ DHCPv6 GRE Discovery Option Code: TBD2 Len: The length of the option value. Ver: The Version Number field which is contained in GRE header, defined in [RFC2784]. Reserved: This field is reserved for future use. A receiver MUST discard a packet where this field is non-zero. These bits MUST be sent as zero and MUST be ignored on receipt. Protocol Type: The Protocol Type field contains the protocol type of the payload packet. This field is defined in [RFC2784]. NPE Address: IPv6 address of NPE, the endpoint of GRE tunnel. Based on requirement defined in [RFC2784] [RFC2890], DHCPv6 GRE Key Option is used in this document to configure the complementary tunnel information. Optionally, the DHCPv6 GRE Key Option is encapsulated in DHCPv6 GRE Discovery Option. It is structured in TLV style shown as follows. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Len = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GRE Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DHCPv6 GRE Key Option Code 1 for DHCPv6 GRE Key Option: TBD3 Xue & Guo Expires January 5, 2015 [Page 8] Internet-Draft Dynamic Stateless GRE July 2014 Len (1 octet): The total octets of the option value field. Option Value : GRE Key according definition in [RFC2890]. 6. IANA Considerations TBD 7. References 7.1. Normative References [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [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. [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. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 7.2. Informative References [I-D.ietf-dhc-option-guidelines] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", draft-ietf-dhc-option-guidelines-17 (work in progress), January 2014. Authors' Addresses Xue & Guo Expires January 5, 2015 [Page 9] Internet-Draft Dynamic Stateless GRE July 2014 Li Xue Huawei No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,HaiDian District Beijing 100095 China Email: xueli@huawei.com Dayong Guo Huawei No.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,HaiDian District Beijing 100095 China Email: guoseu@huawei.com Xue & Guo Expires January 5, 2015 [Page 10]