rfc1608.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                       T. Johannsen
Request for Comments: 1608                            Dresden University
Category: Experimental                                      G. Mansfield
                                                  AIC Systems Laboratory
                                                              M. Kosters
                                                  Network Solutions,Inc.
                                                             S. Sataluri
                                                  AT&T Bell Laboratories
                                                              March 1994


           Representing IP Information in the X.500 Directory

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This document describes the objects necessary to include information
   about IP networks and IP numbers in the X.500 Directory. It extends
   the work "Charting networks in the X.500 Directory" [1] where a
   general framework is presented for representing networks in the
   Directory by applying it to IP networks.  This application of the
   Directory is intended to support the work of IP network assigning
   authorities, NICs, as well as other applications looking for a
   mapping of IP numbers to data of related networks. Furthermore,
   Autonomous Systems and related routing policy information can be
   represented in the Directory along with their relationship to
   networks and organizations.


















Johannsen, Mansfield, Kosters & Sataluri                        [Page 1]

RFC 1608         IP Information in the X.500 Directory        March 1994


Table of Contents

      1. Introduction                                     2
      2. IP images of networks                            3
      2.1 IP network image                                3
      2.2 IP node image                                   5
      2.3 IP network interface image                      6
      2.4 Autonomous Systems                              7
      3. Number assignment information                    7
      3.1 Delegated Block object                          8
      3.2 IP Group object                                 9
      3.3 IP Reference object                            10
      3.4 AS Block object                                10
      3.5 AS Reference object                            10
      4. Directory tree                                  11
      4.1 IP image objects                               11
      4.2 AS objects                                     11
      4.3 Namespace objects                              11
      4.4 Relationship to organizational entries         13
      5. Security Considerations                         14
      6. Authors' Addresses                              15
      References                                         16
      Appendix: OID tables                               17

1. Introduction

   Information related to the Internet Network Infrastructure is created
   and stored by a number of different organizations, such as the
   Internet Assigned Numbers Authority (IANA), Internet Registry (IR),
   Network Information Centers (NICs), and the NSFNET Network Operations
   Center (NOC).  This information is generally "mastered" (stored and
   maintained) by these organizations on a centralized basis, i.e.,
   there is a single place to look for a definitive list of entries for
   these categories.  This has worked well in the past but given the
   tremendous growth of the Internet and its number of users and
   networks, it is essential that a distributed schema be used.

   The X.500 Directory offers the appropriate technology for
   implementing this distributed method of managing network
   infrastructure information.

   The following goals are addressed in this document:

    o Provision of IP specific images of network elements
    o Mapping from Network Number to network, owner, provider etc.
    o Support of delegation of IP address blocks
    o Storage of high-level routing policies and AS information
    o Support of "classless" network address formats



Johannsen, Mansfield, Kosters & Sataluri                        [Page 2]

RFC 1608         IP Information in the X.500 Directory        March 1994


    o Provision of several organizational images of a network

   It may be noted that the document basically consists of two parts.
   In the first part, an IP specific extension of the general framework
   "Charting networks in the Directory" [1] is given.  Objects defined
   by the application of this framework are related to IP numbers. An IP
   namespace is defined in the second part of this paper, referring to
   IP network elements defined at the beginning.

2. IP images of networks

   As defined in [1], networks are modeled as a set of subnetworks and
   nodes, called network elements in the remainder. To obtain a
   particular view of a network element, images were introduced.  Below,
   images of network elements for an IP specific view are defined.
   Please note that images contain references to underlying physical
   information about elements.

   In the remainder, ipStringSyntax is used as attribute type for all
   attributes that are to hold an IP number. Currently, there are two
   definitions for a syntax like this:

    o IpAddress as of [5]
    o ip as of [6]

   It is suggested to use CaseIgnoreStringSyntax for implementations for
   the time being with the convention to use the ordinary IP syntax.
   Nevertheless, an OID has been reserved for ipStringSyntax (see
   Appendix).

2.1 IP network image

   IP network image is one application of network images and therefore
   inherits the networkImageClass. This class is given below for
   reference only, its definition can be found in [1].

   networkImage OBJECT CLASS
    SUBCLASS of ImageCommunicationObject
    MAY CONTAIN
     externalGateway :: distinguishedNameSyntax,
      /* points to one or more nodes that act
         as gateway for the protocol application
         this image refers to */

   An IP network combines all network elements that have a common IP
   network number.  Presently, IP network numbers fall into one of the
   classes A, B, or C. However, sub- and supernetworking is already done
   broadly, and classless networks numbers are expected to be assigned



Johannsen, Mansfield, Kosters & Sataluri                        [Page 3]

RFC 1608         IP Information in the X.500 Directory        March 1994


   soon. [2] proposes to assign bitwise contiguous blocks of class-C-
   addresses to all networks with more than 255 nodes. The definition of
   IP network, therefore, is always related to common network number and
   network mask.

   IP networks have a very close relationship to the Domain Name System.
   Several attributes are introduced to take care of these relations.
   Though we do not intend to abolish the existing DNS service, the
   schema defined here is able to provide the mapping IP number to
   domain name and vice versa.

   An IP network image object as defined below is intended to provide
   technical and administrative data for one IP network. Attributes hold
   information that a NIC-WHOIS server would reveal for the network, and
   more.

   ipNetworkImage OBJECT CLASS
    SUBCLASS of NetworkImage
    MUST CONTAIN
     ipNetworkImageName :: CaseIgnoreString,
      /* common name */
     ipNwNumber :: IPStringSyntax,
      /* the IP network number for
         this (sub)network */
     ipNwMask :: IPStringSyntax
      /* mask that applies to ipNwNumber
         in order to define classless
         network number; also used for routing */

    MAY CONTAIN
    /* DNS related info ; e.g. - */
     associatedDomain :: CaseIgnoreStringSyntax,
      /* the domain name associated to this IP network;
         As there is not always a 1:1 mapping between traditional
         IP numbers and domain names, the name given here
         should contain the "closest match".
         1) (sub)network does not have a domain name
            of its own, but is part of a bigger domain:
            take name of that domain
         2) network is divided into several domains,
            therefore having more than one domain name:
            list all of them.
         Note: a reverse mapping of domain names to
         networks/nodes can be achieved by a modified
         implementation of RFC1279 */
     inAddrServer :: DistinguishedNameSyntax,
      /* refers to the ipNodeImageObject of the
         inaddr Server that holds information about



Johannsen, Mansfield, Kosters & Sataluri                        [Page 4]

RFC 1608         IP Information in the X.500 Directory        March 1994


         this network */
    /* routing policy; e.g. - */
     asNumber :: integerStringSyntax,
      /* number of Autonomous System this network belongs to */
     acceptedUsagePolicy :: caseIgnoreStringSyntax,
      /* semantics to be defined */
    /* Any other - */
     provider   :: DistinguishedNameSyntax,
      /* points to network provider */
     onlineDate :: uTCTimeSyntax
      /* date when network got connected to the Internet */

2.2 IP node image

   If a node in the network is running the IP protocol, an
   ipNodeImageObject should be created for this node. This image is a
   subclass of nodeImageClass and holds IP specific information.  The
   nodeImageClass is given below for reference only, its definition can
   be found in [1].

   nodeImage OBJECT CLASS
    SUBCLASS of ImageCommunicationObject
     /* no attributes common for all nodeImages have been
        defined yet */

   An ipNodeImage is used to obtain technical and administrative
   information on a host. The object is defined as follows:

   ipNodeImage OBJECT CLASS
    SUBCLASS of NodeImage
    MUST CONTAIN
     ipNodeName :: CaseIgnoreString
      /* common name, it is advised to use
         the hostname for this purpose */
    MAY CONTAIN
     protocol :: CaseIgnoreString,
      /* name and version of IP protocol running */
     domainName :: CaseIgnoreString,
      /* the complete domain name of this node;
         CNAMEs can be stored additionally to the
         DNS A record name;
         further relationships, like MX record entries,
         should be taken care of by the domain name tree
         according to RFC 1279 */







Johannsen, Mansfield, Kosters & Sataluri                        [Page 5]

RFC 1608         IP Information in the X.500 Directory        March 1994


2.3 IP network interface image

   The most important IP related information of a node (its IP
   addresses) is registered with ipNetworkInterfaceImageObjects.  This
   picture is accurate as a node can have several IP addresses, but at
   most one per interface.  Furthermore, it shows clearly the
   relationship between interface and neighboring IP network.

   IpNetworkInterfaceImage is a subclass of networkInterfaceImageClass.
   The networkInterfaceImageClass is given below for reference only, its
   definition can be found in [1].  Note that for
   ipNetworkInterfaceImage all references are drawn in the context of
   IP, i.e., networkInterfaceAddress becomes an IP address and
   connectedNetwork points to an ipNetworkImageObject.

   networkInterfaceImage OBJECT CLASS
    SUBCLASS of ImageCommunicationObject
    MAY CONTAIN
     networkInterfaceAddress     :: caseIgnoreStringSyntax,
      /* this interface's address in the context the
         image refers to, e.g. IP number, NSAP */
     connectedNetwork   :: distinguishedNameSyntax
      /* pointer to networkImageObject that describes
         the network this interface is attached to in terms
         of the protocol or application the images
         indicates */

   Additionally, ipNetworkInterfaceImageObject has the following
   properties:

   ipNetworkInterfaceImage OBJECT CLASS
    SUBCLASS of NetworkInterfaceImage
    MUST CONTAIN
     ipNetworkInterfaceName :: CaseIgnoreStringSyntax
      /* It is suggested that the interface name
         is derived from the name of the logical
         device this interface represents for the
         operating system, e.g. le0, COM1 */
    MAY CONTAIN
     ipNwMask ::  IPStringSyntax
      /* mask that applies to networkInterfaceAddress for
         routing of packets to nodes on the connected
         (broadcast) network;
         Note: This is only a fraction
         of the routing table information
         for this interface, namely for one hop. */





Johannsen, Mansfield, Kosters & Sataluri                        [Page 6]

RFC 1608         IP Information in the X.500 Directory        March 1994


2.4 Autonomous Systems

   Autonomous Systems (AS) are defined in asObject which is a subclass of
   imageCommunicationObject.  It provides technical and administrative
   information of an AS. Furthermore, routing policies can be stored with
   the AS object.  The definition of the AS object is aligned with the
   corresponding database object defined in [3].

   as OBJECT CLASS
    SUBCLASS of  ImageCommunicationObject
    MUST CONTAIN
     asNumber :: IntegerStringSyntax

    MAY CONTAIN
     asName :: CaseIgnoreStringSyntax,
      /* if there is a name different from AS */
     asIn ::  CaseIgnoreStringSyntax,
      /* accepted routes from other AS */
      /* for syntax and semantics refer [3] */
     asOut :: CaseIgnoreStringSyntax,
      /* generated routes announced to others */
      /* for syntax and semantics refer [3] */
     asDefault ::CaseIgnoreStringSyntax,
      /* how default routing is handled */
      /* for syntax and semantics refer [3] */
     asGuardian :: DistinguishedNameSyntax, */
      /* DN of guardian of this AS */
     lastModifiedDate :: UTCtimeSyntax */
      /* important as routes change frequently */

   Note that routing policies for an Autonomous System are represented
   by the {asIn, asOut} attributes of asObject. Due to performance
   constraints of present X.500 technology, it will probably not be used