You are here: Home > Participate > Policy Development > Policy Proposals > Registration Requirements for IPv6 End User Assignments

Changes to Registration Requirements for IPv6 End User Assignments

Legend (+) Added (-) Deleted
Changed Tag Added Tag Deleted

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

delete: <br /> delete: <table class="grid listing"> insert: <table class="listing grid">

If the proposal reaches consensus, as well as creating a new RIPE Document (see Draft Document Tab), this proposal will modify the existing RIPE Document: “ IPv6 Address Allocation and Assignment Policy

Below we indicate how the existing RIPE Document will change

insert: <i> insert: </i> insert: <blockquote>

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: <blockquote>
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.

 

insert: </div>

Rationale: Rationale

a. Arguments supporting the proposal

delete: <p> insert: <p style="padding-left: 30px; ">

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.

delete: <p> insert: <p style="padding-left: 30px; ">

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.

delete: <p> insert: <p style="padding-left: 30px; ">

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>

insert: <p style="padding-left: 30px; ">

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.

delete: <p> insert: <p style="padding-left: 30px; ">

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

delete: <p> insert: <p style="padding-left: 30px; ">

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.

delete: <p> insert: <p style="padding-left: 30px; ">

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: <h2>

insert: <b> Impact Analysis: insert: </b> insert: </h2>

insert: <div>
insert: <table class="listing grid"> insert: <tbody>insert: <tr>insert: <th>insert: </tr>insert: </tbody>insert: </table>
Note: In order to provide additional information related to the proposal, details of an impact analysis carried out by the RIPE NCC are documented below. The projections presented in this analysis are based on existing data and should be viewed only as an indication of the possible impact that the policy might have if the proposal is accepted and implemented. insert: </th>
insert: <p>

  insert: </p>

insert: <h3>

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

insert: <p style="padding-left: 30px; ">

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: <h3>

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

insert: <p style="padding-left: 30px; ">

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: <p style="padding-left: 30px; ">

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: <h3>

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

insert: <p style="padding-left: 30px; ">

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: <p style="padding-left: 30px; ">

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: <p style="padding-left: 30px; ">

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: <h3>

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

insert: <p style="padding-left: 30px; ">

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>

insert: <p style="padding-left: 30px; ">

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>

delete: <div> delete: <blockquote> delete: </blockquote> delete: <h2> Abstract delete: </h2>

This document policy proposal could result in the production of one new RIPE Document and an update to an existing document.To help understand what would change, we have produced draft documents. insert: </p>

insert: <h3>

New RIPE Document insert: </h3>

insert: <p>

This policy, if approved will produce a new RIPE Document that describes the new value of the "status:" attribute and the "assignment-size:" of the inet6num object.

delete: <h3> 1.0 Motivation delete: </h3> delete: <p> For verification of efficient use of allocated space, there is a requirement for LIRs to keep records of IPv6 address assignments made to End Users. However, for calculating the efficiency (HD-ratio) there is no need to keep track of personal data associated with these assignments. The number and size of the assignments is sufficient to calculate the HD-ratio and verify efficiency. delete: </p> delete: <p> To standardise these registrations and to provide an open and transparent method of verification, this document introduces a new value insert: <ul> insert: <h3>

Updated RIPE Document insert: </h3>

insert: <p>

This policy, if approved, will result in changes to the RIPE Policy Document insert: <a class="internal-link" href="resolveuid/eefd779fcf78b266160131b9d78af2f3" data-val="eefd779fcf78b266160131b9d78af2f3" data-linktype="internal"> IPv6 Address Allocation and Assignment Policy insert: </a> . This would result in a new attribute called "assignment-size:". This new value allows the creation of delete: <b> inet6num delete: </b> objects indicating them as aggregated End User assignments. The "assignment-size:" attribute is used to indicate the size of the individual End User assignments in this aggregate. delete: </p> delete: <h3> 2.0 Database Objects Affected delete: </h3> delete: <p> Only inet6nums object may contain a "status:" value of "SUB-ASSIGNED PA" or attribute called "assignment size:". When the inet6num has a status of "SUB-ASSIGNED PA", the "assignment-size:" attribute is mandatory. In all other cases, the attribute is optional. delete: </p> delete: <h3> 3.0 Usage delete: </h3> delete: <p> The <SUB-ASSIGNED PA> feature allows registration of individual End User assignments by means of a less specific aggregate object containing multiple assignments of the same size, which is indicated in the "assignment size:" attribute. delete: </p> delete: <p> This allows for efficient registration of assignments when there is either neither the need nor the possibility to register details of individual End Users - such as the use of dynamic address pools for broadband Internet access. delete: </p> delete: <p> When creating a pool for 1000 /56 assignments, the object would be similar to: delete: </p> delete: <blockquote> delete: <pre> <…> delete: <br /> inet6num: 2000::/46 delete: <br /> delete: <br /> status: SUB-ASSIGNED PA delete: <br /> delete: <br /> assignment-size: 56 delete: <br /> delete: <br /> <…> delete: </pre> delete: </blockquote> delete: <p> This indicates a block of /46 internally further split into /56 End User assignments. Optionally, the "remarks:" and "description:" attributes can be used to further clarify usage or give hints such as "used for dynamic assignments". delete: </p> delete: <h3> 4.0 Functionality delete: </h3> delete: <p> When creating or updating an inet6num object, the database will check the value of the "status:" attribute according to the following rules: policy section.

  • The delete: <b> inet6num delete: </b> object may contain an attribute called "assignment-size:". delete: </li> delete: <li> The value of the "assignment-size:" attribute must be less than the size of the object's bit mask. delete: </li> delete: <li> A value of "SUB-ASSIGNED PA" is allowed if a one level less specific object contains a "status:" attribute with a value of "ALLOCATED-BY-RIR", "ALLOCATED-BY-LIR" or "ASSIGNED". delete: </li> delete: <li> When an delete: <b> inet6num delete: </b> contains a "status:" value of "SUB-ASSIGNED PA" the "assignment-size attribute:" becomes mandatory. DRAFT: insert: <a class="internal-link" href="resolveuid/6a6122207e3898e1b3bc6930281d2f27" data-val="6a6122207e3898e1b3bc6930281d2f27" data-linktype="internal"> IPv6 Address Allocation and Assignment Policy insert: </a>
delete: </div>
DRAFT: Value of the "status:" and "assignment-size:" attributes in inet6num objects for sub-assigned PA space Draft Documentation
Get Involved

The IPv6 Working Group is for anyone with an interest in the next generation Internet Protocol. The activities of the WG include education and outreach, sharing deployment experiences and discussing and fixing operational issues. To post a message to the list, send an email to [email protected] Please note that only subscribers can post messages.

RIPE Forum

The RIPE Forum is an additional way to participate in RIPE community mailing list discussions using a web-based interface rather than an email client.

Check out the forum

Please contact if you need more information.

Stay up to date!

Follow @PDO_RIPE_NCC on Twitter.