rfc1608.txt

<VC++网络游戏建摸与实现>源代码

   directly by routers for dynamic routing.  However, it certainly can
   be used in network management systems to determine the allowed paths
   [i.e.,  in accordance with published policies] between two networks.
   This will be useful in finding alternate paths, and evaluating the
   connectivity of networks.

3. Number assignment information

   In the following, Directory objects have been defined to represent IP
   and AS (Autonomous System) namespace in the Directory. Their purpose
   is to provide

     o mapping from IP number to IP network element (network or node)
     o mapping from IP number to AS number and vice versa
     o assignment and delegation information



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


   The need for a global, distributed database supporting the objectives
   arises mainly from distributed IP- and AS-number assignment.

   Describing all IP numbers with one of the new objects delegatedBlock,
   ipGroup and ipReference leads to the desired information. AS number
   information is stored with the objects asBlock and asReference.
   Furthermore, all assigned numbers have some properties in common.
   Therefore, an objectclass assignedNumberClass is introduced. This
   class exports attributes to delegatedBlock, ipGroup, ipReference,
   asBlock, and asReference.

   AssignedNumberClass is defined as follows ("number" always refers to
   IP number of delegatedBlock, network, host, and AS number, resp.):

   assignedNumberClass OBJECT CLASS
    SUBCLASS of  top
    MAY CONTAIN
     assBy :: DistinguishedNameSyntax,
      /* refers to an organization or organizationalRole
         that assigned the number to assTo (see below) */
     assTo :: DistinguishedNameSyntax,
      /* refers to organization or organizationalRole
         that the number was assigned to. This does not
         imply that assTo "owns" this number now. */
     assDate :: uTCTimeSyntax,
      /* date of assignment for this number */
     nicHandle :: CaseIgnoreStringSyntax,
      /* gives the unique ID for a description
         related to this number.
         format: "handle : nic-domain-name"
         example: MAK21 : rs.internic.net */
     relNwElement ::  DistinguishedNameSyntax,
      /* the network element related to this number
         (network or node) */

3.1 Delegated Block object

   This object provides information on a block of IP addresses delegated
   to some local-authority or service provider. Only contiguous blocks
   can be represented with the following schema. If an organization
   (say, a NIC) has been assigned several IP network numbers which do
   not form a contiguous block, it might want to use a different form of
   representing that fact (e.g., using imageNetworks).  The
   delegatedBlock object holds lower and upper bounds of the block.

   Note that the above does not make any assumption about the network
   masks being constrained by byte boundaries. We can thus represent
   subnetting within a "network (number)" that often happens within an



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


   organization in the same framework.

   This schema does lead to some granularity in the otherwise flat IP-
   number space. Further, the granularity is significant as it may be
   used to identify the administrator of the block - a service provider
   or a domain manager.  E.g., it fits well into the schema of
   aggregating networks for routing purposes as has been proposed in
   [4].

   The object delegatedBlock is of the form:

   delegatedBlock OBJECT CLASS
    SUBCLASS of AssignedNumberClass
    MUST CONTAIN
     delegatedBlockName :: caseIgnoreStringSyntax,
     lowerBound :: IPStringSyntax,
      /* smallest IP address belonging to the
         block, e.g. 195.100.0.0 */
     upperBound :: IPStringSyntax
      /* highest  IP address belonging to the
         block, e.g. 195.103.255.255 */

   The attribute relNwElement (inherited from AssignedNumberClass) can
   point to a networkImage covering all networks within the block if
   this makes sense.

3.2 IP Group object

   This object provides information for an IP network number.  Its
   purpose is basically only to

      o show that the number has been assigned, and
      o provide a reference to the descriptive ipNetworkObject for
        this network.

   Regardless of the actual value of x, IP group objects may exist for
   IP numbers x.0.0.0, x.y.0.0 and x.y.z.0. This approach includes
   "classical" class-A, -B and -C network addresses as well as any kind
   of super- and subnetworking.

   The IP group object is a subclass of assignedNumberClass. The
   attribute relNwElement points to an ipNetworkImage as defined above.

   ipGroup OBJECT CLASS
    SUBCLASS of  AssignedNumberClass
    MUST CONTAIN
     ipGroupName :: IPStringSyntax,
      /* IP number; x.0.0.0 or x.y.0.0 or x.y.z.0



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


         where x, y, z in 1..255 */
     ipNwMask   ::    IPStringSyntax
      /* mask that applies to all numbers
         within the group; used to define
         classless networking;  */

3.3 IP Reference object

   There is one IP reference object for each IP host address.  The
   purpose of this object is to

     o tell that this IP number is already assigned to a node
     o give a pointer to the related ipNodeImageObject

   The IP reference object is a subclass of assignedNumberClass.  The
   attribute relNwElement points to an ipNodeImage.

   ipReference OBJECT CLASS
    SUBCLASS of  AssignedNumberClass
    MUST CONTAIN
     ipReferenceName :: IPString
      /* value is always IP address */

3.4 AS block object

   The AS block object is used to show delegation of blocks of AS
   numbers to regional registries. This is similar to delegatedBlock of
   ipNetwork numbers.

   asBlock OBJECT CLASS
    SUBCLASS of  AssignedNumberClass
    MUST CONTAIN
     asBlockName :: caseIgnoreStringSyntax,
     asLowerBound :: integerStringSyntax,
     asUpperBound :: integerStringSyntax

   An AS block will comprise several consecutive AS numbers.  Objects to
   describe these numbers may be stored in asObjects.

3.5 AS reference object

   An AS reference object is used to show that an Autonomous System
   number has been assigned (and thus can not be given to somebody
   else).  Similar to ipGroup, asReference does not contain technical
   details about an autonomous system itself but rather points (with
   relNwElement) to a descriptive asObject.





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


   asReference OBJECT CLASS
    SUBCLASS of  AssignedNumberClass
    MUST CONTAIN
     asNumber :: integerStringSyntax

4. Directory tree


                              root
                               |
                 +-------------+---------------+
                 |                             |
                c=                         o=Internet
                 |                             |
           +-----+------+               +------+-------+
           |            |               |              |
          ipNw=       as=             dbl=           asB=
           |                            |              |
          ipNd=                       ipG=           asRef=
           |                            |
          ipNwIf=                     ipRef=

              Figure 1: Overall relationship of objects.

4.1 IP image objects

   According to [1], IP image entries will be stored underneath the
   organization / organizationalUnit entry of the entity responsible for
   that network. The case that such an entry does not yet exist in the
   white-pages pilot is discussed in 4.4 below.

4.2 AS objects

   The technical and administrative description of an AS is basically
   maintained by NICs, network providers, or other special
   organizations.  It is suggested that these organizations build a
   subtree for information on AS which they are responsible for.

4.3 Namespace objects

   The new IP namespace objects build a single tree in the Directory. It
   is suggested that this tree will have a root of type
   organizationalUnit within @o=Internet@ou=Network Information.

     objectClass= organizationalUnit
     organizationalUnitName= IP networks
     description= root of IP number tree




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


   The tree is built under an administrative and an implementational
   view.  Nowadays, network numbers usually are assigned to
   organizations by (national) Network Information Centers (NIC) which
   themselves have got a block of IP network numbers assigned from
   another authority (e.g., IR at top level). This concept of delegated
   blocks falling apart in smaller delegated blocks and IP network
   numbers is used to model the Directory tree. Thus, an ipGroup object
   is always subordinate of a delegated block object (namely the
   delegated block including this IP number). Network numbers that were
   directly assigned by a top-level authority, i.e., have not been
   object of a delegation to a local assigning authority, will all be at
   one level in the Directory.  Already today, however, we find many
   delegations within the traditional class A-, B- and C-addresses.
   Such a delegation is represented by a delegated block object, having
   the assigned IP network numbers as subordinates. Also, part of the
   block can be further delegated to another authority, leading to
   another delegated block object within the parent delegated block's
   tree.  Usually, subordinates of ipGroup objects are ipReferences,
   i.e., single IP addresses as assigned to nodes. To support
   subnetworking, it is also allowed to divide ipGroups into several
   subnetwork ipGroups, each representing an IP subnetwork.  In such
   cases, subnetwork numbers are given as subordinates to the assigned
   IP network number.  Network masks clarify what the subnetwork
   addresses are.

                         ou=IP networks
                               |
           +-------------------+-----------------------+
          /                    |                        \
                  dbl=150.0.0.0-150.100.0.0
                               |
           +-------------------+-----------------------+
          /                    |                        \
                         ipG=150.80.0.0
                               |
           +-------------------+-----------------------+
          /                    |                        \
                         ipG=150.80.240.0
                               |
           +-------------------+-----------------------+
          /                    |                        \
   ipRef=150.80.254.1    ipRef=150.80.254.2      ipRef=150.80.254.3

      Figure 2: Example population of IP namespace tree according
                to delegation and subnetworking.

   For some applications, the separation of ipImage (description of the
   network) and ipGroup (description of the namespace element) will bear



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


   disadvantages in the look-up procedure. In that case one might think
   of combining both object classes with the aim to provide one object
   describing administrative and technical data for an IP network.

   As Autonomous Systems are an additional namespace to the existing IP
   number space, they should go into a separate subtree. It is suggested
   that this is an organizationalUnit within @o=Internet@ou=Network
   Information.

     objectClass= organizationalUnit
     organizationalUnitName= AS numbers
     description= root of Autonomous System number space

   Similar to blocks of IP network numbers, blocks of AS numbers are
   sometimes delegated to another registry. This is expressed by asBlock
   objects.  These objects come below the root of the AS number space.
   All AS numbers falling into such a block are stored as subordinates
   of the block. An AS block may have smaller AS blocks underneath if
   delegation is extended.

4.4 Relationship to organizational entries

   Organizational information (i.e., white-pages-like information about
   an organization, its departments and employees) occurs at several
   places in the network DIT - [org of IP-Number, org of AS-Number, org
   of Admin- contact, However, it will be basically mastered
   [administered, maintained] by the organization itself in the
   Directory Management Domain (DMD) over which the organization has the
   authority.  This gives rise to some tricky problems - a typical
   example is that of a NIC which holds the AS, DNS, IP, ...  subtrees
   of the DIT.

   A good strategy would avoid explicit duplication of information.  By
   explicit duplication of information we understand information being
   duplicated outside the directory framework, e.g., by having several
   master entries for one and the same piece of information. The only
   way to avoid duplication would be to have relevant entries point to
   the pertinent organizational entry for organizational information.
   But since

     o most organizations do not, as yet, have an entry in the DIT and
     o the reliability of the access to an organizations DIT when
       stored in a remote DSA cannot be taken for granted,

   the following framework is adopted to accommodate the conflicting
   requirements /conditions.





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


     o A copy of all the necessary organization-info is retained
       at the NICs DSA. Since only  the  necessary info will be kept
       the NIC will not be burdened to act as the repository of the
       organizations DIT. These objects may be kept in a separate
       subtree of affiliated-organizations [organizations
       affiliated to the NIC]. Though the affiliated organizations node
       does not really represent a locality, it is suggested to define
       the node as objectClass locality. This does not break the
       Directory schema when entries of organizations shall become
       subordinate to the NICs organization's entry.

     o The problem of information duplication/consistency will arise when
       organizational DITs/DSAs do come into existence. At that stage a
       shadowing mechanism which will attempt to maintain the data
       consistency may be resorted to. The X.500/ISO 9594(1993)
       implementations are expected to provide appropriate shadowing