DRAFT: A Comprehensive Review of "Status:" Attribute Values in Inetnum Objects

Shane Kerr
Leo Vegoda

Document ID: ripe-t.b.a
Date: July 2003
O bsoletes: ripe-127, ripe-239

Introduction

This document reviews the “status:” attribute in inetnum objects registered in the RIPE Database. It defines its purpose and format as well as explaining the RIPE Database’s rules for “status:” attributes with regard to creating and modifying inetnum objects.

This draft document is published with a revised draft IPv4 policy document. Both documents describe new values for the “status:” attribute. If agreed by the RIPE community, the IPv4 policy document will keep the explanation of the purpose of each status value. The RIPE Database Reference Manual (ripe-252) and the RIPE Database User Manual: Getting Started (ripe-253) will be updated with the revised rules for database updates.

Table of Contents

1.0 Purpose of the “status:” attribute
2.0 Indication of hierarchy
3.0 Indication of portability
4.0 Delegation of management
5.0 Summary of “status:” attributes
6.0 Pre-RIR registrations
7.0 Registrations without “status:” attributes
8.0 Database rules for “status:” attributes

1.0 Purpose of the “status:” attribute

“Status:” attributes were introduced to inetnum objects to aid database users in determining two factors about an IPv4 range registered as an inetnum object.

Firstly, the “status:” attribute allows users to determine whether the network is an allocation or an assignment. If an allocation, there may be a more specific registration with more appropriate and useful contact information for the network.

Secondly, the “status:” attribute lets a database user know whether a network is portable, or whether it should be announced as part of an aggregated CIDR route. This is useful in determining whether a less specific inetnum object is likely to contain contact information for an upstream provider.

2.0 Indication of hierarchy

The first part of a “status:” attribute indicates the position of the registration within the allocation and assignment hierarchy.

During 2002 the RIPE community discussed the values for “status:” attributes in inet6num objects. It was decided that the text should indicate which type of registry made the registration. The values are “ALLOCATED-BY-RIR”, “ALLOCATED-BY-LIR” and “ASSIGNED”.

We suggest that the convention used in inet6num objects be applied to the “status:” attributes of inetnum objects. Furthermore, we propose to extend the convention to indicate where allocations are made by the IANA.

3.0 Indication of portability

The second part of the “status:” attribute indicates the portability of the networks registered in the database. This is indicated with the suffixes: “PA” (Provider Aggregatable) and “PI” (Provider Independent).

The terms PA and PI are not immediately apparent to End Users who receive IP address space from network operators, nor to Whois users. Furthermore, it is not immediately clear that PA address space cannot be retained following the termination of a connection from the issuing LIR. For this reason we propose to adopt “PORTABLE” for address space that can be moved from one provider to another (currently “PI”), and “NON-PORTABLE” for networks that cannot be retained by organisations changing provider (currently “PA”).

4.0 Delegation of management

The ”PARTITIONED-BY-LIR” feature allows an LIR to document distribution and delegate management of allocated space within their organisation. This can be done by creating one or more inetnum objects with a status of ”PARTITIONED-BY-LIR” under the inetnum object representing an LIR allocation. These objects may reference different contact information and have different values of “mnt-lower:” and “mnt-routes:” attributes.

Addresses that are actually in use, or allocated to a downstream provider, must be registered with a status of ”ASSIGNED” or ”ALLOCATED-BY-LIR”. The ”PARTITIONED-BY-LIR” value does not mean that address space is in use. Registrations with a status of ”PARTITIONED-BY-LIR” are not counted as used.

5.0 Summary of “status:” attributes

“ALLOCATED-BY-IANA”: This address space has been allocated by the Internet Assigned Numbers Authority (IANA), typically to a Regional Internet Registry (RIR).

“ALLOCATED-BY-RIR NON-PORTABLE”: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations must be returned when moving to another provider.

“ALLOCATED-BY-RIR PORTABLE”: This address space has been allocated to an LIR or RIR and all assignments made from it are portable. Assignments can be kept as long as the criteria for the original assignment are met. Sub-allocations cannot be made from this type of address space.

“ALLOCATED-BY-RIR UNSPECIFIED”: This address space has been allocated to an LIR or RIR. Assignments may be “PORTABLE” or “NON-PORTABLE”. This status is intended to document past allocations pre-dating the introduction of CIDR. It is avoided for new allocations. Sub-allocations cannot be made from this type of address space. LIRs wishing to convert an “UNSPECIFIED” allocation to “NON-PORTABLE” should contact the RIPE NCC via e-mail at <lir-help@ripe.net>.

“ALLOCATED-BY-LIR NON-PORTABLE”: This address space has been sub-allocated by an LIR to a network operator that will make assignments from it. All assignments made from it are “NON-PORTABLE”. They must be returned when moving to a service provided by another provider.

“PARTITIONED-BY-LIR NON-PORTABLE”: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with this status is considered unused. When the addresses are used, a more specific inetnum object must be registered.

“EARLY-REGISTRATION”: This is used by the RIPE Database administration when transferring pre-RIR registrations from the ARIN Database. It indicates that the network was registered prior to the current set of policies. Only the RIPE Database administrators can create objects with this value. The value can be changed by database users.

“NOT-SET”: This indicates that the registration was made before the “status:” attributes became mandatory for inetnum objects. The object has not been updated since then. New objects cannot be created with this value. The value can be changed by database users.

“ASSIGNED NON-PORTABLE”: This address space has been assigned to an End User and must be returned when moving to a service provided by another LIR.

“ASSIGNED PORTABLE”: This address space has been assigned to an End User and can be kept when moving to a service provided by another LIR as long as the criteria for the original assignment are met.

6.0 Pre-RIR registrations

Networks issued prior to the creation of the RIRs that operate in the RIPE NCC service region are being transferred to the RIPE Database. These transfers form part of the pan-RIR Early Registration Transfer (ERX) project. Information on the ERX project can be found at:

http://www.ripe.net/projects/erx/

Due to the history of these objects it is not possible to guess an appropriate “status:” attribute value for the networks they describe in the RIPE Database. As such, a status of ”EARLY-REGISTRATION” is used. Only the RIPE Database administrators can create objects with this value. The value can be changed by database users.

7.0 Registrations without “status:” attributes

Some network registrations pre-date the introduction of “status:” attributes. Modifications to the registration data were previously rejected without introducing a “status:” attribute. This could be confusing and so discouraged users from maintaining accurate contact information. The RIPE Database administrators will update these objects with a “status:” attribute value of ”NOT-SET”. This will allow users to more easily maintain the contact information for the network and encourage an accurate status value to be set.

8.0 Database rules for “status:” attributes

For most values of the “status:” attribute, there are two rules that must be enforced:

• The “status:” attribute of the less-specific inetnum object may only have certain values.
• The “status:” attributes of any more-specific inetnum objects may only have certain values.

The allowed values are detailed in Table 1.

The following additional rules apply:

• inetnum objects with a “status:” value of “ALLOCATED-BY-IANA” do not need to have a less-specific inetnum object.
• inetnum objects with a “status:” value of “ALLOCATED-BY-RIR” must be maintained by the RIPE NCC Hostmaster maintainer. This is done with a “mnt-by:” attribute of “RIPE-NCC-HM-MNT”.
• inetnum objects with a “status:” value of “ALLOCATED-BY-LIR” must have no less-specific or more-specific inetnum objects with a “status:” value of “ALLOCATED-BY-LIR”. (This is because an LIR can sub-allocate a block, but it may not be further sub-allocated.)

There are two additional “status:” attributes, which are not included in the table:

• inetnum objects with a “status:” value of “EARLY-REGISTRATION” may only be created by RIPE Database administrators. More-specific inetnum objects added may only have a “status:” value of “ASSIGNED”.
• inetnum objects without a “status:” attribute may have one added with the value “NOT-SET” by the RIPE Database administrators. More-specific inetnum objects may only have a “status:” value of “ASSIGNED”.

These RIPE Database rules are checked when a new inetnum object is created, or when the “status:” attribute is changed on an existing inetnum object. They are not checked when an inetnum object is modified but the “status:” value does not change. This allows other information on existing objects (e.g. contact information) to be changed even if the “status:” values are in violation of the rules.

The rules are also checked on deletion, but this will only affect the RIPE NCC, as the only possible violations on deletion are created by deleting an inetnum object with a “ALLOCATED-BY-IANA” or “ALLOCATED-BY-RIR” “status:” value.

Table 1