<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi Elvis, <div class="moz-cite-prefix">Am 22.01.2015 um 13:04 schrieb Elvis Daniel Velea: </div> <blockquote cite="mid:54C0E73D.3060801@v4escrow.net" type="cite">[...] <blockquote cite="mid:54C0E13F.9090909@sct.de" type="cite">The proposed policy change will speed up the shortage of IPv4 space; and therefore I still strongly oppose this proposal. </blockquote> 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. </blockquote> 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: <blockquote type="cite">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. </blockquote> 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. <blockquote cite="mid:54C0E73D.3060801@v4escrow.net" type="cite"> <blockquote cite="mid:54C0E13F.9090909@sct.de" type="cite"> 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. </blockquote> 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). </blockquote> 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 <blockquote cite="mid:54C0E73D.3060801@v4escrow.net" type="cite"> Regards, Elvis [1] <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph">https://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-pool-graph</a> <blockquote cite="mid:54C0E13F.9090909@sct.de" type="cite">Kind Regards, Stefan Schiele Am 22.01.2015 um 11:55 schrieb Gert Doering: <blockquote type="cite">Hi, On Wed, Jan 21, 2015 at 11:09:50AM +0000, Daniel Davis wrote: <blockquote type="cite">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. </blockquote> 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 </blockquote> </blockquote> <div class="moz-signature">-- <table border="0" cellpadding="0" cellspacing="0" width="400"> <tbody> <tr> <td valign="top" width="180"><a moz-do-not-send="true" href="http://v4escrow.net" target="_blank"><img src="cid:part2.06010908.07050702@sct.de" style="margin:10px 40px 0px 0px" height="96" width="178"></a></td> <td valign="top" width="200"> <h1 style="font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: rgb(51, 51, 51); margin: 0px 0px 10px;color:#1a9bd7;font-size:14px; ">Elvis Daniel Velea</h1> <h2 style="font-family: Arial, Helvetica, sans-serif; font-size: 14px; color: rgb(51, 51, 51); margin: 0px 0px 10px;color:#74757d;font-size:13px;font-weight:100; ">Chief Executive Officer</h2> Email:�<a moz-do-not-send="true" href="mailto:elvis@v4escrow.net" style="color:#74757d; text-decoration: none; ">elvis@V4Escrow.net</a> US Phone:�+1�(702)�475�5914 EU Phone:�+31�(0)�61458�1914 </td> </tr> <tr> <td colspan="2"> Recognised IPv4 Broker/Facilitator in: </td> </tr> <tr> <td colspan="2"> <img src="cid:part5.00070409.05000703@sct.de" usemap="#Map" style="margin-top:5px;" border="0" height="28" width="376"> </td> </tr> <tr> <td colspan="2" style="padding-left:5px;padding-right:15px;"> 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. </td> </tr> </tbody> </table> <map name="Map"> <area shape="rect" coords="1,2,65,28" href="http://www.ripe.net/lir-services/resource-management/ipv4-transfers/brokers" target="_blank"> <area shape="rect" coords="138,0,234,31" href="http://www.apnic.net/services/become-a-member/manage-your-membership/transfer-resources/transfer-facilitators" target="_blank"> <area shape="rect" coords="297,3,380,40" href="https://www.arin.net/resources/transfer_listing/facilitator_list.html" target="_blank"> </map> </div> </blockquote> </body> </html>