idnits 2.17.1 draft-herbert-nvo3-ila-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: ---------------------------------------------------------------------------- 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 (October 9, 2015) is 3123 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: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC7365' is mentioned on line 208, but not defined == Missing Reference: 'RFC7346' is mentioned on line 527, but not defined == Missing Reference: 'RFC6145' is mentioned on line 1088, but not defined ** Obsolete undefined reference: RFC 6145 (Obsoleted by RFC 7915) == Missing Reference: 'RFC4122' is mentioned on line 1316, but not defined == Unused Reference: 'RFC4291' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'RFC6296' is defined on line 1224, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-08) exists of draft-ietf-nvo3-arch-03 == 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 Tom Herbert 3 Intended Status: Informational Facebook 4 Expires: April 11, 2015 October 9, 2015 6 Identifier-locator addressing for network virtualization 7 draft-herbert-nvo3-ila-01 9 Abstract 11 This specification describes identifier-locator addressing (ILA) in 12 IPv6 for network virtualization. Identifier-locator addressing 13 differentiates between location and identity of a network node. Part 14 of an address expresses the immutable identity of the node, and 15 another part indicates the location of the node which can be dynamic. 16 Identifier-locator addressing can be used to efficiently implement 17 overlay networks for network virtualization 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/1id-abstracts.html 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 Copyright and License Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1 Network virtualization . . . . . . . . . . . . . . . . . . . 5 60 2.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . 5 61 2.1.2 Multi-tenant virtualization . . . . . . . . . . . . . . 6 62 2.2 Data center virtualization . . . . . . . . . . . . . . . . . 6 63 2.2.1 Address per task . . . . . . . . . . . . . . . . . . . . 6 64 2.2.2 Job scheduling . . . . . . . . . . . . . . . . . . . . . 7 65 3 Address formats . . . . . . . . . . . . . . . . . . . . . . . . 8 66 3.1 ILA format . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.2 Identifier format . . . . . . . . . . . . . . . . . . . . . 9 68 3.3 Identifier types . . . . . . . . . . . . . . . . . . . . . . 10 69 3.4 Interface identifiers . . . . . . . . . . . . . . . . . . . 10 70 3.5 Locally unique identifiers . . . . . . . . . . . . . . . . . 10 71 3.6 Virtual networking identifiers for IPv4 . . . . . . . . . . 11 72 3.7 Virtual networking identifiers for IPv6 . . . . . . . . . . 11 73 3.7.1 Virtual networking identifiers for IPv6 unicast . . . . 11 74 3.7.2 Virtual networking identifiers for IPv6 multicast . . . 12 75 3.8 Standard identifier representation addresses . . . . . . . . 13 76 3.8.1 SIR for locally unique identifiers . . . . . . . . . . . 14 77 3.8.2 SIR for virtual addresses . . . . . . . . . . . . . . . 14 78 3.9 Locators . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 4 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 4.1 Identifier to locator mapping . . . . . . . . . . . . . . . 15 81 4.2 Address translations . . . . . . . . . . . . . . . . . . . . 16 82 4.2.1 SIR to ILA address translation . . . . . . . . . . . . . 16 83 4.2.2 ILA to SIR address translation . . . . . . . . . . . . . 17 84 4.3 Virtual networking operation . . . . . . . . . . . . . . . . 17 85 4.3.1 Crossing virtual networks . . . . . . . . . . . . . . . 17 86 4.3.2 IPv4/IPv6 protocol translation . . . . . . . . . . . . . 17 87 4.4 Checksum handling . . . . . . . . . . . . . . . . . . . . . 18 88 4.4.1 Transmit checksum . . . . . . . . . . . . . . . . . . . 18 89 4.4.2 Receive checksum . . . . . . . . . . . . . . . . . . . . 18 90 4.5 Address selection . . . . . . . . . . . . . . . . . . . . . 18 91 4.6 SIR address routing . . . . . . . . . . . . . . . . . . . . 18 92 4.7 Duplicate identifier detection . . . . . . . . . . . . . . . 19 94 5. Communication scenarios . . . . . . . . . . . . . . . . . . . . 19 95 5.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 20 96 5.2 Identifier objects . . . . . . . . . . . . . . . . . . . . . 21 97 5.3 Reference network for scenarios . . . . . . . . . . . . . . 21 98 5.4 Scenario 1: Task to task . . . . . . . . . . . . . . . . . . 22 99 5.5 Scenario 2: Task to Internet . . . . . . . . . . . . . . . . 22 100 5.6 Scenario 3: Internet to task . . . . . . . . . . . . . . . . 23 101 5.7 Scenario 4: TS to service task . . . . . . . . . . . . . . . 23 102 5.8 Scenario 5: Task to TS . . . . . . . . . . . . . . . . . . . 23 103 5.9 Scenario 6: TS to Internet . . . . . . . . . . . . . . . . . 23 104 5.10 Scenario 7: Internet to TS . . . . . . . . . . . . . . . . 24 105 5.11 Scenario 8: IPv4 TS to service . . . . . . . . . . . . . . 24 106 5.12 TS to TS in the same virtual network . . . . . . . . . . . 25 107 5.12.1 Scenario 9: TS to TS in same VN using IPV6 . . . . . . 25 108 5.12.2 Scenario 10: TS to TS in same VN using IPv4 . . . . . . 25 109 5.13 TS to TS in a different virtual networks . . . . . . . . . 25 110 5.13.1 Scenario 11: TS to TS in a different VNs using IPV6 . . 25 111 5.13.2 Scenario 12: TS to TS in a different VNs using IPv4 . . 25 112 5.13.3 Scenario 13: IPv4 TS to IPv6 TS in different VNs . . . 26 113 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 26 114 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 115 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 116 8.1 Normative References . . . . . . . . . . . . . . . . . . . 27 117 8.2 Informative References . . . . . . . . . . . . . . . . . . 27 118 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28 119 Appendix A: Task identifier generation . . . . . . . . . . . . . . 28 120 A.1 Globally unique identifiers method . . . . . . . . . . . . . 28 121 A.2 Universally Unique Identifiers method . . . . . . . . . . . 29 122 Appendix B: Task migration considerations . . . . . . . . . . . . 29 123 B.1 Address migration . . . . . . . . . . . . . . . . . . . . . 29 124 B.2 Connection migration . . . . . . . . . . . . . . . . . . . . 30 126 1 Introduction 128 This specification describes the data path, address formats, and 129 expected use cases of identifier-locator addressing in IPv6 130 ([RFC2460]). The Identifier-Locator Network Protocol (ILNP) 131 ([RFC6740], [RFC6741]) defines a protocol and operations model for 132 identifier-locator addressing in IPv6. Many concepts here are taken 133 from ILNP, however there are some differences in the context of 134 network virtualization-- for instance in ILA a method to encode a 135 virtual network identifier and virtual address within an identifier 136 is defined. 138 In identifier-locator addressing, an IPv6 address is split into a 139 locator and an identifier component. The locator indicates the 140 topological location in the network for a node, and the identifier 141 indicates the node's identity which refers to the logical or virtual 142 node in communications. Locators are routable within a network, but 143 identifiers typically are not. An application addresses a destination 144 by identifier. Identifiers are mapped to locators for transit in the 145 network. The on-the-wire address is composed of a locator and an 146 identifier: the locator is sufficient to route the packet to a 147 physical host, and the identifier allows the receiving host to 148 forward the packet to the addressed application. 150 Identifiers are not statically bound to a host on the network, and in 151 fact their binding (or location) may change. This is the basis for 152 network virtualization and address migration. An identifier is mapped 153 to a locator at any given time, and a set of identifier to locator 154 mappings is propagated throughout a network to allow communications. 155 The mappings are kept synchronized so that if an identifier migrates 156 to a new physical host, its identifier to locator mapping is updated. 158 In network virtualization, an identifier may further be split into a 159 virtual network identifier and virtual host address. With identifier- 160 locator addressing network virtualization can be implemented in an 161 IPv6 network without any additional encapsulation headers. Packets 162 sent with identifier-locator addresses look like plain unencapsulated 163 packets (e.g. TCP/IP packets). This "encapsulation" is transparent to 164 the network, so protocol specific mechanisms in network hardware work 165 seamlessly. These mechanisms include hash calculation for ECMP, NIC 166 large segment offload, checksum offload, etc. 168 ILA exhibits properties of different networking techniques: 170 o Network Address Translation 172 o Source routing 174 o Encapsulation 176 2 Motivation 178 This section highlights the motivation for identifier-locator 179 addressing. 181 2.1 Network virtualization 183 Identifier-locator addressing allows a data plane method to implement 184 network virtualization without encapsulation and its related 185 overheads. The service ILA provides is explicitly layer 3 over layer 186 3 network virtualization (IPv4 or IPv6 over IPv6). 188 2.1.1 Architecture 190 The architecture for Network Virtualization over Layer 3 ([NVO3ARCH]) 191 can be applied to network virtualization with ILA. 193 +--------+ +--------+ 194 | Tenant +--+ +----| Tenant | 195 | System | | (') | System | 196 +--------+ | ................ ( ) +--------+ 197 | +-+--+ . . +--+-+ (_) 198 | | NVE|--. .--| NVE| | 199 +--| | . . | |---+ 200 +-+--+ . . +--+-+ 201 / . . 202 / . Ipv6 Overlay . +--+-++--------+ 203 +--------+ / . Network . | NVE|| Tenant | 204 | Tenant +--+ . .- -| || System | 205 | System | . . +--+-++--------+ 206 +--------+ ................ 208 A Network Virtualization Edge (NVE) [RFC7365] is the entity that 209 implements the overlay functionality using ILA. An NVE resides at 210 the boundary between a Tenant System and the IPV6 overlay network as 211 shown above. An NVE creates and maintains local state about each 212 Virtual Network for which it is providing service on behalf of a 213 Tenant System. 215 As in traditional network virtualization, NVEs are responsible for 216 transit of tenant's packets through the overlay network. With ILA, 217 the NVEs perform address translation on packets as opposed to 218 encapsulation. The ingress NVE will translate the virtual address of 219 a destination to an ILA address. At the egress NVE, the reverse 220 translation is performed. 222 2.1.2 Multi-tenant virtualization 224 Identifier-locator addressing may be used as an alternative to nvo3 225 encapsulation protocols (such as GUE [GUE]). In multi-tenant 226 virtualization, overlay networks are established for various tenants 227 to create virtual networks and a tenant's nodes are assigned virtual 228 addresses. Virtual networking identifiers are used to encode a 229 virtual network identifier and a virtual address in an ILA address. 231 An advantage of identifier-locator addressing is that the overhead of 232 encapsulation is reduced and use of virtualization can be transparent 233 to the underlying network. A downside is that some features that use 234 additional data in an encapsulation aren't available (security option 235 in GUE for instance [GUESEC]). 237 Identifier-locator addressing may be appropriate in network 238 virtualization where the users are trusted, for instance if virtual 239 networks were assigned to different departments within an enterprise. 240 Network virtualization in this context provides a means of isolation 241 of traffic belonging to different departments of a single tenant. In 242 this scenario, if the isolation breaks and packets uintentionally 243 crosses between virtual networks, it would not be considered a 244 security risk. 246 2.2 Data center virtualization 248 A primary motivation for identifier-locator addressing is data center 249 virtualization. Virtualization within a data center permits 250 malleability and flexibility in using data center resources. In 251 particular, identifier-locator addressing virtualizes networking to 252 allow flexible job scheduling and possibility of live task migration. 254 2.2.1 Address per task 256 Managing the port number space for services within a data center is a 257 nontrivial problem. When a service task is created, it may run on 258 arbitrary hosts. The typical scenario is that the task will be 259 started on some machine and will be assigned a port number for its 260 service. The port number must be chosen dynamically to not conflict 261 with any other port numbers already assigned to tasks on the same 262 machine (possibly even other instances of the same service). A 263 canonical name for the service is entered into a database with the 264 host address and assigned port. When a client wishes to connect to 265 the service, it queries the database with the service name to get 266 both the address of an instance as well as its port number. Note that 267 DNS is not adequate for the service lookup since it does not provide 268 port numbers. 270 With ILA, each service task can be assigned its own IPv6 address and 271 therefore will logically be assigned the full port space for that 272 address. This a dramatic simplification since each service can now 273 use a publicly known port number that does not need to unique between 274 services or instances. A client can perform a lookup on the service 275 name to get an IP address of an instance and then connect to that 276 address using a well known port number. In this case, DNS is 277 sufficient for directing clients to instances of a service. 279 Algorithms for the creation of unique address per task are described 280 in Appendix A. 282 2.2.2 Job scheduling 284 In the usual data center model, jobs are scheduled to run as tasks on 285 some number of machines. A distributed job scheduler provides the 286 scheduling which may entail considerable complexity since jobs will 287 often have a variety of resource constraints. The scheduler takes 288 these constraints into account while trying to maximize utility of 289 the data center in terms utilization, cost, latency, etc. Data center 290 jobs do not typically run in virtual machines (VMs), but may run 291 within containers. Containers are mechanisms that provide resource 292 isolation between tasks running on the same host OS. These resources 293 can include CPU, disk, memory, and networking. 295 A fundamental problem arises in that once a task for a job is 296 scheduled on a machine, it often needs to run to completion. If the 297 scheduler needs to schedule a higher priority job or change resource 298 allocations, there may be little recourse but to kill tasks and 299 restart them on a different machine. In killing a task, progress is 300 lost which results in increased latency and wasted CPU cycles. Some 301 tasks may checkpoint progress to minimize the amount of progress 302 lost, but this is not a very transparent or general solution. 304 An alternative approach is to allow transparent job migration. The 305 scheduler may migrate running jobs from one machine to another. 307 Under the orchestration of the job scheduler, the steps to migrate a 308 job may be: 310 1) Stop running tasks for the job. 311 2) Package the run time state of the job. The run time state is 312 derived from the containers for the jobs. 313 3) Send the run time state of the job to the new machine where the 314 job is to run. 315 4) Instantiate the job's state on the new machine. 316 5) Start the tasks for the job continuing from the point at which 317 it was stopped. 319 This model similar to virtual machine (VM) migration except that the 320 run time state is typically much less data-- just task state as 321 opposed to a full OS image. Task state may be compressed to reduce 322 latency in migration. 324 The networking state of interest to migrate are the addresses used by 325 the task and open transport connections. The handling of these at 326 task migration is discussed in Appendix B. 328 3 Address formats 330 This section describes the address formats associated with 331 identifier-locator addressing in network virtualization. 333 3.1 ILA format 335 As described in ILNP ([RFC6741]) an IPv6 address may be encoded to 336 hold a locator and identifier where each occupies sixty-four bits. In 337 ILA, the upper three bits of the identifier indicate an identifier 338 type. 340 /* IPv6 canonical address format */ 341 | 64 bits | 64 bits | 342 +--------------------------------+-------------------------------+ 343 | IPv6 Unicast Routing Prefix | Interface Identifier | 344 +--------------------------------+-------------------------------+ 346 /* ILA for IPv6 */ 347 | 64 bits |3 bits| 61 bits | 348 +--------------------------------+-------------------------------+ 349 | Locator | Type | Identifier | 350 +----------------------------------------------------------------+ 352 An IPv6 header with an ILA address would then have the format: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |Version| Traffic Class | Flow Label | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Payload Length | Next Header | Hop Limit | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Source Address | 362 + + 363 | | 364 + + 365 | | 366 + + 367 | | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Destination Locator | 370 + + 371 | | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 |Type | Destination Identifier | 374 +-+-+-+ + 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 3.2 Identifier format 380 An ILA identifier includes a three bit type field and sixty-one bits 381 for an identifier value. 383 /* Identifier format for ILA */ 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type| Identifier | 388 +-+-+-+ | 389 | | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 o Type: Type of the identifier (see below). 394 o Identifier: Identifier value. 396 3.3 Identifier types 398 Defined identifier types are: 400 0: interface identifier 402 1: locally unique identifier 404 2: virtual networking identifier for IPv4 address 406 3: virtual networking identifier for IPv6 unicast address 408 4: virtual networking identifier for IPv6 multicast address 410 5-7: Reserved 412 3.4 Interface identifiers 414 The interface identifier type indicates a plain local scope interface 415 identifier. When this type is used the address is a normal IPv6 416 address without identifier-locator semantics. The pupose of this type 417 is to allow normal IPv6 addresses to be defined within the same 418 networking prefix as ILA addresses. The type bits must be zero, and 419 the format of the other bits (subnetting) would be site-defined. For 420 example, the format of an interface identifer might be: 422 /* Local scope interface identifier */ 423 | 64 bits |3 bits| 61 bits | 424 +----------------------------+------+---------------------------+ 425 | Prefix | 0x0 | IID | 426 +---------------------------------------------------------------+ 428 3.5 Locally unique identifiers 430 Locally unique identifiers (LUI) can be created for various 431 addressable nodes within a network. These identifiers are in a flat 432 sixty-one bit space and must be unique within a domain (unique within 433 a site for instance). To simplify administration, hierarchical 434 allocation of locally unique identifiers may be performed. 436 /* ILA with locally unique identifiers */ 437 | 64 bits |3 bits| 61 bits | 438 +----------------------------+------+---------------------------+ 439 | Locator | 0x1 | Locally unique ident. | 440 +---------------------------------------------------------------+ 442 3.6 Virtual networking identifiers for IPv4 444 This type defines a format for encoding an IPv4 virtual address and 445 virtual network identifier within an identifier. 447 /* ILA for IPv4 virtual networking */ 448 | 64 bits |3 bits| 29 bits | 32 bits | 449 +----------------------------+------+---------------+-----------+ 450 | Locator | 0x2 | VNID | VADDR | 451 +---------------------------------------------------------------+ 453 VNID is a virtual network identifier and VADDR is a virtual address 454 within the virtual network indicated by the VNID. The VADDR can be an 455 IPv4 unicast or multicast address, and may often be in a private 456 address space (i.e. [RFC1918]) used in the virtual network. 458 3.7 Virtual networking identifiers for IPv6 460 A virtual network identifier and an IPv6 virtual host address (tenant 461 visible address) can be encoded within an identifier. Encoding the 462 virtual host address involves mapping the 128 bit address into a 463 sixy-one bit identifier. Different encodings are used for unicast and 464 multicast addresses. 466 3.7.1 Virtual networking identifiers for IPv6 unicast 468 In this format, the virtual network identifier and virtual IPv6 469 unicast address are encoded within an identifier. To facilitate 470 encoding of virtual addresses, there is a unique mapping between a 471 VNID and a ninety-six bit prefix of the virtual address. 473 /* IPv6 unicast encoding with VNID in ILA */ 474 | 64 bits |3 bits| 29 bits | 32 bits | 475 +------------------------------+------+--------------+-----------+ 476 | Locator | 0x3 | VNID | VADDR6L | 477 +----------------------------------------------------------------+ 479 VADDR6L contains the low order 32 bits of the IPv6 virtual address. 480 The upper 96 bits of the virtual address inferred from the VNID to 481 prefix mapping. 483 The figure below illustrates encoding a tenant IPv6 virtual unicast 484 address into a ILA address. 486 /* IPv6 virtual address seen by tenant */ 487 +----------------------------------------------+-----------------+ 488 | Tenant prefix | VADDR6L | 489 +-----------------------+-------------------------------+--------+ 490 | | 491 +-prefix to VNID-+ | 492 | | 493 v v 494 +---------------------------+------+-----------+-----------------+ 495 | Locator | 0x3 | VNID | VADDR6L | 496 +----------------------------------------------------------------+ 497 /* Encoded IPv6 virtual address with VNID in ILA */ 499 This encoding is reversible, given an ILA address, the virtual 500 address visible to the tenant can be deduced: 502 /* ILA encoded virtual networking address */ 503 +---------------------------+------+-----------+-----------------+ 504 | Locator | 0x3 | VNID | VADDR6L | 505 +----------------------------------------+-----------------------+ 506 | | 507 +-VNID to prefix-+ | 508 | | 509 v v 510 +----------------------------------------------+-----------------+ 511 | Tenant prefix | VADDR6L | 512 +----------------------------------------------------------------+ 513 /* IPv6 virtual address seen by tenant */ 515 3.7.2 Virtual networking identifiers for IPv6 multicast 517 In this format, a virtual network identifier and virtual IPv6 518 multicast address are encoded within an identifier. 520 /* IPv6 multicast address with VNID encoding in ILA */ 521 | 64 bits |3 bits| 29 bits |4 bits| 28 bits | 522 +--------------------------+------+------------------------------+ 523 | Locator | 0x4 | VNID |Scope | MADDR6L | 524 +----------------------------------------------------------------+ 526 This format encodes an IPv6 multicast address in an identifier. The 527 scope indicates multicast address scope as defined in [RFC7346]. 528 MADDR6L is the low order 28 bits of the multicast address. The full 529 multicast address is thus: 531 ff0::0: 533 And so can encode multicast addresses of the form: 535 ff0X::0 to ff0X::0fff:ffff 537 The figure below illustrates encoding a tenant IPv6 virtual multicast 538 address into an ILA address. 540 /* IPv6 multicast address */ 541 | 12 bits | 4 bits| 84 bits | 28 bits | 542 +---------+-------+-----------------------------------+----------+ 543 | 0xfff | Scope | 0's | MADDR6L | 544 +-------------+---------------------------------------------+----+ 545 | | 546 +------------------------------------+ | 547 | | 548 v v 549 +--------------------------+------+------------------------------+ 550 | Locator | 0x4 | VNID |Scope | MADDR6L | 551 +----------------------------------------------------------------+ 552 /* IPv6 multicast address with VNID encoding in ILA */ 554 3.8 Standard identifier representation addresses 556 An identifier serves as the external representation of a network 557 node. For instance, an identifier may refer to a specific host, 558 virtual machine, or tenant system. When a host initiates a connection 559 or sends a packet, it uses the identifier to indicate the peer 560 endpoint of the communication. The endpoints of an established 561 connection context also nominally refer to identifiers. It is only 562 when the packet is actually being sent over a network that the 563 locator for the identifier needs to be resolved. 565 In order to maintain compatibility with existing networking stacks 566 and applications, identifiers are encoded in IPv6 addresses using a 567 standard identifier representation (SIR) address. A SIR address is a 568 combination of a prefix which occupies what would be the locator 569 portion of an ILA address, and the identifier in its usual location. 571 /* SIR address in IPv6 */ 572 | 64 bits | 64 bits | 573 +--------------------------------+-------------------------------+ 574 | SIR prefix | Identifier | 575 +----------------------------------------------------------------+ 577 A SIR prefix may be site-local, or globally routable. A globally 578 routable SIR prefix facilitates connectivity between hosts on the 579 Internet and ILA endpoints. A gateway between a site's network and 580 the Internet can translate between SIR prefix and locator for an 581 identifier. A network may have multiple SIR prefixes, and may also 582 allow tenant specific SIR prefixes in network virtualization. Note 583 that if there are multiple SIR prefixes they would share the same 584 identifier space. 586 The standard identifier representation address can be used as the 587 externally visible address for a node. This can used throughout the 588 network, returned in DNS AAAA records ([RFC3363]), used in logging, 589 etc. An application can use a SIR address without knowledge that it 590 encodes an identifier. 592 3.8.1 SIR for locally unique identifiers 594 The SIR address for a locally unique identifier has format: 596 /* SIR address with locally unique identifiers */ 597 | 64 bits |3 bits| 61 bits | 598 +--------------------------------+-------------------------------+ 599 | SIR prefix | 0x1 | Locally unique ident. | 600 +----------------------------------------------------------------+ 602 When using ILA with locally unique identifiers a flow tuple logically 603 has the form: 605 (source identifier, source port, 606 destination identifier, destination port) 608 Using standard identifier representation the flow is then represented 609 with IPv6 addresses: 611 (source SIR address, source port, 612 destination SIR address, destination port) 614 3.8.2 SIR for virtual addresses 616 An ILA virtual address may be encoded using the standard identifier 617 representation. For example, the SIR address for an IPv6 virtual 618 address may be: 620 /* SIR with IPv6 virtual network encoding */ 621 | 64 bits |3 bits| 29 bits | 32 bits | 622 +------------------------------+------+-------------+------------+ 623 | Tenant's SIR prefix | 0x3 | VNID | VADDRL6 | 624 +----------------------------------------------------------------+ 626 In a tenant system, a flow tuple would have the form: 628 (local VADDR, local port, remote VADDR, remote port) 630 After translating packets for the flow into ILA, the flow would be 631 identified on-the-wire as: 633 ((local VNID, local VADDR), local port, 634 (remote VNID, remote VADDR), remote port 636 A tenant may communicate with a peer in the network which is not in 637 its virtual network, for instance to reach a network service (see 638 below). In this case the flow tuple at the peer may be: 640 (local SIR address, local port, 641 remote SIR address, remote port) 643 In this example, the remote SIR address is a SIR address for a 644 virtual networking identifier, however from peer's connectivity 645 perspective this is not distinguishable from a SIR address with a 646 locally unique identifier or even a non-ILA address. 648 3.9 Locators 650 Locators are routable network address prefixes that address physical 651 hosts within the network. They may be assigned from a global address 652 block [RFC3587], or be based on unique local IPv6 unicast addresses 653 as described in [RFC4193]. 655 /* ILA with a global unicast locator */ 656 |<--------------- Locator --------------->| 657 |3 bits| N bits | M bits | 61-N-M | 64 bits | 658 +------+-------------+---------+---------------------------------+ 659 | 001 | Global prefix | Subnet | Host | Identifier | 660 +------+---------------+---------+--------+----------------------+ 662 /* ILA with a unique local IPv6 unicast locator */ 663 |<--------------- Locator --------->| 664 | 7 bits |1| 40 bits | 16 bits | 64 bits | 665 +--------+-+------------+-----------+----------------------------+ 666 | FC00 |L| Global ID | Host | Identifier | 667 +--------+-+------------+-----------+----------------------------+ 669 4 Operation 671 This section describes operation methods for using identifier-locator 672 addressing with network virtualization. 674 4.1 Identifier to locator mapping 676 An application initiates a communication or flow using a SIR address 677 or virtual address for a destination. In order to send a packet on 678 the network, the destination identifier is mapped to a locator. The 679 mappings are not expected to change frequently, so it is likely that 680 locator mappings can be cached in the flow contexts. 682 Identifier to locator mapping is nearly identical to the mechanism 683 needed in virtual networking to map a virtual network and virtual 684 host address to a physical host. These mechanisms should leverage a 685 common solution. 687 The mechanisms of propagating and maintaining identifier to locator 688 mappings are outside the scope of this document. 690 4.2 Address translations 692 With ILA, address translation is performed to convert SIR addresses 693 to ILA addresses, and ILA addresses to SIR addresses. Translation is 694 done on a destination address as a form of source routing. 696 4.2.1 SIR to ILA address translation 698 When transmitting a packet, the locator for the destination ILA 699 address might need to be set before the packet is sent on the wire. 700 In the case that packet was created using a standard identifier 701 representation, the SIR prefix is overridden with a locator. Since 702 this operation is potentially done for every packet the process 703 should be very efficient. Presumably, a host will maintain a cache of 704 identifier locator mappings with a fast lookup function. If there is 705 a connection state associated with the communication, the locator 706 information may be cached with the connection state to obviate the 707 need to perform a lookup per packet. 709 The typical steps to transmit a packet using ILA are: 711 1) Stack creates a packet with source address set to a SIR address 712 for the local identity, and the destination address is set to 713 the SIR address for the peer. The peer SIR address may have 714 been discovered through DNS or other means. 716 2) Stack overwrites the SIR prefix in the destination address with 717 a locator for the peer. This locator is discovered by a lookup 718 in the locator to identifier mappings. 720 3) If a transport checksum includes a pseudo header that covered 721 the original addresses, the checksum needs to be updated 722 accordingly. 724 4) Packet is sent on the wire. The network routes the packet to 725 the host indicated by the locator. 727 4.2.2 ILA to SIR address translation 729 Upon reception, an ILA address must be translated back to a SIR 730 address before upper layer processing. 732 Receive processing may be: 734 1) Packet is received, the destination locator matches an 735 interface address prefix on the host. 737 2) A lookup is performed on the destination identifier to find if 738 it addresses a local identifier. If match is found, a SIR 739 address can be created for the destination (overwrite locator 740 with a SIR prefix). 742 3) Perform any checks as necessary. Validate locators, 743 identifiers, and check that packet is not illegitimately 744 crossing virtual networks (see below). 746 4) Forward packet to application processing. If necessary, the 747 addresses in the packet can be converted to SIR addresses in 748 place. Changing the addresses may also entail updating the 749 checksum to reflect that (similar to a NAT translation). 751 4.3 Virtual networking operation 753 When using ILA with virtual networking identifiers, address 754 translation is performed to convert tenant virtual network and 755 virtual addresses to ILA addresses, and ILA addresses back to a 756 virtual network and tenant's virtual addresses. Address translation 757 is performed similar to the SIR translation cases described above. 759 4.3.1 Crossing virtual networks 761 With explicit configuration, virtual network hosts may communicate 762 directly with virtual hosts in another virtual network by using SIR 763 addresses for virtualization in both the source and destination 764 addresses. This might be done to allow services in one virtual 765 network to be accessed from another (by prior agreement between 766 tenants). 768 4.3.2 IPv4/IPv6 protocol translation 770 An IPv4 tenant may send a packet that is converted to an IPv6 packet 771 with ILA addresses having IPv4 virtual networking identifiers. 772 Similarly, an IPv6 packet with ILA addresses may be converted to an 773 IPv4 packet to be received by an IPv4-only tenant. These are 774 IPv4/IPv6 stateless protocol translations as described in [RFC6144] 775 and [RFC6145]. 777 4.4 Checksum handling 779 TCP and UDP checksums include a pseudo header checksum that covers 780 the IP addresses in a packet. In the case of identifier-locator 781 addressing the checksum must include the actual addresses set in the 782 packet on the wire. So when creating a checksum for transmit, or 783 verifying a checksum on receive, identifier-locator addressing must 784 be taken into account. 786 4.4.1 Transmit checksum 788 If the source and destination locators are available when the 789 transport checksum is being set, these can be used to calculate the 790 pseudo checksum for the packet. This might be applicable in cases 791 where locator information is cached within the context for a 792 transport connection. 794 If the locators are set after the transport layer processing, the 795 checksum can be updated following NAT procedures for address 796 translation. 798 4.4.2 Receive checksum 800 Similar to the transmit case, if address translation occurs before 801 transport layer processing the checksum must be adjusted per NAT. An 802 implementation may verify a transport checksum before converting 803 addresses to standard identifier representation to potentially 804 obviate modifying the transport checksum to account for translation. 806 4.5 Address selection 808 There may be multiple possibilities for creating either a source or 809 destination address. A node may be associated with more than one 810 identifier, and there may be multiple locators for a particular 811 identifier. The selection of an identifier occurs at flow creation 812 and must be invariant for the duration of the flow. Locator selection 813 should be done once per flow, however may change (in the case of a 814 migrating connection it will change). ILA address selection should 815 follow guidelines in Default Address Selection for Internet Protocol 816 Version 6 (IPv6) ([RFC6724]). 818 4.6 SIR address routing 820 ILA is intended to be sufficiently lightweight so that all the hosts 821 in a data center could potentially send and receive ILA addressed 822 packets. In order to scale this model and allow for hosts that do not 823 participate in ILA, a routing topology may be applied. A simple 824 topology is illustrated below. 826 +---+-+---+-+ 827 (1) Default SIR route |ILA router | 828 +->->->->->->->->->| |->->->->-+ 829 | +---+-+---+-+ | 830 ^ . (2) ILA V 831 | . redirect | 832 +--------++--+--+ . +--+--++--------+ 833 | || |<........... | || | 834 | Host || NVE | | NVE || Host | 835 | || |->->->->->->->->->->->->->| || | 836 +--------++--+--+ (3) Direct route +--+--++--------+ 838 An ILA router is a node that implements both NVE and NVA (Network 839 Virtulization Authority). When an ILA router receives a SIR addressed 840 packet it will perform the ILA translation and send the ILA addressed 841 packet to the destination NVE. 843 Host NVEs might not be initialized with ILA identifier to locator 844 mappings. When a host sends a SIR addressed packet, the packet is 845 routed to an ILA router based on the SIR prefix. The ILA router 846 provides ILA translation for the SIR prefix (this is shown in (1) 847 above). In addition to forwarding the ILA packet, the ILA router may 848 send an "ILA redirect" back to the source (at (2) above). The 849 redirect indicates the locator to use for the associated identifier. 850 Subsequently, the NVE at the source host can perform ILA translation 851 to send directly to the destination NVE thus eliminating triangular 852 routing (as shown in (3)). The specification of the ILA redirect 853 message is outside the scope of this document. 855 4.7 Duplicate identifier detection 857 As part of implementing the locator to identifier mapping, duplicate 858 identifier detection may be implemented in a centralized control 859 plane. A registry of identifiers could be maintained (possibly in 860 association the identifier to locator mapping database). When a node 861 creates an identifier it registers the identifier, and when the 862 identifier is no longer in use (e.g. task completes) the identifier 863 is unregistered. The control plane should able to detect a 864 registration attempt for an existing identifier and deny the request. 866 5. Communication scenarios 868 This section describes the use of identifier-locator addressing in 869 several scenarios. 871 5.1 Terminology 873 A formal notation for identifier-locator addressing with ILNP is 874 described in [RFC6740]. We extend this to include for network 875 virtualization cases. 877 Basic terms are: 879 A = IP Address 880 I = Identifier 881 L = Locator 882 LUI = Locally unique identifier 883 VNI = Virtual network identifier 884 VA = An IPv4 or IPv6 virtual address 885 VAX = An IPv6 networking identifier (IPv6 VA mapped to VAX) 886 SIR = Prefix for standard identifier representation 887 VNET = IPv6 prefix for a tenant (assumed to be globally routable) 888 Iaddr = IPv6 address of an Internet host 890 An ILA IPv6 address is denoted by 892 L:I 894 A transport endpoint IPv6 address with a locally unique identifier 895 with SIR prefix is denoted by 897 SIR:LUI 899 A virtual identifier with a virtual network identifier and a virtual 900 IPv4 address is denoted by 902 VNI:VA 904 An ILA IPv6 address with a virtual networking identifier for IPv4 905 would then be denoted 907 L:(VNI:VA) 909 The local and remote address pair in a packet or endpoint is denoted 911 A,A 913 An address translation sequence from transport visible addresses to 914 ILA addresses for transmission on the network and back to transport 915 endpoint addresses at the receiver has notation: 917 A,A -> L:I,A -> A,A 919 5.2 Identifier objects 921 Identifier-locator addressing is broad enough in scope to address 922 many different types of networking objects within a data center. For 923 descriptive purposes we classify these objects as tasks or tenant 924 systems. 926 A task is a unit of execution that runs in the data center networks. 927 These do not run in a virtual machine, but typically run in the 928 native host context perhaps within containers. Tasks are the 929 execution mechanism for native jobs in the data center. 931 A network service is a task that provides some network wide service 932 such as DNS, remote storage, remote logging, etc. A network service 933 may be accessed by tenant systems as well as other tasks. 935 A tenant system, or TS, is a unit of execution which runs on behalf 936 of a tenant in network virtualization. A TS may be implemented as a 937 virtual machine or possibly using containers mechanisms. In either 938 case, a virtual overlay network is implemented on behalf of a tenant, 939 and isolation between tenants' virtual networks is paramount. 941 5.3 Reference network for scenarios 943 Several communication scenarios can be considered: 945 1) Task to task (service) 946 2) Task to Internet 947 3) Internet to task 948 4) TS to service 949 5) Task to TS 950 6) TS to Internet 951 7) Internet to TS 952 8) IPv4 TS to service 953 9) TS to TS in same virtual network using IPv6 954 10) TS to TS in same virtual network using IPv4 955 11) TS to TS in different virtual network using IPv6 956 12) TS to TS in different virtual network using IPv4 957 13) IPv4 TS to IPv6 TS in different virtual networks 959 The figure below provides an example network topology with ILA 960 addressing in use. In this example, there are four hosts in the 961 network with locators L1, L2, L3, and L4. There three tasks with 962 identifiers T1, T2, and T3, as well as a networking service task with 963 identifier T4. The identifiers for these tasks may be locally unique 964 identifiers. There are two virtual networks VNI1 and VNI2, and four 965 tenant systems addressed as: VA1 and VA2 in VNI1, VA3 and VA4 in 966 VNI2. The network is connected to the Internet via a gateway. 968 ` ............. 969 . . 970 +-----------------+ . Internet . +-----------------+ 971 | Host L1 | . . | Host L2 | 972 | +-------------+ | ............. | +-------------+ | 973 | | TS VNI1:VA1 | | | | | TS VNI1:VA2 | | 974 | +-------------+ +---+ +-----+-----+ +---+ +-------------+ | 975 | +-------------+ | | | Gateway | | | +-------------+ | 976 | | Task T1 | | | +-----+-----+ | | | TS VNI2:VA3 | | 977 | +-------------+ | | | | | +-------------+ | 978 +-----------------+ | ............. | +-----------------+ 979 +-----. Data .-----+ 980 +-----------------+ . Center . +-----------------+ 981 | Host L3 | +-----. Network .---+ | Host L4 | 982 | +-------------+ | | ............. | | +-------------+ | 983 | | Task T2 | | | | | | VM VNI2:VA4 | | 984 | +-------------+ +---+ +-----| +-------------+ | 985 | +-------------+ | | +-------------+ | 986 | | Task T3 | | | | Serv. T4 | | 987 | +-------------+ | | +-------------+ | 988 +-----------------+ +-----------------+ 990 5.4 Scenario 1: Task to task 992 The transport endpoints for task to task communication are the SIR 993 addresses for the tasks. When a packet is sent on the wire, the 994 locator is set in the destination address of the packet. On reception 995 the destination addresses is converted back to SIR representation for 996 processing at the transport layer. 998 If task T1 is communicating with task T2, the ILA translation 999 sequence would be: 1001 SIR:T1,SIR:T2 -> // Transport endpoints on T1 1002 SIR:T1,L3:T2 -> // ILA used on the wire 1003 SIR:T1,SIR:T2 // Received at T2 1005 5.5 Scenario 2: Task to Internet 1007 Communication from a task to the Internet is accomplished through use 1008 of a SIR address (globally routable) in the source address of 1009 packets. No ILA translation is needed in this path. 1011 If task T1 is sending to an address Iaddr on the Internet, the packet 1012 addresses would be: 1014 SIR:T1,Iaddr 1016 5.6 Scenario 3: Internet to task 1018 An Internet host transmits packet to a task using an externally 1019 routable SIR address. The SIR prefix routes the packet to a gateway 1020 for the data center. The gateway translates the destination to an ILA 1021 address. 1023 If a host on the Internet with address Iaddr sends a packet to task 1024 T3, the ILA translation sequence would be: 1026 Iaddr,SIR:T3 -> // Transport endpoint at Iaddr 1027 Iaddr,L1:T3 -> // On the wire in data center 1028 Iaddr,SIR:T3 // Received at T3 1030 5.7 Scenario 4: TS to service task 1032 A tenant can communicate with a data center service using the SIR 1033 address of the service. 1035 If TS VA1 is communicating with service task T4, the ILA translation 1036 sequence would be: 1038 VNET:VA1,SIR:T4-> // Transport endpoints in TS 1039 VNET:VA1,L3:T4-> // On the wire 1040 VNET:VA1,SIR:T4 // Received at T4 1042 Where VNET is the address prefix for the tenant. 1044 Note that from the point of view of the service task there is no 1045 material difference between a peer that is a tenant system versus one 1046 which is another task. 1048 5.8 Scenario 5: Task to TS 1050 A task can communicate with a TS through it's externally visible 1051 address. 1053 If task T2 is communicating with TS VA4, the ILA translation sequence 1054 would be: 1056 SIR:T2,VNET:VA4 -> // Transport endpoints at T2 1057 SIR:T2,L4:(VNI2:VAX4) -> // On the wire 1058 SIR:T2,VNET:VA4 // Received at TS 1060 5.9 Scenario 6: TS to Internet 1062 Communication from a TS to the Internet assumes that the VNET for the 1063 TS is globally routable, hence no ILA translation would be needed. 1065 If TS VA4 sends a packet to the Internet, the addresses would be: 1067 VNET:VA4,Iaddr 1069 5.10 Scenario 7: Internet to TS 1071 An Internet host transmits a packet to a tenant system using an 1072 externally routable tenant prefix and address. The prefix routes the 1073 packet to a gateway for the data center. The gateway translates the 1074 destination to an ILA address. 1076 If a host on the Internet with address Iaddr is sending to TS VA4, 1077 the ILA translation sequence would be: 1079 Iaddr,VNET:VA4 -> // Endpoint at Iaddr 1080 Iaddr,L4:(VNI2:VAX4) -> // On the wire in data center 1081 Iaddr,VNET:VA4 // Received at TS 1083 5.11 Scenario 8: IPv4 TS to service 1085 A TS that is IPv4-only may communicate with a data center network 1086 service using protocol translation. The network service would be 1087 represented as an IPv4 address in the tenant's address space, and 1088 stateless NAT64 should be usable as described in [RFC6145]. 1090 If TS VA2 communicates with service task T4, the ILA translation 1091 sequence would be: 1093 VA2,ADDR4 -> // IPv4 endpoints at TS 1094 SIR:(VNI1:VA2),L4:T4 -> // On the wire in data center 1095 SIR:(VNI1:VA2),SIR:T4 // Received at task 1097 VA2 is the IPv4 address in the tenant's virtual network, ADDR4 is an 1098 address in the tenant's address space that maps to the network 1099 service. 1101 The reverse path, task sending to a TS with an IPv4 address, requires 1102 a similar protocol translation. 1104 For service task T4 to communicate with TS VA2, the ILA translation 1105 sequence would be: 1107 SIR:T4,SIR:(VNI1:VA2) -> // Endpoints at T4 1108 SIR:T4,L2:(VNI1:VA2) -> // On the wire in data center 1109 ADDR4,VA2 // IPv4 endpoint at TS 1111 5.12 TS to TS in the same virtual network 1113 ILA may be used to allow tenants within a virtual network to 1114 communicate without the need for explicit encapsulation headers. 1116 5.12.1 Scenario 9: TS to TS in same VN using IPV6 1118 If TS VA1 sends a packet to TS VA2, the ILA translation sequence 1119 would be: 1121 VNET:VA1,VNET:VA2 -> // Endpoints at VA1 1122 VNET:VA1,L2:(VNI1,VAX2) -> // On the wire 1123 VNET:VA1,VNET:VA2 -> // Received at VA2 1125 5.12.2 Scenario 10: TS to TS in same VN using IPv4 1127 For two tenant systems to communicate using IPv4 and ILA, IPv4/IPv6 1128 protocol translation is done both on the transmit and receive. 1130 If TS VA1 sends an IPv4 packet to TS VA2, the ILA translation 1131 sequence would be: 1133 VA1,VA2 -> // Endpoints at VA1 1134 SIR:(VNI1:VA1),L2:(VNI1,VA2) -> // On the wire 1135 VA1,VA2 // Received at VA2 1137 5.13 TS to TS in a different virtual networks 1139 A tenant system may be allowed to communicate with another tenant 1140 system in a different virtual network. This should only be allowed 1141 with explicit policy configuration. 1143 5.13.1 Scenario 11: TS to TS in a different VNs using IPV6 1145 For TS VA4 to communicate with TS VA1 using IPv6 the translation 1146 sequence would be: 1148 VNET2:VA4,VNET1:VA1-> // Endpoint at VA4 1149 VNET2:VA4,L1:(VNI1,VAX1)-> // On the wire 1150 VNET2:VA4,VNET1:VA1 // Received at VA1 1152 Note that this assumes that VNET1 and VNET2 are globally routable 1153 between the two virtual networks. 1155 5.13.2 Scenario 12: TS to TS in a different VNs using IPv4 1157 To allow IPv4 tenant systems in different virtual networks to 1158 communicate with each other, an address representing the peer would 1159 be mapped into the tenant's address space. IPv4/IPv6 protocol 1160 translation is done on transmit and receive. 1162 For TS VA4 to communicate with TS VA1 using IPv4 the translation 1163 sequence may be: 1165 VA4,SADDR1 -> // IPv4 endpoint at VA4 1166 SIR:(VNI2:VA4),L1:(VNI1,VA1)-> // On the wire 1167 SADDR4,VA1 // Received at VA1 1169 SADDR1 is the mapped address for VA1 in VA4's address space, and 1170 SADDR4 is the mapped address for VA4 in VA1's address space. 1172 5.13.3 Scenario 13: IPv4 TS to IPv6 TS in different VNs 1174 Communication may also be mixed so that an IPv4 tenant system can 1175 communicate with an IPv6 tenant system in another virtual network. 1176 IPv4/IPv6 protocol translation is done on transmit. 1178 For VM VA4 using IPv4 to communicate with VM VA1 using IPv6 the 1179 translation sequence may be: 1181 VA4,SADDR1 -> // IPv4 endpoint at VA4 1182 SIR:(VNI2:VA4),L1:(VNI1,VAX1)-> // On the wire 1183 SIR:(VNI2:VA4),SIR:(VNI1,VAX1) // Received at VA1 1185 SADDR1 is the mapped IPv4 address for VA1 in VA4's address space. 1187 6 Security Considerations 1189 Security must be considered when using identifier-locator addressing. 1190 In particular, the risk of address spoofing or address corruption 1191 must be addressed. To classify this risk the set possible 1192 destinations for a packet are classified as trusted or untrusted. The 1193 set of possible destinations includes those that a packet may 1194 inadvertently be sent due to address or header corruption. 1196 If the set of possible destinations are trusted then packet 1197 misdelivery is considered relatively innocuous. This might be the 1198 case in a data center if all nodes were tightly controlled under 1199 single management. Identifier-locator addressing can be used in this 1200 case without further additional security. 1202 If the set of possible destinations contains untrusted hosts, then 1203 packet misdelivery could be a risk. This may be the case that virtual 1204 machines with untrusted third party applications or OSes are running 1205 in the network. A malicious user may be snooping for misdelivered 1206 packets, or may attempt to spoof addresses. Identifier-locator 1207 addressing should be used with stronger security and isolation 1208 mechanisms such as IPsec or GUESEC. 1210 7 IANA Considerations 1212 There are no IANA considerations in this specification. 1214 8 References 1216 8.1 Normative References 1218 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1219 (IPv6) Specification", RFC 2460, December 1998. 1221 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1222 Architecture", RFC 4291, February 2006. 1224 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1225 Translation", RFC 6296, June 2011. 1227 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1228 "Default Address Selection for Internet Protocol Version 1229 6 (IPv6)", RFC 6724, September 2012. 1231 8.2 Informative References 1233 [RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1234 Protocol (ILNP) Architectural Description", RFC 6740, 1235 November 2012. 1237 [RFC6741] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1238 Protocol (ILNP) Engineering Considerations", RFC 6741, 1239 November 2012. 1241 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1242 and E. Lear, "Address Allocation for Private Internets", 1243 BCP 5, RFC 1918, February 1996. 1245 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 1246 Hain, "Representing Internet Protocol version 6 (IPv6) 1247 Addresses in the Domain Name System (DNS)", RFC 3363, 1248 August 2002. 1250 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 1251 Unicast Address Format", RFC 3587, August 2003. 1253 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1254 Addresses", RFC 4193, October 2005. 1256 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1257 IPv4/IPv6 Translation", RFC 6144, April 2011. 1259 [NVO3ARCH] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and 1260 Narten, T., "An Architecture for Overlay Networks 1261 (NVO3)", draft-ietf-nvo3-arch-03 1263 [GUE] Herbert, T., and Yong, L., "Generic UDP Encapsulation", 1264 draft-herbert-gue-02, work in progress. 1266 [GUESEC] Yong, L., and Herbert, T. "Generic UDP Encapsulation (GUE) 1267 for Secure Transport", draft-hy-gue-4-secure-transport- 1268 00, work in progress 1270 9 Acknowledgments 1272 The author would like to thank Mark Smith, Lucy Yong, Erik Kline, 1273 Saleem Bhatti, and Fred Baker for their insightful comments for this 1274 draft; Roy Bryant, Lorenzo Colitti, Mahesh Bandewar, and Erik Kline 1275 for their work on defining and applying ILA. 1277 Appendix A: Task identifier generation 1279 Potentially every task in a data center could be migratable as long 1280 as each task is assigned a unique identifier. Since an ILA identifier 1281 is sixty-one bits it is conceivable that identifiers could be 1282 allocated using a shared counter or based on a timestamp. 1284 A.1 Globally unique identifiers method 1286 For small to moderate sized deployments the technique for creating 1287 locally assigned global identifiers described in [RFC4193] could be 1288 used. In this technique a SHA-1 digest of the time of day in NTP 1289 format and an EUI-64 identifier of the local host is performed. N 1290 bits of the result are used as the globally unique identifier. 1292 The probability that two or more of these IDs will collide can be 1293 approximated using the formula: 1295 P = 1 - exp(-N**2 / 2**(L+1)) 1297 where P is the probability of collision, N is the number of 1298 identifiers, and L is the length of an identifier. 1300 The following table shows the probability of a collision for a range 1301 of identifiers using a 61-bit length. 1303 Identifiers Probability of Collision 1304 1000 2.1684*10^-13 1305 10000 2.1684*10^-11 1306 100000 2.1684*10^-09 1307 1000000 2.1684*10^-07 1309 Note that locally unique identifiers may be ephemeral, for instance a 1310 task may only exist for a few seconds. This should be considered when 1311 determining the probability of identifier collision. 1313 A.2 Universally Unique Identifiers method 1315 For larger deployments, hierarchical allocation may be desired. The 1316 techniques in Universally Unique Identifier (UUID) URN ([RFC4122]) 1317 can be adapted for allocating unique task identifiers in sixty-one 1318 bits. An identifier is split into two components: a registrar prefix 1319 and sub-identifier. The registrar prefix defines an identifier block 1320 which is managed by an agent, the sub-identifier is a unique value 1321 within the registrar block. 1323 For instance, each host in a network could be an agent so that a task 1324 identifier could be created on the host that initially runs a task. 1325 The identifier might be composed of a twenty-four bit host identifier 1326 followed by a thirty-seven bit timestamp. Assuming that a host can 1327 start up to 100 tasks per second, this allows 43.5 years before wrap 1328 around. 1330 /* Task identifier with host registrar and timestamp */ 1331 |3 bits| 24 bits | 37 bits | 1332 +------+-------------------+-------------------------------------+ 1333 | 0x1 | Host identifier | Timestamp Identifier | 1334 +----------------------------------------------------------------+ 1336 Appendix B: Task migration considerations 1338 B.1 Address migration 1340 ILA facilitates address (specifically identifier) migration between 1341 hosts as part of task migration or for other purposes. The steps in 1342 migrating an address might be: 1344 1) Configure address on the target host. 1346 2) Suspend use of the address on the old host. This includes 1347 handling established connections (see next section). A state 1348 may be established to drop packets or send an ILA redirect when 1349 packets to the migrated address are received. 1351 3) Update the identifier to locator mapping database. Depending on 1352 the control plane implementation this may include pushing the 1353 new mapping to hosts. 1355 4) Communicating hosts will learn of the new mapping via a control 1356 plane either by participation in a protocol for mapping 1357 propagation or by the ILA redirect mechanism. 1359 B.2 Connection migration 1361 When a task and its addresses are migrated between machines, the 1362 disposition of existing TCP connections needs to be considered. 1364 The simplest course of action is to drop TCP connections across a 1365 migration. Since migrations should be relatively rare events, it is 1366 conceivable that TCP connections could be automatically closed in the 1367 network stack during a migration event. If the applications running 1368 are known to handle this gracefully (i.e. reopen dropped connections) 1369 then this may be viable. 1371 For seamless migration, open connections may be migrated between 1372 hosts. Migration of these entails pausing the connection, packaging 1373 connection state and sending to target, instantiating connection 1374 state in the peer stack, and restarting the connection. From the time 1375 the connection is paused to the time it is running again in the new 1376 stack, packets received for the connection should be silently 1377 dropped. For some period of time, the old stack will need to keep a 1378 record of the migrated connection. If it receives a packet, it should 1379 either silently drop the packet or forward it to the new location. 1381 Author's Address 1383 Tom Herbert 1384 Facebook 1385 1 Hacker Way 1386 Menlo Park, CA 1387 EMail: tom@herbertland.com