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

[Daryll Swer]

Hello

Came on to this mailing list real quick, after seeing Ursini's SPARK
proposal doc
<https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_348/>,
and was invited by him to chime in. While I don't have an American presence
(I'm in the APNIC region), I do work quite a bit with American ISPs, with
plenty of IPv6 projects (from WISPs to regular ISPs on fibre).

My understanding is this prop is intended largely (though not exclusively)
for SP networks and use case, and that's typically the type of ORGs I work
with 99.99% of the time for consulting.

Have a few points to note:

   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.
   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>.
   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.
   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).
   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.
   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).
   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.”
>
>
*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.”

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).

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).

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.

@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).

*--*
Best Regards
Daryll Swer
Website: daryllswer.com <https://www.daryllswer.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20251008/3a3a37c0/attachment.htm>