You're looking at an older version: 1
The current (published) version is 2This 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 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.
|
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 |
|---|
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.
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.
At the moment, the text has a lot of ambiguity on the exact specification of 'a database' 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, a lot of the bigger LIRs have requested an allocation for testing purposes, sometimes without a full and detailed deployment plan. As the deployment of IPV6 towards End Users becomes imminent, there will likely be a rise in the number of additional allocation requests.
This proposal adds more transparency to the address allocation and assignment process as well as providing more insight on the actual address space used. This can aid in determining the overall efficiency of address usage within the RIR region as well as providing statistics on the rate of IPv6 deployment.
There are only few networks that have made substantial numbers of End User 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.
This proposal implies a new status attribute, which can lead to confusion for database users, especially since the "assignment-size:" attribute is mandatory only in specific cases.
There might also be security risks involved in publishing the size of individual assignments. There may also be business risks in making public more data on numbers of End Users.