Preston 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.
*--* Best Regards Daryll Swer Website: daryllswer.com <https://l.mailtrack.com/l/aed0e57263aa9273972deb5be0be0e8c4b1f7c14?u=2153471> On Fri, 24 Oct 2025 at 11:03, Preston Ursini via ARIN-PPML < [email protected]> wrote: > Thanks Mohibul: > 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. > > It will be likely that I’ll be withdrawing the proposal and resubmitting > it to the ACSP in due course. > > 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. > > If however, through the ACSP process they later find that they will need a > policy to accomplish this, it can be reintroduced. > > 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. > > > > Preston Louis Ursini > > > On Oct 24, 2025, at 12:21 AM, Mohibul Mahmud <[email protected]> > wrote: > > Dear Preston, Owen, and ARIN Community, > > I appreciate the ongoing discussion about *ARIN-prop-348 (SPARK)*. 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. > > 1. > > *Deciding the Right IPv6 Allocation Size* > 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. > > *Suggestion:* 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. > 2. > > *Making Sure Networks Can Grow Without Waste* > We need to make sure new operators can expand their networks easily, > while also not wasting too many IP addresses. > > *Suggestion:* The policy should include a process for *sparse > allocation* (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. > 3. > > *Making the Policy Simple to Avoid Consultant Manipulation* > The goal of SPARK is to give new operators an easy and direct path to > ARIN. > > *Suggestion:* 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. > 4. > > *Clear Fee Structure* > Although ARIN sets the fees, we need to make sure the fees are easy to > understand. > > *Suggestion:* 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. > > I look forward to working with the Advisory Council to help finalize this > policy and make sure SPARK works well for everyone. > > Best regards, > Mohibul Mahmud > > > > > On Tue, Sep 23, 2025 at 9:27 PM Owen DeLong via ARIN-PPML < > [email protected]> wrote: > >> >> >> On Sep 22, 2025, at 21:09, Preston Ursini <[email protected]> >> wrote: >> >> 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. >> >> >> 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. >> >> 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. >> >> 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. >> >> >> Sounds more like an educational problem than a policy problem. >> >> 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. >> >> >> 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. >> >> 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. >> >> >> There are. >> >> 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. >> >> >> 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. >> >> Owen >> >> >> Preston Louis Ursini >> >> >> >> On Sep 22, 2025, at 10:40 PM, Owen DeLong <[email protected]> wrote: >> >> I’m dismayed that consultants would do that, but I guess there are no >> shortage of bad consultants out there. >> >> 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). >> >> I’ll wait for the proposal to be published as a draft policy before >> commenting further. >> >> Owen >> >> >> On Sep 22, 2025, at 20:16, Preston Ursini via ARIN-PPML < >> [email protected]> wrote: >> >> >> Greetings all: >> >> >> 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. >> >> >> 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. >> >> >> 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. >> >> >> 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. >> >> >> 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. >> >> >> Thank you in advance for your thoughts and feedback. >> >> >> All the best, >> >> Preston Louis Ursini >> >> _______________________________________________ >> >> 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 >> <https://l.mailtrack.com/l/c9a57f781953c33316293aad3bf3a4934795a3cf?u=2153471> >> >> Please contact [email protected] if you experience any issues. >> >> >> >> _______________________________________________ >> 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 >> <https://l.mailtrack.com/l/db9c6e94c826d2cd66bc6d6bd14c16bf1d85dce4?u=2153471> >> Please contact [email protected] if you experience any issues. >> > > _______________________________________________ > 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 > <https://l.mailtrack.com/l/4b8018b43b547eedcefdf85a208d69276880fbbb?u=2153471> > Please contact [email protected] if you experience any issues. >
_______________________________________________ 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.
