idnits 2.17.1 draft-tsou-softwire-gwinit-6rd-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4433 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Informational C. Zhou 5 Expires: September 6, 2012 T. Taylor 6 Huawei Technologies 7 Q. Chen 8 China Telecom 9 March 5, 2012 11 "Gateway-Initiated" 6rd 12 draft-tsou-softwire-gwinit-6rd-06 14 Abstract 16 This document proposes an alternative 6rd deployment model to that of 17 RFC 5969. The basic 6rd model allows IPv6 hosts to gain access to 18 IPv6 networks across an IPv4 access network using 6-in-4 tunnels. 6rd 19 requires support by a device (the 6rd-CE) on the customer site, which 20 must also be assigned an IPv4 address. The alternative model 21 described in this document initiates the 6-in-4 tunnels from an 22 operator-owned gateway collocated with the operator's IPv4 network 23 edge, rather than from customer equipment. The advantages of this 24 approach are that it requires no modification to customer equipment 25 and avoids assignment of IPv4 addresses to customer equipment. The 26 latter point means less pressure on IPv4 addresses in a high-growth 27 environment. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 6, 2012. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 62 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.1. Prefix Delegation . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Relevant Differences From Basic 6rd . . . . . . . . . . . . 7 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 6rd ([RFC5969]) provides a transition tool for connecting IPv6 77 devices across an IPv4 network to an IPv6 network, at which point the 78 packets can be routed natively. The network topology is shown in 79 Figure 1. 81 +--------------+ +-----------------+ +---------+ 82 | | | | | | 83 +-----+ +-----+ | Provider +--------+ | | 84 |IPv6 | | 6rd |__| IPv4 | Border |__| IPv6 | 85 |Host | | CE | | network | Router | | network | 86 +-----+ +-----+ | +--------+ | | 87 | Customer LAN | | | | | 88 +--------------+ +-----------------+ +---------+ 90 Figure 1: 6rd Deployment Topology 92 In Figure 1, the CE is the customer edge router. It is provisioned 93 with a delegated IPv6 prefix, but also with an IPv4 address so that 94 it is reachable through the IPv4 network. If a public IPv4 address 95 is provisioned to every customer, it will aggravate the pressure due 96 to IPv4 address shortage for operators faced with a high rate of 97 growth in the number of broadband subscribers to their network. The 98 use of private addresses with 6rd avoids this particular difficulty, 99 but brings other complications. 101 1.1. Requirements Language 103 This document uses no requirements language. 105 2. Problem Statement 107 Consider an operator facing a high subscriber growth rate. As a 108 result of this growth rate, the operator faces pressure on its stock 109 of available public IPv4 addresses. For this reason, the operator is 110 motivated to offer IPv6 access as quickly as possible. Figure 2 111 shows the sort of network situation envisioned in the present 112 document. 114 +----+ +-------------------+ +----------------+ 115 |Host|\ | | | | 116 +----+ \_+---+ +----+ Metro +----+ | Backbone | 117 _|CPE|----| GW | Network | BR |--| Network | 118 +----+ / +---+ +----+ (IPv4) +----+ | (IPv6) | 119 |Host|/ | | | | 120 +----+ +-------------------+ +----------------+ 122 Host = IPv6 customer host device 123 CPE = customer edge device (customer-provided) 124 GW = provider edge device (Gateway) 125 BR = border router (dual stack) 127 Specialized GW and BR functions are described in the next section. 129 Figure 2: Typical Network Scenario For IPv6 Transition 131 The backbone network will be the first part of the operator's network 132 to support IPv6. The metro network is not so easily upgraded to 133 support IPv6 since many devices need to be modified and there may be 134 some impact to existing services. Thus any means of providing IPv6 135 access has to minimize the changes required to devices in the metro 136 network. 138 In contrast to the situation described for basic 6rd [RFC5569], the 139 operator is assumed to have no control over the capabilities of the 140 IP devices on the customer premises. As a result, the operator 141 cannot assume that any of these devices are capable of supporting 142 6rd. 144 If the customer equipment is in bridged mode and IPv6 is deployed to 145 sites via a Service Provider's (SP's) IPv4 network, the IPv6-only 146 host needs a IPv6 address to visit the IPv6 service. In this 147 scenario, 6to4 or 6rd can be used. However, each IPv6-only host may 148 need one corresponding IPv4 address when using public IPv4 address in 149 6to4 or 6rd, which puts great address pressure on the operators. 151 If the CPE in the above figure is acting in bridging mode, each host 152 behind it needs to be directly assigned an IPv6 prefix so it can 153 access IPv6 services. If the CPE is acting in routing mode, only the 154 CPE needs to be assigned an IPv6 prefix, and it delegates prefixes to 155 the hosts behind it. 157 If the Gateway supports IPv4 only, then an IPv4 address must also be 158 assigned to each host (bridging mode) or to the CPE (routing mode). 159 Both cases, but bridging mode in particular, put pressure on the 160 provider's stock of IPv4 addresses. 162 If the Gateway is dual stack, an arrangement may be possible whereby 163 all communication between the Gateway and the customer site uses IPv6 164 and the need to assign IPv4 addresses to customer devices is avoided. 165 A possible solution is presented in the next section. 167 3. Proposed Solution 169 For basic 6rd [RFC5969], the 6rd CE initiates the 6-in-4 tunnel to 170 the 6rd Border Relay to carry its IPv6 traffic. To avoid the 171 requirement for customer premises equipment to fulfill this role, it 172 is necessary to move the tunneling function to a network device. 173 This document identifies a functional element termed the 6rd Gateway 174 to perform this task. In what follows, the 6rd Gateway and 6rd 175 Border Relay are referred to simply as the Gateway and Border Relay 176 respectively. 178 The functions of Gateway are: 180 o to generate and allocate Gateway initiated 6rd delegated prefixes 181 for IPv6-capable customer devices, as described in Section 3.1. 183 o to forward outgoing IPv6 packets through a tunnel to a Border 184 Relay, which extracts and forwards them to an IPv6 network as for 185 6rd; 187 o to extract incoming IPv6 packets tunneled from the Border Relay 188 and forward them to the correct user device. 190 In the proposed solution, there is only one tunnel initiated from 191 each Gateway to the Border Relay, which greatly reduces the number of 192 tunnels the Border Relay has to handle. The deployment scenario 193 consistent with the problem statement in Section 2 collocates the 194 Gateway with the IP edge of the access network. This is shown in 195 Figure 2 above, and is the typical placement of the Broadband Network 196 Gateway (BNG) in a fixed broadband network. By assumption, the metro 197 network beyond the BNG is IPv4. Transport between the customer site 198 and the Gateway is over layer 2. 200 The elements of the proposed solution are these: 202 o The IPv6 prefix assigned to the customer site contains the 203 compressed IPv4 address of the network-facing side of the Gateway, 204 plus a manually provisioned or Gateway-generated customer site 205 identifier. This is illustrated in Figure 3 below. 207 o The Border Relay is able to route incoming IPv6 packets to the 208 correct Gateway by extracting the compressed Gateway address from 209 the IPv6 destination address of the incoming packet, expanding it 210 to a full 32-bit IPv4 address, and setting it as the destination 211 address of the encapsulated packet. 213 o The Gateway can route incoming packets to the correct link after 214 decapsulation using a mapping from either the full IPv6 prefix or 215 the customer site identifier extracted from that prefix to the 216 appropriate link. 218 3.1. Prefix Delegation 220 Referring back to Figure 2, prefix assignment to the customer 221 equipment occurs in the normal fashion through the Gateway/IP edge, 222 using either DHCPv6 or SLAAC. Figure 3 illustrates the structure of 223 the assigned prefix, and how the components are derived, within the 224 context of a complete address. 226 +--------------------+-----------+ 227 | 32 bit Gateway IPv4 address | 228 +--------------------+-----------+ 229 |<---IPv4MaskLen --->| o bits | Gateway or manually 230 / / generated value, unique 231 Configured / / / for the gateway 232 | / / | 233 | / / V 234 | V p bits | o bits | n bits |m bits | 64 bits | 235 +----------------+------------+---------+-------+----------------+ 236 | | Gateway |Customer | | | 237 | Common prefix | identifier | site |subnet | interface ID | 238 | | | index | ID | | 239 +----------------+------------+---------+-------+----------------+ 240 |<------ GI 6rd delegated prefix ------>| 242 Figure 3: Gateway-Initiated 6rd Address Format for a Customer Site 244 The common prefix, i.e., the first p bits of the GI 6rd delegated 245 prefix, is configured in the Gateway. This part of the prefix is 246 common across multiple customers and multiple Gateways. Multiple 247 common prefix values may be used in a network either for service 248 separation or for scalability. 250 The Gateway Identifier is equal to the o low-order bits of the 251 Gateway IPv4 address on the virtual link to the Border Relay. The 252 number of bits o is equal to 32 - IPv4MaskLen, where the latter is 253 the length of the IPv4 prefix from which the Gateway IPv4 addresses 254 are derived. The value of IPv4MaskLen is configured in both the 255 Gateways and the Border Relays. 257 The Customer Site Index is effectively a sequence number assigned to 258 an individual customer site served by the Gateway. The value of the 259 index for a given customer site must be unique across the Gateway. 260 The length n of the Customer Site Index is provisioned in the 261 Gateway, and must be large enough to accommodate the number of 262 customer sites that the Gateway is expected to serve. 264 To give a numerical example, consider a 6rd domain containing ten 265 million IPv6-capable customer devices (a rather high number given 266 that 6rd is meant for the early stages of IPv6 deployment). The 267 estimated number of 6rd Gateways needed to serve this domain would be 268 in the order of 3,300, each serving 30,000 customer devices. 269 Assuming best-case compression for the Gateway addresses, the Gateway 270 Identifier field has length o = 12 bits. If IPv6-in-IPv4 tunneling 271 is being used, this best case is more likely to be achievable than it 272 would be if the IPv4 addresses belonged to the customer devices. 273 More controllably, the customer device index has length n = 15 bits. 275 Overall, these figures suggest that the length p of the common prefix 276 can be 29 bits for a /56 delegated prefix, or 21 bits if /48 277 delegated prefixes need to be allocated. 279 3.2. Relevant Differences From Basic 6rd 281 A number of the points in [RFC5969] apply with the simple 282 substitution of the Gateway for the 6rd CE. When it comes to 283 configuration, the definition of IPv4MaskLen changes, and there are 284 other differences as indicated in the previous section. Since 285 special configuration of customer equipment is not required, the 6rd 286 DHCPv6 option is inapplicable. 288 Since the link for the customer site to the network now extends only 289 as far as the Gateway, Neighbour Unreachability Detection on the part 290 of customer devices is similarly limited in scope. 292 4. IANA Considerations 294 This memo includes no request to IANA. 296 5. Security Considerations 298 No change from [RFC5969]. 300 6. Acknowledgements 302 Thanks to Ole Troan for his technical comments on an early version of 303 this document. 305 7. References 307 7.1. Normative References 309 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 310 Infrastructures (6rd) -- Protocol Specification", 311 RFC 5969, August 2010. 313 7.2. Informative References 315 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 316 Infrastructures (6rd)", RFC 5569, January 2010. 318 Authors' Addresses 320 Tina Tsou 321 Huawei Technologies (USA) 322 2330 Central Expressway 323 Santa Clara, CA 95050 324 USA 326 Phone: 327 Email: Tina.Tsou.Zouting@huawei.com 329 Cathy Zhou 330 Huawei Technologies 331 Bantian, Longgang District 332 Shenzhen 518129 333 P.R. China 335 Phone: 336 Email: cathy.zhou@huawei.com 337 Tom Taylor 338 Huawei Technologies 339 Ottawa, Ontario 340 Canada 342 Phone: 343 Email: tom.taylor.stds@gmail.com 345 Qi Chen 346 China Telecom 347 109, Zhongshan Ave. West, 348 Tianhe District, Guangzhou 510630 349 P.R. China 351 Phone: 352 Email: chenqi.0819@gmail.com