May 1997 - Test - lists.nanog.org

Re: NANOG 10
by Rudy Amid 16 Jun '97

16 Jun '97

Go to Toronto, Canada then! Summers are nice here. It can be as warm as the Sahara desert. :) There are so many ISPs here in Toronto alone, they may benefit from NANOG's wisdom. --- Rudy Amid (rudy(a)hcl.com) Systems "I'm IT!" Administrator NB: IMHO! >/` Hummingbird Communications, Ltd. 1 Sparks Ave. Toronto, Ont. __ " Canada. M2H 2W1. 416-496-2200 Fax 496-2207 [URL] http://www.hcl.com | PGP key fingerprint is on my home page at http://www.warped.com/~radix \_) ---------- > From: Len Rose <len(a)netsys.com> > To: nanog(a)home.merit.edu > Subject: Re: NANOG 10 > Date: Tuesday, March 18, 1997 4:33 PM > > Who in their right mind would want to go to Florida in the middle of > summer? > > Len > > > len(a)netsys.com > http://www.netsys.com

5 4

NANOG Meeting
by Jim Fleming 05 Jun '97

05 Jun '97

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 "Merit is pleased to announce a tutorial titled "Review of Internet Resources for ISPs," scheduled from 7:30-9:00 p.m. on Wednesday evening, June 4, the evening before NANOG. To be presented by Michael Dillon, a well-known systems integrator and ISP consultant, the session will cover IP address allocation issues, with information targetted especially for providers who are applying for their first IP address allocation from ARIN/the InterNIC." @@@@@@@@@@@@@@@@@@@@@@@@@@@ -- Jim Fleming Unir Corporation http://www.Unir.Corp

13 14

Bye...
by bmanning＠ISI.EDU 02 Jun '97

02 Jun '97

-IF- there is a kind person who would be willing to forward me material relevent to network operations I'd appreciate it. Voting w/ his unsubscribe key.... --bill

11 11

Re: connectivity outside the US
by Vadim Antonov 01 Jun '97

01 Jun '97

smd(a)clock.org (Sean M. Doran) wrote: > 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. Actually, i do not understand why undersea capacity is so expensive. Cable is more expensive, yes; but the paths are much straighter, and there's no need to purchase rights of ways (except for shore-side strips). There's no need to dig trenches -- you just drop the cable off the boat. I guess the real problem with undersea capacity is more in the fact that it was always considered a low-volume service (which it is, in terms of voice traffic); so there's no many competitive providers, and small-quantity pricing. --vadim

6 5

RFC 1918 addresses
by Paul A Vixie 31 May '97

31 May '97

I think that any exposure of these addresses outside their addressing realm is a mistake. Using them for otherwise unnumbered serial links would be fine if Cisco had an option to "use loopback address when sending ICMP's" but they don't. Traceroute is sending increasing-TTL'd UDP datagrams, and if you are seeing a 10.0.0.2 source address on an router's ICMP to you it means you would get that as a normal ICMP too -- meaning not just one due to a diagnostic like Traceroute. I think this is an error. Exposing an RFC 1918 private address in, say, a "Received:" header in e-mail is less of a problem, though the spammers who do it are actually better able to cover their origins, there's no way to prevent it and no normal damage from doing it. No IP datagram with an RFC 1918 address in the protocol headers should be allowed outside a private addressing realm. This means not the source address, not the destination address, and not the encapsulated addresses inside an ICMP payload.

1 0

Re: connectivity outside the US
by Daniel McRobb 31 May '97

31 May '97

> smd(a)clock.org (Sean M. Doran) wrote: > > > 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. > > Actually, i do not understand why undersea capacity is so > expensive. Cable is more expensive, yes; but the paths > are much straighter, and there's no need to purchase > rights of ways (except for shore-side strips). There's > no need to dig trenches -- you just drop the cable off the > boat. >From what I've read, it's quite difficult to lay undersea cable. There was a nice article in the Dec. 1996 issue of WIRED covering the FLAG (Fiberoptic Link Around the Globe) project, written by (of all people) Neal Stephenson. Online at: http://wwww.wired.com/wired/4.12/features/ffglass.html Daniel ~~~~~~

1 0

Re: 10.0.0
by Danny McPherson 31 May '97

31 May '97

> You can have an internal mesh made up of entireley rfc1918 address > space, and not leak these routes to the rest of the world, I've only > once caught MCI leaking stuff from a test lab, which was kinda annoying, > but not really anything bad, and a polite e-mail message to them got > an immediate fix of the problem. > i'd think most providers filter rfc1918 addresses both inbound and outbound at naps (mci does, i believe), although maybe not to customers... using reserved address space internally (as long is it remains internal), seems like a good idea to me - isn't that why it was reserved? -danny

2 1

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