[ppml] Policy Proposal 2007-6 - Abandoned

[Owen DeLong]

** Leslie -- Look about half way down for a statistical request.
Thx,

Owen

On May 3, 2007, at 2:48 PM, Jason Schiller wrote:

> 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.
>
You need to reread the policy.  The policy as written would still  
require
the user to meet the 50% utilization threshold for initial assignment  
and
would require an 80% utilization for any ability to get additional  
assignment(s).

> 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).
>
It was pointed out that it's easier for Spammers to cycle resources like
this through ISPs than through ARIN and there was no reason to believe
that any spammer who would make use of this through ARIN is not already
doing so using /22s.  As such, I consider this argument specious at best
and rather like FUD.
> 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 true in the PA world as well, yet, somehow it seems to end up
working out.  I don't see a difference for these arguments between
PI and PA.
> 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 policy proposal I submitted (and recently revised with Stephen
Sprunk) is an attempt to address this on a more global basis than
just this policy.  Given that you have already stated that any user
who would qualify under this policy (and then some) would have
a slot in the global routing table for their PA space, I'm not sure
I understand how this increases the routing table.  Could you please
explain that?
>>
>> 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.
>
It is a reality regardless of what we do here.  In fact, I would  
argue that
any assignments this policy would provide beyond what are already
available from PA /24s and PI /22s would be well inside the noise floor.

> 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.
>
What's the difference between a multihomed PI v4 and PA v4 from a  
routing
table perspective?  It's still the same sized slot and the same  
amount of
memory.
>
> 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.
>
A customer with 10 hosts wouldn't qualify under the proposed policy.
My math makes me think that to meet the 50% threshold for a /24,
you would need at least 63 hosts (126 available host addresses
divided by 2 (50%) is 63, right?).  Despite this fact, you aboveclaimed
that these customers who DO multihome receive a /24 and get a
slot in the routing table anyway from their providers.  At least the
policy as proposed seems to be better for the global routing table
than your description of current ISP practices.
> 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.
>
True.  However, there is existing policy to address that, and, a policy
proposal designed to make it even easier for ARIN to revoke resources
under such circumstances.






****** Leslie -- Here's the request...

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

Well, 3 years will require us to wait some time for the /22s, but,  
I'd agree.
I've CC'd Leslie on this message.  Hopefully she'll chime in with
the statistics.

>>
>> 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.
>
I agree.  I'm not a big fan of that approach either, and, I'm not  
necessarily
in favor of moving the bit boundary further to the right than /24.
> 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...
>
Yep.  Eventually, you come to realize that the current method of routing
is just plain broken and that we need to start routing on something  
other
than prefix in the IDR world.

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

> 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...
>
As well it should be.  Further, long term deaggregation is the  
reality we simply
need to accept.  It's going to happen.  Aggregation is selling in  
today's market
about as well as DiVX did against DVDs for many of the same reasons.
Consumers just don't like the limitations it imposes on their freedom  
of choice.
> 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.
>
Instead, let's admit that a long term commitment to deaggregation comes
with a long term commitment to fixing the routing process.
>
> 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 ...
>
Do you have any data to support the assertion that sites will  
multihome just
to get PI space?  I would assert that a large portion of sites will  
get PI
space just to make their multihoming choices easier rather than the  
other
way around.

If I'm willing to lie to get PI space by temporarily multihoming for  
that
purpose, then, I can just tell a slightly bigger lie and get a /22 now.

Owen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070503/1301dc08/attachment.p7s>