[address-policy-wg] IPv6 PI resource question!

Sander,

On Feb 14, 2011, at 2:26 PM, Sander Steffann wrote:

[…]

> I do get the impression here that the current policy (Get a /32 or larger PA for providing access service to customers, or get a /48 PI as a multi homed end-user) is not 'wrong', but that people have problems with the cost of running an LIR. If this is the case I am not sure if we should start changing the policy…

I think you have highlighted a major element of the current system. If you are multi-homed you can either get an IPv6 PI block for whatever a friendly LIR will charge you but possibly less than €100 per year. If you are prepared to pay whatever it costs to sign-up you can get a far larger block and do not have to multi-home.

If some ISPs are going to try to get by on a /48 of PI to avoid the higher fees for becoming an LIR, their subscribers are less likely to be able to get decent sized assignments for their own networks. That means their ability to get the full benefit of the innovation we hope will happen around IPv6 will be diminished.

Perhaps it would be fairer to take one of two options. Either require an LIR to be multi-homed to qualify for a /32 allocation, using the same justification as is used for the current IPv6 PI policy, or remove the artificial distinction between PI and PA for IPv6. That is, make anyone with a block of addresses received directly from the RIPE NCC a member.

Doing the former would probably slow down IPv6 adoption. Doing the latter might well speed it up and it is even possible that the additional of an extra few thousand members would help to lower the annual fee to something that is more accessible to everyone. While that second issue is not strictly on topic for this WG, the fact is that the current billing scheme is built around the policy framework. Changing the policy framework will have knock-on consequences for the billing scheme and it would be irresponsible not to consider the likely impact of a major change to the policy on the billing scheme.

Regards,

Leo Vegoda