[arin-ppml] Using fees to encourage route aggregation

[David Farmer]

Scott Leibrand wrote:
> Milton L Mueller wrote:
>>
>> Thanks for your intervention, Chris. That's exactly where I've been 
>> trying to move. In that regard I find it interesting that despite the 
>> constant worrying about route aggregation, the proposal I made to use 
>> RIR fees to encourage aggregation (or "tax" deaggregation) has not 
>> attracted a single comment. People seem more interested in the broad 
>> ideological classifications than in assessing specific proposals. 
> 
> Perhaps people were ignoring the "fairness" thread?  :-)  Or perhaps, 
> like me, most people generally agree with that particular point, so 
> there's maybe not as much to discuss.  My own thought is that using fees 
> to encourage aggregation (discourage deaggregation) would probably work, 
> but that there isn't a lot of need for doing so just yet.  If we get to 
> the point where multiple networks are having problems with routing table 
> growth that can't be solved through filtering of distant more-specifics, 
> through charging customers for route announcements, and/or through 
> peering agreements, then perhaps someone will resurrect the idea on 
> arin-discuss for the board's consideration.
> 
> -Scott

Not that I would be against a market based economic approach, fee based 
disincentives, or necessarily for a policy based regulatory approach to 
encourage aggregation. However I do agree with Bill comments that;

"That ship has sailed for IPv4. CIDR combined with imperfect record
keeping and the concept of LIRs assigning addresses to multihomed
entities killed the possibility of disaggregate filtering in IPv4."

I do believe it is important to deal with IPv6 route aggregation and 
soon, because I also agree with Scott that "there isn't a lot of need 
for doing so just yet".  But that is because the IPv6 toothpaste is 
still mostly in the tube.  So while maybe we don't need it just yet, we 
can't wait until we actually need it, it may be to late to implement 
anything then.

However, even with more and more IPv6 coming out of the toothpaste tube 
everyday, I think we are better off in IPv6 than we are currently in 
IPv4.  With IPv6 there is simply just more room to work with.  Which 
allows for a generous but limited set of allocation sizes from the RIRs, 
with /32s for most ISPs and larger for really large ISPs.  With /48s 
from the RIRs for multihomed PI end-user assignments, or /48s, /56s, 
/64s, or /128s to end-users from providers for PA assignments.

So today for IPv6 ARIN provides /32s or greater for PA allocations from 
a set of ranges, the /48s or greater for PA end-user space from another 
range (probably set of ranges in the future, but only one range so far), 
and there several other special purpose ranges with a /48 
allocation/assignment sizes, this creates up a pretty reasonable set of 
filtering policies that can be implemented by the operator community.

For the ARIN region the current ranges are;

General Purpose Provider Allocations /32 or shorter;
2001:0400::/23
2001:1800::/23
2001:4800::/23
2600:0000::/12
2610:0000::/23

General Purpose End-User Assignments (PI), /48 or shorter;
2620:0000:/23

Special Purpose Micro Allocations, /48 of shorter;
Internal Infrastructure (non-routed), 2001:0506::/31
Exchange Points, 2001:0504::/31
Critical Infrastructure, 2001:0500::/30

If ARIN can maintain allocation and assignment policies that segregate 
the types of allocations and assignments into separate documented ranges 
I think it will be possible for the operator community to maintain 
reasonable routing policy and filters to implement their chosen policy.

I believe the General Purpose ranges, along with the Critical 
Infrastructure and maybe the Exchange Point Micro Allocation ranges, 
should make up most of ARIN region's contribution to the mythical global 
route table.

An idea I've been kicking around is a class of end-user assignments not 
intended for routing in the mythical global route table, but for things 
like VPNs, and other private network needs, not necessarily intended to 
have global reachability, but that needs global uniqueness and reverse 
DNS.  Some of you say use ULA for that, but ULA only provides statical 
uniqueness, not the guarantee of uniqueness that an assignment authority 
can, and since there is no assignment authority for ULA, authoritative 
reverse DNS is not possible. This would be similar to NRPM 6.10.2 but 
for end-users and not ISPs, since Micro-allocations for Internal 
Infrastructure are restricted to "Organizations that currently hold IPv6 
allocations".  I'd rather not debate the merits of this idea now, but 
wanted to provide an example that illustrates how ARIN policy can and 
should work with and enable good routing policy.

I'm not sure how many operators currently filter the Internal 
Infrastructure Micro Allocation range 2001:0506::/31. ARIN policy 
doesn't require anyone to do so, but by having it as a separate 
documented range ARIN policy makes it possible for operators to have a 
routing policy that filters it if they so desire.  Whereas if it were 
not a separate documented range, it would probably be nearly impossible 
to filter these allocations.

So currently the main policy tool that ARIN, and the other RIRs have, 
have that influences and enables routing policy is to create 
classifications for allocations or assignments and to put them into 
documented ranges.  So I believe we need to remember that RIR policy has 
a responsibility the consider and implement at least this part of 
routing policy.

So lets think about applying this to the IPv6 policies on the table 
right now;

2008-3 Community Networks IPv6 Assignment - It is probably kind of late 
in the process for this, but maybe it would be a good idea for these 
assignments to come out of separate documented range.

2009-5 Multiple Discrete Networks - Should those allocations come out of 
a separate documented range?

2009-7 Open Access To IPv6 - One of the things we are doing is removing 
the requirement to advertise a singe aggregate of an allocation. Rather 
than eliminating the restriction all together, it might be better from a 
routing policy point of view to create a separate documented range 
without the requirement to announce an aggregate.  Maybe it is not 
unreasonable for this to have an extra fee associated with an allocation 
out of this block too?  (Fees are not directly a policy issue, but it 
could be a recommendation that the Board consider an extra fee in this 
case.) I have heard some valid reasons for some networks to not announce 
an aggregate of there IPv6 allocation, but I still believe most network 
can and should announce an aggregate.  Maybe we shouldn't through the 
baby out with the bath water on this one.  Creating a range for 
allocations without the requirement for announcing an aggregate would 
allow operators to have a routing policy to require it for the vast 
majority that can and should announce an aggregate.

Comments please, and please bend my ear in Dearborn next week on this 
issue too.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================