- Test - lists.nanog.org

Lame RFC1918 delegations
by Barry Margolin 16 Apr '98

16 Apr '98

Several people have forwarded to me a message you sent to NANOG saying that the problem with the RFC 1918 delegations was fixed yesterday. As far as I can tell, this is not true. I'm still seeing lame responses from both blackhole.isi.edu and ns2.internic.net (which replaced rs0.internic.net in the delegations yesterday). Also, we have a system here configured as a secondary server for the RFC 1918 domains, so that we can point customer firewalls to it for their zone transfers (this way, if the original primary moves, we only have to update one system, not all the firewalls). It used to use ns.isi.edu as its primary, but that stopped working on 3/25. Is there a machine that can be used instead? tools:~#58% whois 172.16 IANA (IANA-BBLK-RESERVED) Internet Assigned Numbers Authority Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 1001 Marina del Rey, CA 90292-6695 Netname: IANA-BBLK-RESERVED Netblock: 172.16.0.0 - 172.31.0.0 Coordinator: Internet Assigned Numbers Authority (IANA-ARIN) iana(a)iana.org (310) 822-1511 Domain System inverse mapping provided by: BLACKHOLE.ISI.EDU 128.9.64.26 NS2.INTERNIC.NET 198.41.0.11 tools:~#61% dig -x 172.16 any @blackhole.isi.edu ; <<>> DiG 2.1 <<>> -x any @blackhole.isi.edu ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd ra; Ques: 1, Ans: 2, Auth: 2, Addit: 2 ;; QUESTIONS: ;; 16.172.in-addr.arpa, type = ANY, class = IN ;; ANSWERS: 16.172.in-addr.arpa. 295906 NS RS0.INTERNIC.NET. 16.172.in-addr.arpa. 295906 NS BLACKHOLE.ISI.EDU. ;; AUTHORITY RECORDS: 16.172.in-addr.arpa. 295906 NS RS0.INTERNIC.NET. 16.172.in-addr.arpa. 295906 NS BLACKHOLE.ISI.EDU. ;; ADDITIONAL RECORDS: RS0.INTERNIC.NET. 43877 A 198.41.0.5 BLACKHOLE.ISI.EDU. 25946 A 128.9.64.26 ;; Total query time: 427 msec ;; FROM: tools.bbnplanet.com to SERVER: blackhole.isi.edu 128.9.64.26 ;; WHEN: Fri Apr 3 09:39:09 1998 ;; MSG SIZE sent: 37 rcvd: 158 tools:~#63% dig -x 172.16 any @ns2.internic.net ; <<>> DiG 2.1 <<>> -x any @ns2.internic.net ; (1 server found) ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10 ;; flags: qr rd; Ques: 1, Ans: 4, Auth: 0, Addit: 2 ;; QUESTIONS: ;; 16.172.in-addr.arpa, type = ANY, class = IN ;; ANSWERS: 16.172.in-addr.arpa. 86400 NS NS.ISI.EDU. 16.172.in-addr.arpa. 86400 NS rs0.internic.net. 16.172.in-addr.arpa. 86400 NS ORB.ISI.EDU. 16.172.in-addr.arpa. 86400 SOA NS.ISI.EDU. bmanning.zed.ISI.EDU. ( 19941005 ; serial 10800 ; refresh (3 hours) 900 ; retry (15 mins) 604800 ; expire (7 days) 86400 ) ; minimum (1 day) ;; ADDITIONAL RECORDS: NS.ISI.EDU. 172800 A 128.9.128.127 rs0.internic.net. 172800 A 198.41.0.5 ;; Total query time: 60 msec ;; FROM: tools.bbnplanet.com to SERVER: ns2.internic.net 198.41.0.11 ;; WHEN: Fri Apr 3 09:39:27 1998 ;; MSG SIZE sent: 37 rcvd: 190 -- Barry Margolin, barmar(a)bbnplanet.com GTE Internetworking, Powered by BBN, Cambridge, MA

3 3

AT&T DSNOC status
by Rob M VanHooren 16 Apr '98

16 Apr '98

FYI, status on AT&T F/R can be had at +1 732 885-7791, option 2. (But I bet you already knew that...) --R. PS: Interesting, it also lists med-sev tickets on 4 nodes, effective at exactly midnight tonight. All CA-80 gear, too (Cisco/Strata?). If you can decipher Bellcore's CLLI/CLEI conventions from memory better than I can, my guess is you'll find the original nodes that freaked out. Anybody around have a copy of Bellcore's DERG, LIDB-LARG, GEL, or other TRA tables on CD-ROM they'll let me have a peek through? I'd buy them myself, but I'm too poor (and too cheap - heheheh). ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-.._..-*~ Rob M. VanHooren - Chief Plumber, +1 519 679-1155 x33 Packet Pusher, and Resident Mad Scientist(tm) Alarms to 646-4724 Network Engineering Services 171 Queens Avenue, Suite 320 Linkdata Communications Inc. London, CANADA

1 0

NANOG 13 REGISTRATION
by Pam Ciesla 15 Apr '98

15 Apr '98

Our Registration Webpage was acting alittle strange, we have since corrected the problem. Please check the Attendee list if you have registered and are not on the list please re-register. Thanks, sorry for the inconvenience. Attendee list update at 10:30AM EDT 4/15. xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 734-936-0172 - phone Merit Network, Inc. 734-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

whois server for CA domain (fwd)
by Michael Dillon 15 Apr '98

15 Apr '98

-------- forwarded message --------- From John Demco: Subject: whois server for CA domain fyi.... (Might be interesting in particular to ISPs.) There is now a whois server for the CA domain available at whois.cdnnet.ca. Typical command-line usage would be something like: whois -h whois.cdnnet.ca some-name.ca I'd like to thank to Richard Sexton, Ed Hew, and others for their suggestions and help. --John

2 1

Re: SMURF amplifier block list
by sob＠academ.com 15 Apr '98

15 Apr '98

> As far as .0 and .255 addresses go, I'm no more "asking for trouble" by > using those than I'm asking for trouble by running an IRC server. They > are completely valid addresses. Perhaps those making such comments are > better at getting IP space than we are, but we need to squeeze every IP we > possibly can into use just to provide enough addresses to our customers. Actually, in the old classful days, you were probably asking for trouble to use those addresses. Today, when everyone is running fully classless IP stacks (everyone is doing that, right?), they should be usable. However, I'd personally avoid them for any host that might have to get regular access to other parts of the Internet (those parts that might still be running really old stacks). You can probably insure they will work inside your network, but you may not be able to guarantee they will work elsewhere. -- Stan | Academ Consulting Services |internet: sob(a)academ.com Olan | For more info on academ, see this |uucp: mcsun!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.

1 0

Re: SMURF amplifier block list - READ THIS
by Joe Provo - Network Architect 15 Apr '98

15 Apr '98

[snip] > What we were talking about was forbidding external connections to the > class-C broadcast addresses on a net, and why that useful process made > addressing hosts on .255 boundaries A Bad Idea. You misspelled "useless process". I also think you dropped the final phrase "if you want to talk to my network." [many previous posts in previous discussion on the topic omitted here. see the archives.] Assuming someone else's topology is stupid; we have dynamic protocols to tell our gear things for good reason. you want a dynamic process? get your head out of the cisco rut: use your rbl-like bgp sessions between gated boxen that then squirt the updates into ACLs. feed these ACLs into your configuration update method (if you have one). That one was free. Cheers, Joe

1 0

Re: AT&T outage (was: the whole world disappeared)
by Sean Donelan 14 Apr '98

14 Apr '98

>Well, it's made the news, at least: > >http://www.wired.com/news/news/technology/story/11648.html >http://www.news.com/News/Item/0,4,21061,00.html?st.ne.fd.mdh AT&T has finally put some press releases up on its web page http://www.att.com. Unfortunately, the 1-800 number AT&T lists to hear the chairman's explaination is experiencing heavy calling volume, so I haven't been able to get through. The press release was delayed long enough to miss most of the deadlines for this morning's newspapers. But those reporters are sure going to be mad in tomorrow's editions. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Re: SMURF amplifier block list
by Jeff Weisberg 14 Apr '98

14 Apr '98

| | Then again, filtering any packets to or from x.x.x.255 would have a | similar but more profound effect. Anyone who actually uses a .255 | address for a host is asking for trouble anyways. around here, we use 'em (.0 too). 'course ARIN makes me justify my utilization before they give me more, so I try to use addresses as efficiently as possible. do others not have this constraint? --jeff ---- Dear Mr. Arin, Thank you for the addresses you gave me previously. I now need more. I have efficiently used the ones you gave me. Sort of. I skipped over addresses ending with .0 and .255. Oh, and those ending in .13 too. Thank you, Mr. Isp Guy

1 0

Re: the whole world disappeared?
by Sean Donelan 14 Apr '98

14 Apr '98

> All AT&T InterSpan North American frame services are down. Our 200 > site WAN just went dark. No ETA for repair. I'm starting to feel jinxed. Two months ago Worldcom was in the office explaining how wonderful their network was, a few days later they lost most of their west coast connectivity. Last month SPRINT was in the office explaining how wonderful their network was, that weekend the Sprint network suffers software upgrade meltdown. This afternoon AT&T was in the office explaining how wonderful their network was, and tonight the AT&T network falls over. I think the only thing saving MCI is their salesperson hasn't been able to tell me how wonderful their network is. Anyone else care to try their luck and schedule an appointment to tell me how wonderfull their network is :-) To keep Randy from yelling at me, I am working on a protocol for reporting alerting users to network and other failures. I've decided no one will implement management guidelines, so lets write some software. And someday you may even be able to configure your Cisco, Ascend, etc to grok the protocol. I think it would be a cool addition to lucky IOS release 13. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

9 8

Re: SMURF amplifier block list
by kline＠uiuc.edu 14 Apr '98

14 Apr '98

> there have been several documented problems over the years with using > these addresses with certain OSes, and it's fairly sure that they will > continue to have problems. One can also make a reasonable case that > it's worth the administrative benefits to not use these addresses. The only subset of documented problems I'd agree with is trying to supernet class C's into larger blocks. But that wasn't what I was talking about. It's a shame that we went through so much trouble to remove classfulness and artificial byte boundaries in address space only to have them be reinserted and carried forth forever with ad hoc policy like this. I understand your point about tradeoffs of administrative benefits, but in this case it seems particularly ill-advised to promulgate brain- damage and justify it by saying "well, broken hosts didn't get fixed fast enough, so we may as well continue the tradition." /cvk

1 0