home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1608.txt < prev    next >
Text File  |  1996-05-07  |  41KB  |  518 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. 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 
  8.  
  9.             Representing IP Information in the X.500 Directory 
  10.  
  11. Status of this Memo 
  12.  
  13.    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. 
  14.  
  15. Abstract 
  16.  
  17.    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. 
  18.  
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32.  
  33.  
  34.  
  35.  Johannsen, Mansfield, Kosters & Sataluri                        [Page 1] 
  36.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  37.  
  38.  Table of Contents 
  39.  
  40.       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 
  41.  
  42. 1. Introduction 
  43.  
  44.    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. 
  45.  
  46.    The X.500 Directory offers the appropriate technology for    implementing this distributed method of managing network    infrastructure information. 
  47.  
  48.    The following goals are addressed in this document: 
  49.  
  50.     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 
  51.  
  52.  
  53.  
  54. Johannsen, Mansfield, Kosters & Sataluri                        [Page 2] 
  55.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  56.  
  57.      o Provision of several organizational images of a network 
  58.  
  59.    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. 
  60.  
  61. 2. IP images of networks 
  62.  
  63.    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. 
  64.  
  65.    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: 
  66.  
  67.     o IpAddress as of [5]     o ip as of [6] 
  68.  
  69.    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). 
  70.  
  71. 2.1 IP network image 
  72.  
  73.    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]. 
  74.  
  75.    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 */ 
  76.  
  77.    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 
  78.  
  79.  
  80.  
  81. Johannsen, Mansfield, Kosters & Sataluri                        [Page 3] 
  82.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  83.  
  84.     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. 
  85.  
  86.    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. 
  87.  
  88.    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. 
  89.  
  90.    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 */ 
  91.  
  92.     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 
  93.  
  94.  
  95.  
  96. Johannsen, Mansfield, Kosters & Sataluri                        [Page 4] 
  97.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  98.  
  99.           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 */ 
  100.  
  101. 2.2 IP node image 
  102.  
  103.    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]. 
  104.  
  105.    nodeImage OBJECT CLASS     SUBCLASS of ImageCommunicationObject      /* no attributes common for all nodeImages have been         defined yet */ 
  106.  
  107.    An ipNodeImage is used to obtain technical and administrative    information on a host. The object is defined as follows: 
  108.  
  109.    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 */ 
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Johannsen, Mansfield, Kosters & Sataluri                        [Page 5] 
  118.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  119.  
  120.  2.3 IP network interface image 
  121.  
  122.    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. 
  123.  
  124.    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. 
  125.  
  126.    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 */ 
  127.  
  128.    Additionally, ipNetworkInterfaceImageObject has the following    properties: 
  129.  
  130.    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. */ 
  131.  
  132.  
  133.  
  134.  
  135.  
  136. Johannsen, Mansfield, Kosters & Sataluri                        [Page 6] 
  137.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  138.  
  139.  2.4 Autonomous Systems 
  140.  
  141.    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]. 
  142.  
  143.    as OBJECT CLASS     SUBCLASS of  ImageCommunicationObject     MUST CONTAIN      asNumber :: IntegerStringSyntax 
  144.  
  145.     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 */ 
  146.  
  147.    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    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. 
  148.  
  149. 3. Number assignment information 
  150.  
  151.    In the following, Directory objects have been defined to represent IP    and AS (Autonomous System) namespace in the Directory. Their purpose    is to provide 
  152.  
  153.      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 
  154.  
  155.  
  156.  
  157. Johannsen, Mansfield, Kosters & Sataluri                        [Page 7] 
  158.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  159.  
  160.     The need for a global, distributed database supporting the objectives    arises mainly from distributed IP- and AS-number assignment. 
  161.  
  162.    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. 
  163.  
  164.    AssignedNumberClass is defined as follows ("number" always refers to    IP number of delegatedBlock, network, host, and AS number, resp.): 
  165.  
  166.    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) */ 
  167.  
  168. 3.1 Delegated Block object 
  169.  
  170.    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. 
  171.  
  172.    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 
  173.  
  174.  
  175.  
  176. Johannsen, Mansfield, Kosters & Sataluri                        [Page 8] 
  177.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  178.  
  179.     organization in the same framework. 
  180.  
  181.    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]. 
  182.  
  183.    The object delegatedBlock is of the form: 
  184.  
  185.    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 */ 
  186.  
  187.    The attribute relNwElement (inherited from AssignedNumberClass) can    point to a networkImage covering all networks within the block if    this makes sense. 
  188.  
  189. 3.2 IP Group object 
  190.  
  191.    This object provides information for an IP network number.  Its    purpose is basically only to 
  192.  
  193.       o show that the number has been assigned, and       o provide a reference to the descriptive ipNetworkObject for         this network. 
  194.  
  195.    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. 
  196.  
  197.    The IP group object is a subclass of assignedNumberClass. The    attribute relNwElement points to an ipNetworkImage as defined above. 
  198.  
  199.    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 
  200.  
  201.  
  202.  
  203. Johannsen, Mansfield, Kosters & Sataluri                        [Page 9] 
  204.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  205.  
  206.           where x, y, z in 1..255 */      ipNwMask   ::    IPStringSyntax       /* mask that applies to all numbers          within the group; used to define          classless networking;  */ 
  207.  
  208. 3.3 IP Reference object 
  209.  
  210.    There is one IP reference object for each IP host address.  The    purpose of this object is to 
  211.  
  212.      o tell that this IP number is already assigned to a node      o give a pointer to the related ipNodeImageObject 
  213.  
  214.    The IP reference object is a subclass of assignedNumberClass.  The    attribute relNwElement points to an ipNodeImage. 
  215.  
  216.    ipReference OBJECT CLASS     SUBCLASS of  AssignedNumberClass     MUST CONTAIN      ipReferenceName :: IPString       /* value is always IP address */ 
  217.  
  218. 3.4 AS block object 
  219.  
  220.    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. 
  221.  
  222.    asBlock OBJECT CLASS     SUBCLASS of  AssignedNumberClass     MUST CONTAIN      asBlockName :: caseIgnoreStringSyntax,      asLowerBound :: integerStringSyntax,      asUpperBound :: integerStringSyntax 
  223.  
  224.    An AS block will comprise several consecutive AS numbers.  Objects to    describe these numbers may be stored in asObjects. 
  225.  
  226. 3.5 AS reference object 
  227.  
  228.    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. 
  229.  
  230.  
  231.  
  232.  
  233.  
  234. Johannsen, Mansfield, Kosters & Sataluri                       [Page 10] 
  235.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  236.  
  237.     asReference OBJECT CLASS     SUBCLASS of  AssignedNumberClass     MUST CONTAIN      asNumber :: integerStringSyntax 
  238.  
  239. 4. Directory tree 
  240.  
  241.                                root                                |                  +-------------+---------------+                  |                             |                 c=                         o=Internet                  |                             |            +-----+------+               +------+-------+            |            |               |              |           ipNw=       as=             dbl=           asB=            |                            |              |           ipNd=                       ipG=           asRef=            |                            |           ipNwIf=                     ipRef= 
  242.  
  243.               Figure 1: Overall relationship of objects. 
  244.  
  245. 4.1 IP image objects 
  246.  
  247.    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. 
  248.  
  249. 4.2 AS objects 
  250.  
  251.    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. 
  252.  
  253. 4.3 Namespace objects 
  254.  
  255.    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. 
  256.  
  257.      objectClass= organizationalUnit      organizationalUnitName= IP networks      description= root of IP number tree 
  258.  
  259.  
  260.  
  261.  Johannsen, Mansfield, Kosters & Sataluri                       [Page 11] 
  262.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  263.  
  264.     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. 
  265.  
  266.                          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 
  267.  
  268.       Figure 2: Example population of IP namespace tree according                 to delegation and subnetworking. 
  269.  
  270.    For some applications, the separation of ipImage (description of the    network) and ipGroup (description of the namespace element) will bear 
  271.  
  272.  
  273.  
  274. Johannsen, Mansfield, Kosters & Sataluri                       [Page 12] 
  275.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  276.  
  277.     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. 
  278.  
  279.    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. 
  280.  
  281.      objectClass= organizationalUnit      organizationalUnitName= AS numbers      description= root of Autonomous System number space 
  282.  
  283.    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. 
  284.  
  285. 4.4 Relationship to organizational entries 
  286.  
  287.    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. 
  288.  
  289.    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 
  290.  
  291.      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, 
  292.  
  293.    the following framework is adopted to accommodate the conflicting    requirements /conditions. 
  294.  
  295.  
  296.  
  297.  
  298.  
  299. Johannsen, Mansfield, Kosters & Sataluri                       [Page 13] 
  300.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  301.  
  302.       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. 
  303.  
  304.      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        mechanisms along X.525. 
  305.  
  306.    It may be noted that what is suggested is not a duplication of an    entire white-pages-like structure at the NIC.  It suggests an    "affiliated organizations node". The entries under this node will be    organization objects with a limited number of attributes, i.e., the    attributes to hold the organization info necessary for the NIC:    nothing more, nothing less.  Operationally, and content wise the NIC    DSA will hold exactly the amount of info that is desired by the NIC.    When an organization sets up its DSA and when the organization    informs the NIC about it, the NIC will set up the shadowing    arrangement to obtain info on changes of interest [and forget about    it]. 
  307.  
  308.    It may be emphasized that the entries under affiliated organizations    are physical entities [replicated and refined from the Master    entries, if and when they exist...] rather than alias entries. If a    NIC dislikes the idea of users poring over the entries in the    affiliated organizations - appropriate access control can be applied.    Though duplication is unavoidable, the proposal attempts to make it    transparent, by delegating the responsibility of maintaining the    integrity to the Directory. 
  309.  
  310.    This issue is discussed in greater detail in a separate document [7]. 
  311.  
  312. 5. Security Considerations 
  313.  
  314.    Security issues are not discussed in this memo. 
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322. Johannsen, Mansfield, Kosters & Sataluri                       [Page 14] 
  323.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  324.  
  325.  6. Authors' Addresses 
  326.  
  327.    Thomas Johannsen    Dresden University of Technology    Institute of Communication Technology    D-01062 Dresden, GERMANY 
  328.  
  329.    Phone: +49 351 463-4621    EMail: Thomas.Johannsen@ifn.et.tu-dresden.de 
  330.  
  331.     Glenn Mansfield    AIC Systems Laboratory    6-6-3 Minami Yoshinari, Aoba-ku    Sendai 989-32, JAPAN 
  332.  
  333.    Phone: +81 22 279-3310    EMail: glenn@aic.co.jp 
  334.  
  335.     Mark Kosters    Network Solutions, Inc.    505 Huntmar Park Dr.    Herndon, VA 22070 
  336.  
  337.    Phone: +1 703 742-4795    EMail: markk@internic.net 
  338.  
  339.     Srinivas R. Sataluri    AT&T Bell Laboratories    Room 1C-429, 101 Crawfords Corner Road    Holmdel, NJ 07733-3030 
  340.  
  341.    Phone: +1 908 949-7782    EMail: sri@qsun.att.com 
  342.  
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357. Johannsen, Mansfield, Kosters & Sataluri                       [Page 15] 
  358.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  359.  
  360.  References 
  361.  
  362.   [1]  Mansfield, G., Johannsen, T., and M. Knopper, "Charting Networks        in the X.500 Directory", RFC 1609, AIC Systems Laboratory,        Dresden University, Merit Networks,Inc., March 1994. 
  363.  
  364.   [2]  Gerich, E., "Guidelines for Management of IP Address Space", RFC        1466, Merit, May 1993. 
  365.  
  366.   [3]  Bates, T., Jouanigot, J.-M., Karrenberg, D., Lothberg, P., and M.        Terpstra, "Representation of IP Routing Policies in the RIPE        Database", Document ripe-81, RIPE, February 1993. 
  367.  
  368.   [4]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting: An        Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,        cisco, MERIT, OARnet, June 1992. 
  369.  
  370.   [5]  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. 
  371.  
  372.   [6]  Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",        RFC 1274, University College London, November 1991. 
  373.  
  374.   [7]  Mansfield, G., Johannsen, T., and J. Murai, J., "Deployment        Strategy for the Directory in the Internet", AIC Systems        Laboratory, Dresden University, Keio University, Work in        Progress, July 1993. 
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  Johannsen, Mansfield, Kosters & Sataluri                       [Page 16] 
  397.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  398.  
  399.  Appendix: OID tables 
  400.  
  401.    This appendix lists object identifiers for object classes and    attributes type defined in [1] and this document. 
  402.  
  403.    OIDs are given in quipu-oidtable format to make it easy for people to    include them into their pilots. 
  404.  
  405.    IMPORT from oidtable.gen: 
  406.  
  407.    iso:                            1    identifiedOrganization:         iso.3    dod:                            identifiedOrganization.6    internet:                       dod.1    experimental:                   internet.3    network-objects:                experimental.53 
  408.  
  409.     -- localoidtable.gen 
  410.  
  411.    id-nw-oc:                       network-objects.1    id-nw-at:                       network-objects.2    id-nw-as:                       network-objects.3    ipStringSyntax:                 ip-nw-as.1 
  412.  
  413.     -- localoidtable.oc 
  414.  
  415.    # general class definitions    # Format is -    #               Object: OID: SubClassOf: MustHave: MayHave 
  416.  
  417.    CommunicationObject: id-nw-oc.1 : top : \             : \             adminContact, technContact, description 
  418.  
  419.    PhysicalCommunicationObject: id-nw-oc.2 : CommunicationObject : \            : \            owner, localityName, ICO 
  420.  
  421.    ImageCommunicationObject: id-nw-oc.3 : CommunicationObject : \            : \            imageType, imageOf 
  422.  
  423.    # physical communication elements 
  424.  
  425.    network: id-nw-oc.4 : PhysicalCommunicationObject : \            networkName : \ 
  426.  
  427.  
  428.  
  429. Johannsen, Mansfield, Kosters & Sataluri                       [Page 17] 
  430.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  431.  
  432.             externalGateway, nwType, media, speed, traffic, \            configurationDate, configurationHistory 
  433.  
  434.    node: id-nw-oc.5 : PhysicalCommunicationObject : \            nodeName : \            typeOfMachine, OS 
  435.  
  436.    networkInterface: id-nw-oc.6 : PhysicalCommunicationObject : \            networkInterfaceName : \            networkInterfaceAddress, connectedNetwork 
  437.  
  438.    # image communication elements 
  439.  
  440.    networkImage: id-nw-oc.7 : ImageCommunicationObject : \            : \            externalGateway, speed, traffic, charge 
  441.  
  442.    nodeImage: id-nw-oc.8 : ImageCommunicationObject : \            : 
  443.  
  444.    networkInterfaceImage: id-nw-oc.9 : ImageCommunicationObject : \            : \            networkInterfaceAddress, connectedNetwork 
  445.  
  446.    # IP image elements 
  447.  
  448.    ipNetworkImage: id-nw-oc.10 : networkImage : \            ipNetworkImageName, ipNwNumber, ipNwMask : \            associatedDomain, inAddrServer, asNumber, \            provider, onlineDate 
  449.  
  450.    ipNodeImage: id-nw-oc.11 : nodeImage : \            ipNodeName : \            protocol, domainName 
  451.  
  452.    ipNetworkInterfaceImage: id-nw-oc.12 : networkInterfaceImage : \            ipNetworkInterfaceName : \            ipNwMask 
  453.  
  454.    as: id-nw-oc.13 : ImageCommunicationObject : \            asNumber : \            asName, asIn, asOut, asDefault, asGuardian, \            lastModifiedDate 
  455.  
  456.    # number assignement objects 
  457.  
  458.    assignedNumberClass: id-nw-oc.14 : top : \            : \ 
  459.  
  460.  
  461.  
  462. Johannsen, Mansfield, Kosters & Sataluri                       [Page 18] 
  463.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  464.  
  465.             assBy, assTo, assDate, nicHandle, relNwElement, \            description 
  466.  
  467.    delegatedBlock: id-nw-oc.15 : AssignedNumberClass : \            delegatedBlockName, lowerBound, upperBound : 
  468.  
  469.    ipGroup: id-nw-oc.16 : AssignedNumberClass : \            ipGroupName, ipNwMask : 
  470.  
  471.    ipReference: id-nw-oc.17 : AssignedNumberClass : \            ipReferenceName : 
  472.  
  473.    asBlock: id-nw-oc.18 : AssignedNumberClass : \            asBlockName, asLowerBound, asUpperBound : 
  474.  
  475.    asReference: id-nw-oc.19 : AssignedNumberClass : \            asNumber : 
  476.  
  477.  
  478.  
  479.    -- localoidtable.at 
  480.  
  481.    adminContact:                id-nw-at.1     :DN    technContact:                id-nw-at.2     :DN    ICO:                         id-nw-at.3     :DN    imageType:                   id-nw-at.4     :caseIgnoreString    imageOf:                     id-nw-at.5     :DN    networkName,nw:              id-nw-at.6     :caseIgnoreString    externalGateway:             id-nw-at.7     :DN    nwType:                      id-nw-at.8     :caseIgnoreString    media:                       id-nw-at.9     :caseIgnoreString    speed:                       id-nw-at.10    :numericString    traffic:                     id-nw-at.11    :numericString    configurationDate:           id-nw-at.12    :utcTime    configurationHistory:        id-nw-at.13    :caseIgnoreString    nodeName,nd:                 id-nw-at.14    :caseIgnoreString    typeOfMachine:               id-nw-at.15    :caseIgnoreString    OS:                          id-nw-at.16    :caseIgnoreString    networkInterfaceName,ni:     id-nw-at.17    :caseIgnoreString    networkInterfaceAddress:     id-nw-at.18    :caseIgnoreString    connectedNetwork:            id-nw-at.19    :DN    charge:                      id-nw-at.20    :numericString    ipNetworkImageName,IPnw:     id-nw-at.21    :caseIgnoreString    ipNwNumber:                  id-nw-at.22    :caseIgnoreString    ipNwMask:                    id-nw-at.23    :caseIgnoreString    inAddrServer:                id-nw-at.24    :DN    asNumber,asN:                id-nw-at.25    :integerString    provider:                    id-nw-at.26    :DN 
  482.  
  483.  
  484.  
  485. Johannsen, Mansfield, Kosters & Sataluri                       [Page 19] 
  486.  RFC 1608         IP Information in the X.500 Directory        March 1994 
  487.  
  488.     onlineDate:                  id-nw-at.27    :utcTime    ipNodeName,IPnd:             id-nw-at.28    :caseIgnoreString    protocol:                    id-nw-at.29    :caseIgnoreString    domainName:                  id-nw-at.30    :caseIgnoreString    ipNetworkInterfaceName,IPni: id-nw-at.31    :caseIgnoreString    asName:                      id-nw-at.32    :caseIgnoreString    asIn:                        id-nw-at.33    :caseIgnoreString    asOut:                       id-nw-at.34    :caseIgnoreString    asDefault:                   id-nw-at.35    :caseIgnoreString    asGuardian:                  id-nw-at.36    :DN    assBy:                       id-nw-at.37    :DN    assTo:                       id-nw-at.38    :DN    assDate:                     id-nw-at.39    :utcTime    nicHandle:                   id-nw-at.40    :caseIgnoreString    relNwElement:                id-nw-at.41    :DN    delegatedBlockName,dbl:      id-nw-at.42    :caseIgnoreString    lowerBound:                  id-nw-at.43    :caseIgnoreString    upperBound:                  id-nw-at.44    :caseIgnoreString    ipGroupName,IPgr:            id-nw-at.45    :caseIgnoreString    ipReferenceName,IPref:       id-nw-at.46    :caseIgnoreString    asBlockName,asBl:            id-nw-at.47    :caseIgnoreString    asLowerBound:                id-nw-at.48    :integerString    asUpperBound:                id-nw-at.49    :integerString 
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  Johannsen, Mansfield, Kosters & Sataluri                       [Page 20] 
  517.  
  518.