<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Some counter points in line…</div><div dir="ltr"><br></div><div dir="ltr"><br></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><ol><li>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.</li></ol></div></div></div></blockquote><div><br></div>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. <br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><ol start="2"><li>I've long pushed for #1 (outside formal channels like RIR props) and advocate for it explicitly in my IPv6 guide post <a href="https://blog.apnic.net/2023/04/04/ipv6-architecture-and-subnetting-guide-for-network-engineers-and-operators/"><span id="mt-tracked-link_3_1759870668242" style="color:red"></span>here</a>, which was at some point added to <a href="https://www.apnic.net/community/ipv6/deploy-ipv6/#resources"><span id="mt-tracked-link_3_1759870684574" style="color:red"></span>APNIC's BCP materials for IPv6</a>.</li></ol></div></div></div></blockquote><div><br></div>Ok<div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><ol start="3"><li>SPARK could instead do something similar to what <a href="https://www.apnic.net/community/policy/resources#a_h_8_0"><span id="mt-tracked-link_3_1759870953174" style="color:red"></span>APNIC</a> and <a href="https://www.ripe.net/publications/docs/ripe-738/#43-minimum-allocation"><span id="mt-tracked-link_3_1759870962538" style="color:red"></span>RIPE</a> 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.</li></ol></div></div></div></blockquote><div><br></div>ARIN already does this, so I’m not sure what you think SPARK would change in that regard. <br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><ol start="4"><li>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).</li></ol></div></div></div></blockquote><div><br></div>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. </div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><ol start="5"><li>/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.</li></ol></div></div></div></blockquote><div><br></div>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. <br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><ol start="6"><li>For ISPs that have presence in <b>more than one state </b>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).</li></ol></div></div></div></blockquote>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. </div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><ol start="7"><li>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.</li></ol><b>Should the majority be against #1, #3, regardless, I still recommend that the following statement:<br></b>“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.”</div></div></div></blockquote><div><br></div>No need for this as a policy change, it’s already current ARIN policy for all practical purposes. </div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div><div><br></div><div><b>Be revised to:</b></div><div>“IPv6 Allocation: The minimum IPv6 allocation under SPARK shall be a /40, issued using sparse allocation so it may be expanded to a <b>/32 up-to or /28</b> without renumbering.”</div></div></div></blockquote><div><br></div>Sparse allocation can’t guarantee this and I’m opposed to creating reservations that may never get used. </div><div><br></div><div>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. </div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><br></div><div>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).</div></div></div></blockquote><div><br></div>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. </div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><br></div><div>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).</div></div></div></blockquote><div><br></div>As you’ve pointed out, no reservation is necessary with sparse allocation. </div><div><br></div><div>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. </div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><br></div><div>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.</div></div></div></blockquote><div><br></div>Sad but true, I guess. They should hire me instead. ;-)</div><div><br><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div><br></div><div><a class="gmail_plusreply" id="plusReplyChip-0">@Owen DeLong</a><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Why would anyone hire a consultant who is taking kickbacks for operating against their client’s interest?<br><br>Seems very unethical to me and not too bright on the part of the clients.<br></blockquote><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div>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.</div><div><br></div><div>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).</div></div></div></blockquote><div><br></div>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. </div><div><br></div><div>Owen</div><div><br></div></body></html>