RFC 1608
Representing IP Information in the X.500 Directory
Representing IP Information in the X.500 Directory 🧚
Hiii bestie, this is RFC 1608 💖 titled Representing IP Information in the X.500 Directory. It came out of the Network Working Group 🌈 in March 1994 📅. The authors are T. Johannsen from Dresden University 🎓, G. Mansfield from AIC Systems Laboratory 🧪, M. Kosters from Network Solutions,Inc. 🌐, and S. Sataluri from AT&T Bell Laboratories 📞. It's an Experimental doc 🧫, and the header doesn't list any Obsoletes or Updates, so it isn't replacing or amending anything else 💅.
Status of this Memo 💅
So this memo defines an Experimental protocol for the Internet community 🧪. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested 🗣️, and distribution of this memo is unlimited 🌍.
Abstract 🦋
Okay so this doc is all about the objects you need to put information about IP networks and IP numbers into the X.500 Directory 📚. It extends the work "Charting networks in the X.500 Directory" [1], which sets up a general framework for representing networks in the Directory, by applying that framework to IP networks 🧩. The goal is to support the work of IP network assigning authorities (the NICs) 🏛️, plus any other apps that want to map IP numbers to data about related networks 🗺️. Autonomous Systems and their routing policy info can also live in the Directory, along with how they relate to networks and organizations 🌈.
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 171. Introduction 🎀
Info about the Internet's network infrastructure gets created and stored by a bunch of different orgs 🏢, like the Internet Assigned Numbers Authority (IANA), the Internet Registry (IR), the Network Information Centers (NICs), and the NSFNET Network Operations Center (NOC) 🛰️. Usually these orgs "master" that info (store and maintain it) in one centralized place, so there's a single spot to look for the definitive list of entries 📍. That worked fine in the past, but with the Internet growing like crazy in users and networks 📈, it's essential that a distributed schema be used now 🫶.
The X.500 Directory has the right tech for doing this distributed way of managing network infrastructure info 💜.
Here's what this doc is going for ✅:
- Provision of IP specific images of network elements
- Mapping from Network Number to network, owner, provider etc.
- Support of delegation of IP address blocks
- Storage of high-level routing policies and AS information
- Support of "classless" network address formats
- Provision of several organizational images of a network
Fun fact: the document basically has two parts 🎁. In part one, an IP specific extension of the general "Charting networks in the Directory" [1] framework gets built, and the objects from that framework get tied to IP numbers 🔢. Part two defines an IP namespace that refers back to the IP network elements from the beginning 🧚.
2. IP images of networks 🌸
Quick recap from [1]: networks get modeled as a set of subnetworks and nodes, which this doc calls network elements 🧱. To get a particular view of a network element, you use images 📸. Down below, images of network elements for an IP specific view are defined 🌐. Heads up, though: images contain references to the underlying physical info about elements, so keep that in mind 👀.
From here on out, ipStringSyntax is the attribute type for every attribute that's meant to hold an IP number 🔢. Right now there are two definitions for a syntax like this:
IpAddressas of [5]ipas of [6]
For the time being, the suggestion is to use CaseIgnoreStringSyntax in implementations, with the convention of using the ordinary IP syntax 🤓. Still, an OID has been reserved for ipStringSyntax (see Appendix) 🎟️.
2.1 IP network image 🌐
The IP network image is one application of network images, so it inherits the networkImageClass 🧬. That class is shown below for reference only, and its real definition is 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 brings together all the network elements that share a common IP network number 💃. Right now, IP network numbers fall into one of the classes A, B, or C 🔢. But sub- and supernetworking is already happening a lot, and classless network numbers are expected to be assigned soon 🚀. [2] proposes assigning bitwise contiguous blocks of class-C-addresses to all networks with more than 255 nodes 🧱. So the definition of an IP network is always tied to a common network number and a network mask 🎭.
IP networks are super close with the Domain Name System 💕, and a few attributes exist just to handle that relationship 🔗. To be clear, they're not trying to cancel DNS 🙅♀️. The schema here can give you the mapping from an IP number to a domain name and back again 🔁.
The IP network image object below is meant to hold technical and administrative data for one IP network 📋. Its attributes hold the stuff a NIC-WHOIS server would reveal about the network, plus 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
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 IP, an ipNodeImageObject should be created for that node 💻. This image is a subclass of nodeImageClass and holds the IP-specific info. The nodeImageClass is shown below for reference only, and its definition lives in [1].
nodeImage OBJECT CLASS
SUBCLASS of ImageCommunicationObject
/* no attributes common for all nodeImages have been
defined yet */An ipNodeImage is what you use to get technical and administrative info on a host 🧑💻. It's defined like this:
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 */2.3 IP network interface image 🔌
The most important IP info about a node (its IP addresses) gets registered with ipNetworkInterfaceImageObjects 📇. This picture is accurate because a node can have several IP addresses, but at most one per interface 🫵. It also shows clearly how an interface relates to its neighboring IP network 🏘️.
IpNetworkInterfaceImage is a subclass of networkInterfaceImageClass 🧩. That class is shown below for reference only, and its definition is in [1]. Important bit: for ipNetworkInterfaceImage, all the references get read in the context of IP. So 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 */On top of that, ipNetworkInterfaceImageObject has these extra 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. */2.4 Autonomous Systems 🦋
Okay so Autonomous Systems (AS) get defined in asObject, which is a subclass of imageCommunicationObject 💅. It holds the technical and admin info about an AS, and you can also stash routing policies right on the AS object. The definition lines up with the matching database object over 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 */Here's the tea: routing policies for an AS are represented by the {asIn, asOut} attributes of asObject. Because of current X.500 performance limits, routers probably won't use it directly for dynamic routing 🙈. But network management systems can totally use it to figure out the allowed paths [i.e., in accordance with published policies] between two networks 💜. That's super useful for finding alternate paths and checking how well networks are connected 🌸.
3. Number assignment information ✨
So in this part, we define Directory objects to represent the IP and AS (Autonomous System) namespaces inside the Directory 🧚. They exist to give you:
- mapping from IP number to IP network element (network or node)
- mapping from IP number to AS number and vice versa
- assignment and delegation information
We need a global, distributed database for all of this mainly because IP and AS numbers get assigned in a distributed way 🌈.
Describing all IP numbers with one of the new objects delegatedBlock, ipGroup and ipReference gets you the info you want. AS number info lives in the asBlock and asReference objects. Also, all assigned numbers share some properties, so we introduce an objectclass called assignedNumberClass. It exports attributes to delegatedBlock, ipGroup, ipReference, asBlock, and asReference 💖.
Here's assignedNumberClass. ("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 one covers a block of IP addresses delegated to some local authority or service provider. Heads up: this schema only handles contiguous blocks. If an organization (say, a NIC) has been assigned several IP network numbers that don't form a contiguous block, it might want a different way to show that, like using imageNetworks (e.g., using imageNetworks) 🙈. The delegatedBlock object holds the lower and upper bounds of the block.
Note that none of this assumes network masks line up with byte boundaries. So you can represent subnetting inside a "network (number)", which happens a lot inside organizations, all in the same framework 🧩.
This schema adds some granularity to the otherwise flat IP-number space 🍓. That granularity matters because it can be used to figure out who administers the block: a service provider or a domain manager. E.g., it fits nicely into the scheme for aggregating networks for routing purposes that's 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 relNwElement attribute (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 gives info for an IP network number. Its job is basically just to:
- show that the number has been assigned, and
- 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 covers "classical" class-A, -B and -C network addresses, plus any kind of super- and subnetworking 🌈.
The IP group object is a subclass of assignedNumberClass. Its relNwElement attribute 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
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's one IP reference object for each IP host address. Its purpose is to:
- tell that this IP number is already assigned to a node
- give a pointer to the related ipNodeImageObject
The IP reference object is a subclass of assignedNumberClass. Its relNwElement attribute 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 shows delegation of blocks of AS numbers to regional registries. It's similar to delegatedBlock for ipNetwork numbers 💅.
asBlock OBJECT CLASS
SUBCLASS of AssignedNumberClass
MUST CONTAIN
asBlockName :: caseIgnoreStringSyntax,
asLowerBound :: integerStringSyntax,
asUpperBound :: integerStringSyntaxAn AS block will comprise several consecutive AS numbers. Objects describing these numbers may be stored in asObjects 🫶.
3.5 AS reference object 🔥
An AS reference object shows that an Autonomous System number has been assigned, so it can not be given to somebody else 🔒. Similar to ipGroup, asReference doesn't contain technical details about an autonomous system itself. Instead, it points (with relNwElement) to a descriptive asObject 💖.
asReference OBJECT CLASS
SUBCLASS of AssignedNumberClass
MUST CONTAIN
asNumber :: integerStringSyntax4. 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 get stored underneath the organization / organizationalUnit entry of the entity responsible for that network. If that entry doesn't exist yet in the white-pages pilot, that's covered in 4.4 below 💜.
4.2 AS objects 👑
The technical and admin description of an AS is basically maintained by NICs, network providers, or other special organizations 💅. It's suggested that these organizations build a subtree for the AS info they're responsible for 🫶.
4.3 Namespace objects 🌸
Okay bestie, so 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 treeThe tree is built with two views in mind: administrative and implementational 💅. Nowadays, network numbers usually get assigned to organizations by (national) Network Information Centers (NIC), and those NICs were themselves given a block of IP network numbers by another authority (e.g., IR at the top level). This idea of delegated blocks breaking down into smaller delegated blocks and IP network numbers is what gets used to model the Directory tree. So an ipGroup object is always subordinate to a delegated block object (namely the delegated block that includes this IP number) 🎀. Network numbers that were assigned directly by a top-level authority, meaning they were never delegated to a local assigning authority, all end up sitting at one level in the Directory.
We already see lots of delegations within the traditional class A-, B- and C-addresses though 👀. A delegation like that is represented by a delegated block object, with the assigned IP network numbers as its subordinates. Part of a block can also be delegated further to another authority, which creates another delegated block object inside the parent delegated block's tree. Usually, the subordinates of ipGroup objects are ipReferences, i.e., single IP addresses as assigned to nodes. To support subnetworking, ipGroups can also be divided into several subnetwork ipGroups, each one representing an IP subnetwork. In those cases, the 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.3Figure 2: Example population of IP namespace tree according to delegation and subnetworking. 🧚
For some applications, keeping ipImage (the description of the network) and ipGroup (the description of the namespace element) separate can cause disadvantages in the look-up procedure 😭. In that case, one might think about combining both object classes, with the aim of providing one object that describes 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 spaceSimilar 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) shows up in several places in the network DIT (org of IP-Number, org of AS-Number, org of Admin-contact). However, it will basically be 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 a NIC that holds the AS, DNS, IP, ... subtrees of the DIT 🙈.
A good strategy would avoid explicit duplication of information. By explicit duplication, we mean 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:
- most organizations do not, as yet, have an entry in the DIT, and
- 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. 🔥
- 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. - 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 that 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. Bestie, read that one twice 💀. This is a spec about putting real network numbers into a Directory, and this memo itself says nothing about security.
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.deGlenn Mansfield
AIC Systems Laboratory
6-6-3 Minami Yoshinari, Aoba-ku
Sendai 989-32, JAPAN
Phone: +81 22 279-3310
EMail: glenn@aic.co.jpMark Kosters
Network Solutions, Inc.
505 Huntmar Park Dr.
Herndon, VA 22070
Phone: +1 703 742-4795
EMail: markk@internic.netSrinivas 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.comReferences 📚
- [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.
Appendix: OID tables 🦋
okay bestie, this appendix is the OID cheat sheet 🎀 It lists the object identifiers for the object classes and attribute types defined in [1] and in this document ✨
the OIDs are written in quipu-oidtable format so people can drop them straight into their pilots 🧚 here's the setup first, the IMPORT and the local base 💅
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.1next up are the object classes 👑 each line has the format Object, OID, SubClassOf, MustHave, MayHave, so you can see who inherits from who 🫶
-- 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 : \
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 : \
: \
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 :last but not least, the attribute types 🌸 each one gets its OID plus its syntax, and some of them have short nicknames after the comma, like nw or nd, so you can use whichever one you like best 💖
-- 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
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📦 where this page comes from
- ietf: rfc1608 1994-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms