- Test - lists.nanog.org

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

RE: NANOG Meeting
by Jim Fleming 30 May '97

30 May '97

On Thursday, May 29, 1997 8:48 PM, Philip J. Nesser II[SMTP:pjnesser@martigny.ai.mit.edu] wrote: @ Jim Fleming supposedly said: @ > @ > Will the Root Name Server Confederations be @ > discussed at the upcoming NANOG meeting @ > where Michael Dillon is giving an ISP tutorial ? @ > @ > @@@@ http://www.nanog.org/mtg-9706/tutorial.html @ @ @ In a word: no @ @ (Of course there are many good laughs had by all when someone comes up with @ the latest joke) @ @ ----> Phil @ Since NANOG is promoting the education, hopefully people will be informed that Mr. Michael Dillon has strong views on some of the various leading edge movements on the Internet. He has also been one of the major advocates for the IAHC. The IAHC has not followed through with registries as promised and now we have brokers out there pre-registering people in Top Level Domains that do not exist and do not have TLD Name Servers. Mr. Michael Dillon has supported the actions of these brokers and claims they are providing a useful service. Does NANOG support that kind of activity ? ============================================================= Re: IANA/ISI/USC/UCLA (Was: Address Space) ------------------------------------------------------------------------ .To: inet-access(a)earth.com .Subject: Re: IANA/ISI/USC/UCLA (Was: Address Space) .From: Michael Dillon <michael(a)memra.com> .Date: Tue, 29 Apr 1997 17:41:29 -0700 (PDT) .In-Reply-To: <3.0.1.32.19970429170232.006af84c(a)jcnis.com> .List-Admin: inet-access-request(a)earth.com (subscribe/unsubscribe requests) .Organization: Memra Software Inc. - Internet consulting ------------------------------------------------------------------------ On Tue, 29 Apr 1997, Patrick Gilmore wrote: > Sorry if I took it too far. I was mostly concerned about your description of IANA because there are a number of people and organizations who are spreading misinformation and pure FUD about IANA in and attempt to get the U.S. government to usurp IANA's authority and enforce a restricted monopoly system of domain names. I personally am opposed to both the Internic/NSI schemes http://www.netsol.com/papers/internet.html and the eDNS schemes http://www.edns.net and the name.space schemes http://www.pgpmedia.com/ns./com/reg_noframe.html One strategy that these people are using is to claim that IANA does not really exist or to claim that IANA has no authority to do what it has done for many years or that someone else (DOD, USC, FNC, ...) really is in charge of the IANA. I know it can be hard to figure out what's really going on with so much FUD being distributed so I don't blame you for misunderstanding the relationships between USC and IANA. Michael Dillon - Internet & ISP Consulting Memra Software Inc. - Fax: +1-250-546-3049 http://www.memra.com - E-mail: michael(a)memra.com ==================================================== -- Jim Fleming Unir Corporation http://www.Unir.Corp

1 0

dissertation available on end-to-end Internet dynamics
by Vern Paxson 30 May '97

30 May '97

[My apologies to those of you who will receive multiple copies of this announcement from other mailing lists ...] My dissertation on "Measurements and Analysis of End-to-End Internet Dynamics" is now available from: ftp://ftp.ee.lbl.gov/papers/vp-thesis/dis.ps.gz 1.8 MB gzip compressed, 7 MB uncompressed, about 400 pages total. Individual chapters are available, too, as described in: ftp://ftp.ee.lbl.gov/papers/vp-thesis/README This is the same material (but in agonizing detail :-) that I've talked about at recent NANOG meetings. Vern Vern Paxson MS 50B/2239 Lawrence Berkeley National Laboratory University of California Berkeley, CA 94720 510-486-7504 510-486-6363 (FAX) vern(a)ee.lbl.gov

1 0