[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

  INTERNET-DRAFT                                             Eric A. Hall
  Document: draft-ietf-crisp-lw-dns-00.txt                      July 2002
  Expires: January, 2003
  Category: Standards-Track
  
  
                      Defining and Locating DNS Domains
                  using the Internet Resource Query Service
  
  
     Status of this Memo
  
     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC 2026.
  
     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups. Note that
     other groups may also distribute working documents as Internet-
     Drafts.
  
     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other
     documents at any time. It is inappropriate to use Internet-Drafts
     as reference material or to cite them other than as "work in
     progress."
  
     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt
  
     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.
  
  
  1.      Abstract
  
     This document defines LDAP schema and searching rules for DNS
     domains, in support of the Internet Resource Query Service
     described in [ldap-whois].
  
  
  
  
  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
  
  2.      Definitions and Terminology
  
     This document unites, enhances and clarifies several pre-existing
     technologies. Readers are expected to be familiar with the
     following specifications:
  
            RFC 2247 - Using Domains in LDAP/X.500 DNs
  
            RFC 2251 - Lightweight Directory Access Protocol (v3)
  
            RFC 2252 - Lightweight Directory Access Protocol (v3):
            Attribute Syntax Definitions.
  
            RFC 2254 - The String Representation of LDAP Search Filters
  
            [ir-dir-req] - <draft-newton-ir-dir-requirements-00.txt> -
            Internet Registry Directory Requirements
  
            [ldap-whois] - <draft-ietf-crisp-lw-core-00.txt> - The
            Internet Resource Query Service and the Internet Resource
            Schema
  
     The following abbreviations are used throughout this document:
  
            DIT (Directory Information Tree) - A DIT is a contained
            branch of the LDAP namespace, having a root of a particular
            distinguished name. "dc=example,dc=com" is used throughout
            this document as one DIT, with many example entries being
            stored in this DIT.
  
            DN (Distinguished Name) - A distinguished name provides a
            unique identifier for an entry, through the use of a multi-
            level naming syntax. Entries are named according to their
            location relevant to the root of their containing DIT. For
            example, "cn=inetResources,dc=example,dc=com" is a DN which
            uniquely identifies the "inetResources" entry within the
            "dc=example,dc=com" DIT.
  
            RDN (Relative DN) - An RDN provides a locally-scoped unique
            identifier for an entry. A complete, globally-unique DN is
            formed by concatenating the RDNs of an entry together. For
            example, "cn=admins,cn=inetResources,dc=example,dc=com"
            consists of two RDNs ("cn=admins" and "cn=inetResources")
            within the "dc=example,dc=com" DIT. RDNs are typically only
            referenced within their local scope.
  
  Hall & Newton          I-D Expires: August 2002              [page 2]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
  
            OID (Object Identifier) - An OID is a globally-unique,
            concatenated set of integers which provide a kind of
            "serial number" to attributes, object classes, syntaxes and
            other schema elements.
  
     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.
  
  
  3.      The inetDnsDomain Object Class
  
     The inetDnsDomain object class is a structural object class which
     provides administrative information about a specific DNS domain
     name resource, such as a zone, a well-known host, or some other
     network resource which is primarily identified by a domain name.
  
  
  3.1.    Naming syntax
  
     The naming syntax for DNS domain entries MUST follow the form of
     "cn=<inetDnsDomainSyntax>,cn=inetResources,<dc-DIT>". Each DNS
     domain name which is managed as a discrete LDAP-WHOIS resource
     MUST have a dedicated entry in each of the DITs which provide
     public LDAP-WHOIS data for that resource.
  
     The inetDnsDomainSyntax component of an entry is subject to DN
     rules, although the inetDnsDomainSyntax is also used for extended
     search operations, and is therefore subject to specific syntax
     rules. The basic rules for this format are that domain names MUST
     be stored as sequences of labels, where each label consists of a
     maximum of 63 characters, with each label being separated by a
     full-stop (period) character, and with the entire domain name
     sequence being a maximum of 255 characters.
  
     For example, the "www.example.com" DNS domain name resource stored
     in the "dc=example,dc=com" DIT would be represented as an entry
     named "cn=www.example.com,cn=inetResources,dc=example,dc=com",
     while the "2.0.192.in-addr.arpa" reverse-lookup domain which was
     stored in the "dc=example,dc=com" DIT would be named
     "cn=2.0.192.in-addr.arpa,cn=inetResources,dc=example,dc=com".
  
     Note that the domain name syntax rules defined by STD 13 allow any
     eight-bit character code to be used within any domain name,
     although the host naming rules defined by RFC 952, STD 13 and STD
  
  Hall & Newton          I-D Expires: August 2002              [page 3]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
     3 only allow a subset of the printable characters from US-ASCII to
     be used for domain names which specify connection targets.
     However, many domain names will need to be queried which will not
     conform to the host naming rules ("_ldap._tcp.example.com" might
     be specified in a search, for example), so any eight-bit character
     MUST be considered valid for this service.
  
     RFC 2253 defines several escaping mechanisms for use when handling
     certain "special" characters, and these mechanisms MUST be used
     whenever a character in a domain name needs to be escaped in order
     for an assertion value to be parsed. However, STD 13 also allows
     the use of special characters, and also provides several
     mechanisms for escaping special characters in DNS domain names,
     and these rules MUST also be accommodated if valid DNS names are
     to be supported.
  
     In order to facilitate this potential overlap while minimizing
     confusion during handling, LDAP-WHOIS clients MUST allow DNS
     domain name query strings to be entered as raw eight-bit data, but
     if any of the characters need to be escaped for the assertion
     value to be properly built, then the client MUST escape these
     characters before the search is submitted.
  
     Secondarily, if the user needs to search for a DNS domain name
     which would normally require escaping or other special handling in
     order for the domain name to be processed, then the user MUST
     provide the domain name in its escaped form. By extension, this
     also means that these DNS domain names MUST be stored as RDNs in
     their escaped form.
  
     STD 13 and RFC 2253 both use a common method of escaping special
     characters with a reverse solidus (backslash) character, with
     either the special character or a two-digit decimal code for that
     character immediately following the reverse solidus.
  
     For example, if a user needs to specify the domain name of
     "weird name.example.com" (where "weird name" is a valid domain
     name label with an embedded space), then the domain name would
     have an RDN of "cn=weird\32name.example.com" in the directory, and
     would have to be entered into the client as a search for
     "weird\32name.example.com". The client would then perform a
     secondary escape to form "weird\\32name.example.com" as the
     assertion value, and this secondary escape would be removed by the
     LDAP-WHOIS server upon receipt. Thus a match would be found.
  
  
  Hall & Newton          I-D Expires: August 2002              [page 4]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
            NOTE: Remember that IPv4 addresses are also stored in DNS
            for reverse-lookup purposes, and the associated zones and
            PTR domain names may also require escaping, particularly
            when used with site-specific CIDR notation.
  
     The common reference to the root domain is a single full-stop
     (".") character, and this usage is also endorsed by this document
     when the root domain name needs to be explicitly queried. For any
     domain name which contains a non-root label, the trailing period
     which normally signifies the root domain MUST be omitted. The
     maximum size of a valid DNS domain name is 255 characters (this
     limit applies to the unescaped assertion value). Clients MUST
     restrict input to this range, prior to submitting the LDAP query.
  
     The domain name component of the DN MUST match the domain name of
     the managed resource exactly as the domain name exists in the DNS
     namespace. For example, if an organization wishes to provide
     information about "www.example.com", then a RDN entry would need
     to exist for "cn=www.example.com". If an organization wishes to
     provide information about the "www.example.com" canonical target
     "server1.example.net", then a RDN for "cn=server1.example.net"
     would need to exist. If an organization wishes to provide
     information about "server1.example.net" whenever a query is
     received for "www.example.com", then the "cn=www.example.com"
     entry would need to be defined as a subordinate reference
     referral, with the ref attribute pointing to the
     "cn=server1.example.net" entry.
  
     This usage model also applies to reverse-lookup domains. If an
     organization is the authority for the "2.0.192.in-addr.arpa"
     reverse-lookup domain associated with an IPv4 network (this is
     different from providing information about the network block in
     particular, as is discussed separately in [ldap-whois-ipv4] and
     [ldap-whois-ipv6], then that syntax would also be used to form the
     RDN for the associated inetDnsDomain entry.
  
     Note that reverse-lookup domain names are mapped directly as they
     exist in the public DNS namespace. If a /24 IPv4 network block
     such as 192.0.2.0 has been delegated to an organization, the
     default controlling domain name of the reverse-lookup zone will be
     2.0.192.in-addr.arpa, and the name of the associated LDAP-WHOIS
     entry would be "cn=2.0.192.in-addr.arpa". However, if that network
     had been delegated to an ISP who had in turn delegated the
     192.0.2.0/29 address block and an associated reverse-lookup zone
     of 29-0.2.0.192.in-addr.arpa to a user, then the associated LDAP-
     WHOIS entry for that zone would be "cn=29-0.2.0.192.in-addr.arpa".
  
  Hall & Newton          I-D Expires: August 2002              [page 5]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
  
  
  3.2.    Schema definition
  
     DNS domain name entries MUST exist with the top, inetResources and
     inetDnsDomain object classes defined. If an entry exists as a
     referral, the entry MUST also be defined with the referral object
     class, in addition to the above requirements.
  
     The inetDnsDomain object class is a structural object class which
     is subordinate to the inetResources object class, and which MUST
     be treated as a container class capable of holding additional
     subordinate entries. The inetDnsDomain object class has no
     mandatory attributes, although it does have several optional
     attributes.
  
     The inetDnsDomain object class defines attributes which are
     specific to DNS domains, particularly as this relates to domain
     delegation (DNS operational information is available through DNS
     itself). This includes information such as the delegation date and
     the status of the delegation. The inetDnsDomain object class is
     subordinate to the inetResources object class, so it inherits
     those attributes as well.
  
     Some of the inetDnsDomain object class attributes define contact-
     related referrals which provide LDAP URLs that refer to
     inetOrgPerson entries, and these entries will need to be queried
     separately if detailed information about a particular contact is
     required. The contact attribute values follow the same rules as
     the labeledURI attribute defined in RFC 2079, with additional
     restrictions described in [ldap-whois].
  
     The various ModifiedBy and ModifiedDate attributes SHOULD be
     treated as operational attributes. Their values SHOULD be filled
     in automatically by the database management application, and
     SHOULD NOT be returned except when explicitly requested.
  
  Hall & Newton          I-D Expires: August 2002              [page 6]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
  
     The schema definition for the inetDnsDomain object class is as
     follows:
  
          inetDnsDomain
          ( 1.3.6.1.4.1.7161.1.1.0 NAME 'inetDnsDomain' DESC 'DNS
            domain attributes.' SUP inetResources STRUCTURAL MAY (
            inetDnsDelegationStatus $ inetDnsDelegationDate $
            inetDnsDelegationModifiedDate $ inetDnsDelegationModifiedBy
            $ inetDnsContacts $ inetDnsContactsModifiedBy $
            inetDnsContactsModifiedDate $ inetDnsAuthServers ) )
  
     The attributes from the inetDnsDomain object class are described
     below:
  
          inetDnsAuthServers
          ( 1.3.6.1.4.1.7161.1.1.2 NAME 'inetDnsAuthServers' DESC
            'Authoritative DNS servers for this domain.' EQUALITY
            caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
  
            The inetDnsAuthServers attribute provides a read-only
            summary of the authoritative servers associated with the
            zone. The attribute is defined as multi-valued, with each
            attribute value currently (tentatively) being defined as:
  
                 domain.dom [address/prefix]
  
            where "domain.dom" is the domain name of the authoritative
            server, written as an inetDnsDomainSyntax string, and where
            "address/prefix" is an IPv4 or IPv6 host-specific network
            address, written as either an inetIpv4NetworkSyntax or
            inetIpv6NetworkSyntax string. Clients that wish to obtain
            additional information about the listed servers can issue
            new queries for either the domain name or address syntax.
  
            NOTE: THIS IS A TEMPORARY ATTRIBUTE WHICH WILL EVENTUALLY
            BE REPLACED WITH GENERALIZED RESOURCE-RECORD ENTRIES AND
            ATTRIBUTES.
  
          inetDnsContacts
          ( 1.3.6.1.4.1.7161.1.1.3 NAME 'inetDnsContacts' DESC
            'Contacts for reporting problems with this domain name.'
            EQUALITY caseExactMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.15 )
  
  
  Hall & Newton          I-D Expires: August 2002              [page 7]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
          inetDnsContactsModifiedBy
          ( 1.3.6.1.4.1.7161.1.1.4 NAME 'inetDnsContactsModifiedBy'
            DESC 'Person who last modified the inetDnsContacts
            attribute.' EQUALITY distinguishedNameMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetDnsContactsModifiedDate
          ( 1.3.6.1.4.1.7161.1.1.5 NAME 'inetDnsContactsModifiedDate'
            DESC 'Last modification date of the inetDnsContacts
            attribute.' EQUALITY generalizedTimeMatch ORDERING
            generalizedTimeOrderingMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetDnsDelegationDate
          ( 1.3.6.1.4.1.7161.1.1.6 NAME 'inetDnsDelegationDate' DESC
            'Date of original delegation.' EQUALITY
            GeneralizedTimeMatch ORDERING generalizedTimeOrderingMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
  
          inetDnsDelegationModifiedBy
          ( 1.3.6.1.4.1.7161.1.1.7 NAME 'inetDnsDelegationModifiedBy'
            DESC 'Person who last modified the  inetDnsDelegationStatus
            attribute.' EQUALITY distinguishedNameMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetDnsDelegationModifiedDate
          ( 1.3.6.1.4.1.7161.1.1.8 NAME 'inetDnsDelegationModifiedDate'
            DESC 'Last modification date of the inetDnsDelegationStatus
            attribute.' EQUALITY generalizedTimeMatch ORDERING
            generalizedTimeOrderingMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetDnsDelegationStatus
          ( 1.3.6.1.4.1.7161.1.1.9 NAME 'inetDnsDelegationStatus' DESC
            'Current delegation status code for this domain.' EQUALITY
            numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{2}
            SINGLE-VALUE )
  
            NOTE: In an effort to facilitate internationalization and
            programmatic processing, the current status of a delegation
            is identified by a 16-bit integer. The values and status
            mapping is as follows:
  
  Hall & Newton          I-D Expires: August 2002              [page 8]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
  
                 0   Reserved delegation (permanently inactive)
                 1   Assigned and active (normal state)
                 2   Assigned but not yet active (new delegation)
                 3   Assigned but on hold (disputed)
                 4   Assignment revoked (database purge pending)
  
            Additional values for the inetDnsDelegationStatus attribute
            are reserved for future use, and are to be administered by
            IANA. Note that there is no status code for "unassigned";
            unassigned entries SHOULD NOT exist, and SHOULD NOT be
            returned as answers.
  
     The inetDnsDomainSyntax syntax is as follows:
  
          inetDnsDomainSyntax
          ( 1.3.6.1.4.1.7161.1.1.1 NAME 'inetDnsDomainSyntax' DESC 'A
            fully-qualified DNS domain name.' )
  
  
  3.3.    Example
  
     An example of the inetDnsDomain object class in use is shown in
     Figure 1 below, with some additional attributes inherited from the
     parent inetResources entry. This query is most likely being sent
     to the LDAP servers responsible for operating the "example.com"
     DNS domain.
  
          cn=example.com,cn=inetResources,dc=example,dc=com
          [top object class]
          [inetResources object class]
          [inetDnsDomain object class]
          |
          +-attribute: description
          | value: "The example.com DNS domain"
          |
          +-attribute: inetDnsContacts
          | value: "ldap://ldap.example.com/cn=hostmaster,ou=admins,
          |           dc=example,dc=com"
          |
          +-attribute: inetGeneralContacts
            value: "ldap://ldap.example.com/cn=admins,ou=admins,
                      dc=example,dc=com"
  
     Figure 1: The example.com inetDnsDomain entry.
  
  
  Hall & Newton          I-D Expires: August 2002              [page 9]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
  
  4.      The inetDnsDomainMatch Filter
  
     The inetDnsDomainMatch filter provides an identifier and search
     string format which collectively inform a queried server that a
     specific DNS domain name should be searched for, and that any
     matching inetDnsDomain object class entries should be returned.
  
     The inetDnsDomainMatch extensibleMatch filter is defined as
     follows:
  
          inetDnsDomainMatch
          ( 1.3.6.1.4.1.7161.1.1.9 NAME 'inetDnsDomainMatch' SYNTAX
            inetDnsDomainSyntax )
  
     The assertion value MUST be a valid DNS domain name, using the
     inetDnsDomainSyntax syntax rules defined in section 3.
  
     The server MUST compare the assertion value against the RDN of all
     entries in the inetResources container which have an object class
     of inetDnsDomain. Any entry for a DNS domain resource which is
     clearly superior to the DNS domain name provided in the input
     string MUST be returned to the client. Entries which do not
     encompass the queried domain name MUST NOT be returned. Entries
     which do not have an object class of inetDnsDomain MUST NOT be
     returned.
  
     For example, assume that the client has issued a query with the
     assertion value of "www.example.com". If the queried server has an
     inetDnsDomain object class entry with a DN of
     "cn=example.com,cn=inetResources,dc=com", then that entry would be
     returned to the client. Similarly, a continuation reference
     referral of "cn=cref1,cn=example.com,cn=inetResources,dc=com"
     would also be returned, since it has a "cn" component that is
     superior to the queried domain name, and has the inetDnsDomain
     object class.
  
     Domain names MUST be compared on label boundaries, and MUST NOT be
     qualified through simple character matching. Given two entries of
     "cn=example.com" and "cn=an-example.com", only the first would
     match an assertion value of "example.com".
  
     Using the notation format described in RFC 2254, the search filter
     expression for the inetDnsDomainMatch query above would be written
     as "(1.3.6.1.4.1.7161.1.1.9:=www.example.com)".
  
  
  Hall & Newton          I-D Expires: August 2002             [page 10]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
     Response entries MAY be fully-developed inetDnsDomain entries, or
     MAY be referrals generated from entries which have the
     inetDnsDomain and referral object classes defined. Any attribute
     values which are received MUST be displayed by the client. If a
     subordinate reference referral is received, the client MUST
     restart the query, using the provided data as the new search base.
     If any continuation reference referrals are received, the client
     SHOULD start new queries for each reference, and append the output
     of those queries to the original query's output.
  
  5.      Security Considerations
  
     This document describes an application of the LDAPv3 protocol, and
     as such it inherits the security considerations associated with
     LDAPv3, as described in section 7 of RFC 2251.
  
     By nature, LDAP is a read-write protocol, while the legacy WHOIS
     service has always been a read-only service. As such, there are
     significant risks associated with allowing unintended updates by
     unauthorized third-parties. Moreover, allowing the LDAP-WHOIS
     service to update the underlying delegation databases could result
     in network resources being stolen from their lawful operators. For
     example, if the LDAP front-end had update access to a domain
     delegation database, a malicious third-party could theoretically
     take ownership of that domain by exploiting an authentication
     weakness, thereby causing ownership of the domain to be changed to
     another party. For this reason, it is imperative that the LDAP-
     WHOIS service not be allowed to make critical modifications to
     delegated resources without ensuring that all possible precautions
     have been taken.
  
     The query processing models described in this document make use of
     DNS lookups in order to locate the LDAP servers associated with a
     particular resource. DNS is susceptible to certain attacks and
     forgeries which may be used to redirect clients to LDAP servers
     which are not authoritative for the resource in question.
  
     Some operators may choose to purposefully provide misleading or
     erroneous information in an effort to avoid responsibility for bad
     behavior. In addition, there are likely to be sporadic operator
     errors which will result in confusing or erroneous answers.
  
     This document provides multiple query models which will cause the
     same query to be answered by different servers (one would be
     processed by a delegation entity, while another would be processed
     by an operational entity). As a result, each of the servers may
  
  Hall & Newton          I-D Expires: August 2002             [page 11]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
     provide different information, depending upon the query type that
     was originally selected.
  
     For all of the reasons listed above, it is essential that
     applications and end-users not make critical decisions based on
     the information provided by the LDAP-WHOIS service without having
     reason to believe the veracity of the information. Users should
     limit unknown or untrusted information to routine purposes.
  
     Finally, there are physical security issues associated with any
     service which provides physical addressing and delivery
     information. Although organizations are generally encouraged to
     provide as much information as they feel comfortable with, no
     information is required.
  
  
  6.      IANA Considerations
  
     This document defines an application of the LDAPv3 protocol rather
     than a new Internet application protocol. As such, there are no
     protocol-related IANA considerations.
  
     However, this document does define several LDAP schema elements,
     including object classes, attributes, syntaxes and extensibleMatch
     filters, and these elements should be assigned OID values from the
     IANA branch, rather than being assigned from a particular
     enterprise branch.
  
     Finally, this document also describes several instances where
     public DNS and LDAP servers are queried. It is expected that IANA
     will establish and maintain these LDAP servers (and the necessary
     DNS SRV domain names and resource records) required for this
     service to operate. This includes providing SRV resource records
     in the generic TLDs and the root domain, and also includes
     administering the referenced LDAP servers.
  
  
  7.      Author's Addresses
  
     Eric A. Hall
     ehall@ehsco.com
  
  
  8.      References
  
            RFC 2247 - Using Domains in LDAP/X.500 DNs
  
  Hall & Newton          I-D Expires: August 2002             [page 12]


  Internet Draft      draft-ietf-crisp-lw-dns-00.txt          July 2002
  
  
  
            RFC 2251 - Lightweight Directory Access Protocol (v3)
  
            RFC 2252 - Lightweight Directory Access Protocol (v3):
            Attribute Syntax Definitions.
  
            RFC 2254 - The String Representation of LDAP Search Filters
  
            [ir-dir-req] - <draft-newton-ir-dir-requirements-00.txt> -
            Internet Registry Directory Requirements
  
            [ldap-whois] - <draft-ietf-crisp-lw-core-00.txt> - The
            Internet Resource Query Service and the Internet Resource
            Schema
  
            [ldap-whois-ipv4] - <draft-ietf-crisp-lw-ipv4-00.txt> -
            Defining and Locating IPv4 Address Blocks using the
            Internet Resource Query Service
  
            [ldap-whois-ipv6] - <draft-ietf-crisp-lw-ipv6-00.txt> -
            Defining and Locating IPv6 Address Blocks using the
            Internet Resource Query Service
  
  
  9.      Acknowledgments
  
     Portions of this work were funded by Network Solutions, Inc.
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 13]
  

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/