- Test - lists.nanog.org

Re: 204.82.160.0/22 invisible
by Kai 25 Sep '95

25 Sep '95

>Kai, it looks like Sprint is announcing this route. If you are a Sprint >customer, I don't recall Sprint saying anything about filtering its own >advertisements, either on NANOG or CIDRD. >Also, this is a typo, and it should be 206.82.160/22, no? Sean didn't say >anything about filtering 204/N either. >-dorian Correct. I have other networks in 204, so above was a typo. Also correct: he (rather cryptically) said Sprint wouldn't filter outgoing (hence customer-owned) routes, but he encouraged OTHER providers to do it like Sprint: filter incoming routes by the rules anounced: this has the same effect, but now Sean could point at Digex (should they employ such a filter) "I didn't do it, man!"... This was not the right way to enforce the relevant RFCs, what's an RFC worth that even the Internic doesn't obey ? And , I beg everyone's pardon: I have only read the NANOG list for a few weeks now, could not make it to nearby Pittsburgh,PA (did this topic surface?) due to work pertinent to just this event, but I NEVER heard of this imminent route prefix filtering until now. Given the anti-trust questions this entire issue raises, I don't see a very bright future for the landscape of network operators at this time: If you are small, you can only get a small network assignment (slow start), as you will be running into the Great Wall "Internic" even with a request for a /22, and if you really succeed with your /22 or /20 assignment, you will have to discover that the conspiracy of the big 6 (laugh!) might have decided you are not worthy, and to go route what you got to yourself and don't expect them even wanting to know about it. If, on the other hand, you bravely get your network assignment from your friendly network provider, once you change this very provider, you are told you can't take the networks you got with you to the new provider, or in the event you are going multi-home (foreseeable for MANY larger Web/Slip/PPP-outfits in the next 6-9 months), you aren't allowed (or outright can't) announce those networks via the additional connection, too. I remember a time when 800 numbers belonged to the LD carriers, who had ranges of them assigned/reserved with the "800 number authority" , BellCore. What's left of those ? The lawyers came, technology came, and swept these anti-competitive practises away, and given the changes in switching/routing of telephony switches that were required to allow 800-number portability, I stop to see the 'impossibilitee' of getting just the same together for IP networks. Either we change, or the lawyers will change us, and I feel there is no longer a choice. Changing your network provider with all your attached networks shall be no less painful then changing the LD carrier on your residential telephone line, and this is exactly what even small/mid-sized (16-64 class-C net-strong) providers want. The steps we see now, are exactly the opposite of this (we won't see nice auto-configuring IPv6 networks for years!), which is deeply troubling to anyone who has ever read anti-trust decisions. If it takes a first stone to be thrown, or a walk with the iron cross, count me in, for the better of us all. --- Kai Schlichting Internet Project Manager, BelCom, Inc. 515 Madison Ave Suite 2100 NY,NY 10022 212-705-9500 (voice) 212-755-0864 (fax) kai(a)belcom.net Ask us about Internet service in the CIS! Bringing Internet, where there is none

1 0

206.40.160.0/20
by Scott Mace 25 Sep '95

25 Sep '95

A customer of ours 206.40.160.0/20 has been hit by the sprintlink filtering. This is just a datapoint. Scott

2 1

204.82.160.0/22 invisible (fwd)
by Alan Hannan 25 Sep '95

25 Sep '95

Sean: As we start to see the (alleged) practical effects of Sprint's filtering, Sean, could you please bring us up to speed in a concise description of the policy changes and their potential ramifications. As well, perhaps a short description of how to "come into compliance" would eliminate threats of the following nature. Thanks! -- Alan Hannan Email: alan(a)mid.net Network Systems Administrator Voice: (402) 472-0239 MIDnet, Lincoln NOC Office Fax: (402) 472-0240 "The only way to make a man trustworthy is to trust him" - Henry Stimson <include previous letter from kai(a)belcom.net> ......... Kai is rumored to have said: ] From: Kai <kai(a)belcom.net> ] To: baldwin(a)SDD.COMSAT.COM, insc(a)sprintlink.net, noc(a)digex.net ] Subject: 204.82.160.0/22 invisible ] Cc: avg(a)sprintlink.net, bertolini(a)computel.com, concaj(a)belcom.net, ] donagm(a)belcom.net, ilya(a)phri.nyu.edu, kai(a)belcom.net, ken(a)belcom.net, ] khalfk(a)belcom.net, ladycom(a)computel.com, nanog(a)MERIT.EDU, smd(a)icp.net, ] smd(a)sprint.net, susan.evans(a)SPRINT.SPRINT.COM ] ] My network assignment 204.82.160.0/22 (Sprint-announced) has become invisible ] to all Digex-connected networks, while my old assignment (204.97.218/219) ] is still seen normally. ] Following the NANOG list, I must suspect this is due to the route prefix ] filtering Sean Doran announced, and which seems to have gone into effect. ] As Comsat (a Digex client) can now no longer reach BelCom's overseas ] subsidaries (BelCom is a Computel client, client of Sprint: Computel is ] technically incapable of handling or comprehending this issue, you will ] have to deal with me). ] I demand that this route prefix filtering is turned off immediately: ] The Almaty NATO networking conference is IN SESSION (trace to 206.82.161.1 ] if you can ), and I was absolutely positive about the consequences this ] will have on the relationship between BelCom and Arna-Sprint in Kazakhstan. ] If you want to avoid a press release at the conference detailing names and ] circumstances of this engineering terrorism, you should turn off the route ] prefix filter THIS MINUTE. There was absolutely no humanly sane reason to ] 'pull the plug' on a Sprint customer like this, and to sabotage an event ] that has cost us $50,000 plus 200 engineering hours to make happen. ] This is off to the lawyers. ] ] --- ] Kai Schlichting ] Internet Project Manager, BelCom, Inc. ] 515 Madison Ave Suite 2100 ] NY,NY 10022 ] 212-705-9500 (voice) ] 212-755-0864 (fax) ] kai(a)belcom.net ] Ask us about Internet service in the CIS! ] Bringing Internet, where there is none ] ] ] <end include of previous letter from kai(a)belcom.net>

1 0

204.82.160.0/22 invisible
by Kai 25 Sep '95

25 Sep '95

My network assignment 204.82.160.0/22 (Sprint-announced) has become invisible to all Digex-connected networks, while my old assignment (204.97.218/219) is still seen normally. Following the NANOG list, I must suspect this is due to the route prefix filtering Sean Doran announced, and which seems to have gone into effect. As Comsat (a Digex client) can now no longer reach BelCom's overseas subsidaries (BelCom is a Computel client, client of Sprint: Computel is technically incapable of handling or comprehending this issue, you will have to deal with me). I demand that this route prefix filtering is turned off immediately: The Almaty NATO networking conference is IN SESSION (trace to 206.82.161.1 if you can ), and I was absolutely positive about the consequences this will have on the relationship between BelCom and Arna-Sprint in Kazakhstan. If you want to avoid a press release at the conference detailing names and circumstances of this engineering terrorism, you should turn off the route prefix filter THIS MINUTE. There was absolutely no humanly sane reason to 'pull the plug' on a Sprint customer like this, and to sabotage an event that has cost us $50,000 plus 200 engineering hours to make happen. This is off to the lawyers. --- Kai Schlichting Internet Project Manager, BelCom, Inc. 515 Madison Ave Suite 2100 NY,NY 10022 212-705-9500 (voice) 212-755-0864 (fax) kai(a)belcom.net Ask us about Internet service in the CIS! Bringing Internet, where there is none

1 0

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