[arin-ppml] ARIN-PPML Digest, Vol 167, Issue 80
Fernando Frediani
fhfrediani at gmail.com
Sun May 12 19:10:14 EDT 2019
I have seen proposals in different RIRs from /23 to /20 and to be honest
I believe that /22 is fine for newcomers or to a maximum or as a maximum
an existing one. /23 is way too small and almost useless to most cases.
Even /22 are not much addresses but enough for someone to exist in the
Internet and do a proper CGNAT or similar techniques in order to have a
proper Dual-Stack.
Anything that comes back into the pool should always favor newcomers or
those who haven't reached a /22 yet. To be honest I don't see much sense
for a newcomer ISP not to receive a /22 straight upon first request.
Being an ISP is already justification to receive a /22.
Anything beyond that should happen via transfers for existing members.
Fernando
On 12/05/2019 15:16, Michael Williams wrote:
> I’m fine increasing the wait list time with a larger size allocation
> such as a /21.
>
> Michael
>
> Sent from my iPhone
>
> On 12 May 2019, at 14:10, David Farmer <farmer at umn.edu
> <mailto:farmer at umn.edu>> wrote:
>
>> With the current policy, as proposed by the AC's response, as long as
>> you have less than a total of three /22s or less direct resources,
>> you could get up to two additional /22s but not a /21 all at once.
>> Note if you have no direct resources at all, you can get up to 5 /22s
>> over a time of at least a year and a quarter plus the wait time on
>> the list.
>>
>> Smaller blocks over time seem fairer as it allows more entities a bit
>> at the apple. We could allow /21s instead of /22s but then we should
>> probably extend the time before you can get back on the list to 6 months.
>>
>> it would be good to hear from more people on these issues.
>>
>> On Sun, May 12, 2019 at 10:55 AM Christian Lefrançois
>> <clefranc at diffusionfermont.ca <mailto: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
>> <mailto:arin-ppml-bounces at arin.net>> De la part de
>> arin-ppml-request at arin.net <mailto:arin-ppml-request at arin.net>
>> Envoyé : 10 mai 2019 18:33
>> À : arin-ppml at arin.net <mailto: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 <mailto: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 <mailto:arin-ppml-request at arin.net>
>>
>> You can reach the person managing the list at
>> arin-ppml-owner at arin.net <mailto: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
>> <mailto:scottleibrand at gmail.com>>
>> To: Michael Williams <michael.williams at glexia.com
>> <mailto:michael.williams at glexia.com>>
>> Cc: Kevin Blumberg <kevinb at thewire.ca
>> <mailto:kevinb at thewire.ca>>, "arin-ppml at arin.net
>> <mailto:arin-ppml at arin.net>"
>> <arin-ppml at arin.net <mailto: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
>> <mailto: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 <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto:tpruitt at stratusnet.com>>
>> > *Cc:* arin-ppml at arin.net <mailto: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 <mailto: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
>> <mailto: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 <mailto: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 <mailto:info at arin.net>> <info at arin.net
>> <mailto:info at arin.net>>
>> >
>> > *To: *
>> >
>> > arin-ppml at arin.net <mailto: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
>> <mailto: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 <mailto: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
>> <mailto: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 <mailto:info at arin.net> if you
>> experience any issues.
>> >
>> >
>> >
>> >
>> > --
>> >
>> > ===============================================
>> > David Farmer Email:farmer at umn.edu <mailto:Email%3Afarmer 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
>> <mailto: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 <mailto: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
>> <mailto: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 <mailto: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
>> <https://lists.arin.net/pipermail/arin-ppml/attachments/20190510/fd735392/attachment.html>>
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> ARIN-PPML mailing list
>> ARIN-PPML at arin.net <mailto: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
>> <mailto: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 <mailto:info at arin.net> if you
>> experience any issues.
>>
>>
>>
>> --
>> ===============================================
>> David Farmer Email:farmer at umn.edu <mailto:Email%3Afarmer 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
>> <mailto: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 <mailto: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/20190512/a182db71/attachment.htm>
More information about the ARIN-PPML
mailing list