- Test - lists.nanog.org

anti-smurf info
by Charles Sprickman 09 Feb '99

09 Feb '99

Hi, Just to let anyone using 3Com/USR gear with "HiPer ARC" term servers know that the latest release supports a new feature that will validate outgoing packets for the proper IP address. Release 4.1.59-1 includes a feature called "SAA" or "Source Address Assurance". It's basically an auto filter that will only let users source packets from the address they are assigned when they dial in. It can be globally applied or triggered per-user via Radius. This is a free download, no service contract required... Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork(a)inch.com access(a)inch.com | = =----------------=

1 0

Re: NIC database/whois
by Robert Szarka 09 Feb '99

09 Feb '99

At 08:11 PM 2/7/99 , Becki Kain wrote: >anyone else noticed the NIC "losing" a set of domain registrations, around >the time of January 11 (during their "speculator" issues), where the NIC >took the modify, modified the domain, then reset it to it's previous >settings (from January 9)? Something similar may have happened to one of the domains hosted here, but I think it was at an earlier date. Submissions--even ones that were acknowledged--were lost over the past month, that's for sure, despite their plea for us not to resubmit! >also, is there a way to do the old "whois server <server NIC name>" to >show everything a server is registered for? I can't seem to get that to >work, no matter what whois I try. There is a form somewhere on their site for requesting that roughly equivalent info be sent via email. It took them a couple of days to get it to me, as I recall, but it did work when I tried it last month. Ah, here it is: http://rs.internic.net/reports/ -- Robert Szarka Managing Partner, Operations DownCity, LLC +1 860 823 3000

6 5

Re: NIC database/whois
by Forrest W. Christian 09 Feb '99

09 Feb '99

On Tue, 9 Feb 1999, Jon Ribbens wrote: > This seems not to work anymore these days. Hmmm.... whois lewis.mt.net # whois ns01.backupdns.com [No name] (NS31832-HST) Hostname: NS01.BACKUPDNS.COM Address: 206.127.77.91 System: ? running ? Record last updated on 30-Sep-97. Database last updated on 8-Feb-99 05:16:01 EST. # whois "server ns31832-HST" Complete Computing Services (TAMECT-DOM) TAMECT.ORG Complete Computing Services (ICS-CO-DOM) ICS-CO.COM Cybervisors, Inc. (CYBERVISORS-DOM) CYBERVISORS.COM Works for me. The only gotcha is that if you have over 50 responses, you need to use the online whois via telnetting to internic.net. - Forrest W. Christian (forrestc(a)imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

1 0

URGENT: Missing AIRONET Wireless Card from NANOG 15
by John M. Brown 09 Feb '99

09 Feb '99

Would the person who's driver's lic is B057253 please return the AiroNet wireless card you borrowed at NANOG 15. Thank you jmbrown(a)ihighway.net

2 1

Re: Why the temptation for dial users to crank back rwin/mtu?
by Aron Sedlack 08 Feb '99

08 Feb '99

> It's always been my belief that the 576 values were generated by hosts > that didn't support Path MTU discovery and wanted to be conservative > and avoid fragmentation. Fair enough.. .... > apparently there's some performance value in this (at least to the .... > > MTU - at least this makes a little bit of sense.. If they're doing > HTTP/1.0 stuff with parallel connections then a smaller MTU is going > to make that parallelization latency much more effective and perceived > performance will go up some.. it doesn't impact full document > retrieval time though (at least not positively!).. are dial links > really lossy enough that chopping the segment size to 1/3 is a big win > in retransmit time or are the win95/98 stacks really braindead enough > that they don't do pmtud so are just trying to dodge fragmentation? I > found it really odd that [7] which I use all the time to track > features in a myriad of shipped OS's actually has a blank entry for > pmtud on both of those (neither yes nor no..) This is discussed in depth in RFC1191 and W. Richard Stevens' book "TCP/IP Illustrated Volume 1" (see page 29-31). Aron

1 0

Smurf Woes
by Jason Weisberger 08 Feb '99

08 Feb '99

If anyone has had any success with CAR as a Smurf suppressant, can you drop me some email - I want to compare some notes. -- Jason Weisberger Chief Technology Officer SoftAware, Inc. 310/305-0275 Friends applaud, the comedy is over. --Ludwig van Beethoven's last words. d.1827

1 0

NIC database/whois
by Becki Kain 08 Feb '99

08 Feb '99

anyone else noticed the NIC "losing" a set of domain registrations, around the time of January 11 (during their "speculator" issues), where the NIC took the modify, modified the domain, then reset it to it's previous settings (from January 9)? also, is there a way to do the old "whois server <server NIC name>" to show everything a server is registered for? I can't seem to get that to work, no matter what whois I try. thanks beckers Becki Kain beckers(a)furph.com -- furph, Inc. WWW/Unix/Windows Solutions 734-513-7763 (voice) info(a)furph.com http://www.furph.com 734-513-7759 (FAX)

2 1

Re: Discussing, or not discussing, major business outages
by George Herbert 07 Feb '99

07 Feb '99

Dave Rand writes: >>George Herbert: >> I would like to see the issue discussed in general terms >> at least; what is appropriate for notifications, what are >> fair responsibilities to customers, the public, other ISPs etc. >> in terms of this sort of event. > >As has happened in the past, it is my opinion that the techincal contacts >for that organization should step forth at the appropriate time with >details. This may, in fact, be after connectivity has been lost. >Often, last minute negotations can restore services with only a momentary >outage. No one but the people directly involved should be aware of this, >for business reasons. Sometimes, business go through tough times for >reasons beyond their control. No reflection on the technical abilities of >the people involved - but just business. The reason I asked the question is that I have been bit today by a series of 4 outages (all completely unrelated to the provider I referred to which is going out of business) from unrelated ISP links or business-critical systems of which at least 2, probably 3 should have resulted in proactive notifications or at least prompt reactive warnings to the customers/users and neighboring parties, and such notifications and warnings did not happen. I am now passing 13 hours of work today in reaction to those events. This has made me extremely sensitive to this sort of issue today. This provider which went out of business apparently has, in fact, cut off lines and forced customers to move (though not all of them) at this time, though I do not have firsthand knowledge of this. They are off the net completely as far as I am able to tell (though I could be wrong... I am busy fighting my own fires, and things may be more up than I can see right now). I agree that this is no reflection on the technical abilities of the people involved. It is, as Dave says, just business, and not all businesses succeed. But there is ethical responsibility to operate, and if it comes to that cease operations, in a manner that provides for minimal trouble for your customers, suppliers, and other related businesses. There appears to be a tendency for the "right time" to talk, as judged by the ISPs which are shutting down, to be woefully late. It is business, but business in a way that can significantly affect operational issues and stability. >I'm certain that others would like to see the insides of every company >exposed at all times. While it may be important to the customers, or >potential customers, it should be a part of the diligence of the customer to >inspect the worthiness of their supplier. >I'm equally certain that the providers in question will step forward at >the appropriate time to establish facts. Obviously, most businesses need to operate with careful limits on public disclosure, because operational issues are often of competitive importance and it's very easy to lose significant amounts of money via trivial information leaks. But that does have its limits. -george william herbert gherbert(a)crl.com I do not work for CRL nor speak for it.

2 1

Why the temptation for dial users to crank back rwin/mtu?
by mcmanus＠appliedtheory.com 07 Feb '99

07 Feb '99

Hi Folks, As we know[1], packet sizes on the network fall almost exclusively into one of 4 categories: Small (<50 byte) dataless packets.. tcp acks/syns/rsts.. 576 byte packets 1500 byte packets runt packets less than sender MTU.. It's always been my belief that the 576 values were generated by hosts that didn't support Path MTU discovery and wanted to be conservative and avoid fragmentation. Fair enough.. but, as I'm sure everybody knows, there's a plethora of website/utilities ([2],[3],[4],[5],[6],..) imploring windows dial users to use any one of a number of tools/techniques to play with their mtu/rwin settings to 'make things faster'.. In typical windows fashion nothing is quantified in any meaningful fashion and the only motivation provided is typically some garbage like "windows comes setup for LAN not internet use".. these tools tend to crank down both rwin and mtu an awful lot. apparently there's some performance value in this (at least to the immediate user) because they keep doing it in droves. It's not obvious to me why the heck this would be. (warning: I am a protocol guy, but I'm not a dialup guy at all.. and even less of a windows guy) MTU - at least this makes a little bit of sense.. If they're doing HTTP/1.0 stuff with parallel connections then a smaller MTU is going to make that parallelization latency much more effective and perceived performance will go up some.. it doesn't impact full document retrieval time though (at least not positively!).. are dial links really lossy enough that chopping the segment size to 1/3 is a big win in retransmit time or are the win95/98 stacks really braindead enough that they don't do pmtud so are just trying to dodge fragmentation? I found it really odd that [7] which I use all the time to track features in a myriad of shipped OS's actually has a blank entry for pmtud on both of those (neither yes nor no..) RWIN - this is the one that boggles my mind.. it gets set way way way down by the above mentioned tools.. I've seen it as low as 2500 bytes recently. Anyone have any insight into the value of pushing this all the way down? The web pages generally mumble about capping the amount of data that needs to be resent in case of a failure.. which is of course true in the extreme case, but I'd much rather have the congestion window providing the throttle than the hard-limit of rwin that can just cap transfer rates on you.. about the only reason I can think of for small RWINs is to conserve the buffer space, but it sure seems worth a few K to me to be sure I can work with high latency links. You could argue that 3 or 4 K is sufficient for any reasonable latency that is bottlenecked by a modem's throughput.. and eventually I might give in (or maybe not ;)).. what I don't get is why this results in any kind of perceived performace increase on the part of the user under any condition.. It almost implies that TCP congestion control is too conservative, although almost all work on that indicates it's a little too aggressive (which would be the side to err on..) Any thoughts? -P [1] http://www.caida.org/Papers/Inet98/ [2] http://www.cerberus-sys.com/~belleisl/tune_faq/tuning.htm [3] http://www.trumpet.com.au/wsk/faq/config.htm [4] http://www.mc-pro.com/hardware/windialup.shtml [5] http://www0.delphi.com/pccompat/mtu.html [6] http://www.pattersondesigns.com/tweakdun/index.html [7] http://www.psc.edu/networking/perf_tune.html

3 3

Re: Discussing, or not discussing, major business outages
by dlr＠bungi.com 07 Feb '99

07 Feb '99

[In the message entitled "Discussing, or not discussing, major business outages" on Feb 6, 23:06, George Herbert writes:] > > I would like to see the issue discussed in general terms > at least; what is appropriate for notifications, what are > fair responsibilities to customers, the public, other ISPs etc. > in terms of this sort of event. > As has happened in the past, it is my opinion that the techincal contacts for that organization should step forth at the appropriate time with details. This may, in fact, be after connectivity has been lost. Often, last minute negotations can restore services with only a momentary outage. No one but the people directly involved should be aware of this, for business reasons. Sometimes, business go through tough times for reasons beyond their control. No reflection on the technical abilities of the people involved - but just business. I'm certain that others would like to see the insides of every company exposed at all times. While it may be important to the customers, or potential customers, it should be a part of the diligence of the customer to inspect the worthiness of their supplier. I'm equally certain that the providers in question will step forward at the appropriate time to establish facts. -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0