- Test - lists.nanog.org

Re: 206.82.160.0/22
by jnc＠ginger.lcs.mit.edu 25 Sep '95

25 Sep '95

<Let's see, this argument has now been had on CIDRD, Big-Internet, Com-Priv, and now it seems to have struck NANOG. Anyone care to guess how many more mailing lists we can have the same debate one? This is really tedious, stupid, and wasteful, everyone.> From: john(a)interport.net (John Riordan) we have had similar problems trying to grow and operate as a small niche provider. It all seems to stem from the understandable fact that the larger providers are trying to look out for the interests of Internet as a whole as well as themselves. This whole conversation would be a more productive if we could basically (see below for exceptions) leave the large and small providers out of it, as well as people looking out for whomever, etc. This whole renumbering/topopology-based-addresses stuff all has its roots years and years back, before we had *any* providers, large, small, or gargantuan. It's here now for reasons that have nothing to do with providers or business reasons. As things stand now, unless we change the Internet so that IPv4 addresses are no longer used by the routing, we have this renumbering/TBA stuff to wrestle with. So, please let's not hear anything more about large providers looking out for anyone, small providers losing, etc, etc. That may be the *effect*, but it's not the *cause*. Anyone who thinks otherwise has ahold of the wrong end of the stick. The one exception to all this is that in any hierachical addressing scheme, as one goes up the tree eventually one gets to chunks of the network which are large enough that one doesn't need to aggregate anymore, and if you're a very large provider, maybe you get to be one of those high-level chunks. These chunks, being top level naming objects, wouldn't have to rename as the topology changed. So, in that sense, maybe the very large providers have an advantage. I don't know how to fix this. However, I feel .. that a competitive market place which allows small niche providers to compete will benefit the Internet in the long run. All else being equal, I agree with you. However, we have to have a working Internet first, and as long as IPv4 addresses are used by the routing, they have to be aggregable, which means they have to be connectivity-based, which means they change when you move. Within that envelope, I'm open to suggestions. it is not clear to me how a policy which only enables organizations able to justify /18 portable independent allocations for reassignment ... will provide a competitive environment which includes small niche providers. I personally think the whole concept of filtering routes based on prefix size is an ugly stopgap, one with bad side-effects. All the prefix-size thing is is an attempt i) to limit the current number of entries in the routing table by getting rid of ones that likely only benefit a few people, and ii) to limit the maximum possible size of the routing tables (although 2^18 is still probably too big). The limit might have to move up if we fill the routing tables with /18's... Maybe I'm missing something, maybe all this is being taken care of as I write this ... or maybe the Internet would be better off without all the small niche providers. You seem to keep assuming that this is all being done to the intended detriment of small providers. It's not. If there were a better solution available already deployed (which is the timeframe we're talking in), I'm sure we'd all be happy to use it. There isn't. My hope is that those parties who do influence policy creation will leave room for small niche players players to compete when they do come to agreement on this and future issues. You seem to keep overestimating the degree to which this is driven by policy. The policy is just strugling to ameliorate the bad side-effects of the technical box we are in, and frankly, there isn't a lot to be done. Also I hope that those same parties are cognizant of the fact that actions they take to further their goals can have a serious impact the small players out there. ... it could devastate a small niche provider someplace who has to say to their clients, "Sorry, we are only able to provide you with partial Internet service at the moment because Sprint doesn't like the addresses we assigned you". "further their goals"? I'd assume that having a working Internet is a goal we *all* share, and not just some nebulous crowd of large providers (AKA Bad Guys). If you don't like the picture of telling your customers that, why don't you try telling them "Sorry, we are only able to provide you with partial Internet service at the moment because due to the way people have assigned addresses, the routing has fallen over." Are they really going to care much about exactly what the phrase is after "because"? Noel

3 2

Request for Comments on a topological address block for N. Calif.
by George Herbert 24 Sep '95

24 Sep '95

This has been brought up before and discussed to no final conclusion. I am more interested at this point in actually doing something, so I would like to issue a final-round-of-discussion request for comments prior to making this happen. I propose that a large block (say, /8 to /10) be allocated to an independent authority which will then reallocate growable blocks to small to mid level ISPs in the northern california region who are connecting via providers attached to MAE-W, CIX, or PacBell's NAP and topologically "at" those connect points. These addresses can then be filtered out of announcements to routers anywhere else in the world and replaced with a /8 aggregate announcement; only routers within the topology zone would require full information on the connected entities. These addresses will be relatively easy to dual-home within the area, yet will have minimal impact on the global routing infrastructure. To minimize the number of routes announced within the area, all addresses assigned would be sufficient for 6-month in the future at demonstrated growth rates, and reservations for up to 18 months in the future at demonstrated growth rates would be made when possible (giving the inherent ability to grow /20's to /19s and /18s etc. rather than have to make a new announcement). A minimum size of /20 would be required for entrance; smaller ISPs would have to go through traditional allocation-from-their-upstream-provider channels. This would tend to make brand new startups avoid cluttering the space until their growth was established and measured. Some sort of nominal fee on the order of $1 to $2.50 per /24 equiv would probably support the operation just fine, which should be within the range nobody will object to. Comments, suggestions, pointing out of fatal flaws or anyone stating they will be completely unwilling to go along with this are solicited (though I would appreciate an explanation for objections or refusals 8-). Thank you. -george william herbert gherbert(a)crl.com

4 10

Re: Request for Comments on a topological address block for N. Calif.
by Sean Doran 24 Sep '95

24 Sep '95

The issue Andrew and Tony were raising was a bit more simple and a bit more complicated on several fronts. Let's start with a picture: MAE-WEST PBNAP MAE-EAST 39.0/10 39.64/10 39.128/10 A------| S----| A--| S------| M----| S--| M------| N9---| M--| N9-----| NE---| N9-| NE-----| Y----| NE-| X------| Z--| In normal conditions: How does X get traffic to Y? How does Y get traffic to X? How does X get traffic to Z? How does Z get traffic to X? How does Y get traffic to Z? How does Z get traffic to Y? How does A get traffic to Y? How does Y get traffic to A? Where can 39.0/9 be aggregated? Where can 39/8 be aggregated? What are the side-effects of both these aggregations when things are operating normally? In failure conditions: If S falls off MAE-WEST, how does it get traffic to the customers of A, M, N9, NE and X that are addressed by 39.0/10? How do A, M, N9, NE, and X get to S's customers that are addressed by 39.0/10? If A falls off MAE-WEST, how does it get traffic to the customers of A, M, N9, NE, and X that are in 39.0/10? How does it get to all of 39.0/9? How does the rest of the world get to A's customers that are addressed in 39.0/10? What happens in both these cases to traffic between Z and everything in 39.0/9, in each direction? These definitely are not hypothetical questions. If geographical or stratum-based allocation that is not _also_ provider-based is to fly, this is precisely the type of thing that must be dealt with. Sean.

2 1

Re: Request for Comments on a topological address block for N. Calif.
by Sean Doran 24 Sep '95

24 Sep '95

| If, say, | mountainview.net (which is fictional (I hope 8-)) branched out to Miami, | and bought another Alternet ISP T-1 connection out there, they would | then be getting free transit between them. Presumably if both were | Alternet connections, you'd figure it out. If they bought Sprint access | in Miami, then they might fool both of you. Forgive me for being obtuse, but I don't see that this is a problem. After all, if they bought two AlterNet connections, isn't being able to send traffic across AlterNet what they're *paying* for? And if they bought a connection to each of AlterNet and Sprint, it strikes me that one fee is going to A to get traffic into S and to accept traffic from S and deliver it to the Alternet site, while the other fee is going to S to get traffic into A and to accept traffic from A and deliver it to the Sprint site. The current situation has just changed a bit. Some provider has identified routing slots as a precious, valuable commodity, and that while reachability outside that provider's network has value, that value-per-routing-slot is considerably greater when the population density of that routing slot is greater. (One might measure population density as one of actual or estimated actual hosts-per-prefix, interesting things per prefix, or potential hosts-per-prefix. Who knows?) Hypothetically speaking, in a situation like the one above, if a site wants to break aggregation -- be it geographical aggregation or be it provider-based aggregation -- then that site might expect to have to negotiate some kind of settlement with one or even many large and small providers in order to let that non-aggregated, less-densely-populated route consume a routing slot in their routers. In this situation again, if the new site were to take addresses from its provider, or from its geographical area, then there will be no additional consumption of a routing prefix beyond the scope of the AAB. If the AAB is the provider, or a subset of the provider's network, then that provider is being paid for the connection anyway, and presumably the routing slots for the prefixes that only that provider sees are rolled into the fee. | You could easily avoid this by adding a statement to your service contracts | for addresses allocated from these geographical block(s), which states that | there must be full disclosure to all involved upstream providers if the | company adds sites outside that area. If they fail to do so they would | then be defrauding you. I see. So you want providers to tell their customers that their customers have to report how well they're doing growth-wise to their providers? Dear Karl Denninger, you are obliged by contract to tell me the locations of all your customers and anything downstream from them that are outside the Chicago area. Do you really think this will fly? (And no, that's not an entirely rhetorical question). Sean.

1 0

Re: filtering long prefixes
by Sean Doran 24 Sep '95

24 Sep '95

Yup, 206.12/16 is the first area that jumped out at me after noting that many /19s and longer under 206/8 can easily be aggregated under /16s or better. Is Herb Kugel still the IP registrar for Canada? One thing to note right now is that because of the 206.12/16 prefix itself, traffic to subnets of 206.12/16 that aren't heard within SprintLink will get delivered to InternetMCI, which announces the /16 to us. Unless InternetMCI changes its configurations to do similar filtering, they may end up dumping traffic for subnets of 206.12/16 onto the MAE or NAP where they receive it from AS 1239. If they change the configuration, then they will follow the longest prefixes they have, which may be the /16, and deliver the traffic appropriately. At that point, some traffic for non-CA*Net sites will hit CA*Net, and whether it gets delivered or not deepends on local connectivity within Canada. It'll work handily for sites that peer with CA*Net or BCNet (which seems to be the CA*Net member that announces 202.12/16). Such is the price of geographical allocation. Something to be considered by the folks who recommend that approach. Sample traceroutes follow. Sean. P.S.: This raises an interesting point that has been raised in private email to various folks concerned with 206/8: if local aggregation cannot be done, then I suppose it would be easy enough to have some well-connected provider somewhere generate a prefix that is 18 bits long or shorter and deliver to the subnets appropriately. Whether this would be done out of the goodness of that provider's well-connected heart, or for a fee, is an interesting question. - -- : chops.icp.net-MHRC ; traceroute 206.12.101.1 traceroute to 206.12.101.1 (206.12.101.1), 30 hops max, 40 byte packets 1 sl-hrn-1-E5.sprintlink.net (199.0.55.1) 5.006 ms 5.927 ms 4.424 ms 2 sl-fw-8-S3/0-T1.sprintlink.net (144.228.38.61) 44.53 ms 40.226 ms 40.043 ms 3 sl-fw-6-F0/0.sprintlink.net (144.228.30.6) 41.199 ms 39.808 ms 39.474 ms 4 sl-ana-1-H2/0-T3.sprintlink.net (144.228.10.30) 73.9 ms 63.938 ms 63.856 ms 5 sl-ana-2-F0/0.sprintlink.net (144.228.70.2) 67.004 ms 63.935 ms 64.846 ms 6 sl-stk-6-H2/0-T3.sprintlink.net (144.228.10.25) 75.445 ms 115.007 ms 130.088 ms 7 sl-mae-w-H1/0-T3.sprintlink.net (144.228.10.46) 120.591 ms 75.239 ms 74.903 ms 8 mae-west.SanFrancisco.mci.net (198.32.136.12) 106.208 ms 84.766 ms 84.696 ms 9 mae-west.net99.net (198.32.136.16) 91.729 ms 81.322 ms 185.042 ms 10 seattle-1-E0.net99.net (204.157.228.50) 121.525 ms 119.73 ms 118.15 ms 11 cortland/C4-0/T1.net99.net (204.157.10.50) 123.203 ms 123.439 ms 119.942 ms 12 cyber/westnet.cyberstore.ca (199.45.68.6) 136.102 ms 125.274 ms 136.192 ms 13 vanrs001.cyberstore.ca (199.45.66.251) 106.903 ms 115.651 ms 107.9 ms 14 sl-chi-4-S3/2-T1.sprintlink.net (144.228.54.37) 103.651 ms 106.569 ms 106.307 ms 15 sl-chi-6-F0/0.sprintlink.net (144.228.50.6) 153.965 ms 221.79 ms 224.213 ms 16 sl-chi-nap-H1/0-T3.sprintlink.net (144.228.56.10) 106.431 ms 105.126 ms 107.66 ms 17 aads-F.mci.net (198.32.130.227) 111.367 ms 111.693 ms 109.686 ms 18 border2-hssi1-0.Chicago.mci.net (204.70.25.5) 104.894 ms 109.886 ms 106.115 ms 19 core-fddi-1.Chicago.mci.net (204.70.3.81) 136.612 ms 159.454 ms 245.642 ms 20 core1-hssi-2.NorthRoyalton.mci.net (204.70.1.94) 104.756 ms 109.119 ms 109.809 ms [ and goes around in circles, because this prefix doesn't seem to be pointed at anything...] : chops.icp.net-MHRC ; traceroute 206.12.117.1 traceroute to 206.12.117.1 (206.12.117.1), 30 hops max, 40 byte packets 1 sl-hrn-1-E5.sprintlink.net (199.0.55.1) 4.724 ms 2.708 ms 3.42 ms 2 sl-fw-8-S3/0-T1.sprintlink.net (144.228.38.61) 43.637 ms 39.825 ms 39.304 ms 3 sl-fw-6-F0/0.sprintlink.net (144.228.30.6) 52.659 ms 42.551 ms 41.278 ms 4 sl-ana-1-H2/0-T3.sprintlink.net (144.228.10.30) 71.023 ms 64.961 ms 63.816 ms 5 sl-ana-2-F0/0.sprintlink.net (144.228.70.2) 67.1 ms 63.442 ms 64.288 ms 6 sl-stk-6-H2/0-T3.sprintlink.net (144.228.10.25) 76.548 ms 72.84 ms 73.785 ms 7 sl-mae-w-H1/0-T3.sprintlink.net (144.228.10.46) 79.905 ms 75.496 ms 74.788 ms 8 mae-west.SanFrancisco.mci.net (198.32.136.12) 89.111 ms 87.641 ms 217.096 ms 9 t3-0.enss144.t3.nsf.net (192.203.230.253) 107.938 ms 95.99 ms 96.662 ms 10 t3-3.cnss8.San-Francisco.t3.ans.net (140.222.8.4) 99.96 ms 95.953 ms 109.311 ms 11 t3-1.cnss88.Seattle.t3.ans.net (140.222.88.2) 112.245 ms 113.35 ms 111.012 ms 12 cnss93.Seattle.t3.ans.net (140.222.88.197) 127.135 ms 114.558 ms 114.102 ms 13 192.103.70.62 (192.103.70.62) 118.403 ms 122.704 ms 122.746 ms 14 192.197.172.25 (192.197.172.25) 141.079 ms 135.193 ms 130.761 ms 15 206.12.117.98 (206.12.117.98) 227.997 ms 144.418 ms 133.641 ms 16 206.12.117.98 (206.12.117.98) 129.806 ms !H !H [ok] : chops.icp.net-MHRC ; traceroute 206.12.154.1 traceroute to 206.12.154.1 (206.12.154.1), 30 hops max, 40 byte packets 1 sl-hrn-1-E5.sprintlink.net (199.0.55.1) 4.548 ms 3.199 ms 4.35 ms 2 sl-fw-8-S3/0-T1.sprintlink.net (144.228.38.61) 41.879 ms 40.927 ms 41.546 ms 3 sl-fw-6-F0/0.sprintlink.net (144.228.30.6) 46.436 ms 41.338 ms 40.558 ms 4 sl-ana-1-H2/0-T3.sprintlink.net (144.228.10.30) 66.792 ms 64.395 ms 63.976 ms 5 sl-ana-2-F0/0.sprintlink.net (144.228.70.2) 66.02 ms 63.443 ms 64.024 ms 6 sl-stk-6-H2/0-T3.sprintlink.net (144.228.10.25) 75.06 ms 74.22 ms 71.917 ms 7 sl-mae-w-H1/0-T3.sprintlink.net (144.228.10.46) 77.256 ms 76.258 ms 74.408 ms 8 mae-west.SanFrancisco.mci.net (198.32.136.12) 88.265 ms 86.16 ms 85.054 ms 9 border2-hssi2-0.SanFrancisco.mci.net (204.70.33.13) 86.393 ms 87.029 ms 84.88 ms 10 borderx2-fddi0-0.SanFrancisco.mci.net (204.70.3.164) 87.03 ms 84.509 ms 87.846 ms 11 core2-fddi-1.SanFrancisco.mci.net (204.70.158.65) 86.86 ms 87.3 ms 85.111 ms 12 core1-hssi-2.Sacramento.mci.net (204.70.1.146) 89.264 ms 86.404 ms 87.708 ms 13 core-hssi-3.Seattle.mci.net (204.70.1.150) 98.816 ms 90.917 ms 92.826 ms 14 border2-fddi-0.Seattle.mci.net (204.70.3.146) 92.045 ms * * 15 fonorola-internet.Seattle.mci.net (204.70.53.22) 103.243 ms 96.078 ms 104.548 ms 16 IceOnline-GW.vancouver.fONOROLA.net (198.53.80.250) 102.898 ms 103.595 ms 109.361 ms 17 router.iceonline.com (204.191.208.2) 104.766 ms 114.713 ms 107.489 ms 18 cisco.iceonline.com (204.191.208.1) 101.188 ms 102.015 ms 104.648 ms 19 router.iceonline.com (204.191.208.2) 120.781 ms 106.341 ms 102.491 ms 20 cisco.iceonline.com (204.191.208.1) 114.748 ms * 104.974 ms 21 router.iceonline.com (204.191.208.2) 112.519 ms 107.59 ms 110.332 ms [again, not really aimed at anything] SL-CHI-6>trace 206.12.229.1 Type escape sequence to abort. Tracing the route to 206.12.229.1 1 sl-chi-nap-H1/0-T3.sprintlink.net (144.228.56.10) 4 msec 0 msec 0 msec 2 aads-F.mci.net (198.32.130.227) [AS 3561] 28 msec 28 msec 28 msec 3 border2-hssi1-0.Chicago.mci.net (204.70.25.5) [AS 3561] 28 msec 76 msec 212 msec 4 core-fddi-1.Chicago.mci.net (204.70.3.81) [AS 3561] 28 msec 28 msec 24 msec 5 core1-hssi-2.NorthRoyalton.mci.net (204.70.1.94) [AS 3561] 28 msec 28 msec 28 msec 6 core1-hssi-3.WestOrange.mci.net (204.70.1.102) [AS 3561] 28 msec 28 msec 28 msec 7 204.70.1.97 [AS 3561] 28 msec 28 msec 28 msec 8 border2-fddi-0.NewYork.mci.net (204.70.3.18) [AS 3561] 24 msec 28 msec 28 msec 9 sprint-nap.NewYork.mci.net (204.70.45.6) [AS 3561] 64 msec 28 msec 28 msec 10 fd-0.enss218.t3.ans.net (192.157.69.4) 28 msec 24 msec 28 msec 11 t3-3.cnss32.New-York.t3.ans.net (140.222.32.4) [AS 690] 32 msec 32 msec 32 msec 12 t3-0.cnss48.Hartford.t3.ans.net (140.222.48.1) [AS 690] 40 msec 36 msec 40 msec 13 t3-2.cnss43.Cleveland.t3.ans.net (140.222.43.3) [AS 690] 52 msec 52 msec 48 msec 14 t3-1.cnss27.Chicago.t3.ans.net (140.222.27.3) [AS 690] 60 msec 56 msec 56 msec 15 t3-1.cnss96.Denver.t3.ans.net (140.222.96.2) [AS 690] 84 msec 84 msec 84 msec 16 t3-0.cnss88.Seattle.t3.ans.net (140.222.88.1) [AS 690] 100 msec 100 msec 100 msec 17 cnss93.Seattle.t3.ans.net (140.222.88.197) [AS 690] 100 msec 100 msec 96 msec 18 192.103.70.62 [AS 1331] 148 msec 308 msec 152 msec 19 192.197.172.2 [AS 1691] 176 msec 152 msec 128 msec 20 192.197.174.34 [AS 577] 128 msec 120 msec 164 msec 21 pme0.awinc.com (199.175.168.240) [AS 1691] 128 msec 196 msec 184 msec 22 pmeMsync.awinc.com (199.175.169.150) [AS 1691] 240 msec 264 msec 256 msec 23 * * * 24 * * * [thud]

3 2

Re: Request for Comments on a topological address block for N. Calif.
by Scott Bradner 24 Sep '95

24 Sep '95

George, > Some sort of nominal fee on the order of $1 to $2.50 per /24 equiv Why would the fee be based on the size of a prefix? Is there a difference in the work required to support a /24 and a /23? It would seem to me that: 1/ the cost per prefix for processing etc should be independent of prefix length (mostly, the reverse table could have some length dependent parts) 2/ thus charging on prefix length is social engineering Is it your intention that the Internet addressing cost structure be based on social engineering to try and ensure the most efficient use of address space (or some other reason)? Scott

2 1

Re: 206.82.160.0/22
by John Riordan 24 Sep '95

24 Sep '95

> Sprint wanted nothing to do with it, and referred to the Internic. > I specifically requested this allocation (for a mere /20 to satisfy the > slow-start policy) as permanent, not as a recyclable temporary assignment. > Everything I ever tried...and non-cooperation out of political motives For what it is worth... I must say I sympathize with Kai. While it looks like our clients may come out ok in all this (I hope), we have had similar problems trying to grow and operate as a small niche provider. It all seems to stem from the understandable fact that the larger providers are trying to look out for the interests of Internet as a whole as well as themselves. If the small niche providers suffer it may, or may not, be a small price to pay. However, I feel (granted I'm biased) that a competitive market place which allows small niche providers to compete will benefit the Internet in the long run. Before I launch into my story I just want to say that while I welcome sympathy for our predicament, I'm not particularly looking for it in this case. We knew full well that the allocations we received from the Internic may not be usable going forward, strange as that notion may seem to those receiving them. We felt it was still the best route to go. A few months ago we went looking for a /18 from the Internic for reassignment to our clients. After about a month of discussion with the Internic, we were unequivocally told we had to make due with a /19. A /19 was all we could justify, and we do understand the need for such justifications - we needed to show that we could make good use of the /19 before they would consider talking with us further on the issue. Furthermore, we had to make a decision or stop taking on new customers at that point, so we took the /19 from the Internic and went ahead with business. We went to the Internic looking for an /18 allocation instead of Sprint or MCI for a handfull of reasons, including: 1) Sprint and MCI (our two providers) were unwilling to provide us with a portable allocation. We do understand the rational behind this - we don't provide portable allocations to our clients either. However, we didn't want to be locked into a supplier - our clients would never understand being told they need to renumber if we ever did away with, or replaced, one of our suppliers. Furthermore we don't want to go punching holes in the large providers aggregations for, what I think, are obvious reasons. 2) While we could only justify a /19, we were rather worried about what was going to happen with the /19's. We were well aware of Sean's opinions on filtering at the /18 and /19 level and his influence in issues such as this. He has the power to affect change in a way few others do. However, based on what we knew from forums like this and talking with people at Merit and elsewhere, we felt that it was likely that the /19's would go unfiltered so we took the risk. 3) Being multi-homed, it seemed to make sense to announce an independent address blocks so as to avoid whatever complications that might arise in the future from the announcing of address blocks belonging to one provider into another provider at our level. So now Sprint went ahead and filtered our /19 as they hear it from MCI. They also hear it from us, so except for our loss of a backup route to Sprint through MCI, we are ok. It looks like Sean will make, if he has not already, an exception in our case - I hope all this doesn't change his mind. I'm not so sure he will make exception in Kai's case or other people in similar situtations. However, if the other major providers follow suit on filtering the /19s on an incoming basis (outgoing filtering I don't have an issue with), we will have a good bit of damage control to do - some warning would have been nice. If we were not Sprint clients, Sprint's action would have had a serious impact on our business, of course arguably our own fault. Going forward, my concern arises because it is not clear to me how a policy which only enables organizations able to justify /18 portable independent allocations for reassignment (at the moment I don't believe you can even buy your way into such an assignment) will provide a competitive environment which includes small niche providers. I don't think an environment which locks small players into a supplier is competitive from anyones vantage point. Maybe I'm missing something, maybe all this is being taken care of as I write this (I did see some good suggestions floating around), or maybe the Internet would be better off without all the small niche providers. My hope is that those parties who do influence policy creation will leave room for small niche players players to compete when they do come to agreement on this and future issues. Also I hope that those same parties are cognizant of the fact that actions they take to further their goals can have a serious impact the small players out there. All this being a case in point. While a little bit of incoming filtering by Sprint may have next to no impact on the ability of Sprint to do business, it could devastate a small niche provider someplace who has to say to their clients, "Sorry, we are only able to provide you with partial Internet service at the moment because Sprint doesn't like the addresses we assigned you". Now that I've had my say, I'm going back to the sideline. John Riordan Vice President Interport Communications Corp. 1133 Broadway New York, NY 10010 212-989-1128

2 1

Re: 206.82.160.0/22
by Sean Doran 24 Sep '95

24 Sep '95

John - Like many others here and in private email, you make excellent points, and were influential in helping move towards allowing /19s in 206/8 on the grounds that many people honestly (mis-)understood comments about indecision with respect to /19s vs /18s and noises about possibly re-evaluating things in the future to be a guarantee of routability of /19s in the 206/8 range. I also agree with your points that encouraging the growth in the number of providers, particularly small providers, is very important to the evolution of the ubiquitous Internet, and that anything that holds back the growth of the number of small and mid-size providers should be avoided. Unfortunately, I don't think that we can adopt a policy of "should be avoided at all costs", because one such cost is having large segments of the Internet stop working. Consequently, there are a number of people at work on preventing further increases in the size of routing tables. While I do agree with Dave Crocker et al. that strict nonportable address allocation does make it difficult for small and mid-size providers to change connectivity to some degree, I believe that for the moment this is unavoidable, no matter that I wish that it was, or that I could put some of my efforts off any longer than I already have. However, with respect to the difficulties that inflexible minimum sizes on portable allocations (i.e., those that are likely to be routable throughout the entire Internet) and limits on routability of long prefixes, most things would be made much easier on small and mid-size providers if sufficiently good renumbering technology existed for small-i internets. Therefore I make the economic argument to workstation, operating-system and router vendors that it is in their interests to develop easy-to-use or (semi-) automatic renumbering tools for all their products, and to participate in the development of protocols that allow these tools to cooperate in the process of renumbering even sizeable small-i internets. I assert (wearing a price-theorist's hat) that such a technology will lower the costs of providing big-I Internet services significantly, and that this cost-savings will allow for a reduction in pricing due to competitive pressures, and, caeteris paribus, will lead to further growth of the Internet and consequently more sales of "Internet-ready" workstations, operating-systems, and routers. Sean. - -- Sean Doran <smd(a)sprint.net>

2 1

multicast and smd's brain-damage
by Sean Doran 23 Sep '95

23 Sep '95

Urgh, I was just reminded of my ongoing and seemingly incurable brain-damage concerning 224/8 - 239/8... I'm grateful to the person who pointed this out with: "... And God help any of them who are expecting to announce anything between 224/8 and 239/8." Sean.

1 0

access-list 112
by Sean Doran 23 Sep '95

23 Sep '95

This is probably ugly and difficult to read. It also can be trimmed, but has been left overly-long and overly-paranoid for readability when using "show access-list 112" and because the IOS 10.3 distribute-list caching doesn't seem to mind the extra deny clauses all that much. Sean. - -- ! list 112 - deny more specifics of some prefixes ! ! IMPORTANT-TO-REMEMBER SYNTAX FOR BGP distribute-list! ! access-list <#> <permit|deny> ip <prefix> <don't care bits> <mask> <don't care bits> ! ! clear old list ! no access-list 112 ! ! this was originally ordered A, B, C and side-effects, but ! what we really want to do is put the permit clauses up front ! starting with the swamp, as this will match the most prefixes ! !!!!! START ! !!!! PERMITs ! !!! C space !! permit /24s in 192/8-205/8. ! (192==1100 0000, 205==1100 1101) ! ! allow M =< /24 in 1100 xx0x * ! (allow mask bits in first three octets) ! 1100xx0x == {192,193,196,197,200,201,204,205} ! access-list 112 permit ip 192.0.0.0 13.255.255.255 0.0.0.0 255.255.255.0 ! ! ! allow M =< /24 in 1100 {0010,0011,0110,0111,1010,1011} ! (which really means 1100 {001x,011x,101x}, ! which in turn is really 1110 {x01x,011x}} ! 1100x01x == {194,195,202,203} ! 1100011x == {198,199} ! access-list 112 permit ip 194.0.0.0 9.255.255.255 0.0.0.0 255.255.255.0 access-list 112 permit ip 198.0.0.0 1.255.255.255 0.0.0.0 255.255.255.0 ! ! !! hack - allow M =< /19 in 206/8 ! access-list 112 permit ip 206.0.0.0 0.255.255.255 0.0.0.0 255.255.224.0 ! ! allow M =< /18 in 206/8-239/8 (1100 111x *, 1110 xxxx *) ! (allow mask bits in first 18 bits) ! 1100111x == {206,207} ! 1110xxxx == {208-239} ! access-list 112 permit ip 206.0.0.0 1.255.255.255 0.0.0.0 255.255.192.0 access-list 112 permit ip 239.0.0.0 15.255.255.255 0.0.0.0 255.255.192.0 ! ! !!! B space !! permit /16s in old B-space ! 10xx xxxx * ! (we don't care what bits are in the first two octets ! of the mask; the second two octets must be 0) ! access-list 112 permit ip 128.0.0.0 63.255.255.255 0.0.0.0 255.255.0.0 ! ! !!! A space !! permit /8s and shorter prefixes in old A-space ! 0xxx xxxx * would be simple but unsafe from 0/8 POV, so ! we make sure that there is at least one 1 bit in the first ! octet's last seven bits, and that the first bit is 0; ! we don't care what bits are set in the mask, because ! we assume IOS won't present us with a prefix with ! bits set in the prefix's first octet but not in the mask, ! unless it's a long mask... ! ! 126=01111110 (IOW, CddddddC C==CARE, d=don't care) ! 125=01111101 ! ... ! 95=01011111 ! 63=00111111 ! access-list 112 permit ip 1.0.0.0 126.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 2.0.0.0 125.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 4.0.0.0 123.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 8.0.0.0 119.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 16.0.0.0 111.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 32.0.0.0 95.0.0.0 0.0.0.0 255.0.0.0 access-list 112 permit ip 64.0.0.0 63.0.0.0 0.0.0.0 255.0.0.0 ! ! !! permit 9.20.0.0/18 and 9.2/16 by exact match ! (both IBM early birds wrt subnets of As) ! access-list 112 permit ip 9.2.0.0 0.0.255.255 255.255.0.0 0.0.0.0 access-list 112 permit ip 9.20.0.0 0.0.255.255 255.255.192.0 0.0.0.0 ! !! permit exp39 /24s and shorter prefixes only ! (no ones set in the fourth octet) ! access-list 112 permit ip 39.0.0.0 0.255.255.255 0.0.0.0 255.255.255.0 ! ! !!!! DENYs ! ! This is super paranoia. At this point we have permitted ! all valid unicast prefixes and masks. ! In theory, we could end right here with a ! ! access-list 112 deny ip any any ! ! but this section below offers some degree of clarity ! policy-wise... (at least to me, but I'm weird -- smd) ! ! we also could have done a quick deny after each permit ! to catch any prefixes which didn't pass the permit filters, ! however, as noted below, I am superparanoid about ! funny, noncontiguous masks and other weirdnesses, and ! would like to be able to see them being caught, if ! they ever get as far as the access-list. ! !!! A space !! deny 0/(9-15) - 127/(9-15) ! deny subnets in old-style class A space, first octet ! (if any bit set in bit 8-15 (second octet), deny) ! ! this is a paranoid way of writing this out; ! less paranoia would let us write: ! ! ... deny ip 0.0.0.0 127.0.0.0 0.0.0.0 255.128.0.0 ! ! because we believe in contiguous netmasks; so we would ! never have a /18 if we block /17. ! ! However, better safe than sorry... ? ! ! 0xxx xxxx * ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.128.0.0 255.127.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.64.0.0 255.191.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.32.0.0 255.223.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.16.0.0 255.239.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.8.0.0 255.247.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.4.0.0 255.251.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.2.0.0 255.253.255.255 access-list 112 deny ip 0.0.0.0 127.255.255.255 0.1.0.0 255.254.255.255 ! !!! B space !! deny 0-127/16, 0-(17-23) - 191/(17-23) ! deny subnets in old-style class-B space ! and second octet of class A space. ! (first two bits will be 00 or 10; so x0xx xxxx; 191==10111111) ! (if any bit set in 16-23, deny) ! we also need to zap 0xxx xxxx * /16 ! access-list 112 deny ip 0.0.0.0 127.255.255.255 0.0.0.0 255.255.0.0 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.128.0 255.255.127.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.64.0 255.255.191.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 0.0.0.0 191.255.255.255 0.0.1.0 255.255.254.255 ! ! !!! C space !! deny 206/(19-23) - 239/(19-23) ! block prefixes longer than /18 in 207/8-239/8 ! no < /18 in 1100 1110 *, 1100 1111 *, 1110 xxxx * ! ! we block all M => /24 below and we did /17-/23 for 0/8-191/8 above, ! so we only need to worry about 19-23 for 207/8-239/8 ! ! first, in 1100 111x (206/8, 207/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 206.0.0.0 1.255.255.255 0.0.1.0 255.255.254.255 ! ! next in 1101 xxxx (208/8-239/8) ! (if mask has 1 bits in third octet (bits 18-23), deny) ! access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.32.0 255.255.223.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.16.0 255.255.239.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.8.0 255.255.247.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.4.0 255.255.251.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.2.0 255.255.253.255 access-list 112 deny ip 239.0.0.0 15.255.255.255 0.0.1.0 255.255.254.255 ! !!! all UNICAST space !! deny ANY/24, ANY/(25-32) ! now we block the final octet for 0/8-239/8 ! (because we specifically allowed /24s in 192/8-205/8, we can ! just block everything in xxxx xxxx * that has any 1 bits in 4th octet) ! access-list 112 deny ip 0.0.0.0 255.255.255.255 255.255.255.0 0.0.0.0 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.128 255.255.255.127 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.64 255.255.255.191 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.32 255.255.255.223 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.16 255.255.255.239 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.8 255.255.255.247 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.4 255.255.255.251 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.2 255.255.255.253 access-list 112 deny ip 0.0.0.0 255.255.255.255 0.0.0.1 255.255.255.252 ! !!! all IP space !! deny 240/(4-32), 0/(8-32) ! finally, we get rid of any announcements that are bogons ! 240/8-255/8 and 0/8 ! 1111 xxxx * and 0000 0000 * (any mask) ! we can leave this last as it's likely almost never to happen ! access-list 112 deny ip 255.0.0.0 15.255.255.255 0.0.0.0 255.255.255.255 access-list 112 deny ip 0.0.0.0 0.255.255.255 0.0.0.0 255.255.255.255 ! !!!!! END end

1 0