Registration Requirements for IPv6 End User Assignments

This proposal has two purposes: to create a new policy that defines the use of new attributes in the RIPE Database and to change the policy text of ripe-481 to require the use of these new database attributes

Summary of Proposal

This proposal has two purposes: to create a new policy that defines the use of new attributes in the RIPE database and to change the policy text of ripe-481 to require the use of these new database attributes.

This proposal will modify the registration requirements for End User assignments as set in section 5.5 of ripe-481 in order to remove the ambiguity from the current text and bring the handling of subsequent allocation requests more in line with the current practice for IPv4.

At the moment the text says that any organisation that makes End User assignments “must register assignment information in a database, accessible by RIRs as appropriate”. Although the text refers to some future distributed model, it does not define what a database is, nor what data it should contain. It only says it has to be granular on End User assignment.

This text has led to a lot of confusion and questions and undoubtedly will lead to differences in the way LIRs will handle this requirement and subsequently in the communication between RIR and LIR.

The new proposed method of registration is largely designed based on the current IPv4 practice, where people do not register individual /32 assignments to End Users but create less specific blocks marking the purpose like 'dynamic pool for DSL customers in place X'. At the point where a subsequent allocation is needed, they then have to prove how many addresses in this pool are used. This system is not a hard requirement from the IPv4 policy but is common practice and is described online.

So instead of not registering anything at all in the public database, the proposal aim to create the same less specific 'supernet' objects. As there is no default assignment size, such objects have to note the assignment size as well. Upon receiving an additional allocation request, the fill percentage of these blocks can then be verified to calculate the HD-ratio.

As an example, one would create <provider-tla>::/36 with an assignment size of /56. A simple MRTG graph over time showing the actual number of assignments or customers can then be generated from the OSS/BSS system or maybe even directly from the DHCPv6 servers involved. This would then satisfy the need to verify the addresses are used efficiently enough and the LIR meets the HD ratio required. It does so in a way to which most LIRs are already familiar and without the need to disclose to any specific information on individual End Users or the resource they hold.

Current Policy Text (if modification)

5.5 Registration

When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register assignment information in a database, accessible by RIRs as appropriate. (Information registered by an RIR/NIR may be replaced by a distributed database for registering address management information in future). Information is registered at the granularity of End Site assignments. When more than a /48 is assigned to an organisation, the assigning organisation is responsible for ensuring that the address space is registered in an RIR/NIR database.

RIR/NIRs will use registered data to calculate the HD-ratio at the time of application for subsequent allocation and to check for changes in assignments over time.

IRs shall maintain systems and practices that protect the security of personal and commercial information that is used in request evaluation, but which is not required for public registration.

New Policy Text:

5.5 Registration

When an organisation holding an IPv6 address allocation makes IPv6 address assignments, it must register these assignments in the appropriate RIR database. These registrations can either be made as individual assignments or by inserting an object with a status field of 'SUB-ASSIGNED PA' where the "assignment-size:" attribute contains the size of the individual assignments made to End Users. When more than a /48 is assigned to an organisation, it must be registered in the database as a separate object with status 'ASSIGNED PA'.

In case of an audit, or when making a request for a subsequent allocation, the LIR must be able to present statistics showing the number of individual assignments made in all objects with a status of 'SUB-ASSIGNED PA' in such a way that the RIR is able to calculate and verify the actual HD-ratio.

Rationale: