- NANOG - lists.nanog.org

Re: 10.0.0
by Tony Li 31 May '97

31 May '97

doshea(a)mail.wiltel.net (Dave O'Shea) writes: > >> The only services that should be affected by the use of such "bogus" > >> addresses will be traceroute and any routing information passed by the > >> device. > > > >Unfortunately that's not quite true. > > > >There are a variety of services which rely on messages received from > >intermediate hops that would break if the the sending host happened > >to filter out RFC1918 addresses and a part of the network > >were using them. > > > >Probably the best example is Path MTU Discovery. > > I meant "services used by normal humans in the course of downloading nude > .gif's", i.e., typical Internet customers. I stand by my statement. :-) As the "normal human in the course of downloading nude .gif's" should be using Path MTU Discovery, I think you're agreeing.... Tony p.s. .gif's are obsolete. Most everything is .jpg's, .mpg's, and .avi now. ;-)

1 0

NANOG Mailing List
by William B. Norton 31 May '97

31 May '97

Hello - I would like to ask that we all take a deep breath and refrain from the attacks, retaliations from attacks, and the subsequent comments on the attacks. This will not likely lead to anything good. It seems to me that we have an issue about the appropriate use of the NANOG mailing list forum. I would like to suggest that during the open session Friday afternoon we spawn a small group to draft a nanog mailing list AUP, and perhaps draft a charter for a couple of new nanog-XXX lists. We can then post the document to the nanog list(s) and implement the policy. Bill -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 764-9430

2 1

Re: 10.0.0
by Dave O'Shea 31 May '97

31 May '97

>> The only services that should be affected by the use of such "bogus" >> addresses will be traceroute and any routing information passed by the >> device. > >Unfortunately that's not quite true. > >There are a variety of services which rely on messages received from >intermediate hops that would break if the the sending host happened >to filter out RFC1918 addresses and a part of the network >were using them. > >Probably the best example is Path MTU Discovery. I meant "services used by normal humans in the course of downloading nude .gif's", i.e., typical Internet customers. I stand by my statement. :-)

1 0

Re: 10.0.0
by Dave O'Shea 31 May '97

31 May '97

I've noted several providers, including a couple of better-known ones, using RFC1597 addresses internally. While not a Really Optimal Solution, it does work, and if you find yourself with only a couple of class C's to work with.. I'd probably rather preserve them for my customers, and go with whatever I had to internally, as long as packets still got from A to B. The only services that should be affected by the use of such "bogus" addresses will be traceroute and any routing information passed by the device. Much more interesting is when you have to connect to several different customers, many of whom have chosen 10/8, 172.16/16, or 192.168.1/24 as their core network addresses. Looks like Sierra is a customer of Phoenix Fiberlink, who is likely dual-homed, since he's got a Sprint netblock transiting UUnet. Hope that helps. ---------- > From: Janet Pippin <jdp(a)cyberramp.net> > To: nanog(a)merit.edu > Cc: Larry Rosenman-CyberRamp System Administration <ler(a)cyberramp.net> > Subject: 10.0.0 > Date: Friday, May 30, 1997 10:53 PM > > ALL: > Upon trying to discover an abuse site's network location, I > happened upon this: > > Now, first it goes to sierra.. Then right after the trace finishes, > I ran the second one.. > > traceroute to ns1.sierra.net (207.135.224.247), 30 hops max, 40 byte packets > 1 cisco.cyberramp.net (207.158.64.1) 2 ms 1 ms 1 ms > 2 166.48.80.9 (166.48.80.9) 6 ms 8 ms 13 ms > 3 core3.Dallas.mci.net (204.70.4.13) 5 ms 7 ms 16 ms > 4 uunet-hssi.Dallas.mci.net (206.157.77.130) 26 ms 7 ms 56 ms > 5 Fddi0-0.CR1.DFW1.Alter.Net (137.39.37.35) 103 ms 13 ms 15 ms > 6 108.Hssi5-0.CR1.SFO1.Alter.Net (137.39.70.221) 135 ms 312 ms 348 ms > 7 133.Hssi4-0.GW1.SLT1.Alter.Net (137.39.68.10) 104 ms 121 ms 122 ms > 8 pfi-gw.customer.ALTER.NET (137.39.167.18) 108 ms 171 ms 106 ms > 9 207.49.13.50 (207.49.13.50) 114 ms 117 ms 112 ms > 10 207.14.235.22 (207.14.235.22) 112 ms 116 ms 113 ms > 11 10.0.0.2 (10.0.0.2) 116 ms 108 ms 114 ms > 12 rock.sierra.net (207.135.224.247) 116 ms 112 ms 113 ms > > jdp@mailhost 18 ~ > wi 10.0.0 > IANA (RESERVED-6) > > Netname: RESERVED-10 > Netnumber: 10.0.0.0 > > hrmm... and the second one: > > jdp@mailhost 17 ~ > t ns1.sierra.net > traceroute to ns1.sierra.net (198.60.22.2), 30 hops max, 40 byte packets > 1 cisco.cyberramp.net (207.158.64.1) 2 ms 1 ms 1 ms > 2 166.48.80.9 (166.48.80.9) 29 ms * 5 ms > 3 bordercore1-loopback.Denver.mci.net (166.48.92.1) 210 ms 252 ms 281 ms > 4 electric-light.Denver.mci.net (166.48.93.254) 274 ms 273 ms 260 ms > 5 F0-0.slkcib01.eli.net (207.0.56.18) 59 ms 59 ms 62 ms > 6 XMISSION-DOM.slkcib01.eli.net (207.49.20.86) 64 ms 67 ms 69 ms > 7 xmission.xmission.com (198.60.22.2) 60 ms * 88 ms > jdp@mailhost 18 ~ > > > enlighten me, someone... :( > > -janet > > > Janet Pippin * CyberRamp Internet Services > Network Administrator *** 11350 Hillguard Road > jdp(a)cyberramp.net * Dallas, Texas 75243-8311 > http://www.cyberramp.net * (214) 340-2020 (817) 226-2020

4 3

Remote power management
by Rodney Joffe 31 May '97

31 May '97

Two months ago I asked for some suggestions for remote out-of-band capable power management equipment, capable of dealing with 20amp circuits etc. A number of people made suggestions, but even more asked me to let them know what the final analysis showed. Short answer: Server Technologies came out the best. If you'd like more details, feel free to email me. Thanks for your help. Rodney Joffe Genuity Inc., a Bechtel company http://www.genuity.net

4 3

10.0.0
by Janet Pippin 31 May '97

31 May '97

ALL: Upon trying to discover an abuse site's network location, I happened upon this: Now, first it goes to sierra.. Then right after the trace finishes, I ran the second one.. traceroute to ns1.sierra.net (207.135.224.247), 30 hops max, 40 byte packets 1 cisco.cyberramp.net (207.158.64.1) 2 ms 1 ms 1 ms 2 166.48.80.9 (166.48.80.9) 6 ms 8 ms 13 ms 3 core3.Dallas.mci.net (204.70.4.13) 5 ms 7 ms 16 ms 4 uunet-hssi.Dallas.mci.net (206.157.77.130) 26 ms 7 ms 56 ms 5 Fddi0-0.CR1.DFW1.Alter.Net (137.39.37.35) 103 ms 13 ms 15 ms 6 108.Hssi5-0.CR1.SFO1.Alter.Net (137.39.70.221) 135 ms 312 ms 348 ms 7 133.Hssi4-0.GW1.SLT1.Alter.Net (137.39.68.10) 104 ms 121 ms 122 ms 8 pfi-gw.customer.ALTER.NET (137.39.167.18) 108 ms 171 ms 106 ms 9 207.49.13.50 (207.49.13.50) 114 ms 117 ms 112 ms 10 207.14.235.22 (207.14.235.22) 112 ms 116 ms 113 ms 11 10.0.0.2 (10.0.0.2) 116 ms 108 ms 114 ms 12 rock.sierra.net (207.135.224.247) 116 ms 112 ms 113 ms jdp@mailhost 18 ~ > wi 10.0.0 IANA (RESERVED-6) Netname: RESERVED-10 Netnumber: 10.0.0.0 hrmm... and the second one: jdp@mailhost 17 ~ > t ns1.sierra.net traceroute to ns1.sierra.net (198.60.22.2), 30 hops max, 40 byte packets 1 cisco.cyberramp.net (207.158.64.1) 2 ms 1 ms 1 ms 2 166.48.80.9 (166.48.80.9) 29 ms * 5 ms 3 bordercore1-loopback.Denver.mci.net (166.48.92.1) 210 ms 252 ms 281 ms 4 electric-light.Denver.mci.net (166.48.93.254) 274 ms 273 ms 260 ms 5 F0-0.slkcib01.eli.net (207.0.56.18) 59 ms 59 ms 62 ms 6 XMISSION-DOM.slkcib01.eli.net (207.49.20.86) 64 ms 67 ms 69 ms 7 xmission.xmission.com (198.60.22.2) 60 ms * 88 ms jdp@mailhost 18 ~ > enlighten me, someone... :( -janet Janet Pippin * CyberRamp Internet Services Network Administrator *** 11350 Hillguard Road jdp(a)cyberramp.net * Dallas, Texas 75243-8311 http://www.cyberramp.net * (214) 340-2020 (817) 226-2020

5 4

Local Peering Points
by bownes＠web9.com 31 May '97

31 May '97

I've been having an offline debate and wanted to take a quick lithmus test...Mostly aimed at the folks who don't currently peer at any of the 'nationally recognized peering points', but I'll take answers from anyone...Ya'll are always so short on opinions. :-} If someone presented you with the following options: 1) $X connect to a local peering point and peer with other local/regional ISPs (MLPA) You retain current transit. 2) $X+$Y connect to a local peering point and peer with other local/regional ISPs plus the host (a decent sized national carrier) You retain current transit. 3) $X+$Y+$Z Purchase transit from the host, not including access to the local peering points Would purchasing #3 prevent or discourage you from purchasing #1 and would purchasing #1 or #2 prevent or discourage you from purchasing #3? How do folks feel about the concept of local peering points? Comments, public or private, are, of course, welcome. bob iii (not speaking for anyone but myself, & certainly not my employer...)

3 2

nanog endorsements and nameservers outside the u.s. (was blah blah blah)
by Sean M. Doran 31 May '97

31 May '97

Sometimes I go reading through email with UCB Mail just to see what my Gnus 5.4.x (http://www.gnus.org/) splits and scorefiles are hiding from me, and to reassure myself that modern Gnus is so excellent a mail and news reader that it's worth using Emacs to enjoy it. (I heartily recommend the newsreader to anyone trying to follow anything on the NANOG mailing list, btw. The threading scheme is great -- You can type T l to lower the score of a thread and can do neat things like scoring down particular individuals (L A) and anything following up to them (L F), and all of this happens nice and quickly using the nnml mail backend, as it uses .overview files. I no longer see all sorts of crap. Gnus has changed my life.) Sometimes reading unfiltered email leads me into replying to something that ordinarily I would never have seen. This is one of those times. Bear in mind that this is being written with an American (or more generally North American) audience in mind. This should probably have gone to com-priv, but hopefully things will stay in a more north american engineering frame of mind than what is usually found there. Jim Fleming wrote: | 1. What is the official Root Name Server configuration | endorsed by NANOG ? NANOG does not endorse anything. This is a failing. Moreover, surely this would be something more appropriate for IEPG, for a more global perspective, rather than just focusing on one regional group of operators. | 3. How do you feel about moving the Root Name | Servers out of the United States ? Are you concerned | about the performance issues ? Having more root nameservers outside the USA is an excellent idea. There is nothing particularly new to this -- there has been a root nameserver at NORDUNET for some time. I trust that BIND will adapt to the vagaries of various network bottlenecks. Paul Vixie is a clever coder. Trans-oceanic botlenecks are a real issue, however, and with the current ICM award about to wind down, the question arises about who pays for poor connectivity to where. Assuming that capacity bottlenecks between North America and Asia becomes an operational issue to North American network operators (could be), they would obviously be able to adopt one of three approaches: -- hide head in sand, hope that other people (namely non-Americans) pick up the cost of the no-longer-subsidized U.S. half-circuits, and continue increasing their own capacity at their own cost. -- purchase their own connectivity to exchange points in Europe (such as KTH in Stockholm and LINX in London -- note that each of these two exchange points has a root nameserver in the same facility) -- cut a deal with someone like BT/MCI, UUNET or the like to use their trans-oceanic capacity The third approach is straightforward -- become a customer of a big global network and trust that customer and other market pressures will keep them expanding globally such that capacity issues don't become overwhelming. The second approach is straightforward too, and is I imagine what people clamouring for peerings at U.S.-based exhcange points so that they can be Independent Big Networks should begin planning for. That is, if you don't want to become a customer of, say, BT/MCI or UUNET or the like and you don't want to find yourself being able to reach fewer and fewer locations or more and more likely to face settlement charges from those big providers, acquiring independent capacity to remote exchange points is a good idea. Examining this a bit more closely, since undersea capacity is terribly expensive, when there is adequate capacity available to a large aggregate of sites people want to get to, there will be an obvious market for access to that capacity. As BT/MCI or UUNET or whoever increases the size of their pipes and aggregates more things behind those pipes, the ability to charge more on either end for transit through those pipes will increase. >From an American perspective, the simple way of looking at this is that as BT/MCI and UUNET increase the amount of transoceanic capacity, their networks become more valuable. This in turn will allow them to continue making a sensible argument for charging for peering that includes access to their non-local (i.e., non-American) customer base. Looking at it from a higher point of view, there is the problem of many geographically separated exchange points where a there are sets of providers who cannot talk to each other because there is no common exchange point. However, unlike in North America, the cost of even relatively small amounts of bandwidth is still very high for trans-oceanic capacity. This results in a market opportunity for people who can aggregate (and likely oversell) that expensive capacity to the disjoint sites. There is the issue of keeping customers happy, as has been mentioned, but salami tactics work nicely. In fact, when dealing with expensive transoceanic capacity, it works better, especially when customers are presented with the option of subsidizing (through increasing customer fees) their routes being presented to a small network in America who refuses to pay for their share of the transoceanic capacity. Finally, there's the third approach. It might be workable, but at some point Europeans and Asians will tire of always increasing the amount of money they put into transoceanic circuits and start becoming either customers of bigger, cheaper providers (or members of consortia or associations which accomplish similar cost-savings) or start coming to the same understanding: access to trans-oceanic capacity while it continues to be hiddeously expensive should be paid for at both ends, since both sides benefit. This has been seen to some degree in the past; there are a number of cases where a relatively unsaturated high bandwidth line was made available only conditionally -- one had to be a research network or had to be a friend of someone or other in order to use the big pipe otherwise one would use the much more saturated thinner pipes across the oceans. Seeing messages fly about saying, "Dear brand new AS 8888, if you pay us 200 ECU per month to cover our costs we will carry your routes across the nice fat pipe between our popular network and MAE-EAST, otherwise good luck finding acceptable (or any) transit bandwidth" (only more polite, of course) will not surprise me. So, the answer to the question is, yes, you should be concerned about performance issues, and yes, you should be working on a tractable scalable engineering plan for both North American and intercontinental connectivity, and this should take into account other people's real and perceived costs. In other words, kids, the increasing number of root nameservers outside the U.S.A. is a sign that the Internet is internationalizing. Engineer for that now, or you're probably in for a bumpy ride as various governments including your own stop subsidizing your connectivity elsewhere. Sean.

2 1

Re: [off-topic] old NSFNET regionals?
by Henry Clark 31 May '97

31 May '97

At 12:23 PM 5/29/97 -0400, Jamie Rishaw wrote: > OARNET Alison Brown, Michael Fidler, Jeff Grumpf Alison is happily retired. Mike is at MITRE. Jeff is at CWRU. Many of the folks previously working at OARnet have moved on to other opportunities. ... returning you to your previously scheduled urination games ... henry

1 0

A FINAL DNS PROPOSAL
by Matthew Pearson 31 May '97

31 May '97

I propose we do away with all name resolution and go back to running striaght IP addresses :) Hell.. its a better proposal than anyone else has come up with! Send all flames to dev(a)null.int

3 2