As per Relevance of the word assigned, we have this rfc below:
Network Working Group T.
Request for Comments: 1608 Dresden
Category: Experimental G.
AIC Systems
M.
Network Solutions,Inc
S.
AT&T Bell
March 1994
Representing IP Information in the X.500
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
This document describes the objects necessary to include
about IP networks and IP numbers in the X.500 Directory. It
the work "Charting networks in the X.500 Directory" [1] where
general framework is presented for representing networks in
Directory by applying it to IP networks. This application of
Directory is intended to support the work of IP network
authorities, NICs, as well as other applications looking for
mapping of IP numbers to data of related networks. Furthermore
Autonomous Systems and related routing policy information can
represented in the Directory along with their relationship
networks and organizations
Johannsen, Mansfield, Kosters & Sataluri [Page 1]
RFC 1608 IP Information in the X.500 Directory March 1994
Table of
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.
Information related to the Internet Network Infrastructure is
and stored by a number of different organizations, such as
Internet Assigned Numbers Authority (IANA), Internet Registry (IR),
Network Information Centers (NICs), and the NSFNET Network
Center (NOC). This information is generally "mastered" (stored
maintained) by these organizations on a centralized basis, i.e.,
there is a single place to look for a definitive list of entries
these categories. This has worked well in the past but given
tremendous growth of the Internet and its number of users
networks, it is essential that a distributed schema be used
The X.500 Directory offers the appropriate technology
implementing this distributed method of managing
infrastructure information
The following goals are addressed in this document
o Provision of IP specific images of network
o Mapping from Network Number to network, owner, provider etc
o Support of delegation of IP address
o Storage of high-level routing policies and AS
o Support of "classless" network address
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
It may be noted that the document basically consists of two parts
In the first part, an IP specific extension of the general
"Charting networks in the Directory" [1] is given. Objects
by the application of this framework are related to IP numbers. An
namespace is defined in the second part of this paper, referring
IP network elements defined at the beginning
2. IP images of
As defined in [1], networks are modeled as a set of subnetworks
nodes, called network elements in the remainder. To obtain
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
information about elements
In the remainder, ipStringSyntax is used as attribute type for
attributes that are to hold an IP number. Currently, there are
definitions for a syntax like this
o IpAddress as of [5]
o ip as of [6]
It is suggested to use CaseIgnoreStringSyntax for implementations
the time being with the convention to use the ordinary IP syntax
Nevertheless, an OID has been reserved for ipStringSyntax (
Appendix).
2.1 IP network
IP network image is one application of network images and
inherits the networkImageClass. This class is given below
reference only, its definition can be found in [1].
networkImage OBJECT
SUBCLASS of
MAY
externalGateway :: distinguishedNameSyntax
/* points to one or more nodes that
as gateway for the protocol
this image refers to */
An IP network combines all network elements that have a common
network number. Presently, IP network numbers fall into one of
classes A, B, or C. However, sub- and supernetworking is already
broadly, and classless networks numbers are expected to be
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
IP network, therefore, is always related to common network number
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,
schema defined here is able to provide the mapping IP number
domain name and vice versa
An IP network image object as defined below is intended to
technical and administrative data for one IP network. Attributes
information that a NIC-WHOIS server would reveal for the network,
more
ipNetworkImage OBJECT
SUBCLASS of
MUST
ipNetworkImageName :: CaseIgnoreString
/* common name */
ipNwNumber :: IPStringSyntax
/* the IP network number
this (sub)network */
ipNwMask ::
/* mask that applies to
in order to define
network number; also used for routing */
MAY
/* 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
IP numbers and domain names, the name given
should contain the "closest match".
1) (sub)network does not have a domain
of its own, but is part of a bigger domain
take name of that
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
networks/nodes can be achieved by a
implementation of RFC1279 */
inAddrServer :: DistinguishedNameSyntax
/* refers to the ipNodeImageObject of
inaddr Server that holds information
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 ::
/* date when network got connected to the Internet */
2.2 IP node
If a node in the network is running the IP protocol,
ipNodeImageObject should be created for this node. This image is
subclass of nodeImageClass and holds IP specific information.
nodeImageClass is given below for reference only, its definition
be found in [1].
nodeImage OBJECT
SUBCLASS of
/* no attributes common for all nodeImages have
defined yet */
An ipNodeImage is used to obtain technical and
information on a host. The object is defined as follows
ipNodeImage OBJECT
SUBCLASS of
MUST
ipNodeName ::
/* common name, it is advised to
the hostname for this purpose */
MAY
protocol :: CaseIgnoreString
/* name and version of IP protocol running */
domainName :: CaseIgnoreString
/* the complete domain name of this node
CNAMEs can be stored additionally to
DNS A record name
further relationships, like MX record entries
should be taken care of by the domain name
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
The most important IP related information of a node (its
addresses) is registered with ipNetworkInterfaceImageObjects.
picture is accurate as a node can have several IP addresses, but
most one per interface. Furthermore, it shows clearly
relationship between interface and neighboring IP network
IpNetworkInterfaceImage is a subclass of networkInterfaceImageClass
The networkInterfaceImageClass is given below for reference only,
definition can be found in [1]. Note that
ipNetworkInterfaceImage all references are drawn in the context
IP, i.e., networkInterfaceAddress becomes an IP address
connectedNetwork points to an ipNetworkImageObject
networkInterfaceImage OBJECT
SUBCLASS of
MAY
networkInterfaceAddress :: caseIgnoreStringSyntax
/* this interface's address in the context
image refers to, e.g. IP number, NSAP */
connectedNetwork ::
/* pointer to networkImageObject that
the network this interface is attached to in
of the protocol or application the
indicates */
Additionally, ipNetworkInterfaceImageObject has the
properties
ipNetworkInterfaceImage OBJECT
SUBCLASS of
MUST
ipNetworkInterfaceName ::
/* It is suggested that the interface
is derived from the name of the
device this interface represents for
operating system, e.g. le0, COM1 */
MAY
ipNwMask ::
/* mask that applies to networkInterfaceAddress
routing of packets to nodes on the
(broadcast) network
Note: This is only a
of the routing table
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
Autonomous Systems (AS) are defined in asObject which is a subclass
imageCommunicationObject. It provides technical and
information of an AS. Furthermore, routing policies can be stored
the AS object. The definition of the AS object is aligned with
corresponding database object defined in [3].
as OBJECT
SUBCLASS of
MUST
asNumber ::
MAY
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
by the {asIn, asOut} attributes of asObject. Due to
constraints of present X.500 technology, it will probably not be
directly by routers for dynamic routing. However, it certainly
be used in network management systems to determine the allowed
[i.e., in accordance with published policies] between two networks
This will be useful in finding alternate paths, and evaluating
connectivity of networks
3. Number assignment
In the following, Directory objects have been defined to represent
and AS (Autonomous System) namespace in the Directory. Their
is to
o mapping from IP number to IP network element (network or node
o mapping from IP number to AS number and vice
o assignment and delegation
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
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
information is stored with the objects asBlock and asReference
Furthermore, all assigned numbers have some properties in common
Therefore, an objectclass assignedNumberClass is introduced.
class exports attributes to delegatedBlock, ipGroup, ipReference
asBlock, and asReference
AssignedNumberClass is defined as follows ("number" always refers
IP number of delegatedBlock, network, host, and AS number, resp.):
assignedNumberClass OBJECT
SUBCLASS of
MAY
assBy :: DistinguishedNameSyntax
/* refers to an organization or
that assigned the number to assTo (see below) */
assTo :: DistinguishedNameSyntax
/* refers to organization or
that the number was assigned to. This does
imply that assTo "owns" this number now. */
assDate :: uTCTimeSyntax
/* date of assignment for this number */
nicHandle :: CaseIgnoreStringSyntax
/* gives the unique ID for a
related to this number
format: "handle : nic-domain-name
example: MAK21 : rs.internic.net */
relNwElement :: DistinguishedNameSyntax
/* the network element related to this
(network or node) */
3.1 Delegated Block
This object provides information on a block of IP addresses
to some local-authority or service provider. Only contiguous
can be represented with the following schema. If an
(say, a NIC) has been assigned several IP network numbers which
not form a contiguous block, it might want to use a different form
representing that fact (e.g., using imageNetworks).
delegatedBlock object holds lower and upper bounds of the block
Note that the above does not make any assumption about the
masks being constrained by byte boundaries. We can thus
subnetting within a "network (number)" that often happens within
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
used to identify the administrator of the block - a service
or a domain manager. E.g., it fits well into the schema
aggregating networks for routing purposes as has been proposed
[4].
The object delegatedBlock is of the form
delegatedBlock OBJECT
SUBCLASS of
MUST
delegatedBlockName :: caseIgnoreStringSyntax
lowerBound :: IPStringSyntax
/* smallest IP address belonging to
block, e.g. 195.100.0.0 */
upperBound ::
/* highest IP address belonging to
block, e.g. 195.103.255.255 */
The attribute relNwElement (inherited from AssignedNumberClass)
point to a networkImage covering all networks within the block
this makes sense
3.2 IP Group
This object provides information for an IP network number.
purpose is basically only
o show that the number has been assigned,
o provide a reference to the descriptive ipNetworkObject
this network
Regardless of the actual value of x, IP group objects may exist
IP numbers x.0.0.0, x.y.0.0 and x.y.z.0. This approach
"classical" class-A, -B and -C network addresses as well as any
of super- and subnetworking
The IP group object is a subclass of assignedNumberClass.
attribute relNwElement points to an ipNetworkImage as defined above
ipGroup OBJECT
SUBCLASS of
MUST
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 ::
/* mask that applies to all
within the group; used to
classless networking; */
3.3 IP Reference
There is one IP reference object for each IP host address.
purpose of this object is
o tell that this IP number is already assigned to a
o give a pointer to the related
The IP reference object is a subclass of assignedNumberClass.
attribute relNwElement points to an ipNodeImage
ipReference OBJECT
SUBCLASS of
MUST
ipReferenceName ::
/* value is always IP address */
3.4 AS block
The AS block object is used to show delegation of blocks of
numbers to regional registries. This is similar to delegatedBlock
ipNetwork numbers
asBlock OBJECT
SUBCLASS of
MUST
asBlockName :: caseIgnoreStringSyntax
asLowerBound :: integerStringSyntax
asUpperBound ::
An AS block will comprise several consecutive AS numbers. Objects
describe these numbers may be stored in asObjects
3.5 AS reference
An AS reference object is used to show that an Autonomous
number has been assigned (and thus can not be given to
else). Similar to ipGroup, asReference does not contain
details about an autonomous system itself but rather points (
relNwElement) to a descriptive asObject
Johannsen, Mansfield, Kosters & Sataluri [Page 10]
RFC 1608 IP Information in the X.500 Directory March 1994
asReference OBJECT
SUBCLASS of
MUST
asNumber ::
4. Directory
|
+-------------+---------------+
| |
c= o=
| |
+-----+------+ +------+-------+
| | | |
ipNw= as= dbl= asB
| | |
ipNd= ipG= asRef
| |
ipNwIf= ipRef
Figure 1: Overall relationship of objects
4.1 IP image
According to [1], IP image entries will be stored underneath
organization / organizationalUnit entry of the entity responsible
that network. The case that such an entry does not yet exist in
white-pages pilot is discussed in 4.4 below
4.2 AS
The technical and administrative description of an AS is
maintained by NICs, network providers, or other
organizations. It is suggested that these organizations build
subtree for information on AS which they are responsible for
4.3 Namespace
The new IP namespace objects build a single tree in the Directory.
is suggested that this tree will have a root of
organizationalUnit within @o=Internet@ou=Network Information
objectClass=
organizationalUnitName= IP
description= root of IP number
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
view. Nowadays, network numbers usually are assigned
organizations by (national) Network Information Centers (NIC)
themselves have got a block of IP network numbers assigned
another authority (e.g., IR at top level). This concept of
blocks falling apart in smaller delegated blocks and IP
numbers is used to model the Directory tree. Thus, an ipGroup
is always subordinate of a delegated block object (namely
delegated block including this IP number). Network numbers that
directly assigned by a top-level authority, i.e., have not
object of a delegation to a local assigning authority, will all be
one level in the Directory. Already today, however, we find
delegations within the traditional class A-, B- and C-addresses
Such a delegation is represented by a delegated block object,
the assigned IP network numbers as subordinates. Also, part of
block can be further delegated to another authority, leading
another delegated block object within the parent delegated block'
tree. Usually, subordinates of ipGroup objects are ipReferences
i.e., single IP addresses as assigned to nodes. To
subnetworking, it is also allowed to divide ipGroups into
subnetwork ipGroups, each representing an IP subnetwork. In
cases, subnetwork numbers are given as subordinates to the
IP network number. Network masks clarify what the
addresses are
ou=IP
|
+-------------------+-----------------------+
/ | \
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
to delegation and subnetworking
For some applications, the separation of ipImage (description of
network) and ipGroup (description of the namespace element) will
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
of combining both object classes with the aim to provide one
describing administrative and technical data for an IP network
As Autonomous Systems are an additional namespace to the existing
number space, they should go into a separate subtree. It is
that this is an organizationalUnit within @o=Internet@ou=
Information
objectClass=
organizationalUnitName= AS
description= root of Autonomous System number
Similar to blocks of IP network numbers, blocks of AS numbers
sometimes delegated to another registry. This is expressed by
objects. These objects come below the root of the AS number space
All AS numbers falling into such a block are stored as
of the block. An AS block may have smaller AS blocks underneath
delegation is extended
4.4 Relationship to organizational
Organizational information (i.e., white-pages-like information
an organization, its departments and employees) occurs at
places in the network DIT - [org of IP-Number, org of AS-Number,
of Admin- contact, However, it will be basically
[administered, maintained] by the organization itself in
Directory Management Domain (DMD) over which the organization has
authority. This gives rise to some tricky problems - a
example is that of a NIC which holds the AS, DNS, IP, ...
of the DIT
A good strategy would avoid explicit duplication of information.
explicit duplication of information we understand information
duplicated outside the directory framework, e.g., by having
master entries for one and the same piece of information. The
way to avoid duplication would be to have relevant entries point
the pertinent organizational entry for organizational information
But
o most organizations do not, as yet, have an entry in the DIT
o the reliability of the access to an organizations DIT
stored in a remote DSA cannot be taken for granted
the following framework is adopted to accommodate the
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
at the NICs DSA. Since only the necessary info will be
the NIC will not be burdened to act as the repository of
organizations DIT. These objects may be kept in a
subtree of affiliated-organizations [
affiliated to the NIC]. Though the affiliated organizations
does not really represent a locality, it is suggested to
the node as objectClass locality. This does not break
Directory schema when entries of organizations shall
subordinate to the NICs organization's entry
o The problem of information duplication/consistency will arise
organizational DITs/DSAs do come into existence. At that stage
shadowing mechanism which will attempt to maintain the
consistency may be resorted to. The X.500/ISO 9594(1993)
implementations are expected to provide appropriate
mechanisms along X.525.
It may be noted that what is suggested is not a duplication of
entire white-pages-like structure at the NIC. It suggests
"affiliated organizations node". The entries under this node will
organization objects with a limited number of attributes, i.e.,
attributes to hold the organization info necessary for the NIC
nothing more, nothing less. Operationally, and content wise the
DSA will hold exactly the amount of info that is desired by the NIC
When an organization sets up its DSA and when the
informs the NIC about it, the NIC will set up the
arrangement to obtain info on changes of interest [and forget
it].
It may be emphasized that the entries under affiliated
are physical entities [replicated and refined from the
entries, if and when they exist...] rather than alias entries. If
NIC dislikes the idea of users poring over the entries in
affiliated organizations - appropriate access control can be applied
Though duplication is unavoidable, the proposal attempts to make
transparent, by delegating the responsibility of maintaining
integrity to the Directory
This issue is discussed in greater detail in a separate document [7].
5. Security
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'
Thomas
Dresden University of
Institute of Communication
D-01062 Dresden,
Phone: +49 351 463-4621
EMail: Thomas.Johannsen@ifn.et.tu-dresden.
Glenn
AIC Systems
6-6-3 Minami Yoshinari, Aoba-
Sendai 989-32,
Phone: +81 22 279-3310
EMail: glenn@aic.co.
Mark
Network Solutions, Inc
505 Huntmar Park Dr
Herndon, VA 22070
Phone: +1 703 742-4795
EMail: markk@internic.
Srinivas R.
AT&T Bell
Room 1C-429, 101 Crawfords Corner
Holmdel, NJ 07733-3030
Phone: +1 908 949-7782
EMail: sri@qsun.att.
Johannsen, Mansfield, Kosters & Sataluri [Page 15]
RFC 1608 IP Information in the X.500 Directory March 1994
[1] Mansfield, G., Johannsen, T., and M. Knopper, "Charting
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",
1466, Merit, May 1993.
[3] Bates, T., Jouanigot, J.-M., Karrenberg, D., Lothberg, P., and M
Terpstra, "Representation of IP Routing Policies in the
Database", Document ripe-81, RIPE, February 1993.
[4] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:
Address Assignment and Aggregation Strategy", RFC 1338, BARRNet
cisco, MERIT, OARnet, June 1992.
[5] Rose, M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", STD 16,
1155, Performance Systems International, Hughes LAN Systems,
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., "
Strategy for the Directory in the Internet", AIC
Laboratory, Dresden University, Keio University, Work
Progress, July 1993.
Johannsen, Mansfield, Kosters & Sataluri [Page 16]
RFC 1608 IP Information in the X.500 Directory March 1994
Appendix: OID
This appendix lists object identifiers for object classes
attributes type defined in [1] and this document
OIDs are given in quipu-oidtable format to make it easy for people
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.
id-nw-oc: network-objects.1
id-nw-at: network-objects.2
id-nw-as: network-objects.3
ipStringSyntax: ip-nw-as.1
-- localoidtable.
# general class
# Format is -
# Object: OID: SubClassOf: MustHave:
CommunicationObject: id-nw-oc.1 : top : \
: \
adminContact, technContact,
PhysicalCommunicationObject: id-nw-oc.2 : CommunicationObject : \
: \
owner, localityName,
ImageCommunicationObject: id-nw-oc.3 : CommunicationObject : \
: \
imageType,
# physical communication
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,
node: id-nw-oc.5 : PhysicalCommunicationObject : \
nodeName : \
typeOfMachine,
networkInterface: id-nw-oc.6 : PhysicalCommunicationObject : \
networkInterfaceName : \
networkInterfaceAddress,
# image communication
networkImage: id-nw-oc.7 : ImageCommunicationObject : \
: \
externalGateway, speed, traffic,
nodeImage: id-nw-oc.8 : ImageCommunicationObject : \
:
networkInterfaceImage: id-nw-oc.9 : ImageCommunicationObject : \
: \
networkInterfaceAddress,
# IP image
ipNetworkImage: id-nw-oc.10 : networkImage : \
ipNetworkImageName, ipNwNumber, ipNwMask : \
associatedDomain, inAddrServer, asNumber, \
provider,
ipNodeImage: id-nw-oc.11 : nodeImage : \
ipNodeName : \
protocol,
ipNetworkInterfaceImage: id-nw-oc.12 : networkInterfaceImage : \
ipNetworkInterfaceName : \
as: id-nw-oc.13 : ImageCommunicationObject : \
asNumber : \
asName, asIn, asOut, asDefault, asGuardian, \
# number assignement
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, \
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.
adminContact: id-nw-at.1 :
technContact: id-nw-at.2 :
ICO: id-nw-at.3 :
imageType: id-nw-at.4 :
imageOf: id-nw-at.5 :
networkName,nw: id-nw-at.6 :
externalGateway: id-nw-at.7 :
nwType: id-nw-at.8 :
media: id-nw-at.9 :
speed: id-nw-at.10 :
traffic: id-nw-at.11 :
configurationDate: id-nw-at.12 :
configurationHistory: id-nw-at.13 :
nodeName,nd: id-nw-at.14 :
typeOfMachine: id-nw-at.15 :
OS: id-nw-at.16 :
networkInterfaceName,ni: id-nw-at.17 :
networkInterfaceAddress: id-nw-at.18 :
connectedNetwork: id-nw-at.19 :
charge: id-nw-at.20 :
ipNetworkImageName,IPnw: id-nw-at.21 :
ipNwNumber: id-nw-at.22 :
ipNwMask: id-nw-at.23 :
inAddrServer: id-nw-at.24 :
asNumber,asN: id-nw-at.25 :
provider: id-nw-at.26 :
Johannsen, Mansfield, Kosters & Sataluri [Page 19]
RFC 1608 IP Information in the X.500 Directory March 1994
onlineDate: id-nw-at.27 :
ipNodeName,IPnd: id-nw-at.28 :
protocol: id-nw-at.29 :
domainName: id-nw-at.30 :
ipNetworkInterfaceName,IPni: id-nw-at.31 :
asName: id-nw-at.32 :
asIn: id-nw-at.33 :
asOut: id-nw-at.34 :
asDefault: id-nw-at.35 :
asGuardian: id-nw-at.36 :
assBy: id-nw-at.37 :
assTo: id-nw-at.38 :
assDate: id-nw-at.39 :
nicHandle: id-nw-at.40 :
relNwElement: id-nw-at.41 :
delegatedBlockName,dbl: id-nw-at.42 :
lowerBound: id-nw-at.43 :
upperBound: id-nw-at.44 :
ipGroupName,IPgr: id-nw-at.45 :
ipReferenceName,IPref: id-nw-at.46 :
asBlockName,asBl: id-nw-at.47 :
asLowerBound: id-nw-at.48 :
asUpperBound: id-nw-at.49 :
Johannsen, Mansfield, Kosters & Sataluri [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
