idnits 2.17.1 draft-herbert-nvo3-ila-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 == Line 565 has weird spacing: '... be transla...' -- The document date (January 20, 2015) is 3346 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC7346' is mentioned on line 358, but not defined == Missing Reference: 'RFC6145' is mentioned on line 922, but not defined ** Obsolete undefined reference: RFC 6145 (Obsoleted by RFC 7915) == Missing Reference: 'RFC6742' is mentioned on line 667, but not defined == Missing Reference: 'RFC4122' is mentioned on line 1162, but not defined == Unused Reference: 'RFC4291' is defined on line 1354, but no explicit reference was found in the text == Unused Reference: 'RFC6724' is defined on line 1360, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-herbert-gue-02 == Outdated reference: A later version (-03) exists of draft-hy-gue-4-secure-transport-00 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Experimental Google 4 Expires: July 2015 January 20, 2015 6 Identifier-locator addressing for network virtualization 7 draft-herbert-nvo3-ila-00 9 Status of this Memo 11 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 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/1id-abstracts.html 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 Copyright and License Notice 32 Copyright (c) 2014 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with respect 40 to this document. Code Components extracted from this document must 41 include Simplified BSD License text as described in Section 4.e of 42 the Trust Legal Provisions and are provided without warranty as 43 described in the Simplified BSD License. 45 Abstract 47 This specification describes identifier-locator addressing (ILA) in 48 IPv6 for network virtualization. Identifier-locator addressing 49 differentiates between location and identity of a network node. Part 50 of an address expresses the immutable identity of the node, and 51 another part indicates the location of the node which can be dynamic. 52 In the context of virtualization, a virtual address serves as an 53 identifier and the address of the host where the associated tenant 54 system currently resides is a locator. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2 Address formats . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1 ILA format . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.2 Identifier format . . . . . . . . . . . . . . . . . . . . . 6 62 2.3 Identifier types . . . . . . . . . . . . . . . . . . . . . . 6 63 2.4 Interface identifiers . . . . . . . . . . . . . . . . . . . 6 64 2.5 Locally unique identifiers . . . . . . . . . . . . . . . . . 7 65 2.6 Virtual networking identifiers for IPv4 . . . . . . . . . . 7 66 2.7 Virtual networking identifiers for IPv6 . . . . . . . . . . 7 67 2.7.1 Virtual networking identifiers for IPv6 unicast . . . . 7 68 2.7.2 Virtual networking identifiers for IPv6 multicast . . . 8 69 2.8 Standard identifier representation addresses . . . . . . . . 9 70 2.8.1 SIR for locally unique identifiers . . . . . . . . . . . 10 71 2.8.2 SIR for virtual addresses . . . . . . . . . . . . . . . 10 72 2.9 Locators . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 3 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 3.1 Identifier to locator mapping . . . . . . . . . . . . . . . 12 75 3.2 Address translations . . . . . . . . . . . . . . . . . . . . 12 76 3.2.1 SIR to ILA address translation . . . . . . . . . . . . . 12 77 3.2.2 ILA to SIR address translation . . . . . . . . . . . . . 13 78 3.3 Virtual networking operation . . . . . . . . . . . . . . . . 13 79 3.3.1 Crossing virtual networks . . . . . . . . . . . . . . . 14 80 3.3.2 IPv4/IPv6 protocol translation . . . . . . . . . . . . . 14 81 3.4 One sided ILA . . . . . . . . . . . . . . . . . . . . . . . 14 82 3.5 Checksum handling . . . . . . . . . . . . . . . . . . . . . 14 83 3.5.1 Transmit checksum . . . . . . . . . . . . . . . . . . . 14 84 3.5.2 Receive checksum . . . . . . . . . . . . . . . . . . . . 15 85 3.6 Address selection . . . . . . . . . . . . . . . . . . . . . 15 86 4. Communication scenarios . . . . . . . . . . . . . . . . . . . . 15 87 4.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 15 88 4.2 Identifier objects . . . . . . . . . . . . . . . . . . . . . 16 89 4.2 Reference network for scenarios . . . . . . . . . . . . . . 17 90 4.3 Scenario 1: Task to task . . . . . . . . . . . . . . . . . . 18 91 4.4 Scenario 2: Task to Internet . . . . . . . . . . . . . . . . 18 92 4.5 Scenario 3: Internet to task . . . . . . . . . . . . . . . . 18 93 4.6 Scenario 4: TS to service task . . . . . . . . . . . . . . . 19 94 4.7 Scenario 5: Task to TS . . . . . . . . . . . . . . . . . . . 19 95 4.8 Scenario 6: TS to Internet . . . . . . . . . . . . . . . . . 20 96 4.9 Scenario 7: Internet to TS . . . . . . . . . . . . . . . . . 20 97 4.10 Scenario 8: IPv4 TS to service . . . . . . . . . . . . . . 20 98 4.11 TS to TS in the same virtual network . . . . . . . . . . . 21 99 4.11.1 Scenario 9: TS to TS in same VN using IPV6 . . . . . . 21 100 4.11.2 Scenario 10: TS to TS in same VN using IPv4 . . . . . . 21 101 4.12 TS to TS in a different virtual network . . . . . . . . . . 21 102 4.12.1 Scenario 11: TS to TS in a different VN using IPV6 . . 22 103 4.12.2 Scenario 12: TS to TS in a different VN using IPv4 . . 22 104 4.12.3 Scenario 13: IPv4 TS to IPv6 TS in different VNs . . . 22 105 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 106 5.1 Data center virtualization . . . . . . . . . . . . . . . . . 23 107 5.1.1 Job scheduling . . . . . . . . . . . . . . . . . . . . . 23 108 5.1.1 Address migration . . . . . . . . . . . . . . . . . . . 24 109 5.1.2 Connection migration . . . . . . . . . . . . . . . . . . 24 110 5.1.3 Task identifier generation . . . . . . . . . . . . . . . 25 111 5.1.3.1 Gobally unique identifiers method . . . . . . . . . 25 112 5.1.3.2 Universally Unique Identifiers method . . . . . . . 25 113 5.1.3.3 Duplicate identifier detection . . . . . . . . . . . 26 114 5.2 Multi-tenant virtualization . . . . . . . . . . . . . . . . 26 115 5.2.1 IPv6 over IPv6 network virtualization . . . . . . . . . 27 116 5.2.2 IPv4 over IPv6 network virtualization . . . . . . . . . 28 117 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 29 118 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 29 119 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 120 8.1 Normative References . . . . . . . . . . . . . . . . . . . 29 121 8.2 Informative References . . . . . . . . . . . . . . . . . . 30 122 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 30 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 125 1 Introduction 127 This document describes the data path, address formats, and expected 128 use cases of identifier-locator addressing in IPv6 ([RFC2460]). The 129 Identifier-Locator Network Protocol (ILNP) ([RFC6740], [RFC6741]) 130 defines a protocol and operations model for identifier-locator 131 addressing in IPv6. Many concepts here are taken from ILNP, however 132 there are some differences in the context of network virtualization-- 133 for instance we assume that a centralized control plane will be 134 implemented that provides mappings of identifiers to locators. 136 In identifier-locator addressing, an IPv6 address is split into a 137 locator and an identifier component. The locator indicates the 138 physical location in the network for a node, and the identifier 139 indicates the node's identity which is the logical or virtual 140 endpoint in communications. Locators are routable within a network, 141 but identifiers typically are not. An application addresses a 142 destination by identifier. Identifiers are mapped to locators for 143 transit in the network. The on-the-wire address is composed of a 144 locator and an identifier: the locator is sufficient to route the 145 packet to a physical host, and the identifier allows the receiving 146 host to forward the packet to the addressed application. 148 Identifiers are not statically bound to a host on the network, and in 149 fact their binding (or location) may change. This is the basis for 150 network virtualization and address migration. An identifier is mapped 151 to a locator at any given time, and a set of identifier to locator 152 mappings is propagated throughout a network to allow communications. 153 The mappings are kept synchronized so that if an identifier migrates 154 to a new physical host, its identifier to locator mapping is updated. 156 In network virtualization, an identifier may further be split into a 157 virtual network identifier and virtual host address. With identifier- 158 locator addressing network virtualization can be implemented in an 159 IPv6 network without any additional encapsulation headers. Packets 160 sent with identifier-locator addresses look like plain unencapsulated 161 packets (e.g. TCP/IP packets). This "encapsulation" is transparent to 162 the network, so protocol specific mechanisms in network hardware work 163 seamlessly. These mechanisms include hash calculation for ECMP, NIC 164 large segment offload, checksum offload, etc. 166 2 Address formats 168 This section describes the address formats associated with 169 identifier-locator addressing in network virtualization. 171 2.1 ILA format 173 As described in ILNP ([RFC6741]) an IPv6 address may be encoded to 174 hold a locator and identifier where each occupies 64 bits. In ILA, 175 the upper three bits of the identifier indicate an identifier type. 177 /* IPv6 canonical address format */ 178 | 64 bits | 64 bits | 179 +--------------------------------+-------------------------------+ 180 | IPv6 Unicast Routing Prefix | Interface Identifier | 181 +--------------------------------+-------------------------------+ 183 /* ILA for IPv6 */ 184 | 64 bits |3 bits| 61 bits | 185 +--------------------------------+-------------------------------+ 186 | Locator | Type | Identifier | 187 +----------------------------------------------------------------+ 189 An IPv6 header with ILA addresses would then have the format: 191 0 1 2 3 192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 |Version| Traffic Class | Flow Label | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Payload Length | Next Header | Hop Limit | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Source Locator | 199 + + 200 | | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 |Type | Source Identifier | 203 +-+-+-+ + 204 | | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Destination Locator | 207 + + 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 |Type | Destination Identifier | 211 +-+-+-+ + 212 | | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Note that there is no requirement that both the source and 216 destination are identifier-locator addresses. 218 2.2 Identifier format 220 An ILA identifier includes a three bit type field and sixy-one bits 221 for an identfier value. 223 /* Identifier format for ILA */ 224 0 1 2 3 225 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type| Identifier | 228 +-+-+-+ | 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 o Type: Type of the identifier (see below). 234 o Identifier: Identifier value. 236 2.3 Identifier types 238 Defined identifier types are: 240 0: interface identifier 241 1: locally unique identifier 242 2: virtual networking identifier for IPv4 address 243 3: virtual networking identifier for IPv6 unicast address 244 4: virtual networking identifier for IPv6 multicast address 245 5-7: Reserved 247 2.4 Interface identifiers 249 The interface identifier type indicates a plain local scope interface 250 identifier. When this type is used the address is a normal IPv6 251 address without identifier-locator semantics. 253 /* Local scope interface identifier */ 254 | 64 bits |3 bits| 61 bits | 255 +----------------------------+------+---------------------------+ 256 | Address1 | 0x0 | Address2 | 257 +---------------------------------------------------------------+ 259 2.5 Locally unique identifiers 261 Locally unique identifiers (LUI) can be created for various 262 addressable nodes within a network. These identifiers are in a flat 263 61 bit space and must be unique within a domain (unique within a site 264 for instance). To simplify administration, hierarchical allocation of 265 locally unique identifiers may be done. 267 /* ILA with locally unique identifiers */ 268 | 64 bits |3 bits| 61 bits | 269 +----------------------------+------+---------------------------+ 270 | Locator | 0x1 | Locally unique ident. | 271 +---------------------------------------------------------------+ 273 2.6 Virtual networking identifiers for IPv4 275 This type defines a format for encoding an IPv4 virtual address and 276 virtual network identifier within an identifier. 278 /* ILA for IPv4 virtual networking */ 279 | 64 bits |3 bits| 29 bits | 32 bits | 280 +----------------------------+------+---------------+-----------+ 281 | Locator | 0x2 | VNID | VADDR | 282 +---------------------------------------------------------------+ 284 VNID is a virtual network identifier and VADDR is a virtual address 285 within the virtual network indicated by the VNID. The VADDR can be an 286 IPv4 unicast or multicast address, and may often be in a private 287 address space (i.e. [RFC1918]) used in the virtual network. 289 2.7 Virtual networking identifiers for IPv6 291 A virtual network identifier and an IPv6 virtual host address (tenant 292 visible address) can be encoded within an identifier. Encoding the 293 virtual host address involves mapping the 128 bit address into a 294 sixy-one bit identifier. Different encodings are used for unicast and 295 multicast addresses. 297 2.7.1 Virtual networking identifiers for IPv6 unicast 299 In this format, the virtual network identifier and virtual IPv6 300 unicast address are encoded within an identifier. To facilitate 301 encoding of virtual addresses, there is a unique mapping between a 302 VNID and a 96 bit prefix. 304 /* IPv6 unicast encoding with VNID in ILA */ 305 | 64 bits |3 bits| 29 bits | 32 bits | 306 +------------------------------+------+--------------+-----------+ 307 | Locator | 0x3 | VNID | VADDR6L | 308 +----------------------------------------------------------------+ 310 VADDR6L contains the low order 32 bits of the IPv6 virtual address. 311 The upper 96 bits of the virtual address inferred from the VNID to 312 prefix mapping. 314 The figure below illustrates encoding a tenant IPv6 virtual unicast 315 address into a ILA address. 317 /* IPv6 virtual address seen by tenant */ 318 +----------------------------------------------+-----------------+ 319 | Tenant prefix | VADDR6L | 320 +-----------------------+-------------------------------+--------+ 321 | | 322 +-prefix to VNID-+ | 323 | | 324 v v 325 +---------------------------+------+-----------+-----------------+ 326 | Locator | 0x3 | VNID | VADDR6L | 327 +----------------------------------------------------------------+ 328 /* Encoded IPv6 virtual address with VNID in ILA */ 330 This encoding is reversible, given an ILA address, the virtual 331 address visible to the tenant can be deduced: 333 /* ILA encoded virtual networking address */ 334 +---------------------------+------+-----------+-----------------+ 335 | Locator | 0x3 | VNID | VADDR6L | 336 +----------------------------------------+-----------------------+ 337 | | 338 +-VNID to prefix-+ | 339 | | 340 v v 341 +----------------------------------------------+-----------------+ 342 | Tenant prefix | VADDR6L | 343 +----------------------------------------------------------------+ 344 /* IPv6 virtual address seen by tenant */ 346 2.7.2 Virtual networking identifiers for IPv6 multicast 348 In this format, a virtual network identifier and virtual IPv6 349 multicast address are encoded within an identifier. 351 /* IPv6 multicast address with VNID encoding in ILA */ 352 | 64 bits |3 bits| 29 bits |4 bits| 28 bits | 353 +--------------------------+------+------------------------------+ 354 | Locator | 0x4 | VNID |Scope | MADDR6L | 355 +----------------------------------------------------------------+ 357 This format encodes a multicast IPv6 address in an identifier. The 358 scope indicates multicast address scope as defined in [RFC7346]. 359 MADDR6L is the low order 28 bits of the multicast address. The full 360 multicast address is thus: 362 ff0::0: 364 This encoding permits encoding of multicast addresses of the form: 366 ff0X::0 to ff0X::0fff:ffff 368 The figure below illustrates encoding a tenant IPv6 virtual multicast 369 address into an ILA address. 371 /* IPv6 multicast address */ 372 | 12 bits | 4 bits| 84 bits | 28 bits | 373 +---------+-------+-----------------------------------+----------+ 374 | 0xfff | Scope | 0's | MADDR6L | 375 +-------------+---------------------------------------------+----+ 376 | | 377 +------------------------------------+ | 378 | | 379 v v 380 +--------------------------+------+------------------------------+ 381 | Locator | 0x4 | VNID |Scope | MADDR6L | 382 +----------------------------------------------------------------+ 383 /* IPv6 multicast address with VNID encoding in ILA */ 385 2.8 Standard identifier representation addresses 387 An identifier serves as the external representation of a network 388 node. For instance, an identifier may refer to a specific host, 389 virtual machine, or tenant system. When a host initiates a connection 390 or sends a packet, it uses the identifier to indicate the peer 391 endpoint of the communication. The endpoints of an established 392 connection context also nominally refer to identifiers. It is only 393 when the packet is actually being sent over a network that the 394 locator for the identifier needs to be resolved. 396 In order to maintain compatibility with existing networking stacks 397 and applications, identifiers are encoded in IPv6 addresses using a 398 standard identifier representation (SIR) address. A SIR address is a 399 combination of a prefix which occupies what would be the locator 400 portion of an ILA address, and the identifier in its usual location. 402 /* SIR address in IPv6 */ 403 | 64 bits | 64 bits | 404 +--------------------------------+-------------------------------+ 405 | SIR prefix | Identifier | 406 +----------------------------------------------------------------+ 408 A SIR prefix may be may be site-local, or globally routable. A 409 globally routable SIR prefix allows connectivity between hosts on the 410 Internet and ILA endpoints. A gateway between a site's network and 411 the Internet can translate between SIR prefix and locator for an 412 identifier. A network may have multiple SIR prefixes, and may also 413 allow tenant specific SIR prefixes in network virtualization. 415 The standard identifier representation can be used as the externally 416 visible address for an node. This can used throughout the network, 417 returned in DNS AAAA records ([RFC3363]), used in logging, etc. An 418 application can use a SIR address without knowledge that it encodes 419 an identifier. 421 2.8.1 SIR for locally unique identifiers 423 The SIR address for a locally unique identifier has format: 425 /* SIR address with locally unique identifiers */ 426 | 64 bits |3 bits| 61 bits | 427 +--------------------------------+-------------------------------+ 428 | SIR prefix | 0x1 | Locally unique ident. | 429 +----------------------------------------------------------------+ 431 When using ILA with locally unique identifiers a flow tuple logically 432 has the form: 434 (source identifier, source port, 435 destination identifier, destination port) 437 Using standard identifier representation the flow is then represented 438 with IPv6 addresses: 440 (source SIR address, source port, 441 destination SIR address, destination port) 443 2.8.2 SIR for virtual addresses 445 An ILA virtual address may be encoded using the standard identifier 446 representation. For example, the SIR address for an IPv6 virtual 447 address may be: 449 /* SIR with IPv6 virtual network encoding */ 450 | 64 bits |3 bits| 29 bits | 32 bits | 451 +------------------------------+------+-------------+------------+ 452 | Tenant's SIR prefix | 0x3 | VNID | VADDRL6 | 453 +----------------------------------------------------------------+ 455 In a tenant system, a flow tuple would have the form: 457 (local VADDR, local port, remote VADDR, remote port) 459 After translating packets for the flow into ILA, the flow would be 460 identified on-the-wire as: 462 ((local VNID, local VADDR), local port, 463 (remote VNID, remote VADDR), remote port 465 A tenant may communicate with a peer in the network which is not in 466 its virtual network, for instance to reach a network service (see 467 below). In this case the flow tuple at the peer may be: 469 (local SIR address, local port, 470 remote SIR address, remote port) 472 In this example, the remote SIR address is a SIR address for a 473 virtual networking identifier, however from peer's connectivity 474 perspective this is not distinguishable from a SIR address with a 475 locally unique identifier or even a non-ILA address. 477 2.9 Locators 479 Locators are routable network address prefixes that address physical 480 hosts within the network. They may be assigned from a global address 481 block [RFC3587], or be based on unique local IPv6 unicast addresses 482 as described in [RFC4193]. 484 /* ILA with a global unicast locator */ 485 |3 bits| N bits | M bits | 61-N-M | 64 bits | 486 +------+-------------+---------+---------------------------------+ 487 | 001 | Global prefix | Subnet | Host | Identifier | 488 +------+---------------+---------+--------+----------------------+ 490 /* ILA with a unique local IPv6 unicast locator */ 491 | 7 bits |1| 40 bits | 16 bits | 64 bits | 492 +--------+-+------------+-----------+----------------------------+ 493 | FC00 |L| Global ID | Host | Identifier | 494 +--------+-+------------+-----------+----------------------------+ 496 3 Operation 498 This section describes operation methods for using identifier-locator 499 addressing with network virtualization. 501 3.1 Identifier to locator mapping 503 An application initiates a communication or flow using a SIR address 504 or virtual address for a destination. In order to send a packet on 505 the network, the destination identifier is mapped to a locator. The 506 mappings are not expected to change frequently, so it is likely that 507 locator mappings can be cached in the flow contexts. 509 Identifier to locator mapping is nearly identical to the mechanism 510 needed in virtual networking to map a virtual network and virtual 511 host address to a physical host. These mechanisms should leverage a 512 common solution. 514 The mechanisms of propagating and maintaining identifier to locator 515 mappings are outside the scope of this document. 517 3.2 Address translations 519 With ILA, address translation is performed to convert SIR addresses 520 to ILA addresses, and ILA addresses to SIR addresses. Translation may 521 be done on either the source or destination address of a packet. 522 Translation is stateless and is done per IPv6-to-IPv6 Network Prefix 523 Translation (NPTv6) ([RFC6296]). 525 3.2.1 SIR to ILA address translation 527 When transmitting a packet, the locator for both the source and 528 destination ILA addresses might need to be set before packet is sent 529 on the wire. In the case that packet was created using a standard 530 identifier representation, the SIR prefix is overridden with a 531 locator. Since this operation is potentially done for every packet 532 the process should be very efficient. Presumably, a host will 533 maintain a cache of identifier locator mappings with a fast lookup 534 function. If there is a connection state associated with the 535 communication, the locator information may be cached with the 536 connection state to obviate the need to perform a lookup per packet. 538 The typical steps to transmit a packet using ILA are: 540 1) Stack creates a packet with source address set to SIR address 541 for the local identity, and the destination address is set to 542 the SIR address for the peer. The peer SIR address may have been 543 discovered through DNS or other means. 545 2) Stack overwrites the SIR prefix in the source address with an 546 appropriate locator for the local host. 548 3) Stack overwrites the SIR prefix in the destination address with 549 a locator for the peer. This locator is discovered by a lookup 550 in the locator to identifier mappings. 552 4) If a transport checksum includes a pseudo header that covered 553 the original addresses, the checksum needs to be updated. This 554 should be akin to the checksum update needed in address 555 translation for NAT ([RFC6296]). 557 5) Packet is sent on the wire. The network routes the packet to the 558 host indicated by the locator. 560 3.2.2 ILA to SIR address translation 562 Upon reception, the identifier is used to match a valid address on 563 the host or a connection context. In order to avoid having networking 564 stack operate on a new address type, identifier-locator addresses may 565 be translated to standard identifier representation addresses by 566 overwriting the locator in the address with a SIR prefix. 568 Receive processing may be: 570 1) Packet is received, the destination locator matches an interface 571 address prefix on the host. 573 2) A lookup is performed on the destination identifier to match to 574 a local identifier. If the lookup is address based, the SIR 575 address can be created for the destination (overwrite locator 576 with a SIR prefix). 578 3) Perform any checks as necessary. Validate locators, identifiers, 579 and check that packet is not illegitimately crossing virtual 580 networks (see below). 582 4) Forward packet to application processing. If necessary, the 583 addresses in the packet can be converted to SIR addresses in 584 place. Changing the addresses may also entail updating the 585 checksum to reflect that (again similar to a NAT translation). 587 3.3 Virtual networking operation 589 When using ILA with virtual networking identifiers, address 590 translation is performed to convert tenant virtual network and 591 virtual addresses to ILA addresses, and ILA addresses back to a 592 virtual network and tenant's virtual addresses. Address translation 593 is performed similar to the SIR translation cases described above. 595 A packet with virtual networking ILA addresses must be verified on 596 reception. By default, the virtual network identifiers in the source 597 and destination addresses must match or the packet is dropped. This 598 would include the case that one address is using ILA with virtual 599 network identifier and the other is not. 601 3.3.1 Crossing virtual networks 603 With explicit configuration, virtual network hosts may communicate 604 directly with virtual hosts in another virtual network. This might be 605 done to allow services in one virtual network to be accessed from 606 another (by prior agreement between tenants). In this case, the 607 virtual networking identifiers in the source and destination 608 addresses won't match. This does require that identifiers are unique 609 in a shared space. 611 3.3.2 IPv4/IPv6 protocol translation 613 An IPv4 tenant may send a packet that is converted to an IPv6 packet 614 with ILA addresses having IPv4 virtual networking identifiers. 615 Similarly, an IPv6 packet with ILA addresses may be converted to an 616 IPv4 packet to be received by an IPv4-only tenant. These are 617 IPv4/IPv6 stateless protocol translations as described in [RFC6144] 618 and [RFC6145]. 620 3.4 One sided ILA 622 It is not required that ILA be used for both and destination 623 addresses. For instance a statically addressed server may provide 624 service to virtual hosts or migratable jobs. Note that even though 625 the server's address is static, locators for its ILA clients may 626 change so the server will need identifier to locator mappings. 628 3.5 Checksum handling 630 TCP and UDP checksum includes a pseudo checksum that covers the IP 631 addresses in a packet. In the case of identifier-locator addressing 632 the checksum must include the actual addresses set in the packet on 633 the wire. So when creating a checksum for transmit, or verifying a 634 checksum on receive, identifier-locator addressing must be taken into 635 account. 637 3.5.1 Transmit checksum 639 If the source and destination locators are available when the 640 transport checksum is being set, these can be used to calculate the 641 pseudo checksum for the packet. This might be applicable in cases 642 where locator information is cached within the context for a 643 transport connection. 645 If the locators are set after the transport layer processing, the 646 checksum can be updated following NAT procedures for address 647 translation. 649 3.5.2 Receive checksum 651 Similar to the transmit case, if address translation occurs before 652 transport layer processing the checksum must be adjusted per NAT. An 653 implementation may verify a transport checksum before converting 654 addresses to standard identifier representation to potentially 655 obviate modifying the transport checksum to account for translation. 657 3.6 Address selection 659 There may be multiple possibilities for creating either a source or 660 destination address. A node may be associated with more than one 661 identifier, and there may be multiple locators for a particular 662 identifier. The selection of an identifier occurs at flow creation 663 and must be constant for the duration of the flow. Locator selection 664 should be done once per flow, however may change (in the case of a 665 migrating connection it will change). ILA address selection should 666 follow guidelines in Default Address Selection for Internet Protocol 667 Version 6 (IPv6) ([RFC6742]). 669 4. Communication scenarios 671 This section describes the use of identifier-locator addressing in 672 several scenarios. 674 4.1 Terminology 676 A formal notation for identifier-locator addressing with ILNP is 677 described in [RFC6740]. We extend this to include for network 678 virtualization cases. 680 Basic terms are: 682 A = IP Address 683 I = Identifier 684 L = Locator 685 LUI = Locally unique identifier 686 VNI = Virtual network identifier 687 VA = An IPv4 or IPv6 virtual address 688 VAX = An IPv6 networking identifier (IPv6 VA mapped to VAX) 689 SIR = Prefix for standard identifier representation 690 EXA = An Internet routable prefix, may be use as a SIR 691 VNET = IPv6 prefix for a tenant 693 An ILA IPv6 address is denoted by 695 L:I 697 A transport endpoint IPv6 address with a locally unique identifier 698 with SIR prefix is denoted by 700 SIR:LUI 702 A virtual identifier with a virtual network identifier and a virtual 703 IPv4 address is denoted by 705 VNI:VA 707 An ILA IPv6 address with a virtual networking identifier for IPv4 708 would then be denoted 710 L:(VNI:VA) 712 The local and remote address pair in a packet or endpoint is denoted 714 A,A 716 An address translation sequence from transport visible addresses to 717 ILA addresses for transmission on the network and back to transport 718 endpoint addresses at the receiver has notation: 720 A,A -> L:I,L:I -> A,A 722 4.2 Identifier objects 724 Identifier-locator addressing is broad enough in scope to address may 725 different types of networking objects within a data center. For 726 descriptive purposes we classify these objects as tasks or tenant 727 systems. 729 A task is a unit of execution that runs in the data center networks. 730 These do not run in a virtual machine, but typically run in the 731 native host context perhaps within containers. Task are the execution 732 mechanism for native jobs in the data center. 734 A tenant system, or TS, is a unit of execution which runs on behalf 735 of a tenant in network virtualization. A TS may be implemented as a 736 virtual machine or possibly using containers mechanisms. In either 737 case, a virtual overlay network is implemented on behalf of a tenant, 738 and isolation between virtual networks is paramount. 740 A network service is a task that provides some network wide service 741 such as DNS, remote storage, remote logging, etc. A network service 742 may be accessed by tenant systems as well as other tasks. 744 4.2 Reference network for scenarios 746 The figure below provides an example network topology with ILA 747 addressing in use. In this example, there are four hosts in the 748 network with locators L1, L2, L3 , and L4. Three tasks with 749 identifiers T1, T2, and T3 exist as well as a networking service task 750 with identifier T4. The identifiers for these tasks may be locally 751 unique identifiers. There are two virtual networks VNI1 and VNI2, and 752 four tenant systems addressed as: VA1 and VA2 in VNI1, VA3 and VA4 in 753 VNI2. The network is connected to the Internet via a gateway. 755 ` ............. 756 . . 757 +-----------------+ . Internet . +-----------------+ 758 | Host L1 | . . | Host L2 | 759 | +-------------+ | ............. | +-------------+ | 760 | | TS VNI1:VA1 | | | | | TS VNI1:VA2 | | 761 | +-------------+ +---+ +-----+-----+ +---+ +-------------+ | 762 | +-------------+ | | | Gateway | | | +-------------+ | 763 | | Task T1 | | | +-----+-----+ | | | TS VNI2:VA3 | | 764 | +-------------+ | | | | | +-------------+ | 765 +-----------------+ | ............. | +-----------------+ 766 +-----. Data .-----+ 767 +-----------------+ . Center . +-----------------+ 768 | Host L3 | +-----. Network .---+ | Host L4 | 769 | +-------------+ | | ............. | | +-------------+ | 770 | | Task T2 | | | | | | VM VNI2:VA4 | | 771 | +-------------+ +---+ +-----| +-------------+ | 772 | +-------------+ | | +-------------+ | 773 | | Task T3 | | | | Serv. T4 | | 774 | +-------------+ | | +-------------+ | 775 +-----------------+ +-----------------+ 777 There are several communications scenario that can be considered: 779 1) Task to task (service) 780 2) Task to Internet 781 3) Internet to task 782 4) TS to service 783 5) Task to TS 784 6) TS to Internet 785 7) Internet to TS 786 8) IPv4 TS to service 787 9) TS to TS in same virtual network using IPv6 788 10) TS to TS in same virtual network using IPv4 789 11) TS to TS in different virtual network using IPv6 790 12) TS to TS in different virtual network using IPv4 791 13) IPv4 TS to IPv6 TS in different virtual networks 793 4.3 Scenario 1: Task to task 795 The transport endpoints for task to task communication are the SIR 796 addresses for the tasks. When a packet is sent on the wire, the 797 locators are set in source and destination addresses of the packet. 798 On reception the source and destination addresses are converted back 799 to SIR representations for processing at the transport layer. 801 If task T1 is communicating with task T2, the ILA translation 802 sequence would be: 804 SIR:T1,SIR:T2 -> // Transport endpoints on T1 805 L1:T1,L3:T2 -> // ILA used on the wire 806 SIR:T1,SIR:T2 // Received at T2 808 4.4 Scenario 2: Task to Internet 810 Communication from a task to the Internet is accomplished through use 811 of a gateway that translates the internal locator for the task source 812 to an externally routable prefix. 814 If task T1 is sending to an address Iaddr on the Internet, the ILA 815 translation sequence would be: 817 SIR:T1,Iaddr -> // Transport endpoints at T1 818 L1:T1,Iaddr -> // On the wire in data center 819 EXA:T1,Iaddr // In the Internet 821 EXA is a globally routable prefix usable on the Internet. On egress 822 from the data center network, a gateway sets EXA in the source 823 address. If the SIR prefix is globally routable then this may be the 824 same as EXA. 826 4.5 Scenario 3: Internet to task 828 An Internet host transmits packet to a task using an externally 829 routable prefix and an identifier. The subnet prefix routes the 830 packet to a gateway for the data center. The gateway translates the 831 destination to an ILA address. 833 If a host on the Internet with address Iaddr is sends a packet to 834 task T3, the ILA translation sequence would be: 836 Iaddr,EXA:T3 -> // Transport endpoint at Iaddr 837 Iaddr,L1:T3 -> // On the wire in data center 838 Iaddr,SIR:T3 // Received at T3 840 EXA is a globally routable prefix usable on the Internet. On ingress 841 into the data center, a gateway overwrites this with a locator. If 842 the SIR prefix for T3 is globally routable then this may be the same 843 as EXA. 845 4.6 Scenario 4: TS to service task 847 A tenant can communicate with a data center service using the SIR 848 address of the service. The source address is translated from the 849 tenant's address and prefix to VNID and VADDR. Locators must be set 850 properly for transmission. 852 If TS VA1 is communicating with service task T4, the ILA translation 853 sequence would be: 855 VNET:VA1,SIR:T4-> // Transport endpoints in TS 856 L1:(VNI1:VAX1),L3:T4-> // On the wire 857 SIR:(VNI1:VAX1),SIR:T4 // Received at T4 859 VNET is the address prefix for the tenant. Alternatively, the service 860 may map the tenant's address to its SIR representation to use VNET 861 for the endpoint: 863 VNET:VA1,SIR:T4-> // Transport endpoints in TS 864 L1:(VNI1:VAX1),L3:T4-> // On the wire 865 VNET:VA1,SIR:T4 // Received at T4 867 Note that from the service point of view there is no material 868 difference between a peer that is a tenant system versus a peer that 869 is a task. 871 4.7 Scenario 5: Task to TS 873 A task can communicate with a TS through it's externally visible 874 address, or by its virtual networking identifier and virtual address. 876 If task T2 is communicating with TS VA4, the ILA translation sequence 877 would be: 879 SIR:T2,SIR:(VNI2:VA4) -> // Transport endpoints at T2 880 L3:T2,L4:(VNI2:VA4) -> // On the wire 881 SIR:T2,VNET:VA4 // Received at TS 883 Alternatively, the task can use the VNET prefix to address a TS: 885 SIR:T2,VNET:VA4 -> // Transport endpoints at T2 886 L3:T2,L4:(VNI2:VAX4) -> // On the wire 887 SIR:T2,VNET:VA4 // Received at TS 889 4.8 Scenario 6: TS to Internet 891 Communication from a TS to the Internet is accomplished through use 892 of a gateway that translates the locator in the TS's source address 893 back to the tenant's prefix. This assumes that the tenant's prefix is 894 properly routed to the data center network. 896 If TS VA4 transmits a packet to address Iaddr on the Internet, the 897 ILA translation sequence would be: 899 VNET:VA4,Iaddr -> // Transport endpoints at TS 900 L4:(VNI2:VAX4),Iaddr -> // On the wire in data center 901 VNET:VA4,Iaddr // On the Internet 903 4.9 Scenario 7: Internet to TS 905 An Internet host transmits a packet to a tenant system using an 906 externally routable tenant prefix and a tenant system identifier. The 907 prefix routes the packet to a gateway for the data center. The 908 gateway translates the destination to an ILA address. 910 If a host on the Internet with address Iaddr is sending to TS VA4, 911 the ILA translation sequence would be: 913 Iaddr,VNET:VA4 -> // Endpoint at Iaddr 914 Iaddr,L4:(VNI2:VAX4) -> // On the wire in data center 915 Iaddr,VNET:VA4 // Received at TS 917 4.10 Scenario 8: IPv4 TS to service 919 A TS that is IPv4-only may communicate with a data center network 920 service using NAT protocol translation. The network service would 921 represented as an IPv4 address in the tenant's address space, and 922 stateless NAT64 should be usable as described in [RFC6145]. 924 If TS VA2 communicates with service task T4, the ILA translation 925 sequence would be: 927 VA2,ADDR4 -> // IPv4 endpoints at TS 928 L2:(VNI1:VA2),L4:T4 -> // On the wire in data center 929 SIR:(VNI1:VA2),SIR:T4 // Received at task 931 VA2 is the IPv4 address in the tenant's virtual network, ADDR4 is an 932 address in the tenant's address space that maps to the network 933 service. 935 The reverse path, task sending to a TS with an IPv4 address, requires 936 a similar protocol translation. 938 For service task T4 to communicate with TS VA2, the ILA translation 939 sequence would be: 941 SIR:T4,SIR:(VNI1:VA2) -> // Endpoints at T4 942 L4:T4,L2:(VNI1:VA2) -> // On the wire in data center 943 ADDR4,VA2 -> // IPv4 endpoint at TS 945 4.11 TS to TS in the same virtual network 947 ILA may be used to allow tenants within a virtual network to 948 communicate without the need for explicit encapsulation headers. 950 4.11.1 Scenario 9: TS to TS in same VN using IPV6 952 If TS VA1 sends a packet to TS VA2, the ILA translation sequence 953 would be: 955 VNET:VA1,VNET:VA2 -> // Endpoints at VA1 956 L1:(VNI1:VAX1),L2:(VNI1,VAX2) -> // On the wire 957 VNET:VA1,VNET:VA2 -> // Received at VA2 959 4.11.2 Scenario 10: TS to TS in same VN using IPv4 961 For two tenant systems to communicate using IPv4 and ILA, IPv4/IPv6 962 protocol translation is done both on the transmit and receive. 964 If TS VA1 sends an IPv4 packet to TS VA2, the ILA translation 965 sequence would be: 967 VA1,VA2 -> // Endpoints at VA1 968 L1:(VNI1:VA1),L2:(VNI1,VA2) -> // On the wire 969 VA1,VA2 // Received at VA2 971 4.12 TS to TS in a different virtual network 973 A tenant system may be allowed to communicate with another tenant 974 system in a different virtual network. This should only be allowed 975 with explicit policy configuration. 977 4.12.1 Scenario 11: TS to TS in a different VN using IPV6 979 For TS VA4 to communicate with TS VA1 using IPv6 the translation 980 sequence would be: 982 VNET2:VA4,VNET1:VA1-> // Endpoints at VA4 983 L4:(VNI2:VA4),L1:(VNI1,VA1)-> // On the wire 984 SIR:VA4,VNET1:VA1 // Received at VA1 986 Alternatively, the the VNET prefix can address a TS: 988 VNET2:VA4,VNET1:VA1-> // Endpoint at VA4 989 L4:(VNI2:VAX4),L1:(VNI1,VAX1)-> // On the wire 990 VNET2:VA4,VNET1:VA1 // Received at VA1 992 4.12.2 Scenario 12: TS to TS in a different VN using IPv4 994 To allow IPv4 tenant systems in different virtual networks to 995 communicate with each other, an address representing the peer would 996 be mapped into the tenant's address space. IPv4/IPv6 protocol 997 translation is done on transmit and receive. 999 For TS VA4 to communicate with TS VA1 using IPv4 the translation 1000 sequence may be: 1002 VA4,SADDR1 -> // IPv4 endpoint at VA4 1003 L4:(VNI2:VA4),L1:(VNI1,VA1)-> // On the wire 1004 SADDR4,VA1 // Received at VA1 1006 SADDR1 is the mapped address for VA1 in VA4's address space, and 1007 SADDR4 is the mapped address for VA4 in VA1's address space. 1009 4.12.3 Scenario 13: IPv4 TS to IPv6 TS in different VNs 1011 Communication may also be mixed so that an IPv4 tenants system can 1012 communicate with an IPv6 tenant system in another virtual network. 1013 IPv4/IPv6 protocol translation is done on transmit. 1015 For VM VA4 using IPv4 to communicate with VM VA1 using IPv6 the 1016 translation sequence may be: 1018 VA4,SADDR1 -> // IPv4 endpoint at VA4 1019 L4:(VNI2:VA4),L1:(VNI1,VAX1)-> // On the wire 1020 SIR:VA4,VNET1:VA1 // Received at VA1 1022 Alternatively the task can use the VNET prefix to address a TS: 1024 VA4,SADDR1 -> // IPv4 endpoint at VA4 1025 L4:(VNI2:VA4),L1:(VNI1,VA1)-> // On the wire 1026 VNET2:VA4,VNET1:VA1 // Received at VA1 1028 SADDR1 is the mapped IPv4 address for VA1 in VA4's address space. 1030 5. Use cases 1032 This section highlights some use cases for identifier-locator 1033 addressing. 1035 5.1 Data center virtualization 1037 A primary motivation for identifier-locator addressing is data center 1038 virtualization. Virtualization within a data center permits 1039 malleability and flexibility in using data center resources. In 1040 particular, identifier-locator addressing virtualizes networking to 1041 allow flexible job scheduling and possibility of live task migration. 1043 5.1.1 Job scheduling 1045 In the usual data center model, jobs are scheduled to run as tasks on 1046 some number of machines. A distributed job scheduler provides the 1047 scheduling which may entail considerable complexity since jobs will 1048 often have a variety of resource constraints. The scheduler takes 1049 these constraints into account while trying to maximize utility of 1050 the data center in terms utilization, cost, latency, etc. Data center 1051 jobs do not typically run in virtual machines (VMs), but may run 1052 within containers. Containers are mechanisms that provide resource 1053 isolation between tasks running on the same host OS. These resources 1054 can include CPU, disk, memory, and networking. 1056 A fundamental problem arises in that once a task for a job is 1057 scheduled on a machine, it often needs to run to completion. If the 1058 scheduler needs to schedule a higher priority job or change resource 1059 allocations, there may be little recourse but to kill tasks and 1060 restart them on a different machine. In killing a task, progress is 1061 lost which results in increased latency and wasted CPU cycles. Some 1062 tasks may checkpoint progress to minimize the amount of progress 1063 lost, but this is not a very transparent or general solution. 1065 An alternative approach is to allow transparent job migration. The 1066 scheduler may migrate running jobs from one machine to another. 1068 Under the orchestration of the job scheduler, the steps to migrate a 1069 job may be: 1071 1) Stop running tasks for the job. 1072 2) Package the run time state of the job. The run time state is 1073 derived from the containers for the jobs. 1074 3) Send the run time state of the job to the new machine where the 1075 job is to run. 1076 4) Instantiate the job's state on the new machine. 1077 5) Start the tasks for the job continuing from the point at which 1078 it was stopped. 1080 This model similar to virtual machine (VM) migration except that the 1081 run time state is typically much less data-- just task state as 1082 opposed to a full OS image. Task state may be compressed to reduce 1083 latency in migration. 1085 The networking state of interest to migrate are the addresses used by 1086 the task and open transport connections. 1088 5.1.1 Address migration 1090 To allow for task migration, each migratable task is assigned a 1091 unique address which be moved to a new location at task migration. 1093 With identifier-locator addressing, tasks are assigned locally unique 1094 identifiers (see below for assignment techniques). A LUI is combined 1095 with a SIR prefix to give each task its own IPv6 address. To 1096 communicate with a running task, the LUI is mapped to a locator which 1097 is placed in the on-the-wire packet as discussed above. When a task 1098 migrates to a new machine, the identifier to locator mapping for the 1099 task is updated to reflect the change. 1101 5.1.2 Connection migration 1103 When a task and its addresses are migrated between machines, the 1104 disposition of existing TCP connections needs to be considered. 1106 The simplest course of action is to drop TCP connections across a 1107 migration. Since migrations should be relatively rare events, it is 1108 conceivable that TCP connections could be automatically closed in the 1109 network stack during a migration event. If the applications running 1110 are known to handle this gracefully (i.e. reopen dropped connections) 1111 then this may be viable. 1113 For seamless migration, open connections may be migrated between 1114 hosts. Migration of these entails pausing the connection, packaging 1115 connection state and sending to target, instantiating connection 1116 state in the peer stack, and restarting the connection. From the time 1117 the connection is paused to the time it is running again in the new 1118 stack, packets received for the connection should be silently 1119 dropped. For some period of time, the old stack will need to keep a 1120 record of the migrated connection. If it receives a packet, it should 1121 either silently drop the packet or forward it to the new location. 1123 5.1.3 Task identifier generation 1125 Potentially every task in a data center could be migratable as long 1126 as each task is assigned a unique identifier. Since the identifier is 1127 fifty-nine bits it is conceivable that identifiers could be allocated 1128 using a shared counter or based on a timestamp. 1130 5.1.3.1 Gobally unique identifiers method 1132 For small to moderate sized deployments the technique for creating 1133 locally assigned global identifiers described in [RFC4193] could be 1134 used. In this technique a SHA-1 digest of the time of day in NTP 1135 format and an EUI-64 identifier of the local host is performed. N 1136 bits of the result are used as the globally unique identifier. 1138 The probability that two or more of these IDs will collide can be 1139 approximated using the formula: 1141 P = 1 - exp(-N**2 / 2**(L+1)) 1143 where P is the probability of collision, N is the number of 1144 identifiers, and L is the length of an identifier. 1146 The following table shows the probability of a collision for a range 1147 of identifiers using a 61-bit length. 1149 Identifiers Probability of Collision 1150 1000 2.1684*10^-13 1151 10000 2.1684*10^-11 1152 100000 2.1684*10^-09 1153 1000000 2.1684*10^-07 1155 Note that locally unique identifiers may be ephemeral, for instance a 1156 task may only exist for a few seconds. This should be considered when 1157 determining the probability of identifier collision. 1159 5.1.3.2 Universally Unique Identifiers method 1161 For larger deployments, hierarchical allocation may be desired. The 1162 techniques in Universally Unique IDentifier (UUID) URN ([RFC4122]) 1163 can be adapted for allocating unique task identifiers in sixty-one 1164 bits. An identifier is split into two components: a registrar prefix 1165 and sub-identifier. The registrar prefix defines an identifier block 1166 which is managed by the same host, the sub-identifier is a unique 1167 value within the registrar block. 1169 For instance, a task identifier could be created on the initial 1170 running host that runs a task. The identifier could be composed of a 1171 24 bit host identifier followed by a 37 bit timestamp. Assuming that 1172 a host can start up to 100 tasks per second, this allows 43.5 years 1173 before wrap around. 1175 /* Task identifier with host registrar and timestamp */ 1176 |3 bits| 24 bits | 37 bits | 1177 +------+-------------------+-------------------------------------+ 1178 | 0x1 | Host identifier | Timestamp Identifier | 1179 +----------------------------------------------------------------+ 1181 Hierarchical allocation may also be used to support hierarchical 1182 locator lookup. 1184 5.1.3.3 Duplicate identifier detection 1186 As part of implementing the locator to identifier mapping, duplicate 1187 identifier detection may be implemented in a centralized control 1188 plane. A registry of identifiers would be maintained. When a node 1189 creates an identifier it registers the identifier, and when the 1190 identifier is no longer in use (e.g. task completes) the identifier 1191 is unregistered. The control plane should able to detect a 1192 registration attempt for an existing identifier and deny the request. 1194 5.2 Multi-tenant virtualization 1196 Identifier-locator addressing may be used as an alternative to nvo3 1197 encapsulation protocols (such as GUE [GUE]). In multi-tenant 1198 virtualization, overlay networks are established for various tenants 1199 to create virtual networks and a tenant's nodes are assigned virtual 1200 addresses. Virtual networking identifiers are used to encode a 1201 virtual network identifier and a virtual address in an ILA address. 1203 An advantage of identifier-locator addressing is that the overhead of 1204 encapsulation is reduced and use of virtualization can be transparent 1205 to the underlying network. A downside is that some features that use 1206 additional data in an encapsulation aren't available (security option 1207 in GUE for instance [GUESEC]). 1209 Identifier-locator addressing may be appropriate in network 1210 virtualization where the users are trusted, for instance if virtual 1211 networks were assigned to different departments within an enterprise. 1212 Network virtualization in this context provides a means of isolation 1213 of traffic belonging to different departments of a single tenant. If 1214 this isolation is broken and traffic illegitimately crosses between 1215 virtual networks, this is not considered a significant security risk. 1217 The communication scenarios section above describes communication 1218 within a virtual network, communications with network services, and 1219 communication with hosts on the Internet. 1221 5.2.1 IPv6 over IPv6 network virtualization 1223 In a canonical implementation of overlay networks for network 1224 virtualization, encapsulation headers are used between outer and IP 1225 inner headers which contains a virtual network identifier and 1226 possibly other data. Typical encapsulation of an IPv6 packet using 1227 GUE is illustrated below: 1229 +-------------------------------+ 1230 | | 1231 | IPv6 header | 1232 | | 1233 |-------------------------------| 1234 | | 1235 | UDP/GUE Header | 1236 | | 1237 |-------------------------------| 1238 | | 1239 | IPv6 header | 1240 | | 1241 |-------------------------------| 1242 | | 1243 | TCP header | 1244 | | 1245 +-------------------------------+ 1247 The addresses in the outer IPv6 header indicate the physical nodes 1248 (source and destination NVEs) in the network. The inner IPv6 1249 addresses are IPv6 addresses within the virtual network specified by 1250 the VNID in the GUE header. 1252 Using ILA eliminates the encapsulation headers and inner IP headers: 1254 +-------------------------------+ 1255 | | 1256 | IPv6 header | 1257 | | 1258 |-------------------------------| 1259 | | 1260 | TCP header | 1261 | | 1262 +-------------------------------+ 1264 The IPv6 addresses are ILA addresses with virtual networking IPv6 1265 identifiers. The encoded VNID indicates the virtual network the 1266 address belongs to, and the encoded VADDR provides the low order 32 1267 bits of the virtual address for both source and destination. The 1268 tenant visible upper 96 bits of the IPv6 address is inferred from the 1269 VNID. 1271 If the destination is multicast, the appropriate multicast identifier 1272 can be used in the destination address. 1274 5.2.2 IPv4 over IPv6 network virtualization 1276 The figure below illustrates the protocol headers when encapsulating 1277 a tenant's IPv4 packet using GUE. 1279 +-------------------------------+ 1280 | | 1281 | IPv6 header | 1282 | | 1283 |-------------------------------| 1284 | | 1285 | UDP/GUE Header | 1286 | | 1287 |-------------------------------| 1288 | | 1289 | IPv4 header | 1290 | | 1291 |-------------------------------| 1292 | | 1293 | TCP header | 1294 | | 1295 +-------------------------------+ 1297 The addresses in the outer IPv6 header indicate the physical nodes 1298 (source and destination NVEs) in the network. The inner IPv4 1299 addresses are in the virtual network specified by the VNID in the GUE 1300 header. 1302 Using ILA eliminates the encapsulation headers and inner IP headers: 1304 +-------------------------------+ 1305 | | 1306 | IPv6 header | 1307 | | 1308 |-------------------------------| 1309 | | 1310 | TCP header | 1311 | | 1312 +-------------------------------+ 1314 The IPv6 addresses are ILA addresses with virtual networking IPv4 1315 identifiers. The encoded VNID indicates the virtual network the 1316 addresses belongs to, and the encoded VADDRs provide the IPv4 virtual 1317 addresses for both source and destination. The IPv4 virtual address 1318 are visible to the tenant systems. 1320 6 Security Considerations 1322 Security must be considered when using identifier-locator addressing. 1323 In particular, the risk of address spoofing or address corruption 1324 must be addressed. To classify this risk the set possible 1325 destinations for a packet are classified as trusted or untrusted. The 1326 set of possible destinations includes those that a packet may 1327 inadvertently be sent due to address or header corruption. 1329 If the set of possible destinations are trusted then packet 1330 misdelivery is considered relatively innocuous. This might be the 1331 case in a data center if all nodes were tightly controlled under 1332 single management. Identifier-locator addressing can be used this 1333 case without further additional security. 1335 If the set of possible destinations are untrusted, then packet 1336 misdelivery is considered detrimental. This may be the case that 1337 virtual machines with third party applications and OS are running in 1338 the network. A malicious user may be snooping for misdelivered 1339 packets, or may attempt to spoof addresses. Identifier locator 1340 addressing should be used with stronger security and isolation 1341 mechanisms such as IPsec or GUESEC. 1343 7 IANA Considerations 1345 There are no IANA considerations in this specification. 1347 8 References 1349 8.1 Normative References 1351 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1352 (IPv6) Specification", RFC 2460, December 1998. 1354 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1355 Architecture", RFC 4291, February 2006. 1357 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1358 Translation", RFC 6296, June 2011. 1360 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1361 "Default Address Selection for Internet Protocol Version 1362 6 (IPv6)", RFC 6724, September 2012. 1364 8.2 Informative References 1366 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1367 (IPv6) Specification", RFC 2460, December 1998. 1369 [RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1370 Protocol (ILNP) Architectural Description", RFC 6740, 1371 November 2012. 1373 [RFC6741] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1374 Protocol (ILNP) Engineering Considerations", RFC 6741, 1375 November 2012. 1377 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1378 and E. Lear, "Address Allocation for Private Internets", 1379 BCP 5, RFC 1918, February 1996. 1381 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 1382 Hain, "Representing Internet Protocol version 6 (IPv6) 1383 Addresses in the Domain Name System (DNS)", RFC 3363, 1384 August 2002. 1386 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 1387 Unicast Address Format", RFC 3587, August 2003. 1389 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1390 Addresses", RFC 4193, October 2005. 1392 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1393 IPv4/IPv6 Translation", RFC 6144, April 2011. 1395 [GUE] Herbert, T., and Yong, L., "Generic UDP Encapsulation", 1396 draft-herbert-gue-02, work in progress. 1398 [GUESEC] Yong L., and Herbert, T. "Generic UDP Encapsulation (GUE) 1399 for Secure Transport", draft-hy-gue-4-secure-transport- 1400 00, work in progress 1402 9 Acknowledgments 1404 The authors would like to thank Mark Smith, Lucy Yong, and Erik Kline 1405 for their insightful comments for this draft; Roy Bryant, Lorenzo 1406 Colitti, Mahesh Bandewar, and Erik Kline for their work on defining 1407 and applying ILA. 1409 Authors' Addresses 1411 Tom Herbert 1412 Google 1413 1600 Amphitheatre Parkway 1414 Mountain View, CA 1415 EMail: therbert@google.com