Big Internet D. Hitchcock INTERNET-DRAFT U.S. DOE May 1993 Endpoint Identifiers: What do they do and why are they a good thing? Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be Updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract There has been an ongoing debate on the Big Internet list over the past year over whether abstracting the concept of Endpoint Identifier (EID) from the concept of address which has significance in the topology of the network. This draft attempts to summarize the arguments pro and con as well as some discussion of whether the EID should be in the network layer or elsewhere. This draft also contains a specific proposal for EID format with a discussion of the pros and cons of this choice. 1. Some Background The assignment of addresses in the internet follows a tree of Address Assignment Authorities. At the root of the tree is the top-level (or 0-level) AAA. This AAA assigns blocks of numbers to the next level down (1-level) AAA, which assigns blocks of numbers from the block it owns to 2-level AAAs and so on. If a traditional left-to-right bit- wise significant address is used, these blocks of numbers are low- order-bits- Big-Internet, Expires November 1, 1993 [Page 1] INTERNET-DRAFT EID's: Pro and Con April 1993 maskable binary numbers. Current internet technology is approaching the end of its useful life due to the expansion in the number of attached networks and hosts. These expansions have resulted in two problems, depletion of the assignable address space and explosion in the amount of information exchanged especially between the top level backbone service providers. There are a number of proposals currently under consideration to support the future growth of the internet: TUBA, SIP, IPAE, PIP, Nimrod,... as well as a near term proposal CIDR to help address these problems as well as some others. It is likely that some number of these technologies will need to coexist and interoperate for some period of years. All of these proposals must address the issue of how to assign these numbers so that 1) routing scales well, 2) good paths are found, 3) constraints on the physical topology are minimized, and 4) reconfiguration of systems is minimized. If one creates a graph where the vertical axis is scaling (bottom is perfect scaling in top is bad scaling) and the horizontal axis is path quality (left is perfect paths and right is bad paths), then the optimal operating point on the graph is the lower left corner. In general the "physics" of networking forces operating points on this graph to be at the upper left or lower right. Depending on the type of address assignment scheme used, however, it is possible to move somewhat towards the lower left (good solutions) or the upper right (bad solutions). Moving to the lower left, however, may increase topology constraints or reconfiguration requirements. Central to the evaluation of any address assignment scheme are answers to the questions 1) what constitutes good scaling, 2) what constitutes a good path, 3) what constitutes unacceptable or costly topology constraints, and 4) what constitutes unacceptable or costly reconfiguration. I suspect that the community has or will come to reasonable agreement on what the characteristics of each address assignment scheme are. Except for possibly the first question, I also suspect that the community will not agree on the answers to the questions, partly because the cost of each aspect is borne by different parties, and partly because we lack experience. In the current IP technology the IP number is both the identifier of a computer system and the carrier of the topological information the network uses to determine how to route information. 2. What is an Endpoint Identifier (EID)? For the purposes of this draft an EID is a fixed length string of defined structure which uniquely identifies a "network endpoint." EID's have the following properties: A single EID may have associated with it multiple network attachment Big-Internet, Expires November 1, 1993 [Page 2] INTERNET-DRAFT EID's: Pro and Con April 1993 points with multiple addresses. A single address can be associated with only one EID at any one time although the binding of addresses to EID's may change over time. EID's are assigned so that they are unique network wide. EID's differ from DNS names in that they are fixed length as well as in some other details... MX records, Cnames,... EID's are stable over time and are not created or destroyed too quickly. EID's are network layer objects in the sense that all transport and higher layer services on a given endpoint use the same EID. In order to make these definitions more specific we must define exactly what we mean by a "network endpoint." This is to some extent a choice of the most appropriate granularity for stable descriptions of network entities. The critical elements of the definition of an endpoint are the concept of fate-sharing developed by Chiappa and the concept of stability. In most cases a network endpoint is a single computer system. However, there are cases where a single system might have more than one EID especially for systems in a multilevel secure environment. 3. What problems do EID's address? Virtually all the proposals for IPv7 as well as the near term CIDR proposal will require significant portions of the internet community to modify their internet addresses, either the assignment, the format, or both. Furthermore, in the foreseeable future the topological information required by the network to reach a given destination will become more changeable rather than less changeable because: commercial providers will be very motivated to change the topology to achieve more balance utilization of their investment in connections. the sources and destinations of network traffic will themselves become mobile or changeable. The current IP addressing and routing technology does not provide easy answers to these problems. In fact the way IP host software is currently implemented implies that it is very difficult to accommodate these issues. The administrative problems of renumbering even a medium sized site using today's tools is formidable and requires at least rebooting every machine. One reason for these problems is that IPv4 uses the IP address both to Big-Internet, Expires November 1, 1993 [Page 3] INTERNET-DRAFT EID's: Pro and Con April 1993 route packets and to identify sources and destinations of packets. 4. The Case for and Against EID's The arguments for EIDs include: 1. System identification and location are qualitatively different functions and so should be separated architecturally. 2. EID's may facilitate mobile hosts. 3. EIDs may allow global changes in network topology without disrupting ongoing processes. 4. EID's may facilitate management of local sites in an environment where "addresses" need to be changed fairly frequently. The argument against EID's include: 1. Its an extra number space to manage. 2. The essential features of the EID are provided by the DNS name (since there is no need for EID's in every packet.) 3. EID's may not be the only way to provide mobility and portability of processes. Complicating this discussion is the fact that all of these different advantages and disadvantages have different levels of importance for various people. In my own view advantages 3 and 4 are very important but other people have different priorities. Also, to be clear about my biases, having a single network layer service EID that multiple higher layer processes could use seems much simpler and easier to manage than a multitude of higher level processes to perform the same functions on a process by process basis. 5. EIDs and DNS Names One issue which needs to be clarified is the realtionship between DNS names and EIDs. EIDs are fixed format identifiers which are suitable for inclusion in every packet; although this may not be required. EIDs do not support the logical constructs equivalent to CNAMEs and MX records in the DNS. One of the major applications which one would like to be robust when Big-Internet, Expires November 1, 1993 [Page 4] INTERNET-DRAFT EID's: Pro and Con April 1993 addressing topology changes is the DNS. While it is possible to imagine complex bootstrap procedures for the DNS to accomplish this if DNS names were used as EID's transforming the DNS search tree to refer to EIDs rather than addresses is likely to be a much simpler way of accomplishing this. 5. Proposed Experiment However, without real experience with EID's it is impossible to accurately evaluate any of this. Therefore, I would like to propose the following EID experiment. Choose an EID format which is the same as the current IPv4 and build an implementation which uses two copies of IPv4 one for routing and one for EID (one could even use the current IP address as EID and add a RD - routing directive - object which looks like IPv4 to minimize the impact on current software implementations). Assume EID assignment follows current DNS delegation procedure. Modify DNS so it can supply EID as well as "address" For all those old applications which use the DNS name and "address" replace "address" with EID Define EARP (EID ARP) which is same as plain old ARP but uses EID instead of "address." Some of the issues which would need to be addressed are how to propagate changes in EID-"address" binding in real time and maintain coherent view of the network. I propose that SNMP be used to build the right fragments to manage this. Note that once a router passes the EID to a layer 2 subnet the delivery of packets works just as it does in IP because of EARP. This testbed is, it seems to me, the minimal thing that one can do to evaluate how useful EIDs would be. In addition, it has the side benefit that if it were successful it could lead to an EID structure which would be directly useful in CIDR. Big-Internet, Expires November 1, 1993 [Page 5]