summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1608.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1608.txt')
-rw-r--r--doc/rfc/rfc1608.txt1123
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]
+