Network Working Group L. Xue Internet-Draft D. Guo Intended status: Standards Track Huawei Expires: August 18, 2014 February 14, 2014 Dynamic Stateless GRE Tunnel draft-xue-dhc-dynamic-gre-01 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 some destination node to decapsulate the GRE packets. According to the information of destination node, a node can setup the GRE tunnel connection. In practice, the IP address of decapsulation node of GRE tunnel may be manually configured on the GRE encapsulation side. This configuration introduces efficiency issues for operators, especially, in the scenarios where there are large amount of GRE tunnels needed. This work proposes an approach to configure the GRE tunnel dynamically. 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 August 18, 2014. Xue & Guo Expires August 18, 2014 [Page 1] Internet-Draft Dynamic Stateless GRE February 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 . . . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 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 encapsulate the user traffic in a GRE tunnel, it needs to first obtain the IP address of some destination node to decapsulate the GRE packets. According to the information of destination node, a node can setup the GRE tunnel connection. In practice, the IP address of decapsulation node of GRE may be manually configured on the GRE encapsulation node. This configuration introduces efficiency issues for operators, especially, in the scenarios where there are large amount of GRE tunnels needed. This work describes a case about large amount of GRE tunnels deployment requirement and proposes a solution which extends Dynamic Host Configuration Protocol (DHCP) so as to enable an encapsulate node of GRE tunnel to be configured the IP address of the destination node. Xue & Guo Expires August 18, 2014 [Page 2] Internet-Draft Dynamic Stateless GRE February 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 gateway of the network, which is a different node from Xue & Guo Expires August 18, 2014 [Page 3] Internet-Draft Dynamic Stateless GRE February 2014 AC. This architecture can avoid the overload for traffic management on the AC. Further, the lawful intercepting of user traffic is needed on the access router. This motivates the need for the WTP to support some tunnel encapsulation technologies where the data tunnelled from the WTP are terminated at an AR. 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. In this scenario, providers prefer an candidate tunnel encapsulation (i.e.,GRE) with simple and easy implementation. 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 IP address of the destination node (AR) to decapsulate the GRE packets. According to the IP address of AR, CPE can then setup the GRE tunnel to AR. CAPWAP +--------+ ++========+ AC | // +--------+ // +-----+// DATA Tunnel (GRE) +--------------+ | WTP |===========================| Access Router| +-----+ +--------------+ Figure 1: WLAN Illustration In practice, GRE encapsulation node generally be configured with the destination IP address manually. This configuration introduces efficiency issues for operators, especially, in the scenarios a large number of WTPs are deployed with the dense crowd. As a result, there will be huge manual configuration work on the WTPs in the network, which could be costly for operators and could introduce enormous management costs. 4. Dynamic GRE Tunnel This work proposes a solution which extends Dynamic Host Configuration Protocol (DHCP) so as to enable an encapsulate node of GRE tunnel to be configured the IP address of the destination node. Based on the IP address configured phase, GRE tunnel can be setup accordingly. Xue & Guo Expires August 18, 2014 [Page 4] Internet-Draft Dynamic Stateless GRE February 2014 Figure 2 illustrates the procedure for dynamic GRE tunnel in WLAN network. The WTP, AR in the picture are respectively the CPE and NPE. / \ 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 may send 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 parameters of tunnel, such as IP address of CPE as source address may be checked and restored as destination of GRE tunnel on NPE. The GRE encapsulated packet used could be data Xue & Guo Expires August 18, 2014 [Page 5] Internet-Draft Dynamic Stateless GRE February 2014 packet or control packet. Generally, CPE can encapsulate UE's first packet with GRE. For example, during a User Equipment (UE) subscriber attached initiates the DHCP procedure for an inner address, CPE should encapsulated this DHCP message from UE via GRE. 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/v6 GRE Discovery (GD) Option is defined, when NPE sends the its IPv4/6 address to CPE in IPv4/6 network for GRE tunnel between CPE and NPE. This Option is carried in DHCPv4/v6 Reply message. According to [I-D.ietf-dhc-option-guidelines], the DHCPv4/6 GD Option and the DHCPv4/6 GRE Key Suboption are 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]. Xue & Guo Expires August 18, 2014 [Page 6] Internet-Draft Dynamic Stateless GRE February 2014 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: IPv4 address of NPE, the endpoint of GRE tunnel. Sub-Option (Optional): DHCPv4 GRE Key Suboption is structured in TLV style shown as follows. It is used to configure the complementary information of a GRE tunnel according to [RFC2784] and [RFC2890]. If the CPE receives suboption, the key MUST be inserted into the GRE encapsulation header. The GRE Key is used for identifying extra context information about the received payload. On the decapsulate node NPE, the GRE packets without the correspondent GRE Key or with an unmatched GRE Key will be dropped silently. 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 In IPv6 network,the DHCPv6 GRE Discovery (GD) Option and the DHCPv6 GRE Key Option are defined accordingly. 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 Xue & Guo Expires August 18, 2014 [Page 7] Internet-Draft Dynamic Stateless GRE February 2014 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. 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 Len (1 octet): The total octets of the option value field. Option Value : GRE Key defined in [RFC2890]. 6. IANA Considerations 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. Xue & Guo Expires August 18, 2014 [Page 8] Internet-Draft Dynamic Stateless GRE February 2014 [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 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 August 18, 2014 [Page 9]