idnits 2.17.1 draft-liu-v6ops-running-multiple-prefixes-03.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 25, 2015) is 3320 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 277, but no explicit reference was found in the text == Unused Reference: 'RFC6879' is defined on line 336, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 V6OPS B. Liu 3 Internet-Draft S. Jiang 4 Intended status: Informational Y. Bo 5 Expires: September 26, 2015 Huawei Technologies 6 March 25, 2015 8 Multiple IPv6 Prefixes: Background and Considerations 9 draft-liu-v6ops-running-multiple-prefixes-03 11 Abstract 13 This document describes several typical multiple prefixes use cases, 14 and discusses that running multiple IPv6 prefixes/addresses in one 15 network/host should be common proactice that administrators need to 16 adapt. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 26, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Multiple Prefixes Use cases . . . . . . . . . . . . . . . . . 3 54 2.1. Multiple Prefixes with Different Scopes . . . . . . . . . 3 55 2.2. Multihoming based on Multiple PA Prefixes . . . . . . . . 3 56 2.3. Multiple Prefix Co-existing during Network Renumbering . 4 57 2.4. Service Prefixes . . . . . . . . . . . . . . . . . . . . 4 58 3. Operational Availability and Considerations . . . . . . . . . 4 59 3.1. Multiple prefix provisioning . . . . . . . . . . . . . . 4 60 3.2. Address Selection . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Exit-router selection . . . . . . . . . . . . . . . . . . 5 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 7.2. Informative References . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 In IPv6 networks, there are deployment scenarios in which multiple 73 prefixes coexists simultaneously in one network. Several typical use 74 cases are: 76 - Multiple Prefixes with Different Scopes (described in Section 2.1) 78 - IPv6 multihoming based on multiple PA prefixes (described in 79 Section 2.2) 81 - Make-before-break renumbeirng (described in Section 2.3) 83 - An IPv6 network with multiple services, each of which has a 84 distinct prefix (described in Section 2.4) . 86 To support the multiple prefixes running mode, there have been some 87 technologies developed. This document discusses these technologies 88 of different aspects, which could allow and smoothen the multiple 89 prefiex operation. 91 Note that, although MIF (Multiple InterFaces) [RFC6418] architecture 92 also involves mutliple IPv6 prefixes, it mainly targets different 93 interfaces which attach to different networks respectively. This 94 document discusses the multiple IPv6 prefixes running in the same 95 network. 97 2. Multiple Prefixes Use cases 99 2.1. Multiple Prefixes with Different Scopes 101 IPv6 contains link-local addresses, global addresses and unique local 102 addresses, which by definition are global but normally are site-scope 103 by practice. 105 As specified in [RFC4291], all interfaces are required to have at 106 least one Link-Local unicast address. This is the basic case of 107 running multiple prefixes. However, this does not require operations 108 from the network administrators since it is automatically processed. 110 Besides Link-Local addresses, the Unique Local Addresses (ULAs, 111 [RFC4193]) might also be used for the interal communication within a 112 site network. In many deployment, the ULA is used along with PA 113 (Provider Aggregated) addresses, which connect to the public network. 114 The benefit of such combination is to provide seperate local 115 communication from the globally communication so that the local 116 communication would not be impacted when ISP uplink fail or 117 prefix(es) be renumbered. It is especially benificial for the home 118 network and private OAM plane or internal-only nodes in an 119 enterprise. 121 2.2. Multihoming based on Multiple PA Prefixes 123 When a network is multihomed, the multiple upstream network providers 124 would assign prefixes respectively. If a network does not acquires a 125 PI (Provider Independent) address spaceu, multihoming will result 126 coexistent multiple PA prefixes. In such network, a single host have 127 multiple PA IPv6 addresses that assoicated with different prefixes. 129 This scenario rarely exists in IPv4 networks, since IPv4 only allows 130 single address per interface. But it is quite practical in IPv6. 131 This new feature of IPv6 allows the SMEs (Small/Medium Enterprises) 132 to multihome without the burden of running PI address space or 133 running IPv6 NAT. Furthermore, multiple PA spaces do not have the 134 potential global routing system scalable issue as the PI does 135 [RFC4894]. 137 However, multihoming with multiple PA prefixes has some operational 138 issues which mainly include address selection, next-hop selection, 139 and exit-router selection. For detailed discussion, please refer to 140 [RFC7157]. [Editor's note: more discussion to be filled.] 142 2.3. Multiple Prefix Co-existing during Network Renumbering 144 [RFC4192] describes a procedure that can be used to renumber a 145 network from one prefix to another smoothly through a "make-before- 146 break" transition. In the transition period, both the old and new 147 prefixes are available; the usage of multiple prefixes provides the 148 smooth transition and avoids the session outage issue in most of 149 renumbering operations. 151 2.4. Service Prefixes 153 An IPv6 network may simultaneously provide multiple services, such as 154 IPTV, Internet access, VPN, etc. Each of these services should have 155 a distinct prefix. The network may apply different policy based on 156 the distinguished prefixes. This deployment would simplify the 157 management and processing on network devices, such as forwarding 158 routers, access authentication devices, account devices, bourder 159 filter, etc. The ISPs would provide one subscriber multiple 160 addresses/prefixes to access different services. This deployment 161 would paricularly benefit for traffic recognision and management. 163 3. Operational Availability and Considerations 165 This section discusses some technologies of different aspects, which 166 could allow and smooth the multiple prefiex operation. 168 3.1. Multiple prefix provisioning 170 o Multiple Prefixes from Different Provisioning Domains 172 In [I-D.ietf-mif-mpvd-arch], provisioning domain is defined as 173 consistent set of network configuration information. 174 Classically, the entire set available on a single interface is 175 provided by a single source, such as network administrator, and 176 can therefore be treated as a single provisioning domain. 178 But in modern IPv6 networks, multihoming or service prefixes 179 may result in provisioning information from more than one 180 provisioning domains being presented on a single link. In 181 these scenarios, current technologies lack support of 182 distinguishing information from multiple provisioning domains, 183 thus the host would not be able to associate configuration 184 information with provisioning domains. 186 However, there are several techniques under developing in MIF 187 WG to solve the problems, we could expect them to be 188 standardized in the near future. 190 o Co-existing DHCPv6/SLAAC 192 Both SLAAC [RFC4862] and DHCPv6-PD [RFC3633] could assign IPv6 193 prefixes. DHCPv6-PD is normally run between routers and 194 routers or routers and DHCPv6 [RFC3315] servers; while SLAAC is 195 normally run between routers and downstream hosts. The two 196 protocols could collabarate sufficiently to cover the whole 197 network's prefix provisioning. 199 If operate properly, SLAAC and DHCPv6 could also co-exist for 200 IPv6 addresses provisioning based on different prefixes. They 201 need to carefully deal with the interaction between the two 202 protocols. It is mostly regarding to the M flag in Neighbor 203 Discovery [RFC4861] messages. 205 3.2. Address Selection 207 In order to support multiple addresses well, IPv6 introduced address 208 selection mechanism which utilize a address selection policy table to 209 calculate a proper source address for a given destination address. 210 Of cource, destination adresses selection is also defined. [RFC6724] 211 described the rationale and algorithms in detail, and also defines a 212 default address selection policy table for operating systems. 214 Note that, the [RFC6724] is a replacement of the old [RFC3484] 215 specification to improve some behaviors (e.g. to prefer IPv4 over 216 ULA for outside connectivity). Currently, so far there haven't been 217 many operating systems supporting the new standard, but we could 218 expect that the new standard would be available in all new released 219 operating systems and becomes the mainstream in the near future. 221 3.3. Exit-router selection 223 In multiple PA multihoming networks, if the ISPs enable ingress 224 filtering at the edge (BCP38, [RFC2827]), then there comes the exit 225 router selection issues that outgoing packets are routed to the 226 appropriate border router and ISP link. Normally, a packet sourced 227 from an address assigned by ISP X should not be sent via ISP Y, 228 otherwise it would be filtered by ISP Y. 230 In the past, the administrators have to either communicate with the 231 ISP for not filtering the prefixes or manually configure routing 232 policies within the network to make sure the traffics are forwarded 233 to the right upstream link, based on source prefixes. Now, there are 234 some source-based routing technologies under development and 235 standardization. We could expect these solutions available soon. 237 4. Security Considerations 239 This document does not introduce any new mechanisms or protocols 240 technologies and as such does not introduce any new security threads. 242 Nevertheless, relevant important security considerations are worth to 243 be iterated here: 245 o [RFC7157] gives the security considerations for multi-prefix based 246 multihoming. 248 o Address selection relevant security considerations are described 249 in [RFC6724]. 251 o ND cache exhausion caused by multiple addresses per host in a big 252 L2 network is described in Section 3.2. It is possibility that 253 malicious users intentionally configure massive addresses on host 254 to make the gateway ND cache exhausted. So administrators always 255 need to consider mitigation operations for potential ND cache DoS 256 attack which is documented as [RFC6583]. 258 5. IANA Considerations 260 This draft does not request any IANA action. 262 6. Acknowledgements 264 Valuable inputs of the texts/ideas were from Ole Troan. 266 Useful comments were received from Brian Carpenter, Victor Kuarsingh, 267 Lorenzo Colliti, Mikael Abrahamsson, Fred Baker, Lee Howard and 268 Roberta Maglione. 270 This document was produced using the xml2rfc tool [RFC2629]. 271 (initiallly prepared using 2-Word-v2.0.template.dot. ) 273 7. References 275 7.1. Normative References 277 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 278 Requirement Levels", BCP 14, RFC 2119, March 1997. 280 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 281 June 1999. 283 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 284 and M. Carney, "Dynamic Host Configuration Protocol for 285 IPv6 (DHCPv6)", RFC 3315, July 2003. 287 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 288 Host Configuration Protocol (DHCP) version 6", RFC 3633, 289 December 2003. 291 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 292 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 293 September 2007. 295 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 296 Address Autoconfiguration", RFC 4862, September 2007. 298 7.2. Informative References 300 [I-D.ietf-mif-mpvd-arch] 301 Anipko, D., "Multiple Provisioning Domain Architecture", 302 draft-ietf-mif-mpvd-arch-11 (work in progress), March 303 2015. 305 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 306 Defeating Denial of Service Attacks which employ IP Source 307 Address Spoofing", BCP 38, RFC 2827, May 2000. 309 [RFC3484] Draves, R., "Default Address Selection for Internet 310 Protocol version 6 (IPv6)", RFC 3484, February 2003. 312 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 313 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 314 September 2005. 316 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 317 Addresses", RFC 4193, October 2005. 319 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 320 Architecture", RFC 4291, February 2006. 322 [RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key 323 Exchange (IKE) and IPsec", RFC 4894, May 2007. 325 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 326 Provisioning Domains Problem Statement", RFC 6418, 327 November 2011. 329 [RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational 330 Neighbor Discovery Problems", RFC 6583, March 2012. 332 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 333 "Default Address Selection for Internet Protocol Version 6 334 (IPv6)", RFC 6724, September 2012. 336 [RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise 337 Network Renumbering Scenarios, Considerations, and 338 Methods", RFC 6879, February 2013. 340 [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 341 Wing, "IPv6 Multihoming without Network Address 342 Translation", RFC 7157, March 2014. 344 Authors' Addresses 346 Bing Liu 347 Huawei Technologies 348 Q14, Huawei Campus, No.156 Beiqing Road 349 Hai-Dian District, Beijing, 100095 350 P.R. China 352 Email: leo.liubing@huawei.com 354 Sheng Jiang 355 Huawei Technologies 356 Q14, Huawei Campus, No.156 Beiqing Road 357 Hai-Dian District, Beijing, 100095 358 P.R. China 360 Email: jiangsheng@huawei.com 362 Bo Yang 363 Huawei Technologies 364 Q21, Huawei Campus, No.156 Beiqing Road 365 Hai-Dian District, Beijing, 100095 366 P.R. China 368 Email: boyang.bo@huawei.com