[address-policy-wg] IPv6 PA/PI - restarting discussion after failed 2013-06 proposal

Hi everyone,

2013-06 has failed to become policy and we all understand that it 
presented such big changes that it became too complex.

I would like to restart that discussion and see what are the 
problems/failures of the IPv6 policies (both PI and PA) and come up with 
a proposal to fix these problems.

I'd like to start with the first 4 problems that I have noticed:

#1. In IPv4 a PI user can connect a customer to it's network or allow a 
customer to use a dedicated server using one IP address. This limitation 
had been extended to up to a /29 (in case redundant connections were 
offered - ie:VRRP) but most of the cases I have encountered were using 
either a /32 or a /30.

Currently, the IPv6 policy states that the minimum a customer should use 
is a /64. And because the minimum per customer is a /64, when someone 
would actually use IPv6 PI for a customer, it would make an assignment 
of a subnet and violate the policy. I've heard of people using /128s for 
the servers of their customers and sharing the same vlan amongst 
multiple customers in the same /64. Others are just requesting a/48 PI 
and expect never to come back for more (therefore, could not care less 
about policies). Others just know that the RIPE NCC has no way to see if 
they sub-assign parts of the /48 PI, so they just request a /48 PI, 
promise never to sub-assign and later on, forget about the promise.

Therefore, I propose that the first change we make to the IPv6 PI policy 
is that where a /64 could be used per customer (regardless of the 
service offered to that customer) only if it is registered properly in 
the RIPE Database.
The change would allow PI users to sub-assign in IPv6, but only small 
(?) amounts of space and only if they actually register the assignment.


#2. Second problem I've noticed is the fact that LIRs can receive /32s 
(and up to /29s) only by asking. On the other hand, if you do not want 
to become a RIPE NCC member or just can not, you are forced to use IPv6 
- a /48. Additionally, this IPv6 PI can only be used for your own 
infrastructure and not to provide any service (other than SaaS) to your 
customers without violating the policy (see problem statement #1). One 
could request more than a /48 but it would need to demonstrate that it 
has two or more sites that have different routing policies or 
demonstrate that it has a need for more than 65K subnets.

I would like to introduce the IPv6 PI ALLOCATION. This time, the PI 
allocation could be made to the PI user and the user could actually make 
assignments from it. The PI allocation would be just as large as the PA 
Allocation and the price for it would be no less than 50% of the 
membership fee (Off course, the fees can only be voted upon at the GM 
and the example is just purely theoretical).

This would introduce that 'additional registry' which we never knew how 
to name during the discussions of 2013-06 and would allow PI users to 
request/receive a /29 from which they could make assignments.

Everyone will say that /32 or /29 will become the new /48. Well, that 
may be true, on the other hand, it may be the price that could keep the 
number of large PI Allocations low.
Additionally,  we could add an arbitrary limit. For example, say that 
you can request an IPv6 PI Allocation only if you already have x hundred 
customers that will receive an assignment from you immediately.


#3. Minimum assignment size

The policy says that the minimum assignment size is a /64. However, the 
RIPE Database does not enforce this rule and I have seen /128s registered.

for example:
inet6num:       2001:b70:f000::/112
inet6num:       2001:820:0:1:1::1000/116
inet6num:       2a01:2f0f:ffff:ffff:100:1000::1/128

There are over 700 inet6num objects registered which are below a /64. If 
we take the policy literally, all these assignments currently violate 
the policy. Therefore, I think we should either change/remove the 
minimum assignment size or have the RIPE Database block the creation of 
any IPv6 assignment smaller than a /64.


#4. fix utilisation and hd-ratio vs assignment size

While the HD-ratio is being calculated in terms of /56s, the policy says 
(at point 5.4.1.) that the minimum assignment that can be made is a /64. 
Furthermore, as you can see above, /128s can be registered in the RIPE 
Database as well.

If we will continue allowing the registration of less than /56 
assignments, it will be difficult to almost impossible to the IPRAs to 
actually calculate what is the HD-ratio of an IPv6 allocation. While now 
it is too early to see additional IPv6 allocation requests, if we keep 
doing things as we've been doing for the past years, we will end up in a 
few years with a huge mess in the registry and the impossibility to 
calculate the HD-ratio without applying random procedures.

A very simple and quick fix would be to say that if any prefix is 
registered, the whole /56 that includes the prefix is in use. But then, 
we may see people registering/using /128s from different /56s just to 
reach the HD-ratio for an additional allocation. Would that still be 
considered an efficient usage?
An other option would be to change the HD-ratio calculation to the 
actual number of IP addresses used and consider all the IP addresses 
from an assignment used if correctly registered in the RIPE Database.


Once we have worked out whether these 4 issues are indeed flaws in the 
policy or not and whether we want them fixed or not, I would like to 
hear your opinion in what else should be modified in the IPv6 policies. 
I will then collect all the feedback, probably present it at the next 
RIPE Meeting, and start to discuss an other approach/policy proposal to 
achieve what 2013-06 failed to achieve.

cheers,
elvis
-- 
<http://v4escrow.net> 	


  Elvis Daniel Velea


    Chief Business Analyst

Email: elvis at V4Escrow.net <mailto:elvis at v4escrow.net>
US Phone: +1 (702) 475 5914
EU Phone: +3 (161) 458 1914

Recognised IPv4 Broker/Facilitator in:

This message is for the designated recipient only and may contain 
privileged, proprietary, or otherwise private information. If you have 
received this email in error, please notify the sender immediately and 
delete the original.Any other use of this email is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20140304/52960616/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 5043 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20140304/52960616/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.png
Type: image/png
Size: 11971 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20140304/52960616/attachment-0001.png>