- Test - lists.nanog.org

Disbanding nsfnet-cert list on merit.edu
by Larry J. Blunk 12 Feb '96

12 Feb '96

At this point, I will be removing the nsfnet-cert mail list exploder on merit.edu (given that the NSFNET is long dead and I don't feel like policing this list). This list is currently subscribed to the cert-advisory list at cert.org. If you're not already subscribed to this list directly, you'll need to subscribe via the following address: cert-advisory-request(a)cert.org By the way, here's the current subscription list for nsfnet-cert(a)merit.edu. Folks may want to subscribe their local exploder to the cert advisory list rather than having individuals subscribe directly. BRENDAN(a)otago.ac.nz, ken(a)VNET.IBM.COM (Ken Paquette), korpela(a)ssl.berkeley.edu (Eric J. Korpela), n.brownlee(a)aukuni.ac.nz, mhageman(a)empros.com (Mary Hageman), dar(a)cadcentre.co.uk (D.Ashton-Reader), mckee(a)sunbelt.net (Tim McKee), cert(a)ncar.ucar.edu, ops(a)noc.sura.net, nsfnet-cert-ml(a)ux1.cso.uiuc.edu, nwnet-cert(a)nwnet.net, nsfnet-cert(a)spot.colorado.edu, nsfnet-cert(a)rice.edu, cert(a)cic.net, merit-cert, regional-techs ------ Larry J. Blunk Merit Network, Inc. Ann Arbor, Michigan

1 0

MTU discovery problems in the Internet?
by Jamshid Mahdavi 12 Feb '96

12 Feb '96

All, In the last few days I have noticed two sites, quite by accident, to which MTU discovery does not work correctly. In one case the router which failed blackholed the traffic, and in the other case, the router returned an MTU value which is garbage (Friday I got 18K, today I get 63692!) Many sites depend on MTU discovery working properly, and the need for MTU discovery is not going away! I ask all of you provider types out there to please look over RFC1191 (it is short). If you don't have tools to diagnose MTU discovery problems, you can pull down ftp://ftp.psc.edu/pub/net_tools/traceroute.tar which includes a -M switch for MTU discovery. Thanks, --Jamshid

2 1

None
by tgardner＠bellsouth.NET 12 Feb '96

12 Feb '96

>From list-admin(a)merit.edu Mon Feb 12 02:13 EST 1996 Return-Path: list-admin(a)merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by ec-mail.bellsouth.net (8.6.12/8.6.12) with ESMTP id CAA01899; Mon, 12 Feb 1996 02:13:21 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-04.dialip.mich.net [35.1.48.53]) by merit.edu (8.7.3/merit-2.0) with SMTP id BAA18366 for <nanog(a)merit.edu>; Mon, 12 Feb 1996 01:16:27 -0500 (EST) Date: Mon, 12 Feb 96 05:05:02 GMT From: "William Allen Simpson" <bsimpson(a)morningstar.com> Message-ID: <4820.bsimpson(a)morningstar.com> To: nanog(a)merit.edu cc: Robert Du Gaue <rdugaue(a)calweb.com> Subject: Re: [NIC-960209.1757] Routing Problem (fwd) Content-Type: Content-Length: > From: "Craig A. Huegen" <c-huegen(a)quad.quadrunner.com> > It's a Catch-22. To provide the multi-homed, reliable services that many > successful providers offer their customers, you need your own IP space. > If the InterNIC isn't handing out blocks of routable size, you can't > exactly have the most flexibility with your links. > No circularity about it. First, you need customers. Second, if you already have enough customers, you get your own IP space. Until then, you get a small chunk out of somebody else's bigger IP space. Them's the current rules. Now, as I noted in my earlier message, I have long advocated that _NOBODY_ gets their own address space, and they _only_ get addresses through the Exchanges where they are connected. But, the rest of the IETF didn't go along with that idea. IPvB for sure, someday. > A good point, but I, as a customer, am looking for a provider which is > stable already; I'm not going to sign up to a service which says "we'll > become multi-homed and fully accessible just as soon as we get X > customers". I've seen others sign up for services which promise > this--you find they go down quickly because they tend to not meet the X > customer line. > So have I. That's another good reason not to give a chunk to such a provider in the first place. > You have to offer services that people want, with good quality, before > you can expect many customers to sign up. If you need X customers before > you can provide those services, then you end up in the Catch-22 loop again. > What's the problem? If you are small, you compete with the other little folks. Demonstrate your quality. You had better not falsely advertise that you are large. Good way to get sued for breach of contract. > Not every ISP has the investment capital to immediately run high-speed > links to every NAP in the nation. There seems to be this misconception -- that there is some _right_ to make money off the Internet without much capital investment. If they cannot meet the barrier to entry, then they deserve to go out of business. > But, that aside, are your customers > going to use your service if they know that the Y% of people on the net > using SprintLink are going to be unable to reach your network? > I hope not. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

None
by tgardner＠bellsouth.NET 12 Feb '96

12 Feb '96

>From list-admin(a)merit.edu Mon Feb 12 02:13 EST 1996 Return-Path: list-admin(a)merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by ec-mail.bellsouth.net (8.6.12/8.6.12) with ESMTP id CAA01895 for <bprice(a)bsan.com>; Mon, 12 Feb 1996 02:13:16 -0500 Received: from Bill.Simpson.DialUp.Mich.Net (pm001-04.dialip.mich.net [35.1.48.53]) by merit.edu (8.7.3/merit-2.0) with SMTP id BAA18366 for <nanog(a)merit.edu>; Mon, 12 Feb 1996 01:16:27 -0500 (EST) Date: Mon, 12 Feb 96 05:05:02 GMT From: "William Allen Simpson" <bsimpson(a)morningstar.com> Message-ID: <4820.bsimpson(a)morningstar.com> To: nanog(a)merit.edu cc: Robert Du Gaue <rdugaue(a)calweb.com> Subject: Re: [NIC-960209.1757] Routing Problem (fwd) Content-Type: Content-Length: > From: "Craig A. Huegen" <c-huegen(a)quad.quadrunner.com> > It's a Catch-22. To provide the multi-homed, reliable services that many > successful providers offer their customers, you need your own IP space. > If the InterNIC isn't handing out blocks of routable size, you can't > exactly have the most flexibility with your links. > No circularity about it. First, you need customers. Second, if you already have enough customers, you get your own IP space. Until then, you get a small chunk out of somebody else's bigger IP space. Them's the current rules. Now, as I noted in my earlier message, I have long advocated that _NOBODY_ gets their own address space, and they _only_ get addresses through the Exchanges where they are connected. But, the rest of the IETF didn't go along with that idea. IPvB for sure, someday. > A good point, but I, as a customer, am looking for a provider which is > stable already; I'm not going to sign up to a service which says "we'll > become multi-homed and fully accessible just as soon as we get X > customers". I've seen others sign up for services which promise > this--you find they go down quickly because they tend to not meet the X > customer line. > So have I. That's another good reason not to give a chunk to such a provider in the first place. > You have to offer services that people want, with good quality, before > you can expect many customers to sign up. If you need X customers before > you can provide those services, then you end up in the Catch-22 loop again. > What's the problem? If you are small, you compete with the other little folks. Demonstrate your quality. You had better not falsely advertise that you are large. Good way to get sued for breach of contract. > Not every ISP has the investment capital to immediately run high-speed > links to every NAP in the nation. There seems to be this misconception -- that there is some _right_ to make money off the Internet without much capital investment. If they cannot meet the barrier to entry, then they deserve to go out of business. > But, that aside, are your customers > going to use your service if they know that the Y% of people on the net > using SprintLink are going to be unable to reach your network? > I hope not. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

None
by tgardner＠bellsouth.NET 12 Feb '96

12 Feb '96

>From list-admin(a)merit.edu Sun Feb 11 22:47 EST 1996 Return-Path: list-admin(a)merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by ec-mail.bellsouth.net (8.6.12/8.6.12) with ESMTP id WAA01493; Sun, 11 Feb 1996 22:47:17 -0500 Received: from nic.hq.cic.net (dorian(a)nic.hq.cic.net [198.108.58.2]) by merit.edu (8.7.3/merit-2.0) with ESMTP id VAA14330 for <nanog(a)merit.edu>; Sun, 11 Feb 1996 21:51:57 -0500 (EST) Received: (from dorian@localhost) by nic.hq.cic.net (8.7.3/8.6.12) id VAA26849; Sun, 11 Feb 1996 21:51:56 -0500 (EST) Date: Sun, 11 Feb 1996 21:51:56 -0500 (EST) From: Dorian Kim <dorian(a)CIC.Net> X-Sender: dorian(a)nic.hq.cic.net To: nanog(a)merit.edu cc: markk(a)internic.net Subject: ISP Domain Auction Message-ID: <Pine.OSF.3.91.960211214941.26007P-100000(a)nic.hq.cic.net> MIME-Version: 1.0 Content-Type: Content-Length: Hmm.. so when do you think we'll see ISP IP block auction? -dorian ---------- Forwarded message ---------- Date: Sun, 11 Feb 1996 16:19:12 -0800 From: domains(a)mrls.com Subject: ISP Domain Auction The following internet domain names are hereby submitted for auction to the highest bidder: astrology.com apparelservices.com britishtrade.com businesssfinancing.com cambodia.com canadatrade.com checks.com closeouts.com czechoslovakia.com deutschland.com diets.com egypt.com exerciseequipment.com exporttrade.com finland.com giftwares.com golfequipment.com guatemala.com greatbritain.com guadalajara.com homebasedbusinesses.com importtrade.com jerusalem.com koreatrade.com mailinglists.com manufacturing.com maritimeworld.com mexicotrade.com moneymanager.com moneysources.com nicaragua.com norway.com oceanshores.com offprice.com offpriceclothes.com pageants.com pilgrimage.com ports.net poulsbo.com puertorico.com riverrafting.com romania.com sanpedrosula.com seniorcitizens.com shipping.net skiresorts.com snohomish.com soulmate.com sweaters.com teenager.com teenagers.com tegucigalpa.com thailandtrade.com usedfurniture.com **************************************************************************** Offers begin at $100.00 per domain. Final bids must be received by 03/31/96 11:59pm PDT To submit a bid on one of these domain names, return this mail or visit http://brokeragent.com.

1 0

None
by tgardner＠bellsouth.NET 12 Feb '96

12 Feb '96

>From list-admin(a)merit.edu Sun Feb 11 22:47 EST 1996 Return-Path: list-admin(a)merit.edu Received: from merit.edu (merit.edu [35.1.1.42]) by ec-mail.bellsouth.net (8.6.12/8.6.12) with ESMTP id WAA01489 for <bprice(a)bsan.com>; Sun, 11 Feb 1996 22:47:13 -0500 Received: from nic.hq.cic.net (dorian(a)nic.hq.cic.net [198.108.58.2]) by merit.edu (8.7.3/merit-2.0) with ESMTP id VAA14330 for <nanog(a)merit.edu>; Sun, 11 Feb 1996 21:51:57 -0500 (EST) Received: (from dorian@localhost) by nic.hq.cic.net (8.7.3/8.6.12) id VAA26849; Sun, 11 Feb 1996 21:51:56 -0500 (EST) Date: Sun, 11 Feb 1996 21:51:56 -0500 (EST) From: Dorian Kim <dorian(a)CIC.Net> X-Sender: dorian(a)nic.hq.cic.net To: nanog(a)merit.edu cc: markk(a)internic.net Subject: ISP Domain Auction Message-ID: <Pine.OSF.3.91.960211214941.26007P-100000(a)nic.hq.cic.net> MIME-Version: 1.0 Content-Type: Content-Length: Hmm.. so when do you think we'll see ISP IP block auction? -dorian ---------- Forwarded message ---------- Date: Sun, 11 Feb 1996 16:19:12 -0800 From: domains(a)mrls.com Subject: ISP Domain Auction The following internet domain names are hereby submitted for auction to the highest bidder: astrology.com apparelservices.com britishtrade.com businesssfinancing.com cambodia.com canadatrade.com checks.com closeouts.com czechoslovakia.com deutschland.com diets.com egypt.com exerciseequipment.com exporttrade.com finland.com giftwares.com golfequipment.com guatemala.com greatbritain.com guadalajara.com homebasedbusinesses.com importtrade.com jerusalem.com koreatrade.com mailinglists.com manufacturing.com maritimeworld.com mexicotrade.com moneymanager.com moneysources.com nicaragua.com norway.com oceanshores.com offprice.com offpriceclothes.com pageants.com pilgrimage.com ports.net poulsbo.com puertorico.com riverrafting.com romania.com sanpedrosula.com seniorcitizens.com shipping.net skiresorts.com snohomish.com soulmate.com sweaters.com teenager.com teenagers.com tegucigalpa.com thailandtrade.com usedfurniture.com **************************************************************************** Offers begin at $100.00 per domain. Final bids must be received by 03/31/96 11:59pm PDT To submit a bid on one of these domain names, return this mail or visit http://brokeragent.com.

1 0

Re: ISP Domain Auction
by Justin W. Newton 12 Feb '96

12 Feb '96

On 11 Feb 96 at 21:51, Dorian Kim wrote: > Hmm.. so when do you think we'll see ISP IP block auction? > > -dorian Hey, I'd actually be willing to pay money for that one ;) Justin Newton | jnewton(a)hq.mainet.com Internet Administrator # (703) 506-0505 MAI Network Services | Detroit MXP online now #

1 0

Re: [NIC-960209.1757] Routing Problem (fwd)
by Robert Du Gaue 12 Feb '96

12 Feb '96

> No circularity about it. First, you need customers. Second, if you > already have enough customers, you get your own IP space. > > Until then, you get a small chunk out of somebody else's bigger IP space. Yeah right. You try that with a growing business. Then when you finally get enough users and corporate customers to 'justify' your own 64block and then give them the news that their entire networks will now need to be reconfigured how do you think they'll react. If I was that big, the amount of money it would cost me and my end-users would not be trivial.

2 1

Re: [NIC-960209.1757] Routing Problem (fwd)
by William Allen Simpson 12 Feb '96

12 Feb '96

> From: "Craig A. Huegen" <c-huegen(a)quad.quadrunner.com> > It's a Catch-22. To provide the multi-homed, reliable services that many > successful providers offer their customers, you need your own IP space. > If the InterNIC isn't handing out blocks of routable size, you can't > exactly have the most flexibility with your links. > No circularity about it. First, you need customers. Second, if you already have enough customers, you get your own IP space. Until then, you get a small chunk out of somebody else's bigger IP space. Them's the current rules. Now, as I noted in my earlier message, I have long advocated that _NOBODY_ gets their own address space, and they _only_ get addresses through the Exchanges where they are connected. But, the rest of the IETF didn't go along with that idea. IPvB for sure, someday. > A good point, but I, as a customer, am looking for a provider which is > stable already; I'm not going to sign up to a service which says "we'll > become multi-homed and fully accessible just as soon as we get X > customers". I've seen others sign up for services which promise > this--you find they go down quickly because they tend to not meet the X > customer line. > So have I. That's another good reason not to give a chunk to such a provider in the first place. > You have to offer services that people want, with good quality, before > you can expect many customers to sign up. If you need X customers before > you can provide those services, then you end up in the Catch-22 loop again. > What's the problem? If you are small, you compete with the other little folks. Demonstrate your quality. You had better not falsely advertise that you are large. Good way to get sued for breach of contract. > Not every ISP has the investment capital to immediately run high-speed > links to every NAP in the nation. There seems to be this misconception -- that there is some _right_ to make money off the Internet without much capital investment. If they cannot meet the barrier to entry, then they deserve to go out of business. > But, that aside, are your customers > going to use your service if they know that the Y% of people on the net > using SprintLink are going to be unable to reach your network? > I hope not. Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: [NIC-960209.1757] Routing Problem (fwd)
by William Allen Simpson 11 Feb '96

11 Feb '96

> From: Robert Du Gaue <rdugaue(a)calweb.com> > To: Network Registration Role Account <netreg(a)internic.net> > cc: nanog(a)merit.edu, cidrd(a)IEPG.ORG, iepg(a)IEPG.ORG, iab(a)isi.edu, iesg(a)isi.edu, > dennis.mcconnell(a)nolte.com, noc(a)pagesat.net, norman(a)pagesat.net So kind of you to include so many lists. (:-{ I truncated the CC to the appropriate list for NA service providers. > How the hell can I be a successful ISP when first, I probably > can not justify 64 blocks (and if I do Sprint may change it to 128 > anyways!) Let's think about this for a moment. How do you define "successful"? If you mean, you already have lots of customers signed up before you ask for your first block, then of course you won't have any problem justifying 64 or more C's. And you will be able to afford to run your own continental links to the various NAPs. I do not see how having no customers signed up qualifies as successful. > and second if the blocks I get are not routed through one of > the MAJOR backbone proivders then they are useless to me and my end > users! On the other hand, are you saying you are "successful", but you are not running your own continental network? Why then, you must be connected to "one of the MAJOR" providers, correct? It only takes one. You get your addresses from them, not from the global pool. As an alternative, I have long advocated that you get your addresses from an Exchange, and that Exchange arrange for connectivity to the rest of the net. There is more than one such Exchange in your region. > Using old policies to justify not doing something against what > is obviously discrimination against smaller ISPs does nothing to solve > the problem. > I don't know what "old policy" you are referring to. The warning about small unaggregated routes is relatively new. Please be more specific. I cannot parsed your sentence. What specific problem are you complaining about, and what is _your_ solution? Bill.Simpson(a)um.cc.umich.edu Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1