[ppml] Just say *NO* to PI space -- or how to make it less destructive

[Stephen Sprunk]

Thus spake "Pekka Savola" <pekkas at netcore.fi>
> On Thu, 20 Apr 2006, Stephen Sprunk wrote:
>> I think that the multihoming requirement will be enough to keep the 
>> number of assignments reasonable; if you look at the actual number of 
>> non-transit ASNs in the v4 table, it's not all that large.  If we assume 
>> one PIv6 prefix per non-transit ASN, which is the goal, we're looking at 
>> under 10k routes from the ARIN region.
>
> (Actually, the number is somewhere between 15k and 20k but that's beside 
> the point.)

ARIN Region origin ASes present in the Internet Routing Table:    10637
...
ARIN Region transit ASes present in the Internet Routing Table:     986

To me, that says we have 9651 non-transit ASes in ARIN-land today.

Now, if every one of those ASes got an assignment under 2005-1, we'd kick up 
the size of the v6 routing table to 14 times its current size -- but it'd 
still be only 1/18th of the current v4 table.  Where's the problem?

> The upper limit is around the number of AS numbers, and if it's expanded 
> to 32 bits, at least I start to feel uncomforable... "Umm.. are we sure 
> 64K folks playing around at DFZ isn't enough??? we want 4B instead...????"

There's at least one router vendor that claims their box can do 1M routes 
today; Moore's Law says in 18 years they'll be able to do 4B ASes with one 
prefix each.  I'm pretty confident we won't run into that particular limit 
before we run out of networks to multihome, at least not with the proposal 
on the table today.

> Remember, it's easy and cheap to have a multihoming setup with two DSL 
> lines...

That loophole in the definition of multihoming needs to be fixed.  For that 
matter, ARIN told me offlist that two IP-in-IP tunnels over a single 
physical link counts as multihoming...  Sheesh.

OTOH, it's ridiculously easy to get PIv4 space today (512 hosts and two 
pipes or tunnels), and there's not all that many companies doing it.  It's 
not growing much either.  The doors are already wide open for a land rush 
and nobody is taking ARIN up on it.  Why does everyone assume it'll happen 
with v6 if it's not happening with v4, which _is_ useful today?

>>> setting a foundation for multihoming research to actually SOLVE this
>>> problem, etc.etc.
>>
>> In theory, we already have a group tasked with that: the IETF.  Are
>> you proposing that RIRs start developing protocols outside the IETF? Or 
>> funding people to work full-time in the IETF on problems pertinent
>> to RIRs?  Again, this is a slippery slope and distracts from the RIRs'
>> purpose.
>
> I said 'research', not 'engineering'.  The IETF isn't the right vessel for 
> research, though IETF could maybe be consulted on it.

s/IETF/IRTF/ then.  The RRG is expecting to have results sometime between 
2007 and 2011.  That's probably sufficient, if they actually deliver 
something useful.

Still, the RIRs' job is not research, it is stewardship of address space and 
serving its members.

>>> I wouldn't object to reserving a /44 just in case, but make no
>>> provisions (at this point) for applying more.  If someone needs more
>>> than /48, it needs to justify another one, and get a separate /48
>>> (with its own reserved /44).
>>
>> So instead of giving an org a /47, which _could_ be advertised as a
>> single route, you'd prefer to give them two /48s, which _must_ be
>> advertised as two routes?  That seems to increase routing table
>> pollution, not reduce it.
>
> Not necessarily.  Doing so would hopefully ensure that it'll be *more* 
> difficult to justify for more than a /48 especially if you have to pay for 
> the extra too (hence less pollution).  I.e., we'd need to figure out we 
> have sufficiently strict criteria.

That just seems backwards to me.  If a site _can_ justify more than a /48 
under whatever the policy is, why would we want to assign two separate 
blocks that can't be aggregated into a single route?

>> Also, what's the point of reserving a /44, or worse multiple /44s, if 
>> we're only going to let people use a /48?  That seems to defeat the 
>> purpose of having a reserved block.
>
> As I said, I wouldn't object to reserving a /44 under those conditions, 
> but I wouldn't require reservation either.  One reason for reserving is 
> that we could have the option of changing the policy later if we become 
> wiser (or dumber) and decide that maybe we'll want to be able to deal out 
> aggregatable chunks after all, regardless of the more specific crap that's 
> filling the routing tables right now.

If we're going to reserve, we ought to assign supernets within that block as 
justified by the org.  If they deaggregate, so be it, but at least there's 
the chance they won't.

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin