[arin-ppml] IPv6 policy: n-year planning horizon?

[John W. O'Brien]

Network engineering is hard to do well. Predicting the future is much 
harder to do.

IPv4 addresses are a scarce, valuable resource, which makes them 
susceptible to fraud, abuse, and negligence in a way that is significant 
for honest, competent participants. Requiring documented forecasts under 
contract terms acts as a check on these things because it helps with 
detection and avoidance as well as when it becomes necessary to 
litigate. However, this also imposes costs on ARIN and on every 
participating operator.

IPv6 addresses are not scarce, and not expected to become scarce within 
a very, very long horizon. While IPv6 address space is not immune to bad 
actors, it is intrinsically much more resilient than IPv4, which is kind 
of the whole point. We should take advantage of this strength to lower 
the bar.

I favor eliminating n-year planning horizons for IPv6 in all but outlier 
cases.

What constitutes an outlier? It might have to do with the total number 
of allocations (e.g. > 2) or maybe the rate (e.g. < 6 mo since last 
allocation).


On 2026-06-25 16:59, William Herrin wrote:
> Howdy,
> 
> I didn't see any feedback on the draft policy rewriting section 6.5,
> so I want to step back and solicit your opinions on what ARIN's IPv6
> policies should become. I'm going to ask some questions and break them
> into separate message threads so that they can be followed separately
> according to your interest.
> 
> 
> The question for this thread is: Should the policy take n-year
> projections into account or should it be something like current
> demonstrated need and ARIN automatically adds a large pad?
> 
> 
> Three and five year IP address use projections, and requirements to
> use addresses within a period of time are a tradition held over from
> IPv4 policy. With IPv4 ARIN tries to balance consumption of two scarce
> resources: IPv4 address blocks and Internet BGP routing table slots.
> Every IP address one registrant is granted is an IP address another
> registrant can't have. But, every discontiguous address block
> allocated to the same organization is another slot in the BGP table
> they will consume, whether or not their network engineering requires
> it.
> 
> So, ARIN tries to allocate enough addresses at a time to meet the
> organization's reasonably foreseeable need. They were going to come
> back for more anyway, and this way they don't needlessly consume BGP
> slots.
> 
> These sort of multi-year planning horizons used to justify ARIN
> address grants are present in the IPv6 policies as well, both in the
> current section 6.5 and in draft 2026-2.
> 
> Are they needed? Are they wanted?
> 
> If we don't go too crazy, we have enough IPv6 addresses for everybody,
> far into the foreseeable future. If anything, the annual ARIN fee is
> enough to suppress careless consumption. We still have limited space
> in the BGP table. In principle, ARIN doesn't ever want registrants
> coming back for more IPv6 addresses. To the maximum extent practical,
> they want that first allocation to be the only one so that network
> engineering alone drives how much of the BGP table the registrant
> consumes.
> 
> What are your thoughts? Continue to use n-year planning horizons?
> Replace that with language around avoidance of a second allocation? A
> third option? Your views are respectfully requested.
> 
> Regards,
> Bill Herrin
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://urldefense.com/v3/__https://lists.arin.net/mailman/listinfo/arin-ppml__;!!IBzWLUs!VoSs47J9K7B3Y1k6ZkU4Hq7NCRgiI45VIrFuE8_HXYncmY6n_NgL-vPF1bo0y2UO6AtZk_nIvnjZItY$
> Please contact info at arin.net if you experience any issues.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 236 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260625/21c8e862/attachment.sig>