- Test - lists.nanog.org

RE: Homeland Security Alert System
by St. Clair, James 24 Feb '03

24 Feb '03

..Once again, reason to pursue getting involved with the Telecomm ISAC. Jim -----Original Message----- From: Sean Donelan [mailto:sean@donelan.com] Sent: Saturday, February 22, 2003 6:47 PM To: nanog(a)merit.edu Subject: Re: Homeland Security Alert System I'm certain the government folks working to protect us 24x7 are doing everything they can, but the fact of the matter is the public alert systems in the US suck. Some just suck less. http://www.nj.com/news/gloucester/index.ssf?/base/news-0/104590500555170.xml "Butts said he often finds out about things like the change in the national threat level on CNN hours before the Communications Center receives a teletype about it." Butts is the Gloucester County Emergency Response Coordinator including the county 9-1-1 communications center. ISPs and other communication providers should be prepared to share information directly and quickly with each other. If you wait to hear from government officials to decide what sanitized information to share, it will be hours later. If ever.

2 1

scripts to map IP to AS?
by William Allen Simpson 24 Feb '03

24 Feb '03

Anybody have a pointer to scripts to map IP to AS? There are still 10K-20K hosts spewing M$SQL slammer/sapphire packets, and I'd like to start blocking routing to those irresponsible AS's that haven't blocked their miscreant customers. http://isc.sans.org/port_details.html?port=1434 -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

21 32

Re: 223.255.255.0/24 (fwd)
by Sean Donelan 24 Feb '03

24 Feb '03

RFC3330 issued in September 2002 does indicate that this address block is subject to future allocations. But I think people were expecting something from the IAB/IETF before IANA actually allocated previous special use reserved address blocks. My understanding was RFC3330 was written by IANA and published by IANA to document existing practices, not to change previous practices. Eventually we'll use it. The simpliest solution is for IANA to inform APNIC that it was an oversight. The 223.255.255.0/24 network block within the 223/8 CIDR block assigned to APNIC is still IANA-RESERVED per RFC3330 and previous practice; and not allocated for APNIC's use at this time. Its probably easier for APNIC to flag the 223.255.255.0/24 network within the CIDR block 223/8 as IANA-RESERVED in the APNIC database just like ARIN does with the other IANA-RESERVED blocks in ARIN's database; rather than do the ugly CIDR block breaking of 223.0.0.0-223.255.254.255 and 223.255.255.0-223-255.255.255. But that is a decision for APNIC. On Mon, 24 Feb 2003, Geoff Huston wrote: > My interpretation of this is that the IETF, by publishing an RFC with an > "IANA Considerations" section can nominate that an address block > declared allocatable under certain criteria, or they can "reserve" the prefix. > > "reserving" in my mind constrains IANA from undertaking any activity > on this block, and this is the state until the IETF elects to produce > a successor document with an IANA Considerations section that nominates > some other status to the block. > > "Reserved" blocks in my opinion cannot be passed to RIRs, or anyone > else - the IANA cannot do anything with the block other than register its > reserved status, and this can only be undone by an action of the IETF. > > Hence, my reading of the IANA registry: > http://www.iana.org/assignments/ipv4-address-space > is that this is a flawed implementation of the instructions in RFC 3330, > and that > the 233.255.255.0/24 should be listed IDENTICALLY to 128.0.0.0/16 > > i.e. its status is actually: > 223.255.255/25 IANA - Reserved - RFC 3330 > > if the IANA is to consistently act upon RFC 3330 (as indeed it should) > > Perhaps the IETF folk on this message should review the RFC and the IANA > registry and see if they agree with this interpretation, and make their > conclusion > as to the accuracy of the registry as it is currently published: > > ("223/8 Feb 03 APNIC (whois.apnic.net)") > > My view is that this block as properly "Reserved", and that the "subject to > allocation" > is an addendum that indicates a forward intention of the IETF, but not a > capability > for any IANA action. > > As my only humble suggestion, perhaps the best thing right now is for the > APNIC folk > to refrain from any assignment actions regarding this prefix until the IETF > folk and the > IANA sort out this inconsistency in the interpretation of RFC 3330. > > Geoff > > > > >Date: Mon, 24 Feb 2003 00:32:47 -0500 (EST) > >From: Sean Donelan <> > >To: > >Cc: > >Subject: Re: 223.255.255.0/24 > > > >On Sun, 23 Feb 2003 bmanning(a)karoshi.com wrote: > > > why would an APNIC/AP region specific issue need to be discussed > > > on the NANOG list and not the RIPE/AFNOG/et.al. regional ops lists? > > > This is a prefix delegated to the APregion and so they should be > > > the ones who set the policies for the prefixes they are responsible > > > for. I appreciate their willingness to share the outcome of their > > > deliberations, but why NAites have any special say in AP policies > > > is a bit beyond me. > > > >The question is really whether IANA properly implemented the relevant > >RFC's by delagating a block containing a reserved special use address to a > >registry without maintaining the previous reservations on those addresses. > > > >Its not up to APNIC how to handle the reserved special use addresses, just > >like the other special use addresses in ARIN's space are really outside > >of ARIN's scope. ARIN can't re-assign special use addresses in "its" > >space for other purposes. Nor should APNIC or RIPE or LANIC or any other > >registry which is assigned a /8 block containing special use addresses. > > > >Its not APNIC bashing. If the ARIN board got to gether and decided to > >assign 128.0.0.0/16 I think folks would be raising questions about ARIN. > > > >IANA should have properly excluded the IANA reserved special use block > >from the delegation to APNIC, just like the other reserved special use > >blocks are reserved from ARIN's use. > > > >

1 0

ot/wan simulation devices
by Tomas Daniska 24 Feb '03

24 Feb '03

hello, is anyone willing to share their experience with adtran atlas 550 simulation boxes? please reply off-list, i'll summarise thanks -- Tomas Daniska systems engineer Tronet Computer Networks Plynarenska 5, 829 75 Bratislava, Slovakia tel: +421 2 58224111, fax: +421 2 58224199 A transistor protected by a fast-acting fuse will protect the fuse by blowing first.

1 0

Re: untied (fwd)
by Christopher L. Morrow 24 Feb '03

24 Feb '03

fwd per request... (I'm not sure how to contact united, though I'd guess PNAP/InterNap might know, since I see the fictional www.united.com through there) ---------- Forwarded message ---------- Date: Mon, 24 Feb 2003 14:36:00 +0900 From: Randy Bush <randy(a)psg.com> To: Christopher L. Morrow <chris(a)UU.NET> Subject: Re: untied bingo!! so, please post to nanog and if you know how to get to untied, ... > So, looks like: > > dig www.united.com > > returns: > > dig www.united.com > > ; <<>> DiG 8.1 <<>> www.united.com > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUERY SECTION: > ;; www.united.com, type = A, class = IN > > ;; ANSWER SECTION: > www.united.com. 5S IN A 64.95.89.8 > > ;; Total query time: 32 msec > ;; FROM: sharpie.argfrp.us.uu.net to SERVER: default -- 153.39.56.91 > ;; WHEN: Mon Feb 24 05:22:35 2003 > ;; MSG SIZE sent: 32 rcvd: 48 > > then: > > dig www.united.com > > ; <<>> DiG 8.1 <<>> www.united.com > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 13 > ;; QUERY SECTION: > ;; www.united.com, type = A, class = IN > > ;; ANSWER SECTION: > www.united.com. 4S IN A 64.95.89.8 > > ;; AUTHORITY SECTION: > COM. 1d20h32m39s IN NS A.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS G.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS H.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS C.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS I.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS B.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS D.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS L.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS F.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS J.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS K.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS E.GTLD-SERVERS.NET. > COM. 1d20h32m39s IN NS M.GTLD-SERVERS.NET. > > ;; ADDITIONAL SECTION: > A.GTLD-SERVERS.NET. 4d20h43m26s IN A 192.5.6.30 > G.GTLD-SERVERS.NET. 21h40m30s IN A 192.42.93.30 > H.GTLD-SERVERS.NET. 21h40m30s IN A 192.54.112.30 > C.GTLD-SERVERS.NET. 21h40m30s IN A 192.26.92.30 > I.GTLD-SERVERS.NET. 21h40m30s IN A 192.43.172.30 > B.GTLD-SERVERS.NET. 21h11m25s IN A 192.33.14.30 > D.GTLD-SERVERS.NET. 21h31m38s IN A 192.31.80.30 > L.GTLD-SERVERS.NET. 5h52m10s IN A 192.41.162.30 > F.GTLD-SERVERS.NET. 21h40m30s IN A 192.35.51.30 > J.GTLD-SERVERS.NET. 7h42m59s IN A 192.48.79.30 > K.GTLD-SERVERS.NET. 7h43m IN A 192.52.178.30 > E.GTLD-SERVERS.NET. 10h26m34s IN A 192.12.94.30 > M.GTLD-SERVERS.NET. 23h34m11s IN A 192.55.83.30 > > ;; Total query time: 10 msec > ;; FROM: sharpie.argfrp.us.uu.net to SERVER: default -- 153.39.56.91 > ;; WHEN: Mon Feb 24 05:22:36 2003 > ;; MSG SIZE sent: 32 rcvd: 483 > > > and that repeats over and over and over... HOWEVER, > > dig NS united.com > > ; <<>> DiG 8.1 <<>> NS united.com > ;; res options: init recurs defnam dnsrch > ;; got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2 > ;; QUERY SECTION: > ;; united.com, type = NS, class = IN > > ;; ANSWER SECTION: > united.com. 23h59m52s IN NS dns01.uls-prod.com. > united.com. 23h59m52s IN NS dns02.uls-prod.com. > > ;; ADDITIONAL SECTION: > dns01.uls-prod.com. 1d11h2m40s IN A 64.95.89.200 > dns02.uls-prod.com. 1d11h2m40s IN A 64.95.88.200 > > ;; Total query time: 1 msec > ;; FROM: sharpie.argfrp.us.uu.net to SERVER: default -- 153.39.56.91 > ;; WHEN: Mon Feb 24 05:22:51 2003 > ;; MSG SIZE sent: 28 rcvd: 112 > > and then querying from one of them direct gets: > > timeouts for: 64.95.89.200 and 64.95.88.200 > > So, their DNS is busted it seems :( bummer for them. (or was this not what > you were seeing?) > > > > --Chris > (chris(a)uu.net) > ####################################################### > ## UUNET Technologies, Inc. ## > ## Manager ## > ## Customer Router Security Engineering Team ## > ## (W)703-886-3823 (C)703-338-7319 ## > ####################################################### > > On Mon, 24 Feb 2003, Randy Bush wrote: > > > > > could someone else please check the dns for www.united.com? the servers > > for united.com seem to delegate www.united.com, but the delegatee seems > > not to return an soa. i get very confusing results. > > > > randy, feeling stoopid > > >

1 0

Re: untied
by Randy Bush 24 Feb '03

24 Feb '03

> btw, when querying bind9 and requesting > 'any www.united.com', i get servfail, but when requesting > 'A www.united.com', i do get a response. that is the reaction to their misconfiguration. i am in a dual-stack universe over here (iij/tokyo). so the browser, looking for an A or AAAA, probably issues a query for ANY. united's dns is sorely broken. anyone know how to get their attention. i can't email to postmaster@... for the same reason. randy

1 0

223.255.255.0/24
by bdragon＠gweep.net 24 Feb '03

24 Feb '03

223.255.255.0/24 has historically been designated as a special-use network as it is the numerically highest Class C network. It is listed in RFC3330 as Reserved but open for possible future allocation. Now that 222/7 has been allocated to APNIC, the question comes up as to whether it is retaining the Reserved designation, or whether APNIC will keep it as reserved. I note that the APNIC whois servers do not denote it as Reserved. I bring this up since many bogon filters include this network for both routing and packet filtering. I have queries out to both APNIC and IANA as to the present status of that network, but I expect IANA will likely defer to APNIC. If it is no longer reserved, I've suggested that RFC3330 be updated to reflect its present status (such as prior-special-use networks are listed). In any event, pending confirmation from APNIC, I suggest folks look over their own bogon filtering. A quick check of Rob's list doesn't have this network specified. I believe that Juniper has a prebuilt bogon list, but I don't recall whether this network is on it or not. I've suggested APNIC send out email to the operations community, but if they don't, I'll send an update with whatever they send me.

7 7

RE: ENUM/E.164 books
by Irwin Lazar 23 Feb '03

23 Feb '03

I've put some ENUM resources on http://www.itprc.com/tcp_ip.htm Irwin -----Original Message----- From: Pete Kruckenberg [mailto:pete@kruckenberg.com] Sent: Saturday, February 22, 2003 11:08 PM To: nanog(a)nanog.org Subject: ENUM/E.164 books Anyone have recommendations on good books (or similar resources) on ENUM/E.164 for education, planning, design, implementation and/or operation? Pete.

1 0

Re: Homeland Security Alert System
by Martin Hannigan 23 Feb '03

23 Feb '03

9 12

ENUM/E.164 books
by Pete Kruckenberg 23 Feb '03

23 Feb '03

Anyone have recommendations on good books (or similar resources) on ENUM/E.164 for education, planning, design, implementation and/or operation? Pete.

1 0