<div dir="ltr"><img width="0" height="0" class="mailtrack-img" alt="" style="display:flex" src="https://mailtrack.io/trace/mail/a2bbe01f987ed16213a912fe2ec9644c7e5ffe40.png?u=2153471"><div>Hello</div><div><br></div><div>Came on to this mailing list real quick, after seeing Ursini's SPARK proposal <a href="https://www.arin.net/participate/policy/proposals/2025/ARIN_prop_348/"><span id="mt-tracked-link_3_1759870066534" style="color:red"></span>doc</a>, 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).</div><div><br></div><div>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.</div><div><br></div><div>Have a few points to note:</div><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><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><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><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><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><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><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.”<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><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><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><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><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 dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><font color="#000000" face="arial, sans-serif"><br><b>--</b><br></font><div><font color="#000000" face="arial, sans-serif">Best Regards</font></div><div><font color="#000000" face="arial, sans-serif">Daryll Swer</font></div><div><font color="#000000" face="arial, sans-serif">Website: <a href="https://www.daryllswer.com" target="_blank"><span id="mt-tracked-link_0_1759873356404" style="color:red"></span>daryllswer.com</a></font></div></div></div></div></div>