- Test - lists.nanog.org

IPv6 in a current defaultless SFP ISP
by John Dupuy 08 Nov '05

08 Nov '05

I am currently tasked with upgrading our network to a dual-stack IPv4/IPv6 architecture. At the beginning of this project, I assumed the difficult part would be with the router upgrades, programming, etc. So far, that has been the easy part. Does anyone know of _any_ defaultless SFP providers (a.k.a. Tier 1) that support dual-stack IPv4/IPv6 BGP sessions? We currently have three transit connections for IPv4 (all to Tier 1 providers). "upgrading" those to IPv4/IPv6 doesn't appear possible as those three providers tell me they can't do IPv6 yet. Given our growth rate, it is quite possible we will need another transit DS3 in less than a year. If I can find a transit provider with IPv6 in St. Louis/Kansas City, that may decide our next choice. To avoid vendor wars on the list, please send vendor recommendations directly to me. John

1 0

Networking Pearl Harbor in the Making
by J. Oquendo 08 Nov '05

08 Nov '05

< CRAPAGANDA > Which operating system, embedded in more than 80% of enterprise IT environments, represents one of the fastest-growing hacker targets and potentially the most-devastating information-security vulnerability? Hint: It ain't Windows. Cisco Systems' Internetwork Operating System now sits at the center of the information security vortex. Because IOS controls the routers that underpin most business networks as well as the Internet, anyone exploiting its flaws stands to wreak havoc on those networks and maybe even reach into the computer systems and databases connected to them. IOS is a highly sophisticated piece of software, but--as with Microsoft's Windows--that's a double-edged proposition. Software complexity can be a hacker's best friend. http://www.informationweek.com/story/showArticle.jhtml?articleID=173402976&… EOC =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo GPG Key ID 0x97B43D89 http://mo.fscker.com :: Obscurity through Insecurity "How can we account for our present situation unless we believe that men high in this government are concerting to deliver us to disaster?" Joseph McCarthy "America's Retreat from Victory"

11 11

MEDIA: Grokster shuts down
by william(at)elan.net 08 Nov '05

08 Nov '05

http://www.latimes.com/business/la-110705grokster_lat,0,4450717.story? coll=la-home-headlines Grokster Ltd. today shut down its online file sharing service to settle an entertainment industry lawsuit aimed at stopping illegal downloads of copyrighted music, movies and other programming. The settlement was announced by the Recording Industry Association of America and comes four months after the Supreme Court ruled that online file-sharing services such as Grokster can be held liable for copyright violations by their users. On its website, Grokster, which was the defendant in a lawsuit, notified visitors of the Supreme Court decision and plans to offer a legal service soon. ...The RIAA said the settlement, which prohibits Grokster from operating or distributing its file-sharing software, will be submitted to court today for approval. "This settlement brings to a close an incredibly significant chapter in the story of digital music," said RIAA Chairman Mitch Bainwol in a statement. ...The battle over file sharing began in 1999, when the original Napster network made it simple for people to copy songs for free from each other's computers. ...After Napster's demise, millions of users flocked to a new generation of file-sharing programs distributed by Grokster, StreamCast and numerous other companies. ...To the major music companies and Hollywood studios, this was doubly offensive -- not only were the companies helping people copy songs and movies for free, they also were milking advertisers for access to a huge audience of infringers. With Metro-Goldwyn-Mayer Studios as the lead plaintiff, the major record labels, movie studios and music publishers sued StreamCast and Grokster for copyright infringement in October 2001.

1 0

RE: Networking Pearl Harbor in the Making
by Robert Bonomi 07 Nov '05

07 Nov '05

> Subject: RE: Networking Pearl Harbor in the Making > Date: Mon, 7 Nov 2005 11:11:52 -0500 > From: "Hannigan, Martin" <hannigan(a)verisign.com> > > > > On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote: > > > > > > It's an argument for vendor diversity. > > > > No it is an argument for code base diversity (or better > > software engineering). > > > > Vendor diversity doesn't necessarily give you this, and you > > can get this with > > one vendor. > > How so? Haven't we recently seen an across the board bug in > multiple version of $vendor code? Excerpt from "Logic 101 -- Introductory Logical Reasoning": "Can" does not mean the same thing as "will". And, thus, the fact that one vendor has an across-the-board bug does _not_ mean that the same situation exists at =all= vendors.. The bug in multiple versions ov $vendor's code was directly attributable to those 'multiple versions' all being derived (at different points in time, and/or for different deployment niches) from the same primary 'code base'. Note: "code base", *singular*. The problem existed in the core code, so, naturally, it was present in all the varients of that *single* core. > > > > > Vendor diversity might be a good idea, but for other reasons. > > Sure. There are more reasons than one to do it. I was specifically > pointing out that code diversity is a good one - and not forgetting > associated cost and economic impacts as mentioned in a later followup. Vendor diversity does *not* _guarantee_ diversity in code-base. You have to *explicitly* spec/check/test for code-base diversity, to ensure that you have code-base diversity. It is _possible_ to get code-base diversity with multiple purchases from a single manufacturer/vendor. It is _possible_ to have a single common code-base among purchases from disparate manufacturers/vendors. The "probability" of getting things with different code-bases -- *without* *actually*checking*for*it* -- is higher if you purchase from multiple manufacturers/vendors, rather than from a single one. "Higher probability" != "guaranteed" Hence the need to explicitly check, if said diversity is a requirement.

1 0

RE: Using BGP to force inbound and outbound routing through particular routes
by Hannigan, Martin 07 Nov '05

07 Nov '05

What's the netblock and ASN you already have? > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Edward W. Ray > Sent: Wednesday, November 02, 2005 2:50 PM > To: nanog(a)merit.edu > Subject: Using BGP to force inbound and outbound routing through > particular routes > > > > spam was a lousy name... > > -----Original Message----- > From: spam [mailto:spamjail@mmicman.com] > Sent: Wednesday, November 02, 2005 11:44 AM > To: 'nanog(a)merit.edu' > Subject: FW: Using BGP to force inbound and outbound routing through > particular routes > > I recently made a request to get a cable modem connection at > my home. I > went for one of those $29.95 for three month specials in case > I run afoul of > some rules prohibiting what I am going to do. I already have > a multi-T1 > connection with a Class C block and BGP running on my Cisco > 3640 router, and > was looking to become multi-homed. The cable connection is > via bridge/DHCP > cable modem, and was going to hook it up to the Cisco 3640. > I have already > done the research and know from what block of IP addresses I will be > assigned, and the BGP route tables/peers. > > I would like to use BGP to force inbound and outbound routing > only through > particular peers, Sprint (AS 1239) and UUNET (AS 701). I > have been reading > "Practical BGP" by Whate, McPherson and Sangli and this appears to be > possible. However, do my adjacent routers need to support > BGP in order for > this to work? Could I use other routing protocols to > accomplish this, or > would this require knowledge of all possible downstream > router IP addresses? > > Edward W. Ray > > >

25 46

It's Not the Frequencies, Stupid
by Sean Donelan 07 Nov '05

07 Nov '05

http://www.tvtechnology.com/features/Masked-Engineer/f_mario_orazio-10.19.0… Katrina communications problems were caused by downed towers, power loss, broken connections, drained batteries, missing generators, and equipment underwater. Pick one or more. They were not caused by a lack of access to frequencies used for analog TV.

1 0

LA Meeting Stats
by Susan Harris 07 Nov '05

07 Nov '05

NANOG 35 October 23-35, 2005 Los Angeles Host: Equinix ---------------------- Many thanks to Equinix, our new Steering/Program committees, and all of you for making this such a great meeting! ------------------------------------------------------------------------ Total attendance 515 Women attendees 9% NAPs represented 11 (5 outside N. America) Univ./Colleges repr. 19 (up from 13 in Seattle) Non-US/Canada/Mexico attendees 65 (up from 19 in Seattle) Attendee occupation breakdown: Vegas Seattle LA ----- ------- --- ISPs/NetOps 44% 50% 42% Hardware vendors 20% 15% 13% Software vendors 3% 4% 3% R&E 11% 9% 10% Government 4% 3% 3% Consultant 4% 3% 3% Content provider 3% 4% 4% Other 11% 12% 22% (IXPs, registries, misc.) Wireless card loans: 5 Maximum RealMedia streaming participants: 70 Support: Meeting coordination: -Merit Network Host: -Equinix Squid, DNS, DHCP: -Measurement Factory Multicast, v6 feed: -Merit Sponsors: -Arbor, Cariden, Cisco, Cloudshield, Foundry Force10, Juniper, Nominum, Packet Design QOSmetrics, Redback, Sandstorm, Tellabs, Wilshire Connection, XKL, and many transit/peering sponsors

1 0

Re: Networking Pearl Harbor in the Making
by Sam Crooks 07 Nov '05

07 Nov '05

I agree... Harvard architecture anyone? On Mon, 2005-11-07 at 11:39 -0600, James Baldwin wrote: > > On Nov 7, 2005, at 10:21 AM, Eric Gauthier wrote: > > > This latter case is what worries me since it implies > > that there is a fundamental problem in IOS, the problem still > > exists even after > > patching, and that Cisco can't readily repair it. > > I would postulate that this is a fundamental problem in how machines > represent and execute code. > > --- > James Baldwin > "Tolerance is for the insincere" > > > CONFIDENTIALITY NOTICE: This message, and any attachments, are intended only for the lawful and specified use of the individual or entity to which it is addressed and may contain information that is privileged, confidential or exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are STRICTLY PROHIBITED from disclosing, printing, storing, disseminating, distributing or copying this communication, or admitting to take any action relying thereon, and doing so may be unlawful. It should be noted that any use of this communication outside of the intended and specified use as designated by the sender, may be unlawful. If you have received this in error, please immediately notify us by return e-mail, fax and/or telephone, and destroy this original transmission and its attachments without reading or saving in any manner.

2 1

RE: Networking Pearl Harbor in the Making
by Hannigan, Martin 07 Nov '05

07 Nov '05

> On Monday 07 Nov 2005 3:42 pm, Hannigan, Martin wrote: > > > > It's an argument for vendor diversity. > > No it is an argument for code base diversity (or better > software engineering). > > Vendor diversity doesn't necessarily give you this, and you > can get this with > one vendor. How so? Haven't we recently seen an across the board bug in multiple version of $vendor code? > > Vendor diversity might be a good idea, but for other reasons. Sure. There are more reasons than one to do it. I was specifically pointing out that code diversity is a good one - and not forgetting associated cost and economic impacts as mentioned in a later followup. -M<

4 4

ALLTEL NOC
by Bob Collie 07 Nov '05

07 Nov '05

Will someone from the Alltel NOC contact me off-list. Your NOC number is not listed on puck, nor do your front end helpdesk-ites or main switchboard folks know how to contact you. Thanks, -Bob -- Bob Collie Education Networks of America, Inc. (ENA) p: +1 615 312-6004 or +1 317 612-2883 f: +1 615 250-0535

1 0