RIPE Database Search

By pressing the "Search" button you explicitly express your agreement with the RIPE Database Terms and Conditions.

Service Announcements
  • All of our services are operating normally.

Documenting IPv6 Assignments in the RIPE Database

This page outlines the new method for documenting IPv6 assignments. There are some rules, constraints and options.

Introduction

The RIPE community approved RIPE Policy Proposal 2010-06, Registration Requirements for IPv6 End User Assignments on 10 February 2011. This requires all IPv6 address assignments to be documented in the RIPE Database. To reduce the workload, a new method of documentation has been implemented in the RIPE Database. This allows a group of multiple assignments of the same size and referencing the same contacts to be aggregated into one object.

This page outlines the new method for documenting IPv6 assignments. There are some rules, constraints and options.

Basic outline

An LIR receives an IPv6 allocation from the RIPE NCC. This will be represented in the RIPE Database as an inet6num object with the "status: ALLOCATED-BY-RIR". The LIR can create any hierarchical arrangement of inet6num objects more specific to this allocation with the "status: ALLOCATED-BY-LIR". At some point in this hierarchy, the LIR will make assignments. These can be more specific, either directly to the ALLOCATED-BY-RIR inet6num object or any one of the ALLOCATED-BY-LIR inet6num objects.

At this point, an inet6num object with the "status: AGGREGATED-BY-LIR" can be created. This object will represent a block of IPv6 addresses from which assignments are made. All the assignments from this block will have the same size. This size will be documented in the "assignment-size:" attribute. A typical hierarchy may look like this:

    /24  status: ALLOCATED-BY-RIR
|-----------------------------------------------------------------------------------------------|


/25 status: ALLOCATED-BY-LIR /25 status: ALLOCATED-BY-LIR
|---------------------------------------------|-------------------------------------------------|


/32 /32
status: status:
AGGREGATED-BY-LIR AGGREGATED-BY-LIR
assignment-size: assignment-size:
48 50
|------------------|----------------------|

This indicates that assignments will be made from the first AGGREGATED-BY-LIR inet6num object and will all have a prefix length of /48. All assignments from the second AGGREGATED-BY-LIR inet6num object will have a prefix length of /50.

What about the assignments?

It is not required to document all the individual assignments in the RIPE Database. Therefore, inet6num objects with "status: ASSIGNED" do not need to be created that are more specific to the AGGREGATED-BY-LIR inet6num objects. It is sufficient to know that they exist more specific to the AGGREGATED-BY-LIR objects and have the prefix length indicated by the "assignment-size:" attribute.

In some parts of the RIPE NCC service region, local laws may require all assignments to be publicly displayed. The inet6num objects with "status: ASSIGNED" can optionally be created that are more specific to the AGGREGATED-BY-LIR inet6num objects. In this case the parent AGGREGATED-BY-LIR inet6num objects can still be created for documentation purposes.

It is still possible to create assignments that are more specific to an inet6num object with "status: ALLOCATED-BY-RIR" or "status: ALLOCATED-BY-LIR" directly.

Different assignment sizes

The above arrangement shows how to create large numbers of assignments of a fixed size. Sometimes it may be necessary to create a batch of assignments of a different size from a pool of address space already set aside for assignments of a larger size. This can be done with a second level of AGGREGATED-BY-LIR inet6num objects. Continuing the above example, suppose an LIR wants to make batches of assignments with prefix lengths of /56 and /64 from the first AGGREGATED-BY-LIR with assignment size 48. AGGREGATED-BY-LIR inet6num objects can be created that are more specific to the first AGGREGATED-BY-LIR inet6num object.

    /25  status: ALLOCATED-BY-LIR
|-----------------------------------------------------------------------------------------------|


/32 status: AGGREGATED-BY-LIR /32 status: AGGREGATED-BY-LIR
assignment-size: 48 assignment-size: 50
|------------------------------------------------|-------------------------------|


/48 /48
status: status:
AGGREGATED-BY-LIR AGGREGATED-BY-LIR
assignment-size: assignment-size:
56 64
|------------------|----------------------|

Note that in all cases, the assignment-size value must be greater than the prefix length of the containing inet6num object. Also note that the more specific AGGREGATED-BY-LIR inet6num objects must have a prefix length equal to the assignment-size value of the less specific object.

Only two levels of AGGREGATED-BY-LIR inet6num objects are allowed in a hierarchy. So the following alternative arrangement is not allowed.

    /25  status: ALLOCATED-BY-LIR
|-----------------------------------------------------------------------------------------------|


/32 status: AGGREGATED-BY-LIR /32 status: AGGREGATED-BY-LIR
assignment-size: 48 assignment-size: 50
|------------------------------------------------|-------------------------------|


/48
status:
AGGREGATED-BY-LIR
assignment-size:
56
|--------------------------|

/56
status:
AGGREGATED-BY-LIR
assignment-size:
64
|-------------------|

Some other general rules

  • inet6num objects with "status: ASSIGNED PI" and "status: ASSIGNED ANYCAST" can not be aggregated
  • Attribute "assignment-size:" is optional in inet6num objects
    • It is required when the inet6num object has "status: AGGREGATED-BY-LIR"
    • It cannot be used in any other inet6num objects
  • The assignment-size value must be greater than the prefix length of the containing inet6num object
  • Only one "assignment-size:" attribute is allowed in an inet6num object
  • The assignment-size value cannot be changed after the inet6num object has been created
  • The status of an existing inet6num object cannot be changed to or from "AGGREGATED-BY-LIR".