<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi<br>
Organizations with no allocation would be free to choose anything
between a /22 and /24, if the smaller fits their needs.<br>
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. <br>
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.</p>
<p>Best regards<br>
Fernando</p>
<div class="moz-cite-prefix">On 11/2/2026 1:39 PM, Eric C. Landgraf
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20261102163911.jz7czpxfks46yr7b@bicycle">
<pre wrap="" class="moz-quote-pre">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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">/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:
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">
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 <a class="moz-txt-link-rfc2396E" href="mailto:arin-ppml-bounces@arin.net"><arin-ppml-bounces@arin.net></a> *On Behalf Of *Fernando
Frediani
*Sent:* Friday, October 30, 2026 9:58 AM
*To:* <a class="moz-txt-link-abbreviated" href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>
*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 <a class="moz-txt-link-rfc2396E" href="mailto:mike@sum.net"><mike@sum.net></a>
<a class="moz-txt-link-rfc2396E" href="mailto:mike@sum.net"><mailto:mike@sum.net></a> 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 <a class="moz-txt-link-rfc2396E" href="mailto:hannigan@gmail.com"><hannigan@gmail.com></a>
<a class="moz-txt-link-rfc2396E" href="mailto:hannigan@gmail.com"><mailto:hannigan@gmail.com></a>
*Sent:* Wednesday, October 28, 2026 5:55 PM
*To:* Mike Burns <a class="moz-txt-link-rfc2396E" href="mailto:mike@iptrading.com"><mike@iptrading.com></a>
<a class="moz-txt-link-rfc2396E" href="mailto:mike@iptrading.com"><mailto:mike@iptrading.com></a>
*Cc:* Eric C. Landgraf <a class="moz-txt-link-rfc2396E" href="mailto:echarlie@vt.edu"><echarlie@vt.edu></a>
<a class="moz-txt-link-rfc2396E" href="mailto:echarlie@vt.edu"><mailto:echarlie@vt.edu></a>; <a class="moz-txt-link-abbreviated" href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>
*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
<a class="moz-txt-link-rfc2396E" href="mailto:arin-ppml@arin.net"><arin-ppml@arin.net></a> <a class="moz-txt-link-rfc2396E" href="mailto:arin-ppml@arin.net"><mailto:arin-ppml@arin.net></a>
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 <a class="moz-txt-link-rfc2396E" href="mailto:arin-ppml-bounces@arin.net"><arin-ppml-bounces@arin.net></a>
<a class="moz-txt-link-rfc2396E" href="mailto:arin-ppml-bounces@arin.net"><mailto:arin-ppml-bounces@arin.net></a> On Behalf Of 'Eric C.
Landgraf'
Sent: Wednesday, October 28, 2026 1:37 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>
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 (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any
issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are
subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any
issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</blockquote>
<pre wrap="" class="moz-quote-pre">
</pre>
<blockquote type="cite">
<pre wrap="" class="moz-quote-pre">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
<pre wrap="" class="moz-quote-pre">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
</body>
</html>