INTERNET DRAFT                                              M. Borella
Expires April 2000                                          3Com Corp.

                                                            October 1999



          Unique Identifiers for Network Objects and Subjects
                       <draft-borella-uid-00.txt>

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 <draft-ietf-nat-
      rsip-framework-02.txt>, 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]