Really, it seems to me that this proposal is another attempt at
eliminating the waiting list for unmet requests.
The first attempt (ARIN auctions the space) met with resistance from
ARIN’s legal team (for good reason), so now this attempts to
sequester the space where it will be
hard to distribute rather than allowing the waiting list to have any
potential to compete with the transfer market.
The proposed targets (4.4 and 4.10 pools) are well stocked and
unlikely to run out in any useful IPv4 lifetime.
As such, restocking them from returned space strikes me as just a way
to sequester this space where it cannot be used.
IMHO, this is counter to ARIN’s mission and should not be allowed.
I oppose the policy as written and as proposed to be amended.
Owen
On Aug 15, 2019, at 13:55 , WOOD Alison * DAS via ARIN-PPML
<[email protected]> wrote:
Thank you for the continued input on this draft policy proposal.
I will be updating the text of the draft policy to include both 4.4
and 4.10 pools. Point of information, the 4.4 pool currently has
approximately 391 /24’s
and 4.10 has approximately 15,753 /24’s available and are not
estimated to run out in the next five years.
Please keep your feedback coming, it is very helpful for the council.
-Alison
From: ARIN-PPML [mailto:[email protected]] On Behalf
Of Fernando Frediani
Sent: Tuesday, July 30, 2019 6:44 AM
To: arin-ppml <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2019-17: Returned
Addresses to the 4.10 Reserved Pool
The point is that you treating IP marketing as something 'natural' or
a 'default route' which it is not and can never be. Natural is to
receive some addresses
from the RIR in first place so they are treated as anyone else was in
the past and have a chance to exist in the Internet with same
conditions as all others.
From that if they need extra space then fine to seek for alternative
ways.
I don't think a new entrants would automatically qualify for 4.10 in
all cases therefore any space left should be targeted also to them as
well to IPv6
transition and critical infrastructure. Otherwise the community will
be creating an artificial barrier to them in order to favor the IP
market while the RIR
still has IPv4 space available for them.
Fernando
On 30/07/2019 10:30, Tom Fantacone wrote:
I would think that the majority of new entrants would need at
least some allocation to help with IPv6 transition and would qualify
for addresses
from the 4.10 pool. Depending on what they receive from that
pool and when, they may not qualify for additional waiting list
addresses and would
have to go to the transfer market for additional IPv4 space
anyway. Those that don't qualify under 4.10 can still get smaller
IPv4 blocks on the
transfer market readily, and the cost for blocks in the /24-/22
range is not prohibitive. Certainly an organization seeking a small
IPv4 block for
multi-homing or other purposes is better off spending a few
thousand dollars to purchase a range than waiting a year on the
waiting list to put
their plans in motion.
Note that while RIPE does not have a reserve pool specifically for
IPv6 transition, the expectation of their final /8 policy was to
allow new entrants
access to IPv4 to assist in this transition. In reality, it didn't
work out that way and most of the /22 allocations to new LIRs from
the final /8 were
to existing organizations who spun up new, related entities in order
to increase their IPv4 holdings:
https://labs.ripe.net/Members/wilhelm/so-long-last-8-and-thanks-for-all-the-allocations
I'm also sympathetic to new entrants, but don't see the current
waiting list as a great help to them vs. the 4.10 pool or the
transfer market, both of
which allow you your allocation in a timely fashion.
Best Regards,
Tom Fantacone
---- On Mon, 29 Jul 2019 11:39:32 -0400 Fernando Frediani
<[email protected]> wrote ----
I find it interesting the idea of privileging the pool
dedicated to
facilitate IPv6 Deployment and I also agree with the comments
below in
the sense that it's not very beneficial do most ARIN members
due to max
size, /22, cannot be holding more than a /20.
However one point I couldn't identify is where the new entrants
stand in
this new possible scenario ? Will they only be able to apply
under the
4.10 reserved pool ? If so for a access/broadband ISPs may be
easier to
fit, but not necessarily for other scenarios and types of ISPs.
Therefore if I didn't miss anything these returned addresses
should also
be able to go to new entrants, not only to 4.10 reserved pool
conditions.
Best regards
Fernando Frediani
On 25/07/2019 17:32, Tom Fantacone wrote:
> I found the wording of the Problem Statement on this one a bit
> confusing. However, after deciphering the effect of the
actual policy
> change I support it.
>
> Essentially, all returned IPv4 space will no longer go to the
waiting
> list but will supplement the 4.10 reserved pool used to
enhance IPv6
> deployment. This essentially kills off the waiting list.
>
> The recent restrictions placed on the waiting list to reduce
fraud
> have hobbled it to the point where it's not very beneficial
to most
> ARIN members. (Max size, /22, cannot be holding more than a
/20).
> It's essentially only useful to new entrants, but those that
go on it
> still have to wait many months to receive their small
allocation. If
> they justify need now, but have to wait that long, how
critical is
> their need if they're willing to wait that long? Small blocks
are not
> terribly expensive and can be quickly gotten on the transfer
market.
> I can understand waiting that long for a large block needed
for a
> longer term project due to prohibitive cost, but I don't see
a great
> benefit to the waiting list as it stands.
>
> Also, if there's any fraud left on the waiting list, this
would kill it.
>
> I would hope, however, that if implemented, those currently
on the
> waiting list would be grandfathered in. I do think some
entities with
> legitimate need got burned on the last change made to the
waiting list.
>
> At 04:05 PM 7/23/2019, ARIN wrote:
>> On 18 July 2019, the ARIN Advisory Council (AC) accepted
>> "ARIN-prop-276: Returned Addresses to the 4.10 Reserved
Pool" as a
>> Draft Policy.
>>
>> Draft Policy ARIN-2019-17 is below and can be found at:
>>
>> https://www.arin.net/participate/policy/drafts/2019_17/
>>
>> You are encouraged to discuss all Draft Policies on PPML.
The AC will
>> evaluate the discussion in order to assess the conformance
of this
>> draft policy with ARIN's Principles of Internet number resource
>> policy as stated in the Policy Development Process (PDP).
>> Specifically, these principles are:
>>
>> * Enabling Fair and Impartial Number Resource Administration
>> * Technically Sound
>> * Supported by the Community
>>
>> The PDP can be found at:
>> https://www.arin.net/participate/policy/pdp/
>>
>> Draft Policies and Proposals under discussion can be found at:
>> https://www.arin.net/participate/policy/drafts/
>>
>> Regards,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>> Draft Policy ARIN-2019-17: Returned Addresses to the 4.10
Reserved Pool
>>
>> Problem Statement:
>>
>> An inconsistent and unpredictable stream of address space is an
>> unsuitable method of populating the waiting list (4.1.8.1) and
>> fulfilling subsequent requests.
>>
>> Policy statement:
>>
>> Change "4.10. Dedicated IPv4 Block to Facilitate IPv6
Deployment" to
>> "4.10 Dedicated IPv4 Pool to Facilitate IPv6 Deployment"
>>
>> Change" When ARIN receives its last /8 IPv4 allocation from
IANA, a
>> contiguous /10 IPv4 block will be set aside and dedicated to
>> facilitate IPv6 deployment. Allocations and assignments from
this
>> block " to "In addition to the contiguous /10 IPv4 block set
aside
>> and dedicated to facilitate IPv6 deployment, all returns and
>> revocations of IPv4 blocks will be added to the pool of space
>> dedicated to the facilitation of IPv6 deployment.
Allocations and
>> assignments from this pool "
>>
>> Change "This block will be subject to a minimum size
allocation of
>> /28 and a maximum size allocation of /24. ARIN should use
sparse
>> allocation when possible within that /10 block." to "This
pool will
>> be subject to a minimum size allocation of /28 and a maximum
sized
>> allocation of /24. ARIN should use sparse allocation when
possible
>> within the pool."
>>
>> Comments:
>>
>> Timetable for implementation: Immediate
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected]).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact [email protected] if you experience any issues.
>
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
