- NANOG - lists.nanog.org

ATT CDPD
by Ronald W. Jean 11 Jul '05

11 Jul '05

Can anyone tell me the status of CDPD in the ATT network? Thanks RonJ

5 6

fuel tanks at 60 Hudson draw community concerns
by Steven M. Bellovin 11 Jul '05

11 Jul '05

http://www.nytimes.com/2005/07/11/nyregion/11fuel.html? Building's Extra Fuel Tanks Raise Concerns in TriBeCa By JENNIFER MEDINA Published: July 11, 2005 Saying that a dangerous amount of diesel fuel is stored in a 25-story building in TriBeCa, elected officials and residents called on Mayor Michael R. Bloomberg yesterday to rescind a variance that permits its storage. The fuel, they warned, could lead to a major fire if there were a terrorist attack or other disaster. The city's Department of Buildings granted a variance to the owners of the tower at 60 Hudson Street late last month, allowing the owners to store 80,000 gallons of diesel fuel, much of it below - but some actually in - the building. ... --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

1 0

Opentransit IPv6 route-server
by German Martinez 11 Jul '05

11 Jul '05

Hello, Just to let you know that our route-server is now IPv6 capable. Feel free to provide any comments/suggestions: telnet://route-server.opentransit.net Thanks! German

1 0

Re: Yahoo and Cisco to submit e-mail ID spec to IETF
by Fergie (Paul Ferguson) 11 Jul '05

11 Jul '05

Okay: "...two other methods for e-mail authentication have been approved by the IESG for publication as "experimental" RFC's..." Mea culpa, - ferg -- "william(at)elan.net" <william(a)elan.net> wrote: > p.s. Of course, this development comes on the heels of two > other methods for e-mail authentication already published > by the IETF as "experimental" RFC's: "Sender Policy Framework > (SPF) for Authorizing Use of Domains in E-Mail" and Microsoft's > "Sender ID: Authenticating E-Mail". That is false information. They have not been published as "experimental" RFCs, only approved for publication. Publication may come later and yet may not happen at all. -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(a)netzero.net or fergdawg(a)sbcglobal.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0

FW: DNS .US outage
by Church, Chuck 11 Jul '05

11 Jul '05

Guess I wasn't going crazy. Forwarded to me by a read-only lister. Might be worth trying if prob still exists for anyone. Chuck Church Lead Design Engineer CCIE #8776, MCNE, MCSE Netco Government Services - Design & Implementation 1210 N. Parker Rd. Greenville, SC 29609 Home office: 864-335-9473 Cell: 703-819-3495 cchurch(a)netcogov.com PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D -----Original Message----- From: Mark Moseley [mailto:moseleymark@gmail.com] Sent: Friday, July 08, 2005 7:17 PM To: Church, Chuck Subject: Re: DNS .US outage Hi. I don't have 'write' access to the nanog group so I'm writing you directly. I saw the exact same behaviour. After some banging-head-against-wall at 3am, I noticed that if I turned *off* "query-source * port 53" in Bind (i.e. it was using port 53 as the source port for queries to make firewalling easier), it magically started working again. Don't know if you're using Bind or Windows DNS, but all I could tell is that when Bind was configured to query *from* port 53, I couldn't get the .us TLDs to answer me, but when using a random ephemeral port (of named's choice), it worked just fine. I don't know if they are (or were, haven't check since then) blocking queries with a source port of 53, but whatever the case it worked for some reason. If this works for you, please feel free to re-post to nanog (unless of course, the outage has gone away and they've fixed their stuff over at the .us TLD servers). One thing to note is that when you use dig or nslookup or whatever, it'll also be using some ephemeral port, so it'll work, even when the lookups from source port 53 wouldn't. Again, I haven't checked since that night to see if that's gone away, so it might be a moot point now. On 7/6/05, Church, Chuck <cchurch(a)netcogov.com> wrote: > > Anyone else having issues with .US right now (~12AM EST)? NSlookup, etc > show various .us destinations as unknown domains... > > > Chuck Church > Lead Design Engineer > CCIE #8776, MCNE, MCSE > Netco Government Services - Design & Implementation Team > 1210 N. Parker Rd. > Greenville, SC 29609 > Home office: 864-335-9473 > Cell: 703-819-3495 > cchurch(a)netcogov.com > PGP key: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x4371A48D >

2 1

London incidents
by Neil J. McRae 11 Jul '05

11 Jul '05

A number of explosion incidents have happened in London affecting the tube causing website and mobile phone saturation and some localised issues with the PSTN. From here we are able to route calls ok and networks seems a little busier, The BBC and Sky TV websites are very busy. Regards, Neil.

6 5

Anyone alive at Sprint Abuse?
by Mike Lyon 11 Jul '05

11 Jul '05

Is there anyone on this list from Sprint Abuse or does anyone have a human contact over there? One of their customers is port scanning one of my customers (who also happens to be a Sprint customer...) and e-mails to abuse(a)sprint.net have gone unanswered. Anyhelp would be appreciated. Thanks, Mike Lyon

1 0

EP.NET 198.32.0.0/16 assignments and bogon filters
by Joe Abley 11 Jul '05

11 Jul '05

Since I've just run into the second of these in as many weeks, I thought this was perhaps worth a mail to the list. EP.NET assign netblocks from 198.32/16 to various Internet infrastructure providers, including exchange points and prominent (e.g. ccTLD) nameservers. And maybe other things, for all I know, ask Bill, but definitely not just for exchange points. I realise that answers from the usual whois servers in response to questions within this netblock may not make this obvious. Many ISPs have import policies which reject exchange point blocks from external peers, for which there are many fine and logical arguments. Several of those ISPs reject "198.32.0.0/16 le 24" as part of that policy, however, believing that 198.32.0.0/16 is only used for exchange point assignments. 198.32.0.0/16 is used for other things, too. Not just exchange points. People who need to block exchange point blocks in their import policy would do well to enumerate the specific subnets of 198.32.0.0/16 which are used at exchange points they connect to, rather than denying all routes covered by the /16. Examples of nameservers that fall victim to over-zealous filtering of 198.32/16 assignments are as follows (these are just those present as glue in the root zone): [jabley@halibut]% dig @192.5.5.241 . axfr | grep 198.32 NS1.DNS.AQ. 172800 IN A 198.32.71.12 MZIZI.KENIC.OR.KE. 172800 IN A 198.32.67.9 FLAG.EP.NET. 172800 IN A 198.32.4.13 L.ROOT-SERVERS.NET. 3600000 IN A 198.32.64.12 NS1.2DAY.CO.NZ. 172800 IN A 198.32.66.12 [jabley@halibut]% If you can't traceroute to those nameservers, it would be great if you could patch up your import filters so that they become reachable to your users and customers. [ISC doesn't use any EP.NET netblocks, but we have friends who do.]

2 1

Re: OMB: IPv6 by June 2008
by Alexei Roudnev 10 Jul '05

10 Jul '05

LC can hold only 20,000 ACTIVE routes., and ask central system if it needs more., How many ACTIVE routes are used in any CORE router? 0.1% or CORE? 2% of CORE? Again, today it is not technical issue anymore. ----- Original Message ----- From: Syed Junaid Farooqi To: Christopher L. Morrow Cc: Alexei Roudnev ; NANOG ; Brad Knowles Sent: Saturday, July 09, 2005 1:02 AM Subject: Re: OMB: IPv6 by June 2008 Christopher L. Morrow wrote: randy already asked for a kibosh on the lunacy here... I agree, it'd be nice, but... On Fri, 8 Jul 2005, Alexei Roudnev wrote: You do not need to - any router have only `1 - 10% of all routing table active, and it is always possible to optimize these alghoritms. and routing vendor's haven't already done some optomizing you think? They sure have, let me explain a bit - Optimization here can be is Route table optimization, forwarding table optimization and the actual forwarding lookup paradigm. But having the best and most opitmized algorithm makes no difference if there is not enough memory on the Line Card, having said that - 1G to 2G mem is something that is already supported by a few vendors - on the Line cards and 2G and above on the Processors (route processor..?) On the other hand - what's wrong with 4Gb on line card in big core router? oh, please please name the router vendor that has 4gb of 'ram' (tcam/fpga/asic-'memory') on the 'linecard'. Oh, can't come up with one? One wonders why that is? If the solution were as simple as: "Joe, add 1.21jigawatts of memory to the linecard so we can support +1M routes" Don't you think the vendor would have done this to get people to stop bitching at them? Now, now, The RAM mentioned in terms of Gb should not be thought, even inadvertently, to have something to do with TCAM/fpga/asic - Memory here can be divided in to 1. forwarding memory , 2. Line card CPU memory, 3. TCAM memory (damn costly stuff ) And as for the number of routes to be support -Right now venodrs do support close to 500K routes - ask me to name the vendor (notice i did not say Vendors here) and i will be happy to name.But, yes to do something like 1M routes - ahem mighty tricky stuff aint it, but, does any one have 1M active routes in his table as of today (notice how iam trying to evade commenting ;) you cant haul me for saying this) It's cheap enough, even today. And we have not 1,000,000 routes yet. In YOUR network you don't... I'd venture to guess there are quite a few very large networks with +1M routes in them today. remember though, I'm the chemical engineer... and I was trained to MAKE the crack cocaine... 1M routes, BGP is hope so - and not on a single box i suppose so. come on, 1M + active routes- it sure would be a killing on the box. Chemical engineer you say, what a wonderfull world - Iam a pharmacist- fully trained to give an anitdote to cocaine addicts. CIAO

3 2

Re: The whole alternate-root ${STATE}horse
by James R. Cutler 10 Jul '05

10 Jul '05

Servers and zones are part of the physical instancing of DNS roots. The definition of the root precedes the instance. In short, the definition of a naming structure is disjoint from the delivery and usage of that structure, be it servers and zones or whatever. Regarding the separation of servers and zones, this is already common practice. BIND provides a good example of this. With BIND, one can serve an arbitrary set of zones from an arbitrary set of servers, subject to the ability to do zone transfers. So there is obvious separation. Cutler At 11:35 PM 7/9/2005, Jay R. Ashworth wrote: On Sat, Jul 09, 2005 at 06:08:25PM -0400, James R. Cutler wrote: > Actually, many naming and addressing management experts consider that > the existence of a root defines a unique namespace. The existence of a root *zone* yes. We really should separate root *servers* from *root* zones. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Designer Baylink RFC 2100 Ashworth & Associates The Things I Think '87 e24 St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274 If you can read this... thank a system administrator. Or two. --me - James R. Cutler james.cutler(a)consultant.com

1 0