idnits 2.17.00 (12 Aug 2021) /tmp/idnits27021/draft-liu-running-multiple-prefixes-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3127 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4894' is mentioned on line 111, but not defined == Missing Reference: 'RFC4193' is mentioned on line 123, but not defined == Missing Reference: 'I-D.jiang-semantic-prefix' is mentioned on line 152, but not defined == Missing Reference: 'RFC3484' is mentioned on line 237, but not defined ** Obsolete undefined reference: RFC 3484 (Obsoleted by RFC 6724) == Missing Reference: 'RFC2827' is mentioned on line 252, but not defined == Missing Reference: 'RFC3704' is mentioned on line 252, but not defined == Missing Reference: 'MULTIHOMING-WITHOUT-NAT' is mentioned on line 253, but not defined == Unused Reference: 'RFC3315' is defined on line 274, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 278, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 282, but no explicit reference was found in the text == Unused Reference: 'RFC4984' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC6555' is defined on line 300, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-addr-select-opt' is defined on line 311, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-bonica-dhcpv6-slaac-problem' is defined on line 316, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: draft-ietf-6man-addr-select-opt has been published as RFC 7078 Summary: 3 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Liu 2 Internet Draft S. Jiang 3 Intended status: Informational Huawei Technologies Co., Ltd 4 Expires: April 24, 2014 October 21, 2013 6 Running Multiple IPv6 Prefixes 7 draft-liu-running-multiple-prefixes-01.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF). Note that other groups may also distribute working 16 documents as Internet-Drafts. The list of current Internet-Drafts is 17 at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on April 24, 2014. 26 Copyright Notice 28 Copyright (c) 2012 IETF Trust and the persons identified as the 29 document authors. All rights reserved. 31 This document is subject to BCP 78 and the IETF Trust's Legal 32 Provisions Relating to IETF Documents 33 (http://trustee.ietf.org/license-info) in effect on the date of 34 publication of this document. Please review these documents 35 carefully, as they describe your rights and restrictions with respect 36 to this document. Code Components extracted from this document must 37 include Simplified BSD License text as described in Section 4.e of 38 the Trust Legal Provisions and are provided without warranty as 39 described in the Simplified BSD License. 41 Abstract 43 This document introduces that multiple prefixes in one network/host 44 might be common in IPv6, and describes several multiple prefixes use 45 cases that might be beneficial to the network. Then some operational 46 considerations and current gaps to support multiple prefixes 47 operations are described. 49 Table of Contents 51 1. Introduction ................................................. 3 52 2. Multiple Prefixes Use cases .................................. 3 53 2.1. Multihoming ............................................. 3 54 2.2. ULA+PA .................................................. 4 55 2.3. Make-before-break renumbering ........................... 4 56 2.4. Semantic Prefixes ....................................... 4 57 3. Basic operational considerations ............................. 5 58 3.1. Multiple prefix provisioning ............................ 5 59 3.2. Multiple addresses in one interface ..................... 5 60 3.3. Address selection ....................................... 5 61 3.4. DNS relevant ............................................ 6 62 4. Current Gaps ................................................. 6 63 5. Security Considerations ...................................... 7 64 6. IANA Considerations .......................................... 7 65 7. Acknowledgments .............................................. 7 66 8. References ................................................... 7 67 8.1. Normative References .................................... 7 68 8.2. Informative References .................................. 7 70 1. Introduction 72 IP protocols have been widely spread. More and more services are 73 relying on IP technology. As the evolution of network application, 74 the IP network architecture/functions are becoming more and more 75 sophisticated. 77 One aspect is the requirement of multiple prefixes. There are several 78 motivations as the following: 80 - Multiple network provisioning, including multihoming and semantic 81 prefixes (as described in section 2.4) etc; 83 - Multiple logic planes, VPN/OAM .etc. 85 In IPv6, multiple prefixes feature is naturally well-supported. 86 Standard IPv6 stack supports multiple-address-per-interface as 87 default; there is a standard address selection algorithms [RFC6724] 88 defined for multiple prefixes purpose. It is one of the most 89 important difference and also an advantage comparing IPv4. 91 This document introduces several multiple prefixes use cases in IPv6 92 that might be beneficial to the network use. And some operational 93 considerations are given, as while as some current gaps for 94 supporting running multiple prefixes. 96 2. Multiple Prefixes Use cases 98 2.1. Multihoming 100 When a network is multihomed, the multiple upstream networks would 101 assign prefixes respectively. If a network for some reason neither 102 acquire a PI (Provider Independent) space nor deploys IPv6 NAT, then 103 the multihoming would resulting in hosts with multiple PA (Provider 104 Aggregated) IPv6 addresses with different prefixes. 106 This approach in IPv4 has rarely been used, since the IPv4 doesn't 107 support multiple addresses/prefixes well. But it is quite practical 108 in IPv6. This approach allows the SMEs to do multihoming without 109 burden from running PI address space or running IPv6 NAT. Furthermore, 110 multiple PA spaces don't have the potential global routing system 111 scalable issue as the PI does [RFC4894]. 113 However, multihoming with multiple PA spaces has some operational 114 issues which mainly include address selection, next-hop selection, 115 and exit-router selection. Especially for the exit-router selection, 116 it seems there has not been any practical solution yet. 118 2.2. ULA+PA 120 Unique Local Addresses (ULAs) are defined in [RFC4193] as provider- 121 independent prefixes. Since there is a 40 bits pseudo random field in 122 the ULA prefix, there is no practical risk of collision (please refer 123 to section 3.2.3 in [RFC4193] for more detail). 125 For either home networks or enterprise networks, the main purpose of 126 using ULA along with GUA is to provide a logically local routing 127 plane separated from the globally routing plane. The benefit is to 128 ensure stable and specific local communication regardless of the ISP 129 uplink failure or change. This benefit is especially meaningful for 130 the home network or private OAM function in an enterprise. 132 In some special cases such as renumbering, enterprise administrators 133 may want to avoid the need to renumber their internal-only, private 134 nodes when they have to renumber the PA addresses of the whole 135 network because of changing ISPs, ISPs restructure their address 136 allocations, or whatever reasons. In these situations, ULA is an 137 effective tool for the internal-only nodes. 139 2.3. Make-before-break renumbering 141 [RFC4192] describes a procedure that can be used to renumber a 142 network from one prefix to another smoothly through a "make-before- 143 break" transition. 145 In the transition period, both the old and new prefixes are available, 146 it is a very good use of multiple prefixes that could avoid the 147 session outage issue in most of the situations when renumbering a 148 network. 150 2.4. Semantic Prefixes 152 [I-D.jiang-semantic-prefix] describes a framework to embed some 153 parameters into the IPv6 prefix segment. The parameters might contain 154 user types, service types, applications, security requirements, 155 traffic identity types, quality requirements and other criteria may 156 also be relevant parameters which a network operator may wish to use 157 to treat packets differently and efficiently. 159 With this approach, for example, the ISPs could provision one 160 subscriber multiple addresses/prefixes to access different services. 162 3. Basic operational considerations 164 There might be some argument/worry that in practice running multiple 165 prefixes would makes terrible operational complexity. It is 166 apprehensible that most of the administrators are not be accustomed 167 to this model, since it is quite different with that in IPv4. 169 But considering running multiple prefixes in IPv6 might be very 170 common, administrators need to adapt this new operational model 171 regardless of personal prefer. 173 Following sub-sections summarize several important operational 174 considerations that try to eliminate the FUD of the administrators. 176 3.1. Multiple prefix provisioning 178 - Multiple provisioning domains: considering current DHCP 179 architecture does not fit multiple provisioning domains well, the 180 administrators should avoid that multiple provisioning domain all 181 directly configuring the host through DHCP, since it might cause 182 confusion for the host. 184 - Multiple provisioning mechanisms: if administrators applied 185 DHCP/SLAAC co-exist in one network, and then they need to learn that 186 there might be some issues, which are reported in [I-D.liu-bonica- 187 dhcpv6-slaac-problems]. 189 3.2. Multiple addresses in one interface 191 - Current implementations support this feature very well; normally 192 this wouldn't be a problem 194 - But current IPAM/NMS applications might have not ready for this 195 multiple mappings management 197 3.3. Address selection 199 This is probably the most error prone problematic issue in running 200 multiple prefixes. 202 [RFC5220] reported various potential problems with address selection 203 in deployment. Some of them have been handled in the updated standard 204 address selection mechanism [RFC6724]. 206 3.4. DNS relevant 208 Normally, one SP only allows only its users to look at DNS records of 209 the service. So in multiple network provisioning scenarios, each DNS 210 query from a host must be forwarded to a suitable DNS server. Hosts 211 normally are not able to select a DNS server for each DNS query 212 target. 214 [RFC6731] is developed for this purpose; it defined DHCPv4/v6 options 215 to deliver the DNS selection policies for hosts. 217 4. Current Gaps 219 o Not all IPAM/NMS tools are able to handle one interface and 220 multiple addresses mappings. 222 o ULA+IPv4 selection 224 There is a special case that needs to be noticed, which is described 225 in section 2.2.2 of [RFC5220]. When an enterprise has IPv4 Internet 226 connectivity but does not yet have IPv6 Internet connectivity, and 227 the enterprise wants to provide site-local IPv6 connectivity, a ULA 228 is the best choice for site-local IPv6 connectivity. Each employee 229 host will have both an IPv4 global or private address and a ULA. Here, 230 when this host tries to connect to an outside node that has 231 registered both A and AAAA records in the DNS, the host will choose 232 AAAA as the destination address and the ULA for the source address 233 according to the IPv6 preference of the default address selection 234 policy [RFC3484]. This will clearly result in a connection failure. 235 Although the new address selection standard [RFC6724] has added ULA 236 specific rules to prefer IPv4 over ULA, but the majority of current 237 existing hosts might still under the old [RFC3484] specification. 239 o Multiple PA exit-router selection 241 In multiple PA multihoming networks, if the ISPs enable ingress 242 filtering at the edge, then the administrators need to deal with the 243 the exit router selection issues. Currently there is no well-used 244 solution, so the administrator might need to communicate with the ISP 245 for not filtering the prefixes. 247 If a site has multiple PA prefixes, complexities in routing 248 configuration will appear. In particular, source-based routing rules 249 might be needed to ensure that outgoing packets are routed to the 250 appropriate border router and ISP link. Normally, a packet sourced 251 from an address assigned by ISP X should not be sent via ISP Y, to 252 avoid ingress filtering by Y [RFC2827] [RFC3704]. Additional 253 considerations may be found in [MULTIHOMING-WITHOUT-NAT]. 255 5. Security Considerations 257 TBD. 259 6. IANA Considerations 261 This draft does not request any IANA actions. 263 7. Acknowledgments 265 Useful comments were received from Victor Kuarsingh and Roberta 266 Maglione. 268 This document was prepared using 2-Word-v2.0.template.dot. 270 8. References 272 8.1. Normative References 274 [RFC3315] R. Droms, Bound, J., Volz, B., Lemon, T., Perkins, C., and 275 M. Carney, "Dynamic Host Configuration Protocol for IPv6 276 (DHCPv6)", RFC 3315, July 2003. 278 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 279 "Neighbor Discovery for IP version 6 (IPv6)", RFC 280 4861,September 2007. 282 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 283 Address Autoconfiguration", RFC 4862, September 2007. 285 8.2. Informative References 287 [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for 288 Renumbering an IPv6 Network without a Flag Day", RFC 4192, 289 September 2005. 291 [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report 292 from the IAB Workshop on Routing and Addressing", RFC 4984, 293 September 2007. 295 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 296 "Problem Statement for Default Address Selection in Multi- 297 Prefix Environments: Operational Issues of RFC 3484 Default 298 Rules", RFC 5220, July 2008. 300 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 301 Dual-Stack Hosts", RFC 6555, April 2012. 303 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 304 "Default Address Selection for Internet Protocol Version 6 305 (IPv6)", RFC 6724, September 2012. 307 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive 308 DNS Server Selection for Multi-Interfaced Nodes", RFC 6731, 309 December 2012. 311 [I-D.ietf-6man-addr-select-opt] 312 Matsumoto, A.M., Fujisaki T.F., and T. Chown, "Distributing 313 Address Selection Policy using DHCPv6", Working in Progress, 314 April 2013. 316 [I-D.liu-bonica-dhcpv6-slaac-problem] 317 Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration 318 Interaction Problem Statement", Working in Progress, 319 February 2013. 321 Authors' Addresses 323 Bing Liu 324 Huawei Technologies Co., Ltd 325 Q14, Huawei Campus 326 No.156 Beiqing Rd. 327 Hai-Dian District, Beijing 100095 328 P.R. China 330 Email: leo.liubing@huawei.com 332 Sheng Jiang 333 Huawei Technologies Co., Ltd 334 Huawei Q14 Building, No.156 Beiqing Rd., 335 Zhong-Guan-Cun Environmental Protection Park, Beijing 336 P.R. China 338 EMail: jiangsheng@huawei.com