idnits 2.17.1 draft-herbert-intarea-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 461: '... Locators MUST map to only one ILA d...' RFC 2119 keyword, line 499: '... SHOULD be assigned from a global address block [RFC3587]....' RFC 2119 keyword, line 523: '... format for identifiers MAY be defined...' RFC 2119 keyword, line 555: '... A SIR prefix SHOULD be a globally routable prefix per [RFC3587]. A...' RFC 2119 keyword, line 562: '... Locators MUST only be associated wi...' (4 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1906 has weird spacing: '...LA node as an...' -- The document date (March 5, 2018) is 2243 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: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC7346' is mentioned on line 807, but not defined == Missing Reference: 'RFC6145' is mentioned on line 1857, but not defined ** Obsolete undefined reference: RFC 6145 (Obsoleted by RFC 7915) == Missing Reference: 'ADDPRIV' is mentioned on line 1271, but not defined == Missing Reference: 'RFC7348' is mentioned on line 1393, but not defined == Missing Reference: 'RFC4193' is mentioned on line 1997, but not defined == Missing Reference: 'RFC4122' is mentioned on line 2026, but not defined == Unused Reference: 'RFC4291' is defined on line 1567, but no explicit reference was found in the text == Unused Reference: 'RFC6296' is defined on line 1570, but no explicit reference was found in the text == Unused Reference: 'RFC8014' is defined on line 1609, but no explicit reference was found in the text == Unused Reference: 'GUE' is defined on line 1615, but no explicit reference was found in the text == Unused Reference: 'GUESEC' is defined on line 1618, but no explicit reference was found in the text ** Downref: Normative reference to an Draft Standard RFC: RFC 4291 ** Downref: Normative reference to an Experimental RFC: RFC 6296 ** Downref: Normative reference to an Informational RFC: RFC 1071 ** Downref: Normative reference to an Informational RFC: RFC 1624 ** Downref: Normative reference to an Proposed Standard RFC: RFC 6724 == Outdated reference: A later version (-09) exists of draft-ietf-intarea-gue-04 Summary: 7 errors (**), 0 flaws (~~), 14 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: Standard Quantonium 4 Expires: September 5, 2018 Petr Lapukhov 5 Facebook 7 March 5, 2018 9 Identifier-locator addressing for IPv6 10 draft-herbert-intarea-ila-01 12 Abstract 14 This specification describes identifier-locator addressing (ILA) for 15 IPv6. Identifier-locator addressing differentiates between location 16 and identity of a network node. Part of an address expresses the 17 immutable identity of the node, and another part indicates the 18 location of the node which can be dynamic. Identifier-locator 19 addressing can be used to efficiently implement overlay networks for 20 network virtualization as well as solutions for use cases in 21 mobility. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.2 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 1.3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2 Architecture overview . . . . . . . . . . . . . . . . . . . . . 7 66 2.1 Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.2 Network topology . . . . . . . . . . . . . . . . . . . . . . 8 68 2.3 Transformations and mappings . . . . . . . . . . . . . . . . 8 69 2.4 ILA routing . . . . . . . . . . . . . . . . . . . . . . . . 9 70 2.5 ILA domains . . . . . . . . . . . . . . . . . . . . . . . . 10 71 2.6 ILA control plane . . . . . . . . . . . . . . . . . . . . . 10 72 3 Address formats . . . . . . . . . . . . . . . . . . . . . . . . 10 73 3.1 ILA address format . . . . . . . . . . . . . . . . . . . . . 10 74 3.2 Locators . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 3.3 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . 11 76 3.4 Standard identifier representation addresses . . . . . . . . 12 77 4 Optional identifier formats . . . . . . . . . . . . . . . . . . 13 78 4.1 Checksum neutral mapping . . . . . . . . . . . . . . . . . . 13 79 4.2 Identifier types . . . . . . . . . . . . . . . . . . . . . 13 80 4.2.1 Interface identifiers . . . . . . . . . . . . . . . . . 15 81 4.2.2 Locally unique identifiers . . . . . . . . . . . . . . . 15 82 4.2.3 Virtual networking identifiers for IPv4 . . . . . . . . 15 83 4.2.4 Virtual networking identifiers for IPv6 unicast . . . . 16 84 4.2.5 Virtual networking identifiers for IPv6 multicast . . . 17 85 4.2.6 Non-local address identifiers . . . . . . . . . . . . . 18 86 4.3 SIR addresses with formatted identifiers . . . . . . . . . . 19 87 4.3.1 SIR for locally unique identifiers . . . . . . . . . . . 20 88 4.3.2 SIR for virtual addresses . . . . . . . . . . . . . . . 20 89 4.3.2 SIR for non-local address identifiers . . . . . . . . . 20 90 5 Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 5.1 Identifier to locator mapping . . . . . . . . . . . . . . . 20 92 5.2 Address transformations . . . . . . . . . . . . . . . . . . 21 93 5.2.1 SIR to ILA address transformation . . . . . . . . . . . 21 94 5.2.2 ILA to SIR address transformation . . . . . . . . . . . 21 95 5.3 Virtual networking operation . . . . . . . . . . . . . . . . 22 96 5.3.1 Crossing virtual networks . . . . . . . . . . . . . . . 22 97 5.3.2 IPv4/IPv6 protocol translation . . . . . . . . . . . . . 22 98 5.4 Transport layer checksums . . . . . . . . . . . . . . . . . 23 99 5.4.1 Checksum-neutral mapping . . . . . . . . . . . . . . . . 23 100 5.4.2 Sending an unmodified checksum . . . . . . . . . . . . . 25 101 5.5 Non-local address mapping . . . . . . . . . . . . . . . . . 25 102 5.6 Address assignment . . . . . . . . . . . . . . . . . . . . . 26 103 5.6.1 Singleton address assignment . . . . . . . . . . . . . . 26 104 5.6.2 Network prefix assignment . . . . . . . . . . . . . . . 26 105 5.6.3 Strong privacy addresses . . . . . . . . . . . . . . . . 27 106 5.7 Address selection . . . . . . . . . . . . . . . . . . . . . 27 107 5.8 Duplicate identifier detection . . . . . . . . . . . . . . . 27 108 5.9 ICMP error handling . . . . . . . . . . . . . . . . . . . . 28 109 5.9.1 Handling ICMP errors by ILA capable hosts . . . . . . . 28 110 5.9.2 Handling ICMP errors by non-ILA capable hosts . . . . . 28 111 5.10 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 29 112 6 Motivation for ILA . . . . . . . . . . . . . . . . . . . . . . 29 113 6.1 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . 29 114 6.1.1 Multi-tenant virtualization . . . . . . . . . . . . . . 29 115 6.1.2 Datacenter virtualization . . . . . . . . . . . . . . . 30 116 6.1.3 Mobile networks . . . . . . . . . . . . . . . . . . . . 30 117 6.2 Alternative methods . . . . . . . . . . . . . . . . . . . . 31 118 6.2.1 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 31 119 6.2.2 Flow label as virtual network identifier . . . . . . . . 31 120 6.2.3 Extension headers . . . . . . . . . . . . . . . . . . . 32 121 6.2.4 Encapsulation techniques . . . . . . . . . . . . . . . . 32 122 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 32 123 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 33 124 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 125 9.1 Normative References . . . . . . . . . . . . . . . . . . . 34 126 9.2 Informative References . . . . . . . . . . . . . . . . . . 34 127 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 35 128 Appendix A: Communication scenarios . . . . . . . . . . . . . . . 36 129 A.1 Terminology for scenario descriptions . . . . . . . . . . . 36 130 A.2 Identifier objects . . . . . . . . . . . . . . . . . . . . . 37 131 A.3 Reference network for scenarios . . . . . . . . . . . . . . 37 132 A.4 Scenario 1: Object to task . . . . . . . . . . . . . . . . . 38 133 A.5 Scenario 2: Object to Internet . . . . . . . . . . . . . . . 38 134 A.6 Scenario 3: Internet to object . . . . . . . . . . . . . . . 38 135 A.7 Scenario 4: Tenant system to service . . . . . . . . . . . . 39 136 A.8 Scenario 5: Object to tenant system . . . . . . . . . . . . 39 137 A.9 Scenario 6: Tenant system to Internet . . . . . . . . . . . 40 138 A.10 Scenario 7: Internet to tenant system . . . . . . . . . . . 40 139 A.11 Scenario 8: IPv4 tenant system to object . . . . . . . . . 40 140 A.12 Tenant to tenant system in the same virtual network . . . . 41 141 A.12.1 Scenario 9: TS to TS in the same VN using IPV6 . . . . 41 142 A.12.2 Scenario 10: TS to TS in same VN using IPv4 . . . . . . 41 143 A.13 Tenant system to tenant system in different virtual 144 networks . . . . . . . . . . . . . . . . . . . . . . . . . 41 145 A.13.1 Scenario 11: TS to TS in different VNs using IPV6 . . . 41 146 A.13.2 Scenario 12: TS to TS in different VNs using IPv4 . . . 42 147 A.13.3 Scenario 13: IPv4 TS to IPv6 TS in different VNs . . . 42 148 A.14 Scenario 14: Non-local address to tenant system . . . . . . 42 149 Appendix B: unique identifier generation . . . . . . . . . . . . . 43 150 B.1 Globally unique identifiers method . . . . . . . . . . . . . 43 151 B.2 Universally Unique Identifiers method . . . . . . . . . . . 44 152 Appendix C: Datacenter task virtualization . . . . . . . . . . . . 44 153 C.1 Address per task . . . . . . . . . . . . . . . . . . . . . . 44 154 C.2 Job scheduling . . . . . . . . . . . . . . . . . . . . . . . 45 155 C.3 Task migration . . . . . . . . . . . . . . . . . . . . . . . 45 156 C.3.1 Address migration . . . . . . . . . . . . . . . . . . . 46 157 C.3.2 Connection migration . . . . . . . . . . . . . . . . . . 46 158 Appendix D: Mobility in wireless networks . . . . . . . . . . . . 47 160 1 Introduction 162 This specification describes the address formats, protocol operation, 163 and communication scenarios of identifier-locator addressing (ILA). 164 In identifier-locator addressing, an IPv6 address is split into a 165 locator and an identifier component. The locator indicates the 166 topological location in the network for a node, and the identifier 167 indicates the node's identity which refers to the logical or virtual 168 node in communications. Locators are routable within a network, but 169 identifiers typically are not. An application addresses a peer 170 destination by identifier. Identifiers are mapped to locators for 171 transit in the network. The on-the-wire address is composed of a 172 locator and an identifier: the locator is sufficient to route the 173 packet to a physical host, and the identifier allows the receiving 174 host to translate and forward the packet to the application. 176 Some of the concepts for ILA are adapted from Identifier-Locator 177 Network Protocol (ILNP) ([RFC6740], [RFC6741]) which defines a 178 protocol and operations model for identifier-locator addressing in 179 IPv6. 181 Section 6 provides a motivation for ILA and comparison of ILA with 182 alternative methods that achieve similar functionality. 184 1.1 Terminology 186 ILA Identifier-locator addressing. 188 ILA host An end host that is capable of performing ILA 189 translations on transmit or receive. 191 ILA router A network node that performs ILA translation and 192 forwarding of translated packets. 194 ILA node A network node capable of performing ILA translations. 195 This can be an ILA router or ILA host. 197 Locator A network prefix that routes to a physical host. 198 Locators provide the topological location of an 199 addressed node. ILA locators are typically sixty-four 200 bit prefixes, however other prefix sizes can be used. 202 Locator address 203 An IPv6 address than contains a locator. 205 Identifier A number that identifies an addressable node in the 206 network independent of its location. ILA identifiers 207 are typically sixty-four bit values, however other 208 sized values may be used. 210 Identifier address 211 An IPv6 address that contains an identifier but not a 212 locator. Identifier addresses are visible to 213 applications and provide a means to address nodes 214 independent of their location. 216 ILA address 217 An IPv6 address composed of a locator and an 218 identifier. In the canonical format the locator 219 occupies the upper sixty-four bits of an address and 220 the identifier is in the lower sixty-four bits. 222 ILA domain A unique identifier namespace. This may be indicated by 223 a SIR prefix where each SIR prefix maps to an ILA 224 domain. 226 ILA transformation 227 The process of transforming an identifier address to a 228 locator address or vice versa. 230 SIR Standard identifier representation. 232 SIR prefix A network prefix used to identify a SIR address. In the 233 canonical format SIR prefixes are sixty-four bits. 235 SIR address 236 An identifier address composed of a SIR prefix 237 (typically upper sixty-four bits) and an identifier 238 (typically lower sixty-four bits). 240 Virtual address 241 An IPv6 or IPv4 address that resides in the address 242 space of a virtual network. Such addresses may be 243 translated to identifier addresses as an external 244 representation of the address outside of the virtual 245 network, or they may be translated to locator addresses 246 for transit over an underlay network. 248 Topological address 249 An address that refers to a non-virtual node in a 250 network topology. These address physical hosts in a 251 network. 253 Checksum-neutral mapping 254 A method to preserve a correct transport layer checksum 255 when performing ILA transformation. When the upper bits 256 of an address are overwritten in an ILA transformation, 257 a modification can be made to the low order bits of the 258 identifier to offset the checksum difference. 260 1.2 Use cases 262 ILA use cases include datacenter virtualization, network 263 virtualization, and mobility in cellular and other mobile networks. 264 Section 6 provides details on these use cases. ILA operates at the 265 network layer so it works with any transport layer protocol and can 266 be used at intermediate devices or end nodes. An ILA implementation 267 may include optimizations depending on where in the network it runs. 269 1.3 Scope 271 Architecturally, ILA is a protocol to implement transparent network 272 overlays without encapsulation. It is also an identifier/locator 273 split protocol where location of a node is decoupled from its 274 identity. ILA works by transforming addresses between identifier and 275 locator addresses. ILA does address "transformation" as opposed to 276 "translation" since address modifications are always undone before 277 delivery to a destination node. 279 With identifier-locator addressing, network virtualization and 280 addressing for mobility can be implemented in an IPv6 network without 281 any additional encapsulation headers. Packets sent with identifier- 282 locator addresses look like plain unencapsulated packets (e.g. TCP/IP 283 packets). This method is transparent to the network, so protocol 284 specific mechanisms in network hardware work seamlessly. These 285 mechanisms include hash calculation for ECMP, NIC large segment 286 offload, checksum offload, etc. 288 ILA includes both a data plane and control plane. The data plane 289 defines the address structure and mechanisms for transforming 290 application visible identifier addresses to locator addresses. The 291 control plane's primary focus is a mapping system that includes a 292 database of identifier to locator mappings. This mapping database 293 drives ILA transformations. Control plane protocols disseminate 294 identifier to locator mappings amongst ILA nodes. 296 This specification is mostly concerned with the data plane for ILA. 297 The control plane is specified elsewhere. 299 2 Architecture overview 301 This section describes the architectural aspects of ILA. 303 2.1 Addressing 305 ILA performs transformations on IPv6 addresses. There are two types 306 of addresses introduced for ILA: locator addresses and identifier 307 addresses. 309 Locator addresses are IPv6 addresses that are composed of a locator 310 (typically upper sixty-four bits) and an identifier (typically low 311 order sixty-four bits). The identifier serves as the logical address 312 of a node, and the locator indicates the location of a node on the 313 network. 315 Identifier addresses are IPv6 addresses that contain an identifier 316 but not a locator. Identifier addresses are visible to applications 317 and provide a means to address nodes independent of their location. 319 A SIR address (Standard Identifier Representation) is an identifier 320 address that contains an identifier and an application visible SIR 321 prefix. SIR addresses are visible to the application and can be used 322 as connection endpoints. When a packet is sent to a SIR address, an 323 ILA router or host overwrites the SIR prefix with a locator 324 corresponding to the identifier. When a peer receives the packet, the 325 locator is overwritten with the original SIR prefix before delivery 326 to the application. In this manner applications only see SIR 327 addresses, they do not have visibility into ILA addresses. 329 ILA transformations can transform addresses from one type to another. 330 In network virtualization, virtual addresses can be transformed into 331 locator or identifier addresses, and conversely locator and 332 identifier addresses can be translated to virtual addresses. 334 2.2 Network topology 336 ILA nodes are nodes in the network that perform ILA transformations. 337 An ILA router is a node that performs ILA address transformation and 338 packet forwarding to implement overlay network functionality. ILA 339 routers perform transformations on packets sent by end nodes for 340 transport across an underlay network. Packets received by ILA routers 341 on the underlay network have their addresses reversed transformed for 342 reception at an end node. An ILA host is an end node that implements 343 ILA functionality for transmitting or receiving packets. 345 ILA nodes are responsible for transit of packets over an underlay 346 network. On ingress, an ILA node (host or router) will transform the 347 virtual or identifier address of a destination to a locator address. 348 At a peer ILA node, the reverse transformation is performed before 349 handing packets to an application. 351 The figure below provides an example topology using ILA with SIR 352 addresses. ILA transformations performed in one direction between 353 Host A and Host B are denoted. Host A sends a packet with a 354 destination SIR address (step (1)). An ILA router in the path 355 transforms the SIR address to an ILA address with a locator. The 356 locator is set to a value that will route packets to a peer ILA node 357 that Host B is downstream of. The packet is forwarded over the 358 network and delivered to the peer ILA node (step 2). The peer ILA 359 node, in this case another ILA router, transforms the destination 360 address back to a SIR address and forwards to the final destination 361 (step 3). 363 +--------+ +--------+ 364 | Host A +-+ +--->| Host B | 365 | | | (2) ILA (') | | 366 +--------+ | ...addressed.... ( ) +--------+ 367 V +---+--+ . packet . +---+--+ (_) 368 (1) SIR | | ILA |----->-------->---->| ILA | | (3) SIR 369 addressed +->|router| . . |router|->-+ addressed 370 packet +---+--+ . IPv6 . +---+--+ packet 371 / . Network . 372 / . . +--+-++--------+ 373 +--------+ / . . |ILA || Host | 374 | Host +--+ . .- -|host|| | 375 | | . . +--+-++--------+ 376 +--------+ ................ 378 2.3 Transformations and mappings 380 Address transformation is the mechanism employed by ILA. Logical or 381 virtual addresses are transformed to topological IPv6 addresses for 382 transport to the proper destination. In the canonical ILA addressing 383 format, transformation occurs in the upper sixty-four bits of an 384 address, the low order sixty-four bits contains an identifier that is 385 immutable and is not used to route a packet. The identifier/locator 386 split in addresses may have alternate arrangements for different use 387 cases. For instance, transformations on non-local identifier address 388 (Section 4.2.6) are performed across the full 128 bit address. 390 Each ILA node maintains a mapping table. This table maps identifiers 391 to locators. The mappings are dynamic as nodes with identifiers can 392 be created, destroyed, or move in the network. Mappings are 393 propagated amongst ILA routers or hosts in a network using mapping 394 propagation protocols (mapping propagation protocols will be 395 described in other specifications). 397 Identifiers are not statically bound to a host on the network, and in 398 fact their binding (or location) may change. This is the basis for 399 network virtualization and device mobility. An identifier is mapped 400 to a locator at any given time, and a set of identifier to locator 401 mappings is propagated throughout a network to allow communications. 402 The mappings are kept synchronized so that if an identifier migrates 403 to a new location, its identifier to locator mapping is updated. 405 2.4 ILA routing 407 ILA is intended to be sufficiently lightweight so that all the hosts 408 in a network could potentially send and receive ILA addressed 409 packets. In order to scale this model and allow for hosts that do not 410 participate in ILA, a routing topology may be applied. A simple 411 routing topology is illustrated below. 413 +---------+--+ 414 (1) Default SIR route |ILA router | (2) Transformed dest. 415 +->->->->->->->->->| |->->->->->+ 416 | +------------+ | 417 | V 418 +--------++-----+ +-----++--------+ 419 | || | | || | 420 | Host || ILA | | ILA || Host | 421 | ||host |->->->->->->->->->->->->->->| host|| | 422 +--------++-----+ (5) Direct route +-----++--------+ 423 . . 424 . . (3) Resolve 425 (4) Resolve . . Request +--------------+ 426 Reply . ..................>| | 427 . | ILA resolver | 428 ........................| | 429 +--------------+ 431 An ILA router can be addressed by an "anycast" SIR prefix so that it 432 receives packets sent on the network with SIR addresses. When an ILA 433 router receives a SIR addressed packet (step (1) in the diagram) it 434 will perform the ILA transformation and send the ILA addressed packet 435 to the destination ILA node (step (2)). 437 If a sending host is ILA capable the triangular routing can be 438 eliminated by performing an ILA resolution protocol. This entails a 439 host sending an ILA resolve request that specifies the SIR address to 440 resolve (step (3) in the figure). An ILA resolver can respond to a 441 resolve request with the identifier to locator mapping (step (4)). 442 Subsequently, the ILA host can perform ILA transformation and send 443 directly to the destination specified in the locator (step (5) in the 444 figure). The ILA resolution protocol will be specified in a companion 445 document. 447 In this model an ILA host maintains a cache of identifier mappings 448 for identifiers that it is currently communicating with. ILA routers 449 are expected to maintain a complete list of identifier to locator 450 mappings within the ILA domains that they service. 452 2.5 ILA domains 454 An ILA domain defines a namespace for identifiers. Identifiers must 455 be unique within an ILA domain. Each SIR prefix maps to one ILA 456 domain so that the combination of a SIR prefix and an identifier (a 457 SIR address) uniquely identifies a node. More than one SIR prefix may 458 be associated a domain where each SIR prefix combined with the same 459 identifier refers to the same node. 461 Locators MUST map to only one ILA domain in order to ensure that 462 transformation from a locator to SIR prefix is unambiguous. 464 2.6 ILA control plane 466 ILA routers and ILA hosts require a control plane that propagates the 467 tables that map identifier addresses to locator address (or just 468 identifier to locator mappings). There are several possible methods 469 for control planes that have been proposed including synchronized 470 configuration, BGP, DNS, and NoSQL databases. Defining a specific 471 control plane for ILA is out of scope of this document. 473 3 Address formats 475 3.1 ILA address format 477 In the canonical format, an ILA address is composed of a locator and 478 an identifier where each occupies sixty-four bits (similar to the 479 encoding in ILNP [RFC6741]). 481 | 64 bits | 64 bits | 482 +--------------------------------+-------------------------------+ 483 | Locator | Identifier | 484 +----------------------------------------------------------------+ 486 Note that there is no technical reason why identifiers and locators 487 must be sixty-four bits. Different sizes could be used. The split is 488 somewhat arbitrary, however it does simplify the description and 489 implementation. For instance, sixty-four bits is the size of a "long 490 long" native data type in several computer architectures. It is 491 conceivable that a different arrangement could be used for some ILA 492 domain. However, for the purposes of this document we assume that the 493 64/64 split is the canonical format. 495 3.2 Locators 497 Locators are routable network address prefixes that create 498 topological addresses for physical hosts within the network. They 499 SHOULD be assigned from a global address block [RFC3587]. 501 The format of an ILA address with a global unicast locator is: 503 |<---------- Locator ----------->| 504 |3 bits| N bits | M bits | 64 bits | 505 +------+-------------+---------+---------------------------------+ 506 | 001 | Global prefix | Subnet | Identifier | 507 +------+---------------+---------+-------------------------------+ 509 3.3 Identifiers 511 Identifiers uniquely identify logical nodes in an ILA domain. The 512 format of an ILA identifier is: 514 0 1 2 3 515 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 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Identifier | 518 + + 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 Identifiers are specified to be sixty-four bit values that are 523 unstructured. A structure and format for identifiers MAY be defined 524 for a domain; for instance the operator of an ILA domain may define 525 the use of prefixes for its identifiers in order to facilitate 526 hierarchies of its identifiers. Section 4 defines optional ILA 527 formats that an ILA domain might impose locally that allow different 528 types of identifiers as well as an indication of checksum neutral 529 mapping. 531 3.4 Standard identifier representation addresses 533 An identifier identifies objects or nodes in a network. For instance, 534 an identifier may refer to a specific host, virtual machine, or 535 tenant system. When a host initiates a connection or sends a packet, 536 it uses an identifier address to indicate the peer endpoint of the 537 communication. The endpoints of an established connection context are 538 also referenced by identifiers (encoded in identifier addresses). It 539 is only when the packet is actually being sent over a network that 540 the locator for the identifier needs to be resolved. 542 In order to maintain compatibility with existing networking stacks 543 and applications, identifiers are encoded in IPv6 addresses using a 544 standard identifier representation (SIR) address. A SIR address is a 545 combination of a prefix which occupies what would be the locator 546 portion of an ILA address, and the identifier in its usual location. 548 The format of a SIR address is: 550 | 64 bits | 64 bits | 551 +--------------------------------+-------------------------------+ 552 | SIR prefix | Identifier | 553 +----------------------------------------------------------------+ 555 A SIR prefix SHOULD be a globally routable prefix per [RFC3587]. A 556 globally routable SIR prefix facilitates connectivity between hosts 557 on the Internet and ILA nodes. An ILA router between a site's network 558 and the Internet can translate between SIR prefix and locator for an 559 identifier. A network may have multiple SIR prefixes where each 560 prefix defines a unique identifier space. 562 Locators MUST only be associated with one SIR prefix. This ensures 563 that if a transformation from a SIR address to an ILA address is 564 performed when sending a packet, the reverse transformation at the 565 receiver yields the same SIR address that was seen at the 566 transmitter. This also ensures that a reverse checksum-neutral 567 mapping can be performed at a receiver to restore the addresses that 568 were included in a pseudo header for setting a transport checksum. 570 An identifier address can be used as the externally visible address 571 for a node. This can used throughout the network, returned in DNS 572 AAAA records [RFC3363], used in logging, etc. An application can use 573 a identifier address without knowledge that it encodes an 574 identifier. 576 4 Optional identifier formats 578 This section describes optional identifier formats that allow for 579 different types of identifiers, groups of identifiers, and checksum 580 neutral mapping being applied. Note that identifiers are defined as 581 unstructured fields, there is no required structure imposed on them. 582 An administrator MAY impose an identifier format within an ILA 583 domain. Any imposed structure is local only to the domain and all ILA 584 nodes within the domain must agree on the format. A format might 585 include optional elements as described below, or may include other 586 elements customized for a domain. 588 4.1 Checksum neutral mapping 590 Checksum neutral mapping is an optional mechanism that may be applied 591 to an ILA address (see section 5.4.1 for description of checksum- 592 neutral mapping). When employed the checksum neutral mapping occupies 593 the low order sixteen bits of the identifier in a locator address. 595 0 1 2 3 596 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 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Identifier | 599 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | | Checksum-neutral adjustment | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 The presence of the checksum-neutral adjustment field must be 604 unambiguous. An optional C-bit flag could be used in the identifier 605 to indicate the checksum-neutral field is valid. The use of the C-bit 606 is demonstrated below. Alternatively, within an ILA domain an 607 operator could require it to be assumed that all ILA addresses have 608 the checksum-neutral field set so that an explicit flag is not 609 needed. Note that checksum-neutral adjustment is not used with 610 identifier addresses. 612 4.2 Identifier types 614 This section describes an optional identifier format that allows for 615 different types of identifiers and an indication of checksum neutral 616 mapping being applied. 618 Note that the identifier type format is optional. If this is not used 619 within an ILA domain then all ILA nodes assume that all identifiers 620 are of the same type (locally unique identifier for instance). 622 The optional type format of an ILA identifier with the checksum 623 adjust flag is: 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Type|C| Identifier | 629 +-+-+-+-+ | 630 | | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Fields are: 635 o Type: Type of the identifier (see below). 637 o C: The C-bit. This indicates that checksum-neutral mapping 638 applied (see below). Presence of this field is optional. 640 o Identifier: Identifier value. 642 Identifier types allow standard encodings for common uses of 643 identifiers. Defined identifier types are: 645 0: interface identifier 647 1: locally unique identifier 649 2: virtual networking identifier for IPv4 address 651 3: virtual networking identifier for IPv6 unicast address 653 4: virtual networking identifier for IPv6 multicast address 655 5: non-local address identfier 657 6-7: Reserved 659 If the C-bit is set then the low order sixteen bits of an identifier 660 contain the adjustment for checksum-neutral mapping (see section 661 4.4.1 for description of checksum-neutral mapping). The format of an 662 identifier with checksum neutral mapping is: 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Type|1| Identifier | 668 +-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | Checksum-neutral adjustment | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 4.2.1 Interface identifiers 674 The interface identifier type indicates a plain local scope interface 675 identifier. When this type is used the address is a normal IPv6 676 address without identifier-locator semantics. The purpose of this 677 type is to allow normal IPv6 addresses to be defined within the same 678 networking prefix as ILA addresses. Type bits and C-bit MUST be zero. 679 The format of an ILA interface identifier address is: 681 | 64 bits |3 bits|1| 60 bits | 682 +----------------------------+------+---------------------------+ 683 | Prefix | 0x0 |0| IID | 684 +---------------------------------------------------------------+ 686 4.2.2 Locally unique identifiers 688 Locally unique identifiers (LUI) can be created for various 689 addressable objects within a network. These identifiers are in a flat 690 space and must be unique within a SIR domain (unique within a site 691 for instance). To simplify administration, hierarchical allocation of 692 locally unique identifiers may be performed. The format of an ILA 693 address with locally unique identifiers is: 695 | 64 bits |3 bits|1| 60 bits | 696 +----------------------------+------+---------------------------+ 697 | Locator | 0x1 |C| Locally unique ident. | 698 +---------------------------------------------------------------+ 700 The figure below illustrates the transformation from SIR address to 701 an ILA address as would be performed when a node sends to a SIR 702 address. Note the low order 16 bits of the identifier may be modified 703 as the checksum-neutral adjustment. The reverse transformation of ILA 704 address to SIR address is symmetric. 706 +----------------------------+------+---------------------------+ 707 | SIR prefix | 0x1 |0| Identifier | 708 +---------------------------------------------------------------+ 709 | | | 710 SIR prefix to locator C-bit if needed | 711 V V V 712 +----------------------------+------+---------------------------+ 713 | Locator | 0x1 |C| Identifier | 714 +---------------------------------------------------------------+ 716 4.2.3 Virtual networking identifiers for IPv4 718 This type defines a format for encoding an IPv4 virtual address and 719 virtual network identifier within an identifier. The format of an ILA 720 address for IPv4 virtual networking is: 722 | 64 bits |3 bits|1| 28 bits | 32 bits | 723 +----------------------------+------+-----------+----------------+ 724 | Locator | 0x2 |C| VNID | VADDR | 725 +----------------------------------------------------------------+ 727 VNID is a virtual network identifier and VADDR is a virtual address 728 within the virtual network indicated by the VNID. The VADDR can be an 729 IPv4 unicast or multicast address, and may often be in a private 730 address space (i.e. [RFC1918]) used in the virtual network. 732 Translating a virtual IPv4 address into an ILA or SIR address and the 733 reverse transformation are straight forward. Note that the low order 734 16 bits of the IPv6 address may be modified as the checksum-neutral 735 adjustment and that this transformation implies protocol translation 736 between IPv4 and IPv6. 738 +----------------+ 739 | IPv4 address | 740 +----------------+ 741 ^ 742 | 743 V 744 +----------------------------+------+-----------+----------------+ 745 | Locator or SIR prefix | 0x2 |C| VNID | IPv4 address | 746 +----------------------------------------------------------------+ 748 4.2.4 Virtual networking identifiers for IPv6 unicast 750 In this format, a virtual network identifier and virtual IPv6 unicast 751 address are encoded within an identifier. To facilitate encoding of 752 virtual addresses, there is a unique mapping between a VNID and a 753 ninety-six bit prefix of the virtual address. The format an IPv6 754 unicast encoding with VNID in an ILA address is: 756 | 64 bits |3 bits|1| 28 bits | 32 bits | 757 +------------------------------+------+--------------+-----------+ 758 | Locator | 0x3 |C| VNID | VADDR6L | 759 +----------------------------------------------------------------+ 761 VADDR6L contains the low order 32 bits of the IPv6 virtual address. 762 The upper 96 bits of the virtual address inferred from the VNID to 763 prefix mapping. Note that for ILA transformations the low order 764 sixteen of the VADDR6L may be modified for checksum-neutral 765 adjustment. 767 The figure below illustrates encoding a tenant IPv6 virtual unicast 768 address into a ILA or SIR address. 770 +----------------------------------------------+-----------------+ 771 | Tenant prefix | VADDR6L | 772 +-----------------------+-------------------------------+--------+ 773 | | 774 +-prefix to VNID-+ | 775 | | 776 v v 777 +---------------------------+------+-----------+-----------------+ 778 | Locator or SIR prefix | 0x3 |C| VNID | VADDR6L | 779 +----------------------------------------------------------------+ 781 This encoding is reversible, given an ILA address, the virtual 782 address visible to the tenant can be deduced: 784 +---------------------------+------+-----------+-----------------+ 785 | Locator or SIR prefix | 0x3 |C| VNID | VADDR6L | 786 +----------------------------------------+-----------------------+ 787 | | 788 +-VNID to prefix-+ | 789 | | 790 v v 791 +----------------------------------------------+-----------------+ 792 | Tenant prefix | VADDR6L | 793 +----------------------------------------------------------------+ 795 4.2.5 Virtual networking identifiers for IPv6 multicast 797 In this format, a virtual network identifier and virtual IPv6 798 multicast address are encoded within an identifier. 800 /* IPv6 multicast address with VNID encoding in an ILA address */ 801 | 64 bits |3 bits|1|28 bits |4 bits| 28 bits | 802 +--------------------------+------+------------------------------+ 803 | Locator | 0x4 |C| VNID |Scope | MADDR6L | 804 +----------------------------------------------------------------+ 806 This format encodes an IPv6 multicast address in an identifier. The 807 scope indicates multicast address scope as defined in [RFC7346]. 808 MADDR6L is the low order 28 bits of the multicast address. The full 809 multicast address is thus: 811 ff0::: 813 And so can encode multicast addresses of the form: 815 ff0X::0 to ff0X::0fff:ffff 817 The figure below illustrates encoding a tenant IPv6 virtual multicast 818 address in an ILA or SIR address. Note that low order sixteen bits 819 of MADDR6L may be modified to be the checksum-neutral adjustment. 821 | 12 bits | 4 bits| 84 bits | 28 bits | 822 +---------+-------+-----------------------------------+----------+ 823 | 0xfff | Scope | 0's | MADDR6L | 824 +-------------+---------------------------------------------+----+ 825 | | 826 +------------------------------------+ | 827 | | 828 v v 829 +--------------------------+------+------------------------------+ 830 | Locator or SIR prefix | 0x4 |C| VNID |Scope | MADDR6L | 831 +----------------------------------------------------------------+ 833 This transformation is reversible: 835 +--------------------------+------+------------------------------+ 836 | Locator or SIR prefix | 0x4 |C| VNID |Scope | MADDR6L | 837 +----------------------------------------------------------------+ 838 | | 839 +------------------------------------+ | 840 | | 841 V V 842 +---------+-------+-----------------------------------+----------+ 843 | 0xfff | Scope | 0's | MADDR6L | 844 +-------------+---------------------------------------------+----+ 846 4.2.6 Non-local address identifiers 848 Non-local address identifiers allow mapping an arbitrary address to 849 an ILA address. The mapping system contains an entry that associates 850 an IPv6 address with an identifier. The associated IP address does 851 not need to be a SIR address or even in the same routing domain. 853 The format of a locator address for a non-local address identifier 854 is: 856 /* Non local identifier address mapping */ 857 | 64 bits |3 bits|1| 44 bits | 16 bits | 858 +--------------------------+------+------------------------------+ 859 | Locator | 0x5 |C| Identifier | csum adj | 860 +----------------------------------------------------------------+ 862 If the checksum adjust field is present it is not part of the 863 identifier that is used in the mapping lookup. The high order bits of 864 the address were originally not a SIR prefix, so it cannot be assumed 865 the checksum adjustment is based on a SIR prefix. The identifier is 866 taken to be the forty-four bits that precede the checksum adjustment 867 field. When creating the ILA address, the checksum adjustment field 868 is initialized to zero and then set based on checksum difference 869 between the original non-local address and the ILA address. 871 The figure below illustrates encoding an address into a locator 872 address. 874 /* Non local address identifier */ 876 +----------------------------------------------------------------+ 877 | Address | 878 +----------------------------------------------------------------+ 879 | 880 +--------------+ 881 | 882 V 883 +-------------------------------+--------------------------------+ 884 | Locator | 0x5 |C| Identifier | Csum-adj | 885 +-------------------------------+--------------------------------+ 887 A reverse transformation is performed based on a lookup in the 888 mapping table on the identifier (44 bits as shown above). The result 889 of the lookup provides the original address. 891 +-------------------------------+--------------------------------+ 892 | Locator | 0x5 |C| Identifier | Csum-adj | 893 +-------------------------------+--------------------------------+ 894 | 895 +-------------+ 896 | 897 V 898 +----------------------------------------------------------------+ 899 | Address | 900 +----------------------------------------------------------------+ 902 4.3 SIR addresses with formatted identifiers 904 The format of a SIR address with a formatted identifier is: 906 | 64 bits |3 bits|1| 60 bits | 907 +--------------------------------+-------------------------------+ 908 | SIR prefix | Type |0| Identifier | 909 +----------------------------------------------------------------+ 911 The C-bit (checksum-neutral mapping) MUST be zero for a SIR address. 912 Type may be any identifier type except zero (interface identifiers) 914 4.3.1 SIR for locally unique identifiers 916 The SIR address for a locally unique identifier has format: 918 | 64 bits |3 bits|1| 60 bits | 919 +--------------------------------+-------------------------------+ 920 | SIR prefix | 0x1 |0|Locally unique ident. | 921 +----------------------------------------------------------------+ 923 4.3.2 SIR for virtual addresses 925 A virtual address can be encoded using the standard identifier 926 representation. For example, the SIR address for an IPv6 virtual 927 address may be: 929 | 64 bits |3 bits|1| 28 bits | 32 bits | 930 +--------------------------------+------+------------+-----------+ 931 | SIR prefix | 0x3 |0| VNID | VADDRL6 | 932 +----------------------------------------------------------------+ 934 Note that this allows three representations of the same address in he 935 network: as a virtual address, a SIR address, and an ILA address. 937 4.3.2 SIR for non-local address identifiers 939 A non-local address identifier can be encoded using the standard 940 identifier representation. For example, an encoding may be: 942 | 64 bits |3 bits|1| 44 bits | 16 bits | 943 +--------------------------------+------+--------------+---------+ 944 | SIR prefix | 0x5 |0| Identifier | 0 | 945 +----------------------------------------------------------------+ 947 Note that lower order sixteen bits are set to zero since that would 948 be the checksum adjustment value bits if transformed to an ILA 949 address. 951 5 Operation 953 This section describes operation methods for using identifier-locator 954 addressing. 956 5.1 Identifier to locator mapping 958 An application initiates a communication or flow using an identifier 959 address or virtual address for a destination. In order to send a 960 packet on the network, the destination address is transformed by an 961 ILA node in the path. An ILA node maintains a list of mappings from 962 identifier to locator to perform this transformation. 964 The mechanisms of propagating and maintaining identifier to locator 965 mappings are outside the scope of this document. 967 5.2 Address transformations 969 With ILA, address transformation is performed to convert identifier 970 addresses to locator addresses, and locator addresses to identifier 971 addresses. Transformation is usually done on a destination address as 972 a form of source routing, however transformation on source virtual 973 addresses to identifier addresses can also be done to support some 974 network virtualization scenarios (see section Appendix A for 975 examples). 977 5.2.1 SIR to ILA address transformation 979 When translating a SIR address to an ILA address, the SIR prefix in 980 the address is overridden with a locator, and checksum neutral 981 mapping may be performed. Since this operation is potentially done 982 for every packet the process should be very efficient (particularly 983 the lookup and checksum processing operations). 985 The typical steps to transmit a packet using ILA are: 987 1) Host stack creates a packet with source address set to a local 988 address (possibly a SIR address) for the local identity, and 989 the destination address is set to the SIR address or virtual 990 address for the peer. The peer address may have been discovered 991 through DNS or other means. 993 2) An ILA node translates the packet to use the locator. If the 994 original destination address is a SIR address then the SIR 995 prefix is overwritten with the locator. If the original packet 996 is a virtually addressed tenant packet then the virtual address 997 is transformed per section 4.2. The locator is discovered by a 998 lookup in the locator to identifier mappings. 1000 3) The ILA node performs checksum-neutral mapping if configured 1001 for that (section 5.4). 1003 4) Packet is forwarded on the wire. The network routes the packet 1004 to the node indicated by the locator. 1006 5.2.2 ILA to SIR address transformation 1008 When a destination node (ILA router or end host) receives an ILA 1009 addressed packet, the ILA address MUST be transformed back to a SIR 1010 address (or virtual address) before upper layer processing. 1012 The steps of receive processing are: 1014 1) Packet is received. The destination locator is verified to 1015 match a locator assigned to the node. 1017 2) A lookup is performed on the destination identifier to find if 1018 it addresses a local identifier. If match is found, either the 1019 locator is overwritten with SIR prefix (for locally unique 1020 identifier type) or the address is transformed back to a tenant 1021 virtual address. 1023 3) Perform reverse checksum-neutral mapping if C-bit is set 1024 (section 5.4). 1026 4) Perform any optional policy checks; for instance that the 1027 source may send a packet to the destination address, that 1028 packet is not illegitimately crossing virtual networks, etc. 1030 5) Forward packet to the application. 1032 5.3 Virtual networking operation 1034 When using ILA with virtual networking identifiers, address 1035 transformation is performed to convert tenant virtual network and 1036 virtual addresses to ILA addresses, and ILA addresses back to a 1037 virtual network and tenant's virtual addresses. Transformation may 1038 occur on either source address, destination address, or both (see 1039 scenarios for virtual networking in Appendix A). Address 1040 transformation is performed similar to the SIR transformation cases 1041 described above. 1043 5.3.1 Crossing virtual networks 1045 With explicit configuration, virtual network hosts may communicate 1046 directly with virtual hosts in another virtual network by using 1047 identifier addresses for virtualization in both the source and 1048 destination addresses. This might be done to allow services in one 1049 virtual network to be accessed from another (by prior agreement 1050 between tenants). See appendix A.13 for example of ILA addressing for 1051 such a scenario. 1053 5.3.2 IPv4/IPv6 protocol translation 1055 An IPv4 tenant may send a packet that is converted to an IPv6 packet 1056 with ILA addresses. Similarly, an IPv6 packet with ILA addresses may 1057 be converted to an IPv4 packet to be received by an IPv4-only tenant. 1059 These are IPv4/IPv6 stateless protocol translations as described in 1060 [RFC6144] and [RFC6145]. See appendix A.12 for a description of these 1061 scenarios. 1063 5.4 Transport layer checksums 1065 Packets undergoing ILA transformation may encapsulate transport layer 1066 checksums (e.g. TCP or UDP) that include a pseudo header that is 1067 affected by the transformation. 1069 ILA provides two alternatives do deal with this: 1071 o Perform a checksum-neutral mapping to ensure that an 1072 encapsulated transport layer checksum is kept correct on the 1073 wire. 1075 o Send the checksum as-is, that is send the checksum value based 1076 on the pseudo header before transformation. 1078 Some intermediate devices that are not the actual end point of a 1079 transport protocol may attempt to validate transport layer checksums. 1080 In particular, many Network Interface Cards (NICs) have offload 1081 capabilities to validate transport layer checksums (including any 1082 pseudo header) and return a result of validation to the host. 1083 Typically, these devices will not drop packets with bad checksums, 1084 they just pass a result to the host. Checksum offload is a 1085 performance benefit, so if packets have incorrect checksums on the 1086 wire this benefit is lost. With this incentive, using checksum- 1087 neutral mapping is recommended. If it is known that the addresses of 1088 a packet are not included in a transport checksum, for instance a GRE 1089 packet is being encapsulated, then a source may choose not to perform 1090 checksum-neutral mapping. 1092 5.4.1 Checksum-neutral mapping 1094 When a change is made to one of the IP header fields in the IPv6 1095 pseudo-header checksum (such as one of the IP addresses), the 1096 checksum field in the transport layer header may become invalid. 1097 Fortunately, an incremental change in the area covered by the 1098 Internet standard checksum [RFC1071] will result in a well-defined 1099 change to the checksum value [RFC1624]. So, a checksum change caused 1100 by modifying part of the area covered by the checksum can be 1101 corrected by making a complementary change to a different 16-bit 1102 field covered by the same checksum. 1104 ILA can perform a checksum-neutral mapping when a SIR prefix or 1105 virtual address is transformed to a locator in an IPv6 address, and 1106 performs the reverse mapping when translating a locator back to a SIR 1107 prefix or virtual address. The low order sixteen bits of the 1108 identifier contain the checksum adjustment value for ILA. 1110 On transmission, the transformation process is: 1112 1) Compute the one's complement difference between the SIR prefix 1113 and the locator. Fold this value to 16 bits (add-with-carry 1114 four 16-bit words of the difference). 1116 2) If the C-bit is to be used then add-with-carry the bit-wise not 1117 of the 0x1000 (i.e. 0xefff) to the value from #1. This 1118 compensates the checksum for setting the C-bit. 1120 3) Add-with-carry the value from #2 to the low order sixteen bits 1121 of the identifier. 1123 4) Set the resultant value from #3 in the low order sixteen bits 1124 of the identifier and set the C-bit if it is to be present. 1126 Note that the "adjustment" (the 16-bit value set in the identifier) 1127 is fixed for a given SIR to locator mapping, so the adjustment value 1128 can be saved in an associated data structure for a mapping to avoid 1129 computing it for each transformation. 1131 On reception of an ILA addressed packet, if checksum-neutral mapping 1132 is applied to the packet (either the C-bit is set or its used is 1133 assumed for the ILA domain): 1135 1) Compute the one's complement difference between the locator in 1136 the address and the SIR prefix that the locator is being 1137 transformed to. Fold this value to 16 bits (add-with-carry four 1138 16-bit words of the difference). 1140 2) If the C-bit is used then add-with-carry 0x1000 to the value 1141 from #1. This compensates the checksum for clearing the C-bit. 1143 3) Add-with-carry the value from #2 to the low order sixteen bits 1144 of the identifier. 1146 4) Set the resultant value from #3 in the low order sixteen bits 1147 of the identifier and clear the C-bit if its present. This 1148 restores the original identifier sent in the packet. 1150 Note that receive checksum-neutral mapping process requires that the 1151 original upper sixty four bits in the address can be deduced. The 1152 method for this is different based on identifier type: 1154 o interface identifier: checksum-neutral mapping is not used. 1156 o locally unique identifier: the SIR prefix is inferred from the 1157 one to one mapping with a locator. 1159 o virtual network identifier for IPv4: the original upper sixty- 1160 four bits are assumed to be zero. 1162 o virtual network identifier for IPv6 unicast: the VNID in the 1163 identifier is mapped to a tenant prefix that includes the 1164 original upper sixty-four bits. 1166 o virtual network identifier for IPv6 multicast: the original 1167 upper sixty-four bits can be deduced by from the scope field in 1168 the identifier and fixed field of the multicast address. 1170 o non-local address identifier: the identifier, not including the 1171 low order sixteen bits of the address, is used to lookup the 1172 original address. Since the full address is provided by the 1173 lookup, the process to undo a checksum-neutral mapping can be 1174 obviated in this case 1176 5.4.2 Sending an unmodified checksum 1178 When sending an unmodified checksum, the checksum is incorrect as 1179 viewed in the packet on the wire. At the receiver, ILA transformation 1180 of the destination ILA address back to the SIR address occurs before 1181 transport layer processing. This ensures that the checksum can be 1182 verified when processing the transport layer header containing the 1183 checksum. Intermediate devices are not expected to drop packets due 1184 to a bad transport layer checksum. 1186 5.5 Non-local address mapping 1188 Non-local addresses may be mapped into ILA addresses using non-local 1189 address identifiers. This allows transit of such addresses across the 1190 underlay of an ILA domain. This would be useful for handling 1191 addresses in a network that originate from an external source. An 1192 example of this would be roaming in cellular network so that a device 1193 can continue using addresses that are part of its home network. 1195 A packet may be forwarded to an ILA router that has a non-local 1196 destination address which is not a identifier address for the domain. 1197 An ILA router can perform a lookup on the full address in an 1198 alternate mapping table. If there is a match, an identifier is 1199 returned that reverses maps to the address. This identifier is in the 1200 ILA domain space and identifies the node with the non-local address. 1201 A normal mapping table lookup can then be done to get the locator for 1202 the node in the ILA domain. 1204 At a peer ILA router, a lookup is performed on the destination 1205 identifier in a table that maps the non-local address identifier to 1206 the original non-local address. If an entry is found, the address is 1207 set in the destination address and the packet is forward to the 1208 destination. 1210 Note that the non-local address to identifier mapping and its reverse 1211 mapping must be set in the table before hand. 1213 5.6 Address assignment 1215 ILA supports single address assignments as well as prefix 1216 assignments. ILA will also support strong privacy in addressing 1217 [ADDRPRIV]. 1219 5.6.1 Singleton address assignment 1221 Singleton addresses can use a canonical 64/64 locator/identifier 1222 split. Singleton addresses can be assigned by DHCPv6. 1224 5.6.2 Network prefix assignment 1226 Prefix assignment can be done via SLAAC or DHCPv6-PD. 1228 To support /64 prefix assignment with ILA, the ILA identifier can be 1229 encoded in the upper sixty-four bits of an address. A level of 1230 indirection is used so that ILA transforms the upper sixty four bits 1231 to contain both a locator and an index into a locator (ILA node) 1232 specific table. The entry in the table provides the original sixty- 1233 four bit prefix so that locator to identifier address transformation 1234 can be done. As an example of this scheme, suppose network has a /24 1235 prefix. The identifier address format for /64 assignment might be: 1237 | 24 bits | 40 bits | 64 bits | 1238 +-------------+---------------------+------------------------------+ 1239 | Network | Identifier | IID | 1240 +-------------+---------------------+------------------------------+ 1242 The IID part is arbitrarily assigned by the device, so that is 1243 ignored by ILA. All routing, lookups, and transformations (excepting 1244 checksum neutral mapping) are based on the upper sixty-four bits. For 1245 identifier to locator address transformation, a lookup is done on the 1246 upper sixty-four bits. That returns a value that contains a locator 1247 and a locator table index. The resulting packet format may be 1248 something like: 1250 | 24 bits | 20 bits | 20 bits | 64 bits | 1251 +-------------+---------+-----------+------------------------------+ 1252 | Network | Locator | Loc index | IID | 1253 +-------------+---------+-----------+------------------------------+ 1255 The packet is forwarded and routed as addressed by locator (/44 route 1256 in this case). At the ILA forwarding node, the locator index is used 1257 as a key to an ILA node specific table that returns a 40 bit 1258 Identifier. This value is then written in the packet do ILA to 1259 identifier address transformation thereby restoring the original 1260 destination address. The locator index is not globally unique, it is 1261 specific to each ILA node. When an end node attaches to an ILA node, 1262 an index is chosen so that the table is populated at the ILA node and 1263 the ILA mapping includes the locator and index. When a node detaches 1264 from on ILA, it's entry in the table is removed and the index can be 1265 reused after a hold-down period to allow stale mappings to be purged. 1267 5.6.3 Strong privacy addresses 1269 Note that when a /64 is assigned to end hosts (such as UEs in a 1270 mobile network), the assigned prefix may become a persistent 1271 identifier for a device. This is a potential privacy issue. [ADDPRIV] 1272 describes this problem and suggests some solutions that may be used 1273 with ILA. 1275 5.7 Address selection 1277 There may be multiple possibilities for creating either a source or 1278 destination address. A node may be associated with more than one 1279 identifier, and there may be multiple locators for a particular 1280 identifier. The choice of locator or identifier is implementation or 1281 configuration specific. The selection of an identifier occurs at flow 1282 creation and must be invariant for the duration of the flow. Locator 1283 selection must be done at least once per flow, and the locator 1284 associated with the destination of a flow may change during the 1285 lifetime of the flow (for instance in the case of a migrating 1286 connection it will change). ILA address selection should follow 1287 specifications in Default Address Selection for Internet Protocol 1288 Version 6 (IPv6) [RFC6724]. 1290 5.8 Duplicate identifier detection 1292 As part of implementing the locator to identifier mapping, duplicate 1293 identifier detection should be implemented in a centralized control 1294 plane. A registry of identifiers could be maintained (possibly in 1295 association with the identifier to locator mapping database). When a 1296 node creates an identifier it registers the identifier, and when the 1297 identifier is no longer in use the identifier is unregistered. The 1298 control plane should able to detect a registration attempt for an 1299 existing identifier and deny the request. 1301 5.9 ICMP error handling 1303 A packet that contains an ILA address may cause ICMP errors within 1304 the network. In this case the ICMP data contains an IP header with an 1305 ILA address. ICMP messages are sent back to the source address in the 1306 packet. Upon receiving an ICMP error the host will process it 1307 differently depending on whether it is ILA capable. 1309 5.9.1 Handling ICMP errors by ILA capable hosts 1311 If a host is ILA capable it can attempt to reverse translate the ILA 1312 address in the destination of a header in the ICMP data back to a SIR 1313 address that was originally used to transmit the packet. The steps 1314 are: 1316 1) Assume that the upper sixty-four bits of the destination 1317 address in the ICMP data is a locator. Match these bits to a 1318 SIR address. If the host is only in one SIR domain, then the 1319 mapping to SIR address is implicit. If the host is in multiple 1320 domains then a locator to SIR addresses table can be maintained 1321 for this lookup. 1323 2) If the identifier includes checksum-neutral mapping, undo the 1324 checksum-neutral mapping using the SIR address found in #1 and 1325 the process in section 5.4.1. The resulting identifier address 1326 is potentially the original address used to send the packet. 1328 3) Lookup the identifier in the identifier to locator mapping 1329 table. If an entry is found compare the locator in the entry to 1330 the locator (upper sixty-four bits) of the destination address 1331 in the IP header of the ICMP data. If these match then proceed 1332 to next step. 1334 4) Overwrite the upper sixty-four bits of the destination address 1335 in the ICMP data with the found SIR prefix and overwrite the 1336 low order sixty-four bits with the found identifier (the result 1337 of undoing checksum-neutral mapping). The resulting address 1338 should be the original SIR address used in sending. The ICMP 1339 error packet can then be received by the stack for further 1340 processing. 1342 5.9.2 Handling ICMP errors by non-ILA capable hosts 1344 A non-ILA capable host may receive an ICMP error generated by the 1345 network that contains an ILA address in IP header contained in the 1346 ICMP data. This would happen in the case that an ILA router performed 1347 transformation on a packet the host sent and that packet subsequently 1348 generated an ICMP error. In this case the host receiving the error 1349 message will attempt to find the connection state corresponding to 1350 the packet header in the ICMP data. Since the host is unaware of ILA 1351 the lookup for connection state should fail. Because the host cannot 1352 recover the original addresses it used to send the packet, it won't 1353 be able any to derive any useful information about the original 1354 destination of the packet that it sent. 1356 If packets for a flow are always routed through an ILA router in both 1357 directions, for example ILA routers are coincident with edge routers 1358 in a network, then ICMP errors could be intercepted by an 1359 intermediate node which could translate the destination addresses in 1360 ICMP data back to the original SIR addresses. A receiving host would 1361 then see the destination address in the packet of the ICMP data to be 1362 that it used to transmit the original packet. 1364 5.10 Multicast 1366 ILA is generally not intended for use with multicast. In the case of 1367 multicast, routing of packets is based on the source address. Neither 1368 the SIR address nor an ILA address is suitable for use as a source 1369 address in a multicast packet. A SIR address is unroutable and hence 1370 would make a multicast packet unroutable if used as a source address. 1371 Using an ILA address as the source address makes the multicast packet 1372 routable, but this exposes ILA address to applications which is 1373 especially problematic on a multicast receiver that doesn't support 1374 ILA. 1376 If all multicast receivers are known to support ILA, a local locator 1377 address may be used in the source address of the multicast packet. In 1378 this case, each receiver will translate the source address from an 1379 ILA address to a SIR address before delivering packets to an 1380 application. 1382 6 Motivation for ILA 1384 6.1 Use cases 1386 6.1.1 Multi-tenant virtualization 1388 In multi-tenant virtualization overlay networks are established for 1389 tenants to provide virtual networks. Each tenant may have one or more 1390 virtual networks and a tenant's nodes are assigned virtual addresses 1391 within virtual networks. Identifier-locator addressing may be used as 1392 an alternative to traditional network virtualization encapsulation 1393 protocols used to create overlay networks (e.g. VXLAN [RFC7348]). 1395 Tenant systems (e.g. VMs) run on physical hosts and may migrate to 1396 different hosts. A tenant system is identified by a virtual address 1397 and virtual networking identifier of a corresponding virtual network. 1398 ILA can encode the virtual address and a virtual networking 1399 identifier in an ILA identifier. Each identifier is mapped to a 1400 locator that indicates the current host where the tenant system 1401 resides. Nodes that send to the tenant system set the locator per the 1402 mapping. When a tenant system migrates, its identifier to locator 1403 mapping is updated and communicating nodes will use the new mapping. 1405 6.1.2 Datacenter virtualization 1407 Datacenter virtualization virtualizes networking resources. Various 1408 objects within a datacenter can be assigned addresses and serve as 1409 logical endpoints of communication. A large address space, for 1410 example that of IPv6, allows addressing to be used beyond the 1411 traditional concepts of host based addressing. Addressed objects can 1412 include tasks, virtual IP addresses (VIPs), pieces of content, disk 1413 blocks, etc. Each object has a location which is given by the host on 1414 which an object resides. Some objects may be migratable between hosts 1415 such that their location changes over time. 1417 Objects are identified by a unique identifier within a namespace for 1418 the datacenter (appendix B discusses methods to create unique 1419 identifiers for ILA). Each identifier is mapped to a locator that 1420 indicates the current host where the object resides. Nodes that send 1421 to an object set the locator per the mapping. When an object migrates 1422 its identifier to locator mapping is updated and communicating nodes 1423 will use the new mapping. 1425 A datacenter object of particular interest is tasks, units of 1426 execution for for applications. The goal of virtualzing tasks is to 1427 maximize resource efficiency and job scheduling. Tasks share many 1428 properties of tenant systems, however they are finer grained objects, 1429 may have a shorter lifetimes, and are likely created in greater 1430 numbers. Appendix C provides more detail and motivation for 1431 virtualizing tasks using ILA. 1433 6.1.3 Mobile networks 1435 ILA may be applied as a solution for mobility in mobile networks 1436 (such as cellular networks). In mobile networks, devices such as 1437 smart phones move physically within the network. When a device moves 1438 it changes its point of attachment in the network. The goal of 1439 mobility is to provide a seamless transition when a device moves from 1440 one attachment point to another. Appendix D provides more detail and 1441 motivation for ILA in wireless networks. 1443 Each mobile device in a network may be assigned one or more 1444 identifiers to use in communications. The ILA mapping table has an 1445 entry for each identifier that maps to a locator indicating the 1446 current network point of attachment for the device. Nodes that send 1447 to the device set the locator per the mapping. When a mobile device 1448 moves to a new attachment point, then mapping table entries all of 1449 its associated identifiers are updated with a new locator. 1451 6.2 Alternative methods 1453 This section discusses the merits of alternative solution that have 1454 been proposed to provide network virtualization or mobility in IPv6. 1456 6.2.1 ILNP 1458 ILNP splits an address into a locator and identifier in the same 1459 manner as ILA. ILNP has characteristics, not present in ILA, that 1460 prevent it from being a practical solution: 1462 o ILNP requires that transport layer protocol implementations must 1463 be modified to work over ILNP. 1465 o ILNP can only be implemented in end hosts, not within the 1466 network. This essentially requires that all end hosts need to be 1467 modified to participate in mobility. 1469 6.2.2 Flow label as virtual network identifier 1471 The IPv6 flow label could conceptually be used as a 20-bit virtual 1472 network identifier in order to indicate a packet is sent on an 1473 overlay network. In this model the addresses may be virtual addresses 1474 within the specified virtual network. Presumably, the tuple of flow- 1475 label and addresses could be used by switches to forward virtually 1476 addressed packets. 1478 This approach has some issues: 1480 o Forwarding virtual packets to their physical location would 1481 require specialized switch support. 1483 o The flow label is only twenty bits, this is too small to be a 1484 discriminator in forwarding a virtual packet to a specific 1485 destination. Conceptually, the flow label might be used in a 1486 type of label switching to solve that. 1488 o The flow label is not considered immutable in transit, 1489 intermediate devices may change it. 1491 o The flow label is not part of the pseudo header for transport 1492 checksum calculation, so it is not covered by any transport (or 1493 other) checksums. 1495 6.2.3 Extension headers 1497 To accomplish network virtualization an extension header, such as a 1498 destination or routing option, could be used that contains the 1499 virtual destination address of a packet. The destination address in 1500 the IPv6 header would be the topological address for the location of 1501 the virtual node. Conceivably, segment routing could be used to 1502 implement network virtualization in this manner. 1504 This technique has some issues: 1506 o Intermediate devices must not insert extension headers 1507 [RFC8200]. 1509 o Extension headers introduce additional packet overhead which may 1510 impact performance. 1512 o Extension headers are not covered by transport checksums (as the 1513 addresses would be) nor any other checksum. 1515 o Extension headers are not widely supported in network hardware 1516 or devices. For instance, several NIC offloads don't work in the 1517 presence of extension headers. 1519 6.2.4 Encapsulation techniques 1521 Various encapsulation techniques have been proposed for implementing 1522 network virtualization and mobility. LISP is an example of an 1523 encapsulation that is based on locator identifier separation similar 1524 to ILA. The primary drawback of encapsulation is complexity and per 1525 packet overhead. For instance, when LISP is used with IPv6 the 1526 encapsulation overhead is fifty-six bytes and two IP headers are 1527 present in every packet. This adds considerable processing costs, 1528 requires considerations to handle path MTU correctly, and certain 1529 network accelerations may be lost. 1531 7 Security Considerations 1533 Security must be considered when using identifier-locator addressing. 1534 In particular, the risk of address spoofing or address corruption 1535 must be addressed. To classify this risk the set possible 1536 destinations for a packet are classified as trusted or untrusted. The 1537 set of possible destinations includes those that a packet may 1538 inadvertently be sent due to address or header corruption. 1540 If the set of possible destinations are trusted then packet 1541 misdelivery is considered relatively innocuous. This might be the 1542 case in a data center if all nodes were tightly controlled under 1543 single management. Identifier-locator addressing can be used in this 1544 case without further additional security. 1546 If the set of possible destinations contains untrusted hosts, then 1547 packet misdelivery could be a risk. This may be the case that virtual 1548 machines with untrusted third party applications or OSes are running 1549 in the network. A malicious user may be snooping for misdelivered 1550 packets, or may attempt to spoof addresses. Identifier-locator 1551 addressing should be used with stronger security and isolation 1552 mechanisms such as IPsec or GUESEC. 1554 8 IANA Considerations 1556 There are no IANA considerations in this specification. 1558 9 References 1560 9.1 Normative References 1562 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1563 (IPv6) Specification", STD 86, RFC 8200, DOI 1564 10.17487/RFC8200, July 2017, . 1567 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1568 Architecture", RFC 4291, February 2006. 1570 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 1571 Translation", RFC 6296, June 2011. 1573 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1574 "Computing the Internet checksum", RFC 1071, September 1575 1988. 1577 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum 1578 via Incremental Update", RFC 1624, May 1994. 1580 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 1581 "Default Address Selection for Internet Protocol Version 1582 6 (IPv6)", RFC 6724, September 2012. 1584 9.2 Informative References 1586 [RFC6740] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1587 Protocol (ILNP) Architectural Description", RFC 6740, 1588 November 2012. 1590 [RFC6741] RJ Atkinson and SN Bhatti, "Identifier-Locator Network 1591 Protocol (ILNP) Engineering Considerations", RFC 6741, 1592 November 2012. 1594 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 1595 and E. Lear, "Address Allocation for Private Internets", 1596 BCP 5, RFC 1918, February 1996. 1598 [RFC3363] Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T. 1599 Hain, "Representing Internet Protocol version 6 (IPv6) 1600 Addresses in the Domain Name System (DNS)", RFC 3363, 1601 August 2002. 1603 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 1604 Unicast Address Format", RFC 3587, August 2003. 1606 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1607 IPv4/IPv6 Translation", RFC 6144, April 2011. 1609 [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., and T. 1610 Narten, "An Architecture for Data-Center Network 1611 Virtualization over Layer 3 (NVO3)", RFC 8014, DOI 1612 10.17487/RFC8014, December 2016, . 1615 [GUE] Herbert, T., and Yong, L., "Generic UDP Encapsulation", 1616 draft-ietf-intarea-gue-04, work in progress. 1618 [GUESEC] Yong, L., and Herbert, T. "Generic UDP Encapsulation (GUE) 1619 for Secure Transport", draft-hy-gue-4-secure-transport- 1620 03, work in progress 1622 [ADDRPRIV] Herbert, T., "Privacy in IPv6 Network Prefix Assignment", 1623 draft-herbert-ipv6-prefix-address-privacy-00 1625 10 Acknowledgments 1627 The authors would like to thank Mark Smith, Lucy Yong, Erik Kline, 1628 Saleem Bhatti, Blake Matheny, Doug Porter, Pierre Pfister, Fred 1629 Baker, and Fred Baker for their insightful comments for this draft; 1630 Roy Bryant, Lorenzo Colitti, Mahesh Bandewar, and Erik Kline for 1631 their work on defining and applying ILA; Kalyani Bogineni, Niranjan 1632 Avula, Behcet Sarikaya, Dirk von-Hugo, and Ratul Guha for insights 1633 regarding the mobility use case. 1635 Appendix A: Communication scenarios 1637 This section describes the use of identifier-locator addressing in 1638 several scenarios. 1640 A.1 Terminology for scenario descriptions 1642 A formal notation for identifier-locator addressing with ILNP is 1643 described in [RFC6740]. We extend this to include for network 1644 virtualization cases. 1646 Basic terms are: 1648 A = IP Address 1649 I = Identifier 1650 L = Locator 1651 LUI = Locally unique identifier 1652 VNI = Virtual network identifier 1653 VA = An IPv4 or IPv6 virtual address 1654 VAX = An IPv6 networking identifier (IPv6 VA mapped to VAX) 1655 SIR = Prefix for standard identifier representation 1656 VNET = IPv6 prefix for a tenant (assumed to be globally routable) 1657 Iaddr = IPv6 address of an Internet host 1659 An ILA IPv6 address is denoted by 1661 L:I 1663 A SIR address with a locally unique identifier and SIR prefix is 1664 denoted by 1666 SIR:LUI 1668 A virtual identifier with a virtual network identifier and a virtual 1669 IPv4 address is denoted by 1671 VNI:VA 1673 An ILA IPv6 address with a virtual networking identifier for IPv4 1674 would then be denoted 1676 L:(VNI:VA) 1678 The local and remote address pair in a packet or endpoint is denoted 1680 A,A 1682 An address translation sequence from SIR addresses to ILA addresses 1683 for transmission on the network and back to SIR addresses at a 1684 receiver has notation: 1686 A,A -> L:I,A -> A,A 1688 A.2 Identifier objects 1690 Identifier-locator addressing is broad enough in scope to address 1691 many different types of networking entities. For the purposes of this 1692 section we classify these as "objects" and "tenant systems". 1694 Objects encompass uses where nodes are address by local unique 1695 identifiers (LUI). In the scenarios below objects are denoted by OBJ. 1697 Tenant systems are those associated with network virtualization that 1698 have virtual addresses (that is they are addressed by VNI:VA). In the 1699 scenarios below tenant systems are denoted by TS. 1701 A.3 Reference network for scenarios 1703 The figure below provides an example network topology with ILA 1704 addressing in use. In this example, there are four hosts in the 1705 network with locators L1, L2, L3, and L4. There three objects with 1706 identifiers O1, O2, and O3, as well as a common networking service 1707 with identifier S1. There are two virtual networks VNI1 and VNI2, and 1708 four tenant systems addressed as: VA1 and VA2 in VNI1, VA3 and VA4 in 1709 VNI2. The network is connected to the Internet via a gateway. 1710 ` ............. 1711 . . 1712 +-----------------+ . Internet . +-----------------+ 1713 | Host L1 | . . | Host L2 | 1714 | +-------------+ | ............. | +-------------+ | 1715 | | TS VNI1:VA1 | | | | | TS VNI1:VA2 | | 1716 | +-------------+ +---+ +-----+-----+ +---+ +-------------+ | 1717 | +-------------+ | | | Gateway | | | +-------------+ | 1718 | | OBJ O1 | | | +-----+-----+ | | | TS VNI2:VA3 | | 1719 | +-------------+ | | | | | +-------------+ | 1720 +-----------------+ | ............. | +-----------------+ 1721 +-----. .-----+ 1722 +-----------------+ . Underlay . +-----------------+ 1723 | Host L3 | +-----. Network .---+ | Host L4 | 1724 | +-------------+ | | ............. | | +-------------+ | 1725 | | OBJ O2 | | | | | | VM VNI2:VA4 | | 1726 | +-------------+ +---+ +-----| +-------------+ | 1727 | +-------------+ | | +-------------+ | 1728 | | OBJ O3 | | | | Serv. S1 | | 1729 | +-------------+ | | +-------------+ | 1730 +-----------------+ +-----------------+ 1731 Several communication scenarios can be considered: 1733 1) Object to object 1734 2) Object to Internet 1735 3) Internet to object 1736 4) Tenant system to local service 1737 5) Object to tenant system 1738 6) Tenant system to Internet 1739 7) Internet to tenant system 1740 8) IPv4 tenant system to service 1741 9) Tenant system to tenant system same virtual network using IPv6 1742 10) Tenant system to tenant system in same virtual network using 1743 IPv4 1744 11) Tenant system to tenant system in different virtual network 1745 using IPv6 1746 12) Tenant system to tenant system in different virtual network 1747 using IPv4 1748 13) IPv4 tenant system to IPv6 tenant system in different virtual 1749 networks 1750 14) Non-local address to tenant system 1752 A.4 Scenario 1: Object to task 1754 The transport endpoints for object to object communication are the 1755 SIR addresses for the objects. When a packet is sent on the wire, the 1756 locator is set in the destination address of the packet. On reception 1757 the destination addresses is converted back to SIR representation for 1758 processing at the transport layer. 1760 If task T1 is communicating with task T2, the ILA translation 1761 sequence would be: 1763 SIR:O1,SIR:O2 -> // Transport endpoints on O1 1764 SIR:O1,L3:O2 -> // ILA used on the wire 1765 SIR:O1,SIR:O2 // Received at O2 1767 A.5 Scenario 2: Object to Internet 1769 Communication from an object to the Internet is accomplished through 1770 use of a SIR address (globally routable) in the source address of 1771 packets. No ILA translation is needed in this path. 1773 If object O1 is sending to an address Iaddr on the Internet, the 1774 packet addresses would be: 1776 SIR:O1,Iaddr 1778 A.6 Scenario 3: Internet to object 1779 An Internet host transmits a packet to a task using an externally 1780 routable SIR address. The SIR prefix routes the packet to a gateway 1781 for the datacenter. The gateway translates the destination to an ILA 1782 address. 1784 If a host on the Internet with address Iaddr sends a packet to object 1785 O3, the ILA translation sequence would be: 1787 Iaddr,SIR:O3 -> // Transport endpoint at Iaddr 1788 Iaddr,L1:O3 -> // On the wire in datacenter 1789 Iaddr,SIR:O3 // Received at O3 1791 A.7 Scenario 4: Tenant system to service 1793 A tenant can communicate with a datacenter service using the SIR 1794 address of the service. 1796 If TS VA1 is communicating with service S1, the ILA translation 1797 sequence would be: 1799 VNET:VA1,Saddr-> // Transport endpoints in TS 1800 SIR:(VNET:VA1):Saddr-> // On the wire 1801 SIR:(VNET:VA1):Saddr // Received at S1 1803 Where VNET is the address prefix for the tenant and Saddr is the IPv6 1804 address of the service. 1806 The ILA translation sequence in the reverse path, service to tenant 1807 system, would be: 1809 Saddr,SIR:(VNET:VA1) // Transport endpoints in S1 1810 Saddr,L1:(VNET:VA1) // On the wire 1811 Saddr,VNET:VA1 // Received at the TS 1813 Note that from the point of view of the service task there is no 1814 material difference between a peer that is a tenant system versus one 1815 which is another task. 1817 A.8 Scenario 5: Object to tenant system 1819 An object can communicate with a tenant system through it's 1820 externally visible address. 1822 If object O2 is communicating with TS VA4, the ILA translation 1823 sequence would be: 1825 SIR:O2,VNET:VA4 -> // Transport endpoints at T2 1826 SIR:O2,L4:(VNI2:VAX4) -> // On the wire 1827 SIR:O2,VNET:VA4 // Received at TS 1829 A.9 Scenario 6: Tenant system to Internet 1831 Communication from a TS to the Internet assumes that the VNET for the 1832 TS is globally routable, hence no ILA translation would be needed. 1834 If TS VA4 sends a packet to the Internet, the addresses would be: 1836 VNET:VA4,Iaddr 1838 A.10 Scenario 7: Internet to tenant system 1840 An Internet host transmits a packet to a tenant system using an 1841 externally routable tenant prefix and address. The prefix routes the 1842 packet to a gateway for the datacenter. The gateway translates the 1843 destination to an ILA address. 1845 If a host on the Internet with address Iaddr is sending to TS VA4, 1846 the ILA translation sequence would be: 1848 Iaddr,VNET:VA4 -> // Endpoint at Iaddr 1849 Iaddr,L4:(VNI2:VAX4) -> // On the wire in datacenter 1850 Iaddr,VNET:VA4 // Received at TS 1852 A.11 Scenario 8: IPv4 tenant system to object 1854 A TS that is IPv4-only may communicate with an object using protocol 1855 translation. The object would be represented as an IPv4 address in 1856 the tenant's address space, and stateless NAT64 should be usable as 1857 described in [RFC6145]. 1859 If TS VA2 communicates with object O3, the ILA translation sequence 1860 would be: 1862 VA2,ADDR3 -> // IPv4 endpoints at TS 1863 SIR:(VNI1:VA2),L3:O3 -> // On the wire in datacenter 1864 SIR:(VNI1:VA2),SIR:O3 // Received at task 1866 VA2 is the IPv4 address in the tenant's virtual network, ADDR4 is an 1867 address in the tenant's address space that maps to the network 1868 service. 1870 The reverse path, task sending to a TS with an IPv4 address, requires 1871 a similar protocol translation. 1873 For object O3 communicate with TS VA2, the ILA translation sequence 1874 would be: 1876 SIR:O3,SIR:(VNI1:VA2) -> // Endpoints at T4 1877 SIR:O3,L2:(VNI1:VA2) -> // On the wire in datacenter 1878 ADDR4,VA2 // IPv4 endpoint at TS 1880 A.12 Tenant to tenant system in the same virtual network 1882 ILA may be used to allow tenants within a virtual network to 1883 communicate without the need for explicit encapsulation headers. 1885 A.12.1 Scenario 9: TS to TS in the same VN using IPV6 1887 If TS VA1 sends a packet to TS VA2, the ILA translation sequence 1888 would be: 1890 VNET:VA1,VNET:VA2 -> // Endpoints at VA1 1891 VNET:VA1,L2:(VNI1,VAX2) -> // On the wire 1892 VNET:VA1,VNET:VA2 -> // Received at VA2 1894 A.12.2 Scenario 10: TS to TS in same VN using IPv4 1896 For two tenant systems to communicate using IPv4 and ILA, IPv4/IPv6 1897 protocol translation is done both on the transmit and receive. 1899 If TS VA1 sends an IPv4 packet to TS VA2, the ILA translation 1900 sequence would be: 1902 VA1,VA2 -> // Endpoints at VA1 1903 SIR:(VNI1:VA1),L2:(VNI1,VA2) -> // On the wire 1904 VA1,VA2 // Received at VA2 1906 Note that the SIR is chosen by an ILA node as an appropriate SIR 1907 prefix in the underlay network. Tenant systems do not use SIR address 1908 for this communication, they only use virtual addresses. 1910 A.13 Tenant system to tenant system in different virtual networks 1912 A tenant system may be allowed to communicate with another tenant 1913 system in a different virtual network. This should only be allowed 1914 with explicit policy configuration. 1916 A.13.1 Scenario 11: TS to TS in different VNs using IPV6 1918 For TS VA4 to communicate with TS VA1 using IPv6 the translation 1919 sequence would be: 1921 VNET2:VA4,VNET1:VA1-> // Endpoint at VA4 1922 VNET2:VA4,L1:(VNI1,VAX1)-> // On the wire 1923 VNET2:VA4,VNET1:VA1 // Received at VA1 1925 Note that this assumes that VNET1 and VNET2 are globally routable 1926 between the two virtual networks. 1928 A.13.2 Scenario 12: TS to TS in different VNs using IPv4 1930 To allow IPv4 tenant systems in different virtual networks to 1931 communicate with each other, an address representing the peer would 1932 be mapped into each tenant's address space. IPv4/IPv6 protocol 1933 translation is done on transmit and receive. 1935 For TS VA4 to communicate with TS VA1 using IPv4 the translation 1936 sequence may be: 1938 VA4,SADDR1 -> // IPv4 endpoint at VA4 1939 SIR:(VNI2:VA4),L1:(VNI1,VA1)-> // On the wire 1940 SADDR4,VA1 // Received at VA1 1942 SADDR1 is the mapped address for VA1 in VA4's address space, and 1943 SADDR4 is the mapped address for VA4 in VA1's address space. 1945 A.13.3 Scenario 13: IPv4 TS to IPv6 TS in different VNs 1947 Communication may also be mixed so that an IPv4 tenant system can 1948 communicate with an IPv6 tenant system in another virtual network. 1949 IPv4/IPv6 protocol translation is done on transmit. 1951 For TS VA4 using IPv4 to communicate with TS VA1 using IPv6 the 1952 translation sequence may be: 1954 VA4,SADDR1 -> // IPv4 endpoint at VA4 1955 SIR:(VNI2:VA4),L1:(VNI1,VAX1)-> // On the wire 1956 SIR:(VNI2:VA4),VNET1:VA1 // Received at VA1 1958 SADDR1 is the mapped IPv4 address for VA1 in VA4's address space. 1960 In the reverse direction, TS VA1 using IPv6 would communicate with TS 1961 VA4 with the translation sequence: 1963 VNET1:VA1,SIR:(VNI2:VA4) // Endpoint at VA1 1964 VNET1:VA1,L4:(VNI2:VA4) // On the wire 1965 SADDR1,VA4 // Received at VA4 1967 A.14 Scenario 14: Non-local address to tenant system 1969 A tenant system may have a global address that is non-local to the 1970 network. A host on the Internet or a tenant system may send packet to 1971 this address. The packet is forwarded by some means to a gateway or 1972 other ILA node (tunneling could be used to accomplish this). An ILA 1973 node can crate a an ILA address for this using a non-local address 1974 identifier. 1976 For a node sending to a non-local address that is an address of task 1977 T2, the ILA translation sequence would be: 1979 SADDR,A // Endpoint at a host 1980 SADDR,L3:X // On the wire 1981 SADDR,A // Received by TS 2 1983 Note that A is the non-local address, and X is is an identifier that 1984 maps to the non-local address. 1986 Appendix B: unique identifier generation 1988 The unique identifier type of ILA identifiers can address 2**60 1989 objects (assuming the typed identifier format is used as described in 1990 section 4). This appendix describes some method to perform allocation 1991 of identifiers for objects to avoid duplicated identifiers being 1992 allocated. 1994 B.1 Globally unique identifiers method 1996 For small to moderate sized deployments the technique for creating 1997 locally assigned global identifiers described in [RFC4193] could be 1998 used. In this technique a SHA-1 digest of the time of day in NTP 1999 format and an EUI-64 identifier of the local host is performed. N 2000 bits of the result are used as the globally unique identifier. 2002 The probability that two or more of these IDs will collide can be 2003 approximated using the formula: 2005 P = 1 - exp(-N**2 / 2**(L+1)) 2007 where P is the probability of collision, N is the number of 2008 identifiers, and L is the length of an identifier. 2010 The following table shows the probability of a collision for a range 2011 of identifiers using a 60-bit length. 2013 Identifiers Probability of Collision 2014 1000 4.3368*10^-13 2015 10000 4.3368*10^-11 2016 100000 4.3368*10^-09 2017 1000000 4.3368*10^-07 2019 Note that locally unique identifiers may be ephemeral, for instance a 2020 task may only exist for a few seconds. This should be considered when 2021 determining the probability of identifier collision. 2023 B.2 Universally Unique Identifiers method 2025 For larger deployments, hierarchical allocation may be desired. The 2026 techniques in Universally Unique Identifier (UUID) URN ([RFC4122]) 2027 can be adapted for allocating unique object identifiers in sixty 2028 bits. An identifier is split into two components: a registrar prefix 2029 and sub-identifier. The registrar prefix defines an identifier block 2030 which is managed by an agent, the sub-identifier is a unique value 2031 within the registrar block. 2033 For instance, each host in a network could be an agent so that unique 2034 identifiers for objects could be created autonomously by the host. 2035 The identifier might be composed of a twenty-four bit host identifier 2036 followed by a thirty-six bit timestamp. Assuming that a host can 2037 allocate up to 100 identifiers per second, this allows about 21.8 2038 years before wrap around. 2040 /* LUI identifier with host registrar and timestamp */ 2041 |3 bits|1| 24 bits | 36 bits | 2042 +------+-------------------+-------------------------------------+ 2043 | 0x1 |C| Host identifier | Timestamp Identifier | 2044 +----------------------------------------------------------------+ 2046 Appendix C: Datacenter task virtualization 2048 This section describes some details to apply ILA to virtualizing 2049 tasks in a datacenter. 2051 C.1 Address per task 2053 Managing the port number space for services within a datacenter is a 2054 nontrivial problem. When a service task is created, it may run on 2055 arbitrary hosts. The typical scenario is that the task will be 2056 started on some machine and will be assigned a port number for its 2057 service. The port number must be chosen dynamically to not conflict 2058 with any other port numbers already assigned to tasks on the same 2059 machine (possibly even other instances of the same service). A 2060 canonical name for the service is entered into a database with the 2061 host address and assigned port. When a client wishes to connect to 2062 the service, it queries the database with the service name to get 2063 both the address of an instance as well as its port number. Note that 2064 DNS is not adequate for the service lookup since it does not provide 2065 port numbers. 2067 With ILA, each service task can be assigned its own IPv6 address and 2068 therefore will logically be assigned the full port space for that 2069 address. This a dramatic simplification since each service can now 2070 use a publicly known port number that does not need to unique between 2071 services or instances. A client can perform a lookup on the service 2072 name to get an IP address of an instance and then connect to that 2073 address using a well known port number. In this case, DNS is 2074 sufficient for directing clients to instances of a service. 2076 C.2 Job scheduling 2078 In the usual datacenter model, jobs are scheduled to run as tasks on 2079 some number of machines. A distributed job scheduler provides the 2080 scheduling which may entail considerable complexity since jobs will 2081 often have a variety of resource constraints. The scheduler takes 2082 these constraints into account while trying to maximize utility of 2083 the datacenter in terms utilization, cost, latency, etc. Datacenter 2084 jobs do not typically run in virtual machines (VMs), but may run 2085 within containers. Containers are mechanisms that provide resource 2086 isolation between tasks running on the same host OS. These resources 2087 can include CPU, disk, memory, and networking. 2089 A fundamental problem arises in that once a task for a job is 2090 scheduled on a machine, it often needs to run to completion. If the 2091 scheduler needs to schedule a higher priority job or change resource 2092 allocations, there may be little recourse but to kill tasks and 2093 restart them on a different machine. In killing a task, progress is 2094 lost which results in increased latency and wasted CPU cycles. Some 2095 tasks may checkpoint progress to minimize the amount of progress 2096 lost, but this is not a very transparent or general solution. 2098 An alternative approach is to allow transparent job migration. The 2099 scheduler may migrate running jobs from one machine to another. 2101 C.3 Task migration 2103 Under the orchestration of the job scheduler, the steps to migrate a 2104 job may be: 2106 1) Stop running tasks for the job. 2107 2) Package the runtime state of the job. The runtime state is 2108 derived from the containers for the jobs. 2109 3) Send the runtime state of the job to the new machine where the 2110 job is to run. 2111 4) Instantiate the job's state on the new machine. 2112 5) Start the tasks for the job continuing from the point at which 2113 it was stopped. 2115 This model similar to virtual machine (VM) migration except that the 2116 runtime state is typically much less data-- just task state as 2117 opposed to a full OS image. Task state may be compressed to reduce 2118 latency in migration. 2120 C.3.1 Address migration 2122 ILA facilitates address (specifically identifier address) migration 2123 between hosts as part of task migration or for other purposes. The 2124 steps in migrating an address might be: 2126 1) Configure address on the target host. 2128 2) Suspend use of the address on the old host. This includes 2129 handling established connections (see next section). A state 2130 may be established to drop packets or send ICMP destination 2131 unreachable when packets to the migrated address are received. 2133 3) Update the identifier to locator mapping database. Depending on 2134 the control plane implementation this may include pushing the 2135 new mapping to hosts. 2137 4) Communicating hosts will learn of the new mapping via a control 2138 plane either by participation in a protocol for mapping 2139 propagation or by the ILA resolution protocol. 2141 C.3.2 Connection migration 2143 When a task and its addresses are migrated between machines, the 2144 disposition of existing TCP connections needs to be considered. 2146 The simplest course of action is to drop TCP connections across a 2147 migration. Since migrations should be relatively rare events, it is 2148 conceivable that TCP connections could be automatically closed in the 2149 network stack during a migration event. If the applications running 2150 are known to handle this gracefully (i.e. reopen dropped connections) 2151 then this may be viable. 2153 For seamless migration, open connections may be migrated between 2154 hosts. Migration of these entails pausing the connection, packaging 2155 connection state and sending to target, instantiating connection 2156 state in the peer stack, and restarting the connection. From the time 2157 the connection is paused to the time it is running again in the new 2158 stack, packets received for the connection should be silently 2159 dropped. For some period of time, the old stack will need to keep a 2160 record of the migrated connection. If it receives a packet, it should 2161 either silently drop the packet or forward it to the new location. 2163 Appendix D: Mobility in wireless networks 2165 ILA can be used in public wireless networks to provide a solution for 2166 mobility. 2168 Devices in a carrier network are referred to as User Equipment (UE) 2169 and can include smart phones, automobiles, and other IoT devices. UEs 2170 attach to provider network at base stations (eNodeB in carrier 2171 terminology). As the device moves, it may change it's point of 2172 attachment to a geographically close base station. A cellular network 2173 is composed of cells each of which has an eNodeB. 2175 A node may change cells several times over a time period. In order to 2176 provide seamless communications it is desirable that the existing 2177 connections of the device are preserved. ILA provides for this by 2178 assigning SIR addresses to UEs and deploying ILA routers in the 2179 network infrastructure. 2181 In a canonical architecture each base station (eNodeB) would have an 2182 ILA router, and there would be a number of ILA routers that serve as 2183 gateways between a provider's network and the Internet. When a host 2184 on the Internet sends to a UE's SIR address, a gateway ILA router 2185 will translate the address. The locator addresses the base station 2186 that is the current point of attachment. At the base station ILA 2187 router, the destination is transformed back to a SIR address and 2188 delivered to a UE. A similar process can happen when two UEs in the 2189 network communicate. 2191 The wireless network use case is conceptually similar to network 2192 virtualization. In both scenarios, nodes have a point of attachment 2193 and can move to other points of attachment. The difference is that in 2194 network virtualization it is virtual machines that are mobile, in 2195 wireless networks it is real devices. 2197 The wireless use case has some unique properties: 2199 o These are often public networks so that privacy is a 2200 consideration. It is likely that devices may have many addresses 2201 assigned to promote privacy. Strong privacy addresses may be 2202 needed [ADDRPRIV]. 2204 o A single device might have many identifiers assigned to it. When 2205 a device moves, all of the identifiers must change to map to the 2206 same locator. 2208 o Devices move on their own accord so that mobility is 2209 unpredictable. 2211 o There are mostly real humans using devices so that human 2212 identity and exposing geo location are concerns. 2214 Author's Address 2216 Tom Herbert 2217 Quantonium 2218 4701 Patrick Henry Dr. 2219 Santa Clara, CA 2221 EMail: tom@herbertland.com 2223 Petr Lapukhov 2224 1 Hacker Way 2225 Menlo Parck, CA 2227 EMail: petr@fb.com