Internet DRAFT - draft-borella-uid
draft-borella-uid
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]
