Changes to 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.

This proposal will modify the insert: <span class="external-link"> registration requirements req insert: </span> uirements 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) Text:

insert: </blockquote>

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. delete: </p> delete: <h2> delete: </h2> registration.] insert: </p>

New Policy Text:

insert: <p>

  insert: </p>

insert: </blockquote>

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 a object with a status field of 'SUB-ASSIGNED PA' value of 'AGGREGATED-BY-LIR' where the "assignment-size:" 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'. 'ASSIGNED'.

In case of an audit, 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' 'AGGREGATED-BY-LIR' in such a way that the RIR is able to calculate and verify the actual HD-ratio.

a. Arguments supporting the proposal

At the moment, moment the text has a lot of ambiguity on what the exact specification of 'a database' is or what the actual operational requirements are to make sure the RIR can access it. This can lead to discussions between the RIR and LIR on the method in which the data is presented or on what data is presented.

The /32 boundary once seemed big enough and nobody expected a huge amount of additional allocation requests. However, However a lot of the bigger LIRs have requested an allocation for testing purposes, sometimes purposes and without a full and detailed deployment plan. As the deployment of IPV6 towards End Users becomes imminent, imminent there likely will likely be a rise be a raise in the number of additional allocation requests.

This proposal adds will add more transparency to the address allocation and assignment process as well as providing provide more insight on the actual address space used. This can aid in determining the overall efficiency of the address usage within the RIR region as well as providing some statistics on the rate of IPv6 deployment. delete: </p> delete: <p> There deployment itself. insert: </p>

As there are only few networks that have made substantial numbers of End User assignments, assignments and where those legacy assignments do exist it is relatively easy to add these to the database as no details on the End Users are required.

Subsequent to the verification need originating from the address policy, giving a hint on the size of individual assignments might also be beneficial to other parties or processes such as geolocation services or the automatic aggregation of black- or whitelists in the security community.

b. Arguments Opposing the Proposal

This proposal implies however does imply a new status attribute, which attribute. This can lead to confusion for by database users, especially since the "assignment-size:" “assignment-size:” attribute is mandatory required only in for specific cases.

There also might also be risks involved in publishing the size of individual assignments. These can be security risks involved in publishing the size of individual assignments. There may such as targeted attacks, but this can also be regarded as a business risks in making public risk as there will be more data publicly available on numbers the number of End Users.

  insert: </p>

insert: <b> A. RIPE NCC's Understanding of the Proposed Policy insert: </b> insert: </h3>

The RIPE NCC sees in this proposal an opportunity to improve the structure of IPv6 Internet resource registration and increase the reliability and usefulness of the registry. insert: </p>

insert: <b> B. Impact of Policy on Registry and Addressing System insert: </b> insert: </h3>

insert: <b> Address/Internet Number Resource Consumption: insert: </b> insert: <br />
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <b> Fragmentation/Aggregation: insert: </b> insert: <br />
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <b> C. Impact of Policy on RIPE NCC Operations/Services insert: </b> insert: </h3>

insert: <b> Registration Services: insert: </b> insert: <br />
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <b> Billing/Finance Department: insert: </b> insert: <br />
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <b> RIPE Database: insert: </b> insert: <br />
After analysing the data that is currently available, the RIPE NCC does not anticipate that any significant impact will be caused if this proposal is implemented. insert: </p>

insert: <b> D. Legal Impact of Policy insert: </b> insert: </h3>

After analysing the data that is currently available, the RIPE NCC does not anticipate that the implementation of this proposed policy will cause any significant legal implications. insert: </p>

However the RIPE NCC would like to make the following notification regarding privacy aspects of the proposal. Recording personal data in the RIPE Database must be in compliance with the data protection legislation. In particular before anyone updates the RIPE Database with personal data, they must obtain the informed and expressed consent of the data subject. insert: </p>