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 <[email protected]> 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 > >
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
