Network Working Group D. Crocker Internet-Draft: Brandenburg InternetWorking draft-crocker-unique-assign-00.txt 13 June 2001 Expiration <12/01> Unique Assignment (Hierarchies) 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 Success of the Internet has relied on the combination of technical development, administrative assignment and operational interconnection. Internet administration and operations have never been simple, but until recently they were not controversial. The requirements for, or against, centralized administration were comfortably resolved within the Internet technical and operations communities. 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 the relevant areas of Internet administration. The evolution of this paper is independent of the IAB; this draft does not carry any IAB imprimatur. However it seeks IETF BCP status, to provide a clear statement by the technical community about the nature and support for these administrative and operational principals. To remain a global network, the Internet requires the existence of globally unique public assignment spaces, such as the DNS public name space and the IP public address space. The DNS name space is a hierarchy, deriving from a single, globally unique naming 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 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. By definition, competing assignment activities, for public- yet-independent assignment spaces, create multiple, overlapping assignment spaces. Put simply, deploying multiple, independent, public assignment processes creates the likelihood - in fact the long-term certainty - that 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 domain name 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. Until recently, Internet administrative operations were not controversial. The requirements for, or against, centralized administration were comfortably resolved within the Internet technical and operations communities. However growth of the Internet has brought a much wider range of participation in Internet technical and operations discussions, with an attendant increase in the range of administrative models being proposed. Some of these new 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 surreptitiously. 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 entirely 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 principals 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 provide approximately 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, because the subordinate nodes are 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 usually used to refer to the root node of the DNS. It often 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. It has sole authority over that assignment space. For administrative convenience, such as scaling a large administrative operation, an assignment authority might delegate portions of the assignment space, to be assigned by a subordinate agency; or assignment can be done by a single agency. With delegation, subordinate assignment agencies are acting on behalf of the assignment authority doing the delegation. A registry may delegate the "front-end" process of doing assignments to users (registrants) to registrars. Delegation of registration of sub-nodes, of course, defines an administrative hierarchy. It is common to have a hierarchy of administrative agencies organized to match an assignment hierarchy, such as successive portions of an IP address or contiguous nodes within a DNS tree. However this is not a requirement. It is also common to have an administrative agency make assignments for multiple levels in an assignment hierarchy. 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 and appropriate 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 independent management of assignment processes by, 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. This is only partial coordination. It cannot succeed, because the assignment authority being tracked is not participating in the coordination process. * It is guaranteed that the assignment authority being tracked will, eventually and inevitably, assign a value that the tracking authority already assigned. * It is essential to understand that the real problem is in this tracking model and not with the action of 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 Assignments are useless without a corresponding operational service. Such a 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. The DNS permits - in fact it requires - each node at every level of the DNS hierarchy to be replicated. DNS service for any replicated nodes is operated on separate hardware and software from any of its parent or children nodes. Again, correct operation requires that all nodes conform to the same operational rules. Mapping (Lookup) Vs. Searching The process of mapping a value - or looking it up - to obtain an associated set of information, is technically distinct from the process of searching that is performed in a directory service. * Mapping and searching functions differ both by the nature of their input and of 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 - 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 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 (i.e., set of DNS records) within that domain. This is as true for the administrative root domain as for any other DNS 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 make them different from all subordinate servers: 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 - 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.