[arin-ppml] Simplified IPv6 policy

[William Herrin]

On Wed, Dec 23, 2009 at 12:24 PM, Scott Leibrand
<scottleibrand at gmail.com> wrote:
> On 12/23/2009 2:53 AM, William Herrin wrote:
>> Problems not resolved by your proposal:
>>
>> * Offers no IPv6 replacement for organizations with small but valuable
>> server infrastructures which today multihome with either a legacy
>> address block or a /24 ISP cutout.
>
> If you have (or acquire via 8.3) a legacy address block, then you can
> qualify for a PI /48.
>
> If you multihome with a PA /24 today, the equivalent in v6 would be to
> multihome with a PA /48.

Hi Scott,

There is no IPv6 equivalent to a multihomed IPv4 /24 PA cutout. Not in
this proposal with its classifications that enable strong disaggregate
filtering. Not in existing IPv6 policy that enables less effective
prefix filtering. Not in the IETF's recommendations.

> At the moment, such cutouts are not routable, but
> to me that's not something policy can fix.  If your upstreams won't take
> your money to accept your /48 cutout from each other, then how are we going
> to get them to agree to route a whole bunch of new PI /48s that they don't
> necessarily get paid for?

Convincing ISPs to accept /48 cutouts from each other is in direct
opposition to the classification for disaggregate management that your
proposal creates.

Further, suggesting that policy can't fix it is a cop-out. Policy did
fix it in IPv4: by authorizing /24 cutouts for multihomed entities
regardless of size based on the knowledge that /24's are generally
routable.

Successful ARIN IPv6 policy will have to create an IPv6 equivalent to
a multihomed IPv4 /24 PA cutout or else leave a well-funded class of
users with a solid technical basis for actively opposing IPv6
deployment.

Put another way: it is absurd to think that we will successfully
disenfranchise anyone in the IPv4 to IPv6 movement. We can change the
shape of the game but some rules are fundamental. The sooner we figure
this out, and address it in formal policy, the sooner we can move
forward.


> This is not a theoretical problem: AFAIK Verizon
> has not yet started accepting the PI /48s ARIN is already allocating.  If we
> give out PI /48s to anyone who wants to multihome, they (and others) will be
> even less likely to accept those.

Whether Verizon plays ball is another matter entirely. Your choices
there are threefold:

1. Bend ARIN policy to meet Verizon's will. You have a Verizon
representative on the AC so you'll have little problem learning their
requirements.

2. Ignore Verizon presuming that customer and government pressure will
eventually compel them to practices compatible with ARIN policy. A
letter from the GSA threatening to classify Verizon as
not-IPv6-compliant with respect to Federal purchasing rules would end
its resistance to /48's overnight.

3. Institute a policy like 103 in which Verizon and the other ISPs
intentionally have the power to make such filtering choices and
registrants can, with an application of cash, adjust their own
decisions to match. In other words, create a dynamic system and let it
find its natural balance point instead of trying to impose one from
on-high at the ARIN level.

It's ironic that bottom-up is an important goal in the PDP but not in the NRPM.



>>> 6.2.3.2  X-Small (/48)
>>> To qualify for a /48 allocation or assignment, an organization must:
>>>    * Serve at least 500 hosts, if multihomed; or
>>>    * Serve at least 1000 hosts; or
>>>
>>
>> IPv6 addressing is LAN-centric rather than host-centric. Accordingly I
>> suggest expressing this in terms of a number of LANs served. Perhaps
>> 50 or 100 LANs instead of 500 or 1000 hosts?
>>
>
> Why is number of LANs a better metric than number of hosts to determine who
> deserves a routing slot?  We're not really talking efficient utilization
> here, so I don't think number of LANs is relevant.  Besides, I can create
> 100 VLANs on a single inexpensive switch.  Creating 500 VMs (with running
> OSs) at least requires gear with more than a few dozen GB of RAM

You mean all I have to do for an IPv4 /22 is stand up 500 VMs? Damn,
I've been doing it the hard way. I just got my new 72 gig vmware
server too.


> These numbers were adapted from existing IPv4 PI policy.  Perhaps we should
> lower the numbers to better reflect the lower IPv4 requirements currently on
> the table.  Perhaps 250 or 500 hosts?

It's just a quibble but hosts is IPv4-think. Subnets is consistent
with IPv6. There will be a certain degree of arbitrariness to any
selected numbers, but basing the count on subnets will make it
slightly less so.


>> At work I operate a ground station for a satellite constellation. The
>> non-IP satellite devices deliver messages to the ground station which
>> disperses them via the Internet.
>>
>> This very high value application uses 5 T1s from 5 different ISPs, a
>> 100 meg ISP link and a 100 meg peering link. It uses only a few score
>> hosts and a handful of LANs.
>>
>> I use an ARIN AS# to announce an IPv4 /24 cutout from an ISP block via
>> BGP on all the ISP and peering links. Because it's multihomed, this is
>> in full compliance with ARIN policy. Because it's impractical to
>> filter announcements /24 and shorter, it works great.
>>
>> How do I get usable IPv6 addresses?
>>
>
> As I mentioned above, if you can't pay your upstreams enough money to accept
> PA /48s from each other, perhaps your application isn't high-value enough to
> justify a routing table slot.  In this case, I think it is, but as I
> mentioned above, I think you should have to work that out with your
> upstreams, not rely on ARIN to make them accept a whole bunch of lower-value
> PI /48s.

Translation: You don't want me to deploy IPv6. Okay. I won't.

This is an example of how needs-based allocation gets you into real
trouble real fast. As the gatekeeper, ARIN is stuck with this
damned-if-you-do, damned-if-you-don't problem which in a dynamic
system like 103 was solved with a trivial application of cash by those
willing to spend it.

If ARIN is to be the gatekeeper then ARIN policy must solve this
problem. Full stop.



>>> 6.2.3.5  Large (/28)
>>> To qualify for a /28, an organization must demonstrate the need to make
>>> assignments and/or reallocations equal to at least 20,000 /48s.
>>
>> Why not demonstrate that they -have made- at least 20,000 /48
>> assignments from their /32?
>
> That would be OK, but I was hoping to avoid having to make an ISP get a /32,
> start using it, and then renumber everything into a /28 if they know from
> the start they have more customers than will fit in a /32.

Why would they renumber? Your proposal allows them to hold both a /32 and a /28.

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