[arin-ppml] ARIN 58 Table Topic - If the Waitlist didn't exist, what would?
Fernando Frediani
fhfrediani at gmail.com
Tue Nov 3 15:29:54 EST 2026
Hi
Organizations with no allocation would be free to choose anything
between a /22 and /24, if the smaller fits their needs.
I personally consider a /24 may be too small for the intention to make a
newcomer able to walk with its own legs, get some revenue and transfer
additional blocks when they need in the future, but it may depend on the
type of business, so a limit of up to a /22 seems reasonable if the
organization is willing to wait longer.
The import change is to only issue space from the waiting list to
newcomers and to not grandfather those who already have something in the
current waiting list.
Best regards
Fernando
On 11/2/2026 1:39 PM, Eric C. Landgraf wrote:
> Hi Fernando,
>
> One observation made during the policy experience report at ARIN 58 is
> that operators requesting a /22 from the waitlist often do not get
> served at all, or at least not in a timely manner. ARIN is freeing up
> lots of /24s in tracking down ownership, but current policy requires
> them to issue aggregates---they cannot fulfil a request for a /22 with 4
> /24s.
>
> For this to be workable (and I will echo Mike Burns' request that you
> draft a proposal), any policy wanting to hand out more than a /24 from a
> successor to the waitlist must amend 4.1.6.
>
> Regards,
> Eric C. Landgraf
> Virginia Tech
>
> On Oct 30 13:17, Fernando Frediani wrote:
>> /24 is nothing as it is /22, so at least give a maximum of a /22 so they can
>> get sizeable minimum enough to get some revenue and transfer additional
>> space in the future if needed. Equally important is not to grandfathering
>> those currently in the list who have more than a /22
>>
>> Fernando
>>
>> On 10/30/2026 12:58 PM, Mike Burns wrote:
>>> Hi Fernando,
>>>
>>> “I once again urge the community to consider giving out addresses from
>>> the waiting list only to newcomers, those who have no IPv4 at all, up to
>>> a /22 and *not* grandfathering the current list.”
>>>
>>> I agree, for the most part, and also proposed this. Give a /24 to those
>>> without addresses, one time only.
>>>
>>> But it failed to reach consensus, and I supported abandoning it.
>>>
>>> It was Prop-327, filed three years ago.
>>>
>>> Now, do you think it might be worth revisiting it?
>>> If so, I encourage you to write a new proposal.
>>>
>>> Regards,
>>> Mike
>>>
>>> *From:*ARIN-PPML<arin-ppml-bounces at arin.net> *On Behalf Of *Fernando
>>> Frediani
>>> *Sent:* Friday, October 30, 2026 9:58 AM
>>> *To:*arin-ppml at arin.net
>>> *Subject:* Re: [arin-ppml] ARIN 58 Table Topic - If the Waitlist didn't
>>> exist, what would?
>>>
>>> This is a great report. Thanks for sharing it Mark
>>>
>>> I once again urge the community to consider giving out addresses from
>>> the waiting list only to newcomers, those who have no IPv4 at all, up to
>>> a /22 and *not* grandfathering the current list.
>>> Those who have something adapt how to live with what they have and when
>>> necessary go to market to transfer. Lowering expectations to receive any
>>> extra allocation from the waiting list helps as well.
>>>
>>> Also agree with the point that making it intentionally unreasonably
>>> difficult to obtain IPv4 has never been a good idea for IPv6 adoption.
>>>
>>> Fernando
>>>
>>> On 10/30/2026 1:21 AM, Mark Van Daele via ARIN-PPML wrote:
>>>
>>> On Oct 28, Eric C. Landgraf wrote:
>>> > It is unfortunate that none of the people actually *using* the
>>> waitlist have chimed in on the mailing list about what getting rid
>>> of the waitlist would mean to them.
>>>
>>> Hey Eric/All,
>>>
>>> I'll take that invitation. For disclosure: I operate MARKVD-NET
>>> (AS402766), a small independent network in the Chicago suburbs
>>> that manages an ARIN /24 recently issued via the waitlist. I would
>>> go through the process again if needed. I've been a lurker for
>>> some time, but excited to get involved in the community.
>>>
>>> Most of the organizations I serve run on a small budget or no
>>> budget. They are mostly volunteer community groups in my area,
>>> whose networks I often support on my own time. Having allocated
>>> space lets me deliver services to them with greater flexibility at
>>> lower costs.
>>>
>>> For networks like these, equipment is not the difficult part. You
>>> certainly don't need a power hungry Cisco router to speak BGP
>>> anymore. Our edge routers are small linux servers running BIRD,
>>> and they handle full tables without issue. When the hardware is
>>> cheap, ipv4 space becomes one of the largest barriers of getting
>>> started, and certainly not a trivial one.
>>>
>>> I don't want to eliminate the waitlist, I'd much rather eliminate
>>> the waiting. ARIN should have a pool of addresses ready for
>>> organizations that can justify the need via the existing NRPM. In
>>> addition to defunct holders as it is today, that pool should come
>>> primarily from holders who have space they cannot justify, often
>>> because they will never *ever* use it all.
>>>
>>> Where I land:
>>>
>>> 1. Leave the current waitlist in 4.1.8 largely as is. The October
>>> distribution shows the waitlist works when space comes back to
>>> ARIN. The problem is supply and not the method of delivery.
>>>
>>> 2. Increase supply through a community appeal and ARIN outreach
>>> encouraging voluntary returns, especially from public
>>> institutions, legacy holders, and government. Many of the largest
>>> ipv4 holdings were issued before ARIN existed to organizations
>>> that would not qualify for as much space under today's rules.
>>> Space that was given freely to public bodies should be returned
>>> freely when it isn't needed or would never realistically be used.
>>>
>>> 3. Give waitlist priority to organizations with no prior ipv4, or
>>> holding a /22 or less. They have the fewest alternatives and might
>>> bring the greatest benefit.
>>>
>>> 4. Don't redirect recovered space to 4.10, it certainly doesn't
>>> need it now and won't for a very long time. At ARIN 54, staff
>>> reported 13,938 /24s remaining in the 4.10 pool, with less than
>>> 400 issued per year. That is more than 34 *years* of supply at the
>>> current rate. The same report noted it would take about 1,727 /24s
>>> to clear the waitlist, against quarterly distributions averaging
>>> around 95 /24s. Recovered space sent to 4.10 would sit idle for
>>> literal *decades* while new operators wait. If anything set a
>>> smaller 4.10 reservation pool (3 years?) and refill it vi 4.1.7 as
>>> blocks arrive. That frees up space to be issued *now* to fill need.
>>>
>>> Two more points, both IMHO:
>>>
>>> - ARIN should not monetize recovered addresses, directly or
>>> through a third party. It directly goes against ARIN's role as a
>>> steward, it turns ipv4 into a walled garden of those who have and
>>> those who can pay, and it rewards holding space rather than using it.
>>>
>>> - ipv6 is the future, and new networks *should* be ipv6 first. My
>>> networks run dual stack where possible and I'm working to move
>>> every service I deliver so it is reachable over ipv6. That said,
>>> nearly every network still needs ipv4 to reach the rest of the
>>> Internet. Encouraging ipv6 adoption is right; penalizing ipv4,
>>> making it intentionally unreasonably difficult to obtain ipv4, or
>>> making ipv6 the only way to get ipv4 shouldn't be the goal and
>>> makes ARIN poor stewards of the resource.
>>>
>>> In conclusion, my question and plea to every large and legacy
>>> holder on this list: Can you reasonably justify your allocated
>>> ipv4 based on current or planned future use? If not, returning the
>>> excess would do more for new operators than any change to the
>>> waitlist. Please be a good steward.
>>>
>>> Thank You,
>>>
>>> Mark Van Daele
>>>
>>> MARKVD-NET (AS402766)
>>>
>>>
>>> On 10/29/2026 2:26 PM, Eric C. Landgraf wrote:
>>>
>>> Hi Martin,
>>>
>>> "Fairness" appears incidental to RFC 7020 and the NRPM; in the
>>> discussion of ARIN-2026-4 I argued against taking the
>>> principle of
>>> fairness out of Section 6 and putting it in Section 1, because
>>> some
>>> policies like §4.10 are inherently unfair (for certain
>>> definitions of
>>> fairness).
>>>
>>> The PDP §1.4.1 does call for "Fair and Impartial Number Resource
>>> Administration", but reading the context, it seems clear to me
>>> that
>>> policy proposals should limit ARIN's discretion in how to enforce
>>> policy---i.e. it says the rules must be imposed fairly, rather
>>> than the
>>> rules must be fair.
>>>
>>> Now, transfers and the waitlist both require a needs-based
>>> justification---yes we know Mike thinks very little of this,
>>> at least
>>> in part because it complicates the business of trading
>>> IPs---but the
>>> material change for end users of sending reclaimed addresses
>>> to the 4.10
>>> pool is that small operators must convincingly deploy IPv6 and we
>>> prevent transfers of new allocations directly from ARIN. And for
>>> operators who cannot justify under 4.10 AND hold less than a
>>> /20 in
>>> aggregate, they are still left with 3 options:
>>>
>>> 1) purchase on the transfer market, justifying need to ARIN;
>>> 2) lease from their ISP or some other organization; or
>>> 3) figure out how to qualify for 4.10 space.
>>>
>>> At present, I suspect that (1) and (2) will actually be much
>>> cheaper for
>>> organizations than (3): a /24 leases for about $2000/a and
>>> sells for
>>> about $7000, based on the best data I can readily get. This is an
>>> absolutely *trivial* cost compared to the capital investment in
>>> equipment and connectivity involved in running even a small
>>> network, and
>>> substantially less than the annual rent and power for a rack
>>> at an IXP.
>>> The straw man of a "little guy" isn't running on a 6509 he
>>> found on the
>>> side of the road, and if he is, IPs cost less than his power!
>>> The needs
>>> justification requirement presumably helps deflate prices of the
>>> transfer market, by raising the bar required for speculative
>>> address
>>> purchases, and the organizations actually able to purchase
>>> addresses
>>> speculatively are almost certainly aware that doing so hurts
>>> their
>>> customers' ability to use their services.
>>>
>>> It is unfortunate that none of the people actually *using* the
>>> waitlist
>>> have chimed in on the mailing list about what getting rid of the
>>> waitlist would mean to them. I do not know what that means,
>>> but it does
>>> not give me a lot of confidence in there even being a
>>> non-strawman
>>> argument for keeping the waiting list.
>>>
>>> Eric C. Landgraf
>>> Virginia Tech
>>>
>>> On Oct 28 19:21, Martin Hannigan wrote:
>>>
>>> Mike,
>>>
>>> I don’t need AI to make post slop for me on this issue.
>>> “Uniqueness and
>>> conservation" isn't the whole mission. RFC 2050 and the
>>> NRPM introduce fair
>>> distribution alongside conservation and aggregation as
>>> goals, and needs
>>> based assessment has always been a “rule” for fairness.
>>> Not just an
>>> efficiency rule. (rathole alert) If ARIN were only a
>>> directory it wouldn’t
>>> be issuing resources.
>>>
>>> Warm regards,
>>>
>>> -M<
>>>
>>>
>>>
>>> On Wed, Oct 28, 2026 at 18:09 Mike Burns<mike at sum.net>
>>> <mailto:mike at sum.net> wrote:
>>>
>>>
>>> Hi Marty,
>>>
>>> Forgive me for using your post as my example. I got
>>> the answer below my
>>> signature from AI, as I am interested in a larger
>>> discussion about the
>>> inevitable ingression of AI into policy development.
>>>
>>> Nonetheless, I do stand by its argument. Giving out
>>> free /22s is not going
>>> to change any economic situation, and the IPv4 market
>>> has moved the debate
>>> into a different realm.
>>>
>>> RIRs are for uniqueness and conservation. Not for
>>> equalizing little guys
>>> and big guys. And these days, price offers more
>>> conservation than anything
>>> else. But as I also said, the waiting list is small
>>> potatoes, and it is
>>> actually functioning quite well.
>>>
>>> Although there was that subject for the lunch table…
>>>
>>> Regards,
>>>
>>> Mike
>>>
>>>
>>>
>>> Hi Martin,
>>>
>>> Yes, I think that became an important rationale for
>>> it: giving smaller
>>> organizations access to IPv4 without requiring them to
>>> compete in the
>>> transfer market with much larger buyers.
>>>
>>> But I don't think that necessarily argues for
>>> maintaining the waiting list
>>> indefinitely.
>>>
>>> We already exclude organizations holding more than a
>>> /20 and limit
>>> waiting-list distributions to a /22. If the objective
>>> now is to make the
>>> remaining recovered IPv4 serve a public-policy purpose
>>> rather than simply
>>> enter the market, 4.10 seems to me the better
>>> destination.
>>>
>>> It preserves non-market access to scarce IPv4, but
>>> ties that access
>>> directly to IPv6 deployment.
>>>
>>> So I agree with the equity concern. I am questioning
>>> whether the waiting
>>> list remains the best mechanism for addressing it.
>>>
>>> Regards,
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>> *From:* Martin Hannigan<hannigan at gmail.com>
>>> <mailto:hannigan at gmail.com>
>>> *Sent:* Wednesday, October 28, 2026 5:55 PM
>>> *To:* Mike Burns<mike at iptrading.com>
>>> <mailto:mike at iptrading.com>
>>> *Cc:* Eric C. Landgraf<echarlie at vt.edu>
>>> <mailto:echarlie at vt.edu>;arin-ppml at arin.net
>>> *Subject:* Re: [arin-ppml] ARIN 58 Table Topic - If
>>> the Waitlist didn't
>>> exist, what would?
>>>
>>>
>>>
>>> Mike,
>>>
>>>
>>>
>>> Wasn’t the point of the waitlist equity with the big
>>> $corp big $$budgets?
>>> Competition and fairness?
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> -M<
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Oct 28, 2026 at 16:43 Mike Burns via ARIN-PPML
>>> <arin-ppml at arin.net> <mailto:arin-ppml at arin.net>
>>> wrote:
>>>
>>> Hi Eric,
>>>
>>> I think we agree on the cleanest solution.
>>>
>>> I encourage you to draft a proposal to deal with
>>> returned addresses in a
>>> manner that doesn't perpetuate the waiting list.
>>> It is an opportune moment, with the list having
>>> recently received a
>>> substantial allocation and the decks somewhat cleared.
>>>
>>> In the long run, this is small potatoes.
>>> I think establishing a cutoff date, grandfathering the
>>> current list, and
>>> allowing it to wither on the vine would be the best
>>> approach.
>>>
>>> I don't think the failure to reach consensus in the
>>> past is much of a
>>> barrier.
>>>
>>> Regards,
>>>
>>> Mike
>>>
>>> -----Original Message-----
>>> From: ARIN-PPML<arin-ppml-bounces at arin.net>
>>> <mailto:arin-ppml-bounces at arin.net> On Behalf Of 'Eric C.
>>> Landgraf'
>>> Sent: Wednesday, October 28, 2026 1:37 PM
>>> To:arin-ppml at arin.net
>>> Subject: Re: [arin-ppml] ARIN 58 Table Topic - If the
>>> Waitlist didn't
>>> exist,
>>> what would?
>>>
>>> On Oct 28 13:12, Mike Burns wrote:
>>>
>>> ARIN is not a charity; that would not be consonant
>>> with its purpose.
>>>
>>> Moving the proceeds one step away does not
>>> eliminate the conflict. If
>>> the police direct ticket revenue to a foundation
>>> they created or
>>> selected, the incentive problem has not
>>> disappeared; it has merely
>>> been moved.
>>>
>>> I do not support the blurring of incentives
>>> between institutional
>>> self-enrichment and enforcing the law equally. So
>>> why do this with
>>> ARIN, even at the one remove you propose?
>>>
>>> An alternate framing: this is equivalent to when your
>>> county or town
>>> auctions off property (thru a 3rd party) to pay
>>> back-tax on it. In many,
>>> perhaps most cases, we can't find the deeded "owner"
>>> of the resource, there
>>> is no entail, and someone forgot to pay their RSP fees
>>> for some length of
>>> time: as ARIN, we want to recover those fees.
>>>
>>> Under that framing, do we have a real conflict of
>>> interest? Does the
>>> facilitator take all the proceeds after the RSP fees
>>> and transfer fees are
>>> paid, or does ARIN get a fixed return if there's a
>>> profit?
>>>
>>> I tend to agree with you that getting rid of
>>> everything that isn't
>>> effectively 4.10 space is probably the cleanest
>>> solution, since needs
>>> justification under 4.10 is still extant with the
>>> extra provisio that you
>>> have to be deploying IPv6. But as you noted, that did
>>> not reach consensus
>>> at
>>> the time it was last proposed, so there is value in
>>> exploring other
>>> potential policies.
>>>
>>> Eric C. Landgraf
>>> Virginia Tech
>>> _______________________________________________
>>> 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 contactinfo 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 contactinfo 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 contactinfo 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 contactinfo 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 contactinfo 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 contactinfo at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20261103/0f83373a/attachment.htm>
More information about the ARIN-PPML
mailing list