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 ([email protected]).
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 [email protected] if you experience any issues.

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
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.

Reply via email to