<div dir="ltr"><div>Daryall,</div><div dir="ltr"><br></div><div dir="ltr">No one said it was difficult to get IPv6; the difficulty is that, currently, to get an initial IPv6 and IPv4 allocation, along with an ASN, you have to make multiple requests, and the order of these requests can matter.<div><br></div><div>I'm glad to hear the author and staff are working together to improve this situation, allowing an initial allocation of IPv6, IPv4, and an ASN through the ACSP. Allowing a streamlined process for an initial allocation of all three types of resources is a great idea. But a policy change probably isn't necessary to accomplish it.</div><div><br></div><div>Thanks. </div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Oct 24, 2025 at 1:17 AM Daryll Swer via ARIN-PPML <<a href="mailto:arin-ppml@arin.net">arin-ppml@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Preston<br><br>I just got another /28 for another American client of mine, yet again. I think, like the others said, getting IPv6 from ARIN isn't difficult. Probably best to withdraw this.</div><div><div dir="ltr" class="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://l.mailtrack.com/l/aed0e57263aa9273972deb5be0be0e8c4b1f7c14?u=2153471" target="_blank">daryllswer.com</a></font></div></div></div></div><br></div><br><img width="0" height="0" alt="" style="display: flex;" src="https://mailtrack.io/trace/mail/94a3420a7722ffc49acb031db384b1855b012063.png?u=2153471"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 24 Oct 2025 at 11:03, Preston Ursini via ARIN-PPML <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Thanks Mohibul:</div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Chiming in as the policy author, after discussing this with ARIN staff and the shepherds, it would appear that this would be possible to implement without a change in policy and would have to go through ARIN's ACSP.</div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">It will be likely that I’ll be withdrawing the proposal and resubmitting it to the ACSP in due course.</div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">I believe ARIN Staff will be updating the website with the latest modification of the policy document that trims its scope to fit within the NRPM, it still likely needs to go through the ACSP, not the PDP.</div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">If however, through the ACSP process they later find that they will need a policy to accomplish this, it can be reintroduced.</div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">If anyone has anything to add, I’m all ears, but I'm leaning towards withdrawal as to not overburden the AC with unnecessary or redundant work.</div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br></div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">Preston Louis Ursini</div><div dir="auto" style="color:rgb(0,0,0);letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"> </div></div></div>
</div>
<div><br><blockquote type="cite"><div>On Oct 24, 2025, at 12:21 AM, Mohibul Mahmud <<a href="mailto:mohibul.mahmud@gmail.com" target="_blank">mohibul.mahmud@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><h3></h3>
<h3><span style="font-size:small;font-weight:normal">Dear Preston, Owen, and ARIN Community,</span></h3><p>I appreciate the ongoing discussion about <strong>ARIN-prop-348 (SPARK)</strong>. This proposal is important for helping new networks grow and adopt IPv6. As a candidate for the Advisory Council, I think we need to make sure the final policy clearly addresses the key technical questions discussed.</p><ol>
<li><p><strong>Deciding the Right IPv6 Allocation Size</strong><br>
There’s been talk about what the minimum size for the initial IPv6 allocation should be (for example, /40 vs. /32). We need to make this clear in the policy.</p><p><strong>Suggestion:</strong> The policy should specify the exact size of the initial IPv6 allocation for SPARK. This should be based on how networks grow over time, to avoid having to renumber networks later on.</p>
</li>
<li><p><strong>Making Sure Networks Can Grow Without Waste</strong><br>
We need to make sure new operators can expand their networks easily, while also not wasting too many IP addresses.</p><p><strong>Suggestion:</strong> The policy should include a process for <strong>sparse allocation</strong> (which means using address space efficiently as the network grows). This will allow new operators to grow their network without reserving too many addresses upfront.</p>
</li>
<li><p><strong>Making the Policy Simple to Avoid Consultant Manipulation</strong><br>
The goal of SPARK is to give new operators an easy and direct path to ARIN.</p><p><strong>Suggestion:</strong> The policy should be as simple as possible and require minimal paperwork. This will make it the easiest and cheapest option, reducing the chance that consultants will push operators toward expensive IPv4 leasing.</p>
</li>
<li><p><strong>Clear Fee Structure</strong><br>
Although ARIN sets the fees, we need to make sure the fees are easy to understand.</p><p><strong>Suggestion:</strong> The policy should allow ARIN to publish a clear, simple fee structure for the SPARK package. This will make it easier for new operators to understand the costs involved and make better decisions.</p>
</li>
</ol><p>I look forward to working with the Advisory Council to help finalize this policy and make sure SPARK works well for everyone.</p><div>
<br></div><p>Best regards,<br>
Mohibul Mahmud</p><p><br></p><p><br></p><p><br></p></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 23, 2025 at 9:27 PM Owen DeLong via ARIN-PPML <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br id="m_-5139966349116135264m_-7757623518503170794m_-4382588471019670993lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Sep 22, 2025, at 21:09, Preston Ursini <<a href="mailto:preston@thefirehorn.com" target="_blank">preston@thefirehorn.com</a>> wrote:</div><br><div><div dir="auto">It comes down to the fact that there is a large incentive for consultants to push IPv4 reliance as the associated brokerage and leasing agreements that pay out commissions. Many of these arrangements even have ongoing payouts for the salespersons.</div></div></blockquote><div><br></div>Why would anyone hire a consultant who is taking kickbacks for operating against their client’s interest?</div><div><br></div><div>Seems very unethical to me and not too bright on the part of the clients.</div><div><br></div><div>The only money I’ve ever taken from brokers or lease providers has been as a consultant for their purposes unrelated to their clients. Never have I taken money from such an organization as a commission for delivering business to them.</div><div><br><blockquote type="cite"><div><div dir="auto"><div><div>Many of these consultants don’t even have strong backgrounds and networking and engineering, but in sales and marketing. Combine that with a lack of knowledge on the subject matter for small entrants, and we have what we have now.</div></div></div></div></blockquote><div><br></div>Sounds more like an educational problem than a policy problem.</div><div><br><blockquote type="cite"><div><div dir="auto"><div><div>This is one tiny inch in the direction that will push the community towards the right path on this. I firmly believe educational and information campaigns combined with this policy will steer the market in the right direction.</div></div></div></div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div><div dir="auto"><div><div>I firmly believe that there are a lot of good consultants out there that do exactly as you were saying, and that this is standard practice among a lot of them.</div></div></div></div></blockquote><div><br></div>There are.</div><div><br><blockquote type="cite"><div><div dir="auto"><div><div>Codifying it and making it easier to self service for these small and new networks will do a lot to get these networks starting on the right path in regards to IPv6 deployment. I think it will be very important to follow up with ARIN staff on how this would be implemented on the front end as well.</div></div></div></div></blockquote><div><br></div>I’m not convinced of this. I think you’re trying to solve an educational problem with a policy hammer, because the policy hammer is easy to reach and education is hard.</div><div><br></div><div>Owen</div><div><br><blockquote type="cite"><div><div dir="auto"><div><div><div><br></div><div>Preston Louis Ursini<br><div><div dir="ltr"><p style="font-size:17px"> <br></p><div></div><div><div></div></div></div><div dir="ltr"><br><blockquote type="cite">On Sep 22, 2025, at 10:40 PM, Owen DeLong <<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><span>I’m dismayed that consultants would do that, but I guess there are no shortage of bad consultants out there.</span><br><span></span><br><span>I’ve been doing effectively SPARK for clients for a long time now (since well before IPv4 runout) and never sent a single client into the leasing realm (despite doing consulting for an IPv4 leasing organization).</span><br><span></span><br><span>I’ll wait for the proposal to be published as a draft policy before commenting further.</span><br><span></span><br><span>Owen</span><br><span></span><br><span></span><br><blockquote type="cite"><span>On Sep 22, 2025, at 20:16, Preston Ursini via ARIN-PPML <<a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a>> wrote:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Greetings all:</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I am seeking community discussion on ARIN-prop-348, the SPARK proposal. SPARK is intended to create a clear and straightforward entry point for new organizations needing core Internet number resources. At present, a new operator must make separate requests for an ASN, IPv4 under section 4.10, and an IPv6 allocation. Each request has its own requirements, paperwork, and fees. This complexity has real-world consequences: many small networks end up turning to consultants who, in practice, often steer them into leasing IPv4 space instead of working directly with ARIN. That approach not only increases costs for these new operators but also delays IPv6 deployment.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>SPARK grew out of conversations with and feedback from small network operators in the community. They want to do things “the right way” but face too many barriers when first approaching ARIN. By creating a single, bundled policy path, SPARK would make it far easier for them to start off on solid footing, with an ASN, a /24 of IPv4 from the transition pool, and an IPv6 allocation that is sized for growth.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>The benefit of defining SPARK explicitly in the NRPM is that it would give ARIN staff a clear framework for implementation and provide new operators with transparency and predictability. It would remove ambiguity, lower entry costs, and encourage IPv6 adoption from day one. Without a policy like this, the market incentives push new operators toward leasing arrangements that solve their immediate IPv4 needs but do nothing to build long-term IPv6 readiness.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I may have confused the historic ASN issuance fee with the current transfer fee when thinking through the costs, which highlights that ARIN’s fee schedule could be presented more clearly on the website. That is probably best addressed through the Consultation and Suggestion Process. The policy question here, however, is whether we should formally establish SPARK as a new allocation category in the NRPM, how it should be structured, and what costs should be attached.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>I would greatly appreciate community input on three fronts: where in the NRPM this category should live, what fee model would be appropriate and fair, and whether the proposed language around eligibility and resource sizes needs adjustment.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>Thank you in advance for your thoughts and feedback.</span><br></blockquote><blockquote type="cite"><span></span><br></blockquote><blockquote type="cite"><span>All the best,</span><br></blockquote><blockquote type="cite"><span>Preston Louis Ursini</span><br></blockquote><blockquote type="cite"><span>_______________________________________________</span><br></blockquote><blockquote type="cite"><span>ARIN-PPML</span><br></blockquote><blockquote type="cite"><span>You are receiving this message because you are subscribed to</span><br></blockquote><blockquote type="cite"><span>the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).</span><br></blockquote><blockquote type="cite"><span>Unsubscribe or manage your mailing list subscription at:</span><br></blockquote><blockquote type="cite"><span><a href="https://l.mailtrack.com/l/c9a57f781953c33316293aad3bf3a4934795a3cf?u=2153471" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a></span><br></blockquote><blockquote type="cite"><span>Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.</span><br></blockquote><span></span><br></div></blockquote></div></div></div></div></div></div></blockquote></div><br></div>_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://l.mailtrack.com/l/db9c6e94c826d2cd66bc6d6bd14c16bf1d85dce4?u=2153471" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div></div>
</div></blockquote></div><br></div>_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://l.mailtrack.com/l/4b8018b43b547eedcefdf85a208d69276880fbbb?u=2153471" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div></div>
_______________________________________________<br>
ARIN-PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="https://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">https://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">===============================================<br>David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>Networking & Telecommunication Services<br>Office of Information Technology<br>University of Minnesota <br>2218 University Ave SE Phone: 612-626-0815<br>Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>=============================================== </div></div>