Re: Your class 'B' address space

[John Todd <jtodd () loligo com>]

[Warning: Long post.  Get another cup of coffee before reading.  To save time
for those of you looking for the short answer: "Mark - start peering with your
upstreams with a small announcement of /23 or /24, and you'll be fine -
there's
no need for you to get a block from ARIN for your requirements."]

At 11:14 AM 9/28/98 -0700, Mark Vickers wrote:
> Let's add a little spice to you list...run it up the flag pole etc... but
> please let's deal with this professionally with out to much flame!
>
> My goal is to ensure the network meets the business objective of our
> company, not simply to debug traffic etc. In order to do this I need
> redundant connections to multiple ISP's, and a method for delivering delay
> sensitive traffic in the most efficient way possible.
> The above implies BGP.

Correct so far.

> I've applied to ARIN for a number block large enough to ensure
> routablility, and have been rejected.  This leaves me with three
> alternatives, please correct me if you see any another alternatives. First,
> we can attempt to buy address space which may or may not be transferable,
> or more likely we acquire a small company, and/or it's assets, one of which
> just happens to be a large chuck of address space. Second, I can do the
> time proven technique of lying about how many hosts I have or how many I
> plan to have, this I find uncomfortable as I think it is dishonest! I'd bet
> at least one of the readers of this list has exaggerated about how may
> hosts they have in their network, or how many they planed to have on a
> template, so don't be to quick to grab for the high moral ground!! Finally,
> I can appeal ARIN's decision, which I have already requested from IANA, and
> was told to request an appeal from hostmaster () ARIN net. I'm still waiting
> to here something.

Your implied assertion that you need a set of address space that is larger
than
a /24 (or /23, or even /22) to "ensure routability" is not valid _enough_. 
Currently, only Sprint, AGIS, and a handful of others are filtering >/19
routes
(in certain /8 ranges) at their borders, unless the number of aggressively
filtering NSPs has changed significantly since it was last brought up on this
list some months ago.

  If your "primary" upstream from whom you've received a /24 is advertising
your /24 in a larger aggregate, and you also are advertising your /24 through
at least one other NSP that is not Sprint (the other possibly being Sprint or
some other NSP) then you have two valid inbound paths with acceptable
redundancy.  You could also ask your primary upstream to "de-CIDRize" their
own
announcement and double-announce the /24 with your AS tag and also the larger
aggregate with only their own AS path, but that's how you get into The CIDR
Report more often.  :)  Anyway, you're indicating that a significant
portion of
your customers are single-homed with Sprint or AGIS (or some other
route-limiting NSP) who can't hear or won't choose the more specific /24 over
the larger aggregate announcement.

I think the number of sites that have this particular situation is very small
and does not justify such an enormous waste of address space to circumvent the
filters on these particular providers.  Small address advertisements (>/19)
are
sufficient to provide acceptable redundancy in a multi-homed environment.

In any case, your intended use of a larger aggregate completely invalidates
the
reasons that (from what I understand) Sprint and AGIS block those routes:
overfull and unstable routing tables.  You're creating the same end result
with
the same number of announcements, and using up valuable IPv4 space as a side
effect.  Double plus ungood.  You should opt for the "least worst" scenario,
and simply advertise a /24 through multiple upstreams out of your primary's
larger aggregate.

Furthermore enforcing "acceptable redundancy", regardless of Sprint/AGIS
filters: Most regionals are multi-homed through at least two NSPs, at least
one
of which will not be Sprint or AGIS.  This means that the packets find their
way to you even if your connection to your "primary" drops (and therefore all
traffic from Sprint to your network in the aggregate starts to blackhole at
your primary's IGP-BGP border.)  Therefore, Sprint/AGIS can't get to you, but
the overwhelming majority of the Internet still can get to you through a more
specific path, even if many of those people have some of their connectivity
provisioned by Sprint/AGIS.  I will certainly not say that you won't have some
number of customers that can't get to your service.  If you're that concerned
about them, pull in T1s from both Sprint and AGIS - they'll announce routes
from customers that they won't accept (at least, Sprint seems to - can't say
about AGIS) and I expect the bandwidth costs for those "Sprint/AGIS only"
links
will not be unfairly priced compared with what you'd have to pay for
transit to
Sprint/AGIS across someone else's backbone, anyway.

Essentially, I disagree that the premise for your address requirements of any
size to ARIN is valid based on the information that you have revealed thus
far.  If you have 5,000 hosts that all must see the Internet and are running
web servers, then it's a different story.  But if you're just a few dozen (or
even hundred) servers, a /24 or /23 should be sufficient for an acceptable
delivery-of-service level.

> On appeal I plan to quote RFC2050 which according to the ARIN web site is
> what they use make allocation descions.  Basically I think ARIN procedures
> only take into account network size, and nothing else. I don't think
> RFC2050 language is that strict.
>
> Please see item '3b' below:
> "In order for the Internet to scale using existing technologies, use of
> regional registry services should be limited to the
> assignment of IP addresses for organizations meeting one or more of the
> following conditions:
>
> a) the organization has no intention of connecting to the Internet-either
> now or in the future-but it still requires a globally
> unique IP address. The organization should consider using reserved
> addresses from 1918. If it is determined this is not
> possible, they can be issued unique (if not Internet routable) IP addresses.
>
> b) the organization is multi-homed with no favored connection.
>
> c) the organization's actual requirement for IP space is very large, for
> example, the network prefix required to cover the
> request is of length /18 or shorter.
>
> All other requesters should contact its ISP for address space or utilize
> the addresses reserved for non-connected networks
> described in 1918 until an Internet connection is established. Note that
> addresses issued directly from the
> IRs,(non-provider based), are the least likely to be routable across the
> Internet. 
> "

You may be right, since option "b" is pretty clear.  And I might even agree
with you that ARIN should allocate you addresses (small addresses, though)
using this as the only criteria.  But it's not the only criteria used.  RFC
2050 is a "guideline" as expressed in http://www.arin.net/ip-allocation.html ,
but other CIDR-based RFCs are listed as resources, and the document even goes
so far as to say:

  "These potential policies may include such steps 
   as setting limits on the size of Classless Inter-Domain 
   Routing (CIDR) prefixes added to the routing tables or 
   filtering of non-aggregated routes."

I'm just reading the text; it's fairly clear that ARIN can be ambiguous about
their allocation sizes.  That may be unfair, or may play favorites, or
what-have-you, but that's not the issue we're debating and should be taken to
another thread (threat?  thread? ;) which can heartily fill my /dev/null
procmail ruleset.

> Also, from 3.1 "utilization is a key factor" implying it's not the only
> factor.
>
> "
> 3.1 Common Registry Requirements
>
> Because the number of available IP addresses on the Internet is limited,
> the utilization rate of address space will be a key
> factor in network number assignment.
> "
>
> Basically our normal output traffic is about 45mb/s with a peak as high as
> 67.6Mb/s during Clinton's shinangians, we've been listed as the 16th
> busiest web site in the world, and I think that ought to count toward
> getting a routable address space!!!

Hardly.  According to nitrous.digex.net - Looking Glass: ad.DoubleClick.com is
on a /23.  www.ABCNews.com is in a /20.  www.weather.com is on a /24.  These
sites are working just fine in >/19 networks, and I'm sure they push just as
much data as you, and are no less "important" as you, unless you care to tell
us how your bits per second output should influence policy that effects
everyone.  So are you a proponent of "largest bit _output_ wins"?  If so,
please see the settlement argument of a few weeks ago on this list for some
excellent discussion.  Shouldn't you be giving IP addresses to ME?  ;)

> I also wonder if there aren't free speech issues involved if US entities
> start dropping traffic based on non technical factors?

I don't see how this is relevant, and in any case, no.

> I welcome any suggestions you may have as to how I can archive my goal of
> obtaining an address block big enough to implement BGP succesfully.

See my initial invalidation of your address size requirement above.  I think
you'll be happy with a properly advertised block from within an aggregate.  

JT

> Thank You
>
> Mark Vickers
> RealNetworks, Inc.