Policy Statement on Address Space Allocations

Sat Jan 27 07:45:05 UTC 1996

Original message <96Jan27.012415-0000_est.20615+371 at chops.icp.net>
From: Sean Doran <smd at icp.net>
Date: Jan 27,  1:24
Subject: Re: Policy Statement on Address Space Allocations
...
> 
> The encouragement, IMHO, should be in the form of the work
> PIER is addressing (sorry about the pun), some possible
> future renumbering tools, NATs, or any other technology
> which results in making a change of addresses painless and
> quick, so that people have little or no reason to object to
> using provider-supplied addresses.

Right. Exactly. But UNTIL such time as easy renumbering for everyone is
a reality, watching a world where the policy of one of the big service
providers collides directly with the policy of the address assignment
agencies makes me wonder what whose goals really are, and really REALLY
glad that the company I founded is as big as it is already. 

And that's because if I was starting that company TODAY, and I knew that in
less than two years down the road I'd be in a position where I'd be multihomed 
and/or at an interchange point, I'd be stuck... because there's no way I could
get an initial address block for assignment to my customers that was also big 
enough to pass Sprint's routing filters. 

I don't even understand how I'd effectively use such an address... If I get
an address from my provider, I'm doomed to renumbering in the event that
provider can't provide me with all the service I need, and I can't subject
my customers to that. But the first "portable" block of addresses I could
get (speaking hypothetically as a new ISP) wouldn't work to get everywhere,
because Sprint (and no doubt others in the future) would ignore the 
announcement. Since those addresses would be worthless, there's no way
I could ever use them, and thus no way I could ever satisfy the Internic
that I'd effectively used my first block of addresses and was ready for
a bigger one. I forsee a large number of new /19's filled with fictitious
entities, followed immediately by the application for an additional, larger, 
block... and if we're concerned about the efficient use of address space
(and not just routing table size) that's a serious waste.

Why can't we just all agree, at least for a little while, on the SAME
address efficiency vs. routing table size tradeoff?  RIPE, et al has decided
that initial assignments of /19 are the right tradeoff. Sprint has decided
that /18 (or maybe /17 now) is the right tradeoff. Similar, but not the same,
choice. If it was the same, this argument would be over and new providers
could continue to spring up without having to wonder how they're going to get
their first addresses routed and NSP engineers would know that routing table
size, while perhaps a bit larger than they'd wanted, would still be seriously
limited in growth compared to the alternatives. I really don't care whether
Sprint changes their filter to be at /19, or if RIPE, IANA, et al decide
that Sprint really is smarter than they are and that /17 is the correct
tradeoff point, but its just 2 bits! Stop claiming technical superiority
and just make it work right for everyone simultaneously!

We (scruz-net) advertise more addresses than I'd like, but the Internic
forced us into that corner. We asked for a big block over a year ago. They
gave us a /21. We used it right up and asked for a big block again. They
gave us a /20. We argued with them about it, and they refused to budge, so
we went ahead and used it up to. Then we asked for a big block again. THAT
time they believed us. We got a /16. Had they given us the /16 the first
time, we'd have 2 fewer announcements in 204.*, and still not be quite done
using it up. But I'm not going to go tell a hundred or more customers
(a good number of those 204.* addresses are subnetted into /29 for "small LAN"
customers) that, without the benefit of any renumbering tools, they get
to change everything around and sit on the phone all day with our tech support
staff until it works correctly again. 

-mattthew kaufman
 matthew at scruz.net