Internet DRAFT - draft-crocker-unique-assign
draft-crocker-unique-assign
Network Working Group D. Crocker
Internet-Draft: Brandenburg InternetWorking
Expiration <1/02> 15 July 2001
Unique Assignment (Hierarchies)
draft-crocker-unique-assign-01.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.
COPYRIGHT NOTICE
Copyright (C) The Internet Society (2001). All Rights Reserved.
SUMMARY
The Internet relies on a combination of technical development,
administrative assignment and operational interconnection. This
paper evolves the Internet Architecture BoardÆs [RFC2826], which
focused on the technical requirement for a unique root to the DNS
administrative hierarchy. The current paper expands the scope of
the discussion, applying the requirements to relevant areas of
Internet administration. The paper seeks IETF BCP status, since it
describes basic requirements for the practise of Internet
administration.
The Internet requires the existence of globally unique public
assignment spaces, such as the DNS name space and the IP address
space. Each of these is designed as a hierarchy, deriving from a
single, globally unique assignment root. This is a technical
constraint inherent in the design of hierarchical assignment spaces.
Therefore it is not technically feasible to have more than one
assignment root in a single public assignment space. For real-time
mapping between an assignment and its associated values, an
operational mapping service is required. For scaling and
reliability the one assignment root of a hierarchy MUST have a
mapping service that is supported by a set of coordinated
operational servers, administered by that unique assignment
authority.
Competing assignment activities that offer public, yet independent,
assignment spaces introduce the likelihood of ambiguous reference.
By definition they create multiple, overlapping assignment spaces.
Hence in the long-term, users of different Internet service
providers will get different responses for the same assignment
value. Users who click on the same link on a web page will end up
at different destinations. Email senders specifying the same
destination address will have their mail delivered to different
systems. Users specifying the same, Internet-based telephone number
will call different stations. Because different providers will
refer to different servers of different administrative authorities,
they will resolve the same administrative string to different
values.
This does not preclude private networks from operating their own
private assignment spaces. However if they wish to make use of
assignments uniquely defined for the global Internet, they MUST
fetch that information from the associated global mapping service,
such as the global DNS naming hierarchy, and in particular from the
coordinated servers associated with that global DNS naming
hierarchy.
1. INTRODUCTION
Once an Internet technology is specified and developed, it must be
deployed and operated. Success of the Internet has relied on the
combination of technical development, administrative assignment and
operational interconnection. Just as Internet success frequently
relies on central coordination for the creation of interoperable
technologies, it frequently relies on central coordination for
deployment and operation of the interoperable services that use
those technologies.
However ôfrequentlyö does not mean ôalwaysö. Internet culture
strongly advocates competitive activities, which means activities
that are not centrally coordinated. This tension between
competition and cooperation has been resolved reasonably well for
the process of creating technical specifications.
Growth of the Internet has brought a wide range of participation in
Internet technical and operations discussions, with an attendant,
wide range of administrative models being proposed. Some of these
models directly contradict established Internet practise and even
contradict basic technical principals.
This paper describes technical requirements for centralized
administration that represent Internet Best Current Practise. It
distinguishes between scenarios that require such administration and
those that do not. It explores proposals that appear to violate
those requirements, and therefore either must fail or must find a
way to introduce centralization, albeit possibly indirectly. The
paper also distinguishes administration from operation, since they
are substantially independent phases of activity and can be subject
to very different styles.
This paper evolves [RFC2826], ôIAB Technical Comment on the Unique
DNS Rootö which focused on the top of the DNS administrative
hierarchy. The current paper is compatible with RFC 2826, and
incorporates the text from it, while expanding the scope of
discussion. It applies the principals behind RFC 2826 to the
general domain of Internet administration, and it seeks to clarify
some points in RFC 2826 that were misunderstood. It further seeks
IETF BCP status, to provide a clear statement from the technical
community about the nature and support for these administrative and
operational principals.
2. TERMINOLOGY AND SCOPE
Assignment and operation are separate, complementary activities.
* Assignment allocates (registers) a value from the assignment space,
giving usage rights to an assignee (registrant).
* Operation provides a service that maps between the assigned value
and some set of information.
* Unless otherwise noted, for any assignment space that is partitioned
into a hierarchy, the principles and constraints described at one
node in the hierarchy apply to every node of the hierarchy.
2.1 Assignment
Correct operation of Internet services requires coordinated
assignment of various values, such as protocol IDs, port numbers, IP
addresses and domain names. A purpose for coordination is to ensure
that values are not ambiguous. That is, values must be assigned
uniquely. If more than one assignment of a value is made, there is
no way to know which assignment to use at a particular time.
Assignment Space
Values are assigned out of a pre-defined range, or ôassignment
spaceö. Typically, the assignment space is determined by the size
and syntax of the assignment field. For example a 16-bit binary
field can provide up to 2**16 values, with some values such as the
lowest and highest often declared unusable.
For domain names, the range of values that can be assigned is called
a ôname spaceö. Because the Domain Names Service uses a tree-
structured hierarchy, the term domain name space can refer to a
particular node within the domain name hierarchy, or to the entire
hierarchy. In most discussions, the reference is to a particular
node, such as the root, with the subordinate nodes being implied.
The term ôzoneö is often used confusingly in public discussion of
the DNS. The term means the set of contiguous nodes of the DNS
hierarchy, supported by a single DNS server. Hence it is an
operational term, and has no meaning with respect to DNS name
assignment. However the term ôroot zoneö is often used to refer to
the root node of the DNS. This does not distinguish between
assignments of values for the root node, versus operation of a
server that uses the root node database.
Assignment Authority
An assignment authority (registry) administers an assignment space.
For administrative convenience an assignment authority might
delegate portions of the assignment space. With delegation,
subordinate assignment agencies are acting on behalf of the
assignment authority doing the delegation. A registry may delegate
to registrars the ôfront-endö process of doing assignments to users
(registrants).
Independent Assignment
Independent assignment efforts MUST use separate assignment spaces.
Separate means separate. It means that there is no linkage
whatsoever between the two (or more) independent processes and no
linkage between the set of values that are assigned by the
independent processes.
Hence it means that each is free û and likely û to assign the same
value.
* If it is guaranteed that assignment efforts for separate assignment
spaces will never assign the same value, then they are not independent
efforts and the assignment spaces are not separate. Some type of
coordination mechanism is operating ôaboveö both efforts, rendering them
logically one, with one logical assignment space.
It can be reasonable to have multiple, independent assignment
processes, when there is no likelihood that activities deriving from
the assignments will overlap. For example a private network that
does not have access to the public Internet can reasonably assign
whatever IP addresses it wishes. However experience has taught that
the likelihood of eventually connecting to the public Internet is
quite high. That is the reason that this otherwise benign
circumstance warranted reservation of special IP addresses, per
[RFC1918]. Hence there is experience that warrants questioning
whether legitimate independence at one point in time will be
maintained over the long term.
Assignment Tracking
A variation on complete independence is to have two, independent
assignment authorities, with one choosing a policy of tracking the
other, for a portion of the assignment space. The authority that
does the tracking is attempting to create a superset of the values
assigned by the other authority.
Because this is only partial coordination, it cannot succeed.
* It is guaranteed that the assignment authority being tracked will,
eventually, assign a value that the tracking authority already assigned.
* It is essential to understand that the source of the problem is in
this tracking model and not with actions by the authority being tracked.
The tracking authority unilaterally declared a relationship to the
tracked authority. That declaration represented an attempt to claim some
authority higher than the tracked authority, thereby attempting to
eliminate the original independence.
2.2 Operation
An operational service maps between the assignment value and
whatever other information is associated. For example, IP addresses
are used in different contexts. One service maps between IP address
and the name of the device to which the address is assigned.
Another maps between IP address and ôrouteö -- or, rather, it uses
an initial portion of the address, to determine which transmission
port to send a packet down. Domain names are principally mapped to
IP addresses.
For IP datagram transport, the mapping between IP address and route
is performed by a distributed routing service, with each IP router
making its own calculations and decisions. However, each shares its
information with its neighbors. The operational routing process is,
therefore, fully distributed. Each node is computationally
independent, but correct system behavior requires that all nodes
conform to the same rules. That is, the logical routing service is
administratively centralized by virtue of its using common,
standardized algorithms.
Replication
Replication is an operations activity. It means that an exact copy
of a database is maintained on a separate operating platform, and
typically by a separate operating service. Hence replication
permits independence of an access service operation, but not
independence of data assignment. This operational independence
improves overall service reliability and performance, without
creating any assignment space conflicts, resulting from
administrative independence. For reliability the DNS requires each
node at every level of the DNS hierarchy to be replicated.
Mapping (Lookup) Vs. Searching
The process of mapping a value û or looking it up û is technically
distinct from the process of searching that is performed in a
directory service.
* Mapping and searching differ in the nature of their input and their
output.
Mapping uses an entire, single assigned identifier value and obtains
the entry associated with that one value. If the value is not yet
assigned, a mapping operation will fail.
In contrast, a searching process takes some string or partial string
V possibly an identifier, but more typically a non-unique, naturally
occurring string, such as personal name û and returns the range of
information associated with the range of matching values.
Abbreviations
As a convenience to users, an operational system might permit
specification of an assigned value in abbreviated form. For example
it might permit users to refer to systems within the same
organization by omitting the trailing, common portion of the domain
name.
In the non-Internet world, the most common example of this type of
abbreviation is making a local telephone call, without including the
country code or area code. Such operational conveniences MUST NOT
be mistaken for differences in the assigned value. When dialing a
telephone that is not local, we know to include area code and, as
appropriate, the country code. When referring to a machine in
another domain, we know to include the complete domain name.
The difficulty with abbreviations is in having users distinguish
when they work correctly and when they do not (and with failing to
understand that the abbreviation is not the entire string.)
3. ASSIGNMENT FUNDAMENTALS
There are several distinct reasons why an administrative hierarchy
requires a single administrative authority. For the DNS this is
often referred to as the requirement for a single (administrative)
root.
3.1 Maintenance Of A Common Symbol Set
Effective communications between two parties requires two essential
preconditions:
* The existence of a common symbol set, and
* The existence of a common semantic interpretation of these symbols.
Failure to meet the first condition implies a failure to communicate
at all, while failure to meet the second implies that the meaning of
the communication is lost.
In the case of a public communications system this condition of a
common symbol set with a common semantic interpretation must be
further strengthened to that of a unique symbol set with a unique
semantic interpretation. This condition of uniqueness allows any
party to initiate a communication that can be received and
understood by any other party. Such a condition rules out the
ability to define a symbol within some bounded context. In such a
case, once the communication moves out of the context of
interpretation in which it was defined, the meaning of the symbol
becomes lost.
Within public digital communications networks, such as the Internet,
this requirement for a uniquely defined symbol set with a uniquely
defined meaning exists at many levels, commencing with the binary
encoding scheme, extending to packet headers and payload formats and
the protocol that an application uses to interact. In each case a
variation of the symbol set or a difference of interpretation of the
symbols being used within the interaction causes a protocol failure,
and the communication fails. The property of uniqueness allows a
symbol to be used unambiguously in any context, allowing the symbol
to be passed on, referred to, and reused, while still preserving the
meaning of the original use.
The DNS is an exemplar service that fulfills an essential role
within the Internet protocol environment, allowing network locations
to be referenced using a label other than a protocol address. As
with any other such symbol set, DNS names are designed to be
globally unique: For any one DNS name, at any one time, there must
be a single set of DNS records uniquely describing protocol
addresses, network resources and services associated with that DNS
name. All of the Internet applications that use the DNS assume
this, and Internet users expect such behavior from DNS names. Names
are then constant symbols, whose interpretation does not
specifically require knowledge of the context of any individual
party. A DNS name can be passed from one party to another without
altering the semantic intent of the name.
* Since the DNS is hierarchically structured into domains, the
uniqueness requirement for DNS names in their entirety implies that each
of the names (sub-domains) defined within a domain has a unique meaning
(that is, set of DNS records) within that domain.
* This is as true for any subordinate domains as it is for the
administrative root domain.
The requirement for uniqueness within a domain further implies that
there be some mechanism to prevent name conflicts within a domain.
In DNS this is accomplished by assigning a single owner or
maintainer to every domain, including the root domain, who is
responsible for ensuring that each sub-domain of that domain has the
proper records associated with it. This is a technical requirement,
not a policy choice.
3.2 Coordination Of Updates
Both the design and implementation of assignment hierarchies, such
as the DNS, assume that there is a single owner or maintainer at
each level of the hierarchy. For maintenance of the information
associated with an assigned value, such as the resources records
associated with a domain, the assumption is that modification is
performed in a single-copy serializable fashion.
Continuing the example with the DNS this means that, even assuming
that a single domain could somehow be "shared" among non-cooperating
parties, there is no means within the DNS protocol by which a user
or client could discover, and choose between, conflicting
definitions of a DNS name made by different parties. The client
will simply return the first set of resource records that it finds
that matches the requested domain, and assume that these are valid.
* This protocol is embedded in the operating software of hundreds of
millions of computer systems, and is not easily updated to support a
shared domain scenario.
* Discussions about easily changing client software are referring to a
change that selects a SINGLE, ALTERNATIVE AUTHORITY, rather than any sort
of shared arrangement.
Moreover, even supposing that some other means of resolving
conflicting definitions could be provided in the future, it would
have to be based on objective rules established in advance. For
example, zone A.B could declare that naming authority Y had been
delegated all subdomains of A.B with an odd number of characters,
and that naming authority Z had been delegated authority to define
subdomains of A.B with an even number of characters.
Thus, a single set of rules would have to be agreed upon, to prevent
Y and Z from making conflicting assignments, and with this train of
actions a single unique space has been created in any case. Hence
even this would not allow multiple non-cooperating authorities to
assign arbitrary sub-domains within a single domain.
* To repeat: A degree of cooperation and agreed technical rules are
required in order to guarantee the uniqueness of names.
In the DNS, these rules are established independently for each part
of the naming hierarchy, and the administrative root domain is no
exception. Thus, there must be a generally agreed single set of
rules for the root, as for each, subordinate node.
3.3 Difficulty Of Relocating An Operational Root Service
The top of an operational hierarchy, such as the DNS root servers,
has a bootstrapping requirement that makes it different from all
subordinate nodes: the addresses of the operational root servers
come from out-of-band information. This out-of-band information is
often poorly maintained and, unlike all other data in the DNS, the
out-of-band information has no automatic timeout or modification
mechanism.
* It is not uncommon for this information to be years out of date at
many sites around the Internet. Hence it is likely to take years to
revise this bootstrapping information.
Continuing the DNS example: Like any other zone, the root zone
contains a set of "name server" resource records listing its
servers, but a resolver with no valid addresses for the current set
of root servers will never be able to obtain these records. More
insidiously, a resolver that has a mixed set of partially valid and
partially stale out-of-band configuration information will not be
able to tell which are the "real" root servers if it gets back
conflicting answers.
* Thus, it is very difficult to revoke the status of a malicious
operational root server, or even to route around a buggy root server.
In effect, every full-service resolver in the world "delegates" the
root of the public tree to the public root server(s) of its choice.
As a direct consequence, any change to the list of IP addresses that
specifies the public root zone is significantly more difficult than
a change to any other aspect of the DNS delegation chain. Thus,
stability of the system calls for extremely conservative and
cautious management of the public root zone: the frequency of
updates to the root zone must be kept low, and the servers for the
root zone must be closely coordinated.
To some extent DNS Security Extensions [DNSSEC] can ameliorate these
problems, but a similar out-of-band configuration problem exists for
the cryptographic signature key to the root zone, so the root zone
still requires tight coupling and coordinated management even in the
presence of DNSSEC.
4. CENTRAL VS. DISTRIBUTED ADMINISTRATIVE CONTROL
Connectivity and routing in the Internet are accomplished through
highly distributed and independent efforts. There is no central
coordination for the administration of Internet connectivity. In
the early Internet, there was a centrally administered core
backbone. Creation of independent backbones has proved to be a
major enhancement to the Internet. In particular it created a
substantially more robust operational environment.
IP address and DNS assignment activities are markedly different,
with entirely centralized û albeit hierarchically delegated and
distributed û authority. It is tempting to look at the history of
distribution and independence, for Internet connectivity, and seek
to emulate that history, for address or name assignment. It could
then be claimed that multiple assignment activities, for the same
set of values, somehow would make the Internet more open, more
competitive or more robust.
The problem is with the difference in semantics. Multiple backbones
create multiple routes between locations. This creates robustness
in connectivity, not differences in the ômeaningö of that
connectivity. Follow any of the different paths and you still reach
the same destination.
* Having multiple assignment authorities û and therefore multiple
assignment spaces û does create different meaning. It creates ambiguity,
not robustness. The ambiguity occurs simply. Different mapping services
that are based on assignments by different authorities will produce
different answers for the same values.
It should also be noted that the benefits of the model allowing
multiple backbones comes at a considerable cost. Maintaining
proper, global routing is very substantially more difficult than
with a single, centralized routing administration model.
5. CONCLUSION
This paper has discussed administration of hierarchical spaces, used
in the Internet for infrastructure identification and mapping. Such
administrative spaces have significant technical limitations. For
example no amount of policy-making can change the requirement for a
single administrative authority over an assignment space, if the
values in that space are to be assigned uniquely.
Policy issues do abound, even for assignment spaces. For example
the choice and design of an administrative authority is more a
matter of policy than technology. However the requirement that
there be a single authority is purely technical.
The DNS type of unique naming and name-mapping system is designed
for a specific set of functions. Such a system may not be ideal for
a number of purposes for which it was never designed, such as
locating information when the user does not precisely know the
complete, correct name. As the Internet continues to expand,
searching-oriented directory systems are expected to evolve, to
assist the user in dealing with vague or ambiguous references.
* There is no getting away from the requirement for unique
administrative authority for the root of an administrative hierarchy, and
for each of its subordinate nodes.
* Independent operational servers that accurately replicate copies of
that authoritative data, can improve reliability, but have no effect on
assignment activities.
6. SECURITY CONSIDERATIONS
This memo does not introduce any new security issues, but it does
attempt to identify some of the problems inherent in a family of
recurring technically naive proposals.
7. IANA CONSIDERATIONS
This memo is not intended to create any new issues for IANA.
8. REFERENCES
[DNS-CONCEPTS] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, November 1987.
[DNS-IMPLEM] Mockapetris, P., "Domain Names û Implementation and
Specification", STD 13, RFC 1035, November 1987.
[DNSSEC] Eastlake, D., "Domain Name System Security
Extensions", RFC 2535, March 1999.
[RFC2826] IAB, ôIAB Technical Comment on the Unique DNS Rootö,
RFC 2826, May 2000
[RFC1918] Y. Rekhter, B. Moskowitz, D. Karrenberg, G. J. de
Groot, E. Lear.Address ôAllocation for Private
Internetsö, RFC1918, February 1996.
9. AUTHOR'S ADDRESS
Dave Crocker
Brandenburg InternetWorking
675 Spruce Drive
Sunnyvale, CA 94086 USA
+1.408.246.8253
dcrocker@brandenburg.com
10. FULL COPYRIGHT STATEMENT
Copyright (C) The Internet Society (2001). 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.
11. ACKNOWLEDGEMENTS
RFC 2826 was the result of a collective effort by the Internet
Architecture Board, responding to serious confusion in some public
discussion forums. RFC 2826 went a considerable distance towards
clarifying basic principals of technical administration for the DNS,
and served well to surface even more basic matters of community
misunderstanding about Internet administration and operation.
