[arin-ppml] ARIN-PPML Digest, Vol 167, Issue 80
Scott Leibrand
scottleibrand at gmail.com
Sun May 12 12:16:41 EDT 2019
The IPv4 transfer market is perfectly legitimate: ARIN policy allows for the transfer of addresses to specified recipients who need them (like you) from organizations who can afford to renumber out of underutilized space if you pay them a market rate to do so.
If your only objection to the transfer market is that you’d have to pay money (to avoid paying your upstreams), then I don’t think you have a valid objection to this policy proposal. Even under this proposal, you have a higher chance of getting a small block from ARIN, maybe even one that will meet your current needs, vs. the previous situation where everyone would hold out for /21s or larger that ARIN simply doesn’t have. And you can go acquire another /22 from the transfer market when you need it.
If you really think that ARIN should be preferentially subsidizing your business model, you could propose a policy proposal attempting to define what IPv4-based business models are so beneficial to the Internet community that they should be funded by the entire ARIN community, not just their customers/members. But no such argument has been made (or is possible IMO) for “all entities that need fewer than 2048 but more than 1024 IPv4 addresses”. The closest we’ve come is for IPv6, where the subsidy is tiny by comparison: https://www.arin.net/participate/policy/nrpm/#6-5-9-community-network-allocations
Scott
> On May 12, 2019, at 8:55 AM, Christian Lefrançois <clefranc at diffusionfermont.ca> wrote:
>
> Hi all,
> I agree with Michael Williams, I'm in the same situation, and on the waiting
> list for more than a year. I need a /21, to finally be free of upstream
> providers fees for IPv4 addresses (lease). I'll gladly give back all
> resources to ARIN in the eventuality of end of business, or if I can manage
> to switch completely to IPv6. Not interested with the IPv4 black market.
>
> I'm in charge of a very small coop cable operator, my market is about 1900
> customers, we're hooking members as fast as possible, will reach (and
> surpass) /22 in a few months. So, in my perspective, /21 should be the
> maximum.
>
> Christian Lefrançois
> Diffusion Fermont
>
> -----Message d'origine-----
> De : ARIN-PPML <arin-ppml-bounces at arin.net> De la part de
> arin-ppml-request at arin.net
> Envoyé : 10 mai 2019 18:33
> À : arin-ppml at arin.net
> Objet : ARIN-PPML Digest, Vol 167, Issue 80
>
> Send ARIN-PPML mailing list submissions to
> arin-ppml at arin.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.arin.net/mailman/listinfo/arin-ppml
> or, via email, send a message with subject or body 'help' to
> arin-ppml-request at arin.net
>
> You can reach the person managing the list at
> arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
> 1. Re: Fwd: Advisory Council Recommendation Regarding NRPM
> 4.1.8. Unmet Requests (Scott Leibrand)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 10 May 2019 15:32:17 -0700
> From: Scott Leibrand <scottleibrand at gmail.com>
> To: Michael Williams <michael.williams at glexia.com>
> Cc: Kevin Blumberg <kevinb at thewire.ca>, "arin-ppml at arin.net"
> <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Fwd: Advisory Council Recommendation
> Regarding NRPM 4.1.8. Unmet Requests
> Message-ID:
> <CAGkMwz5Bhp=SLVipZtx=fpu9ni2_uk_L3Tt1=5Lb3x5rNPQJtg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> There are organizations of all sizes with direct unmet needs for address
> blocks of all sizes up to /16 or larger. The waitlist is *not* intended to
> meet all such requests: it simply can't be done, because the free pool is
> empty, and there is way more demand than supply at a price of ~$0. Rather,
> the waitlist is intended to make sure that returned/reclaimed addresses are
> not stuck at ARIN, but rather distributed in a way that serves a useful
> purpose.
>
> Organizations that need large blocks of address space should be going to the
> market to acquire them, and transferring them to meet their justified need.
> Some organizations that need smaller blocks of addresses, but not urgently,
> can try to get them via the waitlist. But the more larger allocations we
> allow from reclaimed space, the fewer such organizations can be served, and
> the longer they'll need to wait. So it makes sense to me to have a
> relatively stringent maximum wait list allocation, particularly since that
> also reduces the financial reward to fraudulent actors and/or those
> attempting to game the system.
>
> So I support this policy, including the /22 maximum.
>
> -Scott (representing only myself)
>
> On Fri, May 10, 2019 at 3:19 PM Michael Williams <
> michael.williams at glexia.com> wrote:
>
>> Representing ARIN member organisation GLEXI-3 *I do not support* the
>> policy as written. Maximum wait list allocation should be at least a /21.
>> We have a direct unmet need for a /21 right now.
>>
>> My argument is if an organisation receives an allocation from the wait
>> list they should have to return that allocation directly to ARIN if
>> not used. There should be no organisation to organisation transfer
>> allowed for IP allocations received from the wait list. That?d
>> eliminate all these crazy /16 allocation sales that we see now.
>>
>> Regards,
>>
>> Michael
>>
>> Sent from my iPhone
>>
>> On 10 May 2019, at 17:36, Kevin Blumberg <kevinb at thewire.ca> wrote:
>>
>> David,
>>
>>
>>
>> I would rather see a limit or delay on the number of times an
>> organization can go back to the waitlist than prevent organizations
>> from getting any space from the wait list.
>>
>>
>>
>> Would I be more supportive if the number was larger? I don?t believe
>> that is the right control mechanism, so no.
>>
>>
>>
>> Limiting the size to a /22 was a way of distributing fairly to as many
>> organizations as possible and limiting the abuse vector.
>>
>>
>>
>> Thanks,
>>
>> Kevin
>>
>>
>>
>>
>>
>> *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *David
>> Farmer
>> *Sent:* Friday, May 10, 2019 4:44 PM
>> *To:* Tom Pruitt <tpruitt at stratusnet.com>
>> *Cc:* arin-ppml at arin.net
>> *Subject:* Re: [arin-ppml] Fwd: Advisory Council Recommendation
>> Regarding NRPM 4.1.8. Unmet Requests
>>
>>
>>
>> If /20 is too small is their another size you would propose? a /19 or
>> a
>> /18 maybe? Do you have an argument for why that is the right number?
>>
>>
>>
>> When the AC looked at this there was strong support for limiting the
>> size of the organization that could qualify to ensure these resources
>> went to smaller organizations. But there were varying opinions on what
>> that size should be, /20 was just the option with the most support amongst
> the AC.
>>
>>
>>
>> This formulation also provides a limit on how many times an
>> organization can go back to the waiting list, allowing smaller
>> organizations more times to return to the waiting list, while limiting
>> lager organization to fewer times to return to the waiting list. And
>> organizations that already have more than a /20 must go to the market.
>>
>>
>>
>> A /20 limit, gives a new organization (with no resources) the
>> opportunity receive up to 5 allocations from the waiting list if they
>> got a /22 each time.
>>
>> A /19 limit would allow a new ISP up to 9 allocations if they got a
>> /22 each time.
>>
>> A /18 limit would allow a new ISP up to 17 allocations if they got a
>> /22 each time.
>>
>>
>>
>> Please realize the waiting list is primarily a mechanism to ensure
>> resources are not stuck at ARIN, it should not be seen as a reliable
>> means of obtaining resources.
>>
>>
>>
>> Thanks
>>
>>
>>
>> On Fri, May 10, 2019 at 2:45 PM Tom Pruitt <tpruitt at stratusnet.com> wrote:
>>
>> I do not support the new text, specifically the limit of a /20 per
>> organization.
>>
>>
>>
>> The limiting of an organization to an aggregate of a /20 is a huge
>> hinderance of the ability of a smaller ISP to compete. A smaller ISP
>> that can win business on service and cost could lose that same business
> due to
>> simply recouping the IPv4 costs. Large ISPs will often give the IPs away
>> to win the business, and it costs them nothing as they received their IPV4
>> space for free. Additionally, many smaller ISPs operate in outlying
> areas
>> where IPv6 adoption will likely be slow, which will also hinder their
>> ability to push IPv6. I?m not sure at what point an organization
> becomes
>> ?large?, but the smaller organizations are the ones that will be hurt
>> by this limit.
>>
>>
>>
>> What happens to organizations that are currently on the wait list that
>> have an aggregate of a /20 or more? Do they still get a /22. Some of
>> those organizations have been on the list for over a year. Assuming they
>> played by the rules and made decisions based on the assumption that
>> they would get an allotment of IPv4 addresses, denying them any
>> addresses after they have waited a year or more could be very
>> detrimental to them. These policy changes and decisions affect the
>> smaller entities greatly, and they need some clarity.
>>
>>
>>
>>
>>
>>
>>
>> Thanks,
>>
>> Tom Pruitt
>>
>> Network Engineer
>>
>> Stratus Networks
>>
>>
>>
>> <image002.png>
>>
>>
>>
>> *From:* ARIN-PPML <arin-ppml-bounces at arin.net> *On Behalf Of *Andrew
>> Dul
>> *Sent:* Monday, May 6, 2019 4:09 PM
>> *To:* arin-ppml at arin.net
>> *Subject:* [arin-ppml] Fwd: Advisory Council Recommendation Regarding
>> NRPM 4.1.8. Unmet Requests
>>
>>
>>
>> Hello,
>>
>> I'd like to bring your attention to another issue that may have been
>> lost in the flurry of other emails. We are currently in a 14 day
>> feedback period for the AC's response to the Board's suspension of the
> wait-list.
>> Please note the following updated text for the wait-list. Your
>> comments on this updated text are welcome.
>>
>> Thanks,
>>
>> Andrew
>>
>>
>>
>> ===
>>
>> If no such block is available, the organization will be provided the
>> option to be placed on a waiting list of pre-qualified recipients,
>> listing both the block size, for which the organization is qualified,
>> which in the case of the waiting list shall not be larger than a /22,
>> and the smallest block size acceptable to the organization. An
>> organization may not be added to the waiting list if it already holds
>> IPv4 resources amounting in aggregate to more than a /20 of address
>> space. Resources received via section 4.1.8 may not be transferred within
> 60 months of the issuance date.
>>
>>
>>
>> -------- Forwarded Message --------
>>
>> *Subject: *
>>
>> [arin-ppml] Advisory Council Recommendation Regarding NRPM 4.1.8.
>> Unmet Requests
>>
>> *Date: *
>>
>> Mon, 29 Apr 2019 11:16:31 -0400
>>
>> *From: *
>>
>> ARIN <info at arin.net> <info at arin.net>
>>
>> *To: *
>>
>> arin-ppml at arin.net
>>
>>
>>
>> Subject:
>>
>> At their 16 January Meeting, the Board of Trustees suspended issuance
>> of number resources under NRPM section 4.1.8.2. (Fulfilling Unmet
>> Needs), and referred NRPM section 4.1.8 to the ARIN Advisory Council
>> for their recommendation.
>>
>> The Advisory Council has provided its recommendation, and per ARIN's
>> Policy Development Process, the recommendation is hereby submitted to
>> the Public Policy Mailing List for a community discussion period of 14
>> days, to conclude on 13 May.
>>
>> Once completed, the Board of Trustees will review the AC?s
>> recommendation and the PPML discussion.
>>
>> The full text of the Advisory Council's recommendation is below.
>>
>> Board of Trustees meeting minutes are available at:
>>
>> https://www.arin.net/about/welcome/board/meetings/2019_0116/
>>
>> For more details on the Policy Development Process, visit:
>>
>> https://www.arin.net/participate/policy/pdp/
>>
>> Regards,
>>
>> Sean Hopkins
>> Policy Analyst
>> American Registry for Internet Numbers (ARIN)
>>
>>
>>
>> Advisory Council recommendation:
>>
>> In accordance with section 10.2 of the ARIN Policy Development
>> Process, the ARIN Advisory Council recommends the following actions to
>> the Board of Trustees in response to the Board?s suspension of part of
>> the operation of sections 4.1.8, 4.1.8.1 and 4.1.8.2 of the Numbering
> Resource Policy Manual:
>>
>> Replace section 4.1.8 as follows, then reinstate the full operation of
>> sections 4.1.8, 4.1.8.1 and 4.1.8.2 immediately.
>>
>> 4.1.8. Unmet Requests
>>
>> In the event that ARIN does not have a contiguous block of addresses
>> of sufficient size to fulfill a qualified request, ARIN will provide
>> the requesting organization with the option to specify the smallest
>> block size they?d be willing to accept, equal to or larger than the
>> applicable minimum size specified elsewhere in ARIN policy. If such a
>> smaller block is available, ARIN will fulfill the request with the
>> largest single block available that fulfills the request.
>>
>> If no such block is available, the organization will be provided the
>> option to be placed on a waiting list of pre-qualified recipients,
>> listing both the block size, for which the organization is qualified,
>> which in the case of the waiting list shall not be larger than a /22,
>> and the smallest block size acceptable to the organization. An
>> organization may not be added to the waiting list if it already holds
>> IPv4 resources amounting in aggregate to more than a /20 of address
>> space. Resources received via section 4.1.8 may not be transferred within
> 60 months of the issuance date.
>>
>> Repeated requests, in a manner that would circumvent 4.1.6, are not
>> allowed: an organization may only receive one allocation, assignment,
>> or transfer every 3 months, but ARIN, at its sole discretion, may
>> waive this requirement if the requester can document a change in
>> circumstances since their last request that could not have been
>> reasonably foreseen at the time of the original request, and which now
> justifies additional space.
>> Qualified requesters whose request cannot be immediately met will also
>> be advised of the availability of the transfer mechanism in section
>> 8.3 as an alternative mechanism to obtain IPv4 addresses.
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>>
>>
>>
>> --
>>
>> ===============================================
>> David Farmer Email:farmer at umn.edu
>> Networking & Telecommunication Services Office of Information
>> Technology University of Minnesota
>> 2218 University Ave SE Phone: 612-626-0815
>> Minneapolis, MN 55414-3029 Cell: 612-812-9952
>> ===============================================
>>
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
>>
>> _______________________________________________
>> ARIN-PPML
>> You are receiving this message because you are subscribed to the ARIN
>> Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> https://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact info at arin.net if you experience any issues.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <https://lists.arin.net/pipermail/arin-ppml/attachments/20190510/fd735392/at
> tachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> https://lists.arin.net/mailman/listinfo/arin-ppml
>
>
> ------------------------------
>
> End of ARIN-PPML Digest, Vol 167, Issue 80
> ******************************************
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20190512/3c78162f/attachment.htm>
More information about the ARIN-PPML
mailing list