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

Versions: 00

  INTERNET-DRAFT                                             Eric A. Hall
  Document: draft-ietf-crisp-lw-ipv4-00.txt                     July 2002
  Expires: January, 2003
  
  
                  Defining and Locating IPv4 Address Blocks
                  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 IPv4
     addresses and address blocks, in support of the Internet Resource
     Query Service described in [ldap-whois].
  
  
  
  
  Internet Draft     draft-ietf-crisp-lw-ipv4-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-ipv4-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 inetIpv4Network Object Class
  
     The inetIpv4Network object class is a structural object class
     which provides administrative information about a specific IPv4
     address and an associated subnet prefix (this pairing is most
     often used to represent the starting address of an IPv4 network,
     but can also be used to identify a specific host).
  
  
  3.1.    Naming syntax
  
     The naming syntax for IPv4 network entries MUST follow the form of
     "cn=<inetIpv4NetworkSyntax>,cn=inetResources,<dc-DIT>". Each IPv4
     network address which is managed as a discrete LDAP-WHOIS network
     resource MUST have a dedicated entry in each of the DITs which
     provide public LDAP-WHOIS data regarding that network address.
  
     The inetIpv4NetworkSyntax component of an entry is subject to DN
     rules, although the inetIpv4NetworkSyntax is also used for
     extended search operations, and is therefore subject to specific
     syntax rules. The inetIpv4NetworkSyntax specifically requires the
     use of the starting address from a range of inclusive addresses,
     and specifically requires the use of CIDR prefix annotation. In
     this manner, it is possible to create an inetIpv4Network entry for
     a range of addresses (by specifying the starting address and the
     network prefix size), or a single host (by specifying the host-
     specific address and a /32 prefix).
  
     In this definition, inetIpv4NetworkSyntax uses the traditional
     "dotted-quad" notation, where each of four sub-components provide
     a decimal value that represents one octet from a 32-bit IPv4
     address, with the sub-components being separated by a full-stop
     (period) character, and with the four-part sequence being followed
     by a "/" character and a three-digit decimal "prefix" value. An
     augmented BNF for this syntax is as follows:
  
  Hall & Newton          I-D Expires: August 2002              [page 3]


  Internet Draft     draft-ietf-crisp-lw-ipv4-00.txt         July 2002
  
  
  
          inetIpv4NetworkSyntax = vFourPart "." vFourPart "." vFourPart
            "." vFourPart "/" vFourPrefix
  
          vFourPart = decimal value between "0" and "255" inclusive,
            with the non-affective leading zeroes removed
  
          vFourPrefix = decimal value between "1" and "32" inclusive,
            with the non-affective leading zeroes removed
  
     For example, an IPv4 network with a range of addresses between
     "10.0.0.0" and "10.0.255.255" inclusive would be written as
     "10.0.0.0/16", and would appear with an RDN of "cn=10.0.0.0/16".
     Similarly, a host address of "192.0.2.14" would have the RDN of
     "cn=192.0.2.14/32".
  
     The leading zeroes from each octet MUST be removed during query
     string formation. Octets which have a value of zero MUST be
     represented by the single-digit numeric value of "0".
  
     Note that the use of "/" is illegal in LDAP URLs when it is
     provided as data (in particular, URLs use this character as a part
     delimiter). This character MUST be escaped as "%2F" when it is
     provided as part of an inetIpv4Network entry in a ref attribute.
  
  
  3.2.    Schema definition
  
     IPv4 network entries MUST exist with the top, inetResources and
     inetIpv4Network 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 inetIpv4Network 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 inetIpv4Network object class has no
     mandatory attributes, although it does have several optional
     attributes.
  
     The inetIpv4Network object class defines attributes which are
     specific to IPv4 networks, such as the delegation date and the
     status of the delegation. The inetIpv4Network object class is
     subordinate to the inetResources object class, so it inherits
     those attributes as well.
  
  
  Hall & Newton          I-D Expires: August 2002              [page 4]


  Internet Draft     draft-ietf-crisp-lw-ipv4-00.txt         July 2002
  
  
     Some of the inetIpv4Network 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.
  
     The schema definition for the inetIpv4Network object class is as
     follows:
  
          inetIpv4Network
          ( 1.3.6.1.4.1.7161.1.2.0 NAME 'inetIpv4Network' DESC 'IPv4
            network attributes.' SUP inetResources STRUCTURAL MAY (
            inetIpv4DelegationStatus $ inetIpv4DelegationDate $
            inetIpv4DelegationModifiedDate $
            inetIpv4DelegationModifiedBy $ inetIpv4Contacts $
            inetIpv4ContactsModifiedBy $ inetIpv4ContactsModifiedDate $
            inetIpv4RoutingContacts $ inetIpv4RoutingContactsModifiedBy
            $ inetIpv4RoutingContactsModifiedDate ) )
  
     The attributes from the inetIpv4Network object class are described
     below:
  
          inetIpv4Contacts
          ( 1.3.6.1.4.1.7161.1.2.2 NAME 'inetIpv4Contacts' DESC
            'Contacts for reporting problems with this IPv4 network.'
            EQUALITY caseExactMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.15 )
  
          inetIpv4ContactsModifiedBy
          ( 1.3.6.1.4.1.7161.1.2.3 NAME 'inetIpv4ContactsModifiedBy'
            DESC 'Person who last modified the inetIpv4Contacts
            attribute.' EQUALITY distinguishedNameMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
            distributedOperation )
  
  
  Hall & Newton          I-D Expires: August 2002              [page 5]


  Internet Draft     draft-ietf-crisp-lw-ipv4-00.txt         July 2002
  
  
          inetIpv4ContactsModifiedDate
          ( 1.3.6.1.4.1.7161.1.2.4 NAME 'inetIpv4ContactsModifiedDate'
            DESC 'Last modification date of the inetIpv4Contacts
            attribute.' EQUALITY generalizedTimeMatch ORDERING
            generalizedTimeOrderingMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetIpv4DelegationDate
          ( 1.3.6.1.4.1.7161.1.2.5 NAME 'inetIpv4DelegationDate' DESC
            'Date of original delegation.' EQUALITY
            generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE )
  
          inetIpv4DelegationModifiedBy
          ( 1.3.6.1.4.1.7161.1.2.6 NAME 'inetIpv4DelegationModifiedBy'
            DESC 'Person who last modified the inetIpv4DelegationStatus
            attribute.' EQUALITY distinguishedNameMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetIpv4DelegationModifiedDate
          ( 1.3.6.1.4.1.7161.1.2.7 NAME
            'inetIpv4DelegationModifiedDate' DESC 'Last modification
            date of the inetIpv4DelegationStatus attribute.' EQUALITY
            generalizedTimeMatch ORDERING generalizedTimeOrderingMatch
            SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
            distributedOperation )
  
          inetIpv4DelegationStatus
          ( 1.3.6.1.4.1.7161.1.2.8 NAME 'inetIpv4DelegationStatus' DESC
            'Current delegation status code for this network.' 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:
  
                 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)
  
  
  Hall & Newton          I-D Expires: August 2002              [page 6]


  Internet Draft     draft-ietf-crisp-lw-ipv4-00.txt         July 2002
  
  
            Additional values for the inetIpv4DelegationStatus
            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.
  
          inetIpv4RoutingContacts
          ( 1.3.6.1.4.1.7161.1.2.9 NAME 'inetIpv4RoutingContacts' DESC
            'Contacts for routing issues with this IPv4 network.'
            EQUALITY caseExactMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.15 )
  
          inetIpv4RoutingContactsModifiedBy
          ( 1.3.6.1.4.1.7161.1.2.10 NAME
            'inetIpv4RoutingContactsModifiedBy' DESC 'Person who last
            modified the inetIpv4RoutingContacts attribute.' EQUALITY
            distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
            SINGLE-VALUE USAGE distributedOperation )
  
          inetIpv4RoutingContactsModifiedDate
          ( 1.3.6.1.4.1.7161.1.2.11 NAME
            'inetIpv4RoutingContactsModifiedDate' DESC 'Last
            modification date of the inetIpv4RoutingContacts
            attribute.' EQUALITY generalizedTimeMatch ORDERING
            generalizedTimeOrderingMatch SYNTAX
            1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE
            distributedOperation )
  
     The inetIpv4NetworkSyntax syntax is as follows:
  
          inetIpv4NetworkSyntax
          ( 1.3.6.1.4.1.7161.1.2.1 NAME 'inetIpv4NetworkSyntax' DESC
            'An IPv4 address and prefix.' )
  
  
  3.3.    Example
  
     An example of the inetIpv4Network object class is shown in Figure
     1 below, with attributes from the inetResources object class also
     being used to provide administrative contacts. This data is a
     result of a query which was sent to the LDAP servers responsible
     for operating the "192.0.2.0/24" network block.
  
  
  Hall & Newton          I-D Expires: August 2002              [page 7]


  Internet Draft     draft-ietf-crisp-lw-ipv4-00.txt         July 2002
  
  
          cn=192.0.2.0/24,cn=inetResources,dc=example,dc=com
          [top object class]
          [inetResources object class]
          [inetIpv4Network object class]
          |
          +-attribute: description
          | value: "The example.com network"
          |
          +-attribute: inetIpv4Contacts
          | 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 192.0.2.0/24 inetIpv4Network entry.
  
     As stated earlier, reverse-lookup DNS domains for IPv4 address
     blocks are managed as inetDnsDomain object class entries. These
     are entirely different network resources, and should not be
     confused with inetIpv4Network object class entries.
  
  
  4.      The inetIpv4NetworkMatch Filter
  
     The inetIpv4NetworkMatch filter provides an identifier and search
     string format which collectively inform a queried server that a
     specific IPv4 address should be searched for, and that any
     matching inetIpv4network object class entries should be returned.
  
            NOTE: IPv4 addresses are also stored in DNS for reverse-
            lookups, and those entries are treated as inetDnsDomain
            object class entries rather than being treated as
            inetIpv4Network object class entries (they are treated as
            DNS zones with their own operational administrators). As
            such, those entries use the inetDnsDomainMatch query
            described in [ldap-whois-dns].
  
     The inetIpv4NetworkMatch extensibleMatch filter is defined as
     follows:
  
          inetIpv4NetworkMatch
          ( 1.3.6.1.4.1.7161.1.2.12 NAME 'inetIpv4NetworkMatch' SYNTAX
            inetIpv4NetworkSyntax )
  
  
  Hall & Newton          I-D Expires: August 2002              [page 8]


  Internet Draft     draft-ietf-crisp-lw-ipv4-00.txt         July 2002
  
  
     The assertion value MUST be an IPv4 address, using the
     inetIpv4NetworkSyntax defined in section 3. Clients MUST provide
     assertion values in this syntax. If an input string does not match
     this syntax, the client MAY attempt to manipulate the input string
     such that an appropriate assertion value can be formed. For
     example, if a user enters a traditional IPv4 address without
     specifying a prefix value, the client MAY append "/32" to the end
     of the input string to form a valid assertion value. Similarly, if
     a user provides an octal or hexadecimal value, the client MAY
     attempt to convert the input string to the traditional dotted-quad
     IPv4 address notation.
  
     The server MUST compare the assertion value against the RDN of all
     entries in the inetResources container which have an object class
     of inetIpv4Network. Any entry for an IPv4 network resource which
     is clearly superior to the IPv4 address provided in the input
     string MUST be returned to the client. Superiority in this case
     means exactly what it sounds like: the address range specified by
     the inetIpv4Network object class entry (as determined by the
     network number and the prefix combination of the entry's RDN) MUST
     define a range of IPv4 addresses which encompasses the IPv4
     address specified in the query, and any such entry MUST be
     returned in the response message. Entries which do not encompass
     the queried address MUST NOT be returned. Entries which do not
     have an object class of inetIpv4Network MUST NOT be returned.
  
     For example, assume that the client is submitting a search for
     "192.0.2.14/32", with the search base of "dc=in-addr,dc=arpa". The
     queried server may only have an inetIpv4Network entry for
     "cn=192.0.0.0/8,cn=inetResources,dc=in-addr,dc=arpa", and as such
     that would be the only entry returned. However, the server could
     also have multiple entries which matched the queried IPv4 address,
     such as "cn=192.0.0.0/8,cn=inetResources,dc=in-addr,dc=arpa" and
     "cn=192.0.2.0/24,cn=inetResources,dc=in-addr,dc=arpa", both of
     which reflected specific delegations.
  
     Similarly, a query for this IPv4 address which was sent to the
     LDAP servers responsible for the operational network could result
     in "cn=192.0.2.8/29,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa" and
     "cn=192.0.2.14/32,dc=8/29,dc=2,dc=0,dc=192,dc=in-addr,dc=arpa"
     entries being returned to the client (assuming the subnet
     allocation policy of the network reflected this usage, and that
     there was an explicit entry for the IPv4 address in question).
  
  
  Hall & Newton          I-D Expires: August 2002              [page 9]


  Internet Draft     draft-ietf-crisp-lw-ipv4-00.txt         July 2002
  
  
     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.2.12:=192.0.2.14/32)".
  
     Response entries MAY be fully-developed inetIpv4Network entries,
     or MAY be referrals generated from entries which have the
     inetIpv4Network 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.
  
  
  Hall & Newton          I-D Expires: August 2002             [page 10]


  Internet Draft     draft-ietf-crisp-lw-ipv4-00.txt         July 2002
  
  
     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
     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
  
  
  Hall & Newton          I-D Expires: August 2002             [page 11]


  Internet Draft     draft-ietf-crisp-lw-ipv4-00.txt         July 2002
  
  
  
  8.      References
  
            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
  
  
  9.      Acknowledgments
  
     Portions of this work were funded by Network Solutions, Inc.
  
  
  
  Hall & Newton          I-D Expires: August 2002             [page 12]
  

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