idnits 2.17.1 draft-herbert-ila-motivation-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2018) is 2284 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'RFC4459' on line 164 looks like a reference -- Missing reference section? 'RFC2983' on line 165 looks like a reference -- Missing reference section? 'RFC6040' on line 167 looks like a reference -- Missing reference section? 'RFC6935' on line 168 looks like a reference -- Missing reference section? 'RFC6936' on line 168 looks like a reference -- Missing reference section? 'RFC7872' on line 188 looks like a reference -- Missing reference section? 'RFC3513' on line 338 looks like a reference -- Missing reference section? 'RFC4941' on line 388 looks like a reference -- Missing reference section? 'RFC1122' on line 568 looks like a reference -- Missing reference section? 'RFC820' on line 592 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Informational Quantonium 4 Expires: July 2018 6 January 22, 2018 8 Identifier Locator Addressing: Problem areas, Motivation, and Use Cases 9 draft-herbert-ila-motivation-00 11 Abstract 13 This document describes the problems, motivation, and use cases for 14 Identifier-Locator Addressing. 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Copyright and License Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2 Problem areas . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1 Identifier/locator split . . . . . . . . . . . . . . . . . 3 57 2.2 Efficiency of network overlay techniques . . . . . . . . . 3 58 2.3 Ramifications of network tunneling . . . . . . . . . . . . 4 59 2.4 Networking hardware compatibility . . . . . . . . . . . . . 4 60 2.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.6 Mapping systems . . . . . . . . . . . . . . . . . . . . . . 5 62 2.6.1 Nodes with complete set of mappings . . . . . . . . . . 5 63 2.6.2 Mapping caches . . . . . . . . . . . . . . . . . . . . . 5 64 2.7 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 2.7.1 Geo-location . . . . . . . . . . . . . . . . . . . . . . 6 66 2.7.2 Privacy in addresses . . . . . . . . . . . . . . . . . . 7 67 2.8 Address assignment . . . . . . . . . . . . . . . . . . . . 8 68 2.9 Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 2.10 Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 2.10.1 Mapping information . . . . . . . . . . . . . . . . . . 10 71 2.10.2 Mapping protocols . . . . . . . . . . . . . . . . . . . 10 72 2.12 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 73 2.13 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 3 Motivation for ILA . . . . . . . . . . . . . . . . . . . . . . 11 75 3.1 Alternative network overlay technologies . . . . . . . . . 11 76 3.1.1 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 3.1.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . 12 78 3.1.3 Segment routing . . . . . . . . . . . . . . . . . . . . 13 79 3.1.4 Network Address Translation . . . . . . . . . . . . . . 13 80 3.1.5 Transport layer mechanisms . . . . . . . . . . . . . . . 14 81 3.2 Benefits of ILA . . . . . . . . . . . . . . . . . . . . . . 14 82 3.3 Limitations and caveats of ILA . . . . . . . . . . . . . . 16 83 4 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 84 4.1 Mobility networks . . . . . . . . . . . . . . . . . . . . . 16 85 4.2 Datacenter virtualization . . . . . . . . . . . . . . . . . 17 86 4.3 Network virtualization . . . . . . . . . . . . . . . . . . 17 87 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 88 5.1 Normative References . . . . . . . . . . . . . . . . . . . 17 89 5.2 Informative References . . . . . . . . . . . . . . . . . . 17 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 1 Introduction 94 Identifier-locator addressing (ILA) is a protocol based on 95 identifier/locator split that provides network overlays without the 96 use of encapsulation or extension headers. ILA operates at the 97 network layer and is intended to be transparent to both applications 98 and transport layer protocols. 100 This document highlights problem areas, motivation, and use cases of 101 ILA. Problem areas include protocol efficiency, scalability, 102 mobility, privacy, and security for network overlays and 103 identifier/locator split. The motivation for ILA is provided in terms 104 of how ILA addresses the problems and its advantages over alternative 105 approaches. The use cases of ILA include mobility, datacenter 106 virtualization, and network virtualization; some details and 107 considerations for these use cases are provided. 109 2 Problem areas 111 This section highlights some of the problems faced for use of 112 identifier/locator split and network overlays. 114 2.1 Identifier/locator split 116 Identifier/locator split is a technique that has long been discussed 117 within IETF. This is the answer to the problem that IP addresses have 118 traditionally been overloaded with two characteristics: they indicate 119 both the identity of a node and its location. Identifier/locator 120 split endeavors to separate these two notions. A node has identity 121 and location, but they are separate elements in addressing. This 122 disassociation of identity and location allows nodes to become 123 "virtual" and mobile. This distinction has been made in network 124 virtualization and mobility networks for some time, however demand 125 for mobility and virtualization is continuously increasing so that in 126 the future a majority of nodes might be virtualized and subject to 127 identifier/locator split. 129 Deployment of identifier/locator split in existing networks can raise 130 a number of issues. Since addresses no longer contain location, 131 routing needs to change and routing tables need to scale to include 132 many more destinations. Logging and tools also need to change to take 133 into account that location and identity may be separate notions in an 134 address. 136 2.2 Efficiency of network overlay techniques 138 With the emergence of applications such as AR, VR, machine learning, 139 and road safety information, the demands for low latency, high 140 throughput, and highly reliable networking are only increasing. Low 141 latency networking is no longer confined to the purview of 142 specialized application centric networks, requirements for very low 143 latency are being introduced into public access networking 144 technologies such as 5G. As such, the efficiency and performance of 145 network overlays becomes important. 147 Network overlays are a benefit since they facilitates node mobility 148 and malleability in use of network resources. These benefits tend to 149 be architectural in the network and not necessarily obvious to the 150 users or applications in the network. For instance, network overlays 151 facilitate mobility, however the cost of that capability to 152 applications must be taken into a account. Mobility is likely a rare 153 event, and there are many nodes that will never move during their 154 lifetime. When a node is not moving, the cost incurred for having the 155 capability to move should be near zero. 157 2.3 Ramifications of network tunneling 159 The ramifications and issues with tunneling in the network have been 160 well documented and discussed in IETF. 162 If encapsulation is being used in the network to implement a tunnel 163 then the packet size increases so exceeding the MTU is a concern; 164 [RFC4459] discusses MTU and fragmentation considerations for network 165 tunneling. [RFC2983] discusses the interactions of differentiated 166 services with tunnels and procedures to translate diffserv for an 167 inner packet to the outer one. [RFC6040] specifies handling of 168 Explicit Congestion Notification in a tunnel. [RFC6935] and [RFC6936] 169 discuss at length the requirements that must be meant for allowing a 170 zero UDPv6 checksum to be used for tunnels. 172 The upshot is that defining and correctly implementing tunnels in the 173 network is a nontrivial exercise. 175 2.4 Networking hardware compatibility 177 The effects of deploying a protocol with existing network hardware 178 implementation must be considered. Generally, hardware 179 implementations (switches, router, NICs, etc.) are optimized for 180 certain protocols and protocol features. Most devices implement 181 optimizations for the two most common transport protocols, namely TCP 182 and UDP. These optimizations include features like ECMP, checksum 183 offload, and segmentation offload. As one moves away from use of 184 commonly supported protocols, the benefits of optimizations and even 185 feasibility of protocols or protocol features dwindles. For example, 186 IPv6 extension headers have had a checkered history of being properly 187 supported by intermediate nodes, and hence are considered precarious 188 for use on the Internet [RFC7872]. 190 Note that many new encapsulation protocols (GUE, GRE/UDP, LISP, 191 Geneve, etc.) employ encapsulation in UDP. The use of UDP makes 192 packets more palatable to network devices, albeit at the cost of UDP 193 header overhead and additional processing overhead. 195 2.5 Mobility 197 For seamless mobility, a node retains its IP address and connections 198 remain established across mobile events. If network mobility is 199 handled in the network layer then moving should be transparent to the 200 application with only the possibly that latency is increased for a 201 few packets. 203 Mobility is present in different use cases whenever a node changes 204 its point of attachment in the network. When this happens the 205 location of the node and hence its locator changes. A key attribute 206 of an identifier/locator solution is how the network converges when a 207 change occurs. During the convergence period, latency is expected to 208 be bounded and packet loss is expected to be minimized or avoided 209 entirely. 211 2.6 Mapping systems 213 Identifier/locator split solutions employ a mapping system that 214 provides identifier to locator mappings. Similar to IP routing, there 215 may be both nodes that maintain a full list of mappings (analogous to 216 core routers) and nodes that maintain a cache of mappings (analogous 217 to nodes with a neighbor discovery cache). 219 2.6.1 Nodes with complete set of mappings 221 The complete set of mappings in a network might be sharded across 222 some number of nodes. Each node maintains a complete list of mappings 223 for their respective shard. Furthermore, each shard may be replicated 224 on several nodes for redundancy and load balancing. All the nodes for 225 a shard must synchronize information upon changes using a protocol 226 amongst themselves. The time it takes for all nodes to converge when 227 a change happens can correlate to perceived application latency. 229 2.6.2 Mapping caches 231 Anchorless mobility is a goal of identifier/locator split. For 232 achieving low latency, direct routing is preferred. Forwarding nodes 233 that contain a cache of mapping entries may be deployed at or near 234 source hosts to optimize forwarding. These nodes maintain a cache of 235 mapping entries used to directly forward packet to peers in the same 236 identifier/locator domain. The use of a cache avoids triangular 237 routing through an intermediate device that has a complete list of 238 mappings. 240 Mapping caches may be populated either by "push" or "pull" model. In 241 the push model, nodes are informed of changes to the mappings for 242 nodes they are interested in. A node may register to get 243 notifications of changes from authoritative nodes in the mapping 244 system. This is the pub/sub model. In the pull model, a node queries 245 an authoritative node to resolve a mapping for an identifier it is 246 interested in; typically this is done on demand when a packet is 247 being forwarded to a destination address whose mapping is yet not in 248 the cache. 250 Both the pull model and push model have their advantages and 251 disadvantages. The push model (aka pub/sub) should result in faster 252 and more accurate convergence, however may require more 253 communications and be harder to scale than the pull model. The pull 254 model may be more susceptible to Denial of Service attack. 256 Secure redirects are hybrid of the push and pull model. A cache entry 257 is populated by an authoritative node that is forwarding a packet. 258 This "redirect" eliminates triangular routing from the source to the 259 destination. Redirects must be secure since to prevent destination 260 hijacking. 262 2.7 Privacy 264 Identifier/locator split can benefit user privacy, particularly in 265 what is exposed in IP addresses. The benefit is only viable if 266 locators that imply geo-location and identities are not revealed to 267 untrusted parties. 269 2.7.1 Geo-location 271 An effect of identifier/locator split is that location is no longer 272 an inherent component of IP addresses. This is a benefit to user 273 privacy as it can reduce the inference of geo-location of a user 274 based on IP addresses. However, strong privacy implies that locators, 275 which could very well reveal geo-location, are only visible to 276 trusted entities. 278 Conceivably, an identifier-locator protocol could be run at the end 279 user devices in a public network (e.g. UEs in a mobile network). This 280 section provides a privacy argument against that. 282 The major problem with running an identifier/locator protocol on end 283 user devices is that the devices are not controlled by the network 284 infrastructure. User devices on a public network, such as Android 285 devices, can easily be hacked to allow root access to the device. 286 Once a user has root access they can install any program they wish on 287 the device including those that could disable or circumvent security 288 or accounting related to identifier/locator split protocol. 290 If root access can be gained on an end user device, this leads to the 291 stalker problem which would be a very easy means to track 292 individuals. This exploit is described below: 294 * Suppose that a user device participates in an identifier/locator 295 split protocol such that they cache locators and use locators to 296 directly send to peer devices. 298 * A hacker might tap all packets sent or received on the network 299 interfaces which makes locators visible to them. 301 * In order to be able to tap packets, a user needs root access to 302 the device. There are instructions on the web to root an Android 303 device. Similarly, jailbreaking can be done to circumvent 304 restrictions on an iPhone to gain the equivalent of root access. 306 * Once root access has been obtained, packets can be tapped using 307 tcpdump or similar packet sniffer applications. 309 * With the tap running and packet addresses being captured, the 310 hacker just needs to drive around sendimg traffic between two 311 devices in their car. They can observe the locators that are 312 assigned to the their device, and from this can create a geo map 313 of locators. 315 * Given that one hacker can do this, then thousands will do it and 316 web sites will spring up that provide locator geo maps. Efforts 317 to obfuscate or rotate identifiers does not help much here. 318 Obfuscation complicates routing in the network such that more 319 transformations need to happen there. Locator rotation is 320 defeated if there are enough devices to keep the maps up to date 321 in a mashup. 323 * The net effect is that this enables a stalker attack. An 324 individual simply initiates a communication with their target. 325 For instance, this could be a chat or phone call. If in doing 326 this the locators for the device belonging to the target are 327 made visible to the hacker, then the physical location of the 328 target can be deduced using the locator geo maps described 329 above. 331 2.7.2 Privacy in addresses 332 A node may use multiple addresses to prevent inferences by third 333 parties that break privacy. Properties of addresses to maintain 334 strong privacy are: 336 * They are composed of a global routing prefix and a suffix that 337 is internal to an organization or provider. This is the same 338 property for IP addresses [RFC3513]. 340 * The registry and organization of an address can be determined by 341 the network prefix. This is true for any global address. 343 * The organizational bits in the address should have minimal 344 hierarchy to prevent inference. It might be reasonable to have 345 an internal prefix that divides identifiers based on broad 346 geographic regions, but detailed information such as accurate 347 location, department in an enterprise, or device type should not 348 be encoded in a globally visible address. 350 * Given two addresses and no other information, the desired 351 properties of correlating them are: 353 * It can be inferred if they belong the same organization and 354 registry. This is true for any two global IP addresses. 356 * It may be inferred that they belong to the same broad 357 grouping, such as a geographic region, if the information is 358 encoded in the organizational bits of the address (e.g. are 359 in the same shard). 361 * No other correlation can be established. For example, it 362 cannot be inferred that the IP addresses address the same 363 node, the addressed nodes reside in the same subnet, rack, or 364 department, or that the nodes for the two addresses have any 365 geographic proximity to one another. 367 2.8 Address assignment 369 In an identifier/locator split protocol, end hosts are assigned 370 addresses that serve as identifiers. A device may be assigned a 371 network prefix or singleton addresses. 373 A end host may be assigned a /64 address via SLAAC as is common in 374 many provider networks. In this scenario, the low order sixty-four 375 bits contains IIDs arbitrarily assigned by devices for its purposes; 376 so these bits cannot be used as an identifier in identifier/locator 377 split. Effectively, the upper sixty-four bits is the identifier of 378 the node. 380 Ostensibly, assigning a /64 prefix to a node is good for security. 381 The end device can create its own random addresses in the low order 382 sixty-four bits which mitigates address scanning attacks. However, 383 the upper sixty for bits of the address become a static identifier 384 for the device which potentially allows DOS on the device as well as 385 correlating different addresses in the Internet as being sourced from 386 the same device. 388 [RFC4941] recommends rotating addresses to protect privacy. In the 389 case of sixty-four bit address assignments this would entail that a 390 new prefix for the device is periodically requested. There is no 391 recommendation for the frequency of address change and there is no 392 quantitative description of the effects of periodic address change. 394 The following exploit is proposed to defeat the privacy goal of 395 periodic address rotation: 397 * An attacker creates an "always connected" app that provides some 398 seemingly benign service so that users download the app. 400 * The app includes some sort of persistent identity. For instance, 401 this could be an account login. 403 * The backend server for the app logs the user identity and IP 404 address each time a user connects. 406 * When an address change happens, existing connections on the user 407 device are disconnected. The app will receive a notification and 408 immediately attempt to reconnect using the new source address. 410 * The backend server will see the new connection and log the new 411 IP address as being used by the user. Thus, the server has a 412 real-time record of users and the IP addresses they are using. 414 * The attacker gains access to packet traces taken at some point 415 in the Internet. The addresses in the captured packets can be 416 time correlated with the server database to deduce the identity 417 of the source of packets for communications completely unrelated 418 to the app. 420 This exploit would defeat address rotation with any frequency except 421 the for case that that a different source address is used for each 422 flow. 424 2.9 Scaling 426 Since identity is no longer associated with location, each node 427 becomes separately routable in the network. In identifier/locator 428 split, a table that maps identifiers to locators is maintained. Each 429 destination effectively becomes a host route, and hierarchical 430 routing is generally not usable. For instance, a VM may have a 431 virtual address and might be located anywhere in a network. The 432 mapping table would contain a mapping of the virtual address of the 433 VM to the physical address of the server where the VM is running. 435 The number of virtualized or mobile nodes in a network is expected to 436 grow into the billions. This need for scaling is similar in both 437 mobile networks as well as datacenter and multi-tenant virtual 438 networks. In mobile networks, the explosion of IoT devices drives 439 scaling growth. In the datacenter it is the desire to use fine 440 grained addresses for tasks or more generally addressable virtual 441 objects. 443 2.10 Security 445 2.10.1 Mapping information 447 An identifier/locator solution will contain sensitive information 448 that includes identity and location of nodes. In the case that there 449 is a one-to-one correspondence between a network node and user, for 450 instance the node is a smart phone owned by an individual, this 451 information is Personally Identifiable Information (PII). A mapping 452 system needs to ensure security of this information. 454 2.10.2 Mapping protocols 456 Mapping protocols have a couple of security ramifications. 458 A mapping protocol must be authenticated in order to prevent spoofing 459 of messages. In particular, an attacker cannot be able to hijack a 460 mapping entry to redirect packets to their own node. 462 A mapping protocol must also be resilient to DOS attack, especially 463 in a scenario where a cache of mappings is being employed. Such a 464 cache might be populated in response to the activities of a third 465 party (for instance an application sending packets to different 466 destinations). An attack on the cache whereby an attacker attempts to 467 fill the cache with entries to random destinations must be 468 mitigated. 470 2.12 ICMP 472 ICMP presents problems for network overlays as well as 473 identifier/locator split. Specifically, the problem is how to return 474 ICMP errors to the sender that were caused as a result of using a 475 network overlay. ICMP errors that are returned to the source may 476 require translation of address in the ICMP data or other 477 modifications. There may also be security ramifications with ICMP, 478 for instance filtering ICMP may be necessary to prevent locator 479 information from leaking out of a network. 481 2.13 Multicast 483 Multicast is problematic in identifier/locator split since the 484 routing depends on the source address of a packet. If using the 485 network layer multicast, the source address must be a locator not an 486 identifier. 488 3 Motivation for ILA 490 3.1 Alternative network overlay technologies 492 A number of solutions for network overlays have be been defined or 493 proposed in IETF. This section considers layer 3 network overlay 494 solutions, and a few related layer 4 solutions for comparison. An 495 overview of each is provided along with a description of how they 496 deal with the problems enumerated in section 2 and where they are 497 deficient. 499 3.1.1 ILNP 501 Identifier-Locator Network Protocol (ILNP) is similar to ILA and in 502 fact some of the concepts of ILA were adapted from ILNP. 504 ILNP explicitly replaces the use of IP Addresses with two distinct 505 name spaces, each having distinct and different semantics: 507 a) Identifier: a non-topological name for uniquely identifying a 508 node. 510 b) Locator: a topologically bound name for an IP subnetwork. 512 Characteristics of ILNP are: 514 * ILNP changes the meaning of IP addresses. 516 * ILNP requires changes to transport layer protocols. Transport 517 layer endpoints are no longer IP addresses they are identifier 518 values. 520 * The pseudo header for TCP and UDP checksum changes. This might 521 break intermediate nodes that perform checkusm calculation such 522 as NICs that provides checksum offload. 524 * ILNP is an end to end overlay mechanism. There is no prescribed 525 method to use ILNP in intermediate nodes. 527 * ILNP defines a Nonce in Destination Options extension header. 529 * ILNP requires applications to use fully qualified domain names. 530 Applications that use IP addresses presumably need to change. 532 3.1.2 Encapsulation 534 Various encapsulation techniques are used to achieve layer 3 network 535 overlays. These includes IPIP, LISP, GRE, VXLAN, GUE, GTP-U, Geneve, 536 etc. These encapsulation protocols provide the means to create 537 overlays over IP networks via IP over IP encapsulation. They differ 538 in format and extensibility. For instance, IPIP is the simplest 539 method that just encapsulates one IP packet in another. GUE is a UDP 540 based encapsulation that is both generic and extensible. 542 Characteristics of encapsulation are: 544 * While encapsulation has proven functional and useful, it incurs 545 significant on-the-wire overhead, require substantial 546 processing, and may be incompatible with transport layer 547 specific network optimizations for TCP and UDP 549 * Outer IP header overhead. Adoption of IPv6 exacerbates the 550 overhead of encapsulation. Where simple IPv4 over IPv4 551 encapsulation has an overhead of twenty bytes, IPv6 or IPv4 over 552 IPv6 incurs overhead of forty bytes. 554 * Possible additional header overhead if UDP is used or there is 555 an encapsulation header 557 * Can be used at intermediate nodes for tunneling, so all the 558 issues involving tunneling must be addressed. 560 * Compatibility with hardware is an issue. UDP based encapsulation 561 overcomes some of the issues, but in itself creates new ones. 563 * Checksum handling must be considered in various contexts. 564 Encapsulation may break checksum offload feature commonly 565 implemented in NICs. Some network devices are incapable of 566 computing checksums, so if UDPv6 is used the checksum is often 567 set to zero. Some protocols allow a non-zero UDP checksum to be 568 ignored during reception in violation of [RFC1122]. 570 * Issues around tunneling within the network have to be addressed 571 (described in section 2.3). These include dealing with MTU, IPv6 572 checksum, traceroute, ECN, and how to translate diffserv from an 573 inner header to an outer header. 575 * Encapsulation can be used in the network or at end hosts and 576 doesn't require any changes to transport layer implementation. 578 3.1.3 Segment routing 580 Segment routing (SR) has been proposed as a method to provide 581 identifier/locator split for mobile networks. SR leverages the source 582 routing paradigm. A node steers a packet through an ordered list of 583 instructions, called segments. A segment can represent any 584 instruction, topological or service-based. A segment can have a 585 semantic local to an SR node or global within an SR domain 587 Characteristics of segment routing are: 589 * Requires use of extension headers, specifically a routing 590 header. 592 * [RFC820] prohibits extension header insertion at intermediate 593 nodes. Encapsulation is required at ingress intermediate node to 594 use segment routing. 596 * The segment header itself be significant overhead. A segment 597 routing header with just a single address would be twenty four 598 bytes of overhead. 600 * Transport layer checksum is not kept correct when destination 601 address is changed. This could break checksum offload. 603 * Transport layer checksum does not protect the segment routing 604 header, so additional overhead is needed to detect corruption of 605 the SR header. 607 * Extension headers are not transparent to intermediate nodes and 608 this may cause incompatibility with network hardware 609 implementation resulting in loss of optimizations or relegation 610 to slow path processing. 612 3.1.4 Network Address Translation 614 ILA is similar to NAT (address translation not port translation) in 615 that it operates by rewriting the destination address of packet en 616 route. However, the transformation by ILA is always undone before the 617 packet is delivered to its ultimate destination. 619 Characteristics of NAT: 621 * No additional header overhead. Checksum neutral mapping might be 622 used to maintain correct transport layer checksum. 624 * Not useful as an overlay mechanism since NAT translation is not 625 undone before reception at a receiver 627 3.1.5 Transport layer mechanisms 629 There are a number of techniques used in the transport layer or 630 applications to handle mobility. Strictly speaking, these are not 631 network overlay techniques, however they can be used to provide 632 similar effects in mobility. 634 The simplest way to deal with an address change is just to require an 635 application to reconnect when a connection is disconnected. This is 636 not transparent to an application, it must have a method to 637 checkpoint progress on the connection and implement the reconnect 638 logic (this could be handled in a library). The latency to detect 639 that a connection is dead, reconnect, and then recover to a 640 checkpoint is likely much greater than that of a transparent network 641 layer solution. 643 Alternatively, a transport protocol may employ subflows to construct 644 a logical flow. This is the technique used by MPTCP and QUIC. These 645 techniques are transport layer specific, tend to be driven by one 646 sided, and require network layer information. 648 Proxies can also provide network overlay semantics. However, they 649 require statefulness in the network that creates single point of 650 failure and a potential bottleneck. 652 3.2 Benefits of ILA 654 This section enumerates the benefits of ILA and highlights how the 655 problems described in section 3 are addressed. 657 * ILA has zero on-the-wire overhead. 659 * Processing for ILA is efficient. A basic ILA transformation is 660 done by reading the destination address in a packet, performing 661 a fixed length lookup, and writing the destination address with 662 found locator. 664 * ILA does not employing tunneling so considerations for network 665 tunneling are not a concern. 667 * The ILA domain is effectively a virtual link layer or an 668 underlay network for the traffic being carried between hosts 669 outside of the ILA domain. As long as the ILA domain is 670 perfectly transparent to the overlay network and its hosts, then 671 what ever happens within the ILA domain doesn't matter, similar 672 to how link layer compression, as long as fully and perfectly 673 reversed, also doesn't matter. 675 * ILA maintains a correct transport layer checksum via checksum 676 neutral mapping. 678 * ILA can be deployed either in the network or on end hosts. When 679 deployed at end hosts, certain optimizations are available since 680 ILA is integrated into the host stack 682 * ILA is implemented at network layer. It requires no changes to 683 either applications or transport layer implementations. 685 * ILA is transparent to intermediate nodes so that it is 686 compatible with existing networking hardware and protocol 687 optimizations. A TCP/IP packet is still a TCP/IP packet after 688 being transformed by ILA. 690 * ILA enables singleton address assignment for privacy. It also 691 supports /64 address assignment. 693 * It is recommended that ILA be contained within an ILA domain 694 that is one network under administrative control. Locators are 695 not shared with parties outside of the domain. 697 * ILA espouses the use of secure redirects as the primary means to 698 populate a mapping cache. Push and pull models can be used, 699 however secure redirects should be effective in mitigating DOS 700 attacks and scalable. 702 * ILA allows alternative address representations for 703 identifier/locator split other than the canonical 64/64 split. 704 Non-local identifiers are defined as a method to use identifiers 705 to map to 128 bit IP addresses that might not be local to a 706 network. 708 * ILA defines optional addressing schemas for IPv4 to IPv6 709 translation, network virtualization with an embedded virtual 710 networking identifier, and encoding of IP multicast addresses. 712 * ILA defines identifier groups as a convenient way to group 713 identifiers together that have common characteristics. 714 Identifier groups should reduce the number of operations needed 715 on the mapping system. 717 * A reference datapath implementation is supported in stock Linux 718 since version 4.15. A userspace control path implementation will 719 be open sourced. 721 3.3 Limitations and caveats of ILA 723 This section describes limitations and caveats of ILA. 725 * While ILA has much less overhead than encapsulation or extension 726 headers, this does limit the amount of information that can be 727 expressed. ILA is not extensible like some encapsulations so 728 there is no means to associate ancillary information with ILA. 730 * /64 address assignment is feasible in ILA, however requires a 731 level of indirection in addressing. 733 * ILA operates by transforming destination IP addresses in 734 packets. Source addresses are not transformed. This works very 735 well for unicast traffic, but creates some complexity for 736 multicast in using the network layer multicast with ILA. 738 * If the network generates an ICMP error for a packet whose 739 destination contains a transformed address with a locator, the 740 embedded packet in ICMP data contains a destination address with 741 a locator. Before delivery to the original source host this 742 address should be converted back to the original destination 743 address. 745 * Firewalls should filter addresses in packets before ILA 746 translation. The typical scenario is that when a packet is 747 forwarded to a network ingress point, the firewall inspects the 748 packet before ILA is applied. An firewall internal to the 749 network may see ILA addresses as destinations; this should be 750 taken into account. 752 * Logging and tools need to be adapted since they may be operating 753 on ILA addresses. Logged addresses can be mapped to standard 754 identifier representation either by a fixed mapping or by 755 reverse mapping the address by a lookup in the mapping table. 756 The latter would be needed in the case of non-local identifier 757 addresses. 759 4 Use cases 761 4.1 Mobility networks 762 4.2 Datacenter virtualization 764 4.3 Network virtualization 766 5 References 768 5.1 Normative References 770 5.2 Informative References 772 Author's Address 774 Tom Herbert 775 Quantonium 776 Santa Clara, CA 777 USA 779 Email: tom@quantonium.net