From b8b9e2bf5dd263f76458dbbdfbbc36a8c2315bc5 Mon Sep 17 00:00:00 2001 From: Andreas Gustafsson Date: Wed, 6 Mar 2002 19:08:34 +0000 Subject: [PATCH] updated drafts --- doc/draft/draft-hibbs-dns-server-mib-00.txt | 2092 ----------------- doc/draft/draft-hibbs-dns-server-mib-01.txt | 19 + ... => draft-ietf-dnsext-axfr-clarify-04.txt} | 35 +- ... draft-ietf-dnsext-obsolete-iquery-03.txt} | 56 +- ...> draft-ietf-dnsop-inaddr-required-03.txt} | 144 +- ...f-dnsop-v6-name-space-fragmentation-00.txt | 337 --- ...f-dnsop-v6-name-space-fragmentation-01.txt | 348 +++ ...xt => draft-ietf-enum-e164-gstn-np-03.txt} | 662 +++--- ...ey-01.txt => draft-schlyter-appkey-02.txt} | 294 +-- ...-00.txt => draft-schlyter-pkix-dns-01.txt} | 68 +- 10 files changed, 983 insertions(+), 3072 deletions(-) delete mode 100644 doc/draft/draft-hibbs-dns-server-mib-00.txt create mode 100644 doc/draft/draft-hibbs-dns-server-mib-01.txt rename doc/draft/{draft-ietf-dnsext-axfr-clarify-03.txt => draft-ietf-dnsext-axfr-clarify-04.txt} (91%) rename doc/draft/{draft-ietf-dnsext-obsolete-iquery-02.txt => draft-ietf-dnsext-obsolete-iquery-03.txt} (80%) rename doc/draft/{draft-ietf-dnsop-inaddr-required-02.txt => draft-ietf-dnsop-inaddr-required-03.txt} (81%) delete mode 100644 doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-00.txt create mode 100644 doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-01.txt rename doc/draft/{draft-ietf-enum-e164-gstn-np-02.txt => draft-ietf-enum-e164-gstn-np-03.txt} (83%) rename doc/draft/{draft-schlyter-appkey-01.txt => draft-schlyter-appkey-02.txt} (54%) rename doc/draft/{draft-schlyter-pkix-dns-00.txt => draft-schlyter-pkix-dns-01.txt} (80%) diff --git a/doc/draft/draft-hibbs-dns-server-mib-00.txt b/doc/draft/draft-hibbs-dns-server-mib-00.txt deleted file mode 100644 index 46a8347b92..0000000000 --- a/doc/draft/draft-hibbs-dns-server-mib-00.txt +++ /dev/null @@ -1,2092 +0,0 @@ - - DNS Extensions Working Group R.B. Hibbs - INTERNET-DRAFT Nominum, Inc. - Category: Experimental - November 2001 - - - - Domain Name System (DNS) Server MIB - - - - - - Saved Monday, November 12, 2001, 2:52 PM - - - - 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/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html - - - Copyright Notice - - Copyright (C) 2001, The Internet Society. All Rights Reserved. - - Abstract - - This memo defines an experimental portion of the Management - Information Base (MIB) for use with network management protocols in - the Internet Community. In particular, it defines objects used for - the management of Domain Name System (DNS) servers, and reserves an - experimental branch in the MIB-2 tree for DNS servers and resolvers. - - This version (the "-00" draft) is the initial draft of an intended - replacement for RFC1611 which was changed to Historic status in - October, 2001, and is intended to generate discussion and comment on - the desirability and usefulness of a DNS server MIB. - - - - Hibbs Expires: Nov 2001 + 6 months [Page 1] - Internet Draft DNS Server MIB November 2001 - - Table of Contents - - 1. Introduction 2 - 2. The SNMP Network Management Framework 3 - 3. DNS Overview 4 - 3.1. Name Servers 4 - 3.2. Resolvers 5 - 4. Structure of this MIB 5 - 4.1. Server Identification Group 6 - 4.2. Server Configuration Group 6 - 4.3. Server Basic Counters Group 6 - 4.4. Server Optional Counters Group 6 - 4.5. Server Optional Statistics Group 6 - 4.6. Server Zone Group 6 - 5. Textual Conventions 6 - 6. Relationship to Other MIBs 7 - 6.1. DNS Resolver MIB 8 - 6.2. Host System MIB 8 - 7. Definitions 8 - 8. Intellectual Property 30 - 9. Notes 30 - 9.1. Issues 31 - 9.1.1. DNS vs. SNMP Names 31 - 9.1.2. Use of DNS Names as Indices 31 - 9.1.3. Binary Labels and Internationalized Domain Names 31 - 9.1.4. Zone Update Methods Other Than Zone Transfer 31 - 9.1.5. Basis for Counters and Statistics 31 - 9.1.6. Simplicity vs. Completeness 32 - 9.2. Changes from Prior Drafts 32 - 10. Acknowledgements 32 - 11. Security Considerations 32 - 12. References 33 - 13. Editors' Addresses 35 - 14. Full Copyright Statement 35 - - - - 1. Introduction - - This memo was produced by the DNS Extensions Working Group and - defines a portion of the Management Information Base (MIB) for use - with network management protocols in the Internet community. In - particular, it describes a set of MIB extensions that instrument - Domain Name servers. - - With the adoption of the Internet-standard Network Management - Framework [RFC1155, RFC1156, RFC1157, RFC1212], and with a large - number of vendor implementations of these standards in commercially - available products, it became possible to provide a higher level of - effective network management in TCP/IP-based internets than was - previously available. With the growth in the use of these standards, - it has become possible to consider the management of other elements - of the infrastructure beyond the basic TCP/IP protocols. A key - element of the TCP/IP infrastructure is the DNS. - - Hibbs Expires: Nov 2001 + 6 months [Page 2] - Internet Draft DNS Server MIB November 2001 - - This memo obsoletes [RFC1611], which has been moved to Historic - status by consensus of the DNS Extensions Working Group. - - This memo is based on the Internet-standard Network Management - Framework as defined by documents [RFC1902, RFC1903, and RFC1904]. - - Objects defined in this MIB allow access to DNS server software for - reporting of a basic set of counters, optional statistics, and - controls associated with the counters and statistics. Servers MAY - also provide additional management capabilities through the use of - the Applications MIB [RFC2287]. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in document [RFC2119]. - - - 2. The SNMP Network Management Framework - - The SNMP Management Framework presently consists of five major - components: - - o An overall architecture, described in [RFC2571]. - - o Mechanisms for describing and naming objects and events for the - purpose of management. The first version of this Structure of - Management Information (SMI) is called SMIv1 and described in - [RFC1155], [RFC1212] and [RFC1215]. The second version, called - SMIv2, is described in [RFC2578], [RFC2579] and [RFC2580]. - This MIB is based upon the use of SMIv2 for describing objects. - - o Message protocols for transferring management information. The - first version of the SNMP message protocol is called SNMPv1 and - described in [RFC1157]. A second version of the SNMP message - protocol, which is not an Internet standards track protocol, is - called SNMPv2c and described in [RFC1901] and [RFC1906]. The - third version of the message protocol is called SNMPv3 and - described in [RFC1906], [RFC2572] and [RFC2574]. This MIB is - intended ONLY for use with SNMPv3. - - o Protocol operations and associated PDU formats for accessing - management information are described in [RFC1157] and - [RFC1905]. - - o A set of fundamental applications described in [RFC2573] and - the view-based access control mechanism described in [RFC2575]. - - A more detailed introduction to the current SNMP Management Framework - can be found in [RFC2570]. - - Managed objects are accessed via a virtual information store, termed - the Management Information Base or MIB. Objects in the MIB are - defined using the mechanisms defined in the SMI. STD 17, [RFC 1213] - defines MIB-II, the core set of managed objects for the Internet - suite of protocols. - Hibbs Expires: Nov 2001 + 6 months [Page 3] - Internet Draft DNS Server MIB November 2001 - - This memo specifies a MIB module that is compliant to the SMIv2. A - MIB conforming to the SMIv1 can be produced through the appropriate - translations. The resulting translated MIB must be semantically - equivalent, except where objects or events are omitted because no - translation is possible (use of Counter64). Some machine-readable - information in SMIv2 will be converted into textual descriptions in - SMIv1 during the translation process. However, this loss of machine- - readable information is not considered to change the semantics of the - MIB. - - - 3. DNS Overview - - The Domain Name Service is provided by two kinds of entities: - resolvers and name servers. Resolvers ask questions while name - servers answer them. - - Implementors have made widely differing choices about how to divide - DNS functions between resolvers and servers, including a number of - hybrids. Other implementation considerations are the trade-offs - between speed, size, and functionality. The most difficult task in - creating this MIB was to define managed objects that did not - interfere with implementation decisions. - - The various DNS functions have been divided into two non-overlapping - classes, called "resolver functions" and "name server functions." A - DNS entity that performs what we define as resolver functions must - implement the MIB groups required of all resolvers that are defined - in a separate MIB Module. A DNS entity which implements name server - functions must implement the MIB groups required for name servers in - this module. If the same piece of software performs both resolver - and server functions, we imagine that it contains both a resolver and - a server and would thus implement both the DNS Server and DNS - Resolver MIBs. - - - 3.1. Name Servers - - In this model, a name server is a program that provides resource - records to resolvers. All references in this document to "a name - server" imply "the name server's role"; in some cases the name - server's role and the resolver's role might be combined into a single - program. A name server receives DNS protocol queries and sends DNS - protocol replies. A name server neither sends queries nor receives - replies. As a consequence, name servers do not have caches. - Normally, a name server would expect to receive only those queries to - which it could respond with authoritative information. However, if a - name server receives a query that it cannot respond to with purely - authoritative information, it may choose to try to obtain the - necessary additional information from a resolver which may or may not - be a separate process. - - - - - Hibbs Expires: Nov 2001 + 6 months [Page 4] - Internet Draft DNS Server MIB November 2001 - - 3.2. Resolvers - - A resolver is a program that obtains resource records from servers. - Normally it does so at the behest of an application, but may also do - so as part of its own operation. A resolver sends DNS protocol - queries and receives DNS protocol replies. A resolver neither - receives queries nor sends replies. A full service resolver is one - that knows how to resolve queries: it obtains the needed resource - records by contacting a server authoritative for the records desired. - A stub resolver does not know how to resolve queries: it sends all - queries to a local name server, setting the "recursion desired" flag - to indicate that it hopes that the name server will be willing to - resolve the query. A resolver may (optionally) have a cache for - remembering previously acquired resource records. It may also have a - negative cache for remembering names or data that have been - determined not to exist. - - - 4. Structure of this MIB - - In the tradition of the Simple Network Management Protocol (SNMP) the - minimum number of objects possible are defined in this MIB, while - still providing as rich a set of management information as possible. - An object is left out of this MIB when it can be easily derived from - other objects that are provided. Further to the tradition of the - SNMP, computationally intense operations are left to the domain of - the management station. Thus, this MIB provides a set of objects - from which other management information may be derived. - - Many of the objects included in this memo have been created from - information contained in the DNS specifications [RFC1034, RFC1035], - as amended and clarified by subsequent host requirements documents - [RFC1123]. Other objects have been created based on experience with - existing DNS management tools, expected operational needs, the - statistics generated by existing DNS implementations, and the - configuration files used by existing DNS implementations. These - objects have been ordered into groups as follows: - - o Server Identification Group - - o Server Configuration Group - - o Server Basic Counters Group - - o Server Optional Counters Group - - o Server Optional Statistics Group - - o Server Zone Group - - This information has been converted into a standard form using the - SNMPv2 SMI defined in [RFC2578]. For the most part, the descriptions - are influenced by the DNS related RFCs noted above. For example, the - descriptions for counters used for the various types of queries of - - Hibbs Expires: Nov 2001 + 6 months [Page 5] - Internet Draft DNS Server MIB November 2001 - - DNS records are influenced by the definitions used for the various - record types found in [RFC1035]. - - - 4.1. Server Identification Group - - The server identification group contains objects that describe and - identify the server and its current operating status. - - - 4.2. Server Configuration Group - - The server configuration group contains objects that report - fundamental server configuration information such as whether - recursion is enabled. - - - 4.3. Server Basic Counters Group - - The server basic counters group contains objects that count things - implied by [RFC1035], such as authoritative answers and errors. - - - 4.4. Server Optional Counters Group - - The server optional counters group currently has no objects defined. - - - 4.5. Server Optional Statistics Group - - The server optional statistics group primarily contains statistics - about messages received, specifically inter-arrival times useful in - traffic engineering and server load calculations. - - - 4.6. Server Zone Group - - The server zone group contains objects that report detailed - information about the configuration of each zone, but does not give - access to resource records. - - - 5. Textual Conventions - - Several conceptual data types have been introduced as textual - conventions in this DNS MIB document. These additions will - facilitate the common understanding of information used by the DNS. - No changes to the SMI or the SNMP are necessary to support these - conventions. - - Readers familiar with MIBs designed to manage entities in the lower - layers of the Internet protocol suite may be surprised at the number - of non-enumerated integers used in this MIB to represent values such - as DNS RR class and type numbers. The reason for this choice is - simple: the DNS itself is designed as an extensible protocol, - Hibbs Expires: Nov 2001 + 6 months [Page 6] - Internet Draft DNS Server MIB November 2001 - - allowing new classes and types of resource records to be added to the - protocol without recoding the core DNS software. Using non- - enumerated integers to represent these data types in this MIB allows - the MIB to accommodate these changes as well. - - DnsName - - This data type is used to represent the various names recorded in DNS - Resource Records - - DnsNameAsIndex - - This textual convention is like a DnsName, but is used as an index - component in tables. This data type requires a new definition to be - compatible with [RFC2xxx] and [draft-ieft-idn-zzz-nn] to support - internationalized domain names. - - DnsOpCode - - This textual convention is used to represent the DNS OPCODE values - used in the header section of DNS messages. - - DnsQueryClass - - This data type is used to represent the Qclass values which appear in - Resource Records in the DNS. - - DnsQueryType - - This data type is used to represent the Qtype values which appear in - DNS Resource Records. - - DnsResponseCode - - This data type is used to represent the DNS RCODE value in DNS - response messages. - - DnsTime - - This data type measures time in seconds. - - DnsTimeInterval - - This data type measures time in milliseconds. - - - 6. Relationship to Other MIBs - - MIBs, even experimental ones such as defined in this memo, do not - stand alone, but rely on the existence and behavior of other MIBs for - definitions and management of objects not defined in the MIB. - - - - - Hibbs Expires: Nov 2001 + 6 months [Page 7] - Internet Draft DNS Server MIB November 2001 - - 6.1. DNS Resolver MIB - - The DNS Resolver MIB will join its sibling, the DNS Server MIB, in - the "dns" branch of the standard MIB-2 tree, as illustrated by the - following diagram: - - - +-------+ - | MIB-2 | - +---+---+ - | - | - +---+---+ - | dns | - +---+---+ - | - | - +------------+------------+ - | | - +-------+--------+ +--------+-------+ - | dnsServerMIB | | dnsResolverMIB | - +----------------+ +----------------+ - - - The two MIBs will share a common branching point, but are - independently defined. - - - 6.2. Host System MIB - - The Host System MIB [RFC1123] provides for information, command, and - control of the host computer system on which a DNS server resides. - The DNS Server MIB specifically does not include any objects that may - be accessible using the Host System MIB. - - - 7. Definitions - - - -- definitions for a DNS (Domain Name System) server - - DNS-SERVER-MIB DEFINITIONS ::= BEGIN - - IMPORTS - mib-2 - FROM RFC-1213 - - Counter64, Counter32, Gauge32, Unsigned32, mib-2, MODULE-IDENTITY, - OBJECT-TYPE, OBJECT-IDENTITY, IpAddress - FROM SNMPv2-SMI - - TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue, - DateAndTime - FROM SNMPv2-TC - - Hibbs Expires: Nov 2001 + 6 months [Page 8] - Internet Draft DNS Server MIB November 2001 - - MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP - FROM SNMPv2-CONF; - - dns OBJECT-IDENTITY - STATUS current - DESCRIPTION - "The dns branch in the standard network management framework." - ::= { mib-2 32 } -- IANA will make official assignment - - dnsServerMIB MODULE-IDENTITY - LAST-UPDATED "2001-11-12 14:52:11" - ORGANIZATION "Richard Barr Hibbs, P.E." - CONTACT-INFO - " Barr Hibbs - Nominum, Inc. - 950 Charter Street - Redwood City, California 94063 - Phone: +1-(415)-648-3920 - Fax: +1-(415)-648-9017 - E-mail: Barr.Hibbs@Nominum.com" - - - DESCRIPTION - "The DNS branch in the standard management framework consists - of two parts: the DNS server and the DNS resolver. This is - the branch point for distinguishing the two parts." - ::= { dns 1 } - - dnsServerMIBObjects OBJECT-IDENTITY - STATUS current - DESCRIPTION - "The MIB module for entities implementing the server side - of the Domain Name System (DNS) protocol. This MIB does not - include support for Dynamic DNS (DDNS)." - ::= { dnsServerMIB 1 } - - - - -- Textual conventions defined by this memo - - DnsQueryClass ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2d" - STATUS current - DESCRIPTION - "This data type is used to represent the class values that - appear in DNS Resource Records. A 16-bit unsigned integer is - used to allow room for new classes of records to be defined. - Existing standard classes are listed in the DNS - specifications." - REFERENCE - "RFC1035 section 3.2.4." - SYNTAX INTEGER (0..65535) - - DnsName ::= TEXTUAL-CONVENTION - -- A DISPLAY-HINT would be nice, but difficult to express. - Hibbs Expires: Nov 2001 + 6 months [Page 9] - Internet Draft DNS Server MIB November 2001 - - STATUS current - DESCRIPTION - "A DNS name is a sequence of labels. When DNS names are - displayed, the boundaries between labels are typically - indicated by dots (e.g., 'Acme' and 'COM' are labels in the - name 'Acme. COM'). In the DNS protocol, however, no such - separators are needed because each label is encoded as a length - octet followed by the indicated number of octets of label. - - For example, 'Acme.COM' is encoded as the octet sequence: { 4, - 'A', 'c', 'm', 'e', 3, 'C', 'O', 'M', 0 } where the final 0 is - the length of the name of the root domain, which appears - implicitly at the end of any DNS name. This MIB uses the same - encoding as the DNS protocol. Each label that comprises a DNS - name is restricted to 63 octets, and the entire DNS name - restricted to 255 octets. A DNS name may be composed of an - arbitrary number of labels, as long as it fits within the - maximum overall length. - - A DNS name is not restricted to alphabetic, numeric, and a - limited set of special characters as might be inferred from the - example above. Names may be stored in any character coding - appropriate for the use, subject only to the length - restrictions. - - A DnsName must always be a fully qualified name. It is an - error to encode a relative domain name as a DnsName without - first making it a fully qualified name." - REFERENCE - "RFC-1034 section 3.1." - SYNTAX OCTET STRING (SIZE (0..255)) - - DnsNameAsIndex ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "This textual convention is like a DnsName, but is used as an - index componant in tables. Alphabetic characters in names of - this type are restricted to uppercase: the characters 'a' - through 'z' are mapped to the characters 'A' through 'Z'. This - restriction is intended to make the lexical ordering imposed by - SNMP useful when applied to DNS names. - - Note that it is theoretically possible for a valid DNS name to - exceed the allowed length of an SNMP object identifer, and thus - be impossible to represent in tables in this MIB that are - indexed by DNS name. Sampling of DNS names in current use on - the Internet suggests that this limit does not yet pose a - serious problem in practice, but requires further study. - - This convention is no longer appropriate, given the support for - binary labels and internationalized domain names. This - definition MUST be updated to be in conformance with current - status of DNS names." - REFERENCE - "RFC-1034 section 3.1, RFC-1448 section 4.1; RFC-2673." - Hibbs Expires: Nov 2001 + 6 months [Page 10] - Internet Draft DNS Server MIB November 2001 - - SYNTAX DnsName - - DnsOpCode ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "This textual convention is used to represent the DNS OPCODE - values used in the header section of DNS messages. Existing - standard OPCODE values are listed in the DNS specifications." - REFERENCE - "RFC1035 section 4.1.1." - SYNTAX INTEGER (0..15) - - DnsQueryClass ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2d" - STATUS current - DESCRIPTION - "This data type is used to represent the Qclass values which - appear in Resource Records in the DNS. A 16-bit unsigned - integer is used to allow room for new Qclass records to be - defined. Existing standard Qclasses are listed in the DNS - specification." - REFERENCE - "RFC1035 section 3.2.5." - SYNTAX INTEGER (0..65535) - - DnsQueryType ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2d" - STATUS current - DESCRIPTION - "This data type is used to represent the Qtype values which - appear in DNS Resource Records. A 16-bit unsigned integer is - used to allow room for new Qtype records to be defined. - Existing standard Qtypes are listed in the DNS specification." - REFERENCE - "RFC1035 section 3.2.3." - SYNTAX INTEGER (0..65535) - - DnsResponseCode ::= TEXTUAL-CONVENTION - STATUS current - DESCRIPTION - "This data type is used to represent the DNS RCODE value in DNS - response messages. Existing standard RCODE values are listed - in the DNS specifications." - REFERENCE - "RFC1035 section 4.1.1." - SYNTAX INTEGER (0..15) - - DnsTime ::= TEXTUAL-CONVENTION - DISPLAY-HINT "5d" - STATUS current - DESCRIPTION - "DnsTime values are 32-bit unsigned integers that measure time - in seconds." - REFERENCE - "RFC-1035." - Hibbs Expires: Nov 2001 + 6 months [Page 11] - Internet Draft DNS Server MIB November 2001 - - SYNTAX Unsigned32 - - DnsTimeInterval ::= TEXTUAL-CONVENTION - DISPLAY-HINT "2d.3d" - STATUS current - DESCRIPTION - "DnsTimeInterval values are 32-bit unsigned integers that - measures time in milliseconds. If the host system does not - support millisecond clock resolution, this value is computed - from the closest available resolution." - SYNTAX Unsigned32 - - - - -- (Old-style) groups in the DNS server MIB. - - dnsServerIdentification OBJECT IDENTIFIER - ::= { dnsServerMibObjects 1 } - dnsServerConfiguration OBJECT IDENTIFIER - ::= { dnsServerMibObjects 2 } - dnsServerCounters OBJECT IDENTIFIER - ::= { dnsServerMibObjects 3 } - dnsServerOptCounters OBJECT IDENTIFIER - ::= { dnsServerMibObjects 4 } - dnsServerOptStats OBJECT IDENTIFIER - ::= { dnsServerMibObjects 5 } - dnsServerZone OBJECT IDENTIFIER - ::= { dnsServerMibObjects 6 } - - - dnsServerIdentification OBJECT-IDENTITY - STATUS current - DESCRIPTION - "Group of objects that are related to the overall system." - ::= { dnsServerMIBObjects 1 } - - dnsServerConfiguration OBJECT-IDENTITY - STATUS current - DESCRIPTION - Group of objects that report server configuration." - ::= { dnsServerMIBObjects 2 } - - dnsBasicCounters OBJECT-IDENTITY - STATUS current - DESCRIPTION - "Group of objects that count various DNS events." - ::= { dnsServerMIBObjects 3 } - - dnsOptionalCounters OBJECT-IDENTITY - STATUS current - DESCRIPTION - "Group of objects that count various DNS events." - ::= { dnsServerMIBObjects 4 } - - dnsStatsistics OBJECT-IDENTITY - Hibbs Expires: Nov 2001 + 6 months [Page 12] - Internet Draft DNS Server MIB November 2001 - - STATUS current - DESCRIPTION - "Group of objects that measure various DNS statistics." - ::= { dnsServerMIBObjects 5 } - - dnsZones OBJECT-IDENTITY - STATUS current - DESCRIPTION - "Group of objects that report server zone information." - ::= { dnsServerMIBObjects 6 } - - - - -- serverIdentification Group - - dnsServerIdentificationDescription OBJECT-TYPE - SYNTAX DisplayString (SIZE (0..255)) - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "A textual description of the server. This value should - include the full name and version identification of the server. - This string MUST contain only printable NVT ASCII characters." - ::= { dnsServerIdentification 1 } - - dnsServerIdentificationObjectID OBJECT-TYPE - SYNTAX OBJECT IDENTIFIER - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The vendor's authoritative identification of the network - management subsystem contained in this entity. This value is - allocated within the SMI enterprise subtree (1.3.6.1.4.1) and - provides an easy and unambiguous means for determining what - kind of server is being managed. For example, if vendor - 'VeryBigServers, Inc.' is assigned the subtree - 1.3.6.1.4.1.4242, it may assign the identifier - 1.3.6.1.4.1.4242.1.1 to its 'Nomenclator' DNS server." - ::= { dnsServerIdentification 2 } - - dnsServerIdentificationUpTime OBJECT-TYPE - SYNTAX DnsTimeInterval - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "If the server has a persistent state (e.g., a process), this - value will be the time elapsed since it started. For software - without persistant state, this value will be zero." - ::= { dnsServerIdentification 3 } - - dnsServerIdentificationOperatingState OBJECT-TYPE - SYNTAX INTEGER { - other(1), - initializing(2), - running(4) - Hibbs Expires: Nov 2001 + 6 months [Page 13] - Internet Draft DNS Server MIB November 2001 - - } - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Status object to report the persistant name server state, - returning one of the following values: - other(1) - server in some unknown state; - initializing(2) - server (re)initializing; - running(4) - server currently running." - ::= { dnsServerIdentification 4 } - - - - -- Server Configuration Group - - dnsServerConfigurationRecursion OBJECT-TYPE - SYNTAX INTEGER { - available(1), - restricted(2), - unavailable(4) - } - MAX-ACCESS read-write - STATUS current - DESCRIPTION - "This represents the recursion services offered by this name - server. The values of this object are: - available(1) - performs recursion on requests from - clients. - restricted(2) - recursion is performed on requests only - from certain clients, for example; clients on an - access control list. - unavailable(4) - recursion is not available." - ::= { dnsServerConfiguration 1 } - - - - -- Server Basic Counters Group - - -- Authoritative Answer Counters - - dnsServerCountersAuthoritativeAnswers OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries which were authoritatively answered." - REFERENCE - "RFC1035 section 4.1.1. Corresponds to responses with RCODE - value 0 and the AA bit set." - ::= { dnsServerCounters 1 } - - dnsServerCountersAuthoritativeNoNames OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - Hibbs Expires: Nov 2001 + 6 months [Page 14] - Internet Draft DNS Server MIB November 2001 - - DESCRIPTION - "Number of queries for which 'authoritative no such name' - responses were made." - REFERENCE - "RFC1035 section 4.1.1. Corresponds to responses with RCODE - value 3 and the AA bit set." - ::= { dnsServerCounters 2 } - - dnsServerCountersAuthNoDataResps OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries for which 'authoritative no such data' - (empty answer) responses were made." - REFERENCE - "RFC1035 section 4.1.1. Corresponds to RCODE 0 with ANCOUNT - and ARCOUNT both 0, and the AA bit set." - ::= { dnsServerCounters 3 } - - - -- Non-Authoritative Answer Counters - - dnsServerCountersNonAuthAnswers OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries which were non-authoritatively answered - (cached data)." - REFERENCE - "RFC1035 section 4.1.1. Corresponds to replies with RCODE 0 - and the AA bit NOT set." - ::= { dnsServerCounters 5 } - - dnsServerCountersNonAuthNoData OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of queries which were non-authoritatively answered with - no data (empty answer)." - REFERENCE - "RFC1035 section 4.1.1. Corresponds to RCODE 0 with ANCOUNT - and ARCOUNT both 0, and the AA bit NOT set." - ::= { dnsServerCounters 6 } - - dnsServerCountersReferrals OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests that were referred to other servers." - ::= { dnsServerCounters 7 } - - Hibbs Expires: Nov 2001 + 6 months [Page 15] - Internet Draft DNS Server MIB November 2001 - - - -- Error Counters - - dnsServerCountersFormatErrors OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed that were answered - with RCODE value 1." - REFERENCE - "RFC1035 section 4.1.1." - ::= { dnsServerCounters 9 } - - dnsServerCountersServerFailures OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed that were answered - with RCODE value 2." - REFERENCE - "RFC1035 section 4.1.1." - ::= { dnsServerCounters 10 } - - dnsServerCountersNotImplemented OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests the server has processed that were answered - with RCODE value 4." - REFERENCE - "RFC1035 section 4.1.1." - ::= { dnsServerCounters 11 } - - dnsServerCountersRequestsRefused OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of DNS requests refused by the server." - REFERENCE - "RFC1035 section 4.1.1. Corresponds to responses with RCODE - value 5." - ::= { dnsServerCounters 12 } - - - -- DNS Server Counters Table - - dnsServerOpCodeCountersTable OBJECT-TYPE - SYNTAX SEQUENCE OF dnsServerOpCodeCountersEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - Hibbs Expires: Nov 2001 + 6 months [Page 16] - Internet Draft DNS Server MIB November 2001 - - "Counters of queries received by DNS OPCODE value. This table - should contain one row for each OPCODE value, but may be - configured, using some unspecified external mechanism, to - contain only rows of interest to the server administrator, plus - one row (with a zero index value) corresponding to 'all other - OPCODES.'" - ::= { dnsServerCounters 15 } - - dnsServerQClassCountersTable OBJECT-TYPE - SYNTAX SEQUENCE OF dnsServerQClassCountersEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Counters of queries received by DNS class. This table - contains one row for every class to be counted as configured by - the server administrator using some unspecified external - mechanism. - - For example, the administrator may only with to count queries - for a few specific classes. In this case, the table would - contain one row for each class to be counted, plus one row - (with zero index value) for 'all other classes.'" - ::= { dnsServerCounters 16 } - - dnsServerQtypeCountersTable OBJECT-TYPE - SYNTAX SEQUENCE OF dnsServerQTypeCountersEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Counters of queries received by DNS RR type. This table - contains one row for every RR type to be counted as configured - by the server administrator using some unspecified external - mechanism. - - For example, the administrator may only wish to count queries - for A and PTR records, plus 'Any.' In this case the table - would contain only three rows. In the context of this MIB, a - value of zero for RR type means 'all other RR types.'" - ::= { dnsServerCounters 17 } - - dnsServerTransportCountersTable OBJECT-TYPE - SYNTAX SEQUENCE OF dnsServerTransportCountersEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Counters of queries received by DNS transport protocol." - ::= { dnsServerCounters 18 } - - dnsServerOpCodeCountersEntry OBJECT-TYPE - SYNTAX DnsServerOpCodedCountersEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "" - INDEX { dnsServerCountersOpCode } - Hibbs Expires: Nov 2001 + 6 months [Page 17] - Internet Draft DNS Server MIB November 2001 - - ::= { dnsServerCountersTable 1 } - - dnsServerQClassCountersEntry OBJECT-TYPE - SYNTAX DnsServerQClassCountersEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "" - INDEX { dnsServerCountersQueryClass } - ::= { dnsServerCountersTable 2 } - - dnsServeQTypeCountersEntry OBJECT-TYPE - SYNTAX DnsServerQTypeCountersEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "" - INDEX { dnsServerCountersQueryType } - ::= { dnsServerCountersTable 3 } - - dnsServerTransportCountersEntry OBJECT-TYPE - SYNTAX DnsServerTransportCountersEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "" - INDEX { dnsServerCountersTransport } - ::= { dnsServerCountersTable 4 } - - DnsServerOpCodeCountersEntry ::= - SEQUENCE { - DnsServerCountersOpCode DnsOpCode, - DnsServerCountersOpCodeRequests Counter32, - } - - DnsServerQClassCountersEntry ::= - SEQUENCE { - DnsServerCountersQueryClass DnsQueryClass, - DnsServerCountersQClassRequests Counter32, - } - - DnsServerQTypeCountersEntry ::= - SEQUENCE { - DnsServerCountersQueryType DnsQueryType, - DnsServerCountersQTypeRequests Counter32, - } - - DnsServerTransportCountersEntry ::= - SEQUENCE { - DnsServerCountersTransport INTEGER, - DnsServerCountersTransportRequests Counter32, - } - - dnsServerCountersOpCode OBJECT-TYPE - SYNTAX DnsOpCode - Hibbs Expires: Nov 2001 + 6 months [Page 18] - Internet Draft DNS Server MIB November 2001 - - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The DNS OPCODE being counted in this row of the table." - ::= { dnsServerOpCodeCountersEntry 1 } - - dnsServerCountersopCodeRequests OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests (queries) that have been recorded in this - row of the table." - ::= { dnsServerOpCodeCountersEntry 2 } - - dnsServerCountersQueryClass OBJECT-TYPE - SYNTAX DnsQueryClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The class of record being counted in this row of the table." - ::= { dnsServerQClassCountersEntry 1 } - - dnsServerCountersQClassRequests OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests (queries) that have been recorded in this - row of the table." - ::= { dnsServerQClassCountersEntry 2 } - - dnsServerCountersQueryType OBJECT-TYPE - SYNTAX DnsQueryType - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "The type of record which is being counted in this row in the - table." - ::= { dnsServerQTypeCountersEntry 1 } - - dnsServerCountersQTypeRequests OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests (queries) that have been recorded in this - row of the table." - ::= { dnsServerQTypeCountersEntry 2 } - - dnsServerCountersTransport OBJECT-TYPE - SYNTAX INTEGER { - udp(1), - tcp(2), - other(4) - Hibbs Expires: Nov 2001 + 6 months [Page 19] - Internet Draft DNS Server MIB November 2001 - - } - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "A value of udp(1) indicates that the queries reported on this - row were sent using UDP. - - A value of tcp(2) indicates that the queries reported on this - row were sent using TCP. - - A value of other(3) indicates that the queries reported on this - row were sent using a transport that was neither TCP nor UDP." - ::= { dnsServerTransportCountersEntry 1 } - - dnsServerCountersTransportRequests OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Number of requests (queries) that have been recorded in this - row of the table." - ::= { dnsServerTransportCountersEntry 2 } - - - - -- Server Optional Counters Group - - -- [None defined at this time] - - - - -- dnsStatsistics group - - dnsStatsMinArrivalInterval OBJECT-TYPE - SYNTAX DnsTimeInterval - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The minimum amount of time between receiving two DNS messages. - A message is received at the server when the server is able to - begin processing the message. This typically occurs - immediately after the message is read into server memory. If - no messages have been received, then this object contains a - zero value." - ::= { dnsStatsistics 1 } - - dnsStatsMaxArrivalInterval OBJECT-TYPE - SYNTAX DnsTimeInterval - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The maximum amount of time between receiving two DNS messages. - A message is received at the server when the server is able to - begin processing the message. This typically occurs - immediately after the message is read into server memory. If - Hibbs Expires: Nov 2001 + 6 months [Page 20] - Internet Draft DNS Server MIB November 2001 - - no messages have been received, then this object contains a - zero value." - ::= { dnsStatsistics 2 } - - dnsStatsSumArrivalTime OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The sum of the DNS packet inter-arrival times in milli- - seconds. This value may be used to compute the arithmetic mean - of the DNS arrival times." - ::= { dnsStatsistics 3 } - - dnsStatsSumSquaresArrivalTime OBJECT-TYPE - SYNTAX Counter64 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "The sum of the squared DNS packet inter-arrival times in - micro-seconds. This value may be used to compute the variance - and standard deviation of the DNS arrival times. Note that a - micro-second resolution of this object requires a clock - resolution to the milli-second since the square of a milli- - second value produces a value with micro-second resolution." - ::= { dnsStatsistics 4 } - - - - -- Server Zone Group - - -- DNS Management Zone Configuration Table - - -- This table contains zone configuration information. - - dnsServerZoneTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsServZoneEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "Table of zones for which this name server provides - information. Each of the zones may be loaded from stable - storage via an implementation-specific mechanism or may be - obtained from another name server via a zone transfer. - - If name server doesn't load any zones, this table is empty." - ::= { dnsServerZone 1 } - - dnsServerZoneEntry OBJECT-TYPE - SYNTAX DnsServZoneEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry in the name server zone table. New rows may be added - either via SNMP or by the name server itself." - Hibbs Expires: Nov 2001 + 6 months [Page 21] - Internet Draft DNS Server MIB November 2001 - - INDEX { - dnsServerZoneName, - dnsServerZoneClass - } - ::= { dnsServerZoneTable 1 } - - DnsServerZoneEntry ::= - SEQUENCE { - DnsServerZoneName DnsNameAsIndex, - DnsServerZoneClass DnsQueryClass, - DnsServerZoneLastReloadSuccess DnsTime, - DnsServerZoneLastReloadAttempt DnsTime, - DnsServerZoneLastSourceAttempt IpAddress, - DnsServerZoneStatus RowStatus, - dnsServerZoneSerial Counter32, - dnsServerZoneCurrent TruthValue, - dnsServerZoneLastSourceSuccess IpAddress - } - - dnsServerZoneName OBJECT-TYPE - SYNTAX DnsNameAsIndex - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS name of the zone described by this row of the table. This - is the owner name of the SOA RR that defines the top of the - zone. This is name is in uppercase: characters 'a' through 'z' - are mapped to 'A' through 'Z' in order to make the lexical - ordering useful. - - This definition is obsolete and must be replaced to accommodate - binary labels and internationalized domain names." - ::= { dnsServerZoneEntry 1 } - - dnsServerZoneClass OBJECT-TYPE - SYNTAX DnsQueryClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS class of the RRs in this zone." - ::= { dnsServerZoneEntry 2 } - - dnsServerZoneLastReloadSuccess OBJECT-TYPE - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Elapsed time in seconds since last successful reload of this - zone. - - This definition requires update to account for new update - methods." - ::= { dnsServerZoneEntry 3 } - - dnsServerZoneLastReloadAttempt OBJECT-TYPE - Hibbs Expires: Nov 2001 + 6 months [Page 22] - Internet Draft DNS Server MIB November 2001 - - SYNTAX DnsTime - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Elapsed time in seconds since last attempted reload of this - zone. - - This definition requires update to account for new update - methods." - ::= { dnsServerZoneEntry 4 } - - dnsServerZoneLastSourceAttempt OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "IP address of host from which most recent zone transfer of - this zone was attempted. This value should match the value of - dnsServerZoneSourceSuccess if the attempt was succcessful. If - zone transfer has not been attempted within the memory of this - name server, this value should be 0.0.0.0." - - This definition requires update to account for new update - methods." - ::= { dnsServerZoneEntry 5 } - - dnsServerZoneStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of the information represented in this row of the - table." - ::= { dnsServerZoneEntry 6 } - - dnsServerZoneSerial OBJECT-TYPE - SYNTAX Counter32 - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Zone serial number (from the SOA RR) of the zone represented - by this row of the table. If the zone has not been - successfully loaded within the memory of this name server, the - value of this variable is zero." - ::= { dnsServerZoneEntry 7 } - - dnsServerZoneCurrent OBJECT-TYPE - SYNTAX TruthValue - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "Whether the server's copy of the zone represented by this row - of the table is currently valid. If the zone has never been - successfully loaded or has expired since it was last - succesfully loaded, this variable will have the value false(2), - Hibbs Expires: Nov 2001 + 6 months [Page 23] - Internet Draft DNS Server MIB November 2001 - - otherwise this variable will have the value true(1)." - ::= { dnsServerZoneEntry 8 } - - dnsServerZoneLastSourceSuccess OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS read-only - STATUS current - DESCRIPTION - "IP address of host which was the source of the most recent - successful zone transfer for this zone. If unknown (e.g., zone - has never been successfully transfered) or irrelevant (e.g., - zone was loaded from stable storage), this value should be - 0.0.0.0." - ::= { dnsServerZoneEntry 9 } - - - -- DNS Zone Source Table - - dnsServerZoneSourceTable OBJECT-TYPE - SYNTAX SEQUENCE OF DnsServZoneSourceEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "This table is a list of IP addresses from which the server - will attempt to load zone information using DNS zone transfer - operations. A reload may occur due to SNMP operations that - create a row in dnsServerZoneTable or a SET to object - dnsServerZoneReload. This table is only used when the zone is - loaded via zone transfer." - ::= { dnsServerZone 2 } - - dnsServerZoneSourceEntry OBJECT-TYPE - SYNTAX DnsServZoneSourceEntry - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "An entry in the name server zone source table." - INDEX { - dnsServerZoneSourceName, - dnsServerZoneSourceClass, - dnsServerZoneSourceAddr - } - ::= { dnsServerZoneSourceTable 1 } - - DnsServZoneSourceEntry ::= - SEQUENCE { - DnsServerZoneSourceName DnsNameAsIndex, - DnsServerZoneSourceClass DnsQueryClass, - DnsServerZoneSourceAddr IpAddress, - DnsServerZoneSourceStatus RowStatus - } - - dnsServerZoneSourceName OBJECT-TYPE - SYNTAX DnsNameAsIndex - MAX-ACCESS not-accessible - Hibbs Expires: Nov 2001 + 6 months [Page 24] - Internet Draft DNS Server MIB November 2001 - - STATUS current - DESCRIPTION - "DNS name of the zone to which this entry applies." - ::= { dnsServerZoneSourceEntry 1 } - - dnsServerZoneSourceClass OBJECT-TYPE - SYNTAX DnsQueryClass - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "DNS class of zone to which this entry applies." - ::= { dnsServerZoneSourceEntry 2 } - - dnsServerZoneSourceAddr OBJECT-TYPE - SYNTAX IpAddress - MAX-ACCESS not-accessible - STATUS current - DESCRIPTION - "IP address of name server host from which this zone might be - obtainable." - ::= { dnsServerZoneSourceEntry 3 } - - dnsServerZoneSourceStatus OBJECT-TYPE - SYNTAX RowStatus - MAX-ACCESS read-create - STATUS current - DESCRIPTION - "The status of the information represented in this row of the - table." - ::= { dnsServerZoneSourceEntry 4 } - - - - -- SNMPv2 groups. - - dnsServerMibGroups OBJECT IDENTIFIER - ::= { dnsServerMib 2 } - - dnsServerIdentificationGroup OBJECT-GROUP - OBJECTS { - dnsServerIdentificationIdentifier, - dnsServerIdentificationUpTime, - dnsServerIdentificationResetTime, - dnsServerIdentificationOperatingState - } - STATUS current - DESCRIPTION - "A collection of objects providing identification of a DNS name - server." - ::= { dnsServerMibGroups 1 } - - dnsServerConfigurationGroup OBJECT-GROUP - OBJECTS { - dnsServerConfigurationRecursion - } - Hibbs Expires: Nov 2001 + 6 months [Page 25] - Internet Draft DNS Server MIB November 2001 - - STATUS current - DESCRIPTION - "A collection of objects providing basic configuration of a DNS - name server." - ::= { dnsServerMibGroups 2 } - - dnsServerCountersGroup OBJECT-GROUP - OBJECTS { - dnsServerCountersAuthoritativeAnswers , - dnsServerCountersAuthoritativeNoNames, - dnsServerCountersAuthNoDataResps, - dnsServerCountersNonAuthAnswers, - dnsServerCountersNonAuthNoData, - dnsServerCountersReferrals, - dnsServerCountersFormatErrors, - dnsServerCountersServerFailures, - dnsServerCountersNotImplemented, - dnsServerCountersRequestsRefused, - dnsServerCountersReqUnparses, - dnsServerCountersOtherErrors, - dnsServerCountersOpCode, - dnsServerCountersQueryClass, - dnsServerCountersQueryType, - dnsServerCountersTransport, - dnsServerCountersRequests, - dnsServerCountersResponses - } - STATUS current - DESCRIPTION - "A collection of objects providing basic instrumentation of a - DNS name server." - ::= { dnsServerMibGroups 3 } - - dnsServerOptCountersGroup OBJECT-GROUP - OBJECTS { - } - STATUS current - DESCRIPTION - "A collection of objects providing extended instrumentation of - a DNS name server." - ::= { dnsServerMibGroups 4 } - - dnsServerStatisticsGroup OBJECT-GROUP - OBJECTS { - } - STATUS current - DESCRIPTION - "A collection of objects providing extended instrumentation of - a DNS name server." - ::= { dnsServerMibGroups 5 } - - dnsServerZoneGroup OBJECT-GROUP - OBJECTS { - dnsServerZoneName, - dnsServerZoneClass, - Hibbs Expires: Nov 2001 + 6 months [Page 26] - Internet Draft DNS Server MIB November 2001 - - dnsServerZoneLastReloadSuccess, - dnsServerZoneLastReloadAttempt, - dnsServerZoneLastSourceAttempt, - dnsServerZoneLastSourceSuccess, - dnsServerZoneStatus, - dnsServerZoneSerial, - dnsServerZoneCurrent, - dnsServerZoneSourceName, - dnsServerZoneSourceClass, - dnsServerZoneSourceAddr, - dnsServerZoneSourceStatus - } - STATUS current - DESCRIPTION - "A collection of objects providing configuration control of a - DNS name server which loads authoritative zones." - ::= { dnsServerMibGroups 6 } - - - - -- serverNotifyObjects: Objects which are used only in - notifications - - -- [no new objects defined in this MIB] - - - -- Notifications - - serverServerStart NOTIFICATION-TYPE - OBJECTS { serverNotifyServer } - STATUS current - DESCRIPTION - "This notification signifies that the server of the specified - type has started on the host from which this notification has - been sent." - ::= { dnsServerMIBNotifications 3 } - - serverServerStop NOTIFICATION-TYPE - OBJECTS { serverNotifyServer } - STATUS current - DESCRIPTION - "This notification signifies that the server of the specified - type has stopped normally on the host from which this - notification has been sent." - ::= { dnsServerMIBNotifications 4 } - - - - -- Compliances. - - dnsServerMibCompliances OBJECT IDENTIFIER - ::= { dnsServerMib 3 } - - dnsServerMibCompliance MODULE-COMPLIANCE - STATUS current - Hibbs Expires: Nov 2001 + 6 months [Page 27] - Internet Draft DNS Server MIB November 2001 - - DESCRIPTION - "The compliance statement for agents implementing the DNS name - server MIB extensions." - MODULE -- This MIB module - MANDATORY-GROUPS { - dnsServerIdentificationGroup, - dnsServerConfigurationGroup, - dnsServerCountersGroup - } - - GROUP dnsServerOptCountersGroup - DESCRIPTION - "The server optional counter group is unconditionally - optional." - - GROUP dnsServerStatisticsGroup - DESCRIPTION - "The server statistics group is unconditionally optional." - - GROUP dnsServerZoneGroup - DESCRIPTION - "The server zone group is mandatory for any name server that - acts as an authoritative server for any DNS zone." - - - - -- Conformance - - dnsServerMIBConformance OBJECT-IDENTITY - STATUS current - DESCRIPTION - "DNS Server MIB objects are all defined in this branch." - ::= { dnsServerMIB 3 } - - dnsServerMIBCompliances OBJECT IDENTIFIER - ::= { dnsServerMIBConformance 1 } - - dnsServerMIBGroups OBJECT IDENTIFIER - ::= { dnsServerMIBConformance 2 } - - - -- Compliance groups - - dnsServerMIBCompliance MODULE-COMPLIANCE - MODULE -- this module - MANDATORY-GROUPS { - serverIdentificationGroup, - dnsBasicCountersGroup, - dnsOptionalCountersGroup, - dnsStatsisticsGroup, - serverConfigurationGroup - } - STATUS current - DESCRIPTION - "Describes the requirements for conformance to the DNS Server - Hibbs Expires: Nov 2001 + 6 months [Page 28] - Internet Draft DNS Server MIB November 2001 - - MIB." - ::= { dnsServerMIBCompliances 1 } - - dnsBasicCountersGroup OBJECT-GROUP - OBJECTS { - } - STATUS current - DESCRIPTION - "Objects belonging to the dnsBasicCountersGroup." - ::= { dnsServerMIBGroups 3 } - - dnsOptionalCountersGroup OBJECT-GROUP - OBJECTS { - } - STATUS current - DESCRIPTION - "Objects belonging to the dnsOptionalCountersGroup." - ::= { dnsServerMIBGroups 3 } - - dnsStatisticsGroup OBJECT-GROUP - OBJECTS { - dnsStatsMinArrivalInterval, - dnsStatsMaxArrivalInterval, - dnsStatsSumArrivalTime, - dnsStatsSumSquaresArrivalTime - } - STATUS current - DESCRIPTION - "Objects belonging to the dnsStatisticsGroup." - ::= { dnsServerMIBGroups 5 } - - serverZoneGroup OBJECT-GROUP - OBJECTS { - dnsServerZoneName, - dnsServerZoneClass, - dnsServerZoneLastReloadSuccess, - dnsServerZoneLastReloadAttempt, - dnsServerZoneLastSourceAttempt, - dnsServerZoneLastSourceSuccess, - dnsServerZoneStatus, - dnsServerZoneSerial, - dnsServerZoneCurrent, - dnsServerZoneSourceName, - dnsServerZoneSourceClass, - dnsServerZoneSourceAddr, - dnsServerZoneSourceStatus - } - STATUS current - DESCRIPTION - "Objects belonging to the serverConfigurationGroup." - ::= { dnsServerMIBGroups 6 } - - serverNotifyObjectsGroup OBJECT-GROUP - OBJECTS { - serverNotifyServer - Hibbs Expires: Nov 2001 + 6 months [Page 29] - Internet Draft DNS Server MIB November 2001 - - } - STATUS current - DESCRIPTION - "DNS Server MIB objects used in notifications." - ::= { dnsServerMIBGroups 7 } - - serverNotificationsGroup NOTIFICATION-GROUP - NOTIFICATIONS { - serverServerStart, - serverServerStop, - serverDNSQueueTooBig - } - STATUS current - DESCRIPTION - "Notifications which are implemented by the DNS Server agent." - ::= { dnsServerMIBGroups 8 } - - END - - - - 8. Intellectual Property - - The IETF takes no position regarding the validity or scope of any - intellectual property or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; neither does it represent that it - has made any effort to identify any such rights. Information on the - IETF's procedures with respect to rights in standards-track and - standards-related documentation can be found in BCP-11. - - Copies of claims of rights made available for publication and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF Secretariat. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to practice - this standard. Please address the information to the IETF Executive - Director. - - - 9. Notes - - This section will be removed when this memo is published as an RFC. - - - - - - - - Hibbs Expires: Nov 2001 + 6 months [Page 30] - Internet Draft DNS Server MIB November 2001 - - 9.1. Issues - - - 9.1.1. DNS vs. SNMP Names - - Note that it is theoretically possible for a valid DNS name to exceed - the allowed length of an SNMP object identifer, and thus be - impossible to represent in tables in this MIB that are indexed by DNS - name. Sampling of DNS names in current use on the Internet suggests - that this limit does not yet pose a serious problem in practice, but - requires further study. - - - 9.1.2. Use of DNS Names as Indices - - When [RFC1611] was written, DNS names were restricted to be the NVT- - ASCII characters "A" through "Z," "0" through "9," the dot (".") and - dash ("-") characters. Today, DNS names are no longer restricted to - this limited character set, but may be any value that can be - expressed by octets. As a result of this and the work underway by - the Internationalized Domain Names Working Group of the IETF, the - simple case folding and limited character set imposed by the original - definition of the textual convention DnsNameAsIndex is no longer - valid. A more appropriate definition of this index will require - further study. - - - 9.1.3. Binary Labels and Internationalized Domain Names - - The convention used in [RFC1611] for DNS names also conflicts with - the common assumption used in MIBs that many objects are defined as - NVT-ASCII, which is also no longer appropriate given the support for - binary labels and internationalized domain names. This is an item - for further study. - - - 9.1.4. Zone Update Methods Other Than Zone Transfer - - Incremental zone transfers [RFC1995] and dynamic DNS updating - [RFC2136] and [RFC3007] introduce new methods for updating zone data - that were not envisioned at the time that [RFC1611] was written. - Several object definitions may require modification to account for - these additions. - - - 9.1.5. Basis for Counters and Statistics - - The basic counters correspond to specific categories of errors, - responses, and messages as described in RFC1034 and RFC1035. In all - cases the document sections underlying an object are given in the - REFERENCE of each object definition, where such sections exist. - Statistics were generally created from the desire to be able to - characterize the traffic patterns presented to a server and to - provide more detailed performance monitoring tools than simple - counters can provide. - Hibbs Expires: Nov 2001 + 6 months [Page 31] - Internet Draft DNS Server MIB November 2001 - - The editors specifically did not survey all available DNS management - tools to determine the statistics and optional counters included in - the MIB. - - - 9.1.6. Simplicity vs. Completeness - - A DNS server in many cases must be capable of very high performance. - In these cases a DNS server MIB should include the least number of - objects necessary to monitor the server. In other cases DNS - administrators may be more concerned with management and control than - performance, wishing for a rich server MIB to provide them as much - information as possible. Designing a MIB to meet these quite - opposite goals is a bit of a challenge: hopefully the editors have - struck a workable balance by defining a basic set of counters and - configuration objects, with a rich set of optional objects. - - - 9.2. Changes from Prior Drafts - - [none û initial version of the draft] - - - 10. Acknowledgements - - This document is the result of work undertaken the by DNS Extensions - working group. The editors would like to particularly acknowledge - the efforts of the editors of [RFC1611], Rob Austein and Jon Saperia, - who created the original DNS Server MIB. - - - 11. Security Considerations - - There are a number of management objects defined in this MIB that - have a MAX-ACCESS clause of read-write and/or read-create. Such - objects may be considered sensitive or vulnerable in some - environments. The support for SET operations in a non-secure - environment without proper protection can have a negative effect on - network operations. - - SNMPv1 by itself is not a secure environment. Even if the network - itself is secure (for example by using IPSEC), even then, there is no - control as to who on the secure network is allowed to access and - GET/SET (read/change/create/delete) the objects in this MIB. - - It is recommended that the implementers consider the security - features as provided by the SNMPv3 framework. Specifically, the use - of the User-based Security Model [RFC2274] and the View-based Access - Control Model [RFC2275] is recommended. - - It is then a customer/user responsibility to ensure that the SNMP - entity giving access to an instance of this MIB, is properly - configured to give access to the objects only to those principals - (users) that have legitimate rights to indeed GET or SET - (change/create/delete) them. - Hibbs Expires: Nov 2001 + 6 months [Page 32] - Internet Draft DNS Server MIB November 2001 - - 12. References - - [DEN] Directory Enabled Networks Working Group, - http://www.universe.digex.net/~murchiso/den. - - [ISO8824] International Organization for Standardization, - "Information processing systems - Open Systems Interconnection -- - Specification of Abstract Syntax Notation One (ASN.1)," - International Standard 8824, December 1987. - - [RFC1034] Mockapetris, P., "Domain Names -- Concepts and Facilities", - STD 13, RFC 1034, USC/Information Sciences Institute, November - 1987. - - [RFC1035] Mockapetris, P., "Domain Names -- Implementation and - Specification," STD 13, RFC 1035, USC/Information Sciences - Institute, November 1987. - - [RFC1123] Braden, R., Editor, "Requirements for Internet Hosts -- - Application and Support, STD 3, RFC 1123, USC/Information Sciences - Institute, October 1989. - - [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification - of Management Information for TCP/IP-based internets", STD 16, RFC - 1155, Performance Systems International, Hughes LAN Systems, May - 1990. - - [RFC1156] McCloghrie, K., and M. Rose, "Management Information Base - for Network Management of TCP/IP-based internets", RFC 1156, May - 1990. - - [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple - Network Management Protocol", STD 15, RFC 1157, May 1990. - - [RFC1212] Rose, M., and K. McCloghrie, Editors, "Concise MIB - Definitions", STD 16, RFC 1212, March 1991. - - [RFC1213] McCloghrie, K., and M. Rose, "Management Information Base - for Network Management of TCP/IP-based internets: MIB-II", STD - 17, RFC 1213, March 1991. - - [RFC1215] Rose, M. T., "Convention for defining traps for use with - the SNMP," RFC 1215, March 1991. - - [RFC1445] Galvin, J., and K. McCloghrie, "Administrative Model for - version 2 of the Simple Network Management Protocol (SNMPv2)", RFC - 1445, April 1993. - - [RFC1448] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, - "Protocol Operations for version 2 of the Simple Network - Management Protocol (SNMPv2)", RFC 1448, April 1993. - - [RFC1611] Austein, R. and Saperia, J., ôDNS Server MIB Extensions,ö - RFC 1611, May 1994. - - Hibbs Expires: Nov 2001 + 6 months [Page 33] - Internet Draft DNS Server MIB November 2001 - - [RFC1612] Austein, R. and Saperia, J., "DNS Resolver MIB Extensions," - RFC 1612, May 1994 - - [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, - "Introduction to Community-based SNMPv2," RFC 1901, January 1996. - - [RFC1904] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, - "Conformance Statements for Version 2 of the Simple Network - Management Protocol (SNMPv2)," RFC 1904, January 1996. - - [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, - Protocol Operations for Version 2 of the Simple Network Management - Protocol (SNMPv2)," January 1996. - - [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, - "Transport Mappings for Version 2 of the Simple Network Management - Protocol (SNMPv2)," RFC 1906, January 1996. - - [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS," RFC 1995, - August 1996. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", RFC 2119, BCP 14, March 1997. - - [RFC2136] Vixie, P., Thompson, S., Rekhter, Y., Bound, J., "Dynamic - Updates in the Domain Name System (DNS UPDATE)," RFC 2136, April - 1997. - - [RFC2287] Krupczak, C. and Saperia, J., "Definitions of System-Level - Managed Objects for Applications," RFC 2287, February 1998. - - [RFC2535] Eastlake, D., "Domain Name System Security Extensions," RFC - 2535, March 1999. - - [RFC2570] Case, J., Mundy, R., Partain, D., and Stewart, B., - "Introduction to Version 3 of the Internet-standard Network - Management Framework," - - [RFC2571] Harrington, D., Presuhn, R., and Wijnen, B., "An - Architecture for Describing SNMP Management Frameworks," RFC 2571, - April 1999. - - [RFC2572] Case, J., Harrington, D., Presuhn, R., and Wijnen, B., - Message Processing and Dispatching for the Simple Network - Management Protocol (SNMP)," RFC 2572, April 1999. - - [RFC2573] Levi, D., Meyer, P., and Stuart, "SNMP Applications," RFC - 2573, April 1999. - - [RFC2574] Blumenthal, U. and Wijnen, B., "User-based Security Model - (USM) for version 3 of the Simple Network Management Protocol - (SNMPv3)," RFC 2574, April 1999. - - - - Hibbs Expires: Nov 2001 + 6 months [Page 34] - Internet Draft DNS Server MIB November 2001 - - [RFC2575] Wijnen, B., R. Presuhn, R., McCloghrie, K., "View-based - Access Control Model (VACM) for the Simple Network Management - Protocol (SNMP)," RFC 2575, April 1999. - - [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - Rose, M., and S. Waldbusser, "Structure of Management Information - Version 2 (SMIv2)," RFC 2578, April 1999. - - [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - Rose, M., and S. Waldbusser, "Textual Conventions for SMIv2", RFC - 2579, January 1999. - - [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., - Rose, M., and S. Waldbusser, "Conformance Statements for SMIv2," - RFC 2580, April 1999. - - [RFC2673] Crawford, M., " Binary Labels in the Domain Name System," - RFC 2673, August 1999. - - [RFC3007] Wellington, B., " Secure Domain Name System (DNS) Dynamic - Update," RFC 3007, November 2000. - - - 13. Editors' Addresses - - Barr Hibbs - Nominum, Inc. - 950 Charter Street - Redwood City, California 94063 - USA - Phone: +1-(415)-648-3920 - Fax: +1-(415)-648-9017 - E-mail: Barr.Hibbs@Nominum.com - - - 14. 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. - Hibbs Expires: Nov 2001 + 6 months [Page 35] - Internet Draft DNS Server MIB November 2001 - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Hibbs Expires: Nov 2001 + 6 months [Page 36] diff --git a/doc/draft/draft-hibbs-dns-server-mib-01.txt b/doc/draft/draft-hibbs-dns-server-mib-01.txt new file mode 100644 index 0000000000..d03da69139 --- /dev/null +++ b/doc/draft/draft-hibbs-dns-server-mib-01.txt @@ -0,0 +1,19 @@ + +This Internet-Draft has been deleted. Unrevised documents placed in the +Internet-Drafts directories have a maximum life of six months. After +that time, they are deleted. This Internet-Draft was not published as +an RFC. + +Internet-Drafts are not an archival document series, and expired +drafts, such as this one, are not available; please do not ask for +copies... they are not available. The Secretariat does not have +information as to future plans of the authors or working groups WRT the +deleted Internet-Draft. + +For more information or a copy of the document, contact the author directly. + +Draft Author(s): + +R. Hibbs: rbhibbs@pacbell.com + + diff --git a/doc/draft/draft-ietf-dnsext-axfr-clarify-03.txt b/doc/draft/draft-ietf-dnsext-axfr-clarify-04.txt similarity index 91% rename from doc/draft/draft-ietf-dnsext-axfr-clarify-03.txt rename to doc/draft/draft-ietf-dnsext-axfr-clarify-04.txt index 81e2b8e880..17b883800c 100644 --- a/doc/draft/draft-ietf-dnsext-axfr-clarify-03.txt +++ b/doc/draft/draft-ietf-dnsext-axfr-clarify-04.txt @@ -1,6 +1,7 @@ + INTERNET-DRAFT Andreas Gustafsson -draft-ietf-dnsext-axfr-clarify-03.txt Nominum Inc. - July 2001 +draft-ietf-dnsext-axfr-clarify-04.txt Nominum Inc. + March 2002 DNS Zone Transfer Protocol Clarifications @@ -49,9 +50,9 @@ Abstract -Expires January 2002 [Page 1] +Expires September 2002 [Page 1] -draft-ietf-dnsext-axfr-clarify-03.txt July 2001 +draft-ietf-dnsext-axfr-clarify-04.txt March 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -105,9 +106,9 @@ draft-ietf-dnsext-axfr-clarify-03.txt July 2001 -Expires January 2002 [Page 2] +Expires September 2002 [Page 2] -draft-ietf-dnsext-axfr-clarify-03.txt July 2001 +draft-ietf-dnsext-axfr-clarify-04.txt March 2002 DNS message size. In the case of a small zone, this can cause the @@ -161,9 +162,9 @@ draft-ietf-dnsext-axfr-clarify-03.txt July 2001 -Expires January 2002 [Page 3] +Expires September 2002 [Page 3] -draft-ietf-dnsext-axfr-clarify-03.txt July 2001 +draft-ietf-dnsext-axfr-clarify-04.txt March 2002 any combination of messages with and without a question section. @@ -217,9 +218,9 @@ draft-ietf-dnsext-axfr-clarify-03.txt July 2001 -Expires January 2002 [Page 4] +Expires September 2002 [Page 4] -draft-ietf-dnsext-axfr-clarify-03.txt July 2001 +draft-ietf-dnsext-axfr-clarify-04.txt March 2002 send, and slave implementations expect to receive, the zone's SOA RR @@ -273,9 +274,9 @@ References -Expires January 2002 [Page 5] +Expires September 2002 [Page 5] -draft-ietf-dnsext-axfr-clarify-03.txt July 2001 +draft-ietf-dnsext-axfr-clarify-04.txt March 2002 [RFC1035] - Domain Names - Implementation and Specifications, P. @@ -291,7 +292,7 @@ Author's Address Andreas Gustafsson Nominum Inc. - 950 Charter Street + 2385 Bay Rd Redwood City, CA 94063 USA @@ -302,7 +303,7 @@ Author's Address Full Copyright Statement - Copyright (C) The Internet Society (2000, 2001). All Rights Reserved. + Copyright (C) The Internet Society (2000 - 2002). 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 @@ -329,9 +330,9 @@ Full Copyright Statement -Expires January 2002 [Page 6] +Expires September 2002 [Page 6] -draft-ietf-dnsext-axfr-clarify-03.txt July 2001 +draft-ietf-dnsext-axfr-clarify-04.txt March 2002 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." @@ -385,5 +386,5 @@ draft-ietf-dnsext-axfr-clarify-03.txt July 2001 -Expires January 2002 [Page 7] +Expires September 2002 [Page 7] diff --git a/doc/draft/draft-ietf-dnsext-obsolete-iquery-02.txt b/doc/draft/draft-ietf-dnsext-obsolete-iquery-03.txt similarity index 80% rename from doc/draft/draft-ietf-dnsext-obsolete-iquery-02.txt rename to doc/draft/draft-ietf-dnsext-obsolete-iquery-03.txt index b17d92d6b6..bc35af32fa 100644 --- a/doc/draft/draft-ietf-dnsext-obsolete-iquery-02.txt +++ b/doc/draft/draft-ietf-dnsext-obsolete-iquery-03.txt @@ -1,11 +1,15 @@ DNSEXT Working Group David C Lawrence INTERNET-DRAFT Nominum - December 2001 + January 2002 Updates: RFC 1035 + + Obsoleting IQUERY + + Status of this Memo This document is an Internet-Draft and is in full conformance with @@ -30,25 +34,27 @@ Status of this Memo Comments should be sent to the authors or the DNSEXT WG mailing list namedroppers@ops.ietf.org. - This draft expires on 14 June 2002. + This draft expires on 14 July 2002. Copyright Notice - Copyright (C) The Internet Society (2001). All rights reserved. + Copyright (C) The Internet Society (2002). All rights reserved. Abstract - Based on a lack of working implementations of the IQUERY method - of performing inverse DNS lookups, and because an alternative - mechanism for doing inverse queries of address records has been - successfully used operationally for well over a decade, this - draft proposes that the IQUERY operation be entirely obsoleted. + The IQUERY method of performing inverse DNS lookups, specified in + RFC 1035, has not been generally implemented and has usually been + operationally disabled where it has been implemented. Both reflect + a general view in the community that the concept was unwise and + that the widely-used alternate approach of using PTR queries and + reverse-mapping records is preferable. Consequently, this document + deprecates the IQUERY operation and updates RFC 1035 to declare it + entirely obsolete. - -Expires Jun 2002 [Page 1] +Expires Jul 2002 [Page 1] -INTERNET-DRAFT Obsoleting IQUERY June 2001 +INTERNET-DRAFT Obsoleting IQUERY January 2002 1 - Introduction @@ -98,13 +104,13 @@ INTERNET-DRAFT Obsoleting IQUERY June 2001 1.1 - Requirements - The key words "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this - document are to be interpreted as described in RFC2119. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119. - -Expires Jun 2002 [Page 2] +Expires Jul 2002 [Page 2] -INTERNET-DRAFT Obsoleting IQUERY June 2001 +INTERNET-DRAFT Obsoleting IQUERY January 2002 1.2 - Updated documents and sections @@ -153,20 +159,23 @@ INTERNET-DRAFT Obsoleting IQUERY June 2001 6 - Acknowledgments: Olafur Gudmundsson was the instigator for this action. - Matt Crawford contributed some improved wording. + Matt Crawford, John Klensin and Erik Nordmark contributed some + improved wording. - -Expires Jun 2002 [Page 3] +Expires Jul 2002 [Page 3] -INTERNET-DRAFT Obsoleting IQUERY June 2001 +INTERNET-DRAFT Obsoleting IQUERY January 2002 References: [RFC1035] P. Mockapetris, ``Domain Names - Implementation and Specification'', STD 13, RFC 1035, November 1987. +[RFC2119] S. Bradner, ``Key Words for Use in RFCs to Indicate + Requirement Levels'', BCP 14, RFC 2119, March 1997. + 7 - Author's Address David Lawrence @@ -180,7 +189,7 @@ References: Full Copyright Statement - Copyright (C) The Internet Society (2001). All Rights Reserved. + Copyright (C) The Internet Society (2002). 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 @@ -211,7 +220,4 @@ Full Copyright Statement - - - -Expires Jun 2002 [Page 4] +Expires Jul 2002 [Page 4] diff --git a/doc/draft/draft-ietf-dnsop-inaddr-required-02.txt b/doc/draft/draft-ietf-dnsop-inaddr-required-03.txt similarity index 81% rename from doc/draft/draft-ietf-dnsop-inaddr-required-02.txt rename to doc/draft/draft-ietf-dnsop-inaddr-required-03.txt index 7584cd49be..271a4f8b6b 100644 --- a/doc/draft/draft-ietf-dnsop-inaddr-required-02.txt +++ b/doc/draft/draft-ietf-dnsop-inaddr-required-03.txt @@ -6,24 +6,21 @@ INTERNET-DRAFT D. Senie Category: BCP Amaranth Networks Inc. -Expires in six months July 2001 +Expires in six months March 2002 Requiring DNS IN-ADDR Mapping - draft-ietf-dnsop-inaddr-required-02.txt. - - + draft-ietf-dnsop-inaddr-required-03.txt Status of this Memo - This draft, file name draft-ietf-dnsop-inaddr-required-00.txt, is - intended to be become a Best Current Practice RFC. Distribution of - this document is unlimited. Comments should be sent to the Domain - Name Server Operations working group mailing list or - to the author. + This draft, is intended to be become a Best Current Practice RFC. + Distribution of this document is unlimited. Comments should be sent + to the Domain Name Server Operations working group mailing list + or to the author. This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. + 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 @@ -34,16 +31,20 @@ Status of this Memo 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/1id-abstracts.html - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - + To view the list Internet-Draft Shadow Directories, see + http://www.ietf.org/shadow.html. Copyright Notice - Copyright (C) The Internet Society (2000,2001). All Rights Reserved. + Copyright (C) The Internet Society (2000-2002). All Rights Reserved. + +Abstract + + Mapping of addresses to names has been a feature of DNS. Many sites, + implement it, many others don't. Some applications attempt to use it + as a part of a security strategy. The goal of this document is to + encourage proper deployment of address to name mappings, and provide + guidance for their use. 1. Introduction @@ -52,13 +53,6 @@ Copyright Notice address, and address to name mappings are provided for networks. This practice, while documented, has never been documented as a requirement placed upon those who control address blocks. This - document fills this gap. - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. - -2. Discussion @@ -68,9 +62,17 @@ Senie [Page 1] -Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 +Internet-Draft Requiring DNS IN-ADDR Mapping March 2002 + document fills this gap. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Discussion + From the early days of the Domain Name Service [RFC 883] a special domain has been set aside for resolving mappings of IP addresses to domain names. This was refined in [RFC1035], describing the .IN- @@ -81,8 +83,9 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 [RFC2050], which requires regional registries to maintain IN-ADDR records on the large blocks of space issued to ISPs and others. - ARIN's policy only requires ISPs to maintain IN-ADDR if they have a - /16 or larger allocation [ARIN]. APNIC indicates in their policy + ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger + allocations. For smaller allocations, ARIN can provide IN-ADDR for + /24 and shorter prefixes. [ARIN]. APNIC indicates in their policy document [APNIC] that those to whom they allocate blocks, and those further downstream SHOULD maintain IN-ADDR records. RIPE appears to have the strongest policy in this area [ripe-185] indicating Local @@ -111,15 +114,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 it maps back to the address originally known. Failure to resolve matching names is seen as a potential security concern. - Some popular FTP sites will flat-out reject users, even for anonymous - FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR - lookup when itself resolved, does not match. Some Telnet servers also - implement this check. - - Web sites are in some cases using IN-ADDR checks to verify whether - the client is located within a certain geopolitical entity. This is - being employed for downloads of crypto software, for example, where - Senie [Page 2] @@ -128,9 +122,17 @@ Senie [Page 2] -Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 +Internet-Draft Requiring DNS IN-ADDR Mapping March 2002 + Some popular FTP sites will flat-out reject users, even for anonymous + FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR + lookup when itself resolved, does not match. Some Telnet servers also + implement this check. + + Web sites are in some cases using IN-ADDR checks to verify whether + the client is located within a certain geopolitical entity. This is + being employed for downloads of crypto software, for example, where export of that software is prohibited to some locales. Credit card anti-fraud systems also use these methods for geographic placement purposes. @@ -154,7 +156,7 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 Traceroutes with descriptive IN-ADDR naming proves useful when debugging problems spanning large areas. When this information is missing, the traceroutes take longer, and it takes additional steps - to determine who's network is the cause of problems. + to determine which network is the cause of problems. 4. Requirements @@ -171,14 +173,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 Internet providers and other users to whom a block of addresses are delegated SHOULD provide for lookup of host names from IP addresses. This may be provided directly or by delegation to the user of the - address block. The ISP is responsible for one or the other. In the - event of delegation, the user is responsible for resolution. - - Only IP addresses not presently in use within a block, or which are - not valid for use (zeros or ones broadcast addresses) are permitted - to have no mapping. It should be noted that due to CIDR, many - addresses which appear to be otherwise valid host addresses may - actually be zeroes or ones broadcast addresses. As such, attempting @@ -188,9 +182,17 @@ Senie [Page 3] -Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 +Internet-Draft Requiring DNS IN-ADDR Mapping March 2002 + address block. The ISP is responsible for one or the other. In the + event of delegation, the user is responsible for resolution. + + Only IP addresses not presently in use within a block, or which are + not valid for use (zeros or ones broadcast addresses) are permitted + to have no mapping. It should be noted that due to CIDR, many + addresses which appear to be otherwise valid host addresses may + actually be zeroes or ones broadcast addresses. As such, attempting to audit a site's degree of compliance can only be done with a knowledge of the internal routing structure of the site. However, any host which originates an IP packet necessarily will have a valid host @@ -213,7 +215,7 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 This document has no negative impact on security. While it could be argued that lack of PTR record capabilities provides a degree of - anonimity, this is really not valid. Trace routes, whois lookups and + anonymity, this is really not valid. Trace routes, whois lookups and other sources will still provide methods for discovering identity. By recommending applications avoid using IN-ADDR as a security @@ -231,14 +233,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 [RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy," RFC 1519, September - 1993. - - [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," - RFC 2317, March 1998. - - [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation - Guidelines", RFC2050, BCP 12, Novebmer 1996. - @@ -248,14 +242,28 @@ Senie [Page 4] -Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 +Internet-Draft Requiring DNS IN-ADDR Mapping March 2002 + 1993. + + [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", + RFC 2026, BCP 9, October 1996. + + [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + + [RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation + Guidelines", RFC2050, BCP 12, Novebmer 1996. + + [RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation," + RFC 2317, March 1998. + [ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date unknown, http://www.arin.net/regserv/initial-isp.html - [APNIC] "Policies for address space management in the Asia Pacific - Region," Approved October 1999, effective January 2000, + [APNIC] "Policies For IPv4 Address Space Management in the Asia + Pacific Region," APNIC-086, Approval pending, 17 December 2001, http://www.apnic.net/drafts/add-manage-policy.html [RIPE185] "European Internet Registry Policies and Procedures," @@ -283,20 +291,6 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 - - - - - - - - - - - - - - @@ -305,3 +299,7 @@ Internet-Draft Requiring DNS IN-ADDR Mapping July 2001 Senie [Page 5] +----------------------------------------------------------------- +Daniel Senie dts@senie.com +Amaranth Networks Inc. http://www.amaranth.com + diff --git a/doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-00.txt b/doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-00.txt deleted file mode 100644 index 160d0f8298..0000000000 --- a/doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-00.txt +++ /dev/null @@ -1,337 +0,0 @@ - -Internet Draft Johan Ihren -draft-ietf-dnsop-v6-name-space-fragmentation-00.txt Autonomica -January 2002 -Expires in six months - - - IPv4-to-IPv6 migration and DNS name space fragmentation - - -Status of this Memo - - This memo provides information to the Internet community. It does - no specify an Internet standard of any kind. This memo is in full - conformance with all provisions of Section 10 of RFC2026. - - 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 - - This memo documents some problems forseen in transitioning from a - IPv4-only DNS hierarchy via a long period of mixture to an - IPv6-mostly situation sometime in the future. The mixture period is - expected to be very long, and hence design choices should very much - take this into account, rather than just regard the transition as a - relatively short period of pain. - - The main problem with transition that this paper focus on is what - to do about the name space fragmentation that may result from - certain DNS data only being available over one type of transport - (i.e. v4 or v6) which is thereby likely unavailable to hosts that - can cannot utilize that transport. - - Two orthogonal issues are identified and discussed: deployment and - use. The former while technically simple holds certain dangers that - should be avoided. The "use" (as in performing DNS lookups) is much - more complicated, and a roadmap for this is presented. - -1. Terminology - - The key words "MUST", "SHALL", "REQUIRED", "SHOULD", - "RECOMMENDED", and "MAY" in this document are to be interpreted as - described in RFC 2119 [RFC2119]. - - The phrase "v4 name server" indicates a name server available over - IPv4 transport. It does not imply anything about what DNS data is - served. Likewise, "v6 name server" indicates a name server - available over IPv6 transport. - - -2. Introduction to the problem of name space fragmentation - - With all DNS data only available over IPv4 transport everything is - simple. IPv4 resolvers can use the intended mechanism of following - referrals from the root and down while IPv6 resolvers have to work - through a "translator", i.e. they have to use a second name server - on a so-called "dual stack" host as a "forwarder" since they cannot - access the DNS data directly. This is not a scalable solution. - - With all DNS data only available over IPv6 transport everything - would be equally simple, with the exception of old legacy IPv4 name - servers having to switch to a forwarding configuration. - - However, the second situation will not arise in a foreseeable - time. Instead, it is expected that the transition will be from IPv4 - only to a mixture of IPv4 and IPv6, with DNS data of theoretically - three categories depending on whether it is available only over - IPv4 transport, only over IPv6 or both. - - The latter is the best situation, and a major question is how to - ensure that it as quickly as possible becomes the norm. However, - while it is obvious that some DNS data will only be available over - v4 transport for a long time it is also obvious that it is - important to avoid fragmenting the name space available to IPv4 - only hosts. I.e. during transition it is not acceptable to break - the name space that we presently have available for IPv4-only - hosts. - -3. Consequences of deploying a "IPv6 root name server" - - If and when a root name server that is accessible over IPv6 - transport is deployed it will immediately become possible to change - IPv6-only name servers to a "native configuration", i.e. to a - configuration where they follow referrals directly from the root - (which is now accessible to them because of the v6 transport). - - However, initially they will typically quite soon get a so-called - "referral" to a name server only available over IPv4 transport, and - this will be impossible to follow, since there is no common - transport available. Therefore the name it is trying to lookup will - not get looked up and the result is that a v6-only name server - cannot lookup the same names that its v4-only counterpart can. - - There are two available methods of addressing this problem: - - a) ignore it, i.e. don't solve the problem, but put the effort into - helping deployment along so that the problem will shrink over - time. - - b) provide some sort of "transport bridging", i.e. create a - fallback mechanism that enables a name server with only one type - of transport to reach a name server only available over the - other transport via some sort of proxy service. See for instance - [DNS-opreq] and [DNS-proxy] for discussions. - - Regardless of how this problem is handled it is important to - realize that it only concerns the fragmented name space in - IPv6. I.e. the IPv4 name space is not (yet) fragmented, and a more - important question is possibly how to keep it unfragmented. - -4. Policy based avoidance of name space fragmentation. - - Today there are only a few DNS "zones" on the public Internet that - are only available over v6 transport, and they can mostly be - regarded as "experimental". However, as soon as there is a root - name server available over v6 transport it is reasonable to expect - that it will become more common with v6-only zones over time. - - This would not be a good development, since this will fragment the - previously unfragmented IPv4 name space and there are strong - reasons to find a mechanism to avoid it. - -4.1. Requirement of IPv4 address for at least one name server. - - To ensure that all zones remain available over IPv4 transport one - method would be to require that nameservers authoritative for a - zone as part of the zone validation process ensure that there are - IPv4 address records available for the name servers of any child - delegations within the zone). - - I.e. the future policy would be: - - "Every delegation point should have at least one name server - for the child zone reachable over IPv4 transport". - - To ensure this the authoritative server will have to lookup the - address records of the name servers that are part of any - "delegation" points in the zone. - - I.e. for given the domain EXAMPLE.COM with the following data - - $ORIGIN example.com. - child.example.com. IN NS ns.example.com. - child.example.com. IN NS dns.autonomica.se. - ns.example.com. IN A 1.2.3.4 - - the delegation of CHILD.EXAMPLE.COM is to the two name servers - "ns.example.com" and "dns.autonomica.se". The first name server, - "ns.example.com", obviously has an IPv4 address (as shown by the - "glue" record on the last line). - - However, "ns.example.com" may have additional addresses assiciated - with it. Also there is no way for the server loading the zone to - know the address(es) of "dns.autonomica.se". Therefore, to find out - all the publicly available addresses they have to be queried for. - -4.2. Zone validation for non-recursive servers. - - Non-recursive authoritative servers are name servers that run - without ever asking questions. A change in the zone validation - requirements that force them to query for the addresses of name - servers that are part of delegations in the zone change this, since - they now have to query for these addresses. - - However, the main reason that it is important to be able to run - without asking questions is to avoid "caching" possibly bogus - answers. This need can be managed by requiring that a non recursive - name server throw away the looked up address information after - having used it for validation of the delegations in the zone. - -4.3. Future requirement of IPv6 address for at least one name server. - - The immediate need for clarified policies for delegation is to - ensure that IPv4 name space does not start to fragment. Over time, - however, it is reasonable to expect that it may become important to - add a similar requirement to IPv6 name space. - - I.e. an even more refined policy possible at some point in the - future would be: - - "Every delegation point should have at least one name server - for the child zone reachable over IPv4 transport (i.e. should - have an A record) and at least one name server reachable over - IPv6 transport (i.e. should have an AAAA record)". - -4.4. Implementation issues for new zone validation requirements. - - Exactly what action should be taken when a zone does not validate - is not immediately clear. Immediate alternatives include: - - a) fail the entire zone - - b) load the zone but remove the delegation that failed validation - - c) load the entire zone but issue a warning message about the - delegation that failed validation. - - A likely implementation will make it configurable what action to - take. - -5. Overview of suggested transition method. - - By following the steps outlined below it will be possible to - transition without outages or lack of service. The assumption is - that the site has only v4 name servers or possibly v4 name servers - plus v6 name server in a forwarding configuration. All DNS data is - on the v4 name servers. - - 1) Do not change the method of resolution on any name server. - I.e. v4 servers go to the root and follow referrals while v6 - servers go to their translator/forwarder which lookup the name - and return the end result. - - 2) Start mirroring DNS data into v6 by providing v6 name servers - serving the zones. Add v6 address information to to the zones - and as glue at the parent zone. Note that it is important that - the zone should have the same contents regardless of whether it - is the v4 version or the v6 version. Anything else will lead to - confusion. - - 4) Wait for the announcement of the DNS root zone being available - from a v6 name server. - - 5) Ensure that the entire path from the root down to the domain in - question is reachable over both IPv4 and IPv6 transport. - - When this is accomplished it it possible to begin a migration of - the lookup of selected services to be available over IPv6 - (i.e. typically by adding a AAAA record for a server of some sort). - -6. How to deploy DNS hierarchy in v6 space. - - The main problem with changing the DNS data so that it will become - available over both IPv6 and IPv4 transport is one of scale. There - are too many name servers and too many DNS zones for any kind of - forced migration to be aven remotely possible. - - The way of achieving deployment is by providing domain owner with - - a) a reason to deploy - - b) a method to deploy - - c) a way of verififying the correctness of the resulting configuration - -6.1. A reason to deploy. - - It is important to the migration process that zones migrate to - become available over v6 transport (as well as v4 transport). But - it is difficult to actually require such deployment too early in - the migration process. - - Over time, however, it will become more reasonable to add such a - requirement. One likely method to do this will be by updating the - requirements for proper zone validation as was outlined above. - -6.2. How to deploy DNS data. - - Assuming the owner of the DNS domain has access to both IPv4 and - IPv6 address space that is globally routed. The steps to take are - then - - a) identify all name servers that will serve the DNS domain, with - their IPv4 and/or IPv6 addresses - - b) arrange for a suitable method of zone synchronization - - c) announce the new set of servers to the parent zone, including - possible new IPv6 glue - - It is recommended that the name servers run on single stack - machines, i.e. machines that are only able to utilize either IPv4 - transport or IPv6 transport, but not both. - - A common recommendation (mostly orthogonal to IPv6 transition - issues) is that authoritative name servers only serve data, - i.e. they do not act as caching resolvers. That way, since they - operate in non-recursive mode, they will not have any cache, and - hence will not be able to give out wrongful answers based upon - errors in the cache. - - Since the announced name servers are single stack, the primary - master from which they fetch zone data will typically have to be - dual stack or otherwise some other method of data transfer has to - be arranged. - -7. Security Considerations - - Much of the security of the Internet relies, often wrongly, but - still, on the DNS. Thus, changes to the characteristics of the DNS - may impact the security of Internet based services. - - Although it will be avoided, there may be unintended consequences - as a result of operational deployment of RR types and protocols - already approved by the IETF. When or if such consequences are - identified, appropriate feedback will be provided to the IETF and - the operational community on the efficacy of said interactions. - -8. Summary. - - The name space fragmentation problem is identified and examined at - some length. - - A solution based upon a change in the validation method of - delegation points is suggested. This will both help keep the v4 - name space unfragmented and may also help speed up deployment of - DNS hierarchy in v6 space. - - - -9. References - - [RFC1034] Domain names - concepts and facilities. - P.V. Mockapetris. - - [RFC1035] Domain names - implementation and specification. - P.V. Mockapetris. - - [RFC2826] IAB Technical Comment on th Unique DNS Root - - [DNS-proxy] draft-durand-dns-proxy-00.txt - Alain Durand - - [DNS-opreq] draft-ietf-ngtrans-dns-ops-req-02.txt - Alain Durand - - -A. Authors' Address - -Johan Ihren -Autonomica -Bellmansgatan 30 -SE-118 47 Stockholm, Sweden -johani@autonomica.se diff --git a/doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-01.txt b/doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-01.txt new file mode 100644 index 0000000000..14a1b488da --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-v6-name-space-fragmentation-01.txt @@ -0,0 +1,348 @@ + +Internet Draft Johan Ihren +draft-ietf-dnsop-v6-name-space-fragmentation-01.txt Autonomica AB +March 2002 +Expires in six months + + + IPv4-to-IPv6 migration and DNS namespace fragmentation + + +Status of this Memo + + This memo provides information to the Internet community. It does + no specify an Internet standard of any kind. This memo is still not + in full conformance with all provisions of Section 10 of RFC2026. + + 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 + + This memo documents some problems forseen in transitioning from a + IPv4-only DNS hierarchy via a long period of mixture to an + IPv6-mostly situation sometime in the future. The mixture period is + expected to be very long, and hence design choices should very much + take this into account, rather than just regard the transition as a + relatively short period of pain. + + The main problem with transition that this paper focus on is what + to do about the namespace fragmentation that may result from + certain DNS data only being available over one type of transport + (i.e. v4 or v6) which is thereby likely unavailable to hosts that + can cannot utilize that transport. + + Two orthogonal issues are identified and discussed: deployment and + use. The former while technically simple holds certain dangers that + should be avoided. The "use" (as in performing DNS lookups) is much + more complicated, and a suggested roadmap for this is presented. + +1. Terminology + + The key words "MUST", "SHALL", "REQUIRED", "SHOULD", + "RECOMMENDED", and "MAY", when used un uppercase, in this document + are to be interpreted as described in RFC 2119 [RFC2119]. + + The phrase "v4 name server" indicates a name server available over + IPv4 transport. It does not imply anything about what DNS data is + served. Likewise, "v6 name server" indicates a name server + available over IPv6 transport. In general this document only + discuss transport issues and does not care exactly what is + transported. + + +2. Introduction to the problem of namespace fragmentation + + With all DNS data only available over IPv4 transport everything is + simple. IPv4 resolvers can use the intended mechanism of following + referrals from the root and down while IPv6 resolvers have to work + through a "translator", i.e. they have to use a second name server + on a so-called "dual stack" host as a "forwarder" since they cannot + access the DNS data directly. This is not a scalable solution. + + With all DNS data only available over IPv6 transport everything + would be equally simple, with the exception of old legacy IPv4 name + servers having to switch to a forwarding configuration. + + However, the second situation will not arise in a foreseeable + time. Instead, it is expected that the transition will be from IPv4 + only to a mixture of IPv4 and IPv6, with DNS data of theoretically + three types of availability, depending on whether it is available + only over IPv4 transport, only over IPv6 or both. + + The latter is the best situation, and a major question is how to + ensure that it as quickly as possible becomes the norm. However, + while it is obvious that some DNS data will only be available over + v4 transport for a long time it is also obvious that it is + important to avoid fragmenting the namespace available to IPv4 + only hosts. I.e. during transition it is not acceptable to break + the namespace that we presently have available for IPv4-only hosts. + +2.1. Namespace fragmentation vs. unreachability. + + Something that is presently not clear is whether it is actually + necessary to provide access to the "Internet namespace" as defined + by what is visble on the public v4 Internet also on v6 transport. + + The reason for the unclarity is that if one regards "the Internet" + as the largest set of nodes that have a mutual 1-1 reachability for + any pair of nodes over IP and adjust the "Internet namespace" to + fit this set, then there is by definition no need to bridge or do + any special tricks (since they can all reach each other anyhow). + + On the other hand, if we regard "the Internet" as the set of nodes + that share a namespace that we can refer to as "the Internet + namespace" regardless of whether they can all reach each other or + not, then we have to ensure that this namespace is accessible to + every node, regardless of its available transport. + + It is out of scope for this document to make a choice between the + two alternatives, and therefore the rest of this document has to + work from the assumption that the same namespace should, if + possible, be made available to all nodes that claim to be part of + the Internet. + +3. Consequences of deploying a "IPv6 root name server" + + If and when a root name server that is accessible over IPv6 + transport is deployed it will immediately for the first time become + possible to change IPv6-only name servers to a "native + configuration", i.e. to a configuration where they follow referrals + directly from the root (which is now accessible to them because of + the v6 transport). + + However, initially they will typically quite soon get a referral to + a name server only available over IPv4 transport, and this will be + impossible to follow, since there is no common transport available. + Therefore the name it is trying to lookup will not get resolved and + the result is that the v6-only name server cannot lookup the same + set of domain names that its v4-only counterpart can. + + This is fragmentation of the namespace. + + Regardless of how this problem is handled it is important to + realize that at first it will only concern the namespace as viewed + from an IPv6-host. I.e. the IPv4 namespace will not (initially) be + fragmented, and an important question is possibly how to keep it + unfragmented. + +4. A taxonomy of alternatives to avoid fragmentation. + +4.1. Ignore the problem. + + It is possible to ignore the fragmentation issue. Whether that is + an acceptable choice or not has to be very carefully considered. Is + it reasonable to allow v4 only hosts to over time lose access to + parts of the Internet namespace just because they are not + "IPv6-aware"? + +4.2. DNS transport bridging. + + By providing some sort of "DNS transport bridging", i.e. create a + fallback mechanism that enables a name server with only one type of + transport to reach a name server only available over the other + transport via some sort of proxy service it would be possible to + unify the DNS zones available on each transport into a common + namespace. + + The general consensus is that it is not possible to design such a + bridging solution that works in both directions. However, it may be + possible to design one that allows v6 clients to query v4 servers. + See for instance [DNS-opreq] and [DNS-proxy] for more detailed + discussions. + +4.3. Policy based avoidance of fragmentation. + + Today there are only a limited number of DNS zones on the public + Internet that are only available over v6 transport, and they can + mostly be regarded as "experimental". However, as soon as there is + a root name server available over v6 transport it is reasonable to + expect that it will become more common with v6-only zones over + time. + + Such a development would erode the Internet namespace as viewed + from an v4-only client. There are obviously strong reasons to find + a mechanism to avoid this happening. + +4.3.1. Requirement of zone reachability over IPv4 transport. + + To ensure that all zones remain available over IPv4 transport one + method would be to require that nameservers authoritative for a + zone as part of the zone validation process ensure that there are + IPv4 address records available for the name servers of any child + delegations within the zone). + + I.e. the future policy could be: + + "Every delegation point delegated to nameservers available + over v6 transport should have the same availability + requirements for servers over both v4 and v6 transport as v4 + only zones have over v4 transport. + + I.e. if the parent requires "multiple nameservers" for a child, + then the requirement becomes "multiple nameservers available over + v4 transport plus multiple nameservers available over v6 transport" + + I.e. for given the domain EXAMPLE.COM with the following data + + $ORIGIN example.com. + child.example.com. IN NS ns.example.com. + child.example.com. IN NS dns.autonomica.se. + ns.example.com. IN A 1.2.3.4 + + the delegation of CHILD.EXAMPLE.COM is to the two name servers + "ns.example.com" and "dns.autonomica.se". The first name server, + "ns.example.com", obviously has an IPv4 address (as shown by the + "glue" record on the last line). + + However, "ns.example.com" may have additional addresses assiciated + with it. Also there is no way for the server loading the zone to + know the address(es) of "dns.autonomica.se". Therefore, to find out + all the publicly available addresses they have to be queried for. + + To ensure this the authoritative server will have to lookup the + address records of the name servers that are part of any + "delegation" points in the zone. However, this operation is very + costly for large, delegation-dense zones and therefore it is likely + that compromises a la + + * only validate on the master (this is likely always good practice) + + * validate as an offline process (i.e. not part of the zone loading) + + * only validate at time of delegation + + * never validate + + Clearly, as validation is relaxed the amount of errors will + increase, so the sum of pain as usual remains mostly constant. + +4.3.2. Zone validation for non-recursive servers. + + Non-recursive authoritative servers are name servers that run + without ever asking questions. A change in the zone validation + requirements that force them to query for the addresses of name + servers that are part of delegations in the zone change this, since + they now have to query for these addresses. + + However, the main reason that it is important to be able to run + without asking questions is to avoid "caching" possibly bogus + answers. This need can be managed by requiring that a non recursive + name server throw away the looked up address information after + having used it for validation of the delegations in the zone. + +4.3.3. Future requirement of zone reachability over IPv6 transport. + + The immediate need for clarified policies for delegation is to + ensure that IPv4 namespace does not start to fragment. Over time, + however, it is reasonable to expect that it may become important to + add a similar requirement to IPv6 namespace. + + I.e. an even more refined policy possible at some point in the + future would be: + + "Every delegation point should have at least one name server + for the child zone reachable over IPv4 transport (i.e. should + have an A record) and at least one name server reachable over + IPv6 transport (i.e. should have e.g. an AAAA record)". + +4.3.4. Implementation issues for new zone validation requirements. + + Exactly what action should be taken when a zone does not validate + is not immediately clear. Immediate alternatives include: + + a) fail the entire parent zone (the extreme case, not suggested) + + b) load the zone but remove the delegation that failed validation + (also drastic, and not suggested) + + c) load the entire zone but issue a warning message about the + delegation that failed validation (more reasonable) + + Implementations should make it configurable what action to take. In + the case of registries that have a business realtion to the child + zone it is also in principle possible to work on the deployment of + child zones over v6 transport by cost diffentiation for the + customer. + +5. Overview of suggested transition method. + + By following the steps outlined below it will be possible to + transition without outages or lack of service. The assumption is + that the site has only v4 name servers or possibly v4 name servers + plus v6 name server in a forwarding configuration. All DNS data is + on the v4 name servers. + + 1) Do not change the method of resolution on any (recursive) name + server. I.e. v4 servers go to the root and follow referrals + while v6 servers go to their translator/forwarder which lookup + the name and return the end result. + + 2) Start serving authoritative DNS data on v6 transport by + providing name servers with v6 transport serving the zones. Add + v6 address information to to the zones and as glue at the parent + zone. Note that it is of crucial importance that the zone should + have the same contents regardless of whether it is the v4 + version or the v6 version. Anything else will lead to confusion. + + 4) Wait for the announcement of the DNS root zone being available + from a v6 name server. + + 5) Ensure that the entire path from the root down to the domain in + question is reachable over both IPv4 and IPv6 transport. + + When this is accomplished it it possible to begin a migration of + the lookup of selected services to be available over IPv6 + (i.e. typically by adding a IPv6 address record, eg. AAAA record, + for a server of some sort). + +6. Security Considerations + + Much of the security of the Internet relies, often wrongly, but + still, on the DNS. Thus, changes to the characteristics of the DNS + may impact the security of Internet based services. + + Although it will be avoided, there may be unintended consequences + as a result of operational deployment of RR types and protocols + already approved by the IETF. When or if such consequences are + identified, appropriate feedback will be provided to the IETF and + the operational community on the efficacy of said interactions. + +7. Summary. + + The namespace fragmentation problem is identified and examined at + some length. + + A solution based upon a change in the validation method of + delegation points is suggested. This will both help keep the v4 + namespace unfragmented and may also help speed up deployment of + DNS hierarchy in v6 space. + + + +9. References + + [RFC1034] Domain names - concepts and facilities. + P.V. Mockapetris. + + [RFC1035] Domain names - implementation and specification. + P.V. Mockapetris. + + [RFC2826] IAB Technical Comment on th Unique DNS Root + + [DNS-proxy] draft-durand-dns-proxy-00.txt + Alain Durand + + [DNS-opreq] draft-ietf-ngtrans-dns-ops-req-02.txt + Alain Durand + + +A. Authors' Address + +Johan Ihren +Autonomica +Bellmansgatan 30 +SE-118 47 Stockholm, Sweden +johani@autonomica.se diff --git a/doc/draft/draft-ietf-enum-e164-gstn-np-02.txt b/doc/draft/draft-ietf-enum-e164-gstn-np-03.txt similarity index 83% rename from doc/draft/draft-ietf-enum-e164-gstn-np-02.txt rename to doc/draft/draft-ietf-enum-e164-gstn-np-03.txt index 46fc05fa80..b4248b6633 100644 --- a/doc/draft/draft-ietf-enum-e164-gstn-np-02.txt +++ b/doc/draft/draft-ietf-enum-e164-gstn-np-03.txt @@ -1,10 +1,9 @@ - Mark Foster Internet Draft Tom McGarry -Document: James Yu +Document: James Yu NeuStar, Inc. -Category: Informational October 19, 2001 +Category: Informational March 1, 2001 Number Portability in the GSTN: An Overview @@ -30,47 +29,67 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - To learn the current status of any Internet-Draft, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), - munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or - ftp.isi.edu (US West Coast). + + Copyright Notice + + Copyright (C) The Internet Society (2002). All rights reserved. -1. Abstract + Abstract This document provides an overview of E.164 telephone number - portability (NP) in the Global Switched Telephone Network (GSTN). - There are three types of number portability: service provider number - portability (SPNP), location portability, and service portability. - Service provider portability, the focus of the present draft, is a - regulatory imperative in many countries seeking to liberalize local - telephony service competition, by enabling end-users to retain pre- - existing telephone numbers while changing service providers. - Implementation of NP within national GSTN entails potentially - significant changes to numbering administration, network element - signaling, call routing and processing, billing, service management, - and other functions. NP changes the fundamental nature of a dialed - E.164 number from a hierarchical physical routing address to a - virtual address, thereby requiring the transparent translation of - the later to the former. In addition, there are various regulatory - + portability (NP) in the Global Switched Telephone Network (GSTN). + NP is a regulatory imperative seeking to liberalize local telephony + service competition, by enabling end-users to retain telephone + numbers while changing service providers. NP changes the + fundamental nature of a dialed E.164 number from a hierarchical + physical routing address to a virtual address, thereby requiring the + transparent translation of the later to the former. In addition, + there are various regulatory constraints that establish relevant + parameters for NP implementation, most of which are not network + technology specific. Consequently, the implementation of NP + behavior consistent with applicable regulatory constraints, as well + as the need for interoperation with the existing GSTN NP + implementations, are relevant topics for numerous areas of IP + telephony work-in-progress at IETF. - Informational - Expiration in April 19, 2002 1 - -Number Portability in the GSTN: An Overview October 19, 2001 +Foster,McGarry,Yu Expired on August 31, 2002 [Page 1] +Number Portability in the GSTN: An Overview March 1, 2002 - constraints that establish relevant parameters for NP - implementation, most of which are not network technology specific. - Consequently, the implementation of NP behavior consistent with - applicable regulatory constraints, as well as the need for - interoperation with the existing GSTN NP implementations, are - relevant topics for numerous areas of IP telephony work-in-progress - at IETF. - -2. Introduction + Table of Contents + + 1. Introduction ............................................... 2 + 2. Abbreviations and Acronyms ................................. 4 + 3. Types of Number Portability ................................ 5 + 4. Service Provider Number Portability Schemes ................ 7 + 4.1 All Call Query (ACQ) .................................. 7 + 4.2 Query on Release (QoR) ................................ 8 + 4.3 Call Dropback ......................................... 9 + 4.4 Onward Routing (OR) ................................... 9 + 4.5 Comparisons of the Four Schemes ....................... 10 + 5. Database Queries in the NP Environment ..................... 11 + 5.1 U.S. and Canada ....................................... 12 + 5.2 Europe ................................................ 13 + 6. Call Routing in the NP Environment ......................... 14 + 6.1 U.S. and Canada ....................................... 14 + 6.2 Europe ................................................ 15 + 7. NP Implementations for Geographic E.164 Numbers ............ 18 + 8. Number Conservation Method Enabled By NP ................... 20 + 8.1 Block Pooling ......................................... 20 + 8.2 ITN Pooling ........................................... 21 + 9. Potential Implications ..................................... 21 + 10. Security Considerations .................................... 24 + 11. IANA Considerations ........................................ 24 + 12. Normative References ....................................... 25 + 13. Informative References ..................................... 25 + 14. Acknowledgement ............................................ 26 + 15. AuthorsÆ Addresses ......................................... 26 + + + +1. Introduction This document provides an overview of E.164 telephone number portability in the Global Switched Telephone Network (GSTN). There @@ -91,6 +110,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 geographic numbers do not reveal the locations information of those numbers. Geographic E.164 numbers were intentionally designed as hierarchical routing addresses which could systematically be digit- + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 2] +Number Portability in the GSTN: An Overview March 1, 2002 + + analyzed to ascertain the country, serving network provider, serving end-office switch, and specific line of the called party. As such, without NP a subscriber wishing to change service providers would @@ -114,12 +138,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 NP changes the fundamental nature of a dialed E.164 number from a hierarchical physical routing address to a virtual address. NP - - Informational - Expiration in April 19, 2002 2 - -Number Portability in the GSTN: An Overview October 19, 2001 - - implementations attempt to encapsulate the impacts to the GSTN and make NP transparent to subscribers by incorporating a translation function to map a dialed, potentially ported E.164 address, into a @@ -150,6 +168,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 establish relevant parameters for NP implementation, most of which are not network technology specific. Consequently, implementations of NP behavior in IP telephony consistent with applicable regulatory + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 3] +Number Portability in the GSTN: An Overview March 1, 2002 + + constraints, as well as the need for interoperation with the existing GSTN NP implementations, are relevant topics for numerous areas of IP telephony work-in-progress at IETF. @@ -173,13 +196,7 @@ Number Portability in the GSTN: An Overview October 19, 2001 number portability database in North America. - - Informational - Expiration in April 19, 2002 3 - -Number Portability in the GSTN: An Overview October 19, 2001 - - -3. Abbreviations and Acronyms +2. Abbreviations and Acronyms ACQ All Call Query AIN Advanced Intelligent Network @@ -209,6 +226,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 IN Intelligent Network INAP Intelligent Network Application Part INP Interim NP + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 4] +Number Portability in the GSTN: An Overview March 1, 2002 + + IP Internet Protocol IS-41 Interim Standards Number 41 ISDN Integrated Services Digital Network @@ -232,12 +254,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 OSS Operation Support System PCS Personal Communication Services PNTI Ported Number Translation Indicator - - Informational - Expiration in April 19, 2002 4 - -Number Portability in the GSTN: An Overview October 19, 2001 - - PODP Public Office Dialing Plan PUC Public Utility Commission QoR Query on Release @@ -261,13 +277,18 @@ Number Portability in the GSTN: An Overview October 19, 2001 U.S. United States -4. Types of Number Portability +3. Types of Number Portability As there are several types of E.164 numbers (telephone numbers, or just TN) in the GSTN, there are correspondingly several types of E.164 NP in the GSTN. First there are so-call non-geographic E.164 numbers, commonly used for service-specific applications such as freephone (800 or 0800). Portability of these numbers is called + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 5] +Number Portability in the GSTN: An Overview March 1, 2002 + + non-geographic number portability (NGNP). NGNP, for example, was deployed in the U.S. in 1986-92. @@ -291,12 +312,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 The ability to change the subscribed services (e.g., from the plain old telephone service to Integrated Services Digital Network (ISDN) services) while keeping the same phone number is called service - - Informational - Expiration in April 19, 2002 5 - -Number Portability in the GSTN: An Overview October 19, 2001 - - portability. Another aspect of service portability is to allow the subscribers to enjoy the subscribed services in the same way when they roam outside their home networks as is supported by the @@ -326,9 +341,13 @@ Number Portability in the GSTN: An Overview October 19, 2001 telephony implementations as a result of regulatory and industry requirements for providing call routing and signaling independent of the donor network or last previous serving network. - - -5. Service Provider Number Portability Schemes + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 6] +Number Portability in the GSTN: An Overview March 1, 2002 + + +4. Service Provider Number Portability Schemes Four schemes can be used to support service provider portability and are briefly described below. But first, some further terms are @@ -349,13 +368,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 particular TN based on the service provider to whom the subtending number range was administratively assigned. See the discussion below on number pooling, as this enhancement to NP further - - - Informational - Expiration in April 19, 2002 6 - -Number Portability in the GSTN: An Overview October 19, 2001 - - bifurcates the role of donor network into two (the number range or code holder network, and the block holder network). @@ -374,10 +386,27 @@ Number Portability in the GSTN: An Overview October 19, 2001 four schemes is not discussed to simplify the explanation. -5.1 All Call Query (ACQ) +4.1 All Call Query (ACQ) Figure 1 shows the call steps for the ACQ scheme. Those call steps are as follows: + + (1) The Originating Network receives a call from the caller and + sends a query to a centrally administered Number Portability + Database (NPDB), a copy of which is usually resident on a + network element within its network or through a third party + provider. + (2) The NPDB returns the routing number associated with the dialed + directory number. The routing number is discussed later in + Section 6. + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 7] +Number Portability in the GSTN: An Overview March 1, 2002 + + + (3) The Originating Network uses the routing number to route the + call to the new serving network. +-------------+ +-----------+ Number +-----------+ @@ -399,39 +428,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 Figure 1 - All Call Query (ACQ) Scheme. - (1) The Originating Network receives a call from the caller and - sends a query to a centrally administered Number Portability - Database (NPDB), a copy of which is usually resident on a - network element within its network or through a third party - provider. - (2) The NPDB returns the routing number associated with the dialed - directory number. The routing number is discussed later in - Section 7. - (3) The Originating Network uses the routing number to route the - call to the new serving network. - - Informational - Expiration in April 19, 2002 7 - -Number Portability in the GSTN: An Overview October 19, 2001 - - - -5.2 Query on Release (QoR) +4.2 Query on Release (QoR) Figure 2 shows the call steps for the QoR scheme. Those call steps are as follows: - (1) The Originating Network receives a call from the caller and - routes the call to the donor network. - (2) The donor network releases the call and indicates that the - dialed directory number has been ported out of that switch. - (3) The Originating Network sends a query to its copy of the - centrally administered NPDB. - (4) The NPDB returns the routing number associated with the dialed - directory number. - (5) The Originating Network uses the routing number to route the - call to the new serving network. - +-------------+ +-----------+ Number +-----------+ | Centralized | | New Serv. | ported | Old Serv. | @@ -451,8 +452,24 @@ Number Portability in the GSTN: An Overview October 19, 2001 Figure 2 - Query on Release (QoR) Scheme. + (1) The Originating Network receives a call from the caller and + routes the call to the donor network. + (2) The donor network releases the call and indicates that the + dialed directory number has been ported out of that switch. + (3) The Originating Network sends a query to its copy of the + centrally administered NPDB. + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 8] +Number Portability in the GSTN: An Overview March 1, 2002 + + + (4) The NPDB returns the routing number associated with the dialed + directory number. + (5) The Originating Network uses the routing number to route the + call to the new serving network. -5.3 Call Dropback + +4.3 Call Dropback Figure 3 shows the call steps for the Dropback scheme. This scheme is also known as "Return to Pivot (RTP)." Those call steps are as @@ -467,13 +484,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 dialed directory number. (4) The donor network releases the call by providing the routing number. - - - Informational - Expiration in April 19, 2002 8 - -Number Portability in the GSTN: An Overview October 19, 2001 - - (5) The Originating Network uses the routing number to route the call to the new serving network. @@ -496,16 +506,21 @@ Number Portability in the GSTN: An Overview October 19, 2001 Figure 3 - Dropback Scheme. -5.4 Onward Routing (OR) +4.4 Onward Routing (OR) - Figure 4 shows the call steps for the OR scheme. This scheme is also - called Remote Call Forwarding. Those call steps are as follows: + Figure 4 shows the call steps for the OR scheme. Those call steps + are as follows: (1) The Originating Network receives a call from the caller and routes the call to the donor network. (2) The donor network detects that the dialed directory number has been ported out of the donor switch and checks with an internal network-specific NPDB. + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 9] +Number Portability in the GSTN: An Overview March 1, 2002 + + (3) The internal NPDB returns the routing number associated with the dialed directory number. (4) The donor network uses the routing number to route the call to @@ -527,14 +542,8 @@ Number Portability in the GSTN: An Overview October 19, 2001 Figure 4 - Onward Routing (OR) Scheme. - - Informational - Expiration in April 19, 2002 9 - -Number Portability in the GSTN: An Overview October 19, 2001 - - -5.5 Comparisons of the Four Schemes +4.5 Comparisons of the Four Schemes Only the ACQ scheme does not involve the donor network when routing the call to the new serving network of the dialed ported number. @@ -544,17 +553,17 @@ Number Portability in the GSTN: An Overview October 19, 2001 Only the OR scheme requires the setup of two physical call segments, one from the Originating Network to the donor network and the other from the donor network to the new serving network. The OR scheme is - the least efficient in terms of using the network resources. The - QoR and Dropback schemes set up calls to the donor network first but - release the call back to the Originating Network that then initiates - a new call to the Current Serving Network. For the QoR and Dropback - schemes, circuits are still reserved one by one between the - Originating Network and the donor network when the Originating - Network sets up the call towards the donor network. Those circuits - are released one by one when the call is released from the donor - network back to the Originating Network. The ACQ scheme is the most - efficient in terms of using the switching and transmission - facilities for the call. + the least efficient in terms of using the network transmission + facilities. The QoR and Dropback schemes set up calls to the donor + network first but release the call back to the Originating Network + that then initiates a new call to the Current Serving Network. For + the QoR and Dropback schemes, circuits are still reserved one by one + between the Originating Network and the donor network when the + Originating Network sets up the call towards the donor network. + Those circuits are released one by one when the call is released + from the donor network back to the Originating Network. The ACQ + scheme is the most efficient in terms of using the switching and + transmission facilities for the call. Both the ACQ and QoR schemes involve Centralized NPDBs for the Originating Network to retrieve the routing information. @@ -565,6 +574,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 numbers that were ported out of the donor network. The internal NPDB can be a stand-alone database that contains information about all or some ported-out numbers from the donor network. It can also + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 10] +Number Portability in the GSTN: An Overview March 1, 2002 + + reside on the donor switch and only contains information about those numbers ported out of the donor switch. In that case, no query to a stand-alone internal NPDB is required. The donor switch for a @@ -586,12 +600,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 Similarly, in other national E.164 numbering plans, number ranges cover a contiguous range of numbers within that range. Once a - - Informational - Expiration in April 19, 2002 10 - -Number Portability in the GSTN: An Overview October 19, 2001 - - number within that range has ported away from the donor network, all numbers in that range are considered potentially ported and should be queried in the NPDB. @@ -610,7 +618,7 @@ Number Portability in the GSTN: An Overview October 19, 2001 indicate "number ported out" before launching the NPDB query. -6. Database Queries in the NP Environment +5. Database Queries in the NP Environment As indicated earlier, the ACQ and QoR schemes require that a switch query the NPDB for routing information. Various standards have been @@ -624,7 +632,12 @@ Number Portability in the GSTN: An Overview October 19, 2001 routing number from the NPDB to the switch for call routing. -6.1 U.S. and Canada + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 11] +Number Portability in the GSTN: An Overview March 1, 2002 + + +5.1 U.S. and Canada One of the following five NPDB interfaces can be used to query an NPDB: @@ -644,13 +657,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 (b) Intelligent Network (IN), which is similar to the one used for querying the 800 databases. The IN protocol is carried on top of the protocol stack that includes the ANSI MTP Levels 1 - - - Informational - Expiration in April 19, 2002 11 - -Number Portability in the GSTN: An Overview October 19, 2001 - - through 3, ANSI SCCP, and ANSI TCAP. This interface can be used by the wireline or wireless switches. @@ -684,6 +690,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 accessed via an API locally or by a query to a remote NPDB using a proprietary protocol or the schemes described above. + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 12] +Number Portability in the GSTN: An Overview March 1, 2002 + + Wireline switches have the choice of using either (a), (b), or (e). IS-41 based wireless switches have the choice of using (a), (b), @@ -701,15 +712,9 @@ Number Portability in the GSTN: An Overview October 19, 2001 charge when calling a GSM directory number. -6.2 Europe +5.2 Europe One of the following three interfaces can be used to query an NPDB: - - Informational - Expiration in April 19, 2002 12 - -Number Portability in the GSTN: An Overview October 19, 2001 - - (a) Capability Set 1 (CS1) of the ITU-TS INAP [CS1], which is carried on top of the protocol stack that includes the ITU-TS @@ -743,6 +748,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 In most, if not all, cases in Europe, the calls to the wireless directory numbers are routed to the wireless donor network first. Over there, an internal NPDB is queried to determine whether the + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 13] +Number Portability in the GSTN: An Overview March 1, 2002 + + dialed wireless directory number has been ported out or not. In this case, the interface to the internal NPDB is not subject to standardization. @@ -752,10 +762,10 @@ Number Portability in the GSTN: An Overview October 19, 2001 MNP-SRF is used to modify the SCCP Called Party Address parameter in the GSM MAP messages so that they can be re-directed to the wireless serving network. Call routing involving MNP will be explained in - Section 7.2. + Section 6.2. -7. Call Routing in the NP Environment +6. Call Routing in the NP Environment This section discusses the call routing after the routing information has been retrieved either through an NPDB query or an @@ -763,12 +773,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 Services Digital Network User Part (ISUP) signaling message (e.g., for the Dropback scheme). For the ACQ, QoR and Dropback schemes, it is the Originating Network that has the routing information and is - - Informational - Expiration in April 19, 2002 13 - -Number Portability in the GSTN: An Overview October 19, 2001 - - ready to route the call. For the OR scheme, it is the donor network that has the routing information and is ready to route the call. @@ -786,7 +790,7 @@ Number Portability in the GSTN: An Overview October 19, 2001 were redundant queries performed downstream. -7.1 U.S. and Canada +6.1 U.S. and Canada In the U.S. and Canada, a ten-digit North American Numbering Plan (NANP) number called Location Routing Number (LRN) is assigned to @@ -801,6 +805,12 @@ Number Portability in the GSTN: An Overview October 19, 2001 the North America is very often referred to as the LRN scheme or method. + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 14] +Number Portability in the GSTN: An Overview March 1, 2002 + + LRN serves as a network address for terminating calls served off that switch using ported numbers. The LRN is assigned by the switch operator using any of the unique CO codes (NPA+NXX) assigned to that @@ -822,12 +832,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 Indicator (PNTI) bit, is set to imply that NPDB query has already been performed. All the switches in the downstream will not perform the NPDB query if the PNTI bit is set. - - Informational - Expiration in April 19, 2002 14 - -Number Portability in the GSTN: An Overview October 19, 2001 - - When the terminating switch receives the IAM and sees the PNTI bit in the FCI parameter set and its own LRN in the CdPN parameter, it @@ -852,13 +856,19 @@ Number Portability in the GSTN: An Overview October 19, 2001 support the NPDB interface at its mobile switches. -7.2 Europe +6.2 Europe In Europe, a routing number is prefixed to the dialed directory number. The ISUP CdPN parameter in the IAM will contain the routing prefix and the dialed directory number. For example, United Kingdom uses routing prefixes with the format of 5XXXXX and Italy uses C600XXXXX as the routing prefix. The networks use the information + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 15] +Number Portability in the GSTN: An Overview March 1, 2002 + + in the ISUP CdPN parameter to route the call to the New/Current Serving Network. @@ -881,12 +891,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 In addition to the addition of the routing prefix to the CdPN parameter, some other information may be added/modified as is listed - - Informational - Expiration in April 19, 2002 15 - -Number Portability in the GSTN: An Overview October 19, 2001 - - in the draft ITU-T Recommendation Q.769.1 [ISUP]. Those enhancements in the ISUP to support number portability are briefly described below. @@ -918,17 +922,24 @@ Number Portability in the GSTN: An Overview October 19, 2001 There is also a network option to add a new ISUP parameter called Number Portability Forwarding Information parameter. This parameter + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 16] +Number Portability in the GSTN: An Overview March 1, 2002 + + has a four-bit Number Portability Status Indicator field that can provide an indication whether number portability query is done for the called directory number and whether the called directory number is ported or not if the number portability query is done. - - Please note that all those enhancements are for national use. This - is because number portability is supported within a nation. Within - each nation, the telecommunications industry or the regulatory - bodies can decide which method or methods to use. Number - portability related parameters and coding are never passed across - the national boundaries. + + Please note that all those NP enhancements for a ported number can + only be used in the country that defined them. This is because + number portability is supported within a nation. Within each + nation, the telecommunications industry or the regulatory bodies can + decide which method or methods to use. Number portability related + parameters and coding are never passed across the national + boundaries. For example, a UK routing prefix can only be used in + UK, and would cause routing problem if it appears outside UK. As indicated earlier, an originating wireless network can query the NPDB and concatenate the RN with DN in the CdPN parameter and route @@ -940,12 +951,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 an internal NPDB is queried to retrieve the RN that then is concatenated with the DN in the CdPN parameter. - - Informational - Expiration in April 19, 2002 16 - -Number Portability in the GSTN: An Overview October 19, 2001 - - If MNP-SRF is supported, the Gateway Mobile Services Switching Center (GMSC) at the wireless donor network, when receiving a call from the wireline network, can send the GSM MAP Send Routing @@ -975,13 +980,16 @@ Number Portability in the GSTN: An Overview October 19, 2001 directory number. Please see [MNP] for details and additional scenarios. + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 17] +Number Portability in the GSTN: An Overview March 1, 2002 + + -8. NP Implementations for Geographic E.164 Numbers +7. NP Implementations for Geographic E.164 Numbers This section shows the known SPNP implementations worldwide. - - +-------------+----------------------------------------------------+ + Country + SPNP Implementation + +-------------+----------------------------------------------------+ @@ -999,12 +1007,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 + + its network. Telstra uses onward routing via an + + + on-switch solution. + +-------------+----------------------------------------------------+ - - Informational - Expiration in April 19, 2002 17 - -Number Portability in the GSTN: An Overview October 19, 2001 - - + Austria + Uses onward routing at the donor network. Routing + + + prefix is "86xx" where "xx" identifies the + + + recipient switch. + @@ -1036,6 +1038,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 + France + Uses onward routing. Routing prefix is "Z0xxx" + + + where "xxx" identifies the recipient switch. + +-------------+----------------------------------------------------+ + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 18] +Number Portability in the GSTN: An Overview March 1, 2002 + + + Germany + The originating network needs to do necessary + + + rerouting. Operators decide their own solution(s).+ + + Deutsche Telekom uses ACQ. Routing prefix is + @@ -1057,13 +1064,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 +-------------+----------------------------------------------------+ + Italy + Uses onward routing. Routing prefix is "C600xxxxx" + + + where "xxxxx" identifies the recipient switch. + - - - Informational - Expiration in April 19, 2002 18 - -Number Portability in the GSTN: An Overview October 19, 2001 - - + + Telecom Italia uses IN solution and other operators+ + + use on-switch solution. + +-------------+----------------------------------------------------+ @@ -1096,6 +1096,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 + Sweden + Standardized the ACQ but OR for operators without + + + IN. Routing prefix is "xxx" with NOA=8 or "394xxx" + + + with NOA=3 where "xxx" identifies the recipient + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 19] +Number Portability in the GSTN: An Overview March 1, 2002 + + + + network. But operators decide NP scheme to use. + + + Telia uses onward routing between operators. + +-------------+----------------------------------------------------+ @@ -1117,13 +1122,7 @@ Number Portability in the GSTN: An Overview October 19, 2001 +-------------+----------------------------------------------------+ - - Informational - Expiration in April 19, 2002 19 - -Number Portability in the GSTN: An Overview October 19, 2001 - - -9. Number Conservation Methods Enabled by NP +8. Number Conservation Methods Enabled by NP In addition to porting numbers NP provides the ability for number administrators to assign numbering resources to operators in smaller @@ -1141,7 +1140,7 @@ Number Portability in the GSTN: An Overview October 19, 2001 telephone number (ITN) pooling, respectively. -9.1 Block Pooling +8.1 Block Pooling Block Pooling refers to the process whereby the number administrator assigns a range of numbers defined by a logical sub-block of the @@ -1155,6 +1154,11 @@ Number Portability in the GSTN: An Overview October 19, 2001 Porting the sub-blocks from the block holder enables block pooling. Using the example above operator A is the block holder, as well as, + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 20] +Number Portability in the GSTN: An Overview March 1, 2002 + + the holder of the first sub-block, NXX+0000 to NXX+0999. The second sub-block, NXX+1000 to NXX+1999, is ported from operator A to operator B. The third sub-block, NXX+2000 to NXX+2999, is ported @@ -1171,17 +1175,10 @@ Number Portability in the GSTN: An Overview October 19, 2001 serving operator, sub-block holder, and block holder. -9.2 ITN Pooling +8.2 ITN Pooling ITN pooling refers to the process whereby the number administrator assigns individual telephone numbers to operators. Using the North - - - Informational - Expiration in April 19, 2002 20 - -Number Portability in the GSTN: An Overview October 19, 2001 - - American example, one block of 10,000 TNs can be divided into 10,000 ITNs. ITN is more commonly deployed in freephone services. @@ -1191,20 +1188,20 @@ Number Portability in the GSTN: An Overview October 19, 2001 and efficient routing. -10. Conclusion +9. Potential Implications There are three general areas of impact to IP telephony work-in- progress at IETF: - 1. Interoperation between NP in GSTN and IP telephony - 2. NP implementation or emulation in IP telephony - 3. Interconnection to NP administrative environment + - Interoperation between NP in GSTN and IP telephony + - NP implementation or emulation in IP telephony + - Interconnection to NP administrative environment A good understanding of how number portability is supported in the GSTN is important when addressing the interworking issues between IP based networks and the GSTN. This is especially important when the IP based network needs to route the calls to the GSTN. As shown in - Section 6, there are a variety of standards with various protocol + Section 5, there are a variety of standards with various protocol stacks for the switch-to-NPDB interface. Not only that, the national variations of the protocol standards make it very complicate to deal with in a global environment. If an entity in @@ -1214,6 +1211,12 @@ Number Portability in the GSTN: An Overview October 19, 2001 to support all those interface standards to access the NPDBs in many countries. + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 21] +Number Portability in the GSTN: An Overview March 1, 2002 + + Several alternatives may address this particular problem. One alternative is to use certain entities in the IP-based networks for dealing with NP query, similar to the International Switches that @@ -1234,13 +1237,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 another possibility is to use interworking function to convert from one protocol to another. - - - Informational - Expiration in April 19, 2002 21 - -Number Portability in the GSTN: An Overview October 19, 2001 - - IP-based networks can handle the domestic calls between two GSTNs. If the originating GSTN has performed NPDB query, SIP will need to transport and make use of some of the ISUP signaling information @@ -1259,7 +1255,7 @@ Number Portability in the GSTN: An Overview October 19, 2001 dip indicator may not be present because there are cases where routing number is added for routing the call even if NP is not involved. One issue is how to transport the NP related information - via SIP. The SIP Uniform Resource Locator (URL) is one mechanism. + via SIP. The SIP Universal Resource Locator (URL) is one mechanism. Another better choice may be to add an extension to the "tel" URL [TEL] that is also supported by SIP. If the called directory is +1- 202-533-1234, and its associated routing number is +1-202-544-0000, @@ -1273,6 +1269,12 @@ Number Portability in the GSTN: An Overview October 19, 2001 see [TELNP] for the proposed extensions to the "tel" URL to support NP and freephone service. Those extensions to the "tel" and "fax" URLs will be automatically supported by SIP because they can be + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 22] +Number Portability in the GSTN: An Overview March 1, 2002 + + carried as the optional parameters in the user portion of the "sip" URL. @@ -1285,7 +1287,7 @@ Number Portability in the GSTN: An Overview October 19, 2001 present in the "tel" URL in the SIP INVITE message, it instead of the called directory number should be used for making routing decisions. If "rn" is not present, then the dialed directory number - can be used as the routing number for making routing decisions. + can be used as the routing number for making routing decisions. Telephony Routing Information Protocol (TRIP) [TRIP] is a policy driven inter-administrative domain protocol for advertising the @@ -1293,13 +1295,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 for advertising attributes of the routes to those destinations. With the NP in mind, it is very important to know that it is the routing number, if present, not the called directory number that - - - Informational - Expiration in April 19, 2002 22 - -Number Portability in the GSTN: An Overview October 19, 2001 - - should be used to check against the TRIP tables for making the routing decisions. @@ -1315,7 +1310,7 @@ Number Portability in the GSTN: An Overview October 19, 2001 does not handle the overlap signaling and collect the complete called directory number. - The IETF enum working group has defined the use of Domain Name + The IETF enum working group is defining the use of Domain Name System (DNS) for identifying available services associated with a particular E.164 number [ENUM]. [ENUMPO] outlines the principles for the operation of a telephone number service that resolves @@ -1330,13 +1325,31 @@ Number Portability in the GSTN: An Overview October 19, 2001 the telephony service providers do not "own" or control the telephone numbers under the NP environment; therefore, they may not be the proper entities to have the authority for a given E.164 - number. Not only that, the donor network should not be relied on to - reach the delegated authority during the DNS process because there - is a regulatory requirement on NP in some countries. The delegated - authority for a given E.164 number is likely to be an entity - designated by the end user that owns/controls a specific telephone - number or a third-party designated by the end-user or by the - industry. + number. Not only that, there is a regulatory requirement on NP in + some countries that the donor network should not be relied on to + reach the delegated authority during the DNS process . The + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 23] +Number Portability in the GSTN: An Overview March 1, 2002 + + + delegated authority for a given E.164 number is likely to be an + entity designated by the end user that owns/controls a specific + telephone number or one that is designated by the service registrar. + + Since the telephony service providers may have the need to use ENUM + for their network-related services (e.g., map an E.164 number to a + HLR Identifier in wireless networks), their ENUM records must be + collocated with those of the telephony subscribers. If that is the + case, NP will impact ENUM when a telephony subscriber who has ENUM + service changes the telephony service provider. This is because + that the ENUM records from the new telephony service provider must + replace those from the old telephony service provider. To avoid the + NP impact on ENUM, it is recommended that the telephony service + providers use a different domain tree for their network-related + service. For example, if e164.arpa is chosen for ôend userö ENUM, a + domain tree different from e164.arpa should be used for ôcarrierö + ENUM. The IP-based networks also may need to support some forms of number portability in the future if E.164 numbers [E164] are assigned to @@ -1351,21 +1364,34 @@ Number Portability in the GSTN: An Overview October 19, 2001 be to assign a special routing number so that the call to an end user currently served by an IP entity is routed to the nearest GSTN gateway. The called directory number then is used to locate the IP- - entity that serves that dialed directory number. Then some - mechanisms are needed for the IP-based network to locate the IP + entity that serves that dialed directory number. A mechanism can be + developed or used for the IP-based network to locate the IP entity + that serves a particular dialed directory number. Many other types + of networks use E.164 numbers to identify the end users or terminals + in those networks. Number portability among GSTN, IP-based network + and those various types of networks may also need to be supported in + the future. + + +10. Security Considerations + + This document does not raise any security issues. + + + +11. IANA Considerations + + This document introduces no new values for IANA registration. + + + + - Informational - Expiration in April 19, 2002 23 - -Number Portability in the GSTN: An Overview October 19, 2001 +Foster,McGarry,Yu Expired on August 31, 2002 [Page 24] +Number Portability in the GSTN: An Overview March 1, 2002 - entity that serves a particular dialed directory number. ENUM can - be one of the mechanisms. Many other types of networks use E.164 - numbers to identify the end users or terminals in those networks. - Number portability among GSTN, IP-based network and those various - types of networks may also need to be supported in the future. - -11. References +12. Normative References [ANSI OSS] ANSI Technical Requirements No. 1, "Number Portability - Operator Services Switching Systems," April 1999. @@ -1389,10 +1415,6 @@ Number Portability in the GSTN: An Overview October 19, 2001 [ENUM] P. Falstrom, "E.164 number and DNS," RFC 2916. - [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific - Provisioning: Principles of Operations," draft-ietf-enum- - operation-02.txt, February 23, 2001. - [GSM] GSM 09.02: "Digital cellular telecommunications system (Phase 2+); Mobile Application Part (MAP) specification". @@ -1410,83 +1432,85 @@ Number Portability in the GSTN: An Overview October 19, 2001 Technical Realisation; Stage 2; (GSM 03.66 Version 7.2.0 Release 1998). - - - - Informational - Expiration in April 19, 2002 24 - -Number Portability in the GSTN: An Overview October 19, 2001 - - [RFC] Scott Bradner, RFC2026, "The Internet Standards Process -- Revision 3," October 1996. - [TEL] A. Vaha-Sipila, RFC2806, "URLs for Telephone Calls," April - 2000. - - [TELNP] J. Yu, draft-yu-tel-url-03.txt, "Extensions to the "tel" and - "fax" URLs to support Number Portability and Freephone - Service," November 1, 2001. - [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, RFC - 2543, "SIP: Session Initiation Protocl," March 1999. +13. Informative References + + [ENUMPO] A. Brown and G. Vaudreuil, "ENUM Service Specific + Provisioning: Principles of Operations," draft-ietf-enum- + operation-02.txt, February 23, 2001. - [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC XXX, "Telephony - Routing Information Protocol (TRIP)," September 2001. + [TEL] H. Schulzrinne and A. Vaha-Sipila, draft-antti-rfc2806bis- + 02.txt, "URIs for Telephone Calls," February 17, 2002. + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 25] +Number Portability in the GSTN: An Overview March 1, 2002 + + + + [SIP] J. Rosenberg, et al., draft-ietf-sip-rfc2543bis-08.txt, "SIP: + Session Initiation Protocol," February 21, 2002. + + [TELNP] J. Yu, draft-yu-tel-url-04.txt, "Extensions to the "tel" and + "fax" URLs to support Number Portability and Freephone + Service," March 1, 2002. + + [TRIP] J. Rosenberg, H. Salama and M. Squire, RFC 3219, "Telephony + Routing Information Protocol (TRIP)," January 2002. -12. Acknowledgments +14. Acknowledgment The authors would like to thank Monika Muench for providing reference information on ISUP and MNP. -13. Author's Addresses +15. Authors' Addresses Mark D. Foster NeuStar, Inc. 1120 Vermont Avenue, NW, - Suite 550 + Suite 400 Washington, D.C. 20005 United States Phone: +1-202-533-2800 - Fax: +1-202-533-2976 - Email: mark.foster@neustar.com + Fax: +1-202-533-2987 + Email: mark.foster@neustar.biz - Tom McGarry NeuStar, Inc. 1120 Vermont Avenue, NW, - Suite 550 + Suite 400 Washington, D.C. 20005 United States Phone: +1-202-533-2810 Fax: +1-202-533-2987 - + Email: tom.mcgarry@neustar.biz James Yu NeuStar, Inc. 1120 Vermont Avenue, NW, - Suite 550 + Suite 400 Washington, D.C. 20005 - - Informational - Expiration in April 19, 2002 25 - -Number Portability in the GSTN: An Overview October 19, 2001 - - United States Phone: +1-202-533-2814 Fax: +1-202-533-2987 - Email: james.yu@neustar.com + Email: james.yu@neustar.biz + + +Foster,McGarry,Yu Expired on August 31, 2002 [Page 26] +Number Portability in the GSTN: An Overview March 1, 2002 + Full Copyright Statement - - "Copyright (C) The Internet Society (date). All Rights Reserved. + "Copyright (C) The Internet Society (2002). 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 @@ -1498,8 +1522,24 @@ Full Copyright Statement 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. + 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. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. @@ -1512,26 +1552,10 @@ Full Copyright Statement - - - - - - - - - - - - - - - - Informational - Expiration in April 19, 2002 26 - \ No newline at end of file +Foster,McGarry,Yu Expired on August 31, 2002 [Page 27] \ No newline at end of file diff --git a/doc/draft/draft-schlyter-appkey-01.txt b/doc/draft/draft-schlyter-appkey-02.txt similarity index 54% rename from doc/draft/draft-schlyter-appkey-01.txt rename to doc/draft/draft-schlyter-appkey-02.txt index 3a06436a99..5e41523138 100644 --- a/doc/draft/draft-schlyter-appkey-01.txt +++ b/doc/draft/draft-schlyter-appkey-02.txt @@ -1,11 +1,11 @@ Network Working Group J. Schlyter Internet-Draft Carlstedt Research & -Expires: May 11, 2002 Technology - November 10, 2001 +Expires: August 7, 2002 Technology + February 6, 2002 Storing application public keys in the DNS - draft-schlyter-appkey-01.txt + draft-schlyter-appkey-02.txt Status of this Memo @@ -22,17 +22,17 @@ Status of this Memo 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 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. - This Internet-Draft will expire on May 11, 2002. + This Internet-Draft will expire on August 7, 2002. Copyright Notice - Copyright (C) The Internet Society (2001). All Rights Reserved. + Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract @@ -50,28 +50,29 @@ Abstract -Schlyter Expires May 11, 2002 [Page 1] +Schlyter Expires August 7, 2002 [Page 1] -Internet-Draft Application public keys in DNS November 2001 +Internet-Draft Application public keys in DNS February 2002 Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. The APPKEY resource record . . . . . . . . . . . . . . . . . 3 - 2.1 The APPKEY RDATA format . . . . . . . . . . . . . . . . . . 4 - 2.1.1 The protocol field . . . . . . . . . . . . . . . . . . . . . 4 - 2.1.2 Version number octet . . . . . . . . . . . . . . . . . . . . 4 - 2.1.3 Algorithm number specification . . . . . . . . . . . . . . . 5 - 2.2 Text representation of APPKEY RRs . . . . . . . . . . . . . 5 - 2.3 Owner names for APPKEY RRs . . . . . . . . . . . . . . . . . 5 - 3. Applicability Statement . . . . . . . . . . . . . . . . . . 5 - 4. Security considerations . . . . . . . . . . . . . . . . . . 5 - 5. IANA considerations . . . . . . . . . . . . . . . . . . . . 5 - References . . . . . . . . . . . . . . . . . . . . . . . . . 6 - Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 - A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 - Full Copyright Statement . . . . . . . . . . . . . . . . . . 8 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Comments on the KEY RR . . . . . . . . . . . . . . . . . . . . 3 + 2.1 The flag field . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.2 The protocol field . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The APPKEY resource record . . . . . . . . . . . . . . . . . . 3 + 3.1 The APPKEY RDATA format . . . . . . . . . . . . . . . . . . . 4 + 3.2 Algorithm number specification . . . . . . . . . . . . . . . . 4 + 3.3 Text representation of APPKEY RRs . . . . . . . . . . . . . . 4 + 3.4 Owner names for APPKEY RRs . . . . . . . . . . . . . . . . . . 4 + 4. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 + 5. Security considerations . . . . . . . . . . . . . . . . . . . 5 + 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 + References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 + A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 @@ -105,28 +106,29 @@ Table of Contents +Schlyter Expires August 7, 2002 [Page 2] -Schlyter Expires May 11, 2002 [Page 2] - -Internet-Draft Application public keys in DNS November 2001 +Internet-Draft Application public keys in DNS February 2002 1. Introduction The Domain Name System Security Extensions (DNSSEC) as described in - RFC 2535 [4] specifies the KEY resource record (RR). The KEY RR is + RFC 2535 [3] specifies the KEY resource record (RR). The KEY RR is specified for use both for storing keys used by the DNSSEC infrastructure itself and for storing keys used by non-DNSSEC infrastructure applications (e.g. TLS [2], email and IPsec). The issues with combining these two uses in one RR are further discussed - in draft-ietf-dnsext-restrict-key-for-dnssec-00 [11]. + in a draft called "Limiting the Scope of the KEY Resource Record" + [10]. - The protocol field in the KEY RR is only 8-bit and thus limited to - 256 different protocols. As there is no way of separating different - version of a specific protocol, incompatible versions of a single - protocol requires multiple protocol values. A larger protocol field - together with the possibility to specify a version of the protocol - could solve this issue. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + +2. Comments on the KEY RR + +2.1 The flag field The KEY RR includes a flag field that specifies key usage, what kind of entity the key is associated with and various other flags. As @@ -135,108 +137,73 @@ Internet-Draft Application public keys in DNS November 2001 application might need is hard to do, the usability of this field is questionable. +2.2 The protocol field + + The protocol field in the KEY RR is only 8-bit and thus limited to + 256 different protocols. As there is no way of separating different + version of a specific protocol, incompatible versions of a single + protocol requires multiple protocol values. A larger protocol field + together with the possibility to specify a version of the protocol + could solve this issue. + A problem with multiple applications storing their public keys at a single owner name and thus creating a very large RR set has been identified. A possible solution for this could be to use a generic - protocol value [10] indicating that the actual protocol used is + protocol value [9] indicating that the actual protocol used is indicated in the owner name using a SRV-like encoding. Although this would indeed solve the problem with large RR sets when querying for an application key, it could also make the protocol field lose its value in practice as new applications would not require a new - protocol value. The author believes that combining unique protocol - values with SRV-like encode of protocol would be a better solution, - solving both the issue with large RR sets and a large number of - possible applications. + protocol value. - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [1]. - -2. The APPKEY resource record +3. The APPKEY resource record The APPKEY resource record (RR) is used to store a application public + + + +Schlyter Expires August 7, 2002 [Page 3] + +Internet-Draft Application public keys in DNS February 2002 + + key that is associated with a Domain Name System (DNS) name. The RR type code for the APPKEY RR is TBA. - - - -Schlyter Expires May 11, 2002 [Page 3] - -Internet-Draft Application public keys in DNS November 2001 - - An APPKEY RR is, like any other RR, authenticated by a SIG RR. -2.1 The APPKEY RDATA format +3.1 The APPKEY RDATA format - The RDATA for an APPKEY RR consists of a protocol field, a version - number octet, the algorithm number octet and the public key itself. - The format is as follows: + The RDATA for an APPKEY RR consists of an algorithm number octet and + the public key itself. The format is as follows: 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | protocol | version | algorithm | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / + | algorithm | / + +---------------+ public key / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - The meaning of the APPKEY RR owner name, protocol field, version - number octet and algorithm number octet are described in the sections - below. The format of the public key is algorithm dependent. + The meaning of the APPKEY RR owner name and algorithm number octet + are described in the sections below. The format of the public key is + algorithm dependent. APPKEY RRs do not specify their validity period but their - authenticating SIG RR(s) do as described in RFC 2535 [4]. + authenticating SIG RR(s) do as described in RFC 2535 [3]. -2.1.1 The protocol field - - The protocol field specifies what protocol the public key is to be - used for. The following values of the protocol field are available: - - Value Protocol - ----- -------- - 0x0000 reserved - 0x0001 - 0xFEFF available for assignment by IANA - 0xFF00 - 0xFFFE experimental uses - 0xFFFF any protocol - - 0xFFFF indicates that the key can be used in connection with any - protocol. Use of this value is discouraged and the use of unique - protocol values for different protocols is encouraged. - -2.1.2 Version number octet - - The version number octet is defined by the protocol specified in the - protocol field. It is up to the application implementing the - specified protocol to interpret the value of this octet. - - Any document specifying how a protocol uses APPKEY MUST specify how - - - -Schlyter Expires May 11, 2002 [Page 4] - -Internet-Draft Application public keys in DNS November 2001 - - - to specify and interpret the version number octet. - -2.1.3 Algorithm number specification +3.2 Algorithm number specification The algorithm number used is the same as defined for the KEY RR - described in RFC 2535 [4]. + described in RFC 2535 [3]. -2.2 Text representation of APPKEY RRs +3.3 Text representation of APPKEY RRs - The RDATA portion of an APPKEY RR has the protocol field, version - number octet and algorithm number octet represented as unsigned - integers. + The RDATA portion of an APPKEY RR has the algorithm number octet + represented as unsigned integers. - The public key fields is represented in base 64 [9] and may be + The public key fields is represented in base 64 [8] and may be divided up into any number of white space separated substrings, down to single base 64 digits, which are concatenated to obtain the full public key. These substrings can span lines using the standard @@ -244,50 +211,46 @@ Internet-Draft Application public keys in DNS November 2001 have internal sub-fields, these do not appear in the master file representation. -2.3 Owner names for APPKEY RRs +3.4 Owner names for APPKEY RRs - The owner name of the APPKEY RR is defined per application. This can - be, but is not limited to, the domain name of the host the - application is running at (e.g. host.example.com) or a name matching - the SRV RR [6] for the service (e.g. _ssh._tcp.host.example.com). + The owner name of the APPKEY RR is defined per application and SHOULD + be defined in such a way that it is possible to query for a single -3. Applicability Statement + + +Schlyter Expires August 7, 2002 [Page 4] + +Internet-Draft Application public keys in DNS February 2002 + + + application APPKEY. This can be, but is not limited to, the domain + name of the host the application is running at (e.g. + host.example.com) combined with a protocol identifier. A name + matching the SRV RR [5] for the service (e.g. + _service._protocol.host.example.com) could be a good starting point + for this naming. + +4. Applicability Statement The APPKEY resource record (RR) are only intended for storage of public keys - private keys MUST NOT be stored in an APPKEY RR. The APPKEY RR is not intended for storage of certificates and a - separate certificate RR, defined in RFC 2538 [5], has been developed + separate certificate RR, defined in RFC 2538 [4], has been developed for that purpose. -4. Security considerations +5. Security considerations Public keys from an APPKEY RR, SHOULD NOT be trusted unless the APPKEY was authenticated by a trusted SIG RR. Applications that do - not validate the signatures by themselves are advised to use TSIG [7] - or SIG(0) [8] to protect the transport between themselves and the + not validate the signatures by themselves are advised to use TSIG [6] + or SIG(0) [7] to protect the transport between themselves and the name server doing the signature validation. -5. IANA considerations +6. IANA considerations IANA needs to allocate a RR type code for APPKEY from the standard RR - - - -Schlyter Expires May 11, 2002 [Page 5] - -Internet-Draft Application public keys in DNS November 2001 - - - type space. - - Protocol values 0x0000 and 0xFFFF are reserved. - - Protocol values 0x0001 through 0xFEFF are allocated based on - "Specification Required" as defined in RFC 2434 [3]. - - XXX should the protocol values be divided into different ranges for - IETF Standard Action, IETF consensus and Specification Required ? + type space. No other IANA services are required by this document. References @@ -298,44 +261,40 @@ References P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. - [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October - 1998. - - [4] Eastlake, D., "Domain Name System Security Extensions", RFC + [3] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. - [5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the + [4] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. - [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + [5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. - [7] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + + + +Schlyter Expires August 7, 2002 [Page 5] + +Internet-Draft Application public keys in DNS February 2002 + + + [6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000. - [8] Eastlake, D., "DNS Request and Transaction Signatures ( + [7] Eastlake, D., "DNS Request and Transaction Signatures ( SIG(0)s)", RFC 2931, September 2000. - [9] Josefsson, S., "Base Encodings", work in progress draft- - josefsson-base-encoding-02, May 2001. + [8] Josefsson, S., "Base Encodings", work in progress draft- + josefsson-base-encoding-03, November 2001. - [10] Lewis, E., "DNS KEY Resource Record Generic Protocol Value", + [9] Lewis, E., "DNS KEY Resource Record Generic Protocol Value", work in progress draft-lewis-dnsext-key-genprot-00, July 2001. - [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + [10] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record", work in progress draft-ietf-dnsext-restrict-key-for- - - - -Schlyter Expires May 11, 2002 [Page 6] - -Internet-Draft Application public keys in DNS November 2001 - - - dnssec-00, November 2001. + dnssec-01, January 2002. Author's Address @@ -360,6 +319,7 @@ Appendix A. Acknowledgements Edward Lewis + Dan Massey @@ -370,30 +330,14 @@ Appendix A. Acknowledgements +Schlyter Expires August 7, 2002 [Page 6] - - - - - - - - - - - - - - - -Schlyter Expires May 11, 2002 [Page 7] - -Internet-Draft Application public keys in DNS November 2001 +Internet-Draft Application public keys in DNS February 2002 Full Copyright Statement - Copyright (C) The Internet Society (2001). All Rights Reserved. + Copyright (C) The Internet Society (2002). 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 @@ -442,6 +386,6 @@ Acknowledgement -Schlyter Expires May 11, 2002 [Page 8] +Schlyter Expires August 7, 2002 [Page 7] diff --git a/doc/draft/draft-schlyter-pkix-dns-00.txt b/doc/draft/draft-schlyter-pkix-dns-01.txt similarity index 80% rename from doc/draft/draft-schlyter-pkix-dns-00.txt rename to doc/draft/draft-schlyter-pkix-dns-01.txt index 450cd45490..6b088466d5 100644 --- a/doc/draft/draft-schlyter-pkix-dns-00.txt +++ b/doc/draft/draft-schlyter-pkix-dns-01.txt @@ -1,13 +1,13 @@ -Network Working Group J. Schlyter +PKIX Working Group J. Schlyter Internet-Draft Carlstedt Research & -Expires: May 3, 2002 Technology +Expires: August 29, 2002 Technology L. Johansson Stockholm University - November 2, 2001 + February 28, 2002 DNS as X.509 PKIX Certificate Storage - draft-schlyter-pkix-dns-00 + draft-schlyter-pkix-dns-01 Status of this Memo @@ -24,17 +24,17 @@ Status of this Memo 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 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. - This Internet-Draft will expire on May 3, 2002. + This Internet-Draft will expire on August 29, 2002. Copyright Notice - Copyright (C) The Internet Society (2001). All Rights Reserved. + Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract @@ -50,9 +50,9 @@ Abstract -Schlyter & Johansson Expires May 3, 2002 [Page 1] +Schlyter & Johansson Expires August 29, 2002 [Page 1] -Internet-Draft DNS PKIX storage November 2001 +Internet-Draft DNS PKIX storage February 2002 Table of Contents @@ -106,9 +106,9 @@ Table of Contents -Schlyter & Johansson Expires May 3, 2002 [Page 2] +Schlyter & Johansson Expires August 29, 2002 [Page 2] -Internet-Draft DNS PKIX storage November 2001 +Internet-Draft DNS PKIX storage February 2002 1. Introduction @@ -132,10 +132,13 @@ Internet-Draft DNS PKIX storage November 2001 2. Storing PKIX certificates in DNS A PKIX certificate is published in DNS using the CERT RR [5] for a - given domain name which MUST be equal to the dnsName component of the - subjectAltName extension in the certificate. Multiple certificates - may be present for each domain name and all SHOULD have the same - subject DN. + given domain name which SHOULD be equal to the dnsName component of + the subjectAltName extension in the certificate. Multiple + certificates may be present for each domain name and all SHOULD have + the same subject DN. If the domain name does not match the dnsName + component of the subjectAltName extension the client SHOULD notify + the user of this and allow the user to decide weather to allow the + use of the certificate or not. When constructing a certificate path for validation the client MAY use the AuthorityKeyIdentifier and SubjectKeyIdentifier extensions to @@ -159,12 +162,9 @@ Internet-Draft DNS PKIX storage November 2001 +Schlyter & Johansson Expires August 29, 2002 [Page 3] - - -Schlyter & Johansson Expires May 3, 2002 [Page 3] - -Internet-Draft DNS PKIX storage November 2001 +Internet-Draft DNS PKIX storage February 2002 3. Certificate lookup algorithm @@ -172,7 +172,7 @@ Internet-Draft DNS PKIX storage November 2001 Given a certificate with a non-empty issuerAltName extension of type dnsName, perform a DNS lookup of the corresponding domain name with the class IN and type CERT. For each of the certificates returned - that are of type PKIX, implementations MUST verify that the + that are of type PKIX, implementations SHOULD verify that the subjectAltName in the certificate contains a component of type dnsName with the same domain name as the one where the certificate was published using the DNS. @@ -218,9 +218,9 @@ References -Schlyter & Johansson Expires May 3, 2002 [Page 4] +Schlyter & Johansson Expires August 29, 2002 [Page 4] -Internet-Draft DNS PKIX storage November 2001 +Internet-Draft DNS PKIX storage February 2002 Authors' Addresses @@ -237,9 +237,14 @@ Authors' Addresses Leif Johansson Stockholm University + IT and Media Unit + Frescati Hagvag 8 + Stockholm SE-106 91 + Sweden Phone: +46 8 16 45 41 EMail: leifj@it.su.se + URI: http://www.it.su.se Appendix A. Acknowledgements @@ -250,6 +255,7 @@ Appendix A. Acknowledgements Niklas Hallqvist + Edward Lewis @@ -268,20 +274,14 @@ Appendix A. Acknowledgements +Schlyter & Johansson Expires August 29, 2002 [Page 5] - - - - - -Schlyter & Johansson Expires May 3, 2002 [Page 5] - -Internet-Draft DNS PKIX storage November 2001 +Internet-Draft DNS PKIX storage February 2002 Full Copyright Statement - Copyright (C) The Internet Society (2001). All Rights Reserved. + Copyright (C) The Internet Society (2002). 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 @@ -330,6 +330,6 @@ Acknowledgement -Schlyter & Johansson Expires May 3, 2002 [Page 6] +Schlyter & Johansson Expires August 29, 2002 [Page 6]