[arin-ppml] Policy Proposal 103: Change IPv6 Allocation Process - revised

[Matthew Petach]

>
> 6.5.9.3 ARIN shall register no more than one address block of each
> prefix-length for any single organization. These blocks may be
> registered simultaneously. Renumbering of existing blocks is not
> required to receive additional blocks.

So...I'm a company with a /40 allocation.  I buy up 3 companies
with /48 allocations.  According to this, ARIN is supposed to drop
the registrations for 2 of the 3 companies, since I can only have
one /40 allocation and one /48 allocation, right?  What is the
timeframe allocated for renumbering the acquired companies,
and what should ARIN do to the registrations for the blocks in
the meantime?  If my /40 was already full, and doesn't have room
for the 2 new /48s I have to renumber, do I get a /32 allocation
as well, so I can renumber the 2 /48s into the new /32 (thus
coming back into alignment with the requirement to have only
one allocation from each pool size).  If that ends my buying
spree, doesn't it seem a bit wasteful to force a company to
get a /32 allocation to accomodate 2 /48s?

Or does the proposal allow me to simply announce the 3 /48s
in additional to the /40 (following more closely the current IPv4
model for handling acquisitions), even if they're from the same
origin ASN?

> 6.5.9.5 For each allocation size, ARIN shall further manage the
> allocation pools such that the pool identity serves to classify
> whether or not the registrant is Multihomed.
>
> 6.5.9.6 ARIN shall offer addresses from pools classified as multihomed
> only to organizations which ARIN has verified are multihomed on the
> public Internet per NRPM 2.7.
>
> 6.5.9.7 Where an organization ceases to be Multihomed it shall
> surrender all address allocations from within pools classified as
> multihomed within 3 months.

I assume this should be re-written to state that the addresses shall
only be required to be surrendered if the organization *remains*
single-homed for the full three month period.

Otherwise, the moment my second upstream provider suffers a
serious fiber cut and my link is down for any real duration (24 hour
fiber cut, on the order of what happened in Silicon Valley last year),
I cease to be "Multihomed", and I get a "you have 3 months to renumber"
letter from ARIN telling me to move off my multihomed space onto the
single-homed pool.  24 hours after that, I get the "oops, sorry, you don't
have to renumber after all" letter from them, when my second upstream
link is restored.

Also note that NRPM 2.7 was designed primarily for ascertaining the
intent to multihome, and does not detail any provisions for ongoing
testing and validation of multihoming (which is a horrible can of worms
to open up!  After all, what if one of my 2 upstreams is Cogent, and ARIN
is getting its connectivity from he.net, and only sees one upstream for me,
through HE.net; is it my fault ARIN can't see my other upstream because
HE.net and Cogent are fighting that year?)

>
> Q. Why allow only one allocation of each particular size?
>
> A. Without the address scarcity issue which drives IPv4 policy, the
> primary criteria for IPv6 addressing policy is suppressing the
> disaggregation that drives route count in the IPv4 DFZ (NRPM 6.3.8).
> Such a criteria is not well served if an organization holds dozens of
> discontiguous address spaces as a result of acquisitions, mergers and
> and growing a little bit at a time. This proposal says, in effect,
> once you've consumed your smaller allocation it's time for you to get
> a *much* bigger allocation. The rest of us don't want to pay the
> routing table price for you coming back again and again and again.
>
> The proposal could require some renumbering as a result of mergers and
> acquisitions. However, with only modest planning on the registrant's
> part, the policy its flexible enough to allow that renumbering to
> occur over a long period of time so that both cost and disruption are
> minimized. In many cases, customer churn can be expected to take care
> of much of the renumbering activity all by itself.

I don't see any mention of timeframes in this document; you say that to
minimize cost and disruption, renumbering from multiple smaller pools
obtained due to acquisitions can occur "over a long period of time."   Would
a five year renumbering cycle be considered reasonable?   What about a
ten year renumbering cycle?  Twenty years?  At what point does the claim
"I'm renumbering...just very slowly" become specious and indistinguishable
from "I'm just going to announce multiple small blocks...deal with it."

> Q. What happens when organizations merge or split?
>
> A. Entities which merge may renumber out of and return  conflicting
> allocations, or they may maintain the existence of the acquired
> organization in order to keep it's addresses. Either way it should be
> a minor hardship.

What about keeping the address blocks within the combined entity?
Is that verboten in this plan?  Would this then simply lead to a
proliferation of ORG-IDs, with every block allocated potentially
keeping its own ORG-ID, just so that during mergers and acquisitions
no renumbering would be required?  Is there any penalty for an
organization holding dozens of ORG-IDs under one umbrella?

> Entities which split have a bigger problem since the practical effect
> of route filtering may be that only one of them can keep the
> addresses. To a large extent, that problem already exists and is a
> pain in the rump for IPv4 operations today. This policy doesn't solve
> it but it doesn't make it a whole lot worse either. Because
> disaggregates are likely to be filtered, this IPv6 policy does gives
> us a slightly better guarantee that the rest of us won't get stuck
> with the check (in the form of routing slot consumption) when an ISP
> goes bankrupt and gets split up.

It seems to indicate that if I currently have a /40 allocation, and I
split up, as long as the split off portion needs more than a /48, it
can acquire its own /40, right?

> Q. What about reporting requirements for downstream assignments?
>
> A. Reporting requirements were instituted for the purpose of verifying
> eligibility for additional allocations. They have proven useful for
> other purposes and the author encourages ARIN to maintain the SWIP
> system. Nevertheless, this proposal renders the use of SWIP for IPv6
> optional since it is no longer needed to verify eligibility for
> allocations.

Ugh.  I think that being able to identify sources of malware and spam
is eminently useful, as is being able to notify registrants of compromised
systems, etc.  Not requiring any tracking of downstream number resources
makes it very, very hard to identify who the right points of contact are for
addressing issues with traffic originating from those number resources.
I think reporting requirements for downstream assignments should
still be maintained.

> Implementation notes:
>
> To prevent wasteful consumption of IPv6 address space without a
> complicated eligibility regime, the author recommends an initial and
> annual fee regime for IPv6 address allocations similar to:
>
> /56 -- $10 USD
> /48 -- $100 USD
> /40 -- $1000 USD
> /32 -- $10,000 USD
> /24 -- $100,000 USD

Without some controls in place to justify consumption, at those prices
it would take less than half a billion dollars to consume all of ARIN's
current IPv6 number resources.

It might be worth considering *some* level of control to prevent
large entities from simply choosing to buy up all available address
resources.

> For verification of multihoming, the current way ARIN verifies
> multihoming for other parts of it's policy appears satisfactory.
> Should that change, the author suggests requiring that the AS#
> contacts for at least two AS#'s submit a template indicating that they
> intend to originate or propagate IPv6 BGP routes from the registrant's
> ORG.

That's fine for the initial allocation of space in the multihoming pool;
but you talk about reclaiming space 3 months after a site ceases
to be multihomed; how is that going to be handled?  Or will the
upstream ISPs need to send re-affirming letters each month to
establish their ongoing intent to provide transit services?

I see so many issues with this proposal, I don't think I can support
it as it currently stands.  Can more work be done to address the
concerns around mergers, acquisitions, divestitures, and how
multihoming determinations are to be handled?

Thanks!

Matt