doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

diff --git a/doc/rfc/rfc1608.txt b/doc/rfc/rfc1608.txt
new file mode 100644
index 0000000..03ab8f1
--- /dev/null
+++ b/doc/rfc/rfc1608.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+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
+   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
+       mechanisms along X.525.
+
+   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].
+
+   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.
+
+   This issue is discussed in greater detail in a separate document [7].
+
+5. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+Johannsen, Mansfield, Kosters & Sataluri                       [Page 14]
+
+RFC 1608         IP Information in the X.500 Directory        March 1994
+
+
+6. Authors' Addresses
+
+   Thomas Johannsen
+   Dresden University of Technology
+   Institute of Communication Technology
+   D-01062 Dresden, GERMANY
+
+   Phone: +49 351 463-4621
+   EMail: Thomas.Johannsen@ifn.et.tu-dresden.de
+
+
+   Glenn Mansfield
+   AIC Systems Laboratory
+   6-6-3 Minami Yoshinari, Aoba-ku
+   Sendai 989-32, JAPAN
+
+   Phone: +81 22 279-3310
+   EMail: glenn@aic.co.jp
+
+
+   Mark Kosters
+   Network Solutions, Inc.
+   505 Huntmar Park Dr.
+   Herndon, VA 22070
+
+   Phone: +1 703 742-4795
+   EMail: markk@internic.net
+
+
+   Srinivas R. Sataluri
+   AT&T Bell Laboratories
+   Room 1C-429, 101 Crawfords Corner Road
+   Holmdel, NJ 07733-3030
+
+   Phone: +1 908 949-7782
+   EMail: sri@qsun.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johannsen, Mansfield, Kosters & Sataluri                       [Page 15]
+
+RFC 1608         IP Information in the X.500 Directory        March 1994
+
+
+References
+
+  [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.
+
+  [2]  Gerich, E., "Guidelines for Management of IP Address Space", RFC
+       1466, Merit, May 1993.
+
+  [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.
+
+  [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.
+
+  [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.
+
+  [6]  Barker, P., and S. Kille, "The COSINE and Internet X.500 Schema",
+       RFC 1274, University College London, November 1991.
+
+  [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johannsen, Mansfield, Kosters & Sataluri                       [Page 16]
+
+RFC 1608         IP Information in the X.500 Directory        March 1994
+
+
+Appendix: OID tables
+
+   This appendix lists object identifiers for object classes and
+   attributes type defined in [1] and this document.
+
+   OIDs are given in quipu-oidtable format to make it easy for people to
+   include them into their pilots.
+
+   IMPORT from oidtable.gen:
+
+   iso:                            1
+   identifiedOrganization:         iso.3
+   dod:                            identifiedOrganization.6
+   internet:                       dod.1
+   experimental:                   internet.3
+   network-objects:                experimental.53
+
+
+   -- localoidtable.gen
+
+   id-nw-oc:                       network-objects.1
+   id-nw-at:                       network-objects.2
+   id-nw-as:                       network-objects.3
+   ipStringSyntax:                 ip-nw-as.1
+
+
+   -- localoidtable.oc
+
+   # general class definitions
+   # Format is -
+   #               Object: OID: SubClassOf: MustHave: MayHave
+
+   CommunicationObject: id-nw-oc.1 : top : \
+            : \
+            adminContact, technContact, description
+
+   PhysicalCommunicationObject: id-nw-oc.2 : CommunicationObject : \
+           : \
+           owner, localityName, ICO
+
+   ImageCommunicationObject: id-nw-oc.3 : CommunicationObject : \
+           : \
+           imageType, imageOf
+
+   # physical communication elements
+
+   network: id-nw-oc.4 : PhysicalCommunicationObject : \
+           networkName : \
+
+
+
+Johannsen, Mansfield, Kosters & Sataluri                       [Page 17]
+
+RFC 1608         IP Information in the X.500 Directory        March 1994
+
+
+           externalGateway, nwType, media, speed, traffic, \
+           configurationDate, configurationHistory
+
+   node: id-nw-oc.5 : PhysicalCommunicationObject : \
+           nodeName : \
+           typeOfMachine, OS
+
+   networkInterface: id-nw-oc.6 : PhysicalCommunicationObject : \
+           networkInterfaceName : \
+           networkInterfaceAddress, connectedNetwork
+
+   # image communication elements
+
+   networkImage: id-nw-oc.7 : ImageCommunicationObject : \
+           : \
+           externalGateway, speed, traffic, charge
+
+   nodeImage: id-nw-oc.8 : ImageCommunicationObject : \
+           :
+
+   networkInterfaceImage: id-nw-oc.9 : ImageCommunicationObject : \
+           : \
+           networkInterfaceAddress, connectedNetwork
+
+   # IP image elements
+
+   ipNetworkImage: id-nw-oc.10 : networkImage : \
+           ipNetworkImageName, ipNwNumber, ipNwMask : \
+           associatedDomain, inAddrServer, asNumber, \
+           provider, onlineDate
+
+   ipNodeImage: id-nw-oc.11 : nodeImage : \
+           ipNodeName : \
+           protocol, domainName
+
+   ipNetworkInterfaceImage: id-nw-oc.12 : networkInterfaceImage : \
+           ipNetworkInterfaceName : \
+           ipNwMask
+
+   as: id-nw-oc.13 : ImageCommunicationObject : \
+           asNumber : \
+           asName, asIn, asOut, asDefault, asGuardian, \
+           lastModifiedDate
+
+   # number assignement objects
+
+   assignedNumberClass: id-nw-oc.14 : top : \
+           : \
+
+
+
+Johannsen, Mansfield, Kosters & Sataluri                       [Page 18]
+
+RFC 1608         IP Information in the X.500 Directory        March 1994
+
+
+           assBy, assTo, assDate, nicHandle, relNwElement, \
+           description
+
+   delegatedBlock: id-nw-oc.15 : AssignedNumberClass : \
+           delegatedBlockName, lowerBound, upperBound :
+
+   ipGroup: id-nw-oc.16 : AssignedNumberClass : \
+           ipGroupName, ipNwMask :
+
+   ipReference: id-nw-oc.17 : AssignedNumberClass : \
+           ipReferenceName :
+
+   asBlock: id-nw-oc.18 : AssignedNumberClass : \
+           asBlockName, asLowerBound, asUpperBound :
+
+   asReference: id-nw-oc.19 : AssignedNumberClass : \
+           asNumber :
+
+
+
+   -- localoidtable.at
+
+   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
+
+
+
+Johannsen, Mansfield, Kosters & Sataluri                       [Page 19]
+
+RFC 1608         IP Information in the X.500 Directory        March 1994
+
+
+   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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Johannsen, Mansfield, Kosters & Sataluri                       [Page 20]
+