4.2.3 Description of the INET6NUM Object

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

Attribute Name    Presence    Repeat     Indexed
inet6num: mandatory single primary/lookup key
netname: mandatory single lookup key
descr: mandatory multiple
country: mandatory multiple
geofeed: optional single
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
abuse-c: optional single inverse key
status: mandatory single
assignment-size: optional* 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 inet6num object contains information on allocations and assignments of IPv6 address space resources. This is one of the main elements of the RIPE Internet Number Registry. Hierarchy of INET6NUM Objects

The inet6num objects cover many different types of data in the RIPE Database. The policy on issuing IPv6 addresses in the RIPE NCC service region explains more about the process of allocating and assigning addresses. This policy has changed a number of times over the years and some of the data in the RIPE Database was set up under previous policy conditions. The following paragraphs try to 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. This root object is there for data management reasons. It does not mean the RIPE NCC has any administrative authority over the whole IPv6 address space.

The next level down in the hierarchy after the root object includes placeholder objects representing the blocks of address space that the RIPE NCC is administratively responsible for. Most allocations to members are from the placeholder objects. However, there are also some allocations to members that have no parent placeholder object. All of these objects, from the root object down to and including the allocations to members, have the same status value of ‘ALLOCATED-BY-RIR'. There are no differences in the status to distinguish between blocks allocated by IANA to the RIPE NCC and allocations made by the RIPE NCC to members. For this you need to look at the “mnt-lower:”. For the blocks allocated by IANA to the RIPE NCC, the “mnt-lower:” has a RIPE NCC mntner, or it has no “mnt-lower:” which defaults to the “mnt-by:”. For allocations made from these administrative blocks to members, the “mnt-lower:” has the member's mntner. Some objects also include remarks highlighting that they are allocations from IANA to the RIPE NCC.

RIPE NCC also makes assignments to end users and TLD operators from the placeholder administrative objects. These are recognised by the “status:” and the “mnt-by:”. In most cases, these assignments will have the status ‘ASSIGNED PI' or ‘ASSIGNED ANYCAST'. Some of the earlier direct assignments still have the status ‘ASSIGNED'. These can still be recognised, as they should have a RIPE NCC mntner as one of the joint “mnt-by:” attributes.

Within the hierarchy, these allocations and assignments made from the administrative blocks are on the same level. They all have a placeholder object 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 inet6num object, this requirement is set by software business rules.

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 the member can create an aggregation object with part of the allocation. Assignments of a fixed size will be made from this aggregation object. Finally, any part of the address space may be assigned to an End User. Again, the assignment is the lowest level, or an end point, for that part of the hierarchy. All of these levels can be recognised by the status values. Description of Attributes Specific to the INET6NUM Object

  • “inet6num:” – This specifies a block of IPv6 addresses that the inet6num object presents. The block may be one or more addresses.
    Addresses can only be expressed in a prefix notation. The prefix is converted to a canonical format where necessary and an informational message will be returned to the user if this conversion is done.
    The format expresses addresses as a 128-bit number in hexadecimal groups of two bytes with colon separators between the groups . There is the possibility of using a shorthand notation for strings of consecutive zeros. Leading zeros from any two-byte group will be removed by the software. In this case, an informational message will be returned to the user.
  • “netname:” – This is a name given to a range of IP address space. A netname is made up of letters, digits, the underscore character and the hyphen character. The first character of a name must be a letter, and the last character of a name must be a letter or a digit. 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, 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.
  • "geofeed:" – Contains a URL referencing a CSV file containing geolocation data for the resource. The geofeed format is defined in RFC 8805.
  • “geoloc:” – The geolocation coordinates for the resource in decimal degrees notation. Format is latitude followed by longitude, separated by a space. Latitude ranges from [-90,+90] and longitude from [-180,+180]. All more specific objects to the inet6num 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 inet6num 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 inet6num 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. 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 inet6num object in the RIPE Database will then be synchronised with the changes. A user cannot set, remove or change this value. An inet6num 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.
  • “abuse-c:” – This attribute references an abuse contact object. If present, this overrides any existing referenced organisation, or "abuse-c:" attribute present in the hierarchy of this object . This can only be a role object that contains an "abuse-mailbox:" attribute. Making this reference will remove any query limits for that role object, which must only include business data (no personal information).
  • “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-BY-RIR – This is mostly used to identify blocks of addresses for which the RIPE NCC is administratively responsible and allocations made to members by the RIPE NCC.
    • ALLOCATED-BY-LIR – This is equivalent to the inetnum status ‘SUB-ALLOCATED PA'. A member can sub-allocate 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 some parts of it have been sub-allocated to another organisation. 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.
      With the inet6num object there is no equivalent to the inetnum ‘LIR-PARTITIONED' status values allowing partitioning of an allocation by a member for internal business reasons.
    • AGGREGATED-BY-LIR – With IPv6, it is not necessary to document each individual End User assignment in the RIPE Database. If you have a group of End Users who all require blocks of addresses of the same size, say a /56, then you can create a large, single block with this status. The “assignment-size:” attribute specifies the size of the End User blocks. All assignments made from this block must have that size. It is possible to have two levels of ‘AGGREGATED-BY-LIR'.
    • ASSIGNED – 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.
  • “assignment-size:” – This specifies the common size of all individual assignments aggregated into one block with the status ‘AGGREGATED-BY-LIR'. This attribute is required to be present if the inet6num object has this status. The individual assignments do not need to be represented in the RIPE Database. But one or more assignments may be included if the member wishes to specify them for any reason.
  • “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 inet6num 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 inet6num with the “mnt-domains:” attribute. Depending on the hierarchical relationship between the inet6num 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 route6 object creation. Authorisation for route6 object creation is the most complex. This is explained in more detail in the section 'Authorisation'.
  • “mnt-irt:” – Despite its name, 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. So where an “irt:” attribute is included, all more specifics to that inet6num object inherit the reference.