INTERNET DRAFT M. Borella Expires April 2000 3Com Corp. October 1999 Unique Identifiers for Network Objects and Subjects Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In this draft we discuss the attributes and characteristics of an Internet architecture based on assigning unique identifiers to all physical devices, users, services, and agents. A supporting location-finding mechanism is also defined. The advantages of such as architecture are presented. Please note: this discussion is still in the preliminary stages and should be considered as such. 1. Introduction In the past, an IPv4 address could be used, alone or in part, to identify a user, host, or service. These addresses are distributed in a roughly hierarchical fashion and loosely map to the physical topology of the Internet. With the proliferation of DHCP [RFC2131], firewalls, private addresses [RFC1918], and network address translators [RFC2663], Internet endpoints are not guaranteed to have Borella Expires April 2000 [Page 1] INTERNET-DRAFT Unique Identifiers October 1999 unique identifiers. However, UDP and TCP sessions are still bound to particular IP address / port 4-tuples (source IP address, destination IP address, source port, destination port). This binding is quite ingrained, as Mobile IP [RFC2002] has been developed so that a host can maintain the same IP address regardless of where it is in the physical topology. A Unique Identifier (UID) is a naming framework, independent of IP address, that uniquely identifies all subjects (users, agents, and services) and objects (physical hardware and hosts) in the Internet. Use of a UID allows the decoupling of subjects from the objects that they use, and the IP addresses and ports associated with these objects. By binding TCP and UDP sessions to UIDs, end-to-end communication no longer relies on IP addresses, and the IP addresses used for a session may change without disrupting the session. In this draft, we argue that through the use of UIDs, the architecture of the network will become more flexible and robust. We present the fundamental requirements of what UIDs must provide, how the layers of the protocol stack must change to accommodate UIDs, and the architectural implications of UIDs. Caveat: This draft discusses issues that would require a major change to the architecture of the Internet in order to be implemented. We are not suggesting that these changes actually be implemented in the short term; instead, we are offering a framework and model for thinking about and further discussion of the pros and cons of UIDs. Thus, we have kept many of the details of this draft at a high level. It is possible that the framework discussed here will have minor or major drawbacks or limitations that we have not discovered. This is a true "work in progress". 1.1. Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this document are to be interpreted as described in [RFC2119]. 1.2. Terminology Subject A user, application, agent or service that operates within a network. Object A physical device, or part of a physical device, on a network. Borella Expires April 2000 [Page 2] INTERNET-DRAFT Unique Identifiers October 1999 Socket The host-internal binding of an IP address / port 4-tuple (source IP address, destination IP address, source port, destination port) to a communications session. 2. Unique Identifiers A UID is a string of arbitrary symbols that identifies a network object or subject. UIDs may take on many possible forms, such as strings of letter, numbers, alphanumeric characters, or bits. However, for purposes of simplicity, we will consider all UIDs to be bitwise representations of symbols from a fixed space (fixed number of bits). The size of this space must be large enough so that it can uniquely address all subjects and objects that currently use a network, or that may use a network in the future. This requirement indicates that the number of UIDs in the space could conceivably be 2^(512), 2^(1024), or even more. UIDs MAY or MAY NOT imply a physical location. A UID may be assigned to a physical object, such as a workstation on a desk or a telephony device in a conference room. A UID may also be assigned to a subject, such as a user or a service. Examples of services that may be assigned UIDs are web servers, mail servers, configuration servers, location servers, custom stock market tracking agents, and so on. More than one UID may be assigned to an object or subject. Subjects may reside statically on particular objects, or may migrate from object to object. UIDs do not appear in packet headers. Routing and addressing is either that which is currently used with IPv4 and IPv6, or some other mechanism. UIDs only exist at the socket layer to bind communication sessions. IP addresses are still used to deliver packets to and from a host's interface. A main goal and advantage of UIDs is to de-couple Internet applications from their bindings to particular IP addresses and TCP/UDP port numbers. An object or subject with a UID may reside on a physical host that does not have a static IP address. However, when such a host is assigned a new IP address, via DHCP, RSIP, or some other mechanism, communication sessions with the host are not disrupted. Likewise, rather than limiting servers to be run on an appropriately well-known port number, servers may operate at any port number. Thus, multiple servers of the same type may run on a host Borella Expires April 2000 [Page 3] INTERNET-DRAFT Unique Identifiers October 1999 without explicitly notifying all clients of the non-standard port number(s) being used. 3. Location Servers With the use of UIDs, IP addresses no longer can be used to locate an object or subject. Thus, there is a need for location services that are dynamically updated with the current IP address(es) of where a UID can be located. The deployment of location servers may be roughly hierarchical. Global location servers serve the entire Internet. Local location servers serve one or more administrative domains. The data records in a location server map UIDs to IP addresses. The format of the IP addresses may be IPv4 or IPv6. If the location server does not know the IP address of a UID, the mapping may indicate the UID of another location server that may know the sought after IP address. By default, if a local location server does not have an IP address mapping for a UID, it must consider a global UID as the next server to query. 3.1. Messages In this section we define the messages that flow between clients and location servers, as well as between location servers. Arguments are denoted in parentheses. In all fields below, the PORT parameter is optional, and the port may only refer to a particular instance of a service. QUERY-REQ (UID) A lookup request for the IP address of the given UID. QUERY-ACK (UID, IP, PORT) A response to a QUERY message with the UID and its current IP address and port number. QUERY-NAK (UID) A response to a QUERY message indicating that the given UID cannot be located. QUERY-RED (UID, (UID, IP)) A response to a QUERY message indicating the UID/IP tuple of the next server that the client should contact. See section on Borella Expires April 2000 [Page 4] INTERNET-DRAFT Unique Identifiers October 1999 location server modes for details. REGISTER-REQ (UID, IP, PORT) A request to register a UID with an IP address and/or port. REGISTER-ACK (UID, IP, PORT) A response from a location server acknowledging the registration of a UID and its IP address and/or port. TIMEOUT (UID, IP, PORT) A message from a server either a client or other servers that the registration of a UID and an IP address and/or port has expired. 3.2. Registration Updating A client MUST periodically update its registration with its nearest location server. If a client's registration expires, the location server will transmit a TIMEOUT message to the client's last known IP address, and transmit a TIMEOUT to the next location server in the location server hierarchy. This functionality allows soft-state updating of a UID's IP address as the client may be mobile and roam away from a location server's administrative domain. 3.3. Modes Location servers may operate in either proxy or redirect modes with respect to handling queries for UIDs for which they do not know the IP address. A proxy mode location server forwards a query on behalf of a client to the next location server. If does not respond to the client until it receives a response from the next location server, or a timeout occurs. A redirect mode location server informs the client of the UID and/or IP address of the next location server. The difference between proxy and redirect mode is illustrated below. Proxy mode: Borella Expires April 2000 [Page 5] INTERNET-DRAFT Unique Identifiers October 1999 Client Server Next Server QUERY ---------------> QUERY -----------------> RESPONSE <----------------- RESPONSE <--------------- Redirect mode: Client Server Next Server QUERY ---------------> REDIRECT <--------------- QUERY ---------------------------------> RESPONSE <--------------------------------- Note that all clients MUST be able to operate in both proxy and redirect modes. Multiple levels of redirection and proxying may occur. 3.4. Applicability Redundancy, consistency and failover properties are required of any dynamic, distributed database, such as location servers. We do not address these issues in this draft. The existing DNS system may provide a framework for deploying location servers. 4. Address Independent API UID's reflect a new naming mechanism for network entities. This mechanism must be available to applications so that location clients and servers may be implemented on the application layer. Since either IPv4 or IPv6 applications may be used with UID-enabled networks, an address independent API MUST be developed. This API will be used by all applications for network communication. The basic requirements of this API are defined as follows: - Determine local UID Borella Expires April 2000 [Page 6] INTERNET-DRAFT Unique Identifiers October 1999 - Determine remote UID - Determine local IP address - Determine remote IP address - Map a UID to one or more IP addresses - Map an IP address to one or more UIDs - Establish a TCP connection between local and remote UIDs - Establish a UDP session between local and remote UIDs - Determine local port of a connection or session - Determine remote port of a connection or session - Terminate a connection or session - Send data on a connection or session - Receive data on a connection or session The details of the API are future work. 5. Anonymity The needs of a networked entity may include that of anonymity, in the sense that an entity in a communication session may not be able to determine the identity of its peer. To some extent, anonymity is provided in the data stream between two UIDs, since the UID's themselves never appear in the packet headers. However, UID's may appear in packet payloads, and may be stored at remote hosts. The UID framework include provisions for a greater degree of anonymity via an anonymizing proxy server. This type of proxy server acts as a "man in the middle" with respect to two endpoints. One endpoint (LocalUID) will register with the proxy such that it will communicate to its peer (RemoteUID) only via the proxy. The proxy will replace all instance of RemoteUID and its associated IP address(es) and port(s) with values chosen from a pool of "anonymized" UID's, IP addresses and ports, respectively. The following messages are identified for use between a client and an anonymizing proxy: ANON-REQ (LocalUID, RemoteUID) Borella Expires April 2000 [Page 7] INTERNET-DRAFT Unique Identifiers October 1999 A request for the proxy to perform anonymizing services on behalf of the entity at Local UID when this entity communicates with RemoteUID. Note that RemoteUID may be a wildcard indicating that LocalUID wishes to anonymously operate a public server. ANON-ACK (LocalUID, RemoteUID) Acknowledgement that the proxy will perform anonymizing services on behalf of LocalUID with respect to communication with RemoteUID. ANON-NAK (LocalUID, RemoteUID) Indication that the proxy will not perform anonymizing services on behalf of LocalUID with respect to communication with RemoteUID. Note that an anonymizer client does not necessarily know the anonymized UID that is being used by the proxy. Use of an proxy at this layer may prevent or limit the use of end-to- end encryption and authentication. 6. Assignment and Management of UIDs UIDs must be assigned by a centralized authority to guarantee that all UID's are indeed unique. This authority may delegate assignment responsibilities to local authorities by granting them groups of UIDs. Note that UID assignment need not be hierarchical, and no assumptions of hierarchy should necessarily be made from UIDs. Since a potentially enormous number of UIDs may be active at any one time, steps to reduce the impact of the active UID space must be taken. Global location servers must maintain a list of all active UIDs and mappings to the appropriate next location server. Use of hierarchical location servers will reduce the load on global location servers. As a UID roams, it may have to update its registration at one or more local location server, but as long as it remains on an administrative domain associated with a local location server, the global location servers do not need to know of the change. Local location servers may employ caching of recent query responses so that traffic to global and other local location servers is minimized. However, cache entries must have a relatively brief lifetime; i.e., less than that of the interval between UID registration updates. 7. Usability Borella Expires April 2000 [Page 8] INTERNET-DRAFT Unique Identifiers October 1999 Since UID spaces will be very large, it is not practical for human users to remember UIDs. Thus, UIDs SHOULD be hidden from users as much as possible. For example, UIDs of network services might be represented visually as "Company A's Web Site", "My Online Investment Account", or "Jane Smith's Telephone", each with appropriate icons. By clicking on these icons or otherwise selecting these names, the user is connected to the appropriate service. In order for this information to be available to the user in their local environment, services, hosts, users, and their associated UIDs must be advertised at public servers. For example, a search on the name "Jane Smith" at a server may return the following: "Jane Smith's Telephone", "Jane Smith's voicemail", "Jane Smith's web page", "Jane Smith's email", and so on. In general, there must be a method for the user, or some other subject such as a web browser, to locally cache UIDs of frequently used services and represent these to the user in an understandable fashion. 8. Advantages of UIDs We believe that apart from considerable architectural changes, the use of UIDs offers a number of advantages over the current Internet architecture. 8.1. Mobile IP is No Longer Necessary Since applications are not bound to particular IP addresses and ports, and sockets use UIDs rather than IP addresses, Mobile IP is no longer necessary. Mobility is implicitly supported by the UID and location server architecture. 8.2. DNS is No Longer Necessary Mapping UIDs to IP addresses and ports will be handled by the location server architecture. Mapping services to UIDs requires a richer language than is currently supported by DNS. A possible replacement could be based on search engine technology. The result of all this is that DNS is not necessary, and the fully- qualified domain name (FQDN) may be obsoleted. 8.3. Address Space Agnosticism The UID and location server architecture is orthogonal with respect to the address space used by objects and subjects. Thus, this space may be based on IPv4, IPv4 private space with NAT or RSIP gateways, or IPv6. As a result, the transition to IPv6 may Borella Expires April 2000 [Page 9] INTERNET-DRAFT Unique Identifiers October 1999 be facilitated. 8.4. Location Finding on NAT/RSIP Subnets One of the most relevant drawbacks to privately-addressed subnets that use NAT or RSIP for communication with the rest of the network, is that there is no flexible mechanism for contacting services behind a NAT or RSIP gateway. In particular, under the well-known port number schema, only one service of each type per IP address is permissible. Since the UID architecture does not use well-known ports, arbitrary services may exist at any ports at any IP address. Service can be located via location servers. 8.5. Extensibility The registration mechanism, in particular the REGISTER-REQ and REGISTER-ACK messages, can be extended to include arbitrary information. Thus, a wide variety of services may be built on top of these primitives. For example, by specifying a remote UID and a time of day and an interrupt preference, a user may instruct a location server that he wants to receive indication of voice calls from some users at certain times, but others are to be automatically forwarded to a voicemail service. 9. Security Considerations Authentication is a fundamental requirement of all messages that originate with or are destined to a location server. Such authentication may require the deployment of a global public key infrastructure (PKI) [RFC2510]. 10. Examples To be discussed. 11. References [RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de Groot, and E. Lear, "Address Allocation for Private Internets," RFC 1918, Feb. 1996. [RFC2002] C. Perkins, "IP Mobility Support," RFC 2002, Oct. 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Mar. 1997. [RFC2131] R. Droms, "Dynamic Host Configuration Protocol," RFC 2131, Mar. 1997. Borella Expires April 2000 [Page 10] INTERNET-DRAFT Unique Identifiers October 1999 [RFC2510] C. Adams and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols," RFC 2510, Mar. 1999. [RFC2663] P. Srisuresh and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations," RFC 2663, Aug. 1999. [RSIP-FRAME] M. Borella, J. Lo, D. Grabelsky, and G. Montenegro, "Realm Specific IP: Framework," Internet Draft , Oct. 1999 (work in progress). 12. Author's Address Michael Borella 3Com Corp. 1800 W. Central Rd. Mount Prospect IL 60056 (847) 342-6093 mike_borella@3com.com 13. Copyright Statement Copyright (c) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Borella Expires April 2000 [Page 11] INTERNET-DRAFT Unique Identifiers October 1999 Borella Expires April 2000 [Page 12]