[arin-ppml] Simplified IPv6 policy

[Scott Leibrand]

On 12/23/2009 10:52 AM, William Herrin wrote:
> 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.
>    

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

I'm not sure what you think makes /24 PA in IPv4 special, then.  It's 
not because ARIN policy allows ISPs to give them out: IPv6 PA /48s can 
be given out even more easily.  Is it just because we have a swamp of 
legacy class C's that can't be filtered?

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

I proposed (and we adopted) policy 2007-21 
(https://www.arin.net/policy/proposals/2007_21.html) to address the 
issue of the class of users with legacy /24s who couldn't get IPv6 PI 
space.  Maybe once I understand what aspects of IPv4 PA /24s need to be 
replicated in IPv6, I can better understand where current policy (and 
current proposals) fall short.

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

We understand their concerns (and share many of them), but there are a 
lot more small orgs demanding PI, so large orgs definitely don't have a 
veto.

> 2. Ignore Verizon presuming that customer and government pressure will
> eventually compel them to practices compatible with ARIN policy.

This appears to be what will happen for the existing PI /48 policy.  If 
we create a new set of filterable PI with more liberal rules, though, 
I'm pretty sure they (and other ISPs) will filter those for quite a 
while longer.

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

Heh, good luck with that.  :-)  Among other things, you'll need to 
demonstrate why those 500 VMs each need a unique public IP address.

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

Agreed that it's a minor point, which we can decide on when it comes 
time to iron out details.  Either way would work.

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

I think you're making an unfounded assumption that PI space is the only 
way to multihome.  It is true today that PI space is (mostly) routable, 
because most ISPs see filtering PI space as more problematic than 
carrying it in their RIBs and FIBs.  However, if PI space were given out 
like domain names, then that tradeoff  would no longer hold.  If, for 
example, we adopted 103 as written (with your suggested fee schedule), 
then /48s and probably even /40s would be filtered by a large number of 
ISPs, requiring everyone desiring global reachability to upgrade to a 
/32 or go back to PA space.

On the other hand, the only thing I can see preventing ISPs from 
accepting PA /48s is the lack of market pressure to do so.  If my paying 
customers want to multihome with PA /48s, I'll be happy to accept them 
from my customers, announce them to my peers and transit providers, and 
accept them from my peers and transit providers as well (for failover). 
If there's enough demand, I'm sure other ISPs will do so as well.  If 
there's not enough demand, then maybe there's not enough demand to 
justify forcing ISPs to filter, either...

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

Or they could keep both, but I'd rather not force them to have two 
blocks when one will do, either.

-Scott