INTERNET-DRAFT T. Herbert Intended Status: Informational Quantonium Expires: July 2018 January 22, 2018 Identifier Locator Addressing: Problem areas, Motivation, and Use Cases draft-herbert-ila-motivation-00 Abstract This document describes the problems, motivation, and use cases for Identifier-Locator Addressing. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents T. Herbert Expires July 26, 2018 [Page 1] INTERNET DRAFT draft-herbert-ila-motivation carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Problem areas . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Identifier/locator split . . . . . . . . . . . . . . . . . 3 2.2 Efficiency of network overlay techniques . . . . . . . . . 3 2.3 Ramifications of network tunneling . . . . . . . . . . . . 4 2.4 Networking hardware compatibility . . . . . . . . . . . . . 4 2.5 Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.6 Mapping systems . . . . . . . . . . . . . . . . . . . . . . 5 2.6.1 Nodes with complete set of mappings . . . . . . . . . . 5 2.6.2 Mapping caches . . . . . . . . . . . . . . . . . . . . . 5 2.7 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.7.1 Geo-location . . . . . . . . . . . . . . . . . . . . . . 6 2.7.2 Privacy in addresses . . . . . . . . . . . . . . . . . . 7 2.8 Address assignment . . . . . . . . . . . . . . . . . . . . 8 2.9 Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.10 Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.10.1 Mapping information . . . . . . . . . . . . . . . . . . 10 2.10.2 Mapping protocols . . . . . . . . . . . . . . . . . . . 10 2.12 ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.13 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . 11 3 Motivation for ILA . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Alternative network overlay technologies . . . . . . . . . 11 3.1.1 ILNP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.2 Encapsulation . . . . . . . . . . . . . . . . . . . . . 12 3.1.3 Segment routing . . . . . . . . . . . . . . . . . . . . 13 3.1.4 Network Address Translation . . . . . . . . . . . . . . 13 3.1.5 Transport layer mechanisms . . . . . . . . . . . . . . . 14 3.2 Benefits of ILA . . . . . . . . . . . . . . . . . . . . . . 14 3.3 Limitations and caveats of ILA . . . . . . . . . . . . . . 16 4 Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1 Mobility networks . . . . . . . . . . . . . . . . . . . . . 16 4.2 Datacenter virtualization . . . . . . . . . . . . . . . . . 17 4.3 Network virtualization . . . . . . . . . . . . . . . . . . 17 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.1 Normative References . . . . . . . . . . . . . . . . . . . 17 5.2 Informative References . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 T. Herbert Expires July 26, 2018 [Page 2] INTERNET DRAFT draft-herbert-ila-motivation 1 Introduction Identifier-locator addressing (ILA) is a protocol based on identifier/locator split that provides network overlays without the use of encapsulation or extension headers. ILA operates at the network layer and is intended to be transparent to both applications and transport layer protocols. This document highlights problem areas, motivation, and use cases of ILA. Problem areas include protocol efficiency, scalability, mobility, privacy, and security for network overlays and identifier/locator split. The motivation for ILA is provided in terms of how ILA addresses the problems and its advantages over alternative approaches. The use cases of ILA include mobility, datacenter virtualization, and network virtualization; some details and considerations for these use cases are provided. 2 Problem areas This section highlights some of the problems faced for use of identifier/locator split and network overlays. 2.1 Identifier/locator split Identifier/locator split is a technique that has long been discussed within IETF. This is the answer to the problem that IP addresses have traditionally been overloaded with two characteristics: they indicate both the identity of a node and its location. Identifier/locator split endeavors to separate these two notions. A node has identity and location, but they are separate elements in addressing. This disassociation of identity and location allows nodes to become "virtual" and mobile. This distinction has been made in network virtualization and mobility networks for some time, however demand for mobility and virtualization is continuously increasing so that in the future a majority of nodes might be virtualized and subject to identifier/locator split. Deployment of identifier/locator split in existing networks can raise a number of issues. Since addresses no longer contain location, routing needs to change and routing tables need to scale to include many more destinations. Logging and tools also need to change to take into account that location and identity may be separate notions in an address. 2.2 Efficiency of network overlay techniques With the emergence of applications such as AR, VR, machine learning, and road safety information, the demands for low latency, high T. Herbert Expires July 26, 2018 [Page 3] INTERNET DRAFT draft-herbert-ila-motivation throughput, and highly reliable networking are only increasing. Low latency networking is no longer confined to the purview of specialized application centric networks, requirements for very low latency are being introduced into public access networking technologies such as 5G. As such, the efficiency and performance of network overlays becomes important. Network overlays are a benefit since they facilitates node mobility and malleability in use of network resources. These benefits tend to be architectural in the network and not necessarily obvious to the users or applications in the network. For instance, network overlays facilitate mobility, however the cost of that capability to applications must be taken into a account. Mobility is likely a rare event, and there are many nodes that will never move during their lifetime. When a node is not moving, the cost incurred for having the capability to move should be near zero. 2.3 Ramifications of network tunneling The ramifications and issues with tunneling in the network have been well documented and discussed in IETF. If encapsulation is being used in the network to implement a tunnel then the packet size increases so exceeding the MTU is a concern; [RFC4459] discusses MTU and fragmentation considerations for network tunneling. [RFC2983] discusses the interactions of differentiated services with tunnels and procedures to translate diffserv for an inner packet to the outer one. [RFC6040] specifies handling of Explicit Congestion Notification in a tunnel. [RFC6935] and [RFC6936] discuss at length the requirements that must be meant for allowing a zero UDPv6 checksum to be used for tunnels. The upshot is that defining and correctly implementing tunnels in the network is a nontrivial exercise. 2.4 Networking hardware compatibility The effects of deploying a protocol with existing network hardware implementation must be considered. Generally, hardware implementations (switches, router, NICs, etc.) are optimized for certain protocols and protocol features. Most devices implement optimizations for the two most common transport protocols, namely TCP and UDP. These optimizations include features like ECMP, checksum offload, and segmentation offload. As one moves away from use of commonly supported protocols, the benefits of optimizations and even feasibility of protocols or protocol features dwindles. For example, IPv6 extension headers have had a checkered history of being properly supported by intermediate nodes, and hence are considered precarious T. Herbert Expires July 26, 2018 [Page 4] INTERNET DRAFT draft-herbert-ila-motivation for use on the Internet [RFC7872]. Note that many new encapsulation protocols (GUE, GRE/UDP, LISP, Geneve, etc.) employ encapsulation in UDP. The use of UDP makes packets more palatable to network devices, albeit at the cost of UDP header overhead and additional processing overhead. 2.5 Mobility For seamless mobility, a node retains its IP address and connections remain established across mobile events. If network mobility is handled in the network layer then moving should be transparent to the application with only the possibly that latency is increased for a few packets. Mobility is present in different use cases whenever a node changes its point of attachment in the network. When this happens the location of the node and hence its locator changes. A key attribute of an identifier/locator solution is how the network converges when a change occurs. During the convergence period, latency is expected to be bounded and packet loss is expected to be minimized or avoided entirely. 2.6 Mapping systems Identifier/locator split solutions employ a mapping system that provides identifier to locator mappings. Similar to IP routing, there may be both nodes that maintain a full list of mappings (analogous to core routers) and nodes that maintain a cache of mappings (analogous to nodes with a neighbor discovery cache). 2.6.1 Nodes with complete set of mappings The complete set of mappings in a network might be sharded across some number of nodes. Each node maintains a complete list of mappings for their respective shard. Furthermore, each shard may be replicated on several nodes for redundancy and load balancing. All the nodes for a shard must synchronize information upon changes using a protocol amongst themselves. The time it takes for all nodes to converge when a change happens can correlate to perceived application latency. 2.6.2 Mapping caches Anchorless mobility is a goal of identifier/locator split. For achieving low latency, direct routing is preferred. Forwarding nodes that contain a cache of mapping entries may be deployed at or near source hosts to optimize forwarding. These nodes maintain a cache of mapping entries used to directly forward packet to peers in the same T. Herbert Expires July 26, 2018 [Page 5] INTERNET DRAFT draft-herbert-ila-motivation identifier/locator domain. The use of a cache avoids triangular routing through an intermediate device that has a complete list of mappings. Mapping caches may be populated either by "push" or "pull" model. In the push model, nodes are informed of changes to the mappings for nodes they are interested in. A node may register to get notifications of changes from authoritative nodes in the mapping system. This is the pub/sub model. In the pull model, a node queries an authoritative node to resolve a mapping for an identifier it is interested in; typically this is done on demand when a packet is being forwarded to a destination address whose mapping is yet not in the cache. Both the pull model and push model have their advantages and disadvantages. The push model (aka pub/sub) should result in faster and more accurate convergence, however may require more communications and be harder to scale than the pull model. The pull model may be more susceptible to Denial of Service attack. Secure redirects are hybrid of the push and pull model. A cache entry is populated by an authoritative node that is forwarding a packet. This "redirect" eliminates triangular routing from the source to the destination. Redirects must be secure since to prevent destination hijacking. 2.7 Privacy Identifier/locator split can benefit user privacy, particularly in what is exposed in IP addresses. The benefit is only viable if locators that imply geo-location and identities are not revealed to untrusted parties. 2.7.1 Geo-location An effect of identifier/locator split is that location is no longer an inherent component of IP addresses. This is a benefit to user privacy as it can reduce the inference of geo-location of a user based on IP addresses. However, strong privacy implies that locators, which could very well reveal geo-location, are only visible to trusted entities. Conceivably, an identifier-locator protocol could be run at the end user devices in a public network (e.g. UEs in a mobile network). This section provides a privacy argument against that. The major problem with running an identifier/locator protocol on end user devices is that the devices are not controlled by the network T. Herbert Expires July 26, 2018 [Page 6] INTERNET DRAFT draft-herbert-ila-motivation infrastructure. User devices on a public network, such as Android devices, can easily be hacked to allow root access to the device. Once a user has root access they can install any program they wish on the device including those that could disable or circumvent security or accounting related to identifier/locator split protocol. If root access can be gained on an end user device, this leads to the stalker problem which would be a very easy means to track individuals. This exploit is described below: * Suppose that a user device participates in an identifier/locator split protocol such that they cache locators and use locators to directly send to peer devices. * A hacker might tap all packets sent or received on the network interfaces which makes locators visible to them. * In order to be able to tap packets, a user needs root access to the device. There are instructions on the web to root an Android device. Similarly, jailbreaking can be done to circumvent restrictions on an iPhone to gain the equivalent of root access. * Once root access has been obtained, packets can be tapped using tcpdump or similar packet sniffer applications. * With the tap running and packet addresses being captured, the hacker just needs to drive around sendimg traffic between two devices in their car. They can observe the locators that are assigned to the their device, and from this can create a geo map of locators. * Given that one hacker can do this, then thousands will do it and web sites will spring up that provide locator geo maps. Efforts to obfuscate or rotate identifiers does not help much here. Obfuscation complicates routing in the network such that more transformations need to happen there. Locator rotation is defeated if there are enough devices to keep the maps up to date in a mashup. * The net effect is that this enables a stalker attack. An individual simply initiates a communication with their target. For instance, this could be a chat or phone call. If in doing this the locators for the device belonging to the target are made visible to the hacker, then the physical location of the target can be deduced using the locator geo maps described above. 2.7.2 Privacy in addresses T. Herbert Expires July 26, 2018 [Page 7] INTERNET DRAFT draft-herbert-ila-motivation A node may use multiple addresses to prevent inferences by third parties that break privacy. Properties of addresses to maintain strong privacy are: * They are composed of a global routing prefix and a suffix that is internal to an organization or provider. This is the same property for IP addresses [RFC3513]. * The registry and organization of an address can be determined by the network prefix. This is true for any global address. * The organizational bits in the address should have minimal hierarchy to prevent inference. It might be reasonable to have an internal prefix that divides identifiers based on broad geographic regions, but detailed information such as accurate location, department in an enterprise, or device type should not be encoded in a globally visible address. * Given two addresses and no other information, the desired properties of correlating them are: * It can be inferred if they belong the same organization and registry. This is true for any two global IP addresses. * It may be inferred that they belong to the same broad grouping, such as a geographic region, if the information is encoded in the organizational bits of the address (e.g. are in the same shard). * No other correlation can be established. For example, it cannot be inferred that the IP addresses address the same node, the addressed nodes reside in the same subnet, rack, or department, or that the nodes for the two addresses have any geographic proximity to one another. 2.8 Address assignment In an identifier/locator split protocol, end hosts are assigned addresses that serve as identifiers. A device may be assigned a network prefix or singleton addresses. A end host may be assigned a /64 address via SLAAC as is common in many provider networks. In this scenario, the low order sixty-four bits contains IIDs arbitrarily assigned by devices for its purposes; so these bits cannot be used as an identifier in identifier/locator split. Effectively, the upper sixty-four bits is the identifier of the node. T. Herbert Expires July 26, 2018 [Page 8] INTERNET DRAFT draft-herbert-ila-motivation Ostensibly, assigning a /64 prefix to a node is good for security. The end device can create its own random addresses in the low order sixty-four bits which mitigates address scanning attacks. However, the upper sixty for bits of the address become a static identifier for the device which potentially allows DOS on the device as well as correlating different addresses in the Internet as being sourced from the same device. [RFC4941] recommends rotating addresses to protect privacy. In the case of sixty-four bit address assignments this would entail that a new prefix for the device is periodically requested. There is no recommendation for the frequency of address change and there is no quantitative description of the effects of periodic address change. The following exploit is proposed to defeat the privacy goal of periodic address rotation: * An attacker creates an "always connected" app that provides some seemingly benign service so that users download the app. * The app includes some sort of persistent identity. For instance, this could be an account login. * The backend server for the app logs the user identity and IP address each time a user connects. * When an address change happens, existing connections on the user device are disconnected. The app will receive a notification and immediately attempt to reconnect using the new source address. * The backend server will see the new connection and log the new IP address as being used by the user. Thus, the server has a real-time record of users and the IP addresses they are using. * The attacker gains access to packet traces taken at some point in the Internet. The addresses in the captured packets can be time correlated with the server database to deduce the identity of the source of packets for communications completely unrelated to the app. This exploit would defeat address rotation with any frequency except the for case that that a different source address is used for each flow. 2.9 Scaling Since identity is no longer associated with location, each node becomes separately routable in the network. In identifier/locator T. Herbert Expires July 26, 2018 [Page 9] INTERNET DRAFT draft-herbert-ila-motivation split, a table that maps identifiers to locators is maintained. Each destination effectively becomes a host route, and hierarchical routing is generally not usable. For instance, a VM may have a virtual address and might be located anywhere in a network. The mapping table would contain a mapping of the virtual address of the VM to the physical address of the server where the VM is running. The number of virtualized or mobile nodes in a network is expected to grow into the billions. This need for scaling is similar in both mobile networks as well as datacenter and multi-tenant virtual networks. In mobile networks, the explosion of IoT devices drives scaling growth. In the datacenter it is the desire to use fine grained addresses for tasks or more generally addressable virtual objects. 2.10 Security 2.10.1 Mapping information An identifier/locator solution will contain sensitive information that includes identity and location of nodes. In the case that there is a one-to-one correspondence between a network node and user, for instance the node is a smart phone owned by an individual, this information is Personally Identifiable Information (PII). A mapping system needs to ensure security of this information. 2.10.2 Mapping protocols Mapping protocols have a couple of security ramifications. A mapping protocol must be authenticated in order to prevent spoofing of messages. In particular, an attacker cannot be able to hijack a mapping entry to redirect packets to their own node. A mapping protocol must also be resilient to DOS attack, especially in a scenario where a cache of mappings is being employed. Such a cache might be populated in response to the activities of a third party (for instance an application sending packets to different destinations). An attack on the cache whereby an attacker attempts to fill the cache with entries to random destinations must be mitigated. 2.12 ICMP ICMP presents problems for network overlays as well as identifier/locator split. Specifically, the problem is how to return ICMP errors to the sender that were caused as a result of using a network overlay. ICMP errors that are returned to the source may T. Herbert Expires July 26, 2018 [Page 10] INTERNET DRAFT draft-herbert-ila-motivation require translation of address in the ICMP data or other modifications. There may also be security ramifications with ICMP, for instance filtering ICMP may be necessary to prevent locator information from leaking out of a network. 2.13 Multicast Multicast is problematic in identifier/locator split since the routing depends on the source address of a packet. If using the network layer multicast, the source address must be a locator not an identifier. 3 Motivation for ILA 3.1 Alternative network overlay technologies A number of solutions for network overlays have be been defined or proposed in IETF. This section considers layer 3 network overlay solutions, and a few related layer 4 solutions for comparison. An overview of each is provided along with a description of how they deal with the problems enumerated in section 2 and where they are deficient. 3.1.1 ILNP Identifier-Locator Network Protocol (ILNP) is similar to ILA and in fact some of the concepts of ILA were adapted from ILNP. ILNP explicitly replaces the use of IP Addresses with two distinct name spaces, each having distinct and different semantics: a) Identifier: a non-topological name for uniquely identifying a node. b) Locator: a topologically bound name for an IP subnetwork. Characteristics of ILNP are: * ILNP changes the meaning of IP addresses. * ILNP requires changes to transport layer protocols. Transport layer endpoints are no longer IP addresses they are identifier values. * The pseudo header for TCP and UDP checksum changes. This might break intermediate nodes that perform checkusm calculation such as NICs that provides checksum offload. T. Herbert Expires July 26, 2018 [Page 11] INTERNET DRAFT draft-herbert-ila-motivation * ILNP is an end to end overlay mechanism. There is no prescribed method to use ILNP in intermediate nodes. * ILNP defines a Nonce in Destination Options extension header. * ILNP requires applications to use fully qualified domain names. Applications that use IP addresses presumably need to change. 3.1.2 Encapsulation Various encapsulation techniques are used to achieve layer 3 network overlays. These includes IPIP, LISP, GRE, VXLAN, GUE, GTP-U, Geneve, etc. These encapsulation protocols provide the means to create overlays over IP networks via IP over IP encapsulation. They differ in format and extensibility. For instance, IPIP is the simplest method that just encapsulates one IP packet in another. GUE is a UDP based encapsulation that is both generic and extensible. Characteristics of encapsulation are: * While encapsulation has proven functional and useful, it incurs significant on-the-wire overhead, require substantial processing, and may be incompatible with transport layer specific network optimizations for TCP and UDP * Outer IP header overhead. Adoption of IPv6 exacerbates the overhead of encapsulation. Where simple IPv4 over IPv4 encapsulation has an overhead of twenty bytes, IPv6 or IPv4 over IPv6 incurs overhead of forty bytes. * Possible additional header overhead if UDP is used or there is an encapsulation header * Can be used at intermediate nodes for tunneling, so all the issues involving tunneling must be addressed. * Compatibility with hardware is an issue. UDP based encapsulation overcomes some of the issues, but in itself creates new ones. * Checksum handling must be considered in various contexts. Encapsulation may break checksum offload feature commonly implemented in NICs. Some network devices are incapable of computing checksums, so if UDPv6 is used the checksum is often set to zero. Some protocols allow a non-zero UDP checksum to be ignored during reception in violation of [RFC1122]. * Issues around tunneling within the network have to be addressed (described in section 2.3). These include dealing with MTU, IPv6 T. Herbert Expires July 26, 2018 [Page 12] INTERNET DRAFT draft-herbert-ila-motivation checksum, traceroute, ECN, and how to translate diffserv from an inner header to an outer header. * Encapsulation can be used in the network or at end hosts and doesn't require any changes to transport layer implementation. 3.1.3 Segment routing Segment routing (SR) has been proposed as a method to provide identifier/locator split for mobile networks. SR leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a semantic local to an SR node or global within an SR domain Characteristics of segment routing are: * Requires use of extension headers, specifically a routing header. * [RFC820] prohibits extension header insertion at intermediate nodes. Encapsulation is required at ingress intermediate node to use segment routing. * The segment header itself be significant overhead. A segment routing header with just a single address would be twenty four bytes of overhead. * Transport layer checksum is not kept correct when destination address is changed. This could break checksum offload. * Transport layer checksum does not protect the segment routing header, so additional overhead is needed to detect corruption of the SR header. * Extension headers are not transparent to intermediate nodes and this may cause incompatibility with network hardware implementation resulting in loss of optimizations or relegation to slow path processing. 3.1.4 Network Address Translation ILA is similar to NAT (address translation not port translation) in that it operates by rewriting the destination address of packet en route. However, the transformation by ILA is always undone before the packet is delivered to its ultimate destination. T. Herbert Expires July 26, 2018 [Page 13] INTERNET DRAFT draft-herbert-ila-motivation Characteristics of NAT: * No additional header overhead. Checksum neutral mapping might be used to maintain correct transport layer checksum. * Not useful as an overlay mechanism since NAT translation is not undone before reception at a receiver 3.1.5 Transport layer mechanisms There are a number of techniques used in the transport layer or applications to handle mobility. Strictly speaking, these are not network overlay techniques, however they can be used to provide similar effects in mobility. The simplest way to deal with an address change is just to require an application to reconnect when a connection is disconnected. This is not transparent to an application, it must have a method to checkpoint progress on the connection and implement the reconnect logic (this could be handled in a library). The latency to detect that a connection is dead, reconnect, and then recover to a checkpoint is likely much greater than that of a transparent network layer solution. Alternatively, a transport protocol may employ subflows to construct a logical flow. This is the technique used by MPTCP and QUIC. These techniques are transport layer specific, tend to be driven by one sided, and require network layer information. Proxies can also provide network overlay semantics. However, they require statefulness in the network that creates single point of failure and a potential bottleneck. 3.2 Benefits of ILA This section enumerates the benefits of ILA and highlights how the problems described in section 3 are addressed. * ILA has zero on-the-wire overhead. * Processing for ILA is efficient. A basic ILA transformation is done by reading the destination address in a packet, performing a fixed length lookup, and writing the destination address with found locator. * ILA does not employing tunneling so considerations for network tunneling are not a concern. T. Herbert Expires July 26, 2018 [Page 14] INTERNET DRAFT draft-herbert-ila-motivation * The ILA domain is effectively a virtual link layer or an underlay network for the traffic being carried between hosts outside of the ILA domain. As long as the ILA domain is perfectly transparent to the overlay network and its hosts, then what ever happens within the ILA domain doesn't matter, similar to how link layer compression, as long as fully and perfectly reversed, also doesn't matter. * ILA maintains a correct transport layer checksum via checksum neutral mapping. * ILA can be deployed either in the network or on end hosts. When deployed at end hosts, certain optimizations are available since ILA is integrated into the host stack * ILA is implemented at network layer. It requires no changes to either applications or transport layer implementations. * ILA is transparent to intermediate nodes so that it is compatible with existing networking hardware and protocol optimizations. A TCP/IP packet is still a TCP/IP packet after being transformed by ILA. * ILA enables singleton address assignment for privacy. It also supports /64 address assignment. * It is recommended that ILA be contained within an ILA domain that is one network under administrative control. Locators are not shared with parties outside of the domain. * ILA espouses the use of secure redirects as the primary means to populate a mapping cache. Push and pull models can be used, however secure redirects should be effective in mitigating DOS attacks and scalable. * ILA allows alternative address representations for identifier/locator split other than the canonical 64/64 split. Non-local identifiers are defined as a method to use identifiers to map to 128 bit IP addresses that might not be local to a network. * ILA defines optional addressing schemas for IPv4 to IPv6 translation, network virtualization with an embedded virtual networking identifier, and encoding of IP multicast addresses. * ILA defines identifier groups as a convenient way to group identifiers together that have common characteristics. Identifier groups should reduce the number of operations needed T. Herbert Expires July 26, 2018 [Page 15] INTERNET DRAFT draft-herbert-ila-motivation on the mapping system. * A reference datapath implementation is supported in stock Linux since version 4.15. A userspace control path implementation will be open sourced. 3.3 Limitations and caveats of ILA This section describes limitations and caveats of ILA. * While ILA has much less overhead than encapsulation or extension headers, this does limit the amount of information that can be expressed. ILA is not extensible like some encapsulations so there is no means to associate ancillary information with ILA. * /64 address assignment is feasible in ILA, however requires a level of indirection in addressing. * ILA operates by transforming destination IP addresses in packets. Source addresses are not transformed. This works very well for unicast traffic, but creates some complexity for multicast in using the network layer multicast with ILA. * If the network generates an ICMP error for a packet whose destination contains a transformed address with a locator, the embedded packet in ICMP data contains a destination address with a locator. Before delivery to the original source host this address should be converted back to the original destination address. * Firewalls should filter addresses in packets before ILA translation. The typical scenario is that when a packet is forwarded to a network ingress point, the firewall inspects the packet before ILA is applied. An firewall internal to the network may see ILA addresses as destinations; this should be taken into account. * Logging and tools need to be adapted since they may be operating on ILA addresses. Logged addresses can be mapped to standard identifier representation either by a fixed mapping or by reverse mapping the address by a lookup in the mapping table. The latter would be needed in the case of non-local identifier addresses. 4 Use cases 4.1 Mobility networks T. Herbert Expires July 26, 2018 [Page 16] INTERNET DRAFT draft-herbert-ila-motivation 4.2 Datacenter virtualization 4.3 Network virtualization 5 References 5.1 Normative References 5.2 Informative References Author's Address Tom Herbert Quantonium Santa Clara, CA USA Email: tom@quantonium.net T. Herbert Expires July 26, 2018 [Page 17]