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