<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hi,<br>
<br>
am 22.09.2017 um 16:50 schrieb Anna Wilson:<br>
</div>
<blockquote
cite="mid:0B3FF616-F266-495D-88E8-41190C660CEC@heanet.ie"
type="cite">Hi Tom,
<div class=""><br class="">
</div>
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On 22 Sep 2017, at 15:37, Tom Hill <<a
moz-do-not-send="true"
href="mailto:tom.hill@bytemark.co.uk" class="">tom.hill@bytemark.co.uk</a>>
wrote:</div>
<div class="">
<div class=""><br class="">
Because I don't see a way in which this policy will
change anyone's<br class="">
behaviour, or incentivise them differently over the
current policy, I<br class="">
don't believe it needs to be changed. If you would like,
we can take<br class="">
IPv6 adoption out of the argument completely, and I can
still be solely<br class="">
against it for the reason of changing the status quo on
acceptable<br class="">
prefix sizes for no perceivable gain to anyone.<br
class="">
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>The proposal doesn't have a goal of changing anyone's
behaviour or incentivising anyone. The goal is to quadruple
the number of remaining IPv4 applications that RIPE NCC can
fulfil.</div>
<div><br class="">
</div>
<div>So the gain is to those three quarters of applications
that would otherwise be unsuccessful.</div>
</div>
</div>
</blockquote>
<br>
As pointed out by others already, the change from /22 to /24 just
quadruples the per-IP price tag. Due to the cost involved, 2017-03
may shortly reduce the amount of IPv4 space assigned to "new
entrants". From my perspective, this effect will be short lived, as
simply more "PI-LIRs" will be created to get IPv4 space before it's
gone (and/or getting even more expensive).<br>
<br>
<blockquote type="cite">
<div>I'd gently suggest the counter:</div>
<div><br class="">
</div>
<div>- that new entrants are most likely to support IPv6 (because
very little IPv4 can be got);</div>
</blockquote>
<br>
If you finally hold your expensive v4 space, best to make it work
for the money. But each new dual-stacked or, worse, v4-only service
and user lessens the pressure on anyone to switch to v6.<br>
<br>
<blockquote type="cite">
<div>- that even fully IPv6-ed new entrants need some IPv4 to make
IPv6 work;</div>
</blockquote>
<br>
I've read this point multiple times in this thread; but which part
of IPv6 needs public IPv4 addresses to make IPv6 work? These are
completely independent protocols (which is part of the problem and
part of the solution ;)), used to create independent networks.<br>
<br>
<blockquote type="cite">
<div>- reaching IPv4 runout while this is still the case will hurt
those new entrants disproportionately;</div>
</blockquote>
<br>
Isn't this the way of live? IPv4 is considered legacy, and the RIRs
do a tremendous job at prolonging it's life span with their last /8
policies.<br>
<br>
But IPv4 has no future, it's address space is effectively gone
(except for 240/4 …). How long shall we prolong IPv4's infirmity? At
current rate (and policies), RIPE NCC will run out of IPv4 addresses
to allocate somewhere around 2020 or 2021? This was meant to happen
some time, and it will happen some time, regardless of the policy in
place.<br>
<br>
Another issue I see with the proposed policy: With 2017-03 in place,
new LIRs[1] would be severly restricted in their business options,
compared to ripe-680. I see no change in the situation since the
last /8 policy went into effect that would justify this. Everything
runs as expected.<br>
<br>
I'd support a change of 5.2, though: instead of serving the last 64
LIRs with a /22, use that /16 for 256 /24 allocations (or less,
depending on routability at that point) along ARINs current
policy[2].<br>
<br>
Regards,<br>
-kai<br>
<br>
[1]
<a class="moz-txt-link-freetext" href="https://www.ripe.net/manage-ips-and-asns/resource-management/faq/independent-resources/def-terms">https://www.ripe.net/manage-ips-and-asns/resource-management/faq/independent-resources/def-terms</a><br>
[2] <a class="moz-txt-link-freetext" href="https://www.arin.net/policy/nrpm.html#four10">https://www.arin.net/policy/nrpm.html#four10</a><br>
<br>
</body>
</html>