[arin-ppml] ARIN-prop-348 (SPARK Starter Pack for ARIN Resource Kit)

[Daryll Swer]

Owen

Understood on the /32 minimum at ARIN for LIRs.

ARIN policy already fully supports /48 per customer as default assumption.
> Any provider being stingy is not doing so because of limitations in ARIN
> policy.

Interesting, I haven't really seen a lot of American ISPs (besides the ones
built by IPv6-native consultants like yourself) that does /48 per-customer.

Sparse allocation can’t guarantee this and I’m opposed to creating
> reservations that may never get used.

What if, we reserve a /28 per-ORG, and if > 5 years, they never request the
/28, then the remaining space gets taken back for allocating /32s to other
new ORGs who request additional (non-aggregated) /32s?

Sad but true, I guess. They should hire me instead. ;-)

If your hands ever get too full, you know where to forward the work to ;)

That hasn’t been my experience, but YMMV. My experience has been that
> people are generally resistant to policies unless there’s very good reason
> for them.

It varies. One way is if all government services/websites impose IPv6-only
deadline, and they move to IPv6-only stack on their end on said deadline
and IPv4-AFI is wiped from their infrastructure. Then we'll have fun
watching IPv4-only networks scramble.

*--*
Best Regards
Daryll Swer
Website: daryllswer.com
<https://l.shortlink.es/l/54400c3a181acfbf816e00c57ce5f76118212efd?u=2153471>


On Wed, 8 Oct 2025 at 13:30, Owen DeLong <owen at delong.com> wrote:

> Some counter points in line…
>
>
>
>    1. I typically recommend ANY ORG to start with a /32 minimum, easier
>    to scale, avoids renumbering and easier to handle the
>    subnetting/supernetting architecture process long-term.
>
>
> For any ISP org, I agree and this is already default in the ARIN region.
> An ISP can specifically request smaller, but  /32 is available nearly no
> questions asked in current policy.
>
>
>    2. I've long pushed for #1 (outside formal channels like RIR props)
>    and advocate for it explicitly in my IPv6 guide post here
>    <https://blog.apnic.net/2023/04/04/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators/>,
>    which was at some point added to APNIC's BCP materials for IPv6
>    <https://www.apnic.net/community/ipv6/deploy-ipv6/#resources>.
>
>
> Ok
>
>
>    3. SPARK could instead do something similar to what APNIC
>    <https://www.apnic.net/community/policy/resources#a_h_8_0> and RIPE
>    <https://www.ripe.net/publications/docs/ripe-738/#43-minimum-allocation> does,
>    i.e. /32 minimum per-ORG, no questions (well a few questions at most? But
>    this isn't IPv4, so fewer questions, the better up-to a single /32).
>    However, larger allocations should require justification/docs etc.
>
>
> ARIN already does this, so I’m not sure what you think SPARK would change
> in that regard.
>
>
>    4. ISPs will always end up needing more for all kinds of use-cases and
>    by “more” I mean “supernet” aggregates that'll they'll use for internal
>    purposes (not the number of /128s or /80s etc like IPv4 mindset with /31s).
>    This means a larger block (/32 minimum) ensures clean subnetting
>    architecture from day one that avoids renumbering/re-architecture as it
>    scales (explained in more depth in my guide post on #2).
>
>
> With reasonable justification, an ORG can get a larger allocation from
> ARIN under current policy. In fact, I’d argue that ARIN policy may be among
> the most generous, given the nibble boundary roundup and other factors. I
> may be biased as the original architect of that policy, however.
>
>
>    5. /48s (and potentially /44s or /40s) are likely not ideal for
>    RFC9663 — at ISP level, I'm often encouraged (or simply done) /48 per
>    customer (enterprise, residential, all, gets a /48 prefix), if we assume
>    more customers get a single /48 to ensure said customer can do whatever
>    they want with RFC9663, a /40 minimum would not suffice.
>
>
> ARIN policy already fully supports /48 per customer as default assumption.
> Any provider being stingy is not doing so because of limitations in ARIN
> policy.
>
>
>    6. For ISPs that have presence in *more than one state *in large
>    countries like the USA, India etc, I normally do /31 minimum, where one /32
>    is for backbone/internal infrastructure use across the nation (meaning that
>    said /32 should ideally never receive law enforcement requests because
>    there's no human users/eyeballs behind it except the infrastructure itself)
>    and the other /32 depending on the scale is subnetted for customer use in
>    each state. If it was for a large ISP in India (far more population than
>    the USA), I'd do /32 per-state for customers to keep things neatly
>    aggregated at different regional/state levels in both the public DFZ table
>    and internal routing table (keep FIB small as possible).
>
> That’s not allowed in the ARIN region. We round up to nibble boundaries,
> so if you want more than a /32 and can justify a /31, you get a /28.
>
>
>    7. I've done some tiny WISP projects in the USA, these type of ISPs
>    rarely (or never) scale beyond a single-state/small location, a single /32
>    is sufficient for both infra and customer use if subnetted well, for
>    decades until they go out of existence.
>
>
> *Should the majority be against #1, #3, regardless, I still recommend that
> the following statement:*“IPv6 Allocation: The minimum IPv6 allocation
> under SPARK shall be a /40, issued using sparse allocation so it may be
> expanded to a /36 or /32 without renumbering.”
>
>
> No need for this as a policy change, it’s already current ARIN policy for
> all practical purposes.
>
>
> *Be revised to:*
> “IPv6 Allocation: The minimum IPv6 allocation under SPARK shall be a /40,
> issued using sparse allocation so it may be expanded to a */32 up-to or
> /28* without renumbering.”
>
>
> Sparse allocation can’t guarantee this and I’m opposed to creating
> reservations that may never get used.
>
> Sparse allocation gives you the highest likelihood of expansion without
> remembering at any size. If you’re sparse allocating from a /12, you get
> 4096 /32 allocations that can still expand to a /20. However, the 4097th
> issuance will limit someone’s expansion to /24. That’s ok.
>
>
> I.e. reserve a /28 per member-ORG, then assign them a /32 minimum (my
> suggestion), or assign them a /40 (if that's what the majority decides).
>
>
> Reservations like this are not a good way to run a registry. Sparse
> allocation (aka allocation by dissection) is good. Reservations limit
> future allocations potentially without advantage while sparse allocation
> maximizes the chance of hassle free expansion without preventing others
> from using space if needed.
>
>
> A few weeks ago I just dealt with an IPv6 ARIN request for expansion for
> an ISP customer of mine in the US, they had a /32 prefix from ARIN
> originally (allocated years ago), I got that expanded to /28. Besides
> what's already covered in my guide post on IPv6 subnetting, one of the
> reasons I did /28 was for enabling RFC9663 this ISP's campus/enterprise
> type use-case sites with large-scale managed Wi-Fi solutions. This is to
> show the point that /28 reserve is most ideal for ISPs, in my opinion (/29
> is doable too, but /28 is more future-proofing).
>
>
> As you’ve pointed out, no reservation is necessary with sparse allocation.
>
> Thus, I think we accomplish what you want with sparse allocation (indeed,
> potentially even to /24, if needed, and yes, I’ve gotten IPv6 /24s for
> multiple organizations that could justify them.
>
>
>
> Saw some comments already about “many small networks end up turning to
> consultants who, in practice, often steer them into leasing IPv4 space”.
> This is operational reality, whether we like it or not. A lot of such
> “consultants”, abide by their trusty up-to-date IPv4-only CCNA up-to
> whatever-IE training certification from the 90s, even in 2025.
>
>
> Sad but true, I guess. They should hire me instead. ;-)
>
>
> @Owen DeLong
>
>> Why would anyone hire a consultant who is taking kickbacks for operating
>> against their client’s interest?
>>
>> Seems very unethical to me and not too bright on the part of the clients.
>>
> Many consultants are unethical (and may in fact be doing potentially
> illegal things by some nations' laws), but clients are happy with them and
> keep paying anyway — this is the bread and butter of the break/fix IT
> philosophy to begin with.
>
> This isn't about “IPv4 leasing referral fees at $99 or whatever”, more
> about break/fix, as old as time itself. There's not a lot of (daily)
> possible break/fix money making schemes for unethical consultants with
> well-done IPv6 architecture.
>
> A few months ago I helped a non-profit, non-commercial entity in one of
> the African nations, with their Starlink network deployment. It turns out
> their “certified [insert XYZ vendor name here] MSP expert” locally, had
> previously disabled IPv6, did triple NAT and billed them and called it a
> day, then naturally problems came about with triple NAT, and they pulled
> the break/fix approach to keep making money off the client. Finally, I came
> in, did what needed to be done, hasn't required support for months now.
> This isn't uncommon even in western nations.
>
> I think this has very little impact on the problem you claim to be trying
>> to solve. I think pushing for better educational outreach and finding ways
>> to inform these businesses that they should be looking for independent
>> consultants that aren’t taking money from secondary vendors would be far
>> more useful.
>>
> That's idealistic, but not really going to work in the real world, because
> such businesses aren't looking for “education”, ego/pride, whatever you may
> call it, prevents them from consuming such educational materials, they'll
> stick with their trusty IPv4-only consultants.
>
> People like to be “enforced” via policies in the networking world (global
> IPv6 adoption rates speaks for itself) to make a change. People like change
> as long as there's no change (policies/regulatory level).
>
>
> That hasn’t been my experience, but YMMV. My experience has been that
> people are generally resistant to policies unless there’s very good reason
> for them.
>
> Owen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20251015/fa42d91a/attachment-0001.htm>