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

[William Herrin]

On Sun, Nov 22, 2009 at 3:21 AM, Matthew Petach <mpetach at netflight.com> wrote:
> 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?

Hi Matthew,

We can do lots more work. What would you like to see done differently
for the mergers/acquisitions/divestitures process? How would you
recommend doing it instead?


> 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?

The idea here is that as you integrate these acquired customers into
your overall network infrastructure, you will renumber them. There is
no prohibition on continuing to operate the acquired ISP as a separate
legal entity with a separate network for however long as you find it
needful. On the other hand, the PITA aspects of maintaining a separate
entity are intended to encourage you to renumber quickly.


> 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?

Bear in mind that a /40 has more than two orders of magnitude more
addresses than a /48. If your /40 was 99% full when you started then
yes, you'll have to add a /32. If it was only 98% full then it has
space left to accommodate the three new /48's.

A /40 has the same relationship to a /48 that an IPv4 /16 has to a
/24. There are lots of /24's in the /16.



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

If you've resumed multihoming within the three months then you're
multihomed. Why would you need to surrender the addresses?

This is a policy document; everything in it gets passed through a
"common sense" filter during application. In other words, if I
intended that you loose the addresses even if you resumed multihoming,
I'd have to spell that out.

Since the phrasing bothers you, I'll welcome some wordsmithing to set it right.


> 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?)

ARIN currently verifies multihoming by asking you to submit two signed
ISP contracts. That's a little more than just intent.

It could be open to abuse but there's currently no record of it being
routinely abused. If that changes then naturally we'll want ARIN to
tighten it's procedures for multihoming verification. Why create extra
process if the problem it's intended to resolve doesn't exist yet and
might not come to exist at all?


>> 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?

If you stop multihoming and don't surrender the addresses, that's a
breach of the RSA. Just as if you lie in some other way. When someone
reports you, ARIN will audit.

ARIN allows multihomed end users to get a /22 of IPv4 addresses but
requires single-homed users to wait until they can justify a /20.
There hasn't been evidence of any significant abuse.


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

The idea is that you can independently operate the acquired network as
long as you like (even 20 years!) but renumber as you fold individual
customers into your main network.


> 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?

I addressed this in the added section 6.2.10:

6.2.10 Organization

An organization under section 6 is either:

one or more legal entities under common control or ownership, or

one such legal entity which operates strictly separate networks from
the others.



>> 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?

If you "split off" the portion into a separate network and legal
entity that you sell to someone else then it can acquire a /40 merely
because it wants it, regardless of need. What it can't acquire from
ARIN is the components of the original /40. You can delegate them and
if the Internet's routing policy makes it possible you can conceivably
announce them. But at the ARIN level, the original /40 allocation is
indivisible.


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

I think it's useful too, and I think ARIN should maintain the SWIP
system. Public records remains particularly useful to ISPs who want to
claim under DMCA safe harbor that the downstream is the service
provider so don't bother us.

Nevertheless, ARIN's need for that information is tied to evaluating
qualification for addresses. Without needing to evaluate
qualification, the justification for demanding the information goes
away.


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

Half a billion dollars is a lot of disincentive to spend money on
resources you don't actually need. When you consider that RIPE has
already handed out /19's for considerably less money than $100k per
year, I'm not worried about folks abusing this particular "flaw."

In the unlikely event that Bill Gates or Warren Buffet decides to
spoof the system, we can change the policy for ARIN's next /12.

Regards,
Bill Herrin


-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004