- NANOG - lists.nanog.org

RE: IPv8 < IPv6
by Jim Fleming 13 Nov '97

13 Nov '97

Bradley Reynolds[SMTP:brad@b63695.student.cwru.edu] wrote: <snip> @ @Granted, there will be an administrative hierarchy no @matter how you structure addresses, but I would rather that the @consumer decides who is going to administer the tiers @of such a hierarchy instead of leaving that decision @to the protocol fairy. @ I suggest that you use IPv6... http://www.6bone.net/6bone-testv2-address.txt http://www.6bone.net/6bone-testv2-addr-usage.html Jim Fleming Unir Corporation IBC, Tortola, BVI

1 0

Re: Cleveland<->Toronto UUNET..
by Chris MacFarlane 13 Nov '97

13 Nov '97

Certainly, UUnet has admitted they have a congestion problem. We started seeing it during the Scottsdale conference. When reported to UUnet Canada they stated the following. "We have serious congestion between Buffalo NY and Cleveland Ohio on a DS3 between the sites." They have a OC3 circuit on order to the DC area to peer near the Mae-East on AS701. Last update I had they stated the circuit was delayed due to US local loop issue and should be up by month end. In the meantime they are trying to reroute traffic internally to relieve the problem. I don't have any report on the progress of that measure. Hope that helps Chris MacFarlane Manager, Data Operations ACC Telenterprises Canada 4162132023 cmacfarlane(a)acc.ca cjm(a)ican.net -----Original Message----- From: Jamie Rishaw <jamie(a)intuition.iagnet.net> To: nanog(a)merit.edu <nanog(a)merit.edu> Cc: inet-access(a)earth.com <inet-access(a)earth.com> Date: Tuesday, November 11, 1997 12:43 PM Subject: Cleveland<->Toronto UUNET.. >I've had half a dozen tickets open with UUNET, they insist they cannot >replicate. > >Has anyone (besides me) seen problems between Cleveland UU and UUNET-CA(Tor)? > >(It's sporadic but annoying) > >Here's one from Canada: >traceroute to arpa.com (207.206.90.13), 30 hops max, 40 byte packets > 1 205.150.226.1 (205.150.226.1) 2.749 ms 2.831 ms 2.243 ms > 2 vl151.f000.bb1.tor2.uunet.ca (205.150.242.93) 4.974 ms 3.597 ms >2.164 ms > 3 224.Hssi5-0.CR1.CLE1.Alter.Net (137.39.75.17) 348.772 ms * 346.820 >ms > 4 * Fddi0-0.GW1.CLE1.Alter.Net (137.39.37.101) 326.843 ms 359.163 ms > 5 iag-gw.customer.ALTER.NET (157.130.96.178) 332.980 ms 336.167 ms * > >And back: >traceroute to 205.150.226.3 (205.150.226.3), 30 hops max, 40 byte packets > 1 207-206-0-32-27.gw.iagnet.net (207.206.0.33) 1.112 ms 1.088 ms 0.958 ms > 2 fddi-0-0.core1.cleveland.iagnet.net (209.57.2.97) 1.010 ms 0.965 ms 1.353 ms > 3 905.Hssi4-0.GW1.CLE1.ALTER.NET (157.130.96.177) 3.406 ms 2.871 ms 1.759 ms > 4 Fddi0-0.CR1.CLE1.Alter.Net (137.39.37.99) 3.392 ms 3.533 ms 1.904 ms > 5 119.Hssix-x.BB1.TOR2.Alter.Net (137.39.75.18) 336.981 ms 351.017 ms 316.750 ms > 6 vl151.f000.bb1.tor1.uunet.ca (205.150.242.94) 308.387 ms 319.213 ms 362.870 ms > >-- >jamie g.k. rishaw dal/efnet:gavroche __ IAGnet/CIC/netILLINOIS Backoffice >DID:216.902.5455 FAX:216.623.3566 \/ 800.637.4IAGx5455 > Chance favors the prepared mind. >

1 0

None
by John MacQueen 12 Nov '97

12 Nov '97

r

1 0

Trying again, QoS for IP networks???
by Marcel Schoenbeck 12 Nov '97

12 Nov '97

hello Nanog, I forgot the subject, oops. Let's try this again... A While back there was a thread on QoS, CoS for IP networks -- Interesting topic: I'm interested what people think about this category of products. There appear to be a bunch of vendors after this this market... Cisco Ipsilon Checkpoint Packeteer Xedia Structured Internetworks Has anybody worked with any of these products? Do they work? What about the different technologies WFQ CBQ Flow Control not to mention RSVP Is one approach better than another. I'd love to hear any comments or experiences ~ Marc ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

1 0

Re: new facility for nanog mailing list
by Danny McPherson 12 Nov '97

12 Nov '97

That'll certainly free up the majority of Randy's time, I'll be sad to not see his posts any longer :-) -danny > in light of the ongoing discussions about what kind of subject matter > is appropriate to the nanog mailing list, i have completed > development of an "autoflamer" intended to detect any inappropriate > postings to nanog and generate a suitable obnoxious response. > > in light of the difficulty of determing appropriateness of postings > to nanog, it appears that all postings to nanog will have to be > "autoflamed". > > this facility will be enabled on April 1st, 1998.

1 0

Re: Potentially dangerous Pentium bug disc
by Michael McArthur 12 Nov '97

12 Nov '97

On Wed, 12 Nov 1997, Michael 'Moose' Dinn wrote: > > Does anybody know if this affects the Cyrix and AMD "Pentium > > Clone" chips? > > > > It certainly affects the Cyrix - both P166+ and P200+. Don't know about the > Cyrix MX and the AMD tho. > > -- That's the problem -- it isn't a "bug", just an exploitable instruction set that Cyrix, AMD, et al have been faithfully copying. For that matter, the 486 instruction set is a subset of the Pentium instruction set. Does this affect the 486/386 etc..?

14 18

Potentially dangerous Pentium bug discovered
by Jay R. Ashworth 12 Nov '97

12 Nov '97

There tends to be a lot of the following sort of stuff that floats around unattributed, like the email viruses, and such. The following is documented, attributed, and _is_ something you should worry about. Please forward this message around your usual distribution lists. If you work at a company with lots of computers, you're invited to print this up and give it to the people who manage them for you. (If you have lots of computers at your company, and _no one_ to manage them for you, I'm looking for a new gig; have someone call me. :-) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message was originated 11 November 1997, by jra(a)baylink.com... headers have a way of disappearing. Enclosed are four messages from the RISKS Digest, an email forum on risks to the public in computers and related systems, which is one of the oldest standing regular pieces of editory on the Internet. It documents a recently discovered bug in the Intel Pentium<tm> and MMX<tm> processors, which allows user-level code to halt the processor. This is bad because these chips commonly support multi-tasking, and often multi-user, systems; halting such systems arbitrarily can destroy users' work. There appears to be no way to work around this problem that has been discovered as of 11 Nov 97; the only thing I can suggest is be _exceptionally_ careful about running programs the parentage of which you're not certain on production machines... which is good practice, anyway. The first three messages detail the problem, in increasingly technical detail, including a program to demonstrate the problem, and one to search for files containing the deadly instruction; the last message discusses some of the potential implications, and why we should know better. By way of clarification, all processors have a halt instruction. All current multi-tasking operating systems run the processor in such a mode that such instructions are not actually executed as a halt; control is transferred back to the OS. That is: Intel blew it. Badly. RISKS-LIST: Risks-Forum Digest Tuesday 11 November 1997 Volume 19 : Issue 45 FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator ***** See last item for further information, disclaimers, caveats, etc. ***** ------------------------------ Date: Tue, 11 Nov 1997 16:39:41 -0500 From: Chuck Weinstock <weinstock(a)SEI.CMU.EDU> Subject: New Pentium flaw To summarize, according to today's *Wall Street Journal*: The Pentium and Pentium MMX chips apparently can be halted by a single, unprotected, instruction. Over 200 million computers with these chips are expected to be deployed by year-end. My favorite quote from the article is by Linley Gwennap, editor of *Microprocessor Report* in Sunnyvale, who says that "most PC users shouldn't be overly concerned since they would only be affected if they were the target of a malicious attack." My second most favorite quote came from Tom Waldrop of Intel in Santa Clara who "confirmed that someone with malicious intent could exploit the flaw to cause a system to crash. But a hacker would have to have an ability to send programs to a computer in machine code, rather than the conventional computer languages that most programmers use." [We all know how hard that is...actually maybe these days it is, can we count on the fact that few people know how to write machine code these days?] Chuck Weinstock ------------------------------ Date: 09 Nov 1997 09:26:39 +0100 From: Torsten Hilbrich <Torsten.Hilbrich(a)bln.de> Subject: New Pentium flaw Yesterday (Nov, 8) I found the following information on the news-ticker page of the German Heise-Verlag (shortened to the essential information): > The Pentium in standard and MMX version halts on execution of the > instruction: > F0 0F C7 C8 > This code sequence works independent of any memory protection of the > operating system. I was able to reproduce this bug on a Pentium 133 system with the following operating systems: DOS, Windows 95, Linux 2.0.31, and FreeBSD 2.2.x. I don't know about PentiumPro and Pentium II. The risk? Every pentium based server with user access for executing programs can be crashed using this code sequence. Not to mention Trojan Horses or Active-X controls. Here is an example program: unsigned char hang[] = { 0xf0, 0x0f, 0xc7, 0xc8 }; int main() { void (*kill)(); kill = hang; kill(); /* return can be omitted as there is none */ } More information and example programs for various operating systems can be found on http://www.ccc.de Torsten Hilbrich [Also noted by Jeff Anderson-Lee <jonah(a)EECS.Berkeley.EDU> citing an item from Peter Curran in comp.security.unix, 7 Nov 1997. PGN] ------------------------------ Date: Mon, 10 Nov 1997 01:07:34 -0600 (CST) From: "Steven O. Siegfried" <sos(a)dial324.skypoint.net> Subject: New Pentium flaw New Intel Pentium risk: user mode program locks up system The following program, when compiled and run in __USER__ mode on any Pentium (reported as MMX or not, don't know about Pentium II yet) will lock-up the system. > char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 }; > main () > { > void (*f)() = x; > f(); > } Any user can execute this program at the lowest level of security provided by the following operating systems: OS/2, NT, W95, Linux. When I tried it, I could _only_ recover by power-cycling my box. The following perl script, courtesy of Sam Trenholme via the security mailing list at Redhat Software is reported to find _all_ occurences of this code sequence on systems running Linux. (It found my bomb program after I used it to kill my system as a test.) It can probably be adapted for use on other operating systems. > #!/usr/bin/perl > # Source: Sam Trenholme via linux-security(a)redhat.com mailing list. > # There is no known software fix to the F0 0F C7 C8 bug at this time. > # usage: $0 dir > # Where dir is the directory you recursively look at all programs in > # for instances of the F0 0F C7 C8 sequence. > # This script will search for programs with this sequence, which will > # help sysadmins take appropriate action against those running such > # programs. > # This script is written (but has not been tested) in Perl4, to > # insure maximum compatibility . > sub findit { > local($dir,$file,@files,$data) = @_; > undef $/; > if(!opendir(DIR,$dir)) { > print STDERR "Can not open $dir: $!\n"; > return 0; > } > @files=readdir(DIR); > foreach $file (@files) { > if($file ne '.' && $file ne '..') { > if( -f "$dir/$file" && open(FILE,"< $dir/$file")) { > $data=<FILE>; > if($data =~ /\xf0\x0f\xc7\xc8/) { > print "$dir/$file contains F0 0F C7 C8\n"; > } > } elsif( -d "$dir/$file") { > &findit("$dir/$file"); > } > } > } > } > $dir = shift || '/home'; > > &findit($dir); Basically, there's no protection from this. Adjust your execution of downline loaded absolutes accordingly. Steve Siegfried sos(a)skypoint.com sos1(a)xtl.msc.edu ------------------------------ Date: Sat, 8 Nov 1997 12:06:42 -0500 (EST) From: "Cary B. O'Brien" <cobrien(a)access.digex.net> Subject: Recent Pentium opcode bug like Monoclonal Agriculture [...] Once again I am reminded of the parallels between nearly complete market domination by a hardware or software product, and the risks of monoclonal agriculture (*). In either case a flaw (be it a hardware error, software bug, or susceptibility to a strain of bacteria or virus) has the potential to cripple an entire industry, with serious sociological consequences. (cf., the Irish Potato Famine). To me, at least, these parallels reinforce the importance of the government's responsibility to prevent monopolistic activity on the part of corporations. Loss of technological diversity is nearly as bad as the loss of genetic diversity (although far easier to reverse). Cary O'Brien (*) By this I mean when a majority of the farms grow genetically identical products. ------------------------------ Date: 1 Apr 1997 (LAST-MODIFIED) From: RISKS-request(a)csl.sri.com Subject: Abridged info on RISKS (comp.risks) The RISKS Forum is a MODERATED digest. Its Usenet equivalent is comp.risks. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. Or use Bitnet LISTSERV. Alternatively, (via majordomo) DIRECT REQUESTS to <risks-request(a)csl.sri.com> with one-line, SUBSCRIBE (or UNSUBSCRIBE) [with net address if different from FROM:] or INFO [for unabridged version of RISKS information] => The INFO file (submissions, default disclaimers, archive sites, .mil/.uk subscribers, copyright policy, PRIVACY digests, etc.) is also obtainable from http://www.CSL.sri.com/risksinfo.html ftp://www.CSL.sri.com/pub/risks.info The full info file will appear now and then in future issues. *** All contributors are assumed to have read the full info file for guidelines. *** => SUBMISSIONS: to risks(a)CSL.sri.com with meaningful SUBJECT: line. => ARCHIVES are available: ftp://ftp.sri.com/risks or ftp ftp.sri.com<CR>login anonymous<CR>[YourNetAddress]<CR>cd risks [volume-summary issues are in risks-*.00] [back volumes have their own subdirectories, e.g., "cd 18" for volume 18] or http://catless.ncl.ac.uk/Risks/VL.IS.html [i.e., VoLume, ISsue]. The ftp.sri.com site risks directory also contains the most recent PostScript copy of PGN's comprehensive historical summary of one liners: get illustrative.PS ------------------------------ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Cheers, -- jra -- Jay R. Ashworth High Technology Systems Consulting Ashworth Designer Linux: Where Do You Want To Fly Today? & Associates ka1fjx/4 Crack. It does a body good. +1 813 790 7592 jra(a)baylink.com http://rc5.distributed.net NIC: jra3

3 3

Re: I don't want to crash the 'net
by gary flynn 12 Nov '97

12 Nov '97

> From: Paul Ferguson <ferguson(a)cisco.com> > > As an aside, a lot of the same information is contained at: > > BGP Technical Tips > > o EBGP Sample Configuration to Load Balance over Multiple Serial Links > o Using the Border Gateway Protocol for Interdomain Routing Indeed. The second one is written by the author of the book and I found it very useful. However, the book seems better organized with more examples and explanations. I found it worth the investment. His OSPF design guide was also helpful (shoot, it was a priceless) Over the summer I went from: oncampus RIP,classful addressing,static Internet routes to a single provider to oncampus/offcampus OSPF,partial CIDR,BGP4 to multiple providers. My references were: Routing in the Internet Christian Huitema Prentice-Hall ISBN 0-13-132192-7 The afore mentioned book and Cisco BGP web page. OSPF Design Guide Sam Halabi (from Cisco Web server somewhere) RIP and OSPF Redistribution www.cisco.com/univercd/data/doc/cintrnet/ics/icsospf.htm

1 0

Load sharing on BGP on C75xx
by Pascal Petit - SYNET 12 Nov '97

12 Nov '97

Has anyone experienced load balancing on C75xx using BGP. I have noticed that 11.2 introduce multipath support, however I was wondering about performances ... Is it done at Optimal Switching level ? Thanks for sharing any type of experiences as multipath BGP, asymetric traffic on two links, .... ------------------------------------------------------------------------ Pascal Petit SYNET tel: 33 1 4696 0040 74, rue Roque de Fillol fax: 33 1 4696 0041 92800 Puteaux email: ppetit(a)synet.fr FRANCE http://www.synet.fr

1 0

Re: I don't want to crash the 'net
by gary flynn 12 Nov '97

12 Nov '97

> From: Sheryl Chapin <schapin(a)ctel.net> > > So if anyone has any advice, caveats, pointers to docs, > things I absolutely should do or things I absolutely > shouldn't do, I would be EXTREMELY grateful. Sheryl, I recently went through the same learning experience and found the following document very helpful when combined with the references you already listed: Internet Routing Architectures Bassam Halabi Cisco Press/New Riders Publishing Besides applied theory, it contains practical approaches to solving various realistic problems including the whys, the alternate solutions, and related Cisco IOS commands. My copy doesn't have an ISBN number. I think I got it from www.amazon.com (but it may have been Borders). It helped me a lot in making our previous T1 link a backup to our new primary DS3 link. Its worked twice although I think there are still some problems because the BGP table revision keeps incrementing. Nobody's complained of any flaps though. (anyone can take this as an open invitation to complain or suggest fixes <GRIN>) AS 10357 Gary Flynn Network Analyst James Madison University

1 0