[address-policy-wg] Comments on proposal 2014-04 (Remove the IPv6 Requirement for receiving address space)

Hi Elvis,

Am 22.01.2015 um 13:04 schrieb Elvis Daniel Velea:
> [...]
>> The proposed policy change will speed up the shortage of IPv4 space; 
>> and therefore I still strongly oppose this proposal.
> I do not think there will be any difference in how much IPv4 will be 
> requested/allocated from the last /8 if the policy changes. I could 
> easily just use the LIR Portal 3-click request and get an IPv6 
> allocation if it's one of the steps in requesting the IPv4 allocation. 
> It does not mean that I will actually use it or do anything with it. 
> It's just a step in the process of me getting the /22 I wanted.

The current policy actually had a positive effect on our company. The 
main reason for us to sign up as an LIR was to get more IPv4 addresses; 
and since we had to request an IPv6 allocation we wanted to have this 
set up and running. If it had been possible to get that /22 without an 
IPv6 address space we would probably still be using IPv4 only (the IPv4 
address space we currently have is large enough for our business for the 
foreseeable future).

Since this policy had a positive effect on IPv6 awareness for us I 
simply deduce that it should have a positive effect for some other 
companies as well. However, that's not just a guess, there is also 
statistical data regarding this:

Andrea Cima from RIPE NCC wrote on 11 December 2014:
> The RIPE NCC has started allocating /22s from the last /8 on 14 
> September 2012. Since then 4190 IPv6 allocations have been made, out 
> of which 1160 are currently visible in the BGP routing tables.
>
> If we take into consideration the total number of IPv6 allocations 
> made by the RIPE NCC, 8398 IPv6 allocations have been made, out of 
> which 4098 are currently visible in the BGP routing tables.

That means that more than 27% of those IPv6 allocations are really used; 
and that's a quite impressive figure. And I think we can conclude that 
the current policy does have a positive effect on IPv6 deployment. In 
comparison about 49% of all IPv6 allocations are visible in the BGP 
routing table; and that makes that 27% even more impressive.

>>
>> By the way, this proposal would increase prices on the IPv4 transfer 
>> market (due to it speeding up the shortening of the free IPv4 address 
>> space); and that is generally nothing that's good for the community, 
>> either.
>>
> I doubt it will have any effect. The RIPE NCC still has more than a /8 
> in /22s (18.55 mil IP addresses) [1] and can allocate the /22s for at 
> least 5-10 years (my personal opinion is that it will never stop 
> allocating the /22s).

Any increase in IPv6 awareness is good for lessening the demand for IPv4 
addresses. In any free market prices are subject to "supply and demand"; 
anything that reduces supply or increases demand will make prices go up.

I agree with you that the RIPE NCC will not run out of IPv4 address 
space during the next few years. Given the amount of 18.55 mil IP 
addresses this is enough for about 18.000 new /22 allocations. Given the 
data Andrea Cima from RIPE NCC posted on December 11th on this list 4190 
IPv6 allocation have been made between 14 September 2012 (the date when 
the RIPE NCC has started allocation /22s from the last /8) until 11 
December 2014 we could estimate that that address space will be 
sufficient for the next 9-10 years; and even if we take into account 
that the number of new LIRs will increase in the future I still think 
that your 5-10 year range is a reasonable estimate.

Presumably you agree with me that increasing the IPv6 awareness will 
help reducing the demand for IPv4 addresses; my personal opinion is that 
prices for IPv4 addresses on the transfer market will still go up during 
the next years due to the increasing shortage of available IPv4 address 
space; however, if we are successful as a community in convincing new 
and existing LIRs to deploy IPv6 that increase will be lower.

I think that forcing anyone who wants to get address space from the last 
IPv4 to get an IPv6 allocation first won't do any harm to anyone; even 
if a LIR does not want to deploy IPv6 now they can simply put that 
allocation on a shelf and deploy it later. And the impressive statistics 
from the RIPE NCC show that the current policy text helps IPv6 deployment.

Kind Regards,
Stefan

>
> Regards,
> Elvis
>
> [1] 
> https://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph
>
>> Kind Regards,
>>
>> Stefan Schiele
>>
>> Am 22.01.2015 um 11:55 schrieb Gert Doering:
>>> Hi,
>>>
>>> On Wed, Jan 21, 2015 at 11:09:50AM +0000, Daniel Davis wrote:
>>>> Our comment on thIs proposal is:
>>>> We would not support this proposal to Remove the IPv6 Requirement 
>>>> for Receiving Space from the Final /8.
>>>> This is because his policy encourages ripe members to start the 
>>>> process of using ipv6 addresses, and that given the shortage of 
>>>> ipv4 space migration is becoming increasingly important.
>>>> By changing this policy we believe this will give out the wrong 
>>>> signals to the industry about ipv6 migration.
>>> This argument has been brought up before, and I consider it addressed
>>> (by asking the RIPE NCC to send very clear signals regarding IPv6
>>> encouragements to future applicants, and also increasing their general
>>> IPv6 outreach).
>>>
>>> Last Call is there to bring up arguments opposing the proposal that 
>>> have
>>> not been voiced and answered before - like, some completely new angle
>>> hat has been overlooked.
>>>
>>> As always, consensus does not have to be unanimous if there is 
>>> sufficiently
>>> strong support.
>>>
>>> Gert Doering
>>>          -- APWG chair
>>
>>
>
>
> -- 
> <http://v4escrow.net> 	
>
>
>   Elvis Daniel Velea
>
>
>     Chief Executive Officer
>
> Email: elvis at V4Escrow.net <mailto:elvis at v4escrow.net>
> US Phone: +1 (702) 475 5914
> EU Phone: +31 (0) 61458 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/20150122/a23738b3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 5043 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20150122/a23738b3/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 11971 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20150122/a23738b3/attachment-0001.png>