[ppml] Policy Proposal 2007-6 - Abandoned

On Fri, 27 Apr 2007, John Paul Morrison wrote:

> I don't know how this would lead to a run on IPv4 space, because I have 
> had to justify several /24's for
> customers - allocated out of Carriers/Telco IP address space to be used 
> for BGP multi-homing.
> It's a hassle, you are tied to one carrier's address space, and you
> have more dependence on the carrier's BGP policies than if you had your 
> own /24.
> I would prefer to have a direct allocation, but whether I get a /24 from 
> a carrier or ARIN, doesn't
> really change the address consumption.

They way I read the policy, and the way I understand how most ISP do PA
assignemtns, is if a customer is multi-homed even with a very limited
number of hosts they will qualify for a /24.  In otherwords, a single
homed static customer with 10 hosts could be assigned a /28.  The same
customer who is multi-homed would be assigned a /24.  This consumes more
space.

Also there was a concern about spammers.  Spammers tend to get their
address space black listed rather quickly.  Often times they will start a
new company, get new address space, get it black listed with in a month or
so, and then start the process over with a new company and new addresses.  
This could burn through a lot of resources quickly (both IPv4 PI /24s and
ASNs).

Furthmore reclaiming the resources will be problematic as it will be
listed in ACLs and RBLs.  This will be akin to the same difficulty people
have when they are allocated / assigned space that was previously bogon
space, and hence, no one will want pre-spammer IP space due to the
significant clean-up work involved. 

This is why I would be more agreeable with a policy that required a site
to actually be multi-homed for 6 months before they would qualify for
their own PI address space.  (although I suspect it would be hard for me
to support any policy that increases the routing table at this point).  

> 
> The requirement for a /24 to do BGP multi-homing is basically arbitrary, 
> but it dates back to concerns
> about routing table size. If you could convince the majority of ISPs and 
> AS's that /25's  or even longer
> prefixes belong in the global routing tables, then you could come up 
> with a workable IPv4 multi-homing
> solution that doesn't require a /24 allocation. However in practice, 
> longer prefixes may not be routable.
> 
> Perhaps the wording of 2007-6 should be changed to remove the reference 
> to a /24 allocation and focus
> on the actual need.  Routing table bloat is a concern, but I'm not sure 
> it's as big an issue as it once was 5 or 10 years ago.
> If routing table size is really a problem, it's going to be made worse 
> with IPv6, since that's going to cause
> more growth.  (I'm sure you can have an efficient IPv6+IPv4 RIB in 
> backbone routers, but IPv6 will only add routing
> entries, and at that point, who cares whether a route is an IPv6 /48 or 
> an IPv4 /28?)

Yes what we are talking about here is the amount of RIB and FIB memory
consumed.  In short there are a limited number of routing slots, and IPv6
prefixes take up more memory than IPv4 prefixes.  Routing table bloat is a
big concern.  It is a concern in IPv4, it is a concern in IPv6, and it is
a concern in a dual stack environment.  

Because of the current concern about routing table size, there is no clear
consensus among ISPs if they will listen to /48 IPv6 PI addresses (or even
/48 IPv6 PA more specifics) from multi-homed destinations of Peers.  So I
am not sure I buy your arguement of things are going to get really bad
when IPv6 mult-homing happens, so we might as well let some extra IPv4 PI
/24s in the table now.  This to me sounds similar to the arguement that we
are running out of IPv4 addresses so we should just speed this process
along by giving out addresses to anyone who asks.


My concern is that it will increase the number of prefixes in the
table.  A customer with 10 hosts and no need for multi-homing needs only
an IPv4 PA /28.  That IPv4 PA /28 does not show up in the global routing
table as it is aggregated into the the PA aggregate (say a /12).  That
single prefix (/12) in the routing table can represent many (65,535 /28s) 
small customers.  

Now if some percentage of customers have no need for multi-homing but want
their own provider independant IPv4 space, then they may multi-home long
enough to get their own block.  Say for example it may be more cost
effective to purchase a seccond Internet connection for one year in order
to get their own PI addresses rather than the cost of eventual
renumbering.  In one years time when they stop multi-homing, the routing
system will still be required to carry the extra /24 as it cannot be
aggregated into a PA block.

It might be interesting to study what addresses are assigned under the
multi-homing policy, and see what percentage of these blocks (and their
associated ASN) appear to still be multi-homed one, two, or three years
after the assignment is made.  

> 
> If ARIN sets aside some space specifically for multi-homed ASs, which is 
> allowed to have /25 or longer allocations, carriers
> can still filter the rest of the routing table to restrict more specific 
> routes, and can make exceptions for this
> address space. But the technical challenges will have to be addressed by 
> the carriers and end users, because
> prefixes longer than /24 could easily be non-routable.

It seems unfair to have different policies for PI multi-homers and PA
multi-homers.  Not everybody wants PI addresses.  If PI /25s are allowed
to consume a slot in the global routing table, then current PA
mutli-homers will want to be able to divide the PA /24 in two /25s to gain
more control over thier in-bound traffic loading.

Likewise if ISPs start listening to IPv6 PI /48s from Peers, then they
should also listen to IPv6 PA /48s from Peers.  After all if it is
acceptable for a PI multi-homer to consume one slot in the global routing
table, then it should also be acceptable for a PA mutli-homer to do the
same.  Then is goes to follow that more than one slot should be allowed to
enable destinations to control their inbound traffic loading...  

And we end up doing IPv6 multi-homing exactly how we are doing IPv4
multi-homing.  While there are not a ot of prefixes int eh IPv6 routing
table at the moment, once wide spread adoption happens this will no longer
be true.  

I suspect it will me much more difficult to tighten the belt in the
future.  So a decesion now to allow deaggregation to support multi-homing
is likely to be a long term commitment to deagragation in order to support
multi-homing...  

So what does a long term commitment to deagragation look like?  Well, lets
first try to understand how big the routing tabel would be if everyone
adopted IPv6 and moved to a dual stack enviorment tomarrow, and then
project out from there to some future point.


Here is some quick math on the routing table problem:
The CIDR Report:
Date      Prefixes   CIDR Aggregated
04-05-07  216692     139633

24992  	Number of ASes in routing system

1. The IPv4 Internet table is 216,692 routes

2. The IPv4 Internet table can be aggrgeated down to 139633, which means
that there are (216692 - 139633) 77,059 intentional more specifics for
multi-homing and TE and such. 

3. If everyone did dual stack tomarrow (I know there will be a ramp up),
they waould have one aggregate for each site (ASN) 24,992

4. If we did multi-homneing and TE in IPv6 the same a swe do for IPv4 we
would have 77,059 intentional more specifics for multi-homing and TE.
 
5. If everyone did dual staick tomarrow the IPv6 Internet would be 
(24,992 + 77,059) 102,051 routes.

6. add to that the internal IPv4 more specific routes of a large ISP say
150,000 routes.

7. add to that the internal IPv6 more specific routes of a large ISP say 
120,000 routes

8. you end up with a total routing table of about 
(216,692 + 102,051 + 150,000 + 120,000) 588,743 routes.

Now if you think IPv4 exhaustion might happen by Jan 1, 2010, and expect
wide spread IPv6 adoption to follow right behind that then you can project
the routing table will be about a 800,000

If you think IPv4 exhaustion might happen by June 12, 2012, and expect
wide spread IPv6 adoption to follow right behind that then you can project
the routing table will be about 1.2 million routes

Now add to this all of the extra prefixes from sites that start to
multi-home just to get PI space, and all of the /24s that are leased out
of legacy /8 space, and evry third household in China being multi-homed,
and every item in Wal*Mart havig a RFID tag with an IPv6 address, and ...

__Jason 




> 
> 
> John Paul Morrison
> 
> 
> 
> 
> 
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
>