From tvhawaii at shaka.com Thu Jul 1 00:41:36 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 30 Jun 2010 19:41:36 -1000 Subject: Feds disable movie piracy websites in raids Message-ID: <617ED710F19B48228B59A5F5F891060A@DELL16> As randy said not too long ago, First they came for... BURBANK, Calif. (AP) -- U.S. officials on Wednesday announced a major crackdown on movie piracy that involved disabling nine websites that were offering downloads of pirated movies in some cases hours after they appeared in theaters. Officials also seized assets from 15 bank, investment and advertising accounts, and executed residential search warrants in North Carolina, New Jersey, New York and Washington. Immigration and Customs Enforcement officials worked with the U.S. Attorney for the Southern District of New York and other government agencies. The investigation involved about 100 agents in 11 states and the Netherlands. Officials wouldn't say how many people were suspected of intellectual property theft, but said the penalties could include prison time. The raids were the first actions in a new "Operation In Our Sites" initiative to combat Internet counterfeiting and piracy. The government only seized domain names for the sites in question, however, meaning the computers that run the sites could still be used under a different name. http://www.technologyreview.com/wire/25690/?nlid=3195&a=f From patrick at ianai.net Thu Jul 1 00:43:53 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 1 Jul 2010 01:43:53 -0400 Subject: Feds disable movie piracy websites in raids In-Reply-To: <617ED710F19B48228B59A5F5F891060A@DELL16> References: <617ED710F19B48228B59A5F5F891060A@DELL16> Message-ID: On Jul 1, 2010, at 1:41 AM, Michael Painter wrote: > As randy said not too long ago, First they came for... The felons? Strangely, I am not moved to defend them. According to the article, they didn't even take the physical computers running the sites, meaning not even other users on that virtual server were harmed. Exactly what are you worried about here? -- TTFN, patrick > BURBANK, Calif. (AP) -- U.S. officials on Wednesday announced a major crackdown on movie piracy that involved disabling nine websites that were offering downloads of pirated movies in some cases hours after they appeared in theaters. > > Officials also seized assets from 15 bank, investment and advertising accounts, and executed residential search warrants in North Carolina, New Jersey, New York and Washington. > > Immigration and Customs Enforcement officials worked with the U.S. Attorney for the Southern District of New York and other government agencies. The investigation involved about 100 agents in 11 states and the Netherlands. > > Officials wouldn't say how many people were suspected of intellectual property theft, but said the penalties could include prison time. > > The raids were the first actions in a new "Operation In Our Sites" initiative to combat Internet counterfeiting and piracy. > > The government only seized domain names for the sites in question, however, meaning the computers that run the sites could still be used under a different name. > > http://www.technologyreview.com/wire/25690/?nlid=3195&a=f > From ops.lists at gmail.com Thu Jul 1 01:26:22 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 1 Jul 2010 11:56:22 +0530 Subject: Feds disable movie piracy websites in raids In-Reply-To: <617ED710F19B48228B59A5F5F891060A@DELL16> References: <617ED710F19B48228B59A5F5F891060A@DELL16> Message-ID: On Thu, Jul 1, 2010 at 11:11 AM, Michael Painter wrote: > As randy said not too long ago, First they came for... No. Not Randy. That was pastor martin neimoller about the nazis. So, you just invoked godwin's law. Thread over. thank you suresh From funkyfun at gmail.com Thu Jul 1 06:52:12 2010 From: funkyfun at gmail.com (Net) Date: Thu, 1 Jul 2010 07:52:12 -0400 Subject: XO feedback Message-ID: Hi, We're currently looking to buy transit from XO for one of our DCs. Their pricing is very competative compared to some of the other providers we've considered to date. I'm hoping to get some feedback on their services, support, peering arrangements and the overall stability of their core backbone network from folks who've had experience or currently using them. Any info would be greatly appreciated. Thanks in advance -- Sent from my mobile device From ge at linuxbox.org Thu Jul 1 07:04:27 2010 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 01 Jul 2010 15:04:27 +0300 Subject: Finland makes broadband access a legal right Message-ID: <4C2C844B.9020507@linuxbox.org> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?hpt=T2 Interesting... From LarrySheldon at cox.net Thu Jul 1 07:06:13 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 01 Jul 2010 07:06:13 -0500 Subject: Feds disable movie piracy websites in raids In-Reply-To: References: <617ED710F19B48228B59A5F5F891060A@DELL16> Message-ID: <4C2C84B5.9010006@cox.net> On 7/1/2010 00:43, Patrick W. Gilmore wrote: > On Jul 1, 2010, at 1:41 AM, Michael Painter wrote: > >> As randy said not too long ago, First they came for... > > The felons? > > Strangely, I am not moved to defend them. +1 > > According to the article, they didn't even take the physical > computers running the sites, meaning not even other users on that > virtual server were harmed. > > Exactly what are you worried about here? I really wonder where we are going with this "exalt the illegal" thing we have going. How very 1960's. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From fweimer at bfk.de Thu Jul 1 07:39:34 2010 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 01 Jul 2010 12:39:34 +0000 Subject: Feds disable movie piracy websites in raids In-Reply-To: <617ED710F19B48228B59A5F5F891060A@DELL16> (Michael Painter's message of "Wed\, 30 Jun 2010 19\:41\:36 -1000") References: <617ED710F19B48228B59A5F5F891060A@DELL16> Message-ID: <82y6dvwf3t.fsf@mid.bfk.de> * Michael Painter: > BURBANK, Calif. (AP) -- U.S. officials on Wednesday announced a major > crackdown on movie piracy that involved disabling nine websites that > were offering downloads of pirated movies in some cases hours after > they appeared in theaters. Note that some of the domain names in the ICE press release appear to be wrong (or they have already lost control of them). Targeting THEPIRATECITY.ORG and not THEPIRATEBAY.ORG is slightly ridiculous, and it seems that TVSHACK.NET has already reappeared as TVSHACK.CC. ZML.NAME is still controlled by the ZML.COM folks, but seems to have problems right now. This takedown approach might work for controllers of non-too-advanced malware, but you need something better for content which people actually want to access, and which is indexed by helpful search engines. 8-/ -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From scubacuda at gmail.com Thu Jul 1 07:45:44 2010 From: scubacuda at gmail.com (Rogelio) Date: Thu, 1 Jul 2010 05:45:44 -0700 Subject: Future of WiMax In-Reply-To: <91522911795E174F97E7EF8B792A1031229183@ltiserver.LTI.local> References: <4C192774.1050501@rollernet.us> <91522911795E174F97E7EF8B792A1031229183@ltiserver.LTI.local> Message-ID: On Thu, Jun 17, 2010 at 6:46 AM, Dennis Burgess wrote: > Just what is going on in the WISP industry for the most part. ?802.11n > so far on point-2-point links, are working quite well, cheap hardware as > well as ease of use is playing factors in this. ?We are seeing 10+ mile > N links running 60-70 meg TCP and over 200 UDP using only 2x2 MIMO. While WiMAX is often poopoo'd by the WISP community (for good reason, IMO), it often finds its niche in the federal and muni space, particularly when video is involved. Wi-Fi is indeed cheaper on the unlicensed bands, but as a protocol that determines who speaks and how much they speak, Wi-Fi is very loosey goosey (CSMA/CA, or "listen before talk"). This sort of protocol works great when there are tons of laptops and you don't really care who gets priority (unless they're video, and their traffic is tagged WMM QoS or something). But when networks are really *really* REALLY important, you want much tighter traffic engineering options (and are willing to pay a premium to do it). For these sorts of networks, quality of link is more important than quantity of throughput (which is highly variable in unlicensed Wi-Fi networks). Others thoughts on this? From scubacuda at gmail.com Thu Jul 1 07:54:54 2010 From: scubacuda at gmail.com (Rogelio) Date: Thu, 1 Jul 2010 05:54:54 -0700 Subject: LTE for CCTV projects? Message-ID: A friend of mine works for a physical security company, and he is looking for LTE vendors who might help him create wireless networks that they can run video over. Up to this point, they've used 5.x GHz (802.11a and now 802.11n) for most everything, with 4.9 GHz in certain cases where they could apply for the license. Recently, however, he has been aggressively reaching out to LTE vendors. I asked why LTE instead of WiMAX (which is more "baked" when it comes to large CCTV deployments around the world), and he gave the following reasons: --true mobile (not simply souped up local wireless) solution --access to the lower 700 MHz band (which can go farther, for obvious reasons) --access to a public safety block (licensed similar to 4.9 GHz). I've googled "d block LTE", but can't determine whether or not he is 100% eligible or not... --While WiMAX has "better" ROI (for most people, anyway), this isn't too much of an option because their overall ROI is good based on the premium services they offer Anyone else's thoughts on this? I'd be particularly intersted in knowing which LTE vendors might be worth talking to in this dept. From franck at genius.com Thu Jul 1 08:03:55 2010 From: franck at genius.com (Franck Martin) Date: Fri, 2 Jul 2010 01:03:55 +1200 (FJT) Subject: Feds disable movie piracy websites in raids In-Reply-To: <82y6dvwf3t.fsf@mid.bfk.de> Message-ID: <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> The question is because gTLDs operations are in the USA, does it mean that the USA have control over all those domain names? Can we trust solely the USA for such control? This will come back with a vengeance in the JPA negotiations, ICANN, etc... ----- Original Message ----- From: "Florian Weimer" To: "Michael Painter" Cc: nanog at nanog.org Sent: Friday, 2 July, 2010 12:39:34 AM Subject: Re: Feds disable movie piracy websites in raids * Michael Painter: > BURBANK, Calif. (AP) -- U.S. officials on Wednesday announced a major > crackdown on movie piracy that involved disabling nine websites that > were offering downloads of pirated movies in some cases hours after > they appeared in theaters. Note that some of the domain names in the ICE press release appear to be wrong (or they have already lost control of them). Targeting THEPIRATECITY.ORG and not THEPIRATEBAY.ORG is slightly ridiculous, and it seems that TVSHACK.NET has already reappeared as TVSHACK.CC. ZML.NAME is still controlled by the ZML.COM folks, but seems to have problems right now. This takedown approach might work for controllers of non-too-advanced malware, but you need something better for content which people actually want to access, and which is indexed by helpful search engines. 8-/ -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From patrick at ianai.net Thu Jul 1 08:20:45 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 1 Jul 2010 09:20:45 -0400 Subject: Feds disable movie piracy websites in raids In-Reply-To: <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> References: <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <7B6B519D-D0B9-4816-A845-417F29086D43@ianai.net> On Jul 1, 2010, at 9:03 AM, Franck Martin wrote: > The question is because gTLDs operations are in the USA, does it mean that the USA have control over all those domain names? > > Can we trust solely the USA for such control? > > This will come back with a vengeance in the JPA negotiations, ICANN, etc... Yeah, because if the domains were housed in another country than the USofA, that country's court system & law enforcement surely wouldn't feel any sort of authority over the machines on their sovereign soil. It's just the evil USA that would dare to think in such a fashion. Oh, wait.... Is it possible the law enforcement officers went through the standard due process for the country in which they operate, Just Like Any Other Law Enforcement Agency Would? Nahh, no way we could consider that. It wouldn't allow us to bang on the US and make hollow threats about future negotiations. It's fun to bang on the US, but let's try to keep even a hint of reality & perspective in our rants. Please? -- TTFN, patrick > ----- Original Message ----- > From: "Florian Weimer" > To: "Michael Painter" > Cc: nanog at nanog.org > Sent: Friday, 2 July, 2010 12:39:34 AM > Subject: Re: Feds disable movie piracy websites in raids > > * Michael Painter: > >> BURBANK, Calif. (AP) -- U.S. officials on Wednesday announced a major >> crackdown on movie piracy that involved disabling nine websites that >> were offering downloads of pirated movies in some cases hours after >> they appeared in theaters. > > Note that some of the domain names in the ICE press release appear to > be wrong (or they have already lost control of them). > > Targeting THEPIRATECITY.ORG and not THEPIRATEBAY.ORG is slightly > ridiculous, and it seems that TVSHACK.NET has already reappeared as > TVSHACK.CC. ZML.NAME is still controlled by the ZML.COM folks, but > seems to have problems right now. This takedown approach might work > for controllers of non-too-advanced malware, but you need something > better for content which people actually want to access, and which is > indexed by helpful search engines. 8-/ > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 > > From ge at linuxbox.org Thu Jul 1 08:25:04 2010 From: ge at linuxbox.org (Gadi Evron) Date: Thu, 01 Jul 2010 16:25:04 +0300 Subject: The Economist, cyber war issue Message-ID: <4C2C9730.3040806@linuxbox.org> The upcoming issue will be about cyber war. Check out the front page image: http://sphotos.ak.fbcdn.net/hphotos-ak-snc3/hs488.snc3/26668_410367784059_6013004059_4296972_499550_n.jpg Gadi. From mysidia at gmail.com Thu Jul 1 08:31:27 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 1 Jul 2010 08:31:27 -0500 Subject: Feds disable movie piracy websites in raids In-Reply-To: <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> References: <82y6dvwf3t.fsf@mid.bfk.de> <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Thu, Jul 1, 2010 at 8:03 AM, Franck Martin wrote: > The question is because gTLDs operations are in the USA, does it mean that the USA have control over all those domain names? > Can we trust solely the USA for such control? No. However, anyone signing up for a GTLD should already have looked into risks like that, and there are ccTLDs.... > This will come back with a vengeance in the JPA negotiations, ICANN, etc... Only if US officials are forcing domains owned by foreign people/organizations to be disabled in the gTLD registry, based on activities of hosts that records in those domains point to, in that case, then, yes.. That's called introducing instability into the networks of other country's people that are not under your jurisdiction or operating servers in your jurisdiction, by attacking global infrastructure (DNS Servers) they rely on. By the same token, authorities could probably contrive court orders and send to Tier1 ISPs demanding they drop traffic to certain IP addresses (in foreign IP space). -- -J From fweimer at bfk.de Thu Jul 1 08:34:22 2010 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 01 Jul 2010 13:34:22 +0000 Subject: Feds disable movie piracy websites in raids In-Reply-To: <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> (Franck Martin's message of "Fri\, 2 Jul 2010 01\:03\:55 +1200 \(FJT\)") References: <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <82tyojuy01.fsf@mid.bfk.de> * Franck Martin: > The question is because gTLDs operations are in the USA, does it > mean that the USA have control over all those domain names? Most gTLD operators do business pretty much world-wide, so they aren't exposed to just U.S. law alone. Globalization cuts both ways. In this particular case, the copyright infringement seems to have targeted mainly content created in the U.S., so it's quite natural that the U.S. authorities take a particular interest in it. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From franck at genius.com Thu Jul 1 08:45:34 2010 From: franck at genius.com (Franck Martin) Date: Fri, 2 Jul 2010 01:45:34 +1200 (FJT) Subject: Feds disable movie piracy websites in raids In-Reply-To: <7B6B519D-D0B9-4816-A845-417F29086D43@ianai.net> Message-ID: <10733208.41.1277991930530.JavaMail.franck@franck-martins-macbook-pro.local> I'm not saying any other country is better, I'm just saying the Internet is international and we have the power of one jurisdiction over many internet resources. This will lead certainly to a push for re-balancing (successfully or not, for democracy or against democracy,...). The USA had a trust position with the nuke button that they should not have pushed, but they pushed the nuke button. How the rest of the world will react? will they want to have their say on who can push the nuke button? Today is may be for the right reason, but tomorrow? And there is the kill switch bill coming up (or not)... This is all political, and not suitable for nanog, but it opens a can of worms... ----- Original Message ----- From: "Patrick W. Gilmore" To: "NANOG list" Sent: Friday, 2 July, 2010 1:20:45 AM Subject: Re: Feds disable movie piracy websites in raids On Jul 1, 2010, at 9:03 AM, Franck Martin wrote: > The question is because gTLDs operations are in the USA, does it mean that the USA have control over all those domain names? > > Can we trust solely the USA for such control? > > This will come back with a vengeance in the JPA negotiations, ICANN, etc... Yeah, because if the domains were housed in another country than the USofA, that country's court system & law enforcement surely wouldn't feel any sort of authority over the machines on their sovereign soil. It's just the evil USA that would dare to think in such a fashion. Oh, wait.... Is it possible the law enforcement officers went through the standard due process for the country in which they operate, Just Like Any Other Law Enforcement Agency Would? Nahh, no way we could consider that. It wouldn't allow us to bang on the US and make hollow threats about future negotiations. It's fun to bang on the US, but let's try to keep even a hint of reality & perspective in our rants. Please? -- TTFN, patrick From LarrySheldon at cox.net Thu Jul 1 08:57:53 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 01 Jul 2010 08:57:53 -0500 Subject: Feds disable movie piracy websites in raids In-Reply-To: <10733208.41.1277991930530.JavaMail.franck@franck-martins-macbook-pro.local> References: <10733208.41.1277991930530.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C2C9EE1.7090508@cox.net> On 7/1/2010 08:45, Franck Martin wrote: > This is all political, and not suitable for nanog, but it opens a can of worms... If NANOG is truly about "Operations" and not just BGP knob twiddling and searches for free service, it would be well to recognize at long last that the world we operate in is a political and politicized world and becoming more so by the second. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From lowen at pari.edu Thu Jul 1 09:14:59 2010 From: lowen at pari.edu (Lamar Owen) Date: Thu, 1 Jul 2010 10:14:59 -0400 Subject: Advice regarding Cisco/Juniper/HP In-Reply-To: References: Message-ID: <201007011014.59912.lowen@pari.edu> On Wednesday, June 30, 2010 04:50:40 pm Ricky Beam wrote: > No they don't. Which version of IOS are you running? Oh, right, that > switch doesn't run IOS, it runs CatOS? Wait a min, that's a 1900... it > uses a menu interface. Yep, much like the 'NetBeyond' EtherSwitch 1420 I have here doing... well... 10Base-5 to 100Base-FX and 24 10Base-T's 'work'. Man, that left a bad taste in my mouth. But if it ain't broke... > I have three Cisco switches right here that are radically different. In > fact, the 2948G-L3 confused a CCIE for several weeks. :-) Until I told him > stop thinking "switch" and config it like a 48 port router. (and sadly, it > doesn't support interface ranges. :-() Have a couple of 2948G-L3's in production here, doing trunked gigabit etherchannel uplink to a 7609, with the 7609 doing the DHCP. Configure them like the nearly forgotten Catalyst 8500's..... they're one step from broke, but there's no budget to replace at the moment. Too bad they look virtually identical to the very different 2948G's, which is 4500-based instead of 8500-based. But I'm glad to see I'm not the only one still working those AnyFlow-based switches.... In this case, perhaps the statement should be 'Advice concerning Cisco BU1/BU2/BU3/etc/Juniper/HP/Extreme.....' From kurtis at kurtis.pp.se Thu Jul 1 09:56:25 2010 From: kurtis at kurtis.pp.se (Lindqvist Kurt Erik) Date: Thu, 1 Jul 2010 16:56:25 +0200 Subject: Feds disable movie piracy websites in raids In-Reply-To: <7B6B519D-D0B9-4816-A845-417F29086D43@ianai.net> References: <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> <7B6B519D-D0B9-4816-A845-417F29086D43@ianai.net> Message-ID: <0C6524C3-FCC2-4689-B105-F0CE9F5B6971@kurtis.pp.se> On 1 jul 2010, at 15.20, Patrick W. Gilmore wrote: > n Jul 1, 2010, at 9:03 AM, Franck Martin wrote: > >> The question is because gTLDs operations are in the USA, does it mean that the USA have control over all those domain names? >> >> Can we trust solely the USA for such control? >> >> This will come back with a vengeance in the JPA negotiations, ICANN, etc... JPA discussions are concluded and replaced with the AoC. The discussion on the renewal of the IANA contract I suspect will be a recurring theme in IGF in Villnius. > Yeah, because if the domains were housed in another country than the USofA, that country's court system & law enforcement surely wouldn't feel any sort of authority over the machines on their sovereign soil. It's just the evil USA that would dare to think in such a fashion. Oh, wait.... If you look at the . level i.e ICANN my understanding is that if it was a treaty or UN organization that does not apply. However as we are talking gTLD level you are indeed right. > Is it possible the law enforcement officers went through the standard due process for the country in which they operate, Just Like Any Other Law Enforcement Agency Would? Nahh, no way we could consider that. It wouldn't allow us to bang on the US and make hollow threats about future negotiations. > > > It's fun to bang on the US, but let's try to keep even a hint of reality & perspective in our rants. Please? Best regards, - kurtis - -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From jeffrey.lyon at blacklotus.net Thu Jul 1 11:55:14 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 1 Jul 2010 21:25:14 +0430 Subject: XO feedback In-Reply-To: References: Message-ID: I can't say I share the same experience. Their pricing is mediocre and their billing and customer service are absolutely atrocious. They sold me six cabinets with transit in one of their facilities, never installed power to the cabinets, and then tried to invoice me for the transit. To this day no one at XO sees fit to fix this injustice so they're to the impression that I owe them for the balance of a contract that was literally unusable. Jeff On Thu, Jul 1, 2010 at 4:22 PM, Net wrote: > Hi, > > We're currently looking to buy transit from XO for one of our DCs. > Their pricing is very competative compared to some of the other > providers we've considered to date. > > I'm hoping to get some feedback on their services, support, peering > arrangements and the overall stability of their core backbone network > from folks who've had experience or currently using them. > > Any info would be greatly appreciated. > > Thanks in advance > > -- > Sent from my mobile device > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications of The IRC Company, Inc. Follow us on Twitter at http://twitter.com/ddosprotection to find out about news, promotions, and (gasp!) system outages which are updated in real time. Platinum sponsor of HostingCon 2010. Come to Austin, TX on July 19 - 21 to find out how to "protect your booty." From andrew.wallace at rocketmail.com Thu Jul 1 13:12:19 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 1 Jul 2010 11:12:19 -0700 (PDT) Subject: The Economist, cyber war issue In-Reply-To: <4C2C9730.3040806@linuxbox.org> References: <4C2C9730.3040806@linuxbox.org> Message-ID: <390963.66769.qm@web59608.mail.ac4.yahoo.com> Article: http://www.economist.com/node/16481504?story_id=16481504 My opinion: http://www.economist.com/comment/586099#comment-586099 Andrew http://sites.google.com/site/n3td3v/ ----- Original Message ---- From: Gadi Evron To: nanog at nanog.org Sent: Thu, 1 July, 2010 14:25:04 Subject: The Economist, cyber war issue The upcoming issue will be about cyber war. Check out the front page image: http://sphotos.ak.fbcdn.net/hphotos-ak-snc3/hs488.snc3/26668_410367784059_6013004059_4296972_499550_n.jpg Gadi. From richard.barnes at gmail.com Thu Jul 1 13:46:00 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Thu, 1 Jul 2010 14:46:00 -0400 Subject: The Economist, cyber war issue In-Reply-To: <4C2C9730.3040806@linuxbox.org> References: <4C2C9730.3040806@linuxbox.org> Message-ID: Apparently the Economist has just become aware of the coming 8-bit apocalypse: On Thu, Jul 1, 2010 at 9:25 AM, Gadi Evron wrote: > The upcoming issue will be about cyber war. Check out the front page image: > > http://sphotos.ak.fbcdn.net/hphotos-ak-snc3/hs488.snc3/26668_410367784059_6013004059_4296972_499550_n.jpg > > ? ? ? ?Gadi. > > From jeroen at mompl.net Thu Jul 1 13:57:08 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 01 Jul 2010 11:57:08 -0700 Subject: The Economist, cyber war issue In-Reply-To: <390963.66769.qm@web59608.mail.ac4.yahoo.com> References: <4C2C9730.3040806@linuxbox.org> <390963.66769.qm@web59608.mail.ac4.yahoo.com> Message-ID: <4C2CE504.8070505@mompl.net> andrew.wallace wrote: > Article: http://www.economist.com/node/16481504?story_id=16481504 I know it's shortsighted, but any article with the word cyber in it, used in such a way as being about "cyber this-or-that", already lost its credibility by virtue of using the word. It must be a of rather high quality to win back its credibility. This economist article sadly does the opposite. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ From randy at psg.com Thu Jul 1 15:27:57 2010 From: randy at psg.com (Randy Bush) Date: Fri, 02 Jul 2010 05:27:57 +0900 Subject: Feds disable movie piracy websites in raids In-Reply-To: <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> References: <82y6dvwf3t.fsf@mid.bfk.de> <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > The question is because gTLDs operations are in the USA, does it mean > that the USA have control over all those domain names? the usg controls the cctlds too. randy From mbein at iso-ne.com Thu Jul 1 15:48:14 2010 From: mbein at iso-ne.com (Bein, Matthew) Date: Thu, 1 Jul 2010 16:48:14 -0400 Subject: SPANS Vs Taps Message-ID: As I was doing a design today. I found that I had a bunch of 100 MB connections that I was going to bring into a aggregation tap. Then I was thinking, why don't I use a switch like a Cisco 3560 to gain more density. Anyone run into this? Any down falls with using a switch to aggregate instead of a true port aggregator?? Regards, Matthew From nanog at butchevans.com Thu Jul 1 16:15:41 2010 From: nanog at butchevans.com (Butch Evans) Date: Thu, 01 Jul 2010 16:15:41 -0500 Subject: Type of network operators? Message-ID: <1278018941.6704.675.camel@localhost.localdomain> I have been on this list for about 2 weeks, just observing the discussions. I have primarily worked with wireless service providers in the past who are fairly low budget operators. Some of the things I've observed about this group are: * This list seems to be populated by better funded operations (whether that means larger or just better at getting funding may remain to be seen) * Most of the operators on this list seem to be pretty good at their work and the questions seem to revolve around more complex issues * There seems to be a number of corporate network operators on this list as opposed to access network operators (such as ISPs and such) I hope you all don't take this as an affront and get offended, as that's not my intent. I am just making some simple observations. Having said this, I wanted to introduce myself and see if this is a list that I need to participate in actively. I am a network engineer and consultant. I have worked in the past with Cisco, Juniper and other similar "higher end" type devices, but it's been a while since I had customers who use that gear. Most of my current customer base are smaller operators who can pinch a penny in half. :-) I do a lot of work with MikroTik RouterOS, ImageStream and other Linux based devices. I do engineering, training, hardware sales and such for networks all over the world. I am likely to continue to monitor the list for questions that are in my area of expertise, but wondered if these devices I mention are "common" to operators on this list. I know that I have not caught a discussion that involved any of them so far (other than one reference to an OpenBSD solution a day or two ago). Anyway, hello to the list and I look forward to finding a home among this group. From gladney at stsci.edu Thu Jul 1 16:27:04 2010 From: gladney at stsci.edu (Gary Gladney) Date: Thu, 1 Jul 2010 17:27:04 -0400 (EDT) Subject: SPANS Vs Taps In-Reply-To: References: Message-ID: <20100701172704.ABQ02980@comet.stsci.edu> Depends on the the bunch of 100MB connections. On the down side, when aggregating using a Cisco switch is a limit on the number of switch ports you can aggregate. On the up side, you don't have to be concerned about another device between the switch and device you want to connect to. Gary Gary Gladney Space Telescope Science Institute Email: gladney at stsci.edu Voice: 410.338.4912 Public Key: ldap://certserver.pgp.com ---- Original message ---- >Date: Thu, 1 Jul 2010 16:48:14 -0400 >From: "Bein, Matthew" >Subject: SPANS Vs Taps >To: > >As I was doing a design today. I found that I had a bunch of 100 MB >connections that I was going to bring into a aggregation tap. Then I was >thinking, why don't I use a switch like a Cisco 3560 to gain more >density. Anyone run into this? Any down falls with using a switch to >aggregate instead of a true port aggregator?? > > > >Regards, > > > >Matthew > From andrew.wallace at rocketmail.com Thu Jul 1 16:51:20 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 1 Jul 2010 14:51:20 -0700 (PDT) Subject: The Economist, cyber war issue In-Reply-To: <4C2CE504.8070505@mompl.net> References: <4C2C9730.3040806@linuxbox.org> <390963.66769.qm@web59608.mail.ac4.yahoo.com> <4C2CE504.8070505@mompl.net> Message-ID: <862176.46872.qm@web59616.mail.ac4.yahoo.com> There is a part 2 as well http://www.economist.com/node/16478792?story_id=16478792 Andrew ----- Original Message ---- From: Jeroen van Aart To: NANOG list Sent: Thu, 1 July, 2010 19:57:08 Subject: Re: The Economist, cyber war issue andrew.wallace wrote: > Article: http://www.economist.com/node/16481504?story_id=16481504 I know it's shortsighted, but any article with the word cyber in it, used in such a way as being about "cyber this-or-that", already lost its credibility by virtue of using the word. It must be a of rather high quality to win back its credibility. This economist article sadly does the opposite. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ From randy at psg.com Thu Jul 1 17:01:02 2010 From: randy at psg.com (Randy Bush) Date: Fri, 02 Jul 2010 07:01:02 +0900 Subject: The Economist, cyber war issue In-Reply-To: <862176.46872.qm@web59616.mail.ac4.yahoo.com> References: <4C2C9730.3040806@linuxbox.org> <390963.66769.qm@web59608.mail.ac4.yahoo.com> <4C2CE504.8070505@mompl.net> <862176.46872.qm@web59616.mail.ac4.yahoo.com> Message-ID: > There is a part 2 as well and this is a bug or a feature? From lists at stefan-spuehler.org Thu Jul 1 17:05:36 2010 From: lists at stefan-spuehler.org (=?ISO-8859-1?Q?Stefan_Sp=FChler?=) Date: Fri, 02 Jul 2010 00:05:36 +0200 Subject: Finland makes broadband access a legal right In-Reply-To: <4C2C844B.9020507@linuxbox.org> References: <4C2C844B.9020507@linuxbox.org> Message-ID: <4C2D1130.9030704@stefan-spuehler.org> On 07/01/2010 02:04 PM, Gadi Evron wrote: > http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?hpt=T2 > > > Interesting... > Finland isn't first. http://www.comcom.admin.ch/aktuell/00429/00457/00560/index.html?lang=en&msg-id=13239 From bill at herrin.us Thu Jul 1 17:17:43 2010 From: bill at herrin.us (William Herrin) Date: Thu, 1 Jul 2010 18:17:43 -0400 Subject: Finland makes broadband access a legal right In-Reply-To: <4C2C844B.9020507@linuxbox.org> References: <4C2C844B.9020507@linuxbox.org> Message-ID: On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: > http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?hpt=T2 In the US, the Communications Act of 1934 brought about the creation of the "Universal Service Fund." The idea, more or less, was that every phone line customer contributed to the fund (you'll find it itemized on your phone bill) and the phone companies had to charge the same for every phone line regardless of where delivered in their territory but when initially installing an unusually difficult (expensive) phone line the phone company was entitled to reimburse its cost from the fund. In 1996 a certain inventor of the Internet decided that the universal service fund needed to pay for PCs in rural schools (the "E-Rate" program) instead of improving rural communications... -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From stefan at csudsu.com Thu Jul 1 17:21:25 2010 From: stefan at csudsu.com (Stefan Molnar) Date: Thu, 1 Jul 2010 15:21:25 -0700 (PDT) Subject: XO feedback In-Reply-To: References: Message-ID: <20100701150758.T81245@clockwork> XO has many downs than ups. I am a current XO customer mainly due to the costs, having voice, PtP, Transit, and Co-Location. Here is my rundown. Internet Transit: Yes it works, and when their routing goes ape, no one knows what is going on. They have a tendency not to do a "wr mem" on their ciscos. Point to Point: Yes it works, but when they have to take an OC12 or some large circuit down you might be notified the day of. Also if you have more than one circuit with them, finding what circuit will be hit takes ages on their side. Co-Location: One crap shoot close to death. A "change control" group has to approve changes, adds, and you as a customer has zero say. Call Center: I feel like Mr. Bean is running the call center. Depending on who you call, and when they last did trainning you will get a wild range of responces. Even for the simplest of things takes about 20 min to make a ticket, and some have taken past 40min. Voice: Random failures of not being able to reach cell phone carriers. Random issues where some trunk lines just go offline. But to XO it is always the customer hardware. Another great feature if you have a trouble ticket and in part of correcting the issue if some other change was introduced an automated system will back out any changes weeks later. It is one of those things in life you deal with because the tradeoff is something execs see as the monthly OPEX costs. Stefan On Thu, 1 Jul 2010, Net wrote: > Hi, > > We're currently looking to buy transit from XO for one of our DCs. > Their pricing is very competative compared to some of the other > providers we've considered to date. > > I'm hoping to get some feedback on their services, support, peering > arrangements and the overall stability of their core backbone network > from folks who've had experience or currently using them. > > Any info would be greatly appreciated. > > Thanks in advance > > -- > Sent from my mobile device > > > From matthew at walster.org Thu Jul 1 18:14:42 2010 From: matthew at walster.org (Matthew Walster) Date: Fri, 2 Jul 2010 00:14:42 +0100 Subject: Finland makes broadband access a legal right In-Reply-To: References: <4C2C844B.9020507@linuxbox.org> Message-ID: On 1 July 2010 23:17, William Herrin wrote: > In 1996 a certain inventor of the Internet decided that the universal > service fund needed to pay for PCs in rural schools (the "E-Rate" > program) instead of improving rural communications... As someone who's always been in the "tech" field, the amount spent on ICT in schools has always shocked and appalled me. Bring back the Acorn Archimedes and ECONET! M From darren at bolding.org Thu Jul 1 18:24:38 2010 From: darren at bolding.org (Darren Bolding) Date: Thu, 1 Jul 2010 16:24:38 -0700 Subject: SPANS Vs Taps In-Reply-To: References: Message-ID: Tap manufactures will be sure to tell you of many issues. The main concern I would have is that it is possible for a switch to drop frames of a SPAN. Your decision might be influenced based on your application and the impact of such errors (billing, lawful intercept, forensics). A tap vendors take: http://www.networkcritical.com/What-are-Network-Taps On a somewhat related note, I will mention that TNAPI from ntop is quite handy. http://www.ntop.org/TNAPI.html --D On Thu, Jul 1, 2010 at 1:48 PM, Bein, Matthew wrote: > As I was doing a design today. I found that I had a bunch of 100 MB > connections that I was going to bring into a aggregation tap. Then I was > thinking, why don't I use a switch like a Cisco 3560 to gain more > density. Anyone run into this? Any down falls with using a switch to > aggregate instead of a true port aggregator?? > > > > Regards, > > > > Matthew > > -- -- Darren Bolding -- -- darren at bolding.org -- From LarrySheldon at cox.net Thu Jul 1 18:25:52 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 01 Jul 2010 18:25:52 -0500 Subject: Finland makes broadband access a legal right In-Reply-To: References: <4C2C844B.9020507@linuxbox.org> Message-ID: <4C2D2400.3050308@cox.net> On 7/1/2010 18:14, Matthew Walster wrote: > On 1 July 2010 23:17, William Herrin wrote: >> In 1996 a certain inventor of the Internet decided that the universal >> service fund needed to pay for PCs in rural schools (the "E-Rate" >> program) instead of improving rural communications... > > As someone who's always been in the "tech" field, the amount spent on > ICT in schools has always shocked and appalled me. > > Bring back the Acorn Archimedes and ECONET! Does anybody know how much the Big Sky Telegraph cost, and who paid for it? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jfbeam at gmail.com Thu Jul 1 19:50:40 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Thu, 01 Jul 2010 20:50:40 -0400 Subject: SPANS Vs Taps In-Reply-To: References: Message-ID: On Thu, 01 Jul 2010 19:24:38 -0400, Darren Bolding wrote: > Tap manufactures will be sure to tell you of many issues. Well, there are issues on both sides... A true tap is an electronic mirror. It doesn't much care what the signal is; whatever it senses, it replicates. As the OP is talking about an aggrigating tap, he's already using a switch. I've used NetworkCritical, NetOptics, and several other "cheap" taps. None of them are even remotely cheap. That said, use an ethernet switch... > The main concern I would have is that it is possible for a switch to drop > frames of a SPAN. Your decision might be influenced based on your > application and the impact of such errors (billing, lawful intercept, > forensics). Yes, a switch can drop traffic (inbound and out.) But so can a tap. And so can the thing listening to the tap. At work I'm configuring an integrate Broadcom 10G switch (SoC) as a pure mirror. The ports wired to the system form a trunk group which is the destination for the mirror of the external ports. This is exactly what you'll find inside $$$$$ commercial multiport aggrigating "taps". (and btw, we've thrown over 1Mpps at it without issue; ~50% 64byte packets, the bane of any switch. (recorded) real world traffic, not some Spirent simulation.) --Ricky From mpalmer at hezmatt.org Thu Jul 1 20:54:52 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 2 Jul 2010 11:54:52 +1000 Subject: Finland makes broadband access a legal right In-Reply-To: References: <4C2C844B.9020507@linuxbox.org> Message-ID: <20100702015452.GB7566@hezmatt.org> On Fri, Jul 02, 2010 at 12:14:42AM +0100, Matthew Walster wrote: > On 1 July 2010 23:17, William Herrin wrote: > > In 1996 a certain inventor of the Internet decided that the universal > > service fund needed to pay for PCs in rural schools (the "E-Rate" > > program) instead of improving rural communications... > > As someone who's always been in the "tech" field, the amount spent on > ICT in schools has always shocked and appalled me. Don't get me started on ICT in schools. Please. - Matt -- I remember going to my first tutorial in room 404. I was most upset when I found it. From tme at americafree.tv Thu Jul 1 21:33:57 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 1 Jul 2010 22:33:57 -0400 Subject: Finland makes broadband access a legal right In-Reply-To: References: <4C2C844B.9020507@linuxbox.org> Message-ID: <00173191-2CCE-43A6-A928-139979306E08@americafree.tv> On Jul 1, 2010, at 6:17 PM, William Herrin wrote: > On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: >> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?hpt=T2 > > In the US, the Communications Act of 1934 brought about the creation > of the "Universal Service Fund." The idea, more or less, was that > every phone line customer contributed to the fund (you'll find it > itemized on your phone bill) and the phone companies had to charge the > same for every phone line regardless of where delivered in their > territory but when initially installing an unusually difficult > (expensive) phone line the phone company was entitled to reimburse its > cost from the fund. > > In 1996 a certain inventor of the Internet decided that the universal > service fund needed to pay for PCs in rural schools (the "E-Rate" > program) instead of improving rural communications... > > Sen. Larry Pressler (R-S.D.) invented the Internet ? Regards Marshall > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From hannigan at gmail.com Thu Jul 1 22:18:45 2010 From: hannigan at gmail.com (Martin Hannigan) Date: Thu, 1 Jul 2010 23:18:45 -0400 Subject: Type of network operators? In-Reply-To: <1278018941.6704.675.camel@localhost.localdomain> References: <1278018941.6704.675.camel@localhost.localdomain> Message-ID: Thanks. Your observations are good related to active posters. The overall list is very diverse. Aside from the active posters, the list is about 10K strong. Everything from AOL to people from Zoos, law enforcement, banks, and any industry you can think of. NANOG is not just a list, but an interesting hodge podge of builders and occupants of the Internet that sometimes make sense. :-) As Paul Wall might say, Drive Slow. Best, Marty On 7/1/10, Butch Evans wrote: > I have been on this list for about 2 weeks, just observing the > discussions. I have primarily worked with wireless service > providers in > the past who are fairly low budget operators. Some of the > things I've > observed about this group are: > > * This list seems to be populated by better funded operations > (whether > that means larger or just better at getting funding may remain > to be > seen) > > * Most of the operators on this list seem to be pretty good at > their > work and the questions seem to revolve around more complex > issues > > * There seems to be a number of corporate network operators on > this list > as opposed to access network operators (such as ISPs and such) > > I hope you all don't take this as an affront and get offended, > as that's > not my intent. I am just making some simple observations. > > Having said this, I wanted to introduce myself and see if this > is a list > that I need to participate in actively. I am a network engineer > and > consultant. I have worked in the past with Cisco, Juniper and > other > similar "higher end" type devices, but it's been a while since I > had > customers who use that gear. Most of my current customer base > are > smaller operators who can pinch a penny in half. :-) > > I do a lot of work with MikroTik RouterOS, ImageStream and other > Linux > based devices. I do engineering, training, hardware sales and > such for > networks all over the world. I am likely to continue to monitor > the > list for questions that are in my area of expertise, but > wondered if > these devices I mention are "common" to operators on this list. > I know > that I have not caught a discussion that involved any of them so > far > (other than one reference to an OpenBSD solution a day or two > ago). > > Anyway, hello to the list and I look forward to finding a home > among > this group. > > > > From robert.west at just-micro.com Thu Jul 1 22:24:59 2010 From: robert.west at just-micro.com (Robert West) Date: Thu, 1 Jul 2010 23:24:59 -0400 Subject: Type of network operators? In-Reply-To: References: <1278018941.6704.675.camel@localhost.localdomain> Message-ID: <000401cb1996$27236150$756a23f0$@just-micro.com> But Butch be da dude. Only half a penny?! Butch, I can cut that penny at least into eighths! Sheeesh! Bob- -----Original Message----- From: Martin Hannigan [mailto:hannigan at gmail.com] Sent: Thursday, July 01, 2010 11:19 PM To: Butch Evans; nanog at nanog.org Subject: Re: Type of network operators? Thanks. Your observations are good related to active posters. The overall list is very diverse. Aside from the active posters, the list is about 10K strong. Everything from AOL to people from Zoos, law enforcement, banks, and any industry you can think of. NANOG is not just a list, but an interesting hodge podge of builders and occupants of the Internet that sometimes make sense. :-) As Paul Wall might say, Drive Slow. Best, Marty On 7/1/10, Butch Evans wrote: > I have been on this list for about 2 weeks, just observing the > discussions. I have primarily worked with wireless service > providers in > the past who are fairly low budget operators. Some of the > things I've > observed about this group are: > > * This list seems to be populated by better funded operations > (whether > that means larger or just better at getting funding may remain > to be > seen) > > * Most of the operators on this list seem to be pretty good at > their > work and the questions seem to revolve around more complex > issues > > * There seems to be a number of corporate network operators on > this list > as opposed to access network operators (such as ISPs and such) > > I hope you all don't take this as an affront and get offended, > as that's > not my intent. I am just making some simple observations. > > Having said this, I wanted to introduce myself and see if this > is a list > that I need to participate in actively. I am a network engineer > and > consultant. I have worked in the past with Cisco, Juniper and > other > similar "higher end" type devices, but it's been a while since I > had > customers who use that gear. Most of my current customer base > are > smaller operators who can pinch a penny in half. :-) > > I do a lot of work with MikroTik RouterOS, ImageStream and other > Linux > based devices. I do engineering, training, hardware sales and > such for > networks all over the world. I am likely to continue to monitor > the > list for questions that are in my area of expertise, but > wondered if > these devices I mention are "common" to operators on this list. > I know > that I have not caught a discussion that involved any of them so > far > (other than one reference to an OpenBSD solution a day or two > ago). > > Anyway, hello to the list and I look forward to finding a home > among > this group. > > > > From don.mcmorris at gmail.com Thu Jul 1 22:45:56 2010 From: don.mcmorris at gmail.com (Don McMorris) Date: Thu, 1 Jul 2010 23:45:56 -0400 Subject: Sample RFP/RFQs for routing/switching equipment Message-ID: I'm working with a very rapidly growing SME that is preparing an RFP/RFQ for new routing and switching equipment. Nothing too extravagant - 2 locations, <100mbps throughput. I'm seeking sample RFPs and RFQs for them to assist in the process - specifically to see what to ask for in terms of features and other considerations. There's a deep passion to get this "right the first time". If you know of or have access to RFPs or RFQs you'd be willing to share, it would be of great help. I briefly searched the NANOG archives, and (somewhat surprisingly) did not find a similar request. Thank you very much. --Don From kris.foster at gmail.com Thu Jul 1 23:31:30 2010 From: kris.foster at gmail.com (kris foster) Date: Thu, 1 Jul 2010 21:31:30 -0700 Subject: Sample RFP/RFQs for routing/switching equipment In-Reply-To: References: Message-ID: On Jul 1, 2010, at 8:45 PM, Don McMorris wrote: > I'm working with a very rapidly growing SME that is preparing an > RFP/RFQ for new routing and switching equipment. Nothing too > extravagant - 2 locations, <100mbps throughput. > > I'm seeking sample RFPs and RFQs for them to assist in the process - > specifically to see what to ask for in terms of features and other > considerations. There's a deep passion to get this "right the first > time". If you know of or have access to RFPs or RFQs you'd be willing > to share, it would be of great help. I briefly searched the NANOG > archives, and (somewhat surprisingly) did not find a similar request. Conference presentation archives: http://www.nanog.org/meetings/nanog46/abstracts.php?pt=MTM5MCZuYW5vZzQ2&nm=nanog46 -- kris From Scott.Amyoony at conyersdill.com Fri Jul 2 06:24:12 2010 From: Scott.Amyoony at conyersdill.com (Scott Amyoony) Date: Fri, 02 Jul 2010 08:24:12 -0300 Subject: Please remove me from all mailing lists !!! Message-ID: <4C2DA22C0200000D004589C7@mail.cdp.bm> _____________________________________________ From: [mailto:nanog-bounces at nanog.org] Sent: Friday, July 02, 2010 8:23 AM To: Subject: The results of your email commands The results of your email command are provided below. Attached is your original message. - Unprocessed: move me. Thanks! _____________________________________________ From: [mailto:nanog-request at nanog.org]=20 Sent: Friday, July 02, 2010 12:19 AM To: Subject: NANOG Digest, Vol 30, Issue 4 Send NANOG mailing list submissions to =09nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit =09https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to =09nanog-request at nanog.org You can reach the person managing the list at =09nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." - Ignored: Today's Topics: 1. Re: The Economist, cyber war issue (andrew.wallace) 2. Re: The Economist, cyber war issue (Randy Bush) 3. Re: Finland makes broadband access a legal right (Stefan Sp?hler) 4. Re: Finland makes broadband access a legal right (William Herrin) 5. Re: XO feedback (Stefan Molnar) 6. Re: Finland makes broadband access a legal right (Matthew Walster) 7. Re: SPANS Vs Taps (Darren Bolding) 8. Re: Finland makes broadband access a legal right (Larry Sheldon) 9. Re: SPANS Vs Taps (Ricky Beam) 10. Re: Finland makes broadband access a legal right (Matthew Palmer) 11. Re: Finland makes broadband access a legal right (Marshall Eubanks) 12. Re: Type of network operators? (Martin Hannigan) ---------------------------------------------------------------------- Message: 1 Date: Thu, 1 Jul 2010 14:51:20 -0700 (PDT) From: "andrew.wallace" Subject: Re: The Economist, cyber war issue To: Jeroen van Aart Cc: nanog at nanog.org Message-ID: <862176.46872.qm at web59616.mail.ac4.yahoo.com> Content-Type: text/plain; charset=3Dutf-8 There is a part 2 as well http://www.economist.com/node/16478792?story_id= =3D16478792 Andrew ----- Original Message ---- From: Jeroen van Aart To: NANOG list Sent: Thu, 1 July, 2010 19:57:08 Subject: Re: The Economist, cyber war issue andrew.wallace wrote: > Article: http://www.economist.com/node/16481504?story_id=3D16481504 I know it's shortsighted, but any article with the word cyber in it, used i= n such a way as being about "cyber this-or-that", already lost its credibil= ity by virtue of using the word. It must be a of rather high quality to win= back its credibility. This economist article sadly does the opposite. Regards, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ =20 ------------------------------ Message: 2 Date: Fri, 02 Jul 2010 07:01:02 +0900 From: Randy Bush Subject: Re: The Economist, cyber war issue To: "andrew.wallace" Cc: nanog at nanog.org Message-ID: Content-Type: text/plain; charset=3DUS-ASCII > There is a part 2 as well and this is a bug or a feature? ------------------------------ Message: 3 Date: Fri, 02 Jul 2010 00:05:36 +0200 From: Stefan Sp?hler Subject: Re: Finland makes broadband access a legal right To: nanog at nanog.org Message-ID: <4C2D1130.9030704 at stefan-spuehler.org> Content-Type: text/plain; charset=3DISO-8859-1 On 07/01/2010 02:04 PM, Gadi Evron wrote: > http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?h= pt=3DT2 >=20 >=20 > Interesting... > Finland isn't first. http://www.comcom.admin.ch/aktuell/00429/00457/00560/index.html?lang=3Den&m= sg-id=3D13239 ------------------------------ Message: 4 Date: Thu, 1 Jul 2010 18:17:43 -0400 From: William Herrin Subject: Re: Finland makes broadband access a legal right To: Gadi Evron Cc: nanog at nanog.org Message-ID: =09 Content-Type: text/plain; charset=3DISO-8859-1 On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: > http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?h= pt=3DT2 In the US, the Communications Act of 1934 brought about the creation of the "Universal Service Fund." The idea, more or less, was that every phone line customer contributed to the fund (you'll find it itemized on your phone bill) and the phone companies had to charge the same for every phone line regardless of where delivered in their territory but when initially installing an unusually difficult (expensive) phone line the phone company was entitled to reimburse its cost from the fund. In 1996 a certain inventor of the Internet decided that the universal service fund needed to pay for PCs in rural schools (the "E-Rate" program) instead of improving rural communications... --=20 William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 ------------------------------ Message: 5 Date: Thu, 1 Jul 2010 15:21:25 -0700 (PDT) From: Stefan Molnar Subject: Re: XO feedback To: Net Cc: nanog at nanog.org Message-ID: <20100701150758.T81245 at clockwork> Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed XO has many downs than ups. I am a current XO customer mainly due to the= =20 costs, having voice, PtP, Transit, and Co-Location. Here is my rundown. Internet Transit: Yes it works, and when their routing goes ape, no one=20 knows what is going on. They have a tendency not to do a "wr mem" on=20 their ciscos. Point to Point: Yes it works, but when they have to take an OC12 or some= =20 large circuit down you might be notified the day of. Also if you have=20 more than one circuit with them, finding what circuit will be hit takes=20 ages on their side. Co-Location: One crap shoot close to death. A "change control" group has= =20 to approve changes, adds, and you as a customer has zero say. Call Center: I feel like Mr. Bean is running the call center. Depending= =20 on who you call, and when they last did trainning you will get a wild=20 range of responces. Even for the simplest of things takes about 20 min to= =20 make a ticket, and some have taken past 40min. Voice: Random failures of not being able to reach cell phone carriers.=20 Random issues where some trunk lines just go offline. But to XO it is=20 always the customer hardware. Another great feature if you have a trouble= =20 ticket and in part of correcting the issue if some other change was=20 introduced an automated system will back out any changes weeks later. It is one of those things in life you deal with because the tradeoff is=20 something execs see as the monthly OPEX costs. Stefan On Thu, 1 Jul 2010, Net wrote: > Hi, > > We're currently looking to buy transit from XO for one of our DCs. > Their pricing is very competative compared to some of the other > providers we've considered to date. > > I'm hoping to get some feedback on their services, support, peering > arrangements and the overall stability of their core backbone network > from folks who've had experience or currently using them. > > Any info would be greatly appreciated. > > Thanks in advance > > --=20 > Sent from my mobile device > > > ------------------------------ Message: 6 Date: Fri, 2 Jul 2010 00:14:42 +0100 From: Matthew Walster Subject: Re: Finland makes broadband access a legal right To: nanog list Message-ID: =09 Content-Type: text/plain; charset=3DUTF-8 On 1 July 2010 23:17, William Herrin wrote: > In 1996 a certain inventor of the Internet decided that the universal > service fund needed to pay for PCs in rural schools (the "E-Rate" > program) instead of improving rural communications... As someone who's always been in the "tech" field, the amount spent on ICT in schools has always shocked and appalled me. Bring back the Acorn Archimedes and ECONET! M ------------------------------ Message: 7 Date: Thu, 1 Jul 2010 16:24:38 -0700 From: Darren Bolding Subject: Re: SPANS Vs Taps To: "Bein, Matthew" Cc: nanog at nanog.org Message-ID: =09 Content-Type: text/plain; charset=3DISO-8859-1 Tap manufactures will be sure to tell you of many issues. The main concern I would have is that it is possible for a switch to drop frames of a SPAN. Your decision might be influenced based on your application and the impact of such errors (billing, lawful intercept, forensics). A tap vendors take: http://www.networkcritical.com/What-are-Network-Taps On a somewhat related note, I will mention that TNAPI from ntop is quite handy. http://www.ntop.org/TNAPI.html --D On Thu, Jul 1, 2010 at 1:48 PM, Bein, Matthew wrote: > As I was doing a design today. I found that I had a bunch of 100 MB > connections that I was going to bring into a aggregation tap. Then I was > thinking, why don't I use a switch like a Cisco 3560 to gain more > density. Anyone run into this? Any down falls with using a switch to > aggregate instead of a true port aggregator?? > > > > Regards, > > > > Matthew > > --=20 -- Darren Bolding -- -- darren at bolding.org -- ------------------------------ Message: 8 Date: Thu, 01 Jul 2010 18:25:52 -0500 From: Larry Sheldon Subject: Re: Finland makes broadband access a legal right To: nanog at nanog.org Message-ID: <4C2D2400.3050308 at cox.net> Content-Type: text/plain; charset=3DISO-8859-1 On 7/1/2010 18:14, Matthew Walster wrote: > On 1 July 2010 23:17, William Herrin wrote: >> In 1996 a certain inventor of the Internet decided that the universal >> service fund needed to pay for PCs in rural schools (the "E-Rate" >> program) instead of improving rural communications... >=20 > As someone who's always been in the "tech" field, the amount spent on > ICT in schools has always shocked and appalled me. >=20 > Bring back the Acorn Archimedes and ECONET! Does anybody know how much the Big Sky Telegraph cost, and who paid for it? --=20 Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml =09 ------------------------------ Message: 9 Date: Thu, 01 Jul 2010 20:50:40 -0400 From: "Ricky Beam" Subject: Re: SPANS Vs Taps To: "Darren Bolding" , "Bein, Matthew" =09 Cc: nanog at nanog.org Message-ID: Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed; delsp=3Dyes On Thu, 01 Jul 2010 19:24:38 -0400, Darren Bolding =20 wrote: > Tap manufactures will be sure to tell you of many issues. Well, there are issues on both sides... A true tap is an electronic mirror. It doesn't much care what the signal = =20 is; whatever it senses, it replicates. As the OP is talking about an =20 aggrigating tap, he's already using a switch. I've used NetworkCritical, = =20 NetOptics, and several other "cheap" taps. None of them are even remotely = =20 cheap. That said, use an ethernet switch... > The main concern I would have is that it is possible for a switch to drop > frames of a SPAN. Your decision might be influenced based on your > application and the impact of such errors (billing, lawful intercept, > forensics). Yes, a switch can drop traffic (inbound and out.) But so can a tap. And = =20 so can the thing listening to the tap. At work I'm configuring an integrate Broadcom 10G switch (SoC) as a pure = =20 mirror. The ports wired to the system form a trunk group which is the =20 destination for the mirror of the external ports. This is exactly what =20 you'll find inside $$$$$ commercial multiport aggrigating "taps". (and =20 btw, we've thrown over 1Mpps at it without issue; ~50% 64byte packets, the = =20 bane of any switch. (recorded) real world traffic, not some Spirent =20 simulation.) --Ricky ------------------------------ Message: 10 Date: Fri, 2 Jul 2010 11:54:52 +1000 From: Matthew Palmer Subject: Re: Finland makes broadband access a legal right To: nanog at nanog.org Message-ID: <20100702015452.GB7566 at hezmatt.org> Content-Type: text/plain; charset=3Dus-ascii On Fri, Jul 02, 2010 at 12:14:42AM +0100, Matthew Walster wrote: > On 1 July 2010 23:17, William Herrin wrote: > > In 1996 a certain inventor of the Internet decided that the universal > > service fund needed to pay for PCs in rural schools (the "E-Rate" > > program) instead of improving rural communications... >=20 > As someone who's always been in the "tech" field, the amount spent on > ICT in schools has always shocked and appalled me. Don't get me started on ICT in schools. Please. - Matt --=20 I remember going to my first tutorial in room 404. I was most upset when I found it. ------------------------------ Message: 11 Date: Thu, 1 Jul 2010 22:33:57 -0400 From: Marshall Eubanks Subject: Re: Finland makes broadband access a legal right To: William Herrin Cc: nanog at nanog.org Message-ID: <00173191-2CCE-43A6-A928-139979306E08 at americafree.tv> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed On Jul 1, 2010, at 6:17 PM, William Herrin wrote: > On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: >> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?= hpt=3DT2 > > In the US, the Communications Act of 1934 brought about the creation > of the "Universal Service Fund." The idea, more or less, was that > every phone line customer contributed to the fund (you'll find it > itemized on your phone bill) and the phone companies had to charge the > same for every phone line regardless of where delivered in their > territory but when initially installing an unusually difficult > (expensive) phone line the phone company was entitled to reimburse its > cost from the fund. > > In 1996 a certain inventor of the Internet decided that the universal > service fund needed to pay for PCs in rural schools (the "E-Rate" > program) instead of improving rural communications... > > Sen. Larry Pressler (R-S.D.) invented the Internet ? Regards Marshall > > --=20 > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > ------------------------------ Message: 12 Date: Thu, 1 Jul 2010 23:18:45 -0400 From: Martin Hannigan Subject: Re: Type of network operators? To: Butch Evans , nanog at nanog.org Message-ID: =09 Content-Type: text/plain; charset=3DISO-8859-1 Thanks. Your observations are good related to active posters. The overall list is very diverse. Aside from the active posters, the list is about 10K strong. Everything from AOL to people from Zoos, law enforcement, banks, and any industry you can think of. NANOG is not just a list, but an interesting hodge podge of builders and occupants of the Internet that sometimes make sense. :-) As Paul Wall might say, Drive Slow. Best, Marty On 7/1/10, Butch Evans wrote: > I have been on this list for about 2 weeks, just observing the > discussions. I have primarily worked with wireless service > providers in > the past who are fairly low budget operators. Some of the > things I've > observed about this group are: > > * This list seems to be populated by better funded operations > (whether > that means larger or just better at getting funding may remain > to be > seen) > > * Most of the operators on this list seem to be pretty good at > their > work and the questions seem to revolve around more complex > issues > > * There seems to be a number of corporate network operators on > this list > as opposed to access network operators (such as ISPs and such) > > I hope you all don't take this as an affront and get offended, > as that's > not my intent. I am just making some simple observations. > > Having said this, I wanted to introduce myself and see if this > is a list > that I need to participate in actively. I am a network engineer > and > consultant. I have worked in the past with Cisco, Juniper and > other > similar "higher end" type devices, but it's been a while since I > had > customers who use that gear. Most of my current customer base > are > smaller operators who can pinch a penny in half. :-) > > I do a lot of work with MikroTik RouterOS, ImageStream and other > Linux > based devices. I do engineering, training, hardware sales and > such for > networks all over the world. I am likely to continue to monitor > the > list for questions that are in my area of expertise, but > wondered if > these devices I mention are "common" to operators on this list. > I know > that I have not caught a discussion that involved any of them so > far > (other than one reference to an OpenBSD solution a day or two > ago). > > Anyway, hello to the list and I look forward to finding a home > among > this group. > > > > ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 30, Issue 4 ************************************ - Done. -------------- next part -------------- An embedded message was scrubbed... From: "Scott Amyoony" Subject: PLEEEEASE REMOVE ME FROM MAILING LISTS ! Date: Fri, 02 Jul 2010 08:22:21 -0300 Size: 18585 URL: From funkyfun at gmail.com Fri Jul 2 07:19:14 2010 From: funkyfun at gmail.com (Net) Date: Fri, 2 Jul 2010 08:19:14 -0400 Subject: XO feedback In-Reply-To: <20100701150758.T81245@clockwork> References: <20100701150758.T81245@clockwork> Message-ID: Thanks for the detailed feedback stefan. Its very much appreciated. I'd also like to say thanks for all the private replies. This will certainly go a long way in helping us decide who we end up going with. Best, On 7/1/10, Stefan Molnar wrote: > > XO has many downs than ups. I am a current XO customer mainly due to the > costs, having voice, PtP, Transit, and Co-Location. > > Here is my rundown. > > Internet Transit: Yes it works, and when their routing goes ape, no one > knows what is going on. They have a tendency not to do a "wr mem" on > their ciscos. > > Point to Point: Yes it works, but when they have to take an OC12 or some > large circuit down you might be notified the day of. Also if you have > more than one circuit with them, finding what circuit will be hit takes > ages on their side. > > Co-Location: One crap shoot close to death. A "change control" group has > to approve changes, adds, and you as a customer has zero say. > > Call Center: I feel like Mr. Bean is running the call center. Depending > on who you call, and when they last did trainning you will get a wild > range of responces. Even for the simplest of things takes about 20 min to > make a ticket, and some have taken past 40min. > > Voice: Random failures of not being able to reach cell phone carriers. > Random issues where some trunk lines just go offline. But to XO it is > always the customer hardware. Another great feature if you have a trouble > ticket and in part of correcting the issue if some other change was > introduced an automated system will back out any changes weeks later. > > It is one of those things in life you deal with because the tradeoff is > something execs see as the monthly OPEX costs. > > Stefan > > > On Thu, 1 Jul 2010, Net wrote: > >> Hi, >> >> We're currently looking to buy transit from XO for one of our DCs. >> Their pricing is very competative compared to some of the other >> providers we've considered to date. >> >> I'm hoping to get some feedback on their services, support, peering >> arrangements and the overall stability of their core backbone network >> from folks who've had experience or currently using them. >> >> Any info would be greatly appreciated. >> >> Thanks in advance >> >> -- >> Sent from my mobile device >> >> >> > -- Sent from my mobile device From tme at americafree.tv Fri Jul 2 07:20:06 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 2 Jul 2010 08:20:06 -0400 Subject: Please remove me from all mailing lists !!! In-Reply-To: <4C2DA22C0200000D004589C7@mail.cdp.bm> References: <4C2DA22C0200000D004589C7@mail.cdp.bm> Message-ID: <3DB24873-B283-4860-B423-AA40B474BF6C@americafree.tv> At the very bottom of each message, you will see https://mailman.nanog.org/mailman/listinfo/nanog If you go there, you can unsubscribe. Regards Marshall On Jul 2, 2010, at 7:24 AM, Scott Amyoony wrote: > > > _____________________________________________ > From: [mailto:nanog-bounces at nanog.org] > Sent: Friday, July 02, 2010 8:23 AM > To: > Subject: The results of your email commands > > > The results of your email command are provided below. Attached is your > original message. > > > - Unprocessed: > move me. > Thanks! > _____________________________________________ > From: [mailto:nanog-request at nanog.org]=20 > Sent: Friday, July 02, 2010 12:19 AM > To: > Subject: NANOG Digest, Vol 30, Issue 4 > Send NANOG mailing list submissions to > =09nanog at nanog.org > To subscribe or unsubscribe via the World Wide Web, visit > =09https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > =09nanog-request at nanog.org > You can reach the person managing the list at > =09nanog-owner at nanog.org > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > - Ignored: > > > Today's Topics: > > 1. Re: The Economist, cyber war issue (andrew.wallace) > 2. Re: The Economist, cyber war issue (Randy Bush) > 3. Re: Finland makes broadband access a legal right (Stefan Sp? > hler) > 4. Re: Finland makes broadband access a legal right (William > Herrin) > 5. Re: XO feedback (Stefan Molnar) > 6. Re: Finland makes broadband access a legal right (Matthew > Walster) > 7. Re: SPANS Vs Taps (Darren Bolding) > 8. Re: Finland makes broadband access a legal right (Larry > Sheldon) > 9. Re: SPANS Vs Taps (Ricky Beam) > 10. Re: Finland makes broadband access a legal right (Matthew > Palmer) > 11. Re: Finland makes broadband access a legal right > (Marshall Eubanks) > 12. Re: Type of network operators? (Martin Hannigan) > > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 1 Jul 2010 14:51:20 -0700 (PDT) > From: "andrew.wallace" > Subject: Re: The Economist, cyber war issue > To: Jeroen van Aart > Cc: nanog at nanog.org > Message-ID: <862176.46872.qm at web59616.mail.ac4.yahoo.com> > Content-Type: text/plain; charset=3Dutf-8 > > There is a part 2 as well http://www.economist.com/node/16478792?story_id= > =3D16478792 > > Andrew > > > > ----- Original Message ---- > From: Jeroen van Aart > To: NANOG list > Sent: Thu, 1 July, 2010 19:57:08 > Subject: Re: The Economist, cyber war issue > > andrew.wallace wrote: >> Article: http://www.economist.com/node/16481504?story_id=3D16481504 > > I know it's shortsighted, but any article with the word cyber in > it, used i= > n such a way as being about "cyber this-or-that", already lost > its credibil= > ity by virtue of using the word. It must be a of rather high > quality to win= > back its credibility. This economist article sadly does the > opposite. > > Regards, > Jeroen > > -- http://goldmark.org/jeff/stupid-disclaimers/ > > > =20 > > > > > ------------------------------ > > Message: 2 > Date: Fri, 02 Jul 2010 07:01:02 +0900 > From: Randy Bush > Subject: Re: The Economist, cyber war issue > To: "andrew.wallace" > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=3DUS-ASCII > >> There is a part 2 as well > > and this is a bug or a feature? > > > > ------------------------------ > > Message: 3 > Date: Fri, 02 Jul 2010 00:05:36 +0200 > From: Stefan Sp?hler > Subject: Re: Finland makes broadband access a legal right > To: nanog at nanog.org > Message-ID: <4C2D1130.9030704 at stefan-spuehler.org> > Content-Type: text/plain; charset=3DISO-8859-1 > > On 07/01/2010 02:04 PM, Gadi Evron wrote: >> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?h= > pt=3DT2 >> =20 >> =20 >> Interesting... >> > Finland isn't first. > > http://www.comcom.admin.ch/aktuell/00429/00457/00560/index.html?lang=3Den&m= > sg-id=3D13239 > > > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 1 Jul 2010 18:17:43 -0400 > From: William Herrin > Subject: Re: Finland makes broadband access a legal right > To: Gadi Evron > Cc: nanog at nanog.org > Message-ID: > =09 > Content-Type: text/plain; charset=3DISO-8859-1 > > On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: >> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?h= > pt=3DT2 > > In the US, the Communications Act of 1934 brought about the > creation > of the "Universal Service Fund." The idea, more or less, was that > every phone line customer contributed to the fund (you'll find it > itemized on your phone bill) and the phone companies had to > charge the > same for every phone line regardless of where delivered in their > territory but when initially installing an unusually difficult > (expensive) phone line the phone company was entitled to > reimburse its > cost from the fund. > > In 1996 a certain inventor of the Internet decided that the > universal > service fund needed to pay for PCs in rural schools (the "E-Rate" > program) instead of improving rural communications... > > > > --=20 > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > > ------------------------------ > > Message: 5 > Date: Thu, 1 Jul 2010 15:21:25 -0700 (PDT) > From: Stefan Molnar > Subject: Re: XO feedback > To: Net > Cc: nanog at nanog.org > Message-ID: <20100701150758.T81245 at clockwork> > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed > > > XO has many downs than ups. I am a current XO customer mainly > due to the= > =20 > costs, having voice, PtP, Transit, and Co-Location. > > Here is my rundown. > > Internet Transit: Yes it works, and when their routing goes ape, > no one=20 > knows what is going on. They have a tendency not to do a "wr > mem" on=20 > their ciscos. > > Point to Point: Yes it works, but when they have to take an OC12 > or some= > =20 > large circuit down you might be notified the day of. Also if you > have=20 > more than one circuit with them, finding what circuit will be hit > takes=20 > ages on their side. > > Co-Location: One crap shoot close to death. A "change control" > group has= > =20 > to approve changes, adds, and you as a customer has zero say. > > Call Center: I feel like Mr. Bean is running the call center. > Depending= > =20 > on who you call, and when they last did trainning you will get a > wild=20 > range of responces. Even for the simplest of things takes about > 20 min to= > =20 > make a ticket, and some have taken past 40min. > > Voice: Random failures of not being able to reach cell phone > carriers.=20 > Random issues where some trunk lines just go offline. But to XO > it is=20 > always the customer hardware. Another great feature if you have > a trouble= > =20 > ticket and in part of correcting the issue if some other change > was=20 > introduced an automated system will back out any changes weeks > later. > > It is one of those things in life you deal with because the > tradeoff is=20 > something execs see as the monthly OPEX costs. > > Stefan > > > On Thu, 1 Jul 2010, Net wrote: > >> Hi, >> >> We're currently looking to buy transit from XO for one of our DCs. >> Their pricing is very competative compared to some of the other >> providers we've considered to date. >> >> I'm hoping to get some feedback on their services, support, peering >> arrangements and the overall stability of their core backbone network >> from folks who've had experience or currently using them. >> >> Any info would be greatly appreciated. >> >> Thanks in advance >> >> --=20 >> Sent from my mobile device >> >> >> > > > > ------------------------------ > > Message: 6 > Date: Fri, 2 Jul 2010 00:14:42 +0100 > From: Matthew Walster > Subject: Re: Finland makes broadband access a legal right > To: nanog list > Message-ID: > =09 > Content-Type: text/plain; charset=3DUTF-8 > > On 1 July 2010 23:17, William Herrin wrote: >> In 1996 a certain inventor of the Internet decided that the universal >> service fund needed to pay for PCs in rural schools (the "E-Rate" >> program) instead of improving rural communications... > > As someone who's always been in the "tech" field, the amount > spent on > ICT in schools has always shocked and appalled me. > > Bring back the Acorn Archimedes and ECONET! > > M > > > > ------------------------------ > > Message: 7 > Date: Thu, 1 Jul 2010 16:24:38 -0700 > From: Darren Bolding > Subject: Re: SPANS Vs Taps > To: "Bein, Matthew" > Cc: nanog at nanog.org > Message-ID: > =09 > Content-Type: text/plain; charset=3DISO-8859-1 > > Tap manufactures will be sure to tell you of many issues. > > The main concern I would have is that it is possible for a switch > to drop > frames of a SPAN. Your decision might be influenced based on your > application and the impact of such errors (billing, lawful > intercept, > forensics). > > A tap vendors take: http://www.networkcritical.com/What-are-Network-Taps > > On a somewhat related note, I will mention that TNAPI from ntop > is quite > handy. http://www.ntop.org/TNAPI.html > > --D > > On Thu, Jul 1, 2010 at 1:48 PM, Bein, Matthew > wrote: > >> As I was doing a design today. I found that I had a bunch of 100 MB >> connections that I was going to bring into a aggregation tap. Then >> I was >> thinking, why don't I use a switch like a Cisco 3560 to gain more >> density. Anyone run into this? Any down falls with using a switch to >> aggregate instead of a true port aggregator?? >> >> >> >> Regards, >> >> >> >> Matthew >> >> > > > --=20 > -- Darren Bolding -- > -- darren at bolding.org -- > > > ------------------------------ > > Message: 8 > Date: Thu, 01 Jul 2010 18:25:52 -0500 > From: Larry Sheldon > Subject: Re: Finland makes broadband access a legal right > To: nanog at nanog.org > Message-ID: <4C2D2400.3050308 at cox.net> > Content-Type: text/plain; charset=3DISO-8859-1 > > On 7/1/2010 18:14, Matthew Walster wrote: >> On 1 July 2010 23:17, William Herrin wrote: >>> In 1996 a certain inventor of the Internet decided that the >>> universal >>> service fund needed to pay for PCs in rural schools (the "E-Rate" >>> program) instead of improving rural communications... >> =20 >> As someone who's always been in the "tech" field, the amount spent on >> ICT in schools has always shocked and appalled me. >> =20 >> Bring back the Acorn Archimedes and ECONET! > > Does anybody know how much the Big Sky Telegraph cost, and who > paid for it? > > --=20 > Somebody should have said: > A democracy is two wolves and a lamb voting on what to have for > dinner. > > Freedom under a constitutional republic is a well armed lamb > contesting > the vote. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > =09 > > > > ------------------------------ > > Message: 9 > Date: Thu, 01 Jul 2010 20:50:40 -0400 > From: "Ricky Beam" > Subject: Re: SPANS Vs Taps > To: "Darren Bolding" , "Bein, Matthew" > =09 > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=3Dus-ascii; format=3Dflowed; > delsp=3Dyes > > On Thu, 01 Jul 2010 19:24:38 -0400, Darren Bolding > =20 > wrote: >> Tap manufactures will be sure to tell you of many issues. > > Well, there are issues on both sides... > > A true tap is an electronic mirror. It doesn't much care what > the signal = > =20 > is; whatever it senses, it replicates. As the OP is talking > about an =20 > aggrigating tap, he's already using a switch. I've used > NetworkCritical, = > =20 > NetOptics, and several other "cheap" taps. None of them are even > remotely = > =20 > cheap. That said, use an ethernet switch... > >> The main concern I would have is that it is possible for a switch >> to drop >> frames of a SPAN. Your decision might be influenced based on your >> application and the impact of such errors (billing, lawful intercept, >> forensics). > > Yes, a switch can drop traffic (inbound and out.) But so can a > tap. And = > =20 > so can the thing listening to the tap. > > At work I'm configuring an integrate Broadcom 10G switch (SoC) as > a pure = > =20 > mirror. The ports wired to the system form a trunk group which > is the =20 > destination for the mirror of the external ports. This is > exactly what =20 > you'll find inside $$$$$ commercial multiport aggrigating "taps". > (and =20 > btw, we've thrown over 1Mpps at it without issue; ~50% 64byte > packets, the = > =20 > bane of any switch. (recorded) real world traffic, not some > Spirent =20 > simulation.) > > --Ricky > > > > ------------------------------ > > Message: 10 > Date: Fri, 2 Jul 2010 11:54:52 +1000 > From: Matthew Palmer > Subject: Re: Finland makes broadband access a legal right > To: nanog at nanog.org > Message-ID: <20100702015452.GB7566 at hezmatt.org> > Content-Type: text/plain; charset=3Dus-ascii > > On Fri, Jul 02, 2010 at 12:14:42AM +0100, Matthew Walster wrote: >> On 1 July 2010 23:17, William Herrin wrote: >>> In 1996 a certain inventor of the Internet decided that the >>> universal >>> service fund needed to pay for PCs in rural schools (the "E-Rate" >>> program) instead of improving rural communications... >> =20 >> As someone who's always been in the "tech" field, the amount spent on >> ICT in schools has always shocked and appalled me. > > Don't get me started on ICT in schools. Please. > > - Matt > > --=20 > I remember going to my first tutorial in room 404. I was > most upset > when I found it. > > > > ------------------------------ > > Message: 11 > Date: Thu, 1 Jul 2010 22:33:57 -0400 > From: Marshall Eubanks > Subject: Re: Finland makes broadband access a legal right > To: William Herrin > Cc: nanog at nanog.org > Message-ID: <00173191-2CCE-43A6-A928-139979306E08 at americafree.tv> > Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed > > > On Jul 1, 2010, at 6:17 PM, William Herrin wrote: > >> On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: >>> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?= > hpt=3DT2 >> >> In the US, the Communications Act of 1934 brought about the creation >> of the "Universal Service Fund." The idea, more or less, was that >> every phone line customer contributed to the fund (you'll find it >> itemized on your phone bill) and the phone companies had to charge >> the >> same for every phone line regardless of where delivered in their >> territory but when initially installing an unusually difficult >> (expensive) phone line the phone company was entitled to reimburse >> its >> cost from the fund. >> >> In 1996 a certain inventor of the Internet decided that the universal >> service fund needed to pay for PCs in rural schools (the "E-Rate" >> program) instead of improving rural communications... >> >> > > Sen. Larry Pressler (R-S.D.) invented the Internet ? > > Regards > Marshall > > > >> >> --=20 >> William D. Herrin ................ herrin at dirtside.com >> bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> > > > > > ------------------------------ > > Message: 12 > Date: Thu, 1 Jul 2010 23:18:45 -0400 > From: Martin Hannigan > Subject: Re: Type of network operators? > To: Butch Evans , nanog at nanog.org > Message-ID: > =09 > Content-Type: text/plain; charset=3DISO-8859-1 > > Thanks. Your observations are good related to active posters. The > overall list is very diverse. Aside from the active posters, the > list > is about 10K strong. Everything from AOL to people from Zoos, law > enforcement, banks, and any industry you can think of. NANOG is > not > just a list, but an interesting hodge podge of builders and > occupants > of the Internet that sometimes make sense. :-) > > As Paul Wall might say, Drive Slow. > > Best, > > Marty > > > > On 7/1/10, Butch Evans wrote: >> I have been on this list for about 2 weeks, just observing the >> discussions. I have primarily worked with wireless service >> providers in >> the past who are fairly low budget operators. Some of the >> things I've >> observed about this group are: >> >> * This list seems to be populated by better funded operations >> (whether >> that means larger or just better at getting funding may remain >> to be >> seen) >> >> * Most of the operators on this list seem to be pretty good at >> their >> work and the questions seem to revolve around more complex >> issues >> >> * There seems to be a number of corporate network operators on >> this list >> as opposed to access network operators (such as ISPs and such) >> >> I hope you all don't take this as an affront and get offended, >> as that's >> not my intent. I am just making some simple observations. >> >> Having said this, I wanted to introduce myself and see if this >> is a list >> that I need to participate in actively. I am a network >> engineer >> and >> consultant. I have worked in the past with Cisco, Juniper and >> other >> similar "higher end" type devices, but it's been a while >> since I >> had >> customers who use that gear. Most of my current customer base >> are >> smaller operators who can pinch a penny in half. :-) >> >> I do a lot of work with MikroTik RouterOS, ImageStream and >> other >> Linux >> based devices. I do engineering, training, hardware sales and >> such for >> networks all over the world. I am likely to continue to >> monitor >> the >> list for questions that are in my area of expertise, but >> wondered if >> these devices I mention are "common" to operators on this >> list. >> I know >> that I have not caught a discussion that involved any of >> them so >> far >> (other than one reference to an OpenBSD solution a day or two >> ago). >> >> Anyway, hello to the list and I look forward to finding a home >> among >> this group. >> >> >> >> > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 30, Issue 4 > ************************************ > > > > > - Done. > > From: "Scott Amyoony" > Date: July 2, 2010 7:22:21 AM EDT > To: > Subject: PLEEEEASE REMOVE ME FROM MAILING LISTS ! > > > I have tried the mailman link, could not get password reset. PLEASE > just remove me. > > Thanks! > > _____________________________________________ > From: [mailto:nanog-request at nanog.org] > Sent: Friday, July 02, 2010 12:19 AM > To: > Subject: NANOG Digest, Vol 30, Issue 4 > > > Send NANOG mailing list submissions to > nanog at nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request at nanog.org > > You can reach the person managing the list at > nanog-owner at nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: The Economist, cyber war issue (andrew.wallace) > 2. Re: The Economist, cyber war issue (Randy Bush) > 3. Re: Finland makes broadband access a legal right (Stefan Sp?hler) > 4. Re: Finland makes broadband access a legal right (William Herrin) > 5. Re: XO feedback (Stefan Molnar) > 6. Re: Finland makes broadband access a legal right (Matthew > Walster) > 7. Re: SPANS Vs Taps (Darren Bolding) > 8. Re: Finland makes broadband access a legal right (Larry Sheldon) > 9. Re: SPANS Vs Taps (Ricky Beam) > 10. Re: Finland makes broadband access a legal right (Matthew Palmer) > 11. Re: Finland makes broadband access a legal right > (Marshall Eubanks) > 12. Re: Type of network operators? (Martin Hannigan) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 1 Jul 2010 14:51:20 -0700 (PDT) > From: "andrew.wallace" > Subject: Re: The Economist, cyber war issue > To: Jeroen van Aart > Cc: nanog at nanog.org > Message-ID: <862176.46872.qm at web59616.mail.ac4.yahoo.com> > Content-Type: text/plain; charset=utf-8 > > There is a part 2 as well http://www.economist.com/node/16478792?story_id=16478792 > > Andrew > > > > ----- Original Message ---- > From: Jeroen van Aart > To: NANOG list > Sent: Thu, 1 July, 2010 19:57:08 > Subject: Re: The Economist, cyber war issue > > andrew.wallace wrote: >> Article: http://www.economist.com/node/16481504?story_id=16481504 > > I know it's shortsighted, but any article with the word cyber in it, > used in such a way as being about "cyber this-or-that", already lost > its credibility by virtue of using the word. It must be a of rather > high quality to win back its credibility. This economist article > sadly does the opposite. > > Regards, > Jeroen > > -- http://goldmark.org/jeff/stupid-disclaimers/ > > > > > > > > ------------------------------ > > Message: 2 > Date: Fri, 02 Jul 2010 07:01:02 +0900 > From: Randy Bush > Subject: Re: The Economist, cyber war issue > To: "andrew.wallace" > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=US-ASCII > >> There is a part 2 as well > > and this is a bug or a feature? > > > > ------------------------------ > > Message: 3 > Date: Fri, 02 Jul 2010 00:05:36 +0200 > From: Stefan Sp?hler > Subject: Re: Finland makes broadband access a legal right > To: nanog at nanog.org > Message-ID: <4C2D1130.9030704 at stefan-spuehler.org> > Content-Type: text/plain; charset=ISO-8859-1 > > On 07/01/2010 02:04 PM, Gadi Evron wrote: >> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?hpt=T2 >> >> >> Interesting... >> > Finland isn't first. > > http://www.comcom.admin.ch/aktuell/00429/00457/00560/index.html?lang=en&msg-id=13239 > > > > > > > > ------------------------------ > > Message: 4 > Date: Thu, 1 Jul 2010 18:17:43 -0400 > From: William Herrin > Subject: Re: Finland makes broadband access a legal right > To: Gadi Evron > Cc: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: >> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?hpt=T2 > > In the US, the Communications Act of 1934 brought about the creation > of the "Universal Service Fund." The idea, more or less, was that > every phone line customer contributed to the fund (you'll find it > itemized on your phone bill) and the phone companies had to charge the > same for every phone line regardless of where delivered in their > territory but when initially installing an unusually difficult > (expensive) phone line the phone company was entitled to reimburse its > cost from the fund. > > In 1996 a certain inventor of the Internet decided that the universal > service fund needed to pay for PCs in rural schools (the "E-Rate" > program) instead of improving rural communications... > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > > > ------------------------------ > > Message: 5 > Date: Thu, 1 Jul 2010 15:21:25 -0700 (PDT) > From: Stefan Molnar > Subject: Re: XO feedback > To: Net > Cc: nanog at nanog.org > Message-ID: <20100701150758.T81245 at clockwork> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > XO has many downs than ups. I am a current XO customer mainly due > to the > costs, having voice, PtP, Transit, and Co-Location. > > Here is my rundown. > > Internet Transit: Yes it works, and when their routing goes ape, no > one > knows what is going on. They have a tendency not to do a "wr mem" on > their ciscos. > > Point to Point: Yes it works, but when they have to take an OC12 or > some > large circuit down you might be notified the day of. Also if you have > more than one circuit with them, finding what circuit will be hit > takes > ages on their side. > > Co-Location: One crap shoot close to death. A "change control" > group has > to approve changes, adds, and you as a customer has zero say. > > Call Center: I feel like Mr. Bean is running the call center. > Depending > on who you call, and when they last did trainning you will get a wild > range of responces. Even for the simplest of things takes about 20 > min to > make a ticket, and some have taken past 40min. > > Voice: Random failures of not being able to reach cell phone > carriers. > Random issues where some trunk lines just go offline. But to XO it is > always the customer hardware. Another great feature if you have a > trouble > ticket and in part of correcting the issue if some other change was > introduced an automated system will back out any changes weeks later. > > It is one of those things in life you deal with because the tradeoff > is > something execs see as the monthly OPEX costs. > > Stefan > > > On Thu, 1 Jul 2010, Net wrote: > >> Hi, >> >> We're currently looking to buy transit from XO for one of our DCs. >> Their pricing is very competative compared to some of the other >> providers we've considered to date. >> >> I'm hoping to get some feedback on their services, support, peering >> arrangements and the overall stability of their core backbone network >> from folks who've had experience or currently using them. >> >> Any info would be greatly appreciated. >> >> Thanks in advance >> >> -- >> Sent from my mobile device >> >> >> > > > > ------------------------------ > > Message: 6 > Date: Fri, 2 Jul 2010 00:14:42 +0100 > From: Matthew Walster > Subject: Re: Finland makes broadband access a legal right > To: nanog list > Message-ID: > > Content-Type: text/plain; charset=UTF-8 > > On 1 July 2010 23:17, William Herrin wrote: >> In 1996 a certain inventor of the Internet decided that the universal >> service fund needed to pay for PCs in rural schools (the "E-Rate" >> program) instead of improving rural communications... > > As someone who's always been in the "tech" field, the amount spent on > ICT in schools has always shocked and appalled me. > > Bring back the Acorn Archimedes and ECONET! > > M > > > > ------------------------------ > > Message: 7 > Date: Thu, 1 Jul 2010 16:24:38 -0700 > From: Darren Bolding > Subject: Re: SPANS Vs Taps > To: "Bein, Matthew" > Cc: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Tap manufactures will be sure to tell you of many issues. > > The main concern I would have is that it is possible for a switch to > drop > frames of a SPAN. Your decision might be influenced based on your > application and the impact of such errors (billing, lawful intercept, > forensics). > > A tap vendors take: http://www.networkcritical.com/What-are-Network-Taps > > On a somewhat related note, I will mention that TNAPI from ntop is > quite > handy. http://www.ntop.org/TNAPI.html > > --D > > On Thu, Jul 1, 2010 at 1:48 PM, Bein, Matthew > wrote: > >> As I was doing a design today. I found that I had a bunch of 100 MB >> connections that I was going to bring into a aggregation tap. Then >> I was >> thinking, why don't I use a switch like a Cisco 3560 to gain more >> density. Anyone run into this? Any down falls with using a switch to >> aggregate instead of a true port aggregator?? >> >> >> >> Regards, >> >> >> >> Matthew >> >> > > > -- > -- Darren Bolding -- > -- darren at bolding.org -- > > > ------------------------------ > > Message: 8 > Date: Thu, 01 Jul 2010 18:25:52 -0500 > From: Larry Sheldon > Subject: Re: Finland makes broadband access a legal right > To: nanog at nanog.org > Message-ID: <4C2D2400.3050308 at cox.net> > Content-Type: text/plain; charset=ISO-8859-1 > > On 7/1/2010 18:14, Matthew Walster wrote: >> On 1 July 2010 23:17, William Herrin wrote: >>> In 1996 a certain inventor of the Internet decided that the >>> universal >>> service fund needed to pay for PCs in rural schools (the "E-Rate" >>> program) instead of improving rural communications... >> >> As someone who's always been in the "tech" field, the amount spent on >> ICT in schools has always shocked and appalled me. >> >> Bring back the Acorn Archimedes and ECONET! > > Does anybody know how much the Big Sky Telegraph cost, and who paid > for it? > > -- > Somebody should have said: > A democracy is two wolves and a lamb voting on what to have for > dinner. > > Freedom under a constitutional republic is a well armed lamb > contesting > the vote. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > > > > ------------------------------ > > Message: 9 > Date: Thu, 01 Jul 2010 20:50:40 -0400 > From: "Ricky Beam" > Subject: Re: SPANS Vs Taps > To: "Darren Bolding" , "Bein, Matthew" > > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes > > On Thu, 01 Jul 2010 19:24:38 -0400, Darren Bolding > > wrote: >> Tap manufactures will be sure to tell you of many issues. > > Well, there are issues on both sides... > > A true tap is an electronic mirror. It doesn't much care what the > signal > is; whatever it senses, it replicates. As the OP is talking about an > aggrigating tap, he's already using a switch. I've used > NetworkCritical, > NetOptics, and several other "cheap" taps. None of them are even > remotely > cheap. That said, use an ethernet switch... > >> The main concern I would have is that it is possible for a switch >> to drop >> frames of a SPAN. Your decision might be influenced based on your >> application and the impact of such errors (billing, lawful intercept, >> forensics). > > Yes, a switch can drop traffic (inbound and out.) But so can a > tap. And > so can the thing listening to the tap. > > At work I'm configuring an integrate Broadcom 10G switch (SoC) as a > pure > mirror. The ports wired to the system form a trunk group which is the > destination for the mirror of the external ports. This is exactly > what > you'll find inside $$$$$ commercial multiport aggrigating "taps". (and > btw, we've thrown over 1Mpps at it without issue; ~50% 64byte > packets, the > bane of any switch. (recorded) real world traffic, not some Spirent > simulation.) > > --Ricky > > > > ------------------------------ > > Message: 10 > Date: Fri, 2 Jul 2010 11:54:52 +1000 > From: Matthew Palmer > Subject: Re: Finland makes broadband access a legal right > To: nanog at nanog.org > Message-ID: <20100702015452.GB7566 at hezmatt.org> > Content-Type: text/plain; charset=us-ascii > > On Fri, Jul 02, 2010 at 12:14:42AM +0100, Matthew Walster wrote: >> On 1 July 2010 23:17, William Herrin wrote: >>> In 1996 a certain inventor of the Internet decided that the >>> universal >>> service fund needed to pay for PCs in rural schools (the "E-Rate" >>> program) instead of improving rural communications... >> >> As someone who's always been in the "tech" field, the amount spent on >> ICT in schools has always shocked and appalled me. > > Don't get me started on ICT in schools. Please. > > - Matt > > -- > I remember going to my first tutorial in room 404. I was > most upset > when I found it. > > > > ------------------------------ > > Message: 11 > Date: Thu, 1 Jul 2010 22:33:57 -0400 > From: Marshall Eubanks > Subject: Re: Finland makes broadband access a legal right > To: William Herrin > Cc: nanog at nanog.org > Message-ID: <00173191-2CCE-43A6-A928-139979306E08 at americafree.tv> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > > On Jul 1, 2010, at 6:17 PM, William Herrin wrote: > >> On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: >>> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?hpt=T2 >> >> In the US, the Communications Act of 1934 brought about the creation >> of the "Universal Service Fund." The idea, more or less, was that >> every phone line customer contributed to the fund (you'll find it >> itemized on your phone bill) and the phone companies had to charge >> the >> same for every phone line regardless of where delivered in their >> territory but when initially installing an unusually difficult >> (expensive) phone line the phone company was entitled to reimburse >> its >> cost from the fund. >> >> In 1996 a certain inventor of the Internet decided that the universal >> service fund needed to pay for PCs in rural schools (the "E-Rate" >> program) instead of improving rural communications... >> >> > > Sen. Larry Pressler (R-S.D.) invented the Internet ? > > Regards > Marshall > > > >> >> -- >> William D. Herrin ................ herrin at dirtside.com >> bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> > > > > > ------------------------------ > > Message: 12 > Date: Thu, 1 Jul 2010 23:18:45 -0400 > From: Martin Hannigan > Subject: Re: Type of network operators? > To: Butch Evans , nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Thanks. Your observations are good related to active posters. The > overall list is very diverse. Aside from the active posters, the list > is about 10K strong. Everything from AOL to people from Zoos, law > enforcement, banks, and any industry you can think of. NANOG is not > just a list, but an interesting hodge podge of builders and occupants > of the Internet that sometimes make sense. :-) > > As Paul Wall might say, Drive Slow. > > Best, > > Marty > > > > On 7/1/10, Butch Evans wrote: >> I have been on this list for about 2 weeks, just observing the >> discussions. I have primarily worked with wireless service >> providers in >> the past who are fairly low budget operators. Some of the >> things I've >> observed about this group are: >> >> * This list seems to be populated by better funded operations >> (whether >> that means larger or just better at getting funding may remain >> to be >> seen) >> >> * Most of the operators on this list seem to be pretty good at >> their >> work and the questions seem to revolve around more complex >> issues >> >> * There seems to be a number of corporate network operators on >> this list >> as opposed to access network operators (such as ISPs and such) >> >> I hope you all don't take this as an affront and get offended, >> as that's >> not my intent. I am just making some simple observations. >> >> Having said this, I wanted to introduce myself and see if this >> is a list >> that I need to participate in actively. I am a network >> engineer >> and >> consultant. I have worked in the past with Cisco, Juniper and >> other >> similar "higher end" type devices, but it's been a while >> since I >> had >> customers who use that gear. Most of my current customer base >> are >> smaller operators who can pinch a penny in half. :-) >> >> I do a lot of work with MikroTik RouterOS, ImageStream and >> other >> Linux >> based devices. I do engineering, training, hardware sales and >> such for >> networks all over the world. I am likely to continue to >> monitor >> the >> list for questions that are in my area of expertise, but >> wondered if >> these devices I mention are "common" to operators on this >> list. >> I know >> that I have not caught a discussion that involved any of >> them so >> far >> (other than one reference to an OpenBSD solution a day or two >> ago). >> >> Anyway, hello to the list and I look forward to finding a home >> among >> this group. >> >> >> >> > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 30, Issue 4 > ************************************ > > > > > From funkyfun at gmail.com Fri Jul 2 07:21:59 2010 From: funkyfun at gmail.com (Net) Date: Fri, 2 Jul 2010 08:21:59 -0400 Subject: XO feedback In-Reply-To: References: Message-ID: Thanks for reaching out Brian. We'll certainly keep Saavis in mind and advise as deemed fit. Regards, On 7/1/10, Bellis, Brian wrote: > Dear Funky Fun, > > Have you consider Savvis for IP transit. We are a Tier 1 IP backbone > provider operating AS-3561. We announce approximately 23% of all > internet routes on our backbone and are privately peered with all other > Tier 1 providers meaning we don't buy upstream to gain access to routes. > We are very price competitive and offer fixed and burstable pricing. We > are located in virtually every telehouse across the US and have PoPs in > London, Paris, Frankfurt and Amsterdam. > > No pressure here and no need to respond if you are not interested. Just > wanted to give you another option you may have not considered. Thank > you. > > Best regards, > > Brian > > > > Brian Bellis | Sr. Sales Director Service Providers > > > > Savvis > 2355 Dulles Corner Blvd, Herndon, VA 20171 > Office: 703.667.6254 | Mobile: 202.997.1336 | Fax: 703.880.7239 > > E-mail: brian.bellis at savvis.net > > www.savvis.net > > > > > -----Original Message----- > From: Net [mailto:funkyfun at gmail.com] > Sent: Thursday, July 01, 2010 7:52 AM > To: nanog at nanog.org > Subject: XO feedback > > Hi, > > We're currently looking to buy transit from XO for one of our DCs. > Their pricing is very competative compared to some of the other > providers we've considered to date. > > I'm hoping to get some feedback on their services, support, peering > arrangements and the overall stability of their core backbone network > from folks who've had experience or currently using them. > > Any info would be greatly appreciated. > > Thanks in advance > > -- > Sent from my mobile device > > > This message contains information which may be confidential and/or > privileged. Unless you are the intended recipient (or authorized to receive > for the intended recipient), you may not read, use, copy or disclose to > anyone the message or any information contained in the message. If you have > received the message in error, please advise the sender by reply e-mail and > delete the message and any attachment(s) thereto without retaining any > copies. > -- Sent from my mobile device From bill at edisys.co.uk Fri Jul 2 07:28:51 2010 From: bill at edisys.co.uk (William Hamilton) Date: Fri, 02 Jul 2010 13:28:51 +0100 Subject: Please remove me from all mailing lists !!! In-Reply-To: <3DB24873-B283-4860-B423-AA40B474BF6C@americafree.tv> References: <4C2DA22C0200000D004589C7@mail.cdp.bm> <3DB24873-B283-4860-B423-AA40B474BF6C@americafree.tv> Message-ID: <4C2DDB83.9060708@edisys.co.uk> On 02/07/2010 13:20, Marshall Eubanks wrote: > At the very bottom of each message, you will see > > https://mailman.nanog.org/mailman/listinfo/nanog > > If you go there, you can unsubscribe. > > Regards > Marshall > > Was it really necessary to quote the entirety of the digest when responding? B From bclark at spectraaccess.com Fri Jul 2 07:34:57 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 02 Jul 2010 08:34:57 -0400 Subject: Please remove me from all mailing lists !!! In-Reply-To: <4C2DDB83.9060708@edisys.co.uk> References: <4C2DA22C0200000D004589C7@mail.cdp.bm> <3DB24873-B283-4860-B423-AA40B474BF6C@americafree.tv> <4C2DDB83.9060708@edisys.co.uk> Message-ID: <4C2DDCF1.90801@spectraaccess.com> On 07/02/2010 08:28 AM, William Hamilton wrote: > On 02/07/2010 13:20, Marshall Eubanks wrote: > >> At the very bottom of each message, you will see >> >> https://mailman.nanog.org/mailman/listinfo/nanog >> >> If you go there, you can unsubscribe. >> >> Regards >> Marshall >> >> >> > Was it really necessary to quote the entirety of the digest when responding? > > B > > > 28.8k Modem users... From fm-lists at st-kilda.org Fri Jul 2 07:38:28 2010 From: fm-lists at st-kilda.org (Fearghas McKay) Date: Fri, 2 Jul 2010 13:38:28 +0100 Subject: Please remove me from all mailing lists !!! In-Reply-To: <4C2DDCF1.90801@spectraaccess.com> References: <4C2DA22C0200000D004589C7@mail.cdp.bm> <3DB24873-B283-4860-B423-AA40B474BF6C@americafree.tv> <4C2DDB83.9060708@edisys.co.uk> <4C2DDCF1.90801@spectraaccess.com> Message-ID: <0508D87B-DCC2-4A05-BD15-61905E797459@st-kilda.org> On 2 Jul 2010, at 13:34, Bret Clark wrote: > 28.8k Modem users... AT&T iPhone users... the new 14.4 modem of the internet. From LarrySheldon at cox.net Fri Jul 2 08:52:42 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Fri, 02 Jul 2010 08:52:42 -0500 Subject: Please remove me from all mailing lists !!! In-Reply-To: <4C2DDB83.9060708@edisys.co.uk> References: <4C2DA22C0200000D004589C7@mail.cdp.bm> <3DB24873-B283-4860-B423-AA40B474BF6C@americafree.tv> <4C2DDB83.9060708@edisys.co.uk> Message-ID: <4C2DEF2A.4070603@cox.net> On 7/2/2010 07:28, William Hamilton wrote: > On 02/07/2010 13:20, Marshall Eubanks wrote: >> At the very bottom of each message, you will see >> >> https://mailman.nanog.org/mailman/listinfo/nanog >> >> If you go there, you can unsubscribe. >> >> Regards >> Marshall >> >> > > Was it really necessary to quote the entirety of the digest when responding? > > B > > > Was it really necessary to send the question to the whole list when clearly not one person is capable of answering it. And yes, I know I'm doing the same rude, annoying, irritating thing. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From ebw at abenaki.wabanaki.net Fri Jul 2 09:00:24 2010 From: ebw at abenaki.wabanaki.net (Eric Brunner-Williams) Date: Fri, 02 Jul 2010 10:00:24 -0400 Subject: I went so you don't have to -- ICANN Bruxelles pour les nuls Message-ID: <4C2DF0F8.9060909@abenaki.wabanaki.net> There are a few people who have some passing interest in ICANN so I will inflict upon the list my few paragraph summary of things that matter. All the past large dragons appear to have been killed or reduced to largish lizards. The Four Over Arching Issues, of which only one was real, protection of trademark holders, are sufficiently solved. On the other hand, biting off fingers as usual, are two new shiny objects for the jays and daws to chase: vertical integration of registries and registrars (VI, like, you know, the visual mode of ex, not the evil EMACS cult) and morality and decency (MoDo). How big a thrill MoDo is going to be is still TBD. Content regulation via names. Whoopie! VI is going to be put to bed one way or another by Labor Day. About VI, which has consumed my every waking hour since ... the Nairobi meeting. Prior to Nairobi the rules reflected the NetSol/VGRS breakup, and allowed registries to own approximately 15% of a registrar, and registrars to own registries. Afilias (.info) and NeuLevel (.biz) were formed under these equity restrictions. At Nairobi the Board voted that there be no cross ownership in new gTLD registries, and just prior to the Brussels meeting last week, ICANN released the 4th version of the Draft Applicant Guide, which put the cross-ownership limit at 2%. The VI activity is an attempt to articulate an alternate to the 0%, now 2%, and still fluid rule the Board may adopt prior to starting the next application round. The broad choices (and venomous camps) are: 1. things pretty much stay the same, the 15% rule with some change continues, for .com-like and .coop-like registries, insiders rule, 2. things pretty much change, with 100% cross-ownership allowed, with various proposals for the prevention of abuse by the integrated entity, for .com-like and .coop-like registries, hurray for the revolution, and 3. who cares about 1 and 2? corporations and TLD consultants want lots (like hundreds) of brands in the root, now. The VI Working Group is about as fun as USENET, though the face-to-face meetings in Brussels were surprisingly civil. Of interest to some here is covert wiggling of a subscriber-type TLD through the semi-mythical loophole for "brand" TLDs. There are walled garden serpents working the issue towards ".my-walled-garden". The ISPSG (that's the ISP -- Internet.Service.Providers Stakeholders Group) continued to drift into senility and decay with ISPs still staffing ICANN issue advocacy out of their IP (Intellectual Property) in-house counsels rather than their IP (4&6&BGP&tone&stuff) operational sides, so wakeful behavior remains confined to the ASO input to ICANN, and limited to the last v4 /8s known to LGBT and other persons. Those are the big ticket items. The Board approved adding the Han Script labels requested by .cn (China), .tw (Taiwan) and .hk (Hong Kong), which made a lot of people, me included, feel good. This is the continuation of the approvals (and awkward delegations) of Arabic Script labels and Cyrillic Script labels made earlier. The security weenies continue to whine that all the new registries should be armored up to prevent abuses that overwhelmingly occur in .com, and surprise steer well clear of treading on Verisign's toes, so in vast areas of policy life in the playpen is quite surreal. The next meeting is in December, so I finally get a Halloween at home, in Cartagena, Columbia. The usual self-and-corporate-promotion-as-news is going on over CircleID, which everyone is free to read or avoid, and if you read today's CIDR and BGP reports with more than a passing interest, and this "pour les nuls", remember the first is reality based and the second is not. And no, there still is no firm date for ICANN to start the public announcement and four months later, start accepting applications and $185,000 checks. This sentence appears to age well, I've used it without sending it out for cleaning since the Paris meeting, six meetings in a row. This exchange: > On 2 Jul 2010, at 13:34, Bret Clark wrote: > >> 28.8k Modem users... > > AT&T iPhone users... the new 14.4 modem of the internet. Had me laughing! Have a nice weekend everyone! Eric From sean at donelan.com Fri Jul 2 09:22:20 2010 From: sean at donelan.com (Sean Donelan) Date: Fri, 2 Jul 2010 10:22:20 -0400 (EDT) Subject: Finland makes broadband access a legal right In-Reply-To: References: <4C2C844B.9020507@linuxbox.org> Message-ID: On Thu, 1 Jul 2010, William Herrin wrote: > On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: >> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html?hpt=T2 > > In the US, the Communications Act of 1934 brought about the creation > of the "Universal Service Fund." The idea, more or less, was that The Universal Service Fund was created as a result of the Bell divesture in 1984; and extended by the Telecommunications Act of 1996. It didn't exist before then. There was the Kingsbury Agreement in 1913 (One System, One Policy, Universal Service), but universal service didn't mean the same thing. Universal service meant if you had a phone, it could call any other phone; but there wasn't a goal of a phone in every house until the 1960s. > every phone line customer contributed to the fund (you'll find it > itemized on your phone bill) and the phone companies had to charge the > same for every phone line regardless of where delivered in their > territory but when initially installing an unusually difficult > (expensive) phone line the phone company was entitled to reimburse its > cost from the fund. As part of the natural monopoly, there was a system of rate averaging and settlements. But there was often radically different prices based on public policy goals, for example business phone users paid more and residential phone users paid less. Long distance prices were kept high in order to keep monthly residential bills low. Its very difficult to maintain public policy price differentials in a competitive environment; but it was also difficult to maintain those prices even in a monopoly environment. The early ARPANET/Internet indirectly benefited from some of those public policy pricing decisions in the US. > In 1996 a certain inventor of the Internet decided that the universal > service fund needed to pay for PCs in rural schools (the "E-Rate" > program) instead of improving rural communications... The 1996 Universal Service Fund also expanded who paid into the fund. If the Universal Service Fund is expanded again to pay for "broadband," the biggest question is how will the "contribution base" be expanded to pay for it? From dholmes at mwdh2o.com Fri Jul 2 09:33:55 2010 From: dholmes at mwdh2o.com (Holmes,David A) Date: Fri, 2 Jul 2010 07:33:55 -0700 Subject: Finland makes broadband access a legal right In-Reply-To: References: <4C2C844B.9020507@linuxbox.org> Message-ID: <485ED9BA02629E4BBBA53AC892EDA50E0B4F9B5D@usmsxt104.mwd.h2o> Does a "... certain inventor of the Internet ..." refer to the High Performance and Communications Act of 1991, also known as the "Gore Act"? The 1991 Act, based on a study by Dr. Leonard Kleinrock ("Towards a National Research Network") created the commercial Internet that we know and work with today. -----Original Message----- From: Sean Donelan [mailto:sean at donelan.com] Sent: Friday, July 02, 2010 7:22 AM To: nanog at nanog.org Subject: Re: Finland makes broadband access a legal right On Thu, 1 Jul 2010, William Herrin wrote: > On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: >> http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html? hpt=T2 > > In the US, the Communications Act of 1934 brought about the creation > of the "Universal Service Fund." The idea, more or less, was that The Universal Service Fund was created as a result of the Bell divesture in 1984; and extended by the Telecommunications Act of 1996. It didn't exist before then. There was the Kingsbury Agreement in 1913 (One System, One Policy, Universal Service), but universal service didn't mean the same thing. Universal service meant if you had a phone, it could call any other phone; but there wasn't a goal of a phone in every house until the 1960s. > every phone line customer contributed to the fund (you'll find it > itemized on your phone bill) and the phone companies had to charge the > same for every phone line regardless of where delivered in their > territory but when initially installing an unusually difficult > (expensive) phone line the phone company was entitled to reimburse its > cost from the fund. As part of the natural monopoly, there was a system of rate averaging and settlements. But there was often radically different prices based on public policy goals, for example business phone users paid more and residential phone users paid less. Long distance prices were kept high in order to keep monthly residential bills low. Its very difficult to maintain public policy price differentials in a competitive environment; but it was also difficult to maintain those prices even in a monopoly environment. The early ARPANET/Internet indirectly benefited from some of those public policy pricing decisions in the US. > In 1996 a certain inventor of the Internet decided that the universal > service fund needed to pay for PCs in rural schools (the "E-Rate" > program) instead of improving rural communications... The 1996 Universal Service Fund also expanded who paid into the fund. If the Universal Service Fund is expanded again to pay for "broadband," the biggest question is how will the "contribution base" be expanded to pay for it? From tme at americafree.tv Fri Jul 2 09:51:13 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 2 Jul 2010 10:51:13 -0400 Subject: Finland makes broadband access a legal right In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0B4F9B5D@usmsxt104.mwd.h2o> References: <4C2C844B.9020507@linuxbox.org> <485ED9BA02629E4BBBA53AC892EDA50E0B4F9B5D@usmsxt104.mwd.h2o> Message-ID: <1429788F-C02F-4136-9F38-DC30363F9F80@americafree.tv> On Jul 2, 2010, at 10:33 AM, Holmes,David A wrote: > Does a "... certain inventor of the Internet ..." refer to the High > Performance and Communications Act of 1991, also known as the "Gore > Act"? The 1991 Act, based on a study by Dr. Leonard Kleinrock > ("Towards > a National Research Network") created the commercial Internet that we > know and work with today. > I don't know, but I do know that Larry Pressler was the sole sponsor of the Telecommunications Act of 1996, which is where E-rate came from. This was when the Republicans controlled both houses of Congress, and as far as I know Senator Gore had nothing to do with this bill; he didn't even offer any amendments. None of this is helping me configure any routers, so I am going to shut up about this now. Regards Marshall > -----Original Message----- > From: Sean Donelan [mailto:sean at donelan.com] > Sent: Friday, July 02, 2010 7:22 AM > To: nanog at nanog.org > Subject: Re: Finland makes broadband access a legal right > > On Thu, 1 Jul 2010, William Herrin wrote: >> On Thu, Jul 1, 2010 at 8:04 AM, Gadi Evron wrote: >>> > http://edition.cnn.com/2010/TECH/web/07/01/finland.broadband/index.html? > hpt=T2 >> >> In the US, the Communications Act of 1934 brought about the creation >> of the "Universal Service Fund." The idea, more or less, was that > > The Universal Service Fund was created as a result of the Bell > divesture > > in 1984; and extended by the Telecommunications Act of 1996. It > didn't > exist before then. There was the Kingsbury Agreement in 1913 (One > System, One Policy, Universal Service), but universal service didn't > mean > the same thing. Universal service meant if you had a phone, it could > call > any other phone; but there wasn't a goal of a phone in every house > until > the 1960s. > >> every phone line customer contributed to the fund (you'll find it >> itemized on your phone bill) and the phone companies had to charge >> the >> same for every phone line regardless of where delivered in their >> territory but when initially installing an unusually difficult >> (expensive) phone line the phone company was entitled to reimburse >> its >> cost from the fund. > > As part of the natural monopoly, there was a system of rate averaging > and > settlements. But there was often radically different prices based on > public policy goals, for example business phone users paid more and > residential phone users paid less. Long distance prices were kept > high > in order to keep monthly residential bills low. Its very difficult to > maintain public policy price differentials in a competitive > environment; > > but it was also difficult to maintain those prices even in a monopoly > environment. > > The early ARPANET/Internet indirectly benefited from some of those > public > policy pricing decisions in the US. > >> In 1996 a certain inventor of the Internet decided that the universal >> service fund needed to pay for PCs in rural schools (the "E-Rate" >> program) instead of improving rural communications... > > The 1996 Universal Service Fund also expanded who paid into the fund. > If > the Universal Service Fund is expanded again to pay for "broadband," > the > > biggest question is how will the "contribution base" be expanded to > pay > for it? > > > From smb at cs.columbia.edu Fri Jul 2 09:56:12 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 2 Jul 2010 10:56:12 -0400 Subject: Finland makes broadband access a legal right In-Reply-To: <1429788F-C02F-4136-9F38-DC30363F9F80@americafree.tv> References: <4C2C844B.9020507@linuxbox.org> <485ED9BA02629E4BBBA53AC892EDA50E0B4F9B5D@usmsxt104.mwd.h2o> <1429788F-C02F-4136-9F38-DC30363F9F80@americafree.tv> Message-ID: <4104476A-230F-4EB1-92EE-9D05CCC6542B@cs.columbia.edu> On Jul 2, 2010, at 10:51 13AM, Marshall Eubanks wrote: > > On Jul 2, 2010, at 10:33 AM, Holmes,David A wrote: > >> Does a "... certain inventor of the Internet ..." refer to the High >> Performance and Communications Act of 1991, also known as the "Gore >> Act"? The 1991 Act, based on a study by Dr. Leonard Kleinrock ("Towards >> a National Research Network") created the commercial Internet that we >> know and work with today. >> > > I don't know, but I do know that Larry Pressler was the sole sponsor of the Telecommunications Act of 1996, which is where E-rate came from. This was when the Republicans controlled both houses of Congress, and as far as I know Senator Gore had nothing to do with this bill; he didn't even offer any amendments. > And while Gore was president of the Senate in 1996, he wasn't Senator Gore then... --Steve Bellovin, http://www.cs.columbia.edu/~smb From bzs at world.std.com Fri Jul 2 10:23:21 2010 From: bzs at world.std.com (Barry Shein) Date: Fri, 2 Jul 2010 11:23:21 -0400 Subject: Finland makes broadband access a legal right In-Reply-To: References: <4C2C844B.9020507@linuxbox.org> Message-ID: <19502.1129.868220.56018@world.std.com> Around 1991 I offered (dial-up) internet to the school district offices in Boston for $1/month/office, 10 districts, $10/month, $120/year, shareable accounts. The person from the board of ed I was talking to said free would be a problem as it might be seen as some sort of graft etc. and might be complicated to "clean up". I figured it might let them play around with it and "inject" it into the culture and we could go from there. The person I was speaking to knew what the internet was etc. and was appreciative of the offer. It seemed like a start. A couple of weeks later she calls me and says the response from her powers that be was: If we have $120/year to waste on internet connections ``we'' can think of other uses for that $120!!!" so thanks but no thanks. The Boston education budget is about $800M today, so maybe it was $500M back then? Whatever, hundreds of millions. But they fight over the crumbs! -b From william.allen.simpson at gmail.com Fri Jul 2 10:46:43 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Fri, 02 Jul 2010 11:46:43 -0400 Subject: I went so you don't have to -- ICANN Bruxelles pour les nuls In-Reply-To: <4C2DF0F8.9060909@abenaki.wabanaki.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> Message-ID: <4C2E09E3.4080607@gmail.com> On 7/2/10 10:00 AM, Eric Brunner-Williams wrote: > There are a few people who have some passing interest in ICANN so I will inflict upon the list my few paragraph summary of things that matter. > I thank you! And I'm sure others here do too.... > The ISPSG (that's the ISP -- Internet.Service.Providers Stakeholders Group) continued to drift into senility and decay with ISPs still staffing ICANN issue advocacy out of their IP (Intellectual Property) in-house counsels rather than their IP > (4&6&BGP&tone&stuff) operational sides, so wakeful behavior remains confined to the ASO input to ICANN, and limited to the last v4 /8s known to LGBT and other persons. > Yeah, well -- I'd burned out after just 3 meetings forming ICANN, was truly unhappy about the treatment of Auerbach, and there's really not anything in the budget. I don't know how you do it. > This exchange: > >> On 2 Jul 2010, at 13:34, Bret Clark wrote: >> >>> 28.8k Modem users... >> >> AT&T iPhone users... the new 14.4 modem of the internet. > > Had me laughing! > Me, too. From cra at WPI.EDU Fri Jul 2 11:03:12 2010 From: cra at WPI.EDU (Chuck Anderson) Date: Fri, 2 Jul 2010 12:03:12 -0400 Subject: recommendations on fiber jumper diameter Message-ID: <20100702160312.GX32456@angus.ind.WPI.EDU> Does anyone have any pros/cons with using duplex 2-fiber zipcord jumpers with 2.9mm vs. 2.0mm vs. 1.6mm exterior jacket diameters? Thanks. From bzs at world.std.com Fri Jul 2 11:21:52 2010 From: bzs at world.std.com (Barry Shein) Date: Fri, 2 Jul 2010 12:21:52 -0400 Subject: I went so you don't have to -- ICANN Bruxelles pour les nuls In-Reply-To: <4C2DF0F8.9060909@abenaki.wabanaki.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> Message-ID: <19502.4640.803487.668157@world.std.com> Plus ca change, plus c'est la meme chose. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From andrew.wallace at rocketmail.com Fri Jul 2 11:22:51 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Fri, 2 Jul 2010 09:22:51 -0700 (PDT) Subject: The Economist, cyber war issue In-Reply-To: References: <4C2C9730.3040806@linuxbox.org> <390963.66769.qm@web59608.mail.ac4.yahoo.com> <4C2CE504.8070505@mompl.net> <862176.46872.qm@web59616.mail.ac4.yahoo.com> Message-ID: <23414.11068.qm@web59609.mail.ac4.yahoo.com> Why hasn't Gadi left a comment on the article? Andrew ----- Original Message ---- From: Randy Bush To: andrew.wallace Cc: Jeroen van Aart ; nanog at nanog.org Sent: Thu, 1 July, 2010 23:01:02 Subject: Re: The Economist, cyber war issue > There is a part 2 as well and this is a bug or a feature? From randy at psg.com Fri Jul 2 11:28:53 2010 From: randy at psg.com (Randy Bush) Date: Sat, 03 Jul 2010 01:28:53 +0900 Subject: The Economist, cyber war issue In-Reply-To: <23414.11068.qm@web59609.mail.ac4.yahoo.com> References: <4C2C9730.3040806@linuxbox.org> <390963.66769.qm@web59608.mail.ac4.yahoo.com> <4C2CE504.8070505@mompl.net> <862176.46872.qm@web59616.mail.ac4.yahoo.com> <23414.11068.qm@web59609.mail.ac4.yahoo.com> Message-ID: > Why hasn't Gadi left a comment on the article? who gives a damn? and if he did, i would not see it. and i'm now plonking you. kiddies! randy From streiner at cluebyfour.org Fri Jul 2 08:01:47 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 2 Jul 2010 09:01:47 -0400 (EDT) Subject: recommendations on fiber jumper diameter In-Reply-To: <20100702160312.GX32456@angus.ind.WPI.EDU> References: <20100702160312.GX32456@angus.ind.WPI.EDU> Message-ID: On Fri, 2 Jul 2010, Chuck Anderson wrote: > Does anyone have any pros/cons with using duplex 2-fiber zipcord > jumpers with 2.9mm vs. 2.0mm vs. 1.6mm exterior jacket diameters? It really depends on what you need, intended applications, etc. A thicker jacket will provide a little more protection, usually at the expense of flexibility and wire management since the thicker jacket is usually a little stiffer. This can also have the benefit of helping to prevent people from violating bend radius rules, etc... Also, some jumpers normally come with a thinner jacket. Most anything I've seen that has an LC connector on at least one end uses a thinner jacket because the thicker jacket won't work too well with LC connectors. jms From lowen at pari.edu Fri Jul 2 12:21:10 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 2 Jul 2010 13:21:10 -0400 Subject: Finland makes broadband access a legal right In-Reply-To: <19502.1129.868220.56018@world.std.com> References: <4C2C844B.9020507@linuxbox.org> Message-ID: <201007021321.10709.lowen@pari.edu> On Friday, July 02, 2010 11:23:21 am Barry Shein wrote: > The Boston education budget is about $800M today, so maybe it was > $500M back then? Whatever, hundreds of millions. But they fight over > the [$120] crumbs! "If you mind the pennies, the dollars will follow." From wadeb at cupofcompassion.com Fri Jul 2 12:52:27 2010 From: wadeb at cupofcompassion.com (Wade Blackwell) Date: Fri, 2 Jul 2010 10:52:27 -0700 Subject: IPV4/6 Playing together in the same sandbox? Message-ID: Good morning from the West coast, I have done a fair bit of reading on IPV4/6 co-existence, from what I have read these two can live together and function totally independent of one another. I have a large QA environment where they would like DHCPv6 deployed in an environment where all services are currently IPV4. There is no requirement (at this point) to route V6 out of this environment (flat V4 X.X.X.X/22). If anyone can give some practical advice on deployment strategies and gotchas that would be great. Thanks all. -W -- Wade Blackwell From cscora at apnic.net Fri Jul 2 13:13:18 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 3 Jul 2010 04:13:18 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201007021813.o62IDI6I018246@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 03 Jul, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 324314 Prefixes after maximum aggregation: 149409 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 158777 Total ASes present in the Internet Routing Table: 34277 Prefixes per ASN: 9.46 Origin-only ASes present in the Internet Routing Table: 29765 Origin ASes announcing only one prefix: 14419 Transit ASes present in the Internet Routing Table: 4512 Transit-only ASes present in the Internet Routing Table: 107 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 269 Unregistered ASNs in the Routing Table: 114 Number of 32-bit ASNs allocated by the RIRs: 657 Prefixes from 32-bit ASNs in the Routing Table: 777 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 161 Number of addresses announced to Internet: 2252946208 Equivalent to 134 /8s, 73 /16s and 59 /24s Percentage of available address space announced: 60.8 Percentage of allocated address space announced: 65.5 Percentage of available address space allocated: 92.8 Percentage of address space in use by end-sites: 83.6 Total number of prefixes smaller than registry allocations: 154912 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 78350 Total APNIC prefixes after maximum aggregation: 27003 APNIC Deaggregation factor: 2.90 Prefixes being announced from the APNIC address blocks: 75198 Unique aggregates announced from the APNIC address blocks: 33264 APNIC Region origin ASes present in the Internet Routing Table: 4098 APNIC Prefixes per ASN: 18.35 APNIC Region origin ASes announcing only one prefix: 1122 APNIC Region transit ASes present in the Internet Routing Table: 640 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 525699616 Equivalent to 31 /8s, 85 /16s and 138 /24s Percentage of available APNIC address space announced: 78.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 134542 Total ARIN prefixes after maximum aggregation: 69307 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 107370 Unique aggregates announced from the ARIN address blocks: 41845 ARIN Region origin ASes present in the Internet Routing Table: 13759 ARIN Prefixes per ASN: 7.80 ARIN Region origin ASes announcing only one prefix: 5287 ARIN Region transit ASes present in the Internet Routing Table: 1349 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 730656800 Equivalent to 43 /8s, 140 /16s and 240 /24s Percentage of available ARIN address space announced: 62.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 74631 Total RIPE prefixes after maximum aggregation: 43298 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 67750 Unique aggregates announced from the RIPE address blocks: 44478 RIPE Region origin ASes present in the Internet Routing Table: 14568 RIPE Prefixes per ASN: 4.65 RIPE Region origin ASes announcing only one prefix: 7503 RIPE Region transit ASes present in the Internet Routing Table: 2158 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 433071392 Equivalent to 25 /8s, 208 /16s and 37 /24s Percentage of available RIPE address space announced: 75.9 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 28481 Total LACNIC prefixes after maximum aggregation: 6882 LACNIC Deaggregation factor: 4.14 Prefixes being announced from the LACNIC address blocks: 27028 Unique aggregates announced from the LACNIC address blocks: 14292 LACNIC Region origin ASes present in the Internet Routing Table: 1296 LACNIC Prefixes per ASN: 20.85 LACNIC Region origin ASes announcing only one prefix: 394 LACNIC Region transit ASes present in the Internet Routing Table: 228 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 74937536 Equivalent to 4 /8s, 119 /16s and 116 /24s Percentage of available LACNIC address space announced: 55.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7313 Total AfriNIC prefixes after maximum aggregation: 1862 AfriNIC Deaggregation factor: 3.93 Prefixes being announced from the AfriNIC address blocks: 5614 Unique aggregates announced from the AfriNIC address blocks: 1738 AfriNIC Region origin ASes present in the Internet Routing Table: 378 AfriNIC Prefixes per ASN: 14.85 AfriNIC Region origin ASes announcing only one prefix: 113 AfriNIC Region transit ASes present in the Internet Routing Table: 86 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 19531520 Equivalent to 1 /8s, 42 /16s and 7 /24s Percentage of available AfriNIC address space announced: 58.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1851 8423 487 Korea Telecom (KIX) 4755 1367 295 161 TATA Communications formerly 7545 1345 232 105 TPG Internet Pty Ltd 17488 1322 140 131 Hathway IP Over Cable Interne 17974 1152 285 30 PT TELEKOMUNIKASI INDONESIA 9583 994 73 487 Sify Limited 24560 927 307 171 Bharti Airtel Ltd., Telemedia 4134 876 21292 408 CHINANET-BACKBONE 4808 827 1572 216 CNCGROUP IP network: China169 9829 810 684 41 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3910 3734 293 bellsouth.net, inc. 4323 2715 1114 394 Time Warner Telecom 19262 1825 4562 275 Verizon Global Networks 1785 1777 698 129 PaeTec Communications, Inc. 20115 1561 1520 655 Charter Communications 7018 1508 5736 957 AT&T WorldNet Services 6478 1289 260 91 AT&T Worldnet Services 2386 1282 568 906 AT&T Data Communications Serv 3356 1176 10875 404 Level 3 Communications, LLC 22773 1167 2859 65 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 648 56 6 United Telecom of Georgia 3292 452 2027 393 TDC Tele Danmark 30890 443 111 205 Evolva Telecom 702 411 1869 327 UUNET - Commercial IP service 9198 408 202 13 Kazakhtelecom Data Network Ad 8866 402 117 18 Bulgarian Telecommunication C 8551 400 353 46 Bezeq International 3320 373 7329 324 Deutsche Telekom AG 3301 372 1414 327 TeliaNet Sweden 34984 360 89 185 BILISIM TELEKOM Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1518 3017 245 UniNet S.A. de C.V. 10620 1066 238 150 TVCABLE BOGOTA 28573 1023 791 97 NET Servicos de Comunicao S.A 7303 748 385 106 Telecom Argentina Stet-France 6503 554 137 183 AVANTEL, S.A. 22047 548 310 15 VTR PUNTO NET S.A. 3816 495 217 81 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 14420 471 33 69 ANDINATEL S.A. 11172 449 99 76 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1152 445 10 TEDATA 24863 728 147 39 LINKdotNET AS number 36992 644 279 184 Etisalat MISR 3741 267 834 228 The Internet Solution 33776 219 12 11 Starcomms Nigeria Limited 2018 210 244 61 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 24835 192 78 10 RAYA Telecom - Egypt 29571 176 19 10 Ci Telecom Autonomous system 29975 133 506 14 Vodacom Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3910 3734 293 bellsouth.net, inc. 4323 2715 1114 394 Time Warner Telecom 4766 1851 8423 487 Korea Telecom (KIX) 19262 1825 4562 275 Verizon Global Networks 1785 1777 698 129 PaeTec Communications, Inc. 20115 1561 1520 655 Charter Communications 8151 1518 3017 245 UniNet S.A. de C.V. 7018 1508 5736 957 AT&T WorldNet Services 4755 1367 295 161 TATA Communications formerly 7545 1345 232 105 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2715 2321 Time Warner Telecom 1785 1777 1648 PaeTec Communications, Inc. 19262 1825 1550 Verizon Global Networks 4766 1851 1364 Korea Telecom (KIX) 8151 1518 1273 UniNet S.A. de C.V. 7545 1345 1240 TPG Internet Pty Ltd 4755 1367 1206 TATA Communications formerly 6478 1289 1198 AT&T Worldnet Services 17488 1322 1191 Hathway IP Over Cable Interne 8452 1152 1142 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:25 /11:68 /12:196 /13:406 /14:707 /15:1285 /16:11156 /17:5338 /18:9126 /19:18399 /20:22806 /21:22871 /22:29932 /23:29604 /24:169130 /25:1031 /26:1320 /27:707 /28:117 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2504 3910 bellsouth.net, inc. 4766 1482 1851 Korea Telecom (KIX) 4323 1396 2715 Time Warner Telecom 1785 1239 1777 PaeTec Communications, Inc. 11492 1070 1160 Cable One 17488 1069 1322 Hathway IP Over Cable Interne 18566 1069 1088 Covad Communications 8452 1040 1152 TEDATA 10620 982 1066 TVCABLE BOGOTA 7018 911 1508 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:6 2:10 4:13 8:286 12:2012 13:7 14:1 15:23 16:3 17:8 20:17 24:1452 27:187 31:1 32:48 33:12 38:679 40:98 41:2440 44:3 47:12 52:9 55:4 56:2 57:25 58:749 59:501 60:459 61:1090 62:1055 63:1977 64:3659 65:2361 66:4037 67:1810 68:1105 69:2874 70:723 71:380 72:1953 73:2 74:2263 75:253 76:313 77:952 78:604 79:437 80:981 81:799 82:489 83:435 84:710 85:1053 86:452 87:678 88:342 89:1567 90:93 91:2847 92:489 93:985 94:1400 95:637 96:352 97:207 98:574 99:29 108:97 109:551 110:364 111:535 112:266 113:315 114:427 115:563 116:1073 117:661 118:483 119:944 120:127 121:728 122:1452 123:927 124:1122 125:1321 128:226 129:202 130:196 131:555 132:251 133:17 134:197 135:42 136:241 137:159 138:264 139:104 140:480 141:198 142:346 143:392 144:452 145:50 146:435 147:168 148:606 149:301 150:149 151:230 152:302 153:169 154:2 155:328 156:157 157:319 158:107 159:378 160:316 161:181 162:254 163:176 164:408 165:365 166:462 167:404 168:652 169:157 170:713 171:58 172:2 173:875 174:468 175:105 176:1 178:248 180:516 182:147 183:228 184:103 186:487 187:387 188:993 189:744 190:3742 192:5739 193:4714 194:3365 195:2798 196:1181 198:3573 199:3452 200:5258 201:1523 202:7942 203:8278 204:4070 205:2339 206:2521 207:3105 208:3871 209:3443 210:2523 211:1265 212:1694 213:1666 214:637 215:68 216:4659 217:1522 218:493 219:379 220:1134 221:398 222:314 223:1 End of report From Crist.Clark at globalstar.com Fri Jul 2 13:46:43 2010 From: Crist.Clark at globalstar.com (Crist Clark) Date: Fri, 02 Jul 2010 11:46:43 -0700 Subject: Inquiries to Acquire IPs Message-ID: <4C2DD19B.33E4.0097.1@globalstar.com> We got a strange and out of the blue inquiry from someone wishing to pay us for a chunk of our ARIN allocation, > Hello, > > According to Whois data, you company owns the following > IP address space: > > 206.220.220.0/24 > > We would like to get this block of IP addresses for our business > needs. Is it possible to assign this block for our company with > PI (Provider Independent) or PA (Provider Assigned) status? > > We ready to pay about $5,000 for the net block itself > and all related procedures. > > Would you be interested in such an offer? The amount of compensation > is subject to negotiation. We're not interested, mostly because we use our allocation, but also because I think this is not allowed by our agreement with ARIN. Seems a bit fishy. I should add the sender identified himself and his company clearly. It wasn't from some free mail account. (Although it could of course be spoofed.) Is this a new thing? IP speculation as we come upon free pool depletion? A front for spammers? From sethm at rollernet.us Fri Jul 2 13:56:06 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 02 Jul 2010 11:56:06 -0700 Subject: Inquiries to Acquire IPs In-Reply-To: <4C2DD19B.33E4.0097.1@globalstar.com> References: <4C2DD19B.33E4.0097.1@globalstar.com> Message-ID: <4C2E3646.7080807@rollernet.us> On 7/2/2010 11:46, Crist Clark wrote: > We got a strange and out of the blue inquiry from someone > wishing to pay us for a chunk of our ARIN allocation, > >> Hello, >> >> According to Whois data, you company owns the following >> IP address space: >> >> 206.220.220.0/24 >> >> We would like to get this block of IP addresses for our business >> needs. Is it possible to assign this block for our company with >> PI (Provider Independent) or PA (Provider Assigned) status? >> >> We ready to pay about $5,000 for the net block itself >> and all related procedures. >> >> Would you be interested in such an offer? The amount of compensation >> is subject to negotiation. > > We're not interested, mostly because we use our allocation, > but also because I think this is not allowed by our agreement > with ARIN. Seems a bit fishy. > > I should add the sender identified himself and his company > clearly. It wasn't from some free mail account. (Although it > could of course be spoofed.) > > Is this a new thing? IP speculation as we come upon free pool > depletion? A front for spammers? > Not a new thing. Usually they're looking for ways around ARIN's rules or they just want to "borrow" your IP space. In the latter case they'll just use the block for some limited period of time (such as for sending spam) and return it to you when they're done. ~Seth From heather.schiller at verizonbusiness.com Fri Jul 2 14:08:48 2010 From: heather.schiller at verizonbusiness.com (Schiller, Heather A (HeatherSkanks)) Date: Fri, 02 Jul 2010 19:08:48 +0000 Subject: Inquiries to Acquire IPs In-Reply-To: <4C2DD19B.33E4.0097.1@globalstar.com> References: <4C2DD19B.33E4.0097.1@globalstar.com> Message-ID: +2 so far here.. Same email, same guy, different netblocks. Spamming for IP's to spam with? --heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241 security at verizonbusiness.com -----Original Message----- From: Crist Clark [mailto:Crist.Clark at globalstar.com] Sent: Friday, July 02, 2010 2:47 PM To: Nanog Subject: Inquiries to Acquire IPs We got a strange and out of the blue inquiry from someone wishing to pay us for a chunk of our ARIN allocation, > Hello, > > According to Whois data, you company owns the following IP address > space: > > 206.220.220.0/24 > > We would like to get this block of IP addresses for our business > needs. Is it possible to assign this block for our company with PI > (Provider Independent) or PA (Provider Assigned) status? > > We ready to pay about $5,000 for the net block itself and all related > procedures. > > Would you be interested in such an offer? The amount of compensation > is subject to negotiation. We're not interested, mostly because we use our allocation, but also because I think this is not allowed by our agreement with ARIN. Seems a bit fishy. I should add the sender identified himself and his company clearly. It wasn't from some free mail account. (Although it could of course be spoofed.) Is this a new thing? IP speculation as we come upon free pool depletion? A front for spammers? From owen at delong.com Fri Jul 2 14:07:48 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 2 Jul 2010 12:07:48 -0700 Subject: Inquiries to Acquire IPs In-Reply-To: <4C2DD19B.33E4.0097.1@globalstar.com> References: <4C2DD19B.33E4.0097.1@globalstar.com> Message-ID: On Jul 2, 2010, at 11:46 AM, Crist Clark wrote: > We got a strange and out of the blue inquiry from someone > wishing to pay us for a chunk of our ARIN allocation, > >> Hello, >> >> According to Whois data, you company owns the following >> IP address space: >> >> 206.220.220.0/24 >> >> We would like to get this block of IP addresses for our business >> needs. Is it possible to assign this block for our company with >> PI (Provider Independent) or PA (Provider Assigned) status? >> >> We ready to pay about $5,000 for the net block itself >> and all related procedures. >> >> Would you be interested in such an offer? The amount of compensation >> is subject to negotiation. > > We're not interested, mostly because we use our allocation, > but also because I think this is not allowed by our agreement > with ARIN. Seems a bit fishy. > > I should add the sender identified himself and his company > clearly. It wasn't from some free mail account. (Although it > could of course be spoofed.) > > Is this a new thing? IP speculation as we come upon free pool > depletion? A front for spammers? > They would have to justify their need with ARIN prior to the transfer actually taking effect, but, this is now allowed for /22 and shorter under NRPM 8.3 (for better or worse). However, at the current time, if they can justify an IPv4 /24 under ARIN policy, they're better off to wait for the board to approve proposal 2010-2 (which the AC forwarded to the board for final adoption at our last meeting) and simply apply directly to ARIN. Once that proposal is enacted by the board, it would also be possible to effectuate the transfer they described, but, they would still have to demonstrate their need for the space to ARIN in order for the transfer to happen. Since they can get the same block from ARIN as an end user until IPv4 runout for $1250 initial and $100/year, I don't see why they would want to pay $5000 for it under the same terms. Owen From msmith at internap.com Fri Jul 2 14:14:59 2010 From: msmith at internap.com (Michael Smith) Date: Fri, 2 Jul 2010 15:14:59 -0400 Subject: Inquiries to Acquire IPs In-Reply-To: References: <4C2DD19B.33E4.0097.1@globalstar.com> Message-ID: <65C5927BEED3C2428307863DB5C6C6FB04226957@cx49.800onemail.com> Feel free to share the sender's "identity" in case they happen to actually be a paying customer of any of us on the list... -----Original Message----- From: Schiller, Heather A (HeatherSkanks) [mailto:heather.schiller at verizonbusiness.com] Sent: Friday, July 02, 2010 3:09 PM To: Crist Clark; Nanog Subject: RE: Inquiries to Acquire IPs +2 so far here.. Same email, same guy, different netblocks. Spamming for IP's to spam with? --heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241 security at verizonbusiness.com -----Original Message----- From: Crist Clark [mailto:Crist.Clark at globalstar.com] Sent: Friday, July 02, 2010 2:47 PM To: Nanog Subject: Inquiries to Acquire IPs We got a strange and out of the blue inquiry from someone wishing to pay us for a chunk of our ARIN allocation, > Hello, > > According to Whois data, you company owns the following IP address > space: > > 206.220.220.0/24 > > We would like to get this block of IP addresses for our business > needs. Is it possible to assign this block for our company with PI > (Provider Independent) or PA (Provider Assigned) status? > > We ready to pay about $5,000 for the net block itself and all related > procedures. > > Would you be interested in such an offer? The amount of compensation > is subject to negotiation. We're not interested, mostly because we use our allocation, but also because I think this is not allowed by our agreement with ARIN. Seems a bit fishy. I should add the sender identified himself and his company clearly. It wasn't from some free mail account. (Although it could of course be spoofed.) Is this a new thing? IP speculation as we come upon free pool depletion? A front for spammers? From mike at mtcc.com Fri Jul 2 14:17:14 2010 From: mike at mtcc.com (Michael Thomas) Date: Fri, 02 Jul 2010 12:17:14 -0700 Subject: Inquiries to Acquire IPs In-Reply-To: References: <4C2DD19B.33E4.0097.1@globalstar.com> Message-ID: <4C2E3B3A.9090707@mtcc.com> Schiller, Heather A (HeatherSkanks) wrote: > +2 so far here.. Same email, same guy, different netblocks. Spamming > for IP's to spam with? $5k payable in faked viagra, no doubt. Mike From osilva at scuff.cc.utexas.edu Fri Jul 2 14:22:53 2010 From: osilva at scuff.cc.utexas.edu (Oscar Ricardo Silva) Date: Fri, 02 Jul 2010 14:22:53 -0500 Subject: Inquiries to Acquire IPs In-Reply-To: <4C2DD19B.33E4.0097.1@globalstar.com> References: <4C2DD19B.33E4.0097.1@globalstar.com> Message-ID: <4C2E3C8D.4010409@scuff.cc.utexas.edu> On 07/02/2010 01:46 PM, Crist Clark wrote: > We got a strange and out of the blue inquiry from someone > wishing to pay us for a chunk of our ARIN allocation, > >> Hello, >> >> According to Whois data, you company owns the following >> IP address space: >> >> 206.220.220.0/24 >> >> We would like to get this block of IP addresses for our business >> needs. Is it possible to assign this block for our company with >> PI (Provider Independent) or PA (Provider Assigned) status? >> >> We ready to pay about $5,000 for the net block itself >> and all related procedures. >> >> Would you be interested in such an offer? The amount of compensation >> is subject to negotiation. > > We're not interested, mostly because we use our allocation, > but also because I think this is not allowed by our agreement > with ARIN. Seems a bit fishy. > > I should add the sender identified himself and his company > clearly. It wasn't from some free mail account. (Although it > could of course be spoofed.) > > Is this a new thing? IP speculation as we come upon free pool > depletion? A front for spammers? Yeah, we received the same kind of offer here. Here's the message in full: ****************************** Hello, According to Whois data, you company owns the following IP address space: 146.6.6.0/24 We would like to get this block of IP addresses for our business needs. Is it possible to assign this block for our company with PI (Provider Independent) or PA (Provider Assigned) status? We ready to pay about $5,000 for the net block itself and all related procedures. Would you be interested in such an offer? The amount of compensation is subject to negotiation. -- Kind regards, Sergey Gotsulyak Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: goz at idecogateway.com Web: www.idecogateway.com ****************************** Oscar From kevin at steadfast.net Fri Jul 2 14:26:55 2010 From: kevin at steadfast.net (Kevin Stange) Date: Fri, 02 Jul 2010 14:26:55 -0500 Subject: Inquiries to Acquire IPs In-Reply-To: <4C2E3C8D.4010409@scuff.cc.utexas.edu> References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> Message-ID: <4C2E3D7F.9040309@steadfast.net> On 07/02/2010 02:22 PM, Oscar Ricardo Silva wrote: > On 07/02/2010 01:46 PM, Crist Clark wrote: >> We got a strange and out of the blue inquiry from someone >> wishing to pay us for a chunk of our ARIN allocation, >> >>> Hello, >>> >>> According to Whois data, you company owns the following >>> IP address space: >>> >>> 206.220.220.0/24 > 146.6.6.0/24 Anyone else notice they seem to be looking for IP blocks where the middle octets are the same? How could that specific quality be worth $5K? -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From Crist.Clark at globalstar.com Fri Jul 2 14:27:44 2010 From: Crist.Clark at globalstar.com (Crist Clark) Date: Fri, 02 Jul 2010 12:27:44 -0700 Subject: Inquiries to Acquire IPs In-Reply-To: <4C2DD19B.33E4.0097.1@globalstar.com> References: <4C2DD19B.33E4.0097.1@globalstar.com> Message-ID: <4C2DDB38.33E4.0097.1@globalstar.com> Bingo! >From an off list response, it looks like this is someone searching for "memorable" (note the range he inquired about with us has the repeated 220 octets in the middle) IP addresses for some project. The email we received was apparently from the same Sergey Gotsulyak of Ideco sent this to a RIPE list, http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2010/msg00038.html On 7/2/2010 at 11:46 AM, "Crist Clark" wrote: > We got a strange and out of the blue inquiry from someone > wishing to pay us for a chunk of our ARIN allocation, > >> Hello, >> >> According to Whois data, you company owns the following >> IP address space: >> >> 206.220.220.0/24 >> >> We would like to get this block of IP addresses for our business >> needs. Is it possible to assign this block for our company with >> PI (Provider Independent) or PA (Provider Assigned) status? >> >> We ready to pay about $5,000 for the net block itself >> and all related procedures. >> >> Would you be interested in such an offer? The amount of compensation >> is subject to negotiation. > > We're not interested, mostly because we use our allocation, > but also because I think this is not allowed by our agreement > with ARIN. Seems a bit fishy. > > I should add the sender identified himself and his company > clearly. It wasn't from some free mail account. (Although it > could of course be spoofed.) > > Is this a new thing? IP speculation as we come upon free pool > depletion? A front for spammers? From morrowc.lists at gmail.com Fri Jul 2 14:29:35 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 2 Jul 2010 15:29:35 -0400 Subject: Inquiries to Acquire IPs In-Reply-To: <4C2E3C8D.4010409@scuff.cc.utexas.edu> References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> Message-ID: On Fri, Jul 2, 2010 at 3:22 PM, Oscar Ricardo Silva wrote: > On 07/02/2010 01:46 PM, Crist Clark wrote: >> >> We got a strange and out of the blue inquiry from someone >> wishing to pay us for a chunk of our ARIN allocation, >> >>> Hello, >>> >>> According to Whois data, you company owns the following >>> IP address space: >>> >>> 206.220.220.0/24 >>> >>> We would like to get this block of IP addresses for our business >>> needs. Is it possible to assign this block for our company with >>> PI (Provider Independent) or PA (Provider Assigned) status? >>> >>> We ready to pay about $5,000 for the net block itself >>> and all related procedures. >>> >>> Would you be interested in such an offer? The amount of compensation >>> is subject to negotiation. >> >> We're not interested, mostly because we use our allocation, >> but also because I think this is not allowed by our agreement >> with ARIN. Seems a bit fishy. >> >> I should add the sender identified himself and his company >> clearly. It wasn't from some free mail account. (Although it >> could of course be spoofed.) >> >> Is this a new thing? IP speculation as we come upon free pool >> depletion? A front for spammers? > > > Yeah, we received the same kind of offer here. ?Here's the message in full: > > ****************************** > Hello, > > According to Whois data, you company owns the following > IP address space: > > 146.6.6.0/24 > > We would like to get this block of IP addresses for our business > needs. Is it possible to assign this block for our company with > PI (Provider Independent) or PA (Provider Assigned) status? > > We ready to pay about $5,000 for the net block itself > and all related procedures. > > Would you be interested in such an offer? The amount of compensation > is subject to negotiation. > > -- > Kind regards, > Sergey Gotsulyak http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2010/msg00038.html http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2010/msg00039.html > > Ideco Sales Team > 280 Madison Ave, Suite 912 > New York, NY 10016 > > Phone: (800) 715-3502 > Email: goz at idecogateway.com > Web: www.idecogateway.com > ****************************** > > > Oscar > > From sethm at rollernet.us Fri Jul 2 14:31:09 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 02 Jul 2010 12:31:09 -0700 Subject: Inquiries to Acquire IPs In-Reply-To: References: <4C2DD19B.33E4.0097.1@globalstar.com> Message-ID: <4C2E3E7D.7040006@rollernet.us> On 7/2/2010 12:07, Owen DeLong wrote: > > They would have to justify their need with ARIN prior to the transfer > actually taking effect, but, this is now allowed for /22 and shorter > under NRPM 8.3 (for better or worse). > My gut tells me they aren't looking for a transfer. I've been through this last year with someone originally approached me about doing a colo, then started waffling when it came to how much space and power they needed. It turns out they only wanted to borrow various /24's for a few months and would return them when done. ~Seth From jess.kitchen at adjacentnetworks.net Fri Jul 2 14:33:23 2010 From: jess.kitchen at adjacentnetworks.net (Jess Kitchen) Date: Fri, 2 Jul 2010 20:33:23 +0100 (BST) Subject: Inquiries to Acquire IPs In-Reply-To: <4C2E3D7F.9040309@steadfast.net> References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> Message-ID: On Fri, 2 Jul 2010, Kevin Stange wrote: >>>> Hello, >>>> >>>> According to Whois data, you company owns the following >>>> IP address space: >>>> >>>> 206.220.220.0/24 > >> 146.6.6.0/24 > > Anyone else notice they seem to be looking for IP blocks where the > middle octets are the same? How could that specific quality be worth $5K? They are vanity IPs for use with an anycast DNS service From richard.barnes at gmail.com Fri Jul 2 14:49:34 2010 From: richard.barnes at gmail.com (Richard Barnes) Date: Fri, 2 Jul 2010 15:49:34 -0400 Subject: Inquiries to Acquire IPs In-Reply-To: References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> Message-ID: Maybe APNIC should give him 1.1.1.1 and see how he likes it! On Fri, Jul 2, 2010 at 3:33 PM, Jess Kitchen wrote: > On Fri, 2 Jul 2010, Kevin Stange wrote: > >>>>> Hello, >>>>> >>>>> According to Whois data, you company owns the following >>>>> IP address space: >>>>> >>>>> 206.220.220.0/24 >> >>> 146.6.6.0/24 >> >> Anyone else notice they seem to be looking for IP blocks where the >> middle octets are the same? ?How could that specific quality be worth $5K? > > They are vanity IPs for use with an anycast DNS service > > From internetplumber at gmail.com Fri Jul 2 15:48:06 2010 From: internetplumber at gmail.com (Rob Evans) Date: Fri, 2 Jul 2010 21:48:06 +0100 Subject: Inquiries to Acquire IPs In-Reply-To: References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> Message-ID: I saw a few reports of those today and wrote a short note to forewarn some other European R&E networks, plus our customers. http://webmedia.company.ja.net/edlabblogs/developmenteye/2010/07/03/wanted-memorable-24-for-us5k/ Yup, I know the date on the blog is off by one. :) Cheers, Rob From mloftis at wgops.com Fri Jul 2 16:21:26 2010 From: mloftis at wgops.com (Michael Loftis) Date: Fri, 02 Jul 2010 15:21:26 -0600 Subject: Inquiries to Acquire IPs In-Reply-To: References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> Message-ID: <88BEEEB6B0C5FF34BA349538@[192.168.1.100]> Makes one wonder what dead:beef::/32 and c0ff:ee00::/32 will go for? :) --On Friday, July 02, 2010 9:48 PM +0100 Rob Evans wrote: > I saw a few reports of those today and wrote a short note to forewarn > some other European R&E networks, plus our customers. > > http://webmedia.company.ja.net/edlabblogs/developmenteye/2010/07/03/wante > d-memorable-24-for-us5k/ > > Yup, I know the date on the blog is off by one. :) > > Cheers, > Rob > From dwhite at olp.net Fri Jul 2 16:36:04 2010 From: dwhite at olp.net (Dan White) Date: Fri, 2 Jul 2010 16:36:04 -0500 Subject: Inquiries to Acquire IPs In-Reply-To: <88BEEEB6B0C5FF34BA349538@[192.168.1.100]> References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> <88BEEEB6B0C5FF34BA349538@[192.168.1.100]> Message-ID: <20100702213604.GK2395@dan.olp.net> On 02/07/10?15:21?-0600, Michael Loftis wrote: > Makes one wonder what dead:beef::/32 and c0ff:ee00::/32 will go for? :) Even more off topic: No match found for cafe:d00d:4:cafe:babe::/32 -- Dan White From kurt at honeycomb.net Fri Jul 2 16:39:02 2010 From: kurt at honeycomb.net (Kurt Anderson) Date: Fri, 2 Jul 2010 16:39:02 -0500 Subject: Inquiries to Acquire IPs References: <4C2DD19B.33E4.0097.1@globalstar.com><4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> <88BEEEB6B0C5FF34BA349538@[192.168.1.100]> Message-ID: <64975B31C6249247A722D0610F4110F7017FF23E@hive.officespace.honeycomb.net> Did someone say they had fake viagera? -----Original Message----- From: Michael Loftis [mailto:mloftis at wgops.com] Sent: Friday, July 02, 2010 4:21 PM To: nanog at nanog.org Subject: Re: Inquiries to Acquire IPs Makes one wonder what dead:beef::/32 and c0ff:ee00::/32 will go for? :) --On Friday, July 02, 2010 9:48 PM +0100 Rob Evans wrote: > I saw a few reports of those today and wrote a short note to forewarn > some other European R&E networks, plus our customers. > > http://webmedia.company.ja.net/edlabblogs/developmenteye/2010/07/03/want e > d-memorable-24-for-us5k/ > > Yup, I know the date on the blog is off by one. :) > > Cheers, > Rob > From aaron at wholesaleinternet.net Fri Jul 2 16:40:07 2010 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Fri, 2 Jul 2010 16:40:07 -0500 Subject: Inquiries to Acquire IPs In-Reply-To: <20100702213604.GK2395@dan.olp.net> References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> <88BEEEB6B0C5FF34BA349538@[192.168.1.100]> <20100702213604.GK2395@dan.olp.net> Message-ID: <00bb01cb1a2f$239232c0$6ab69840$@net> I sent an inquiry in to ARIN yesterday for a certain ASN that was available and was told that management won't allow them to issue requested numbers. :( Aaron -----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: Friday, July 02, 2010 4:36 PM To: Michael Loftis Cc: nanog at nanog.org Subject: Re: Inquiries to Acquire IPs On 02/07/10?15:21?-0600, Michael Loftis wrote: > Makes one wonder what dead:beef::/32 and c0ff:ee00::/32 will go for? :) Even more off topic: No match found for cafe:d00d:4:cafe:babe::/32 -- Dan White No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.830 / Virus Database: 271.1.1/2977 - Release Date: 07/02/10 01:35:00 From cidr-report at potaroo.net Fri Jul 2 17:00:03 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Jul 2010 22:00:03 GMT Subject: BGP Update Report Message-ID: <201007022200.o62M03Km035165@wattle.apnic.net> BGP Update Report Interval: 24-Jun-10 -to- 01-Jul-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS6298 105080 6.2% 39.2 -- ASN-CXA-PH-6298-CBS - Cox Communications Inc. 2 - AS9808 72242 4.2% 164.2 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 3 - AS24400 69052 4.1% 5754.3 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 4 - AS22773 23744 1.4% 14.5 -- ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 5 - AS14420 23556 1.4% 49.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 6 - AS210 19720 1.2% 54.8 -- WEST-NET-WEST - Utah Education Network 7 - AS5800 17170 1.0% 79.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 8 - AS9116 15708 0.9% 29.7 -- GOLDENLINES-ASN 012 Smile Communications Main Autonomous System 9 - AS35931 13107 0.8% 2184.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 10 - AS32528 13049 0.8% 1631.1 -- ABBOTT Abbot Labs 11 - AS577 11432 0.7% 17.7 -- BACOM - Bell Canada 12 - AS10474 10432 0.6% 267.5 -- NETACTIVE 13 - AS18910 9606 0.6% 600.4 -- BIG-SANDY-BROADBAND-INC - Big Sandy Broadband Inc 14 - AS8151 9388 0.6% 6.1 -- Uninet S.A. de C.V. 15 - AS17974 9251 0.5% 8.1 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 16 - AS45464 9109 0.5% 211.8 -- NEXTWEB-AS-AP Room 201, TGU Bldg 17 - AS7552 9069 0.5% 10.9 -- VIETEL-AS-AP Vietel Corporation 18 - AS14522 9053 0.5% 26.8 -- Satnet 19 - AS7459 7700 0.5% 32.1 -- GRANDECOM-AS1 - Grande Communications Networks, Inc. 20 - AS36992 7588 0.5% 11.7 -- ETISALAT-MISR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS24400 69052 4.1% 5754.3 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 2 - AS35931 13107 0.8% 2184.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS32528 13049 0.8% 1631.1 -- ABBOTT Abbot Labs 4 - AS30372 2446 0.1% 1223.0 -- SBS-NEWARK-CA - SIEMENS BUSINESS SERVICES 5 - AS11613 762 0.0% 762.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 6 - AS55482 1266 0.1% 633.0 -- DIGITAL-WAVE-MY Level 12 Menara Sunway, Jalan Lagoon Timur, 7 - AS18910 9606 0.6% 600.4 -- BIG-SANDY-BROADBAND-INC - Big Sandy Broadband Inc 8 - AS38596 288 0.0% 288.0 -- INNODATA-MDE-AS-PH Innodata-ISOGEN, Inc 9 - AS45936 285 0.0% 285.0 -- AE-MANILA-AS-AP Affinity Express 10 - AS9556 1697 0.1% 282.8 -- ADAM-AS-AP Adam Internet Pty Ltd 11 - AS10474 10432 0.6% 267.5 -- NETACTIVE 12 - AS28863 253 0.0% 253.0 -- THALES-TTLS Thales Transport and Security Ltd 13 - AS45598 1260 0.1% 252.0 -- BLUEMEDIACOM-PH Unit 503 5th Floor Net One Center 14 - AS21115 245 0.0% 245.0 -- AS-NESTLE NESTLE Autonomous System 15 - AS45647 486 0.0% 243.0 -- LBCBANK-AS-AP LBC Development Bank 16 - AS17894 5089 0.3% 242.3 -- APMI-AS-AP AyalaPort Makati, Inc. / Data Center Operator 17 - AS23964 241 0.0% 241.0 -- GLOBALSTRIDE-AS-AP Globalstride 18 - AS18249 481 0.0% 240.5 -- GLOBEIDC-AS-AP Globe Telecom Internet Data Center 19 - AS9821 240 0.0% 240.0 -- DOST-PH-AP Department of Science and Technology 20 - AS9232 240 0.0% 240.0 -- CONCENTRIX-PH-AS-AP Concentrix Technologies, Inc TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 111.10.4.0/24 14236 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 2 - 111.10.3.0/24 14231 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 3 - 111.10.0.0/24 14229 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 4 - 111.10.2.0/24 14227 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 5 - 111.10.1.0/24 14225 0.8% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 6 - 196.2.16.0/24 10315 0.6% AS10474 -- NETACTIVE 7 - 117.131.0.0/17 10062 0.6% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 8 - 120.204.0.0/16 9886 0.5% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 9 - 117.136.8.0/24 9834 0.5% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 10 - 117.135.128.0/18 9735 0.5% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 11 - 117.135.0.0/17 9724 0.5% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 12 - 198.140.43.0/24 7497 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - 130.36.34.0/24 6507 0.4% AS32528 -- ABBOTT Abbot Labs 14 - 130.36.35.0/24 6506 0.4% AS32528 -- ABBOTT Abbot Labs 15 - 190.65.228.0/22 6110 0.3% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 16 - 221.181.64.0/18 5973 0.3% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 17 - 63.211.68.0/22 5531 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 18 - 143.138.107.0/24 4251 0.2% AS747 -- TAEGU-AS - Headquarters, USAISC 19 - 211.136.96.0/19 3461 0.2% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 20 - 211.136.128.0/19 3459 0.2% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 2 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 2 Jul 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201007022200.o62M003G035155@wattle.apnic.net> This report has been generated at Fri Jul 2 21:11:38 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 25-06-10 326998 202457 26-06-10 327077 202580 27-06-10 327276 202660 28-06-10 327386 202922 29-06-10 327417 203125 30-06-10 327486 202384 01-07-10 327556 202237 02-07-10 328551 201923 AS Summary 34754 Number of ASes in routing system 14757 Number of ASes announcing only one prefix 4474 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 95976768 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 02Jul10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 328253 201959 126294 38.5% All ASes AS6389 3908 296 3612 92.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4474 1749 2725 60.9% TWTC - tw telecom holdings, inc. AS19262 1824 274 1550 85.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4766 1851 501 1350 72.9% KIXS-AS-KR Korea Telecom AS22773 1166 70 1096 94.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17488 1322 318 1004 75.9% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1367 375 992 72.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS6478 1288 318 970 75.3% ATT-INTERNET3 - AT&T WorldNet Services AS10620 1066 155 911 85.5% Telmex Colombia S.A. AS8151 1518 615 903 59.5% Uninet S.A. de C.V. AS18566 1087 267 820 75.4% COVAD - Covad Communications Co. AS5668 922 134 788 85.5% AS-5668 - CenturyTel Internet Holdings, Inc. AS7545 1357 581 776 57.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS8452 1152 392 760 66.0% TEDATA TEDATA AS7303 749 119 630 84.1% Telecom Argentina S.A. AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS4808 827 236 591 71.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS35805 648 57 591 91.2% SILKNET-AS SILKNET AS AS7018 1508 959 549 36.4% ATT-INTERNET4 - AT&T WorldNet Services AS4780 684 164 520 76.0% SEEDNET Digital United Inc. AS3356 1178 663 515 43.7% LEVEL3 Level 3 Communications AS7552 653 153 500 76.6% VIETEL-AS-AP Vietel Corporation AS28573 1023 526 497 48.6% NET Servicos de Comunicao S.A. AS9443 570 75 495 86.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 578 83 495 85.6% GIGAINFRA Softbank BB Corp. AS1785 1777 1284 493 27.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS7011 1133 652 481 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS24560 927 471 456 49.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS33588 642 187 455 70.9% BRESNAN-AS - Bresnan Communications, LLC. AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. Total 38354 11776 26578 69.3% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS16637 MTNNS-AS 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.169.96.0/24 AS7545 TPG-INTERNET-AP TPG Internet Pty Ltd 202.169.98.0/24 AS10143 EXETEL-AS-AP Exetel Pty Ltd 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From mpalmer at hezmatt.org Fri Jul 2 17:14:07 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 3 Jul 2010 08:14:07 +1000 Subject: Inquiries to Acquire IPs In-Reply-To: <00bb01cb1a2f$239232c0$6ab69840$@net> References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> <88BEEEB6B0C5FF34BA349538@[192.168.1.100]> <20100702213604.GK2395@dan.olp.net> <00bb01cb1a2f$239232c0$6ab69840$@net> Message-ID: <20100702221407.GE7566@hezmatt.org> On Fri, Jul 02, 2010 at 04:40:07PM -0500, Aaron Wendel wrote: > I sent an inquiry in to ARIN yesterday for a certain ASN that was available > and was told that management won't allow them to issue requested numbers. :( That's easy, then... "Can I have any of ASN 0 to $DESIRED-1 or $DESIRED+1 to 65535"... since they can't issue a number that's requested, the one you want is the only one left. - Matt (Back into my hole) From gerren.murphy at gmail.com Fri Jul 2 18:01:40 2010 From: gerren.murphy at gmail.com (Gerren Murphy) Date: Fri, 2 Jul 2010 19:01:40 -0400 Subject: OT: Career Advice Message-ID: Hello All, Anyone out there willing to entertain a few career advice-related questions off list? Nothing too deep, I promise, just a little advice from those of you who have been in the industry a bit longer than I have? Thanks for any and all assistance, and have a great weekend. From asr+nanog at latency.net Fri Jul 2 18:04:42 2010 From: asr+nanog at latency.net (Adam Rothschild) Date: Fri, 2 Jul 2010 19:04:42 -0400 Subject: XO feedback In-Reply-To: References: Message-ID: <20100702230442.GA95331@latency.net> Here in the New York Metro, XO's collocation offering is pretty solid. No frills, but competently managed, and offered under a reasonable pricing model for retail collocation. I've had similarly positive experiences with their transport side of the house. I've not looked at the IP product... I certainly belive the negative XO feedback shared; having heard similar, it would seem there's definite potential to be treated as merely a number. At the same time, our experience has been great, and I'd happily recommend them. I think the quality of your XO customer experience is directly proportional to the caliber of your account team, along with your ability to vendor-manage and assemble a suitable escalation matrix. As for the Savvis suggestion, I'm not sure I'd agree. We're in 2010, yet they continue to maintain a fair number of gigabit-sized peering interfaces, seemingly operating at or close to capacity. HTH, -a From sean at donelan.com Fri Jul 2 18:08:04 2010 From: sean at donelan.com (Sean Donelan) Date: Fri, 2 Jul 2010 19:08:04 -0400 (EDT) Subject: Finland makes broadband access a legal right In-Reply-To: <4104476A-230F-4EB1-92EE-9D05CCC6542B@cs.columbia.edu> References: <4C2C844B.9020507@linuxbox.org> <485ED9BA02629E4BBBA53AC892EDA50E0B4F9B5D@usmsxt104.mwd.h2o> <1429788F-C02F-4136-9F38-DC30363F9F80@americafree.tv> <4104476A-230F-4EB1-92EE-9D05CCC6542B@cs.columbia.edu> Message-ID: On Fri, 2 Jul 2010, Steven Bellovin wrote: > On Jul 2, 2010, at 10:51 13AM, Marshall Eubanks wrote: >> On Jul 2, 2010, at 10:33 AM, Holmes,David A wrote: >>> Does a "... certain inventor of the Internet ..." refer to the High >>> Performance and Communications Act of 1991, also known as the "Gore >>> Act"? The 1991 Act, based on a study by Dr. Leonard Kleinrock ("Towards >>> a National Research Network") created the commercial Internet that we >>> know and work with today. >> I don't know, but I do know that Larry Pressler was the sole sponsor of the Telecommunications Act of 1996, which is where E-rate came from. This was when the Republicans controlled both houses of Congress, and as far as I know Senator Gore had nothing to do with this bill; he didn't even offer any amendments. > And while Gore was president of the Senate in 1996, he wasn't Senator Gore then... Snopes covers urban legends http://www.snopes.com/quotes/internet.asp Phil Agre traces the story back to a source at the time http://web.archive.org/web/20040603092645/commons.somewhere.com/rre/2000/RRE.Al.Gore.and.the.Inte1.html While you can't configure your router with politics, politics sometimes wants to tell you how to configure your routers. From mysidia at gmail.com Fri Jul 2 19:12:27 2010 From: mysidia at gmail.com (James Hess) Date: Fri, 2 Jul 2010 19:12:27 -0500 Subject: Inquiries to Acquire IPs In-Reply-To: References: <4C2DD19B.33E4.0097.1@globalstar.com> Message-ID: On Fri, Jul 2, 2010 at 2:07 PM, Owen DeLong wrote: > Crist Clark wrote: An interesting if disturbing thing to see... I suppose there is a possibility that some IP address speculator is trying to er, acquire interesting /24s in anticipation of RIR address exhaustion. I have doubts that an unsolicited e-mail sender intends that proper policy be followed. especially since they didn't well, in that unsolicited introduction, even bother with a pretense of a legitimate assignment reason for PA that would be valid, such as buying IP connectivity or transit services. they would probably like things recorded as a simple assign with anonymized contact info. Presumptively if their intent is nefarious, they just need to fool one ISP... > > According to Whois data, you company owns the following Has been assigned, not owns. ARIN RSA Section 9. No property rights. >>> PI (Provider Independent) or PA (Provider Assigned) status? > They would have to justify their need with ARIN prior to the transfer > actually taking effect, but, this is now allowed for /22 and shorter > under NRPM 8.3 (for better or worse). They think PA means "Provider Assigned"? PA conventionally means really provider aggregable, and according to ARIN policy ASSIGNED PA space is for use in connection with network services obtained through the provider assigning it, ARIN NRPM 2.4, 4.2.1.1, 4.2.3.1, 4.2.3.4.1, 4.2.3.7.1. Blocks in the middle of an ISP allocation cannot be changed to PI blocks by providers these days, not without a transfer approved by ARIN anyways. At some point ARIN added requirements to the RSA, that require ISPs to refrain from permanently assigning rights to blocks of IP addresses, when IP addresses are assigned to users. The only way anything assigned directly by an ISP could be PI is back before the requirements were added to the RSA, if the ISP assigned the IP block, without making the user promise to 'return the addresses', and only if the user who got the assignment never later agreed they would return IP addresses when services ended.... ARIN RSA 15(a)(i): "(i) Except as provided in 15(a)(ii), Applicant may not assign or delegate this Agreement or any of its rights or obligations under it, including without limitation the exclusive right to use the number resources allocated or assigned to it, without ARIN?s express written permission, (ii) The event of any transaction (whether a merger, acquisition, or sale) in which Applicant?s controlling managerial and/or voting interest changes during the term of this Agreement shall be considered an assignment, so long as the Applicant provides ARIN with written notification within thirty (30) days of such assignment." -- -JH From compuwizz at gmail.com Sat Jul 3 00:47:19 2010 From: compuwizz at gmail.com (Jared Geiger) Date: Sat, 3 Jul 2010 01:47:19 -0400 Subject: XO feedback In-Reply-To: <20100702230442.GA95331@latency.net> References: <20100702230442.GA95331@latency.net> Message-ID: On Fri, Jul 2, 2010 at 7:04 PM, Adam Rothschild > wrote: > Here in the New York Metro, XO's collocation offering is pretty solid. > No frills, but competently managed, and offered under a reasonable > pricing model for retail collocation. > > I've had similarly positive experiences with their transport side of > the house. I've not looked at the IP product... > > I certainly belive the negative XO feedback shared; having heard > similar, it would seem there's definite potential to be treated as > merely a number. At the same time, our experience has been great, and > I'd happily recommend them. I think the quality of your XO customer > experience is directly proportional to the caliber of your account > team, along with your ability to vendor-manage and assemble a suitable > escalation matrix. > > As for the Savvis suggestion, I'm not sure I'd agree. We're in 2010, > yet they continue to maintain a fair number of gigabit-sized peering > interfaces, seemingly operating at or close to capacity. > > HTH, > -a > > In the DC Market I can provide this input: Voice PRIs - Apparently they don't realize they can provide CNAM service and will argue that CallerID Name is not available from XO at all. Voice SIP - They had a major DID outage this year for 8 to 12 hours that was nationwide. Point to Point DS3 - 3 or 4 complete failures in the past year. They then failed to work with the local ILEC to arrange a time to meet and test equipment. If I buy a circuit from XO, I don't expect to have to call Qwest and Verizon to organize engineers. I'm paying XO to do that for me. Each outage was on average 3 days long. In the Las Vegas Market: Flex T1 - Internet latency was extremely high. However they did install the circuit in 2 weeks. Usually the pricing is very good and this makes it hard to weigh all the cons. ~Jared From tglassey at earthlink.net Sat Jul 3 08:28:39 2010 From: tglassey at earthlink.net (todd glassey) Date: Sat, 03 Jul 2010 06:28:39 -0700 Subject: XO feedback In-Reply-To: References: <20100702230442.GA95331@latency.net> Message-ID: <4C2F3B07.5040307@earthlink.net> On 7/2/2010 10:47 PM, Jared Geiger wrote: > On Fri, Jul 2, 2010 at 7:04 PM, Adam Rothschild > >> wrote: How many co-lo centers do they operate and where are they ? - Curiosity on my part. Todd >> Here in the New York Metro, XO's collocation offering is pretty solid. >> No frills, but competently managed, and offered under a reasonable >> pricing model for retail collocation. >> >> I've had similarly positive experiences with their transport side of >> the house. I've not looked at the IP product... >> >> I certainly belive the negative XO feedback shared; having heard >> similar, it would seem there's definite potential to be treated as >> merely a number. At the same time, our experience has been great, and >> I'd happily recommend them. I think the quality of your XO customer >> experience is directly proportional to the caliber of your account >> team, along with your ability to vendor-manage and assemble a suitable >> escalation matrix. >> >> As for the Savvis suggestion, I'm not sure I'd agree. We're in 2010, >> yet they continue to maintain a fair number of gigabit-sized peering >> interfaces, seemingly operating at or close to capacity. >> >> HTH, >> -a >> >> > In the DC Market I can provide this input: > > Voice PRIs - Apparently they don't realize they can provide CNAM service and > will argue that CallerID Name is not available from XO at all. > > Voice SIP - They had a major DID outage this year for 8 to 12 hours that was > nationwide. > > Point to Point DS3 - 3 or 4 complete failures in the past year. They then > failed to work with the local ILEC to arrange a time to meet and test > equipment. If I buy a circuit from XO, I don't expect to have to call Qwest > and Verizon to organize engineers. I'm paying XO to do that for me. Each > outage was on average 3 days long. > > In the Las Vegas Market: > > Flex T1 - Internet latency was extremely high. However they did install the > circuit in 2 weeks. > > Usually the pricing is very good and this makes it hard to weigh all the > cons. > > ~Jared > From funkyfun at gmail.com Sat Jul 3 12:23:11 2010 From: funkyfun at gmail.com (Net) Date: Sat, 3 Jul 2010 13:23:11 -0400 Subject: XO feedback In-Reply-To: References: <20100702230442.GA95331@latency.net> Message-ID: Thanks for the feedback Jared. On 7/3/10, Jared Geiger wrote: > On Fri, Jul 2, 2010 at 7:04 PM, Adam Rothschild > >> wrote: > >> Here in the New York Metro, XO's collocation offering is pretty solid. >> No frills, but competently managed, and offered under a reasonable >> pricing model for retail collocation. >> >> I've had similarly positive experiences with their transport side of >> the house. I've not looked at the IP product... >> >> I certainly belive the negative XO feedback shared; having heard >> similar, it would seem there's definite potential to be treated as >> merely a number. At the same time, our experience has been great, and >> I'd happily recommend them. I think the quality of your XO customer >> experience is directly proportional to the caliber of your account >> team, along with your ability to vendor-manage and assemble a suitable >> escalation matrix. >> >> As for the Savvis suggestion, I'm not sure I'd agree. We're in 2010, >> yet they continue to maintain a fair number of gigabit-sized peering >> interfaces, seemingly operating at or close to capacity. >> >> HTH, >> -a >> >> > > In the DC Market I can provide this input: > > Voice PRIs - Apparently they don't realize they can provide CNAM service and > will argue that CallerID Name is not available from XO at all. > > Voice SIP - They had a major DID outage this year for 8 to 12 hours that was > nationwide. > > Point to Point DS3 - 3 or 4 complete failures in the past year. They then > failed to work with the local ILEC to arrange a time to meet and test > equipment. If I buy a circuit from XO, I don't expect to have to call Qwest > and Verizon to organize engineers. I'm paying XO to do that for me. Each > outage was on average 3 days long. > > In the Las Vegas Market: > > Flex T1 - Internet latency was extremely high. However they did install the > circuit in 2 weeks. > > Usually the pricing is very good and this makes it hard to weigh all the > cons. > > ~Jared > -- Sent from my mobile device From alan at gtekcommunications.com Sat Jul 3 12:43:27 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Sat, 3 Jul 2010 12:43:27 -0500 Subject: Mikrotik & OC-3 Connection Message-ID: I haven't seen much traffic on this list about Mikrotik or RouterOS, but I thought it was worth a shot as a last ditch effort to get this going. Does anyone know of a solution to connect a POS OC-3 to a router running Mikrotik's RouterOS? I have searched google extensively with varying phrases and nothing helpful comes out of it. -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From sethm at rollernet.us Sat Jul 3 14:16:08 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 03 Jul 2010 12:16:08 -0700 Subject: Mikrotik & OC-3 Connection In-Reply-To: References: Message-ID: <4C2F8C78.3040900@rollernet.us> On 7/3/10 10:43 AM, Alan Bryant wrote: > I haven't seen much traffic on this list about Mikrotik or RouterOS, > but I thought it was worth a shot as a last ditch effort to get this > going. > > Does anyone know of a solution to connect a POS OC-3 to a router > running Mikrotik's RouterOS? I have searched google extensively with > varying phrases and nothing helpful comes out of it. > Maybe this? It's ATM though. http://www.iphase.com/products/product.cfm/PCI/198 ~Seth From mike-nanog at tiedyenetworks.com Sat Jul 3 14:22:11 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 03 Jul 2010 12:22:11 -0700 Subject: Mikrotik & OC-3 Connection In-Reply-To: References: Message-ID: <4C2F8DE3.2070001@tiedyenetworks.com> Alan Bryant wrote: > I haven't seen much traffic on this list about Mikrotik or RouterOS, > but I thought it was worth a shot as a last ditch effort to get this > going. > > Does anyone know of a solution to connect a POS OC-3 to a router > running Mikrotik's RouterOS? I have searched google extensively with > varying phrases and nothing helpful comes out of it. > > Mikrotik is great at lower end stuff where you have ethernet interfaces. Real POS OC-3 however, ain't in it's repertory and would not be what I would choose to route at those interfaces/speeds. However, if you must 'connect mikrotik to oc-3', you might as well find yourself a cisco router of some kind with a PA-POS-OC3 card and use it as a simple modem. Of course, for the price, you might as well just let the cisco do what you're planning on doing with the Mikrotik and get orders of magnitude of functionality and stability out of it in the process. From sethm at rollernet.us Sat Jul 3 14:40:20 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 03 Jul 2010 12:40:20 -0700 Subject: Mikrotik & OC-3 Connection In-Reply-To: <4C2F8DE3.2070001@tiedyenetworks.com> References: <4C2F8DE3.2070001@tiedyenetworks.com> Message-ID: <4C2F9224.7000109@rollernet.us> On 7/3/10 12:22 PM, Mike wrote: > Alan Bryant wrote: >> I haven't seen much traffic on this list about Mikrotik or RouterOS, >> but I thought it was worth a shot as a last ditch effort to get this >> going. >> >> Does anyone know of a solution to connect a POS OC-3 to a router >> running Mikrotik's RouterOS? I have searched google extensively with >> varying phrases and nothing helpful comes out of it. >> >> > Mikrotik is great at lower end stuff where you have ethernet interfaces. > Real POS OC-3 however, ain't in it's repertory and would not be what I > would choose to route at those interfaces/speeds. However, if you must > 'connect mikrotik to oc-3', you might as well find yourself a cisco > router of some kind with a PA-POS-OC3 card and use it as a simple modem. > Of course, for the price, you might as well just let the cisco do what > you're planning on doing with the Mikrotik and get orders of magnitude > of functionality and stability out of it in the process. > That's what I was going to say. ;) Once you reach SONET land you're no longer playing in the "everything is Ethernet" playground that they specializes in. I would say that you've outgrown your Mikrotik routers if you need SONET interfaces and it's time to forklift into a Cisco or Juniper. ~Seth From alan at gtekcommunications.com Sat Jul 3 14:45:26 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Sat, 3 Jul 2010 14:45:26 -0500 Subject: Mikrotik & OC-3 Connection In-Reply-To: <4C2F8DE3.2070001@tiedyenetworks.com> References: <4C2F8DE3.2070001@tiedyenetworks.com> Message-ID: On Sat, Jul 3, 2010 at 2:22 PM, Mike wrote: > Mikrotik is great at lower end stuff where you have ethernet interfaces. > Real POS OC-3 however, ain't in it's repertory and would not be what I would > choose to route at those interfaces/speeds. However, if you must 'connect > mikrotik to oc-3', you might as well find yourself a cisco router of some > kind with a PA-POS-OC3 card and use it as a simple modem. Of course, for the > price, you might as well just let the cisco do what you're planning on doing > with the Mikrotik and get orders of magnitude of functionality and stability > out of it in the process. > Thanks for the responses guys. Unfortunately, we just don't have it in the budget for Cisco or Juniper hardware at this time. I was hoping there would be something available for Mikrotik, but I pretty much already knew the answer. While I know a lot of you guys would recommend Cisco or Juniper over anything else, and I also know that you guys probably think if you're needing an OC-3, it's time to invest in the big boys. However, I'm not the one who makes the final say on purchases. So, with all that being said, is there anyone who has any thoughts on ImageStream's products? They have a POS OC-3 card, and the price appears to be considerably lower for the router anyway, not necessarily the card, though. I'm just trying to see what options there are and make the decision off of that. If Cisco or Juniper is the only way, then so be it. I just want to be sure. -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From chris.young at intermetro.net Sat Jul 3 15:07:49 2010 From: chris.young at intermetro.net (Christopher Young) Date: Sat, 3 Jul 2010 20:07:49 +0000 Subject: Mikrotik & OC-3 Connection In-Reply-To: References: <4C2F8DE3.2070001@tiedyenetworks.com> Message-ID: <1301553246-1278187668-cardhu_decombobulator_blackberry.rim.net-552917278-@bda623.bisx.prod.on.blackberry> Mike, Check out http://www.usedcisco.com they have some good prices. -- Christopher Young InterMetro Communications NOC Department imcnoc at intermetro.net 866-4IMCNOC, (866) 446-2662 805-433-8000 Main 805-433-0050 Direct 805-433-2589 Mobile -----Original Message----- From: Alan Bryant Date: Sat, 3 Jul 2010 14:45:26 To: Mike Cc: Subject: Re: Mikrotik & OC-3 Connection On Sat, Jul 3, 2010 at 2:22 PM, Mike wrote: > Mikrotik is great at lower end stuff where you have ethernet interfaces. > Real POS OC-3 however, ain't in it's repertory and would not be what I would > choose to route at those interfaces/speeds. However, if you must 'connect > mikrotik to oc-3', you might as well find yourself a cisco router of some > kind with a PA-POS-OC3 card and use it as a simple modem. Of course, for the > price, you might as well just let the cisco do what you're planning on doing > with the Mikrotik and get orders of magnitude of functionality and stability > out of it in the process. > Thanks for the responses guys. Unfortunately, we just don't have it in the budget for Cisco or Juniper hardware at this time. I was hoping there would be something available for Mikrotik, but I pretty much already knew the answer. While I know a lot of you guys would recommend Cisco or Juniper over anything else, and I also know that you guys probably think if you're needing an OC-3, it's time to invest in the big boys. However, I'm not the one who makes the final say on purchases. So, with all that being said, is there anyone who has any thoughts on ImageStream's products? They have a POS OC-3 card, and the price appears to be considerably lower for the router anyway, not necessarily the card, though. I'm just trying to see what options there are and make the decision off of that. If Cisco or Juniper is the only way, then so be it. I just want to be sure. -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From mike-nanog at tiedyenetworks.com Sat Jul 3 15:10:54 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 03 Jul 2010 13:10:54 -0700 Subject: Mikrotik & OC-3 Connection In-Reply-To: References: <4C2F8DE3.2070001@tiedyenetworks.com> Message-ID: <4C2F994E.5060100@tiedyenetworks.com> Alan Bryant wrote: > > I'm just trying to see what options there are and make the decision > off of that. If Cisco or Juniper is the only way, then so be it. I > just want to be sure. > > The real issue is that these legacy telco interfaces are just expensive, straight up, and being forced to use these specialized interfaces for your IP connectivity just drives your costs up for no real gain. I bet what you would really love is just a simple ethernet handoff but of course no provider in your area probabbly makes that available. So you get collared into these expensive interfaces that force you to just buy more when you need more connectivity, as opposed to ethernet which could easilly grow to 1000mbps without needing $$$ I/O cards every 155mbps along the way (and loop charges and hassle and pain, etc). On the good news front, there's lots of capable cisco hardware out there you can take multiple interfaces types on, for pretty cheap especially if you look at "refurbished" gear. Before you run off and make a purchase decision, most of these cisco resellers can really help you decide on the right platform (thats their value add), so if you think you might wind up with an OC3 and 8t1s for example they can help you figure out what NPE (cpu) you need and ram and ios version and such. From mansaxel at besserwisser.org Sat Jul 3 15:42:55 2010 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Sat, 3 Jul 2010 22:42:55 +0200 Subject: Inquiries to Acquire IPs In-Reply-To: <00bb01cb1a2f$239232c0$6ab69840$@net> References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> <88BEEEB6B0C5FF34BA349538@[192.168.1.100]> <20100702213604.GK2395@dan.olp.net> <00bb01cb1a2f$239232c0$6ab69840$@net> Message-ID: <20100703204255.GA20122@besserwisser.org> Subject: RE: Inquiries to Acquire IPs Date: Fri, Jul 02, 2010 at 04:40:07PM -0500 Quoting Aaron Wendel (aaron at wholesaleinternet.net): > I sent an inquiry in to ARIN yesterday for a certain ASN that was available > and was told that management won't allow them to issue requested numbers. :( RIPE does, correctly prodded ;-) % Information related to 'AS31337' aut-num: AS31337 as-name: ELEET-AS descr: ELEET Network descr: Location: Sweden (Story is, IIRC, that adjacent number was assigned initially, but the confirmation mail was answered with "Can I have 31337 instead?" which in turn was granted. ) -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 Those aren't WINOS -- that's my JUGGLER, my AERIALIST, my SWORD SWALLOWER, and my LATEX NOVELTY SUPPLIER!! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From owen at delong.com Sat Jul 3 15:57:52 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 3 Jul 2010 13:57:52 -0700 Subject: Inquiries to Acquire IPs In-Reply-To: <20100703204255.GA20122@besserwisser.org> References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> <88BEEEB6B0C5FF34BA349538@[192.168.1.100]> <20100702213604.GK2395@dan.olp.net> <00bb01cb1a2f$239232c0$6ab69840$@net> <20100703204255.GA20122@besserwisser.org> Message-ID: <70CE9ED3-7795-47AF-ACBC-0EBF6038E6B2@delong.com> Vanity ASNs are a horrible idea, IMHO... Unless you want WIPO to come in and start applying UDRP to IP addresses and ASNs, I suggest this be avoided. Owen On Jul 3, 2010, at 1:42 PM, Mans Nilsson wrote: > Subject: RE: Inquiries to Acquire IPs Date: Fri, Jul 02, 2010 at 04:40:07PM -0500 Quoting Aaron Wendel (aaron at wholesaleinternet.net): >> I sent an inquiry in to ARIN yesterday for a certain ASN that was available >> and was told that management won't allow them to issue requested numbers. :( > > RIPE does, correctly prodded ;-) > > % Information related to 'AS31337' > > aut-num: AS31337 > as-name: ELEET-AS > descr: ELEET Network > descr: Location: Sweden > > (Story is, IIRC, that adjacent number was assigned initially, but the > confirmation mail was answered with "Can I have 31337 instead?" which > in turn was granted. ) > > -- > M?ns Nilsson primary/secondary/besserwisser/machina > MN-1334-RIPE +46 705 989668 > Those aren't WINOS -- that's my JUGGLER, my AERIALIST, my SWORD > SWALLOWER, and my LATEX NOVELTY SUPPLIER!! From nanog at butchevans.com Sat Jul 3 16:07:10 2010 From: nanog at butchevans.com (Butch Evans) Date: Sat, 03 Jul 2010 16:07:10 -0500 Subject: Mikrotik & OC-3 Connection In-Reply-To: <4C2F8DE3.2070001@tiedyenetworks.com> References: <4C2F8DE3.2070001@tiedyenetworks.com> Message-ID: <1278191230.6704.949.camel@localhost.localdomain> On Sat, 2010-07-03 at 12:22 -0700, Mike wrote: > Mikrotik is great at lower end stuff where you have ethernet interfaces. > Real POS OC-3 however, ain't in it's repertory and would not be what I > would choose to route at those interfaces/speeds. While I agree that Mikrotik and OC-3 don't go together, I don't know why you would suppose that it can't route at that speed. It's a Linux kernel and given the right hardware, can easily handle that much speed. > However, if you must > 'connect mikrotik to oc-3', you might as well find yourself a cisco > router of some kind with a PA-POS-OC3 card and use it as a simple modem. Or ImageStream for about 1/2 (or better) of the price. > Of course, for the price, you might as well just let the cisco do what > you're planning on doing with the Mikrotik and get orders of magnitude > of functionality and stability out of it in the process. More functionality from a Cisco? You MUST be joking. MT (and ImageStream for that matter) can do WAY more than Cisco for a fraction of the price. Both will offer a much better firewall option, infinitely better QOS capability and is easily as good with dynamic routing (BGP, OSPF, etc.). What's more, you can have a spare on the shelf and STILL not spend as much money as you would for a Cisco device. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From ras at e-gerbil.net Sat Jul 3 17:50:23 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Sat, 3 Jul 2010 17:50:23 -0500 Subject: Inquiries to Acquire IPs In-Reply-To: <20100703204255.GA20122@besserwisser.org> References: <4C2DD19B.33E4.0097.1@globalstar.com> <4C2E3C8D.4010409@scuff.cc.utexas.edu> <4C2E3D7F.9040309@steadfast.net> <88BEEEB6B0C5FF34BA349538@[192.168.1.100]> <20100702213604.GK2395@dan.olp.net> <00bb01cb1a2f$239232c0$6ab69840$@net> <20100703204255.GA20122@besserwisser.org> Message-ID: <20100703225023.GI12163@f-gerbil.cluepon.net> On Sat, Jul 03, 2010 at 10:42:55PM +0200, Mans Nilsson wrote: > aut-num: AS31337 > as-name: ELEET-AS > descr: ELEET Network > descr: Location: Sweden > > (Story is, IIRC, that adjacent number was assigned initially, but the > confirmation mail was answered with "Can I have 31337 instead?" which > in turn was granted. ) I tried to time it to get 6.9 from ARIN, ended up with 6.8 instead, and they kept 6.9 for themselves. Bastards! :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From scott at sberkman.net Sat Jul 3 18:32:48 2010 From: scott at sberkman.net (Scott Berkman) Date: Sat, 3 Jul 2010 19:32:48 -0400 Subject: Mikrotik & OC-3 Connection In-Reply-To: <4C2F994E.5060100@tiedyenetworks.com> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> Message-ID: <01c101cb1b08$0c569400$2503bc00$@net> I really wouldn't use the word legacy to describe SONET and OC-3's. -Scott -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Saturday, July 03, 2010 4:11 PM To: Alan Bryant Cc: nanog at nanog.org Subject: Re: Mikrotik & OC-3 Connection Alan Bryant wrote: > > I'm just trying to see what options there are and make the decision > off of that. If Cisco or Juniper is the only way, then so be it. I > just want to be sure. > > The real issue is that these legacy telco interfaces are just expensive, straight up, and being forced to use these specialized interfaces for your IP connectivity just drives your costs up for no real gain. I bet what you would really love is just a simple ethernet handoff but of course no provider in your area probabbly makes that available. So you get collared into these expensive interfaces that force you to just buy more when you need more connectivity, as opposed to ethernet which could easilly grow to 1000mbps without needing $$$ I/O cards every 155mbps along the way (and loop charges and hassle and pain, etc). On the good news front, there's lots of capable cisco hardware out there you can take multiple interfaces types on, for pretty cheap especially if you look at "refurbished" gear. Before you run off and make a purchase decision, most of these cisco resellers can really help you decide on the right platform (thats their value add), so if you think you might wind up with an OC3 and 8t1s for example they can help you figure out what NPE (cpu) you need and ram and ios version and such. From msa at latt.net Sat Jul 3 19:12:14 2010 From: msa at latt.net (Majdi S. Abbas) Date: Sat, 3 Jul 2010 17:12:14 -0700 Subject: Mikrotik & OC-3 Connection In-Reply-To: <01c101cb1b08$0c569400$2503bc00$@net> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> Message-ID: <20100704001214.GF21858@puck.nether.net> On Sat, Jul 03, 2010 at 07:32:48PM -0400, Scott Berkman wrote: > I really wouldn't use the word legacy to describe SONET and OC-3's. It's around 25 years old (work started in 1985, first standards published in 1988) and we now have a ratified 100G Ethernet standard. Much of it is being used to transport subrate links, some of which are derived from even older transport standards. If not legacy, what word WOULD you use? --msa From sethm at rollernet.us Sat Jul 3 19:25:35 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 03 Jul 2010 17:25:35 -0700 Subject: Mikrotik & OC-3 Connection In-Reply-To: <20100704001214.GF21858@puck.nether.net> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> <20100704001214.GF21858@puck.nether.net> Message-ID: <4C2FD4FF.7090000@rollernet.us> On 7/3/2010 17:12, Majdi S. Abbas wrote: > On Sat, Jul 03, 2010 at 07:32:48PM -0400, Scott Berkman wrote: >> I really wouldn't use the word legacy to describe SONET and OC-3's. > > It's around 25 years old (work started in 1985, first standards > published in 1988) and we now have a ratified 100G Ethernet standard. > > Much of it is being used to transport subrate links, some of > which are derived from even older transport standards. > > If not legacy, what word WOULD you use? > I'd start calling it legacy when it's as easy to order from your telco as X.25 would be. I still see Ethernet circuits delivered via OC-3/STM-1 today with an Overture. If you're throwing OC-3 into the legacy bin you might as well call OC-192 and OC-768 legacy as well. Big deal if the standard is old, apparently it's still useful enough that there isn't a replacement yet. ~Seth From alan at gtekcommunications.com Sat Jul 3 19:51:12 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Sat, 3 Jul 2010 19:51:12 -0500 Subject: Mikrotik & OC-3 Connection In-Reply-To: <4C2FD4FF.7090000@rollernet.us> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> <20100704001214.GF21858@puck.nether.net> <4C2FD4FF.7090000@rollernet.us> Message-ID: Ok, scenario time. I've found a 7206VXR\NPE-G1 w/ 256MB RAM. It has the 3 onboard GigE ports and a PA-POS-1OC3 card in it that should be fine for our OC-3 connection. We need a total of 5 Ethernet ports, not necessarily all GigE. I found this card, PA-2FE-TX that would give us 2 10/100 ports. Everything that I have seen says this should work with the above router. Can anyone confirm this for me? We plan on doing BGP on the WAN side and BGP or OSPF on the LAN side. I'm assuming that I will need to upgrade the RAM on this router. Would I need to upgrade it all the way to the 1GB that it can take? From what i can tell it is not that expensive for the RAM, so we might as well. Will the following IOS version allow us to do all of the above? Cisco IOS Software, 7200 Software (C7200-IS-M), Version 12.4(12), RELEASE SOFTWARE (fc1) I'm finding it difficult to figure out the IOS versions and what is compatible from Cisco's website. Is this the highest IOS that this router can run? Thank you all for all the incredible help. Hopefully I will be able to repay the community at some point. On Sat, Jul 3, 2010 at 7:25 PM, Seth Mattinen wrote: > On 7/3/2010 17:12, Majdi S. Abbas wrote: >> On Sat, Jul 03, 2010 at 07:32:48PM -0400, Scott Berkman wrote: >>> I really wouldn't use the word legacy to describe SONET and OC-3's. >> >> ? ? ? It's around 25 years old (work started in 1985, first standards >> published in 1988) and we now have a ratified 100G Ethernet standard. >> >> ? ? ? Much of it is being used to transport subrate links, some of >> which are derived from even older transport standards. >> >> ? ? ? If not legacy, what word WOULD you use? >> > > > I'd start calling it legacy when it's as easy to order from your telco > as X.25 would be. I still see Ethernet circuits delivered via OC-3/STM-1 > today with an Overture. If you're throwing OC-3 into the legacy bin you > might as well call OC-192 and OC-768 legacy as well. Big deal if the > standard is old, apparently it's still useful enough that there isn't a > replacement yet. > > ~Seth > > -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From chris at uplogon.com Sat Jul 3 19:57:45 2010 From: chris at uplogon.com (Chris Gotstein) Date: Sat, 03 Jul 2010 19:57:45 -0500 Subject: Mikrotik & OC-3 Connection In-Reply-To: References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> <20100704001214.GF21858@puck.nether.net> <4C2FD4FF.7090000@rollernet.us> Message-ID: <4C2FDC89.4080706@uplogon.com> Do you plan on getting full BGP routes from your upstream? If so, go with 1Gb of ram on the NPE G1. I believe that IOS 12.4.25c is the latest version for the 7200VXR series. It's stable, been running it for quite some time. Depending on what you will be doing with this router, will depend on what feature set you'll want. I typically use the Service Provider IOS with IPSEC, 3DES and Lawful Intercept. On 7/3/2010 7:51 PM, Alan Bryant wrote: > Ok, scenario time. > > I've found a 7206VXR\NPE-G1 w/ 256MB RAM. > > It has the 3 onboard GigE ports and a PA-POS-1OC3 card in it that > should be fine for our OC-3 connection. > > We need a total of 5 Ethernet ports, not necessarily all GigE. I found > this card, PA-2FE-TX that would give us 2 10/100 ports. Everything > that I have seen says this should work with the above router. Can > anyone confirm this for me? > > We plan on doing BGP on the WAN side and BGP or OSPF on the LAN side. > I'm assuming that I will need to upgrade the RAM on this router. Would > I need to upgrade it all the way to the 1GB that it can take? From > what i can tell it is not that expensive for the RAM, so we might as > well. > > Will the following IOS version allow us to do all of the above? > Cisco IOS Software, 7200 Software (C7200-IS-M), Version 12.4(12), > RELEASE SOFTWARE (fc1) > > I'm finding it difficult to figure out the IOS versions and what is > compatible from Cisco's website. Is this the highest IOS that this > router can run? > > Thank you all for all the incredible help. Hopefully I will be able to > repay the community at some point. > > On Sat, Jul 3, 2010 at 7:25 PM, Seth Mattinen wrote: >> On 7/3/2010 17:12, Majdi S. Abbas wrote: >>> On Sat, Jul 03, 2010 at 07:32:48PM -0400, Scott Berkman wrote: >>>> I really wouldn't use the word legacy to describe SONET and OC-3's. >>> >>> It's around 25 years old (work started in 1985, first standards >>> published in 1988) and we now have a ratified 100G Ethernet standard. >>> >>> Much of it is being used to transport subrate links, some of >>> which are derived from even older transport standards. >>> >>> If not legacy, what word WOULD you use? >>> >> >> >> I'd start calling it legacy when it's as easy to order from your telco >> as X.25 would be. I still see Ethernet circuits delivered via OC-3/STM-1 >> today with an Overture. If you're throwing OC-3 into the legacy bin you >> might as well call OC-192 and OC-768 legacy as well. Big deal if the >> standard is old, apparently it's still useful enough that there isn't a >> replacement yet. >> >> ~Seth >> >> > > > -- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris at uplogon.com From ray at oneunified.net Sat Jul 3 20:09:32 2010 From: ray at oneunified.net (Ray Burkholder) Date: Sat, 3 Jul 2010 22:09:32 -0300 Subject: Mikrotik & OC-3 Connection In-Reply-To: <4C2FDC89.4080706@uplogon.com> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> <20100704001214.GF21858@puck.nether.net> <4C2FD4FF.7090000@rollernet.us> <4C2FDC89.4080706@uplogon.com> Message-ID: <015f01cb1b15$902db990$b0892cb0$@net> > > I believe that IOS 12.4.25c is the latest version for the 7200VXR > series. It's stable, been running it for quite some time. Depending > on > what you will be doing with this router, will depend on what feature > set > you'll want. I typically use the Service Provider IOS with IPSEC, 3DES > and Lawful Intercept. > > > > > We plan on doing BGP on the WAN side and BGP or OSPF on the LAN side. > > I'm assuming that I will need to upgrade the RAM on this router. > Would The 15.0 series is available for the 7200VXR. However, unless I'm missing something, note that the Service Provider version doesn't have OSPFv3 for IPv6. You have to go with the Advanced IP series for that. Ray -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From mpalmer at hezmatt.org Sat Jul 3 20:26:07 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 4 Jul 2010 11:26:07 +1000 Subject: Mikrotik & OC-3 Connection In-Reply-To: <20100704001214.GF21858@puck.nether.net> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> <20100704001214.GF21858@puck.nether.net> Message-ID: <20100704012607.GO7566@hezmatt.org> On Sat, Jul 03, 2010 at 05:12:14PM -0700, Majdi S. Abbas wrote: > On Sat, Jul 03, 2010 at 07:32:48PM -0400, Scott Berkman wrote: > > I really wouldn't use the word legacy to describe SONET and OC-3's. > > It's around 25 years old (work started in 1985, first standards > published in 1988) and we now have a ratified 100G Ethernet standard. > > Much of it is being used to transport subrate links, some of > which are derived from even older transport standards. > > If not legacy, what word WOULD you use? Legacy (adj.): A pejorative term used in the computer industry meaning "it works". - Matt -- Apparently if you are aware that the From: field can be, and often is, forged, you are overqualified to write antivirus software. -- Jamie Zawinski, http://www.jwz.org/gruntle/virus.html From chris at uplogon.com Sat Jul 3 20:41:14 2010 From: chris at uplogon.com (Chris Gotstein) Date: Sat, 03 Jul 2010 20:41:14 -0500 Subject: Mikrotik & OC-3 Connection In-Reply-To: <015f01cb1b15$902db990$b0892cb0$@net> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> <20100704001214.GF21858@puck.nether.net> <4C2FD4FF.7090000@rollernet.us> <4C2FDC89.4080706@uplogon.com> <015f01cb1b15$902db990$b0892cb0$@net> Message-ID: <4C2FE6BA.9040108@uplogon.com> 12.4 Service provider has IPv6 and OSPFv3. On 7/3/2010 8:09 PM, Ray Burkholder wrote: >> >> I believe that IOS 12.4.25c is the latest version for the 7200VXR >> series. It's stable, been running it for quite some time. Depending >> on >> what you will be doing with this router, will depend on what feature >> set >> you'll want. I typically use the Service Provider IOS with IPSEC, 3DES >> and Lawful Intercept. >> >>> >>> We plan on doing BGP on the WAN side and BGP or OSPF on the LAN side. >>> I'm assuming that I will need to upgrade the RAM on this router. >> Would > > The 15.0 series is available for the 7200VXR. However, unless I'm missing > something, note that the Service Provider version doesn't have OSPFv3 for > IPv6. You have to go with the Advanced IP series for that. > > Ray > > -- Chris Gotstein Sr Network Engineer UP Logon/Computer Connection UP 500 N Stephenson Ave Iron Mountain, MI 49801 Phone: 906-774-4847 Fax: 906-774-0335 chris at uplogon.com From mike-nanog at tiedyenetworks.com Sat Jul 3 21:29:02 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Sat, 03 Jul 2010 19:29:02 -0700 Subject: Mikrotik & OC-3 Connection In-Reply-To: <1278191203.6704.948.camel@localhost.localdomain> References: <4C2F8DE3.2070001@tiedyenetworks.com> <1278191203.6704.948.camel@localhost.localdomain> Message-ID: <4C2FF1EE.8000100@tiedyenetworks.com> Butch Evans wrote: > > More functionality from a Cisco? You MUST be joking. MT (and > ImageStream for that matter) can do WAY more than Cisco for a > fraction > of the price. Both will offer a much better firewall option, > infinitely > better QOS capability and is easily as good with dynamic routing > (BGP, > OSPF, etc.). What's more, you can have a spare on the shelf and > STILL > not spend as much money as you would for a Cisco device. > Yeah, that's what the brochure says anyways, but I don't know of many highly scaled networks using 'mikrotic' and some of the reasons come down to management, software stability and a readily available pool of knowledgeable admins ready to build the next google with it. Don't get me wrong - I believe in linux and am a network operator as well as embedded systems software developer who makes network appliances with it (linux) that do all of the above for use in my network of a 1000+ subscribers, and I sleep very well at night. However, that sleep comes with the price of having to be a linux guru in order to do most network config operations, and in the 8 years I have been eating my own dog food and running in my network now, I've not encountered many who I could successfully pass off network admin duties too for these boxes (quagga, iproute2, ebtables, iptables for instance) and centralized management and configuration control is non-existent. These commercial systems you scoff at also support advanced and important features such as online insertion/removal - which lets you take a card like a gigE switch module, or a fiber/sonet interface, or a ds3, and just plug it in and immediately without a reboot or driver searching/updating/missing dance, start working. Another important difference is that these commercial units are NOT hosts and don't have silly host/desktop type stuff going on within them, like periodic flash writes, file systems filling with junk that causes system hangs, or hundeds of other possible reasons and causes that create 'system down' on host type machines that DON'T affect the commercial boxes, and contribute (in theory anyways) to the continued prospect of very long uptimes and reliable operation. Also basic hardware features like dual and triple redundant power supplies, good fans and overall rugged design that further contribute to long lives (again in theory), that PC/x86 and other COTS SBC type hardware does not have. So in summary, for small jobs, yeah you're right, but once your jobs aren't small anymore and you need more of these features or business continuity becomes really critical, these commercial solutions are far more likely to take you there today. $0.02 Mike- From randy at psg.com Sat Jul 3 22:35:08 2010 From: randy at psg.com (Randy Bush) Date: Sun, 04 Jul 2010 12:35:08 +0900 Subject: Mikrotik & OC-3 Connection In-Reply-To: <20100704001214.GF21858@puck.nether.net> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> <20100704001214.GF21858@puck.nether.net> Message-ID: >> I really wouldn't use the word legacy to describe SONET and OC-3's. > If not legacy, what word WOULD you use? widely deployed and used, and if your device can't deal then it's no deal. i am not overly fond of sonet, but i can't always choose the media over which i have to run packets. randy From randy at psg.com Sat Jul 3 22:36:15 2010 From: randy at psg.com (Randy Bush) Date: Sun, 04 Jul 2010 12:36:15 +0900 Subject: Mikrotik & OC-3 Connection In-Reply-To: <015f01cb1b15$902db990$b0892cb0$@net> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> <20100704001214.GF21858@puck.nether.net> <4C2FD4FF.7090000@rollernet.us> <4C2FDC89.4080706@uplogon.com> <015f01cb1b15$902db990$b0892cb0$@net> Message-ID: > The 15.0 series is available for the 7200VXR. However, unless I'm missing > something, note that the Service Provider version doesn't have OSPFv3 for > IPv6. is-is From LarrySheldon at cox.net Sun Jul 4 00:34:39 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Sun, 04 Jul 2010 00:34:39 -0500 Subject: Mikrotik & OC-3 Connection In-Reply-To: <01c101cb1b08$0c569400$2503bc00$@net> References: <4C2F8DE3.2070001@tiedyenetworks.com> <4C2F994E.5060100@tiedyenetworks.com> <01c101cb1b08$0c569400$2503bc00$@net> Message-ID: <4C301D6F.7030702@cox.net> On 7/3/2010 18:32, Scott Berkman wrote: > I really wouldn't use the word legacy to describe SONET and OC-3's. The word "legacy" is applied to any product that has actually shipped From nanog at butchevans.com Sun Jul 4 02:46:08 2010 From: nanog at butchevans.com (Butch Evans) Date: Sun, 04 Jul 2010 02:46:08 -0500 Subject: Mikrotik & OC-3 Connection In-Reply-To: <4C2FF1EE.8000100@tiedyenetworks.com> References: <4C2F8DE3.2070001@tiedyenetworks.com> <1278191203.6704.948.camel@localhost.localdomain> <4C2FF1EE.8000100@tiedyenetworks.com> Message-ID: <1278229568.6704.973.camel@localhost.localdomain> On Sat, 2010-07-03 at 19:29 -0700, Mike wrote: > Yeah, that's what the brochure says anyways, I have been in the ISP business since early 1993. I have used a LOT of Cisco gear in the past 17 years. I am fully aware of it's functionality and it limits. > but I don't know of > many highly scaled networks using 'mikrotic' It's "MikroTik", by the way. Because you don't know about them makes it true that they don't exist? I help to manage one network that covers the entire state of Wisconsin that uses MikroTik. Is that "highly scaled" in your estimation? > and some of the reasons > come down to management, software stability and a readily available pool > of knowledgeable admins ready to build the next google with it. The world IS changing. Linux is moving into places that we never suspected it would go. I am not suggesting that Cisco will go away because of it. I am simply suggesting that your contention that the only "real" option is Cisco or Juniper is very short-sighted. Also, your statement that there is more functionality in a Cisco is just dead wrong. There is, perhaps, more functionality is SOME Ciscos, but not in a single unit. > However, that sleep comes > with the price of having to be a linux guru in order to do most network > config operations, And this is different from Cisco how? While it's true that there is a lot of support out there for Cisco, it is, in my experience, even MORE true that there is good support for Linux network configurations. > and in the 8 years I have been eating my own dog food > and running in my network now, I've not encountered many who I could > successfully pass off network admin duties too for these boxes (quagga, > iproute2, ebtables, iptables for instance) and centralized management > and configuration control is non-existent. Are you suggesting that you would do that if you used Cisco? This seems like a pretty isolated bit of anecdotal evidence when you talk about "highly scaled" networks in the first sentence. > These commercial systems you scoff at No "scoffing" here. I merely suggested that Cisco/Juniper were not the ONLY choices. Not sure where you get the "scoffing" out of that. > also support advanced and important features such as online > insertion/removal - which lets you take a card like a gigE switch > module, or a fiber/sonet interface, or a ds3, and just plug it in and > immediately without a reboot or driver searching/updating/missing dance, > start working. Another important difference is that these commercial > units are NOT hosts and don't have silly host/desktop type stuff going > on within them, like periodic flash writes, file systems filling with > junk that causes system hangs, or hundeds of other possible reasons and > causes that create 'system down' on host type machines that DON'T affect > the commercial boxes, and contribute (in theory anyways) to the > continued prospect of very long uptimes and reliable operation. This is in some respects true. Many of those things you point out certainly make the Cisco worth a look. I mean, if the network is moving data that cannot handle a few microseconds of downtime for VRRP or whatever failover solution you have in place to correct a problem, then I'm with you. Obviously, you cannot easily do this with the OC3, but it is not impossible to create very fast failover. If you recall, THAT was the interface we were discussing. With those interfaces, plugging in the module is only part of the process. The circuit will still take time to come up, whether you reboot the box or not. > basic hardware features like dual and triple redundant power supplies, > good fans and overall rugged design that further contribute to long > lives (again in theory), that PC/x86 and other COTS SBC type hardware > does not have. These features are available at a price. I have one X86 system that is running with dual power supplies right now. I can't imagine a scenario where I would need 3. Perhaps that's just my limited experience... > So in summary, for small jobs, yeah you're right, but once your jobs > aren't small anymore and you need more of these features or business > continuity becomes really critical, these commercial solutions are far > more likely to take you there today. There are places where I'd use Cisco. For a switching fabric, Cisco is certainly a very strong contender. I have used Cisco switches in numerous places with very good success. For the routing, I just don't see the need. I'm not trying to convince you to switch your network (or even your opinion). I am merely correcting an inaccurate statement on your part regarding functionality comparisons between Cisco and Linux based routers. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From swmike at swm.pp.se Sun Jul 4 03:14:21 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 4 Jul 2010 10:14:21 +0200 (CEST) Subject: Mikrotik & OC-3 Connection In-Reply-To: References: Message-ID: On Sat, 3 Jul 2010, Alan Bryant wrote: > Does anyone know of a solution to connect a POS OC-3 to a router running > Mikrotik's RouterOS? I have searched google extensively with varying > phrases and nothing helpful comes out of it. I don't know much about Mikrotik, but there are OC-3 interfaces you can put in a regular pc: http://www.tmcnet.com/voip/0808/telesoft-technologies-stm-1-oc-3-pci-express-card.htm http://oem.imagestream.com/PCI_Card_Overview.html (the 1104 does POS/OC3 if I read it correctly). There seems to be others, last I checked though these cards were in the USD4000-5000 range or so, so it was cheaper to buy a used 7200/NPE-300 and PA-POS/PA-GE. If someone knows and has good experience of a POS card (pci or pci-e) that works well in Linux (2.6.32 preferrably) I'm very interested. From rubensk at gmail.com Sun Jul 4 08:25:09 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Sun, 4 Jul 2010 10:25:09 -0300 Subject: Mikrotik & OC-3 Connection In-Reply-To: References: Message-ID: If your routing platform doesn't have POS OC-3, you can use a converter to map Ethernet services to it and keep using the platform you've been using. You lose a little on efficiency and failure detection, but turning BFD on might help: http://wiki.mikrotik.com/wiki/Manual:Routing/BFD I've worked with converters from a local industry and I don't think they ship worldwide; in the US I would take at look at RAD, Transition Networks, Allied Telesis and probably some others. This is an issue not specific to Mikrotik; my experience with such a solution was with Cisco switch-routers that could do up to MPLS but had only Ethernet interfaces. Rubens On Sat, Jul 3, 2010 at 2:43 PM, Alan Bryant wrote: > I haven't seen much traffic on this list about Mikrotik or RouterOS, > but I thought it was worth a shot as a last ditch effort to get this > going. > > Does anyone know of a solution to connect a POS OC-3 to a router > running Mikrotik's RouterOS? I have searched google extensively with > varying phrases and nothing helpful comes out of it. > > -- > Alan Bryant | Systems Administrator > Gtek Computers & Wireless, LLC. > alan at gtekcommunications.com | www.gtek.biz > O 361-777-1400 | F 361-777-1405 > > From dburk at burkov.aha.ru Sun Jul 4 11:30:12 2010 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sun, 04 Jul 2010 20:30:12 +0400 Subject: Feds disable movie piracy websites in raids In-Reply-To: References: <82y6dvwf3t.fsf@mid.bfk.de> <20249146.28.1277989432590.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C30B714.3000900@burkov.aha.ru> On 02.07.10 0:27, Randy Bush wrote: >> The question is because gTLDs operations are in the USA, does it mean >> that the USA have control over all those domain names? >> > the usg controls the cctlds too. > > you know better... > randy > > From dburk at burkov.aha.ru Sun Jul 4 11:34:38 2010 From: dburk at burkov.aha.ru (Dmitry Burkov) Date: Sun, 04 Jul 2010 20:34:38 +0400 Subject: The Economist, cyber war issue In-Reply-To: References: <4C2C9730.3040806@linuxbox.org> <390963.66769.qm@web59608.mail.ac4.yahoo.com> <4C2CE504.8070505@mompl.net> <862176.46872.qm@web59616.mail.ac4.yahoo.com> Message-ID: <4C30B81E.9040909@burkov.aha.ru> On 02.07.10 2:01, Randy Bush wrote: >> There is a part 2 as well >> > and this is a bug or a feature? > > I see it is a feature ... From tim at baseworx.net Sun Jul 4 12:23:54 2010 From: tim at baseworx.net (Tim McKee) Date: Sun, 04 Jul 2010 13:23:54 -0400 Subject: Mikrotik & OC-3 Connection In-Reply-To: <1278191230.6704.949.camel@localhost.localdomain> References: <4C2F8DE3.2070001@tiedyenetworks.com> <1278191230.6704.949.camel@localhost.localdomain> Message-ID: <1278264234.2846.2.camel@ns1.baseworx.net> You can always use a Gig-E <-> OC3c/STM1 media converter. I've used one from RAD just to provide OC3c access speeds for some over Cisco 75xx routers which don't support POS interfaces. Works great. Tim McKee On Sat, 2010-07-03 at 16:07 -0500, Butch Evans wrote: > On Sat, 2010-07-03 at 12:22 -0700, Mike wrote: > > Mikrotik is great at lower end stuff where you have ethernet > interfaces. > > Real POS OC-3 however, ain't in it's repertory and would not > be what I > > would choose to route at those interfaces/speeds. > > While I agree that Mikrotik and OC-3 don't go together, I don't > know why > you would suppose that it can't route at that speed. It's a > Linux > kernel and given the right hardware, can easily handle that much > speed. > > > However, if you must > > 'connect mikrotik to oc-3', you might as well find yourself a > cisco > > router of some kind with a PA-POS-OC3 card and use it as a > simple modem. > > Or ImageStream for about 1/2 (or better) of the price. > > > Of course, for the price, you might as well just let the cisco > do what > > you're planning on doing with the Mikrotik and get orders of > magnitude > > of functionality and stability out of it in the process. > > More functionality from a Cisco? You MUST be joking. MT (and > ImageStream for that matter) can do WAY more than Cisco for a > fraction > of the price. Both will offer a much better firewall option, > infinitely > better QOS capability and is easily as good with dynamic routing > (BGP, > OSPF, etc.). What's more, you can have a spare on the shelf and > STILL > not spend as much money as you would for a Cisco device. > > -- > ******************************************************************** > * Butch Evans * Professional Network > Consultation* > * http://www.butchevans.com/ * Network Engineering > * > * http://store.wispgear.net/ * Wired or Wireless Networks > * > * http://blog.butchevans.com/ * ImageStream, Mikrotik and > MORE! * > ******************************************************************** > > From msokolov at ivan.Harhan.ORG Sun Jul 4 13:28:47 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Sun, 4 Jul 2010 18:28:47 GMT Subject: Mikrotik & OC-3 Connection Message-ID: <1007041828.AA17962@ivan.Harhan.ORG> OK, I'll bite and add my 2 Russian kopecks to the Cisco vs. Linux router thread. To make it clear where I'm coming from, I see the networking world from the viewpoint of non-Ethernet WAN interfaces. A world consisting of nothing but Ethernet is too bland and boring for me to live in, and I choose not to live in such an Ethernet-only world. I do indeed like the good old ifconfig & route better than Cisco IOS stuff: it's simpler, makes more sense to me, and fits my simple needs. However, this model works well for Ethernet because it's very simple: with Ethernet one generally has a 1:1 correspondence between the physical hardware unit and the logical "network interface" unit visible to ifconfig and the rest of the BSD/Linux network stack. But that is most definitely not the case for non-Ethernet WAN interfaces, and that is where I see a big shortcoming in what's currently available in the Linux router world. With non-Ethernet WAN interfaces one really needs an extra layer of highly configurable software functionality sandwiched in between the hardware interface unit and the ifconfig layer. The physical hardware interface is a synchronous serial bit stream processor that sends and receives either HDLC frames or ATM cells, and that is where the hardware-dictated part ends. Let's take the case of HDLC as it's more pleasant than ATM: in the case of HDLC the software layer between the HDLC controller and the ifconfig layer needs to do the following: * Let the user choose the encapsulation, and there are many choices: Cisco HDLC, straight PPP (RFC 1662), Frame Relay, PPP over FR (RFC 1973), ATM FUNI, etc. * If it's a Frame Relay encapsulation, let the user configure DLCIs. Oh, and there can be more than one, hence there may be multiple ifconfig-able entities on the same FR interface. * RFC 1490 (FR) and RFC 1483 (ATM) both allow bridged/MAC-encapsulated and true routed circuits; our software layer should support both, as as well as the possibility of mixing the two on different FR interfaces or different DLCIs on the same interface. These two modes need to look different to the ifconfig layer: if it's a bridged encapsulation, ifconfig needs to see a virtual Ethernet interface ("virteth0" or "macwan0"); if it's a true routed encapsulation, ifconfig needs to see a MAC-less and ARP-less point-to-point interface like "ipwan0". * Now let's support both HDLC and serial ATM (bit-by-bit cell delineation) if the underlying hardware is capable of both (like Freescale MPC862 and MPC866). Let's provide a user to switch between the two with a simple software command, and let's provide as much commonality as possible between the two configurations: let's support all RFC 1483 encapsulations on HDLC via FUNI, but make the configuration commands look just like ATM. Let's also support FRF.5 by allowing one to take an ATM PVC and treat its payload as a virtual HDLC interface, with possibly many FR DLCIs inside. I would love to be corrected on this, but I am not aware of anyone having implemented all of the above for Linux (or for any BSD variant) in a clean and generalized manner. Instead what we see is that each vendor of a PCI card for some non-Ethernet WAN interface has their own ad hoc solution which typically comes nowhere close to what I've outlined above in terms of generality and flexibility. Now here is something I'd like to build which will attempt to solve this mess. I'd like to build a modular WAN router based on the MPC866 chip from Freescale, former Motorola. MPC866 is a PowerPC with one very neat twist: it has 4 serial communication controller (SCC) cores on chip. Each SCC has a traditional 7-wire serial interface coming out of it (Rx data, Rx clock, Tx data, Tx clock, RTS, CTS and CD) and supports both HDLC and serial ATM. (The serial ATM mode supports both bit-by-bit cell delineation for a raw bit stream and octet-by-octet cell delineation for use with a framer that provides octet boundaries.) My modular router would be rather unique in that the interface to the pluggable WAN modules would not be PCI or anything of that sort, instead it would be the 7-wire serial interface coming from an MPC866 SCC, and there would be 4 possible daughtercard slots corresponding to the 4 SCCs. When the interface for pluggable WAN modules is something like PCI, the HDLC or ATM (including SAR) core has to be reimplemented anew by everyone who wants to build a new WAN module for a different flavor of Layer 1 physical interface, and I find it wasteful. The proliferation of such reinvented-wheel HDLC/ATM reimplementations is precisely the reason why there is no universally-accepted standardized framework for non-Ethernet WAN interfaces in Linux or *BSD. But if the cores implementing HDLC and ATM SAR reside inside the CPU chip like they do with MPC86x processors, we can have ONE well-written generic driver for these cores, and it will work exactly the same way and provide exactly the same array of configurable Layer 2 options to the user regardless of which Layer 1 interface is used: we can build daughtercards for T1/E1, for SDSL, for T3/E3, etc, and the specialized circuitry on each of these daughtercards will only concern itself with Layer 1, not with HDLC or ATM SAR. I would greatly appreciate any leads/ideas/suggestions as to who might possibly be interested in funding such a project. :-) MS From adrian at creative.net.au Sun Jul 4 19:40:59 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Mon, 5 Jul 2010 08:40:59 +0800 Subject: Mikrotik & OC-3 Connection In-Reply-To: <1007041828.AA17962@ivan.Harhan.ORG> References: <1007041828.AA17962@ivan.Harhan.ORG> Message-ID: <20100705004059.GE20931@skywalker.creative.net.au> On Sun, Jul 04, 2010, Michael Sokolov wrote: > OK, I'll bite and add my 2 Russian kopecks to the Cisco vs. Linux router > thread. It's ok. I'll trade you Russian for Australian currency. I don't know which is going to be better in the long run. > With non-Ethernet WAN interfaces one really needs an extra layer of > highly configurable software functionality sandwiched in between the > hardware interface unit and the ifconfig layer. The physical hardware > interface is a synchronous serial bit stream processor that sends and > receives either HDLC frames or ATM cells, and that is where the Hey, sounds like FreeBSD's NetGraph! > hardware-dictated part ends. Let's take the case of HDLC as it's more > pleasant than ATM: in the case of HDLC the software layer between the > HDLC controller and the ifconfig layer needs to do the following: > > * Let the user choose the encapsulation, and there are many choices: > Cisco HDLC, straight PPP (RFC 1662), Frame Relay, PPP over FR > (RFC 1973), ATM FUNI, etc. ng_ > * If it's a Frame Relay encapsulation, let the user configure DLCIs. > Oh, and there can be more than one, hence there may be multiple > ifconfig-able entities on the same FR interface. ng_ > * RFC 1490 (FR) and RFC 1483 (ATM) both allow bridged/MAC-encapsulated > and true routed circuits; our software layer should support both, as > as well as the possibility of mixing the two on different FR interfaces > or different DLCIs on the same interface. These two modes need to > look different to the ifconfig layer: if it's a bridged encapsulation, > ifconfig needs to see a virtual Ethernet interface ("virteth0" or > "macwan0"); if it's a true routed encapsulation, ifconfig needs to see > a MAC-less and ARP-less point-to-point interface like "ipwan0". ng_bridge, IIRC > * Now let's support both HDLC and serial ATM (bit-by-bit cell delineation) > if the underlying hardware is capable of both (like Freescale MPC862 > and MPC866). Let's provide a user to switch between the two with a > simple software command, and let's provide as much commonality as > possible between the two configurations: let's support all RFC 1483 > encapsulations on HDLC via FUNI, but make the configuration commands > look just like ATM. Let's also support FRF.5 by allowing one to take > an ATM PVC and treat its payload as a virtual HDLC interface, with > possibly many FR DLCIs inside. I think there's ng_ stuff; I could be wrong. There should be functional ATM code in FreeBSD and if so, I'd be surprised to find it isn't linked into netgraph. > I would love to be corrected on this, but I am not aware of anyone having > implemented all of the above for Linux (or for any BSD variant) in a > clean and generalized manner. Instead what we see is that each vendor > of a PCI card for some non-Ethernet WAN interface has their own ad hoc > solution which typically comes nowhere close to what I've outlined above > in terms of generality and flexibility. FreeBSD netgraph. It's clean, it's generalised, it's just not very well documented. > Now here is something I'd like to build which will attempt to solve this > mess. I'd like to build a modular WAN router based on the MPC866 chip > from Freescale, former Motorola. MPC866 is a PowerPC with one very neat > twist: it has 4 serial communication controller (SCC) cores on chip. > Each SCC has a traditional 7-wire serial interface coming out of it (Rx > data, Rx clock, Tx data, Tx clock, RTS, CTS and CD) and supports both > HDLC and serial ATM. (The serial ATM mode supports both bit-by-bit cell > delineation for a raw bit stream and octet-by-octet cell delineation for > use with a framer that provides octet boundaries.) Have a chat to the FreeBSD community. There's a powerpc port. Shoehorn FreeBSD into it somehow, help tidy up the code to do whateveer you need and start leveraging the very powerful network stack FreeBSD has. FreeBSD-head has support for multiple routing tables which I believe you can just dump netgraph interface nodes into to support VRFs. I'm peripehrally doing something similar as a prototype using FreeBSD/MIPS on ubiquiti hardware - but I'm mostly squeezing my squid fork onto it and making it work "right". :) Adrian > My modular router would be rather unique in that the interface to the > pluggable WAN modules would not be PCI or anything of that sort, instead > it would be the 7-wire serial interface coming from an MPC866 SCC, and > there would be 4 possible daughtercard slots corresponding to the 4 SCCs. > > When the interface for pluggable WAN modules is something like PCI, the > HDLC or ATM (including SAR) core has to be reimplemented anew by everyone > who wants to build a new WAN module for a different flavor of Layer 1 > physical interface, and I find it wasteful. The proliferation of such > reinvented-wheel HDLC/ATM reimplementations is precisely the reason why > there is no universally-accepted standardized framework for non-Ethernet > WAN interfaces in Linux or *BSD. > > But if the cores implementing HDLC and ATM SAR reside inside the CPU > chip like they do with MPC86x processors, we can have ONE well-written > generic driver for these cores, and it will work exactly the same way > and provide exactly the same array of configurable Layer 2 options to > the user regardless of which Layer 1 interface is used: we can build > daughtercards for T1/E1, for SDSL, for T3/E3, etc, and the specialized > circuitry on each of these daughtercards will only concern itself with > Layer 1, not with HDLC or ATM SAR. > > I would greatly appreciate any leads/ideas/suggestions as to who might > possibly be interested in funding such a project. :-) -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From msokolov at ivan.Harhan.ORG Sun Jul 4 21:16:05 2010 From: msokolov at ivan.Harhan.ORG (Michael Sokolov) Date: Mon, 5 Jul 2010 02:16:05 GMT Subject: Mikrotik & OC-3 Connection Message-ID: <1007050216.AA18805@ivan.Harhan.ORG> Adrian Chadd wrote: > FreeBSD netgraph. It's clean, it's generalised, it's just not very well > documented. > [...] > Have a chat to the FreeBSD community. There's a powerpc port. Shoehorn > FreeBSD into it somehow, help tidy up the code to do whateveer you need > and start leveraging the very powerful network stack FreeBSD has. Thanks for the tip - that sounds very nice indeed, very much like what I had in mind. It's nice to know that *someone* in the generic free OS world has had the foresight to design this thing right. (Just to be clear, I have no political preferences between Linux and FreeBSD; to me it's all a matter of what works and what I'm familiar with.) But it won't matter until I build the hardware: I want to build the hardware first, the HW itself will be totally open source as in free schematics and full docs etc, and then we'll think about which free OS(es) we want to run on it. I still want to build my MPC866 router platform though: even if the software part has been solved by the fine FreeBSD folks, with the present situation (PCI as the expansion interface on FreeBSD/Linux-based routers) one still has the issue that the HDLC interface or the ATM SAR block has to be wheel-reinvented each time someone wants a different flavor of Layer 1 physical interface. The situation is even more pronounced when a given Layer 1 medium type (say, T1 or SDSL) exists in both HDLC and ATM flavors. I would really like to be able to have a single hardware card that supports both: it is trivial with MPC86x, but I expect it to be cost-prohibitive to do that on a PCI card. MS From ulf at Alameda.net Mon Jul 5 11:44:29 2010 From: ulf at Alameda.net (Ulf Zimmermann) Date: Mon, 5 Jul 2010 09:44:29 -0700 Subject: XO feedback In-Reply-To: <4C2F3B07.5040307@earthlink.net> References: <20100702230442.GA95331@latency.net> <4C2F3B07.5040307@earthlink.net> Message-ID: <20100705164429.GY62987@evil.alameda.net> On Sat, Jul 03, 2010 at 06:28:39AM -0700, todd glassey wrote: > On 7/2/2010 10:47 PM, Jared Geiger wrote: > > On Fri, Jul 2, 2010 at 7:04 PM, Adam Rothschild > > > >> wrote: > > How many co-lo centers do they operate and where are they ? - Curiosity > on my part. We are in their datacenter in Fremont, CA, which is an old Concentric datacenter. A while back they moved the management of that under their telco-colo management. Only more problems since then. 3-phase power? Only because we are grand fathered in. Their telco-colos are very cookie cutter and the Fremont Datacenter does not fit into this mold. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From hrlinneweh at sbcglobal.net Mon Jul 5 15:29:33 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Mon, 5 Jul 2010 13:29:33 -0700 (PDT) Subject: XO feedback In-Reply-To: <20100705164429.GY62987@evil.alameda.net> References: <20100702230442.GA95331@latency.net> <4C2F3B07.5040307@earthlink.net> <20100705164429.GY62987@evil.alameda.net> Message-ID: <587477.92943.qm@web180303.mail.gq1.yahoo.com> Here is a page that will point you to all their locations http://www.xo.com/services/network/Pages/collocation.aspx ________________________________ From: Ulf Zimmermann To: todd glassey Cc: nanog at nanog.org Sent: Mon, July 5, 2010 9:44:29 AM Subject: Re: XO feedback On Sat, Jul 03, 2010 at 06:28:39AM -0700, todd glassey wrote: > On 7/2/2010 10:47 PM, Jared Geiger wrote: > > On Fri, Jul 2, 2010 at 7:04 PM, Adam Rothschild > > > >> wrote: > > How many co-lo centers do they operate and where are they ? - Curiosity > on my part. We are in their datacenter in Fremont, CA, which is an old Concentric datacenter. A while back they moved the management of that under their telco-colo management. Only more problems since then. 3-phase power? Only because we are grand fathered in. Their telco-colos are very cookie cutter and the Fremont Datacenter does not fit into this mold. -- Regards, Ulf. --------------------------------------------------------------------- Ulf Zimmermann, 1525 Pacific Ave., Alameda, CA-94501, #: 510-865-0204 You can find my resume at: http://www.Alameda.net/~ulf/resume.html From Jonathon.Exley at kordia.co.nz Mon Jul 5 16:26:53 2010 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Tue, 6 Jul 2010 09:26:53 +1200 Subject: Mikrotik & OC-3 Connection In-Reply-To: References: Message-ID: <035FE016D625174BA7C7A9FA83E6C17985C1CAB3C1@winexmp02> In terms of FOSS routing platforms, I think Vyatta has a better user interface than Mikrotik. IMHO if the CLI is awkward then there a higher risk of misconfiguration. I haven't used either enough to comment about stability. Jonathon. This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used, copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From steve at ipv6canada.com Mon Jul 5 18:18:10 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Mon, 05 Jul 2010 19:18:10 -0400 Subject: Mikrotik & OC-3 Connection In-Reply-To: <035FE016D625174BA7C7A9FA83E6C17985C1CAB3C1@winexmp02> References: <035FE016D625174BA7C7A9FA83E6C17985C1CAB3C1@winexmp02> Message-ID: <4C326832.30206@ipv6canada.com> On 2010.07.05 17:26, Jonathon Exley wrote: > In terms of FOSS routing platforms, I think Vyatta has a better user interface than Mikrotik. > IMHO if the CLI is awkward then there a higher risk of misconfiguration. > I haven't used either enough to comment about stability. ...not that I'd like to revert this to Mikrotic vs _vendor_, but *all* Mikrotic-specific hardware that we have deployed has always accepted a custom install of FreeBSD & Quagga, that boots directly from the same type of media that the Mikrotic OS originally came on. fwiw, the Quagga interface is very friendly to those who know Cisco. Steve From yuan_zhihui at venustech.com.cn Tue Jul 6 03:46:11 2010 From: yuan_zhihui at venustech.com.cn (=?gb2312?B?1KzWx7vU?=) Date: Tue, 6 Jul 2010 16:46:11 +0800 Subject: Question about Manycore processor- "Tilera" In-Reply-To: <4C326832.30206@ipv6canada.com> References: <035FE016D625174BA7C7A9FA83E6C17985C1CAB3C1@winexmp02> <4C326832.30206@ipv6canada.com> Message-ID: Hello, all. I am not sure is it suitable or not that I ask this question here. My question is about "Tilera", a new multi-core processor provider, however, they call themselves "Many-Core" to separate from RMI, Cavium, etc. Tilera claims that their processor have a 2D mesh so they can put more Cores(from 36,64 to 1K) in one Chip, while Cavium only with 1D bus, so Tilera think they have a much higher performance. My question is: 1 Is it true that Tilera revolutionarily improve the performance of multi-core(or Many-core) processor? 2 If you make the choice between Tilera and Cavium, what do you prefer? Why? Devin. BTW, its website is http://www.tilera.com/ From adrian at creative.net.au Tue Jul 6 04:09:20 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 6 Jul 2010 17:09:20 +0800 Subject: Question about Manycore processor- "Tilera" In-Reply-To: References: <4C326832.30206@ipv6canada.com> Message-ID: <20100706090920.GC32308@skywalker.creative.net.au> There's been plenty of "multi-dimensional" processor interconnects over the years. You should do some further research. :) Adrian (hypercube-connected O2000, anyone?) On Tue, Jul 06, 2010, ?????? wrote: > Hello, all. > > I am not sure is it suitable or not that I ask this question here. > > My question is about "Tilera", a new multi-core processor provider, however, > they call themselves "Many-Core" to separate from RMI, Cavium, etc. > > Tilera claims that their processor have a 2D mesh so they can put more > Cores(from 36,64 to 1K) in one Chip, while Cavium only with 1D bus, so > Tilera think they have a much higher performance. > > My question is: > 1 Is it true that Tilera revolutionarily improve the performance of > multi-core(or Many-core) processor? > 2 If you make the choice between Tilera and Cavium, what do you prefer? Why? > > Devin. > > BTW, its website is http://www.tilera.com/ > > -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From Valdis.Kletnieks at vt.edu Tue Jul 6 08:26:35 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 06 Jul 2010 09:26:35 -0400 Subject: Question about Manycore processor- "Tilera" In-Reply-To: Your message of "Tue, 06 Jul 2010 17:09:20 +0800." <20100706090920.GC32308@skywalker.creative.net.au> References: <4C326832.30206@ipv6canada.com> <20100706090920.GC32308@skywalker.creative.net.au> Message-ID: <71906.1278422795@localhost> On Tue, 06 Jul 2010 17:09:20 +0800, Adrian Chadd said: > There's been plenty of "multi-dimensional" processor interconnects over the > years. You should do some further research. :) The original poster totally failed to answer the single biggest unasked question - "What problem are you trying to solve with a Tilera?". There's large classes of problems that will run much better on a Tilera chipset. And there's plenty of workloads that will totally suck on that hardware. 1K cores on a chip. All hanging off one memory interconnect. I think that about says it all right there. > (hypercube-connected O2000, anyone?) No thanks, I got like a half dozen of their ilk already. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ewilliams at connectria.com Tue Jul 6 10:05:37 2010 From: ewilliams at connectria.com (Eric Williams) Date: Tue, 6 Jul 2010 10:05:37 -0500 Subject: Overseas - Latency Message-ID: We have several customers that are reporting horrible latency when coming from overseas (Israel, Europe, etc...) Looking at a few global maps for latency, I don't see any issues. Does anybody know of any fiber cuts or any issues currently going on? FYI, the customer in question at my datacenter currently uses Level3 and Cogent and we reside in St. Louis. From ariev at vayner.net Tue Jul 6 10:20:47 2010 From: ariev at vayner.net (Arie Vayner) Date: Tue, 6 Jul 2010 18:20:47 +0300 Subject: Overseas - Latency In-Reply-To: References: Message-ID: Eric, I just ran a few traceroutes from Israel (through 2 different providers) and the performance seems normal. Can you tell me where to test specifically to? Thanks Arie On Tue, Jul 6, 2010 at 6:05 PM, Eric Williams wrote: > We have several customers that are reporting horrible latency when coming > from overseas (Israel, Europe, etc...) Looking at a few global maps for > latency, I don't see any issues. Does anybody know of any fiber cuts or > any issues currently going on? FYI, the customer in question at my > datacenter currently uses Level3 and Cogent and we reside in St. Louis. > From caleb.tennis at gmail.com Tue Jul 6 10:36:30 2010 From: caleb.tennis at gmail.com (Caleb Tennis) Date: Tue, 6 Jul 2010 11:36:30 -0400 Subject: Overseas - Latency In-Reply-To: References: Message-ID: <2C2BEB68-0866-4819-9089-4F0355F7AE9B@gmail.com> I saw this earlier this morning, not sure if it relates to you or not: http://www.telegeography.com/cu/article.php?article_id=33597 On Jul 6, 2010, at 11:05 AM, Eric Williams wrote: > We have several customers that are reporting horrible latency when coming > from overseas (Israel, Europe, etc...) Looking at a few global maps for > latency, I don't see any issues. Does anybody know of any fiber cuts or > any issues currently going on? FYI, the customer in question at my > datacenter currently uses Level3 and Cogent and we reside in St. Louis. From dmm at 1-4-5.net Tue Jul 6 11:34:03 2010 From: dmm at 1-4-5.net (David Meyer) Date: Tue, 6 Jul 2010 09:34:03 -0700 Subject: [NANOG-announce] NANOG 50 Call for Presentations now available Message-ID: <20100706163403.GA30178@1-4-5.net> Folks, Its time to start thinking about the presentation(s) you want to give at NANOG 50. NANOG 50 is our annual joint meeting with ARIN, so there will be great opportunities to present both the NANOG and ARIN communities. We had a great deal of content for NANOG 49 so if your talk wasn't accepted please consider resubmitting for NANOG 50. The Call for Presentations can be found on http://nanog.org/meetings/nanog50/callforpresent.php Looking forward to seeing all of you in Atlanta. Dave (for the NANOG PC) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From gbonser at seven.com Tue Jul 6 12:24:35 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 6 Jul 2010 10:24:35 -0700 Subject: Penetration Test Vendors - The List Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52A129@RWC-EX1.corp.seven.com> Quite a varied list. As one respondent put it (possibly paraphrased) "security testing is like underwear, everyone has their own preference". In this case we are likely to go with one of the vendors suggested by our client who has done work for them before and who they feel comfortable with. Thanks for your feedback, everyone, and I hope I didn't miss any. VZB (Verizon Business) IBM ISS (multiple positive) SecureWorks MSS (multiple positive recommendations, multiple negative) Sysnet (sysnet.ie) Deloitte (reported poor result) British Telecom Managed Services Mandiant Inguardians (multiple positive) Metasploit Rapid7 BreakingPoint Counterpane MWR Infosec Corsaire KPMG (negative) Vulnerability Research Labs C2 Company Fishnet Security Neohapsis Trustwave/Ambiron (multiple positive, multiple negative) Terremark Qualys Foundstone Netcraft Patch Advisor Praetorian Global Netragard Enclave Core Security Technologies Matasano Stach & Liu Gotham Digital Science Secure Network Technologies From yuan_zhihui at venustech.com.cn Tue Jul 6 21:21:30 2010 From: yuan_zhihui at venustech.com.cn (=?gb2312?B?1KzWx7vU?=) Date: Wed, 7 Jul 2010 10:21:30 +0800 Subject: Question about Manycore processor- "Tilera" In-Reply-To: <20100706090920.GC32308@skywalker.creative.net.au> References: <4C326832.30206@ipv6canada.com> <20100706090920.GC32308@skywalker.creative.net.au> Message-ID: <365E3A7571A24478B4AA786AF32857A7@venus> Thank you. :) -----Original Message----- From: Adrian Chadd [mailto:adrian at creative.net.au] Sent: Tuesday, July 06, 2010 5:09 PM To: ?????? Cc: nanog at nanog.org Subject: Re: Question about Manycore processor- "Tilera" There's been plenty of "multi-dimensional" processor interconnects over the years. You should do some further research. :) Adrian (hypercube-connected O2000, anyone?) On Tue, Jul 06, 2010, ?????? wrote: > Hello, all. > > I am not sure is it suitable or not that I ask this question here. > > My question is about "Tilera", a new multi-core processor provider, however, > they call themselves "Many-Core" to separate from RMI, Cavium, etc. > > Tilera claims that their processor have a 2D mesh so they can put more > Cores(from 36,64 to 1K) in one Chip, while Cavium only with 1D bus, so > Tilera think they have a much higher performance. > > My question is: > 1 Is it true that Tilera revolutionarily improve the performance of > multi-core(or Many-core) processor? > 2 If you make the choice between Tilera and Cavium, what do you prefer? Why? > > Devin. > > BTW, its website is http://www.tilera.com/ > > -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From joelja at bogus.com Tue Jul 6 22:24:49 2010 From: joelja at bogus.com (joel jaeggli) Date: Tue, 06 Jul 2010 20:24:49 -0700 Subject: Mikrotik & OC-3 Connection In-Reply-To: References: <4C2F8DE3.2070001@tiedyenetworks.com> Message-ID: <4C33F381.3040603@bogus.com> On 2010-07-03 12:45, Alan Bryant wrote: > On Sat, Jul 3, 2010 at 2:22 PM, Mike wrote: >> Mikrotik is great at lower end stuff where you have ethernet interfaces. >> Real POS OC-3 however, ain't in it's repertory and would not be what I would >> choose to route at those interfaces/speeds. However, if you must 'connect >> mikrotik to oc-3', you might as well find yourself a cisco router of some >> kind with a PA-POS-OC3 card and use it as a simple modem. Of course, for the >> price, you might as well just let the cisco do what you're planning on doing >> with the Mikrotik and get orders of magnitude of functionality and stability >> out of it in the process. >> > > Thanks for the responses guys. Unfortunately, we just don't have it in > the budget for Cisco or Juniper hardware at this time. I was hoping > there would be something available for Mikrotik, but I pretty much > already knew the answer. oc-3 pos or atm is riding the tail end of the technology curve, there's not a lot of demand for new products using old technology and no downward pressure on price other than that no-one cares (large capex opportunity) any more and that they are readily available on the secondary market. > While I know a lot of you guys would recommend Cisco or Juniper over > anything else, and I also know that you guys probably think if you're > needing an OC-3, it's time to invest in the big boys. actually buying the thing is only one dimension of the cost of ownership. in this case the price is also a signal that perhaps the other options make more sense, metro-e eosdh etc. of course if you need channelized atm for some reason you may have other feature requirements that are the decision point. > However, I'm not > the one who makes the final say on purchases. So, with all that being > said, is there anyone who has any thoughts on ImageStream's products? > They have a POS OC-3 card, and the price appears to be considerably > lower for the router anyway, not necessarily the card, though. > > I'm just trying to see what options there are and make the decision > off of that. If Cisco or Juniper is the only way, then so be it. I > just want to be sure. > From lists at quux.de Wed Jul 7 04:47:16 2010 From: lists at quux.de (Jens Link) Date: Wed, 07 Jul 2010 11:47:16 +0200 Subject: Overseas - Latency In-Reply-To: <2C2BEB68-0866-4819-9089-4F0355F7AE9B@gmail.com> (Caleb Tennis's message of "Tue\, 6 Jul 2010 11\:36\:30 -0400") References: <2C2BEB68-0866-4819-9089-4F0355F7AE9B@gmail.com> Message-ID: <87sk3vaajf.fsf@oban.berlin.quux.de> Caleb Tennis writes: > I saw this earlier this morning, not sure if it relates to you or not: > > http://www.telegeography.com/cu/article.php?article_id=33597 Well that's Africa and most unfortunate for all the soccer fans there. jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From Rod.Beck at hiberniaatlantic.com Wed Jul 7 05:18:16 2010 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Wed, 7 Jul 2010 11:18:16 +0100 Subject: Overseas - Latency References: <2C2BEB68-0866-4819-9089-4F0355F7AE9B@gmail.com> <87sk3vaajf.fsf@oban.berlin.quux.de> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB03958116@bert.HiberniaAtlantic.local> There are several cable systems landing in South Africa. I doubt it will affect television coverage ... Roderick S. Beck Director of European Sales Hibernia Atlantic Budapest, New York, and Paris -----Original Message----- From: Jens Link [mailto:lists at quux.de] Sent: Wed 7/7/2010 10:47 AM To: North American Network Operators Group Subject: Re: Overseas - Latency Caleb Tennis writes: > I saw this earlier this morning, not sure if it relates to you or not: > > http://www.telegeography.com/cu/article.php?article_id=33597 Well that's Africa and most unfortunate for all the soccer fans there. jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From lists at quux.de Wed Jul 7 05:29:19 2010 From: lists at quux.de (Jens Link) Date: Wed, 07 Jul 2010 12:29:19 +0200 Subject: Overseas - Latency In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB03958116@bert.HiberniaAtlantic.local> (Rod Beck's message of "Wed\, 7 Jul 2010 11\:18\:16 +0100") References: <2C2BEB68-0866-4819-9089-4F0355F7AE9B@gmail.com> <87sk3vaajf.fsf@oban.berlin.quux.de> <1E8B940C5E21014AB8BE70B975D40EDB03958116@bert.HiberniaAtlantic.local> Message-ID: <87sk3v1t6o.fsf@oban.berlin.quux.de> "Rod Beck" writes: > There are several cable systems landing in South Africa. I doubt it will affect > television coverage ... TV is not an issue Internet is. At least thats what I read in an article yesterday. According to the article I read many (smaller) providers there have only on connection and another cable connection not ready yet. I found some news here: http://www.techcentral.co.za/tag/seacom/ Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From drew.weaver at thenap.com Wed Jul 7 07:07:07 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Wed, 7 Jul 2010 08:07:07 -0400 Subject: DNS traffic sourced from my address space to myself. Message-ID: Howdy, Recently I have been noticing a good amount of totally bogus DNS traffic coming in on my transit links via my own IP addresses (spoofed). SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.145.161(0) -> x.x.145.235(0), 1 packet SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.74(0) -> x.x.145.235(0), 1 packet SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.70(0) -> x.x.145.235(0), 1 packet SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.57(0) -> x.x.145.235(0), 1 packet There are multiple different instances of this traffic, the pattern seems to be: -The source is always 'my own IPs' and obviously spoofed. -It's DNS traffic -The "source addresses" all seem to be randomly chosen from the same /23 as the destination address (they cycle through randomly). Has anyone else noticed anything similar coming in on their transit links or am I just lucky? Normally my iACL catches this but I've just been noticing more of it lately. -Drew From jlewis at lewis.org Wed Jul 7 07:25:39 2010 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 7 Jul 2010 08:25:39 -0400 (EDT) Subject: DNS traffic sourced from my address space to myself. In-Reply-To: References: Message-ID: On Wed, 7 Jul 2010, Drew Weaver wrote: > Recently I have been noticing a good amount of totally bogus DNS traffic coming in on my transit links via my own IP addresses (spoofed). > > SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.145.161(0) -> x.x.145.235(0), 1 packet > SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.74(0) -> x.x.145.235(0), 1 packet > SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.70(0) -> x.x.145.235(0), 1 packet > SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.57(0) -> x.x.145.235(0), 1 packet > > There are multiple different instances of this traffic, the pattern seems to be: > > -The source is always 'my own IPs' and obviously spoofed. > -It's DNS traffic > -The "source addresses" all seem to be randomly chosen from the same /23 as the destination address (they cycle through randomly). > > Has anyone else noticed anything similar coming in on their transit links or am I just lucky? I posted the same thing June 16, 2010. Search for Subject: Todd Underwood was a little late If you can capture some of the traffic and see what the DNS requests are, that would let you see if its the same sort of issue I was seeing or something different. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From rsk at gsp.org Wed Jul 7 09:00:55 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 7 Jul 2010 10:00:55 -0400 Subject: [Bruce Hoffman] Thank-you for your recent participation. In-Reply-To: References: <86k4pozfe2.fsf@seastrom.com> <20100627182234.GB24403@gsp.org> Message-ID: <20100707140055.GA11359@gsp.org> On Mon, Jun 28, 2010 at 04:52:48AM +0000, Paul Vixie wrote: > Rich Kulawiec writes: > > This spam came from the "icontact" spammers-for-hire: [snip] > > domains and/or cidrs, plz? The spam appears to always come from icpbounce.com, so blocking that on rDNS and/or HELO should suffice. Observed ranges are: 66.192.165.128/28 74.202.227.32/27 216.27.93.0/25 ---Rsk From bmanning at vacation.karoshi.com Wed Jul 7 11:26:41 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 7 Jul 2010 16:26:41 +0000 Subject: DNS traffic sourced from my address space to myself. In-Reply-To: References: Message-ID: <20100707162641.GC5157@vacation.karoshi.com.> On Wed, Jul 07, 2010 at 08:07:07AM -0400, Drew Weaver wrote: > Howdy, > > Recently I have been noticing a good amount of totally bogus DNS traffic coming in on my transit links via my own IP addresses (spoofed). > > SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.145.161(0) -> x.x.145.235(0), 1 packet > SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.74(0) -> x.x.145.235(0), 1 packet > SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.70(0) -> x.x.145.235(0), 1 packet > SLOT 2:Jul 2 11:26:02 EDT: %SEC-6-IPACCESSLOGP: list 119 permitted udp x.x.146.57(0) -> x.x.145.235(0), 1 packet > > There are multiple different instances of this traffic, the pattern seems to be: > > -The source is always 'my own IPs' and obviously spoofed. > -It's DNS traffic > -The "source addresses" all seem to be randomly chosen from the same /23 as the destination address (they cycle through randomly). > > Has anyone else noticed anything similar coming in on their transit links or am I just lucky? > > Normally my iACL catches this but I've just been noticing more of it lately. > > -Drew > > Yeah... I've seen this type of behaviour w/ folks picking random source addresses from the IPv6 /32... Sure wish I could announce something smaller. --bill From leslie at craigslist.org Wed Jul 7 14:20:25 2010 From: leslie at craigslist.org (Leslie) Date: Wed, 07 Jul 2010 12:20:25 -0700 Subject: NANOG50 conference info ? Message-ID: <4C34D379.5060704@craigslist.org> Does anyone have the location of NANOG50 ? I am trying to coordinate my travel due to another conference in Atlanta right before NANOG. Thanks! Leslie From dmm at 1-4-5.net Wed Jul 7 14:45:45 2010 From: dmm at 1-4-5.net (David Meyer) Date: Wed, 7 Jul 2010 12:45:45 -0700 Subject: NANOG50 conference info ? In-Reply-To: <4C34D379.5060704@craigslist.org> References: <4C34D379.5060704@craigslist.org> Message-ID: Leslie, Does anyone have the location of NANOG50 ? > I am trying to coordinate my travel due to another conference in Atlanta > right before NANOG. > > Thanks! > The venue will be formally announced when registration opens on July 19. Hope this helps, Dave From zaid at zaidali.com Wed Jul 7 20:50:13 2010 From: zaid at zaidali.com (Zaid Ali) Date: Wed, 07 Jul 2010 18:50:13 -0700 Subject: Email over v6 Message-ID: Are there any folks here who would be inclined to do SMTP over IPv6? I have a test v6 network with is ready to do email but getting some real world data to verify headers would be more helpful. Please send me an email offlist if you are interested. Thanks, Zaid From andrew.wallace at rocketmail.com Wed Jul 7 20:52:47 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 7 Jul 2010 18:52:47 -0700 (PDT) Subject: U.S. Plans Cyber Shield for Utilities, Companies Message-ID: <439593.93433.qm@web59615.mail.ac4.yahoo.com> Article: http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html My opinion: http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html#articleTabs%3Dcomments%26commentId%3D1330685 Andrew http://sites.google.com/site/n3td3v/ From tony at lava.net Wed Jul 7 21:00:33 2010 From: tony at lava.net (Antonio Querubin) Date: Wed, 7 Jul 2010 16:00:33 -1000 (HST) Subject: Email over v6 In-Reply-To: References: Message-ID: On Wed, 7 Jul 2010, Zaid Ali wrote: > Are there any folks here who would be inclined to do SMTP over IPv6? I have > a test v6 network with is ready to do email but getting some real world data > to verify headers would be more helpful. Please send me an email offlist if > you are interested. The NANOG list mail server is IPv6-enabled. Your above message came into our mail server over IPv6. So by just using this list you'll be testing your mailserver over IPv6. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From patrick at zill.net Wed Jul 7 21:02:24 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Wed, 07 Jul 2010 22:02:24 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <439593.93433.qm@web59615.mail.ac4.yahoo.com> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> Message-ID: <4C3531B0.4010306@zill.net> andrew.wallace wrote: > Article: > http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html > Why does it cost $100 million to install and configure OpenBSD on a bunch of old systems? --Patrick From jlewis at lewis.org Wed Jul 7 21:14:53 2010 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 7 Jul 2010 22:14:53 -0400 (EDT) Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <4C3531B0.4010306@zill.net> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <4C3531B0.4010306@zill.net> Message-ID: On Wed, 7 Jul 2010, Patrick Giagnocavo wrote: > andrew.wallace wrote: >> Article: >> http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html >> > > Why does it cost $100 million to install and configure OpenBSD on a > bunch of old systems? A) it's being done for the government B) it's being done by a defense contractor C) regardless of what they install, somebody's got to manage it and be managed by multiple layers of managers D) other Pick three or more answers. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From adrian at creative.net.au Wed Jul 7 21:18:19 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 8 Jul 2010 10:18:19 +0800 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <4C3531B0.4010306@zill.net> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <4C3531B0.4010306@zill.net> Message-ID: <20100708021819.GD23008@skywalker.creative.net.au> On Wed, Jul 07, 2010, Patrick Giagnocavo wrote: > Why does it cost $100 million to install and configure OpenBSD on a > bunch of old systems? I think you've misunderstood the question if you think "openbsd on old systems" is the answer. :) Adrian From jimi.thompson at gmail.com Wed Jul 7 21:20:12 2010 From: jimi.thompson at gmail.com (Jimi Thompson) Date: Wed, 07 Jul 2010 21:20:12 -0500 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: Message-ID: ROFL You forgot E) Oversight by a committee and F) All of the above On 7/7/10 9:14 PM, "Jon Lewis" wrote: > On Wed, 7 Jul 2010, Patrick Giagnocavo wrote: > >> andrew.wallace wrote: >>> Article: >>> http://online.wsj.com/article/SB10001424052748704545004575352983850463108.ht >>> ml >>> >> >> Why does it cost $100 million to install and configure OpenBSD on a >> bunch of old systems? > > A) it's being done for the government > B) it's being done by a defense contractor > C) regardless of what they install, somebody's got to manage it and be > managed by multiple layers of managers > D) other > > Pick three or more answers. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From franck at genius.com Wed Jul 7 21:33:57 2010 From: franck at genius.com (Franck Martin) Date: Thu, 8 Jul 2010 14:33:57 +1200 (FJT) Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: Message-ID: <771081.85.1278555617740.JavaMail.franck@franck-martins-macbook-pro.local> You forgot -It is carrier grade, ISO certified and other certification program not worth the paper it is printed on. ----- Original Message ----- From: "Jon Lewis" To: "Patrick Giagnocavo" Cc: nanog at nanog.org Sent: Thursday, 8 July, 2010 2:14:53 PM Subject: Re: U.S. Plans Cyber Shield for Utilities, Companies On Wed, 7 Jul 2010, Patrick Giagnocavo wrote: > andrew.wallace wrote: >> Article: >> http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html >> > > Why does it cost $100 million to install and configure OpenBSD on a > bunch of old systems? A) it's being done for the government B) it's being done by a defense contractor C) regardless of what they install, somebody's got to manage it and be managed by multiple layers of managers D) other From Valdis.Kletnieks at vt.edu Wed Jul 7 22:59:24 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 07 Jul 2010 23:59:24 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: Your message of "Wed, 07 Jul 2010 22:02:24 EDT." <4C3531B0.4010306@zill.net> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <4C3531B0.4010306@zill.net> Message-ID: <26242.1278561564@localhost> On Wed, 07 Jul 2010 22:02:24 EDT, Patrick Giagnocavo said: > andrew.wallace wrote: > > Article: > > http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html > > > > Why does it cost $100 million to install and configure OpenBSD on a > bunch of old systems? That's the first $3M. The other $97M is actually turning it into a functional system - which is the hard part that nobody really understands. And I see you smirking in the back row - no, you don't understand it either, or you would have already figured out a way to monetize your understanding. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From joelja at bogus.com Wed Jul 7 23:08:53 2010 From: joelja at bogus.com (joel jaeggli) Date: Wed, 07 Jul 2010 21:08:53 -0700 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <4C3531B0.4010306@zill.net> Message-ID: <4C354F55.1020002@bogus.com> On 2010-07-07 19:14, Jon Lewis wrote: > On Wed, 7 Jul 2010, Patrick Giagnocavo wrote: > >> andrew.wallace wrote: >>> Article: >>> http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html >>> >>> >> >> Why does it cost $100 million to install and configure OpenBSD on a >> bunch of old systems? Having supported contractors deploying of all things firewall rulesets for scada systems I can only imagine that $100 million is only getting started. > A) it's being done for the government > B) it's being done by a defense contractor > C) regardless of what they install, somebody's got to manage it and be > managed by multiple layers of managers > D) other > > Pick three or more answers. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > From tvhawaii at shaka.com Thu Jul 8 00:16:27 2010 From: tvhawaii at shaka.com (Michael Painter) Date: Wed, 7 Jul 2010 19:16:27 -1000 Subject: U.S. Plans Cyber Shield for Utilities, Companies References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> Message-ID: <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> andrew.wallace wrote: > Article: > http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html > > My opinion: > http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html#articleTabs%3Dcomments%26commentId%3D1330685 "Perfect Citizen will look at large, typically older computer control systems that were often designed without Internet connectivity or security in mind. Many of those systems?which run everything from subway systems to air-traffic control networks?have since been linked to the Internet, making them more efficient but also exposing them to cyber attack." Have we all gone mad? I find it hard to understand that a nuclear power plant, air-traffic control network, or electrical grid would be 'linked' to the Internet in the interest of 'efficiency'. Air gap them all and let them apply for "Inefficiency Relief" from the $100 million relief fund. From tjc at ecs.soton.ac.uk Thu Jul 8 02:08:46 2010 From: tjc at ecs.soton.ac.uk (Tim Chown) Date: Thu, 8 Jul 2010 08:08:46 +0100 Subject: Email over v6 In-Reply-To: References: <2D9C4F16-7679-4D49-AC91-130518DEB25C@ecs.soton.ac.uk> Message-ID: On 8 Jul 2010, at 03:00, Antonio Querubin wrote: > On Wed, 7 Jul 2010, Zaid Ali wrote: > >> Are there any folks here who would be inclined to do SMTP over IPv6? I have >> a test v6 network with is ready to do email but getting some real world data >> to verify headers would be more helpful. Please send me an email offlist if >> you are interested. > > The NANOG list mail server is IPv6-enabled. Your above message came into our mail server over IPv6. So by just using this list you'll be testing your mailserver over IPv6. So for example here's Antonio's reply header going to the list over v6 transport then out to our site also by v6: Received: from s0.nanog.org (s0.nanog.org [2001:48a8:6880:95::20]) by crow.ecs.soton.ac.uk (crow.ecs.soton.ac.uk [2001:630:d0:f110::25b]) envelope-from with ESMTP id m673381995435214jA ret-id none; Thu, 08 Jul 2010 03:03:19 +0100 Received: from localhost ([::1] helo=s0.nanog.org) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OWgRQ-000HxK-8m; Thu, 08 Jul 2010 02:02:20 +0000 Received: from outgoing03.lava.net ([2001:1888:0:1:202:b3ff:fe1d:6b98]) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from ) id 1OWgPi-000G1S-Si for nanog at nanog.org; Thu, 08 Jul 2010 02:00:35 +0000 From swmike at swm.pp.se Thu Jul 8 02:20:18 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 8 Jul 2010 09:20:18 +0200 (CEST) Subject: Email over v6 In-Reply-To: References: <2D9C4F16-7679-4D49-AC91-130518DEB25C@ecs.soton.ac.uk> Message-ID: On Thu, 8 Jul 2010, Tim Chown wrote: > Received: from s0.nanog.org (s0.nanog.org = > [2001:48a8:6880:95::20]) by crow.ecs.soton.ac.uk (crow.ecs.soton.ac.uk = > [2001:630:d0:f110::25b]) envelope-from = > with ESMTP id = > m673381995435214jA ret-id none; Thu, 08 Jul 2010 03:03:19 +0100 > Received: from localhost ([::1] helo=3Ds0.nanog.org) by = > s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from = > ) id 1OWgRQ-000HxK-8m; Thu, 08 Jul 2010 = > 02:02:20 +0000 > Received: from outgoing03.lava.net = > ([2001:1888:0:1:202:b3ff:fe1d:6b98]) by s0.nanog.org with esmtp (Exim = > 4.68 (FreeBSD)) (envelope-from ) id 1OWgPi-000G1S-Si for = > nanog at nanog.org; Thu, 08 Jul 2010 02:00:35 +0000 One other thing I also notice is that there is a high correlation between use of TLS and IPv6, I guess a lot of people with IPv6 clue also enable TLS: Received: from s0.nanog.org (s0.nanog.org [IPv6:2001:48a8:6880:95::20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by uplift.swm.pp.se (Postfix) with ESMTPS id F1B959F for ; Thu, 8 Jul 2010 09:10:41 +0200 (CEST) -- Mikael Abrahamsson email: swmike at swm.pp.se From jlewis at packetnexus.com Thu Jul 8 06:48:09 2010 From: jlewis at packetnexus.com (Jason Lewis) Date: Thu, 8 Jul 2010 07:48:09 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> Message-ID: On Thu, Jul 8, 2010 at 1:16 AM, Michael Painter wrote: > Have we all gone mad? > I find it hard to understand that a nuclear power plant, air-traffic control > network, or electrical grid would be 'linked' to the Internet in the > interest of 'efficiency'. ?Air gap them all and let them apply for > "Inefficiency Relief" from the $100 million relief fund. > > Efficiency in this context refers to the nuke plant operator checking his email and playing games online. It is not efficient to have him use one computer for the power plant and one for his personal use. From bross at pobox.com Thu Jul 8 08:51:52 2010 From: bross at pobox.com (Brandon Ross) Date: Thu, 8 Jul 2010 09:51:52 -0400 (EDT) Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> Message-ID: On Wed, 7 Jul 2010, Michael Painter wrote: > Have we all gone mad? > I find it hard to understand that a nuclear power plant, air-traffic control > network, or electrical grid would be 'linked' to the Internet in the interest > of 'efficiency'. Air gap them all and let them apply for "Inefficiency > Relief" from the $100 million relief fund. Absolutely! For example, those thousands of flight plans filed every day by airlines across the globe, not to mention private flights, should be done manually the old fashioned way, with a paper form and stopping by your local FAA office where a human keys them into the ATC computer. Oh wait, we closed all of those offices when we moved all of those functions to the Internet. I guess we'll just have to re-open them. And flight tracking data that airlines and freight companies use to track their aircraft, yea, let's cut those off too. If they want to know where their plane is, just have them call the FAA. Surely the government can staff some huge call centers to handle the load of each airline calling about each flight every few minutes. Heck, removing all of these functions from the Internet will create jobs, too, right? And no one would mind paying for all of this out of their airline tickets, it should only increase fares by a third or so. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From jgreco at ns.sol.net Thu Jul 8 09:06:47 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Jul 2010 09:06:47 -0500 (CDT) Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: Message-ID: <201007081406.o68E6lkX004874@aurora.sol.net> > On Wed, 7 Jul 2010, Michael Painter wrote: > > > Have we all gone mad? > > I find it hard to understand that a nuclear power plant, air-traffic control > > network, or electrical grid would be 'linked' to the Internet in the interest > > of 'efficiency'. Air gap them all and let them apply for "Inefficiency > > Relief" from the $100 million relief fund. > > Absolutely! For example, those thousands of flight plans filed every day > by airlines across the globe, not to mention private flights, should be > done manually the old fashioned way, with a paper form and stopping by > your local FAA office where a human keys them into the ATC computer. Oh > wait, we closed all of those offices when we moved all of those functions > to the Internet. I guess we'll just have to re-open them. > > And flight tracking data that airlines and freight companies use to track > their aircraft, yea, let's cut those off too. If they want to know where > their plane is, just have them call the FAA. Surely the government can > staff some huge call centers to handle the load of each airline calling > about each flight every few minutes. > > Heck, removing all of these functions from the Internet will create jobs, > too, right? And no one would mind paying for all of this out of their > airline tickets, it should only increase fares by a third or so. There's a happy medium in there somewhere; it's not clear that having (to use the examples given) air traffic control computers directly on the Internet has sufficient value to outweigh the risks. However, it seems that being able to securely gateway appropriate information between the two networks should be manageable, certainly a lot more manageable than the NxM complexity involved if you try to do it by securing each and every Internet-connected ATC PC individually. It sucks in some ways, but providing a limited number of pathways in that are under tight, secure control is a desirable goal. If you give the PC that allows control of the power grid access to the Internet so that the operator can "efficiently" update his Facebook while he's simultaneously controlling the power grid, that's hazardous, and no amount of snide remarks about job creation will change that reality. These networks ought to be air gapped to the maximum reasonable extent possible; all pathways in ought to be defended as though they were the gateway to the kingdom. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From Valdis.Kletnieks at vt.edu Thu Jul 8 09:12:23 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 08 Jul 2010 10:12:23 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: Your message of "Wed, 07 Jul 2010 19:16:27 -1000." <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> Message-ID: <5620.1278598343@localhost> On Wed, 07 Jul 2010 19:16:27 -1000, Michael Painter said: > I find it hard to understand that a nuclear power plant, air-traffic control > network, or electrical grid would be 'linked' to the Internet in the interest > of 'efficiency'. Air gap them all and let them apply for "Inefficiency Relief" > from the $100 million relief fund. OK, so you airgap the whole thing, and apply for "Inefficiency Relief" to help pay for those 2,397 separate dark fiber dedicated links you need to contact your 2,397 remote sensing stations and control points. And of course, since you end up burning a *lot* of dark fiber pairs when every utility starts doing that, the provider gets to go back and put a whole lot more 96-pair or whatever alongside the previous bundle, driving prices back up after our long-term fiber glut. And then you discover that your actual network reliability goes *down*, because getting your provider to troubleshoot your measly 64K channel is a pain and takes a long time to get results - whereas if you went commodity Internet your packets are now mixed in with everybody else's on a important 10GE link. Sure, that 10GE link may be just 2 fibers over in the same bundle - but guess which one will probably be spliced first after the backhoe hits? (Plus of course, if 37 of those 2,397 links were in the bundle, it's going to take 37 splices to get you 100% back up, instead of just one splice....) What's the going rate these days that you have to pay to make sure your fiber gets spliced first rather than that other customer's 10GE? And what's it cost to do it for all 2,397 links? And if your electrical-grid fiber is in the same cable as the other customer's ATC cable, who gets spliced first? If you have a single point of failure in your design, you really want to make sure that the point is heavily fate-shared with enough other customers that the provider will feel *really* motivated to fix your problem. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jared at puck.nether.net Thu Jul 8 09:32:41 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Jul 2010 10:32:41 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <5620.1278598343@localhost> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> <5620.1278598343@localhost> Message-ID: On Jul 8, 2010, at 10:12 AM, Valdis.Kletnieks at vt.edu wrote: > What's the going rate these days that you have to pay to make sure your fiber > gets spliced first rather than that other customer's 10GE? And what's it > cost to do it for all 2,397 links? And if your electrical-grid fiber is > in the same cable as the other customer's ATC cable, who gets spliced first? http://tsp.ncs.gov/ From tme at americafree.tv Thu Jul 8 09:59:07 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 8 Jul 2010 10:59:07 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <5620.1278598343@localhost> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> <5620.1278598343@localhost> Message-ID: <09C1E7CF-D891-49B3-AA91-77F665164A0E@americafree.tv> On Jul 8, 2010, at 10:12 AM, Valdis.Kletnieks at vt.edu wrote: > On Wed, 07 Jul 2010 19:16:27 -1000, Michael Painter said: > >> I find it hard to understand that a nuclear power plant, air- >> traffic control >> network, or electrical grid would be 'linked' to the Internet in >> the interest >> of 'efficiency'. Air gap them all and let them apply for >> "Inefficiency Relief" >> from the $100 million relief fund. > > OK, so you airgap the whole thing, and apply for "Inefficiency > Relief" to help > pay for those 2,397 separate dark fiber dedicated links you need to > contact > your 2,397 remote sensing stations and control points. And of > course, since you > end up burning a *lot* of dark fiber pairs when every utility starts > doing > that, the provider gets to go back and put a whole lot more 96-pair > or whatever > alongside the previous bundle, driving prices back up after our long- > term fiber > glut. I think that there needs to be a balance. There is no Internet access to certain military systems, for example, but that doesn't mean that the base housing them has no Internet access. I would expect the same to be true for, e.g., nuclear power systems. If this has never been thought through by someone, it would not be a bad idea to start now. On the other hand, my friends in military networking tend to be cynical about these kinds of exercises. They may or may not actually increase security, in fact they sometimes degrade it, but they tend to be very good at sending money to politically well connected contractors. Regards Marshall > > And then you discover that your actual network reliability goes > *down*, because > getting your provider to troubleshoot your measly 64K channel is a > pain and > takes a long time to get results - whereas if you went commodity > Internet your > packets are now mixed in with everybody else's on a important 10GE > link. Sure, > that 10GE link may be just 2 fibers over in the same bundle - but > guess which > one will probably be spliced first after the backhoe hits? (Plus of > course, if > 37 of those 2,397 links were in the bundle, it's going to take 37 > splices to > get you 100% back up, instead of just one splice....) > > What's the going rate these days that you have to pay to make sure > your fiber > gets spliced first rather than that other customer's 10GE? And > what's it > cost to do it for all 2,397 links? And if your electrical-grid > fiber is > in the same cable as the other customer's ATC cable, who gets > spliced first? > > If you have a single point of failure in your design, you really > want to > make sure that the point is heavily fate-shared with enough other > customers > that the provider will feel *really* motivated to fix your problem. ;) > From jcdill.lists at gmail.com Thu Jul 8 10:12:29 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 08 Jul 2010 08:12:29 -0700 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <5620.1278598343@localhost> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> <5620.1278598343@localhost> Message-ID: <4C35EADD.60908@gmail.com> Valdis.Kletnieks at vt.edu wrote: > What's the going rate these days that you have to pay to make sure your fiber > gets spliced first rather than that other customer's 10GE? I'm not familiar with cable break splicing procedures, but is it even possible to pay extra to have your splice done first? I would think that the logistics of splicing are such that the guy down in the hole doesn't know whose traffic is on each strand in the bundle, and his job is just to splice them as he matches them (using color codes or similar on the sheaths of the individual strands) as fast as he can. Trying to identify a specific strand and then splicing it first would greatly slow down the task of splicing them all. If you have more than 1 strand that needs to get spliced "first" it would likely take longer to identify these "special" customers and get them done first than to just splice with no priority and get the whole bundle done. jc From michael.holstein at csuohio.edu Thu Jul 8 10:13:24 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 08 Jul 2010 11:13:24 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> Message-ID: <4C35EB14.7080504@csuohio.edu> > I find it hard to understand that a nuclear power plant, air-traffic > control network, or electrical grid would be 'linked' to the Internet > in the interest of 'efficiency'. The Davis-Besse nuclear generating station computers were hit by the SQL Slammer / Saphire worm back in 2003. http://www.theregister.co.uk/2003/08/20/slammer_worm_crashed_ohio_nuke/ The utility claims that there was never a risk, but take that with a grain of salt since this is the same utility that conveniently managed to overlook a hole the size of a book in the reactor head for several years. Cheers, Michael Holstein Cleveland State University From Valdis.Kletnieks at vt.edu Thu Jul 8 10:26:04 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 08 Jul 2010 11:26:04 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: Your message of "Thu, 08 Jul 2010 08:12:29 PDT." <4C35EADD.60908@gmail.com> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> <5620.1278598343@localhost> <4C35EADD.60908@gmail.com> Message-ID: <7965.1278602764@localhost> On Thu, 08 Jul 2010 08:12:29 PDT, JC Dill said: > Valdis.Kletnieks at vt.edu wrote: > > What's the going rate these days that you have to pay to make sure your fiber > > gets spliced first rather than that other customer's 10GE? > I'm not familiar with cable break splicing procedures, but is it even > possible to pay extra to have your splice done first? I would think > that the logistics of splicing are such that the guy down in the hole > doesn't know whose traffic is on each strand in the bundle Exactly - which is a case for just having everybody's traffic mingled on a very busy 12-pair rather than several 96-pair with lots of dedicated links, *everybody* ends up back in service a lot faster... And remember - this industry has more trouble with backhoes and would-be copper thieves than terrorists. Anybody who is defending against terrorists by increasing their vulnerability to backhoes is, well... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bicknell at ufp.org Thu Jul 8 10:52:38 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 8 Jul 2010 08:52:38 -0700 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <4C35EADD.60908@gmail.com> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> <5620.1278598343@localhost> <4C35EADD.60908@gmail.com> Message-ID: <20100708155238.GA47378@ussenterprise.ufp.org> In a message written on Thu, Jul 08, 2010 at 08:12:29AM -0700, JC Dill wrote: > I'm not familiar with cable break splicing procedures, but is it even > possible to pay extra to have your splice done first? I would think > that the logistics of splicing are such that the guy down in the hole > doesn't know whose traffic is on each strand in the bundle, and his job > is just to splice them as he matches them (using color codes or similar > on the sheaths of the individual strands) as fast as he can. Trying to > identify a specific strand and then splicing it first would greatly slow > down the task of splicing them all. If you have more than 1 strand that > needs to get spliced "first" it would likely take longer to identify > these "special" customers and get them done first than to just splice > with no priority and get the whole bundle done. In the simple case of a fiber cut and repair (the proverbial errant backhoe) you're pretty much correct. The tech splices the cable in the obvious to fix order (typically by color code). I suspect you could try and be lower in the color code, but in practical terms once they get going there is not much time difference first to last. There are more complicated cases though; consider the Baltimore tunnel fire years ago. Restoration required running several km of new fiber on a temporary route, and most importantly troubleshooting if that did anything bad to anyone (e.g. put them over their distance budget). It is entirely possible to be moved to the front of the "I need help" queue in those situations. In most cases, if you care about paying lots of money to be first you have enough money to buy an actually physically diverse route, and it's a non-issue though.... -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From sil at infiltrated.net Thu Jul 8 10:56:35 2010 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 08 Jul 2010 11:56:35 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> Message-ID: <4C35F533.4080409@infiltrated.net> Michael Painter wrote: > > Have we all gone mad? > I find it hard to understand that a nuclear power plant, air-traffic > control network, or electrical grid would be 'linked' to the Internet > in the interest of 'efficiency'. Air gap them all and let them apply > for "Inefficiency Relief" from the $100 million relief fund. What's hard to understand about mobility. Sure the HMI, RTU's etc are NOT connected to the public Internet however, they ARE networked. All a company needs is one client side attack to give an outsider the same level of access as an insider and it's checkmate. @Jared's TSP link... Wonder how this will affect VoIP ITSP's etal, e.g., how many local NS/EP's have swapped over to VoIP. Logically, anyone with a network running a managed VoIP service, trunk, etc., could qualify. @Fiber splicing ... Let the NSA handles this (http://www.zdnet.com/news/spy-agency-taps-into-undersea-cable/115877) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From bruns at 2mbit.com Thu Jul 8 11:00:46 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 08 Jul 2010 10:00:46 -0600 Subject: Email over v6 In-Reply-To: References: <2D9C4F16-7679-4D49-AC91-130518DEB25C@ecs.soton.ac.uk> Message-ID: <4C35F62E.8050900@2mbit.com> On 7/8/10 1:20 AM, Mikael Abrahamsson wrote: > On Thu, 8 Jul 2010, Tim Chown wrote: > > One other thing I also notice is that there is a high correlation > between use of TLS and IPv6, I guess a lot of people with IPv6 clue also > enable TLS: > By default, at least on Debian, TLS and IPv6 (if available, even if only using link local addresses) are on by default, so there's not too much that needs to be done to use TLS on the SMTP side. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bross at pobox.com Thu Jul 8 11:00:56 2010 From: bross at pobox.com (Brandon Ross) Date: Thu, 8 Jul 2010 12:00:56 -0400 (EDT) Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <201007081406.o68E6lkX004874@aurora.sol.net> References: <201007081406.o68E6lkX004874@aurora.sol.net> Message-ID: On Thu, 8 Jul 2010, Joe Greco wrote: > There's a happy medium in there somewhere; it's not clear that having (to > use the examples given) air traffic control computers directly on the > Internet has sufficient value to outweigh the risks. However, it seems > that being able to securely gateway appropriate information between the > two networks should be manageable, certainly a lot more manageable than > the NxM complexity involved if you try to do it by securing each and > every Internet-connected ATC PC individually. What makes you think that isn't exactly what this "Cyber Shield" project is supposed to do? Heck, what makes you think that's not the way most of these systems already work today? Do people really think the guy in the airport control tower is really surfing Facebook while he's controlling aircraft on the same computer, or that capability is even what is under consideration? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From bmanning at vacation.karoshi.com Thu Jul 8 11:08:36 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 8 Jul 2010 16:08:36 +0000 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> Message-ID: <20100708160836.GA14198@vacation.karoshi.com.> On Thu, Jul 08, 2010 at 09:51:52AM -0400, Brandon Ross wrote: > On Wed, 7 Jul 2010, Michael Painter wrote: > > >Have we all gone mad? > > Absolutely! For example, those thousands of flight plans filed every day > by airlines across the globe, not to mention private flights, should be > done manually the old fashioned way, with a paper form and stopping by > your local FAA office where a human keys them into the ATC computer. Oh > wait, we closed all of those offices when we moved all of those functions > to the Internet. I guess we'll just have to re-open them. yeah! jobs for americans! actually, the interesting questions raised are along the lines of "what is your contingency plan?" ... the big EMP is coming. > Heck, removing all of these functions from the Internet will create jobs, > too, right? And no one would mind paying for all of this out of their > airline tickets, it should only increase fares by a third or so. > > -- > Brandon Ross AIM: BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss From sil at infiltrated.net Thu Jul 8 11:13:47 2010 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 08 Jul 2010 12:13:47 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: References: <201007081406.o68E6lkX004874@aurora.sol.net> Message-ID: <4C35F93B.8070306@infiltrated.net> Brandon Ross wrote: > > Do people really think the guy in the airport control tower is really > surfing Facebook while he's controlling aircraft on the same computer, or > that capability is even what is under consideration? > "Air traffic controller suspended for allowing son to radio instructions to pilots at New York's Kennedy Airport" http://www.dallasnews.com/sharedcontent/dws/dn/latestnews/stories/030410dnnatairtraffic.170a785b7.html "Air traffic controller suspended, was chatting on phone with girlfriend during Hudson River crash" http://www.nydailynews.com/ny_local/2009/08/13/2009-08-13_air_traffic_controller__on_phone_with_girlfriend__an_supervisor_suspended_over_h.html Huh? ... Scary isn't it: "Pilots were working on laptops when plane overflew Minneapolis destination" http://www.japantoday.com/category/world/view/wayward-pilots-were-working-on-their-laptops-when-plane-overflew-minneapolis-destination There is that capability however, you may be looking at it from a different perspective. It's easy enough to plop open an iPhone for Internet usage. I'm almost positive there are no "smart phone" policies in an Air Traffic Control tower. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From bross at pobox.com Thu Jul 8 11:22:05 2010 From: bross at pobox.com (bross at pobox.com) Date: Thu, 8 Jul 2010 12:22:05 -0400 (EDT) Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <4C35F93B.8070306@infiltrated.net> References: <201007081406.o68E6lkX004874@aurora.sol.net> <4C35F93B.8070306@infiltrated.net> Message-ID: On Thu, 8 Jul 2010, J. Oquendo wrote: > Brandon Ross wrote: >> >> Do people really think the guy in the airport control tower is really >> surfing Facebook while he's controlling aircraft on the same computer, or >> that capability is even what is under consideration? >> > "Air traffic controller suspended for allowing son to radio instructions > to pilots at New York's Kennedy Airport" > http://www.dallasnews.com/sharedcontent/dws/dn/latestnews/stories/030410dnnatairtraffic.170a785b7.html Please read critically before replying. My exact quote included the words "on the same computer". The article that started this thread is about protecting critical systems, not preventing people from making stupid mistakes. If you want to talk about ATC procedures or the misbehavior of controllers using unapproved devices, there's a whole separate mailing list for that. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From swmike at swm.pp.se Thu Jul 8 12:04:22 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 8 Jul 2010 19:04:22 +0200 (CEST) Subject: Email over v6 In-Reply-To: <4C35F62E.8050900@2mbit.com> References: <2D9C4F16-7679-4D49-AC91-130518DEB25C@ecs.soton.ac.uk> <4C35F62E.8050900@2mbit.com> Message-ID: On Thu, 8 Jul 2010, Brielle Bruns wrote: > By default, at least on Debian, TLS and IPv6 (if available, even if only > using link local addresses) are on by default, so there's not too much > that needs to be done to use TLS on the SMTP side. TLS wasn't enabled on my Debian using Postfix, so I guess it depends on more factors than just "running Debian". IPv6 seems to be on by default, yes. -- Mikael Abrahamsson email: swmike at swm.pp.se From jcdill.lists at gmail.com Thu Jul 8 12:05:59 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 08 Jul 2010 10:05:59 -0700 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <439593.93433.qm@web59615.mail.ac4.yahoo.com> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> Message-ID: <4C360577.2060404@gmail.com> andrew.wallace wrote: > Article: > http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html > > My opinion: > http://online.wsj.com/article/SB10001424052748704545004575352983850463108.html#articleTabs%3Dcomments%26commentId%3D1330685 > Politifact has an interesting article on the cyber police topic: http://www.politifact.com/truth-o-meter/statements/2010/jul/06/andrew-napolitano/glenn-beck-host-says-obama-may-soon-be-able-shut-d/ Politifact says that > it is technologically possible for Internet Service Providers (ISPs) > to significantly limit the flow of Internet traffic because > the network operator community is fairly tight-knit, so "it is > conceivable that (network operators) could coordinate a response to a > major event and terminate basic connectivity within a matter of > minutes." Network operators who maintain the Internet backbone share > cell phone information, have regular meetings, and often work together > through established channels in emergencies. (The "have regular meetings" text is a link to nanog.org) jc ** From gbonser at seven.com Thu Jul 8 12:13:25 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 8 Jul 2010 10:13:25 -0700 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: References: <439593.93433.qm@web59615.mail.ac4.yahoo.com><31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52A1FA@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Brandon Ross > Sent: Thursday, July 08, 2010 6:52 AM > To: Michael Painter > Cc: nanog at nanog.org > Subject: Re: U.S. Plans Cyber Shield for Utilities, Companies > > On Wed, 7 Jul 2010, Michael Painter wrote: > > > Have we all gone mad? > > I find it hard to understand that a nuclear power plant, air-traffic > control > > network, or electrical grid would be 'linked' to the Internet in the > interest > > of 'efficiency'. Air gap them all and let them apply for > "Inefficiency > > Relief" from the $100 million relief fund. > > Absolutely! For example, those thousands of flight plans filed every > day > by airlines across the globe, not to mention private flights, should be > done manually the old fashioned way, with a paper form and stopping by > your local FAA office where a human keys them into the ATC computer. > Oh > wait, we closed all of those offices when we moved all of those > functions > to the Internet. I guess we'll just have to re-open them. I believe the point was in response to: "control systems that were often designed without Internet connectivity or security in mind. Many of those systems-which run everything from subway systems to air-traffic control networks-have since been linked to the Internet" If something was designed without network security "in mind" and then connected to the internet as-is, then yeah, that pretty much is not only "madness" but is just asking for trouble. So I am torn between this being another exercise in treating the symptoms while ignoring the underlying cause and at least having SOMEONE watching the front door if the owners aren't paying any attention themselves. But I would think the cost of the program could be scaled back somewhat if certain basic security practices were mandated prior to the system being installed. From owen at delong.com Thu Jul 8 12:11:44 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Jul 2010 10:11:44 -0700 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: References: <201007081406.o68E6lkX004874@aurora.sol.net> Message-ID: <92403D84-4DF7-40DF-9CD0-5F3E20F2FE2E@delong.com> On Jul 8, 2010, at 9:00 AM, Brandon Ross wrote: > On Thu, 8 Jul 2010, Joe Greco wrote: > >> There's a happy medium in there somewhere; it's not clear that having (to >> use the examples given) air traffic control computers directly on the >> Internet has sufficient value to outweigh the risks. However, it seems >> that being able to securely gateway appropriate information between the >> two networks should be manageable, certainly a lot more manageable than >> the NxM complexity involved if you try to do it by securing each and >> every Internet-connected ATC PC individually. > > What makes you think that isn't exactly what this "Cyber Shield" project is supposed to do? Heck, what makes you think that's not the way most of these systems already work today? > > Do people really think the guy in the airport control tower is really > surfing Facebook while he's controlling aircraft on the same computer, or > that capability is even what is under consideration? In fact, I know he isn't. For one thing, the guys in the towers generally do not use computers at all. Yes, some towers have RADAR displays that are actually generated by computer, but, they are essentially read-only and they are not general purpose computers with web browsers, internet connectivity, or even a keyboard for that matter. However, the guys in the tower primarily use binoculars, mark 1 eyeballs, flight progress strips, and a lot of ingenuity to control aircraft within the class D/C/B airspace immediately surrounding their airport (the local controller) and the aircraft on the ground (the ground controller). In some cases, clearance delivery is using a computer, but, technically, he's not controlling aircraft, just in the tower for communication convenience. Now, if you wanted to talk about a TRACON or ARTCC, we might (MIGHT) get into a different realm. In the TRACON, mostly not. Those controllers are generally also working specialized scopes to control aircraft within the airspace around some of the busier airports below about 12,000 feet. In the ARTCC (commonly referred to as "Center") case, mostly they are using similar equipment to the TRACON, but, have wider areas of coverage with lower traffic densities and coverage up to 60,000 feet (Flight level 600). The exception would be the guys working some of the oceanic sectors who depend on email (yes, email) to receive position reports and other data from pilots via ARINC, and, to send instructions to AIRINC to relay to pilots. However, to the best of my knowledge, even that email based system is not connected to the internet and the controllers that are doing that are not doing anything else while they are doing that. I know this from being a pilot, and, also from having toured the following ATC facilities: Towers: CCR PAO SFO TRACONs: SOCAL Bay -- Now defunct, rolled into NORCAL NORCAL Monterey -- Now defunct, rolled into NORCAL Stockton -- Now defunct, rolled into NORCAL ARTCCs: ZOA (Oakland Center) Owen From cmaurand at xyonet.com Thu Jul 8 12:25:54 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Thu, 08 Jul 2010 13:25:54 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> Message-ID: <4C360A22.6070301@xyonet.com> On 7/8/2010 9:51 AM, Brandon Ross wrote: > On Wed, 7 Jul 2010, Michael Painter wrote: > >> Have we all gone mad? >> I find it hard to understand that a nuclear power plant, air-traffic >> control network, or electrical grid would be 'linked' to the Internet >> in the interest of 'efficiency'. Air gap them all and let them apply >> for "Inefficiency Relief" from the $100 million relief fund. > > > Heck, removing all of these functions from the Internet will create > jobs, too, right? And no one would mind paying for all of this out of > their airline tickets, it should only increase fares by a third or so. > You know it is possible, mind you, possible to have control systems for things like the power grid and nuclear power plants to live on a physically separate network within a building from a terminal that has the internet connected to it. --C From owen at delong.com Thu Jul 8 12:28:58 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 8 Jul 2010 10:28:58 -0700 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52A1FA@RWC-EX1.corp.seven.com> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com><31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> <5A6D953473350C4B9995546AFE9939EE0A52A1FA@RWC-EX1.corp.seven.com> Message-ID: On Jul 8, 2010, at 10:13 AM, George Bonser wrote: > > >> -----Original Message----- >> From: Brandon Ross >> Sent: Thursday, July 08, 2010 6:52 AM >> To: Michael Painter >> Cc: nanog at nanog.org >> Subject: Re: U.S. Plans Cyber Shield for Utilities, Companies >> >> On Wed, 7 Jul 2010, Michael Painter wrote: >> >>> Have we all gone mad? >>> I find it hard to understand that a nuclear power plant, air-traffic >> control >>> network, or electrical grid would be 'linked' to the Internet in the >> interest >>> of 'efficiency'. Air gap them all and let them apply for >> "Inefficiency >>> Relief" from the $100 million relief fund. >> >> Absolutely! For example, those thousands of flight plans filed every >> day >> by airlines across the globe, not to mention private flights, should > be >> done manually the old fashioned way, with a paper form and stopping by >> your local FAA office where a human keys them into the ATC computer. >> Oh >> wait, we closed all of those offices when we moved all of those >> functions >> to the Internet. I guess we'll just have to re-open them. > > I believe the point was in response to: > > "control systems that were often designed without Internet connectivity > or security in mind. Many of those systems-which run everything from > subway systems to air-traffic control networks-have since been linked to > the Internet" > > If something was designed without network security "in mind" and then > connected to the internet as-is, then yeah, that pretty much is not only > "madness" but is just asking for trouble. So I am torn between this > being another exercise in treating the symptoms while ignoring the > underlying cause and at least having SOMEONE watching the front door if > the owners aren't paying any attention themselves. But I would think > the cost of the program could be scaled back somewhat if certain basic > security practices were mandated prior to the system being installed. > > > I think part of the problem comes from interrelationships between the transitive property of trust (if A trusts B and B trusts C, then A trusts C whether A knows it or not) and the perceived vs. actual nature of linkage. For example, it would seem madness to put an HTTP server directly on the primary Air Traffic Scheduling System at "FAA Central" and have it collect flight plans directly from the internet. However, what happens is that FAA contracts Lockheed out to run several Automated Flight Service Stations and also contracts two other companies (GTE and CONTEL last I looked at who had the contracts) to run a service known as "Direct User Access Terminals" or DUATS. Lockheed runs their own systems and interacts with pilots by telephone and radio. Flight Plans and Pilot Reports collected by Lockheed are put into Lockheed systems which are then linked into the FAA systems. I do not know if any of those links involve internet connectivity or not. LIkely some do. The DUATS systems also link into the FAA computers for uploading flight plans and pilot reports and for getting weather and NOTAM information from the FAA. As such, at least on some level, the FAA systems are linked to systems that are linked to the internet and there definitely isn't an air-gap. I suspect it is a full enough form of proxy that only data can traverse from one to the other. I think the design of the systems is probably relatively sane on that level. However, I doubt anyone on this list really knows for sure how the systems were designed or the exact nature of their linkages and I suspect there are many many other examples of such indirect linkages that have grown organically over time as the internet has moved from scientific novelty to a place to distribute web access and now starts to become the fundamental basis for communication among humans, machines, and others throughout the world. There used to be a clear line between telecom and datacom. It used to be that the internet was clearly datacom. Today, it's almost as if telecom as a separate discipline is going away and instead voice is becoming an application on the datacom network. It used to be that datacom was many disparate specialized networks each serving a particular datacom purpose. Today, the internet has become the generic low-level building block upon which virtually every datacom application, including the new telecom (voice as an application on a data network) is being built. With these changes and their relationships to legacy systems come new security concerns. Some known, many likely not even noticed as things move forward. Owen From shrdlu at deaddrop.org Thu Jul 8 12:33:56 2010 From: shrdlu at deaddrop.org (Shrdlu) Date: Thu, 08 Jul 2010 10:33:56 -0700 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <92403D84-4DF7-40DF-9CD0-5F3E20F2FE2E@delong.com> References: <201007081406.o68E6lkX004874@aurora.sol.net> <92403D84-4DF7-40DF-9CD0-5F3E20F2FE2E@delong.com> Message-ID: <4C360C04.4060502@deaddrop.org> Owen DeLong wrote: [snip] > I know this from being a pilot, and, also from having toured the following > ATC facilities: > Towers: > TRACONs: > ARTCCs: Ditto to absolutely EVERYTHING that Owen said, and I can guarantee this further, having had experience with various east coast and southeastern Towers, TRACONs, and ARTCCs (and having fond memories of it all). Personally, I'm more concerned about "Cisco Security Advisory: Hard-Coded SNMP Community Names in Cisco Industrial Ethernet 3000 Series Switches Vulnerability" than worrying about whatever the latest scary headline from n3td3v (aka andrew wallace) is. -- All men whilst they are awake are in one common world: but each of them, when he is asleep, is in a world of his own. Plutarch From bruns at 2mbit.com Thu Jul 8 12:38:30 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 08 Jul 2010 11:38:30 -0600 Subject: Email over v6 In-Reply-To: References: <2D9C4F16-7679-4D49-AC91-130518DEB25C@ecs.soton.ac.uk> <4C35F62E.8050900@2mbit.com> Message-ID: <4C360D16.5090100@2mbit.com> On 7/8/10 11:04 AM, Mikael Abrahamsson wrote: > On Thu, 8 Jul 2010, Brielle Bruns wrote: > >> By default, at least on Debian, TLS and IPv6 (if available, even if >> only using link local addresses) are on by default, so there's not too >> much that needs to be done to use TLS on the SMTP side. > > TLS wasn't enabled on my Debian using Postfix, so I guess it depends on > more factors than just "running Debian". IPv6 seems to be on by default, > yes. > Exim tends to be the default installed MTA from everything i've seen, and its TLS configuration is done as part of the split config method they use - check /etc/exim4/conf.d/main/03_exim4-config_tlsoptions I can't speak for anything other then what I see on default installs - given I only use exim myself, no real experience with postfix beyond my ISPConfig3 server. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jared at puck.nether.net Thu Jul 8 12:45:14 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Jul 2010 13:45:14 -0400 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <4C35F533.4080409@infiltrated.net> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> <4C35F533.4080409@infiltrated.net> Message-ID: On Jul 8, 2010, at 11:56 AM, J. Oquendo wrote: > @Jared's TSP link... Wonder how this will affect VoIP ITSP's etal, e.g., > how many local NS/EP's have swapped over to VoIP. Logically, anyone with > a network running a managed VoIP service, trunk, etc., could qualify. This certainly is a frequent discussion point in some circles. A lot of carriers take your POTS/PRI and turn them into VoIP internally so they get the advantages of multiplexing the data on IP. This isn't universal, but a good question to ask your carrier. If you care about your call going through, you may actually want to pay a bit more and be on that more expensive TDM gear. Of course, whomever you call may also need to be on that same carrier. Take some time and research and test things out so you don't end up having trouble when you need your communications the most. You may also want to find your local HAM operator and buddy up with them, or get your no-code license today :) - Jared From dwhite at olp.net Thu Jul 8 13:21:03 2010 From: dwhite at olp.net (Dan White) Date: Thu, 8 Jul 2010 13:21:03 -0500 Subject: Email over v6 In-Reply-To: References: <2D9C4F16-7679-4D49-AC91-130518DEB25C@ecs.soton.ac.uk> <4C35F62E.8050900@2mbit.com> Message-ID: <20100708182103.GE2342@dan.olp.net> On 08/07/10?19:04?+0200, Mikael Abrahamsson wrote: > On Thu, 8 Jul 2010, Brielle Bruns wrote: > >> By default, at least on Debian, TLS and IPv6 (if available, even if >> only using link local addresses) are on by default, so there's not too >> much that needs to be done to use TLS on the SMTP side. > > TLS wasn't enabled on my Debian using Postfix, so I guess it depends on > more factors than just "running Debian". IPv6 seems to be on by default, > yes. I can confirm that STARTTLS was enabled out of the box on my Debian unstable system... using the snakeoil cert of course. IPv6 (port 25 incoming) was not enabled out of the box. I needed to add "inet_protocols = ipv4, ipv6" to enable it. -- Dan White From jgreco at ns.sol.net Thu Jul 8 13:23:10 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 8 Jul 2010 13:23:10 -0500 (CDT) Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: Message-ID: <201007081823.o68INAj2008059@aurora.sol.net> > On Thu, 8 Jul 2010, Joe Greco wrote: > > There's a happy medium in there somewhere; it's not clear that having (to > > use the examples given) air traffic control computers directly on the > > Internet has sufficient value to outweigh the risks. However, it seems > > that being able to securely gateway appropriate information between the > > two networks should be manageable, certainly a lot more manageable than > > the NxM complexity involved if you try to do it by securing each and > > every Internet-connected ATC PC individually. > > What makes you think that isn't exactly what this "Cyber Shield" project > is supposed to do? Because I'm cynical and I know how the real world works, and even if it's supposed to do that, by the time all is said and done, it probably won't. > Heck, what makes you think that's not the way most of > these systems already work today? Because we've all been told by those in the know that there are real vulnerabilities in these systems. > Do people really think the guy in the airport control tower is really > surfing Facebook while he's controlling aircraft on the same computer, or > that capability is even what is under consideration? The reality of what's actually going on can be debated pointlessly until we're blue in the face; none of us are in a position to know, I suspect. On the other hand, it takes a few milliseconds to recall an air traffic controller letting his kid land planes. http://tinyurl.com/2dzvooc So let's not be too naive here. Anything you expect can't happen - can and probably will at some point. The point is that we want to forcibly separate networks and technology so that an air traffic controller CANNOT possibly be surfing Facebook on a computer that's being used for critical work. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From LarrySheldon at cox.net Thu Jul 8 13:28:45 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 08 Jul 2010 13:28:45 -0500 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <09C1E7CF-D891-49B3-AA91-77F665164A0E@americafree.tv> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> <5620.1278598343@localhost> <09C1E7CF-D891-49B3-AA91-77F665164A0E@americafree.tv> Message-ID: <4C3618DD.4030200@cox.net> On 7/8/2010 09:59, Marshall Eubanks wrote: > I think that there needs to be a balance. I think it needs to be the purview of the custodian of the facility. Not some political wonk. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From jared at puck.nether.net Thu Jul 8 13:37:07 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Jul 2010 14:37:07 -0400 Subject: Email over v6 In-Reply-To: <20100708182103.GE2342@dan.olp.net> References: <2D9C4F16-7679-4D49-AC91-130518DEB25C@ecs.soton.ac.uk> <4C35F62E.8050900@2mbit.com> <20100708182103.GE2342@dan.olp.net> Message-ID: <1FAAD401-8414-46C1-AAA7-E92F2B715AF1@puck.nether.net> On Jul 8, 2010, at 2:21 PM, Dan White wrote: > On 08/07/10 19:04 +0200, Mikael Abrahamsson wrote: >> On Thu, 8 Jul 2010, Brielle Bruns wrote: >> >>> By default, at least on Debian, TLS and IPv6 (if available, even if only using link local addresses) are on by default, so there's not too much that needs to be done to use TLS on the SMTP side. >> >> TLS wasn't enabled on my Debian using Postfix, so I guess it depends on more factors than just "running Debian". IPv6 seems to be on by default, yes. > > I can confirm that STARTTLS was enabled out of the box on my Debian unstable > system... using the snakeoil cert of course. > > IPv6 (port 25 incoming) was not enabled out of the box. I needed to add > "inet_protocols = ipv4, ipv6" to enable it. I figured I would share actual data for everyone here, roughly 1:4.22 messages that are handled by my system go over some sort of IPv6 transport. (excluding connections from itself-to-itself.. i should make these be IPv6) puck:~> grep sm-mta /var/log/maillog | grep IPv4 | grep -v 204.42.254.5 | wc -l 22696 puck:~> grep sm-mta /var/log/maillog | grep IPv6 | wc -l 5371 The technical community lists are good fodder for this data. (eg: nanog, *-nsp) I do wonder if gmail.com gives out AAAA addresses for their MX, and the same for other mail solutions. This seems like something that is a no-brainer for me, as latency on email isn't a big deal where for HTTP transactions it can be. - Jared From danny at tcb.net Thu Jul 8 14:51:36 2010 From: danny at tcb.net (Danny McPherson) Date: Thu, 8 Jul 2010 13:51:36 -0600 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <7965.1278602764@localhost> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <31DB73E599B24579BED1D0DA1C1DDB7C@DELL16> <5620.1278598343@localhost> <4C35EADD.60908@gmail.com> <7965.1278602764@localhost> Message-ID: <8B858479-7411-489C-90CC-D749BA054EAA@tcb.net> On Jul 8, 2010, at 9:26 AM, Valdis.Kletnieks at vt.edu wrote: >> >> I'm not familiar with cable break splicing procedures, but is it even >> possible to pay extra to have your splice done first? I would think >> that the logistics of splicing are such that the guy down in the hole >> doesn't know whose traffic is on each strand in the bundle > > Exactly - which is a case for just having everybody's traffic mingled on > a very busy 12-pair rather than several 96-pair with lots of dedicated links, > *everybody* ends up back in service a lot faster... > > And remember - this industry has more trouble with backhoes and would-be > copper thieves than terrorists. Anybody who is defending against terrorists > by increasing their vulnerability to backhoes is, well... Having done a good bit of manual copper and [old school fusion] fiber splicing for a few years as an outside plant monkey in the Army Signal Corp and a short stint thereafter as a contractor, I assure you that prioritization can make a significant different with large cable damage, in particular when single wire/pair splicing is done. Copper multi-pair splicing still allows specific bundles to be prioritized as well, sorta the same as fiber. Given that cuts and other damage usually requires splicing on two ends, some bit of coordination is required but mostly trivial, in particular with large copper cable (e.g., 2400 pair). Of course, in fairness to Valdis's comment, setup time on both ends is often the dominating factor, although bundle 1 to bundle 96 is an 2400 pair copper cable could be several hours or more. Of course, physical plant prioritization is only the dominating factor when last mile damage occurs. It's more useful and commonly employed when intermediate facility failures happen - prioritized regrooming of critical services is sometimes even automated, and often results in, err.. less critical services being booted until full restoration has occurred. -danny From jared at puck.nether.net Thu Jul 8 16:13:41 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 8 Jul 2010 17:13:41 -0400 Subject: Email over v6 In-Reply-To: <1FAAD401-8414-46C1-AAA7-E92F2B715AF1@puck.nether.net> References: <2D9C4F16-7679-4D49-AC91-130518DEB25C@ecs.soton.ac.uk> <4C35F62E.8050900@2mbit.com> <20100708182103.GE2342@dan.olp.net> <1FAAD401-8414-46C1-AAA7-E92F2B715AF1@puck.nether.net> Message-ID: <2F87AB2A-006E-44B8-82F6-49E30AFD3A17@puck.nether.net> A few people have sent private replies commenting on the email/IPv6 deployment stats I posted. I thought I would also share some nameserver statistics to give an idea of what I see (at least at puck.nether.net) for IPv6 vs IPv4 queries. I won't break down the numbers for everyone, just posting the raw values from a bind stats dump. The stats are from ~June 21st to now. [View: _bind] ++ Name Server Statistics ++ 359127071 IPv4 requests received 6024171 IPv6 requests received ++ Resolver Statistics ++ [Common] 12966 mismatch responses received [View: default] 9028037 IPv4 queries sent 733851 IPv6 queries sent 8431489 IPv4 responses received 705457 IPv6 responses received ... 800617 IPv4 NS address fetches 807581 IPv6 NS address fetches 16773 IPv4 NS address fetch failed 759240 IPv6 NS address fetch failed [View: _bind (Cache: _bind)] ++ Socket I/O Statistics ++ 9047706 UDP/IPv4 sockets opened 741832 UDP/IPv6 sockets opened 73995 TCP/IPv4 sockets opened 1362 TCP/IPv6 sockets opened 9047703 UDP/IPv4 sockets closed 741831 UDP/IPv6 sockets closed 91701 TCP/IPv4 sockets closed 1569 TCP/IPv6 sockets closed 1421 UDP/IPv4 socket bind failures 10 UDP/IPv6 socket bind failures 10718 TCP/IPv4 socket connect failures 632 TCP/IPv6 socket connect failures 9025101 UDP/IPv4 connections established 733586 UDP/IPv6 connections established 63200 TCP/IPv4 connections established 729 TCP/IPv6 connections established 17709 TCP/IPv4 connections accepted 208 TCP/IPv6 connections accepted 29998 UDP/IPv4 recv errors 6842 UDP/IPv6 recv errors 1055 TCP/IPv4 recv errors From alan at gtekcommunications.com Thu Jul 8 17:05:57 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Thu, 8 Jul 2010 17:05:57 -0500 Subject: Rate Limiting on Cisco Router Message-ID: Thanks again for all the responses to my previous post. We have a Cisco 7206VXR router with IOS of 12.4(12) and a PA-POS-1OC3 card ofr our OC3. The problem we have now is that we are only paying for 80 MB/s of the OC-3, and the ISP is leaving the capping of it up to us. I have googled and the only things I can find is that you can not do a real cap on this type of interface. We have tried the rate-limit command with various parameters and we are unable to keep it at 80. I have read that this is not the correct way to do it, but I'm not sure what is. Any advice? Pointers appreciated. -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From tony at lava.net Thu Jul 8 17:19:32 2010 From: tony at lava.net (Antonio Querubin) Date: Thu, 8 Jul 2010 12:19:32 -1000 (HST) Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: On Thu, 8 Jul 2010, Alan Bryant wrote: > We have tried the rate-limit command with various parameters and we > are unable to keep it at 80. I have read that this is not the correct > way to do it, but I'm not sure what is. What burst parameters are you using? Try something along the lines of: rate-limit input 80000000 15000000 15000000 conform-action transmit exceed-action drop rate-limit output 80000000 15000000 15000000 conform-action transmit exceed-action drop on your OC3 interface. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From tony at lava.net Thu Jul 8 17:25:41 2010 From: tony at lava.net (Antonio Querubin) Date: Thu, 8 Jul 2010 12:25:41 -1000 (HST) Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: On Thu, 8 Jul 2010, Alan Bryant wrote: > The problem we have now is that we are only paying for 80 MB/s of the > OC-3, and the ISP is leaving the capping of it up to us. I have BTW, rate-limiting of traffic that the ISP router sends to your router is best done at the ISP router. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From nick at brevardwireless.com Thu Jul 8 17:28:02 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Thu, 8 Jul 2010 18:28:02 -0400 Subject: Rate Limiting on Cisco Router Message-ID: <268266c3$523aca29$3d939b96$@com> That's strange, Are you paying for a CIR of 80Mb/s? Normally they only leave the limiting up to you if its more of a burstable connection, Like you pay for 80Mb/s but its a full line rate interface and its billed per Mb/s over 80 on a 95th percentile scheme. If that is the case you can safely go over 80Mb/s for a certian amount of time per month, Assuming its billed monthly. Nick Olsen Network Operations (321) 205-1100 x106 ---------------------------------------- From: "Alan Bryant" Sent: Thursday, July 08, 2010 6:07 PM To: nanog at nanog.org Subject: Rate Limiting on Cisco Router Thanks again for all the responses to my previous post. We have a Cisco 7206VXR router with IOS of 12.4(12) and a PA-POS-1OC3 card ofr our OC3. The problem we have now is that we are only paying for 80 MB/s of the OC-3, and the ISP is leaving the capping of it up to us. I have googled and the only things I can find is that you can not do a real cap on this type of interface. We have tried the rate-limit command with various parameters and we are unable to keep it at 80. I have read that this is not the correct way to do it, but I'm not sure what is. Any advice? Pointers appreciated. -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From Jay.Murphy at state.nm.us Thu Jul 8 17:43:40 2010 From: Jay.Murphy at state.nm.us (Murphy, Jay, DOH) Date: Thu, 8 Jul 2010 16:43:40 -0600 Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: traffic-shape rate 75000000 90000000 90000000 1000 for example. Your rate limit will police your traffic and drop it all. Traffic shaping produces a queue, and does not completely junk a packet. It becomes q'd, and produces a smoother output. ~Jay Murphy IP Network Specialist NM State Government IT Services Division PSB ? IP Network Management Center Santa F?, New M?xico 87505 "We move the information that moves your world." ?Good engineering demands that we understand what we?re doing and why, keep an open mind, and learn from experience.? ?Engineering is about finding the sweet spot between what's solvable and what isn't." Radia Perlman ? Please consider the environment before printing e-mail -----Original Message----- From: Antonio Querubin [mailto:tony at lava.net] Sent: Thursday, July 08, 2010 4:26 PM To: Alan Bryant Cc: nanog at nanog.org Subject: Re: Rate Limiting on Cisco Router On Thu, 8 Jul 2010, Alan Bryant wrote: > The problem we have now is that we are only paying for 80 MB/s of the > OC-3, and the ISP is leaving the capping of it up to us. I have BTW, rate-limiting of traffic that the ISP router sends to your router is best done at the ISP router. Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System. From kenny.sallee at gmail.com Thu Jul 8 18:35:24 2010 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Thu, 8 Jul 2010 16:35:24 -0700 Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: I think if you try to traffic-shape 80Mbps on that platform you'll have problems. We have a 7200 with NPE-G1 (rate limited at 80Mbps) and it killed the CPU when the threshold was hit. I imagine that traffic-shaping would do the same to CPU and memory. I'd lab it first. Kenny On Thu, Jul 8, 2010 at 3:43 PM, Murphy, Jay, DOH wrote: > traffic-shape rate 75000000 90000000 90000000 1000 for example. Your rate > limit will police your traffic and drop it all. > > Traffic shaping produces a queue, and does not completely junk a packet. It > becomes q'd, and produces a smoother output. > > ~Jay Murphy > IP Network Specialist > NM State Government > > IT Services Division > PSB ? IP Network Management Center > Santa F?, New M?xico 87505 > "We move the information that moves your world." > ?Good engineering demands that we understand what we?re doing and why, keep > an open mind, and learn from experience.? > ?Engineering is about finding the sweet spot between what's solvable and > what isn't." > Radia Perlman > ? Please consider the environment before printing e-mail > > > -----Original Message----- > From: Antonio Querubin [mailto:tony at lava.net] > Sent: Thursday, July 08, 2010 4:26 PM > To: Alan Bryant > Cc: nanog at nanog.org > Subject: Re: Rate Limiting on Cisco Router > > On Thu, 8 Jul 2010, Alan Bryant wrote: > > > The problem we have now is that we are only paying for 80 MB/s of the > > OC-3, and the ISP is leaving the capping of it up to us. I have > > BTW, rate-limiting of traffic that the ISP router sends to your router is > best done at the ISP router. > > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp: tony at lava.net > > > > Confidentiality Notice: This e-mail, including all attachments is for the > sole use of the intended recipient(s) and may contain confidential and > privileged information. Any unauthorized review, use, disclosure or > distribution is prohibited unless specifically provided under the New Mexico > Inspection of Public Records Act. If you are not the intended recipient, > please contact the sender and destroy all copies of this message. -- This > email has been scanned by the Sybari - Antigen Email System. > > > > From bclark at spectraaccess.com Thu Jul 8 18:41:31 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 08 Jul 2010 19:41:31 -0400 Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: <4C36622B.6070504@spectraaccess.com> Agree...when you rate limit verse shaping you can actually cause more traffic because the packets need to be retransmitted to deal with those that got dropped. On 07/08/2010 06:43 PM, Murphy, Jay, DOH wrote: > traffic-shape rate 75000000 90000000 90000000 1000 for example. Your rate limit will police your traffic and drop it all. > > Traffic shaping produces a queue, and does not completely junk a packet. It becomes q'd, and produces a smoother output. > > ~Jay Murphy > IP Network Specialist > NM State Government > > From tony at lava.net Thu Jul 8 18:43:17 2010 From: tony at lava.net (Antonio Querubin) Date: Thu, 8 Jul 2010 13:43:17 -1000 (HST) Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: On Thu, 8 Jul 2010, Murphy, Jay, DOH wrote: > Traffic shaping produces a queue, and does not completely junk a packet. > It becomes q'd, and produces a smoother output. Traffic-shaping 80Mb/s of traffic is probably not a good idea for your router cpu :) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From jbates at brightok.net Thu Jul 8 18:54:56 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 08 Jul 2010 18:54:56 -0500 Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: <4C366550.4030303@brightok.net> Antonio Querubin wrote: > > Traffic-shaping 80Mb/s of traffic is probably not a good idea for your > router cpu :) > Honestly, cpu overhead shouldn't be an issue with a traffic shape queue. If it is, probably a seriously underpowered router or poor code. Now if you applied extensive rules for various traffic at different rates and queue priorities, I could see lots of extra ticks. Don't get me wrong. I have 400mbps+ traffic shapes on my junipers and probably glad for the extensive hardware support (like I have a choice, no hardware support, the router won't do it) Jack From brandon.kim at brandontek.com Thu Jul 8 19:01:26 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 8 Jul 2010 20:01:26 -0400 Subject: Rate Limiting on Cisco Router In-Reply-To: References: , , , Message-ID: What about purchasing a low-end packetshaper to be used in between? I know this doesn't answer the question but could it be an option? > Date: Thu, 8 Jul 2010 13:43:17 -1000 > From: tony at lava.net > To: Jay.Murphy at state.nm.us > Subject: RE: Rate Limiting on Cisco Router > CC: nanog at nanog.org > > On Thu, 8 Jul 2010, Murphy, Jay, DOH wrote: > > > Traffic shaping produces a queue, and does not completely junk a packet. > > It becomes q'd, and produces a smoother output. > > Traffic-shaping 80Mb/s of traffic is probably not a good idea for your > router cpu :) > > Antonio Querubin > 808-545-5282 x3003 > e-mail/xmpp: tony at lava.net > From gordslater at ieee.org Thu Jul 8 19:07:32 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 09 Jul 2010 01:07:32 +0100 Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: <1278634052.4941.17.camel@ub-g-d2> On Thu, 2010-07-08 at 16:35 -0700, Kenny Sallee wrote: > I think if you try to traffic-shape 80Mbps on that platform you'll have > problems. We have a 7200 with NPE-G1 (rate limited at 80Mbps) and it killed > the CPU when the threshold was hit. I imagine that traffic-shaping would do > the same to CPU and memory. I'd lab it first. > I've seen that model preceded by a BSD machine with 2 physical ethernet NICs. When I asked - "limiting for the 7206's outgoing", so I'm assuming that was a CPU thing. In that case the 7206 was just an edge box for the fibre, so doing nothing complex. Capped at 48Mbps (IIRC) in that case - YMMV. Also bear in mind that this is borderline black art - it needs a bit of testing to be sure it's working as you expect :) My usual technique is to replay some flows then set several iperf streams going simultaneously to see how it reacts. Sometimes limiting just seems to temporarily break down under stress in bizarre ways. Whether it fails "open", "restricted" or "closed" seems to be very unpredictable and not very reproducible on some kit- keep your eye on it at first, or use BSD to do it if you're more familiar with that. Gord -- Awake! for morning in the bowl of light has flung the stone that puts the stars to flight From gordslater at ieee.org Thu Jul 8 19:13:23 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 09 Jul 2010 01:13:23 +0100 Subject: Rate Limiting on Cisco Router In-Reply-To: <4C366550.4030303@brightok.net> References: <4C366550.4030303@brightok.net> Message-ID: <1278634403.4941.21.camel@ub-g-d2> On Thu, 2010-07-08 at 18:54 -0500, Jack Bates wrote: > underpowered router or poor code Agreed. So which is it? :) To be fair, some IOS versions were better than others at it in my limited experience of that chassis. Gord -- I hold you XAP From alan at gtekcommunications.com Thu Jul 8 20:32:45 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Thu, 8 Jul 2010 20:32:45 -0500 Subject: Rate Limiting on Cisco Router In-Reply-To: <1278634403.4941.21.camel@ub-g-d2> References: <4C366550.4030303@brightok.net> <1278634403.4941.21.camel@ub-g-d2> Message-ID: So you guys would not recommend the traffic shaping route on a 7206 with a NPE-G1? Is it the processor or memory that would not be able to handle it? I don't necessarily plan on doing anything other than limiting it at 80Mbps or whatever it is that we are capping ourselves at at the time. On Thu, Jul 8, 2010 at 7:13 PM, gordon b slater wrote: > On Thu, 2010-07-08 at 18:54 -0500, Jack Bates wrote: >> underpowered router or poor code > > Agreed. So which is it? ?:) > > To be fair, some IOS versions were better than others at it in my > limited experience of that chassis. > > Gord > -- > I hold you XAP > > > > -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From alan at gtekcommunications.com Thu Jul 8 20:40:01 2010 From: alan at gtekcommunications.com (Alan Bryant) Date: Thu, 8 Jul 2010 20:40:01 -0500 Subject: Rate Limiting on Cisco Router In-Reply-To: References: <4C366550.4030303@brightok.net> <1278634403.4941.21.camel@ub-g-d2> Message-ID: Also, are there any upgrades that can be done to this router to increase it's processing power? Is there something better for the 7206VXR than the NPE-G1? I see the NPE-G2, but even on ebay it is very costly. On Thu, Jul 8, 2010 at 8:32 PM, Alan Bryant wrote: > So you guys would not recommend the traffic shaping route on a 7206 > with a NPE-G1? Is it the processor or memory that would not be able to > handle it? > > I don't necessarily plan on doing anything other than limiting it at > 80Mbps or whatever it is that we are capping ourselves at at the time. > > On Thu, Jul 8, 2010 at 7:13 PM, gordon b slater wrote: >> On Thu, 2010-07-08 at 18:54 -0500, Jack Bates wrote: >>> underpowered router or poor code >> >> Agreed. So which is it? ?:) >> >> To be fair, some IOS versions were better than others at it in my >> limited experience of that chassis. >> >> Gord >> -- >> I hold you XAP >> >> >> >> > > > > -- > Alan Bryant | Systems Administrator > Gtek Computers & Wireless, LLC. > alan at gtekcommunications.com | www.gtek.biz > O 361-777-1400 | F 361-777-1405 > -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From sethm at rollernet.us Thu Jul 8 20:52:03 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Thu, 08 Jul 2010 18:52:03 -0700 Subject: Rate Limiting on Cisco Router In-Reply-To: References: <4C366550.4030303@brightok.net> <1278634403.4941.21.camel@ub-g-d2> Message-ID: <4C3680C3.4040608@rollernet.us> On 7/8/2010 18:40, Alan Bryant wrote: > Also, are there any upgrades that can be done to this router to > increase it's processing power? Is there something better for the > 7206VXR than the NPE-G1? I see the NPE-G2, but even on ebay it is very > costly. > The NPE-G2 is the next step after the NPE-G1. ~Seth From cjp at 0x1.net Thu Jul 8 20:59:09 2010 From: cjp at 0x1.net (Christopher J. Pilkington) Date: Thu, 8 Jul 2010 21:59:09 -0400 Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: <20100709015909.GJ12614@0x1.net> On Thu, Jul 08, 2010 at 01:43:17PM -1000, Antonio Querubin wrote: > Traffic-shaping 80Mb/s of traffic is probably not a good idea for your > router cpu :) I concur, we shape a 100Mb/s ethernet down to 50Mb/s on a 3845, so that QoS is doable. The router gets brought to its knees around 40Mb/s. Turn off shaping and the router is usable all the way up to the 50Mb/s and then some. Is there a more reasonable way to do this on Cisco? max-reserved-bandwidth? -cjp From danny at tcb.net Thu Jul 8 21:04:11 2010 From: danny at tcb.net (Danny McPherson) Date: Thu, 8 Jul 2010 20:04:11 -0600 Subject: Rate Limiting on Cisco Router In-Reply-To: References: Message-ID: <96810006-1210-4B32-822B-3D6A35F2E059@tcb.net> On Jul 8, 2010, at 4:05 PM, Alan Bryant wrote: > Thanks again for all the responses to my previous post. > > We have a Cisco 7206VXR router with IOS of 12.4(12) and a PA-POS-1OC3 > card ofr our OC3. > > The problem we have now is that we are only paying for 80 MB/s of the > OC-3, and the ISP is leaving the capping of it up to us. I have > googled and the only things I can find is that you can not do a real > cap on this type of interface. > > We have tried the rate-limit command with various parameters and we > are unable to keep it at 80. I have read that this is not the correct > way to do it, but I'm not sure what is. > > Any advice? If your issue is cost for rates larger than 80 Mbps then you probably want to find out what applications are using the bulk of the bandwidth and either adjust your budget, or their performance expectations and allocate network resources expressly. Flow data (even local cache analysis v. exporting) would help you glean some of this, but external longer term analysis would surely be more useful - and there are lots of way you can do that - and use the data to either justify more budget or cull offending applications. As others have noted, rate *limiting* is usually indiscriminate and often results in non-determinism and far less 'goodput' than rate-shaping. If hardware constraints with those WAN-side PHY devices are gating, you could always do it on the LAN side, and perhaps much more selectively based on which application and associated network transaction traffic is the most valuable to your business and in your operating environment. Given, you didn't talk about asymmetries and egress traffic policy tweaking at the CPE to induce desired ingress levels is usually a science in and of it's self - but alas, if one must turn the steam valves ;-) I can't see application of any rate-limiting policies indiscriminately be desirable in any business environment, and suggest that if budget constrained worst case you align network resource allocation with critical business applications first via LAN-side rate-shaping functions - or AUPs, or.... -danny From swmike at swm.pp.se Thu Jul 8 23:12:47 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 9 Jul 2010 06:12:47 +0200 (CEST) Subject: Rate Limiting on Cisco Router In-Reply-To: References: <4C366550.4030303@brightok.net> <1278634403.4941.21.camel@ub-g-d2> Message-ID: On Thu, 8 Jul 2010, Alan Bryant wrote: > So you guys would not recommend the traffic shaping route on a 7206 > with a NPE-G1? Is it the processor or memory that would not be able to > handle it? With a G1 you'll be able to shape just fine, even do fancy stuff like fair-queue within those 80 megs. I've done this on a NPE-300, but only egress, and as long as packet sizes were fairly large (normal TCP sessions with mostly 1500 byte packets + ACKs) it coped with 90 megs of traffic. So with the added power of G1 you should definitely try before ruling it out. Shaping is so much better than the packet dropping that a rate limiter does. -- Mikael Abrahamsson email: swmike at swm.pp.se From gordslater at ieee.org Fri Jul 9 00:33:04 2010 From: gordslater at ieee.org (gordon b slater) Date: Fri, 09 Jul 2010 06:33:04 +0100 Subject: Rate Limiting on Cisco Router In-Reply-To: References: , , , Message-ID: <1278653584.4941.46.camel@ub-g-d2> On Thu, 2010-07-08 at 20:01 -0400, Brandon Kim wrote: > What about purchasing a low-end packetshaper to be used in between? If - 1/ budget is a problem and 2/ you have no BSD knowledge inhouse and 3/ the LAN side is all ethernet you could have a stab at using a PFsense box with two (and strictly ONLY two, for this use) physical NICs. It has a GUI to set up traffic shaping (see the sticky on the pfsense forums) PFsense 1.2.3 is current, don't go for the experimental 2.0 for production. There's a book and commercial support if you need it, free support via forums if you can't. Only two physical NICs is necessary due to shaper problems with more than two, whereas in a firewalling role the slots are the only limit (but VLANS are the norm for bucketloads of ports on a firewall PFsense box) An ITX (Littlefalls etc) mobo with 512MB RAM with an extra PCI Intel NIC added will do you fine . PFsense has nice traffic graphs, which helps you with shaping speeds in a big way. It also has a TFTP server available for it so it's handy for unmanned sites with only a few blue boxes ;) PS - a crazy afterthough - surely just about anything with a 10/100 ethernet link running at 100 and placed inline, cannot exceed 100Mbps - and probably less if it's plastic-cased? Try a few 8-port junkers and see what happens if you fancy a walk on the dangerous side. Watch out for errors and smoke :) Gord -- The drinker you are the smoker you get From jbates at brightok.net Fri Jul 9 00:50:19 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 09 Jul 2010 00:50:19 -0500 Subject: Rate Limiting on Cisco Router In-Reply-To: References: <4C366550.4030303@brightok.net> <1278634403.4941.21.camel@ub-g-d2> Message-ID: <4C36B89B.1060908@brightok.net> Mikael Abrahamsson wrote: > > With a G1 you'll be able to shape just fine, even do fancy stuff like > fair-queue within those 80 megs. I've done this on a NPE-300, but only > egress, and as long as packet sizes were fairly large (normal TCP > sessions with mostly 1500 byte packets + ACKs) it coped with 90 megs of > traffic. So with the added power of G1 you should definitely try before > ruling it out. > Definitely worth the try. Your biggest enemy may be 12.4 IOS. It's bloated and buggy in my experience, but that has mostly been edge services. If 12.4 pegs your processor, you may want to check the software/hardware matrix and see if one of the older 12.0/2 service provider trains that they continued to add support for (probably some large customer's special requests). I don't know if it will support the G1, but if so, you might have better performance out of it. > Shaping is so much better than the packet dropping that a rate limiter > does. > Definitely. My favorite off the wall use of shaping was to smooth traffic flow on a Gig-e to reduce microbursts from overrunning the hardware rx on a 7513. :) Jack From Hampus.Linden at ipreo.com Fri Jul 9 02:00:40 2010 From: Hampus.Linden at ipreo.com (Hampus Linden) Date: Fri, 9 Jul 2010 08:00:40 +0100 Subject: Can someone from Level3 contact me off list please Message-ID: <4B34F73EAA399D47921538F1637A2D8B0D4565EAC4@ex45chuk01.uk.corp.local> I can see a stray subnet of the IP space we advertise to you in the Level3 looking glass. Thanks, Hampus ________________________________ ****************************************************************** This e-mail message and any attachments are confidential. Dissemination, distribution or copying of this e-mail or any attachments by anyone other than the intended recipient is prohibited. If you are not the intended recipient, please notify Ipreo immediately by replying to this e-mail, and destroy all copies of this e-mail and any attachments. Thank you! ****************************************************************** From cayers at ena.com Fri Jul 9 08:19:12 2010 From: cayers at ena.com (Cory Ayers) Date: Fri, 9 Jul 2010 08:19:12 -0500 Subject: Rate Limiting on Cisco Router In-Reply-To: <4C36B89B.1060908@brightok.net> References: <4C366550.4030303@brightok.net><1278634403.4941.21.camel@ub-g-d2> <4C36B89B.1060908@brightok.net> Message-ID: > Definitely worth the try. Your biggest enemy may be 12.4 IOS. It's > bloated and buggy in my experience, but that has mostly been edge > services. If 12.4 pegs your processor, you may want to check the > software/hardware matrix and see if one of the older 12.0/2 service > provider trains that they continued to add support for (probably some > large customer's special requests). I don't know if it will support the > G1, but if so, you might have better performance out of it. > > > Jack We've implemented 400Mbps shaping with over twenty nested child policies (individual customer shaping and queuing within the 400M) on an NPE-G1 running 12.4(12c). CPU does start to become an issue at that point, and by removing the policy we can reach nearly 600Mbps on the same kit. We run standard ACL, OSPF, EIGRP, VRF Selection, MPLS, MP-BGP, etc. but do not run a full Internet BGP feed on these boxes, so you'll need to subtract that process usage if it applies. I would note that upgrading the box to 12.2(33)SRC caused a 20%+ increase in CPU attributed to the HQF (Hierarchical QOS Framework) process. We decided to stay with the 12.4 train. Cory Ayers CCIE #16874 (R&S), CCIP Director of Network Strategy Education Networks of America From brandon.kim at brandontek.com Fri Jul 9 08:49:43 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Fri, 9 Jul 2010 09:49:43 -0400 Subject: Rate Limiting on Cisco Router In-Reply-To: <1278653584.4941.46.camel@ub-g-d2> References: ,, ,, ,, , , <1278653584.4941.46.camel@ub-g-d2> Message-ID: Pretty funny and good stuff....since no one really acheives true 100MB speeds anyways, then a 100MB port might actually traffic shape itself naturally!!! I forget what the actual speeds truly are... is it 80% advertised speeds? I'm not sure which is cheaper but I think Juniper has some low end Netscreens you can try also that have traffic shaping features..... > Subject: RE: Rate Limiting on Cisco Router > From: gordslater at ieee.org > To: brandon.kim at brandontek.com > CC: nanog at nanog.org > Date: Fri, 9 Jul 2010 06:33:04 +0100 > > On Thu, 2010-07-08 at 20:01 -0400, Brandon Kim wrote: > > What about purchasing a low-end packetshaper to be used in between? > > If - > > 1/ budget is a problem > > and > > 2/ you have no BSD knowledge inhouse > > and > > 3/ the LAN side is all ethernet > > you could have a stab at using a PFsense box with two (and strictly ONLY > two, for this use) physical NICs. It has a GUI to set up traffic shaping > (see the sticky on the pfsense forums) PFsense 1.2.3 is current, don't > go for the experimental 2.0 for production. There's a book and > commercial support if you need it, free support via forums if you can't. > > Only two physical NICs is necessary due to shaper problems with more > than two, whereas in a firewalling role the slots are the only limit > (but VLANS are the norm for bucketloads of ports on a firewall PFsense > box) > An ITX (Littlefalls etc) mobo with 512MB RAM with an extra PCI Intel NIC > added will do you fine > .. > PFsense has nice traffic graphs, which helps you with shaping speeds in > a big way. It also has a TFTP server available for it so it's handy for > unmanned sites with only a few blue boxes ;) > > PS - a crazy afterthough - surely just about anything with a 10/100 > ethernet link running at 100 and placed inline, cannot exceed 100Mbps - > and probably less if it's plastic-cased? Try a few 8-port junkers and > see what happens if you fancy a walk on the dangerous side. Watch out > for errors and smoke :) > > Gord > -- > The drinker you are the smoker you get > > From dylan.ebner at crlmed.com Fri Jul 9 11:43:09 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Fri, 9 Jul 2010 16:43:09 +0000 Subject: Hardware for 50Mbs BGP feed.WAS Rate Limiting on Cisco Router In-Reply-To: References: <4C366550.4030303@brightok.net> <1278634403.4941.21.camel@ub-g-d2> Message-ID: <017265BF3B9640499754DD48777C3D206909E34508@MBX9.EXCHPROD.USA.NET> Yesterday we took possession of a free 50Mb connection upgrade from one of our ISPs. The previous connection was 30Mbps with a partial route table via BGP. Other than BGP, the only other complex functions the router performs is access listing the CRYMU Team Bogon table and traffic shaping. We terminate this into a 2811 running 12.4 with 512MB of memory. When the Access lists were applied we peaked the connection at 39Mbps and when the access list was removed we peaked at 43.5Mbps. The CPU was pegged at 65% with the acl and 50% without. Given the recent discussion about 80Mbps and a 7200, what would members here recommend for a 50Mb connection that we expect to grow to 100Mb in the next 18 months. We are also planning on adding netflow collection in the next year as well. We were think of upgrading to a 3900 series, but it sounds like maybe we should be thinking bigger? Also, how do members determine if their routers are overloaded. Besides looking at memory and CPU usage are their other statistics they look at? Are their third party tools that provide some insight into the routers condition? Dylan Ebner -----Original Message----- From: Alan Bryant [mailto:alan at gtekcommunications.com] Sent: Thursday, July 08, 2010 8:33 PM To: gordslater at ieee.org Cc: Murphy, Jay, DOH; nanog at nanog.org Subject: Re: Rate Limiting on Cisco Router So you guys would not recommend the traffic shaping route on a 7206 with a NPE-G1? Is it the processor or memory that would not be able to handle it? I don't necessarily plan on doing anything other than limiting it at 80Mbps or whatever it is that we are capping ourselves at at the time. On Thu, Jul 8, 2010 at 7:13 PM, gordon b slater wrote: > On Thu, 2010-07-08 at 18:54 -0500, Jack Bates wrote: >> underpowered router or poor code > > Agreed. So which is it? ?:) > > To be fair, some IOS versions were better than others at it in my > limited experience of that chassis. > > Gord > -- > I hold you XAP > > > > -- Alan Bryant | Systems Administrator Gtek Computers & Wireless, LLC. alan at gtekcommunications.com | www.gtek.biz O 361-777-1400 | F 361-777-1405 From chris at uplogon.com Fri Jul 9 12:35:52 2010 From: chris at uplogon.com (Chris Gotstein) Date: Fri, 09 Jul 2010 12:35:52 -0500 Subject: Hardware for 50Mbs BGP feed.WAS Rate Limiting on Cisco Router In-Reply-To: <017265BF3B9640499754DD48777C3D206909E34508@MBX9.EXCHPROD.USA.NET> References: <4C366550.4030303@brightok.net> <1278634403.4941.21.camel@ub-g-d2> <017265BF3B9640499754DD48777C3D206909E34508@MBX9.EXCHPROD.USA.NET> Message-ID: <4C375DF8.5050807@uplogon.com> I think a 7200VXR with NPE-G1 that has 1Gb of ram would work just fine for you. We are running a very similar setup, passing about 70Mbs, full BGP routes, 2 providers and ACLs, only seeing about 20% usage on the CPU at peak times. ---- ---- ---- ---- Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. http://uplogon.com | +1 906 774 4847 | chris at uplogon.com On 7/9/2010 11:43 AM, Dylan Ebner wrote: > Yesterday we took possession of a free 50Mb connection upgrade from one of our ISPs. The previous connection was 30Mbps with a partial route table via BGP. Other than BGP, the only other complex functions the router performs is access listing the CRYMU Team Bogon table and traffic shaping. We terminate this into a 2811 running 12.4 with 512MB of memory. When the Access lists were applied we peaked the connection at 39Mbps and when the access list was removed we peaked at 43.5Mbps. The CPU was pegged at 65% with the acl and 50% without. Given the recent discussion about 80Mbps and a 7200, what would members here recommend for a 50Mb connection that we expect to grow to 100Mb in the next 18 months. We are also planning on adding netflow collection in the next year as well. > > We were think of upgrading to a 3900 series, but it sounds like maybe we should be thinking bigger? > > Also, how do members determine if their routers are overloaded. Besides looking at memory and CPU usage are their other statistics they look at? Are their third party tools that provide some insight into the routers condition? > > > > Dylan Ebner > > -----Original Message----- > From: Alan Bryant [mailto:alan at gtekcommunications.com] > Sent: Thursday, July 08, 2010 8:33 PM > To: gordslater at ieee.org > Cc: Murphy, Jay, DOH; nanog at nanog.org > Subject: Re: Rate Limiting on Cisco Router > > So you guys would not recommend the traffic shaping route on a 7206 > with a NPE-G1? Is it the processor or memory that would not be able to > handle it? > > I don't necessarily plan on doing anything other than limiting it at > 80Mbps or whatever it is that we are capping ourselves at at the time. > > On Thu, Jul 8, 2010 at 7:13 PM, gordon b slater wrote: >> On Thu, 2010-07-08 at 18:54 -0500, Jack Bates wrote: >>> underpowered router or poor code >> >> Agreed. So which is it? :) >> >> To be fair, some IOS versions were better than others at it in my >> limited experience of that chassis. >> >> Gord >> -- >> I hold you XAP >> >> >> >> > > > From mhuff at ox.com Fri Jul 9 13:01:02 2010 From: mhuff at ox.com (Matthew Huff) Date: Fri, 9 Jul 2010 14:01:02 -0400 Subject: Hardware for 50Mbs BGP feed.WAS Rate Limiting on Cisco Router In-Reply-To: <4C375DF8.5050807@uplogon.com> References: <4C366550.4030303@brightok.net> <1278634403.4941.21.camel@ub-g-d2> <017265BF3B9640499754DD48777C3D206909E34508@MBX9.EXCHPROD.USA.NET> <4C375DF8.5050807@uplogon.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2C29EA355@PUR-EXCH07.ox.com> We have something very similar. We have 2 x 7204VXR/NPE-G1 with 1GB RAM each with a 50Mb connection to an upstream provider with full routes. No cpu or other problems at all. -----Original Message----- From: Chris Gotstein [mailto:chris at uplogon.com] Sent: Friday, July 09, 2010 1:36 PM To: nanog at nanog.org Subject: Re: Hardware for 50Mbs BGP feed.WAS Rate Limiting on Cisco Router I think a 7200VXR with NPE-G1 that has 1Gb of ram would work just fine for you. We are running a very similar setup, passing about 70Mbs, full BGP routes, 2 providers and ACLs, only seeing about 20% usage on the CPU at peak times. ---- ---- ---- ---- Chris Gotstein, Network Engineer, U.P. Logon/Computer Connection U.P. http://uplogon.com | +1 906 774 4847 | chris at uplogon.com On 7/9/2010 11:43 AM, Dylan Ebner wrote: > Yesterday we took possession of a free 50Mb connection upgrade from one of our ISPs. The previous connection was 30Mbps with a partial route table via BGP. Other than BGP, the only other complex functions the router performs is access listing the CRYMU Team Bogon table and traffic shaping. We terminate this into a 2811 running 12.4 with 512MB of memory. When the Access lists were applied we peaked the connection at 39Mbps and when the access list was removed we peaked at 43.5Mbps. The CPU was pegged at 65% with the acl and 50% without. Given the recent discussion about 80Mbps and a 7200, what would members here recommend for a 50Mb connection that we expect to grow to 100Mb in the next 18 months. We are also planning on adding netflow collection in the next year as well. > > We were think of upgrading to a 3900 series, but it sounds like maybe we should be thinking bigger? > > Also, how do members determine if their routers are overloaded. Besides looking at memory and CPU usage are their other statistics they look at? Are their third party tools that provide some insight into the routers condition? > > > > Dylan Ebner > > -----Original Message----- > From: Alan Bryant [mailto:alan at gtekcommunications.com] > Sent: Thursday, July 08, 2010 8:33 PM > To: gordslater at ieee.org > Cc: Murphy, Jay, DOH; nanog at nanog.org > Subject: Re: Rate Limiting on Cisco Router > > So you guys would not recommend the traffic shaping route on a 7206 > with a NPE-G1? Is it the processor or memory that would not be able to > handle it? > > I don't necessarily plan on doing anything other than limiting it at > 80Mbps or whatever it is that we are capping ourselves at at the time. > > On Thu, Jul 8, 2010 at 7:13 PM, gordon b slater wrote: >> On Thu, 2010-07-08 at 18:54 -0500, Jack Bates wrote: >>> underpowered router or poor code >> >> Agreed. So which is it? :) >> >> To be fair, some IOS versions were better than others at it in my >> limited experience of that chassis. >> >> Gord >> -- >> I hold you XAP >> >> >> >> > > > From cscora at apnic.net Fri Jul 9 13:10:06 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 10 Jul 2010 04:10:06 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201007091810.o69IA73J022590@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 10 Jul, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 325466 Prefixes after maximum aggregation: 149552 Deaggregation factor: 2.18 Unique aggregates announced to Internet: 158969 Total ASes present in the Internet Routing Table: 34308 Prefixes per ASN: 9.49 Origin-only ASes present in the Internet Routing Table: 29787 Origin ASes announcing only one prefix: 14424 Transit ASes present in the Internet Routing Table: 4521 Transit-only ASes present in the Internet Routing Table: 105 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 302 Unregistered ASNs in the Routing Table: 115 Number of 32-bit ASNs allocated by the RIRs: 679 Prefixes from 32-bit ASNs in the Routing Table: 817 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 158 Number of addresses announced to Internet: 2254936928 Equivalent to 134 /8s, 103 /16s and 155 /24s Percentage of available address space announced: 60.8 Percentage of allocated address space announced: 65.6 Percentage of available address space allocated: 92.8 Percentage of address space in use by end-sites: 83.6 Total number of prefixes smaller than registry allocations: 155267 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 78693 Total APNIC prefixes after maximum aggregation: 27034 APNIC Deaggregation factor: 2.91 Prefixes being announced from the APNIC address blocks: 75569 Unique aggregates announced from the APNIC address blocks: 33337 APNIC Region origin ASes present in the Internet Routing Table: 4107 APNIC Prefixes per ASN: 18.40 APNIC Region origin ASes announcing only one prefix: 1132 APNIC Region transit ASes present in the Internet Routing Table: 638 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 526528800 Equivalent to 31 /8s, 98 /16s and 49 /24s Percentage of available APNIC address space announced: 78.5 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 134709 Total ARIN prefixes after maximum aggregation: 69317 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 107638 Unique aggregates announced from the ARIN address blocks: 41899 ARIN Region origin ASes present in the Internet Routing Table: 13775 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix: 5281 ARIN Region transit ASes present in the Internet Routing Table: 1351 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 730782240 Equivalent to 43 /8s, 142 /16s and 218 /24s Percentage of available ARIN address space announced: 62.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 74687 Total RIPE prefixes after maximum aggregation: 43289 RIPE Deaggregation factor: 1.73 Prefixes being announced from the RIPE address blocks: 67835 Unique aggregates announced from the RIPE address blocks: 44452 RIPE Region origin ASes present in the Internet Routing Table: 14572 RIPE Prefixes per ASN: 4.66 RIPE Region origin ASes announcing only one prefix: 7500 RIPE Region transit ASes present in the Internet Routing Table: 2177 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 433722912 Equivalent to 25 /8s, 218 /16s and 22 /24s Percentage of available RIPE address space announced: 76.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 28990 Total LACNIC prefixes after maximum aggregation: 6947 LACNIC Deaggregation factor: 4.17 Prefixes being announced from the LACNIC address blocks: 27474 Unique aggregates announced from the LACNIC address blocks: 14473 LACNIC Region origin ASes present in the Internet Routing Table: 1305 LACNIC Prefixes per ASN: 21.05 LACNIC Region origin ASes announcing only one prefix: 401 LACNIC Region transit ASes present in the Internet Routing Table: 226 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 75275520 Equivalent to 4 /8s, 124 /16s and 157 /24s Percentage of available LACNIC address space announced: 56.1 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7322 Total AfriNIC prefixes after maximum aggregation: 1844 AfriNIC Deaggregation factor: 3.97 Prefixes being announced from the AfriNIC address blocks: 5621 Unique aggregates announced from the AfriNIC address blocks: 1725 AfriNIC Region origin ASes present in the Internet Routing Table: 373 AfriNIC Prefixes per ASN: 15.07 AfriNIC Region origin ASes announcing only one prefix: 110 AfriNIC Region transit ASes present in the Internet Routing Table: 82 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 19610368 Equivalent to 1 /8s, 43 /16s and 59 /24s Percentage of available AfriNIC address space announced: 58.4 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1857 8425 493 Korea Telecom (KIX) 4755 1369 296 163 TATA Communications formerly 7545 1359 232 105 TPG Internet Pty Ltd 17488 1322 144 125 Hathway IP Over Cable Interne 17974 1156 285 28 PT TELEKOMUNIKASI INDONESIA 9583 999 74 488 Sify Limited 24560 927 305 168 Bharti Airtel Ltd., Telemedia 4134 877 21420 409 CHINANET-BACKBONE 4808 824 1575 219 CNCGROUP IP network: China169 9829 810 683 29 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3903 3734 290 bellsouth.net, inc. 4323 2719 1114 394 Time Warner Telecom 19262 1827 4562 274 Verizon Global Networks 1785 1778 698 129 PaeTec Communications, Inc. 20115 1546 1522 655 Charter Communications 7018 1510 5735 962 AT&T WorldNet Services 6478 1284 258 126 AT&T Worldnet Services 2386 1279 567 903 AT&T Data Communications Serv 3356 1175 10877 405 Level 3 Communications, LLC 22773 1167 2859 65 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 650 56 6 United Telecom of Georgia 3292 452 2027 393 TDC Tele Danmark 30890 442 111 207 Evolva Telecom 702 414 1869 326 UUNET - Commercial IP service 9198 409 202 13 Kazakhtelecom Data Network Ad 8866 402 117 18 Bulgarian Telecommunication C 8551 400 353 46 Bezeq International 3320 373 7329 324 Deutsche Telekom AG 3301 372 1414 327 TeliaNet Sweden 34984 359 89 185 BILISIM TELEKOM Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1523 3017 245 UniNet S.A. de C.V. 10620 1062 238 150 TVCABLE BOGOTA 28573 1028 795 98 NET Servicos de Comunicao S.A 7303 760 390 104 Telecom Argentina Stet-France 6503 682 175 219 AVANTEL, S.A. 22047 548 310 15 VTR PUNTO NET S.A. 3816 499 216 87 Empresa Nacional de Telecomun 14420 489 31 71 CORPORACION NACIONAL DE TELEC 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 451 99 77 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1165 445 10 TEDATA 24863 727 147 39 LINKdotNET AS number 36992 646 279 185 Etisalat MISR 3741 267 834 229 The Internet Solution 33776 219 12 11 Starcomms Nigeria Limited 2018 209 244 61 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 24835 191 78 10 RAYA Telecom - Egypt 29571 177 19 10 Ci Telecom Autonomous system 16637 161 440 96 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3903 3734 290 bellsouth.net, inc. 4323 2719 1114 394 Time Warner Telecom 4766 1857 8425 493 Korea Telecom (KIX) 19262 1827 4562 274 Verizon Global Networks 1785 1778 698 129 PaeTec Communications, Inc. 20115 1546 1522 655 Charter Communications 8151 1523 3017 245 UniNet S.A. de C.V. 7018 1510 5735 962 AT&T WorldNet Services 4755 1369 296 163 TATA Communications formerly 7545 1359 232 105 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2719 2325 Time Warner Telecom 1785 1778 1649 PaeTec Communications, Inc. 19262 1827 1553 Verizon Global Networks 4766 1857 1364 Korea Telecom (KIX) 8151 1523 1278 UniNet S.A. de C.V. 7545 1359 1254 TPG Internet Pty Ltd 4755 1369 1206 TATA Communications formerly 17488 1322 1197 Hathway IP Over Cable Interne 6478 1284 1158 AT&T Worldnet Services 8452 1165 1155 TEDATA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:20 /9:10 /10:25 /11:68 /12:196 /13:407 /14:709 /15:1286 /16:11170 /17:5348 /18:9150 /19:18443 /20:22955 /21:22945 /22:30130 /23:29679 /24:169670 /25:1036 /26:1328 /27:714 /28:117 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2501 3903 bellsouth.net, inc. 4766 1485 1857 Korea Telecom (KIX) 4323 1392 2719 Time Warner Telecom 1785 1239 1778 PaeTec Communications, Inc. 11492 1074 1165 Cable One 18566 1068 1087 Covad Communications 17488 1067 1322 Hathway IP Over Cable Interne 8452 1053 1165 TEDATA 10620 978 1062 TVCABLE BOGOTA 7018 910 1510 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:7 2:2 4:13 8:287 12:2015 13:7 14:1 15:22 16:3 17:8 20:17 24:1458 27:238 31:1 32:49 33:12 38:680 40:98 41:2446 44:3 46:1 47:18 52:9 55:4 56:2 57:28 58:752 59:501 60:459 61:1086 62:1065 63:1977 64:3655 65:2360 66:4042 67:1815 68:1106 69:2868 70:725 71:381 72:1952 73:2 74:2269 75:247 76:313 77:937 78:617 79:436 80:984 81:799 82:488 83:444 84:679 85:1051 86:456 87:680 88:331 89:1552 90:94 91:2863 92:487 93:989 94:1398 95:640 96:353 97:209 98:589 99:31 108:100 109:560 110:364 111:542 112:284 113:316 114:429 115:567 116:1073 117:651 118:479 119:941 120:132 121:724 122:1460 123:933 124:1122 125:1320 128:227 129:201 130:196 131:553 132:251 133:17 134:196 135:45 136:240 137:158 138:264 139:104 140:383 141:198 142:345 143:375 144:469 145:50 146:451 147:168 148:664 149:300 150:152 151:230 152:296 153:169 154:2 155:328 156:159 157:322 158:109 159:379 160:315 161:181 162:254 163:177 164:409 165:366 166:460 167:412 168:652 169:157 170:712 171:59 172:2 173:934 174:470 175:138 176:1 178:279 180:516 182:151 183:235 184:107 186:491 187:385 188:1004 189:781 190:3803 192:5733 193:4706 194:3375 195:2798 196:1184 198:3575 199:3460 200:5336 201:1564 202:7950 203:8284 204:4069 205:2330 206:2520 207:3114 208:3868 209:3454 210:2529 211:1268 212:1709 213:1640 214:641 215:69 216:4673 217:1531 218:496 219:378 220:1138 221:401 222:316 223:1 End of report From cidr-report at potaroo.net Fri Jul 9 17:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Jul 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201007092200.o69M029R044413@wattle.apnic.net> BGP Update Report Interval: 01-Jul-10 -to- 08-Jul-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9808 73291 5.7% 893.8 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 2 - AS24400 70334 5.4% 5861.2 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 3 - AS30890 37300 2.9% 84.0 -- EVOLVA Evolva Telecom s.r.l. 4 - AS2018 27569 2.1% 132.5 -- TENET-1 5 - AS14420 19813 1.5% 41.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 6 - AS5416 16616 1.3% 152.4 -- BATELCO-BH 7 - AS35931 15545 1.2% 7772.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - AS32528 12913 1.0% 2582.6 -- ABBOTT Abbot Labs 9 - AS8151 12351 0.9% 13.8 -- Uninet S.A. de C.V. 10 - AS2386 11099 0.9% 15.8 -- INS-AS - AT&T Data Communications Services 11 - AS25620 11084 0.9% 61.9 -- COTAS LTDA. 12 - AS5800 10191 0.8% 48.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 13 - AS9829 9961 0.8% 41.2 -- BSNL-NIB National Internet Backbone 14 - AS45464 9042 0.7% 215.3 -- NEXTWEB-AS-AP Room 201, TGU Bldg 15 - AS27947 8672 0.7% 50.7 -- Telconet S.A 16 - AS210 8228 0.6% 65.3 -- WEST-NET-WEST - Utah Education Network 17 - AS10620 8012 0.6% 7.7 -- Telmex Colombia S.A. 18 - AS8866 7832 0.6% 19.5 -- BTC-AS Bulgarian Telecommunication Company Plc. 19 - AS17974 6903 0.5% 15.8 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 20 - AS6503 6689 0.5% 11.1 -- Axtel, S.A.B. de C. V. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35931 15545 1.2% 7772.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS24400 70334 5.4% 5861.2 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 3 - AS32528 12913 1.0% 2582.6 -- ABBOTT Abbot Labs 4 - AS13030 2197 0.2% 2197.0 -- INIT7 Init Seven AG, Zurich, Switzerland 5 - AS19174 1460 0.1% 1460.0 -- CNC-USA - China Netcom (USA) Operations Ltd. 6 - AS9808 73291 5.7% 893.8 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 7 - AS11613 833 0.1% 833.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 8 - AS30372 1510 0.1% 755.0 -- SBS-NEWARK-CA - SIEMENS BUSINESS SERVICES 9 - AS27027 705 0.1% 705.0 -- ANBELL ASN-ANBELL 10 - AS7737 2050 0.2% 683.3 -- ASWELLNET - Aswell Corporation 11 - AS20708 1346 0.1% 673.0 -- SKODA-AUTO SKODA AUTO a.s. 12 - AS9969 1944 0.1% 648.0 -- WMS-NET-AS-KR KOREA RESOURCES RECOVERY AND REUTILIZATION CORPORATION 13 - AS15236 600 0.1% 600.0 -- Universidad de Colima 14 - AS9556 1650 0.1% 550.0 -- ADAM-AS-AP Adam Internet Pty Ltd 15 - AS38869 479 0.0% 479.0 -- SKYNET-AS-AP Skynetworks LLC 16 - AS26615 927 0.1% 463.5 -- Tim Celular S.A. 17 - AS26232 432 0.0% 432.0 -- VYATTA - Vyatta, Inc. 18 - AS3505 811 0.1% 405.5 -- WINDSTREAM - Windstream Communications Inc 19 - AS10445 2291 0.2% 381.8 -- HTG - Huntleigh Telcom 20 - AS28621 371 0.0% 371.0 -- FAROLBR NETWORKS LTDA. TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 111.10.4.0/24 14470 1.0% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 2 - 111.10.3.0/24 14465 1.0% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 3 - 111.10.1.0/24 14465 1.0% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 4 - 111.10.0.0/24 14464 1.0% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 5 - 111.10.2.0/24 14459 1.0% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 6 - 117.136.8.0/24 10524 0.8% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 7 - 117.135.128.0/18 10306 0.7% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 8 - 117.135.0.0/17 10289 0.7% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 9 - 117.131.0.0/17 9810 0.7% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 10 - 120.204.0.0/16 9664 0.7% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 11 - 198.140.43.0/24 8571 0.6% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 12 - 201.218.38.192/2 7096 0.5% AS27947 -- Telconet S.A 13 - 63.211.68.0/22 6974 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 14 - 130.36.34.0/24 6449 0.5% AS32528 -- ABBOTT Abbot Labs 15 - 130.36.35.0/24 6449 0.5% AS32528 -- ABBOTT Abbot Labs 16 - 196.2.16.0/24 5776 0.4% AS10474 -- NETACTIVE 17 - 190.65.228.0/22 5543 0.4% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 18 - 221.181.64.0/18 5135 0.4% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 19 - 143.138.107.0/24 3977 0.3% AS747 -- TAEGU-AS - Headquarters, USAISC 20 - 211.136.96.0/19 3656 0.3% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 9 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 9 Jul 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201007092200.o69M00qq044399@wattle.apnic.net> This report has been generated at Fri Jul 9 21:11:35 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 02-07-10 328551 201935 03-07-10 328172 202289 04-07-10 328506 202086 05-07-10 328496 202285 06-07-10 328385 202663 07-07-10 328504 202385 08-07-10 328535 202851 09-07-10 329107 202571 AS Summary 34808 Number of ASes in routing system 14764 Number of ASes announcing only one prefix 4480 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 96501056 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 09Jul10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 329268 202640 126628 38.5% All ASes AS6389 3901 295 3606 92.4% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4480 1771 2709 60.5% TWTC - tw telecom holdings, inc. AS19262 1827 274 1553 85.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4766 1857 507 1350 72.7% KIXS-AS-KR Korea Telecom AS22773 1168 70 1098 94.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1369 292 1077 78.7% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS17488 1322 325 997 75.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS6478 1284 375 909 70.8% ATT-INTERNET3 - AT&T WorldNet Services AS8151 1526 620 906 59.4% Uninet S.A. de C.V. AS10620 1063 231 832 78.3% Telmex Colombia S.A. AS5668 948 132 816 86.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS7545 1376 581 795 57.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS8452 1164 417 747 64.2% TEDATA TEDATA AS7303 760 116 644 84.7% Telecom Argentina S.A. AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS35805 650 52 598 92.0% SILKNET-AS SILKNET AS AS4808 824 243 581 70.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7018 1511 965 546 36.1% ATT-INTERNET4 - AT&T WorldNet Services AS7552 653 130 523 80.1% VIETEL-AS-AP Vietel Corporation AS4780 685 165 520 75.9% SEEDNET Digital United Inc. AS1785 1778 1268 510 28.7% AS-PAETEC-NET - PaeTec Communications, Inc. AS3356 1177 668 509 43.2% LEVEL3 Level 3 Communications AS9443 570 75 495 86.8% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 578 83 495 85.6% GIGAINFRA Softbank BB Corp. AS7011 1133 652 481 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS24560 931 469 462 49.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS28573 1028 571 457 44.5% NET Servicos de Comunicao S.A. AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. AS36992 648 210 438 67.6% ETISALAT-MISR Total 38453 11722 26731 69.5% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.45.0/24 AS16637 MTNNS-AS 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS33052 VZUNET - Verizon Data Services LLC 198.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.72.224.0/21 AS24013 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.81.18.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 202.81.23.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 202.81.24.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 202.81.30.0/24 AS24300 202.81.31.0/24 AS2687 ASATTCA AT&T Global Network Services - AP 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.169.96.0/24 AS7545 TPG-INTERNET-AP TPG Internet Pty Ltd 202.169.98.0/24 AS10143 EXETEL-AS-AP Exetel Pty Ltd 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nick.boyce at gmail.com Sat Jul 10 09:26:41 2010 From: nick.boyce at gmail.com (Nick Boyce) Date: Sat, 10 Jul 2010 15:26:41 +0100 Subject: [Bruce Hoffman] Thank-you for your recent participation. In-Reply-To: <20100707140055.GA11359@gsp.org> References: <86k4pozfe2.fsf@seastrom.com> <20100627182234.GB24403@gsp.org> <20100707140055.GA11359@gsp.org> Message-ID: On Thu, Jun 24, 2010 at 6:54 PM, Scott Leibrand wrote: > > On Thu 6/24/2010 7:14 AM, Robert E. Seastrom wrote: >> >> Amusingly, this was sent to me *after* I replied to abuse at internap >> complaining about getting spammed. > > If anyone else gets any unwanted contact from us, please let me know and > I'll make sure it's taken care of. Just my tinfoil-coated 2 cents: I tend to assume that when I get an email allegedly from Company A (Internap) but actually sent by Company/Domain B (iContact), inviting me to enter all kinds of sensitive information about my organisation's operations into a "survey" hosted at Domain C (Zoomerang), in return for which I may win a Dell laptop (but only if I give full identity-theft-enabling details about myself), then I'm being socially engineered by a Bad Guy, and I just press "delete". I do this, even when Company A is a big well-known company (e.g. Sun ... it's happened) or an industry magazine (e.g. Secure Computing .. ditto), cos lets face it .. who needs a Dell laptop anyway ;) I urge everyone else to just do the same (at the very least it may help to eliminate UCE merchants from the world). Cheers Nick -- Leave the Olympics in Greece, where they belong. From joe.abley at icann.org Sat Jul 10 11:40:52 2010 From: joe.abley at icann.org (Joe Abley) Date: Sat, 10 Jul 2010 16:40:52 +0000 Subject: Root Zone DNSSEC Deployment Technical Status Update Message-ID: Root Zone DNSSEC Deployment Technical Status Update 2010-07-10 This is the tenth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at . We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. KSK CEREMONY 2 The second KSK ceremony for the root zone will take place in El Segundo, CA, USA on Monday 2010-07-12. The ceremony is scheduled to begin at 1300 local time (2000 UTC) and is expected to end by 1900 local time (0200 UTC). Video from Ceremony 2 will be recorded for audit purposes, as with Ceremony 1. Video and associated audit materials will be published before the signed root enters full production on 2010-07-15. Details will be circulated before that date. ICANN will operate a separate camera whose video will not be retained for audit purposes, but which will instead be streamed live in order to provide remote observers an opportunity to watch the ceremony. The live stream will be provided on a best-effort basis. The live video stream will be available at: http://dns.icann.org/ksk/stream/ FULL PRODUCTION SIGNED ROOT ZONE The transition from Deliberately-Unvalidatable Root Zone (DURZ) to production signed root zone will take place on 2010-07-15. Trust anchor publication, according to draft-icann-dnssec-trust-anchor-00 will take place after the maintenance window closes, once a final set of tests have been completed by ICANN and the results have been found to be positive. FTP ACCESS TO SIGNED ZONE FILES Following the transition on 2010-07-15 the unsigned root and ARPA zone files published at ftp://rs.internic.net/domain/ ftp://ftp.internic.net/domain/ will be replaced by signed zone files. That is, the zone files retrieved from both FTP servers will contain DNSSEC data, and will hence faithfully represent the zones being served by root servers. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ 2010-06-16: First Key Signing Key (KSK) Ceremony To come: 2010-07-12: Second Key Signing Key (KSK) Ceremony 2010-07-15: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) From netfortius at gmail.com Sun Jul 11 14:35:20 2010 From: netfortius at gmail.com (Stefan) Date: Sun, 11 Jul 2010 14:35:20 -0500 Subject: AT&T issues in NE USA? Message-ID: AT&T large capacity circuits (OC) experiencing problems in NE US?!? This is what AT&T keeps telling us on BGP peering losses over our MPLS in the area. Anybody else?!? ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From tomb at byrneit.net Sun Jul 11 18:31:43 2010 From: tomb at byrneit.net (Tomas L. Byrnes) Date: Sun, 11 Jul 2010 16:31:43 -0700 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <4C3531B0.4010306@zill.net> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <4C3531B0.4010306@zill.net> Message-ID: <72F9A69DCF990443B2CEC064E605CE0608581F@Pascal.zaphodb.org> Because no-one who could do it for less can afford to respond to government contracts, and make sure they comply with all the applicable laws and regulations, and keep the sort of records, and be prepared for the audits of said records, required. As soon as you do business with the govt, the overhead goes through the roof. > -----Original Message----- > From: Patrick Giagnocavo [mailto:patrick at zill.net] > Sent: Wednesday, July 07, 2010 7:02 PM > To: nanog at nanog.org > Subject: Re: U.S. Plans Cyber Shield for Utilities, Companies > > andrew.wallace wrote: > > Article: > > > http://online.wsj.com/article/SB100014240527487045450045753529838504631 > 08.html > > > > Why does it cost $100 million to install and configure OpenBSD on a > bunch of old systems? > > --Patrick From sjk at sleepycatz.com Sun Jul 11 20:37:48 2010 From: sjk at sleepycatz.com (sjk) Date: Sun, 11 Jul 2010 20:37:48 -0500 Subject: U.S. Plans Cyber Shield for Utilities, Companies In-Reply-To: <72F9A69DCF990443B2CEC064E605CE0608581F@Pascal.zaphodb.org> References: <439593.93433.qm@web59615.mail.ac4.yahoo.com> <4C3531B0.4010306@zill.net> <72F9A69DCF990443B2CEC064E605CE0608581F@Pascal.zaphodb.org> Message-ID: <4C3A71EC.6020500@sleepycatz.com> $100M is for the first phase, which I would think would be the initial deployment of intrusions sensors with out of band data feeds, and the building of a baseline traffic model. The real question is why do any critical control networks ever touch anything remotely connected to a public network? Laziness - that's why. Tomas L. Byrnes wrote: > Because no-one who could do it for less can afford to respond to government contracts, and make sure they comply with all the applicable laws and regulations, and keep the sort of records, and be prepared for the audits of said records, required. > > As soon as you do business with the govt, the overhead goes through the roof. > > >> -----Original Message----- >> From: Patrick Giagnocavo [mailto:patrick at zill.net] >> Sent: Wednesday, July 07, 2010 7:02 PM >> To: nanog at nanog.org >> Subject: Re: U.S. Plans Cyber Shield for Utilities, Companies >> >> andrew.wallace wrote: >>> Article: >>> >> http://online.wsj.com/article/SB100014240527487045450045753529838504631 >> 08.html >> Why does it cost $100 million to install and configure OpenBSD on a >> bunch of old systems? >> >> --Patrick > From jay at west.net Sun Jul 11 22:08:55 2010 From: jay at west.net (Jay Hennigan) Date: Sun, 11 Jul 2010 20:08:55 -0700 Subject: [Bruce Hoffman] Thank-you for your recent participation. In-Reply-To: References: <86k4pozfe2.fsf@seastrom.com> <20100627182234.GB24403@gsp.org> <20100707140055.GA11359@gsp.org> Message-ID: <4C3A8747.4090007@west.net> On 7/10/10 7:26 AM, Nick Boyce wrote: > Just my tinfoil-coated 2 cents: > > I tend to assume that when I get an email allegedly from Company A > (Internap) but actually sent by Company/Domain B (iContact), inviting > me to enter all kinds of sensitive information about my organisation's > operations into a "survey" hosted at Domain C (Zoomerang), in return > for which I may win a Dell laptop (but only if I give full > identity-theft-enabling details about myself), then I'm being socially > engineered by a Bad Guy, and I just press "delete". That doesn't alter Company A's behavior, it reinforces it. As there will be others who fall for it, passively hitting delete does nothing to disprove Company A's idea that doing this type of thing is acceptable. "It got some results and nobody complained." That's how spammers work. Rather than JHD (just hit delete) please try to reach out to someone with technical clue at Company A or their upstream. > I do this, even when Company A is a big well-known company (e.g. Sun > ... it's happened) Sun giving away Dell laptops? O RLY? > or an industry magazine (e.g. Secure Computing .. > ditto), cos lets face it .. who needs a Dell laptop anyway ;) I expect this type of crap from magazines. They've been playing fast and loose with their customers' personal data for decades. > I urge everyone else to just do the same (at the very least it may > help to eliminate UCE merchants from the world). Shaming them is IMHO more effective, although it takes more work. -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From popovua27 at meta.ua Mon Jul 12 04:20:35 2010 From: popovua27 at meta.ua (Popov Max) Date: Mon, 12 Jul 2010 12:20:35 +0300 (EEST) Subject: Level3 - have they alive abuse team? Message-ID: <55900.91.118.50.178.1278926435.metamail@webmail.meta.ua> Hello! I am an owner of the small telecom business in Eastern Europe. We have the provider independent network and own autonomous system number. Due to the financial crisis impact, we was off-line for some time. Now it is possible to return to business. But I found our network is already announced by Level3!!! I have dropped them a letter to abuse at level3.com, then got an auto-answer from the robot, after several days have repeat it... Level3 keep silence, and our network is announced now by /24 pieces! What is the good way to push these network hijackers more efficiently? ______________________________ ? ????????? ?????? ?? ???? http://webmail.meta.ua From joelja at bogus.com Mon Jul 12 05:24:55 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 12 Jul 2010 03:24:55 -0700 Subject: Level3 - have they alive abuse team? In-Reply-To: <55900.91.118.50.178.1278926435.metamail@webmail.meta.ua> References: <55900.91.118.50.178.1278926435.metamail@webmail.meta.ua> Message-ID: <4C3AED77.3070908@bogus.com> Specifying the prefix in question is likely to produce more rapid and cogent response. joel On 7/12/10 2:20 AM, Popov Max wrote: > Hello! > > I am an owner of the small telecom business in Eastern Europe. We have the > provider independent network and own autonomous system number. > Due to the financial crisis impact, we was off-line for some time. Now it > is possible to return to business. > > But I found our network is already announced by Level3!!! I have dropped > them a letter to abuse at level3.com, then got an auto-answer from the robot, > after several days have repeat it... Level3 keep silence, and our network > is announced now by /24 pieces! > > What is the good way to push these network hijackers more efficiently? > > ______________________________ > ? ????????? ?????? ?? ???? http://webmail.meta.ua > > From NNewman at nw3c.org Mon Jul 12 07:40:40 2010 From: NNewman at nw3c.org (Nick Newman) Date: Mon, 12 Jul 2010 08:40:40 -0400 Subject: Contact at RNK Communications Message-ID: Anyone have a contact at RNK communications? Off-list replies will be greatly appreciated. Cheers, Nick From scott at sberkman.net Mon Jul 12 09:38:08 2010 From: scott at sberkman.net (Scott Berkman) Date: Mon, 12 Jul 2010 10:38:08 -0400 Subject: Level3 - have they alive abuse team? In-Reply-To: <55900.91.118.50.178.1278926435.metamail@webmail.meta.ua> References: <55900.91.118.50.178.1278926435.metamail@webmail.meta.ua> Message-ID: <037901cb21cf$d8db2ae0$8a9180a0$@net> I'd probably start here: http://puck.nether.net/netops/nocs.cgi?level -Scott -----Original Message----- From: Popov Max [mailto:popovua27 at meta.ua] Sent: Monday, July 12, 2010 5:21 AM To: nanog at nanog.org Subject: Level3 - have they alive abuse team? Hello! I am an owner of the small telecom business in Eastern Europe. We have the provider independent network and own autonomous system number. Due to the financial crisis impact, we was off-line for some time. Now it is possible to return to business. But I found our network is already announced by Level3!!! I have dropped them a letter to abuse at level3.com, then got an auto-answer from the robot, after several days have repeat it... Level3 keep silence, and our network is announced now by /24 pieces! What is the good way to push these network hijackers more efficiently? ______________________________ ? ????????? ?????? ?? ???? http://webmail.meta.ua From stefan at csudsu.com Mon Jul 12 12:47:07 2010 From: stefan at csudsu.com (Stefan Molnar) Date: Mon, 12 Jul 2010 10:47:07 -0700 (PDT) Subject: Stratogent CoLo/DC Info Message-ID: <20100712104457.D83923@clockwork> Anyoneone know anything about Stratogent ( www.stratogent.com )? They look to me as a Internap reseller with SaaS direction. I am being asked to have a meeting with them from one of my VP level guys. Thanks From bill at herrin.us Mon Jul 12 15:38:06 2010 From: bill at herrin.us (William Herrin) Date: Mon, 12 Jul 2010 16:38:06 -0400 Subject: Stratogent CoLo/DC Info In-Reply-To: <20100712104457.D83923@clockwork> References: <20100712104457.D83923@clockwork> Message-ID: On Mon, Jul 12, 2010 at 1:47 PM, Stefan Molnar wrote: > Anyoneone know anything about Stratogent ( www.stratogent.com )? > > They look to me as a Internap reseller with SaaS direction. ?I am being > asked to have a meeting with them from one of my VP level guys. Networking vendors whose web page isn't functional without Flash exhibit a clear level of competence. -- William D. Herrin ................ herrin at dirtside.com bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From joly at punkcast.com Mon Jul 12 16:09:59 2010 From: joly at punkcast.com (Joly MacFie) Date: Mon, 12 Jul 2010 17:09:59 -0400 Subject: Hunter Newby / ISOC-NY Round 2 - Weds 7pm at NYU - poll for questions Message-ID: The Internet Society's New York Chapter (ISOC-NY) held a meeting with Hunter Newby, CEO of Allied Fiber, on Jun 28 2010. This was an interesting and wide ranging roundtable discussion on AF's plans to encircle the entire USA with a dark fiber ring with carrier neutral access at any point. As the meeting was held at short notice, regrettably our two associates with the greatest expertise in such matters Frank Coluccio and NYC Community Fiber's Lou Klepner were not able to be present. After I posted the audio on the ISOC-NY NoticeBoard AF requested that it be taken down pending review - not surprising as the discussion shot off on multiple tangents, mainly on the history of networking. It has now been decided, rather than attempt a coherent edit of 2+ hours of audio, to videotape a follow-up meeting commencing with a more formal presentation. Both Frank and Lou have promised to attend. This meeting will take place on Weds 14 July 2010 at NYU (7pm) ? if interested in attending please RSVP to president at isoc-ny.org What we'd like to do is to get to the nitty gritty of the AF dark fiber model and it's possible application to the communities it is passing, and to ferret out any catches that are being glossed over. Newby has said he's trying to make an emulatable model - the more we can define it, the better for everyone. Hunter Newby has asked that we advise of him of any technical or other detailed questions in advance, to ensure that he has the answers on tap. Read up some background on http://www.telecomramblings.com/2010/06/industry-spotlight-allied-fibers-hunter-newby/ I'd like to get those questions to him by end of day Tuesday. j -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From tme at americafree.tv Mon Jul 12 21:43:44 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 12 Jul 2010 22:43:44 -0400 Subject: Haiti - Bahama Fiber optic Message-ID: <5297E31D-C437-4A30-BB42-4BB9E5EEF59E@americafree.tv> Does anyone know if the BDSNi fiber from Port-au-Prince, Haiti, to the Bahamas has been restored to service after the Earthquake ? Regards Marshall From reygue at htg.ht Tue Jul 13 00:54:33 2010 From: reygue at htg.ht (Reynold Guerrier) Date: Tue, 13 Jul 2010 00:54:33 -0500 Subject: Haiti - Bahama Fiber optic In-Reply-To: <5297E31D-C437-4A30-BB42-4BB9E5EEF59E@americafree.tv> References: <5297E31D-C437-4A30-BB42-4BB9E5EEF59E@americafree.tv> Message-ID: Hello Marshall This cable belonged to TELECO the incumbent state owned company. A new company named NATCOM had taken over TELECO, it has been heard that the landing station has been restored and the cable has been tested but I can't confirm. I'll try to get more information. Regards Reynold On Mon, Jul 12, 2010 at 9:43 PM, Marshall Eubanks wrote: > Does anyone know if the BDSNi fiber from Port-au-Prince, Haiti, to the > Bahamas has been restored to service after the Earthquake ? > > Regards > Marshall > > > > -- =================================== Reynold Guerrier IT Consultant 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From sharef.mustafa at paltel.net Tue Jul 13 01:34:36 2010 From: sharef.mustafa at paltel.net (Sharef Mustafa) Date: Tue, 13 Jul 2010 09:34:36 +0300 Subject: Vyatta as a BRAS Message-ID: Have anyone tried Vyatta router instead of a Cisco 7200 as BRAS for adsl customers? If so, what model? do you recommend it? BR Sharef From rdobbins at arbor.net Tue Jul 13 01:50:59 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 13 Jul 2010 06:50:59 +0000 Subject: Vyatta as a BRAS In-Reply-To: References: Message-ID: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net> On Jul 13, 2010, at 1:34 PM, Sharef Mustafa wrote: > do you recommend it? My comment would be that a software-based BRAS - 7200, Vyatta, et. al. - is no longer viable in today's Internet, and hasn't been for years, due to security/availability concerns. Same for peering/transit edge, customer aggregation edge, et. al. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From truman at suspicious.org Tue Jul 13 01:56:16 2010 From: truman at suspicious.org (Truman Boyes) Date: Tue, 13 Jul 2010 16:56:16 +1000 Subject: Vyatta as a BRAS In-Reply-To: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net> Message-ID: <711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> On 13/07/2010, at 4:50 PM, Dobbins, Roland wrote: > > On Jul 13, 2010, at 1:34 PM, Sharef Mustafa wrote: > >> do you recommend it? > > > My comment would be that a software-based BRAS - 7200, Vyatta, et. al. - is no longer viable in today's Internet, and hasn't been for years, due to security/availability concerns. Same for peering/transit edge, customer aggregation edge, et. al. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken I agree. In a bind I have seen small providers experiment with FreeBSD/Linux L2TP termination (as a LNS), I would recommend against it if you have a business that depends upon these customers' happiness. There were all sorts of issues to address when the customer ran significant traffic forwarding through the unix boxes, namely adjusting kernel parameters for NMB_CLUSTERS, heap sizes, all sorts of sysctl parameters, adding additional interface counts, etc. A low cost 7200 or ERX-310 would easily fit the bill, and you can buy them cheap these days. Cheers, Truman From khatfield at socllc.net Tue Jul 13 03:00:44 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Tue, 13 Jul 2010 08:00:44 +0000 Subject: Vyatta as a BRAS In-Reply-To: <711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net><711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> Message-ID: <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> My comment would be: That is simply matter of opinion and opinions may be swayed depending on the market that signs your check? :) There have been a fair share of appliance bugs/sec vulnerabilities over the years as well. I agree software-based deployments have their flaws but I do not agree that it cannot be managed securely with comparable or exceeding uptime -vs- a drop in appliance. I firmly believe it has it's place in 'today's internet'. The question is where your expertise lies and what you expect to get out of it. If your background is Cisco and you have a good relationship then I wouldn't fix what isn't broken. I have very little experience with Vyatta other than doing some mild testing. I am simply speaking more to the 'software-based' market like Vyatta/BSD. -----Original Message----- From: Truman Boyes Date: Tue, 13 Jul 2010 16:56:16 To: Dobbins, Roland Cc: NANOG list Subject: Re: Vyatta as a BRAS On 13/07/2010, at 4:50 PM, Dobbins, Roland wrote: > > On Jul 13, 2010, at 1:34 PM, Sharef Mustafa wrote: > >> do you recommend it? > > > My comment would be that a software-based BRAS - 7200, Vyatta, et. al. - is no longer viable in today's Internet, and hasn't been for years, due to security/availability concerns. Same for peering/transit edge, customer aggregation edge, et. al. > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken I agree. In a bind I have seen small providers experiment with FreeBSD/Linux L2TP termination (as a LNS), I would recommend against it if you have a business that depends upon these customers' happiness. There were all sorts of issues to address when the customer ran significant traffic forwarding through the unix boxes, namely adjusting kernel parameters for NMB_CLUSTERS, heap sizes, all sorts of sysctl parameters, adding additional interface counts, etc. A low cost 7200 or ERX-310 would easily fit the bill, and you can buy them cheap these days. Cheers, Truman From rdobbins at arbor.net Tue Jul 13 03:53:55 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 13 Jul 2010 08:53:55 +0000 Subject: Vyatta as a BRAS In-Reply-To: <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net><711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> Message-ID: On Jul 13, 2010, at 3:00 PM, wrote: > I agree software-based deployments have their flaws but I do not agree that it cannot be managed securely with comparable or exceeding uptime -vs- a drop in appliance. I firmly believe it has it's place in 'today's internet'. When a single botted/misbehaving host easily can take down a software-based BRAS, that's a pretty strong indication that software-based edge devices are contraindicated, heh. Software-based edge devices have been obsolete for a long time, now. They're a great risk to operators who've yet to replace them with hardware-based devices. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From EricMo at BarrettXplore.com Tue Jul 13 07:13:52 2010 From: EricMo at BarrettXplore.com (Eric Morin) Date: Tue, 13 Jul 2010 09:13:52 -0300 Subject: Route reflector/server appliance for access router aggregation Message-ID: Hi I working on a solution to offload my current internet facing, and soon to be backbone, routers from terminating IBGP sessions from aggregation network routers. I currently have 4948s (pizza box version of the cat4500) in place, mostly bridging traffic, but some routing (OSPF, couple dozen SVIs with HSRP). The 4948s surpasses all solution requirements (I think) except when it comes to scaling the number of BGP sessions to 80-100. The obvious solution is to replace with a much larger platform (ASR1k, etc), which I am consider as an option but capital is the killer. A more economical idea is to pair the 4948s with a route reflector or server. I am looking for recommendations on platforms that I should consider. I have seen the presentation from NANOG48 on open source route server applications (Thanks!), and I am considering a home grown solution, but I want to also consider any other commercial appliances that we can drop in (with some lab work of course) and buy support services on. I looked at a Vyatta appliance (2500 looks good, but single power supply is disappointing). At each PoP I would plan on having two reflectors/servers clustered, each paired with one 4948. I have 7206 NPE-G2s coming out of service in the future that could perhaps be used, but the timing wont work. If anyone has a recommendation on a platform, or general criticism of the idea, please advise. Feedback, positive or negative, is always welcome. Thanks in advance Eric RR Morin From jack at crepinc.com Tue Jul 13 09:06:09 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 13 Jul 2010 10:06:09 -0400 Subject: Route reflector/server appliance for access router aggregation In-Reply-To: References: Message-ID: On the subject of route reflection, I've run into a few people happy with Quaggo or openBGPd on intel hardware. You can throw a 1U box together with dual PSUs, a bunch of ram, and SSD/CF disks for far less than a C or J setup and won't be wasting money on ASICs you aren't using. If I recall correctly this is what Any2 was using when I spoke to them some years ago, but perhaps someone here can offer more specifics. -Jack Carrozzo On Tue, Jul 13, 2010 at 8:13 AM, Eric Morin wrote: > Hi > > I working on a solution to offload my current internet facing, and soon > to be backbone, routers from terminating IBGP sessions from aggregation > network routers. I currently have 4948s (pizza box version of the > cat4500) in place, mostly bridging traffic, but some routing (OSPF, > couple dozen SVIs with HSRP). The 4948s surpasses all solution > requirements (I think) except when it comes to scaling the number of BGP > sessions to 80-100. The obvious solution is to replace with a much > larger platform (ASR1k, etc), which I am consider as an option but > capital is the killer. A more economical idea is to pair the 4948s with > a route reflector or server. I am looking for recommendations on > platforms that I should consider. I have seen the presentation from > NANOG48 on open source route server applications (Thanks!), and I am > considering a home grown solution, but I want to also consider any other > commercial appliances that we can drop in (with some lab work of course) > and buy support services on. I looked at a Vyatta appliance (2500 looks > good, but single power supply is disappointing). At each PoP I would > plan on having two reflectors/servers clustered, each paired with one > 4948. I have 7206 NPE-G2s coming out of service in the future that could > perhaps be used, but the timing wont work. > > > > If anyone has a recommendation on a platform, or general criticism of > the idea, please advise. Feedback, positive or negative, is always > welcome. > > > > > > Thanks in advance > > > > Eric RR Morin > > > > From steve at ipv6canada.com Tue Jul 13 09:40:00 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Tue, 13 Jul 2010 10:40:00 -0400 Subject: Route reflector/server appliance for access router aggregation In-Reply-To: References: Message-ID: <4C3C7AC0.30708@ipv6canada.com> On 2010.07.13 10:06, Jack Carrozzo wrote: > On the subject of route reflection, I've run into a few people happy with > Quaggo or openBGPd on intel hardware. You can throw a 1U box together with > dual PSUs, a bunch of ram, and SSD/CF disks for far less than a C or J setup > and won't be wasting money on ASICs you aren't using. If I recall correctly > this is what Any2 was using when I spoke to them some years ago, but > perhaps someone here can offer more specifics. I use these: http://www.mikrotikrouter.net/ I just toss the Mikrotik CF card aside, and replace it with a USB thumb drive running FreeBSD/Quagga. For upgrades/testing, I just dd one stick to another, and load up the system in a lab box, do my work, and then reload the router with the upgraded, known working stick. Steve From andy at nosignal.org Tue Jul 13 09:45:49 2010 From: andy at nosignal.org (Andy Davidson) Date: Tue, 13 Jul 2010 15:45:49 +0100 Subject: Route reflector/server appliance for access router aggregation In-Reply-To: References: Message-ID: <933E8F82-8591-484B-A29A-7BD323C0EB60@nosignal.org> On 13 Jul 2010, at 15:06, Jack Carrozzo wrote: > On the subject of route reflection, I've run into a few people happy with > Quaggo or openBGPd on intel hardware. You can throw a 1U box together with > dual PSUs, a bunch of ram, and SSD/CF disks for far less than a C or J setup > and won't be wasting money on ASICs you aren't using. If I recall correctly > this is what Any2 was using when I spoke to them some years ago, but > perhaps someone here can offer more specifics. A side note - There is not a total commonality of behaviour/featureset between a reflector service at an IXP, and on a single AS. IXP route-servers tend to be deployed on pc servers, because the C and J units don't have features required[1] for IXP operation (unmodified AS-path, filtering between participants, multiple RIBs for shadow-free filtering.) That's not to say that white-box solutions wont work well on your network. It's easy to make the reflector highly available too - just run multiple reflectors, and build multiple adjacencies on your forwarding routers. Andy [1] Some slides on this topic should you be interested : General explanation : http://www.peering-forum.eu/epf3/presentations/day1/inex-epf-dublin-2008-09-15-01.pdf http://tools.ietf.org/html/draft-jasinska-ix-bgp-route-server-00 Further reading on specific implementations: http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_N48.pdf From cmaurand at xyonet.com Tue Jul 13 10:05:09 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 13 Jul 2010 11:05:09 -0400 Subject: Vyatta as a BRAS In-Reply-To: <711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net> <711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> Message-ID: <4C3C80A5.8030409@xyonet.com> On 7/13/2010 2:56 AM, Truman Boyes wrote: > On 13/07/2010, at 4:50 PM, Dobbins, Roland wrote: > > >> On Jul 13, 2010, at 1:34 PM, Sharef Mustafa wrote: >> >> >>> do you recommend it? >>> >> >> My comment would be that a software-based BRAS - 7200, Vyatta, et. al. - is no longer viable in today's Internet, and hasn't been for years, due to security/availability concerns. Same for peering/transit edge, customer aggregation edge, et. al. >> >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> Injustice is relatively easy to bear; what stings is justice. >> >> -- H.L. Mencken >> > A low cost 7200 or ERX-310 would easily fit the bill, and you can buy them cheap these days. > > Cisco may be a lot of things, but low cost is not one of them. I've been running Vyatta on a small 1U Supermicro Server (cost $600.00) for over one year. It handles all of our VPN traffic and is the main router for our fiber connection. Except for dropping a tunnel every now and then its been flawless. I've set up a cron job to monitor the VPN and restart any tunnel that might drop. No tunnel is ever down for more than a minute. router:~# uptime 11:01:52 up 377 days, 17:22, 1 user, load average: 0.00, 0.00, 0.00 --Curtis From cmaurand at xyonet.com Tue Jul 13 10:07:11 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 13 Jul 2010 11:07:11 -0400 Subject: Vyatta as a BRAS In-Reply-To: References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net><711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> Message-ID: <4C3C811F.4090900@xyonet.com> On 7/13/2010 4:53 AM, Dobbins, Roland wrote: > On Jul 13, 2010, at 3:00 PM, wrote: > > >> I agree software-based deployments have their flaws but I do not agree that it cannot be managed securely with comparable or exceeding uptime -vs- a drop in appliance. I firmly believe it has it's place in 'today's internet'. >> > > When a single botted/misbehaving host easily can take down a software-based BRAS, that's a pretty strong indication that software-based edge devices are contraindicated, heh. > > Software-based edge devices have been obsolete for a long time, now. They're a great risk to operators who've yet to replace them with hardware-based devices. > They are all software based, no matter who builds them. Cisco IOS, Juniper JunOS, etc. --Curtis From Greg.Whynott at oicr.on.ca Tue Jul 13 10:11:57 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Tue, 13 Jul 2010 11:11:57 -0400 Subject: Vyatta as a BRAS In-Reply-To: <4C3C811F.4090900@xyonet.com> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net><711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> Message-ID: >> > > They are all software based, no matter who builds them. Cisco IOS, > Juniper JunOS, etc. controlling hardware asic's and fpga's. -g From dts at senie.com Tue Jul 13 10:22:18 2010 From: dts at senie.com (Daniel Senie) Date: Tue, 13 Jul 2010 11:22:18 -0400 Subject: Vyatta as a BRAS In-Reply-To: References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net><711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> Message-ID: <03250769-E01A-41CB-A2B7-6DB5642D1CE2@senie.com> On Jul 13, 2010, at 11:11 AM, Greg Whynott wrote: >>> >> >> They are all software based, no matter who builds them. Cisco IOS, >> Juniper JunOS, etc. > > controlling hardware asic's and fpga's. Which are in essence software burned into chips. They can provide some acceleration, but will the next faster set of multicore CPUs and related chipsets be faster? This back-and-forth has happened repeatedly over the decades. Even in NIC cards, where there were early cards that offloaded processing from the main computer, but on the next newer main CPU, these "accelerated" cards were now the bottleneck and processing moved back to the host. So it is with routers, ASICs and the like. You should buy a solution because it meets your needs. You should not care about the presence or absence of programmed logic vs. one or more CPUs. You should care about throughput capabilities, latency, packets per second, performance of filtering rules, etc. If the results can be obtained with off the shelf parts and at a fraction of the cost, why do you care whether it was built by someone with a big budget to spin ASICs, or by a company using software in fast, off-the-shelf hardware? Many Cisco products do not have ASICs or FPGAs, but are quite capable as routers. I expect that's true of all the vendors. From lowen at pari.edu Tue Jul 13 10:25:53 2010 From: lowen at pari.edu (Lamar Owen) Date: Tue, 13 Jul 2010 11:25:53 -0400 Subject: Vyatta as a BRAS In-Reply-To: References: Message-ID: <201007131125.54089.lowen@pari.edu> On Tuesday, July 13, 2010 11:11:57 am Greg Whynott wrote: > > They are all software based, no matter who builds them. Cisco IOS, > > Juniper JunOS, etc. > > controlling hardware asic's and fpga's. That run low level software microcode and bitstreams. Sorry, it's software running those ASIC's and FPGA's, even at that level. Verilog and VHDL, while not your ordinary programming languages, blur the line very effectively. From cmaurand at xyonet.com Tue Jul 13 10:30:00 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Tue, 13 Jul 2010 11:30:00 -0400 Subject: Vyatta as a BRAS In-Reply-To: References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net><711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> Message-ID: <4C3C8678.3000905@xyonet.com> On 7/13/2010 11:11 AM, Greg Whynott wrote: >>> >> They are all software based, no matter who builds them. Cisco IOS, >> Juniper JunOS, etc. >> > controlling hardware asic's and fpga's. > In a PIX, its a Pentium 4. I've also been in other routers that use PowerPC. It depends on the manufacturer. Cisco uses its own custom processor when it gets to that level. Its why you have a choice of processor in the 7200's. --Curtis From lowen at pari.edu Tue Jul 13 10:35:00 2010 From: lowen at pari.edu (Lamar Owen) Date: Tue, 13 Jul 2010 11:35:00 -0400 Subject: Vyatta as a BRAS In-Reply-To: References: Message-ID: <201007131135.00574.lowen@pari.edu> On Tuesday, July 13, 2010 04:53:55 am Dobbins, Roland wrote: > When a single botted/misbehaving host easily can take down a software-based BRAS, that's a pretty strong indication that software-based edge devices are contraindicated, heh. I'm assuming you have data on that assertion, right? And can we compare that with a 'hardware' BRAS with a weak control plane CPU? Say, Cisco 7600 with Sup720 and badly configured COPP? > Software-based edge devices have been obsolete for a long time, now. They're a great risk to operators who've yet to replace them with hardware-based devices. Let's run this rabbit. Is there really a true hardware router or BRAS out there? Or are we misusing the term 'hardware-based' to really mean 'hardware accelerated?' Further, is the data plane on hardware accelerated routers really truly hardware-based, or does the firmware, microcode, FPGA bitstreams, and other software do the heavy lifting? And isn't the control plane in a BRAS arguably more critical than the data plane, as it has lots of work to do that requires software running on a general purpose processor to do it? And aren't many 'hardware' routers weak on the control plane side of the house? Which one can be refitted to do IPv6 the quickest, and in the most robust manner? And without requiring a budget-busting (and maybe even bankrupting) expenditure to swap out the whole works (or the majority of the works)? Which one requires the least capex when you yet again overflow your routing tables? Which one is the quickest to get patched when bugs are found? From jgreco at ns.sol.net Tue Jul 13 10:58:36 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 13 Jul 2010 10:58:36 -0500 (CDT) Subject: Vyatta as a BRAS In-Reply-To: <4C3C80A5.8030409@xyonet.com> Message-ID: <201007131558.o6DFwavk096542@aurora.sol.net> > >> My comment would be that a software-based BRAS - 7200, Vyatta, et. > >> al. - is no longer viable in today's Internet, and hasn't been for > >> years, due to security/availability concerns. Same for peering/ > >> transit edge, customer aggregation edge, et. al. > > > > A low cost 7200 or ERX-310 would easily fit the bill, and you can > > buy them cheap these days. ...didn't he just finish saying "not 7200"? > Cisco may be a lot of things, but low cost is not one of them. Agree... > I've been running Vyatta on a small 1U Supermicro Server (cost $600.00) > for over one year. It handles all of our VPN traffic and is the main > router for our fiber connection. Except for dropping a tunnel every now > and then its been flawless. I've set up a cron job to monitor the VPN > and restart any tunnel that might drop. No tunnel is ever down for more > than a minute. This isn't a new issue. Quite frankly, software routers have some very great strengths, and also some large weaknesses. Advocates of hardware based solutions frequently gloss over their own weaknesses. Let's talk plainly here. I'm not going to touch on things like Cisco's software-powered systems, and for purposes of this discussion, let's take "hardware" to mean "hardware-accelerated" solutions that implement forwarding in silicon. That makes a fairly clear delineation between something like a Cisco 7600 and a Vyatta router. So. Hardware router: Insanely great forwarding rates. Software router: Varies substantially based on platform architecture and software competence. Generally speaking, a competent config can run 1Gbps ports without issue, but >=10Gbps gets dicey. Cisco: Everyone learns Cisco's CLI. Anything else: Everyone disses it because it's not Cisco. Even when it's very close to Cisco. Hardware router: Usually a fixed lookup table size - have to have a gameplan to maintain routing table once you exceed it. Software router: Virtually unlimited lookup table size. Hardware router: Expensive custom hardware, good luck and hope you have a service contract in a crisis. Software router: Varying cost hardware; for certain uses, an off-the- shelf server may do. The potential to be able to repurpose a gizmo in a crisis is a bonus. Hardware router: Features are generally costly upgrades. Software router: Might not have all the features you want, but typically most common features are readily available and reliable, usually at no cost. Hardware router: Closed source software. Good luck if your vendor isn't patching your pet bug or security issue. Software router: May be open source software. Inspect/audit for bugs, patch yourself. Might have to hire an expert though. Hardware router: Low competence basic filtering at line rates. Software router: High competence complex filtering, often at less than line rates. Hardware router: May have moving parts. May not. Software router: May have moving parts. May not. It's interesting. One can get equally militant and say that hardware based routers are irrelevant in many applications. I think it depends on the application, and it's usually the specifics of the application and the scale and features needed that's going to be more of a deciding factor. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rdobbins at arbor.net Tue Jul 13 11:15:18 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 13 Jul 2010 16:15:18 +0000 Subject: Vyatta as a BRAS In-Reply-To: <201007131558.o6DFwavk096542@aurora.sol.net> References: <201007131558.o6DFwavk096542@aurora.sol.net> Message-ID: <393F4B4D-01B8-4C13-B0FF-94FE13D78D80@arbor.net> On Jul 13, 2010, at 10:58 PM, Joe Greco wrote: > It's interesting. One can get equally militant and say that hardware based routers are irrelevant in many applications. When BCPs are followed, they don't tend to fall over the moment someone hits them with a few kpps of packets - which should be a key criteria for an edge device. The same can't be said of software-based devices. If maintaining availability is important, then hardware-based (semantic hairsplitting aside) devices are a requirement. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From christianchapman at eircom.net Tue Jul 13 11:31:25 2010 From: christianchapman at eircom.net (Christian Chapman) Date: Tue, 13 Jul 2010 23:31:25 +0700 Subject: Vyatta as a BRAS References: <201007131125.54089.lowen@pari.edu> Message-ID: <000d01cb22a8$d7f9e600$6401a8c0@cisco.com> >> Sorry, it's software running those ASIC's and FPGA's, even at that level Sorry ..Its a clock that runs ASIC's and FPGA's HDL is simply used to describe functionality before synthesis tools translate the design into real hardware (gates and wires) ----- Original Message ----- From: "Lamar Owen" To: Sent: Tuesday, July 13, 2010 10:25 PM Subject: Re: Vyatta as a BRAS > On Tuesday, July 13, 2010 11:11:57 am Greg Whynott wrote: >> > They are all software based, no matter who builds them. Cisco IOS, >> > Juniper JunOS, etc. >> >> controlling hardware asic's and fpga's. > > That run low level software microcode and bitstreams. Sorry, it's > software running those ASIC's and FPGA's, even at that level. Verilog and > VHDL, while not your ordinary programming languages, blur the line very > effectively. > From Valdis.Kletnieks at vt.edu Tue Jul 13 11:59:11 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 13 Jul 2010 12:59:11 -0400 Subject: Vyatta as a BRAS In-Reply-To: Your message of "Tue, 13 Jul 2010 23:31:25 +0700." <000d01cb22a8$d7f9e600$6401a8c0@cisco.com> References: <201007131125.54089.lowen@pari.edu> <000d01cb22a8$d7f9e600$6401a8c0@cisco.com> Message-ID: <156305.1279040351@localhost> On Tue, 13 Jul 2010 23:31:25 +0700, Christian Chapman said: > >> Sorry, it's software running those ASIC's and FPGA's, even at that level > Sorry ..Its a clock that runs ASIC's and FPGA's And how many clockless CPU's have we seen so far? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From surfer at mauigateway.com Tue Jul 13 12:31:34 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Tue, 13 Jul 2010 10:31:34 -0700 Subject: Vyatta as a BRAS Message-ID: <20100713103134.AF88708A@resin07.mta.everyone.net> --- rdobbins at arbor.net wrote: When BCPs are followed, they don't tend to fall over the moment someone hits them with a few kpps of packets - which should be a key criteria for an edge device. ------------------------------------------------------- I'm guessing "a few kpps of packets" is tounge-in-cheek? Entry level script kiddies can get to a few hundred kpps easily. scott From khatfield at socllc.net Tue Jul 13 12:39:32 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Tue, 13 Jul 2010 17:39:32 +0000 Subject: Vyatta as a BRAS In-Reply-To: <393F4B4D-01B8-4C13-B0FF-94FE13D78D80@arbor.net> References: <201007131558.o6DFwavk096542@aurora.sol.net><393F4B4D-01B8-4C13-B0FF-94FE13D78D80@arbor.net> Message-ID: <425285528-1279042773-cardhu_decombobulator_blackberry.rim.net-203286577-@bda903.bisx.prod.on.blackberry> I haven't done real world testing with Vyatta but we consistently pass 750KPPS+ without the slightest hiccup on our FreeBSD routing systems. Correct hardware with the right configuration can make all of the difference. -----Original Message----- From: "Dobbins, Roland" Date: Tue, 13 Jul 2010 16:15:18 To: NANOG list Subject: Re: Vyatta as a BRAS On Jul 13, 2010, at 10:58 PM, Joe Greco wrote: > It's interesting. One can get equally militant and say that hardware based routers are irrelevant in many applications. When BCPs are followed, they don't tend to fall over the moment someone hits them with a few kpps of packets - which should be a key criteria for an edge device. The same can't be said of software-based devices. If maintaining availability is important, then hardware-based (semantic hairsplitting aside) devices are a requirement. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Tue Jul 13 12:56:43 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 13 Jul 2010 17:56:43 +0000 Subject: Vyatta as a BRAS In-Reply-To: <425285528-1279042773-cardhu_decombobulator_blackberry.rim.net-203286577-@bda903.bisx.prod.on.blackberry> References: <201007131558.o6DFwavk096542@aurora.sol.net><393F4B4D-01B8-4C13-B0FF-94FE13D78D80@arbor.net> <425285528-1279042773-cardhu_decombobulator_blackberry.rim.net-203286577-@bda903.bisx.prod.on.blackberry> Message-ID: On Jul 14, 2010, at 12:39 AM, wrote: > I haven't done real world testing with Vyatta but we consistently pass 750KPPS+ without the slightest hiccup on our FreeBSD routing systems. 750kpps packeting the box itself? Also, note that kpps is a small amount of traffic, compared to what even very small botnets can dish out. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Tue Jul 13 12:57:26 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 13 Jul 2010 17:57:26 +0000 Subject: Vyatta as a BRAS In-Reply-To: <20100713103134.AF88708A@resin07.mta.everyone.net> References: <20100713103134.AF88708A@resin07.mta.everyone.net> Message-ID: On Jul 14, 2010, at 12:31 AM, Scott Weeks wrote: > I'm guessing "a few kpps of packets" is tounge-in-cheek? Entry level script kiddies can get to a few hundred kpps easily. That's what I meant - even a very small botnet can easily overwhelm software-based edge routers. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From matthew at matthew.at Tue Jul 13 13:02:46 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Tue, 13 Jul 2010 11:02:46 -0700 Subject: Vyatta as a BRAS In-Reply-To: <201007131558.o6DFwavk096542@aurora.sol.net> References: <201007131558.o6DFwavk096542@aurora.sol.net> Message-ID: <4C3CAA46.2000703@matthew.at> Joe Greco wrote: > > This isn't a new issue. Quite frankly, software routers have some very > great strengths, and also some large weaknesses. > > Advocates of hardware based solutions frequently gloss over their own > weaknesses. > > Let's talk plainly here. > > I'm not going to touch on things like Cisco's software-powered systems, > and for purposes of this discussion, let's take "hardware" to mean > "hardware-accelerated" solutions that implement forwarding in silicon. > That makes a fairly clear delineation between something like a Cisco > 7600 and a Vyatta router. So. > > Hardware router: Insanely great forwarding rates. > Software router: Varies substantially based on platform architecture and > software competence. Generally speaking, a competent config can > run 1Gbps ports without issue, but >=10Gbps gets dicey. ... [remaining good summary removed] > There's really three categories: 1) Devices which make all forwarding decisions and do the forwarding in software 2A) Devices which do forwarding in hardware, but which have a significantly limited forwarding table and punt to software for misses 2B) Devices which do forwarding in hardware, and which have hardware forwarding tables sufficient to hold your whole routing table These then have the following attributes: 1) Can't handle traffic forwarding rates as high as the others, can do complex filtering, often least expensive choice, may scale well with commodity hardware scaling (processor, RAM, interface speeds). Great choice if you operate within their limitations and/or need their flexibility and potential processing complexity. 2A) Can handle higher forwarding rates, often can forward packets using less power-per-bps than systems in category 1, filtering at these rates is limited in capability, tends to scale with improvements in LAN switching technology (these are essentially layer 3 switches). Great in data centers, network edges. Dangerous in places where forwarding table exceeds hardware cache limits. (See Code Red worm stories) 2B) Can handle high forwarding rates, potentially lowest power-per-bps for forwarding if you are operating at sufficient scale, filtering at these rates is limited in capability, scales with investment in these highly specialized devices and the underlying TCAM technology. Great for Internet backbone network routing if you have the money. Expensive. Matthew Kaufman From rdobbins at arbor.net Tue Jul 13 13:11:45 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 13 Jul 2010 18:11:45 +0000 Subject: Vyatta as a BRAS In-Reply-To: <4C3CAA46.2000703@matthew.at> References: <201007131558.o6DFwavk096542@aurora.sol.net> <4C3CAA46.2000703@matthew.at> Message-ID: On Jul 14, 2010, at 1:02 AM, Matthew Kaufman wrote: > Dangerous in places where forwarding table > exceeds hardware cache limits. (See Code Red worm stories) During the Code Red/Nimda period (2001), and on into the Slammer/Blaster/Nachi period (2003), all the routers I personally know of which were adversely affected were software-based, didn't make use of ASICs for forwarding. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From khatfield at socllc.net Tue Jul 13 13:29:52 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Tue, 13 Jul 2010 18:29:52 +0000 Subject: Vyatta as a BRAS Message-ID: <1374765135-1279045793-cardhu_decombobulator_blackberry.rim.net-1570093878-@bda903.bisx.prod.on.blackberry> Routing. We can route that. If it were targeting the box itself it would depend if the attack were getting through. Certainly iptables can't handle something like that but pf does well with high PPS rates. If it were all 'DROP' traffic then likely higher. If it were hitting the box directly and getting past the firewall, yes it would be substantially lower. We were talking about routing though. ------Original Message------ From: Dobbins, Roland To: NANOG list Subject: Re: Vyatta as a BRAS Sent: Jul 13, 2010 12:56 PM On Jul 14, 2010, at 12:39 AM, wrote: > I haven't done real world testing with Vyatta but we consistently pass 750KPPS+ without the slightest hiccup on our FreeBSD routing systems. 750kpps packeting the box itself? Also, note that kpps is a small amount of traffic, compared to what even very small botnets can dish out. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Tue Jul 13 13:37:48 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 13 Jul 2010 18:37:48 +0000 Subject: Vyatta as a BRAS In-Reply-To: <1374765135-1279045793-cardhu_decombobulator_blackberry.rim.net-1570093878-@bda903.bisx.prod.on.blackberry> References: <1374765135-1279045793-cardhu_decombobulator_blackberry.rim.net-1570093878-@bda903.bisx.prod.on.blackberry> Message-ID: <0B5F334A-9492-4402-B43D-30825053FB26@arbor.net> On Jul 14, 2010, at 1:29 AM, wrote: > We were talking about routing though. I was talking about packeting the boxes directly, apologies for being unclear - that's what I meant when I said that the era of software-based edge boxes is long past. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From khatfield at socllc.net Tue Jul 13 14:02:21 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Tue, 13 Jul 2010 19:02:21 +0000 Subject: Vyatta as a BRAS Message-ID: <2017587087-1279047742-cardhu_decombobulator_blackberry.rim.net-210903084-@bda903.bisx.prod.on.blackberry> In that case you are entirely accurate. If you were to use Vyatta (linux-based) systems for this then you would likely need additional infrastructure to firewall or zone it to ensure it can't be hit directly. Depending on what all it has running and the configuration it could be firewalled off locally but you're right it wouldn't withstand like 'hardware-accelerated' as stated before. Sorry for the confusion :) ------Original Message------ From: Dobbins, Roland To: NANOG list Subject: Re: Vyatta as a BRAS Sent: Jul 13, 2010 1:37 PM On Jul 14, 2010, at 1:29 AM, wrote: > We were talking about routing though. I was talking about packeting the boxes directly, apologies for being unclear - that's what I meant when I said that the era of software-based edge boxes is long past. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From nick at foobar.org Tue Jul 13 14:05:21 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 13 Jul 2010 20:05:21 +0100 Subject: Vyatta as a BRAS In-Reply-To: <4C3C811F.4090900@xyonet.com> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net><711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> Message-ID: <4C3CB8F1.6080703@foobar.org> On 13/07/2010 16:07, Curtis Maurand wrote: > On 7/13/2010 4:53 AM, Dobbins, Roland wrote: >> When a single botted/misbehaving host easily can take down a >> software-based BRAS, that's a pretty strong indication that >> software-based edge devices are contraindicated, heh. >> >> Software-based edge devices have been obsolete for a long time, now. >> They're a great risk to operators who've yet to replace them with >> hardware-based devices. >> > > They are all software based, no matter who builds them. Cisco IOS, > Juniper JunOS, etc. I think Roland's point was that on "hardware routers", there is a separation of function between the control and the forwarding planes, and that the forwarding plane is designed to be able to transmit data in an efficient parallel manner. I.e. on a well-designed hardware router, if you trash the data path on the router through ingress A and egress B, the damage stops there: the control plane is unaffected and ingress C to egress D is also ok (for arbitrary values of C and D). Depending on your configuration, this may or may not be important to your IP connectivity requirements. For many - if not most - companies, it is. Nick From tony.li at tony.li Tue Jul 13 15:26:29 2010 From: tony.li at tony.li (Tony Li) Date: Tue, 13 Jul 2010 13:26:29 -0700 Subject: Vyatta as a BRAS In-Reply-To: <4C3CB8F1.6080703@foobar.org> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net><711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> <4C3CB8F1.6080703@foobar.org> Message-ID: <7D84DDA7-1ACD-42D4-94B8-F0E95165731F@tony.li> Hi folks, On Jul 13, 2010, at 12:05 PM, Nick Hilliard wrote: > I think Roland's point was that on "hardware routers", there is a > separation of function between the control and the forwarding planes, and > that the forwarding plane is designed to be able to transmit data in an > efficient parallel manner. I.e. on a well-designed hardware router, if you > trash the data path on the router through ingress A and egress B, the > damage stops there: the control plane is unaffected and ingress C to egress > D is also ok (for arbitrary values of C and D). The key point here is one of design, not one of implementation technology. If you need a router that is robust against DoS attacks, then that's what you should buy. Such routers can be built from ASICs, CPUs, or even 7400 series TTL, if you work hard enough at it. There is no meaningful distinction of 'hardware' or 'software'. All of the ASIC based systems embody processors of various flavors in the ASICs that are running forwarding software. And the difference between an ASIC and a CPU is not as much as you might think. Ok, ASICs typically don't go to full custom layout (tho some crazy people have done that) and are typically a few steps behind on the process technology curve. But this is not the fundamental issue. The whole point about being DoS resistant is one of horsepower. To do DoS protection correctly, you need to be able to do packet examination at line rate. When there are packets destined for the router, they need to be classified appropriately, queued carefully and those queues need to be serviced in The Right Way (tm). If your system has the performance to do this in addition to the normal transit load on the system, then it's in pretty good shape. Regards, Tony From Valdis.Kletnieks at vt.edu Tue Jul 13 16:03:34 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 13 Jul 2010 17:03:34 -0400 Subject: Vyatta as a BRAS In-Reply-To: Your message of "Tue, 13 Jul 2010 18:11:45 -0000." References: <201007131558.o6DFwavk096542@aurora.sol.net> <4C3CAA46.2000703@matthew.at> Message-ID: <180177.1279055014@localhost> On Tue, 13 Jul 2010 18:11:45 -0000, "Dobbins, Roland" said: > During the Code Red/Nimda period (2001), and on into the Slammer/Blaster/Nachi > period (2003), all the routers I personally know of which were adversely > affected were software-based, didn't make use of ASICs for forwarding. Cisco 7206VXF apparently had some issues dealing with it: https://puck.nether.net/pipermail/cisco-nsp/2003-September/005578.html Slammer's use of multicast addresses melted down at least a few large Cisco and Juniper boxes: http://paintsquirrel.ucs.indiana.edu/pdf/SLAMMER.pdf I wasn't aware that the 7206 and M20 classified as software-based. (cue weasel-words about those routers using ASICs for most forwarding, but doing multicast forwarding in software in 5.. 4.. 3..) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From lowen at pari.edu Tue Jul 13 16:05:12 2010 From: lowen at pari.edu (Lamar Owen) Date: Tue, 13 Jul 2010 17:05:12 -0400 Subject: Vyatta as a BRAS In-Reply-To: <2017587087-1279047742-cardhu_decombobulator_blackberry.rim.net-210903084-@bda903.bisx.prod.on.blackberry> References: <2017587087-1279047742-cardhu_decombobulator_blackberry.rim.net-210903084-@bda903.bisx.prod.on.blackberry> Message-ID: <201007131705.13082.lowen@pari.edu> On Tuesday, July 13, 2010 03:02:21 pm khatfield at socllc.net wrote: > In that case you are entirely accurate. If you were to use Vyatta (linux-based) systems for this then you would likely need additional infrastructure to firewall or zone it to ensure it can't be hit directly. Much like COPP for the Sup720 control plane, no? Tarpit is your friend. From thegameiam at yahoo.com Tue Jul 13 16:13:47 2010 From: thegameiam at yahoo.com (David Barak) Date: Tue, 13 Jul 2010 14:13:47 -0700 (PDT) Subject: Vyatta as a BRAS In-Reply-To: <180177.1279055014@localhost> Message-ID: <200110.29279.qm@web31813.mail.mud.yahoo.com> --- On Tue, 7/13/10, Valdis.Kletnieks at vt.edu wrote: > I wasn't aware that the 7206 and M20 classified as > software-based. > No weasel words necessary. I won't speak for the M20, but I've always thought of the 7206 as a software-routing platform - it's a pretty good swiss-army-knife software router which supports limited hardware acceleration of specific functions. Is there anyone who considers the 7206 a "hardware" router? David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com From robert at gdk.org Tue Jul 13 17:08:30 2010 From: robert at gdk.org (Robert Bays) Date: Tue, 13 Jul 2010 15:08:30 -0700 Subject: Vyatta as a BRAS In-Reply-To: References: <201007131558.o6DFwavk096542@aurora.sol.net><393F4B4D-01B8-4C13-B0FF-94FE13D78D80@arbor.net> <425285528-1279042773-cardhu_decombobulator_blackberry.rim.net-203286577-@bda903.bisx.prod.on.blackberry> Message-ID: <4C3CE3DE.1010101@gdk.org> On 7/13/10 10:56 AM, Dobbins, Roland wrote: > > On Jul 14, 2010, at 12:39 AM, > wrote: > >> I haven't done real world testing with Vyatta but we consistently >> pass 750KPPS+ without the slightest hiccup on our FreeBSD routing >> systems. > > 750kpps packeting the box itself? > > Also, note that kpps is a small amount of traffic, compared to what > even very small botnets can dish out. I work for Vyatta. We regularly see 700+kpps per core using a Nehalem class cpu with higher rates possible in tuned systems. On a multi-core system this translates to a fairly high level of throughput. To echo an earlier post, Linux can comfortably handle gigabit. It wasn't too long ago that this wasn't the case. The growth in the number of cores available to the end user, the introduction of multi-queue nics, the move away from the FSB architecture towards QPI, ever faster PCIe... The technology is directionally trending towards faster, more consistent network throughputs whether your Linux host is acting as a router, firewall, web server, or whatever. There are activities taking place on the software front as well to increase speed and consistency in the realms of forwarding and firewall, including technologies that separate the control and forwarding planes. There is still headroom available in commodity compute to scale further. I will be the first to admit that Vyatta won't work for everyone. We still have a lot of work to do for our system to fit seamlessly in some environments. But, the bet that we have made is that commodity compute coupled with the amazing OSS dev community can keep pace with a good portion of the networking worlds needs. So far, that bet looks like a good one. To discount all software routing running on general purpose processors as being antiquated seems to me to be premature, especially given the various vendors interests as more functionality migrates into the cloud. As that happens commodity components in the cloud fabric will necessarily need to behave more like network appliances. Cheers, Robert. From franck at genius.com Tue Jul 13 17:16:53 2010 From: franck at genius.com (Franck Martin) Date: Wed, 14 Jul 2010 10:16:53 +1200 (FJT) Subject: Vyatta as a BRAS In-Reply-To: <4C3CE3DE.1010101@gdk.org> Message-ID: <27024896.1376.1279059412169.JavaMail.franck@franck-martins-macbook-pro.local> I think the issue, is that don't expect to build your own router using linux/bsd etc.. There are too many kernel parameters to tweak to make it optimal (unless a suboptimal router is ok with your environment) You need people that understand network and the appliance they sell you. Why Cisco is reliable (and expensive), because they give you that experience... Software based router can give you that experience if they are backed by a team that know what they are doing. ----- Original Message ----- From: "Robert Bays" To: nanog at nanog.org Sent: Wednesday, 14 July, 2010 10:08:30 AM Subject: Re: Vyatta as a BRAS On 7/13/10 10:56 AM, Dobbins, Roland wrote: > > On Jul 14, 2010, at 12:39 AM, > wrote: > >> I haven't done real world testing with Vyatta but we consistently >> pass 750KPPS+ without the slightest hiccup on our FreeBSD routing >> systems. > > 750kpps packeting the box itself? > > Also, note that kpps is a small amount of traffic, compared to what > even very small botnets can dish out. I work for Vyatta. We regularly see 700+kpps per core using a Nehalem class cpu with higher rates possible in tuned systems. On a multi-core system this translates to a fairly high level of throughput. To echo an earlier post, Linux can comfortably handle gigabit. It wasn't too long ago that this wasn't the case. The growth in the number of cores available to the end user, the introduction of multi-queue nics, the move away from the FSB architecture towards QPI, ever faster PCIe... The technology is directionally trending towards faster, more consistent network throughputs whether your Linux host is acting as a router, firewall, web server, or whatever. There are activities taking place on the software front as well to increase speed and consistency in the realms of forwarding and firewall, including technologies that separate the control and forwarding planes. There is still headroom available in commodity compute to scale further. I will be the first to admit that Vyatta won't work for everyone. We still have a lot of work to do for our system to fit seamlessly in some environments. But, the bet that we have made is that commodity compute coupled with the amazing OSS dev community can keep pace with a good portion of the networking worlds needs. So far, that bet looks like a good one. To discount all software routing running on general purpose processors as being antiquated seems to me to be premature, especially given the various vendors interests as more functionality migrates into the cloud. As that happens commodity components in the cloud fabric will necessarily need to behave more like network appliances. Cheers, Robert. From lowen at pari.edu Tue Jul 13 17:29:15 2010 From: lowen at pari.edu (Lamar Owen) Date: Tue, 13 Jul 2010 18:29:15 -0400 Subject: Vyatta as a BRAS In-Reply-To: <000d01cb22a8$d7f9e600$6401a8c0@cisco.com> References: Message-ID: <201007131829.15988.lowen@pari.edu> On Tuesday, July 13, 2010 12:31:25 pm Christian Chapman wrote: > >> Sorry, it's software running those ASIC's and FPGA's, even at that level > Sorry ..Its a clock that runs ASIC's and FPGA's > HDL is simply used to describe functionality before synthesis tools > translate the design into real hardware (gates and wires) I missed an 'on' in my sentence; should have read '...software running ON those ASIC's and FPGA's....' My apologies for the error, which completely changed the meaning of my statement. A perusal of Cisco's own documentation for one of their 'hardware' forwarding engines, the PXF used in the 10k edge services router and others, shows that even with the Toaster ASIC (looking at a pair right now on an older PRE1 for uBR10K) and its associated memory, you have something running its own software doing the work. Cisco's own documentation describes PXF in these words: "Each of the coprocessors in a PXF network processor is an independent, high-performance processor, customized for packet processing. Each processor, called an Express Micro Controller (XMC), provides a sophisticated dual-instruction-issue execution unit, with a variety of special instructions designed to execute packet-processing tasks efficiently." Instruction issue? Execution unit? Special instructions? Sounds like a software-driven processor to me. Specialized software instruction set, yes. True hardware forwarding, no software involvement? No. More like asymmetrical multiprocessing software routing. Call it hardware accelerated if you like; PXF is to networking as a nVidia GeForce GPU is to graphics. Now, if we're talking directed attacks at the control plane.... well, COPP exists for a reason in Cisco-land. Tarpits and other techniques (too bad nVidia's ActiveArmor firewall inside their nForce chipset's NIC's is so broken), including transparent layer 2 stateful inspection firewalling (easily doable with Linux iptables and bridging), can do the same for a single-core router. Now to, as Emeril would say, kick it up a notch, you're going to have a very hard time DoS'ing twenty-four Phenom II cores (four sockets, six cores per socket), though (which will likely set you back less than a midrange Cisco router). I could see Vyatta on 24 Phenom II cores having blistering and nearly DoS-proof performance, for about what accelerated forwarding platforms cost. When the developers of software forwarding engines figure out how to leverage vector processing (SSE and similar, as well as nVidia's CUDA) to do packet forwarding, we're going to see commodity OS network routing performance hit another level. But specialized network processors don't always guarantee the great scalability that can be obtained with the technique. Catalyst 8540 anyone? (I have several, and use a few in production; great boxes for raw IPv4 routing, but not at the edge, although in theory they should have been DoS-proof, since they're already switching worst-case packet sizes on the shared memory fabric at wire speed; their control plane was their weakest link). Dedicated network coprocessors can be a good thing, but they're still software-based (even in the Catalyst 8540's case). From jgreco at ns.sol.net Tue Jul 13 17:45:11 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 13 Jul 2010 17:45:11 -0500 (CDT) Subject: Vyatta as a BRAS In-Reply-To: <393F4B4D-01B8-4C13-B0FF-94FE13D78D80@arbor.net> Message-ID: <201007132245.o6DMjBJO001553@aurora.sol.net> > On Jul 13, 2010, at 10:58 PM, Joe Greco wrote: > > It's interesting. One can get equally militant and say that hardware bas= > ed routers are irrelevant in many applications.=20 > > When BCPs are followed, they don't tend to fall over the moment someone hit= > s them with a few kpps of packets - which should be a key criteria for an e= > dge device. > > The same can't be said of software-based devices. That's just a completely ignorant statement to make. I notice in particular how carefully you qualify that with "[w]hen BCPs are followed"; the fact that hardware router manufacturers have declared everything and anything that derails their bullet trains as "not a BCP" is a perfect example of this deceptive sort of misinformation. There are plenty of FreeBSD based devices out there that are passing tons of traffic; almost any of them are more competent than any Cisco router I'm aware of when hitting them directly with traffic, since the CPU's on your average Cisco are pretty flimsy, the CPU on a FreeBSD box is going to be fairly current tech, and the code on a FreeBSD box is going to have been designed to defend against such attacks because things like IRC server operators often don't have the luxury of hiding their device management on a protected net. The fact of the matter is that the way that most "hardware" platforms try to survive a DoS attack against their control plane is through hardware filtering; to the extent that that works, it's going to be pretty effective. However, if we're going to allow for that, then we have to allow the software platform to defend itself with a firewall as well, and once you do that, on both platforms, what actually happens in the end is that both devices can successfully defend at gigabit speeds, but you start losing traffic because you're filling the inbound pipe. Or, put another way: "When BCP's are followed, software devices don't tend to fall over the moment someone hits them with a few Mpps of packets either." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rdobbins at arbor.net Tue Jul 13 21:18:18 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 02:18:18 +0000 Subject: Vyatta as a BRAS In-Reply-To: <7D84DDA7-1ACD-42D4-94B8-F0E95165731F@tony.li> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net><711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> <4C3CB8F1.6080703@foobar.org> <7D84DDA7-1ACD-42D4-94B8-F0E95165731F@tony.li> Message-ID: On Jul 14, 2010, at 3:26 AM, Tony Li wrote: > The whole point about being DoS resistant is one of horsepower. To do DoS protection correctly, you need to be able to do packet examination at line rate. Right. And to date, such routers make use of ASICs - i.e., 'hardware-based' routers, in the vernacular. Routers which use only centralized, general-purpose processors can't handle even a fraction of 'line-rate' without tanking, as innumerable real-world examples of said behavior over the years have repeatedly and conclusively demonstrated. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Tue Jul 13 21:27:02 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 02:27:02 +0000 Subject: Vyatta as a BRAS In-Reply-To: <180177.1279055014@localhost> References: <201007131558.o6DFwavk096542@aurora.sol.net> <4C3CAA46.2000703@matthew.at> <180177.1279055014@localhost> Message-ID: On Jul 14, 2010, at 4:03 AM, wrote: > I wasn't aware that the 7206 and M20 classified as software-based. 7200 certainly is - I'm not familiar with the minutiae of Juniper boxes, but I believe the M20 is hardware-based. In the classic report you cite, the issue with the M20 occurred due to lack of BCP implementation. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From dwhite at olp.net Tue Jul 13 21:31:29 2010 From: dwhite at olp.net (Dan White) Date: Tue, 13 Jul 2010 21:31:29 -0500 Subject: Vyatta as a BRAS In-Reply-To: References: <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> <4C3CB8F1.6080703@foobar.org> <7D84DDA7-1ACD-42D4-94B8-F0E95165731F@tony.li> Message-ID: <20100714023129.GC2527@dan.olp.net> On 14/07/10?02:18?+0000, Dobbins, Roland wrote: > >On Jul 14, 2010, at 3:26 AM, Tony Li wrote: > >> The whole point about being DoS resistant is one of horsepower. To do >> DoS protection correctly, you need to be able to do packet examination >> at line rate. > >Right. And to date, such routers make use of ASICs - i.e., >'hardware-based' routers, in the vernacular. > >Routers which use only centralized, general-purpose processors can't >handle even a fraction of 'line-rate' without tanking, as innumerable >real-world examples of said behavior over the years have repeatedly and >conclusively demonstrated. I'm not really all that opinionated on the subject, other than to say that the definition of a router, and what qualifies as a sufficient router for any given administrator's needs, greatly varies. However, to state something like > as innumerable real-world examples of said behavior over the years have > repeatedly and conclusively demonstrated. has the appearance of you struggling to hold on to an idea that may have been more true in the past, and less true today, as is evident based on the input from other list participants. -- Dan White From rdobbins at arbor.net Tue Jul 13 21:36:28 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 02:36:28 +0000 Subject: Vyatta as a BRAS In-Reply-To: <201007132245.o6DMjBJO001553@aurora.sol.net> References: <201007132245.o6DMjBJO001553@aurora.sol.net> Message-ID: <37927AEC-676C-4D2A-BD4B-0B6A067AA1B5@arbor.net> On Jul 14, 2010, at 5:45 AM, Joe Greco wrote: > That's just a completely ignorant statement to make. It's based on a great deal of real-world experience; I'm sorry you consider that to be 'ignorant'. > I notice in particular how carefully you qualify that with "[w]hen BCPs are > followed"; the fact that hardware router manufacturers have declared > everything and anything that derails their bullet trains as "not a > BCP" is a perfect example of this deceptive sort of misinformation. Anti-spoofing, iACLs, CoPP (or its equivalent on non-Cisco platforms), et. al. aren't 'misinformation'. They're useful, proven techniques/features which any operator ought to implement. > There are plenty of FreeBSD based devices out there that are passing > tons of traffic; almost any of them are more competent than any Cisco > router I'm aware of when hitting them directly with traffic Then your experience of Cisco routers (and/or those from other vendors) must be limited to the lower-end platforms; I can assure you that faster Cisco boxes such as ASRs, GSRs, CRSes, and so forth are in another league entirely, and can handle mpps of to-us traffic, when properly configured. Software-based routers simply can't do that; it's not an indictment of them, it's just that they aren't suited to purpose, just as station wagons generally aren't to be found in the Indy 500. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Tue Jul 13 21:50:13 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 02:50:13 +0000 Subject: Vyatta as a BRAS In-Reply-To: <20100714023129.GC2527@dan.olp.net> References: <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> <4C3CB8F1.6080703@foobar.org> <7D84DDA7-1ACD-42D4-94B8-F0E95165731F@tony.li> <20100714023129.GC2527@dan.olp.net> Message-ID: On Jul 14, 2010, at 9:31 AM, Dan White wrote: > has the appearance of you struggling to hold on to an idea that may have been more true in the past, It's true today, and I'm not 'struggling to hold' onto anything. Take any software-based router from Cisco or Juniper or whomever (if Juniper still make software-based routers, I don't know if they do or not), packet it until it falls over, then repeat the process with a properly-configured hardware-based router from the same manufacturer - you can demonstrate the validity of the proposition for yourself, as the hardware-based router can handle considerably more traffic, whereas the software-based router will pitch over as a result of a surprisingly small amount of traffic. > and less true today, as is evident based on the input from other list participants. Input based upon experience which is seemingly heavily weighted towards the lower end, rather than the higher end, of network speeds and routing platforms - and which doesn't seem to encompass much examination of the ability of said lower-end devices to maintain availability in the face of direct attack. It can be quite interesting to take a packet-generator to a software-based router and see just how easy it is to make it fall over, and then repeat the experience with a hardware-based router, and consider the implications thereof, even at relatively low bandwidth/throughput. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From yamu at ciklum.net Wed Jul 14 01:13:31 2010 From: yamu at ciklum.net (Yasir Munir Abbasi) Date: Wed, 14 Jul 2010 06:13:31 +0000 Subject: Receive Digest Message-ID: <261E17F810EEC548ACD322ED2E847CE3095C66@exten02.kyiv.ciklum.net> Dear, I always receive digest with volume number, where number of email correspondence shown. That is very grim for reading. Is there any possibility I can receive individual email correspondence. Thanks Yasir Munir Abbasi Senior Network Engineer Ciklum Pakistan 2nd floor, Software Technology Park II, Evacuee Trust Plaza F-5/1, Islamabad Tel + 92 51 2826114 Fax +92 51 2870756 Mob +92 333 5605512 EMail: yamu at ciklum.net From swmike at swm.pp.se Wed Jul 14 01:34:45 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 14 Jul 2010 08:34:45 +0200 (CEST) Subject: Vyatta as a BRAS In-Reply-To: <201007131829.15988.lowen@pari.edu> References: <201007131829.15988.lowen@pari.edu> Message-ID: On Tue, 13 Jul 2010, Lamar Owen wrote: > Instruction issue? Execution unit? Special instructions? Sounds like > a software-driven processor to me. Specialized software instruction > set, yes. True hardware forwarding, no software involvement? No. > More like asymmetrical multiprocessing software routing. Call it > hardware accelerated if you like; PXF is to networking as a nVidia > GeForce GPU is to graphics. This is true on a lot of newer Cisco high end platforms. CRS-1 uses multicore processors (hundreds of cores) for forwarding on their linecards, and they achieve 40+ Mpps per linecard. This is the trend in networking where you need to do intelligent things, it's easier to do multicore parallell processing than doing hugely fast FPGA forwarding (at least it seems that way, and it's faster to upgrade the software on a CPU than on a FPGA). The lines are blurring between CPU/FPA/ASIC (well, ASIC is really a misnomer as it's just "application specific" which means packaging, not function) and since people want flexibility, general CPUs used for forwarding is the way it's headed, even though the CPUs right now have little to do with the CPUs we see in "normal" PCs. -- Mikael Abrahamsson email: swmike at swm.pp.se From rdobbins at arbor.net Wed Jul 14 02:24:49 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 07:24:49 +0000 Subject: Vyatta as a BRAS In-Reply-To: References: <201007131829.15988.lowen@pari.edu> Message-ID: <118DC950-0AC0-48D1-93E5-F8E350817E73@arbor.net> On Jul 14, 2010, at 1:34 PM, Mikael Abrahamsson wrote: > CRS-1 uses multicore processors (hundreds of cores) for forwarding on their linecards, and they achieve 40+ Mpps per linecard. The CRS-1 makes use of the Metro subsystem for forwarding, with multiple Metros per Modular Service Card (MSC). Each Metro complex (there are two per MSC) consists of the Metro chip itself, an NPU which contains 188 embedded RISC cores; two TCAM banks; SRAM; and FCRAM. There's also a gatekeeper ASIC of some sort on the MSC which handles traffic incoming from the fabric, as well as another interface module ASIC on the Physical Layer Interface Module (PLIM). I believe the CRS-3-specific MSCs each contain two QFAP complexes, which allow for 140gb/sec per linecard, and that there are various additional supporting ASICs on the MSCs and the PLIMs, as well. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From lists at xodus.org Wed Jul 14 06:53:17 2010 From: lists at xodus.org (Marc Powell) Date: Wed, 14 Jul 2010 06:53:17 -0500 Subject: Receive Digest In-Reply-To: <261E17F810EEC548ACD322ED2E847CE3095C66@exten02.kyiv.ciklum.net> References: <261E17F810EEC548ACD322ED2E847CE3095C66@exten02.kyiv.ciklum.net> Message-ID: On Jul 14, 2010, at 1:13 AM, Yasir Munir Abbasi wrote: > Dear, > > I always receive digest with volume number, where number of email correspondence shown. That is very grim for reading. Is there any possibility I can receive individual email correspondence. Thanks Standard mailman. Go to https://mailman.nanog.org/mailman/listinfo/nanog. Log in at the 'NANOG Subscribers' section and change your delivery option. -- Marc From Valdis.Kletnieks at vt.edu Wed Jul 14 07:01:56 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 14 Jul 2010 08:01:56 -0400 Subject: Vyatta as a BRAS In-Reply-To: Your message of "Wed, 14 Jul 2010 02:18:18 -0000." References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net> <711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> <4C3CB8F1.6080703@foobar.org> <7D84DDA7-1ACD-42D4-94B8-F0E95165731F@tony.li> Message-ID: <238090.1279108916@localhost> On Wed, 14 Jul 2010 02:18:18 -0000, "Dobbins, Roland" said: > Right. And to date, such routers make use of ASICs - i.e., 'hardware-based' > routers, in the vernacular. > > Routers which use only centralized, general-purpose processors can't handle > even a fraction of 'line-rate' without tanking But as others have stated, the 7206 has at least some hardware acceleration, so it's *not* a router that uses *only* centralized general-purpose CPUs. So at least some hardware-assisted routers tank under loads too. And even the most heavily hardware-assisted systems have to do call outs from the FPGA's for *some* stuff, and can be tanked by suitably creative abuse of their weaknesses. Of course, in general the more hardware assist, the harder it is to tank (but it's never impossible). So basically, your definition of "hardware based" router is "one that has enough FPGAs to not tank under some arbitrary workload". Not very useful,that. Let's face it Roland - it's a continuum from hardware to software, and in many places it's downright murky which it is. Is the CRS-1 hardware or software? Lots of custom hardware in there - but lots of processing cores that look suspiciously like software engines too. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From yamu at ciklum.net Wed Jul 14 07:10:58 2010 From: yamu at ciklum.net (Yasir Munir Abbasi) Date: Wed, 14 Jul 2010 12:10:58 +0000 Subject: Receive Digest In-Reply-To: References: <261E17F810EEC548ACD322ED2E847CE3095C66@exten02.kyiv.ciklum.net> Message-ID: <261E17F810EEC548ACD322ED2E847CE3095E52@exten02.kyiv.ciklum.net> I got it. Thanks you to all... Yasir Munir Abbasi Senior Network Engineer Ciklum Pakistan 2nd floor, Software Technology Park II, Evacuee Trust Plaza F-5/1, Islamabad Tel? +?92 51 2826114 Fax +92?51 2870756 Mob +92 333 5605512 EMail: yamu at ciklum.net -----Original Message----- From: Marc Powell [mailto:lists at xodus.org] Sent: Wednesday, July 14, 2010 4:53 PM To: nanog at nanog.org Subject: Re: Receive Digest On Jul 14, 2010, at 1:13 AM, Yasir Munir Abbasi wrote: > Dear, > > I always receive digest with volume number, where number of email correspondence shown. That is very grim for reading. Is there any possibility I can receive individual email correspondence. Thanks Standard mailman. Go to https://mailman.nanog.org/mailman/listinfo/nanog. Log in at the 'NANOG Subscribers' section and change your delivery option. -- Marc From rdobbins at arbor.net Wed Jul 14 07:39:50 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 12:39:50 +0000 Subject: Vyatta as a BRAS In-Reply-To: <238090.1279108916@localhost> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net> <711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> <4C3CB8F1.6080703@foobar.org> <7D84DDA7-1ACD-42D4-94B8-F0E95165731F@tony.li> <238090.1279108916@localhost> Message-ID: <0428DEB0-B24B-4E32-890F-0ADEE5F7B954@arbor.net> On Jul 14, 2010, at 7:01 PM, wrote: > But as others have stated, the 7206 has at least some hardware acceleration, Unfortunately, said statements are factually incorrect. 7200s have no hardware acceleration of any type whatsoever. from : 'Processor 1.67-GHz Motorola Freescale 7448 processor' > so it's *not* a router that uses *only* centralized general-purpose CPUs. Actually, it is. Same with ISRs. from Note the 'Multicore Processor' line-item - singular. The SREs for the ISR2s do each contain their own Intel x86 processor - so, the ISR2 models which can take SREs are distributed platforms, but aren't hardware-based in the sense that they contain high-performance forwarding chips. The processors in the SREs are used to run applications on-board the router itself - so, they're kind of like special-purpose servers on a card, rather than high-performance linecards as one finds in higher-end platforms. > So basically, your definition of "hardware based" router is "one that has enough > FPGAs to not tank under some arbitrary workload". Not very useful,that. It's extremely useful to differentiate routers which have special-purpose forwarding hardware from those which don't, as the latter crumble quite quickly when packeted. If you don't believe me, run some tests of your own with purely software-based routers, such as 7200s, and then with a hardware-based router such as an ASR1K, ASR9K, GSR, CRS-1, N7K, what-have-you. I've seen this divergent behavior between software-based and hardware-based platforms time and time again in real, live production networks, during real, live attacks. It isn't something which can simply be dismissed by semantic hairsplitting. And it's not *my* definition - 'hardware-based' vs. 'software-based' are the terms to describe these two fundamental architectural classes of router *within Cisco itself*. > Let's face it Roland - it's a continuum from hardware to software, and in many > places it's downright murky which it is. Is the CRS-1 hardware or software? Hardware, obviously - it has special-purpose NPUs on the linecards, along with special-purpose ASICs, and TCAMs. > Lots of custom hardware in there - but lots of processing cores that look suspiciously like software engines too. There's a world of difference in packet-handling mechanisms and sheer performance between a 7200 and a CRS-1, or a GSR, or a CRS-3, or Juniper T-series - and not just one of 'more, faster processors', but of fundamental architecture. This is why 'hardware-based' vs. 'software-based' is a useful distinction; again, note that within Cisco, these are the common terms used to describe these general classes of device, with 7200s and ISRs being termed 'software-based', and the other models mentioned above described as 'hardware-based'. Anyway, enough on this topic. If folks wish to continue to deploy software-based routers at the edges of their networks, then they oughtn't to be surprised or dismayed when said software-based routers fall over under relatively small amounts of packeting, either deliberate attacks or as the result of misconfiguration, et. al. If, on the other hand, they prize availability, then investing in hardware-based platforms and then configuring said hardware-based routers with the appropriate BCPs greatly reduces the risk of such an occurrence. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From fweimer at bfk.de Wed Jul 14 08:38:35 2010 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 14 Jul 2010 13:38:35 +0000 Subject: Vyatta as a BRAS In-Reply-To: <180177.1279055014@localhost> (Valdis Kletnieks's message of "Tue\, 13 Jul 2010 17\:03\:34 -0400") References: <201007131558.o6DFwavk096542@aurora.sol.net> <4C3CAA46.2000703@matthew.at> <180177.1279055014@localhost> Message-ID: <82lj9enpyc.fsf@mid.bfk.de> * Valdis Kletnieks: > (cue weasel-words about those routers using ASICs for most forwarding, but > doing multicast forwarding in software in 5.. 4.. 3..) There's also the question of IP options (or extension headers). 8-) -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From rdobbins at arbor.net Wed Jul 14 08:43:34 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 13:43:34 +0000 Subject: Vyatta as a BRAS In-Reply-To: <82lj9enpyc.fsf@mid.bfk.de> References: <201007131558.o6DFwavk096542@aurora.sol.net> <4C3CAA46.2000703@matthew.at> <180177.1279055014@localhost> <82lj9enpyc.fsf@mid.bfk.de> Message-ID: <3B8F01CE-9F9F-4235-A82C-946B0A5475C3@arbor.net> On Jul 14, 2010, at 8:38 PM, Florian Weimer wrote: > There's also the question of IP options (or extension headers). 8-) I know that some modern hardware-based routers have the ability to either ignore options, or to drop option packets altogether. I believe the same is now true of IPv6 extension-headere, or soon will be. You're absolutely correct that this is a significant possible attack vector, causing the packets in question to be punted, if there isn't a mechanism available to ignore them or to drop said packets. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From fweimer at bfk.de Wed Jul 14 08:48:29 2010 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 14 Jul 2010 13:48:29 +0000 Subject: Vyatta as a BRAS In-Reply-To: (Roland Dobbins's message of "Tue\, 13 Jul 2010 17\:57\:26 +0000") References: <20100713103134.AF88708A@resin07.mta.everyone.net> Message-ID: <82hbk2nphu.fsf@mid.bfk.de> * Roland Dobbins: > That's what I meant - even a very small botnet can easily overwhelm > software-based edge routers. >From or to your customers? Stopping customer-sourced attacks is probably a good thing for the Internet at learge. And you can't combat attacks targeted at customers within your own network unless you've got very large WAN pipes, moving you into the realm of special-purpose hardware for other reasons. Previously, this was really a no-brainer because you couldn't get PCI cards with the required interfaces, but with Ethernet everywhere, the bandwidths you can handle on commodity hardware will keep increasing. Eventually, you'll need special-purpose hardware only for a smallish portion at the top of the router market, or if you can't get the software with the required protocol support on other devices. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Wed Jul 14 08:59:39 2010 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 14 Jul 2010 13:59:39 +0000 Subject: Vyatta as a BRAS In-Reply-To: <3B8F01CE-9F9F-4235-A82C-946B0A5475C3@arbor.net> (Roland Dobbins's message of "Wed\, 14 Jul 2010 13\:43\:34 +0000") References: <201007131558.o6DFwavk096542@aurora.sol.net> <4C3CAA46.2000703@matthew.at> <180177.1279055014@localhost> <82lj9enpyc.fsf@mid.bfk.de> <3B8F01CE-9F9F-4235-A82C-946B0A5475C3@arbor.net> Message-ID: <8239vmnoz8.fsf@mid.bfk.de> * Roland Dobbins: > On Jul 14, 2010, at 8:38 PM, Florian Weimer wrote: > >> There's also the question of IP options (or extension headers). 8-) > > I know that some modern hardware-based routers have the ability to > either ignore options, or to drop option packets altogether. There might be contractual reasons not to enable that feature. 8-/ Some vendors can process options in hardware, though. > I believe the same is now true of IPv6 extension-headere, or soon > will be. You're absolutely correct that this is a significant > possible attack vector, causing the packets in question to be > punted, if there isn't a mechanism available to ignore them or to > drop said packets. It's probably not a high-priority issue for vendors until there are network issues (as opposed to potential problems seen in labs), so it's going to take quite a bit of time. Demand for devices with some IP-layer inspection capability that can handle (Fast or Gigabit) Ethernet at line rate, no matter what type of frames come in, is also a pretty recent thing, and I would be surprised if vendors can provide such capabilities across their entire relevant product line (where they advertise line-based forwarding). -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From rdobbins at arbor.net Wed Jul 14 09:12:07 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 14:12:07 +0000 Subject: Vyatta as a BRAS In-Reply-To: <82hbk2nphu.fsf@mid.bfk.de> References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> Message-ID: On Jul 14, 2010, at 8:48 PM, Florian Weimer wrote: > From or to your customers? Both. > Stopping customer-sourced attacks is probably a good thing for the Internet at learge. Concur 100%. > And you can't combat attacks targeted at customers within your own network unless you've got very large WAN > pipes, moving you into the realm of special-purpose hardware for other reasons. Sure, you can, via S/RTBH, IDMS, et. al. While DNS reflection/amplification attacks are used to create crushing volumes of attack traffic, and even smallish botnets can create high-volume attacks, most packet-flooding attacks are predicated on throughput - i.e., pps - rather than bandwidth, and tend to use small packets. Of course, they can use *lots and lots* of small packets, and often do, but one can drop these packets via the various mechanisms one has available, then reach out to the global opsec community for filtering closer to the sources. The thing is, with many DDoS attacks, the pps/bps/cps/tps required to disrupt the targets can be quite small, due to the unpreparedness of the defenders. Many high-profile attacks discussed in the press such as the Mafiaboy attacks, the Estonian attacks, the Russian/Georgian/Azerbaijan attacks, the China DNS meltdown, and the RoK/USA DDoS attacks were all a) low-volume, b) low-throughput, c) exceedingly unsophisticated, and d) eminently avoidable via sound architecture, deployment of BCPs, and sound operational practices. In fact, many DDoS attacks are quite simplistic in nature and many are low in bandwidth/throughput; the miscreants only use the resources necessary to achieve their goals, and due to the unpreparedness of defenders, they don't have a need to make use of overwhelming and/or complex attack methodologies. This doesn't mean that high-bandwidth, high-throughput, and/or complex DDoS attacks don't occur, or that folks shouldn't be prepared to handle them; quite the opposite, we see a steady increase in attack volume, thoughput and sophistication at the high end. But the fact of the matter is that many DDoS targets - and associated network infrastructure, and services such as DNS - are surprisingly fragile, and thus are vulnerable to surprisingly simple/small attacks, or even inadvertent/accidental attacks. > Previously, this was really a no-brainer because you couldn't get PCI > cards with the required interfaces, but with Ethernet everywhere, the > bandwidths you can handle on commodity hardware will keep increasing. Concur 100%. > Eventually, you'll need special-purpose hardware only for a smallish > portion at the top of the router market, or if you can't get the > software with the required protocol support on other devices. I believe that the days of software-based routers are numbered, period, due to the factors you describe. Of course, the 'top of the router market' seems to keep moving upwards, despite many predictions to the contrary. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Wed Jul 14 09:27:15 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 14:27:15 +0000 Subject: Vyatta as a BRAS In-Reply-To: <8239vmnoz8.fsf@mid.bfk.de> References: <201007131558.o6DFwavk096542@aurora.sol.net> <4C3CAA46.2000703@matthew.at> <180177.1279055014@localhost> <82lj9enpyc.fsf@mid.bfk.de> <3B8F01CE-9F9F-4235-A82C-946B0A5475C3@arbor.net> <8239vmnoz8.fsf@mid.bfk.de> Message-ID: <4D6ECB75-8603-4BA3-B66F-CE9D135259E1@arbor.net> On Jul 14, 2010, at 8:59 PM, Florian Weimer wrote: > There might be contractual reasons not to enable that feature. 8-/ Ignoring is generally pretty harmless; dropping can break traceroute, RSVP, et. al. Conversely, there are also generally pretty strong contractual reasons not to have one's edge routers go down due to excessive punts. ;> > Some vendors can process options in hardware, though. True. > It's probably not a high-priority issue for vendors until there are > network issues (as opposed to potential problems seen in labs), This is always true when it comes to security, and especially to availability. That being said, I know that at least one major vendor is cognizant of the header-extenstion issue, and is taking steps to mitigate the associated risk. > so it's going to take quite a bit of time. Yes, this is always the case, unfortunately. > Demand for devices with some IP-layer inspection capability that can handle (Fast or Gigabit) > Ethernet at line rate, no matter what type of frames come in, is also > a pretty recent thing, and I would be surprised if vendors can provide > such capabilities across their entire relevant product line (where > they advertise line-based forwarding). With large vendors, these things are generally accomplished piecemeal, on a BU-by-BY, product-by-product basis. Unfortunate, but true, nonetheless. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From dylan.ebner at crlmed.com Wed Jul 14 09:55:52 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Wed, 14 Jul 2010 14:55:52 +0000 Subject: OER/PfR with BGP for inbound load sharing Message-ID: <017265BF3B9640499754DD48777C3D206909F0B950@MBX9.EXCHPROD.USA.NET> Does anyone have any experience with using OER for inbound load sharing? I am looking to see if people are generaly satisfied with it's abilities or if I should look for other options to balance my inbound traffic. I have two connections (one 50Mb and one 25Mb) with partial BGP routes across two routers that I would like to move from an active/standby model to a more active/active model. Our organization moves very little information out of our forward facing precessence servers so outbound balancing is not as important. Almost 80% of our inbound traffic is VPN as well so using application discovery isn't that important either. Some specific questions I have are: Is OER aware of traffic-shape or bandwidth contstraints that are applied to an interface? Does OER simply add prepending for my advertised routes to my upstreams or does it actually prepend AS from inbound providers to move specific traffic from an AS to one of my underutilized connections? Does OER have to ability to control inbound traffic on a subnet level within the same AS? We receive a ton of data from a few AS numbers, so simply moving a single AS to a different connection may not be extremely effective. Thanks. Dylan Ebner From rdobbins at arbor.net Wed Jul 14 10:10:20 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 15:10:20 +0000 Subject: OER/PfR with BGP for inbound load sharing In-Reply-To: <017265BF3B9640499754DD48777C3D206909F0B950@MBX9.EXCHPROD.USA.NET> References: <017265BF3B9640499754DD48777C3D206909F0B950@MBX9.EXCHPROD.USA.NET> Message-ID: <1F082953-F081-421D-96C8-4638F6D40E77@arbor.net> On Jul 14, 2010, at 9:55 PM, Dylan Ebner wrote: > I should look for other options to balance my inbound traffic. Beyond the binary choice to advertise or not to advertise a given prefix via a given peer/upstream and/or any TE policies your peers/upstreams may support via community/attribute tagging, you've really no control over inbound traffic path selection. You can prepend, but whether other networks honor it or ignore it - or if they do honor it, *how* they honor it - is entirely beyond your control. So, vendor marketing claims aside, the concept of 'load-balancing' inbound traffic isn't really a valid one. The only actual path-selection control you have is over your outbound traffic, and that only for a single hop beyond your network, into each of your peers/upstreams. What happens after that is beyond your control, as well. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From jgreco at ns.sol.net Wed Jul 14 10:17:48 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 14 Jul 2010 10:17:48 -0500 (CDT) Subject: Vyatta as a BRAS In-Reply-To: <37927AEC-676C-4D2A-BD4B-0B6A067AA1B5@arbor.net> Message-ID: <201007141517.o6EFHmhI013994@aurora.sol.net> > On Jul 14, 2010, at 5:45 AM, Joe Greco wrote: > > That's just a completely ignorant statement to make. > > It's based on a great deal of real-world experience; I'm sorry you consider= > that to be 'ignorant'. You're speaking to someone who has extensive experience with "software" based routers, and you're failing to acknowledge the upsides of such an architecture, when I've already conceded the upsides of a hardware architecture. > > I notice in particular how carefully you qualify that with "[w]hen BCPs = > are=20 > > followed"; the fact that hardware router manufacturers have declared > > everything and anything that derails their bullet trains as "not a > > BCP" is a perfect example of this deceptive sort of misinformation. > > Anti-spoofing, iACLs, CoPP (or its equivalent on non-Cisco platforms), et. = > al. aren't 'misinformation'. They're useful, proven techniques/features wh= > ich any operator ought to implement. The things that any given use scenario ought to implement are highly dependent on the actual application. > > There are plenty of FreeBSD based devices out there that are passing > > tons of traffic; almost any of them are more competent than any Cisco > > router I'm aware of when hitting them directly with traffic > > Then your experience of Cisco routers (and/or those from other vendors) mus= > t be limited to the lower-end platforms; I can assure you that faster Cisco= > boxes such as ASRs, GSRs, CRSes, and so forth are in another league entire= > ly, and can handle mpps of to-us traffic, when properly configured. Softwa= > re-based routers simply can't do that; it's not an indictment of them, it's= > just that they aren't suited to purpose, just as station wagons generally = > aren't to be found in the Indy 500. So your solution is to keep throwing heavier hardware at the problem until it works. Okay, I see that. Now, let me quote from a different message: > If maintaining availability is important, then hardware-based (semantic > hairsplitting aside) devices are a requirement. The truth is that you can keep throwing CPU at a problem as well. I can size a software based router such that it can remain available. This is neither new nor exciting technology. Luigi Rizzo was doing extensive work on this about a decade ago: he took an Athlon 750 platform with 4 100Mbit ethernet interfaces in it (Athlon 750 = 1999 tech) and was able to exceed 100Mbps levels without a problem. The UNIX based platforms have extensive capabilities to defend against attack, even without a firewall. As with a hardware based platform, there are both good things and bad things you can do that will impact availability. Software based platforms have an incredible edge in areas that hardware based platforms don't, including capex and the ability to find replacement parts after a disaster. I spent some time after the Haiti quake getting FreeBSD-based routers up and running, a task made easier because it's a lot easier to find a working PC and scavenge some network cards than it is to find a working Cisco router in a city where all inbound and outbound transportation is paralyzed. You can continue to defend your position, of course, but it's just looking a bit silly. A wise engineer knows that there are several ways to tackle any task, and "one tool for every job" is not a sound policy. If you'd like to revise your position to "Cisco and Juniper software based solutions are underpowered PoS", that's probably a defensible position, and you won't get any argument from me. Please don't generalize such a position into all software based devices, though. Overall, there are a lot more software based routers out there than hardware based devices. Your cablemodem, your ADSL modem, your wifi access point, all these are probably software based devices. Some of them will melt under a too-great load. Some won't. This is a function of many different factors. There is nothing inherent in a software-based device that's going to make it fail under load - just as there's nothing inherent in a hardware-based device that's going to make it succeed (which is why you have to qualify your defense of these with "must follow BCP"). It's the related engineering that ultimately determines whether or not it all works out. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rdobbins at arbor.net Wed Jul 14 10:44:11 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 15:44:11 +0000 Subject: Vyatta as a BRAS In-Reply-To: <201007141517.o6EFHmhI013994@aurora.sol.net> References: <201007141517.o6EFHmhI013994@aurora.sol.net> Message-ID: On Jul 14, 2010, at 10:17 PM, Joe Greco wrote: > The truth is that you can keep throwing CPU at a problem as well. I can size a software based router such that it can remain available. Not against mpps, or even high kpps, you can't, unfortunately. > Software based platforms have an incredible edge in areas that hardware based platforms don't, including capex and the ability to find replacement parts after a disaster. I agree 100% with this, and with much of what you say. My point is that at the *edge* - like a BRAS, which is how this thread started - one must have platforms which can be adequately protected against attack/abuse, and hardware-based platforms are the only practical way to do that. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From karim.adel at gmail.com Wed Jul 14 12:24:04 2010 From: karim.adel at gmail.com (Kasper Adel) Date: Wed, 14 Jul 2010 20:24:04 +0300 Subject: NOC Best Practices Message-ID: Hello Everyone, I am currently working on building a NOC so i'm looking for materials/pointers to Best Practices documented out there. On the top of my head are things like: 1) Documenting Incidents and handling them 2) Documenting Syslog messages 3) Documenting Vendor Software Bugs 4) Shift to Shift Hand over procedures 5) Commonly used scripts for monitoring 6) Frequently testing High Availability 7) Capturing config changes. ....etc I can see that this is years of experience but i am wondering if any of this was captured some where. Thanks, Kim From lowen at pari.edu Wed Jul 14 13:49:47 2010 From: lowen at pari.edu (Lamar Owen) Date: Wed, 14 Jul 2010 14:49:47 -0400 Subject: Vyatta as a BRAS In-Reply-To: <0428DEB0-B24B-4E32-890F-0ADEE5F7B954@arbor.net> References: Message-ID: <201007141449.48220.lowen@pari.edu> On Wednesday, July 14, 2010 08:39:50 am Dobbins, Roland wrote: > And it's not *my* definition - 'hardware-based' vs. 'software-based' are the terms to describe these two fundamental architectural classes of router *within Cisco itself*. [snip] > There's a world of difference in packet-handling mechanisms and sheer performance between a 7200 and a CRS-1, or a GSR, or a CRS-3, or Juniper T-series - and not just one of 'more, faster processors', but of fundamental architecture. CEF is CEF is CEF, whether done on a 2600 or a 7200 or a GSR. Now, don't get me wrong; the engineers who make massively parallel forwarding engines are creative and smart folks, and have come up with very elegant methods of moving the bits ever faster, but the fundamental forwarding architectures, even of these accelerated boxes, can be implemented in pure software, as evidenced by the Cisco Nexus 1000V. > This is why 'hardware-based' vs. 'software-based' is a useful distinction; again, note that within Cisco, these are the common terms used to describe these general classes of device, with 7200s and ISRs being termed 'software-based', and the other models mentioned above described as 'hardware-based'. Marketingspeak doesn't necessarily reflect reality. The original draft of one of my replies in this thread said this 'Let's run this rabbit, and dispel some marketing hype while we're at it.' The reality is that 'hardware-based' routers really are AMP (asymmetrical multiprocessing) software-based routers, with specialized processors running specialized software. And when implemented properly they are very good at what they do; I have GSR's, they work great, and regardless of what engine is on the linecard some software at some level running on some processor is making the forwarding decisions at the data plane, and they can even for certain things require a punt to the MIPS processor on the linecard (IPv6 on Engine 1, anyone?). Knowing the technology and its architecture, without blindly buying into marketingspeak, helps operators make better procurement decisions. And Cisco's website has most of the information you need to make that decision, if you use their hardware, which is very good. Dig deeply enough, and past the hardware versus software pseudodichotomy, and you can make very informed decisions indeed. As a tongue in cheek example, remember the 'switching router' versus 'routing switch' distinction? If a specialized network processing engine in an AMP router can protect the control plane CPU, then code running on different processors in an SMP system could do the same. Perhaps not as efficiently, but the end result can be the same. I mean, I wonder if Blue Gene or Jaguar could give a CRS series a run for its money in terms of routing power (especially on the control plane), and what the price/performance ratio would be to throwing something like Jaguar (224K Opteron processors, running Linux) at the relatively mundane task of throwing precisely metered bits around the wires. :-) Regardless of recommendations, people are using commodity server-grade SMP hardware to run commodity OS's to get the job done, and given the people who have chimed in here, apparently are doing it without lots of problems. The increase on this and other lists of questions about Mikrotik, Vyatta, and other nontraditional routing platforms is an interesting throwback to the days of Proteon routers, the original SUN, and Cisco's multibus roots, and it shows that people are deploying these newer and much faster boxen in the real world, bugs and all. It's not a 'software-based = bad; hardware-based = good' world, even at the edge anymore; a few years ago, sure, I wouldn't dream of doing such a thing. I for one love what a good parallel state machine in an FPGA can do to your software's performance (we're doing that here, doing interferometric correlation at 96Gb/s on a relatively inexpensive FPGA platform based on IBOB); or what GPU acceleration can do to graphics performance, but it is a help to realize that those activities, accelerated though they may be, are still software-based. And while it's not a BRAS, one of the most exciting products I've seen in a long while from Cisco is the above-mentioned Nexus 1000V. Pure software virtual switching for VMware. From jlewis at lewis.org Wed Jul 14 14:05:29 2010 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 14 Jul 2010 15:05:29 -0400 (EDT) Subject: Vyatta as a BRAS In-Reply-To: <180177.1279055014@localhost> References: <201007131558.o6DFwavk096542@aurora.sol.net> <4C3CAA46.2000703@matthew.at> <180177.1279055014@localhost> Message-ID: On Tue, 13 Jul 2010 Valdis.Kletnieks at vt.edu wrote: > I wasn't aware that the 7206 and M20 classified as software-based. I don't see why you could call it anything but a software router. That's sort of why things like it and the 7500 before it lasted so long. As the thing ages, cisco comes out with new NPE (or RSP/VIP) processors with faster CPUs / more memory capacity that are able to move more packets. i.e. NPE-100->NPE-150->NPE-200->NPE-225->NPE-300->NPE-400->NPE-G1->NPE-G2 You could start with a VXR with NPE-225 and keep upgrading the CPU and keep the thing in service with the same interface cards 15 years or more. ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From sthaug at nethelp.no Wed Jul 14 14:20:20 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 14 Jul 2010 21:20:20 +0200 (CEST) Subject: Vyatta as a BRAS In-Reply-To: <201007141449.48220.lowen@pari.edu> References: <238090.1279108916@localhost> <0428DEB0-B24B-4E32-890F-0ADEE5F7B954@arbor.net> <201007141449.48220.lowen@pari.edu> Message-ID: <20100714.212020.74739844.sthaug@nethelp.no> > Regardless of recommendations, people are using commodity server-grade SMP hardware to run commodity OS's to get the job done, and given the people who have chimed in here, apparently are doing it without lots of problems. The increase on this and other lists of questions about Mikrotik, Vyatta, and other nontraditional routing platforms is an interesting throwback to the days of Proteon routers, the original SUN, and Cisco's multibus roots, and it shows that people are deploying these newer and much faster boxen in the real world, bugs and all. How many of them are deploying server-grade SMP hardware / commodity OS to handle 10 Gig links and expect to handle DoS attacks using minimum sized packets? That's 14.88 Mpps with Ethernet encapsulation, for each 10 Gig link. Anybody? Steinar Haug, Nethelp consulting, sthaug at nethelp.no From sthaug at nethelp.no Wed Jul 14 14:21:22 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 14 Jul 2010 21:21:22 +0200 (CEST) Subject: Vyatta as a BRAS In-Reply-To: References: <180177.1279055014@localhost> Message-ID: <20100714.212122.41645644.sthaug@nethelp.no> > > I wasn't aware that the 7206 and M20 classified as software-based. > > I don't see why you could call it anything but a software router. The 7206 yes. The M20, no. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From rdobbins at arbor.net Wed Jul 14 15:14:52 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Wed, 14 Jul 2010 20:14:52 +0000 Subject: Vyatta as a BRAS In-Reply-To: <201007141449.48220.lowen@pari.edu> References: <0428DEB0-B24B-4E32-890F-0ADEE5F7B954@arbor.net> <201007141449.48220.lowen@pari.edu> Message-ID: On Jul 15, 2010, at 1:49 AM, Lamar Owen wrote: > CEF is CEF is CEF, whether done on a 2600 or a 7200 or a GSR. Now, don't get me wrong; the engineers who make massively parallel forwarding engines are creative and smart folks, and have come up with very elegant methods of moving the bits ever faster, but the fundamental forwarding architectures, even of these accelerated boxes, can be implemented in pure software, as evidenced by the Cisco Nexus 1000V. This is a *vast* oversimplification of the 'life of a packet' in a box like a CRS-1 vs. a 7200, for example. You know this, of course. > Marketingspeak doesn't necessarily reflect reality. The original draft of one of my replies in this thread said this 'Let's run this rabbit, and dispel some marketing hype while we're at it.' I wasn't a marketing person during my time at Cisco, and I'm not a marketing person now. Technical people within Cisco and outside Cisco routinely make use of the terms 'hardware-based' and 'software-based' to describe these fundamental classes of routers, and have for years. > The reality is that 'hardware-based' routers really are AMP (asymmetrical multiprocessing) software-based routers, with specialized processors running specialized software. Right - the 'hardware-based routers' idiom comes from the 'specialized processors', known as NPUs, ASICs, TCAMs, and so forth. > And when implemented properly they are very good at what they do; I have GSR's, they work great, and regardless of what engine is on the linecard some software at some level running on some processor is making the forwarding decisions at the data plane, 'Some processor' = ASIC or NPU = 'hardware-baed'. > and they can even for certain things require a punt to the MIPS processor on the linecard (IPv6 on Engine 1, anyone?). Yes, this is true - or even to the system RP. > Knowing the technology and its architecture, without blindly buying into marketingspeak, helps operators make better procurement decisions. Nobody in this conversation so far is 'blindly buying into marketingspeak', to my knowledge - certainly not me. > And Cisco's website has most of the information you need to make that decision, if you use their hardware, which is very good. The content on Cisco's Web site is confusing, redundant, full of *actual* marketing-speak, and highly confusing in many aspects. This isn't a problem unique to Cisco, mind, but afflicts almost all technology companies. > Dig deeply enough, and past the hardware versus software pseudodichotomy, and you can make very informed decisions indeed. Yes, but you aren't going to do that by looking at product marketing materials on a Web site. > As a tongue in cheek example, remember the 'switching router' versus 'routing switch' distinction? Yes, which was nonsense. OTOH, 'hardware-based' vs. 'software-based' is a useful distinction commonly employed by technical, non-marketing people within both the vendor and operational communities alike. > If a specialized network processing engine in an AMP router can protect the control plane CPU, then code running on different processors in an SMP system could do the same. Not on a general-purpose SMP system running commodity processors such as those found in PCs. > Perhaps not as efficiently, but the end result can be the same. I mean, I wonder if Blue Gene or Jaguar could give a CRS series a run for its money in terms of routing power (especially on the control plane), Possibly - certainly not on the forwarding plane. > and what the price/performance ratio would be to throwing something like Jaguar (224K Opteron processors, running Linux) at the relatively mundane task of throwing precisely metered bits around the wires. :-) Fruitless speculation, IMHO. > Regardless of recommendations, people are using commodity server-grade SMP hardware to run commodity OS's to get the job done, and given the people who have chimed in here, apparently are doing it without lots of problems. My experience is that folks doing this on the edges of their networks eventually end up regretting it, after they get zorched a time or two. > The increase on this and other lists of questions about Mikrotik, Vyatta, and other nontraditional routing platforms is an interesting throwback to the days of Proteon routers, the original SUN, and Cisco's multibus roots, and it shows that people are deploying these newer and much faster boxen in the real world, bugs and all. It shows me that a lot of folks, because they haven't been in the industry very long and/or don't learn from the mistakes of others in the past, seem determined to repeat those same mistakes, ad nauseam, ad infinitum. > It's not a 'software-based = bad; hardware-based = good' world, even at the edge anymore; I very strongly disagree with this, based upon my hands-on operational experience in production networks. Running software-based platforms at the edges of one's network is extraordinarily irresponsible, in operational terms, if availability is an important metric for said network. > a few years ago, sure, I wouldn't dream of doing such a thing. I for one love what a good parallel state machine in an FPGA can do to your software's performance (we're doing that here, doing interferometric correlation at 96Gb/s on a relatively inexpensive FPGA platform based on IBOB); or what GPU acceleration can do to graphics performance, but it is a help to realize that those activities, accelerated though they may be, are still software-based. Again, with the semantics. If you take this hairsplitting to its logical extension, there's no such thing as 'hardware', because it's all 'software' - just some of it is 'hardware' which happens to be instantiated in the form of physical chipsets. While this may be intellectually appealing to some folks at the hand-waving, 30,000-foot, pseudo-philosophical level, as a matter of practical reality in the real world on real networks using real boxes, the distinction has a great deal of import. > And while it's not a BRAS, one of the most exciting products I've seen in a long while from Cisco is the above-mentioned Nexus 1000V. Pure software virtual switching for VMware. The N1KV is interesting primarily because it's Cisco's first retail pure-software - i.e., not tied to a box - product intended to move packets around. It also highlights the flexibility and portability of NX-OS, which is Cisco's best OS to date, IMHO. At the same time, from a performance perspective, it leaves a lot to be desired. I hardly like to think what will happen when a few dozen VMs sending their traffic through an N1KV get botted and start spewing out SYN-floods and so forth. We all know there's a great deal of difference between a box like a CRS-1 and a box like a 7200, and/or an Intel box running Quagga or what-have-you, and it's absurd to pretend otherwise. Bottom line - use a software-based box for a layer-3 edge application like a BRAS, and you're asking for trouble. And this time, I'm really done with this thread, as semantic arguments quickly grow tiresome. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From pelle at hemmop.com Wed Jul 14 15:16:11 2010 From: pelle at hemmop.com (Per Carlson) Date: Wed, 14 Jul 2010 22:16:11 +0200 Subject: Vyatta as a BRAS In-Reply-To: <238090.1279108916@localhost> References: <2DBC2701-5719-4156-9B44-E31DA93288BA@arbor.net> <711A949B-79BD-4995-85F8-4155A2452C00@suspicious.org> <357804033-1279008045-cardhu_decombobulator_blackberry.rim.net-1282305806-@bda903.bisx.prod.on.blackberry> <4C3C811F.4090900@xyonet.com> <4C3CB8F1.6080703@foobar.org> <7D84DDA7-1ACD-42D4-94B8-F0E95165731F@tony.li> <238090.1279108916@localhost> Message-ID: > Is the CRS-1 hardware or software? > Lots of custom hardware in there - but lots of processing cores that look > suspiciously like software engines too. It might well be software engines in there, but that's not the point here. The linecards (MSC/PLIM etc.) in a CRS is designed to handle wirerate traffic *of any packet length* and simultaneously do ACLs, QoS or whatever else you throw at them. If that is done using FPGAs, CPUs or trained monkeys isn't really that interesting, as long as it works. And it does. But it won't come for free. A software-based router, i.e something equipped with a central CPU doing all heavy lifting, of *any kind* isn't designed to do that. The old corollary 7a in RFC1925 still make sense: "Good, Fast, Cheap: Pick any two (you can't have all three)." Some of the arguments expressed also vaguely resembles truth 11 in the same RFC: Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works. There is a reason internet isn't built on Dell hardware... -- Pelle A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? From joe.abley at icann.org Wed Jul 14 17:12:35 2010 From: joe.abley at icann.org (Joe Abley) Date: Wed, 14 Jul 2010 22:12:35 +0000 Subject: Root Zone DNSSEC Deployment Technical Status Update Message-ID: Root Zone DNSSEC Deployment Technical Status Update 2010-07-14 This is the eleventh of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at . We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. KSK CEREMONY 2 COMPLETE The second KSK ceremony for the root zone was completed this week in El Segundo, CA, USA. The Ceremony Administrator was Mehmet Akcin. The second production Key Signing Request (KSR) generated by VeriSign has now been processed by ICANN using the root zone KSK generated in KSK Ceremony 1, and the resulting Signed Key Response (SKR) has been accepted by VeriSign. This SKR contains signatures for Q4 2010, for use between 2010-10-01 and 2010-12-31. Audit materials relating to both the first and second ceremonies will be published today at . FULL PRODUCTION SIGNED ROOT ZONE The transition from Deliberately-Unvalidatable Root Zone (DURZ) to production signed root zone is scheduled take place on 2010-07-15 within a maintenance window which begins at 1930 UTC and ends at 2330 UTC. This is the usual window for the generation and distribution of root zones with SOA serials ending in 01. PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ 2010-06-16: First Key Signing Key (KSK) Ceremony 2010-07-12: Second Key Signing Key (KSK) Ceremony To come: 2010-07-15: Distribution of validatable, production, signed root zone; publication of root zone trust anchor (Please note that this schedule is tentative and subject to change based on testing results or other unforeseen factors.) From joelja at bogus.com Wed Jul 14 18:39:26 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 14 Jul 2010 16:39:26 -0700 Subject: Vyatta as a BRAS In-Reply-To: References: <201007131558.o6DFwavk096542@aurora.sol.net> <4C3CAA46.2000703@matthew.at> Message-ID: <4C3E4AAE.5030803@bogus.com> On 7/13/10 11:11 AM, Dobbins, Roland wrote: > > On Jul 14, 2010, at 1:02 AM, Matthew Kaufman wrote: > >> Dangerous in places where forwarding table exceeds hardware cache >> limits. (See Code Red worm stories) > > > During the Code Red/Nimda period (2001), and on into the > Slammer/Blaster/Nachi period (2003), all the routers I personally > know of which were adversely affected were software-based, didn't > make use of ASICs for forwarding. Having msdp turned on was a great way to get nuked by slammer regardless of your choice of forwarding technology. Which reminds me control plane protection is about more than just acls and rate limiting. > ----------------------------------------------------------------------- > > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > From jgreco at ns.sol.net Wed Jul 14 19:03:59 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 14 Jul 2010 19:03:59 -0500 (CDT) Subject: Vyatta as a BRAS In-Reply-To: Message-ID: <201007150003.o6F03xFa019423@aurora.sol.net> > On Jul 14, 2010, at 10:17 PM, Joe Greco wrote: > > > The truth is that you can keep throwing CPU at a problem as well. I can = > size a software based router such that it can remain available. > > Not against mpps, or even high kpps, you can't, unfortunately. Really? I'm positive that I can, because I *have*, and other people *have*. The sweet spot for protecting a 100Mbps circuit, in particular, moved from hardware to software about five years ago. That simply means it's more cost-effective for a competent admin to spend some time to set up the box than it is to spend money on dedicated silicon that'll be obsolete in a few years, a fact that's conveniently ignored by a lot of the advocates of such solutions. To drive the point home, FreeBSD based routers that we built in 2004 are able to cope with full routing tables and IPv6 *today*, at the same traffic levels they were designed for, and those particular qualities don't seem to be present in many of the hardware-based offerings of the era. If and when they cease to be useful in that capacity, they can be trivially repurposed as firewalls or web servers or other similar tasks, because unlike the pricey purpose-built router hardware, there are advantages to general purpose hardware. Quite frankly, this is starting to be a little annoying. Perhaps you could do some research, or find some competent admins and test a few well built setups yourself before you make any more disprovable claims. My claims are not ridiculous and are not a figment of my imagination; I can point to many-years-old documented examples, such as http://lists.freebsd.org/pipermail/freebsd-net/2004-September/004840.html http://info.iet.unipi.it/~luigi/polling/ These are tests of forwarding capabilities, true, but the reality is that the same sorts of things that make this possible make it relatively easy to support large numbers of packets directed "at the control plane", since the concept of the control plane isn't as separated in the FreeBSD software model as it is in the hardware model. As a result, a FreeBSD box can take and sink quite a bit of traffic. Doing so does not cripple it. For giggles, I took two out-of-the-box FreeBSD 8.0 servers, twiddled *only* device polling to on, and started them running traffic at each other. Both were sending north of 100Mbps (>>100Kpps) of traffic at the other, both when listening and when not, no problems, no crashes, no issues. That doesn't sound too great until I reveal that I was lazy and it's only some excess capacity on a VMware box that's available to these two virtual servers. > > Software based platforms have an incredible edge in areas that hardware b= > ased platforms don't, including capex and the ability to find replacement p= > arts after a disaster. > > I agree 100% with this, and with much of what you say. My point is that at= > the *edge* - like a BRAS, which is how this thread started - one must have= > platforms which can be adequately protected against attack/abuse, and hard= > ware-based platforms are the only practical way to do that. In some cases, for some purposes, yes. Otherwise, no. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From tvarriale at comcast.net Wed Jul 14 23:16:49 2010 From: tvarriale at comcast.net (Tony Varriale) Date: Wed, 14 Jul 2010 23:16:49 -0500 Subject: Vyatta as a BRAS References: <201007150003.o6F03xFa019423@aurora.sol.net> Message-ID: ----- Original Message ----- From: "Joe Greco" To: "Dobbins, Roland" Cc: "NANOG list" Sent: Wednesday, July 14, 2010 7:03 PM Subject: Re: Vyatta as a BRAS >> On Jul 14, 2010, at 10:17 PM, Joe Greco wrote: >> >> > The truth is that you can keep throwing CPU at a problem as well. I >> > can = >> size a software based router such that it can remain available. >> >> Not against mpps, or even high kpps, you can't, unfortunately. > > Really? I'm positive that I can, because I *have*, and other people > *have*. The sweet spot for protecting a 100Mbps circuit, in particular, > moved from hardware to software about five years ago. That simply means > it's more cost-effective for a competent admin to spend some time to set > up the box than it is to spend money on dedicated silicon that'll be > obsolete in a few years, a fact that's conveniently ignored by a lot of > the advocates of such solutions. To drive the point home, FreeBSD based > routers that we built in 2004 are able to cope with full routing tables > and IPv6 *today*, at the same traffic levels they were designed for, and > those particular qualities don't seem to be present in many of the > hardware-based offerings of the era. If and when they cease to be useful > in that capacity, they can be trivially repurposed as firewalls or web > servers or other similar tasks, because unlike the pricey purpose-built > router hardware, there are advantages to general purpose hardware. > > Quite frankly, this is starting to be a little annoying. Perhaps you > could do some research, or find some competent admins and test a few well > built setups yourself before you make any more disprovable claims. My > claims are not ridiculous and are not a figment of my imagination; I can > point to many-years-old documented examples, such as > > http://lists.freebsd.org/pipermail/freebsd-net/2004-September/004840.html > > http://info.iet.unipi.it/~luigi/polling/ > > These are tests of forwarding capabilities, true, but the reality is that > the same sorts of things that make this possible make it relatively easy > to support large numbers of packets directed "at the control plane", since > the concept of the control plane isn't as separated in the FreeBSD > software > model as it is in the hardware model. As a result, a FreeBSD box can take > and sink quite a bit of traffic. Doing so does not cripple it. > > For giggles, I took two out-of-the-box FreeBSD 8.0 servers, twiddled > *only* device polling to on, and started them running traffic at each > other. Both were sending north of 100Mbps (>>100Kpps) of traffic at > the other, both when listening and when not, no problems, no crashes, > no issues. That doesn't sound too great until I reveal that I was > lazy and it's only some excess capacity on a VMware box that's > available to these two virtual servers. > >> > Software based platforms have an incredible edge in areas that hardware >> > b= >> ased platforms don't, including capex and the ability to find replacement >> p= >> arts after a disaster. >> >> I agree 100% with this, and with much of what you say. My point is that >> at= >> the *edge* - like a BRAS, which is how this thread started - one must >> have= >> platforms which can be adequately protected against attack/abuse, and >> hard= >> ware-based platforms are the only practical way to do that. > > In some cases, for some purposes, yes. Otherwise, no. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > I briefly browsed the links and I didn't see any traffic profiles included. If you are talking about pushing x mbps with no specifics and/or general traffic, I think most of us agree you can do that easily and probably consistently without any issues. And for some icing, you may even do it at <90% average CPU util. Does that mean it should be an edge device at any service provider? No. Some? Sure. Can you point to any specific tests of attack vectors and/or traffic profiles with: CPU utilization, packet loss levels and pps/mbps/etc data? The reason I ask is that Roland is in a specific business and has a specific point. As a side, were those 2 VMs on the same box? That traffic out on the wire? What's the traffic profile? tv From jgreco at ns.sol.net Thu Jul 15 10:23:15 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 15 Jul 2010 10:23:15 -0500 (CDT) Subject: Vyatta as a BRAS In-Reply-To: Message-ID: <201007151523.o6FFNFX2010704@aurora.sol.net> > I briefly browsed the links and I didn't see any traffic profiles included. > > If you are talking about pushing x mbps with no specifics and/or general > traffic, I think most of us agree you can do that easily and probably > consistently without any issues. And for some icing, you may even do it at > <90% average CPU util. Does that mean it should be an edge device at any > service provider? No. Some? Sure. Those last two words are the point I've been trying to make. If you'll recall, Roland said flat out that that wasn't the case. > Can you point to any specific tests of attack vectors and/or traffic > profiles with: CPU utilization, packet loss levels and pps/mbps/etc data? Not without doing the work; I have no plans to do the work for free just to prove a point on NANOG. I have Real Work to do. > The reason I ask is that Roland is in a specific business and has a specific > point. Sure, and I'm making the point that this point isn't universally true in the way Roland would like to paint it. > As a side, were those 2 VMs on the same box? That traffic out on the wire? > What's the traffic profile? Yes, no (just between vm's), just sheer UDP blasting of both the vservers from the other (mutual attack) with ports both closed and opened. Since Roland's point seems to be that the availability of the platform is impacted by an attack on the control plane (in this case, for all reasonable intents and purposes, that would appear to be the host OS's addresses), I didn't really feel it necessary to get particularly complicated, and just tested the control plane availability theory. My point is that a randomly created *virtual* machine can absorb a >100Mbps attack on it at minimum packet size without blinking, while simultaneously delivering such an attack, in the spare CPU cycles of a vm host that has dozens of hosts on it. It's meant to suggest that what Roland is selling includes a healthy dose of FUD; I, on the other hand, am happy to concede that at a certain point, the hardware stuff is going to be more effective. It'd be nice if Roland could concede that software-based routers have some advantages and some reasonable use profiles. For example, for a provider whose entire upstream capacity is 1Gbps, I have a hard time seeing how a Linux- or FreeBSD-based box could credibly be claimed not to be a suitable edge router. The problem with Roland's statement is its absoluteness; I have a much easier side to argue, since I merely need to explain one case where the use profile does not result in failure, and there are many to choose from. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rdobbins at arbor.net Thu Jul 15 10:35:45 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 15 Jul 2010 15:35:45 +0000 Subject: Vyatta as a BRAS In-Reply-To: <201007151523.o6FFNFX2010704@aurora.sol.net> References: <201007151523.o6FFNFX2010704@aurora.sol.net> Message-ID: <52797E25-BE3A-4ECB-B70E-B56ABB3908CE@arbor.net> On Jul 15, 2010, at 10:23 PM, Joe Greco wrote: > For example, for a provider whose entire upstream capacity is 1Gbps, I have a hard time seeing how a Linux- or FreeBSD-based box could credibly be claimed not to be a suitable edge router. Because it can and will be whacked quite easily by anyone who packets it, either deliberately or inadvertently. I've seen too many software-based routers fall over with far, far less traffic than 1gb/sec to think otherwise. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From bogstad at pobox.com Thu Jul 15 10:54:39 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Thu, 15 Jul 2010 11:54:39 -0400 Subject: Vyatta as a BRAS In-Reply-To: <52797E25-BE3A-4ECB-B70E-B56ABB3908CE@arbor.net> References: <201007151523.o6FFNFX2010704@aurora.sol.net> <52797E25-BE3A-4ECB-B70E-B56ABB3908CE@arbor.net> Message-ID: On Thu, Jul 15, 2010 at 11:35 AM, Dobbins, Roland wrote: > > On Jul 15, 2010, at 10:23 PM, Joe Greco wrote: > >> For example, for a provider whose entire upstream capacity is 1Gbps, I have a hard time seeing how a Linux- or FreeBSD-based box could credibly be claimed not to be a suitable edge router. > > Because it can and will be whacked quite easily by anyone who packets it, either deliberately or inadvertently. ?I've seen too many software-based routers fall over with far, far less traffic than 1gb/sec to think otherwise. Since you've seen "many software-based routers fall over", can you provide details on specific hardware/software/traffic patterns/rates where you've seen these failures? From what I can tell, software based routers are almost universally used in SOHO environments; so it would be nice to know when such solutions are no longer viable in your experience. Thanks, Bill Bogstad From cian.brennan at redbrick.dcu.ie Thu Jul 15 11:01:32 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Thu, 15 Jul 2010 17:01:32 +0100 Subject: Vyatta as a BRAS In-Reply-To: References: <201007151523.o6FFNFX2010704@aurora.sol.net> <52797E25-BE3A-4ECB-B70E-B56ABB3908CE@arbor.net> Message-ID: <20100715160132.GA18135@minerva.redbrick.dcu.ie> On Thu, Jul 15, 2010 at 11:54:39AM -0400, Bill Bogstad wrote: > On Thu, Jul 15, 2010 at 11:35 AM, Dobbins, Roland wrote: > > > > On Jul 15, 2010, at 10:23 PM, Joe Greco wrote: > > > >> For example, for a provider whose entire upstream capacity is 1Gbps, I have a hard time seeing how a Linux- or FreeBSD-based box could credibly be claimed not to be a suitable edge router. > > > > Because it can and will be whacked quite easily by anyone who packets it, either deliberately or inadvertently. ?I've seen too many software-based routers fall over with far, far less traffic than 1gb/sec to think otherwise. > > Since you've seen "many software-based routers fall over", can you > provide details on specific hardware/software/traffic patterns/rates > where you've seen these failures? From what I can tell, software > based routers are almost universally used in SOHO environments; so it > would be nice to know when such solutions are no longer viable in your > experience. > SOHO environmnents aren't normally targets of DOS attacks. And if they are, their pipes are probably small enough to be easily filled with far less difficulty than making the router fall over. I'm almost certain they're not the uses that Roland is saying that software routers are entirely unsuited for. > Thanks, > Bill Bogstad > > From rdobbins at arbor.net Thu Jul 15 11:04:38 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 15 Jul 2010 16:04:38 +0000 Subject: Vyatta as a BRAS In-Reply-To: <20100715160132.GA18135@minerva.redbrick.dcu.ie> References: <201007151523.o6FFNFX2010704@aurora.sol.net> <52797E25-BE3A-4ECB-B70E-B56ABB3908CE@arbor.net> <20100715160132.GA18135@minerva.redbrick.dcu.ie> Message-ID: On Jul 15, 2010, at 11:01 PM, Cian Brennan wrote: > I'm almost certain they're not the uses that Roland is saying that software > routers are entirely unsuited for. Correct - I'm talking about SP (and even enterprise) edge routers. I've seen as little as a few hundred kpps totally hose Cisco 7200s, boxes running Zebra/Quagga, and so forth. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From jgreco at ns.sol.net Thu Jul 15 11:33:09 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Thu, 15 Jul 2010 11:33:09 -0500 (CDT) Subject: Vyatta as a BRAS In-Reply-To: <52797E25-BE3A-4ECB-B70E-B56ABB3908CE@arbor.net> Message-ID: <201007151633.o6FGXAbJ011684@aurora.sol.net> > On Jul 15, 2010, at 10:23 PM, Joe Greco wrote: > > For example, for a provider whose entire upstream capacity is 1Gbps, I ha= > ve a hard time seeing how a Linux- or FreeBSD-based box could credibly be c= > laimed not to be a suitable edge router. > > Because it can and will be whacked quite easily by anyone who packets it, e= > ither deliberately or inadvertently. I've seen too many software-based rou= > ters fall over with far, far less traffic than 1gb/sec to think otherwise. You seem to be off in your own little world. Provided with a counterexample where this isn't true, you simply ignore it. Your arguments revolve around "My Ford Pinto's gas tank once exploded on me and it happened to other people too, therefore all inexpensive cars have unsafe gas tanks." The sad reality is that any gas tank can be ruptured and can be made to explode, but concluding that this is limited to inexpensive cars is a silly conclusion. The fact of the matter is that a /poorly engineered/ gas tank is much more prone to problems, whether it's in an inexpensive car or a high end one. You're drawing poor conclusions based on even poorer reasoning. Your negative experience with some software routers does not mean that they are all crap, just as my negative experience with some hardware routers does not mean that they are all crap. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From rdobbins at arbor.net Thu Jul 15 11:39:30 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 15 Jul 2010 16:39:30 +0000 Subject: Vyatta as a BRAS In-Reply-To: <201007151633.o6FGXAbJ011684@aurora.sol.net> References: <201007151633.o6FGXAbJ011684@aurora.sol.net> Message-ID: <198FA3B2-DBD5-4B33-9BE9-59B3A472AA3F@arbor.net> On Jul 15, 2010, at 11:33 PM, Joe Greco wrote: > Provided with a counterexample where this isn't true, you simply ignore it. I've yet to see a counterexample involving a software-based edge router in a realistic testbed environment being deliberately packeted in order to cause an availability hit - apologies if I've missed one, mind. > Your arguments revolve around "My Ford Pinto's gas tank once exploded on me and it happened to other people too, therefore all inexpensive cars have unsafe gas tanks." Actually, it's more along the lines of, "I've seen multiple accidents involving multiple brands/models of economy-class automobiles in which the passengers were grievously-injured or worse, while also having observed passengers walking away from similar accidents in similar circumstances involving heavier, more sturdily-built vehicles." ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From LarrySheldon at cox.net Thu Jul 15 11:43:01 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 15 Jul 2010 11:43:01 -0500 Subject: A question for the house and the moderators (was Re: Vyatta as a BRAS) In-Reply-To: <198FA3B2-DBD5-4B33-9BE9-59B3A472AA3F@arbor.net> References: <201007151633.o6FGXAbJ011684@aurora.sol.net> <198FA3B2-DBD5-4B33-9BE9-59B3A472AA3F@arbor.net> Message-ID: <4C3F3A95.9050509@cox.net> On 7/15/2010 11:39, Dobbins, Roland wrote: > > On Jul 15, 2010, at 11:33 PM, Joe Greco wrote: > >> Provided with a counterexample where this isn't true, you simply ignore it. > > > I've yet to see a counterexample involving a software-based edge router in a realistic testbed environment being deliberately packeted in order to cause an availability hit - apologies if I've missed one, mind. > >> Your arguments revolve around "My Ford Pinto's gas tank once exploded on me and it happened to other people too, therefore all inexpensive cars have unsafe gas tanks." > > Actually, it's more along the lines of, "I've seen multiple accidents involving multiple brands/models of economy-class automobiles in which the passengers were grievously-injured or worse, while also having observed passengers walking away from similar accidents in similar circumstances involving heavier, more sturdily-built vehicles." > > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > > -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From LarrySheldon at cox.net Thu Jul 15 11:46:13 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Thu, 15 Jul 2010 11:46:13 -0500 Subject: A question for the house and the moderators (was Re: Vyatta as a BRAS) In-Reply-To: <198FA3B2-DBD5-4B33-9BE9-59B3A472AA3F@arbor.net> References: <201007151633.o6FGXAbJ011684@aurora.sol.net> <198FA3B2-DBD5-4B33-9BE9-59B3A472AA3F@arbor.net> Message-ID: <4C3F3B55.3050904@cox.net> Oops--itch trigger finger.... [a round of the on-going and growing tedious micturation tournament] Is this squalling fest really more "operational" than a conversation dealing with a disabling spam attack? Really? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From rdobbins at arbor.net Thu Jul 15 11:48:06 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 15 Jul 2010 16:48:06 +0000 Subject: A question for the house and the moderators (was Re: Vyatta as a BRAS) In-Reply-To: <4C3F3A95.9050509@cox.net> References: <201007151633.o6FGXAbJ011684@aurora.sol.net> <198FA3B2-DBD5-4B33-9BE9-59B3A472AA3F@arbor.net> <4C3F3A95.9050509@cox.net> Message-ID: <0AA251C0-B5D5-4649-B6EA-62C6FD2B148D@arbor.net> On Jul 15, 2010, at 11:43 PM, Larry Sheldon wrote: > A democracy is two wolves and a lamb voting on what to have for dinner. Under the assumption that I'm meant to be fulfilling the role of the lamb, I know when I'm outvoted, heh. This topic is obviously past its shelf-life. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From nick.boyce at gmail.com Thu Jul 15 12:10:32 2010 From: nick.boyce at gmail.com (Nick Boyce) Date: Thu, 15 Jul 2010 18:10:32 +0100 Subject: [Bruce Hoffman] Thank-you for your recent participation. In-Reply-To: <4C3A8747.4090007@west.net> References: <86k4pozfe2.fsf@seastrom.com> <20100627182234.GB24403@gsp.org> <20100707140055.GA11359@gsp.org> <4C3A8747.4090007@west.net> Message-ID: On Mon, Jul 12, 2010 at 4:08 AM, Jay Hennigan wrote: > On 7/10/10 7:26 AM, Nick Boyce wrote: > >> I tend to assume that when I get an email allegedly from Company A >> (Internap) but actually sent by Company/Domain B (iContact), inviting >> me to enter all kinds of sensitive information about my organisation's >> operations into a "survey" hosted at Domain C (Zoomerang) ... then >> I'm being socially engineered by a Bad Guy, and I just press "delete". [...] > Rather than JHD (just hit delete) please try to reach out to someone > with technical clue at Company A or their upstream. Actually I _do_ do that quite a lot .... much to the amusement of some colleagues who think I complain too much. I'm quite used to contacting abuse@ and security@ teams anyway, so I often just treat these emails as a security issue, and forward them to security at CompanyA stating "Someone is sending email claiming to be from your company but it looks as if they're actually a completely different organisation. You may want to look into this as a possibly fraudulent activity against your employer. If however these emails are genuine then my apologies for wasting your time, but you may wish to forward my email to the relevant marketing department, pointing out how ineffective their campaign will be, due to the number of recipients who will treat it as a scam." However, as I'm sure you will have found, this often results in either (a) no response, or (b) a tedious, painful response dialog with various Company A staff who just don't get it. Only rarely do you get to talk to Someone With A Clue who gets the required policy changes implemented. >> I do this, even when Company A is a big well-known company (e.g. Sun >> ... it's happened) > > Sun giving away Dell laptops? ?O RLY? [grin] .... no, in their case it was a free iPod as I recall ... wouldn't have minded one of those, except that they won't play OGG media. > Shaming them is IMHO more effective, although it takes more work. Trouble is, they're almost always outsourcing their campaigns, as part of the western world's obsession with cost cutting by eliminating in-house staff. The MBA whizz-kids who dream it up just won't listen to anything but bottom line. "Incorrect domain name on the sender address ?", they say, "... I'm afraid I don't see the significance. I'm telling you now that ACME Mailshot Campaigns And Surveys Inc. is fully authorised by us". [subtext: my bonus depends on the resulting "savings"] But yes, as and when I can bear it, I do what you suggest. Keep the faith, Nick -- /* affect != effect */ void affect(int *thing,int effect) { *thing += effect; } From dmburgess at linktechs.net Thu Jul 15 12:22:52 2010 From: dmburgess at linktechs.net (Dennis Burgess) Date: Thu, 15 Jul 2010 12:22:52 -0500 Subject: Vyatta as a BRAS References: <201007141517.o6EFHmhI013994@aurora.sol.net> Message-ID: <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> RouterOS is a software based router, we have them all over the world as CORE and EDGE routers to networks. Some of our hardware can hit multi-gig speeds, BGP etc. We commonly replace 7206VXRs. Does some other form of DoS attack have an effect on it, sure, but as long as you have enough CPU to weather the storm you normally don't have major issues. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Joe Greco [mailto:jgreco at ns.sol.net] Sent: Wednesday, July 14, 2010 10:18 AM To: Dobbins, Roland Cc: NANOG list Subject: Re: Vyatta as a BRAS > On Jul 14, 2010, at 5:45 AM, Joe Greco wrote: > > That's just a completely ignorant statement to make. > > It's based on a great deal of real-world experience; I'm sorry you consider= > that to be 'ignorant'. You're speaking to someone who has extensive experience with "software" based routers, and you're failing to acknowledge the upsides of such an architecture, when I've already conceded the upsides of a hardware architecture. > > I notice in particular how carefully you qualify that with "[w]hen BCPs = > are=20 > > followed"; the fact that hardware router manufacturers have declared > > everything and anything that derails their bullet trains as "not a > > BCP" is a perfect example of this deceptive sort of misinformation. > > Anti-spoofing, iACLs, CoPP (or its equivalent on non-Cisco platforms), et. = > al. aren't 'misinformation'. They're useful, proven techniques/features wh= > ich any operator ought to implement. The things that any given use scenario ought to implement are highly dependent on the actual application. > > There are plenty of FreeBSD based devices out there that are passing > > tons of traffic; almost any of them are more competent than any Cisco > > router I'm aware of when hitting them directly with traffic > > Then your experience of Cisco routers (and/or those from other vendors) mus= > t be limited to the lower-end platforms; I can assure you that faster Cisco= > boxes such as ASRs, GSRs, CRSes, and so forth are in another league entire= > ly, and can handle mpps of to-us traffic, when properly configured. Softwa= > re-based routers simply can't do that; it's not an indictment of them, it's= > just that they aren't suited to purpose, just as station wagons generally = > aren't to be found in the Indy 500. So your solution is to keep throwing heavier hardware at the problem until it works. Okay, I see that. Now, let me quote from a different message: > If maintaining availability is important, then hardware-based (semantic > hairsplitting aside) devices are a requirement. The truth is that you can keep throwing CPU at a problem as well. I can size a software based router such that it can remain available. This is neither new nor exciting technology. Luigi Rizzo was doing extensive work on this about a decade ago: he took an Athlon 750 platform with 4 100Mbit ethernet interfaces in it (Athlon 750 = 1999 tech) and was able to exceed 100Mbps levels without a problem. The UNIX based platforms have extensive capabilities to defend against attack, even without a firewall. As with a hardware based platform, there are both good things and bad things you can do that will impact availability. Software based platforms have an incredible edge in areas that hardware based platforms don't, including capex and the ability to find replacement parts after a disaster. I spent some time after the Haiti quake getting FreeBSD-based routers up and running, a task made easier because it's a lot easier to find a working PC and scavenge some network cards than it is to find a working Cisco router in a city where all inbound and outbound transportation is paralyzed. You can continue to defend your position, of course, but it's just looking a bit silly. A wise engineer knows that there are several ways to tackle any task, and "one tool for every job" is not a sound policy. If you'd like to revise your position to "Cisco and Juniper software based solutions are underpowered PoS", that's probably a defensible position, and you won't get any argument from me. Please don't generalize such a position into all software based devices, though. Overall, there are a lot more software based routers out there than hardware based devices. Your cablemodem, your ADSL modem, your wifi access point, all these are probably software based devices. Some of them will melt under a too-great load. Some won't. This is a function of many different factors. There is nothing inherent in a software-based device that's going to make it fail under load - just as there's nothing inherent in a hardware-based device that's going to make it succeed (which is why you have to qualify your defense of these with "must follow BCP"). It's the related engineering that ultimately determines whether or not it all works out. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From sil at infiltrated.net Thu Jul 15 12:46:24 2010 From: sil at infiltrated.net (J. Oquendo) Date: Thu, 15 Jul 2010 13:46:24 -0400 Subject: On another security note... (of sorts) Message-ID: <4C3F4970.2060800@infiltrated.net> While on another list (security list that some of you guys are on) there is a discussion about a particular botnet that the "BP approach" of containment is occurring. Not a big deal, we've all seen them from time to time. I read with interest on how volunteers are scrambling to contain this botnet. Mind you, most of us work and do this (security tidbits) at the same time while we work. Many of us do it for self-satisfaction, for learning, for maybe naively thinking we can help make the net a better place (INSERT_SAPPY_SONG_THERE). I just can't help but taking the 50k foot view here... Why is it that network operators can't work together on instances like this and have a "botnet killswitch" framework in order. Now I know I will see the ramblings of "Why should I waste my time (spend my money)" or "This is not an operational post take a hike" and other similar posting however, this IS related to 'many-a-networks' that could be avoided. RFP anyone.. Botnet Mitigation for Networks surely collectively it would and CAN work. Is it going to take an act of someone 'pwning' everyone's account here before someone else says: "We should work together" or will go in one ear and out the other while misfits run around emptying out accounts, causing businesses to go under. Some of you guys have the most amazing minds and have literally been the glue for what we use (the Internet) and some have been the laziest admins I've seen on the planet. Surely even a minimal framework to submit "validated" botnet distribution sites is something everyone can collectively do. Nipping at the head surely minimizes the overall damage these things are doing. Now I do know some would come back and state the oft-said "Why bother! ... Dude fast-flux, etc." We know... To those, why respond. How about solutions from those who are controlling how traffic on the net flows. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From Valdis.Kletnieks at vt.edu Thu Jul 15 13:03:39 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 15 Jul 2010 14:03:39 -0400 Subject: On another security note... (of sorts) In-Reply-To: Your message of "Thu, 15 Jul 2010 13:46:24 EDT." <4C3F4970.2060800@infiltrated.net> References: <4C3F4970.2060800@infiltrated.net> Message-ID: <12382.1279217019@localhost> On Thu, 15 Jul 2010 13:46:24 EDT, "J. Oquendo" said: > RFP anyone.. Botnet Mitigation for Networks surely collectively it would > and CAN work. A nice idea, but consider if a more automated tool/system was created to behead a botnet (50,000 null0 routes to blackhole all the nodes? Or accept collateral damage? etc). Now consider that jujutsu is designed around using the opponent's energy against him. How can this possibly go wrong? :) Hint: Why do many sites refuse to accept automated BGP feeds from Cymru's bogon list or RIR services? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From kornholijo at gmail.com Thu Jul 15 13:17:19 2010 From: kornholijo at gmail.com (Kornelijus Survila) Date: Thu, 15 Jul 2010 13:17:19 -0500 Subject: On another security note... (of sorts) In-Reply-To: <12382.1279217019@localhost> References: <4C3F4970.2060800@infiltrated.net> <12382.1279217019@localhost> Message-ID: On Thu, Jul 15, 2010 at 1:03 PM, wrote: > > Hint: Why do many sites refuse to accept automated BGP feeds from Cymru's > bogon list or RIR services? > The same reason many sites don't follow best practices and let spoofed packets leave their network, etc? From lukasz at bromirski.net Thu Jul 15 13:24:06 2010 From: lukasz at bromirski.net (=?ISO-8859-2?Q?=A3ukasz_Bromirski?=) Date: Thu, 15 Jul 2010 20:24:06 +0200 Subject: Vyatta as a BRAS In-Reply-To: <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> References: <201007141517.o6EFHmhI013994@aurora.sol.net> <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> Message-ID: <4C3F5246.8080606@bromirski.net> On 2010-07-15 19:22, Dennis Burgess wrote: > RouterOS is a software based router, we have them all over the world as > CORE and EDGE routers to networks. Wonderful, congratulations. > Some of our hardware can hit multi-gig speeds, BGP etc. Same can do your competitors. > We commonly replace 7206VXRs. Sad story, really. And I bet 7200VXRs commonly replace RouterOS. > Does some other form of DoS attack have an effect on it, sure, but > as long as you have enough CPU to weather the storm you normally > don't have major issues. Sure, a lot of people were at this point of their learning curve, pretty sure that they will withstand anything with their multi-GHz, multi-core CPUs. Then they met real world, or as it is often said, real world met them. (and I'm all for FreeBSD boxes, don't get me wrong, the whole point of this discussion is that either you're doing hardware forwarding and you're pretty safe [unfortunately often with a lot of caveats, but still], or you're doing software forwarding and you have a nice attack vector open for anyone willing) -- "Everything will be okay in the end. | ?ukasz Bromirski If it's not okay, it's not the end." | http://lukasz.bromirski.net From michael.holstein at csuohio.edu Thu Jul 15 13:40:50 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Thu, 15 Jul 2010 14:40:50 -0400 Subject: On another security note... (of sorts) In-Reply-To: <4C3F4970.2060800@infiltrated.net> References: <4C3F4970.2060800@infiltrated.net> Message-ID: <4C3F5632.4080408@csuohio.edu> > Why is it that network operators can't work together > on instances like this and have a "botnet killswitch" Trust (or lack thereof). Cheers, Michael Holstein Cleveland State University From markk at arin.net Thu Jul 15 15:45:09 2010 From: markk at arin.net (Mark Kosters) Date: Thu, 15 Jul 2010 16:45:09 -0400 Subject: ARIN's Whois-RWS Directory Service Available 17 July Message-ID: <20100715204509.GD9379@arin.net> ----- Forwarded message from Member Services ----- From: Member Services Date: Thu, 15 Jul 2010 16:03:37 -0400 To: "arin-announce at arin.net" Subject: [arin-announce] ARIN's Whois-RWS Directory Service Available 17 July ARIN is pleased to announce that it will deploy its Whois-RWS service on 17 July 2010. We have corrected the issues that impacted the first release and are now able to bring you the following services that provide the general public with access to ARIN's registration data: * a RESTful Web Service (RWS) * a NICNAME/WHOIS port 43 service * a user-friendly web site (http://whois.arin.net) When using the Whois-RWS you will notice some differences in behavior for certain queries and corresponding result sets on the NICNAME/WHOIS port 43 service. The detailed documentation on these differences has been updated and is now available at: https://www.arin.net/resources/whoisrws/whois_diff.html ARIN?s Directory Service for registration data has used the NICNAME/WHOIS protocol since its inception. The limitations of the NICNAME/WHOIS protocol are well known and documented in RFC3912. Whois-RWS was created as an alternative to the ARIN Whois and will provide much richer functionality and capability to the community. ARIN continues to welcome community participation on the Whois-RWS mailing list, and we invite you to subscribe and share your experience and feedback about the new service: http://lists.arin.net/mailman/listinfo/arin-whoisrws Regards, Mark Kosters Chief Technical Officer American Registry for Internet Numbers (ARIN) ----- End forwarded message ----- From mlarson at verisign.com Thu Jul 15 15:51:35 2010 From: mlarson at verisign.com (Matt Larson) Date: Thu, 15 Jul 2010 16:51:35 -0400 Subject: First signed root zone published Message-ID: <20100715205135.GC23132@dul1mcmlarson-l1.vcorp.ad.vrsn.com> I am pleased to report that the first fully validatable production signed root zone, with SOA serial number 2010071501, was published and began rolling out to the root servers at 1625 UTC. More details to follow in a formal update. Matt ...on behalf of the root DNSSEC design team From mlarson at verisign.com Thu Jul 15 15:54:15 2010 From: mlarson at verisign.com (Matt Larson) Date: Thu, 15 Jul 2010 16:54:15 -0400 Subject: First signed root zone published In-Reply-To: <20100715205135.GC23132@dul1mcmlarson-l1.vcorp.ad.vrsn.com> References: <20100715205135.GC23132@dul1mcmlarson-l1.vcorp.ad.vrsn.com> Message-ID: <20100715205415.GF23132@dul1mcmlarson-l1.vcorp.ad.vrsn.com> On Thu, 15 Jul 2010, Matt Larson wrote: > [...] was published and began rolling out to the root servers at 1625 UTC. Make that 1650 UTC... (The perils of staging email.) From mlarson at verisign.com Thu Jul 15 16:01:53 2010 From: mlarson at verisign.com (Matt Larson) Date: Thu, 15 Jul 2010 17:01:53 -0400 Subject: First signed root zone published In-Reply-To: <20100715205415.GF23132@dul1mcmlarson-l1.vcorp.ad.vrsn.com> References: <20100715205135.GC23132@dul1mcmlarson-l1.vcorp.ad.vrsn.com> <20100715205415.GF23132@dul1mcmlarson-l1.vcorp.ad.vrsn.com> Message-ID: <20100715210152.GG23132@dul1mcmlarson-l1.vcorp.ad.vrsn.com> On Thu, 15 Jul 2010, Matt Larson wrote: > On Thu, 15 Jul 2010, Matt Larson wrote: > > [...] was published and began rolling out to the root servers at 1625 UTC. > > Make that 1650 UTC... > > (The perils of staging email.) Make that 2050 UTC (1650 EDT). (The perils of a stressful deployment and time zone conversion.) From pauldotwall at gmail.com Thu Jul 15 19:28:44 2010 From: pauldotwall at gmail.com (Paul WALL) Date: Thu, 15 Jul 2010 20:28:44 -0400 Subject: Vyatta as a BRAS In-Reply-To: <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> References: <201007141517.o6EFHmhI013994@aurora.sol.net> <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> Message-ID: On Thu, Jul 15, 2010 at 1:22 PM, Dennis Burgess wrote: > RouterOS is a software based router, we have them all over the world as > CORE and EDGE routers to networks. You keep using that word ("CORE"). I do not think it means what you think it means. Drive Slow, DoS Slower, Paul Wall From kornholijo at gmail.com Thu Jul 15 20:20:44 2010 From: kornholijo at gmail.com (Kornelijus Survila) Date: Thu, 15 Jul 2010 20:20:44 -0500 Subject: [c-nsp] L2VPN with IP address In-Reply-To: References: Message-ID: The multihop BGP solution might be the best one with least overhead; however you should be able to use a GRE tunnel if you still want to do this: interface Tunnel1 ip address 10.10.10.1 255.255.255.252 tunnel source FastEthernet0/0 tunnel destination small.router.ip interface Tunnel1 ip address 10.10.10.2 255.255.255.252 tunnel source FastEthernet0/0 tunnel destination big.router.ip -k On Thu, Jul 15, 2010 at 7:40 PM, Pshem Kowalczyk wrote: > Hi, > > I have a situation, where a customer wants a full BGP table > (persuasion failed already), but is connected to small router (2821), > with not enough memory to get anywhere near full table. I have few > other routers (ASR1K, 7600) that would normally be used for that, but > are in far-away locations. Of course I can set up a local BGP session > and then add a multihop one for the full feed, but that doesn't seem > like an elegant solution any more. All the routers run MPLS, so if I > could get a xconnect going between one of the bigger boxes and the > small PE, without actually wasting port on the bigger router (by > having some sort of logical interface) then I could run the BGP > session directly. I had a look on Cisco website, but either it's not > possible or that kind of bridging has a special name that I can't pin > down. If you've heard of such feature - please let me know. > > kind regards > Pshem > _______________________________________________ > cisco-nsp mailing list cisco-nsp at puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > From jared at puck.nether.net Thu Jul 15 20:43:34 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 16 Jul 2010 10:43:34 +0900 Subject: Vyatta as a BRAS In-Reply-To: References: <201007141517.o6EFHmhI013994@aurora.sol.net> <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> Message-ID: <2931F4B5-BE11-42F2-971D-1F464DDDFC39@puck.nether.net> I have that same problem with vendors that insist that there is a core vs customer vs peering edge set in networks. If a customer has 10g to a specific peer why should one not place them on the same device, ASIC, linecard, usw.... Core today means something that is 200g+/slot capable IMHO. Anything else is non-core. Jared Mauch On Jul 16, 2010, at 9:28 AM, Paul WALL wrote: > On Thu, Jul 15, 2010 at 1:22 PM, Dennis Burgess wrote: >> RouterOS is a software based router, we have them all over the world as >> CORE and EDGE routers to networks. > > You keep using that word ("CORE"). I do not think it means what you > think it means. > > Drive Slow, DoS Slower, > Paul Wall From tglassey at earthlink.net Thu Jul 15 21:46:59 2010 From: tglassey at earthlink.net (todd glassey) Date: Thu, 15 Jul 2010 19:46:59 -0700 Subject: On another security note... (of sorts) In-Reply-To: <4C3F5632.4080408@csuohio.edu> References: <4C3F4970.2060800@infiltrated.net> <4C3F5632.4080408@csuohio.edu> Message-ID: <4C3FC823.3040005@earthlink.net> On 7/15/2010 11:40 AM, Michael Holstein wrote: >> Why is it that network operators can't work together >> on instances like this and have a "botnet killswitch" > Trust (or lack thereof). If networking tools were designed properly it wouldn't matter... its about designing tools for the intentional creation of evidence and rather than arguing with the suits about what is necessary just make them create a list of evidence aspects and then we implement that. This isnt complex its about building systems which are better (more trustworthy) than their operators. Just my two cents. Todd Glassey > Cheers, > > Michael Holstein > Cleveland State University > > From hrlinneweh at sbcglobal.net Thu Jul 15 22:57:15 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Thu, 15 Jul 2010 20:57:15 -0700 (PDT) Subject: Vyatta as a BRAS In-Reply-To: References: <201007141517.o6EFHmhI013994@aurora.sol.net> <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> Message-ID: <385099.56910.qm@web180304.mail.gq1.yahoo.com> Edge Router Definition: - A term used in asynchronous transfer mode (ATM) networks, an edge router is a device that routes data packets between one or more local area networks (LANs) and an ATM backbone network, whether a campus network or a wide area network (WAN). An edge router is an example of an edge device and is sometimes referred to as a boundary router. An edge router is sometimes contrasted with a core router, which forwards packets to computer hosts within a network (but not between networks). Core Router: - A core router is a router that forwards packets to computer hosts within a network (but not between networks). A core router is sometimes contrasted with an edge router, which routes packets between a self-contained network and other outside networks along a network backbone. Can we get a consensus definition on these definition's and what hardware vender's make edge routers and what hardware vender's make core routers. I think this will make us all, have the same understanding. -henry ________________________________ From: Paul WALL To: Dennis Burgess Cc: nanog at nanog.org Sent: Thu, July 15, 2010 5:28:44 PM Subject: Re: Vyatta as a BRAS On Thu, Jul 15, 2010 at 1:22 PM, Dennis Burgess wrote: > RouterOS is a software based router, we have them all over the world as > CORE and EDGE routers to networks. You keep using that word ("CORE"). I do not think it means what you think it means. Drive Slow, DoS Slower, Paul Wall From uri.joskovitch at telrad.com Fri Jul 16 00:28:27 2010 From: uri.joskovitch at telrad.com (Uri Joskovitch) Date: Fri, 16 Jul 2010 08:28:27 +0300 Subject: ATM STM4/OC12 support on RNC's References: <4C05458E.1050200@rollernet.us> <02755D474772E74E97471FC5BBE7641B031F4934@TLRD-MAIL1.Telrad.co.il> <51A20C9C-B20F-4DDC-9F19-19F666161DC6@gmail.com> Message-ID: <02755D474772E74E97471FC5BBE7641B033902F4@TLRD-MAIL1.Telrad.co.il> Hi All I am wondering, do you see in the Wireless Backhaul application, RNC's that support in ATM services OC12/STM4 ports? (not only OC3/STM1) If answer is yes does they support mapping of STS3c only?, STS12c only?, Or both? Thanks Uri From swmike at swm.pp.se Fri Jul 16 00:45:22 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 16 Jul 2010 07:45:22 +0200 (CEST) Subject: ATM STM4/OC12 support on RNC's In-Reply-To: <02755D474772E74E97471FC5BBE7641B033902F4@TLRD-MAIL1.Telrad.co.il> References: <4C05458E.1050200@rollernet.us> <02755D474772E74E97471FC5BBE7641B031F4934@TLRD-MAIL1.Telrad.co.il> <51A20C9C-B20F-4DDC-9F19-19F666161DC6@gmail.com> <02755D474772E74E97471FC5BBE7641B033902F4@TLRD-MAIL1.Telrad.co.il> Message-ID: On Fri, 16 Jul 2010, Uri Joskovitch wrote: > I am wondering, do you see in the Wireless Backhaul application, RNC's > that support in ATM services OC12/STM4 ports? (not only OC3/STM1) If you need that much capacity, go for GigE instead, you'll be happy for it in the long run. > If answer is yes does they support mapping of STS3c only?, STS12c only?, > Or both? I'm no ATM expert, but I've never seen ATM be anything else than concatenated, so I'd say vc-4-4c (STM4) and plain vc4 (STM1). -- Mikael Abrahamsson email: swmike at swm.pp.se From butche at butchevans.com Fri Jul 16 02:10:55 2010 From: butche at butchevans.com (Butch Evans) Date: Fri, 16 Jul 2010 02:10:55 -0500 Subject: ISC DHCPD Message-ID: <1279264255.3118.170.camel@localhost.localdomain> I have a cisco cmts that forwards dhcp requests to an ISC dhcp server. I have a working configuration for this. I am trying to set up ISC DHCPD so that it can handle multiple shared-networks. I cannot seem to get this working correctly. If there is an expert "in the house" who can offer me a few minutes of your time to look over a configuration for me, please send me a phone number/email offlist and I'll discuss specifics. -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From luca.simonetti at enginenetworks.net Fri Jul 16 02:31:49 2010 From: luca.simonetti at enginenetworks.net (Engine Networks | Luca Simonetti) Date: Fri, 16 Jul 2010 09:31:49 +0200 Subject: [c-nsp] L2VPN with IP address In-Reply-To: References: Message-ID: <4C400AE5.4000105@enginenetworks.net> Just pay attention to MTU with GRE tunnel and packet fragmentation. -- Luca Simonetti ________ Engine Networks http://www.enginenetworks.net Datacenter GENEVA 1: Rue de la Conf?d?ration, 6 1204 Geneve - CH Datacenter ZURICH 1: Josefstrasse, 225 - 8005 Z?rich - CH Datacenter MILAN 1: Caldera, 21 - 20100 Milan - IT From sean at donelan.com Fri Jul 16 02:49:45 2010 From: sean at donelan.com (Sean Donelan) Date: Fri, 16 Jul 2010 03:49:45 -0400 (EDT) Subject: On another security note... (of sorts) In-Reply-To: <12382.1279217019@localhost> References: <4C3F4970.2060800@infiltrated.net> <12382.1279217019@localhost> Message-ID: On Thu, 15 Jul 2010, Valdis.Kletnieks at vt.edu wrote: > On Thu, 15 Jul 2010 13:46:24 EDT, "J. Oquendo" said: >> RFP anyone.. Botnet Mitigation for Networks surely collectively it would >> and CAN work. > > A nice idea, but consider if a more automated tool/system was created to > behead a botnet (50,000 null0 routes to blackhole all the nodes? Or accept > collateral damage? etc). Now consider that jujutsu is designed around using > the opponent's energy against him. > > How can this possibly go wrong? :) Damned if they do, Damned if they don't. It seems like every 4-6 weeks people alternate between ISPs are bad because they don't try to prevent X, Y or Z; and then 4-6 weeks later ISPs are bad because they tried to prevent A, B or C. It doesn't matter what A, B, C or X, Y, Z are; it must be the ISPs fault. Everyone agrees that ISPs are bad, they just disagree about what ISPs are supposed to do about whatever. And so it goes... From Valdis.Kletnieks at vt.edu Fri Jul 16 08:02:42 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 16 Jul 2010 09:02:42 -0400 Subject: Vyatta as a BRAS In-Reply-To: Your message of "Thu, 15 Jul 2010 20:57:15 PDT." <385099.56910.qm@web180304.mail.gq1.yahoo.com> References: <201007141517.o6EFHmhI013994@aurora.sol.net> <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> <385099.56910.qm@web180304.mail.gq1.yahoo.com> Message-ID: <55112.1279285362@localhost> On Thu, 15 Jul 2010 20:57:15 PDT, Henry Linneweh said: Your definitions seem to be rather ATM-specific, which may be a bit of a problem in a world dominated by Ethernet... > Can we get a consensus definition on these definition's and what hardware > vender's make edge routers and what hardware vender's make core routers. I got a router, it's got 5-6 10GE interfaces talking to other routers on my network backbone, and a bunch of 10GE links to end-user-facing aggregation switches. Since it's only forwarding inside my network, it's a core router by your definition. I now turn up an identical hardware 10GE link - connected to Level3. I just became an edge router by your definition since I'm talking to another network. (I know, I probably don't want to do that - but I *could*, maybe even without a full BGP feed if the routing situation allows. The point is the definition is busticated). Adding to the confusion is the fact that the edge routers of some large providers need more capacity than the core routers of smaller organizations.... Maybe we need to ditch the terms edge and core, and instead talk about: 1/4" plastic tubing - http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_nut.jpg garden hose - http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800px-Garden_hose.jpg fire hose - http://www.firetrainingcenter.com/images/FireHoseStreams.jpg NYC Delaware Aqueduct - http://www.allpropertymanagement.com/blog/2010/02/09/worlds-awesome-tunnels/ Everybody good with that? ;) (Man.. it *leaks* 15 million gallons a day. That's capacity. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sil at infiltrated.net Fri Jul 16 08:21:45 2010 From: sil at infiltrated.net (J. Oquendo) Date: Fri, 16 Jul 2010 09:21:45 -0400 Subject: On another security note... (of sorts) In-Reply-To: References: <4C3F4970.2060800@infiltrated.net> <12382.1279217019@localhost> Message-ID: <4C405CE9.9040305@infiltrated.net> Sean Donelan wrote: > > Damned if they do, Damned if they don't. > > It seems like every 4-6 weeks people alternate between ISPs are bad > because they don't try to prevent X, Y or Z; and then 4-6 weeks later > ISPs are bad because they tried to prevent A, B or C. It doesn't matter > what A, B, C or X, Y, Z are; it must be the ISPs fault. > > Everyone agrees that ISPs are bad, they just disagree about what ISPs > are supposed to do about whatever. > > And so it goes... > > Odd, I definitely don't recall saying outright ISP's are bad. More to the tune of "ISP's can do more given they're in the best position to do so..." which brings things full-circle, what can be done? How about an RFC, then building from there. Anyone can comment about the potential of "I'm not adding hundreds of thousands of null0's to my Cisco!@" and the point would be missed. As an NSP/NAP/ISP (pick your poison), you have the potential to see where your machines are connecting to. And I don't mean snooping their traffic outright, but its as simple as keeping tabs on a "destination", if you KNOW and it has been CONFIRMED, that the destination is a known purveyor "of un-fine" goods, wouldn't you like to potentially help your clients before they become zombiefied? If there was a method for operators to obtain information and share it, (think an unbiased, validated, "most wanted" list) do you really want to state that you wouldn't care about it, you couldn't use it. Surely I'd like to use something similar and if I were in a position to do something on a massive scale to eliminate bad traffic from 1) reaching my customers (since money is obvious the main concern) and 2) from making sure my customers don't affect your customers (YOUR money), I would jump up and down on it doing whatever I could. So it's not the ISP's are bad (at least to me they're not), it's more like "ISP OPERATORS/OWNERS are too busy fighting AGAINST things like this from happening, often spending more time and effort against it, then they are trying to collaboratively solve a problem." Analogy: "ALL gunmakers have seen their firearms mistakenly fire off at will (purposefully or accidentally). They all agree that by putting a safety mechanism, the rates of fatalities and injuries will go down. Some choose not to, because after all, they would need to spend more money to do so... Many protest against it: Smith and Wesson doesn't have that, why should I?!... Fatalities continue and gunmakers complain: All gunmakers are bad right, sure... uh-huh" What's wrong with that analogy. What about responsibility. Forget the politricks for a moment and think about the *ultimate* bottom line here... Would you like to prevent someone from possibly wrecking havoc on your personal bank account? Remember, what goes around comes around. You're not only doing neighbors (peers) a favor but if collectively the same approach was taken by many, there would be less "dirty traffic" around. No one on this list can seriously counter this claim. We can get into: "oh yea smart ass... They could encrypt!@... They could fast flux!!!, they could..." Guess what? What is anyone going to do when they can't connect? E.g: src(my_compromised_machine):port --> dst(known_dirty_host_on_X_net) My_NSP(hourly) ---> Mega_Peer_Dirty_Host_Watcher --> get_list_apply_filter Result: src(my_compromised_machine):port --> dst(known_dirty_host_on_X_net) --> My_Provider --> ::1 Anyway, just a thought, maybe a far out there thought, but I truly believe it can be done at an upstream level with little to no cost. I believe it costs more to sit around complaining and doing nothing than it does when you start losing customers because someone compromised them and wiped out their accounts driving them to bankruptcy. (http://krebsonsecurity.com/2010/02/n-y-firm-faces-bankruptcy-from-164000-e-banking-loss/) -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From jgreco at ns.sol.net Fri Jul 16 08:53:04 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 16 Jul 2010 08:53:04 -0500 (CDT) Subject: Vyatta as a BRAS In-Reply-To: <55112.1279285362@localhost> Message-ID: <201007161353.o6GDr468027126@aurora.sol.net> > I got a router, it's got 5-6 10GE interfaces talking to other routers on > my network backbone, and a bunch of 10GE links to end-user-facing aggregation > switches. Since it's only forwarding inside my network, it's a core router > by your definition. > > I now turn up an identical hardware 10GE link - connected to Level3. I just > became an edge router by your definition since I'm talking to another network. > (I know, I probably don't want to do that - but I *could*, maybe even without > a full BGP feed if the routing situation allows. The point is the definition > is busticated). > > Adding to the confusion is the fact that the edge routers of some large providers > need more capacity than the core routers of smaller organizations.... There's a problem here in that some people want 'core router' to mean 'biggest fscking router', while other people want a functional definition that explains a router's role in the design of a network. For an enterprise, for example, it doesn't make sense for them to have a router in the middle of their network and then tell them "but you can not call it your core router, because that term is reserved for routers with 200g or more capacity per slot (Jared's def'n)." I'm going to submit that the "big fscking router" definition is stupid and meaningless, because today's big fscking router is tomorrow's small aggregation router, and then a few years later just a coffee table stand. Hello, 7513 from .. what, 1995? :-) A more customary understanding of border, core, etc., can be found in places like RFC4098. Generally speaking, a core router is an internal router, i.e. one that speaks only to other devices/endpoints/whatever in the same AS. Various refinements to the definition might want it to speak BGP, etc. That definition is very reasonable. A small enterprise with a DS3 to the 'net has a border router that connects them to their ISP, which connects to a firewall/IDS that protects their net, and then a core router that connects all their internal networks and links to the firewall for external connectivity. You could talk to most network engineers and they'd understand the terminology without further explanation. There are of course problems with the core and border definitions as well, of course, such as what happens when you connect a core router interface to an upstream and you wind up with a mongrel. However, the "core means bfr" definition strikes me as singularly useless and something that's really more marketingspeak from router vendors who would like you to think of these routers powering the core of the Internet, or whatever. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From lowen at pari.edu Fri Jul 16 09:03:15 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 16 Jul 2010 10:03:15 -0400 Subject: Vyatta as a BRAS In-Reply-To: <4C3F5246.8080606@bromirski.net> References: <201007141517.o6EFHmhI013994@aurora.sol.net> Message-ID: <201007161003.16090.lowen@pari.edu> On Thursday, July 15, 2010 02:24:06 pm ?ukasz Bromirski wrote: > (and I'm all for FreeBSD boxes, don't get me wrong, the whole point > of this discussion is that either you're doing hardware forwarding > and you're pretty safe [unfortunately often with a lot of caveats, > but still], or you're doing software forwarding and you have > a nice attack vector open for anyone willing) This distills one of the points of view nicely. An operationally useful question is to ask (yourself) at what point (bandwidth- and type of traffic- speaking) does a particular box become vulnerable? 10Mb/s? 100Mb/s? 1Gb/s? 100Gb/s? Traffic directed at the control plane? Small packet traffic? Any traffic? Any box; hardware-based or software-based is irrelevant, because at some data volume all boxes become vulnerable; the variance is only in what volume the box can handle and how well the control plane is protected from that volume. Test with reasonable traffic loads (and drawing on the collective wisdom of this group as to what is 'reasonable' for a BRAS is good!), and derive conclusions that fit your need. Knowing these things allows you to scale your solution to avoid the majority of the problems and buy what fits your projected scale over the design life of the solution. Take a 2003-vintage OSR7609 (Sup2/MSFC2) still running 12.1E. Definitely a hardware-based router. Does it have a nice attack vector? Perhaps. Is this combination still in use? I'm not sure I want to know (Sup2/MSFC2 is, I know; the 12.1E part is the scary one). Hardware-based is not a magic bullet that destroys attack vectors dead in their tracks (as ?ukasz hints at with the parenthetical caveats remark). And software-based is not defenseless, either. From joe.abley at icann.org Fri Jul 16 09:35:39 2010 From: joe.abley at icann.org (Joe Abley) Date: Fri, 16 Jul 2010 14:35:39 +0000 Subject: Root Zone DNSSEC Deployment Technical Status Update Message-ID: Root Zone DNSSEC Deployment Technical Status Update 2010-07-16 This is the twelfth of a series of technical status updates intended to inform a technical audience on progress in signing the root zone of the DNS. RESOURCES Details of the project, including documentation published to date, can be found at . We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. FULL PRODUCTION SIGNED ROOT ZONE The transition from Deliberately-Unvalidatable Root Zone (DURZ) to production signed root zone took place on 2010-07-15 at 2050 UTC. The first full production signed root zone had SOA serial 2010071501. There have been no reported harmful effects. The root zone trust anchor can be found at . PLANNED DEPLOYMENT SCHEDULE Already completed: 2010-01-27: L starts to serve DURZ 2010-02-10: A starts to serve DURZ 2010-03-03: M, I start to serve DURZ 2010-03-24: D, K, E start to serve DURZ 2010-04-14: B, H, C, G, F start to serve DURZ 2010-05-05: J starts to serve DURZ 2010-06-16: First Key Signing Key (KSK) Ceremony 2010-07-12: Second Key Signing Key (KSK) Ceremony 2010-07-15: Distribution of validatable, production, signed root zone; publication of root zone trust anchor From lowen at pari.edu Fri Jul 16 09:42:40 2010 From: lowen at pari.edu (Lamar Owen) Date: Fri, 16 Jul 2010 10:42:40 -0400 Subject: On another security note... (of sorts) In-Reply-To: <4C3F5632.4080408@csuohio.edu> References: <4C3F4970.2060800@infiltrated.net> Message-ID: <201007161042.40853.lowen@pari.edu> On Thursday, July 15, 2010 02:40:50 pm Michael Holstein wrote: > > Why is it that network operators can't work together > > on instances like this and have a "botnet killswitch" > Trust (or lack thereof). That's certainly one of the biggest non-technical reasons. Others go by the acronyms NIH and NIMBY. But to me it boils down to some hard questions: what is a botnet, who gets to make that definition, what is a killswitch, and who is allowed to push it? I'm sure the collective wisdom here is capable of pulling the task off at least in theory; the hard part would be deciding whether to do it in hardware or software.... From bicknell at ufp.org Fri Jul 16 09:53:15 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 16 Jul 2010 07:53:15 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: Message-ID: <20100716145315.GA19935@ussenterprise.ufp.org> In a message written on Fri, Jul 16, 2010 at 02:35:39PM +0000, Joe Abley wrote: > The transition from Deliberately-Unvalidatable Root Zone (DURZ) to > production signed root zone took place on 2010-07-15 at 2050 UTC. The > first full production signed root zone had SOA serial 2010071501. There > have been no reported harmful effects. The root zone trust anchor can > be found at . Perhaps you could explain why the keys are being made available in formats that, as far as I can tell, no nameserver software on the planet uses? Pretty much 100% of the users will need a conversion from one of the 6 formats you provided, when you could have provided 6 example configs for the 6 most popular nameserver packages and covered 99% of the users with cut and paste. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From smb at cs.columbia.edu Fri Jul 16 10:12:08 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 16 Jul 2010 11:12:08 -0400 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: Message-ID: <1642C308-AC74-4C42-B215-207D8207B26B@cs.columbia.edu> Wonderful news! From mike-nanog at tiedyenetworks.com Fri Jul 16 10:23:04 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Fri, 16 Jul 2010 08:23:04 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <20100716145315.GA19935@ussenterprise.ufp.org> References: <20100716145315.GA19935@ussenterprise.ufp.org> Message-ID: <4C407958.3050303@tiedyenetworks.com> Leo Bicknell wrote: > > Perhaps you could explain why the keys are being made available in > formats that, as far as I can tell, no nameserver software on the > planet uses? Pretty much 100% of the users will need a conversion > from one of the 6 formats you provided, when you could have provided > 6 example configs for the 6 most popular nameserver packages and > covered 99% of the users with cut and paste. > > Ditto. Rapid deployment follows where cut-and-past mostly works to implement. (for better or worse) From cmadams at hiwaay.net Fri Jul 16 10:32:33 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 16 Jul 2010 10:32:33 -0500 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <20100716145315.GA19935@ussenterprise.ufp.org> References: <20100716145315.GA19935@ussenterprise.ufp.org> Message-ID: <20100716153233.GA1137974@hiwaay.net> Once upon a time, Leo Bicknell said: > Perhaps you could explain why the keys are being made available in > formats that, as far as I can tell, no nameserver software on the > planet uses? Pretty much 100% of the users will need a conversion > from one of the 6 formats you provided, when you could have provided > 6 example configs for the 6 most popular nameserver packages and > covered 99% of the users with cut and paste. There aren't 6 formats, there is just one format provided for the current trust anchor set: XML. A simple XSLT will transform it into any needed format. Individual trust anchors (there's only one at the moment) are provided in two formats: PKCS#10 (for signing) and X509 (signed by ICANN). There are also detached signatures (in PKCS#7 format for validation against the ICANN cert bundle and in OpenPGP format) of the XML anchor set file. This is all in the documentation in the same directory (in plain-text and HTML formats). -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From Ed.Lewis at neustar.biz Fri Jul 16 10:36:47 2010 From: Ed.Lewis at neustar.biz (Edward Lewis) Date: Fri, 16 Jul 2010 11:36:47 -0400 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <20100716145315.GA19935@ussenterprise.ufp.org> References: <20100716145315.GA19935@ussenterprise.ufp.org> Message-ID: At 7:53 -0700 7/16/10, Leo Bicknell wrote: >Perhaps you could explain why the keys are being made available in >formats that, as far as I can tell, no nameserver software on the >planet uses? (My guess:) There's no standard input format for name servers, especially regarding configuration information. The problem isn't (just) that the root anchor isn't in the format for any name server, the problem is that name servers can't read the formats given. If you want it for BIND, for example, ISC would be the place to get it in the "trusted-keys" syntax. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Spouses, like Internet protocols, lack necessary troubleshooting tools. Sigh. From tony.li at tony.li Fri Jul 16 10:50:58 2010 From: tony.li at tony.li (Tony Li) Date: Fri, 16 Jul 2010 08:50:58 -0700 Subject: Vyatta as a BRAS In-Reply-To: <55112.1279285362@localhost> References: <201007141517.o6EFHmhI013994@aurora.sol.net> <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> <385099.56910.qm@web180304.mail.gq1.yahoo.com> <55112.1279285362@localhost> Message-ID: On Jul 16, 2010, at 6:02 AM, Valdis.Kletnieks at vt.edu wrote: > 1/4" plastic tubing - http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_nut.jpg > garden hose - http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800px-Garden_hose.jpg > fire hose - http://www.firetrainingcenter.com/images/FireHoseStreams.jpg > NYC Delaware Aqueduct - http://www.allpropertymanagement.com/blog/2010/02/09/worlds-awesome-tunnels/ So, you finally admit it. The Internet is just a bunch of tubes. ;-) Tony From joelja at bogus.com Fri Jul 16 11:17:46 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 16 Jul 2010 09:17:46 -0700 Subject: Vyatta as a BRAS In-Reply-To: <55112.1279285362@localhost> References: <201007141517.o6EFHmhI013994@aurora.sol.net> <91522911795E174F97E7EF8B792A1031229554@ltiserver.LTI.local> <385099.56910.qm@web180304.mail.gq1.yahoo.com> <55112.1279285362@localhost> Message-ID: <4C40862A.7060906@bogus.com> On 7/16/10 6:02 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 15 Jul 2010 20:57:15 PDT, Henry Linneweh said: >> Can we get a consensus definition on these definition's and what hardware >> vender's make edge routers and what hardware vender's make core routers. > > I got a router, it's got 5-6 10GE interfaces talking to other routers on > my network backbone, and a bunch of 10GE links to end-user-facing aggregation > switches. Since it's only forwarding inside my network, it's a core router > by your definition. > > I now turn up an identical hardware 10GE link - connected to Level3. I just > became an edge router by your definition since I'm talking to another network. > (I know, I probably don't want to do that - but I *could*, maybe even without > a full BGP feed if the routing situation allows. The point is the definition > is busticated). There's also virtualization due to the ubiquitous deployment of VRF's moderate to size extra-large routers are entirely likely to be serving in multiple roles. > Adding to the confusion is the fact that the edge routers of some large providers > need more capacity than the core routers of smaller organizations.... > > Maybe we need to ditch the terms edge and core, and instead talk about: > > 1/4" plastic tubing - http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_nut.jpg > garden hose - http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800px-Garden_hose.jpg > fire hose - http://www.firetrainingcenter.com/images/FireHoseStreams.jpg > NYC Delaware Aqueduct - http://www.allpropertymanagement.com/blog/2010/02/09/worlds-awesome-tunnels/ > > Everybody good with that? ;) > > (Man.. it *leaks* 15 million gallons a day. That's capacity. :) From Greg.Whynott at oicr.on.ca Fri Jul 16 11:18:01 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 16 Jul 2010 12:18:01 -0400 Subject: virtual switches Message-ID: <7AFBB29F-2CDB-40F7-86B1-E2CAF16DC7C5@oicr.on.ca> Cisco has VSS (on 6500 class) and H3C has IRF; allowing you to virtualize 2 or more physical switches/routers in an active/active configuration where you can use all links and terminate LACP aggregates between the two devices. Is anyone using this or similar technology from another vendor? any recommendations or comments would be appreciated. thanks very much for your time! -g From dot at dotat.at Fri Jul 16 13:07:46 2010 From: dot at dotat.at (Tony Finch) Date: Fri, 16 Jul 2010 19:07:46 +0100 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <20100716153233.GA1137974@hiwaay.net> References: <20100716145315.GA19935@ussenterprise.ufp.org> <20100716153233.GA1137974@hiwaay.net> Message-ID: On Fri, 16 Jul 2010, Chris Adams wrote: > > A simple XSLT will transform it into any needed format. XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires. Tony. -- f.anthony.n.finch http://dotat.at/ TYNE DOGGER FISHER: SOUTHERLY VEERING WESTERLY 5 TO 7, DECREASING 4 OR 5. MODERATE OR ROUGH, OCCASIONALLY VERY ROUGH AT FIRST IN FISHER, BECOMING SLIGHT OR MODERATE. SQUALLY, THUNDERY SHOWERS. MODERATE OR GOOD. From cscora at apnic.net Fri Jul 16 13:11:46 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 17 Jul 2010 04:11:46 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201007161811.o6GIBkgM011483@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 17 Jul, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 325312 Prefixes after maximum aggregation: 149926 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 159012 Total ASes present in the Internet Routing Table: 34366 Prefixes per ASN: 9.47 Origin-only ASes present in the Internet Routing Table: 29833 Origin ASes announcing only one prefix: 14455 Transit ASes present in the Internet Routing Table: 4533 Transit-only ASes present in the Internet Routing Table: 100 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 25 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 308 Unregistered ASNs in the Routing Table: 118 Number of 32-bit ASNs allocated by the RIRs: 686 Prefixes from 32-bit ASNs in the Routing Table: 825 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 166 Number of addresses announced to Internet: 2276042112 Equivalent to 135 /8s, 169 /16s and 165 /24s Percentage of available address space announced: 61.4 Percentage of allocated address space announced: 66.2 Percentage of available address space allocated: 92.8 Percentage of address space in use by end-sites: 83.8 Total number of prefixes smaller than registry allocations: 154768 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 78953 Total APNIC prefixes after maximum aggregation: 27110 APNIC Deaggregation factor: 2.91 Prefixes being announced from the APNIC address blocks: 75847 Unique aggregates announced from the APNIC address blocks: 33498 APNIC Region origin ASes present in the Internet Routing Table: 4111 APNIC Prefixes per ASN: 18.45 APNIC Region origin ASes announcing only one prefix: 1138 APNIC Region transit ASes present in the Internet Routing Table: 633 Average APNIC Region AS path length visible: 3.6 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 531282208 Equivalent to 31 /8s, 170 /16s and 185 /24s Percentage of available APNIC address space announced: 79.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 134218 Total ARIN prefixes after maximum aggregation: 69466 ARIN Deaggregation factor: 1.93 Prefixes being announced from the ARIN address blocks: 107063 Unique aggregates announced from the ARIN address blocks: 41911 ARIN Region origin ASes present in the Internet Routing Table: 13792 ARIN Prefixes per ASN: 7.76 ARIN Region origin ASes announcing only one prefix: 5279 ARIN Region transit ASes present in the Internet Routing Table: 1357 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 729625120 Equivalent to 43 /8s, 125 /16s and 50 /24s Percentage of available ARIN address space announced: 62.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 74811 Total RIPE prefixes after maximum aggregation: 43408 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 67993 Unique aggregates announced from the RIPE address blocks: 44455 RIPE Region origin ASes present in the Internet Routing Table: 14604 RIPE Prefixes per ASN: 4.66 RIPE Region origin ASes announcing only one prefix: 7511 RIPE Region transit ASes present in the Internet Routing Table: 2179 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 434075776 Equivalent to 25 /8s, 223 /16s and 120 /24s Percentage of available RIPE address space announced: 76.1 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 28966 Total LACNIC prefixes after maximum aggregation: 6957 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 27578 Unique aggregates announced from the LACNIC address blocks: 14516 LACNIC Region origin ASes present in the Internet Routing Table: 1307 LACNIC Prefixes per ASN: 21.10 LACNIC Region origin ASes announcing only one prefix: 410 LACNIC Region transit ASes present in the Internet Routing Table: 232 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 25 Number of LACNIC addresses announced to Internet: 75606464 Equivalent to 4 /8s, 129 /16s and 169 /24s Percentage of available LACNIC address space announced: 56.3 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7287 Total AfriNIC prefixes after maximum aggregation: 1866 AfriNIC Deaggregation factor: 3.91 Prefixes being announced from the AfriNIC address blocks: 5592 Unique aggregates announced from the AfriNIC address blocks: 1599 AfriNIC Region origin ASes present in the Internet Routing Table: 380 AfriNIC Prefixes per ASN: 14.72 AfriNIC Region origin ASes announcing only one prefix: 117 AfriNIC Region transit ASes present in the Internet Routing Table: 85 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 19625216 Equivalent to 1 /8s, 43 /16s and 117 /24s Percentage of available AfriNIC address space announced: 58.5 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1859 8425 493 Korea Telecom (KIX) 7545 1379 232 105 TPG Internet Pty Ltd 4755 1375 297 162 TATA Communications formerly 17488 1333 145 127 Hathway IP Over Cable Interne 17974 1166 285 51 PT TELEKOMUNIKASI INDONESIA 9583 1001 74 485 Sify Limited 24560 957 305 178 Bharti Airtel Ltd., Telemedia 4134 879 21740 411 CHINANET-BACKBONE 4808 824 1572 215 CNCGROUP IP network: China169 9829 813 685 32 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3891 3718 287 bellsouth.net, inc. 4323 2717 1112 393 Time Warner Telecom 19262 1827 4562 274 Verizon Global Networks 1785 1780 698 129 PaeTec Communications, Inc. 20115 1548 1524 653 Charter Communications 7018 1484 5736 963 AT&T WorldNet Services 2386 1284 568 905 AT&T Data Communications Serv 6478 1257 253 197 AT&T Worldnet Services 22773 1173 2859 65 Cox Communications, Inc. 3356 1162 10879 405 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 652 56 6 United Telecom of Georgia 9198 497 202 13 Kazakhtelecom Data Network Ad 3292 452 2027 393 TDC Tele Danmark 30890 440 111 206 Evolva Telecom 702 413 1869 325 UUNET - Commercial IP service 8866 402 117 18 Bulgarian Telecommunication C 8551 400 353 46 Bezeq International 3320 373 7329 324 Deutsche Telekom AG 3301 372 1414 327 TeliaNet Sweden 34984 362 89 183 BILISIM TELEKOM Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1529 3033 248 UniNet S.A. de C.V. 10620 1072 240 149 TVCABLE BOGOTA 28573 1042 812 99 NET Servicos de Comunicao S.A 7303 736 390 93 Telecom Argentina Stet-France 6503 700 177 219 AVANTEL, S.A. 22047 551 310 15 VTR PUNTO NET S.A. 3816 503 218 88 Empresa Nacional de Telecomun 14420 498 32 72 CORPORACION NACIONAL DE TELEC 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 449 99 76 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1101 445 10 TEDATA 24863 727 147 39 LINKdotNET AS number 36992 650 279 185 Etisalat MISR 3741 267 834 229 The Internet Solution 33776 220 12 12 Starcomms Nigeria Limited 2018 209 244 61 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 24835 189 78 9 RAYA Telecom - Egypt 29571 177 19 10 Ci Telecom Autonomous system 16637 166 440 95 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3891 3718 287 bellsouth.net, inc. 4323 2717 1112 393 Time Warner Telecom 4766 1859 8425 493 Korea Telecom (KIX) 19262 1827 4562 274 Verizon Global Networks 1785 1780 698 129 PaeTec Communications, Inc. 20115 1548 1524 653 Charter Communications 8151 1529 3033 248 UniNet S.A. de C.V. 7018 1484 5736 963 AT&T WorldNet Services 7545 1379 232 105 TPG Internet Pty Ltd 4755 1375 297 162 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2717 2324 Time Warner Telecom 1785 1780 1651 PaeTec Communications, Inc. 19262 1827 1553 Verizon Global Networks 4766 1859 1366 Korea Telecom (KIX) 8151 1529 1281 UniNet S.A. de C.V. 7545 1379 1274 TPG Internet Pty Ltd 4755 1375 1213 TATA Communications formerly 17488 1333 1206 Hathway IP Over Cable Interne 17974 1166 1115 PT TELEKOMUNIKASI INDONESIA 22773 1173 1108 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:68 /12:197 /13:408 /14:713 /15:1289 /16:11185 /17:5357 /18:9179 /19:18475 /20:23046 /21:23004 /22:29925 /23:29564 /24:169691 /25:1006 /26:1277 /27:702 /28:110 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2491 3891 bellsouth.net, inc. 4766 1487 1859 Korea Telecom (KIX) 4323 1392 2717 Time Warner Telecom 1785 1241 1780 PaeTec Communications, Inc. 17488 1078 1333 Hathway IP Over Cable Interne 11492 1068 1160 Cable One 18566 1068 1087 Covad Communications 8452 993 1101 TEDATA 10620 988 1072 TVCABLE BOGOTA 7018 885 1484 AT&T WorldNet Services Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:10 2:2 4:13 8:287 12:2018 13:7 14:1 15:22 16:3 17:8 20:6 24:1464 27:251 31:1 32:49 33:12 38:688 40:98 41:2399 44:3 46:2 47:17 52:9 55:5 56:2 57:28 58:755 59:503 60:461 61:1088 62:1042 63:1970 64:3678 65:2347 66:4045 67:1828 68:1109 69:2690 70:723 71:385 72:1947 73:2 74:2262 75:248 76:316 77:897 78:619 79:430 80:974 81:765 82:492 83:444 84:680 85:1050 86:458 87:682 88:340 89:1563 90:94 91:2875 92:503 93:987 94:1401 95:645 96:356 97:212 98:610 99:31 108:100 109:567 110:384 111:547 112:286 113:319 114:431 115:568 116:1088 117:654 118:483 119:880 120:131 121:728 122:1483 123:944 124:1116 125:1322 128:226 129:199 130:196 131:553 132:247 133:17 134:195 135:45 136:241 137:145 138:265 139:104 140:483 141:197 142:337 143:370 144:470 145:50 146:449 147:167 148:663 149:301 150:153 151:229 152:298 153:169 154:2 155:359 156:160 157:296 158:109 159:356 160:316 161:183 162:249 163:177 164:405 165:365 166:458 167:414 168:649 169:157 170:708 171:59 172:2 173:942 174:480 175:146 176:1 178:301 180:522 182:149 183:235 184:111 186:499 187:391 188:1008 189:768 190:3813 192:5737 193:4719 194:3396 195:2800 196:1192 198:3577 199:3456 200:5336 201:1565 202:7972 203:8285 204:4074 205:2319 206:2486 207:3104 208:3864 209:3453 210:2532 211:1272 212:1711 213:1663 214:639 215:69 216:4699 217:1525 218:498 219:378 220:1149 221:402 222:316 223:1 End of report From joelja at bogus.com Fri Jul 16 13:12:58 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 16 Jul 2010 11:12:58 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: <20100716145315.GA19935@ussenterprise.ufp.org> <20100716153233.GA1137974@hiwaay.net> Message-ID: <4C40A12A.8050201@bogus.com> On 7/16/10 11:07 AM, Tony Finch wrote: > On Fri, 16 Jul 2010, Chris Adams wrote: >> >> A simple XSLT will transform it into any needed format. > > XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires. > > Tony. anchors2keys will. From cmadams at hiwaay.net Fri Jul 16 13:14:24 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 16 Jul 2010 13:14:24 -0500 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: <20100716145315.GA19935@ussenterprise.ufp.org> <20100716153233.GA1137974@hiwaay.net> Message-ID: <20100716181424.GD1137974@hiwaay.net> Once upon a time, Tony Finch said: > On Fri, 16 Jul 2010, Chris Adams wrote: > > A simple XSLT will transform it into any needed format. > > XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires. That sounds like a problem with BIND then. :-) -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From karim.adel at gmail.com Fri Jul 16 13:34:53 2010 From: karim.adel at gmail.com (Kasper Adel) Date: Fri, 16 Jul 2010 21:34:53 +0300 Subject: NOC Best Practices In-Reply-To: References: Message-ID: Thanks for all the people that replied off list, asking me to send them responses i will get. I got nothing other than : http://www.nanog.org/meetings/nanog24/abstracts.php?pt=OTM1Jm5hbm9nMjQ=&nm=nanog24 and Network Management- Accounting and Performance Strategies - Just the first three chapters Which is useful but i am looking for more stuff from the best people that run the best NOCs in the world. So i'm throwing this out again. I am looking for pointers, suggestions, URLs, documents, donations on what a professional NOC would have on the below topics: 1) Briefly, how they handle their own tickets with vendors or internal 2) How they create a learning environment for their people (Documenting Syslog, lessons learned from problems...etc) 3) Shift to Shift hand over procedures 4) Manual tests they start their day with and what they automate (common stuff) 5) Change management best practices and working with operations/engineering when a change will be implemented Should i be looking for ITIL stuff or its not any good? Thanks, Kim On Wed, Jul 14, 2010 at 8:24 PM, Kasper Adel wrote: > Hello Everyone, > > I am currently working on building a NOC so i'm looking for > materials/pointers to Best Practices documented out there. > > On the top of my head are things like: > > 1) Documenting Incidents and handling them > 2) Documenting Syslog messages > 3) Documenting Vendor Software Bugs > 4) Shift to Shift Hand over procedures > 5) Commonly used scripts for monitoring > 6) Frequently testing High Availability > 7) Capturing config changes. > ....etc > > I can see that this is years of experience but i am wondering if any of > this was captured some where. > > Thanks, > Kim > From butche at butchevans.com Fri Jul 16 13:47:34 2010 From: butche at butchevans.com (Butch Evans) Date: Fri, 16 Jul 2010 13:47:34 -0500 Subject: ISC DHCPD In-Reply-To: <1279264255.3118.170.camel@localhost.localdomain> References: <1279264255.3118.170.camel@localhost.localdomain> Message-ID: <1279306054.3118.196.camel@localhost.localdomain> On Fri, 2010-07-16 at 02:10 -0500, Butch Evans wrote: > I have a cisco cmts that forwards dhcp requests to an ISC dhcp server. > I have a working configuration for this. I am trying to set up ISC > DHCPD so that it can handle multiple shared-networks. I cannot seem to > get this working correctly. If there is an expert "in the house" who > can offer me a few minutes of your time to look over a configuration for > me, please send me a phone number/email offlist and I'll discuss > specifics. To all who have responded. THANK YOU. I found the issue and it has now been resolved. Actually, it was Bryan Scott at Wireless Beehive that found the issue. For those that wonder, it was a problem where certain attributes were being returned for some clients and not others. After moving the problem attributes to another area of the configuration, the issue was resolved. Big thanks to those who offered insights (some of you offered assistance that I did not directly respond to, but I did look at your suggestions and tried several of them). -- ******************************************************************** * Butch Evans * Professional Network Consultation* * http://www.butchevans.com/ * Network Engineering * * http://store.wispgear.net/ * Wired or Wireless Networks * * http://blog.butchevans.com/ * ImageStream, Mikrotik and MORE! * ******************************************************************** From joesox at gmail.com Fri Jul 16 15:08:45 2010 From: joesox at gmail.com (JoeSox) Date: Fri, 16 Jul 2010 13:08:45 -0700 Subject: NOC Best Practices In-Reply-To: References: Message-ID: I believe, myself included, are hesitant to answer because it really depends upon a lot of variables. Type of business your NOC is running, the operating budget, number of racks, etc. The details matter when narrowing things down. But yes, I have seen this ITIL http://www.frontrange.com/ click the Register for a Free ITIL Success Kit! You may be interested in. -- Thanks, Joe On Fri, Jul 16, 2010 at 11:34 AM, Kasper Adel wrote: > Thanks for all the people that replied off list, asking me to send them > responses i will get. > > I got nothing other than : > http://www.nanog.org/meetings/nanog24/abstracts.php?pt=OTM1Jm5hbm9nMjQ=&nm=nanog24 > and > > Network Management- ?Accounting and Performance Strategies - Just the first > three chapters > > Which is useful but i am looking for more stuff from the best people that > run the best NOCs in the world. > > So i'm throwing this out again. > > I am looking for pointers, suggestions, URLs, documents, donations on what a > professional NOC would have on the below topics: > > 1) Briefly, how they handle their own tickets with vendors or internal > 2) How they create a learning environment for their people (Documenting > Syslog, lessons learned from problems...etc) > 3) Shift to Shift hand over procedures > 4) Manual tests ?they start their day with and what they automate (common > stuff) > 5) Change management best practices and working with operations/engineering > when a change will be implemented > > Should i be looking for ITIL stuff or its not any good? > > Thanks, > Kim > > On Wed, Jul 14, 2010 at 8:24 PM, Kasper Adel wrote: > >> Hello Everyone, >> >> I am currently working on building a NOC so i'm looking for >> materials/pointers to Best Practices documented out there. >> >> On the top of my head are things like: >> >> 1) Documenting Incidents and handling them >> 2) Documenting Syslog messages >> 3) Documenting Vendor Software Bugs >> 4) Shift to Shift Hand over procedures >> 5) Commonly used scripts for monitoring >> 6) Frequently testing High Availability >> 7) Capturing config changes. >> ....etc >> >> I can see that this is years of experience but i am wondering if any of >> this was captured some where. >> >> Thanks, >> Kim >> > From cidr-report at potaroo.net Fri Jul 16 17:00:03 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Jul 2010 22:00:03 GMT Subject: BGP Update Report Message-ID: <201007162200.o6GM03Zl075104@wattle.apnic.net> BGP Update Report Interval: 08-Jul-10 -to- 15-Jul-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30890 249855 14.3% 577.0 -- EVOLVA Evolva Telecom s.r.l. 2 - AS24400 45751 2.6% 3812.6 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 3 - AS9808 41156 2.4% 762.1 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 4 - AS50075 37055 2.1% 553.1 -- INBAR-BUSINESS-CORPORATION INBAR BUSINESS CORPORATION S.R.L. 5 - AS5416 25273 1.4% 231.9 -- BATELCO-BH 6 - AS11981 24624 1.4% 2736.0 -- SPECIALSYSTEMS - Special Systems Inc. 7 - AS44475 19785 1.1% 618.3 -- TIADOLI-AS SC Tiadoli Company SRL 8 - AS39543 17502 1.0% 700.1 -- TENNET-AS SC TENNET TELECOM SRL 9 - AS8452 16954 1.0% 19.8 -- TEDATA TEDATA 10 - AS25620 16765 1.0% 94.7 -- COTAS LTDA. 11 - AS48838 16755 1.0% 507.7 -- EUROLAN-ASN Eurolan Solutions SRL 12 - AS35931 14704 0.8% 7352.0 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - AS37204 14341 0.8% 1434.1 -- TELONE 14 - AS41852 12670 0.7% 666.8 -- EXPERTNET-AS S.C. EXPERTNET S.R.L. 15 - AS35805 12130 0.7% 19.3 -- SILKNET-AS SILKNET AS 16 - AS32528 11879 0.7% 2969.8 -- ABBOTT Abbot Labs 17 - AS34916 11168 0.6% 620.4 -- DNET-AS SC Digital Construction Network SRL 18 - AS8151 9871 0.6% 10.5 -- Uninet S.A. de C.V. 19 - AS36992 9824 0.6% 15.1 -- ETISALAT-MISR 20 - AS45464 9098 0.5% 227.4 -- NEXTWEB-AS-AP Room 201, TGU Bldg TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35931 14704 0.8% 7352.0 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS48754 5269 0.3% 5269.0 -- SOBIS-AS SOBIS SOLUTIONS SRL 3 - AS19174 4986 0.3% 4986.0 -- CNC-USA - China Netcom (USA) Operations Ltd. 4 - AS24400 45751 2.6% 3812.6 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 5 - AS13030 7306 0.4% 3653.0 -- INIT7 Init Seven AG, Zurich, Switzerland 6 - AS32528 11879 0.7% 2969.8 -- ABBOTT Abbot Labs 7 - AS11981 24624 1.4% 2736.0 -- SPECIALSYSTEMS - Special Systems Inc. 8 - AS37204 14341 0.8% 1434.1 -- TELONE 9 - AS49086 1289 0.1% 1289.0 -- EDC-AS SC Euro Data Construct SRL 10 - AS39692 1200 0.1% 1200.0 -- ROMSERV-AS SC ROMSERV SOLUTIONS SRL 11 - AS39874 3532 0.2% 1177.3 -- AUTOGENN-TELECOM Bucuresti 2, Romania 12 - AS51076 2290 0.1% 1145.0 -- GE-AND-CO-COMPUTER-INDUSTRIES GE & CO COMPUTER INDUSTRIES SRL 13 - AS47345 1098 0.1% 1098.0 -- RTS-TELECOM-AS RTS Telecom SRL 14 - AS38997 3291 0.2% 1097.0 -- INTRANET-AS SC INTRANET VISION SRL 15 - AS43647 3171 0.2% 1057.0 -- LINK-NET-ASN SC. Link Net SRL. 16 - AS41633 2077 0.1% 1038.5 -- X-TREME-AS S.C. X-Treme Share SRL 17 - AS39345 6030 0.3% 1005.0 -- BTS-AS SC BTS NET TELECOM SRL 18 - AS38947 999 0.1% 999.0 -- KNETWORKMEDIA K Network Media 19 - AS49829 8414 0.5% 934.9 -- CAPITAL-COM SC Capital Communication Investment SRL 20 - AS49383 909 0.1% 909.0 -- EVER-NET-AS SC M-Tel Consulting SRL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 111.10.4.0/24 8088 0.4% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 2 - 111.10.0.0/24 8088 0.4% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 3 - 111.10.1.0/24 8086 0.4% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 4 - 111.10.2.0/24 8085 0.4% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 5 - 111.10.3.0/24 8085 0.4% AS9808 -- CMNET-GD Guangdong Mobile Communication Co.Ltd. 6 - 198.140.43.0/24 7567 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - 212.51.128.0/19 7296 0.4% AS13030 -- INIT7 Init Seven AG, Zurich, Switzerland 8 - 63.211.68.0/22 7137 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - 117.131.0.0/17 6828 0.4% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 10 - 120.204.0.0/16 6750 0.4% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 11 - 117.136.8.0/24 6398 0.3% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 12 - 117.135.128.0/18 6228 0.3% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 13 - 117.135.0.0/17 6220 0.3% AS24400 -- CMNET-V4SHANGHAI-AS-AP Shanghai Mobile Communications Co.,Ltd. 14 - 130.36.34.0/24 5870 0.3% AS32528 -- ABBOTT Abbot Labs 15 - 130.36.35.0/24 5869 0.3% AS32528 -- ABBOTT Abbot Labs 16 - 190.65.228.0/22 5737 0.3% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 17 - 91.212.23.0/24 5269 0.3% AS48754 -- SOBIS-AS SOBIS SOLUTIONS SRL 18 - 207.254.176.0/20 4986 0.3% AS19174 -- CNC-USA - China Netcom (USA) Operations Ltd. 19 - 41.34.29.0/24 4976 0.3% AS8452 -- TEDATA TEDATA 20 - 148.204.141.0/24 4100 0.2% AS8151 -- Uninet S.A. de C.V. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 16 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 16 Jul 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201007162200.o6GM00mr075095@wattle.apnic.net> This report has been generated at Fri Jul 16 21:11:34 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 09-07-10 329107 202441 10-07-10 329272 202604 11-07-10 329306 202611 12-07-10 329227 202212 13-07-10 328424 202676 14-07-10 328854 202711 15-07-10 328939 202642 16-07-10 329107 202892 AS Summary 34865 Number of ASes in routing system 14800 Number of ASes announcing only one prefix 4480 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 97811776 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 16Jul10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 329227 202838 126389 38.4% All ASes AS6389 3891 292 3599 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4480 1820 2660 59.4% TWTC - tw telecom holdings, inc. AS19262 1828 275 1553 85.0% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4766 1859 507 1352 72.7% KIXS-AS-KR Korea Telecom AS22773 1173 70 1103 94.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1375 301 1074 78.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS17488 1333 332 1001 75.1% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1530 617 913 59.7% Uninet S.A. de C.V. AS6478 1253 414 839 67.0% ATT-INTERNET3 - AT&T WorldNet Services AS5668 947 134 813 85.9% AS-5668 - CenturyTel Internet Holdings, Inc. AS7545 1397 590 807 57.8% TPG-INTERNET-AP TPG Internet Pty Ltd AS8452 1101 396 705 64.0% TEDATA TEDATA AS10620 1072 384 688 64.2% Telmex Colombia S.A. AS7303 761 123 638 83.8% Telecom Argentina S.A. AS35805 652 41 611 93.7% SILKNET-AS SILKNET AS AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS4808 824 241 583 70.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS28573 1042 508 534 51.2% NET Servicos de Comunicao S.A. AS4780 691 168 523 75.7% SEEDNET Digital United Inc. AS7018 1484 965 519 35.0% ATT-INTERNET4 - AT&T WorldNet Services AS7552 652 141 511 78.4% VIETEL-AS-AP Vietel Corporation AS9443 571 75 496 86.9% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 580 84 496 85.5% GIGAINFRA Softbank BB Corp. AS3356 1164 670 494 42.4% LEVEL3 Level 3 Communications AS1785 1780 1288 492 27.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS24560 957 473 484 50.6% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7011 1133 652 481 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS9198 497 40 457 92.0% KAZTELECOM-AS JSC Kazakhtelecom AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. Total 38269 11766 26503 69.3% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.72.112.0/20 AS19166 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 181.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.139.3.0/24 AS23184 PERSONA - PERSONA COMMUNICATIONS INC. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.72.224.0/21 AS24013 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 207.241.192.0/20 AS3356 LEVEL3 Level 3 Communications 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jeff at ocjtech.us Fri Jul 16 19:34:54 2010 From: jeff at ocjtech.us (Jeffrey Ollie) Date: Fri, 16 Jul 2010 19:34:54 -0500 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <4C40A12A.8050201@bogus.com> References: <20100716145315.GA19935@ussenterprise.ufp.org> <20100716153233.GA1137974@hiwaay.net> <4C40A12A.8050201@bogus.com> Message-ID: On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli wrote: > On 7/16/10 11:07 AM, Tony Finch wrote: >> >> On Fri, 16 Jul 2010, Chris Adams wrote: >>> >>> A simple XSLT will transform it into any needed format. >> >> XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires. > > anchors2keys will. Actually, it won't. The ITAR anchors.xml and anchors2keys use a different XML schema than the root-anchors.xml does. -- Jeff Ollie From joelja at bogus.com Fri Jul 16 20:24:23 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 16 Jul 2010 18:24:23 -0700 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: <20100716145315.GA19935@ussenterprise.ufp.org> <20100716153233.GA1137974@hiwaay.net> <4C40A12A.8050201@bogus.com> Message-ID: <45E69A40-E608-462E-93BF-5AB401DA2F90@bogus.com> Yeah oops. Just noticed that Joel's iPad On Jul 16, 2010, at 5:34 PM, Jeffrey Ollie wrote: > On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli wrote: >> On 7/16/10 11:07 AM, Tony Finch wrote: >>> >>> On Fri, 16 Jul 2010, Chris Adams wrote: >>>> >>>> A simple XSLT will transform it into any needed format. >>> >>> XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires. >> >> anchors2keys will. > > Actually, it won't. The ITAR anchors.xml and anchors2keys use a > different XML schema than the root-anchors.xml does. > > -- > Jeff Ollie > From rdobbins at arbor.net Fri Jul 16 22:17:14 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 17 Jul 2010 03:17:14 +0000 Subject: On another security note... (of sorts) In-Reply-To: <201007161042.40853.lowen@pari.edu> References: <4C3F5632.4080408@csuohio.edu> <201007161042.40853.lowen@pari.edu> Message-ID: <384B29B4-B24B-4EF4-BCCB-F87CE505151D@arbor.net> On Jul 16, 2010, at 9:42 PM, Lamar Owen wrote: > I'm sure the collective wisdom here is capable of pulling the task off at least in theory; The thorniest issues aren't technology-related, per se; they're legal exposure (both real and imagined), regulatory concerns (both real and imagined), antitrust concerns (both real and imagined), management/marketing/PR concerns (largely imagined), skillset shortages/concerns (very real), customer perception concerns (both real and imagined), and so forth. The second tier of barriers are those surrounding trust. It's basically a sociological analogue of 'the PKI problem'. Technology issues form the third set of barriers. Yes, they're real and they're important, but if we could wiggle our noses a la Elizabeth Montgomery and make all the technology issues go away, the other sets of issues would still preclude any kind of universal solution, for some value of 'solution'. There's a great deal of opsec coordination and work which takes place in a sub rosa fashion, via individual actions, closed, vetted mitigation communities, ad hoc personal relationships, etc. In actuality, a very great deal of the useful opsec work that gets done is accomplished by folks who in some cases are going beyond their portfolios to do so, as their management, legal teams, PR/marketing teams, et. al. would actively forbid them to do this work, were they to know about it. That's one of the reasons why a lot of people who make sweeping generalizations and recommendations about 'cyber-this' and 'cyber-that' tend not to have a good grasp of even the fundamentals - they aren't the folks who do the actual work, they don't know who does the actual work, and they often don't know anybody who knows somebody who actually does the actual work. They often don't even know that actual work is taking place, or what it entails, in the first place, because the actual work takes place out of the limelight. > the hard part would be deciding whether to do it in hardware or software.... ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From nanog-post at rsuc.gweep.net Sat Jul 17 13:56:04 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Sat, 17 Jul 2010 14:56:04 -0400 Subject: NOC Best Practices In-Reply-To: References: Message-ID: <20100717185604.GA41823@gweep.net> On Fri, Jul 16, 2010 at 09:34:53PM +0300, Kasper Adel wrote: > Thanks for all the people that replied off list, asking me to send them > responses i will get. [snip] > Which is useful but i am looking for more stuff from the best people that > run the best NOCs in the world. > > So i'm throwing this out again. > > I am looking for pointers, suggestions, URLs, documents, donations on what a > professional NOC would have on the below topics: A lot, as others have said, depending on the business, staffing, goals, SLA, contracts, etc. > 1) Briefly, how they handle their own tickets with vendors or internal Run a proper ticketing system over which you have control (RT and friends rather than locking you into something you have to pay for changes). Don't just by ticket closure rate, judge by succesfully resolving problems. Encourage folks to use the system for tracking projects and keeping notes on work in progress rather than private datastores. Inculcate a culture of open exploration to solve problems rather than rote memorization. This gets you a large way to #2. > 2) How they create a learning environment for their people (Documenting > Syslog, lessons learned from problems...etc) Mentoring, shoulder surfing. Keep your senior people in the mix of triage & response so they don't get dull and cross-pollenate skills. When someone is new, have their probationary period be shadowing the primary on-call the entire time. Your third shift [or whatever spans your maintenance windows] should be the folks who actually wind up executing well-specified maintenances (with guidance as needed) and be the breeding ground of some of your better hands-on folks. > 3) Shift to Shift hand over procedures This will depend on your systems for tickets, logbooks, etc. Sole that first and this should become evident. > 4) Manual tests they start their day with and what they automate (common > stuff) This will vary on the business and what's on-site; I can't advise you to always include the genset is you don't have one. > 5) Change management best practices and working with operations/engineering > when a change will be implemented Standing maintenance windows (of varying severity if that matters yo your business), clear definition of what needs to be done only duringthose and what can be done anytime [hint: policy tuning shouldn't be restructed to them, and you shouldn't make it so an urgent things like a BGP leak can't be fixed]. Linear rather than parallel workflows for approval, and not too many approval stages else your staff will be spending time trying to get things through the administrative stages instead of actual work. Very simply, have a standard for specifying what needs to be done, the minimal tests needed to verify success, and how you fallback if you fail the tests. If someone can't specify it and insist on frobbing around, they likely don't understand the problem or the needed work. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From khatfield at socllc.net Sat Jul 17 15:02:01 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Sat, 17 Jul 2010 20:02:01 +0000 Subject: NOC Best Practices In-Reply-To: <20100717185604.GA41823@gweep.net> References: <20100717185604.GA41823@gweep.net> Message-ID: <137742149-1279396922-cardhu_decombobulator_blackberry.rim.net-67367057-@bda903.bisx.prod.on.blackberry> I have to agree that this is all good information. Your question on ITIL: My personal opinion is that ITIL best practices are great to apply to all environments. It makes sense, specifically in the change control systems. However, as stated, it's also highly dependent on how many devices being managed/monitored. I come from a NOC managing 8600+ network devices across 190+ countries. Strict change management policies, windows, approvers. All depending on times relative to the operations in different countries. We were growing so rapidly that we continued purchasing companies and bringing over their infrastructure. Each time bringing in new ticket systems, etc. NNM is by far one of my favorite choices for network monitoring. The issue with it is really the views and getting them organized in an easily viewable fashion. RT is a great ticketing tool for specific needs. It allows for approvers and approval tracking of tickets. However, it isn't extremely robust. I would recommend something like HP ServiceCenter since it can integrate and automate the alert output directly to tickets. This also allows the capability to use Alarmpoint for automated paging of your on-calls based on their schedules, by device, etc. Not to say that I'm a complete HP fan boy but I will say that it works extremely well. Easy to use and simplicity is the key to less mistakes. All of our equipment was 99% Cisco so the combination worked extremely well. Turnover : I firmly believe shift changes should be verbally handed off. Build a template for the days top items or most critical issues. List out the ongoing issues and any tickets being carried over with the status. Allot 15 minutes for the team to sit down with the printout and review it. Contracts/SLA's: We placed all of our systems in a bulk 99.999% uptime critical SLA. However, this was a mistake on our part and the lack of time to plan well when adapting to an ever-changing environment. It would be best to setup your appliances/hardware in your ticket system and monitoring tool based on the SLA you intend to apply to it. Also ensure you include all hardware information: Supply Vendor, Support Vendor, Support coverage, ETR from Vendor, Replacement time. There are many tools that do automated discovery on your network and monitors changes on the network. This is key if you have a changing environment. The more devices you have, the more difficult it is to pinpoint what a failed router or switch ACTUALLY affects upstream or downstream. If this is your chance, take the opportunity to map your hardware/software dependencies. If a switch fails and it provides service to: example: db01 and db01 drives the service in another location. Then you should know that failure is there. It's far too common for companies to get so large they have no idea what the impact of 1 port failure in xyz does to the entire infrastructure. Next: Build your monitoring infrastructure completely separate than the rest of the network. If you don't do switch redundancy (active/passive) on all of your systems or NIC teaming (active/passive) then ensure you do it at least on your monitoring systems. Build your logging out in a PCI/SOX fashion. Ensure you have remote logging on everything, log retention based on your need. Tripwire with approved reports being sent weekly on the systems requiring PCI/SOX monitoring. Remember, if your monitoring systems go down, your NOC is blind. It's highly recommend that the NOC have gateway/jump box systems available to all parts of the network. Run the management completely on RFC1918 for security. Ensure all on-calls have access, use a VPN solution that requires a password + vpn keygen. Utilize TACACs/LDAP the most you can. Tighten everything. Log everything. I can't say that enough. Enforce pw changes every 89 days, require strong passwords/non dictionary, etc. Build an internal site, use a wiki-based format, allow the team the ability to add/modify with approval. Build a FAQ/Knowledgebase. Possibly create a forum so your team can post extra tips/notes, one-offs. Anything that may help new members or people who run across something in the middle of the night they may have never seen. This keeps from waking up your lead staff in the middle of the night. On-calls: Always have a primary/secondary with a clear on-call procedure 'documented'. Example (critical): 1. Issue occurs 2. Page on-call within 10 minutes 3. Allow 10 minutes for return call. 4. Page again 5. Allow 5 minutes 6. Page secondary Etc. Ensure the staff documents every step they take and they copy/paste every page they send into the ticket system. Build templated paging formats. Understand that most txt messages with several carriers have hard limits. Use something like: Time InitialsofNOCPerson SystemAlerting Error CallbackNumber (Ie. 14:05 KH nycgw01 System reports down 555-555-5555 xt103) Use a paging internal website/software or as mentioned, something like Alarmpoint. There is nothing more frustrating for an on-call to be paged and have no idea who to call back, who paged, or what the number is. I've written so much my fingers hurt from these Blackberry keys. Hope this information helps a little. Best of luck, -Kevin Excuse the spelling/punctuation... This is from my mobile. -----Original Message----- From: Joe Provo Date: Sat, 17 Jul 2010 14:56:04 To: Kasper Adel Reply-To: nanog-post at rsuc.gweep.net Cc: NANOG list Subject: Re: NOC Best Practices On Fri, Jul 16, 2010 at 09:34:53PM +0300, Kasper Adel wrote: > Thanks for all the people that replied off list, asking me to send them > responses i will get. [snip] > Which is useful but i am looking for more stuff from the best people that > run the best NOCs in the world. > > So i'm throwing this out again. > > I am looking for pointers, suggestions, URLs, documents, donations on what a > professional NOC would have on the below topics: A lot, as others have said, depending on the business, staffing, goals, SLA, contracts, etc. > 1) Briefly, how they handle their own tickets with vendors or internal Run a proper ticketing system over which you have control (RT and friends rather than locking you into something you have to pay for changes). Don't just by ticket closure rate, judge by succesfully resolving problems. Encourage folks to use the system for tracking projects and keeping notes on work in progress rather than private datastores. Inculcate a culture of open exploration to solve problems rather than rote memorization. This gets you a large way to #2. > 2) How they create a learning environment for their people (Documenting > Syslog, lessons learned from problems...etc) Mentoring, shoulder surfing. Keep your senior people in the mix of triage & response so they don't get dull and cross-pollenate skills. When someone is new, have their probationary period be shadowing the primary on-call the entire time. Your third shift [or whatever spans your maintenance windows] should be the folks who actually wind up executing well-specified maintenances (with guidance as needed) and be the breeding ground of some of your better hands-on folks. > 3) Shift to Shift hand over procedures This will depend on your systems for tickets, logbooks, etc. Sole that first and this should become evident. > 4) Manual tests they start their day with and what they automate (common > stuff) This will vary on the business and what's on-site; I can't advise you to always include the genset is you don't have one. > 5) Change management best practices and working with operations/engineering > when a change will be implemented Standing maintenance windows (of varying severity if that matters yo your business), clear definition of what needs to be done only duringthose and what can be done anytime [hint: policy tuning shouldn't be restructed to them, and you shouldn't make it so an urgent things like a BGP leak can't be fixed]. Linear rather than parallel workflows for approval, and not too many approval stages else your staff will be spending time trying to get things through the administrative stages instead of actual work. Very simply, have a standard for specifying what needs to be done, the minimal tests needed to verify success, and how you fallback if you fail the tests. If someone can't specify it and insist on frobbing around, they likely don't understand the problem or the needed work. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From xbanchon at telconet.net Sat Jul 17 15:20:26 2010 From: xbanchon at telconet.net (Xavier Banchon) Date: Sat, 17 Jul 2010 20:20:26 +0000 Subject: NOC Best Practices In-Reply-To: <20100717185604.GA41823@gweep.net> References: <20100717185604.GA41823@gweep.net> Message-ID: <1347941069-1279398033-cardhu_decombobulator_blackberry.rim.net-244588648-@bda2730.bisx.prod.on.blackberry> What about e-TOM? Is it better than ITIL V3? Regards, Xavier Telconet S.A -----Original Message----- From: Joe Provo Date: Sat, 17 Jul 2010 14:56:04 To: Kasper Adel Reply-To: nanog-post at rsuc.gweep.net Cc: NANOG list Subject: Re: NOC Best Practices On Fri, Jul 16, 2010 at 09:34:53PM +0300, Kasper Adel wrote: > Thanks for all the people that replied off list, asking me to send them > responses i will get. [snip] > Which is useful but i am looking for more stuff from the best people that > run the best NOCs in the world. > > So i'm throwing this out again. > > I am looking for pointers, suggestions, URLs, documents, donations on what a > professional NOC would have on the below topics: A lot, as others have said, depending on the business, staffing, goals, SLA, contracts, etc. > 1) Briefly, how they handle their own tickets with vendors or internal Run a proper ticketing system over which you have control (RT and friends rather than locking you into something you have to pay for changes). Don't just by ticket closure rate, judge by succesfully resolving problems. Encourage folks to use the system for tracking projects and keeping notes on work in progress rather than private datastores. Inculcate a culture of open exploration to solve problems rather than rote memorization. This gets you a large way to #2. > 2) How they create a learning environment for their people (Documenting > Syslog, lessons learned from problems...etc) Mentoring, shoulder surfing. Keep your senior people in the mix of triage & response so they don't get dull and cross-pollenate skills. When someone is new, have their probationary period be shadowing the primary on-call the entire time. Your third shift [or whatever spans your maintenance windows] should be the folks who actually wind up executing well-specified maintenances (with guidance as needed) and be the breeding ground of some of your better hands-on folks. > 3) Shift to Shift hand over procedures This will depend on your systems for tickets, logbooks, etc. Sole that first and this should become evident. > 4) Manual tests they start their day with and what they automate (common > stuff) This will vary on the business and what's on-site; I can't advise you to always include the genset is you don't have one. > 5) Change management best practices and working with operations/engineering > when a change will be implemented Standing maintenance windows (of varying severity if that matters yo your business), clear definition of what needs to be done only duringthose and what can be done anytime [hint: policy tuning shouldn't be restructed to them, and you shouldn't make it so an urgent things like a BGP leak can't be fixed]. Linear rather than parallel workflows for approval, and not too many approval stages else your staff will be spending time trying to get things through the administrative stages instead of actual work. Very simply, have a standard for specifying what needs to be done, the minimal tests needed to verify success, and how you fallback if you fail the tests. If someone can't specify it and insist on frobbing around, they likely don't understand the problem or the needed work. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From khatfield at socllc.net Sat Jul 17 17:01:45 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Sat, 17 Jul 2010 22:01:45 +0000 Subject: NOC Best Practices In-Reply-To: <1347941069-1279398033-cardhu_decombobulator_blackberry.rim.net-244588648-@bda2730.bisx.prod.on.blackberry> References: <20100717185604.GA41823@gweep.net><1347941069-1279398033-cardhu_decombobulator_blackberry.rim.net-244588648-@bda2730.bisx.prod.on.blackberry> Message-ID: <282252414-1279404107-cardhu_decombobulator_blackberry.rim.net-115058073-@bda903.bisx.prod.on.blackberry> eTOM is best regarded as a companion to ITIL practices. It has additional layers not covered by ITIL and vice versa. I think a combination of practices from both is the best method. -Kevin -----Original Message----- From: "Xavier Banchon" Date: Sat, 17 Jul 2010 20:20:26 To: ; Kasper Adel Reply-To: xbanchon at telconet.net Cc: NANOG list Subject: Re: NOC Best Practices What about e-TOM? Is it better than ITIL V3? Regards, Xavier Telconet S.A -----Original Message----- From: Joe Provo Date: Sat, 17 Jul 2010 14:56:04 To: Kasper Adel Reply-To: nanog-post at rsuc.gweep.net Cc: NANOG list Subject: Re: NOC Best Practices On Fri, Jul 16, 2010 at 09:34:53PM +0300, Kasper Adel wrote: > Thanks for all the people that replied off list, asking me to send them > responses i will get. [snip] > Which is useful but i am looking for more stuff from the best people that > run the best NOCs in the world. > > So i'm throwing this out again. > > I am looking for pointers, suggestions, URLs, documents, donations on what a > professional NOC would have on the below topics: A lot, as others have said, depending on the business, staffing, goals, SLA, contracts, etc. > 1) Briefly, how they handle their own tickets with vendors or internal Run a proper ticketing system over which you have control (RT and friends rather than locking you into something you have to pay for changes). Don't just by ticket closure rate, judge by succesfully resolving problems. Encourage folks to use the system for tracking projects and keeping notes on work in progress rather than private datastores. Inculcate a culture of open exploration to solve problems rather than rote memorization. This gets you a large way to #2. > 2) How they create a learning environment for their people (Documenting > Syslog, lessons learned from problems...etc) Mentoring, shoulder surfing. Keep your senior people in the mix of triage & response so they don't get dull and cross-pollenate skills. When someone is new, have their probationary period be shadowing the primary on-call the entire time. Your third shift [or whatever spans your maintenance windows] should be the folks who actually wind up executing well-specified maintenances (with guidance as needed) and be the breeding ground of some of your better hands-on folks. > 3) Shift to Shift hand over procedures This will depend on your systems for tickets, logbooks, etc. Sole that first and this should become evident. > 4) Manual tests they start their day with and what they automate (common > stuff) This will vary on the business and what's on-site; I can't advise you to always include the genset is you don't have one. > 5) Change management best practices and working with operations/engineering > when a change will be implemented Standing maintenance windows (of varying severity if that matters yo your business), clear definition of what needs to be done only duringthose and what can be done anytime [hint: policy tuning shouldn't be restructed to them, and you shouldn't make it so an urgent things like a BGP leak can't be fixed]. Linear rather than parallel workflows for approval, and not too many approval stages else your staff will be spending time trying to get things through the administrative stages instead of actual work. Very simply, have a standard for specifying what needs to be done, the minimal tests needed to verify success, and how you fallback if you fail the tests. If someone can't specify it and insist on frobbing around, they likely don't understand the problem or the needed work. Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jul 17 21:47:26 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 18 Jul 2010 12:17:26 +0930 Subject: Vyatta as a BRAS In-Reply-To: References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> Message-ID: <20100718121726.3a2c78ac@opy.nosense.org> On Wed, 14 Jul 2010 14:12:07 +0000 "Dobbins, Roland" wrote: > > On Jul 14, 2010, at 8:48 PM, Florian Weimer wrote: > > > From or to your customers? > > Both. > > > Stopping customer-sourced attacks is probably a good thing for the Internet at learge. > > Concur 100%. > > > And you can't combat attacks targeted at customers within your own network unless you've got very large WAN > > pipes, moving you into the realm of special-purpose hardware for other reasons. > > Sure, you can, via S/RTBH, IDMS, et. al. While DNS reflection/amplification attacks are used to create crushing volumes of attack traffic, and even smallish botnets can create high-volume attacks, most packet-flooding attacks are predicated on throughput - i.e., pps - rather than bandwidth, and tend to use small packets. Of course, they can use *lots and lots* of small packets, and often do, but one can drop these packets via the various mechanisms one has available, then reach out to the global opsec community for filtering closer to the sources. > > The thing is, with many DDoS attacks, the pps/bps/cps/tps required to disrupt the targets can be quite small, due to the unpreparedness of the defenders. Many high-profile attacks discussed in the press such as the Mafiaboy attacks, the Estonian attacks, the Russian/Georgian/Azerbaijan attacks, the China DNS meltdown, and the RoK/USA DDoS attacks were all a) low-volume, b) low-throughput, c) exceedingly unsophisticated, and d) eminently avoidable via sound architecture, deployment of BCPs, and sound operational practices. > > In fact, many DDoS attacks are quite simplistic in nature and many are low in bandwidth/throughput; the miscreants only use the resources necessary to achieve their goals, and due to the unpreparedness of defenders, they don't have a need to make use of overwhelming and/or complex attack methodologies. > > This doesn't mean that high-bandwidth, high-throughput, and/or complex DDoS attacks don't occur, or that folks shouldn't be prepared to handle them; quite the opposite, we see a steady increase in attack volume, thoughput and sophistication at the high end. But the fact of the matter is that many DDoS targets - and associated network infrastructure, and services such as DNS - are surprisingly fragile, and thus are vulnerable to surprisingly simple/small attacks, or even inadvertent/accidental attacks. > > > Previously, this was really a no-brainer because you couldn't get PCI > > cards with the required interfaces, but with Ethernet everywhere, the > > bandwidths you can handle on commodity hardware will keep increasing. > > Concur 100%. > > > Eventually, you'll need special-purpose hardware only for a smallish > > portion at the top of the router market, or if you can't get the > > software with the required protocol support on other devices. > > I believe that the days of software-based routers are numbered, period, due to the factors you describe. Of course, the 'top of the router market' seems to keep moving upwards, despite many predictions to the contrary. > Since specific routers have been mentioned, care to comment on the Cisco ASR? If the days of software-based routers are numbered, I'm sure Cisco would have recognised that, and not gone and developed it (or rather, bought the company that did). It seems to me that three key factors that haven't been discussed in this thread are the chances of failure, types of failure triggers and consequence of failure. It seems to have been a binary hardware = no failure, software = failure. If you put large amounts of traffic on a single router, you're likely to need a hardware router, driving up the cost, sacrificing flexibility and re-deployability, and impacting very large numbers of network users if it fails. You may not be vulnerable or as vulnerable to a DoS (software punt mentioned), but DoS's aren't the only type of failure you can suffer from. Software faults on these high end platforms can be a far more common issue within the first few years of release, because they're less widely deployed. Hardware forwarding doesn't protect you from protocol or protocol implementation vulnerabilities on the control plane, and since these are big boxes with a big consequence if they fail, they're a much larger target to aim for. OTOH, if you have options to divide the traffic load across a number of smaller routers, then you may gain the cost effectiveness of more commodity platforms (with the ultimate commodity platform being a PC acting as a router), more robustness because the platform is being used by far more people in far more environments, and less of a consequence when failures occur (DoS or not). I don't think the hardware/software augment is as simple as it is being made out to be. It is completely context dependent. Cost, availability, scalability and flexibility all need to be considered. I personally put a fair bit of weight on flexibility, because I can't tell the future, and therefore a software upgrade to an existing platform is a useful property compared to a fork lift replacement, and a box now sitting on the floor that can't be re-deployed anywhere else in the network. As long as you're aware of the associated limitations, you may be able to engineer around them, or around them enough, depending on the context. > ----------------------------------------------------------------------- > Roland Dobbins // > > Injustice is relatively easy to bear; what stings is justice. > > -- H.L. Mencken > > > > From rdobbins at arbor.net Sun Jul 18 04:58:17 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 18 Jul 2010 09:58:17 +0000 Subject: Vyatta as a BRAS In-Reply-To: <20100718121726.3a2c78ac@opy.nosense.org> References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> Message-ID: <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> On Jul 18, 2010, at 9:47 AM, Mark Smith wrote: > Since specific routers have been mentioned, care to comment on the Cisco ASR? ASR1K, which is what I'm assuming you're referring to, is a hardware-based router. Same for ASR9K. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From nick at foobar.org Sun Jul 18 12:12:29 2010 From: nick at foobar.org (Nick Hilliard) Date: Sun, 18 Jul 2010 18:12:29 +0100 Subject: Vyatta as a BRAS In-Reply-To: <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> Message-ID: On 18 Jul 2010, at 10:58, "Dobbins, Roland" wrote: > ASR1K, which is what I'm assuming you're referring to, is a hardware-based router. Same for ASR9K. My c* SE swears that the asr1k is a "software router". I didn't push him on it's architecture though. The asr9k is an npu based device - a completely different beast with different architecture / operating system / capabilities / etc. Nick From rbf+nanog at panix.com Sun Jul 18 12:55:23 2010 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 18 Jul 2010 12:55:23 -0500 Subject: Vyatta as a BRAS In-Reply-To: References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> Message-ID: <20100718175523.GA10166@panix.com> On Sun, Jul 18, 2010 at 06:12:29PM +0100, Nick Hilliard wrote: > On 18 Jul 2010, at 10:58, "Dobbins, Roland" wrote: > > ASR1K, which is what I'm assuming you're referring to, is a > > hardware-based router. Same for ASR9K. > > My c* SE swears that the asr1k is a "software router". I didn't push > him on it's architecture though. All routers have hardware, and any but the most overwhelmingly simple "hardware" based devices are using ASICs running software to puah packets around. The line has been blurred for a long time, and the ASR1K makes it very, very blurry. It forwards packets in a relatively general-purpose (but not as general purpose as, say the Intel processors inside your servers) CPU that has 40 cores and is optimised (it's architecture, instruction set, etc.) for moving packets around. Is that hardware forwarding? Is that software forwarding? Depends in what you want to call it. Do video cards with high-end GPUs do things in "hardware" or "software"? There are now development kits to allow you to easily use those GPUs to do general purpose compute tasks. The processors in the ASR could do that, also, but Cisco hasn't written any code or released ay libraries to actually do that (at lease not publicly; I wouldn't be surprised to learn that some developer has hacked a 40-threaded SETI at Home or something like that onto it just to prove it could be done). So where do you draw the line? Is the ASR hardware forwarding? If so, would it still be hardware if, intead of the specialized processor, Cisco got Intel to develop a 40-core pentium and used that? What if Cisco instead used 10 off-the-shelf 4-core processors from Intel or AMD? Where along this continuoum do we cross the line from "software router" to "hardware router"? -- Brett From rdobbins at arbor.net Sun Jul 18 15:42:59 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 18 Jul 2010 20:42:59 +0000 Subject: Vyatta as a BRAS In-Reply-To: <20100718175523.GA10166@panix.com> References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> <20100718175523.GA10166@panix.com> Message-ID: <00CAA74D-03DE-4AC5-9DB5-067F8D3768F2@arbor.net> On Jul 19, 2010, at 1:55 AM, Brett Frankenberger wrote: > So where do you draw the line? Is the ASR hardware forwarding? Yes - specialized muticore NPU plus TCAM. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rdobbins at arbor.net Sun Jul 18 15:43:58 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 18 Jul 2010 20:43:58 +0000 Subject: Vyatta as a BRAS In-Reply-To: References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> Message-ID: On Jul 19, 2010, at 1:12 AM, Nick Hilliard wrote: > My c* SE swears that the asr1k is a "software router". I didn't push him on it's architecture though. Specialized multicore NPU + TCAM = hardware. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From dot at dotat.at Sun Jul 18 16:22:37 2010 From: dot at dotat.at (Tony Finch) Date: Sun, 18 Jul 2010 22:22:37 +0100 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: References: <20100716145315.GA19935@ussenterprise.ufp.org> <20100716153233.GA1137974@hiwaay.net> <4C40A12A.8050201@bogus.com> Message-ID: On Fri, 16 Jul 2010, Jeffrey Ollie wrote: > > The ITAR anchors.xml and anchors2keys use a different XML schema than > the root-anchors.xml does. *sigh* Tony. -- f.anthony.n.finch http://dotat.at/ NORTHWEST FITZROY SOLE: SOUTHWESTERLY 5 OR 6, DECREASING 3 OR 4 LATER. MODERATE OR ROUGH. RAIN, SHOWERS LATER. MODERATE OR POOR, BECOMING GOOD LATER. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jul 18 16:43:46 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 19 Jul 2010 07:13:46 +0930 Subject: Vyatta as a BRAS In-Reply-To: References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> Message-ID: <20100719071346.49b500f3@opy.nosense.org> On Sun, 18 Jul 2010 18:12:29 +0100 Nick Hilliard wrote: > On 18 Jul 2010, at 10:58, "Dobbins, Roland" wrote: > > ASR1K, which is what I'm assuming you're referring to, is a hardware-based router. Same for ASR9K. > > My c* SE swears that the asr1k is a "software router". I didn't push him on it's architecture though. > This document supports that. If the definition of a software router is one that doesn't have a fixed at the factory forwarding function, then the ASR1K is one. http://www.cisco.com/en/US/prod/collateral/routers/ps9343/solution_overview_c22-448936.html The CRS-3 might be too, as they say they've added the quantumflow processor into those too. > The asr9k is an npu based device - a completely different beast with different architecture / operating system / capabilities / etc. > > Nick From rdobbins at arbor.net Sun Jul 18 17:07:57 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 18 Jul 2010 22:07:57 +0000 Subject: Vyatta as a BRAS In-Reply-To: <20100719071346.49b500f3@opy.nosense.org> References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> <20100719071346.49b500f3@opy.nosense.org> Message-ID: <4E0162C5-8B2A-4E89-9310-EE34F8D4D0D6@arbor.net> On Jul 19, 2010, at 5:43 AM, Mark Smith wrote: > This document supports that. No, it doesn't. Specialized NPUs, TCAMs present in ASR1K. CRS-3 has specialized NPUs, ASICs, as well. Enough on this topic - it's obvious that both ASR1K and CRS-3 are hardware-based platforms. ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From rbf+nanog at panix.com Sun Jul 18 19:01:56 2010 From: rbf+nanog at panix.com (Brett Frankenberger) Date: Sun, 18 Jul 2010 19:01:56 -0500 Subject: Vyatta as a BRAS In-Reply-To: <20100719071346.49b500f3@opy.nosense.org> References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> <20100719071346.49b500f3@opy.nosense.org> Message-ID: <20100719000156.GA1312@panix.com> On Mon, Jul 19, 2010 at 07:13:46AM +0930, Mark Smith wrote: > > This document supports that. If the definition of a software router is > one that doesn't have a fixed at the factory forwarding function, then > the ASR1K is one. The code running in the ASICs on line cards in 6500-series chassis isn't fixed at the factory. Same with the code running on the PFCs in those boxes. There's not a tremendous amount of flexibility to make changes after the fact, because the code is so tightly integrated with the hardware, but there is some. (Not saying the 6500 is a software-based platform. It's pretty clearly a hardware-based platform under most peoples' definition. But: the line is blurry.) -- Brett From tdurack at gmail.com Sun Jul 18 20:07:36 2010 From: tdurack at gmail.com (Tim Durack) Date: Sun, 18 Jul 2010 21:07:36 -0400 Subject: Vyatta as a BRAS In-Reply-To: <20100719000156.GA1312@panix.com> References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> <20100719071346.49b500f3@opy.nosense.org> <20100719000156.GA1312@panix.com> Message-ID: On Sun, Jul 18, 2010 at 8:01 PM, Brett Frankenberger wrote: > On Mon, Jul 19, 2010 at 07:13:46AM +0930, Mark Smith wrote: >> >> This document supports that. If the definition of a software router is >> one that doesn't have a fixed at the factory forwarding function, then >> the ASR1K is one. > > The code running in the ASICs on line cards in 6500-series > chassis isn't fixed at the factory. ?Same with the code running on the > PFCs in those boxes. ?There's not a tremendous amount of flexibility to > make changes after the fact, because the code is so tightly integrated > with the hardware, but there is some. > > (Not saying the 6500 is a software-based platform. ?It's pretty clearly > a hardware-based platform under most peoples' definition. ?But: ?the > line is blurry.) > > ? ? -- Brett > > Surely the important point for most forwarding engines is that there is isolation between control, management and forwarding planes? If I'm looking for a box, I want line rate forwarding on all interfaces. I want stateless ACLs and policing functions on the forwarding plane. I want to use those functions to protect the control and management planes. I want the control plane to cope with the required amount of forwarding state and churn. I want the management plane to be somewhat as capable as the Linux tools I run to maintain the network. I don't honestly care whether it is a single cpu, multi-core multi-cpu, ASIC or NPU. That being said, for the networks I help maintain, the C6K meets most of those requirements. I think the N7K is movement in the right direction. I consider both to be L2/L3 switches :-) -- Tim:> From truman at suspicious.org Sun Jul 18 20:09:43 2010 From: truman at suspicious.org (Truman Boyes) Date: Mon, 19 Jul 2010 11:09:43 +1000 Subject: virtual switches In-Reply-To: <7AFBB29F-2CDB-40F7-86B1-E2CAF16DC7C5@oicr.on.ca> References: <7AFBB29F-2CDB-40F7-86B1-E2CAF16DC7C5@oicr.on.ca> Message-ID: <5C18AFC5-3D20-4DA8-87B9-EF7826631039@suspicious.org> On 17/07/2010, at 2:18 AM, Greg Whynott wrote: > Cisco has VSS (on 6500 class) and H3C has IRF; allowing you to virtualize 2 or more physical switches/routers in an active/active configuration where you can use all links and terminate LACP aggregates between the two devices. Is anyone using this or similar technology from another vendor? any recommendations or comments would be appreciated. thanks very much for your time! > > -g Juniper also has Virtual Chassis support on the EX-series. The MX also supports active/active multi chassis-LAG. It works as you would expect, as you setup an ICCP link between the MX's. Truman From drais at icantclick.org Sun Jul 18 22:31:15 2010 From: drais at icantclick.org (david raistrick) Date: Sun, 18 Jul 2010 23:31:15 -0400 (EDT) Subject: virtual switches In-Reply-To: <5C18AFC5-3D20-4DA8-87B9-EF7826631039@suspicious.org> References: <7AFBB29F-2CDB-40F7-86B1-E2CAF16DC7C5@oicr.on.ca> <5C18AFC5-3D20-4DA8-87B9-EF7826631039@suspicious.org> Message-ID: On Mon, 19 Jul 2010, Truman Boyes wrote: >> Cisco has VSS (on 6500 class) and H3C has IRF; allowing you to >> virtualize 2 or more physical switches/routers in an active/active >> configuration > Juniper also has Virtual Chassis support on the EX-series. The MX also > supports active/active multi chassis-LAG. It works as you would expect, I seem to recall that both of these implementations suffer from some significant limitations around how/what you can do with them, as well as HA options...though that's all I can remember from digging into it (enough to realize it wouldn't work for us) last year. OTOH, Raptor's "virtual chassis" magic (while it has its own issues...) didn't have these problems. :) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From oleg.albegov at gmail.com Mon Jul 19 02:27:39 2010 From: oleg.albegov at gmail.com (Oleg Albegov) Date: Mon, 19 Jul 2010 11:27:39 +0400 Subject: virtual switches In-Reply-To: <7AFBB29F-2CDB-40F7-86B1-E2CAF16DC7C5@oicr.on.ca> References: <7AFBB29F-2CDB-40F7-86B1-E2CAF16DC7C5@oicr.on.ca> Message-ID: BTW, with VSS you can only combine 2 switches. 2010/7/16 Greg Whynott > Cisco has VSS (on 6500 class) and H3C has IRF; allowing you to virtualize > 2 or more physical switches/routers in an active/active configuration where > you can use all links and terminate LACP aggregates between the two devices. > Is anyone using this or similar technology from another vendor? any > recommendations or comments would be appreciated. thanks very much for your > time! > > -g > > > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Jul 19 04:38:52 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 19 Jul 2010 19:08:52 +0930 Subject: Vyatta as a BRAS In-Reply-To: References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> <20100719071346.49b500f3@opy.nosense.org> <20100719000156.GA1312@panix.com> Message-ID: <20100719190852.5c6acfcc@opy.nosense.org> On Sun, 18 Jul 2010 21:07:36 -0400 Tim Durack wrote: > On Sun, Jul 18, 2010 at 8:01 PM, Brett Frankenberger > wrote: > > On Mon, Jul 19, 2010 at 07:13:46AM +0930, Mark Smith wrote: > >> > >> This document supports that. If the definition of a software router is > >> one that doesn't have a fixed at the factory forwarding function, then > >> the ASR1K is one. > > > > The code running in the ASICs on line cards in 6500-series > > chassis isn't fixed at the factory. ?Same with the code running on the > > PFCs in those boxes. ?There's not a tremendous amount of flexibility to > > make changes after the fact, because the code is so tightly integrated > > with the hardware, but there is some. > > > > (Not saying the 6500 is a software-based platform. ?It's pretty clearly > > a hardware-based platform under most peoples' definition. ?But: ?the > > line is blurry.) > > > > ? ? -- Brett > > > > > > Surely the important point for most forwarding engines is that there > is isolation between control, management and forwarding planes? > > If I'm looking for a box, I want line rate forwarding on all > interfaces. I want stateless ACLs and policing functions on the > forwarding plane. I want to use those functions to protect the control > and management planes. I want the control plane to cope with the > required amount of forwarding state and churn. I want the management > plane to be somewhat as capable as the Linux tools I run to maintain > the network. And that's the crux of the issue. Can the box survive if line rate maximum PPS is being aimed at it, either for forwarding or at the control plane? If the answer is yes, then whether it is a "software router" or "hardware router" is academic. > > I don't honestly care whether it is a single cpu, multi-core > multi-cpu, ASIC or NPU. > > That being said, for the networks I help maintain, the C6K meets most > of those requirements. I think the N7K is movement in the right > direction. I consider both to be L2/L3 switches :-) > > -- > Tim:> From sil at infiltrated.net Mon Jul 19 07:06:08 2010 From: sil at infiltrated.net (J. Oquendo) Date: Mon, 19 Jul 2010 08:06:08 -0400 Subject: On another security note... (of sorts) In-Reply-To: <384B29B4-B24B-4EF4-BCCB-F87CE505151D@arbor.net> References: <4C3F5632.4080408@csuohio.edu> <201007161042.40853.lowen@pari.edu> <384B29B4-B24B-4EF4-BCCB-F87CE505151D@arbor.net> Message-ID: <4C443FB0.8000602@infiltrated.net> Dobbins, Roland wrote: > > The thorniest issues aren't technology-related, per se; they're legal exposure (both real and imagined), regulatory concerns (both real and imagined), antitrust concerns (both real and imagined), management/marketing/PR concerns (largely imagined), skillset shortages/concerns (very real), customer perception concerns (both real and imagined), and so forth. Legal issues for a situation like this can easily be resolved however the problem boils down to who is willing to become "case law." There aren't many laws surrounding this topic. Antitrust and regulatory issues too can be trumped when businesses collectively conclude that its for the best interest of everyone. I believe that too many perceive this imaginatory 'brick wall' coming down on them and often take a step back choosing to do nothing then coming back and wondering why they're businesses are now listed on DataLossDB.org. Customer perceptions and concerns very real? I'm curious to know what your perception is. As a customer *somewhere* down the line, if a business slash vendor told me they were working with other businesses to deter/minimize fraud, I'd be all for it. I can think of any situation where I would come around to a grinding halt: E.g.: From Starbucks: "We're working with SEARS to minimize theft/fraud..." me: "OMG No! You better not work to make sure thieves don't get ahold of my data!" I didn't follow that glaringly big "very real." If you mean on the bits side of things... E.g. (myself working at an ITSP) My competitor: "We're working to make an attacker database to defend ourselves from toll-fraudsters, care to join?" ... Me: "No way in hell I'm going to defend myself because you're seeing more attacks. Thanks but no thanks!" Maybe naivete on my part, but I don't see how customers would have issues if the scenario/framework was concisely explained. > The second tier of barriers are those surrounding trust. It's basically a sociological analogue of 'the PKI problem'. Anyone here not peering, raise your hand?! Sure there will be trust issues, those too can be overcome. A "vetting" process could be implemented and selected individuals can be "voted" in or out. We "trust" NANOG to select the best individual to moderate this list. At the granular level, I don't know anything about the moderator, yet I trust my peers knew enough to give them a vote of confidence. Should I go back and and create a dossier on the moderator or should I trust my peers. I think for the most part it's a "so far so good" situation. Life goes on until otherwise noted. > Technology issues form the third set of barriers. Yes, they're real and they're important, but if we could wiggle our noses a la Elizabeth Montgomery and make all the technology issues go away, the other sets of issues would still preclude any kind of universal solution, for some value of 'solution'. Here is a semi-universal solution... Throw an N-Byte field into the TCP protocol and label it "dirty" the dirty bit. The dirty bit would be for a combination of a host and or other identifier which came into the radar N amount of times. The dirty bit would automatically get populated into every routing table X amount of time where if a "dirty bit" tried to route traffic from ANYWHERE, after some time, even its own TCP stack wouldn't let it route out. Even the collaboration of about 12 major companies (MS, Cisco, Juniper, Sun, IBM) would likely cut the likelihood of attacks to probably in the teen percentile. > That's one of the reasons why a lot of people who make sweeping generalizations and recommendations about 'cyber-this' and 'cyber-that' tend not to have a good grasp of even the fundamentals - they aren't the folks who do the actual work, they don't know who does the actual work, and they often don't know anybody who knows somebody who actually does the actual work. They often don't even know that actual work is taking place, or what it entails, in the first place, because the actual work takes place out of the limelight. Acknowledged... Still I believe a framework (anti-malicious/pattern-matching/dirty-host) is long overdue. I also believe far too many people take the "NIMBY" approach and make excuses as opposed to solutions. This is seriously evident based on the amount of responses to something which is (I perceive to be) mission critical. Moreso than arguing over the pros and cons of NOT doing anything. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From rdobbins at arbor.net Mon Jul 19 07:12:42 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 19 Jul 2010 12:12:42 +0000 Subject: On another security note... (of sorts) In-Reply-To: <4C443FB0.8000602@infiltrated.net> References: <4C3F5632.4080408@csuohio.edu> <201007161042.40853.lowen@pari.edu> <384B29B4-B24B-4EF4-BCCB-F87CE505151D@arbor.net> <4C443FB0.8000602@infiltrated.net> Message-ID: On Jul 19, 2010, at 8:06 PM, J. Oquendo wrote: > Here is a semi-universal solution... Throw an N-Byte field into the TCP protocol and label it "dirty" the dirty bit. ;> ----------------------------------------------------------------------- Roland Dobbins // Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken From brunner at nic-naa.net Mon Jul 19 08:16:19 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 19 Jul 2010 09:16:19 -0400 Subject: On another security note... (of sorts) In-Reply-To: <384B29B4-B24B-4EF4-BCCB-F87CE505151D@arbor.net> References: <4C3F5632.4080408@csuohio.edu> <201007161042.40853.lowen@pari.edu> <384B29B4-B24B-4EF4-BCCB-F87CE505151D@arbor.net> Message-ID: <4C445023.2060900@nic-naa.net> On 7/16/10 11:17 PM, Dobbins, Roland wrote: > The thorniest issues aren't technology-related, per se; they're legal exposure (both real and imagined), regulatory concerns (both real and imagined), antitrust concerns (both real and imagined), management/marketing/PR concerns (largely imagined), skillset shortages/concerns (very real), customer perception concerns (both real and imagined), and so forth. >... I recommend kc.claffy's notes on the subject: Ten Things the FCC Should Know about the Internet http://www.caida.org/publications/presentations/2009/top_ten_fcc/top_ten_fcc.pdf and top ten things lawyers should know about the Internet http://blog.caida.org/best_available_data/2008/04/16/top-ten-things-lawyers-should-know-about-internet-research-1/ Eric From Valdis.Kletnieks at vt.edu Mon Jul 19 09:21:56 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 19 Jul 2010 10:21:56 -0400 Subject: On another security note... (of sorts) In-Reply-To: Your message of "Mon, 19 Jul 2010 08:06:08 EDT." <4C443FB0.8000602@infiltrated.net> References: <4C3F5632.4080408@csuohio.edu> <201007161042.40853.lowen@pari.edu> <384B29B4-B24B-4EF4-BCCB-F87CE505151D@arbor.net> <4C443FB0.8000602@infiltrated.net> Message-ID: <64253.1279549316@localhost> On Mon, 19 Jul 2010 08:06:08 EDT, "J. Oquendo" said: > Maybe naivete on my part, but I don't see how customers would have > issues if the scenario/framework was concisely explained. It's one thing to be sitting in my office rationally discussing what my bank does to prevent credit card fraud, and almost nobody will disagree with the concept that the bank should try to prevent fraud. However... It's quite another when I'm driving to my brother's funeral, stop to get gas in the middle of the night. For some reason, they go ahead and pump the gas before running the credit card, and after they've pumped nearly a full tank of gase, my credit card is declined and flagged (I find out later) by my bank's anti-fraud group because it's being used 3 states away from where it's usually used. Since they don't take checks, I'm forced to use pretty much all the cash I was planning to use for tolls/etc so I had to find a way to Long Island without paying any tolls because the stupid card wasn't working in ATMs in the area either. Driving around Trenton (where I've never been before) at 3AM trying to find the construction detour from I-295 to Route 1 because my map says that's my best free way to LI wasn't my idea of fun... Fortunately for my sanity, I was able to get hold of them the next morning and convinced them I was me by having them call me back on the phone number they already had for me - if somebody in their fraud group had realized that if the credit card was stolen, the cell phone might be as well, I'd have been screwed... Understand now how customers might have isssues? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From william.allen.simpson at gmail.com Mon Jul 19 11:14:12 2010 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 19 Jul 2010 12:14:12 -0400 Subject: On another security note... (of sorts) In-Reply-To: <64253.1279549316@localhost> References: <4C3F5632.4080408@csuohio.edu> <201007161042.40853.lowen@pari.edu> <384B29B4-B24B-4EF4-BCCB-F87CE505151D@arbor.net> <4C443FB0.8000602@infiltrated.net> <64253.1279549316@localhost> Message-ID: <4C4479D4.1060301@gmail.com> On 7/19/10 10:21 AM, Valdis.Kletnieks at vt.edu wrote: > ... my credit card is declined and flagged (I find out later) by my bank's > anti-fraud group because it's being used 3 states away from where it's usually > used. ... > Or in my recent case, I used my card multiple times in California in April, and the next time was trying to make a *deposit* back home in Michigan a month or so later. Card rejected. > Fortunately for my sanity, I was able to get hold of them the next morning and > convinced them I was me by having them call me back on the phone number they > already had for me - if somebody in their fraud group had realized that if the > credit card was stolen, the cell phone might be as well, I'd have been > screwed... > Unfortunately, I had to go to a credit union branch, and have them call the main office after showing my drivers license for picture proof.... And that meant I had to wait 3 days for the office to be open after the holiday! > Understand now how customers might have isssues? > Yep, most simple algorithms are severely flawed. Doesn't mean there couldn't be better algorithms. And an understanding that banking is just the same as a grocery store or a mall -- or an ISP.... From tglassey at earthlink.net Mon Jul 19 13:25:55 2010 From: tglassey at earthlink.net (todd glassey) Date: Mon, 19 Jul 2010 11:25:55 -0700 Subject: replacement SSG550 Firmware Image Message-ID: <4C4498B3.4020108@earthlink.net> I just inherited a 550 from our old stash of Juniper and find that someone corrupted the flash image. Anyone know where there is a replacement image online? - contact me off list please. Todd Glassey From markk at arin.net Mon Jul 19 15:53:18 2010 From: markk at arin.net (Mark Kosters) Date: Mon, 19 Jul 2010 16:53:18 -0400 Subject: Whois-RWS Released 17 July 2010 Message-ID: <20100719205318.GA64924@arin.net> ----- Forwarded message from Member Services ----- From: Member Services Date: Mon, 19 Jul 2010 13:27:32 -0400 To: "arin-announce at arin.net" Subject: [arin-announce] Whois-RWS Released 17 July 2010 ARIN is pleased to announce the release of Whois-RWS. ARIN's Whois RESTful Web Service (Whois-RWS) is the directory service for accessing registration data contained within ARIN's registration database. Whois-RWS provides several improvements over ARIN's previous Whois service. Whois-RWS can easily be integrated into command line scripts similar to Whois or RWhois, or it can be accessed with a web browser. For those who rely on existing scripts and clients, ARIN will continue to maintain services for the NICNAME/WHOIS protocol on TCP/43. This is achieved by using a proxy service to translate traditional ARIN Whois queries into Whois-RWS queries. View service differences, a Whois-RWS FAQ, and API documentation at: https://www.arin.net/resources/whoisrws/ Important details on other features in development can be found at: https://www.arin.net/features/ Please send any questions, comments, or issues to: hostmaster at arin.net. Regards, Mark Kosters Chief Technical Officer American Registry for Internet Numbers (ARIN) ----- End forwarded message ----- From bora at pnl.gov Mon Jul 19 16:40:07 2010 From: bora at pnl.gov (Akyol, Bora A) Date: Mon, 19 Jul 2010 14:40:07 -0700 Subject: Vyatta as a BRAS In-Reply-To: <20100719190852.5c6acfcc@opy.nosense.org> References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> <20100719071346.49b500f3@opy.nosense.org> <20100719000156.GA1312@panix.com> <20100719190852.5c6acfcc@opy.nosense.org> Message-ID: Except that the goal you set below is very very hard to do on a software router unless its CPU has packet classification properties implemented in HW. In some systems, just the act of receiving the packet in the ISR and classifying it into a bucket is enough to overwhelm the system without proper hardware assist. Bora -----Original Message----- From: Mark Smith [mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Monday, July 19, 2010 2:39 AM To: Tim Durack Cc: NANOG list Subject: Re: Vyatta as a BRAS And that's the crux of the issue. Can the box survive if line rate maximum PPS is being aimed at it, either for forwarding or at the control plane? If the answer is yes, then whether it is a "software router" or "hardware router" is academic. From LarrySheldon at cox.net Mon Jul 19 17:15:15 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 19 Jul 2010 17:15:15 -0500 Subject: While we worry about Vyatta and Bras..... Message-ID: <4C44CE73.6070202@cox.net> ..in other news (that seems to have attracted little attention)... http://www.moonbattery.com/archives/2010/07/73000-blogs-shu.html 73000 Internet "sites" where shutdown by somebody, for something. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From joe at nethead.com Mon Jul 19 17:21:17 2010 From: joe at nethead.com (Joe Hamelin) Date: Mon, 19 Jul 2010 15:21:17 -0700 Subject: While we worry about Vyatta and Bras..... In-Reply-To: <4C44CE73.6070202@cox.net> References: <4C44CE73.6070202@cox.net> Message-ID: On Mon, Jul 19, 2010 at 3:15 PM, Larry Sheldon wrote: > ..in other news (that seems to have attracted little attention)... > > http://www.moonbattery.com/archives/2010/07/73000-blogs-shu.html > > 73000 Internet "sites" where shutdown by somebody, for something. http://yro.slashdot.org/story/10/07/19/2052202/Blogetery-Shutdown-Due-To-al-Qaeda-Info The single host/box had bomb making info and hit lists. Yeah, I'd shut it down too if it was on my network. Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From LarrySheldon at cox.net Mon Jul 19 17:25:10 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 19 Jul 2010 17:25:10 -0500 Subject: While we worry about Vyatta and Bras..... In-Reply-To: References: <4C44CE73.6070202@cox.net> Message-ID: <4C44D0C6.8020304@cox.net> On 7/19/2010 17:21, Joe Hamelin wrote: > On Mon, Jul 19, 2010 at 3:15 PM, Larry Sheldon wrote: >> ..in other news (that seems to have attracted little attention)... >> >> http://www.moonbattery.com/archives/2010/07/73000-blogs-shu.html >> >> 73000 Internet "sites" where shutdown by somebody, for something. > > > http://yro.slashdot.org/story/10/07/19/2052202/Blogetery-Shutdown-Due-To-al-Qaeda-Info > > The single host/box had bomb making info and hit lists. Yeah, I'd > shut it down too if it was on my network. > > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 Seems like somebody would know who ordered it. And were all 73000 "sites" about making bombs? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml From tme at americafree.tv Mon Jul 19 17:36:57 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 19 Jul 2010 18:36:57 -0400 Subject: While we worry about Vyatta and Bras..... In-Reply-To: <4C44D0C6.8020304@cox.net> References: <4C44CE73.6070202@cox.net> <4C44D0C6.8020304@cox.net> Message-ID: <5D95BAEC-24F2-4CEB-9BF1-B43B3B78F365@americafree.tv> On Jul 19, 2010, at 6:25 PM, Larry Sheldon wrote: > On 7/19/2010 17:21, Joe Hamelin wrote: >> On Mon, Jul 19, 2010 at 3:15 PM, Larry Sheldon >> wrote: >>> ..in other news (that seems to have attracted little attention)... >>> >>> http://www.moonbattery.com/archives/2010/07/73000-blogs-shu.html >>> >>> 73000 Internet "sites" where shutdown by somebody, for something. >> >> >> http://yro.slashdot.org/story/10/07/19/2052202/Blogetery-Shutdown-Due-To-al-Qaeda-Info >> >> The single host/box had bomb making info and hit lists. Yeah, I'd >> shut it down too if it was on my network. >> >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > Seems like somebody would know who ordered it. And were all 73000 > "sites" about making bombs? Nobody ordered it from what I can tell; it was requested and the Burst site CEO decided to terminate the service. That is a rather different matter. http://news.cnet.com/8301-31001_3-20010923-261.html None of this is going to help configure any routers. Regards Marshall > > -- > Somebody should have said: > A democracy is two wolves and a lamb voting on what to have for > dinner. > > Freedom under a constitutional republic is a well armed lamb > contesting > the vote. > > Requiescas in pace o email > Ex turpi causa non oritur actio > Eppure si rinfresca > > ICBM Targeting Information: http://tinyurl.com/4sqczs > http://tinyurl.com/7tp8ml > > > > From joe at nethead.com Mon Jul 19 17:36:58 2010 From: joe at nethead.com (Joe Hamelin) Date: Mon, 19 Jul 2010 15:36:58 -0700 Subject: While we worry about Vyatta and Bras..... In-Reply-To: <4C44D0C6.8020304@cox.net> References: <4C44CE73.6070202@cox.net> <4C44D0C6.8020304@cox.net> Message-ID: On Mon, Jul 19, 2010 at 3:25 PM, Larry Sheldon wrote: > Seems like somebody would know who ordered it. And were all 73000 > "sites" about making bombs? >From TFA it was the FBI and it was one box with no back-ups. The hosting company decided to do the adult thing and pull the plug. 73k 'sites' may be a bit of a stretch IMHO. http://news.cnet.com/8301-31001_3-20010923-261.html "Sources close to the investigation say that included in those materials were the names of American citizens targeted for assassination by al-Qaeda. Messages from Osama bin Laden and other leaders of the terrorist organization, as well as bomb-making tips, were also allegedly found on the server. But Marr said a Burst.net employee erred in telling Blogetery's operator and members of the media that the FBI had ordered it to terminate Blogetery's service. He said Burst.net did that on its own. " Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From LarrySheldon at cox.net Mon Jul 19 17:41:29 2010 From: LarrySheldon at cox.net (Larry Sheldon) Date: Mon, 19 Jul 2010 17:41:29 -0500 Subject: While we worry about Vyatta and Bras..... In-Reply-To: <5D95BAEC-24F2-4CEB-9BF1-B43B3B78F365@americafree.tv> References: <4C44CE73.6070202@cox.net> <4C44D0C6.8020304@cox.net> <5D95BAEC-24F2-4CEB-9BF1-B43B3B78F365@americafree.tv> Message-ID: <4C44D499.70402@cox.net> On 7/19/2010 17:36, Marshall Eubanks wrote: > None of this is going to help configure any routers. Yeah. We gotta configure routers. Why do I keep hearing a phone ring and ring and ring? From steve at ipv6canada.com Mon Jul 19 17:52:33 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Mon, 19 Jul 2010 18:52:33 -0400 Subject: Standard for BGP community lists Message-ID: <4C44D731.5010709@ipv6canada.com> Many ISPs publish community lists that go above-and-beyond standard route selection. Is there a standard for this? ie. I want my clients to utilize my s/rtbh setup as they see fit, for themselves. I'd also like my upstreams to do the same if necessary. Is there a consensus on which communities are used for these purposes? If so, which ones? otoh, is there such an engineer/network that has a client that they trust so much that they'd enable them to null a block for you globally, via community list? Steve From nathan at atlasnetworks.us Mon Jul 19 18:08:53 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 19 Jul 2010 23:08:53 +0000 Subject: NANOG Digest, Vol 30, Issue 50 In-Reply-To: References: Message-ID: <8C26A4FDAE599041A13EB499117D3C2816452A55@ex-mb-1.corp.atlasnetworks.us> > > ..in other news (that seems to have attracted little attention)... > > > > http://www.moonbattery.com/archives/2010/07/73000-blogs-shu.html > > > > 73000 Internet "sites" where shutdown by somebody, for something. > > > http://yro.slashdot.org/story/10/07/19/2052202/Blogetery-Shutdown-Due- > To-al-Qaeda-Info > > The single host/box had bomb making info and hit lists. Yeah, I'd > shut it down too if it was on my network. > > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 As would any reasonable operator. I'm pretty disappointed that an article of the Moon Battery's very low caliber is considered by anyone to be news, especially news worth citing on NANOG. These malformed packets should have matched a mental drop rule, or at the very least, invoked a 'reputable news source' query. Or, as our icanhazcheezburger friends would say... I can haz obvious political agenda? Nathan Eisenberg, Atlas Networks From egon at egon.cc Mon Jul 19 18:31:03 2010 From: egon at egon.cc (James Downs) Date: Mon, 19 Jul 2010 16:31:03 -0700 Subject: NANOG Digest, Vol 30, Issue 50 In-Reply-To: <8C26A4FDAE599041A13EB499117D3C2816452A55@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C2816452A55@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Jul 19, 2010, at 4:08 PM, Nathan Eisenberg wrote: >> The single host/box had bomb making info and hit lists. Yeah, I'd >> shut it down too if it was on my network. >> >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > As would any reasonable operator. Or maybe it would have been better to not destroy a known source, and work with the FBI to maximize its value. Cutting it off like that was short-sighted and stupid. -j From deleskie at gmail.com Mon Jul 19 18:44:07 2010 From: deleskie at gmail.com (jim deleskie) Date: Mon, 19 Jul 2010 20:44:07 -0300 Subject: NANOG Digest, Vol 30, Issue 50 In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C2816452A55@ex-mb-1.corp.atlasnetworks.us> Message-ID: This tread is starting to sound less and less operational, or maybe I'm just old and jaded and its to out to care. You wonder if maybe his legal dept or own moral views felt its wasn't worth the risk of some joker doing something "BAD" with the info so that the FBI could get involved. On Mon, Jul 19, 2010 at 8:31 PM, James Downs wrote: > > On Jul 19, 2010, at 4:08 PM, Nathan Eisenberg wrote: > >>> The single host/box had bomb making info and hit lists. ?Yeah, I'd >>> shut it down too if it was on my network. >>> >>> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> >> As would any reasonable operator. > > Or maybe it would have been better to not destroy a known source, and work > with the FBI to maximize its value. > > Cutting it off like that was short-sighted and stupid. > > -j > > From nathan at atlasnetworks.us Mon Jul 19 18:45:13 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 19 Jul 2010 23:45:13 +0000 Subject: While we worry about Vyatta and Bras..... Message-ID: <8C26A4FDAE599041A13EB499117D3C2816452ADD@ex-mb-1.corp.atlasnetworks.us> > >> The single host/box had bomb making info and hit lists. Yeah, I'd > >> shut it down too if it was on my network. > >> > >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > > As would any reasonable operator. > > Or maybe it would have been better to not destroy a known source, and > work with the FBI to maximize its value. > > Cutting it off like that was short-sighted and stupid. > > -j (Fixing the subject line - sorry about that...) It sounds like the letter from the FBI to Burst.net specifically allowed for that possibility. "In the FBI's letter, the agency included a clause that says Web hosts and Internet service providers may voluntarily elect to shut down the sites of customers involved in these kinds of situations." Nathan Eisenberg, Atlas Networks From jeroen at mompl.net Mon Jul 19 19:21:31 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 19 Jul 2010 17:21:31 -0700 Subject: While we worry about Vyatta and Bras..... In-Reply-To: <4C44CE73.6070202@cox.net> References: <4C44CE73.6070202@cox.net> Message-ID: <4C44EC0B.4010405@mompl.net> Larry Sheldon wrote: > ..in other news (that seems to have attracted little attention)... > > http://www.moonbattery.com/archives/2010/07/73000-blogs-shu.html > > 73000 Internet "sites" where shutdown by somebody, for something. "BurstNet, the Web-hosting company, informed Blogetery's operator that service was terminated at the request of some law enforcement agency but wouldn't say which one. As for the reason, BurstNet hasn't made that clear either. In an e-mail to Blogetery's operator, BurstNet managers did say that they had little choice but to terminate service." Burstnet huh? Somehow I am not surprised. Currently I have the below in my blocklists. Since this company facilitates spammers and other dubious activity and doesn't look like it hosts much legitimate content. Maybe the shutdown was an attempt to combat spam? (yeah right!). I suggest everyone adds these to their blocklists: # Hostnoc/Burstnet - 31032010 64.120.128.0/17 64.191.0.0/17 66.96.192.0/18 66.197.128.0/17 96.9.128.0/18 173.212.192.0/18 184.82.0.0/16 I should add that I have personally found proof of brute force break in attempts to a company's systems coming from at least one of those IP ranges. -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From bdflemin at gmail.com Mon Jul 19 23:45:55 2010 From: bdflemin at gmail.com (Brad Fleming) Date: Mon, 19 Jul 2010 23:45:55 -0500 Subject: Standard for BGP community lists In-Reply-To: <4C44D731.5010709@ipv6canada.com> References: <4C44D731.5010709@ipv6canada.com> Message-ID: <0407CEDC-13D4-45E7-AB22-66E963FE76AD@gmail.com> I don't know about anyone else, but I use: 9999:9999 for local rtbh 9999:8888 for local + remote rtbh Basically, whether I should blockhole the traffic to a capture box on my network for user analysis -OR- whether I should blackhole within my network AND make a best effort to blackhole within my direct peers as well. Its obviously a sticky case since some of my direct peers don't support blackhole routing. I allow users to signal either case to me and I also offer to inject the routes on their behalf. I didn't have much reason for selecting 9999 other than it was easy to identify visually. And obviously, I have safe-guards to not leak those communities into other networks. brad On Jul 19, 2010, at 5:52 PM, Steve Bertrand wrote: > Many ISPs publish community lists that go above-and-beyond standard > route selection. > > Is there a standard for this? > > ie. I want my clients to utilize my s/rtbh setup as they see fit, for > themselves. I'd also like my upstreams to do the same if necessary. > > Is there a consensus on which communities are used for these purposes? > If so, which ones? > > otoh, is there such an engineer/network that has a client that they > trust so much that they'd enable them to null a block for you > globally, > via community list? > > Steve > > > > > > > > > From saku at ytti.fi Tue Jul 20 02:26:53 2010 From: saku at ytti.fi (Saku Ytti) Date: Tue, 20 Jul 2010 10:26:53 +0300 Subject: Standard for BGP community lists In-Reply-To: <0407CEDC-13D4-45E7-AB22-66E963FE76AD@gmail.com> References: <4C44D731.5010709@ipv6canada.com> <0407CEDC-13D4-45E7-AB22-66E963FE76AD@gmail.com> Message-ID: <20100720072653.GA25749@mx.ytti.net> On (2010-07-19 23:45 -0500), Brad Fleming wrote: Hey, > 9999:9999 for local rtbh > 9999:8888 for local + remote rtbh > > I didn't have much reason for selecting 9999 other than it was easy > to identify visually. And obviously, I have safe-guards to not leak > those communities into other networks. I would recommend against using other public ASNs for internal signalling, ASN part should be considered property of given ASN. AS9999 might want to use 9999 to signal particular source where route was learned and your customer might want to do TE with it. Now you must delete them on ingress and rob your customers of this possibility. Hopefully future community (*wink*wink*blink*blink* Raszuk) standards will explicitly state that this is faux pas. -- ++ytti From feldman at twincreeks.net Tue Jul 20 02:26:54 2010 From: feldman at twincreeks.net (Steve Feldman) Date: Tue, 20 Jul 2010 00:26:54 -0700 Subject: [NANOG-announce] Registration open for NANOG 50 - Atlanta, GA Message-ID: <265B70F2-480F-4536-9FCA-536C730D126A@twincreeks.net> Registration is now open for the 50th Meeting of the North American Network Operators' Group. NANOG 50 will be held October 3-6 in the new Loews Atlanta Hotel in Midtown. The meeting will be hosted by Telx. The meeting will be back-to-back with ARIN XXVI. A joint NANOG/ARIN program will be presented on the morning of October 6, featuring IPv6 deployment experiences. ARIN XXVI will continue through October 8. See http://www.nanog.org/meetings/nanog50/index.php for complete meeting details, and follow the important links on the left to submit presentations, register, and reserve your hotel room. Please note there are tiered rates for registration, so plan to register early to take advantage of the best rate. If you need lodging you are encouraged to make your reservation early, as rooms are limited. The NANOG group rate expires on September 15 or when filled. See you in Atlanta this fall! Steve Feldman NANOG Steering Committee Chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From bit.gossip at chello.nl Tue Jul 20 06:07:47 2010 From: bit.gossip at chello.nl (bit gossip) Date: Tue, 20 Jul 2010 13:07:47 +0200 Subject: QppB and SCU/DCU Message-ID: <1279624067.2747.7.camel@localhost> Experts, is there a standard comprising these 2 vendor specific implementations of the ~same~ feature? Thanks, bit. From tony.li at tony.li Tue Jul 20 06:50:39 2010 From: tony.li at tony.li (Tony Li) Date: Tue, 20 Jul 2010 13:50:39 +0200 Subject: Vyatta as a BRAS In-Reply-To: References: <20100713103134.AF88708A@resin07.mta.everyone.net> <82hbk2nphu.fsf@mid.bfk.de> <20100718121726.3a2c78ac@opy.nosense.org> <0A34ADE6-FCA6-4518-B5AE-3E8E92C75E9A@arbor.net> <20100719071346.49b500f3@opy.nosense.org> <20100719000156.GA1312@panix.com> <20100719190852.5c6acfcc@opy.nosense.org> Message-ID: If there is sufficient CPU power (and I/O to the CPU) as compared to the bandwidth, then this is doable. Tony On Jul 19, 2010, at 11:40 PM, Akyol, Bora A wrote: > Except that the goal you set below is very very hard to do on a software router unless its CPU has packet classification properties implemented in HW. > > In some systems, just the act of receiving the packet in the ISR and classifying it into a bucket is enough to overwhelm the system without proper hardware assist. > > Bora > > > -----Original Message----- > From: Mark Smith [mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] > Sent: Monday, July 19, 2010 2:39 AM > To: Tim Durack > Cc: NANOG list > Subject: Re: Vyatta as a BRAS > And that's the crux of the issue. Can the box survive if line rate > maximum PPS is being aimed at it, either for forwarding or at the > control plane? If the answer is yes, then whether it is a "software > router" or "hardware router" is academic. > From rsk at gsp.org Tue Jul 20 07:18:59 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 20 Jul 2010 08:18:59 -0400 Subject: While we worry about Vyatta and Bras..... In-Reply-To: <4C44EC0B.4010405@mompl.net> References: <4C44CE73.6070202@cox.net> <4C44EC0B.4010405@mompl.net> Message-ID: <20100720121859.GA13162@gsp.org> On Mon, Jul 19, 2010 at 05:21:31PM -0700, Jeroen van Aart wrote: > Burstnet huh? Somehow I am not surprised. > Currently I have the below in my blocklists. Since this company > facilitates spammers and other dubious activity and doesn't look > like it hosts much legitimate content. They've been doing a lot of both for a decade. Others have noticed as well: http://groups.google.com/group/news.admin.net-abuse.email/msg/fba14415f70e08c8 I strongly recommend blacklisting/null-routing anything they touch. ---Rsk From rjsager at gmail.com Tue Jul 20 07:59:13 2010 From: rjsager at gmail.com (Robert Sager) Date: Tue, 20 Jul 2010 08:59:13 -0400 Subject: Multicast Network Monitoring Message-ID: Curious if anyone has any experience with tools specifically for monitoring multicast. Finds where the trees are, paths they are on, tracks all senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast Manager, CA Spectrum? The good and the bad? Worth the effort/investment? Thanks From brandon.kim at brandontek.com Tue Jul 20 08:11:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 09:11:51 -0400 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From aduitsis at gmail.com Tue Jul 20 09:39:17 2010 From: aduitsis at gmail.com (Athanasios Douitsis) Date: Tue, 20 Jul 2010 17:39:17 +0300 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: On Tue, Jul 20, 2010 at 4:11 PM, Brandon Kim wrote: > > Interesting question, I'd like to know more about this myself. I'm so used > to monitoring SNMP-based > devices, never really thought about multi-casts and being able to see the > pattern/tree.... > > Shameless plug, I once developed a tool which was called multicast weathermap. You can see what remains of it here: http://netmon.grnet.gr/multicast-map.shtml (hover over the nodes and the links and you can see various useful info) (you can see the tree of a specific group by selecting from the drop down list at the bottom) and the presentation here http://tnc2004.terena.org/programme/presentations/show2c2c.html?pres_id=47 Since I too myself am into multicast, I intended to incorporate into it everything needed to know everything. But eventually it was left as it is. Apart from that, the NNM advanced used to have a multicast plugin, and it was fairly usable. You could take a look at it probably, but I don't know whether it can handle those MPLS cases you mention. Lastly, those guys at Poznan used to work on a tool called Muvi http://muvi.man.poznan.pl/ You may want to take a look, although I fear it too has been abandoned. Best Regards, Athanasios > > > > > Date: Tue, 20 Jul 2010 08:59:13 -0400 > > Subject: Multicast Network Monitoring > > From: rjsager at gmail.com > > To: nanog at nanog.org > > > > Curious if anyone has any experience with tools specifically for > monitoring > > multicast. Finds where the trees are, paths they are on, tracks all > > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > > Manager, CA Spectrum? The good and the bad? Worth the > effort/investment? > > > > Thanks > > From brandon.kim at brandontek.com Tue Jul 20 09:57:55 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 10:57:55 -0400 Subject: Multicast Network Monitoring In-Reply-To: References: , , Message-ID: Wow that looks great! The URL has an extra "dot" before the SHTML though when you click on it. Easy fix though. Are there no commercial applications for this kind of monitoring? I see your graphs are powered by MRTG. =) Date: Tue, 20 Jul 2010 17:39:17 +0300 Subject: Re: Multicast Network Monitoring From: aduitsis at gmail.com To: brandon.kim at brandontek.com CC: nanog at nanog.org On Tue, Jul 20, 2010 at 4:11 PM, Brandon Kim wrote: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... Shameless plug, I once developed a tool which was called multicast weathermap. You can see what remains of it here: http://netmon.grnet.gr/multicast-map.shtml (hover over the nodes and the links and you can see various useful info)(you can see the tree of a specific group by selecting from the drop down list at the bottom) and the presentation here http://tnc2004.terena.org/programme/presentations/show2c2c.html?pres_id=47 Since I too myself am into multicast, I intended to incorporate into it everything needed to know everything. But eventually it was left as it is. Apart from that, the NNM advanced used to have a multicast plugin, and it was fairly usable. You could take a look at it probably, but I don't know whether it can handle those MPLS cases you mention. Lastly, those guys at Poznan used to work on a tool called Muvi http://muvi.man.poznan.pl/You may want to take a look, although I fear it too has been abandoned. Best Regards,Athanasios > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From Valdis.Kletnieks at vt.edu Tue Jul 20 10:15:42 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 20 Jul 2010 11:15:42 -0400 Subject: While we worry about Vyatta and Bras..... In-Reply-To: Your message of "Mon, 19 Jul 2010 18:36:57 EDT." <5D95BAEC-24F2-4CEB-9BF1-B43B3B78F365@americafree.tv> References: <4C44CE73.6070202@cox.net> <4C44D0C6.8020304@cox.net> <5D95BAEC-24F2-4CEB-9BF1-B43B3B78F365@americafree.tv> Message-ID: <5540.1279638942@localhost> On Mon, 19 Jul 2010 18:36:57 EDT, Marshall Eubanks said: > None of this is going to help configure any routers. Most people call a network of routers run in isolation, without any care or consideration of the outside world and its potential impact on operations, a "test lab". The occasional injection of external reality is useful. And I dunno - some of us may indeed configure our routers differently after being reminded that we could get a letter from the FBI similar to the one that Burstnet got. When was the last time you checked your routers to ensure that they implemented the action your corporate policy dictates for receipt of such a letter? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From danny at tcb.net Tue Jul 20 10:34:40 2010 From: danny at tcb.net (Danny McPherson) Date: Tue, 20 Jul 2010 09:34:40 -0600 Subject: Standard for BGP community lists In-Reply-To: <20100720072653.GA25749@mx.ytti.net> References: <4C44D731.5010709@ipv6canada.com> <0407CEDC-13D4-45E7-AB22-66E963FE76AD@gmail.com> <20100720072653.GA25749@mx.ytti.net> Message-ID: On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote: > On (2010-07-19 23:45 -0500), Brad Fleming wrote: > > Hey, > >> 9999:9999 for local rtbh >> 9999:8888 for local + remote rtbh >> >> I didn't have much reason for selecting 9999 other than it was easy >> to identify visually. And obviously, I have safe-guards to not leak >> those communities into other networks. > > I would recommend against using other public ASNs for internal signalling, > ASN part should be considered property of given ASN. AS9999 might want to > use 9999 to signal particular source where route was learned and your > customer might want to do TE with it. Now you must delete them on ingress > and rob your customers of this possibility. IMO, any reasonable routing policy would reset all BGP communities on ingress (and MEDs for that matter), whether from a customer or peer, as transiting stuff that has varying semantic interpretations, unknown propagation scope, or relying on others to act on non-mandatory not-well-known communities that may not even be propagated in some BGP configurations as a matter of default behavior, is a simple recipe for nondeterministic behavior, more senseless path attribute tuples in the global routing system, resulting in less efficient BGP update packing, and may even result in security issues. And customer ingress policy can always be crafted to accommodate the upstream special handling policies for RFC1998+ functions, as well as source and destination-based RTBH and other capabilities, across one or more ISPs, even if they vary. There have been some spirited discussions on the specification of more well-known communities for functions related to this and other applications in various IETF working groups, from IDR and GROW to OPSEC and L3VPN, for those interested in having a gander... -danny From jtk at cymru.com Tue Jul 20 10:39:47 2010 From: jtk at cymru.com (John Kristoff) Date: Tue, 20 Jul 2010 10:39:47 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: <20100720103947.1175f624@t61p> On Tue, 20 Jul 2010 08:59:13 -0400 Robert Sager wrote: > Curious if anyone has any experience with tools specifically for > monitoring multicast. Finds where the trees are, paths they are on, > tracks all senders/receivers per group, handles PIM-SM, RPs, MSDP, > MDT Tunnels over MPLS VPN, etc. Such as Cisco Multicast Manager, EMC > Ionix Multicast Manager, CA Spectrum? The good and the bad? Worth > the effort/investment? I've never seen or used those vendor-specific tools so I can't comment on them. IP multicast can be extremely complex. I'd be interested in hearing if they are any good and what is good about them if so. There have been a handful of community built tools over the years, but nothing as I recall is very comprehensive. What is available now tends to be a defunct research project or simply no longer supported. CAIDA has a small list of some older tools here: Marshall Eubanks had one of the best global views of IP multicast, but it too does not appear to be supported any longer: I had a very cheesey SNMP-based cli tool that grabbed some numbers of useful IP multicast-related OIDs that probably still works: There were a couple of multicast beacon projects, which was a useful way to see how others view your IP multicast connectivity and vice versa. Doesn't look like those are running any longer I'm afraid. I've thought about reincarnating some things I've done or building on some prior work, but there seems to be so little call for IP multicast tools that I haven't been able to justify the time investment. I'd be interested in hearing if there are lots of folks now clamoring for something. John From dmm at 1-4-5.net Tue Jul 20 10:46:19 2010 From: dmm at 1-4-5.net (David Meyer) Date: Tue, 20 Jul 2010 11:46:19 -0400 Subject: [NANOG-announce] Please get your talks in for NANOG 50 Message-ID: Folks, NANOG 50 is looming. If you have content you'd like to present, please go to pc.nanog.org, create a username (if you don't have one), and upload your materials. Thanks, Dave (for the NANOG PC) -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From lowen at pari.edu Tue Jul 20 14:02:44 2010 From: lowen at pari.edu (Lamar Owen) Date: Tue, 20 Jul 2010 15:02:44 -0400 Subject: Vyatta as a BRAS In-Reply-To: References: <20100713103134.AF88708A@resin07.mta.everyone.net> Message-ID: <201007201502.44453.lowen@pari.edu> On Monday, July 19, 2010 05:40:07 pm Akyol, Bora A wrote: > Except that the goal you set below is very very hard to do on a software router unless its CPU has packet classification properties implemented in HW. And then there are Systems on a Chip (SoC) like the Realtek 8650 that really take it to another level. See http://www.csie.nctu.edu.tw/~cfliu/work/8650.htm for more information; by most definitions here this would be a SoC 'hardware' router. It's in many very low cost SoHo devices, such as NetGear FVS114. From brandon.kim at brandontek.com Tue Jul 20 08:11:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 08:11:51 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From brandon.kim at brandontek.com Tue Jul 20 08:11:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 08:11:51 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From brandon.kim at brandontek.com Tue Jul 20 08:11:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 08:11:51 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From brandon.kim at brandontek.com Tue Jul 20 08:11:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 08:11:51 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From brandon.kim at brandontek.com Tue Jul 20 08:11:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 08:11:51 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From brandon.kim at brandontek.com Tue Jul 20 08:11:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 08:11:51 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From brandon.kim at brandontek.com Tue Jul 20 08:11:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 08:11:51 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From brandon.kim at brandontek.com Tue Jul 20 08:11:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Tue, 20 Jul 2010 08:11:51 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based devices, never really thought about multi-casts and being able to see the pattern/tree.... > Date: Tue, 20 Jul 2010 08:59:13 -0400 > Subject: Multicast Network Monitoring > From: rjsager at gmail.com > To: nanog at nanog.org > > Curious if anyone has any experience with tools specifically for monitoring > multicast. Finds where the trees are, paths they are on, tracks all > senders/receivers per group, handles PIM-SM, RPs, MSDP, MDT Tunnels over > MPLS VPN, etc. Such as Cisco Multicast Manager, EMC Ionix Multicast > Manager, CA Spectrum? The good and the bad? Worth the effort/investment? > > Thanks From sethm at rollernet.us Tue Jul 20 21:22:14 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 20 Jul 2010 19:22:14 -0700 Subject: Multicast Network Monitoring In-Reply-To: References: Message-ID: <4C4659D6.70608@rollernet.us> On 7/20/2010 06:11, Brandon Kim wrote: > > Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based > devices, never really thought about multi-casts and being able to see the pattern/tree.... > > Is it just me, or is anyone else receiving multiple copies of this same message? ~Seth From jay at miscreant.org Tue Jul 20 21:29:01 2010 From: jay at miscreant.org (Jay Mitchell) Date: Wed, 21 Jul 2010 12:29:01 +1000 Subject: Multicast Network Monitoring In-Reply-To: <4C4659D6.70608@rollernet.us> References: <4C4659D6.70608@rollernet.us> Message-ID: <005401cb287c$7c261f40$74725dc0$@miscreant.org> 9 Copies here. The headers seem to show a bit of bouncing around inside cisco.com > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Wednesday, 21 July 2010 12:22 PM > To: nanog at nanog.org > Subject: Re: Multicast Network Monitoring > > On 7/20/2010 06:11, Brandon Kim wrote: > > > > Interesting question, I'd like to know more about this myself. I'm so > > used to monitoring SNMP-based devices, never really thought about multi- > casts and being able to see the pattern/tree.... > > > > > > > Is it just me, or is anyone else receiving multiple copies of this same message? > > ~Seth From tme at americafree.tv Tue Jul 20 21:38:47 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 20 Jul 2010 22:38:47 -0400 Subject: Multicast Network Monitoring In-Reply-To: <005401cb287c$7c261f40$74725dc0$@miscreant.org> References: <4C4659D6.70608@rollernet.us> <005401cb287c$7c261f40$74725dc0$@miscreant.org> Message-ID: <4AACCB07-D3CB-4E72-BFC9-03098CCB7073@americafree.tv> On Jul 20, 2010, at 10:29 PM, Jay Mitchell wrote: > 9 Copies here. > > The headers seem to show a bit of bouncing around inside cisco.com > Maybe they are having issues with their multicast mail routing protocol. Regards Marshall >> -----Original Message----- >> From: Seth Mattinen [mailto:sethm at rollernet.us] >> Sent: Wednesday, 21 July 2010 12:22 PM >> To: nanog at nanog.org >> Subject: Re: Multicast Network Monitoring >> >> On 7/20/2010 06:11, Brandon Kim wrote: >>> >>> Interesting question, I'd like to know more about this myself. I'm >>> so >>> used to monitoring SNMP-based devices, never really thought about >>> multi- >> casts and being able to see the pattern/tree.... >>> >>> >> >> >> Is it just me, or is anyone else receiving multiple copies of this >> same > message? >> >> ~Seth > > > > From tony at lava.net Tue Jul 20 21:44:13 2010 From: tony at lava.net (Antonio Querubin) Date: Tue, 20 Jul 2010 16:44:13 -1000 (HST) Subject: Multicast Network Monitoring In-Reply-To: <4AACCB07-D3CB-4E72-BFC9-03098CCB7073@americafree.tv> References: <4C4659D6.70608@rollernet.us> <005401cb287c$7c261f40$74725dc0$@miscreant.org> <4AACCB07-D3CB-4E72-BFC9-03098CCB7073@americafree.tv> Message-ID: On Tue, 20 Jul 2010, Marshall Eubanks wrote: > Maybe they are having issues with their multicast mail routing protocol. Looks like their mmrpf (multicast mail reply path forwarding) is broken ;) Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From mysidia at gmail.com Tue Jul 20 22:03:39 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 20 Jul 2010 22:03:39 -0500 Subject: Multicast Network Monitoring In-Reply-To: References: <4C4659D6.70608@rollernet.us> <005401cb287c$7c261f40$74725dc0$@miscreant.org> <4AACCB07-D3CB-4E72-BFC9-03098CCB7073@americafree.tv> Message-ID: On Tue, Jul 20, 2010 at 9:44 PM, Antonio Querubin wrote: > On Tue, 20 Jul 2010, Marshall Eubanks wrote: >> Maybe they are having issues with their multicast mail routing protocol. > Looks like their mmrpf (multicast mail reply path forwarding) is broken ;) > Or.. perhaps someone over there just turned on smrp routing ? You know.. SMRP ( Sadistic Mail Replication Protocol ) -- -JH From nanog-post at rsuc.gweep.net Tue Jul 20 22:05:22 2010 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Tue, 20 Jul 2010 23:05:22 -0400 Subject: Standard for BGP community lists In-Reply-To: References: <4C44D731.5010709@ipv6canada.com> <0407CEDC-13D4-45E7-AB22-66E963FE76AD@gmail.com> <20100720072653.GA25749@mx.ytti.net> Message-ID: <20100721030521.GA19709@gweep.net> On Tue, Jul 20, 2010 at 09:34:40AM -0600, Danny McPherson wrote: > > On Jul 20, 2010, at 1:26 AM, Saku Ytti wrote: > > > On (2010-07-19 23:45 -0500), Brad Fleming wrote: > > > > Hey, > > > >> 9999:9999 for local rtbh > >> 9999:8888 for local + remote rtbh > >> > >> I didn't have much reason for selecting 9999 other than it was easy > >> to identify visually. And obviously, I have safe-guards to not leak > >> those communities into other networks. > > > > I would recommend against using other public ASNs for internal signalling, > > ASN part should be considered property of given ASN. AS9999 might want to > > use 9999 to signal particular source where route was learned and your > > customer might want to do TE with it. Now you must delete them on ingress > > and rob your customers of this possibility. > > IMO, any reasonable routing policy would reset all BGP communities on > ingress (and MEDs for that matter), whether from a customer or peer, > as transiting stuff that has varying semantic interpretations, unknown > propagation scope, or relying on others to act on non-mandatory > not-well-known communities that may not even be propagated in some > BGP configurations as a matter of default behavior, is a simple recipe > for nondeterministic behavior, more senseless path attribute tuples in > the global routing system, resulting in less efficient BGP update packing, > and may even result in security issues. We're still seeing buffer overflows, so people obviously fail to generalize about sanitizing input. One would think the need is more obvious for signalling protocols, but expecting people to DTRT often results in disappointment. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From a.slastenov at gmail.com Wed Jul 21 04:22:18 2010 From: a.slastenov at gmail.com (Andrey Slastenov) Date: Wed, 21 Jul 2010 13:22:18 +0400 Subject: Multicast Network Monitoring In-Reply-To: References: <4C4659D6.70608@rollernet.us> <005401cb287c$7c261f40$74725dc0$@miscreant.org> <4AACCB07-D3CB-4E72-BFC9-03098CCB7073@americafree.tv> Message-ID: CMM - Cisco Multicast Manager www.cisco.com/go/cmm 2010/7/21 James Hess > On Tue, Jul 20, 2010 at 9:44 PM, Antonio Querubin wrote: > > On Tue, 20 Jul 2010, Marshall Eubanks wrote: > >> Maybe they are having issues with their multicast mail routing protocol. > > Looks like their mmrpf (multicast mail reply path forwarding) is broken > ;) > > > > Or.. perhaps someone over there just turned on smrp routing ? > > You know.. SMRP ( Sadistic Mail Replication Protocol ) > > > -- > -JH > > From matthias.flittner at de-cix.net Wed Jul 21 04:58:52 2010 From: matthias.flittner at de-cix.net (Matthias Flittner) Date: Wed, 21 Jul 2010 11:58:52 +0200 Subject: POC amazon dot de or dot com Message-ID: <4C46C4DC.3040807@de-cix.net> Hi folks, Can someone from amazon dot de or dot com onlineshop contact me off-list regarding some abuse or rather anomolies with my account? Thanks a lot. I would be appreciate if someone could assist me. best regards, -FliTTi -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From brandon.kim at brandontek.com Wed Jul 21 06:04:46 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 21 Jul 2010 07:04:46 -0400 Subject: Multicast Network Monitoring In-Reply-To: <4C4659D6.70608@rollernet.us> References: , , <4C4659D6.70608@rollernet.us> Message-ID: I was wondering what was going on. Kinda tired of seeing my own emails over and over!!!! > Date: Tue, 20 Jul 2010 19:22:14 -0700 > From: sethm at rollernet.us > To: nanog at nanog.org > Subject: Re: Multicast Network Monitoring > > On 7/20/2010 06:11, Brandon Kim wrote: > > > > Interesting question, I'd like to know more about this myself. I'm so used to monitoring SNMP-based > > devices, never really thought about multi-casts and being able to see the pattern/tree.... > > > > > > > Is it just me, or is anyone else receiving multiple copies of this same > message? > > ~Seth > From jlewis at packetnexus.com Wed Jul 21 07:44:44 2010 From: jlewis at packetnexus.com (Jason Lewis) Date: Wed, 21 Jul 2010 08:44:44 -0400 Subject: PCH.net down? Message-ID: This says it's not just down for me. http://downforeveryoneorjustme.com/pch.net Anyone else? From pstewart at nexicomgroup.net Wed Jul 21 07:46:59 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 21 Jul 2010 08:46:59 -0400 Subject: PCH.net down? In-Reply-To: References: Message-ID: Loads from here (outside of Toronto, ON) - peered with them. Seemed slow to load though.. Paul -----Original Message----- From: Jason Lewis [mailto:jlewis at packetnexus.com] Sent: Wednesday, July 21, 2010 8:45 AM To: nanog at nanog.org Subject: PCH.net down? This says it's not just down for me. http://downforeveryoneorjustme.com/pch.net Anyone else? From nicks at sunbelt-software.com Wed Jul 21 07:54:56 2010 From: nicks at sunbelt-software.com (Nick Suan) Date: Wed, 21 Jul 2010 08:54:56 -0400 Subject: PCH.net down? In-Reply-To: References: Message-ID: <25D91FEA-8A50-4F0B-BE35-6FE64E33840F@sunbelt-software.com> From everywhere I've tried, it connects but loads slowly. On Jul 21, 2010, at 8:44 AM, Jason Lewis wrote: > This says it's not just down for me. http://downforeveryoneorjustme.com/pch.net > > Anyone else? > From bbillon-ml at splio.fr Wed Jul 21 07:55:08 2010 From: bbillon-ml at splio.fr (Benjamin Billon) Date: Wed, 21 Jul 2010 14:55:08 +0200 Subject: PCH.net down? In-Reply-To: References: Message-ID: <4C46EE2C.8080706@splio.fr> Also ok from France. Lg also working fine (https://prefix.pch.net/applications/lg/), do you need to look through a specific glass? > Loads from here (outside of Toronto, ON) - peered with them. > > Seemed slow to load though.. From l at p8x.net Wed Jul 21 08:05:53 2010 From: l at p8x.net (p8x) Date: Wed, 21 Jul 2010 21:05:53 +0800 Subject: PCH.net down? In-Reply-To: References: Message-ID: <4C46F0B1.8030003@p8x.net> It seems to be fine for me as well, in Australia. Loading time was a bit slow, but I do have a few downloads running. On 21/07/2010 8:44 PM, Jason Lewis wrote: > This says it's not just down for me. http://downforeveryoneorjustme.com/pch.net > > Anyone else? > From allen_bass at comcast.net Wed Jul 21 10:13:27 2010 From: allen_bass at comcast.net (Allen Bass) Date: Wed, 21 Jul 2010 11:13:27 -0400 Subject: PCH.net down? In-Reply-To: References: Message-ID: <048401cb28e7$45bdbc90$d13935b0$@net> I received the same message from http://downforeveryoneorjustme.com/pch.net but if I go to the site directly from Miami it pulls up, but is slow to do so. -----Original Message----- From: Paul Stewart [mailto:pstewart at nexicomgroup.net] Sent: Wednesday, July 21, 2010 8:47 AM To: Jason Lewis; nanog at nanog.org Subject: RE: PCH.net down? Loads from here (outside of Toronto, ON) - peered with them. Seemed slow to load though.. Paul -----Original Message----- From: Jason Lewis [mailto:jlewis at packetnexus.com] Sent: Wednesday, July 21, 2010 8:45 AM To: nanog at nanog.org Subject: PCH.net down? This says it's not just down for me. http://downforeveryoneorjustme.com/pch.net Anyone else? From fred at cisco.com Wed Jul 21 08:18:29 2010 From: fred at cisco.com (Fred Baker) Date: Wed, 21 Jul 2010 09:18:29 -0400 Subject: Looking for comments Message-ID: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> Hi IETF IPv6 Operations WG is looking at this draft, and we're interested in any comments you might have as well. http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines "Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred Baker, 12-Jul-10 From morrowc.lists at gmail.com Wed Jul 21 10:48:42 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 21 Jul 2010 11:48:42 -0400 Subject: PCH.net down? In-Reply-To: <048401cb28e7$45bdbc90$d13935b0$@net> References: <048401cb28e7$45bdbc90$d13935b0$@net> Message-ID: On Wed, Jul 21, 2010 at 11:13 AM, Allen Bass wrote: > I received the same message from http://downforeveryoneorjustme.com/pch.net > but if I go to the site directly from Miami it pulls up, but is slow to do everyone should take careful note... downforeveryoneorjustme.com lives ... on appengine at google, so 'downforeveryoneorjustme' really just tests if google's network has a path to it. From pstewart at nexicomgroup.net Wed Jul 21 10:49:18 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Wed, 21 Jul 2010 11:49:18 -0400 Subject: PCH.net down? In-Reply-To: References: <048401cb28e7$45bdbc90$d13935b0$@net> Message-ID: Very interesting - thanks for sharing that tip.... Paul -----Original Message----- From: christopher.morrow at gmail.com [mailto:christopher.morrow at gmail.com] On Behalf Of Christopher Morrow Sent: Wednesday, July 21, 2010 11:49 AM To: Allen Bass Cc: Paul Stewart; Jason Lewis; nanog at nanog.org Subject: Re: PCH.net down? On Wed, Jul 21, 2010 at 11:13 AM, Allen Bass wrote: > I received the same message from http://downforeveryoneorjustme.com/pch.net > but if I go to the site directly from Miami it pulls up, but is slow to do everyone should take careful note... downforeveryoneorjustme.com lives ... on appengine at google, so 'downforeveryoneorjustme' really just tests if google's network has a path to it. From avitkovsky at emea.att.com Wed Jul 21 11:13:59 2010 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Wed, 21 Jul 2010 18:13:59 +0200 Subject: "vpn exchange point" Message-ID: Hello, Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns Let's say I'm an ISP that bought or merged with many small ISPs each with it's own AS# and would like to start offering mpls vpn services end to end If there would be just a few autonomous systems involved I could do option-C and run a full mesh between the Inter-AS-RRs Let's also assume there are more Inter-AS-RRs per AS -but still with small number of ASes the full mesh is doable However if there's like dozen or more ASes -peering with all the Inter-AS-RRs would be cumbersome -that's where the vpn exchange point would be appropriate I believe the exchange-point could work something like option-c ---- Inter-AS-RR-AS1---- Inter-AS-RR-AS2---- Inter-AS-RR-AS3---- -where the AS2 would be represented by a single node -the exchange point Let's also assume the ASes have separate mpls links enabled between them Than this exchange point is just about the control plane (no transit traffic -just inter-as-vpn-routes distribution) It's like adding another layer of RRs to the picture Let's say there are Intra-AS-RRs -that reflect routes between PE routers within a single AS Let's say there are Inter-AS-RRs -that reflect routes between multiple ASes (but if there are may ASes and we can't cope with the full mesh anymore) We can ad Global-RRs --that will reflect routes between Inter-AS-RRs -these Global-RRs could be thought of as the exchange points adam From woody at pch.net Wed Jul 21 11:44:19 2010 From: woody at pch.net (Bill Woodcock) Date: Wed, 21 Jul 2010 09:44:19 -0700 Subject: "vpn exchange point" In-Reply-To: References: Message-ID: <47A1DD08-7CC0-4DF2-A557-77C956159C6B@pch.net> On Jul 21, 2010, at 9:13 AM, Vitkovsky, Adam wrote: > Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns That would be like an IXP but for email. Or an IXP but for web traffic. VPNs are an application that run over IP, and IXPs are interconnection locations for IP traffic. So you don't need to worry about what you're worrying about. Nor, for instance, do the VoIP people. Ahem. -Bill From alexb at ripe.net Wed Jul 21 11:57:01 2010 From: alexb at ripe.net (Alex Band) Date: Wed, 21 Jul 2010 18:57:01 +0200 Subject: Addressing plan exercise for our IPv6 course Message-ID: We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ I'm curious to hear if you think it's clear and useful. Cheers, Alex Band RIPE NCC Trainer (Big props go to Marco Hogewoning @XS4ALL) From woody at pch.net Wed Jul 21 11:58:24 2010 From: woody at pch.net (Bill Woodcock) Date: Wed, 21 Jul 2010 09:58:24 -0700 Subject: PCH.net down? In-Reply-To: References: Message-ID: <66475BEA-DAE8-4323-91FE-70C747BE9BED@pch.net> On Jul 21, 2010, at 5:44 AM, Jason Lewis wrote: > This says it's not just down for me. http://downforeveryoneorjustme.com/pch.net > Anyone else? We don't know of an outage this morning, but one of our web servers has been a bit slow because someone's been multi-thread downloading our routing-table archive from it for the last week or so. That hasn't caused performance issues in the past, but now we're looking at putting the http-visible side of big things that people download on a server of their own that isn't also serving http for other tools and web-site parts. -Bill From simon.perreault at viagenie.ca Wed Jul 21 12:22:47 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Wed, 21 Jul 2010 13:22:47 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: <4C472CE7.50907@viagenie.ca> On 2010-07-21 12:57, Alex Band wrote: > We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. > > Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ > > I'm curious to hear if you think it's clear and useful. Useful, yes. But it should be clearer that not all address plans are equally good. It's not just a matter of filling in the blanks with something that will work. For instance, would one be expected to follow RFC 3531? Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From hrlinneweh at sbcglobal.net Wed Jul 21 12:29:23 2010 From: hrlinneweh at sbcglobal.net (Henry Linneweh) Date: Wed, 21 Jul 2010 10:29:23 -0700 (PDT) Subject: PCH.net down? In-Reply-To: <66475BEA-DAE8-4323-91FE-70C747BE9BED@pch.net> References: <66475BEA-DAE8-4323-91FE-70C747BE9BED@pch.net> Message-ID: <635478.47770.qm@web180306.mail.gq1.yahoo.com> http://pch.net/home/index.php I got there with no problem -henry ________________________________ From: Bill Woodcock To: Jason Lewis Cc: nanog at nanog.org Sent: Wed, July 21, 2010 9:58:24 AM Subject: Re: PCH.net down? On Jul 21, 2010, at 5:44 AM, Jason Lewis wrote: > This says it's not just down for me. >http://downforeveryoneorjustme.com/pch.net > Anyone else? We don't know of an outage this morning, but one of our web servers has been a bit slow because someone's been multi-thread downloading our routing-table archive from it for the last week or so. That hasn't caused performance issues in the past, but now we're looking at putting the http-visible side of big things that people download on a server of their own that isn't also serving http for other tools and web-site parts. -Bill From brandon.kim at brandontek.com Wed Jul 21 12:34:19 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 21 Jul 2010 13:34:19 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: Alex this looks great! Just printed it out and will play with it. I've spent some time learning IPv6 but when you're not looking at it daily, you begin to forget.... > From: alexb at ripe.net > Subject: Addressing plan exercise for our IPv6 course > Date: Wed, 21 Jul 2010 18:57:01 +0200 > To: nanog at nanog.org > > We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. > > Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ > > I'm curious to hear if you think it's clear and useful. > > Cheers, > > Alex Band > RIPE NCC Trainer > > (Big props go to Marco Hogewoning @XS4ALL) From marcoh at marcoh.net Wed Jul 21 13:47:18 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 21 Jul 2010 20:47:18 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C472CE7.50907@viagenie.ca> References: <4C472CE7.50907@viagenie.ca> Message-ID: <01436732-0511-43CC-8C9E-C94510F3E094@marcoh.net> On 21 jul 2010, at 19:22, Simon Perreault wrote: > On 2010-07-21 12:57, Alex Band wrote: >> We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. >> >> Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ >> >> I'm curious to hear if you think it's clear and useful. > > Useful, yes. But it should be clearer that not all address plans are > equally good. It's not just a matter of filling in the blanks with > something that will work. Every address plan will turn out to be a custom job anyway. Primary goal of this exercise is to show the basics and to show how you can get a lot of aggregation done without wasting a lot of space. Making people familiar with the way subnets are split up and the very basics of counting to 16. I'm also working on a more extensive half day workshop which contains a lot more scenarios and for instance show how to fit this same network into a /48 PI assignment instead of the /32 PA. If you are bored with this one already, go ahead and try :) > For instance, would one be expected to follow RFC 3531? For a novice ? I wouldn't recommend it. From what I get back 'in the field' it's already hard enough to get people familliar to the whole concept of hexadecimal without going into bit level. But then again, if you are a fairly technical company maybe you can get away with it. As far as customer assignments is concerned, I would simply stick to the /48 and not make any reservation for future growth beyond that, i should probably cater for 99% of your cases and if they really run out I can probably handle a second assignment/route for another one (or leave them the choice to renumber into a /47). In fact part of this exercise is meant to teach people how to avoid such disasters as running 'out of space' by being really inefficient. The only way where I see this becoming relevant is when trying to make subassignments from a /48. But as far as PI is concerned, and that would be the most likely case, in RIPE region you are not allowed to make subassignments from within a PI block. The other one would be subassignments from a PA block, which under the same policy can easily be made a few bits bigger and if I would encounter a customer who would actually subassign large numbers of customers from within a PA assignment. I would recommend becoming an LIR themselves and get a /32. MarcoH From zaid at zaidali.com Wed Jul 21 14:08:10 2010 From: zaid at zaidali.com (Zaid Ali) Date: Wed, 21 Jul 2010 12:08:10 -0700 Subject: v6 bgp peer costs? Message-ID: I currently have a v4 BGP session with AS 701 and recently requested a v6 BGP session to which I was told a tunnel session will be provided (Same circuit would be better but whatever!). Towards the final stage in discussions I was told that it will cost $1500. I find this quite ridiculous and it will certainly not motivate people to move to v6 if providers put a direct price tag on it. I am going through a bandwidth reseller though so I am not sure who is trying to jack me here. Has anyone here gone through a similar experience? Thanks, Zaid From marcoh at marcoh.net Wed Jul 21 14:22:14 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 21 Jul 2010 21:22:14 +0200 Subject: v6 bgp peer costs? In-Reply-To: References: Message-ID: On 21 jul 2010, at 21:08, Zaid Ali wrote: > I currently have a v4 BGP session with AS 701 and recently requested a v6 > BGP session to which I was told a tunnel session will be provided (Same > circuit would be better but whatever!). Towards the final stage in > discussions I was told that it will cost $1500. I find this quite ridiculous > and it will certainly not motivate people to move to v6 if providers put a > direct price tag on it. I am going through a bandwidth reseller though so I > am not sure who is trying to jack me here. Has anyone here gone through a > similar experience? I think the main question here would be, what they would charge for a change to a v4 session. Most likely they just decided that setting up the tunnel and configuring BGP takes time and since time is money they decided to charge for you. Seems like a reasonabe rule of business, why should it be free ? At the same time, the same set of economics will probably find you somebody who will do this for less and maybe even is happy to take your business and setup v4/v6 dual stack for free. So get a quote from a competitor, call back 701 and offer them the choice of setting up the tunnel or loose a customer. My personal preference would be to leave and find somebody who can do native all the way. MarcoH From Nathan_Sipes at kindermorgan.com Wed Jul 21 14:30:33 2010 From: Nathan_Sipes at kindermorgan.com (Sipes, Nathan) Date: Wed, 21 Jul 2010 13:30:33 -0600 Subject: v6 bgp peer costs? In-Reply-To: References: Message-ID: I recently began the process of turning up BGP to AS 701 with both V4 and V6 peers and there were no additional costs. Nathan Sipes Sr. Network Design Specialist Tel: 303-914-4996 FAX: 303-763-3510? Kinder Morgan 370 Van Gordon St Lakewood, CO 80228 Nathan_Sipes at kindermorgan.com -----Original Message----- From: Zaid Ali [mailto:zaid at zaidali.com] Sent: Wednesday, July 21, 2010 1:08 PM To: NANOG list Subject: v6 bgp peer costs? I currently have a v4 BGP session with AS 701 and recently requested a v6 BGP session to which I was told a tunnel session will be provided (Same circuit would be better but whatever!). Towards the final stage in discussions I was told that it will cost $1500. I find this quite ridiculous and it will certainly not motivate people to move to v6 if providers put a direct price tag on it. I am going through a bandwidth reseller though so I am not sure who is trying to jack me here. Has anyone here gone through a similar experience? Thanks, Zaid From brandon.kim at brandontek.com Wed Jul 21 14:34:06 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Wed, 21 Jul 2010 15:34:06 -0400 Subject: v6 bgp peer costs? In-Reply-To: References: , Message-ID: Is dual-stacking with an edge device considered native? Or is "true" native when you have an edge device or any network device for that matter that's v6 only? Just curious.... > Subject: Re: v6 bgp peer costs? > From: marcoh at marcoh.net > Date: Wed, 21 Jul 2010 21:22:14 +0200 > To: zaid at zaidali.com > CC: nanog at nanog.org > > > On 21 jul 2010, at 21:08, Zaid Ali wrote: > > > I currently have a v4 BGP session with AS 701 and recently requested a v6 > > BGP session to which I was told a tunnel session will be provided (Same > > circuit would be better but whatever!). Towards the final stage in > > discussions I was told that it will cost $1500. I find this quite ridiculous > > and it will certainly not motivate people to move to v6 if providers put a > > direct price tag on it. I am going through a bandwidth reseller though so I > > am not sure who is trying to jack me here. Has anyone here gone through a > > similar experience? > > I think the main question here would be, what they would charge for a change to a v4 session. Most likely they just decided that setting up the tunnel and configuring BGP takes time and since time is money they decided to charge for you. Seems like a reasonabe rule of business, why should it be free ? At the same time, the same set of economics will probably find you somebody who will do this for less and maybe even is happy to take your business and setup v4/v6 dual stack for free. > > So get a quote from a competitor, call back 701 and offer them the choice of setting up the tunnel or loose a customer. My personal preference would be to leave and find somebody who can do native all the way. > > MarcoH > > From sethm at rollernet.us Wed Jul 21 14:36:17 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 21 Jul 2010 12:36:17 -0700 Subject: v6 bgp peer costs? In-Reply-To: References: , Message-ID: <4C474C31.8020201@rollernet.us> On 7/21/2010 12:34, Brandon Kim wrote: > > Is dual-stacking with an edge device considered native? Or is "true" native when you have > an edge device or any network device for that matter that's v6 only? > > Just curious.... > Dual stack is considered native, i.e. "no tunnels". ~Seth From mleber at he.net Wed Jul 21 14:38:28 2010 From: mleber at he.net (Mike Leber) Date: Wed, 21 Jul 2010 12:38:28 -0700 Subject: v6 bgp peer costs? In-Reply-To: References: Message-ID: <4C474CB4.9050309@he.net> You can get a free IPv6 BGP tunnel from Hurricane Electric at http://tunnelbroker.net We have tunnel servers spread through out the world, so typically the nearest server has reasonably low latency from your location. Of course our main business is selling wholesale native IPv6 and IPv4 transit, however you don't have to be a paying customer to use our free service. Mike. On 7/21/10 12:08 PM, Zaid Ali wrote: > I currently have a v4 BGP session with AS 701 and recently requested a v6 > BGP session to which I was told a tunnel session will be provided (Same > circuit would be better but whatever!). Towards the final stage in > discussions I was told that it will cost $1500. I find this quite ridiculous > and it will certainly not motivate people to move to v6 if providers put a > direct price tag on it. I am going through a bandwidth reseller though so I > am not sure who is trying to jack me here. Has anyone here gone through a > similar experience? > > Thanks, > Zaid > > > From sethm at rollernet.us Wed Jul 21 14:39:49 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 21 Jul 2010 12:39:49 -0700 Subject: v6 bgp peer costs? In-Reply-To: References: Message-ID: <4C474D05.3070108@rollernet.us> On 7/21/2010 12:08, Zaid Ali wrote: > I currently have a v4 BGP session with AS 701 and recently requested a v6 > BGP session to which I was told a tunnel session will be provided (Same > circuit would be better but whatever!). Towards the final stage in > discussions I was told that it will cost $1500. I find this quite ridiculous > and it will certainly not motivate people to move to v6 if providers put a > direct price tag on it. I am going through a bandwidth reseller though so I > am not sure who is trying to jack me here. Has anyone here gone through a > similar experience? > Ooh, Verizon? Good luck. Do you know what pop (VZ calles them "hubs") your existing circuit is out of? Not all of 701 is IPv6 enabled. If you are currently served from a v4 only location you're out of luck. I ordered an Ethernet circuit from Verizon last year as dual-stack IPv4/IPv6. There was no extra cost involved. However, they never did actually deliver the layer 3 portion, so I just let them languish into obscurity. My problem was that I'm closer to a v4 only pop (Sacramento), but the closest 4/6 pop is further away in San Jose. For some reason they could not figure out how to go there and kept defaulting to Sac. Eventually they called me and said it's just not possible to deliver the service. I ended up placing an order with Global Crossing and the dual-stack process was completely painless. I also have an IPv6 BGP tunnel to Sprint which is included with my v4 service for free. It works fine, but it's still a tunnel and has much higher latency than the DS3 it's running over. Hopefully native in August. ~Seth From susanh at arin.net Wed Jul 21 14:47:16 2010 From: susanh at arin.net (Susan Hamlin) Date: Wed, 21 Jul 2010 15:47:16 -0400 Subject: ARIN Meetings Fellowship to Attend ARIN XXVI - Apply by 6 August Message-ID: ARIN is pleased to offer a Meetings Fellowship Program to bring new voices and ideas to public policy discussions. This call is for Fellows to attend ARIN XXVI in Atlanta, GA from 6-8 October 2010. If you have never attended an ARIN meeting and are interested in participating in the program, submit your application by 6 August. The application link, submission instructions, and a detailed description of the program can be found at: https://www.arin.net/participate/meetings/fellowship.html One individual from each of the three sectors within ARIN's service region (Canada, the Caribbean and North Atlantic Islands, and the United States and Outlying Areas) will be selected. Fellows receive financial support to attend the Public Policy and Members Meeting, and ARIN Advisory Council representatives will serve as mentors to the Fellows to help maximize their meeting experience. Individuals selected for the fellowship receive: * Free meeting registration * Round-trip economy class airfare to the meeting, booked directly by ARIN * Hotel accommodations at the venue hotel, booked directly by ARIN * A stipend to cover meals and incidental travel expenses Please contact info at arin.net if you have any questions concerning the program and the application process. Be sure to share this opportunity with anyone you feel might be interested. Regards, Susan Hamlin Director, Communications and Member Services American Registry for Internet Numbers (ARIN) 1.703.227.9851 O 1.703.930.6094 C From ipv6nog at gmail.com Wed Jul 21 14:55:13 2010 From: ipv6nog at gmail.com (Jim Fleming) Date: Wed, 21 Jul 2010 14:55:13 -0500 Subject: NANOG50 BOF Atlanta.311 IEEE 802.1Q VLAN Message-ID: NANOG50 BOF Atlanta.311 IEEE 802.1Q VLAN http://en.wikipedia.org/wiki/IEEE_802.1Q Triple-Tagging with 66-bit Addressing (48+18) IP Addresses in MAC fields NANOG operational testing needed with sample EDU reference routers http://NetFPGA.org BYOR - Bring/Buid Your Own Router - gigE to SATA NANOG50 BOF Atlanta.311 IEEE 802.1Q VLAN From zaid at zaidali.com Wed Jul 21 14:55:19 2010 From: zaid at zaidali.com (Zaid Ali) Date: Wed, 21 Jul 2010 12:55:19 -0700 Subject: v6 bgp peer costs? In-Reply-To: Message-ID: On 7/21/10 12:22 PM, "Marco Hogewoning" wrote: > > On 21 jul 2010, at 21:08, Zaid Ali wrote: > >> I currently have a v4 BGP session with AS 701 and recently requested a v6 >> BGP session to which I was told a tunnel session will be provided (Same >> circuit would be better but whatever!). Towards the final stage in >> discussions I was told that it will cost $1500. I find this quite ridiculous >> and it will certainly not motivate people to move to v6 if providers put a >> direct price tag on it. I am going through a bandwidth reseller though so I >> am not sure who is trying to jack me here. Has anyone here gone through a >> similar experience? > > I think the main question here would be, what they would charge for a change > to a v4 session. Most likely they just decided that setting up the tunnel and > configuring BGP takes time and since time is money they decided to charge for > you. Seems like a reasonabe rule of business, why should it be free ? At the > same time, the same set of economics will probably find you somebody who will > do this for less and maybe even is happy to take your business and setup v4/v6 > dual stack for free. > > So get a quote from a competitor, call back 701 and offer them the choice of > setting up the tunnel or loose a customer. My personal preference would be to > leave and find somebody who can do native all the way. > > MarcoH > Thanks, I am trying to see if there is a trend or anomalous gouging. From off-list answers it doesn't seem like a trend among other vendors. My worry about high costs is when you have several circuits this will add up and going to a CFO to justify will be pretty hard. A CFO will generally say lets deal with that problem next year when v4 actually runs out. Two years ago I felt there wasn't enough motivation for folks to move to v6, I don't see this changing especially when vendors, resellers etc charge more $$ for v6. Zaid From simon.perreault at viagenie.ca Wed Jul 21 14:50:40 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Wed, 21 Jul 2010 15:50:40 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <01436732-0511-43CC-8C9E-C94510F3E094@marcoh.net> References: <4C472CE7.50907@viagenie.ca> <01436732-0511-43CC-8C9E-C94510F3E094@marcoh.net> Message-ID: <4C474F90.9070704@viagenie.ca> On 2010-07-21 14:47, Marco Hogewoning wrote: > For a novice ? I wouldn't recommend it. From what I get back 'in the field' it's already hard enough to get people familliar to the whole concept of hexadecimal without going into bit level. But then again, if you are a fairly technical company maybe you can get away with it. Not disagreeing, but here's a tool to make it easier: http://www.ipv6book.ca/allocation.html Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From zaid at zaidali.com Wed Jul 21 14:57:52 2010 From: zaid at zaidali.com (Zaid Ali) Date: Wed, 21 Jul 2010 12:57:52 -0700 Subject: v6 bgp peer costs? In-Reply-To: <4C474CB4.9050309@he.net> Message-ID: I already have a v6 BGP tunnel with Hurricane Electric and works like a charm :) It is other vendors I am concerned about. Zaid On 7/21/10 12:38 PM, "Mike Leber" wrote: > > You can get a free IPv6 BGP tunnel from Hurricane Electric at > http://tunnelbroker.net > > We have tunnel servers spread through out the world, so typically the > nearest server has reasonably low latency from your location. > > Of course our main business is selling wholesale native IPv6 and IPv4 > transit, however you don't have to be a paying customer to use our free > service. > > Mike. > > On 7/21/10 12:08 PM, Zaid Ali wrote: >> I currently have a v4 BGP session with AS 701 and recently requested a v6 >> BGP session to which I was told a tunnel session will be provided (Same >> circuit would be better but whatever!). Towards the final stage in >> discussions I was told that it will cost $1500. I find this quite ridiculous >> and it will certainly not motivate people to move to v6 if providers put a >> direct price tag on it. I am going through a bandwidth reseller though so I >> am not sure who is trying to jack me here. Has anyone here gone through a >> similar experience? >> >> Thanks, >> Zaid >> >> >> > From william.mccall at gmail.com Wed Jul 21 14:59:32 2010 From: william.mccall at gmail.com (William McCall) Date: Wed, 21 Jul 2010 14:59:32 -0500 Subject: "vpn exchange point" In-Reply-To: <47A1DD08-7CC0-4DF2-A557-77C956159C6B@pch.net> References: <47A1DD08-7CC0-4DF2-A557-77C956159C6B@pch.net> Message-ID: OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not sure that I've (personally) ever heard of an IXP for MPLS. The question really is... does it make sense for carriers to create an MPLS/BGP VPN sort of internet? I'd vote probably not in their immediate interests. --WM On Wed, Jul 21, 2010 at 11:44 AM, Bill Woodcock wrote: > > On Jul 21, 2010, at 9:13 AM, Vitkovsky, Adam wrote: >> Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns > > That would be like an IXP but for email. ?Or an IXP but for web traffic. ?VPNs are an application that run over IP, and IXPs are interconnection locations for IP traffic. ?So you don't need to worry about what you're worrying about. > > Nor, for instance, do the VoIP people. ?Ahem. > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?-Bill > > > > > > > From marcoh at marcoh.net Wed Jul 21 15:00:49 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 21 Jul 2010 22:00:49 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C474F90.9070704@viagenie.ca> References: <4C472CE7.50907@viagenie.ca> <01436732-0511-43CC-8C9E-C94510F3E094@marcoh.net> <4C474F90.9070704@viagenie.ca> Message-ID: <680DFE71-8A75-4F51-97A6-31DDE035757B@marcoh.net> On 21 jul 2010, at 21:50, Simon Perreault wrote: > On 2010-07-21 14:47, Marco Hogewoning wrote: >> For a novice ? I wouldn't recommend it. From what I get back 'in the field' it's already hard enough to get people familliar to the whole concept of hexadecimal without going into bit level. But then again, if you are a fairly technical company maybe you can get away with it. > > Not disagreeing, but here's a tool to make it easier: > > http://www.ipv6book.ca/allocation.html Nice tool but they just learn a trick instead of understanding what is going on. Anyway, left or right there is this huge lack of knowledge and a maximum of 12 months to fix it. So whatever gets it going. MarcoH From zaid at zaidali.com Wed Jul 21 15:09:44 2010 From: zaid at zaidali.com (Zaid Ali) Date: Wed, 21 Jul 2010 13:09:44 -0700 Subject: v6 bgp peer costs? In-Reply-To: <4C474D05.3070108@rollernet.us> Message-ID: On 7/21/10 12:39 PM, "Seth Mattinen" wrote: > On 7/21/2010 12:08, Zaid Ali wrote: >> I currently have a v4 BGP session with AS 701 and recently requested a v6 >> BGP session to which I was told a tunnel session will be provided (Same >> circuit would be better but whatever!). Towards the final stage in >> discussions I was told that it will cost $1500. I find this quite ridiculous >> and it will certainly not motivate people to move to v6 if providers put a >> direct price tag on it. I am going through a bandwidth reseller though so I >> am not sure who is trying to jack me here. Has anyone here gone through a >> similar experience? >> > > Ooh, Verizon? Good luck. Do you know what pop (VZ calles them "hubs") > your existing circuit is out of? Not all of 701 is IPv6 enabled. If you > are currently served from a v4 only location you're out of luck. > POS-6 SJC > I ordered an Ethernet circuit from Verizon last year as dual-stack > IPv4/IPv6. There was no extra cost involved. However, they never did > actually deliver the layer 3 portion, so I just let them languish into > obscurity. My problem was that I'm closer to a v4 only pop (Sacramento), > but the closest 4/6 pop is further away in San Jose. For some reason > they could not figure out how to go there and kept defaulting to Sac. > Eventually they called me and said it's just not possible to deliver the > service. I ended up placing an order with Global Crossing and the > dual-stack process was completely painless. Sigh.. Explains why I never got a straight answer on native v6 support. First they said yes then now Tunnel only. Perhaps time to turn them off. Zaid From alexb at ripe.net Wed Jul 21 15:11:05 2010 From: alexb at ripe.net (Alex Band) Date: Wed, 21 Jul 2010 22:11:05 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <43139732-735A-429A-9F9A-41FB2092D0B9@delong.com> References: <43139732-735A-429A-9F9A-41FB2092D0B9@delong.com> Message-ID: <48ECDB11-F208-4228-94A4-002148690CC6@ripe.net> Hi Owen, The RIPE NCC does actually ask for an addressing plan before we allocate a /32 IPv6, so I didn't phrase my opening email 100% accurate; we don't just blindly hand it out. On the other hand, we don't do rigorous checks if it is actually any good, or appropriate for their network. What we see in the real world, is that many LIRs haven't requested a v6 allocation yet because they simply wouldn't know where to begin making an addressing plan. Then there is the group that sent in an addressing plan, got their allocation, and starting trying some things implementing it. In a lot of cases, they get stuck because reality was a lot different than what they thought it would be, and put the allocation in a drawer since it's not that urgent yet. This exercise is for both those groups. Just to get them going, understanding the basics. Cheers, Alex On 21 Jul 2010, at 21:53, Owen DeLong wrote: > First, think this is very wrong teaching. I think we should be stressing the need to develop an addressing and subdivision plan FIRST, then request an appropriate amount of IPv6 space. > > I will endeavor to review and comment on the exercises later, but I wanted to convey this point first. > > Owen > > > Sent from my iPad > > On Jul 21, 2010, at 11:57 AM, Alex Band wrote: > >> We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. >> >> Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ >> >> I'm curious to hear if you think it's clear and useful. >> >> Cheers, >> >> Alex Band >> RIPE NCC Trainer >> >> (Big props go to Marco Hogewoning @XS4ALL) > From MDikkema at canwest.com Wed Jul 21 15:43:28 2010 From: MDikkema at canwest.com (Dikkema, Michael (CITG)) Date: Wed, 21 Jul 2010 15:43:28 -0500 Subject: Autmatic DNS mapping tools Message-ID: <0D2372ADEB4C944E84002E85E63C9ED00D13BD8B@WPGMSXVSA01.ca.canwest.com> Do any tools exist for automatically creating DNS zone files from CDP/SNMP information? Do large networks typically do this in an automated way? Thanks. From Kent.Frederick at ironmountain.com Wed Jul 21 15:51:20 2010 From: Kent.Frederick at ironmountain.com (Frederick, Kent) Date: Wed, 21 Jul 2010 16:51:20 -0400 Subject: "vpn exchange point" Message-ID: <022FAC80F9000940B496345544D73DA19E9BD17DD2@NUMEVP11.na.imtn.com> Kent Frederick Network Architect, Network Services Iron Mountain 745 Atlantic Ave Boston, MA 02111 Phone: (617) 535-4901 Mobile: (617) 894-7349 Fax: (208) 475-6722 kent.frederick at ironmountain.com www.ironmountain.com The information contained in this email message and its attachments is intended only for the private and confidential use of the recipient(s) named above, unless the sender expressly agrees otherwise. Transmission of email over the Internet is not a secure communications medium. If you are requesting or have requested the transmittal of personal data, as defined in applicable privacy laws by means of email or in an attachment to email, you must select a more secure alternate means of transmittal that supports your obligations to protect such personal data. If the reader of this message is not the intended recipient and/or you have received this email in error, you must take no action based on the information in this email and you are hereby notified that any dissemination, misuse or copying or disclosure of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email and delete the original message. From cvicente at network-services.uoregon.edu Wed Jul 21 16:23:42 2010 From: cvicente at network-services.uoregon.edu (Carlos Vicente) Date: Wed, 21 Jul 2010 14:23:42 -0700 Subject: Autmatic DNS mapping tools In-Reply-To: <0D2372ADEB4C944E84002E85E63C9ED00D13BD8B@WPGMSXVSA01.ca.canwest.com> References: <0D2372ADEB4C944E84002E85E63C9ED00D13BD8B@WPGMSXVSA01.ca.canwest.com> Message-ID: <4C47655E.2010108@ns.uoregon.edu> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Our Network Documentation Tool [1] can generate DNS records for each device interface with an IP address. [1] https://netdot.uoregon.edu [2] http://www.nanog.org/meetings/nanog49/presentations/Tuesday/Vicente-netdot-presentation-nanog49.pdf cv Dikkema, Michael (CITG) wrote: > Do any tools exist for automatically creating DNS zone files from > CDP/SNMP information? Do large networks typically do this in an > automated way? > > > > Thanks. > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFMR2VdDADXcoYj2ZwRAlBWAJ9Mtrd4gIuetv2Rqj0oC1r65lZI2wCfSYNH EV6upmxFEOa/TQ0lxwTc4ko= =oZdX -----END PGP SIGNATURE----- From ipv6nog at gmail.com Wed Jul 21 16:30:10 2010 From: ipv6nog at gmail.com (Jim Fleming) Date: Wed, 21 Jul 2010 16:30:10 -0500 Subject: "vpn exchange point" VLAN Exchange Points NANOG50 Atlanta.311 Message-ID: "vpn exchange point" VLAN Exchange Points NANOG50 Atlanta.311 Tagged VLANs make most sense in dense MetroLANs (MANs) What goes on in Atlanta Stays in Atlanta - NANOG50 http://en.wikipedia.org/wiki/IEEE_802.1Q What goes on in North America Stays in North America ? NA ? North America ? Note: 33-bit IPv4 addressing is half of 66-bit Tagged VLAN - LOC.ID From woody at pch.net Wed Jul 21 16:43:20 2010 From: woody at pch.net (Bill Woodcock) Date: Wed, 21 Jul 2010 14:43:20 -0700 Subject: "vpn exchange point" In-Reply-To: References: <47A1DD08-7CC0-4DF2-A557-77C956159C6B@pch.net> Message-ID: <266EAC81-B0BB-473D-B704-3658EB7C85A3@pch.net> On Jul 21, 2010, at 12:59 PM, William McCall wrote: > OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not sure > that I've (personally) ever heard of an IXP for MPLS. Isn't that what one iteration of IXP-NSP in Japan was? I seem to recall that they talked about it a lot, back when MPLS was still trendy, but I haven't heard word one about it for many years since. -Bill From tme at americafree.tv Wed Jul 21 16:59:52 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Wed, 21 Jul 2010 17:59:52 -0400 Subject: "vpn exchange point" In-Reply-To: <266EAC81-B0BB-473D-B704-3658EB7C85A3@pch.net> References: <47A1DD08-7CC0-4DF2-A557-77C956159C6B@pch.net> <266EAC81-B0BB-473D-B704-3658EB7C85A3@pch.net> Message-ID: <50A582AE-7020-4038-AE2D-8C4559A48D25@americafree.tv> On Jul 21, 2010, at 5:43 PM, Bill Woodcock wrote: > > On Jul 21, 2010, at 12:59 PM, William McCall wrote: > >> OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not >> sure >> that I've (personally) ever heard of an IXP for MPLS. > > Isn't that what one iteration of IXP-NSP in Japan was? I seem to > recall that they talked about it a lot, back when MPLS was still > trendy, but I haven't heard word one about it for many years since. > The TelX Video Exchange http://www.telx.com/Products-Services/telx-video-exchange.html is supposed to be a MPLS to MPLS exchange with some tailoring for H. 323 (and maybe SIP/RTP) video transport. Regards > -Bill > > > > > > > From ipv6nog at gmail.com Wed Jul 21 17:09:47 2010 From: ipv6nog at gmail.com (Jim Fleming) Date: Wed, 21 Jul 2010 17:09:47 -0500 Subject: NANOG to NEWNOG - BootCamp - August 9 - Friday, August 13, 2010 Message-ID: NANOG to NEWNOG - BootCamp - August 9 - Friday, August 13, 2010 Restart or jumpstart your career with Router fundamentals http://netfpga.org/tutorials/SummerCamp2010/index.php Atlanta.311 NANOG50 http://netfpga.org/foswiki/bin/view/NetFPGA/OneGig/ProjectTable Virtual Data Plane 1.2 In Progress Georgia Tech From asr+nanog at latency.net Wed Jul 21 17:56:11 2010 From: asr+nanog at latency.net (Adam Rothschild) Date: Wed, 21 Jul 2010 18:56:11 -0400 Subject: v6 bgp peer costs? In-Reply-To: References: Message-ID: <20100721225611.GA39732@latency.net> On 2010-07-21-15:08:10, Zaid Ali wrote: > I currently have a v4 BGP session with AS 701 and recently requested a v6 > BGP session to which I was told a tunnel session will be provided (Same > circuit would be better but whatever!). Towards the final stage in > discussions I was told that it will cost $1500. I find this quite ridiculous > and it will certainly not motivate people to move to v6 if providers put a > direct price tag on it. I am going through a bandwidth reseller though so I > am not sure who is trying to jack me here. Has anyone here gone through a > similar experience? You're certainly not in the minority. The practice of charging for v6 service (I've seen it represented as a MRC, NRC, and/or per-mb premium) seems partly rooted in a desire to gouge unsuspecting customers, and partly an honest misunderstanding of an organization's change processes and systems (is v6 considered a change request? New order?)... Whatever the situation, the correct response is to demand native connectivity at no charge, or else walk away at the expiration of your contract. Tunnels are messy now, and stand to become a lot messier as content adaptation and overall traffic volumes increase. -a From horms at verge.net.au Wed Jul 21 20:52:56 2010 From: horms at verge.net.au (Simon Horman) Date: Thu, 22 Jul 2010 10:52:56 +0900 Subject: PCH.net down? In-Reply-To: References: <048401cb28e7$45bdbc90$d13935b0$@net> Message-ID: <20100722015256.GB27663@verge.net.au> On Wed, Jul 21, 2010 at 11:48:42AM -0400, Christopher Morrow wrote: > On Wed, Jul 21, 2010 at 11:13 AM, Allen Bass wrote: > > I received the same message from http://downforeveryoneorjustme.com/pch.net > > but if I go to the site directly from Miami it pulls up, but is slow to do > > everyone should take careful note... downforeveryoneorjustme.com lives > ... on appengine at google, so 'downforeveryoneorjustme' really just > tests if google's network has a path to it. Thats quite a revelation. I assumed it tested from all points of the internet other than mine :^) From kauer at biplane.com.au Wed Jul 21 21:10:36 2010 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 22 Jul 2010 12:10:36 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: <1279764636.5467.101.camel@karl> On Wed, 2010-07-21 at 18:57 +0200, Alex Band wrote: > We've been working on an exercise for the IPv6 training course > [...] > how to subdivide prefixes over their network and how to write an > addressing plan. > Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ > I'm curious to hear if you think it's clear and useful. I think it is very clear, and very useful. Areas that might be improved: 1: It does not mention technical or management policy considerations. Those need to be clear before you can start divvying up your allocation. A technical policy point, for example, might be whether you are going to stick to /64 subnets throughout, or accept /126 on point to point links. A management policy might be to always provide for some level of expansion. I think the exercise would be better if it were prefaced by a phase where students (or the class as a group) work out the policies that will apply. 2: It is a very detailed, specific example using real numbers. The exercise demands a lot of technical precision that doesn't relate to the intellectual problem at hand. Technical precision is good, but it might be better sought in a separate exercise. You might get more out of students by getting them to think about what they would do in more general terms - i.e., the sizes and groupings of subnets rather than what specific subnets they would use. This would also help emphasis the point that it's not addresses that matter in IPv6 - it's subnets. 3: "There is no significant growth". Part of any network design should be to mitigate the unexpected. So IMHO students should be encouraged to, for example, duplicate addressing structures across POPs as much as is feasible, build in reserves for expansion and contraction, and use ULA addressing for internal networking components to reduce the pain if networks are split or merged. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From bill at herrin.us Wed Jul 21 22:03:43 2010 From: bill at herrin.us (William Herrin) Date: Wed, 21 Jul 2010 17:03:43 -1000 Subject: Looking for comments In-Reply-To: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> Message-ID: On Wed, Jul 21, 2010 at 3:18 AM, Fred Baker wrote: > IETF IPv6 Operations WG is looking at this draft, and we're interested > in any comments you might have as well. > > http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines > ?"Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred > ?Baker, 12-Jul-10 Hi Fred, Some feedback: In section 4.1, you kind of gloss over the challenges with native dual stack. You do state them, but if I didn't already know, I'd miss the significance of what you wrote. The significance is this: 1. The IPv6 Internet is not yet operating at the same availability standard as the IPv4 Internet and for reasons obvious to those of us who maintain operational systems, won't operate at the same standard until the networking emphasis (and funding!) moves from Ipv4 to Ipv6. 2. Connections to a dual stacked IPv6 host where the IPv6 path isn't working are much like connections to an IPv4 host with two IP addresses where one isn't working. With the added bonus that all assigned IPv6 addresses are tried first. The document is a little short on mitigations. Whitelisting between providers? Somehow in the name lookup? In what DNS software? And what about the folks who don't resolve names locally? There is a third major challenge to dual-stack that isn't addressed in the document: differing network security models that must deliver the same result for the same collection of hosts regardless of whether Ipv4 or v6 is selected. I can throw a COTS d-link box with address-overloaded NAT on a connection and have reasonably effective network security and anonymity in IPv4. Achieving comparable results in the IPv6 portion of the dual stack on each of those hosts is complicated at best. While interesting, 4.3 remains too deep in theory to seriously consider it for a short-term transition strategy. While 4.4 may be useful in the waning days of IPv4, it doesn't seem credible in the waxing days of IPv6. I'm going to make the vast majority of my customers pass through how many additional points of failure? That I have to pay extra to maintain? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jul 21 22:16:25 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 22 Jul 2010 12:46:25 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: <20100722124625.70ce5f53@opy.nosense.org> On Wed, 21 Jul 2010 18:57:01 +0200 Alex Band wrote: > We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. > > Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ > > I'm curious to hear if you think it's clear and useful. > You could add a reference to addressing related RFCs e.g. RFC 5375 "IPv6 Unicast Address Assignment Considerations" > Cheers, > > Alex Band > RIPE NCC Trainer > > (Big props go to Marco Hogewoning @XS4ALL) From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Jul 21 22:19:43 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 22 Jul 2010 12:49:43 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: <20100722124943.6f52345a@opy.nosense.org> On Wed, 21 Jul 2010 18:57:01 +0200 Alex Band wrote: > We've been working on an exercise for the IPv6 training course we deliver for LIRs. It's aimed at people who are unfamiliar with IPv6, so the goal is to get them to the point where once they get their IPv6 /32 allocation, they have a good idea how to subdivide prefixes over their network and how to write an addressing plan. > > Here's a PDF with the exercise (two pages A3): http://bit.ly/c7jZRJ > And I'd also explicitly mention that 2001:db8 is the documentation/example prefix. > I'm curious to hear if you think it's clear and useful. > > Cheers, > > Alex Band > RIPE NCC Trainer > > (Big props go to Marco Hogewoning @XS4ALL) From moreiras at nic.br Wed Jul 21 22:34:19 2010 From: moreiras at nic.br (Antonio M. Moreiras) Date: Thu, 22 Jul 2010 00:34:19 -0300 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <20100722124943.6f52345a@opy.nosense.org> References: <20100722124943.6f52345a@opy.nosense.org> Message-ID: <4C47BC3B.9020201@nic.br> I think it is a very well planned exercise. I would suggest you not to be straight in its execution. In some point, you could ask if the decisions would be the same in cases with different conditions: more pops, more users, less users, etc... We have a similar exercise in our training at NIC.br and we use this diagram to help the trainees understand the addresses: http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/enderec-v6.pdf... Maybe it could be useful. Moreiras. Em 22/07/10 00:19, Mark Smith escreveu: > >> I'm curious to hear if you think it's clear and useful. >> >> Cheers, >> >> Alex Band >> RIPE NCC Trainer >> >> (Big props go to Marco Hogewoning @XS4ALL) From owen at delong.com Wed Jul 21 22:37:12 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Jul 2010 20:37:12 -0700 Subject: Looking for comments In-Reply-To: References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> Message-ID: <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> > > > There is a third major challenge to dual-stack that isn't addressed in > the document: differing network security models that must deliver the > same result for the same collection of hosts regardless of whether > Ipv4 or v6 is selected. I can throw a COTS d-link box with > address-overloaded NAT on a connection and have reasonably effective > network security and anonymity in IPv4. Achieving comparable results > in the IPv6 portion of the dual stack on each of those hosts is > complicated at best. > Actually, it isn't particularly hard at all... Turn on privacy addressing on each of the hosts (if it isn't on by default) and then put a linux firewall in front of them with a relatively simple ip6tables configuration for outbound only. (The linux firewall could be as simple as a WRT-54G running dd-wrt or such). Owen From kauer at biplane.com.au Wed Jul 21 23:24:59 2010 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 22 Jul 2010 14:24:59 +1000 Subject: Looking for comments In-Reply-To: <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> Message-ID: <1279772699.5467.141.camel@karl> On Wed, 2010-07-21 at 20:37 -0700, Owen DeLong wrote: > I can throw a COTS d-link box with > > address-overloaded NAT on a connection and have reasonably effective > > network security and anonymity in IPv4. Achieving comparable results > > in the IPv6 portion of the dual stack on each of those hosts is > > complicated at best. > > > Actually, it isn't particularly hard at all... Turn on privacy addressing > on each of the hosts (if it isn't on by default) and then put a linux > firewall in front of them with a relatively simple ip6tables configuration > for outbound only. All respect to someone that knows his stuff, and I do realise that the OP mentioned small-scale hardware, but in the wider world (and even the world of home users as seen from the carrier side) any solution that says "do on every host" is just not workable. As for the Linux packet filter, that's an exercise for the advanced home user. Outside the home environment - well, most people here have traffic rates that would leave a Linux firewall a melted puddle of slag. It has to be a standards based solution, implemented in silicon. That said, you get 99% of everything worth having out of NAT with a packet filter that says "allow established and related in, allow anything out, block everything else". That can be implemented trivially on just about any router from the tiniest piece of CPE up to the Cisco and Juniper refrigerator boxes, and I would expect to see it the default in any IPv6 CPE (when they at last begin appearing). While there are people who want anonymity (by which they mean not exposing actual addresses to the Internet), I am of the opinion that this is little more than another version of security through obscurity, and that the very minor benefit it may confer is massively outweighed by the operational impost. Some people don't want their MAC addresses exposed to the Internet, so they don't want to use IPv6 autoconf addresses. I feel pretty much the same way about that idea as I do about the other, but at least there is a simple, standard solution for it - DHCP. DHCP is far less obstructive to troubleshooting and logging than privacy addresses. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From franck at genius.com Wed Jul 21 23:58:41 2010 From: franck at genius.com (Franck Martin) Date: Thu, 22 Jul 2010 16:58:41 +1200 (FJT) Subject: Looking for comments In-Reply-To: <1279772699.5467.141.camel@karl> Message-ID: <28175031.1319.1279774718013.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Karl Auer" > To: nanog at nanog.org > Sent: Thursday, 22 July, 2010 4:24:59 PM > Subject: Re: Looking for comments > On Wed, 2010-07-21 at 20:37 -0700, Owen DeLong wrote: > > I can throw a COTS d-link box with > > > address-overloaded NAT on a connection and have reasonably > > > effective > > > network security and anonymity in IPv4. Achieving comparable > > > results > > > in the IPv6 portion of the dual stack on each of those hosts is > > > complicated at best. > > > > > Actually, it isn't particularly hard at all... Turn on privacy > > addressing > > on each of the hosts (if it isn't on by default) and then put a > > linux > > firewall in front of them with a relatively simple ip6tables > > configuration > > for outbound only. > > All respect to someone that knows his stuff, and I do realise that the > OP mentioned small-scale hardware, but in the wider world (and even > the > world of home users as seen from the carrier side) any solution that > says "do on every host" is just not workable. As for the > Linux packet filter, that's an exercise for the advanced home user. On Mac Airport Extreme it is "disallow outside to access internal machines", tick and it is done! From owen at delong.com Thu Jul 22 00:35:24 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 21 Jul 2010 22:35:24 -0700 Subject: Looking for comments In-Reply-To: <28175031.1319.1279774718013.JavaMail.franck@franck-martins-macbook-pro.local> References: <28175031.1319.1279774718013.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <21CE3D31-17A3-4195-A400-420BEF33E38F@delong.com> On Jul 21, 2010, at 9:58 PM, Franck Martin wrote: > > > ----- Original Message ----- >> From: "Karl Auer" >> To: nanog at nanog.org >> Sent: Thursday, 22 July, 2010 4:24:59 PM >> Subject: Re: Looking for comments >> On Wed, 2010-07-21 at 20:37 -0700, Owen DeLong wrote: >>> I can throw a COTS d-link box with >>>> address-overloaded NAT on a connection and have reasonably >>>> effective >>>> network security and anonymity in IPv4. Achieving comparable >>>> results >>>> in the IPv6 portion of the dual stack on each of those hosts is >>>> complicated at best. >>>> >>> Actually, it isn't particularly hard at all... Turn on privacy >>> addressing >>> on each of the hosts (if it isn't on by default) and then put a >>> linux >>> firewall in front of them with a relatively simple ip6tables >>> configuration >>> for outbound only. >> >> All respect to someone that knows his stuff, and I do realise that the >> OP mentioned small-scale hardware, but in the wider world (and even >> the >> world of home users as seen from the carrier side) any solution that >> says "do on every host" is just not workable. As for the >> Linux packet filter, that's an exercise for the advanced home user. > In a home environment where do X on every host isn't workable, it's rare that every is more than 1, so, it's do X on THE host most of the time. Windows defaults to privacy addresses on by default, so, that also takes care of most of the environments where people have minimal understanding of technology. It takes some effort (minimal) on Linux. I haven't investigated what it takes on Mac. Again, this only matters if you care about address obfuscation anyway, which isn't really security, but, does provide some (minimal and ineffective) aspects of privacy. The packet filter doesn't have to be done on every host, just the gateway. > On Mac Airport Extreme it is "disallow outside to access internal machines", tick and it is done! That takes care of the packet filter, but, it doesn't handle the stated requirement for address obfuscation. I question the value of address obfuscation, but, the people with that religion will not give it up so I attempted to address the problem as stated. Owen From franck at genius.com Thu Jul 22 00:56:40 2010 From: franck at genius.com (Franck Martin) Date: Thu, 22 Jul 2010 17:56:40 +1200 (FJT) Subject: Looking for comments In-Reply-To: <21CE3D31-17A3-4195-A400-420BEF33E38F@delong.com> Message-ID: <8107049.1335.1279778197305.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Owen DeLong" > To: "Franck Martin" > Cc: "Karl Auer" , nanog at nanog.org > Sent: Thursday, 22 July, 2010 5:35:24 PM > Subject: Re: Looking for comments > On Jul 21, 2010, at 9:58 PM, Franck Martin wrote: > > > > > > On Mac Airport Extreme it is "disallow outside to access internal > > machines", tick and it is done! > > That takes care of the packet filter, but, it doesn't handle the > stated > requirement for address obfuscation. > > I question the value of address obfuscation, but, the people with that > religion will not give it up so I attempted to address the problem as > stated. Yes I understand that part, but all the people have already given away their privacy on Facebook, so why bother? If you are really worried about your privacy, then you will find the setting... I'm not sure in a corporate environment you will want address obfuscation for internal/legal reasons, so it would apply at home? but then I already know your network, and it does not matter if it is the computer of your wife, kids,... You are still responsible... May be in an open Wifi environment you will want to do that... From rodolfo.garciapenas at telefonica.es Thu Jul 22 02:40:39 2010 From: rodolfo.garciapenas at telefonica.es (rodolfo.garciapenas at telefonica.es) Date: Thu, 22 Jul 2010 09:40:39 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C474F90.9070704@viagenie.ca> Message-ID: Hi! this page may be useful http://www.getipv6.info/index.php/IPv6_Addressing_Plans Rodolfo Simon Perreault Para Marco Hogewoning 21/07/2010 22:02 cc Nanog Asunto Re: Addressing plan exercise for our IPv6 course On 2010-07-21 14:47, Marco Hogewoning wrote: > For a novice ? I wouldn't recommend it. From what I get back 'in the field' it's already hard enough to get people familliar to the whole concept of hexadecimal without going into bit level. But then again, if you are a fairly technical company maybe you can get away with it. Not disagreeing, but here's a tool to make it easier: http://www.ipv6book.ca/allocation.html Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org _____________________________________________________________________ Mensaje analizado y protegido por Telefonica Empresas From bill at herrin.us Thu Jul 22 02:49:40 2010 From: bill at herrin.us (William Herrin) Date: Wed, 21 Jul 2010 21:49:40 -1000 Subject: Looking for comments In-Reply-To: <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> Message-ID: On Wed, Jul 21, 2010 at 5:37 PM, Owen DeLong wrote: >>> http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines >> There is a third major challenge to dual-stack that isn't addressed in >> the document: differing network security models that must deliver the >> same result for the same collection of hosts regardless of whether >> Ipv4 or v6 is selected. I can throw a COTS d-link box with >> address-overloaded NAT on a connection and have reasonably effective >> network security and anonymity in IPv4. Achieving comparable results >> in the IPv6 portion of the dual stack on each of those hosts is >> complicated at best. >> > Actually, it isn't particularly hard at all... Turn on privacy addressing > on each of the hosts (if it isn't on by default) and then put a linux > firewall in front of them with a relatively simple ip6tables configuration > for outbound only. >From the lack of dispute, can I infer agreement with the remainder of my comments wrt mitigations for the "one of my addresses doesn't work" problem and the impracticality of the document's section 4.3 and 4.4 for wide scale Ipv6 deployment? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From elmi at 4ever.de Thu Jul 22 03:03:40 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Thu, 22 Jul 2010 10:03:40 +0200 Subject: v6 bgp peer costs? In-Reply-To: <4C474CB4.9050309@he.net> References: <4C474CB4.9050309@he.net> Message-ID: <20100722080339.GT96953@ronin.4ever.de> mleber at he.net (Mike Leber) wrote: > > You can get a free IPv6 BGP tunnel from Hurricane Electric at > http://tunnelbroker.net > > We have tunnel servers spread through out the world, so typically the > nearest server has reasonably low latency from your location. > > Of course our main business is selling wholesale native IPv6 and IPv4 > transit, however you don't have to be a paying customer to use our free > service. > > On 7/21/10 12:08 PM, Zaid Ali wrote: >> I currently have a v4 BGP session with AS 701 and recently requested a v6 >> BGP session to which I was told a tunnel session will be provided (Same >> circuit would be better but whatever!). Towards the final stage in >> discussions I was told that it will cost $1500. I find this quite Mike, Mike, I still wonder how you are able to sell the stuff that you are *also* giving away for free (minus the physical port) and that admittedly works like a charm... Elmar. PS: Keep up the good tunne^Wwork! PPS: Any plans on having something inside mainland China? From morrowc.lists at gmail.com Thu Jul 22 03:40:45 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 22 Jul 2010 09:40:45 +0100 Subject: "vpn exchange point" In-Reply-To: <50A582AE-7020-4038-AE2D-8C4559A48D25@americafree.tv> References: <47A1DD08-7CC0-4DF2-A557-77C956159C6B@pch.net> <266EAC81-B0BB-473D-B704-3658EB7C85A3@pch.net> <50A582AE-7020-4038-AE2D-8C4559A48D25@americafree.tv> Message-ID: equinix ethernet exchange On Wed, Jul 21, 2010 at 10:59 PM, Marshall Eubanks wrote: > > On Jul 21, 2010, at 5:43 PM, Bill Woodcock wrote: > >> >> On Jul 21, 2010, at 12:59 PM, William McCall wrote: >> >>> OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not sure >>> that I've (personally) ever heard of an IXP for MPLS. >> >> Isn't that what one iteration of IXP-NSP in Japan was? ?I seem to recall >> that they talked about it a lot, back when MPLS was still trendy, but I >> haven't heard word one about it for many years since. >> > > The TelX Video Exchange > > http://www.telx.com/Products-Services/telx-video-exchange.html > > is supposed to be a MPLS to MPLS exchange with some tailoring for H.323 (and > maybe SIP/RTP) video transport. > > Regards > > >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? -Bill >> >> >> >> >> >> >> > > > From morrowc.lists at gmail.com Thu Jul 22 03:43:06 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 22 Jul 2010 09:43:06 +0100 Subject: PCH.net down? In-Reply-To: <20100722015256.GB27663@verge.net.au> References: <048401cb28e7$45bdbc90$d13935b0$@net> <20100722015256.GB27663@verge.net.au> Message-ID: On Thu, Jul 22, 2010 at 2:52 AM, Simon Horman wrote: > Thats quite a revelation. I assumed it tested from all points of > the internet other than mine :^) I suspect it simple does an equivalent of 'wget' of the hostname you enter... the appengine api doesn't really permit much more than http/s out I think :( of course it COULD run that wget to some external service that queries from 100k other points of light, but really... I bet it's just doing it to the hostname you enter. -chris From bjorn at mork.no Thu Jul 22 07:16:00 2010 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 22 Jul 2010 14:16:00 +0200 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: (Jeffrey Ollie's message of "Fri, 16 Jul 2010 19:34:54 -0500") References: <20100716145315.GA19935@ussenterprise.ufp.org> <20100716153233.GA1137974@hiwaay.net> <4C40A12A.8050201@bogus.com> Message-ID: <87aapj4sqn.fsf@nemi.mork.no> Jeffrey Ollie writes: > On Fri, Jul 16, 2010 at 1:12 PM, Joel Jaeggli wrote: >> On 7/16/10 11:07 AM, Tony Finch wrote: >>> >>> On Fri, 16 Jul 2010, Chris Adams wrote: >>>> >>>> A simple XSLT will transform it into any needed format. >>> >>> XSLT can't turn root-anchors.xml into the DNSKEY RR that BIND requires. >> >> anchors2keys will. > > Actually, it won't. The ITAR anchors.xml and anchors2keys use a > different XML schema than the root-anchors.xml does. Just for the fun of it, I explored how difficult it would be implementing something similar in perl using the excellent Net::DNS::SEC module. It was really simple: http://www.mork.no/~bjorn/rootanchor2keys.pl Ugly as hell as usual with my perl code, but it works. And it is simple enough to be verifiable. You will need Net::DNS::SEC and XML::Simple from CPAN or your friendly OS distribution (libnet-dns-sec-perl and libxml-simple-perl in Debian) Bj?rn From owen at delong.com Thu Jul 22 08:02:04 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Jul 2010 06:02:04 -0700 Subject: Looking for comments In-Reply-To: References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> Message-ID: On Jul 22, 2010, at 12:49 AM, William Herrin wrote: > On Wed, Jul 21, 2010 at 5:37 PM, Owen DeLong wrote: >>>> http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines >>> There is a third major challenge to dual-stack that isn't addressed in >>> the document: differing network security models that must deliver the >>> same result for the same collection of hosts regardless of whether >>> Ipv4 or v6 is selected. I can throw a COTS d-link box with >>> address-overloaded NAT on a connection and have reasonably effective >>> network security and anonymity in IPv4. Achieving comparable results >>> in the IPv6 portion of the dual stack on each of those hosts is >>> complicated at best. >>> >> Actually, it isn't particularly hard at all... Turn on privacy addressing >> on each of the hosts (if it isn't on by default) and then put a linux >> firewall in front of them with a relatively simple ip6tables configuration >> for outbound only. > >> From the lack of dispute, can I infer agreement with the remainder of > my comments wrt mitigations for the "one of my addresses doesn't work" > problem and the impracticality of the document's section 4.3 and 4.4 > for wide scale Ipv6 deployment? > No, merely resignation to the fact that you don't get it. Owen From alexb at ripe.net Thu Jul 22 08:11:42 2010 From: alexb at ripe.net (Alex Band) Date: Thu, 22 Jul 2010 15:11:42 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C47BC3B.9020201@nic.br> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> Message-ID: Hi Antonio, That diagram looks interesting. We currently use slides with a bunch of animation to explain to this concept, but it may be nice to have something like this that people can keep as a printed version. By the way, this is what we think two possible answers are: http://bit.ly/9V5GfU There are more options, but these two are the most convenient weighing all the up and downsides. Does anyone disagree? Cheers, Alex On 22 Jul 2010, at 05:34, Antonio M. Moreiras wrote: > I think it is a very well planned exercise. I would suggest you not to > be straight in its execution. In some point, you could ask if the > decisions would be the same in cases with different conditions: more > pops, more users, less users, etc... > > We have a similar exercise in our training at NIC.br and we use this > diagram to help the trainees understand the addresses: > http://www.ipv6.br/pub/IPV6/MenuIPv6CursoPresencial/enderec-v6.pdf... > Maybe it could be useful. > > Moreiras. > > Em 22/07/10 00:19, Mark Smith escreveu: >> >>> I'm curious to hear if you think it's clear and useful. >>> >>> Cheers, >>> >>> Alex Band >>> RIPE NCC Trainer >>> >>> (Big props go to Marco Hogewoning @XS4ALL) > > > From bill at herrin.us Thu Jul 22 08:43:34 2010 From: bill at herrin.us (William Herrin) Date: Thu, 22 Jul 2010 03:43:34 -1000 Subject: Looking for comments In-Reply-To: References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> Message-ID: On Thu, Jul 22, 2010 at 3:02 AM, Owen DeLong wrote: > On Jul 22, 2010, at 12:49 AM, William Herrin wrote: >>> From the lack of dispute, can I infer agreement with the remainder of >> my comments wrt mitigations for the "one of my addresses doesn't work" >> problem and the impracticality of the document's section 4.3 and 4.4 >> for wide scale Ipv6 deployment? >> > No, merely resignation to the fact that you don't get it. I see. Well, you want to engage in a genuine discussion of the challenges which obstruct *my* deployment of Ipv6, you let me know. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From sfischer1967 at gmail.com Thu Jul 22 10:01:32 2010 From: sfischer1967 at gmail.com (Steven Fischer) Date: Thu, 22 Jul 2010 11:01:32 -0400 Subject: anyone seeing issues within the AT&T/SBC network today? Message-ID: seeing better than 90% (approaching 100%) packet loss to a host within the AT&T network today. Seems to be the result of either a severed link or some really munged up routing between AT&T and Verizon - from my traceroute, the issue appears about 8 hops into the AT&T network. Any insight into this is greatly appreciated. -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From strizhov at cs.colostate.edu Thu Jul 22 12:47:07 2010 From: strizhov at cs.colostate.edu (Mikhail Strizhov) Date: Thu, 22 Jul 2010 11:47:07 -0600 Subject: PCH.net down? In-Reply-To: References: Message-ID: <4C48841B.6000104@cs.colostate.edu> Dead again? Web page says "Could not connect: ". Northern Colorado, US. -- *Sincerely,* *Mikhail Strizhov* *Email: strizhov at cs.colostate.edu * On 07/21/2010 06:44 AM, Jason Lewis wrote: > This says it's not just down for me. http://downforeveryoneorjustme.com/pch.net > > Anyone else? > > From mikeal.clark at gmail.com Thu Jul 22 13:05:43 2010 From: mikeal.clark at gmail.com (Mikeal Clark) Date: Thu, 22 Jul 2010 13:05:43 -0500 Subject: PCH.net down? In-Reply-To: <4C48841B.6000104@cs.colostate.edu> References: <4C48841B.6000104@cs.colostate.edu> Message-ID: Up for me in Wi. Sent from my iPhone On Jul 22, 2010, at 12:47 PM, Mikhail Strizhov wrote: > Dead again? > > Web page says "Could not connect: ". > > Northern Colorado, US. > > -- > *Sincerely,* > *Mikhail Strizhov* > *Email: strizhov at cs.colostate.edu > > * > > On 07/21/2010 06:44 AM, Jason Lewis wrote: >> This says it's not just down for me. http://downforeveryoneorjustme.com/pch.net >> >> Anyone else? >> >> > From woody at pch.net Thu Jul 22 13:27:52 2010 From: woody at pch.net (Bill Woodcock) Date: Thu, 22 Jul 2010 11:27:52 -0700 Subject: PCH.net down? In-Reply-To: <4C48841B.6000104@cs.colostate.edu> References: <4C48841B.6000104@cs.colostate.edu> Message-ID: <2F745249-267C-4647-B245-04ED150208B4@pch.net> On Jul 22, 2010, at 10:47 AM, Mikhail Strizhov wrote: > Dead again? > Web page says "Could not connect: ". The multi-threaded download that's been hammering our web servers is still going on. We've just turned up a new server this morning, and expect to have the bulk-download processes moved over to it later today, offloading the stuff the rest of you are trying to use. My apologies. We're getting a lot of inquiries about it, so I'll try to post back to NANOG as soon as we think everything has been separated out and is working at full speed again. -Bill From wavetossed at googlemail.com Thu Jul 22 14:46:48 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 22 Jul 2010 20:46:48 +0100 Subject: "vpn exchange point" In-Reply-To: References: Message-ID: > Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns > > Let's say I'm an ISP that bought or merged with many small ISPs each with it's own AS# and would like to start offering mpls vpn services end to end In the MPLS world, this type of interconnect is called NNI (Network to Network Interconnect) and it needs to take into account things like COS mappings. I don't know of anyone doing this as an exchange, But I imagine that if you had a router with a private ASN, you could always do NNI with a different ASN on each port and therefore, achieve something analogous to an IXP. But you could only do this if you control all the ASNs involved, because vPn is a form of private network, so you need a higher level of trust with the other ASns. Most MPLS providers only use this to extend their reach into a territory where they will likely never build PoPs. For instance, to get good coverage of Russia, population 150 million, or the 4 Nordic countries, you could either build loss-leader PoPs, spend lots of money on longlining or do NNI with an MPLS provider that has good coverage because they focus on smaller regional customers. --Michael Dillon P.S. If you do this, it would be interesting to report back to NANOG on how you configured it, and what are the strengths and weaknesses. From morrowc.lists at gmail.com Thu Jul 22 16:17:25 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 22 Jul 2010 17:17:25 -0400 Subject: "vpn exchange point" In-Reply-To: References: Message-ID: On Thu, Jul 22, 2010 at 3:46 PM, Michael Dillon wrote: >> Do you know of any "vpn exchange point" implementations please? -I mean something like IXP but for mpls vpns >> >> Let's say I'm an ISP that bought or merged with many small ISPs each with it's own AS# and would like to start offering mpls vpn services end to end > > In the MPLS world, this type of interconnect is called NNI (Network to > Network Interconnect) hey look frame-relay! (joking, sorta, not really) In almost all cases this is still done via the A version (or 1 version of 4) mpls interconnect types where each customer VPN is broken down to native-IP links (vlans most often I believe, sometimes frame dlcis! :)) and the contracted cos/qos setup is replicated on the adjacent provider's interface as well... as you (michael) pointed out though, it's pretty much only done for 'i dont want to build in XXX' places. Additionally, from my (admittedly limited involvement) understanding these sorts of connections are notoriously problematic, painful and ultimately expensive for the provider(s) in question :( boo. > and it needs to take into account things like COS mappings. I don't > know of anyone doing this > as an exchange, But I imagine that if you had a router with a private > ASN, you could always > do NNI with a different ASN on each port and therefore, achieve > something analogous to an > IXP. the real question is why? what's the business driver? what's the support model? is it truly worthwhile? -chris From brian.e.carpenter at gmail.com Thu Jul 22 16:38:23 2010 From: brian.e.carpenter at gmail.com (Brian E Carpenter) Date: Fri, 23 Jul 2010 09:38:23 +1200 Subject: Looking for comments In-Reply-To: References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> Message-ID: <4C48BA4F.6030708@gmail.com> Bill, On 2010-07-22 19:49, William Herrin wrote: > On Wed, Jul 21, 2010 at 5:37 PM, Owen DeLong wrote: >>>> http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines >>> There is a third major challenge to dual-stack that isn't addressed in >>> the document: differing network security models that must deliver the >>> same result for the same collection of hosts regardless of whether >>> Ipv4 or v6 is selected. I can throw a COTS d-link box with >>> address-overloaded NAT on a connection and have reasonably effective >>> network security and anonymity in IPv4. Achieving comparable results >>> in the IPv6 portion of the dual stack on each of those hosts is >>> complicated at best. >>> >> Actually, it isn't particularly hard at all... Turn on privacy addressing >> on each of the hosts (if it isn't on by default) and then put a linux >> firewall in front of them with a relatively simple ip6tables configuration >> for outbound only. > >>From the lack of dispute, can I infer agreement with the remainder of > my comments wrt mitigations for the "one of my addresses doesn't work" > problem and the impracticality of the document's section 4.3 and 4.4 > for wide scale Ipv6 deployment? As for those two scenarios (IPv6-only ISPs and IPv6-only clients, to simplify them), the document doesn't place them as first preference solutions. However, the fact is that various *extremely* large operators find themselves more or less forced into these scenarios by IPv4 exhaustion. I think it's more reasonable to describe solutions for them than to rule their problem out of order. Brian From nick at foobar.org Thu Jul 22 17:57:22 2010 From: nick at foobar.org (Nick Hilliard) Date: Thu, 22 Jul 2010 23:57:22 +0100 Subject: Looking for comments In-Reply-To: <4C48BA4F.6030708@gmail.com> References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> <4C48BA4F.6030708@gmail.com> Message-ID: <4C48CCD2.5000308@foobar.org> On 22/07/2010 22:38, Brian E Carpenter wrote: > As for those two scenarios (IPv6-only ISPs and IPv6-only clients, to simplify > them), the document doesn't place them as first preference solutions. > However, the fact is that various *extremely* large operators find themselves > more or less forced into these scenarios by IPv4 exhaustion. Some of the extremely large operators have found themselves having to deploy ipv6 extensively in order to manage CPE devices and their infrastructure networks. However, I'm not aware of any large provider which is deploying ipv6-only customer access products, either due to a shortage of ipv4 space or any other reason. If you can supply names of providers doing this, I'd be very interested to hear. That's not to say that they won't start doing this relatively shortly. And you correctly point out that we need to create solutions _now_ so that access providers will have feature equivalence when they start deploying ipv6 in anger on access / hosted networks. This is a cue to get people on this list to shout at their vendors for ipv6 feature equivalence on their favourite kit. Nick From matthew at walster.org Thu Jul 22 18:33:45 2010 From: matthew at walster.org (Matthew Walster) Date: Fri, 23 Jul 2010 00:33:45 +0100 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> Message-ID: On 22 July 2010 14:11, Alex Band wrote: > There are more options, but these two are the most convenient weighing all > the up and downsides. Does anyone disagree? I never saw the point of assigning a /48 to a DSL customer. Surely the better idea would be to assign your bog standard residential DSL customer a /64 and assign them a /56 or /48 if they request it, routed to an IP of their choosing. For the rest of it, I largely agree, though. M From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Jul 22 19:17:21 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 23 Jul 2010 09:47:21 +0930 Subject: Looking for comments In-Reply-To: <4C48CCD2.5000308@foobar.org> References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> <4C48BA4F.6030708@gmail.com> <4C48CCD2.5000308@foobar.org> Message-ID: <20100723094721.61f6ed4d@opy.nosense.org> On Thu, 22 Jul 2010 23:57:22 +0100 Nick Hilliard wrote: > On 22/07/2010 22:38, Brian E Carpenter wrote: > > As for those two scenarios (IPv6-only ISPs and IPv6-only clients, to simplify > > them), the document doesn't place them as first preference solutions. > > However, the fact is that various *extremely* large operators find themselves > > more or less forced into these scenarios by IPv4 exhaustion. > > Some of the extremely large operators have found themselves having to > deploy ipv6 extensively in order to manage CPE devices and their > infrastructure networks. However, I'm not aware of any large provider > which is deploying ipv6-only customer access products, either due to a > shortage of ipv4 space or any other reason. If you can supply names of > providers doing this, I'd be very interested to hear. > Does this qualify? What the customer sees is delivered over IPv6, unlike the CPE management problem, where the ISP is the "IPv6 customer". "IPv6: The Future of IPTV? In Japan it isn't the future, it's now." http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm > That's not to say that they won't start doing this relatively shortly. > And you correctly point out that we need to create solutions _now_ so > that access providers will have feature equivalence when they start > deploying ipv6 in anger on access / hosted networks. > > This is a cue to get people on this list to shout at their vendors for > ipv6 feature equivalence on their favourite kit. > > Nick > From franck at genius.com Thu Jul 22 19:22:52 2010 From: franck at genius.com (Franck Martin) Date: Fri, 23 Jul 2010 12:22:52 +1200 (FJT) Subject: Looking for comments In-Reply-To: <20100723094721.61f6ed4d@opy.nosense.org> Message-ID: <31670233.1547.1279844569864.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Mark Smith" > To: "Nick Hilliard" > Cc: "NANOG list" , "Brian E Carpenter" > Sent: Friday, 23 July, 2010 12:17:21 PM > Subject: Re: Looking for comments > On Thu, 22 Jul 2010 23:57:22 +0100 > Nick Hilliard wrote: > > > On 22/07/2010 22:38, Brian E Carpenter wrote: > > > As for those two scenarios (IPv6-only ISPs and IPv6-only clients, > > > to simplify > > > them), the document doesn't place them as first preference > > > solutions. > > > However, the fact is that various *extremely* large operators find > > > themselves > > > more or less forced into these scenarios by IPv4 exhaustion. > > > > Some of the extremely large operators have found themselves having > > to > > deploy ipv6 extensively in order to manage CPE devices and their > > infrastructure networks. However, I'm not aware of any large > > provider > > which is deploying ipv6-only customer access products, either due to > > a > > shortage of ipv4 space or any other reason. If you can supply names > > of > > providers doing this, I'd be very interested to hear. > > > > Does this qualify? What the customer sees is delivered over IPv6, > unlike the CPE management problem, where the ISP is the "IPv6 > customer". > > "IPv6: The Future of IPTV? In Japan it isn't the future, it's now." > http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm > In the USA too, see netflix From Valdis.Kletnieks at vt.edu Thu Jul 22 19:24:18 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 22 Jul 2010 20:24:18 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: Your message of "Fri, 23 Jul 2010 00:33:45 BST." References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> Message-ID: <6289.1279844658@localhost> On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said: > I never saw the point of assigning a /48 to a DSL customer. Surely the > better idea would be to assign your bog standard residential DSL > customer a /64 and assign them a /56 or /48 if they request it, routed > to an IP of their choosing. If they're using autoconfigure for IPv6 addresses, what happens if they want to share that connection? Giving them a /64 off the bat means that a very sizable fraction of your users are going to call. Phrased differently - how screwed would you be if you engineered your IPv4 network so the default was "one device only", and the customer had to call you and ask for a network config change because they wanted to hook up a $50 home wifi router? If it doesn't make sense for IPv4, why would you want to do it for IPv6? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From matthew at matthew.at Thu Jul 22 19:37:53 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 22 Jul 2010 17:37:53 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <6289.1279844658@localhost> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> Message-ID: <4C48E461.9090002@matthew.at> Valdis.Kletnieks at vt.edu wrote: > On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said: > > >> I never saw the point of assigning a /48 to a DSL customer. Surely the >> better idea would be to assign your bog standard residential DSL >> customer a /64 and assign them a /56 or /48 if they request it, routed >> to an IP of their choosing. >> > > If they're using autoconfigure for IPv6 addresses, what happens if they want to > share that connection? Giving them a /64 off the bat means that a very sizable > fraction of your users are going to call. > > Phrased differently - how screwed would you be if you engineered your IPv4 > network so the default was "one device only", and the customer had to call you > and ask for a network config change because they wanted to hook up a $50 home > wifi router? > > If it doesn't make sense for IPv4, why would you want to do it for IPv6? > "Home wifi router" vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls. Matthew Kaufman From kauer at biplane.com.au Thu Jul 22 19:45:43 2010 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 23 Jul 2010 10:45:43 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <6289.1279844658@localhost> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> Message-ID: <1279845943.28305.7.camel@karl> On Thu, 2010-07-22 at 20:24 -0400, Valdis.Kletnieks at vt.edu wrote: > On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said: > > I never saw the point of assigning a /48 to a DSL customer. Surely the > > better idea would be to assign your bog standard residential DSL > > customer a /64 and assign them a /56 or /48 if they request it, routed > > to an IP of their choosing. > > If they're using autoconfigure for IPv6 addresses, what happens if they want to > share that connection? Giving them a /64 off the bat means that a very sizable > fraction of your users are going to call. Um, but they will have 18 billion billion addresses in that /64. That should do them, unless they want to subnet in the home. Which is not so unusual, so while doing a /48 might be overkill, doing a /60 or even a /56 off the bat is not such a silly idea. Unless I've misunderstood Matthew, and he was suggesting that the /64 be the link network. That would indeed effectively give the customer a single address, unless it was being bridged rather than routed at the CPE. Not sure bridging it is such a good idea - most people will probably want their home networks to keep working even if the ISP has an outage. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jkelty at pandora.com Thu Jul 22 20:50:56 2010 From: jkelty at pandora.com (James Kelty) Date: Thu, 22 Jul 2010 18:50:56 -0700 Subject: Qwest NOC contact? Message-ID: Could a clueful Qwest NOC engineer contact me off list regarding this: jkelty at zao:512 -> mtr --curses --no-dns --report --report-cycles=2 205.185.95.11 HOST: zao Loss% Snt Last Avg Best Wrst StDev 1. 208.85.40.5 0.0% 2 0.3 0.4 0.3 0.5 0.1 2. 208.85.40.1 0.0% 2 0.6 0.6 0.6 0.6 0.0 3. 77.67.77.185 0.0% 2 9.4 5.2 1.0 9.4 6.0 4. 77.67.68.118 0.0% 2 1.2 1.3 1.2 1.3 0.0 5. 67.14.1.218 0.0% 2 30.6 30.6 30.6 30.6 0.0 6. 205.171.155.38 0.0% 2 31.1 30.9 30.8 31.1 0.2 7. 67.134.58.130 0.0% 2 35.4 35.6 35.4 35.8 0.3 8. 67.129.132.33 0.0% 2 35.3 35.7 35.3 36.2 0.6 9. 67.129.132.34 0.0% 2 36.8 36.3 35.8 36.8 0.8 10. 67.129.132.33 0.0% 2 36.3 35.9 35.6 36.3 0.5 11. 67.129.132.34 0.0% 2 35.7 36.3 35.7 36.8 0.8 12. 67.129.132.33 0.0% 2 36.2 36.0 35.8 36.2 0.3 13. 67.129.132.34 0.0% 2 36.0 36.2 36.0 36.3 0.2 14. 67.129.132.33 0.0% 2 35.9 35.9 35.8 35.9 0.1 15. 67.129.132.34 0.0% 2 36.2 36.0 35.8 36.2 0.3 16. 67.129.132.33 0.0% 2 36.2 36.1 36.0 36.2 0.2 17. 67.129.132.34 0.0% 2 36.0 36.0 36.0 36.1 0.1 18. 67.129.132.33 0.0% 2 37.0 36.5 36.1 37.0 0.6 19. 67.129.132.34 0.0% 2 36.1 37.9 36.1 39.8 2.6 20. 67.129.132.33 0.0% 2 37.4 37.3 37.3 37.4 0.1 21. 67.129.132.34 0.0% 2 36.9 39.2 36.9 41.5 3.3 22. 67.129.132.33 0.0% 2 36.0 36.1 36.0 36.3 0.2 23. 67.129.132.34 0.0% 2 36.7 36.8 36.7 36.9 0.1 24. 67.129.132.33 0.0% 2 36.6 36.5 36.4 36.6 0.1 25. 67.129.132.34 0.0% 2 36.4 36.5 36.4 36.6 0.2 26. 67.129.132.33 0.0% 2 45.8 41.3 36.8 45.8 6.4 27. 67.129.132.34 0.0% 2 36.4 36.6 36.4 36.8 0.3 28. 67.129.132.33 0.0% 2 37.4 38.8 37.4 40.2 2.0 29. 67.129.132.34 0.0% 2 37.7 38.0 37.7 38.3 0.4 30. 67.129.132.33 0.0% 2 37.1 37.1 37.1 37.1 0.0 jkelty at zao:513 -> whois -h whois.cymru.com " -v 67.129.132.33" AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 209 | 67.129.132.33 | 67.128.0.0/13 | US | arin | 2002-07-12 | ASN-QWEST - Qwest Communications Company, LLC jkelty at zao:514 -> whois -h whois.cymru.com " -v 205.185.95.11" AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name 209 | 205.185.95.11 | 205.185.64.0/19 | US | arin | 2009-07-16 | ASN-QWEST - Qwest Communications Company, LLC jkelty at zao:515 -> Thanks. -James -- James Kelty Lead Network Engineer jkelty at pandora.com "The New Jersey Nets are the Detroit Lions of the NBA" - Max K., Age 12 From owen at delong.com Thu Jul 22 21:34:56 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Jul 2010 19:34:56 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C48E461.9090002@matthew.at> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <4C48E461.9090002@matthew.at> Message-ID: <249A55AC-0EB0-4D91-91F0-520FA1EAFD8C@delong.com> On Jul 22, 2010, at 5:37 PM, Matthew Kaufman wrote: > Valdis.Kletnieks at vt.edu wrote: >> On Fri, 23 Jul 2010 00:33:45 BST, Matthew Walster said: >> >> >>> I never saw the point of assigning a /48 to a DSL customer. Surely the >>> better idea would be to assign your bog standard residential DSL >>> customer a /64 and assign them a /56 or /48 if they request it, routed >>> to an IP of their choosing. >>> >> >> If they're using autoconfigure for IPv6 addresses, what happens if they want to >> share that connection? Giving them a /64 off the bat means that a very sizable >> fraction of your users are going to call. >> >> Phrased differently - how screwed would you be if you engineered your IPv4 >> network so the default was "one device only", and the customer had to call you >> and ask for a network config change because they wanted to hook up a $50 home >> wifi router? >> >> If it doesn't make sense for IPv4, why would you want to do it for IPv6? >> > "Home wifi router" vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls. > > Matthew Kaufman Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary? Owen From bora at pnl.gov Thu Jul 22 21:53:48 2010 From: bora at pnl.gov (Akyol, Bora A) Date: Thu, 22 Jul 2010 19:53:48 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <249A55AC-0EB0-4D91-91F0-520FA1EAFD8C@delong.com> Message-ID: As long as customers believe that having a NAT router/"firewall" in place is a security feature, I don't think anyone is going to get rid of the NAT box. In all reality, NAT boxes do work for 99% of customers out there. Bora On 7/22/10 7:34 PM, "Owen DeLong" wrote: Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary? Owen From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Jul 22 22:26:14 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 23 Jul 2010 12:56:14 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> Message-ID: <20100723125614.4beb1659@opy.nosense.org> On Fri, 23 Jul 2010 00:33:45 +0100 Matthew Walster wrote: > On 22 July 2010 14:11, Alex Band wrote: > > There are more options, but these two are the most convenient weighing all > > the up and downsides. Does anyone disagree? > > I never saw the point of assigning a /48 to a DSL customer. Surely the > better idea would be to assign your bog standard residential DSL > customer a /64 and assign them a /56 or /48 if they request it, routed > to an IP of their choosing. > I estimate that an addressing request will cost the ISP at least 15 minutes of time to process. When a minimum allocation of a /32 contains 16 777 216 /56s, do you really need to create that artificial addressing cost, eventually passed onto the customer? With more address space than we need, the value we get is addressing convenience (just like we've had in Ethernet addressing since 1982). There is no need to make IPv6 addressing artificially precious and as costly as IPv4 addressing is. There are a variety of scenarios where customers, including residential, will benefit from having multiple subnets. They may wish to separate the wired and wireless segments, to prevent multicast IPTV from degrading wireless performance. They may wish to segregate the children/family PC from the adult PC network or SOHO network, allowing the subnet boundary to be an additional Internet access policy enforcement point. They'll need separate subnets if they wish to use a different link layer technology, such as LoWPAN. They may wish to setup a separate subnet to act as a DMZ for Internet facing devices, such as a local web server for sharing photos with relatives. Game consoles may be put in a separate subnet to ensure file transfers don't interfere with game traffic latency, using the subnet ID as a QoS classifier. > For the rest of it, I largely agree, though. > > M > From jabley at hopcount.ca Thu Jul 22 22:52:58 2010 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 23 Jul 2010 05:52:58 +0200 Subject: Root Zone DNSSEC Deployment Technical Status Update In-Reply-To: <20100716145315.GA19935@ussenterprise.ufp.org> References: <20100716145315.GA19935@ussenterprise.ufp.org> Message-ID: Hi Leo, Late reply! Sorry. Have been neglecting this folder. On 2010-07-16, at 16:53, Leo Bicknell wrote: > In a message written on Fri, Jul 16, 2010 at 02:35:39PM +0000, Joe Abley wrote: >> The transition from Deliberately-Unvalidatable Root Zone (DURZ) to >> production signed root zone took place on 2010-07-15 at 2050 UTC. The >> first full production signed root zone had SOA serial 2010071501. There >> have been no reported harmful effects. The root zone trust anchor can >> be found at . > > Perhaps you could explain why the keys are being made available in > formats that, as far as I can tell, no nameserver software on the > planet uses? There seem to be two related issues, here: 1. Why use a format that is non-native to any particular implementation? We made the decision to publish the trust anchor in a vendor-independent fashion. We also wanted a way of publishing a full set of current plus historic trust anchors (for which there is no obvious prior art). The XML representation you've seen has the advantage that precisely because it is not in a format directly amenable to cut and paste (although obviously you can scrape the RDATA out of it easily; it's just a text file) there's reduced risk that someone would paste an old trust anchor into a validator's configuration and experience great user hilarity. We have already seen people produce tools which can process the XML-published trust anchor set to configure validators. No doubt we will see more tools in future. Maybe some vendors will decide to support it directly. 2. Why publish the trust anchor as a hash of the public key (DS RDATA) rather than the public key itself (DNSKEY RDATA)? Because as far as we can identify, that's the consensus in the relevant IETF working groups for how trust anchors should be published. I've heard the argument both ways. Don't shoot the messenger. On a more general note we first published the document which described the trust anchor format back in January, and since then we've been soliciting input on that (and other documents) in more or less every ops meeting and ops mailing list you could mention. We got zero feedback on that document, and perhaps unreasonably we interpreted that as a lack of concern over (e.g.) the point you mentioned. Here's a link to the final version: http://www.root-dnssec.org/wp-content/uploads/2010/07/draft-icann-dnssec-trust-anchor-01.txt Joe From jmaimon at ttec.com Thu Jul 22 23:09:09 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 23 Jul 2010 00:09:09 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <249A55AC-0EB0-4D91-91F0-520FA1EAFD8C@delong.com> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <4C48E461.9090002@matthew.at> <249A55AC-0EB0-4D91-91F0-520FA1EAFD8C@delong.com> Message-ID: <4C4915E5.9030005@ttec.com> Owen DeLong wrote: > > On Jul 22, 2010, at 5:37 PM, Matthew Kaufman wrote: > >> Valdis.Kletnieks at vt.edu wrote: > >>> >>> If it doesn't make sense for IPv4, why would you want to do it for IPv6? >>> >> "Home wifi router" vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls. >> >> Matthew Kaufman > > Well, wouldn't it be better if the provider simply issued enough space to > make NAT66 unnecessary? > > Owen > If the only reason the common denominator of internet service has not and does not come with more than minimum sufficient supply of IPv4 is due to scarcity, then it may be reasonable to hope that in the future the common denominator of internet service will include near limitless IPv6 addresses for its end users. Very likely, that is better. However, even then, there is no guarantee that the common denominator CPE for this service wont have NAT66 features, maybe even turned on by default. And if those CPE do have the feature on by default, then there is no reason for vendors to do more than supply the single /128 or even /64. Perhaps CPE will respond to a market condition of that nature by throwing out /64 subnetting rules and implementing their own divide-and-consume addressing scheme. And so it may go on and on. Action by action, reaction by reaction, the common scenario evolves, constantly. Automatic extension of dynamic routing protocols deep into the customers network may not be as sound a notion and as universally adoptable as is currently viewed. I believe it is way too early to predict with any confidence how this will play out. NAT44 did not become the method-du-jour until well after the scarcity was felt by the actual end users of the IPv4 network. Its increasing effect on network design and engineering came later yet. So any addressing plan that does not leave a hefty chunk of space reserved to be available for unknown future uses, a la IANA's other /3s, strikes me as unable or unwilling to withstand the test of time, by design. It would be an epic tragedy if down the road those other /3's were deemed as unusable as 240/4, maybe even for similar reasons. I suspect the perfect address plan is the holy grail of networking and just as locatable. Joe From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Jul 22 23:15:17 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 23 Jul 2010 13:45:17 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <249A55AC-0EB0-4D91-91F0-520FA1EAFD8C@delong.com> Message-ID: <20100723134517.6a67df97@opy.nosense.org> On Thu, 22 Jul 2010 19:53:48 -0700 "Akyol, Bora A" wrote: > As long as customers believe that having a NAT router/"firewall" in place is a security feature, > I don't think anyone is going to get rid of the NAT box. > You need to separate the NAT function (or more specifically, Network Address Port Translation (NAPT)), and the side effect of that operation being a deny all for uninitiated inbound traffic. It is not a unique property to NAPT, and in fact, stateful firewalling using public addresses has been around as long as NAT (at least since 1995 IIRC). > In all reality, NAT boxes do work for 99% of customers out there. > So would a firewall with public addressing. It's worked for me for 10+ years with IPv4, and 4+ years with IPv6. Of course, it didn't protect me when I ran an email attachment that contained malware, or when I clicked on one of those "PC check" popups that installed an application. (well, not actually me, but a large number of people do this, helping the attacker completely bypass any "NAT security". Inviting the attacker in as though they were a trusted guest makes the best locks in the world on the door a waste of time.) It seems you haven't done much with NAT to have encountered it's limitations, or experienced the benefits of end-to-end connectivity (ever had to stuff around with port forwarding, TURN, STUN etc. to get VoIP working at home? I haven't, and I got to spend that time on something else much more useful than fiddling with NAT work arounds.) > > Bora > > > On 7/22/10 7:34 PM, "Owen DeLong" wrote: > > > Well, wouldn't it be better if the provider simply issued enough space to > make NAT66 unnecessary? > > Owen > > > > From frnkblk at iname.com Thu Jul 22 23:35:30 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Thu, 22 Jul 2010 23:35:30 -0500 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <249A55AC-0EB0-4D91-91F0-520FA1EAFD8C@delong.com> Message-ID: Keep selling them the NAT router, just don't tell them that it applies only to IPv4 only and not to IPv6. 99.9% of consumers don't know about NAT, they just want to plug it in and be connected. That's why having a stateful firewall as standard element of an IPv6-capable router specification would keep SOHO IPv6 connectivity "on par" with IPv4. Frank -----Original Message----- From: Akyol, Bora A [mailto:bora at pnl.gov] Sent: Thursday, July 22, 2010 9:54 PM To: Owen DeLong; matthew at matthew.at Cc: nanog list Subject: Re: Addressing plan exercise for our IPv6 course As long as customers believe that having a NAT router/"firewall" in place is a security feature, I don't think anyone is going to get rid of the NAT box. In all reality, NAT boxes do work for 99% of customers out there. Bora On 7/22/10 7:34 PM, "Owen DeLong" wrote: Well, wouldn't it be better if the provider simply issued enough space to make NAT66 unnecessary? Owen From jmaimon at ttec.com Thu Jul 22 23:51:14 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 23 Jul 2010 00:51:14 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <20100723125614.4beb1659@opy.nosense.org> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <20100723125614.4beb1659@opy.nosense.org> Message-ID: <4C491FC2.5040308@ttec.com> Mark Smith wrote: > On Fri, 23 Jul 2010 00:33:45 +0100 > Matthew Walster wrote: > >> On 22 July 2010 14:11, Alex Band wrote: >>> There are more options, but these two are the most convenient weighing all >>> the up and downsides. Does anyone disagree? >> >> I never saw the point of assigning a /48 to a DSL customer. Surely the >> better idea would be to assign your bog standard residential DSL >> customer a /64 and assign them a /56 or /48 if they request it, routed >> to an IP of their choosing. >> > > I estimate that an addressing request will cost the ISP at least 15 > minutes of time to process. When a minimum allocation of a /32 contains > 16 777 216 /56s, do you really need to create that artificial > addressing cost, eventually passed onto the customer? Funny how so much concern is given to eliminating the possibility of end users returning for more space, yet for ISP's we have no real concern with what will happen when they near depletion of their /32 what with /48s to some thousands customers, aggregation, churn, what have you. The effort and cost of that on the organization is hard to predict, especially as how it may vary from size to size, organization to organization. Furthermore, everyone else pays with a DFZ slot. /48 per customer gives the customer as many potential subnets as you have potential customers. > > With more address space than we need, the value we get is addressing > convenience (just like we've had in Ethernet addressing since 1982). > There is no need to make IPv6 addressing artificially precious and as > costly as IPv4 addressing is. A balance should be struck and for that to happen, weight must be given to both sides. Joe From owen at delong.com Fri Jul 23 00:13:10 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Jul 2010 22:13:10 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: <8AC1FEFF-C2A5-4063-BB26-8F11BB1985EE@delong.com> In all reality: 1. NAT has nothing to do with security. Stateful inspection provides security, NAT just mangles addresses. 2. In the places where NAT works, it does so at a terrible cost. It breaks a number of things, and, applications like Skype are incredibly more complex pieces of code in order to solve NAT traversal. The elimination of NAT is one of the greatest features of IPv6. Most customers don't know or care what NAT is and wouldn't know the difference between a NAT firewall and a stateful inspection firewall. I do think that people will get rid of the NAT box by and large, or, at least in IPv6, the box won't be NATing. Whether or not they NAT it, it's still better to give the customer enough addresses that they don't HAVE to NAT. Owen On Jul 22, 2010, at 7:53 PM, Akyol, Bora A wrote: > As long as customers believe that having a NAT router/"firewall" in place is a security feature, > I don't think anyone is going to get rid of the NAT box. > > In all reality, NAT boxes do work for 99% of customers out there. > > > Bora > > > On 7/22/10 7:34 PM, "Owen DeLong" wrote: > > > Well, wouldn't it be better if the provider simply issued enough space to > make NAT66 unnecessary? > > Owen > > From owen at delong.com Fri Jul 23 00:23:17 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 22 Jul 2010 22:23:17 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C491FC2.5040308@ttec.com> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <20100723125614.4beb1659@opy.nosense.org> <4C491FC2.5040308@ttec.com> Message-ID: <07A85B5D-CF76-442A-84CE-C48F4265D2F7@delong.com> On Jul 22, 2010, at 9:51 PM, Joe Maimon wrote: > > > Mark Smith wrote: >> On Fri, 23 Jul 2010 00:33:45 +0100 >> Matthew Walster wrote: >> >>> On 22 July 2010 14:11, Alex Band wrote: >>>> There are more options, but these two are the most convenient weighing all >>>> the up and downsides. Does anyone disagree? >>> >>> I never saw the point of assigning a /48 to a DSL customer. Surely the >>> better idea would be to assign your bog standard residential DSL >>> customer a /64 and assign them a /56 or /48 if they request it, routed >>> to an IP of their choosing. >>> >> >> I estimate that an addressing request will cost the ISP at least 15 >> minutes of time to process. When a minimum allocation of a /32 contains >> 16 777 216 /56s, do you really need to create that artificial >> addressing cost, eventually passed onto the customer? > > Funny how so much concern is given to eliminating the possibility of end users returning for more space, yet for ISP's we have no real concern with what will happen when they near depletion of their /32 what with /48s to some thousands customers, aggregation, churn, what have you. > There's no need to give it a lot of concern because that process is pretty well understood and not particularly different from the current process in IPv4. When an ISP runs out, they apply for more from either their upstream, or, their RIR. Just that simple. > The effort and cost of that on the organization is hard to predict, especially as how it may vary from size to size, organization to organization. Furthermore, everyone else pays with a DFZ slot. > Yeah, but, the number of DFZ slots consumed by this in IPv6 will be so much smaller than IPv4 that I really find it hard to take this argument seriously. Additionally, it's not necessarily true due to allocation by bisection. > /48 per customer gives the customer as many potential subnets as you have potential customers. > You say that like it is a bad thing. >> >> With more address space than we need, the value we get is addressing >> convenience (just like we've had in Ethernet addressing since 1982). >> There is no need to make IPv6 addressing artificially precious and as >> costly as IPv4 addressing is. > > A balance should be struck and for that to happen, weight must be given to both sides. > And it has. /32 is merely the default minimum allocation to an ISP. Larger blocks can be given, and, now that the RIRs are allocating by bisection, it should even be possible in most cases for that additional space to be an expansion of the existing allocation without changing the number of prefixes. e.g. 2001:db8::/32 could be expanded to 2001:db8::/28 16 times as much address space, same number of DFZ slots. Owen From marcoh at marcoh.net Fri Jul 23 03:06:43 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 23 Jul 2010 10:06:43 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> Message-ID: <9C3B3385-0201-4E80-B441-804BB39EE1D0@marcoh.net> On 23 jul 2010, at 01:33, Matthew Walster wrote: > On 22 July 2010 14:11, Alex Band wrote: >> There are more options, but these two are the most convenient weighing all >> the up and downsides. Does anyone disagree? > > I never saw the point of assigning a /48 to a DSL customer. Surely the > better idea would be to assign your bog standard residential DSL > customer a /64 and assign them a /56 or /48 if they request it, routed > to an IP of their choosing. /64 is too small, especially when sensornetworks take off you probably want multple ranges. In fact the CPE we use at the moment already takes a /64 for internals like voip clients, dns resolver and management interfaces and assigns the second one to the LAN. Optionally you want people to create a seperate zone for wifi guests (it supports dual band radio). So in reallife you already need more then one. Giving the way reverse DNS is designed I wouldn't recommend people to leave the 4 bit boundry on which it is organised unless you want to make your life miserable and complicated. So that would make it a /60 at minimum. So why /48 and not /56 or /60 ? We'll first of all we, and I mean the collective group of people that tries to run the internet (which includes you reading this), screwed it up in marketing. First of all we keep telling everybody there are so many addresses we will never run out of them. Now of course this is BS and we all know that someday we find 128 bits wasn't enough. By that time we probably realise that the current almost classfull system wasn't a smart choice and we introduce CIDR again to save our day. Which brings me to the second point and that is introducing semi fixed borders like /64 for a subnet and the original wording 'if you think they ever need more then one subnet, assign a /48'. That amazingly got stuck in peoples head like classfull once did. I still have customers asking for a C-class and some of them are even born in the CIDR era. As far as the customer base understand what IPv6 is, all they ever hear is 'I'll get a /48' even in those cases where you say something else. We told them NATs are going away and we told them we had so many addresses there wasn't a problem at all. /64 subnet, /48 when you need more did the rest. So assume I assign the mass that is unaware a /64, do I reserve some bits for future growth? I'll bet you when IPv6 does hit the market somebody will find an application for it and requires a second subnet (sensors for instance). What do I do when somebody requests this, assign a secondary /64 or renumber ? So maybe I should reserve a /60, but is that different from assigning it directly ? Takes up space anyway. So now I assign a /60, unfortunately the /48 is stuck in people's head so I get people complaining about this. This is amplified by the fact that early adopters, even the ones with tunnels, got a /48. Remember those folks who got a /8 back in the days, did you ever thought 'what if I would have been there' ? So I get into discussions with customers and that has a cost, I at least have to pay for the guy who answers the phone on our end. Next to that, there is that risk that I lose business because the shop across the road does offer /56 or even /48. Which brings me into the economics, we are in a hurry. We need to deploy and we need to deploy yesterday. In fact if you are not running IPv6 by now, you are too late. So I have the choice of creating a really complicated deployment scheme in which I can assign variable subnet lenghts to customers without breaking aggregation and without annoying them with renumbering. One-size-fits-all makes life easy and saves an huge pile of money and not only money but it saves time, time I need, beacuse we are already a bit late. In short, why a /48 'Because we can!'. We had about 15 years to design a proper scheme, we failed. Now we can discuss a redesign, but then we need to squeeze another 10 years out of IPv4. MarcoH From marcoh at marcoh.net Fri Jul 23 03:07:56 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 23 Jul 2010 10:07:56 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C48E461.9090002@matthew.at> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <4C48E461.9090002@matthew.at> Message-ID: > "Home wifi router" vendors will do whatever it takes to make this work, so of course in your scenario they simply implement NAT66 (whether or not IETF folks think it is a good idea) however they see fit and nobody calls. This will greatly help in deploying IPv6...here is another NAT because we said NATs would disappear. MarcoH From marcoh at marcoh.net Fri Jul 23 03:10:34 2010 From: marcoh at marcoh.net (Marco Hogewoning) Date: Fri, 23 Jul 2010 10:10:34 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C4915E5.9030005@ttec.com> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <4C48E461.9090002@matthew.at> <249A55AC-0EB0-4D91-91F0-520FA1EAFD8C@delong.com> <4C4915E5.9030005@ttec.com> Message-ID: > However, even then, there is no guarantee that the common denominator CPE for this service wont have NAT66 features, maybe even turned on by default. I've tested a lot of CPE's and haven't come across one that supports NAT66, they all do support DHCPv6 prefix delegation and actually most of them require it to work as most can't bridge between the WAN and LAN on the same /64. MarcoH From jordi.palet at consulintel.es Fri Jul 23 04:13:22 2010 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 23 Jul 2010 15:13:22 +0600 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <9C3B3385-0201-4E80-B441-804BB39EE1D0@marcoh.net> Message-ID: Well said. One more reason is transition mechanisms. For example, 6to4, TBs, manual tunnels, those are just a few examples, which use/provide /48. We have today many customers using /48, which have already their own internal addressing plans, or manual subnets configured internally. Are you going to tell them now that you provide a dual stack service with less subnets and they need to remake their addressing plan and/or renumber ? Those customers are smart, they will look to your competitors and look for a better provider. No economical reason to provide "less" subnets to customers, many economical reasons to provide them as many subnets as you can, avoid wasting time, renumbering, etc., and being able to provide more applications that may be easily deployed in different subnets. Yes, 16 bits subnets are a lot, but time cost more, announcing more prefixes per customer is even more expensive, even for residential customers that will use more and more applications and services requiring them. You don't want to manage again a more complex network specially if as Tony Hain calculated some time ago, providing /48 for every possible customer in the Earth will mean IPv6 will last 480 years. Do you really believe we will keep using IP (not talking about v4 or v6) as we know it today ? I bet in less than 100 years we will need, for other reasons different than the need for more addresses, a new protocol. Why we insist in making things complicated againg, I guess because humans like complicated life ! Regards, Jordi > From: Marco Hogewoning > Reply-To: > Date: Fri, 23 Jul 2010 10:06:43 +0200 > To: Matthew Walster > Cc: nanog list > Subject: Re: Addressing plan exercise for our IPv6 course > > > On 23 jul 2010, at 01:33, Matthew Walster wrote: > >> On 22 July 2010 14:11, Alex Band wrote: >>> There are more options, but these two are the most convenient weighing all >>> the up and downsides. Does anyone disagree? >> >> I never saw the point of assigning a /48 to a DSL customer. Surely the >> better idea would be to assign your bog standard residential DSL >> customer a /64 and assign them a /56 or /48 if they request it, routed >> to an IP of their choosing. > > > /64 is too small, especially when sensornetworks take off you probably want > multple ranges. > > In fact the CPE we use at the moment already takes a /64 for internals like > voip clients, dns resolver and management interfaces and assigns the second > one to the LAN. Optionally you want people to create a seperate zone for wifi > guests (it supports dual band radio). So in reallife you already need more > then one. > > Giving the way reverse DNS is designed I wouldn't recommend people to leave > the 4 bit boundry on which it is organised unless you want to make your life > miserable and complicated. So that would make it a /60 at minimum. > > So why /48 and not /56 or /60 ? We'll first of all we, and I mean the > collective group of people that tries to run the internet (which includes you > reading this), screwed it up in marketing. > > First of all we keep telling everybody there are so many addresses we will > never run out of them. Now of course this is BS and we all know that someday > we find 128 bits wasn't enough. By that time we probably realise that the > current almost classfull system wasn't a smart choice and we introduce CIDR > again to save our day. > > Which brings me to the second point and that is introducing semi fixed borders > like /64 for a subnet and the original wording 'if you think they ever need > more then one subnet, assign a /48'. That amazingly got stuck in peoples head > like classfull once did. I still have customers asking for a C-class and some > of them are even born in the CIDR era. As far as the customer base understand > what IPv6 is, all they ever hear is 'I'll get a /48' even in those cases where > you say something else. We told them NATs are going away and we told them we > had so many addresses there wasn't a problem at all. /64 subnet, /48 when you > need more did the rest. > > So assume I assign the mass that is unaware a /64, do I reserve some bits for > future growth? I'll bet you when IPv6 does hit the market somebody will find > an application for it and requires a second subnet (sensors for instance). > What do I do when somebody requests this, assign a secondary /64 or renumber ? > So maybe I should reserve a /60, but is that different from assigning it > directly ? Takes up space anyway. > > So now I assign a /60, unfortunately the /48 is stuck in people's head so I > get people complaining about this. This is amplified by the fact that early > adopters, even the ones with tunnels, got a /48. Remember those folks who got > a /8 back in the days, did you ever thought 'what if I would have been there' > ? So I get into discussions with customers and that has a cost, I at least > have to pay for the guy who answers the phone on our end. Next to that, there > is that risk that I lose business because the shop across the road does offer > /56 or even /48. > > Which brings me into the economics, we are in a hurry. We need to deploy and > we need to deploy yesterday. In fact if you are not running IPv6 by now, you > are too late. So I have the choice of creating a really complicated deployment > scheme in which I can assign variable subnet lenghts to customers without > breaking aggregation and without annoying them with renumbering. > One-size-fits-all makes life easy and saves an huge pile of money and not only > money but it saves time, time I need, beacuse we are already a bit late. > > In short, why a /48 'Because we can!'. We had about 15 years to design a > proper scheme, we failed. Now we can discuss a redesign, but then we need to > squeeze another 10 years out of IPv4. > > MarcoH > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From lists at quux.de Fri Jul 23 04:50:02 2010 From: lists at quux.de (Jens Link) Date: Fri, 23 Jul 2010 11:50:02 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <8AC1FEFF-C2A5-4063-BB26-8F11BB1985EE@delong.com> (Owen DeLong's message of "Thu\, 22 Jul 2010 22\:13\:10 -0700") References: <8AC1FEFF-C2A5-4063-BB26-8F11BB1985EE@delong.com> Message-ID: <87hbjqa5o5.fsf@oban.berlin.quux.de> Owen DeLong writes: > In all reality: > > 1. NAT has nothing to do with security. Stateful inspection provides > security, NAT just mangles addresses. You know that, I know that and (hopefully) all people on this list know that. But NAT == security was and still is sold by many people. > Most customers don't know or care what NAT is and wouldn't know the > difference between a NAT firewall and a stateful inspection firewall. I Agree. But there are also many people who want to believe in NAT as security feature. After one of my talks about IPv6 the firewall admins of a company said something like: "So we can't use NAT as an excuse anymore and have to configure firewall rules? We don't want this." cheers Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From nick at foobar.org Fri Jul 23 05:18:39 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 23 Jul 2010 11:18:39 +0100 Subject: Looking for comments In-Reply-To: <20100723094721.61f6ed4d@opy.nosense.org> References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> <4C48BA4F.6030708@gmail.com> <4C48CCD2.5000308@foobar.org> <20100723094721.61f6ed4d@opy.nosense.org> Message-ID: <4C496C7F.9040005@foobar.org> On 23/07/2010 01:17, Mark Smith wrote: > Does this qualify? What the customer sees is delivered over IPv6, > unlike the CPE management problem, where the ISP is the "IPv6 customer". > > "IPv6: The Future of IPTV? In Japan it isn't the future, it's now." > http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm I understand that there are several networks doing this; the STB - like the CPE modem - is managed by the service provider and the customer has no management / control access over it. The customer stays on ipv4 for their regular access product. Someone offline pointed me at the Google IPv6 Implementors 2010 conference, at which: > https://sites.google.com/site/ipv6implementors/2010/agenda/13_Byrne_T-Mobile_IPv6GoogleMeeting.pdf?attredirects=0&d=1 This is genuinely interesting. Nick From avitkovsky at emea.att.com Fri Jul 23 06:36:06 2010 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Fri, 23 Jul 2010 13:36:06 +0200 Subject: "vpn exchange point" In-Reply-To: References: Message-ID: Yes please I believe that what Michael have mentioned by the mpls NNI is actually the RFC 2547bis Option 10A And yes please as Chris mentioned this Option 10A is used mainly between two different administrative domains (ISPs) because of the lack of trust and maybe a sort of configuration simplicity (known CE-to-PE setup)-despite of it's obvious drawbacks like the lack of scalability (because for each vpn there need's to be a sub-interface configured and the ASBRs need to hold all the vpn routes) The other drawback is not optimal routing across the AS regions/domains Yes the PE has an optimal route towards the ASBR -but is that ASBR on the shortest path towards the destination PE/CE -the PE can't tell because it's missing the whole picture The other two RFC 2547bis options: Option 10B and 10C requires some level of trust between the autonomous systems and thus are rarely used between different ISPs -though these options found a great use in ISPs with more than one AS# -where advertising the ip addresses of PEs and Inter-AS-RRs into the different AS (as in option 10C)-is not a concern Both Option 10B and 10C provides end-to-end LSP necessary for mpls services (like TE,VPLS,..)-in addition to that Option 10C provides optimal routing across the AS domains -these might be couple of business reasons for opt 10B and 10C The other way to extend the reach of an ISP is the Carrier supporting Carrier model but that's a whole another playground :) Now back to my initial assumptions Should a provider have multiple AS numbers (for whatever reason: supporting different regions, fusing with other ISPs) -assuming common control over all the ASes -that provider's best choice would be to use Option 10C for the reasons mentioned above However the Option 10C has one drawback -it does not scale well should the number of AS regions increase Should we want the full view from all the PE routers -we would need a full mesh between the Inter-AS-RRs -which are exchanging the vpn routes between AS domains and forwarding them to the PEs in their local AS afterwards -we could mitigate the issue of full mesh requirement between RRs by using the RR-Clusters and just do a full mesh between the clusters (which I didn't lab yet and I'm not sure how the cluster configuration would interact with the vpnv4 RRs) Or the other solution is to introduce another level of RRs into the picture of full mesh between the Inter-AS-RRs In this solution the Inter-AS-RRs would not peer with each other in a full mesh fashion -but they would rather peer with the higher level RRs "Global RRs" avoiding the need for a full mesh (I didn't lab this one either so I'm not sure how it will work out) These higher level RRs "Global RRs" would be sort of a "mpls-vpn-IXPs" As with well known IXPs they are deployed where a lot of ASes needs to exchange routing information and traffic -with important difference: This "mpls-vpn-IXPs" would not be passing any actual traffic -just the routing and vpn information Remember these are just RRs and do not need to or should not be on the forwarding path -we are only talking control plane here And I'm assuming the AS regions are interconnected via links between ASBRs in each particular AS -with no global visibility (data plane) From matthew at matthew.at Fri Jul 23 09:04:17 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 23 Jul 2010 07:04:17 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <249A55AC-0EB0-4D91-91F0-520FA1EAFD8C@delong.com> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <4C48E461.9090002@matthew.at> <249A55AC-0EB0-4D91-91F0-520FA1EAFD8C@delong.com> Message-ID: <4C49A161.3020109@matthew.at> Owen DeLong wrote: > > Well, wouldn't it be better if the provider simply issued enough space to > make NAT66 unnecessary? > > The thing is, IPv6 is 128 bits of address space, so a /64 for your home *really* should be enough to have >1 machine online at a time. It'll be a lot easier to change the subnetting rules inside small networks, and we all know that DHCPv6 is far superior to SAA for almost all cases, but especially home users who need things like their DNS entries set up for them by their "router". Matthew Kaufman From jordi.palet at consulintel.es Fri Jul 23 10:14:13 2010 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 23 Jul 2010 21:14:13 +0600 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C49A161.3020109@matthew.at> Message-ID: And then next you can say ok, so /32 bits is big enough for your home, so let's change it again, kill autoconfiguration, ask existing IPv6 users to redo their addressing plans, renumber, etc., and use all the rest of the bits for routing ? And so on, of course, where is the limit ? You should propose this to 6man at the IETF. You're not getting it. Autoconfiguration is a very good feature. More bits for the user to subnet means more business for smart ISPs who don't want to sell addresses but instead services and applications much more easier to deploy thanks to a uniform /48 ways to address all end sites. Regards, Jordi > From: Matthew Kaufman > Reply-To: > Date: Fri, 23 Jul 2010 07:04:17 -0700 > To: Owen DeLong > Cc: nanog list > Subject: Re: Addressing plan exercise for our IPv6 course > > Owen DeLong wrote: >> >> Well, wouldn't it be better if the provider simply issued enough space to >> make NAT66 unnecessary? >> >> > The thing is, IPv6 is 128 bits of address space, so a /64 for your home > *really* should be enough to have >1 machine online at a time. > > It'll be a lot easier to change the subnetting rules inside small > networks, and we all know that DHCPv6 is far superior to SAA for almost > all cases, but especially home users who need things like their DNS > entries set up for them by their "router". > > Matthew Kaufman > ********************************************** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From matthew at matthew.at Fri Jul 23 09:22:53 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 23 Jul 2010 07:22:53 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: <4C49A5BD.7060908@matthew.at> JORDI PALET MARTINEZ wrote: > And then next you can say ok, so /32 bits is big enough for your home, so > let's change it again, kill autoconfiguration, ask existing IPv6 users to > redo their addressing plans, renumber, etc., and use all the rest of the > bits for routing ? > I *really* don't understand why a /32 isn't big enough for a home. Even if you insist on SAA for getting the addresses. How many IPv6 devices is the guy going to plug in / attach wirelessly anyway? > And so on, of course, where is the limit ? You should propose this to 6man > at the IETF. > The same IETF that until just a few months ago believed that DCCP and SCTP would be wildly successful as new IP protocols because NATs don't matter? > You're not getting it. Autoconfiguration is a very good feature. No, no it isn't. It goes on the list of "interesting ideas for IPv6 that were good enough to be implemented, and refined (in this case as DHCP), for IPv4". Insisting on SAA is basically saying "well, you know all those things we learned when we deployed DHCP... lets go ahead and forget them and pretend that home machine OS vendors *and* IT departments are wrong. > More bits > for the user to subnet means more business for smart ISPs who don't want to > sell addresses but instead services and applications much more easier to > deploy thanks to a uniform /48 ways to address all end sites. > I fail to see how a household, even a really big one, is going to attach more bandwidth-consuming devices (which I presume is how the ISP does more business) to a link with a /48 on it vs a link with a /64 on it. A /64 allows more machines in your house than today's entire Internet has connected. Unless you have a new plan for electric power delivery to the home, there's no need to go beyond that. Matthew Kaufman From jordi.palet at consulintel.es Fri Jul 23 11:07:01 2010 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 23 Jul 2010 22:07:01 +0600 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C49A5BD.7060908@matthew.at> Message-ID: It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. The ISP "new" business is not just about more bandwidth but also about offering new services, which they can charge for. Those services are very difficult to deploy in NATed scenarios such as the one that we have today with IPv4. And I'm not saying to forget about what we have learn with DHCP, in fact DHCPv6 has many new and good features, but for many reasons, autonconfiguration is good enough, and much more simple. Regards, Jordi > From: Matthew Kaufman > Reply-To: > Date: Fri, 23 Jul 2010 07:22:53 -0700 > To: Jordi Palet Mart?nez > Cc: > Subject: Re: Addressing plan exercise for our IPv6 course > > JORDI PALET MARTINEZ wrote: >> And then next you can say ok, so /32 bits is big enough for your home, so >> let's change it again, kill autoconfiguration, ask existing IPv6 users to >> redo their addressing plans, renumber, etc., and use all the rest of the >> bits for routing ? >> > I *really* don't understand why a /32 isn't big enough for a home. Even > if you insist on SAA for getting the addresses. How many IPv6 devices is > the guy going to plug in / attach wirelessly anyway? >> And so on, of course, where is the limit ? You should propose this to 6man >> at the IETF. >> > The same IETF that until just a few months ago believed that DCCP and > SCTP would be wildly successful as new IP protocols because NATs don't > matter? >> You're not getting it. Autoconfiguration is a very good feature. > No, no it isn't. It goes on the list of "interesting ideas for IPv6 that > were good enough to be implemented, and refined (in this case as DHCP), > for IPv4". Insisting on SAA is basically saying "well, you know all > those things we learned when we deployed DHCP... lets go ahead and > forget them and pretend that home machine OS vendors *and* IT > departments are wrong. >> More bits >> for the user to subnet means more business for smart ISPs who don't want to >> sell addresses but instead services and applications much more easier to >> deploy thanks to a uniform /48 ways to address all end sites. >> > I fail to see how a household, even a really big one, is going to attach > more bandwidth-consuming devices (which I presume is how the ISP does > more business) to a link with a /48 on it vs a link with a /64 on it. A > /64 allows more machines in your house than today's entire Internet has > connected. Unless you have a new plan for electric power delivery to the > home, there's no need to go beyond that. > > Matthew Kaufman > ********************************************** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From andre.edwards at gmail.com Fri Jul 23 10:09:08 2010 From: andre.edwards at gmail.com (=?ISO-8859-1?Q?Andr=E9_Edwards?=) Date: Fri, 23 Jul 2010 11:09:08 -0400 Subject: Caribbean Network Operators Group Inaugural Meeting in St Maarten August 15th to 20th 2010 Message-ID: Invitation to CARIBNOG 1 -------------------------------------- August 15th ? 20th, 2010 Westin Hotel & Resort 144 Oyster Pond Road St Maarten -------------------------------------- Dear colleagues, members of the Lacnic community. The Caribbean Network Operators Group (CARIBNOG) has the pleasure of announcing and inviting you to participate in the first Regional CaribNOG meeting, CARIBNOG 1, from August 15th ? 20th, 2010. The event will be held at the Westin Hotel and Resort in the beautiful island of St. Maarten during the Inaugural St. Maarten?s ICT Week which is being hosted by the Government of St. Maarten and the Caribbean Telecommunications Union (CTU). The Caribbean Network Operators Group (CaribNOG) is a community of Network Operators dedicated to exchanging technical information and experiences related to the management of IP networks in the Caribbean region. CaribNOG conferences provide a forum for the coordination and dissemination of technical information related to networking technologies, research and operational practices. The meetings are informal, with an emphasis on practical solutions, training and insight relevant to the region. In St. Maarten, expert speakers from the regional and international technical community will be conducting hands-on workshops, in-depth tutorials and presentations on the following topics: ? VoIP: VOIP workshop ? Deploying secure small and medium Scale VoIP solutions ? LINUX: Configuring and Securing LAMP, creating a secure LAMP application, IP Services and Security ? ROUTING: Basics; introduction to OSPF, BGP, VoIP and SIP ? CSIRT: Developing a Network Security and Incident Response Team. You are welcome to join us in St Maarten for this inaugural meeting. More detailed information on the event and its program, accommodation, registration, and general information will soon be available on CARIBNOG's website: www.caribnog.org Sincerely, Andre Edwards CARIBNOG 1 Program Committee From tglassey at earthlink.net Fri Jul 23 10:12:41 2010 From: tglassey at earthlink.net (todd glassey) Date: Fri, 23 Jul 2010 08:12:41 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: <4C49B169.3040701@earthlink.net> On 7/23/2010 9:07 AM, JORDI PALET MARTINEZ wrote: > It is not about how many devices, it is about how many subnets, because you > may want to keep them isolated, for many reasons. > > It is not just about devices consuming lots of bandwidth, it is also about > many small sensors, actuators and so. > > The ISP "new" business is not just about more bandwidth but also about > offering new services, which they can charge for. Those services are very > difficult to deploy in NATed scenarios such as the one that we have today > with IPv4. > > And I'm not saying to forget about what we have learn with DHCP, in fact > DHCPv6 has many new and good features, but for many reasons, > autonconfiguration is good enough, and much more simple. > > Regards, > Jordi > Jordi - the real issues are in guaranteed delivery of certain evidence-grade services and what it takes to offer those. Todd > > >> From: Matthew Kaufman >> Reply-To: >> Date: Fri, 23 Jul 2010 07:22:53 -0700 >> To: Jordi Palet Mart?nez >> Cc: >> Subject: Re: Addressing plan exercise for our IPv6 course >> >> JORDI PALET MARTINEZ wrote: >>> And then next you can say ok, so /32 bits is big enough for your home, so >>> let's change it again, kill autoconfiguration, ask existing IPv6 users to >>> redo their addressing plans, renumber, etc., and use all the rest of the >>> bits for routing ? >>> >> I *really* don't understand why a /32 isn't big enough for a home. Even >> if you insist on SAA for getting the addresses. How many IPv6 devices is >> the guy going to plug in / attach wirelessly anyway? >>> And so on, of course, where is the limit ? You should propose this to 6man >>> at the IETF. >>> >> The same IETF that until just a few months ago believed that DCCP and >> SCTP would be wildly successful as new IP protocols because NATs don't >> matter? >>> You're not getting it. Autoconfiguration is a very good feature. >> No, no it isn't. It goes on the list of "interesting ideas for IPv6 that >> were good enough to be implemented, and refined (in this case as DHCP), >> for IPv4". Insisting on SAA is basically saying "well, you know all >> those things we learned when we deployed DHCP... lets go ahead and >> forget them and pretend that home machine OS vendors *and* IT >> departments are wrong. >>> More bits >>> for the user to subnet means more business for smart ISPs who don't want to >>> sell addresses but instead services and applications much more easier to >>> deploy thanks to a uniform /48 ways to address all end sites. >>> >> I fail to see how a household, even a really big one, is going to attach >> more bandwidth-consuming devices (which I presume is how the ISP does >> more business) to a link with a /48 on it vs a link with a /64 on it. A >> /64 allows more machines in your house than today's entire Internet has >> connected. Unless you have a new plan for electric power delivery to the >> home, there's no need to go beyond that. >> >> Matthew Kaufman >> > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > > From david.freedman at uk.clara.net Fri Jul 23 10:20:56 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 23 Jul 2010 16:20:56 +0100 Subject: "vpn exchange point" In-Reply-To: References: Message-ID: <4C49B358.6050603@uk.clara.net> If you are going to go multi-VLAN data plane (as opposed to multi-label) then 10A will cause you scaling issues as you'll need multiple BGP peers (or static routing), I'd prefer to use http://tools.ietf.org/html/draft-kulmala-l3vpn-interas-option-d-02 which already has implementations, i.e (albeit differently named) http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ias_optab.html Dave. From david.freedman at uk.clara.net Fri Jul 23 10:20:56 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 23 Jul 2010 16:20:56 +0100 Subject: "vpn exchange point" In-Reply-To: References: Message-ID: <4C49B358.6050603@uk.clara.net> If you are going to go multi-VLAN data plane (as opposed to multi-label) then 10A will cause you scaling issues as you'll need multiple BGP peers (or static routing), I'd prefer to use http://tools.ietf.org/html/draft-kulmala-l3vpn-interas-option-d-02 which already has implementations, i.e (albeit differently named) http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ias_optab.html Dave. From owen at delong.com Fri Jul 23 10:33:19 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 23 Jul 2010 08:33:19 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <87hbjqa5o5.fsf@oban.berlin.quux.de> References: <8AC1FEFF-C2A5-4063-BB26-8F11BB1985EE@delong.com> <87hbjqa5o5.fsf@oban.berlin.quux.de> Message-ID: <38E7A759-F062-4F0B-903F-29B4C1F66DF7@delong.com> On Jul 23, 2010, at 2:50 AM, Jens Link wrote: > Owen DeLong writes: > >> In all reality: >> >> 1. NAT has nothing to do with security. Stateful inspection provides >> security, NAT just mangles addresses. > > You know that, I know that and (hopefully) all people on this list know > that. But NAT == security was and still is sold by many people. > So is snake oil. >> Most customers don't know or care what NAT is and wouldn't know the >> difference between a NAT firewall and a stateful inspection firewall. > > I Agree. But there are also many people who want to believe in NAT as > security feature. > > After one of my talks about IPv6 the firewall admins of a company said > something like: "So we can't use NAT as an excuse anymore and have to > configure firewall rules? We don't want this." > So how did you answer him? The correct answer is "No, you don't have to configure rules, you just need one rule supplied by default which denies anything that doesn't have a corresponding outbound entry in the state table and it works just like NAT without the address mangling". In my experience, other than a small handful of religious zealots, that explanation is sufficient to get the point across to most such admins. Owen From sthaug at nethelp.no Fri Jul 23 10:53:33 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 23 Jul 2010 17:53:33 +0200 (CEST) Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <4C49A5BD.7060908@matthew.at> Message-ID: <20100723.175333.74690943.sthaug@nethelp.no> > It is not about how many devices, it is about how many subnets, because you > may want to keep them isolated, for many reasons. > > It is not just about devices consuming lots of bandwidth, it is also about > many small sensors, actuators and so. I have no problems with giving the customer several subnets. /56 is just fine for that. I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer. So we end up with /56 for residential users. > And I'm not saying to forget about what we have learn with DHCP, in > fact DHCPv6 has many new and good features, but for many reasons, > autonconfiguration is good enough, and much more simple. For our scenarios DHCPv6 is needed, autoconfiguration is *not* good enough. It seems quite likely that in many cases the CPE will use the /56 it gets from us (via DHCPv6 PD) as basis for autoconfiguration on the LAN side - and that's just fine and dandy. [I see no point in repeating the arguments for why autoconfiguration is not good enough - this has been beaten to death, repeatedly, on lots of IPv6 lists.] Steinar Haug, Nethelp consulting, sthaug at nethelp.no From bill at herrin.us Fri Jul 23 11:37:20 2010 From: bill at herrin.us (William Herrin) Date: Fri, 23 Jul 2010 06:37:20 -1000 Subject: Looking for comments In-Reply-To: <4C48BA4F.6030708@gmail.com> References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> <4C48BA4F.6030708@gmail.com> Message-ID: On Thu, Jul 22, 2010 at 11:38 AM, Brian E Carpenter wrote: > However, the fact is that various *extremely* large operators find themselves > more or less forced into these scenarios by IPv4 exhaustion. Hi Brian, Respectfully, anyone betting on what the ISPs will be "forced" to do is betting to lose. The operators, large and small, have a number of options for dealing with free pool exhaustion. NAT, aggressive address recovery, transfer markets, dual stack of course, and others. That having been said, I don't want to stray from the point of your document -- offering practical advice to folks for whom IPv6 plays a role in their plans for dealing with free pool depletion. I respectfully submit that a silent assumption that ISPs will be forced kicking and screaming to adopt one of the strategies you've outlined does not make for a healthy foundation for the document. Assume they'll have other options than IPv6, dual stack or otherwise. Assume they'll abandon dual stack for the other options if dual stack proves too challenging. Then figure out the mitigations and go in to technical detail citing examples. > I think it's > more reasonable to describe solutions for them than to rule their > problem out of order. In that, you are surely correct. But frankly, having read 4.3 I have a hard time taking it seriously as an early-stage IPv6 transition mechanism. It reads to me like pie in the sky. I can see 4.4 as a late stage mechanism when we're slowly dismantling our IPv4 networks... I can also see it as an under-the-hood mechanism for deploying new integrated technologies (utility meters, IPTV, etc). As a replacement for general-purpose IPv4 access in the stages before Ipv6 is ubiquitous? I welcome you to prove me wrong, but sitting here looking forward it just doesn't seem credible to me. If I was writing your document, I think I'd describe it that way: potentially valuable for deployments of new technologies such as [list] so that their roll out and operation doesn't get caught up in the expensive free pool exhaustion issues, but unlikely to be acceptable for general purpose Internet access. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From avitkovsky at emea.att.com Fri Jul 23 11:45:07 2010 From: avitkovsky at emea.att.com (Vitkovsky, Adam) Date: Fri, 23 Jul 2010 18:45:07 +0200 Subject: "vpn exchange point" In-Reply-To: <4C49B358.6050603@uk.clara.net> References: <4C49B358.6050603@uk.clara.net> Message-ID: Yes please -option d also known as option AB -it's the same as option b with addition of VRFs on the ASBRs -it might as well be viewed as a natural step between opt a and opt b -opt ab offers the same great control over the routes advertised between ASes as opt a -though provides for better scalability by introducing mp-ebgp session between ASBRs By removing the VRFs from the ASBRs and turning off the default mp-ibgp behavior -option b doesn't suffer from some of the inherent drawbacks of opt ab like: Increased memory demands because ASBRs have to store routes in the per-vrf RIBs in addition to mp-bgp database Opt b has also streamlined the forwarding process by omitting the additional per-vrf ip lookup on the ASBRs The tradeoff is however -less control over the routes advertised between the AS domains One advantage that comes naturally with opt ab is -you don't need to worry about the import/export RTs not matching in two different ASes and configuring RT rewrites on ASBRs -opt ab will take care of that for you adam -----Original Message----- From: David Freedman [mailto:david.freedman at uk.clara.net] Sent: Friday, July 23, 2010 5:21 PM To: Vitkovsky, Adam Cc: Christopher Morrow; Michael Dillon; nanog at nanog.org Subject: Re: "vpn exchange point" If you are going to go multi-VLAN data plane (as opposed to multi-label) then 10A will cause you scaling issues as you'll need multiple BGP peers (or static routing), I'd prefer to use http://tools.ietf.org/html/draft-kulmala-l3vpn-interas-option-d-02 which already has implementations, i.e (albeit differently named) http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_vpn_ias_optab.html Dave. From kenny.sallee at gmail.com Fri Jul 23 12:07:43 2010 From: kenny.sallee at gmail.com (Kenny Sallee) Date: Fri, 23 Jul 2010 10:07:43 -0700 Subject: "vpn exchange point" In-Reply-To: References: <4C49B358.6050603@uk.clara.net> Message-ID: On Fri, Jul 23, 2010 at 9:45 AM, Vitkovsky, Adam wrote: > > Yes please -option d also known as option AB > -it's the same as option b with addition of VRFs on the ASBRs > -it might as well be viewed as a natural step between opt a and opt b > > -opt ab offers the same great control over the routes advertised between > ASes as opt a -though provides for better scalability by introducing mp-ebgp > session between ASBRs > > By removing the VRFs from the ASBRs and turning off the default mp-ibgp > behavior -option b doesn't suffer from some of the inherent drawbacks of opt > ab like: > Increased memory demands because ASBRs have to store routes in the per-vrf > RIBs in addition to mp-bgp database > Opt b has also streamlined the forwarding process by omitting the > additional per-vrf ip lookup on the ASBRs > The tradeoff is however -less control over the routes advertised between > the AS domains > > One advantage that comes naturally with opt ab is -you don't need to worry > about the import/export RTs not matching in two different ASes and > configuring RT rewrites on ASBRs -opt ab will take care of that for you > > > FWIW - I tried to get a couple of larger carriers in the states to do option b with my company (we are an ASP) - where we were the other 'ISP/AS'. Doing so would have allowed me to extend the VRF / VPN-ipV4 addresses to my core and map those to a VLAN interface in the same VRF (thus allowing all of our customers to maintain their own IP ranges instead of us handing out non-overlapping ranges). None of them would do it for security / manageability reasons. The solution today is back to back DS3 with frame encapsulation and a gazillion sub-interfaces (each sub-interface is in a VRF - and each VRF can have a VLAN interface for L2 and L3 autonomy). It solves my problem - but the config is a little complicated. So for me - it'd be nice if the carriers played in the Multi-AS backbone arena a little more. I could loose frame encapsulation and the management/scalability issues that goes along with a ton of sub-if's. It'd be easier on their provisioning teams as well. Not to mention a simplified QoS config etc... Another practical use for multi-as MPLS VPN options: if there were 2 providers that used RFC 4364 Multi-AS options - I could provide carrier / circuit redundancy into my data centers. Today I can only do that via a single MPLS provider and hope the core engineers of that carrier don't make mistakes...If I could have an MPLS circuit dropped from 2 different providers that provide access between our customers and our data centers - there'd be a lot of value there. I'm sure a lot of enterprises using MPLS would be interested. Kenny From positivelyoptimistic at gmail.com Fri Jul 23 12:11:06 2010 From: positivelyoptimistic at gmail.com (Positively Optimistic) Date: Fri, 23 Jul 2010 13:11:06 -0400 Subject: IPv4 Exhaustion... Message-ID: How do ISPs handle RIAA notices when NATTING customers.. ? We have several customers that don't require public address space that could be moved to private.. We're reluctant to make the move due to legal liabilities.. From khatfield at socllc.net Fri Jul 23 12:36:18 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Fri, 23 Jul 2010 17:36:18 +0000 Subject: IPv4 Exhaustion... Message-ID: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> Hello, From our past experience this can be accomplished without issue as long as you have good log records and tracking in place. Ensure you have long-term retention for the logs to cover yourself. Many ISP's are moving to this sort of environment simply due to the reasoning stated. -Kevin ------Original Message------ From: Positively Optimistic To: nanog at nanog.org Subject: IPv4 Exhaustion... Sent: Jul 23, 2010 12:11 PM How do ISPs handle RIAA notices when NATTING customers.. ? We have several customers that don't require public address space that could be moved to private.. We're reluctant to make the move due to legal liabilities.. From dave at mvn.net Fri Jul 23 12:45:02 2010 From: dave at mvn.net (David E. Smith) Date: Fri, 23 Jul 2010 12:45:02 -0500 Subject: IPv4 Exhaustion... In-Reply-To: References: Message-ID: On Fri, Jul 23, 2010 at 12:11, Positively Optimistic < positivelyoptimistic at gmail.com> wrote: > How do ISPs handle RIAA notices when NATTING customers.. ? We have > several customers that don't require public address space that could be > moved to private.. We're reluctant to make the move due to legal > liabilities.. > On a related note, what's the best way to handle RIAA/MPAA requests for end-users that intentionally run "open" APs, especially when the notices don't show up for days or weeks (by which time the offender, a hotel guest, has long since moved on)? David Smith MVN.net From nick at brevardwireless.com Fri Jul 23 12:54:20 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Fri, 23 Jul 2010 13:54:20 -0400 Subject: IPv4 Exhaustion... Message-ID: <27ddb44$33139d32$5a0c27a9$@com> We get them pretty often. Always the same email with a different movie and IP. If its one of our hotspots or "open" AP's. We just ignore it for the most part. If its a res/commercial customer we contact them and let them know someone is watching. Never has gone past the cookie cutter email we get from media sentry. Nick Olsen Network Operations (321) 205-1100 x106 ---------------------------------------- From: "David E. Smith" Sent: Friday, July 23, 2010 1:46 PM To: nanog at nanog.org Subject: Re: IPv4 Exhaustion... On Fri, Jul 23, 2010 at 12:11, Positively Optimistic < positivelyoptimistic at gmail.com> wrote: > How do ISPs handle RIAA notices when NATTING customers.. ? We have > several customers that don't require public address space that could be > moved to private.. We're reluctant to make the move due to legal > liabilities.. > On a related note, what's the best way to handle RIAA/MPAA requests for end-users that intentionally run "open" APs, especially when the notices don't show up for days or weeks (by which time the offender, a hotel guest, has long since moved on)? David Smith MVN.net From smb at cs.columbia.edu Fri Jul 23 12:59:41 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 23 Jul 2010 13:59:41 -0400 Subject: IPv4 Exhaustion... In-Reply-To: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> Message-ID: <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> On Jul 23, 2010, at 1:36 18PM, khatfield at socllc.net wrote: > Hello, > From our past experience this can be accomplished without issue as long as you have good log records and tracking in place. Do the complaints you receive include port numbers? Do you log the translation for every TCP connection and UDP exchange? I don't see how logs would work without that. > Ensure you have long-term retention for the logs to cover yourself. I'd consult a lawyer on that -- are you required to have such logs? Per the above, I'm not convinced that it's technically feasible to keep such logs for an operation of any size, nor do I think that most complaints have the right information (to wit, port numbers) to use them if they do exist. --Steve Bellovin, http://www.cs.columbia.edu/~smb From cscora at apnic.net Fri Jul 23 13:11:10 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 24 Jul 2010 04:11:10 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201007231811.o6NIBA5Q003060@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 24 Jul, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 326536 Prefixes after maximum aggregation: 150103 Deaggregation factor: 2.18 Unique aggregates announced to Internet: 159244 Total ASes present in the Internet Routing Table: 34425 Prefixes per ASN: 9.49 Origin-only ASes present in the Internet Routing Table: 29885 Origin ASes announcing only one prefix: 14463 Transit ASes present in the Internet Routing Table: 4540 Transit-only ASes present in the Internet Routing Table: 105 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 26 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 304 Unregistered ASNs in the Routing Table: 118 Number of 32-bit ASNs allocated by the RIRs: 701 Prefixes from 32-bit ASNs in the Routing Table: 851 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 162 Number of addresses announced to Internet: 2277322752 Equivalent to 135 /8s, 189 /16s and 48 /24s Percentage of available address space announced: 61.4 Percentage of allocated address space announced: 66.2 Percentage of available address space allocated: 92.8 Percentage of address space in use by end-sites: 83.9 Total number of prefixes smaller than registry allocations: 155564 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 79446 Total APNIC prefixes after maximum aggregation: 27173 APNIC Deaggregation factor: 2.92 Prefixes being announced from the APNIC address blocks: 76327 Unique aggregates announced from the APNIC address blocks: 33533 APNIC Region origin ASes present in the Internet Routing Table: 4123 APNIC Prefixes per ASN: 18.51 APNIC Region origin ASes announcing only one prefix: 1135 APNIC Region transit ASes present in the Internet Routing Table: 637 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 532226080 Equivalent to 31 /8s, 185 /16s and 32 /24s Percentage of available APNIC address space announced: 79.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 134651 Total ARIN prefixes after maximum aggregation: 69494 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 107489 Unique aggregates announced from the ARIN address blocks: 42017 ARIN Region origin ASes present in the Internet Routing Table: 13802 ARIN Prefixes per ASN: 7.79 ARIN Region origin ASes announcing only one prefix: 5273 ARIN Region transit ASes present in the Internet Routing Table: 1358 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 729830688 Equivalent to 43 /8s, 128 /16s and 85 /24s Percentage of available ARIN address space announced: 62.1 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 75032 Total RIPE prefixes after maximum aggregation: 43448 RIPE Deaggregation factor: 1.73 Prefixes being announced from the RIPE address blocks: 68199 Unique aggregates announced from the RIPE address blocks: 44519 RIPE Region origin ASes present in the Internet Routing Table: 14632 RIPE Prefixes per ASN: 4.66 RIPE Region origin ASes announcing only one prefix: 7521 RIPE Region transit ASes present in the Internet Routing Table: 2185 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 433475968 Equivalent to 25 /8s, 214 /16s and 81 /24s Percentage of available RIPE address space announced: 76.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 29026 Total LACNIC prefixes after maximum aggregation: 6973 LACNIC Deaggregation factor: 4.16 Prefixes being announced from the LACNIC address blocks: 27538 Unique aggregates announced from the LACNIC address blocks: 14474 LACNIC Region origin ASes present in the Internet Routing Table: 1311 LACNIC Prefixes per ASN: 21.01 LACNIC Region origin ASes announcing only one prefix: 414 LACNIC Region transit ASes present in the Internet Routing Table: 232 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 26 Number of LACNIC addresses announced to Internet: 75723840 Equivalent to 4 /8s, 131 /16s and 116 /24s Percentage of available LACNIC address space announced: 56.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7279 Total AfriNIC prefixes after maximum aggregation: 1870 AfriNIC Deaggregation factor: 3.89 Prefixes being announced from the AfriNIC address blocks: 5589 Unique aggregates announced from the AfriNIC address blocks: 1640 AfriNIC Region origin ASes present in the Internet Routing Table: 383 AfriNIC Prefixes per ASN: 14.59 AfriNIC Region origin ASes announcing only one prefix: 120 AfriNIC Region transit ASes present in the Internet Routing Table: 84 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 19892224 Equivalent to 1 /8s, 47 /16s and 136 /24s Percentage of available AfriNIC address space announced: 59.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1857 8409 489 Korea Telecom (KIX) 4755 1474 298 160 TATA Communications formerly 7545 1361 232 104 TPG Internet Pty Ltd 17488 1334 147 128 Hathway IP Over Cable Interne 17974 1179 286 55 PT TELEKOMUNIKASI INDONESIA 9583 1002 74 486 Sify Limited 24560 985 304 179 Bharti Airtel Ltd., Telemedia 4808 827 1575 219 CNCGROUP IP network: China169 9829 813 685 32 BSNL National Internet Backbo 4134 783 21740 411 CHINANET-BACKBONE Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3889 3718 287 bellsouth.net, inc. 4323 2723 1112 393 Time Warner Telecom 19262 1942 4567 278 Verizon Global Networks 1785 1780 698 129 PaeTec Communications, Inc. 20115 1488 1522 654 Charter Communications 7018 1477 5734 960 AT&T WorldNet Services 2386 1287 568 909 AT&T Data Communications Serv 6478 1261 252 187 AT&T Worldnet Services 22773 1172 2858 61 Cox Communications, Inc. 3356 1159 10878 403 Level 3 Communications, LLC Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 653 56 6 United Telecom of Georgia 9198 497 202 13 Kazakhtelecom Data Network Ad 3292 449 2026 390 TDC Tele Danmark 30890 442 111 206 Evolva Telecom 702 413 1869 325 UUNET - Commercial IP service 8866 403 117 18 Bulgarian Telecommunication C 8551 401 353 46 Bezeq International 3320 375 7329 326 Deutsche Telekom AG 3301 371 1414 326 TeliaNet Sweden 34984 363 89 183 BILISIM TELEKOM Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1460 3049 251 UniNet S.A. de C.V. 10620 1072 240 149 TVCABLE BOGOTA 28573 1011 818 100 NET Servicos de Comunicao S.A 7303 768 396 103 Telecom Argentina Stet-France 6503 700 177 218 AVANTEL, S.A. 22047 553 310 15 VTR PUNTO NET S.A. 14420 499 32 72 CORPORACION NACIONAL DE TELEC 3816 492 208 87 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 448 99 76 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1107 445 10 TEDATA 24863 727 147 39 LINKdotNET AS number 36992 651 279 185 Etisalat MISR 3741 269 898 231 The Internet Solution 33776 220 12 12 Starcomms Nigeria Limited 2018 210 245 62 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 24835 189 78 9 RAYA Telecom - Egypt 29571 183 19 10 Ci Telecom Autonomous system 16637 159 423 93 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3889 3718 287 bellsouth.net, inc. 4323 2723 1112 393 Time Warner Telecom 19262 1942 4567 278 Verizon Global Networks 4766 1857 8409 489 Korea Telecom (KIX) 1785 1780 698 129 PaeTec Communications, Inc. 20115 1488 1522 654 Charter Communications 7018 1477 5734 960 AT&T WorldNet Services 4755 1474 298 160 TATA Communications formerly 8151 1460 3049 251 UniNet S.A. de C.V. 7545 1361 232 104 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2723 2330 Time Warner Telecom 19262 1942 1664 Verizon Global Networks 1785 1780 1651 PaeTec Communications, Inc. 4766 1857 1368 Korea Telecom (KIX) 4755 1474 1314 TATA Communications formerly 7545 1361 1257 TPG Internet Pty Ltd 8151 1460 1209 UniNet S.A. de C.V. 17488 1334 1206 Hathway IP Over Cable Interne 17974 1179 1124 PT TELEKOMUNIKASI INDONESIA 22773 1172 1111 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:68 /12:198 /13:408 /14:710 /15:1296 /16:11185 /17:5336 /18:9163 /19:18517 /20:23089 /21:23139 /22:30043 /23:29643 /24:170473 /25:1046 /26:1310 /27:768 /28:28 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2490 3889 bellsouth.net, inc. 4766 1487 1857 Korea Telecom (KIX) 4323 1394 2723 Time Warner Telecom 1785 1242 1780 PaeTec Communications, Inc. 17488 1078 1334 Hathway IP Over Cable Interne 18566 1069 1088 Covad Communications 11492 1067 1158 Cable One 8452 1000 1107 TEDATA 10620 988 1072 TVCABLE BOGOTA 19262 912 1942 Verizon Global Networks Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:12 2:2 4:13 8:290 12:2018 13:7 14:1 15:21 16:3 17:8 20:6 24:1463 27:251 31:1 32:49 33:12 38:691 40:98 41:2441 44:3 46:10 47:17 52:9 55:5 56:2 57:28 58:761 59:504 60:462 61:1068 62:1034 63:1972 64:3693 65:2344 66:4046 67:1823 68:1093 69:2705 70:708 71:446 72:1946 73:2 74:2261 75:250 76:318 77:900 78:622 79:433 80:995 81:767 82:495 83:439 84:682 85:1044 86:457 87:685 88:340 89:1560 90:95 91:2895 92:506 93:991 94:1403 95:654 96:528 97:210 98:614 99:33 108:105 109:583 110:391 111:533 112:287 113:327 114:437 115:573 116:1083 117:654 118:481 119:877 120:135 121:727 122:1564 123:948 124:1115 125:1312 128:227 129:198 130:193 131:557 132:247 133:17 134:195 135:45 136:242 137:145 138:265 139:104 140:484 141:196 142:342 143:373 144:465 145:50 146:450 147:168 148:662 149:290 150:155 151:230 152:296 153:168 154:2 155:357 156:159 157:324 158:110 159:357 160:317 161:183 162:255 163:174 164:410 165:367 166:460 167:414 168:646 169:157 170:716 171:59 172:2 173:950 174:502 175:152 176:1 178:314 180:466 182:198 183:240 184:115 186:519 187:379 188:1012 189:750 190:3817 192:5742 193:4721 194:3408 195:2808 196:1188 198:3572 199:3480 200:5324 201:1551 202:7989 203:8353 204:4073 205:2311 206:2493 207:3112 208:3866 209:3458 210:2558 211:1272 212:1712 213:1661 214:641 215:69 216:4715 217:1522 218:500 219:485 220:1144 221:402 222:317 223:1 End of report From bill at herrin.us Fri Jul 23 13:14:10 2010 From: bill at herrin.us (William Herrin) Date: Fri, 23 Jul 2010 08:14:10 -1000 Subject: IPv4 Exhaustion... In-Reply-To: References: Message-ID: On Fri, Jul 23, 2010 at 7:11 AM, Positively Optimistic wrote: > How do ISPs ?handle RIAA notices when NATTING customers.. ? ? We have > several customers that don't require public address space that could be > moved to private.. ? We're reluctant to make the move due to legal > liabilities.. Answer 1. Log the translations so you can match the source/destination ports and timestamp back to the real customer. Answer 2. "We were unable to locate the offending material / identify the offending customer using the information you provided. We have narrowed it to one of customers and preserved the relevant logs. Please contact us at 123-456-7890 and reference ticket 5432 for further assistance." "The IP address you specified is a multiuser access point. If you let us know the IP address on your end, we can watch for it inside our network for the next 24 hours and determine which customer is talking to it. We're unable to historically determine which customers interacted with your IP address." -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at ttec.com Fri Jul 23 13:48:47 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 23 Jul 2010 14:48:47 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <07A85B5D-CF76-442A-84CE-C48F4265D2F7@delong.com> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <20100723125614.4beb1659@opy.nosense.org> <4C491FC2.5040308@ttec.com> <07A85B5D-CF76-442A-84CE-C48F4265D2F7@delong.com> Message-ID: <4C49E40F.3050103@ttec.com> Owen DeLong wrote: > > On Jul 22, 2010, at 9:51 PM, Joe Maimon wrote: > >> >> >> >> Funny how so much concern is given to eliminating the possibility of end users returning for more space, yet for ISP's we have no real concern with what will happen when they near depletion of their /32 what with /48s to some thousands customers, aggregation, churn, what have you. >> > There's no need to give it a lot of concern because that process is pretty well understood and not particularly different from the current process in IPv4. There are a whole lot of organizations who do not view getting IPv4 from ARIN as particularly easy or well understood. Whether IPv6 requests will be better or worse for more or less of the population is completely unpredictable at this time. My point is that very little concern is being given to them and all of it to the end user, who all understand how to contact their service provider to request more service. > > When an ISP runs out, they apply for more from either their upstream, or, their RIR. Just that simple. When an end user runs out, they apply for more from either their upstream, or, their RIR. Just that simple. > >> The effort and cost of that on the organization is hard to predict, especially as how it may vary from size to size, organization to organization. Furthermore, everyone else pays with a DFZ slot. >> > Yeah, but, the number of DFZ slots consumed by this in IPv6 will be so much smaller than IPv4 that I really find it hard to take this argument seriously. Early days yet. And each IPv6 is worth four of IPv4. We are already proposing doubling the allocation rate for transitional mechanisms. > > Additionally, it's not necessarily true due to allocation by bisection. > >> /48 per customer gives the customer as many potential subnets as you have potential customers. >> > You say that like it is a bad thing. I say it as if it is a curious thing worthy of real consideration whether we are indeed following the wisest course of action. > >>> >>> With more address space than we need, the value we get is addressing >>> convenience (just like we've had in Ethernet addressing since 1982). >>> There is no need to make IPv6 addressing artificially precious and as >>> costly as IPv4 addressing is. >> >> A balance should be struck and for that to happen, weight must be given to both sides. >> > And it has. /32 is merely the default minimum allocation to an ISP. Larger blocks > can be given, > and, now that the RIRs are allocating by bisection, it should even > be possible in most cases for that additional space to be an expansion of the > existing allocation without changing the number of prefixes. > > e.g. 2001:db8::/32 could be expanded to 2001:db8::/28 > > 16 times as much address space, same number of DFZ slots. > > Owen Yes, the one saving grace of this system. Joe From matthew at matthew.at Fri Jul 23 15:26:43 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Fri, 23 Jul 2010 13:26:43 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <20100723.175333.74690943.sthaug@nethelp.no> References: <4C49A5BD.7060908@matthew.at> <20100723.175333.74690943.sthaug@nethelp.no> Message-ID: <4C49FB03.2030104@matthew.at> sthaug at nethelp.no wrote: >> It is not about how many devices, it is about how many subnets, because you >> may want to keep them isolated, for many reasons. >> >> It is not just about devices consuming lots of bandwidth, it is also about >> many small sensors, actuators and so. >> > > I have no problems with giving the customer several subnets. /56 is > just fine for that. /56? How about /62? That certainly covers "several"... and if you're really worried they might have too many subnets for that to work, how about /60? > I haven't seen any kind of realistic scenarios > which require /48 for residential users *and* will actually use lots > and lots of subnets - without requiring a similar amount of manual > configuration on the part of the customer. > > So we end up with /56 for residential users. > Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up. Matthew Kaufman From jfbeam at gmail.com Fri Jul 23 15:40:02 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 23 Jul 2010 16:40:02 -0400 Subject: IPv4 Exhaustion... In-Reply-To: <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> Message-ID: On Fri, 23 Jul 2010 13:59:41 -0400, Steven Bellovin wrote: > Do the complaints you receive include port numbers? I've never seen one that did. I've not even seen one with an exact timestamp. You would require the src and dst ip *and* port, plus the near exact timestamp of when the connection was opened and closed. Even then, that's one needle in a huge pile of identical needles. The netflow/sflow/etc. data needed to support such a lookup for a modern ISP network would be absolutely insane. (a decade ago for a small, regional ISP/telco, just prefix records were over 700MB per day -- back in the days of 2mb DSL, before bittorrent...) --Ricky From dougb at dougbarton.us Fri Jul 23 15:51:19 2010 From: dougb at dougbarton.us (Doug Barton) Date: Fri, 23 Jul 2010 13:51:19 -0700 (PDT) Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <9C3B3385-0201-4E80-B441-804BB39EE1D0@marcoh.net> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <9C3B3385-0201-4E80-B441-804BB39EE1D0@marcoh.net> Message-ID: On Fri, 23 Jul 2010, Marco Hogewoning wrote: > In short, why a /48 'Because we can!'. I do not buy your argument "consumers expect a /48 so we'll get grief if we don't give it to them." As others have pointed out, "consumers" don't want IPv6, they want web surfing, playing games, and e-mail. When this topic has come up in the past I've posted my discomfort on the idea of "/48s all the way down" and given that there is now good traction for the idea of actually using the squishy stuff between our ears for designing address plans, I'm not going to rehash that. What I will rehash, because no one else has repeated it yet, is that there is a middle ground between "assign /{56|60} only, and then suffer later if it's not enough" and "/48 all the way down!" You simply RESERVE a /48 for each customer, but ASSIGN the first /56 in the range. This will give you lots of great operational experience in how your customers actually use IPv6 under the umbrella of "/56 really is likely to be enough" while not having painted yourself into any corners if it turns out we're wrong about that. Why those particular boundaries? There are 256 /64 subnets in a /56 (once again, should be enough), and 256 /56s in a /48 (a: I like round numbers, b: see below). Once you've had some operational experience with this plan it should be pretty obvious how to move forward. If it turns out that /56 really is enough and you're running out of /48s to reserve, you go back through and start again on the /49 boundary of the /48s you already reserved. If it turns out that your customers really do need /48s, you go back to the RIR and ask for more space. Personally, I think the right answer is going to be a mix of both, but the beauty of this plan is that it allows for that. hth, Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From lee at asgard.org Fri Jul 23 16:19:26 2010 From: lee at asgard.org (Lee Howard) Date: Fri, 23 Jul 2010 17:19:26 -0400 Subject: Looking for comments In-Reply-To: References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> <4C48BA4F.6030708@gmail.com> Message-ID: <000c01cb2aac$bb096e10$311c4a30$@org> > > I think it's > > more reasonable to describe solutions for them than to rule their > > problem out of order. > > In that, you are surely correct. But frankly, having read 4.3 I have a > hard time taking it seriously as an early-stage IPv6 transition > mechanism. It reads to me like pie in the sky. Section 4.3 (IPv6-only core) makes sense, if you define "core" as "customer edge to peering edge." ISPs won't save much IPv4 address space by numbering their core routers into IPv6, but if they assign IPv6 addresses to Dual-stack Lite routers and LSNs, they have a transition plan. I can't say whether it's a viable plan, but it's a plan. > I can see 4.4 as a late stage mechanism when we're slowly dismantling > our IPv4 networks... I can also see it as an under-the-hood mechanism > for deploying new integrated technologies (utility meters, IPTV, etc). I think that's exactly the scenario it describes. IPv6 plus an IPv4-stretcher (NAT444, DS-Lite) is the crustimony proseedcake. Lee From leo.vegoda at icann.org Fri Jul 23 16:29:00 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 23 Jul 2010 14:29:00 -0700 Subject: IPv4 Exhaustion... In-Reply-To: References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> Message-ID: On 23 Jul 2010, at 1:40, Ricky Beam wrote: [...] >> Do the complaints you receive include port numbers? > > I've never seen one that did. I've not even seen one with an exact > timestamp. > > You would require the src and dst ip *and* port, plus the near exact > timestamp of when the connection was opened and closed. Even then, that's > one needle in a huge pile of identical needles. The netflow/sflow/etc. > data needed to support such a lookup for a modern ISP network would be > absolutely insane. (a decade ago for a small, regional ISP/telco, just > prefix records were over 700MB per day -- back in the days of 2mb DSL, > before bittorrent...) Richard Clayton wrote some interesting articles on this earlier this year. There's a UK flavour to them but I expect the concepts are transferable. http://www.lightbluetouchpaper.org/2010/01/12/extending-the-requirements-for-traceability/ http://www.lightbluetouchpaper.org/2010/01/13/practical-mobile-internet-access-traceability/ http://www.lightbluetouchpaper.org/2010/01/14/mobile-internet-access-data-retention-not/ Regards, Leo From lee at asgard.org Fri Jul 23 16:39:49 2010 From: lee at asgard.org (Lee Howard) Date: Fri, 23 Jul 2010 17:39:49 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C48E461.9090002@matthew.at> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <4C48E461.9090002@matthew.at> Message-ID: <001b01cb2aaf$942817d0$bc784770$@org> > -----Original Message----- > From: Matthew Kaufman [mailto:matthew at matthew.at] > Sent: Thursday, July 22, 2010 8:38 PM > To: Valdis.Kletnieks at vt.edu > Cc: nanog list > Subject: Re: Addressing plan exercise for our IPv6 course > "Home wifi router" vendors will do whatever it takes to make this work, > so of course in your scenario they simply implement NAT66 (whether or > not IETF folks think it is a good idea) however they see fit and nobody > calls. If that's what you want, you'd better submit that feature request, because it's not in queue yet. IPv6 will be in production before that comes out. Re: NAT vs firewall: draft-ietf-v6ops-ipv6-cpe-router-06 says "Use draft-ietf-v6ops-cpe-simple-security" which says "Block bogons and have a stateful firewall." Lee From lee at asgard.org Fri Jul 23 16:43:39 2010 From: lee at asgard.org (Lee Howard) Date: Fri, 23 Jul 2010 17:43:39 -0400 Subject: IPv4 Exhaustion... In-Reply-To: References: Message-ID: <001c01cb2ab0$1cc40450$564c0cf0$@org> "Your subpoena is overly broad. Go back and specify port number and timestamp. And read draft-ford-shared-addressing-issues-02, section 10." RIAA should be IPv6 activists. Lee > -----Original Message----- > From: Positively Optimistic [mailto:positivelyoptimistic at gmail.com] > Sent: Friday, July 23, 2010 1:11 PM > To: nanog at nanog.org > Subject: IPv4 Exhaustion... > > How do ISPs handle RIAA notices when NATTING customers.. ? We have > several customers that don't require public address space that could be > moved to private.. We're reluctant to make the move due to legal > liabilities.. From cidr-report at potaroo.net Fri Jul 23 17:00:04 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Jul 2010 22:00:04 GMT Subject: BGP Update Report Message-ID: <201007232200.o6NM04NI024238@wattle.apnic.net> BGP Update Report Interval: 15-Jul-10 -to- 22-Jul-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4725 61076 4.4% 484.7 -- ODN SOFTBANK TELECOM Corp. 2 - AS35805 26163 1.9% 40.1 -- SILKNET-AS SILKNET AS 3 - AS30890 21193 1.5% 49.1 -- EVOLVA Evolva Telecom s.r.l. 4 - AS25620 17016 1.2% 108.4 -- COTAS LTDA. 5 - AS3464 15808 1.1% 69.6 -- ASC-NET - Alabama Supercomputer Network 6 - AS11981 14829 1.1% 1647.7 -- SPECIALSYSTEMS - Special Systems Inc. 7 - AS5800 13984 1.0% 69.6 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 8 - AS45464 13358 1.0% 351.5 -- NEXTWEB-AS-AP Room 201, TGU Bldg 9 - AS5536 13198 1.0% 117.8 -- Internet-Egypt 10 - AS35931 12681 0.9% 4227.0 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 11 - AS7552 12209 0.9% 15.9 -- VIETEL-AS-AP Vietel Corporation 12 - AS36992 11330 0.8% 17.2 -- ETISALAT-MISR 13 - AS8452 11328 0.8% 20.6 -- TEDATA TEDATA 14 - AS48754 9460 0.7% 9460.0 -- SOBIS-AS SOBIS SOLUTIONS SRL 15 - AS8151 8270 0.6% 17.2 -- Uninet S.A. de C.V. 16 - AS32528 7723 0.6% 1287.2 -- ABBOTT Abbot Labs 17 - AS3816 7671 0.6% 37.4 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 18 - AS29049 7666 0.6% 28.6 -- DELTA-TELECOM-AS Delta Telecom LTD. 19 - AS17894 7244 0.5% 345.0 -- APMI-AS-AP AyalaPort Makati, Inc. / Data Center Operator 20 - AS20115 7152 0.5% 6.8 -- CHARTER-NET-HKY-NC - Charter Communications TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 9460 0.7% 9460.0 -- SOBIS-AS SOBIS SOLUTIONS SRL 2 - AS19174 6745 0.5% 6745.0 -- CNC-USA - China Netcom (USA) Operations Ltd. 3 - AS35931 12681 0.9% 4227.0 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS12109 2483 0.2% 2483.0 -- TECHNOLOGYINVESTORSINC - Technology Investors, Inc. 5 - AS11981 14829 1.1% 1647.7 -- SPECIALSYSTEMS - Special Systems Inc. 6 - AS43534 1340 0.1% 1340.0 -- CREDITCALL CreditCall Ltd 7 - AS29843 6464 0.5% 1292.8 -- FIVEA-AS1 - FIVE AREA SYSTEMS, INC 8 - AS32528 7723 0.6% 1287.2 -- ABBOTT Abbot Labs 9 - AS30990 1039 0.1% 1039.0 -- ADJIB-AS 10 - AS523 3116 0.2% 1038.7 -- REDSTONE-AS - Headquarters, USAISC 11 - AS13030 2019 0.1% 1009.5 -- INIT7 Init Seven AG, Zurich, Switzerland 12 - AS11613 791 0.1% 791.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 13 - AS44630 624 0.1% 624.0 -- A1799-AS A1799 Military Unit 14 - AS8792 591 0.0% 591.0 -- ASVNET Axel Springer Verlag AG 15 - AS23812 533 0.0% 533.0 -- SPEEDWAY-NET Japan Broadband Communications Corporation 16 - AS23795 1599 0.1% 533.0 -- FURUKAWA Fitec Corp. 17 - AS7513 533 0.0% 533.0 -- NETFORWARD Hitachi Information Systems, Ltd. 18 - AS7677 530 0.0% 530.0 -- DNP Dai Nippon Printing Co., Ltd 19 - AS23926 3162 0.2% 527.0 -- YSM-JP Yahoo Search Marketing Japan 20 - AS22779 513 0.0% 513.0 -- ASGAARD - Asgaard Holdings, LLC TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 91.212.23.0/24 9460 0.7% AS48754 -- SOBIS-AS SOBIS SOLUTIONS SRL 2 - 207.254.176.0/20 6745 0.5% AS19174 -- CNC-USA - China Netcom (USA) Operations Ltd. 3 - 63.211.68.0/22 6427 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - 198.140.43.0/24 6240 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 190.65.228.0/22 5769 0.4% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 6 - 41.34.29.0/24 4547 0.3% AS8452 -- TEDATA TEDATA 7 - 130.36.34.0/24 3717 0.2% AS32528 -- ABBOTT Abbot Labs 8 - 130.36.35.0/24 3715 0.2% AS32528 -- ABBOTT Abbot Labs 9 - 148.204.141.0/24 3368 0.2% AS8151 -- Uninet S.A. de C.V. 10 - 206.184.16.0/24 3096 0.2% AS174 -- COGENT Cogent/PSI 11 - 201.218.38.192/2 2812 0.2% AS27947 -- Telconet S.A 12 - 208.22.99.0/24 2483 0.2% AS12109 -- TECHNOLOGYINVESTORSINC - Technology Investors, Inc. 13 - 202.92.235.0/24 2284 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 14 - 212.51.128.0/19 2011 0.1% AS13030 -- INIT7 Init Seven AG, Zurich, Switzerland 15 - 149.2.97.0/24 1962 0.1% AS11981 -- SPECIALSYSTEMS - Special Systems Inc. 16 - 149.2.98.0/24 1962 0.1% AS11981 -- SPECIALSYSTEMS - Special Systems Inc. 17 - 63.66.59.0/24 1962 0.1% AS11981 -- SPECIALSYSTEMS - Special Systems Inc. 18 - 149.2.100.0/24 1962 0.1% AS11981 -- SPECIALSYSTEMS - Special Systems Inc. 19 - 149.2.102.0/24 1961 0.1% AS11981 -- SPECIALSYSTEMS - Special Systems Inc. 20 - 24.248.166.0/24 1960 0.1% AS11981 -- SPECIALSYSTEMS - Special Systems Inc. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 23 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 23 Jul 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201007232200.o6NM00kT024228@wattle.apnic.net> This report has been generated at Fri Jul 23 21:11:35 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 16-07-10 329107 202865 17-07-10 329205 202705 18-07-10 329157 202732 19-07-10 329144 202635 20-07-10 329235 202892 21-07-10 329718 202787 22-07-10 328930 202763 23-07-10 329517 203197 AS Summary 34932 Number of ASes in routing system 14801 Number of ASes announcing only one prefix 4485 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 94248768 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 23Jul10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 330004 203156 126848 38.4% All ASes AS6389 3889 292 3597 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4485 1819 2666 59.4% TWTC - tw telecom holdings, inc. AS19262 1943 278 1665 85.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4766 1857 503 1354 72.9% KIXS-AS-KR Korea Telecom AS22773 1172 66 1106 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1474 392 1082 73.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1088 63 1025 94.2% COVAD - Covad Communications Co. AS17488 1334 325 1009 75.6% HATHWAY-NET-AP Hathway IP Over Cable Internet AS8151 1460 559 901 61.7% Uninet S.A. de C.V. AS5668 1015 123 892 87.9% AS-5668 - CenturyTel Internet Holdings, Inc. AS6478 1262 397 865 68.5% ATT-INTERNET3 - AT&T WorldNet Services AS10620 1072 231 841 78.5% Telmex Colombia S.A. AS7545 1379 590 789 57.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS8452 1107 388 719 65.0% TEDATA TEDATA AS7303 769 121 648 84.3% Telecom Argentina S.A. AS4804 678 72 606 89.4% MPX-AS Microplex PTY LTD AS35805 653 64 589 90.2% SILKNET-AS SILKNET AS AS4808 827 242 585 70.7% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4780 690 163 527 76.4% SEEDNET Digital United Inc. AS28573 1018 493 525 51.6% NET Servicos de Comunicao S.A. AS7018 1477 962 515 34.9% ATT-INTERNET4 - AT&T WorldNet Services AS24560 985 484 501 50.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7552 653 154 499 76.4% VIETEL-AS-AP Vietel Corporation AS1785 1780 1282 498 28.0% AS-PAETEC-NET - PaeTec Communications, Inc. AS9443 572 76 496 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS17676 580 84 496 85.5% GIGAINFRA Softbank BB Corp. AS3356 1161 668 493 42.5% LEVEL3 Level 3 Communications AS7011 1135 653 482 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 553 81 472 85.4% VTR BANDA ANCHA S.A. AS9198 497 39 458 92.2% KAZTELECOM-AS JSC Kazakhtelecom Total 38565 11664 26901 69.8% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 178.238.160.0/20 AS15576 NTS NTS workspace AG, Bern, Switzerland 181.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.248.0/23 AS680 DFN-IP service X-WiN 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.51.93.0/24 AS10435 IDCOMM - ID COMMUNICATIONS 198.51.94.0/24 AS10435 IDCOMM - ID COMMUNICATIONS 198.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.26.183.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 200.1.112.0/24 AS29754 GO2TEL GO2TEL.COM INC. 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.72.224.0/21 AS24013 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.89.214.0/24 AS4323 TWTC - tw telecom holdings, inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From rah at shipwright.com Fri Jul 23 17:15:30 2010 From: rah at shipwright.com (R.A. Hettinga) Date: Fri, 23 Jul 2010 18:15:30 -0400 Subject: Caribbean Network Operators Group Inaugural Meeting in St Maarten August 15th to 20th 2010 In-Reply-To: References: Message-ID: On Jul 23, 2010, at 11:09 AM, Andr? Edwards wrote: > St. Maarten Damn. That's next door. :-) Cheers, RAH From nicholas.hatch at gmail.com Fri Jul 23 17:16:06 2010 From: nicholas.hatch at gmail.com (nick hatch) Date: Fri, 23 Jul 2010 15:16:06 -0700 Subject: IPv4 Exhaustion... In-Reply-To: References: Message-ID: On Fri, Jul 23, 2010 at 10:11 AM, Positively Optimistic < positivelyoptimistic at gmail.com> wrote: > How do ISPs handle RIAA notices when NATTING customers.. ? We have > several customers that don't require public address space that could be > moved to private.. We're reluctant to make the move due to legal > liabilities.. > It might be helpful to review the requirements for DMCA Safe Harbor for conduit communication providers, specifically section 512(a). It's been my experience that some networks (.edu's in particular) have voluntarily expanded their actions in response to DMCA complaints, and will sometimes falsely attribute these actions to DMCA requirements. If I recall correctly, the primary responsibilities for a conduit provider are limited to terminating repeat offenders, and informing subscribers of this policy. The DMCA doesn't explicitly define what a repeat offender is, nor does it explicitly mandate specific logging measures. If a provider makes best-effort attempts to correlate complaints to subscribers in order to track repeat offenders, I'm not sure there is a liability problem here. -Nick From kauer at biplane.com.au Fri Jul 23 19:56:14 2010 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 24 Jul 2010 10:56:14 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <20100723.175333.74690943.sthaug@nethelp.no> References: <4C49A5BD.7060908@matthew.at> <20100723.175333.74690943.sthaug@nethelp.no> Message-ID: <1279932974.28305.250.camel@karl> On Fri, 2010-07-23 at 17:53 +0200, sthaug at nethelp.no wrote: > > And I'm not saying to forget about what we have learn with DHCP, in > > fact DHCPv6 has many new and good features, but for many reasons, > > autonconfiguration is good enough, and much more simple. > [...] > For our scenarios DHCPv6 is needed, autoconfiguration is *not* good > enough. > [...] > I see no point in repeating the arguments for why autoconfiguration > is not good enough - this has been beaten to death, repeatedly, on > lots of IPv6 lists. It's not like "there can be only one". If autoconf is good enough for your purposes, that's great! If not, there's DHCP. That's great too! Or use autoconf AND stateless DHCP - that's great too! Heck, some of us will be using static addressing in a lot of places and that's great too. Most of us will be using all four methods. Understanding the advantages and limitations of each method and combo is important, but just because something has a limitation doesn't make it completely useless for everybody. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From scubacuda at gmail.com Fri Jul 23 20:29:41 2010 From: scubacuda at gmail.com (Rogelio) Date: Fri, 23 Jul 2010 18:29:41 -0700 Subject: NetApp contact in Bay Area? Message-ID: Anyone have a good NetApp contact for the Bay Area (East Bay, to be exact). I called their line today to try to get a quote (long story, but this is not an opportunity for a VAR), but their voice mail thingee kept punting me off and I never got to talk to a real person. Thanks in advance From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Jul 23 23:13:25 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 24 Jul 2010 13:43:25 +0930 Subject: Looking for comments In-Reply-To: <4C496C7F.9040005@foobar.org> References: <9AC0E2DA-EB3C-4EF7-B055-9D660FB4201C@cisco.com> <23B64BD6-BEDE-4A5B-A37D-81E65D36D2D4@delong.com> <4C48BA4F.6030708@gmail.com> <4C48CCD2.5000308@foobar.org> <20100723094721.61f6ed4d@opy.nosense.org> <4C496C7F.9040005@foobar.org> Message-ID: <20100724134325.6fc55b1e@opy.nosense.org> On Fri, 23 Jul 2010 11:18:39 +0100 Nick Hilliard wrote: > On 23/07/2010 01:17, Mark Smith wrote: > > Does this qualify? What the customer sees is delivered over IPv6, > > unlike the CPE management problem, where the ISP is the "IPv6 customer". > > > > "IPv6: The Future of IPTV? In Japan it isn't the future, it's now." > > http://www.internetnews.com/dev-news/article.php/3795086/IPv6-The-Future-of-IPTV.htm > > I understand that there are several networks doing this; the STB - like the > CPE modem - is managed by the service provider and the customer has no > management / control access over it. The customer stays on ipv4 for their > regular access product. > > Someone offline pointed me at the Google IPv6 Implementors 2010 conference, > at which: > > > https://sites.google.com/site/ipv6implementors/2010/agenda/13_Byrne_T-Mobile_IPv6GoogleMeeting.pdf?attredirects=0&d=1 > > This is genuinely interesting. > Certainly is. I've generally classified mobile operators as people who are heavily on the side of walled gardens. It's refreshing to see one advocating e2e and global reachability. > Nick From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Jul 23 23:38:49 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 24 Jul 2010 14:08:49 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C49E40F.3050103@ttec.com> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <20100723125614.4beb1659@opy.nosense.org> <4C491FC2.5040308@ttec.com> <07A85B5D-CF76-442A-84CE-C48F4265D2F7@delong.com> <4C49E40F.3050103@ttec.com> Message-ID: <20100724140849.796c9ba2@opy.nosense.org> On Fri, 23 Jul 2010 14:48:47 -0400 Joe Maimon wrote: > > > Owen DeLong wrote: > > > > On Jul 22, 2010, at 9:51 PM, Joe Maimon wrote: > > > >> > >> > > >> > >> Funny how so much concern is given to eliminating the possibility of end users returning for more space, yet for ISP's we have no real concern with what will happen when they near depletion of their /32 what with /48s to some thousands customers, aggregation, churn, what have you. > >> > > There's no need to give it a lot of concern because that process is pretty well understood and not particularly different from the current process in IPv4. > > There are a whole lot of organizations who do not view getting IPv4 from > ARIN as particularly easy or well understood. Whether IPv6 requests will > be better or worse for more or less of the population is completely > unpredictable at this time. > > My point is that very little concern is being given to them and all of > it to the end user, who all understand how to contact their service > provider to request more service. > > > > > > When an ISP runs out, they apply for more from either their upstream, or, their RIR. Just that simple. > > When an end user runs out, they apply for more from either their > upstream, or, their RIR. Just that simple. > Well my point isn't about how simple it is. It is how much that each request costs to handle. You could give each of residential your customers a single /64, and have some percentage of them come back every year for more subnets. Or you could give them all /56s, and likely have none of them come back at all for additional address space while they continue to be your customer. Up to a point (/56 seeming to be the common view at the moment) IPv6 address space is so plentiful that handling a request for more costs both or either the ISP or the customer more than if the customers were initially given enough to exceed their common and foreseeable requirements. There would be better things for an ISP to spend it's staff time on than dealing with low end customer IPv6 address space requests, when the ISP has the choice of giving all customers more than they'll likely need, resulting in additional address space requests to being a rare and exceptional occasion. > > > >> The effort and cost of that on the organization is hard to predict, especially as how it may vary from size to size, organization to organization. Furthermore, everyone else pays with a DFZ slot. > >> > > Yeah, but, the number of DFZ slots consumed by this in IPv6 will be so much smaller than IPv4 that I really find it hard to take this argument seriously. > > Early days yet. And each IPv6 is worth four of IPv4. We are already > proposing doubling the allocation rate for transitional mechanisms. > > > > > Additionally, it's not necessarily true due to allocation by bisection. > > > >> /48 per customer gives the customer as many potential subnets as you have potential customers. > >> > > You say that like it is a bad thing. > > I say it as if it is a curious thing worthy of real consideration > whether we are indeed following the wisest course of action. > > > > >>> > >>> With more address space than we need, the value we get is addressing > >>> convenience (just like we've had in Ethernet addressing since 1982). > >>> There is no need to make IPv6 addressing artificially precious and as > >>> costly as IPv4 addressing is. > >> > >> A balance should be struck and for that to happen, weight must be given to both sides. > >> > > And it has. /32 is merely the default minimum allocation to an ISP. Larger blocks > > can be given, > > and, now that the RIRs are allocating by bisection, it should even > > be possible in most cases for that additional space to be an expansion of the > > existing allocation without changing the number of prefixes. > > > > e.g. 2001:db8::/32 could be expanded to 2001:db8::/28 > > > > 16 times as much address space, same number of DFZ slots. > > > > Owen > > > Yes, the one saving grace of this system. > > Joe > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jul 24 00:50:46 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 24 Jul 2010 15:20:46 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C49FB03.2030104@matthew.at> References: <4C49A5BD.7060908@matthew.at> <20100723.175333.74690943.sthaug@nethelp.no> <4C49FB03.2030104@matthew.at> Message-ID: <20100724152046.6df037f7@opy.nosense.org> On Fri, 23 Jul 2010 13:26:43 -0700 Matthew Kaufman wrote: > sthaug at nethelp.no wrote: > >> It is not about how many devices, it is about how many subnets, because you > >> may want to keep them isolated, for many reasons. > >> > >> It is not just about devices consuming lots of bandwidth, it is also about > >> many small sensors, actuators and so. > >> > > > > I have no problems with giving the customer several subnets. /56 is > > just fine for that. > /56? How about /62? That certainly covers "several"... and if you're > really worried they might have too many subnets for that to work, how > about /60? > > I haven't seen any kind of realistic scenarios > > which require /48 for residential users *and* will actually use lots > > and lots of subnets - without requiring a similar amount of manual > > configuration on the part of the customer. > > > > So we end up with /56 for residential users. > > > Only because people think that the boundaries need to happen at > easy-to-type points given the textual representation. /56 is still > overkill for a house. And there's several billion houses in the world to > hook up. > So you're also strongly against 48 bit Ethernet MAC addresses? Dropping the two bits for group and local addresses, that's 70 368 744 177 664 nodes per LAN. How ridiculous! What were those idiots+ thinking! "48-bit Absolute Internet and Ethernet Host Numbers", by Yogan K. Dalal, Robert S. Printis, *July 1981* http://ethernethistory.typepad.com/papers/HostNumbers.pdf + not actually idiots From fred at cisco.com Sat Jul 24 01:34:13 2010 From: fred at cisco.com (Fred Baker) Date: Sat, 24 Jul 2010 08:34:13 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <20100724152046.6df037f7@opy.nosense.org> References: <4C49A5BD.7060908@matthew.at> <20100723.175333.74690943.sthaug@nethelp.no> <4C49FB03.2030104@matthew.at> <20100724152046.6df037f7@opy.nosense.org> Message-ID: <8701D525-1FFA-4388-A7BC-2B37EDB5D5B2@cisco.com> I tend to think a /60 is a reasonable allocation for a residential user. In my home I have two subnets and will in time likely add two more: - general network access - my office (required to be separate by Cisco Information Security policy) - (future) would likely want routable separate bandwidth for A/V at some point - (future) Smart Grid HAN will likely be its own subnet If my wife went to work for a company with an infosec policy like Cisco's, that becomes a fifth subnet. Yes, 16 to choose from seems reasonable. /56 seems appropriate to a small company, /48 for a larger company, and I could see a market for a /52. A company that needs more than a /48 is likely to also be using ULAs for some of its areas, which is an automatic extension, and could always justify another /48 (or one per continent) if it really needed them. Could I do all this within a /64? Of course, with some thought, and by getting the Smart Grid and office prefixes from other sources (Cisco, my utility) and running them over a VPN (which I do anyway). The question is why I should have to. Why four bit boundaries? Because we're using hexadecimal, and each character identifies four bits. It makes tracking numbers simple - no "remember to count by N" as in IPv4. It's not magic, but to my small mind - and especially for of non-technical residential customers - it seems reasonable. And yes, I think the logic behind a 48 bit MAC address is reasonable too. On Jul 24, 2010, at 7:50 AM, Mark Smith wrote: > On Fri, 23 Jul 2010 13:26:43 -0700 > Matthew Kaufman wrote: > >> sthaug at nethelp.no wrote: >>>> It is not about how many devices, it is about how many subnets, because you >>>> may want to keep them isolated, for many reasons. >>>> >>>> It is not just about devices consuming lots of bandwidth, it is also about >>>> many small sensors, actuators and so. >>>> >>> >>> I have no problems with giving the customer several subnets. /56 is >>> just fine for that. >> /56? How about /62? That certainly covers "several"... and if you're >> really worried they might have too many subnets for that to work, how >> about /60? >>> I haven't seen any kind of realistic scenarios >>> which require /48 for residential users *and* will actually use lots >>> and lots of subnets - without requiring a similar amount of manual >>> configuration on the part of the customer. >>> >>> So we end up with /56 for residential users. >>> >> Only because people think that the boundaries need to happen at >> easy-to-type points given the textual representation. /56 is still >> overkill for a house. And there's several billion houses in the world to >> hook up. >> > > So you're also strongly against 48 bit Ethernet MAC addresses? Dropping > the two bits for group and local addresses, that's 70 368 744 177 664 > nodes per LAN. How ridiculous! What were those idiots+ thinking! > > "48-bit Absolute Internet and Ethernet Host Numbers", by Yogan K. Dalal, > Robert S. Printis, *July 1981* > > http://ethernethistory.typepad.com/papers/HostNumbers.pdf > > > > > + not actually idiots > > http://www.ipinc.net/IPv4.GIF From Valdis.Kletnieks at vt.edu Sat Jul 24 02:50:25 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 24 Jul 2010 03:50:25 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: Your message of "Thu, 22 Jul 2010 19:53:48 PDT." References: Message-ID: <68964.1279957825@localhost> On Thu, 22 Jul 2010 19:53:48 PDT, "Akyol, Bora A" said: > As long as customers believe that having a NAT router/"firewall" in place is a security feature, > I don't think anyone is going to get rid of the NAT box. Firewall != NAT. The former is still needed in IPv6, the latter is not. And I suspect that most Joe Sixpacks think of that little box they bought as a "firewall" and don't understand NAT. If Joe Sixpack actually knows what NAT is, tell them the little box still provides all the firewall security and NAT isn't needed for IPv6. And if Joe Sixpack *still* insists on NAT, give him a /56 and tell him to turn on IPv6 autoconfigure. Poof - his subnet no longer matches the outside subnet, so he must be NAT'ed, right? (And if Joe sees through *that* subterfuge, consider hiring him ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From saku at ytti.fi Sat Jul 24 03:29:32 2010 From: saku at ytti.fi (Saku Ytti) Date: Sat, 24 Jul 2010 11:29:32 +0300 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <68964.1279957825@localhost> References: <68964.1279957825@localhost> Message-ID: <20100724082932.GA12472@mx.ytti.net> On (2010-07-24 03:50 -0400), Valdis.Kletnieks at vt.edu wrote: > Firewall != NAT. The former is still needed in IPv6, the latter is not. And I > suspect that most Joe Sixpacks think of that little box they bought as a Maybe you are talking strictly in context of residential DSL, in which case I would agree, NAT is killable, if we don't fsck-up in our DSL offerings. (Provide customer /64 and route /56 to ::c/64, so first /64 is bridged, if customer ever wants to start routing, they just add ::c/64 router to LAN.) However it is quite optimistic to think IPv6 would remove completely need for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. This is non-technical problem, enterprises of non-trivial size can't typically even tell without months of research all the devices and software where they've written down the IP addresses. RFC4193 + NAT quite simply is what they know and are comfortable with. It would be hard sell to ask them to design whole IPv6 infra so that they can confidently renumber it in 15min, like you can with RFC4193+NAT. -- ++ytti From owen at delong.com Sat Jul 24 03:40:19 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Jul 2010 01:40:19 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C49FB03.2030104@matthew.at> References: <4C49A5BD.7060908@matthew.at> <20100723.175333.74690943.sthaug@nethelp.no> <4C49FB03.2030104@matthew.at> Message-ID: On Jul 23, 2010, at 1:26 PM, Matthew Kaufman wrote: > sthaug at nethelp.no wrote: >>> It is not about how many devices, it is about how many subnets, because you >>> may want to keep them isolated, for many reasons. >>> >>> It is not just about devices consuming lots of bandwidth, it is also about >>> many small sensors, actuators and so. >>> >> >> I have no problems with giving the customer several subnets. /56 is >> just fine for that. > /56? How about /62? That certainly covers "several"... and if you're really worried they might have too many subnets for that to work, how about /60? /60 at a bare minimum since you can do RDNS delegation on /x boundaries where x%4==0. RDNS for a /62 is do-able, but, it requires 4 zone files and 4 sets of parent NS records instead of 1. /62 for 4 customers ends up requiring 16 zone files and 16 sets of parent NS records instead of 4. >> I haven't seen any kind of realistic scenarios >> which require /48 for residential users *and* will actually use lots >> and lots of subnets - without requiring a similar amount of manual >> configuration on the part of the customer. >> >> So we end up with /56 for residential users. >> > Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up. > Yes... Overkill is a good thing in IPv6. Even with this level of overkill, fully deploying the current world with a /48 for every house consumes less than 0.1% of the address space. (Apprximately 4x10^9 households on earth getting a /48 each = roughly one /16 which is 1/65,536th of the total address space and 1/8192nd of 2000::/3) What is the harm in doing so? Why not minimize provisioning effort and maximize user flexibility by consuming a very tiny fraction of a plentiful resource which costs virtually nothing? Owen From owen at delong.com Sat Jul 24 03:48:13 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Jul 2010 01:48:13 -0700 Subject: IPv4 Exhaustion... In-Reply-To: References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> Message-ID: On Jul 23, 2010, at 1:40 PM, Ricky Beam wrote: > On Fri, 23 Jul 2010 13:59:41 -0400, Steven Bellovin wrote: >> Do the complaints you receive include port numbers? > > I've never seen one that did. I've not even seen one with an exact timestamp. > > You would require the src and dst ip *and* port, plus the near exact timestamp of when the connection was opened and closed. Even then, that's one needle in a huge pile of identical needles. The netflow/sflow/etc. data needed to support such a lookup for a modern ISP network would be absolutely insane. (a decade ago for a small, regional ISP/telco, just prefix records were over 700MB per day -- back in the days of 2mb DSL, before bittorrent...) > > --Ricky Rough translation: LSN + CALEA = Very Interesting Times for ISPs that deploy LSN and are subject to CALEA. Owen From owen at delong.com Sat Jul 24 04:13:18 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Jul 2010 02:13:18 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <20100724082932.GA12472@mx.ytti.net> References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> Message-ID: On Jul 24, 2010, at 1:29 AM, Saku Ytti wrote: > On (2010-07-24 03:50 -0400), Valdis.Kletnieks at vt.edu wrote: > >> Firewall != NAT. The former is still needed in IPv6, the latter is not. And I >> suspect that most Joe Sixpacks think of that little box they bought as a > > Maybe you are talking strictly in context of residential DSL, in which case > I would agree, NAT is killable, if we don't fsck-up in our DSL offerings. > (Provide customer /64 and route /56 to ::c/64, so first /64 is bridged, if > customer ever wants to start routing, they just add ::c/64 router to LAN.) > > However it is quite optimistic to think IPv6 would remove completely need > for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I > fear we will notice PRNG returning 0 very often) and then NAT it to > provider provided public IP addresses. I'm just hoping that we'll at least > see 1:1 NAT instead of NAPT being used. > Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. > This is to facilitate easy and cheap way to change provider. Getting PI > address is even harder now, as at least RIPE will verify that you are > multihomed, while many enterprises don't intent to be, they just need low > cost ability to change operator. > Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? Finally, if you think that non-multihomed end sites need PI, then, put a proposal in to change the RIR policies. RIR policies are not immutable. Each RIR has a bottom-up consensus driven process. If you don't like the policies, it really isn't that hard to get them changed. (I say this as an author of the first successful policy to create IPv6 PI) > This is non-technical problem, enterprises of non-trivial size can't > typically even tell without months of research all the devices and software > where they've written down the IP addresses. Sounds like they haven't written them down very well. > RFC4193 + NAT quite simply is what they know and are comfortable with. It > would be hard sell to ask them to design whole IPv6 infra so that they can > confidently renumber it in 15min, like you can with RFC4193+NAT. > Why would you need to renumber in 15 minutes? It's easy enough to do in a week, given the above RA-based process. Owen From saku at ytti.fi Sat Jul 24 04:27:31 2010 From: saku at ytti.fi (Saku Ytti) Date: Sat, 24 Jul 2010 12:27:31 +0300 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> Message-ID: <20100724092731.GA13155@mx.ytti.net> On (2010-07-24 02:13 -0700), Owen DeLong wrote: > > This is non-technical problem, enterprises of non-trivial size can't > > typically even tell without months of research all the devices and software > > where they've written down the IP addresses. > > Sounds like they haven't written them down very well. Exactly, unfortunately this is reality in many enterprises today. And it is optimistic to hope any technical change will fix the situation. It would be excessively easy to renumber IPv4 infrastructure if it was built with that goal, yet it can be multiyear MUSDs gig to integrator. -- ++ytti From llynch at civil-tongue.net Sat Jul 24 07:47:21 2010 From: llynch at civil-tongue.net (Lucy Lynch) Date: Sat, 24 Jul 2010 05:47:21 -0700 (PDT) Subject: Caribbean Network Operators Group Inaugural Meeting in St Maarten August 15th to 20th 2010 In-Reply-To: References: Message-ID: Andr? - Nice program. Congratulations and bonne chance! - Lucy On Fri, 23 Jul 2010, Andr? Edwards wrote: > Invitation to CARIBNOG 1 > > -------------------------------------- > > August 15th ? 20th, 2010 > > Westin Hotel & Resort > > 144 Oyster Pond Road > > St Maarten > > -------------------------------------- > > Dear colleagues, members of the Lacnic community. > > The Caribbean Network Operators Group (CARIBNOG) has the pleasure of > announcing and inviting you to participate in the first Regional CaribNOG > meeting, CARIBNOG 1, from August 15th ? 20th, 2010. The event will be held > at the Westin Hotel and Resort in the beautiful island of St. Maarten during > the Inaugural St. Maarten?s ICT Week which is being hosted by the Government > of St. Maarten and the Caribbean Telecommunications Union (CTU). > > The Caribbean Network Operators Group (CaribNOG) is a community of Network > Operators dedicated to exchanging technical information and experiences > related to the management of IP networks in the Caribbean region. CaribNOG > conferences provide a forum for the coordination and dissemination of > technical information related to networking technologies, research and > operational practices. The meetings are informal, with an emphasis on > practical solutions, training and insight relevant to the region. > > In St. Maarten, expert speakers from the regional and international > technical community will be conducting hands-on workshops, in-depth > tutorials and presentations on the following topics: > > ? VoIP: VOIP workshop ? Deploying secure small and medium Scale VoIP > solutions > > ? LINUX: Configuring and Securing LAMP, creating a secure LAMP > application, IP Services and Security > > ? ROUTING: Basics; introduction to OSPF, BGP, VoIP and SIP > > ? CSIRT: Developing a Network Security and Incident Response Team. > > You are welcome to join us in St Maarten for this inaugural meeting. > > More detailed information on the event and its program, accommodation, > registration, and general information will soon be available on CARIBNOG's > website: www.caribnog.org > > Sincerely, > > Andre Edwards > > CARIBNOG 1 Program Committee > From ipv3.com at gmail.com Sat Jul 24 08:00:46 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Sat, 24 Jul 2010 08:00:46 -0500 Subject: Proposed Global Policy for Autonomous System Numbers - Final Call for Comments and Background Report Message-ID: Proposed Global Policy for Autonomous System Numbers - Final Call for Comments and Background Report http://www.icann.org/en/announcements/announcement-23jul10-en.htm ---------- Forwarded message ---------- From: IPv3.com Date: Sat, Jul 24, 2010 at 7:45 AM Subject: ASN IANA MLM Leasing Business Out-Dated - Now Automated To: asn-proposal-2010 at icann.org ASN IANA MLM Leasing Business Out-Dated - Now Automated Selling or leasing UNIQUE binary values is no longer viable because .COM owners can derive them FREE With IPv3 and IPv16 a simple 6-bit Alphabet (Symbol Set) is used for mapping UNIQUE binary values 64 symbols - 6-bits - {[0-9][A-Z][a-z]-.} A 5-Letter .COM owner can create a UNIQUE 30-bit ASN for FREE via the 6-bit Alphabet If upper and lower case symbols are used, several FREE ASNs can be generated A $6 annual fee for the .COM registration covers all of the costs needed to generate UNIQUE binary values The 4-Letter .COM owners can generate several FREE 24-bit prefixes (called /24s) for IPv* Addressing ASN IANA MLM Leasing Business Out-Dated - Now Automated 4096 Trending TLD selections are also automated ICANN and the RIRs can be Dissolved From matthew at matthew.at Sat Jul 24 10:50:28 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Sat, 24 Jul 2010 08:50:28 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> Message-ID: <4C4B0BC4.5030908@matthew.at> Owen DeLong wrote: > > Why on earth would you do that? Why not just put the provider-assigned > addresses on the interfaces along side the ULA addresses? Using ULA > in that manner is horribly kludgy and utterly unnecessary. > Because, although one of the original goals of IPv6 was for hosts to be easily multihomed at multiple addresses like this, host software (and even some of the required specifications) isn't really isn't there yet, and often the wrong thing happens. Never mind that the timescale for IPv6 deployment, no matter how long it is, will be shorter than the timescale for updating PCI, HIPPA, and SOX audit checklists to remove the requirements around "hide internal topology" and "do not use public addresses on any interface of critical hosts". > > Why is that easier/cheaper than changing your RAs to the new provider and > letting the old provider addresses time out? > This would *also* require multihoming to actually work properly, only worse as the rules for selecting ULA vs PA routes are usually more right than the rules for selecting one PA vs another PA as an outbound interface, even if your host does multiple default routes properly. Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. Matthew Kaufman From jbates at brightok.net Sat Jul 24 10:54:18 2010 From: jbates at brightok.net (Jack Bates) Date: Sat, 24 Jul 2010 10:54:18 -0500 Subject: Router/switch vendor recommendations? off-list replies fine Message-ID: <4C4B0CAA.2090605@brightok.net> I'm trying to find versatile vendors that can handle a variety of features that meet my needs for several projects. Honestly, the projects aren't that big, but I'd like certain versatility with them, and having trouble finding the right vendors. Perhaps it's just my engineering that is flawed. Suscriber management (both a redundant and non-redundant unit) - PPPoE (4/6) - DHCP (4/6) - IPv6 support for both with reasonable management plans - option 82 (DHCPv6 have an equiv option?) - backend support for DHCP (preferably both radius and DHCP) - q-in-q L3 termination w/ proxy-arp support - LAG for at least 2 Gig-E - line rate L3 speeds - support for OC3 SONET a plus - support for OC3 ATM with RBE type setup a plus - isis (4/6) multi-topology - BGP4 (4/6) NSR a plus L2 Switch (redundant) - LAG (40Gig+ ring) - Line rate - 8100 in 8100 (simple q-in-q) - ability to take untagged traffic on port and arbitrarily provide it double tags (one to send across network, and the inner to drop on a trunk to an aggregation site for customer) Basic q-in-q but customer doesn't have ability to assign vlan on their side. - standard guards for spanning tree, dhcp, IPv6 etc. - rj45 10/100, mm-fx 100, sm-fx 100/1000 CPE switch (for customer who can't terminate fiber or for extending our testing demarc) -1 to 2 rj45 100/1000 -1 to 2 sm-fx 100/1000 -inexpensive, small From kauer at biplane.com.au Sat Jul 24 11:23:06 2010 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 25 Jul 2010 02:23:06 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C4B0BC4.5030908@matthew.at> References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> <4C4B0BC4.5030908@matthew.at> Message-ID: <1279988586.28305.356.camel@karl> On Sat, 2010-07-24 at 08:50 -0700, Matthew Kaufman wrote: > Even if all your hosts end up with external connectivity that works, the odds > that they can reliably talk to each other is low. I hope I'm not taking the above quote out of context, but why do you think this? How does the fact that interfaces on your host may have more than one public address translate into low odds that they can talk to each other? The only thing I can think of is that if an interface in your network has a public address from only one provider, and another interface in your network has a public address only from another provider, then the connection will go out through one provider and back in from the other, which would be less than optimal. On the other hand, there is no reason to think this would be particularly unreliable, and if such a situation existed it would either indicate a fault or be what you actually wanted. The discussion was in the context of a renumbering exercise. Using the simple method of having a period where both provider ranges are active and allowing the old provider range to "time out" may result in lost connections; there may also be caching difficulties with some applications. Neither situation is long-lived, and both can be mitigated by careful planning. Is that what you meant? Maybe I've missed your point. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From brandon at rd.bbc.co.uk Sat Jul 24 11:40:35 2010 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 24 Jul 2010 17:40:35 +0100 (BST) Subject: Addressing plan exercise for our IPv6 course Message-ID: <201007241640.RAA07071@sunf10.rd.bbc.co.uk> > > Enterprises of non-trivial size will likely use RFC4193 (and I > > fear we will notice PRNG returning 0 very often) and then NAT it to > > provider provided public IP addresses. Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. > > I'm just hoping that we'll at least > > see 1:1 NAT instead of NAPT being used. I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist. RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode. > Why on earth would you do that? Why not just put the provider-assigned > addresses on the interfaces along side the ULA addresses? Using ULA > in that manner is horribly kludgy and utterly unnecessary. Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent. With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap. > > This is to facilitate easy and cheap way to change provider. Getting PI > > address is even harder now, as at least RIPE will verify that you are > > multihomed, while many enterprises don't intent to be, they just need low > > cost ability to change operator. > > > Why is that easier/cheaper than changing your RAs to the new provider and > letting the old provider addresses time out? And changing all the ACLs based on the old providers addresses And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with 10year+ refresh cycle) brandon From bzs at world.std.com Sat Jul 24 11:54:12 2010 From: bzs at world.std.com (Barry Shein) Date: Sat, 24 Jul 2010 12:54:12 -0400 Subject: IPv4 Exhaustion... In-Reply-To: References: Message-ID: <19531.6836.39002.615249@world.std.com> What's crazy is: a) How each org/company seems to be handling these notices themselves. b) How they seem to be filtering down to operations people to sort out. Seems like an opportunity for some lawyers to form a membership association. Agree to some reasonable policy, send them your RIAA (et al, because this kind of thing is growing like kudzu) takedowns, they'll respond or tell you what you should do to satisfy (if anything.) This would let that org develop some leverage with RIAA et al, "if we don't hang together we will surely hang separately", RIAA is taking advantage of this, their lawyers know full well how a+b above can be exploited. I sat in an "intellectual property constituency" meeting at ICANN which was basically me, and 100+ lawyers. Their main topic was takedowns, and how horrible it was that ISPs et al don't just reformat all their disks on receipt of a lawyer letter on nice letterhead, the bastards (i.e., us) start demanding court orders etc, outrageous! expensive! burdensome! I told some quick anecdotes about phony takedown demands (e.g., painful divorce or business partner fights) and my inability/reluctance to accurately judge these things beyond the most obvious. I can't say they weren't receptive, it was a little bit of a "WAKE UP AND SMELL THE COFFEE, TAKEDOWNS ARE VALUABLE CONSIDERATIONS!" which they understood, and the potential liability aspects for an ISP. Anyhow my take is that takedowns are a growth industry. -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From andre.edwards at gmail.com Sat Jul 24 12:04:09 2010 From: andre.edwards at gmail.com (=?ISO-8859-1?Q?Andr=E9_Edwards?=) Date: Sat, 24 Jul 2010 13:04:09 -0400 Subject: Caribbean Network Operators Group Inaugural Meeting in St Maarten August 15th to 20th 2010 In-Reply-To: References: Message-ID: Thanks for the support everyone. Our hope is for the community to grow as a rich resource. Look out for more updates. Regards, On Sat, Jul 24, 2010 at 8:47 AM, Lucy Lynch wrote: > Andr? - > > Nice program. Congratulations and bonne chance! > > - Lucy > > > On Fri, 23 Jul 2010, Andr? Edwards wrote: > > Invitation to CARIBNOG 1 >> >> -------------------------------------- >> >> August 15th ? 20th, 2010 >> >> Westin Hotel & Resort >> >> 144 Oyster Pond Road >> >> St Maarten >> >> -------------------------------------- >> >> Dear colleagues, members of the Lacnic community. >> >> The Caribbean Network Operators Group (CARIBNOG) has the pleasure of >> announcing and inviting you to participate in the first Regional CaribNOG >> meeting, CARIBNOG 1, from August 15th ? 20th, 2010. The event will be >> held >> at the Westin Hotel and Resort in the beautiful island of St. Maarten >> during >> the Inaugural St. Maarten?s ICT Week which is being hosted by the >> Government >> of St. Maarten and the Caribbean Telecommunications Union (CTU). >> >> The Caribbean Network Operators Group (CaribNOG) is a community of Network >> Operators dedicated to exchanging technical information and experiences >> related to the management of IP networks in the Caribbean region. CaribNOG >> conferences provide a forum for the coordination and dissemination of >> technical information related to networking technologies, research and >> operational practices. The meetings are informal, with an emphasis on >> practical solutions, training and insight relevant to the region. >> >> In St. Maarten, expert speakers from the regional and international >> technical community will be conducting hands-on workshops, in-depth >> tutorials and presentations on the following topics: >> >> ? VoIP: VOIP workshop ? Deploying secure small and medium Scale >> VoIP >> solutions >> >> ? LINUX: Configuring and Securing LAMP, creating a secure LAMP >> application, IP Services and Security >> >> ? ROUTING: Basics; introduction to OSPF, BGP, VoIP and SIP >> >> ? CSIRT: Developing a Network Security and Incident Response Team. >> >> You are welcome to join us in St Maarten for this inaugural meeting. >> >> More detailed information on the event and its program, accommodation, >> registration, and general information will soon be available on CARIBNOG's >> website: www.caribnog.org >> >> Sincerely, >> >> Andre Edwards >> >> CARIBNOG 1 Program Committee >> >> -- Andr? M Edwards The Caribbean must be one! http://www.integratemenow.com/ http://www.myrx7story.com From fred at cisco.com Sat Jul 24 12:06:20 2010 From: fred at cisco.com (Fred Baker) Date: Sat, 24 Jul 2010 19:06:20 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <201007241640.RAA07071@sunf10.rd.bbc.co.uk> References: <201007241640.RAA07071@sunf10.rd.bbc.co.uk> Message-ID: On Jul 24, 2010, at 6:40 PM, Brandon Butterworth wrote: > Such a site would be the seed for when (if) we come up with the tech > for everyone to have PI and lose all the restrictions imposed so far. Oh, we have the technology. It's called "memory". Speaking from the perspective of a vendor, I'll happily sell it to you. Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours. From leen at consolejunkie.net Sat Jul 24 12:19:36 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Sat, 24 Jul 2010 19:19:36 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <201007241640.RAA07071@sunf10.rd.bbc.co.uk> References: <201007241640.RAA07071@sunf10.rd.bbc.co.uk> Message-ID: <4C4B20A8.2080802@consolejunkie.net> > Eventually ARIN (or someone else will do it for them) may create a site > you can register your address and know that it really is unique > among participating registrants. Random is fine, unique is better. > > Such a site would be the seed for when (if) we come up with the tech > for everyone to have PI and lose all the restrictions imposed so far. > > Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/ From owen at delong.com Sat Jul 24 12:42:19 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Jul 2010 10:42:19 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C4B0BC4.5030908@matthew.at> References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> <4C4B0BC4.5030908@matthew.at> Message-ID: <891EB3CD-5C88-491C-AE8E-F2A963A8637C@delong.com> On Jul 24, 2010, at 8:50 AM, Matthew Kaufman wrote: > Owen DeLong wrote: >> >> Why on earth would you do that? Why not just put the provider-assigned >> addresses on the interfaces along side the ULA addresses? Using ULA >> in that manner is horribly kludgy and utterly unnecessary. >> > Because, although one of the original goals of IPv6 was for hosts to be easily multihomed at multiple addresses like this, host software (and even some of the required specifications) isn't really isn't there yet, and often the wrong thing happens. > Host software is there, but, it requires some education on how to configure it. You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason. > Never mind that the timescale for IPv6 deployment, no matter how long it is, will be shorter than the timescale for updating PCI, HIPPA, and SOX audit checklists to remove the requirements around "hide internal topology" and "do not use public addresses on any interface of critical hosts". I expect the PCI changes to be out in less than a year. HIPPA and SOX may take closer to two years, maybe even three. I don't expect enterprise-wide adoption of IPv6 to be significant in less than 5 years. The big push for IPv6 right now needs to be on the public-facing services side which doesn't have hidden topology by definition. >> >> Why is that easier/cheaper than changing your RAs to the new provider and >> letting the old provider addresses time out? >> > This would *also* require multihoming to actually work properly, only worse as the rules for selecting ULA vs PA routes are usually more right than the rules for selecting one PA vs another PA as an outbound interface, even if your host does multiple default routes properly. Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. > Why use rules for selection... Simply have the RAs contain proper priorities for the ones you want to use at any particular moment and change the RA priorities as needed. Owen From brandon at rd.bbc.co.uk Sat Jul 24 12:49:55 2010 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 24 Jul 2010 18:49:55 +0100 (BST) Subject: Addressing plan exercise for our IPv6 course Message-ID: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> >> Eventually ARIN (or someone else will do it for them) may create a site ... > Did you mean something like this maybe ?: > > http://www.sixxs.net/tools/grh/ula/ Q.E.D. The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. brandon From brandon at rd.bbc.co.uk Sat Jul 24 12:52:16 2010 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 24 Jul 2010 18:52:16 +0100 (BST) Subject: Addressing plan exercise for our IPv6 course Message-ID: <201007241752.SAA14419@sunf10.rd.bbc.co.uk> > > Such a site would be the seed for when (if) we come up with the tech > > for everyone to have PI and lose all the restrictions imposed so far. > > Oh, we have the technology. It's called "memory" If that were viable then we'd be doing it. > Speaking from the perspective of a vendor, I'll happily sell it to you. > > Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours. > Indeed, best not listen to vendors brandon From owen at delong.com Sat Jul 24 12:48:50 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Jul 2010 10:48:50 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <1279988586.28305.356.camel@karl> References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> <4C4B0BC4.5030908@matthew.at> <1279988586.28305.356.camel@karl> Message-ID: <1C9397A1-DC6B-4A40-A333-749EC8316C2E@delong.com> On Jul 24, 2010, at 9:23 AM, Karl Auer wrote: > On Sat, 2010-07-24 at 08:50 -0700, Matthew Kaufman wrote: >> Even if all your hosts end up with external connectivity that works, the odds >> that they can reliably talk to each other is low. > > I hope I'm not taking the above quote out of context, but why do you > think this? How does the fact that interfaces on your host may have more > than one public address translate into low odds that they can talk to > each other? > > The only thing I can think of is that if an interface in your network > has a public address from only one provider, and another interface in > your network has a public address only from another provider, then the > connection will go out through one provider and back in from the other, > which would be less than optimal. On the other hand, there is no reason > to think this would be particularly unreliable, and if such a situation > existed it would either indicate a fault or be what you actually wanted. > I would think even that would be unlikely as the border routers would most likely know routes to both sets of internal addresses and worst case, the packets should hairpin inside the border router rather than being forwarded to the external providers. Ideally, this hairpinning should be designed to occur prior to reaching the firewall, or, the firewall(s) must have rulesets to enable such. However, either solution is easily implemented in most topologies. Owen From kauer at biplane.com.au Sat Jul 24 12:56:52 2010 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 25 Jul 2010 03:56:52 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <891EB3CD-5C88-491C-AE8E-F2A963A8637C@delong.com> References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> <4C4B0BC4.5030908@matthew.at> <891EB3CD-5C88-491C-AE8E-F2A963A8637C@delong.com> Message-ID: <1279994212.28305.358.camel@karl> On Sat, 2010-07-24 at 10:42 -0700, Owen DeLong wrote: > You do have to properly set up the rules for which addresses to use for what > communication properly. It breaks less if you forego the ULA brokenness, > but, some people insist for whatever reason. What is "the ULA brokenness"? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Sat Jul 24 12:57:49 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Jul 2010 10:57:49 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <201007241640.RAA07071@sunf10.rd.bbc.co.uk> References: <201007241640.RAA07071@sunf10.rd.bbc.co.uk> Message-ID: On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote: >>> Enterprises of non-trivial size will likely use RFC4193 (and I >>> fear we will notice PRNG returning 0 very often) and then NAT it to >>> provider provided public IP addresses. > > Eventually ARIN (or someone else will do it for them) may create a site > you can register your address and know that it really is unique > among participating registrants. Random is fine, unique is better. > > Such a site would be the seed for when (if) we come up with the tech > for everyone to have PI and lose all the restrictions imposed so far. > SIXXS already has such a registry with a pretty low adoption rate. I still fail to see any advantage whatsoever to this approach and I think that the limited number of sites that implement it is unlikely to get continued support from ISVs. >>> I'm just hoping that we'll at least >>> see 1:1 NAT instead of NAPT being used. > > I think that will be a common PI alternative. If people really don't > want NAT then we shouldn't provide reasons for it to exist. > > RFC4193 seems to be the best enterprise plan. They can link to other > enterprises and change ISPs easily or multihome. They are not beholden > to any ISP or numbering authority. The global table doesn't explode. > I agree that easier to get PI addresses is a better alternative. I will support policy initiatives to do that. RFC4193 remains an utterly horrible idea and NATing it to the public internet remains even worse. >> Why on earth would you do that? Why not just put the provider-assigned >> addresses on the interfaces along side the ULA addresses? Using ULA >> in that manner is horribly kludgy and utterly unnecessary. > > Enterprises tend to want only one identifier to manage per device and > that it be unique and mostly permanent. > Right... That identifier is the EUI-64 which is both permanent and unique. The prefix changes when you switch providers, but, that's mostly not particularly horrible since there are tools to make that easier for the bulk of internal hosts. > With several PA and ULA on each device, links to ISPs and other > enterprises, the combinations of addresses and paths to manage flows > and security over become too hard (if it's not simple it's probably not > secure). Every device becomes a router and firewall and the staff who > manage those aren't cheap. > Actually, if you set things up correctly, most of the security stuff to manage is about the same because you hairpin the stuff that doesn't need filtration at a point before it hits the packet filters. >>> This is to facilitate easy and cheap way to change provider. Getting PI >>> address is even harder now, as at least RIPE will verify that you are >>> multihomed, while many enterprises don't intent to be, they just need low >>> cost ability to change operator. >>> >> Why is that easier/cheaper than changing your RAs to the new provider and >> letting the old provider addresses time out? > > And changing all the ACLs based on the old providers addresses > Mostly this is a pretty straight forward copy->search->replace problem with prefix changes that can be done with the equivalent of an s/x/y/g construct. > And allowing for all the 5 - 15 year old kit that predates this and > won't be upgraded (we have that problem with NT embedded in systems > with 10year+ refresh cycle) > That kit won't support IPv6, so, I fail to see the relevance. Any kit that supports IPv6 supports this. Owen From kauer at biplane.com.au Sat Jul 24 13:19:26 2010 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 25 Jul 2010 04:19:26 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> Message-ID: <1279995566.28305.375.camel@karl> On Sat, 2010-07-24 at 18:49 +0100, Brandon Butterworth wrote: > > Did you mean something like this maybe ?: > > > > http://www.sixxs.net/tools/grh/ula/ > > Q.E.D. > > The RFC seeks to avoid a registry so we end up with the potential for > many as a result. May as well have had ARIN do it officially in the > first place so there'd only be one. The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Sixxs "manages" prefixes from within the random one, there is as yet nothing set up to properly manage the other one. Dunno why ARIN should necessarily manage it; or any particular RIR for that matter. The "random" one allows for swift, bureaucracy-free self-allocation. The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. Makes it an interesting question as to whether the managed range is really necessary at all. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From brandon at rd.bbc.co.uk Sat Jul 24 13:41:18 2010 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 24 Jul 2010 19:41:18 +0100 (BST) Subject: Addressing plan exercise for our IPv6 course Message-ID: <201007241841.TAA18787@sunf10.rd.bbc.co.uk> > The RFC provides for two address ranges in fc00::/7, one for random > prefixes (fc00::/8), the other reserved for later management (fd00::/8). Later, in some undefined way. A PI lacking enterprise considering doing v6 this way either waits or decides the available space will do as someone will fix the managment later. Sixxs demonstrated that some will see a need With low take up of v6 it's early to know what they will see important > The more important it is to you that your allocation be unique, the > more careful you will be to choose a truly random one. So a way to have really unique is reasonable. > The chance that any > random prefix will conflict with any chosen prefix is very, very small. > The chance that two conflicting prefixes would belong to entities that > will ever actually interact is even smaller. People still play the lotteries. brandon From jbates at brightok.net Sat Jul 24 14:07:06 2010 From: jbates at brightok.net (Jack Bates) Date: Sat, 24 Jul 2010 14:07:06 -0500 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <1279995566.28305.375.camel@karl> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <1279995566.28305.375.camel@karl> Message-ID: <4C4B39DA.9070307@brightok.net> Karl Auer wrote: > The "random" one allows for swift, bureaucracy-free self-allocation. The > more important it is to you that your allocation be unique, the more > careful you will be to choose a truly random one. If it is that important, you'd prefer a managed solution, not a truly random one. > The chance that any > random prefix will conflict with any chosen prefix is very, very small. > The chance that two conflicting prefixes would belong to entities that > will ever actually interact is even smaller. Makes it an interesting > question as to whether the managed range is really necessary at all. 1) While the chance of conflict is small, it is not non-existent, and when the interaction does occur and a conflict does arise, there may be huge costs involved. Random is fine for small deployments. It is a horrifying prospect for a 500+ subnet network. 2) Managing non-globally routed addressing is easy and doesn't require a lot of overhead. IANA itself could manage it, as it does all other globally unique numbers. First come, first serve. Have a nice day. I enjoy my unique enterprise oid. Why shouldn't I enjoy my own unique non-globally routed address space identifier? There shouldn't be a need for justification of the identifier (or services such as whois), so pawning it off on a RIR seems silly. Jack From ipv3.com at gmail.com Sat Jul 24 14:26:15 2010 From: ipv3.com at gmail.com (IPv3.com) Date: Sat, 24 Jul 2010 14:26:15 -0500 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? Message-ID: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? As some people (who understand IPv4) know, there is a SINGLE spare/unused bit in the IPv4 header that can be set to 0 or 1. Some religions require that it be set to 0. Adult content is marked with a 1. That single bit can be viewed as common between the Source and Destination creating a 33rd bit of addressing. Since it is a single bit, it is welded together for both Source and Destination. 0-Normal 1-Evil/Other/Adult/XXX In anticipation of expanding to 33-bit addressing, another bit was deprecated years ago. It can now be used to UNWELD the EVIL bit. That would allow EVIL to be only for the Source. The Destination would have its own EVIL bit. If two bits are used, then the potential to communicate between the previously welded address spaces arises. Some enforcement could still be used in Edge Network Elements to make sure both bits are 0 or both 1. Enforcements are hard to maintain and full 33-bit addressing may emerge. As an aside, NAT was primarily added to improve the .NET Architecture with a Flash Upgrade-able Network Element. It is a shame that IPv6 salesman do not seem to understand "Architecture". They continue on the [NAT is Evil] path. NANOG can play an important role in shaping how Address Plans for North America evolve. Since Network Elements are going to be flash upgraded for the new DNS, it is easy to (unweld/change) the 33-bit addressing for .XXX The 33-bit addressing works into the 66-bit Triple-Tagged VLAN addressing with Content Rating. http://en.wikipedia.org/wiki/IEEE_802.1Q The Locator is 33-bits and the ID is 33-bits. Both are UNIQUE. Both fit in the IPv4 foot-print. The three-ring circus architecture emerges. (((Core)Edge)Fringe) does NANOG care? is NANOG now Fringe ? From morrowc.lists at gmail.com Sat Jul 24 14:40:58 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 24 Jul 2010 15:40:58 -0400 Subject: IPv4 Exhaustion... In-Reply-To: References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> Message-ID: On Sat, Jul 24, 2010 at 4:48 AM, Owen DeLong wrote: > > Rough translation: LSN + CALEA = Very Interesting Times for ISPs that deploy LSN and are subject to CALEA. why wouldn't you just do the intercept before the LSN? (also, calea and it's ilk knew this was coming, 'your failure to plan...' and all that jazz) From sking at kingrst.com Sat Jul 24 14:50:32 2010 From: sking at kingrst.com (Steven King) Date: Sat, 24 Jul 2010 15:50:32 -0400 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: References: Message-ID: <4C4B4408.3040804@kingrst.com> I am very curious to see how this would play with networks that wouldn't support such a technology. How would you ensure communication between a network that supported 33-Bit addressing and one that doesn't? On 7/24/10 3:26 PM, IPv3.com wrote: > 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? > > As some people (who understand IPv4) know, there is a SINGLE > spare/unused bit in the IPv4 header that can be set to 0 or 1. > Some religions require that it be set to 0. Adult content is marked with a 1. > > That single bit can be viewed as common between the Source and > Destination creating a 33rd bit of addressing. > Since it is a single bit, it is welded together for both Source and > Destination. 0-Normal 1-Evil/Other/Adult/XXX > > In anticipation of expanding to 33-bit addressing, another bit was > deprecated years ago. It can now be used to UNWELD > the EVIL bit. That would allow EVIL to be only for the Source. The > Destination would have its own EVIL bit. > If two bits are used, then the potential to communicate between the > previously welded address spaces arises. > Some enforcement could still be used in Edge Network Elements to make > sure both bits are 0 or both 1. > Enforcements are hard to maintain and full 33-bit addressing may emerge. > > As an aside, NAT was primarily added to improve the .NET Architecture > with a Flash Upgrade-able Network Element. > It is a shame that IPv6 salesman do not seem to understand > "Architecture". They continue on the [NAT is Evil] path. > > NANOG can play an important role in shaping how Address Plans for > North America evolve. Since Network Elements > are going to be flash upgraded for the new DNS, it is easy to (unweld/change) > the 33-bit addressing for .XXX > > The 33-bit addressing works into the 66-bit Triple-Tagged VLAN > addressing with Content Rating. > http://en.wikipedia.org/wiki/IEEE_802.1Q > The Locator is 33-bits and the ID is 33-bits. Both are UNIQUE. Both > fit in the IPv4 foot-print. > The three-ring circus architecture emerges. (((Core)Edge)Fringe) > > does NANOG care? is NANOG now Fringe ? > -- Steve King Senior Linux Engineer - Advance Internet, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional From nenolod at systeminplace.net Sat Jul 24 15:17:47 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Sat, 24 Jul 2010 15:17:47 -0500 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: <4C4B4408.3040804@kingrst.com> References: <4C4B4408.3040804@kingrst.com> Message-ID: <1280002667.12383.2.camel@petrie> On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote: > I am very curious to see how this would play with networks that > wouldn't support such a technology. How would you ensure communication > between a network that supported 33-Bit addressing and one that doesn't? 33-bit is a fucking retarded choice for any addressing scheme as it's neither byte nor nibble-aligned. Infact, the 33rd bit would ensure that an IPv4 header had to have 5 byte addresses. William From morrowc.lists at gmail.com Sat Jul 24 15:23:12 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 24 Jul 2010 16:23:12 -0400 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: <1280002667.12383.2.camel@petrie> References: <4C4B4408.3040804@kingrst.com> <1280002667.12383.2.camel@petrie> Message-ID: isn't ipv3.com at gmail.com jim fleming? (for reference) pls to not be replying to the list when ipv3.com posts to nanog.. -Chris On Sat, Jul 24, 2010 at 4:17 PM, William Pitcock wrote: > On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote: >> I am very curious to see how this would play with networks that >> wouldn't support such a technology. How would you ensure communication >> between a network that supported 33-Bit addressing and one that doesn't? > > 33-bit is a fucking retarded choice for any addressing scheme as it's > neither byte nor nibble-aligned. ?Infact, the 33rd bit would ensure that > an IPv4 header had to have 5 byte addresses. > > William > > > > From Valdis.Kletnieks at vt.edu Sat Jul 24 15:22:49 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 24 Jul 2010 16:22:49 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: Your message of "Sat, 24 Jul 2010 18:49:55 BST." <201007241749.SAA14213@sunf10.rd.bbc.co.uk> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> Message-ID: <100948.1280002969@localhost> On Sat, 24 Jul 2010 18:49:55 BST, Brandon Butterworth said: > The RFC seeks to avoid a registry so we end up with the potential for > many as a result. May as well have had ARIN do it officially in the > first place so there'd only be one. Given our failure rate with registries of AS numbers, IP address blocks, and routing table entries, and the fact we have no special reason to believe that we'll be able to sprinkle Magic ULA Dust all over it and avoid all the failure modes of registries, we're probably better off just randomly generating them and just hope for no collisions. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Sat Jul 24 15:28:32 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 24 Jul 2010 16:28:32 -0400 Subject: IPv4 Exhaustion... In-Reply-To: Your message of "Sat, 24 Jul 2010 15:40:58 EDT." References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> Message-ID: <101106.1280003312@localhost> On Sat, 24 Jul 2010 15:40:58 EDT, Christopher Morrow said: > why wouldn't you just do the intercept before the LSN? That gets interesting too, when several tens of thousands of users may all be behind the same LSN. Making sure you intercept only the right user's traffic gets a lot more interesting in front of the LSN. Doing it behind the LSN means you can snarf up just the traffic heading to/from one NAT'ed IP, which is hopefully changing not all that often. Doing it in front of the LSN means you need to decide whether to capture the data in real time on a per-flow basis (consider the fun involved in catching a SYN packet outbound - what's your time budget between when the miscreant's packet leaves his host and when you have to catch it on the outbound side of the LSN)... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From morrowc.lists at gmail.com Sat Jul 24 15:36:08 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 24 Jul 2010 16:36:08 -0400 Subject: IPv4 Exhaustion... In-Reply-To: <101106.1280003312@localhost> References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> <101106.1280003312@localhost> Message-ID: On Sat, Jul 24, 2010 at 4:28 PM, wrote: > On Sat, 24 Jul 2010 15:40:58 EDT, Christopher Morrow said: >> why wouldn't you just do the intercept before the LSN? > > That gets interesting too, when several tens of thousands of users may all be > behind the same LSN. ?Making sure you intercept only the right user's traffic > gets a lot more interesting in front of the LSN. ?Doing it behind the LSN means > you can snarf up just the traffic heading to/from one NAT'ed IP, which is > hopefully changing not all that often. ?Doing it in front of the LSN means you > need to decide whether to capture the data in real time on a per-flow basis > (consider the fun involved in catching a SYN packet outbound - what's your time > budget between when the miscreant's packet leaves his host and when you have to > catch it on the outbound side of the LSN)... innocent until proven guilty... plus probably a large portion of the calea things aren't for a 'miscreant' anyway but for other reasons. say, i wonder how many actual calea requests have been sent out anyway?? (I know one very large network has yet to get a single one, or so the grape vine tells me.) > > From andrew.wallace at rocketmail.com Sat Jul 24 16:22:56 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 24 Jul 2010 14:22:56 -0700 (PDT) Subject: North Korea conflict with US and South Korea could spark cyber war Message-ID: <128780.52289.qm@web59616.mail.ac4.yahoo.com> n3td3v Security is monitoring the situation between North Korea, US and South Korea. North Korea has already threatened to use its nuclear arms when the "wargames" begin Sunday by United States and South Korea, but n3td3v Security predicts North Korea is planning a large scale cyber attack on US interests. We could really see the first cyber war proper here when it all kicks off Sunday between US, S.Korea and the North. n3td3v Security is warning critical infrastructure utility companies to keep an eye on its cyber assets incase NK's cyber command launch any attack. Andrew Wallace http://sites.google.com/site/n3td3v/ From owen at delong.com Sat Jul 24 16:58:29 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Jul 2010 14:58:29 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <201007241841.TAA18787@sunf10.rd.bbc.co.uk> References: <201007241841.TAA18787@sunf10.rd.bbc.co.uk> Message-ID: <171C149E-8AFB-4F62-8A3F-042E63A695F1@delong.com> On Jul 24, 2010, at 11:41 AM, Brandon Butterworth wrote: >> The RFC provides for two address ranges in fc00::/7, one for random >> prefixes (fc00::/8), the other reserved for later management (fd00::/8). > > Later, in some undefined way. A PI lacking enterprise considering > doing v6 this way either waits or decides the available space will do > as someone will fix the managment later. Sixxs demonstrated that some > will see a need > Or they forego the kludge and go with PA v6 realizing that they can do overlapping PA v6 transitions with relative ease when they switch providers. Of course during that time of overlap, they are technically multi-homed, so, there are other options as well. > With low take up of v6 it's early to know what they will see important > Yep. Enterprises are really the least of the concerns right now as well. We have about a year, maybe less to try and get public-facing stuff dual-stacked. We have lots of time yet to address the enterprise issues. >> The more important it is to you that your allocation be unique, the >> more careful you will be to choose a truly random one. > > So a way to have really unique is reasonable. > I think the simplest approach is simply to multihome and get a PI assignment if you don't want to live with PA. That's the cleanest approach too with the added benefit that you can load-balance and gain some redundancy and other optimizations in the process. >> The chance that any >> random prefix will conflict with any chosen prefix is very, very small. >> The chance that two conflicting prefixes would belong to entities that >> will ever actually interact is even smaller. > > People still play the lotteries. > My favorite definition of the term Lottery is: Lottery (n): A tax on people who are bad at math. Owen From jwbensley at gmail.com Sat Jul 24 17:49:28 2010 From: jwbensley at gmail.com (James Bensley) Date: Sat, 24 Jul 2010 23:49:28 +0100 Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <128780.52289.qm@web59616.mail.ac4.yahoo.com> References: <128780.52289.qm@web59616.mail.ac4.yahoo.com> Message-ID: I cant check that link out right now, but if what you say is true, this would be very serious. Can anyone confirm this? On 7/24/10, andrew.wallace wrote: > n3td3v Security is monitoring the situation between North Korea, US and > South > Korea. > > North Korea has already threatened to use its nuclear arms when the > "wargames" > begin Sunday by United States and South Korea, but n3td3v Security predicts > North Korea is planning a large scale cyber attack on US interests. > > We could really see the first cyber war proper here when it all kicks off > Sunday > between US, S.Korea and the North. > > n3td3v Security is warning critical infrastructure utility companies to keep > an > eye on its cyber assets incase NK's cyber command launch any attack. > > Andrew Wallace > > http://sites.google.com/site/n3td3v/ > > > > > > > -- Sent from my mobile device Regards, James. http://www.jamesbensley.co.cc/ There are 10 kinds of people in the world; Those who understand Vigesimal, and J others...? From trelane at trelane.net Sat Jul 24 18:33:07 2010 From: trelane at trelane.net (Andrew Kirch) Date: Sat, 24 Jul 2010 19:33:07 -0400 Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: References: <128780.52289.qm@web59616.mail.ac4.yahoo.com> Message-ID: <4C4B7833.4010003@trelane.net> James, 1. cyberwar is bullsh*t, always has been, always will be. 2. we are risking a "cyberwar" (which is, as previously mentioned, bullsh*t) with North Korea which can't even feed itself, let alone buy things like computers, or real internet access. So, yes you can knock out root name servers for a few hours, it has been done by the way, and only people on this list really noticed. The tactical loss of those name servers won't slow down the components of the US military which are now bombing your country. With this point we get to why cyberwar is bullsh*t. Bombs blow stuff up, soldiers shoot and kill people, tanks blow stuff up, big ships with huge cannons blow stuff up. This sort of stuff has to be rebuilt. Launching a crippling internet attack slow down the flow of e-mail, and while this might make our day a bit harder if the blackberry doesn't beep happily every minute and a half, in comparison to bombing, or getting shot, or blown up, or shelled by battleships, e-mail is pretty insignificant. Andrew On 7/24/2010 6:49 PM, James Bensley wrote: > I cant check that link out right now, but if what you say is true, > this would be very serious. Can anyone confirm this? > > On 7/24/10, andrew.wallace wrote: >> n3td3v Security is monitoring the situation between North Korea, US and >> South >> Korea. >> >> North Korea has already threatened to use its nuclear arms when the >> "wargames" >> begin Sunday by United States and South Korea, but n3td3v Security predicts >> North Korea is planning a large scale cyber attack on US interests. >> >> We could really see the first cyber war proper here when it all kicks off >> Sunday >> between US, S.Korea and the North. >> >> n3td3v Security is warning critical infrastructure utility companies to keep >> an >> eye on its cyber assets incase NK's cyber command launch any attack. >> >> Andrew Wallace >> >> http://sites.google.com/site/n3td3v/ >> >> >> >> >> >> >> From mksmith at adhost.com Sat Jul 24 18:41:47 2010 From: mksmith at adhost.com (Michael K. Smith) Date: Sat, 24 Jul 2010 16:41:47 -0700 Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: Message-ID: On 7/24/10 3:49 PM, "James Bensley" wrote: > I cant check that link out right now, but if what you say is true, > this would be very serious. Can anyone confirm this? > The North Koreans have historically threatened to go to war whenever the US and South Korea are performing military exercises in the region. I have no idea how the threat of nuclear conflict equates to a cyber attack. Perhaps n3td3v would like to provide something a little more concrete about the origin of their prediction. Mike From ryan at u13.net Sat Jul 24 18:44:53 2010 From: ryan at u13.net (Ryan Rawdon) Date: Sat, 24 Jul 2010 19:44:53 -0400 Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <128780.52289.qm@web59616.mail.ac4.yahoo.com> References: <128780.52289.qm@web59616.mail.ac4.yahoo.com> Message-ID: <2a593abfbb20cfedf96a41e6326889cc@192.168.152.50> On Sat, 24 Jul 2010 14:22:56 -0700 (PDT), "andrew.wallace" wrote: > n3td3v Security is monitoring the situation between North Korea, US and > South > Korea. > > North Korea has already threatened to use its nuclear arms when the > "wargames" > begin Sunday by United States and South Korea, but n3td3v Security > predicts > North Korea is planning a large scale cyber attack on US interests. > > We could really see the first cyber war proper here when it all kicks off > Sunday > between US, S.Korea and the North. > > n3td3v Security is warning critical infrastructure utility companies to > keep an > eye on its cyber assets incase NK's cyber command launch any attack. > > Andrew Wallace > > http://sites.google.com/site/n3td3v/ Can you provide information to back this up? At first glance glance I am having a hard time believing this is anything but speculation, but would be interested to hear more. From trelane at trelane.net Sat Jul 24 18:46:28 2010 From: trelane at trelane.net (Andrew Kirch) Date: Sat, 24 Jul 2010 19:46:28 -0400 Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <2a593abfbb20cfedf96a41e6326889cc@192.168.152.50> References: <128780.52289.qm@web59616.mail.ac4.yahoo.com> <2a593abfbb20cfedf96a41e6326889cc@192.168.152.50> Message-ID: <4C4B7B54.1020905@trelane.net> On 7/24/2010 7:44 PM, Ryan Rawdon wrote: > Can you provide information to back this up? At first glance glance I am > having a hard time believing this is anything but speculation, but would be > interested to hear more. > That is because n3td3v is a troll. Please do not feed, thx. Andrew From Chrisf at apcon.com Sat Jul 24 19:10:47 2010 From: Chrisf at apcon.com (Chris Fenton) Date: Sun, 25 Jul 2010 00:10:47 +0000 Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <2a593abfbb20cfedf96a41e6326889cc@192.168.152.50> References: <128780.52289.qm@web59616.mail.ac4.yahoo.com> <2a593abfbb20cfedf96a41e6326889cc@192.168.152.50> Message-ID: <8923BDAA-1306-4B7F-8FEB-71497A3B6109@apcon.com> Maybe we should check snopes.com. Haha. Excuse the spelling/punctuation, this is sent from my mobile device... ChrisFenton On Jul 24, 2010, at 4:46 PM, "Ryan Rawdon" wrote: > > > > On Sat, 24 Jul 2010 14:22:56 -0700 (PDT), "andrew.wallace" > wrote: >> n3td3v Security is monitoring the situation between North Korea, US >> and >> South >> Korea. >> >> North Korea has already threatened to use its nuclear arms when the >> "wargames" >> begin Sunday by United States and South Korea, but n3td3v Security >> predicts >> North Korea is planning a large scale cyber attack on US interests. >> >> We could really see the first cyber war proper here when it all kicks > off >> Sunday >> between US, S.Korea and the North. >> >> n3td3v Security is warning critical infrastructure utility >> companies to >> keep an >> eye on its cyber assets incase NK's cyber command launch any attack. >> >> Andrew Wallace >> >> http://sites.google.com/site/n3td3v/ > > Can you provide information to back this up? At first glance glance > I am > having a hard time believing this is anything but speculation, but > would be > interested to hear more. > From kauer at biplane.com.au Sat Jul 24 19:42:03 2010 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 25 Jul 2010 10:42:03 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C4B39DA.9070307@brightok.net> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <1279995566.28305.375.camel@karl> <4C4B39DA.9070307@brightok.net> Message-ID: <1280018523.28305.467.camel@karl> On Sat, 2010-07-24 at 14:07 -0500, Jack Bates wrote: > > The chance that any > > random prefix will conflict with any chosen prefix is very, very small. > > The chance that two conflicting prefixes would belong to entities that > > will ever actually interact is even smaller. Makes it an interesting > > question as to whether the managed range is really necessary at all. > > 1) While the chance of conflict is small, it is not non-existent, and > when the interaction does occur and a conflict does arise, there may be > huge costs involved. Random is fine for small deployments. It is a > horrifying prospect for a 500+ subnet network. If two (or four, or ten, or a thousand) ULA prefixes are chosen randomly, the chance that any will conflict with any others is far, far less than the chance that your staff will make a terrible, disastrous mistake that puts you out of commission for weeks. And if you happen to have contingency plans for that, they will do just fine for dealing with a ULA conflict.[1] And of course, to be an actual problem the conflicting prefixes have to be in use by entities whose networks actually interact. Within an administrative domain, uniqueness can be guaranteed anyway. Winning a lottery is *far* more likely[2] than that a randomly chosen prefix from the ULA range will conflict with any other prefix in the same range, randomly chosen or not. Regards, K. [1] A ULA conflict is generally not going to require instant remedial action. People planning interaction at a network level will (one hopes!) do basic stuff like checking what prefixes are in use on the two networks. [2] Depending on the number of "players" in each "game", anything from hundreds of times more likely to millions of times more likely. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From trelane at trelane.net Sat Jul 24 19:44:18 2010 From: trelane at trelane.net (Andrew Kirch) Date: Sat, 24 Jul 2010 20:44:18 -0400 Subject: Fwd: Re: North Korea conflict with US and South Korea could spark cyber war Message-ID: <4C4B88E2.2060600@trelane.net> -------- Original Message -------- Subject: Re: North Korea conflict with US and South Korea could spark cyber war Date: Sat, 24 Jul 2010 17:04:23 -0700 (PDT) From: andrew.wallace To: Andrew Kirch Continue to call me a troll in public and I'll be seeking legal advice. ----- Original Message ---- From: Andrew Kirch To: nanog at nanog.org Sent: Sun, 25 July, 2010 0:46:28 Subject: Re: North Korea conflict with US and South Korea could spark cyber war That is because n3td3v is a troll. Please do not feed, thx. Andrew QED. From khatfield at socllc.net Sat Jul 24 19:46:28 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Sun, 25 Jul 2010 00:46:28 +0000 Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <8923BDAA-1306-4B7F-8FEB-71497A3B6109@apcon.com> References: <128780.52289.qm@web59616.mail.ac4.yahoo.com><2a593abfbb20cfedf96a41e6326889cc@192.168.152.50><8923BDAA-1306-4B7F-8FEB-71497A3B6109@apcon.com> Message-ID: <347600614-1280018789-cardhu_decombobulator_blackberry.rim.net-73637446-@bda903.bisx.prod.on.blackberry> /agree Looks like a stunt to drive traffic to his blog unless he actually has something to back this up. Mr. Wallace: I think I speak for a majority of the members on this list when I say that we are busy enough dealing with real business. Please do not sacrifice the professionalism of this list for baseless predictions or PR. -----Original Message----- From: Chris Fenton Date: Sun, 25 Jul 2010 00:10:47 To: Ryan Rawdon Cc: nanog at nanog.org Subject: Re: North Korea conflict with US and South Korea could spark cyber war Maybe we should check snopes.com. Haha. Excuse the spelling/punctuation, this is sent from my mobile device... ChrisFenton On Jul 24, 2010, at 4:46 PM, "Ryan Rawdon" wrote: > > > > On Sat, 24 Jul 2010 14:22:56 -0700 (PDT), "andrew.wallace" > wrote: >> n3td3v Security is monitoring the situation between North Korea, US >> and >> South >> Korea. >> >> North Korea has already threatened to use its nuclear arms when the >> "wargames" >> begin Sunday by United States and South Korea, but n3td3v Security >> predicts >> North Korea is planning a large scale cyber attack on US interests. >> >> We could really see the first cyber war proper here when it all kicks > off >> Sunday >> between US, S.Korea and the North. >> >> n3td3v Security is warning critical infrastructure utility >> companies to >> keep an >> eye on its cyber assets incase NK's cyber command launch any attack. >> >> Andrew Wallace >> >> http://sites.google.com/site/n3td3v/ > > Can you provide information to back this up? At first glance glance > I am > having a hard time believing this is anything but speculation, but > would be > interested to hear more. > From shrdlu at deaddrop.org Sat Jul 24 19:50:15 2010 From: shrdlu at deaddrop.org (Shrdlu) Date: Sat, 24 Jul 2010 17:50:15 -0700 Subject: Fwd: Re: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <4C4B88E2.2060600@trelane.net> References: <4C4B88E2.2060600@trelane.net> Message-ID: <4C4B8A47.9080109@deaddrop.org> Normally, I wouldn't top post, but in just this one instance... Andrew Wallace, aka n3td3v, and one of the few people to EVER be banned from Full Disclosure, is a troll. Please don't copy his message back when you reply to him, since most of us long ago dropped him in the kill file. Everywhere. Legal advice. Hah. Could this now please end? On 7/24/2010 5:44 PM, Andrew Kirch wrote: > > -------- Original Message -------- > Subject: Re: North Korea conflict with US and South Korea could spark > cyber war > Date: Sat, 24 Jul 2010 17:04:23 -0700 (PDT) > From: andrew.wallace > To: Andrew Kirch > Continue to call me a troll in public and I'll be seeking legal advice. > ----- Original Message ---- > From: Andrew Kirch > To: nanog at nanog.org > Sent: Sun, 25 July, 2010 0:46:28 > Subject: Re: North Korea conflict with US and South Korea could spark > cyber war > > That is because n3td3v is a troll. Please do not feed, thx. -- Injustice is relatively easy to bear; what stings is justice. H.L. Mencken From streiner at cluebyfour.org Sat Jul 24 16:10:40 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sat, 24 Jul 2010 17:10:40 -0400 (EDT) Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <4C4B7B54.1020905@trelane.net> References: <128780.52289.qm@web59616.mail.ac4.yahoo.com> <2a593abfbb20cfedf96a41e6326889cc@192.168.152.50> <4C4B7B54.1020905@trelane.net> Message-ID: On Sat, 24 Jul 2010, Andrew Kirch wrote: > On 7/24/2010 7:44 PM, Ryan Rawdon wrote: >> Can you provide information to back this up? At first glance glance I am >> having a hard time believing this is anything but speculation, but would >> be >> interested to hear more. >> > That is because n3td3v is a troll. Please do not feed, thx. It does indeed seem to be tool/net.kook day here on NANOG. I didn't check to see if there is supposed to be a full moon tonight. jms From trelane at trelane.net Sat Jul 24 20:16:25 2010 From: trelane at trelane.net (Andrew Kirch) Date: Sat, 24 Jul 2010 21:16:25 -0400 Subject: Fwd: Re: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <4C4B88E2.2060600@trelane.net> References: <4C4B88E2.2060600@trelane.net> Message-ID: <4C4B9069.7050004@trelane.net> I'd request that anyone with evidence that Andrew Wallace had inappropriate contact with a minor male child in 1999, please contact me off-list. Thanks, and this will be my last response to anything regarding Mr. Wallace publicly as I'll no longer be seeing much of him. Andrew From r.engehausen at gmail.com Sat Jul 24 20:23:19 2010 From: r.engehausen at gmail.com (Roy) Date: Sat, 24 Jul 2010 18:23:19 -0700 Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: References: <128780.52289.qm@web59616.mail.ac4.yahoo.com> <2a593abfbb20cfedf96a41e6326889cc@192.168.152.50> <4C4B7B54.1020905@trelane.net> Message-ID: <4C4B9207.9060606@gmail.com> On 7/24/2010 2:10 PM, Justin M. Streiner wrote: > ... > It does indeed seem to be tool/net.kook day here on NANOG. I didn't > check to see if there is supposed to be a full moon tonight. > > jms > > Close! Full Moon on 25 July 2010 at 9:37 p.m. Eastern Daylight Time. From andrew.wallace at rocketmail.com Sat Jul 24 20:28:23 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sat, 24 Jul 2010 18:28:23 -0700 (PDT) Subject: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <4C4B9207.9060606@gmail.com> References: <128780.52289.qm@web59616.mail.ac4.yahoo.com> <2a593abfbb20cfedf96a41e6326889cc@192.168.152.50> <4C4B7B54.1020905@trelane.net> <4C4B9207.9060606@gmail.com> Message-ID: <392084.98953.qm@web59604.mail.ac4.yahoo.com> On Sun, Jul 25, 2010 at 2:23 AM, Roy wrote: > On 7/24/2010 2:10 PM, Justin M. Streiner wrote: >> >> ... >> It does indeed seem to be tool/net.kook day here on NANOG. I didn't check >> to see if there is supposed to be a full moon tonight. >> >> jms >> >> > > Close! Full Moon on 25 July 2010 at 9:37 p.m. Eastern Daylight Time. > > They should be banned from Nanog, the rules state: "Postings that include foul language, character assassination, and lack of respect for other participants are prohibited." http://nanog.org/mailinglist/ Andrew Wallace From drc at virtualized.org Sat Jul 24 21:27:34 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 25 Jul 2010 04:27:34 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <201007241752.SAA14419@sunf10.rd.bbc.co.uk> References: <201007241752.SAA14419@sunf10.rd.bbc.co.uk> Message-ID: <310B8CAA-FB09-48E1-B544-F5D010551BF0@virtualized.org> On Jul 24, 2010, at 7:52 PM, Brandon Butterworth wrote: >>> Such a site would be the seed for when (if) we come up with the tech >>> for everyone to have PI and lose all the restrictions imposed so far. >> Oh, we have the technology. It's called "memory" > If that were viable then we'd be doing it. We are. I'm told that the fully outfitted top-end routers from Cisco and Juniper can handle tens of millions of routes (as long as you're not in a rush to converge and you have lots of cheap power). Of course, the price of said routers is a bit steep, particularly for smaller ISPs and enterprises, so you'll see a shift in the way the Internet works (perhaps not surprisingly, back towards the way telco networks look with a small number of very large companies). >> Speaking from the perspective of a vendor, I'll happily sell it to you. >> >> Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours. > > Indeed, best not listen to vendors As it is best not to listen to doctors that tell you if you continue chain smoking or eating 5000 calories a day, you'll likely regret it. Regards, -drc From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jul 24 22:25:14 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 25 Jul 2010 12:55:14 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <201007241640.RAA07071@sunf10.rd.bbc.co.uk> Message-ID: <20100725125514.191f4bbb@opy.nosense.org> On Sat, 24 Jul 2010 10:57:49 -0700 Owen DeLong wrote: > > On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote: > > >>> Enterprises of non-trivial size will likely use RFC4193 (and I > >>> fear we will notice PRNG returning 0 very often) and then NAT it to > >>> provider provided public IP addresses. > > > > Eventually ARIN (or someone else will do it for them) may create a site > > you can register your address and know that it really is unique > > among participating registrants. Random is fine, unique is better. > > > > Such a site would be the seed for when (if) we come up with the tech > > for everyone to have PI and lose all the restrictions imposed so far. > > > SIXXS already has such a registry with a pretty low adoption rate. > And I think that is good news. The fd00::/8 range is not defined as guaranteed globally unique. I'm concerned that the SIXXS registry could imply to those people who have used it, that it is. They may think that because that registry exists, and that they've used it, that address space it now theirs, and nobody else is allowed to use it. Once somebody perceives ownership of something they believe is unique, I think they commonly won't listen to reason about their actual lack of global ownership. fc00::/8 is for guaranteed globally unique ULAs. > I still fail to see any advantage whatsoever to this approach and I think > that the limited number of sites that implement it is unlikely to get > continued support from ISVs. > > >>> I'm just hoping that we'll at least > >>> see 1:1 NAT instead of NAPT being used. > > > > I think that will be a common PI alternative. If people really don't > > want NAT then we shouldn't provide reasons for it to exist. > > > > RFC4193 seems to be the best enterprise plan. They can link to other > > enterprises and change ISPs easily or multihome. They are not beholden > > to any ISP or numbering authority. The global table doesn't explode. > > > I agree that easier to get PI addresses is a better alternative. I will support > policy initiatives to do that. RFC4193 remains an utterly horrible idea > and NATing it to the public internet remains even worse. > Well I think RFC4193 is a great idea. I don't want my home network addressing to be bound to having a commercial arrangement with an ISP, or having an active Internet connection. I can also use the ULA prefix as a simple designator of trusted verses untrusted traffic sources in firewall rules. I see those advantages equally applicable to enterprise or ISP networks. Then again, I'm happy with the idea of multiple addresses on an interface, and source address selection. They're not much different to those issues in IPv4, such as unnumbered interfaces on routers, designated source addresses for router SNMP traps etc., or source address selection for policy routing. > >> Why on earth would you do that? Why not just put the provider-assigned > >> addresses on the interfaces along side the ULA addresses? Using ULA > >> in that manner is horribly kludgy and utterly unnecessary. > > > > Enterprises tend to want only one identifier to manage per device and > > that it be unique and mostly permanent. > > That's IPv4 thinking showing though. People fundamentally don't want change when they don't know of or understand the benefits they will gain. ULAs are an overhead, but they also provide benefits that can't be achieved with global address space assigned by an ISP. (I don't accept the PI argument, because it isn't feasible for residential networks). > Right... That identifier is the EUI-64 which is both permanent and unique. > The prefix changes when you switch providers, but, that's mostly not > particularly horrible since there are tools to make that easier for the > bulk of internal hosts. > > > With several PA and ULA on each device, links to ISPs and other > > enterprises, the combinations of addresses and paths to manage flows > > and security over become too hard (if it's not simple it's probably not > > secure). Every device becomes a router and firewall and the staff who > > manage those aren't cheap. > > > Actually, if you set things up correctly, most of the security stuff to manage > is about the same because you hairpin the stuff that doesn't need filtration > at a point before it hits the packet filters. > > >>> This is to facilitate easy and cheap way to change provider. Getting PI > >>> address is even harder now, as at least RIPE will verify that you are > >>> multihomed, while many enterprises don't intent to be, they just need low > >>> cost ability to change operator. > >>> > >> Why is that easier/cheaper than changing your RAs to the new provider and > >> letting the old provider addresses time out? > > > > And changing all the ACLs based on the old providers addresses > > > Mostly this is a pretty straight forward copy->search->replace > problem with prefix changes that can be done with the equivalent > of an s/x/y/g construct. > > > And allowing for all the 5 - 15 year old kit that predates this and > > won't be upgraded (we have that problem with NT embedded in systems > > with 10year+ refresh cycle) > > > That kit won't support IPv6, so, I fail to see the relevance. Any kit that supports > IPv6 supports this. > > Owen > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Jul 24 22:29:02 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 25 Jul 2010 12:59:02 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <201007241841.TAA18787@sunf10.rd.bbc.co.uk> References: <201007241841.TAA18787@sunf10.rd.bbc.co.uk> Message-ID: <20100725125902.393cf010@opy.nosense.org> On Sat, 24 Jul 2010 19:41:18 +0100 (BST) Brandon Butterworth wrote: > > The RFC provides for two address ranges in fc00::/7, one for random > > prefixes (fc00::/8), the other reserved for later management (fd00::/8). > > Later, in some undefined way. A PI lacking enterprise considering > doing v6 this way either waits or decides the available space will do > as someone will fix the managment later. Sixxs demonstrated that some > will see a need > > With low take up of v6 it's early to know what they will see important > > > The more important it is to you that your allocation be unique, the > > more careful you will be to choose a truly random one. > > So a way to have really unique is reasonable. > > > The chance that any > > random prefix will conflict with any chosen prefix is very, very small. > > The chance that two conflicting prefixes would belong to entities that > > will ever actually interact is even smaller. > > People still play the lotteries. > And those people, and some others by the looks of it, don't appear to understand statistics and chance ... > brandon > > > > From dougb at dougbarton.us Sun Jul 25 00:35:07 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sat, 24 Jul 2010 22:35:07 -0700 (PDT) Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> Message-ID: On Sat, 24 Jul 2010, Brandon Butterworth wrote: >>> Eventually ARIN (or someone else will do it for them) may create a site > ... >> Did you mean something like this maybe ?: >> >> http://www.sixxs.net/tools/grh/ula/ > > Q.E.D. > > The RFC seeks to avoid a registry so we end up with the potential for > many as a result. May as well have had ARIN do it officially in the > first place so there'd only be one. So, back when ULA was first proposed, some of us said (sometimes privately) that there are only 2 rational options: 1. Do it; with a persistent, guaranteed unique, global registry. 2. Don't do it. Option 2 was a non-starter since there was too much critical mass. The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) So given the overwhelming force pulling at this thing from both directions, you end up somewhere in the middle where no one wants to be. And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owen at delong.com Sun Jul 25 01:10:52 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 24 Jul 2010 23:10:52 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> Message-ID: <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> On Jul 24, 2010, at 10:35 PM, Doug Barton wrote: > On Sat, 24 Jul 2010, Brandon Butterworth wrote: > >>>> Eventually ARIN (or someone else will do it for them) may create a site >> ... >>> Did you mean something like this maybe ?: >>> >>> http://www.sixxs.net/tools/grh/ula/ >> >> Q.E.D. >> >> The RFC seeks to avoid a registry so we end up with the potential for >> many as a result. May as well have had ARIN do it officially in the >> first place so there'd only be one. > > So, back when ULA was first proposed, some of us said (sometimes privately) that there are only 2 rational options: > 1. Do it; with a persistent, guaranteed unique, global registry. > 2. Don't do it. > > Option 2 was a non-starter since there was too much critical mass. The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) > For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it? > So given the overwhelming force pulling at this thing from both directions, you end up somewhere in the middle where no one wants to be. > > And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins. > Except in the case of ULA, hitting the jackpot is actually losing. Owen From drc at virtualized.org Sun Jul 25 01:40:46 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 25 Jul 2010 08:40:46 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> Message-ID: On Jul 25, 2010, at 8:10 AM, Owen DeLong wrote: >> The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) > For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it? None of the "sides of IANA" pay for anything. There is no binding between what parties pay and what the ICANN staff who perform the IANA function do. In fact, those staff do not have any knowledge of whether any organization has paid anything (other than what they might hear incidentally). The (zero dollar) IANA functions contract has 3 major functions, of which allocating blocks of addresses to the RIRs (and at the direction of the IETF) is one. Failure to perform that function would be interpreted as breach of contract, regardless of whether the RIRs pay anything to ICANN or not. Regards, -drc From jbates at brightok.net Sun Jul 25 01:42:44 2010 From: jbates at brightok.net (Jack Bates) Date: Sun, 25 Jul 2010 01:42:44 -0500 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> Message-ID: <4C4BDCE4.7040009@brightok.net> Doug Barton wrote: > having none of that. (For bonus points, explain how the RIRs continue to > exist if everyone can have all of the guaranteed-globally-unique IPv6 > space they wanted for free.) whois. what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2. > > And BTW, the lottery is actually the perfect analogy for ULA, since no > matter how astronomical the odds against, eventually someone always wins. > This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad. From jbates at brightok.net Sun Jul 25 01:56:53 2010 From: jbates at brightok.net (Jack Bates) Date: Sun, 25 Jul 2010 01:56:53 -0500 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <310B8CAA-FB09-48E1-B544-F5D010551BF0@virtualized.org> References: <201007241752.SAA14419@sunf10.rd.bbc.co.uk> <310B8CAA-FB09-48E1-B544-F5D010551BF0@virtualized.org> Message-ID: <4C4BE035.6080903@brightok.net> David Conrad wrote: > On Jul 24, 2010, at 7:52 PM, Brandon Butterworth wrote: >> Indeed, best not listen to vendors > > As it is best not to listen to doctors that tell you if you continue chain smoking or eating 5000 calories a day, you'll likely regret it. > Bad analogy. A doctor tells you these things for your well being. In fact, the doctor's advice, while meeting the goals of his oath, conflict with his business needs (your regret of not following his advice will be lots more doctor bills). Vendors care about their bottom line. Some will happily lie for a sale. Most will highlight their strong points and gloss over their weaknesses. More care goes to those who pay the most. An engineer is closer to a doctor. The engineer cares about the health of their network and how well it performs, even if it means begging for more expensive gear from management. The engineer is less concerned with the bottom line and more concerned with doing things right (especially if it means less work, less headaches, and less problems for the same amount of pay). I rant OT too much. :) Jack From drc at virtualized.org Sun Jul 25 02:01:33 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 25 Jul 2010 09:01:33 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C4BDCE4.7040009@brightok.net> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> Message-ID: On Jul 25, 2010, at 8:42 AM, Jack Bates wrote: > Doug Barton wrote: >> having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) > whois. http://whois.iana.org > what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). With the exception of a routing registry (which I wasn't aware was an address allocation requirement), these services are provided by ICANN as part of the IANA functions contract. Out of curiosity, why do you think providing whois, POC management/validity, and even a routing registry requires a large staff? > I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2. As you note, ICANN already provides something like this as part of the protocol parameter function of the IANA functions contract for private enterprise numbers (OIDs). > This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. I remember arguments like that about why Token Ring was going to win over Ethernet :-) > Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad. Indeed. I have stories... Regards, -drc (who no longer works for ICANN) From drc at virtualized.org Sun Jul 25 02:12:24 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 25 Jul 2010 09:12:24 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C4BE035.6080903@brightok.net> References: <201007241752.SAA14419@sunf10.rd.bbc.co.uk> <310B8CAA-FB09-48E1-B544-F5D010551BF0@virtualized.org> <4C4BE035.6080903@brightok.net> Message-ID: <8E48DCFE-B63C-4836-8484-A104AE62A4E1@virtualized.org> On Jul 25, 2010, at 8:56 AM, Jack Bates wrote: > David Conrad wrote: >> On Jul 24, 2010, at 7:52 PM, Brandon Butterworth wrote: >>> Indeed, best not listen to vendors >> As it is best not to listen to doctors that tell you if you continue chain smoking or eating 5000 calories a day, you'll likely regret it. > > Bad analogy. A doctor tells you these things for your well being. In fact, the doctor's advice, while meeting the goals of his oath, conflict with his business needs (your regret of not following his advice will be lots more doctor bills). I'll stick by the analogy. There are engineers inside routing vendors who have been quite loud in saying that we can't keep adding more routes to the routing system and expect costs to remain linear. Those same engineers will also tell you that the companies they work for will be happy to build what the customer wants, even if it will cost the customer 3 arms and 4 legs. > Vendors care about their bottom line. Some will happily lie for a sale. Most will highlight their strong points and gloss over their weaknesses. More care goes to those who pay the most. Which, according to numerous studies, also describes the health care system in the US, but that's not an appropriate topic for this list. > An engineer is closer to a doctor. The engineer cares about the health of their network and how well it performs, even if it means begging for more expensive gear from management. The engineer is less concerned with the bottom line and more concerned with doing things right (especially if it means less work, less headaches, and less problems for the same amount of pay). All vendors that expect to remain in business for any length of time have engineering staff that behave as you describe. For just one example, look at the folks behind LISP (not the language). Or the active participants in the IRTF RRG working group. Regards, -drc From randy at psg.com Sun Jul 25 02:13:25 2010 From: randy at psg.com (Randy Bush) Date: Sun, 25 Jul 2010 09:13:25 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C4BDCE4.7040009@brightok.net> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> Message-ID: > whois. what did I win? IANA can handle very basic assignments, but > hasn't the staff for large support or extra services (whois, POC > management/validity, routing registry). routing registry not necessarily needed from address registry. and i am sure even the icann/iana could do the combined rir work for half the combined rir budgets, especially with the insane budgets of the more inflated rirs. randy From dougb at dougbarton.us Sun Jul 25 02:18:04 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 25 Jul 2010 00:18:04 -0700 (PDT) Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C4BDCE4.7040009@brightok.net> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> Message-ID: On Sun, 25 Jul 2010, Jack Bates wrote: > Doug Barton wrote: >> having none of that. (For bonus points, explain how the RIRs continue to >> exist if everyone can have all of the guaranteed-globally-unique IPv6 space >> they wanted for free.) > > whois. what did I win? IANA can handle very basic assignments, but hasn't the > staff for large support or extra services (whois, POC management/validity, > routing registry). I think IANA would be perfect for ULA identifier > assignments. No whois/poc/routing registry needed. Send email, get an > identifier in a week or 2. You misunderstood. The correct answer to ULA was "Don't do it (or, more correctly, do IPv6 PI instead)." >> And BTW, the lottery is actually the perfect analogy for ULA, since no >> matter how astronomical the odds against, eventually someone always wins. >> > > This is my concern. A business would rather be assured uniqueness over > gambling, no matter what the odds. Given no additional services are needed, > the administration cost is the same as handing out snmp enterprise oids. The > fact that the community isn't offering such due to politics is disheartening > and just plain sad. Now that sounds like something it would have been easy for IANA to do. See, you have tension on this topic even in your own line of reasoning. :) Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From randy at psg.com Sun Jul 25 02:19:08 2010 From: randy at psg.com (Randy Bush) Date: Sun, 25 Jul 2010 09:19:08 +0200 Subject: Fwd: Re: North Korea conflict with US and South Korea could spark cyber war In-Reply-To: <4C4B88E2.2060600@trelane.net> References: <4C4B88E2.2060600@trelane.net> Message-ID: > From: andrew.wallace > Continue to call me a troll in public and I'll be seeking legal > advice. andrew wallace, i think you are a troll who needs legal advice. probably could also use some other care. randy From tariq198487 at hotmail.com Sun Jul 25 02:20:43 2010 From: tariq198487 at hotmail.com (Tarig Yassin) Date: Sun, 25 Jul 2010 10:20:43 +0300 Subject: Appliance Vs Software based routers Message-ID: Dear all Greetings I'm wondering why the software based router is not preferable in business even if they have high featured Processers, and high capcity of memory. What is the main deferent between Appliance router and Software based routers? thank you all in adavance. -- Tarig Y. Adam _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. https://signup.live.com/signup.aspx?id=60969 From dougb at dougbarton.us Sun Jul 25 02:21:40 2010 From: dougb at dougbarton.us (Doug Barton) Date: Sun, 25 Jul 2010 00:21:40 -0700 (PDT) Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> Message-ID: On Sat, 24 Jul 2010, Owen DeLong wrote: > > On Jul 24, 2010, at 10:35 PM, Doug Barton wrote: > >> On Sat, 24 Jul 2010, Brandon Butterworth wrote: >> >>>>> Eventually ARIN (or someone else will do it for them) may create a >>>>> site >>> ... >>>> Did you mean something like this maybe ?: >>>> >>>> http://www.sixxs.net/tools/grh/ula/ >>> >>> Q.E.D. >>> >>> The RFC seeks to avoid a registry so we end up with the potential >>> for many as a result. May as well have had ARIN do it officially in >>> the first place so there'd only be one. >> >> So, back when ULA was first proposed, some of us said (sometimes >> privately) that there are only 2 rational options: 1. Do it; with a >> persistent, guaranteed unique, global registry. 2. Don't do it. >> >> Option 2 was a non-starter since there was too much critical mass. >> The logical candidate to operate option 1 was the IANA, and the RIRs >> were having none of that. (For bonus points, explain how the RIRs >> continue to exist if everyone can have all of the >> guaranteed-globally-unique IPv6 space they wanted for free.) >> > For bonus points, explain how the numbers side of IANA pays for > anything when the RIRs stop funding it? David already answered more eloquently than I could, so I'll simply add that what he said applied when I was there as well. The IANA is, and always has been a cost center. You don't want to live in an IANA fee-for-service world. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From jbates at brightok.net Sun Jul 25 02:31:46 2010 From: jbates at brightok.net (Jack Bates) Date: Sun, 25 Jul 2010 02:31:46 -0500 Subject: Appliance Vs Software based routers In-Reply-To: References: Message-ID: <4C4BE862.1020305@brightok.net> Tarig Yassin wrote: > What is the main deferent between Appliance router and Software based routers? I believe the main difference is the ability to handle features at line rate speeds. The more interfaces/speed + CoS/ACL, the harder it is for a software based router to keep up. Jack From kauer at biplane.com.au Sun Jul 25 02:32:27 2010 From: kauer at biplane.com.au (Karl Auer) Date: Sun, 25 Jul 2010 17:32:27 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C4BDCE4.7040009@brightok.net> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> Message-ID: <1280043147.28305.515.camel@karl> On Sun, 2010-07-25 at 01:42 -0500, Jack Bates wrote: > This is my concern. A business would rather be assured uniqueness over > gambling, no matter what the odds. Given no additional services are > needed, the administration cost is the same as handing out snmp > enterprise oids. The fact that the community isn't offering such due to > politics is disheartening and just plain sad. "No matter what the odds"? A good business person weighs the odds carefully and takes calculated risks. The chance of a conflict if you choose a random ULA prefix is lower than just about any other risk an enterprise would even bother considering. There is much more chance of an employee going postal, of a massive lightning strike, of a disastrous fire or flood, of a two-week power outage, than there is of a ULA prefix conflict, and all those things will cause far more real damage than a ULA prefix conflict. The risk of a ULA prefix conflict is for *all practical purposes* zero. It is a far lower risk than almost anything else you probably have contingency plans for. Not only that, but *even if the event comes to pass*, it is merely an inconvenience. Not only that but it is an inconvenience that can be detected in plenty of time and planned for and mitigated with relative ease. There may be good arguments against ULA, but the risk of prefix conflict is not one of them. Please let's stop behaving as if a ULA conflict is some kind of accident waiting to happen. If an expert stood up in court and said "the chances that this fingerprint is the defendant's are a million to one", and the prosecutor then said "Aha! So you admit it's *possible*!" we would rightly scorn the prosecutor for being an innumerate nincompoop. Yet here we are paying serious heed to the idea that a ULA prefix conflict is a real business risk. Sheesh, if we professionals can't get a grip on what these tiny, tiny probabilities really *mean* then how is anyone else going to? Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From adrian at creative.net.au Sun Jul 25 03:21:37 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Sun, 25 Jul 2010 16:21:37 +0800 Subject: Appliance Vs Software based routers In-Reply-To: References: Message-ID: <20100725082137.GV28859@skywalker.creative.net.au> The official answer: commodity hardware doesn't handle all the features needed at "line rate". The (more often than not) unofficial answer: using a custom platform raises the entry barrier for cloning/abuse/etc. It's a bit hard to run your appliance MIPS software on an off-the-shelf PC; but it (used) to be possible to run PIX software on a PC (and in a VM too, IIRC.) Fun times, Adrian On Sun, Jul 25, 2010, Tarig Yassin wrote: > > Dear all > > > > Greetings > > > > I'm wondering why the software based router is not preferable in business even if they have high featured Processers, and high capcity of memory. > > > > What is the main deferent between Appliance router and Software based routers? > > > > thank you all in adavance. > > -- > Tarig Y. Adam > > > > > > > _________________________________________________________________ > Hotmail: Trusted email with powerful SPAM protection. > https://signup.live.com/signup.aspx?id=60969 -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From saku at ytti.fi Sun Jul 25 03:40:19 2010 From: saku at ytti.fi (Saku Ytti) Date: Sun, 25 Jul 2010 11:40:19 +0300 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <1280043147.28305.515.camel@karl> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> <1280043147.28305.515.camel@karl> Message-ID: <20100725084019.GA3406@mx.ytti.net> On (2010-07-25 17:32 +1000), Karl Auer wrote: > The risk of a ULA prefix conflict is for *all practical purposes* zero. http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^1000000+((2^40)-1000000)!)+ It wouldn't puke nice graph with 'n', it did try, but never finished. So if there are million assigned ULA's there is 36.5% chance of collision, if formula is right. If operator fscks-up their residential DSL product, lets say the assign all the /128 user could want, but from single shared /64 subnet, not routing dedicated /48 to each customer. Users who need to route, will want solution and some vendor will step in, providing router which will auto-assign ULA + NAT66, will that vendor sell million copies of said CPE? But I don't think it is interesting to discuss the random chance of collisions, as human factor will guarantee collisions, many people will assign fd::/48 to get short and memorable addresses in their network. (You've made your bed, now lie in it.) If your IT staff includes personnel who've done painful renumbering due to M&A, there is good chance they'll allocate random, otherwise they'll likely opt for short and memorable network, as they did with RFC1918. Just because we get IPv6, doesn't mean people will get sudden burst of insight in design and engineering. -- ++ytti From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jul 25 08:52:16 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 25 Jul 2010 23:22:16 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> Message-ID: <20100725232216.5a2e9d9c@opy.nosense.org> On Sun, 25 Jul 2010 09:01:33 +0200 David Conrad wrote: > On Jul 25, 2010, at 8:42 AM, Jack Bates wrote: > > > Doug Barton wrote: > >> having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) > > whois. > > http://whois.iana.org > > > what did I win? IANA can handle very basic assignments, but hasn't the staff for large support or extra services (whois, POC management/validity, routing registry). > > With the exception of a routing registry (which I wasn't aware was an address allocation requirement), these services are provided by ICANN as part of the IANA functions contract. Out of curiosity, why do you think providing whois, POC management/validity, and even a routing registry requires a large staff? > > > I think IANA would be perfect for ULA identifier assignments. No whois/poc/routing registry needed. Send email, get an identifier in a week or 2. > > As you note, ICANN already provides something like this as part of the protocol parameter function of the IANA functions contract for private enterprise numbers (OIDs). > > > This is my concern. A business would rather be assured uniqueness over gambling, no matter what the odds. > > I remember arguments like that about why Token Ring was going to win over Ethernet :-) > +1 +1 +1 (Was quite happy when I was able to have an 10Mpbs ethernet pulled from the floor below when my gov dept. was merged with another gov dept. and I was moved to their IT section - and they were using 4Mbps token ring) Of course being in business is a gamble in itself. They gamble on future profits occurring when they spend on product or service development, government regulation staying stable, cost bases that aren't going to dramatically change, and possibly currency values staying fairly stable (GFC type events being the ones that out bad gamblers). I doubt businesses will be all that uncomfortable with IPv6 ULA collision odds that are worse than winning the lottery. > > Given no additional services are needed, the administration cost is the same as handing out snmp enterprise oids. The fact that the community isn't offering such due to politics is disheartening and just plain sad. > > Indeed. I have stories... > > Regards, > -drc > (who no longer works for ICANN) > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Jul 25 09:15:58 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 25 Jul 2010 23:45:58 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <20100725084019.GA3406@mx.ytti.net> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> <1280043147.28305.515.camel@karl> <20100725084019.GA3406@mx.ytti.net> Message-ID: <20100725234558.2f72c7ff@opy.nosense.org> On Sun, 25 Jul 2010 11:40:19 +0300 Saku Ytti wrote: > On (2010-07-25 17:32 +1000), Karl Auer wrote: > > > > The risk of a ULA prefix conflict is for *all practical purposes* zero. > > http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^1000000+((2^40)-1000000)!)+ > > It wouldn't puke nice graph with 'n', it did try, but never finished. > > So if there are million assigned ULA's there is 36.5% chance of collision, if > formula is right. > That's duplication, not collision. Collision only occurs when two ULA domains want to interconnect, and have duplicate routes they would like to exchange. Here is what the RFC says about odds - 3.2.3. Analysis of the Uniqueness of Global IDs The selection of a pseudo random Global ID is similar to the selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of [RTP]. This analysis is adapted from that document. Since Global IDs are chosen randomly (and independently), it is possible that separate networks have chosen the same Global ID. For any given network, with one or more random Global IDs, that has inter-connections to other such networks, having a total of N such IDs, the probability that two or more of these IDs will collide can be approximated using the formula: P = 1 - exp(-N**2 / 2**(L+1)) where P is the probability of collision, N is the number of interconnected Global IDs, and L is the length of the Global ID. The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 2 1.81*10^-12 10 4.54*10^-11 100 4.54*10^-09 1000 4.54*10^-07 10000 4.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs. > If operator fscks-up their residential DSL product, lets say the assign all the > /128 user could want, but from single shared /64 subnet, not routing dedicated > /48 to each customer. Users who need to route, will want solution and some > vendor will step in, providing router which will auto-assign ULA + NAT66, will > that vendor sell million copies of said CPE? > > But I don't think it is interesting to discuss the random chance of collisions, > as human factor will guarantee collisions, many people will assign fd::/48 to > get short and memorable addresses in their network. (You've made your bed, now > lie in it.) > That bed was called "site locals", and the prefix was fec0::/10. If two separate organisations choose to make ULAs effectively site locals, and then join their ULA domains, then they deserve the pain they'll get because they haven't followed the RFC4193 formula. At the end of the day you can't stop people doing stupid things unless you take away the variables that they can set. If people are arguing that ULA specs won't be followed correctly, then any other IPv6 spec variable may also not be set correctly by the same person. Ultimately that means that incompetent networking people are running the network. I don't think you can use that as a valid reason to dismiss ULAs, and then not use it to dismiss the whole of IPv6 *and* IPv4. > If your IT staff includes personnel who've done painful renumbering due to M&A, > there is good chance they'll allocate random, otherwise they'll likely opt for > short and memorable network, as they did with RFC1918. > Just because we get IPv6, doesn't mean people will get sudden burst of insight > in design and engineering. > > > -- > ++ytti > From Valdis.Kletnieks at vt.edu Sun Jul 25 09:14:52 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 25 Jul 2010 10:14:52 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: Your message of "Sat, 24 Jul 2010 22:35:07 PDT." References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> Message-ID: <53710.1280067292@localhost> On Sat, 24 Jul 2010 22:35:07 PDT, Doug Barton said: > having none of that. (For bonus points, explain how the RIRs continue to > exist if everyone can have all of the guaranteed-globally-unique IPv6 > space they wanted for free.) The same way that companies are making money selling people credit reports they are legally able to get for free. Sorry, but you asked. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Sun Jul 25 09:28:53 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 25 Jul 2010 10:28:53 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: Your message of "Sun, 25 Jul 2010 11:40:19 +0300." <20100725084019.GA3406@mx.ytti.net> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> <1280043147.28305.515.camel@karl> <20100725084019.GA3406@mx.ytti.net> Message-ID: <53955.1280068133@localhost> On Sun, 25 Jul 2010 11:40:19 +0300, Saku Ytti said: > On (2010-07-25 17:32 +1000), Karl Auer wrote: > > > > The risk of a ULA prefix conflict is for *all practical purposes* zero. > > http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^1000000+((2^40)-1000000)!)+ > > It wouldn't puke nice graph with 'n', it did try, but never finished. > > So if there are million assigned ULA's there is 36.5% chance of collision, if > formula is right. Bzzt! Wrong, but thank you for playing. If there exists some screwed-up network design that *interconnects* 1M networks that are all *advertising* ULAs there's a 36% chance of collision. It's a subtle but important difference. You only care about a collision if (a) you and some site in Zimbabwe both chose the same ULA prefix *AND* (b) you wish to set up a private interconnect with them and talk with them *using the ULA prefix*. Very important 'and' there. On the other hand, today if you interconnect *3* private networks that use NAT you have like a 90% chance of collision. And yet, people manage to do this all the time. So ULAs give a way to make it literally a million times easier - and THOSE SAME PEOPLE WHO DO THIS WITH NAT ADDRESSES ALL THE TIME ARE WHINING ULA IS UNWORKABLE. Geez guys, give me a break. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Sun Jul 25 09:30:38 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 25 Jul 2010 10:30:38 -0400 Subject: Appliance Vs Software based routers In-Reply-To: Your message of "Sun, 25 Jul 2010 10:20:43 +0300." References: Message-ID: <54007.1280068238@localhost> On Sun, 25 Jul 2010 10:20:43 +0300, Tarig Yassin said: > I'm wondering why the software based router is not preferable in business Sorry, but you've gone wrong already. You can't ask "why something is true" until you first establish that the something is in fact true. There are *plenty* of businesses where a software based router is quite preferable due to its lower cost and increased flexibility. Proof: How many "software-based routers" (whatever that really means) has Cisco sold that are making their shops very happy? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From saku at ytti.fi Sun Jul 25 09:40:06 2010 From: saku at ytti.fi (Saku Ytti) Date: Sun, 25 Jul 2010 17:40:06 +0300 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <53955.1280068133@localhost> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> <1280043147.28305.515.camel@karl> <20100725084019.GA3406@mx.ytti.net> <53955.1280068133@localhost> Message-ID: <20100725144006.GA7550@mx.ytti.net> On (2010-07-25 10:28 -0400), Valdis.Kletnieks at vt.edu and Mark Smith wrote similarly: > > http://www.wolframalpha.com/input/?i=1-((2^40)!)%2F((2^40)^1000000+((2^40)-1000000)!)+ > > > > So if there are million assigned ULA's there is 36.5% chance of collision, if > > formula is right. > > Bzzt! Wrong, but thank you for playing. Point I was trying to convey is that you should not assume ULA to be globally unique. Visibility of IP can extend past routing, for example someone could use x-forwarded-for and assume rfc4193 to be as unique as any other IPv6 address. I personally have no beef with ULA and I don't mind that it can't be trusted to be globally unique identifier. It'll still allow well planned enterprise networks to avoid renumbering in M&A. -- ++ytti From owen at delong.com Sun Jul 25 10:48:02 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Jul 2010 08:48:02 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> Message-ID: <4D9905AC-1960-4165-8A17-E7293C135B94@delong.com> On Jul 24, 2010, at 11:40 PM, David Conrad wrote: > On Jul 25, 2010, at 8:10 AM, Owen DeLong wrote: >>> The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) >> For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it? > > None of the "sides of IANA" pay for anything. There is no binding between what parties pay and what the ICANN staff who perform the IANA function do. In fact, those staff do not have any knowledge of whether any organization has paid anything (other than what they might hear incidentally). > > The (zero dollar) IANA functions contract has 3 major functions, of which allocating blocks of addresses to the RIRs (and at the direction of the IETF) is one. Failure to perform that function would be interpreted as breach of contract, regardless of whether the RIRs pay anything to ICANN or not. > > Regards, > -drc The point was more that if the RIRs go away, IANA loses significant funding. Owen From owen at delong.com Sun Jul 25 10:58:54 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Jul 2010 08:58:54 -0700 Subject: Appliance Vs Software based routers In-Reply-To: <4C4BE862.1020305@brightok.net> References: <4C4BE862.1020305@brightok.net> Message-ID: <789C9E39-FF9B-4C8F-B11A-7176576AD65C@delong.com> On Jul 25, 2010, at 12:31 AM, Jack Bates wrote: > Tarig Yassin wrote: >> What is the main deferent between Appliance router and Software based routers? > > I believe the main difference is the ability to handle features at line rate speeds. The more interfaces/speed + CoS/ACL, the harder it is for a software based router to keep up. > > > Jack Most "Appliances" are small(er) software-based routers. Owen From owen at delong.com Sun Jul 25 11:02:09 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Jul 2010 09:02:09 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> Message-ID: >>> >> For bonus points, explain how the numbers side of IANA pays for anything when the RIRs stop funding it? > > David already answered more eloquently than I could, so I'll simply add that what he said applied when I was there as well. The IANA is, and always has been a cost center. You don't want to live in an IANA fee-for-service world. > My point was that as a cost center, IANA depends on funding from other sources. The RIRs are a major source of that funding. Owen From nathan at atlasnetworks.us Sun Jul 25 11:07:03 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 25 Jul 2010 16:07:03 +0000 Subject: Appliance Vs Software based routers In-Reply-To: References: Message-ID: <8C26A4FDAE599041A13EB499117D3C281645C290@ex-mb-1.corp.atlasnetworks.us> > I'm wondering why the software based router is not preferable in > business even if they have high featured Processers, and high capcity > of memory. It may be helpful before proceeding if you provide some examples of each, so we can understand your definition of a 'appliance' vs 'software router'. Best Regards, Nathan Eisenberg From nathan at atlasnetworks.us Sun Jul 25 11:19:00 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 25 Jul 2010 16:19:00 +0000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <1280043147.28305.515.camel@karl> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> <1280043147.28305.515.camel@karl> Message-ID: <8C26A4FDAE599041A13EB499117D3C281645C2D5@ex-mb-1.corp.atlasnetworks.us> > If an expert stood up in court and said "the chances that this > fingerprint is the defendant's are a million to one", and the > prosecutor then said "Aha! So you admit it's *possible*!" we would > rightly scorn the prosecutor for being an innumerate nincompoop. Yet > here we are paying serious heed to the idea that a ULA prefix conflict > is a real business risk. Yes, but if this prosecutor does this a million times, he's bound to be right at least once. Yes, a good businessperson takes risks. They also do everything possible to mitigate those risks, such as background checks on employees, lightning rods and grounding systems and insurance on the electronics in the building, buy generators and fuel contracts or source an emergency workplace. Yes, a crazy employee may get through a background check, but if the question is the presence of an attempt and prevention, then what is the risk mitigation for ULA? Best Regards, Nathan Eisenberg From tglassey at earthlink.net Sun Jul 25 11:24:30 2010 From: tglassey at earthlink.net (todd glassey) Date: Sun, 25 Jul 2010 09:24:30 -0700 Subject: Appliance Vs Software based routers In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281645C290@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C281645C290@ex-mb-1.corp.atlasnetworks.us> Message-ID: <4C4C653E.4030506@earthlink.net> On 7/25/2010 9:07 AM, Nathan Eisenberg wrote: >> I'm wondering why the software based router is not preferable in >> business even if they have high featured Processers, and high capcity >> of memory. > It may be helpful before proceeding if you provide some examples of each, so we can understand your definition of a 'appliance' vs 'software router'. > > Best Regards, > Nathan Eisenberg > > > They are all software based routers... It really shouldn't matter whether an Appliance Application (i.e. some routing program is running on a minimal runtime environment ) or a routing program is running as part of an OS or as an Application on an OS. It is all Software until it becomes silicon. The only issue is how far off the metal you are and its not hardware based routing really until there is no OS, no development environment, no software involved right? Todd From nathan at atlasnetworks.us Sun Jul 25 12:00:26 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 25 Jul 2010 17:00:26 +0000 Subject: Appliance Vs Software based routers In-Reply-To: <4C4C653E.4030506@earthlink.net> References: <8C26A4FDAE599041A13EB499117D3C281645C290@ex-mb-1.corp.atlasnetworks.us> <4C4C653E.4030506@earthlink.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C281645C390@ex-mb-1.corp.atlasnetworks.us> > They are all software based routers... It really shouldn't matter > whether an Appliance Application (i.e. some routing program is running > on a minimal runtime environment ) or a routing program is running as > part of an OS or as an Application on an OS. It is all Software until > it > becomes silicon. > > The only issue is how far off the metal you are and its not hardware > based routing really until there is no OS, no development environment, > no software involved right? As has been pointed out, hardware/appliance/software can be a highly semantic issue, at least for some people. OP seemed like a specific question couched in vague terms - I'd rather have a discussion about what OP was trying to accomplish than rehash "Vyatta as a BRAS". What's specifically important is the distinction between an 'appliance' platform (like a MIPS or Cisco routing switch), and what I presume OP infers a 'software' platform to be (an x86 box running iptables or Quagga). In that case, I would tell OP that the PCI/PCI-e bus architecture isn't built to handle the rampant interrupts (or polling) that a real routing/switching workload generates. The bus controller is built/sized to pump data to and from a video card/IO controller/etc, not to ship Ethernet packets up to the CPU and back out again in 8 different directions. On the other hand, moving packets between 8 interfaces is exactly what a routing switch like a Cisco 3750 is built to do. So, I wanted to retrieve the values of 'software router' and 'appliance' from OP to see if that's where he was going. Best Regards, Nathan Eisenberg From bill at herrin.us Sun Jul 25 12:03:09 2010 From: bill at herrin.us (William Herrin) Date: Sun, 25 Jul 2010 07:03:09 -1000 Subject: Appliance Vs Software based routers In-Reply-To: References: Message-ID: On Sat, Jul 24, 2010 at 9:20 PM, Tarig Yassin wrote: > I'm wondering why the software based router is not preferable in > business even if they have high featured Processers, and high capcity of memory. > > What is the main deferent between Appliance router and Software based routers? http://www.pagiamtzis.com/cam/camintro.html Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tariq198487 at hotmail.com Sun Jul 25 12:24:27 2010 From: tariq198487 at hotmail.com (Tarig Yassin) Date: Sun, 25 Jul 2010 20:24:27 +0300 Subject: Who controlls the Internet? Message-ID: Deal all I want to show you some obstacles that some countries face them every day. For example when users from Sudan trying to access some web site they will get a *Forbidden Access Error* message. And some messages say: you are forbidden to access this web site because your IP address appears form country black listed due to USA government policy. I would like to issue a question here, who controls this Internet? ThanksTarig _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969 From tariq198487 at hotmail.com Sun Jul 25 12:29:25 2010 From: tariq198487 at hotmail.com (Tarig Yassin) Date: Sun, 25 Jul 2010 20:29:25 +0300 Subject: Who controlls the Internet? Message-ID: And why not the ICCAN take this reponsibity as an International organization not USA government? From: tariq198487 at hotmail.com To: nanog at nanog.org Subject: Who controlls the Internet? Date: Sun, 25 Jul 2010 20:24:27 +0300 Deal all I want to show you some obstacles that some countries face them every day. For example when users from Sudan trying to access some web site they will get a *Forbidden Access Error* message. And some messages say: you are forbidden to access this web site because your IP address appears form country black listed due to USA government policy. I would like to issue a question here, who controls this Internet? Thanks Tarig Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now. _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969 From josh.hoppes at gmail.com Sun Jul 25 12:39:03 2010 From: josh.hoppes at gmail.com (Josh Hoppes) Date: Sun, 25 Jul 2010 12:39:03 -0500 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: In all honesty control over the Internet doesn't sound like the issue here. The US Government regulates entities functioning with in it's boarders. This would be no different if I being in the US were restricted access to a site in any other country due to their regulations. From streiner at cluebyfour.org Sun Jul 25 08:42:10 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 25 Jul 2010 09:42:10 -0400 (EDT) Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: On Sun, 25 Jul 2010, Tarig Yassin wrote: > I want to show you some obstacles that some countries face them every day. > > For example when users from Sudan trying to access some web site they > will get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site > because your IP address appears form country black listed due to USA > government policy. > > I would like to issue a question here, who controls this Internet? No one person or entity controls "the Internet", which itself is just a large collection of interconnected public and private networks that use the same protocols to communicate with each other. Many government entities exert some degree of control over the connectivity to, from, and within their contries. This ranges from overt restriction of access to certain sites, to overt/covert monitoring of user activity. Numerous examples have been discussed here over the years (China, Pakistan, Iran, Burma/Myanmar, Australia, India... the list goes on and on). Discussions related to the political reasons for such control are likely off topic for this list. In the case of certain websites in the USA being forbidden from IP addresses listed as being registered to a Sudanese entity, that is the result either of a choice not to accept connections from Sudanese IP blocks (to the extent that they can be identified) or the site has content and is within the sphere of influence of the US government, which maintains a list of contries with whom they either do not have direct diplomatic relations (Iran, North Korea) or they keep at arms' length for other reasons (Syria, Sudan, Somalia, etc). jms From streiner at cluebyfour.org Sun Jul 25 08:44:31 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Sun, 25 Jul 2010 09:44:31 -0400 (EDT) Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: On Sun, 25 Jul 2010, Tarig Yassin wrote: > And why not the ICCAN take this reponsibity as an International > organization not USA government? ICANN has no authority to tell sovereign nations how to run their IP connectivity. jms > From: tariq198487 at hotmail.com > To: nanog at nanog.org > Subject: Who controlls the Internet? > Date: Sun, 25 Jul 2010 20:24:27 +0300 > > > > Deal all > > I want to show you some obstacles that some countries face them every day. > > For example when users from Sudan trying to access some web site they will get a *Forbidden Access Error* message. > And some messages say: you are forbidden to access this web site because your IP address appears form country black listed due to USA government policy. > > I would like to issue a question here, who controls this Internet? > > > Thanks > > Tarig > > > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. Sign up now. > _________________________________________________________________ > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. > https://signup.live.com/signup.aspx?id=60969 From bortzmeyer at nic.fr Sun Jul 25 12:50:18 2010 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 25 Jul 2010 19:50:18 +0200 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: <20100725175018.GA18041@sources.org> On Sun, Jul 25, 2010 at 08:24:27PM +0300, Tarig Yassin wrote a message of 27 lines which said: > For example when users from Sudan trying to access some web site > they will get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site > because your IP address appears form country black listed due to USA > government policy. > > I would like to issue a question here, who controls this Internet? It is not "the Internet", it is just some Web sites in the USA which, for local reasons, ban access from Sudan. The Internet still works. And, on the Internet, any Web site can unilaterally decide to refuse access from country X or country Y, either because a *local* law mandates it or because they just feel that way. Go to Web sites in Japan or Costa-Rica and I assume everything will be OK. > And why not the ICCAN take this reponsibity as an International > organization not USA government? Since the ICANN is nothing more than a puppet of the US government, I don't see the improvment it would make. From patrick at ianai.net Sun Jul 25 12:55:56 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 25 Jul 2010 13:55:56 -0400 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> On Jul 25, 2010, at 13:24, Tarig Yassin wrote: > I want to show you some obstacles that some countries face them every day. > > For example when users from Sudan trying to access some web site they will get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site because your IP address appears form country black listed due to USA government policy. > > > I would like to issue a question here, who controls this Internet? No one. To be more clear, no on person, company, government, or any other entity controls "the Internet". Not even ICANN. Also, I am interested in examples of sites that the US gov't has blocked or otherwise somehow limited access. Please exclude sites owned by the US gov't itself. (Any entity which owns a web server can configure the ACLs on that sever however they plz as far as I'm concerned.) -- TTFN, patrick From tariq198487 at hotmail.com Sun Jul 25 13:05:59 2010 From: tariq198487 at hotmail.com (Tarig Yassin) Date: Sun, 25 Jul 2010 21:05:59 +0300 Subject: Who controlls the Internet? In-Reply-To: <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> References: , <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> Message-ID: probabaly every web server in USA e.g. Google, Verisign and sourceforge. What if a large orginization which has an infrstructure in many countires, in which regulations the will comply, in terms to ban other countries accessing to thier Internet resources. my regards, -- Tarig Y. Adam > From: patrick at ianai.net > Subject: Re: Who controlls the Internet? > Date: Sun, 25 Jul 2010 13:55:56 -0400 > To: nanog at nanog.org > > On Jul 25, 2010, at 13:24, Tarig Yassin wrote: > > > I want to show you some obstacles that some countries face them every day. > > > > For example when users from Sudan trying to access some web site they will get a *Forbidden Access Error* message. > > > > And some messages say: you are forbidden to access this web site because your IP address appears form country black listed due to USA government policy. > > > > > > I would like to issue a question here, who controls this Internet? > > No one. > > To be more clear, no on person, company, government, or any other entity controls "the Internet". Not even ICANN. > > Also, I am interested in examples of sites that the US gov't has blocked or otherwise somehow limited access. Please exclude sites owned by the US gov't itself. (Any entity which owns a web server can configure the ACLs on that sever however they plz as far as I'm concerned.) > > -- > TTFN, > patrick > _________________________________________________________________ Hotmail: Free, trusted and rich email service. https://signup.live.com/signup.aspx?id=60969 From jmamodio at gmail.com Sun Jul 25 13:21:46 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 25 Jul 2010 13:21:46 -0500 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: > I would like to issue a question here, who controls this Internet? The global abstract Internet ? nobody. Your government/service provider and/or the government/service provider of the destination you are trying to reach may restrict/block/redirect/tweak/tamper/sniff/shape the free flow of packets. Have you ever considered trying to use Tor ? (http://www.torproject.org/ well if you can get to it :-) PS. ICANN has no responsibility or operational role denying access or services. Regards From laurens at daemon.be Sun Jul 25 13:49:31 2010 From: laurens at daemon.be (Laurens Vets) Date: Sun, 25 Jul 2010 20:49:31 +0200 Subject: Appliance Vs Software based routers In-Reply-To: <20100725082137.GV28859@skywalker.creative.net.au> References: <20100725082137.GV28859@skywalker.creative.net.au> Message-ID: <4C4C873B.4010209@daemon.be> > The (more often than not) unofficial answer: using a custom platform > raises the entry barrier for cloning/abuse/etc. It's a bit hard to > run your appliance MIPS software on an off-the-shelf PC; but it (used) > to be possible to run PIX software on a PC (and in a VM too, IIRC.) Cisco PIX: no, Cisco ASA: yes. It even runs under VMware... It's however very hackish... :) From drc at virtualized.org Sun Jul 25 13:54:23 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 25 Jul 2010 20:54:23 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> Message-ID: <8B9FA608-FB8B-4152-97BC-7F8366E37DE8@virtualized.org> On Jul 25, 2010, at 6:02 PM, Owen DeLong wrote: > My point was that as a cost center, IANA depends on funding from other sources. The RIRs are a major source of that funding. I guess it depends on your definition of "major". From section 5.1 of ICANN's draft FY11 budget (http://www.icann.org/en/financials/proposed-opplan-budget-v1-fy11-17may10-en.pdf if you care): Registry $32,647,000 Registrar $29,159,000 RIR $823,000 ccTLD $1,600,000 IDN ccTLD $780,000 Meeting Sponsorships $500,000 Total $65,509,000 So the RIRs contribute 1.25% of ICANN's budget. Regards, -drc From sethm at rollernet.us Sun Jul 25 13:56:54 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 25 Jul 2010 11:56:54 -0700 Subject: Who controlls the Internet? In-Reply-To: References: , <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> Message-ID: <4C4C88F6.5050409@rollernet.us> On 7/25/10 11:05 AM, Tarig Yassin wrote: > > probabaly every web server in USA e.g. Google, Verisign and sourceforge. > Hah, no. ~Seth From fred at cisco.com Sun Jul 25 14:14:40 2010 From: fred at cisco.com (Fred Baker) Date: Sun, 25 Jul 2010 21:14:40 +0200 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: <95222324-4A25-438E-9725-4B711F3BCAE8@cisco.com> On Jul 25, 2010, at 7:24 PM, Tarig Yassin wrote: > Deal all > > I want to show you some obstacles that some countries face them every day. > > For example when users from Sudan trying to access some web site they will get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site because your IP address appears form country black listed due to USA government policy. I don't know of USG blacklists. There are certainly blacklists looked at by operators; they do this for their own reasons, not due to government pressure. Understand that the kind of thing that would motivate the USG to blacklist a country from looking at a given web site would be if the web site displayed information that would enable that country to threaten the US. There is information that is covered by a set of regulations called ITAR; it doesn't say what country can't receive information, it says what information a US citizen cannot legally communicate to anyone that is not a US citizen. I suspect that what is really happening here is that the Sudan has a redirect in place that blocks information it considers its citizens should not be able to access. The web page you see is designed to get you to wonder about those evil devils, the Americans, rather than those who are actually blocking the traffic. > I would like to issue a question here, who controls this Internet? Nobody, and everybody. > ThanksTarig > _________________________________________________________________ > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. > https://signup.live.com/signup.aspx?id=60969 http://www.ipinc.net/IPv4.GIF From drc at virtualized.org Sun Jul 25 14:17:17 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 25 Jul 2010 21:17:17 +0200 Subject: Who controlls the Internet? In-Reply-To: References: , <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> Message-ID: <17E04534-E6D5-43C3-86C0-1F3645DC6A91@virtualized.org> On Jul 25, 2010, at 8:05 PM, Tarig Yassin wrote: > probabaly every web server in USA e.g. Google, Verisign and sourceforge. ALL companies that operate in the US are bound by law to abide by restrictions that are defined at http://www.ustreas.gov/offices/enforcement/ofac/ and elsewhere. Failure to abide by those laws can result in criminal sanctions (that is, being thrown in jail for years). However, the US is not the only country that restricts who does business with whom. I suspect you'll find pretty much every country in the world has a similar list in one form or another. In many cases, and depending on context, companies can obtain licenses that permit the provision of content and services to countries and people that are under sanction, but those companies have to do the work and I suspect most find it isn't worth the effort. In addition, Intellectual Property owners may decide that they want to deny access to content for arbitrary reasons. Examples of this outside of the Internet are region encoded DVDs. These restrictions are determined by business models. The issue isn't that the US has these restrictions, rather it is that there is a lot of useful content that is generated in and/or distributed from the US. One could argue that this encourages creation of and distribution channels for useful content outside the US... > What if a large orginization which has an infrstructure in many countires, in which regulations the will comply, in terms to ban other countries accessing to thier Internet resources. As has been pointed out, the Internet is a set of interconnected public and private networks. Each of those networks has their own rules about who they'll grant access and what resources they'll make available. Regards, -drc From andrew.wallace at rocketmail.com Sun Jul 25 14:58:01 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sun, 25 Jul 2010 12:58:01 -0700 (PDT) Subject: Who controlls the Internet? In-Reply-To: <4C4C88F6.5050409@rollernet.us> References: , <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> <4C4C88F6.5050409@rollernet.us> Message-ID: <988255.20513.qm@web59612.mail.ac4.yahoo.com> On Sun, Jul 25, 2010 at 6:24 PM, Tarig Yassin wrote: > I would like to issue a question here, who controls this Internet? The truth to your question is, anybody who wants to. Hackers, activists, governments, terrorists all have the ability to control it. But probably not all at the same time. With the increase in irresponsible security disclosures by folks such as Tavis Ormandy, power and control is very much being handed to "the people". I have been campaigning for a while to get tighter laws introduced on irresponsible security disclosures, to give the government more control over the internet. Andrew Wallace From bmanning at vacation.karoshi.com Sun Jul 25 15:18:16 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 25 Jul 2010 20:18:16 +0000 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: <20100725201816.GB19483@vacation.karoshi.com.> On Sun, Jul 25, 2010 at 08:24:27PM +0300, Tarig Yassin wrote: > > Deal all > > > > I want to show you some obstacles that some countries face them every day. > > > For example when users from Sudan trying to access some web site they will get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site because your IP address appears form country black listed due to USA government policy. thats a nice, vague, and non-supportable message that is phrased to generate anger. which web sites, what web proxies, and which orgin IP addresses are in question here? > > I would like to issue a question here, who controls this Internet? the brief answer is - lots of people. ISPs, Telecoms companies, Government censors and regulators, your content providers, access providers (the Internet cafe), and your parents. > > > > > ThanksTarig > _________________________________________________________________ > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. > https://signup.live.com/signup.aspx?id=60969 From bmanning at vacation.karoshi.com Sun Jul 25 15:21:39 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 25 Jul 2010 20:21:39 +0000 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: <20100725202139.GC19483@vacation.karoshi.com.> On Sun, Jul 25, 2010 at 01:21:46PM -0500, Jorge Amodio wrote: > > PS. ICANN has no responsibility or operational role denying access or services. > > Regards except ICANN has presumed for itself an operational role. it has taken on root server operations for some years now and is trying to take over root zone editorial control. --bil From techie.jovenes at gmail.com Sun Jul 25 15:25:49 2010 From: techie.jovenes at gmail.com (techie jovenes) Date: Sun, 25 Jul 2010 23:25:49 +0300 Subject: Who controlls the Internet? In-Reply-To: References: <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> Message-ID: On 25 July 2010 21:05, Tarig Yassin wrote: > > probabaly every web server in USA e.g. Google, Verisign and sourceforge. > > > In this case you will most likely discover that these are blocked by the service provider at your end and not by Google et al. > What if a large orginization which has an infrstructure in many countires, > in which regulations the will comply, in terms to ban other countries > accessing to thier Internet resources. > > > The local laws/regulations take precedence in each country and they must abide to what's been set. This however isnt a concern to many since not many countries impose such strict restrictions. ./TJ From nathan at atlasnetworks.us Sun Jul 25 16:44:02 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sun, 25 Jul 2010 21:44:02 +0000 Subject: Who controlls the Internet? In-Reply-To: References: <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C281645C586@ex-mb-1.corp.atlasnetworks.us> > The local laws/regulations take precedence in each country and they must > abide to what's been set. This however isnt a concern to many since not many > countries impose such strict restrictions. I thought most countries had trade and export restrictions of one sort or another? Best Regards, Nathan Eisenberg From kauer at biplane.com.au Sun Jul 25 17:58:26 2010 From: kauer at biplane.com.au (Karl Auer) Date: Mon, 26 Jul 2010 08:58:26 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <8C26A4FDAE599041A13EB499117D3C281645C2D5@ex-mb-1.corp.atlasnetworks.us> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <4C4BDCE4.7040009@brightok.net> <1280043147.28305.515.camel@karl> <8C26A4FDAE599041A13EB499117D3C281645C2D5@ex-mb-1.corp.atlasnetworks.us> Message-ID: <1280098706.28305.713.camel@karl> On Sun, 2010-07-25 at 16:19 +0000, Nathan Eisenberg wrote: > > If an expert stood up in court and said "the chances that this > > fingerprint is the defendant's are a million to one", and the > > prosecutor then said "Aha! So you admit it's *possible*!" we would > > rightly scorn the prosecutor for being an innumerate nincompoop. Yet > > here we are paying serious heed to the idea that a ULA prefix conflict > > is a real business risk. > > Yes, but if this prosecutor does this a million times, he's bound to > be right at least once. Hm. Would you hire a prosecutor who was, on average, right once in a million times? > Yes, a good businessperson takes risks. They also do everything > possible to mitigate those risks, such as background checks on > employees, lightning rods and grounding systems and insurance on the > electronics in the building, buy generators and fuel contracts or > source an emergency workplace. Yes, a crazy employee may get through > a background check, but if the question is the presence of an attempt > and prevention, then what is the risk mitigation for ULA? Choose a random ULA prefix. Done. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From joly at punkcast.com Sun Jul 25 18:11:46 2010 From: joly at punkcast.com (Joly MacFie) Date: Sun, 25 Jul 2010 19:11:46 -0400 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: Hi Tarig This is a bit like asking who controls friendship. Of course nobody does. However if certain friends of yours are going to impose conditions on you, you have to go along with it or find new friends. One way round it is to use other friends as interlocutors, simply by using proxy services, or, in more intense situations, something like Kaleidoscope http://www.isoc-ny.org/?p=1485 j On Sun, Jul 25, 2010 at 1:24 PM, Tarig Yassin wrote: > > Deal all > > > > I want to show you some obstacles that some countries face them every day. > > > > For example when users from Sudan trying to access some web site they will > get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site because > your IP address appears form country black listed due to USA government > policy. > > > > I would like to issue a question here, who controls this Internet? > > > > > ThanksTarig > _________________________________________________________________ > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. > https://signup.live.com/signup.aspx?id=60969 > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From cian.brennan at redbrick.dcu.ie Sun Jul 25 18:18:12 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Mon, 26 Jul 2010 00:18:12 +0100 Subject: Who controlls the Internet? In-Reply-To: <988255.20513.qm@web59612.mail.ac4.yahoo.com> References: <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> <4C4C88F6.5050409@rollernet.us> <988255.20513.qm@web59612.mail.ac4.yahoo.com> Message-ID: <20100725231812.GA6704@minerva.redbrick.dcu.ie> On Sun, Jul 25, 2010 at 12:58:01PM -0700, andrew.wallace wrote: > On Sun, Jul 25, 2010 at 6:24 PM, Tarig Yassin wrote: > > I would like to issue a question here, who controls this Internet? > > The truth to your question is, anybody who wants to. Hackers, activists, > governments, terrorists all have the ability to control it. But probably not all > at the same time. > > > With the increase in irresponsible security disclosures by folks such as Tavis > Ormandy, power and control is very much being handed to "the people". > > I have been campaigning for a while to get tighter laws introduced on > irresponsible security disclosures, to give the government more control over the > internet. > Which government? There are rather a lot of them, and they all have a legitimate interest in control over the internet (or at least their chunk of it. Good luck deciding where their chunk ends though). > Andrew Wallace > > > > > > From allen_bass at comcast.net Sun Jul 25 18:32:59 2010 From: allen_bass at comcast.net (Allen Bass) Date: Sun, 25 Jul 2010 19:32:59 -0400 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: <06b901cb2c51$b82b2700$28817500$@net> Tarig, Just going out on a limb here, but who says the sites in the US are blocking instead of the country itself? Maybe the Sudan government is blocking access to the sites for whatever reason. Allen -----Original Message----- From: Joly MacFie [mailto:joly at punkcast.com] Sent: Sunday, July 25, 2010 7:12 PM To: Tarig Yassin Cc: nanog Subject: Re: Who controlls the Internet? Hi Tarig This is a bit like asking who controls friendship. Of course nobody does. However if certain friends of yours are going to impose conditions on you, you have to go along with it or find new friends. One way round it is to use other friends as interlocutors, simply by using proxy services, or, in more intense situations, something like Kaleidoscope http://www.isoc-ny.org/?p=1485 j On Sun, Jul 25, 2010 at 1:24 PM, Tarig Yassin wrote: > > Deal all > > > > I want to show you some obstacles that some countries face them every day. > > > > For example when users from Sudan trying to access some web site they will > get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site because > your IP address appears form country black listed due to USA government > policy. > > > > I would like to issue a question here, who controls this Internet? > > > > > ThanksTarig > _________________________________________________________________ > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. > https://signup.live.com/signup.aspx?id=60969 > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From jmamodio at gmail.com Sun Jul 25 18:54:56 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 25 Jul 2010 18:54:56 -0500 Subject: Who controlls the Internet? In-Reply-To: <20100725202139.GC19483@vacation.karoshi.com.> References: <20100725202139.GC19483@vacation.karoshi.com.> Message-ID: >> PS. ICANN has no responsibility or operational role denying access or services. >> >> Regards > > ? ? ? ?except ICANN has presumed for itself an operational role. > ? ? ? ?it has taken on root server operations for some years now > ? ? ? ?and is trying to take over root zone editorial control. Sure, no doubt there are some groups under the ICANN umbrella desperate to expand their "operational" role including the last move about creating a DNS-CERT or GAC-ifing every decision. Besides L server I don't think ICANN has much control of the rest of the root servers. Amen about the root zone. I'd love to see how viable and what it would take to "go Postel", screw ICANN and declare independence from it. I'd say that today nobody has full control but among some organizations (including now the other competing traveling circus aka IGF) many want to have it. Cheers Jorge From owen at delong.com Sun Jul 25 20:30:59 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 25 Jul 2010 18:30:59 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <8B9FA608-FB8B-4152-97BC-7F8366E37DE8@virtualized.org> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> <8B9FA608-FB8B-4152-97BC-7F8366E37DE8@virtualized.org> Message-ID: <87AE246B-A12D-4A66-94A7-53C96303687B@delong.com> On Jul 25, 2010, at 11:54 AM, David Conrad wrote: > On Jul 25, 2010, at 6:02 PM, Owen DeLong wrote: >> My point was that as a cost center, IANA depends on funding from other sources. The RIRs are a major source of that funding. > > I guess it depends on your definition of "major". From section 5.1 of ICANN's draft FY11 budget (http://www.icann.org/en/financials/proposed-opplan-budget-v1-fy11-17may10-en.pdf if you care): > > Registry $32,647,000 > Registrar $29,159,000 > RIR $823,000 > ccTLD $1,600,000 > IDN ccTLD $780,000 > Meeting Sponsorships $500,000 > Total $65,509,000 > > So the RIRs contribute 1.25% of ICANN's budget. > > Regards, > -drc Correct, now, what portion of ICANN's budget is related to the NRO sector? My bet is that it's less than 1.25%. I suppose you can make domain owners pay for address administration if you want to make address administration free, but, that seems a bit backwards to me. Owen From bonomi at mail.r-bonomi.com Sun Jul 25 22:15:58 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sun, 25 Jul 2010 22:15:58 -0500 (CDT) Subject: Who controlls the Internet? Message-ID: <201007260315.o6Q3FwsT023667@mail.r-bonomi.com> > From: Tarig Yassin > To: nanog > Subject: Who controlls the Internet? > Date: Sun, 25 Jul 2010 20:24:27 +0300 > > > Deal all > > I want to show you some obstacles that some countries face them every day. > > For example when users from Sudan trying to access some web site they will > get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site because > your IP address appears form country black listed due to USA government > p= > y. > I would like to issue a question here, who controls this Internet? "Fluffy owns USENET", as everybody knows, and her big mean brother owns the Internet. I could tell you his name, but then I'd have to kill you. Whether you like it or not, the government of a country where a server is located, and/or where the service operator is located, *CAN* dictate terms to that server or service operator. There are _no_ 'uniform' international rules, or guarantees of aceess. Be thankful you're not in China, where attempts to access 'forbidden' sites can bring the secret police knocking. Or some of the Middle East Countries, where *everything* going out-of- country goes through government-owned/-operated censorship boxes. The answer to your question -- "as asked" -- is "everybody, and NOBODY". Any government entity can enact laws concerning what people _within_ _their_jurisdiction_ can do over the Internet, just as they can regulate any other aspcet of 'life'. OTOH, there's no international authority you have to go to, to get a 'license' to get on the Internet and use it. except to whatever extent it is controlled by local government, you can set up services, buy connectivity from whomever you want, and -do- whatever you want, regardless of whether or not such activities make you a 'good net neighbor' or a 'bad' one. As for your particular 'problem', some countries have intternational reputations for being 'bad neighbors'. Things like financing known terrorist organizations, providing various facilities and training capabilities, etc. Countries that do things like this -- or more properly _allow_ things like this to go on within their jurisdiction, run the risk of being cast as 'beyond the pale' by those countries that frown on such things. In which case, any resources that _might_ help those 'bad guys' with ther malevolent efforts are denied to _anyone_ from that country. If you don't like being in that classification, take it up with *your* government. Good Luck. From robert.west at just-micro.com Sun Jul 25 22:39:59 2010 From: robert.west at just-micro.com (Robert West) Date: Sun, 25 Jul 2010 23:39:59 -0400 Subject: Who controlls the Internet? In-Reply-To: <201007260315.o6Q3FwsT023667@mail.r-bonomi.com> References: <201007260315.o6Q3FwsT023667@mail.r-bonomi.com> Message-ID: <000001cb2c74$3916b8d0$ab442a70$@just-micro.com> I'm moving all operations to Sealand................ Bob- -----Original Message----- From: Robert Bonomi [mailto:bonomi at mail.r-bonomi.com] Sent: Sunday, July 25, 2010 11:16 PM To: nanog at nanog.org Subject: Re: Who controlls the Internet? > From: Tarig Yassin > To: nanog > Subject: Who controlls the Internet? > Date: Sun, 25 Jul 2010 20:24:27 +0300 > > > Deal all > > I want to show you some obstacles that some countries face them every day. > > For example when users from Sudan trying to access some web site they > will get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site > because your IP address appears form country black listed due to USA > government p= > y. > I would like to issue a question here, who controls this Internet? "Fluffy owns USENET", as everybody knows, and her big mean brother owns the Internet. I could tell you his name, but then I'd have to kill you. Whether you like it or not, the government of a country where a server is located, and/or where the service operator is located, *CAN* dictate terms to that server or service operator. There are _no_ 'uniform' international rules, or guarantees of aceess. Be thankful you're not in China, where attempts to access 'forbidden' sites can bring the secret police knocking. Or some of the Middle East Countries, where *everything* going out-of- country goes through government-owned/-operated censorship boxes. The answer to your question -- "as asked" -- is "everybody, and NOBODY". Any government entity can enact laws concerning what people _within_ _their_jurisdiction_ can do over the Internet, just as they can regulate any other aspcet of 'life'. OTOH, there's no international authority you have to go to, to get a 'license' to get on the Internet and use it. except to whatever extent it is controlled by local government, you can set up services, buy connectivity from whomever you want, and -do- whatever you want, regardless of whether or not such activities make you a 'good net neighbor' or a 'bad' one. As for your particular 'problem', some countries have intternational reputations for being 'bad neighbors'. Things like financing known terrorist organizations, providing various facilities and training capabilities, etc. Countries that do things like this -- or more properly _allow_ things like this to go on within their jurisdiction, run the risk of being cast as 'beyond the pale' by those countries that frown on such things. In which case, any resources that _might_ help those 'bad guys' with ther malevolent efforts are denied to _anyone_ from that country. If you don't like being in that classification, take it up with *your* government. Good Luck. From robert.west at just-micro.com Sun Jul 25 22:41:05 2010 From: robert.west at just-micro.com (Robert West) Date: Sun, 25 Jul 2010 23:41:05 -0400 Subject: FW: Who controlls the Internet? References: Message-ID: <000101cb2c74$60a44d40$21ece7c0$@just-micro.com> -----Original Message----- From: Robert West [mailto:robert.west at just-micro.com] Sent: Sunday, July 25, 2010 10:56 PM To: 'Tarig Yassin' Subject: RE: Who controlls the Internet? Each individual government seems to control the information the enters or leaves their borders. Do a search for "Internet Censorship Wikileaks". Every government has their own set of morals and standards and politically motivated black list. Certainly the USA wants to swagger and force its will on not only its own people but the entire planet, but they are not alone. Australia, China, North Korea, Germany........ Etc............ All with their own agenda. It would be great if there was ONE entity that controlled content and each country had to abide by their decisions in order to have access to the backbone but that's only just a dream at this point. The flat earth that should be the flow of information needs to be demanded by everyone. That's my 13 cents worth. (Inflation sucks) But who am I but just a thinking and caring animal of this planet? Bob- -----Original Message----- From: Tarig Yassin [mailto:tariq198487 at hotmail.com] Sent: Sunday, July 25, 2010 1:24 PM To: nanog Subject: Who controlls the Internet? Deal all I want to show you some obstacles that some countries face them every day. For example when users from Sudan trying to access some web site they will get a *Forbidden Access Error* message. And some messages say: you are forbidden to access this web site because your IP address appears form country black listed due to USA government policy. I would like to issue a question here, who controls this Internet? ThanksTarig _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969 From robert.west at just-micro.com Sun Jul 25 22:41:21 2010 From: robert.west at just-micro.com (Robert West) Date: Sun, 25 Jul 2010 23:41:21 -0400 Subject: FW: Who controlls the Internet? References: Message-ID: <000201cb2c74$6a3cd070$3eb67150$@just-micro.com> -----Original Message----- From: Robert West [mailto:robert.west at just-micro.com] Sent: Sunday, July 25, 2010 11:02 PM To: 'Tarig Yassin' Subject: RE: Who controlls the Internet? To add....... This is a great reason to provide proxy servers or to use Tor. If enough resources are thrown against it to make it irrelevant.............. Well........... Okay, so they will fight back with even more. Time to shoot one's self in the head. :) In the immortal words of Bob Marley, "Get Up, Stand Up! Don't Give Up The Fight!" Bob- -----Original Message----- From: Tarig Yassin [mailto:tariq198487 at hotmail.com] Sent: Sunday, July 25, 2010 1:24 PM To: nanog Subject: Who controlls the Internet? Deal all I want to show you some obstacles that some countries face them every day. For example when users from Sudan trying to access some web site they will get a *Forbidden Access Error* message. And some messages say: you are forbidden to access this web site because your IP address appears form country black listed due to USA government policy. I would like to issue a question here, who controls this Internet? ThanksTarig _________________________________________________________________ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969 From robert.west at just-micro.com Sun Jul 25 22:41:52 2010 From: robert.west at just-micro.com (Robert West) Date: Sun, 25 Jul 2010 23:41:52 -0400 Subject: FW: Who controlls the Internet? References: , <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> <4C4C88F6.5050409@rollernet.us> <988255.20513.qm@web59612.mail.ac4.yahoo.com> Message-ID: <000301cb2c74$7e41c8a0$7ac559e0$@just-micro.com> -----Original Message----- From: Robert West [mailto:robert.west at just-micro.com] Sent: Sunday, July 25, 2010 11:15 PM To: 'andrew.wallace' Subject: RE: Who controlls the Internet? I thought it was Kim Jong-il. At least that was what was on the memo............. Bob- -----Original Message----- From: andrew.wallace [mailto:andrew.wallace at rocketmail.com] Sent: Sunday, July 25, 2010 3:58 PM To: tariq198487 at hotmail.com Cc: nanog at nanog.org Subject: Re: Who controlls the Internet? On Sun, Jul 25, 2010 at 6:24 PM, Tarig Yassin wrote: > I would like to issue a question here, who controls this Internet? The truth to your question is, anybody who wants to. Hackers, activists, governments, terrorists all have the ability to control it. But probably not all at the same time. With the increase in irresponsible security disclosures by folks such as Tavis Ormandy, power and control is very much being handed to "the people". I have been campaigning for a while to get tighter laws introduced on irresponsible security disclosures, to give the government more control over the internet. Andrew Wallace From robert.west at just-micro.com Sun Jul 25 22:44:58 2010 From: robert.west at just-micro.com (Robert West) Date: Sun, 25 Jul 2010 23:44:58 -0400 Subject: ho controlls the Internet? Message-ID: <000401cb2c74$eba3cc40$c2eb64c0$@just-micro.com> I thought it was Kim Jong-il. At least that was what was on the memo............. Bob- -----Original Message----- From: andrew.wallace [mailto:andrew.wallace at rocketmail.com] Sent: Sunday, July 25, 2010 3:58 PM To: tariq198487 at hotmail.com Cc: nanog at nanog.org Subject: Re: Who controlls the Internet? On Sun, Jul 25, 2010 at 6:24 PM, Tarig Yassin wrote: > I would like to issue a question here, who controls this Internet? The truth to your question is, anybody who wants to. Hackers, activists, governments, terrorists all have the ability to control it. But probably not all at the same time. With the increase in irresponsible security disclosures by folks such as Tavis Ormandy, power and control is very much being handed to "the people". I have been campaigning for a while to get tighter laws introduced on irresponsible security disclosures, to give the government more control over the internet. Andrew Wallace From lists at quux.de Sun Jul 25 23:09:44 2010 From: lists at quux.de (Jens Link) Date: Mon, 26 Jul 2010 06:09:44 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: (Owen DeLong's message of "Sat\, 24 Jul 2010 02\:13\:18 -0700") References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> Message-ID: <874ofmkho7.fsf@oban.berlin.quux.de> Owen DeLong writes: >> for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I >> fear we will notice PRNG returning 0 very often) and then NAT it to >> provider provided public IP addresses. >> > Why on earth would you do that? Why not just put the provider-assigned > addresses on the interfaces along side the ULA addresses? Using ULA > in that manner is horribly kludgy and utterly unnecessary. To state the obvious: People are stupid. >> This is to facilitate easy and cheap way to change provider. Getting PI >> address is even harder now, as at least RIPE will verify that you are >> multihomed, while many enterprises don't intent to be, they just need low >> cost ability to change operator. >> > Why is that easier/cheaper than changing your RAs to the new provider and > letting the old provider addresses time out? Well it's not cheaper but using NAT (and multiple NAT) leads to job security as nobody else will understand the network. BTST. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From lists at quux.de Sun Jul 25 23:13:07 2010 From: lists at quux.de (Jens Link) Date: Mon, 26 Jul 2010 06:13:07 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <20100724082932.GA12472@mx.ytti.net> (Saku Ytti's message of "Sat\, 24 Jul 2010 11\:29\:32 +0300") References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> Message-ID: <87zkxej2y4.fsf@oban.berlin.quux.de> Saku Ytti writes: > RFC4193 + NAT quite simply is what they know and are comfortable with. NAT is *not simple*. NAT adds one more layer of complexity. When using multiple NAT things get worse. In most cases people don't want or need NAT they are just used to it and old habits die hard. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From joe at nethead.com Sun Jul 25 23:24:03 2010 From: joe at nethead.com (Joe Hamelin) Date: Sun, 25 Jul 2010 21:24:03 -0700 Subject: FW: Who controlls the Internet? In-Reply-To: <000301cb2c74$7e41c8a0$7ac559e0$@just-micro.com> References: <6AC149DF-F0B3-4BDE-9BDB-D506197B3CBD@ianai.net> <4C4C88F6.5050409@rollernet.us> <988255.20513.qm@web59612.mail.ac4.yahoo.com> <000301cb2c74$7e41c8a0$7ac559e0$@just-micro.com> Message-ID: I thought that Randy Bush won it from Paul Vixie in a poker game. Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From lists at quux.de Sun Jul 25 23:24:04 2010 From: lists at quux.de (Jens Link) Date: Mon, 26 Jul 2010 06:24:04 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <38E7A759-F062-4F0B-903F-29B4C1F66DF7@delong.com> (Owen DeLong's message of "Fri\, 23 Jul 2010 08\:33\:19 -0700") References: <8AC1FEFF-C2A5-4063-BB26-8F11BB1985EE@delong.com> <87hbjqa5o5.fsf@oban.berlin.quux.de> <38E7A759-F062-4F0B-903F-29B4C1F66DF7@delong.com> Message-ID: <87mxtej2fv.fsf@oban.berlin.quux.de> Owen DeLong writes: >> You know that, I know that and (hopefully) all people on this list know >> that. But NAT == security was and still is sold by many people. >> > So is snake oil. Ack, but people are still buying snake oil too. >> After one of my talks about IPv6 the firewall admins of a company said >> something like: "So we can't use NAT as an excuse anymore and have to >> configure firewall rules? We don't want this." >> > So how did you answer him? To be honest: I don't remember. I got drunk that evening. ;-) > The correct answer is "No, you don't have to configure rules, you just need > one rule supplied by default which denies anything that doesn't have a > corresponding outbound entry in the state table and it works just like NAT > without the address mangling". They used NAT as an excuse not to let some applications to the outside. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From mpalmer at hezmatt.org Mon Jul 26 00:07:02 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Mon, 26 Jul 2010 15:07:02 +1000 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <87mxtej2fv.fsf@oban.berlin.quux.de> References: <8AC1FEFF-C2A5-4063-BB26-8F11BB1985EE@delong.com> <87hbjqa5o5.fsf@oban.berlin.quux.de> <38E7A759-F062-4F0B-903F-29B4C1F66DF7@delong.com> <87mxtej2fv.fsf@oban.berlin.quux.de> Message-ID: <20100726050702.GV19771@hezmatt.org> On Mon, Jul 26, 2010 at 06:24:04AM +0200, Jens Link wrote: > Owen DeLong writes: > > The correct answer is "No, you don't have to configure rules, you just need > > one rule supplied by default which denies anything that doesn't have a > > corresponding outbound entry in the state table and it works just like NAT > > without the address mangling". > > They used NAT as an excuse not to let some applications to the > outside. That's OK, if it's NAT unfriendly, chances are it requires deep packet inspection to make the state tables do the right thing anyway. - Matt -- Skippy was a wallaby. ... Wallabies are dumb and not very trainable... The *good* thing...is that one Skippy looks very much like all the rest, hence..."one-shot Skippy" and "plug-compatible Skippy". I don't think they ever had to go as far as "belt-fed Skippy" -- Robert Sneddon, ASR From drc at virtualized.org Mon Jul 26 00:05:56 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 26 Jul 2010 07:05:56 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <87AE246B-A12D-4A66-94A7-53C96303687B@delong.com> References: <201007241749.SAA14213@sunf10.rd.bbc.co.uk> <31D602B9-4C7F-4958-AF08-88AEAD5CA504@delong.com> <8B9FA608-FB8B-4152-97BC-7F8366E37DE8@virtualized.org> <87AE246B-A12D-4A66-94A7-53C96303687B@delong.com> Message-ID: Owen, > Correct, now, what portion of ICANN's budget is related to the NRO sector? Read the ICANN budget. ICANN does not budget things that way. You asked "explain how the numbers side of IANA pays for anything when the RIRs stop funding it?" Doug and I, who have a bit of knowledge on the subject, have told you IANA does not "pay for anything". ICANN is a signatory to a contract with the US Department of Commerce that requires ICANN to provide the IANA functions, of which numbers allocation is one. Failure to perform any of the functions would be interpreted by DoC as a breach of contract. If the NRO did not contribute the (currently) 1.5% (which they have withheld in the past), ICANN would still be required to perform the number allocation function (as they did even when the RIR contribution was withheld). There is _no_ linkage between the contributions made by any stakeholder and the operation of the IANA functions contract. In the case of coordinating ULA assignments, I have no doubt IANA staff at ICANN _could_ provide the function quite easily since most of the infrastructure and processes are already in place for other services ICANN provides as part of the IANA functions contract. The question of whether or not the community, including folks from the RIR community and the IETF, want ICANN to perform that service is entirely different, and highly non-technical. Regards, -drc From randy at psg.com Mon Jul 26 01:12:16 2010 From: randy at psg.com (Randy Bush) Date: Mon, 26 Jul 2010 08:12:16 +0200 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: > For example when users from Sudan trying to access some web site they > will get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site > because your IP address appears form country black listed due to USA > government policy. > > I would like to issue a question here, who controls this Internet? clearly, the united states government does randy From tme at americafree.tv Mon Jul 26 02:04:53 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 26 Jul 2010 03:04:53 -0400 Subject: Who controlls the Internet? In-Reply-To: <000101cb2c74$60a44d40$21ece7c0$@just-micro.com> References: <000101cb2c74$60a44d40$21ece7c0$@just-micro.com> Message-ID: On Jul 25, 2010, at 11:41 PM, Robert West wrote: > > > -----Original Message----- > From: Robert West [mailto:robert.west at just-micro.com] > Sent: Sunday, July 25, 2010 10:56 PM > To: 'Tarig Yassin' > Subject: RE: Who controlls the Internet? > > Each individual government seems to control the information the > enters or > leaves their borders. Do a search for "Internet Censorship > Wikileaks". > Every government has their own set of morals and standards and > politically > motivated black list. Certainly the USA wants to swagger and force > its will > on not only its own people but the entire planet, but they are not > alone. > Australia, China, North Korea, Germany........ Etc............ All > with > their own agenda. It would be great if there was ONE entity that > controlled > content and each country had to abide by their decisions in order to > have > access to the backbone but that's only just a dream at this point. Dream ? That's a nightmare. It would rapidly lead to the worst of both worlds. Internet rules would be made like intellectual property rules, in the dead of night by non-elected government bureaucrats at the behest of corporate lobbyists. Study the history of ACTA if you doubt me. Regards Marshall > The flat > earth that should be the flow of information needs to be demanded by > everyone. > > That's my 13 cents worth. > > (Inflation sucks) > > But who am I but just a thinking and caring animal of this planet? > > Bob- > > > > -----Original Message----- > From: Tarig Yassin [mailto:tariq198487 at hotmail.com] > Sent: Sunday, July 25, 2010 1:24 PM > To: nanog > Subject: Who controlls the Internet? > > > Deal all > > > > I want to show you some obstacles that some countries face them > every day. > > > > For example when users from Sudan trying to access some web site > they will > get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site > because > your IP address appears form country black listed due to USA > government > policy. > > > > I would like to issue a question here, who controls this Internet? > > > > > ThanksTarig > _________________________________________________________________ > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. > https://signup.live.com/signup.aspx?id=60969 > > > From Jared.Hirst at serversaustralia.com.au Mon Jul 26 02:15:49 2010 From: Jared.Hirst at serversaustralia.com.au (Jared Hirst) Date: Mon, 26 Jul 2010 07:15:49 +0000 Subject: Who controlls the Internet? In-Reply-To: References: <000101cb2c74$60a44d40$21ece7c0$@just-micro.com> Message-ID: <7EBAC712-423D-417B-83BB-990E44189226@serversaustralia.com.au> Internet filtering in Australia is yet to come in, however give it time and Australia will have filters in place to block all content that the government deems inappropriate! Just do a google for filtering in Australia! Kindest Regards, Jared Hirst Sent from my iPhone On 26/07/2010, at 5:06 PM, Marshall Eubanks wrote: > > On Jul 25, 2010, at 11:41 PM, Robert West wrote: > >> >> >> -----Original Message----- >> From: Robert West [mailto:robert.west at just-micro.com] >> Sent: Sunday, July 25, 2010 10:56 PM >> To: 'Tarig Yassin' >> Subject: RE: Who controlls the Internet? >> >> Each individual government seems to control the information the enters or >> leaves their borders. Do a search for "Internet Censorship Wikileaks". >> Every government has their own set of morals and standards and politically >> motivated black list. Certainly the USA wants to swagger and force its will >> on not only its own people but the entire planet, but they are not alone. >> Australia, China, North Korea, Germany........ Etc............ All with >> their own agenda. It would be great if there was ONE entity that controlled >> content and each country had to abide by their decisions in order to have >> access to the backbone but that's only just a dream at this point. > > Dream ? That's a nightmare. It would rapidly lead to the worst of both worlds. Internet rules would be made like intellectual property rules, in the dead of night by non-elected government bureaucrats at the behest of corporate lobbyists. Study the history of ACTA if you doubt me. > > Regards > Marshall > > > >> The flat >> earth that should be the flow of information needs to be demanded by >> everyone. >> >> That's my 13 cents worth. >> >> (Inflation sucks) >> >> But who am I but just a thinking and caring animal of this planet? >> >> Bob- >> >> >> >> -----Original Message----- >> From: Tarig Yassin [mailto:tariq198487 at hotmail.com] >> Sent: Sunday, July 25, 2010 1:24 PM >> To: nanog >> Subject: Who controlls the Internet? >> >> >> Deal all >> >> >> >> I want to show you some obstacles that some countries face them every day. >> >> >> >> For example when users from Sudan trying to access some web site they will >> get a *Forbidden Access Error* message. >> >> And some messages say: you are forbidden to access this web site because >> your IP address appears form country black listed due to USA government >> policy. >> >> >> >> I would like to issue a question here, who controls this Internet? >> >> >> >> >> ThanksTarig >> _________________________________________________________________ >> Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. >> https://signup.live.com/signup.aspx?id=60969 >> >> >> > > From cian.brennan at redbrick.dcu.ie Mon Jul 26 02:53:27 2010 From: cian.brennan at redbrick.dcu.ie (Cian Brennan) Date: Mon, 26 Jul 2010 08:53:27 +0100 Subject: FW: Who controlls the Internet? In-Reply-To: <000101cb2c74$60a44d40$21ece7c0$@just-micro.com> References: <000101cb2c74$60a44d40$21ece7c0$@just-micro.com> Message-ID: <20100726075327.GA15187@minerva.redbrick.dcu.ie> On Sun, Jul 25, 2010 at 11:41:05PM -0400, Robert West wrote: > > > -----Original Message----- > From: Robert West [mailto:robert.west at just-micro.com] > Sent: Sunday, July 25, 2010 10:56 PM > To: 'Tarig Yassin' > Subject: RE: Who controlls the Internet? > > Each individual government seems to control the information the enters or > leaves their borders. Do a search for "Internet Censorship Wikileaks". > Every government has their own set of morals and standards and politically > motivated black list. Certainly the USA wants to swagger and force its will > on not only its own people but the entire planet, but they are not alone. > Australia, China, North Korea, Germany........ Etc............ All with > their own agenda. It would be great if there was ONE entity that controlled > content and each country had to abide by their decisions in order to have > access to the backbone but that's only just a dream at this point. The flat > earth that should be the flow of information needs to be demanded by > everyone. > Not all states (or people for that matter) agree with Voltaire's view of free speech. If our democratically accountable, and elected government wants to ban hate speech/child porn/$OTHER_ILLEGAL_CONTENT, and puts in an accountable method of dealing with it, I find it hard to see why the US view of free speech should prevail over that choice. > That's my 13 cents worth. > > (Inflation sucks) > > But who am I but just a thinking and caring animal of this planet? > > Bob- > > > > -----Original Message----- > From: Tarig Yassin [mailto:tariq198487 at hotmail.com] > Sent: Sunday, July 25, 2010 1:24 PM > To: nanog > Subject: Who controlls the Internet? > > > Deal all > > > > I want to show you some obstacles that some countries face them every day. > > > > For example when users from Sudan trying to access some web site they will > get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site because > your IP address appears form country black listed due to USA government > policy. > > > > I would like to issue a question here, who controls this Internet? > > > > > ThanksTarig > _________________________________________________________________ > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. > https://signup.live.com/signup.aspx?id=60969 > > > From tme at americafree.tv Mon Jul 26 02:55:37 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 26 Jul 2010 03:55:37 -0400 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: <937FE18A-84BE-4D5E-B1B5-2FAD5E2BE9E5@americafree.tv> On Jul 25, 2010, at 1:24 PM, Tarig Yassin wrote: > > Deal all > > > > I want to show you some obstacles that some countries face them > every day. > > > > For example when users from Sudan trying to access some web site > they will get a *Forbidden Access Error* message. > > And some messages say: you are forbidden to access this web site > because your IP address appears form country black listed due to USA > government policy. Well, I don't know of any such US government policy. And we (AmericaFree.TV) have a steady audience in Sudan (including at this very moment), for content streamed from the USA. It would be useful to list what sites for what content. Regards Marshall > > > > I would like to issue a question here, who controls this Internet? > > > > > ThanksTarig > _________________________________________________________________ > Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. > https://signup.live.com/signup.aspx?id=60969 From drc at virtualized.org Mon Jul 26 03:57:26 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 26 Jul 2010 10:57:26 +0200 Subject: ICANN bashing (was Re: Who controlls the Internet?) In-Reply-To: <20100725202139.GC19483@vacation.karoshi.com.> References: <20100725202139.GC19483@vacation.karoshi.com.> Message-ID: <982E0E20-6EFF-444F-9B48-CD830CEBBA32@virtualized.org> Bill, On Jul 25, 2010, at 10:21 PM, bmanning at vacation.karoshi.com wrote: > except ICANN has presumed for itself an operational role. ICANN, since its inception, has been the IANA functions _operator_. It inherited the role IANA staff performed prior to ICANN's creation. As far as I am aware, other than DNSSEC stuff (e.g., handling the root KSK), there has not been a significant change in the operational role ICANN performs beyond what has been requested by the community (if any). > it has taken on root server operations for some years now Yes. I think the folks who run L can be pretty proud of their achievements. Want to compare root server operations? :-) > and is trying to take over root zone editorial control. Actually, no, it isn't. The US Department of Commerce has been pretty clear that they are happy with the current model in which ICANN receives and vets root zone change requests, DoC NTIA authorizes those requests, and VeriSign edits the root zone and publishes it. Despite some portions of the ICANN community not being happy with this state of affairs, I'd be surprised if this changed anytime soon and I'm not aware of anyone in ICANN actively pursuing a change. Regards, -drc (no longer working for ICANN, but feeling a need to defend it against baseless bashing) From bmanning at vacation.karoshi.com Mon Jul 26 04:30:52 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 26 Jul 2010 09:30:52 +0000 Subject: ICANN bashing (was Re: Who controlls the Internet?) In-Reply-To: <982E0E20-6EFF-444F-9B48-CD830CEBBA32@virtualized.org> References: <20100725202139.GC19483@vacation.karoshi.com.> <982E0E20-6EFF-444F-9B48-CD830CEBBA32@virtualized.org> Message-ID: <20100726093052.GB21928@vacation.karoshi.com.> On Mon, Jul 26, 2010 at 10:57:26AM +0200, David Conrad wrote: > Bill, > > On Jul 25, 2010, at 10:21 PM, bmanning at vacation.karoshi.com wrote: > > except ICANN has presumed for itself an operational role. > > ICANN, since its inception, has been the IANA functions _operator_. It inherited the role IANA staff performed prior to ICANN's creation. As far as I am aware, other than DNSSEC stuff (e.g., handling the root KSK), there has not been a significant change in the operational role ICANN performs beyond what has been requested by the community (if any). and here we see how english is a poor language. yes, ICANN is the current IANA functions _operator_. The IANA _never_ ran/operated network infrastructure (root server operations) prior to ICANNs assumption of the role. This is the distinction. Perhaps w/o a difference. > > it has taken on root server operations for some years now > > Yes. I think the folks who run L can be pretty proud of their achievements. Want to compare root server operations? :-) Yes they do a fine job. But root server operations is not in ICANNs charter or mission. Their stated role, when they took it over from USC was as a temporary steward, until they could find someone to take it on. Only later did they back away from that statement and claimed it for their own. > > and is trying to take over root zone editorial control. > > Actually, no, it isn't. The US Department of Commerce has been pretty clear that they are happy with the current model in which ICANN receives and vets root zone change requests, DoC NTIA authorizes those requests, and VeriSign edits the root zone and publishes it. Despite some portions of the ICANN community not being happy with this state of affairs, I'd be surprised if this changed anytime soon and I'm not aware of anyone in ICANN actively pursuing a change. You describe the current state of affairs very well. From a reasonably recent counterpoint, there were several models proposed for the recently augmented root zone mgmt task. One of the proposed (and rejected) models showed a much larger role for ICANN in the root zone generation process. Those of us who reviewed these models (in the NTIA NoI) saw this as a (perhaps reasonable) way to reduce the roles played by the other two actors. > Regards, > -drc > (no longer working for ICANN, but feeling a need to defend it against baseless bashing) Regards, --bill (not baseless bashing, just pointing out some facts) > From ge at linuxbox.org Mon Jul 26 05:47:40 2010 From: ge at linuxbox.org (Gadi Evron) Date: Mon, 26 Jul 2010 13:47:40 +0300 Subject: Who controlls the Internet? In-Reply-To: References: Message-ID: <4C4D67CC.5070702@linuxbox.org> On 7/25/10 8:24 PM, Tarig Yassin wrote: > I would like to issue a question here, who controls this Internet? Vix does, who else? :) Gadi. From franck at genius.com Mon Jul 26 07:00:50 2010 From: franck at genius.com (Franck Martin) Date: Tue, 27 Jul 2010 00:00:50 +1200 (FJT) Subject: Who controlls the Internet? In-Reply-To: Message-ID: <31183047.18.1280145649321.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Tarig Yassin" > > > I would like to issue a question here, who controls this Internet? > The elders of the Internet: http://www.youtube.com/watch?v=iDbyYGrswtg From drc at virtualized.org Mon Jul 26 07:59:49 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 26 Jul 2010 05:59:49 -0700 Subject: ICANN bashing (was Re: Who controlls the Internet?) In-Reply-To: <20100726093052.GB21928@vacation.karoshi.com.> References: <20100725202139.GC19483@vacation.karoshi.com.> <982E0E20-6EFF-444F-9B48-CD830CEBBA32@virtualized.org> <20100726093052.GB21928@vacation.karoshi.com.> Message-ID: Bill, I suspect this thread has degenerated to the point of irrelevance, so this will be my last comment. Feel free to have the last word. On Jul 26, 2010, at 2:30 AM, bmanning at vacation.karoshi.com wrote: > yes, ICANN is the current IANA functions _operator_. The IANA _never_ > ran/operated network infrastructure (root server operations) prior to ICANNs > assumption of the role. This is the distinction. Perhaps w/o a difference. As when IANA was operated by USC, IANA staff (still) do not run root server operations. The ICANN group that run the root server (and do other DNS things) are distinct from the folks who do IANA stuff. I would argue that IANA staff have always had an operational role in the management of the various registries and any additional operational activities performed by ICANN were requested by the community. I'm sure you disagree. > Yes they do a fine job. But root server operations is not in ICANNs charter or > mission. Their stated role, when they took it over from USC was as a temporary > steward, until they could find someone to take it on. Only later did they > back away from that statement and claimed it for their own. True, if somewhat negatively skewed and abbreviated. If I understand correctly (since I was doing other things in the timeframe we're talking here), a set of new root servers were created to fill up the 512 byte response and a Cooperative Research and Development Agreement (CRADA) between NTIA/NIST and ICANN was undertaken to establish where the new root server(s) were to be distributed (among many other things, see http://www.icann.org/en/committees/dns-root/crada.htm). However, my understanding (since I wasn't involved in root operations back then) was that no real progress was made on the CRADA. Folks who were involved in that CRADA might wish to correct me or expand on why. Without resolution of the CRADA, I'd imagine ICANN acting unilaterally would have generated far more criticism. >>> and is trying to take over root zone editorial control. > You describe the current state of affairs very well. Yes, you used present tense so describing current state of affairs seemed appropriate. Regards, -drc From michael.dinn at airfire.ca Mon Jul 26 08:50:32 2010 From: michael.dinn at airfire.ca (Michael 'Moose' Dinn) Date: Mon, 26 Jul 2010 10:50:32 -0300 Subject: 3com switching geeks? Message-ID: <20100726135032.GX15636@blend.twistedpair.ca> Any 3com switching geeks out there? Contact me offlist if you don't mind a question or two. thanks From patrick at ianai.net Mon Jul 26 09:00:01 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 26 Jul 2010 10:00:01 -0400 Subject: Who controlls the Internet? In-Reply-To: <000101cb2c74$60a44d40$21ece7c0$@just-micro.com> References: <000101cb2c74$60a44d40$21ece7c0$@just-micro.com> Message-ID: On Jul 25, 2010, at 11:41 PM, Robert West wrote: > Each individual government seems to control the information the enters or > leaves their borders. No, each individual government can have laws restricting information entering and leaving their borders. Few gov'ts actually control said info. The US gov't most certainly does not (despite the tin-foil-hat brigades protestations to the contrary). > Do a search for "Internet Censorship Wikileaks". > Every government has their own set of morals and standards and politically > motivated black list. Certainly the USA wants to swagger and force its will > on not only its own people but the entire planet, but they are not alone. Nice political blather. What has it got to do on the point at hand. (Also, I would be very happy if every gov't on the planet were as open with information exchange / lax on information control as the USG is.) > Australia, China, North Korea, Germany........ Etc............ All with > their own agenda. It would be great if there was ONE entity that controlled > content and each country had to abide by their decisions in order to have > access to the backbone but that's only just a dream at this point. The flat > earth that should be the flow of information needs to be demanded by > everyone. I believe someone else explained just how stupid an idea that was. So I will just add my voice to the idea that multiple unrelated entities running the 'Net is much better than a single, central control. -- TTFN, patrick From brunner at nic-naa.net Mon Jul 26 09:33:10 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 26 Jul 2010 10:33:10 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <4C2DF0F8.9060909@abenaki.wabanaki.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> Message-ID: <4C4D9CA6.1040201@nic-naa.net> There are a few people who have some passing interest in ICANN so I will inflict upon the list my few paragraph summary of things that matter, see also my July 2nd post: I went so you don't have to -- ICANN Bruxelles pour les nuls. The initial report of the 65 person VI WG is published. Registry contracts executed in the 2001 and 2004 new gTLD rounds limited Registry ownership of Registrars at 15%, an artifact of the VGRS/NSI split up, with no limit on registrar ownership of registries, allowing the formation of NeuLevel (.biz through Melbourne IT and NeuStar), and the formation of Afilias (.info by several registries). At the Nairobi ICANN meeting the ICANN Board established the cross-ownership in either directions at 0%, and called for the GNSO to originate some alternative to strict structural separation, if it could arrive at such a policy be consensus. In DAGv4, publish just before the Brussels meeting, ICANN Staff proposed a cross-ownership cap of 2%. That sets the stage. The Initial Report is the first step towards policy concerning the possibility of allowing vertical integration in the DNS registry-registrar market. There are three basic positions on the issues, and a fourth position. The three basic positions are: (a) stay at 15%, that makes compliance easy, and no one has really gamed this restriction, (b) allow full integration conditionally, with serious compliance, and allow several exceptions (see also the fourth position) (c) no restriction on integration, no harms will result so compliance is not important, and exceptions are unnecessary (see also the fourth position). These policy positions are advocated by: (a) Afilias, PIR, GoDaddy, several NomCom appointees and others, including myself (for CORE), subject to some functional exceptions relating to registry services provisioning and market share, (b) NeuStar, Network Solutions, Verisign, Enom, and several others, (c) Several smaller (than the top 4) registrars and some people from the Business Constituency and some Free Market ideologues. In terms of balance of forces, it is pretty much a three-way tie. The fourth position is the Intellectual Property Constituency, which seeks an exception for brand owners, and no others, from whatever limits are proposed on cross-ownership. It has no support outside of the IPC, but when all the inchoate "exceptions for X" are summed, there is the appearance of strong support for what is called "single registrant" type applications. I recommend to those employed in the ISP industry the statement of the ISPCP, at pages 90 and 91. There are a lot of nuances, or tinfoil hat dress up opportunities. If Verisign, Afilias, NeuStar, CORE and Midcounties Co-operative Domains run almost all of the gTLDs, and are ineligible to provide registry services to the new gTLD applicants, what existing operators will be favored? What capitalization will start-up operators have to secure to meet the SLA, DNSSEC, continuity instrument and other costs in excess of the application fee and subsequent fees the new applicants must capitalize? Are the Free Trade Guys and ICANN's economists right, the market will correct any abuses and competition authorities will be there when the market doesn't correct an abuse? Is "continuity" or "change" the better policy w.r.t. the registry function and the registrar function? I trust this will be at least as useful as the jrandom luser plaint concerning what singular Animal, Mineral or Vegetable controls the singular capital-I Internet and the IANA function sniping. Oblig disclosure. The VI WG has been more than a quarter of my paid time since it began. I'm in the "continuity" camp and my Statement of Interests is linked to from the Initial Report. An outcome I'd like to see avoided is registrars preferentially selling their own-or-partner inventories, resulting in a by-registrar-affiliation partition of the non-state DNS as a market not dependent upon state actors, resulting in reduced competition with the legacy gTLD registry operators and their properties. Yeah. I know. Nothing other than redelegation of .org has created competition for Verisign. Eric From jmamodio at gmail.com Mon Jul 26 11:45:09 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 26 Jul 2010 11:45:09 -0500 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <4C4D9CA6.1040201@nic-naa.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> Message-ID: You forgot the fifth option. Invade a country (invasion is not strictly required) and take over control of their ccTLD which probably does not have an agreement with ICANN so you can charge and do as you please. Many of the greedy registrars will be more than happy to sell the name ... Get your dotCO before they are all gone !!! Cheers Jorge From brunner at nic-naa.net Mon Jul 26 13:42:03 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 26 Jul 2010 14:42:03 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> Message-ID: <4C4DD6FB.2040303@nic-naa.net> On 7/26/10 12:45 PM, Jorge Amodio wrote: > You forgot the fifth option. > > Invade a country (invasion is not strictly required) and take over > control of their ccTLD which probably does not have an agreement with > ICANN so you can charge and do as you please. Many of the greedy > registrars will be more than happy to sell the name ... Umm, I wish there had been more people who paid attention when the .iq registry was subject to ... a voluntary change of control resulting in ... things being done as one pleased. But I do take your point about .co/.com, and in all fairness, it is a decade delayed favor returned by NeuStar to Verisign for the .bz/.biz "collaborative marketing" ploy of 2001. When Hewlett-Packard wrote to ICANN earlier this year that it should get .hp, the obvious rejoinder was "Buy a country like everyone else, submit a change request to the iso3166/MA, and do business under .hp, your new country code property." Apparently HP didn't want to actually buy a country first. Cheapskates. Now seriously, just how many pages of the IV Initial Report did you read before coming up with "the fifth option"? Eric From jmamodio at gmail.com Mon Jul 26 14:28:59 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 26 Jul 2010 14:28:59 -0500 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <4C4DD6FB.2040303@nic-naa.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> <4C4DD6FB.2040303@nic-naa.net> Message-ID: > Now seriously, just how many pages of the IV Initial Report did you read > before coming up with "the fifth option"? I read the entire thing. Of the 138 pages, take out the Summary, the ToC and several of the Annexes where many of them are sort of cut & past of discussions/text circulated through email lists/blogs/tweets, and positions that were clearly stated in meetings and conference calls, you are left with few pages with some novelty stuff. Hard to believe there will be any consensus before the Cartagena meeting (even after), the BoD will end directing staff to use the magic wand and negotiate something with VeriDaddy and NeuSign. Regards Jorge From bzs at world.std.com Mon Jul 26 15:04:55 2010 From: bzs at world.std.com (Barry Shein) Date: Mon, 26 Jul 2010 16:04:55 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <4C4DD6FB.2040303@nic-naa.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> <4C4DD6FB.2040303@nic-naa.net> Message-ID: <19533.60007.823008.406460@world.std.com> On July 26, 2010 at 14:42 brunner at nic-naa.net (Eric Brunner-Williams) wrote: > > When Hewlett-Packard wrote to ICANN earlier this year that it should > get .hp, the obvious rejoinder was "Buy a country like everyone else, > submit a change request to the iso3166/MA, and do business under .hp, > your new country code property." Apparently HP didn't want to actually > buy a country first. Cheapskates. HP doesn't even have HP as a stock symbol, that'd be Helmerich & Payne, a contract oil/gas driller. The computer company can be traded under symbol HPC. "Happy name spaces are all alike; every unhappy name space is unhappy in its own way." -- !Tolstoy -- -Barry Shein The World | bzs at TheWorld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD | Dial-Up: US, PR, Canada Software Tool & Die | Public Access Internet | SINCE 1989 *oo* From brunner at nic-naa.net Mon Jul 26 15:09:43 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 26 Jul 2010 16:09:43 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> <4C4DD6FB.2040303@nic-naa.net> Message-ID: <4C4DEB87.7040400@nic-naa.net> On 7/26/10 3:28 PM, Jorge Amodio wrote: >> Now seriously, just how many pages of the IV Initial Report did you read >> before coming up with "the fifth option"? > > I read the entire thing. Of the 138 pages, take out the Summary, the > ToC and several of the Annexes where many of them are sort of cut& > past of discussions/text circulated through email lists/blogs/tweets, > and positions that were clearly stated in meetings and conference > calls, you are left with few pages with some novelty stuff. Being one of the rare known external readers, is there any bit of it you have a view on not already reflected in the para above and below? > Hard to believe there will be any consensus before the Cartagena > meeting (even after), the BoD will end directing staff to use the That was my initial view, that there would be consensus around three proposed policy -- a 15% cap with minor variation, no cap with minor variation, and happy brand owners, with no consensus between any two of these three positions. Now I think the no-cap advocates and the brand advocates will tactically compromise. > magic wand and negotiate something with VeriDaddy and NeuSign. Actually the alliances visible at present are: JN2 proposal: Verisign, NeuStar, NetSol and eNom and others, RACK proposal: Afilas, PIR, GoDaddy, and others, including CORE. I look forward to your public comments, here or at the ICANN comment site. Eric From jfbeam at gmail.com Mon Jul 26 15:30:07 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 26 Jul 2010 16:30:07 -0400 Subject: IPv4 Exhaustion... In-Reply-To: <001c01cb2ab0$1cc40450$564c0cf0$@org> References: <001c01cb2ab0$1cc40450$564c0cf0$@org> Message-ID: On Fri, 23 Jul 2010 17:43:39 -0400, Lee Howard wrote: > RIAA should be IPv6 activists. Right. That's not going to bite them on the ass either... privacy addresses only stick around for ~72hrs. A demand for an address from 3 months back would be impossible to answer. (that would require L2 tracking that an ISP simply cannot do.) From mike at mtcc.com Mon Jul 26 15:36:00 2010 From: mike at mtcc.com (Michael Thomas) Date: Mon, 26 Jul 2010 13:36:00 -0700 Subject: IPv4 Exhaustion... In-Reply-To: References: <001c01cb2ab0$1cc40450$564c0cf0$@org> Message-ID: <4C4DF1B0.1050807@mtcc.com> On 07/26/2010 01:30 PM, Ricky Beam wrote: > On Fri, 23 Jul 2010 17:43:39 -0400, Lee Howard wrote: >> RIAA should be IPv6 activists. > > Right. That's not going to bite them on the ass either... privacy > addresses only stick around for ~72hrs. A demand for an address from 3 > months back would be impossible to answer. (that would require L2 > tracking that an ISP simply cannot do.) Actually, what they'd probably really like is HIP (host identity payload). Mike, I don't think it went anywhere though From jfbeam at gmail.com Mon Jul 26 15:45:07 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 26 Jul 2010 16:45:07 -0400 Subject: IPv4 Exhaustion... In-Reply-To: References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> Message-ID: On Sat, 24 Jul 2010 04:48:13 -0400, Owen DeLong wrote: > ... Very Interesting Times for ISPs that deploy LSN and are subject to > CALEA. CALEA is not a time machine. When an order is received, the "collection agency" starts receiving traffic; nothing (or at most, very little) is known prior to the wiretap order. Put another way, you cannot be ordered to produce tapes of phone call that happened a month ago. (CALEA only says you must have the ability to monitor anyone; not that you must be monitoring everyone to have "stuff" available before being asked for it.) With CALEA, you're innocent until there's a reason to think otherwise. With the RIAA/MPAA/et.al., we're all guilty, all the time, so everything should be monitored until they get around to suing, err, extorting us. --Ricky From deepak at ai.net Mon Jul 26 16:02:13 2010 From: deepak at ai.net (Deepak Jain) Date: Mon, 26 Jul 2010 17:02:13 -0400 Subject: IPv4 Exhaustion... In-Reply-To: References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> Message-ID: > CALEA is not a time machine. When an order is received, the > "collection > agency" starts receiving traffic; nothing (or at most, very little) is > known prior to the wiretap order. Put another way, you cannot be > ordered > to produce tapes of phone call that happened a month ago. (CALEA only > says > you must have the ability to monitor anyone; not that you must be > monitoring everyone to have "stuff" available before being asked for > it.) > Another point about CALEA is that you don't *have* to have infrastructure in place in advance of the order. You simply have to provide Law Enforcement the wiretaps they are asking for -- however you accomplish it. You don't need to solve for every case, just the case they ask of you at the time. This keeps the cost of compliance way down (provided you don't need these for a significant percentage of your user base). Between e-discovery and RIAA issues, retention times are probably shrinking even though capacity for retention is growing. Deepak Jain AiNET From jfbeam at gmail.com Mon Jul 26 16:05:07 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 26 Jul 2010 17:05:07 -0400 Subject: IPv4 Exhaustion... In-Reply-To: References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> <101106.1280003312@localhost> Message-ID: On Sat, 24 Jul 2010 16:36:08 -0400, Christopher Morrow wrote: > say, i wonder how many actual calea requests have been sent out > anyway?? (I know one very large network has yet to get a single one, > or so the grape vine tells me.) I see this asked a lot... http://www.askcalea.net/reports/wiretap.html [2009] http://www.askcalea.net/reports/docs/2009wiretap.pdf (warning: 314pg verbose report) From deepak at ai.net Mon Jul 26 16:09:55 2010 From: deepak at ai.net (Deepak Jain) Date: Mon, 26 Jul 2010 17:09:55 -0400 Subject: IPv4 Exhaustion... In-Reply-To: References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> <101106.1280003312@localhost> Message-ID: > I see this asked a lot... > > http://www.askcalea.net/reports/wiretap.html > > [2009] http://www.askcalea.net/reports/docs/2009wiretap.pdf (warning: > 314pg verbose report) To save yourself the trouble (pg 8 of the slow 5MB download): Telephone wiretaps accounted for 98 percent (1,720 cases) of the intercepts installed in 2009, the majority of them involving cellular telephones. I think it's safe to say CALEA is a non-issue for this crowd. It's also safe to say that RIAA is more of a nuisance than a real issue. Manage your retention times with e-discovery in mind and you don?t need to worry about RIAA issues either. :) From rubensk at gmail.com Mon Jul 26 16:32:26 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 26 Jul 2010 18:32:26 -0300 Subject: IPv4 Exhaustion... In-Reply-To: References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> Message-ID: > Between e-discovery and RIAA issues, retention times are probably shrinking even though capacity for retention is growing. Capacity for retention has grown but one still needs fast searching of data, or a few LEA requests on the same day or week will overflow your capacity to answer them. Disks are cheap, a good DW is not, for logs you probably need something in the middle. Simple tar-gzipping will get you crazy some day. Rubens From jfbeam at gmail.com Mon Jul 26 16:50:08 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 26 Jul 2010 17:50:08 -0400 Subject: IPv4 Exhaustion... In-Reply-To: References: <1101219972-1279906580-cardhu_decombobulator_blackberry.rim.net-1881903051-@bda903.bisx.prod.on.blackberry> <06B8EDAF-BAA0-445D-BC50-2FAA10E3ECD3@cs.columbia.edu> <101106.1280003312@localhost> Message-ID: On Mon, 26 Jul 2010 17:09:55 -0400, Deepak Jain wrote: > I think it's safe to say CALEA is a non-issue for this crowd. That's true for now. But with an increasingly data hungry world, and VoIP popularity, ISPs aren't going to escape CALEA forever. There are reasons IOS has provisions for CALEA :-) (and for the record, CALEA is a non-issue for most telcos. the telco I used to work for has never had a wiretap order, and didn't start any CALEA mess until 2003.) --Ricky From joly at punkcast.com Mon Jul 26 17:00:03 2010 From: joly at punkcast.com (Joly MacFie) Date: Mon, 26 Jul 2010 18:00:03 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <4C4DEB87.7040400@nic-naa.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> <4C4DD6FB.2040303@nic-naa.net> <4C4DEB87.7040400@nic-naa.net> Message-ID: I found Milton Mueller's summary - noted at http://www.isoc-ny.org/p2/?p=1006- useful. Is there anything there that you would disagree with? j On Mon, Jul 26, 2010 at 4:09 PM, Eric Brunner-Williams wrote: > Actually the alliances visible at present are: > > JN2 proposal: Verisign, NeuStar, NetSol and eNom and others, > > RACK proposal: Afilas, PIR, GoDaddy, and others, including CORE. > > I look forward to your public comments, here or at the ICANN comment site. > > Eric > > -- --------------------------------------------------------------- Joly MacFie? 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com ?http://pinstand.com - http://punkcast.com ? Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From franck at genius.com Mon Jul 26 18:11:54 2010 From: franck at genius.com (Franck Martin) Date: Tue, 27 Jul 2010 11:11:54 +1200 (FJT) Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: Message-ID: <7666130.42.1280185909730.JavaMail.franck@franck-martins-macbook-pro.local> The question too, is which model is mitigating the best the presence of rogue registrars (like domain tasting registrars, etc..) ----- Original Message ----- From: "Joly MacFie" To: "Eric Brunner-Williams" Cc: nanog at nanog.org Sent: Tuesday, 27 July, 2010 10:00:03 AM Subject: Re: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies I found Milton Mueller's summary - noted at http://www.isoc-ny.org/p2/?p=1006- useful. Is there anything there that you would disagree with? j On Mon, Jul 26, 2010 at 4:09 PM, Eric Brunner-Williams wrote: > Actually the alliances visible at present are: > > JN2 proposal: Verisign, NeuStar, NetSol and eNom and others, > > RACK proposal: Afilas, PIR, GoDaddy, and others, including CORE. > > I look forward to your public comments, here or at the ICANN comment site. > > Eric > > -- --------------------------------------------------------------- Joly MacFie? 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com ?http://pinstand.com - http://punkcast.com ? Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From brunner at nic-naa.net Mon Jul 26 18:16:49 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 26 Jul 2010 19:16:49 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> <4C4DD6FB.2040303@nic-naa.net> <4C4DEB87.7040400@nic-naa.net> Message-ID: <4C4E1761.3010009@nic-naa.net> On 7/26/10 6:00 PM, Joly MacFie wrote: > I found Milton Mueller's summary - noted at > http://www.isoc-ny.org/p2/?p=1006- useful. > > Is there anything there that you would disagree with? He errors in characterizing the position statements as static, rather than evolving over time. His own position is now in its 3rd iteration. 1. He errors in describing DAGv4 as the Nairobi Resolution. The cross ownership limit at Nairobi was 0%. The same cross ownership limit in DAGv4 is 2%. Under a Zero rule, none of Verisign, Afilias, NeuStar, Core and Midlands would be allowed to provide registry services to new gTLD applicants, or to apply for new gTLDs in their own right, as all have non-zero registrar ownership. Under a 2% rule, Verisign's market cap, and CORE's membership model, and perhaps NeuStar's market cap and resolution of the NeuLevel partnership with Melbourne IT, a registrar, would be allowed, and Afilias and Midlands would not be allowed, to provide registry services to new gTLD applicants, or to apply for new gTLDs in their own right, as all have less than 2% registrar ownership. [There is a nuance in the CORE 2% question. CORE has more than 50 members, and the question goes to whether control is properly aggregated by individual independent members.] 2. He errors in particular in characterizing the RACK+ position as without exceptions. He also uses "status quo" rather than accurately characterizing the proposal, which is a different form of error. And it is RACK+, not RACK. 3. He errors in particular in characterizing the Free Trade position as without limitations. There are limitations, one of which is the rejection of "harms" and compliance as a necessity. 4. He errors in particular in characterizing the JN2 position as without limitations other than no self-sales. There is a 15% cap for the first 18 months and exceptions from that require conditional approval, and a significant commitment to compliance as a deterrent to "harms". And it is JN2, not JN2+ (the post-JN2 position developed at Brussels is not described). 5. He errors in omitting to mention that the "special panel" is composed of the competition authorities of some states, e.g., the US DOJ Antitrust Division, is going to review in finite time applications by, let us say, the United Mine Workers of America for .appalachia, in which the UMWA proposes to acquire 16% or more of the largest registrar in West Virginia, or the example of your choice in Lower Elbonia. He also manages not to point out how many supporters there are for his proposal. 6. He errors in assigning percentages to positions in polls. 7. He errors in stating that the VI WG is "tasked with coming up with a solution before the ICANN board next meets in September." That would be convenient for the hypothetical new gTLD round, but the VI WG is tasked with coming up with a policy proposal, if not now, before the heat death of the universe. 8. Make up your own #8, it is a target rich environment. Eric From brunner at nic-naa.net Mon Jul 26 18:37:02 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 26 Jul 2010 19:37:02 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <7666130.42.1280185909730.JavaMail.franck@franck-martins-macbook-pro.local> References: <7666130.42.1280185909730.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C4E1C1E.3080801@nic-naa.net> On 7/26/10 7:11 PM, Franck Martin wrote: > The question too, is which model is mitigating the best the presence of rogue registrars (like domain tasting registrars, etc..) Franck, First, tasting is only a part of the extensions from the registrant serving business model that ICANN explicitly allows, due in part to the advocacy by Professor Mueller and others circa 1999 that ICANN has no business in determining business models. So rather than characterize registrars who used the Add Grace Period for purposes of acquiring domains with "natural traffic" under a PPC business model as "rogue", you might consider whether Google primarily, but not exclusively, and ICANN, created the system whereby "natural traffic" in the .com namespace could be monitized by exploits of the AGP. That particular problem has been resolved, but the rest of the ecology of "upstream" and "backorder" is untouched. But assuming that "rogue registrars" is a useful tool (and I encourage you and anyone else interested in registrars to review the 900 or so ICANN accreditations and observe the marvelous ownerships of Enom, Snapname, Directi and Dotster, and those are simply for the aftermarket (drop pool) for expired names), and "tasting" is a useful referent (both of which I think miss the central issues), then the model question is well posed. In what follows, "ROI" refers to return on investment for bad acts. The 15% cap proponents think that structural separation removes the ROI incentive. The integration proponents think that (jn2) compliance will remove the ROI incentive, and (freetrade) that ROI will not incent, so compliance is unnecessary. The competition authority proponents think that ROI is irrelevant. So yeah, pick your model. Pick with care. Eric From nenolod at systeminplace.net Mon Jul 26 18:50:05 2010 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 26 Jul 2010 18:50:05 -0500 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <4C4DD6FB.2040303@nic-naa.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> <4C4DD6FB.2040303@nic-naa.net> Message-ID: <1280188205.18294.7.camel@petrie> On Mon, 2010-07-26 at 14:42 -0400, Eric Brunner-Williams wrote: > But I do take your point about .co/.com, and in all fairness, it is a > decade delayed favor returned by NeuStar to Verisign for the .bz/.biz > "collaborative marketing" ploy of 2001. Or eNom's .cc/.com ploy from 1999-present. Don't you remember the television ad buy they did on all of the networks? Rednecks dancing around playing fiddles singing about ".cc". On the other hand, at least they weren't showing soft porn like GoDaddy does. William From brunner at nic-naa.net Mon Jul 26 19:22:10 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 26 Jul 2010 20:22:10 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <1280188205.18294.7.camel@petrie> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> <4C4DD6FB.2040303@nic-naa.net> <1280188205.18294.7.camel@petrie> Message-ID: <4C4E26B2.7020101@nic-naa.net> On 7/26/10 7:50 PM, William Pitcock wrote: > On Mon, 2010-07-26 at 14:42 -0400, Eric Brunner-Williams wrote: >> But I do take your point about .co/.com, and in all fairness, it is a >> decade delayed favor returned by NeuStar to Verisign for the .bz/.biz >> "collaborative marketing" ploy of 2001. > > Or eNom's .cc/.com ploy from 1999-present. Don't you remember the > television ad buy they did on all of the networks? Rednecks dancing > around playing fiddles singing about ".cc". On the other hand, at least > they weren't showing soft porn like GoDaddy does. Sorry, ENOTEEVEE. I'll have to imagine my folks with fiddles singing about a repurposed ccTLD. GoDaddy's advertising use of a NASCAR driver is not quite a "vertical integration" issue. Could y'all please keep up with the geezer play'n washboard or the boy blow'n jug? Dance, sing or holl'r as you like. Thankee. Eric From jmamodio at gmail.com Mon Jul 26 19:46:07 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 26 Jul 2010 19:46:07 -0500 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: <4C4DEB87.7040400@nic-naa.net> References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> <4C4DD6FB.2040303@nic-naa.net> <4C4DEB87.7040400@nic-naa.net> Message-ID: > Being one of the rare known external readers, is there any bit of it you > have a view on not already reflected in the para above and below? There is another dimension to the whole enchilada that makes a compromise a moving shooting target. Some of the entities at the table don't like or want at all new gTLDs, today they may say "we like milkshakes with anchovies and we can live with that" (not really), tomorrow they will say "we only drink our brand of tomato juice". At least a byproduct of the outcome of this WG is that as observers we are getting a more clear picture of who is on each side today before any compromise. GNSO was very explicit that this can not introduce additional delays to the gTLD program so sooner or later a compromise position is needed, what if the GNSO is not able to provide a recommendation on time, what the BoD will do ? Regards Jorge From brunner at nic-naa.net Mon Jul 26 20:13:50 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Mon, 26 Jul 2010 21:13:50 -0400 Subject: I slogged through it so you don't have to -- ICANN Vertical Integration WG for dummies In-Reply-To: References: <4C2DF0F8.9060909@abenaki.wabanaki.net> <4C4D9CA6.1040201@nic-naa.net> <4C4DD6FB.2040303@nic-naa.net> <4C4DEB87.7040400@nic-naa.net> Message-ID: <4C4E32CE.1040508@nic-naa.net> On 7/26/10 8:46 PM, Jorge Amodio wrote: >> Being one of the rare known external readers, is there any bit of it you >> have a view on not already reflected in the para above and below? > > There is another dimension to the whole enchilada that makes a > compromise a moving shooting target. > > Some of the entities at the table don't like or want at all new gTLDs, > today they may say "we like milkshakes with anchovies and we can live > with that" (not really), tomorrow they will say "we only drink our > brand of tomato juice". Well, the IPC is kind of excited about getting their own TLDs, and some Board members have opined (why I don't know, the .tm gag was old when WIPO-I was current) that .brands will cure cybersquatting. I discern no effort by alternative technology vendors (search to be specific, as an alternative to lookup) to determine outcomes. > At least a byproduct of the outcome of this WG is that as observers we > are getting a more clear picture of who is on each side today before > any compromise. Agree. I'm not going to share the real time data, but some of the alliance choices have been surprising, and some of the business models some advocates may be protecting may not be publicly disclosed. I feel kind of boring in comparison. For those watching the antitrust channel, pay attention to references to external counsel and if you know where the 9th Circuit is, grovel. For those watching the golden tree, pay attention to the pursuit of ENUM post-dotTel. Me==boring++. I used to work where the golden tree was sought, or at least the fleece of the golden tree. > GNSO was very explicit that this can not introduce additional delays > to the gTLD program so sooner or later a compromise position is > needed, what if the GNSO is not able to provide a recommendation on > time, what the BoD will do ? Toss a three sided coin. 0. The Board really meant "zero" when the voted "zero". I've mentioned the consequences. Actually they're not so bad, if you're not a current RSP or registrar or have 1 share that can be acquired by a registrar you'd then like to pay more than market price to recover. 1. The Board is convinced by Staff's interpretation of "zero" as 2%. I've mentioned the consequences. See 9th Circuit, above. Quickly. 2. Something else happens. I hope that a "continuity" proposal will be selected. I know that similar hopes are held by other advocates for other policy choices. We (VI WG) prepare an update for August, there is a Board Retreat in September, and we don't actually have a hard schedule to the acceptance of applications, as the current "shinny object" to chase is "morality and public decency", so we don't actually know in fact that Cartagena is a hard hard deadline. We just assume it is. Your opportunity is to submit a public comment, if you think there is a policy issue you have any views on, any views what so ever. Eric From heather.schiller at verizonbusiness.com Tue Jul 27 12:32:50 2010 From: heather.schiller at verizonbusiness.com (Schiller, Heather A (HeatherSkanks)) Date: Tue, 27 Jul 2010 17:32:50 +0000 Subject: v6 bgp peer costs? In-Reply-To: References: Message-ID: We do not charge v4 customers anything to turn up an IPv6 tunnel. If you hear otherwise, please feel free to drop me a line. Native v6 is available in atleast 31 markets, on over 210 edge devices in 701. There is a good chance that native v6 is available for most, or close enough to rehome to a v6 capable device. If native isn't available you should be offered a tunnel for free. I'm happy to try to help anyone with VZ (701/702/703/14551) with their IPv6 issues. --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241 security at verizonbusiness.com -----Original Message----- From: Zaid Ali [mailto:zaid at zaidali.com] Sent: Wednesday, July 21, 2010 3:08 PM To: NANOG list Subject: v6 bgp peer costs? I currently have a v4 BGP session with AS 701 and recently requested a v6 BGP session to which I was told a tunnel session will be provided (Same circuit would be better but whatever!). Towards the final stage in discussions I was told that it will cost $1500. I find this quite ridiculous and it will certainly not motivate people to move to v6 if providers put a direct price tag on it. I am going through a bandwidth reseller though so I am not sure who is trying to jack me here. Has anyone here gone through a similar experience? Thanks, Zaid From sethm at rollernet.us Tue Jul 27 12:42:52 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 27 Jul 2010 10:42:52 -0700 Subject: v6 bgp peer costs? In-Reply-To: References: Message-ID: <4C4F1A9C.4030408@rollernet.us> On 7/27/10 10:32 AM, Schiller, Heather A (HeatherSkanks) wrote: > > > We do not charge v4 customers anything to turn up an IPv6 tunnel. If > you hear otherwise, please feel free to drop me a line. Native v6 is > available in atleast 31 markets, on over 210 edge devices in 701. There > is a good chance that native v6 is available for most, or close enough > to rehome to a v6 capable device. If native isn't available you should > be offered a tunnel for free. > Although re-homing can take up to a year, and in my case, they gave up trying and just canceled the service. ~Seth From jared at puck.nether.net Tue Jul 27 13:03:50 2010 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 27 Jul 2010 14:03:50 -0400 Subject: v6 bgp peer costs? In-Reply-To: <4C4F1A9C.4030408@rollernet.us> References: <4C4F1A9C.4030408@rollernet.us> Message-ID: <8B4EAC38-73B1-4A85-92D6-D4AE6F2F2478@puck.nether.net> On Jul 27, 2010, at 1:42 PM, Seth Mattinen wrote: > On 7/27/10 10:32 AM, Schiller, Heather A (HeatherSkanks) wrote: >> >> >> We do not charge v4 customers anything to turn up an IPv6 tunnel. If >> you hear otherwise, please feel free to drop me a line. Native v6 is >> available in atleast 31 markets, on over 210 edge devices in 701. There >> is a good chance that native v6 is available for most, or close enough >> to rehome to a v6 capable device. If native isn't available you should >> be offered a tunnel for free. >> > > Although re-homing can take up to a year, and in my case, they gave up > trying and just canceled the service. I must say going with a provider that has a truly native network plan vs 6PE model (as presented at NANOG) might avoid these problems. There are likely to be a lot of people in the next 12-18 months that start running around trying to upgrade and bolt IPv6 to their networks, utilizing methods like 6PE, etc.. and this problem is likely to get worse before it gets better. I'm honestly interested in what the US based DSL (incumbent) providers are doing for IPv6 (eg: att/bls/sbc/uverse, qwest, vz dsl). Most of the "ethernet" (including PON) equipment is more likely to do IPv6 correctly, but I'm not sure that the PPPo* DSL equipment is going to be quite as happy with it. This should be interesting. I also look forward to seeing what devices start to keel over by software vs hardware switched IPv6 paths as traffic increases. - Jared From jeroen at unfix.org Tue Jul 27 13:20:21 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 27 Jul 2010 20:20:21 +0200 Subject: What are ISPs going to do for deploying IPv6? (Was: v6 bgp peer costs?) In-Reply-To: <8B4EAC38-73B1-4A85-92D6-D4AE6F2F2478@puck.nether.net> References: <4C4F1A9C.4030408@rollernet.us> <8B4EAC38-73B1-4A85-92D6-D4AE6F2F2478@puck.nether.net> Message-ID: <4C4F2365.6010104@unfix.org> On 2010-07-27 20:03, Jared Mauch wrote: [..] > I'm honestly interested in what the US based DSL (incumbent) providers > are doing for IPv6 (eg: att/bls/sbc/uverse, qwest, vz dsl). > Most of the "ethernet" (including PON) equipment is more likely > to do IPv6 correctly, but I'm not sure that the PPPo* DSL equipment > is going to be quite as happy with it. > I actually have only one answer that makes sense for this: 6rd Or to state it in a more complete way: - native IPv4 + IPv6 where possible - native IPv4 + 6rd everywhere else Any other method has deployment-wise too much overhead or not enough control and 6rd is rapidly getting implemented in a lot of hardware. Actually today I noticed that even iproute (aka 'ip' on Linux) has 6rd support built-in, dunno when that happened, but that is nice to see. Yes, you lose a few bits, yes you have to come up with a way of mapping the IPv4 space in your IPv6 address plan, but that is not soo difficult and actually will make network admins happy as the bits are easy to identify. Of course, if one has CPE at the enduser which can do PPPv6 then PPPv6 definitely is also a proper "native" alike deployment scenario. > This should be interesting. I also look forward to seeing what > devices start to keel over by software vs hardware switched IPv6 > paths as traffic increases. That one will be very interesting indeed. In the case of 6rd though one can just add more hardware to the pile and anycast it to make it scale as far as one wants. And yes, I indeed say to just add Linux/BSD boxes for handling this, 1U boxes are cheap, OS is easy to install as you do with all those webservers/storage/mail etc you already have anyway, thus it is just another box to add to the auto-deploy setup. One has to remember though that 6rd is a TRANSITION mechanism that should fade away on the long run. For the next year or two though most likely one can get away with tunneled connectivity, after that, when major sites will be enabling IPv6 and thus content and traffic shifts from IPv4 to IPv6 the folks who are already trying to get native to their customers today and have hardware IPv6 enabled in their cores will definitely have a monetary advantage. One important thing folks should not forget though is to make sure that they can handle abuse and statistics properly. Take that into account from the start and you'll save yourself a lot of hassle. As for non-managed/non-owned paths, ISPs can then always still opt for a tunnel-broker like solution, be that PPTP based, TIC(AYIYA/hb) or TSP based. Like always, what shoe best fits your foot. But do think about what you want to be running on till the next upgrade cycle of your hardware comes around ;) Greets, Jeroen From bora at pnl.gov Tue Jul 27 14:05:19 2010 From: bora at pnl.gov (Akyol, Bora A) Date: Tue, 27 Jul 2010 12:05:19 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <8AC1FEFF-C2A5-4063-BB26-8F11BB1985EE@delong.com> Message-ID: Please see comments inline. On 7/22/10 10:13 PM, "Owen DeLong" wrote: > In all reality: > > 1. NAT has nothing to do with security. Stateful inspection provides > security, NAT just mangles addresses. Of course, the problem is that there are millions of customers that believe that NAT == security. This needs to change. > > 2. In the places where NAT works, it does so at a terrible cost. It > breaks a number of things, and, applications like Skype are > incredibly more complex pieces of code in order to solve NAT > traversal. I look at this as water under the bridge. Yep, it was complicated code and now it works. I can run bittorrent just fine beyond an Apple wireless router and I did nothing to make that work. Micro-torrent just communicates with the router to make the port available. > The elimination of NAT is one of the greatest features of IPv6. > > Most customers don't know or care what NAT is and wouldn't know the > difference between a NAT firewall and a stateful inspection firewall. > > I do think that people will get rid of the NAT box by and large, or, at least > in IPv6, the box won't be NATing. > > Whether or not they NAT it, it's still better to give the customer enough > addresses that they don't HAVE to NAT. > > Owen > Of course, no disagreement there. The real challenge is going to be education of customers so that they can actually configure a firewall policy to protect their now-suddenly-addressable-on-the-Internet home network. I would love to see how SOHO vendors are going to address this. From owen at delong.com Tue Jul 27 14:34:40 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 27 Jul 2010 12:34:40 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: On Jul 27, 2010, at 12:05 PM, Akyol, Bora A wrote: > Please see comments inline. > > > On 7/22/10 10:13 PM, "Owen DeLong" wrote: > >> In all reality: >> >> 1. NAT has nothing to do with security. Stateful inspection provides >> security, NAT just mangles addresses. > Of course, the problem is that there are millions of customers that believe > that NAT == security. This needs to change. >> >> 2. In the places where NAT works, it does so at a terrible cost. It >> breaks a number of things, and, applications like Skype are >> incredibly more complex pieces of code in order to solve NAT >> traversal. > > I look at this as water under the bridge. Yep, it was complicated code and > now it works. I can run bittorrent just fine beyond an Apple wireless router > and I did nothing to make that work. Micro-torrent just communicates with > the router to make the port available. > It's only water under the bridge for IPv4. If we start putting NAT66 into play, it will be the same thing all over again. Additionally, it's only water under the bridge for existing applications. Each new application seems to go through the same exercise because for some reason, no two NAT gateways seem to have exactly the same traversal requirements and no two applications seem to implement the same set of traversal code. > >> The elimination of NAT is one of the greatest features of IPv6. >> >> Most customers don't know or care what NAT is and wouldn't know the >> difference between a NAT firewall and a stateful inspection firewall. >> >> I do think that people will get rid of the NAT box by and large, or, at least >> in IPv6, the box won't be NATing. >> >> Whether or not they NAT it, it's still better to give the customer enough >> addresses that they don't HAVE to NAT. >> >> Owen >> > > Of course, no disagreement there. The real challenge is going to be > education of customers so that they can actually configure a firewall policy > to protect their now-suddenly-addressable-on-the-Internet home network. I > would love to see how SOHO vendors are going to address this. > Not so much... SOHO gateways should implement stateful inspection with the same default policy a NAT box provides today... 1. Outbound packets create a state table entry. 2. Inbound packets are only forwarded if they match an existing state table entry. Pretty simple, actually. Owen From andrew.wallace at rocketmail.com Tue Jul 27 18:43:21 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Tue, 27 Jul 2010 16:43:21 -0700 (PDT) Subject: Web expert on his 'catastrophe' key for the internet Message-ID: <354777.24939.qm@web59608.mail.ac4.yahoo.com> A British computer expert has been entrusted with part of a digital key, to help restart the internet in the event of a major catastrophe. ? Paul Kane talked to Eddie Mair on Radio 4's PM programme about what he might be called upon to do in the event of an international online emergency. ? http://www.bbc.co.uk/news/uk-10781240 From zaid at zaidali.com Tue Jul 27 18:58:42 2010 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 27 Jul 2010 16:58:42 -0700 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <354777.24939.qm@web59608.mail.ac4.yahoo.com> Message-ID: Great! So I assume he is an elder of the Internet? http://www.youtube.com/watch?v=iRmxXp62O8g On 7/27/10 4:43 PM, "andrew.wallace" wrote: > A British computer expert has been entrusted with part of a digital key, to > help > restart the internet in the event of a major catastrophe. > > ? > Paul Kane talked to Eddie Mair on Radio 4's PM programme about what he might > be > called upon to do in the event of an international online emergency. > ? > http://www.bbc.co.uk/news/uk-10781240 > > > > > From Valdis.Kletnieks at vt.edu Tue Jul 27 19:21:40 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Jul 2010 20:21:40 -0400 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: Your message of "Tue, 27 Jul 2010 16:43:21 PDT." <354777.24939.qm@web59608.mail.ac4.yahoo.com> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> Message-ID: <35925.1280276500@localhost> On Tue, 27 Jul 2010 16:43:21 PDT, "andrew.wallace" said: > A British computer expert has been entrusted with part of a digital key, to help > restart the internet in the event of a major catastrophe. You *do* realize this "news" is like two months old, right? http://www.icann.org/en/announcements/announcement-2-07jun10-en.htm The DNS root has been signed in production for over 2 weeks now. That plus the phrase "restarting the Internet" is more than a little bit misleading. One has to wonder if there was a *complete* failure of the Internet, and it needed "restarting", whether enough people holding shares would be able to get to the same place to have another root-signing ceremony. Consider the impact on plane reservations, etc. Those of us who lived through the Morris worm fragmenting the Arpa/Milnet in 1988 and things like major worm-induced outages remember what a hassle it was to *really* restart the net. Calling up your upstream on the phone asking if it was safe to turn up the link again, or looking for help in cleaning your net before you reconnected, etc...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jgreco at ns.sol.net Tue Jul 27 19:38:42 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 27 Jul 2010 19:38:42 -0500 (CDT) Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <35925.1280276500@localhost> Message-ID: <201007280038.o6S0cgTd020683@aurora.sol.net> > Those of us who lived through the Morris worm fragmenting the Arpa/Milnet in > 1988 and things like major worm-induced outages remember what a hassle it was > to *really* restart the net. Calling up your upstream on the phone asking if it > was safe to turn up the link again, or looking for help in cleaning your net > before you reconnected, etc...) Weren't the FCC and at&t recently suggesting that VoIP was the future of telephony? I can just imagine how it'll be trying to call your upstream to have them reconnect you... "Your call could not be completed at this time. Your circuit is not connected. Please hang up, connect to the Internet, and then try your call again." Ha. Now, seriously, at what point do we lose visibility of the bigger picture? Twenty years ago, the PSTN wasn't horribly hard to grasp and was sufficiently distinct that one could understand the set of circumstances that would render both phone and data unusable. As wonderful as the new communications paradigms are, do we also have a situation now developing where it might eventually become very difficult or even impossible to ensure out-of-band lines of communications remain available? ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From cnielsen at pobox.com Tue Jul 27 19:57:09 2010 From: cnielsen at pobox.com (Christopher Nielsen) Date: Tue, 27 Jul 2010 17:57:09 -0700 Subject: DSL or T1 Service to Equinix DC5, Ashburn, VA Message-ID: We've been trying to get a DSL line to our cage at Equinix DC5 in Ashburn, VA with no luck. It seems there is no DSL service in the area; that's what we've been told anyway. Anyone know differently? Alternately, any thoughts on a good provider for a T1? Replies off-list, please. Thanks! -- Christopher Nielsen "They who can give up essential liberty for temporary safety, deserve neither liberty nor safety." --Benjamin Franklin "The tree of liberty must be refreshed from time to time with the blood of patriots & tyrants." --Thomas Jefferson From weaselkeeper at gmail.com Tue Jul 27 20:21:56 2010 From: weaselkeeper at gmail.com (Jim Richardson) Date: Tue, 27 Jul 2010 18:21:56 -0700 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <201007280038.o6S0cgTd020683@aurora.sol.net> References: <35925.1280276500@localhost> <201007280038.o6S0cgTd020683@aurora.sol.net> Message-ID: On Tue, Jul 27, 2010 at 5:38 PM, Joe Greco wrote: > > As wonderful as the new communications paradigms are, do we also > have a situation now developing where it might eventually become > very difficult or even impossible to ensure out-of-band lines of > communications remain available? > That's already a problem for getting alert pages. Any actual *pager* companies left? They all seem to have gone to SMS systems. -- http://neon-buddha.net From jgreco at ns.sol.net Tue Jul 27 20:37:57 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 27 Jul 2010 20:37:57 -0500 (CDT) Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: Message-ID: <201007280137.o6S1bvKX021279@aurora.sol.net> > On Tue, Jul 27, 2010 at 5:38 PM, Joe Greco wrote: > > As wonderful as the new communications paradigms are, do we also > > have a situation now developing where it might eventually become > > very difficult or even impossible to ensure out-of-band lines of > > communications remain available? > > That's already a problem for getting alert pages. Any actual *pager* > companies left? They all seem to have gone to SMS systems. Well, USA Mobility was supporting ReFLEX pagers for us up until I got tired of playing the tech support "try this alternate TAP dialup number" game that seemed to be needed every year or so, because suddenly messages wouldn't be delivered or would be queued for many hours (and these are two-way pagers we're talking about, the network knows where they are). That was probably less than a year ago when I got fed up and told them we weren't renewing. Relatively speaking, at&t's Enterprise Paging (which appears to just be enterprise SMS with a TAP/SNPP gateway) has been a lot more reliable. I have no idea how reliable it'd be in a major telecom crisis, of course. Aren't there still some satellite pager providers out there? :-) ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From Valdis.Kletnieks at vt.edu Tue Jul 27 21:44:19 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 27 Jul 2010 22:44:19 -0400 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: Your message of "Tue, 27 Jul 2010 20:37:57 CDT." <201007280137.o6S1bvKX021279@aurora.sol.net> References: <201007280137.o6S1bvKX021279@aurora.sol.net> Message-ID: <6692.1280285059@localhost> On Tue, 27 Jul 2010 20:37:57 CDT, Joe Greco said: > Aren't there still some satellite pager providers out there? :-) Works fine till solar flare season. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jfbeam at gmail.com Tue Jul 27 21:47:58 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Tue, 27 Jul 2010 22:47:58 -0400 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <201007280137.o6S1bvKX021279@aurora.sol.net> References: <201007280137.o6S1bvKX021279@aurora.sol.net> Message-ID: On Tue, 27 Jul 2010 21:21:56 -0400, Jim Richardson wrote: > That's already a problem for getting alert pages. Any actual *pager* > companies left? They all seem to have gone to SMS systems. SkyTel is the only one I remember. Sadly, their coverage is about that of Cricket or Clearwire. (at least in NC) On Tue, 27 Jul 2010 21:37:57 -0400, Joe Greco wrote: > Relatively speaking, at&t's Enterprise Paging (which appears to just be > enterprise SMS with a TAP/SNPP gateway) has been a lot more reliable. I > have no idea how reliable it'd be in a major telecom crisis, of course. I'd expect it to work as well as the cellular network, since it's riding on it. (read: it stops working when your cellphone does.) SkyTel *used* to have satelite pagers. I don't think anyone runs such a network anymore... the pagers were bulky and the network is quite expensive to run. (just look at Iridium.) --Ricky From jgreco at ns.sol.net Tue Jul 27 22:52:16 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 27 Jul 2010 22:52:16 -0500 (CDT) Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: Message-ID: <201007280352.o6S3qGSC022631@aurora.sol.net> > On Tue, 27 Jul 2010 21:37:57 -0400, Joe Greco wrote: > > Relatively speaking, at&t's Enterprise Paging (which appears to just be > > enterprise SMS with a TAP/SNPP gateway) has been a lot more reliable. I > > have no idea how reliable it'd be in a major telecom crisis, of course. > > I'd expect it to work as well as the cellular network, since it's riding > on it. (read: it stops working when your cellphone does.) Right, I think I pointed out it was basically SMS, despite being billed as "enterprise paging," which brings us back to the previous question.... Or are you saying that there are SMS networks out there that aren't part of the cellular network? :-) > SkyTel *used* to have satelite pagers. I don't think anyone runs such a > network anymore... the pagers were bulky and the network is quite > expensive to run. (just look at Iridium.) Yes, fun. The downside of the evolution of capable cellular devices. It's still an interesting issue, though. As data and telecom become impossible to tell apart, how do you go about arranging for notification services that work when some particular layer/portion of the Internet's broken? What parts of any virtual circuit from your monitoring server to your belt device are impacted by an Internet failure? By a worm that manages to take out gear that handles both Internet traffic and private network VoIP? Etc. What happens in twenty years when at&t-the-legacy- telco has been spun off, gone all VoIP, and has gotten out of the long haul biz and rents IP capacity from some other major backbone? The potential for interdependence in the future could be a very complicated issue. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From matthew at walster.org Wed Jul 28 02:19:07 2010 From: matthew at walster.org (Matthew Walster) Date: Wed, 28 Jul 2010 08:19:07 +0100 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <201007280352.o6S3qGSC022631@aurora.sol.net> References: <201007280352.o6S3qGSC022631@aurora.sol.net> Message-ID: On 28 July 2010 04:52, Joe Greco wrote: > Right, I think I pointed out it was basically SMS, despite being billed > as "enterprise paging," which brings us back to the previous question.... > > Or are you saying that there are SMS networks out there that aren't part > of the cellular network? ?:-) I'm not sure of the situation over in NA, but in Europe, yes. M From leen at consolejunkie.net Wed Jul 28 02:28:51 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Wed, 28 Jul 2010 09:28:51 +0200 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <35925.1280276500@localhost> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <35925.1280276500@localhost> Message-ID: <4C4FDC33.5070309@consolejunkie.net> On 07/28/2010 02:21 AM, Valdis.Kletnieks at vt.edu wrote: > > That plus the phrase "restarting the Internet" is more than a little bit > misleading. > > If you think that is misleading, you would want to see this article: http://www.metro.co.uk/news/836210-brit-given-a-key-to-unlock-the-internet By some reports some have "counted 11 factual errors" in just this small article. I think a journalist created the article based on a similair interview like the BBC. From prt at prt.org Wed Jul 28 02:38:53 2010 From: prt at prt.org (Paul Thornton) Date: Wed, 28 Jul 2010 08:38:53 +0100 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <4C4FDC33.5070309@consolejunkie.net> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <35925.1280276500@localhost> <4C4FDC33.5070309@consolejunkie.net> Message-ID: <4C4FDE8D.7070904@prt.org> Leen Besselink wrote: > On 07/28/2010 02:21 AM, Valdis.Kletnieks at vt.edu wrote: >> >> That plus the phrase "restarting the Internet" is more than a little bit >> misleading. >> >> > > If you think that is misleading, you would want to see this article: > > http://www.metro.co.uk/news/836210-brit-given-a-key-to-unlock-the-internet Yes, we've been howling with derision about that on this side of the pond for the last couple of days. Putting the source into perspective though, The Metro isn't known for quality journalism - its a free paper liberally scattered around London (usually found as entertaining reading material when you're stuck on the tube going somewhere late at night). Paul. From elmi at 4ever.de Wed Jul 28 03:33:27 2010 From: elmi at 4ever.de (Elmar K. Bins) Date: Wed, 28 Jul 2010 10:33:27 +0200 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <354777.24939.qm@web59608.mail.ac4.yahoo.com> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> Message-ID: <20100728083327.GW96953@ronin.4ever.de> andrew.wallace at rocketmail.com (andrew.wallace) wrote: > A British computer expert has been entrusted with part of a digital key, to help > restart the internet in the event of a major catastrophe. > > ? > Paul Kane talked to Eddie Mair on Radio 4's PM programme about what he might be > called upon to do in the event of an international online emergency. > ? > http://www.bbc.co.uk/news/uk-10781240 One, I do not see the operational relevance of this "news". Second, people cult is just not the hype anymore. Third, my opinion towards Mr. Kane will stay with myself. From gordslater at ieee.org Wed Jul 28 04:24:00 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 28 Jul 2010 10:24:00 +0100 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <20100728083327.GW96953@ronin.4ever.de> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> Message-ID: <1280309040.9110.28.camel@ub-g-d2> On Wed, 2010-07-28 at 10:33 +0200, Elmar K. Bins wrote: > One, I do not see the operational relevance of this "news". The real problem is that articles like this DO get considerable attention in the UK - a place where "the internet" has yet to gain true understanding and recognition as a national business and government asset in the eyes of the general consumer populace and their politicians. Stories written like this still have a "wow" factor, both with the unconnected and the great unwashed customers in general. > Second, people cult is just not the hype anymore Rest assured, none of the intended viewers know or care who the dungeon-master is :) All they care about is their "MSN" working. They have to depict someone doing something, and ascii-armored printout is far too confusing for the folks to comprehend. Gord -- You have been eaten by a grue From Joel.Snyder at Opus1.COM Wed Jul 28 04:48:16 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Wed, 28 Jul 2010 11:48:16 +0200 Subject: Out-of-band paging (was: Web expert ...) Message-ID: <4C4FFCE0.4040601@Opus1.COM> From: Jim Richardson Subject: Re: Web expert on his 'catastrophe' key for the internet > > As wonderful as the new communications paradigms are, do we also > > have a situation now developing where it might eventually become > > very difficult or even impossible to ensure out-of-band lines of > > communications remain available? > > >That's already a problem for getting alert pages. Any actual *pager* >companies left? They all seem to have gone to SMS systems. Yes, several, although SMS is a better strategy today as far as I can tell. Skytel (now Velocita Wireless) has a fine 2-way network, which we used until early last year. We switched over to Metrotel, which had a smaller form-factor unit w/o 2-way which was better for us, for about a year. However, we have completely cut over to SMS for alert pages now. Multitech makes a nice little GSM modem that sits on a serial port on your alerting systems. I threw AT&T SIMs in them, wrote a tiny bit of glue to convert from email alerts to SMS alerts, and now we get all of our alerts using SMS. There's lots of open source code to handle the modems. It's completely out-of-band, even more so than our old touch-tone-phone-paging system was, so I'm actually happier with the total performance. Given that GSM coverage is increasing while pager coverage seems static or decreasing, SMS via out-of-band GSM looks like a great solution. Even situations like major power outages which would eventually take down cell towers w/o generators (or with malfunctioning generation) aren't a real concern because you usually have plenty of notice before the power goes all the way out... jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From bross at pobox.com Wed Jul 28 06:47:55 2010 From: bross at pobox.com (Brandon Ross) Date: Wed, 28 Jul 2010 07:47:55 -0400 (EDT) Subject: Out-of-band paging (was: Web expert ...) In-Reply-To: <4C4FFCE0.4040601@Opus1.COM> References: <4C4FFCE0.4040601@Opus1.COM> Message-ID: On Wed, 28 Jul 2010, Joel M Snyder wrote: > It's completely out-of-band, even more so than our old > touch-tone-phone-paging system was, so I'm actually happier with the total > performance. Given that GSM coverage is increasing while pager coverage > seems static or decreasing, SMS via out-of-band GSM looks like a great > solution. Be wary, there is a fast growing trend amongst mobile operators to outsource backhaul from their towers to IP network operators. So far there are only a few that are using the same network as for other IP traffic, but the economy of scale motivations to combine onto a single IP network are strong and will not be resisted for long. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From jgreco at ns.sol.net Wed Jul 28 08:40:35 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 28 Jul 2010 08:40:35 -0500 (CDT) Subject: Out-of-band paging (was: Web expert ...) In-Reply-To: Message-ID: <201007281340.o6SDeZSP030951@aurora.sol.net> > On Wed, 28 Jul 2010, Joel M Snyder wrote: > > It's completely out-of-band, even more so than our old > > touch-tone-phone-paging system was, so I'm actually happier with the total > > performance. Given that GSM coverage is increasing while pager coverage > > seems static or decreasing, SMS via out-of-band GSM looks like a great > > solution. > > Be wary, there is a fast growing trend amongst mobile operators to > outsource backhaul from their towers to IP network operators. So far > there are only a few that are using the same network as for other IP > traffic, but the economy of scale motivations to combine onto a single IP > network are strong and will not be resisted for long. I would definitely consider the direction that cell and SMS is moving to be at-risk and probably effectively in-band during a communications crisis. As I pointed out to someone else last night in private e-mail: : [...] but TDM as a backhaul : technology for cellular will eventually give way to all-IP based : backhaul. The pressures in the cellular space are particularly intense : with the "advanced"(*) IP services that networks such as at&t wireless : are selling to customers. In some areas, data traffic already exceeds : voice loads, and maintaining both TDM and IP backhaul for wildly varying : loads effectively means ensuring excess capacity available on two : different networks. TDM in particular may be viewed as wasteful; it's : possible to get better network efficiencies out of SIP/IMS based voice : processing. : : And then consider landlines. : : TDM is an expensive and inefficient technology, when you look at it from : the point of view of cost to implement and maintain. If you're at&t and : you're selling Uverse, for example, you're already encoding the POTS : line as data to haul it over the copper/fiber to the customer. Does it : make a lot of sense to maintain a local central office switch that's : essentially a dinosaur, converting TDM to VoIP at the CO, just to justify : the continued existence of a switch at the CO? : : Point is, TDM's goose is cooked. Your cell phone's going to wind up on : the same IP network that your landline's going to be on, and that's also : likely to have overlap with consumer Internet connectivity. It may not : be that way today, or tomorrow, or next year, but let's be realistic, as : efforts to cut costs are made, telcos are not going to see value for : their dollar in maintaining completely separate networks, and they're : going to touch. : : (*) "advanced" == "Internet access", we NANOG'ers consider it basic. Please remember before anyone tries to "correct" me that I'm making forward-looking statements about where things are likely to go, and not just looking at the current state of the technology. I see mobile data as being strong growth, and mobile devices becoming plentiful, but the demand for mobile voice is not going to grow in the same ways. Just as the early days of the Internet were dialup and low bandwidth sites, but we transitioned to broadband and bandwidth-hungry sites that were made possible as a result, we'll see a lot of that happen with wireless data too. What that really implies is that voice demand is going to remain more or less constant when compared to the explosive growth of data; data demand is going to grow, and carriers will get to the point where they're running gigE to a cell tower. Right now, maybe voice is of sufficient importance and data is sufficiently new and problematic that there is some segregation internally of that traffic within the carrier's networks, but even in the most optimistic case for network segregation, I see it getting to the point where someone looks at the picture in a few years and says, "we've already got 1Gbps data pipes to our cell sites, why are we running voice over a separate 45Mbps pipe?" And as far as I can tell, that's happening a lot more quickly than many people have expected. I strongly agree with your conclusions about economy of scale motivations. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From dot at dotat.at Wed Jul 28 09:17:24 2010 From: dot at dotat.at (Tony Finch) Date: Wed, 28 Jul 2010 15:17:24 +0100 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <201007280038.o6S0cgTd020683@aurora.sol.net> References: <201007280038.o6S0cgTd020683@aurora.sol.net> Message-ID: On Tue, 27 Jul 2010, Joe Greco wrote: > > Weren't the FCC and at&t recently suggesting that VoIP was the future of > telephony? BT are currently upgrading the UK's phone system to VOIP. But it's running on a private network. Tony. -- f.anthony.n.finch http://dotat.at/ SOUTH FITZROY: NORTHEASTERLY 5 TO 7. MODERATE OR ROUGH. FAIR. GOOD. From dot at dotat.at Wed Jul 28 09:21:33 2010 From: dot at dotat.at (Tony Finch) Date: Wed, 28 Jul 2010 15:21:33 +0100 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <4C4FDC33.5070309@consolejunkie.net> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <35925.1280276500@localhost> <4C4FDC33.5070309@consolejunkie.net> Message-ID: On Wed, 28 Jul 2010, Leen Besselink wrote: > > If you think that is misleading, you would want to see this article: > > http://www.metro.co.uk/news/836210-brit-given-a-key-to-unlock-the-internet See also the press releases from Bath University: http://www.bath.ac.uk/news/2010/07/26/internet-security/ and CommunityDNS themselves: http://cdns.net/ROOT-DNSSEC.html The problem seems to be that Bath's press office decided to sex up the story and Metro confused DNSSEC with the Internet kill switch proposal. Tony. -- f.anthony.n.finch http://dotat.at/ SHANNON: NORTHWEST, BACKING SOUTH OR SOUTHWEST, 3 OR 4. ROUGH BECOMING MODERATE. RAIN OR DRIZZLE WITH FOG PATCHES. MODERATE OR GOOD, OCCASIONALLY VERY POOR. From Joel.Snyder at Opus1.COM Wed Jul 28 09:38:25 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Wed, 28 Jul 2010 16:38:25 +0200 Subject: Out-of-band paging In-Reply-To: <201007281340.o6SDeZSP030951@aurora.sol.net> References: <201007281340.o6SDeZSP030951@aurora.sol.net> Message-ID: <4C5040E1.1010502@Opus1.COM> On 7/28/10 3:40 PM, Joe Greco wrote: > I would definitely consider the direction that cell and SMS is moving to > be at-risk and probably effectively in-band during a communications > crisis. As I pointed out to someone else last night in private e-mail: > [summary: TDM will run over same infrastructure too] I agree with you & Brandon in terms of the directions: yes, your local access (and your tower access for GSM) will likely all be backhauled over the same unexpectedly attenuated piece of fiber, causing your alerts to be as silent as your dial tone. But... you can take this sort of 'single point of failure' argument almost as far as you want. In the security business (where I spend most of my time), I see people do this a lot--they get deep into the ultra-ultra-ultra marginal risk, which takes then an enormous amount of money to mitigate. It's an easy rat hole to explore, and often fun. Obviously, using SMTP-to-SMS-over-the-Internet to tell yourself that your SMTP infrastructure is hosed is the wrong answer. On the other hand, triply-redundantly engineering things to deal with the outage of the fiber that connects your building, POTS, GSM, and everything else may not be the right answer. To some extent, there's the practical question of "if my entire city is disconnected, do I really need to know about it since I probably can't do anything about it?" (Yes, I know your help desk would want to know, but realistically...) I guess my point is: yeah, Brandon, Joe, you're right. But, I've built the alerting solution that minimizes the risk I will miss an alert I care about while also minimizing my overall cost and minimizing the complexity of the alerting system. I'm happy to make it better, cheaper, more robust, etc., but I think it's important to balance these things. (I should also note, if anyone had any doubts, that I'm also one of those mom-and-pop ISPs, not Time-Warner or Verizon, so my concept of alerting is a bit different from someone who is trying to keep tabs on 1300 POPs in 40 countries...) jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From bicknell at ufp.org Wed Jul 28 09:42:30 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 28 Jul 2010 07:42:30 -0700 Subject: Out-of-band paging In-Reply-To: <4C5040E1.1010502@Opus1.COM> References: <201007281340.o6SDeZSP030951@aurora.sol.net> <4C5040E1.1010502@Opus1.COM> Message-ID: <20100728144230.GA6946@ussenterprise.ufp.org> In a message written on Wed, Jul 28, 2010 at 04:38:25PM +0200, Joel M Snyder wrote: > But... you can take this sort of 'single point of failure' argument > almost as far as you want. In the security business (where I spend most > of my time), I see people do this a lot--they get deep into the > ultra-ultra-ultra marginal risk, which takes then an enormous amount of > money to mitigate. It's an easy rat hole to explore, and often fun. I agree worring about the cell site is not the worry. However I suspect many of the folks relying on SMS have no idea how it works inside the carrier. There are in fact other points of failure that may be much more "single point". For instance your SMS likely passes through a database in the carrier network (in case your phone is off). That's redundant, right? Fully RAID'ed and a hot standby spare and all that, after all it probably handles SMS's for a few million customers. Not always. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From maxsec at gmail.com Wed Jul 28 09:52:45 2010 From: maxsec at gmail.com (Martin Hepworth) Date: Wed, 28 Jul 2010 15:52:45 +0100 Subject: Out-of-band paging In-Reply-To: <20100728144230.GA6946@ussenterprise.ufp.org> References: <201007281340.o6SDeZSP030951@aurora.sol.net> <4C5040E1.1010502@Opus1.COM> <20100728144230.GA6946@ussenterprise.ufp.org> Message-ID: On 28 July 2010 15:42, Leo Bicknell wrote: > In a message written on Wed, Jul 28, 2010 at 04:38:25PM +0200, Joel M > Snyder wrote: > > But... you can take this sort of 'single point of failure' argument > > almost as far as you want. In the security business (where I spend most > > of my time), I see people do this a lot--they get deep into the > > ultra-ultra-ultra marginal risk, which takes then an enormous amount of > > money to mitigate. It's an easy rat hole to explore, and often fun. > > I agree worring about the cell site is not the worry. > > However I suspect many of the folks relying on SMS have no idea how > it works inside the carrier. There are in fact other points of > failure that may be much more "single point". For instance your > SMS likely passes through a database in the carrier network (in > case your phone is off). That's redundant, right? Fully RAID'ed > and a hot standby spare and all that, after all it probably handles > SMS's for a few million customers. > > Not always. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > (view from the UK where SMS is very very prevalent) TXT's can take ages to deliver (hours days not uncommon). GSM networks can get put to emergency access only so they don't get swamped when a civil emergency occurs and emergency workers need priority access to mobile network. eg 7 July 2005 in London -- Martin Hepworth Oxford, UK From cmadams at hiwaay.net Wed Jul 28 09:55:27 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Wed, 28 Jul 2010 09:55:27 -0500 Subject: Out-of-band paging In-Reply-To: <4C5040E1.1010502@Opus1.COM> References: <201007281340.o6SDeZSP030951@aurora.sol.net> <4C5040E1.1010502@Opus1.COM> Message-ID: <20100728145527.GA1450478@hiwaay.net> Once upon a time, Joel M Snyder said: > Obviously, using SMTP-to-SMS-over-the-Internet to tell yourself that > your SMTP infrastructure is hosed is the wrong answer. We even ran into this with paging and direct submission via TAP. We had a POTS line not provisioned over fiber (so not the same physical layer as our regular connectivity), used a modem on a computer with a dedicated UPS, etc. Then we realized that our local paging provider was connected to us for Internet access and sent pages to towers outside the immediate area over the Internet. Oops. Now we use SMS and a GSM modem. Since the cell carriers don't buy any access from us, we're at least somewhat better off. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jgreco at ns.sol.net Wed Jul 28 10:22:43 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 28 Jul 2010 10:22:43 -0500 (CDT) Subject: Out-of-band paging In-Reply-To: <4C5040E1.1010502@Opus1.COM> Message-ID: <201007281522.o6SFMhU4032101@aurora.sol.net> > I guess my point is: yeah, Brandon, Joe, you're right. But, I've built > the alerting solution that minimizes the risk I will miss an alert I > care about while also minimizing my overall cost and minimizing the > complexity of the alerting system. I'm happy to make it better, > cheaper, more robust, etc., but I think it's important to balance these > things. (I should also note, if anyone had any doubts, that I'm also > one of those mom-and-pop ISPs, not Time-Warner or Verizon, so my concept > of alerting is a bit different from someone who is trying to keep tabs > on 1300 POPs in 40 countries...) I think my point's more along the lines of: don't expect to be able to magically hand off a message to a service provider and expect that it will be delivered; they have the same sorts of problems that you do, and the way things are going, they may even be using the same infrastructure that you are. That last bit in particular is worth thinking about. >From my point of view, my ideal alerting system is probably something like a smartphone running an app that's connected to the network monitoring system, and can tell me: 1) when it has lost that connection, and 2) whatever problems the network monitoring system chooses to let me know about. The old-timers would recognize this as one form of supervised circuit. I don't really care about the possibility of lost messages so long as I'm aware that I may not be "in touch". I'm perfectly capable of sorting that situation out myself. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From jbates at brightok.net Wed Jul 28 10:38:52 2010 From: jbates at brightok.net (Jack Bates) Date: Wed, 28 Jul 2010 10:38:52 -0500 Subject: Out-of-band paging In-Reply-To: <201007281522.o6SFMhU4032101@aurora.sol.net> References: <201007281522.o6SFMhU4032101@aurora.sol.net> Message-ID: <4C504F0C.4070808@brightok.net> Joe Greco wrote: >>From my point of view, my ideal alerting system is probably something > like a smartphone running an app that's connected to the network > monitoring system, and can tell me: > > 1) when it has lost that connection, and > > 2) whatever problems the network monitoring system chooses to let me > know about. > I use the triple approach myself. Old fashioned TAP line, helpdesk notifications (they have plenty of methods of contacting me), and an out of band hard relay alarm that goes to the telco operators. Some methods use direct circuits to neighboring town's fiber node, some things use the local town's fiber node, both taking different paths. It's extremely hard to get fully isolated. Monitoring server even has it's own separate UPS, though I really need to just throw an offsite redundant monitoring server up. The app solution is one I actually believe to be the best method, but I'm a poor country folk and smart isn't exactly what I'd call this little phone. Jack From andrew.wallace at rocketmail.com Wed Jul 28 11:24:57 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 28 Jul 2010 09:24:57 -0700 (PDT) Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <20100728083327.GW96953@ronin.4ever.de> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> Message-ID: <959927.54991.qm@web59602.mail.ac4.yahoo.com> On Wed, Jul 28, 2010 at 9:33 AM, Elmar K. Bins wrote: > andrew.wallace at rocketmail.com (andrew.wallace) wrote: > >> A British computer expert has been entrusted with part of a digital key, to >>help >> restart the internet in the event of a major catastrophe. >> >> >> Paul Kane talked to Eddie Mair on Radio 4's PM programme about what he might >be >> called upon to do in the event of an international online emergency. >> >> http://www.bbc.co.uk/news/uk-10781240 > > One, I do not see the operational relevance of this "news". > Second, people cult is just not the hype anymore. > Third, my opinion towards Mr. Kane will stay with myself. > I think there is a social vulnerability in a group of people who need to travel, a lot of the time, by plane, to exactly the same location to make new keys to reset DNSSEC. What I think is, this is leaving them wide open to attack. If an attack was state-sponsored, its likely they would be able to stop those selected people reaching the location in the United States by way of operational officers intercepting them by kidnap or murder, and indeed, a cyber attack without the need for human intervention to stop the select people getting to their destination could be done by knocking out the air traffic system. Which would, hamper the resetting and creation of new keys for DNSSEC. Even without the select people being prevented from reaching their location in the United States, the disclosure tells the bad guys, approximately how long an attack window they've got between the selected people leaving their work or home and travelling by plane to the location. It would have been better if the people who are the selected key holders was kept classified, a lot of the information given out wasn't in the public interest, or in the national interest for the arrangements to be made public. I'm guessing also, Mr.Kane would be travelling to the United States in a military plane and not a commercial airliner, but who knows? Of course this is just my opinion. Andrew Wallace From scg at gibbard.org Wed Jul 28 11:54:29 2010 From: scg at gibbard.org (Steve Gibbard) Date: Wed, 28 Jul 2010 09:54:29 -0700 (PDT) Subject: Out-of-band paging In-Reply-To: <4C5040E1.1010502@Opus1.COM> References: <201007281340.o6SDeZSP030951@aurora.sol.net> <4C5040E1.1010502@Opus1.COM> Message-ID: On Wed, 28 Jul 2010, Joel M Snyder wrote: > But... you can take this sort of 'single point of failure' argument almost as > far as you want. In the security business (where I spend most of my time), I > see people do this a lot--they get deep into the ultra-ultra-ultra marginal > risk, which takes then an enormous amount of money to mitigate. It's an easy > rat hole to explore, and often fun. I think people are getting lost in the weeds here, and confusing technologies with paths. My current employer has been upgrading its transit circuits, and spent time in the last few months worrying about diversity of the transit paths. But we didn't insist that one provider come in via metro ethernet, one via SONET, and one via a GRE tunnel. What we did was have them bring in network maps, and make them sell us circuits that weren't running down the same streets as our other providers. The same goes for your paging network. If it's running over IP, that's not a huge problem. If anything, if you're an IP engineer, it probably makes it easier for you to audit the setup. Where you do have a problem is if it's running over YOUR IP network, but that's just a more accute version of the problem you'd have if your paging company were using fiber along the same path as somebody you were buying fiber from. So, for paging, or out of band management, or redundant capacity, the rules seem pretty simple. Buy from somebody who's not your customer. Audit whatever information you can get about their network paths to verify that they're not sharing segments with you. And, for good measure, have some backup plans in case the notifications don't work. You probably are better off if you have humans in a NOC, rather than a purely automated alerting system. Those people can notice if you're not responding, and be creative. Maybe they can figure out how to fix problems themselves. If all else fails, they may be able to dispatch somebody to your house. Remember, organizations have been tracking down critical personnel for far longer than there have been telephones. Or are people here worried about a scenario in which the entire world is run off of one big interconnected IP network, and that when it fails it's not only not possible to make a phone call, but also not possible to get across town to alert the people who could fix it? It seems to me that if things really got that bad, it might be pretty hard for even the most oblivious on-call person to miss. -Steve From jmamodio at gmail.com Wed Jul 28 12:25:32 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 28 Jul 2010 12:25:32 -0500 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <959927.54991.qm@web59602.mail.ac4.yahoo.com> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> Message-ID: > Of course this is just my opinion. Which is totally unfounded and equivalent to a ton of dung. Please stop with the non-operational content conspiracy theories, tnx. From Valdis.Kletnieks at vt.edu Wed Jul 28 13:55:47 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 28 Jul 2010 14:55:47 -0400 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: Your message of "Wed, 28 Jul 2010 09:24:57 PDT." <959927.54991.qm@web59602.mail.ac4.yahoo.com> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> Message-ID: <15502.1280343347@localhost> On Wed, 28 Jul 2010 09:24:57 PDT, "andrew.wallace" said: > What I think is, this is leaving them wide open to attack. If an attack was > state-sponsored, its likely they would be able to stop those selected people > reaching the location in the United States by way of operational officers > intercepting them by kidnap or murder, and indeed, a cyber attack without the > need for human intervention to stop the select people getting to their > destination could be done by knocking out the air traffic system. Which would, > hamper the resetting and creation of new keys for DNSSEC. Movie-plot threat. Hint 1 - if you want to cause actual mischief, I'd start the merriment over at gtld-servers.net rather than the actual root, or maybe even one more level down at the actual TLD servers. '.' is small enough that it can easily be hand-verified if need be, but there's like 140M things under .com handled by dozens of registries and registrars - even with DNSSEC, plenty of room for fun and games. (What protection does DNSSEC grant you against a squatter who snarfs up a domain name that's accidentally expired due to a billing issue?) Hint 2 - What do the 5th and 6th fields on the '.' SOA entry mean, especially in this context? In particular, what operational aspect does the specified 5th value give us if we're contemplating this movie-plot scenario? > Even without the select people being prevented from reaching their location in > the United States, the disclosure tells the bad guys, approximately how long an > attack window they've got between the selected people leaving their work or home > and travelling by plane to the location. Bzzt! Wrong, but thank you for playing. The bad guys *actual* window is between when the current root keys are lost/ compromised, and when the selected people *leave* to go to the selected location. Once you learn that the root key is compromised, you can take other steps to mitigate damage (see hint 2 above). When Paul Kane gets that phone call that says he needs to take a plane trip, the window is *closing*, not opening. > It would have been better if the people who are the selected key holders was > kept classified, a lot of the information given out wasn't in the public > interest, or in the national interest for the arrangements to be made public. Obviously you have approximately zero understanding of the crypto community. They tend to be the most paranoid people out there - and the *only* way to get acceptance of a signed root was to make sure that ICANN is *not* in posession of enough keying material to sign a key by itself. In addition, the owners of keys need to be publicly known, to avoid allegations of "ICANN and a bunch of unnamed people not associated with them. Honest - trust us". In the crypto world, "trust us" is a fast path to Bruce Schneier's Doghouse. > Of course this is just my opinion. There's opinions, and opinions backed by operational experience. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jmamodio at gmail.com Wed Jul 28 14:20:51 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 28 Jul 2010 14:20:51 -0500 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <15502.1280343347@localhost> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <15502.1280343347@localhost> Message-ID: > Obviously you have approximately zero understanding of the crypto community. > They tend to be the most paranoid people out there - and the *only* way to get > acceptance of a signed root was to make sure that ICANN is *not* in posession > of enough keying material to sign a key by itself. ?In addition, the owners of > keys need to be publicly known, to avoid allegations of "ICANN and a bunch > of unnamed people not associated with them. Honest - trust us". Also, these famous guys selected as part of the TCR group where the number is not actually seven, don't even have enough material to sign anything by themselves. The RKSH or Recovery Key Share Holder just holds in a tamper evident bag, a smart card with part of the key used to encrypt the backup copies of the HSM (Hardware Security Module). I'd love to see how they can "restart the world wide web" with that ... Cheers Jorge From Valdis.Kletnieks at vt.edu Wed Jul 28 14:31:25 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 28 Jul 2010 15:31:25 -0400 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: Your message of "Wed, 28 Jul 2010 14:20:51 CDT." References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <15502.1280343347@localhost> Message-ID: <16710.1280345485@localhost> On Wed, 28 Jul 2010 14:20:51 CDT, Jorge Amodio said: > Also, these famous guys selected as part of the TCR group where the > number is not actually seven, don't even have enough material to sign > anything by themselves. Of course not. The only real requirement is that the TCR group hold enough shares so ICANN can't sign anything without them. For instance, make 12 shares, give 6 to ICANN and 1 to each of six TCR people, and then require 11 shares in order to sign something. The only way anything happens is for ICANN and at least 5 TCR to cooperate - which is about the only way to make it palatable for all concerned. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jmamodio at gmail.com Wed Jul 28 15:16:19 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Wed, 28 Jul 2010 15:16:19 -0500 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <16710.1280345485@localhost> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <15502.1280343347@localhost> <16710.1280345485@localhost> Message-ID: >> Also, these famous guys selected as part of the TCR group where the >> number is not actually seven, don't even have enough material to sign >> anything by themselves. > > Of course not. ?The only real requirement is that the TCR group hold enough > shares so ICANN can't sign anything without them. ?For instance, make 12 > shares, give 6 to ICANN and 1 to each of six TCR people, and then require 11 > shares in order to sign something. The only way anything happens is for ICANN > and at least 5 TCR to cooperate - which is about the only way to make it > palatable for all concerned. Have you noticed that the Provisional TCR Proposal doc from ICANN has the page numbers encrypted ? (http://www.root-dnssec.org/wp-content/uploads/2010/04/ICANN-TCR-Proposal-20100408.pdf) Looks it is the strange "I don't know how to number pages on pdf files" algorithm :-) Cheers Jorge From tglassey at earthlink.net Wed Jul 28 15:29:08 2010 From: tglassey at earthlink.net (todd glassey) Date: Wed, 28 Jul 2010 13:29:08 -0700 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <15502.1280343347@localhost> <16710.1280345485@localhost> Message-ID: <4C509314.1090500@earthlink.net> On 7/28/2010 1:16 PM, Jorge Amodio wrote: >>> Also, these famous guys selected as part of the TCR group where the >>> number is not actually seven, don't even have enough material to sign >>> anything by themselves. >> Of course not. The only real requirement is that the TCR group hold enough >> shares so ICANN can't sign anything without them. For instance, make 12 >> shares, give 6 to ICANN and 1 to each of six TCR people, and then require 11 >> shares in order to sign something. The only way anything happens is for ICANN >> and at least 5 TCR to cooperate - which is about the only way to make it >> palatable for all concerned. > Have you noticed that the Provisional TCR Proposal doc from ICANN has > the page numbers encrypted ? > > (http://www.root-dnssec.org/wp-content/uploads/2010/04/ICANN-TCR-Proposal-20100408.pdf) > > Looks it is the strange "I don't know how to number pages on pdf > files" algorithm :-) > > Cheers > Jorge > > Add the numbers to the pages when the pdf IS printed. Its in the printing configuration. Todd From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Jul 29 05:46:29 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 29 Jul 2010 20:16:29 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: Message-ID: <20100729201629.6b1629dc@opy.nosense.org> On Tue, 27 Jul 2010 12:34:40 -0700 Owen DeLong wrote: > > On Jul 27, 2010, at 12:05 PM, Akyol, Bora A wrote: > > > Please see comments inline. > > > > > > On 7/22/10 10:13 PM, "Owen DeLong" wrote: > > > >> In all reality: > >> > >> 1. NAT has nothing to do with security. Stateful inspection provides > >> security, NAT just mangles addresses. > > Of course, the problem is that there are millions of customers that believe > > that NAT == security. This needs to change. > >> > >> 2. In the places where NAT works, it does so at a terrible cost. It > >> breaks a number of things, and, applications like Skype are > >> incredibly more complex pieces of code in order to solve NAT > >> traversal. > > > > I look at this as water under the bridge. Yep, it was complicated code and > > now it works. I can run bittorrent just fine beyond an Apple wireless router > > and I did nothing to make that work. Micro-torrent just communicates with > > the router to make the port available. > > > It's only water under the bridge for IPv4. If we start putting NAT66 into play, > it will be the same thing all over again. > > Additionally, it's only water under the bridge for existing applications. Each > new application seems to go through the same exercise because for some > reason, no two NAT gateways seem to have exactly the same traversal > requirements and no two applications seem to implement the same set > of traversal code. > What is worse about that is that we networking people have ended up shifting the cost of fixing our problem onto the application developers and onto the application users. Because we don't provide end-to-end visibility between peers on the Internet ("Internet transparency" - see RFC4924), application developers have to try to develop methods of doing that themselves. As you've said, this creates additional application complexity, additional bugs, and duplicate functionality between different applications, all at the application layer. (HTTP has become the de facto substrate protocol of the Internet because firewalls permit it, and client server communication has become the de facto communications method for applications that would truly benefit from peer-to-peer communications (i.e. more scalable, more available), because client server overcomes the lack of global reachability NAT creates)) Who pays this additional application development cost? Everybody, including us networking people, because we also use applications too. We get code that is possibly more buggy because it is more complex, written by people who are usually not networking code experts. We might miss out on better user interfaces or less buggy code that's there to do what the application's purpose is, because that time was instead spent on developing network layer work arounds. It seems to me that the best place to solve problems is whether they exist or where they're caused. Those solutions usually solve the problem properly, and commonly are also the cheapest way to solve it. The network layer is where these problems exist, and that's where they should be solved. We should use IPv6 to restore Internet transparency, so that application developers don't have to do it for us - again. We'll end up with a better and simpler Internet to operate, and better and/or cheaper applications. Regards, Mark. > > > >> The elimination of NAT is one of the greatest features of IPv6. > >> > >> Most customers don't know or care what NAT is and wouldn't know the > >> difference between a NAT firewall and a stateful inspection firewall. > >> > >> I do think that people will get rid of the NAT box by and large, or, at least > >> in IPv6, the box won't be NATing. > >> > >> Whether or not they NAT it, it's still better to give the customer enough > >> addresses that they don't HAVE to NAT. > >> > >> Owen > >> > > > > Of course, no disagreement there. The real challenge is going to be > > education of customers so that they can actually configure a firewall policy > > to protect their now-suddenly-addressable-on-the-Internet home network. I > > would love to see how SOHO vendors are going to address this. > > > Not so much... SOHO gateways should implement stateful inspection > with the same default policy a NAT box provides today... > > 1. Outbound packets create a state table entry. > 2. Inbound packets are only forwarded if they match an existing > state table entry. > > Pretty simple, actually. > > Owen > > From tim at pelican.org Thu Jul 29 05:45:43 2010 From: tim at pelican.org (Tim Franklin) Date: Thu, 29 Jul 2010 10:45:43 +0000 (GMT) Subject: Addressing plan exercise for our IPv6 course In-Reply-To: Message-ID: <5739982.31280400343185.JavaMail.root@jennyfur.pelican.org> > I look at this as water under the bridge. Yep, it was complicated code > and now it works. I can run bittorrent just fine beyond an Apple > wireless router and I did nothing to make that work. Micro-torrent > just communicates with the router to make the port available. So, the security model here is that arbitrary untrusted applications, running on an arbitrary untrusted OS, selected by people who have no understanding of computer or network security are allowed to update the security policy on the perimeter device. I can see why those secure NAT boxes have *totally* stopped the Windows botnet problem in its tracks... > Of course, no disagreement there. The real challenge is going to be > education of customers so that they can actually configure a firewall > policy to protect their now-suddenly-addressable-on-the-Internet home > network. I would love to see how SOHO vendors are going to address this. Permit any outbound Permit any inbound established Deny any inbound Achieves essentially the same functionality as a NAT device without the annoying mangling of addresses. Vendors could then continue to offer the UPnP "request a hole" functionality that they do today, or tweak the labels on their "forward this port" web GUI to say "permit the port" instead. For end-users who want to carry on doing exactly what they do today, the changes required for both them and their CPE vendor are trivial. For end-users who are currently frustrated by NAT, they have their real, honest-to-goodness end-to-end Internet restored. Everybody wins, apart those with a vested interest in "upselling" to "business" connectivity plans, or those who would prefer that the Internet is TV on new technology, and that end-users remain good little eyeballs, dutifully paying for their Big Business Content. Regards, Tim. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Jul 29 05:51:42 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 29 Jul 2010 20:21:42 +0930 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <1279994212.28305.358.camel@karl> References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> <4C4B0BC4.5030908@matthew.at> <891EB3CD-5C88-491C-AE8E-F2A963A8637C@delong.com> <1279994212.28305.358.camel@karl> Message-ID: <20100729202142.16e304c0@opy.nosense.org> On Sun, 25 Jul 2010 03:56:52 +1000 Karl Auer wrote: > On Sat, 2010-07-24 at 10:42 -0700, Owen DeLong wrote: > > You do have to properly set up the rules for which addresses to use for what > > communication properly. It breaks less if you forego the ULA brokenness, > > but, some people insist for whatever reason. > > What is "the ULA brokenness"? > If it is address selection policy distribution, then this Internet Draft is aiming to solve that - "Distributing Address Selection Policy using DHCPv6" http://tools.ietf.org/html/draft-fujisaki-6man-addr-select-opt-00.html > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) > > GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF From matthew at walster.org Thu Jul 29 06:08:27 2010 From: matthew at walster.org (Matthew Walster) Date: Thu, 29 Jul 2010 12:08:27 +0100 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <1279845943.28305.7.camel@karl> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> Message-ID: On 23 July 2010 01:45, Karl Auer wrote: > Unless I've misunderstood Matthew, and he was suggesting that the /64 be > the link network. That would indeed effectively give the customer a > single address, unless it was being bridged rather than routed at the > CPE. Not sure bridging it is such a good idea - most people will > probably want their home networks to keep working even if the ISP has an > outage. Sorry for the week's delay - I meant delegating a /64 using DHCPv6 PD, I had assumed the link net would be based on provider preference - /64 would obviously make the most sense for the vast majority of scenarios. In my experience, I would have though well over 99% of residential users just require one subnet, if they require additional subnets they'll ask for them, and if it's standardised, a /56 could easily be quickly assigned and added to either the DHCPv6 PD or static routed if required. That would usually be a service the customer would pay extra for. I'm purely looking at residential use here, not SOHO nor SME. M M From owen at delong.com Thu Jul 29 09:42:58 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Jul 2010 07:42:58 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <20100729202142.16e304c0@opy.nosense.org> References: <68964.1279957825@localhost> <20100724082932.GA12472@mx.ytti.net> <4C4B0BC4.5030908@matthew.at> <891EB3CD-5C88-491C-AE8E-F2A963A8637C@delong.com> <1279994212.28305.358.camel@karl> <20100729202142.16e304c0@opy.nosense.org> Message-ID: <970EE538-6E4C-4B61-9D96-25DE2255008B@delong.com> On Jul 29, 2010, at 3:51 AM, Mark Smith wrote: > On Sun, 25 Jul 2010 03:56:52 +1000 > Karl Auer wrote: > >> On Sat, 2010-07-24 at 10:42 -0700, Owen DeLong wrote: >>> You do have to properly set up the rules for which addresses to use for what >>> communication properly. It breaks less if you forego the ULA brokenness, >>> but, some people insist for whatever reason. >> >> What is "the ULA brokenness"? >> > > If it is address selection policy distribution, then this Internet > Draft is aiming to solve that - > > "Distributing Address Selection Policy using DHCPv6" > http://tools.ietf.org/html/draft-fujisaki-6man-addr-select-opt-00.html Source address selection is one of the problems. Distribution of source address selection policy is part of that problem. Owen From owen at delong.com Thu Jul 29 09:49:56 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Jul 2010 07:49:56 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> Message-ID: <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> On Jul 29, 2010, at 4:08 AM, Matthew Walster wrote: > On 23 July 2010 01:45, Karl Auer wrote: >> Unless I've misunderstood Matthew, and he was suggesting that the /64 be >> the link network. That would indeed effectively give the customer a >> single address, unless it was being bridged rather than routed at the >> CPE. Not sure bridging it is such a good idea - most people will >> probably want their home networks to keep working even if the ISP has an >> outage. > > Sorry for the week's delay - I meant delegating a /64 using DHCPv6 PD, > I had assumed the link net would be based on provider preference - /64 > would obviously make the most sense for the vast majority of > scenarios. > > In my experience, I would have though well over 99% of residential > users just require one subnet, if they require additional subnets > they'll ask for them, and if it's standardised, a /56 could easily be > quickly assigned and added to either the DHCPv6 PD or static routed if > required. That would usually be a service the customer would pay extra > for. I'm purely looking at residential use here, not SOHO nor SME. > > M > > M Why not just give them a /48 and not worry about who needs what? Why add the cost and complexity of all these different sized assignments based on requests and such? If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. Even if it turns out this is a bad idea and we can't sustain this level of IP consumption, we still have 7/8ths of the address space available to use more conservative addressing plans. Owen From matthew at walster.org Thu Jul 29 10:00:40 2010 From: matthew at walster.org (Matthew Walster) Date: Thu, 29 Jul 2010 16:00:40 +0100 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> Message-ID: On 29 July 2010 15:49, Owen DeLong wrote: > If we give every household on the planet a /48 (approximately 3 billion > /48s), we consume less than 1/8192 of 2000::/3. There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers. All I'm saying is, why waste the space when they're only going to need 1 subnet? If they want more than one subnet, give them a /48,/56,/60 or whatever, as requested. M From jordi.palet at consulintel.es Thu Jul 29 10:38:50 2010 From: jordi.palet at consulintel.es (Jordi Palet =?iso-8859-1?Q?Mart=EDnez?=) Date: Thu, 29 Jul 2010 17:38:50 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> Message-ID: The policies available in all the 5 RIR regions, allow you to request not the "default" /32, but whatever is appropriate for the size of your network even if you provide to your end-users /48. Not an issue. Regards, Jordi -----Original Message----- From: Matthew Walster To: Owen DeLong Cc: nanog at nanog.org Date: Thu, 29 Jul 2010 16:00:40 +0100 Subject: Re: Addressing plan exercise for our IPv6 course On 29 July 2010 15:49, Owen DeLong wrote: > If we give every household on the planet a /48 (approximately 3 billion > /48s), we consume less than 1/8192 of 2000::/3. There are 65,536 /48s in a /32. It's not about how available 2000::/3 is, it's hassle to keep requesting additional PA space. Some ISPs literally have millions of customers. All I'm saying is, why waste the space when they're only going to need 1 subnet? If they want more than one subnet, give them a /48,/56,/60 or whatever, as requested. M ********************************************** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From leo.vegoda at icann.org Thu Jul 29 12:08:33 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 29 Jul 2010 10:08:33 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> Message-ID: <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> On 29 Jul 2010, at 8:00, Matthew Walster wrote: > On 29 July 2010 15:49, Owen DeLong wrote: >> If we give every household on the planet a /48 (approximately 3 billion >> /48s), we consume less than 1/8192 of 2000::/3. > > There are 65,536 /48s in a /32. It's not about how available 2000::/3 > is, it's hassle to keep requesting additional PA space. Some ISPs > literally have millions of customers. Why would you initially request and receive a /32 if you know that you'll need far more space to assign subnets to all your customers? > All I'm saying is, why waste the space when they're only going to need > 1 subnet? If they want more than one subnet, give them a /48,/56,/60 > or whatever, as requested. There's a good chance that you want to keep your customers for the long haul. There's a good chance that in the long run multi-subnet home networks will become the norm. Leo From owen at delong.com Thu Jul 29 12:19:36 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Jul 2010 10:19:36 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> Message-ID: On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote: > On 29 July 2010 15:49, Owen DeLong wrote: >> If we give every household on the planet a /48 (approximately 3 billion >> /48s), we consume less than 1/8192 of 2000::/3. > > There are 65,536 /48s in a /32. It's not about how available 2000::/3 > is, it's hassle to keep requesting additional PA space. Some ISPs > literally have millions of customers. > If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space? 1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts. It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you. > All I'm saying is, why waste the space when they're only going to need > 1 subnet? If they want more than one subnet, give them a /48,/56,/60 > or whatever, as requested. > For at least the following reasons: 1. A single subnet may be the norm today because residential users and there vendors have been in a scarcity of addresses mentality for so long that applications to take full advantage of internet as it should be haven't been possible. That will change. 2. A single subnet may be enough for many (definitely not all and possibly not even most) today, but, certainly won't be the norm for long once IPv6 is more ubiquitous. 3. It places unnecessary limitations on the user and makes it unnecessarily more difficult to deploy additional capabilities. 4. Your increasing the workload on your own staff as your customers realize that one subnet is no longer enough and come back to you for larger assignments. 5. It's short sighted and assumes that the current IPv4 model will permanently apply to IPv6. Why waste valuable people's time to conserve nearly valueless renewable resources? Owen From tim at pelican.org Thu Jul 29 12:32:57 2010 From: tim at pelican.org (Tim Franklin) Date: Thu, 29 Jul 2010 17:32:57 +0000 (GMT) Subject: Addressing plan exercise for our IPv6 course In-Reply-To: Message-ID: <11395510.61280424777540.JavaMail.root@jennyfur.pelican.org> > Why waste valuable people's time to conserve nearly valueless > renewable resources? See my earlier comments on "upsell" and "control". While you have some ISPs starting from the mentality that gives us "accepting incoming connections is a chargeable extra", they're also going to be convinced that there's a revenue opportunity in segmenting customers who want N of some resource from those who want 2N, 4N, ... That the resource in question is, for all practical purposes, both free and infinite (cue someone with a 'tragedy of the commons' analysis) does not factor - if they want more, they must pay more! Regards, Tim. From jeroen at unfix.org Thu Jul 29 12:40:53 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 29 Jul 2010 19:40:53 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <11395510.61280424777540.JavaMail.root@jennyfur.pelican.org> References: <11395510.61280424777540.JavaMail.root@jennyfur.pelican.org> Message-ID: <4C51BD25.8030907@unfix.org> On 2010-07-29 19:32, Tim Franklin wrote: >> Why waste valuable people's time to conserve nearly valueless >> renewable resources? > > See my earlier comments on "upsell" and "control". While you > have some ISPs starting from the mentality that gives us "accepting > incoming connections is a chargeable extra", they're also going > to be convinced that there's a revenue opportunity in segmenting > customers who want N of some resource from those who want 2N, 4N, ... > That the resource in question is, for all practical purposes, both > free and infinite (cue someone with a 'tragedy of the commons' > analysis) does not factor - if they want more, they must pay more! Ever thought about this tiny thing called BANDWIDTH USAGE? It is what ISPs are charged by their transit providers / peers, thus why not do that do users? Oh yeah.. something with overselling capacity.... but that is not a big issue either, you can probably figure out what the average is, the lowest and the highest and come up with a good competitive pricing strategy from there. And there is another advantage there: the people who use a lot of bandwidth are actually paying for it then, thus you don't have to ratelimit these folks, as heck, they pay for it! Need more capacity in an area, well, no problem they paid for it already, thus do calculate that into your pricing too of course ;) Thus don't charge folks for the amount of IP addresses they have, that is not what you get charged for by your transit/peers either. Greets, Jeroen From stephen at sprunk.org Thu Jul 29 12:41:40 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 29 Jul 2010 12:41:40 -0500 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> Message-ID: <4C51BD54.8040900@sprunk.org> On 29 Jul 2010 12:19, Owen DeLong wrote: > On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote: > >> On 29 July 2010 15:49, Owen DeLong wrote: >> >>> If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. >>> >> There are 65,536 /48s in a /32. It's not about how available 2000::/3 >> is, it's hassle to keep requesting additional PA space. Some ISPs >> literally have millions of customers. >> > If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space? 1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts. > ... and paying sixteen times as much in assignment and maintenance fees. See the problem there? > It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you. > Yes. However, I don't think the RIRs are as willing to give out address space for _potential_ customers, e.g. if a telco or cableco wanted to assign a single block to each CO/head end to account for future growth. OTOH, you can get address space based on a /48 per actual customer, then actually assign a /64 per potential customer and have enough for massive growth. > Why waste valuable people's time to conserve nearly valueless > renewable resources? > By creating artificial scarcity, one can increase profits per unit of nearly-valueless, renewable resources. See also: De Beers and the demonizing of artificial diamonds. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From owen at delong.com Thu Jul 29 14:01:03 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Jul 2010 12:01:03 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <11395510.61280424777540.JavaMail.root@jennyfur.pelican.org> References: <11395510.61280424777540.JavaMail.root@jennyfur.pelican.org> Message-ID: <11D30A23-47F6-4B6D-A1A4-A07A6209554C@delong.com> On Jul 29, 2010, at 10:32 AM, Tim Franklin wrote: >> Why waste valuable people's time to conserve nearly valueless >> renewable resources? > > See my earlier comments on "upsell" and "control". While you have some ISPs starting from the mentality that gives us "accepting incoming connections is a chargeable extra", they're also going to be convinced that there's a revenue opportunity in segmenting customers who want N of some resource from those who want 2N, 4N, ... That the resource in question is, for all practical purposes, both free and infinite (cue someone with a 'tragedy of the commons' analysis) does not factor - if they want more, they must pay more! > If you want to build a business based on upsell and control by trying to convince users that they should give you extra money to provision a resource that costs you virtually nothing, then more power to you. However, I think this will, in the end, be as popular as american restaurants that charge for ice water. Consumers are moderately ignorant, but, not completely stupid. Address scarcity has allowed this model to succeed to some extent in IPv4, largely due to lack of alternatives and the fact that all consumer ISPs operate on this model. In IPv6, there is no scarcity, some ISPs will offer alternatives, and, consumers will rapidly learn about this disparity and I'm guessing that a model that says: Network Numbers Our Cost You Pay 1 $0.000000001 $0.00 2 $0.000000002 $1.00 4 $0.000000004 $2.00 etc. Is probably going to be at a significant competitive disadvantage vs. a model that says "You can have whatever address space you can justify. We'll start you with 65,536 networks which we believe is way more than enough for virtually any residential user. We don't charge you anything for address space. We think charging people for integers is illogical." However, if you think there is a competitive or revenue advantage, more power to you. Owen From owen at delong.com Thu Jul 29 14:06:18 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 29 Jul 2010 12:06:18 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C51BD54.8040900@sprunk.org> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <4C51BD54.8040900@sprunk.org> Message-ID: <481EEC47-CB8F-4470-87F1-BF1B5420ED68@delong.com> On Jul 29, 2010, at 10:41 AM, Stephen Sprunk wrote: > On 29 Jul 2010 12:19, Owen DeLong wrote: >> On Jul 29, 2010, at 8:00 AM, Matthew Walster wrote: >> >>> On 29 July 2010 15:49, Owen DeLong wrote: >>> >>>> If we give every household on the planet a /48 (approximately 3 billion /48s), we consume less than 1/8192 of 2000::/3. >>>> >>> There are 65,536 /48s in a /32. It's not about how available 2000::/3 >>> is, it's hassle to keep requesting additional PA space. Some ISPs >>> literally have millions of customers. >>> >> If you have millions of customers, why get a /32? Why not take that fact and ask for the right amount of space? 1,000,000 customers should easily qualify you for a /24 or thereabouts. If you have 8,000,000 customers, you should probably be asking for a /20 or thereabouts. >> > > ... and paying sixteen times as much in assignment and maintenance > fees. See the problem there? > If you have millions of IPv4 customers, then, you're already paying that for your IPv4 space. Since you pay the greater of your IPv4 or IPv6 utilization, I think the larger you are, the less likely it is that you will be paying more for IPv6 than IPv4, even if you give your customers all /48s of IPv6 instead of /32s of IPv4. >> It's not rocket science to ask for enough address space, and, if you have the number of customers to justify it based on a /48 per customer, the RIRs will happily allocate it to you. >> > > Yes. However, I don't think the RIRs are as willing to give out address > space for _potential_ customers, e.g. if a telco or cableco wanted to > assign a single block to each CO/head end to account for future growth. > OTOH, you can get address space based on a /48 per actual customer, then > actually assign a /64 per potential customer and have enough for massive > growth. > I believe you can actually do this to a pretty large extent within policy. The tricky part comes when you need more space and haven't met the HD Ratio requirements across the board. I agree there's room for improvement in the policy here. >> Why waste valuable people's time to conserve nearly valueless >> renewable resources? >> > > By creating artificial scarcity, one can increase profits per unit of > nearly-valueless, renewable resources. See also: De Beers and the > demonizing of artificial diamonds. > There are lots of opportunities to exploit people. I was limiting my comments to the layer 0-7 issues for the most part. I think optimizing the exploitation of customers is probably out of charter for this list. Owen From jmamodio at gmail.com Thu Jul 29 14:59:36 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 29 Jul 2010 14:59:36 -0500 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <4C509314.1090500@earthlink.net> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <15502.1280343347@localhost> <16710.1280345485@localhost> <4C509314.1090500@earthlink.net> Message-ID: The story keeps growing out of proportion and in the wrong direction ... This one claims that "six" guys hold the keys to bring back porn : http://indyposted.com/34983/six-guys-have-the-keys-to-the-internet/comment-page-1/#comment-15785 And ABC is talking about the "brotherhood" : http://abcnews.go.com/Technology/brotherhood-internet-keys-chosen/story?id=11271450&page=2 On the next ICANN meeting we should shave their heads and give them a monk outfit. Is ICANN doing such a poor PR job that mainstream media are getting this non-event not quite right ? Sigh From tim at pelican.org Thu Jul 29 16:40:13 2010 From: tim at pelican.org (Tim Franklin) Date: Thu, 29 Jul 2010 22:40:13 +0100 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <11D30A23-47F6-4B6D-A1A4-A07A6209554C@delong.com> References: <11395510.61280424777540.JavaMail.root@jennyfur.pelican.org> <11D30A23-47F6-4B6D-A1A4-A07A6209554C@delong.com> Message-ID: <4C51F53D.8020802@pelican.org> Owen DeLong wrote: > If you want to build a business based on upsell and control by trying > to convince users that they should give you extra money to provision > a resource that costs you virtually nothing, then more power to you. > > However, I think this will, in the end, be as popular as american > restaurants that charge for ice water. Sorry, I need to dial back on the cynicism / sarcasm a bit, it doesn't travel so well through the tubes - that's a rant about the attitudes I encounter, not my views! I *utterly* agree with you that trying to micro-manage the allocation size on a per-customer basis for high-volume residential / SOHO connections is a complete waste of resources. I equally believe that a number of ISPs operating in that market are going to try, not just one or two crazy outliers, based on the attitudes I touched on in my rant (which, again, *aren't* mine). Coming from an IPv4 business model that goes: Extra for a static IP Extra for more than one IP Extra for a contract that doesn't forbid incoming connections Extra for non-generic reverse DNS Extra for not blocking IPSec Extra for... I fully expect some ISPs to extend that into whatever parts of IPv6 they can measure and charge for. > Is probably going to be at a significant competitive disadvantage vs. > a model that says "You can have whatever address space you can > justify. We'll start you with 65,536 networks which we believe is way > more than enough for virtually any residential user. We don't charge > you anything for address space. We think charging people for integers > is illogical." I really hope you're right. I'd love to see the Internet opened back up again, for everyone. Regards, Tim. From tim at pelican.org Thu Jul 29 16:44:45 2010 From: tim at pelican.org (Tim Franklin) Date: Thu, 29 Jul 2010 22:44:45 +0100 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C51BD25.8030907@unfix.org> References: <11395510.61280424777540.JavaMail.root@jennyfur.pelican.org> <4C51BD25.8030907@unfix.org> Message-ID: <4C51F64D.8070304@pelican.org> Jeroen Massar wrote: >> See my earlier comments on "upsell" and "control". While you >> have some ISPs starting from the mentality that gives us "accepting >> incoming connections is a chargeable extra", they're also going >> to be convinced that there's a revenue opportunity in segmenting >> customers who want N of some resource from those who want 2N, 4N, ... >> That the resource in question is, for all practical purposes, both >> free and infinite (cue someone with a 'tragedy of the commons' >> analysis) does not factor - if they want more, they must pay more! > > Ever thought about this tiny thing called BANDWIDTH USAGE? [snip] > Thus don't charge folks for the amount of IP addresses they have, that > is not what you get charged for by your transit/peers either. Apologies - again, my sarcasm doesn't travel well. I don't think selling IP addresses is a good idea - it's an idea I hit against and get annoyed by in the IPv4 world that I expect at least some ISPs to try and perpetuate into the IPv6 world. Regards, Tim. From jabley at hopcount.ca Thu Jul 29 17:48:40 2010 From: jabley at hopcount.ca (Joe Abley) Date: Fri, 30 Jul 2010 00:48:40 +0200 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <959927.54991.qm@web59602.mail.ac4.yahoo.com> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> Message-ID: <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> On 2010-07-28, at 18:24, andrew.wallace wrote: > I think there is a social vulnerability in a group of people who need to travel, > a lot of the time, by plane, to exactly the same location to make new keys to > reset DNSSEC. Let's try to forget this "reset DNSSEC" meme. This is a technical list. Let's concentrate on what we can describe accurately. > What I think is, this is leaving them wide open to attack. If an attack was > state-sponsored, its likely they would be able to stop those selected people > reaching the location in the United States by way of operational officers > intercepting them by kidnap or murder, and indeed, a cyber attack without the > need for human intervention to stop the select people getting to their > destination could be done by knocking out the air traffic system. Which would, > hamper the resetting and creation of new keys for DNSSEC. The crypto officers who have generously volunteered to travel to the key management facility where they were enrolled from time to time will carry with them safety deposit box keys. As part of the process, they will unlock the safety deposit boxes contained within one of the safes in the key management facility tier 5, and extract a tamper-evident bag containing smart cards. The smart cards, under supervision of the crypto officer, are used to carry out the HSM operations that are planned for execution during that ceremony. In the event that insufficient crypto officers are able to attend (for whatever reason) ICANN retains the ability to drill the safety deposit boxes and extract the smart cards in order to preserve the security and stability of the DNS. ICANN would never do this unless the security and stability of the DNS was under threat, and would exercise this last-resort option with a great deal of public visibility. That full disclosure would unavoidably include details of people who were not able to attend. By publicising the list of crypto officers ICANN aims to increase transparency in the normal process (no drills required). We have no reason to think that our last-resort options will ever be exercised, but we have planned for them nonetheless because this is an important system and all bases need to be covered. All these details (and more) can be found in the DNSSEC Policy Statement (DPS) published at . I encourage anybody with the time and interest to dissect that document and challenge it wherever possible. Our aim is for maximum transparency and the greatest reason for the public to trust that the KSK is secure and worth trusting. One observation from a non-crypto operations guy that was drawn into this project and has learnt a lot from having to implement the infrastructure designed by real crypto people: security is not always obvious. What seems like a flaw is often not, and what seems safe is often risky. There is a great deal to learn about security engineering, and what seems obvious is frequently not. Joe From jmamodio at gmail.com Thu Jul 29 20:19:45 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 29 Jul 2010 20:19:45 -0500 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> Message-ID: > By publicising the list of crypto officers ICANN aims to increase transparency in the normal process (no drills required). We have no reason to think that our last-resort options will ever be exercised, but we have planned for them nonetheless because this is an important system and all bases need to be covered. I thought that was the original idea, to have a system that is based on community trust. I believe that the DNSSEC deployment team did a very good job, perhaps the extra PR and hype from ICANN generated some confusion but I don't think that it was the actual source of such a rainfall of misinformation. I suggest that it should be seriously considered to revoke the role of RKSH from the person that used that role to obtain publicity and self promotion, and request the immediate return of all cryptographic material. This is not something to get the guy on a limo an parade him on the streets of his local town or have now every one included on the public list interviewed by news outfits. So much buzz around his role and comments about being part of the "circle of trust" or "brotherhood" or anything similar discredits the entire process. My .02 Jorge From tal at whatexit.org Thu Jul 29 21:31:31 2010 From: tal at whatexit.org (Tom Limoncelli) Date: Thu, 29 Jul 2010 22:31:31 -0400 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: <1280002667.12383.2.camel@petrie> References: <4C4B4408.3040804@kingrst.com> <1280002667.12383.2.camel@petrie> Message-ID: On Sat, Jul 24, 2010 at 4:17 PM, William Pitcock wrote: > On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote: >> I am very curious to see how this would play with networks that >> wouldn't support such a technology. How would you ensure communication >> between a network that supported 33-Bit addressing and one that doesn't? > > 33-bit is a fucking retarded choice for any addressing scheme as it's > neither byte nor nibble-aligned. ?Infact, the 33rd bit would ensure that > an IPv4 header had to have 5 byte addresses. 33 bits nearly as useful as my proposal to extend the live of IPv4 by simply using the unused addresses. What "unused addresses" do I speak of? Currently the highest IP address is 255.255.255.255. Well, why not use the addresses from 256 to 999? IP addresses could go all the way to 999.999.999.999 and still be 3-digits per octet. We wouldn't even have to modify much code. How many times have you see a perl script that uses \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} as the regular expression for matching IP addresses? Tons of code assumes 3 digits per octet. None of that would have to change. We can get a few more bits another way. Why not steal bits from the port number? We used to think we needed 64k different ports. However, now we really only need port 80. Instant Message tunnels over port 80, so does nearly every important new protocol. Why not just reclaim those bits and use them for addresses? Instant address extension! Tom :-) <<<--- indicates humor or sarcasm (in case you weren't sure) -- http://EverythingSysadmin.com? -- my blog http://www.TomOnTime.com -- my advice From Valdis.Kletnieks at vt.edu Thu Jul 29 22:09:15 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Jul 2010 23:09:15 -0400 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: Your message of "Thu, 29 Jul 2010 20:19:45 CDT." References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> Message-ID: <8745.1280459355@localhost> On Thu, 29 Jul 2010 20:19:45 CDT, Jorge Amodio said: > I suggest that it should be seriously considered to revoke the role of > RKSH from the person that used that role to obtain publicity and self > promotion, and request the immediate return of all cryptographic > material. This is not something to get the guy on a limo an parade him > on the streets of his local town or have now every one included on the > public list interviewed by news outfits. Well, there's a bit of a problem - you have to make the list of key holders known, so that all and sundry can verify for themselves that ICANN (or any other single organization, for that matter) doesn't have all the marbles. A second point is that if you have 7 keyholders who are not well known, they're actually *easier* targets than if they're well known public figures. Think about that for a bit - who's easier to coerce without being detected, the guy who lives in the apartment downstairs from me, or somebody who's out in the open and identified as important? A pretty good article that puts a lot of the rest of it back into perspective: http://www.digitalsociety.org/2010/07/fantasy-role-playing-has-no-place-in-dnssec -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From franck at genius.com Thu Jul 29 22:23:25 2010 From: franck at genius.com (Franck Martin) Date: Fri, 30 Jul 2010 15:23:25 +1200 (FJT) Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> Message-ID: <29068462.194.1280460152569.JavaMail.franck@franck-martins-macbook-pro.local> Hmmm, from the interview of the British guy, the smart card seems to be in UK (he did a lapsus on it), which differs from what you describe. if all the smart cards are in the US in an individual safe deposit box in the same location, this raise the concern that there is only one place the smartcard can be stolen or destroyed. Also, is it part of the process that each smart card holder must routinely check that "his" smartcard is still there? I would have also thought, that there would be redundancy into these smartcards, like you need 3 out of 5 to rebuild the key, or something like this. I should read the spec.... Usually IETF people are well versed on security, so I believe the process to be quite sound. ----- Original Message ----- From: "Joe Abley" To: "andrew.wallace" Cc: nanog at nanog.org Sent: Friday, 30 July, 2010 10:48:40 AM Subject: Re: Web expert on his 'catastrophe' key for the internet On 2010-07-28, at 18:24, andrew.wallace wrote: > I think there is a social vulnerability in a group of people who need to travel, > a lot of the time, by plane, to exactly the same location to make new keys to > reset DNSSEC. Let's try to forget this "reset DNSSEC" meme. This is a technical list. Let's concentrate on what we can describe accurately. > What I think is, this is leaving them wide open to attack. If an attack was > state-sponsored, its likely they would be able to stop those selected people > reaching the location in the United States by way of operational officers > intercepting them by kidnap or murder, and indeed, a cyber attack without the > need for human intervention to stop the select people getting to their > destination could be done by knocking out the air traffic system. Which would, > hamper the resetting and creation of new keys for DNSSEC. The crypto officers who have generously volunteered to travel to the key management facility where they were enrolled from time to time will carry with them safety deposit box keys. As part of the process, they will unlock the safety deposit boxes contained within one of the safes in the key management facility tier 5, and extract a tamper-evident bag containing smart cards. The smart cards, under supervision of the crypto officer, are used to carry out the HSM operations that are planned for execution during that ceremony. In the event that insufficient crypto officers are able to attend (for whatever reason) ICANN retains the ability to drill the safety deposit boxes and extract the smart cards in order to preserve the security and stability of the DNS. ICANN would never do this unless the security and stability of the DNS was under threat, and would exercise this last-resort option with a great deal of public visibility. That full disclosure would unavoidably include details of people who were not able to attend. By publicising the list of crypto officers ICANN aims to increase transparency in the normal process (no drills required). We have no reason to think that our last-resort options will ever be exercised, but we have planned for them nonetheless because this is an important system and all bases need to be covered. All these details (and more) can be found in the DNSSEC Policy Statement (DPS) published at . I encourage anybody with the time and interest to dissect that document and challenge it wherever possible. Our aim is for maximum transparency and the greatest reason for the public to trust that the KSK is secure and worth trusting. One observation from a non-crypto operations guy that was drawn into this project and has learnt a lot from having to implement the infrastructure designed by real crypto people: security is not always obvious. What seems like a flaw is often not, and what seems safe is often risky. There is a great deal to learn about security engineering, and what seems obvious is frequently not. Joe From grobe0ba at gmail.com Thu Jul 29 22:38:56 2010 From: grobe0ba at gmail.com (Atticus) Date: Thu, 29 Jul 2010 23:38:56 -0400 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: References: <4C4B4408.3040804@kingrst.com> <1280002667.12383.2.camel@petrie> Message-ID: What world do live in? Yes, we extend the life of IPv4 by increasing the numeric range. As for "only needing port 80", I'm not really sure where you've been for the last decade or so. There's are hundreds of services using different ports, and tunneling them all makes absolutely no sense. Yes, we don't really need 65k ports, but stealing bits in the header from them is the most ridiculous thing I've heard yet. List of registered ports: http://www.iana.org/assignments/port-numbers Also take into account public access *nix servers, with people running their own services on whatever port they've taken or been assigned. How do you intend to implement a solution for that? Give public access servers the middle finger and keep on going? On Thu, Jul 29, 2010 at 10:31 PM, Tom Limoncelli wrote: > On Sat, Jul 24, 2010 at 4:17 PM, William Pitcock > wrote: > > On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote: > >> I am very curious to see how this would play with networks that > >> wouldn't support such a technology. How would you ensure communication > >> between a network that supported 33-Bit addressing and one that doesn't? > > > > 33-bit is a fucking retarded choice for any addressing scheme as it's > > neither byte nor nibble-aligned. Infact, the 33rd bit would ensure that > > an IPv4 header had to have 5 byte addresses. > > 33 bits nearly as useful as my proposal to extend the live of IPv4 by > simply using the unused addresses. What "unused addresses" do I speak > of? Currently the highest IP address is 255.255.255.255. Well, why > not use the addresses from 256 to 999? IP addresses could go all the > way to 999.999.999.999 and still be 3-digits per octet. > > We wouldn't even have to modify much code. How many times have you > see a perl script that uses \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} as the > regular expression for matching IP addresses? Tons of code assumes 3 > digits per octet. None of that would have to change. > > We can get a few more bits another way. Why not steal bits from the > port number? We used to think we needed 64k different ports. > However, now we really only need port 80. Instant Message tunnels > over port 80, so does nearly every important new protocol. Why not > just reclaim those bits and use them for addresses? Instant address > extension! > > Tom > > :-) <<<--- indicates humor or sarcasm (in case you weren't sure) > > -- > http://EverythingSysadmin.com -- my blog > http://www.TomOnTime.com -- my advice > > -- Byron Grobe From grobe0ba at gmail.com Thu Jul 29 22:45:03 2010 From: grobe0ba at gmail.com (Atticus) Date: Thu, 29 Jul 2010 23:45:03 -0400 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: References: <4C4B4408.3040804@kingrst.com> <1280002667.12383.2.camel@petrie> Message-ID: What world do live in? Yes, we extend the life of IPv4 by increasing the numeric range. As for "only needing port 80", I'm not really sure where you've been for the last decade or so. There's are hundreds of services using different ports, and tunneling them all makes absolutely no sense. Yes, we don't really need 65k ports, but stealing bits in the header from them is the most ridiculous thing I've heard yet. List of registered ports: http://www.iana.org/assignments/port-numbers Also take into account public access *nix servers, with people running their own services on whatever port they've taken or been assigned. How do you intend to implement a solution for that? Give public access servers the middle finger and keep on going? -- Byron Grobe -- Byron Grobe From jmamodio at gmail.com Thu Jul 29 22:45:28 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 29 Jul 2010 22:45:28 -0500 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <8745.1280459355@localhost> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> <8745.1280459355@localhost> Message-ID: > A pretty good article that puts a lot of the rest of it back into perspective: > > http://www.digitalsociety.org/2010/07/fantasy-role-playing-has-no-place-in-dnssec Good article indeed. It is highly unlikely that we will ever need the service of the RKSH, I agree that a well know public figure from the community could constitute a more difficult target, but as anything in information security, everything is relative. What I find unacceptable is to take advantage of the community trust by using the RKSH role for personal self promotion and publicity. Regards Jorge From dougb at dougbarton.us Thu Jul 29 22:49:04 2010 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 29 Jul 2010 20:49:04 -0700 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <29068462.194.1280460152569.JavaMail.franck@franck-martins-macbook-pro.local> References: <29068462.194.1280460152569.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4C524BB0.6060600@dougbarton.us> On 07/29/10 20:23, Franck Martin wrote: > I should read the spec.... Yes, preferably before commenting on it publicly ... Doug (... oops) -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From Valdis.Kletnieks at vt.edu Thu Jul 29 22:55:30 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 29 Jul 2010 23:55:30 -0400 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: Your message of "Thu, 29 Jul 2010 23:45:03 EDT." References: <4C4B4408.3040804@kingrst.com> <1280002667.12383.2.camel@petrie> Message-ID: <9610.1280462130@localhost> On Thu, 29 Jul 2010 23:45:03 EDT, Atticus said: > What world do live in? Yes, we extend the life of IPv4 by increasing the > numeric range. As for "only needing port 80", I'm not really sure where > you've been for the last decade or so. I hate to say this, but all of you who are actually thinking about stealing bits from IPv4 headers when IPv6 is already here: Look who started the "ONE bit or TWO bits" thread. YHBT. HAND. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dougb at dougbarton.us Thu Jul 29 22:58:52 2010 From: dougb at dougbarton.us (Doug Barton) Date: Thu, 29 Jul 2010 20:58:52 -0700 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <8745.1280459355@localhost> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> <8745.1280459355@localhost> Message-ID: <4C524DFC.9090702@dougbarton.us> On 07/29/10 20:09, Valdis.Kletnieks at vt.edu wrote: > On Thu, 29 Jul 2010 20:19:45 CDT, Jorge Amodio said: > >> I suggest that it should be seriously considered to revoke the role of >> RKSH from the person that used that role to obtain publicity and self >> promotion, and request the immediate return of all cryptographic >> material. This is not something to get the guy on a limo an parade him >> on the streets of his local town or have now every one included on the >> public list interviewed by news outfits. > > Well, there's a bit of a problem - you have to make the list of key holders > known, so that all and sundry can verify for themselves that ICANN (or any > other single organization, for that matter) doesn't have all the marbles. > > A second point is that if you have 7 keyholders who are not well known, they're > actually *easier* targets than if they're well known public figures. Think > about that for a bit - who's easier to coerce without being detected, the guy > who lives in the apartment downstairs from me, or somebody who's out in the > open and identified as important? > > A pretty good article that puts a lot of the rest of it back into perspective: > > http://www.digitalsociety.org/2010/07/fantasy-role-playing-has-no-place-in-dnssec That article has numerous errors in it as well, and in some ways is even worse because the guy is claiming to be a security expert who actually understands how it all works. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From grobe0ba at gmail.com Thu Jul 29 23:14:46 2010 From: grobe0ba at gmail.com (Atticus) Date: Fri, 30 Jul 2010 00:14:46 -0400 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: <9610.1280462130@localhost> References: <4C4B4408.3040804@kingrst.com> <1280002667.12383.2.camel@petrie> <9610.1280462130@localhost> Message-ID: I (unfortunately) cannot get native IPv6 from my ISP at this time, but do have several tunnels set up using Hurricane Electric's excellent tunnel brokerage service. All my local systems are dual-stack, my public access server has a routed /48 that I use to broker my own tunnels for devices (like my Motorola Droid cell phone). IPv6 is the future, and it is coming. As Valdis said, why try to extend the life of an effectively dead technology, and an inferior one at that. With IPSec compliance integrated into the protocol itself, and the hundreds of other benefits, why try to morph an old technology? In with the new, out with the old. IPv4 is very soon to be a completely dead beast, and we'll be all the better for it. This is the age of the internet, everything is interconnected. There is no possible way for v4 to keep up with the growth of this era. On Thu, Jul 29, 2010 at 11:55 PM, wrote: > On Thu, 29 Jul 2010 23:45:03 EDT, Atticus said: > > What world do live in? Yes, we extend the life of IPv4 by increasing the > > numeric range. As for "only needing port 80", I'm not really sure where > > you've been for the last decade or so. > > I hate to say this, but all of you who are actually thinking about stealing > bits from IPv4 headers when IPv6 is already here: Look who started the "ONE > bit > or TWO bits" thread. YHBT. HAND. ;) > > -- Byron Grobe From Valdis.Kletnieks at vt.edu Thu Jul 29 23:33:13 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 30 Jul 2010 00:33:13 -0400 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: Your message of "Fri, 30 Jul 2010 00:14:46 EDT." References: <4C4B4408.3040804@kingrst.com> <1280002667.12383.2.camel@petrie> <9610.1280462130@localhost> Message-ID: <10627.1280464393@localhost> On Fri, 30 Jul 2010 00:14:46 EDT, Atticus said: > technology, and an inferior one at that. With IPSec compliance integrated > into the protocol itself, and the hundreds of other benefits, why try to > morph an old technology? You *do* realize that IPv6 IPSec is the *exact same stuff* that's in IPv4, the only difference is that a "compliant" IPv6 stack has to include it, as opposed to the optional-but-all-major-OS-do-it status in IPv4, right? Does anybody know of *any* products that support dual-stack and include the IPv6 IPSec stuff but left the IPv4 IPSec stuff out? I've never actually seen one... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From franck at genius.com Thu Jul 29 23:48:11 2010 From: franck at genius.com (Franck Martin) Date: Fri, 30 Jul 2010 16:48:11 +1200 (FJT) Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <4C524BB0.6060600@dougbarton.us> Message-ID: <17393808.202.1280465258044.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Doug Barton" > To: "Franck Martin" > Cc: "Joe Abley" , nanog at nanog.org > Sent: Friday, 30 July, 2010 3:49:04 PM > Subject: Re: Web expert on his 'catastrophe' key for the internet > On 07/29/10 20:23, Franck Martin wrote: > > I should read the spec.... > > Yes, preferably before commenting on it publicly ... > > Do I look like someone that reads manuals? ;) From mysidia at gmail.com Thu Jul 29 23:55:38 2010 From: mysidia at gmail.com (James Hess) Date: Thu, 29 Jul 2010 23:55:38 -0500 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <29068462.194.1280460152569.JavaMail.franck@franck-martins-macbook-pro.local> References: <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> <29068462.194.1280460152569.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Thu, Jul 29, 2010 at 10:23 PM, Franck Martin wrote: > Hmmm, from the interview of the British guy, the smart card seems to be in UK (he did a lapsus on it), which differs from what you describe. You gotta read up on the whole ceremony and their statement of practices: https://www.iana.org/dnssec/icann-dps.txt ... Crypto Officers are different from Recovery Key Share Holders. Crypto officers hold a key to a safe deposit box in the safe room Safe 2, containing the operator cards. "Tier 5" Each vault contains a Tamper-evident bag (TEB) with a smart card required to authenticate with the HSM to perform crypto operations. Those cards don't leave the facility. The operatorscards are only authentication tokens, the key is stored on the hardware security modules. Hardware security modules, and the laptop+DVD+USB Flash stick required to operate them are stored in tamper evident bags in Safe 1. There are 7 crypto officers per site, but only 3 are required to authenticate to the HSM to enable it to perform operations. The recovery key share holders have a key to a bank safety deposit box under _their own_ control, containing a smartcard in tamper-evident bag, holding part of the HSM's internal encryption key. Each RKSH has to provide and maintain records of where they are storing their smartcard. 7 RKSH per site, but only 5 are required for recovery operations. -- -J From sean at donelan.com Fri Jul 30 00:14:44 2010 From: sean at donelan.com (Sean Donelan) Date: Fri, 30 Jul 2010 01:14:44 -0400 (EDT) Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> References: <354777.24939.qm@web59608.mail.ac4.yahoo.com> <20100728083327.GW96953@ronin.4ever.de> <959927.54991.qm@web59602.mail.ac4.yahoo.com> <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> Message-ID: On Fri, 30 Jul 2010, Joe Abley wrote: > One observation from a non-crypto operations guy that was drawn into >this project and has learnt a lot from having to implement the >infrastructure designed by real crypto people: security is not always >obvious. What seems like a flaw is often not, and what seems safe is >often risky. There is a great deal to learn about security engineering, >and what seems obvious is frequently not. Trust is also based on perception, whether justified or not. The participants in the community wanted this kind of key ceremony and many ceremonial key holders for a variety of reasons. If the community changes its mind in the future, and wants a different kind of key ceremony and ceremonial key holders, then submit comments and propose changes. Whether Recovery Key Share Holders serve any useful role after the HSMs are initialized is one of those questions that lots of beer may help. From tme at americafree.tv Fri Jul 30 00:59:13 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 30 Jul 2010 01:59:13 -0400 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: References: <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> <29068462.194.1280460152569.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <334BF2E6-47AE-44A7-8676-C7A8284398DD@americafree.tv> On Jul 30, 2010, at 12:55 AM, James Hess wrote: > On Thu, Jul 29, 2010 at 10:23 PM, Franck Martin > wrote: >> Hmmm, from the interview of the British guy, the smart card seems >> to be in UK (he did a lapsus on it), which differs from what you >> describe. > > You gotta read up on the whole ceremony and their statement of > practices: https://www.iana.org/dnssec/icann-dps.txt ... Hmm. Looks like an RFC, but isn't. Do you know if there are any plans to actually publish this ? Regards Marshall > Crypto > Officers are different from Recovery Key Share Holders. > Crypto officers hold a key to a safe deposit box in the safe room > Safe 2, containing the operator cards. > "Tier 5" > > Each vault contains a Tamper-evident bag (TEB) with a smart card > required to authenticate with the HSM to perform crypto operations. > Those cards don't leave the facility. > The operatorscards are only authentication tokens, the key is stored > on the hardware security modules. > > Hardware security modules, and the laptop+DVD+USB Flash stick required > to operate them are stored in > tamper evident bags in Safe 1. > > There are 7 crypto officers per site, but only 3 are required to > authenticate to the HSM to enable it to perform operations. > > The recovery key share holders have a key to a bank safety deposit > box under _their own_ control, > containing a smartcard in tamper-evident bag, holding part of > the HSM's internal encryption key. > > Each RKSH has to provide and maintain records of where they are > storing their smartcard. > 7 RKSH per site, but only 5 are required for recovery operations. > > > -- > -J > > From matthew at walster.org Fri Jul 30 02:27:29 2010 From: matthew at walster.org (Matthew Walster) Date: Fri, 30 Jul 2010 08:27:29 +0100 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> Message-ID: On 29 July 2010 18:08, Leo Vegoda wrote: > There's a good chance that in the long run multi-subnet home networks will become the norm. With all due respect, I can't see it. Why would a home user need multiple subnets? Are they really likely to have CPE capable of routing between subnets at 21st Century LAN speeds? Isn't that needlessly complicating the home environment? Additionally, when it comes to address size, Andy Davidson et al make a good point - you request what you expect to assign, and due to the massive availability of the IPv6 address space, you generally get it assigned within a few days. It just seems *wasteful* to me. /32 is a lot of space, if most customers are only going to have a few machines on one subnet, why not just give them a /64 and have an easy way to just click on a button on your customer portal or similar to assign a /48 and get it routed to them. M From jeroen at unfix.org Fri Jul 30 02:32:53 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 30 Jul 2010 09:32:53 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> Message-ID: <4C528025.5040407@unfix.org> On 2010-07-30 09:27, Matthew Walster wrote: > On 29 July 2010 18:08, Leo Vegoda wrote: >> There's a good chance that in the long run multi-subnet home networks will become the norm. > > With all due respect, I can't see it. Why would a home user need > multiple subnets? * Wireless * Wired * DMZ Those three I see a lot at various people's places. Also note that you should stop thinking of "today", think about what might be possible in 10, 20, 30, 40, 50 years... You don't have to bother your customers and your customers don't have to bother you anymore. The /48 for end-users might indeed be a bit on the much side, but a /56 is IMHO perfect fit for any home-site. The huge advantage of just giving out /48s though is that you don't have to care about if the connection is terminated at a home or a big corporation, as they say with shirts: one size fits all, simply as it is way too big. Greets, Jeroen From matthew at walster.org Fri Jul 30 03:13:54 2010 From: matthew at walster.org (Matthew Walster) Date: Fri, 30 Jul 2010 09:13:54 +0100 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <4C528025.5040407@unfix.org> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> <4C528025.5040407@unfix.org> Message-ID: On 30 July 2010 08:32, Jeroen Massar wrote: > On 2010-07-30 09:27, Matthew Walster wrote: >> On 29 July 2010 18:08, Leo Vegoda wrote: >>> There's a good chance that in the long run multi-subnet home networks will become the norm. >> >> With all due respect, I can't see it. Why would a home user need >> multiple subnets? > > * Wireless > * Wired > * DMZ > > Those three I see a lot at various people's places. I have *never* seen those three security zones separated outside of a business or the house of a nerd who runs his own Linux distro (Smoothwall etc). Furthermore, you're then pushing all that traffic into a $30 router which almost guaranteed will be underpowered. Look at it this way: When I signed up at tunnelbroker.net, I received a /64. I was happy, and I went about my business. I wanted to have a play with something a bit bigger, I pressed "Assign /48" and it was ready to go in under a second. That's how it *should* work, or at least, in my opinion. > Also note that you should stop thinking of "today", think about what > might be possible in 10, 20, 30, 40, 50 years... I'm not thinking of today, I'm thinking about the people who use these services. They don't know about networking, they don't know about security apart from "install this virus checker". Most of them will laboriously transfer files from system to system using a USB drive (or floppy disk!) even though there's a big flashing icon on their desktop saying "put files here and they'll magically appear on your other machine". These people don't know and don't *care* about networks. They care about the service they get. That isn't going to change in 50 years. If you genuinely think that regular residential users need multiple subnets to create a zoned config... You're wrong. It *will* piss them off, even if transparent. It's not just because of the speed (which as you say, will improve over time) it's because suddenly their wired-in Xbox in front of the TV just won't talk to the wireless Xbox their mate just brought round to have a play with. If you say that's down to education, you've entirely missed the point. > The /48 for end-users might indeed be a bit on the much side, but a /56 > is IMHO perfect fit for any home-site. The huge advantage of just giving > out /48s though is that you don't have to care about if the connection > is terminated at a home or a big corporation, as they say with shirts: > one size fits all, simply as it is way too big. Completely agree. M From drc at virtualized.org Fri Jul 30 03:20:19 2010 From: drc at virtualized.org (David Conrad) Date: Fri, 30 Jul 2010 10:20:19 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> Message-ID: <60122607-451A-4AB8-BBB9-6DA7A45A6758@virtualized.org> Matthew, On Jul 30, 2010, at 9:27 AM, Matthew Walster wrote: > On 29 July 2010 18:08, Leo Vegoda wrote: >> There's a good chance that in the long run multi-subnet home networks will become the norm. > > Why would a home user need multiple subnets? Even today, people are deploying multiple subnets in their homes. For example, Apple's Airport allows you to trivially set up a "guest" network that uses a different prefix (192.168.0.0/24) and different SSID than your "normal" network (10.0.1.0/24). > Are they really likely to have CPE capable of routing between subnets at 21st Century LAN speeds? Sure. Given time and Moore's law, I figure that's pretty much guaranteed. > Isn't that needlessly complicating the home environment? It's really a question of time horizons. If you buy into a future world of sensornets and massive home automation, rooms in houses would have tens or hundreds of devices, all individually addressable. And that's ignoring devices hung off your body attached via a personal area network. In such an environment, I can easily imagine multiple subnets. Of course, not everyone buys into these ideas (and they're certainly not going to happen tomorrow), however I believe one of the rationales behind /48s is "why architect in impediments if you don't have to?". > It just seems *wasteful* to me. It is (mindboggling so), in the sense of address utilization. However, there are a lot of /48s in IPv6 (if you multiply the current IPv4 address consumption rate by 1000, the 1/8th of the IPv6 address space currently used for global unicast allocations would last about 120 years), so people are suggesting we optimize for flexibility. As various people have noted, innovation is greatly facilitated when you have plentiful resources (mechanical power: industrial revolution, cpu power: GUIs, bandwidth: on-demand entertainment, etc). I gather the theory is that if you remove the need to be efficient with addresses, you'll see new innovations in the use of the network. > /32 is a > lot of space, if most customers are only going to have a few machines > on one subnet, why not just give them a /64 and have an easy way to > just click on a button on your customer portal or similar to assign a > /48 and get it routed to them. Unless you allocate the /64 out of the /48 you'd assign to them (in which case, why not simply assign the /48), it would force the customer to renumber. Perhaps not that big a deal, but it seems like work for little benefit. Regards, -drc From matthew at walster.org Fri Jul 30 03:36:49 2010 From: matthew at walster.org (Matthew Walster) Date: Fri, 30 Jul 2010 09:36:49 +0100 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: <60122607-451A-4AB8-BBB9-6DA7A45A6758@virtualized.org> References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> <60122607-451A-4AB8-BBB9-6DA7A45A6758@virtualized.org> Message-ID: On 30 July 2010 09:20, David Conrad wrote: > Even today, people are deploying multiple subnets in their homes. ?For example, Apple's Airport allows you to trivially set up a "guest" network that uses a different prefix (192.168.0.0/24) and different SSID than your "normal" network (10.0.1.0/24). Clearly, you think you're in the right and that you're making a valid and salient point. I see the above as unreasonable rationale. The very definition of "trivial" I would contend here - I honestly don't know a single resi user who has even logged into their modem/router. They're shipped with the username/password already entered by many ISPs these days, so they don't even have to set it up, they just plug it an and "use the internet". There's no point in arguing this further. As you rightly say, there's plenty of IPv6 space, I don't dispute the /48 point. I'm saying that there is no need for a /63 let alone a /48. No, I'm not saying /63 is a sensible allocation policy. I've yet to be convinced of any need for more than one subnet in the vast majority of residential internet cases. "sensornets" or otherwise (a concept invented in the early 20th Century and still not present outside of science fiction and commerce). M From owen at delong.com Fri Jul 30 03:53:45 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Jul 2010 01:53:45 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> Message-ID: On Jul 30, 2010, at 12:27 AM, Matthew Walster wrote: > On 29 July 2010 18:08, Leo Vegoda wrote: >> There's a good chance that in the long run multi-subnet home networks will become the norm. > > With all due respect, I can't see it. Why would a home user need > multiple subnets? Are they really likely to have CPE capable of > routing between subnets at 21st Century LAN speeds? Isn't that > needlessly complicating the home environment? > 1. Because eventually, home environments will become cognizant of the fact that they need more than one security profile for more than one usage. Because the number of devices present in home networks today is a very tiny fraction of the likely number in just a few years as new applications are developed to take advantage of the restoration of the end-to-end model of the internet. Because the devices in homes today represent a small fraction of the diversity that is likely within the next 10 years. 2. Yes, they are already available. A moderate PC with 4 Gig-E ports can actually route all four of them at near wire speed. For 10/100Mbps, you can get full featured CPE like the SRX-100 for around $500. That's the upper end of the residential CPE price range, but, it's a small fraction of the cost of that functionality just 2 years ago. 3. Not at all. In fact, one could argue that limited address space, NAT, uPNP, and a number of the things home users live with today complicate the home environment much more than a relatively simple router with DHCP-PD and some basic default security policies for such subnets as: Home sensor network and/or appliances Kids net (nanny software?) Home entertainment systems Guest wireless General purpose network > Additionally, when it comes to address size, Andy Davidson et al make > a good point - you request what you expect to assign, and due to the > massive availability of the IPv6 address space, you generally get it > assigned within a few days. It just seems *wasteful* to me. /32 is a > lot of space, if most customers are only going to have a few machines > on one subnet, why not just give them a /64 and have an easy way to > just click on a button on your customer portal or similar to assign a > /48 and get it routed to them. > Why go to all that extra effort instead of just giving them the /48 to begin with? What is the gain to the preservation of integers? How's this sound... Try IPv6 as designed with liberal address assignments in favor of good aggregation for 2000::/3. If we run out of that, I'll support any reasonable proposal to be conservative with the other 7/8ths of the address space if I'm still alive when we get there. Owen From diogo.montagner at gmail.com Fri Jul 30 04:06:31 2010 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Fri, 30 Jul 2010 17:06:31 +0800 Subject: Monitoring tools for IPv6 tools Message-ID: Hello, I am looking for monitoring tools that already have support to IPv6. I am looking for both freeware and commercial tools. Please, do you know what network management system are already supporting IPv6 ? Thanks ./diogo -montagner From mpalmer at hezmatt.org Fri Jul 30 04:05:06 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Fri, 30 Jul 2010 19:05:06 +1000 Subject: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? In-Reply-To: References: <4C4B4408.3040804@kingrst.com> <1280002667.12383.2.camel@petrie> Message-ID: <20100730090506.GD6176@hezmatt.org> On Thu, Jul 29, 2010 at 11:38:56PM -0400, Atticus wrote: > What world do live in? Yes, we extend the life of IPv4 by increasing the > numeric range. As for "only needing port 80", I'm not really sure where > you've been for the last decade or so. There's are hundreds of services > using different ports, and tunneling them all makes absolutely no sense. > Yes, we don't really need 65k ports, but stealing bits in the header from > them is the most ridiculous thing I've heard yet. Fark, Tom, he's gone straight past the hook, line, and sinker, and taken it all the way up to the second line guide. Better get the big pliers. - Matt From owen at delong.com Fri Jul 30 04:07:10 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Jul 2010 02:07:10 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> <4C528025.5040407@unfix.org> Message-ID: On Jul 30, 2010, at 1:13 AM, Matthew Walster wrote: > On 30 July 2010 08:32, Jeroen Massar wrote: >> On 2010-07-30 09:27, Matthew Walster wrote: >>> On 29 July 2010 18:08, Leo Vegoda wrote: >>>> There's a good chance that in the long run multi-subnet home networks will become the norm. >>> >>> With all due respect, I can't see it. Why would a home user need >>> multiple subnets? >> >> * Wireless >> * Wired >> * DMZ >> >> Those three I see a lot at various people's places. > > I have *never* seen those three security zones separated outside of a > business or the house of a nerd who runs his own Linux distro > (Smoothwall etc). Furthermore, you're then pushing all that traffic > into a $30 router which almost guaranteed will be underpowered. > If you'd like to come by my house, we can arrange that. I don't run linux on anything except one server. It doesn't do any routing. The routers that provide security boundaries are: 1. Juniper SRX-100 2. Apple Airport Extreme > Look at it this way: When I signed up at tunnelbroker.net, I received > a /64. I was happy, and I went about my business. I wanted to have a > play with something a bit bigger, I pressed "Assign /48" and it was > ready to go in under a second. That's how it *should* work, or at > least, in my opinion. > That's certainly one way to do it. However, I'm not sure it's how we would do it if we were starting today knowing what we know now. It does add a certain amount of complexity to our address planning and to our systems to make it work that way. IMHO, that complexity is unnecessary. >> Also note that you should stop thinking of "today", think about what >> might be possible in 10, 20, 30, 40, 50 years... > > I'm not thinking of today, I'm thinking about the people who use these > services. They don't know about networking, they don't know about > security apart from "install this virus checker". Most of them will > laboriously transfer files from system to system using a USB drive (or > floppy disk!) even though there's a big flashing icon on their desktop > saying "put files here and they'll magically appear on your other > machine". These people don't know and don't *care* about networks. > They care about the service they get. That isn't going to change in 50 > years. > First, your assumption that their knowledge level remains constant is absurd, so, in that statement you are thinking only of today. 10 years ago, most of those users wouldn't know what a web site was. Most of the do today. Just 10 years ago, most of them didn't know what email was. Most of them use email on a daily basis today. Second, with DHCP-PD and likely future CPE products, they will be able to simply connect pre-defined security zones to the right ports on the CPE based on the port labels. There will likely be a reasonable default security policy pre-installed for each zone. Even my parents could handle plugging things like TiVo, the stereo, etc. into ports labeled "Home Entertainment" while plugging the Kids computers into "Nanny" ports and their own computers into "General Access" ports. It's not significantly harder than the current need to get the LAN and WAN ports right on today's CPE. > If you genuinely think that regular residential users need multiple > subnets to create a zoned config... You're wrong. It *will* piss them > off, even if transparent. It's not just because of the speed (which as > you say, will improve over time) it's because suddenly their wired-in > Xbox in front of the TV just won't talk to the wireless Xbox their > mate just brought round to have a play with. If you say that's down to > education, you've entirely missed the point. > Why wouldn't they be able to talk to each other? You make assumptions about the future implementations of CPE there that I don't think are entirely accurate. I don't even see a reason to expect that wireless devices wouldn't be able to register for an appropriate security zone by device type in some implementations. Alternatively, the wired Xbox may need to initiate the connection to the wireless, or, vice-versa depending on implementation, but, I would expect CPE vendors to be able to solve that problem in the future. > Owen From BECHA at ripe.net Fri Jul 30 04:45:16 2010 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 30 Jul 2010 11:45:16 +0200 Subject: Monitoring tools for IPv6 tools In-Reply-To: References: Message-ID: <4C529F2C.6070108@ripe.net> Hi, > I am looking for monitoring tools that already have support to IPv6. I > am looking for both freeware and commercial tools. > > Please, do you know what network management system are already > supporting IPv6 ? we keep the list in the "LIR Handbook" (page #64) http://www.ripe.net/training/material/LIR-Training-Course/LIR-Handbook.pdf here is a list of some of the "free" (and/or open source) tools: # IPAT (IP Allocation Tool) http://nethead.de/index.php/ipat # NetDot https://netdot.uoregon.edu/trac/ # HaCi http://sourceforge.net/projects/haci/ # FreeIPdb http://home.globalcrossing.net/~freeipdb/ # Infoblox IPAM Freeware http://www.infoblox.com/services/infoblox-ipam-freeware.cfm Following tools do not support IPv6 yet, but is in the list of planned features: IPplan http://iptrack.sourceforge.net/ TIPP http://tipp.tobez.org/ & http://github.com/tobez/tipp ONA (OpenNetAdmin) http://opennetadmin.com/ Commercial IP Address Management (IPAM) Tools with IPv6 support In alphabetic order: Alcatel-Lucent VitalQIP DNS/DHCP IP Management Software & Appliance Bluecat Networks / Proteus Enterprise IPAM Appliance BT Diamond IP - IPControl(TM) Sapphyre Appliances BT Diamond ? IPControl(TM) Software Crypton UK - EasyIP(TM) Incognito / Address Commander(TM) Infoblox IPAM Express? Solution Internet Associates IPal Men & Mice Suite: IPAM management module Nixu NameSurfer Suite Other related commercial products that also support IPv6: EMC Ionix IPv6 Availability Manager NetCracker (Operational Support Systems or OSS) tool OPNET IT Guru (R) Network Planner These lists are for information purposes only and are not necessarily complete. RIPE NCC does not recommend any of them. There will be an article on RIPE Labs soon covering this in more detail... http://labs.ripe.net Regards, Vesna Manojlovic RIPE NCC Trainer From tore.anderson at redpill-linpro.com Fri Jul 30 05:10:42 2010 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Fri, 30 Jul 2010 12:10:42 +0200 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> <60122607-451A-4AB8-BBB9-6DA7A45A6758@virtualized.org> Message-ID: <4C52A522.9000401@redpill-linpro.com> Hi, * Matthew Walster > On 30 July 2010 09:20, David Conrad wrote: >> Even today, people are deploying multiple subnets in their homes. >> For example, Apple's Airport allows you to trivially set up a >> "guest" network that uses a different prefix (192.168.0.0/24) and >> different SSID than your "normal" network (10.0.1.0/24). > > Clearly, you think you're in the right and that you're making a > valid and salient point. I see the above as unreasonable rationale. > The very definition of "trivial" I would contend here - I honestly > don't know a single resi user who has even logged into their > modem/router. They're shipped with the username/password already > entered by many ISPs these days, so they don't even have to set it > up, they just plug it an and "use the internet". I can order VOIP and IP-TV services from the broadband provider I use at home. This is realised by using a separate subnet per service, so with VOIP+IPTV+Internet I'm already using three distinct subnets. I don't have to configure anything - that's all handled by my ISP. I just have to connect the IP telephone and IPTV tuner to the correct port on the CPE and I'm ready to go. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From matthew at walster.org Fri Jul 30 05:11:04 2010 From: matthew at walster.org (Matthew Walster) Date: Fri, 30 Jul 2010 11:11:04 +0100 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> Message-ID: On 30 July 2010 09:53, Owen DeLong wrote: > 2. ? ? ?Yes, they are already available. A moderate PC with 4 Gig-E > ? ? ? ?ports can actually route all four of them at near wire speed. > ? ? ? ?For 10/100Mbps, you can get full featured CPE like the SRX-100 > ? ? ? ?for around $500. That's the upper end of the residential CPE > ? ? ? ?price range, but, it's a small fraction of the cost of that functionality > ? ? ? ?just 2 years ago. A moderate PC is not a typical CPE. An SRX-100 is not a typical CPE. A Draytek DSL modem/router is not a typical CPE. Your typical CPE is, and always will be, a simple device. It will (and should) contain no user configuration that is required for operation. If it does, it's too complicated for the average user. > ? ? ? ? ? ? ? ?Home sensor network and/or appliances If it's really necessary to put these on a separate network, I highly doubt anyone but the true gadget geek will bother. > ? ? ? ? ? ? ? ?Kids net (nanny software?) Should be sorted at the PC-level, not the network level. If it really is going to be a network service, it should be off the home network and a managed service by an ISP somewhere. > ? ? ? ? ? ? ? ?Home entertainment systems Really? A separate network just for an HTPC? > ? ? ? ? ? ? ? ?Guest wireless Wireless is polluted enough. Supposing everything's fixed in the future and there is near-unlimited wireless spectrum, your average user is just going to give the encryption key to the router to the guest. Network management is not on the radar for 99.9% of resi users. Seriously, this is getting silly. I'm not even going to respond any more - if you genuinely think users care about network management, you're wrong. They treat it as a black box, and that isn't going to change for a long, long, long time. M From Valdis.Kletnieks at vt.edu Fri Jul 30 06:51:36 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 30 Jul 2010 07:51:36 -0400 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: Your message of "Fri, 30 Jul 2010 11:11:04 BST." References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> Message-ID: <61902.1280490696@localhost> On Fri, 30 Jul 2010 11:11:04 BST, Matthew Walster said: > Seriously, this is getting silly. I'm not even going to respond any > more - if you genuinely think users care about network management, > you're wrong. They treat it as a black box, and that isn't going to > change for a long, long, long time. The point you're missing is that users may not care about network management *directly* - but they may care very much about the *features* that the network-ready appliance they bought at Best Buy provides them using multiple subnets under the hood. If the box says "provides separate 'Guest' wireless access", that can be a selling point even if the user doesn't know it happens because the unit uses separate subnets for the "home" and "guest" addresses. End users are already used to a world where they plug in some hardware, run a program off the CD, have it ask a few questions about how you want to use the device, click the 'Do It!' button, and it all works. If networking is any different experience *for the end user*, we've as an industry screwed up big time. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From darden at armc.org Fri Jul 30 07:21:28 2010 From: darden at armc.org (Patrick Darden) Date: Fri, 30 Jul 2010 08:21:28 -0400 Subject: Monitoring tools for IPv6 tools In-Reply-To: <4C529F2C.6070108@ripe.net> References: <4C529F2C.6070108@ripe.net> Message-ID: <4C52C3C8.8020407@armc.org> I think he was looking for something more in the nature of network monitoring/analysis systems that support IPv6, like NTOP. ntop has been ported to ipv6--although I am unsure of the results. http://www.ntop.org/trac/wiki/ntop cold is a snffer/analyzer with ipv6 support. http://mailman.isi.edu/pipermail/6bone/2000-August/003161.html wireshark is a fantastic sniffer/analyzer, and it supports ipv6. http://wiki.wireshark.org/ snoop comes with Solaris 10, and it supports ipv6. http://docs.sun.com/app/docs/doc/816-4554/gexky?a=view tracepath6 and traceroute6 come with the iptraf package for linux. ethereal has a non-commercial version. http://www.ethereal.com/ iperf lets you simply monitor ipv6 tcp/udp performance. http://dast.nlanr.net/projects/Iperf/ mtr uses traceroute and ping, http://www.bitwizard.nl/mtr/ nagios is a host/server/service monitoring tool. http://www.nagios.org/ weathermap creates a visual network diagram showing health. http://netmon.grnet.gr/weathermap/ Is this what you wanted? --p On 07/30/2010 05:45 AM, Vesna Manojlovic wrote: > Hi, > >> I am looking for monitoring tools that already have support to IPv6. I >> am looking for both freeware and commercial tools. >> >> Please, do you know what network management system are already >> supporting IPv6 ? > > we keep the list in the "LIR Handbook" (page #64) > http://www.ripe.net/training/material/LIR-Training-Course/LIR-Handbook.pdf > > > here is a list of some of the "free" (and/or open source) tools: > > # IPAT (IP Allocation Tool) http://nethead.de/index.php/ipat > # NetDot https://netdot.uoregon.edu/trac/ > # HaCi http://sourceforge.net/projects/haci/ > # FreeIPdb http://home.globalcrossing.net/~freeipdb/ > # Infoblox IPAM Freeware > http://www.infoblox.com/services/infoblox-ipam-freeware.cfm > > Following tools do not support IPv6 yet, but is in the list of planned > features: > IPplan http://iptrack.sourceforge.net/ > TIPP http://tipp.tobez.org/ & http://github.com/tobez/tipp > ONA (OpenNetAdmin) http://opennetadmin.com/ > > Commercial IP Address Management (IPAM) Tools with IPv6 support > In alphabetic order: > > Alcatel-Lucent VitalQIP DNS/DHCP IP Management Software & Appliance > Bluecat Networks / Proteus Enterprise IPAM Appliance > BT Diamond IP - IPControl(TM) Sapphyre Appliances > BT Diamond ? IPControl(TM) Software > Crypton UK - EasyIP(TM) > Incognito / Address Commander(TM) > Infoblox IPAM Express? Solution > Internet Associates IPal > Men & Mice Suite: IPAM management module > Nixu NameSurfer Suite > > Other related commercial products that also support IPv6: > > EMC Ionix IPv6 Availability Manager > NetCracker (Operational Support Systems or OSS) tool > OPNET IT Guru (R) Network Planner > > These lists are for information purposes only and are not necessarily > complete. RIPE NCC does not recommend any of them. > > There will be an article on RIPE Labs soon covering this in more > detail... > > http://labs.ripe.net > > Regards, > Vesna Manojlovic > RIPE NCC Trainer > > From diogo.montagner at gmail.com Fri Jul 30 07:26:52 2010 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Fri, 30 Jul 2010 20:26:52 +0800 Subject: Monitoring tools for IPv6 tools In-Reply-To: <4C52C3C8.8020407@armc.org> References: <4C529F2C.6070108@ripe.net> <4C52C3C8.8020407@armc.org> Message-ID: Yes. This one. But also looking for IPv6 support for tools like OpenView, Infovista, Concord eHealth. Thanks ./diogo -montagner On Fri, Jul 30, 2010 at 8:21 PM, Patrick Darden wrote: > > I think he was looking for something more in the nature of network > monitoring/analysis systems that support IPv6, like NTOP. > > ntop has been ported to ipv6--although I am unsure of the results. > ?http://www.ntop.org/trac/wiki/ntop > cold is a snffer/analyzer with ipv6 support. > ?http://mailman.isi.edu/pipermail/6bone/2000-August/003161.html > wireshark is a fantastic sniffer/analyzer, and it supports ipv6. > ?http://wiki.wireshark.org/ > snoop comes with Solaris 10, and it supports ipv6. > ?http://docs.sun.com/app/docs/doc/816-4554/gexky?a=view > tracepath6 and traceroute6 come with the iptraf package for linux. > ethereal has a non-commercial version. ?http://www.ethereal.com/ > iperf lets you simply monitor ipv6 tcp/udp performance. > ?http://dast.nlanr.net/projects/Iperf/ > mtr uses traceroute and ping, http://www.bitwizard.nl/mtr/ > nagios is a host/server/service monitoring tool. http://www.nagios.org/ > weathermap creates a visual network diagram showing health. > ?http://netmon.grnet.gr/weathermap/ > > Is this what you wanted? > --p > > On 07/30/2010 05:45 AM, Vesna Manojlovic wrote: >> >> Hi, >> >>> I am looking for monitoring tools that already have support to IPv6. I >>> am looking for both freeware and commercial tools. >>> >>> Please, do you know what network management system are already >>> supporting IPv6 ? >> >> we keep the list in the "LIR Handbook" (page #64) >> http://www.ripe.net/training/material/LIR-Training-Course/LIR-Handbook.pdf >> >> here is a list of some of the "free" (and/or open source) tools: >> >> # IPAT (IP Allocation Tool) ? http://nethead.de/index.php/ipat >> # NetDot ? ? https://netdot.uoregon.edu/trac/ >> # HaCi ? ? http://sourceforge.net/projects/haci/ >> # FreeIPdb ? ? ?http://home.globalcrossing.net/~freeipdb/ >> # Infoblox IPAM Freeware >> http://www.infoblox.com/services/infoblox-ipam-freeware.cfm >> >> Following tools do not support IPv6 yet, but is in the list of planned >> features: >> IPplan http://iptrack.sourceforge.net/ >> TIPP http://tipp.tobez.org/ & http://github.com/tobez/tipp >> ONA (OpenNetAdmin) http://opennetadmin.com/ >> >> Commercial IP Address Management (IPAM) Tools with IPv6 support >> In alphabetic order: >> >> Alcatel-Lucent VitalQIP DNS/DHCP IP Management Software & Appliance >> Bluecat Networks / Proteus Enterprise IPAM Appliance >> BT Diamond IP - IPControl(TM) Sapphyre Appliances >> BT Diamond ? IPControl(TM) Software >> Crypton UK - EasyIP(TM) >> Incognito / Address Commander(TM) >> Infoblox IPAM Express? Solution >> Internet Associates IPal >> Men & Mice Suite: IPAM management module >> Nixu NameSurfer Suite >> >> Other related commercial products that also support IPv6: >> >> EMC Ionix IPv6 Availability Manager >> NetCracker (Operational Support Systems or OSS) tool >> OPNET IT Guru (R) Network Planner >> >> These lists are for information purposes only and are not necessarily >> complete. RIPE NCC does not recommend any of them. >> >> There will be an article on RIPE Labs soon covering this in more detail... >> >> http://labs.ripe.net >> >> Regards, >> Vesna Manojlovic >> RIPE NCC Trainer >> >> > > From bicknell at ufp.org Fri Jul 30 07:42:30 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 30 Jul 2010 05:42:30 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> <4C528025.5040407@unfix.org> Message-ID: <20100730124230.GA63401@ussenterprise.ufp.org> In a message written on Fri, Jul 30, 2010 at 09:13:54AM +0100, Matthew Walster wrote: > On 30 July 2010 08:32, Jeroen Massar wrote: > > On 2010-07-30 09:27, Matthew Walster wrote: > >> On 29 July 2010 18:08, Leo Vegoda wrote: > >> With all due respect, I can't see it. Why would a home user need > >> multiple subnets? > > > > * Wireless > > * Wired > > * DMZ > > > > Those three I see a lot at various people's places. > > I have *never* seen those three security zones separated outside of a > business or the house of a nerd who runs his own Linux distro > (Smoothwall etc). Furthermore, you're then pushing all that traffic > into a $30 router which almost guaranteed will be underpowered. I know of at least one nationwide DSL provider that ships (with higher end products) a WiFi router with a single checkbox for "guest network", which provides a captive portal style guest WiFi network for folks who visit your house. The same box has had for years a "DMZ" function for your gaming console/machine. The guest network is a separate subnet. The DMZ today is not, it's the wierd IPv4 pass-through thing many NAT boxes do to make weird games work. Still, it's all in a box thats given away for free by an ISP to a new signup; and with IPv6 having more addresses I see no reason each might not be its own subnet in 5-10 more years when IPv6 has taken hold. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From nanogf at spoofer.com Fri Jul 30 10:07:58 2010 From: nanogf at spoofer.com (nanogf .) Date: Fri, 30 Jul 2010 08:07:58 -0700 Subject: Monitoring tools for IPv6 tools Message-ID: <20100730080758.1229D090@resin06.mta.everyone.net> https://docs.google.com/viewer?url=http://www.6diss.org/tutorials/management.pdf http://tools.6net.org/ --- diogo.montagner at gmail.com wrote: From: Diogo Montagner To: nanog at nanog.org Subject: Monitoring tools for IPv6 tools Date: Fri, 30 Jul 2010 17:06:31 +0800 Hello, I am looking for monitoring tools that already have support to IPv6. I am looking for both freeware and commercial tools. Please, do you know what network management system are already supporting IPv6 ? Thanks ./diogo -montagner _____________________________________________________________ Get your own *free* email address like this one from www.OwnEmail.com From jcdill.lists at gmail.com Fri Jul 30 10:24:07 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 30 Jul 2010 08:24:07 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> Message-ID: <4C52EE97.9090102@gmail.com> Matthew Walster wrote: > On 29 July 2010 18:08, Leo Vegoda wrote: > >> There's a good chance that in the long run multi-subnet home networks will become the norm. >> > > With all due respect, I can't see it. Why would a home user need > multiple subnets? Are they really likely to have CPE capable of > routing between subnets at 21st Century LAN speeds? Isn't that > needlessly complicating the home environment? I strongly urge all my competitors to approach IPv6 with this philosophy. In other words, in the long run it will push up your labor costs (for admins, for customer support), and push down your customer satisfaction because you were needlessly worried about the "scarcity" of a plentiful resource and didn't think ahead to new technologies, new ideas, and hampered your network with an allocation scheme that didn't expand gracefully to acomodate new uses. Look at it this way - most (ISPs, businesses, consumers, appliance vendors) are going to allocate according to the recommendations or be using an allocation according to the recommendations. Why are you even *considering* using a different allocation scheme? What do *you* gain? All I see are headaches from doing it differently. When you hire you will need to retrain admins who are accustomed to the recommended system. When you get new customers, you will have to retrain them to use your non-standard system. When they try to use appliances that are pre-configured to use the recommended system, their appliances won't work right or will need special configuration. Etc. If - IF the recommendations are not conservative enough (which is considered to be a very remote possibility), then we can change the recommendations when we put the next 1/8 of the IPv6 IPs into service. But consider the possible use case where we actually start to run out of IPs in this first 1/8 segment of the IPv6 space. It's not going to happen by IP usage from current services. It's going to happen by IP consumption from new, as yet unimagined, services. And if we have all these new services (devices, appliances) that require IP addresses then it means we WILL need to do subnetting at end user premises. jc From marty at supine.com Fri Jul 30 10:38:55 2010 From: marty at supine.com (Martin Barry) Date: Fri, 30 Jul 2010 17:38:55 +0200 Subject: SingTel (AS7473) is only announcing ConnectPlus (AS9911) routes to Level3 (AS3356) in SJC? Message-ID: Anyone on the list who can offer an explanation about the following scenario? We have taken this up with providers at either end but it will take awhile to filter up to the ASes in question. We were seeing a London to Singapore connection go via San Jose causing a 50%+ increase in latency. It appears that SingTel (AS7473) is only announcing ConnectPlus (AS9911) routes to Level3 (AS3356) in SJC. However they have many adjacencies in many countries and other routes of both AS7473 and it's other downstreams don't appear to be affected (although I haven't tested them all). Traceroutes are appended at the end but to see for yourself use 202.176.222.0 as a BGP or traceroute query in the Level3 looking glass for both London and any other location, then compare with 167.172.93.0 Checking another large AS at random, they see AS7473 announcing AS9911 routes in London. thanks Marty Show Level 3 (London, England) Traceroute to 202.176.222.212 1 ae-34-52.ebr2.London1.Level3.net (4.69.139.97) 0 msec 0 msec 0 msec 2 ae-42-42.ebr1.NewYork1.Level3.net (4.69.137.70) 68 msec 68 msec ae-41-41.ebr1.NewYork1.Level3.net (4.69.137.66) 72 msec 3 ae-71-71.csw2.NewYork1.Level3.net (4.69.134.70) 68 msec ae-81-81.csw3.NewYork1.Level3.net (4.69.134.74) 72 msec ae-61-61.csw1.NewYork1.Level3.net (4.69.134.66) 76 msec 4 ae-82-82.ebr2.NewYork1.Level3.net (4.69.148.41) 80 msec ae-92-92.ebr2.NewYork1.Level3.net (4.69.148.45) 84 msec ae-72-72.ebr2.NewYork1.Level3.net (4.69.148.37) 80 msec 5 ae-2-2.ebr4.SanJose1.Level3.net (4.69.135.185) 144 msec 144 msec 144 msec 6 ae-74-74.csw2.SanJose1.Level3.net (4.69.134.246) 140 msec ae-94-94.csw4.SanJose1.Level3.net (4.69.134.254) 148 msec ae-64-64.csw1.SanJose1.Level3.net (4.69.134.242) 144 msec 7 ae-12-69.car2.SanJose1.Level3.net (4.68.18.4) 140 msec ae-32-89.car2.SanJose1.Level3.net (4.68.18.132) 140 msec ae-22-79.car2.SanJose1.Level3.net (4.68.18.68) 140 msec 8 SINGAPORE-T.car2.SanJose1.Level3.net (4.79.42.230) 140 msec 140 msec 136 msec 9 POS3-2.sngtp-ar2.ix.singtel.com (203.208.182.205) [AS7473 {APNIC-AS-2-BLOCK}] 148 msec 152 msec 203.208.182.105 [AS7473 {APNIC-AS-2-BLOCK}] 136 msec 10 ge-4-0-0-0.plapx-cr2.ix.singtel.com (203.208.183.173) [AS7473 {APNIC-AS-2-BLOCK}] 148 msec xe-1-0-0-0.plapx-cr3.ix.singtel.com (203.208.183.170) [AS7473 {APNIC-AS-2-BLOCK}] 140 msec 140 msec 11 ge-2-1-0-0.sngtp-dr1.ix.singtel.com (203.208.183.62) [AS7473 {APNIC-AS-2-BLOCK}] 348 msec so-2-0-0-0.sngtp-cr1.ix.singtel.com (203.208.149.181) [AS7473 {APNIC-AS-2-BLOCK}] 336 msec ge-3-0-0-0.sngtp-dr1.ix.singtel.com (203.208.183.66) [AS7473 {APNIC-AS-2-BLOCK}] 360 msec 12 ae0-0.sngtp-cr1.ix.singtel.com (203.208.183.57) [AS7473 {APNIC-AS-2-BLOCK}] 328 msec ge-4-0-0-0.sngtp-cr2.ix.singtel.com (203.208.182.102) [AS7473 {APNIC-AS-2-BLOCK}] 336 msec 202.160.250.226 [AS7473 {APNIC-AS-2-BLOCK}] 336 msec 13 ge-3-0-0-0.sngtp-dr1.ix.singtel.com (203.208.183.66) [AS7473 {APNIC-AS-2-BLOCK}] 348 msec 524 msec 416 msec 14 202.160.250.226 [AS7473 {APNIC-AS-2-BLOCK}] 328 msec 344 msec 203.208.232.234 [AS9911 {APNIC-AS-3-BLOCK}] 336 msec 15 203.208.129.29 [AS9911 {APNIC-AS-3-BLOCK}] 308 msec * 412 msec 16 203.208.232.234 [AS9911 {APNIC-AS-3-BLOCK}] 376 msec * * 17 * * * Show Level 3 (London, England) Traceroute to 167.172.93.1 1 SINGAPORE-T.car1.London1.Level3.net (212.187.160.190) 0 msec 4 msec 0 msec 2 so-0-2-0-0.sngtp-ar6.ix.singtel.com (203.208.151.133) [AS7473 {APNIC-AS-2-BLOCK}] 284 msec 276 msec 276 msec 3 203.208.152.134 [AS7473 {APNIC-AS-2-BLOCK}] 288 msec 284 msec 288 msec 4 ge-5-0-8-0.hkgcw-cr3.ix.singtel.com (203.208.152.37) [AS7473 {APNIC-AS-2-BLOCK}] 276 msec 276 msec ge-5-0-2-0.hkgcw-cr3.ix.singtel.com (203.208.152.117) [AS7473 {APNIC-AS-2-BLOCK}] 284 msec 5 * * * Router: mpr1.lhr1.uk.above.net Command: traceroute 202.176.222.212 traceroute to 202.176.222.212 (202.176.222.212), 30 hops max, 40 byte packets 1 195.66.225.10 (195.66.225.10) 0.991 ms 2.433 ms 0.927 ms 2 so-0-2-0-0.sngtp-ar6.ix.singtel.com (203.208.151.133) 455.799 ms 271.095 ms 254.167 ms 3 203.208.149.210 (203.208.149.210) 255.751 ms 254.794 ms 254.838 ms 4 202.160.250.226 (202.160.250.226) 263.850 ms 263.912 ms 292.504 ms 5 203.208.129.29 (203.208.129.29) 275.109 ms 282.247 ms 313.901 ms 6 203.208.232.234 (203.208.232.234) 265.677 ms 265.604 ms 266.072 ms 7 * * * From owen at delong.com Fri Jul 30 10:57:40 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 30 Jul 2010 08:57:40 -0700 Subject: Addressing plan exercise for our IPv6 course In-Reply-To: References: <20100722124943.6f52345a@opy.nosense.org> <4C47BC3B.9020201@nic.br> <6289.1279844658@localhost> <1279845943.28305.7.camel@karl> <2C4DBA48-36B7-41C1-B1D1-7660AAE8484D@delong.com> <90F9E090-AFF4-4BC3-B05B-CC70E56D385B@icann.org> Message-ID: On Jul 30, 2010, at 3:11 AM, Matthew Walster wrote: > On 30 July 2010 09:53, Owen DeLong wrote: >> 2. Yes, they are already available. A moderate PC with 4 Gig-E >> ports can actually route all four of them at near wire speed. >> For 10/100Mbps, you can get full featured CPE like the SRX-100 >> for around $500. That's the upper end of the residential CPE >> price range, but, it's a small fraction of the cost of that functionality >> just 2 years ago. > > A moderate PC is not a typical CPE. An SRX-100 is not a typical CPE. A > Draytek DSL modem/router is not a typical CPE. > > Your typical CPE is, and always will be, a simple device. It will (and > should) contain no user configuration that is required for operation. > If it does, it's too complicated for the average user. > An Apple Airport Extreme is relatively typical CEP and meets your criteria. I have one forwarding packets at 800Mbps throughput between the LAN and WAN ports. On a gig-E network, that seems close enough to LAN speed. A lot of your "simple devices" are actually PCs running linux under the hood, so, in fact, a moderate PC today is likely to be tomorrows "toaster". >> Home sensor network and/or appliances > > If it's really necessary to put these on a separate network, I highly > doubt anyone but the true gadget geek will bother. > Then you will be surprised. >> Kids net (nanny software?) > > Should be sorted at the PC-level, not the network level. If it really > is going to be a network service, it should be off the home network > and a managed service by an ISP somewhere. > We can agree to disagree about this. >> Home entertainment systems > > Really? A separate network just for an HTPC? > No. A separate network for: Playstation/Wii/etc. Amplifier (See Yamaha RXV-3900 for example) HTPCs Apple TVs TiVOs Mac Minis operating in that role (the new one rocks for that) DVD players Blue Ray players Monitors/Televisions etc. Just because the only home entertainment thing you have today with an ethernet port is an HTPC (which, btw, is way geekier than half the CPE you argued against at this point) does not mean that everyone will be subject to such limitations. >> Guest wireless > > Wireless is polluted enough. Supposing everything's fixed in the > future and there is near-unlimited wireless spectrum, your average > user is just going to give the encryption key to the router to the > guest. Network management is not on the radar for 99.9% of resi users. > Again, we can agree to disagree. Lots of people I know, including non-technical ones have turned on the guest wireless capability with their Airport Extremes. > Seriously, this is getting silly. I'm not even going to respond any > more - if you genuinely think users care about network management, > you're wrong. They treat it as a black box, and that isn't going to > change for a long, long, long time. > I don't think they care. I think it will be automated for them in the future. The argument wasn't about whether users care or not. The argument was about whether households would eventually come to a point where the norm was to require more than one subnet per household. You remain in denial, and, that's fine, but, I think enough use cases have been shown and enough people have told you that they already have multiple subnets in IPv4 as a result of default service they receive from their provider to prove that multiple subnets in the average home will be commonplace in the future. Owen From cscora at apnic.net Fri Jul 30 13:10:38 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 31 Jul 2010 04:10:38 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201007301810.o6UIAcKF007446@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 31 Jul, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 327096 Prefixes after maximum aggregation: 150524 Deaggregation factor: 2.17 Unique aggregates announced to Internet: 159810 Total ASes present in the Internet Routing Table: 34482 Prefixes per ASN: 9.49 Origin-only ASes present in the Internet Routing Table: 29935 Origin ASes announcing only one prefix: 14512 Transit ASes present in the Internet Routing Table: 4547 Transit-only ASes present in the Internet Routing Table: 101 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 38 Max AS path prepend of ASN (22394) 35 Prefixes from unregistered ASNs in the Routing Table: 306 Unregistered ASNs in the Routing Table: 113 Number of 32-bit ASNs allocated by the RIRs: 716 Prefixes from 32-bit ASNs in the Routing Table: 874 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 165 Number of addresses announced to Internet: 2281256256 Equivalent to 135 /8s, 249 /16s and 53 /24s Percentage of available address space announced: 61.5 Percentage of allocated address space announced: 66.4 Percentage of available address space allocated: 92.8 Percentage of address space in use by end-sites: 84.0 Total number of prefixes smaller than registry allocations: 155817 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 79192 Total APNIC prefixes after maximum aggregation: 27270 APNIC Deaggregation factor: 2.90 Prefixes being announced from the APNIC address blocks: 76117 Unique aggregates announced from the APNIC address blocks: 33644 APNIC Region origin ASes present in the Internet Routing Table: 4145 APNIC Prefixes per ASN: 18.36 APNIC Region origin ASes announcing only one prefix: 1154 APNIC Region transit ASes present in the Internet Routing Table: 633 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 536013088 Equivalent to 31 /8s, 242 /16s and 233 /24s Percentage of available APNIC address space announced: 79.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 58/8, 59/8, 60/8, 61/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary ---------------------------- Prefixes being announced by ARIN Region ASes: 134849 Total ARIN prefixes after maximum aggregation: 69675 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 107709 Unique aggregates announced from the ARIN address blocks: 42178 ARIN Region origin ASes present in the Internet Routing Table: 13823 ARIN Prefixes per ASN: 7.79 ARIN Region origin ASes announcing only one prefix: 5299 ARIN Region transit ASes present in the Internet Routing Table: 1367 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 38 Number of ARIN addresses announced to Internet: 730011936 Equivalent to 43 /8s, 131 /16s and 25 /24s Percentage of available ARIN address space announced: 62.2 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 75230 Total RIPE prefixes after maximum aggregation: 43549 RIPE Deaggregation factor: 1.73 Prefixes being announced from the RIPE address blocks: 68351 Unique aggregates announced from the RIPE address blocks: 44695 RIPE Region origin ASes present in the Internet Routing Table: 14643 RIPE Prefixes per ASN: 4.67 RIPE Region origin ASes announcing only one prefix: 7534 RIPE Region transit ASes present in the Internet Routing Table: 2180 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 433696384 Equivalent to 25 /8s, 217 /16s and 174 /24s Percentage of available RIPE address space announced: 76.0 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 29324 Total LACNIC prefixes after maximum aggregation: 6984 LACNIC Deaggregation factor: 4.20 Prefixes being announced from the LACNIC address blocks: 27836 Unique aggregates announced from the LACNIC address blocks: 14618 LACNIC Region origin ASes present in the Internet Routing Table: 1317 LACNIC Prefixes per ASN: 21.14 LACNIC Region origin ASes announcing only one prefix: 406 LACNIC Region transit ASes present in the Internet Routing Table: 232 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 26 Number of LACNIC addresses announced to Internet: 75899776 Equivalent to 4 /8s, 134 /16s and 35 /24s Percentage of available LACNIC address space announced: 56.5 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7377 Total AfriNIC prefixes after maximum aggregation: 1867 AfriNIC Deaggregation factor: 3.95 Prefixes being announced from the AfriNIC address blocks: 5682 Unique aggregates announced from the AfriNIC address blocks: 1606 AfriNIC Region origin ASes present in the Internet Routing Table: 384 AfriNIC Prefixes per ASN: 14.80 AfriNIC Region origin ASes announcing only one prefix: 119 AfriNIC Region transit ASes present in the Internet Routing Table: 88 Average AfriNIC Region AS path length visible: 3.7 Max AfriNIC Region AS path length visible: 14 Number of AfriNIC addresses announced to Internet: 19798016 Equivalent to 1 /8s, 46 /16s and 24 /24s Percentage of available AfriNIC address space announced: 59.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1856 8409 488 Korea Telecom (KIX) 4755 1477 298 164 TATA Communications formerly 7545 1371 234 87 TPG Internet Pty Ltd 17488 1343 151 126 Hathway IP Over Cable Interne 17974 1186 287 60 PT TELEKOMUNIKASI INDONESIA 9583 1003 74 486 Sify Limited 24560 994 305 183 Bharti Airtel Ltd., Telemedia 4808 833 1582 225 CNCGROUP IP network: China169 9829 817 686 33 BSNL National Internet Backbo 4134 784 21996 412 CHINANET-BACKBONE Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3881 3716 284 bellsouth.net, inc. 4323 2735 1116 397 Time Warner Telecom 19262 1947 4567 278 Verizon Global Networks 1785 1782 698 129 PaeTec Communications, Inc. 20115 1488 1522 653 Charter Communications 7018 1467 5733 953 AT&T WorldNet Services 2386 1286 554 908 AT&T Data Communications Serv 6478 1266 253 175 AT&T Worldnet Services 22773 1174 2858 61 Cox Communications, Inc. 11492 1160 209 90 Cable One Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 35805 654 56 6 United Telecom of Georgia 9198 499 202 13 Kazakhtelecom Data Network Ad 3292 448 2026 389 TDC Tele Danmark 30890 444 111 206 Evolva Telecom 702 412 1853 324 UUNET - Commercial IP service 8866 403 117 18 Bulgarian Telecommunication C 8551 401 353 46 Bezeq International 3320 375 7329 327 Deutsche Telekom AG 3301 372 1414 327 TeliaNet Sweden 34984 364 89 183 BILISIM TELEKOM Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1523 3048 247 UniNet S.A. de C.V. 10620 1072 240 149 TVCABLE BOGOTA 28573 1028 818 100 NET Servicos de Comunicao S.A 7303 775 396 104 Telecom Argentina Stet-France 6503 719 178 222 AVANTEL, S.A. 22047 555 310 15 VTR PUNTO NET S.A. 14420 537 34 74 CORPORACION NACIONAL DE TELEC 3816 494 210 90 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 448 99 76 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1177 445 10 TEDATA 24863 726 147 39 LINKdotNET AS number 36992 654 279 185 Etisalat MISR 3741 270 898 232 The Internet Solution 33776 220 12 12 Starcomms Nigeria Limited 2018 213 277 64 Tertiary Education Network 6713 195 186 16 Itissalat Al-MAGHRIB 29571 191 19 10 Ci Telecom Autonomous system 24835 189 78 9 RAYA Telecom - Egypt 16637 140 440 95 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3881 3716 284 bellsouth.net, inc. 4323 2735 1116 397 Time Warner Telecom 19262 1947 4567 278 Verizon Global Networks 4766 1856 8409 488 Korea Telecom (KIX) 1785 1782 698 129 PaeTec Communications, Inc. 8151 1523 3048 247 UniNet S.A. de C.V. 20115 1488 1522 653 Charter Communications 4755 1477 298 164 TATA Communications formerly 7018 1467 5733 953 AT&T WorldNet Services 7545 1371 234 87 TPG Internet Pty Ltd Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2735 2338 Time Warner Telecom 19262 1947 1669 Verizon Global Networks 1785 1782 1653 PaeTec Communications, Inc. 4766 1856 1368 Korea Telecom (KIX) 4755 1477 1313 TATA Communications formerly 7545 1371 1284 TPG Internet Pty Ltd 8151 1523 1276 UniNet S.A. de C.V. 17488 1343 1217 Hathway IP Over Cable Interne 8452 1177 1167 TEDATA 17974 1186 1126 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 16927 UNALLOCATED 12.0.252.0/23 7018 AT&T WorldNet Servic 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 7018 AT&T WorldNet Servic 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.152.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.154.0/23 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.155.0/24 7018 AT&T WorldNet Servic 26973 UNALLOCATED 12.39.159.0/24 7018 AT&T WorldNet Servic 25639 UNALLOCATED 12.41.169.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.38.240.0/21 33287 Comcast Cable Communications, 24.38.248.0/21 33287 Comcast Cable Communications, 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.188.0/24 22351 Intelsat 41.223.189.0/24 6453 Teleglobe Inc. 41.223.196.0/24 36990 Alkan Telecom Ltd Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:21 /9:10 /10:25 /11:67 /12:198 /13:410 /14:709 /15:1296 /16:11182 /17:5376 /18:9196 /19:18500 /20:23144 /21:23148 /22:30166 /23:29780 /24:170707 /25:1051 /26:1192 /27:740 /28:118 /29:47 /30:6 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2485 3881 bellsouth.net, inc. 4766 1486 1856 Korea Telecom (KIX) 4323 1398 2735 Time Warner Telecom 1785 1244 1782 PaeTec Communications, Inc. 17488 1085 1343 Hathway IP Over Cable Interne 11492 1069 1160 Cable One 18566 1069 1088 Covad Communications 8452 1066 1177 TEDATA 10620 988 1072 TVCABLE BOGOTA 19262 913 1947 Verizon Global Networks Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:37 2:2 4:13 8:292 12:2016 13:7 14:1 15:21 16:3 17:8 20:6 24:1436 27:271 31:1 32:59 33:12 38:688 40:98 41:2487 44:3 46:17 47:16 52:9 55:6 56:2 57:28 58:770 59:508 60:462 61:1068 62:1038 63:1969 64:3713 65:2346 66:4052 67:1826 68:1096 69:2724 70:712 71:444 72:1944 73:2 74:2282 75:254 76:324 77:900 78:620 79:428 80:996 81:779 82:494 83:450 84:682 85:1043 86:466 87:686 88:332 89:1558 90:96 91:2896 92:507 93:1009 94:1410 95:666 96:529 97:210 98:618 99:33 100:1 108:105 109:587 110:434 111:515 112:273 113:314 114:434 115:573 116:1059 117:649 118:483 119:881 120:136 121:724 122:1517 123:950 124:1115 125:1304 128:226 129:163 130:196 131:558 132:247 133:16 134:196 135:45 136:240 137:135 138:267 139:104 140:480 141:197 142:340 143:370 144:469 145:52 146:446 147:170 148:673 149:299 150:153 151:228 152:297 153:168 154:2 155:356 156:160 157:324 158:110 159:360 160:315 161:182 162:255 163:173 164:410 165:366 166:460 167:413 168:645 169:157 170:716 171:59 172:2 173:959 174:505 175:161 176:1 178:329 180:478 182:163 183:242 184:122 186:529 187:409 188:1040 189:773 190:3861 192:5746 193:4719 194:3405 195:2818 196:1183 198:3571 199:3496 200:5355 201:1578 202:7963 203:8284 204:4042 205:2404 206:2506 207:3077 208:3874 209:3465 210:2549 211:1289 212:1714 213:1655 214:647 215:69 216:4729 217:1527 218:500 219:378 220:1143 221:399 222:313 223:2 End of report From cidr-report at potaroo.net Fri Jul 30 17:00:06 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Jul 2010 22:00:06 GMT Subject: BGP Update Report Message-ID: <201007302200.o6UM06rJ019505@wattle.apnic.net> BGP Update Report Interval: 22-Jul-10 -to- 29-Jul-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4725 42987 2.5% 333.2 -- ODN SOFTBANK TELECOM Corp. 2 - AS25620 25906 1.5% 155.1 -- COTAS LTDA. 3 - AS30890 23547 1.4% 52.7 -- EVOLVA Evolva Telecom s.r.l. 4 - AS5536 17248 1.0% 155.4 -- Internet-Egypt 5 - AS4538 16596 1.0% 56.6 -- ERX-CERNET-BKB China Education and Research Network Center 6 - AS35805 13596 0.8% 20.7 -- SILKNET-AS SILKNET AS 7 - AS14420 13130 0.8% 24.1 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 8 - AS35931 12653 0.7% 2108.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - AS8452 12390 0.7% 10.5 -- TEDATA TEDATA 10 - AS6389 12249 0.7% 3.1 -- BELLSOUTH-NET-BLK - BellSouth.net Inc. 11 - AS16526 11337 0.7% 68.7 -- BIRCH-TELECOM - Birch Telecom, Inc. 12 - AS9829 11077 0.7% 13.6 -- BSNL-NIB National Internet Backbone 13 - AS48754 10172 0.6% 10172.0 -- SOBIS-AS SOBIS SOLUTIONS SRL 14 - AS4323 9027 0.5% 3.2 -- TWTC - tw telecom holdings, inc. 15 - AS8151 8956 0.5% 5.8 -- Uninet S.A. de C.V. 16 - AS45464 8700 0.5% 202.3 -- NEXTWEB-AS-AP Room 201, TGU Bldg 17 - AS3816 8541 0.5% 16.6 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 18 - AS11492 8475 0.5% 7.2 -- CABLEONE - CABLE ONE, INC. 19 - AS5800 8120 0.5% 40.4 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - AS210 8069 0.5% 7.2 -- WEST-NET-WEST - Utah Education Network TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48754 10172 0.6% 10172.0 -- SOBIS-AS SOBIS SOLUTIONS SRL 2 - AS19174 5197 0.3% 5197.0 -- CNC-USA - China Netcom (USA) Operations Ltd. 3 - AS25090 2415 0.1% 2415.0 -- EOS-AS Energie Ouest Suisse Autonomous System 4 - AS35931 12653 0.7% 2108.8 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS23670 1757 0.1% 1757.0 -- OZSERVERS-AU Oz Servers, Data Centres, Australia Wide 6 - AS29843 6886 0.4% 1147.7 -- FIVEA-AS1 - FIVE AREA SYSTEMS, INC 7 - AS8792 893 0.1% 893.0 -- ASVNET Axel Springer Verlag AG 8 - AS11613 748 0.0% 748.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 9 - AS32528 5369 0.3% 671.1 -- ABBOTT Abbot Labs 10 - AS30600 1988 0.1% 497.0 -- AS-CMN - Cinergy Metronet, Inc. 11 - AS47593 402 0.0% 402.0 -- ATELECOM A-Telcom Ltd 12 - AS38467 394 0.0% 394.0 -- DBAMOYLAN-TRANSIT-AS-AP DBA Moylan 13 - AS44630 389 0.0% 389.0 -- A1799-AS A1799 Military Unit 14 - AS7513 381 0.0% 381.0 -- NETFORWARD Hitachi Information Systems, Ltd. 15 - AS7677 379 0.0% 379.0 -- DNP Dai Nippon Printing Co., Ltd 16 - AS7517 754 0.0% 377.0 -- MII ICOMT Inc. 17 - AS48275 374 0.0% 374.0 -- TSMS-ABKHAZIA-AS Technical Service of Trunk Communications of UPI and SMK of the President of Republic of Abkhazia 18 - AS9352 1080 0.1% 360.0 -- KUMAGAYA KuMaGaYaNet 19 - AS38063 359 0.0% 359.0 -- SANMEDIA-AS SANMEDIA Corporation, Local ISP in JAPAN YONAGO 20 - AS24289 1795 0.1% 359.0 -- KBN Kagawa T.V Broadcast Network Co,.Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 91.212.23.0/24 10172 0.5% AS48754 -- SOBIS-AS SOBIS SOLUTIONS SRL 2 - 198.140.43.0/24 6980 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - 190.65.228.0/22 6027 0.3% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 4 - 63.211.68.0/22 5647 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 207.254.176.0/20 5197 0.2% AS19174 -- CNC-USA - China Netcom (USA) Operations Ltd. 6 - 41.34.29.0/24 4202 0.2% AS8452 -- TEDATA TEDATA 7 - 206.184.16.0/24 3146 0.1% AS174 -- COGENT Cogent/PSI 8 - 130.36.34.0/24 2600 0.1% AS32528 -- ABBOTT Abbot Labs 9 - 130.36.35.0/24 2598 0.1% AS32528 -- ABBOTT Abbot Labs 10 - 202.92.235.0/24 2440 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 11 - 193.8.222.0/24 2415 0.1% AS25090 -- EOS-AS Energie Ouest Suisse Autonomous System 12 - 129.66.0.0/17 1918 0.1% AS3464 -- ASC-NET - Alabama Supercomputer Network 13 - 129.66.128.0/17 1913 0.1% AS3464 -- ASC-NET - Alabama Supercomputer Network 14 - 117.20.0.0/24 1757 0.1% AS23670 -- OZSERVERS-AU Oz Servers, Data Centres, Australia Wide 15 - 143.138.107.0/24 1590 0.1% AS747 -- TAEGU-AS - Headquarters, USAISC 16 - 63.99.80.0/21 1377 0.1% AS29843 -- FIVEA-AS1 - FIVE AREA SYSTEMS, INC 17 - 63.99.88.0/22 1377 0.1% AS29843 -- FIVEA-AS1 - FIVE AREA SYSTEMS, INC 18 - 65.216.40.0/21 1377 0.1% AS29843 -- FIVEA-AS1 - FIVE AREA SYSTEMS, INC 19 - 63.96.42.0/23 1377 0.1% AS29843 -- FIVEA-AS1 - FIVE AREA SYSTEMS, INC 20 - 216.229.112.0/20 1377 0.1% AS29843 -- FIVEA-AS1 - FIVE AREA SYSTEMS, INC Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Jul 30 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 30 Jul 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201007302200.o6UM003A019455@wattle.apnic.net> This report has been generated at Fri Jul 30 21:11:44 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 23-07-10 329517 203177 24-07-10 330008 203237 25-07-10 329997 203298 26-07-10 329978 203486 27-07-10 330171 203377 28-07-10 330486 203379 29-07-10 330636 203594 30-07-10 330809 203570 AS Summary 34995 Number of ASes in routing system 14852 Number of ASes announcing only one prefix 4490 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 95297344 Largest address span announced by an AS (/32s) AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street Aggregation Summary The algorithm used in this report proposes aggregation only when there is a precise match using the AS path, so as to preserve traffic transit policies. Aggregation is also proposed across non-advertised address space ('holes'). --- 30Jul10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 330870 203434 127436 38.5% All ASes AS6389 3881 289 3592 92.6% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4490 1833 2657 59.2% TWTC - tw telecom holdings, inc. AS19262 1948 279 1669 85.7% VZGNI-TRANSIT - Verizon Internet Services Inc. AS4766 1856 502 1354 73.0% KIXS-AS-KR Korea Telecom AS22773 1174 66 1108 94.4% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1477 401 1076 72.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS18566 1088 63 1025 94.2% COVAD - Covad Communications Co. AS17488 1343 320 1023 76.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS5668 1098 85 1013 92.3% AS-5668 - CenturyTel Internet Holdings, Inc. AS8151 1455 554 901 61.9% Uninet S.A. de C.V. AS6478 1266 391 875 69.1% ATT-INTERNET3 - AT&T WorldNet Services AS10620 1077 295 782 72.6% Telmex Colombia S.A. AS8452 1177 402 775 65.8% TEDATA TEDATA AS7545 1389 710 679 48.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 775 121 654 84.4% Telecom Argentina S.A. AS4804 682 72 610 89.4% MPX-AS Microplex PTY LTD AS35805 654 55 599 91.6% SILKNET-AS SILKNET AS AS4808 833 248 585 70.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4780 694 161 533 76.8% SEEDNET Digital United Inc. AS7552 653 137 516 79.0% VIETEL-AS-AP Vietel Corporation AS7018 1467 955 512 34.9% ATT-INTERNET4 - AT&T WorldNet Services AS17676 581 80 501 86.2% GIGAINFRA Softbank BB Corp. AS24560 994 493 501 50.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS1785 1782 1282 500 28.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS3356 1161 664 497 42.8% LEVEL3 Level 3 Communications AS9443 572 76 496 86.7% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 1135 653 482 42.5% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 555 83 472 85.0% VTR BANDA ANCHA S.A. AS9198 499 40 459 92.0% KAZTELECOM-AS JSC Kazakhtelecom AS7738 477 30 447 93.7% Telecomunicacoes da Bahia S.A. Total 38233 11340 26893 70.3% Top 30 total Possible Bogus Routes 24.38.240.0/21 AS33287 COMCAST-33287 - Comcast Cable Communications, Inc. 24.38.248.0/21 AS33287 COMCAST-33287 - Comcast Cable Communications, Inc. 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.188.0/24 AS22351 INTELSAT Intelsat Global BGP Routing Policy 41.223.189.0/24 AS6453 GLOBEINTERNET TATA Communications 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.82.128.0/19 AS16617 COMMUNITYISP - CISP 64.82.160.0/19 AS16617 COMMUNITYISP - CISP 66.128.38.0/24 AS15246 Telecomunicaciones Satelitales Telesat S.A. 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.241.112.0/20 AS21547 REVNETS - Revolution Networks 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 69.6.80.0/24 AS13442 69.6.81.0/24 AS13442 69.80.224.0/19 AS19166 ACRONOC - ACRONOC INC 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 100.100.100.0/24 AS3549 GBLX Global Crossing Ltd. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 110.173.64.0/19 AS37963 CNNIC-ALIBABA-CN-NET-AP Alibaba (China) Technology Co., Ltd. 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 158.222.70.0/23 AS6137 SISNA - SISNA, Inc. 158.222.72.0/23 AS6137 SISNA - SISNA, Inc. 158.222.224.0/20 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.224.0/22 AS19864 O1COMM - O1 COMMUNICATIONS 158.222.229.0/24 AS19864 O1COMM - O1 COMMUNICATIONS 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 181.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 190.104.32.0/21 AS27882 Telef?nica Celular de Bolivia S.A. 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.70.164.0/24 AS25689 NRCNET-AS - National Research Council of Canada 192.101.46.0/24 AS6503 Axtel, S.A.B. de C. V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.51.93.0/24 AS10435 IDCOMM - ID COMMUNICATIONS 198.51.94.0/24 AS10435 IDCOMM - ID COMMUNICATIONS 198.51.100.0/24 AS16953 ASCENT-MEDIA-GROUP-LLC - Ascent Media Group, LLC 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.135.236.0/24 AS4358 XNET - XNet Information Systems, Inc. 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.72.224.0/21 AS24013 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.80.192.0/20 AS2706 PI-HK Pacnet Internet (Hong Kong) Limited 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS Wind International Services SA 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.9.218.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.197.0.0/16 AS3356 LEVEL3 Level 3 Communications 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.194.0/23 AS27375 IDS-TELECOM - IDS Telecom 206.72.196.0/23 AS7018 ATT-INTERNET4 - AT&T WorldNet Services 206.72.208.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.209.0/24 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.123.129.0/24 AS10790 INREACH-AS - InReach Internet 206.180.240.0/20 AS12083 KNOLOGY-NET - Knology Holdings 206.197.184.0/24 AS23304 DATOTEL-STL-AS - Datotel LLC, a NetLabs LLC Company 207.174.131.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.132.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.152.0/23 AS26116 INDRA - Indra's Net Inc. 207.174.154.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.155.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.188.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.189.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.190.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.191.0/24 AS26116 INDRA - Indra's Net Inc. 207.174.200.0/24 AS22658 EARTHNET - Earthnet, Inc. 207.174.248.0/21 AS6653 PRIVATEI - privateI, LLC 207.231.96.0/19 AS11194 NUNETPA - NuNet Inc. 208.73.4.0/22 AS27630 PREMIER - Premier Innovations, LLC 208.78.164.0/24 AS16565 208.78.165.0/24 AS16565 208.78.167.0/24 AS16565 208.84.76.0/22 AS18561 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.213.0.0/20 AS33005 ELTOPIA - Eltopia.com, LLC 209.213.1.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 209.213.4.0/24 AS7849 CROCKERCOM - CROCKER COMMUNICATIONS 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com 223.223.216.0/24 AS24549 SPEEDVPS-AS-AP Pacificnet Hosting Ltd Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From diogo.montagner at gmail.com Fri Jul 30 21:04:16 2010 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Sat, 31 Jul 2010 10:04:16 +0800 Subject: Monitoring tools for IPv6 tools In-Reply-To: <20100730080758.1229D090@resin06.mta.everyone.net> References: <20100730080758.1229D090@resin06.mta.everyone.net> Message-ID: Hi, thanks for the link. This was the best compilation that I found before. Unfortunately, this presentation is a little bit old (2006). I am supposing that most of commercial tools have improved your IPv6 support. Thanks ./diogo -montagner On Fri, Jul 30, 2010 at 11:07 PM, nanogf . wrote: > https://docs.google.com/viewer?url=http://www.6diss.org/tutorials/management.pdf > > > http://tools.6net.org/ > > > --- diogo.montagner at gmail.com wrote: > > From: Diogo Montagner > To: nanog at nanog.org > Subject: Monitoring tools for IPv6 tools > Date: Fri, 30 Jul 2010 17:06:31 +0800 > > Hello, > > I am looking for monitoring tools that already have support to IPv6. I > am looking for both freeware and commercial tools. > > Please, do you know what network management system are already > supporting IPv6 ? > > Thanks > ./diogo -montagner > > > > > > _____________________________________________________________ > Get your own *free* email address like this one from www.OwnEmail.com > From Valdis.Kletnieks at vt.edu Sat Jul 31 02:20:20 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 31 Jul 2010 03:20:20 -0400 Subject: Monitoring tools for IPv6 tools In-Reply-To: Your message of "Sat, 31 Jul 2010 10:04:16 +0800." References: <20100730080758.1229D090@resin06.mta.everyone.net> Message-ID: <49325.1280560820@localhost> On Sat, 31 Jul 2010 10:04:16 +0800, Diogo Montagner said: > This was the best compilation that I found before. Unfortunately, this > presentation is a little bit old (2006). I am supposing that most of > commercial tools have improved your IPv6 support. Dunno. Were the customers pressuring the vendors to improve the IPv6 support, or were they letting it slide because they didn't plan to deploy IPv6 till 2012 or so? ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From sethm at rollernet.us Sat Jul 31 12:57:45 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 31 Jul 2010 10:57:45 -0700 Subject: Monitoring tools for IPv6 tools In-Reply-To: <49325.1280560820@localhost> References: <20100730080758.1229D090@resin06.mta.everyone.net> <49325.1280560820@localhost> Message-ID: <4C546419.2070307@rollernet.us> On 7/31/10 12:20 AM, Valdis.Kletnieks at vt.edu wrote: > On Sat, 31 Jul 2010 10:04:16 +0800, Diogo Montagner said: >> This was the best compilation that I found before. Unfortunately, this >> presentation is a little bit old (2006). I am supposing that most of >> commercial tools have improved your IPv6 support. > > Dunno. Were the customers pressuring the vendors to improve the IPv6 support, > or were they letting it slide because they didn't plan to deploy IPv6 till 2012 > or so? ;) > Personally, I stopped pressuring vendors that didn't support IPv6, preferring to drop the completely and pick up one with equal or better service who did. Sometimes this was easy, sometimes it was exceedingly difficult. In every case when they asked why I said it was the lack of IPv6 support because I've been running a dual stack network for years, not as part of some future plan. ~Seth From cb.list6 at gmail.com Sat Jul 31 16:46:30 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sat, 31 Jul 2010 14:46:30 -0700 Subject: T-Mobile IPv6 Beta Message-ID: Folks, T-Mobile USA has launched an IPv6 beta service and we are interested in recruiting some friendly users as part of this trial service. Right now, the service is only for T-Mobile USA subscribers in T-Mobile USA coverage (no roaming) and only Nokia phones are supported. For more info and discussion, please visit our group page http://groups.google.com/group/tmoipv6beta Thanks, Cameron From jabley at hopcount.ca Sat Jul 31 16:46:40 2010 From: jabley at hopcount.ca (Joe Abley) Date: Sat, 31 Jul 2010 23:46:40 +0200 Subject: Web expert on his 'catastrophe' key for the internet In-Reply-To: <334BF2E6-47AE-44A7-8676-C7A8284398DD@americafree.tv> References: <50986CDE-E517-48CA-A3FC-FD3D3DC3049D@hopcount.ca> <29068462.194.1280460152569.JavaMail.franck@franck-martins-macbook-pro.local> <334BF2E6-47AE-44A7-8676-C7A8284398DD@americafree.tv> Message-ID: <21C92BB3-686B-49CA-B485-D82392286B2B@hopcount.ca> On 2010-07-30, at 07:59, Marshall Eubanks wrote: > Hmm. Looks like an RFC, but isn't. Do you know if there are any plans to actually publish this ? The authoritative and current ICANN DPS is published here: https://www.iana.org/dnssec/ My understanding is that the current copyright and the source of some of the derivative text in that document means it cannot be published as-is as an RFC, assuming that's what you meant. My understanding may be weak however, and anybody who happens to be expert in copyright as it applies to the RFC series should feel very free to drop me a private note, if they feel an urge to educate me. For completeness, the corresponding DPS from VeriSign can be found here: https://www.verisign.com/repository/dnssec-practice-statement-root-zone-zsk-operator.pdf Together the two documents describe the whole system. Joe From netfortius at gmail.com Sat Jul 31 20:37:22 2010 From: netfortius at gmail.com (Stefan) Date: Sat, 31 Jul 2010 20:37:22 -0500 Subject: T-Mobile IPv6 Beta In-Reply-To: References: Message-ID: Nokia N900: http://n900-ipv6.garage.maemo.org/ - worth giving it a shot ... ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius On Sat, Jul 31, 2010 at 4:46 PM, Cameron Byrne wrote: > Folks, > > T-Mobile USA has launched an IPv6 beta service and we are interested > in recruiting some friendly users as part of this trial service. > Right now, the service is only for T-Mobile USA subscribers in > T-Mobile USA coverage (no roaming) and only Nokia phones are > supported. > > For more info and discussion, please visit our group page > > http://groups.google.com/group/tmoipv6beta > > Thanks, > > Cameron > >