idnits 2.17.1 draft-carpenter-nvo3-addressing-00.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 (July 4, 2012) is 4307 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2460' is defined on line 323, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-kreeger-nvo3-overlay-cp-00 == Outdated reference: A later version (-03) exists of draft-lasserre-nvo3-framework-02 == Outdated reference: A later version (-05) exists of draft-liu-v6ops-ula-usage-analysis-02 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NVO3 B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Intended status: Informational S. Jiang 5 Expires: January 5, 2013 Huawei Technologies Co., Ltd 6 July 4, 2012 8 Layer 3 Addressing Considerations for Network Virtualization Overlays 9 draft-carpenter-nvo3-addressing-00 11 Abstract 13 This document discusses network layer addressing issues for virtual 14 network overlays in large scale data centres hosting many virtual 15 servers for multiple customers. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 5, 2013. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Aspects of addressing in virtual overlay networks . . . . . . . 3 53 2.1. Address Independence and Isolation . . . . . . . . . . . . 3 54 2.2. Multiple Data Centres . . . . . . . . . . . . . . . . . . . 4 55 2.3. Address mapping . . . . . . . . . . . . . . . . . . . . . . 4 56 2.4. Address migration . . . . . . . . . . . . . . . . . . . . . 5 57 2.5. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.6. Dual Stack Operation . . . . . . . . . . . . . . . . . . . 6 59 3. Consequences for IPv4 address management . . . . . . . . . . . 6 60 4. Consequences for IPv6 address management . . . . . . . . . . . 7 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 64 8. Change log [RFC Editor: Please remove] . . . . . . . . . . . . 8 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 A common technique in large data centres hosting servers and services 73 for many customers is to use virtual layer 3 network overlays (NVO3) 74 to organise, manage and separate the virtual servers used by 75 individual customers. The related problems are discussed in 76 [I-D.narten-nvo3-overlay-problem-statement], and a framework for the 77 main components of a solution is described in 78 [I-D.lasserre-nvo3-framework]. 80 [Note: In this draft we do not yet give detailed references to the 81 various NVO3 drafts, none of which discuss addressing issues in 82 detail.] 84 When emulating a large number of virtual hosts on whatever physical 85 network topology is used, probably involving multiple LAN segments, 86 virtual LANs at layer2, and both routers and switches, the question 87 of the IP addressing scheme for the virtual hosts is not trivial. 88 The intention of the present document is to describe the resulting 89 consequences for IP address management in such an environment. 90 Firstly the general aspects are discussed, and then the consequences 91 for both IPv4 and IPv6 addressing schemes are described. 93 2. Aspects of addressing in virtual overlay networks 95 2.1. Address Independence and Isolation 97 In a typical hosting centre, there will be a number of customers, who 98 are quite possibly mutual competitors who happen to use the same 99 hosting centre. It is essential that virtual hosts assigned to one 100 customer cannot communicate directly with, or even be aware of, 101 virtual hosts assigned to any other customer. It is also essential 102 that virtual networks are operationally independent to the maximum 103 possible extent. 105 Therefore, to simplify operations by clearly separating independent 106 virtual networks (VNs) from one another, and to enhance both real and 107 perceived confidentiality of each network, it is desirable for the 108 addresses used by each virtual layer 3 network to be allocated and 109 managed independently of all the others. A consequence of this is 110 that it becomes reasonably straightforward to configure layer 3 111 routing such that traffic from one VN can never unintentionally enter 112 another one, because each network has its own well defined range of 113 addresses. Similarly, it is also reasonably straightforward to 114 configure firewalls or filters to detect and block any unwanted 115 traffic between VNs, even if there is a routing misconfiguration. 117 For these reasons alone, it is necessary for each VN to have its own 118 well-defined layer 3 address space that is managed independently of 119 all other VNs. This requirement is independent of whether the 120 physical hosts that contain the virtual hosts are on one or more 121 physical or bridged LANs or VLANs. In other words, once the layer 3 122 topology is virtualised, layer 2 address independence and isolation 123 is neither necessary nor sufficient to guarantee layer 3 address 124 independence and isolation. 126 It should be understood that independent address allocation does not 127 imply unique addresses. In the IPv4 context, as further discussed 128 below, it is very likely that multiple VNs will use the same 129 ambiguous address space, running over the same physical network 130 infrastructure. 132 2.2. Multiple Data Centres 134 A given customer might have virtual hosts spread across multiple data 135 centres (DCs). Furthermore, those data centres might be owned and 136 operated by competing enterprises. The only safe assumption is that 137 a single address range cannot span multiple DCs, and that a virtual 138 host being relocated to another DC might need to be renumbered. The 139 addressing scheme for virtual hosts must be compatible with such a 140 situation. Most likely this means extending the requirement for 141 address independence and isolation to cover separate parts of a given 142 customer's total set of virtual servers. In other words the usage 143 scenario for any given customer must be able to deal with virtual 144 hosts in multiple independent and mutually isolated layer 3 address 145 spaces, and with the risk of occasional virtual host renumbering. 147 This complicates the issues of routing configuration and address 148 filtering. If a VN extends over multiple DCs, VN routing across DC 149 borders must be supported for the address ranges concerned, and 150 address filtering must also be applied in a consistent way at each DC 151 hosting part of a given VN. 153 2.3. Address mapping 155 Several of the NVO3 documents state the need for an address mapping 156 scheme. Some aspects of this are discussed in 157 [I-D.kreeger-nvo3-overlay-cp]. It is generally assumed that an NVO3 158 system will be built using tunnels, and the required mapping is 159 between virtual host addresses and tunnel end points. The addressing 160 scheme for virtual hosts needs to be consistent with the mapping 161 system adopted and whatever dynamic update protocol is used for that 162 mapping. 164 In the case of a VN that covers multiple DCs, the mapping scheme must 165 also support multiple DCs. The mapping update protocol will need to 166 exchange mapping information between tunnel endpoints at all DCs 167 involved. This information needs to be specified in some detail, and 168 it must be decided whether this protocol needs to be run per VN or 169 per DC, how this protocol decides which DCs it should talk with, etc. 171 2.4. Address migration 173 As discussed in [I-D.narten-nvo3-overlay-problem-statement], current 174 virtual host mechanisms assume that a host's IP address is fixed. If 175 a workload is migrated from one physical host to another, the 176 migration mechanisms assume that existing transport layer 177 associations such as TCP sessions stay alive, and the succesful 178 migration of a job in progress relies on this. 180 As workload conditions change in a large data centre, virtual hosts 181 may need to be migrated from one physical host to another, and quite 182 possibly this will mean moving to a different physical LAN. However, 183 the virtual host address itself should remain constant as just 184 mentioned. The addressing scheme adopted needs to be consistent with 185 this requirement. Another way to view this is as an inverted form of 186 renumbering - instead of the address of a given host changing, a 187 given address is reassigned to a different physical host, thereby 188 representing the move of a given virtual host. 190 When such a move occurs, there will normally be changes in both the 191 layer 2/layer 3 mapping (given by ARP, Neighbour Discovery, etc.) and 192 the virtual host address to tunnel mapping mentioned above. However, 193 an address which is moved in this way should still remain part of the 194 same aggregate for routing purposes. Otherwise, an immediate change 195 to the routing configuration will be needed as well. 197 As mentioned above, if a virtual host needs to be migrated between 198 DCs, it might be unavoidable for its virtual address to change. In 199 this case an application layer mechanism will be needed to recover 200 from the resulting loss of transport layer sessions. 202 2.5. DNS 204 A Domain Name Service, which resolves queries for hostnames into IP 205 addresses, can reduce the direct dependence of customer applications 206 on IP addresses. If a virtual host is always connected using its 207 hostname, the renumbering issue during inter-DC migrations, mentioned 208 in previous section, would be significantly mitigated. However, this 209 would imply a need for rapid DNS updates. 211 2.6. Dual Stack Operation 213 In the case of a dual stack deployment, where each virtual host has 214 both an IPv4 and an IPv6 address, there will presumably be some sort 215 of interdependency of the two addressing schemes. At least, the 216 virtual subnet topologies would usually be the same for the two 217 addressing schemes, and virtual hosts would need to migrate 218 simultaneously for IPv4 and IPv6 purposes. If this was not the case, 219 scenarios requiring IPv4/IPv6 interworking might arise unexpectedly, 220 which would be inconvenient and inefficient. A particular case would 221 be the migration of a virtual host between two DCs, one of which 222 supports dual stack and the other of which supports only a single 223 stack. 225 In general, these situations would require a layer 3 IPv4/IPv6 226 translator within a VN. This solution should be avoided if possible. 228 3. Consequences for IPv4 address management 230 In IPv4, it must be assumed that in many if not most cases, the 231 virtual hosts will be numbered out of ambiguous private address space 232 [RFC1918]. The only safe assumption for a general model is that any 233 individual VN may use the same address space as any other. This 234 increases the importance of the requirements for address isolation, 235 independence and mapping. In fact, without address mapping (and in 236 some scenarios network address translation) a large scale IPv4 NVO3 237 system could not be made to work. 239 Since the IPv4 addresses in use will be ambiguous, management tools 240 must be carefully designed so that operators will never need to rely 241 on addresses alone to identify individual servers. For example, when 242 an address is presented to an operator for any reason, it should 243 always be tagged with some sort of VN identifier. The same goes for 244 any place that an address is logged or stored for any other reason. 245 Legacy software and tools that do not do this should be avoided as 246 much as possible. 248 An interesting aspect of using, say, Net 10 for every VN instance is 249 that the number of virtual hosts can be quite large, up to 2**24 (in 250 excess of 16 million). This frees the designer from traditional 251 limits on the size of an IPv4 subnet. 253 An unavoidable consequence of using RFC1918 addresses is that the 254 virtual hosts, if accessed by outside users, will be hidden behind 255 either an application layer proxy or a NAT. In both cases these 256 might be part of a load balancing system. 258 4. Consequences for IPv6 address management 260 In IPv6, there is no concept of ambiguous private space. Each VN can 261 have its own global-scope address prefix. This removes the 262 operational problems casued by ambiguous addresses in IPv4. 264 Even a basic /64 prefix would allow for more virtual host addresses 265 than would ever be possible in IPv4, so again the designer is not 266 restricted by any absolute limit on subnet size. Nevertheless, it is 267 advisable to use a shorter prefix such as /48 or /56 for each VN, so 268 that a VN can span more than one LAN using standard IPv6 routing 269 without difficulty. It is unclear that tunnels and address mapping 270 are needed for IPv6-based VNs, due to the absence of ambiguous 271 addresses. 273 A choice can be made between a regular IPv6 prefix from the 274 customer's own IPv6 space or from ISP-assigned space, and a Unique 275 Local Address prefix [RFC4193], [I-D.liu-v6ops-ula-usage-analysis]. 276 The latter has the advantage of needing no administrative procedure 277 before assigning it, and it is also routinely blocked by site and ISP 278 border routers, like an RFC1918 prefix. However, apart from that the 279 choice of IPv6 prefix has little external importance and is mainly a 280 matter of convenience. 282 There is no requirement for IPv6 prefix translation [RFC6296] between 283 the virtual hosts and any outside users. However, the presence of 284 such translation, or of some form of load balancing, cannot be 285 excluded. 287 5. Security Considerations 289 Routing configurations and filters in firewalls and routers should be 290 constructed such that, by default, packets from virtual hosts in one 291 VN cannot be forwarded into another VN. Traffic to and from a given 292 VN should only be allowed for the designated users of that VN, and 293 for the VN management and operations tools. 295 An independent and isolated addressing scheme is not by itself a 296 security solution. While it might avoid the most trivial and 297 straightforward penetration attempts, it is in no way a substitute 298 for a security solution that responds to specific threat models in 299 the NVO3 situation. 301 6. IANA Considerations 303 This document requests no action by IANA. 305 7. Acknowledgements 307 Valuable comments and contributions were made by ... and others. 309 This document was produced using the xml2rfc tool [RFC2629]. 311 8. Change log [RFC Editor: Please remove] 313 draft-carpenter-nvo3-addressing-00: original version, 2012-07-04. 315 9. References 317 9.1. Normative References 319 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 320 E. Lear, "Address Allocation for Private Internets", 321 BCP 5, RFC 1918, February 1996. 323 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 324 (IPv6) Specification", RFC 2460, December 1998. 326 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 327 Addresses", RFC 4193, October 2005. 329 9.2. Informative References 331 [I-D.kreeger-nvo3-overlay-cp] 332 Black, D., Dutt, D., Kreeger, L., Sridhavan, M., and T. 333 Narten, "Network Virtualization Overlay Control Protocol 334 Requirements", draft-kreeger-nvo3-overlay-cp-00 (work in 335 progress), January 2012. 337 [I-D.lasserre-nvo3-framework] 338 Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. 339 Rekhter, "Framework for DC Network Virtualization", 340 draft-lasserre-nvo3-framework-02 (work in progress), 341 June 2012. 343 [I-D.liu-v6ops-ula-usage-analysis] 344 Liu, B., Jiang, S., and C. Byrne, "Analysis and 345 recommendation for the ULA usage", 346 draft-liu-v6ops-ula-usage-analysis-02 (work in progress), 347 March 2012. 349 [I-D.narten-nvo3-overlay-problem-statement] 350 Narten, T., Sridhavan, M., Dutt, D., Black, D., and L. 352 Kreeger, "Problem Statement: Overlays for Network 353 Virtualization", 354 draft-narten-nvo3-overlay-problem-statement-02 (work in 355 progress), June 2012. 357 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 358 June 1999. 360 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 361 Translation", RFC 6296, June 2011. 363 Authors' Addresses 365 Brian Carpenter 366 Department of Computer Science 367 University of Auckland 368 PB 92019 369 Auckland, 1142 370 New Zealand 372 Email: brian.e.carpenter@gmail.com 374 Sheng Jiang 375 Huawei Technologies Co., Ltd 376 Q14, Huawei Campus 377 No.156 Beiqing Road 378 Hai-Dian District, Beijing 100095 379 P.R. China 381 Email: jiangsheng@huawei.com