Network Working Group Dayong Guo Internet Draft Sheng Jiang Intended status: Standards Track Huawei Technologies Co., Ltd Expires: April 18, 2010 October 19, 2009 Auto GRE Tunnel for Hub and Spoke Softwire draft-guo-softwire-auto-gre-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 18, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Guo & Jiang Expires April 18, 2010 [Page 1] Internet-Draft draft-guo-softwire-auto-gre-00.txt October 2009 Abstract This document proposes an auto-configured GRE tunnel mechanism in hub and spoke network. This mechanism automatically configures GRE tunnel encapsulation parameters to end user devices using DHCP protocol. It can also simplify and drive IPv6 transition. Table of Contents 1. Introduction.................................................3 2. Terminology..................................................4 3. Auto GRE Tunnel..............................................4 3.1. Preliminary Phase.......................................4 3.1.1. SC discovery on SI.................................4 3.1.2. Pre-configuration on SC............................4 3.2. Tunnel Establishment....................................4 3.3. Tunnel Maintenance......................................5 3.4. Tunnel Teardown.........................................5 4. Application Example of Auto GRE Tunnel.......................6 4.1. Auto GRE Tunnel deploys in IPv6 network.................6 5. Security Considerations......................................7 6. IANA Considerations..........................................7 7. References...................................................7 7.1. Normative References....................................7 7.2. Informative References..................................8 Author's Addresses..............................................9 Guo & Jiang Expires April 18, 2010 [Page 2] Internet-Draft draft-guo-softwire-auto-gre-00.txt October 2009 1. Introduction The Softwires Working Group has standardized Layer Two Tunneling Protocol version 2 (L2TPv2) as the phase 1 protocol to be deployed in the Softwire "Hub and Spoke" solution space [RFC5571]. L2TPv2 supports "IPvX/PPP/L2TPv2/UDP/IPvY" encapsulations and fulfills requirements in [RFC4925]. Especially L2TPv2 has good capacity to traverse NAT, since L2TPv2 runs over UDP. However, as a multi-layers encapsulation protocol, L2TPv2 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) is too simple to be L2TPv2 initiator. In most scenarios, providers do not need such a complicated transition method that meets all requirements in [RFC4925]. For example, NAT does NOT exist in many scenarios. A simple Auto GRE (Generic Routing Encapsulation) Tunnel, proposed in this document, can meet most requirements in [RFC4925] except for the NAT traverse requirements. GRE [RFC2784] is widely deployed in the ISP networks. Up to now, GRE tunnels are stateless and configured manually. The proposed Auto GRE mechanism does not modify encapsulation format of GRE, but adds signaling, using Dynamic Host Configuration Protocol (DHCP) [RFC2131] or DHCP for IPv6 [RFC3315], so that the softwire can be automatically set up or torn down. Carrier Grade NATs (CGNs) in IPv4/IPv6 transition are such scenarios that do not require NAT traversal. CGN solutions have recently been proposed to simplify IPv4/IPv6 transition in the edge network. [Incremental CGN] and [DS-lite CGN] describes a few dispersive IPvX users bridge IPvX Internet by softwire spanning IPvY infrastructure. Both scenarios require users set up tunnels to CGN. Obviously, there is no NAT between CPE and CGN in both DS-lite and Incremental CGN scenarios. Additionally, the auto-configure mechanism described in the document can also support auto IP-in-IP tunnel. The advantage of GRE is more manageable and extensible than IP-in-IP. Auto IP-in-IP tunnel is out of the focus of this document. Guo & Jiang Expires April 18, 2010 [Page 3] Internet-Draft draft-guo-softwire-auto-gre-00.txt October 2009 2. Terminology 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 [RFC2119]. 3. Auto GRE Tunnel Auto GRE tunnel mechanism enables a Softwire Initiator (SI) exchanges tunnel control signals with its correspondent Softwire Concentrator (SC). DHCP is commonly used when an administrator requires more control to hosts. DHCP or DHCPv6 is adopted as the signaling protocol. This document does NOT project to invent a new signaling protocol but makes full use of DHCP and GRE combinations. The SI in Auto GRE may be a CPE, a host or an edge router. The SC may be a tunnel concentrator or CGN. The Process is described in the following sub-sections. 3.1. Preliminary Phase 3.1.1. SC discovery on SI Before tunneling to SC, SI MUST get the address and other parameters of a SC. The information may be configured manually on the SI. However, manual configuration are difficult to operate when the information of the SC changes. [Discovery] proposes an auto SC discovery method by extending DHCP or Point-to-Point Protocol (PPP)[RFC1661]. 3.1.2. Pre-configuration on SC To support auto-configure GRE tunnel, the SC MUST configure a GRE tunnel interface and listen to GRE packet being sent to the interface. A DHCP snooping is REQUIRED in SC in order to trigger configuration and updating state of the tunnel. 3.2. Tunnel Establishment To set up softwires to the SC, a SI should send a DHCP request message with GRE encapsulation to request an inner address of the tunnel and other relevant network parameters. The destination IP of outer layer header in GRE encapsulation comes from description of Section 2.1.1 SC discovery. The outer source IP uses the IP address of the SI. Guo & Jiang Expires April 18, 2010 [Page 4] Internet-Draft draft-guo-softwire-auto-gre-00.txt October 2009 When SC receives the DHCP request message 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 SC adds source IP into the tunnel client list, decapsulates GRE header and deals with the DHCP request. The SC sends the DHCP reply message, which allocates the inner address, with GRE encapsulation too. The source and destination address in IP header of DHCP reply should comply with DHCP or DHCPv6. The source and destination of the GRE encapsulation MUST originate from the destination and source IP of outer GRE encapsulation of the DHCP request message. 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, the lifetime of the tunnel. The lifetime of the tunnel SHOULD synchronize with the lifetime of SI inner address. For inbound traffic, SC checks the tunnel client list according to destination address of the packet and decides which tunnel the traffic should be forwarded to. While SI receives the DHCP reply message with GRE encapsulation, SI configures itself with the allocated address and other network parameters in the DHCP message. 3.3. Tunnel Maintenance DHCP address lifetime or lease is used for the SC to maintain tunnel state. A SI SHOULD periodically renew the lifetime of the address to keep tunnel alive. The SI renew period SHOULD be shorter than the lifetime. When the lifetime of SI inner address is renewed, the lifetime of the tunnel in the tunnel client list SHOULD be synchronized. Once the lifetime of tunnel expires, the SC tears down the tunnel and releases resource. The lifetime SHOULD be set to appropriate time so that SC deletes inactivity tunnel as well as avoids too frequently renew procedures. 3.4. Tunnel Teardown Tunnels are naturally torn down when the SI inner address expires, as is described in Section 2.3. If the SI wants to actively tear down the GRE tunnel, it will send a DHCP Release Message with GRE encapsulation and then delete the tunnel. While SC receives the DHCP release message encapsulated in GRE tunnel, it tears down the related Auto GRE tunnel. Guo & Jiang Expires April 18, 2010 [Page 5] Internet-Draft draft-guo-softwire-auto-gre-00.txt October 2009 4. Application Example of Auto GRE Tunnel 4.1. Auto GRE Tunnel deploys in IPv6 network Figure 1 illustrates how Auto GRE tunnel deploys in DS lite case. The CPE and CGN in DS lite are respectively the SI and SC in softwire. _________ ______ / \ / \ ___________ / Dual-stack\ +-----+ / IPv6 \ +-----+ / IPv4 \ | or IPv4 |-| SI |-----| Network |----| SC |----| Internet | \ network / +-----+ \ / +-----+ \___________/ \_________/IPv6-2001:DB8::5\______/ IPv6-2001:DB8::1 IPv4-10.0.0.1 | Pre-configuration+and Listen | | Tunnel | DHCPv4 Request in GRE Encap. | Initiation + ===========================> + | | | DHCPv4 Reply in GRE Encap. | Getting IPv4 + <=========================== + Tunnel Addr 10.0.0.2 | with allocated 10.0.0.2 | Establishment Tunnel | | Establishment | | | | Tunnel | DHCPv4 Request in GRE Encap. | Maintenance + ===========================> + | DHCPv4 Reply in GRE Encap. | + <=========================== + | | | | Tunnel | DHCPv4 Release in GRE Encap. | Teardown + ===========================> + Tunnel teardown | | Figure 1 Auto-configuring GRE tunnel in DS lite case Before initiating tunnel establishment, the SI may get information of SC by the method mentioned in Section 2.2.1. The SC is listening to GRE setup requests of all clients. When the SI starts to set up Auto GRE tunnel, it sends a DHCPv4 Request message with GRE encapsulation to the SC's IPv6 address 2001:DB8::1. The source IP of GRE header is 2001:DB8::5. Once a SC receives the packet, it answers an IPv4 address in DHCPv4 reply message with GRE encapsulation. At the same time, the SC creates and configures a new GRE tunnel. Because the SC allocate IP Guo & Jiang Expires April 18, 2010 [Page 6] Internet-Draft draft-guo-softwire-auto-gre-00.txt October 2009 address 10.0.0.2 to the SI, a mapping "inner address of tunnel: 10.0.0.2, outer IP of client: 2001:DB8::5" is added into the tunnel client list on the SC. After SI received the DHCPv4 packet with GRE encapsulation, it completes inner address configuration based on parameters in the DHCPv4 message. Finally the application IPv4 traffic can pass through the GRE tunnel. The SI should periodically intercommunicate DHCPv4 Request/Reply message with GRE encapsulation to keep tunnel alive. The SI may either sends a DHCPv4 release message in GRE tunnel to inform CGN tears down or wait until lifetime expires. 5. Security Considerations [RFC5619] has listed security analysis and requirements in hub and spoke network. It is watchful for SC to resist Denial of Service. DHCP security mechanisms [RFC3118, RFC3315, SecDHC] can be used when necessary. 6. IANA Considerations There are no IANA considerations in this document. 7. References 7.1. Normative References [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, July 1994 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3118] R. Droms and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and M. Carney, "Dynamic Host Configure Protocol for IPv6", RFC3315, July 2003. Guo & Jiang Expires April 18, 2010 [Page 7] Internet-Draft draft-guo-softwire-auto-gre-00.txt October 2009 [RFC5571] B. Storer, C. Pignataro, Ed., M. Dos Santos, B. Stevant, Ed., L. Toutain and J. Tremblay, "Softwire Hub & Spoke Deployment Framework with L2TPv2", RFC 5571, June 2009. [RFC5619] S. Yamamoto, C. Williams, H. Yokota and F. Parent, "Softwire Security Analysis and Requirements", RFC 5619, August 2009. 7.2. Informative References [RFC4925] X. Li, S. Dawkins, D. Ward and A. Durand, "Softwire Problem Statement", RFC 4925, July 2007. [Ds-lite CGN] A. Durand, R. Droms, B. Haberman, and J. Woodyatt, "Dual-stack lite broadband deployments post IPv4 exhaustion", draft-ietf-softwire-dual-stack-lite-01, work in progress, July 2009. [Incremental CGN] S. Jiang, D. Guo and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition" draft-jiang- v6ops-incremental-cgn-03, work in progress, September 2009. [Discovery] D. Guo and S. Jiang "DHCP Option for CGN or Tunnel Concentrator Discovery", draft-guo-dhc-tunnel-discovery-02, work in progress, October 2009. [SecDHC] S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft- jiang-dhc-secure-dhcpv6-02.txt, work in progress, July 2009. Guo & Jiang Expires April 18, 2010 [Page 8] Internet-Draft draft-guo-softwire-auto-gre-00.txt October 2009 Author's Addresses Dayong Guo Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 P.R. China Phone: 86-10-82836077 Email: guoseu@huawei.com Sheng Jiang Huawei Technologies Co., Ltd KuiKe Building, No.9 Xinxi Rd., Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 P.R. China Phone: 86-10-82836081 Email: shengjiang@huawei.com Guo & Jiang Expires April 18, 2010 [Page 9]