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

I totally agree with Stefan and I support what he said here. ipv6 should be
a must.
On Jan 22, 2015 6:42 PM, "Stefan Schiele" <st at sct.de> wrote:

>  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 <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/99ffa497/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/99ffa497/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/99ffa497/attachment-0001.png>