4.2.4 Description of the INETNUM Object

Below is the object template for the inetnum object. It lists all possible attributes allowed in this object type. Required attributes are shown as ‘optional*’.

Attribute Name    Presence   Repeat     Indexed
inetnum:         mandatory  single     primary/lookup key
netname:        mandatory  single     lookup key
descr:          optional  multiple 
country:        mandatory  multiple 
geoloc:         optional   single   
language:       optional   multiple 
org:            optional*  single     inverse key
sponsoring-org: optional   single   
admin-c:        mandatory  multiple   inverse key
tech-c:         mandatory  multiple   inverse key
status:         mandatory  single   
remarks:        optional   multiple 
notify:         optional   multiple   inverse key
mnt-by:         mandatory  multiple   inverse key
mnt-lower:      optional   multiple   inverse key
mnt-routes:     optional   multiple   inverse key
mnt-domains:    optional   multiple   inverse key
mnt-irt:        optional   multiple   inverse key
created:         generated  single
last-modified:  generated  single
source:         mandatory  single    

An inetnum object contains information on allocations and assignments of IPv4 address space resources. This is one of the main elements of the RIPE Internet Number Registry.

4.2.4.1 Hierarchy of INETNUM Objects

The inetnum objects cover many different types of data in the RIPE Database. The policy on issuing IPv4 addresses in the RIPE NCC service region explains more about the process of allocating and assigning addresses within the region. This policy has changed many times over the years. Some of the data in the RIPE Database was set up under previous policy conditions. The following paragraphs outline how this physical data in the RIPE Database is structured and how to make sense of it.

They are arranged in a hierarchical structure starting with a root object 0/0. This root object is there for data management reasons. It does not mean the RIPE NCC has any administrative authority over the whole IPv4 address space.

The next level down in the hierarchy after the root object includes placeholder objects representing the /8 ranges of address space that the RIPE NCC is administratively responsible for.  There are also top-level legacy objects. These are outside the administrative control of the RIPE NCC but still used by resource holders within the RIPE NCC service region. These are generally smaller than a /8 but hierarchically on the same level. In other words, the root object is the parent of all the top-level legacy objects and these /8 placeholder objects. There may be other placeholder objects outside these /8 objects for historical reasons. These will be cleaned up at some point in the future. There are also some allocations to members that have no parent placeholder object.

The different types of data can be recognised by the “status:” and “mnt-lower:” attribute values. The root object and all the placeholder objects will have a status ‘ALLOCATED UNSPECIFIED’. But some of the member allocations may also have this status. If it has this status and has a RIPE NCC mntner as the “mnt-lower:”, then it is an administrative block. All the legacy objects will have the status ‘LEGACY’.

The RIPE NCC has directly issued address space to its members and End Users from the placeholder administrative objects. Again, these are recognised by the “status:” and “mnt-lower:” attribute values. Most allocations to members have a status ‘ALLOCATED PA’. But a few will also have the status ‘ALLOCATED UNSPECIFIED’ or ‘ALLOCATED PI’. They will all have the members mntner as “mnt-lower:”.  The assignments made by the RIPE NCC will have a status ‘ASSIGNED PI’ or ‘ASSIGNED ANYCAST’.

Within the hierarchy, these allocations and assignments made from the administrative blocks are on the same level. They all have the placeholder objects as their parent. All of these allocations and assignments are required to have a reference to an organisation object. Although the “org:” attribute is syntactically optional in an inetnum object, this requirement is set by software business rules.

The member allocation objects are partly managed by the RIPE NCC and partly by the member. Because of this joint management, there are two maintainers on the object as the “mnt-by:” - these are the RIPE NCC maintainer and the LIR's default maintainer. If no default maintainer is present yet, the LIR must select it on the LIR Portal account details page. After doing this, the default maintainer will be reflected on all existing and new objects that have joint responsibility. Business rules determine which attributes can only be changed by the RIPE NCC and which ones can be changed by the LIR.

The same principle applies to the assignments made from these administrative blocks. These are jointly managed by the RIPE NCC and either the End User or the sponsoring organisation. The sponsoring organisation is a RIPE NCC member who handles the End User’s administration for this resource with the RIPE NCC.

An assignment is the lowest level of the hierarchy. There can be no more specific objects. For the allocations, the hierarchy can continue down several levels of more specific objects. All objects more specific to the allocation are created and managed in the RIPE Database by the member organisation, not by the RIPE NCC.

The allocation can be partitioned to match the member organisation’s business structure, or part of it can be sub-allocated to another organisation. Finally, any part of it may be assigned to an End User. Again, the assignment is the lowest level or end point for that part of the hierarchy. All of these levels can be recognised by the status values.

The top-level legacy objects are also jointly managed by the resource holder and the RIPE NCC. Some values in these objects have business rules preventing the resource holder from changing the values. All other parts of the object can be edited in the same way as any other object. Below the top-level legacy object, the resource holder can create as many levels of hierarchy as they wish. All the objects in this legacy hierarchy will have the same status value of ‘LEGACY’. So it is not possible to identify, for example, sub-allocations or assignments in the legacy hierarchy by status.

4.2.4.2 Description of Attributes Specific to the INETNUM Object

  • “inetnum:” – This specifies a range of IPv4 addresses that the inetnum object presents. The range may be one or more addresses.

Addresses can be expressed in either range or prefix notation. If prefix notation is used, the software will convert this to range notation and an informational message will be returned to the user. The end address must always be greater than or equal to the start address.

The range notation expresses addresses as 32-bit whole numbers in dotted quad notation. Leading zeros from any quad will be removed by the software and an informational message will be returned to the user.

  • “netname:” – This is a name given to a range of IP address space. It is recommended that the same netname be used for any set of assignment ranges used for a common purpose, such as a customer or service.
  • “descr:” - A short description related to the object.
  • “country:” – This identifies a country using the ISO 3166-2 letter country codes. It has never been specified what this country represents. It could be the location of the head office of a multi-national company or where the server centre is based or the home of the End User. Therefore, it cannot be used in any reliable way to map IP addresses to countries.
  • “geoloc:” - The geolocation coordinates for the resource as longitude and latitude. All more specific objects to the inetnum object containing this attribute inherit this data.
  • “language:” - Identifies the language as a two-letter code from the ISO 639-1 language code list. All more specific objects to the inetnum object containing this attribute inherit this data.
  • “org:” – single-valued to make sure that only one organisation is responsible for this resource.

This is a required attribute. In some cases, there are business rules to ensure that it is present. If the inetnum object is (jointly) maintained by the RIPE NCC then the object must have an “org:” attribute.

  • “sponsoring-org:” – references an organisation object representing the sponsoring organisation that is administratively responsible for the resource. This value is generated by the software and synchronised with the registry information. If a resource is no longer subject to a contract with the sponsoring organisation, or a contract is signed with a new sponsoring organisation, this will be updated in the registry information for this resource. The inetnum object in the RIPE Database will then be synchronised with the changes. A user cannot set, remove or change this value. An inetnum object can be created without this attribute. The software will generate the correct value if it is required. The RIPE NCC will remove the attribute during a period in-between the ending of a contract with one sponsoring organisation and the signing of a contract with a new sponsoring organisation.
  • “status:” – The status is used to show the different types of data stored in an inetnum object and the relative positions within a hierarchy. It can take one of these values:
    • ‘ALLOCATED UNSPECIFIED’ – This is mostly used to identify blocks of addresses for which the RIPE NCC is administratively responsible. Historically, a small number of allocations made to members have this status also.
    • ‘ALLOCATED PA’ – These are allocations made to members by the RIPE NCC.
    • ‘ALLOCATED PI’ – This is mostly used to identify blocks of addresses from which the RIPE NCC makes assignments to end users. Historically, a small number of allocations made to members have this status also.
    • ‘LIR-PARTITIONED PA’ – This is to allow partitioning of an allocation by a member for internal business reasons.
    • ‘LIR-PARTITIONED PI’ – This is to allow partitioning of an allocation by a member for internal business reasons.
    • ‘SUB-ALLOCATED PA’ – A member can sub-allocate a part of an allocation to another organisation. The other organisation may take over some of the management of this sub-allocation. However, the RIPE NCC member is still responsible for the whole of their registered resources, even if parts of it have been sub-allocated. Provisions have been built in to the RIPE Database software to ensure that the member is always technically in control of their allocated address space.
    • ‘ASSIGNED PA’ – These are assignments made by a member from their allocations to an End User.
    • ‘ASSIGNED PI’ – These are assignments made by the RIPE NCC directly to an End User. In most cases, there is a member acting as the sponsoring organisation who handles the administrative processes on behalf of the End User. The sponsoring organisation may also manage the resource and related objects in the RIPE Database for the End User.
    • ‘ASSIGNED ANYCAST’ - This address space has been assigned for use in TLD anycast networks.
    • ‘LEGACY’ – These are resources that were allocated to users before the RIPE NCC was set up.
    • ‘NOT-SET’ – There are some very old objects in the RIPE Database where the status was unknown when the “status:” attribute was introduced. When it became a mandatory attribute, these objects were given this status value. When contact is made with the organisations holding these resources, the real status value will be determined.
  • “mnt-lower:” – This attribute references mntner objects that provide a set of authorisation tokens used for hierarchical object creation. These tokens are used to authorise the creation of the one-level more specific (child) objects to the inetnum with the “mnt-lower:” attribute. If there is no “mnt-lower:” attribute, the “mnt-by:” authorises the creation of the child objects. This is explained in more detail in the section, 'Authorisation'.
  • “mnt-domains:” - This attribute references mntner objects that provide a set of authorisation tokens used for domain object creation for reverse delegation. These tokens are used to authorise the creation of the domain objects whose prefixes are contained within the range of addresses set by the inetnum with the “mnt-domains:” attribute. Depending on the hierarchical relationship between the inetnum and domain objects, the “mnt-lower:” and “mnt-by:” attributes may also be used. This is explained in more detail in the section, 'Authorisation'.
  • “mnt-routes:” - This attribute references mntner objects that provide a set of authorisation tokens that may be used for route object creation. Authorisation for route object creation is the most complex. This is explained in more detail in the section, 'Authorisation'.
  • “mnt-irt:” - This attribute is not a reference to a mntner object. It references an irt object, which is a contact data object, like the role object. Authorisation is required from the irt object to be able to add this reference. These references apply in a hierarchical way. Therefore, where an “irt:” attribute is included, all more specifics to that inetnum object inherit the reference. This is explained in more detail in the section on Abuse Handling.