Network Working Group L. Xue Internet-Draft D. Guo Intended status: Standards Track Huawei Expires: January 10, 2014 July 09, 2013 Dynamic Stateless GRE tunnel draft-xue-dhc-dynamic-gre-00 Abstract Specifically, WiFi has emerged as an important access technology for Multiple Service Operator (MSO) and mobile service provider. For mobile service provider, WiFi is preferred as a trusted access technology for service. It has became important to provide simple transition method expected for service via WiFi access. For example, tunnelling on the customer side aims at conveying WiFi service between a hotspot and the Service Gateway. GRE tunnel is an increasingly popular encapsulation choice because of simple encapsulation and easy implementation, especially in aforementioned environments. However, manual configuration is not suitable if there are large numbers of the end-points of GRE tunnels. This document proposes a dynamic-configured stateless GRE tunnel, which does not modify encapsulation format of GRE, but adds signaling for tunnel parameters discovery, such as address, GRE key etc. 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 10, 2014. Xue & Guo Expires January 10, 2014 [Page 1] Internet-Draft Dynamic Stateless GRE July 2013 Copyright Notice Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Dynamic Stateless GRE Tunnel . . . . . . . . . . . . . . . . 4 3.1. Preliminary Phase . . . . . . . . . . . . . . . . . . . . 4 3.1.1. NPE discovery on CPE . . . . . . . . . . . . . . . . 5 3.1.2. CPE discovery on NPE . . . . . . . . . . . . . . . . 5 3.2. Establishment Phase . . . . . . . . . . . . . . . . . . . 6 3.3. Keepalive Phase . . . . . . . . . . . . . . . . . . . . . 6 4. DHCP Option Definition . . . . . . . . . . . . . . . . . . . 6 5. Application of Dynamic Stateless GRE Tunnel . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Generic Routing Encapsulation (GRE) tunnel[RFC1701][RFC2784] is widely deployed in the ISP networks. There are several general scenarios that many access devices set up GRE tunnels to a concentrator network equipment for public or private services. In this document, the tunnel endpoint may be Customer Premises Equipment (CPE), i.e., a home gateway or an access point, and a network concentrator equipment, i.e., a Service Gateway which is kind of Network Facing PE (NPE). Specifically, WiFi has emerged as an important access technology for Multiple Service Operator (MSO) and mobile service provider. For mobile service provider, WiFi is preferred as a trusted access technology for private service. It has became important to provide simple transition method expected for service via WiFi access. For Xue & Guo Expires January 10, 2014 [Page 2] Internet-Draft Dynamic Stateless GRE July 2013 example, tunnelling on the customer side aims at conveying WiFi service. A tunnel is thus defined in this scenario as the connection between the end-point at the cable modem or hotspot, and the other end-point at the Service Gateway. 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 Customer Premises Equipment (CPE), such as cable modem or hotspot is too simple to be a L2TPv3 initiator. In most scenarios, providers do not need such a complicated transition method. GRE tunnel is an increasingly popular encapsulation choice because of simple encapsulation and easy implementation, especially in aforementioned environments. An illustration about GRE tunnel deployment in MSO network is shown in the following figure. +-----+ +-----+ +-----+ | | GRE Tunnel | | | | | +-------------+-----+-----------+ | | +-------------+-----+-----------+ | | | | | | | +-----+ +-----+ +-----+ CPE UPE NPE Figure 1: An Illustration about GRE Tunnel Deployment However, up to now, GRE tunnels are stateless and configured manually. Manual configuration is not suitable if there are large numbers of CPEs, i.e., Cable Modems (CMs) or hotspots, which are the end-points of GRE tunnels. This document proposes a dynamic- configured stateless GRE tunnel, which does not modify encapsulation format of GRE, but adds signaling for tunnel parameters discovery, such as address, GRE key, etc[RFC2890]. In addition, this document extends Dynamic Host Configuration Protocol (DHCP) for IPv4 [RFC2131]or DHCP for IPv6 [RFC3315], so that Customer Premises Equipment (CPE) can automatically acquire the Network Premises Equipment (NPE) address. Then the stateless GRE will be setup dynamically. Additionally, the discovery process may also support load-sharing and recovery from a single point of failure. Xue & Guo Expires January 10, 2014 [Page 3] Internet-Draft Dynamic Stateless GRE July 2013 In the absence of DHCP, PPP, Router Advertisements or CAPWAP could be used for GRE tunnel discovery automatically, but this document does not discuss these methods in detail. 2. Terminology The following terminologies are used in this document. User Equipment (UE) The UE is the a device of the subscriber, which could be PC or Mobile Phone. Customer Premises Equipment (CPE) The CPE equipment is the box that a provider places with the customer, 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" User Facing Equipment (UPE) The UPE is the device to which the functions needs to take forwarding or switching 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", when CPE is using DHCP to obtain network address. Network Facing Equipment (NPE) The NPE is the device to which the signalling and control functions are allocated. It is kind of Service Gateway. 3. Dynamic Stateless GRE Tunnel Stateless Dynamic GRE tunnel mechanism enables the tunnel endpoints can discovery each other dynamically at first. Based on this preliminary discovery phase, GRE tunnel will be setup accordingly. The process is described in the following sub-sections. 3.1. Preliminary Phase Xue & Guo Expires January 10, 2014 [Page 4] Internet-Draft Dynamic Stateless GRE July 2013 3.1.1. NPE discovery on CPE Before tunneling to NPE,CPE MUST get the NPE address and other tunnel parameters such as GRE Key, Version, Protocol Type[RFC2784][RFC2890] if required. The information may be configured on the CPE. However, manual configurations are difficult to operate when there are large number of CPEs. A new mechanism is required to enable the access point in the access network to discover the information of the concentrator automatically. It is proposed to extend DHCPv4 or DHCPv6 for discovery. In order to support NPE discovery on CPE, new DHCP GRE Discovery (GD) Options are defined respectively for DHCPv4 and DHCPv6. They have the identical structure apart from address length. The form is defined in Section 4. When a DHCP server answers a CPE request message, the NPE information can be carried in a DHCP reply message via DHCP options. Thus CPE configures the NPE address and tunnel parameter of GRE tunnel, such as GRE key etc if they are carried in the DHCP message. Details are descried in Section 3. DHCP server decides to attach GD option based on policy. One choice is to respond only if the client requests the GD option; another is to append it to every reply no matter the client requests it or not. For load sharing or single-point failure recovery purposes, a DHCP reply message may carry information of more than one NPEs. 3.1.2. CPE discovery on NPE Normally, GRE encapsulated packet should be received by NPE. In this case,NPE should recognize that this is a GRE packet. 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, additionally, GRE Key, GRE Version, Protocol Type. The GRE encapsulated packet used could be data 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. The destination IP of outer layer header in GRE encapsulation can be obtained as description of section 2.1.1. The outer source IP uses the IP address of the CPE. Xue & Guo Expires January 10, 2014 [Page 5] Internet-Draft Dynamic Stateless GRE July 2013 Consequently, NPE can discover CPE via the received GRE encapsulated packet from CPE. 3.2. Establishment Phase As the description in aforementioned section, in order to set up the dynamic tunnel, tunnel endpoints are required to discover each other. After the Preliminary Phase, GRE tunnel can be setup subsequently. 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. For example, if NPE recognizes the packet is the DHCP message from UE for address request after decapsulating GRE header. Then the NPE can records the assigned UE's address, which is the inner address of GRE encapsulated packet. The tunnel client list records the information of all tunnel clients. Each entry of the list describes information of a tunnel, includes the mapping of the inner address of tunnel and the outer IP of client. Based on transmission method over GRE, the inner address is UE's IP address when IP over GRE, or MAC address when Eth over GRE. For inbound traffic, NPE checks the tunnel client list according to destination address of the packet and decides which tunnel the traffic should be forwarded to. 3.3. Keepalive Phase 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. 4. DHCP Option Definition The DHCPv4 GRE Discovery (GD) Option is mainly used 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 | NPE Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cont. | Sub-Options (Optional)| Xue & Guo Expires January 10, 2014 [Page 6] Internet-Draft Dynamic Stateless GRE July 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | cont. | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DHCPv4 GRE Discovery Option Code: TBD1 Len: The length of total option. If there are several instance for multiple NPE address considering redundancy, the length should be Len1 + Len2 + ... + Len n +Len of sub options in octets. NPE Address: IPv4 address of NPE, the endpoint of GRE tunnel. Sub-Options (Optional): The sub-options are 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub Code | Sub Len | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . Suboption Value (Variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DHCP Sub-option Based on requirement defined in [RFC2784] [RFC2890], following sub- options are used in this document to configure the complementary tunnel information. Sub Code (1 octet) o GRE Key Sub-option: Sub code = 1 o GRE Version Sub-option: Sub code = 2 o GRE Protocol Sub-option: Sub code =3 Sub length (1 octet): The total octets of the suboption value field Suboption Value (variable): encodings of the value field depend on the suboption type as enumerated above, according definition in [RFC2890]. Xue & Guo Expires January 10, 2014 [Page 7] Internet-Draft Dynamic Stateless GRE July 2013 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. Considering redundancy, more than one GD Options can be carried in DHCPv6 message. The DHCPv6 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ . NPE Address . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Sub-option . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ DHCPv6 GRE Discovery Option Code: TBD1 Len: The length of total option. NPE Address: IPv6 address of NPE, the endpoint of GRE tunnel. Sub-Options (Optional): The sub-options are structured in TLV style. They are consistent with the sub-options defined in DHCPv4 GD option. 5. Application of Dynamic Stateless GRE Tunnel Figure 2 illustrates the procedure for dynamic stateless GRE tunnel in MSO WLAN network. The CM, CMTS and SG in the picture are respectively the CPE, UPE and NPE. / \ IPv4-x.x.x.x IPv4-y.y.y.y / \ / \ +-------+ +-------+ +-------+ / \ | | | CM | | CMTS | | SG | | | | UE +-----+ (CPE) +-------+ (UPE) +------+ (NPE) +------+Internet \ / | | | | | | \ / \ / +-------+ +-------+ +-------+ \ / DHCP Client DHCP Server | | | | | |DHCPv4 Request | | | Preliminay + ------------->| | | Phase | | | | (Discovery) | DHCPv4 Reply | | | + <-------------| | | | with y.y.y.y | | | Xue & Guo Expires January 10, 2014 [Page 8] Internet-Draft Dynamic Stateless GRE July 2013 | | | | *-------------------------------* |--------------+----User Packet-in-GRE-Encap.->| | Establishment*----with x.x.x.x -------------* | Phase | / \ | | | Tunnel Client | | | \ List Config. / | | | | Keepalive *-------------------------------* | Phase |<-------KeepAlive Packet------>| | *-------------------------------* Figure 2: Dynamic Stateless GRE Tunnel in MSO WLAN Network At Preliminary Phase, the CM, as one endpoint of GRE tunnel, may get information of SG by the DHCP method mentioned in section 2.1.1. Subsequently, the CM encapsulates the UE's packet with GRE encapsulation to SG's address y.y.y.y. The source IP of GRE header is x.x.x.x. Once receiving the packet, the SG looks up the outer source IP x.x.x.x of the packet in its tunnel client list. If it is a new client, SG will creat and configure a new GRE tunnel. Generally, the encapsulated packet could be DHCP packet from UE for address. For example, if NPE recognizes the packet is the DHCP message from UE for address request after decapsulating GRE header. Then the NPE can records the assigned UE's address, which is the inner address of GRE encapsulated packet. In addition, a mapping between the inner address of UE and the outer IP address of GRE is added into the tunnel client list on SG. Finally the application IPv4 traffic can pass through the GRE tunnel, and the establishment phase finished. During Keepalive Phase, 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. 6. IANA Considerations IANA is requested to allocate one DHCPv4 GD Option code TBD1 and one DHCPv6 GD Option code TBD2. 7. Security Considerations [RFC2890] describes the security requirement of GRE tunnel. This document follows the requirements based on sub-options used when necessary, mentioned in Section 3. Xue & Guo Expires January 10, 2014 [Page 9] Internet-Draft Dynamic Stateless GRE July 2013 8. 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. 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 January 10, 2014 [Page 10]