idnits 2.17.1 draft-guo-softwire-auto-gre-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 75 has weird spacing: '...lations and ...' == Line 85 has weird spacing: '... In most s...' == Line 142 has weird spacing: '...scovery metho...' == Line 191 has weird spacing: '...ifetime of t...' -- The document date (October 19, 2009) is 5302 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DS-lite CGN' is mentioned on line 102, but not defined == Missing Reference: 'RFC2119' is mentioned on line 118, but not defined == Unused Reference: 'Ds-lite CGN' is defined on line 312, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-01 -- No information found for draft-guo-dhc-tunnel-discovery - is the name correct? == Outdated reference: A later version (-03) exists of draft-jiang-dhc-secure-dhcpv6-02 Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dayong Guo 2 Internet Draft Sheng Jiang 3 Intended status: Standards Track Huawei Technologies Co., Ltd 4 Expires: April 18, 2010 October 19, 2009 6 Auto GRE Tunnel for Hub and Spoke Softwire 8 draft-guo-softwire-auto-gre-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on April 18, 2010. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/license-info). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 This document proposes an auto-configured GRE tunnel mechanism in hub 46 and spoke network. This mechanism automatically configures GRE tunnel 47 encapsulation parameters to end user devices using DHCP protocol. It 48 can also simplify and drive IPv6 transition. 50 Table of Contents 52 1. Introduction.................................................3 53 2. Terminology..................................................4 54 3. Auto GRE Tunnel..............................................4 55 3.1. Preliminary Phase.......................................4 56 3.1.1. SC discovery on SI.................................4 57 3.1.2. Pre-configuration on SC............................4 58 3.2. Tunnel Establishment....................................4 59 3.3. Tunnel Maintenance......................................5 60 3.4. Tunnel Teardown.........................................5 61 4. Application Example of Auto GRE Tunnel.......................6 62 4.1. Auto GRE Tunnel deploys in IPv6 network.................6 63 5. Security Considerations......................................7 64 6. IANA Considerations..........................................7 65 7. References...................................................7 66 7.1. Normative References....................................7 67 7.2. Informative References..................................8 68 Author's Addresses..............................................9 70 1. Introduction 72 The Softwires Working Group has standardized Layer Two Tunneling 73 Protocol version 2 (L2TPv2) as the phase 1 protocol to be deployed in 74 the Softwire "Hub and Spoke" solution space [RFC5571]. L2TPv2 75 supports "IPvX/PPP/L2TPv2/UDP/IPvY" encapsulations and fulfills 76 requirements in [RFC4925]. Especially L2TPv2 has good capacity to 77 traverse NAT, since L2TPv2 runs over UDP. 79 However, as a multi-layers encapsulation protocol, L2TPv2 has to 80 carry multiple protocol headers per data packet. It is complicated 81 and costly, mostly used for Virtual Private Network (VPN). Most 82 Customer Premises Equipment (CPE) is too simple to be L2TPv2 83 initiator. 85 In most scenarios, providers do not need such a complicated 86 transition method that meets all requirements in [RFC4925]. For 87 example, NAT does NOT exist in many scenarios. A simple Auto GRE 88 (Generic Routing Encapsulation) Tunnel, proposed in this document, 89 can meet most requirements in [RFC4925] except for the NAT traverse 90 requirements. 92 GRE [RFC2784] is widely deployed in the ISP networks. Up to now, GRE 93 tunnels are stateless and configured manually. The proposed Auto GRE 94 mechanism does not modify encapsulation format of GRE, but adds 95 signaling, using Dynamic Host Configuration Protocol (DHCP) [RFC2131] 96 or DHCP for IPv6 [RFC3315], so that the softwire can be automatically 97 set up or torn down. 99 Carrier Grade NATs (CGNs) in IPv4/IPv6 transition are such scenarios 100 that do not require NAT traversal. CGN solutions have recently been 101 proposed to simplify IPv4/IPv6 transition in the edge network. 102 [Incremental CGN] and [DS-lite CGN] describes a few dispersive IPvX 103 users bridge IPvX Internet by softwire spanning IPvY infrastructure. 104 Both scenarios require users set up tunnels to CGN. Obviously, there 105 is no NAT between CPE and CGN in both DS-lite and Incremental CGN 106 scenarios. 108 Additionally, the auto-configure mechanism described in the document 109 can also support auto IP-in-IP tunnel. The advantage of GRE is more 110 manageable and extensible than IP-in-IP. Auto IP-in-IP tunnel is out 111 of the focus of this document. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC2119 [RFC2119]. 119 3. Auto GRE Tunnel 121 Auto GRE tunnel mechanism enables a Softwire Initiator (SI) exchanges 122 tunnel control signals with its correspondent Softwire Concentrator 123 (SC). DHCP is commonly used when an administrator requires more 124 control to hosts. DHCP or DHCPv6 is adopted as the signaling protocol. 125 This document does NOT project to invent a new signaling protocol but 126 makes full use of DHCP and GRE combinations. 128 The SI in Auto GRE may be a CPE, a host or an edge router. The SC may 129 be a tunnel concentrator or CGN. 131 The Process is described in the following sub-sections. 133 3.1. Preliminary Phase 135 3.1.1. SC discovery on SI 137 Before tunneling to SC, SI MUST get the address and other parameters 138 of a SC. The information may be configured manually on the SI. 140 However, manual configuration are difficult to operate when the 141 information of the SC changes. [Discovery] proposes an auto SC 142 discovery method by extending DHCP or Point-to-Point Protocol 143 (PPP)[RFC1661]. 145 3.1.2. Pre-configuration on SC 147 To support auto-configure GRE tunnel, the SC MUST configure a GRE 148 tunnel interface and listen to GRE packet being sent to the interface. 149 A DHCP snooping is REQUIRED in SC in order to trigger configuration 150 and updating state of the tunnel. 152 3.2. Tunnel Establishment 154 To set up softwires to the SC, a SI should send a DHCP request 155 message with GRE encapsulation to request an inner address of the 156 tunnel and other relevant network parameters. The destination IP of 157 outer layer header in GRE encapsulation comes from description of 158 Section 2.1.1 SC discovery. The outer source IP uses the IP address 159 of the SI. 161 When SC receives the DHCP request message with GRE encapsulation, it 162 SHOULD look up the outer source IP of the packet in its tunnel client 163 list. If it is a new client, the SC adds source IP into the tunnel 164 client list, decapsulates GRE header and deals with the DHCP request. 165 The SC sends the DHCP reply message, which allocates the inner 166 address, with GRE encapsulation too. The source and destination 167 address in IP header of DHCP reply should comply with DHCP or DHCPv6. 168 The source and destination of the GRE encapsulation MUST originate 169 from the destination and source IP of outer GRE encapsulation of the 170 DHCP request message. 172 The tunnel client list records the information of all tunnel clients. 173 Each entry of the list describes information of a tunnel, includes 174 the mapping of the inner address of tunnel and the outer IP of client, 175 the lifetime of the tunnel. The lifetime of the tunnel SHOULD 176 synchronize with the lifetime of SI inner address. For inbound 177 traffic, SC checks the tunnel client list according to destination 178 address of the packet and decides which tunnel the traffic should be 179 forwarded to. 181 While SI receives the DHCP reply message with GRE encapsulation, SI 182 configures itself with the allocated address and other network 183 parameters in the DHCP message. 185 3.3. Tunnel Maintenance 187 DHCP address lifetime or lease is used for the SC to maintain tunnel 188 state. A SI SHOULD periodically renew the lifetime of the address to 189 keep tunnel alive. The SI renew period SHOULD be shorter than the 190 lifetime. When the lifetime of SI inner address is renewed, the 191 lifetime of the tunnel in the tunnel client list SHOULD be 192 synchronized. Once the lifetime of tunnel expires, the SC tears down 193 the tunnel and releases resource. The lifetime SHOULD be set to 194 appropriate time so that SC deletes inactivity tunnel as well as 195 avoids too frequently renew procedures. 197 3.4. Tunnel Teardown 199 Tunnels are naturally torn down when the SI inner address expires, as 200 is described in Section 2.3. 202 If the SI wants to actively tear down the GRE tunnel, it will send a 203 DHCP Release Message with GRE encapsulation and then delete the 204 tunnel. While SC receives the DHCP release message encapsulated in 205 GRE tunnel, it tears down the related Auto GRE tunnel. 207 4. Application Example of Auto GRE Tunnel 209 4.1. Auto GRE Tunnel deploys in IPv6 network 211 Figure 1 illustrates how Auto GRE tunnel deploys in DS lite case. The 212 CPE and CGN in DS lite are respectively the SI and SC in softwire. 214 _________ ______ 215 / \ / \ ___________ 216 / Dual-stack\ +-----+ / IPv6 \ +-----+ / IPv4 \ 217 | or IPv4 |-| SI |-----| Network |----| SC |----| Internet | 218 \ network / +-----+ \ / +-----+ \___________/ 219 \_________/IPv6-2001:DB8::5\______/ IPv6-2001:DB8::1 220 IPv4-10.0.0.1 221 | Pre-configuration+and Listen 222 | | 223 Tunnel | DHCPv4 Request in GRE Encap. | 224 Initiation + ===========================> + 225 | | 226 | DHCPv4 Reply in GRE Encap. | 227 Getting IPv4 + <=========================== + Tunnel 228 Addr 10.0.0.2 | with allocated 10.0.0.2 | Establishment 229 Tunnel | | 230 Establishment | | 231 | | 232 Tunnel | DHCPv4 Request in GRE Encap. | 233 Maintenance + ===========================> + 234 | DHCPv4 Reply in GRE Encap. | 235 + <=========================== + 236 | | 237 | | 238 Tunnel | DHCPv4 Release in GRE Encap. | 239 Teardown + ===========================> + Tunnel teardown 240 | | 241 Figure 1 Auto-configuring GRE tunnel in DS lite case 243 Before initiating tunnel establishment, the SI may get information of 244 SC by the method mentioned in Section 2.2.1. The SC is listening to 245 GRE setup requests of all clients. 247 When the SI starts to set up Auto GRE tunnel, it sends a DHCPv4 248 Request message with GRE encapsulation to the SC's IPv6 address 249 2001:DB8::1. The source IP of GRE header is 2001:DB8::5. 251 Once a SC receives the packet, it answers an IPv4 address in DHCPv4 252 reply message with GRE encapsulation. At the same time, the SC 253 creates and configures a new GRE tunnel. Because the SC allocate IP 254 address 10.0.0.2 to the SI, a mapping "inner address of tunnel: 255 10.0.0.2, outer IP of client: 2001:DB8::5" is added into the tunnel 256 client list on the SC. 258 After SI received the DHCPv4 packet with GRE encapsulation, it 259 completes inner address configuration based on parameters in the 260 DHCPv4 message. Finally the application IPv4 traffic can pass through 261 the GRE tunnel. 263 The SI should periodically intercommunicate DHCPv4 Request/Reply 264 message with GRE encapsulation to keep tunnel alive. The SI may 265 either sends a DHCPv4 release message in GRE tunnel to inform CGN 266 tears down or wait until lifetime expires. 268 5. Security Considerations 270 [RFC5619] has listed security analysis and requirements in hub and 271 spoke network. It is watchful for SC to resist Denial of Service. 272 DHCP security mechanisms [RFC3118, RFC3315, SecDHC] can be used when 273 necessary. 275 6. IANA Considerations 277 There are no IANA considerations in this document. 279 7. References 281 7.1. Normative References 283 [RFC1661] W. Simpson, "The Point-to-Point Protocol (PPP)", RFC 1661, 284 July 1994 286 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 287 March 1997. 289 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina, 290 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 292 [RFC3118] R. Droms and W. Arbaugh, "Authentication for DHCP Messages", 293 RFC 3118, June 2001. 295 [RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and 296 M. Carney, "Dynamic Host Configure Protocol for IPv6", 297 RFC3315, July 2003. 299 [RFC5571] B. Storer, C. Pignataro, Ed., M. Dos Santos, B. Stevant, 300 Ed., L. Toutain and J. Tremblay, "Softwire Hub & Spoke 301 Deployment Framework with L2TPv2", RFC 5571, June 2009. 303 [RFC5619] S. Yamamoto, C. Williams, H. Yokota and F. Parent, 304 "Softwire Security Analysis and Requirements", RFC 5619, 305 August 2009. 307 7.2. Informative References 309 [RFC4925] X. Li, S. Dawkins, D. Ward and A. Durand, "Softwire Problem 310 Statement", RFC 4925, July 2007. 312 [Ds-lite CGN] A. Durand, R. Droms, B. Haberman, and J. Woodyatt, 313 "Dual-stack lite broadband deployments post IPv4 314 exhaustion", draft-ietf-softwire-dual-stack-lite-01, work 315 in progress, July 2009. 317 [Incremental CGN] S. Jiang, D. Guo and B. Carpenter, "An Incremental 318 Carrier-Grade NAT (CGN) for IPv6 Transition" draft-jiang- 319 v6ops-incremental-cgn-03, work in progress, September 2009. 321 [Discovery] D. Guo and S. Jiang "DHCP Option for CGN or Tunnel 322 Concentrator Discovery", draft-guo-dhc-tunnel-discovery-02, 323 work in progress, October 2009. 325 [SecDHC] S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft- 326 jiang-dhc-secure-dhcpv6-02.txt, work in progress, July 2009. 328 Author's Addresses 330 Dayong Guo 331 Huawei Technologies Co., Ltd 332 KuiKe Building, No.9 Xinxi Rd., 333 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 334 P.R. China 335 Phone: 86-10-82836077 336 Email: guoseu@huawei.com 338 Sheng Jiang 339 Huawei Technologies Co., Ltd 340 KuiKe Building, No.9 Xinxi Rd., 341 Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085 342 P.R. China 343 Phone: 86-10-82836081 344 Email: shengjiang@huawei.com