Hello Brendan, I appreciate your thoughtful opposition to prop-168, but I believe you're approaching this from the wrong strategic framework entirely.
*The Counter-Intuitive Case: Accelerate IPv4 Exhaustion* You argue that prop-127 was designed to "preserve a meaningful on-ramp for future networks for as long as possible." I fundamentally disagree with this preservation mindset. The goal shouldn't be managing IPv4's decline over decades—it should be actively managing it *out of service*. Here's why rapid exhaustion is actually better for future networks: 1. *IPv4 availability delays IPv6 adoption*: My recent network analysis (achieving 99.6% native IPv6 on a production SOHO network) demonstrates that IPv6 is functionally complete *now*. The remaining ~0.4% IPv4 is legacy IoT hardware and a handful of IPv4-only services—artifacts, not requirements. The continued availability of IPv4 creates a comfort blanket that removes urgency for IPv6 deployment. 2. *Hoarding creates economic inefficiency*: Unused addresses sitting idle in the pool while small networks pay market rates for transfers is economically perverse. We're artificially creating scarcity for existing operators while "preserving" addresses for hypothetical future members. This forces real networks with real needs into exploitative leasing markets *today* to protect theoretical networks *tomorrow*. 3. *The 9-year runway is actually too long*: Stretching IPv4 availability until 2034-2035 guarantees another decade of dual-stack complexity, CGNAT /NAT444 deployments, and delayed IPv6 investment. Every year we extend this timeline is another year the industry avoids the inevitable transition. 4. *"Grab it because you can" is prevented by needs assessment*: You suggest this creates perverse incentives, but APNIC's needs-based justification process remains in place. Organizations still must demonstrate legitimate requirements. The Hostmasters aren't rubber-stamping applications—they're evaluating genuine operational needs. *The Real Barrier to Entry* You state: "Once that runway is consumed it is gone permanently, and the next wave of networks will have fewer options and a higher barrier to entry." This is precisely backwards. The *highest* barrier to entry is forcing new networks into expensive transfer markets when usable space exists in the pool. Future networks will deploy IPv6-first with NAT64/464XLAT for legacy compatibility—this is the proven path forward (T-Mobile US, Reliance Jio, and my own 99.6% IPv6 network demonstrate this works). By 2035, when the pool exhausts under current policy, these translation technologies will be mature and ubiquitous. Future networks won't need IPv4 allocations at all—they'll need IPv6 allocations and access to shared NAT64 infrastructure. We should be building that infrastructure *now*, not hoarding a depleting resource for nine more years. *Managing Out vs. Managing Down* The fundamental disagreement is this: you want to manage IPv4 *down* slowly. I argue we should manage it *out* deliberately. Every additional IPv4 allocation made today under needs-based justification is better than that same address sitting unused until 2030 while forcing networks to market transfers. Prop-168 doesn't undermine prop-127's intent—it recognizes that the context has changed. We're not in 2019 anymore. IPv6 is production-ready. The transition technologies work. The only thing holding us back is the illusion that carefully rationing IPv4 protects future networks, when in reality it's just delaying the inevitable transition while creating economic inefficiency today. *A Question Back to You* If you believe preserving the pool is important, how do you justify forcing existing networks with demonstrated needs into transfer markets while addresses sit idle? Isn't that creating the exact "grab it because you can" dynamic in the transfer market that you're trying to prevent in the allocation process? Regards, <https://about.me/terry.sweetser?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb> Terry Sweetser about.me/terry.sweetser <https://about.me/terry.sweetser?promo=email_sig&utm_source=product&utm_medium=email_sig&utm_campaign=gmail_api&utm_content=thumb> On Fri, 19 Dec 2025 at 06:49, Brendan Halley <[email protected]> wrote: > Hello, > > I wholeheartedly disagree with this proposal. I believe it lacks proper > foresight for the decades to come. > > prop-127 was a deliberate step to reduce the maximum from /22 to /23 to > slow consumption of the remaining 103/8 pool and preserve a meaningful > on-ramp for future networks for as long as possible. Reversing that now > undermines the intent of prop-127 and shifts value away from new entrants > and toward existing members simply because they got here first. > > I also think this change creates an obvious "grab it because you can" > incentive. Even if many organisations do not truly need a /22, plenty will > take the upgrade while it is available, and that accelerates depletion of > the remaining pool. Once that runway is consumed it is gone permanently, > and the next wave of networks will have fewer options and a higher barrier > to entry. > > If there is a real problem to solve here, I would rather see something > narrowly targeted at demonstrable need or specific edge cases, not a broad > increase to the cap that shortens the runway for everyone who comes after > us. > > Regards, > Brendan > _______________________________________________ > SIG-policy - https://mailman.apnic.net/[email protected]/ > To unsubscribe send an email to [email protected]
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
