From gbonser at seven.com Tue Mar 1 00:56:14 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 28 Feb 2011 22:56:14 -0800 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP><20862_1298182779_p1K6JX2d011053_93717E08238F7B4392FAD1F82A87FBD3365F49A9@SAT2EXD02.RACKSPACE.CORP><5A6D953473350C4B9995546AFE9939EE0BC13C5D@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC13E29@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13E2F@RWC-EX1.corp.seven.com> > > It was updated last year -- apparently handled in HW now. > > 24 ports of 10GE, routing, GRE, and small form-factor = everything the > original inquiry listed. > > FYI, > -Jeff No, not for TurboIron. FESX, FSX, and SX only in that line of code. It is a little confusing because the TurboIron uses the same configuration manual as the other ones I just listed, you have to look closely at the GRE section (search the doc for 2784 should put you in the right neighborhood). You will notice that the TurboIron is not mentioned. I also looked at the release notes up to 4.2.00c and nothing for GRE on TIX24, in fact, it won't even do PMTUD. IPv4 point-to-point GRE tunnels Platform Support: FESX, FSX and SX IPv6 devices running software release FSX 05.1.00 and later This section describes support for point-to-point Generic Routing Encapsulation (GRE) tunnels and how to configure them on a Brocade device. GRE tunnels support includes, but is not limited to, the following: * IPv4 over GRE tunnels. IPv6 over GRE tunnels is not supported. * Static and dynamic unicast routing over GRE tunnels * Multicast routing over GRE tunnels * Hardware forwarding of IP data traffic across a GRE tunnel. * Path MTU Discovery (PMTUD) In fact, if you go to Appendix B (RFC Support) on page 1768 there is a support matrix, you see under RFC 2784 Generic Routing Encapsulation go across to the TIX column and there is a big fat "NO" there. Looking at all the release notes in subsequent minor releases shows no GRE for TIX24 Maybe you have access to a version of code that isn't in GA yet. From jsw at inconcepts.biz Tue Mar 1 01:22:51 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Tue, 1 Mar 2011 02:22:51 -0500 Subject: What vexes VoIP users? In-Reply-To: References: <12254284.370.1298934926996.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, Feb 28, 2011 at 6:28 PM, Leigh Porter wrote: > Exactly the point I made earlier. POTS is simple, it does what it does and it is pretty good at it. Now, in the background, you have a whole lot of engineering. But I would trust a DMS100 far more than any of the stuff that routes IP. > > POTS is cheap, easy, scalable and resistant to many disasters that would soon wipe any VoIP network out. I wouldn't call DMS100 a "cheap" platform. The switch gear is expensive, features are expensive, floor space is expensive, training is expensive, and provisioning, for the most part, is stuck in the dark ages. Sure, it works, but to make the generalization that it's cheaper than modern VoIP switching is just incorrect. Besides that, if you have done much DMS100 ops, you are well aware that there are many (infrequent) tasks that require multi-hour outages of major DMS100 components, e.g. one of the two CMs (control plane, for unfamiliar readers.) In addition, the official maintenance procedures often don't tell you how to perform these tasks without taking the whole switch out of service. A growing number of end-users are perfectly happy with no land-line and no VoIP, relying only on cellular phone service. I'm sure that cellular is generally orders of magnitude less reliable than POTS. I'm sure most VoIP offerings are somewhere in-between. End-users are going to choose the product they want, and for many, the choice will be to save hundreds of dollars per year while sacrificing a little bit of reliability which they are unlikely to notice or miss. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From owen at delong.com Tue Mar 1 01:34:27 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 23:34:27 -0800 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <99B7A9A2-EBA4-48DB-AB72-D8A157BE1667@internode.com.au> References: <4D69DDD2.8050903@bogus.com> <4D69E529.5090109@bogus.com> <20110227140321.GM9424@angus.ind.WPI.EDU> <72B7B4EA-0E25-4D31-B9A1-653308E4D675@arbor.net> <071A89DA-A414-4DCC-BC47-3C86AB67EFE0@cs.columbia.edu> <70835095-819D-419A-830E-2B6ECCFE3102@cs.columbia.edu> <4D6BA5DD.2050504@freedesktop.org> <35826B01-F1D5-48CF-809E-FEC7329D1231@arbor.net> <4D6BB5C7.8050009@utc.edu> <99B7A9A2-EBA4-48DB-AB72-D8A157BE1667@internode.com.au> Message-ID: <4A328308-6CCE-474B-839E-69BA001E9C9B@delong.com> On Feb 28, 2011, at 9:23 PM, Mark Newton wrote: > > On 01/03/2011, at 1:23 AM, Brian Johnson wrote: > >> Can someone explain what exactly the security threat is? > > > If I see two IPv6 addresses which share the same 64 bit suffix, > I can be reasonably certain that they both correspond to the same > device because they'll both be generated by the same MAC address. > > Your IPv6 address has thereby become a token I can use to track > your whereabouts, which is the kind of thing that privacy advocates > often find upsetting. > Correct. > RFC4941 should be (but generally isn't) enabled by default. > Incorrect. > Having said that, implementation of RFC4941 is lossy. On MacOS, > long-held TCP sessions time-out when a new privacy suffix is > generated and the old one ages out. I'd have thought that a > better outcome would be for old addresses to continue working > until their refcount drops to zero. > I'm not sure addresses maintain a refcount in that way and it might not be so easy for the thing cleaning the address off the interface to find the open connections at the time. Also, since this probably happens in protected sections of the kernel, you probably want it to happen pretty quickly and adding baggage is anathema to speed. > > The new attack vector which SLAAC with EUI64 creates is one of > "trackability." I can't passively accumulate IPv4 logs which tell me > which ISPs you've used, which cities you're in, which WiFi hotspots > you've used, which companies you've worked at, which websites you've > visited, etc. > True, you have to use a cookie or a Javascript that reports the Mac Address to do that. :p > I can accumulate logs which tell me which IP addresses have done those > things, but I can't (for example) correlate them to your personal > smartphone. > Unless... > I can with IPv6. > More accurate to say "It's easier with IPv6 and SLAAC." > That's new, and (to my mind) threatening. We've not even begun to > consider the attack vectors that'll open up. > It's not new. It's not all that threatening. It's just easier. We've begun to consider it. That's why paranoid people do things like turning off cookies. I suspect you probably think browsers should ship with a default of "don't accept cookies", too. Privacy addresses create quite a bit of ugliness and are a miscreants wet dream. They're a MAC forwarding table DOS looking for a place to happen. They're probably a necessary evil for a limited subgroup of users, but, not something which should, generally, be enabled by default. Of course, because that's the case, Micr0$0ft has seen fit to do exactly that. Owen From owen at delong.com Tue Mar 1 01:48:18 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Feb 2011 23:48:18 -0800 Subject: What vexes VoIP users? In-Reply-To: References: <12254284.370.1298934926996.JavaMail.root@benjamin.baylink.com> Message-ID: <467402F7-EADB-4765-B50D-B914C1762E05@delong.com> On Feb 28, 2011, at 11:22 PM, Jeff Wheeler wrote: > On Mon, Feb 28, 2011 at 6:28 PM, Leigh Porter > wrote: >> Exactly the point I made earlier. POTS is simple, it does what it does and it is pretty good at it. Now, in the background, you have a whole lot of engineering. But I would trust a DMS100 far more than any of the stuff that routes IP. >> >> POTS is cheap, easy, scalable and resistant to many disasters that would soon wipe any VoIP network out. > > I wouldn't call DMS100 a "cheap" platform. The switch gear is > expensive, features are expensive, floor space is expensive, training > is expensive, and provisioning, for the most part, is stuck in the > dark ages. > Per subscriber, amortized over the likely 20-30 year lifetime of a DMS-100, compared to VOIP gear, rapid product life cycling, and low subscriber density, uh, yeah, the DMS-100 is, actually cheap in many cases. > Sure, it works, but to make the generalization that it's cheaper than > modern VoIP switching is just incorrect. Besides that, if you have > done much DMS100 ops, you are well aware that there are many > (infrequent) tasks that require multi-hour outages of major DMS100 > components, e.g. one of the two CMs (control plane, for unfamiliar > readers.) In addition, the official maintenance procedures often > don't tell you how to perform these tasks without taking the whole > switch out of service. > VOIP is just starting to get cheaper than POTS, but, barely. As to the reliability issue, you're technically correct, but, there is actually a very strong emotional connection for many end users of "I want my phone to work to call 911 when the lights are out." Cellular, in spite of its reliability issues is perceived to provide that. POTS is perceived to provide that and it's pretty rock solid. VOIP is perceived to have that as a severe limitation. Owen From tim at pelican.org Tue Mar 1 03:25:23 2011 From: tim at pelican.org (Tim Franklin) Date: Tue, 1 Mar 2011 09:25:23 +0000 (GMT) Subject: What vexes VoIP users? In-Reply-To: Message-ID: <4952321.01298971523361.JavaMail.root@jennyfur.pelican.org> > I do not live over there, I have never seen a Vonage or Magic jack or > any other VoIP service ad on TV in the UK, ever. Vonage *are* advertising on UK TV. Hardly the carpet-bombing the OP suggests is the case in the US, but they are doing something. > It is quite a different market here. I can get POTS services over the > same copper from, I'd say, about 5 different companies. Maybe more, I > have not counted. I guess the competition already available on the > copper would largely preclude anything but the cheapest VoIP service. For UK national calls, which pretty much all the POTS providers are offering for "free" (read "bundled"), I tend to agree - especially given that the POTS providers who *aren't* BT (Residential) are largely having to lease at least the last mile copper from BT (OpenReach). The Vonage TV ads that I've seen in the UK are pitched at offering cheap / free / bundled international calls, and the target market for that I believe is both different and smaller. Regards, Tim. From nenolod at systeminplace.net Tue Mar 1 03:32:31 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Tue, 1 Mar 2011 03:32:31 -0600 Subject: What vexes VoIP users? In-Reply-To: <4952321.01298971523361.JavaMail.root@jennyfur.pelican.org> References: <4952321.01298971523361.JavaMail.root@jennyfur.pelican.org> Message-ID: <20110301033231.203521fc@petrie> Hi, On Tue, 1 Mar 2011 09:25:23 +0000 (GMT) Tim Franklin wrote: > > I do not live over there, I have never seen a Vonage or Magic jack > > or any other VoIP service ad on TV in the UK, ever. > > Vonage *are* advertising on UK TV. Hardly the carpet-bombing the OP > suggests is the case in the US, but they are doing something. > > > It is quite a different market here. I can get POTS services over > > the same copper from, I'd say, about 5 different companies. Maybe > > more, I have not counted. I guess the competition already available > > on the copper would largely preclude anything but the cheapest VoIP > > service. > > For UK national calls, which pretty much all the POTS providers are > offering for "free" (read "bundled"), I tend to agree - especially > given that the POTS providers who *aren't* BT (Residential) are > largely having to lease at least the last mile copper from BT > (OpenReach). The Vonage TV ads that I've seen in the UK are pitched > at offering cheap / free / bundled international calls, and the > target market for that I believe is both different and smaller. That is the same market Vonage is now targeting in the US, basically. National calling in the US is basically bundled with most calling plans now. I'm not convinced that many people use Vonage in the US - my experience with it was that it was not as reliable as the VOIP products offered through the various broadband providers I have had. William From nick at foobar.org Tue Mar 1 05:12:53 2011 From: nick at foobar.org (Nick Hilliard) Date: Tue, 01 Mar 2011 11:12:53 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <4D6C74FC.1000707@bogus.com> References: <8951E87B-D779-469E-BE3B-6DCC8089034E@delong.com> <27343021.942.1298868810899.JavaMail.franck@franck-martins-macbook-pro.local> <4D6BB65B.8050309@foobar.org> <4D6C74FC.1000707@bogus.com> Message-ID: <4D6CD4B5.6080406@foobar.org> On 01/03/2011 04:24, Joel Jaeggli wrote: > Oddly enough the meeting NOC is in the business of providing services to > customers and we generally assume that to be with the highest > availability and minimum breakage feasible under the circumstances... That is exactly my point. [...] > I am mystified. Don't be mystified. I'm just frustrated that ipv6 isn't further down the line in terms of basic plug-n-play functionality. And it's easier to create straw men arguments and hurl blame at the IETF / vendors / everyone else than sit down and try to work through the problems. I'm human. So yes, I'm fully aware that the straw man of suggesting that ipv4 be disabled at an ietf meeting would cause breakage for reasons unrelated to the ra/dhcp mess, and more to do with lack of endpoint availability / operating system problems / etc (all unrelated to the ietf). However, that doesn't mean that I feel less frustrated that mistakes of the past are coming back to haunt us. Nick From leigh.porter at ukbroadband.com Tue Mar 1 05:38:28 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 1 Mar 2011 11:38:28 +0000 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <18886_1298039457_p1IEUpvU024871_93717E08238F7B4392FAD1F82A87FBD3365F2E87@SAT2EXD02.RACKSPACE.CORP> <20862_1298182779_p1K6JX2d011053_93717E08238F7B4392FAD1F82A87FBD3365F49A9@SAT2EXD02.RACKSPACE.CORP> <5A6D953473350C4B9995546AFE9939EE0BC13C5D@RWC-EX1.corp.seven.com> Message-ID: Juniper MX80 does all this. On 1 Mar 2011, at 01:07, "Jeff Hartley" wrote: > On Sun, Feb 20, 2011 at 3:15 PM, George Bonser wrote: >>> On 2/18/11 6:30 AM, "Matt Newsom" wrote: >>> >>>> I am looking for a switch with a minimum of 12 X >> 10GE >>>> ports on it, that can has routing protocol support and can do GRE in >>>> hardware. Does anyone have a suggestion that might fit. Keep in mind >> I >>> am >>>> looking for something in the 1-2U range and not a chassis. >>>> >>>> >> >> Hard to tell from the data sheet: >> >> http://www.xbridgeservices.com/images/files/7450_ess.pdf >> >> But it looks like the Alcatel-Lucent 7450 ESS-1 might do it. Not sure >> if it has 4, 8, or 12 10G ports, though. The data sheet is confusing to >> me and it would be oversubscribed but that might be OK in your >> applications. >> >> >> >> > > > Brocade TurboIron 24X fits all of those criteria. > > -Jeff > From sthaug at nethelp.no Tue Mar 1 05:44:23 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Tue, 01 Mar 2011 12:44:23 +0100 (CET) Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13C5D@RWC-EX1.corp.seven.com> Message-ID: <20110301.124423.74661930.sthaug@nethelp.no> > Juniper MX80 does all this. 1. It's not a switch (so don't expect "switch pricing"). 2. It doesn't offer 12 x 10GE ports. And I believe this has been mentioned earlier in the same thread... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jra at baylink.com Tue Mar 1 07:51:51 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 1 Mar 2011 08:51:51 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <20110301033231.203521fc@petrie> Message-ID: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "William Pitcock" > That is the same market Vonage is now targeting in the US, basically. > National calling in the US is basically bundled with most calling plans > now. I'm not convinced that many people use Vonage in the US - my > experience with it was that it was not as reliable as the VOIP > products offered through the various broadband providers I have had. Let us be clear: if you're getting "digital telephone" service from a cable television provider, it is *not* "VoIP", in the usage in which most speakers mean that term -- "Voice Over Internet" is what they should be saying, and cable-phone isn't that; the voice traffic rides over a separate DOCSiS channel, protected from both the Internet and CATV traffic on the link. So of course Vonage and other VoN products will be less rugged. As I recall, this questionably fair competitive advantage has been looked into by ... someone. (Cablecos won't permit competing VoIP services to utilize this protected channel, somewhere between "generally" and "ever".) Cheers, -- jra From khelms at ispalliance.net Tue Mar 1 08:34:42 2011 From: khelms at ispalliance.net (Scott Helms) Date: Tue, 01 Mar 2011 09:34:42 -0500 Subject: What vexes VoIP users? In-Reply-To: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6D0402.7020404@ispalliance.net> offered through the various broadband providers I have had. > Let us be clear: if you're getting "digital telephone" service from a > cable television provider, it is *not* "VoIP", in the usage in which > most speakers mean that term -- "Voice Over Internet" is what they should > be saying, and cable-phone isn't that; the voice traffic rides over a > separate DOCSiS channel, protected from both the Internet and CATV > traffic on the link. > No, this incorrect. Packet Cable most certainly _is_ VOIP (a MGCP variant to be precise until 2.0 after which it is SIP). While a few providers, usually for non-technical reasons, did deploy an entirely separate set of downstream and upstream interfaces that is far from the norm. AFAIK the only top 20 MSO to do so in scale was Charter and I don't know if they continue that today. Comcast, the largest cable telephone provider certainly does not nor do providers need to since any Packetcable CMTS and EMTA combo offers reliable prioritization in the same channel(s) as the normal data path. > So of course Vonage and other VoN products will be less rugged. > > As I recall, this questionably fair competitive advantage has been > looked into by ... someone. (Cablecos won't permit competing VoIP > services to utilize this protected channel, somewhere between "generally" > and "ever".) As I said, this second channel doesn't exist in almost all cases (its not cost effective nor needed in almost all cases). Having said that over the top VOIP providers do suffer in comparison because they don't get the benefit of prioritization in the local cable plant. > Cheers, > -- jra > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at ispalliance.net Tue Mar 1 08:44:36 2011 From: khelms at ispalliance.net (Scott Helms) Date: Tue, 01 Mar 2011 09:44:36 -0500 Subject: What vexes VoIP users? In-Reply-To: <201102282335.p1SNZNDZ065306@aurora.sol.net> References: <201102282335.p1SNZNDZ065306@aurora.sol.net> Message-ID: <4D6D0654.60203@ispalliance.net> > > There may be no compelling reason to do so, at least. However, digital > gear offers benefits, and some people want them. Others, like me, live > in bad RF environments where POTS picks up too much noise unless you > very carefully select your gear and shield your cables. Further, the > digital phones support other features, such as the ability to manage > multiple calls seamlessly, present Caller-ID reliably (even while you > are on another call), etc. If you have issues with your wiring as bad as you describe then your problem is with your in home wiring and possibly the wiring in your area. Twisted pair inherently resists the kinds ingress your describing if its properly installed and maintained. Of course this has nothing to do with digital communications since any communication over your wiring will be problematic. > I hate to tell *you*, but the LEC's and cable companies like to hand > off POTS to small businesses too. Of course they do, but the discussion was specifically about residential users. In the case of enterprise users there are lots of choices ranging from "virtual" PBXs to local PBXs with proprietary digital phones. > Your argument: "This works fine for most people therefore it will > work for everyone." Is that really what you're saying? No, I asked what will make consumers choose digital connections today for residential service rather than re-using their existing hand sets. >> What's broken for a residential user? > That depends. I've got many years of experience with POTS. That's nice, but your experience doesn't track with what the market has done. You describe specific wiring related problems as if they are endemic to in home wiring and that's simply not true nor does a "digital" hand set magically fix them if they are there. If anything when a user has that many issues with in home wiring the lowest cost solution is usually to install a wireless set, not because its "better" but because its cheaper than fixing the in home wiring in many/most cases for operators. > > That's a matter of the consumer and their needs and wants. > The market has very definitively answered this question so far which is what confuses me about your argument. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From mike at mtcc.com Tue Mar 1 08:53:49 2011 From: mike at mtcc.com (Michael Thomas) Date: Tue, 01 Mar 2011 06:53:49 -0800 Subject: What vexes VoIP users? In-Reply-To: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6D087D.1020005@mtcc.com> On 03/01/2011 05:51 AM, Jay Ashworth wrote: > ----- Original Message ----- > >> From: "William Pitcock" >> > >> That is the same market Vonage is now targeting in the US, basically. >> National calling in the US is basically bundled with most calling plans >> now. I'm not convinced that many people use Vonage in the US - my >> experience with it was that it was not as reliable as the VOIP >> products offered through the various broadband providers I have had. >> > Let us be clear: if you're getting "digital telephone" service from a > cable television provider, it is *not* "VoIP", in the usage in which > most speakers mean that term -- "Voice Over Internet" is what they should > be saying, and cable-phone isn't that; the voice traffic rides over a > separate DOCSiS channel, protected from both the Internet and CATV > traffic on the link. > Er, I'm not sure what the difference you're trying to make. Is IP running over an L2 with a SLA any less "IP" than one without a SLA? That's all the DOCSIS qos is: dynamically creating/tearing down enhanced L2 qos channels for rtp to run over. It's been quite a while since I've been involved, but what we were working on with CableLabs certainly was VoIP in every respect I can think of. | As I recall, this questionably fair competitive advantage has been > looked into by ... someone. (Cablecos won't permit competing VoIP > services to utilize this protected channel, somewhere between "generally" > and "ever".) > There's is a great deal of overhead involved with the booking of resources for enhanced qos -- one big problem is that it adds quite a bit of latency to call set up. I'm sceptical at this point that it makes much difference for voice quality since voice traffic is such a tiny proportion of traffic in general -- a lot has changed in the last 15 years. Now video... I'm willing to believe that that enhanced qos still makes a difference there, but with youtube, netflix, etc, etc the genie isn't getting back in that bottle any time soon. So Moore's law is likely to have the final word there too making all of the docsis qos stuff ultimately irrelevant. Mike From tsison at gmail.com Tue Mar 1 09:09:54 2011 From: tsison at gmail.com (=?utf-8?B?dHNpc29uQGdtYWlsLmNvbQ==?=) Date: Tue, 01 Mar 2011 08:09:54 -0700 Subject: =?utf-8?B?UmU6IFN3aXRjaCB3aXRoIDEwIEdpZyBhbmQgR1JFIHN1cHBvcnQgaW4gaGFyZHdhcmUu?= Message-ID: <4d6d0c36.8658dc0a.1531.7c08@mx.google.com> is the requirment still 1-2 U switch? ----- Reply message ----- From: sthaug at nethelp.no Date: Tue, Mar 1, 2011 4:44 am Subject: Switch with 10 Gig and GRE support in hardware. To: Cc: > Juniper MX80 does all this. 1. It's not a switch (so don't expect "switch pricing"). 2. It doesn't offer 12 x 10GE ports. And I believe this has been mentioned earlier in the same thread... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From leigh.porter at ukbroadband.com Tue Mar 1 09:28:30 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 1 Mar 2011 15:28:30 -0000 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: <4d6d0c36.8658dc0a.1531.7c08@mx.google.com> References: <4d6d0c36.8658dc0a.1531.7c08@mx.google.com> Message-ID: OK. Please show me a ?switch? that will terminate Layer 3 GRE tunnels.. If it does GRE then it is making Layer 3 forwarding decisions which is a router function. It may be built into a switch as well, but it is still a router. -- Leigh Porter From: tsison at gmail.com [mailto:tsison at gmail.com] Sent: 01 March 2011 15:10 To: sthaug at nethelp.no; Leigh Porter Cc: nanog at nanog.org Subject: Re: Switch with 10 Gig and GRE support in hardware. is the requirment still 1-2 U switch? ----- Reply message ----- From: sthaug at nethelp.no Date: Tue, Mar 1, 2011 4:44 am Subject: Switch with 10 Gig and GRE support in hardware. To: Cc: > Juniper MX80 does all this. 1. It's not a switch (so don't expect "switch pricing"). 2. It doesn't offer 12 x 10GE ports. And I believe this has been mentioned earlier in the same thread... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jgreco at ns.sol.net Tue Mar 1 09:34:02 2011 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 1 Mar 2011 09:34:02 -0600 (CST) Subject: What vexes VoIP users? In-Reply-To: <4D6D0654.60203@ispalliance.net> Message-ID: <201103011534.p21FY2nI080286@aurora.sol.net> > > There may be no compelling reason to do so, at least. However, digital > > gear offers benefits, and some people want them. Others, like me, live > > in bad RF environments where POTS picks up too much noise unless you > > very carefully select your gear and shield your cables. Further, the > > digital phones support other features, such as the ability to manage > > multiple calls seamlessly, present Caller-ID reliably (even while you > > are on another call), etc. > > If you have issues with your wiring as bad as you describe then your > problem is with your in home wiring and possibly the wiring in your > area. Yes. The problem couldn't possibly be related to the AM/FM broadcasting mega-station with several towers just a short distance away, and it couldn't be related to poorly shielded electronics devices that are made as cheaply as possible... > Twisted pair inherently resists the kinds ingress your describing > if its properly installed and maintained. Of course this has nothing to > do with digital communications since any communication over your wiring > will be problematic. Twisted pair mildly deters RF interference. Give it enough and the whole thing's still an antenna... which is why shielding cables is part of the solution. > > I hate to tell *you*, but the LEC's and cable companies like to hand > > off POTS to small businesses too. > > Of course they do, but the discussion was specifically about residential > users. In the case of enterprise users there are lots of choices > ranging from "virtual" PBXs to local PBXs with proprietary digital phones. If you actually work with small businesses, you'll find that in many cases, products like TDS's XData or whatever Time Warner Cable's bundled business offering is called have been sold to small businesses and they like to hand off POTS. As in, in most cases, no other option exists. The problem here is that all of this discourages the advantages inherent in digital technology. POTS functions as a chokepoint in the realm of possibilities. Once you've converted the signal from digital to POTS and then reconverted it to digital, there's less flexibility. There's no particularly good reason that a VoIP-over-cable system shouldn't be able to hand off calls to an arbitrary SIP device. > > Your argument: "This works fine for most people therefore it will > > work for everyone." Is that really what you're saying? > > No, I asked what will make consumers choose digital connections today > for residential service rather than re-using their existing hand sets. In many cases, they don't care. I already answered things that *will* make some people choose digital connections. > >> What's broken for a residential user? > > That depends. I've got many years of experience with POTS. > > That's nice, but your experience doesn't track with what the market has > done. You describe specific wiring related problems as if they are > endemic to in home wiring and that's simply not true nor does a > "digital" hand set magically fix them if they are there. If anything > when a user has that many issues with in home wiring the lowest cost > solution is usually to install a wireless set, not because its "better" > but because its cheaper than fixing the in home wiring in many/most > cases for operators. Actually, a digital phone does. Dumping POTS for ISDN BRI eliminated numerous problems; most notably, the call quality went from wildly erratic with random radio interference, to crystal clear. ISDN BRI was essentially *just* substituting a digital path from the same CO to the same CPE over the same copper; at&t still had problems getting their systems to do things like presenting multiple calls to the same DN on the BRI (who knows why). So the switch from BRI to VoIP added other useful capabilities, such as multiple call appearances working properly. For your average residential user, the idea that someone can pick up a phone and not accidentally cut in on someone else's call is nearly stunning; to be able to accept multiple incoming calls or place more than one simultaneous outbound call is quite nice in some households. > > That's a matter of the consumer and their needs and wants. > > The market has very definitively answered this question so far which is > what confuses me about your argument. No, the market hasn't. What *has* happened is that the LEC's and cable carriers have deemed it a support nightmare to try to support random VoIP gear, and they'd rather sell $29/month VoIP-to-a-POTS-jack service because it's more profitable. That's an artificial constraint on the market, that's not actually the market. This is probably off-topic for NANOG at this point; I'm not sure where to redirect it to though. ... 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 ctracy at es.net Tue Mar 1 10:47:39 2011 From: ctracy at es.net (Chris Tracy) Date: Tue, 1 Mar 2011 11:47:39 -0500 Subject: Verizon Issues? East Coast US In-Reply-To: References: <4D6C5F9B.9080301@kenweb.org> Message-ID: >> Seeing some packet loss via Cogent. >> www.internetpulse.net seems to be lighting up. > I'm noticing it too. POP in Grand Rapids, circuit to Detroit. Packet loss, > but no total loss of connectivity. Interesting. I began to notice trouble reaching google about a week ago from 2 different east-cost Verizon FiOS lines -- one business and one residential -- but my problem appears to be congestion at the AS701 <> AS15169 border. I'm not noticing any loss across AS701. These problems began around 9am Eastern on Saturday Feb 19th -- see attached smokeping graph. You can see the diurnal pattern in the loss -- packet loss peaks between 9a-4p ET. Of course, I can get toipv6.google.com without any loss at all via my HE tunnel! In both cases, mtr shows ~50% loss beginning at google-gw.customer.alter.net (152.179.50.62), the first hop in AS15169. It's clear that I must be losing more ICMP than TCP packets given that google webpages come up fairly quickly, but youtube videos hang ever since this started. Anybody else seeing this? Thanks, -Chris -- Chris Tracy Energy Sciences Network (ESnet) Lawrence Berkeley National Laboratory -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen shot 2011-03-01 at Mar 1 11.44.55 AM.jpg Type: image/jpg Size: 48055 bytes Desc: not available URL: From gbonser at seven.com Tue Mar 1 11:39:33 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 1 Mar 2011 09:39:33 -0800 Subject: IPv6? Why, you are the first one to ask for it! Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> Fairly major global network provider likes to call themselves a "Tier 1". Asking about native IPv6 in one of their colo facilities in the UK. They say their US facilities won't be v6 capable until Q4 2011. The UK rep acted like it was the first he'd ever heard of it and implied we were the very first to ask for it. Note to providers: That might have worked a couple of years ago but when we hear that today, we know it is false. Please be honest in your responses to that question. If you aren't going to deploy it for another year or two, just say so. The notion that we are the very first ones to ever ask for it from a global provider in a major country is just lame. George From paul at paulgraydon.co.uk Tue Mar 1 11:46:01 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 01 Mar 2011 07:46:01 -1000 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> Message-ID: <4D6D30D9.6040502@paulgraydon.co.uk> On 03/01/2011 07:39 AM, George Bonser wrote: > Fairly major global network provider likes to call themselves a "Tier > 1". Asking about native IPv6 in one of their colo facilities in the UK. > They say their US facilities won't be v6 capable until Q4 2011. The UK > rep acted like it was the first he'd ever heard of it and implied we > were the very first to ask for it. > > Note to providers: That might have worked a couple of years ago but > when we hear that today, we know it is false. Please be honest in your > responses to that question. If you aren't going to deploy it for > another year or two, just say so. The notion that we are the very first > ones to ever ask for it from a global provider in a major country is > just lame. > > George > > Having worked both inside and outside the ISP industry, I wouldn't necessarily trust a salesman to know a DSL from a leased line, let alone IPv6 vs IPv4, nor to have remembered being asked about it before. That's stuff for pre-sales engineers to handle, not the salesman. From bret at getjive.com Tue Mar 1 13:05:07 2011 From: bret at getjive.com (Bret Palsson) Date: Tue, 1 Mar 2011 12:05:07 -0700 Subject: Verizon Issues? East Coast US In-Reply-To: References: <4D6C5F9B.9080301@kenweb.org> Message-ID: From our experience and smoke pings on Verizon's alternet, they ALWAYS have issues. Which is why we moved away from them. -Bret On Mar 1, 2011, at 9:47 AM, Chris Tracy wrote: >>> Seeing some packet loss via Cogent. >>> www.internetpulse.net seems to be lighting up. >> I'm noticing it too. POP in Grand Rapids, circuit to Detroit. Packet loss, >> but no total loss of connectivity. > > Interesting. I began to notice trouble reaching google about a week ago from 2 different east-cost Verizon FiOS lines -- one business and one residential -- but my problem appears to be congestion at the AS701 <> AS15169 border. I'm not noticing any loss across AS701. > > These problems began around 9am Eastern on Saturday Feb 19th -- see attached smokeping graph. You can see the diurnal pattern in the loss -- packet loss peaks between 9a-4p ET. Of course, I can get toipv6.google.com without any loss at all via my HE tunnel! > > In both cases, mtr shows ~50% loss beginning at google-gw.customer.alter.net (152.179.50.62), the first hop in AS15169. It's clear that I must be losing more ICMP than TCP packets given that google webpages come up fairly quickly, but youtube videos hang ever since this started. > > Anybody else seeing this? > > Thanks, > -Chris > > -- > Chris Tracy > Energy Sciences Network (ESnet) > Lawrence Berkeley National Laboratory > > From rsm at fast-serv.com Tue Mar 1 13:35:28 2011 From: rsm at fast-serv.com (Randy McAnally) Date: Tue, 1 Mar 2011 14:35:28 -0500 Subject: Verizon Issues? East Coast US In-Reply-To: References: <4D6C5F9B.9080301@kenweb.org> Message-ID: <20110301193412.M20301@fast-serv.com> On Tue, 1 Mar 2011 11:47:39 -0500, Chris Tracy wrote > In both cases, mtr shows ~50% loss beginning at google- > gw.customer.alter.net (152.179.50.62), the first hop in AS15169. > It's clear that I must be losing more ICMP than TCP packets given > that google webpages come up fairly quickly, but youtube videos hang > ever since this started. > > Anybody else seeing this? I've been seeing ~50% packet loss to google from FiOS (WDC area) for a while now. Youtube completely unusable during the day for the most part, but that has been going on for months to tell you the truth. ~Randy From khuon at neebu.net Tue Mar 1 14:07:07 2011 From: khuon at neebu.net (Jake Khuon) Date: Tue, 01 Mar 2011 12:07:07 -0800 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <4D6D30D9.6040502@paulgraydon.co.uk> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> <4D6D30D9.6040502@paulgraydon.co.uk> Message-ID: <1299010028.9363.14.camel@Decaf.NEEBU.Net> On Tue, 2011-03-01 at 07:46 -1000, Paul Graydon wrote: > Having worked both inside and outside the ISP industry, I wouldn't > necessarily trust a salesman to know a DSL from a leased line, let alone > IPv6 vs IPv4, nor to have remembered being asked about it before. > That's stuff for pre-sales engineers to handle, not the salesman. If IPv6 is being mentioned in mainstream news media including local and national TV news (which it has) then I would expect a salesperson of an ISP to also be somewhat knowledgeable enough to be able to able to at least spell it. And I agree with the previous poster that in this day and age, it is unlikely that the sales group of a global provider would not have encountered such a request. If anything, they should have been hit with those kinds of requests starting ten years ago. Perhaps that particular salesperson had not but he/she should have been briefed on it and should be familiar enough with deployment status to be able to talk intelligently and honestly with a potential customer. -- /*=================[ Jake Khuon ]=================+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | -------- | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==================================================================*/ From khelms at ispalliance.net Tue Mar 1 14:24:27 2011 From: khelms at ispalliance.net (Scott Helms) Date: Tue, 01 Mar 2011 15:24:27 -0500 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <1299010028.9363.14.camel@Decaf.NEEBU.Net> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> <4D6D30D9.6040502@paulgraydon.co.uk> <1299010028.9363.14.camel@Decaf.NEEBU.Net> Message-ID: <4D6D55FB.8050707@ispalliance.net> We've been the "first" for one of the oldest and best known Tier 1's in Metro Atlanta for quite some time.... It only took them 3 weeks to get the order right in their billing system and another 4.5 months to get it working. > And I agree with the previous poster that in this day and age, it is > unlikely that the sales group of a global provider would not have > encountered such a request. If anything, they should have been hit with > those kinds of requests starting ten years ago. Perhaps that particular > salesperson had not but he/she should have been briefed on it and should > be familiar enough with deployment status to be able to talk > intelligently and honestly with a potential customer. > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From cdel at firsthand.net Tue Mar 1 14:28:14 2011 From: cdel at firsthand.net (Christian de Larrinaga) Date: Tue, 1 Mar 2011 21:28:14 +0100 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> Message-ID: <08D619A4-45DB-4BF7-AB1F-55E6FFA74F61@firsthand.net> Do please let me know which major global network provider this is. Off-list if you prefer. Christian On 1 Mar 2011, at 18:39, George Bonser wrote: > Fairly major global network provider likes to call themselves a "Tier > 1". Asking about native IPv6 in one of their colo facilities in the UK. > They say their US facilities won't be v6 capable until Q4 2011. The UK > rep acted like it was the first he'd ever heard of it and implied we > were the very first to ask for it. > > Note to providers: That might have worked a couple of years ago but > when we hear that today, we know it is false. Please be honest in your > responses to that question. If you aren't going to deploy it for > another year or two, just say so. The notion that we are the very first > ones to ever ask for it from a global provider in a major country is > just lame. > > George > > From franck at genius.com Tue Mar 1 15:16:43 2011 From: franck at genius.com (Franck Martin) Date: Tue, 1 Mar 2011 13:16:43 -0800 (PST) Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> Message-ID: <16290139.211.1299014203066.JavaMail.franck@franck-martins-macbook-pro.local> Don't forget there is no commission for the salesperson to enable IPv6 for you, so definitively they are not interested and you asking them to deal with the issue, will just lower their pay at the end of the month because they could not use this valuable time to find customers with commissions... ----- Original Message ----- > From: "George Bonser" > To: "NANOG list" > Sent: Tuesday, 1 March, 2011 9:39:33 AM > Subject: IPv6? Why, you are the first one to ask for it! > Fairly major global network provider likes to call themselves a "Tier > 1". Asking about native IPv6 in one of their colo facilities in the > UK. > They say their US facilities won't be v6 capable until Q4 2011. The UK > rep acted like it was the first he'd ever heard of it and implied we > were the very first to ask for it. > > Note to providers: That might have worked a couple of years ago but > when we hear that today, we know it is false. Please be honest in your > responses to that question. If you aren't going to deploy it for > another year or two, just say so. The notion that we are the very > first > ones to ever ask for it from a global provider in a major country is > just lame. > > George From jeroen at unfix.org Tue Mar 1 15:41:45 2011 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 01 Mar 2011 22:41:45 +0100 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <16290139.211.1299014203066.JavaMail.franck@franck-martins-macbook-pro.local> References: <16290139.211.1299014203066.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4D6D6819.6060008@unfix.org> On 2011-03-01 22:16, Franck Martin wrote: > Don't forget there is no commission for the salesperson to enable > IPv6 for you, so definitively they are not interested and you asking > them to deal with the issue, will just lower their pay at the end of > the month because they could not use this valuable time to find > customers with commissions... And that, hits the hammer right on the nail... Or to put it better: http://www.youtube.com/watch?v=PUYdi43qXHc It always just depends on whose pocket it is, in the above example the blocker is the sales droid whose pockets won't get any deeper at the moment, in a lot of other cases it is the management types who don't get a direct benefit from it. And actually, who can blame them? Be sure to know that when time runs out though that they will come screaming at the techies, but then again, those types generally don't get the bonusses for that then to save the ass of the above types... Greets, Jeroen From gbonser at seven.com Tue Mar 1 15:43:43 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 1 Mar 2011 13:43:43 -0800 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <1299010028.9363.14.camel@Decaf.NEEBU.Net> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com><4D6D30D9.6040502@paulgraydon.co.uk> <1299010028.9363.14.camel@Decaf.NEEBU.Net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13E4B@RWC-EX1.corp.seven.com> > Perhaps that > particular > salesperson had not but he/she should have been briefed on it and > should > be familiar enough with deployment status to be able to talk > intelligently and honestly with a potential customer. > > I could buy that if it weren't for the fact that it took two days to come back with that answer. An off the cuff "wow, nobody has ever asked me that before, I need to check on it" would have been understandable for a new rep. Two days later coming back with "gee, we really haven't had anyone ask about that before" is bogus. I am not trying to beat anyone up here, the point is a general one for the providers out there. If you can't offer v6, say so, don't try to dance around it and pretend that customer is the only one on the planet with a migration plan because we know better. From scott at sberkman.net Tue Mar 1 16:25:57 2011 From: scott at sberkman.net (Scott Berkman) Date: Tue, 1 Mar 2011 17:25:57 -0500 Subject: Coffer MAC Address Vendor Database Message-ID: <034601cbd85f$a3253b10$e96fb130$@sberkman.net> Is anyone on the list that knows about the Coffer MAC address vendor database (http://www.coffer.com/mac_find/)? I have used this resource for years and I am now getting a permission error (403 Forbidden) when I try to go to any page on that site. Otherwise, anyone have recommendations for another resource for this information? Thanks, -Scott From rcarpen at network1.net Tue Mar 1 16:32:50 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 01 Mar 2011 17:32:50 -0500 (EST) Subject: Coffer MAC Address Vendor Database In-Reply-To: <034601cbd85f$a3253b10$e96fb130$@sberkman.net> Message-ID: <52055394-ac99-418e-a42d-9f8cb5e079ab@zimbra.network1.net> Straight from the source: http://standards.ieee.org/develop/regauth/oui/public.html -Randy ----- Original Message ----- > Is anyone on the list that knows about the Coffer MAC address vendor > database (http://www.coffer.com/mac_find/)? > > > > I have used this resource for years and I am now getting a permission > error > (403 Forbidden) when I try to go to any page on that site. > > > > Otherwise, anyone have recommendations for another resource for this > information? > > > > Thanks, > > > > -Scott > > > From franck at genius.com Tue Mar 1 17:57:52 2011 From: franck at genius.com (Franck Martin) Date: Tue, 1 Mar 2011 15:57:52 -0800 (PST) Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <4D6D6819.6060008@unfix.org> Message-ID: <18206893.221.1299023869984.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Jeroen Massar" > To: "Franck Martin" > Cc: "George Bonser" , "NANOG list" > Sent: Tuesday, 1 March, 2011 1:41:45 PM > Subject: Re: IPv6? Why, you are the first one to ask for it! > On 2011-03-01 22:16, Franck Martin wrote: > > Don't forget there is no commission for the salesperson to enable > > IPv6 for you, so definitively they are not interested and you asking > > them to deal with the issue, will just lower their pay at the end of > > the month because they could not use this valuable time to find > > customers with commissions... > > And that, hits the hammer right on the nail... > > Or to put it better: > http://www.youtube.com/watch?v=PUYdi43qXHc > > It always just depends on whose pocket it is, in the above example the > blocker is the sales droid whose pockets won't get any deeper at the > moment, in a lot of other cases it is the management types who don't > get > a direct benefit from it. > > And actually, who can blame them? Be sure to know that when time runs > out though that they will come screaming at the techies, but then > again, > those types generally don't get the bonusses for that then to save the > ass of the above types... > The board to the managers/sales people: "Please explain us again why we can't have more customers?" From bhmccie at gmail.com Tue Mar 1 18:17:07 2011 From: bhmccie at gmail.com (-Hammer-) Date: Tue, 1 Mar 2011 18:17:07 -0600 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <16290139.211.1299014203066.JavaMail.franck@franck-martins-macbook-pro.local> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> <16290139.211.1299014203066.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <01f001cbd86f$2bc79260$8356b720$@com> I don't know about that. Even though the carriers (USA) I've talked to are having trouble presenting native IPv6 to me in the next few quarters, they have no problem pitching professional services to help me with the implementation. Several of my hardware vendors have too. Don't be surprised at all to see this presented to senior management as a new revenue stream. "Helping the inept prepare for tomorrow". -Hammer- "I was a normal American nerd." -Jack Herer -----Original Message----- From: Franck Martin [mailto:franck at genius.com] Sent: Tuesday, March 01, 2011 3:17 PM To: George Bonser Cc: NANOG list Subject: Re: IPv6? Why, you are the first one to ask for it! Don't forget there is no commission for the salesperson to enable IPv6 for you, so definitively they are not interested and you asking them to deal with the issue, will just lower their pay at the end of the month because they could not use this valuable time to find customers with commissions... ----- Original Message ----- > From: "George Bonser" > To: "NANOG list" > Sent: Tuesday, 1 March, 2011 9:39:33 AM > Subject: IPv6? Why, you are the first one to ask for it! > Fairly major global network provider likes to call themselves a "Tier > 1". Asking about native IPv6 in one of their colo facilities in the > UK. > They say their US facilities won't be v6 capable until Q4 2011. The UK > rep acted like it was the first he'd ever heard of it and implied we > were the very first to ask for it. > > Note to providers: That might have worked a couple of years ago but > when we hear that today, we know it is false. Please be honest in your > responses to that question. If you aren't going to deploy it for > another year or two, just say so. The notion that we are the very > first > ones to ever ask for it from a global provider in a major country is > just lame. > > George From deepak at ai.net Tue Mar 1 18:47:38 2011 From: deepak at ai.net (Deepak Jain) Date: Tue, 1 Mar 2011 19:47:38 -0500 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <18206893.221.1299023869984.JavaMail.franck@franck-martins-macbook-pro.local> References: <4D6D6819.6060008@unfix.org> <18206893.221.1299023869984.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > The board to the managers/sales people: "Please explain us again why we > can't have more customers?" Let's be real for a second, there are plenty of backbone-ish companies that have been around long enough to accumulate tons, and tons of IPv4 space. I remember an old SP that used to give every PC in their NOC, possibly their whole company, a /24 and /16s weren't hard to get either. Lots of shops that had IP-based hosting that have gone name-based probably have tons of available space too. The "no more IP addresses available" will affect folks unevenly... if I were to guess, mostly the folks that aren't large/old enough to have gobs of space lying around but are too large to get provider space. I'm also guessing that these guys are the ones creating the most pressure for IPv6 in their upstreams, as it serves their interests to make IPv4 unneeded as soon as possible. The next big surge of IT spend that isn't about reduction or consolidation will create pressure on Enterprises to use more address space, and if they are nearly out of IPv4 space (with firewalls, NAT, VPNs, etc, not a lot of pressure there) they will push their SPs for it. Government contracts for telecomm all require IPv6 support, and all the vendors on them say they support it, but gov't customers trying to order say that is a no-go. (As of two weeks ago)... so even gov't isn't a big enough buyer to make this happen sooner. DJ From scott at sberkman.net Tue Mar 1 19:10:23 2011 From: scott at sberkman.net (Scott Berkman) Date: Tue, 1 Mar 2011 20:10:23 -0500 Subject: Coffer MAC Address Vendor Database In-Reply-To: <034601cbd85f$a3253b10$e96fb130$@sberkman.net> References: <034601cbd85f$a3253b10$e96fb130$@sberkman.net> Message-ID: <039001cbd876$9bb40d40$d31c27c0$@sberkman.net> Back up now, thanks for the responses. -Scott -----Original Message----- From: Scott Berkman [mailto:scott at sberkman.net] Sent: Tuesday, March 01, 2011 5:26 PM To: nanog at nanog.org Subject: Coffer MAC Address Vendor Database Is anyone on the list that knows about the Coffer MAC address vendor database (http://www.coffer.com/mac_find/)? I have used this resource for years and I am now getting a permission error (403 Forbidden) when I try to go to any page on that site. Otherwise, anyone have recommendations for another resource for this information? Thanks, -Scott From marka at isc.org Tue Mar 1 19:14:00 2011 From: marka at isc.org (Mark Andrews) Date: Wed, 02 Mar 2011 12:14:00 +1100 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: Your message of "Tue, 01 Mar 2011 19:47:38 CDT." References: <4D6D6819.6060008@unfix.org> <18206893.221.1299023869984.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20110302011400.52373B5E991@drugs.dv.isc.org> In message , Deepak Ja in writes: > > The board to the managers/sales people: "Please explain us again why we > > can't have more customers?" > > Let's be real for a second, there are plenty of backbone-ish companies > that have been around long enough to accumulate tons, and tons of IPv4 > space. > > I remember an old SP that used to give every PC in their NOC, possibly > their whole company, a /24 and /16s weren't hard to get either. Lots of > shops that had IP-based hosting that have gone name-based probably have > tons of available space too. > > The "no more IP addresses available" will affect folks unevenly... if I > were to guess, mostly the folks that aren't large/old enough to have gobs > of space lying around but are too large to get provider space. I'm also > guessing that these guys are the ones creating the most pressure for IPv6 > in their upstreams, as it serves their interests to make IPv4 unneeded as > soon as possible. > > The next big surge of IT spend that isn't about reduction or > consolidation will create pressure on Enterprises to use more address > space, and if they are nearly out of IPv4 space (with firewalls, NAT, > VPNs, etc, not a lot of pressure there) they will push their SPs for it. > Government contracts for telecomm all require IPv6 support, and all the > vendors on them say they support it, but gov't customers trying to order > say that is a no-go. (As of two weeks ago)... so even gov't isn't a big > enough buyer to make this happen sooner. > > DJ While some companies will have plenty of IPv4 space for a long time, not all the people they communicate with will. Some of them will be forced into using IPv6 sooner rather than later. All companies need to be ready for that regardless of how much IPv4 they have. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jason at i6ix.com Tue Mar 1 19:42:28 2011 From: jason at i6ix.com (Jason Bertoch) Date: Tue, 1 Mar 2011 20:42:28 -0500 (EST) Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13E4B@RWC-EX1.corp.seven.com> Message-ID: <9372287.65.1299030148669.JavaMail.root@zimbra.i6ix.com> ----- Original Message ----- > From: "George Bonser" > > I could buy that if it weren't for the fact that it took two days to > come back with that answer. An off the cuff "wow, nobody has ever > asked me that before, I need to check on it" would have been > understandable for a new rep. Two days later coming back with "gee, we > really haven't had anyone ask about that before" is bogus. > > I am not trying to beat anyone up here, the point is a general one for > the providers out there. If you can't offer v6, say so, don't try to > dance around it and pretend that customer is the only one on the > planet with a migration plan because we know better. At this point, I'd even settle for a lie from one of my upstreams. I've asked the local tech folks a couple of times over the last year or so, on top of a request to our sales rep, without even a single response to the question of "do you support v6 yet and, if not, what's your timeline?". -- /Jason From matt.addison at lists.evilgeni.us Tue Mar 1 16:32:36 2011 From: matt.addison at lists.evilgeni.us (Matt Addison) Date: Tue, 1 Mar 2011 17:32:36 -0500 Subject: Coffer MAC Address Vendor Database In-Reply-To: <034601cbd85f$a3253b10$e96fb130$@sberkman.net> References: <034601cbd85f$a3253b10$e96fb130$@sberkman.net> Message-ID: On Tue, Mar 1, 2011 at 17:25, Scott Berkman wrote: > Otherwise, anyone have recommendations for another resource for this > information? > http://standards.ieee.org/develop/regauth/oui/public.html ~Matt From gih at apnic.net Tue Mar 1 20:53:28 2011 From: gih at apnic.net (Geoff Huston) Date: Wed, 2 Mar 2011 13:53:28 +1100 Subject: Request for assistance with BGP feeds Message-ID: <6F4C56FC-BFF4-4E41-87DB-BA58817C6A4C@apnic.net> Hi I am conducting some research relating to BGP behaviour and I need some eBGP multihop feeds - IPv4 and/or IPv6 eBGP, and full eBGP route table feeds please. These are incoming feeds only (I will be announcing _nothing_ back in these sessions - I'll filtering outbound and you should defensively filter inbound of course). I am looking at the real time behaviour of BGP updates in a relatively dense multi-peer environment, which is why I am looking for a number of full route feeds. Please drop me a note if you can assist me with this activity. Thanks in advance, Geoff -- Geoff Huston APNIC From jcdill.lists at gmail.com Tue Mar 1 21:03:22 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Tue, 01 Mar 2011 19:03:22 -0800 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <1299010028.9363.14.camel@Decaf.NEEBU.Net> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> <4D6D30D9.6040502@paulgraydon.co.uk> <1299010028.9363.14.camel@Decaf.NEEBU.Net> Message-ID: <4D6DB37A.2090702@gmail.com> On 01/03/11 12:07 PM, Jake Khuon wrote: > And I agree with the previous poster that in this day and age, it is > unlikely that the sales group of a global provider would not have > encountered such a request. If anything, they should have been hit with > those kinds of requests starting ten years ago. Perhaps that particular > salesperson had not but he/she should have been briefed on it and should > be familiar enough with deployment status to be able to talk > intelligently and honestly with a potential customer. You can use their reply to an IPv6 request as a bit of a bozo filter, much like the RFP discussed here used RFC 1149 to determine if the companies actually read and understood the RFCs they were expected to support. http://www.itworld.com/NWW010409bradner I *love* using Bozo filters. Anytime you can trick companies into revealing their true colors, you are a step ahead in the game. jc From jra at baylink.com Tue Mar 1 21:33:42 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 1 Mar 2011 22:33:42 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <4D6D087D.1020005@mtcc.com> Message-ID: <25289587.644.1299036822117.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Thomas" > On 03/01/2011 05:51 AM, Jay Ashworth wrote: > > Let us be clear: if you're getting "digital telephone" service from a > > cable television provider, it is *not* "VoIP", in the usage in which > > most speakers mean that term -- "Voice Over Internet" is what they > > should be saying, and cable-phone isn't that; the voice traffic rides over > > a separate DOCSiS channel, protected from both the Internet and CATV > > traffic on the link. > > > > Er, I'm not sure what the difference you're trying to make. Er, I'm not sure why... > Is IP running over an L2 with a SLA any less "IP" than one > without a SLA? That's all the DOCSIS qos is: dynamically > creating/tearing down enhanced L2 qos channels for rtp > to run over. It's been quite a while since I've been involved, > but what we were working on with CableLabs certainly was > VoIP in every respect I can think of. Wow. I thought I was pretty clear in what I said above; I'm sorry you didn't get it. "What everyone is actually *selling* commercially, except for cable providers, is *not* VoIP; it's a subset of that: VoN; Voice Over Internet; where the IP transport *goes over the public internet*, and through whatever exchange points may be necessary to get from you to the provider. Cable companies are selling you *one hop* (maybe 2 or 3; certainly not 12-18), over a link with bandwidth protected from whatever may be going on on the Internet IP link they're also selling you; and which is therefore guaranteed to have better quality than whatever "VoIP" service it might be competing with." Better? > | As I recall, this questionably fair competitive advantage has been > > looked into by ... someone. (Cablecos won't permit competing VoIP > > services to utilize this protected channel, somewhere between > > "generally" > > and "ever".) > > There's is a great deal of overhead involved with the booking > of resources for enhanced qos -- one big problem is that it > adds quite a bit of latency to call set up. I'm sceptical at this > point that it makes much difference for voice quality since voice > traffic is such a tiny proportion of traffic in general -- a lot has > changed in the last 15 years. Now video... I'm willing to believe > that that enhanced qos still makes a difference there, but > with youtube, netflix, etc, etc the genie isn't getting back in > that bottle any time soon. So Moore's law is likely to have the > final word there too making all of the docsis qos stuff ultimately > irrelevant. I wasn't suggesting QOS. I was suggesting *there's a completely separate pipe*, on non-Internet connected IP transport, carrying only the voice traffic, directly to a termination point, which is dedicated from the triple-play box and nailed up. Are you suggesting that's *not* how it's being done in production? Cheers, -- jra From bret at getjive.com Tue Mar 1 21:42:29 2011 From: bret at getjive.com (Bret Palsson) Date: Tue, 1 Mar 2011 20:42:29 -0700 Subject: What vexes VoIP users? In-Reply-To: <25289587.644.1299036822117.JavaMail.root@benjamin.baylink.com> References: <25289587.644.1299036822117.JavaMail.root@benjamin.baylink.com> Message-ID: <-462746519160898026@unknownmsgid> Sent from my iPhone On Mar 1, 2011, at 8:35 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Michael Thomas" > >> On 03/01/2011 05:51 AM, Jay Ashworth wrote: >>> Let us be clear: if you're getting "digital telephone" service from a >>> cable television provider, it is *not* "VoIP", in the usage in which >>> most speakers mean that term -- "Voice Over Internet" is what they >>> should be saying, and cable-phone isn't that; the voice traffic rides over >>> a separate DOCSiS channel, protected from both the Internet and CATV >>> traffic on the link. >>> >> >> Er, I'm not sure what the difference you're trying to make. > > Er, I'm not sure why... > >> Is IP running over an L2 with a SLA any less "IP" than one >> without a SLA? That's all the DOCSIS qos is: dynamically >> creating/tearing down enhanced L2 qos channels for rtp >> to run over. It's been quite a while since I've been involved, >> but what we were working on with CableLabs certainly was >> VoIP in every respect I can think of. > > Wow. > > I thought I was pretty clear in what I said above; I'm sorry you didn't > get it. > > "What everyone is actually *selling* commercially, except for cable > providers, is *not* VoIP; it's a subset of that: VoN; Voice Over Internet; > where the IP transport *goes over the public internet*, and through > whatever exchange points may be necessary to get from you to the > provider. > > Cable companies are selling you *one hop* (maybe 2 or 3; certainly not > 12-18), over a link with bandwidth protected from whatever may be > going on on the Internet IP link they're also selling you; and which is > therefore guaranteed to have better quality than whatever "VoIP" service > it might be competing with." > > Better? > Many VoIP companies like jive, peer with providers to give customers "*one hop* (maybe 2 or 3; certainly not > > 12-18), over a link with bandwidth protected from whatever may be > going on on the Internet IP link they're also selling you;" VoN? Didn't know there was a difference. Same protocols, same RTP,RTCP, Codecs, DSCP values. Am I missing something? >> | As I recall, this questionably fair competitive advantage has been >>> looked into by ... someone. (Cablecos won't permit competing VoIP >>> services to utilize this protected channel, somewhere between >>> "generally" >>> and "ever".) >> >> There's is a great deal of overhead involved with the booking >> of resources for enhanced qos -- one big problem is that it >> adds quite a bit of latency to call set up. I'm sceptical at this >> point that it makes much difference for voice quality since voice >> traffic is such a tiny proportion of traffic in general -- a lot has >> changed in the last 15 years. Now video... I'm willing to believe >> that that enhanced qos still makes a difference there, but >> with youtube, netflix, etc, etc the genie isn't getting back in >> that bottle any time soon. So Moore's law is likely to have the >> final word there too making all of the docsis qos stuff ultimately >> irrelevant. > > I wasn't suggesting QOS. I was suggesting *there's a completely separate > pipe*, on non-Internet connected IP transport, carrying only the > voice traffic, directly to a termination point, which is dedicated > from the triple-play box and nailed up. > > Are you suggesting that's *not* how it's being done in production? > > Cheers, > -- jra > From nathan at atlasnetworks.us Tue Mar 1 21:45:53 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 2 Mar 2011 03:45:53 +0000 Subject: What vexes VoIP users? In-Reply-To: <25289587.644.1299036822117.JavaMail.root@benjamin.baylink.com> References: <4D6D087D.1020005@mtcc.com> <25289587.644.1299036822117.JavaMail.root@benjamin.baylink.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3ADC3D@ex-mb-1.corp.atlasnetworks.us> > "What everyone is actually *selling* commercially, except for cable > providers, is *not* VoIP; it's a subset of that: VoN; Voice Over > Internet; > where the IP transport *goes over the public internet*, and through > whatever exchange points may be necessary to get from you to the > provider. This is utterly irrelevant to the topic at hand (What vexes VoIP users/providers). Further, it's ridiculous to say that something is a subset of something else, and yet not that something else. A1 cannot be a subtype of A without being A. A1 cannot be a subset of steak sauce without being steak sauce. Yes, it's a specific type of steak sauce, and is basically made of corn sugar, which may negate some of the issues with tomato-paste based steak sauces, but it is STILL a steak sauce, and is still relevant when talking about how many people put sauce on their steak as opposed to utilizing old fashioned steak rub. > Cable companies are selling you *one hop* (maybe 2 or 3; certainly not > 12-18), over a link with bandwidth protected from whatever may be > going on on the Internet IP link they're also selling you; and which is > therefore guaranteed to have better quality than whatever "VoIP" > service > it might be competing with." > > Better? Not really, because you're still arguing a point that doesn't matter. Is it Voice? Is it IP? Then it's VoIP. A lot of the issues are still relevant, and certainly the number of users can be said to count. The number of hops doesn't matter one iota. Is it not email if you're only 1 hop away from your SMTP server? Nathan From jra at baylink.com Tue Mar 1 21:51:49 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 1 Mar 2011 22:51:49 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <4D6D0402.7020404@ispalliance.net> Message-ID: <2039035.658.1299037908960.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Scott Helms" > > Let us be clear: if you're getting "digital telephone" service from a > > cable television provider, it is *not* "VoIP", in the usage in which > > most speakers mean that term -- "Voice Over Internet" is what they > > should be saying, and cable-phone isn't that; the voice traffic rides over > > a separate DOCSiS channel, protected from both the Internet and CATV > > traffic on the link. > > No, this incorrect. Packet Cable most certainly _is_ VOIP (a MGCP > variant to be precise until 2.0 after which it is SIP). While a few > providers, usually for non-technical reasons, did deploy an entirely > separate set of downstream and upstream interfaces that is far from the > norm. AFAIK the only top 20 MSO to do so in scale was Charter and I > don't know if they continue that today. Comcast, the largest cable > telephone provider certainly does not nor do providers need to since > any Packetcable CMTS and EMTA combo offers reliable prioritization in the > same channel(s) as the normal data path. Indeed. Then either Bright House is lying, their deployment was pretty early, or I'm nuts, cause I'm pretty certain that their early triple- play advertising said this -- though not in so many technical words. > > So of course Vonage and other VoN products will be less rugged. > > > > As I recall, this questionably fair competitive advantage has been > > looked into by ... someone. (Cablecos won't permit competing VoIP > > services to utilize this protected channel, somewhere between > > "generally" and "ever".) > As I said, this second channel doesn't exist in almost all cases (its > not cost effective nor needed in almost all cases). Having said that > over the top VOIP providers do suffer in comparison because they don't > get the benefit of prioritization in the local cable plant. "Cost-effective"? Could you expand on how the provisioning of a second virtual pipe down the hill to a cable box has any incremental costs at all? Cheers, -- jra From mike at mtcc.com Tue Mar 1 21:53:26 2011 From: mike at mtcc.com (Michael Thomas) Date: Tue, 01 Mar 2011 19:53:26 -0800 Subject: What vexes VoIP users? In-Reply-To: <25289587.644.1299036822117.JavaMail.root@benjamin.baylink.com> References: <25289587.644.1299036822117.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6DBF36.6020805@mtcc.com> On 03/01/2011 07:33 PM, Jay Ashworth wrote: > Is IP running over an L2 with a SLA any less "IP" than one >> without a SLA? That's all the DOCSIS qos is: dynamically >> creating/tearing down enhanced L2 qos channels for rtp >> to run over. It's been quite a while since I've been involved, >> but what we were working on with CableLabs certainly was >> VoIP in every respect I can think of. >> > Wow. > > I thought I was pretty clear in what I said above; I'm sorry you didn't > get it. > > "What everyone is actually *selling* commercially, except for cable > providers, is *not* VoIP; it's a subset of that: VoN; Voice Over Internet; > where the IP transport *goes over the public internet*, and through > whatever exchange points may be necessary to get from you to the > provider. > > Cable companies are selling you *one hop* (maybe 2 or 3; certainly not > 12-18), over a link with bandwidth protected from whatever may be > going on on the Internet IP link they're also selling you; and which is > therefore guaranteed to have better quality than whatever "VoIP" service > it might be competing with." > > Better? > Uh, I was part of the standards at packetcable from around 1999 or so on, and it was always plain old rtp over docsis. Since the upstream was really lousy back then, the MSO's wanted to give committed bit rate l2 docsis channels to the rtp traffic, but it was still rtp/rtcp flowing through them. So I still have no idea what distinction you're trying to draw. > I wasn't suggesting QOS. I was suggesting *there's a completely separate > pipe*, on non-Internet connected IP transport, carrying only the > voice traffic, directly to a termination point, which is dedicated > from the triple-play box and nailed up. > > Are you suggesting that's *not* how it's being done in production? > There were some MSO's who were thinking about doing that, but as I recall they went the way of the AAL2 dodo bird. Maybe a few deployed it, but from a packetcable/cablelabs perspective they weren't on the table. MGCP was the answer to getting rid of class 5 switches altogether, which the MSO's didn't have any particular affinity to. It was always rtp over ip over DOCSIS with DSCP in the core and arguments about RSVP. Mike, member of the packetcable security spec team whose work spawned SRTP and KINK amongst other things From jra at baylink.com Tue Mar 1 22:01:58 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 1 Mar 2011 23:01:58 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <-462746519160898026@unknownmsgid> Message-ID: <32446190.666.1299038518678.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Bret Palsson" > VoN? Didn't know there was a difference. Same protocols, same > RTP,RTCP, Codecs, DSCP values. Am I missing something? Well, you try to hold a conversation with someone while there's Torrent traffic going on on the same link, using a third-party SIP provider, and you tell *me* how that works out... Cheers, -- jra From mike at mtcc.com Tue Mar 1 22:05:52 2011 From: mike at mtcc.com (Michael Thomas) Date: Tue, 01 Mar 2011 20:05:52 -0800 Subject: What vexes VoIP users? In-Reply-To: <32446190.666.1299038518678.JavaMail.root@benjamin.baylink.com> References: <32446190.666.1299038518678.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6DC220.2040702@mtcc.com> On 03/01/2011 08:01 PM, Jay Ashworth wrote: > ----- Original Message ----- > >> From: "Bret Palsson" >> > >> VoN? Didn't know there was a difference. Same protocols, same >> RTP,RTCP, Codecs, DSCP values. Am I missing something? >> > Well, you try to hold a conversation with someone while there's Torrent > traffic going on on the same link, using a third-party SIP provider, and > you tell *me* how that works out... > That's completely under the control of the user's CPE: just get a router that prioritizes one over the other, or use a cable modem that does that for you. It doesn't require any Docsis magic. Mike From mike at mtcc.com Tue Mar 1 22:08:16 2011 From: mike at mtcc.com (Michael Thomas) Date: Tue, 01 Mar 2011 20:08:16 -0800 Subject: What vexes VoIP users? In-Reply-To: <2039035.658.1299037908960.JavaMail.root@benjamin.baylink.com> References: <2039035.658.1299037908960.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6DC2B0.9000608@mtcc.com> On 03/01/2011 07:51 PM, Jay Ashworth wrote: > As I said, this second channel doesn't exist in almost all cases (its >> not cost effective nor needed in almost all cases). Having said that >> over the top VOIP providers do suffer in comparison because they don't >> get the benefit of prioritization in the local cable plant. >> > "Cost-effective"? > > Could you expand on how the provisioning of a second virtual pipe down > the hill to a cable box has any incremental costs at all? > The original analog cable plant was separated into bands, so carving out IP of any kind meant sacrificing channels. They initially put the IP uplink into a band that was used originally used for very low bandwidth uplink signalling... the kind the big refrigerators and other noise producers torqued badly. So from the MSO's perspective, giving QoS treatment to the upstream had a big potential business case. Of course, analog cable is now gone and I doubt that any of the original assumptions have much bearing today. Mike, where's John Chapman when you need him? From bret at getjive.com Tue Mar 1 22:10:39 2011 From: bret at getjive.com (Bret Palsson) Date: Tue, 1 Mar 2011 21:10:39 -0700 Subject: What vexes VoIP users? In-Reply-To: <32446190.666.1299038518678.JavaMail.root@benjamin.baylink.com> References: <32446190.666.1299038518678.JavaMail.root@benjamin.baylink.com> Message-ID: <1870920561509363890@unknownmsgid> Works just fine. Yes that is one of the many tests we do. It's call partnerships with carriers and prioritization. DSCP works wonders, so do EF queues and policies, yes this is on the carrier side. Sounds like you need a VoIP company that cares. Sent from my iPhone On Mar 1, 2011, at 9:03 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Bret Palsson" > >> VoN? Didn't know there was a difference. Same protocols, same >> RTP,RTCP, Codecs, DSCP values. Am I missing something? > > Well, you try to hold a conversation with someone while there's Torrent > traffic going on on the same link, using a third-party SIP provider, and > you tell *me* how that works out... > > Cheers, > -- jra > From jra at baylink.com Tue Mar 1 22:11:11 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 1 Mar 2011 23:11:11 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3ADC3D@ex-mb-1.corp.atlasnetworks.us> Message-ID: <5574345.678.1299039071402.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Nathan Eisenberg" > > "What everyone is actually *selling* commercially, except for cable > > providers, is *not* VoIP; it's a subset of that: VoN; Voice Over > > Internet; where the IP transport *goes over the public internet*, and through > > whatever exchange points may be necessary to get from you to the > > provider. > > This is utterly irrelevant to the topic at hand (What vexes VoIP > users/providers). Further, it's ridiculous to say that something is a > subset of something else, and yet not that something else. A1 cannot > be a subtype of A without being A. A1 cannot be a subset of steak > sauce without being steak sauce. Yes, it's a specific type of steak > sauce, and is basically made of corn sugar, which may negate some of > the issues with tomato-paste based steak sauces, but it is STILL a > steak sauce, and is still relevant when talking about how many people > put sauce on their steak as opposed to utilizing old fashioned steak > rub. I believe you have a polarity reversal in your reading of my post. VoN is a subset of VoIP; it is what providers who *advertise* VoIP are generally actually selling; it is much more prone to problems on the local IP loop and the backbone than the subset of VoIP which the cable company who's selling you the broadband is offering. > > Cable companies are selling you *one hop* (maybe 2 or 3; certainly > > not > > 12-18), over a link with bandwidth protected from whatever may be > > going on on the Internet IP link they're also selling you; and which > > is > > therefore guaranteed to have better quality than whatever "VoIP" > > service > > it might be competing with." > > > > Better? > > Not really, because you're still arguing a point that doesn't matter. > Is it Voice? Is it IP? Then it's VoIP. A lot of the issues are still > relevant, and certainly the number of users can be said to count. The > number of hops doesn't matter one iota. Is it not email if you're only > 1 hop away from your SMTP server? Aw, c'mon with the strawmen, Nathan. SMTP isn't latency, jitter, and dropped-packet sensitive and SIP/RTP is, and that's pretty obvious. Yes, the number of hops and exchange points matters to VoIP in ways that it doesn't matter to SMTP and POP. I will attempt, one more time, to clarify my original underlying point. Then, if you absolutely insist, I shall give up: """ Lots of people sell PSTN gateway access via the TCP/IP public Internet. Nearly all of them call this VoIP. It is, but that term is insufficiently specific to allow the comparison of this service with "VoIP" service offered as a "triple-play" by broadband/cable companies, because their service is "protected" in one fashion or another from many impairments which the service sold by those third-parties is prone to, by the nature of the differences in their transport. Additionally, characterizing that third-party service solely as "VoIP" tends to give that term a bad reputation in other contexts, such as protected internal VoIP PBX service, in which it's perfectly suitable, even though Vonage is generally no better than mediocre. """ Did that more clearly explain why I'm unhappy with the fast and loose usage of the term VoIP in many contexts? Cheers, -- jra From jra at baylink.com Tue Mar 1 22:14:08 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 1 Mar 2011 23:14:08 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <4D6DBF36.6020805@mtcc.com> Message-ID: <2464999.680.1299039248681.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Thomas" > > I wasn't suggesting QOS. I was suggesting *there's a completely > > separate pipe*, on non-Internet connected IP transport, carrying only the > > voice traffic, directly to a termination point, which is dedicated > > from the triple-play box and nailed up. > > > > Are you suggesting that's *not* how it's being done in production? > > There were some MSO's who were thinking about doing that, > but as I recall they went the way of the AAL2 dodo bird. Maybe > a few deployed it, but from a packetcable/cablelabs perspective > they weren't on the table. MGCP was the answer to getting > rid of class 5 switches altogether, which the MSO's didn't > have any particular affinity to. It was always rtp over ip over > DOCSIS with DSCP in the core and arguments about RSVP. Over *the same* IP transport which carried packets from the user's router or PC to the broadband provider's edge router? Really? Then Bright House was either "special", or pretty carefully misleading in the advertising they did here. > Mike, member of the packetcable security spec team whose > work spawned SRTP and KINK amongst other things Well, you'd certainly have been in a position to hear about it. I've Been Mislead. My apologies, all. Cheers, -- jra From bret at getjive.com Tue Mar 1 22:29:01 2011 From: bret at getjive.com (Bret Palsson) Date: Tue, 1 Mar 2011 21:29:01 -0700 Subject: What vexes VoIP users? In-Reply-To: <5574345.678.1299039071402.JavaMail.root@benjamin.baylink.com> References: <5574345.678.1299039071402.JavaMail.root@benjamin.baylink.com> Message-ID: <-2425553653258109540@unknownmsgid> I'm sensing you have been burned badly by VoIP... which is too bad. I'm going to step out of the conversation since no one but you is likely to "win". Which isn't a bad thing, but trying to help someone understand a bit more about how some VoIP providers actually work now a days, who have already made up their mind... it's just not worth the effort. Certainly it's not helping others on this list. -Bret Bret Palsson Sr. Network & Systems Administrator Jive Communications, Inc. www.getjive.com Sent from my iPad On Mar 1, 2011, at 9:15 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Nathan Eisenberg" > >>> "What everyone is actually *selling* commercially, except for cable >>> providers, is *not* VoIP; it's a subset of that: VoN; Voice Over >>> Internet; where the IP transport *goes over the public internet*, and through >>> whatever exchange points may be necessary to get from you to the >>> provider. >> >> This is utterly irrelevant to the topic at hand (What vexes VoIP >> users/providers). Further, it's ridiculous to say that something is a >> subset of something else, and yet not that something else. A1 cannot >> be a subtype of A without being A. A1 cannot be a subset of steak >> sauce without being steak sauce. Yes, it's a specific type of steak >> sauce, and is basically made of corn sugar, which may negate some of >> the issues with tomato-paste based steak sauces, but it is STILL a >> steak sauce, and is still relevant when talking about how many people >> put sauce on their steak as opposed to utilizing old fashioned steak >> rub. > > I believe you have a polarity reversal in your reading of my post. > > VoN is a subset of VoIP; it is what providers who *advertise* VoIP are > generally actually selling; it is much more prone to problems on the > local IP loop and the backbone than the subset of VoIP which the cable > company who's selling you the broadband is offering. > >>> Cable companies are selling you *one hop* (maybe 2 or 3; certainly >>> not >>> 12-18), over a link with bandwidth protected from whatever may be >>> going on on the Internet IP link they're also selling you; and which >>> is >>> therefore guaranteed to have better quality than whatever "VoIP" >>> service >>> it might be competing with." >>> >>> Better? >> >> Not really, because you're still arguing a point that doesn't matter. >> Is it Voice? Is it IP? Then it's VoIP. A lot of the issues are still >> relevant, and certainly the number of users can be said to count. The >> number of hops doesn't matter one iota. Is it not email if you're only >> 1 hop away from your SMTP server? > > Aw, c'mon with the strawmen, Nathan. SMTP isn't latency, jitter, and > dropped-packet sensitive and SIP/RTP is, and that's pretty obvious. > > Yes, the number of hops and exchange points matters to VoIP in ways > that it doesn't matter to SMTP and POP. > > I will attempt, one more time, to clarify my original underlying point. > Then, if you absolutely insist, I shall give up: > > """ > Lots of people sell PSTN gateway access via the TCP/IP public Internet. > > Nearly all of them call this VoIP. It is, but that term is insufficiently > specific to allow the comparison of this service with "VoIP" service > offered as a "triple-play" by broadband/cable companies, because their > service is "protected" in one fashion or another from many impairments > which the service sold by those third-parties is prone to, by the > nature of the differences in their transport. > > Additionally, characterizing that third-party service solely as "VoIP" > tends to give that term a bad reputation in other contexts, such as > protected internal VoIP PBX service, in which it's perfectly suitable, > even though Vonage is generally no better than mediocre. > """ > > Did that more clearly explain why I'm unhappy with the fast and loose > usage of the term VoIP in many contexts? > > Cheers, > -- jra > From jsw at inconcepts.biz Tue Mar 1 23:31:23 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 2 Mar 2011 00:31:23 -0500 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> Message-ID: I guess I'll plug this Wikipedia page again: http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From streiner at cluebyfour.org Tue Mar 1 08:42:43 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 1 Mar 2011 09:42:43 -0500 (EST) Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> Message-ID: On Tue, 1 Mar 2011, George Bonser wrote: > Note to providers: That might have worked a couple of years ago but > when we hear that today, we know it is false. Please be honest in your > responses to that question. If you aren't going to deploy it for > another year or two, just say so. The notion that we are the very first > ones to ever ask for it from a global provider in a major country is > just lame. I would also recommend that the sales organizations of those providers be provided with some level of training and/or coordination with their SEs and technical groups to understand what people are talking about when someone asks about that "eye-pee-vee-six" thing. Another common complaint has been getting different (often contradictory) responses from different salescritters. jms From frnkblk at iname.com Tue Mar 1 23:55:16 2011 From: frnkblk at iname.com (Frank Bulk) Date: Tue, 1 Mar 2011 23:55:16 -0600 Subject: What vexes VoIP users? In-Reply-To: <4D6D0402.7020404@ispalliance.net> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> <4D6D0402.7020404@ispalliance.net> Message-ID: <005a01cbd89e$67c22440$37466cc0$@iname.com> Scott: Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? Frank -----Original Message----- From: Scott Helms [mailto:khelms at ispalliance.net] Sent: Tuesday, March 01, 2011 8:35 AM To: nanog at nanog.org Subject: Re: What vexes VoIP users? offered through the various broadband providers I have had. > Let us be clear: if you're getting "digital telephone" service from a > cable television provider, it is *not* "VoIP", in the usage in which > most speakers mean that term -- "Voice Over Internet" is what they should > be saying, and cable-phone isn't that; the voice traffic rides over a > separate DOCSiS channel, protected from both the Internet and CATV > traffic on the link. > No, this incorrect. Packet Cable most certainly _is_ VOIP (a MGCP variant to be precise until 2.0 after which it is SIP). While a few providers, usually for non-technical reasons, did deploy an entirely separate set of downstream and upstream interfaces that is far from the norm. AFAIK the only top 20 MSO to do so in scale was Charter and I don't know if they continue that today. Comcast, the largest cable telephone provider certainly does not nor do providers need to since any Packetcable CMTS and EMTA combo offers reliable prioritization in the same channel(s) as the normal data path. > So of course Vonage and other VoN products will be less rugged. > > As I recall, this questionably fair competitive advantage has been > looked into by ... someone. (Cablecos won't permit competing VoIP > services to utilize this protected channel, somewhere between "generally" > and "ever".) As I said, this second channel doesn't exist in almost all cases (its not cost effective nor needed in almost all cases). Having said that over the top VOIP providers do suffer in comparison because they don't get the benefit of prioritization in the local cable plant. > Cheers, > -- jra > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From frnkblk at iname.com Wed Mar 2 00:00:47 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 2 Mar 2011 00:00:47 -0600 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <01f001cbd86f$2bc79260$8356b720$@com> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> <16290139.211.1299014203066.JavaMail.franck@franck-martins-macbook-pro.local> <01f001cbd86f$2bc79260$8356b720$@com> Message-ID: <005b01cbd89f$2cf03310$86d09930$@iname.com> I'm extremely annoyed by the marketing PR of those professional service arms when their transit/service provide business doesn't have IPv6 fully deployed. Please have your own house in order first, or be more humble about your services, please. Frank -----Original Message----- From: -Hammer- [mailto:bhmccie at gmail.com] Sent: Tuesday, March 01, 2011 6:17 PM To: 'Franck Martin'; 'George Bonser' Cc: 'NANOG list' Subject: RE: IPv6? Why, you are the first one to ask for it! I don't know about that. Even though the carriers (USA) I've talked to are having trouble presenting native IPv6 to me in the next few quarters, they have no problem pitching professional services to help me with the implementation. Several of my hardware vendors have too. Don't be surprised at all to see this presented to senior management as a new revenue stream. "Helping the inept prepare for tomorrow". -Hammer- "I was a normal American nerd." -Jack Herer -----Original Message----- From: Franck Martin [mailto:franck at genius.com] Sent: Tuesday, March 01, 2011 3:17 PM To: George Bonser Cc: NANOG list Subject: Re: IPv6? Why, you are the first one to ask for it! Don't forget there is no commission for the salesperson to enable IPv6 for you, so definitively they are not interested and you asking them to deal with the issue, will just lower their pay at the end of the month because they could not use this valuable time to find customers with commissions... ----- Original Message ----- > From: "George Bonser" > To: "NANOG list" > Sent: Tuesday, 1 March, 2011 9:39:33 AM > Subject: IPv6? Why, you are the first one to ask for it! > Fairly major global network provider likes to call themselves a "Tier > 1". Asking about native IPv6 in one of their colo facilities in the > UK. > They say their US facilities won't be v6 capable until Q4 2011. The UK > rep acted like it was the first he'd ever heard of it and implied we > were the very first to ask for it. > > Note to providers: That might have worked a couple of years ago but > when we hear that today, we know it is false. Please be honest in your > responses to that question. If you aren't going to deploy it for > another year or two, just say so. The notion that we are the very > first > ones to ever ask for it from a global provider in a major country is > just lame. > > George From gih at apnic.net Wed Mar 2 00:20:04 2011 From: gih at apnic.net (Geoff Huston) Date: Wed, 2 Mar 2011 17:20:04 +1100 Subject: Request for assistance with BGP feeds In-Reply-To: <6F4C56FC-BFF4-4E41-87DB-BA58817C6A4C@apnic.net> References: <6F4C56FC-BFF4-4E41-87DB-BA58817C6A4C@apnic.net> Message-ID: thanks heaps everyone - I'm now well provisioned - now to configure them all! Geoff On 02/03/2011, at 1:53 PM, Geoff Huston wrote: > Hi > > I am conducting some research relating to BGP behaviour and I need some eBGP multihop feeds - IPv4 and/or IPv6 eBGP, and full eBGP route table feeds please. These are incoming feeds only (I will be announcing _nothing_ back in these sessions - I'll filtering outbound and you should defensively filter inbound of course). I am looking at the real time behaviour of BGP updates in a relatively dense multi-peer environment, which is why I am looking for a number of full route feeds. > > Please drop me a note if you can assist me with this activity. > > Thanks in advance, > > Geoff > > > > -- > > Geoff Huston > APNIC > > > > > -- Geoff Huston Chief Scientist, APNIC +61 7 3858 3100 gih at apnic.net From owen at delong.com Wed Mar 2 01:50:37 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 1 Mar 2011 23:50:37 -0800 Subject: What vexes VoIP users? In-Reply-To: <32446190.666.1299038518678.JavaMail.root@benjamin.baylink.com> References: <32446190.666.1299038518678.JavaMail.root@benjamin.baylink.com> Message-ID: <5027BA67-0B67-4954-990A-8B40152C7663@delong.com> On Mar 1, 2011, at 8:01 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Bret Palsson" > >> VoN? Didn't know there was a difference. Same protocols, same >> RTP,RTCP, Codecs, DSCP values. Am I missing something? > > Well, you try to hold a conversation with someone while there's Torrent > traffic going on on the same link, using a third-party SIP provider, and > you tell *me* how that works out... > > Cheers, > -- jra It's worked out great for me in a number of places. OTOH, it was kind of dicey even without the torrents from other places. I found that bandwidth and jitter were the bigger issues than other applications I was sharing the link with. I even managed to get passable call quality (though far from ideal) calling the US on a US third party provider from my soft-phone on my laptop from Kigali, Rwanda. I think that's close to a worst case scenario, frankly. These days, voice is a very low-bandwidth service. On any decent link, it seems to get through just fine. Owen From lars.eggert at nokia.com Wed Mar 2 02:29:10 2011 From: lars.eggert at nokia.com (Lars Eggert) Date: Wed, 2 Mar 2011 10:29:10 +0200 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <4D6DB37A.2090702@gmail.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> <4D6D30D9.6040502@paulgraydon.co.uk> <1299010028.9363.14.camel@Decaf.NEEBU.Net> <4D6DB37A.2090702@gmail.com> Message-ID: <0FA84A4A-919C-4644-84EE-92AF1342260F@nokia.com> On 2011-3-2, at 5:03, JC Dill wrote: > You can use their reply to an IPv6 request as a bit of a bozo filter A senior technical person at my local (consumer) ISP here just told me that their IPv6 plans are "at an early stage" and "lots of work has to be done" before they can start testing. (I asked if they had plans for a friendly user test I could join.) He also said that they understand that IPv6 is not ready because OS vendors have not implemented IPsec. Talk about a bozo filter... Lars PS: ISP is DNA/Welho. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4367 bytes Desc: not available URL: From peter.rudasingwa at altechstream.rw Wed Mar 2 02:46:03 2011 From: peter.rudasingwa at altechstream.rw (Peter Rudasingwa) Date: Wed, 02 Mar 2011 10:46:03 +0200 Subject: Postfix spam Message-ID: <4D6E03CB.9060702@altechstream.rw> Hello, I am being attacked by a lot of spams on my postfix box. What is the best way to block them and fix this for good? It is so bad some of my IPs have been black listed. Thanks for your help. -- Best Regards, Peter R. *** * From ops.lists at gmail.com Wed Mar 2 02:53:53 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Wed, 2 Mar 2011 14:23:53 +0530 Subject: Postfix spam In-Reply-To: <4D6E03CB.9060702@altechstream.rw> References: <4D6E03CB.9060702@altechstream.rw> Message-ID: MAAWG best practices - please see http://www.maawg.org for several best practice documents. If your IPs are getting blacklisted - they are emitting spam. Please email me offlist and I'll try to help you with some suggestions On Wed, Mar 2, 2011 at 2:16 PM, Peter Rudasingwa wrote: > > I am being attacked by a lot of spams on my postfix box. What is the best > way to block them and fix this for good? > > It is so bad some of my IPs have been black listed. -- Suresh Ramasubramanian (ops.lists at gmail.com) From lists at memetic.org Wed Mar 2 03:59:11 2011 From: lists at memetic.org (Adam Armstrong) Date: Wed, 02 Mar 2011 09:59:11 +0000 Subject: Failure modes: NAT vs SPI In-Reply-To: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> References: <13040078.4555.1296760192315.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6E14EF.3020200@memetic.org> This thread makes me sad. adam. On 03/02/2011 19:09, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" >> On Feb 3, 2011, at 8:29 AM, Jay Ashworth wrote: >>> This is the crux of the argument I've been trying, rather ineptly, >>> to make: when it breaks, *which way does it fail*. NAT fails safe, >>> generally. >>> >> So does any decent stateful inspection firewall. That's why your >> argument doesn't hold water. > Perhaps we disagree on the definition of "decent". > > An SPI Firewall is code, running on a router. It drops packets which should > not otherwise be routed by the base routing code running on that router, > which knows how to reach the internal network's addresses, and packets are > sent to it from the Net-at-large. > > In the NAT4 case, those internal addresses are unknown to the NAL, and the > NAT code, as configured by the person operating the edge router, is the only > way for packets to get into the LAN; if the NAT code falls over on the router, > then packets cannot get in, since the outside world *cannot get packets to > that router with addresses which it will further route inbound*. > > That's the expansion of "fails safe". > > Let us now examine the alternate case. > > In this case, that original SPI case I mentioned above, we're assuming > routable addresses behind that firewall -- that is, the NAL *does* know > how to aim packets at a *specific host inside my LAN*. > > Those packets get to my edge router, and the SPI firewall drops the > appropriate packets before they're actually handed to the routing core, > and sent inwards. > > If the firewall code fails or is inadvertanly turned off, what happens? > > Why, the router does what it's designed for, it routes. Those external > packets. In, to my hosts. With no firewall in the way. > > Sorry to have to show my work, but that's my work: please explain how > you feel that those two situations do *not* make NAT safer in the edge > case where an SPI firewall fails in such a fashion as not to drop the > packets asked of it? > > All that's necessary to cause that failure is to say "turn it off", whereas > causing a comparable failure on the NAT side requires *defining specific new > rules that target specific internal hosts by IP address*, which is a > much more complex task, which effectively cannot be accomplished by > accident, unlike accidentally disabling a firewall. > > Cheers, > -- jra > From lists at memetic.org Wed Mar 2 04:19:32 2011 From: lists at memetic.org (Adam Armstrong) Date: Wed, 02 Mar 2011 10:19:32 +0000 Subject: Switch with 24x SFP PVLAN QinQ Layer 2 Message-ID: <4D6E19B4.3020204@memetic.org> Hi All, I'm scouring the Internet for potential devices to use in a FTTB/FTTP scenario. Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Has anyone come across anything I've not found yet? Thanks, adam. From alexb at ripe.net Wed Mar 2 04:29:18 2011 From: alexb at ripe.net (Alex Band) Date: Wed, 2 Mar 2011 11:29:18 +0100 Subject: Video explaining [RPKI] Resource Certification Message-ID: Under the NRO flag, we have just released a short video about Resource Certification, giving a high-level explanation of what it is and why it is important for your organisation: http://youtu.be/rH3CPosGNjY I hope to release another video going into more detail, outlining what it means practically for an operator. To get an idea of the practical side for now, here is a video we released earlier on how to set up and use the hosted Resource Certification service the RIPE NCC provides: http://youtu.be/Q0C0kEYa1d8 Kind regards, Alex Band Product Manager, RIPE NCC From a.harrowell at gmail.com Wed Mar 2 04:55:21 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 2 Mar 2011 10:55:21 +0000 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <4D6DB37A.2090702@gmail.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> <1299010028.9363.14.camel@Decaf.NEEBU.Net> <4D6DB37A.2090702@gmail.com> Message-ID: <201103021055.32401.a.harrowell@gmail.com> On Wednesday 02 March 2011 03:03:22 JC Dill wrote: > > I *love* using Bozo filters. Anytime you can trick companies into > revealing their true colors, you are a step ahead in the game. > > jc > AKA the Brown M&M gambit. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From mysidia at gmail.com Wed Mar 2 08:11:08 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 2 Mar 2011 08:11:08 -0600 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <16290139.211.1299014203066.JavaMail.franck@franck-martins-macbook-pro.local> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> <16290139.211.1299014203066.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Tue, Mar 1, 2011 at 3:16 PM, Franck Martin wrote: > Don't forget there is no commission for the salesperson to enable IPv6 for you, so definitively they are not interested and you asking them to deal with the issue, will just lower their pay at the end of the month because they could not use this valuable time to find customers with commissions... Well, if there is a sale to be made at all, and IPv6 is a requirement for that particular sale, then any (other) commission is dependant on enabling IPv6. So if you need to buy IPv6, make it a required condition before you agree to buy service, or let them know that $other_big_provider is offering IPv6. Sale = Possible commission. No sale = No commission, period. "You were the very first to ask for it." Sounds like an excuse to me. No "excuse" validates a complete lack of cognisance of IPv6 at this point. Providers have had plenty of time to train their sales staff. One can only hope their technical staff are ready to deal with any IPv6 connectivity issues... "You were the very first to ask for it" does not instill much confidence or make a good impression of the provider, even if IPv6 does turn out to be available from them. -- -Jh From jra at baylink.com Wed Mar 2 08:23:09 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 2 Mar 2011 09:23:09 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <4D6DC8CA.6090803@mtcc.com> Message-ID: <16929916.734.1299075789369.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Thomas" > Yes, really. The only difference was which L2 channels the RTP > packets were flowed onto, which was determined by the MGCP/SIP > signalling and interaction with the telephony gateway. There > is a **very** complicated state machine that deals with this > using some bastardized IETF protocols (COPS IIRC). Ok, see, now I (like, I suspect, Frank Bulk) am confused again: when you say "which L2 channels the RTP packets were flowed onto", that sounds to me a *whole* lot like "which VLAN on the end-user drop carried the RTP packets from the terminal adapter in their cable box to our concentrator"... which is pretty much the point I was originally trying to make, if perhaps in slightly different terms. Am I still misunderstanding you? Cheers, -- jra From ncolton at allophone.net Wed Mar 2 09:16:52 2011 From: ncolton at allophone.net (Nick Colton) Date: Wed, 2 Mar 2011 08:16:52 -0700 Subject: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: <4D6E19B4.3020204@memetic.org> References: <4D6E19B4.3020204@memetic.org> Message-ID: Adam, Have you looked at the Calix E7 platform or the Adtran TA5000? Both are Layer 2 only. Nick Colton Allo Communications On Wed, Mar 2, 2011 at 3:19 AM, Adam Armstrong wrote: > Hi All, > > I'm scouring the Internet for potential devices to use in a FTTB/FTTP > scenario. > > Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. > Most devices that fit the requirements are Layer 3, which pushes the cost > per port too high. > > Has anyone come across anything I've not found yet? > > Thanks, > adam. > > From khelms at ispalliance.net Wed Mar 2 09:21:46 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 02 Mar 2011 10:21:46 -0500 Subject: What vexes VoIP users? In-Reply-To: <2039035.658.1299037908960.JavaMail.root@benjamin.baylink.com> References: <2039035.658.1299037908960.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6E608A.9000904@ispalliance.net> >> As I said, this second channel doesn't exist in almost all cases (its >> not cost effective nor needed in almost all cases). Having said that >> over the top VOIP providers do suffer in comparison because they don't >> get the benefit of prioritization in the local cable plant. > "Cost-effective"? > > Could you expand on how the provisioning of a second virtual pipe down > the hill to a cable box has any incremental costs at all? > > Cheers, > -- jra > > Because it takes either another 6 MHz on the downstream side that could be used for a TV channel as well as 3.2 MHz (or 6.4 MHz for >=D2) on the upstream side. It also takes the CMTS interfaces, which are not cheap even with the advent of high capacity cards & QAMs for D3. On top of all this it also takes more time on the design and management side because you have to make sure all of your nodes are getting both sets of channels and you have to make sure your provisioning or CMTS config keeps the EMTA's on the right channels. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From MGauvin at dryden.ca Wed Mar 2 09:22:43 2011 From: MGauvin at dryden.ca (Mark Gauvin) Date: Wed, 2 Mar 2011 09:22:43 -0600 Subject: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: References: <4D6E19B4.3020204@memetic.org> Message-ID: <4DEA063ACE629740877D59B74D6FB26423FF122398@exchange.citydryden.local> Rad ETX 1002 and ETX 201A as CPE -----Original Message----- From: Nick Colton [mailto:ncolton at allophone.net] Sent: Wednesday, March 02, 2011 9:17 AM To: Adam Armstrong Cc: nanog at nanog.org Subject: Re: Switch with 24x SFP PVLAN QinQ Layer 2 Adam, Have you looked at the Calix E7 platform or the Adtran TA5000? Both are Layer 2 only. Nick Colton Allo Communications On Wed, Mar 2, 2011 at 3:19 AM, Adam Armstrong wrote: > Hi All, > > I'm scouring the Internet for potential devices to use in a FTTB/FTTP > scenario. > > Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. > Most devices that fit the requirements are Layer 3, which pushes the cost > per port too high. > > Has anyone come across anything I've not found yet? > > Thanks, > adam. > > From khelms at ispalliance.net Wed Mar 2 09:26:33 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 02 Mar 2011 10:26:33 -0500 Subject: What vexes VoIP users? In-Reply-To: <005a01cbd89e$67c22440$37466cc0$@iname.com> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> <4D6D0402.7020404@ispalliance.net> <005a01cbd89e$67c22440$37466cc0$@iname.com> Message-ID: <4D6E61A9.4010405@ispalliance.net> Frank, No, not all. There seems to be some confusion here between the concept of PacketCable flows which everyone _should_ (but aren't) be using to prioritize their voice traffic and separate downstream and upstream channels which a few operators use for voice traffic only. On 3/2/2011 12:55 AM, Frank Bulk wrote: > Scott: > > Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? > > Frank -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From eschoedler at viavale.com.br Wed Mar 2 09:35:49 2011 From: eschoedler at viavale.com.br (Eduardo Schoedler) Date: Wed, 2 Mar 2011 12:35:49 -0300 Subject: RES: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: <4D6E19B4.3020204@memetic.org> References: <4D6E19B4.3020204@memetic.org> Message-ID: We bought Extreme Networks Summit x350 for FTTx purposes. -- Eduardo Schoedler > -----Mensagem original----- > De: Adam Armstrong [mailto:lists at memetic.org] > Enviada em: quarta-feira, 2 de mar?o de 2011 07:20 > Para: nanog at nanog.org > Assunto: Switch with 24x SFP PVLAN QinQ Layer 2 > > Hi All, > > I'm scouring the Internet for potential devices to use in a FTTB/FTTP > scenario. > > Requirements are basically just 24/48 SFP ports, PVLAN and selective > QinQ. Most devices that fit the requirements are Layer 3, which pushes > the cost per port too high. > > Has anyone come across anything I've not found yet? > > Thanks, > adam. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6506 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Mar 2 09:40:11 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 02 Mar 2011 10:40:11 -0500 Subject: What vexes VoIP users? In-Reply-To: Your message of "Tue, 01 Mar 2011 23:55:16 CST." <005a01cbd89e$67c22440$37466cc0$@iname.com> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> <4D6D0402.7020404@ispalliance.net> <005a01cbd89e$67c22440$37466cc0$@iname.com> Message-ID: <7513.1299080411@localhost> On Tue, 01 Mar 2011 23:55:16 CST, Frank Bulk said: > Are you saying that the large MSOs don't use CM configuration files that > create separate downstream and upstream service flows for Internet, > voice signaling, and voice bearer traffic? So the cable company carves out a protected flow for its own triple-play telephone, while third-party VoIP vendors have to contend on the Internet flow? Why aren't the net-neutrality people busy having a cow over this? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From ernesto at cs.fiu.edu Wed Mar 2 09:55:51 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Wed, 2 Mar 2011 10:55:51 -0500 Subject: Issues with 23.1.64.0/20? Message-ID: <14783185-70A9-4223-B034-7A31D6721B89@cs.fiu.edu> Anyone else see anything / know of any odd behavior on the prefix yesterday afternoon/today? Here in Miami (NAP) we saw some issues through one of our upstreams and ended up disabling the BGP session, then re-enabling it with a filter to block said prefix. We've since removed the filter and things are stable but would be nice to know what broke 'out there.' Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From khelms at ispalliance.net Wed Mar 2 10:15:43 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 02 Mar 2011 11:15:43 -0500 Subject: What vexes VoIP users? In-Reply-To: <25289587.644.1299036822117.JavaMail.root@benjamin.baylink.com> References: <25289587.644.1299036822117.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6E6D2F.1000807@ispalliance.net> > "What everyone is actually *selling* commercially, except for cable > providers, is *not* VoIP; it's a subset of that: VoN; Voice Over Internet; > where the IP transport *goes over the public internet*, and through > whatever exchange points may be necessary to get from you to the > provider. Hmm, I don't know if this is a useful distinction. I do know that is not the common usage for VoN. VoN is more commonly understood to be Voice over Network which is a superset of VOIP rather than a subset. http://en.wikipedia.org/wiki/Voip http://bit.ly/f9u08K > Cable companies are selling you *one hop* (maybe 2 or 3; certainly not > 12-18), over a link with bandwidth protected from whatever may be > going on on the Internet IP link they're also selling you; and which is > therefore guaranteed to have better quality than whatever "VoIP" service > it might be competing with." That also depends. While the most common method for cable operators is Packet Cable using dedicated links to and from the softswitch/session border controller that is by no means universal. Here are two companies I know of that specialize in selling pure SIP solutions, which are often back hauled across the public Internet. http://xcastlabs.com/ https://www.momentumtelecom.com/ > I wasn't suggesting QOS. I was suggesting *there's a completely separate > pipe*, on non-Internet connected IP transport, carrying only the > voice traffic, directly to a termination point, which is dedicated > from the triple-play box and nailed up. > > Are you suggesting that's *not* how it's being done in production? In some cases, there is a dedicated connection to the underlying MGCP/SIP network and in others there is not. In some cases there is an MPLS connection with QoS over the public Internet and in others there is prioritization at all. (I don't recommend the latter, but its usually an economic issue.) > Cheers, > -- jra > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at ispalliance.net Wed Mar 2 10:18:00 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 02 Mar 2011 11:18:00 -0500 Subject: What vexes VoIP users? In-Reply-To: <7513.1299080411@localhost> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> <4D6D0402.7020404@ispalliance.net> <005a01cbd89e$67c22440$37466cc0$@iname.com> <7513.1299080411@localhost> Message-ID: <4D6E6DB8.7000208@ispalliance.net> On 3/2/2011 10:40 AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 01 Mar 2011 23:55:16 CST, Frank Bulk said: >> Are you saying that the large MSOs don't use CM configuration files that >> create separate downstream and upstream service flows for Internet, >> voice signaling, and voice bearer traffic? > So the cable company carves out a protected flow for its own triple-play > telephone, while third-party VoIP vendors have to contend on the Internet flow? > Why aren't the net-neutrality people busy having a cow over this? > You mean besides the fact that most of the net neutrality wonks don't know nor want to know how stuff works? -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From jcdill.lists at gmail.com Wed Mar 2 10:22:33 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Wed, 02 Mar 2011 08:22:33 -0800 Subject: IPv6? Why, you are the first one to ask for it! In-Reply-To: <201103021055.32401.a.harrowell@gmail.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13E34@RWC-EX1.corp.seven.com> <1299010028.9363.14.camel@Decaf.NEEBU.Net> <4D6DB37A.2090702@gmail.com> <201103021055.32401.a.harrowell@gmail.com> Message-ID: <4D6E6EC9.20507@gmail.com> On 02/03/11 2:55 AM, Alexander Harrowell wrote: > On Wednesday 02 March 2011 03:03:22 JC Dill wrote: >> I *love* using Bozo filters. Anytime you can trick companies into >> revealing their true colors, you are a step ahead in the game > AKA the Brown M&M gambit. Exactly! Per Wikipedia: http://en.wikipedia.org/wiki/Rider_%28theater%29#Unreasonable_Requests Van Halen requested in the technical rider that a bowl of M&Ms be provided in their dressing room with the brown ones removed (failure to do so would not only mean that the band would not perform, but the venue would still have to pay the full fee). The objective of this wasn't due to any excesses on the part of the band, but was a method to determine how much attention to detail the crew at a local venue paid to the requests specified in the rider. Should the bowl be absent, or if brown M&Ms were present, it would give band members reason to suspect other, legitimate, technical and safety issues were also being performed poorly or were outright overlooked. David Lee Roth stated in his autobiography that this request was done as a result of faulty workmanship at a venue on an earlier tour which nearly cost the life of a member of Van Halen's road crew, as well as $85,000 damage to the venue and their own equipment. From frnkblk at iname.com Wed Mar 2 10:26:40 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 2 Mar 2011 10:26:40 -0600 Subject: What vexes VoIP users? In-Reply-To: <4D6E61A9.4010405@ispalliance.net> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> <4D6D0402.7020404@ispalliance.net> <005a01cbd89e$67c22440$37466cc0$@iname.com> <4D6E61A9.4010405@ispalliance.net> Message-ID: <011901cbd8f6$9bf72190$d3e564b0$@iname.com> Thanks for clarifying. I can't imagine an MSO using separate DS and US QAMs for their eMTAs. Regardless, the customer's Internet would flow over those same QAMs (unless it was a D3 channel-bonding eMTA, and even then I'm not sure if the CMTS could be provisioned to use one QAM for voice and the remaining QAMs for data). Frank -----Original Message----- From: Scott Helms [mailto:khelms at ispalliance.net] Sent: Wednesday, March 02, 2011 9:27 AM To: frnkblk at iname.com Cc: nanog at nanog.org Subject: Re: What vexes VoIP users? Frank, No, not all. There seems to be some confusion here between the concept of PacketCable flows which everyone _should_ (but aren't) be using to prioritize their voice traffic and separate downstream and upstream channels which a few operators use for voice traffic only. On 3/2/2011 12:55 AM, Frank Bulk wrote: > Scott: > > Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? > > Frank -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From mike at mtcc.com Wed Mar 2 10:36:08 2011 From: mike at mtcc.com (Michael Thomas) Date: Wed, 02 Mar 2011 08:36:08 -0800 Subject: What vexes VoIP users? In-Reply-To: <16929916.734.1299075789369.JavaMail.root@benjamin.baylink.com> References: <16929916.734.1299075789369.JavaMail.root@benjamin.baylink.com> Message-ID: <4D6E71F8.10909@mtcc.com> On 03/02/2011 06:23 AM, Jay Ashworth wrote: > ----- Original Message ----- > >> From: "Michael Thomas" >> > >> Yes, really. The only difference was which L2 channels the RTP >> packets were flowed onto, which was determined by the MGCP/SIP >> signalling and interaction with the telephony gateway. There >> is a **very** complicated state machine that deals with this >> using some bastardized IETF protocols (COPS IIRC). >> > Ok, see, now I (like, I suspect, Frank Bulk) am confused again: > > when you say "which L2 channels the RTP packets were flowed onto", that > sounds to me a *whole* lot like "which VLAN on the end-user drop carried > the RTP packets from the terminal adapter in their cable box to our > concentrator"... which is pretty much the point I was originally trying > to make, if perhaps in slightly different terms. > > Am I still misunderstanding you? > They're kind of like VLAN's, but not exactly. It's been a long time since I worked on this... The RTP is flowed over what is called unsolicited grants (UGS) which give slots on the upstream for transmission. There are several other types of qos treatment between the CM and CMTS... I think that packetcable flows the MGCP and SIP over nrt-PS, but I might be misremembering. The signalling between the CM (MTA) and CMS (eg MGCP) is what fields the requests for better qos treatment for the RTP stream, and the CMS talks to the CMTS via COPS to set up the UGS flows to the cable modem/voice box (ie, an embedded MTA). In any case, this is 100% IP end to end, with all kinds of goodies for LEA and privacy to boot, which make the entire problem of faithfully reproducing the PSTN over IP a giant headache. Mike, I should know about the LEA aspect since I was the first one at Cisco to find and then dutifully step on that mine From frnkblk at iname.com Wed Mar 2 10:47:04 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 2 Mar 2011 10:47:04 -0600 Subject: What vexes VoIP users? In-Reply-To: <7513.1299080411@localhost> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> <4D6D0402.7020404@ispalliance.net> <005a01cbd89e$67c22440$37466cc0$@iname.com> <7513.1299080411@localhost> Message-ID: <011d01cbd8f9$75ca2730$615e7590$@iname.com> Yes, that's how PacketCable works. Here's some CLI output -- nothing like a quick example to make that clear. Here's a customer with 8M/512K Internet service: CMTS:7A#sh cable modem 0008.0ed2.0928 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 1 cable 0/0 Upstream 512000 2 cable 0/0 Downstream 8000000 CMTS:7A# Here's a customer with 128K/128K Internet service and two additional service flows for voice signaling: CMTS:7A#sh cable modem 0013.1192.f867 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 3593 cable 0/1 Upstream 128000 3594 cable 0/1 Upstream 12000 3595 cable 0/1 Downstream 128000 3596 cable 0/1 Downstream 30000 CMTS:7A# And here's a customer with 2M/2M Internet service with a call in progress. Note the additional service flows, with sufficient bandwidth and overhead for a G.711 call. CMTS:7A#show cable modem 0015.a275.efd3 svc-flow-id Service flow id Interface Flow Direction Flow Max Rate 4425 cable 1/1 Upstream 2048000 4426 cable 1/1 Upstream 12000 4427 cable 1/1 Downstream 2048000 4428 cable 1/1 Downstream 30000 8745 cable 1/1 Upstream 92800 29314 cable 1/1 Downstream 87200 CMTS:7A# Remember, PacketCable is not Internet VoIP and I don't think any MSO has claimed it is such. It doesn't run over the Internet connection and is not given priority within the Internet flow. That's why there should be no net neutrality concerns. Frank -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Wednesday, March 02, 2011 9:40 AM To: frnkblk at iname.com Cc: 'Scott Helms'; nanog at nanog.org Subject: Re: What vexes VoIP users? On Tue, 01 Mar 2011 23:55:16 CST, Frank Bulk said: > Are you saying that the large MSOs don't use CM configuration files that > create separate downstream and upstream service flows for Internet, > voice signaling, and voice bearer traffic? So the cable company carves out a protected flow for its own triple-play telephone, while third-party VoIP vendors have to contend on the Internet flow? Why aren't the net-neutrality people busy having a cow over this? From khelms at ispalliance.net Wed Mar 2 10:48:55 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 02 Mar 2011 11:48:55 -0500 Subject: What vexes VoIP users? In-Reply-To: <011901cbd8f6$9bf72190$d3e564b0$@iname.com> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> <4D6D0402.7020404@ispalliance.net> <005a01cbd89e$67c22440$37466cc0$@iname.com> <4D6E61A9.4010405@ispalliance.net> <011901cbd8f6$9bf72190$d3e564b0$@iname.com> Message-ID: <4D6E74F7.7030800@ispalliance.net> Frank, It gets better (which is sad) in the case of Charter if a customer ordered voice and data they were given a normal Moto SB for Internet data and a separate Arris eMTA (with no CPEs allowed other than the TA and the Ethernet port disabled) for voice. The channels they were using for voice even terminated on a different CMTS altogether. On 3/2/2011 11:26 AM, Frank Bulk wrote: > Thanks for clarifying. I can't imagine an MSO using separate DS and US QAMs for their eMTAs. Regardless, the customer's Internet would flow over those same QAMs (unless it was a D3 channel-bonding eMTA, and even then I'm not sure if the CMTS could be provisioned to use one QAM for voice and the remaining QAMs for data). > > Frank > > -----Original Message----- > From: Scott Helms [mailto:khelms at ispalliance.net] > Sent: Wednesday, March 02, 2011 9:27 AM > To: frnkblk at iname.com > Cc: nanog at nanog.org > Subject: Re: What vexes VoIP users? > > Frank, > > No, not all. There seems to be some confusion here between the > concept of PacketCable flows which everyone _should_ (but aren't) be > using to prioritize their voice traffic and separate downstream and > upstream channels which a few operators use for voice traffic only. > > On 3/2/2011 12:55 AM, Frank Bulk wrote: >> Scott: >> >> Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? >> >> Frank -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From mike at mtcc.com Wed Mar 2 10:50:44 2011 From: mike at mtcc.com (Michael Thomas) Date: Wed, 02 Mar 2011 08:50:44 -0800 Subject: What vexes VoIP users? In-Reply-To: <5027BA67-0B67-4954-990A-8B40152C7663@delong.com> References: <32446190.666.1299038518678.JavaMail.root@benjamin.baylink.com> <5027BA67-0B67-4954-990A-8B40152C7663@delong.com> Message-ID: <4D6E7564.4050009@mtcc.com> On 03/01/2011 11:50 PM, Owen DeLong wrote: > It's worked out great for me in a number of places. OTOH, it was kind > of dicey even without the torrents from other places. > > I found that bandwidth and jitter were the bigger issues than other > applications I was sharing the link with. > > I even managed to get passable call quality (though far from ideal) > calling the US on a US third party provider from my soft-phone on > my laptop from Kigali, Rwanda. I think that's close to a worst case > scenario, frankly. > > These days, voice is a very low-bandwidth service. On any decent > link, it seems to get through just fine. > Right, if it wasn't skype would be useless which it manifestly isn't. Which is why all the heavy machinery to dynamically provision qos for the rtp flows was, per typical, overwhelmed by moore's law. I floated that heresy about 10 years ago, but by then there was too much invested in seeing it through. Mike, skype shows you can do all manner of horrible things and still work... real time media over tcp! From frnkblk at iname.com Wed Mar 2 10:51:44 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 2 Mar 2011 10:51:44 -0600 Subject: What vexes VoIP users? In-Reply-To: <4D6E71F8.10909@mtcc.com> References: <16929916.734.1299075789369.JavaMail.root@benjamin.baylink.com> <4D6E71F8.10909@mtcc.com> Message-ID: <011e01cbd8fa$1cc112b0$56433810$@iname.com> The service class for the bearer stream, at least on modern configurations with Moto, is "DefVoiceDown" and "DefUGS". The signaling is DefRRDown and DefRRUp. MSOs may create different service classes with unique names, so our (plain vanilla configuration which uses the default names) may not be representative of other implementations. Frank -----Original Message----- From: Michael Thomas [mailto:mike at mtcc.com] Sent: Wednesday, March 02, 2011 10:36 AM To: Jay Ashworth Cc: NANOG Subject: Re: What vexes VoIP users? On 03/02/2011 06:23 AM, Jay Ashworth wrote: > ----- Original Message ----- > >> From: "Michael Thomas" >> > >> Yes, really. The only difference was which L2 channels the RTP >> packets were flowed onto, which was determined by the MGCP/SIP >> signalling and interaction with the telephony gateway. There >> is a **very** complicated state machine that deals with this >> using some bastardized IETF protocols (COPS IIRC). >> > Ok, see, now I (like, I suspect, Frank Bulk) am confused again: > > when you say "which L2 channels the RTP packets were flowed onto", that > sounds to me a *whole* lot like "which VLAN on the end-user drop carried > the RTP packets from the terminal adapter in their cable box to our > concentrator"... which is pretty much the point I was originally trying > to make, if perhaps in slightly different terms. > > Am I still misunderstanding you? > They're kind of like VLAN's, but not exactly. It's been a long time since I worked on this... The RTP is flowed over what is called unsolicited grants (UGS) which give slots on the upstream for transmission. There are several other types of qos treatment between the CM and CMTS... I think that packetcable flows the MGCP and SIP over nrt-PS, but I might be misremembering. The signalling between the CM (MTA) and CMS (eg MGCP) is what fields the requests for better qos treatment for the RTP stream, and the CMS talks to the CMTS via COPS to set up the UGS flows to the cable modem/voice box (ie, an embedded MTA). In any case, this is 100% IP end to end, with all kinds of goodies for LEA and privacy to boot, which make the entire problem of faithfully reproducing the PSTN over IP a giant headache. Mike, I should know about the LEA aspect since I was the first one at Cisco to find and then dutifully step on that mine From frnkblk at iname.com Wed Mar 2 10:52:28 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 2 Mar 2011 10:52:28 -0600 Subject: What vexes VoIP users? In-Reply-To: <4D6E74F7.7030800@ispalliance.net> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> <4D6D0402.7020404@ispalliance.net> <005a01cbd89e$67c22440$37466cc0$@iname.com> <4D6E61A9.4010405@ispalliance.net> <011901cbd8f6$9bf72190$d3e564b0$@iname.com> <4D6E74F7.7030800@ispalliance.net> Message-ID: <011f01cbd8fa$36fb17c0$a4f14740$@iname.com> Wow, I was not aware of that, what a management and maintenance nightmare. Do they still do this? Frank -----Original Message----- From: Scott Helms [mailto:khelms at ispalliance.net] Sent: Wednesday, March 02, 2011 10:49 AM To: frnkblk at iname.com Cc: nanog at nanog.org Subject: Re: What vexes VoIP users? Frank, It gets better (which is sad) in the case of Charter if a customer ordered voice and data they were given a normal Moto SB for Internet data and a separate Arris eMTA (with no CPEs allowed other than the TA and the Ethernet port disabled) for voice. The channels they were using for voice even terminated on a different CMTS altogether. On 3/2/2011 11:26 AM, Frank Bulk wrote: > Thanks for clarifying. I can't imagine an MSO using separate DS and US QAMs for their eMTAs. Regardless, the customer's Internet would flow over those same QAMs (unless it was a D3 channel-bonding eMTA, and even then I'm not sure if the CMTS could be provisioned to use one QAM for voice and the remaining QAMs for data). > > Frank > > -----Original Message----- > From: Scott Helms [mailto:khelms at ispalliance.net] > Sent: Wednesday, March 02, 2011 9:27 AM > To: frnkblk at iname.com > Cc: nanog at nanog.org > Subject: Re: What vexes VoIP users? > > Frank, > > No, not all. There seems to be some confusion here between the > concept of PacketCable flows which everyone _should_ (but aren't) be > using to prioritize their voice traffic and separate downstream and > upstream channels which a few operators use for voice traffic only. > > On 3/2/2011 12:55 AM, Frank Bulk wrote: >> Scott: >> >> Are you saying that the large MSOs don't use CM configuration files that create separate downstream and upstream service flows for Internet, voice signaling, and voice bearer traffic? >> >> Frank -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From khelms at ispalliance.net Wed Mar 2 11:07:21 2011 From: khelms at ispalliance.net (Scott Helms) Date: Wed, 02 Mar 2011 12:07:21 -0500 Subject: What vexes VoIP users? In-Reply-To: <011f01cbd8fa$36fb17c0$a4f14740$@iname.com> References: <33345132.498.1298987511821.JavaMail.root@benjamin.baylink.com> <4D6D0402.7020404@ispalliance.net> <005a01cbd89e$67c22440$37466cc0$@iname.com> <4D6E61A9.4010405@ispalliance.net> <011901cbd8f6$9bf72190$d3e564b0$@iname.com> <4D6E74F7.7030800@ispalliance.net> <011f01cbd8fa$36fb17c0$a4f14740$@iname.com> Message-ID: <4D6E7949.90903@ispalliance.net> Frank, I hope not, but the sales guy I knew (he was the one who sold all of the VOIP only CMTSs) is in a different field now. Their architecture was crummy and their reasoning for doing obtuse, but my friend was happy to sell them the gear. On 3/2/2011 11:52 AM, Frank Bulk wrote: > Wow, I was not aware of that, what a management and maintenance nightmare. Do they still do this? > > Frank > > -----Original Message----- > From: Scott Helms [mailto:khelms at ispalliance.net] > Sent: Wednesday, March 02, 2011 10:49 AM > To: frnkblk at iname.com > Cc: nanog at nanog.org > Subject: Re: What vexes VoIP users? > > Frank, > > It gets better (which is sad) in the case of Charter if a customer > ordered voice and data they were given a normal Moto SB for Internet > data and a separate Arris eMTA (with no CPEs allowed other than the TA > and the Ethernet port disabled) for voice. The channels they were using > for voice even terminated on a different CMTS altogether. > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From rubensk at gmail.com Wed Mar 2 12:26:16 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Wed, 2 Mar 2011 15:26:16 -0300 Subject: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: <4D6E19B4.3020204@memetic.org> References: <4D6E19B4.3020204@memetic.org> Message-ID: > Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. > Most devices that fit the requirements are Layer 3, which pushes the cost > per port too high. Cisco ME6524 has a model with 32 SFP ports (24 with 3:1 oversubscription, 8 non-oversubscribed) and "IP Base" IOS which has very limited L3 features (RIP and EIGRP stub only), focused on Layer 2 deployments. Rubens From lists at memetic.org Wed Mar 2 12:39:24 2011 From: lists at memetic.org (Adam Armstrong) Date: Wed, 02 Mar 2011 18:39:24 +0000 Subject: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: References: <4D6E19B4.3020204@memetic.org> Message-ID: <4D6E8EDC.303@memetic.org> On 02/03/2011 18:26, Rubens Kuhl wrote: >> Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. >> Most devices that fit the requirements are Layer 3, which pushes the cost >> per port too high. > Cisco ME6524 has a model with 32 SFP ports (24 with 3:1 > oversubscription, 8 non-oversubscribed) and "IP Base" IOS which has > very limited L3 features (RIP and EIGRP stub only), focused on Layer 2 > deployments. Hardware is still ridiculously expensive for purposes. adam. From wschultz at bsdboy.com Wed Mar 2 12:38:07 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Wed, 2 Mar 2011 10:38:07 -0800 Subject: TWTelecom DNS issues... Message-ID: <8DB4C275-A748-4B38-92B5-AA77B80A6DEA@bsdboy.com> ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly stopped serving DNS for domains it's not authoritative for this morning. Requests are being actively refused from within their network. Caused a small issue for us, just thought I'd pass along. -wil From morrowc.lists at gmail.com Wed Mar 2 13:17:13 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 2 Mar 2011 14:17:13 -0500 Subject: TWTelecom DNS issues... In-Reply-To: <8DB4C275-A748-4B38-92B5-AA77B80A6DEA@bsdboy.com> References: <8DB4C275-A748-4B38-92B5-AA77B80A6DEA@bsdboy.com> Message-ID: On Wed, Mar 2, 2011 at 1:38 PM, Wil Schultz wrote: > ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly stopped serving DNS for domains it's not authoritative for this morning. Requests are being actively refused from within their network. > > Caused a small issue for us, just thought I'd pass along. they were recursing previously and are no longer? that seems like a win... or did I misconstrue what you said? From JTyler at fiberutilities.com Wed Mar 2 13:18:47 2011 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Wed, 2 Mar 2011 13:18:47 -0600 Subject: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: <4D6E19B4.3020204@memetic.org> References: <4D6E19B4.3020204@memetic.org> Message-ID: <1A8A762BD508624A8BDAB9F5E1638F945FB4C3BCEE@comsrv01.fg.local> I would take a look at a Ciena 3940 and other models. They look to be cost effective for layer 2 deployments. -----Original Message----- From: Adam Armstrong [mailto:lists at memetic.org] Sent: Wednesday, March 02, 2011 4:20 AM To: nanog at nanog.org Subject: Switch with 24x SFP PVLAN QinQ Layer 2 Hi All, I'm scouring the Internet for potential devices to use in a FTTB/FTTP scenario. Requirements are basically just 24/48 SFP ports, PVLAN and selective QinQ. Most devices that fit the requirements are Layer 3, which pushes the cost per port too high. Has anyone come across anything I've not found yet? Thanks, adam. From jamesbbrown04 at gmail.com Wed Mar 2 13:19:52 2011 From: jamesbbrown04 at gmail.com (James Brown) Date: Wed, 2 Mar 2011 14:19:52 -0500 Subject: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: References: <4D6E19B4.3020204@memetic.org> Message-ID: On Wed, Mar 2, 2011 at 1:26 PM, Rubens Kuhl wrote: > > Requirements are basically just 24/48 SFP ports, PVLAN and selective > QinQ. > > Most devices that fit the requirements are Layer 3, which pushes the cost > > per port too high. > > Cisco ME6524 has a model with 32 SFP ports (24 with 3:1 > oversubscription, 8 non-oversubscribed) and "IP Base" IOS which has > very limited L3 features (RIP and EIGRP stub only), focused on Layer 2 > deployments. > > > Rubens > > The ME3600X might be more a more appropriate Cisco solution than the ME6524. The ME3600X is one of the current metro MDU access CPE device of choice. 2x10GE and 24xGE SFP or Copper versions with Metro Feature set. http://www.cisco.com/en/US/products/ps10956/index.html *In the spirit of full disclosure I am biased towards this vendor From lists at memetic.org Wed Mar 2 13:39:40 2011 From: lists at memetic.org (Adam Armstrong) Date: Wed, 02 Mar 2011 19:39:40 +0000 Subject: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: References: <4D6E19B4.3020204@memetic.org> Message-ID: <4D6E9CFC.3030700@memetic.org> On 02/03/2011 19:19, James Brown wrote: > > > On Wed, Mar 2, 2011 at 1:26 PM, Rubens Kuhl > wrote: > > > Requirements are basically just 24/48 SFP ports, PVLAN and > selective QinQ. > > Most devices that fit the requirements are Layer 3, which pushes > the cost > > per port too high. > > Cisco ME6524 has a model with 32 SFP ports (24 with 3:1 > oversubscription, 8 non-oversubscribed) and "IP Base" IOS which has > very limited L3 features (RIP and EIGRP stub only), focused on Layer 2 > deployments. > > > Rubens > > The ME3600X might be more a more appropriate Cisco solution than the > ME6524. The ME3600X is one of the current metro MDU access CPE device > of choice. > > 2x10GE and 24xGE SFP or Copper versions with Metro Feature set. > > http://www.cisco.com/en/US/products/ps10956/index.html > > *In the spirit of full disclosure I am biased towards this vendor Still much too expensive :) adam. From wschultz at bsdboy.com Wed Mar 2 13:42:32 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Wed, 2 Mar 2011 11:42:32 -0800 Subject: TWTelecom DNS issues... In-Reply-To: References: <8DB4C275-A748-4B38-92B5-AA77B80A6DEA@bsdboy.com> Message-ID: <07EE9A15-CED3-431A-A80D-B7A126E29DB7@bsdboy.com> On Mar 2, 2011, at 11:17 AM, Christopher Morrow wrote: > On Wed, Mar 2, 2011 at 1:38 PM, Wil Schultz wrote: >> ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly stopped serving DNS for domains it's not authoritative for this morning. Requests are being actively refused from within their network. >> >> Caused a small issue for us, just thought I'd pass along. > > they were recursing previously and are no longer? that seems like a > win... or did I misconstrue what you said? They definitely do use ns1.twtelecom.net and ns2.twtelecom.net for hosting purposes (which probably shouldn't recurse), but they also generically recommend their clients to use them for recursion. Whatever the issue, all of their DNS servers that I tested lost the ability to recurse for about an hour. They are *mostly* working at this point, but not consistently. Not a huge operational issue, but I'm sure there are some folks that this hit a little bit. From sthaug at nethelp.no Wed Mar 2 14:57:33 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Wed, 02 Mar 2011 21:57:33 +0100 (CET) Subject: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: <4D6E9CFC.3030700@memetic.org> References: <4D6E9CFC.3030700@memetic.org> Message-ID: <20110302.215733.74702098.sthaug@nethelp.no> > > > Requirements are basically just 24/48 SFP ports, PVLAN and > > selective QinQ. > > > Most devices that fit the requirements are Layer 3, which pushes > > the cost > > > per port too high. ... > > The ME3600X might be more a more appropriate Cisco solution than the > > ME6524. The ME3600X is one of the current metro MDU access CPE device > > of choice. > > > > 2x10GE and 24xGE SFP or Copper versions with Metro Feature set. > > > > http://www.cisco.com/en/US/products/ps10956/index.html > > > > *In the spirit of full disclosure I am biased towards this vendor > > Still much too expensive :) If the ME3600X is much too expensive, it's possible your expectations for pricing aren't realistic. Selective QinQ is pretty new, and tends to be found only in provider type equipment. If you can live without that, "normal" (non selective) QinQ is offered on most switches today. In that case several different Extreme switches might be of interest. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From gbonser at seven.com Wed Mar 2 15:30:47 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 2 Mar 2011 13:30:47 -0800 Subject: Switch with 24x SFP PVLAN QinQ Layer 2 In-Reply-To: <20110302.215733.74702098.sthaug@nethelp.no> References: <4D6E9CFC.3030700@memetic.org> <20110302.215733.74702098.sthaug@nethelp.no> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13E88@RWC-EX1.corp.seven.com> > If the ME3600X is much too expensive, it's possible your expectations > for pricing aren't realistic. > > Selective QinQ is pretty new, and tends to be found only in provider > type equipment. If you can live without that, "normal" (non selective) > QinQ is offered on most switches today. In that case several different > Extreme switches might be of interest. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no Finding switches that will do private vlans, selective QinQ and the requirement for 24SFP ports is a combination that adds up to a switch in the $5,000 to $7,000 range even without layer 3 from most of the vendors whose products I use. Best one I have been able to come up with price-wise that seems to meet your requirements is Huawei Quidway S5300 (S5328C-EI-24S) which seems to be in the $3000 neighborhood but I have never used their gear. From jra at baylink.com Wed Mar 2 20:09:12 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 2 Mar 2011 21:09:12 -0500 (EST) Subject: What vexes VoIP users? In-Reply-To: <7513.1299080411@localhost> Message-ID: <6299263.874.1299118152605.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Valdis Kletnieks" > On Tue, 01 Mar 2011 23:55:16 CST, Frank Bulk said: > > Are you saying that the large MSOs don't use CM configuration files > > that create separate downstream and upstream service flows for Internet, > > voice signaling, and voice bearer traffic? > > So the cable company carves out a protected flow for its own triple-play > telephone, while third-party VoIP vendors have to contend on the Internet flow? > Why aren't the net-neutrality people busy having a cow over this? Ok, see, Valdis; this was where I started this conversation, and -- I think because I was merely using terms they didn't like for the objects involved -- everyone told me no, that wasn't what was really going on. But it sure *sounds* like what I thought was going on, really is (ie: the condition about which you inquire, above). And it wouldn't be Net Neutrality: it would be common-carrier equal access. I think. Cheers, -- jra From rdobbins at arbor.net Wed Mar 2 20:24:26 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 3 Mar 2011 02:24:26 +0000 Subject: TWTelecom DNS issues... In-Reply-To: <07EE9A15-CED3-431A-A80D-B7A126E29DB7@bsdboy.com> References: <8DB4C275-A748-4B38-92B5-AA77B80A6DEA@bsdboy.com> <07EE9A15-CED3-431A-A80D-B7A126E29DB7@bsdboy.com> Message-ID: <2DEBBBA8-4919-490E-A0FD-83CE06284F50@arbor.net> On Mar 3, 2011, at 2:42 AM, Wil Schultz wrote: > Not a huge operational issue, but I'm sure there are some folks that this hit a little bit. As Chris indicates, it would be a big win if recursion were disabled on the authoritative servers, and instead handled by dedicated caching-only recursors which would only answer queries from within their network. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From jra at baylink.com Wed Mar 2 20:31:45 2011 From: jra at baylink.com (Jay Ashworth) Date: Wed, 2 Mar 2011 21:31:45 -0500 (EST) Subject: TWTelecom DNS issues... In-Reply-To: Message-ID: <32980473.892.1299119505285.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Christopher Morrow" > On Wed, Mar 2, 2011 at 1:38 PM, Wil Schultz > wrote: > > ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS > > servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly > > stopped serving DNS for domains it's not authoritative for this > > morning. Requests are being actively refused from within their > > network. > > > > Caused a small issue for us, just thought I'd pass along. > > they were recursing previously and are no longer? that seems like a > win... or did I misconstrue what you said? Not if you're an end user who was configured, for some reason, to use them as a recursive server... which is what I infer from the fact that he posted it. In which case, it would be useful for Wil to provide us the IP addresses of those servers as he understand them, since that is what such affected users would have programmed... Cheers, -- jra From wschultz at bsdboy.com Wed Mar 2 21:09:06 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Wed, 2 Mar 2011 19:09:06 -0800 Subject: TWTelecom DNS issues... In-Reply-To: <32980473.892.1299119505285.JavaMail.root@benjamin.baylink.com> References: <32980473.892.1299119505285.JavaMail.root@benjamin.baylink.com> Message-ID: <55513F7F-2319-4DFC-BD67-05CD96EF3205@bsdboy.com> On Mar 2, 2011, at 6:31 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Christopher Morrow" > >> On Wed, Mar 2, 2011 at 1:38 PM, Wil Schultz >> wrote: >>> ns1.twtelecom.net and ns2.twtelecom.net (along with some other DNS >>> servers, ns1.orng.twtelecom.net and ns1.ptld.twtelecom.net) suddenly >>> stopped serving DNS for domains it's not authoritative for this >>> morning. Requests are being actively refused from within their >>> network. >>> >>> Caused a small issue for us, just thought I'd pass along. >> >> they were recursing previously and are no longer? that seems like a >> win... or did I misconstrue what you said? > > Not if you're an end user who was configured, for some reason, to use them > as a recursive server... which is what I infer from the fact that he posted > it. In which case, it would be useful for Wil to provide us the IP > addresses of those servers as he understand them, since that is what such > affected users would have programmed... > > Cheers, > -- jra > Oh sure, here are the ones that I tested and can confirm were down. Well, not "down" but actively refusing queries. ns1.iplt.twtelecom.net (64.132.94.250) ns1.milw.twtelecom.net (216.136.95.2) ns1.orng.twtelecom.net (168.215.210.50) ns1.snan.twtelecom.net (168.215.165.186) ns1.twtelecom.net (216.136.95.2, 2001:4870:6082:3::5) ns2.twtelecom.net (64.132.94.250, 2001:4870:8000:3::5) ns1.twtelecom.net and ns2.twtelecom.net are well known to be authoritative for a number of domain, and I would have presumed that the rest would be their recursive servers. I found an old welcome letter from them that states ns1.twtelecom.net and ms2.twtelecom.net were the preferred forwarders on the circuit. Some other network segments use their other resolvers but weren't affected because our internal boxes cache. I can't speak as to why they have it set up this way, but that's the list I have and every single one wasn't working from within or outside of their network. From my testing authoritative requests were never denied, however. There was a complete outage for a bit over an hour, then it was intermittent for a couple hours after that. Also, good or bad, all of the above servers recurse from on and off their network once again. Their NOC gave me a resolution of "Added an ACL to block an IP address". :-) Regardless, I'm not using their resolvers anymore but thought it would be helpful in case anyone else saw a segment of their network start yammering about facebook and twitter being down. -wil From ripe at alfatelecom.cz Thu Mar 3 01:55:11 2011 From: ripe at alfatelecom.cz (Alfa Telecom) Date: Thu, 03 Mar 2011 08:55:11 +0100 Subject: Ranges announced by Level3 without permitions. Message-ID: <4D6F495F.2020501@alfatelecom.cz> Hello All! Maybe somebody could help me with some issue: Ranges below are announced by Level3 79.110.224.0/20 *[BGP/170] 08:23:34, MED 0, localpref 150, from 213.248.64.245 AS path: 3356 79.110.64.0/20 *[BGP/170] 08:25:07, MED 0, localpref 150, from 213.248.64.245 AS path: 3356 Both ranges are from RIPE region and couldn't be announced from ARIN ASN at all. We're sponsored LIR for both companies, I sent several emails to Level3 noc, made several calls but they still announce these ranges. ------------------ Andrew From danny.pinto at ymail.com Thu Mar 3 02:07:21 2011 From: danny.pinto at ymail.com (Danny Pinto) Date: Thu, 3 Mar 2011 13:37:21 +0530 (IST) Subject: 39.0.0.0/8 on table already ? Message-ID: <346909.26739.qm@web95509.mail.in.yahoo.com> Hi , I saw 39.0.0.0/8 from AS273 on global table till last week .Was it a genuine advertisement or some tests ongoing with 39.0.0.0/8 or any other previously reserved spaces . I am updating my bogons lists and want to know any experiments happening with previous reserved spaces. Thanks, Dan From ripe at alfatelecom.cz Thu Mar 3 02:13:13 2011 From: ripe at alfatelecom.cz (Network Department) Date: Thu, 3 Mar 2011 09:13:13 +0100 Subject: Ranges announced by Level3 without permitions. In-Reply-To: References: <4D6F495F.2020501@alfatelecom.cz> Message-ID: Hi! 1) RIPE NCC policy requires all routes must be present at the RIPE DB and RIPE IPs could be officially announced outside RIPE Region. 2) Resources owners don't know anything about these routes.. so it means that ranges were announces without permission by third party company. On Thu, Mar 3, 2011 at 9:05 AM, Owen DeLong wrote: > > On Mar 2, 2011, at 11:55 PM, Alfa Telecom wrote: > >> Hello All! >> >> Maybe somebody could help me with some issue: >> >> Ranges below are announced by Level3 >> >> 79.110.224.0/20 ? ?*[BGP/170] 08:23:34, MED 0, localpref 150, from 213.248.64.245 >> ? ? ? ? ? ? ? ? ? ? ?AS path: 3356 >> 79.110.64.0/20 ? ? *[BGP/170] 08:25:07, MED 0, localpref 150, from 213.248.64.245 >> ? ? ? ? ? ? ? ? ? ? ?AS path: 3356 >> >> Both ranges are from RIPE region and couldn't be announced from ARIN ASN at all. We're sponsored LIR for both companies, I sent several emails to Level3 noc, made several calls but they still announce these ranges. >> ------------------ >> Andrew > > Why can't they be announced from ARIN ASN? ?Many network ranges issued by RIPE > are held by companies with operations in north america and are announced in > North America from North American ASNs. > > If you are saying that the announcement from Level 3 is not on behalf of the companies > for whom you are the sponsoring LIR, then, perhaps the registered customers (to whom > the addresses are listed in whois) should contact Level 3 directly so that they can > validate the resource registrants properly before removing the routes. > > If I misunderstand what you are attempting to say, I apologize, but, your message is > hard to understand. > > Owen > > -- Network Department Alfa Telecom s.r.o. http://www.alfatelecom.cz email: ripe at alfatelecom.cz phone: +420 226 020 362 From scott at doc.net.au Thu Mar 3 02:16:53 2011 From: scott at doc.net.au (Scott Howard) Date: Thu, 3 Mar 2011 00:16:53 -0800 Subject: [v6z] 39.0.0.0/8 on table already ? In-Reply-To: <346909.26739.qm@web95509.mail.in.yahoo.com> References: <346909.26739.qm@web95509.mail.in.yahoo.com> Message-ID: 39/8 was assigned to APNIC in January, and realistically should have been removed from any bogon lists at that time. At this stage it appears they are still doing "Resource Quality Assessment" on it and haven't actually carried out any assignments, but that in itself is enough of a reason to make sure that it's reachable. http://www.apnic.net/services/services-apnic-provides/registration-services/resource-quality-assurance Scott. On Thu, Mar 3, 2011 at 12:07 AM, Danny Pinto wrote: > Hi , > > I saw 39.0.0.0/8 from AS273 on global table till last week .Was it a > genuine advertisement or some tests ongoing with 39.0.0.0/8 or any other > previously reserved spaces . > > I am updating my bogons lists and want to know any experiments happening > with previous reserved spaces. > > Thanks, > Dan > > > > > > > From bonomi at mail.r-bonomi.com Thu Mar 3 04:18:49 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 3 Mar 2011 04:18:49 -0600 (CST) Subject: Postfix spam In-Reply-To: <4D6E03CB.9060702@altechstream.rw> Message-ID: <201103031018.p23AInYC058697@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Wed Mar 2 02:53:14 2011 > Date: Wed, 02 Mar 2011 10:46:03 +0200 > From: Peter Rudasingwa > To: nanog at nanog.org > Subject: Postfix spam > > Hello, > > I am being attacked by a lot of spams on my postfix box. What is the best > way to block them and fix this for good? > > It is so bad some of my IPs have been black listed. > > Thanks for your help. > 1) Hire a professional, as staff or as a contractor, to secure your systems. 2) Find the 'off' switch on the postfix box, and _use_ it. From literalka at gmail.com Thu Mar 3 08:03:18 2011 From: literalka at gmail.com (Leon Kaiser) Date: Thu, 03 Mar 2011 09:03:18 -0500 Subject: [BEWARE] David J. Moore Message-ID: <1299160998.11122.2.camel@kafir> This is the man who poisoned DroneBL. He is a bad man. Keep your children safe. http://raged.tittybang.org/ Leon ======================================================== Leon Kaiser - Head of GNAA Public Relations - literalka at gnaa.eu || literalka at goatse.fr http://gnaa.eu || http://security.goatse.fr 7BEECD8D FCBED526 F7960173 459111CE F01F9923 "The mask of anonymity is not intensely constructive." -- Andrew "weev" Auernheimer ======================================================== From literalka at gmail.com Thu Mar 3 08:10:31 2011 From: literalka at gmail.com (Leon Kaiser) Date: Thu, 03 Mar 2011 09:10:31 -0500 Subject: [BEWARE] David J. Moore In-Reply-To: <1299160998.11122.2.camel@kafir> References: <1299160998.11122.2.camel@kafir> Message-ID: <1299161431.11122.5.camel@kafir> This is the man who poisoned DroneBL. He is a bad man. Keep your children safe. > http://raged.tittybang.org/ > > Leon > ======================================================== > Leon Kaiser - Head of GNAA Public Relations - > literalka at gnaa.eu || literalka at goatse.fr > http://gnaa.eu || http://security.goatse.fr > 7BEECD8D FCBED526 F7960173 459111CE F01F9923 > "The mask of anonymity is not intensely constructive." > -- Andrew "weev" Auernheimer > ======================================================== kunwon1: what a bad man ``kunwon1'' aka David J. Moore is a mentally unstable chatter found on irc.freenode.net ##politics, where he frequently promotes racism, bigotry, and his own extremist political views. He is a violent felon, a pedophile, and a drug addict. Keep this sick, sick man away from your children at all costs. In addition to being a violent sex offender, he is a devout Muslim and deeply closeted homosexual. kunwon1: confirmed sex offender If you let David J. Moore anywhere near your children, there is no doubt in my mind that your child will soon become a rape victim. This is a very sick man who belongs in prison, not on IRC. Quick Facts about David J. Moore: Violent Sex Fiend * David J. Moore is responsible for 88% of all 'Amber Alerts. * There are literally hundreds of reported instances of Moore molesting children. * Authorities suspect that Moore keeps over 30 children locked in his basement, based on the screams neighbors frequently report to the police. * Moore was once described as calling a 4-year-old girl "very molestable", and a 7-month-old boy as "a hot piece of ass". * It is rumored that he is responsible for 45% of all child abuse in his county, and that 40% of all child pornography on the Internet can be traced back to him. * There is not a second in the day where David J. Moore does not lust after children. kunwon1: Junkie Labeled a pedophile and shunned by neighbors and peers alike, David J. Moore turned to drugs for companionship. After years of injecting Heroin and other opiates into his veins, it began to get harder to find a "good" vein to shoot up in. Moore was forced to turn to other drugs to fill the void in his life that Heroin once did. Drugs that David J. Moore is addicted to * Crack Cocaine * Marijuana * Morphine * LSD * Speed * Crystal Meth * Vicodin * Heroin * DXM * Ketamine * Steroids * Peyote * Salvia * Ecstacy * Shrooms * Oxycodone * Klonopin * Methadone * Ayahuasca * Adrenochrome Moore has also been known to huff "raid" from time to time. kunwon1: soft chatter Warning! The text that follows may be disturbing and thus unsuitable for younger viewers. If you are under the age of 18, or are offended at any time, please press the ``back'' button on your web browser. Click here for examples of kunwon1's deviant chatting. 15:39:49 ,---Whois--< kunwon1 [~kunwon1 at unaffiliated/kunwon1] 15:39:49 | gecos : Specialization is for Insects 15:39:50 | channels : #freenode @##child_pic_swap ##politics @##narco_trade ##politics-outcast +##infant-sex-workers ##gaydads4sons @#child_porn_dungeon 15:39:50 | server : brown.freenode.net (Madison, WI, US) 15:39:50 | : is using a secure connection 15:39:50 | idle : 0 days 0 hours 2 mins 40 secs (signon: Mon Feb 28 15:09:52 2011) 15:39:50 | account : kunwon1 15:39:50 `----------< From deric.kwok2000 at gmail.com Thu Mar 3 08:11:28 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Thu, 3 Mar 2011 09:11:28 -0500 Subject: download speed very fast. Message-ID: Hi all Do you know about sppedboost? Why it can suddenly burst to higher transfer rate from first 10M Can you share what equipment behinds to make it work? eg: cisco, juniper? Thank you so much From bross at pobox.com Thu Mar 3 08:25:07 2011 From: bross at pobox.com (Brandon Ross) Date: Thu, 3 Mar 2011 09:25:07 -0500 (EST) Subject: Ranges announced by Level3 without permitions. In-Reply-To: <4D6F495F.2020501@alfatelecom.cz> References: <4D6F495F.2020501@alfatelecom.cz> Message-ID: On Thu, 3 Mar 2011, Alfa Telecom wrote: > Both ranges are from RIPE region and couldn't be announced from ARIN ASN at > all. Your premise is incorrect. Any block from any RIR can be announced by any ASN. > We're sponsored LIR for both companies, I sent several emails to Level3 > noc, made several calls but they still announce these ranges. Why should they stop announcing them? Do you believe they have been hijacked? If these companies have decided to contract with another transit provider, you cannot stop them from doing so in this way. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From ripe at alfatelecom.cz Thu Mar 3 08:34:11 2011 From: ripe at alfatelecom.cz (Alfa Telecom) Date: Thu, 03 Mar 2011 15:34:11 +0100 Subject: Ranges announced by Level3 without permitions. In-Reply-To: References: <4D6F495F.2020501@alfatelecom.cz> Message-ID: <4D6FA6E3.40602@alfatelecom.cz> On 03/03/2011 03:25 PM, Brandon Ross wrote: > On Thu, 3 Mar 2011, Alfa Telecom wrote: > >> Both ranges are from RIPE region and couldn't be announced from ARIN >> ASN at all. > > Your premise is incorrect. Any block from any RIR can be announced by > any ASN. 1) All routing data must be present at the RIPE DB. If you work with RIPE DB you could see that webtools don't allow you to create route to ASN not from RIPE region. 2) RIPE IP Usage policy don't allow to route RIPE IPs from non-RIPE region. > >> We're sponsored LIR for both companies, I sent several emails to >> Level3 noc, made several calls but they still announce these ranges. > > Why should they stop announcing them? Do you believe they have been > hijacked? If these companies have decided to contract with another > transit provider, you cannot stop them from doing so in this way. > IPs are announced by Level3... I respect this company but looks like Level3 is scammed and currently announce without necessary permissions. From patrick at ianai.net Thu Mar 3 08:39:03 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 3 Mar 2011 09:39:03 -0500 Subject: Ranges announced by Level3 without permitions. In-Reply-To: <4D6FA6E3.40602@alfatelecom.cz> References: <4D6F495F.2020501@alfatelecom.cz> <4D6FA6E3.40602@alfatelecom.cz> Message-ID: <9D1D6D60-0D02-4DAF-8A92-1EAA2FDD0B13@ianai.net> On Mar 3, 2011, at 9:34 AM, Alfa Telecom wrote: > On 03/03/2011 03:25 PM, Brandon Ross wrote: >> On Thu, 3 Mar 2011, Alfa Telecom wrote: >> >>> Both ranges are from RIPE region and couldn't be announced from ARIN ASN at all. >> >> Your premise is incorrect. Any block from any RIR can be announced by any ASN. > 1) All routing data must be present at the RIPE DB. If you work with RIPE DB you could see that webtools don't allow you to create route to ASN not from RIPE region. > 2) RIPE IP Usage policy don't allow to route RIPE IPs from non-RIPE region. You are confused. >>> We're sponsored LIR for both companies, I sent several emails to Level3 noc, made several calls but they still announce these ranges. >> >> Why should they stop announcing them? Do you believe they have been hijacked? If these companies have decided to contract with another transit provider, you cannot stop them from doing so in this way. >> > IPs are announced by Level3... I respect this company but looks like Level3 is scammed and currently announce without necessary permissions. You will need more than a baseless accusation to make others change. Especially after you have shown ignorance of some basic facts on how networks announce & accept prefixes. -- TTFN, patrick From bross at pobox.com Thu Mar 3 08:39:51 2011 From: bross at pobox.com (Brandon Ross) Date: Thu, 3 Mar 2011 09:39:51 -0500 (EST) Subject: Ranges announced by Level3 without permitions. In-Reply-To: <4D6FA6E3.40602@alfatelecom.cz> References: <4D6F495F.2020501@alfatelecom.cz> <4D6FA6E3.40602@alfatelecom.cz> Message-ID: On Thu, 3 Mar 2011, Alfa Telecom wrote: > On 03/03/2011 03:25 PM, Brandon Ross wrote: >> On Thu, 3 Mar 2011, Alfa Telecom wrote: >> >>> Both ranges are from RIPE region and couldn't be announced from ARIN ASN >>> at all. >> >> Your premise is incorrect. Any block from any RIR can be announced by any >> ASN. > 1) All routing data must be present at the RIPE DB. If you work with RIPE DB > you could see that webtools don't allow you to create route to ASN not from > RIPE region. > 2) RIPE IP Usage policy don't allow to route RIPE IPs from non-RIPE region. Your premise is still wrong. Only networks that use the RIPE DB care about what's in the RIPE DB. There is no requirement for Level 3 to use it. There is no law that says they have to. >>> We're sponsored LIR for both companies, I sent several emails to Level3 >>> noc, made several calls but they still announce these ranges. >> >> Why should they stop announcing them? Do you believe they have been >> hijacked? If these companies have decided to contract with another transit >> provider, you cannot stop them from doing so in this way. >> > IPs are announced by Level3... I respect this company but looks like Level3 > is scammed and currently announce without necessary permissions. Again, do you believe these networks are hijacked? If they are in legitimate use by the companies that they are allocated to in whois, then there is no scam. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From morrowc.lists at gmail.com Thu Mar 3 08:55:24 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 3 Mar 2011 09:55:24 -0500 Subject: Ranges announced by Level3 without permitions. In-Reply-To: References: <4D6F495F.2020501@alfatelecom.cz> <4D6FA6E3.40602@alfatelecom.cz> Message-ID: On Thu, Mar 3, 2011 at 9:39 AM, Brandon Ross wrote: > On Thu, 3 Mar 2011, Alfa Telecom wrote: > >> On 03/03/2011 03:25 PM, Brandon Ross wrote: >>> >>> On Thu, 3 Mar 2011, Alfa Telecom wrote: >>> >>>> Both ranges are from RIPE region and couldn't be announced from ARIN ASN >>>> at all. netblocks in question: 79.110.224.0/20 79.110.64.0/20 I'd note both of these blocks seem to route to a L3 customer in SJC: 16 ae-3-80.edge8.SanJose1.Level3.net (4.69.152.148) 63.993 ms 63.770 ms ae-1-60.edge8.SanJose1.Level3.net (4.69.152.20) 63.421 ms 17 BANDCON.edge8.SanJose1.Level3.net (4.53.30.42) 93.556 ms 60.929 ms 60.376 ms 18 79.110.64.10 (79.110.64.10) 65.057 ms 64.949 ms 64.960 ms maybe it's better to ask them: OrgName: Bandcon OrgId: BANDC Address: 151 Kalmus Drive Address: Suite M-2 City: Costa Mesa StateProv: CA PostalCode: 92926 Country: US RegDate: 2002-11-08 Updated: 2009-02-11 Ref: http://whois.arin.net/rest/org/BANDC TechHandle: NOC2402-ARIN TechName: Network Operation Center TechPhone: +1-888-253-8353 TechEmail: arinpoc at bandcon.com TechRef: http://whois.arin.net/rest/poc/NOC2402-ARIN AdminHandle: NOC2402-ARIN AdminName: Network Operation Center AdminPhone: +1-888-253-8353 AdminEmail: arinpoc at bandcon.com AdminRef: http://whois.arin.net/rest/poc/NOC2402-ARIN What's going on? (shouting on public mailing-lists ain't gonna fix this I bet) -Chris From ops.lists at gmail.com Thu Mar 3 08:56:58 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 3 Mar 2011 20:26:58 +0530 Subject: Ranges announced by Level3 without permitions. In-Reply-To: References: <4D6F495F.2020501@alfatelecom.cz> <4D6FA6E3.40602@alfatelecom.cz> Message-ID: On Thu, Mar 3, 2011 at 8:09 PM, Brandon Ross wrote: >> IPs are announced by Level3... I respect this company but looks like >> Level3 is scammed and currently announce without necessary permissions. > > Again, do you believe these networks are hijacked? ?If they are in Hmm - so who should announce it? And who owns the netblock? The whois etc lookups below could put this either in the US or in Eastern Europe / Russia or in Italy. $ whois -h whois.radb.net 79.110.224.0/20 route: 79.110.224.0/20 descr: Avangard origin: AS50245 mnt-by: SERVEREL-MNT changed: noc at serverel.com 20110210 source: RIPE remarks: **************************** remarks: * THIS OBJECT IS NOT VALID remarks: * Please note that all data that is generally regarded as personal remarks: * data has been removed from this object. remarks: * http://www.ripe.net/whois remarks: **************************** Has a US address in the whois - which a little googling shows is a maildrop. http://www.beavertonvalleytimes.com/news/story.php?story_id=118668700663617700 person: Serverel NOC address: 14525 SW Millikan Way # 33735 Beaverton, OR 97005-2343 phone: +1(877)246 78 63 abuse-mailbox: abuse at serverel.com serverel.com Name-- Iurii Salmanov EMail-: (domains at serverel.com) serverel.net name: Andrew Neal mail: domains at serverel.com tel: +1.8772467863 org: Serverel Corporation Then ripe whois says the netblock is either owned by someone in the ukraine or in italy inetnum: 79.110.224.0 - 79.110.239.255 netname: Avangard descr: PE "Avangard" country: UA person: Karol Wojtula <- named for the late pope john paul II, I see ..? address: Bari , Italy , Piazzale Cristoforo Colombo, 1, 70122 <- google that address and its the ferry port in Bari, Italy. phone: +39 080 327 8841 And AS50425 - which'd announce it if that RADB object was actually valid - is in russia, not the czech republic organisation: ORG-JS33-RIPE org-name: Closed JSC "TV Services" org-type: OTHER address: 43, Bolshoy Tishinskiy per., Moscow, Russia, 123557 mnt-ref: TV-SERVICE-MNT mnt-by: TV-SERVICE-MNT source: RIPE # Filtered person: Dolgopolov Alexey address: Russia address: Moscow address: 43, Bolshoy Tishinskiy per phone: +7 495 9334592 nic-hdl: DA489-RIPE source: RIPE # Filtered So - the whois for these is quite confusing - not very easy for any one entity to establish ownership? -- Suresh Ramasubramanian (ops.lists at gmail.com) From alex-lists-nanog at yuriev.com Thu Mar 3 09:18:03 2011 From: alex-lists-nanog at yuriev.com (Alex Yuriev) Date: Thu, 3 Mar 2011 10:18:03 -0500 Subject: Anyone has a contact with IP clue at VerizonBusiness? Message-ID: <20110303151803.GA15474@corp.zubrcom.net> I know it may be a stretch but is there a remote possibility that someone knows anyone inside Verizon Business who has an ounce of clue about IPv4 address allocation and routing? It seems the panic over IPv4 scarcity is resulting in the most peculiar ideas bubbling up in the IP provisioning side which must be stomped out of existence before such ideas create signigicant connectivity issues. Thanks, Alex From wschultz at bsdboy.com Thu Mar 3 09:24:26 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Thu, 3 Mar 2011 07:24:26 -0800 Subject: Interesting google redirects. Message-ID: Has anyone else had complaints that www.google.com is occasionally redirecting (http 302) to www.google.com.hk this morning? -wil From lists at nexus6.co.za Thu Mar 3 09:34:29 2011 From: lists at nexus6.co.za (Andy Ashley) Date: Thu, 03 Mar 2011 16:34:29 +0100 Subject: Cross connect from Telx to Level 3 @ 111 8th Ave Message-ID: <4D6FB505.6060202@nexus6.co.za> Hi, Does anyone know if it is possible to get a cross connect from Telx (room 524) to Level 3 (room 304) at 111 8th Ave? Neither Telx or L3 can do this without serious complication and prohibitive cost. (contact me off list please) Thanks. Regards, Andy Ashley. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From Valdis.Kletnieks at vt.edu Thu Mar 3 09:39:03 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 03 Mar 2011 10:39:03 -0500 Subject: Anyone has a contact with IP clue at VerizonBusiness? In-Reply-To: Your message of "Thu, 03 Mar 2011 10:18:03 EST." <20110303151803.GA15474@corp.zubrcom.net> References: <20110303151803.GA15474@corp.zubrcom.net> Message-ID: <7043.1299166743@localhost> On Thu, 03 Mar 2011 10:18:03 EST, Alex Yuriev said: > It seems the panic over IPv4 scarcity is resulting in the most peculiar > ideas bubbling up in the IP provisioning side What peculiar ideas might these be? Inquiring minds want to know (as well as those who seek amusement, or need to be ready to deal with the aftermath). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Skywing at valhallalegends.com Thu Mar 3 09:53:36 2011 From: Skywing at valhallalegends.com (Skywing) Date: Thu, 3 Mar 2011 09:53:36 -0600 Subject: Interesting google redirects. Message-ID: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> (Apologies for the top-post.) I've been experiencing the same. Seems like their geolocation data is busted (since last morning at least), if I had to take a guess. - S -----Original Message----- From: Wil Schultz Sent: Thursday, March 03, 2011 7:25 To: NANOG Operators Group Subject: Interesting google redirects. Has anyone else had complaints that www.google.com is occasionally redirecting (http 302) to www.google.com.hk this morning? -wil From isabeldias1 at yahoo.com Thu Mar 3 10:07:46 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Thu, 3 Mar 2011 08:07:46 -0800 (PST) Subject: [BEWARE] David J. Moore In-Reply-To: <1299160998.11122.2.camel@kafir> References: <1299160998.11122.2.camel@kafir> Message-ID: <879887.59945.qm@web121615.mail.ne1.yahoo.com> The only reason why you feel that way is cause you haven't been?made aware and your network of friends is not "helping you at all" so?do speak up and make yourself heard! ----- Original Message ---- From: Leon Kaiser To: full-disclosure at lists.grok.org.uk; nanog at nanog.org; irc-security at lists.irc-unity.org; dronebl-discussion at dronebl.org Sent: Thu, March 3, 2011 2:03:18 PM Subject: [BEWARE] David J. Moore This is the man who poisoned DroneBL. He is a bad man. Keep your children safe. http://raged.tittybang.org/ Leon ======================================================== Leon Kaiser? ? ? - Head of GNAA Public Relations - ? ? ? ? literalka at gnaa.eu || literalka at goatse.fr ? ? ? http://gnaa.eu || http://security.goatse.fr ? ? ? 7BEECD8D FCBED526 F7960173 459111CE F01F9923 "The mask of anonymity is not intensely constructive." ? ? ? -- Andrew "weev" Auernheimer ======================================================== From aaron at wholesaleinternet.net Thu Mar 3 10:12:15 2011 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 3 Mar 2011 10:12:15 -0600 Subject: Interesting google redirects. In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> Message-ID: <91da9cb5-ebbc-4ada-b458-a834bd9d521c@blur> My IPs have been redirecting to google bk for several days. I thought it was just me. Sent via DROID on Verizon Wireless -----Original message----- From: Skywing To: Wil Schultz , nanog Sent: Thu, Mar 3, 2011 15:53:36 GMT+00:00 Subject: RE: Interesting google redirects. (Apologies for the top-post.) I've been experiencing the same. Seems like their geolocation data is busted (since last morning at least), if I had to take a guess. - S -----Original Message----- From: Wil Schultz Sent: Thursday, March 03, 2011 7:25 To: NANOG Operators Group Subject: Interesting google redirects. Has anyone else had complaints that www.google.com is occasionally redirecting (http 302) to www.google.com.hk this morning? -wil From richard.barnes at gmail.com Thu Mar 3 10:11:32 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Thu, 3 Mar 2011 11:11:32 -0500 Subject: Interesting google redirects. In-Reply-To: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> Message-ID: What networks are the affected clients on? On Thu, Mar 3, 2011 at 10:53 AM, Skywing wrote: > (Apologies for the top-post.) > > I've been experiencing the same. ?Seems like their geolocation data is busted (since last morning at least), if I had to take a guess. > > - S > > -----Original Message----- > From: Wil Schultz > Sent: Thursday, March 03, 2011 7:25 > To: NANOG Operators Group > Subject: Interesting google redirects. > > > Has anyone else had complaints that www.google.com is occasionally redirecting (http 302) to www.google.com.hk this morning? > > -wil > > From isabeldias1 at yahoo.com Thu Mar 3 10:13:41 2011 From: isabeldias1 at yahoo.com (isabel dias) Date: Thu, 3 Mar 2011 08:13:41 -0800 (PST) Subject: [BEWARE] David J. Moore Message-ID: <632109.26671.qm@web121617.mail.ne1.yahoo.com> If you can't be good be carefull! A "relation" is just a relationship between sets of information What is a relation? A Relation is a group of Functions ? ----- Original Message ---- From: isabel dias To: literalka at gnaa.eu; full-disclosure at lists.grok.org.uk; nanog at nanog.org; irc-security at lists.irc-unity.org; dronebl-discussion at dronebl.org Sent: Thu, March 3, 2011 4:07:46 PM Subject: Re: [BEWARE] David J. Moore The only reason why you feel that way is cause you haven't been?made aware and your network of friends is not "helping you at all" so?do speak up and make yourself heard! ----- Original Message ---- From: Leon Kaiser To: full-disclosure at lists.grok.org.uk; nanog at nanog.org; irc-security at lists.irc-unity.org; dronebl-discussion at dronebl.org Sent: Thu, March 3, 2011 2:03:18 PM Subject: [BEWARE] David J. Moore This is the man who poisoned DroneBL. He is a bad man. Keep your children safe. http://raged.tittybang.org/ Leon ======================================================== Leon Kaiser? ? ? - Head of GNAA Public Relations - ? ? ? ? literalka at gnaa.eu || literalka at goatse.fr ? ? ? http://gnaa.eu || http://security.goatse.fr ? ? ? 7BEECD8D FCBED526 F7960173 459111CE F01F9923 "The mask of anonymity is not intensely constructive." ? ? ? -- Andrew "weev" Auernheimer ======================================================== From shrdlu at deaddrop.org Thu Mar 3 10:15:22 2011 From: shrdlu at deaddrop.org (Lynda) Date: Thu, 03 Mar 2011 08:15:22 -0800 Subject: [BEWARE] David J. Moore In-Reply-To: <879887.59945.qm@web121615.mail.ne1.yahoo.com> References: <1299160998.11122.2.camel@kafir> <879887.59945.qm@web121615.mail.ne1.yahoo.com> Message-ID: <4D6FBE9A.1050308@deaddrop.org> On 3/3/2011 8:07 AM, isabel dias wrote: > The only reason why you feel that way is cause you haven't been made aware and > your network of friends is not "helping you at all" so do speak up and make > yourself heard! No, don't speak up. Please don't pollute NANOG any further than it already is, and please don't encourage others to do so. -- Amor fati. Vale. (Seneca) From morgan.miskell at caro.net Thu Mar 3 10:15:51 2011 From: morgan.miskell at caro.net (Morgan Miskell) Date: Thu, 03 Mar 2011 11:15:51 -0500 Subject: AT&T via Tata and Level3 Message-ID: <1299168951.3079.357.camel@cromagnon> I've noticed that we have thousands of routes for AT&T via Tata that we don't have from AT&T through Level3. I would expect Level3 to have most of the routes for AT&T that Tata does since they are both directly peered with AT&T. This seems to have started around midnight last night. I have a ticket open with Level3 to inquire...anyone else notice this or anything similar around 12-1AM EST this morning? -- Morgan A. Miskell CaroNet Data Centers 704-643-8330 x206 ---------------------------------------------------------------------------- The information contained in this e-mail is confidential and is intended only for the named recipient(s). If you are not the intended recipient you must not copy, distribute, or take any action or reliance on it. If you have received this e-mail in error, please notify the sender. Any unauthorized disclosure of the information contained in this e-mail is strictly prohibited. ---------------------------------------------------------------------------- From mike at jellydonut.org Thu Mar 3 10:19:36 2011 From: mike at jellydonut.org (Michael Proto) Date: Thu, 3 Mar 2011 11:19:36 -0500 Subject: download speed very fast. In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 9:11 AM, Deric Kwok wrote: > Hi all > > Do you know about sppedboost? > > Why it can suddenly burst to higher transfer rate from first 10M > > Can you share what equipment behinds to make it work? > > eg: cisco, juniper? > > Thank you so much > > I don't know about hardware, but as I understand it from some colleagues Speedboost uses a HFSC-based queuing mechanism on the backside. http://en.wikipedia.org/wiki/Hierarchical_Fair_Service_Curve -Proto From Brian.Rettke at cableone.biz Thu Mar 3 10:39:35 2011 From: Brian.Rettke at cableone.biz (Rettke, Brian) Date: Thu, 3 Mar 2011 09:39:35 -0700 Subject: download speed very fast. In-Reply-To: References: Message-ID: <96CA80CDCD822B4F9B41FB3A109C9359A3EB86364A@E2K7MAILBOX1.corp.cableone.net> It's essentially a 2 token bucket system. We implement based on the rate plan given via our DHCP server for residential customers, but it can be implemented using QoS on any router. Most DHCP server platforms offer it, and it is written into the configuration file downloaded by a cable modem. Sincerely, Brian A . Rettke -----Original Message----- From: Michael Proto [mailto:mike at jellydonut.org] Sent: Thursday, March 03, 2011 9:20 AM To: Deric Kwok Cc: nanog at nanog.org Subject: Re: download speed very fast. On Thu, Mar 3, 2011 at 9:11 AM, Deric Kwok wrote: > Hi all > > Do you know about sppedboost? > > Why it can suddenly burst to higher transfer rate from first 10M > > Can you share what equipment behinds to make it work? > > eg: cisco, juniper? > > Thank you so much > > I don't know about hardware, but as I understand it from some colleagues Speedboost uses a HFSC-based queuing mechanism on the backside. http://en.wikipedia.org/wiki/Hierarchical_Fair_Service_Curve -Proto From khelms at ispalliance.net Thu Mar 3 10:39:52 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 03 Mar 2011 11:39:52 -0500 Subject: download speed very fast. In-Reply-To: References: Message-ID: <4D6FC458.3040901@ispalliance.net> Deric, Depending on the kind of access gear being used there are different methods for making this work. This kind of technology is most commonly deployed on DOCSIS cable systems, for example Comcast has this trademarked as PowerBoost and they have done a ton of marketing around it. You can implement this kind of temporary speed boosting for cable systems on several CMTS brands (I know Cisco and Arris) and its probably possible for any CMTS that is certified for D2 or better. I haven't found a certified modem that couldn't handle that side of things. On 3/3/2011 9:11 AM, Deric Kwok wrote: > Hi all > > Do you know about sppedboost? > > Why it can suddenly burst to higher transfer rate from first 10M > > Can you share what equipment behinds to make it work? > > eg: cisco, juniper? > > Thank you so much > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From ez2517 at gmail.com Thu Mar 3 10:50:23 2011 From: ez2517 at gmail.com (Varun) Date: Thu, 3 Mar 2011 22:20:23 +0530 Subject: Interesting google redirects. In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> Message-ID: I have seen some of our APAC customers getting redirected to google.com.tw; the internet egress point is in japan. also some EU customers are getting redirected to .au domain On 03-Mar-2011 9:46 PM, "Richard Barnes" wrote: What networks are the affected clients on? On Thu, Mar 3, 2011 at 10:53 AM, Skywing wrote: > (Apologies for the... From l at p8x.net Thu Mar 3 10:55:02 2011 From: l at p8x.net (p8x) Date: Fri, 04 Mar 2011 00:55:02 +0800 Subject: Interesting google redirects. In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> Message-ID: <4D6FC7E6.5020100@p8x.net> I seem to be getting redirected to Google HK as well for the last week to 2 weeks or so (I am in AU). On 4/03/2011 12:50 AM, Varun wrote: > I have seen some of our APAC customers getting redirected to > google.com.tw; the internet egress point is in japan. > > also some EU customers are getting redirected to .au domain > From linkconnect at googlemail.com Thu Mar 3 11:04:19 2011 From: linkconnect at googlemail.com (Wayne Lee) Date: Thu, 3 Mar 2011 17:04:19 +0000 Subject: Interesting google redirects. In-Reply-To: <4D6FC7E6.5020100@p8x.net> References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> <4D6FC7E6.5020100@p8x.net> Message-ID: >> also some EU customers are getting redirected to .au ?domain Mine got redirected to google.be for a while. From prt at prt.org Thu Mar 3 11:07:58 2011 From: prt at prt.org (Paul Thornton) Date: Thu, 03 Mar 2011 17:07:58 +0000 Subject: Interesting google redirects. In-Reply-To: <4D6FC7E6.5020100@p8x.net> References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> <4D6FC7E6.5020100@p8x.net> Message-ID: <4D6FCAEE.4040403@prt.org> On 03/03/2011 16:55, p8x wrote: >> also some EU customers are getting redirected to .au domain >> I was being redirected to .ru earlier this week from UK addresses... Has stopped now. Paul. From frnkblk at iname.com Thu Mar 3 12:33:39 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 3 Mar 2011 12:33:39 -0600 Subject: download speed very fast. In-Reply-To: <4D6FC458.3040901@ispalliance.net> References: <4D6FC458.3040901@ispalliance.net> Message-ID: <015901cbd9d1$83ba0670$8b2e1350$@iname.com> In addition to the CMTS configuration, added to the CM configuration file are a two parameters that describe how much more bandwidth (peak rate) and how many more bytes (burst size). More here on Cisco's implementation: http://www.cisco.com/en/US/docs/ios/cable/configuration/guide/cmts_docsis11_ ps2209_TSD_Products_Configuration_Guide_Chapter.html#wp1278817 Frank -----Original Message----- From: Scott Helms [mailto:khelms at ispalliance.net] Sent: Thursday, March 03, 2011 10:40 AM To: nanog at nanog.org Subject: Re: download speed very fast. Deric, Depending on the kind of access gear being used there are different methods for making this work. This kind of technology is most commonly deployed on DOCSIS cable systems, for example Comcast has this trademarked as PowerBoost and they have done a ton of marketing around it. You can implement this kind of temporary speed boosting for cable systems on several CMTS brands (I know Cisco and Arris) and its probably possible for any CMTS that is certified for D2 or better. I haven't found a certified modem that couldn't handle that side of things. On 3/3/2011 9:11 AM, Deric Kwok wrote: > Hi all > > Do you know about sppedboost? > > Why it can suddenly burst to higher transfer rate from first 10M > > Can you share what equipment behinds to make it work? > > eg: cisco, juniper? > > Thank you so much > > -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From oiyankok at yahoo.ca Thu Mar 3 13:40:13 2011 From: oiyankok at yahoo.ca (ann kok) Date: Thu, 3 Mar 2011 11:40:13 -0800 (PST) Subject: icmp question Message-ID: <375540.6115.qm@web111315.mail.gq1.yahoo.com> Hello Have you had any experience about icmp from window and linux? I ping this linux host and they all are same LAN but Linux (ubuntu) is slow than window to this linux host Do you know why? Thank you From frlinux at gmail.com Thu Mar 3 13:45:17 2011 From: frlinux at gmail.com (FRLinux) Date: Thu, 3 Mar 2011 19:45:17 +0000 Subject: icmp question In-Reply-To: <375540.6115.qm@web111315.mail.gq1.yahoo.com> References: <375540.6115.qm@web111315.mail.gq1.yahoo.com> Message-ID: On Thu, Mar 3, 2011 at 7:40 PM, ann kok wrote: > Hello > Have you had any experience about icmp from window and linux? > I ping this linux host and they all are same LAN > but Linux (ubuntu) is slow than window to this linux host > Do you know why? > Thank you Hello, Without posting any inteface output, that might be a bit hard to diagnose and give an accurate answer :) Steph From ras at e-gerbil.net Thu Mar 3 14:12:16 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 3 Mar 2011 14:12:16 -0600 Subject: AT&T via Tata and Level3 In-Reply-To: <1299168951.3079.357.camel@cromagnon> References: <1299168951.3079.357.camel@cromagnon> Message-ID: <20110303201216.GK68199@gerbil.cluepon.net> On Thu, Mar 03, 2011 at 11:15:51AM -0500, Morgan Miskell wrote: > I've noticed that we have thousands of routes for AT&T via Tata that > we don't have from AT&T through Level3. I would expect Level3 to have > most of the routes for AT&T that Tata does since they are both > directly peered with AT&T. Well, I don't know anything about this specific issue or any policy changes that may have been made, but at a high level I can tell you that BGP doesn't work like that. BGP is only capable of passing on a single best path for each route, and what is considered the best path is totally in the eye of the beholder. First off you must understand that the vast majority of Internet routes are multi-homed at some level. As you get into large Tier 1 carriers, the amount of overlap is massive (i.e. you'll hear the same route as a "customer" from multiple networks), and the question of which path will be selected is completely up to the policies of the network doing the selecting. Not only does this vary by policy, but it varies by the composition of other networks they peer with (or buy from), what other networks buy from them, and even their network topology (due to tie breaking rules like EBGP > IBGP). For example, Level 3 is a much larger network with significantly more customer routes than Tata. I'm too lazy to do an actual comparison between the two, but odds are high that of the AT&T customer routes that they announce to their peers, probably somewhere around 30-40% of those routes are also Level 3 customer routes as well. A network will ALWAYS prefer their customer routes above those learned from peers (or else they wouldn't be able to guarantee that they're actually providing full transit service), so those routes coming from AT&T will never be selected. Meanwhile, Tata is receiving those same routes from both AT&T and Level 3 (and potentially other peers and/or customers too), and is completely free to make their own best path selections based on their own local criteria. The result is that you should almost never expect to see the same paths for the same networks being selected by two different large networks, unless the routes in question are single homed and there are no other choices (which is a small minority of the routes on the Internet). -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From efinley.lists at gmail.com Thu Mar 3 14:31:06 2011 From: efinley.lists at gmail.com (Elliot Finley) Date: Thu, 3 Mar 2011 13:31:06 -0700 Subject: Real World NAT64 deployments Message-ID: So as not to re-invent the wheel - if you are currently doing NAT64 in production and are willing to share: What software/hardware are you using? Why? TIA Elliot From bhmccie at gmail.com Thu Mar 3 14:41:20 2011 From: bhmccie at gmail.com (Hammer) Date: Thu, 3 Mar 2011 14:41:20 -0600 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: I need a cheat sheet. nat64 6to4nat 6in4nat etc... -Hammer- "I was a normal American nerd." -Jack Herer On Thu, Mar 3, 2011 at 2:31 PM, Elliot Finley wrote: > So as not to re-invent the wheel - if you are currently doing NAT64 in > production and are willing to share: > > What software/hardware are you using? > > Why? > > TIA > Elliot > From brunner at nic-naa.net Thu Mar 3 14:43:55 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Thu, 03 Mar 2011 15:43:55 -0500 Subject: OT: Where are the VoIP clue bats? Message-ID: <4D6FFD8B.6080502@nic-naa.net> First, thanks for all the responses to "What vexes VoIP users?" I'm looking for pointers to sites, like Geoff Huston's potaroo.net, that are VoIP clue dense, or mailing lists(*) where the VoIP-full lurk. Thanks in advance, Eric (*) I'm already on the ecrit list, though my real interest in the ongoing IETF "emergency services" meme has been a "I'm alive" app, not circuit and bandwidth capture by government. I was pleased to see a "I'm alive" app fielded by Google last week at Christchurch, NZ. From alex-lists-nanog at yuriev.com Thu Mar 3 14:47:54 2011 From: alex-lists-nanog at yuriev.com (Alexander O. Yuriev) Date: Thu, 3 Mar 2011 15:47:54 -0500 Subject: What vexes VoIP users? In-Reply-To: <201103011534.p21FY2nI080286@aurora.sol.net> References: <4D6D0654.60203@ispalliance.net> <201103011534.p21FY2nI080286@aurora.sol.net> Message-ID: <20110303204754.GB7889@corp.zubrcom.net> > There's no particularly good reason that a VoIP-over-cable system > shouldn't be able to hand off calls to an arbitrary SIP device. No, there's no particulary good technological reason why VOIP-over-cable system shouldn't be able to hand off calls to an arbitrary SIP device. The reason is purely business - it will destroy their own voice service user base. Alex From joshua.klubi at gmail.com Thu Mar 3 15:08:16 2011 From: joshua.klubi at gmail.com (Joshua Klubi) Date: Thu, 3 Mar 2011 21:08:16 +0000 Subject: Postfix spam In-Reply-To: <201103031018.p23AInYC058697@mail.r-bonomi.com> References: <201103031018.p23AInYC058697@mail.r-bonomi.com> Message-ID: <33EAC37F-0067-41A9-9768-2CC026B3D94C@gmail.com> Get A.S.S.P and integrate it with your postfix box, implement SPF and run dkimproxy on your postfix box and bid spams adieu . You would be surprised the power of ASSP . It is the best out there that kills spam dead on arrival and departure. Sent from my iPhone On Mar 3, 2011, at 10:18, Robert Bonomi wrote: >> From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Wed Mar 2 02:53:14 2011 >> Date: Wed, 02 Mar 2011 10:46:03 +0200 >> From: Peter Rudasingwa >> To: nanog at nanog.org >> Subject: Postfix spam >> >> Hello, >> >> I am being attacked by a lot of spams on my postfix box. What is the best >> way to block them and fix this for good? >> >> It is so bad some of my IPs have been black listed. >> >> Thanks for your help. >> > > 1) Hire a professional, as staff or as a contractor, to secure your systems. > > 2) Find the 'off' switch on the postfix box, and _use_ it. > > > From khelms at ispalliance.net Thu Mar 3 15:08:36 2011 From: khelms at ispalliance.net (Scott Helms) Date: Thu, 03 Mar 2011 16:08:36 -0500 Subject: What vexes VoIP users? In-Reply-To: <20110303204754.GB7889@corp.zubrcom.net> References: <4D6D0654.60203@ispalliance.net> <201103011534.p21FY2nI080286@aurora.sol.net> <20110303204754.GB7889@corp.zubrcom.net> Message-ID: <4D700354.90109@ispalliance.net> On 3/3/2011 3:47 PM, Alexander O. Yuriev wrote: >> There's no particularly good reason that a VoIP-over-cable system >> shouldn't be able to hand off calls to an arbitrary SIP device. > No, there's no particulary good technological reason why VOIP-over-cable > system shouldn't be able to hand off calls to an arbitrary SIP device. > > The reason is purely business - it will destroy their own voice service user base. > > Alex > > PacketCable pre-dates network neutrality discussions in the US, think 1999 for version 1.0 http://www.cablelabs.com/specifications/PKT-SP-TGCP-C01-071129.pdf So we have a working technology that pre-dated significant direct to consumer SIP services. Vonage went direct to consumer in 2002, before that their model was selling to the cable operators.) Now its true there is no technical reason that 3rd party SIP devices couldn't be included in the mix, especially since PacketCable 2.0 moves from MGCP to SIP. However, there is a ton of work to build an interoperable protocol for signaling call setup, AAA, number ports, etc, etc. Integrating 3rd party SIP into the existing PacketCable standards is certainly possible, but who is going to pay for it? I know of no 3rd party VOIP vendors that even want to go down this path. Vonage's technical folks seem quite happy to have a ~60% success rate in my experience troubleshooting networks and Skype seems even more disinterested. I also think you greatly over estimate the amount of concern generated by MagicJack, Skype, Vonage, et al. -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From frnkblk at iname.com Thu Mar 3 15:29:04 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 3 Mar 2011 15:29:04 -0600 Subject: What vexes VoIP users? In-Reply-To: <20110303204754.GB7889@corp.zubrcom.net> References: <4D6D0654.60203@ispalliance.net> <201103011534.p21FY2nI080286@aurora.sol.net> <20110303204754.GB7889@corp.zubrcom.net> Message-ID: <016501cbd9ea$0586b500$10941f00$@iname.com> Depends on the network, but we use private IPs on the eMTA side of the CM. Frank -----Original Message----- From: Alexander O. Yuriev [mailto:alex-lists-nanog at yuriev.com] Sent: Thursday, March 03, 2011 2:48 PM To: nanog at nanog.org Subject: Re: What vexes VoIP users? > There's no particularly good reason that a VoIP-over-cable system > shouldn't be able to hand off calls to an arbitrary SIP device. No, there's no particulary good technological reason why VOIP-over-cable system shouldn't be able to hand off calls to an arbitrary SIP device. The reason is purely business - it will destroy their own voice service user base. Alex From bill at herrin.us Thu Mar 3 15:54:48 2011 From: bill at herrin.us (William Herrin) Date: Thu, 3 Mar 2011 16:54:48 -0500 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 3:41 PM, Hammer wrote: > I need a cheat sheet. > > nat64 > 6to4nat > 6in4nat > etc... 6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6 nodes to talk to each other via an IPv4 backbone. nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 endpoints. nat44 is the IPv4 NAT you're used to. nat444 is carrier NAT (translated once by the customer and once again by the ISP, get it?) -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bhmccie at gmail.com Thu Mar 3 16:01:29 2011 From: bhmccie at gmail.com (Hammer) Date: Thu, 3 Mar 2011 16:01:29 -0600 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: A little better. So what's the difference between 6to4 and 6in4? Isn't 6in4 what HE uses? -Hammer- "I was a normal American nerd." -Jack Herer On Thu, Mar 3, 2011 at 3:54 PM, William Herrin wrote: > On Thu, Mar 3, 2011 at 3:41 PM, Hammer wrote: > > I need a cheat sheet. > > > > nat64 > > 6to4nat > > 6in4nat > > etc... > > 6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6 > nodes to talk to each other via an IPv4 backbone. > > nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 endpoints. > > nat44 is the IPv4 NAT you're used to. > nat444 is carrier NAT (translated once by the customer and once again > by the ISP, get it?) > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > From jg at freedesktop.org Thu Mar 3 16:17:28 2011 From: jg at freedesktop.org (Jim Gettys) Date: Thu, 03 Mar 2011 17:17:28 -0500 Subject: What vexes VoIP users? - Bufferbloat In-Reply-To: <20110301033231.203521fc@petrie> References: <4952321.01298971523361.JavaMail.root@jennyfur.pelican.org> <20110301033231.203521fc@petrie> Message-ID: <4D701378.3060403@freedesktop.org> On 03/01/2011 04:32 AM, William Pitcock wrote: > > That is the same market Vonage is now targeting in the US, basically. > National calling in the US is basically bundled with most calling plans > now. I'm not convinced that many people use Vonage in the US - my > experience with it was that it was not as reliable as the VOIP > products offered through the various broadband providers I have had. > Due to bufferbloat in the broadband edge, the broadband carriers have a fundamental advantage in providing VOIP, since they do not do so over the data service the user has but does not have access to for any classification; it is provisioned entirely separately on different channels. As you can see in the ICSI Netalyzr data you can find in my blog at http://gettys.wordpress.com/2010/12/06/whose-house-is-of-glasse-must-not-throw-stones-at-another/ whenever a home connection is saturated for any reason, customers can easily experience *seconds* of latency. (Telephony standards for max latency + jitter are in the 150MS range). Even web browsing induces transient jitter of order hundred(s) of milliseconds, from some experiments I've done, which is a problem for VOIP, much less the bulk data transfers which kill you for long periods. Now that I have mitigated the bufferbloat disaster in my home cable service via bandwidth shaping, Skype works sooo much better for me. This is what devices such as Ooma are doing. Unfortunately, it means you have to defeat features such as Comcast's PowerBoost. Note I do not believe bufferbloat was intended by any broadband carrier to give them such an advantage. Right now, they take it in the ear on service calls. And as far as I've been able to tell, just about everyone has been making the same generic mistake. I'm sure the conspiracy theorists will love to make such claims, however. If you don't know what bufferbloat is, you can try the talk I gave recently in Bell Labs, available at: http://mirrors.bufferbloat.net/Talks/BellLabs01192011/ or wade through my blog at: http://gettys.wordpress.com/ or come to the transport area meeting at the Prague IETF where I will be giving a somewhat abbreviated version of the talk. Best regards, Jim Gettys Bell Labs From jordi.palet at consulintel.es Thu Mar 3 16:20:47 2011 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 03 Mar 2011 23:20:47 +0100 Subject: Real World NAT64 deployments In-Reply-To: Message-ID: 6in4 is IPv6 encapsulated in IPv4 = protocol 41, typically used in manual tunnelling configuration and also in tunnel brokers and some other type of tunnels. 6to4 is an automatic transition mechanism that uses 6in4 to automatically create IPv6 tunnels using a special IPv6 prefix 2002::/16, appending the IPv4 public address to obtain a /48 for each IPv4 public address. It works very well for peer-to-peer, but it requires 6to4 relays for connecting to end-sites using any other kind of IPv6 connectivity (anything not-6to4). See: http://www.ipv6tf.org/index.php?page=using/connectivity/6to4 Regards, Jordi -----Mensaje original----- De: Hammer Responder a: Fecha: Thu, 3 Mar 2011 16:01:29 -0600 Para: William Herrin CC: Asunto: Re: Real World NAT64 deployments >A little better. So what's the difference between 6to4 and 6in4? Isn't >6in4 >what HE uses? > > > -Hammer- > >"I was a normal American nerd." >-Jack Herer > > > > > >On Thu, Mar 3, 2011 at 3:54 PM, William Herrin wrote: > >> On Thu, Mar 3, 2011 at 3:41 PM, Hammer wrote: >> > I need a cheat sheet. >> > >> > nat64 >> > 6to4nat >> > 6in4nat >> > etc... >> >> 6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6 >> nodes to talk to each other via an IPv4 backbone. >> >> nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 >>endpoints. >> >> nat44 is the IPv4 NAT you're used to. >> nat444 is carrier NAT (translated once by the customer and once again >> by the ISP, get it?) >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company 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 gbonser at seven.com Thu Mar 3 16:39:09 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 3 Mar 2011 14:39:09 -0800 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13ED3@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Elliot Finley > Sent: Thursday, March 03, 2011 12:31 PM > To: nanog at nanog.org > Subject: Real World NAT64 deployments > > So as not to re-invent the wheel - if you are currently doing NAT64 in > production and are willing to share: > > What software/hardware are you using? > > Why? > > TIA > Elliot I would be interested in this, too. Right now I am considering TAYGA but would be interested in the experience of others. George From gbonser at seven.com Thu Mar 3 16:57:28 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 3 Mar 2011 14:57:28 -0800 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13ED8@RWC-EX1.corp.seven.com> > From: Elliot Finley > Sent: Thursday, March 03, 2011 12:31 PM > To: nanog at nanog.org > Subject: Real World NAT64 deployments > > So as not to re-invent the wheel - if you are currently doing NAT64 in > production and are willing to share: > > What software/hardware are you using? > > Why? > > TIA > Elliot Ok, apparently there is NAT64 and there is NAT64. I don't believe the poster was talking about a v6 load balancer VIP with v4 servers. I think the OP is talking about the NAT64 portion of NAT64/DNS64 where native v6 source and destination IPs are NATed to v4 destination and source IPs for communicating with v4 resources from a v6 host. But I might be projecting my own needs here. So, what kind of NAT64 are we talking about? George From alex-lists-nanog at yuriev.com Thu Mar 3 17:07:31 2011 From: alex-lists-nanog at yuriev.com (Alexander O. Yuriev) Date: Thu, 3 Mar 2011 18:07:31 -0500 Subject: What vexes VoIP users? In-Reply-To: <4D700354.90109@ispalliance.net> References: <4D6D0654.60203@ispalliance.net> <201103011534.p21FY2nI080286@aurora.sol.net> <20110303204754.GB7889@corp.zubrcom.net> <4D700354.90109@ispalliance.net> Message-ID: <20110303230731.GA18169@corp.zubrcom.net> On Thu, Mar 03, 2011 at 04:08:36PM -0500, Scott Helms wrote: >> No, there's no particulary good technological reason why VOIP-over-cable >> system shouldn't be able to hand off calls to an arbitrary SIP device. >> >> The reason is purely business - it will destroy their own voice service user base. >> > > PacketCable pre-dates network neutrality discussions in the US, think 1999 > for version 1.0 > http://www.cablelabs.com/specifications/PKT-SP-TGCP-C01-071129.pdf > > So we have a working technology that pre-dated significant direct to > consumer SIP services. Vonage went direct to consumer in 2002, before that > their model was selling to the cable operators.) Now its true there is no > technical reason that 3rd party SIP devices couldn't be included in the > mix, especially since PacketCable 2.0 moves from MGCP to SIP. This has nothing to do with Vonage and likes that market to consumer - their devices are locked so the consumer is locked into the services that Vonage/MagicJack/etc provides. They are not the companies that are going to eat lunch of cable companies and old school telcos as their business model is to sell the same servie at a minimum discount to the rates of dominant carriers. What the cable companies are afraid of is that when a consumers have SIP speaking devices used to terminate calls the consumers will find VOIP providers that charge $1.00 a month for a phone number and another $0.01457 per voice minute with 6, 5, 4, 3, 2 or 1 second billing. After deploying about nearly a thousand SIP-speaking phones for different folk over last few months I can tell you that the self-provisioning for the customer's side is becoming so easy a caveman can do it. There goes their $20 or more per month worth of profit per phone number. Does it mean that they are preventing other SIP devices to work on their IP network? No, it does not. But what they are doing is preventing SIP devices from working with their voice network because they do not want it to be a user-controlled SIP device. Alex -- Alexander O. Yuriev Providing and Managing Solutions CTO, Zubr Communications Hosting, Servers, Applications, Access web: http://www.zubrcom.net tel: 267-298-3232 fax: 267-350-3303 From ryan.g at atwgpc.net Thu Mar 3 17:10:08 2011 From: ryan.g at atwgpc.net (Ryan Gelobter) Date: Thu, 3 Mar 2011 17:10:08 -0600 Subject: Windows Live Mail/Hotmail Postmaster Contact? Message-ID: Can anyone provide me with an alternative contact to someone at Hotmail? I've tried their support form over at https://support.msn.com/eform.aspx?productKey=edfsmsbl&ct=eformts&st=1&wfxredirect=1which doesn't seem to ever generate even an auto-reply anymore. Feel free to contact me off-list. From bill at herrin.us Thu Mar 3 17:25:44 2011 From: bill at herrin.us (William Herrin) Date: Thu, 3 Mar 2011 18:25:44 -0500 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: On Thu, Mar 3, 2011 at 5:01 PM, Hammer wrote: > A little better. So what's the difference between 6to4 and 6in4? Isn't 6in4 > what HE uses? I haven't used 6in4 so I couldn't tell you. 6to4 is a stateless tunnelling protocol. You have a dual-stacked router. It has an IPv4 address, 1.2.3.4. Therefore it supports a 6to4 IPv6 network numbered 2002:0102:0304::/48. Somebody tries to send a packet to 2002:0102:0304::1, it goes to a 6to4 router which encapsulates the IPv6 packet in an IPv4 packet and sends it to 1.2.3.4. 6to4 is handy as a toy or for experimenting, but it relies on a loose network of generous volunteers who, while generous, are neither generous nor numerous enough to support production traffic. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bonomi at mail.r-bonomi.com Thu Mar 3 17:39:06 2011 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Thu, 3 Mar 2011 17:39:06 -0600 (CST) Subject: AT&T via Tata and Level3 In-Reply-To: <20110303201216.GK68199@gerbil.cluepon.net> Message-ID: <201103032339.p23Nd6wn062995@mail.r-bonomi.com> > Date: Thu, 3 Mar 2011 14:12:16 -0600 > From: Richard A Steenbergen > Subject: Re: AT&T via Tata and Level3 > Cc: nanog at nanog.org > > On Thu, Mar 03, 2011 at 11:15:51AM -0500, Morgan Miskell wrote: > > I've noticed that we have thousands of routes for AT&T via Tata that we > > don't have from AT&T through Level3. I would expect Level3 to have > > most of the routes for AT&T that Tata does since they are both directly > > peered with AT&T. > > Well, I don't know anything about this specific issue or any policy > changes that may have been made, but at a high level I can tell you that > BGP doesn't work like that. BGP is only capable of passing on a single > best path for each route, and what is considered the best path is totally > in the eye of the beholder. [[.. sneck much good stuff ..]] While what you say is accurate, it is _irrelevant_ to the situation that the OP posted about. Methinks you misunderstood what he said. He peers with Level3 and TATA. Both of whom peer with AT&T. Looking at the -incoming- data from those two peers, he sees "thousands" of entries for AT&T address-blocks announced to him by TATA that are not being announced to him by Level3. Postulating that AT&T _is_ announcing all its address-blocks to both of those direct peers, the 'one-BGP-hop-removed-from-directly-connected' network should expect to see all those blocks from any of it's directly connected peers that are directly connected to AT&T. If one of those peers sees a 'better' route to one of those AT&T address-blocks, then it should be announcing that indirect path instead of the direct one. Ditto for blocks that AT&D does -not- announce (for whatever reason, traffic engineering, maybe?) to a directly connected peer. I would hazard a guess that the "missing routes" _might_ be the result of supressing 'more specifics', or they _are_ being announced to Level3, but with a 'community' tag that Level3 interprets as 'use locally, but do not announce externally'. From efinley.lists at gmail.com Thu Mar 3 17:33:03 2011 From: efinley.lists at gmail.com (Elliot Finley) Date: Thu, 3 Mar 2011 16:33:03 -0700 Subject: Real World NAT64 deployments In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13ED8@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13ED8@RWC-EX1.corp.seven.com> Message-ID: > > Ok, apparently there is NAT64 and there is NAT64. I don't believe the > poster was talking about a v6 load balancer VIP with v4 servers. I > think the OP is talking about the NAT64 portion of NAT64/DNS64 where > native v6 source and destination IPs are NATed to v4 destination and > source IPs for communicating with v4 resources from a v6 host. > > But I might be projecting my own needs here. So, what kind of NAT64 are > we talking about? > > George > > You are correct. I'm talking about the NAT64 portion of NAT64/DNS64. Elliot From berni at birkenwald.de Thu Mar 3 18:24:48 2011 From: berni at birkenwald.de (Bernhard Schmidt) Date: Fri, 4 Mar 2011 00:24:48 +0000 (UTC) Subject: Mac OS X 10.7, still no DHCPv6 References: <4D69DDD2.8050903@bogus.com> Message-ID: Mikael Abrahamsson wrote: > On a more serious note, I can on my Ubuntu machine just "apt-get install > wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in > resolv.conf for dns-over-ipv6 transport, even though the connection > manager knows nothing about it, at least dual stack works properly. This is finally getting fixed now. NetworkManager 0.8.3, to be shipped in the upcoming Ubuntu 11.04 (Natty) seems to do the right thing, including using the OtherConfig-Flag in RA to trigger a stateless DHCPv6 request. Haven't tested stateful yet. Bernhard From marka at isc.org Thu Mar 3 19:16:59 2011 From: marka at isc.org (Mark Andrews) Date: Fri, 04 Mar 2011 12:16:59 +1100 Subject: Real World NAT64 deployments In-Reply-To: Your message of "Thu, 03 Mar 2011 18:25:44 CDT." References: Message-ID: <20110304011659.0C834BA2009@drugs.dv.isc.org> In message , Will iam Herrin writes: > On Thu, Mar 3, 2011 at 5:01 PM, Hammer wrote: > > A little better. So what's the difference between 6to4 and 6in4? > Isn't 6in4 what HE uses? > > I haven't used 6in4 so I couldn't tell you. > > 6to4 is a stateless tunnelling protocol. You have a dual-stacked > router. It has an IPv4 address, 1.2.3.4. Therefore it supports a 6to4 > IPv6 network numbered 2002:0102:0304::/48. Somebody tries to send a > packet to 2002:0102:0304::1, it goes to a 6to4 router which > encapsulates the IPv6 packet in an IPv4 packet and sends it to > 1.2.3.4. > > 6to4 is handy as a toy or for experimenting, but it relies on a loose > network of generous volunteers who, while generous, are neither > generous nor numerous enough to support production traffic. Any ISP that is delivering IPv6 to their clients would be insane to not run a 6to4 relays for return traffic to 2002::/16. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From trejrco at gmail.com Thu Mar 3 19:27:18 2011 From: trejrco at gmail.com (TJ) Date: Thu, 3 Mar 2011 20:27:18 -0500 Subject: Real World NAT64 deployments Message-ID: 6in4 == deprecated automatic tunneling mechanism ... HE is an example of manually configured Protocol41 encaps. And 6to4 doesn't allow IPv6 to talk to IPv4, contrary to what the name seems to imply :). Some poorly chosen names for our tunneling, yes? Thanks, TJ's Droid2 On Mar 3, 2011 6:27 PM, "William Herrin" wrote: From bicknell at ufp.org Thu Mar 3 20:03:26 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 3 Mar 2011 18:03:26 -0800 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: <20110304020326.GA79595@ussenterprise.ufp.org> In a message written on Thu, Mar 03, 2011 at 08:27:18PM -0500, TJ wrote: > And 6to4 doesn't allow IPv6 to talk to IPv4, contrary to what the name seems > to imply :). > > Some poorly chosen names for our tunneling, yes? I think 6automaticallyover4 was determined to be too long. :P -- 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 ops.lists at gmail.com Thu Mar 3 20:18:36 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 4 Mar 2011 07:48:36 +0530 Subject: Postfix spam In-Reply-To: <33EAC37F-0067-41A9-9768-2CC026B3D94C@gmail.com> References: <201103031018.p23AInYC058697@mail.r-bonomi.com> <33EAC37F-0067-41A9-9768-2CC026B3D94C@gmail.com> Message-ID: The headers this guy sent me offlist = what you suggest just wouldn't work, sorry. He most likely had a rootkit on his server that was emitting direct to MX spam. On Fri, Mar 4, 2011 at 2:38 AM, Joshua Klubi wrote: > Get A.S.S.P and integrate it with your postfix box, implement SPF and run dkimproxy on your postfix box and bid spams adieu . > > You would be surprised the power of ASSP . It is the best out there that kills spam dead on arrival and departure. -- Suresh Ramasubramanian (ops.lists at gmail.com) From scott at sberkman.net Thu Mar 3 21:43:49 2011 From: scott at sberkman.net (Scott Berkman) Date: Thu, 3 Mar 2011 22:43:49 -0500 Subject: Where are the VoIP clue bats? In-Reply-To: <4D6FFD8B.6080502@nic-naa.net> References: <4D6FFD8B.6080502@nic-naa.net> Message-ID: <02b101cbda1e$601ba690$2052f3b0$@sberkman.net> http://voip-info.org Great general reference http://voiceops.org Great List (ok I helped start it so I might be a little biased) http://puck.nether.net/mailman/listinfo/cisco-voip Cisco VOIP specific list -Scott -----Original Message----- From: Eric Brunner-Williams [mailto:brunner at nic-naa.net] Sent: Thursday, March 03, 2011 3:44 PM To: NANOG list Subject: OT: Where are the VoIP clue bats? First, thanks for all the responses to "What vexes VoIP users?" I'm looking for pointers to sites, like Geoff Huston's potaroo.net, that are VoIP clue dense, or mailing lists(*) where the VoIP-full lurk. Thanks in advance, Eric (*) I'm already on the ecrit list, though my real interest in the ongoing IETF "emergency services" meme has been a "I'm alive" app, not circuit and bandwidth capture by government. I was pleased to see a "I'm alive" app fielded by Google last week at Christchurch, NZ. From frnkblk at iname.com Thu Mar 3 22:38:34 2011 From: frnkblk at iname.com (Frank Bulk) Date: Thu, 3 Mar 2011 22:38:34 -0600 Subject: Real World NAT64 deployments In-Reply-To: <20110304011659.0C834BA2009@drugs.dv.isc.org> References: <20110304011659.0C834BA2009@drugs.dv.isc.org> Message-ID: <000101cbda26$05652c00$102f8400$@iname.com> There's no assurance that the content provider will use the ISP's 6to4 relay. In fact, there's a good chance it won't use the ISP's 6to4 relay for return traffic. Frank -----Original Message----- From: Mark Andrews [mailto:marka at isc.org] Sent: Thursday, March 03, 2011 7:17 PM To: William Herrin Cc: nanog at nanog.org Subject: Re: Real World NAT64 deployments Any ISP that is delivering IPv6 to their clients would be insane to not run a 6to4 relays for return traffic to 2002::/16. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From owen at delong.com Thu Mar 3 23:41:05 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Mar 2011 21:41:05 -0800 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: <696B8314-4C41-4927-BAFF-646E9AEB410B@delong.com> On Mar 3, 2011, at 1:54 PM, William Herrin wrote: > On Thu, Mar 3, 2011 at 3:41 PM, Hammer wrote: >> I need a cheat sheet. >> >> nat64 >> 6to4nat >> 6in4nat >> etc... > > 6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6 > nodes to talk to each other via an IPv4 backbone. > > nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 endpoints. > > nat44 is the IPv4 NAT you're used to. > nat444 is carrier NAT (translated once by the customer and once again > by the ISP, get it?) > > More accurately: NAT44 is consumer NAT you're used to. LSN/CGN is NAT at the carrier level. DS-LITE is native IPv6 with private IPv4 tunneled over IPv6 to reach an LSN/CGN for IPv4 connectivity. NAT444 is NAT44 + LSN/CGN Owen From owen at delong.com Thu Mar 3 23:44:17 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Mar 2011 21:44:17 -0800 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: HE uses 6in4. 6in4 is basically the same protocol as 6to4, but, with defined end-points for point-to-point tunneling packets from multipoint to multipoint. 6to4, conversely, uses anycast to identify the tunnel exit point towards the IPv6 network or to identify the tunnel entry point towards the IPv4 segment. It depends on encoding the IPv4 address of the local encapsulating host sending the packet inside of the IPv6 source address in order to be able to identify the IPv4 destination after encapsulation. For 6to4, one end is almost always a single specific host which both generates the packets and does he IPv4 encapsulation. Owen On Mar 3, 2011, at 2:01 PM, Hammer wrote: > A little better. So what's the difference between 6to4 and 6in4? Isn't 6in4 > what HE uses? > > > -Hammer- > > "I was a normal American nerd." > -Jack Herer > > > > > > On Thu, Mar 3, 2011 at 3:54 PM, William Herrin wrote: > >> On Thu, Mar 3, 2011 at 3:41 PM, Hammer wrote: >>> I need a cheat sheet. >>> >>> nat64 >>> 6to4nat >>> 6in4nat >>> etc... >> >> 6to4 and 6in4 are not NAT. They're tunnels (VPNs) that allow two IPv6 >> nodes to talk to each other via an IPv4 backbone. >> >> nat64 is NAT. It allows IPv6 endpoints to communicate with IPv4 endpoints. >> >> nat44 is the IPv4 NAT you're used to. >> nat444 is carrier NAT (translated once by the customer and once again >> by the ISP, get it?) >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> From rmacharia at gmail.com Thu Mar 3 23:55:00 2011 From: rmacharia at gmail.com (Raymond Macharia) Date: Fri, 4 Mar 2011 08:55:00 +0300 Subject: Interesting google redirects. In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> <4D6FC7E6.5020100@p8x.net> Message-ID: Noticed the same thing to the .com.hk Raymond Macharia On Thu, Mar 3, 2011 at 8:04 PM, Wayne Lee wrote: > >> also some EU customers are getting redirected to .au domain > > Mine got redirected to google.be for a while. > > From mark at viviotech.net Fri Mar 4 00:13:49 2011 From: mark at viviotech.net (Mark Keymer) Date: Thu, 03 Mar 2011 22:13:49 -0800 Subject: Interesting google redirects. In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> <4D6FC7E6.5020100@p8x.net> Message-ID: <4D70831D.4050001@viviotech.net> On this same subject. My techs have been complaining lately about our new VPS's we are making going to google.vm. Is there anything I can do on my end to get this corrected? Sincerely, Mark Keymer Raymond Macharia wrote: >Noticed the same thing to the .com.hk >Raymond Macharia > > >On Thu, Mar 3, 2011 at 8:04 PM, Wayne Lee wrote: > > > >>>>also some EU customers are getting redirected to .au domain >>>> >>>> >>Mine got redirected to google.be for a while. >> >> >> >> From joshua.klubi at gmail.com Fri Mar 4 00:51:51 2011 From: joshua.klubi at gmail.com (Joshua William Klubi) Date: Fri, 4 Mar 2011 06:51:51 +0000 Subject: Postfix spam In-Reply-To: References: <201103031018.p23AInYC058697@mail.r-bonomi.com> <33EAC37F-0067-41A9-9768-2CC026B3D94C@gmail.com> Message-ID: Then like Robert Suggest he should implement step 2 and it would solve his problem asap Joshua On Fri, Mar 4, 2011 at 2:18 AM, Suresh Ramasubramanian wrote: > The headers this guy sent me offlist = what you suggest just wouldn't > work, sorry. > > He most likely had a rootkit on his server that was emitting direct to MX > spam. > > On Fri, Mar 4, 2011 at 2:38 AM, Joshua Klubi > wrote: > > Get A.S.S.P and integrate it with your postfix box, implement SPF and run > dkimproxy on your postfix box and bid spams adieu . > > > > You would be surprised the power of ASSP . It is the best out there that > kills spam dead on arrival and departure. > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) > From scott at doc.net.au Fri Mar 4 01:01:55 2011 From: scott at doc.net.au (Scott Howard) Date: Thu, 3 Mar 2011 23:01:55 -0800 Subject: [v6z] Re: Interesting google redirects. In-Reply-To: <4D70831D.4050001@viviotech.net> References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> <4D6FC7E6.5020100@p8x.net> <4D70831D.4050001@viviotech.net> Message-ID: On Thu, Mar 3, 2011 at 10:13 PM, Mark Keymer wrote: > On this same subject. My techs have been complaining lately about our new > VPS's we are making going to google.vm. Is there anything I can do on my end > to get this corrected? > http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=873 (Hint: the NANOG list archives can often be helpful for this type of stuff!) Scott From kauer at biplane.com.au Fri Mar 4 01:17:48 2011 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 04 Mar 2011 18:17:48 +1100 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: <1299223068.27837.62.camel@karl> On Thu, 2011-03-03 at 20:27 -0500, TJ wrote: > 6in4 == deprecated automatic tunneling mechanism ... HE is an example of > manually configured Protocol41 encaps. Deprecated? Do you have a reference...? Thanks, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From sthaug at nethelp.no Fri Mar 4 01:14:16 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Fri, 04 Mar 2011 08:14:16 +0100 (CET) Subject: Real World NAT64 deployments In-Reply-To: <20110304011659.0C834BA2009@drugs.dv.isc.org> References: <20110304011659.0C834BA2009@drugs.dv.isc.org> Message-ID: <20110304.081416.74704949.sthaug@nethelp.no> > > 6to4 is handy as a toy or for experimenting, but it relies on a loose > > network of generous volunteers who, while generous, are neither > > generous nor numerous enough to support production traffic. > > Any ISP that is delivering IPv6 to their clients would be insane > to not run a 6to4 relays for return traffic to 2002::/16. Given the number of ISPs that will need to turn on IPv6 the next few years, I believe the only conclusion here is that we'll see a large number of "insane" ISPs ... Steinar Haug, Nethelp consulting, sthaug at nethelp.no From owen at delong.com Fri Mar 4 01:33:37 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 3 Mar 2011 23:33:37 -0800 Subject: Real World NAT64 deployments In-Reply-To: <1299223068.27837.62.camel@karl> References: <1299223068.27837.62.camel@karl> Message-ID: <7956DBE6-21C0-4AB7-9050-D112AA74F1E7@delong.com> He is mistaken... HE Tunnels are an example of 6in4 and it is not deprecated, but, some original mechanisms for 6in4 to which he may be referring were deprecated. http://en.wikipedia.org/wiki/6in4 Owen On Mar 3, 2011, at 11:17 PM, Karl Auer wrote: > On Thu, 2011-03-03 at 20:27 -0500, TJ wrote: >> 6in4 == deprecated automatic tunneling mechanism ... HE is an example of >> manually configured Protocol41 encaps. > > Deprecated? Do you have a reference...? > > Thanks, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 From tom at ninjabadger.net Fri Mar 4 02:59:03 2011 From: tom at ninjabadger.net (Tom Hill) Date: Fri, 04 Mar 2011 08:59:03 +0000 Subject: Real World NAT64 deployments In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13ED8@RWC-EX1.corp.seven.com> Message-ID: <1299229143.23937.3.camel@teh-desktop> On Thu, 2011-03-03 at 16:33 -0700, Elliot Finley wrote: > You are correct. I'm talking about the NAT64 portion of NAT64/DNS64. > > Elliot Andrews & Arnold (http://aaisp.net.uk) have a NAT64 gateway which is operated by a Firebrick 6202, IIRC. As an ISP this is really for a handful of IPv6-only customers, but it seems to be working well. I've been considering the smaller Firebrick models (2700/2500) to do something similar for IPv6-only connectivity to an army of older Parallels Plesk installations, which of course Parallels has zero intention of bringing up to date. (Plesk 10.2 'preview' is floating about with IPv6 support -- it'll likely take them another 3-4 releases before any of it works properly, based on their performance to date.) Tom From randy at psg.com Fri Mar 4 03:14:12 2011 From: randy at psg.com (Randy Bush) Date: Fri, 04 Mar 2011 18:14:12 +0900 Subject: [BEWARE] David J. Moore In-Reply-To: <4D6FBE9A.1050308@deaddrop.org> References: <1299160998.11122.2.camel@kafir> <879887.59945.qm@web121615.mail.ne1.yahoo.com> <4D6FBE9A.1050308@deaddrop.org> Message-ID: > No, don't speak up. Please don't pollute NANOG any further than it > already is, and please don't encourage others to do so. is it spring vaccation in the states, when the children are loosed upon the net? randy From randy at psg.com Fri Mar 4 03:15:36 2011 From: randy at psg.com (Randy Bush) Date: Fri, 04 Mar 2011 18:15:36 +0900 Subject: Ranges announced by Level3 without permitions. In-Reply-To: <4D6FA6E3.40602@alfatelecom.cz> References: <4D6F495F.2020501@alfatelecom.cz> <4D6FA6E3.40602@alfatelecom.cz> Message-ID: > 1) All routing data must be present at the RIPE DB. pure bull > 2) RIPE IP Usage policy don't allow to route RIPE IPs from non-RIPE > region. pure bull randy From randy at psg.com Fri Mar 4 03:19:27 2011 From: randy at psg.com (Randy Bush) Date: Fri, 04 Mar 2011 18:19:27 +0900 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: > 6to4 is an automatic transition mechanism ^ non- which allows an end site to have horrible v6 pseudo-connectivity over a provider who has not deployed ipv6 randy From jordi.palet at consulintel.es Fri Mar 4 03:25:17 2011 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Fri, 04 Mar 2011 10:25:17 +0100 Subject: Real World NAT64 deployments In-Reply-To: Message-ID: Hi Randy, I don't advocate for 6to4. I'm for dual-stack, even with IPv4 private addresses and NAT, which is what we have today. However, we like it or not 6to4 is there in many platforms, and the best we can do is to deploy 6to4 relays in both sides, ISPs and content providers. That will minimise the problem. I think some other folks in the list already said it many times. I think is much much much better having 6to4 and relays than nothing. Same observations for Teredo. Regards, Jordi -----Mensaje original----- De: Randy Bush Responder a: Fecha: Fri, 04 Mar 2011 18:19:27 +0900 Para: Jordi Palet Martinez CC: Asunto: Re: Real World NAT64 deployments >> 6to4 is an automatic transition mechanism > ^ non- > >which allows an end site to have horrible v6 pseudo-connectivity over a >provider who has not deployed ipv6 > >randy ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company 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 ops.lists at gmail.com Fri Mar 4 04:22:39 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 4 Mar 2011 15:52:39 +0530 Subject: Postfix spam In-Reply-To: References: <201103031018.p23AInYC058697@mail.r-bonomi.com> <33EAC37F-0067-41A9-9768-2CC026B3D94C@gmail.com> Message-ID: That's as cluebie an answer as it gets. ps: man iptables on restricting / allowing by uid. cheers srs On Fri, Mar 4, 2011 at 12:21 PM, Joshua William Klubi wrote: > Then like Robert Suggest he should implement step 2 > and it would solve his problem asap -- Suresh Ramasubramanian (ops.lists at gmail.com) From a.harrowell at gmail.com Fri Mar 4 04:53:23 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Fri, 4 Mar 2011 10:53:23 +0000 Subject: Fasthosts postmaster Message-ID: <201103041053.24251.a.harrowell@gmail.com> Can someone who's a mail admin at Fasthosts Ltd. in the UK/AS15148 contact this customer off list? Messagelabs is rejecting random e-mail from one of your SMTP boxes (error 553: Spam, exchange-out-45.livemail.co.uk/213.171.216.45). Your phone number goes to people who don't know what a postmaster is, and your whois tech contact goes to the sales desk. Meanwhile, our ticket has been assigned to someone who wants to know "your e-mail address and password". Hint: 1) of those is in the to: field, and 2) is perfectly useless - how exactly do you login to the mail server's admin interface with a user's address and SMTP pwd? Further, not so sure about sending passwords about in cleartext e-mail to some outsourced thing or other. I've verified that neither us, nor that host, is in any of the major *BLs. (PS, if anyone from Messagelabs is around and can fix the problem without going through Fasthosts, that would be optimal:-)) Sorry for the noise, list. This may be e-mail related, but it is operational. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From nenolod at systeminplace.net Fri Mar 4 05:37:16 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 4 Mar 2011 05:37:16 -0600 Subject: [BEWARE] David J. Moore In-Reply-To: <1299160998.11122.2.camel@kafir> References: <1299160998.11122.2.camel@kafir> Message-ID: <20110304053716.1546b5c4@petrie> On Thu, 03 Mar 2011 09:03:18 -0500 Leon Kaiser wrote: > This is the man who poisoned DroneBL. He is a bad man. Keep your > children safe. > http://raged.tittybang.org/ How, exactly, has kunwon1 poisoned DroneBL when he has had no RPC key for over a year? William From nenolod at systeminplace.net Fri Mar 4 05:40:46 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Fri, 4 Mar 2011 05:40:46 -0600 Subject: Ranges announced by Level3 without permitions. In-Reply-To: <4D6FA6E3.40602@alfatelecom.cz> References: <4D6F495F.2020501@alfatelecom.cz> <4D6FA6E3.40602@alfatelecom.cz> Message-ID: <20110304054046.71b33fe1@petrie> On Thu, 03 Mar 2011 15:34:11 +0100 Alfa Telecom wrote: > On 03/03/2011 03:25 PM, Brandon Ross wrote: > > On Thu, 3 Mar 2011, Alfa Telecom wrote: > > > >> Both ranges are from RIPE region and couldn't be announced from > >> ARIN ASN at all. > > > > Your premise is incorrect. Any block from any RIR can be announced > > by any ASN. > 1) All routing data must be present at the RIPE DB. If you work with > RIPE DB you could see that webtools don't allow you to create route > to ASN not from RIPE region. > 2) RIPE IP Usage policy don't allow to route RIPE IPs from non-RIPE > region. This is not true, I have seen several instances of IPs from RIPE being used in the US, by people in Europe. William From trejrco at gmail.com Fri Mar 4 05:54:31 2011 From: trejrco at gmail.com (TJ) Date: Fri, 4 Mar 2011 06:54:31 -0500 Subject: Real World NAT64 deployments In-Reply-To: <7956DBE6-21C0-4AB7-9050-D112AA74F1E7@delong.com> References: <1299223068.27837.62.camel@karl> <7956DBE6-21C0-4AB7-9050-D112AA74F1E7@delong.com> Message-ID: Apologies, was thinking 6over4 ... And I still think we could have done better at naming these (DSTM, anyone?) Thanks, TJ's Droid2 On Mar 4, 2011 2:40 AM, "Owen DeLong" wrote: > He is mistaken... HE Tunnels are an example of 6in4 and it is not deprecated, > but, some original mechanisms for 6in4 to which he may be referring were > deprecated. > > http://en.wikipedia.org/wiki/6in4 > > Owen > > On Mar 3, 2011, at 11:17 PM, Karl Auer wrote: > >> On Thu, 2011-03-03 at 20:27 -0500, TJ wrote: >>> 6in4 == deprecated automatic tunneling mechanism ... HE is an example of >>> manually configured Protocol41 encaps. >> >> Deprecated? Do you have a reference...? >> >> Thanks, K. >> >> -- >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) >> http://www.biplane.com.au/kauer/ +61-428-957160 (mob) >> >> GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 >> Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > > From jay at jcornwall.me.uk Fri Mar 4 06:16:43 2011 From: jay at jcornwall.me.uk (Jay Cornwall) Date: Fri, 04 Mar 2011 12:16:43 +0000 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: References: <4D69DDD2.8050903@bogus.com> Message-ID: <056b8a41489032afc2d5b4a5278f9874@mail.jcornwall.me.uk> On Fri, 4 Mar 2011 00:24:48 +0000 (UTC), Bernhard Schmidt wrote: > Mikael Abrahamsson wrote: > >> On a more serious note, I can on my Ubuntu machine just "apt-get >> install >> wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in >> resolv.conf for dns-over-ipv6 transport, even though the connection >> manager knows nothing about it, at least dual stack works properly. > > This is finally getting fixed now. NetworkManager 0.8.3, to be > shipped > in the upcoming Ubuntu 11.04 (Natty) seems to do the right thing, > including using the OtherConfig-Flag in RA to trigger a stateless > DHCPv6 > request. Haven't tested stateful yet. I've tested stateful configuration and it works correctly (with stateless/stateful and stateful only) in NetworkManager with ISC DHCP 4. The DHCP client uses a dynamic DUID based on the link-local address and time. That's not quite as flexible as WIDE or Dibbler. -- Jay Cornwall http://www.jcornwall.me.uk/ From jmamodio at gmail.com Fri Mar 4 06:36:34 2011 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 4 Mar 2011 06:36:34 -0600 Subject: [BEWARE] David J. Moore In-Reply-To: References: <1299160998.11122.2.camel@kafir> <879887.59945.qm@web121615.mail.ne1.yahoo.com> <4D6FBE9A.1050308@deaddrop.org> Message-ID: > is it spring vaccation in the states, when the children are loosed upon > the net? not yet, in two weeks. this may be from Jeff Williams boot camp. -J From simon.perreault at viagenie.ca Fri Mar 4 07:25:15 2011 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Fri, 04 Mar 2011 08:25:15 -0500 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: <4D70E83B.30302@viagenie.ca> On 2011-03-03 15:31, Elliot Finley wrote: > So as not to re-invent the wheel - if you are currently doing NAT64 in > production and are willing to share: > > What software/hardware are you using? http://ecdysis.viagenie.ca/ > Why? Dogfooding. http://en.wikipedia.org/wiki/Eating_your_own_dog_food ;) Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From vovan at fakmoymozg.ru Fri Mar 4 07:25:58 2011 From: vovan at fakmoymozg.ru (Vladimir) Date: Fri, 04 Mar 2011 16:25:58 +0300 Subject: Hetzner using Netdirekt =?UTF-8?Q?network=3F?= Message-ID: <7eae2629a1b661a2e7f8bac50ed55016@fakmoymozg.ru> Hello, I've heard a rumour that Hetzner datacenter is leasing Netdirekt's bandwidth, could anyone confirm please? By tracerouting hetzner.de, netdirekt.de, and two servers (one placed in Netdirekt and another in Hetzner) I can't find anything similar (except russian gateways): kai at zuze:~> lft -s 12345 -d 80 netdirekt.de Tracing .........************.........T TTL LFT trace to ad150.unix-server.com (217.20.112.80):80/tcp ** [neglected] no reply packets received from TTL 1 2 10.1.141.145 177.1/105.0ms ** [neglected] no reply packets received from TTLs 3 through 4 5 yota-msk-gw.gblnet.ru (109.239.134.1) 101.0/59.8ms 6 msk-spb-te-gw4.gblnet.ru (94.124.183.242) 206.1/109.6ms 7 94.124.182.193 228.6/119.8ms 8 ams-sth-te-gw.gblnet.ru (94.124.182.222) 167.6/174.9ms 9 ams-fra-te-gw1.gblnet.ru (94.124.182.198) 180.0/99.8ms 10 decix.edpnet.net (80.81.192.139) 194.8/310.1ms 11 77.109.91.126.static.edpnet.net (77.109.91.126) 173.5/204.8ms ** [neglected] no reply packets received from TTL 12 13 [target open] ad150.unix-server.com (217.20.112.80):80 150.3/203.6ms kai at zuze:~> lft -s 12345 -d 80 hetzner.de Tracing ........*.***.********.........T TTL LFT trace to www.hetzner.de (213.133.107.227):80/tcp ** [neglected] no reply packets received from TTL 1 2 10.1.141.145 91.7/173.8ms ** [neglected] no reply packets received from TTLs 3 through 5 6 yota-msk-gw.gblnet.ru (109.239.134.1) 94.6/125.2ms 7 msk-spb-te-gw4.gblnet.ru (94.124.183.242) 185.8ms 8 94.124.182.193 134.3/164.1ms 9 ams-sth-te-gw.gblnet.ru (94.124.182.222) 164.4/164.8ms 10 ams-fra-te-gw1.gblnet.ru (94.124.182.198) 138.8/169.9ms 11 decix2-gw.hetzner.de (80.81.193.164) 181.1/176.5ms 12 hos-bb1.juniper1.fs.hetzner.de (213.239.240.242) 253.9/168.4ms 13 hos-tr2.ms-ex3k1.rz11.hetzner.de (213.239.236.83) 187.8/179.9ms 14 [target open] www.hetzner.de (213.133.107.227):80 130.7/151.3ms kai at zuze:~> lft -s 12345 -d 80 ns Tracing ......************.....T TTL LFT trace to ns (188.72.255.99):80/tcp ** [neglected] no reply packets received from TTL 1 2 10.1.141.145 95.1/76.3ms ** [neglected] no reply packets received from TTLs 3 through 4 5 213.33.166.241.sovintel.ru (213.33.166.241) 104.3/181.5ms 6 mx01.Frankfurt.gldn.net (194.186.157.138) 136.3/205.0ms 7 decix.edpnet.net (80.81.192.139) 179.0/180.6ms 8 77.109.91.126.static.edpnet.net (77.109.91.126) 148.0/139.8ms ** [neglected] no reply packets received from TTL 9 10 [target open] ns (188.72.255.99):80 144.2ms kai at zuze:~> lft -s 12345 -d 80 rh Tracing ........*.***********.........T TTL LFT trace to rh (178.63.47.150):80/tcp ** [neglected] no reply packets received from TTL 1 2 10.1.141.145 74.4/78.6ms ** [neglected] no reply packets received from TTLs 3 through 5 6 yota-msk-gw.gblnet.ru (109.239.134.1) 90.0/92.5ms 7 msk-spb-te-gw5.gblnet.ru (94.124.183.238) 136.7/185.0ms 8 spb-ams-te-gw5.gblnet.ru (94.124.182.209) 184.9/165.0ms 9 ams-fra-te-gw1.gblnet.ru (94.124.182.198) 176.0/185.2ms 10 decix2-gw.hetzner.de (80.81.193.164) 144.4/186.0ms 11 hos-bb1.juniper1.fs.hetzner.de (213.239.240.242) 165.0/174.1ms 12 hos-tr2.ex3k6.rz12.hetzner.de (213.239.228.167) 209.8/174.6ms 13 [target open] rh (178.63.47.150):80 163.4/234.9ms So is it true or just a rumour? Thanks in advance. Cheers, Vladimir From ftigeot at wolfpond.org Fri Mar 4 07:32:10 2011 From: ftigeot at wolfpond.org (Francois Tigeot) Date: Fri, 4 Mar 2011 14:32:10 +0100 Subject: Real World NAT64 deployments In-Reply-To: <4D70E83B.30302@viagenie.ca> References: <4D70E83B.30302@viagenie.ca> Message-ID: <20110304133210.GA16042@sekishi.zefyris.com> On Fri, Mar 04, 2011 at 08:25:15AM -0500, Simon Perreault wrote: > On 2011-03-03 15:31, Elliot Finley wrote: > > So as not to re-invent the wheel - if you are currently doing NAT64 in > > production and are willing to share: > > > > What software/hardware are you using? > > http://ecdysis.viagenie.ca/ What about its integration in upstream software ? The dns64 part is integrated in the newly released Bind 9.8 but I've not seen any real information for the nat part in pf or iptables. Could you enlighten us ? -- Francois Tigeot From simon.perreault at viagenie.ca Fri Mar 4 07:41:01 2011 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Fri, 04 Mar 2011 08:41:01 -0500 Subject: Real World NAT64 deployments In-Reply-To: <20110304133210.GA16042@sekishi.zefyris.com> References: <4D70E83B.30302@viagenie.ca> <20110304133210.GA16042@sekishi.zefyris.com> Message-ID: <4D70EBED.8000707@viagenie.ca> On 2011-03-04 08:32, Francois Tigeot wrote: >> http://ecdysis.viagenie.ca/ > > What about its integration in upstream software ? None of it is integrated yet. > The dns64 part is integrated in the newly released Bind 9.8 That's not our code. ISC made their own DNS64 implementation for Bind 9.8. As for Unbound, everybody wants it merged. It's just a matter of actually doing it. > but I've not > seen any real information for the nat part in pf or iptables. Pf has changed a lot between OpenBSD 4.6 and 4.7. We will need to updated our patch quite significantly. As for iptables, it's a different story. Our code does not use the regular conntrack NAT infrastructure. This is intentional. We wanted to be 100% RFC-compliant, and the conntrack stuff is very un-compliant. Because of this I doubt that it would be included upstream. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From rps at maine.edu Fri Mar 4 09:21:18 2011 From: rps at maine.edu (Ray Soucy) Date: Fri, 4 Mar 2011 10:21:18 -0500 Subject: Mac OS X 10.7, still no DHCPv6 In-Reply-To: <056b8a41489032afc2d5b4a5278f9874@mail.jcornwall.me.uk> References: <4D69DDD2.8050903@bogus.com> <056b8a41489032afc2d5b4a5278f9874@mail.jcornwall.me.uk> Message-ID: One issue with this is that distributions like RHEL don't open DHCPv6 in the default firewall policy. On Mar 4, 2011 7:17 AM, "Jay Cornwall" wrote: > On Fri, 4 Mar 2011 00:24:48 +0000 (UTC), Bernhard Schmidt wrote: > >> Mikael Abrahamsson wrote: >> >>> On a more serious note, I can on my Ubuntu machine just "apt-get >>> install >>> wide-dhcpv6-client" and I get dhcpv6, it'll properly put stuff in >>> resolv.conf for dns-over-ipv6 transport, even though the connection >>> manager knows nothing about it, at least dual stack works properly. >> >> This is finally getting fixed now. NetworkManager 0.8.3, to be >> shipped >> in the upcoming Ubuntu 11.04 (Natty) seems to do the right thing, >> including using the OtherConfig-Flag in RA to trigger a stateless >> DHCPv6 >> request. Haven't tested stateful yet. > > I've tested stateful configuration and it works correctly (with > stateless/stateful and stateful only) in NetworkManager with ISC DHCP 4. > > The DHCP client uses a dynamic DUID based on the link-local address and > time. That's not quite as flexible as WIDE or Dibbler. > > -- > Jay Cornwall > http://www.jcornwall.me.uk/ > From khelms at ispalliance.net Fri Mar 4 10:02:13 2011 From: khelms at ispalliance.net (Scott Helms) Date: Fri, 04 Mar 2011 11:02:13 -0500 Subject: What vexes VoIP users? In-Reply-To: <20110303230731.GA18169@corp.zubrcom.net> References: <4D6D0654.60203@ispalliance.net> <201103011534.p21FY2nI080286@aurora.sol.net> <20110303204754.GB7889@corp.zubrcom.net> <4D700354.90109@ispalliance.net> <20110303230731.GA18169@corp.zubrcom.net> Message-ID: <4D710D05.5060104@ispalliance.net> > This has nothing to do with Vonage and likes that market to consumer - their > devices are locked so the consumer is locked into the services that > Vonage/MagicJack/etc provides. They are not the companies that are going to > eat lunch of cable companies and old school telcos as their business model > is to sell the same servie at a minimum discount to the rates of dominant > carriers. > > What the cable companies are afraid of is that when a consumers have SIP > speaking devices used to terminate calls the consumers will find VOIP > providers that charge $1.00 a month for a phone number and another $0.01457 > per voice minute with 6, 5, 4, 3, 2 or 1 second billing. After deploying > about nearly a thousand SIP-speaking phones for different folk over last few > months I can tell you that the self-provisioning for the customer's side is > becoming so easy a caveman can do it. > > There goes their $20 or more per month worth of profit per phone number. First its indisputable that voice is inexpensive and will become less expensive, from all providers that stay in the business, over time. Having said that, perhaps you might want to look at both Skype & MagicJack since their pricing ranges between free to extremely inexpensive. MagicJack does require an adapter designed for them, but that seems to mainly be because they are targeting the very low technical skill market specifically. Skype (and clones) of course run on multiple devices ranging from SOHO 3rd party adapters to PCs to smart phones. MagicJack charges $19.99 per year for unlimited US and Canadian calling(and it appears to really be unlimited http://blogs.computerworld.com/voip_quiz_how_many_minutes_in_an_unlimited_plan). While Skype and MagicJack have attracted users (so has Google Voice which is also free) they haven't eroded the VOIP take rates for the cable operators in significant numbers. I would suggest that this has nothing to do with the fact these services/devices don't inter-operate with PacketCable networks and more to do with customers liking bundles and generally believing that the cable offering is a good deal even if its not the cheapest offering. > Does it mean that they are preventing other SIP devices to work on their > IP network? No, it does not. But what they are doing is preventing SIP > devices from working with their voice network because they do not want it to > be a user-controlled SIP device. > > Alex > Exactly how are they preventing anything? This is like someone yelling that they have designed a car that is 14 feet wide and the government is preventing them from being able to drive on the existing roads which by standard are only 12 feet wide (some older roads are much narrower). -- Scott Helms Vice President of Technology ISP Alliance, Inc. DBA ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- From bzeeb-lists at lists.zabbadoz.net Fri Mar 4 10:27:48 2011 From: bzeeb-lists at lists.zabbadoz.net (Bjoern A. Zeeb) Date: Fri, 4 Mar 2011 16:27:48 +0000 (UTC) Subject: Real World NAT64 deployments In-Reply-To: <4D70EBED.8000707@viagenie.ca> References: <4D70E83B.30302@viagenie.ca> <20110304133210.GA16042@sekishi.zefyris.com> <4D70EBED.8000707@viagenie.ca> Message-ID: On Fri, 4 Mar 2011, Simon Perreault wrote: > On 2011-03-04 08:32, Francois Tigeot wrote: >>> http://ecdysis.viagenie.ca/ >> >> What about its integration in upstream software ? > > None of it is integrated yet. > >> but I've not >> seen any real information for the nat part in pf or iptables. > > Pf has changed a lot between OpenBSD 4.6 and 4.7. We will need to > updated our patch quite significantly. Let me add that the plan still is to have it in the update pf in FreeBSD for 9.0, though this will be for a 4.5 equivalent pf. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From admin+nanog at msk4.com Fri Mar 4 10:30:53 2011 From: admin+nanog at msk4.com (imNet Administrator) Date: Fri, 04 Mar 2011 10:30:53 -0600 Subject: Spam from "baosteel" Message-ID: <4D7113BD.8010905@msk4.com> Is anyone else getting spam similar to this: I started getting this (albeit in English) a month or two ago, and it went away about the same time I turned on the CBL/XBL filters on postfix. It appears it's back again. Note, I have absolutely zero connection with "baosteel.com" before these started showing up. Example: -------------------------------------------------------------------------------- > From - Fri Mar 04 10:17:59 2011 > X-Account-Key: account3 > X-UIDL: 0000144b4b5bb8b1 > X-Mozilla-Status: 0001 > X-Mozilla-Status2: 00000000 > X-Mozilla-Keys: > Return-Path: > X-Original-To: immute##THISWASADDED##@msk4.com > Delivered-To: immute##THISWASADDED##@msk4.com > Received: from smtps-2.sercomtel.com.br (smtps-2.sercomtel.com.br [200.155.34.156]) > by li01.msk4.com (Postfix) with ESMTP id E4ED34157 > for ; Fri, 4 Mar 2011 01:20:13 -0600 (CST) > Received: from User (unknown [95.59.199.4]) > by smtps-2.sercomtel.com.br (Postfix) with ESMTP id 6E1D32F00C2; > Fri, 4 Mar 2011 04:17:55 -0300 (BRT) > Reply-To: > From: "Mail Administrator" > Subject: Email Quota Exceeded > Date: Fri, 4 Mar 2011 08:19:40 +0100 > MIME-Version: 1.0 > Content-Type: text/plain; > charset="Windows-1251" > Content-Transfer-Encoding: 7bit > X-Priority: 3 > X-MSMail-Priority: Normal > X-Mailer: Microsoft Outlook Express 6.00.2800.1081 > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 > Message-Id: <20110304071756.6E1D32F00C2 at smtps-2.sercomtel.com.br> > To: undisclosed-recipients:; > > This is to inform you that you have exceeded your E-mail Quota Limit and > you need to increase your E-mail Quota Limit because in less than 96 hours > your E- mail Account will be disabled.Increase your E-mail Quota Limit and > continue to use your Webmail Account. > > To increase your E-mail Quota Limit to 2.7GB, Fill in your Details as > below and send to the E-mail Quota Webmaster by CLICKING REPLY: > > EMAIL ADDRESS: > USERNAME: > PASSWORD: > CONFIRM PASSWORD: > DATE OF BIRTH: > > Thank you for your understanding and corperation in helping us give you > the Best of E-mail Service. -------------------------------------------------------------------------------- From john-nanog at johnpeach.com Fri Mar 4 10:35:54 2011 From: john-nanog at johnpeach.com (John Peach) Date: Fri, 4 Mar 2011 11:35:54 -0500 Subject: Spam from "baosteel" In-Reply-To: <4D7113BD.8010905@msk4.com> References: <4D7113BD.8010905@msk4.com> Message-ID: <20110304113554.78178211@jpeach-desktop.anbg.mssm.edu> Common phishing scam; we see them all the time, nearly always from accounts which have been compromised by others who respond to the same scam. On Fri, 04 Mar 2011 10:30:53 -0600 imNet Administrator wrote: > Is anyone else getting spam similar to this: > I started getting this (albeit in English) a month or two ago, and it > went away about the same time I turned on the CBL/XBL filters on > postfix. It appears it's back again. > Note, I have absolutely zero connection with "baosteel.com" before > these started showing up. > > Example: > -------------------------------------------------------------------------------- > > From - Fri Mar 04 10:17:59 2011 > > X-Account-Key: account3 > > X-UIDL: 0000144b4b5bb8b1 > > X-Mozilla-Status: 0001 > > X-Mozilla-Status2: 00000000 > > X-Mozilla-Keys: > > Return-Path: > > X-Original-To: immute##THISWASADDED##@msk4.com > > Delivered-To: immute##THISWASADDED##@msk4.com > > Received: from smtps-2.sercomtel.com.br (smtps-2.sercomtel.com.br > > [200.155.34.156]) by li01.msk4.com (Postfix) with ESMTP id E4ED34157 > > for ; Fri, 4 Mar 2011 > > 01:20:13 -0600 (CST) Received: from User (unknown [95.59.199.4]) > > by smtps-2.sercomtel.com.br (Postfix) with ESMTP id > > 6E1D32F00C2; Fri, 4 Mar 2011 04:17:55 -0300 (BRT) > > Reply-To: > > From: "Mail Administrator" > > Subject: Email Quota Exceeded > > Date: Fri, 4 Mar 2011 08:19:40 +0100 > > MIME-Version: 1.0 > > Content-Type: text/plain; > > charset="Windows-1251" > > Content-Transfer-Encoding: 7bit > > X-Priority: 3 > > X-MSMail-Priority: Normal > > X-Mailer: Microsoft Outlook Express 6.00.2800.1081 > > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1081 > > Message-Id: <20110304071756.6E1D32F00C2 at smtps-2.sercomtel.com.br> > > To: undisclosed-recipients:; > > > > This is to inform you that you have exceeded your E-mail Quota > > Limit and you need to increase your E-mail Quota Limit because in > > less than 96 hours your E- mail Account will be disabled.Increase > > your E-mail Quota Limit and continue to use your Webmail Account. > > > > To increase your E-mail Quota Limit to 2.7GB, Fill in your Details > > as below and send to the E-mail Quota Webmaster by CLICKING REPLY: > > > > EMAIL ADDRESS: > > USERNAME: > > PASSWORD: > > CONFIRM PASSWORD: > > DATE OF BIRTH: > > > > Thank you for your understanding and corperation in helping us give > > you the Best of E-mail Service. > -------------------------------------------------------------------------------- > > > > > -- John From tme at americafree.tv Fri Mar 4 10:42:05 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 4 Mar 2011 11:42:05 -0500 Subject: Internet to Libya ? Message-ID: Does anyone have evidence that the Internet is up to Libya today ? The Google "transparency report" is showing flatlines after about mid-day yesterday. http://www.google.com/transparencyreport/traffic/?r=LY&l=WEBSEARCH&csd=1298650426153&ced=1299255226153 Regards Marshall From admin+nanog at msk4.com Fri Mar 4 10:53:57 2011 From: admin+nanog at msk4.com (imNet Administrator) Date: Fri, 04 Mar 2011 10:53:57 -0600 Subject: Spam from "baosteel" In-Reply-To: <20110304113554.78178211@jpeach-desktop.anbg.mssm.edu> References: <4D7113BD.8010905@msk4.com> <20110304113554.78178211@jpeach-desktop.anbg.mssm.edu> Message-ID: <4D711925.7010202@msk4.com> On 3/4/2011 10:35 AM, John Peach wrote: > Common phishing scam; we see them all the time, nearly always from > accounts which have been compromised by others who respond to the same > scam. I thought this might be the case. Any particular hints on spam filters that can catch this type of thing? I already have most of the Postfix Anti-UCE cheatsheet implemented, but I'm hesitant to implement body checks because this installation supports a very small userbase and runs on limited hardware. From labovit at gmail.com Fri Mar 4 11:20:36 2011 From: labovit at gmail.com (Craig Labovitz) Date: Fri, 4 Mar 2011 12:20:36 -0500 Subject: Internet to Libya ? In-Reply-To: References: Message-ID: <782FFC71-5B9D-46A1-921D-8ED8ECE186F2@gmail.com> http://monkey.org/~labovit/images/march4_libya.pdf - Craig On Mar 4, 2011, at 11:42 AM, Marshall Eubanks wrote: > Does anyone have evidence that the Internet is up to Libya today ? > > The Google "transparency report" is showing flatlines after about mid-day yesterday. > > http://www.google.com/transparencyreport/traffic/?r=LY&l=WEBSEARCH&csd=1298650426153&ced=1299255226153 > > Regards > Marshall From tme at americafree.tv Fri Mar 4 11:39:12 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 4 Mar 2011 12:39:12 -0500 Subject: Internet to Libya ? In-Reply-To: <782FFC71-5B9D-46A1-921D-8ED8ECE186F2@gmail.com> References: <782FFC71-5B9D-46A1-921D-8ED8ECE186F2@gmail.com> Message-ID: On Mar 4, 2011, at 12:20 PM, Craig Labovitz wrote: > > > http://monkey.org/~labovit/images/march4_libya.pdf I also saw this http://www.renesys.com/blog/ Do you know if this is all of Libya (including the "liberated" East, e.g., Cyrenaica), or just Tripolitania (the part under gov. control) ? I believe that the cable landing is in Tripoli, so one cut could also isolate the rebel regions, unless there is an overland link to Egypt. Regards Marshall > > - Craig > > On Mar 4, 2011, at 11:42 AM, Marshall Eubanks wrote: > >> Does anyone have evidence that the Internet is up to Libya today ? >> >> The Google "transparency report" is showing flatlines after about mid-day yesterday. >> >> http://www.google.com/transparencyreport/traffic/?r=LY&l=WEBSEARCH&csd=1298650426153&ced=1299255226153 >> >> Regards >> Marshall > > > From cscora at apnic.net Fri Mar 4 12:37:34 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 5 Mar 2011 04:37:34 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201103041837.p24IbYdd001242@thyme.rand.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.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 05 Mar, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 349307 Prefixes after maximum aggregation: 157488 Deaggregation factor: 2.22 Unique aggregates announced to Internet: 172148 Total ASes present in the Internet Routing Table: 36007 Prefixes per ASN: 9.70 Origin-only ASes present in the Internet Routing Table: 31031 Origin ASes announcing only one prefix: 14946 Transit ASes present in the Internet Routing Table: 4976 Transit-only ASes present in the Internet Routing Table: 122 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 375 Unregistered ASNs in the Routing Table: 164 Number of 32-bit ASNs allocated by the RIRs: 1169 Prefixes from 32-bit ASNs in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 258 Number of addresses announced to Internet: 2455757344 Equivalent to 146 /8s, 95 /16s and 226 /24s Percentage of available address space announced: 66.3 Percentage of allocated address space announced: 66.3 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 89.1 Total number of prefixes smaller than registry allocations: 144961 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 86769 Total APNIC prefixes after maximum aggregation: 29668 APNIC Deaggregation factor: 2.92 Prefixes being announced from the APNIC address blocks: 83555 Unique aggregates announced from the APNIC address blocks: 36074 APNIC Region origin ASes present in the Internet Routing Table: 4337 APNIC Prefixes per ASN: 19.27 APNIC Region origin ASes announcing only one prefix: 1198 APNIC Region transit ASes present in the Internet Routing Table: 690 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 594716448 Equivalent to 35 /8s, 114 /16s and 167 /24s Percentage of available APNIC address space announced: 75.4 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, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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: 140246 Total ARIN prefixes after maximum aggregation: 71637 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 110832 Unique aggregates announced from the ARIN address blocks: 44959 ARIN Region origin ASes present in the Internet Routing Table: 14236 ARIN Prefixes per ASN: 7.79 ARIN Region origin ASes announcing only one prefix: 5417 ARIN Region transit ASes present in the Internet Routing Table: 1476 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 787480704 Equivalent to 46 /8s, 240 /16s and 0 /24s Percentage of available ARIN address space announced: 62.6 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, 23/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, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/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: 82597 Total RIPE prefixes after maximum aggregation: 46884 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 75881 Unique aggregates announced from the RIPE address blocks: 49204 RIPE Region origin ASes present in the Internet Routing Table: 15386 RIPE Prefixes per ASN: 4.93 RIPE Region origin ASes announcing only one prefix: 7770 RIPE Region transit ASes present in the Internet Routing Table: 2391 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 30 Number of RIPE addresses announced to Internet: 478711936 Equivalent to 28 /8s, 136 /16s and 144 /24s Percentage of available RIPE address space announced: 77.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, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 31972 Total LACNIC prefixes after maximum aggregation: 7376 LACNIC Deaggregation factor: 4.33 Prefixes being announced from the LACNIC address blocks: 30817 Unique aggregates announced from the LACNIC address blocks: 16093 LACNIC Region origin ASes present in the Internet Routing Table: 1434 LACNIC Prefixes per ASN: 21.49 LACNIC Region origin ASes announcing only one prefix: 433 LACNIC Region transit ASes present in the Internet Routing Table: 263 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 81347200 Equivalent to 4 /8s, 217 /16s and 66 /24s Percentage of available LACNIC address space announced: 53.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/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: 7507 Total AfriNIC prefixes after maximum aggregation: 1815 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 5903 Unique aggregates announced from the AfriNIC address blocks: 1957 AfriNIC Region origin ASes present in the Internet Routing Table: 433 AfriNIC Prefixes per ASN: 13.63 AfriNIC Region origin ASes announcing only one prefix: 128 AfriNIC Region transit ASes present in the Internet Routing Table: 96 Average AfriNIC Region AS path length visible: 5.4 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 21862912 Equivalent to 1 /8s, 77 /16s and 154 /24s Percentage of available AfriNIC address space announced: 32.6 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2419 9501 891 Korea Telecom (KIX) 7545 1603 301 83 TPG Internet Pty Ltd 4755 1421 638 165 TATA Communications formerly 17974 1405 475 29 PT TELEKOMUNIKASI INDONESIA 24560 1120 323 185 Bharti Airtel Ltd., Telemedia 4808 1046 2142 294 CNCGROUP IP network: China169 9583 1045 77 488 Sify Limited 17488 940 161 102 Hathway IP Over Cable Interne 9829 898 764 46 BSNL National Internet Backbo 18101 878 115 139 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3683 3855 260 bellsouth.net, inc. 4323 2582 1109 403 Time Warner Telecom 19262 1829 4953 282 Verizon Global Networks 1785 1790 697 131 PaeTec Communications, Inc. 6478 1531 297 94 AT&T Worldnet Services 20115 1527 1534 650 Charter Communications 18566 1522 326 178 Covad Communications 7018 1364 6706 885 AT&T WorldNet Services 2386 1296 537 939 AT&T Data Communications Serv 11492 1288 236 70 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 514 1780 319 UPC Distribution Services 9198 470 267 15 Kazakhtelecom Data Network Ad 34984 466 98 146 BILISIM TELEKOM 3292 448 1996 389 TDC Tele Danmark 8866 442 133 23 Bulgarian Telecommunication C 20940 415 99 319 Akamai Technologies European 3320 406 7604 354 Deutsche Telekom AG 8551 405 355 38 Bezeq International 702 396 1800 310 UUNET - Commercial IP service 12479 394 577 6 Uni2 Autonomous System Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1382 257 165 TVCABLE BOGOTA 8151 1361 2700 363 UniNet S.A. de C.V. 28573 1221 961 83 NET Servicos de Comunicao S.A 6503 1174 354 73 AVANTEL, S.A. 7303 911 464 147 Telecom Argentina Stet-France 14420 644 56 93 CORPORACION NACIONAL DE TELEC 22047 541 310 15 VTR PUNTO NET S.A. 3816 514 225 96 Empresa Nacional de Telecomun 7738 479 922 30 Telecomunicacoes da Bahia S.A 11172 463 83 82 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 795 445 11 TEDATA 24863 766 147 39 LINKdotNET AS number 15475 439 90 10 Nile Online 36992 301 271 14 Etisalat MISR 3741 266 987 228 The Internet Solution 33776 230 13 5 Starcomms Nigeria Limited 24835 222 78 10 RAYA Telecom - Egypt 29571 192 17 11 Ci Telecom Autonomous system 6713 187 191 17 Itissalat Al-MAGHRIB 16637 147 439 87 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3683 3855 260 bellsouth.net, inc. 4323 2582 1109 403 Time Warner Telecom 4766 2419 9501 891 Korea Telecom (KIX) 19262 1829 4953 282 Verizon Global Networks 1785 1790 697 131 PaeTec Communications, Inc. 7545 1603 301 83 TPG Internet Pty Ltd 6478 1531 297 94 AT&T Worldnet Services 20115 1527 1534 650 Charter Communications 18566 1522 326 178 Covad Communications 4755 1421 638 165 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2582 2179 Time Warner Telecom 1785 1790 1659 PaeTec Communications, Inc. 19262 1829 1547 Verizon Global Networks 4766 2419 1528 Korea Telecom (KIX) 7545 1603 1520 TPG Internet Pty Ltd 6478 1531 1437 AT&T Worldnet Services 17974 1405 1376 PT TELEKOMUNIKASI INDONESIA 18566 1522 1344 Covad Communications 4755 1421 1256 TATA Communications formerly 11492 1288 1218 Cable One Complete listing at http://thyme.rand.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 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 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.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 1.5.0.0/16 38639 NTT Communications Corporatio 1.6.0.0/15 38639 NTT Communications Corporatio 1.8.0.0/16 38639 NTT Communications Corporatio 1.20.0.0/16 38639 NTT Communications Corporatio 1.32.0.0/16 38639 NTT Communications Corporatio 1.37.0.0/16 38639 NTT Communications Corporatio 1.187.0.0/16 38639 NTT Communications Corporatio 14.0.0.0/24 38639 NTT Communications Corporatio 14.0.1.0/24 38639 NTT Communications Corporatio 14.0.2.0/23 38639 NTT Communications Corporatio Complete listing at http://thyme.rand.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:24 /9:10 /10:26 /11:73 /12:217 /13:446 /14:764 /15:1371 /16:11553 /17:5660 /18:9343 /19:18973 /20:24536 /21:25127 /22:33465 /23:31886 /24:182381 /25:1154 /26:1395 /27:713 /28:171 /29:9 /30:3 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2272 3683 bellsouth.net, inc. 18566 1500 1522 Covad Communications 6478 1485 1531 AT&T Worldnet Services 4323 1391 2582 Time Warner Telecom 10620 1273 1382 TVCABLE BOGOTA 11492 1245 1288 Cable One 7011 1057 1158 Citizens Utilities 1785 1055 1790 PaeTec Communications, Inc. 6503 956 1174 AVANTEL, S.A. 19262 941 1829 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:262 2:61 4:14 5:1 8:339 9:1 12:2029 13:1 14:423 15:15 16:3 17:8 20:9 23:1 24:1508 27:600 31:3 32:60 33:4 34:2 36:2 37:1 38:706 39:1 40:101 41:2295 42:13 44:3 46:686 47:4 49:164 50:174 52:13 55:3 56:2 57:41 58:857 59:477 60:384 61:1108 62:1022 63:1926 64:3850 65:2347 66:4323 67:1777 68:1067 69:2875 70:699 71:406 72:1997 73:1 74:2356 75:291 76:342 77:846 78:697 79:444 80:1058 81:791 82:522 83:463 84:636 85:1046 86:574 87:753 88:357 89:1568 90:169 91:3573 92:493 93:1053 94:1224 95:782 96:463 97:253 98:812 99:33 101:50 106:1 107:4 108:127 109:910 110:471 111:712 112:319 113:388 114:510 115:668 116:955 117:677 118:688 119:1045 120:255 121:701 122:1624 123:1043 124:1290 125:1258 128:266 129:165 130:172 131:562 132:108 133:20 134:219 135:49 136:211 137:146 138:295 139:118 140:486 141:203 142:374 143:386 144:487 145:51 146:435 147:203 148:638 149:273 150:166 151:229 152:299 153:180 154:3 155:376 156:178 157:343 158:127 159:378 160:311 161:210 162:278 163:155 164:486 165:345 166:501 167:409 168:728 169:157 170:758 171:69 172:2 173:1245 174:519 175:321 176:1 177:33 178:786 180:809 181:4 182:387 183:242 184:249 186:1033 187:812 188:906 189:1031 190:4580 192:5769 193:4792 194:3502 195:2953 196:1196 197:4 198:3576 199:3838 200:5577 201:1583 202:8235 203:8430 204:4108 205:2303 206:2652 207:3069 208:3901 209:3483 210:2638 211:1356 212:1927 213:1730 214:758 215:63 216:4843 217:1653 218:544 219:373 220:1152 221:473 222:319 223:104 End of report From cidr-report at potaroo.net Fri Mar 4 16:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Mar 2011 22:00:02 GMT Subject: BGP Update Report Message-ID: <201103042200.p24M02pg023545@wattle.apnic.net> BGP Update Report Interval: 24-Feb-11 -to- 03-Mar-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9829 18263 1.2% 14.3 -- BSNL-NIB National Internet Backbone 2 - AS6503 16222 1.1% 6.6 -- Axtel, S.A.B. de C.V. 3 - AS17842 14640 1.0% 1464.0 -- CNE-AS-KR Chungchungnam-Do office of Education 4 - AS35931 14104 1.0% 2350.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS9498 13232 0.9% 16.9 -- BBIL-AP BHARTI Airtel Ltd. 6 - AS10113 13011 0.9% 64.7 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD 7 - AS23681 12453 0.9% 1383.7 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 8 - AS32528 12393 0.8% 1549.1 -- ABBOTT Abbot Labs 9 - AS5722 12254 0.8% 188.5 -- Universidad Nacional de Colombia 10 - AS25086 12046 0.8% 1204.6 -- URALTC-AS CJSC "COMSTAR-regions" 11 - AS24560 11094 0.8% 9.9 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 12 - AS17974 11011 0.8% 7.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 13 - AS14522 10912 0.8% 25.3 -- Satnet 14 - AS4755 10717 0.7% 7.4 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 15 - AS27738 9055 0.6% 26.7 -- Ecuadortelecom S.A. 16 - AS1785 8587 0.6% 4.8 -- AS-PAETEC-NET - PaeTec Communications, Inc. 17 - AS7552 8316 0.6% 12.5 -- VIETEL-AS-AP Vietel Corporation 18 - AS22950 7673 0.5% 163.3 -- USASK - University of Saskatchewan 19 - AS11492 7667 0.5% 5.9 -- CABLEONE - CABLE ONE, INC. 20 - AS25220 7516 0.5% 578.2 -- GLOBALNOC-AS Averbo GmbH TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS17874 6163 0.4% 6163.0 -- NPC-AS-KR National Pension Corporation 2 - AS5572 5213 0.4% 2606.5 -- BOTIK Botik Technologies Ltd. 3 - AS35931 14104 1.0% 2350.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS10198 4496 0.3% 2248.0 -- CUP-AS-KR Catholic University of Pusan 5 - AS32528 12393 0.8% 1549.1 -- ABBOTT Abbot Labs 6 - AS17842 14640 1.0% 1464.0 -- CNE-AS-KR Chungchungnam-Do office of Education 7 - AS23681 12453 0.9% 1383.7 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 8 - AS35619 1370 0.1% 1370.0 -- APISNET APIS Ltd. 9 - AS32909 2692 0.2% 1346.0 -- ROYALTY-CARPET-MILLS - Royalty Carpet Mills 10 - AS25086 12046 0.8% 1204.6 -- URALTC-AS CJSC "COMSTAR-regions" 11 - AS45699 4516 0.3% 903.2 -- JDN-AS-ID Jogja Digital, PT 12 - AS49600 792 0.1% 792.0 -- LASEDA La Seda de Barcelona, S.A 13 - AS28519 2118 0.1% 706.0 -- Universidad Autonoma de Guadalajara, A.C. 14 - AS25220 7516 0.5% 578.2 -- GLOBALNOC-AS Averbo GmbH 15 - AS47805 1052 0.1% 526.0 -- MCIT Ministry of Communications and Information 16 - AS49777 4593 0.3% 510.3 -- ATEXS-AS ATEXS PLUS Ltd. 17 - AS28247 1959 0.1% 489.8 -- 18 - AS27771 959 0.1% 479.5 -- Instituto Venezolano de Investigaciones Cientificas 19 - AS46167 384 0.0% 384.0 -- LANDSERVICESUSA - Land Services USA, Inc 20 - AS18399 5272 0.4% 351.5 -- BAGAN-TRANSIT-AS Bagan Cybertech IDC & Teleport International Transit TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 85.235.42.0/23 10889 0.6% AS25086 -- URALTC-AS CJSC "COMSTAR-regions" 2 - 202.92.235.0/24 9331 0.5% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 3 - 63.211.68.0/22 9122 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - 202.61.252.0/24 8292 0.5% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 5 - 202.61.212.0/24 8292 0.5% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 6 - 202.61.234.0/24 8292 0.5% AS10113 -- DATAFAST-AP DATAFAST TELECOMMUNICATIONS LTD AS23681 -- ITU-TRANSIT-AS-AP Paradox Digital ASN on behalf of IT Universe. To provide BGP interconnects to VIX and Paradox. 7 - 85.197.100.0/22 7504 0.4% AS25220 -- GLOBALNOC-AS Averbo GmbH 8 - 130.36.34.0/24 6193 0.3% AS32528 -- ABBOTT Abbot Labs 9 - 130.36.35.0/24 6189 0.3% AS32528 -- ABBOTT Abbot Labs 10 - 211.173.99.0/24 6163 0.3% AS17874 -- NPC-AS-KR National Pension Corporation 11 - 193.232.174.0/24 5176 0.3% AS5572 -- BOTIK Botik Technologies Ltd. 12 - 198.140.43.0/24 4862 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - 168.176.127.0/24 4051 0.2% AS5722 -- Universidad Nacional de Colombia 14 - 200.24.8.0/24 4038 0.2% AS5722 -- Universidad Nacional de Colombia 15 - 168.176.197.0/24 4038 0.2% AS5722 -- Universidad Nacional de Colombia 16 - 68.65.152.0/22 3457 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 17 - 202.153.174.0/24 3021 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 18 - 203.192.205.0/24 2949 0.2% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd. AS9498 -- BBIL-AP BHARTI Airtel Ltd. 19 - 206.184.16.0/24 2928 0.2% AS174 -- COGENT Cogent/PSI 20 - 210.93.62.0/23 2248 0.1% AS10198 -- CUP-AS-KR Catholic University of Pusan 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 Mar 4 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 4 Mar 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201103042200.p24M00PZ023536@wattle.apnic.net> This report has been generated at Fri Mar 4 21:11:55 2011 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-02-11 350116 205298 26-02-11 350148 205121 27-02-11 349941 205119 28-02-11 349947 205114 01-03-11 350017 205278 02-03-11 350400 205668 03-03-11 350734 205625 04-03-11 350670 205625 AS Summary 36938 Number of ASes in routing system 15565 Number of ASes announcing only one prefix 3683 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108914944 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'). --- 04Mar11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 351354 205549 145805 41.5% All ASes AS6389 3683 265 3418 92.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2573 407 2166 84.2% TWTC - tw telecom holdings, inc. AS19262 1829 282 1547 84.6% VZGNI-TRANSIT - Verizon Online LLC AS4766 2419 909 1510 62.4% KIXS-AS-KR Korea Telecom AS6478 1531 211 1320 86.2% ATT-INTERNET3 - AT&T Services, Inc. AS10620 1387 182 1205 86.9% Telmex Colombia S.A. AS22773 1277 89 1188 93.0% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1422 354 1068 75.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1793 764 1029 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS18566 1522 611 911 59.9% COVAD - Covad Communications Co. AS28573 1220 317 903 74.0% NET Servicos de Comunicao S.A. AS7545 1606 739 867 54.0% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 934 154 780 83.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS24560 1106 349 757 68.4% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS6503 1176 441 735 62.5% Axtel, S.A.B. de C.V. AS4808 1050 326 724 69.0% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 912 192 720 78.9% Telecom Argentina S.A. AS3356 1184 491 693 58.5% LEVEL3 Level 3 Communications AS8151 1363 680 683 50.1% Uninet S.A. de C.V. AS11492 1290 618 672 52.1% CABLEONE - CABLE ONE, INC. AS17488 940 275 665 70.7% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4780 861 222 639 74.2% SEEDNET Digital United Inc. AS17676 651 70 581 89.2% GIGAINFRA Softbank BB Corp. AS855 634 58 576 90.9% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS14420 644 104 540 83.9% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22561 861 322 539 62.6% DIGITAL-TELEPORT - Digital Teleport Inc. AS7552 664 128 536 80.7% VIETEL-AS-AP Vietel Corporation AS3549 896 369 527 58.8% GBLX Global Crossing Ltd. AS22047 541 30 511 94.5% VTR BANDA ANCHA S.A. AS9498 769 260 509 66.2% BBIL-AP BHARTI Airtel Ltd. Total 38738 10219 28519 73.6% Top 30 total Possible Bogus Routes 1.5.0.0/16 AS38639 HANABI NTT Communications Corporation 1.6.0.0/15 AS38639 HANABI NTT Communications Corporation 1.8.0.0/16 AS38639 HANABI NTT Communications Corporation 1.20.0.0/16 AS38639 HANABI NTT Communications Corporation 1.32.0.0/16 AS38639 HANABI NTT Communications Corporation 1.37.0.0/16 AS38639 HANABI NTT Communications Corporation 1.187.0.0/16 AS38639 HANABI NTT Communications Corporation 1.200.0.0/20 AS38639 HANABI NTT Communications Corporation 14.0.0.0/24 AS38639 HANABI NTT Communications Corporation 14.0.1.0/24 AS38639 HANABI NTT Communications Corporation 14.0.2.0/23 AS38639 HANABI NTT Communications Corporation 14.0.4.0/24 AS38639 HANABI NTT Communications Corporation 14.0.15.0/24 AS38639 HANABI NTT Communications Corporation 14.1.0.0/24 AS38639 HANABI NTT Communications Corporation 14.102.128.0/23 AS38639 HANABI NTT Communications Corporation 14.192.76.0/24 AS38639 HANABI NTT Communications Corporation 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.129.192.0/19 AS7922 COMCAST-7922 - Comcast Cable Communications, Inc. 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 36.0.0.0/24 AS38639 HANABI NTT Communications Corporation 36.0.1.0/24 AS38639 HANABI NTT Communications Corporation 36.50.0.0/20 AS38639 HANABI NTT Communications Corporation 36.255.0.0/16 AS38639 HANABI NTT Communications Corporation 41.57.192.0/18 AS22750 BCSNET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 42.0.0.0/24 AS38639 HANABI NTT Communications Corporation 42.0.1.0/24 AS38639 HANABI NTT Communications Corporation 42.0.25.0/24 AS38639 HANABI NTT Communications Corporation 42.1.56.0/23 AS38639 HANABI NTT Communications Corporation 42.50.0.0/20 AS38639 HANABI NTT Communications Corporation 42.62.181.0/24 AS38639 HANABI NTT Communications Corporation 42.83.80.0/24 AS38639 HANABI NTT Communications Corporation 42.96.111.0/24 AS38639 HANABI NTT Communications Corporation 42.99.114.0/24 AS38639 HANABI NTT Communications Corporation 42.123.39.0/24 AS38639 HANABI NTT Communications Corporation 42.156.39.0/24 AS38639 HANABI NTT Communications Corporation 42.187.123.0/24 AS38639 HANABI NTT Communications Corporation 42.194.10.0/24 AS38639 HANABI NTT Communications Corporation 42.201.36.0/24 AS38639 HANABI NTT Communications Corporation 42.240.51.0/24 AS38639 HANABI NTT Communications Corporation 42.255.0.0/16 AS38639 HANABI NTT Communications Corporation 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 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.207.192.0/24 AS30304 64.207.193.0/24 AS30304 64.207.194.0/24 AS30304 64.207.195.0/24 AS30304 64.207.196.0/24 AS30304 64.207.197.0/24 AS30304 64.207.198.0/24 AS30304 64.207.200.0/24 AS30304 64.207.201.0/24 AS30304 64.207.202.0/24 AS30304 64.207.203.0/24 AS30304 64.207.204.0/24 AS30304 64.207.205.0/24 AS30304 64.207.206.0/24 AS30304 64.207.208.0/20 AS30304 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 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 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 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 91.224.212.0/23 AS50935 VERTICALNET Vertical Concept SRL 101.1.1.0/24 AS38639 HANABI NTT Communications Corporation 101.2.173.0/24 AS38639 HANABI NTT Communications Corporation 101.50.56.0/24 AS38639 HANABI NTT Communications Corporation 101.53.100.0/24 AS38639 HANABI NTT Communications Corporation 101.55.225.0/24 AS38639 HANABI NTT Communications Corporation 101.78.2.0/24 AS38639 HANABI NTT Communications Corporation 101.96.8.0/24 AS38639 HANABI NTT Communications Corporation 101.99.97.0/24 AS38639 HANABI NTT Communications Corporation 101.99.100.0/24 AS38639 HANABI NTT Communications Corporation 101.110.116.0/24 AS38639 HANABI NTT Communications Corporation 101.203.172.0/24 AS38639 HANABI NTT Communications Corporation 101.234.78.0/24 AS38639 HANABI NTT Communications Corporation 101.251.0.0/24 AS38639 HANABI NTT Communications Corporation 102.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 103.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 104.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 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. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 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.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 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 179.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 185.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 188.191.248.0/21 AS50935 VERTICALNET Vertical Concept SRL 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 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.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 G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 193.193.166.0/24 AS12388 Cablesurf Backbone AS 193.193.167.0/24 AS12388 Cablesurf Backbone AS 193.193.168.0/24 AS12388 Cablesurf Backbone AS 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.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 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 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 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.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - 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.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. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 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.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 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.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 CIX-ADELAIDE-AS Internode Systems Pty Ltd 203.30.26.0/23 AS3491 BTN-ASN - Beyond The Network America, Inc. 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 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.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 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 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 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 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.105.192.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.196.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.200.0/21 AS7385 INTEGRATELECOM - Integra Telecom, 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.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 223.0.0.0/15 AS38639 HANABI NTT Communications Corporation 223.223.223.0/24 AS38639 HANABI NTT Communications Corporation 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 os10rules at gmail.com Mon Mar 7 13:27:49 2011 From: os10rules at gmail.com (Greg Ihnen) Date: Mon, 7 Mar 2011 14:57:49 -0430 Subject: A BGP issue? Message-ID: I run a small network on a mission base in the Amazon jungle which is fed by a satellite internet connection. We had an outage from Feb 25th to the 28th where we had no connectivity with email, http/s, ftp, Skype would indicate it's connected but even chatting failed, basically everything stopped working except for ICMP. I could ping everywhere just fine. I started doing traceroutes and they all were very odd, all not reaching their destination and some hopping all over creation before dying. But if I did traceroute with ICMP it worked fine. Does this indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed Hughesnet which is the service they resell. I'm wondering what kind of problem would let ping work fine but not any of the other protocols. It also seems odd that I could traceroute via UDP part way to a destination but then it would fail if the problem was my own provider. Thanks. If this is the wrong forum for this post I'm sorry and please just hit delete. If this is the wrong forum but you'd be kind enough to share your expertise please reply off-list. Thanks! Here's some examples of the traceroutes I saved during the outage. Using UDP: Gregs-MacBook-Pro:~ GregIhnen$ traceroute metaconi.com traceroute to metaconi.com (70.32.39.205), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 1541.165 ms 25.665 ms 39.211 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 625.710 ms 860.264 ms 694.238 ms 4 192.168.180.5 (192.168.180.5) 645.666 ms 757.161 ms 664.785 ms 5 10.254.253.158 (10.254.253.158) 738.661 ms 801.487 ms 728.139 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 726.884 ms 733.989 ms 647.736 ms 7 te3-4.miami7.mia.seabone.net (195.22.199.97) 740.233 ms 694.619 ms 685.464 ms 8 206.111.1.161.ptr.us.xo.net (206.111.1.161) 639.077 ms 741.495 ms 679.880 ms 9 te-4-1-0.rar3.miami-fl.us.xo.net (207.88.12.161) 650.312 ms 612.386 ms 660.452 ms 10 te-3-2-0.rar3.atlanta-ga.us.xo.net (207.88.12.5) 787.079 ms 725.495 ms 685.068 ms 11 te-11-0-0.rar3.washington-dc.us.xo.net (207.88.12.10) 760.002 ms 828.076 ms 702.041 ms 12 ae0d0.mcr2.chicago-il.us.xo.net (216.156.0.166) 719.324 ms 641.274 ms 689.997 ms 13 ae1d0.mcr1.chicago-il.us.xo.net (216.156.1.81) 669.613 ms 813.794 ms 737.211 ms 14 edge1.chi1.ubiquityservers.com (216.55.8.30) 729.875 ms 751.481 ms 730.088 ms 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * * * 24 * * * 25 * * * 26 * * * 27 * * Now here it is again doing traceroute via ICMP: Gregs-MacBook-Pro:~ GregIhnen$ traceroute -I metaconi.com traceroute to metaconi.com (70.32.39.205), 64 hops max, 72 byte packets 1 192.168.7.1 (192.168.7.1) 5.254 ms 3.059 ms 2.578 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 1511.146 ms 711.304 ms 822.967 ms 4 192.168.180.5 (192.168.180.5) 712.672 ms 821.990 ms 713.009 ms 5 10.254.253.158 (10.254.253.158) 823.244 ms 711.764 ms 823.219 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 712.640 ms 613.306 ms 614.429 ms 7 te3-4.miami7.mia.seabone.net (195.22.199.97) 823.232 ms 711.881 ms 823.166 ms 8 206.111.1.161.ptr.us.xo.net (206.111.1.161) 712.765 ms 822.398 ms 712.531 ms 9 te-4-1-0.rar3.miami-fl.us.xo.net (207.88.12.161) 822.809 ms 920.831 ms 712.399 ms 10 te-3-2-0.rar3.atlanta-ga.us.xo.net (207.88.12.5) 823.288 ms 711.478 ms 822.887 ms 11 te-11-0-0.rar3.washington-dc.us.xo.net (207.88.12.10) 712.705 ms 822.287 ms 712.713 ms 12 * ae0d0.mcr2.chicago-il.us.xo.net (216.156.0.166) 738.656 ms 919.752 ms 13 ae1d0.mcr1.chicago-il.us.xo.net (216.156.1.81) 921.381 ms 920.884 ms 1228.683 ms 14 edge1.chi1.ubiquityservers.com (216.55.8.30) 921.560 ms 920.482 ms 921.634 ms 15 relativity.mrk.com (70.32.39.205) 880.318 ms 753.150 ms 823.285 ms Gregs-MacBook-Pro:~ GregIhnen$ Here's an example of a UDP traceroute going all over creation: Gregs-MacBook-Pro:~ GregIhnen$ traceroute skype.com traceroute to skype.com (78.141.177.7), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 18.939 ms 4.596 ms 27.124 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 724.034 ms 704.520 ms 823.886 ms 4 192.168.180.5 (192.168.180.5) 711.962 ms 704.606 ms 823.208 ms 5 10.254.253.158 (10.254.253.158) 712.622 ms 912.870 ms 921.471 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 712.642 ms 822.307 ms 712.720 ms 7 * te9-1.ccr01.mia03.atlas.cogentco.com (154.54.11.37) 3692.277 ms 702.345 ms 8 te9-1.ccr01.mia03.atlas.cogentco.com (154.54.11.37) 823.172 ms 920.050 ms 921.612 ms 9 te8-2.ccr01.mia01.atlas.cogentco.com (154.54.28.245) 921.681 ms te8-7.ccr02.mia01.atlas.cogentco.com (154.54.1.185) 703.270 ms te8-2.ccr02.mia01.atlas.cogentco.com (154.54.2.153) 730.152 ms 10 te0-0-0-5.ccr21.atl01.atlas.cogentco.com (154.54.30.33) 797.769 ms te2-1.ccr02.atl01.atlas.cogentco.com (154.54.3.25) 913.513 ms te0-1-0-4.ccr21.atl01.atlas.cogentco.com (154.54.24.161) 782.095 ms 11 te0-4-0-7.ccr21.dca01.atlas.cogentco.com (154.54.42.189) 814.870 ms te0-5-0-7.ccr22.dca01.atlas.cogentco.com (154.54.42.201) 815.878 ms te0-2-0-3.ccr21.dca01.atlas.cogentco.com (154.54.24.9) 912.453 ms 12 te0-5-0-6.ccr22.jfk02.atlas.cogentco.com (154.54.42.30) 913.183 ms te0-2-0-2.ccr21.jfk02.atlas.cogentco.com (154.54.26.186) 913.078 ms te0-4-0-7.ccr22.jfk02.atlas.cogentco.com (154.54.41.14) 913.268 ms 13 te2-8.ccr02.lon02.atlas.cogentco.com (154.54.30.22) 833.515 ms te0-4-0-7.mpd22.jfk02.atlas.cogentco.com (154.54.41.30) 702.568 ms te0-4-0-7.ccr22.bos01.atlas.cogentco.com (154.54.44.50) 815.549 ms 14 te0-3-0-2.ccr21.bos01.atlas.cogentco.com (154.54.44.14) 1010.769 ms te0-1-0-5.ccr21.bos01.atlas.cogentco.com (154.54.44.30) 913.070 ms te4-8.ccr01.lon01.atlas.cogentco.com (130.117.0.186) 913.076 ms 15 te7-3.mpd02.lon01.atlas.cogentco.com (154.54.30.130) 913.495 ms te4-4.mpd02.lon01.atlas.cogentco.com (130.117.1.134) 831.442 ms te1-1.mpd02.lon01.atlas.cogentco.com (154.54.5.162) 811.198 ms 16 te0-0-0-0.mpd21.par01.atlas.cogentco.com (130.117.2.5) 913.200 ms 912.636 ms te1-4.ccr01.bru01.atlas.cogentco.com (130.117.51.106) 921.496 ms 17 te0-0-0-0.mpd21.par01.atlas.cogentco.com (130.117.2.5) 913.344 ms 920.902 ms te1-4.ccr01.bru01.atlas.cogentco.com (130.117.51.106) 921.368 ms 18 149.6.134.86 (149.6.134.86) 920.406 ms 1014.226 ms * 19 213.166.61.194 (213.166.61.194) 959.442 ms 828.583 ms 920.909 ms 20 213.135.247.42 (213.135.247.42) 1019.971 ms 78.141.177.7 (78.141.177.7) 988.848 ms 213.135.247.42 (213.135.247.42) 1011.307 ms Gregs-MacBook-Pro:~ GregIhnen$ UDP traceroute worked to Google though I still couldn't load their pages Gregs-MacBook-Pro:~ GregIhnen$ traceroute google.com traceroute to google.com (74.125.229.114), 64 hops max, 52 byte packets 1 192.168.7.1 (192.168.7.1) 5.023 ms 3.971 ms 6.712 ms 2 * * * 3 192.168.14.254 (192.168.14.254) 1471.985 ms 643.770 ms 785.534 ms 4 192.168.180.5 (192.168.180.5) 712.715 ms 704.409 ms 626.374 ms 5 10.254.253.158 (10.254.253.158) 808.083 ms 647.244 ms 619.878 ms 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 776.534 ms 711.870 ms 640.372 ms 7 * te7-1.miami7.mia.seabone.net (195.22.199.109) 810.819 ms 731.713 ms 8 google.miami7.mia.seabone.net (89.221.41.18) 712.471 ms google.miami7.mia.seabone.net (89.221.41.74) 703.638 ms google.miami7.mia.seabone.net (89.221.41.18) 704.814 ms 9 209.85.253.116 (209.85.253.116) 822.336 ms 761.621 ms 209.85.253.74 (209.85.253.74) 709.705 ms 10 209.85.254.180 (209.85.254.180) 705.062 ms 702.723 ms 824.497 ms 11 74.125.229.114 (74.125.229.114) 712.196 ms 704.509 ms 596.077 ms Gregs-MacBook-Pro:~ GregIhnen$ From babydr at baby-dragons.com Sun Mar 6 17:34:45 2011 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Sun, 6 Mar 2011 14:34:45 -0900 (AKST) Subject: Something is worng with the list I think . Message-ID: Hello All , Nothing in the archive nor in the mailbox , Testing if mail server is actually accepting mail . Sorry , JimL ps: with the right domain nake this time . -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From mawatari at jpix.ad.jp Mon Mar 7 08:52:37 2011 From: mawatari at jpix.ad.jp (MAWATARI Masataka) Date: Mon, 07 Mar 2011 23:52:37 +0900 Subject: Real World NAT64 deployments In-Reply-To: References: Message-ID: <20110307235236.FF3B.8FE1F57E@jpix.ad.jp> JPIX started XLATE trial service for our IX members in July 2010. I talked about this service status at APRICOT 2011 last month. Please see a presentation material below. http://www.apricot-apan.asia/__data/assets/pdf_file/0018/31365/Masataka_Mawatari_IPv6v4_Exchange_Service_for_sharing_IPv4_address.pdf If you have any comments, please let me know. Regards, Masataka MAWATARI * On Thu, 3 Mar 2011 13:31:06 -0700 * Elliot Finley wrote: > So as not to re-invent the wheel - if you are currently doing NAT64 in > production and are willing to share: > > What software/hardware are you using? > > Why? > > TIA > Elliot From babydr at baby-dragons.com Sun Mar 6 17:30:43 2011 From: babydr at baby-dragons.com (Mr. James W. Laferriere) Date: Sun, 6 Mar 2011 14:30:43 -0900 (AKST) Subject: Something is worng with the list I think . Message-ID: Hello All , Nothing in the archive nor in the mailbox , Testing if mail server is actually accepting mail . Sorry , JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network&System Engineer | 3237 Holden Road | Give me Linux | | babydr at baby-dragons.com | Fairbanks, AK. 99709 | only on AXP | +------------------------------------------------------------------+ From avg at kotovnik.com Mon Mar 7 05:43:20 2011 From: avg at kotovnik.com (Vadim Antonov) Date: Mon, 07 Mar 2011 03:43:20 -0800 Subject: IPv4 address shortage? Really? Message-ID: <1299498200.29652.40.camel@kotti.kotovnik.com> I'm wondering (and that shows that I have nothing better to do at 3:30am on Monday...) how many people around here realize that the plain old IPv4 - as widely implemented and specified in standard RFCs can be easily used to connect pretty much arbitrary number (arbitrary means >2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION. Yes, you hear me right. And, no, it does not require any changes any in the global routing infrastructure - as implemented now, and most OS kernels (those which aren't broken-as-designed, grin) would do the trick just fine. None of that dual-stack stupidity, and, of course, no chicken-and-egg problem if the servers and gateways can be made to respect really old and well-established standards. DNS and most applications would need some (fairly trivial) updating, though, to work properly with the extended addressing; and sysadmins would need to do tweaks in their configs since some mythology-driven "security" can get in the way. But they don't have to do that en mass and all at once. The most obvious solution to the non-problem of address space shortage is the hardest to notice, ain't it? --vadim P.S. Hfr YFEE gb ebhgr orgjrra cevingr nqqerff fcnprf bire choyvpnyyl ebhgrq fcnpr, Yhxr. Guvax bs cevingr nqqerff ovgf nf n evtug-fvqr rkgrafvba gb gur sbhe-bpgrg choyvp nqqerff. P.P.S. Gb rkgraq shegure, nygreangr gjb qvfgvapg cevingr nqqerff fcnprf, nf znal gvzrf nf lbh pna svg vagb gur urnqre. From dustinnanog at gmail.com Mon Mar 7 14:06:49 2011 From: dustinnanog at gmail.com (Dustin Swinford) Date: Mon, 7 Mar 2011 14:06:49 -0600 Subject: Ethernet circuit testing Message-ID: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> More often on Ethernet services, we experience a customer wanting to see more than an Ookla based server test from our network. Our hands in the field are limited in the number of Ethernet smart loopback devices that they own. If we do have a tester on site, we can generate traffic from an Exfo purpose built appliance toward the loop and determine results. Too often, we have found things such as ftp downloads to be unreliable based on use of server, windows PC doing the download, etc. What other methods are you guys using for testing these services? From dholmes at mwdh2o.com Mon Mar 7 18:13:49 2011 From: dholmes at mwdh2o.com (Holmes,David A) Date: Mon, 7 Mar 2011 16:13:49 -0800 Subject: Ethernet circuit testing In-Reply-To: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> References: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> Message-ID: <922ACC42D498884AA02B3565688AF99531DB5A4027@USEXMBS01.mwd.h2o> EXFO purchased the BRIX active management system a couple of years ago. BRIX can be used to determine basic rtt, packet loss, jitter, and also contains a suite of application tests such as ftp, various voice codecs, etc. -----Original Message----- From: Dustin Swinford [mailto:dustinnanog at gmail.com] Sent: Monday, March 07, 2011 12:07 PM To: nanog at nanog.org Subject: Ethernet circuit testing More often on Ethernet services, we experience a customer wanting to see more than an Ookla based server test from our network. Our hands in the field are limited in the number of Ethernet smart loopback devices that they own. If we do have a tester on site, we can generate traffic from an Exfo purpose built appliance toward the loop and determine results. Too often, we have found things such as ftp downloads to be unreliable based on use of server, windows PC doing the download, etc. What other methods are you guys using for testing these services? From jackson.tim at gmail.com Mon Mar 7 18:26:18 2011 From: jackson.tim at gmail.com (Tim Jackson) Date: Mon, 7 Mar 2011 18:26:18 -0600 Subject: Ethernet circuit testing In-Reply-To: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> References: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> Message-ID: http://documents.exfo.com/specsheets/ETS-1000L-angHR.pdf We use these for testing, much cheaper than a full test set... On Mon, Mar 7, 2011 at 2:06 PM, Dustin Swinford wrote: > More often on Ethernet services, we experience a customer wanting to see > more than an Ookla based server test from our network. Our hands in the > field are limited in the number of Ethernet smart loopback devices that > they > own. If we do have a tester on site, we can generate traffic from an Exfo > purpose built appliance toward the loop and determine results. Too often, > we have found things such as ftp downloads to be unreliable based on use of > server, windows PC doing the download, etc. What other methods are you > guys > using for testing these services? > > > > > > > > From joey.liuyq at gmail.com Mon Mar 7 11:32:39 2011 From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu) Date: Mon, 7 Mar 2011 11:32:39 -0600 Subject: About the different causes of multiple origin ASN(MOAS) problem Message-ID: Hi, I'm trying to find all causes of multiple origin AS problem(MOAS) as follows, but not sure if it's complete. Also please let me know how popular each item is, especially item 3 and 4 that I'm very curious about. 1. Internet Exchange Points, we have observed a list of this prefixes, although they generally are not announced to the DFZ. 2. Anycast, rare, but occurs sometimes, for example, 192.88.99.0/24, 2002::/16, and 2001::/32 3. Multi-homing with Private AS number 4. Multi-homing using static route (customer doesn't have AS number) 5. Misconfiguration 6. Hijacking 7. What else? Thanks, Yaoqing From rdobbins at arbor.net Mon Mar 7 19:02:19 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 8 Mar 2011 01:02:19 +0000 Subject: About the different causes of multiple origin ASN(MOAS) problem In-Reply-To: References: Message-ID: <6A23D7CB-9DA4-48DF-B655-B1397C573BF6@arbor.net> On Mar 8, 2011, at 1:32 AM, Yaoqing(Joey) Liu wrote: > I'm trying to find all causes of multiple origin AS problem(MOAS) as > follows, but not sure if it's complete. 1. MOAS isn't necessarily a 'problem'; it's fairly common, these days, and has been for quite some time. The actual problem is the inability to determine when it's intentional and not evil, vs. unintentional or intentional and evil. 2. There's already a fair body of work on this topic, as a Web search for "multiple origin as" reveals. Check the NANOG archives for Lixia's preso, among others. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From mksmith at adhost.com Mon Mar 7 19:07:46 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 8 Mar 2011 01:07:46 +0000 Subject: NANOG List Outages Message-ID: Hello: We had a system issue over the weekend that interrupted delivery of all of the NANOG mailing lists. We are working presently to clear the queues of the various applications that service the lists. I anticipate we will have "complete" delivery within a few hours. If you find that messages you sent to the lists have not been processed and you feel they need to be part of the lists, please send your message(s) again. We apologize for any inconvenience this may have caused. If you have further issues please send emal to admins at nanog.org and we will do our best to assist you. Regards, Mike On behalf of the NANOG Communications Committee -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From sherwin.ang at gmail.com Mon Mar 7 19:23:46 2011 From: sherwin.ang at gmail.com (Sherwin Ang) Date: Tue, 8 Mar 2011 09:23:46 +0800 Subject: Ethernet circuit testing In-Reply-To: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> References: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> Message-ID: RFC2544 testers. On Tue, Mar 8, 2011 at 4:06 AM, Dustin Swinford wrote: > More often on Ethernet services, we experience a customer wanting to see > more than an Ookla based server test from our network. ?Our hands in the > field are limited in the number of Ethernet smart loopback devices that they > own. ?If we do have a tester on site, we can generate traffic from an Exfo > purpose built appliance toward the loop and determine results. ?Too often, > we have found things such as ftp downloads to be unreliable based on use of > server, windows PC doing the download, etc. ?What other methods are you guys > using for testing these services? > > > > > > > > From morrowc.lists at gmail.com Mon Mar 7 19:43:24 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Mon, 7 Mar 2011 20:43:24 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: <1299498200.29652.40.camel@kotti.kotovnik.com> References: <1299498200.29652.40.camel@kotti.kotovnik.com> Message-ID: On Mon, Mar 7, 2011 at 6:43 AM, Vadim Antonov wrote: > > --vadim > > P.S. Hfr YFEE gb ebhgr orgjrra cevingr nqqerff fcnprf bire choyvpnyyl > ebhgrq fcnpr, Yhxr. Guvax bs cevingr nqqerff ovgf nf n evtug-fvqr > rkgrafvba gb gur sbhe-bpgrg choyvp nqqerff. > > P.P.S. Gb rkgraq shegure, nygreangr gjb qvfgvapg cevingr nqqerff fcnprf, > nf znal gvzrf nf lbh pna svg vagb gur urnqre. Gbqq Haqrejbbq jbhyq ybir lbhe fbyhgvba! Cebcf! From marka at isc.org Mon Mar 7 19:48:09 2011 From: marka at isc.org (Mark Andrews) Date: Tue, 08 Mar 2011 12:48:09 +1100 Subject: IPv4 address shortage? Really? In-Reply-To: Your message of "Mon, 07 Mar 2011 03:43:20 -0800." <1299498200.29652.40.camel@kotti.kotovnik.com> References: <1299498200.29652.40.camel@kotti.kotovnik.com> Message-ID: <20110308014809.53CD0BD1629@drugs.dv.isc.org> This has been thought of before, discussed and rejected. In message <1299498200.29652.40.camel at kotti.kotovnik.com>, Vadim Antonov writes : > I'm wondering (and that shows that I have nothing better to do at 3:30am > on Monday...) how many people around here realize that the plain old > IPv4 - as widely implemented and specified in standard RFCs can be > easily used to connect pretty much arbitrary number (arbitrary means > >2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION. Yes, you hear > me right. > > And, no, it does not require any changes any in the global routing > infrastructure - as implemented now, and most OS kernels (those which > aren't broken-as-designed, grin) would do the trick just fine. None of > that dual-stack stupidity, and, of course, no chicken-and-egg problem if > the servers and gateways can be made to respect really old and > well-established standards. > > DNS and most applications would need some (fairly trivial) updating, > though, to work properly with the extended addressing; and sysadmins > would need to do tweaks in their configs since some mythology-driven > "security" can get in the way. But they don't have to do that en mass > and all at once. > > The most obvious solution to the non-problem of address space shortage > is the hardest to notice, ain't it? > > --vadim > > P.S. Hfr YFEE gb ebhgr orgjrra cevingr nqqerff fcnprf bire choyvpnyyl > ebhgrq fcnpr, Yhxr. Guvax bs cevingr nqqerff ovgf nf n evtug-fvqr > rkgrafvba gb gur sbhe-bpgrg choyvp nqqerff. > > P.P.S. Gb rkgraq shegure, nygreangr gjb qvfgvapg cevingr nqqerff fcnprf, > nf znal gvzrf nf lbh pna svg vagb gur urnqre. > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nitzan.tzelniker at gmail.com Sun Mar 6 14:46:47 2011 From: nitzan.tzelniker at gmail.com (Nitzan Tzelniker) Date: Sun, 6 Mar 2011 22:46:47 +0200 Subject: Switch with 10 Gig and GRE support in hardware. In-Reply-To: References: <4d6d0c36.8658dc0a.1531.7c08@mx.google.com> Message-ID: HP A5820 (3com/H3C in the past ) is doing 24*10GE + GRE (we test it ) btw in the latest release it is also doing mpls (not test it yet ) Nitzan On Tue, Mar 1, 2011 at 17:28, Leigh Porter wrote: > OK. Please show me a ?switch? that will terminate Layer 3 GRE tunnels.. > > > > If it does GRE then it is making Layer 3 forwarding decisions which is a > router function. It may be built into a switch as well, but it is still a > router. > > > > -- > > Leigh Porter > > > > > > From: tsison at gmail.com [mailto:tsison at gmail.com] > Sent: 01 March 2011 15:10 > To: sthaug at nethelp.no; Leigh Porter > Cc: nanog at nanog.org > Subject: Re: Switch with 10 Gig and GRE support in hardware. > > > > is the requirment still 1-2 U switch? > > ----- Reply message ----- > From: sthaug at nethelp.no > Date: Tue, Mar 1, 2011 4:44 am > Subject: Switch with 10 Gig and GRE support in hardware. > To: > Cc: > > > > Juniper MX80 does all this. > > 1. It's not a switch (so don't expect "switch pricing"). > 2. It doesn't offer 12 x 10GE ports. > > And I believe this has been mentioned earlier in the same thread... > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no > > > > > From nanog at jima.tk Mon Mar 7 20:15:20 2011 From: nanog at jima.tk (Jima) Date: Mon, 07 Mar 2011 20:15:20 -0600 Subject: IPv4 address shortage? Really? In-Reply-To: <1299498200.29652.40.camel@kotti.kotovnik.com> References: <1299498200.29652.40.camel@kotti.kotovnik.com> Message-ID: <4D759138.7080002@jima.tk> On 3/7/2011 5:43 AM, Vadim Antonov wrote: > I'm wondering (and that shows that I have nothing better to do at 3:30am > on Monday...) how many people around here realize that the plain old > IPv4 - as widely implemented and specified in standard RFCs can be > easily used to connect pretty much arbitrary number (arbitrary means >> 2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION. Yes, you hear > me right. This seems like either truly bizarre trolling, or the misguided idea of someone who's way too invested in IPv4 and hasn't made any necessary plans or steps to implement IPv6. To implement this -- which, to begin with, seems like a bad idea to me (and judging by Mr. Andrews' response, others) -- you'd have to overhaul software on many, many computers, routers, and other devices. (Wait, why does this sound familiar?) Of course, the groundwork would need to be laid out and discussed, which will probably cost us a few years...too bad we don't have a plan that could be put into action sooner, or maybe even was already deployed. Anyway, the needless ROT13 text fairly well convinced me that our messages may be traveling over an ethernet bridge. Jima From scott.brim at gmail.com Mon Mar 7 20:41:38 2011 From: scott.brim at gmail.com (Scott W Brim) Date: Mon, 7 Mar 2011 21:41:38 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: <20110308014809.53CD0BD1629@drugs.dv.isc.org> References: <1299498200.29652.40.camel@kotti.kotovnik.com> <20110308014809.53CD0BD1629@drugs.dv.isc.org> Message-ID: There are a number of reasons why you want IP addresses to be globally unique, even if they are not globally routed. From warren at kumari.net Mon Mar 7 20:46:47 2011 From: warren at kumari.net (Warren Kumari) Date: Mon, 7 Mar 2011 21:46:47 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: <20110308014809.53CD0BD1629@drugs.dv.isc.org> References: <1299498200.29652.40.camel@kotti.kotovnik.com> <20110308014809.53CD0BD1629@drugs.dv.isc.org> Message-ID: On Mar 7, 2011, at 8:48 PM, Mark Andrews wrote: > > This has been thought of before, discussed and rejected. But has this: http://tools.ietf.org/id/draft-terrell-math-quant-ternary-logic-of-binary-sys-12.txt ? Please read and explain *exactly* why it doesn't work... W > > In message <1299498200.29652.40.camel at kotti.kotovnik.com>, Vadim Antonov writes > : >> I'm wondering (and that shows that I have nothing better to do at 3:30am >> on Monday...) how many people around here realize that the plain old >> IPv4 - as widely implemented and specified in standard RFCs can be >> easily used to connect pretty much arbitrary number (arbitrary means >>> 2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION. Yes, you hear >> me right. >> >> And, no, it does not require any changes any in the global routing >> infrastructure - as implemented now, and most OS kernels (those which >> aren't broken-as-designed, grin) would do the trick just fine. None of >> that dual-stack stupidity, and, of course, no chicken-and-egg problem if >> the servers and gateways can be made to respect really old and >> well-established standards. >> >> DNS and most applications would need some (fairly trivial) updating, >> though, to work properly with the extended addressing; and sysadmins >> would need to do tweaks in their configs since some mythology-driven >> "security" can get in the way. But they don't have to do that en mass >> and all at once. >> >> The most obvious solution to the non-problem of address space shortage >> is the hardest to notice, ain't it? >> >> --vadim >> >> P.S. Hfr YFEE gb ebhgr orgjrra cevingr nqqerff fcnprf bire choyvpnyyl >> ebhgrq fcnpr, Yhxr. Guvax bs cevingr nqqerff ovgf nf n evtug-fvqr >> rkgrafvba gb gur sbhe-bpgrg choyvp nqqerff. >> >> P.P.S. Gb rkgraq shegure, nygreangr gjb qvfgvapg cevingr nqqerff fcnprf, >> nf znal gvzrf nf lbh pna svg vagb gur urnqre. >> >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org W PS: :-) From patrick at ianai.net Mon Mar 7 20:49:55 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 7 Mar 2011 21:49:55 -0500 Subject: A BGP issue? In-Reply-To: References: Message-ID: <3EB9AA75-7CBE-4571-871A-CA4DC9A0A978@ianai.net> On Mar 7, 2011, at 14:27, Greg Ihnen wrote: > I run a small network on a mission base in the Amazon jungle which is fed by a satellite internet connection. We had an outage from Feb 25th to the 28th where we had no connectivity with email, http/s, ftp, Skype would indicate it's connected but even chatting failed, basically everything stopped working except for ICMP. I could ping everywhere just fine. I started doing traceroutes and they all were very odd, all not reaching their destination and some hopping all over creation before dying. But if I did traceroute with ICMP it worked fine. Does this indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed Hughesnet which is the service they resell. I'm wondering what kind of problem would let ping work fine but not any of the other protocols. It also seems odd that I could traceroute via UDP part way to a destination but then it would fail if the problem was my own provider. Thanks. > > If this is the wrong forum for this post I'm sorry and please just hit delete. If this is the wrong forum but you'd be kind enough to share your expertise please reply off-list. Thanks! Honestly, I would rate this as one of the most on-topic posts in a while. BGP only handles reachability, not higher level protocols. (Of course, you can h4x0r anything to do jus about anything, but we are talking the general case here.) If you can ping, BGP is working. If you can ping and cannot use TCP, then something other than BGP is at fault. I've seen strange things like someone enabling TCP compression (common on very small or very expensive links) one side but not the other, which then allowed ICMP and UDP but not TCP. It is a great way to annoy someone. "See, I can ping, it must be your side!" Have you tried TCP traceroute? Or telnetting to port 80? -- TTFN, patrick > Here's some examples of the traceroutes I saved during the outage. > > Using UDP: > > Gregs-MacBook-Pro:~ GregIhnen$ traceroute metaconi.com > traceroute to metaconi.com (70.32.39.205), 64 hops max, 52 byte packets > 1 192.168.7.1 (192.168.7.1) 1541.165 ms 25.665 ms 39.211 ms > 2 * * * > 3 192.168.14.254 (192.168.14.254) 625.710 ms 860.264 ms 694.238 ms > 4 192.168.180.5 (192.168.180.5) 645.666 ms 757.161 ms 664.785 ms > 5 10.254.253.158 (10.254.253.158) 738.661 ms 801.487 ms 728.139 ms > 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 726.884 ms 733.989 ms 647.736 ms > 7 te3-4.miami7.mia.seabone.net (195.22.199.97) 740.233 ms 694.619 ms 685.464 ms > 8 206.111.1.161.ptr.us.xo.net (206.111.1.161) 639.077 ms 741.495 ms 679.880 ms > 9 te-4-1-0.rar3.miami-fl.us.xo.net (207.88.12.161) 650.312 ms 612.386 ms 660.452 ms > 10 te-3-2-0.rar3.atlanta-ga.us.xo.net (207.88.12.5) 787.079 ms 725.495 ms 685.068 ms > 11 te-11-0-0.rar3.washington-dc.us.xo.net (207.88.12.10) 760.002 ms 828.076 ms 702.041 ms > 12 ae0d0.mcr2.chicago-il.us.xo.net (216.156.0.166) 719.324 ms 641.274 ms 689.997 ms > 13 ae1d0.mcr1.chicago-il.us.xo.net (216.156.1.81) 669.613 ms 813.794 ms 737.211 ms > 14 edge1.chi1.ubiquityservers.com (216.55.8.30) 729.875 ms 751.481 ms 730.088 ms > 15 * * * > 16 * * * > 17 * * * > 18 * * * > 19 * * * > 20 * * * > 21 * * * > 22 * * * > 23 * * * > 24 * * * > 25 * * * > 26 * * * > 27 * * > > > Now here it is again doing traceroute via ICMP: > > Gregs-MacBook-Pro:~ GregIhnen$ traceroute -I metaconi.com > traceroute to metaconi.com (70.32.39.205), 64 hops max, 72 byte packets > 1 192.168.7.1 (192.168.7.1) 5.254 ms 3.059 ms 2.578 ms > 2 * * * > 3 192.168.14.254 (192.168.14.254) 1511.146 ms 711.304 ms 822.967 ms > 4 192.168.180.5 (192.168.180.5) 712.672 ms 821.990 ms 713.009 ms > 5 10.254.253.158 (10.254.253.158) 823.244 ms 711.764 ms 823.219 ms > 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 712.640 ms 613.306 ms 614.429 ms > 7 te3-4.miami7.mia.seabone.net (195.22.199.97) 823.232 ms 711.881 ms 823.166 ms > 8 206.111.1.161.ptr.us.xo.net (206.111.1.161) 712.765 ms 822.398 ms 712.531 ms > 9 te-4-1-0.rar3.miami-fl.us.xo.net (207.88.12.161) 822.809 ms 920.831 ms 712.399 ms > 10 te-3-2-0.rar3.atlanta-ga.us.xo.net (207.88.12.5) 823.288 ms 711.478 ms 822.887 ms > 11 te-11-0-0.rar3.washington-dc.us.xo.net (207.88.12.10) 712.705 ms 822.287 ms 712.713 ms > 12 * ae0d0.mcr2.chicago-il.us.xo.net (216.156.0.166) 738.656 ms 919.752 ms > 13 ae1d0.mcr1.chicago-il.us.xo.net (216.156.1.81) 921.381 ms 920.884 ms 1228.683 ms > 14 edge1.chi1.ubiquityservers.com (216.55.8.30) 921.560 ms 920.482 ms 921.634 ms > 15 relativity.mrk.com (70.32.39.205) 880.318 ms 753.150 ms 823.285 ms > Gregs-MacBook-Pro:~ GregIhnen$ > > Here's an example of a UDP traceroute going all over creation: > > Gregs-MacBook-Pro:~ GregIhnen$ traceroute skype.com > traceroute to skype.com (78.141.177.7), 64 hops max, 52 byte packets > 1 192.168.7.1 (192.168.7.1) 18.939 ms 4.596 ms 27.124 ms > 2 * * * > 3 192.168.14.254 (192.168.14.254) 724.034 ms 704.520 ms 823.886 ms > 4 192.168.180.5 (192.168.180.5) 711.962 ms 704.606 ms 823.208 ms > 5 10.254.253.158 (10.254.253.158) 712.622 ms 912.870 ms 921.471 ms > 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 712.642 ms 822.307 ms 712.720 ms > 7 * te9-1.ccr01.mia03.atlas.cogentco.com (154.54.11.37) 3692.277 ms 702.345 ms > 8 te9-1.ccr01.mia03.atlas.cogentco.com (154.54.11.37) 823.172 ms 920.050 ms 921.612 ms > 9 te8-2.ccr01.mia01.atlas.cogentco.com (154.54.28.245) 921.681 ms > te8-7.ccr02.mia01.atlas.cogentco.com (154.54.1.185) 703.270 ms > te8-2.ccr02.mia01.atlas.cogentco.com (154.54.2.153) 730.152 ms > 10 te0-0-0-5.ccr21.atl01.atlas.cogentco.com (154.54.30.33) 797.769 ms > te2-1.ccr02.atl01.atlas.cogentco.com (154.54.3.25) 913.513 ms > te0-1-0-4.ccr21.atl01.atlas.cogentco.com (154.54.24.161) 782.095 ms > 11 te0-4-0-7.ccr21.dca01.atlas.cogentco.com (154.54.42.189) 814.870 ms > te0-5-0-7.ccr22.dca01.atlas.cogentco.com (154.54.42.201) 815.878 ms > te0-2-0-3.ccr21.dca01.atlas.cogentco.com (154.54.24.9) 912.453 ms > 12 te0-5-0-6.ccr22.jfk02.atlas.cogentco.com (154.54.42.30) 913.183 ms > te0-2-0-2.ccr21.jfk02.atlas.cogentco.com (154.54.26.186) 913.078 ms > te0-4-0-7.ccr22.jfk02.atlas.cogentco.com (154.54.41.14) 913.268 ms > 13 te2-8.ccr02.lon02.atlas.cogentco.com (154.54.30.22) 833.515 ms > te0-4-0-7.mpd22.jfk02.atlas.cogentco.com (154.54.41.30) 702.568 ms > te0-4-0-7.ccr22.bos01.atlas.cogentco.com (154.54.44.50) 815.549 ms > 14 te0-3-0-2.ccr21.bos01.atlas.cogentco.com (154.54.44.14) 1010.769 ms > te0-1-0-5.ccr21.bos01.atlas.cogentco.com (154.54.44.30) 913.070 ms > te4-8.ccr01.lon01.atlas.cogentco.com (130.117.0.186) 913.076 ms > 15 te7-3.mpd02.lon01.atlas.cogentco.com (154.54.30.130) 913.495 ms > te4-4.mpd02.lon01.atlas.cogentco.com (130.117.1.134) 831.442 ms > te1-1.mpd02.lon01.atlas.cogentco.com (154.54.5.162) 811.198 ms > 16 te0-0-0-0.mpd21.par01.atlas.cogentco.com (130.117.2.5) 913.200 ms 912.636 ms > te1-4.ccr01.bru01.atlas.cogentco.com (130.117.51.106) 921.496 ms > 17 te0-0-0-0.mpd21.par01.atlas.cogentco.com (130.117.2.5) 913.344 ms 920.902 ms > te1-4.ccr01.bru01.atlas.cogentco.com (130.117.51.106) 921.368 ms > 18 149.6.134.86 (149.6.134.86) 920.406 ms 1014.226 ms * > 19 213.166.61.194 (213.166.61.194) 959.442 ms 828.583 ms 920.909 ms > 20 213.135.247.42 (213.135.247.42) 1019.971 ms > 78.141.177.7 (78.141.177.7) 988.848 ms > 213.135.247.42 (213.135.247.42) 1011.307 ms > Gregs-MacBook-Pro:~ GregIhnen$ > > UDP traceroute worked to Google though I still couldn't load their pages > > Gregs-MacBook-Pro:~ GregIhnen$ traceroute google.com > traceroute to google.com (74.125.229.114), 64 hops max, 52 byte packets > 1 192.168.7.1 (192.168.7.1) 5.023 ms 3.971 ms 6.712 ms > 2 * * * > 3 192.168.14.254 (192.168.14.254) 1471.985 ms 643.770 ms 785.534 ms > 4 192.168.180.5 (192.168.180.5) 712.715 ms 704.409 ms 626.374 ms > 5 10.254.253.158 (10.254.253.158) 808.083 ms 647.244 ms 619.878 ms > 6 fe11-0-5.miami1.mia.seabone.net (195.22.199.77) 776.534 ms 711.870 ms 640.372 ms > 7 * te7-1.miami7.mia.seabone.net (195.22.199.109) 810.819 ms 731.713 ms > 8 google.miami7.mia.seabone.net (89.221.41.18) 712.471 ms > google.miami7.mia.seabone.net (89.221.41.74) 703.638 ms > google.miami7.mia.seabone.net (89.221.41.18) 704.814 ms > 9 209.85.253.116 (209.85.253.116) 822.336 ms 761.621 ms > 209.85.253.74 (209.85.253.74) 709.705 ms > 10 209.85.254.180 (209.85.254.180) 705.062 ms 702.723 ms 824.497 ms > 11 74.125.229.114 (74.125.229.114) 712.196 ms 704.509 ms 596.077 ms > Gregs-MacBook-Pro:~ GregIhnen$ > > > From joey.liuyq at gmail.com Mon Mar 7 21:14:41 2011 From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu) Date: Mon, 7 Mar 2011 21:14:41 -0600 Subject: NANOG Digest, Vol 38, Issue 26 In-Reply-To: References: Message-ID: > > Message: 9 > Date: Mon, 7 Mar 2011 11:32:39 -0600 > From: "Yaoqing(Joey) Liu" > Subject: About the different causes of multiple origin ASN(MOAS) > problem > To: nanog at nanog.org > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > I'm trying to find all causes of multiple origin AS problem(MOAS) as > follows, but not sure if it's complete. Also please let me know how popular > each item is, especially item 3 and 4 that I'm very curious about. > > 1. Internet Exchange Points, we have observed a list of this prefixes, > although they generally are not announced to the DFZ. > 2. Anycast, rare, but occurs sometimes, for example, 192.88.99.0/24, > 2002::/16, and 2001::/32 > 3. Multi-homing with Private AS number > 4. Multi-homing using static route (customer doesn't have AS number) > 5. Misconfiguration > 6. Hijacking > 7. What else? > > Thanks, > Yaoqing > > > ------------------------------ > > Message: 10 > Date: Tue, 8 Mar 2011 01:02:19 +0000 > From: "Dobbins, Roland" > Subject: Re: About the different causes of multiple origin ASN(MOAS) > problem > To: nanog group > Message-ID: <6A23D7CB-9DA4-48DF-B655-B1397C573BF6 at arbor.net> > Content-Type: text/plain; charset="us-ascii" > > > On Mar 8, 2011, at 1:32 AM, Yaoqing(Joey) Liu wrote: > > > I'm trying to find all causes of multiple origin AS problem(MOAS) as > > follows, but not sure if it's complete. > > 1. MOAS isn't necessarily a 'problem'; it's fairly common, these days, > and has been for quite some time. The actual problem is the inability to > determine when it's intentional and not evil, vs. unintentional or > intentional and evil. > Good point. That's why I need to have a complete cause list first, then I can try to tell the evil from the good. > > 2. There's already a fair body of work on this topic, as a Web search > for "multiple origin as" reveals. Check the NANOG archives for Lixia's > preso, among others. > I know a lot of previous work about MOAS, but they were not comprehensive enough to drill down to the prefix level and also the results have been outdated. We need to know what things were going on recently. Yaoqing > > ----------------------------------------------------------------------- > Roland Dobbins // > > The basis of optimism is sheer terror. > > -- Oscar Wilde > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 38, Issue 26 > ************************************* > From randy at psg.com Mon Mar 7 21:17:55 2011 From: randy at psg.com (Randy Bush) Date: Tue, 08 Mar 2011 12:17:55 +0900 Subject: NANOG Digest, Vol 38, Issue 26 In-Reply-To: References: Message-ID: > Good point. That's why I need to have a complete cause list first, > then I can try to tell the evil from the good. there is no complete cause list you can not know evil from good because you have no way of knowing intent haven't you ucla people figured this out yet? randy From bmanning at vacation.karoshi.com Mon Mar 7 22:09:39 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Mar 2011 04:09:39 +0000 Subject: IPv4 address shortage? Really? In-Reply-To: <4D759138.7080002@jima.tk> References: <1299498200.29652.40.camel@kotti.kotovnik.com> <4D759138.7080002@jima.tk> Message-ID: <20110308040939.GA26901@vacation.karoshi.com.> On Mon, Mar 07, 2011 at 08:15:20PM -0600, Jima wrote: > On 3/7/2011 5:43 AM, Vadim Antonov wrote: > >I'm wondering (and that shows that I have nothing better to do at 3:30am > >on Monday...) how many people around here realize that the plain old > >IPv4 - as widely implemented and specified in standard RFCs can be > >easily used to connect pretty much arbitrary number (arbitrary means > >>2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION. Yes, you hear > >me right. > > This seems like either truly bizarre trolling, or the misguided idea > of someone who's way too invested in IPv4 and hasn't made any necessary > plans or steps to implement IPv6. To implement this -- which, to begin > with, seems like a bad idea to me (and judging by Mr. Andrews' response, > others) -- you'd have to overhaul software on many, many computers, > routers, and other devices. (Wait, why does this sound familiar?) Of > course, the groundwork would need to be laid out and discussed, which > will probably cost us a few years...too bad we don't have a plan that > could be put into action sooner, or maybe even was already deployed. > > Anyway, the needless ROT13 text fairly well convinced me that our > messages may be traveling over an ethernet bridge. > > Jima well... not that it gained any traction atall, but given the actual size/complexity of the global interconnect mesh, we -could- ease the transition timing by many years with the following administrative change. No tricks, no OS hacks, no changes to software anywhere.. just a bit of renumbering... recipie: the usable IPv4 ranges RFC 1918 Step one: Invert RFC 1918 to define the global Internets interconnection mesh. Step two: make all other usable IPv4 space "private". Serves 2,000,000 million clients w/o changing to a new protocol family. Enjoy! --bill From joey.liuyq at gmail.com Mon Mar 7 22:12:57 2011 From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu) Date: Mon, 7 Mar 2011 22:12:57 -0600 Subject: NANOG Digest, Vol 38, Issue 26 In-Reply-To: References: Message-ID: On Mon, Mar 7, 2011 at 9:17 PM, Randy Bush wrote: > > Good point. That's why I need to have a complete cause list first, > > then I can try to tell the evil from the good. > > there is no complete cause list > I admit it's basically impossible to get a complete list, but at least, I want to have a try to make it as complete as possible in order to understand the issue. I think industry people should have more experience to give me the answer, since all the data come from the real practice. For example, how popular private AS number used for multi-homing, and how popular one organization has no AS number using static routing. Yaoqing > > you can not know evil from good because you have no way of knowing > intent > > > haven't you ucla people figured this out yet? > > randy > From joelja at bogus.com Mon Mar 7 22:41:23 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 07 Mar 2011 20:41:23 -0800 Subject: why hp bladeserver chassis have a sudden interest in thailand. Message-ID: <4D75B373.2040506@bogus.com> http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451 As a potentially cautionary tale for the squatting on unused pieces of address space either in your network or applications. drive slow (and filter 22 outgoing to 49.48.46.49 until you get new firmware) joel From jra at baylink.com Mon Mar 7 22:47:31 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 7 Mar 2011 23:47:31 -0500 (EST) Subject: why hp bladeserver chassis have a sudden interest in thailand. In-Reply-To: <4D75B373.2040506@bogus.com> Message-ID: <31657724.1969.1299559651369.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Joel Jaeggli" > http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451 > > As a potentially cautionary tale for the squatting on unused pieces of > address space either in your network or applications. > > drive slow (and filter 22 outgoing to 49.48.46.49 until you get new > firmware) (HP Blades apparently depended on rDNS for 49.48/16 failing hard, which stopped happening when the block was allocated) Hey, isn't this what I was talking about a week or two ago: applications depending on DNS not lying to them about whether things actually exist or not? (Ok, it's a *bit* sideways, but not much...) Cheers, -- jra From toasty at dragondata.com Mon Mar 7 23:16:55 2011 From: toasty at dragondata.com (Kevin Day) Date: Mon, 7 Mar 2011 23:16:55 -0600 Subject: why hp bladeserver chassis have a sudden interest in thailand. In-Reply-To: <31657724.1969.1299559651369.JavaMail.root@benjamin.baylink.com> References: <31657724.1969.1299559651369.JavaMail.root@benjamin.baylink.com> Message-ID: <5E24D630-0113-4CE6-8CF0-29F3C0B8A683@dragondata.com> On Mar 7, 2011, at 10:47 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Joel Jaeggli" > >> http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451 >> >> As a potentially cautionary tale for the squatting on unused pieces of >> address space either in your network or applications. >> >> drive slow (and filter 22 outgoing to 49.48.46.49 until you get new >> firmware) > > (HP Blades apparently depended on rDNS for 49.48/16 failing hard, which > stopped happening when the block was allocated) For those at home scratching their heads, I ran into this before too when trying to figure out why they were making in-addr.arpa requests over and over again... 49 decimal in ASCII = "1" 48 decimal in ASCII = "0" 46 decimal in ASCII = "." 49 decimal in ASCII = "1" or "10.1" If you had a hard-coded IP address instead of a hostname for its management host, the logic to resolve the hostname would get confused and attempt to do a reverse-dns lookup of the first 4 characters of the ASCII representation of the hostname, and connect to that instead. So, if your management host was "10.1.1.1" the first 4 characters were "10.1" which is 49.48.46.49 if you smash the values of each character into a v4 address and try to grab a PTR record for it. If that lookup failed, it'd fall back to connecting to the IP correctly. Only after 49.48/16 was assigned and started giving out PTR records did this bug actually do anything. It is attempting to SSH to the host at 49.48.46.49 though, which is probably bad. (the above is my own attempt at figuring out what was happening, but might not be 100% accurate) From frnkblk at iname.com Mon Mar 7 23:40:47 2011 From: frnkblk at iname.com (Frank Bulk) Date: Mon, 7 Mar 2011 23:40:47 -0600 Subject: Ethernet circuit testing In-Reply-To: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> References: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> Message-ID: <005201cbdd53$60666b20$21334160$@iname.com> I've heard good things from a neighbor service provider that uses EXFO's EtherSAM. Frank -----Original Message----- From: Dustin Swinford [mailto:dustinnanog at gmail.com] Sent: Monday, March 07, 2011 2:07 PM To: nanog at nanog.org Subject: Ethernet circuit testing More often on Ethernet services, we experience a customer wanting to see more than an Ookla based server test from our network. Our hands in the field are limited in the number of Ethernet smart loopback devices that they own. If we do have a tester on site, we can generate traffic from an Exfo purpose built appliance toward the loop and determine results. Too often, we have found things such as ftp downloads to be unreliable based on use of server, windows PC doing the download, etc. What other methods are you guys using for testing these services? From randy at psg.com Tue Mar 8 00:08:39 2011 From: randy at psg.com (Randy Bush) Date: Tue, 08 Mar 2011 15:08:39 +0900 Subject: why hp bladeserver chassis have a sudden interest in thailand. In-Reply-To: <4D75B373.2040506@bogus.com> References: <4D75B373.2040506@bogus.com> Message-ID: > http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451 rofl. the goddesses are indeed just. randy From gbonser at seven.com Tue Mar 8 01:18:43 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 7 Mar 2011 23:18:43 -0800 Subject: IPv4 address shortage? Really? In-Reply-To: <20110308040939.GA26901@vacation.karoshi.com.> References: <1299498200.29652.40.camel@kotti.kotovnik.com><4D759138.7080002@jima.tk> <20110308040939.GA26901@vacation.karoshi.com.> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13F79@RWC-EX1.corp.seven.com> > well... not that it gained any traction atall, but given > the actual size/complexity of the global interconnect mesh, > we -could- ease the transition timing by many years with the > following administrative change. No tricks, no OS hacks, > no changes to software anywhere.. just a bit of renumbering... > > recipie: > > the usable IPv4 ranges > RFC 1918 > > Step one: Invert RFC 1918 to define the global Internets > interconnection > mesh. > Step two: make all other usable IPv4 space "private". > > Serves 2,000,000 million clients w/o changing to a new protocol > family. > > > Enjoy! > > --bill And I fully expect that to be done at some point or another. Country takes the entire 32bit address space for itself. You want to serve that country? Fine, apply for an allocation out of their /0 and route to it over v6. From gaurab at lahai.com Tue Mar 8 01:27:34 2011 From: gaurab at lahai.com (Gaurab Raj Upadhaya) Date: Tue, 08 Mar 2011 07:27:34 +0000 Subject: About the different causes of multiple origin ASN(MOAS) problem In-Reply-To: References: Message-ID: <4D75DA66.30509@lahai.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/7/11 5:32 PM, Yaoqing(Joey) Liu wrote: > 4. Multi-homing using static route (customer doesn't have AS number) 4a: Upstream forces static routes, because they can't support 4 byte ASN (or don't want to). - -gaurab > 5. Misconfiguration > 6. Hijacking > 7. What else? - -- http://www.gaurab.org.np/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.16 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk112mYACgkQSo7fU26F3X2m7QCgiE5VDvKanS6EhhPy9N7sv6CK nhEAn0Smmxjoi2K9Tn/1lo74/iYzTEHQ =h7tS -----END PGP SIGNATURE----- From hank at efes.iucc.ac.il Tue Mar 8 01:25:52 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 08 Mar 2011 09:25:52 +0200 Subject: A BGP issue? In-Reply-To: <3EB9AA75-7CBE-4571-871A-CA4DC9A0A978@ianai.net> References: Message-ID: <5.1.0.14.2.20110308092120.035e89f8@efes.iucc.ac.il> At 21:49 07/03/2011 -0500, Patrick W. Gilmore wrote: >On Mar 7, 2011, at 14:27, Greg Ihnen wrote: > > > I run a small network on a mission base in the Amazon jungle which is > fed by a satellite internet connection. We had an outage from Feb 25th to > the 28th where we had no connectivity with email, http/s, ftp, Skype > would indicate it's connected but even chatting failed, basically > everything stopped working except for ICMP. I could ping everywhere just > fine. I started doing traceroutes and they all were very odd, all not > reaching their destination and some hopping all over creation before > dying. But if I did traceroute with ICMP it worked fine. Does this > indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed > Hughesnet which is the service they resell. I'm wondering what kind of > problem would let ping work fine but not any of the other protocols. It > also seems odd that I could traceroute via UDP part way to a destination > but then it would fail if the problem was my own provider. Thanks. > > > > If this is the wrong forum for this post I'm sorry and please just hit > delete. If this is the wrong forum but you'd be kind enough to share your > expertise please reply off-list. Thanks! > >Honestly, I would rate this as one of the most on-topic posts in a while. +1. When you have http working I suggest running: http://netalyzr.icsi.berkeley.edu/index.html to give you a benchmark of what your connection can do in the way of protocols. Regards, Hank From nathan at atlasnetworks.us Tue Mar 8 01:51:46 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 8 Mar 2011 07:51:46 +0000 Subject: IPv4 address shortage? Really? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13F79@RWC-EX1.corp.seven.com> References: <1299498200.29652.40.camel@kotti.kotovnik.com><4D759138.7080002@jima.tk> <20110308040939.GA26901@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0BC13F79@RWC-EX1.corp.seven.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3C0ACF@ex-mb-1.corp.atlasnetworks.us> > And I fully expect that to be done at some point or another. Country > takes the entire 32bit address space for itself. You want to serve > that > country? Fine, apply for an allocation out of their /0 and route to it > over v6. What happens when countries are formed from secession? Does one half have to renumber? ;) From ops.lists at gmail.com Tue Mar 8 02:21:32 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 8 Mar 2011 13:51:32 +0530 Subject: IPv4 address shortage? Really? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3C0ACF@ex-mb-1.corp.atlasnetworks.us> References: <1299498200.29652.40.camel@kotti.kotovnik.com> <4D759138.7080002@jima.tk> <20110308040939.GA26901@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0BC13F79@RWC-EX1.corp.seven.com> <8C26A4FDAE599041A13EB499117D3C286B3C0ACF@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Tue, Mar 8, 2011 at 1:21 PM, Nathan Eisenberg wrote: > > What happens when countries are formed from secession? ?Does one half have to renumber? ?;) > There's a civil war and the winner takes all -- Suresh Ramasubramanian (ops.lists at gmail.com) From randy at psg.com Tue Mar 8 04:24:15 2011 From: randy at psg.com (Randy Bush) Date: Tue, 08 Mar 2011 19:24:15 +0900 Subject: the largest deployment of v6 in japan Message-ID: http://avexnet.or.jp/v6/ http://en.wikipedia.org/wiki/V6_%28band%29 From franck at genius.com Tue Mar 8 04:37:07 2011 From: franck at genius.com (Franck Martin) Date: Tue, 8 Mar 2011 02:37:07 -0800 (PST) Subject: the largest deployment of v6 in japan In-Reply-To: Message-ID: <30699686.184.1299580626045.JavaMail.franck@Macintosh.local> But do they route? ----- Original Message ----- From: "Randy Bush" To: "NANOG Operators' Group" Sent: Tuesday, 8 March, 2011 2:24:15 AM Subject: the largest deployment of v6 in japan http://avexnet.or.jp/v6/ http://en.wikipedia.org/wiki/V6_%28band%29 From avg at kotovnik.com Tue Mar 8 04:41:33 2011 From: avg at kotovnik.com (Vadim Antonov) Date: Tue, 08 Mar 2011 02:41:33 -0800 Subject: A BGP issue? In-Reply-To: <5.1.0.14.2.20110308092120.035e89f8@efes.iucc.ac.il> References: <5.1.0.14.2.20110308092120.035e89f8@efes.iucc.ac.il> Message-ID: <1299580893.29652.183.camel@kotti.kotovnik.com> On Tue, 2011-03-08 at 09:25 +0200, Hank Nussbacher wrote: > At 21:49 07/03/2011 -0500, Patrick W. Gilmore wrote: > >On Mar 7, 2011, at 14:27, Greg Ihnen wrote: > > > > > I run a small network on a mission base in the Amazon jungle which is > > fed by a satellite internet connection. We had an outage from Feb 25th to > > the 28th where we had no connectivity with email, http/s, ftp, Skype > > would indicate it's connected but even chatting failed, basically > > everything stopped working except for ICMP. I could ping everywhere just > > fine. I started doing traceroutes and they all were very odd, all not > > reaching their destination and some hopping all over creation before > > dying. But if I did traceroute with ICMP it worked fine. Does this > > indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed > > Hughesnet which is the service they resell. I'm wondering what kind of > > problem would let ping work fine but not any of the other protocols. It > > also seems odd that I could traceroute via UDP part way to a destination > > but then it would fail if the problem was my own provider. Thanks. > > > > > > If this is the wrong forum for this post I'm sorry and please just hit > > delete. If this is the wrong forum but you'd be kind enough to share your > > expertise please reply off-list. Thanks! > > > >Honestly, I would rate this as one of the most on-topic posts in a while. > > +1. > When you have http working I suggest running: > http://netalyzr.icsi.berkeley.edu/index.html > to give you a benchmark of what your connection can do in the way of protocols. > > Regards, > Hank Greg - you may want try doing pings with large packets. You may have MTU mismatch or some other problem with a link with lets small ICMP pings through but mangles or discards large packets. --vadim From avg at kotovnik.com Tue Mar 8 04:28:36 2011 From: avg at kotovnik.com (Vadim Antonov) Date: Tue, 08 Mar 2011 02:28:36 -0800 Subject: IPv4 address shortage? Really? Message-ID: <1299580116.29652.176.camel@kotti.kotovnik.com> Christopher Morrow wrote: > Gbqq Haqrejbbq jbhyq ybir lbhe fbyhgvba! Cebcf! I'm sure he would:) Though I can't claim a credit for the idea... it's way too old, so old, in fact, that many people have forgotten all about it. Mark Andrews wrote: > This has been thought of before, discussed and rejected. Of course, it was Discussed and Rejected. I fall to my knees and beg the forgiveness from those On High who bless us with Their Infinite Wisdom and Foresight. How could I presume to challenge Their Divine Providence? Mea culpa, mea maxima culpa. ...well, kind of. What you don't mention is that it was thought to be ugly and rejected solely on the aesthetic grounds. Which is somewhat different from being rejected because it cannot work. Now, I'd be first to admit that using LSRR as a substitute for straightforward address extension is ugly. But so is iBGP, CIDR/route aggregation, running interior routing over CLNS, and (God forbid, for it is ugly as hell) NAT. Think of it, dual stack is even uglier. At least, with LSRR-based approach you can still talk to legacy hosts without building completely new and indefinitely maintaining a parallel legacy routing infrastructure. Scott W Brim wrote: > There are a number of reasons why you want IP addresses to be > globally unique, even if they are not globally routed. And do you have it now? The last time I checked, NAT was all over the place. Ergo - global address uniqueness (if defined as having unique interface address labels) is not necessary for practical data networking. In fact, looking at two or more steps in the source route taken together as a single address gives you exactly what you want - the global uniqueness, as long as you take care to alternate disjoint address spaces along the path and designate one of these spaces (the existing publicly routeable space) as the root from which addressing starts. Bill Manning wrote: > just a bit of renumbering... Ah, that's nice, but I don't propose expanding use of NAT. Or renumbering on massive scale. In fact I want to remind that NAT was never a necessity. It's a temporary fix which gave IPv4 a lot of extra mileage and became popular precisely because it didn't break networking too much while allowing folks to keep using the existing stuff. The real problem with NAT is called "P2P" (and I think it will become important enough to become the death of NAT). Jima wrote: > This seems like either truly bizarre trolling, I guess you haven't been around NANOG (and networking) too long, or you'd be careful to call me a troll:) What I want is to remind people that with a little bit of lateral thinking we can get a lot more mileage out of the good old IPv4. Its death was predicted many times already. (Let me remember... there was that congestion collapse, then it was the routing table overwhelming the IGPs, and then there was that shortage of class Bs and routing tables outgrowing RAM in ciscos, and then there was a heated battle over IP address ownership, and there was the Big Deal about n^2 growth of iBGP mesh). I don't remember what was the deal with Bob Metcalfe and his (presumably eaten) hat. Something about Moore's Law? > or the misguided idea of someone who's way too invested in IPv4 and > hasn't made any necessary plans or steps to implement IPv6. "Too invested in IPv4"? Like, the Internet and everybody on it? You know, I left the networking soapbox years ago, and I couldn't care less about the religious wars regarding the best ways to shoot themselves in the foot. The reason why I moved to different pastures was sheer boredom. The last interesting development in the networking technology was when some guy figured out that you can shuffle IP packets around faster than you can convert a lambda from photons to electrons - and thus has shown that there's no technological limitation to the bandwidth of Internet backbones. > you'd have to overhaul software on many, many computers, routers, > and other devices. (Wait, why does this sound familiar?) You probably missed the whole point - which is that unlike dual-stack solution using LSRR leverages existing, installed, and paid for, infrastructure. > too bad we don't have a plan that could be put into action sooner The cynical old codgers like yours truly have predicted that the whole IPv6 saga would come precisely to that - when it was beginning. The reason for that is called the Second System Effect of which IPv6 is a classical example. A truly workable and clean solution back then would be to simply add more bits to IPv4 addresses (that's what options are for). Alas, a lot of people thought that it would be very neat to replace the whole piston engine with a turbine powerplant instead of limiting themselves to changing spark plugs and continuing on the way to the real job (namely, making moving bits from place A to place B as cheap and fast as possible). Now, we don't have a problem of running out of IPv4 addresses - NAT takes care of that, and will continue to do so for many years more. We do have a problem of having no way[*] to initiate connections to boxes hidden behind NATs. Which is bad for P2P applications. To solve this problem three things need to be done: 1) to create network infrastructure which can haul packets with extended addresses (be it IPv4 or IPv6) and extend network stacks in the OSes to support this transport; 2) to create a way to map domain names to those addresses; 3) to get applications to work with the extended addresses. You also need a clean migration path from legacy to the new architecture (which IPv6 lacks), just to stay in the realm of practical. 1 and 3 are seriously expensive. 2 is relatively easy as DNS has provisions for expansion which were actually used (instead of reinventing the wheel, thankfully). The issue #1 can be sidestepped by use of LSRR as I suggested. #2 and #3 are, to a considerable extent, already solved by the people implementing IPv6. Now, listen carefully: you don't have to use IPv6 packets to use IPv6 addresses. In fact, all we need to get benefits of extended addressing w/o going to the trouble of implementing native or tunneled IPv6 networks is a simple shim (either within kernels or within language libraries) which takes IPv6 address/socket and translates it into IPv4 socket with appropriate LSRR option information attached. (A small subset of IPv6 addresses could be set aside for the purpose... one /32 or such; just so you can still have IPv6 in all its glory if you wish). The entire amount of development for a Unix-like OS is about 500 lines of code (that's my educated guess based on the gut feeling developed while I was hacking various Unix kernels for living since v6). My question to the community - is it interesting enough? I.e. should I spend my time on writing I-D on IPv4 Extended Addressing, or will I be dismissed as a troll for my trouble? --vadim [*] chownat exceeds even my tolerance for ugliness, though the expoit itself is an elegant use of the quasi-paradox from probability theory. From smb at cs.columbia.edu Tue Mar 8 06:37:27 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 8 Mar 2011 07:37:27 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: <1299580116.29652.176.camel@kotti.kotovnik.com> References: <1299580116.29652.176.camel@kotti.kotovnik.com> Message-ID: > > ...well, kind of. What you don't mention is that it was thought to be > ugly and rejected solely on the aesthetic grounds. Which is somewhat > different from being rejected because it cannot work. > > Now, I'd be first to admit that using LSRR as a substitute for > straightforward address extension is ugly. But so is iBGP, CIDR/route > aggregation, running interior routing over CLNS, and (God forbid, for it > is ugly as hell) NAT. No. It was rejected because routers tended to melt down into quivering puddles of silicon from seeing many packets with IP options set -- a fast trip to the slow path. It also requires just as many changes to applications and DNS content, and about as large an addressing plan change as v6. There were more reasons, but they escape me at the moment. --Steve Bellovin, http://www.cs.columbia.edu/~smb From Donald.Smith at qwest.com Tue Mar 8 06:46:09 2011 From: Donald.Smith at qwest.com (Smith, Donald) Date: Tue, 8 Mar 2011 05:46:09 -0700 Subject: [arin-ppml] why hp bladeserver chassis have a sudden interest in thailand. In-Reply-To: <4D75B373.2040506@bogus.com> References: <4D75B373.2040506@bogus.com> Message-ID: http://isc.sans.edu/diary/Outbound+SSH+Traffic+from+HP+Virtual+Connect+Blades/10498 It is going for a range of ips. We only see syn's never a response from the ips. Netflow sampling at 1/1k results from yesterday's SSH fun:) Countx1k ip 244 49.48.46.49 125 49.48.46.51 74 49.48.46.50 69 49.48.46.54 25 49.48.46.55 18 49.48.46.53 11 49.48.46.48 2 49.48.46.57 (coffee != sleep) & (!coffee == sleep) Donald.Smith at qwest.com ________________________________________ From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] On Behalf Of Joel Jaeggli [joelja at bogus.com] Sent: Monday, March 07, 2011 9:41 PM To: NANOG; arin-ppml at arin.net Subject: [arin-ppml] why hp bladeserver chassis have a sudden interest in thailand. http://forums11.itrc.hp.com/service/forums/questionanswer.do?admit=109447626+1299558177753+28353475&threadId=1471451 As a potentially cautionary tale for the squatting on unused pieces of address space either in your network or applications. drive slow (and filter 22 outgoing to 49.48.46.49 until you get new firmware) joel _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. From viraviralh at gmail.com Tue Mar 8 06:50:57 2011 From: viraviralh at gmail.com (Viral Vira) Date: Tue, 8 Mar 2011 18:20:57 +0530 Subject: A BGP issue? In-Reply-To: <1299580893.29652.183.camel@kotti.kotovnik.com> References: <5.1.0.14.2.20110308092120.035e89f8@efes.iucc.ac.il> <1299580893.29652.183.camel@kotti.kotovnik.com> Message-ID: I have seen this kind of problems in our customers networks and this is motly related to MTU/MSS. Network reachability is fine but applciations does not work. Apply the MSS on the LAN interface which is around 100 bytes less than the MTU on the WAN interface. -Thanks, Viral. On 8 March 2011 16:11, Vadim Antonov wrote: > On Tue, 2011-03-08 at 09:25 +0200, Hank Nussbacher wrote: > > At 21:49 07/03/2011 -0500, Patrick W. Gilmore wrote: > > >On Mar 7, 2011, at 14:27, Greg Ihnen wrote: > > > > > > > I run a small network on a mission base in the Amazon jungle which is > > > fed by a satellite internet connection. We had an outage from Feb 25th > to > > > the 28th where we had no connectivity with email, http/s, ftp, Skype > > > would indicate it's connected but even chatting failed, basically > > > everything stopped working except for ICMP. I could ping everywhere > just > > > fine. I started doing traceroutes and they all were very odd, all not > > > reaching their destination and some hopping all over creation before > > > dying. But if I did traceroute with ICMP it worked fine. Does this > > > indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed > > > Hughesnet which is the service they resell. I'm wondering what kind of > > > problem would let ping work fine but not any of the other protocols. It > > > also seems odd that I could traceroute via UDP part way to a > destination > > > but then it would fail if the problem was my own provider. Thanks. > > > > > > > > If this is the wrong forum for this post I'm sorry and please just > hit > > > delete. If this is the wrong forum but you'd be kind enough to share > your > > > expertise please reply off-list. Thanks! > > > > > >Honestly, I would rate this as one of the most on-topic posts in a > while. > > > > +1. > > When you have http working I suggest running: > > http://netalyzr.icsi.berkeley.edu/index.html > > to give you a benchmark of what your connection can do in the way of > protocols. > > > > Regards, > > Hank > > > Greg - you may want try doing pings with large packets. You may have MTU > mismatch or some other problem with a link with lets small ICMP pings > through but mangles or discards large packets. > > --vadim > > > From swm at emanon.com Tue Mar 8 07:18:37 2011 From: swm at emanon.com (Scott Morris) Date: Tue, 08 Mar 2011 08:18:37 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13F79@RWC-EX1.corp.seven.com> References: <1299498200.29652.40.camel@kotti.kotovnik.com><4D759138.7080002@jima.tk> <20110308040939.GA26901@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0BC13F79@RWC-EX1.corp.seven.com> Message-ID: <4D762CAD.40704@emanon.com> It would be a lot easier to do it by continent. 3 bits at prepend. We only have 7 of those and Antarctica likely doesn't need several billion addresses anyway. Got some leftover for the United Federation of Planets. :) (or whatever other semi-practical use that may be dreamed up) You could do the same type of thing with E.164 country code ideas, but that may be a bit stranger and drive the need for more RIRs along the way. Scott On 3/8/11 2:18 AM, George Bonser wrote: >> well... not that it gained any traction atall, but given >> the actual size/complexity of the global interconnect mesh, >> we -could- ease the transition timing by many years with the >> following administrative change. No tricks, no OS hacks, >> no changes to software anywhere.. just a bit of renumbering... >> >> recipie: >> >> the usable IPv4 ranges >> RFC 1918 >> >> Step one: Invert RFC 1918 to define the global Internets >> interconnection >> mesh. >> Step two: make all other usable IPv4 space "private". >> >> Serves 2,000,000 million clients w/o changing to a new protocol >> family. >> >> >> Enjoy! >> >> --bill > And I fully expect that to be done at some point or another. Country > takes the entire 32bit address space for itself. You want to serve that > country? Fine, apply for an allocation out of their /0 and route to it > over v6. > > > > > > From Valdis.Kletnieks at vt.edu Tue Mar 8 07:32:59 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Mar 2011 08:32:59 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: Your message of "Tue, 08 Mar 2011 07:37:27 EST." References: <1299580116.29652.176.camel@kotti.kotovnik.com> Message-ID: <42008.1299591179@localhost> On Tue, 08 Mar 2011 07:37:27 EST, Steven Bellovin said: > No. It was rejected because routers tended to melt down into quivering > puddles of silicon from seeing many packets with IP options set -- a fast > trip to the slow path. It also requires just as many changes to applications > and DNS content, and about as large an addressing plan change as v6. There > were more reasons, but they escape me at the moment. Steve, you of all people should remember the other big reason why: pathalias tended to do Very Bad Things like violating the Principle of Least Surprise if there were two distinct nodes both called 'turtlevax' or whatever. That, and if you think BGP convergence sucks, imagine trying to run pathalias for a net the size of the current Internet. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From regnauld at nsrc.org Tue Mar 8 07:43:38 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 8 Mar 2011 14:43:38 +0100 Subject: [afnog] Suspicious request for IP address space In-Reply-To: References: Message-ID: <20110308134337.GI87854@macbook.catpipe.net> (Cross posting to nanog, apologies if this is considered not appropriate). Shepherd Magumo (shepherd) writes: > Good day, > > I work for an ISP with own small AfriNIC IP block and ASN number and > recently received a second suspicious request for a huge IP address space > with server hosting solution and we are about to turn it down. > > Below is the exact request and I am sure there is something dodge about this > request. Anybody else in ISP receive this? > > We are looking for an IP address space of /17 and we would like to lease it > > for one complete year. Please quote us the price and if its something in > > our > > range, We will go ahead and purchase, Along with it do you provide > > dedicated > > servers and hosting services. Get back to me soon along with the requested > > details. Hi Shepherd, Without disclosing the sender of this mail, do you know where it's originating from, region wise ? The size looks a bit large to be a legitimate request. They might be probing the market to find a LIR willing to go along with a scam. As I see it, if you consider the ratio of available IPv4 space left in the AfriNIC pool vs. the population in Africa, there is a temptation for IPv4 hungry orgs. to acquire v4 space via front companies in Africa, and announce it elsewhere - where the validation process for the appropriate RIR would be more stringent. Cheers, Phil From smb at cs.columbia.edu Tue Mar 8 07:43:53 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 8 Mar 2011 08:43:53 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: <42008.1299591179@localhost> References: <1299580116.29652.176.camel@kotti.kotovnik.com> <42008.1299591179@localhost> Message-ID: <357BF221-A470-4E5F-83F1-546A956CD2AB@cs.columbia.edu> On Mar 8, 2011, at 8:32 59AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 08 Mar 2011 07:37:27 EST, Steven Bellovin said: > >> No. It was rejected because routers tended to melt down into quivering >> puddles of silicon from seeing many packets with IP options set -- a fast >> trip to the slow path. It also requires just as many changes to applications >> and DNS content, and about as large an addressing plan change as v6. There >> were more reasons, but they escape me at the moment. > > Steve, you of all people should remember the other big reason why: > > pathalias tended to do Very Bad Things like violating the Principle of Least > Surprise if there were two distinct nodes both called 'turtlevax' or whatever. > That, and if you think BGP convergence sucks, imagine trying to run pathalias > for a net the size of the current Internet. :) > It wouldn't -- couldn't -- work that way. Leaving out longer paths (for many, many reasons) and sticking to 64-bit addresses, every host would have a 64-bit address: a gateway and a local address. For multihoming, there might be two or more such pairs. (Note that this isn't true loc/id split, since the low-order 32 bits aren't unique.) There's no pathalias problem at all, since we don't try to have a unique turtlevax section. --Steve Bellovin, http://www.cs.columbia.edu/~smb From os10rules at gmail.com Tue Mar 8 07:52:16 2011 From: os10rules at gmail.com (Greg Ihnen) Date: Tue, 8 Mar 2011 09:22:16 -0430 Subject: A BGP issue? In-Reply-To: <3EB9AA75-7CBE-4571-871A-CA4DC9A0A978@ianai.net> References: <3EB9AA75-7CBE-4571-871A-CA4DC9A0A978@ianai.net> Message-ID: On Mar 7, 2011, at 10:19 PM, Patrick W. Gilmore wrote: > On Mar 7, 2011, at 14:27, Greg Ihnen wrote: > >> I run a small network on a mission base in the Amazon jungle which is fed by a satellite internet connection. We had an outage from Feb 25th to the 28th where we had no connectivity with email, http/s, ftp, Skype would indicate it's connected but even chatting failed, basically everything stopped working except for ICMP. I could ping everywhere just fine. I started doing traceroutes and they all were very odd, all not reaching their destination and some hopping all over creation before dying. But if I did traceroute with ICMP it worked fine. Does this indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed Hughesnet which is the service they resell. I'm wondering what kind of problem would let ping work fine but not any of the other protocols. It also seems odd that I could traceroute via UDP part way to a destination but then it would fail if the problem was my own provider. Thanks. >> >> If this is the wrong forum for this post I'm sorry and please just hit delete. If this is the wrong forum but you'd be kind enough to share your expertise please reply off-list. Thanks! > > Honestly, I would rate this as one of the most on-topic posts in a while. > > BGP only handles reachability, not higher level protocols. (Of course, you can h4x0r anything to do jus about anything, but we are talking the general case here.) > > If you can ping, BGP is working. If you can ping and cannot use TCP, then something other than BGP is at fault. > > I've seen strange things like someone enabling TCP compression (common on very small or very expensive links) one side but not the other, which then allowed ICMP and UDP but not TCP. It is a great way to annoy someone. "See, I can ping, it must be your side!" > > Have you tried TCP traceroute? Or telnetting to port 80? > > -- > TTFN, > patrick Patrick, Thank you very much! Thank you to everyone else who replied. I did try TCP traceroute and it failed too. I didn't have a machine to telnet to on port 80 but I did try an ssh tunnel on port 9999 and it failed too. From what everyone is saying it sounds like it was the satellite internet provider's compression scheme that was having trouble or some kind of an MTU issue. What I don't understand is why when using traceroute UDP/TCP/GRE I could get replies from some routers but not all routers to the destination, and why some routes were bizarre. If it was a failure of the sat internet provider's compression scheme or an MTU issue wouldn't traceroute UDP/TCP/GRE fail completely? What could have happened to my packets that would make them go only part way or go the wrong way? According to our satellite internet service provider Bantel the outage was system wide. Thank again! Greg From ken.henault at hp.com Tue Mar 8 08:30:21 2011 From: ken.henault at hp.com (Henault, Ken) Date: Tue, 8 Mar 2011 14:30:21 +0000 Subject: [arin-ppml] why hp bladeserver chassis have a sudden interest in thailand. Message-ID: <4900ECFB68765141B437958EF008863875EB80898A@GVW1119EXC.americas.hpqcorp.net> HP has identified a DNS related issue with HP Virtual Connect that does not impact data traffic but does impair the manageability of Virtual Connect devices. HP is acting promptly to help customers remove this issue in the short term with an interim resolution. A permanent firmware fix will be available in the next three weeks. Customer Advisory Document ID: c02720395, March 7, 2011 is available now at the url below to resolve this issue. If you have questions or need assistance, contact HP Support in your home country. HP is committed to minimizing any impact on customer environments and to resolving the issue as quickly as possible. Download Customer Advisory Document ID: c02720395, March 7, 2011: http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c02720395&lang=en&cc=us&taskId=101&prodSeriesId=3540808&prodTypeId=329290 Visit the HP Support worldwide contact list: http://welcome.hp.com/country/us/en/wwcontact_us.html From bmanning at vacation.karoshi.com Tue Mar 8 09:18:51 2011 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 8 Mar 2011 15:18:51 +0000 Subject: [afnog] Suspicious request for IP address space In-Reply-To: <20110308134337.GI87854@macbook.catpipe.net> References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: <20110308151851.GA21573@vacation.karoshi.com.> On Tue, Mar 08, 2011 at 02:43:38PM +0100, Phil Regnauld wrote: > (Cross posting to nanog, apologies if this is considered not appropriate). > > Shepherd Magumo (shepherd) writes: > > Good day, > > > > I work for an ISP with own small AfriNIC IP block and ASN number and > > recently received a second suspicious request for a huge IP address space > > with server hosting solution and we are about to turn it down. > > > > Below is the exact request and I am sure there is something dodge about this > > request. Anybody else in ISP receive this? > > > > We are looking for an IP address space of /17 and we would like to lease it > > > for one complete year. Please quote us the price and if its something in > > > our > > > range, We will go ahead and purchase, Along with it do you provide > > > dedicated > > > servers and hosting services. Get back to me soon along with the requested > > > details. > > Hi Shepherd, > > Without disclosing the sender of this mail, do you know where it's > originating from, region wise ? The size looks a bit large to be a > legitimate request. They might be probing the market to find a LIR > willing to go along with a scam. > > As I see it, if you consider the ratio of available IPv4 space left in > the AfriNIC pool vs. the population in Africa, there is a temptation > for IPv4 hungry orgs. to acquire v4 space via front companies in Africa, > and announce it elsewhere - where the validation process for the > appropriate RIR would be more stringent. > i received the -exact- text as well. I offered a lease, at the usual terms, which was outside their range of acceptable cost. the request came from outside the AFRInic service area.... --bill From leigh.porter at ukbroadband.com Tue Mar 8 09:33:11 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 8 Mar 2011 15:33:11 -0000 Subject: [afnog] Suspicious request for IP address space In-Reply-To: <20110308151851.GA21573@vacation.karoshi.com.> References: <20110308134337.GI87854@macbook.catpipe.net> <20110308151851.GA21573@vacation.karoshi.com.> Message-ID: My recently deceased uncle has a total of 100 /16s which at the moment are held in a bank in Libya. I am looking for a partner to help release these IPv4 resources to invest in your country..... -----Original Message----- From: bmanning at vacation.karoshi.com [mailto:bmanning at vacation.karoshi.com] Sent: 08 March 2011 15:19 To: Phil Regnauld Cc: afnog at afnog.org; nanog at nanog.org; Shepherd Magumo Subject: Re: [afnog] Suspicious request for IP address space On Tue, Mar 08, 2011 at 02:43:38PM +0100, Phil Regnauld wrote: > (Cross posting to nanog, apologies if this is considered not appropriate). > > Shepherd Magumo (shepherd) writes: > > Good day, > > > > I work for an ISP with own small AfriNIC IP block and ASN number and > > recently received a second suspicious request for a huge IP address space > > with server hosting solution and we are about to turn it down. > > > > Below is the exact request and I am sure there is something dodge about this > > request. Anybody else in ISP receive this? > > > > We are looking for an IP address space of /17 and we would like to lease it > > > for one complete year. Please quote us the price and if its something in > > > our > > > range, We will go ahead and purchase, Along with it do you provide > > > dedicated > > > servers and hosting services. Get back to me soon along with the requested > > > details. > > Hi Shepherd, > > Without disclosing the sender of this mail, do you know where it's > originating from, region wise ? The size looks a bit large to be a > legitimate request. They might be probing the market to find a LIR > willing to go along with a scam. > > As I see it, if you consider the ratio of available IPv4 space left in > the AfriNIC pool vs. the population in Africa, there is a temptation > for IPv4 hungry orgs. to acquire v4 space via front companies in Africa, > and announce it elsewhere - where the validation process for the > appropriate RIR would be more stringent. > i received the -exact- text as well. I offered a lease, at the usual terms, which was outside their range of acceptable cost. the request came from outside the AFRInic service area.... --bill From jlewis at lewis.org Tue Mar 8 09:36:44 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 8 Mar 2011 10:36:44 -0500 (EST) Subject: [afnog] Suspicious request for IP address space In-Reply-To: <20110308134337.GI87854@macbook.catpipe.net> References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: On Tue, 8 Mar 2011, Phil Regnauld wrote: >> Below is the exact request and I am sure there is something dodge about this >> request. Anybody else in ISP receive this? >> >> We are looking for an IP address space of /17 and we would like to lease it >>> for one complete year. Please quote us the price and if its something in >>> our >>> range, We will go ahead and purchase, Along with it do you provide >>> dedicated >>> servers and hosting services. Get back to me soon along with the requested >>> details. > > Hi Shepherd, > > Without disclosing the sender of this mail, do you know where it's > originating from, region wise ? The size looks a bit large to be a > legitimate request. They might be probing the market to find a LIR > willing to go along with a scam. Odds are, they're looking for a willing host for a snowshoe spamming operation. If I wanted space for something like that, Afrinic region providers would not be my first choice...particularly for the hosting. AFAIK, there are numerous LIRs in the RIPE region, particularly Romania who are more than happy to lease large blocks of IPv4 to anyone for any purpose. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jlewis at lewis.org Tue Mar 8 09:42:03 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 8 Mar 2011 10:42:03 -0500 (EST) Subject: [afnog] Suspicious request for IP address space In-Reply-To: <20110308151851.GA21573@vacation.karoshi.com.> References: <20110308134337.GI87854@macbook.catpipe.net> <20110308151851.GA21573@vacation.karoshi.com.> Message-ID: On Tue, 8 Mar 2011 bmanning at vacation.karoshi.com wrote: > i received the -exact- text as well. I offered a lease, at the usual > terms, which was outside their range of acceptable cost. the request > came from outside the AFRInic service area.... $100,000,000,000.00 per year? http://www.youtube.com/watch?v=jTmXHvGZiSY ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From patrick at ianai.net Tue Mar 8 09:47:18 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 8 Mar 2011 10:47:18 -0500 Subject: A BGP issue? In-Reply-To: References: <3EB9AA75-7CBE-4571-871A-CA4DC9A0A978@ianai.net> Message-ID: <933B32DB-FF63-44CC-97FD-E9EBF7246D9E@ianai.net> On Mar 8, 2011, at 8:52 AM, Greg Ihnen wrote: > On Mar 7, 2011, at 10:19 PM, Patrick W. Gilmore wrote: >> On Mar 7, 2011, at 14:27, Greg Ihnen wrote: >> >>> I run a small network on a mission base in the Amazon jungle which is fed by a satellite internet connection. We had an outage from Feb 25th to the 28th where we had no connectivity with email, http/s, ftp, Skype would indicate it's connected but even chatting failed, basically everything stopped working except for ICMP. I could ping everywhere just fine. I started doing traceroutes and they all were very odd, all not reaching their destination and some hopping all over creation before dying. But if I did traceroute with ICMP it worked fine. Does this indicate our upstream (Bantel.net) had a BGP issue? Bantel blamed Hughesnet which is the service they resell. I'm wondering what kind of problem would let ping work fine but not any of the other protocols. It also seems odd that I could traceroute via UDP part way to a destination but then it would fail if the problem was my own provider. Thanks. >>> >>> If this is the wrong forum for this post I'm sorry and please just hit delete. If this is the wrong forum but you'd be kind enough to share your expertise please reply off-list. Thanks! >> >> Honestly, I would rate this as one of the most on-topic posts in a while. >> >> BGP only handles reachability, not higher level protocols. (Of course, you can h4x0r anything to do jus about anything, but we are talking the general case here.) >> >> If you can ping, BGP is working. If you can ping and cannot use TCP, then something other than BGP is at fault. >> >> I've seen strange things like someone enabling TCP compression (common on very small or very expensive links) one side but not the other, which then allowed ICMP and UDP but not TCP. It is a great way to annoy someone. "See, I can ping, it must be your side!" >> >> Have you tried TCP traceroute? Or telnetting to port 80? > I did try TCP traceroute and it failed too. I didn't have a machine to telnet to on port 80 but I did try an ssh tunnel on port 9999 and it failed too. Sure you do. Any web server will allow you to telnet to port 80. TiggerBook-Air3:~ patrick$ telnet www.yahoo.com 80 Trying 67.195.160.76... Connected to any-fp.wa1.b.yahoo.com. Escape character is '^]'. GET GET Not Found Your requested URL was not found. Connection closed by foreign host. [In case it wasn't clear, I typed "GET GET" myself, just to have the web server respond with something.] > From what everyone is saying it sounds like it was the satellite internet provider's compression scheme that was having trouble or some kind of an MTU issue. > > What I don't understand is why when using traceroute UDP/TCP/GRE I could get replies from some routers but not all routers to the destination, and why some routes were bizarre. If it was a failure of the sat internet provider's compression scheme or an MTU issue wouldn't traceroute UDP/TCP/GRE fail completely? What could have happened to my packets that would make them go only part way or go the wrong way? It was likely not MTU if you can traceroute to some places, but not others. Traceroute doesn't send or receive big packets. And I didn't really see anything terribly unusual in the traces you sent, other than some not completing. If you are talking about the Cogent one, with many routers per hop, that's just standard load balancing. -- TTFN, patrick From tom at ninjabadger.net Tue Mar 8 09:52:26 2011 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 08 Mar 2011 15:52:26 +0000 Subject: [afnog] Suspicious request for IP address space In-Reply-To: References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: <1299599546.7027.42.camel@teh-desktop> On Tue, 2011-03-08 at 10:36 -0500, Jon Lewis wrote: > Odds are, they're looking for a willing host for a snowshoe spamming > operation. If I wanted space for something like that, Afrinic region > providers would not be my first choice...particularly for the > hosting. > AFAIK, there are numerous LIRs in the RIPE region, particularly > Romania > who are more than happy to lease large blocks of IPv4 to anyone for > any > purpose. Indeed. However, and I too get similar requests (not quite as big, but /24's and /23's etc.) The first thing I do is search for their "name" and domain they're e-mailling from, with the term 'ROKSO' behind it. 50% of the time you find a reference to the domain or their name in Spamhaus' ROKSO list. The other 50% of the time you find someone that isn't in there, but really should be... Tom From dustin at rseng.net Tue Mar 8 09:52:38 2011 From: dustin at rseng.net (Dustin Jurman) Date: Tue, 8 Mar 2011 10:52:38 -0500 Subject: Ethernet circuit testing In-Reply-To: <005201cbdd53$60666b20$21334160$@iname.com> References: <61CFCA0622DF4996973497EC3B407FF1@dlaptop> <005201cbdd53$60666b20$21334160$@iname.com> Message-ID: <85D7F07C-22FC-411D-A7DF-FEFA9E81AA44@rseng.net> We use the EXFO 860's. Great product, rugged and Accurate. Sent from my iPhone On Mar 7, 2011, at 9:41 PM, "Frank Bulk" wrote: > I've heard good things from a neighbor service provider that uses EXFO's > EtherSAM. > > Frank > > -----Original Message----- > From: Dustin Swinford [mailto:dustinnanog at gmail.com] > Sent: Monday, March 07, 2011 2:07 PM > To: nanog at nanog.org > Subject: Ethernet circuit testing > > More often on Ethernet services, we experience a customer wanting to see > more than an Ookla based server test from our network. Our hands in the > field are limited in the number of Ethernet smart loopback devices that they > own. If we do have a tester on site, we can generate traffic from an Exfo > purpose built appliance toward the loop and determine results. Too often, > we have found things such as ftp downloads to be unreliable based on use of > server, windows PC doing the download, etc. What other methods are you guys > using for testing these services? > > > > > > > > > > From ops.lists at gmail.com Tue Mar 8 10:03:33 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Tue, 8 Mar 2011 21:33:33 +0530 Subject: [afnog] Suspicious request for IP address space In-Reply-To: References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: On Tue, Mar 8, 2011 at 9:06 PM, Jon Lewis wrote: > > Odds are, they're looking for a willing host for a snowshoe spamming > operation. ?If I wanted space for something like that, Afrinic region > providers would not be my first choice...particularly for the hosting. > AFAIK, there are numerous LIRs in the RIPE region, particularly Romania who > are more than happy to lease large blocks of IPv4 to anyone for any purpose. > Eh. If you acquire blocks that big all you need to do is to persuade some provider with a poorly enforced AUP / a willingness to look the other way to route the netblock for you, from anywhere you choose. -- Suresh Ramasubramanian (ops.lists at gmail.com) From mikea at mikea.ath.cx Tue Mar 8 10:14:54 2011 From: mikea at mikea.ath.cx (mikea) Date: Tue, 8 Mar 2011 10:14:54 -0600 Subject: Who owns (or is allocated) 208.64.200.0/22? Message-ID: <20110308161454.GA98448@mikea.ath.cx> I rise to expose my ignorance. 208.0.0.0/8 is an ARIN block, and ARIN has allocation data for the blocks immediately adjoining 208.64.200.0/22, but no allocation data for 208.64.200.0/22 itself, either in WHOIS or in the website. Nor does 208.64.200.0/22 appear to be "special" in any way. Is this an oversight? How do I get it corrected, if it is? -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From mikea at mikea.ath.cx Tue Mar 8 10:18:11 2011 From: mikea at mikea.ath.cx (mikea) Date: Tue, 8 Mar 2011 10:18:11 -0600 Subject: Who owns (or is allocated) 208.64.200.0/22? In-Reply-To: <20110308161454.GA98448@mikea.ath.cx> References: <20110308161454.GA98448@mikea.ath.cx> Message-ID: <20110308161811.GB98448@mikea.ath.cx> On Tue, Mar 08, 2011 at 10:14:54AM -0600, mikea wrote: > I rise to expose my ignorance. > > 208.0.0.0/8 is an ARIN block, and ARIN has allocation data for the > blocks immediately adjoining 208.64.200.0/22, but no allocation data for > 208.64.200.0/22 itself, either in WHOIS or in the website. Nor does > 208.64.200.0/22 appear to be "special" in any way. > > Is this an oversight? How do I get it corrected, if it is? Never mind. I appear to have found one of the remaining unallocated /22 blocks. Shame I appear to have got spam from it; I hope that's forged. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From Valdis.Kletnieks at vt.edu Tue Mar 8 10:21:09 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 08 Mar 2011 11:21:09 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: Your message of "Tue, 08 Mar 2011 08:43:53 EST." <357BF221-A470-4E5F-83F1-546A956CD2AB@cs.columbia.edu> References: <1299580116.29652.176.camel@kotti.kotovnik.com> <42008.1299591179@localhost> <357BF221-A470-4E5F-83F1-546A956CD2AB@cs.columbia.edu> Message-ID: <9616.1299601269@localhost> On Tue, 08 Mar 2011 08:43:53 EST, Steven Bellovin said: > It wouldn't -- couldn't -- work that way. Leaving out longer paths (for many, > many reasons) and sticking to 64-bit addresses, every host would have a 64-bit > address: a gateway and a local address. For multihoming, there might be two or > more such pairs. (Note that this isn't true loc/id split, since the low-order > 32 bits aren't unique.) There's no pathalias problem at all, since we don't > try to have a unique turtlevax section. Sticking to 64-bit won't work, because some organizations *will* try to dig themselves out of an RFC1918 quagmire and get reachability to "the other end of our private net" by applying this 4 or 5 times to get through the 4 or 5 layers of NAT they currently have. And then some other dim bulb will connect one of those 5 layers to the outside world... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From scott at doc.net.au Tue Mar 8 10:21:57 2011 From: scott at doc.net.au (Scott Howard) Date: Tue, 8 Mar 2011 08:21:57 -0800 Subject: Who owns (or is allocated) 208.64.200.0/22? In-Reply-To: <20110308161454.GA98448@mikea.ath.cx> References: <20110308161454.GA98448@mikea.ath.cx> Message-ID: It was unallocated a few days ago : http://lists.arin.net/pipermail/arin-issued/2011-March/000807.html Google will probably give you a fair idea why (the word "botnet" comes up a lot!) Scott On Tue, Mar 8, 2011 at 8:14 AM, mikea wrote: > I rise to expose my ignorance. > > 208.0.0.0/8 is an ARIN block, and ARIN has allocation data for the > blocks immediately adjoining 208.64.200.0/22, but no allocation data for > 208.64.200.0/22 itself, either in WHOIS or in the website. Nor does > 208.64.200.0/22 appear to be "special" in any way. > > Is this an oversight? How do I get it corrected, if it is? > > -- > Mike Andrews, W5EGO > mikea at mikea.ath.cx > Tired old sysadmin > > From jlewis at lewis.org Tue Mar 8 10:24:34 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 8 Mar 2011 11:24:34 -0500 (EST) Subject: Who owns (or is allocated) 208.64.200.0/22? In-Reply-To: <20110308161454.GA98448@mikea.ath.cx> References: <20110308161454.GA98448@mikea.ath.cx> Message-ID: On Tue, 8 Mar 2011, mikea wrote: > I rise to expose my ignorance. > > 208.0.0.0/8 is an ARIN block, and ARIN has allocation data for the > blocks immediately adjoining 208.64.200.0/22, but no allocation data for > 208.64.200.0/22 itself, either in WHOIS or in the website. Nor does > 208.64.200.0/22 appear to be "special" in any way. > > Is this an oversight? How do I get it corrected, if it is? No whois. No route in the global table at this time. My first guess would be it's not allocated/assigned to anyone at this time. According to RIPE RIS: This prefix originated from AS11730 (CIL-ASN - Circle Internet LTD) [last seen on 2011-02-11 23:31:20 UTC]. Hijacked unallocated space? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From regnauld at nsrc.org Tue Mar 8 11:18:27 2011 From: regnauld at nsrc.org (Phil Regnauld) Date: Tue, 8 Mar 2011 18:18:27 +0100 Subject: [afnog] Suspicious request for IP address space In-Reply-To: References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: <20110308171826.GF90947@macbook.catpipe.net> Jon Lewis (jlewis) writes: > > Odds are, they're looking for a willing host for a snowshoe spamming > operation. If they're asking for hosting and not only IP allocation, you might be right. > If I wanted space for something like that, Afrinic > region providers would not be my first choice...particularly for the > hosting. AFAIK, there are numerous LIRs in the RIPE region, > particularly Romania who are more than happy to lease large blocks > of IPv4 to anyone for any purpose. They're exploring new marktes. Legitimate businesses are not the only ones scouting for cheap suppliers. Cheers, Phil From smb at cs.columbia.edu Tue Mar 8 11:37:10 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Tue, 8 Mar 2011 12:37:10 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: <9616.1299601269@localhost> References: <1299580116.29652.176.camel@kotti.kotovnik.com> <42008.1299591179@localhost> <357BF221-A470-4E5F-83F1-546A956CD2AB@cs.columbia.edu> <9616.1299601269@localhost> Message-ID: <887545CC-A5B6-4A70-B042-CCB1B71D66E1@cs.columbia.edu> On Mar 8, 2011, at 11:21 09AM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 08 Mar 2011 08:43:53 EST, Steven Bellovin said: > >> It wouldn't -- couldn't -- work that way. Leaving out longer paths (for many, >> many reasons) and sticking to 64-bit addresses, every host would have a 64-bit >> address: a gateway and a local address. For multihoming, there might be two or >> more such pairs. (Note that this isn't true loc/id split, since the low-order >> 32 bits aren't unique.) There's no pathalias problem at all, since we don't >> try to have a unique turtlevax section. > > Sticking to 64-bit won't work, because some organizations *will* try to > dig themselves out of an RFC1918 quagmire and get reachability to > "the other end of our private net" by applying this 4 or 5 times to get > through the 4 or 5 layers of NAT they currently have. And then some > other dim bulb will connect one of those 5 layers to the outside world... > Those are just a few of the "many, many reasons" I alluded to... The "right" fix there is to define AA records that only have pairs of addresses. --Steve Bellovin, http://www.cs.columbia.edu/~smb From jschauma at netmeister.org Tue Mar 8 12:09:31 2011 From: jschauma at netmeister.org (Jan Schaumann) Date: Tue, 8 Mar 2011 13:09:31 -0500 Subject: L3DSR server side bits open sourced Message-ID: <20110308180930.GC8546@netmeister.org> Hello, Some of you may remember my talk at Nanog51 about L3DSR (http://nanog.org/meetings/nanog51/presentations/Monday/NANOG51.Talk45.nanog51-Schaumann.pdf). I had promised that we'd try to get the server side bits released soon. While it took longer than anticipated, I'm glad to be able to announce that as of about ten minutes ago, they have finally escaped^Wbeen released into the wild: https://github.com/yahoo/l3dsr It's possible that we will try to put together a more formal announcement of this, but since I had promised the release at Nanog, I figured it'd be fair to let you guys know first. :-) Vanity plug: https://twitter.com/#!/jschauma/status/45181937089908736 Happy L3DSR'ing! -Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From gbonser at seven.com Tue Mar 8 12:35:47 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 8 Mar 2011 10:35:47 -0800 Subject: Who owns (or is allocated) 208.64.200.0/22? In-Reply-To: References: <20110308161454.GA98448@mikea.ath.cx> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13F93@RWC-EX1.corp.seven.com> > From: Scott Howard > Sent: Tuesday, March 08, 2011 8:22 AM > To: NANOG list > Subject: Re: Who owns (or is allocated) 208.64.200.0/22? > > It was unallocated a few days ago : > http://lists.arin.net/pipermail/arin-issued/2011-March/000807.html > > Google will probably give you a fair idea why (the word "botnet" comes > up a > lot!) > > Scott > > 208.64.200.0/22 is currently listed in the cymru ipv4 "full bogons" list so yeah, that wouldn't be a valid IP block at the current time. From randy at psg.com Tue Mar 8 15:32:05 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Mar 2011 06:32:05 +0900 Subject: [afnog] Suspicious request for IP address space In-Reply-To: References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: > Even more suspicious is the fact that there is no organisational > information attached to the request and the sender used a gmail > address. They supplied an Indian telephone number. it is about this point where i realize that i am overloaded with real work, hit delete, and get back to that work. randy From randy at psg.com Tue Mar 8 15:38:42 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Mar 2011 06:38:42 +0900 Subject: L3DSR server side bits open sourced In-Reply-To: <20110308180930.GC8546@netmeister.org> References: <20110308180930.GC8546@netmeister.org> Message-ID: a real use for the diffserv bits! why not flowlabel in 6? it's been looking for a use for a decade. randy From george.herbert at gmail.com Tue Mar 8 15:42:23 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 8 Mar 2011 13:42:23 -0800 Subject: [afnog] Suspicious request for IP address space In-Reply-To: References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: On Tue, Mar 8, 2011 at 1:32 PM, Randy Bush wrote: >> Even more suspicious is the fact that there is no organisational >> information attached to the request and the sender used a gmail >> address. They supplied an Indian telephone number. > > it is about this point where i realize that i am overloaded with real > work, hit delete, and get back to that work. I view this as an excercise in applied humor and in the potential scammer's RFC-1918 knowledge. "I can offer you 172.29.128.0/17 for the reasonable price of..." However, if Real Work is sufficiently important today, the amusement value of pursuing it is probably not worth it. -- -george william herbert george.herbert at gmail.com From morrowc.lists at gmail.com Tue Mar 8 15:45:45 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 8 Mar 2011 16:45:45 -0500 Subject: L3DSR server side bits open sourced In-Reply-To: References: <20110308180930.GC8546@netmeister.org> Message-ID: On Tue, Mar 8, 2011 at 4:38 PM, Randy Bush wrote: > a real use for the diffserv bits! ?why not flowlabel in 6? ?it's been > looking for a use for a decade. v6 has subnet anycast... done and done! (also, a thing that's needed a use for 10 years) From randy at psg.com Tue Mar 8 15:48:24 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Mar 2011 06:48:24 +0900 Subject: L3DSR server side bits open sourced In-Reply-To: References: <20110308180930.GC8546@netmeister.org> Message-ID: > v6 has subnet anycast... done and done! never published Network Working Group R. Bush Internet-Draft IIJ Intended status: Standards Track August 2010 Expires: February 2, 2011 IPv6 Subnet Anycast Deprecated draft-ymbk-no-subnet-anycast-00 Abstract IPv6 subnet anycast is not used operationally, complicates implementations, and complicates protocol specifications. The form of anycast actually used in the Internet is routing-based, and is essentilly the same as that of IPv4 anycast. Therefore, this document deprecates IPv6 subnet anycast. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 2, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bush Expires February 2, 2011 [Page 1] Internet-Draft IPv6 Subnet Anycast Deprecated August 2010 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4.1. Normative References . . . . . . . . . . . . . . . . . . . 3 4.2. Informative References . . . . . . . . . . . . . . . . . . 3 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 4 Bush Expires February 2, 2011 [Page 2] Internet-Draft IPv6 Subnet Anycast Deprecated August 2010 1. Introduction The form of anycast which is used in the operational internet is described in [RFC4786]. This is used widely in IPv4 and IPv6. To quote, "To distribute a service using anycast, the service is first associated with a stable set of IP addresses, and reachability to those addresses is advertised in a routing system from multiple, independent service nodes." IPv6 subnet anycast, as defined in [RFC2526], complicates host and router stacks. It also makes address assignment unnecessarily complex, see [I-D.kohno-ipv6-prefixlen-p2p]. IPv6 subnet anycast is not actually used or deployed. In this case, it is sure that implementations are not even debugged. Therefore, this document deprecates IPv6 subnet anycast and removes conformance requirements from host and router implementations. 2. Security Considerations There are no known security implications for this document. 3. IANA Considerations This document has no IANA Considerations. 4. References 4.1. Normative References [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. 4.2. Informative References [I-D.kohno-ipv6-prefixlen-p2p] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., and L. Colitti, "Using 127-bit IPv6 Prefixes on Inter-Router Links", draft-kohno-ipv6-prefixlen-p2p-02 (work in progress), July 2010. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Bush Expires February 2, 2011 [Page 3] Internet-Draft IPv6 Subnet Anycast Deprecated August 2010 Services", BCP 126, RFC 4786, December 2006. Author's Address Randy Bush Internet Initiative Japan, Inc. 5147 Crystal Springs Bainbridge Island, Washington 98110 US Phone: +1 206 780 0431 x1 Email: randy at psg.com Bush Expires February 2, 2011 [Page 4] From jeffrey.lyon at blacklotus.net Tue Mar 8 15:58:27 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 8 Mar 2011 16:58:27 -0500 Subject: [afnog] Suspicious request for IP address space In-Reply-To: References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: Real Work can always be postponed for such great laughs. Jeff On Tue, Mar 8, 2011 at 4:42 PM, George Herbert wrote: > On Tue, Mar 8, 2011 at 1:32 PM, Randy Bush wrote: >>> Even more suspicious is the fact that there is no organisational >>> information attached to the request and the sender used a gmail >>> address. They supplied an Indian telephone number. >> >> it is about this point where i realize that i am overloaded with real >> work, hit delete, and get back to that work. > > I view this as an excercise in applied humor and in the potential > scammer's RFC-1918 knowledge. > > "I can offer you 172.29.128.0/17 for the reasonable price of..." > > However, if Real Work is sufficiently important today, the amusement > value of pursuing it is probably not worth it. > > > -- > -george william herbert > george.herbert at gmail.com > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From tammy-lists at wiztech.biz Tue Mar 8 16:05:35 2011 From: tammy-lists at wiztech.biz (Tammy A Wisdom) Date: Tue, 8 Mar 2011 15:05:35 -0700 Subject: [afnog] Suspicious request for IP address space In-Reply-To: References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: <217B0E56-5E80-4210-A4F3-D7FDB6A6028C@wiztech.biz> My isn't the pot calling the kettle black... I'm surprised your not offering them internet since you seem to be a spam heaven Jeffery (refering too your previous lies on nanog) Tammy AHBL/SOSDG Sent from my iPhone On Mar 8, 2011, at 14:58, Jeffrey Lyon wrote: > Real Work can always be postponed for such great laughs. > > Jeff > > On Tue, Mar 8, 2011 at 4:42 PM, George Herbert wrote: >> On Tue, Mar 8, 2011 at 1:32 PM, Randy Bush wrote: >>>> Even more suspicious is the fact that there is no organisational >>>> information attached to the request and the sender used a gmail >>>> address. They supplied an Indian telephone number. >>> >>> it is about this point where i realize that i am overloaded with real >>> work, hit delete, and get back to that work. >> >> I view this as an excercise in applied humor and in the potential >> scammer's RFC-1918 knowledge. >> >> "I can offer you 172.29.128.0/17 for the reasonable price of..." >> >> However, if Real Work is sufficiently important today, the amusement >> value of pursuing it is probably not worth it. >> >> >> -- >> -george william herbert >> george.herbert at gmail.com >> >> > > > > -- > Jeffrey Lyon, Leadership Team > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > Black Lotus Communications - AS32421 > First and Leading in DDoS Protection Solutions > ****************************************************************************** Disclaimer: This e-mail may contain trade secrets or privileged, undisclosed or otherwise confidential information. If you have received this e-mail in error, you are hereby notified that any review, copying or distribution of it is strictly prohibited. Please inform us immediately and destroy the original transmittal. Thank you for your cooperation. ****************************************************************************** From jeffrey.lyon at blacklotus.net Tue Mar 8 16:08:21 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 8 Mar 2011 17:08:21 -0500 Subject: [afnog] Suspicious request for IP address space In-Reply-To: <217B0E56-5E80-4210-A4F3-D7FDB6A6028C@wiztech.biz> References: <20110308134337.GI87854@macbook.catpipe.net> <217B0E56-5E80-4210-A4F3-D7FDB6A6028C@wiztech.biz> Message-ID: This reply is not only off topic, but is a perfect example of the "pot calling the kettle black." Jeff On Tue, Mar 8, 2011 at 5:05 PM, Tammy A Wisdom wrote: > My isn't the pot calling the kettle black... I'm surprised your not offering them internet since you seem to be a spam heaven Jeffery (refering too your previous lies on nanog) > Tammy > AHBL/SOSDG > > Sent from my iPhone > > On Mar 8, 2011, at 14:58, Jeffrey Lyon wrote: > >> Real Work can always be postponed for such great laughs. >> >> Jeff >> >> On Tue, Mar 8, 2011 at 4:42 PM, George Herbert wrote: >>> On Tue, Mar 8, 2011 at 1:32 PM, Randy Bush wrote: >>>>> Even more suspicious is the fact that there is no organisational >>>>> information attached to the request and the sender used a gmail >>>>> address. They supplied an Indian telephone number. >>>> >>>> it is about this point where i realize that i am overloaded with real >>>> work, hit delete, and get back to that work. >>> >>> I view this as an excercise in applied humor and in the potential >>> scammer's RFC-1918 knowledge. >>> >>> "I can offer you 172.29.128.0/17 for the reasonable price of..." >>> >>> However, if Real Work is sufficiently important today, the amusement >>> value of pursuing it is probably not worth it. >>> >>> >>> -- >>> -george william herbert >>> george.herbert at gmail.com >>> >>> >> >> >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications - AS32421 >> First and Leading in DDoS Protection Solutions >> > > ****************************************************************************** > Disclaimer: > > This e-mail may contain trade secrets or privileged, undisclosed or > otherwise confidential information. If you have received this e-mail > in error, you are hereby notified that any review, copying or > distribution of it is strictly prohibited. Please inform us > immediately and destroy the original transmittal. Thank you for your > cooperation. > > ****************************************************************************** > > -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From randy at psg.com Tue Mar 8 16:09:43 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Mar 2011 07:09:43 +0900 Subject: [afnog] Suspicious request for IP address space In-Reply-To: <217B0E56-5E80-4210-A4F3-D7FDB6A6028C@wiztech.biz> References: <20110308134337.GI87854@macbook.catpipe.net> <217B0E56-5E80-4210-A4F3-D7FDB6A6028C@wiztech.biz> Message-ID: > My isn't the pot calling the kettle black ok, children. recess is over. back to work. randy From chrise at ci.hillsboro.or.us Tue Mar 8 18:15:03 2011 From: chrise at ci.hillsboro.or.us (Chris Enger) Date: Tue, 8 Mar 2011 16:15:03 -0800 Subject: Internet Edge Router replacement - IPv6 route table size considerations Message-ID: Greetings, I am researching possible replacements for our Internet edge routers, and wanted to see what people could recommend for a smaller chassis or fixed router that can handle current IPv4 routes and transition into IPv6. Currently we have Brocade NetIron 4802s pulling full IPv4 routes plus a default route. I've looked at Extreme, Brocade, Cisco, and a few others. Most range from 256k - 500k IPv4 and 4k - 16k IPv6 routes when CAM space is allocated for both. The only exception I've found so far is the Cisco ASR 1002, which can do 125k v6 along with 500k v4 routes at once. I'm curious if any other vendors have comparable products. My concern is trying to find a router (within our budget) that has room for growth in the IPv6 routing space. When compared to the live table sizes that the CIDR report and routeviews show, some can't handle current routing tables, let alone years of growth. BGP tweaks may keep us going but I can't see how 16k or fewer IPv6 routes on a router is going to be viable a few years from now. Thank you, Chris Enger From gbonser at seven.com Tue Mar 8 18:18:33 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 8 Mar 2011 16:18:33 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13FC2@RWC-EX1.corp.seven.com> > From: Chris Enger > Sent: Tuesday, March 08, 2011 4:15 PM > To: 'nanog at nanog.org' > Subject: Internet Edge Router replacement - IPv6 route table > sizeconsiderations > > Greetings, > > I am researching possible replacements for our Internet edge > routers, and wanted to see what people could recommend for a smaller > chassis or fixed router that can handle current IPv4 routes and > transition into IPv6. Currently we have Brocade NetIron 4802s pulling > full IPv4 routes plus a default route. I've looked at Extreme, > Brocade, Cisco, and a few others. Most range from 256k - 500k IPv4 and > 4k - 16k IPv6 routes when CAM space is allocated for both. The only > exception I've found so far is the Cisco ASR 1002, which can do 125k v6 > along with 500k v4 routes at once. I'm curious if any other vendors > have comparable products. > The NetIron XMR will get you 1,000,000 routes. From tsison at gmail.com Tue Mar 8 18:32:30 2011 From: tsison at gmail.com (=?utf-8?B?dHNpc29uQGdtYWlsLmNvbQ==?=) Date: Tue, 08 Mar 2011 17:32:30 -0700 Subject: =?utf-8?B?UmU6IEludGVybmV0IEVkZ2UgUm91dGVyIHJlcGxhY2VtZW50IC0gSVB2NiByb3V0ZSB0YWJsZSBzaXplIGNvbnNpZGVyYXRpb25z?= Message-ID: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> have you looked into juniper networks? ----- Reply message ----- From: "Chris Enger" Date: Tue, Mar 8, 2011 5:15 pm Subject: Internet Edge Router replacement - IPv6 route table size considerations To: "'nanog at nanog.org'" Greetings, I am researching possible replacements for our Internet edge routers, and wanted to see what people could recommend for a smaller chassis or fixed router that can handle current IPv4 routes and transition into IPv6. Currently we have Brocade NetIron 4802s pulling full IPv4 routes plus a default route. I've looked at Extreme, Brocade, Cisco, and a few others. Most range from 256k - 500k IPv4 and 4k - 16k IPv6 routes when CAM space is allocated for both. The only exception I've found so far is the Cisco ASR 1002, which can do 125k v6 along with 500k v4 routes at once. I'm curious if any other vendors have comparable products. My concern is trying to find a router (within our budget) that has room for growth in the IPv6 routing space. When compared to the live table sizes that the CIDR report and routeviews show, some can't handle current routing tables, let alone years of growth. BGP tweaks may keep us going but I can't see how 16k or fewer IPv6 routes on a router is going to be viable a few years from now. Thank you, Chris Enger From owen at delong.com Tue Mar 8 18:51:46 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Mar 2011 16:51:46 -0800 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: References: Message-ID: I've been very happy with the Juniper J4350/6350 series. Owen On Mar 8, 2011, at 4:15 PM, Chris Enger wrote: > Greetings, > > I am researching possible replacements for our Internet edge routers, and wanted to see what people could recommend for a smaller chassis or fixed router that can handle current IPv4 routes and transition into IPv6. Currently we have Brocade NetIron 4802s pulling full IPv4 routes plus a default route. I've looked at Extreme, Brocade, Cisco, and a few others. Most range from 256k - 500k IPv4 and 4k - 16k IPv6 routes when CAM space is allocated for both. The only exception I've found so far is the Cisco ASR 1002, which can do 125k v6 along with 500k v4 routes at once. I'm curious if any other vendors have comparable products. > > My concern is trying to find a router (within our budget) that has room for growth in the IPv6 routing space. When compared to the live table sizes that the CIDR report and routeviews show, some can't handle current routing tables, let alone years of growth. BGP tweaks may keep us going but I can't see how 16k or fewer IPv6 routes on a router is going to be viable a few years from now. > > Thank you, > Chris Enger From chrise at ci.hillsboro.or.us Tue Mar 8 18:57:04 2011 From: chrise at ci.hillsboro.or.us (Chris Enger) Date: Tue, 8 Mar 2011 16:57:04 -0800 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> Message-ID: I did look at a Juniper J6350, and the documentation states it can handle 400k routes with 1GB of memory, or 1 million with 2GB. However it doesn?t spell out how that is divvyed up between the two based on a profile setting or some other mechanism. Chris From: tsison at gmail.com [mailto:tsison at gmail.com] Sent: Tuesday, March 08, 2011 4:33 PM To: Chris Enger; 'nanog at nanog.org' Subject: Re: Internet Edge Router replacement - IPv6 route table size considerations have you looked into juniper networks? ----- Reply message ----- From: "Chris Enger" Date: Tue, Mar 8, 2011 5:15 pm Subject: Internet Edge Router replacement - IPv6 route table size considerations To: "'nanog at nanog.org'" Greetings, I am researching possible replacements for our Internet edge routers, and wanted to see what people could recommend for a smaller chassis or fixed router that can handle current IPv4 routes and transition into IPv6. Currently we have Brocade NetIron 4802s pulling full IPv4 routes plus a default route. I've looked at Extreme, Brocade, Cisco, and a few others. Most range from 256k - 500k IPv4 and 4k - 16k IPv6 routes when CAM space is allocated for both. The only exception I've found so far is the Cisco ASR 1002, which can do 125k v6 along with 500k v4 routes at once. I'm curious if any other vendors have comparable products. My concern is trying to find a router (within our budget) that has room for growth in the IPv6 routing space. When compared to the live table sizes that the CIDR report and routeviews show, some can't handle current routing tables, let alone years of growth. BGP tweaks may keep us going but I can't see how 16k or fewer IPv6 routes on a router is going to be viable a few years from now. Thank you, Chris Enger From jlewis at lewis.org Tue Mar 8 19:01:13 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 8 Mar 2011 20:01:13 -0500 (EST) Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13FC2@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FC2@RWC-EX1.corp.seven.com> Message-ID: On Tue, 8 Mar 2011, George Bonser wrote: >> exception I've found so far is the Cisco ASR 1002, which can do 125k v6 >> along with 500k v4 routes at once. I'm curious if any other vendors >> have comparable products. >> > > The NetIron XMR will get you 1,000,000 routes. 1M of what kind of routes? A Sup720-3bxl can do 1M v4 routes or some split of v4 and v6 routes. i.e. L3 Forwarding Resources FIB TCAM usage: Total Used %Used 72 bits (IPv4, MPLS, EoM) 622592 348493 56% 144 bits (IP mcast, IPv6) 212992 263 1% ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From nanog at studio442.com.au Tue Mar 8 19:08:06 2011 From: nanog at studio442.com.au (Julien Goodwin) Date: Wed, 09 Mar 2011 12:08:06 +1100 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> Message-ID: <4D76D2F6.5030301@studio442.com.au> On 09/03/11 11:57, Chris Enger wrote: > I did look at a Juniper J6350, and the documentation states it can handle 400k routes with 1GB of memory, or 1 million with 2GB. However it doesn?t spell out how that is divvyed up between the two based on a profile setting or some other mechanism. It's a software router so the short answer is "it isn't" With 3GB of RAM both a 4350 and 6350 can easily handle multiple IPv4 feeds and an IPv6 feed (3GB just happens to be what I have due to upgrading from 1GB by adding a pair of 1GB sticks) If you need more then ~500Mbit or so then you would want something bigger. The MX80 is nice and has some cheap bundles at the moment; it's specced for 8M routes (unspecified, but the way Juniper chips typically store routes there's less difference in size then the straight 4x) >From others the Cisco ASR1k or Brocade NetIron XMR (2M routes IIRC) are the obvious choices. From nanog at studio442.com.au Tue Mar 8 19:09:27 2011 From: nanog at studio442.com.au (Julien Goodwin) Date: Wed, 09 Mar 2011 12:09:27 +1100 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: <4D76D2F6.5030301@studio442.com.au> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> Message-ID: <4D76D347.2030105@studio442.com.au> On 09/03/11 12:08, Julien Goodwin wrote: > On 09/03/11 11:57, Chris Enger wrote: >> I did look at a Juniper J6350, and the documentation states it can handle 400k routes with 1GB of memory, or 1 million with 2GB. However it doesn?t spell out how that is divvyed up between the two based on a profile setting or some other mechanism. > It's a software router so the short answer is "it isn't" > > With 3GB of RAM both a 4350 and 6350 can easily handle multiple IPv4 > feeds and an IPv6 feed (3GB just happens to be what I have due to > upgrading from 1GB by adding a pair of 1GB sticks) > > If you need more then ~500Mbit or so then you would want something > bigger. The MX80 is nice and has some cheap bundles at the moment; it's > specced for 8M routes (unspecified, but the way Juniper chips typically > store routes there's less difference in size then the straight 4x) > > From others the Cisco ASR1k or Brocade NetIron XMR (2M routes IIRC) are > the obvious choices. And I meant Brocade NetIron CES here. From chrise at ci.hillsboro.or.us Tue Mar 8 19:18:20 2011 From: chrise at ci.hillsboro.or.us (Chris Enger) Date: Tue, 8 Mar 2011 17:18:20 -0800 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: <4D76D347.2030105@studio442.com.au> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> Message-ID: Our Brocade reps pointed us to the CER 2000 series, and they can do up to 512k v4 or up to 128k v6. With other Brocade products they spell out the CAM profiles that are available, however I haven't found specifics on the CER series. Chris -----Original Message----- From: Julien Goodwin [mailto:nanog at studio442.com.au] Sent: Tuesday, March 08, 2011 5:09 PM To: 'nanog at nanog.org' Cc: Chris Enger Subject: Re: Internet Edge Router replacement - IPv6 route table size considerations On 09/03/11 12:08, Julien Goodwin wrote: > On 09/03/11 11:57, Chris Enger wrote: >> I did look at a Juniper J6350, and the documentation states it can handle 400k routes with 1GB of memory, or 1 million with 2GB. However it doesn?t spell out how that is divvyed up between the two based on a profile setting or some other mechanism. > It's a software router so the short answer is "it isn't" > > With 3GB of RAM both a 4350 and 6350 can easily handle multiple IPv4 > feeds and an IPv6 feed (3GB just happens to be what I have due to > upgrading from 1GB by adding a pair of 1GB sticks) > > If you need more then ~500Mbit or so then you would want something > bigger. The MX80 is nice and has some cheap bundles at the moment; it's > specced for 8M routes (unspecified, but the way Juniper chips typically > store routes there's less difference in size then the straight 4x) > > From others the Cisco ASR1k or Brocade NetIron XMR (2M routes IIRC) are > the obvious choices. And I meant Brocade NetIron CES here. From gbonser at seven.com Tue Mar 8 19:58:02 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 8 Mar 2011 17:58:02 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13FCA@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Chris Enger [mailto:chrise at ci.hillsboro.or.us] > Sent: Tuesday, March 08, 2011 5:18 PM > To: 'jgoodwin at studio442.com.au'; 'nanog at nanog.org' > Subject: RE: Internet Edge Router replacement - IPv6 route table > sizeconsiderations > > Our Brocade reps pointed us to the CER 2000 series, and they can do up > to 512k v4 or up to 128k v6. With other Brocade products they spell > out the CAM profiles that are available, however I haven't found > specifics on the CER series. > > Chris > \ CER features are here: http://www.brocade.com/products/all/routers/product-details/netiron-cer-2000-series/features.page From bret at getjive.com Tue Mar 8 20:45:12 2011 From: bret at getjive.com (Bret Palsson) Date: Tue, 8 Mar 2011 19:45:12 -0700 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13FCA@RWC-EX1.corp.seven.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC13FCA@RWC-EX1.corp.seven.com> Message-ID: <-2617086122573867169@unknownmsgid> We use both NI-CERs and NI-XMRs for less than 175k. Work with a rep. Don't go by list. The price depends on quantity and configuration. So less than 175k could mean 80k or 500k for your config. -Bret Sent from my iPhone On Mar 8, 2011, at 6:59 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Chris Enger [mailto:chrise at ci.hillsboro.or.us] >> Sent: Tuesday, March 08, 2011 5:18 PM >> To: 'jgoodwin at studio442.com.au'; 'nanog at nanog.org' >> Subject: RE: Internet Edge Router replacement - IPv6 route table >> sizeconsiderations >> >> Our Brocade reps pointed us to the CER 2000 series, and they can do up >> to 512k v4 or up to 128k v6. With other Brocade products they spell >> out the CAM profiles that are available, however I haven't found >> specifics on the CER series. >> >> Chris >> \ > > CER features are here: > > http://www.brocade.com/products/all/routers/product-details/netiron-cer-2000-series/features.page > > From jack at crepinc.com Tue Mar 8 20:47:11 2011 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 8 Mar 2011 21:47:11 -0500 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13FCA@RWC-EX1.corp.seven.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC13FCA@RWC-EX1.corp.seven.com> Message-ID: Get a cheap J series, load it full of memory, forget about it. If you haven't played with Juniper gear before, you will be quite pleased. -Jack Carrozzo On Tue, Mar 8, 2011 at 8:58 PM, George Bonser wrote: > > > > -----Original Message----- > > From: Chris Enger [mailto:chrise at ci.hillsboro.or.us] > > Sent: Tuesday, March 08, 2011 5:18 PM > > To: 'jgoodwin at studio442.com.au'; 'nanog at nanog.org' > > Subject: RE: Internet Edge Router replacement - IPv6 route table > > sizeconsiderations > > > > Our Brocade reps pointed us to the CER 2000 series, and they can do up > > to 512k v4 or up to 128k v6. With other Brocade products they spell > > out the CAM profiles that are available, however I haven't found > > specifics on the CER series. > > > > Chris > > \ > > CER features are here: > > > http://www.brocade.com/products/all/routers/product-details/netiron-cer-2000-series/features.page > > > From jackson.tim at gmail.com Tue Mar 8 21:04:05 2011 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 8 Mar 2011 21:04:05 -0600 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC13FCA@RWC-EX1.corp.seven.com> Message-ID: MX80 is perfect for this.. 5g 10g bundles are cheap.. On Mar 8, 2011 8:49 PM, "Jack Carrozzo" wrote: > Get a cheap J series, load it full of memory, forget about it. If you > haven't played with Juniper gear before, you will be quite pleased. > > -Jack Carrozzo > > On Tue, Mar 8, 2011 at 8:58 PM, George Bonser wrote: > >> >> >> > -----Original Message----- >> > From: Chris Enger [mailto:chrise at ci.hillsboro.or.us] >> > Sent: Tuesday, March 08, 2011 5:18 PM >> > To: 'jgoodwin at studio442.com.au'; 'nanog at nanog.org' >> > Subject: RE: Internet Edge Router replacement - IPv6 route table >> > sizeconsiderations >> > >> > Our Brocade reps pointed us to the CER 2000 series, and they can do up >> > to 512k v4 or up to 128k v6. With other Brocade products they spell >> > out the CAM profiles that are available, however I haven't found >> > specifics on the CER series. >> > >> > Chris >> > \ >> >> CER features are here: >> >> >> http://www.brocade.com/products/all/routers/product-details/netiron-cer-2000-series/features.page >> >> >> From swmike at swm.pp.se Tue Mar 8 21:17:35 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 9 Mar 2011 04:17:35 +0100 (CET) Subject: estimation of number of DFZ IPv4 routes at peak in the future Message-ID: Hi. We had an interesting discussion the other day at work. We were speculating on how many DFZ IPv4 routes there would be at peak in the future before it starts to decline again due to less IPv4 usage. The current number is around 350k, and my personal estimation is that it would grow by at least 100k more due to the the last 5 /8s being carved up at around /22 meaning each /8 ending up with 16k routes, plus the last allocations being seen in the remaining RIR "normal allocations" would be smaller than before plus de-aggregation of space as people "sell" or "lease" subspace of their allocations. My guess therefore is a peak around 450-500k IPv4 DFZ routes and that this would happen in around 3-5 years. I wanted to record this for posterity. What is your guess, any why? -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Tue Mar 8 21:44:05 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Mar 2011 12:44:05 +0900 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: Message-ID: i am more of a pessimist. i suspect that there will be enough v4-only destinations out there that multi-homed enterprises fronting onto dual-stack backbones will announce teenie bits of v4 so they can nat64. randy From rcarpen at network1.net Tue Mar 8 21:52:01 2011 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 08 Mar 2011 22:52:01 -0500 (EST) Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: Message-ID: But, even one of the small MX80 bundles are about the price of 5 J4350s or 3 J6350s. Granted, if you need the throughput, it is very difficult to beat an MX80, particularly one of the 5g or 10g bundles. -Randy ----- Original Message ----- > MX80 is perfect for this.. 5g 10g bundles are cheap.. > On Mar 8, 2011 8:49 PM, "Jack Carrozzo" wrote: > > Get a cheap J series, load it full of memory, forget about it. If > > you > > haven't played with Juniper gear before, you will be quite pleased. > > > > -Jack Carrozzo > > > > On Tue, Mar 8, 2011 at 8:58 PM, George Bonser > > wrote: > > > >> > >> > >> > -----Original Message----- > >> > From: Chris Enger [mailto:chrise at ci.hillsboro.or.us] > >> > Sent: Tuesday, March 08, 2011 5:18 PM > >> > To: 'jgoodwin at studio442.com.au'; 'nanog at nanog.org' > >> > Subject: RE: Internet Edge Router replacement - IPv6 route table > >> > sizeconsiderations > >> > > >> > Our Brocade reps pointed us to the CER 2000 series, and they can > >> > do up > >> > to 512k v4 or up to 128k v6. With other Brocade products they > >> > spell > >> > out the CAM profiles that are available, however I haven't found > >> > specifics on the CER series. > >> > > >> > Chris > >> > \ > >> > >> CER features are here: > >> > >> > >> > http://www.brocade.com/products/all/routers/product-details/netiron-cer-2000-series/features.page > >> > >> > >> > > From bill at herrin.us Tue Mar 8 21:55:19 2011 From: bill at herrin.us (William Herrin) Date: Tue, 8 Mar 2011 22:55:19 -0500 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: Message-ID: On Tue, Mar 8, 2011 at 10:17 PM, Mikael Abrahamsson wrote: > We had an interesting discussion the other day at work. We were speculating > on how many DFZ IPv4 routes there would be at peak in the future before it > starts to decline again due to less IPv4 usage. > My guess therefore is a peak around 450-500k IPv4 DFZ routes and that this > would happen in around 3-5 years. I wanted to record this for posterity. > > What is your guess, any why? Five million. Assuming the /24 boundary holds (this is likely) and we're only carrying global unicast and anycast routes (1. to 223. excluding RFC1918, 127, etc) the theoretical maximum number of possible IPv4 prefixes is around 28M. (2**24)*0.8~=14M /24's. Plus 7M /23s, 4M /22's, etc. However, practical issues will prevent excessive numbers of fully covered prefixes... So we won't generally see both /24's under a /23. We might see a /24 and a covering /23 but if we do we won't generally see the other /24. This drops us to an upper bound of 14M. There will also be a significant number of prefixes where there's just no gain from breaking them up. You're using the entire /20 at your site and you only have one /24 that you want routed differently than "normal." This will pull it down still further, cutting it somewhere between half and a third of the 14M upper bound. It'll take 10 to 20 years to get there. If we're actually able to start retiring IPv4 in 10 years then it'll peak lower. But if IPv4 sticks around, I think the global IPv4 BGP table will reach a steady state somewhere around 5 million prefixes. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jared at puck.nether.net Tue Mar 8 22:10:42 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 8 Mar 2011 23:10:42 -0500 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: Message-ID: <16967D01-4466-4B76-B620-600F12BC9877@puck.nether.net> On Mar 8, 2011, at 10:17 PM, Mikael Abrahamsson wrote: > My guess therefore is a peak around 450-500k IPv4 DFZ routes and that this would happen in around 3-5 years. I wanted to record this for posterity. > > What is your guess, any why? I think it'll end up around the same range, mostly due to hardware with built-in route limits. Some providers will be stuck with this for ~5-7 years due to equipment lifecycle depreciation. - jared From owen at delong.com Tue Mar 8 22:40:51 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 8 Mar 2011 20:40:51 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: Message-ID: <1A267DE4-0F98-41E3-A0FC-19021EA4406E@delong.com> You have ignored the probability of disaggregation due to IP trading markets, especially given the wild-west nature of the APNIC transfer policy. Many of the legacy blocks will get dramatically disaggregated in the likely market which could take the DFZ well beyond 500k routes. It will be very interesting to watch. Owen On Mar 8, 2011, at 7:17 PM, Mikael Abrahamsson wrote: > > Hi. > > We had an interesting discussion the other day at work. We were speculating on how many DFZ IPv4 routes there would be at peak in the future before it starts to decline again due to less IPv4 usage. The current number is around 350k, and my personal estimation is that it would grow by at least 100k more due to the the last 5 /8s being carved up at around /22 meaning each /8 ending up with 16k routes, plus the last allocations being seen in the remaining RIR "normal allocations" would be smaller than before plus de-aggregation of space as people "sell" or "lease" subspace of their allocations. > > My guess therefore is a peak around 450-500k IPv4 DFZ routes and that this would happen in around 3-5 years. I wanted to record this for posterity. > > What is your guess, any why? > > -- > Mikael Abrahamsson email: swmike at swm.pp.se From george.herbert at gmail.com Tue Mar 8 22:55:57 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 8 Mar 2011 20:55:57 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <1A267DE4-0F98-41E3-A0FC-19021EA4406E@delong.com> References: <1A267DE4-0F98-41E3-A0FC-19021EA4406E@delong.com> Message-ID: On Tue, Mar 8, 2011 at 8:40 PM, Owen DeLong wrote: > You have ignored the probability of disaggregation due to IP trading markets, especially > given the wild-west nature of the APNIC transfer policy. > > Many of the legacy blocks will get dramatically disaggregated in the likely market which > could take the DFZ well beyond 500k routes. > > It will be very interesting to watch. > > Owen > > On Mar 8, 2011, at 7:17 PM, Mikael Abrahamsson wrote: > >> >> Hi. >> >> We had an interesting discussion the other day at work. We were speculating on how many DFZ IPv4 routes there would be at peak in the future before it starts to decline again due to less IPv4 usage. The current number is around 350k, and my personal estimation is that it would grow by at least 100k more due to the the last 5 /8s being carved up at around /22 meaning each /8 ending up with 16k routes, plus the last allocations being seen in the remaining RIR "normal allocations" would be smaller than before plus de-aggregation of space as people "sell" or "lease" subspace of their allocations. >> >> My guess therefore is a peak around 450-500k IPv4 DFZ routes and that this would happen in around 3-5 years. I wanted to record this for posterity. >> >> What is your guess, any why? Strange, had this exact conversation with a boutique ISP owner I know earlier today... My hope is that things peak around 510k and that routers that can handle about a million routes now can handle all of IPv4Peak and IPv6 growth for their economic lifetimes. Disaggregation and leasing of space (or whatever) could easily spike that significantly, but aren't likely to further increase the rate of new announcements, merely how long we keep going with them. I predict that we can't really predict this yet; IPv6 actual adoption isn't far enough along to tell how bad that will end up being. If it's five years before it dominates things, we're screwed on IPv4 tables. People who need smallish but routeable blocks will be able to find them and pry them loose via enough funds and announce them. 5 more years of that, and current routers go "poof". Many go "poof" sooner. -- -george william herbert george.herbert at gmail.com From msa at latt.net Tue Mar 8 23:43:48 2011 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 8 Mar 2011 22:43:48 -0700 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: Message-ID: <20110309054348.GA46879@puck.nether.net> On Wed, Mar 09, 2011 at 12:44:05PM +0900, Randy Bush wrote: > i am more of a pessimist. i suspect that there will be enough v4-only > destinations out there that multi-homed enterprises fronting onto > dual-stack backbones will announce teenie bits of v4 so they can nat64. I'll take this one a little further. I suspect that as we reach exhaustion, more people will be forced to break space out of their provider's v4 aggregates, and announce them, and an unfiltered DFZ may well approach the 'million' entries some vendors now claim to support. Conveniently, we've given them enough ASes to do so, with four byte support. At least if our vendors get that working correctly. If we get there, or even close (anything beyond 0.5M), I expect we'll see some of the native dual stack networks actually acquire transport specifically for v6 and start running parallel 4/6 networks to deal with hardware forwarding limitations, particularly those involving v6. Of course, I'd really, really, really love to be wrong here. It'd be great if v4 traffic fell off quickly enough people wouldn't deagg for TE purposes, or v4 growth fell off, and a widespread forwarding problem could be avoided. --msa From frnkblk at iname.com Wed Mar 9 00:12:43 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 9 Mar 2011 00:12:43 -0600 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13FC2@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FC2@RWC-EX1.corp.seven.com> Message-ID: <007a01cbde21$00ba0870$022e1950$@iname.com> That's 1M IPv4 routes, IIRC. Put IPv6 into the mix and that 1M quickly shrinks. Frank -----Original Message----- From: George Bonser [mailto:gbonser at seven.com] Sent: Tuesday, March 08, 2011 6:19 PM To: Chris Enger; nanog at nanog.org Subject: RE: Internet Edge Router replacement - IPv6 route table sizeconsiderations > From: Chris Enger > Sent: Tuesday, March 08, 2011 4:15 PM > To: 'nanog at nanog.org' > Subject: Internet Edge Router replacement - IPv6 route table > sizeconsiderations > > Greetings, > > I am researching possible replacements for our Internet edge > routers, and wanted to see what people could recommend for a smaller > chassis or fixed router that can handle current IPv4 routes and > transition into IPv6. Currently we have Brocade NetIron 4802s pulling > full IPv4 routes plus a default route. I've looked at Extreme, > Brocade, Cisco, and a few others. Most range from 256k - 500k IPv4 and > 4k - 16k IPv6 routes when CAM space is allocated for both. The only > exception I've found so far is the Cisco ASR 1002, which can do 125k v6 > along with 500k v4 routes at once. I'm curious if any other vendors > have comparable products. > The NetIron XMR will get you 1,000,000 routes. From swmike at swm.pp.se Wed Mar 9 00:27:05 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Wed, 9 Mar 2011 07:27:05 +0100 (CET) Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <1A267DE4-0F98-41E3-A0FC-19021EA4406E@delong.com> References: <1A267DE4-0F98-41E3-A0FC-19021EA4406E@delong.com> Message-ID: On Tue, 8 Mar 2011, Owen DeLong wrote: > On Mar 8, 2011, at 7:17 PM, Mikael Abrahamsson wrote: >> last allocations being seen in the remaining RIR "normal allocations" >> would be smaller than before plus de-aggregation of space as people >> "sell" or "lease" subspace of their allocations. > You have ignored the probability of disaggregation due to IP trading markets, especially > given the wild-west nature of the APNIC transfer policy. No, I haven't ignored it. I'm just more optimistic about IPv6 deployment and that there will be a lot less de-aggregation due to trading than others are. -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Wed Mar 9 00:31:02 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 08 Mar 2011 22:31:02 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <007a01cbde21$00ba0870$022e1950$@iname.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FC2@RWC-EX1.corp.seven.com> <007a01cbde21$00ba0870$022e1950$@iname.com> Message-ID: <4D771EA6.60609@bogus.com> On 3/8/11 10:12 PM, Frank Bulk wrote: > That's 1M IPv4 routes, IIRC. Put IPv6 into the mix and that 1M quickly > shrinks. >> I am researching possible replacements for our Internet edge >> routers, and wanted to see what people could recommend for a smaller >> chassis or fixed router that can handle current IPv4 routes and >> transition into IPv6. Currently we have Brocade NetIron 4802s pulling >> full IPv4 routes plus a default route. I've looked at Extreme, >> Brocade, Cisco, and a few others. Most range from 256k - 500k IPv4 > and >> 4k - 16k IPv6 routes when CAM space is allocated for both. The only >> exception I've found so far is the Cisco ASR 1002, which can do 125k > v6 >> along with 500k v4 routes at once. I'm curious if any other vendors >> have comparable products. >> Mx80 Doesn't use CAM for route lookups and the actual number of routes is 72MB of RLDRAM holds will vary based on the distribution of sizes but it's north of 2 Million ipv4 routes. > The NetIron XMR will get you 1,000,000 routes. > > > > From gbonser at seven.com Wed Mar 9 01:19:52 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 8 Mar 2011 23:19:52 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <007a01cbde21$00ba0870$022e1950$@iname.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FC2@RWC-EX1.corp.seven.com> <007a01cbde21$00ba0870$022e1950$@iname.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13FD2@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Frank Bulk [mailto:frnkblk at iname.com] > Sent: Tuesday, March 08, 2011 10:13 PM > To: George Bonser; nanog at nanog.org > Subject: RE: Internet Edge Router replacement - IPv6 route table > sizeconsiderations > > That's 1M IPv4 routes, IIRC. Put IPv6 into the mix and that 1M quickly > shrinks. > > Frank > Yes, you have two choices with the Brocade gear. You can have it set to install the /64 prefix in the table making a v6 route 2x as expensive as a v4 route (default behavior) or you can have it use the entire 128 bit destination where it becomes 4x more expensive. The ipv4-ipv6-2 CAM profile in 5.1 gives 768K v4 routes and 64k v6 routes which should be good for quite a while. That is provided you aren't using MPLS VPNs. If you are, the best you can get using static CAM profiles is multi-service-2 which gives you 384K v4 and 128K v6. But you can put the thing in dynamic cam mode where unused entries can be aged out saving resources for routes you never really talk to: Dynamic mode - In the dynamic mode, routes are entered into the CAM dynamically using a flow-based scheme, where routes are only added to the CAM as they are required. Once routes are added to the CAM, they can be aged-out when they are not in use. Because this mode conserves CAM, it is useful for situations where CAM resources are stressed or limited. Static mode - In the static mode, routes are entered into the CAM whenever they are discovered. Routes are not aged once routes are added to the CAM and can be aged-out when they are not in use. The default behavior is static mode. I use dynamic mode on dual-stack gear at the moment with the ipv4-ipv6-2 CAM profile. From igor at gashinsky.net Wed Mar 9 01:35:21 2011 From: igor at gashinsky.net (Igor Gashinsky) Date: Wed, 9 Mar 2011 02:35:21 -0500 (EST) Subject: L3DSR server side bits open sourced In-Reply-To: References: <20110308180930.GC8546@netmeister.org> Message-ID: On Wed, 9 Mar 2011, Randy Bush wrote: :: a real use for the diffserv bits! why not flowlabel in 6? it's been :: looking for a use for a decade. Honestly, we figured flowlabel might actually find a use before all the values of diffserv will :) In all seriousness, we are starting to set the spec for v6 l3dsr now, so, if you care, and believe that flowlabel would be a better field to "hijack" (or have a suggestion for another, better way then same DSCP methodology that we used for ipv4), we welcome input.. Thanks, -igor (yahoo) From randy at psg.com Wed Mar 9 01:37:40 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Mar 2011 16:37:40 +0900 Subject: L3DSR server side bits open sourced In-Reply-To: References: <20110308180930.GC8546@netmeister.org> Message-ID: > :: a real use for the diffserv bits! why not flowlabel in 6? it's been > :: looking for a use for a decade. > > Honestly, we figured flowlabel might actually find a use before all the > values of diffserv will :) In all seriousness, we are starting to set the > spec for v6 l3dsr now, so, if you care, and believe that flowlabel would > be a better field to "hijack" (or have a suggestion for another, better > way then same DSCP methodology that we used for ipv4), we welcome input.. well, compared to an extension header, it wins hands down. randy From randy at psg.com Wed Mar 9 01:40:20 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Mar 2011 16:40:20 +0900 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <1A267DE4-0F98-41E3-A0FC-19021EA4406E@delong.com> Message-ID: btw, this discussion should not forget that the load on routers is churn and number of paths, not just prefix count. randy From gbonser at seven.com Wed Mar 9 01:41:42 2011 From: gbonser at seven.com (George Bonser) Date: Tue, 8 Mar 2011 23:41:42 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> > From: Randy Bush > Sent: Tuesday, March 08, 2011 7:44 PM > To: Mikael Abrahamsson > Cc: nanog at nanog.org > Subject: Re: estimation of number of DFZ IPv4 routes at peak in the > future > > i am more of a pessimist. i suspect that there will be enough v4-only > destinations out there that multi-homed enterprises fronting onto > dual-stack backbones will announce teenie bits of v4 so they can nat64. > > randy I suspect people will get varying experiences with that. That they will attempt to multi-home with teenie bits of v4 I don't disagree with but that teenie bit better be part of a larger aggregate that can reach at least one of their runs home. There will likely be considerable filtration once there is enough dual-stack pressure put on gear, and v6 being where the growth is it will get priority. Dual-homing to their ISP might be a compromise solution seen more often with v4 in that scenario. From randy at psg.com Wed Mar 9 02:35:57 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Mar 2011 17:35:57 +0900 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> Message-ID: >> i am more of a pessimist. i suspect that there will be enough >> v4-only destinations out there that multi-homed enterprises fronting >> onto dual-stack backbones will announce teenie bits of v4 so they can >> nat64. > that teenie bit better be part of a larger aggregate that can reach at > least one of their runs home. the last serious satainc phylters died in 2001. sales&marketing pressure. when eyecandy.com is behind a /27, or your s&m folk sell to weenie.foo who wants you to announce their /26, it will be the end of the /24 barrier. > v6 being where the growth is it will get priority. we wish. wanna start a pool on the growth of v6 announcements vs new multi-homed v4 announcements? randy From joelja at bogus.com Wed Mar 9 03:18:13 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 09 Mar 2011 01:18:13 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> Message-ID: <4D7745D5.6040608@bogus.com> On 3/9/11 12:35 AM, Randy Bush wrote: >>> i am more of a pessimist. i suspect that there will be enough >>> v4-only destinations out there that multi-homed enterprises fronting >>> onto dual-stack backbones will announce teenie bits of v4 so they can >>> nat64. >> that teenie bit better be part of a larger aggregate that can reach at >> least one of their runs home. > > the last serious satainc phylters died in 2001. sales&marketing > pressure. when eyecandy.com is behind a /27, or your s&m folk > sell to weenie.foo who wants you to announce their /26, it will be > the end of the /24 barrier. > >> v6 being where the growth is it will get priority. > > we wish. wanna start a pool on the growth of v6 announcements vs > new multi-homed v4 announcements? one of these curves is steeper than the other. http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step If the slope on the second stays within some reasonable bounds of it's current trajactory then everything's cool, you buy new routers on schedule and the world moves on. The first one however will eventually kill us. The long run is a misleading guide to current affairs. In the long run we are all dead - John Maynard Keynes > randy > From rs at seastrom.com Wed Mar 9 03:37:43 2011 From: rs at seastrom.com (Robert E. Seastrom) Date: Wed, 09 Mar 2011 04:37:43 -0500 Subject: What vexes VoIP users? - Bufferbloat In-Reply-To: <4D701378.3060403@freedesktop.org> (Jim Gettys's message of "Thu, 03 Mar 2011 17:17:28 -0500") References: <4952321.01298971523361.JavaMail.root@jennyfur.pelican.org> <20110301033231.203521fc@petrie> <4D701378.3060403@freedesktop.org> Message-ID: <86sjuwr5w8.fsf@seastrom.com> Jim Gettys writes: > Now that I have mitigated the bufferbloat disaster in my home cable > service via bandwidth shaping, Skype works sooo much better for > me. This is what devices such as Ooma are doing. Unfortunately, it > means you have to defeat features such as Comcast's PowerBoost. Actually not... if your queueing scheme is smart enough to stay one step ahead of PowerBoost it works fine. https://calomel.org/pf_hfsc.html I run flashrd/OpenBSD 4.8 on an ALIX 2D3. Love it. -r From randy at psg.com Wed Mar 9 03:50:15 2011 From: randy at psg.com (Randy Bush) Date: Wed, 09 Mar 2011 18:50:15 +0900 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <4D7745D5.6040608@bogus.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> <4D7745D5.6040608@bogus.com> Message-ID: > one of these curves is steeper than the other. > > http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step > > http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step hey geoff, would you put on same graph :) From tony at lava.net Wed Mar 9 03:55:25 2011 From: tony at lava.net (Antonio Querubin) Date: Tue, 8 Mar 2011 23:55:25 -1000 (HST) Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <4D7745D5.6040608@bogus.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> <4D7745D5.6040608@bogus.com> Message-ID: On Wed, 9 Mar 2011, Joel Jaeggli wrote: > one of these curves is steeper than the other. > > http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step > > http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step > > If the slope on the second stays within some reasonable bounds of it's > current trajactory then everything's cool, you buy new routers on > schedule and the world moves on. The first one however will eventually > kill us. A valid comparison really needs to use the same vertical scale. That first is only 2300 new entries in the last 12 months. The other is 35000 new entries in the same period. Antonio Querubin e-mail/xmpp: tony at lava.net From Gavin.Pearce at 3seven9.com Wed Mar 9 04:49:17 2011 From: Gavin.Pearce at 3seven9.com (Gavin Pearce) Date: Wed, 9 Mar 2011 10:49:17 -0000 Subject: Interesting google redirects. In-Reply-To: <4D70831D.4050001@viviotech.net> References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> <4D6FC7E6.5020100@p8x.net> <4D70831D.4050001@viviotech.net> Message-ID: Sure you all know this already: http://google.com/ncr Temp fix for getting the .com version. G -----Original Message----- From: Mark Keymer [mailto:mark at viviotech.net] Sent: 04 March 2011 06:14 To: Raymond Macharia Cc: nanog at nanog.org Subject: Re: Interesting google redirects. On this same subject. My techs have been complaining lately about our new VPS's we are making going to google.vm. Is there anything I can do on my end to get this corrected? Sincerely, Mark Keymer Raymond Macharia wrote: >Noticed the same thing to the .com.hk >Raymond Macharia > > >On Thu, Mar 3, 2011 at 8:04 PM, Wayne Lee wrote: > > > >>>>also some EU customers are getting redirected to .au domain >>>> >>>> >>Mine got redirected to google.be for a while. >> >> >> >> From avg at kotovnik.com Wed Mar 9 05:34:18 2011 From: avg at kotovnik.com (Vadim Antonov) Date: Wed, 09 Mar 2011 03:34:18 -0800 Subject: IPv4 address shortage? Really? In-Reply-To: References: <1299580116.29652.176.camel@kotti.kotovnik.com> Message-ID: <1299670458.29652.219.camel@kotti.kotovnik.com> On Tue, 2011-03-08 at 07:37 -0500, Steven Bellovin wrote: > > > > ...well, kind of. What you don't mention is that it was thought to be > > ugly and rejected solely on the aesthetic grounds. Which is somewhat > > different from being rejected because it cannot work. > No. It was rejected because routers tended to melt down into quivering > puddles of silicon from seeing many packets with IP options set -- a fast > trip to the slow path. Let me get it right... an important factor in the architectural decision was that the current OFRV implementation of a router was buggy-by-design? Worse, when having a choice between something which already worked (slow as it were - the IPv4 options) and something which didn't exist at all (the new L3 frame format) the chosen one was the thing which didn't exist. Any wonder it took so long to get IPv6 into any shape resembling working? > It also requires just as many changes to applications > and DNS content, and about as large an addressing plan change as v6. There > were more reasons, but they escape me at the moment. Not really. DNS change is trivial; and if 64-bit extended IPv4 address was choosen (instead of a new address family) 80% applications would only needed to be recompiled with a different header file having long long instead of int in s_addr. Most of the rest would only need a change in a data type and maybe in custom address-to-string formats. Compare that with try-one-address family and if failed try another logic which you need to build into every app with the dual-stack approach. Do you remember the mighty trouble with changing from 32-bit file sizes to 64-bit size_t in Linux? No? That's the point. Valdis.Kletnieks at vt.edu wrote: > Steve, you of all people should remember the other big reason why: > pathalias tended to do Very Bad Things like violating the Principle of > Least Surprise As the guy who implemented the country-wide domain name e-mail router over UUCP, I remember this issue pretty well. In any case, it is not applicable if you structure 32-bit address spaces into a tree. Which maps very nicely onto the real-life Internet topology. Steven Bellovin wrote: > And then some other dim bulb will connect one of those 5 layers to the > outside world... A dim bulb has infinite (and often much subtler) ways of screwing routing in his employer's network. Protecting against idiots is the weakest argument I ever heard for architectural design. (Now, I don't deny value of designing UIs and implementation logic in a way which helps people to avoid mistakes... how could I, having been doing GPS Z to SQL just a few hours ago, in IMC:) So. You pretty much confirmed my original contention that the choice was made not because of technical merits of the LSRR or IPv4 extended address option but merely because people wanted to build beautifully perfect Network Two - at the expense of compatibility and ease of transition. Well, I think IPv4 will outlive IPv6 for precisely this reason. The real-life users don't care about what's under the hood - but they do care that the stuff they used to have working will keep working. And the real-life net admins would do whatever it takes to keep the users happy - even if it is ugly as hell. --vadim From arturo.servin at gmail.com Wed Mar 9 06:06:04 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 9 Mar 2011 10:06:04 -0200 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <4D7745D5.6040608@bogus.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> <4D7745D5.6040608@bogus.com> Message-ID: <4E69369F-BA08-4FCD-B589-22C2EE5E987B@gmail.com> On 9 Mar 2011, at 07:18, Joel Jaeggli wrote: > > one of these curves is steeper than the other. That's what we wanted for the first one. > > http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step > > http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step > > If the slope on the second stays within some reasonable bounds of it's > current trajactory then everything's cool, you buy new routers on > schedule and the world moves on. The first one however will eventually > kill us. It won't, it will take an "S" shape eventually. Possibly around 120k prefixes, then it will follow the normal growth of the Internet as v4 did. > > The long run is a misleading guide to current affairs. In the long run > we are all dead - John Maynard Keynes > > >> randy >> > -as From lear at cisco.com Wed Mar 9 06:31:03 2011 From: lear at cisco.com (Eliot Lear) Date: Wed, 09 Mar 2011 13:31:03 +0100 Subject: IPv4 address shortage? Really? In-Reply-To: <42008.1299591179@localhost> References: <1299580116.29652.176.camel@kotti.kotovnik.com> <42008.1299591179@localhost> Message-ID: <4D777307.70409@cisco.com> On 3/8/11 2:32 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 08 Mar 2011 07:37:27 EST, Steven Bellovin said: > >> No. It was rejected because routers tended to melt down into quivering >> puddles of silicon from seeing many packets with IP options set -- a fast >> trip to the slow path. It also requires just as many changes to applications >> and DNS content, and about as large an addressing plan change as v6. There >> were more reasons, but they escape me at the moment. > Steve, you of all people should remember the other big reason why: > > pathalias tended to do Very Bad Things like violating the Principle of Least > Surprise if there were two distinct nodes both called 'turtlevax' or whatever. > That, and if you think BGP convergence sucks, imagine trying to run pathalias > for a net the size of the current Internet. :) No No. That was Mel Pleasant and me? the RABID REROUTERs. And people weren't all THAT surprised. But beyond that, I've actually done some analysis on doing nearly just that. If you think about it there are about 300,000 entries, and this is not beyond the capacity of an O(nlog(n)) algorithm like, for instance, Dijkstra in a modern world. And before you say, ?Ew! SPF for Interdomain?, we had the precise same debate for IGP back in 1990 or so. The only big difference is that exposing of policy in SPF isn't that desirable. And quite frankly the idea has gone around a few times, the one that remains in my head was TRIAD, which was work done by Gritter and Cheriton. Eliot From bblackford at gmail.com Wed Mar 9 07:53:01 2011 From: bblackford at gmail.com (Bill Blackford) Date: Wed, 9 Mar 2011 05:53:01 -0800 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: References: Message-ID: Chris, With address exhaustion and deaggregation, the table is only going to get bigger so choosing anything now that can only handle anything south of 1M routes is not a wise investment. Several posters have recommended ASR1002 and MX80. I use both of these platforms in my environment and have been quite pleased with both. ARA100x. Cisco has lower/cheaper options here including a 1RU device. I don't have the specs handy, but these are lacking in scalability that you will most likely need. I believe the forwarding cap is 2.5G. With the ASR1002, you can start up with the 5G forwarding board. The MX80. There are several models/bundles. A good choice for you may be the MX80-5G. Incidentally, the "5G" does not mean 5gig. It ships with a 20 port ge MIC that will do line rate. The other MIC and the on-board 4X 10GE are disabled. As previously mentioned, it doesn't use TCAM so your V4, V6 routes don't share finite resources with each other or MAC entires, etc. If you're familiar with the benefits if JUNOS - once you've used it for awhile - it's hard to go back. If your environment is rapidly growing, stay away from low CAM limits,anything that's runs in software, (C7200, C7330, J6350), and make the jump to line-rate hardware devices. -b On Tue, Mar 8, 2011 at 4:15 PM, Chris Enger wrote: > Greetings, > > ? ?I am researching possible replacements for our Internet edge routers, and wanted to see what people could recommend for a smaller chassis or fixed router that can handle current IPv4 routes and transition into IPv6. ?Currently we have Brocade NetIron 4802s pulling full IPv4 routes plus a default route. ?I've looked at Extreme, Brocade, Cisco, and a few others. ?Most range from 256k - 500k IPv4 and 4k - 16k IPv6 routes when CAM space is allocated for both. ?The only exception I've found so far is the Cisco ASR 1002, which can do 125k v6 along with 500k v4 routes at once. ?I'm curious if any other vendors have comparable products. > > My concern is trying to find a router (within our budget) that has room for growth in the IPv6 routing space. ?When compared to the live table sizes that the CIDR report and routeviews show, some can't handle current routing tables, let alone years of growth. ?BGP tweaks may keep us going but I can't see how 16k or fewer IPv6 routes on a router is going to be viable a few years from now. > > Thank you, > Chris Enger > > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From jcurran at istaff.org Wed Mar 9 08:32:41 2011 From: jcurran at istaff.org (John Curran) Date: Wed, 9 Mar 2011 09:32:41 -0500 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <20110309054348.GA46879@puck.nether.net> References: <20110309054348.GA46879@puck.nether.net> Message-ID: <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> On Mar 9, 2011, at 12:43 AM, Majdi S. Abbas wrote: > On Wed, Mar 09, 2011 at 12:44:05PM +0900, Randy Bush wrote: >> i am more of a pessimist. i suspect that there will be enough v4-only >> destinations out there that multi-homed enterprises fronting onto >> dual-stack backbones will announce teenie bits of v4 so they can nat64. > > I'll take this one a little further. > > I suspect that as we reach exhaustion, more people will be > forced to break space out of their provider's v4 aggregates, and > announce them, and an unfiltered DFZ may well approach the 'million' > entries some vendors now claim to support. This matches my personal view (and could be viewed as "success" compared to the 5M estimate of Mr. Herrin...) /John From oiyankok at yahoo.ca Wed Mar 9 08:41:43 2011 From: oiyankok at yahoo.ca (ann kok) Date: Wed, 9 Mar 2011 06:41:43 -0800 (PST) Subject: ipv6 question Message-ID: <320484.18776.qm@web111304.mail.gq1.yahoo.com> Hi I read ipv6forum.pdf about ipv6 It said MTU must be at least 1280 bytes (1500+) Does it mean to set the mtu over 1500 I set my linux box eth0 as 2001:db8:cafe:1111::12/64 but I can't ping it inet6 2001:db8:cafe:1111::12/64 scope global tentative ls it this problem? Thank you # ping6 2001:db8:cafe:1111::12 PING 2001:db8:cafe:1111::12(2001:db8:cafe:1111::12) 56 data bytes >From ::1 icmp_seq=1 Destination unreachable: Address unreachable >From ::1 icmp_seq=2 Destination unreachable: Address unreachable From admin+nanog at msk4.com Wed Mar 9 09:01:35 2011 From: admin+nanog at msk4.com (imNet Administrator) Date: Wed, 09 Mar 2011 09:01:35 -0600 Subject: ipv6 question In-Reply-To: <320484.18776.qm@web111304.mail.gq1.yahoo.com> References: <320484.18776.qm@web111304.mail.gq1.yahoo.com> Message-ID: <4D77964F.1000606@msk4.com> On 3/9/2011 8:41 AM, ann kok wrote: > Hi > > I read ipv6forum.pdf about ipv6 > > It said > > MTU must be at least 1280 bytes (1500+) > Does it mean to set the mtu over 1500 No, it simply means that the minimum MTU for IPv6 is 1280. > > I set my linux box eth0 as 2001:db8:cafe:1111::12/64 but I can't ping it > inet6 2001:db8:cafe:1111::12/64 scope global tentative > > ls it this problem? Thank you Where are you pinging it from? also, the 2001:db8::/32 prefix is used for "documentation purposes" and might be handled differently by the TCP/IP stack. > > > # ping6 2001:db8:cafe:1111::12 > PING 2001:db8:cafe:1111::12(2001:db8:cafe:1111::12) 56 > > > data bytes > > >>From ::1 icmp_seq=1 Destination unreachable: > > > Address unreachable > > >>From ::1 icmp_seq=2 Destination unreachable: > > > Address unreachable > > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature URL: From shane at castlepoint.net Wed Mar 9 09:12:53 2011 From: shane at castlepoint.net (Shane Amante) Date: Wed, 9 Mar 2011 08:12:53 -0700 Subject: L3DSR server side bits open sourced In-Reply-To: References: <20110308180930.GC8546@netmeister.org> Message-ID: <2A59479C-DD1E-4A1D-9719-44CA77E16DAC@castlepoint.net> On Mar 9, 2011, at 00:35 MST, Igor Gashinsky wrote: > On Wed, 9 Mar 2011, Randy Bush wrote: > > :: a real use for the diffserv bits! why not flowlabel in 6? it's been > :: looking for a use for a decade. > > Honestly, we figured flowlabel might actually find a use before all the > values of diffserv will :) In all seriousness, we are starting to set the > spec for v6 l3dsr now, so, if you care, and believe that flowlabel would > be a better field to "hijack" (or have a suggestion for another, better > way then same DSCP methodology that we used for ipv4), we welcome input.. :-/ Please don't abuse the flow-label this way, otherwise your proposal could get added to the "graveyard of IPv6 flow-label proposals" draft: http://tools.ietf.org/html/draft-hu-flow-label-cases-03#section-3 There has been *a lot* of discussion in the 6man WG recently to (finally) define the flow-label to be: a) be stateless; and, b) potentially be useful as an input-key, when used in conjunction with {src_ip, dst_ip}, for fine-grained load-balancing over LAG & ECMP paths, (instead of the traditional IPv6 header 5-tuple). One example where this might be useful is within Layer-2 switches, at IXP's or other parts of the network, where you'd really like them to only have to look at the 3-tuple: {src_ip, dst_ip + flow-label} as input-keys for LAG load-balancing, since they are at a fixed location in the IPv6 header. The other, longer-term win of this approach is that hosts can be free to define, or re-define, new IPv6 Extension Headers and you won't have to worry about Core routers/switches needing to dig into those Ext. headers (or, past them) to find useful input-keys for load-balancing over LAG & ECMP paths. Take a look at the following drafts and comment on the 6man WG mailing list if you have questions or concerns: IPv6 Flow Label Specification -- proposed revisions to the most current (& confusing) flow-label RFC: http://tools.ietf.org/html/draft-ietf-6man-flow-3697bis-01 Using the IPv6 flow label for equal cost multipath routing and link aggregation in tunnels http://tools.ietf.org/html/draft-ietf-6man-flow-ecmp-01 Rationale for update to the IPv6 flow label specification http://tools.ietf.org/html/draft-ietf-6man-flow-update-03 -shane From jsw at inconcepts.biz Wed Mar 9 09:21:03 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 9 Mar 2011 10:21:03 -0500 Subject: How many IPv6 BGP routes are you planning for in DFZ? Message-ID: On Wed, Mar 9, 2011 at 2:19 AM, George Bonser wrote: > The ipv4-ipv6-2 CAM profile in 5.1 gives 768K v4 routes and 64k v6 > routes which should be good for quite a while. ?That is provided you How many IPv6 BGP routes are folks typically planning for in the DFZ before a hardware upgrade is required? Here are some relevant figures (note that my script makes some minor errors but this is good enough for discussion purposes): IPv6: Unique Origin ASes seen: 3287 Examined 4705 active routes IPv4: Unique Origin ASes seen: 36707 Examined 352688 active routes Making some assumptions, let's say every active ASN in DFZ will announce a mean of 1.4 IPv6 routes (the number seen today.) If IPv6 grows from under 10% of ASNs today to 100% of ASNs in a year or two, we will see about 53k IPv6 routes in DFZ. Keep in mind that many, if not most, ASNs originating IPv6 routes today have substantially no production services on IPv6, and they may deaggregate more in the future, etc. Some folks seem to believe that not every ASN will announce routes to the DFZ. I don't think that is a safe assumption upon which to base purchasing decisions for routers which should have a life-cycle of several years. Whether or not networks *should* announce more than one route, or any routes at all, seems debatable; but when making router purchasing decisions, I don't want to tell my clients two years from now that they have to spend capital dollars on routers just to gain IPv6 FIB. I also don't want to tell them they have to filter some routes, and make any BGP customers unhappy, and live with other downfalls of that unfortunate compromise. I am certainly not deploying any boxes that will only do 64k IPv6 FIB in default-free part of my clients' networks. It certainly will work now, and will almost certainly be safe in one year. In two years, it seems a little questionable. Beyond that time-frame, it is much easier to justify new routers, as ports become cheaper and faster; but I still do not want my clients to be forced to buy new routers simply because of overly-optimistic assumptions about IPv6 DFZ size. Really, I would like vendors to make IPv4 and IPv6 FIB come from the same pool (with obviously different allocation sizes) or allow me to configure the partitioning as I see fit. This has been the case for quite a few platforms for many years. I am not comfortable guessing at whether I will first need to exceed 500K IPv4 routes (maybe we won't even see that number) or 64K IPv6 routes (this seems a virtual certainty, but when it happens is hard to say.) Once you add L3VPN into your list of concerns, your future FIB needs become even more difficult to predict. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From Valdis.Kletnieks at vt.edu Wed Mar 9 09:25:51 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 09 Mar 2011 10:25:51 -0500 Subject: IPv4 address shortage? Really? In-Reply-To: Your message of "Wed, 09 Mar 2011 03:34:18 PST." <1299670458.29652.219.camel@kotti.kotovnik.com> References: <1299580116.29652.176.camel@kotti.kotovnik.com> <1299670458.29652.219.camel@kotti.kotovnik.com> Message-ID: <14397.1299684351@localhost> On Wed, 09 Mar 2011 03:34:18 PST, Vadim Antonov said: > Steven Bellovin wrote: > > > And then some other dim bulb will connect one of those 5 layers to the > > outside world... Broken attribution alert - I wrote that, not Steve.. > A dim bulb has infinite (and often much subtler) ways of screwing > routing in his employer's network. Protecting against idiots is the > weakest argument I ever heard for architectural design. Yes, a dim bulb can do other things. That doesn't mean it's OK to simply ignore totally predictable failure modes. Consider BGP - what happens when some dim bulb manages to create a routing loop? What would have happened if the BGP designers had said "We're not going to worry about this because there's other things the dim bulb can do to hose himself"? -------------- 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 Wed Mar 9 09:27:05 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Wed, 9 Mar 2011 07:27:05 -0800 Subject: How many IPv6 BGP routes are you planning for in DFZ? In-Reply-To: References: Message-ID: <20110309152705.GA6492@ussenterprise.ufp.org> In a message written on Wed, Mar 09, 2011 at 10:21:03AM -0500, Jeff Wheeler wrote: > Making some assumptions, let's say every active ASN in DFZ will > announce a mean of 1.4 IPv6 routes (the number seen today.) If IPv6 I figure backbone gear should have a lifespan of 5 years minimum, and that it is typically really bad to push it past about 85-90%. Using both of those I would assume around 2 routes per ASN, and probably on the order of 70k ASN's in use in 5 years, so 140,000 route minimum capability. > Really, I would like vendors to make IPv4 and IPv6 FIB come from the > same pool (with obviously different allocation sizes) or allow me to > configure the partitioning as I see fit. This has been the case for I like having them both come from the same pool, but I never understood the need for the network operator to configure partitioning. It seems like the boxes should be able to adjust the partition dynamically with an overall fill rate > 95%. I don't want to have to go back and recompute a partition size every 6 months if the tables together end up nearly filling memory, or have to maintain different partitions for core and edge boxes. Maybe in 1995 I would have accepted manual partitioning, but come on, memory management has moved on. -- 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 joelja at bogus.com Wed Mar 9 10:51:08 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 09 Mar 2011 08:51:08 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> <4D7745D5.6040608@bogus.com> Message-ID: <4D77AFFC.5000501@bogus.com> On 3/9/11 1:55 AM, Antonio Querubin wrote: > On Wed, 9 Mar 2011, Joel Jaeggli wrote: > >> one of these curves is steeper than the other. >> >> http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step >> >> >> http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step >> >> >> If the slope on the second stays within some reasonable bounds of it's >> current trajactory then everything's cool, you buy new routers on >> schedule and the world moves on. The first one however will eventually >> kill us. > > A valid comparison really needs to use the same vertical scale. That > first is only 2300 new entries in the last 12 months. The other is > 35000 new entries in the same period. No it doesn't. I'm more concerned about the percentage rather than absolute numbers and one of these things is doubling annually. I'll go out on a limb and say I need 150k ipv6 routes in gear that's supposed to last to 2016. joel > Antonio Querubin > e-mail/xmpp: tony at lava.net > From gbonser at seven.com Wed Mar 9 11:05:57 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Mar 2011 09:05:57 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC13FE1@RWC-EX1.corp.seven.com> > the last serious satainc phylters died in 2001. sales&marketing > pressure. when eyecandy.com is behind a /27, or your s&m folk > sell to weenie.foo who wants you to announce their /26, it will be > the end of the /24 barrier. Sure, you can sell to someone who wants to announce a /26 and you can carry the route, but you can't force your peers or your peers' peers to take it. That's what I meant by the experience possibly varying. It might work, it might not from some locations. > > v6 being where the growth is it will get priority. > > we wish. wanna start a pool on the growth of v6 announcements vs > new multi-homed v4 announcements? I meant growth in traffic, not routing table. If traffic is growing on v6 and a network with dual-stacked routers comes under routing table pressure, v6 might win in the filtering decision. From owen at delong.com Wed Mar 9 11:28:02 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 9 Mar 2011 09:28:02 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <4E69369F-BA08-4FCD-B589-22C2EE5E987B@gmail.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> <4D7745D5.6040608@bogus.com> <4E69369F-BA08-4FCD-B589-22C2EE5E987B@gmail.com> Message-ID: <5B86E65F-4D37-4F8F-87D7-D5D4CD9AED6B@delong.com> On Mar 9, 2011, at 4:06 AM, Arturo Servin wrote: > > On 9 Mar 2011, at 07:18, Joel Jaeggli wrote: >> >> one of these curves is steeper than the other. > > That's what we wanted for the first one. > >> >> http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step >> > >> http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step >> >> If the slope on the second stays within some reasonable bounds of it's >> current trajactory then everything's cool, you buy new routers on >> schedule and the world moves on. The first one however will eventually >> kill us. > > It won't, it will take an "S" shape eventually. Possibly around 120k prefixes, then it will follow the normal growth of the Internet as v4 did. > I think it will grow a lot slower than IPv4 because with rational planning, few organizations should need to add more prefixes annually, the way they had to in IPv4 due to scarcity based allocation policies. Owen From george.herbert at gmail.com Wed Mar 9 11:48:06 2011 From: george.herbert at gmail.com (George Herbert) Date: Wed, 9 Mar 2011 09:48:06 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <5B86E65F-4D37-4F8F-87D7-D5D4CD9AED6B@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> <4D7745D5.6040608@bogus.com> <4E69369F-BA08-4FCD-B589-22C2EE5E987B@gmail.com> <5B86E65F-4D37-4F8F-87D7-D5D4CD9AED6B@delong.com> Message-ID: On Wed, Mar 9, 2011 at 9:28 AM, Owen DeLong wrote: > > On Mar 9, 2011, at 4:06 AM, Arturo Servin wrote: > >> >> On 9 Mar 2011, at 07:18, Joel Jaeggli wrote: >>> >>> one of these curves is steeper than the other. >> >> ? ? ? That's what we wanted for the first one. >> >>> >>> http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fv6%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step >>> >> >>> http://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step >>> >>> If the slope on the second stays within some reasonable bounds of it's >>> current trajactory then everything's cool, you buy new routers on >>> schedule and the world moves on. The first one however will eventually >>> kill us. >> >> ? ? ? It won't, it will take an "S" shape eventually. Possibly around 120k prefixes, then it will follow the normal growth of the Internet as v4 did. >> > I think it will grow a lot slower than IPv4 because with rational planning, few organizations should need to add more > prefixes annually, the way they had to in IPv4 due to scarcity based allocation policies. ...which was, ultimately, a large part of the point of going to 128 bits. The most important one for networks. -- -george william herbert george.herbert at gmail.com From drc at virtualized.org Wed Mar 9 12:00:22 2011 From: drc at virtualized.org (David Conrad) Date: Wed, 9 Mar 2011 08:00:22 -1000 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <5B86E65F-4D37-4F8F-87D7-D5D4CD9AED6B@delong.com> References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> <4D7745D5.6040608@bogus.com> <4E69369F-BA08-4FCD-B589-22C2EE5E987B@gmail.com> <5B86E65F-4D37-4F8F-87D7-D5D4CD9AED6B@delong.com> Message-ID: On Mar 9, 2011, at 7:28 AM, Owen DeLong wrote: >> It won't, it will take an "S" shape eventually. Possibly around 120k prefixes, then it will follow the normal growth of the Internet as v4 did. > I think it will grow a lot slower than IPv4 because with rational planning, few organizations should need to add more prefixes annually, the way they had to in IPv4 due to scarcity based allocation policies. The implication of this statement would seem to be that the reason the routing tables are growing is due primarily to allocations and not deaggregation (e.g., for traffic engineering). Does anyone have any actual data to corroborate or refute this? Regards, -drc From chrise at ci.hillsboro.or.us Wed Mar 9 12:25:21 2011 From: chrise at ci.hillsboro.or.us (Chris Enger) Date: Wed, 9 Mar 2011 10:25:21 -0800 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: References: Message-ID: Thank you everyone for the suggestions both on and off list. We will be looking at a few additional devices along with what we have researched. Thanks, Chris -----Original Message----- From: Bill Blackford [mailto:bblackford at gmail.com] Sent: Wednesday, March 09, 2011 5:53 AM To: Chris Enger Cc: nanog at nanog.org Subject: Re: Internet Edge Router replacement - IPv6 route table size considerations Chris, With address exhaustion and deaggregation, the table is only going to get bigger so choosing anything now that can only handle anything south of 1M routes is not a wise investment. Several posters have recommended ASR1002 and MX80. I use both of these platforms in my environment and have been quite pleased with both. ARA100x. Cisco has lower/cheaper options here including a 1RU device. I don't have the specs handy, but these are lacking in scalability that you will most likely need. I believe the forwarding cap is 2.5G. With the ASR1002, you can start up with the 5G forwarding board. The MX80. There are several models/bundles. A good choice for you may be the MX80-5G. Incidentally, the "5G" does not mean 5gig. It ships with a 20 port ge MIC that will do line rate. The other MIC and the on-board 4X 10GE are disabled. As previously mentioned, it doesn't use TCAM so your V4, V6 routes don't share finite resources with each other or MAC entires, etc. If you're familiar with the benefits if JUNOS - once you've used it for awhile - it's hard to go back. If your environment is rapidly growing, stay away from low CAM limits,anything that's runs in software, (C7200, C7330, J6350), and make the jump to line-rate hardware devices. -b On Tue, Mar 8, 2011 at 4:15 PM, Chris Enger wrote: > Greetings, > > ? ?I am researching possible replacements for our Internet edge routers, and wanted to see what people could recommend for a smaller chassis or fixed router that can handle current IPv4 routes and transition into IPv6. ?Currently we have Brocade NetIron 4802s pulling full IPv4 routes plus a default route. ?I've looked at Extreme, Brocade, Cisco, and a few others. ?Most range from 256k - 500k IPv4 and 4k - 16k IPv6 routes when CAM space is allocated for both. ?The only exception I've found so far is the Cisco ASR 1002, which can do 125k v6 along with 500k v4 routes at once. ?I'm curious if any other vendors have comparable products. > > My concern is trying to find a router (within our budget) that has room for growth in the IPv6 routing space. ?When compared to the live table sizes that the CIDR report and routeviews show, some can't handle current routing tables, let alone years of growth. ?BGP tweaks may keep us going but I can't see how 16k or fewer IPv6 routes on a router is going to be viable a few years from now. > > Thank you, > Chris Enger > > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From arturo.servin at gmail.com Wed Mar 9 12:30:20 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Wed, 9 Mar 2011 16:30:20 -0200 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> <4D7745D5.6040608@bogus.com> <4E69369F-BA08-4FCD-B589-22C2EE5E987B@gmail.com> <5B86E65F-4D37-4F8F-87D7-D5D4CD9AED6B@delong.com> Message-ID: <8994979B-8146-44C7-B0E7-488497909178@gmail.com> http://scholar.google.com/scholar?hl=en&as_sdt=0,5&cluster=6058676534328717115 @article{cittadini2010evolution, title={{Evolution of Internet Address Space Deaggregation: Myths and Reality}}, author={Cittadini, L. and Muhlbauer, W. and Uhlig, S. and Bush, R. and Fran{\c{c}}ois, P. and Maennel, O.}, journal={Selected Areas in Communications, IEEE Journal on}, volume={28}, number={8}, pages={1238--1249}, issn={0733-8716}, year={2010}, publisher={IEEE} } But times are changing and IMHO in the future the growth would be because of deaggregation (in v4). For v6 the growth I assume is (and will be) allocation, but I do not have a research to support that. -as On 9 Mar 2011, at 16:00, David Conrad wrote: > On Mar 9, 2011, at 7:28 AM, Owen DeLong wrote: >>> It won't, it will take an "S" shape eventually. Possibly around 120k prefixes, then it will follow the normal growth of the Internet as v4 did. >> I think it will grow a lot slower than IPv4 because with rational planning, few organizations should need to add more prefixes annually, the way they had to in IPv4 due to scarcity based allocation policies. > > The implication of this statement would seem to be that the reason the routing tables are growing is due primarily to allocations and not deaggregation (e.g., for traffic engineering). Does anyone have any actual data to corroborate or refute this? > > Regards, > -drc > From igor at gashinsky.net Wed Mar 9 12:30:37 2011 From: igor at gashinsky.net (Igor Gashinsky) Date: Wed, 9 Mar 2011 13:30:37 -0500 (EST) Subject: L3DSR server side bits open sourced In-Reply-To: <2A59479C-DD1E-4A1D-9719-44CA77E16DAC@castlepoint.net> References: <20110308180930.GC8546@netmeister.org> <2A59479C-DD1E-4A1D-9719-44CA77E16DAC@castlepoint.net> Message-ID: On Wed, 9 Mar 2011, Shane Amante wrote: :: :: On Mar 9, 2011, at 00:35 MST, Igor Gashinsky wrote: :: > On Wed, 9 Mar 2011, Randy Bush wrote: :: > :: > :: a real use for the diffserv bits! why not flowlabel in 6? it's been :: > :: looking for a use for a decade. :: > :: > Honestly, we figured flowlabel might actually find a use before all the :: > values of diffserv will :) In all seriousness, we are starting to set the :: > spec for v6 l3dsr now, so, if you care, and believe that flowlabel would :: > be a better field to "hijack" (or have a suggestion for another, better :: > way then same DSCP methodology that we used for ipv4), we welcome input.. :: :: :-/ Please don't abuse the flow-label this way, otherwise your proposal could get added to the "graveyard of IPv6 flow-label proposals" draft: :: http://tools.ietf.org/html/draft-hu-flow-label-cases-03#section-3 :: :: There has been *a lot* of discussion in the 6man WG recently to (finally) define the flow-label to be: a) be stateless; and, b) potentially be useful as an input-key, when used in conjunction with {src_ip, dst_ip}, for fine-grained load-balancing over LAG & ECMP paths, (instead of the traditional IPv6 header 5-tuple). One example where this might be useful is within Layer-2 switches, at IXP's or other parts of the network, where you'd really like them to only have to look at the 3-tuple: {src_ip, dst_ip + flow-label} as input-keys for LAG load-balancing, since they are at a fixed location in the IPv6 header. The other, longer-term win of this approach is that hosts can be free to define, or re-define, new IPv6 Extension Headers and you won't have to worry about Core routers/switches needing to dig into those Ext. headers (or, past them) to find useful input-keys for load-balancing over LAG & ECMP paths. :: Yeap, this is why I said flow-label might actually find a good use soon enough :) -igor From heather.schiller at verizonbusiness.com Wed Mar 9 13:32:53 2011 From: heather.schiller at verizonbusiness.com (Schiller, Heather A) Date: Wed, 09 Mar 2011 19:32:53 +0000 Subject: Geolocation Info Correction Needed at Apple, Yahoo, MSN Message-ID: If anyone is listening, would you be so kind as to update geolocation info for the following-- they are in Mexico, not Argentina. inetnum: 186.64.16.176/29 status: reallocated owner: Infor Global Solutions Mexico SA de CV ownerid: MX-IGSM-LACNIC responsible: Hector Garcia Bernal address: Montes Urales 505 Lomas de Chapultepec, , address: - mexico city - country: MX I couldn't find information on how to get geolocation errors corrected for Apple, Yahoo or MSN on their websites. It would be nice if folks would also update http://nanog.cluepon.net/index.php/GeoIP which details the process for several large sites. Thanks, --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241 security at verizonbusiness.com From frnkblk at iname.com Wed Mar 9 13:50:07 2011 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 9 Mar 2011 13:50:07 -0600 Subject: Geolocation Info Correction Needed at Apple, Yahoo, MSN In-Reply-To: References: Message-ID: <001c01cbde93$314b2c40$93e184c0$@iname.com> There is no (publicly) known process for those three major sites -- if anyone does learn, please update the wiki. Probably the best place to start with each of those is the generic support e-mail/web form. Frank -----Original Message----- From: Schiller, Heather A [mailto:heather.schiller at verizonbusiness.com] Sent: Wednesday, March 09, 2011 1:33 PM To: nanog at merit.edu Subject: Geolocation Info Correction Needed at Apple, Yahoo, MSN If anyone is listening, would you be so kind as to update geolocation info for the following-- they are in Mexico, not Argentina. inetnum: 186.64.16.176/29 status: reallocated owner: Infor Global Solutions Mexico SA de CV ownerid: MX-IGSM-LACNIC responsible: Hector Garcia Bernal address: Montes Urales 505 Lomas de Chapultepec, , address: - mexico city - country: MX I couldn't find information on how to get geolocation errors corrected for Apple, Yahoo or MSN on their websites. It would be nice if folks would also update http://nanog.cluepon.net/index.php/GeoIP which details the process for several large sites. Thanks, --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241 security at verizonbusiness.com From joelja at bogus.com Wed Mar 9 14:07:18 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 09 Mar 2011 12:07:18 -0800 Subject: Geolocation Info Correction Needed at Apple, Yahoo, MSN In-Reply-To: References: Message-ID: <4D77DDF6.6080303@bogus.com> I'd be willing to bet that's maxmind's geoip database. for some if not all three it corroborates the argentina response... correction at maxmind.com On 3/9/11 11:32 AM, Schiller, Heather A wrote: > > If anyone is listening, would you be so kind as to update geolocation > info for the following-- they are in Mexico, not Argentina. > > inetnum: 186.64.16.176/29 > status: reallocated > owner: Infor Global Solutions Mexico SA de CV > ownerid: MX-IGSM-LACNIC > responsible: Hector Garcia Bernal > address: Montes Urales 505 Lomas de Chapultepec, , > address: - mexico city - > country: MX > > I couldn't find information on how to get geolocation errors corrected > for Apple, Yahoo or MSN on their websites. It would be nice if folks > would also update http://nanog.cluepon.net/index.php/GeoIP which > details the process for several large sites. > > Thanks, > --Heather > > ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* > Heather Schiller > Network Security - Verizon Business > 1.800.900.0241 security at verizonbusiness.com > > From heather.schiller at verizonbusiness.com Wed Mar 9 14:24:56 2011 From: heather.schiller at verizonbusiness.com (Schiller, Heather A) Date: Wed, 09 Mar 2011 20:24:56 +0000 Subject: Anyone has a contact with IP clue at VerizonBusiness? In-Reply-To: <20110303151803.GA15474@corp.zubrcom.net> References: <20110303151803.GA15474@corp.zubrcom.net> Message-ID: Hi :) I don't manage IP space day to day anymore.. But can get you in touch w/ the folks who do. No promises, as I don't know what the issue is - but I can try to help clear up any problem as well. ..and there really isn't a panic over here, we've known it was coming for years. --Heather -----Original Message----- From: Alex Yuriev [mailto:alex-lists-nanog at yuriev.com] Sent: Thursday, March 03, 2011 10:18 AM To: nanog at nanog.org Subject: Anyone has a contact with IP clue at VerizonBusiness? I know it may be a stretch but is there a remote possibility that someone knows anyone inside Verizon Business who has an ounce of clue about IPv4 address allocation and routing? It seems the panic over IPv4 scarcity is resulting in the most peculiar ideas bubbling up in the IP provisioning side which must be stomped out of existence before such ideas create signigicant connectivity issues. Thanks, Alex From randy at psg.com Wed Mar 9 16:30:37 2011 From: randy at psg.com (Randy Bush) Date: Thu, 10 Mar 2011 07:30:37 +0900 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC13FD5@RWC-EX1.corp.seven.com> <4D7745D5.6040608@bogus.com> <4E69369F-BA08-4FCD-B589-22C2EE5E987B@gmail.com> <5B86E65F-4D37-4F8F-87D7-D5D4CD9AED6B@delong.com> Message-ID: > The implication of this statement would seem to be that the reason the > routing tables are growing is due primarily to allocations and not > deaggregation (e.g., for traffic engineering). Does anyone have any > actual data to corroborate or refute this? Luca Cittadini, Wolfgang M?hlbauer, Steve Uhlig, Randy Bush, Pierre Francois, Olaf Maennel, Evolution of Internet Address Space Deaggregation: Myths and Reality, in IEEE Journal on Selected Areas in Communications, Vol. 28, No. 8, October 2010. http://archive.psg.com/jsac-deagg.pdf randy From kauer at biplane.com.au Wed Mar 9 16:57:29 2011 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 10 Mar 2011 09:57:29 +1100 Subject: ipv6 question In-Reply-To: <4D77964F.1000606@msk4.com> References: <320484.18776.qm@web111304.mail.gq1.yahoo.com> <4D77964F.1000606@msk4.com> Message-ID: <1299711449.2109.98.camel@karl> On Wed, 2011-03-09 at 09:01 -0600, imNet Administrator wrote: > Where are you pinging it from? also, the 2001:db8::/32 prefix is used > for "documentation purposes" and might be handled differently by the > TCP/IP stack. Works fine in Linux - I've been using it (in an isolated training room setup) for years. 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: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From marka at isc.org Wed Mar 9 18:43:31 2011 From: marka at isc.org (Mark Andrews) Date: Thu, 10 Mar 2011 11:43:31 +1100 Subject: ipv6 question In-Reply-To: Your message of "Thu, 10 Mar 2011 09:57:29 +1100." <1299711449.2109.98.camel@karl> References: <320484.18776.qm@web111304.mail.gq1.yahoo.com> <4D77964F.1000606@msk4.com><1299711449.2109.98.camel@karl> Message-ID: <20110310004335.C0B56C02D01@drugs.dv.isc.org> In message <1299711449.2109.98.camel at karl>, Karl Auer writes: > On Wed, 2011-03-09 at 09:01 -0600, imNet Administrator wrote: > > Where are you pinging it from? also, the 2001:db8::/32 prefix is used > > for "documentation purposes" and might be handled differently by the > > TCP/IP stack. > > Works fine in Linux - I've been using it (in an isolated training room > setup) for years. > > Regards, K. It is not a good idea to use the documentation prefix for anything other than documentation. How hard is it to generate a ULA and use it? > --=20 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > > --=-nDQtqdgDW08ncP39wFQZ > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: This is a digitally signed message part > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > > iEYEABECAAYFAk14BdEACgkQMAcU7Vc29oc3ewCffqKqCJQ67ytpAHeAT7iZ834G > 5SMAniLZpqhnAS8Nk3HRcZzhaRrF1c0L > =PFHP > -----END PGP SIGNATURE----- > > --=-nDQtqdgDW08ncP39wFQZ-- > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rekoil at semihuman.com Wed Mar 9 20:11:29 2011 From: rekoil at semihuman.com (Chris Woodfield) Date: Wed, 9 Mar 2011 18:11:29 -0800 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> Message-ID: I think this is the point where I get a shovel, a bullwhip and head over to the horse graveyard that is CAM optimization... -C On Mar 8, 2011, at 5:18 20PM, Chris Enger wrote: > Our Brocade reps pointed us to the CER 2000 series, and they can do up to 512k v4 or up to 128k v6. With other Brocade products they spell out the CAM profiles that are available, however I haven't found specifics on the CER series. > > Chris > > -----Original Message----- > From: Julien Goodwin [mailto:nanog at studio442.com.au] > Sent: Tuesday, March 08, 2011 5:09 PM > To: 'nanog at nanog.org' > Cc: Chris Enger > Subject: Re: Internet Edge Router replacement - IPv6 route table size considerations > > On 09/03/11 12:08, Julien Goodwin wrote: >> On 09/03/11 11:57, Chris Enger wrote: >>> I did look at a Juniper J6350, and the documentation states it can handle 400k routes with 1GB of memory, or 1 million with 2GB. However it doesn?t spell out how that is divvyed up between the two based on a profile setting or some other mechanism. >> It's a software router so the short answer is "it isn't" >> >> With 3GB of RAM both a 4350 and 6350 can easily handle multiple IPv4 >> feeds and an IPv6 feed (3GB just happens to be what I have due to >> upgrading from 1GB by adding a pair of 1GB sticks) >> >> If you need more then ~500Mbit or so then you would want something >> bigger. The MX80 is nice and has some cheap bundles at the moment; it's >> specced for 8M routes (unspecified, but the way Juniper chips typically >> store routes there's less difference in size then the straight 4x) >> >> From others the Cisco ASR1k or Brocade NetIron XMR (2M routes IIRC) are >> the obvious choices. > And I meant Brocade NetIron CES here. From jeroen at mompl.net Wed Mar 9 20:20:12 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 09 Mar 2011 18:20:12 -0800 Subject: dhcp6 solicit Message-ID: <4D78355C.9030300@mompl.net> I was doing some packet scanning on one of my IPv6 enabled servers and I found traffic such as the following frequently (IPs slightly edited): 02:23:02.410360 IP6 fe80::ff78.546 > ff02::2.547: dhcp6 solicit Not having done too much ipv6 packet scanning yet I am curious to know if this is a mis-configured dhcp6 server somewhere? Is this a rather common thing to see in IPv6 traffic? The addresses are not mine, neither do I run a dhcpv6 daemon (no need for it). Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From Valdis.Kletnieks at vt.edu Wed Mar 9 20:44:56 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 09 Mar 2011 21:44:56 -0500 Subject: dhcp6 solicit In-Reply-To: Your message of "Wed, 09 Mar 2011 18:20:12 PST." <4D78355C.9030300@mompl.net> References: <4D78355C.9030300@mompl.net> Message-ID: <8818.1299725096@localhost> On Wed, 09 Mar 2011 18:20:12 PST, Jeroen van Aart said: > I was doing some packet scanning on one of my IPv6 enabled servers and I > found traffic such as the following frequently (IPs slightly edited): > > 02:23:02.410360 IP6 fe80::ff78.546 > ff02::2.547: dhcp6 solicit > The addresses are not mine, neither do I run a dhcpv6 daemon (no need > for it). The addresses *are* yours (sort of, the same way that in IPv4, 127.0.0.1 belongs to you even though it's in a netblock assigned to IANA rather than you). fe80: is a prefix for "link level" addresses (basically "only valid on this subnet"), and is what the machine asking for the dhcp6 uses so it has *an* address it can use (or more correctly, so that the machine that replies can fill in a destination for the reply). Meanwhile, ff02::2 is a reserved address for "all routers on the network segment". You can probably pull the mac address out of that fe80:: address, as it's an EUI-64. For example, on my laptop I have: inet6 addr: fe80::224:d6ff:fe53:c5ba/64 Scope:Link Pull out the 'ff:fe', take out that first 2, and my MAC address is 00:24:d6:53:c5:ba. Hope that helps you find the offending box that is under the impression that dhcp6 *is* needed. ;) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From gbonser at seven.com Wed Mar 9 21:00:57 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Mar 2011 19:00:57 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC14006@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Chris Woodfield [mailto:rekoil at semihuman.com] > Sent: Wednesday, March 09, 2011 6:11 PM > To: Chris Enger > Cc: 'jgoodwin at studio442.com.au'; 'nanog at nanog.org' > Subject: Re: Internet Edge Router replacement - IPv6 route table > sizeconsiderations > > I think this is the point where I get a shovel, a bullwhip and head > over to the horse graveyard that is CAM optimization... > > -C > Well, it really isn't so bad. With Brocade FPGA gear you can change how much CAM is allocated to different functions (but you can't do it on the fly, it takes a reboot). I don't think these are available for the CER series, though. The MLX or MXR can be reconfigured. The thing is that the XMR and MLX are not ASIC-based devices, they are FPGA-based which means the hardware can be re-wired with a code change. Personally, I like to be able to reallocate CAM from features I am not using to features that I am using. And to be fair, Brocade has been improving over the past couple of years. Now if only we could route layer 3 on MCT VLANS ... (MCT is sort of like Arista mLAG but it is layer2 only at this point). From ulf at Alameda.net Wed Mar 9 21:51:47 2011 From: ulf at Alameda.net (Ulf Zimmermann) Date: Wed, 9 Mar 2011 19:51:47 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC14006@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC14006@RWC-EX1.corp.seven.com> Message-ID: <20110310035147.GB96621@evil.alameda.net> On Wed, Mar 09, 2011 at 07:00:57PM -0800, George Bonser wrote: > > > > -----Original Message----- > > From: Chris Woodfield [mailto:rekoil at semihuman.com] > > Sent: Wednesday, March 09, 2011 6:11 PM > > To: Chris Enger > > Cc: 'jgoodwin at studio442.com.au'; 'nanog at nanog.org' > > Subject: Re: Internet Edge Router replacement - IPv6 route table > > sizeconsiderations > > > > I think this is the point where I get a shovel, a bullwhip and head > > over to the horse graveyard that is CAM optimization... > > > > -C > > > > > Well, it really isn't so bad. With Brocade FPGA gear you can change how > much CAM is allocated to different functions (but you can't do it on the > fly, it takes a reboot). I don't think these are available for the CER > series, though. The MLX or MXR can be reconfigured. The thing is that > the XMR and MLX are not ASIC-based devices, they are FPGA-based which > means the hardware can be re-wired with a code change. Personally, I > like to be able to reallocate CAM from features I am not using to > features that I am using. > > And to be fair, Brocade has been improving over the past couple of > years. Now if only we could route layer 3 on MCT VLANS ... > (MCT is sort of like Arista mLAG but it is layer2 only at this point). My experience with Foundry/Brocade which is recent, is only with the FCX devices and I wished I had gone with something else. No SNMP stats for virtual vlan interfaces and when asking Brocade about it, you get told "it is too hard to program". You gotta be kiddin me .... Or how they do vlan configurations. Or how a FCX stack will crash when you do jumbo frames. -- 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 kauer at biplane.com.au Wed Mar 9 22:11:31 2011 From: kauer at biplane.com.au (Karl Auer) Date: Thu, 10 Mar 2011 15:11:31 +1100 Subject: ipv6 question Message-ID: <1299730291.2109.119.camel@karl> On Thu, 2011-03-10 at 11:43 +1100, Mark Andrews wrote: > In message <1299711449.2109.98.camel at karl>, Karl Auer writes: > > On Wed, 2011-03-09 at 09:01 -0600, imNet Administrator wrote: > > > Where are you pinging it from? also, the 2001:db8::/32 prefix is used > > > for "documentation purposes" and might be handled differently by the > > > TCP/IP stack. > > > > Works fine in Linux - I've been using it (in an isolated training room > > setup) for years. > > > > Regards, K. > > It is not a good idea to use the documentation prefix for anything > other than documentation. How hard is it to generate a ULA and use > it? I suppose I took/take the view that it *is*, in a sense, being used for documentation. The network is a training network, isolated from the Internet, and used for demonstration purposes. It's a good way to engrave the doco prefix in the students' minds. It also allows all the slides, exercises and other documentation to use the documentation prefix and yet directly match the demonstration network. ULA prefixes have little internal logic and are hard to remember. Not a problem in production, but just another barrier in a training environment. "2001:db8::/32" is very easy to remember (I guess that's the point) and easy to add easy-to-use subnets into. However, I do appreciate that it's a bit of an edge case. In my training I specifically draw the students' attention to this fact. Thanks, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From gbonser at seven.com Wed Mar 9 22:52:54 2011 From: gbonser at seven.com (George Bonser) Date: Wed, 9 Mar 2011 20:52:54 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <20110310035147.GB96621@evil.alameda.net> References: <5A6D953473350C4B9995546AFE9939EE0BC14006@RWC-EX1.corp.seven.com> <20110310035147.GB96621@evil.alameda.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC1400D@RWC-EX1.corp.seven.com> > No SNMP stats for virtual vlan interfaces and when asking Brocade > about it, you get told "it is too hard to program". You gotta be > kiddin me .... Yeah, that is something that has been bugging me. No stats on ve interfaces. > Or how they do vlan configurations. I have complained about that, too. With Cisco you add vlans to ports, with Brocade you add ports to vlans. Subtle difference. You can't look at the config and very easily see which vlans are on which ports, you have to do something like: show vlan e 1/1/1 and parse through the output. > Or how a FCX stack will crash when you do jumbo frames. I have been running jumbo frames with stacked FCX units, no problems so far. Running 7.2.00 From nanog at feltonline.com Wed Mar 9 23:15:12 2011 From: nanog at feltonline.com (nanog) Date: Wed, 09 Mar 2011 22:15:12 -0700 Subject: Long Distance Dark Fiber Message-ID: <3c53efc09fb96ffb77934bc5dbe1e475@feltonline.com> Good Evening all. I got an odd and somewhat crazy request from our development group for a long haul OC48 connection for testing (they specifically said from their office in Utah to the east coast and back) with minimal jitter. They need to be able to run their own framing Sonet and WDM - don't ask me why, it doesn't make sense to me. It would seem to me that the last requirement would require a dark fiber? So I've got several questions. One, is there any provider that would provide us such a beast for only one month? I realize that the fact this is long haul OC48 would make the cost astronomically high, and then throwing on the one month would make it even more expensive.... Two, is there any good way to simulate such a long distance link? I know such equipment exists for smaller links, but I haven't yet found anything that'll do OC48 fiber. I'm sure the cost would be high for the equipment, however I'm betting it is *much* lower than the long distance link. Three, could we sanely encapsulate their framing into GRE (or some other such technology) and send it over an IP link and get SLAs to minimize the jitter? Offlist responses would be greatly appreciated. From hank at efes.iucc.ac.il Thu Mar 10 01:06:48 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 10 Mar 2011 09:06:48 +0200 Subject: Geolocation Info Correction Needed at Apple, Yahoo, MSN In-Reply-To: <4D77DDF6.6080303@bogus.com> References: Message-ID: <5.1.0.14.2.20110310090310.00c02d08@efes.iucc.ac.il> At 12:07 09/03/2011 -0800, Joel Jaeggli wrote: >I'd be willing to bet that's maxmind's geoip database. > >for some if not all three it corroborates the argentina response... > >correction at maxmind.com That is a blackhole. I have sent emails there on Jan 18, Feb 3, Feb 23 as well as to support at maxmind.com since their incorrect geo data affects Ookla as well - and all emails have gone unanswered. If anyone has some contact within Maxmind tell them to get a clue. -Hank >On 3/9/11 11:32 AM, Schiller, Heather A wrote: > > > > If anyone is listening, would you be so kind as to update geolocation > > info for the following-- they are in Mexico, not Argentina. > > > > inetnum: 186.64.16.176/29 > > status: reallocated > > owner: Infor Global Solutions Mexico SA de CV > > ownerid: MX-IGSM-LACNIC > > responsible: Hector Garcia Bernal > > address: Montes Urales 505 Lomas de Chapultepec, , > > address: - mexico city - > > country: MX > > > > I couldn't find information on how to get geolocation errors corrected > > for Apple, Yahoo or MSN on their websites. It would be nice if folks > > would also update http://nanog.cluepon.net/index.php/GeoIP which > > details the process for several large sites. > > > > Thanks, > > --Heather > > > > ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* > > Heather Schiller > > Network Security - Verizon Business > > 1.800.900.0241 security at verizonbusiness.com > > > > From joelja at bogus.com Thu Mar 10 01:12:49 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 09 Mar 2011 23:12:49 -0800 Subject: Geolocation Info Correction Needed at Apple, Yahoo, MSN In-Reply-To: <5.1.0.14.2.20110310090310.00c02d08@efes.iucc.ac.il> References: <5.1.0.14.2.20110310090310.00c02d08@efes.iucc.ac.il> Message-ID: <4D7879F1.6080606@bogus.com> On 3/9/11 11:06 PM, Hank Nussbacher wrote: > At 12:07 09/03/2011 -0800, Joel Jaeggli wrote: >> I'd be willing to bet that's maxmind's geoip database. >> >> for some if not all three it corroborates the argentina response... >> >> correction at maxmind.com > > That is a blackhole. I have sent emails there on Jan 18, Feb 3, Feb 23 > as well as to support at maxmind.com since their incorrect geo data affects > Ookla as well - and all emails have gone unanswered. If anyone has some > contact within Maxmind tell them to get a clue. I've not only gotten a response from them via that alias, but they adjusted the prefixes in their next rev. mileage may vary of course. > -Hank > > >> On 3/9/11 11:32 AM, Schiller, Heather A wrote: >> > >> > If anyone is listening, would you be so kind as to update geolocation >> > info for the following-- they are in Mexico, not Argentina. >> > >> > inetnum: 186.64.16.176/29 >> > status: reallocated >> > owner: Infor Global Solutions Mexico SA de CV >> > ownerid: MX-IGSM-LACNIC >> > responsible: Hector Garcia Bernal >> > address: Montes Urales 505 Lomas de Chapultepec, , >> > address: - mexico city - >> > country: MX >> > >> > I couldn't find information on how to get geolocation errors corrected >> > for Apple, Yahoo or MSN on their websites. It would be nice if folks >> > would also update http://nanog.cluepon.net/index.php/GeoIP which >> > details the process for several large sites. >> > >> > Thanks, >> > --Heather >> > >> > ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* >> > Heather Schiller >> > Network Security - Verizon Business >> > 1.800.900.0241 security at verizonbusiness.com >> > >> > > From sthaug at nethelp.no Thu Mar 10 01:30:17 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Thu, 10 Mar 2011 08:30:17 +0100 (CET) Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1400D@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC14006@RWC-EX1.corp.seven.com> <20110310035147.GB96621@evil.alameda.net> <5A6D953473350C4B9995546AFE9939EE0BC1400D@RWC-EX1.corp.seven.com> Message-ID: <20110310.083017.74746340.sthaug@nethelp.no> > > Or how they do vlan configurations. > > I have complained about that, too. With Cisco you add vlans to ports, > with Brocade you add ports to vlans. Subtle difference. You can't look > at the config and very easily see which vlans are on which ports, you > have to do something like: Extreme does the same. It has the great advantage that a trunk port doesn't magically allow all VLANs - which is an absolutely horrible default for Cisco in the SP case. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From ulf at Alameda.net Thu Mar 10 02:53:29 2011 From: ulf at Alameda.net (Ulf Zimmermann) Date: Thu, 10 Mar 2011 00:53:29 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC1400D@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0BC14006@RWC-EX1.corp.seven.com> <20110310035147.GB96621@evil.alameda.net> <5A6D953473350C4B9995546AFE9939EE0BC1400D@RWC-EX1.corp.seven.com> Message-ID: <20110310085329.GD96621@evil.alameda.net> On Wed, Mar 09, 2011 at 08:52:54PM -0800, George Bonser wrote: > > No SNMP stats for virtual vlan interfaces and when asking Brocade > > about it, you get told "it is too hard to program". You gotta be > > kiddin me .... > > Yeah, that is something that has been bugging me. No stats on ve > interfaces. > > > Or how they do vlan configurations. > > I have complained about that, too. With Cisco you add vlans to ports, > with Brocade you add ports to vlans. Subtle difference. You can't look > at the config and very easily see which vlans are on which ports, you > have to do something like: > > show vlan e 1/1/1 > > and parse through the output. > > > > Or how a FCX stack will crash when you do jumbo frames. > > I have been running jumbo frames with stacked FCX units, no problems so > far. Running 7.2.00 This is with code 07.2.00aT7f3. Had two units stacked together, rebooted/power cycled at least once and it worked. Next time we had to power cycle due to a bad config apply, second unit came back and as soon it would join the stack, it crashed. Brocade wanted us to remove it from the stack (remotely) and/or disabled jumbo frames. -- 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 ulf at Alameda.net Thu Mar 10 02:54:46 2011 From: ulf at Alameda.net (Ulf Zimmermann) Date: Thu, 10 Mar 2011 00:54:46 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <20110310.083017.74746340.sthaug@nethelp.no> References: <5A6D953473350C4B9995546AFE9939EE0BC14006@RWC-EX1.corp.seven.com> <20110310035147.GB96621@evil.alameda.net> <5A6D953473350C4B9995546AFE9939EE0BC1400D@RWC-EX1.corp.seven.com> <20110310.083017.74746340.sthaug@nethelp.no> Message-ID: <20110310085446.GE96621@evil.alameda.net> On Thu, Mar 10, 2011 at 08:30:17AM +0100, sthaug at nethelp.no wrote: > > > Or how they do vlan configurations. > > > > I have complained about that, too. With Cisco you add vlans to ports, > > with Brocade you add ports to vlans. Subtle difference. You can't look > > at the config and very easily see which vlans are on which ports, you > > have to do something like: > > Extreme does the same. It has the great advantage that a trunk port > doesn't magically allow all VLANs - which is an absolutely horrible > default for Cisco in the SP case. > > Steinar Haug, Nethelp consulting, sthaug at nethelp.no I can agree with no allowing all vlans by default, but Brocades way is just broken imho. -- 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 sh.vahabzadeh at gmail.com Thu Mar 10 03:24:40 2011 From: sh.vahabzadeh at gmail.com (Shahab Vahabzadeh) Date: Thu, 10 Mar 2011 12:54:40 +0330 Subject: Interesting google redirects. In-Reply-To: References: <982D8D05B6407A49AD506E6C3AC8E7D602BE63DE93BB@caralain.haven.nynaeve.net> <4D6FC7E6.5020100@p8x.net> <4D70831D.4050001@viviotech.net> Message-ID: mine is redirecting to google.com.hk too :) On Wed, Mar 9, 2011 at 2:19 PM, Gavin Pearce wrote: > Sure you all know this already: > http://google.com/ncr > > Temp fix for getting the .com version. > > G > > -----Original Message----- > From: Mark Keymer [mailto:mark at viviotech.net] > Sent: 04 March 2011 06:14 > To: Raymond Macharia > Cc: nanog at nanog.org > Subject: Re: Interesting google redirects. > > On this same subject. My techs have been complaining lately about our > new VPS's we are making going to google.vm. Is there anything I can do > on my end to get this corrected? > > Sincerely, > > Mark Keymer > > > Raymond Macharia wrote: > > >Noticed the same thing to the .com.hk > >Raymond Macharia > > > > > >On Thu, Mar 3, 2011 at 8:04 PM, Wayne Lee > wrote: > > > > > > > >>>>also some EU customers are getting redirected to .au domain > >>>> > >>>> > >>Mine got redirected to google.be for a while. > >> > >> > >> > >> > > > > -- Regards, Shahab Vahabzadeh, IP Engineer, *nix Admin and Geek Phone: +1 (405) 5184491 Blog: http://blog.shahabv.com PGP Key Fingerprint: 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90 From jsw at inconcepts.biz Thu Mar 10 07:14:12 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 10 Mar 2011 08:14:12 -0500 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> Message-ID: On Wed, Mar 9, 2011 at 9:11 PM, Chris Woodfield wrote: > I think this is the point where I get a shovel, a bullwhip and head over to the horse graveyard that is CAM optimization... The classic problem with any sort of FIB optimization is that you can't optimize every figure on the spec sheet at once, at least not without telling lies to your customers! You can have more compact structures which require more memory accesses and clock cycles to perform look-ups, or you can have bigger structures which improve look-up speed at the expense of memory footprint. Since the market is pretty much used to everything being advertised as "wire speed" now, in order to continue doing look-ups at wire speed with an ever-increasing number of routes in the FIB and with entries having longer bit masks, you need more silicon -- more parallel look-up capability, faster (or parallel) memory, or "optimizations" which may not maintain wire speed for all use cases (cache, interleaving, etc.) As the guy making purchasing decisions, I really care about one thing: correct information on the spec sheet. You may have noticed that some recent spec sheets from Cisco include little asterisks about the number of routes which will fit on the FIB are based on "prefix length distribution," which means, in effect, that such "optimizations" are in effect and the box should perform at a guaranteed forwarding speed by sacrificing a guaranteed number of possible routes in FIB. Relating to IPv6 forwarding in particular, this produces an interesting problem when deploying the network: the IPv6 NDP table exhaustion issue. Some folks think it's a red herring; I obviously strongly disagree and point to Cisco's knob, which Cisco will gladly tell you only allows you to control the failure mode of your box (not prevent subnets/interfaces from breaking), as evidence. (I am not aware of any other vendors who have even added knobs for this.) If you configure a /64, you are much more likely to have guaranteed forwarding speed to that destination, and guaranteed number of routes in FIB. What you don't have is a guarantee that ARP/NDP will work correctly on the access router. If you choose to configure a /120, you may lose one or both of the first guarantees. The currently-available compromise is to configure a /120 on the access device and summarize to a /64 (or shorter) towards your aggregation/core. I see nothing wrong with this, since I allocate a /64 even if I only configure a /120 within it, and this is one of the driving reasons behind that decision (the other being a possible future solution to NDP table exhaustion, if one becomes practical.) The number of people thinking about the "big picture" of IPv6 forwarding is shockingly small, and the lack of public discussion about these issues continues to concern me. I fear we are headed down a road where the first large IPv6 DDoS attacks will be a major wake-up call for operators and vendors. I don't intend to be one of the guys hurriedly redesigning my access layer as a result, but I'm pretty sure that many networks will be in exactly that situation. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From joe at gonetforward.com Thu Mar 10 12:37:56 2011 From: joe at gonetforward.com (Joe Renwick) Date: Thu, 10 Mar 2011 10:37:56 -0800 Subject: Loading MIB Definitions - Help me get out of SNMP Hell! Message-ID: Hello All, Apologize for my lameness in advance. I have spent some serious time researching this topic and have decided to reach out to the forums as the two of the smartest people I know have hit the same wall in the past. Bottom line is I do not understand how to add (?compile?) MIB(s) into my SNMP management system. I use Cacti running on Ubuntu server and it works great. My only frustrations have been in the area of finding the MIB OID(s) to use for gathering specific data. In many cases with CIsco I manage to find the OID name i.e. 'CISCO-PROCESS-MIB::cpmCPUTotal5min.9' but Cacti needs the numeric value. So I try 'snmpget' and here is what I see: *jozo at crdtools:/var/www/cacti/rra$ snmpget -v 2c -c ptasa2etb 192.168.55.5 CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree* *MIB search path: /home/jozo/.snmp/mibs:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp * *Cannot find module (CISCO-MEMORY-POOL-MIB): At line 0 in (none)* *CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree: Unknown Object Identifier* Did some research and using the following link I loaded the MIB(s)... which basically consisted of a 'wget' of the MIB files into my /home/jozo/.snmp directory. At least I think they are the MIB definition files with a '.my' extension. http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-PROCESS-MIB But I still cannot get the numeric OID values: *jozo at crdtools:~$ snmptranslate -On CISCO-PROCESS-MIB::cpmCPUTotal5min.9* *No log handling enabled - turning on stderr logging* *Unexpected index type: 7 cpmCPUTotalIndex 9* *.1.3.6.1.4.1.9.9.109.1.1.1.1.5.9* Can anyone point me in the right direction. Any links or advice on how to operate SNMP on a Unix type system would be greatly appreciated. Even a response like "RTMF Buddy" would be awesome if a manual was recommended. Thanks to all who read this email. You deserve a beer. Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From gbonser at seven.com Thu Mar 10 12:52:37 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 10 Mar 2011 10:52:37 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> > If you configure a /64, you are much more likely to have guaranteed > forwarding speed to that destination, and guaranteed number of routes > in FIB. What you don't have is a guarantee that ARP/NDP will work > correctly on the access router. If you choose to configure a /120, > you may lose one or both of the first guarantees. The > currently-available compromise is to configure a /120 on the access > device and summarize to a /64 (or shorter) towards your > aggregation/core. I see nothing wrong with this, since I allocate a > /64 even if I only configure a /120 within it, and this is one of the > driving reasons behind that decision (the other being a possible > future solution to NDP table exhaustion, if one becomes practical.) What I have done on point to points and small subnets between routers is to simply make static neighbor entries. That eliminates any neighbor table exhaustion causing the desired neighbors to become unreachable. I also do the same with neighbors at public peering points. Yes, that comes at the cost of having to reconfigure the entry if a MAC address changes, but that doesn't happen often. From ras at e-gerbil.net Thu Mar 10 13:12:26 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 10 Mar 2011 13:12:26 -0600 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> Message-ID: <20110310191226.GP68199@gerbil.cluepon.net> On Thu, Mar 10, 2011 at 10:52:37AM -0800, George Bonser wrote: > > What I have done on point to points and small subnets between routers > is to simply make static neighbor entries. That eliminates any > neighbor table exhaustion causing the desired neighbors to become > unreachable. I also do the same with neighbors at public peering > points. Yes, that comes at the cost of having to reconfigure the > entry if a MAC address changes, but that doesn't happen often. And this is better than just not trying to implement IPv6 stateless auto-configuration on ptp links in the first place how exactly? Don't get taken in by the people waving an RFC around without actually taking the time to do a little critical thinking on their own first, /64s and auto-configuration just don't belong on router ptp links. And btw only a handful of routers are so poorly designed that they depend on not having subnets longer than /64s when doing IPv6 lookups, and there are many other good reasons why you should just not be using those boxes in the first place. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From streiner at cluebyfour.org Thu Mar 10 09:35:47 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 10 Mar 2011 10:35:47 -0500 (EST) Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <20110310191226.GP68199@gerbil.cluepon.net> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <20110310191226.GP68199@gerbil.cluepon.net> Message-ID: On Thu, 10 Mar 2011, Richard A Steenbergen wrote: > On Thu, Mar 10, 2011 at 10:52:37AM -0800, George Bonser wrote: >> >> What I have done on point to points and small subnets between routers >> is to simply make static neighbor entries. That eliminates any >> neighbor table exhaustion causing the desired neighbors to become >> unreachable. I also do the same with neighbors at public peering >> points. Yes, that comes at the cost of having to reconfigure the >> entry if a MAC address changes, but that doesn't happen often. > > And this is better than just not trying to implement IPv6 stateless > auto-configuration on ptp links in the first place how exactly? Don't > get taken in by the people waving an RFC around without actually taking > the time to do a little critical thinking on their own first, /64s and > auto-configuration just don't belong on router ptp links. And btw only a > handful of routers are so poorly designed that they depend on not having > subnets longer than /64s when doing IPv6 lookups, and there are many > other good reasons why you should just not be using those boxes in the > first place. :) +1 Auto-config has its place, and I don't think core infrastructure is one of them. In our addressing plan, I've allocated /64s for each point-to-point link, but will use /127s in practice. That seemed like the best compromise between throwing /64s at everything and being prepared for the off-chance that something absolutely requires a /64. jms From owen at delong.com Thu Mar 10 13:32:05 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Mar 2011 11:32:05 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <20110310191226.GP68199@gerbil.cluepon.net> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <20110310191226.GP68199@gerbil.cluepon.net> Message-ID: <3A648F97-CD06-4D09-B62A-576F3EC28F37@delong.com> On Mar 10, 2011, at 11:12 AM, Richard A Steenbergen wrote: > On Thu, Mar 10, 2011 at 10:52:37AM -0800, George Bonser wrote: >> >> What I have done on point to points and small subnets between routers >> is to simply make static neighbor entries. That eliminates any >> neighbor table exhaustion causing the desired neighbors to become >> unreachable. I also do the same with neighbors at public peering >> points. Yes, that comes at the cost of having to reconfigure the >> entry if a MAC address changes, but that doesn't happen often. > > And this is better than just not trying to implement IPv6 stateless > auto-configuration on ptp links in the first place how exactly? Don't > get taken in by the people waving an RFC around without actually taking > the time to do a little critical thinking on their own first, /64s and > auto-configuration just don't belong on router ptp links. And btw only a > handful of routers are so poorly designed that they depend on not having > subnets longer than /64s when doing IPv6 lookups, and there are many > other good reasons why you should just not be using those boxes in the > first place. :) > I agree that SLAAC doesn't belong on PTP links, but, I fail to see why having /64s on them is problematic if you take proper precautions. Owen From Tim_Bulger at polk.com Thu Mar 10 13:59:14 2011 From: Tim_Bulger at polk.com (Bulger, Tim) Date: Thu, 10 Mar 2011 14:59:14 -0500 Subject: Loading MIB Definitions - Help me get out of SNMP Hell! In-Reply-To: References: Message-ID: <550031AE4E25FE40BCD5D6894BC95DD5031964B8@DCPWMF303.polk.com> I suggest grabbing the whole lot from ftp://ftp.cisco.com/pub/mibs/v2/v2.tar.gz ... I generally extract that to a directory and move files to my MIB directory individually. This has the benefit of preventing Net-SNMP from ripping through megabytes of garbage related to x.25 and the like. Your issue looks like it's missing or not loading a dependency. Try adding a -m ALL to your command line to ensure that it's loading all of the MIBs. FWIW, I attached the list of the MIBs in my working directory, which includes lots of Cisco, Netscreen, Microsoft, APC, Liebert/Emerson, VMware, F5, etc. It compiles without errors and resolves more than 90% of the tree for most of my devices. Good luck, Tim -----Original Message----- From: Joe Renwick [mailto:joe at gonetforward.com] Sent: Thursday, March 10, 2011 1:38 PM To: nanog at nanog.org Subject: Loading MIB Definitions - Help me get out of SNMP Hell! Hello All, Apologize for my lameness in advance. I have spent some serious time researching this topic and have decided to reach out to the forums as the two of the smartest people I know have hit the same wall in the past. Bottom line is I do not understand how to add (?compile?) MIB(s) into my SNMP management system. I use Cacti running on Ubuntu server and it works great. My only frustrations have been in the area of finding the MIB OID(s) to use for gathering specific data. In many cases with CIsco I manage to find the OID name i.e. 'CISCO-PROCESS-MIB::cpmCPUTotal5min.9' but Cacti needs the numeric value. So I try 'snmpget' and here is what I see: *jozo at crdtools:/var/www/cacti/rra$ snmpget -v 2c -c ptasa2etb 192.168.55.5 CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree* *MIB search path: /home/jozo/.snmp/mibs:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/sha re/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp * *Cannot find module (CISCO-MEMORY-POOL-MIB): At line 0 in (none)* *CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree: Unknown Object Identifier* Did some research and using the following link I loaded the MIB(s)... which basically consisted of a 'wget' of the MIB files into my /home/jozo/.snmp directory. At least I think they are the MIB definition files with a '.my' extension. http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibN ame=CISCO-PROCESS-MIB But I still cannot get the numeric OID values: *jozo at crdtools:~$ snmptranslate -On CISCO-PROCESS-MIB::cpmCPUTotal5min.9* *No log handling enabled - turning on stderr logging* *Unexpected index type: 7 cpmCPUTotalIndex 9* *.1.3.6.1.4.1.9.9.109.1.1.1.1.5.9* Can anyone point me in the right direction. Any links or advice on how to operate SNMP on a Unix type system would be greatly appreciated. Even a response like "RTMF Buddy" would be awesome if a manual was recommended. Thanks to all who read this email. You deserve a beer. Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? ***************************************************************** This message has originated from R. L. Polk & Co., 26533 Evergreen Road Suite 900, Southfield, MI 48076. R. L. Polk & Co. sends various types of email communications. If this email message concerns the potential licensing of a Polk product or service, and you do not wish to receive further emails regarding Polk products, forward this email to Do_Not_Send at polk.com with the word "remove" in the subject line. The email and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this email in error, please delete this message and notify the Polk System Administrator at postmaster at polk.com. ***************************************************************** -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: miblist.txt URL: From mwalter at 3z.net Thu Mar 10 14:00:40 2011 From: mwalter at 3z.net (Mike Walter) Date: Thu, 10 Mar 2011 20:00:40 +0000 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <20110310191226.GP68199@gerbil.cluepon.net> Message-ID: Is anyone staying away from certain address ranges in /127s? I have seen where they say not to use the all zeros or end addresses from 1 - 127. Thoughts on this? -Mike -----Original Message----- From: Justin M. Streiner [mailto:streiner at cluebyfour.org] Sent: Thursday, March 10, 2011 10:36 AM To: Richard A Steenbergen Cc: nanog at nanog.org Subject: Re: Internet Edge Router replacement - IPv6 route table sizeconsiderations On Thu, 10 Mar 2011, Richard A Steenbergen wrote: > On Thu, Mar 10, 2011 at 10:52:37AM -0800, George Bonser wrote: >> >> What I have done on point to points and small subnets between routers >> is to simply make static neighbor entries. That eliminates any >> neighbor table exhaustion causing the desired neighbors to become >> unreachable. I also do the same with neighbors at public peering >> points. Yes, that comes at the cost of having to reconfigure the >> entry if a MAC address changes, but that doesn't happen often. > > And this is better than just not trying to implement IPv6 stateless > auto-configuration on ptp links in the first place how exactly? Don't > get taken in by the people waving an RFC around without actually taking > the time to do a little critical thinking on their own first, /64s and > auto-configuration just don't belong on router ptp links. And btw only a > handful of routers are so poorly designed that they depend on not having > subnets longer than /64s when doing IPv6 lookups, and there are many > other good reasons why you should just not be using those boxes in the > first place. :) +1 Auto-config has its place, and I don't think core infrastructure is one of them. In our addressing plan, I've allocated /64s for each point-to-point link, but will use /127s in practice. That seemed like the best compromise between throwing /64s at everything and being prepared for the off-chance that something absolutely requires a /64. jms From joe at gonetforward.com Thu Mar 10 14:40:14 2011 From: joe at gonetforward.com (Joe Renwick) Date: Thu, 10 Mar 2011 12:40:14 -0800 Subject: Loading MIB Definitions - Help me get out of SNMP Hell! In-Reply-To: References: Message-ID: Problem solved. NANOG is awesome! Thanks much to all who assisted. It is actually quite easy to load the MIB definitions to you Ubuntu machine. I just downloaded the complete Cisco MIB tree to make life easier " ftp://ftp.cisco.com/pub/mibs/v2". Downloaded the "v2.tar.gz file". Unpacked the MIB(s) into '$HOME/.snmp/mibs' directory and life is good. Note that when the tarball unpacks it creates a weird directory structure. Just find the .my files and move them to $HOME/.snmp/mibs. Here is success: *jozo at crdtools:~/.snmp$ snmpget -v 1 -c 'ptasa2etb' 192.168.10.2 CISCO-PROCESS-MIB::cpmCPUTotal5min.1* *CISCO-PROCESS-MIB::cpmCPUTotal5min.1 = Gauge32: 0* Now that my servers understand the MIB I can get the numerical OID for Cacti: *jozo at crdtools:~/.snmp$ snmptranslate -On CISCO-PROCESS-MIB::cpmCPUTotal5min.1* *.1.3.6.1.4.1.9.9.109.1.1.1.1.5.1* Hope this helps someone down the road. Cheers, Joe On Thu, Mar 10, 2011 at 10:37 AM, Joe Renwick wrote: > Hello All, > > Apologize for my lameness in advance. I have spent some serious time > researching this topic and have decided to reach out to the forums as the > two of the smartest people I know have hit the same wall in the past. > Bottom line is I do not understand how to add (?compile?) MIB(s) into my > SNMP management system. I use Cacti running on Ubuntu server and it works > great. My only frustrations have been in the area of finding the MIB OID(s) > to use for gathering specific data. In many cases with CIsco I manage to > find the OID name i.e. 'CISCO-PROCESS-MIB::cpmCPUTotal5min.9' but Cacti > needs the numeric value. So I try 'snmpget' and here is what I see: > > *jozo at crdtools:/var/www/cacti/rra$ snmpget -v 2c -c ptasa2etb 192.168.55.5 > CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree* > *MIB search path: > /home/jozo/.snmp/mibs:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp > * > *Cannot find module (CISCO-MEMORY-POOL-MIB): At line 0 in (none)* > *CISCO-MEMORY-POOL-MIB::ciscoMemoryPoolFree: Unknown Object Identifier* > > Did some research and using the following link I loaded the MIB(s)... which > basically consisted of a 'wget' of the MIB files into my /home/jozo/.snmp > directory. At least I think they are the MIB definition files with a '.my' > extension. > > > http://tools.cisco.com/Support/SNMP/do/BrowseMIB.do?local=en&step=2&mibName=CISCO-PROCESS-MIB > > But I still cannot get the numeric OID values: > > *jozo at crdtools:~$ snmptranslate -On CISCO-PROCESS-MIB::cpmCPUTotal5min.9* > *No log handling enabled - turning on stderr logging* > *Unexpected index type: 7 cpmCPUTotalIndex 9* > *.1.3.6.1.4.1.9.9.109.1.1.1.1.5.9* > > Can anyone point me in the right direction. Any links or advice on how to > operate SNMP on a Unix type system would be greatly appreciated. Even a > response like "RTMF Buddy" would be awesome if a manual was recommended. > > Thanks to all who read this email. You deserve a beer. > > Cheers, > > -- > Joe Renwick > IP Network Consultant, CCIE #16465 > GO NETFORWARD! > Direct: 619-800-2055, Emergency Support: 800-719-0504 > Is your network moving you forward? > > > -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From blake at ispn.net Thu Mar 10 15:01:22 2011 From: blake at ispn.net (Blake Hudson) Date: Thu, 10 Mar 2011 15:01:22 -0600 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: References: Message-ID: <4D793C22.7060104@ispn.net> > My concern is trying to find a router (within our budget) that has room for growth in the IPv6 routing space. When compared to the live table sizes that the CIDR report and routeviews show, some can't handle current routing tables, let alone years of growth. BGP tweaks may keep us going but I can't see how 16k or fewer IPv6 routes on a router is going to be viable a few years from now. > > Thank you, > Chris Enger > Does anyone think that the IP6 routes will grow like IP4 routes have? With most organizations being granted IP6 /32's - e.g. something larger than they could ever use - wouldn't you expect the number of routes to be much much fewer than with today's IP4 setup where even small organizations often have multiple routes, and big organizations may have hundreds? When sizing routers, shouldn't we be looking at the number of expected ISPs (AS's) active on the Internet, within the anticipated lifetime of the router? If so, then the question becomes how many is that - 16k seems very shortsighted, 128k maybe overkill (at least, for now). We're currently at 37k AS's (http://www.cidr-report.org/as2.0/). So 64k IP6 routes would probably be the minimum that I would accept on a new single homed router. If I expected to act as a carrier, or participate in equal cost BGP routing on a multi-homed router, I'd need more. As IP6 adoption grows, and networks start to de-aggregate, 128K IP6 routes sound like a better number for the second or third revision of "IP6 ready" gear that would be purchased in 5+ years. --Blake From gbonser at seven.com Thu Mar 10 15:10:33 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 10 Mar 2011 13:10:33 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <20110310191226.GP68199@gerbil.cluepon.net> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <20110310191226.GP68199@gerbil.cluepon.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC14034@RWC-EX1.corp.seven.com> > And this is better than just not trying to implement IPv6 stateless > auto-configuration on ptp links in the first place how exactly? I don't use autoconfiguration. Static configured IPs, static neighbor entries for these types of links. From pekkas at netcore.fi Thu Mar 10 15:28:20 2011 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 10 Mar 2011 23:28:20 +0200 (EET) Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC14034@RWC-EX1.corp.seven.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <20110310191226.GP68199@gerbil.cluepon.net> <5A6D953473350C4B9995546AFE9939EE0BC14034@RWC-EX1.corp.seven.com> Message-ID: On Thu, 10 Mar 2011, George Bonser wrote: >> And this is better than just not trying to implement IPv6 stateless >> auto-configuration on ptp links in the first place how exactly? > > I don't use autoconfiguration. Static configured IPs, static neighbor > entries for these types of links. Man. It must be annoying to change all those static neighbor entries when the interfaces fail, links must be migrated to another line cards or you replace routers. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From gbonser at seven.com Thu Mar 10 15:35:14 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 10 Mar 2011 13:35:14 -0800 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <20110310191226.GP68199@gerbil.cluepon.net> <5A6D953473350C4B9995546AFE9939EE0BC14034@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC14037@RWC-EX1.corp.seven.com> > > Man. It must be annoying to change all those static neighbor entries > when the interfaces fail, links must be migrated to another line cards > or you replace routers. > > -- Yeah, that happens about once every five years or so and in my particular case there aren't a lot of these point to point links, maybe a dozen. So what works for me wouldn't necessarily be a global truth. From owen at delong.com Thu Mar 10 16:58:55 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Mar 2011 14:58:55 -0800 Subject: Internet Edge Router replacement - IPv6 route table size considerations In-Reply-To: <4D793C22.7060104@ispn.net> References: <4D793C22.7060104@ispn.net> Message-ID: <4FA8A1FF-514D-4E41-823B-F532195A5C1E@delong.com> On Mar 10, 2011, at 1:01 PM, Blake Hudson wrote: > >> My concern is trying to find a router (within our budget) that has room for growth in the IPv6 routing space. When compared to the live table sizes that the CIDR report and routeviews show, some can't handle current routing tables, let alone years of growth. BGP tweaks may keep us going but I can't see how 16k or fewer IPv6 routes on a router is going to be viable a few years from now. >> >> Thank you, >> Chris Enger >> > > Does anyone think that the IP6 routes will grow like IP4 routes have? > With most organizations being granted IP6 /32's - e.g. something larger > than they could ever use - wouldn't you expect the number of routes to > be much much fewer than with today's IP4 setup where even small > organizations often have multiple routes, and big organizations may have > hundreds? > Most end user organizations should be receiving a /48 per end site. Most ISPs should probably get something larger than a /32 unless they have fewer than 48,000 customers or so. The number of prefixes per ASN in IPv6 should probably end up around 1.75. The current average in IPv4 is approximately 10. > When sizing routers, shouldn't we be looking at the number of expected > ISPs (AS's) active on the Internet, within the anticipated lifetime of > the router? If so, then the question becomes how many is that - 16k > seems very shortsighted, 128k maybe overkill (at least, for now). We're > currently at 37k AS's (http://www.cidr-report.org/as2.0/). So 64k IP6 > routes would probably be the minimum that I would accept on a new single > homed router. If I expected to act as a carrier, or participate in equal > cost BGP routing on a multi-homed router, I'd need more. > 16k is extraordinarily short-sighted. It will be at least 30,000 just to duplicate the current IPv4 network. 128k is probably reasonable headroom. I wouldn't want to go any smaller, given the likelihood of some multiple slightly greater than 1 prefix per AS. > As IP6 adoption grows, and networks start to de-aggregate, 128K IP6 > routes sound like a better number for the second or third revision of > "IP6 ready" gear that would be purchased in 5+ years. > I would say 128k is more like the minimum for anything I would buy now. Owen From jason at lixfeld.ca Thu Mar 10 17:44:40 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Thu, 10 Mar 2011 18:44:40 -0500 Subject: Any AT&T IP Transit sales folks listening? Message-ID: I'm looking for an AT&T IP Transit sales contact. Email links on the website don't seem to work and I was on hold for 30 minutes with an auto-attendant when I tried to call. I'm looking for transit on a 1Gbps access out of TelX @ 60 Hudson. Thanks in advance. From jsw at inconcepts.biz Thu Mar 10 19:28:11 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 10 Mar 2011 20:28:11 -0500 Subject: Internet Edge Router replacement - IPv6 route table sizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> Message-ID: On Thu, Mar 10, 2011 at 1:52 PM, George Bonser wrote: > What I have done on point to points and small subnets between routers is > to simply make static neighbor entries. ?That eliminates any neighbor > table exhaustion causing the desired neighbors to become unreachable. ?I > also do the same with neighbors at public peering points. ?Yes, that > comes at the cost of having to reconfigure the entry if a MAC address > changes, but that doesn't happen often. I wouldn't bet on the router evicting a maliciously-learned dynamic NDP entry to install a static NDP entry when an interface flaps up, and if it doesn't, I wouldn't bet on that static NDP entry ever being installed until the interface flaps again. Remember, there are several possible attack methods here, one of which is a compromised or badly broken box on a connected LAN. As Richard points out, there is *no* reason to configure /64s on point-to-point links, and there are obvious disadvantages. The "RFC wavers" are downright stupid to suggest otherwise. As for IXP LANs, I predict that one of two things will happen: either one or more major IXPs will be subject to NDP DoS and will decide to shrink their subnet size, allowing others to follow suit; or vendors will make NDP inspection work and be configurable enough to prevent most problems. Again, Cisco has already added a knob to some platforms which allows you to steer the failure mode. Interfaces will fail regardless of what you do; the Cisco knob just lets you decide to break NDP on only the interface(s) subject to attack instead of on the entire box. In any case, I don't judge static NDP entries on IXP LANs to be a practical long-term solution. There are obvious disadvantages to that. If your network is entirely made up of backbone routers with fairly static neighbors, your strategy can certainly work with a bit of extra effort and a vendor box that doesn't do entirely crazy things. If you have customers (those pesky customers!) they may not be so comfortable having to open a ticket and feel like they are troubleshooting a problem you've caused them because you have configured a static NDP entry facing them. If you have hosting customers with servers attached to VLANs, especially in a VPS environment where IP/MAC associations may routinely change ... good luck with those static NDP entries. Obviously, some folks will continue to cite "standards" for something which was developed in 1997 and still isn't really working, or claim their own "fix" works, until they get actual IPv6 customers. Those folks are probably choosing to redesign their access layer in the future, *AFTER* they already have customers. I have been talking to smart people about this problem for nearly ten years, and I have never heard a practical solution that doesn't involve some kind of persistent "sticky NDP" which refuses to make discovery requests to the LAN for addresses which have never been seen from the LAN. I've also never seen a practical idea for preventing malicious hosts on the LAN from filling the table that doesn't involve NDP inspection at the access port, some kind of database (e.g. RADIUS/etc) or additional configuration in the router, or proposals that would simply change the failure mode (e.g. rate-limit knobs.) You'll notice that there have been several discussions about this on NANOG and other mailing lists, most of which include some "RFC wavers," some people saying "the sky is falling," and some guys in-between who think their vendor's box will fail gracefully or that NDP learning not functioning for some or all interfaces is not bad as long as the box doesn't evict busy entries. I suggest all the folks in the middle ask themselves why Cisco added a knob *just to control the failure mode.* This is a real problem, and the current, practical fix is simply to not configure /64. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From gbonser at seven.com Thu Mar 10 21:51:17 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 10 Mar 2011 19:51:17 -0800 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au><5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> > > As Richard points out, there is *no* reason to configure /64s on > point-to-point links, and there are obvious disadvantages. The "RFC > wavers" are downright stupid to suggest otherwise. > > As for IXP LANs, I predict that one of two things will happen: either > one or more major IXPs will be subject to NDP DoS and will decide to > shrink their subnet size, allowing others to follow suit; or vendors > will make NDP inspection work and be configurable enough to prevent > most problems. Again, Cisco has already added a knob to some > platforms which allows you to steer the failure mode. Interfaces will > fail regardless of what you do; the Cisco knob just lets you decide to > break NDP on only the interface(s) subject to attack instead of on the > entire box. In any case, I don't judge static NDP entries on IXP LANs > to be a practical long-term solution. There are obvious disadvantages > to that. And I say making them /127s may not really make any difference. Say you make all of those /127s, at some point you *are* going to have a network someplace that is a /64 that has hosts on it and that one is just as subject to such an attack. If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. The end result is the same. You have managed to re-arrange the deck chairs. Have another squeeze at that water balloon. If you are a service provider where practically all of your links are point to points, sure. > If your network is entirely made up of backbone routers with fairly > static neighbors, your strategy can certainly work with a bit of extra > effort and a vendor box that doesn't do entirely crazy things. Where that is done is primarily on a backbone section of the network and where I connect to public peering points. I add static entries for the specific peers I communicate with. Yes, it does take a little maintenance when a peer changes out some gear or moves to a different port on their gear but that doesn't happen all that often and is a compromise I am willing to make in exchange for some added protection. It also protects against someone who I am not peering with on that same switch fat-fingering an IP address during some maintenance and accidently configuring their gear with the same IP as someone I *am* peering with. I won't even see it if I have a static neighbor (the same thing is also done with v4 on public peering switches with static ARP entries, too). > If you have customers (those pesky customers!) they may not be so > comfortable having to open a ticket and feel like they are > troubleshooting a problem you've caused them because you have > configured a static NDP entry facing them. Right, if I had dozens of point-to-points with gear that is constantly changing at the other end, yeah. I agree. I might then consider that approach. But in this case I can only speak about my own stuff and what is the best solution for one specific application might not be the best solution for someone else. I am not trying to say that this solution is best for everyone, I am simply pointing out a solution that others might find useful depending on their application. > I have been talking to smart people about this problem for nearly ten > years, and I have never heard a practical solution that doesn't > involve some kind of persistent "sticky NDP" which refuses to make > discovery requests to the LAN for addresses which have never been seen > from the LAN. I've also never seen a practical idea for preventing > malicious hosts on the LAN from filling the table that doesn't involve > NDP inspection at the access port, some kind of database (e.g. > RADIUS/etc) or additional configuration in the router, or proposals > that would simply change the failure mode (e.g. rate-limit knobs.) Yeah, it's a tough nut to crack. I do agree that 64-bit host addressing is just too big. The reason is that it even allows you to configure more IPs on a single subnet legitimately than the network gear can handle. The notion of "we are going to give you a subnet with 8 bazillion possible addresses, but don't try to use more than half a million of them or you will melt your network gear" seems quite idiotic, actually. So you have a huge address space that you actually can't use much of (relative to the size of the space) and it creates a stability risk. We didn't need much more host addressing, we needed more subnet addressing. I would have settled for 16 bits of host addressing and 112 bits of subnet addressing and I suppose nothing prevents me from doing that except none of the standard IPv6 automatic stuff would work anymore. > You'll notice that there have been several discussions about this on > NANOG and other mailing lists, most of which include some "RFC > wavers," some people saying "the sky is falling," and some guys > in-between who think their vendor's box will fail gracefully or that > NDP learning not functioning for some or all interfaces is not bad as > long as the box doesn't evict busy entries. I suggest all the folks > in the middle ask themselves why Cisco added a knob *just to control > the failure mode.* This is a real problem, and the current, practical > fix is simply to not configure /64. And again, are you talking about all the way down to the host subnet level? I suppose I could configure server farms in /112 or even /96 (/96 has some appeal for other reasons mostly having to do with multicast) but then I would wonder how many bugs that would flush out of OS v6 stacks. Something will have to evolve to handle this problem because I agree with you, it is going to be a major issue at some point. It might just be as simple as a host doing what amounts to a gratuitous announcement when an IP is assigned to an interface (and some kind of withdrawal announcement when the address is removed). If a packet arrived from an interface off the host's subnet for an IP address that is not in the neighbor table at all (even stale ones), then maybe the router simply drops the packet. Leave it up to the hosts themselves to keep their information current on the network even when they aren't passing traffic. That doesn't protect against rogue hosts but there might be ways around that, too, or at least limiting the damage a rogue host can cause. So any packet arriving on a router for a local subnet, if that address isn't already in the neighbor table, drop it on the floor or return an "unreachable" or whatever. Something will have to be done at some point ... soon. From rdobbins at arbor.net Thu Mar 10 22:00:46 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 11 Mar 2011 04:00:46 +0000 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au><5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> Message-ID: On Mar 11, 2011, at 10:51 AM, George Bonser wrote: > If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. Of course, it does - you may have many content farms/instances, and taking down point-to-point links can DoS your entire set of farms/instances, whereas an attack against a given endpoint access network doesn't necessarily mean that your other properties/networks/services are being attacked, as well. Limiting this vector to endpoint access networks also makes mitigation mechanisms far more practicable. There is no good reason to use /64s on point-to-point links. It is wasteful (please, no more about the supposed infinitude of IPv6 addresses; some of us reject this as being shortsighted and insufficiently visionary concerning eventual one-time-uses of IPv6 addresses at nanoscale) and turns your routers into sinkholes. It is a Very Bad Idea. ;> ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From gbonser at seven.com Thu Mar 10 22:34:05 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 10 Mar 2011 20:34:05 -0800 Subject: Internet Edge Router replacement - IPv6 routetablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au><5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC14055@RWC-EX1.corp.seven.com> = > Of course, it does - you may have many content farms/instances, and > taking down point-to-point links can DoS your entire set of > farms/instances, whereas an attack against a given endpoint access > network doesn't necessarily mean that your other > properties/networks/services are being attacked, as well. And I say taking down 10 such farms is no bigger problem than taking down 10 /64 backbone links. Same challenge. A /64 is a /64, seen one you've seen them all. > There is no good reason to use /64s on point-to-point links. It is > wasteful (please, no more about the supposed infinitude of IPv6 > addresses; some of us reject this as being shortsighted and > insufficiently visionary concerning eventual one-time-uses of IPv6 > addresses at nanoscale) and turns your routers into sinkholes. It is a > Very Bad Idea. I wouldn't say it is wasteful so much as it is unnecessary but the difference is that everything is pretty much known to work as expected with a /64 subnet. Anything broken with a /64 is really broken and the vendor would be expected to get right on it. If something breaks while using a /127, the doctor might tell you to stop sticking the spoon in your eye. From rdobbins at arbor.net Thu Mar 10 23:55:51 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 11 Mar 2011 05:55:51 +0000 Subject: Internet Edge Router replacement - IPv6 routetablesizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC14055@RWC-EX1.corp.seven.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au><5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14055@RWC-EX1.corp.seven.com> Message-ID: <2F173ED6-ECA0-4B0E-816F-D4A3ADEB7EF2@arbor.net> On Mar 11, 2011, at 11:34 AM, George Bonser wrote: > And I say taking down 10 such farms is no bigger problem than taking down 10 /64 backbone links. Yes, but the difference is in routine attacker behavior. And of course, iACLs should be protecting p2p links and loopbacks, irrespective of CIDR length, anyways. > If something breaks while using a /127, the doctor might tell you to stop sticking the spoon in your eye. If vendors are somehow optimizing for or restricting functionality to certain CIDR lengths, they should stop this immediately. Features and functionality should work the same, irrespective of CIDR length. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From yoshida at nttv6.jp Fri Mar 11 00:19:42 2011 From: yoshida at nttv6.jp (Tomoya Yoshida) Date: Fri, 11 Mar 2011 15:19:42 +0900 Subject: so big earthquake in JP Message-ID: <20110311145954.2707.9C4C12A4@nttv6.jp> Japan had so big terrible earthquake -- Tomoya Yoshida From kawamucho at mesh.ad.jp Fri Mar 11 00:23:19 2011 From: kawamucho at mesh.ad.jp (Seiichi Kawamura) Date: Fri, 11 Mar 2011 15:23:19 +0900 Subject: [apops] so big earthquake in JP In-Reply-To: <20110311145954.2707.9C4C12A4@nttv6.jp> References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: <4D79BFD7.4050902@mesh.ad.jp> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (2011/03/11 15:19), Tomoya Yoshida wrote: > Japan had so big terrible earthquake Still shaking here in Tokyo. We're seeing major traffic loss. Seiichi -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iEYEARECAAYFAk15v9cACgkQcrhTYfxyMkIQbgCfSjhufgIIPZRhdzYwFXYdpFke KwsAn3+FjH+hTU0zVp+u/Pp/EqeP1eD0 =fCS5 -----END PGP SIGNATURE----- From fergdawgster at gmail.com Fri Mar 11 00:25:27 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Thu, 10 Mar 2011 22:25:27 -0800 Subject: so big earthquake in JP In-Reply-To: <20110311145954.2707.9C4C12A4@nttv6.jp> References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: 7.9 magnitude: http://www.google.com/hostednews/canadianpress/article/ALeqM5iOJwLEwcIwB93yjCubUJpuu4UZKA?docId=6212195 I received word a few minutes ago from a colleague in out Tokyo (Shinjiku) office -- they could see the smoke of building fires in the distance. - ferg On Thu, Mar 10, 2011 at 10:19 PM, Tomoya Yoshida wrote: > Japan had so big terrible earthquake > > -- > Tomoya Yoshida > > > -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From joseph.prasad at gmail.com Fri Mar 11 00:25:37 2011 From: joseph.prasad at gmail.com (Joseph Prasad) Date: Thu, 10 Mar 2011 22:25:37 -0800 Subject: [apops] so big earthquake in JP In-Reply-To: <4D79BFD7.4050902@mesh.ad.jp> References: <20110311145954.2707.9C4C12A4@nttv6.jp> <4D79BFD7.4050902@mesh.ad.jp> Message-ID: here is the Live Video feed. a Tsunami has hit also. http://www.livestation.com/channels/3-al-jazeera-english-english On Thu, Mar 10, 2011 at 10:23 PM, Seiichi Kawamura wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (2011/03/11 15:19), Tomoya Yoshida wrote: > > Japan had so big terrible earthquake > > Still shaking here in Tokyo. > We're seeing major traffic loss. > > Seiichi > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > > iEYEARECAAYFAk15v9cACgkQcrhTYfxyMkIQbgCfSjhufgIIPZRhdzYwFXYdpFke > KwsAn3+FjH+hTU0zVp+u/Pp/EqeP1eD0 > =fCS5 > -----END PGP SIGNATURE----- > > -- *--------------------------------* *The only power people exert over us, is the power we allow them to exert.* *http://obamacrimes.com/* *--------------------------------* * * From swmike at swm.pp.se Fri Mar 11 00:32:05 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 11 Mar 2011 07:32:05 +0100 (CET) Subject: [apops] so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> <4D79BFD7.4050902@mesh.ad.jp> Message-ID: On Thu, 10 Mar 2011, Joseph Prasad wrote: > here is the Live Video feed. > a Tsunami has hit also. > > http://www.livestation.com/channels/3-al-jazeera-english-english USGS is saying 8.8 magnitude now: http://earthquake.usgs.gov/earthquakes/recenteqsww/Quakes/usc0001xgp.php -- Mikael Abrahamsson email: swmike at swm.pp.se From randy at psg.com Fri Mar 11 00:37:02 2011 From: randy at psg.com (Randy Bush) Date: Fri, 11 Mar 2011 15:37:02 +0900 Subject: [apops] so big earthquake in JP In-Reply-To: <20110311145954.2707.9C4C12A4@nttv6.jp> References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: > Japan had so big terrible earthquake still shaking in jimbocho From gbonser at seven.com Fri Mar 11 00:39:31 2011 From: gbonser at seven.com (George Bonser) Date: Thu, 10 Mar 2011 22:39:31 -0800 Subject: [apops] so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> Upgraded to M8.8 24km deep. This is a big one. > -----Original Message----- > From: Randy Bush [mailto:randy at psg.com] > Sent: Thursday, March 10, 2011 10:37 PM > To: Tomoya Yoshida > Cc: pacnog at pacnog.org; nanog at nanog.org; routing-wg at ripe.net; > apops at apops.net; afnog at afnog.org; sanog at sanog.org > Subject: Re: [apops] so big earthquake in JP > > > Japan had so big terrible earthquake > > still shaking in jimbocho From dorian at blackrose.org Fri Mar 11 00:41:23 2011 From: dorian at blackrose.org (Dorian Kim) Date: Fri, 11 Mar 2011 01:41:23 -0500 Subject: [apops] so big earthquake in JP In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> References: <20110311145954.2707.9C4C12A4@nttv6.jp> <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> Message-ID: <20110311064123.GB54705@blackrose.org> On Thu, Mar 10, 2011 at 10:39:31PM -0800, George Bonser wrote: > Upgraded to M8.8 24km deep. This is a big one. M8.8 at 05:46:23 UTC and M6.4 at 06:06:11 UTC so far according to USGS. -dorian From randy at psg.com Fri Mar 11 00:43:05 2011 From: randy at psg.com (Randy Bush) Date: Fri, 11 Mar 2011 15:43:05 +0900 Subject: [apops] so big earthquake in JP In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> References: <20110311145954.2707.9C4C12A4@nttv6.jp> <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> Message-ID: manichi daily still says 7.7. but english language news is not very current. maz-san reports at least one fiber break randy, cleaning up a lot of spilled coffee From never.quitter at gmail.com Fri Mar 11 01:00:30 2011 From: never.quitter at gmail.com (Yuki Nakae) Date: Fri, 11 Mar 2011 16:00:30 +0900 Subject: [apops] so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> Message-ID: Kayabacho has also shaken heavily twice. The epicenter is off shore Miyagi pref. 2011/3/11 Randy Bush > manichi daily still says 7.7. but english language news is not very > current. > > maz-san reports at least one fiber break > > randy, cleaning up a lot of spilled coffee > > From owen at delong.com Fri Mar 11 01:02:58 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Mar 2011 23:02:58 -0800 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au><5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> Message-ID: <49E4FB94-3D1B-476B-89C4-78155EDF2749@delong.com> On Mar 10, 2011, at 8:00 PM, Dobbins, Roland wrote: > > On Mar 11, 2011, at 10:51 AM, George Bonser wrote: > >> If you are a content provider, it doesn't make any difference if they take down the links between your routers or if they take down the link that your content farm is on. > > > Of course, it does - you may have many content farms/instances, and taking down point-to-point links can DoS your entire set of farms/instances, whereas an attack against a given endpoint access network doesn't necessarily mean that your other properties/networks/services are being attacked, as well. > How is an attack against all your content farms in any way MORE difficult than an attack against enough point to point links to take everything out? If you've designed things properly, it takes more PtoP links to DOS the complete set than it does End point networks. > Limiting this vector to endpoint access networks also makes mitigation mechanisms far more practicable. > It's actually pretty easy to eliminate it 100% from the PtoP links even if they are /64s by simply not allowing traffic to the PtoP addresses other from selected sources (NOC/Admin Network, required peers, etc.). If you want to be truly anal about it, you can also block packets to non-existent addresses on the PtoP links. > There is no good reason to use /64s on point-to-point links. It is wasteful (please, no more about the supposed infinitude of IPv6 addresses; some of us reject this as being shortsighted and insufficiently visionary concerning eventual one-time-uses of IPv6 addresses at nanoscale) and turns your routers into sinkholes. It is a Very Bad Idea. > This isn't a one-time-use of IPv6 addresses and the one-time-uses of IPv6 addresses are what should be considered unscalable and absurdly wasteful. There's a lot to be said for the principle of least surprise and uniform /64s actually help with that quite a bit. Frankly, unless you have parallel links, there isn't a definite need to even number PtoP links for IPv6. Every thing you need to do with an interface specific address on a PtoP link can be done with link local. Owen From joseph.prasad at gmail.com Fri Mar 11 01:05:23 2011 From: joseph.prasad at gmail.com (Joseph Prasad) Date: Thu, 10 Mar 2011 23:05:23 -0800 Subject: [apops] so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> Message-ID: BBC Feed; http://www.veetle.com/index.php/channel/view#4d713653b2e98 On Thu, Mar 10, 2011 at 11:00 PM, Yuki Nakae wrote: > Kayabacho has also shaken heavily twice. > > The epicenter is off shore Miyagi pref. > > 2011/3/11 Randy Bush > > > manichi daily still says 7.7. but english language news is not very > > current. > > > > maz-san reports at least one fiber break > > > > randy, cleaning up a lot of spilled coffee > > > > > -- *--------------------------------* *The only power people exert over us, is the power we allow them to exert.* *http://obamacrimes.com/* *--------------------------------* * * From randy at psg.com Fri Mar 11 01:06:43 2011 From: randy at psg.com (Randy Bush) Date: Fri, 11 Mar 2011 16:06:43 +0900 Subject: [apops] so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> Message-ID: > http://www.veetle.com/index.php/channel/view#4d713653b2e98 bad report. murdoch style exaggeration. From sparctacus at gmail.com Fri Mar 11 01:08:15 2011 From: sparctacus at gmail.com (Bryan Irvine) Date: Thu, 10 Mar 2011 23:08:15 -0800 Subject: so big earthquake in JP In-Reply-To: <20110311145954.2707.9C4C12A4@nttv6.jp> References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: On Thu, Mar 10, 2011 at 10:19 PM, Tomoya Yoshida wrote: > Japan had so big terrible earthquake How big? I see reports of Tokyo, was Kyoto affected? From brokenflea at gmail.com Fri Mar 11 01:13:42 2011 From: brokenflea at gmail.com (Khurram Khan) Date: Fri, 11 Mar 2011 00:13:42 -0700 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: bbc reports 8.8 magnitude with a tsunami. http://www.bbc.co.uk/news/world-asia-pacific-12709598 On Fri, Mar 11, 2011 at 12:08 AM, Bryan Irvine wrote: > On Thu, Mar 10, 2011 at 10:19 PM, Tomoya Yoshida wrote: >> Japan had so big terrible earthquake > > How big? ?I see reports of Tokyo, was Kyoto affected? > > From d3e3e3 at gmail.com Fri Mar 11 01:18:03 2011 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Fri, 11 Mar 2011 02:18:03 -0500 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: USGS now says magnitude 8.9. And there seem to have been three aftershocks so far, two in the 7.x range... Thanks, Donald On Fri, Mar 11, 2011 at 2:13 AM, Khurram Khan wrote: > bbc reports 8.8 magnitude with a tsunami. > > http://www.bbc.co.uk/news/world-asia-pacific-12709598 > > > > On Fri, Mar 11, 2011 at 12:08 AM, Bryan Irvine wrote: >> On Thu, Mar 10, 2011 at 10:19 PM, Tomoya Yoshida wrote: >>> Japan had so big terrible earthquake >> >> How big? ?I see reports of Tokyo, was Kyoto affected? >> >> > > From dorian at blackrose.org Fri Mar 11 01:18:32 2011 From: dorian at blackrose.org (Dorian Kim) Date: Fri, 11 Mar 2011 02:18:32 -0500 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: <20110311071832.GD54705@blackrose.org> I think it's probably more useful for people to follow this instead of media reports: http://earthquake.usgs.gov/earthquakes/recenteqsww/Quakes/quakes_big.php -dorian From rdobbins at arbor.net Fri Mar 11 01:22:00 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 11 Mar 2011 07:22:00 +0000 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <49E4FB94-3D1B-476B-89C4-78155EDF2749@delong.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au><5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <49E4FB94-3D1B-476B-89C4-78155EDF2749@delong.com> Message-ID: <7EAB7486-5CE6-4D3A-8A78-0CB8B48879D9@arbor.net> On Mar 11, 2011, at 2:02 PM, Owen DeLong wrote: > If you want to be truly anal about it, you can also block packets to non-existent > addresses on the PtoP links. Sure, I advocate iACLs to block traffic to p2p links and loopbacks. Still, it's best not to turn routers into sinkholes in the first place. > This isn't a one-time-use of IPv6 addresses and the one-time-uses of IPv6 addresses are what should be considered unscalable and absurdly wasteful. I don't know that I agree with this - I can see lots of value in one-time-use addresses/blocks, and have a metaphysical degree of certitude that they'll be used that way in some cases, irrespective of what I think. > There's a lot to be said for the principle of least surprise and uniform /64s actually help with that quite a bit. Enforcing uniformity of wasteful and potentially harmful addressing practices in the name of consistency isn't necessarily a win, IMHO. ;> > Frankly, unless you have parallel links, there isn't a definite need to even number PtoP links for IPv6. > Every thing you need to do with an interface specific address on a PtoP link can be done with link local. Which is why IP unnumbered caught on so well in IPv4-land, heh? ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From yoshida at nttv6.jp Fri Mar 11 01:26:33 2011 From: yoshida at nttv6.jp (Tomoya Yoshida) Date: Fri, 11 Mar 2011 16:26:33 +0900 Subject: so big earthquake in JP In-Reply-To: References: Message-ID: <20110311162500.271D.9C4C12A4@nttv6.jp> According to the Japan Meteorological Agency, it's 8.4 -05:46 UTC M8.4 in Miyagi Pref. not M8.8 -06:15 UTC M7.4 in Ibaragi Pref. tomoya On Fri, 11 Mar 2011 00:13:42 -0700 Khurram Khan wrote: |bbc reports 8.8 magnitude with a tsunami. | |http://www.bbc.co.uk/news/world-asia-pacific-12709598 | | | |On Fri, Mar 11, 2011 at 12:08 AM, Bryan Irvine wrote: |> On Thu, Mar 10, 2011 at 10:19 PM, Tomoya Yoshida wrote: |>> Japan had so big terrible earthquake |> |> How big? ?I see reports of Tokyo, was Kyoto affected? |> |> -- Tomoya Yoshida From owen at delong.com Fri Mar 11 01:25:12 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Mar 2011 23:25:12 -0800 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: Upgraded to 8.8 a little while ago. Owen On Mar 10, 2011, at 10:25 PM, Paul Ferguson wrote: > 7.9 magnitude: > > http://www.google.com/hostednews/canadianpress/article/ALeqM5iOJwLEwcIwB93yjCubUJpuu4UZKA?docId=6212195 > > I received word a few minutes ago from a colleague in out Tokyo > (Shinjiku) office -- they could see the smoke of building fires in the > distance. > > - ferg > > > On Thu, Mar 10, 2011 at 10:19 PM, Tomoya Yoshida wrote: > >> Japan had so big terrible earthquake >> >> -- >> Tomoya Yoshida >> >> >> > > > > -- > "Fergie", a.k.a. Paul Ferguson > Engineering Architecture for the Internet > fergdawgster(at)gmail.com > ferg's tech blog: http://fergdawg.blogspot.com/ From yoshida at nttv6.jp Fri Mar 11 01:29:20 2011 From: yoshida at nttv6.jp (Tomoya Yoshida) Date: Fri, 11 Mar 2011 16:29:20 +0900 Subject: [routing-wg] Re: [apops] so big earthquake in JP In-Reply-To: <20110311064123.GB54705@blackrose.org> References: <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> <20110311064123.GB54705@blackrose.org> Message-ID: <20110311155032.2714.9C4C12A4@nttv6.jp> According to the Japan Meteorological Agency -05:46 UTC M7.9 in Miyagi Pref. not M8.8 -06:15 UTC M7.4 in Ibaragi Pref. still aftershocks often... We see 20% - 30% traffic change in JPNAP Tokyo I http://www.jpnap.net/english/jpnap-tokyo-i/traffic.html JPIX also http://www.jpix.ad.jp/en/technical/traffic.html I think these include people stopping PC and watch TV # major reason like World Cup? In Osaka area, small traffic change observed in JPNAP Osaka. http://www.jpnap.net/english/jpnap-osaka/traffic.html tomoya On Fri, 11 Mar 2011 01:41:23 -0500 Dorian Kim wrote: |On Thu, Mar 10, 2011 at 10:39:31PM -0800, George Bonser wrote: |> Upgraded to M8.8 24km deep. This is a big one. | |M8.8 at 05:46:23 UTC and M6.4 at 06:06:11 UTC so far according to USGS. | |-dorian -- Tomoya Yoshida From jeroen at mompl.net Fri Mar 11 01:33:00 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 10 Mar 2011 23:33:00 -0800 Subject: [apops] so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> Message-ID: <4D79D02C.4060009@mompl.net> Randy Bush wrote: > manichi daily still says 7.7. but english language news is not very > current. > > maz-san reports at least one fiber break > > randy, cleaning up a lot of spilled coffee > It started a few days earlier, I was keeping an eye on it: http://earthquake.usgs.gov/earthquakes/recenteqsww/Quakes/usb0001r57.php For a complete list so far: http://earthquake.usgs.gov/earthquakes/recenteqsww/Maps/10/145_40_eqs.php Did you feel it? http://earthquake.usgs.gov/earthquakes/dyfi/events/us/c0001xgp/us/index.html -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From randy at psg.com Fri Mar 11 01:36:51 2011 From: randy at psg.com (Randy Bush) Date: Fri, 11 Mar 2011 16:36:51 +0900 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: > USGS now says magnitude 8.9. And there seem to have been three > aftershocks so far, two in the 7.x range... shaking pretty continuous still From jeroen at mompl.net Fri Mar 11 01:37:14 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Thu, 10 Mar 2011 23:37:14 -0800 Subject: [apops] so big earthquake in JP In-Reply-To: <4D79D02C.4060009@mompl.net> References: <20110311145954.2707.9C4C12A4@nttv6.jp> <5A6D953473350C4B9995546AFE9939EE0BC14059@RWC-EX1.corp.seven.com> <4D79D02C.4060009@mompl.net> Message-ID: <4D79D12A.70705@mompl.net> Jeroen van Aart wrote: > It started a few days earlier, I was keeping an eye on it: > http://earthquake.usgs.gov/earthquakes/recenteqsww/Quakes/usb0001r57.php > > For a complete list so far: > http://earthquake.usgs.gov/earthquakes/recenteqsww/Maps/10/145_40_eqs.php > > Did you feel it? > http://earthquake.usgs.gov/earthquakes/dyfi/events/us/c0001xgp/us/index.html > > This shows tsunami warnings: http://www.weather.gov/ptwc/ -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From randy at psg.com Fri Mar 11 01:37:23 2011 From: randy at psg.com (Randy Bush) Date: Fri, 11 Mar 2011 16:37:23 +0900 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: > How big? I see reports of Tokyo, was Kyoto affected? it's up north at sendia which is taking the brunt From owen at delong.com Fri Mar 11 01:33:51 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Mar 2011 23:33:51 -0800 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <7EAB7486-5CE6-4D3A-8A78-0CB8B48879D9@arbor.net> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au><5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <49E4FB94-3D1B-476B-89C4-78155EDF2749@delong.com> <7EAB7486-5CE6-4D3A-8A78-0CB8B48879D9@arbor.net> Message-ID: <42AD349D-432A-42C1-8EEC-4573203766C4@delong.com> On Mar 10, 2011, at 11:22 PM, Dobbins, Roland wrote: > > On Mar 11, 2011, at 2:02 PM, Owen DeLong wrote: > >> If you want to be truly anal about it, you can also block packets to non-existent >> addresses on the PtoP links. > > Sure, I advocate iACLs to block traffic to p2p links and loopbacks. Still, it's best not to turn routers into sinkholes in the first place. > >> This isn't a one-time-use of IPv6 addresses and the one-time-uses of IPv6 addresses are what should be considered unscalable and absurdly wasteful. > > I don't know that I agree with this - I can see lots of value in one-time-use addresses/blocks, and have a metaphysical degree of certitude that they'll be used that way in some cases, irrespective of what I think. > If so, opefully from a tiny and limited range. fc::/7 sounds good to me. It has few other useful purposes in life. >> There's a lot to be said for the principle of least surprise and uniform /64s actually help with that quite a bit. > > Enforcing uniformity of wasteful and potentially harmful addressing practices in the name of consistency isn't necessarily a win, IMHO. > We can agree to disagree. I don't think it's so wasteful and it's what the bits were put there to do. Perverting them to other uses and then complaining that the legitimate uses are getting in the way, OTOH, well... > ;> > >> Frankly, unless you have parallel links, there isn't a definite need to even number PtoP links for IPv6. >> Every thing you need to do with an interface specific address on a PtoP link can be done with link local. > > Which is why IP unnumbered caught on so well in IPv4-land, heh? > There's a HUGE difference between IP unnumbered and link-local. Frankly, absent parallel links, there was a lot to be said for IP unnumbered and I think that if people had better understood the implications of where and when it was a good vs. bad idea and tied it properly to loopbacks instead of $RANDOM_INTERFACE, it might have caught on better. Owen From cdl at asgaard.org Fri Mar 11 02:02:34 2011 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Fri, 11 Mar 2011 00:02:34 -0800 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> Message-ID: <6991C2BD-4175-4409-8DB1-71FFDE58059B@asgaard.org> Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three dart bouys have detected > 2 ft wave fronts. Warnings up for entire pacific basin except for Alaska/canada/us west coast. Chris -- Pardon the typos - sent from a silly keyboard On 10/03/2011, at 23:13, Khurram Khan wrote: > bbc reports 8.8 magnitude with a tsunami. > > http://www.bbc.co.uk/news/world-asia-pacific-12709598 > > > > On Fri, Mar 11, 2011 at 12:08 AM, Bryan Irvine wrote: >> On Thu, Mar 10, 2011 at 10:19 PM, Tomoya Yoshida wrote: >>> Japan had so big terrible earthquake >> >> How big? I see reports of Tokyo, was Kyoto affected? >> >> > > From tvhawaii at shaka.com Fri Mar 11 02:40:26 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Thu, 10 Mar 2011 22:40:26 -1000 Subject: so big earthquake in JP References: <20110311145954.2707.9C4C12A4@nttv6.jp> <6991C2BD-4175-4409-8DB1-71FFDE58059B@asgaard.org> Message-ID: Christopher LILJENSTOLPE wrote: > Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three dart bouys have detected > 2 ft wave fronts. > Warnings > up for entire pacific basin except for Alaska/canada/us west coast. > > Chris Tsunami sirens just went off on Maui. From rdobbins at arbor.net Fri Mar 11 02:43:12 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 11 Mar 2011 08:43:12 +0000 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <42AD349D-432A-42C1-8EEC-4573203766C4@delong.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com><4D76D2F6.5030301@studio442.com.au><4D76D347.2030105@studio442.com.au><5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <49E4FB94-3D1B-476B-89C4-78155EDF2749@delong.com> <7EAB7486-5CE6-4D3A-8A78-0CB8B48879D9@arbor.net> <42AD349D-432A-42C1-8EEC-4573203766C4@delong.com> Message-ID: <58F8D659-8CE0-45B3-83A4-72B60F0EE30E@arbor.net> On Mar 11, 2011, at 2:33 PM, Owen DeLong wrote: > There's a HUGE difference between IP unnumbered and link-local. In all honesty, at the macro level, I don't see it; if you wouldn't mind elaborating on this, I would certainly find it useful. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From jeroen at mompl.net Fri Mar 11 02:50:41 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 11 Mar 2011 00:50:41 -0800 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> <6991C2BD-4175-4409-8DB1-71FFDE58059B@asgaard.org> Message-ID: <4D79E261.8050404@mompl.net> Michael Painter wrote: > Christopher LILJENSTOLPE wrote: >> Pacific tsunami warning centre has confirmed a deep ocean tsunami. >> Three dart bouys have detected > 2 ft wave fronts. Warnings >> up for entire pacific basin except for Alaska/canada/us west coast. >> >> Chris > > Tsunami sirens just went off on Maui. You may get information by going to forecast.weather.gov and searching for a location. i.e.: http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&site=MFR&textField1=43.3667&textField2=-124.217&e=0 Then click the Tsunami Watch link: http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=ORC011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch Also see: http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000 -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From belin.daniel at gmail.com Fri Mar 11 07:50:37 2011 From: belin.daniel at gmail.com (Daniel Belin) Date: Fri, 11 Mar 2011 08:50:37 -0500 Subject: so big earthquake in JP In-Reply-To: <4D79E261.8050404@mompl.net> References: <20110311145954.2707.9C4C12A4@nttv6.jp> <6991C2BD-4175-4409-8DB1-71FFDE58059B@asgaard.org> <4D79E261.8050404@mompl.net> Message-ID: <1C66D369-2C5A-447B-834E-E3DC9B180212@gmail.com> Are we aware of how much the infrastructure has been damaged yet? Are aftershocks still going? --- Daniel Belin On Mar 11, 2011, at 3:50 AM, Jeroen van Aart wrote: > Michael Painter wrote: >> Christopher LILJENSTOLPE wrote: >>> Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three dart bouys have detected > 2 ft wave fronts. Warnings >>> up for entire pacific basin except for Alaska/canada/us west coast. >>> >>> Chris >> Tsunami sirens just went off on Maui. > > You may get information by going to forecast.weather.gov and searching for a location. i.e.: > > http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&site=MFR&textField1=43.3667&textField2=-124.217&e=0 > > Then click the Tsunami Watch link: > http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=ORC011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch > > Also see: > http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000 > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > From jsw at inconcepts.biz Fri Mar 11 07:53:51 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 11 Mar 2011 08:53:51 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> Message-ID: On Thu, Mar 10, 2011 at 10:51 PM, George Bonser wrote: > And I say making them /127s may not really make any difference. ?Say you > make all of those /127s, at some point you *are* going to have a network > someplace that is a /64 that has hosts on it and that one is just as > subject to such an attack. ?If you are a content provider, it doesn't > make any difference if they take down the links between your routers or > if they take down the link that your content farm is on. ?The end result > is the same. ?You have managed to re-arrange the deck chairs. ?Have > another squeeze at that water balloon. Again, this is the argument put forth by the "RFC wavers," that you can't solve the problem because you must want to configure /64s for ... what, exactly? Oh, right, SLAAC. More on that below. If I'm a content provider, I don't have to configure a /64 for my content farm. I can configure a /120 or whatever subnet size is practical for my environment. I can also use link-local addressing on my content farm LANs and route subnets to my content boxes, if that is somehow more practical than using a smaller subnet. > If you are a service provider where practically all of your links are > point to points, sure. No, you can avoid configuring /64s if you don't need SLAAC. Who needs SLAAC? I don't. It has absolutely no place in any of my environments. It seems to me that DHCPv6 will do everything which SLAAC does, and everything SLAAC forgot about. The "complexity" argument is pretty much indefensible when the trade-off is configuring DHCPv6 vs turning a bunch of router knobs and hoping no one ever targets your LANs with an NDP DoS. > We didn't need much more host addressing, we needed more subnet > addressing. ?I would have settled for 16 bits of host addressing and 112 > bits of subnet addressing and I suppose nothing prevents me from doing > that except none of the standard IPv6 automatic stuff would work > anymore. None of that "standard IPv6 automatic stuff" works today, anyway. The state of IPv6 support on end-user CPE generally ranges from non-existent to untested to verified-to-be-broken. This is the only place in your network where /64 can offer any value, and currently, CPE is just not there. Even the latest Cisco/Linksys CPE does not support IPv6. Sure, that'll change; but what won't change is the total lack of any basis for configuring /64 LANs for "content farms" or any similar non-end-user, non-dynamic segments. I don't want 16 bits of host addressing. I want to choose an appropriate size for each subnet. Why? Because exactly zero of my access routers can handle 2**16 NDP entries, let alone 2**16 entries on multiple interfaces/VLANs. I would like to see much larger ARP/NDP tables in layer-3 switches, and I think vendors will deliver on that, but I doubt we'll soon see even a 10x increase from typical table sizes of today. VPS farms are already pushing the envelope with IPv4, where customers are already used to conserving addresses. Guess what, customers may still have to conserve addresses with IPv6, not because the numbers themselves are precious, but because the number of ARP/NDP entries in the top-of-rack or distribution switch is finite. > And again, are you talking about all the way down to the host subnet > level? ?I suppose I could configure server farms in /112 or even /96 > (/96 has some appeal for other reasons mostly having to do with > multicast) but then I would wonder how many bugs that would flush out of > OS v6 stacks. I'm not getting reports of problems with smaller-than-/64 subnets from customers yet. Am I confident that I never will? No, absolutely not! Like almost everyone else, I have some customers who have configured IPv6, but the amount of production traffic on it remains trivial. That is why I allocate a /64 but provision a /120 (or similar practical size.) I can grow the subnet if I have to. I do know that /64 LANs will cause me DoS problems, so I choose to work around that problem now. If /120 LANs cause me OS headaches in the future, I have the option to revise my choice with minimal effort (no services get renumbered, only the subnet must grow.) Why would you suggest /96 as being more practical than /64 from the perspective of NDP DoS? Again, this is an example of the "in-between" folks in these arguments, who seem not to fully understand the problem. Your routers do not have room for 2**(128-96) NDP entries. Typical access switches today have room for a few thousand to perhaps 16k, and typical "bigger" switches are specifying figures below 100k. This doesn't approach the 4.3M addresses in a /96. In short, suggesting /96 is flat out stupid -- you get "the worst of both worlds," potential for OS compatibility issues, AND guaranteed NDP DoS vulnerability. > passing traffic. That doesn't protect against rogue hosts but there > might be ways around that, too, or at least limiting the damage a rogue > host can cause. How do you suggest we limit the damage a rogue host can cause? A lot of people would like to hear your idea. Again, in nearly ten years of discussing this with colleagues, I have not seen any idea which is more practical than configuring a /120 instead of a /64. I have not seen any idea, period, which doesn't involve configuring the IPs which are allowed to be used on the LAN, either on the access switch port (NDP inspection), the access router, or in a database (like RADIUS.) This kind of configuration complexity is exactly what SLAAC hoped to avoid. Unfortunately, the folks who thought that up did so at a time when most access routers were still routing in CPU and main memory, not ASIC. It's important to understand how the underlying technology has changed in the past 15+ years -- if you don't, you must think, "man, those IPv6 standards guys were idiots." They weren't idiots, but they didn't know how routing and switching hardware would evolve, certainly they did not know how long it would take IPv6 to be deployed (it still isn't, effectively), and they probably didn't consider the potential future where DDoS is rampant and virtually unchecked to be a good reason not to craft SLAAC into the standards. They were also coming out of an era where CIDR/VLSM was still kinda new, and I believe there were *zero* boxes at that time which could "route" at wire speed, vs many boxes that would switch at wire speed, thus there were perceived advantages to having fewer, bigger subnets with no requirement for VLSM. Remember when there was no such thing as a layer-3 switch, and installing an RSM in your Cat5500 to get a little bit of routing capability was the greatest thing since sliced bread? This is where IPv6 came from, and it is why we have these design problems today -- the standards people are ideologically married to ideas that made perfect sense in the mid-90s, but they forgot why those ideas made sense back then and don't understand why this is not practical today. I'm glad SLAAC is an option, but that's all it is, an option. /64 LANs must also be considered optional, and should be considered useful only when SLAAC is desired. > Something will have to be done at some point ... soon. I'm glad more people are coming around to this point of view. Cisco certainly is there. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From tme at americafree.tv Fri Mar 11 08:08:54 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 11 Mar 2011 09:08:54 -0500 Subject: so big earthquake in JP In-Reply-To: <1C66D369-2C5A-447B-834E-E3DC9B180212@gmail.com> References: <20110311145954.2707.9C4C12A4@nttv6.jp> <6991C2BD-4175-4409-8DB1-71FFDE58059B@asgaard.org> <4D79E261.8050404@mompl.net> <1C66D369-2C5A-447B-834E-E3DC9B180212@gmail.com> Message-ID: On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote: > Are we aware of how much the infrastructure has been damaged yet? Are aftershocks still going? The tsunami was 1/2 meter in Kauai http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs ETA's for the West Coast are around 7:00 AM PST http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-arrival-times-for-canadas-west-coast/article1938243/ > > --- > > Daniel Belin > > On Mar 11, 2011, at 3:50 AM, Jeroen van Aart wrote: > >> Michael Painter wrote: >>> Christopher LILJENSTOLPE wrote: >>>> Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three dart bouys have detected > 2 ft wave fronts. Warnings >>>> up for entire pacific basin except for Alaska/canada/us west coast. Official warming http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.133222 The tsunami was 1.3 meters at Midway Is., 1/2 meter at Kauai http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs Here is a live feed - it is striking Waikiki (with no real damage IFAICT, but it is dark) right now http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1 ETA's for the West Coast are around 7:00 AM PST http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-arrival-times-for-canadas-west-coast/article1938243/ Regards Marshall >>>> >>>> Chris >>> Tsunami sirens just went off on Maui. >> >> You may get information by going to forecast.weather.gov and searching for a location. i.e.: >> >> http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&site=MFR&textField1=43.3667&textField2=-124.217&e=0 >> >> Then click the Tsunami Watch link: >> http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=ORC011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch >> >> Also see: >> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000 >> >> -- >> http://goldmark.org/jeff/stupid-disclaimers/ >> http://linuxmafia.com/~rick/faq/plural-of-virus.html >> > > From patrick at ianai.net Fri Mar 11 08:11:28 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 11 Mar 2011 09:11:28 -0500 Subject: so big earthquake in JP In-Reply-To: <1C66D369-2C5A-447B-834E-E3DC9B180212@gmail.com> References: <20110311145954.2707.9C4C12A4@nttv6.jp> <6991C2BD-4175-4409-8DB1-71FFDE58059B@asgaard.org> <4D79E261.8050404@mompl.net> <1C66D369-2C5A-447B-834E-E3DC9B180212@gmail.com> Message-ID: <415ECF6B-E6A6-4C4B-A4D7-15C2E98E30B0@ianai.net> On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote: > Are we aware of how much the infrastructure has been damaged yet? Are aftershocks still going? Subway & bus lines are still down. Fire at the nuke plant has been put out, no radiation detected, but they still evacuated a couple thousand residents because the backup generator failed & the water pump is not pumping. The Japanese gov't has sent troops into some areas, asked Washington to let the US service men in .jp (about 50K) help. I don't know if D.C. has agreed, but I can't imagine Obama would say no. A few hundred bodies have been found so far. It is very bad. But it could have been worse, the Japanese are very well prepared (building codes, emergency procedures, etc.). -- TTFN, patrick From tme at americafree.tv Fri Mar 11 08:19:33 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 11 Mar 2011 09:19:33 -0500 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> <6991C2BD-4175-4409-8DB1-71FFDE58059B@asgaard.org> <4D79E261.8050404@mompl.net> <1C66D369-2C5A-447B-834E-E3DC9B180212@gmail.com> Message-ID: <10221EDF-DD32-40E8-A20E-E839682E9595@americafree.tv> On Mar 11, 2011, at 9:08 AM, Marshall Eubanks wrote: > > On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote: > >> Are we aware of how much the infrastructure has been damaged yet? Are aftershocks still going? > > > The tsunami was 1/2 meter in Kauai > > http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs This live feed from Honolulu indicates that Hawaii damage is minor so far. The Tsunami is striking Hilo right now, and the Waikiki sea wall is under water. http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1 Regards Marshall > > ETA's for the West Coast are around 7:00 AM PST > > http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-arrival-times-for-canadas-west-coast/article1938243/ > >> >> --- >> >> Daniel Belin >> >> On Mar 11, 2011, at 3:50 AM, Jeroen van Aart wrote: >> >>> Michael Painter wrote: >>>> Christopher LILJENSTOLPE wrote: >>>>> Pacific tsunami warning centre has confirmed a deep ocean tsunami. Three dart bouys have detected > 2 ft wave fronts. Warnings >>>>> up for entire pacific basin except for Alaska/canada/us west coast. > > Official warming > http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.133222 > > The tsunami was 1.3 meters at Midway Is., 1/2 meter at Kauai > > http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs > > Here is a live feed - it is striking Waikiki (with no real damage IFAICT, but it is dark) right now > http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1 > > ETA's for the West Coast are around 7:00 AM PST > > http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami-arrival-times-for-canadas-west-coast/article1938243/ > > Regards > Marshall > > >>>>> >>>>> Chris >>>> Tsunami sirens just went off on Maui. >>> >>> You may get information by going to forecast.weather.gov and searching for a location. i.e.: >>> >>> http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&site=MFR&textField1=43.3667&textField2=-124.217&e=0 >>> >>> Then click the Tsunami Watch link: >>> http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=ORC011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch >>> >>> Also see: >>> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000 >>> >>> -- >>> http://goldmark.org/jeff/stupid-disclaimers/ >>> http://linuxmafia.com/~rick/faq/plural-of-virus.html >>> >> >> > > > From ml at kenweb.org Fri Mar 11 08:25:32 2011 From: ml at kenweb.org (ML) Date: Fri, 11 Mar 2011 09:25:32 -0500 Subject: Long Distance Dark Fiber In-Reply-To: <3c53efc09fb96ffb77934bc5dbe1e475@feltonline.com> References: <3c53efc09fb96ffb77934bc5dbe1e475@feltonline.com> Message-ID: <4D7A30DC.7010502@kenweb.org> On 3/10/2011 12:15 AM, nanog wrote: > Good Evening all. I got an odd and somewhat crazy request from our > development group for a long haul OC48 connection for testing (they > specifically said from their office in Utah to the east coast and back) > with minimal jitter. They need to be able to run their own framing Sonet > and WDM - don't ask me why, it doesn't make sense to me. It would seem to > me that the last requirement would require a dark fiber? > > So I've got several questions. > > One, is there any provider that would provide us such a beast for only one > month? I realize that the fact this is long haul OC48 would make the cost > astronomically high, and then throwing on the one month would make it even > more expensive.... > > Two, is there any good way to simulate such a long distance link? I know > such equipment exists for smaller links, but I haven't yet found anything > that'll do OC48 fiber. I'm sure the cost would be high for the equipment, > however I'm betting it is *much* lower than the long distance link. > > Three, could we sanely encapsulate their framing into GRE (or some other > such technology) and send it over an IP link and get SLAs to minimize the > jitter? > > Offlist responses would be greatly appreciated. Would it be too crazy to buy a spool of fiber and splice the end of one pair to the next pair and so on? Won't be able to simulate 2200 miles of fiber but it'll be a long span. From garret at picchioni.org Fri Mar 11 08:29:29 2011 From: garret at picchioni.org (Garret Picchioni) Date: Fri, 11 Mar 2011 07:29:29 -0700 Subject: so big earthquake in JP In-Reply-To: <10221EDF-DD32-40E8-A20E-E839682E9595@americafree.tv> Message-ID: Does anyone have any stats on route updates that might suggest the possibility of fiber on the ocean floor being damaged? On 3/11/11 7:19 AM, "Marshall Eubanks" wrote: > >On Mar 11, 2011, at 9:08 AM, Marshall Eubanks wrote: > >> >> On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote: >> >>> Are we aware of how much the infrastructure has been damaged yet? Are >>>aftershocks still going? >> >> >> The tsunami was 1/2 meter in Kauai >> >> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs > >This live feed from Honolulu indicates that Hawaii damage is minor so >far. The Tsunami is striking Hilo right now, and the Waikiki sea wall is >under water. > >http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1 > >Regards >Marshall > >> >> ETA's for the West Coast are around 7:00 AM PST >> >> >>http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami- >>arrival-times-for-canadas-west-coast/article1938243/ >> >>> >>> --- >>> >>> Daniel Belin >>> >>> On Mar 11, 2011, at 3:50 AM, Jeroen van Aart wrote: >>> >>>> Michael Painter wrote: >>>>> Christopher LILJENSTOLPE wrote: >>>>>> Pacific tsunami warning centre has confirmed a deep ocean tsunami. >>>>>>Three dart bouys have detected > 2 ft wave fronts. Warnings >>>>>> up for entire pacific basin except for Alaska/canada/us west coast. >> >> Official warming >> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.133222 >> >> The tsunami was 1.3 meters at Midway Is., 1/2 meter at Kauai >> >> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs >> >> Here is a live feed - it is striking Waikiki (with no real damage >>IFAICT, but it is dark) right now >> http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1 >> >> ETA's for the West Coast are around 7:00 AM PST >> >> >>http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami- >>arrival-times-for-canadas-west-coast/article1938243/ >> >> Regards >> Marshall >> >> >>>>>> >>>>>> Chris >>>>> Tsunami sirens just went off on Maui. >>>> >>>> You may get information by going to forecast.weather.gov and >>>>searching for a location. i.e.: >>>> >>>> >>>>http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&sit >>>>e=MFR&textField1=43.3667&textField2=-124.217&e=0 >>>> >>>> Then click the Tsunami Watch link: >>>> >>>>http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=OR >>>>C011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch >>>> >>>> Also see: >>>> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000 >>>> >>>> -- >>>> http://goldmark.org/jeff/stupid-disclaimers/ >>>> http://linuxmafia.com/~rick/faq/plural-of-virus.html >>>> >>> >>> >> >> >> > > From RShimonski at carcogroup.com Fri Mar 11 08:32:55 2011 From: RShimonski at carcogroup.com (Robert Shimonski) Date: Fri, 11 Mar 2011 09:32:55 -0500 Subject: Switching Email Message-ID: <4D79EC47020000FA00050E82@CARNYGW.carcogroup.com> I would like to opt out of this news list. Thanks you Rob Shimonski Information Technology CARCO Group, Inc. 5000 Corporate Court, Suite 203 Holtsville, NY 11742 Phone 631-862-9300 Ext 455 This electronic communication (including attachments) contains privileged and confidential information intended only for the use of the named recipient. If you are not the intended recipient, you are prohibited from disseminating, distributing or copying this communication. If you have received this communication in error, please immediately notify us by return message or by telephone and delete this communication from your system. Thank you. From belin.daniel at gmail.com Fri Mar 11 08:33:15 2011 From: belin.daniel at gmail.com (Daniel Belin) Date: Fri, 11 Mar 2011 09:33:15 -0500 Subject: so big earthquake in JP In-Reply-To: References: <10221EDF-DD32-40E8-A20E-E839682E9595@americafree.tv> Message-ID: The BGP route between NLR and JGN and JGN2+ has been down for more than an hour and a half. On Fri, Mar 11, 2011 at 9:29 AM, Garret Picchioni wrote: > Does anyone have any stats on route updates that might suggest the > possibility of fiber on the ocean floor being damaged? > > On 3/11/11 7:19 AM, "Marshall Eubanks" wrote: > > > > >On Mar 11, 2011, at 9:08 AM, Marshall Eubanks wrote: > > > >> > >> On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote: > >> > >>> Are we aware of how much the infrastructure has been damaged yet? Are > >>>aftershocks still going? > >> > >> > >> The tsunami was 1/2 meter in Kauai > >> > >> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs > > > >This live feed from Honolulu indicates that Hawaii damage is minor so > >far. The Tsunami is striking Hilo right now, and the Waikiki sea wall is > >under water. > > > >http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1 > > > >Regards > >Marshall > > > >> > >> ETA's for the West Coast are around 7:00 AM PST > >> > >> > >> > http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami- > >>arrival-times-for-canadas-west-coast/article1938243/ > >> > >>> > >>> --- > >>> > >>> Daniel Belin > >>> > >>> On Mar 11, 2011, at 3:50 AM, Jeroen van Aart wrote: > >>> > >>>> Michael Painter wrote: > >>>>> Christopher LILJENSTOLPE wrote: > >>>>>> Pacific tsunami warning centre has confirmed a deep ocean tsunami. > >>>>>>Three dart bouys have detected > 2 ft wave fronts. Warnings > >>>>>> up for entire pacific basin except for Alaska/canada/us west coast. > >> > >> Official warming > >> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.133222 > >> > >> The tsunami was 1.3 meters at Midway Is., 1/2 meter at Kauai > >> > >> http://www.weather.gov/ptwc/?region=1&id=pacific.2011.03.11.133222&obs > >> > >> Here is a live feed - it is striking Waikiki (with no real damage > >>IFAICT, but it is dark) right now > >> > http://www.hawaiinewsnow.com/Global/category.asp?C=176904&nav=menu55_1_1 > >> > >> ETA's for the West Coast are around 7:00 AM PST > >> > >> > >> > http://www.theglobeandmail.com/news/world/asia-pacific/estimated-tsunami- > >>arrival-times-for-canadas-west-coast/article1938243/ > >> > >> Regards > >> Marshall > >> > >> > >>>>>> > >>>>>> Chris > >>>>> Tsunami sirens just went off on Maui. > >>>> > >>>> You may get information by going to forecast.weather.gov and > >>>>searching for a location. i.e.: > >>>> > >>>> > >>>> > http://forecast.weather.gov/MapClick.php?CityName=Coos+Bay&state=OR&sit > >>>>e=MFR&textField1=43.3667&textField2=-124.217&e=0 > >>>> > >>>> Then click the Tsunami Watch link: > >>>> > >>>> > http://forecast.weather.gov/showsigwx.php?warnzone=ORZ021&warncounty=OR > >>>>C011&firewxzone=ORZ615&local_place1=Coos+Bay+OR&product1=Tsunami+Watch > >>>> > >>>> Also see: > >>>> http://www.weather.gov/ptwc/text.php?id=pacific.2011.03.11.073000 > >>>> > >>>> -- > >>>> http://goldmark.org/jeff/stupid-disclaimers/ > >>>> http://linuxmafia.com/~rick/faq/plural-of-virus.html > >>>> > >>> > >>> > >> > >> > >> > > > > > > > -- Sincerely, Daniel F. Belin From dorian at blackrose.org Fri Mar 11 08:37:02 2011 From: dorian at blackrose.org (Dorian Kim) Date: Fri, 11 Mar 2011 09:37:02 -0500 Subject: so big earthquake in JP In-Reply-To: References: <10221EDF-DD32-40E8-A20E-E839682E9595@americafree.tv> Message-ID: <20110311143702.GH54705@blackrose.org> On Fri, Mar 11, 2011 at 07:29:29AM -0700, Garret Picchioni wrote: > Does anyone have any stats on route updates that might suggest the > possibility of fiber on the ocean floor being damaged? There are some submarine cable outages but I don't believe exact locations of damage has been isolated. I suspect that this may take some time. -dorian From jmaimon at ttec.com Fri Mar 11 08:38:12 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 11 Mar 2011 09:38:12 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> Message-ID: <4D7A33D4.7000406@ttec.com> Jeff Wheeler wrote: > I'm glad SLAAC is an option, but that's all it is, an option. /64 > LANs must also be considered optional, and should be considered useful > only when SLAAC is desired. That also could be optional, automatic host configuration does not actually require 64 bits, unless there is a naive assumption that DAD need not occur. Which it must always and for many reasons. rfc3927 does not require 64 bits and works sufficiently well wherever it is employed. SLAAC should be redesigned to be configurable to work with however many bits are available to it and it should be a standard feature to turn that knob all the way from on - off with 128 bit stops in between. And now DHCP-PD can start at any point in the connected hierarchy, working with whatever amount of space is available and not requiring complete upstream support. I dont accept that IPv6 is set in stone. IPv4 wasnt/isnt set in stone and people were/are actually using it because they depend on it. Joe From andrew.wallace at rocketmail.com Fri Mar 11 08:43:23 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Fri, 11 Mar 2011 06:43:23 -0800 (PST) Subject: so big earthquake in JP Message-ID: <153329.62088.qm@web59611.mail.ac4.yahoo.com> Here is a forecast map of the Tsunami http://www.bbc.co.uk/news/world-asia-pacific-12715415 Andrew From jsw at inconcepts.biz Fri Mar 11 09:16:21 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 11 Mar 2011 10:16:21 -0500 Subject: Long Distance Dark Fiber In-Reply-To: <4D7A30DC.7010502@kenweb.org> References: <3c53efc09fb96ffb77934bc5dbe1e475@feltonline.com> <4D7A30DC.7010502@kenweb.org> Message-ID: On Fri, Mar 11, 2011 at 9:25 AM, ML wrote: > Would it be too crazy to buy a spool of fiber and splice the end of one pair > to the next pair and so on? ?Won't be able to simulate 2200 miles of fiber > but it'll be a long span. This is by no means crazy. If you visit a laboratory where gear is tested, you'll find exactly that -- spools of fiber which can be connected together (through whatever splicing or patching method is desired for the simulation) to give the desired span length. These usually look nicer than big spools of cable, and are even available in rack-mount enclosures with vendor logos. :) -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From joelja at bogus.com Fri Mar 11 09:50:41 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 11 Mar 2011 07:50:41 -0800 Subject: Long Distance Dark Fiber In-Reply-To: References: <3c53efc09fb96ffb77934bc5dbe1e475@feltonline.com> <4D7A30DC.7010502@kenweb.org> Message-ID: <4D7A44D1.3030609@bogus.com> On 3/11/11 7:16 AM, Jeff Wheeler wrote: > On Fri, Mar 11, 2011 at 9:25 AM, ML wrote: >> Would it be too crazy to buy a spool of fiber and splice the end of one pair >> to the next pair and so on? Won't be able to simulate 2200 miles of fiber >> but it'll be a long span. > > This is by no means crazy. If you visit a laboratory where gear is > tested, you'll find exactly that -- spools of fiber which can be > connected together (through whatever splicing or patching method is > desired for the simulation) to give the desired span length. These > usually look nicer than big spools of cable, and are even available in > rack-mount enclosures with vendor logos. :) one does not however do 2200 miles of terrestrial fiber simulation without simulating regeneration as well. From sbryant at thepit.org Fri Mar 11 09:51:40 2011 From: sbryant at thepit.org (Shaun Bryant) Date: Fri, 11 Mar 2011 08:51:40 -0700 Subject: so big earthquake in JP In-Reply-To: <153329.62088.qm@web59611.mail.ac4.yahoo.com> References: <153329.62088.qm@web59611.mail.ac4.yahoo.com> Message-ID: We can't bring up our satellite links that we use for point to point classroom learning with another SciTech school in JP. Not sure if it is a power issue on the other end or they are now out of alignment, but we can normally bring up these camera's at will. We have backup controls via 3G and that is down as well and it has 12+ hours of power backup. Shaun *Shaun Bryant* * **I* Director of Technology * l Denver School of Science and Technology * On Fri, Mar 11, 2011 at 7:43 AM, andrew.wallace < andrew.wallace at rocketmail.com> wrote: > Here is a forecast map of the Tsunami > > http://www.bbc.co.uk/news/world-asia-pacific-12715415 > > Andrew > > > > > From Valdis.Kletnieks at vt.edu Fri Mar 11 12:07:15 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 11 Mar 2011 13:07:15 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: Your message of "Fri, 11 Mar 2011 09:38:12 EST." <4D7A33D4.7000406@ttec.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> Message-ID: <49506.1299866835@localhost> On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said: > rfc3927 does not require 64 bits and works sufficiently well wherever it > is employed. SLAAC should be redesigned to be configurable to work with > however many bits are available to it and it should be a standard > feature to turn that knob all the way from on - off with 128 bit stops > in between. Feel free to explain how SLAAC should work on a /96 with 32 bits of host address (or any amount smaller than the 48 bits most MAC addresses provide). Remember in your answer to deal with collisions. It's one thing to say "it should be redesigned". It's another matter entirely to actually come up with a scheme that doesn't suck even harder than "screw it, it's a /64". -------------- 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 Fri Mar 11 12:12:09 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Mar 2011 10:12:09 -0800 Subject: so big earthquake in JP Message-ID: <20110311101209.36F31CF5@resin16.mta.everyone.net> --- tme at americafree.tv wrote: From: Marshall Eubanks The tsunami was 1/2 meter in Kauai ------------------------------------------- The road to the west side is still closed at Hanapepe. No work today. Yipeee! :-) scott From surfer at mauigateway.com Fri Mar 11 12:19:55 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Mar 2011 10:19:55 -0800 Subject: so big earthquake in JP Message-ID: <20110311101955.36F31A65@resin16.mta.everyone.net> --- surfer at mauigateway.com wrote: --- tme at americafree.tv wrote: The tsunami was 1/2 meter in Kauai ------------------------------------------- The road to the west side is still closed at Hanapepe. No work today. Yipeee! :-) ----------------------------------------------- Also, no real damage: http://thegardenisland.com/news/local/article_6a515a9a-4bdb-11e0-a9b3-001cc4c03286.html "Doug Sears of the Grand Hyatt Kauai in Poipu told KHON around 3:30 a.m. that there was "nothing exciting yet." He reported a "non-event" and said a minor surge in the surf was observed. Reports around the island indicated only slight rises in water levels at coastal areas. A 2.1-foot rise was recorded at Nawiliwli Harbor; 2.8 feet in Hanalei, according to the National Weather Service. No damage was reported." scott From mike at mtcc.com Fri Mar 11 12:29:12 2011 From: mike at mtcc.com (Michael Thomas) Date: Fri, 11 Mar 2011 10:29:12 -0800 Subject: voip vs tdm fallout Message-ID: <4D7A69F8.2030104@mtcc.com> Is it too soon to start to compare and contrast how voip held up vs. tdm? Back in the old days circa mid to late 90's, there was a lot of hand wringing about whether voip would be up to the task of dealing with a massive emergency. Well, we certainly have one now in Japan on almost every front imaginable. Is voice such a small fraction of data that the larger issues of cuts, electricity, etc make it moot, or has there been some appreciable differences between the two's ability to stay in usable service? Mike From george.herbert at gmail.com Fri Mar 11 12:35:18 2011 From: george.herbert at gmail.com (George Herbert) Date: Fri, 11 Mar 2011 10:35:18 -0800 Subject: so big earthquake in JP In-Reply-To: <20110311101955.36F31A65@resin16.mta.everyone.net> References: <20110311101955.36F31A65@resin16.mta.everyone.net> Message-ID: We're seeing damage in harbors on the west coast - live imagery of Santa Cruz harbor with multiple piers broken up, boats loose, boats sunk, from local geography focusing waves that were only 2-3 foot surges (personal Ouch - I used to own a boat in that harbor). Phone reporting from Crescent City (northern california) indicating that the latest surge up there is 8.1 feet just now - their harbor is apparently pretty bad off. I have no reports of fiber landings affected - along most coastal beaches it's just an unusual wave surge height - but the surges are in some locations getting to the point that they could do that. -george On Fri, Mar 11, 2011 at 10:19 AM, Scott Weeks wrote: > > > --- surfer at mauigateway.com wrote: > --- tme at americafree.tv wrote: > > The tsunami was 1/2 meter in Kauai > ------------------------------------------- > > The road to the west side is still closed at Hanapepe. ?No work today. ?Yipeee! :-) > ----------------------------------------------- > > > Also, no real damage: http://thegardenisland.com/news/local/article_6a515a9a-4bdb-11e0-a9b3-001cc4c03286.html > > "Doug Sears of the Grand Hyatt Kauai in Poipu told KHON around 3:30 a.m. that there was "nothing exciting yet." He reported a "non-event" and said a minor surge in the surf was observed. > > Reports around the island indicated only slight rises in water levels at coastal areas. > > A 2.1-foot rise was recorded at Nawiliwli Harbor; 2.8 feet in Hanalei, according to the National Weather Service. No damage was reported." > > > scott > > -- -george william herbert george.herbert at gmail.com From cscora at apnic.net Fri Mar 11 12:38:29 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 12 Mar 2011 04:38:29 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201103111838.p2BIcTFB000918@thyme.rand.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.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 12 Mar, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 350049 Prefixes after maximum aggregation: 157788 Deaggregation factor: 2.22 Unique aggregates announced to Internet: 172931 Total ASes present in the Internet Routing Table: 36036 Prefixes per ASN: 9.71 Origin-only ASes present in the Internet Routing Table: 31061 Origin ASes announcing only one prefix: 14941 Transit ASes present in the Internet Routing Table: 4975 Transit-only ASes present in the Internet Routing Table: 124 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 392 Unregistered ASNs in the Routing Table: 178 Number of 32-bit ASNs allocated by the RIRs: 1191 Prefixes from 32-bit ASNs in the Routing Table: 2 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 252 Number of addresses announced to Internet: 2467281824 Equivalent to 147 /8s, 15 /16s and 187 /24s Percentage of available address space announced: 66.6 Percentage of allocated address space announced: 66.6 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 89.1 Total number of prefixes smaller than registry allocations: 145075 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 87220 Total APNIC prefixes after maximum aggregation: 29669 APNIC Deaggregation factor: 2.94 Prefixes being announced from the APNIC address blocks: 84042 Unique aggregates announced from the APNIC address blocks: 36224 APNIC Region origin ASes present in the Internet Routing Table: 4339 APNIC Prefixes per ASN: 19.37 APNIC Region origin ASes announcing only one prefix: 1194 APNIC Region transit ASes present in the Internet Routing Table: 690 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 18 Number of APNIC addresses announced to Internet: 595474464 Equivalent to 35 /8s, 126 /16s and 56 /24s Percentage of available APNIC address space announced: 75.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, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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: 140487 Total ARIN prefixes after maximum aggregation: 71719 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 110994 Unique aggregates announced from the ARIN address blocks: 44983 ARIN Region origin ASes present in the Internet Routing Table: 14247 ARIN Prefixes per ASN: 7.79 ARIN Region origin ASes announcing only one prefix: 5417 ARIN Region transit ASes present in the Internet Routing Table: 1472 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 796431232 Equivalent to 47 /8s, 120 /16s and 147 /24s Percentage of available ARIN address space announced: 63.3 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, 23/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, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/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: 82683 Total RIPE prefixes after maximum aggregation: 47102 RIPE Deaggregation factor: 1.76 Prefixes being announced from the RIPE address blocks: 76020 Unique aggregates announced from the RIPE address blocks: 49879 RIPE Region origin ASes present in the Internet Routing Table: 15397 RIPE Prefixes per ASN: 4.94 RIPE Region origin ASes announcing only one prefix: 7770 RIPE Region transit ASes present in the Internet Routing Table: 2401 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 23 Number of RIPE addresses announced to Internet: 480842752 Equivalent to 28 /8s, 169 /16s and 20 /24s Percentage of available RIPE address space announced: 77.5 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, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 31952 Total LACNIC prefixes after maximum aggregation: 7382 LACNIC Deaggregation factor: 4.33 Prefixes being announced from the LACNIC address blocks: 30818 Unique aggregates announced from the LACNIC address blocks: 16131 LACNIC Region origin ASes present in the Internet Routing Table: 1438 LACNIC Prefixes per ASN: 21.43 LACNIC Region origin ASes announcing only one prefix: 431 LACNIC Region transit ASes present in the Internet Routing Table: 264 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 81386624 Equivalent to 4 /8s, 217 /16s and 220 /24s Percentage of available LACNIC address space announced: 53.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/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: 7497 Total AfriNIC prefixes after maximum aggregation: 1812 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 5880 Unique aggregates announced from the AfriNIC address blocks: 1850 AfriNIC Region origin ASes present in the Internet Routing Table: 434 AfriNIC Prefixes per ASN: 13.55 AfriNIC Region origin ASes announcing only one prefix: 129 AfriNIC Region transit ASes present in the Internet Routing Table: 94 Average AfriNIC Region AS path length visible: 5.3 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 22031360 Equivalent to 1 /8s, 80 /16s and 44 /24s Percentage of available AfriNIC address space announced: 32.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2421 9508 892 Korea Telecom (KIX) 7545 1594 301 84 TPG Internet Pty Ltd 4755 1473 653 157 TATA Communications formerly 17974 1413 468 29 PT TELEKOMUNIKASI INDONESIA 24560 1120 324 186 Bharti Airtel Ltd., Telemedia 9583 1048 77 488 Sify Limited 4808 1046 2142 294 CNCGROUP IP network: China169 9829 1005 868 53 BSNL National Internet Backbo 17488 944 162 100 Hathway IP Over Cable Interne 18101 938 117 144 Reliance Infocom Ltd Internet Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3681 3839 259 bellsouth.net, inc. 4323 2584 1109 403 Time Warner Telecom 19262 1829 4953 282 Verizon Global Networks 1785 1792 681 131 PaeTec Communications, Inc. 6478 1538 298 75 AT&T Worldnet Services 20115 1526 1534 650 Charter Communications 18566 1524 326 180 Covad Communications 7018 1365 6706 887 AT&T WorldNet Services 11492 1311 236 66 Cable One 2386 1294 537 934 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 515 1780 318 UPC Distribution Services 9198 470 267 15 Kazakhtelecom Data Network Ad 3292 450 1996 389 TDC Tele Danmark 34984 449 95 200 BILISIM TELEKOM 8866 443 133 23 Bulgarian Telecommunication C 20940 411 98 314 Akamai Technologies European 3320 407 7604 353 Deutsche Telekom AG 8551 403 353 46 Bezeq International 12479 401 577 6 Uni2 Autonomous System 8402 397 320 11 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1384 258 163 TVCABLE BOGOTA 8151 1243 2700 368 UniNet S.A. de C.V. 28573 1234 963 83 NET Servicos de Comunicao S.A 6503 1181 354 72 AVANTEL, S.A. 7303 919 464 148 Telecom Argentina Stet-France 14420 644 56 93 CORPORACION NACIONAL DE TELEC 22047 541 310 15 VTR PUNTO NET S.A. 3816 514 225 97 Empresa Nacional de Telecomun 11172 488 83 82 Servicios Alestra S.A de C.V 7738 479 922 30 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 791 445 11 TEDATA 24863 762 147 36 LINKdotNET AS number 15475 419 90 8 Nile Online 36992 300 271 14 Etisalat MISR 3741 266 987 228 The Internet Solution 33776 230 13 5 Starcomms Nigeria Limited 24835 228 78 10 RAYA Telecom - Egypt 6713 204 199 11 Itissalat Al-MAGHRIB 29571 192 17 11 Ci Telecom Autonomous system 16637 141 422 85 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3681 3839 259 bellsouth.net, inc. 4323 2584 1109 403 Time Warner Telecom 4766 2421 9508 892 Korea Telecom (KIX) 19262 1829 4953 282 Verizon Global Networks 1785 1792 681 131 PaeTec Communications, Inc. 7545 1594 301 84 TPG Internet Pty Ltd 6478 1538 298 75 AT&T Worldnet Services 20115 1526 1534 650 Charter Communications 18566 1524 326 180 Covad Communications 4755 1473 653 157 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2584 2181 Time Warner Telecom 1785 1792 1661 PaeTec Communications, Inc. 19262 1829 1547 Verizon Global Networks 4766 2421 1529 Korea Telecom (KIX) 7545 1594 1510 TPG Internet Pty Ltd 6478 1538 1463 AT&T Worldnet Services 17974 1413 1384 PT TELEKOMUNIKASI INDONESIA 18566 1524 1344 Covad Communications 4755 1473 1316 TATA Communications formerly 11492 1311 1245 Cable One Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 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 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 1.5.0.0/16 38639 NTT Communications Corporatio 1.6.0.0/15 38639 NTT Communications Corporatio 1.8.0.0/16 38639 NTT Communications Corporatio 1.20.0.0/16 38639 NTT Communications Corporatio 1.32.0.0/16 38639 NTT Communications Corporatio 1.37.0.0/16 38639 NTT Communications Corporatio 1.187.0.0/16 38639 NTT Communications Corporatio 14.0.0.0/24 38639 NTT Communications Corporatio 14.0.1.0/24 38639 NTT Communications Corporatio 14.0.2.0/23 38639 NTT Communications Corporatio Complete listing at http://thyme.rand.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:24 /9:11 /10:26 /11:73 /12:216 /13:447 /14:768 /15:1370 /16:11556 /17:5669 /18:9352 /19:19025 /20:24651 /21:25208 /22:33478 /23:32020 /24:182909 /25:1136 /26:1330 /27:720 /28:42 /29:9 /30:3 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2271 3681 bellsouth.net, inc. 18566 1502 1524 Covad Communications 6478 1492 1538 AT&T Worldnet Services 4323 1391 2584 Time Warner Telecom 10620 1275 1384 TVCABLE BOGOTA 11492 1268 1311 Cable One 7011 1058 1158 Citizens Utilities 1785 1055 1792 PaeTec Communications, Inc. 6503 959 1181 AVANTEL, S.A. 19262 941 1829 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:271 2:57 4:14 5:1 8:340 12:2027 13:1 14:429 15:15 16:3 17:8 20:9 23:3 24:1515 27:608 31:2 32:60 33:4 34:2 36:2 37:1 38:714 39:1 40:101 41:2306 42:13 44:3 46:703 47:4 49:164 50:197 52:13 55:2 56:2 57:32 58:860 59:495 60:386 61:1133 62:1013 63:1922 64:3867 65:2351 66:4339 67:1775 68:1063 69:2886 70:701 71:399 72:2007 73:1 74:2351 75:283 76:341 77:837 78:699 79:445 80:1093 81:801 82:514 83:462 84:644 85:1044 86:571 87:753 88:350 89:1568 90:174 91:3593 92:486 93:1045 94:1216 95:778 96:471 97:251 98:805 99:34 101:58 106:1 107:4 108:129 109:905 110:477 111:720 112:320 113:379 114:496 115:711 116:958 117:678 118:719 119:1036 120:256 121:753 122:1615 123:1042 124:1298 125:1262 128:266 129:168 130:171 131:560 132:110 133:20 134:220 135:49 136:212 137:146 138:298 139:110 140:487 141:203 142:377 143:379 144:493 145:52 146:424 147:194 148:640 149:276 150:161 151:229 152:298 153:180 154:3 155:377 156:179 157:345 158:131 159:371 160:312 161:211 162:277 163:160 164:487 165:352 166:496 167:410 168:728 169:156 170:760 171:69 172:2 173:1259 174:516 175:328 177:35 178:804 180:813 181:4 182:384 183:243 184:233 186:1044 187:837 188:919 189:1032 190:4561 192:5756 193:4780 194:3483 195:2948 196:1171 197:4 198:3581 199:3867 200:5585 201:1585 202:8302 203:8484 204:4106 205:2305 206:2653 207:3071 208:3909 209:3484 210:2686 211:1348 212:1932 213:1716 214:751 215:63 216:4844 217:1653 218:554 219:382 220:1199 221:476 222:318 223:101 End of report From sethm at rollernet.us Fri Mar 11 12:42:05 2011 From: sethm at rollernet.us (Seth Mattinen) Date: Fri, 11 Mar 2011 10:42:05 -0800 Subject: voip vs tdm fallout In-Reply-To: <4D7A69F8.2030104@mtcc.com> References: <4D7A69F8.2030104@mtcc.com> Message-ID: <4D7A6CFD.90106@rollernet.us> On 3/11/2011 10:29, Michael Thomas wrote: > > Is it too soon to start to compare and contrast how voip > held up vs. tdm? Back in the old days circa mid to late > 90's, there was a lot of hand wringing about whether > voip would be up to the task of dealing with a massive > emergency. Well, we certainly have one now in Japan > on almost every front imaginable. > > Is voice such a small fraction of data that the larger > issues of cuts, electricity, etc make it moot, or has > there been some appreciable differences between the > two's ability to stay in usable service? > My question would be what communications methods are working *right now* in the inital stages? (I heard cellular was down.) Past that, what's seeing service restoration first? ~Seth From belin.daniel at gmail.com Fri Mar 11 12:50:51 2011 From: belin.daniel at gmail.com (Daniel Belin) Date: Fri, 11 Mar 2011 13:50:51 -0500 Subject: voip vs tdm fallout In-Reply-To: <4D7A6CFD.90106@rollernet.us> References: <4D7A69F8.2030104@mtcc.com> <4D7A6CFD.90106@rollernet.us> Message-ID: On Fri, Mar 11, 2011 at 1:42 PM, Seth Mattinen wrote: >My question would be what communications methods are working *right now* >in the inital stages? (I heard cellular was down.) Past that, what's >seeing service restoration first? >From what I've heard, most of the cellular networks and wireless infrastructure is down. Thats what I heard recently, I don't know if anything has come back up. On a related note, whats going on with JUSCN, which has a landing in Shima? I heard there was damage, but I don't have hard facts as of yet. On Fri, Mar 11, 2011 at 1:42 PM, Seth Mattinen wrote: > On 3/11/2011 10:29, Michael Thomas wrote: > > > > Is it too soon to start to compare and contrast how voip > > held up vs. tdm? Back in the old days circa mid to late > > 90's, there was a lot of hand wringing about whether > > voip would be up to the task of dealing with a massive > > emergency. Well, we certainly have one now in Japan > > on almost every front imaginable. > > > > Is voice such a small fraction of data that the larger > > issues of cuts, electricity, etc make it moot, or has > > there been some appreciable differences between the > > two's ability to stay in usable service? > > > > My question would be what communications methods are working *right now* > in the inital stages? (I heard cellular was down.) Past that, what's > seeing service restoration first? > > ~Seth > > -- Sincerely, Daniel F. Belin From jmaimon at ttec.com Fri Mar 11 12:54:41 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 11 Mar 2011 13:54:41 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <49506.1299866835@localhost> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> Message-ID: <4D7A6FF1.8010202@ttec.com> Valdis.Kletnieks at vt.edu wrote: > On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said: > >> rfc3927 does not require 64 bits and works sufficiently well wherever it >> is employed. SLAAC should be redesigned to be configurable to work with >> however many bits are available to it and it should be a standard >> feature to turn that knob all the way from on - off with 128 bit stops >> in between. > > Feel free to explain how SLAAC should work on a /96 with 32 bits of host address > (or any amount smaller than the 48 bits most MAC addresses provide). Remember > in your answer to deal with collisions. Is there something fundamentally wrong with rfc3927? > > It's one thing to say "it should be redesigned". It's another matter entirely to actually > come up with a scheme that doesn't suck even harder than "screw it, it's a /64". > I dont have to, its already been done. In ipv4. Joe From stahr at mailbag.com Fri Mar 11 12:55:33 2011 From: stahr at mailbag.com (James Stahr) Date: Fri, 11 Mar 2011 12:55:33 -0600 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <42AD349D-432A-42C1-8EEC-4573203766C4@delong.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <49E4FB94-3D1B-476B-89C4-78155EDF2749@delong.com> <7EAB7486-5CE6-4D3A-8A78-0CB8B48879D9@arbor.net> <42AD349D-432A-42C1-8EEC-4573203766C4@delong.com> Message-ID: <20110311185541.2C618A009@h-mailbag-msp-1.msp-coloc.binc.net> At 01:33 AM 3/11/2011, Owen DeLong wrote: >On Mar 10, 2011, at 11:22 PM, Dobbins, Roland wrote: > > > > > On Mar 11, 2011, at 2:02 PM, Owen DeLong wrote: > > > > >> Frankly, unless you have parallel links, there isn't a definite > need to even number PtoP links for IPv6. > >> Every thing you need to do with an interface specific address on > a PtoP link can be done with link local. > > > > Which is why IP unnumbered caught on so well in IPv4-land, heh? > > >There's a HUGE difference between IP unnumbered and link-local. > >Frankly, absent parallel links, there was a lot to be said for IP unnumbered >and I think that if people had better understood the implications of where and >when it was a good vs. bad idea and tied it properly to loopbacks instead >of $RANDOM_INTERFACE, it might have caught on better. > >Owen Is anyone else considering only using link local for their PtoP links? I realized while deploying our IPv6 infrastructure that OSPFv3 uses the link-local address in the routing table and than the global address, so if I want to have a routing table which makes sense, I need to statically assign a global address AND the link-local address. Then I realized, why even assign a global in the first place? Traceroutes replies end up using the loopback. BGP will use loopbacks. So is there any obvious harm in this approach that I'm missing? -James From bicknell at ufp.org Fri Mar 11 12:58:09 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 11 Mar 2011 10:58:09 -0800 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <49506.1299866835@localhost> References: <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> Message-ID: <20110311185809.GA93069@ussenterprise.ufp.org> In a message written on Fri, Mar 11, 2011 at 01:07:15PM -0500, Valdis.Kletnieks at vt.edu wrote: > On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said: > > rfc3927 does not require 64 bits and works sufficiently well wherever it > > is employed. SLAAC should be redesigned to be configurable to work with > > however many bits are available to it and it should be a standard > > feature to turn that knob all the way from on - off with 128 bit stops > > in between. > > Feel free to explain how SLAAC should work on a /96 with 32 bits of host address > (or any amount smaller than the 48 bits most MAC addresses provide). Remember > in your answer to deal with collisions. Well, I at least think an option should be a /80, using the 48 bits of MAC directly. This generates exactly the same collision potential as today we have with a /64 and an EUI-64 constructed from an EUI-48 ethernet address. The router is already sending RA's for SLAAC to work, sending along one of a well-known set of masks would be a relatively minor modification. That said, ND has built into it DAD - Duplicate Address Detection. There is already an expectation that there will be collisions, and the protocols to detect them are already in place. I see little to no reason you couldn't use a different length subnet (like the /96 in your example), randomly select an address and do DAD to see if it is in use. Indeed, this is pretty much how AppleTalk back in the day worked (with a 16 bit number space). The probability of collision is pretty low, and the penalty/recovery (picking a new address and trying again) is rather quick and cheap. If a service provider is going to end up giving me a /64 at home (I know, a whole different argument) I'd vastly prefer to use /80 or /96 subnets with either of these methods, and still be able to subnet the space. I suspect if /64's are given out one or both will come to be "standard". -- 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 tdurack at gmail.com Fri Mar 11 13:04:45 2011 From: tdurack at gmail.com (Tim Durack) Date: Fri, 11 Mar 2011 14:04:45 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <20110311185541.2C618A009@h-mailbag-msp-1.msp-coloc.binc.net> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <49E4FB94-3D1B-476B-89C4-78155EDF2749@delong.com> <7EAB7486-5CE6-4D3A-8A78-0CB8B48879D9@arbor.net> <42AD349D-432A-42C1-8EEC-4573203766C4@delong.com> <20110311185541.2C618A009@h-mailbag-msp-1.msp-coloc.binc.net> Message-ID: On Fri, Mar 11, 2011 at 1:55 PM, James Stahr wrote: > Is anyone else considering only using link local for their PtoP links? I > realized while deploying our IPv6 infrastructure that OSPFv3 uses the > link-local address in the routing table and than the global address, so if I > want to have a routing table which makes sense, I need to statically assign > a global address AND the link-local address. Then I realized, why even > assign a global in the first place? Traceroutes replies end up using the > loopback. BGP will use loopbacks. So is there any obvious harm in this > approach that I'm missing? > For now I have allocated /64s per p-t-p, but I'm doing "ipv6 unnumbered loopback0" I quite like how the core route table looks. It also lets me avoid "The Point to Point Wars" :-) Maybe there will be a good reason to go back and slap globals on there, but I've not been convinced yet. -- Tim:> From oiyankok at yahoo.ca Fri Mar 11 13:15:36 2011 From: oiyankok at yahoo.ca (ann kok) Date: Fri, 11 Mar 2011 11:15:36 -0800 (PST) Subject: ipv6 question In-Reply-To: <1299730291.2109.119.camel@karl> Message-ID: <735479.99562.qm@web111316.mail.gq1.yahoo.com> Hi Then I won't use this ipv6 address 2001:db8:cafe:1111::12 for test Acutually, I have one in eth0 when I run ifconfig -a inet6 addr: fe80::20c:29ff:fe3c:92a1/64 Scope:Link but I also can't ping it ping6 fe80::20c:29ff:fe3c:92a1 connect: Invalid argument but ping6 ::1 is fine ping6 ::1 PING ::1(::1) 56 data bytes 64 bytes from ::1: icmp_seq=0 ttl=64 time=7.18 ms 64 bytes from ::1: icmp_seq=1 ttl=64 time=0.050 ms --- On Wed, 3/9/11, Karl Auer wrote: > From: Karl Auer > Subject: Re: ipv6 question > To: nanog at nanog.org > Received: Wednesday, March 9, 2011, 11:11 PM > On Thu, 2011-03-10 at 11:43 +1100, > Mark Andrews wrote: > > In message <1299711449.2109.98.camel at karl>, Karl > Auer writes: > > > On Wed, 2011-03-09 at 09:01 -0600, imNet > Administrator wrote: > > > > Where are you pinging it from? also, the > 2001:db8::/32 prefix is used > > > > for "documentation purposes" and might be > handled differently by the > > > > TCP/IP stack. > > > > > > Works fine in Linux - I've been using it (in an > isolated training room > > > setup) for years. > > > > > > Regards, K. > > > > It is not a good idea to use the documentation prefix > for anything > > other than documentation.? How hard is it to > generate a ULA and use > > it? > > I suppose I took/take the view that it *is*, in a sense, > being used for > documentation. > > The network is a training network, isolated from the > Internet, and used > for demonstration purposes. It's a good way to engrave the > doco prefix > in the students' minds. It also allows all the slides, > exercises and > other documentation to use the documentation prefix and yet > directly > match the demonstration network. > > ULA prefixes have little internal logic and are hard to > remember. Not a > problem in production, but just another barrier in a > training > environment. "2001:db8::/32" is very easy to remember (I > guess that's > the point) and easy to add easy-to-use subnets into. > > However, I do appreciate that it's a bit of an edge case. > In my training > I specifically draw the students' attention to this fact. > > Thanks, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au)? > ? ? ? ? ? ? ? > ???+61-2-64957160 (h) > http://www.biplane.com.au/kauer/? ? ? > ? ? ? ? ? > ???+61-428-957160 (mob) > > GPG fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED > 5736 F687 > Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B > CD97 0156 > From Valdis.Kletnieks at vt.edu Fri Mar 11 13:21:54 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 11 Mar 2011 14:21:54 -0500 Subject: ipv6 question In-Reply-To: Your message of "Fri, 11 Mar 2011 11:15:36 PST." <735479.99562.qm@web111316.mail.gq1.yahoo.com> References: <735479.99562.qm@web111316.mail.gq1.yahoo.com> Message-ID: <57915.1299871314@localhost> On Fri, 11 Mar 2011 11:15:36 PST, ann kok said: > inet6 addr: fe80::20c:29ff:fe3c:92a1/64 Scope:Link This is a link level address, only valid on one interface. So you need to look at which interface it is attached to in the ifconfig output. > ping6 fe80::20c:29ff:fe3c:92a1 > connect: Invalid argument ping6 wants the interface name for link-scope addresses, because on some hardware setups, the same MAC is used for all interfaces, which means that each interface has the same link-scope address. So to disambiguate it, you have to feed it the interface name so it knows which link to use. On my laptop, I currently have: wlan0 Link encap:Ethernet HWaddr 00:24:D6:53:C5:BA inet6 addr: fe80::224:d6ff:fe53:c5ba/64 Scope:Link % ping fe80::224:d6ff:fe53:c5ba%wlan0 ping6 fe80::224:d6ff:fe53:c5ba%wlan0 PING fe80::224:d6ff:fe53:c5ba%wlan0(fe80::224:d6ff:fe53:c5ba) 56 data bytes 64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=1 ttl=64 time=0.072 ms 64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=2 ttl=255 time=0.081 ms 64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=3 ttl=255 time=0.090 ms ^C --- fe80::224:d6ff:fe53:c5ba%wlan0 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1999ms rtt min/avg/max/mdev = 0.072/0.081/0.090/0.007 ms -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From jsw at inconcepts.biz Fri Mar 11 13:22:51 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 11 Mar 2011 14:22:51 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <49506.1299866835@localhost> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> Message-ID: On Fri, Mar 11, 2011 at 1:07 PM, wrote: > Feel free to explain how SLAAC should work on a /96 with 32 bits of host address > (or any amount smaller than the 48 bits most MAC addresses provide). ?Remember > in your answer to deal with collisions. Why should SLAAC dictate the size of *every subnet* on the IPv6 Internet? This is what people who I label "IPv6 Fundamentalists" wish to do. They refuse to admit that their ideas were conceived in the mid-90s, that technology has advanced a great deal since that time, and ARP/NDP is a real limit now, while VLSM is no longer a tough challenge (vendors have had a couple decades to make it work really well!) I think there are a lot of people who throw around the SLAAC argument like it's actually good for something. Do these people know what SLAAC does? For core networks, it doesn't do anything. For hosting/datacenter networks and cluster/VPS environments, again, it doesn't do anything. Zero benefit. You probably don't configure these things using DHCP today. Wait, you do? Oh, it's a good thing we've got DHCPv6, which clearly can run alongside your DHCP for IPv4. Is SLAAC for end-user access networks? Not so much. See recent discussions on this list about things which are not included in SLAAC that DHCPv6 does do today. SLAAC can provide an advantage if you can live without those things, but that advantage is limited to one thing: the subnet doesn't need a DHCPv6 server (or proxy/forwarding of packets to same.) IPv4 has gotten along just fine for a long time with both full-featured and light-weight DHCP servers, and statically configured subnets. Is SLAAC solving any problem? Sure, for some situations, like SOHO networks, it's a nice option, but it's just that, an option. It isn't needed. Is SLAAC for fully peer-to-peer networks, with no central gateway? No. To function, SLAAC requires an RA message from something that decides it is a router. It isn't going to facilitate a headless, ad-hoc network to support the next revolution with peer-to-peer cell phones. So what we know is that the sole arguments from "IPv6 Fundamentalists" in favor of /64 LANs are * VLSM is hard (it isn't; vendors are really good at it now, otherwise IPv4 wouldn't work) * SLAAC needs it to work (not all LANs need SLAAC) * it's the standard (more on this below) I believe everything except the "it's the standard" argument is fully and completely debunked. If anyone disagrees with me, feel free to correct me, or argue your point until you are blue in the face. I have often been reminded that I should have been more vocal about this matter 10+ years ago, but frankly, I thought vendors, large ISPs, veterans with more public credibility than myself, or the standards folks themselves, would have straightened this out a long time ago. If you can decide for yourself that VLSM is easy and you trust your vendor to do it right (if you don't, summarize to /64 towards your core, or do one great thing IPv6 allows us to do, and summarize to *even shorter* prefixes towards your core, and carry fewer routes in core) then you are half-way there. If you realize SLAAC isn't a tool for your VPS farm or on your backbone link-nets, you're all the way there. At this point, you can deploy your IPv6 without it being broken by design. The only thing broken here is the "Fundamentalists," who are stuck in a mid-1990s mindset. These guys need to get out of the way, because they are impeding deployment (for those smart enough to recognize this problem) and they are creating an almost certain need for a future re-design (for those who aren't smart.) This "future" doesn't depend on anything except v6 actually getting deployed enough to where DDoS happens over it at any appreciable scale. In the current state of the Internet, it is certain that this problem will happen. No visible progress has been made on solving it, except by guys like myself who are happy to cry "the sky is falling," configure our networks in a "non-standard" way, and tell the standards folks they are wrong. The Cisco knob is "progress" only in that Cisco recognizes customers are concerned about this problem and allow them to steer their failure mode. If the DDoS happens before vendors provide a real solution, or before standards are revised or thrown out, you can thank those of us on the "sky is falling" side of this argument for testing the work-around (by never having exposed ourselves to the problem in the first place.) > It's one thing to say "it should be redesigned". It's another matter entirely to actually > come up with a scheme that doesn't suck even harder than "screw it, it's a /64". This is true. I think the price of energy is continuing to rise and our future is very uncertain as a result. I don't know how to fix it. Does that mean I should keep my opinion to myself? Of course not. Recognizing a problem is the first step on the path to a solution. I imagine the same arguments taking place before VLSM and again before CIDR, which pre-dates my entry into this field by a few years. I don't think most people in our field today understand why the IPv6 standard ended up the way it did. They haven't been around long enough to understand the context of IPv6 being developed in what was truly a different era. I don't have a better idea for SLAAC, in large part because I do not care about SLAAC. I don't think SLAAC should dictate the size of *every subnet.* I do think SLAAC should be an *option* available to those who want it on a given LAN. I've got three feasible "fixes" to the NDP flooding problem. One is dead simple: don't configure /64 LANs. How hard is that? It's a lot easier than the alternatives. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From swmike at swm.pp.se Fri Mar 11 13:37:01 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 11 Mar 2011 20:37:01 +0100 (CET) Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> Message-ID: On Fri, 11 Mar 2011, Jeff Wheeler wrote: > I've got three feasible "fixes" to the NDP flooding problem. One is > dead simple: don't configure /64 LANs. How hard is that? It's a lot > easier than the alternatives. What problem are you trying to solve by not having every subnet being a /64 ? -- Mikael Abrahamsson email: swmike at swm.pp.se From bicknell at ufp.org Fri Mar 11 13:55:05 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 11 Mar 2011 11:55:05 -0800 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <20110311185809.GA93069@ussenterprise.ufp.org> References: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> <20110311185809.GA93069@ussenterprise.ufp.org> Message-ID: <20110311195505.GA97129@ussenterprise.ufp.org> In a message written on Fri, Mar 11, 2011 at 10:58:09AM -0800, Leo Bicknell wrote: > That said, ND has built into it DAD - Duplicate Address Detection. > There is already an expectation that there will be collisions, and > the protocols to detect them are already in place. I see little > to no reason you couldn't use a different length subnet (like the > /96 in your example), randomly select an address and do DAD to see > if it is in use. Indeed, this is pretty much how AppleTalk back > in the day worked (with a 16 bit number space). Three people have now mailed me privately saying that DAD does not provide a way to select a second address if your first choice is not in use. What I am basically suggesting is to use the same method in RFC 3041 as the default way to get an address. That is the protocol is already defined and deployed, it's just today it's used for a second (third, fourth, ...) address. -- 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 oiyankok at yahoo.ca Fri Mar 11 14:19:11 2011 From: oiyankok at yahoo.ca (ann kok) Date: Fri, 11 Mar 2011 12:19:11 -0800 (PST) Subject: ipv6 question In-Reply-To: <57915.1299871314@localhost> Message-ID: <908442.89677.qm@web111307.mail.gq1.yahoo.com> Hi Thank you. I try your way. the ipv6 address is on eth0 interface. I try to run ping6 the fe80::20c:29ff:fe3c:92a1%eth0 lt is same problem! Any idea? Thank you 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:0c:29:3c:92:a1 brd ff:ff:ff:ff:ff:ff inet 192.168.1.12/24 brd 192.168.1.255 scope global eth0 inet6 fe80::20c:29ff:fe3c:92a1/64 scope link tentative valid_lft forever preferred_lft forever # ping6 fe80::20c:29ff:fe3c:92a1 connect: Invalid argument # ping6 fe80::20c:29ff:fe3c:92a1%eth0 connect: Invalid argument --- On Fri, 3/11/11, Valdis.Kletnieks at vt.edu wrote: > From: Valdis.Kletnieks at vt.edu > Subject: Re: ipv6 question > To: "ann kok" > Cc: nanog at nanog.org > Received: Friday, March 11, 2011, 2:21 PM > On Fri, 11 Mar 2011 11:15:36 PST, ann > kok said: > > > inet6 addr: fe80::20c:29ff:fe3c:92a1/64 Scope:Link > > This is a link level address, only valid on one > interface.? So you need to look > at which interface it is attached to in the ifconfig > output. > > > ping6 fe80::20c:29ff:fe3c:92a1 > > connect: Invalid argument > > ping6 wants the interface name for link-scope addresses, > because on some > hardware setups, the same MAC is used for all interfaces, > which means that > each interface has the same link-scope address.? So to > disambiguate it, > you have to feed it the interface name so it knows which > link to use. > > On my laptop, I currently have: > > wlan0? ???Link encap:Ethernet? > HWaddr 00:24:D6:53:C5:BA > ??? inet6 addr: fe80::224:d6ff:fe53:c5ba/64 > Scope:Link > > % ping? fe80::224:d6ff:fe53:c5ba%wlan0 > ping6? fe80::224:d6ff:fe53:c5ba%wlan0 > PING > fe80::224:d6ff:fe53:c5ba%wlan0(fe80::224:d6ff:fe53:c5ba) 56 > data bytes > 64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=1 ttl=64 > time=0.072 ms > 64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=2 ttl=255 > time=0.081 ms > 64 bytes from fe80::224:d6ff:fe53:c5ba: icmp_seq=3 ttl=255 > time=0.090 ms > ^C > --- fe80::224:d6ff:fe53:c5ba%wlan0 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time > 1999ms > rtt min/avg/max/mdev = 0.072/0.081/0.090/0.007 ms > > From ras at e-gerbil.net Fri Mar 11 14:27:32 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 11 Mar 2011 14:27:32 -0600 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <20110311185541.2C618A009@h-mailbag-msp-1.msp-coloc.binc.net> References: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <49E4FB94-3D1B-476B-89C4-78155EDF2749@delong.com> <7EAB7486-5CE6-4D3A-8A78-0CB8B48879D9@arbor.net> <42AD349D-432A-42C1-8EEC-4573203766C4@delong.com> <20110311185541.2C618A009@h-mailbag-msp-1.msp-coloc.binc.net> Message-ID: <20110311202732.GY68199@gerbil.cluepon.net> On Fri, Mar 11, 2011 at 12:55:33PM -0600, James Stahr wrote: > link-local address. Then I realized, why even assign a global in the > first place? Traceroutes replies end up using the loopback. BGP will > use loopbacks. So is there any obvious harm in this approach that I'm > missing? Traceroute replies most assuredly do NOT use loopbacks on most networks, and it would make troubleshooting massively more difficult if this was the only option. Imagine any kind of complex network where there is more than one link between a pair of routers (and don't just picture your own internal network, but imagine customers connecting to their ISPs as well) , and now tell me how you plan on identifying a particular link with a traceroute. The two words that best sum this up would be "epic disaster". -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jason at i6ix.com Fri Mar 11 14:31:35 2011 From: jason at i6ix.com (Jason Bertoch) Date: Fri, 11 Mar 2011 15:31:35 -0500 Subject: ipv6 question In-Reply-To: <908442.89677.qm@web111307.mail.gq1.yahoo.com> References: <908442.89677.qm@web111307.mail.gq1.yahoo.com> Message-ID: <4D7A86A7.80803@i6ix.com> On 2011/03/11 3:19 PM, ann kok wrote: > Thank you. I try your way. the ipv6 address is on eth0 interface. > > I try to run ping6 the fe80::20c:29ff:fe3c:92a1%eth0 > > lt is same problem! Try ping6 -I eth0 fe80::20c:29ff:fe3c:92a1 -- /Jason From oiyankok at yahoo.ca Fri Mar 11 14:36:43 2011 From: oiyankok at yahoo.ca (ann kok) Date: Fri, 11 Mar 2011 12:36:43 -0800 (PST) Subject: ipv6 question In-Reply-To: <4D7A86A7.80803@i6ix.com> Message-ID: <341901.90105.qm@web111309.mail.gq1.yahoo.com> Hi What is this meaning? ping6 -l eth0 fe80::20c:29ff:fe3c:92a1 ping: bad preload value, should be 1..65536 Thank you --- On Fri, 3/11/11, Jason Bertoch wrote: > From: Jason Bertoch > Subject: Re: ipv6 question > To: nanog at nanog.org > Received: Friday, March 11, 2011, 3:31 PM > On 2011/03/11 3:19 PM, ann kok > wrote: > > Thank you. I try your way.? the ipv6 address is > on eth0 interface. > > > > I try to run ping6 the fe80::20c:29ff:fe3c:92a1%eth0 > > > > lt is same problem! > > Try ping6 -I eth0 fe80::20c:29ff:fe3c:92a1 > > -- > /Jason > > From ramdas.pophale at gmail.com Fri Mar 11 14:38:11 2011 From: ramdas.pophale at gmail.com (Ramdas Pophale) Date: Fri, 11 Mar 2011 14:38:11 -0600 Subject: Data request Message-ID: Dear all, I am looking for some data to do network analysis for a research project. For a small network.. 1. topology related data between different nodes of a network such as obtained from traceroute probes 2. attack data for the same network, could be non-specific scanning or DDOS and such 3. performance related data for the same network. Latency information may be. I would have liked to have the data for a couple of networks (~100 to ~1000 nodes) over a six month period. It's alright if the IP addresses are anonymized. Hopefully, this clarifies the requirements. I would have imagined that a network administrator would have access to such data. If someone is willing to share/sell it, that would be great. Any suggestions on the matter would be appreciated. Thanks for your time. Regards, Ramdas. From jason at i6ix.com Fri Mar 11 14:41:37 2011 From: jason at i6ix.com (Jason Bertoch) Date: Fri, 11 Mar 2011 15:41:37 -0500 Subject: ipv6 question In-Reply-To: <341901.90105.qm@web111309.mail.gq1.yahoo.com> References: <341901.90105.qm@web111309.mail.gq1.yahoo.com> Message-ID: <4D7A8901.8090107@i6ix.com> On 2011/03/11 3:36 PM, ann kok wrote: > What is this meaning? > > ping6 -l eth0 fe80::20c:29ff:fe3c:92a1 > ping: bad preload value, should be 1..65536 That was a capital "i" not a lower case "L". man ping6 -- /Jason From oiyankok at yahoo.ca Fri Mar 11 14:51:23 2011 From: oiyankok at yahoo.ca (ann kok) Date: Fri, 11 Mar 2011 12:51:23 -0800 (PST) Subject: ipv6 question In-Reply-To: <4D7A8901.8090107@i6ix.com> Message-ID: <20958.43165.qm@web111304.mail.gq1.yahoo.com> Hi Jason Thank you. Can I know what is wrong? ping6 -I eth0 fe80::20c:29ff:fe3c:92a1 connect: Cannot assign requested address Thank you --- On Fri, 3/11/11, Jason Bertoch wrote: > From: Jason Bertoch > Subject: Re: ipv6 question > To: nanog at nanog.org > Received: Friday, March 11, 2011, 3:41 PM > On 2011/03/11 3:36 PM, ann kok > wrote: > > What is this meaning? > > > > ping6 -l eth0 fe80::20c:29ff:fe3c:92a1 > > ping: bad preload value, should be 1..65536 > > That was a capital "i" not a lower case "L". man ping6 > -- > /Jason > > From nick at foobar.org Fri Mar 11 15:00:52 2011 From: nick at foobar.org (Nick Hilliard) Date: Fri, 11 Mar 2011 21:00:52 +0000 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> Message-ID: <4D7A8D84.50803@foobar.org> On 11/03/2011 19:37, Mikael Abrahamsson wrote: > What problem are you trying to solve by not having every subnet being a > /64 ? nd cache exhaustion? Personally, I'm rather concerned about this, and you should be too, given the overlapping spheres of our interests. Particularly as there is no DAI equivalent for ipv6 on any switch vendor roadmap that i've seen. Nick From jmaimon at ttec.com Fri Mar 11 15:05:30 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 11 Mar 2011 16:05:30 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <20110311195505.GA97129@ussenterprise.ufp.org> References: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> <20110311185809.GA93069@ussenterprise.ufp.org> <20110311195505.GA97129@ussenterprise.ufp.org> Message-ID: <4D7A8E9A.7010409@ttec.com> Leo Bicknell wrote: > Three people have now mailed me privately saying that DAD does not > provide a way to select a second address if your first choice is not > in use. So fix that as well while we are at it, how bout it? Its code, not stone. From pete at altadena.net Fri Mar 11 15:16:08 2011 From: pete at altadena.net (Pete Carah) Date: Fri, 11 Mar 2011 16:16:08 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <4D7A8E9A.7010409@ttec.com> References: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> <20110311185809.GA93069@ussenterprise.ufp.org> <20110311195505.GA97129@ussenterprise.ufp.org> <4D7A8E9A.7010409@ttec.com> Message-ID: <4D7A9118.7060701@altadena.net> On 03/11/2011 04:05 PM, Joe Maimon wrote: > > > Leo Bicknell wrote: > >> Three people have now mailed me privately saying that DAD does not >> provide a way to select a second address if your first choice is not >> in use. > > So fix that as well while we are at it, how bout it? Its code, not stone. So it is simple, use privacy (3041) addresses scaled appropriately for the appropriate netmask... remember the last D in DAD is detection; what you do about it is in another protocol. -- Pete > > > > From jason at i6ix.com Fri Mar 11 15:22:27 2011 From: jason at i6ix.com (Jason Bertoch) Date: Fri, 11 Mar 2011 16:22:27 -0500 Subject: ipv6 question In-Reply-To: <20958.43165.qm@web111304.mail.gq1.yahoo.com> References: <20958.43165.qm@web111304.mail.gq1.yahoo.com> Message-ID: <4D7A9293.8050503@i6ix.com> On 2011/03/11 3:51 PM, ann kok wrote: > ping6 -I eth0 fe80::20c:29ff:fe3c:92a1 > connect: Cannot assign requested address Maybe duplicate address detection? Are you statically assigning this address? Have you checked your kernel log? -- /Jason From cidr-report at potaroo.net Fri Mar 11 16:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Mar 2011 22:00:02 GMT Subject: BGP Update Report Message-ID: <201103112200.p2BM02gb089222@wattle.apnic.net> BGP Update Report Interval: 03-Mar-11 -to- 10-Mar-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS45595 23891 1.5% 66.2 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 2 - AS23966 23516 1.5% 70.4 -- LDN-AS-PK LINKdotNET Telecom Limited 3 - AS26210 23379 1.4% 135.9 -- AXS Bolivia S. A. 4 - AS32528 17323 1.1% 2165.4 -- ABBOTT Abbot Labs 5 - AS6713 15863 1.0% 27.1 -- IAM-AS 6 - AS9829 15212 0.9% 15.2 -- BSNL-NIB National Internet Backbone 7 - AS35931 12715 0.8% 2119.2 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - AS24560 11343 0.7% 10.0 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 9 - AS17974 11294 0.7% 7.9 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 10 - AS9498 11141 0.7% 14.3 -- BBIL-AP BHARTI Airtel Ltd. 11 - AS14420 10784 0.7% 16.7 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 12 - AS8402 10706 0.7% 6.0 -- CORBINA-AS Corbina Telecom 13 - AS25220 9517 0.6% 732.1 -- GLOBALNOC-AS Averbo GmbH 14 - AS17488 8066 0.5% 8.5 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 15 - AS7491 7756 0.5% 84.3 -- PI-PH-AS-AP PI-PHILIPINES 16 - AS8452 7575 0.5% 8.6 -- TE-AS TE-AS 17 - AS5800 7144 0.4% 30.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 18 - AS19743 7017 0.4% 1002.4 -- 19 - AS23696 6959 0.4% 869.9 -- FIRSTASIANET-AS-ID PT Asia Utama. 20 - AS210 6885 0.4% 5.1 -- WEST-NET-WEST - Utah Education Network TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 17323 1.1% 2165.4 -- ABBOTT Abbot Labs 2 - AS35931 12715 0.8% 2119.2 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 3 - AS17874 2013 0.1% 2013.0 -- NPC-AS-KR National Pension Corporation 4 - AS49600 1246 0.1% 1246.0 -- LASEDA La Seda de Barcelona, S.A 5 - AS19743 7017 0.4% 1002.4 -- 6 - AS10198 1820 0.1% 910.0 -- CUP-AS-KR Catholic University of Pusan 7 - AS23696 6959 0.4% 869.9 -- FIRSTASIANET-AS-ID PT Asia Utama. 8 - AS35870 850 0.1% 850.0 -- PHI-CCR-BACKBONE - Public Health Institute California Cancer Registry 9 - AS25220 9517 0.6% 732.1 -- GLOBALNOC-AS Averbo GmbH 10 - AS28519 2042 0.1% 680.7 -- Universidad Autonoma de Guadalajara, A.C. 11 - AS22288 538 0.0% 538.0 -- RFBKCORP - Republic First Bancorp, Inc. 12 - AS36591 371 0.0% 371.0 -- PRT - PixelRiver 13 - AS40607 364 0.0% 364.0 -- HCPL-7-ASN - HALL CAPITAL PARTNERS, LLC 14 - AS46167 361 0.0% 361.0 -- LANDSERVICESUSA - Land Services USA, Inc 15 - AS48377 322 0.0% 322.0 -- CEB-AS Credit Europe Bank Ukraine OOO 16 - AS42292 308 0.0% 308.0 -- CREDITWESTBANK CJSC "CREDITWEST BANK" 17 - AS38757 584 0.0% 292.0 -- ICONPLN-ID-AP PT. Indonesia Comnets Plus 18 - AS39348 584 0.0% 292.0 -- TYACHIV-AS Initiativa Ltd. 19 - AS52260 1668 0.1% 278.0 -- T?l?communications de Hait? (Teleco) 20 - AS27771 541 0.0% 270.5 -- Instituto Venezolano de Investigaciones Cientificas TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 85.197.100.0/22 9504 0.6% AS25220 -- GLOBALNOC-AS Averbo GmbH 2 - 130.36.34.0/24 8658 0.5% AS32528 -- ABBOTT Abbot Labs 3 - 130.36.35.0/24 8658 0.5% AS32528 -- ABBOTT Abbot Labs 4 - 63.211.68.0/22 8316 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - 202.92.235.0/24 7485 0.4% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 6 - 221.121.96.0/19 4999 0.3% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 7 - 198.140.43.0/24 4095 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 203.192.205.0/24 3687 0.2% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd. AS9498 -- BBIL-AP BHARTI Airtel Ltd. 9 - 68.65.152.0/22 3443 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 10 - 206.184.16.0/24 3186 0.2% AS174 -- COGENT Cogent/PSI 11 - 202.153.174.0/24 3017 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 12 - 208.54.82.0/24 2421 0.1% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 13 - 211.173.99.0/24 2013 0.1% AS17874 -- NPC-AS-KR National Pension Corporation 14 - 204.154.140.0/24 1757 0.1% AS5050 -- PSC-EXT - Pittsburgh Supercomputing Center AS7018 -- ATT-INTERNET4 - AT&T Services, Inc. 15 - 65.122.196.0/24 1383 0.1% AS19743 -- 16 - 190.15.7.128/25 1307 0.1% AS27817 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA 17 - 213.170.59.0/24 1246 0.1% AS49600 -- LASEDA La Seda de Barcelona, S.A 18 - 41.189.225.0/24 1242 0.1% AS30990 -- ADJIB-AS 19 - 65.162.204.0/24 1127 0.1% AS19743 -- 20 - 65.163.182.0/24 1127 0.1% AS19743 -- Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 11 16:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 11 Mar 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201103112200.p2BM00DZ089217@wattle.apnic.net> This report has been generated at Fri Mar 11 21:11:52 2011 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 04-03-11 350670 205614 05-03-11 351328 205558 06-03-11 351081 205642 07-03-11 351367 205780 08-03-11 351530 205762 09-03-11 351488 205962 10-03-11 351724 206002 11-03-11 351885 205736 AS Summary 36986 Number of ASes in routing system 15565 Number of ASes announcing only one prefix 3680 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 108914944 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'). --- 11Mar11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 352175 205734 146441 41.6% All ASes AS6389 3680 264 3416 92.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2575 407 2168 84.2% TWTC - tw telecom holdings, inc. AS19262 1830 282 1548 84.6% VZGNI-TRANSIT - Verizon Online LLC AS4766 2421 911 1510 62.4% KIXS-AS-KR Korea Telecom AS6478 1538 204 1334 86.7% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1281 89 1192 93.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS10620 1384 208 1176 85.0% Telmex Colombia S.A. AS4755 1475 374 1101 74.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS1785 1795 764 1031 57.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1237 316 921 74.5% NET Servicos de Comunicao S.A. AS18566 1524 613 911 59.8% COVAD - Covad Communications Co. AS7545 1594 728 866 54.3% TPG-INTERNET-AP TPG Internet Pty Ltd AS24560 1120 281 839 74.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS18101 935 154 781 83.5% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS6503 1183 428 755 63.8% Axtel, S.A.B. de C.V. AS4808 1050 323 727 69.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 919 195 724 78.8% Telecom Argentina S.A. AS3356 1182 490 692 58.5% LEVEL3 Level 3 Communications AS8151 1243 562 681 54.8% Uninet S.A. de C.V. AS11492 1311 631 680 51.9% CABLEONE - CABLE ONE, INC. AS17488 944 272 672 71.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4780 864 229 635 73.5% SEEDNET Digital United Inc. AS17676 657 70 587 89.3% GIGAINFRA Softbank BB Corp. AS855 636 58 578 90.9% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17908 623 67 556 89.2% TCISL Tata Communications AS14420 644 104 540 83.9% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22561 861 325 536 62.3% DIGITAL-TELEPORT - Digital Teleport Inc. AS3549 900 370 530 58.9% GBLX Global Crossing Ltd. AS7552 620 101 519 83.7% VIETEL-AS-AP Vietel Corporation AS9498 773 262 511 66.1% BBIL-AP BHARTI Airtel Ltd. Total 38799 10082 28717 74.0% Top 30 total Possible Bogus Routes 1.5.0.0/16 AS38639 HANABI NTT Communications Corporation 1.6.0.0/15 AS38639 HANABI NTT Communications Corporation 1.8.0.0/16 AS38639 HANABI NTT Communications Corporation 1.20.0.0/16 AS38639 HANABI NTT Communications Corporation 1.32.0.0/16 AS38639 HANABI NTT Communications Corporation 1.37.0.0/16 AS38639 HANABI NTT Communications Corporation 1.187.0.0/16 AS38639 HANABI NTT Communications Corporation 1.200.0.0/20 AS38639 HANABI NTT Communications Corporation 14.0.0.0/24 AS38639 HANABI NTT Communications Corporation 14.0.1.0/24 AS38639 HANABI NTT Communications Corporation 14.0.2.0/23 AS38639 HANABI NTT Communications Corporation 14.0.4.0/24 AS38639 HANABI NTT Communications Corporation 14.0.15.0/24 AS38639 HANABI NTT Communications Corporation 14.1.0.0/24 AS38639 HANABI NTT Communications Corporation 14.102.128.0/23 AS38639 HANABI NTT Communications Corporation 14.192.76.0/24 AS38639 HANABI NTT Communications Corporation 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 36.0.0.0/24 AS38639 HANABI NTT Communications Corporation 36.0.1.0/24 AS38639 HANABI NTT Communications Corporation 36.50.0.0/20 AS38639 HANABI NTT Communications Corporation 36.255.0.0/16 AS38639 HANABI NTT Communications Corporation 41.57.192.0/18 AS22750 BCSNET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 42.0.0.0/24 AS38639 HANABI NTT Communications Corporation 42.0.1.0/24 AS38639 HANABI NTT Communications Corporation 42.0.25.0/24 AS38639 HANABI NTT Communications Corporation 42.1.56.0/23 AS38639 HANABI NTT Communications Corporation 42.50.0.0/20 AS38639 HANABI NTT Communications Corporation 42.62.181.0/24 AS38639 HANABI NTT Communications Corporation 42.83.80.0/24 AS38639 HANABI NTT Communications Corporation 42.96.111.0/24 AS38639 HANABI NTT Communications Corporation 42.99.114.0/24 AS38639 HANABI NTT Communications Corporation 42.123.39.0/24 AS38639 HANABI NTT Communications Corporation 42.156.39.0/24 AS38639 HANABI NTT Communications Corporation 42.187.123.0/24 AS38639 HANABI NTT Communications Corporation 42.194.10.0/24 AS38639 HANABI NTT Communications Corporation 42.201.36.0/24 AS38639 HANABI NTT Communications Corporation 42.240.51.0/24 AS38639 HANABI NTT Communications Corporation 42.255.0.0/16 AS38639 HANABI NTT Communications Corporation 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 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.207.192.0/24 AS30304 64.207.193.0/24 AS30304 64.207.194.0/24 AS30304 64.207.195.0/24 AS30304 64.207.196.0/24 AS30304 64.207.197.0/24 AS30304 64.207.198.0/24 AS30304 64.207.200.0/24 AS30304 64.207.201.0/24 AS30304 64.207.202.0/24 AS30304 64.207.203.0/24 AS30304 64.207.204.0/24 AS30304 64.207.205.0/24 AS30304 64.207.206.0/24 AS30304 64.207.208.0/20 AS30304 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 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 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 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 101.1.1.0/24 AS38639 HANABI NTT Communications Corporation 101.2.173.0/24 AS38639 HANABI NTT Communications Corporation 101.50.56.0/24 AS38639 HANABI NTT Communications Corporation 101.53.100.0/24 AS38639 HANABI NTT Communications Corporation 101.55.225.0/24 AS38639 HANABI NTT Communications Corporation 101.78.2.0/24 AS38639 HANABI NTT Communications Corporation 101.96.8.0/24 AS38639 HANABI NTT Communications Corporation 101.99.97.0/24 AS38639 HANABI NTT Communications Corporation 101.99.100.0/24 AS38639 HANABI NTT Communications Corporation 101.110.116.0/24 AS38639 HANABI NTT Communications Corporation 101.203.172.0/24 AS38639 HANABI NTT Communications Corporation 101.234.78.0/24 AS38639 HANABI NTT Communications Corporation 101.251.0.0/24 AS38639 HANABI NTT Communications Corporation 102.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 103.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 104.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 110.34.44.0/22 AS12653 COMTONET KB Impuls Hellas 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 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.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 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 172.33.69.0/24 AS36992 ETISALAT-MISR 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 179.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 185.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 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.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 G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - 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.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 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 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 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.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - 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.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. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 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.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.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 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.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.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.131.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.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 INTERNODE-AS Internode Pty Ltd 203.30.26.0/23 AS3491 BTN-ASN - Beyond The Network America, Inc. 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone 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 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 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 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 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.105.192.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.196.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.200.0/21 AS7385 INTEGRATELECOM - Integra Telecom, 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.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 223.0.0.0/15 AS38639 HANABI NTT Communications Corporation 223.223.223.0/24 AS38639 HANABI NTT Communications Corporation Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jkrejci at usinternet.com Fri Mar 11 17:39:21 2011 From: jkrejci at usinternet.com (Justin Krejci) Date: Fri, 11 Mar 2011 17:39:21 -0600 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> Message-ID: <1299886761.16616.22.camel@sysadmin3a> On Wed, 2011-03-09 at 09:32 -0500, John Curran wrote: > On Mar 9, 2011, at 12:43 AM, Majdi S. Abbas wrote: > > On Wed, Mar 09, 2011 at 12:44:05PM +0900, Randy Bush wrote: > >> i am more of a pessimist. i suspect that there will be enough v4-only > >> destinations out there that multi-homed enterprises fronting onto > >> dual-stack backbones will announce teenie bits of v4 so they can nat64. > > > > I'll take this one a little further. > > > > I suspect that as we reach exhaustion, more people will be > > forced to break space out of their provider's v4 aggregates, and > > announce them, and an unfiltered DFZ may well approach the 'million' > > entries some vendors now claim to support. > > This matches my personal view (and could be viewed as > "success" compared to the 5M estimate of Mr. Herrin...) > > /John Are people going to be relying on using default-routing then in the future if they don't upgrade routers to handle large routing table growth? Or perhaps forgo dual-stack and have a separate physical IPv6 BGP network from IPv4? Are there any other strategies? From owen at delong.com Fri Mar 11 17:33:42 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Mar 2011 15:33:42 -0800 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> Message-ID: <7E27F319-7736-41F5-AD4D-3E5C1A67A41A@delong.com> On Mar 11, 2011, at 5:53 AM, Jeff Wheeler wrote: > On Thu, Mar 10, 2011 at 10:51 PM, George Bonser wrote: >> And I say making them /127s may not really make any difference. Say you >> make all of those /127s, at some point you *are* going to have a network >> someplace that is a /64 that has hosts on it and that one is just as >> subject to such an attack. If you are a content provider, it doesn't >> make any difference if they take down the links between your routers or >> if they take down the link that your content farm is on. The end result >> is the same. You have managed to re-arrange the deck chairs. Have >> another squeeze at that water balloon. > > Again, this is the argument put forth by the "RFC wavers," that you > can't solve the problem because you must want to configure /64s for > ... what, exactly? Oh, right, SLAAC. More on that below. > > If I'm a content provider, I don't have to configure a /64 for my > content farm. I can configure a /120 or whatever subnet size is > practical for my environment. I can also use link-local addressing on > my content farm LANs and route subnets to my content boxes, if that is > somehow more practical than using a smaller subnet. > Yes, you can bring as much of the pain from IPv4 forward into IPv6 as you like. You can also commit many other acts of masochism. Personally, I prefer to approach IPv6 as a way to reduce some of the more painful aspects of IPv4, such as undersized subnets, having to renumber or add prefixes for growth, limited aggregation, NAT, and more. >> If you are a service provider where practically all of your links are >> point to points, sure. > > No, you can avoid configuring /64s if you don't need SLAAC. Who needs > SLAAC? I don't. It has absolutely no place in any of my > environments. It seems to me that DHCPv6 will do everything which > SLAAC does, and everything SLAAC forgot about. The "complexity" > argument is pretty much indefensible when the trade-off is configuring > DHCPv6 vs turning a bunch of router knobs and hoping no one ever > targets your LANs with an NDP DoS. > SLAAC is a very useful and convenient way to deal with client networks. I would agree it's of limited use in a content provider scenario, but, there is utility to /64s beyond just SLAAC. Yes, they are a hard requirement for SLAAC. >> We didn't need much more host addressing, we needed more subnet >> addressing. I would have settled for 16 bits of host addressing and 112 >> bits of subnet addressing and I suppose nothing prevents me from doing >> that except none of the standard IPv6 automatic stuff would work >> anymore. > > None of that "standard IPv6 automatic stuff" works today, anyway. The > state of IPv6 support on end-user CPE generally ranges from > non-existent to untested to verified-to-be-broken. This is the only > place in your network where /64 can offer any value, and currently, > CPE is just not there. Even the latest Cisco/Linksys CPE does not > support IPv6. Sure, that'll change; but what won't change is the > total lack of any basis for configuring /64 LANs for "content farms" > or any similar non-end-user, non-dynamic segments. > As someone using SLAAC in a number of environments, I'm confused by this statement. It seems to be working quite well in many places and end-user residential networks are certainly not the only places where it is useful. Yes, residential end-user CPE is rather limited and somewhat less than ideal today. I would argue that there are probably at least as many end-user hosts on non-residential networks that could take advantage of SLAAC if the administrators wanted to. > I don't want 16 bits of host addressing. I want to choose an > appropriate size for each subnet. Why? Because exactly zero of my > access routers can handle 2**16 NDP entries, let alone 2**16 entries > on multiple interfaces/VLANs. I would like to see much larger ARP/NDP > tables in layer-3 switches, and I think vendors will deliver on that, > but I doubt we'll soon see even a 10x increase from typical table > sizes of today. VPS farms are already pushing the envelope with IPv4, > where customers are already used to conserving addresses. Guess what, > customers may still have to conserve addresses with IPv6, not because > the numbers themselves are precious, but because the number of ARP/NDP > entries in the top-of-rack or distribution switch is finite. > What do your access routers have to do with your content farm? Sounds like you've got some pretty darn small access routers as well if they can't handle 64k NDP entries. Yes, larger tables in switches would be a good thing, but, I hardly think that's a reason to use smaller netmasks. Most of the top-of-rack switches I'm aware of have no problem doing at least 64k NDP/ARP entries. Many won't do more than that, but, most will go at least that far. >> And again, are you talking about all the way down to the host subnet >> level? I suppose I could configure server farms in /112 or even /96 >> (/96 has some appeal for other reasons mostly having to do with >> multicast) but then I would wonder how many bugs that would flush out of >> OS v6 stacks. > > I'm not getting reports of problems with smaller-than-/64 subnets from > customers yet. Am I confident that I never will? No, absolutely not! > Like almost everyone else, I have some customers who have configured > IPv6, but the amount of production traffic on it remains trivial. > That is why I allocate a /64 but provision a /120 (or similar > practical size.) I can grow the subnet if I have to. I do know that > /64 LANs will cause me DoS problems, so I choose to work around that > problem now. If /120 LANs cause me OS headaches in the future, I have > the option to revise my choice with minimal effort (no services get > renumbered, only the subnet must grow.) > How many customers are using smaller-than-/64 subnets to do much of anything yet? I find it interesting that you _KNOW_ that /64 LANs will cause you DoS problems and yet we've been running them for years without incident. I believe growing the subnet still requires you to touch every machine unless they're getting all their configuration from DHCP. Again, sounds like an exercise in unnecessary masochism to me. > Why would you suggest /96 as being more practical than /64 from the > perspective of NDP DoS? Again, this is an example of the "in-between" > folks in these arguments, who seem not to fully understand the > problem. Your routers do not have room for 2**(128-96) NDP entries. > Typical access switches today have room for a few thousand to perhaps > 16k, and typical "bigger" switches are specifying figures below 100k. > This doesn't approach the 4.3M addresses in a /96. In short, > suggesting /96 is flat out stupid -- you get "the worst of both > worlds," potential for OS compatibility issues, AND guaranteed NDP DoS > vulnerability. > Yeah, in-between makes little sense. Kind of worst of both worlds. On that we can at least agree. As to your /96, that's 4.3B, not 4.3M. (at least last I looked, 2^32 was 4.3B and 4.3M was approximately a /114). >> passing traffic. That doesn't protect against rogue hosts but there >> might be ways around that, too, or at least limiting the damage a rogue >> host can cause. > > How do you suggest we limit the damage a rogue host can cause? A lot > of people would like to hear your idea. Again, in nearly ten years of > discussing this with colleagues, I have not seen any idea which is > more practical than configuring a /120 instead of a /64. I have not > seen any idea, period, which doesn't involve configuring the IPs which > are allowed to be used on the LAN, either on the access switch port > (NDP inspection), the access router, or in a database (like RADIUS.) > There are several things that could eventually be implemented in the access switch software. Techniques like rapidly timing out unanswered NDP requests, not storing ND entries for SLAAC MAC-based suffixes (after all, the information you need is already in the IP address, just use that). Not storing ND entries for things that don't have an entry in the MAC forwarding table (pass the first ND packet and if you get a response, create the ND entry at that time), etc. Yes, these all involve a certain amount of changing some expected behaviors, but, those changes could probably be easily accommodated in most environments. Finally, the bottom line is that a rogue host behind your firewall is probably going to cause other forms of damage well before it runs you out of ND entries and any time you have such a thing, it's going to be pretty vital to identify and remove it as fast as possible anyway. > > I'm glad SLAAC is an option, but that's all it is, an option. /64 > LANs must also be considered optional, and should be considered useful > only when SLAAC is desired. > They are entirely optional, but, IMHO, avoiding them at all costs such as you seem to be suggesting is unnecessarily painful in most environments. >> Something will have to be done at some point ... soon. > > I'm glad more people are coming around to this point of view. Cisco > certainly is there. I'd settle for Cisco coming to the point of having RA guard universally available on all switch products. That, to me, is a much more pressing issue than this imagined ND exhaustion attack which, in reality, requires near DDOS levels of traffic for most networks to actually run the ND table meaningfully into overflow. Owen From owen at delong.com Fri Mar 11 17:34:39 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Mar 2011 15:34:39 -0800 Subject: so big earthquake in JP In-Reply-To: <415ECF6B-E6A6-4C4B-A4D7-15C2E98E30B0@ianai.net> References: <20110311145954.2707.9C4C12A4@nttv6.jp> <6991C2BD-4175-4409-8DB1-71FFDE58059B@asgaard.org> <4D79E261.8050404@mompl.net> <1C66D369-2C5A-447B-834E-E3DC9B180212@gmail.com> <415ECF6B-E6A6-4C4B-A4D7-15C2E98E30B0@ianai.net> Message-ID: On Mar 11, 2011, at 6:11 AM, Patrick W. Gilmore wrote: > On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote: > >> Are we aware of how much the infrastructure has been damaged yet? Are aftershocks still going? > > Subway & bus lines are still down. Fire at the nuke plant has been put out, no radiation detected, but they still evacuated a couple thousand residents because the backup generator failed & the water pump is not pumping. > I hear that there is now rising radiation levels outside the plant and US is flying in some dampers in hopes to resolve the situation. Owen From owen at delong.com Fri Mar 11 17:48:25 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Mar 2011 15:48:25 -0800 Subject: Long Distance Dark Fiber In-Reply-To: <4D7A44D1.3030609@bogus.com> References: <3c53efc09fb96ffb77934bc5dbe1e475@feltonline.com> <4D7A30DC.7010502@kenweb.org> <4D7A44D1.3030609@bogus.com> Message-ID: <11DF6F66-C934-4C17-BF46-377DFE26A9BE@delong.com> On Mar 11, 2011, at 7:50 AM, Joel Jaeggli wrote: > On 3/11/11 7:16 AM, Jeff Wheeler wrote: >> On Fri, Mar 11, 2011 at 9:25 AM, ML wrote: >>> Would it be too crazy to buy a spool of fiber and splice the end of one pair >>> to the next pair and so on? Won't be able to simulate 2200 miles of fiber >>> but it'll be a long span. >> >> This is by no means crazy. If you visit a laboratory where gear is >> tested, you'll find exactly that -- spools of fiber which can be >> connected together (through whatever splicing or patching method is >> desired for the simulation) to give the desired span length. These >> usually look nicer than big spools of cable, and are even available in >> rack-mount enclosures with vendor logos. :) > > one does not however do 2200 miles of terrestrial fiber simulation > without simulating regeneration as well. > > You can, but, it requires electronic retiming of the fiber signal (fiber->ring buffer->configurable delay->fiber). I guess technically that simulates one iteration of regeneration to some extent, but, it certainly wouldn't represent a test of 2200 miles worth of analog regeneration of a digital signal. Owen From simagami at gmail.com Fri Mar 11 17:53:29 2011 From: simagami at gmail.com (Junichi Shimagami) Date: Sat, 12 Mar 2011 08:53:29 +0900 Subject: so big earthquake in JP In-Reply-To: <20110311143702.GH54705@blackrose.org> References: <10221EDF-DD32-40E8-A20E-E839682E9595@americafree.tv> <20110311143702.GH54705@blackrose.org> Message-ID: Hello all, The situation is still quite bad in north eastern area of Honshu island where Sendai resides. In Tokyo, we still have frequent aftershocks, but it's getting back to normal gradually. As of connectivity from Japan to overseas, IIJ is seeing several international circuits going down. Several cables, not only trans pacific but also intra Asian, seems to be affected by the earthquake offshore of Japan. You may encounter some congestion not only to Japan but also to Asia. Thanks for you support. Sincerely, Junichi Shimagami Internet Initiative Japan Inc. from Tokyo 2011/3/11 Dorian Kim : > On Fri, Mar 11, 2011 at 07:29:29AM -0700, Garret Picchioni wrote: >> Does anyone have any stats on route updates that might suggest the >> possibility of fiber on the ocean floor being damaged? > > There are some submarine cable outages but I don't believe exact > locations of damage has been isolated. I suspect that this may take > some time. > > -dorian > > From owen at delong.com Fri Mar 11 18:13:13 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Mar 2011 16:13:13 -0800 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <20110311185809.GA93069@ussenterprise.ufp.org> References: <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> <20110311185809.GA93069@ussenterprise.ufp.org> Message-ID: On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: > In a message written on Fri, Mar 11, 2011 at 01:07:15PM -0500, Valdis.Kletnieks at vt.edu wrote: >> On Fri, 11 Mar 2011 09:38:12 EST, Joe Maimon said: >>> rfc3927 does not require 64 bits and works sufficiently well wherever it >>> is employed. SLAAC should be redesigned to be configurable to work with >>> however many bits are available to it and it should be a standard >>> feature to turn that knob all the way from on - off with 128 bit stops >>> in between. >> >> Feel free to explain how SLAAC should work on a /96 with 32 bits of host address >> (or any amount smaller than the 48 bits most MAC addresses provide). Remember >> in your answer to deal with collisions. > > Well, I at least think an option should be a /80, using the 48 bits > of MAC directly. This generates exactly the same collision potential > as today we have with a /64 and an EUI-64 constructed from an EUI-48 > ethernet address. The router is already sending RA's for SLAAC to > work, sending along one of a well-known set of masks would be a > relatively minor modification. > How would you use that on a Firewire netowrk or FDDI or any of the other media that uses 64-bit MAC addresses? > That said, ND has built into it DAD - Duplicate Address Detection. > There is already an expectation that there will be collisions, and > the protocols to detect them are already in place. I see little > to no reason you couldn't use a different length subnet (like the > /96 in your example), randomly select an address and do DAD to see > if it is in use. Indeed, this is pretty much how AppleTalk back > in the day worked (with a 16 bit number space). > Detect, yes. Mitigate, no. DAD on the link-local results in Interface shutdown. In an environment where there's a very low probability of collision, that's an acceptable risk that is easily mitigated in most cases. In an environment where you create a much higher risk of collision, such as 1/2^32 or less, vs. 1/2^48 or more, I think that's a rather ill advised approach. > The probability of collision is pretty low, and the penalty/recovery > (picking a new address and trying again) is rather quick and cheap. > IPv6 does not try to pick a new address and try again in SLAAC, at least not what it's supposed to do. > If a service provider is going to end up giving me a /64 at home (I > know, a whole different argument) I'd vastly prefer to use /80 or /96 > subnets with either of these methods, and still be able to subnet the > space. I suspect if /64's are given out one or both will come to be > "standard". > If a service provider attempts to give ma a /64 at home, I'd opt for a new provider instead. Owen From jeffrey.lyon at blacklotus.net Fri Mar 11 18:33:00 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 11 Mar 2011 19:33:00 -0500 Subject: so big earthquake in JP In-Reply-To: References: <10221EDF-DD32-40E8-A20E-E839682E9595@americafree.tv> <20110311143702.GH54705@blackrose.org> Message-ID: On Fri, Mar 11, 2011 at 6:53 PM, Junichi Shimagami wrote: > Hello all, > > The situation is still quite bad in north eastern area of Honshu > island where Sendai resides. > In Tokyo, we still have frequent aftershocks, but it's getting back to > normal gradually. > > As of connectivity from Japan to overseas, IIJ is seeing several > international circuits going down. > Several cables, not only trans pacific but also intra Asian, seems to > be affected by the earthquake offshore of Japan. > You may encounter some congestion not only to Japan but also to Asia. > > Thanks for you support. > > > Sincerely, > > Junichi Shimagami > Internet Initiative Japan Inc. > from Tokyo > > > 2011/3/11 Dorian Kim : >> On Fri, Mar 11, 2011 at 07:29:29AM -0700, Garret Picchioni wrote: >>> Does anyone have any stats on route updates that might suggest the >>> possibility of fiber on the ocean floor being damaged? >> >> There are some submarine cable outages but I don't believe exact >> locations of damage has been isolated. I suspect that this may take >> some time. >> >> -dorian >> >> > > I don't have anything specific, but PCCW is reporting issues with trans Pacific routes. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From bicknell at ufp.org Fri Mar 11 18:56:49 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 11 Mar 2011 16:56:49 -0800 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> <20110311185809.GA93069@ussenterprise.ufp.org> Message-ID: <20110312005649.GA12836@ussenterprise.ufp.org> In a message written on Fri, Mar 11, 2011 at 04:13:13PM -0800, Owen DeLong wrote: > On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: > > Well, I at least think an option should be a /80, using the 48 bits > > of MAC directly. This generates exactly the same collision potential > > as today we have with a /64 and an EUI-64 constructed from an EUI-48 > > ethernet address. The router is already sending RA's for SLAAC to > > work, sending along one of a well-known set of masks would be a > > relatively minor modification. > > > How would you use that on a Firewire netowrk or FDDI or any of the > other media that uses 64-bit MAC addresses? It wouldn't. I'm not proposing a solution for everything, just a useful case for some things. I don't want to change say, RIR policy that you can allocate a /64, just allow operators to use /80's, or /96's in a more useful way if they find that useful. Basically I think the IETF and IPv6 propoents went a bit too far down the "one size fits all" route. It has nothing to do with how many numbers may or may not be used, but everything to do with the fact that you often have to fit inside what's been given to you. If you're stuck with a monopoly provider who gives you a /64 to your cable modem there should be easy options to split it up and get some subnets. -- 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 streiner at cluebyfour.org Fri Mar 11 12:16:00 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 11 Mar 2011 13:16:00 -0500 (EST) Subject: Switching Email In-Reply-To: <4D79EC47020000FA00050E82@CARNYGW.carcogroup.com> References: <4D79EC47020000FA00050E82@CARNYGW.carcogroup.com> Message-ID: On Fri, 11 Mar 2011, Robert Shimonski wrote: > I would like to opt out of this news list. A link that includes mailing list management functions, including the ability to unsubscribe yourself from the list, is append to the end of every email that's posted to the list. Using that link would be your best bet if you want to unsubscribe. jms From bill at herrin.us Fri Mar 11 19:08:19 2011 From: bill at herrin.us (William Herrin) Date: Fri, 11 Mar 2011 20:08:19 -0500 Subject: Switching Email In-Reply-To: References: <4D79EC47020000FA00050E82@CARNYGW.carcogroup.com> Message-ID: On Fri, Mar 11, 2011 at 1:16 PM, Justin M. Streiner wrote: > On Fri, 11 Mar 2011, Robert Shimonski wrote: >> I would like to opt out of this news list. > > A link that includes mailing list management functions, including the > ability to unsubscribe yourself from the list, is append to the end of every > email that's posted to the list. No, it isn't. Contrary to mailing list best practices, NANOG unsubscribe information is stubbornly stashed in the email headers where users of certain mail programs have no prayer of getting to it and users of most other mail programs don't know how to look for it. Mr. Shimonski could solve his problem by googling "unsubscribe nanog" but he probably has no other way of figuring out how to get off of the list. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From surfer at mauigateway.com Fri Mar 11 19:24:30 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Fri, 11 Mar 2011 17:24:30 -0800 Subject: Switching Email Message-ID: <20110311172430.36FD6F37@resin14.mta.everyone.net> --- bill at herrin.us wrote: From: William Herrin No, it isn't. Contrary to mailing list best practices, NANOG unsubscribe information is stubbornly stashed in the email headers ---------------------------------------------- That's a feature. Not a bug. :-) scott From bill at herrin.us Fri Mar 11 19:43:13 2011 From: bill at herrin.us (William Herrin) Date: Fri, 11 Mar 2011 20:43:13 -0500 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <1299886761.16616.22.camel@sysadmin3a> References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> Message-ID: On Fri, Mar 11, 2011 at 6:39 PM, Justin Krejci wrote: > On Wed, 2011-03-09 at 09:32 -0500, John Curran wrote: >> On Mar 9, 2011, at 12:43 AM, Majdi S. Abbas wrote: >> > ? ?I suspect that as we reach exhaustion, more people will be >> > forced to break space out of their provider's v4 aggregates, and >> > announce them, and an unfiltered DFZ may well approach the 'million' >> > entries some vendors now claim to support. >> >> This matches my personal view (and could be viewed as >> "success" compared to the 5M estimate of Mr. Herrin...) > > Are people going to be relying on using default-routing then in the > future if they don't upgrade routers to handle large routing table > growth? Or perhaps forgo dual-stack and have a separate physical IPv6 > BGP network from IPv4? Are there any other strategies? Hi Justin, IMHO, the most sensible strategy is to recognize that that cost of a route has been dropping faster than the route count has been rising for the past decade. Then recognize that with today's hardware, building a route processor capable of keeping up with 10M routes instead of 1M routes would cost maybe twice as much... 10M being sufficient to handle the worst case estimates for the final size of the IPv4 table in parallel with any reasonable estimate of the IPv6 table in the foreseeable future. Better CPU, more DRAM, bigger TCAM. It could be built today. Finally, get mad at your respective router manufacturers for engineering obsolescence into their product line by declining to give you the option. But that's just my opinion... Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Fri Mar 11 19:46:40 2011 From: bill at herrin.us (William Herrin) Date: Fri, 11 Mar 2011 20:46:40 -0500 Subject: Switching Email In-Reply-To: <20110311172430.36FD6F37@resin14.mta.everyone.net> References: <20110311172430.36FD6F37@resin14.mta.everyone.net> Message-ID: On Fri, Mar 11, 2011 at 8:24 PM, Scott Weeks wrote: >> No, it isn't. Contrary to mailing list best practices, NANOG >> unsubscribe information is stubbornly stashed in the email headers > > That's a feature. ?Not a bug. ?:-) I wonder if the "feature" has anything to do with the number of increasing number of NANOG list messages that I have to fish out of my gmail spam folder. Particularly annoying with the CIDR and BGP reports that I've had to fish out every single week for months now. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From tme at americafree.tv Fri Mar 11 19:51:41 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 11 Mar 2011 20:51:41 -0500 Subject: so big earthquake in JP In-Reply-To: References: <20110311145954.2707.9C4C12A4@nttv6.jp> <6991C2BD-4175-4409-8DB1-71FFDE58059B@asgaard.org> <4D79E261.8050404@mompl.net> <1C66D369-2C5A-447B-834E-E3DC9B180212@gmail.com> <415ECF6B-E6A6-4C4B-A4D7-15C2E98E30B0@ianai.net> Message-ID: <839FF102-B578-4B86-AD77-B50B36C002EF@americafree.tv> On Mar 11, 2011, at 6:34 PM, Owen DeLong wrote: > > On Mar 11, 2011, at 6:11 AM, Patrick W. Gilmore wrote: > >> On Mar 11, 2011, at 8:50 AM, Daniel Belin wrote: >> >>> Are we aware of how much the infrastructure has been damaged yet? Are aftershocks still going? >> >> Subway & bus lines are still down. Fire at the nuke plant has been put out, no radiation detected, but they still evacuated a couple thousand residents because the backup generator failed & the water pump is not pumping. >> > I hear that there is now rising radiation levels outside the plant and US is flying in some dampers > in hopes to resolve the situation. Here is what the IAEA has to say about the situation http://www.iaea.org/press/?p=1133 Japanese officials have also reported that pressure is increasing inside the Unit 1 reactor?s containment, and the officials have decided to vent the containment to lower the pressure. The controlled release will be filtered to retain radiation within the containment. TEPCO has a lot more detail http://www.tepco.co.jp/en/press/corp-com/release/11031203-e.html http://www.tepco.co.jp/en/press/corp-com/release/11031209-e.html Regards Marshall > > Owen > > > From brandon at rd.bbc.co.uk Fri Mar 11 19:54:55 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 12 Mar 2011 01:54:55 GMT Subject: Switching Email Message-ID: <201103120154.BAA03213@sunf10.rd.bbc.co.uk> > Mr. Shimonski could solve his problem by googling "unsubscribe nanog" > but he probably has no other way of figuring out how to get off of the > list. besides the monthly happy mailman day message reminding you how brandon From owen at delong.com Fri Mar 11 19:53:57 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 11 Mar 2011 17:53:57 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> Message-ID: <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> On Mar 11, 2011, at 5:43 PM, William Herrin wrote: > On Fri, Mar 11, 2011 at 6:39 PM, Justin Krejci wrote: >> On Wed, 2011-03-09 at 09:32 -0500, John Curran wrote: >>> On Mar 9, 2011, at 12:43 AM, Majdi S. Abbas wrote: >>>> I suspect that as we reach exhaustion, more people will be >>>> forced to break space out of their provider's v4 aggregates, and >>>> announce them, and an unfiltered DFZ may well approach the 'million' >>>> entries some vendors now claim to support. >>> >>> This matches my personal view (and could be viewed as >>> "success" compared to the 5M estimate of Mr. Herrin...) >> >> Are people going to be relying on using default-routing then in the >> future if they don't upgrade routers to handle large routing table >> growth? Or perhaps forgo dual-stack and have a separate physical IPv6 >> BGP network from IPv4? Are there any other strategies? > > > Hi Justin, > > IMHO, the most sensible strategy is to recognize that that cost of a > route has been dropping faster than the route count has been rising > for the past decade. Then recognize that with today's hardware, > building a route processor capable of keeping up with 10M routes > instead of 1M routes would cost maybe twice as much... 10M being > sufficient to handle the worst case estimates for the final size of > the IPv4 table in parallel with any reasonable estimate of the IPv6 > table in the foreseeable future. Better CPU, more DRAM, bigger TCAM. > It could be built today. > But the RP is the easy cheap part. It's the line cards and the TCAM/etc. that they use that gets pricey fast. > Finally, get mad at your respective router manufacturers for > engineering obsolescence into their product line by declining to give > you the option. > The option of $60,000 line cards instead of $30,000 or even $25,000 instead of $12,000 does not seem like one that most would have found appealing. > But that's just my opinion... > And the above is just mine. Owen From bill at herrin.us Fri Mar 11 20:14:40 2011 From: bill at herrin.us (William Herrin) Date: Fri, 11 Mar 2011 21:14:40 -0500 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> Message-ID: On Fri, Mar 11, 2011 at 8:53 PM, Owen DeLong wrote: > On Mar 11, 2011, at 5:43 PM, William Herrin wrote: >> Finally, get mad at your respective router manufacturers for >> engineering obsolescence into their product line by declining to give >> you the option. >> > The option of $60,000 line cards instead of $30,000 or > even $25,000 instead of $12,000 does not seem like one > that most would have found appealing. Ever buy SAS drives instead of SATA even though they're twice as expensive for the same disk space? Why? You may be right, but it'd be nice to have the option. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Fri Mar 11 20:17:21 2011 From: bill at herrin.us (William Herrin) Date: Fri, 11 Mar 2011 21:17:21 -0500 Subject: Switching Email In-Reply-To: <201103120154.BAA03213@sunf10.rd.bbc.co.uk> References: <201103120154.BAA03213@sunf10.rd.bbc.co.uk> Message-ID: On Fri, Mar 11, 2011 at 8:54 PM, Brandon Butterworth wrote: >> Mr. Shimonski could solve his problem by googling "unsubscribe nanog" >> but he probably has no other way of figuring out how to get off of the >> list. > > besides the monthly happy mailman day message reminding you how We get what, 20, 30, 100 messages a day? How about as a prank I subscribe you to the Justin Bieber mailing list at the same message volume, only you can't get instructions about how to unsubscribe for 30 days and you have to read the mail in Microsoft Lookout, interspersed with work-oriented messages from your boss and colleagues. With Outlook popping new-message-notifications up on the projector while you try to give a presentation during a meeting, each containing the sender and message subject... -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jeff-kell at utc.edu Fri Mar 11 21:28:30 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Fri, 11 Mar 2011 22:28:30 -0500 Subject: Switching Email In-Reply-To: <20110311172430.36FD6F37@resin14.mta.everyone.net> References: <20110311172430.36FD6F37@resin14.mta.everyone.net> Message-ID: <4D7AE85E.6080400@utc.edu> On 3/11/2011 8:24 PM, Scott Weeks wrote: > --- bill at herrin.us wrote: > From: William Herrin > > No, it isn't. Contrary to mailing list best practices, NANOG > unsubscribe information is stubbornly stashed in the email headers > ---------------------------------------------- > > That's a feature. Not a bug. :-) Actually, it's RFC 2369 :) Jeff From jsw at inconcepts.biz Fri Mar 11 22:14:16 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Fri, 11 Mar 2011 23:14:16 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <7E27F319-7736-41F5-AD4D-3E5C1A67A41A@delong.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <7E27F319-7736-41F5-AD4D-3E5C1A67A41A@delong.com> Message-ID: On Fri, Mar 11, 2011 at 6:33 PM, Owen DeLong wrote: > Yes, you can bring as much of the pain from IPv4 forward into IPv6 > as you like. You can also commit many other acts of masochism. This is the problem with "Fundamentalists," such as yourself, Owen. You think that "fixing" things which work fine (like reasonable-sized VLSM LANs for content farms) is worth introducing a DDoS vulnerability for which there is no current defense, and for which the only feasible defense is either reversing your choice and renumbering the subnet from /64 to /smaller, or waiting until your vendors supply you with patched images for your routers and/or switches. You need to move beyond this myopic view that /64 provides a benefit that is worth this kind of operational sacrifice. When vendors cough up some more knobs, I'll be right there with you, configuring /64 subnets. I've already allocated them! It's pretty easy for me to renumber my /120 subnets to /64, after all -- I don't have to update any zone files for public-facing services, or modify significant configuration for software -- I just have to reconfigure my router and host interfaces from /120 to /64. You, on the other hand, may have addresses in use all over that /64, and condensing them into a smaller subnet is guaranteed to be at least as hard as my work for growing my subnet, and may be much more difficult -- every bit as difficult as renumbering from one IPv4 block to another. Given the current state of IPv6, your "Fundamentalist" way introduces new problems *and* brings the old ones forward. This makes no sense, but Fundamentalists rarely do. > Personally, I prefer to approach IPv6 as a way to reduce some of > the more painful aspects of IPv4, such as undersized subnets, > having to renumber or add prefixes for growth, limited aggregation, > NAT, and more. I look forward to that when it works. As I've noticed, I have prepared to take advantage of those things as soon as the NDP issue is resolved. >> None of that "standard IPv6 automatic stuff" works today, anyway. ?The >> state of IPv6 support on end-user CPE generally ranges from > As someone using SLAAC in a number of environments, I'm confused > by this statement. It seems to be working quite well in many places > and end-user residential networks are certainly not the only places > where it is useful. Your definition of "working quite well in many places" is different than mine. I'll come around to your point of view when it is possible to get working IPv6 connectivity from most major end-user ISPs, and all (or close enough) the CPE being sold at Fry's and Best Buy works right. We are pretty far from that right now. This is another thing the "IPv6 Fundamentalists" seem to ignore. CPE support is almost non-existent, ISP support is not there (some tier-1 transit networks still have no IPv6 product!), and the major IXPs still have three orders of magnitude more IPv4 traffic than IPv6. Cogent, Level3, and Hurricane Electric still can't decide that it's in their mutual interest to exchange IPv6 traffic with each-other, and their customers don't care enough to go to another service provider, because IPv6 is largely unimportant to them. None of this stuff "works" today. You aren't seeing DDoS scenarios on the v6 network today because the largest IPv4 DDoS attacks are larger than the total volume of inter-domain IPv6 traffic. > Most of the top-of-rack switches I'm aware of have no problem doing > at least 64k NDP/ARP entries. Many won't do more than that, but, > most will go at least that far. Owen, this statement is either: 1) a gross misunderstanding on your part, because you can't or don't read spec sheets, let alone test gear 2) you've never seen or used a top-of-rack switch or considered buying one long enough to examine the specs 3) your racks are about 3 feet taller than everyone else's and you blow 100k on switching for every few dozen servers 4) an outright lie, although not an atypical one for the "IPv6 Fundamentalist" crowd I'd like you to clarify which of these is the case. Please list some switches which fit your definition of "top-of-rack switch" that support 64k NDP entries. Then list how many "top-of-rack" switches you are currently aware of. Don't bother listing the ones you know don't support 64k, because I'll gladly provide a list of plenty more of those, than the number of switches which you find to support 64k in a ToR form-factor. For those following along at home, how many ToR switches do indeed support at least 64k NDP entries? Unlike Owen, I know the answer to this question: Zero. There are no ToR switches that support >= 64k NDP table entries. Of course, I don't really mean to call Owen a liar, or foolish, or anything else. I do mean to point out that his "facts" are wrong and his argument not based in the world of reality. He is a "Fundamentalist," and is part of the problem, not the solution. > I find it interesting that you _KNOW_ that /64 LANs will cause you DoS > problems and yet we've been running them for years without incident. That's because I understand how packet forwarding to access LANs actually works. You don't. Again, the biggest DDoS attacks today dwarf the whole volume of inter-domain IPv6 traffic. *Routine* IPv4 attacks are greater than the peak IPv6 traffic at any IXP. IPv6 hasn't seen any real DDoS yet. It will probably happen soon. > There are several things that could eventually be implemented in the > access switch software. Techniques like rapidly timing out unanswered > NDP requests, not storing ND entries for SLAAC MAC-based suffixes > (after all, the information you need is already in the IP address, just > use that). Not storing ND entries for things that don't have an entry > in the MAC forwarding table (pass the first ND packet and if you > get a response, create the ND entry at that time), etc. I am glad you have given this some thought. The things you mention above are not bad, but they don't fix the problem. There are several practical solutions available which require pretty straight-forward router/switch knobs. Vendors will *eventually* deliver these knobs. Probably not before IPv6 is deployed enough that we see real DDoS, though; and if the most popular fix becomes dependent on NDP inspection ... you can forget about benefiting from that fix if you still have 10-year-old access switches. I do have 10-year-old access switches, and older. I'm not upgrading them specifically because vendors aren't offering the needed knobs to solve this problem. I want budgetary resources to be available to me when that time comes. To Cisco/Foundry/Juniper/et al: I've been waiting a real long time to upgrade these old beasts, and whichever of you gets me a fix I consider practical first, is very likely to be the vendor that gets to sell me > 1000 new ToR switches. Unless Cisco feels like back-porting a fix to my older platforms, which I see as unlikely, I am quite prepared to replace 10 - 15 year old switches when NDP flooding fix is among the benefits I receive. I really hope my 0 to 5 year old switches all get back-ported fixes, or I'll be pretty displeased. > Yes, these all involve a certain amount of changing some expected > behaviors, but, those changes could probably be easily accommodated > in most environments. This can be fixed without changing *any* behavior at all from the host's perspective. We just need the knobs. To get that, we need people like you to stop telling people this isn't a problem, and to start telling your vendors that "the sky is falling," and asking for some specific fix that you think is practical, or a fix in general, if you don't think you have a truly practical idea. > Finally, the bottom line is that a rogue host behind your firewall > is probably going to cause other forms of damage well before > it runs you out of ND entries and any time you have such a thing, > it's going to be pretty vital to identify and remove it as fast as > possible anyway. I've seen this argument before, too. We all have. It doesn't hold water. Once again, you "Fundamentalists" think that if there is any case where a fix might not be helpful, or you can distract attention from this issue to one of host security, you try to do so. Let me give you the case I care about: Script kiddie hacks one server in a multi-use hosting datacenter, which is served by a layer-3 switch aggregating hundreds of customers. Script kiddie decides to DoS someone from his newly-hacked server, and uses random source addresses within the configured /64. Maybe he intends to DoS the upstream aggregation switch, or maybe it doesn't even occur to him. Either way, my NDP table immediately becomes full (even with only a few hundred PPS.) Are any other customers affected? Yes, potentially all the customers on this layer-3 switch are affected. Definitely all the customers on this VLAN/subnet are affected, even with the Cisco knob (which is better than all VLANs/subnets breaking.) Now replace the "some script kiddie" scenario with something that's simply misconfigured or buggy. You don't even have to be compromised. >> I'm glad SLAAC is an option, but that's all it is, an option. ?/64 >> LANs must also be considered optional, and should be considered useful > They are entirely optional, but, IMHO, avoiding them at all costs > such as you seem to be suggesting is unnecessarily painful in > most environments. "At all costs?" Again, more "IPv6 Fundamentalist" talk. What is the cost of configuring a /120 instead of a /64 on my LAN, if I already know I don't want SLAAC on this LAN? None. Might the subnet need to grow? I'll grant that, but it's a minimal cost compared to a DoS vulnerability which can be exploited trivially. > I'd settle for Cisco coming to the point of having RA guard > universally available on all switch products. That, to me, > is a much more pressing issue than this imagined ND > exhaustion attack which, in reality, requires near DDOS > levels of traffic for most networks to actually run the ND > table meaningfully into overflow. First, I agree, we need more knobs on all switching ports, period. Vendors are not delivering, and I'm not buying any more access switches than I absolutely have to. I have been putting off upgrades for *years* because of these things. Anytime clients ask me, "should we replace these old switches? They work but.. they're pretty old!" I say "no, wait until X." This is X. Second, ND exhaustion attack is hardly imagined. Go do it on a box. Any box, pick one. They all break, period. The failure mode differs somewhat from one vendor to the next (when entries are evicted, etc.) but *every router* breaks today, period. Third, I don't know what you mean by "near DDOS levels of traffic," but I already know that you are unfamiliar with common NDP table sizes. 4k - 8k is actually a pretty common range of supported NDP entries for modern layer-3 ToR switches, and I'm talking about 1-year-old, 40x10GbE switches from reputable vendors. As you might imagine, it only takes a few thousand packets to fill this up, and aging timers these days get up to several *hours* before entries are evicted. One packet per second is plenty. One PPS! Some DDoS, huh? If this sounds like a "magic packet" issue to some, remember, it's not. This is not "ping of death" or "winnuke," and it's not smurf. It's the same thing that happens if you toss a /8 on an IPv4 LAN and start banging away at the ARP table, while expecting all of your legitimate hosts within that /8 to continue working correctly. We all know that's crazy, right? How is it suddenly less crazy to put an even larger subnet on an IPv6 LAN without gaining any direct benefits from doing so? Remember, many LANs don't need SLAAC. The VPS farm sure doesn't. The router point-to-point doesn't. Any person who would tell you to configure a /64 for those LANs is an "IPv6 Fundamentalist." -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From rdobbins at arbor.net Fri Mar 11 22:33:00 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 12 Mar 2011 04:33:00 +0000 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <7E27F319-7736-41F5-AD4D-3E5C1A67A41A@delong.com> Message-ID: <7C957936-ECCA-45ED-9ADA-97B831B832C6@arbor.net> On Mar 12, 2011, at 11:14 AM, Jeff Wheeler wrote: > Of course, I don't really mean to call Owen a liar, or foolish, or anything else. Please don't; even though I disagree with him and agree with you very strongly on this set of issues, Owen is a smart and straightforward guy, and is simply speaking from his (selective on this particular set of topics, IMHO) own individual viewpoint. ;> > and if the most popular fix becomes dependent on NDP inspection If that comes to pass, then the fix will be useless, unfortunately, just as dynamic ARP inspection (DAI) is useless today; it self-DoSes the box. Any form of 'inspection' will not scale for this problem, as it will be CPU-bound even on ASIC-based platforms. All this ICMPv6 weirdness and outright brokenness is the Achilles' heel of IPv6, and I see no ready solution in sight for the set of problems it engenders. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From ryan.landry at gmail.com Fri Mar 11 22:41:02 2011 From: ryan.landry at gmail.com (Ryan Landry) Date: Fri, 11 Mar 2011 21:41:02 -0700 Subject: Switching Email In-Reply-To: References: <20110311172430.36FD6F37@resin14.mta.everyone.net> Message-ID: there are handy gmail filters that can fix this for you... On Fri, Mar 11, 2011 at 6:46 PM, William Herrin wrote: > > > I wonder if the "feature" has anything to do with the number of > increasing number of NANOG list messages that I have to fish out of my > gmail spam folder. Particularly annoying with the CIDR and BGP reports > that I've had to fish out every single week for months now. > > -Bill > > > > -- > William D. Herrin ................ herrin at dirtside.com bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From francois.rousseau.tech at gmail.com Fri Mar 11 23:39:05 2011 From: francois.rousseau.tech at gmail.com (=?UTF-8?Q?Fran=C3=A7ois_Rousseau?=) Date: Sat, 12 Mar 2011 00:39:05 -0500 Subject: Switching Email In-Reply-To: References: <20110311172430.36FD6F37@resin14.mta.everyone.net> Message-ID: 2011/3/11 Ryan Landry : > there are handy gmail filters that can fix this for you... > > On Fri, Mar 11, 2011 at 6:46 PM, William Herrin wrote: >> >> >> I wonder if the "feature" has anything to do with the number of >> increasing number of NANOG list messages that I have to fish out of my >> gmail spam folder. Particularly annoying with the CIDR and BGP reports >> that I've had to fish out every single week for months now. >> >> -Bill >> >> >> >> -- >> William D. Herrin ................ herrin at dirtside.com ?bill at herrin.us >> 3005 Crane Dr. ...................... Web: >> Falls Church, VA 22042-3004 >> >> > Well it's a mailman server so you could email nanog-request at nanog.org with the subject: unsubscribe From joelja at bogus.com Sat Mar 12 01:17:19 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Fri, 11 Mar 2011 23:17:19 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> Message-ID: I'm super-tired of the "but tcams are an expensive non-commodity part not subject to economies of scale". this has been repeated ad nauseam since the raws workshop if not before. You don't have to build a lookup engine around a tcam and in fact you can use less power doing so even though you need more silicon to achieve increased parallelism. RFC 4984 has a lot of useful insights in it but it was flat wrong about two things since 2007. The impact of rate of growth in the DFZ(for one thing churn failed to grow in lockstep), and the ability of the technology to keep up. Not all the devices in your network need a 2 million route FIB, yet getting a device today that has one isn't that hard. and it'll be a lot easier in five years and it likely will do so without having a 144Mbit CAM ASIC. I don't know if we'll be using commercially viable MRAM implementations in place of SRAM cells in a decade or if we'll have more of the same only smaller and faster and much much wider, Or if the LISP religion will take over the world and we'll carry the state for diversely connected edges elsewhere in the stack. What I am confident of is that as an industry we'll be able to deliver something that works without jacking up the Internet routing system and replacing it, and without somehow altering the individual decision making processes in many tens of thousands of autonomous systems. I am also confident that the early adopters will pay more for the technology than the stragglers, that we will grumble about how much it costs and the inevitability of obsolescence, and that life will somehow go on. Joel's widget number 2 On Mar 11, 2011, at 17:53, Owen DeLong wrote: > > On Mar 11, 2011, at 5:43 PM, William Herrin wrote: > >> On Fri, Mar 11, 2011 at 6:39 PM, Justin Krejci wrote: >>> On Wed, 2011-03-09 at 09:32 -0500, John Curran wrote: >>>> On Mar 9, 2011, at 12:43 AM, Majdi S. Abbas wrote: >>>>> I suspect that as we reach exhaustion, more people will be >>>>> forced to break space out of their provider's v4 aggregates, and >>>>> announce them, and an unfiltered DFZ may well approach the 'million' >>>>> entries some vendors now claim to support. >>>> >>>> This matches my personal view (and could be viewed as >>>> "success" compared to the 5M estimate of Mr. Herrin...) >>> >>> Are people going to be relying on using default-routing then in the >>> future if they don't upgrade routers to handle large routing table >>> growth? Or perhaps forgo dual-stack and have a separate physical IPv6 >>> BGP network from IPv4? Are there any other strategies? >> >> >> Hi Justin, >> >> IMHO, the most sensible strategy is to recognize that that cost of a >> route has been dropping faster than the route count has been rising >> for the past decade. Then recognize that with today's hardware, >> building a route processor capable of keeping up with 10M routes >> instead of 1M routes would cost maybe twice as much... 10M being >> sufficient to handle the worst case estimates for the final size of >> the IPv4 table in parallel with any reasonable estimate of the IPv6 >> table in the foreseeable future. Better CPU, more DRAM, bigger TCAM. >> It could be built today. >> > But the RP is the easy cheap part. It's the line cards and the > TCAM/etc. that they use that gets pricey fast. > >> Finally, get mad at your respective router manufacturers for >> engineering obsolescence into their product line by declining to give >> you the option. >> > The option of $60,000 line cards instead of $30,000 or > even $25,000 instead of $12,000 does not seem like one > that most would have found appealing. > >> But that's just my opinion... >> > And the above is just mine. > > Owen > > > From joe at gonetforward.com Sat Mar 12 01:31:54 2011 From: joe at gonetforward.com (Joe Renwick) Date: Fri, 11 Mar 2011 23:31:54 -0800 Subject: Cisco IOS MPLS VPN Bug Message-ID: Hello All, A customer of our's has had two major outages due to a bug in Cisco's software. The network is an MPLS VPN environment. The bug has occurred on our 6500(s) with VS-S720-10G Supervisors running s72033-adventerprisek9_wan-mz.122-33.SXH6.bin. These routers are configured as BGP route-reflectors. The first time the bug hit occurred when a new route-reflector client was added. The second time was due to a topology change on the network. On both occasions the only fix was removing the peer configurations on the RR and re-applying. Niether soft nor hard clears on the BGP neighbors worked, only the config removal. Once re-applied life was good. The bug itself was with the BGP updates sent by the RR. During the outage these updates did not include the Route Target Extended Community required by the route-reflector clients which identifies which VRF the route belongs too. Below is output on a client during the outage and after the config yanking. Notice the mysterious disappearance of the RT community. Looking to see if anyone has seen this issue particularly with this version of code. TAC is trying to tell me that this was a bug in a previous version but is fixed in the code I am running. Huh? Been running around in circles with them for a month so this is my act of desperation. Also if anyone is running a similar environment without issue I would be very interested in what version of code your using. Thanks to all who took the time to read this email... Happy Friday. *BAD:* CLN-MWB-2811-01#sh ip bgp vpnv4 all 10.180.33.22 BGP routing table entry for 102:102:10.180.33.20/30, version 1763889 Paths: (2 available, best #2, no table) Advertised to update-groups: 1 Local 10.180.20.1 (metric 9) from 10.180.20.3 (10.180.20.3) Origin incomplete, metric 0, localpref 100, valid, internal Extended Community: RT:102:102 Originator: 10.180.20.1, Cluster list: 0.0.255.245 mpls labels in/out nolabel/16 Local 10.180.20.1 (metric 9) from *10.180.20.1* (10.180.20.1) Origin incomplete, metric 0, localpref 100, valid, internal, best mpls labels in/out nolabel/16 *GOOD:* CLN-MWB-2811-01#sh ip bgp vpnv4 all 10.180.33.22 BGP routing table entry for 102:102:10.180.33.20/30, version 1765931 Paths: (2 available, best #1, table AMS) Advertised to update-groups: 1 Local 10.180.20.1 (metric 9) from *10.180.20.1* (10.180.20.1) Origin incomplete, metric 0, localpref 100, valid, internal, best *Extended Community: RT:102:102* mpls labels in/out nolabel/16 Local 10.180.20.1 (metric 9) from 10.180.20.3 (10.180.20.3) Origin incomplete, metric 0, localpref 100, valid, internal Extended Community: RT:102:102 Originator: 10.180.20.1, Cluster list: 0.0.255.245 mpls labels in/out nolabel/16 Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From george.herbert at gmail.com Sat Mar 12 02:25:48 2011 From: george.herbert at gmail.com (George Herbert) Date: Sat, 12 Mar 2011 00:25:48 -0800 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <7E27F319-7736-41F5-AD4D-3E5C1A67A41A@delong.com> Message-ID: On Fri, Mar 11, 2011 at 8:14 PM, Jeff Wheeler wrote: > It's the same thing that happens if you toss a /8 on an IPv4 LAN and > start banging away at the ARP table, while expecting all of your > legitimate hosts within that /8 to continue working correctly. ?We all > know that's crazy, right? This is a valid concern. However... >?How is it suddenly less crazy to put an > even larger subnet on an IPv6 LAN without gaining any direct benefits > from doing so? ?[...] This is not a valid statement. I understand that you don't value the benefits we find with /64 or less, but we find value there, and it's really important to us, and they're things which were explicitly hoped for and planned for with IPv6 transition. The problem you pointed out, with a single host overrunning switch tables, can be outsmarted rather than brute forced by mandating small enough subnets that it doesn't exist. If we presume that the originating host doesn't fake its' layer 2 MAC as it's faking its layer 3 address, it's pretty trivial; you build in a software option that puts a maximum number of IPs per MAC. You balance virtualization cluster size limits with preemptive defense against this type of DOS when you do that, but balance points around 1E2 to 1E3 seem to me to be able to handle that just fine. You build in an override for switches / L2 gateways, or by port, or whatever other tuning mechanisms make sense (default to 10, override for your VMware cluster box and your switches...). If the originating host does try to fake its layer 2 MAC, you can detect new floods of new MACs via existing mechanisms. Plenty of port MAC map / allowed MAC mechanisms already exist for basic LAN security purposes. You just dump the fake MACs on the floor. The world is not perfect, and I'm sure there are still new vulnerabilities out there. But we can smart this one. If we can't smart this one, I'll be extremely surprised and disappointed. -- -george william herbert george.herbert at gmail.com From B.Candler at pobox.com Sat Mar 12 04:49:39 2011 From: B.Candler at pobox.com (Brian Candler) Date: Sat, 12 Mar 2011 10:49:39 +0000 Subject: [afnog] Suspicious request for IP address space In-Reply-To: References: <20110308134337.GI87854@macbook.catpipe.net> Message-ID: <20110312104939.GA6973@uk.tiscali.com> On Tue, Mar 08, 2011 at 06:23:26PM +0200, Shepherd Magumo wrote: > Odds are, they're looking for a willing host for a snowshoe spamming > operation. If I wanted space for something like that, Afrinic > region providers would not be my first choice...particularly for the > hosting. AFAIK, there are numerous LIRs in the RIPE region, > particularly Romania who are more than happy to lease large blocks > of IPv4 to anyone for any purpose. > > I guessed as much, it can only be a spamming operation. I will play > along, offer them a lease and charge them over 9000 a day. Tell them they can have the block, but they need to send you an up-front reservation fee (by Western Union) to cover local administrative costs. From bill at herrin.us Sat Mar 12 07:00:10 2011 From: bill at herrin.us (William Herrin) Date: Sat, 12 Mar 2011 08:00:10 -0500 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> Message-ID: On Sat, Mar 12, 2011 at 2:17 AM, Joel Jaeggli wrote: > I'm super-tired of the "but tcams are an expensive >non-commodity part not subject to economies of scale". this >has been repeated ad nauseam since the raws workshop if not before. > > You don't have to build a lookup engine around a tcam and in fact >you can use less power doing so even though you need more >silicon to achieve increased parallelism. Hi Joel, You're either building a bunch of big TCAMs or a radix trie engine with sufficient parallelism to get the same aggregate lookup rate. If there's a materially different 3rd way to build a FIB, one that works at least as well, feel free to educate me. And while RIB churn doesn't grow in lockstep with table size, it does grow. Either way when you boost from 1M to 10M you're talking about engineering challenges with heat dissipation and operating challenges with power consumption, not to mention more transistors. I'll be convinced it can be done for less than 2x cost when someone actually does it for less than 2x cost. Whether it's 2x cost or 1.2x cost, the point remains the same: we could have routers today that handle the terminal size of the IPv4 table without breaking the bank. Your favorite router manufacturer has made vague assertions about how they would build one given sufficient customer demand. So make a demand. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bill at herrin.us Sat Mar 12 07:16:19 2011 From: bill at herrin.us (William Herrin) Date: Sat, 12 Mar 2011 08:16:19 -0500 Subject: Switching Email In-Reply-To: <4D7AE85E.6080400@utc.edu> References: <20110311172430.36FD6F37@resin14.mta.everyone.net> <4D7AE85E.6080400@utc.edu> Message-ID: On Fri, Mar 11, 2011 at 10:28 PM, Jeff Kell wrote: > On 3/11/2011 8:24 PM, Scott Weeks wrote: >> --- bill at herrin.us wrote: >> From: William Herrin >> >> No, it isn't. Contrary to mailing list best practices, NANOG >> unsubscribe information is stubbornly stashed in the email headers >> ---------------------------------------------- >> >> That's a feature. ?Not a bug. ?:-) > > Actually, it's RFC 2369 ?:) Anyone have a list of MUAs that actually support RFC 2369 with subscription management widgets in the GUI? Surely someone has written one but I can't seem to find any documentation to that effect. On the other hand, the very first guideline at http://www.mail-abuse.com/an_listmgntgdlines.html is: "Mailing list administrators must provide [...] clear and effective instructions for unsubscribing from a mailing list." Hidden in the headers is rather less than clear or effective. Even that lightweight, the CAN-SPAM act, calls for each message to contain "clear and conspicuous notice of the opportunity [...] to decline to receive further" messages. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From deric.kwok2000 at gmail.com Sat Mar 12 07:51:20 2011 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Sat, 12 Mar 2011 05:51:20 -0800 Subject: need help about switch montior Message-ID: Hi ls there any program/way to monitor the switch port/switch status when it reaches to certain bandwidth? Thank you so much From avg at kotovnik.com Sat Mar 12 08:07:08 2011 From: avg at kotovnik.com (Vadim Antonov) Date: Sat, 12 Mar 2011 06:07:08 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> Message-ID: <1299938828.30354.24.camel@kotti.kotovnik.com> On Sat, 2011-03-12 at 08:00 -0500, William Herrin wrote: > You're either building a bunch of big TCAMs or a radix trie engine > with sufficient parallelism to get the same aggregate lookup rate. If > there's a materially different 3rd way to build a FIB, one that works > at least as well, feel free to educate me. And while RIB churn doesn't > grow in lockstep with table size, it does grow. Radix trie traversal can be pipelined, with every step in the search being done in separate memory bank. The upper levels of tries are small, and the lower levels contain a lot of gunk which is not used often - so they can be cached on-chip. FIB lookup is much easier than executing instructions like CPUs do precisely because packets are not dependent on each other, so you don't need to stall pipeline (like CPUs do on jumps, I'll skip the discussion of things like branch prediction and speculative execution). This didn't stop folks at Intel producing cheap silicon which executes instructions at astonishing speeds. Where TCAMs really shine is packet classification - but you don't generally need huge TCAM to hold ACLs in. > Your favorite router manufacturer has made vague assertions about how > they would build one given sufficient customer demand. So make a > demand. OFRV has a track record of producing grossly over-engineered devices, hardware-wise. I've heard a very senior hardware guy who came from OFRV claiming that they do that deliberately to increase barriers to entry for competition, though this doesn't make sense to me. --vadim From dmm at 1-4-5.net Tue Mar 1 14:28:27 2011 From: dmm at 1-4-5.net (David Meyer) Date: Tue, 1 Mar 2011 12:28:27 -0800 Subject: [NANOG-announce] NANOG 52 Registration is open! Message-ID: Registration for NANOG 52 is open. Something new this time around: There is a $25 discount for NewNOG members. Please register soon and see you in Denver. Dave (for the NANOG PC) _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From wschultz at bsdboy.com Sat Mar 12 08:52:05 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Sat, 12 Mar 2011 06:52:05 -0800 Subject: need help about switch montior In-Reply-To: References: Message-ID: <8F71F037-3711-4D2E-9348-D11E6A1C2119@bsdboy.com> I use this Nagios plugin for up/down status alerts, it has some support for interface bandwidth (and errors/discards) monitoring. It's just a perl script so you could easily modify it to suit your needs. http://nagios.manubulon.com/snmp_int.html -wil On Mar 12, 2011, at 5:51 AM, Deric Kwok wrote: > Hi > > ls there any program/way to monitor the switch port/switch status when > it reaches to certain bandwidth? > > Thank you so much > From johnl at iecc.com Sat Mar 12 09:02:38 2011 From: johnl at iecc.com (John Levine) Date: 12 Mar 2011 15:02:38 -0000 Subject: unsubscribing, was Switching Email In-Reply-To: Message-ID: <20110312150238.28754.qmail@joyce.lan> >Anyone have a list of MUAs that actually support RFC 2369 with >subscription management widgets in the GUI? Surely someone has written >one but I can't seem to find any documentation to that effect. Alpine, which has what must be the cruddiest GUI on the planet, does. Too bad people prefer glitz to function. R's, John From DStaal at usa.net Sat Mar 12 09:07:18 2011 From: DStaal at usa.net (Daniel Staal) Date: Sat, 12 Mar 2011 10:07:18 -0500 Subject: unsubscribing, was Switching Email In-Reply-To: <20110312150238.28754.qmail@joyce.lan> References: <20110312150238.28754.qmail@joyce.lan> Message-ID: --As of March 12, 2011 3:02:38 PM +0000, John Levine is alleged to have said: >> Anyone have a list of MUAs that actually support RFC 2369 with >> subscription management widgets in the GUI? Surely someone has written >> one but I can't seem to find any documentation to that effect. > > Alpine, which has what must be the cruddiest GUI on the planet, does. > Too bad people prefer glitz to function. --As for the rest, it is mine. Squirrelmail and Kmail both do as well, although in both cases it's an option that needs to be configured. (In Squirrelmail's case it's actually a plugin, I think.) Daniel T. Staal --------------------------------------------------------------- This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. --------------------------------------------------------------- From lists at quux.de Sat Mar 12 09:12:40 2011 From: lists at quux.de (Jens Link) Date: Sat, 12 Mar 2011 16:12:40 +0100 Subject: Switching Email In-Reply-To: (William Herrin's message of "Sat, 12 Mar 2011 08:16:19 -0500") References: <20110311172430.36FD6F37@resin14.mta.everyone.net> <4D7AE85E.6080400@utc.edu> Message-ID: <878vwk4bkn.fsf@oban.berlin.quux.de> William Herrin writes: > Anyone have a list of MUAs that actually support RFC 2369 with > subscription management widgets in the GUI? Surely someone has written > one but I can't seem to find any documentation to that effect. Gnus? Jens, Gnus user since 1999 -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From lists at quux.de Sat Mar 12 09:15:31 2011 From: lists at quux.de (Jens Link) Date: Sat, 12 Mar 2011 16:15:31 +0100 Subject: Switching Email In-Reply-To: (William Herrin's message of "Fri, 11 Mar 2011 21:17:21 -0500") References: <201103120154.BAA03213@sunf10.rd.bbc.co.uk> Message-ID: <874o784bfw.fsf@oban.berlin.quux.de> William Herrin writes: > and you have to read the mail in Microsoft Lookout, interspersed with > work-oriented messages from your boss and colleagues. With Outlook > popping new-message-notifications up on the projector while you try to > give a presentation during a meeting, each containing the sender and > message subject... Well I try to avoid Outlook, but even I was able to create some basic filter rules during my last projekt (where I was forced to use it). Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From nemix at gsh-lan.com Sat Mar 12 09:24:47 2011 From: nemix at gsh-lan.com (nemix) Date: Sat, 12 Mar 2011 16:24:47 +0100 Subject: need help about switch montior In-Reply-To: <8F71F037-3711-4D2E-9348-D11E6A1C2119@bsdboy.com> References: <8F71F037-3711-4D2E-9348-D11E6A1C2119@bsdboy.com> Message-ID: We use Solarwinds Orion for this stuff. We have some alerts for some switch Ports configured. You can get a trial version at www.solarwinds.com 2011/3/12 Wil Schultz > I use this Nagios plugin for up/down status alerts, it has some support for > interface bandwidth (and errors/discards) monitoring. It's just a perl > script so you could easily modify it to suit your needs. > > http://nagios.manubulon.com/snmp_int.html > > -wil > > > On Mar 12, 2011, at 5:51 AM, Deric Kwok wrote: > > > Hi > > > > ls there any program/way to monitor the switch port/switch status when > > it reaches to certain bandwidth? > > > > Thank you so much > > > > > From jeff-kell at utc.edu Sat Mar 12 10:05:41 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Sat, 12 Mar 2011 11:05:41 -0500 Subject: unsubscribing, was Switching Email In-Reply-To: <20110312150238.28754.qmail@joyce.lan> References: <20110312150238.28754.qmail@joyce.lan> Message-ID: <4D7B99D5.6060905@utc.edu> On 3/12/2011 10:02 AM, John Levine wrote: >> Anyone have a list of MUAs that actually support RFC 2369 with >> subscription management widgets in the GUI? Surely someone has written >> one but I can't seem to find any documentation to that effect. > Alpine, which has what must be the cruddiest GUI on the planet, does. > Too bad people prefer glitz to function. And Glitzy MUAs and MTAs tend to be the least RFC compliant of all. Thunderbird (older versions) had a plugin (Display Mailing List Headers) that would do it, but the plugin is not compatible with the current version[s] of Thunderbird. Any MUA that has a toggle or view to "display all headers" may indirectly do it if they create "clickable links" for http: and mailto: directives, e.g., from this list: > List-Id: North American Network Operators Group > List-Unsubscribe: , > > List-Archive: > List-Post: > List-Help: > List-Subscribe: , > Jeff From vnktshsriram at gmail.com Sat Mar 12 10:24:23 2011 From: vnktshsriram at gmail.com (Venkatesh Sriram) Date: Sat, 12 Mar 2011 21:54:23 +0530 Subject: OSPFv3 Authentication In-Reply-To: References: Message-ID: Janos, > On Tue, 28 Sep 2010, Venkatesh Sriram wrote: > >> While I have used MD5 with OSPFv2, I never used authentication with >> OSPFv3 since IPsec is (a) not available on all platforms (or/and >> requires a special license) and (b) requires too much of coordination >> with other folks to bring it up. I know operators who use >> authentication with ISIS for v6, but very little auth for >> OSPFv3.Obviously, you'll find an equal number that enthusiastically >> use auth with OSPFv3, so really there isnt any one right answer. > > Dear Sriram, > ? ? ? ?Can you list/name the platforms does not support IPsec for OSPFv3 > without special license? e.g. to avoid such a platform.... > ? ? ? ?Best Regards, > ? ? ? ? ? ? ? ?Janos Some platforms of Cisco for one. http://mellowd.co.uk/ccie/?p=1421 Sriram From jason at lixfeld.ca Sat Mar 12 10:34:52 2011 From: jason at lixfeld.ca (Jason Lixfeld) Date: Sat, 12 Mar 2011 11:34:52 -0500 Subject: Cisco IOS MPLS VPN Bug In-Reply-To: References: Message-ID: <75C33CD8-C40E-4B1B-B3E2-68DAAD651CDB@lixfeld.ca> On 2011-03-12, at 2:31 AM, Joe Renwick wrote: > These routers > are configured as BGP route-reflectors. ... > Niether > soft nor hard clears on the BGP neighbors worked, only the config removal. > Once re-applied life was good. ... > The bug itself was with the BGP updates sent by the RR. During the outage > these updates did not include the Route Target Extended Community required > by the route-reflector clients which identifies which VRF the route belongs > too. ... > Notice the mysterious disappearance of the RT community. ... > Looking to see if anyone has seen this issue particularly with this version > of code. TAC is trying to tell me that this was a bug in a previous version > but is fixed in the code I am running. Interesting. I recently closed off a TAC case on a similar issue, but not an identical issue. In my case, it was 12.2(52)EY on an ME3600 and in my particular topology, an ME3600 wasn't announcing a plain ol' BGP community to one of it's two RRs. The extended communities were fine tho. Also, the announcements were being stuffed into two different update groups; the ME that was sending the 'good' announcement was announcing updates to update-group 1 and 2 and the ME that was announcing the 'bad' announcement was announcing updates to update-group 1 only. We didn't spend as much time as you clearly have troubleshooting the issue because we caught it before it was customer affecting. That said, at the time, I noticed the same thing; hard clearing the sessions didn't fix it. I didn't try to unconfigure the neighbour though; in my case, I was running EY on this switch and because the ME3600s are so new and EY1 was available and I knew that I'd have to reboot anyway to clear the issue, I decided to upgrade to EY1 and that seemed to clear up the problem. I haven't seen this resurface since. EY1 was available as soon as we started receiving our ME3600s, so as a policy we upgraded every one before it went into the field, except I had missed this one in particular. There were no open bugs pointing to my issue that the TAC engineer could find, but if you could pass me the case number, I'd like to give it to my engineer so he can see if your issue is somehow related to mine, just manifested in a slightly different way. From tal at whatexit.org Sat Mar 12 11:52:13 2011 From: tal at whatexit.org (Tom Limoncelli) Date: Sat, 12 Mar 2011 12:52:13 -0500 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: On Fri, Feb 11, 2011 at 8:29 PM, Tom Limoncelli wrote: > On Fri, Feb 11, 2011 at 2:56 PM, Owen DeLong wrote: >> I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. >> > > I'm writing an article where I want to say that but I can't find an > article I can reference to back it up. > > I don't want to accidentally encourage an urban legend or rumor. ?(For > example, I can't find verification to the rumor that ARIN rejected a > request from LTE providers for IPv4 space and instead told them to go > straight to IPv6. ?I do others in this thread saying that native IPv4 > on LTE is common, so unless someone can give me evidence, I'll have to > update that part of the article. ?OMG i'd love to make that point; > anyone have proof?). > > I could, instead, write, "most carriers will probably roll IPv6 out as > part of their 4G upgrade" but that sounds wishy-washy. > > Thanks in advance, > Tom > > -- > http://EverythingSysadmin.com? -- my blog (new posts Mon and Wed) > http://www.TomOnTime.com -- my advice (more videos coming soon) > The article I mentioned I was writing has been published and is now available on-line here: http://queue.acm.org/detail.cfm?id=1959015 Thanks for all the assistance both on this mailing list and the private email I received! Tom Limoncelli http://www.EverythingSysadmin.com -- Sign up for my new class "Advanced Time Mgmt: Team Efficiency" at PICC! April 29-30, New Jersey, LOPSA PICC: www.picconf.org Dec 4-9, Boston, Usenix LISA, www.usenix.org/event/lisa11 Dec 4-5, Boston, ACM CHIMIT, chimit.acm.org "Call for papers and talk proposals" open at LISA and CHIMIT! From cdel at firsthand.net Sat Mar 12 13:02:23 2011 From: cdel at firsthand.net (Christian de Larrinaga) Date: Sat, 12 Mar 2011 20:02:23 +0100 Subject: IPv6 mistakes, was: Re: Looking for an IPv6 naysayer... In-Reply-To: References: <7715397372EE344E96F03DBEA1E8894E2856E6@ADF-MBX-01.tul.solarwinds.net> <616000D2-4434-4A91-BDDD-D50894FA71B0@muada.com> <245D404E-23F1-44D0-B22B-D596E6B6C23F@muada.com> <8C26A4FDAE599041A13EB499117D3C286B3692E7@ex-mb-1.corp.atlasnetworks.us> <4D5415C6.80700@matthew.at> <5A6D953473350C4B9995546AFE9939EE0BC13A22@RWC-EX1.corp.seven.com> <4D554F29.8070903@ispalliance.net> <116E791B-4F77-47C8-9A3A-0C8034FAD95C@delong.com> Message-ID: Now that is what Baldrick* would call "a cunning plan!" And interesting examples. Christian *Apologies to Tony Robinson and Blackadder On 12 Mar 2011, at 18:52, Tom Limoncelli wrote: > On Fri, Feb 11, 2011 at 8:29 PM, Tom Limoncelli wrote: >> On Fri, Feb 11, 2011 at 2:56 PM, Owen DeLong wrote: >>> I think you'll be in for a surprise here, too. The 4G transition is already underway. For the vendors where 4G means LTE, IPv6 is the native protocol and IPv4 requires a certain amount of hackery to operate. >>> >> >> I'm writing an article where I want to say that but I can't find an >> article I can reference to back it up. >> >> I don't want to accidentally encourage an urban legend or rumor. (For >> example, I can't find verification to the rumor that ARIN rejected a >> request from LTE providers for IPv4 space and instead told them to go >> straight to IPv6. I do others in this thread saying that native IPv4 >> on LTE is common, so unless someone can give me evidence, I'll have to >> update that part of the article. OMG i'd love to make that point; >> anyone have proof?). >> >> I could, instead, write, "most carriers will probably roll IPv6 out as >> part of their 4G upgrade" but that sounds wishy-washy. >> >> Thanks in advance, >> Tom >> >> -- >> http://EverythingSysadmin.com -- my blog (new posts Mon and Wed) >> http://www.TomOnTime.com -- my advice (more videos coming soon) >> > > The article I mentioned I was writing has been published and is now > available on-line here: > > http://queue.acm.org/detail.cfm?id=1959015 > > Thanks for all the assistance both on this mailing list and the > private email I received! > > Tom Limoncelli > http://www.EverythingSysadmin.com > > -- > Sign up for my new class "Advanced Time Mgmt: Team Efficiency" at PICC! > April 29-30, New Jersey, LOPSA PICC: www.picconf.org > Dec 4-9, Boston, Usenix LISA, www.usenix.org/event/lisa11 > Dec 4-5, Boston, ACM CHIMIT, chimit.acm.org > "Call for papers and talk proposals" open at LISA and CHIMIT! > From Valdis.Kletnieks at vt.edu Sat Mar 12 14:10:00 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sat, 12 Mar 2011 15:10:00 -0500 Subject: Switching Email In-Reply-To: Your message of "Sat, 12 Mar 2011 08:16:19 EST." References: <20110311172430.36FD6F37@resin14.mta.everyone.net> <4D7AE85E.6080400@utc.edu> Message-ID: <11759.1299960600@localhost> On Sat, 12 Mar 2011 08:16:19 EST, William Herrin said: > Anyone have a list of MUAs that actually support RFC 2369 with > subscription management widgets in the GUI? Surely someone has written > one but I can't seem to find any documentation to that effect. EXMH had that support long ago: cvs repository 4/9/1999 Support for RFC2369. If a message contains RFC2369 compliant headers, a "List..." menu will appear with List related items on it. [ Note that this makes visible a mailto url related bug which you'll find described in exmh.BUGS ] -cwg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From perldork at webwizarddesign.com Sat Mar 12 15:40:48 2011 From: perldork at webwizarddesign.com (Max) Date: Sat, 12 Mar 2011 16:40:48 -0500 Subject: Switching Email In-Reply-To: <11759.1299960600@localhost> References: <20110311172430.36FD6F37@resin14.mta.everyone.net> <4D7AE85E.6080400@utc.edu> <11759.1299960600@localhost> Message-ID: On Sat, Mar 12, 2011 at 3:10 PM, wrote: > EXMH had that support long ago: > > cvs repository 4/9/1999 > ? ?Support for RFC2369. ?If a message contains RFC2369 compliant > ? ? ? ?headers, a "List..." menu will appear with List related items > ? ? ? ?on it. ?[ Note that this makes visible a mailto url related > ? ? ? ?bug which you'll find described in exmh.BUGS ] -cwg Previous big fan of NMH reporting in - was my favorite email client for many many years :) From jcdill.lists at gmail.com Sat Mar 12 15:41:13 2011 From: jcdill.lists at gmail.com (JC Dill) Date: Sat, 12 Mar 2011 13:41:13 -0800 Subject: Switching Email In-Reply-To: References: <20110311172430.36FD6F37@resin14.mta.everyone.net> <4D7AE85E.6080400@utc.edu> Message-ID: <4D7BE879.6000503@gmail.com> On 12/03/11 5:16 AM, William Herrin wrote: > On Fri, Mar 11, 2011 at 10:28 PM, Jeff Kell wrote: >> On 3/11/2011 8:24 PM, Scott Weeks wrote: >>> --- bill at herrin.us wrote: >>> From: William Herrin >>> >>> No, it isn't. Contrary to mailing list best practices, NANOG >>> unsubscribe information is stubbornly stashed in the email headers >>> ---------------------------------------------- >>> >>> That's a feature. Not a bug. :-) >> Actually, it's RFC 2369 :) > Anyone have a list of MUAs I don't have a list, but if you are viewing the email using the gmail web interface, and select the "show details" interface, you will see: from Scott Weeks reply-to surfer at mauigateway.com to nanog at nanog.org date Fri, Mar 11, 2011 at 5:24 PM subject Re: Switching Email mailing list nanog.nanog.org Filter messages from this mailing list mailed-by nanog.org unsubscribe Unsubscribe from this mailing-list Where "Filter messages from this mailing list" is a link, and "Unsubscribe from this mailing-list" is a link. Unfortunately, there's no confirmation or "undo" when you try to unsubscribe (as I just did, to test it). Oops! jc From joelja at bogus.com Sat Mar 12 15:43:14 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 12 Mar 2011 13:43:14 -0800 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> Message-ID: <4D7BE8F2.1050201@bogus.com> On 3/12/11 5:00 AM, William Herrin wrote: > On Sat, Mar 12, 2011 at 2:17 AM, Joel Jaeggli wrote: >> I'm super-tired of the "but tcams are an expensive >> non-commodity part not subject to economies of scale". this >> has been repeated ad nauseam since the raws workshop if not before. >> >> You don't have to build a lookup engine around a tcam and in fact >> you can use less power doing so even though you need more >> silicon to achieve increased parallelism. > > Hi Joel, > > You're either building a bunch of big TCAMs or a radix trie engine > with sufficient parallelism to get the same aggregate lookup rate. The trie is working acceptably in 120Gb/s linecards today. > If > there's a materially different 3rd way to build a FIB, one that works > at least as well, feel free to educate me. Don't need one, that's the point, heroic measures are not in fact required. On the trie side it's the key length O(m) that ditactates the lookup time in the trie and the worst case is therefore bounded by the straight-forward proposition (how to I forward to this /128). having generally shorter routes would got long way towards extending the route capacity of the device, but the table sizes kills you on installing and updating the fib not on the search part. > And while RIB churn doesn't > grow in lockstep with table size, it does grow. It does, it just has to not grow faster than our ability to manage it. so long as the remains the case managing the RIB remains in the domain of straight forward capacity management. compressing rib churn out of fib updates and tweaks to bgp state-machines generally is I think an area that has a lot of room for innovation, but that doesn't have to involve the forwarding plane. > Either way when you boost from 1M to 10M you're talking about > engineering challenges with heat dissipation and operating challenges > with power consumption, not to mention more transistors. We don't need 10 million routes today, we need 2 million in the class of device that currently has 512K (36Mbit CAM) (and has been in production for some time) in 3-5years... That today can/is being done with 64MB RLDRAM. In same time-frame the networks that currently need 2 million route FIBS will need 4-5M. To harp on rldram since I'm somewhat familiar with it, clearly we need faster parts with lower power consumption and it's timely that ddr3 derived parts should begin sampling at some point. > I'll be > convinced it can be done for less than 2x cost when someone actually > does it for less than 2x cost. part of the exercise is neither building nor buying the capacity before you need it. the later the features needed crystalize into silicon the more likely they are to be usable. > Whether it's 2x cost or 1.2x cost, the point remains the same: we > could have routers today that handle the terminal size of the IPv4 > table without breaking the bank. > > Your favorite router manufacturer has made vague assertions about how > they would build one given sufficient customer demand. So make a > demand. previous $employer crossed the 800K prefix count in FIBS on couple devices a while ago. I generally don't have to many cases where vendors roll their eyes and laugh hysterically when I talk about what we project our FIB requirements as, that's reserved for other features. > Regards, > Bill Herrin > > From marka at isc.org Sat Mar 12 15:46:35 2011 From: marka at isc.org (Mark Andrews) Date: Sun, 13 Mar 2011 08:46:35 +1100 Subject: Switching Email In-Reply-To: Your message of "Sat, 12 Mar 2011 08:16:19 CDT." References: <20110311172430.36FD6F37@resin14.mta.everyone.net> <4D7AE85E.6080400@utc.edu> Message-ID: <20110312214635.1F752C72F20@drugs.dv.isc.org> In message , Will iam Herrin writes: > On Fri, Mar 11, 2011 at 10:28 PM, Jeff Kell wrote: > > On 3/11/2011 8:24 PM, Scott Weeks wrote: > >> --- bill at herrin.us wrote: > >> From: William Herrin > >> > >> No, it isn't. Contrary to mailing list best practices, NANOG > >> unsubscribe information is stubbornly stashed in the email headers > >> ---------------------------------------------- > >> > >> That's a feature. =A0Not a bug. =A0:-) > > > > Actually, it's RFC 2369 =A0:) > > Anyone have a list of MUAs that actually support RFC 2369 with > subscription management widgets in the GUI? Surely someone has written > one but I can't seem to find any documentation to that effect. > > On the other hand, the very first guideline at > http://www.mail-abuse.com/an_listmgntgdlines.html is: > "Mailing list administrators must provide [...] clear and effective > instructions for unsubscribing from a mailing list." Hidden in the > headers is rather less than clear or effective. > > Even that lightweight, the CAN-SPAM act, calls for each message to > contain "clear and conspicuous notice of the opportunity [...] to > decline to receive further" messages. Headers are the ONLY way to do this so it works in all languages for all the planet. "Click here to unsubscribe" is a joke when it is written in a language you don't read. As for the CAN-SPAM act, it's also a joke. It doesn't require a pre-existing relationship where there is a chance the recipient can read the message. > -Bill > > > --=20 > William D. Herrin ................ herrin at dirtside.com=A0 bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From surfer at mauigateway.com Sat Mar 12 15:47:28 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 12 Mar 2011 13:47:28 -0800 Subject: Switching Email Message-ID: <20110312134728.36F4994B@resin16.mta.everyone.net> --- bill at herrin.us wrote: On Fri, Mar 11, 2011 at 10:28 PM, Jeff Kell wrote: > On 3/11/2011 8:24 PM, Scott Weeks wrote: >> --- bill at herrin.us wrote: >> From: William Herrin >> >> No, it isn't. Contrary to mailing list best practices, NANOG >> unsubscribe information is stubbornly stashed in the email headers >> ---------------------------------------------- >> >> That's a feature. ?Not a bug. ?:-) > > Actually, it's RFC 2369 ?:) -------------------------------------------------------- ---------------------------------------------------- On the other hand, the very first guideline at http://www.mail-abuse.com/an_listmgntgdlines.html is: "Mailing list administrators must provide [...] clear and effective instructions for unsubscribing from a mailing list." Hidden in the headers is rather less than clear or effective. ---------------------------------------------------- On the many other mailing lists I'm on folks don't even read it when it's at the bottom of the email. Having it at the bottom of every email is irritating and does not solve the problem of folks sending in the emails to the list for unsubscription. scott From surfer at mauigateway.com Sat Mar 12 15:51:07 2011 From: surfer at mauigateway.com (Scott Weeks) Date: Sat, 12 Mar 2011 13:51:07 -0800 Subject: Switching Email Message-ID: <20110312135107.36F499EB@resin16.mta.everyone.net> --- bill at herrin.us wrote: From: William Herrin colleagues. With Outlook popping new-message-notifications up on the projector while you try to give a presentation during a meeting, each containing the sender and message subject... ---------------------------------------------- I am happy I have never used Outlook for that reason and many others. Try Pine. It won't do that to you. >;-) scott From bill at herrin.us Sat Mar 12 18:27:01 2011 From: bill at herrin.us (William Herrin) Date: Sat, 12 Mar 2011 19:27:01 -0500 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: <4D7BE8F2.1050201@bogus.com> References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> <4D7BE8F2.1050201@bogus.com> Message-ID: On Sat, Mar 12, 2011 at 4:43 PM, Joel Jaeggli wrote: > On 3/12/11 5:00 AM, William Herrin wrote: >> I'll be >> convinced it can be done for less than 2x cost when someone actually >> does it for less than 2x cost. > > part of the exercise is neither building nor buying the capacity before > you need it. the later the features needed crystalize into silicon the > more likely they are to be usable. That must be my mistake then, because I thought the exercise was building it in a way that it stays built for the maximum practical number of years. When it has to be touched again (or tweaked if it gets near its limit) that's manpower. Skilled manpower plus the secondary costs from the inevitable delay deploying it is usually the most expensive thing. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jsw at inconcepts.biz Sat Mar 12 19:44:04 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sat, 12 Mar 2011 20:44:04 -0500 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> <4D7BE8F2.1050201@bogus.com> Message-ID: On Sat, Mar 12, 2011 at 7:27 PM, William Herrin wrote: > That must be my mistake then, because I thought the exercise was > building it in a way that it stays built for the maximum practical > number of years. When it has to be touched again (or tweaked if it So when you upgrade a device, you always buy the suitable device which has the highest capabilities? You put in a top-of-rack switch with 10GbE for servers with no 10GbE ports and no plans of needing 10GbE connectivity to the next round of servers? You buy a modular router for branch offices that have only a few workstations and no predictable need for upgraded connectivity? This is a good way to waste money, and a bad way to ensure that you will have the *features* you may want in the future. New features will not be back-ported to your box of choice, but you will have sunk unnecessary budget resources into that box, making it harder to justify upgrades. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jmaimon at ttec.com Sat Mar 12 21:13:55 2011 From: jmaimon at ttec.com (Joe Maimon) Date: Sat, 12 Mar 2011 22:13:55 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <20110312005649.GA12836@ussenterprise.ufp.org> References: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> <20110311185809.GA93069@ussenterprise.ufp.org> <20110312005649.GA12836@ussenterprise.ufp.org> Message-ID: <4D7C3673.6000300@ttec.com> Leo Bicknell wrote: > In a message written on Fri, Mar 11, 2011 at 04:13:13PM -0800, Owen DeLong wrote: >> On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: >>> Well, I at least think an option should be a /80, using the 48 bits >>> of MAC directly. This generates exactly the same collision potential >>> as today we have with a /64 and an EUI-64 constructed from an EUI-48 >>> ethernet address. The router is already sending RA's for SLAAC to >>> work, sending along one of a well-known set of masks would be a >>> relatively minor modification. >>> >> How would you use that on a Firewire netowrk or FDDI or any of the >> other media that uses 64-bit MAC addresses? > > It wouldn't. Yes it would. It works for any size subnet that can fit both the RA node and the auto configuring one, from /0 - /127. And it is even backwards compatible. 1) Listen to RA, discover subnet size and whether to perform autoconfiguration, for backwards compatibility, assume /64 size if not included in RA. 2a) Generate address using phy bits, right aligned up to the lesser of subnet/phy size. Use 1fff as leftmost host bits if the subnet size is 64 and the phy is 48. 2b) Use any other algorithm that may be more desirable, such as one that helps preserves privacy and that contains /dev/random as one of its inputs. The randomness can be optionally initially confined to the subnet bits that exceed the phy bits, if any. 3) Perform DAD 4a) Collision, goto 2b, remembering the previous values and avoiding them. Retry 2a and forget all avoided values when they total up to (subnet size ** 2) - 3. 4b) No collision, happy surfing. 5) RA values change/expire, goto 1 Why is the ability to blindly embed the phy L2 into an auto-configured L3 address considered a prerequisite, let alone a universally good idea? > > I'm not proposing a solution for everything, just a useful case for > some things. I don't want to change say, RIR policy that you can > allocate a /64, just allow operators to use /80's, or /96's in a > more useful way if they find that useful. > > Basically I think the IETF and IPv6 propoents went a bit too far > down the "one size fits all" route. It has nothing to do with how > many numbers may or may not be used, but everything to do with the > fact that you often have to fit inside what's been given to you. > If you're stuck with a monopoly provider who gives you a /64 to > your cable modem there should be easy options to split it up and > get some subnets. > Leaving scarcity behind should not mean kicking flexibility to the curb as well. Just because SLAAC may work best with /64 should not mean that it must only work with a /64. And failing with an unconfigurable stack when DAD detects a collision means that SLAAC is not a guaranteed safe general use option, contrasted with DHCP and the possibility of conflict detection and reaction. Using bad design choices as justification for requiring additional ones simply means that SLAAC is broken as designed. It also means attempts to fix it are going to run up against entrenched opposition. Which is readily apparent. DHCPv6 needs to be fixed with address and router options and then all DHCPv6 servers/helpers should be configurable to disable all RA on a segment by way of beaconing their own poison-reverse RA. Joe From outsider at scarynet.org Sun Mar 13 06:45:04 2011 From: outsider at scarynet.org (Alexander Maassen) Date: Sun, 13 Mar 2011 12:45:04 +0100 Subject: Why does abuse handling take so long ? Message-ID: <4D7CAE40.4030708@scarynet.org> Dear nanog members, As current maintainer of DroneBL I happen to receive a lot of unwanted packets in the form of DDoS attacks, now the DDoS itself is not the real problem, dealing with it the fast way is. Now most of you would think: Just filter it, put a big firewall in front of it, bla bla bla bla. But what I'm really talking about is the ignorance most providers show when it comes to handling the abuse when it gets reported. The issue in there being, it's way too slow, and my hoster needs to temporary nullroute my ip range in order to protect his network. We both mail all the involved providers and sometimes need to wait days before hostings act upon the mail. In most cases the only thing the abuse@ contacts do as hoster, is relay the mail to the client but do not dare to do anything themself, even if you provide them with a shitload of logs, even if you call them and say that the attack from their source is still continueing, they refuse to look into it and shutdown the source. And that pisses me off badly. Why o why are isp's and hosters so ignorant in dealing with such issues and act like they do not care? Kind regards, Alexander Maassen Maintainer DroneBL -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From goemon at anime.net Sun Mar 13 07:39:02 2011 From: goemon at anime.net (goemon at anime.net) Date: Sun, 13 Mar 2011 05:39:02 -0700 (PDT) Subject: Why does abuse handling take so long ? In-Reply-To: <4D7CAE40.4030708@scarynet.org> References: <4D7CAE40.4030708@scarynet.org> Message-ID: On Sun, 13 Mar 2011, Alexander Maassen wrote: > Why o why are isp's and hosters so ignorant in dealing with such issues > and act like they do not care? they don't act like they do not care. they really *don't* care. no acting. 1) you're not a direct customer, why should they do anything? by doing nothing it cost them nothing. 2) why should they do anything to shut down paying customers? shutting down abusive customers is shutting off revenue sources. 3) lifting a finger is too much like work. it costs the money and gains them nothing. the only way to correct this behavior is to make it more expensive for providers to retain abusive customers than it is to keep them. From sthaug at nethelp.no Sun Mar 13 08:02:47 2011 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Sun, 13 Mar 2011 14:02:47 +0100 (CET) Subject: Why does abuse handling take so long ? In-Reply-To: References: <4D7CAE40.4030708@scarynet.org> Message-ID: <20110313.140247.74714513.sthaug@nethelp.no> > > Why o why are isp's and hosters so ignorant in dealing with such issues > > and act like they do not care? > > they don't act like they do not care. they really *don't* care. no acting. Well now, I'd say this varies considerably. There are definitely ISPs that care and *do* work hard at reducing abuse. But even so - assuming I'm an ISP that cares, - You're presenting me with evidence of abuse. OK, I don't know you. Why should I believe your evidence? At best I'm going to take it as a *hint*. - If I take your evidence as a hint, I'm going to want to correlate it with my own logs. This takes time. - I probably have customer contracts in place that specify under what circumstances I can actually take the customer off net. My tolerance of abuse may not be the same as your. Also, "due process" means that these things take time. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From nenolod at systeminplace.net Sun Mar 13 08:41:07 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Sun, 13 Mar 2011 08:41:07 -0500 Subject: Why does abuse handling take so long ? In-Reply-To: References: <4D7CAE40.4030708@scarynet.org> Message-ID: <20110313084107.19530483@petrie> On Sun, 13 Mar 2011 05:39:02 -0700 (PDT) goemon at anime.net wrote: > On Sun, 13 Mar 2011, Alexander Maassen wrote: > > Why o why are isp's and hosters so ignorant in dealing with such > > issues and act like they do not care? > > they don't act like they do not care. they really *don't* care. no > acting. well, they should care. if a customer is compromised and ddosing, it costs the provider money (additional traffic being pushed bringing your 95% closer to your commit levels or possibly causing an overage to be incurred.) by doing nothing it may wind up costing them something - even if they can make the money back by passing the overage onto the customer, there is a high likelyhood that the customer will just jump ship and not pay the invoice and go elsewhere. william From fw at deneb.enyo.de Sun Mar 13 09:25:01 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 13 Mar 2011 15:25:01 +0100 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7CAE40.4030708@scarynet.org> (Alexander Maassen's message of "Sun, 13 Mar 2011 12:45:04 +0100") References: <4D7CAE40.4030708@scarynet.org> Message-ID: <871v2bnlmq.fsf@mid.deneb.enyo.de> * Alexander Maassen: > In most cases the only thing the abuse@ contacts do as hoster, is relay > the mail to the client but do not dare to do anything themself, even if > you provide them with a shitload of logs, even if you call them and say > that the attack from their source is still continueing, they refuse to > look into it and shutdown the source. And that pisses me off badly. There is a relatively nice way of putting this. If you can't contact the customer and don't know what they are doing, it is difficult to estimate the risk from terminating the customer's connectivity. Therefore, giving them some time to react---4 business hours or perhaps even a business day---seems reasonable, and this can be a very long time span for many types of network abuse, especially when time zones are taken into account. > Why o why are isp's and hosters so ignorant in dealing with such issues > and act like they do not care? The less nice way is that many hosters attract customers who don't care if they are compromised. These customers do not perceive abuse notifications as valuable, so the hoster gains nothing from forwarding them: the abuse won't stop, and the customer is likely less happy than before. From trelane at trelane.net Sun Mar 13 10:36:36 2011 From: trelane at trelane.net (Andrew Kirch) Date: Sun, 13 Mar 2011 11:36:36 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: References: <4D7CAE40.4030708@scarynet.org> Message-ID: <4D7CE484.5090002@trelane.net> On 3/13/2011 8:39 AM, goemon at anime.net wrote: > On Sun, 13 Mar 2011, Alexander Maassen wrote: >> Why o why are isp's and hosters so ignorant in dealing with such issues >> and act like they do not care? > > they don't act like they do not care. they really *don't* care. no > acting. > > 1) you're not a direct customer, why should they do anything? by doing > nothing it cost them nothing. > 2) why should they do anything to shut down paying customers? shutting > down abusive customers is shutting off revenue sources. > 3) lifting a finger is too much like work. it costs the money and > gains them nothing. > > the only way to correct this behavior is to make it more expensive for > providers to retain abusive customers than it is to keep them. > Is it time for another "notion of self-defense" in responding to/retaliating against a DDoS attack of sufficient strength to hold down a large network, or resource? Andrew From jsw at inconcepts.biz Sun Mar 13 12:20:59 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 13 Mar 2011 13:20:59 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7CAE40.4030708@scarynet.org> References: <4D7CAE40.4030708@scarynet.org> Message-ID: On Sun, Mar 13, 2011 at 7:45 AM, Alexander Maassen wrote: > In most cases the only thing the abuse@ contacts do as hoster, is relay > the mail to the client but do not dare to do anything themself, even if The RIPE IRR database contains a systemic means for operators, responsible for IP address blocks, to exchange PGP-signed messages amongst each-other in relation to security incidents. It unfortunately does not see much use: under 1% of allocations in RIPE's database include any reference to one of only 235 "incident response teams," which are conceptually similar to a POC. Other things have been tried but haven't reached "critical mass" also, such as dial-by-ASN VOIP connectivity. The real problem with handling serious network abuse is it's pretty hard to get through the "bozo filter" and actually reach anyone who might understand your request or complaint (DDoS), let alone have the power to act. The anti-spam folks have honestly made this problem far, far worse, by slamming every role mailbox they can find for every network operator, regardless of whether or not a specific mailbox for email-related abuse exists or how good (or bad) a network may be at keeping spam off its network. I hope this remark doesn't steer the thread far off-topic, but I wish the anti-spam folks would realize how counter-productive it is to intentionally send the same complaints to a multitude of different abuse mailboxes. For this reason, it really is necessary to have an automatic filtering mechanism in place just to make sure the network abuse people don't have to sift through messages which are mostly related to email abuse. If operators would decide to use a system like IRT, supported in RIPE IRR, then we would not only be able to filter out a lot of the B.S., we would also know that signed messages complaining of DDoS coming in were actually from the security folks at the complaining organization, people who have authority to make requests on behalf of the org that "owns" related netblocks. This pretty much eliminates the "why should I believe your evidence?" argument, because we shouldn't have to believe anyone's evidence to at least block traffic towards the netblocks they operate. For example: if I am an end-user with address 192.0.2.80 and my web site is being subject to DDoS which I believe is originating from 203.0.113.66, I would contact my ISP, who registers themselves as the IRT for 192.0.2.0/24. My ISP would probably do a sanity check on my claim, examine their netflow, etc. and then agree that 203.0.113.66 is a source of the DDoS. They'd see that an IRT is registered for 203.0.113.0/24 and send over a PGP-signed message to the counter-party IRT. That IRT would verify the PGP signature and association with the target of the DoS, 192.0.2.80, and at that point, they would have absolutely zero excuse for not immediately dropping all traffic from 203.0.113.66 towards me at 192.0.2.80. It doesn't matter if there are any logs or "evidence," it matters that the proven security/abuse contact for 192.0.2.0/24 requested that the counter-party stop sending traffic to 192.0.2.0/24. Whether or not the ISP for 203.0.113.66 decides to investigate any further is up to them; maybe they log some traffic, find a compromised host, and shut it down. Maybe they really don't care. Now that you know people are capable of doing all that based on data in RIPE's trusted IRR database, you may also realize that this process could be streamlined to any point between "human reads email, checks relationships, and configures network" all the way to "script reads email, checks relationships, and configures network." Implementing this could save NOCs time (if they really cared about outgoing DDoS from their networks) and improve response to network abuse. So ultimately, there is already a good framework in place to substantially "fix" this problem. No one uses it. That is unlikely to change until there is an economic incentive, such as a lawsuit by someone targeted by DoS which can be proven to be originated from a negligent network, causing calculable damages. Until some network has to pay out a million bucks because they sat on their hands, I don't see anything changing. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From joelja at bogus.com Sun Mar 13 12:24:18 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 13 Mar 2011 10:24:18 -0700 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7CE484.5090002@trelane.net> References: <4D7CAE40.4030708@scarynet.org> <4D7CE484.5090002@trelane.net> Message-ID: <4D7CFDC2.3020001@bogus.com> On 3/13/11 8:36 AM, Andrew Kirch wrote: > On 3/13/2011 8:39 AM, goemon at anime.net wrote: >> On Sun, 13 Mar 2011, Alexander Maassen wrote: >>> Why o why are isp's and hosters so ignorant in dealing with such issues >>> and act like they do not care? >> >> they don't act like they do not care. they really *don't* care. no >> acting. >> >> 1) you're not a direct customer, why should they do anything? by doing >> nothing it cost them nothing. >> 2) why should they do anything to shut down paying customers? shutting >> down abusive customers is shutting off revenue sources. >> 3) lifting a finger is too much like work. it costs the money and >> gains them nothing. >> >> the only way to correct this behavior is to make it more expensive for >> providers to retain abusive customers than it is to keep them. >> > Is it time for another "notion of self-defense" in responding > to/retaliating against a DDoS attack of sufficient strength to hold down > a large network, or resource? Because there just aren't enough internet vigilantes already... > Andrew > From morrowc.lists at gmail.com Sun Mar 13 12:27:34 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 13 Mar 2011 13:27:34 -0400 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> <4D7BE8F2.1050201@bogus.com> Message-ID: On Sat, Mar 12, 2011 at 8:44 PM, Jeff Wheeler wrote: > On Sat, Mar 12, 2011 at 7:27 PM, William Herrin wrote: >> That must be my mistake then, because I thought the exercise was >> building it in a way that it stays built for the maximum practical >> number of years. When it has to be touched again (or tweaked if it > > So when you upgrade a device, you always buy the suitable device which > has the highest capabilities? ?You put in a top-of-rack switch with > 10GbE for servers with no 10GbE ports and no plans of needing 10GbE > connectivity to the next round of servers? ?You buy a modular router > for branch offices that have only a few workstations and no > predictable need for upgraded connectivity? there's probably a different need in TOR and BO/SOHO locations than core devices, eh? From copraphage at gmail.com Sun Mar 13 12:29:17 2011 From: copraphage at gmail.com (Chris McDonald) Date: Sun, 13 Mar 2011 13:29:17 -0400 Subject: In need of an att person at the slo cls Message-ID: Please ping me off list. I'm in urgent need of escalation of a xcon. Thx Chris Cmcdonald at pccwglobal.com -- Sent from my mobile device From william.allen.simpson at gmail.com Sun Mar 13 12:31:11 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Sun, 13 Mar 2011 13:31:11 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7CAE40.4030708@scarynet.org> References: <4D7CAE40.4030708@scarynet.org> Message-ID: <4D7CFF5F.8060507@gmail.com> On 3/13/11 7:45 AM, Alexander Maassen wrote: > Why o why are isp's and hosters so ignorant in dealing with such issues > and act like they do not care? > Because network operators rarely get together and turn off routing to abusive hosting. On the few occasions that has happened, it took years of consensus building. So, part of the problem is *your* upstream. Why didn't your upstream actively remove the entire abusive netblock? Why didn't your upstream contact other providers with your evidence, and together remove the abusive network from the global routing tables? As we get more experience with global "cyberwar", we're going to need faster response mechanisms. What will we do as some major government coordinates an attack on another? What will we do as some major North American government coordinates an attack on another region or facility? From jsw at inconcepts.biz Sun Mar 13 13:11:34 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 13 Mar 2011 14:11:34 -0400 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> <4D7BE8F2.1050201@bogus.com> Message-ID: On Sun, Mar 13, 2011 at 1:27 PM, Christopher Morrow wrote: > there's probably a different need in TOR and BO/SOHO locations than > core devices, eh? In today's backbone, this is certainly true. Feature-driven upgrades shouldn't be much of a factor for "P boxes" today, because modern networks have the option of simply label-switching in the core (just like 1990s networks could ATM/Frame-switch) without doing much of anything else. Feature-driven upgrades should be largely confined to "PE boxes." For the same reason, upgrading a P box should be easy, not hard. After all, it's just label-switching. In today's backbones, it should be more practical than ever to buy the most cost-effective box needed for now and the predictable near-term. Cost per gigabit continues to fall. Buying dramatically more capacity than is planned to be necessary sinks capital dollars into a box that does nothing but depreciate. I realize that organizationally-painful budgeting and purchasing processes often drive networks to buy the biggest thing available. Vendors understand this, too: they love to sell you a much bigger box than you need just because upgrading is hard to get approved so you don't want to do it any more frequently than necessary, even when that behavior is detrimental to cash-flow and bottom line. The more broken your organization, the more you need to spend extra money on "too big" boxes. Sounds pretty self-defeating, doesn't it? -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From morrowc.lists at gmail.com Sun Mar 13 14:42:28 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 13 Mar 2011 15:42:28 -0400 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> <4D7BE8F2.1050201@bogus.com> Message-ID: On Sun, Mar 13, 2011 at 2:11 PM, Jeff Wheeler wrote: > On Sun, Mar 13, 2011 at 1:27 PM, Christopher Morrow > wrote: >> there's probably a different need in TOR and BO/SOHO locations than >> core devices, eh? > > In today's backbone, this is certainly true. ?Feature-driven upgrades > shouldn't be much of a factor for "P boxes" today, because modern > networks have the option of simply label-switching in the core (just > like 1990s networks could ATM/Frame-switch) without doing much of > anything else. ?Feature-driven upgrades should be largely confined to > "PE boxes." > not everyone drinks the mpls koolaide... so it's not always 'just a label switch' and depending upon how large your PE mesh is, there are still some challenges in scaling this. MPLS also only shifts the burden to another place, if you provide ip-transit and you need a full table you'll have to put those routes somewhere. Sure the 'core' may not need that info, but the edge likely does, yes? Have 100g customers today? planning on having them in the next ~8/12/18 months? > For the same reason, upgrading a P box should be easy, not hard. > After all, it's just label-switching. ?In today's backbones, it should upgrades aren't hard, unless you get yourself into a SPOF situation with the 'P' router(s)... mechanically the upgrades aren't hard. Cost-wise though it could be, it depends upon your particular cost structure I imagine. > be more practical than ever to buy the most cost-effective box needed > for now and the predictable near-term. ?Cost per gigabit continues to > fall. ?Buying dramatically more capacity than is planned to be > necessary sinks capital dollars into a box that does nothing but > depreciate. The discussion at the RAWS meeting, and which seems to hold true for larger networks, is that a box lives in the network for ~5-7 years. First, for the core-class device today, in the core, then progressively further to the edge. Some thought goes into 'today I have X requirements, I can project based on some set of metrics I'll have X+Y tomorrow.' > I realize that organizationally-painful budgeting and purchasing > processes often drive networks to buy the biggest thing available. > Vendors understand this, too: they love to sell you a much bigger box > than you need just because upgrading is hard to get approved so you > don't want to do it any more frequently than necessary, even when that > behavior is detrimental to cash-flow and bottom line. ?The more broken > your organization, the more you need to spend extra money on "too big" > boxes. ?Sounds pretty self-defeating, doesn't it? sometimes... sometimes it's just business. I suppose the point here is that a box doesn't live ~12 months or even 24, it lives longer. Planning that horizon today is problematic when a box today (even the largest box) tops out just north of 2m routes (v4, I forget the mix v4/6 numbers). your network design may permit you to side step that issue in places, but planning for that number is painful today. -Chris From bruns at 2mbit.com Sun Mar 13 14:59:43 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 13 Mar 2011 13:59:43 -0600 Subject: Why does abuse handling take so long ? In-Reply-To: <20110313.140247.74714513.sthaug@nethelp.no> References: <4D7CAE40.4030708@scarynet.org> <20110313.140247.74714513.sthaug@nethelp.no> Message-ID: <4D7D222F.10608@2mbit.com> On 3/13/11 7:02 AM, sthaug at nethelp.no wrote: > Well now, I'd say this varies considerably. There are definitely ISPs > that care and*do* work hard at reducing abuse. But even so - assuming > I'm an ISP that cares, > > - You're presenting me with evidence of abuse. OK, I don't know you. > Why should I believe your evidence? At best I'm going to take it as a > *hint*. > - If I take your evidence as a hint, I'm going to want to correlate it > with my own logs. This takes time. This also applies in reverse when your asking to get out of a DNSbl. FWIW, when you deal with me on getting out of the AHBL, how well you handle my abuse report affects how well I handle your request to be delisted. :) effort in == effort out > - I probably have customer contracts in place that specify under what > circumstances I can actually take the customer off net. My tolerance > of abuse may not be the same as your. Also, "due process" means that > these things take time. You aren't by chance related to Andrew Stevens? He's been going on recently about "due process" (quotes and all) to the point where certain newsgroups are flooded with socks. If not, then you have my apology :) > > Steinar Haug, Nethelp consulting,sthaug at nethelp.no -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From trelane at trelane.net Sun Mar 13 15:03:18 2011 From: trelane at trelane.net (Andrew Kirch) Date: Sun, 13 Mar 2011 16:03:18 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7CFDC2.3020001@bogus.com> References: <4D7CAE40.4030708@scarynet.org> <4D7CE484.5090002@trelane.net> <4D7CFDC2.3020001@bogus.com> Message-ID: <4D7D2306.7040008@trelane.net> On 3/13/2011 1:24 PM, Joel Jaeggli wrote: > On 3/13/11 8:36 AM, Andrew Kirch wrote:= >> Is it time for another "notion of self-defense" in responding >> to/retaliating against a DDoS attack of sufficient strength to hold down >> a large network, or resource? > Because there just aren't enough internet vigilantes already... > The problem does seem to persist. 10 years later and DDoS, it's mitigation, and asleep at the switch abuse departments are still a problem. From bruns at 2mbit.com Sun Mar 13 15:05:08 2011 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 13 Mar 2011 14:05:08 -0600 Subject: Why does abuse handling take so long ? In-Reply-To: <20110313084107.19530483@petrie> References: <4D7CAE40.4030708@scarynet.org> <20110313084107.19530483@petrie> Message-ID: <4D7D2374.8080100@2mbit.com> On 3/13/11 7:41 AM, William Pitcock wrote: > well, they should care. if a customer is compromised and ddosing, it > costs the provider money (additional traffic being pushed bringing your > 95% closer to your commit levels or possibly causing an overage to be > incurred.) > > by doing nothing it may wind up costing them something - even if they > can make the money back by passing the overage onto the customer, there > is a high likelyhood that the customer will just jump ship and not pay > the invoice and go elsewhere. > > william In the case of a DoS, a call to the legal dept of the ISP might do the trick. One successful lawsuit against a provider for knowingly allowing their customers to DoS/DDoS would certainly change alot of attitudes about the value of an abuse desk. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From fw at deneb.enyo.de Sun Mar 13 16:33:11 2011 From: fw at deneb.enyo.de (Florian Weimer) Date: Sun, 13 Mar 2011 22:33:11 +0100 Subject: Why does abuse handling take so long ? In-Reply-To: (Jeff Wheeler's message of "Sun, 13 Mar 2011 13:20:59 -0400") References: <4D7CAE40.4030708@scarynet.org> Message-ID: <87wrk2k8o8.fsf@mid.deneb.enyo.de> * Jeff Wheeler: > On Sun, Mar 13, 2011 at 7:45 AM, Alexander Maassen > wrote: >> In most cases the only thing the abuse@ contacts do as hoster, is relay >> the mail to the client but do not dare to do anything themself, even if > > The RIPE IRR database contains a systemic means for operators, > responsible for IP address blocks, to exchange PGP-signed messages > amongst each-other in relation to security incidents. It > unfortunately does not see much use: under 1% of allocations in RIPE's > database include any reference to one of only 235 "incident response > teams," which are conceptually similar to a POC. Not that the IRTs are often not the party you want to talk to anyway. They don't run the box, and in many cases, they don't even run the network, so they can put in filters (even if they wanted). In many cases, the IRT object routes complaints *away* from the party who is capable of taking action. From jsw at inconcepts.biz Sun Mar 13 16:40:49 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 13 Mar 2011 17:40:49 -0400 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> <4D7BE8F2.1050201@bogus.com> Message-ID: On Sun, Mar 13, 2011 at 3:42 PM, Christopher Morrow wrote: > not everyone drinks the mpls koolaide... so it's not always 'just a > label switch' and depending upon how large your PE mesh is, there are If it isn't just a label switch, then features can (and sometimes do) drive upgrades (therefore costs.) > not need that info, but the edge likely does, yes? Have 100g customers > today? planning on having them in the next ~8/12/18 months? If you did your purchasing the way Bill Herrin suggests, you'd buy a box with 100GbE ports for a POP or branch that is not projected to have 100GbE customers, just because it's the biggest box. His position is that man-power to do an upgrade is always more costly than capital dollars for the actual equipment, and ignores the fact that the biggest box is by no means guaranteed to offer new *features* which may be required. I think most of your post is responding to a mis-read of my post, so I'll skip back to the FIB size question at hand: > sometimes... sometimes it's just business. I suppose the point here is > that a box doesn't live ~12 months or even 24, it lives longer. > Planning that horizon today is problematic when a box today (even the > largest box) tops out just north of 2m routes (v4, I forget the mix > v4/6 numbers). your network design may permit you to side step that > issue in places, but planning for that number is painful today. I'm not comfortable making the generalization that buying the box with the largest available FIB is always the most cost-effective choice. In some "box roles," traffic growth drives upgrades, and increased FIB size in future boxes will be one advantage of a future upgrade that also increases port speed or density. In other "box roles," features drive upgrades, and again, FIB size may increase in future boxes which will be bought anyway to gain desired features. It's foolish and overly-simplistic to assume that every box upgrade will be driven by an eventual exhaustion of FIB capacity. Currently, FIB capacity is being driven by the needs of service providers' VPN PE boxes. This is great for networks that do not have that need, because it is driving FIB capacity up (or cost down) and further reducing the chance that FIB exhaustion will trigger an upgrade before other factors, such as port speed/density/features. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jsw at inconcepts.biz Sun Mar 13 16:48:03 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 13 Mar 2011 17:48:03 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: <87wrk2k8o8.fsf@mid.deneb.enyo.de> References: <4D7CAE40.4030708@scarynet.org> <87wrk2k8o8.fsf@mid.deneb.enyo.de> Message-ID: On Sun, Mar 13, 2011 at 5:33 PM, Florian Weimer wrote: > Not that the IRTs are often not the party you want to talk to anyway. This is why my post highlights the underlying mechanism/system. It can and should be used to streamline DDoS mitigation. It is unfortunately not in practical use, since the cost of ignoring DoS originating from one's network is generally low or zero. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From goemon at anime.net Sun Mar 13 16:47:33 2011 From: goemon at anime.net (goemon at anime.net) Date: Sun, 13 Mar 2011 14:47:33 -0700 (PDT) Subject: Why does abuse handling take so long ? In-Reply-To: References: <4D7CAE40.4030708@scarynet.org> Message-ID: On Sun, 13 Mar 2011, Jeff Wheeler wrote: > So ultimately, there is already a good framework in place to > substantially "fix" this problem. No one uses it. That is unlikely > to change until there is an economic incentive, such as a lawsuit by > someone targeted by DoS which can be proven to be originated from a > negligent network, causing calculable damages. Until some network has > to pay out a million bucks because they sat on their hands, I don't > see anything changing. Exactly. Make this a question of economics and the problem will solve itself. It has to become more expensive to ignore abuse than it is to deal with it. Until that changes, the abuse will continue. From outsider at scarynet.org Sun Mar 13 17:18:56 2011 From: outsider at scarynet.org (Alexander Maassen) Date: Sun, 13 Mar 2011 23:18:56 +0100 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7CFF5F.8060507@gmail.com> References: <4D7CAE40.4030708@scarynet.org> <4D7CFF5F.8060507@gmail.com> Message-ID: <4D7D42D0.30604@scarynet.org> On 13-3-2011 18:31, William Allen Simpson wrote: > On 3/13/11 7:45 AM, Alexander Maassen wrote: >> Why o why are isp's and hosters so ignorant in dealing with such issues >> and act like they do not care? >> > > So, part of the problem is *your* upstream. Why didn't your upstream > actively remove the entire abusive netblock? Why didn't your upstream > contact other providers with your evidence, and together remove the > abusive network from the global routing tables? > My hoster did mail, his upstream is EGI, however, EGI does not want to block/filter since it would pollute their routers they say. I asked through my hoster if they would be willing to place a simple UDP filter, blocking all of it. They refuse. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From goemon at anime.net Sun Mar 13 17:34:42 2011 From: goemon at anime.net (goemon at anime.net) Date: Sun, 13 Mar 2011 15:34:42 -0700 (PDT) Subject: Why does abuse handling take so long ? In-Reply-To: <4D7D42D0.30604@scarynet.org> References: <4D7CAE40.4030708@scarynet.org> <4D7CFF5F.8060507@gmail.com> <4D7D42D0.30604@scarynet.org> Message-ID: On Sun, 13 Mar 2011, Alexander Maassen wrote: > On 13-3-2011 18:31, William Allen Simpson wrote: >> On 3/13/11 7:45 AM, Alexander Maassen wrote: >>> Why o why are isp's and hosters so ignorant in dealing with such issues >>> and act like they do not care? >> So, part of the problem is *your* upstream. Why didn't your upstream >> actively remove the entire abusive netblock? Why didn't your upstream >> contact other providers with your evidence, and together remove the >> abusive network from the global routing tables? > My hoster did mail, his upstream is EGI, however, EGI does not want to > block/filter since it would pollute their routers they say. > I asked through my hoster if they would be willing to place a simple UDP > filter, blocking all of it. They refuse. again make it a question of economics. vote with your wallet, vote with your feet. if they won't block, leave. From larry-lists at maxqe.com Sun Mar 13 17:57:32 2011 From: larry-lists at maxqe.com (Larry Brower) Date: Sun, 13 Mar 2011 17:57:32 -0500 Subject: Why does abuse handling take so long ? In-Reply-To: References: <4D7CAE40.4030708@scarynet.org> <4D7CFF5F.8060507@gmail.com> <4D7D42D0.30604@scarynet.org> Message-ID: <4D7D4BDC.7010504@maxqe.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03/13/2011 05:34 PM, goemon at anime.net wrote: > On Sun, 13 Mar 2011, Alexander Maassen wrote: >> On 13-3-2011 18:31, William Allen Simpson wrote: >>> On 3/13/11 7:45 AM, Alexander Maassen wrote: >>>> Why o why are isp's and hosters so ignorant in dealing with such issues >>>> and act like they do not care? >>> So, part of the problem is *your* upstream. Why didn't your upstream >>> actively remove the entire abusive netblock? Why didn't your upstream >>> contact other providers with your evidence, and together remove the >>> abusive network from the global routing tables? >> My hoster did mail, his upstream is EGI, however, EGI does not want to >> block/filter since it would pollute their routers they say. >> I asked through my hoster if they would be willing to place a simple UDP >> filter, blocking all of it. They refuse. > > again make it a question of economics. > > vote with your wallet, vote with your feet. > > if they won't block, leave. > leaving is not always as easy as you imply. There are some areas with only one real provider. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJNfUvcAAoJEPXCUD/44PWqje8QALqCB5SmUamIvItQSsJZ+B0t bKSDxmUszgAkFMxc9y7n1TuymOKx2lsCQmO8aQmE95NXOUloH1R89aA51DMaxxsX vt9GspDi2zuzoGngMUhl7Xuho5lxekg0nw8zEqa14MdZK/iMQw1e9D+pfl2GF43X 4KyFBqL85DrpnJhaNpQ3BB/EsM4+hMxxZYm5CAqZYKa2ywuR9LGVjQ5i0zoqc3e9 wFUAk2C/0ATf+eUhBaw6OHtpj7E2JgGfkP8K8npr27U9WVMpjBjd1ERZVy7FZ+7n rEVj+bUrW57VVvdv1UzE4rHa49Y0YXALnq05rGxuE0iCkIcth8pDI5YVYwTwsvDx gZR5H0Kmm9bQvOpvUR8TmW7BXlamVOHC1beCYHhI6Oig1bTx1DfCP+CniMnz5l3o G+sweZA589nJxonawl5qGhySCBg6a9Z4gtoYRaFsTVe8sI59JtzsbyvjdVvUwSkR UOPdPpHUuG72i3dB+/bdTKWDeGjghn6oTheVY/03oYvOLAg+8zZPupb3Ql9FARnw qb2Qc5ebzEG6wuaXlC/iHzTuc4DHp4rWvwm9tE1sQ379ntZJiKpfm0eMcdeo+xJ9 RxDg5fksOaihhM8MVRi4recdHyySzHZw9JPrx1VfhPWv3umPYt/csT0/L/EeyAJu Ybo7ahfzII26suzrAr43 =M/H6 -----END PGP SIGNATURE----- From bicknell at ufp.org Sun Mar 13 18:21:47 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 13 Mar 2011 16:21:47 -0700 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7CAE40.4030708@scarynet.org> References: <4D7CAE40.4030708@scarynet.org> Message-ID: <20110313232147.GA56804@ussenterprise.ufp.org> In a message written on Sun, Mar 13, 2011 at 12:45:04PM +0100, Alexander Maassen wrote: > Why o why are isp's and hosters so ignorant in dealing with such issues > and act like they do not care? One of the things you have to remember is that ISP's get a ton of reports, and most of them are of very low quality. Abuse queues are full of people who sign up for a properly run mailing list and then a year or two later mail abuse to get taken off saying its now spam. Or folks who misconfigure their firewall / IDS and send in reports of being DDOSed, by a nameserver, to which they are sending queries and then flagging the responses as an "attack". There are a lot of reports that don't include either the source or destination IP, or leave out any time information. Worst of all, there are the automated reports where someone has a different opinion than the law, or even reality. They create systems to basically DDOS abuse@, by reporting every case they can find individually when in fact the "spammer" is doing things legally and properly. Of course it varies greatly ISP to ISP, depends on customer mix, time of the day, time of the year and all sorts of other factors. Still, there are times when I would say less than 1 in 50 e-mails received to abuse@ is something that is a complete report and actionable Keep that in mind, along with what others have pointed out, that there is generally no "profit" in handling abuse. Quite frankly, most ISP's aren't going to take your DDOS report seriously via e-mail. If it's not bad enough to you that it is worth your time and money to make a phone call and help them track it down it is not worth their time and money to track it down and make it stop. In short, try picking up the phone. You'll bypass the entire e-mail reporting cesspool I just described, and show the ISP you actually care. 9 out of 10 times they will respond by showing they care as well. -- 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 outsider at scarynet.org Sun Mar 13 20:08:08 2011 From: outsider at scarynet.org (Alexander Maassen) Date: Mon, 14 Mar 2011 02:08:08 +0100 Subject: Why does abuse handling take so long ? In-Reply-To: <20110313232147.GA56804@ussenterprise.ufp.org> References: <4D7CAE40.4030708@scarynet.org> <20110313232147.GA56804@ussenterprise.ufp.org> Message-ID: <4D7D6A78.50108@scarynet.org> Op 14-3-2011 0:21, Leo Bicknell schreef: > > Quite frankly, most ISP's aren't going to take your DDOS report > seriously via e-mail. If it's not bad enough to you that it is > worth your time and money to make a phone call and help them track > it down it is not worth their time and money to track it down and > make it stop. > > In short, try picking up the phone. You'll bypass the entire e-mail > reporting cesspool I just described, and show the ISP you actually > care. 9 out of 10 times they will respond by showing they care as > well. > Quite frankly, been there, done that, got the t-shirt. And the answer I get most of the time there is: [loop] - Sorry, email abuse and wait for a reply - Sorry, I can't help you, wait for a reply on your abuse email - Sorry, there is nothing I can do, my hands are bound, wait for a reply from the abuse department [/loop] So much regarding the 9 out of 10. It's the 1 remaining that actually cares and tries something. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From goemon at anime.net Sun Mar 13 20:35:12 2011 From: goemon at anime.net (goemon at anime.net) Date: Sun, 13 Mar 2011 18:35:12 -0700 (PDT) Subject: Why does abuse handling take so long ? In-Reply-To: <20110313232147.GA56804@ussenterprise.ufp.org> References: <4D7CAE40.4030708@scarynet.org> <20110313232147.GA56804@ussenterprise.ufp.org> Message-ID: On Sun, 13 Mar 2011, Leo Bicknell wrote: > Quite frankly, most ISP's aren't going to take your DDOS report > seriously via e-mail. If it's not bad enough to you that it is > worth your time and money to make a phone call and help them track > it down it is not worth their time and money to track it down and > make it stop. > > In short, try picking up the phone. You'll bypass the entire e-mail > reporting cesspool I just described, and show the ISP you actually > care. 9 out of 10 times they will respond by showing they care as > well. In my experience, most phone calls cause the ISP to become immediately hostile. They find abuse report phone calls extremely threatening / scary / etc. and go into full shields-up mode. 9 out of 10 times the very first words out of their mouth is "talk to our lawyers". the remaining 1 out of 10 is "block it on your end". Email tends to be non threatening. As useless as it tends to be, it is still generally better than calling. the real cesspool is POC registries. i wish arin would start revoking allocations for entities with invalid POCs. From ops.lists at gmail.com Sun Mar 13 20:55:48 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 14 Mar 2011 07:25:48 +0530 Subject: Why does abuse handling take so long ? In-Reply-To: References: <4D7CAE40.4030708@scarynet.org> <20110313232147.GA56804@ussenterprise.ufp.org> Message-ID: Depends on what you're yelling at them about and what you tell them. I've picked up the phone and had a NOC guy at a russian SP (can't remember which, Caravan I think) kill off a syn flood that was hitting us promptly, at like 1 AM their time. On Mon, Mar 14, 2011 at 7:05 AM, wrote: > > In my experience, most phone calls cause the ISP to become immediately > hostile. They find abuse report phone calls extremely threatening / scary / > etc. and go into full shields-up mode. 9 out of 10 times the very first > words out of their mouth is "talk to our lawyers". the remaining 1 out of 10 > is "block it on your end". > > Email tends to be non threatening. As useless as it tends to be, it is still > generally better than calling. > > the real cesspool is POC registries. i wish arin would start revoking > allocations for entities with invalid POCs. -- Suresh Ramasubramanian (ops.lists at gmail.com) From bill at herrin.us Sun Mar 13 20:56:33 2011 From: bill at herrin.us (William Herrin) Date: Sun, 13 Mar 2011 21:56:33 -0400 Subject: estimation of number of DFZ IPv4 routes at peak in the future In-Reply-To: References: <20110309054348.GA46879@puck.nether.net> <91E4F353-2C3A-4E49-9001-4DE078974675@istaff.org> <1299886761.16616.22.camel@sysadmin3a> <845E1195-46D2-4DB9-926F-8AEF4D833BB7@delong.com> <4D7BE8F2.1050201@bogus.com> Message-ID: On Sun, Mar 13, 2011 at 5:40 PM, Jeff Wheeler wrote: > On Sun, Mar 13, 2011 at 3:42 PM, Christopher Morrow > wrote: >> not need that info, but the edge likely does, yes? Have 100g customers >> today? planning on having them in the next ~8/12/18 months? > > If you did your purchasing the way Bill Herrin suggests, you'd buy a > box with 100GbE ports for a POP or branch that is not projected to > have 100GbE customers, just because it's the biggest box. Jeff, No, Chris wouldn't, because that misrepresents my suggestion. What I suggested is that you spend your efforts making solid projections and then buy a box that satisfies the targeted function for the foreseeable future. That way you don't spend manpower replacing it until something materially different than the projections occurs. Which avoids some mistaken-driven and defect-driven outages and has a myriad of similar secondary effects. Circuit outages are minimized when the CWA is on strike. Why? Because nobody's futzing with the equipment. There's a lesson there: maximize reliability by minimizing change. For your information, the ISP where I was the operations director survived the burst of the bubble. While revenues shrunk significantly it was still in the black in 2004 when I left. To the best of my knowledge it remained in the black until it was sold a few years later. There were a number of causes, but one of them was that in the key time frames we were able to crunch the capital budget to almost nothing, there being sufficient excess capacity in most of the equipment we already owned. >?His > position is that man-power to do an upgrade is always more costly than > capital dollars for the actual equipment, and ignores the fact that > the biggest box is by no means guaranteed to offer new *features* > which may be required. My position is that the terminal size of the IPv4 table is visible on the horizon. Now that it's part of the foreseeable future, I'd like to be able to buy boxes that support it. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bhmccie at gmail.com Mon Mar 14 09:30:04 2011 From: bhmccie at gmail.com (Hammer) Date: Mon, 14 Mar 2011 09:30:04 -0500 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <4D7C3673.6000300@ttec.com> References: <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> <20110311185809.GA93069@ussenterprise.ufp.org> <20110312005649.GA12836@ussenterprise.ufp.org> <4D7C3673.6000300@ttec.com> Message-ID: Nice article relating to the original subject of the post. I didn't see if it had be previously posted. http://ccie-in-3-months.blogspot.com/2011/03/trying-to-calculate-ipv6-bgp-table-in.html -Hammer- "I was a normal American nerd." -Jack Herer On Sat, Mar 12, 2011 at 9:13 PM, Joe Maimon wrote: > > > Leo Bicknell wrote: > >> In a message written on Fri, Mar 11, 2011 at 04:13:13PM -0800, Owen DeLong >> wrote: >> >>> On Mar 11, 2011, at 10:58 AM, Leo Bicknell wrote: >>> >>>> Well, I at least think an option should be a /80, using the 48 bits >>>> of MAC directly. This generates exactly the same collision potential >>>> as today we have with a /64 and an EUI-64 constructed from an EUI-48 >>>> ethernet address. The router is already sending RA's for SLAAC to >>>> work, sending along one of a well-known set of masks would be a >>>> relatively minor modification. >>>> >>>> How would you use that on a Firewire netowrk or FDDI or any of the >>> other media that uses 64-bit MAC addresses? >>> >> >> It wouldn't. >> > > Yes it would. It works for any size subnet that can fit both the RA node > and the auto configuring one, from /0 - /127. And it is even backwards > compatible. > > 1) > > Listen to RA, discover subnet size and whether to perform > autoconfiguration, for backwards compatibility, assume /64 size if not > included in RA. > > 2a) > > Generate address using phy bits, right aligned up to the lesser of > subnet/phy size. Use 1fff as leftmost host bits if the subnet size is 64 and > the phy is 48. > > 2b) > > Use any other algorithm that may be more desirable, such as one that helps > preserves privacy and that contains /dev/random as one of its inputs. The > randomness can be optionally initially confined to the subnet bits that > exceed the phy bits, if any. > > 3) > > Perform DAD > > 4a) > > Collision, goto 2b, remembering the previous values and avoiding them. > Retry 2a and forget all avoided values when they total up to (subnet size ** > 2) - 3. > > 4b) > > No collision, happy surfing. > > 5) > > RA values change/expire, goto 1 > > > Why is the ability to blindly embed the phy L2 into an auto-configured L3 > address considered a prerequisite, let alone a universally good idea? > > > > >> I'm not proposing a solution for everything, just a useful case for >> some things. I don't want to change say, RIR policy that you can >> allocate a /64, just allow operators to use /80's, or /96's in a >> more useful way if they find that useful. >> >> Basically I think the IETF and IPv6 propoents went a bit too far >> down the "one size fits all" route. It has nothing to do with how >> many numbers may or may not be used, but everything to do with the >> fact that you often have to fit inside what's been given to you. >> If you're stuck with a monopoly provider who gives you a /64 to >> your cable modem there should be easy options to split it up and >> get some subnets. >> >> > Leaving scarcity behind should not mean kicking flexibility to the curb as > well. > > Just because SLAAC may work best with /64 should not mean that it must only > work with a /64. > > And failing with an unconfigurable stack when DAD detects a collision means > that SLAAC is not a guaranteed safe general use option, contrasted with DHCP > and the possibility of conflict detection and reaction. > > Using bad design choices as justification for requiring additional ones > simply means that SLAAC is broken as designed. It also means attempts to fix > it are going to run up against entrenched opposition. Which is readily > apparent. > > DHCPv6 needs to be fixed with address and router options and then all > DHCPv6 servers/helpers should be configurable to disable all RA on a segment > by way of beaconing their own poison-reverse RA. > > Joe > > From tme at americafree.tv Mon Mar 14 10:54:15 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 14 Mar 2011 11:54:15 -0400 Subject: Rush to Fix Quake-Damaged Undersea Cables Message-ID: In this WSJ article http://online.wsj.com/article/SB10001424052748704893604576199952421569210.html or http://on.wsj.com/gaPk8V This caught my eye : About half of the existing cables running across the Pacific are damaged ... It that realistic ? That seems like much more damage than anything I have heard or seen. Regards Marshall From jason at i6ix.com Mon Mar 14 11:07:28 2011 From: jason at i6ix.com (Jason Bertoch) Date: Mon, 14 Mar 2011 12:07:28 -0400 Subject: need help about switch montior In-Reply-To: References: Message-ID: <4D7E3D40.1000505@i6ix.com> On 2011/03/12 8:51 AM, Deric Kwok wrote: > Hi > > ls there any program/way to monitor the switch port/switch status when > it reaches to certain bandwidth? > Cacti with Threshold plugin -- /Jason From william.allen.simpson at gmail.com Mon Mar 14 11:11:54 2011 From: william.allen.simpson at gmail.com (William Allen Simpson) Date: Mon, 14 Mar 2011 12:11:54 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: References: <4D7CAE40.4030708@scarynet.org> <20110313232147.GA56804@ussenterprise.ufp.org> Message-ID: <4D7E3E4A.8080503@gmail.com> On 3/13/11 9:35 PM, goemon at anime.net wrote: > the real cesspool is POC registries. i wish arin would start revoking allocations for entities with invalid POCs. > Hear, hear! Leo's remembering the old days (80s - early '90s), when we checked whois and called each others' NOCs directly. That stopped working, and we started getting front line support, who's whole purpose was to filter. Nowadays, I've often been stuck in voice prompt or voice mail hell, unable to get anybody on the phone, and cannot get any response from email, either. Ever. The big ILECs are the worst. What we need is an "abuse" for ARIN, telling them the contacts don't work properly, which ARIN could verify, revoke the allocation, and send notice to the upstream telling them to withdraw the route immediately. Force them to go through the entire allocation process from the beginning, and always assign a new block. That might make them take notice.... And shrink the routing table! Win, win! Since we'd only send notification to ARIN about an actual problem, we'd only drop the real troublemakers. To help enforce that, ARIN would also verify the reporter's contacts. :-) From myamanis at japan-telecom.com Mon Mar 14 11:15:41 2011 From: myamanis at japan-telecom.com (Masato YAMANISHI) Date: Mon, 14 Mar 2011 09:15:41 -0700 Subject: Rush to Fix Quake-Damaged Undersea Cables In-Reply-To: References: Message-ID: Hi Marshall and all, > About half of the existing cables running across the Pacific > are damaged ... > > It that realistic ? That seems like much more damage than > anything I have heard or seen. Yes, it's definetely true. Rgs, Masato > -----Original Message----- > From: Marshall Eubanks [mailto:tme at americafree.tv] > Sent: Monday, March 14, 2011 8:54 AM > To: NANOG list > Subject: Rush to Fix Quake-Damaged Undersea Cables > > In this WSJ article > > http://online.wsj.com/article/SB100014240527487048936045761999 > 52421569210.html > > or > > http://on.wsj.com/gaPk8V > > This caught my eye : > > About half of the existing cables running across the Pacific > are damaged ... > > It that realistic ? That seems like much more damage than > anything I have heard or seen. > > Regards > Marshall > > > From bicknell at ufp.org Mon Mar 14 11:35:00 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 14 Mar 2011 09:35:00 -0700 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7E3E4A.8080503@gmail.com> References: <4D7CAE40.4030708@scarynet.org> <20110313232147.GA56804@ussenterprise.ufp.org> <4D7E3E4A.8080503@gmail.com> Message-ID: <20110314163459.GA15923@ussenterprise.ufp.org> In a message written on Mon, Mar 14, 2011 at 12:11:54PM -0400, William Allen Simpson wrote: > Leo's remembering the old days (80s - early '90s), when we checked whois and > called each others' NOCs directly. That stopped working, and we started > getting > front line support, who's whole purpose was to filter. Nowadays, I've often > been stuck in voice prompt or voice mail hell, unable to get anybody on the > phone, and cannot get any response from email, either. Ever. The big ILECs > are the worst. If you're a network operator, you probably know much better resources for getting phone numbers. That's not to say I wouldn't like to see ARIN records cleaned up, I fought that battle for a number of years. INOC DBA? Peeringdb.com? puck.nether.net/netops? I hate to say it, but if you're calling the number in Whois or on the front off www.foo.com then perhaps frontline support is exactly who you should be talking to about these issues. The entire purpose of any support organization is to filter to the appropriate folks. The more clue you show in directing your query, the more clue you'll get in response. Also, it can help if you follow the relationships. Consider two "regional" networks and two "international backbone providers", so you have a network path like: R1----ISP1----ISP2----R2 I understand we'd all like it to work that if R1 needs to reach R2 they call them directly. However sometimes calling ISP1 and making them get involved allows them to get the attention of ISP2, and finally them to get R2 to do something. I can't think of a time I wasn't able to get ahold of the right folks when I needed to do so, using publically available information. But then I don't bother people about a few spams, or 1Mbps "DDOS's", remain calm when I call, provide lots of information, and have a realistic expectation of how quickly they might be able to respond. Having answered abuse phones off and on for many years I can tell you that's the exception, not the rule. More common is to get someone calling to scream at you for 15 minutes about how you're destroying his livelyhood only to figure out that his box was misconfigured. Funny how you never even get an "I'm sorry" when that happens. -- 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 dmiller at tiggee.com Mon Mar 14 11:35:27 2011 From: dmiller at tiggee.com (David Miller) Date: Mon, 14 Mar 2011 12:35:27 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7E3E4A.8080503@gmail.com> References: <4D7CAE40.4030708@scarynet.org> <20110313232147.GA56804@ussenterprise.ufp.org> <4D7E3E4A.8080503@gmail.com> Message-ID: <4D7E43CF.2040006@tiggee.com> On 3/14/2011 12:11 PM, William Allen Simpson wrote: > On 3/13/11 9:35 PM, goemon at anime.net wrote: >> the real cesspool is POC registries. i wish arin would start revoking >> allocations for entities with invalid POCs. >> > Hear, hear! > > Leo's remembering the old days (80s - early '90s), when we checked > whois and > called each others' NOCs directly. That stopped working, and we > started getting > front line support, who's whole purpose was to filter. Nowadays, I've > often > been stuck in voice prompt or voice mail hell, unable to get anybody > on the > phone, and cannot get any response from email, either. Ever. The big > ILECs > are the worst. > > What we need is an "abuse" for ARIN, telling them the contacts don't work > properly, which ARIN could verify, revoke the allocation, and send > notice to > the upstream telling them to withdraw the route immediately. > Define "contacts don't work properly". - Email / phone number does not exist? - Email / phone was answered by unhelpful person? - Your particular issue provided in email / phone call was not addressed immediately (or within a timeframe that *you* see as appropriate)? The first can be verified objectively. The others are subjective and impossible to verify. > Force them to go through the entire allocation process from the > beginning, > and always assign a new block. That might make them take notice.... And > shrink the routing table! Win, win! > > Since we'd only send notification to ARIN about an actual problem, we'd > only drop the real troublemakers. To help enforce that, ARIN would also > verify the reporter's contacts. :-) > From patrick at ianai.net Mon Mar 14 11:54:37 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 14 Mar 2011 12:54:37 -0400 Subject: Rush to Fix Quake-Damaged Undersea Cables In-Reply-To: References: Message-ID: <77C94EE4-4DF1-4746-B66C-01C634828BFD@ianai.net> On Mar 14, 2011, at 12:15 PM, Masato YAMANISHI wrote: >> About half of the existing cables running across the Pacific >> are damaged ... >> >> It that realistic ? That seems like much more damage than >> anything I have heard or seen. > > Yes, it's definetely true. I'd like to see a list of damaged cables. I thought a lot of capacity was installed which did not go through Japan, so half the capacity across the Pacific would be most of the capacity into Japan. Or such is my understanding, which may be incorrect. Does someone have data? -- TTFN, patrick From bicknell at ufp.org Mon Mar 14 12:07:30 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 14 Mar 2011 10:07:30 -0700 Subject: Rush to Fix Quake-Damaged Undersea Cables In-Reply-To: References: Message-ID: <20110314170730.GA19363@ussenterprise.ufp.org> In a message written on Mon, Mar 14, 2011 at 11:54:15AM -0400, Marshall Eubanks wrote: > About half of the existing cables running across the Pacific are damaged ... If you have a broad view of damaged, this may be plausable. Remember that "damaged" does not mean traffic impacting in all cases, for instance... - one side of a redundant cable impacted, so no down time to actual traffic on 1+1 circuits. - Landing station in Japan has damage, or even simply no power and is running on generator. So perhaps all services are up, but it's now got to be kept fueled, and/or physical damage may require repairs in the near future. Due to great circle routing distances a lot of pacific cables go near Japan or have Japanese landing sites on their northern paths, even if going further south. I would like to see some more specific data about the types of damage to the cables, and expected time to repair. -- 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 Mon Mar 14 12:09:42 2011 From: sil at infiltrated.net (J. Oquendo) Date: Mon, 14 Mar 2011 13:09:42 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7CAE40.4030708@scarynet.org> References: <4D7CAE40.4030708@scarynet.org> Message-ID: <4D7E4BD6.1080400@infiltrated.net> On 3/13/2011 7:45 AM, Alexander Maassen wrote: > Why o why are isp's and hosters so ignorant in dealing with such issues > and act like they do not care? > > They really do take this serious as it cuts into productivity. Proof they care: http://www.infiltrated.net/voipabuse/responses/fortress-takes-abuse-serious.txt -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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 42B0 5A53 6505 6638 44BB 3943 2BF7 D83F 210A 95AF http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x2BF7D83F210A95AF From Valdis.Kletnieks at vt.edu Mon Mar 14 13:13:06 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 14 Mar 2011 14:13:06 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: Your message of "Mon, 14 Mar 2011 12:35:27 EDT." <4D7E43CF.2040006@tiggee.com> References: <4D7CAE40.4030708@scarynet.org> <20110313232147.GA56804@ussenterprise.ufp.org> <4D7E3E4A.8080503@gmail.com> <4D7E43CF.2040006@tiggee.com> Message-ID: <31556.1300126386@localhost> On Mon, 14 Mar 2011 12:35:27 EDT, David Miller said: > Define "contacts don't work properly". > - Email / phone number does not exist? > - Email / phone was answered by unhelpful person? Somewhere between these two should be "email/phone number exists, but is completely unable to serve the function" (auto-responders that tell you they can't act on your report without the information that was already in the note they are auto-responding to, in the format they requested, Level 1 desk unable to escalate to a Level 2, etc etc). -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From brent at servuhome.net Mon Mar 14 14:17:38 2011 From: brent at servuhome.net (Brent Jones) Date: Mon, 14 Mar 2011 12:17:38 -0700 Subject: need help about switch montior In-Reply-To: <4D7E3D40.1000505@i6ix.com> References: <4D7E3D40.1000505@i6ix.com> Message-ID: On Mon, Mar 14, 2011 at 9:07 AM, Jason Bertoch wrote: > On 2011/03/12 8:51 AM, Deric Kwok wrote: >> >> Hi >> >> ls there any program/way to monitor the switch port/switch status when >> it reaches to certain bandwidth? >> > > Cacti with Threshold plugin > > -- > /Jason > > ^ This. -- Brent Jones brent at servuhome.net From ahebert at pubnix.net Mon Mar 14 14:19:38 2011 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 14 Mar 2011 15:19:38 -0400 Subject: need help about switch montior In-Reply-To: References: <4D7E3D40.1000505@i6ix.com> Message-ID: <4D7E6A4A.3030207@pubnix.net> ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 On 03/14/11 15:17, Brent Jones wrote: > On Mon, Mar 14, 2011 at 9:07 AM, Jason Bertoch wrote: >> On 2011/03/12 8:51 AM, Deric Kwok wrote: >>> Hi >>> >>> ls there any program/way to monitor the switch port/switch status when >>> it reaches to certain bandwidth? >>> >> Cacti with Threshold plugin >> >> -- >> /Jason >> >> > ^ This. > From ahebert at pubnix.net Mon Mar 14 14:29:25 2011 From: ahebert at pubnix.net (Alain Hebert) Date: Mon, 14 Mar 2011 15:29:25 -0400 Subject: need help about switch montior In-Reply-To: References: <4D7E3D40.1000505@i6ix.com> Message-ID: <4D7E6C95.4030100@pubnix.net> On 03/14/11 15:17, Brent Jones wrote: > On Mon, Mar 14, 2011 at 9:07 AM, Jason Bertoch wrote: >> On 2011/03/12 8:51 AM, Deric Kwok wrote: >>> Hi >>> >>> ls there any program/way to monitor the switch port/switch status when >>> it reaches to certain bandwidth? >>> >> Cacti with Threshold plugin >> >> -- >> /Jason >> >> > ^ This. > Sorry about that. (Too jittery this morning) I was to confirm that Cacti (Lookup CactiEZ for quick testing) + Threshold plugin has been working for well over 6 months in our test lab. The site has over 18,000 thresholds and that on a single clunker, un-optimized it takes about 1m to process. We mainly placed threshold on Environment reading, Traffic High/Low, Discards and other Errors on each ports. You should check Cacti licensing, I think it is still GPL. ----- Alain Hebert ahebert at pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.net Fax: 514-990-9443 From jason at i6ix.com Mon Mar 14 15:51:13 2011 From: jason at i6ix.com (Jason Bertoch) Date: Mon, 14 Mar 2011 16:51:13 -0400 Subject: Why does abuse handling take so long ? In-Reply-To: <31556.1300126386@localhost> References: <4D7CAE40.4030708@scarynet.org> <20110313232147.GA56804@ussenterprise.ufp.org> <4D7E3E4A.8080503@gmail.com> <4D7E43CF.2040006@tiggee.com> <31556.1300126386@localhost> Message-ID: <4D7E7FC1.6020901@i6ix.com> On 3/14/2011 2:13 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 14 Mar 2011 12:35:27 EDT, David Miller said: > >> Define "contacts don't work properly". >> - Email / phone number does not exist? >> - Email / phone was answered by unhelpful person? > Somewhere between these two should be "email/phone number exists, but is > completely unable to serve the function" (auto-responders that tell you they > can't act on your report without the information that was already in the note > they are auto-responding to, in the format they requested, Level 1 desk unable > to escalate to a Level 2, etc etc). > My favorite is: -----Original Message----- > > After investigation, we have determined that this email message did not > originate from the Yahoo! Mail system. It appears that the sender of > this message forged the header information to give the impression that > it came from the Yahoo! Mail system. > > > > Original Message Follows: > ------------------------- > > Received: from nm20.bullet.mail.ac4.yahoo.com > (nm20.bullet.mail.ac4.yahoo.com > [98.139.52.217]) -- /Jason From ask at develooper.com Mon Mar 14 18:30:58 2011 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Mon, 14 Mar 2011 16:30:58 -0700 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> Message-ID: <7306CDDE-4902-498A-B301-AE9EDBC3F441@develooper.com> On Mar 11, 2011, at 11:22, Jeff Wheeler wrote: > I think there are a lot of people who throw around the SLAAC argument > like it's actually good for something. Do these people know what > SLAAC does? For core networks, it doesn't do anything. For > hosting/datacenter networks and cluster/VPS environments, again, it > doesn't do anything. Zero benefit. Doesn't SLAAC give you automatic "MAC address to IP" mapping? It'll save you manually doing that (in an otherwise well controlled environment). - ask From dotis at mail-abuse.org Mon Mar 14 18:35:05 2011 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 14 Mar 2011 16:35:05 -0700 Subject: Why does abuse handling take so long ? In-Reply-To: <4D7E3E4A.8080503@gmail.com> References: <4D7CAE40.4030708@scarynet.org> <20110313232147.GA56804@ussenterprise.ufp.org> <4D7E3E4A.8080503@gmail.com> Message-ID: <4D7EA629.9090507@mail-abuse.org> On 3/14/11 9:11 AM, William Allen Simpson wrote: > On 3/13/11 9:35 PM, goemon at anime.net wrote: >> the real cesspool is POC registries. i wish arin would start revoking >> allocations for entities with invalid POCs. >> > Hear, hear! > > Leo's remembering the old days (80s - early '90s), when we checked > whois and > called each others' NOCs directly. That stopped working, and we > started getting > front line support, who's whole purpose was to filter. Nowadays, I've > often > been stuck in voice prompt or voice mail hell, unable to get anybody > on the > phone, and cannot get any response from email, either. Ever. The big > ILECs > are the worst. > > What we need is an "abuse" for ARIN, telling them the contacts don't work > properly, which ARIN could verify, revoke the allocation, and send > notice to > the upstream telling them to withdraw the route immediately. > > Force them to go through the entire allocation process from the > beginning, > and always assign a new block. That might make them take notice.... And > shrink the routing table! Win, win! > > Since we'd only send notification to ARIN about an actual problem, we'd > only drop the real troublemakers. To help enforce that, ARIN would also > verify the reporter's contacts. :-) Distributing abusive IP addresses within IPv6 is not likely sustainable, nor would authenticating network reporters and actors. Filtering routes could be more manageable, and would leave dealing with compromised systems within popular networks. Calling for abuse management by ISPs might be an effective approach when structured not to conflict with maximizing profits. A Carbon Tax for abuse imposed by a governing organization to support an Internet remediation fund? :^) -Doug From nick at foobar.org Mon Mar 14 18:38:34 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 14 Mar 2011 23:38:34 +0000 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: <7306CDDE-4902-498A-B301-AE9EDBC3F441@develooper.com> References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> <7306CDDE-4902-498A-B301-AE9EDBC3F441@develooper.com> Message-ID: On 14 Mar 2011, at 23:30, Ask Bj?rn Hansen wrote: > Doesn't SLAAC give you automatic "MAC address to IP" mapping? It'll save you manually doing that (in an otherwise well controlled environment). No, it doesn't. On some systems, the mac address is used to create the ipv6 address, but not on others (e.g. windows 7). Nick From ask at develooper.com Mon Mar 14 18:49:13 2011 From: ask at develooper.com (=?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?=) Date: Mon, 14 Mar 2011 16:49:13 -0700 Subject: Internet Edge Router replacement - IPv6 route tablesizeconsiderations In-Reply-To: References: <4d76ca91.cf3edc0a.1f07.345d@mx.google.com> <4D76D2F6.5030301@studio442.com.au> <4D76D347.2030105@studio442.com.au> <5A6D953473350C4B9995546AFE9939EE0BC14026@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0BC14054@RWC-EX1.corp.seven.com> <4D7A33D4.7000406@ttec.com> <49506.1299866835@localhost> <7306CDDE-4902-498A-B301-AE9EDBC3F441@develooper.com> Message-ID: <6D96444F-5BC3-4965-B2E4-D70CE2C6E93A@develooper.com> On Mar 14, 2011, at 16:38, Nick Hilliard wrote: >> Doesn't SLAAC give you automatic "MAC address to IP" mapping? It'll save you manually doing that (in an otherwise well controlled environment). > > No, it doesn't. On some systems, the mac address is used to create the ipv6 address, but not on others (e.g. windows 7). Sorry, I made the mail a bit too short I supposed. "Well controlled environment" in my case is a bunch of relatively homogeneous linux server systems ("plain" hardware and virtualized), all managed by the same team. - ask -- Ask Bj?rn Hansen, http://askask.com/ From Gavin.Pearce at 3seven9.com Tue Mar 15 06:47:37 2011 From: Gavin.Pearce at 3seven9.com (Gavin Pearce) Date: Tue, 15 Mar 2011 11:47:37 -0000 Subject: 213.123.192.0/20 | 193.179.160.0/22 | 174.132.0.0/15 | 65.75.128.0/18 In-Reply-To: References: Message-ID: Morning all - anyone here responsible for any of the following: 213.123.192.0/20 (BT-ADSL) 193.179.160.0/22 (KULAJ-NET) 174.132.0.0/15 (NETBLK-THEPLANET-BLK-15) 65.75.128.0/18 (MSG-65-75-128-0) Abuse/Technical contacts gone unanswered for each (mailed 1 - 2 months ago). *sigh* Getting multiple brute force and/or spam from single IPs within those ranges against different devices on different dates. Gav -----Original Message----- From: Masato YAMANISHI [mailto:myamanis at japan-telecom.com] Sent: 14 March 2011 16:16 To: 'Marshall Eubanks'; 'NANOG list' Subject: RE: Rush to Fix Quake-Damaged Undersea Cables Hi Marshall and all, > About half of the existing cables running across the Pacific > are damaged ... > > It that realistic ? That seems like much more damage than > anything I have heard or seen. Yes, it's definetely true. Rgs, Masato > -----Original Message----- > From: Marshall Eubanks [mailto:tme at americafree.tv] > Sent: Monday, March 14, 2011 8:54 AM > To: NANOG list > Subject: Rush to Fix Quake-Damaged Undersea Cables > > In this WSJ article > > http://online.wsj.com/article/SB100014240527487048936045761999 > 52421569210.html > > or > > http://on.wsj.com/gaPk8V > > This caught my eye : > > About half of the existing cables running across the Pacific > are damaged ... > > It that realistic ? That seems like much more damage than > anything I have heard or seen. > > Regards > Marshall > > > From andrellio at yahoo.com Tue Mar 15 08:11:58 2011 From: andrellio at yahoo.com (Andrew Elliott) Date: Tue, 15 Mar 2011 06:11:58 -0700 (PDT) Subject: SP's and v4 block assignments Message-ID: <546905.53339.qm@web120919.mail.ne1.yahoo.com> Hello, Looking for information on the current standard practices for charging customers for larger than default v4 assignments. Especially with the rapidly depleting v4 space, how are SP's handling these requests? Is it safe to assume customers requesting larger blocks are willing to pay a premium? How much are SP's charging and what are the thresholds? What are default allocations based on? (ie: size of the circuit, type of product, etc...) Are SP's requiring more strict justification for said assignments? Thanks in advance, -drew From patrick at ianai.net Tue Mar 15 08:27:58 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 15 Mar 2011 09:27:58 -0400 Subject: SP's and v4 block assignments In-Reply-To: <546905.53339.qm@web120919.mail.ne1.yahoo.com> References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> Message-ID: On Mar 15, 2011, at 9:11 AM, Andrew Elliott wrote: > Looking for information on the current standard practices for charging customers > for larger than default v4 assignments. > > Especially with the rapidly depleting v4 space, how are SP's handling these > requests? Is it safe to assume customers requesting larger blocks are willing > to pay a premium? > > How much are SP's charging and what are the thresholds? What are default > allocations based on? (ie: size of the circuit, type of product, etc...) > > Are SP's requiring more strict justification for said assignments? "Larger than default"? There are rules about allocating IP space, it has to do with justification, not default sizes. Charging for them means you are likely a spammer or provider catering to spammers, and lying on your justification forms. Hopefully these types of providers will go away as space gets tighter and justifications are scrutinized more. -- TTFN, patrick From andrellio at yahoo.com Tue Mar 15 08:46:08 2011 From: andrellio at yahoo.com (Andrew Elliott) Date: Tue, 15 Mar 2011 06:46:08 -0700 (PDT) Subject: SP's and v4 block assignments In-Reply-To: References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> Message-ID: <607343.20821.qm@web120911.mail.ne1.yahoo.com> > "Larger than default"? There are rules about allocating IP space, it has to do >with justification, not default sizes. Right, by "default" I was referring to a default minimum size block assigned to a particular product (I would guess this would normally be in the range of /29 to /27). I understand justification would be required (I hope), but I was thinking of this from the perspective of trying to put the onus on the customer's to have an incentive for using their provider assigned blocks in the most efficient way. > Charging for them means you are likely a spammer or provider catering to >spammers, and lying on your justification forms. Hopefully these types of >providers will go away as space gets tighter and justifications are scrutinized >more. I understand this, but if said SP is doing this for spammers, they are likely not getting paid and only ending up with dirty blocks that nobody wants. Please understand I am discussing this based on the assumption that the additional addresses are justified by a non-spammer customer who really needs more space. I am open to the idea that charging for address space is a non-issue due to the spammer issue mentioned above, but could you please elaborate? Is it just common practice to never charge by most SPs? -drew From jlewis at lewis.org Tue Mar 15 09:02:45 2011 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 15 Mar 2011 10:02:45 -0400 (EDT) Subject: SP's and v4 block assignments In-Reply-To: References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> Message-ID: On Tue, 15 Mar 2011, Patrick W. Gilmore wrote: > On Mar 15, 2011, at 9:11 AM, Andrew Elliott wrote: > >> Looking for information on the current standard practices for charging customers >> for larger than default v4 assignments. >> >> Especially with the rapidly depleting v4 space, how are SP's handling these >> requests? Is it safe to assume customers requesting larger blocks are willing >> to pay a premium? >> >> How much are SP's charging and what are the thresholds? What are default >> allocations based on? (ie: size of the circuit, type of product, etc...) >> >> Are SP's requiring more strict justification for said assignments? > > "Larger than default"? There are rules about allocating IP space, it has to do with justification, not default sizes. > > Charging for them means you are likely a spammer or provider catering to spammers, and lying on your justification forms. Hopefully these types of providers will go away as space gets tighter and justifications are scrutinized more. You've not been an ISP for too long. Charging for IP space (even justified, not being used for spamming) is pretty common. I don't get involved in sales very often, so I don't know what we charge for them, but I know we do. I don't believe our rates for IPs have changed [yet] in anticipation of IPv4 runout. Our standard IPv4 assignment for dedi/colo single servers has been /28. For cloud, it's /32. Anything more adds to the MRC. I can see the former shrinking soon to /29 or /30 unless the customer demands more. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jcurran at arin.net Tue Mar 15 10:00:25 2011 From: jcurran at arin.net (John Curran) Date: Tue, 15 Mar 2011 15:00:25 +0000 Subject: Major ARIN Online system changes on 19 March 2010 Message-ID: <9E818434-B036-46D5-B4AD-2CCB02DC6A4E@corp.arin.net> NANOG Folks - Apologies for the cross post from ARIN-Announce, but I believe there is a potential for indirect operational impact for networks otherwise unaware. Thanks! /John John Curran President and CEO ARIN To: ARIN-Announce Posted: Wed, 9 March 2011 On 19 March, ARIN will deploy the biggest system update in the history of ARIN Online along with launching our new RESTful Provisioning system. This deployment will change the way all customers do business with ARIN, and we want to take this opportunity to remind you of what is in store. It is critical to note that all initial and additional requests for Internet number resources (IPv4, IPv6, and ASNs) will only be processed through ARIN Online. This means you will be able to complete your request via an online form, upload any required documentation, and all subsequent communication, excluding securing officer attestation, will be tracked directly in the ticket history for the request. ARIN Online can also be used to submit IPv4 and IPv6 network modifications, ASN modifications, and for all types of POC and Org management. Because there are a number of actions that customers prefer to automate, ARIN is also releasing updated templates (Version 5). This template set includes POCs, Orgs, reassignments, reallocations, and Network Modifications. The nameserver fields are being removed from the Version 5 templates; nameservers will be managed using the ARIN Online delegation management system. The new templates are available for preview at: https://www.arin.net/features/template_changes.html All templates will require the inclusion of an API key for added security and authentication. Details on API keys are available at: https://www.arin.net/features/api_keys.html All of the transactions that are available using the Version 5 templates can also be automated using the RESTful Provisioning system which will also be released at this time. Documentation on ARIN?s RESTful methods and payloads can be found at: https://www.arin.net/resources/restful-interfaces.html We have created a chart to help you visualize which actions can be performed via ARIN Online, RESTful Provisioning, and Version 5 templates. The guide, Interacting with ARIN?s Registration Services, is available for preview at: https://www.arin.net/resources/interacting.html ARIN is also releasing the previously mentioned ARIN Online delegation management system. We have created a flash tutorial on the new DNS management interface. We encourage you to view the tutorial which demonstrates how to use ARIN Online for delegation management along with new DNSSEC functionality. https://www.arin.net/knowledge/dnssec/ If you have further questions about these template changes or other upcoming features, please email hostmaster at arin.net. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From patrick at ianai.net Tue Mar 15 10:13:51 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 15 Mar 2011 11:13:51 -0400 Subject: SP's and v4 block assignments In-Reply-To: References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> Message-ID: On Mar 15, 2011, at 10:02 AM, Jon Lewis wrote: > On Tue, 15 Mar 2011, Patrick W. Gilmore wrote: >> On Mar 15, 2011, at 9:11 AM, Andrew Elliott wrote: >> >>> Looking for information on the current standard practices for charging customers >>> for larger than default v4 assignments. >>> >>> Especially with the rapidly depleting v4 space, how are SP's handling these >>> requests? Is it safe to assume customers requesting larger blocks are willing >>> to pay a premium? >>> >>> How much are SP's charging and what are the thresholds? What are default >>> allocations based on? (ie: size of the circuit, type of product, etc...) >>> >>> Are SP's requiring more strict justification for said assignments? >> >> "Larger than default"? There are rules about allocating IP space, it has to do with justification, not default sizes. >> >> Charging for them means you are likely a spammer or provider catering to spammers, and lying on your justification forms. Hopefully these types of providers will go away as space gets tighter and justifications are scrutinized more. > > You've not been an ISP for too long. Charging for IP space (even justified, not being used for spamming) is pretty common. I don't get involved in sales very often, so I don't know what we charge for them, but I know we do. I don't believe our rates for IPs have changed [yet] in anticipation of IPv4 runout. Our standard IPv4 assignment for dedi/colo single servers has been /28. For cloud, it's /32. Anything more adds to the MRC. I can see the former shrinking soon to /29 or /30 unless the customer demands more. Sorry, hasty note. Whenever someone says "how much can I charge for giving a customer more space than they need", I think "spammer". Maybe that's wrong, maybe not, but that's the bell that rang in my head. And I do hope that spammers will have their space reclaimed, because it is _not_ a justified use of space to put a /16 on a single mail server to avoid blacklists. As for your first sentence, it is true, I Am Not An Isp. :) However, I do get space from providers, and it is not at all normal for the provider to ask us for money. But then, maybe we are special. -- TTFN, patrick From bdflemin at gmail.com Tue Mar 15 10:19:08 2011 From: bdflemin at gmail.com (Brad Fleming) Date: Tue, 15 Mar 2011 10:19:08 -0500 Subject: March Madness on Demand CDN? Message-ID: Does anyone know which CDN(s) will be used for this year's March Madness On Demand? From sbras at ripe.net Tue Mar 15 10:29:16 2011 From: sbras at ripe.net (Sandra Bras) Date: Tue, 15 Mar 2011 16:29:16 +0100 Subject: Announcement: New RIPE NCC E-Learning Module DNS Vulnerabilities Message-ID: <4D7F85CC.4080905@ripe.net> I sent this as an official announcement to several RIPE mailing lists, and I am sending it to you because I think you would appreciate this information too. The RIPE NCC announced today the launch of "DNS vulnerabilities", the second module of our DNSSEC E-Learning course. This module explains two common DNS security problems: "Man in the Middle" and "Kaminsky Attack". It can be viewed at: http://www.ripe.net/lir-services/training/e-learning/dnssec/dns-vulnerabilities We will be releasing more modules in the coming months, including: Module 3 DNSSEC and RIPE Database Modules. The RIPE NCC E-Learning is a free service that is available to everyone. If you have any questions, please feel free to contact us at e-learning at ripe.net. I hope this is useful for you. Sandra Br?s Trainer/E-Learning Coordinator RIPE NCC From bicknell at ufp.org Tue Mar 15 10:31:04 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Tue, 15 Mar 2011 08:31:04 -0700 Subject: SP's and v4 block assignments In-Reply-To: References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> Message-ID: <20110315153104.GA94945@ussenterprise.ufp.org> In a message written on Tue, Mar 15, 2011 at 11:13:51AM -0400, Patrick W. Gilmore wrote: > As for your first sentence, it is true, I Am Not An Isp. :) > However, I do get space from providers, and it is not at all normal > for the provider to ask us for money. But then, maybe we are > special. I think the type of service being purchased is the difference. When buying DS-3 and up I've almost never seen providers charge for IP's. A few have a one time fee to provision, but no ongoing monthly. However, in the DSL/Cable Modem/WISP world, and to some degree in the small scale hosting world (think the < $100/month plans) it seems totally common to charge fees for IP's. One static for $10, a /29 for $30, etc. I think the issue with many of the low end plans is you are in a situation where if the customer calls in the support cost exceeds your profit for some number of years, and thus if they call in for static IP's / more IP's you charge them to recover those costs. -- 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 owen at delong.com Tue Mar 15 10:40:51 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Mar 2011 08:40:51 -0700 Subject: SP's and v4 block assignments In-Reply-To: References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> Message-ID: <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> On Mar 15, 2011, at 6:27 AM, Patrick W. Gilmore wrote: > On Mar 15, 2011, at 9:11 AM, Andrew Elliott wrote: > >> Looking for information on the current standard practices for charging customers >> for larger than default v4 assignments. >> >> Especially with the rapidly depleting v4 space, how are SP's handling these >> requests? Is it safe to assume customers requesting larger blocks are willing >> to pay a premium? >> >> How much are SP's charging and what are the thresholds? What are default >> allocations based on? (ie: size of the circuit, type of product, etc...) >> >> Are SP's requiring more strict justification for said assignments? > > "Larger than default"? There are rules about allocating IP space, it has to do with justification, not default sizes. > > Charging for them means you are likely a spammer or provider catering to spammers, and lying on your justification forms. Hopefully these types of providers will go away as space gets tighter and justifications are scrutinized more. > > -- > TTFN, > patrick > I'll point out that Comcast charges $5/month for a static IP on their business circuits. If you want more addresses, they charge even more. This is not uncommon practice. I agree with you that it's undesirable, but, it's not uncommon among the access networks. Owen From owen at delong.com Tue Mar 15 11:13:11 2011 From: owen at delong.com (Owen DeLong) Date: Tue, 15 Mar 2011 09:13:11 -0700 Subject: SP's and v4 block assignments In-Reply-To: <607343.20821.qm@web120911.mail.ne1.yahoo.com> References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <607343.20821.qm@web120911.mail.ne1.yahoo.com> Message-ID: <508838C5-A4C8-4ED1-82AB-B2A23EDD82AA@delong.com> On Mar 15, 2011, at 6:46 AM, Andrew Elliott wrote: >> "Larger than default"? There are rules about allocating IP space, it has to do >> with justification, not default sizes. > > Right, by "default" I was referring to a default minimum size block assigned to > a particular product (I would guess this would normally be in the range of /29 > to /27). I understand justification would be required (I hope), but I was > thinking of this from the perspective of trying to put the onus on the > customer's to have an incentive for using their provider assigned blocks in the > most efficient way. > IMHO, the ideal default prefix size for any end-site is still /48. (someone had to say it) Owen From andyring at inebraska.com Tue Mar 15 15:47:22 2011 From: andyring at inebraska.com (Andy Ringsmuth) Date: Tue, 15 Mar 2011 15:47:22 -0500 Subject: Microsoft contact Message-ID: <04250266-6D99-47DB-8AE2-EA0C0B24BF69@inebraska.com> Any chance there's someone on here from Microsoft that could reply to me off-list? Thanks in advance. --- Andy Ringsmuth andyring at inebraska.com From Valdis.Kletnieks at vt.edu Tue Mar 15 16:09:25 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 15 Mar 2011 17:09:25 -0400 Subject: Microsoft contact In-Reply-To: Your message of "Tue, 15 Mar 2011 15:47:22 CDT." <04250266-6D99-47DB-8AE2-EA0C0B24BF69@inebraska.com> References: <04250266-6D99-47DB-8AE2-EA0C0B24BF69@inebraska.com> Message-ID: <31744.1300223365@localhost> On Tue, 15 Mar 2011 15:47:22 CDT, Andy Ringsmuth said: > Any chance there's someone on here from Microsoft that could reply to me off-list? Always helps to say what *part* of Microsoft - the OS guys, the sales guys, the infrastructure guys, the WindowsUpdate , the HotMail guys, the.... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mike at sentex.net Tue Mar 15 16:13:08 2011 From: mike at sentex.net (Mike Tancsa) Date: Tue, 15 Mar 2011 17:13:08 -0400 Subject: gmail issues ? Message-ID: <4D7FD664.1060102@sentex.net> Anyone seeing gmail issues ? I checked at http://www.google.com/appsstatus#hl=en and it says all ok. Yet I either get an RST, or it just times out, or the 3 way handshake completes, and then just FINs my connection. I tried a number of different source IPs inside my network as well as some outside my AS. # telnet gmail-smtp-in.l.google.com 25 Trying 74.125.95.27... telnet: connect to address 74.125.95.27: Connection refused telnet: Unable to connect to remote host 17:12:29.464719 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [S], seq 688245543, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2436358711 ecr 0], length 0 17:12:29.496153 IP 209.85.225.27.25 > 64.7.153.18.19574: Flags [S.], seq 2208544696, ack 688245544, win 5672, options [mss 1430,sackOK,TS val 1980791251 ecr 2436358711,nop,wscale 6], length 0 17:12:29.496174 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [.], ack 1, win 8330, options [nop,nop,TS val 2436358743 ecr 1980791251], length 0 17:12:29.528117 IP 209.85.225.27.25 > 64.7.153.18.19574: Flags [F.], seq 1, ack 1, win 89, options [nop,nop,TS val 1980791283 ecr 2436358743], length 0 17:12:29.528135 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [.], ack 2, win 8330, options [nop,nop,TS val 2436358775 ecr 1980791283], length 0 17:12:29.528195 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [F.], seq 1, ack 2, win 8330, options [nop,nop,TS val 2436358775 ecr 1980791283], length 0 17:12:29.559511 IP 209.85.225.27.25 > 64.7.153.18.19574: Flags [.], ack 2, win 89, options [nop,nop,TS val 1980791314 ecr 2436358775], length 0 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From andyring at inebraska.com Tue Mar 15 16:16:05 2011 From: andyring at inebraska.com (Andy Ringsmuth) Date: Tue, 15 Mar 2011 16:16:05 -0500 Subject: Microsoft contact In-Reply-To: <31744.1300223365@localhost> References: <04250266-6D99-47DB-8AE2-EA0C0B24BF69@inebraska.com> <31744.1300223365@localhost> Message-ID: On Mar 15, 2011, at 4:09 PM, Valdis.Kletnieks at vt.edu wrote: > On Tue, 15 Mar 2011 15:47:22 CDT, Andy Ringsmuth said: >> Any chance there's someone on here from Microsoft that could reply to me off-list? > > Always helps to say what *part* of Microsoft - the OS guys, the sales guys, the > infrastructure guys, the WindowsUpdate , the HotMail guys, the.... My mistake - good point. Ultimately I'm trying to find someone in the Macintosh Business Unit. I know it might be a bit of a stretch on NANOG but worth a shot. -Andy From leigh.porter at ukbroadband.com Tue Mar 15 16:33:52 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 15 Mar 2011 21:33:52 -0000 Subject: gmail issues ? In-Reply-To: <4D7FD664.1060102@sentex.net> References: <4D7FD664.1060102@sentex.net> Message-ID: Yes, I have issues with IMAP at the moment. -----Original Message----- From: Mike Tancsa [mailto:mike at sentex.net] Sent: 15 March 2011 21:13 To: NANOG list Subject: gmail issues ? Anyone seeing gmail issues ? I checked at http://www.google.com/appsstatus#hl=en and it says all ok. Yet I either get an RST, or it just times out, or the 3 way handshake completes, and then just FINs my connection. I tried a number of different source IPs inside my network as well as some outside my AS. # telnet gmail-smtp-in.l.google.com 25 Trying 74.125.95.27... telnet: connect to address 74.125.95.27: Connection refused telnet: Unable to connect to remote host 17:12:29.464719 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [S], seq 688245543, win 65535, options [mss 1460,nop,wscale 3,sackOK,TS val 2436358711 ecr 0], length 0 17:12:29.496153 IP 209.85.225.27.25 > 64.7.153.18.19574: Flags [S.], seq 2208544696, ack 688245544, win 5672, options [mss 1430,sackOK,TS val 1980791251 ecr 2436358711,nop,wscale 6], length 0 17:12:29.496174 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [.], ack 1, win 8330, options [nop,nop,TS val 2436358743 ecr 1980791251], length 0 17:12:29.528117 IP 209.85.225.27.25 > 64.7.153.18.19574: Flags [F.], seq 1, ack 1, win 89, options [nop,nop,TS val 1980791283 ecr 2436358743], length 0 17:12:29.528135 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [.], ack 2, win 8330, options [nop,nop,TS val 2436358775 ecr 1980791283], length 0 17:12:29.528195 IP 64.7.153.18.19574 > 209.85.225.27.25: Flags [F.], seq 1, ack 2, win 8330, options [nop,nop,TS val 2436358775 ecr 1980791283], length 0 17:12:29.559511 IP 209.85.225.27.25 > 64.7.153.18.19574: Flags [.], ack 2, win 89, options [nop,nop,TS val 1980791314 ecr 2436358775], length 0 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From mloftis at wgops.com Tue Mar 15 19:07:29 2011 From: mloftis at wgops.com (Michael Loftis) Date: Tue, 15 Mar 2011 18:07:29 -0600 Subject: gmail issues ? In-Reply-To: <4D7FD664.1060102@sentex.net> References: <4D7FD664.1060102@sentex.net> Message-ID: On Tue, Mar 15, 2011 at 3:13 PM, Mike Tancsa wrote: > Anyone seeing gmail issues ? I checked at > http://www.google.com/appsstatus#hl=en I've been having massively delayed incoming mail since about Sunday (2011/03/13) some email taking days to come in, some still hasn't (Amazon Order status updates for example from Monday still haven't shown up yet) From grobe0ba at gmail.com Tue Mar 15 19:15:43 2011 From: grobe0ba at gmail.com (Atticus) Date: Tue, 15 Mar 2011 20:15:43 -0400 Subject: gmail issues ? In-Reply-To: References: <4D7FD664.1060102@sentex.net> Message-ID: Odd. I haven't had any problems at all. From paul at paulgraydon.co.uk Tue Mar 15 19:43:01 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 15 Mar 2011 14:43:01 -1000 Subject: gmail issues ? In-Reply-To: References: <4D7FD664.1060102@sentex.net> Message-ID: <4D800795.6090305@paulgraydon.co.uk> On 3/15/2011 2:07 PM, Michael Loftis wrote: > On Tue, Mar 15, 2011 at 3:13 PM, Mike Tancsa wrote: >> Anyone seeing gmail issues ? I checked at >> http://www.google.com/appsstatus#hl=en > I've been having massively delayed incoming mail since about Sunday > (2011/03/13) some email taking days to come in, some still hasn't > (Amazon Order status updates for example from Monday still haven't > shown up yet) > > I've been having problems with gmail sending to my works domain for a couple of months now. All e-mails that come via the gmail infrastructure are being delayed by up to an hour between two hops in their infrastructure. In typical fashion Google's support are utterly non-communicative. I've even had a friend who works for them pass on details internally to see whether that would help but no joy. The conversations I've had or heard over the last couple of years regarding their support quality leaves me reluctant to ever consider Google's Apps for Business as anything even remotely approaching suitable for such. Paul From joe at gonetforward.com Tue Mar 15 19:43:08 2011 From: joe at gonetforward.com (Joe Renwick) Date: Tue, 15 Mar 2011 17:43:08 -0700 Subject: gmail issues ? In-Reply-To: References: <4D7FD664.1060102@sentex.net> Message-ID: I have a personal gmail account and several Google Apps accounts for email and other services for my business. Been using them constantly without issue. Please follow up if you find an issue on their end... Joe On Tue, Mar 15, 2011 at 5:15 PM, Atticus wrote: > Odd. I haven't had any problems at all. > -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From r.engehausen at gmail.com Tue Mar 15 19:53:26 2011 From: r.engehausen at gmail.com (Roy) Date: Tue, 15 Mar 2011 17:53:26 -0700 Subject: gmail issues ? In-Reply-To: References: <4D7FD664.1060102@sentex.net> Message-ID: <4D800A06.3040800@gmail.com> The pop server had some problems today for my account. Cleared about an hour later. The web version of the email worked fine. Roy On 3/15/2011 5:43 PM, Joe Renwick wrote: > I have a personal gmail account and several Google Apps accounts for email > and other services for my business. Been using them constantly without > issue. Please follow up if you find an issue on their end... > > Joe > > On Tue, Mar 15, 2011 at 5:15 PM, Atticus wrote: > >> Odd. I haven't had any problems at all. >> > > From joe at gonetforward.com Tue Mar 15 22:05:43 2011 From: joe at gonetforward.com (Joe Renwick) Date: Tue, 15 Mar 2011 20:05:43 -0700 Subject: gmail issues ? In-Reply-To: <4D800A06.3040800@gmail.com> References: <4D7FD664.1060102@sentex.net> <4D800A06.3040800@gmail.com> Message-ID: I have been a happy Google Business Apps user for a good year now. I cannot think of a single outage myself, although I have had an employee complain a time or two. As I work quite a bit more, and use the services quite a bit more, and have noticed nothing I am chalking there "issue" up to user error. Anyway that said I was curious to find out how there support is as I have not really had to use it. I just logged into my admin portal and called the following phone number: 800-598-3901. Within a minute I had a capable human on the phone who spoke good english. No offense to those who don't but hey I admit it is nice to pay for a service and have the ability to communicate with their support. He says that all business apps are online as of about 10 minutes ago. He also referred me to the link below if I wanted to keep up to date on the status of services and look into any issue. Looks like they have one issue reported on the 9th so they do maintain it. Anyway I am satisfied with the support. http://www.google.com/appsstatus#hl=en Thanks for the conversation... motivated me to get all the support information jotted down in case I do run into something. Cheers, Joe On Tue, Mar 15, 2011 at 5:53 PM, Roy wrote: > > > The pop server had some problems today for my account. Cleared about an > hour later. The web version of the email worked fine. > > Roy > > On 3/15/2011 5:43 PM, Joe Renwick wrote: > >> I have a personal gmail account and several Google Apps accounts for email >> and other services for my business. Been using them constantly without >> issue. Please follow up if you find an issue on their end... >> >> Joe >> >> On Tue, Mar 15, 2011 at 5:15 PM, Atticus wrote: >> >> Odd. I haven't had any problems at all. >>> >>> >> >> > > -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From ryan.landry at gmail.com Tue Mar 15 22:49:56 2011 From: ryan.landry at gmail.com (ryanL) Date: Tue, 15 Mar 2011 21:49:56 -0600 Subject: US .mil blocking in Japan Message-ID: should i be surprised that this hasn't been discussed much? anyone care to elaborate and/or expand on the real telecom damage done in japan? re: http://on.cnn.com/h8wiYg .rL From mysidia at gmail.com Wed Mar 16 00:31:23 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Wed, 16 Mar 2011 00:31:23 -0500 Subject: SP's and v4 block assignments In-Reply-To: <546905.53339.qm@web120919.mail.ne1.yahoo.com> References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> Message-ID: On Tue, Mar 15, 2011 at 8:11 AM, Andrew Elliott wrote: > How much are SP's charging and what are the thresholds? ?What are default > allocations based on? ?(ie: size of the circuit, type of product, etc...) For IPv4, there are policies provided by ARIN for this; they come from RFC 2050. To be in compliance with registry addressing policies, SPs and anyone else acting as a LIR have to apply a utilization criterion, for anything /29 or larger, at least, and collect documentation such as network designs and contact details from their downstream user (for SWIP or RWHOIS), and the utilization criterion is how the amount of IP space that the ISP is allowed to delegated is determined. There is no provision or thing allowed called "pay for IP addresses". You either have the unique hosts to justify that many IPs or you don't. If you don't have the hosts and justified need, an SP can't sell you as many IPs as you like. However, if a SP has very little IP address space left to allocate, going forward, the SPs with no IPs left are likely to limit allocations they would make without additional payment to subscribers of low margin products, to a smaller delegation than could be allowed or justified by the utilization criterion. The availability and cost of IP addresses through ARIN 8.3 Specified Transfer arrangements is likely to have a major effect: if the approximate "cost for an IP address" by specified transfer is low enough, it will give an SPs a convenient number they can say they need to charge for IP addresses (which SPs may just roll into the cost of service, with possible discounts to networks bringing their own IPs). If the specified transfer market is reasonably stable in pricing and availability of IPs, under those circumstances you could see a "price per IP" begin to appear. I don't think there are any 'hard and fast' thresholds. But a SP is not likely to currently delegate a /24 for the average home DSL or 20 meg Ethernet user, for example, even if they've got 200 hosts. Without additional negotiation and payment (unless that's some really expensive 10 meg service.) If IPs are that scarce, that user (to get a /24) for example, is ultimately going to need to pay enough to make up for the lost opportunity to sell products that require a unique IP addresses which would not be tied up if that user didn't get the entire /24. Some SPs might even need to start reviewing subdelegations they already made, to verify the utilization criterion is still met, or increase prices for the service, based on opportunity costs due to utilized IP addresses, if they are short on IPs and could use them to sell more product, or profit by disposing of the IPs via disaggregating their block and listing on the specified transfer market.... -- -JH From nathalie at ripe.net Wed Mar 16 04:04:48 2011 From: nathalie at ripe.net (Nathalie Trenaman) Date: Wed, 16 Mar 2011 10:04:48 +0100 Subject: Creating an IPv6 addressing plan for end users Message-ID: Hi all, In our IPv6 courses, we often get the question: I give my customers a /48 (or a /56 or a /52) but they have no idea how to distribute that space in their network. In December Sander Steffann and Surfnet wrote a manual explaining exactly that, in clear language with nice graphics. A very useful document but it was in Dutch, so RIPE NCC decided to translate that document to English. Yesterday, we have published that document on our website and we hope this document is able to take away some of the fear that end users seem to have for these huge blocks. You can find this document here: http://bit.ly/IPv6addrplan (PDF) I look forward to your feedback, tips and comments. With kind regards, Nathalie Trenaman RIPE NCC Trainer From bkain1 at ford.com Wed Mar 16 07:27:45 2011 From: bkain1 at ford.com (Kain, Rebecca (.)) Date: Wed, 16 Mar 2011 08:27:45 -0400 Subject: gmail issues ? In-Reply-To: References: <4D7FD664.1060102@sentex.net> Message-ID: <1370D6F16AD7E843BBBCA5DA3BCB71D505D10150@na1fcm32.fmc1.ford.com> I was seeing the same yesterday between 5:30 and 6pm, eastern time -----Original Message----- From: Michael Loftis [mailto:mloftis at wgops.com] Sent: Tuesday, March 15, 2011 8:07 PM To: Mike Tancsa Cc: NANOG list Subject: Re: gmail issues ? On Tue, Mar 15, 2011 at 3:13 PM, Mike Tancsa wrote: > Anyone seeing gmail issues ? I checked at > http://www.google.com/appsstatus#hl=en I've been having massively delayed incoming mail since about Sunday (2011/03/13) some email taking days to come in, some still hasn't (Amazon Order status updates for example from Monday still haven't shown up yet) From jaitken at aitken.com Wed Mar 16 07:58:20 2011 From: jaitken at aitken.com (Jeff Aitken) Date: Wed, 16 Mar 2011 12:58:20 +0000 Subject: US .mil blocking in Japan In-Reply-To: References: Message-ID: <20110316125820.GC49411@eagle.aitken.com> On Tue, Mar 15, 2011 at 09:49:56PM -0600, ryanL wrote: > should i be surprised that this hasn't been discussed much? anyone care to > elaborate and/or expand on the real telecom damage done in japan? What's to be surprised about? The US military is temporarily blocking access to certain high-traffic web sites on its networks. This obviously affects only those users on DoD networks. What "damage" are you referring to? --Jeff From fortitude.zhang at gmail.com Wed Mar 16 08:29:57 2011 From: fortitude.zhang at gmail.com (Dongya Zhang) Date: Wed, 16 Mar 2011 06:29:57 -0700 (PDT) Subject: gmail issues ? In-Reply-To: <1370D6F16AD7E843BBBCA5DA3BCB71D505D10150@na1fcm32.fmc1.ford.com> References: <4D7FD664.1060102@sentex.net> <1370D6F16AD7E843BBBCA5DA3BCB71D505D10150@na1fcm32.fmc1.ford.com> Message-ID: <20110316.212958.123866140.fortitude.zhang@gmail.com> From: "Kain, Rebecca (.)" Subject: RE: gmail issues ? Date: Wed, 16 Mar 2011 08:27:45 -0400 > > I was seeing the same yesterday between 5:30 and 6pm, eastern time > > -----Original Message----- > From: Michael Loftis [mailto:mloftis at wgops.com] > Sent: Tuesday, March 15, 2011 8:07 PM > To: Mike Tancsa > Cc: NANOG list > Subject: Re: gmail issues ? > > On Tue, Mar 15, 2011 at 3:13 PM, Mike Tancsa wrote: >> Anyone seeing gmail issues ? I checked at >> http://www.google.com/appsstatus#hl=en > > I've been having massively delayed incoming mail since about Sunday > (2011/03/13) some email taking days to come in, some still hasn't > (Amazon Order status updates for example from Monday still haven't > shown up yet) > > ??????????????? From andrew.wallace at rocketmail.com Wed Mar 16 11:14:13 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Wed, 16 Mar 2011 09:14:13 -0700 (PDT) Subject: US .mil blocking in Japan Message-ID: <582587.43563.qm@web59616.mail.ac4.yahoo.com> On Wed, Mar 16, 2011 at 12:58 PM, Jeff Aitken wrote: > What's to be surprised about? This isn't the rhetoric of a super power, more like one of a university campus. To think these guys have built a cyber command with war waging capabilities, and allegedly capable of building nuclear worms such as Stuxnet. It strikes me straight away as amateurish to be blocking web sites in able to have enough bandwidth for operational purposes. You would think their war fighting networks, weren't the same ones used for civilian-based web sites on the public internet. It seems there is a conflict here between what they push out to the media as to what their cyber capabilities are, and what the realities are on the ground. In that respect, yes I'm very surprised. --- Andrew From joesox at gmail.com Wed Mar 16 11:49:17 2011 From: joesox at gmail.com (JoeSox) Date: Wed, 16 Mar 2011 09:49:17 -0700 Subject: US .mil blocking in Japan In-Reply-To: <582587.43563.qm@web59616.mail.ac4.yahoo.com> References: <582587.43563.qm@web59616.mail.ac4.yahoo.com> Message-ID: Andrew, I am not sure I understand your statement (below). The ONE-NET network is what I have worked on in the past while in the Navy Reserve http://findarticles.com/p/articles/mi_m0OBA/is_1_23/ai_n15390013/ http://www.marketwire.com/press-release/Multimax-Awarded-74-Million-in-Options-for-Navys-ONE-NET-Program-726586.htm The military has a bunch of sub systems that can integrate with crypto devices. In any event, military end users need classified and unclassified networks for their desktops and I am guessing the article is talking about military unclassified networks which provides internet access. -- Joe On Wed, Mar 16, 2011 at 9:14 AM, andrew.wallace wrote: >You would think their war fighting networks, weren't the same ones used for civilian-based web sites on the public internet. It seems there is a conflict here between what they push out to the media as to what their cyber capabilities are, and what the realities are on the ground. In that respect, yes I'm very surprised. --- Andrew > From achatz at forthnet.gr Wed Mar 16 11:56:28 2011 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Wed, 16 Mar 2011 18:56:28 +0200 Subject: bfd-like mechanism for LANPHY connections between providers Message-ID: <4D80EBBC.6040202@forthnet.gr> Are there any transit providers out there that accept using the BFD (or any other similar) mechanism for eBGP peerings? If no, how do you solve the issue with the physical interface state when LANPHY connections are used? Anyone messing with the BGP timers? If yes, what about multiple LAN connections with a single BGP peering? -- Tassos From ras at e-gerbil.net Wed Mar 16 12:03:43 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 16 Mar 2011 12:03:43 -0500 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: <4D80EBBC.6040202@forthnet.gr> References: <4D80EBBC.6040202@forthnet.gr> Message-ID: <20110316170343.GA68199@gerbil.cluepon.net> On Wed, Mar 16, 2011 at 06:56:28PM +0200, Tassos Chatzithomaoglou wrote: > Are there any transit providers out there that accept using the BFD (or > any other similar) mechanism for eBGP peerings? > If no, how do you solve the issue with the physical interface state when > LANPHY connections are used? > Anyone messing with the BGP timers? If yes, what about multiple LAN > connections with a single BGP peering? Well first off LAN PHY has a perfectly useful link state. That's pretty much the ONLY thing it has in the way of native OAM, but it does have that, and that's normally good enough to bring down your EBGP session quickly. Personally I find the risk of false positives when speaking to other people's random bad BGP implementations to be too great if you go much below 30 sec hold timers (and sadly, even 30 secs is too low for some people). We (nLayer) are still waiting for our first customer to request BFD, we'd be happy to offer it (with reasonable timer values of course). :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From achatz at forthnet.gr Wed Mar 16 13:25:58 2011 From: achatz at forthnet.gr (Tassos Chatzithomaoglou) Date: Wed, 16 Mar 2011 20:25:58 +0200 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: <20110316170343.GA68199@gerbil.cluepon.net> References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> Message-ID: <4D8100B6.9070602@forthnet.gr> Richard A Steenbergen wrote on 16/03/2011 19:03: > On Wed, Mar 16, 2011 at 06:56:28PM +0200, Tassos Chatzithomaoglou wrote: > >> Are there any transit providers out there that accept using the BFD (or >> any other similar) mechanism for eBGP peerings? >> If no, how do you solve the issue with the physical interface state when >> LANPHY connections are used? >> Anyone messing with the BGP timers? If yes, what about multiple LAN >> connections with a single BGP peering? >> > Well first off LAN PHY has a perfectly useful link state. That's pretty > much the ONLY thing it has in the way of native OAM, but it does have > that, and that's normally good enough to bring down your EBGP session > quickly. Personally I find the risk of false positives when speaking to > other people's random bad BGP implementations to be too great if you go > much below 30 sec hold timers (and sadly, even 30 secs is too low for > some people). We (nLayer) are still waiting for our first customer to > request BFD, we'd be happy to offer it (with reasonable timer values of > course). :) > > Link state is good for the local connection. If there are multiple intermediate optical points (not managed by either party), or a lan switch (IX environment), you won't get any link notification for everything not connected locally to your interface, unless there is a mechanism to signal that to you. -- Tassos From JTyler at fiberutilities.com Wed Mar 16 13:33:51 2011 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Wed, 16 Mar 2011 13:33:51 -0500 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: <4D8100B6.9070602@forthnet.gr> References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> Message-ID: <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> We are going to turn up BFD with Level3 this Saturday. They require that you run a Juniper(per SE). Its sounds like it is fairly new as there was no paperwork to request the service, had to put it in the notes. We have many switches between us and Level3 so we don't get a "interface down" to drop the session in the event of a failure. -----Original Message----- From: Tassos Chatzithomaoglou [mailto:achatz at forthnet.gr] Sent: Wednesday, March 16, 2011 1:26 PM To: nanog at nanog.org Subject: Re: bfd-like mechanism for LANPHY connections between providers Richard A Steenbergen wrote on 16/03/2011 19:03: > On Wed, Mar 16, 2011 at 06:56:28PM +0200, Tassos Chatzithomaoglou wrote: > >> Are there any transit providers out there that accept using the BFD (or >> any other similar) mechanism for eBGP peerings? >> If no, how do you solve the issue with the physical interface state when >> LANPHY connections are used? >> Anyone messing with the BGP timers? If yes, what about multiple LAN >> connections with a single BGP peering? >> > Well first off LAN PHY has a perfectly useful link state. That's pretty > much the ONLY thing it has in the way of native OAM, but it does have > that, and that's normally good enough to bring down your EBGP session > quickly. Personally I find the risk of false positives when speaking to > other people's random bad BGP implementations to be too great if you go > much below 30 sec hold timers (and sadly, even 30 secs is too low for > some people). We (nLayer) are still waiting for our first customer to > request BFD, we'd be happy to offer it (with reasonable timer values of > course). :) > > Link state is good for the local connection. If there are multiple intermediate optical points (not managed by either party), or a lan switch (IX environment), you won't get any link notification for everything not connected locally to your interface, unless there is a mechanism to signal that to you. -- Tassos From jaitken at aitken.com Wed Mar 16 13:48:11 2011 From: jaitken at aitken.com (Jeff Aitken) Date: Wed, 16 Mar 2011 18:48:11 +0000 Subject: US .mil blocking in Japan In-Reply-To: <582587.43563.qm@web59616.mail.ac4.yahoo.com> References: <582587.43563.qm@web59616.mail.ac4.yahoo.com> Message-ID: <20110316184811.GB59111@eagle.aitken.com> On Wed, Mar 16, 2011 at 09:14:13AM -0700, andrew.wallace wrote: > This isn't the rhetoric of a super power, more like one of a university > campus. [...] It strikes me straight away as amateurish to be blocking > web sites in able to have enough bandwidth for operational purposes. On the contrary, it's entirely plausible that US forces assisting with the recovery are (1) using more communications resources than normal, and (2) relying on infrastructure that's operating in a degraded state due to fiber or power issues. If so, it's entirely reasonable to put limits on bandwidth-hungry but non-essential applications as a precautionary measure. Here's an excerpt from http://www.nextgov.com/nextgov/ng_20110314_9111.php?oref=topnews: Military units operating in Japan face bandwidth shortages and network limitations that inhibit communications and command and control, Defense sources told Nextgov. Misawa Air Base, located on the northeast tip of Honshu, warned its personnel on a blog post Friday that the Defense Switched Network, which handles voice calls, was in backup mode and had only limited capacity, a fact confirmed by a Pentagon source Monday. The blog post added, "We have a number of connectivity issues. Internet has been up and down due to our connections through other places in Japan. For example, Yokota [Air Base] and several other locations are having issues because we all have power and connectivity issues right now." The Pentagon also took the extraordinary step of blocking access to a range of commercial websites to ensure that its networks have enough bandwidth to support mission-essential communications, Nextgov learned. This move, a military source told Nextgov, possibly indicates one or more undersea cables used by military networks were damaged by the earthquake. --Jeff From heather.schiller at verizonbusiness.com Wed Mar 16 13:52:41 2011 From: heather.schiller at verizonbusiness.com (Schiller, Heather A) Date: Wed, 16 Mar 2011 18:52:41 +0000 Subject: Creating an IPv6 addressing plan for end users In-Reply-To: References: Message-ID: For those who don't like clicking on random bit.ly links: http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6 _addr_plan4.pdf --Heather -----Original Message----- From: Nathalie Trenaman [mailto:nathalie at ripe.net] Sent: Wednesday, March 16, 2011 5:05 AM To: nanog at nanog.org Subject: Creating an IPv6 addressing plan for end users Hi all, In our IPv6 courses, we often get the question: I give my customers a /48 (or a /56 or a /52) but they have no idea how to distribute that space in their network. In December Sander Steffann and Surfnet wrote a manual explaining exactly that, in clear language with nice graphics. A very useful document but it was in Dutch, so RIPE NCC decided to translate that document to English. Yesterday, we have published that document on our website and we hope this document is able to take away some of the fear that end users seem to have for these huge blocks. You can find this document here: http://bit.ly/IPv6addrplan (PDF) I look forward to your feedback, tips and comments. With kind regards, Nathalie Trenaman RIPE NCC Trainer From jsw at inconcepts.biz Wed Mar 16 13:55:14 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 16 Mar 2011 14:55:14 -0400 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> Message-ID: On Wed, Mar 16, 2011 at 2:33 PM, Jensen Tyler wrote: > We have many switches between us and Level3 so we don't get a "interface down" to drop the session in the event of a failure. This is often my topology as well. I am satisfied with BGP's mechanism and default timers, and have been for many years. The reason for this is quite simple: failures are relatively rare, my convergence time to a good state is largely bounded by CPU, and I do not consider a slightly improved convergence time to be worth an a-typical configuration. Case in point, Richard says that none of his customers have requested such configuration to date; and you indicate that Level3 will provision BFD only if you use a certain vendor and this is handled outside of their normal provisioning process. For an IXP LAN interface and associated BGP neighbors, I see much more advantage. I imagine this will become common practice for IXP peering sessions long before it is typical to use BFD on customer/transit-provider BGP sessions. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From Gavin.Pearce at 3seven9.com Wed Mar 16 14:23:28 2011 From: Gavin.Pearce at 3seven9.com (Gavin Pearce) Date: Wed, 16 Mar 2011 19:23:28 -0000 Subject: 213.123.192.0/20 | 193.179.160.0/22 | 174.132.0.0/15 | 65.75.128.0/18 In-Reply-To: References: Message-ID: Just a quick update to the below message, I have a contact for The Planet, if anyone has a contact for any of the following, would be much appreciated: 64.167.200.160/29 (SBCIS-1001120-113647) [new] 213.123.192.0/20 (BT-ADSL) 193.179.160.0/22 (KULAJ-NET) 65.75.128.0/18 (MSG-65-75-128-0) Many thanks, Gavin -----Original Message----- From: Gavin Pearce [mailto:Gavin.Pearce at 3seven9.com] Sent: 15 March 2011 11:48 To: NANOG list Subject: 213.123.192.0/20 | 193.179.160.0/22 | 174.132.0.0/15 | 65.75.128.0/18 Morning all - anyone here responsible for any of the following: Abuse/Technical contacts gone unanswered for each (mailed 1 - 2 months ago). *sigh* Getting multiple brute force and/or spam from single IPs within those ranges against different devices on different dates. Gav -----Original Message----- From: Masato YAMANISHI [mailto:myamanis at japan-telecom.com] Sent: 14 March 2011 16:16 To: 'Marshall Eubanks'; 'NANOG list' Subject: RE: Rush to Fix Quake-Damaged Undersea Cables Hi Marshall and all, > About half of the existing cables running across the Pacific > are damaged ... > > It that realistic ? That seems like much more damage than > anything I have heard or seen. Yes, it's definetely true. Rgs, Masato > -----Original Message----- > From: Marshall Eubanks [mailto:tme at americafree.tv] > Sent: Monday, March 14, 2011 8:54 AM > To: NANOG list > Subject: Rush to Fix Quake-Damaged Undersea Cables > > In this WSJ article > > http://online.wsj.com/article/SB100014240527487048936045761999 > 52421569210.html > > or > > http://on.wsj.com/gaPk8V > > This caught my eye : > > About half of the existing cables running across the Pacific > are damaged ... > > It that realistic ? That seems like much more damage than > anything I have heard or seen. > > Regards > Marshall > > > From ras at e-gerbil.net Wed Mar 16 14:28:15 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Wed, 16 Mar 2011 14:28:15 -0500 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> Message-ID: <20110316192815.GB68199@gerbil.cluepon.net> On Wed, Mar 16, 2011 at 02:55:14PM -0400, Jeff Wheeler wrote: > > This is often my topology as well. I am satisfied with BGP's > mechanism and default timers, and have been for many years. The > reason for this is quite simple: failures are relatively rare, my > convergence time to a good state is largely bounded by CPU, and I do > not consider a slightly improved convergence time to be worth an > a-typical configuration. Case in point, Richard says that none of his > customers have requested such configuration to date; and you indicate > that Level3 will provision BFD only if you use a certain vendor and > this is handled outside of their normal provisioning process. There are still a LOT of platforms where BFD doesn't work reliably (without false positives), doesn't work as advertised, doesn't work under every configuration (e.g. on SVIs), or doesn't scale very well (i.e. it would fall over if you had more than a few neighbors configured). The list of caveats is huge, the list of vendors which support it well is small, and there should be giant YMMV stickers everywhere. But Juniper (M/T/MX series at any rate) is definitely one of the better options (though not without its flaws, inability to configure on the group level and selectively disable per-peer, and lack of support on the group level where any IPv6 neighbor is configured, come to mind). Running BFD with a transit provider is USUALLY the least interesting use case, since you're typically connected either directly, or via a metro transport service which is capable of passing link state. One possible exception to this is when you need to bundle multiple links together, but link-agg isn't a good solution, and you need to limit the number of EBGP paths to reduce load on the routers. The typical solution for this is loopback peering, but this kills your link state detection mechanism for killing BGP during a failure, which is where BFD starts to make sense. For IX's, where you have an active L2 switch in the middle and no link state, BFD makes the most sense. Unfortunately it's the area where we've seen the least traction among peers, with "zomg why are you sending me these udp packets" complaints outnumbering people interesting in configuring BFD 10:1. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From jeffrey.lyon at blacklotus.net Wed Mar 16 14:50:08 2011 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 16 Mar 2011 15:50:08 -0400 Subject: US .mil blocking in Japan In-Reply-To: <20110316184811.GB59111@eagle.aitken.com> References: <582587.43563.qm@web59616.mail.ac4.yahoo.com> <20110316184811.GB59111@eagle.aitken.com> Message-ID: On Wed, Mar 16, 2011 at 2:48 PM, Jeff Aitken wrote: > On Wed, Mar 16, 2011 at 09:14:13AM -0700, andrew.wallace wrote: >> This isn't the rhetoric of a super power, more like one of a university >> campus. [...] It strikes me straight away as amateurish to be blocking >> web sites in able to have enough bandwidth for operational purposes. > > On the contrary, it's entirely plausible that US forces assisting with the > recovery are (1) using more communications resources than normal, and (2) > relying on infrastructure that's operating in a degraded state due to > fiber or power issues. ?If so, it's entirely reasonable to put limits on > bandwidth-hungry but non-essential applications as a precautionary measure. > > Here's an excerpt from http://www.nextgov.com/nextgov/ng_20110314_9111.php?oref=topnews: > > ? ?Military units operating in Japan face bandwidth shortages and > ? ?network limitations that inhibit communications and command and > ? ?control, Defense sources told Nextgov. Misawa Air Base, located on the > ? ?northeast tip of Honshu, warned its personnel on a blog post Friday > ? ?that the Defense Switched Network, which handles voice calls, was in > ? ?backup mode and had only limited capacity, a fact confirmed by a > ? ?Pentagon source Monday. > > ? ?The blog post added, "We have a number of connectivity issues. > ? ?Internet has been up and down due to our connections through other > ? ?places in Japan. For example, Yokota [Air Base] and several other > ? ?locations are having issues because we all have power and connectivity > ? ?issues right now." > > ? ?The Pentagon also took the extraordinary step of blocking access to a > ? ?range of commercial websites to ensure that its networks have enough > ? ?bandwidth to support mission-essential communications, Nextgov > ? ?learned. This move, a military source told Nextgov, possibly indicates > ? ?one or more undersea cables used by military networks were damaged by > ? ?the earthquake. > > > --Jeff > > > Here's the problem with the logic of blocking all of the most popular sites; they tried this from time to time in Afghanistan on the NIPRnet. Whenever someone was unable to get to YouTube, Facebook, etc. they, still bored and/or wasting time, simply went to some other web site which also wasted equally as much bandwidth. -- Jeffrey Lyon, Leadership Team jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus Communications - AS32421 First and Leading in DDoS Protection Solutions From hescominsoon at emmanuelcomputerconsulting.com Wed Mar 16 15:22:32 2011 From: hescominsoon at emmanuelcomputerconsulting.com (William Warren) Date: Wed, 16 Mar 2011 16:22:32 -0400 Subject: US .mil blocking in Japan In-Reply-To: <582587.43563.qm@web59616.mail.ac4.yahoo.com> References: <582587.43563.qm@web59616.mail.ac4.yahoo.com> Message-ID: <4D811C08.1000000@emmanuelcomputerconsulting.com> On 3/16/2011 12:14 PM, andrew.wallace wrote: > On Wed, Mar 16, 2011 at 12:58 PM, Jeff Aitken wrote: >> What's to be surprised about? > This isn't the rhetoric of a super power, more like one of a university campus. To think these guys have built a cyber command with war waging capabilities, and allegedly capable of building nuclear worms such as Stuxnet. It strikes me straight away as amateurish to be blocking web sites in able to have enough bandwidth for operational purposes. You would think their war fighting networks, weren't the same ones used for civilian-based web sites on the public internet. It seems there is a conflict here between what they push out to the media as to what their cyber capabilities are, and what the realities are on the ground. In that respect, yes I'm very surprised. --- Andrew > > > As a former Military Member I can tell you we don't have unlimited amounts of bandwidth...especially overseas. There's been several undersea cables damaged or completely knocked offline. I don't find this policy very surprising due to the disaster in Japan. From JTyler at fiberutilities.com Wed Mar 16 15:42:39 2011 From: JTyler at fiberutilities.com (Jensen Tyler) Date: Wed, 16 Mar 2011 15:42:39 -0500 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> Message-ID: <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> Correct me if I am wrong but to detect a failure by default BGP would wait the "hold-timer" then declare a peer dead and converge. So you would be looking at 90 seconds(juniper default?) + CPU bound convergence time to recover? Am I thinking about this right? -----Original Message----- From: Jeff Wheeler [mailto:jsw at inconcepts.biz] Sent: Wednesday, March 16, 2011 1:55 PM To: nanog at nanog.org Subject: Re: bfd-like mechanism for LANPHY connections between providers On Wed, Mar 16, 2011 at 2:33 PM, Jensen Tyler wrote: > We have many switches between us and Level3 so we don't get a "interface down" to drop the session in the event of a failure. This is often my topology as well. I am satisfied with BGP's mechanism and default timers, and have been for many years. The reason for this is quite simple: failures are relatively rare, my convergence time to a good state is largely bounded by CPU, and I do not consider a slightly improved convergence time to be worth an a-typical configuration. Case in point, Richard says that none of his customers have requested such configuration to date; and you indicate that Level3 will provision BFD only if you use a certain vendor and this is handled outside of their normal provisioning process. For an IXP LAN interface and associated BGP neighbors, I see much more advantage. I imagine this will become common practice for IXP peering sessions long before it is typical to use BFD on customer/transit-provider BGP sessions. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jsw at inconcepts.biz Wed Mar 16 17:59:35 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 16 Mar 2011 18:59:35 -0400 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> Message-ID: On Wed, Mar 16, 2011 at 4:42 PM, Jensen Tyler wrote: > Correct me if I am wrong but to detect a failure by default BGP would wait the "hold-timer" then declare a peer dead and converge. > > So you would be looking at 90 seconds(juniper default?) + CPU bound convergence time to recover? Am I thinking about this right? This is correct. Note that 90 seconds isn't just a "Juniper default." This suggested value appeared in RFC 1267 ?5.4 (BGP-3) all the way back in 1991. In my view, configuring BFD for eBGP sessions is risking increased MTBF for rare reductions in MTTR. This is a risk / reward decision that IMO is still leaning towards "lots of risk" for "little reward." I'll change my mind about this when BFD works on most boxes and is part of the standard provisioning procedure for more networks. It has already been pointed out that this is not true today. If your eBGP sessions are failing so frequently that you are very concerned about this 90 seconds, I suggest you won't reduce your operational headaches or customer grief by configuring BFD. This is probably an indication that you need to: 1) straighten out the problems with your switching network or transport vendor 2) get better transit 3) depeer some peers who can't maintain a stable connection to you; or 4) sacrifice something to the backhoe deity Again, in the case of an IXP interface, I believe BFD has much more potential benefit. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From skhuraijam at liveops.com Wed Mar 16 19:00:20 2011 From: skhuraijam at liveops.com (Sudeep Khuraijam) Date: Wed, 16 Mar 2011 17:00:20 -0700 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> Message-ID: Correct me if I am wrong but to detect a failure by default BGP would wait the "hold-timer" then declare a peer dead and converge. Hence the case for BFD. There a difference of several orders of magnitude between BFD keepalive intervals (in ms) and BGP (in seconds) with generally configurable multipliers vs. hold timer. With Real time media and ever faster last miles, BGP hold timer may find itself inadequate, if not in appropriate in some cases. For a provider to require a vendor instead of RFC compliance is sinful. Sudeep On Mar 16, 2011, at 1:42 PM, Jensen Tyler wrote: Correct me if I am wrong but to detect a failure by default BGP would wait the "hold-timer" then declare a peer dead and converge. So you would be looking at 90 seconds(juniper default?) + CPU bound convergence time to recover? Am I thinking about this right? -----Original Message----- From: Jeff Wheeler [mailto:jsw at inconcepts.biz] Sent: Wednesday, March 16, 2011 1:55 PM To: nanog at nanog.org Subject: Re: bfd-like mechanism for LANPHY connections between providers On Wed, Mar 16, 2011 at 2:33 PM, Jensen Tyler > wrote: We have many switches between us and Level3 so we don't get a "interface down" to drop the session in the event of a failure. This is often my topology as well. I am satisfied with BGP's mechanism and default timers, and have been for many years. The reason for this is quite simple: failures are relatively rare, my convergence time to a good state is largely bounded by CPU, and I do not consider a slightly improved convergence time to be worth an a-typical configuration. Case in point, Richard says that none of his customers have requested such configuration to date; and you indicate that Level3 will provision BFD only if you use a certain vendor and this is handled outside of their normal provisioning process. For an IXP LAN interface and associated BGP neighbors, I see much more advantage. I imagine this will become common practice for IXP peering sessions long before it is typical to use BFD on customer/transit-provider BGP sessions. -- Jeff S Wheeler > Sr Network Operator / Innovative Network Concepts ____________________________________________ Sudeep Khuraijam | I speak for no one but I From jsw at inconcepts.biz Wed Mar 16 20:05:46 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Wed, 16 Mar 2011 21:05:46 -0400 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> Message-ID: On Wed, Mar 16, 2011 at 8:00 PM, Sudeep Khuraijam wrote: > There a difference of several orders of magnitude ?between BFD keepalive intervals ?(in ms) and BGP (in seconds) with generally configurable multipliers vs. hold timer. > With Real time media and ever faster last miles, BGP hold timer may find itself inadequate, if not in appropriate in some cases. For eBGP peerings, your router must re-converge to a good state in < 9 seconds to see an order of magnitude improvement in time-to-repair. This is typically not the case for transit/customer sessions. To make a risk/reward choice that is actually based in reality, you need to understand your total time to re-converge to a good state, and how much of that is BGP hold-time. You should then consider whether changing BGP timers (with its own set of disadvantages) is more or less practical than using BFD. Let's put it another way: if CPU/FIB convergence time were not a significant issue, do you think vendors would be working to optimize this process, that we would have concepts like MPLS FRR and PIC, and that each new router product line upgrade comes with a yet-faster CPU? Of course not. Vendors would just have said, "hey, let's get together on a lower hold time for BGP." As I stated, I'll change my opinion of BFD when implementations improve. I understand the risk/reward situation. You don't seem to get this, and as a result, your overly-simplistic view is that "BGP takes seconds" and "BFD takes milliseconds." > For a provider to require a vendor instead of RFC compliance is sinful. Many sins are more practical than the alternatives. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From Anees.Uddin at xo.com Thu Mar 17 00:17:46 2011 From: Anees.Uddin at xo.com (Uddin, Anees M) Date: Thu, 17 Mar 2011 00:17:46 -0500 Subject: Test In-Reply-To: References: Message-ID: <453F048B80D4E4428887A11060BE2463403BF960@txplanexch02.corp.inthosts.net> Test From skhuraijam at liveops.com Thu Mar 17 00:33:39 2011 From: skhuraijam at liveops.com (Sudeep Khuraijam) Date: Wed, 16 Mar 2011 22:33:39 -0700 Subject: bfd-like mechanism for LANPHY connections between providers In-Reply-To: References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> Message-ID: <5B88CD19-31DC-4EE7-9C2A-74A372055309@liveops.com> On Mar 16, 2011, at 6:05 PM, Jeff Wheeler wrote: >>There a difference of several orders of magnitude between BFD keepalive intervals (in ms) and BGP (in seconds) with generally configurable multipliers vs. >>hold timer. >>With Real time media and ever faster last miles, BGP hold timer may find itself inadequate, if not in appropriate in some cases." >For eBGP peerings, your router must re-converge to a good state in < 9 >seconds to see an order of magnitude improvement in time-to-repair. >This is typically not the case for transit/customer sessions." Not so, if your goal is peer deactivation and failover. Also you miss the point. Once the event is detected the rest of the process starts. I am talking about event detection. One may want longer than a 30 second hold-timer but peer state deactivated instantly on link failure. If thats the design goal AND link state is not passed through, then BFD BGP deactivation is a good choice. >To make a risk/reward choice that is actually based in reality, you >need to understand your total time to re-converge to a good state, and >how much of that is BGP hold-time. You should then consider whether >changing BGP timers (with its own set of disadvantages) is more or >less practical than using BFD. Yes I see that and I mentioned "in some cases" not all or most cases. >Let's put it another way: if CPU/FIB convergence time were not a >significant issue, do you think vendors would be working to optimize This goes orthogonal to my point. The Table size taxes, best path algorithms and the speed with which you can re-FIB &rewrite the ASICs are constant in both the cases. But thats post event. >this process, that we would have concepts like MPLS FRR and PIC, and Those are out of scope in the context of this thread and have completely different roles. >that each new router product line upgrade comes with a yet-faster CPU? For things they can sell more licenses for such as 3DES, keying algorithms , virtual instances, other things on BGP, stuff that allow service providers to charge a lot more money while running on common infrastructure such as MPLS & FRR and zillion other things like stateful redundancy, higher housekeeping needs, inservice upgrades and anything else with a list price. And its cheaper than the old cpu. >Of course not. Vendors would just have said, "hey, let's get >together on a lower hold time for BGP." Because it would be horrible code design. Link detection is a common service. Besides BGP process threads can run longer than min intervals for link. Vendors would have to write checkpoints within BGP code to come up and service link state machine. And wait its a user configurable checkpoint!! So came BFD. Write a simple state machine and make it available to all protocols. >As I stated, I'll change my opinion of BFD when implementations >improve. I understand the risk/reward situation. You don't seem to >get this, and as a result, your overly-simplistic view is that "BGP >takes seconds" and "BFD takes milliseconds." I have no doubt that you understand your risk/reward but you don't for every other environments. For event detection leading to a state change leading to peer deactivation, "my overly-simplistic view" is the fact ( not as you put it, but as it was written unedited). How you want to act in response is dependent on design. >is that "BGP >takes seconds" and "BFD takes milliseconds." Thats what you read not what I wrote. I was comparing the speed of event detection. Now like I said for speed of deactivation "BGP hold timer may find itself inadequate, if not in appropriate in some cases" in this same context. But as I mentioned , we don't know the pain we are trying to solve for the requirements thats drove this thread in the first place. So I simply put the facts and a business driver. BFD is no different than deactivating a peer based on link failure. Your view is that there is no case for it. My point is - it arrived yesterday, its just a damn hard thing to monetize upstream in transit. >>For a provider to require a vendor instead of RFC compliance is sinful. >Many sins are more practical than the alternatives. Few maybe. -- Jeff S Wheeler >> Sr Network Operator / Innovative Network Concepts From loopback at digi-muse.com Thu Mar 17 08:45:13 2011 From: loopback at digi-muse.com (Loopback) Date: Thu, 17 Mar 2011 08:45:13 -0500 Subject: Simple Low Cost WAN Link Simulator Recommendations In-Reply-To: References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> Message-ID: <4D821069.1050804@digi-muse.com> Need the ability to test Network Management and Provisioning applications over a variety of WAN link speeds from T1 equivalent up to 1GB speeds. Seems to be quite a few offerings but I am looking for recommendations from actual users. Thanks in advance. From serge.devorop at gmail.com Thu Mar 17 08:54:21 2011 From: serge.devorop at gmail.com (Sergey Voropaev) Date: Thu, 17 Mar 2011 16:54:21 +0300 Subject: Simple Low Cost WAN Link Simulator Recommendations In-Reply-To: <4D821069.1050804@digi-muse.com> References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> <4D821069.1050804@digi-muse.com> Message-ID: I've used WANem (http://wanem.sourceforge.net/) for a last 2 years. Simple WEB-interface, wide range of setting - it is enough fro network engineers. On 17 March 2011 16:45, Loopback wrote: > Need the ability to test Network Management and Provisioning applications > over a variety of WAN link speeds from T1 equivalent up to 1GB speeds. > ?Seems to be quite a few offerings but I am looking for recommendations from > actual users. ? Thanks in advance. > > > > From loopback at digi-muse.com Thu Mar 17 08:57:01 2011 From: loopback at digi-muse.com (Loopback) Date: Thu, 17 Mar 2011 08:57:01 -0500 Subject: Simple Low Cost WAN Link Simulator Recommendations In-Reply-To: References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> Message-ID: <4D82132D.6080107@digi-muse.com> Need the ability to test Network Management and Provisioning applications over a variety of WAN link speeds from T1 equivalent up to 1GB speeds. Seems to be quite a few offerings but I am looking for recommendations from actual users. Thanks in advance. From psirt at cisco.com Thu Mar 17 10:58:12 2011 From: psirt at cisco.com (Cisco Systems Product Security Incident Response Team) Date: Thu, 17 Mar 2011 11:58:12 -0400 Subject: Deferral Announcement for the March 2011 Cisco IOS Software Security Advisories Message-ID: <201103171158.ios-bundle-deferred-eap@psirt.cisco.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco PSIRT regularly discloses vulnerabilities in Cisco IOS Software on the fourth Wednesday in March and September via the Cisco IOS Security Advisory bundle. The next bundled disclosure was planned for Wednesday, March 23, 2011, but Cisco will defer this disclosure until the next scheduled Cisco IOS bundle on September 28, 2011. Cisco has a long-standing policy of disclosing vulnerabilities to customers and the public simultaneously to ensure equal access to patched software. Based on recent events in Japan and eastern Asia, we are sensitive to the fact that customers globally are impacted directly or indirectly by these events and may not be able to respond effectively to the scheduled disclosure event. This regional disaster has not affected the ability of Cisco to disclose vulnerability information. In keeping with our policy, if we see evidence of active exploitation of a vulnerability that could lead to increased risk for Cisco customers, we will disclose appropriate information out of cycle. Please direct any questions about this announcement to either psirt at cisco.com or your local Cisco support team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAk2CKzMACgkQQXnnBKKRMNBLjgD/bPLtpIYQd/8DSNfx9/PQg1jA Wmpe6qGaHA3L1YXSzP0A/i7Kyal+nGaJJnqwSsAzaQeV+Lh261Ah9fozXSBba0Kb =kX8s -----END PGP SIGNATURE----- From shtsuchi at cisco.com Thu Mar 17 11:56:35 2011 From: shtsuchi at cisco.com (Shishio Tsuchiya) Date: Fri, 18 Mar 2011 01:56:35 +0900 Subject: Service Provider Route Flap Damping Deployment Status Survey Message-ID: <4D823D43.9090403@cisco.com> Dear NANOG, I'm Shishio,Cisco Systems Japan. I,Seiichi and Randy did presentation about "BGP topic" on JANOG27 which held 20th & 21st January 2011 in Kanazawa. http://www.janog.gr.jp/en/index.php?JANOG27%20Programs#qe7ec71d Randy explained "Route Flap Damping Considered Useable". http://ripe61.ripe.net/presentations/222-101117.ripe-rfd.pdf This report explains how to improve today's harmful RFD. We heard various opinion from bgp operators about RFD. So we took survey about "Service Provider Route Flap Damping Deployment Status" on janog at janog.gr.jp. We would like to hear more opinions to analyze current RFD operation,problem and so on. Could you please open the following url and answer the questionaire? https://www.surveymonkey.com/s/rfd-survey The JAPAN result summary is below. ----------------------------------- Q1.Do you use Route Flap Damping ? Yes: 5 No: 13 Q2.If you select No on Q1,why? Do not have the need: 3 Did not know about the feature: 2 No benefits expected: 3 Customers would complain:1 Because I read RIPE-378 :2 Other: 3 Q3.If you select Yes on Q1,what parameter do you use? Default parameters: 3 RIPE-178 : 0 RIPE-210 : 0 RIPE-229 : 0 Other: 3 Q4.Do you know Randy Bush et. al's report ''Route Flap Damping Considered Usable?'' Yes: 12 No: 7 Q5.IOS's max-penalty is currently limited to 20K. Do you need this limitation to be relaxed to over 50K? Yes: 10 No: 9 Q6.If you have any comments, please fill this box. -Our peer seems to have damping enabled, and our prefix gets damped sometimes. -We do not enable damping because we think that customers want a non-damped route. -From the perspective of a downstream ISP, if our upstream told us that an outage occurred because a route was damped, I may call and ask "is it written in the agreement that you will do this?" -We use damping pretty heavily -I had RFD turned on until this morning when I discovered our router has CSCtd26215 issues. I would like to turn on a "useful" RFD. ----------------------------------- other reference: https://tools.ietf.org/html/draft-shishio-grow-isp-rfd-implement-survey-01 https://tools.ietf.org/html/draft-ymbk-rfd-usable-00 Best Regards, -- Shishio Tsuchiya From grobe0ba at gmail.com Thu Mar 17 15:59:10 2011 From: grobe0ba at gmail.com (Atticus) Date: Thu, 17 Mar 2011 16:59:10 -0400 Subject: i386 home firewall/router/nat bottleneck diagnostics? In-Reply-To: <20110317205214.GA2695@antioche.eu.org> References: <20110316145253.GA18733@cs.uni-bonn.de> <96c562132916631b85fc3f32d2399552.squirrel@wm.sdf.org> <20110317205214.GA2695@antioche.eu.org> Message-ID: I have a four or five of 'em I don't use. If anyone needs one, I'll mail it, just contact me off list. From xenophage at godshell.com Thu Mar 17 20:57:28 2011 From: xenophage at godshell.com (Jason 'XenoPhage' Frisvold) Date: Thu, 17 Mar 2011 21:57:28 -0400 Subject: [Nanog] Re: US .mil blocking in Japan In-Reply-To: <4D811C08.1000000@emmanuelcomputerconsulting.com> References: <582587.43563.qm@web59616.mail.ac4.yahoo.com> <4D811C08.1000000@emmanuelcomputerconsulting.com> Message-ID: <74ED5184-E383-4A83-B588-23606263D0AA@godshell.com> On Mar 16, 2011, at 4:22 PM, William Warren wrote: > As a former Military Member I can tell you we don't have unlimited amounts of bandwidth...especially overseas. There's been several undersea cables damaged or completely knocked offline. I don't find this policy very surprising due to the disaster in Japan. Could this also be part of a "communications blackout" ? No, not in a sinister, government keeping secrets, manner. A friend of mine serves on a ship that's over there right now. He dropped me a note last night that they were going into a communications blackout to try and control some of the wild miscommunication being sent out. It seems reasonable enough if only to prevent widespread panic from someone "close" to the situation saying something incorrect. --------------------------- Jason 'XenoPhage' Frisvold xenophage at godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law From nanog at deman.com Thu Mar 17 23:33:14 2011 From: nanog at deman.com (Michael DeMan) Date: Thu, 17 Mar 2011 21:33:14 -0700 Subject: [Nanog] Re: US .mil blocking in Japan In-Reply-To: <74ED5184-E383-4A83-B588-23606263D0AA@godshell.com> References: <582587.43563.qm@web59616.mail.ac4.yahoo.com> <4D811C08.1000000@emmanuelcomputerconsulting.com> <74ED5184-E383-4A83-B588-23606263D0AA@godshell.com> Message-ID: <8A57EFB7-F08A-42A5-A2B3-C22CEE54319A@deman.com> Wasn't this announced on the news already? That because the infrastructure in Japan was hit (no highly publicized) but still working, that the US military also said they were blocking u-tube and other high bandwidth sites in order to conserve resources? I am definitely not one to be outside of hearing about a conspiracy theory or something, but I know up in our neck of the woods in the NorthWest of NorthWest Washington State, that this is just common sense to do. On Mar 17, 2011, at 6:57 PM, Jason 'XenoPhage' Frisvold wrote: > On Mar 16, 2011, at 4:22 PM, William Warren wrote: >> As a former Military Member I can tell you we don't have unlimited amounts of bandwidth...especially overseas. There's been several undersea cables damaged or completely knocked offline. I don't find this policy very surprising due to the disaster in Japan. > > Could this also be part of a "communications blackout" ? No, not in a sinister, government keeping secrets, manner. A friend of mine serves on a ship that's over there right now. He dropped me a note last night that they were going into a communications blackout to try and control some of the wild miscommunication being sent out. > > It seems reasonable enough if only to prevent widespread panic from someone "close" to the situation saying something incorrect. > > > --------------------------- > Jason 'XenoPhage' Frisvold > xenophage at godshell.com > --------------------------- > "Any sufficiently advanced magic is indistinguishable from technology." > - Niven's Inverse of Clarke's Third Law > > > > From jloiacon at csc.com Fri Mar 18 07:48:16 2011 From: jloiacon at csc.com (Joe Loiacono) Date: Fri, 18 Mar 2011 08:48:16 -0400 Subject: Announcement: FlowViewer v3.4 released In-Reply-To: References: Message-ID: Open-source FlowViewer version 3.4 has been released. FlowViewer is a web-based companion set of tools to Mark Fullmer's flow-tools netflow capture and analysis tool suite. FlowViewer enables users to analyze and track traffic through their network. Users can quickly and easily create textual reports, graphical reports, or long-term tracking reports on any specified subset of their network traffic. FlowViewer v3.4 can be downloaded from: http://ensight.eos.nasa.gov/FlowViewer/ Regards, Joe Loiacono From adam at leff.co Fri Mar 18 09:05:47 2011 From: adam at leff.co (Adam Leff) Date: Fri, 18 Mar 2011 10:05:47 -0400 Subject: WAN Acceleration: Infineta Message-ID: Has anyone had any experience with Infineta for WAN Acceleration that you'd be willing to share? Off-list replies are certainly welcome. ~Adam From mikec at callagy.org Fri Mar 18 11:34:46 2011 From: mikec at callagy.org (Mike Callagy) Date: Fri, 18 Mar 2011 09:34:46 -0700 Subject: Simple Low Cost WAN Link Simulator Recommendations In-Reply-To: <4D82132D.6080107@digi-muse.com> References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> <4D82132D.6080107@digi-muse.com> Message-ID: Network Nightmare http://gigenn.net/ I used this device in the past to test an HP RGS deployment. You can simulate different connection rates and induce latency. Documentation is weak but it does the job. On Thu, Mar 17, 2011 at 6:57 AM, Loopback wrote: > Need the ability to test Network Management and Provisioning applications > over a variety of WAN link speeds from T1 equivalent up to 1GB speeds. > Seems to be quite a few offerings but I am looking for recommendations from > actual users. Thanks in advance. > > > > From JamesL at Lugoj.com Fri Mar 18 12:27:18 2011 From: JamesL at Lugoj.com (Jim Logajan) Date: Fri, 18 Mar 2011 10:27:18 -0700 Subject: Simple Low Cost WAN Link Simulator Recommendations References: AANLkTinDoBbfbM2vLOPxXKsv=kf_LY5TwMhbY8AwTbzg@mail.gmail.com Message-ID: <4D8395F6.4070502@Lugoj.com> Loopback wrote: > Need the ability to test Network Management and Provisioning > applications over a variety of WAN link speeds from T1 equivalent up to > 1GB speeds. Seems to be quite a few offerings but I am looking for > recommendations from actual users. Thanks in advance. I've used both Mini Maxwell and Maxwell Pro from InterWorking Labs with great success: http://minimaxwell.iwl.com/ http://maxwell.iwl.com/ The Maxwell Pro has a bunch of interesting capabilities - it can be used to actually modify packets as they pass through (like changing IP addresses and port numbers, or messing with other parts of selected packets.) Obviously that goes beyond simple WAN emulation. Jim From cscora at apnic.net Fri Mar 18 13:38:03 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 19 Mar 2011 04:38:03 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201103181838.p2IIc3Ye027532@thyme.rand.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.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 19 Mar, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 350396 Prefixes after maximum aggregation: 158064 Deaggregation factor: 2.22 Unique aggregates announced to Internet: 173325 Total ASes present in the Internet Routing Table: 36104 Prefixes per ASN: 9.71 Origin-only ASes present in the Internet Routing Table: 31128 Origin ASes announcing only one prefix: 14967 Transit ASes present in the Internet Routing Table: 4976 Transit-only ASes present in the Internet Routing Table: 126 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 419 Unregistered ASNs in the Routing Table: 197 Number of 32-bit ASNs allocated by the RIRs: 1207 Prefixes from 32-bit ASNs in the Routing Table: 1 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 195 Number of addresses announced to Internet: 2389006912 Equivalent to 142 /8s, 101 /16s and 90 /24s Percentage of available address space announced: 64.5 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 89.5 Total number of prefixes smaller than registry allocations: 145036 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 87454 Total APNIC prefixes after maximum aggregation: 29725 APNIC Deaggregation factor: 2.94 Prefixes being announced from the APNIC address blocks: 84332 Unique aggregates announced from the APNIC address blocks: 36512 APNIC Region origin ASes present in the Internet Routing Table: 4355 APNIC Prefixes per ASN: 19.36 APNIC Region origin ASes announcing only one prefix: 1209 APNIC Region transit ASes present in the Internet Routing Table: 688 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 20 Number of APNIC addresses announced to Internet: 599437120 Equivalent to 35 /8s, 186 /16s and 175 /24s Percentage of available APNIC address space announced: 76.0 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, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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: 140255 Total ARIN prefixes after maximum aggregation: 71845 ARIN Deaggregation factor: 1.95 Prefixes being announced from the ARIN address blocks: 110784 Unique aggregates announced from the ARIN address blocks: 45089 ARIN Region origin ASes present in the Internet Routing Table: 14268 ARIN Prefixes per ASN: 7.76 ARIN Region origin ASes announcing only one prefix: 5424 ARIN Region transit ASes present in the Internet Routing Table: 1481 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 796960256 Equivalent to 47 /8s, 128 /16s and 166 /24s Percentage of available ARIN address space announced: 63.3 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, 23/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, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/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: 82861 Total RIPE prefixes after maximum aggregation: 47241 RIPE Deaggregation factor: 1.75 Prefixes being announced from the RIPE address blocks: 76228 Unique aggregates announced from the RIPE address blocks: 49953 RIPE Region origin ASes present in the Internet Routing Table: 15431 RIPE Prefixes per ASN: 4.94 RIPE Region origin ASes announcing only one prefix: 7778 RIPE Region transit ASes present in the Internet Routing Table: 2398 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 30 Number of RIPE addresses announced to Internet: 465167872 Equivalent to 27 /8s, 185 /16s and 230 /24s Percentage of available RIPE address space announced: 74.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, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 32138 Total LACNIC prefixes after maximum aggregation: 7344 LACNIC Deaggregation factor: 4.38 Prefixes being announced from the LACNIC address blocks: 31063 Unique aggregates announced from the LACNIC address blocks: 16158 LACNIC Region origin ASes present in the Internet Routing Table: 1433 LACNIC Prefixes per ASN: 21.68 LACNIC Region origin ASes announcing only one prefix: 428 LACNIC Region transit ASes present in the Internet Routing Table: 261 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 81506688 Equivalent to 4 /8s, 219 /16s and 177 /24s Percentage of available LACNIC address space announced: 54.0 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/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: 7476 Total AfriNIC prefixes after maximum aggregation: 1806 AfriNIC Deaggregation factor: 4.14 Prefixes being announced from the AfriNIC address blocks: 5882 Unique aggregates announced from the AfriNIC address blocks: 1800 AfriNIC Region origin ASes present in the Internet Routing Table: 434 AfriNIC Prefixes per ASN: 13.55 AfriNIC Region origin ASes announcing only one prefix: 127 AfriNIC Region transit ASes present in the Internet Routing Table: 93 Average AfriNIC Region AS path length visible: 5.4 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 22062080 Equivalent to 1 /8s, 80 /16s and 164 /24s Percentage of available AfriNIC address space announced: 32.9 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2426 9508 896 Korea Telecom (KIX) 7545 1569 301 84 TPG Internet Pty Ltd 4755 1476 653 158 TATA Communications formerly 17974 1443 480 34 PT TELEKOMUNIKASI INDONESIA 24560 1134 324 187 Bharti Airtel Ltd., Telemedia 9583 1047 77 490 Sify Limited 4808 1046 2142 294 CNCGROUP IP network: China169 9829 1004 868 53 BSNL National Internet Backbo 18101 939 117 143 Reliance Infocom Ltd Internet 17488 936 162 96 Hathway IP Over Cable Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3675 3839 259 bellsouth.net, inc. 4323 2569 1093 402 Time Warner Telecom 1785 1792 681 131 PaeTec Communications, Inc. 18566 1606 331 194 Covad Communications 6478 1551 300 76 AT&T Worldnet Services 20115 1527 1536 645 Charter Communications 19262 1488 4939 299 Verizon Global Networks 7018 1368 6835 887 AT&T WorldNet Services 11492 1314 236 64 Cable One 2386 1289 536 929 AT&T Data Communications Serv Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 515 1780 318 UPC Distribution Services 9198 472 267 15 Kazakhtelecom Data Network Ad 34984 455 95 203 BILISIM TELEKOM 3292 453 2013 391 TDC Tele Danmark 8866 443 133 24 Bulgarian Telecommunication C 20940 411 98 314 Akamai Technologies European 3320 406 7604 354 Deutsche Telekom AG 8551 403 353 46 Bezeq International 12479 403 577 6 Uni2 Autonomous System 8402 398 320 11 Corbina telecom Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1392 259 163 TVCABLE BOGOTA 28573 1243 965 82 NET Servicos de Comunicao S.A 8151 1238 2702 368 UniNet S.A. de C.V. 6503 1175 354 73 AVANTEL, S.A. 7303 923 464 147 Telecom Argentina Stet-France 14420 639 52 91 CORPORACION NACIONAL DE TELEC 22047 543 310 15 VTR PUNTO NET S.A. 3816 513 225 97 Empresa Nacional de Telecomun 13489 491 213 106 Orbitel S.A. E.S.P. 11172 487 99 81 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 791 445 11 TEDATA 24863 773 147 39 LINKdotNET AS number 15475 420 90 8 Nile Online 36992 297 271 14 Etisalat MISR 3741 266 987 228 The Internet Solution 33776 230 13 5 Starcomms Nigeria Limited 24835 220 78 10 RAYA Telecom - Egypt 6713 207 199 11 Itissalat Al-MAGHRIB 29571 192 17 11 Ci Telecom Autonomous system 16637 147 439 87 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3675 3839 259 bellsouth.net, inc. 4323 2569 1093 402 Time Warner Telecom 4766 2426 9508 896 Korea Telecom (KIX) 1785 1792 681 131 PaeTec Communications, Inc. 18566 1606 331 194 Covad Communications 7545 1569 301 84 TPG Internet Pty Ltd 6478 1551 300 76 AT&T Worldnet Services 20115 1527 1536 645 Charter Communications 19262 1488 4939 299 Verizon Global Networks 4755 1476 653 158 TATA Communications formerly Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2569 2167 Time Warner Telecom 1785 1792 1661 PaeTec Communications, Inc. 4766 2426 1530 Korea Telecom (KIX) 7545 1569 1485 TPG Internet Pty Ltd 6478 1551 1475 AT&T Worldnet Services 18566 1606 1412 Covad Communications 17974 1443 1409 PT TELEKOMUNIKASI INDONESIA 4755 1476 1318 TATA Communications formerly 11492 1314 1250 Cable One 10620 1392 1229 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 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 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 31.31.96.0/19 6876 TeNeT Autonomous System 31.31.160.0/21 50168 Bogal AB 41.57.192.0/18 22750 BCSNET 41.222.79.0/24 36938 >>UNKNOWN<< Complete listing at http://thyme.rand.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:19 /9:11 /10:26 /11:74 /12:217 /13:447 /14:767 /15:1373 /16:11566 /17:5690 /18:9398 /19:19019 /20:24711 /21:25164 /22:33584 /23:32079 /24:183044 /25:1126 /26:1302 /27:722 /28:40 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2268 3675 bellsouth.net, inc. 18566 1585 1606 Covad Communications 6478 1505 1551 AT&T Worldnet Services 4323 1380 2569 Time Warner Telecom 10620 1283 1392 TVCABLE BOGOTA 11492 1271 1314 Cable One 7011 1062 1162 Citizens Utilities 1785 1057 1792 PaeTec Communications, Inc. 6503 955 1175 AVANTEL, S.A. 22773 835 1287 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:272 2:61 4:14 5:1 8:342 12:2021 13:1 14:422 15:15 16:3 17:8 20:10 23:3 24:1558 27:654 31:2 32:60 33:3 34:2 37:1 38:714 39:1 40:101 41:2279 44:3 46:731 47:4 49:162 50:109 52:13 55:3 56:2 57:32 58:866 59:492 60:386 61:1149 62:997 63:1926 64:3873 65:2353 66:4367 67:1771 68:1076 69:2905 70:698 71:359 72:1935 73:1 74:2325 75:284 76:343 77:844 78:697 79:453 80:1091 81:817 82:515 83:466 84:645 85:1042 86:554 87:756 88:353 89:1565 90:174 91:3642 92:504 93:1042 94:1226 95:782 96:448 97:251 98:799 99:34 101:49 106:1 107:4 108:72 109:908 110:520 111:715 112:320 113:374 114:504 115:713 116:968 117:674 118:723 119:1077 120:257 121:767 122:1609 123:1042 124:1300 125:1248 128:265 129:170 130:172 131:551 132:100 133:20 134:215 135:49 136:212 137:145 138:299 139:113 140:479 141:173 142:377 143:382 144:473 145:52 146:436 147:208 148:615 149:275 150:161 151:187 152:298 153:180 154:3 155:375 156:185 157:348 158:127 159:372 160:313 161:212 162:278 163:164 164:489 165:351 166:499 167:411 168:722 169:156 170:761 171:69 172:2 173:1250 174:522 175:333 177:43 178:810 180:791 181:4 182:398 183:245 184:228 185:1 186:1056 187:865 188:914 189:1031 190:4750 192:5768 193:4792 194:3494 195:2945 196:1178 197:15 198:3566 199:3873 200:5523 201:1586 202:8392 203:8467 204:4111 205:2310 206:2642 207:3025 208:3902 209:3486 210:2676 211:1352 212:1947 213:1702 214:756 215:66 216:4861 217:1647 218:550 219:381 220:1195 221:472 222:321 223:100 End of report From swmike at swm.pp.se Fri Mar 18 14:08:25 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 18 Mar 2011 20:08:25 +0100 (CET) Subject: Weekly Routing Table Report In-Reply-To: <201103181838.p2IIc3Ye027532@thyme.rand.apnic.net> References: <201103181838.p2IIc3Ye027532@thyme.rand.apnic.net> Message-ID: On Sat, 19 Mar 2011, Routing Analysis Role Account wrote: > Number of 32-bit ASNs allocated by the RIRs: 1207 > Prefixes from 32-bit ASNs in the Routing Table: 1 Is the report not getting the routes from the real 32bit ASNs or is the above figures really accurate? -- Mikael Abrahamsson email: swmike at swm.pp.se From jeroen at mompl.net Fri Mar 18 16:11:05 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 18 Mar 2011 14:11:05 -0700 Subject: SP's and v4 block assignments In-Reply-To: <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> Message-ID: <4D83CA69.8080806@mompl.net> Owen DeLong wrote: > I'll point out that Comcast charges $5/month for a static IP on their business circuits. I get charged $6 for a static IP for a home internet connection (not a business account). Although in the Netherlands xs4all will give you one for free, so it depends. I am wondering though, is it normal to charge around $5/month for rDNS on that IP? I'd say a one time fee for the effort of adding the record to the nameserver would be enough. But then maybe the consumer ISP gets charged by their ISP for rDNS. > This is not uncommon practice. I agree with you that it's undesirable, but, it's not uncommon > among the access networks. I guess it's ok to expect a small fee when your consumer grade internet connection gets a static IP. Given that many large ISPs force you to get a business account if you want a static IP, and a higher price. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From cidr-report at potaroo.net Fri Mar 18 17:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Mar 2011 22:00:02 GMT Subject: BGP Update Report Message-ID: <201103182200.p2IM024v074453@wattle.apnic.net> BGP Update Report Interval: 10-Mar-11 -to- 17-Mar-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9498 30279 2.1% 41.4 -- BBIL-AP BHARTI Airtel Ltd. 2 - AS24560 25808 1.8% 22.8 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 3 - AS9829 24512 1.7% 45.3 -- BSNL-NIB National Internet Backbone 4 - AS45899 20311 1.4% 34.3 -- VNPT-AS-VN VNPT Corp 5 - AS32528 17908 1.2% 8954.0 -- ABBOTT Abbot Labs 6 - AS22085 17352 1.2% 315.5 -- Telet S.A. 7 - AS25620 17227 1.2% 115.6 -- COTAS LTDA. 8 - AS27738 13284 0.9% 39.3 -- Ecuadortelecom S.A. 9 - AS35931 13000 0.9% 4333.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 10 - AS17488 11005 0.8% 12.6 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 11 - AS17974 10917 0.8% 14.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 12 - AS14420 10501 0.7% 16.2 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 13 - AS25220 9839 0.7% 4919.5 -- GLOBALNOC-AS Averbo GmbH 14 - AS9245 8510 0.6% 531.9 -- COMPASS-NZ-AP COMPASS NZ 15 - AS45595 8383 0.6% 23.2 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 16 - AS227 8006 0.6% 48.5 -- SHAFTER-AS - Headquarters, USAISC 17 - AS33475 7878 0.5% 57.5 -- RSN-1 - RockSolid Network, Inc. 18 - AS8151 7875 0.5% 7.1 -- Uninet S.A. de C.V. 19 - AS7491 7407 0.5% 154.3 -- PI-PH-AS-AP PI-PHILIPINES 20 - AS7303 7242 0.5% 8.1 -- Telecom Argentina S.A. TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 17908 1.2% 8954.0 -- ABBOTT Abbot Labs 2 - AS51280 5270 0.4% 5270.0 -- AS51280 Parsian Electronic Commerce Company 3 - AS25220 9839 0.7% 4919.5 -- GLOBALNOC-AS Averbo GmbH 4 - AS35931 13000 0.9% 4333.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS42408 6715 0.5% 2238.3 -- TSV-AS JSC Company Transsviaz 6 - AS44609 5560 0.4% 1853.3 -- FNA Fars News Agency Cultural Arts Institute 7 - AS49600 1548 0.1% 1548.0 -- LASEDA La Seda de Barcelona, S.A 8 - AS20463 1499 0.1% 1499.0 -- EZYIELD - EZ Yield.com, Inc. 9 - AS27771 2591 0.2% 1295.5 -- Instituto Venezolano de Investigaciones Cientificas 10 - AS17874 1143 0.1% 1143.0 -- NPC-AS-KR National Pension Corporation 11 - AS56341 1094 0.1% 1094.0 -- ENTER-AS ENTER, LLC 12 - AS19743 5361 0.4% 893.5 -- 13 - AS2 677 0.1% 56.0 -- MN-NDC-MN National Data Center building 14 - AS22288 623 0.0% 623.0 -- RFBKCORP - Republic First Bancorp, Inc. 15 - AS3 598 0.0% 735.0 -- FWP-AS Funkwerk plettac electronic GmbH 16 - AS44355 564 0.0% 564.0 -- AUTOSCOUT24-AS AutoScout24 GmbH 17 - AS9245 8510 0.6% 531.9 -- COMPASS-NZ-AP COMPASS NZ 18 - AS17408 2990 0.2% 498.3 -- ABOVE-AS-AP AboveNet Communications Taiwan 19 - AS28519 1483 0.1% 494.3 -- Universidad Autonoma de Guadalajara, A.C. 20 - AS3505 978 0.1% 489.0 -- WINDSTREAM - Windstream Communications Inc TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 202.92.235.0/24 11726 0.8% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 2 - 85.197.100.0/22 9836 0.6% AS25220 -- GLOBALNOC-AS Averbo GmbH 3 - 130.36.35.0/24 8955 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.34.0/24 8953 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 63.211.68.0/22 8020 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 212.80.25.0/24 5270 0.3% AS51280 -- AS51280 Parsian Electronic Commerce Company 7 - 221.121.96.0/19 4872 0.3% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 8 - 198.140.43.0/24 4831 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - 68.65.152.0/22 3464 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 10 - 206.184.16.0/24 3355 0.2% AS174 -- COGENT Cogent/PSI 11 - 79.98.204.0/22 3348 0.2% AS42408 -- TSV-AS JSC Company Transsviaz 12 - 79.98.200.0/22 3348 0.2% AS42408 -- TSV-AS JSC Company Transsviaz 13 - 202.153.174.0/24 2950 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 14 - 178.22.79.0/24 2836 0.2% AS44609 -- FNA Fars News Agency Cultural Arts Institute 15 - 203.192.205.0/24 2724 0.2% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd. AS9498 -- BBIL-AP BHARTI Airtel Ltd. 16 - 203.192.204.0/24 2722 0.2% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd. AS9498 -- BBIL-AP BHARTI Airtel Ltd. 17 - 178.22.72.0/21 2713 0.2% AS44609 -- FNA Fars News Agency Cultural Arts Institute 18 - 208.54.82.0/24 2712 0.2% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 19 - 190.15.7.128/25 2335 0.1% AS27817 -- Red Nacional Acad?mica de Tecnolog?a Avanzada - RENATA 20 - 71.48.160.0/20 1983 0.1% AS6367 -- EMBARQ-KLLN - Embarq Corporation Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 18 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 18 Mar 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201103182200.p2IM00GO074447@wattle.apnic.net> This report has been generated at Fri Mar 18 21:12:17 2011 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 11-03-11 351885 205662 12-03-11 351935 205702 13-03-11 352144 205910 14-03-11 352370 206016 15-03-11 352494 206757 16-03-11 354080 205926 17-03-11 351746 206331 18-03-11 352404 206405 AS Summary 37074 Number of ASes in routing system 15613 Number of ASes announcing only one prefix 3675 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109185280 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'). --- 18Mar11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 352388 206365 146023 41.4% All ASes AS6389 3675 264 3411 92.8% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2560 406 2154 84.1% TWTC - tw telecom holdings, inc. AS4766 2426 915 1511 62.3% KIXS-AS-KR Korea Telecom AS6478 1551 192 1359 87.6% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1287 89 1198 93.1% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1488 299 1189 79.9% VZGNI-TRANSIT - Verizon Online LLC AS4755 1478 362 1116 75.5% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS10620 1392 327 1065 76.5% Telmex Colombia S.A. AS1785 1795 766 1029 57.3% AS-PAETEC-NET - PaeTec Communications, Inc. AS18566 1606 627 979 61.0% COVAD - Covad Communications Co. AS28573 1245 317 928 74.5% NET Servicos de Comunicao S.A. AS6503 1176 384 792 67.3% Axtel, S.A.B. de C.V. AS18101 936 153 783 83.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7545 1570 814 756 48.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 923 191 732 79.3% Telecom Argentina S.A. AS4808 1050 330 720 68.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS24560 1134 420 714 63.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3356 1177 486 691 58.7% LEVEL3 Level 3 Communications AS8151 1235 551 684 55.4% Uninet S.A. de C.V. AS17488 936 270 666 71.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS11492 1314 649 665 50.6% CABLEONE - CABLE ONE, INC. AS4780 869 235 634 73.0% SEEDNET Digital United Inc. AS17676 657 70 587 89.3% GIGAINFRA Softbank BB Corp. AS855 639 58 581 90.9% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17908 624 67 557 89.3% TCISL Tata Communications AS3549 913 377 536 58.7% GBLX Global Crossing Ltd. AS14420 639 103 536 83.9% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22561 860 327 533 62.0% DIGITAL-TELEPORT - Digital Teleport Inc. AS7552 626 98 528 84.3% VIETEL-AS-AP Vietel Corporation AS9498 776 263 513 66.1% BBIL-AP BHARTI Airtel Ltd. Total 38557 10410 28147 73.0% Top 30 total Possible Bogus Routes 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 31.31.96.0/19 AS6876 TENET-AS TeNeT Autonomous System 31.31.160.0/21 AS50168 BOGALNET Bogal AB 41.57.192.0/18 AS22750 BCSNET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 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.207.192.0/24 AS30304 64.207.193.0/24 AS30304 64.207.194.0/24 AS30304 64.207.195.0/24 AS30304 64.207.196.0/24 AS30304 64.207.197.0/24 AS30304 64.207.198.0/24 AS30304 64.207.200.0/24 AS30304 64.207.201.0/24 AS30304 64.207.202.0/24 AS30304 64.207.203.0/24 AS30304 64.207.204.0/24 AS30304 64.207.205.0/24 AS30304 64.207.206.0/24 AS30304 64.207.208.0/20 AS30304 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 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 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 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 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 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.54.160.0/24 AS38890 121.54.161.0/24 AS38890 121.54.162.0/24 AS38890 121.54.163.0/24 AS38890 121.54.164.0/24 AS38890 121.54.166.0/24 AS38890 121.54.167.0/24 AS38890 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 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 172.33.69.0/24 AS36992 ETISALAT-MISR 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 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.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 G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - 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.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 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 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 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.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - 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.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. 200.24.73.0/24 AS26061 Equant Colombia 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 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.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 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.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.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.131.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.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 INTERNODE-AS Internode Pty Ltd 203.30.26.0/23 AS3491 BTN-ASN - Beyond The Network America, Inc. 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone 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 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 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 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 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.105.192.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.196.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.200.0/21 AS7385 INTEGRATELECOM - Integra Telecom, 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.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From owen at delong.com Fri Mar 18 17:49:01 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 18 Mar 2011 15:49:01 -0700 Subject: SP's and v4 block assignments In-Reply-To: <4D83CA69.8080806@mompl.net> References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> <4D83CA69.8080806@mompl.net> Message-ID: On Mar 18, 2011, at 2:11 PM, Jeroen van Aart wrote: > Owen DeLong wrote: >> I'll point out that Comcast charges $5/month for a static IP on their business circuits. > > I get charged $6 for a static IP for a home internet connection (not a business account). Although in the Netherlands xs4all will give you one for free, so it depends. > In the US, Comcast won't give you a static on a home connection. You have to subscribe to business class service to get a static IP. > I am wondering though, is it normal to charge around $5/month for rDNS on that IP? I'd say a one time fee for the effort of adding the record to the nameserver would be enough. But then maybe the consumer ISP gets charged by their ISP for rDNS. > I've never had anyone charge me for hosting DNS or providing rDNS, but, I haven't needed anyone else to do that for me in so long that I have no idea what is standard now. >> This is not uncommon practice. I agree with you that it's undesirable, but, it's not uncommon >> among the access networks. > > I guess it's ok to expect a small fee when your consumer grade internet connection gets a static IP. Given that many large ISPs force you to get a business account if you want a static IP, and a higher price. > I think both practices are relatively despicable, but, widespread enough that perhaps I am in the minority. Hopefully this will get better in IPv6. Owen From tshaw at oitc.com Fri Mar 18 18:03:59 2011 From: tshaw at oitc.com (TR Shaw) Date: Fri, 18 Mar 2011 19:03:59 -0400 Subject: SP's and v4 block assignments In-Reply-To: References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> <4D83CA69.8080806@mompl.net> Message-ID: <7903C248-FD54-41C5-959E-AA055BD31FE9@oitc.com> On Mar 18, 2011, at 6:49 PM, Owen DeLong wrote: > > On Mar 18, 2011, at 2:11 PM, Jeroen van Aart wrote: > >>> This is not uncommon practice. I agree with you that it's undesirable, but, it's not uncommon >>> among the access networks. >> >> I guess it's ok to expect a small fee when your consumer grade internet connection gets a static IP. Given that many large ISPs force you to get a business account if you want a static IP, and a higher price. >> > I think both practices are relatively despicable, but, widespread enough that perhaps I am in the minority. > Hopefully this will get better in IPv6. > Owen, I doubt it will get better. Lots are into nickle and dime'ing for everyone to get an extra buck. Look at wireless, they charge for x Mega/giga bits per month from your hand help device (phone). Oh you want to tether, that will be more? Say what? Bits are bits but somehow tethered bits are different. Oh, its cause we can pretend and charge more for them.... Tom From jlewis at lewis.org Fri Mar 18 18:27:20 2011 From: jlewis at lewis.org (Jon Lewis) Date: Fri, 18 Mar 2011 19:27:20 -0400 (EDT) Subject: SP's and v4 block assignments In-Reply-To: <4D83CA69.8080806@mompl.net> References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> <4D83CA69.8080806@mompl.net> Message-ID: On Fri, 18 Mar 2011, Jeroen van Aart wrote: > I get charged $6 for a static IP for a home internet connection (not a > business account). Although in the Netherlands xs4all will give you one for > free, so it depends. > > I am wondering though, is it normal to charge around $5/month for rDNS on > that IP? I'd say a one time fee for the effort of adding the record to the > nameserver would be enough. But then maybe the consumer ISP gets charged by > their ISP for rDNS. My past two ISPs (Cox and Brighthouse) both charge extra (require you to upgrade to business class service) for a static IP, and charge extra for each additional IP if you want more than one. Cox did customer requested PTR for no extra charge. BHN wanted $ for it. I can't see any reason for it other than it's something they can charge for, so why shouldn't they? I've actually been considering going back to residential service and OpenVPN for my static addressing. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From xenophage at godshell.com Fri Mar 18 21:12:26 2011 From: xenophage at godshell.com (Jason 'XenoPhage' Frisvold) Date: Fri, 18 Mar 2011 22:12:26 -0400 Subject: [Nanog] Re: US .mil blocking in Japan In-Reply-To: <8A57EFB7-F08A-42A5-A2B3-C22CEE54319A@deman.com> References: <582587.43563.qm@web59616.mail.ac4.yahoo.com> <4D811C08.1000000@emmanuelcomputerconsulting.com> <74ED5184-E383-4A83-B588-23606263D0AA@godshell.com> <8A57EFB7-F08A-42A5-A2B3-C22CEE54319A@deman.com> Message-ID: <85F1AE10-6342-4766-A7ED-1E5B5C54C16D@godshell.com> On Mar 18, 2011, at 12:33 AM, Michael DeMan wrote: > Wasn't this announced on the news already? Yup, I learned more about it later after I saw this on Nanog. > I am definitely not one to be outside of hearing about a conspiracy theory or something, but I know up in our neck of the woods in the NorthWest of NorthWest Washington State, that this is just common sense to do. Wasn't trying to pass anything off as a conspiracy theory, just passing on info I was given by someone on-site. --------------------------- Jason 'XenoPhage' Frisvold xenophage at godshell.com --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - Niven's Inverse of Clarke's Third Law From fred at cisco.com Fri Mar 18 23:49:00 2011 From: fred at cisco.com (Fred Baker) Date: Fri, 18 Mar 2011 21:49:00 -0700 Subject: [Nanog] Re: US .mil blocking in Japan In-Reply-To: <74ED5184-E383-4A83-B588-23606263D0AA@godshell.com> References: <582587.43563.qm@web59616.mail.ac4.yahoo.com> <4D811C08.1000000@emmanuelcomputerconsulting.com> <74ED5184-E383-4A83-B588-23606263D0AA@godshell.com> Message-ID: <68AFFF98-AE52-44CE-AB41-9446987024D3@cisco.com> On Mar 17, 2011, at 6:57 PM, Jason 'XenoPhage' Frisvold wrote: > Could this also be part of a "communications blackout" ? No, not in a sinister, government keeping secrets, manner. A friend of mine serves on a ship that's over there right now. He dropped me a note last night that they were going into a communications blackout to try and control some of the wild miscommunication being sent out. That's fairly common with naval operations. They go into a blackout when there is some probability of a PR or intelligence fumble, usually related to an upcoming mission assignment. From owen at delong.com Sat Mar 19 10:35:03 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 19 Mar 2011 08:35:03 -0700 Subject: SP's and v4 block assignments In-Reply-To: <7903C248-FD54-41C5-959E-AA055BD31FE9@oitc.com> References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> <4D83CA69.8080806@mompl.net> <7903C248-FD54-41C5-959E-AA055BD31FE9@oitc.com> Message-ID: On Mar 18, 2011, at 4:03 PM, TR Shaw wrote: > > On Mar 18, 2011, at 6:49 PM, Owen DeLong wrote: > >> >> On Mar 18, 2011, at 2:11 PM, Jeroen van Aart wrote: >> >>>> This is not uncommon practice. I agree with you that it's undesirable, but, it's not uncommon >>>> among the access networks. >>> >>> I guess it's ok to expect a small fee when your consumer grade internet connection gets a static IP. Given that many large ISPs force you to get a business account if you want a static IP, and a higher price. >>> >> I think both practices are relatively despicable, but, widespread enough that perhaps I am in the minority. >> Hopefully this will get better in IPv6. >> > > Owen, > > I doubt it will get better. Lots are into nickle and dime'ing for everyone to get an extra buck. Look at wireless, they charge for x Mega/giga bits per month from your hand help device (phone). Oh you want to tether, that will be more? Say what? Bits are bits but somehow tethered bits are different. Oh, its cause we can pretend and charge more for them.... > > Tom > Well... Let's see: Verizon: $20/month for unlimited data service on iPhone 4 (without tethering) AT&T: $29.95/month for unlimited data service on my iPad SPRINT: 4G Unlimited Everything plan: $127.45/month (all taxes, fees, handset insurance, etc. included) (3G $10/month less) Metro: $40/month for unlimited talk/text/web Where's the $/mbytes/month in those prices? Yes, they are now trying to charge more for tethering. I think the additional charges for tethering are because tethered tends to use significantly more bandwidth on average than non-tethered. I agree that charging for tethering is also somewhat despicable and I haven't added tethering to my plan for that reason. Rumor has it that there is now a tethering app. out for Droid that will bypass the $/tethering issue. I haven't tried it yet. Owen From nathan at atlasnetworks.us Sat Mar 19 10:53:59 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sat, 19 Mar 2011 15:53:59 +0000 Subject: SP's and v4 block assignments In-Reply-To: <7903C248-FD54-41C5-959E-AA055BD31FE9@oitc.com> References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> <4D83CA69.8080806@mompl.net> <7903C248-FD54-41C5-959E-AA055BD31FE9@oitc.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3DCE3D@ex-mb-1.corp.atlasnetworks.us> > I doubt it will get better. Lots are into nickle and dime'ing for > everyone to get an extra buck. Look at wireless, they charge for x > Mega/giga bits per month from your hand help device (phone). Oh you > want to tether, that will be more? Say what? Bits are bits but somehow > tethered bits are different. Oh, its cause we can pretend and charge > more for them.... I don't think it's a matter of pretending that some bits are different than others. The simple reality is that for the vast, vast majority of cell phone users, they will generate a tiny number of packets untethered, and a fair number of packets tethered. Given that many tower backhauls, especially in metropolitan areas, are already far above their data/channel capacity, it's obvious that this is (and always has been) an attempt to discourage tethering. As for charging for residential static assignments, I don't think it's all that odd, or 'despicable'. Allocating static assignments consumes engineer time for configuration and documentation. On a business class service, you can eat that cost fairly easily. On a low-yield residential circuit, there has to be some long term ROI because that work probably takes the margin out of the service for months. Nathan As always, these are my own views, and not that of my employer. From jsw at inconcepts.biz Sat Mar 19 11:46:57 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sat, 19 Mar 2011 12:46:57 -0400 Subject: SP's and v4 block assignments In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3DCE3D@ex-mb-1.corp.atlasnetworks.us> References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> <4D83CA69.8080806@mompl.net> <7903C248-FD54-41C5-959E-AA055BD31FE9@oitc.com> <8C26A4FDAE599041A13EB499117D3C286B3DCE3D@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Sat, Mar 19, 2011 at 11:53 AM, Nathan Eisenberg wrote: > As for charging for residential static assignments, I don't think it's all that odd, or 'despicable'. ?Allocating static assignments consumes engineer time for configuration and documentation. ?On a business class service, you can eat that cost fairly easily. ?On a low-yield residential circuit, there has to be some long term ROI because that work probably takes the margin out of the service for months. "Engineer time" is not an issue. If it requires an "engineer" for "configuration" and "documentation," the provisioning process is already flawed. The reason to not want residential users to have static IPs is that these users represent large chunks of traffic which can be easily moved from one group of HFC channels to another when additional capacity must be created by breaking up access network segments. If many users had a static IP, this would be more difficult. Since most users don't have a static IP, the overhead of dealing with the few users who do is entirely manageable, especially when these users are paying a higher fee. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From gih at apnic.net Sat Mar 19 17:40:43 2011 From: gih at apnic.net (Geoff Huston) Date: Sun, 20 Mar 2011 09:40:43 +1100 Subject: Weekly Routing Table Report In-Reply-To: References: <201103181838.p2IIc3Ye027532@thyme.rand.apnic.net> Message-ID: <89DC638D-DB0E-453A-A1D7-47BB2E892A2C@apnic.net> On 19/03/2011, at 6:08 AM, Mikael Abrahamsson wrote: > On Sat, 19 Mar 2011, Routing Analysis Role Account wrote: > >> Number of 32-bit ASNs allocated by the RIRs: 1207 >> Prefixes from 32-bit ASNs in the Routing Table: 1 > > Is the report not getting the routes from the real 32bit ASNs or is the above figures really accurate? Its probably not getting the routes - I see 915 AS's in the routing table using 32 bit AS numbers (http://www.potaroo.net/tools/asn32/) Geoff From owen at delong.com Sun Mar 20 02:28:08 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 20 Mar 2011 00:28:08 -0700 Subject: SP's and v4 block assignments In-Reply-To: References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> <4D83CA69.8080806@mompl.net> <7903C248-FD54-41C5-959E-AA055BD31FE9@oitc.com> <8C26A4FDAE599041A13EB499117D3C286B3DCE3D@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Mar 19, 2011, at 9:46 AM, Jeff Wheeler wrote: > On Sat, Mar 19, 2011 at 11:53 AM, Nathan Eisenberg > wrote: >> As for charging for residential static assignments, I don't think it's all that odd, or 'despicable'. Allocating static assignments consumes engineer time for configuration and documentation. On a business class service, you can eat that cost fairly easily. On a low-yield residential circuit, there has to be some long term ROI because that work probably takes the margin out of the service for months. > > "Engineer time" is not an issue. If it requires an "engineer" for > "configuration" and "documentation," the provisioning process is > already flawed. The reason to not want residential users to have > static IPs is that these users represent large chunks of traffic which > can be easily moved from one group of HFC channels to another when > additional capacity must be created by breaking up access network > segments. If many users had a static IP, this would be more > difficult. Since most users don't have a static IP, the overhead of > dealing with the few users who do is entirely manageable, especially > when these users are paying a higher fee. > This assumes an HFC network and not a PON or DSL topology where it is not an issue. Owen From alex.wilkinson at dsto.defence.gov.au Sun Mar 20 09:24:45 2011 From: alex.wilkinson at dsto.defence.gov.au (Wilkinson, Alex) Date: Sun, 20 Mar 2011 22:24:45 +0800 Subject: Simple Low Cost WAN Link Simulator Recommendations [SEC=UNCLASSIFIED] In-Reply-To: <4D8395F6.4070502@Lugoj.com> References: <4D8395F6.4070502@Lugoj.com> Message-ID: <20110320142445.GC1650@stlux503.dsto.defence.gov.au> 0n Fri, Mar 18, 2011 at 10:27:18AM -0700, Jim Logajan wrote: >Loopback wrote: >> Need the ability to test Network Management and Provisioning >> applications over a variety of WAN link speeds from T1 equivalent up to >> 1GB speeds. Seems to be quite a few offerings but I am looking for >> recommendations from actual users. Thanks in advance. FreeBSD + DummyNet [http://www.freebsd.org/cgi/man.cgi?query=dummynet&sektion=4] -Alex IMPORTANT: This email remains the property of the Department of Defence and is subject to the jurisdiction of section 70 of the Crimes Act 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From jsw at inconcepts.biz Sun Mar 20 13:18:54 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 20 Mar 2011 14:18:54 -0400 Subject: SP's and v4 block assignments In-Reply-To: References: <546905.53339.qm@web120919.mail.ne1.yahoo.com> <62A33F6D-43FD-444B-9635-4E5DD200A867@delong.com> <4D83CA69.8080806@mompl.net> <7903C248-FD54-41C5-959E-AA055BD31FE9@oitc.com> <8C26A4FDAE599041A13EB499117D3C286B3DCE3D@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Sun, Mar 20, 2011 at 3:28 AM, Owen DeLong wrote: > This assumes an HFC network and not a PON or DSL topology > where it is not an issue. It assumes that the access network topology does not employ any kind of triangular routing to terminate the subscriber's layer-3 traffic on a desired access router, as opposed to one dictated by where the subscriber's layer-1 facility terminates. It's really not an issue of HFC or DSL, and I guess I should have spelled it out since several folks failed to understand that -- it's an issue of carrying routes for customer static IPs in your IGP or being able to steer their sessions to a certain device. I'm sure we all remember the days when ordinary dial-up subscribers could get a static IP address from nation-wide dial-up ISPs, and the network took care of routing that static IP to whatever box was receiving the modem call. The problems with scaling up static IPs for fixed-line services are much less troublesome than a nation-wide switched access service like dial-up; but the same basic constraints apply -- you need triangular routing, or a bigger routing table, when users' static IPs are not bound to an aggregate pool for their layer-3 access router. "Almost Static IPs," which remain unchanged until your ISP has some need to reorganize their access network and move you into a different IP address pool, are a good compromise that are okay for many end-users. That eliminates all the technical challenges (from the ISP perspective) and yet there are many ISPs that offer this product only to "business" customers, not ordinary residential subscribers -- which means you're still left with the issue that they simply don't want to offer anything like a static IP to the lowest-margin customers, as they hope it will force some subscribers to upgrade to a higher-cost service. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From Skeeve at eintellego.net Sun Mar 20 16:44:50 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Mon, 21 Mar 2011 08:44:50 +1100 Subject: CSI New York fake IPv6 Message-ID: All, I just thought this is amusing that in CSI: New York ? Season 7, Episode 17, they do a 'Remote Desktop' hack and they enter in the following details? http://www.eintellego.net/public/CSINY.s07e17-fakev6.jpg Promoting IPv6 = Win! Dodgy Address = Fail! But seriously? That a major TV show is actually using IPv6 addressing (or pretending to) is an awesome thing in my opinion. ?Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego or eintellego at facebook.com twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis From mpetach at netflight.com Sun Mar 20 17:20:58 2011 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 20 Mar 2011 15:20:58 -0700 Subject: Simple Low Cost WAN Link Simulator Recommendations In-Reply-To: <4D82132D.6080107@digi-muse.com> References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> <4D82132D.6080107@digi-muse.com> Message-ID: On Thu, Mar 17, 2011 at 6:57 AM, Loopback wrote: > Need the ability to test Network Management and Provisioning applications > over a variety of WAN link speeds from T1 equivalent up to 1GB speeds. > ?Seems to be quite a few offerings but I am looking for recommendations from > actual users. ? Thanks in advance. We've used FreeBSD + dummynet on a multi-NIC box in bridging mode to do 'bump on the wire' WAN simulations involving packet loss, latency, and unidirectional packet flow variances. Works wonderfully, and the price is right. Matt From tdurack at gmail.com Sun Mar 20 17:30:07 2011 From: tdurack at gmail.com (Tim Durack) Date: Sun, 20 Mar 2011 18:30:07 -0400 Subject: Simple Low Cost WAN Link Simulator Recommendations In-Reply-To: References: <4D80EBBC.6040202@forthnet.gr> <20110316170343.GA68199@gerbil.cluepon.net> <4D8100B6.9070602@forthnet.gr> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C40F@comsrv01.fg.local> <1A8A762BD508624A8BDAB9F5E1638F945FB4C3C43A@comsrv01.fg.local> <4D82132D.6080107@digi-muse.com> Message-ID: On Sun, Mar 20, 2011 at 6:20 PM, Matthew Petach wrote: > On Thu, Mar 17, 2011 at 6:57 AM, Loopback wrote: > > Need the ability to test Network Management and Provisioning applications > > over a variety of WAN link speeds from T1 equivalent up to 1GB speeds. > > Seems to be quite a few offerings but I am looking for recommendations > from > > actual users. Thanks in advance. > Linux tc netem: http://www.linuxfoundation.org/collaborate/workgroups/networking/netem Has worked well for us. -- Tim:> From Valdis.Kletnieks at vt.edu Sun Mar 20 17:29:22 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 20 Mar 2011 18:29:22 -0400 Subject: CSI New York fake IPv6 In-Reply-To: Your message of "Mon, 21 Mar 2011 08:44:50 +1100." References: Message-ID: <55275.1300660162@localhost> On Mon, 21 Mar 2011 08:44:50 +1100, Skeeve Stevens said: > http://www.eintellego.net/public/CSINY.s07e17-fakev6.jpg > > Promoting IPv6 = Win! > Dodgy Address = Fail! Intentional Fail, probably, similar to how most phone numbers on a TV show are in the 555 exchange. You put a number on TV, and drunk idiots will call it, as a number of annoyed people found out after Tommy Tutone had an actual hit song... 257 seems to be a popular octet value. (Personally, I'm surprised 148.18.1.193 got used in that image) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From patrick at ianai.net Sun Mar 20 17:35:35 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 20 Mar 2011 18:35:35 -0400 Subject: CSI New York fake IPv6 In-Reply-To: <55275.1300660162@localhost> References: <55275.1300660162@localhost> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 20, 2011, at 6:29 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 21 Mar 2011 08:44:50 +1100, Skeeve Stevens said: > >> http://www.eintellego.net/public/CSINY.s07e17-fakev6.jpg >> >> Promoting IPv6 = Win! >> Dodgy Address = Fail! > > Intentional Fail, probably, similar to how most phone numbers on a TV show are > in the 555 exchange. You put a number on TV, and drunk idiots will call it, as > a number of annoyed people found out after Tommy Tutone had an actual hit > song... 257 seems to be a popular octet value. > > (Personally, I'm surprised 148.18.1.193 got used in that image) So am I. But I'm surprised 1918 space was used as well. ANY v4 address will get typed into ping or a browser or something by someone if it is on TV. How many corporations have 1918 space that their VPN'ed home users are about to abuse because of that? Is 127.0.0.1 / ::1 the Internet version of "555"? Or will "I hurt myself, so now I'm going to sue you" mean we can't even use that? - - -- TTFN, patrick - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk2GgTEACgkQznMLL4aoth+u3wCglGK+yrFj3PhI61O78IEqQ40V KyMAoK0MJ26OxPab10za4LQ6U8qomrPU =uJz7 - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAk2GgTcACgkQznMLL4aoth9c8ACgkT0XYIAsZ2IORlYH+nopOLmH z/sAoLILGcEnxhR1QHXnU+NvJPDuaYvT =RNrE -----END PGP SIGNATURE----- From Skeeve at eintellego.net Sun Mar 20 17:39:54 2011 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Mon, 21 Mar 2011 09:39:54 +1100 Subject: CSI New York fake IPv6 In-Reply-To: <55275.1300660162@localhost> Message-ID: Especially since 148.18 is Department of Defence - but it doesn't seem to be routed at the moment. ...Skeeve -- Skeeve Stevens, CEO - eintellego Pty Ltd - The Networking Specialists skeeve at eintellego.net ; www.eintellego.net Phone: 1300 753 383 ; Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 ; skype://skeeve facebook.com/eintellego or eintellego at facebook.com twitter.com/networkceoau ; www.linkedin.com/in/skeeve PO Box 7726, Baulkham Hills, NSW 1755 Australia -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Brocade - Arista - Allied Telesis On 21/03/11 9:29 AM, "Valdis.Kletnieks at vt.edu" > wrote: On Mon, 21 Mar 2011 08:44:50 +1100, Skeeve Stevens said: http://www.eintellego.net/public/CSINY.s07e17-fakev6.jpg Promoting IPv6 = Win! Dodgy Address = Fail! Intentional Fail, probably, similar to how most phone numbers on a TV show are in the 555 exchange. You put a number on TV, and drunk idiots will call it, as a number of annoyed people found out after Tommy Tutone had an actual hit song... 257 seems to be a popular octet value. (Personally, I'm surprised 148.18.1.193 got used in that image) From paul at paulgraydon.co.uk Sun Mar 20 20:01:41 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Sun, 20 Mar 2011 15:01:41 -1000 Subject: CSI New York fake IPv6 In-Reply-To: References: Message-ID: <4D86A375.1070909@paulgraydon.co.uk> On 3/20/2011 11:44 AM, Skeeve Stevens wrote: > All, > > I just thought this is amusing that in CSI: New York ? Season 7, Episode 17, they do a 'Remote Desktop' hack and they enter in the following details? > > http://www.eintellego.net/public/CSINY.s07e17-fakev6.jpg > > Promoting IPv6 = Win! > Dodgy Address = Fail! > > But seriously? That a major TV show is actually using IPv6 addressing (or pretending to) is an awesome thing in my opinion. > Makes a good change from a 5 octet IP number I remember them using in one episode revolving around an adult webcam website. Paul From jra at baylink.com Sun Mar 20 21:21:37 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 20 Mar 2011 22:21:37 -0400 (EDT) Subject: CSI New York fake IPv6 In-Reply-To: Message-ID: <27306108.22.1300674097914.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Patrick W. Gilmore" > Is 127.0.0.1 / ::1 the Internet version of "555"? Or will "I hurt > myself, so now I'm going to sue you" mean we can't even use that? I'm a touch surprised that *you're* asking that question, Patrick. I figured your chapeau was geriatric enough you'd already know. :-) No, there are several reserved stretches of both IPv4 and DNS space for just such reasons. example.com is the most common and well known, but see also RFC 3330 and RFC 5737, not necessarily in that order. Anyone who really *wants* to run nmap on camera has lots of safe networks to point it at. Cheers, -- jra From sfouant at shortestpathfirst.net Sun Mar 20 21:45:17 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sun, 20 Mar 2011 22:45:17 -0400 Subject: CSI New York fake IPv6 In-Reply-To: <4D86A375.1070909@paulgraydon.co.uk> References: <4D86A375.1070909@paulgraydon.co.uk> Message-ID: <009c01cbe772$35aeb080$a10c1180$@net> > -----Original Message----- > From: Paul Graydon [mailto:paul at paulgraydon.co.uk] > Sent: Sunday, March 20, 2011 9:02 PM > To: nanog at nanog.org > Subject: Re: CSI New York fake IPv6 > > > But seriously. That a major TV show is actually using IPv6 addressing > (or pretending to) is an awesome thing in my opinion. > > > Makes a good change from a 5 octet IP number I remember them using in > one episode revolving around an adult webcam website. I remember seeing that show. I think they had Jim Fleming on as a consultant. ;> Stefan Fouant From jra at baylink.com Sun Mar 20 21:50:24 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 20 Mar 2011 22:50:24 -0400 (EDT) Subject: CSI New York fake IPv6 In-Reply-To: <009c01cbe772$35aeb080$a10c1180$@net> Message-ID: <23562991.30.1300675824164.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Stefan Fouant" > > Makes a good change from a 5 octet IP number I remember them using > > in one episode revolving around an adult webcam website. > > I remember seeing that show. I think they had Jim Fleming on as a > consultant. ;> Shhh... don't say his name. I think he Kibozes. Cheers, -- jra From jsw at inconcepts.biz Sun Mar 20 21:51:58 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sun, 20 Mar 2011 22:51:58 -0400 Subject: CSI New York fake IPv6 In-Reply-To: <27306108.22.1300674097914.JavaMail.root@benjamin.baylink.com> References: <27306108.22.1300674097914.JavaMail.root@benjamin.baylink.com> Message-ID: On Sun, Mar 20, 2011 at 10:21 PM, Jay Ashworth wrote: > No, there are several reserved stretches of both IPv4 and DNS space > for just such reasons. ?example.com is the most common and well known, > but see also RFC 3330 and RFC 5737, not necessarily in that order. See also this thread http://mailman.nanog.org/pipermail/nanog/2011-March/034179.html from less than two weeks ago for discussion of this in relation to IPv6. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From paul at telcodata.us Mon Mar 21 00:35:50 2011 From: paul at telcodata.us (Paul Timmins) Date: Mon, 21 Mar 2011 01:35:50 -0400 Subject: CSI New York fake IPv6 In-Reply-To: References: <55275.1300660162@localhost> Message-ID: <4D86E3B6.6080807@telcodata.us> Patrick W. Gilmore wrote: > Is 127.0.0.1 / ::1 the Internet version of "555"? Or will "I hurt myself, so now I'm going to sue you" mean we can't even use that? > It'd be nice if TV producers even knew that not all of 555 was to be used for television shows*, let alone that there's an internet equivalent. Heck, it'd be nice if phone companies knew they weren't supposed to route all of 555 to information (Hi, Global Crossing). I can only assume it's some sort of "stupid tax" for people who dial crap they see on TV. -Paul * = http://www.nanpa.com/nas/public/form555MasterReport.do?method=display555MasterReport Only the range of 0100-0199 is to be used for ficticious use From nanog at jima.tk Mon Mar 21 00:47:49 2011 From: nanog at jima.tk (Jima) Date: Mon, 21 Mar 2011 00:47:49 -0500 Subject: CSI New York fake IPv6 In-Reply-To: References: Message-ID: <4D86E685.8020606@jima.tk> On 3/20/2011 4:44 PM, Skeeve Stevens wrote: > Promoting IPv6 = Win! > Dodgy Address = Fail! > > But seriously? That a major TV show is actually using IPv6 addressing (or pretending to) is an awesome thing in my opinion. More curious, for me, is their choice of a hardware vendor: Alacron, Inc. ( http://www.alacron.com/ ) (Source: Address in screenshot: 2002:sc0c:0198:0 ... 22:42ff:fe2d:48563 -- making the MAC prefix ??:22:42. `grep '^..2242' /usr/share/nmap/nmap-mac-prefixes` = "002242 Alacron", double-checked as the only match against the latest http://standards.ieee.org/develop/regauth/oui/oui.txt ) Jima From member at linkedin.com Mon Mar 21 00:57:40 2011 From: member at linkedin.com (Rod James Bio via LinkedIn) Date: Mon, 21 Mar 2011 05:57:40 +0000 (UTC) Subject: Invitation to connect on LinkedIn Message-ID: <1785847341.4712882.1300687060848.JavaMail.app@ela4-bed36.prod> LinkedIn ------------Rod James Bio requested to add you as a connection on LinkedIn: ------------------------------------------ Ted, I'd like to add you to my professional network on LinkedIn. - Rod James Accept invitation from Rod James Bio http://www.linkedin.com/e/-voa23o-glizhral-1k/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I1208666905_3/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYPnPkMejoSdzwMcz59bR0SsShJjkxnbPwNdPkPd30Qdj8LrCBxbOYWrSlI/EML_comm_afe/ View invitation from Rod James Bio http://www.linkedin.com/e/-voa23o-glizhral-1k/q0XU4EiXDUS2IbxL1NdPb3ZaZI/blk/I1208666905_3/3dvdj0VdzoSe30OckALqnpPbOYWrSlI/svi/ ------------------------------------------ DID YOU KNOW that LinkedIn can find the answers to your most difficult questions? Post those vexing questions on LinkedIn Answers to tap into the knowledge of the world's foremost business experts: http://www.linkedin.com/e/-voa23o-glizhral-1k/ask/inv-23/ -- (c) 2011, LinkedIn Corporation From millnert at gmail.com Mon Mar 21 01:04:30 2011 From: millnert at gmail.com (Martin Millnert) Date: Mon, 21 Mar 2011 02:04:30 -0400 Subject: CSI New York fake IPv6 In-Reply-To: References: <55275.1300660162@localhost> Message-ID: On Sun, Mar 20, 2011 at 6:35 PM, Patrick W. Gilmore wrote: > Is 127.0.0.1 / ::1 the Internet version of "555"? Not according to the RFC:s. Given the use of "555" in the (North American) TV world, and the regularity with which IETF defines specific example resources of various sorts, one would almost expect there'd be "555"-equivalent address spaces defined by the IETF already. I assume it has been discussed and rejected. Can anyone enlighten us on why? Regards, Martin PS. It's quite obvious that it would be announced and point to HTTP servers serving responses containing various evil things, I guess? PPS. Didn't know Adobe made web browsers with remote connect clients in them. :) From starcat at starcat.rlyeh.net Mon Mar 21 04:25:33 2011 From: starcat at starcat.rlyeh.net (Ina Faye-Lund) Date: Mon, 21 Mar 2011 10:25:33 +0100 Subject: CSI New York fake IPv6 In-Reply-To: References: <55275.1300660162@localhost> Message-ID: <20110321092533.GA23251@fnord.no> On Sun, Mar 20, 2011 at 06:35:35PM -0400, Patrick W. Gilmore wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mar 20, 2011, at 6:29 PM, Valdis.Kletnieks at vt.edu wrote: > > On Mon, 21 Mar 2011 08:44:50 +1100, Skeeve Stevens said: > > > >> http://www.eintellego.net/public/CSINY.s07e17-fakev6.jpg > >> > >> Promoting IPv6 = Win! > >> Dodgy Address = Fail! > > > > Intentional Fail, probably, similar to how most phone numbers on a TV show are > > in the 555 exchange. You put a number on TV, and drunk idiots will call it, as > > a number of annoyed people found out after Tommy Tutone had an actual hit > > song... 257 seems to be a popular octet value. > > > > (Personally, I'm surprised 148.18.1.193 got used in that image) > > So am I. But I'm surprised 1918 space was used as well. ANY v4 address will get typed into ping or a browser or something by someone if it is on TV. How many corporations have 1918 space that their VPN'ed home users are about to abuse because of that? > > Is 127.0.0.1 / ::1 the Internet version of "555"? Or will "I hurt myself, so now I'm going to sue you" mean we can't even use that? I would have used 192.0.2.0/24. It is the IPv4 version of example.com. -- Ina From robert at ripe.net Mon Mar 21 05:06:24 2011 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 21 Mar 2011 11:06:24 +0100 Subject: Weekly Routing Table Report In-Reply-To: <89DC638D-DB0E-453A-A1D7-47BB2E892A2C@apnic.net> References: <201103181838.p2IIc3Ye027532@thyme.rand.apnic.net> <89DC638D-DB0E-453A-A1D7-47BB2E892A2C@apnic.net> Message-ID: <4D872320.9070906@ripe.net> On 2011.03.19. 23:40, Geoff Huston wrote: > > On 19/03/2011, at 6:08 AM, Mikael Abrahamsson wrote: > >> On Sat, 19 Mar 2011, Routing Analysis Role Account wrote: >> >>> Number of 32-bit ASNs allocated by the RIRs: 1207 >>> Prefixes from 32-bit ASNs in the Routing Table: 1 >> >> Is the report not getting the routes from the real 32bit ASNs or is the above figures really accurate? > > Its probably not getting the routes - I see 915 AS's in the routing table using 32 bit AS numbers (http://www.potaroo.net/tools/asn32/) > > Geoff In RIS we saw 918 32 bit ASNs advertising about 2200 prefixes on 2011-03-19. Robert From nick at foobar.org Mon Mar 21 05:09:34 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 21 Mar 2011 10:09:34 +0000 Subject: CSI New York fake IPv6 In-Reply-To: References: <55275.1300660162@localhost> Message-ID: <4D8723DE.30401@foobar.org> On 21/03/2011 06:04, Martin Millnert wrote: > I assume it has been discussed and rejected. Can anyone enlighten us on why? RFC 3849? Nick From dot at dotat.at Mon Mar 21 06:36:00 2011 From: dot at dotat.at (Tony Finch) Date: Mon, 21 Mar 2011 11:36:00 +0000 Subject: CSI New York fake IPv6 In-Reply-To: References: <55275.1300660162@localhost> Message-ID: Patrick W. Gilmore wrote: > > But I'm surprised 1918 space was used as well. 172.12.0.0 is not RFC 1918 but it is unallocated. Tony. -- f.anthony.n.finch http://dotat.at/ Viking: Southwesterly 5 to 7, occasionally gale 8 in northwest Viking, veering westerly 5 or 6 later. Moderate or rough, occasionally very rough in north. Occasional rain and drizzle. Moderate, occasionally poor. From gbonser at seven.com Mon Mar 21 10:49:44 2011 From: gbonser at seven.com (George Bonser) Date: Mon, 21 Mar 2011 08:49:44 -0700 Subject: CSI New York fake IPv6 In-Reply-To: <20110321092533.GA23251@fnord.no> References: <55275.1300660162@localhost> <20110321092533.GA23251@fnord.no> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E28CA@RWC-EX1.corp.seven.com> > > I would have used 192.0.2.0/24. It is the IPv4 version of example.com. > > -- > Ina Or even anything in 127.55.0.0 should be safe. From fred at cisco.com Mon Mar 21 11:22:59 2011 From: fred at cisco.com (Fred Baker) Date: Mon, 21 Mar 2011 09:22:59 -0700 Subject: CSI New York fake IPv6 In-Reply-To: References: <55275.1300660162@localhost> Message-ID: <8DFB0937-4459-44DF-9AEE-77F8DF4EFA6A@cisco.com> On Mar 20, 2011, at 11:04 PM, Martin Millnert wrote: > one would almost expect there'd be "555"-equivalent > address spaces defined by the IETF already. In IPv6, I would expect the documentation example (2001:db8::/32) would suffice for the purpose. From rusty_conover at me.com Mon Mar 21 12:11:54 2011 From: rusty_conover at me.com (Rusty Conover) Date: Mon, 21 Mar 2011 13:11:54 -0400 Subject: RCN / NYIIX / Tiscali latency to West Coast Message-ID: <8ED784CC-B925-4CF2-9D16-87FEB13505C5@me.com> Hi Guys, I've been seeing latency from RCN via NYIIX to Tiscali to the west coast. It seemed to have changed just last week, any known issues with RCN or Tiscali? Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 10.0.1.1 0.0% 719 4.1 1.4 0.8 21.8 1.9 2. bdl1.80w-ubr2.nyr-80w.ny.cable.rcn.net 0.0% 719 9.4 10.3 6.7 33.3 3.6 3. vl4.aggr1.nyw.ny.rcn.net 0.1% 719 11.9 18.6 7.3 225.9 32.1 4. port-chan2.border1.nyw.ny.rcn.net 0.0% 719 8.8 19.6 7.4 209.6 32.2 5. nyiix.ip.tiscali.net 7.2% 718 125.6 127.6 99.1 191.8 12.2 6. xe-4-2-0.lax20.ip4.tinet.net 6.7% 718 210.4 213.5 187.2 308.1 12.2 7. 360networks-gw.ip4.tinet.net 5.0% 718 217.2 221.2 196.2 291.4 9.2 8. 66.62.2.217 3.9% 718 221.8 220.7 195.9 256.3 7.6 9. 66.62.2.166 5.3% 718 207.3 209.1 186.7 246.0 6.4 10. 66.62.2.174 7.0% 718 225.4 225.3 201.5 253.5 6.6 11. 66.62.2.5 5.0% 718 237.6 240.9 216.3 273.4 6.7 12. 66.62.2.21 5.6% 718 231.3 236.8 212.6 277.8 7.0 13. 66.62.2.42 9.5% 718 236.9 241.5 217.2 308.6 7.2 14. 66.62.192.42 6.1% 718 240.7 251.7 218.6 453.5 27.8 15. ge-1-0-0-0-blngmt-fh.core.ip.transaria.net 5.7% 718 243.5 244.5 220.3 335.4 11.7 Cheers, Rusty From sfouant at shortestpathfirst.net Mon Mar 21 12:19:50 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Mon, 21 Mar 2011 13:19:50 -0400 Subject: ICANN approves .XXX red-light district for the Internet Message-ID: <004a01cbe7ec$338874b0$9a995e10$@net> Surprised this was actually approved, but more so that this story seems to have gone unnoticed on the list... I would have expected a lot more chatter here - http://arstechnica.com/tech-policy/news/2011/03/icann-approves-xxx-red-light -district-for-the-internet.ars So the days of pointless TLDs are amongst us as we've now given would-be registrars the right to print money and companies are forced to purchase useless domain names in order to protect their trademarks, prevent squatting, etc. When will sanity prevail? Stefan Fouant From joelja at bogus.com Mon Mar 21 12:27:00 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 21 Mar 2011 10:27:00 -0700 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <004a01cbe7ec$338874b0$9a995e10$@net> References: <004a01cbe7ec$338874b0$9a995e10$@net> Message-ID: <4D878A64.8020903@bogus.com> On 3/21/11 10:19 AM, Stefan Fouant wrote: > Surprised this was actually approved, but more so that this story seems to > have gone unnoticed on the list... I would have expected a lot more chatter > here - > > http://arstechnica.com/tech-policy/news/2011/03/icann-approves-xxx-red-light > -district-for-the-internet.ars > > So the days of pointless TLDs are amongst us as we've now given would-be > registrars the right to print money and companies are forced to purchase > useless domain names in order to protect their trademarks, prevent > squatting, etc. When will sanity prevail? .biz/.info was 2001 > Stefan Fouant > > > From cconn at b2b2c.ca Mon Mar 21 15:18:00 2011 From: cconn at b2b2c.ca (Chris Conn) Date: Mon, 21 Mar 2011 16:18:00 -0400 Subject: SORBS contact? Message-ID: <4D87B278.8060204@b2b2c.ca> Hello, We have opened a number of tickets in the SORBS DUHL system to notify them of the use of a former dialup /24 for static assignments to no avail. Anyone from SORBS reading this? Thank you, Chris Conn B2B2C.ca From tshaw at oitc.com Mon Mar 21 15:31:21 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 21 Mar 2011 16:31:21 -0400 Subject: SORBS contact? In-Reply-To: <4D87B278.8060204@b2b2c.ca> References: <4D87B278.8060204@b2b2c.ca> Message-ID: On Mar 21, 2011, at 4:18 PM, Chris Conn wrote: > Hello, > > We have opened a number of tickets in the SORBS DUHL system to notify them of the use of a former dialup /24 for static assignments to no avail. Anyone from SORBS reading this? > > Thank you, > > Chris Conn > B2B2C.ca > One might wonder about the quality of the mail admins that rely on SORBS.... You might try http://www.au.sorbs.net/cgi-bin/support Tom From ken at heavycomputing.ca Mon Mar 21 18:58:16 2011 From: ken at heavycomputing.ca (Ken Chase) Date: Mon, 21 Mar 2011 19:58:16 -0400 Subject: SORBS contact? In-Reply-To: References: <4D87B278.8060204@b2b2c.ca> Message-ID: <20110321235816.GO25491@sizone.org> On Mon, Mar 21, 2011 at 04:31:21PM -0400, TR Shaw said: >One might wonder about the quality of the mail admins that rely on SORBS.... > >You might try http://www.au.sorbs.net/cgi-bin/support > One might also do other things that are to no avail, one of such things is to read this and realise nothing can be done: http://seclists.org/nanog/2010/Jan/393 good luck! /kc -- Ken Chase - ken at heavycomputing.ca skype:kenchase23 +1 416 897 6284 Toronto Canada Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From livio.zanol.puppim at gmail.com Mon Mar 21 19:36:20 2011 From: livio.zanol.puppim at gmail.com (Livio Zanol Puppim) Date: Mon, 21 Mar 2011 21:36:20 -0300 Subject: DWDM Metro Access Design Message-ID: Hello, I don't know if this is the appropriate list for this kind of subject, so if anyone knows another specific list, please tell me... I'm analysing several DWDM designs to implement at my city, but I'm still a bit confusing about the Metro acess design. I'm supposed to build a physical ring topology with 6 pairs of fiber with an hub-and-spoke logical topology. The ring will have about 40Km. At the HUB we'll install our point-of-presence with a MPLS equipment, and at the spokes we'll use only IP routers. We need an flexible design where we can add or remove spokes as needed with the minimum effort possible. We are planning to have, at a initial deployment, about 200 hundred spokes, and all these spokes are talking only with the HUB site. Everything should work like in an FTTH or FTTB design, no other type of transportation is allowed (wireless and copper). We can't use SONET/SDH. The solution must be only IPoDWDM or complemented with TDMoIP at the access equipment. The problem, is that all documents that I'm reading specifies that we should be worried with faults scenarios at the spokes, so that the optical network does not stops. For example, if the OADM equipment at the spoke is down, the lambda dropped at that site will be down too... Or at least, if we use a lot of lambdas, we need to keep and eye at the points where we have regenerators. We need bandwidth from 10Mbps to 1000Mbps at these spokes. My question is: Is it possible to make such a network in a way that we don't need to worry about faults (electrical or others) at the spokes? If so, how can I do this? I don't want the spokes sites interfering directly at the operation for the whole network. Thanks for your help. -- []'s L?vio Zanol Puppim From mksmith at adhost.com Mon Mar 21 20:01:50 2011 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Tue, 22 Mar 2011 01:01:50 +0000 Subject: DWDM Metro Access Design In-Reply-To: Message-ID: On 3/21/11 5:36 PM, "Livio Zanol Puppim" wrote: >Hello, > >I don't know if this is the appropriate list for this kind of subject, so >if >anyone knows another specific list, please tell me... > >I'm analysing several DWDM designs to implement at my city, but I'm still >a >bit confusing about the Metro acess design. I'm supposed to build a >physical >ring topology with 6 pairs of fiber with an hub-and-spoke logical >topology. >The ring will have about 40Km. At the HUB we'll install our >point-of-presence with a MPLS equipment, and at the spokes we'll use only >IP >routers. We need an flexible design where we can add or remove spokes as >needed with the minimum effort possible. We are planning to have, at a >initial deployment, about 200 hundred spokes, and all these spokes are >talking only with the HUB site. Everything should work like in an FTTH or >FTTB design, no other type of transportation is allowed (wireless and >copper). > >We can't use SONET/SDH. The solution must be only IPoDWDM or complemented >with TDMoIP at the access equipment. > >The problem, is that all documents that I'm reading specifies that we >should >be worried with faults scenarios at the spokes, so that the optical >network >does not stops. For example, if the OADM equipment at the spoke is down, >the >lambda dropped at that site will be down too... Or at least, if we use a >lot >of lambdas, we need to keep and eye at the points where we have >regenerators. > >We need bandwidth from 10Mbps to 1000Mbps at these spokes. > >My question is: >Is it possible to make such a network in a way that we don't need to worry >about faults (electrical or others) at the spokes? If so, how can I do >this? > >I don't want the spokes sites interfering directly at the operation for >the >whole network. > >Thanks for your help. Hello Livio: At some point you will have a single point of failure, it's just a matter of where. If you are running a single-threaded lambda or set of them into a spoke site, that node will go down should your transport gear fail. If you want your add-drop sites to be redundant through the network layer you will have to feed each spoke site from the East and West side of your ring on separate add-drop gear. That will be expensive. If price is no object, you can do that and then use your upper layer protocols to determine path availability. Or, you can build your add drop site with a single device and built-in redundancy (controller cards, power supplies, etc.) to keep the cost down. Long story short, if you need those sites to stay up regardless of anything else, you have to build two of everything at each site. It can certainly be done and many a vendor would like to talk to you about solutions I'm sure! :-) Mike -- Michael K. Smith - CISSP, GSEC, GISP Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com w: +1 (206) 404-9500 f: +1 (206) 404-9050 PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) From livio.zanol.puppim at gmail.com Mon Mar 21 20:11:21 2011 From: livio.zanol.puppim at gmail.com (Livio Zanol Puppim) Date: Mon, 21 Mar 2011 22:11:21 -0300 Subject: DWDM Metro Access Design In-Reply-To: References: Message-ID: I don't rally care about the uptime at the spokes. It's not my responsability to maintain the spokes sites, we'll just give communication to our network. I know that I'll have single point of failure in my topology, like having just one HUB, but I just don't want a spoke interfering in the opeartion of my network. Ex.: I don't want a eletrical failure at one spoke interfering in the operation of other spokes... Thanks for your reply. :) 2011/3/21 Michael K. Smith - Adhost > > On 3/21/11 5:36 PM, "Livio Zanol Puppim" > wrote: > > >Hello, > > > >I don't know if this is the appropriate list for this kind of subject, so > >if > >anyone knows another specific list, please tell me... > > > >I'm analysing several DWDM designs to implement at my city, but I'm still > >a > >bit confusing about the Metro acess design. I'm supposed to build a > >physical > >ring topology with 6 pairs of fiber with an hub-and-spoke logical > >topology. > >The ring will have about 40Km. At the HUB we'll install our > >point-of-presence with a MPLS equipment, and at the spokes we'll use only > >IP > >routers. We need an flexible design where we can add or remove spokes as > >needed with the minimum effort possible. We are planning to have, at a > >initial deployment, about 200 hundred spokes, and all these spokes are > >talking only with the HUB site. Everything should work like in an FTTH or > >FTTB design, no other type of transportation is allowed (wireless and > >copper). > > > >We can't use SONET/SDH. The solution must be only IPoDWDM or complemented > >with TDMoIP at the access equipment. > > > >The problem, is that all documents that I'm reading specifies that we > >should > >be worried with faults scenarios at the spokes, so that the optical > >network > >does not stops. For example, if the OADM equipment at the spoke is down, > >the > >lambda dropped at that site will be down too... Or at least, if we use a > >lot > >of lambdas, we need to keep and eye at the points where we have > >regenerators. > > > >We need bandwidth from 10Mbps to 1000Mbps at these spokes. > > > >My question is: > >Is it possible to make such a network in a way that we don't need to worry > >about faults (electrical or others) at the spokes? If so, how can I do > >this? > > > >I don't want the spokes sites interfering directly at the operation for > >the > >whole network. > > > >Thanks for your help. > > > Hello Livio: > > At some point you will have a single point of failure, it's just a matter > of where. If you are running a single-threaded lambda or set of them into > a spoke site, that node will go down should your transport gear fail. If > you want your add-drop sites to be redundant through the network layer you > will have to feed each spoke site from the East and West side of your ring > on separate add-drop gear. > > That will be expensive. If price is no object, you can do that and then > use your upper layer protocols to determine path availability. Or, you > can build your add drop site with a single device and built-in redundancy > (controller cards, power supplies, etc.) to keep the cost down. > > Long story short, if you need those sites to stay up regardless of > anything else, you have to build two of everything at each site. It can > certainly be done and many a vendor would like to talk to you about > solutions I'm sure! :-) > > Mike > -- > Michael K. Smith - CISSP, GSEC, GISP > Chief Technical Officer - Adhost Internet LLC mksmith at adhost.com > w: +1 (206) 404-9500 f: +1 (206) 404-9050 > PGP: B49A DDF5 8611 27F3 08B9 84BB E61E 38C0 (Key ID: 0x9A96777D) > > > > > > > > -- []'s L?vio Zanol Puppim From a.harrowell at gmail.com Tue Mar 22 05:19:33 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Tue, 22 Mar 2011 10:19:33 +0000 Subject: DWDM Metro Access Design In-Reply-To: References: Message-ID: <201103221019.45243.a.harrowell@gmail.com> What's the constraint that rules out using SONET or something similar, which is designed to give you a robust ring topology? I think it's probably quite important to know whether that's really, absolutely out of the question, or whether it's a possibility to relax that in favour of a less painful higher layer solution. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From streiner at cluebyfour.org Tue Mar 22 04:31:40 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Tue, 22 Mar 2011 05:31:40 -0400 (EDT) Subject: CSI New York fake IPv6 In-Reply-To: References: Message-ID: On Mon, 21 Mar 2011, Skeeve Stevens wrote: > I just thought this is amusing that in CSI: New York ? Season 7, > Episode 17, they do a 'Remote Desktop' hack and they enter in the > following details? > > http://www.eintellego.net/public/CSINY.s07e17-fakev6.jpg > > Promoting IPv6 = Win! > Dodgy Address = Fail! This reminds me of the end of the 1995 movie "The Net" where Sandra Bullock captures criminals with an enhanced version of traceroute (or an enhanced version of the Intertubes) that showed some very dodgy IP addresses, and an enhanced version of whois that shows you a picture of the person using a particular IP address. Apparently that whois client was also licensed to "Law and Order" at some point :) jms From Don.DuQuette at fngp.com Tue Mar 22 12:44:17 2011 From: Don.DuQuette at fngp.com (Don.DuQuette at fngp.com) Date: Tue, 22 Mar 2011 12:44:17 -0500 Subject: ATT Maro Message-ID: Does anyone have information regarding the AT&T MARO product for redundancy? What technology are they using? Is it simply being done via BGP? Any information would be greatly appreciated Don DuQuette From cconn at b2b2c.ca Tue Mar 22 14:07:29 2011 From: cconn at b2b2c.ca (Chris Conn) Date: Tue, 22 Mar 2011 15:07:29 -0400 Subject: SORBS contact? Message-ID: <4D88F371.1000902@b2b2c.ca> Hello, Thank you to all that answered, all helpful info. Surprisingly minutes after my Nanog post, a couple of my tickets saw action and the /24 was finally removed a short while later. Thanks again, Chris From paul at paulgraydon.co.uk Tue Mar 22 14:14:57 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 22 Mar 2011 09:14:57 -1000 Subject: SORBS contact? In-Reply-To: <4D88F371.1000902@b2b2c.ca> References: <4D88F371.1000902@b2b2c.ca> Message-ID: <4D88F531.4030605@paulgraydon.co.uk> On 03/22/2011 09:07 AM, Chris Conn wrote: > Hello, > > Thank you to all that answered, all helpful info. Surprisingly > minutes after my Nanog post, a couple of my tickets saw action and the > /24 was finally removed a short while later. > > Thanks again, > > Chris > Woah... *collapses on the floor in shock* SORBS actually did something?! Quick, buy a lottery ticket before your luck changes! Paul (one of many fed up of dealing with SORBS) From mike-nanog at tiedyenetworks.com Tue Mar 22 14:21:56 2011 From: mike-nanog at tiedyenetworks.com (Mike) Date: Tue, 22 Mar 2011 12:21:56 -0700 Subject: SORBS contact? In-Reply-To: <4D88F531.4030605@paulgraydon.co.uk> References: <4D88F371.1000902@b2b2c.ca> <4D88F531.4030605@paulgraydon.co.uk> Message-ID: <4D88F6D4.5070901@tiedyenetworks.com> On 03/22/2011 12:14 PM, Paul Graydon wrote: > On 03/22/2011 09:07 AM, Chris Conn wrote: >> Hello, >> >> Thank you to all that answered, all helpful info. Surprisingly minutes >> after my Nanog post, a couple of my tickets saw action and the /24 was >> finally removed a short while later. >> >> Thanks again, >> >> Chris >> > Woah... *collapses on the floor in shock* SORBS actually did something?! > Quick, buy a lottery ticket before your luck changes! > > Paul > (one of many fed up of dealing with SORBS) Yeah +1 to that. What we need an RBL that lists any mail server that USES sorbs for filtering decisions. Mike- From steve at blighty.com Tue Mar 22 16:56:20 2011 From: steve at blighty.com (Steve Atkins) Date: Tue, 22 Mar 2011 14:56:20 -0700 Subject: SORBS contact? In-Reply-To: <4D88F6D4.5070901@tiedyenetworks.com> References: <4D88F371.1000902@b2b2c.ca> <4D88F531.4030605@paulgraydon.co.uk> <4D88F6D4.5070901@tiedyenetworks.com> Message-ID: <1DC945F7-3469-44A3-89CA-293E82A35252@blighty.com> On Mar 22, 2011, at 12:21 PM, Mike wrote: > On 03/22/2011 12:14 PM, Paul Graydon wrote: >> On 03/22/2011 09:07 AM, Chris Conn wrote: >>> Hello, >>> >>> Thank you to all that answered, all helpful info. Surprisingly minutes >>> after my Nanog post, a couple of my tickets saw action and the /24 was >>> finally removed a short while later. >>> >>> Thanks again, >>> >>> Chris >>> >> Woah... *collapses on the floor in shock* SORBS actually did something?! >> Quick, buy a lottery ticket before your luck changes! >> >> Paul >> (one of many fed up of dealing with SORBS) > > > Yeah +1 to that. What we need an RBL that lists any mail server that USES sorbs for filtering decisions. Cut GFI a little slack, at least for a few more weeks. They seem to have made some decent decisions w.r.t. SORBS very recently and it's likely that things will be improving, at least as far as SORBS policies and support responsiveness are concerned. They may yet screw it up, but give them a chance to demonstrate otherwise. Cheers, Steve From sven at cb3rob.net Tue Mar 22 17:05:11 2011 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 22 Mar 2011 22:05:11 +0000 (UTC) Subject: SBL99576 195.191.102.0/24 SR04 Message-ID: <201103222224.p2MMO3BP072604@smtp-vbr7.xs4all.nl> BL99576 195.191.102.0/24 SR04 SBL100272 195.191.102.0/23 SR02 > IDEAR4BUSINESS (trademark fraud replicas spammers) > Trademark fraud replicas & knock-offs advertised in spam. (was SBL99180, > also SBL99576) - trademarks are not valid in china - chinese law applies to the customer's services - no evidence of fraud - no evidence of spamming (also, judistiction thingy). "Partners of "AS34109/AS51787 (CB3ROB)" - not a partner, a downstream transit customer, that just so happens to be on AS34109 for now as they lack their own (for now ;) - the /23 seems to overlap with the /24... there may be 2 reasons for this 1: the customer seems to have added 2 /24 "delegations' on his -PI- space in the RIPE database, which, isn't supposed to be possible with PI space anyway, nontheless, that happened ;) 2: they are indeed announced as 2 seperate /24's most of the time (incoming ddos attack "migitation") -IF- spamming -really- would be going on, from these ranges or to these ranges, you are ofcourse free to list those, and only those: 195.191.102.0/23 IDEAR4BUSINESS 84.22.98.8/29 Media Entertainment Guide 84.22.98.16/29 Media Entertainment Guide 84.22.98.24/29 Media Entertainment Guide and whatever is behind AS56512 (no idea, several prefixes on several ASNs)) these are the only listings for which spamhaus seems to have -any- reason whatsoever, despite that for these listings as well, all the evidence is lacking and there are merely a few unbased claims and some whois outputs to "support" them. (and usually they even got the whois/prefix lenght wrong, or added it to the wrong company's "case"... ;) All of the above listings are ISPs themselves, and usually don't have anything to do with the hosted content. as for the AS56512 thingy, no idea what your problem is with them, its not like we can make it up from your listings besides you calling everyone 'spammers' and 'frauders' and replica rolex sellers or partners thereof (including us!), none of which is supplied with any evidence, police reports, or court convictions. Now, its really quite easy, we WILL NOT DISCONNECT any customers just because spamhaus tries to blackmail us into doing so by adding: SBL105802 205.189.71.0/24 (PCCF, a company in which the cyberbunker-group holds the majority of shares) SBL105804 205.189.72.0/23 (PCCF, a company in which the cyberbunker-group holds the majority of shares) SBL105803 91.209.12.0/24 ZYZTM research #10 B.V. (part of the cyberbunker-group) These ranges are used solely for research and development of new internet protocols. (including one to replace that dusty old spam-infested smtp crap of yours ;) SBL99505 84.22.96.0/19 (entire PA space of ours) SBL105813 84.22.96.0/32 (?) SBL105806 84.22.96.0/32 (?) No idea why you'd list the entire PA space while all customers are clearly marked in whois, it's PA space, you're SUPPOSED to delegate it to different customers, after which, its up to the customers. well, except for that you clearly are trying to blackmail us into disconnecting customers without getting a court order or even providing evidence of any of your claims. if blacklisting won't work if you do it for the actual prefix that's "causing" it (according to your claims) it also won't work for larger prefixes or completely non-related prefixes, therefore, thats nothing more or less than just blackmail, and very childish. let's just say that port 25/tcp traffic is mainly incoming... ;) except for the occasional invoice going out... spamhaus is ofcourse absolutely free to list spammers, spamhaus is not free to "make things up" and blackmail carriers and calling third parties 'criminals' and what not. as a european provider, we have no liability whatsoever for what customers do or do not do, all or most of our customers are ISPs themselves, go bug them... if they don't do what you want, they probably have their reasons for it (really i don't see why we even reply to third parties like spamhaus either ;) wherever the customers have their office, there probably are courts, should you think the customer is breaking the law, feel free to have some attorneys or the cops do something about it, but the moment you start to claim things without any evidence, spamhaus is clearly in the wrong. any carriers/peers that could potentially drop prefixes due to spamhaus listings are well advised to review their terms and conditions and contracts as i'm quite sure it doesn't mention "spamhaus listing" in there as a "reason" to filter prefixes anywhere... therefore, if you're a paid transit, and receive prefixes, you're gonna have to relay them, with or without spamhaus listings. spamhaus is no authority whatsoever, and clearly, for very valid reasons. i'm not "for spamming" but frankly, i no longer give a shit about that rusty old protocol without a friends list, as far as i'm concerned, it's dead and replaced by skype ages ago. we expect this matter to be resolved. until that time, we advise everyone not to resolve spamhaus'es blocklists, as clearly, 99% of it, is just there to attempt to blackmail. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. & Co. KG ========================================================================= Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration: HRA 42834 B BERLIN Phone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE: CBSK1-RIPE e-Mail: sven at cb3rob.net ========================================================================= C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob ========================================================================= Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. From franck at genius.com Tue Mar 22 17:24:29 2011 From: franck at genius.com (Franck Martin) Date: Wed, 23 Mar 2011 10:24:29 +1200 (MHT) Subject: SORBS contact? In-Reply-To: <1DC945F7-3469-44A3-89CA-293E82A35252@blighty.com> Message-ID: <17127599.1067.1300832667980.JavaMail.franck@Macintosh-3.local> +1 They know the challenges, aware of the issues and I have seen some progress. ----- Original Message ----- From: "Steve Atkins" To: nanog at nanog.org Sent: Wednesday, 23 March, 2011 9:56:20 AM Subject: Re: SORBS contact? On Mar 22, 2011, at 12:21 PM, Mike wrote: > On 03/22/2011 12:14 PM, Paul Graydon wrote: >> On 03/22/2011 09:07 AM, Chris Conn wrote: >>> Hello, >>> >>> Thank you to all that answered, all helpful info. Surprisingly minutes >>> after my Nanog post, a couple of my tickets saw action and the /24 was >>> finally removed a short while later. >>> >>> Thanks again, >>> >>> Chris >>> >> Woah... *collapses on the floor in shock* SORBS actually did something?! >> Quick, buy a lottery ticket before your luck changes! >> >> Paul >> (one of many fed up of dealing with SORBS) > > > Yeah +1 to that. What we need an RBL that lists any mail server that USES sorbs for filtering decisions. Cut GFI a little slack, at least for a few more weeks. They seem to have made some decent decisions w.r.t. SORBS very recently and it's likely that things will be improving, at least as far as SORBS policies and support responsiveness are concerned. They may yet screw it up, but give them a chance to demonstrate otherwise. Cheers, Steve From paul at paulgraydon.co.uk Tue Mar 22 17:58:46 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Tue, 22 Mar 2011 12:58:46 -1000 Subject: SORBS contact? In-Reply-To: <17127599.1067.1300832667980.JavaMail.franck@Macintosh-3.local> References: <17127599.1067.1300832667980.JavaMail.franck@Macintosh-3.local> Message-ID: <4D8929A6.6030802@paulgraydon.co.uk> On 03/22/2011 12:24 PM, Franck Martin wrote: > +1 > > They know the challenges, aware of the issues and I have seen some progress. I'm glad to hear that, one less extortion racket on the 'net is no bad thing. They might do better by rebranding though. SORBS has one heck of an amount of negative karma for them to get past. > ----- Original Message ----- > From: "Steve Atkins" > To: nanog at nanog.org > Sent: Wednesday, 23 March, 2011 9:56:20 AM > Subject: Re: SORBS contact? > > > On Mar 22, 2011, at 12:21 PM, Mike wrote: > >> On 03/22/2011 12:14 PM, Paul Graydon wrote: >>> On 03/22/2011 09:07 AM, Chris Conn wrote: >>>> Hello, >>>> >>>> Thank you to all that answered, all helpful info. Surprisingly minutes >>>> after my Nanog post, a couple of my tickets saw action and the /24 was >>>> finally removed a short while later. >>>> >>>> Thanks again, >>>> >>>> Chris >>>> >>> Woah... *collapses on the floor in shock* SORBS actually did something?! >>> Quick, buy a lottery ticket before your luck changes! >>> >>> Paul >>> (one of many fed up of dealing with SORBS) >> >> Yeah +1 to that. What we need an RBL that lists any mail server that USES sorbs for filtering decisions. > Cut GFI a little slack, at least for a few more weeks. > > They seem to have made some decent decisions w.r.t. SORBS very recently and it's likely that things will be improving, at least as far as SORBS policies and support responsiveness are concerned. > > They may yet screw it up, but give them a chance to demonstrate otherwise. > > Cheers, > Steve > > From Valdis.Kletnieks at vt.edu Tue Mar 22 17:59:44 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 22 Mar 2011 18:59:44 -0400 Subject: SBL99576 195.191.102.0/24 SR04 In-Reply-To: Your message of "Tue, 22 Mar 2011 22:05:11 -0000." <201103222224.p2MMO3BP072604@smtp-vbr7.xs4all.nl> References: <201103222224.p2MMO3BP072604@smtp-vbr7.xs4all.nl> Message-ID: <34770.1300834784@localhost> On Tue, 22 Mar 2011 22:05:11 -0000, Sven Olaf Kamphuis said: > > IDEAR4BUSINESS (trademark fraud replicas spammers) > > Trademark fraud replicas & knock-offs advertised in spam. (was SBL99180, > > also SBL99576) > > - trademarks are not valid in china > - chinese law applies to the customer's services Yes, but if said customer is advertising the product to US residents (or anyplace else that recognizes the trademark), the trademark issue (and other applicable US/whatever import laws) *does* become important. I'll let other fight about the rest of the content of the note. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From mike-nanog at tiedyenetworks.com Tue Mar 22 18:08:36 2011 From: mike-nanog at tiedyenetworks.com (Mike) Date: Tue, 22 Mar 2011 16:08:36 -0700 Subject: SORBS contact? In-Reply-To: <4D8929A6.6030802@paulgraydon.co.uk> References: <17127599.1067.1300832667980.JavaMail.franck@Macintosh-3.local> <4D8929A6.6030802@paulgraydon.co.uk> Message-ID: <4D892BF4.4@tiedyenetworks.com> On 03/22/2011 03:58 PM, Paul Graydon wrote: > On 03/22/2011 12:24 PM, Franck Martin wrote: >> +1 >> >> They know the challenges, aware of the issues and I have seen some >> progress. > > I'm glad to hear that, one less extortion racket on the 'net is no bad > thing. They might do better by rebranding though. SORBS has one heck of > an amount of negative karma for them to get past. > Competently managed and with even a modicum of responsiveness, SORBS could be redeemed. But yeah, they should get a new name, SORBS is tainted in my book. From jbfixurpc at gmail.com Tue Mar 22 18:14:02 2011 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Tue, 22 Mar 2011 18:14:02 -0500 Subject: OT: Question/Netflix issues? Message-ID: Greetings, I know this is way off topic, but is anyone else getting calls/tickets about Netflix access problems? I tried (sucessfully) to duplicate the issues, seems like extremely slow responses from the servers I have tested, as well seems the web servers are also either overloaded or just dropping packets. Just wondering if anyone else is seeing the same. Kind Regards, -Joe Blanchard From tshaw at oitc.com Tue Mar 22 18:16:28 2011 From: tshaw at oitc.com (TR Shaw) Date: Tue, 22 Mar 2011 19:16:28 -0400 Subject: SORBS contact? In-Reply-To: <4D892BF4.4@tiedyenetworks.com> References: <17127599.1067.1300832667980.JavaMail.franck@Macintosh-3.local> <4D8929A6.6030802@paulgraydon.co.uk> <4D892BF4.4@tiedyenetworks.com> Message-ID: <93226FD1-615B-4D63-B94F-575A4CF57BE9@oitc.com> On Mar 22, 2011, at 7:08 PM, Mike wrote: > On 03/22/2011 03:58 PM, Paul Graydon wrote: >> On 03/22/2011 12:24 PM, Franck Martin wrote: >>> +1 >>> >>> They know the challenges, aware of the issues and I have seen some >>> progress. >> >> I'm glad to hear that, one less extortion racket on the 'net is no bad >> thing. They might do better by rebranding though. SORBS has one heck of >> an amount of negative karma for them to get past. >> > > Competently managed and with even a modicum of responsiveness, SORBS could be redeemed. But yeah, they should get a new name, SORBS is tainted in my book. SORBS is tainted worldwide. You should hear the the laughing and negative comments about them at MAAWG and at other conferences let alone all the users that dumped them and all the legit ISPs that they held for ransom. If they have gotten rid of Michelle and have gotten new management and gotten a new attitude they should run that up the flag pole so that everyone will know. And, I agree they need to rebrand if they are really dedicated to a change in operations. Then, they face the long term to get back their reputation. From rsk at gsp.org Tue Mar 22 18:25:51 2011 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 22 Mar 2011 19:25:51 -0400 Subject: SORBS contact? In-Reply-To: <4D87B278.8060204@b2b2c.ca> References: <4D87B278.8060204@b2b2c.ca> Message-ID: <20110322232551.GA29375@gsp.org> For future reference: you're much more likely to elicit a useful response by using the "mailop" list, since you'll be addressing a mixed audience of mail system operators, DNSBL operators, software authors, etc., all of whom are focused on mail and not network operations. ---rsk From ios.run at gmail.com Tue Mar 22 18:49:12 2011 From: ios.run at gmail.com (Raul Rodriguez) Date: Tue, 22 Mar 2011 16:49:12 -0700 Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: What does the AS path look like from them to you? -RR On 3/22/11, Joe Blanchard wrote: > Greetings, > > I know this is way off topic, but is anyone else getting calls/tickets > about Netflix access problems? > > I tried (sucessfully) to duplicate the issues, seems like extremely slow > responses from the servers I have tested, as well seems the web servers > are also either overloaded or just dropping packets. Just wondering if > anyone else is seeing the same. > > Kind Regards, > -Joe Blanchard > -- Sent from my mobile device From pmi at bluegrass.net Tue Mar 22 19:04:10 2011 From: pmi at bluegrass.net (Paul M. Impellizzeri) Date: Tue, 22 Mar 2011 20:04:10 -0400 Subject: OT: Question/Netflix issues? In-Reply-To: Message-ID: We?re sorry, the Netflix website and the ability to instantly watch movies are both temporarily unavailable.However, our shipping centers are continuing to send and receive DVDs so your order is in process as usual. Our engineers are working hard to bring the site and ability to watch instantly back up as soon as possible. We appreciate your patience and, again, we apologize for any inconvenience this may cause. If you need further assistance, please call us at 1-877-445-6064. On 3/22/11 6:49 PM, "Raul Rodriguez" wrote: >What does the AS path look like from them to you? > >-RR > >On 3/22/11, Joe Blanchard wrote: >> Greetings, >> >> I know this is way off topic, but is anyone else getting calls/tickets >> about Netflix access problems? >> >> I tried (sucessfully) to duplicate the issues, seems like extremely slow >> responses from the servers I have tested, as well seems the web servers >> are also either overloaded or just dropping packets. Just wondering if >> anyone else is seeing the same. >> >> Kind Regards, >> -Joe Blanchard >> > >-- >Sent from my mobile device > From jbfixurpc at gmail.com Tue Mar 22 19:07:29 2011 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Tue, 22 Mar 2011 19:07:29 -0500 Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: Thanks Paul, I keep getting busy signals trying to reach them after the Sales office and directly. Just needed to know it wasn't something on our side. Thanks all for the feed back. -Joe Blanchard On Tue, Mar 22, 2011 at 7:04 PM, Paul M. Impellizzeri wrote: > > > > We?re sorry, the Netflix website and the ability to instantly watch > movies are both temporarily unavailable.However, our shipping centers > are continuing to send and receive DVDs so your order is in > process as usual. > Our engineers are working hard to bring the site and ability to watch > instantly back up as soon > as possible. We appreciate your patience and, again, we apologize for > any inconvenience this may > cause. If you need further assistance, please call us at 1-877-445-6064. > > > > > > On 3/22/11 6:49 PM, "Raul Rodriguez" wrote: > > >What does the AS path look like from them to you? > > > >-RR > > > >On 3/22/11, Joe Blanchard wrote: > >> Greetings, > >> > >> I know this is way off topic, but is anyone else getting calls/tickets > >> about Netflix access problems? > >> > >> I tried (sucessfully) to duplicate the issues, seems like extremely slow > >> responses from the servers I have tested, as well seems the web servers > >> are also either overloaded or just dropping packets. Just wondering if > >> anyone else is seeing the same. > >> > >> Kind Regards, > >> -Joe Blanchard > >> > > > >-- > >Sent from my mobile device > > > > > -- -Joe Blanchard (262)496-1732 From calin at en.ro Tue Mar 22 19:07:58 2011 From: calin at en.ro (Calin Nemes) Date: Tue, 22 Mar 2011 17:07:58 -0700 Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: http://twitter.com/Netflixhelps/status/50326616840220672 On Mar 22, 2011 4:15 PM, "Joe Blanchard" wrote: > Greetings, > > I know this is way off topic, but is anyone else getting calls/tickets > about Netflix access problems? > > I tried (sucessfully) to duplicate the issues, seems like extremely slow > responses from the servers I have tested, as well seems the web servers > are also either overloaded or just dropping packets. Just wondering if > anyone else is seeing the same. > > Kind Regards, > -Joe Blanchard From goemon at anime.net Tue Mar 22 19:17:30 2011 From: goemon at anime.net (goemon at anime.net) Date: Tue, 22 Mar 2011 17:17:30 -0700 (PDT) Subject: SBL99576 195.191.102.0/24 SR04 In-Reply-To: <201103222224.p2MMO3BP072604@smtp-vbr7.xs4all.nl> References: <201103222224.p2MMO3BP072604@smtp-vbr7.xs4all.nl> Message-ID: On Tue, 22 Mar 2011, Sven Olaf Kamphuis wrote: > as a european provider, we have no liability whatsoever for what customers > do or do not do about the best reason i can think of for listing this block until the heat death of the universe. -Dan From MGauvin at dryden.ca Tue Mar 22 19:19:42 2011 From: MGauvin at dryden.ca (Mark Gauvin) Date: Tue, 22 Mar 2011 19:19:42 -0500 Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: <5ACB34A5-0307-4C9A-A79F-E406B4BF7287@dryden.ca> Netflix is currently down Sent from my iPhone On 2011-03-22, at 6:47 PM, "Raul Rodriguez" wrote: > What does the AS path look like from them to you? > > -RR > > On 3/22/11, Joe Blanchard wrote: >> Greetings, >> >> I know this is way off topic, but is anyone else getting calls/ >> tickets >> about Netflix access problems? >> >> I tried (sucessfully) to duplicate the issues, seems like extremely >> slow >> responses from the servers I have tested, as well seems the web >> servers >> are also either overloaded or just dropping packets. Just wondering >> if >> anyone else is seeing the same. >> >> Kind Regards, >> -Joe Blanchard >> > > -- > Sent from my mobile device > From mike at sentex.net Tue Mar 22 19:26:08 2011 From: mike at sentex.net (Mike Tancsa) Date: Tue, 22 Mar 2011 20:26:08 -0400 Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: <4D893E20.6010809@sentex.net> Where do you pick up their feeds from ? A lot of their content seems to come from CDNs like Akamai in my neighbourhood (in this case, Torix). That being said, I just tried to watch a movie and all I get is "Checking for device activation".... My browser seems to be blabbing back and forth with 208.75.79.32 on port 443 which I see 11647 6453 7922 2906. ---Mike On 3/22/2011 7:14 PM, Joe Blanchard wrote: > Greetings, > > I know this is way off topic, but is anyone else getting calls/tickets > about Netflix access problems? > > I tried (sucessfully) to duplicate the issues, seems like extremely slow > responses from the servers I have tested, as well seems the web servers > are also either overloaded or just dropping packets. Just wondering if > anyone else is seeing the same. > > Kind Regards, > -Joe Blanchard > > -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From robert at ufl.edu Tue Mar 22 19:32:19 2011 From: robert at ufl.edu (Scott, Robert D.) Date: Wed, 23 Mar 2011 00:32:19 +0000 Subject: Question/Netflix issues? In-Reply-To: References: Message-ID: <14384A642243C34495DE884D7E13C83EA32140@UFEXCH-MBXN02.ad.ufl.edu> Greetings, I know this is way off topic, but is anyone else getting calls/tickets about Netflix access problems? <<<<>>>> -Joe Blanchard Quite to the contrary Joe. It is actually a pleasure to read an operationally relevant thread on NANOG. If your customers are calling about accessibility issues then this is 200% relevant. The week long diatribe about why, who, what, when, and if Sun Spots caused it, after the fact, are not. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-273-0743 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell From robert at ufl.edu Tue Mar 22 19:40:14 2011 From: robert at ufl.edu (Scott, Robert D.) Date: Wed, 23 Mar 2011 00:40:14 +0000 Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: <14384A642243C34495DE884D7E13C83EA3217C@UFEXCH-MBXN02.ad.ufl.edu> What Paul missed was to credit this info. http://www.netflix.com/ Rather simple to go look. Robert D. Scott Robert at ufl.edu Senior Network Engineer 352-273-0113 Phone CNS - Network Services 352-392-2061 CNS Phone Tree University of Florida 352-273-0743 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell 3216630421 at messaging.sprintpcs.com -----Original Message----- From: Paul M. Impellizzeri [mailto:pmi at bluegrass.net] Sent: Tuesday, March 22, 2011 8:04 PM To: NANOG list Subject: Re: OT: Question/Netflix issues? We?re sorry, the Netflix website and the ability to instantly watch movies are both temporarily unavailable.However, our shipping centers are continuing to send and receive DVDs so your order is in process as usual. Our engineers are working hard to bring the site and ability to watch instantly back up as soon as possible. We appreciate your patience and, again, we apologize for any inconvenience this may cause. If you need further assistance, please call us at 1-877-445-6064. On 3/22/11 6:49 PM, "Raul Rodriguez" wrote: >What does the AS path look like from them to you? > >-RR > >On 3/22/11, Joe Blanchard wrote: >> Greetings, >> >> I know this is way off topic, but is anyone else getting >> calls/tickets about Netflix access problems? >> >> I tried (sucessfully) to duplicate the issues, seems like extremely >> slow responses from the servers I have tested, as well seems the web >> servers are also either overloaded or just dropping packets. Just >> wondering if anyone else is seeing the same. >> >> Kind Regards, >> -Joe Blanchard >> > >-- >Sent from my mobile device > From jeff-kell at utc.edu Tue Mar 22 19:47:13 2011 From: jeff-kell at utc.edu (Jeff Kell) Date: Tue, 22 Mar 2011 20:47:13 -0400 Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: <4D894311.5080704@utc.edu> Now getting "We?re sorry, the Netflix website and the ability to instantly watch movies are both temporarily unavailable." out of Charter. Campus getting same routed via 1239 209 2906. Jeff From john-nanog at johnpeach.com Tue Mar 22 20:10:53 2011 From: john-nanog at johnpeach.com (John Peach) Date: Tue, 22 Mar 2011 21:10:53 -0400 Subject: SBL99576 195.191.102.0/24 SR04 In-Reply-To: References: <201103222224.p2MMO3BP072604@smtp-vbr7.xs4all.nl> Message-ID: <20110322211053.1423bffe@milhouse> On Tue, 22 Mar 2011 17:17:30 -0700 (PDT) goemon at anime.net wrote: > On Tue, 22 Mar 2011, Sven Olaf Kamphuis wrote: > > as a european provider, we have no liability whatsoever for what customers > > do or do not do > > about the best reason i can think of for listing this block until the heat > death of the universe. I thought it was very kind of him to supply the address ranges which need blocking. > > -Dan > -- John From malayter at gmail.com Tue Mar 22 20:20:27 2011 From: malayter at gmail.com (Ryan Malayter) Date: Tue, 22 Mar 2011 18:20:27 -0700 (PDT) Subject: OT: Question/Netflix issues? In-Reply-To: <4D894311.5080704@utc.edu> References: <4D894311.5080704@utc.edu> Message-ID: <55b67f74-ea3d-4843-8c01-4278d2ee011d@e21g2000yqe.googlegroups.com> On Mar 22, 7:47?pm, Jeff Kell wrote: > Now getting "We re sorry, the Netflix website and the ability to > instantly watch movies are both temporarily unavailable." out of Charter. > > Campus getting same routed via 1239 209 2906. > > Jeff Guess that move to Amazon EC2 wasn't such a good idea. First reddit, now netflix. http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html I suppose there's a reason you can't get an SLA with any teeth from Amazon... From george.herbert at gmail.com Tue Mar 22 20:27:05 2011 From: george.herbert at gmail.com (George Herbert) Date: Tue, 22 Mar 2011 18:27:05 -0700 Subject: OT: Question/Netflix issues? In-Reply-To: <55b67f74-ea3d-4843-8c01-4278d2ee011d@e21g2000yqe.googlegroups.com> References: <4D894311.5080704@utc.edu> <55b67f74-ea3d-4843-8c01-4278d2ee011d@e21g2000yqe.googlegroups.com> Message-ID: On Tue, Mar 22, 2011 at 6:20 PM, Ryan Malayter wrote: > > > On Mar 22, 7:47?pm, Jeff Kell wrote: >> Now getting "We re sorry, the Netflix website and the ability to >> instantly watch movies are both temporarily unavailable." out of Charter. >> >> Campus getting same routed via 1239 209 2906. >> >> Jeff > > Guess that move to Amazon EC2 wasn't such a good idea. First reddit, > now netflix. > http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html > > I suppose there's a reason you can't get an SLA with any teeth from > Amazon... You're assuming that the outage was somehow related to the quality of hosting (virtual server, instance management, etc). In my experience with large website failures, some of mine and talking to others at conferences and elsewhere, I can't recall one where the servers HW performance / virtualization management were the root cause (and only one that was intrinsically hardware-based, which was a catastrophic storage failure and not server failure). Configuration management, inadequate testing of new software, systems management error, DBMS throughput capacity, emergent software / architecture failures are the usual culprits. -- -george william herbert george.herbert at gmail.com From lyndon at orthanc.ca Tue Mar 22 20:31:50 2011 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Tue, 22 Mar 2011 17:31:50 -0800 Subject: OT: Question/Netflix issues? In-Reply-To: <55b67f74-ea3d-4843-8c01-4278d2ee011d@e21g2000yqe.googlegroups.com> Message-ID: > Guess that move to Amazon EC2 wasn't such a good idea. First reddit, > now netflix. > http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html FWIW, at $DAYJOB we haven't been able to run out a pool of a couple of dozen EC2 instances for more than two weeks (since last June) without at least one of them going down. The same number of hardware servers we ran ourselves in Peer1 ran for a couple of years with no unplanned outages. Amortized over five years, Peer1 colo + hardware is also cheaper than the equivalent EC2 cost. Hey everyone! Join the cloud, and stand in the pissing rain. --lyndon From jbfixurpc at gmail.com Tue Mar 22 21:03:41 2011 From: jbfixurpc at gmail.com (Joe Blanchard) Date: Tue, 22 Mar 2011 21:03:41 -0500 Subject: OT: Question/Netflix issues? In-Reply-To: References: <4D894311.5080704@utc.edu> <55b67f74-ea3d-4843-8c01-4278d2ee011d@e21g2000yqe.googlegroups.com> Message-ID: Greetings, Just to be clear I am only looking for a scope of the issue I am seeing, its not a direct assumption of fault or mis-configuration, more so a sanity check if you will. Thanks much for all of the feed back, as I see it its not just me. Thanks again -Joe Blanchard On Tue, Mar 22, 2011 at 8:27 PM, George Herbert wrote: > On Tue, Mar 22, 2011 at 6:20 PM, Ryan Malayter wrote: > > > > > > On Mar 22, 7:47 pm, Jeff Kell wrote: > >> Now getting "We re sorry, the Netflix website and the ability to > >> instantly watch movies are both temporarily unavailable." out of > Charter. > >> > >> Campus getting same routed via 1239 209 2906. > >> > >> Jeff > > > > Guess that move to Amazon EC2 wasn't such a good idea. First reddit, > > now netflix. > > > http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html > > > > I suppose there's a reason you can't get an SLA with any teeth from > > Amazon... > > You're assuming that the outage was somehow related to the quality of > hosting (virtual server, instance management, etc). > > In my experience with large website failures, some of mine and talking > to others at conferences and elsewhere, I can't recall one where the > servers HW performance / virtualization management were the root cause > (and only one that was intrinsically hardware-based, which was a > catastrophic storage failure and not server failure). Configuration > management, inadequate testing of new software, systems management > error, DBMS throughput capacity, emergent software / architecture > failures are the usual culprits. > > > -- > -george william herbert > george.herbert at gmail.com > > -- -Joe Blanchard (262)496-1732 From marquis at roble.com Wed Mar 23 00:05:08 2011 From: marquis at roble.com (Roger Marquis) Date: Tue, 22 Mar 2011 22:05:08 -0700 (PDT) Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: A probable case of outsourcing core business functionality without a fully tested plan B... Roger Marquis > We?re sorry, the Netflix website and the ability to instantly watch movies > are both temporarily unavailable.However, our shipping centers are > continuing to send and receive DVDs so your order is in process as usual. > Our engineers are working hard to bring the site and ability to watch > instantly back up as soon as possible. We appreciate your patience and, > again, we apologize for any inconvenience this may cause. If you need > further assistance, please call us at 1-877-445-6064. From goemon at anime.net Wed Mar 23 00:57:07 2011 From: goemon at anime.net (goemon at anime.net) Date: Tue, 22 Mar 2011 22:57:07 -0700 (PDT) Subject: SBL99576 195.191.102.0/24 SR04 In-Reply-To: <20110322211053.1423bffe@milhouse> References: <201103222224.p2MMO3BP072604@smtp-vbr7.xs4all.nl> <20110322211053.1423bffe@milhouse> Message-ID: On Tue, 22 Mar 2011, John Peach wrote: > On Tue, 22 Mar 2011 17:17:30 -0700 (PDT) goemon at anime.net wrote: >> On Tue, 22 Mar 2011, Sven Olaf Kamphuis wrote: >>> as a european provider, we have no liability whatsoever for what customers >>> do or do not do >> about the best reason i can think of for listing this block until the heat >> death of the universe. > I thought it was very kind of him to supply the address ranges which > need blocking. He also shouldnt worry about RBLs since everyone will have hardcoded his address ranges into their routers and access lists. -Dan From outsider at scarynet.org Wed Mar 23 02:35:33 2011 From: outsider at scarynet.org (Alexander Maassen) Date: Wed, 23 Mar 2011 08:35:33 +0100 Subject: SORBS contact? In-Reply-To: <20110322232551.GA29375@gsp.org> References: <4D87B278.8060204@b2b2c.ca> <20110322232551.GA29375@gsp.org> Message-ID: <4D89A2C5.9040400@scarynet.org> mailop list? I run a dnsbl myself (dronebl to be exact), call me dumb or whatever, but never heard about that list. In fact, I am also working on granting AS admins to be able to list entries in their ranges etc, so if you are listed in whois as administrator of an AS and you want access to listings within your ranges, gimme a yell. Op 23-3-2011 0:25, Rich Kulawiec schreef: > For future reference: you're much more likely to elicit a useful > response by using the "mailop" list, since you'll be addressing > a mixed audience of mail system operators, DNSBL operators, software > authors, etc., all of whom are focused on mail and not network operations. > > ---rsk > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 552 bytes Desc: OpenPGP digital signature URL: From mdavids at forfun.net Wed Mar 23 06:58:19 2011 From: mdavids at forfun.net (Marco Davids (Prive)) Date: Wed, 23 Mar 2011 12:58:19 +0100 (CET) Subject: DNSSEC on the resolver-side? Message-ID: Hi, I wonder... How many people here have activated DNSSEC validation on their resolvers? Please let me know off-list when the page below results in a green tick: http://dnssectest.sidn.nl/ Additional details are welcome, like: - The IP-address of the resolver(s) you used (if you know) - Whether this is an 'official' resolver at an ISP or not - You current IP-address, or the ISP you are at (http://ip.sidn.nl might be helpful). Maybe some of you DNS-gurus are even able to tell why DNSSEC validation failed, even when using DNSSEC-enabled resolvers. For example because of some old-school DNS-forwarder in your ADSL modem or something. That would be great information also. The reason for this post is just for me to get a rough understanding of the level of DNSSEC adoption on the resolver-side and the problems that might still exist with DNSSEC validation. The NANOG wiki (http://nanog.cluepon.net) has nothing about DNSSEC yet. Would it be an idea to add something about DNSSEC? I am more than willing to do the kick-off for that. Regards, -- Marco From bhmccie at gmail.com Wed Mar 23 08:14:36 2011 From: bhmccie at gmail.com (Hammer) Date: Wed, 23 Mar 2011 08:14:36 -0500 Subject: Creating an IPv6 addressing plan for end users In-Reply-To: References: Message-ID: Nathalie, As an end customer (not a carrier) over in ARIN land I purchased a /48 about a year ago for our future IPv6 needs. We have 4 different Internet touchpoints (two per carrier) all rated at about 1Gbps. Recently, both carriers told us that the minimum advertisement they would accept PER CIRCUIT would be a /48. I was surprised to say the least. Basically a /48 would not be enough for us. The arguement was that this was to support all the summarization efforts and blah blah blah. Even though my space would be unique to either carrier. So now I'm contemplating a much larger block. Seems wasteful but I have to for the carriers. Have you heard of this elsewhere or is this maybe just an ARIN/American thing? Both carriers told me that in discussions with their peers that they were all doing this. -Hammer- "I was a normal American nerd." -Jack Herer On Wed, Mar 16, 2011 at 1:52 PM, Schiller, Heather A < heather.schiller at verizonbusiness.com> wrote: > > For those who don't like clicking on random bit.ly links: > > http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6 > _addr_plan4.pdf > > --Heather > > -----Original Message----- > From: Nathalie Trenaman [mailto:nathalie at ripe.net] > Sent: Wednesday, March 16, 2011 5:05 AM > To: nanog at nanog.org > Subject: Creating an IPv6 addressing plan for end users > > Hi all, > > In our IPv6 courses, we often get the question: I give my customers a > /48 (or a /56 or a /52) but they have no idea how to distribute that > space in their network. > In December Sander Steffann and Surfnet wrote a manual explaining > exactly that, in clear language with nice graphics. A very useful > document but it was in Dutch, so RIPE NCC decided to translate that > document to English. > > Yesterday, we have published that document on our website and we hope > this document is able to take away some of the fear that end users seem > to have for these huge blocks. > You can find this document here: > > http://bit.ly/IPv6addrplan (PDF) > > I look forward to your feedback, tips and comments. > > With kind regards, > > Nathalie Trenaman > RIPE NCC Trainer > > From bhmccie at gmail.com Wed Mar 23 08:26:40 2011 From: bhmccie at gmail.com (Hammer) Date: Wed, 23 Mar 2011 08:26:40 -0500 Subject: Question/Netflix issues? In-Reply-To: <14384A642243C34495DE884D7E13C83EA32140@UFEXCH-MBXN02.ad.ufl.edu> References: <14384A642243C34495DE884D7E13C83EA32140@UFEXCH-MBXN02.ad.ufl.edu> Message-ID: Netflix was hard down for about an hour last night. This is strictly from an end user perspective. Several of my buddies told me it was not even responding to DNS. -Hammer- "I was a normal American nerd." -Jack Herer On Tue, Mar 22, 2011 at 7:32 PM, Scott, Robert D. wrote: > > Greetings, > > I know this is way off topic, but is anyone else getting calls/tickets > about Netflix access problems? > <<<<>>>> > -Joe Blanchard > > Quite to the contrary Joe. It is actually a pleasure to read an > operationally relevant thread on NANOG. If your customers are calling about > accessibility issues then this is 200% relevant. The week long diatribe > about why, who, what, when, and if Sun Spots caused it, after the fact, are > not. > > Robert D. Scott Robert at ufl.edu > Senior Network Engineer 352-273-0113 Phone > CNS - Network Services 352-392-2061 CNS Phone Tree > University of Florida 352-273-0743 FAX > Florida Lambda Rail 352-294-3571 FLR NOC > Gainesville, FL 32611 321-663-0421 Cell > > From bhmccie at gmail.com Wed Mar 23 08:28:46 2011 From: bhmccie at gmail.com (Hammer) Date: Wed, 23 Mar 2011 08:28:46 -0500 Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: So did anyone get a root cause? -Hammer- "I was a normal American nerd." -Jack Herer On Wed, Mar 23, 2011 at 12:05 AM, Roger Marquis wrote: > A probable case of outsourcing core business functionality without a > fully tested plan B... > > < > http://www.computerworlduk.com/news/cloud-computing/3250260/netflix-switches-to-amazon-web-services-to-save-money/ > > > > > > > < > http://www.reddit.com/r/blog/comments/g66f0/why_reddit_was_down_for_6_of_the_last_24_hours/c1l6ykx > > > > Roger Marquis > > > We?re sorry, the Netflix website and the ability to instantly watch >> movies >> are both temporarily unavailable.However, our shipping centers are >> continuing to send and receive DVDs so your order is in process as usual. >> Our engineers are working hard to bring the site and ability to watch >> instantly back up as soon as possible. We appreciate your patience and, >> again, we apologize for any inconvenience this may cause. If you need >> further assistance, please call us at 1-877-445-6064. >> > > From cjp at 0x1.net Wed Mar 23 09:30:27 2011 From: cjp at 0x1.net (Christopher Pilkington) Date: Wed, 23 Mar 2011 10:30:27 -0400 Subject: Power issues at SAVVIS DC3 yesterday? Message-ID: We saw multiple 110V power feeds drop simultaneously yesterday at SAVVIS DC3, around 10am EDT. Anyone else have an issue, or is someone just playing with our breakers? We didn't lose any of our 208V. -cjp From jakari at bithose.com Wed Mar 23 09:39:55 2011 From: jakari at bithose.com (Jameel Akari) Date: Wed, 23 Mar 2011 10:39:55 -0400 (EDT) Subject: Power issues at SAVVIS DC3 yesterday? In-Reply-To: References: Message-ID: On Wed, 23 Mar 2011, Christopher Pilkington wrote: > We saw multiple 110V power feeds drop simultaneously yesterday at > SAVVIS DC3, around 10am EDT. Anyone else have an issue, or is someone > just playing with our breakers? We didn't lose any of our 208V. Usually Savvis sends announcement to all datacenter customers when something like this occurs, and posts it on the portal as well. I don't see anything today (but then, we're not in DC3 either.) Definitely open a ticket and hound them for a resolution on it if you didn't get a notification. -- Jameel Akari From mir at ripe.net Wed Mar 23 09:55:22 2011 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 23 Mar 2011 15:55:22 +0100 Subject: Internet Activity in Libya measured by looking at unsolicited traffic Message-ID: <4D8A09DA.7070407@ripe.net> Dear colleagues, Amidst the recent political unrest in the Middle East, researchers have observed significant changes in Internet traffic and connectivity. In this new article on RIPE Labs, Emile Aben from the RIPE NCC in collaboration with CAIDA, tapped into a previously unused source of data: unsolicited Internet traffic arriving from Libya. http://labs.ripe.net/Members/emileaben/unsolicited-internet-traffic-from-libya Kind Regards, Mirjam Kuehne RIPE NCC From Liudy at bukys.org Wed Mar 23 10:56:38 2011 From: Liudy at bukys.org (Liudvikas Bukys) Date: Wed, 23 Mar 2011 11:56:38 -0400 Subject: Creating an IPv6 addressing plan for end users In-Reply-To: References: Message-ID: Hi, I saw your document "Preparing an IPv6 Addressing Plan" after its URL was posted to NANOG. I have one small comment that perhaps you would consider in future revisions: The use of decimal numbers coded in hexadecimal is introduced in section 3.2, "Direct Link Between IPv4 and IPv6 Addresses", without discussion. It's also implicit in section 4.9 when encoding decimal VLAN numbers in hexadecimal address ranges. My opinion is that this may be a source of confusion, and should be explicitly described somewhere before section 3.2, as a deliberate implementation choice that makes it easier for human operators to configure and recognize deliberately-chosen mappings between decimals in IPv4 addresses and integers and corresponding fields in hexadecimal address ranges. Without an explicit discussion, this point may be missed by some readers -- especially since this is a training document. Just my opinion! I'm also curious as to whether this describes the way the world has already settled on, or whether this is a novel, controversial, or only-occasonally-observed technique. I see that RFC 5963 - IPv6 Deployment in Internet Exchange Points (IXPs) of August 2010 does mention BCD encoding of both ASNs and IPV4 digits, so I guess it's not that novel. > > -----Original Message----- > > From: Nathalie Trenaman [mailto:nathalie at ripe.net] > > Sent: Wednesday, March 16, 2011 5:05 AM > > To: nanog at nanog.org > > Subject: Creating an IPv6 addressing plan for end users > > > > Hi all, > > > > In our IPv6 courses, we often get the question: I give my customers a > > /48 (or a /56 or a /52) but they have no idea how to distribute that > > space in their network. > > In December Sander Steffann and Surfnet wrote a manual explaining > > exactly that, in clear language with nice graphics. A very useful > > document but it was in Dutch, so RIPE NCC decided to translate that > > document to English. > > > > Yesterday, we have published that document on our website and we hope > > this document is able to take away some of the fear that end users seem > > to have for these huge blocks. > > You can find this document here: > > > > http://bit.ly/IPv6addrplan (PDF) > > > > I look forward to your feedback, tips and comments. > > > > With kind regards, > > > > Nathalie Trenaman > > RIPE NCC Trainer > > > > > From llynch at civil-tongue.net Wed Mar 23 13:57:40 2011 From: llynch at civil-tongue.net (Lucy Lynch) Date: Wed, 23 Mar 2011 11:57:40 -0700 (PDT) Subject: =?UTF-8?Q?Internet_Society=E2=80=99s_Next_Generation_Leaders_program?= Message-ID: All - Please see below. If you know someone who would benefit from this program, and who meets the requirements outined, please forward this on. If you'd like a copy of the text in French let me know and I'll send you text. - Lucy >From ross at isoc.org Mon Mar 14 09:18:35 2011 Date: Mon, 14 Mar 2011 16:55:20 +0100 From: Gerard Ross Subject: Applications now open - Next Generation Leaders eLearning programme ?Shaping the Internet ? History and Futures? --------------------------------------------------------- Applications now open - Next Generation Leaders eLearning programme ?Shaping the Internet ? History and Futures? (English) --------------------------------------------------------- Applications are now open for the Internet Society?s Next Generation Leaders (NGL) eLearning programme ?Shaping the Internet ? History and Futures?. The Internet Society is pleased to call for applications from talented individuals seeking to join the new generation of Internet leaders, who will address the critical technology, policy, business, and education challenges that lie ahead. Following the successful launch of the programme last year, in 2011 the Internet Society is offering concurrent classes in English and French. Both classes will start in the week of 16 May 2011. The course, ?Shaping the Internet ? History and Futures?, is delivered by the DiploFoundation through their eLearning platform and learning methodology and features weekly online discussions of the course materials, moderated by a tutor and an expert facilitator. The NGL programme is designed to advance the careers of individuals who have the potential to become local, regional, and international leaders within the Internet technology, policy, and governance communities. The curriculum empowers participants to share their particular expertise with colleagues while acquiring knowledge in areas outside of their specialties. Places in the eLearning course are strictly limited, so all applications will be subject to a thorough selection process. * The deadline for applications is 8 April 2011. * The Programme --------------- The programme offers 20-25 places in each class for professionals from diverse stakeholder backgrounds in the fields of Internet technology, governance, and policy. Both courses are open to individuals from around the world. The programme will be conducted entirely online. The programme includes four thematic parts, which take place over six months during 2011 (May to October, with an exam in the first week of November): - The History of the Internet - Technical Background - Internet Standards and Technology - Internet Governance and Policy - Emerging issues ? Studies in Internet Policies, Processes and Diplomacy Learning activities take place in an online classroom and include analysis of course materials, interactive group discussions using a variety of communication tools, assignments, and exams. Successful participants will receive a certificate of completion of the programme. Languages ----------- Course materials and moderated online discussions for each course are in English and French, respectively. Target Audience ---------------- The project is designed for Internet Society members from academia, the public sector, technology industries, and civil society who are committed to the ongoing expansion of an open, sustainable Internet. Applications from the following categories of individuals from both developed and developing countries are encouraged: - officials in governmental ministries and departments dealing with ICT-related issues (for example, telecommunications, culture, education, foreign affairs, justice) - officials in regulatory authorities or institutions dealing with Information Society, Internet, and ICT-related issues - postgraduate students and researchers (for example, telecommunications, electrical engineering, law, economics, development studies, sociology) - engineers in the Internet field - civil society activists in the Internet field - journalists covering Internet-related issues - business people in the Internet field (for example, those managing ISPs or involved in software development). Timeline --------- - 14 March: 2011 Call for Applications begins - 8 April: 2011 Call for Applications ends - 28 April: Selection Results released - 16 May: Online classes commence Requirements ------------- Applicants are required to have: - met the age requirement (20-40 years old) - a basic awareness of, and interest in, Internet-related issues - knowledge and experience of the multi-stakeholder approach in international affairs - a professional background and relevant work or academic experience in the Internet field - member status in ISOC - fluency in English or French - good writing skills, ability to summarize information, and focus on details - regular access to the Internet (dial-up connection is sufficient) - minimum of 8 hours commitment per week during each thematic part of the online course (this is perhaps the single most important requirement and should be evaluated seriously by any potential applicant) - readiness to participate in online consultations (once a week at specified times) Deadline for Applications -------------------------- The deadline for applications is 8 April 2011, by midnight UTC/GMT. How to Apply -------------- For more information about the full Next Generation Leaders programme, including details on how to apply to either eLearning course, please visit: http://www.internetsociety.org/leaders If you have any questions, please contact . The Next Generation Leaders programme is supported by Nominet Trust and operates under the patronage of the European Commission for Information Society and Media. Delivery of the eLearning programme in French is sponsored by AFNIC. From sillywizard at rs4668.com Wed Mar 23 14:41:58 2011 From: sillywizard at rs4668.com (sillywizard at rs4668.com) Date: Wed, 23 Mar 2011 19:41:58 +0000 Subject: OT: Question/Netflix issues? In-Reply-To: References: Message-ID: <201103231941.p2NJfwnt010592@domU-12-31-38-04-61-C3.compute-1.internal> "Lyndon Nerenberg (VE6BBM/VE7TFX)" wrote: > > Guess that move to Amazon EC2 wasn't such a good idea. First reddit, > > now netflix. > > http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html > > FWIW, at $DAYJOB we haven't been able to run out a pool of a couple of > dozen EC2 instances for more than two weeks (since last June) without > at least one of them going down. The same number of hardware servers > we ran ourselves in Peer1 ran for a couple of years with no unplanned > outages. > > Amortized over five years, Peer1 colo + hardware is also cheaper than > the equivalent EC2 cost. > > Hey everyone! Join the cloud, and stand in the pissing rain. > > --lyndon > Interesting, because we run 120 with almost no issues whatsoever (3 failures over the past 12 months, none of which caused downtime). I've never had an EBS volume fail in the 18 months we've used them. IMHO, the "issues" with the cloud are almost always at a layer above the infrastructure. --L From kemp at network-services.uoregon.edu Wed Mar 23 15:32:44 2011 From: kemp at network-services.uoregon.edu (John Kemp) Date: Wed, 23 Mar 2011 13:32:44 -0700 Subject: route-views.saopaulo.routeviews.org is up and running Message-ID: <4D8A58EC.3020806@network-services.uoregon.edu> We announced on the PTTMetro list yesterday. http://www.routeviews.org/saopaulo.html If there is anyone else on PTTMetro who can share full tables, we would love to work with you on that. [ Also reminders: route-views.sydney.routeviews.org is running at EQIX SYD1. And we have the V6 interface available now at PAIX. Interface specifics at: http://www.peeringdb.com/view.php?asn=6447 ] Thanks, --- John Kemp (kemp at routeviews.org) RouteViews Engineer NOC: help at routeviews.org http://www.routeviews.org From paul at paulgraydon.co.uk Wed Mar 23 20:42:04 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Wed, 23 Mar 2011 15:42:04 -1000 Subject: OT: Question/Netflix issues? In-Reply-To: <201103231941.p2NJfwnt010592@domU-12-31-38-04-61-C3.compute-1.internal> References: <201103231941.p2NJfwnt010592@domU-12-31-38-04-61-C3.compute-1.internal> Message-ID: <4D8AA16C.9080707@paulgraydon.co.uk> On 03/23/2011 09:41 AM, sillywizard at rs4668.com wrote: > "Lyndon Nerenberg (VE6BBM/VE7TFX)" wrote: > >>> Guess that move to Amazon EC2 wasn't such a good idea. First reddit, >>> now netflix. >>> http://techblog.netflix.com/2010/12/four-reasons-we-choose-amazons-cloud-as.html >> FWIW, at $DAYJOB we haven't been able to run out a pool of a couple of >> dozen EC2 instances for more than two weeks (since last June) without >> at least one of them going down. The same number of hardware servers >> we ran ourselves in Peer1 ran for a couple of years with no unplanned >> outages. >> >> Amortized over five years, Peer1 colo + hardware is also cheaper than >> the equivalent EC2 cost. >> >> Hey everyone! Join the cloud, and stand in the pissing rain. >> >> --lyndon >> > Interesting, because we run 120 with almost no issues whatsoever (3 failures over the past 12 months, none of which caused downtime). I've never had an EBS volume fail in the 18 months we've used them. IMHO, the "issues" with the cloud are almost always at a layer above the infrastructure. > > --L > Reddit has routinely had EBS volumes either outright fail (2 major outages in the last month/month and a half, both caused by several EBSs vanishing), or show some not insignificant degradation in performance, and it seems barely a month goes by when I don't hear someone on twitter talking about similar with their infrastructures. Most of the problems I've heard about do seem to revolve around EBS, however, rather than their other services. It may be just the nature of people to pick on and shout about the biggest targets, but I'm reasonably sure almost all the problems I hear about relating to cloud services revolve around Amazon and rarely their competitors. http://highscalability.com/blog/2010/12/20/netflix-use-less-chatty-protocols-in-the-cloud-plus-26-fixes.html When it comes to other layers in the infrastructure probably one of the most talked about problems is network latency between instances. Netflix had to specifically re-engineer their platform because of it (and other major users talk of similar changes). There is almost certainly an argument to be made that the outcome of the forced re-engineering is a good thing as it's generally boosting resilience, but that it's been forced on them in such a way surely should also be of some cause for concern also. Reddit seem to be working hard to make their platform as resilient as possible to their routine problems cause by the infrastructure. One of their outgoing dev's gave a pretty interesting read on the problems they'd experience with Amazon: http://www.reddit.com/r/blog/comments/g66f0/why_reddit_was_down_for_6_of_the_last_24_hours/c1l6ykx I absolutely do think cloud hosting / virtual servers have value and use and shouldn't be underestimated or written off as a fad, but I'm also not entirely convinced at the moment that Amazon is a vendor to particularly trust with such services, I'd probably also argue that anyone keeping their eggs in one basket and relying on a single vendor for such services is taking a significant risk. There are plenty of tools and libraries out there to help provide a standard API for rolling out servers on different platforms. It seems crazy not to take advantage of the flexibility the cloud offers to remove as many SPOFs as possible. Paul From millnert at gmail.com Wed Mar 23 22:05:56 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 23 Mar 2011 23:05:56 -0400 Subject: The state-level attack on the SSL CA security model Message-ID: To my surprise, I did not see a mention in this community of the latest proof of the complete failure of the SSL CA model to actually do what it is supposed to: provide security, rather than a false sense of security. Essentially a state somewhere between Iraq and Pakistan snatched valid certs for: - mail.google.com - www.google.com - login.yahoo.com - login.skype.com - addons.mozilla.org - login.live.com - "global trustee" https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html http://www.imperialviolet.org/2011/03/18/revocation.html (on epic failure of cert revocation lists implementations in browsers, failing open (!)) http://blog.mozilla.com/security/2011/03/22/firefox-blocking-fraudulent-certificates/ http://www.microsoft.com/technet/security/advisory/2524375.mspx For over a week users of browsers, and the internet at large, were/was not informed by COMODO that their security was compromised. "Why not" is beyond many of us. Announcing this high and loud even before fixes were available would not have exposed more users to threats, but less. Conclusion: protecting people must not be a priority in the SSL CA model. In some places, failure of internet security means people die, and it is high time to start serious work to replace this time-and-time again proven flawed model with something that, at the very least, does not fail this tragically. DNSSEC is a good but insufficient start in this particular case. Regards, Martin From rdobbins at arbor.net Wed Mar 23 23:13:37 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 24 Mar 2011 04:13:37 +0000 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: Message-ID: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> On Mar 24, 2011, at 11:05 AM, Martin Millnert wrote: > Announcing this high and loud even before fixes were available would not have exposed more users to threats, but less. An argument against doing this prior to fixes being available is that miscreants who didn't know about this previously would be alerted to the possibility of using one of these certs (assuming they could get their hands on one) in conjunction with name resolution manipulation. Note that announcing this prior to fixes would've dramatically increased the resale value of these certificates in the underground economy, making them much more attractive/lucrative. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From nathalie at ripe.net Thu Mar 24 03:06:44 2011 From: nathalie at ripe.net (Nathalie Trenaman) Date: Thu, 24 Mar 2011 09:06:44 +0100 Subject: Creating an IPv6 addressing plan for end users In-Reply-To: References: Message-ID: Hi Liudvikas, Thank you very much for your feedback. On Mar 23, 2011, at 4:56 PM, Liudvikas Bukys wrote: > Hi, I saw your document "Preparing an IPv6 Addressing Plan" after its URL was posted to NANOG. > > I have one small comment that perhaps you would consider in future revisions: > > The use of decimal numbers coded in hexadecimal is introduced in section 3.2, "Direct Link Between IPv4 and IPv6 Addresses", without discussion. It's also implicit in section 4.9 when encoding decimal VLAN numbers in hexadecimal address ranges. > > My opinion is that this may be a source of confusion, and should be explicitly described somewhere before section 3.2, as a deliberate implementation choice that makes it easier for human operators to configure and recognize deliberately-chosen mappings between decimals in IPv4 addresses and integers and corresponding fields in hexadecimal address ranges. You are right, we could explain this section in more detail and we have received this feedback from some other readers as well. We will take this into account for future revision. > > Without an explicit discussion, this point may be missed by some readers -- especially since this is a training document. > > Just my opinion! > > I'm also curious as to whether this describes the way the world has already settled on, or whether this is a novel, controversial, or only-occasonally-observed technique. I see that RFC 5963 - IPv6 Deployment in Internet Exchange Points (IXPs) of August 2010 does mention BCD encoding of both ASNs and IPV4 digits, so I guess it's not that novel. As I'm not the author of the document - only the initiator of the translation - I'm not sure if I'm the right person to answer this question :) However, I do think it is an interesting discussion on how far "the world has already settled on" different IPv6 implementation techniques. There are relatively only a few mature operational IPv6 implementations at the moment and the intention of this document is to have people think of a structure for their address plan and give them some pointers. In case you would like to know more of the background of this document, please talk to Sander Steffann (the author). I'm sure he will be happy to answer your questions. Kind regards, Nathalie Trenaman RIPE NCC Trainer > > > > -----Original Message----- > > From: Nathalie Trenaman [mailto:nathalie at ripe.net] > > Sent: Wednesday, March 16, 2011 5:05 AM > > To: nanog at nanog.org > > Subject: Creating an IPv6 addressing plan for end users > > > > Hi all, > > > > In our IPv6 courses, we often get the question: I give my customers a > > /48 (or a /56 or a /52) but they have no idea how to distribute that > > space in their network. > > In December Sander Steffann and Surfnet wrote a manual explaining > > exactly that, in clear language with nice graphics. A very useful > > document but it was in Dutch, so RIPE NCC decided to translate that > > document to English. > > > > Yesterday, we have published that document on our website and we hope > > this document is able to take away some of the fear that end users seem > > to have for these huge blocks. > > You can find this document here: > > > > http://bit.ly/IPv6addrplan (PDF) > > > > I look forward to your feedback, tips and comments. > > > > With kind regards, > > > > Nathalie Trenaman > > RIPE NCC Trainer > > > > > From joakim at aronius.se Thu Mar 24 05:19:47 2011 From: joakim at aronius.se (Joakim Aronius) Date: Thu, 24 Mar 2011 11:19:47 +0100 Subject: The state-level attack on the SSL CA security model In-Reply-To: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> Message-ID: <20110324101947.GA11913@nike.aronius.se> * Dobbins, Roland (rdobbins at arbor.net) wrote: > > On Mar 24, 2011, at 11:05 AM, Martin Millnert wrote: > > > Announcing this high and loud even before fixes were available would not have exposed more users to threats, but less. > > > An argument against doing this prior to fixes being available is that miscreants who didn't know about this previously would be alerted to the possibility of using one of these certs (assuming they could get their hands on one) in conjunction with name resolution manipulation. The fix here is to delete the compromised UID and revoke the certs, thats done immediately, then inform the public, no reason to wait after that. IF the speculations about a specific nation is true then there is a risk that people there run real (like physical) risks by using e.g. yahoo the last few days. They would have appreciated being informed. > > Note that announcing this prior to fixes would've dramatically increased the resale value of these certificates in the underground economy, making them much more attractive/lucrative. Why? Surely the value of stolen certs are higher if the public do not know that they exist. /Joakim From rdobbins at arbor.net Thu Mar 24 05:28:26 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 24 Mar 2011 10:28:26 +0000 Subject: The state-level attack on the SSL CA security model In-Reply-To: <20110324101947.GA11913@nike.aronius.se> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> Message-ID: On Mar 24, 2011, at 6:19 PM, Joakim Aronius wrote: > Surely the value of stolen certs are higher if the public do not know that they exist. A wider swathe of interested parties would know of their existence, and their existence would be officially confirmed, which would make them more valuable. Unfortunately, the general public neither know, understand, or care about such things. They happily click 'I Understand the Risks' or whatever the button says in their browsers of choice to accept self-signed certificates all the time. I don't know enough details of what actually transpired to have an actual opinion on the Comodo situation one way or another; but I can see both sides of the argument. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From fweimer at bfk.de Thu Mar 24 05:41:14 2011 From: fweimer at bfk.de (Florian Weimer) Date: Thu, 24 Mar 2011 10:41:14 +0000 Subject: The state-level attack on the SSL CA security model In-Reply-To: (Roland Dobbins's message of "Thu\, 24 Mar 2011 10\:28\:26 +0000") References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> Message-ID: <8239mchkc5.fsf@mid.bfk.de> * Roland Dobbins: > A wider swathe of interested parties would know of their existence, > and their existence would be officially confirmed, which would make > them more valuable. This is at odds with what happens in other contexts. Disclosure devalues information. -- 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 eugen at leitl.org Thu Mar 24 07:57:57 2011 From: eugen at leitl.org (Eugen Leitl) Date: Thu, 24 Mar 2011 13:57:57 +0100 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million Message-ID: <20110324125757.GG23560@leitl.org> http://blog.internetgovernance.org/blog/_archives/2011/3/23/4778509.html Nortel, in bankruptcy, sells IPv4 address block for $7.5 million by Milton Mueller on Wed 23 Mar 2011 10:30 PM EDT | Permanent Link | ShareThis Wake up call for our friends in the Regional Internet Registries. Nortel, the Canadian telecommunications equipment manufacturer that filed for bankruptcy protection in 2009, has succeeded in making its legacy IPv4 address block an asset that can be sold to generate money for its creditors. The March 23 edition of the Dow Jones Daily Bankruptcy Report has reported that Nortel's block of 666,624 IPv4's was sold for $7.5 million - a price of $11.25 per IP address. The buyer of the addresses was Microsoft. More information is in its filing in a Delware bankruptcy court. Now the interesting question becomes, does the price of IPv4s go up or down from here? As the realities of dual stack sink in, I'm betting...up. From zeusdadog at gmail.com Thu Mar 24 08:10:10 2011 From: zeusdadog at gmail.com (Jay Nakamura) Date: Thu, 24 Mar 2011 09:10:10 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <20110324125757.GG23560@leitl.org> References: <20110324125757.GG23560@leitl.org> Message-ID: 666,624 is kind of odd number, isn't it? That comes out to a /13,/15,/19,/21 and a /22. On Thu, Mar 24, 2011 at 8:57 AM, Eugen Leitl wrote: > > http://blog.internetgovernance.org/blog/_archives/2011/3/23/4778509.html > > Nortel, in bankruptcy, sells IPv4 address block for $7.5 million > > by Milton Mueller on Wed 23 Mar 2011 10:30 PM EDT ?| ?Permanent Link ?| > ShareThis > > Wake up call for our friends in the Regional Internet Registries. Nortel, the > Canadian telecommunications equipment manufacturer that filed for bankruptcy > protection in 2009, has succeeded in making its legacy IPv4 address block an > asset that can be sold to generate money for its creditors. The March 23 > edition of the Dow Jones Daily Bankruptcy Report has reported that Nortel's > block of 666,624 IPv4's was sold for $7.5 million - a price of $11.25 per IP > address. The buyer of the addresses was Microsoft. More information is in its > filing in a Delware bankruptcy court. Now the interesting question becomes, > does the price of IPv4s go up or down from here? As the realities of dual > stack sink in, I'm betting...up. > > From tom at ninjabadger.net Thu Mar 24 08:20:35 2011 From: tom at ninjabadger.net (Tom Hill) Date: Thu, 24 Mar 2011 13:20:35 +0000 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> Message-ID: <1300972835.1822.7.camel@teh-desktop> On Thu, 2011-03-24 at 09:10 -0400, Jay Nakamura wrote: > 666,624 is kind of odd number, isn't it? That comes out to a > /13,/15,/19,/21 and a /22. Yeah, I was trying to work that out -- well done for persevering. :) From dot at dotat.at Thu Mar 24 08:27:29 2011 From: dot at dotat.at (Tony Finch) Date: Thu, 24 Mar 2011 13:27:29 +0000 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> Message-ID: Jay Nakamura wrote: > 666,624 is kind of odd number, isn't it? That comes out to a > /13,/15,/19,/21 and a /22. >From the court documents I gather that it is a collection of miscellaneous blocks that Nortel acquired over the years, presumable via corporate M&A. However there isn't (as far as I can see) a list of the actual blocks. See docket 5143 at http://chapter11.epiqsystems.com/NNI/docket/Default.aspx Tony. -- f.anthony.n.finch http://dotat.at/ South-east Iceland: Cyclonic 4 or 5, increasing 5 to 7 for a time in north. Moderate or rough. Occasional rain. Moderate or good. From bclark at spectraaccess.com Thu Mar 24 08:32:21 2011 From: bclark at spectraaccess.com (Bret Clark) Date: Thu, 24 Mar 2011 09:32:21 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> Message-ID: <4D8B47E5.9010709@spectraaccess.com> Why would Microsoft need this many IP's? I could see the benefiting service providers much more. On 03/24/2011 09:27 AM, Tony Finch wrote: > Jay Nakamura wrote: > >> 666,624 is kind of odd number, isn't it? That comes out to a >> /13,/15,/19,/21 and a /22. > > From the court documents I gather that it is a collection of miscellaneous > blocks that Nortel acquired over the years, presumable via corporate M&A. > However there isn't (as far as I can see) a list of the actual blocks. See > docket 5143 at http://chapter11.epiqsystems.com/NNI/docket/Default.aspx > > Tony. From garrett at skjelstad.org Thu Mar 24 08:37:21 2011 From: garrett at skjelstad.org (Garrett Skjelstad) Date: Thu, 24 Mar 2011 06:37:21 -0700 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8B47E5.9010709@spectraaccess.com> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> Message-ID: yay cloud. On Thu, Mar 24, 2011 at 6:32 AM, Bret Clark wrote: > Why would Microsoft need this many IP's? I could see the benefiting service > providers much more. > > From owen at delong.com Thu Mar 24 08:45:15 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Mar 2011 06:45:15 -0700 Subject: Creating an IPv6 addressing plan for end users In-Reply-To: References: Message-ID: <9AA521FF-107E-458C-80FA-80A930E347EE@delong.com> On Mar 24, 2011, at 1:06 AM, Nathalie Trenaman wrote: > Hi Liudvikas, > > Thank you very much for your feedback. > > On Mar 23, 2011, at 4:56 PM, Liudvikas Bukys wrote: > >> Hi, I saw your document "Preparing an IPv6 Addressing Plan" after its URL was posted to NANOG. >> >> I have one small comment that perhaps you would consider in future revisions: >> >> The use of decimal numbers coded in hexadecimal is introduced in section 3.2, "Direct Link Between IPv4 and IPv6 Addresses", without discussion. It's also implicit in section 4.9 when encoding decimal VLAN numbers in hexadecimal address ranges. >> >> My opinion is that this may be a source of confusion, and should be explicitly described somewhere before section 3.2, as a deliberate implementation choice that makes it easier for human operators to configure and recognize deliberately-chosen mappings between decimals in IPv4 addresses and integers and corresponding fields in hexadecimal address ranges. > > You are right, we could explain this section in more detail and we have received this feedback from some other readers as well. We will take this into account for future revision. > >> >> Without an explicit discussion, this point may be missed by some readers -- especially since this is a training document. >> >> Just my opinion! >> >> I'm also curious as to whether this describes the way the world has already settled on, or whether this is a novel, controversial, or only-occasonally-observed technique. I see that RFC 5963 - IPv6 Deployment in Internet Exchange Points (IXPs) of August 2010 does mention BCD encoding of both ASNs and IPV4 digits, so I guess it's not that novel. > > As I'm not the author of the document - only the initiator of the translation - I'm not sure if I'm the right person to answer this question :) However, I do think it is an interesting discussion on how far "the world has already settled on" different IPv6 implementation techniques. There are relatively only a few mature operational IPv6 implementations at the moment and the intention of this document is to have people think of a structure for their address plan and give them some pointers. > I believe based on my observation and experience that it describes a relatively common practice, but, not one which has in any way been standardized. It is one approach that is available and which has proven useful to others. Both the BCD and Hex translation techniques are in relatively common use, but, the BCD mechanism seems to be somewhat more common. The important thing to be careful about with BCD is that you do not attempt to represent all four octets of an address with each cluster representing an octet because you will violate the "first 12 bits of a static suffix must be zero" rule (following that rule avoids accidental conflicts with stateless autoconf). Owen From ops.lists at gmail.com Thu Mar 24 08:48:52 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 24 Mar 2011 19:18:52 +0530 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8B47E5.9010709@spectraaccess.com> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> Message-ID: On Thu, Mar 24, 2011 at 7:02 PM, Bret Clark wrote: > Why would Microsoft need this many IP's? I could see the benefiting service > providers much more. Microsoft runs Hotmail. Office Live and a bunch of other services you might have heard of. And if every common or garden snowshoer can get a /15, why can't a legitimate corporation get some for itself? :) -- Suresh Ramasubramanian (ops.lists at gmail.com) From owen at delong.com Thu Mar 24 08:54:18 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Mar 2011 06:54:18 -0700 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <1300972835.1822.7.camel@teh-desktop> References: <20110324125757.GG23560@leitl.org> <1300972835.1822.7.camel@teh-desktop> Message-ID: On Mar 24, 2011, at 6:20 AM, Tom Hill wrote: > On Thu, 2011-03-24 at 09:10 -0400, Jay Nakamura wrote: >> 666,624 is kind of odd number, isn't it? That comes out to a >> /13,/15,/19,/21 and a /22. > > Yeah, I was trying to work that out -- well done for persevering. :) > Sounds like the pieces of their /8 that weren't in use or something like that. Owen From nanog-post at rsuc.gweep.net Thu Mar 24 09:06:36 2011 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 24 Mar 2011 10:06:36 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> Message-ID: <20110324140636.GA28981@gweep.net> On Thu, Mar 24, 2011 at 01:27:29PM +0000, Tony Finch wrote: > Jay Nakamura wrote: > > > 666,624 is kind of odd number, isn't it? That comes out to a > > /13,/15,/19,/21 and a /22. > > >From the court documents I gather that it is a collection of miscellaneous > blocks that Nortel acquired over the years, presumable via corporate M&A. > However there isn't (as far as I can see) a list of the actual blocks. See > docket 5143 at http://chapter11.epiqsystems.com/NNI/docket/Default.aspx Exhibit B expressly indicates they were listed but filed under seal; interesting to request that. Previous documents indicate they used a third party to shop things around, who got a $200k retainer and is getting paid 5% of the sale. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From bicknell at ufp.org Thu Mar 24 09:08:21 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 24 Mar 2011 07:08:21 -0700 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8B47E5.9010709@spectraaccess.com> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> Message-ID: <20110324140821.GA57022@ussenterprise.ufp.org> In a message written on Thu, Mar 24, 2011 at 09:32:21AM -0400, Bret Clark wrote: > Why would Microsoft need this many IP's? I could see the benefiting > service providers much more. I think the more interesting question is why would Microsoft pay $7.5 million for something they can, at least for the moment, get for free. -- 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 chk at pobox.com Thu Mar 24 09:09:13 2011 From: chk at pobox.com (Harald Koch) Date: Thu, 24 Mar 2011 10:09:13 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: Message-ID: <4D8B5089.4010507@pobox.com> On 3/23/2011 11:05 PM, Martin Millnert wrote: > To my surprise, I did not see a mention in this community of the > latest proof of the complete failure of the SSL CA model to actually > do what it is supposed to: provide security, rather than a false sense > of security. This story strikes me as a success - the certs were revoked immediately, and it took a surprisingly short amount of time for security fixes to appear all over the place. > In some places, failure of internet security means people die Those people know that using highly visible services like gmail and skype is asking to be exposed... -- Harald From aaron at wholesaleinternet.net Thu Mar 24 09:27:58 2011 From: aaron at wholesaleinternet.net (Aaron Wendel) Date: Thu, 24 Mar 2011 09:27:58 -0500 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <20110324140821.GA57022@ussenterprise.ufp.org> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> Message-ID: <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> That's a good question. Maybe they can't qualify under Arin rules. Another question will be: how is Arin going to handle it? Im pretty sure that the RSA says that in the event of bankruptcy ips revert to the Arin pool. I understand that these were legacy addresses but....... Aaron Sent via DROID on Verizon Wireless -----Original message----- From: Leo Bicknell To: nanog at nanog.org Sent: Thu, Mar 24, 2011 14:08:21 GMT+00:00 Subject: Re: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In a message written on Thu, Mar 24, 2011 at 09:32:21AM -0400, Bret Clark wrote: > Why would Microsoft need this many IP's? I could see the benefiting > service providers much more. I think the more interesting question is why would Microsoft pay $7.5 million for something they can, at least for the moment, get for free. -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From tore.anderson at redpill-linpro.com Thu Mar 24 09:40:27 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 24 Mar 2011 15:40:27 +0100 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <20110324140821.GA57022@ussenterprise.ufp.org> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> Message-ID: <4D8B57DB.7080602@redpill-linpro.com> * Leo Bicknell > I think the more interesting question is why would Microsoft pay > $7.5 million for something they can, at least for the moment, get > for free. A very interesting question indeed! However, they can only get them for free from ARIN if they can document an immediate demand. Perhaps they don't have an immediate demand, and are simply stockpiling addresses for later use post ARIN depletion? Or perhaps they hope to make a profit then by selling them to someone else. Either way, it sure seems they're speculating that the market price of an IPv4 address is going to rise to more than US$11.25. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From Valdis.Kletnieks at vt.edu Thu Mar 24 09:43:54 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 24 Mar 2011 10:43:54 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: Your message of "Thu, 24 Mar 2011 09:27:58 CDT." <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> Message-ID: <7161.1300977834@localhost> On Thu, 24 Mar 2011 09:27:58 CDT, Aaron Wendel said: > That's a good question. Maybe they can't qualify under Arin rules. Another > question will be: how is Arin going to handle it? > > Im pretty sure that the RSA says that in the event of bankruptcy ips revert > to the Arin pool. I understand that these were legacy addresses but....... The *important* question is - do they *remain* legacy addresses under the legacy address rules after the Microsoft acquisition, and thus re-sellable at a later date? If so, we may have seen the first case of IP address speculation, and the start of the bubble. I don't want to see how this bubble bursts.. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nixon at nsc.liu.se Thu Mar 24 09:46:14 2011 From: nixon at nsc.liu.se (Leif Nixon) Date: Thu, 24 Mar 2011 15:46:14 +0100 Subject: The state-level attack on the SSL CA security model In-Reply-To: <4D8B5089.4010507@pobox.com> (Harald Koch's message of "Thu, 24 Mar 2011 10:09:13 -0400") References: <4D8B5089.4010507@pobox.com> Message-ID: Harald Koch writes: > On 3/23/2011 11:05 PM, Martin Millnert wrote: >> To my surprise, I did not see a mention in this community of the >> latest proof of the complete failure of the SSL CA model to actually >> do what it is supposed to: provide security, rather than a false sense >> of security. > > This story strikes me as a success - the certs were revoked > immediately, and it took a surprisingly short amount of time for > security fixes to appear all over the place. But revocation doesn't work, and people don't install updates, so this is only a *theoretical* success. -- Leif Nixon - Security officer National Supercomputer Centre - Swedish National Infrastructure for Computing Nordic Data Grid Facility - European Grid Infrastructure From jim at impactbusiness.com Thu Mar 24 09:46:05 2011 From: jim at impactbusiness.com (Jim Gonzalez) Date: Thu, 24 Mar 2011 10:46:05 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8B57DB.7080602@redpill-linpro.com> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> Message-ID: <014c01cbea32$374dc8a0$a5e959e0$@com> Just wondering if Microsoft has to justify the address space once they change ownerships with Arin ? -----Original Message----- From: Tore Anderson [mailto:tore.anderson at redpill-linpro.com] Sent: Thursday, March 24, 2011 10:40 AM To: nanog at nanog.org Subject: Re: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million * Leo Bicknell > I think the more interesting question is why would Microsoft pay > $7.5 million for something they can, at least for the moment, get > for free. A very interesting question indeed! However, they can only get them for free from ARIN if they can document an immediate demand. Perhaps they don't have an immediate demand, and are simply stockpiling addresses for later use post ARIN depletion? Or perhaps they hope to make a profit then by selling them to someone else. Either way, it sure seems they're speculating that the market price of an IPv4 address is going to rise to more than US$11.25. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From woody at pch.net Thu Mar 24 09:48:24 2011 From: woody at pch.net (Bill Woodcock) Date: Thu, 24 Mar 2011 07:48:24 -0700 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8B57DB.7080602@redpill-linpro.com> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> Message-ID: <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> On Mar 24, 2011, at 7:40 AM, Tore Anderson wrote: > They can only get them for free from ARIN if they can document > an immediate demand. Perhaps they don't have an immediate demand? They can only get them _at all_ if they can document need. All receipt of address space, whether from the free-pool or through a transfer, is needs-based. Anything else would be removing a critical resource from use. -Bill From hank at efes.iucc.ac.il Thu Mar 24 09:49:57 2011 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 24 Mar 2011 16:49:57 +0200 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8B57DB.7080602@redpill-linpro.com> References: <20110324140821.GA57022@ussenterprise.ufp.org> <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> Message-ID: <5.1.0.14.2.20110324164605.00c39f20@efes.iucc.ac.il> At 15:40 24/03/2011 +0100, Tore Anderson wrote: >Either way, it sure seems they're speculating that the market price of >an IPv4 address is going to rise to more than US$11.25. Anything that has ceased to be produced and has demand will go up in value. Just rename IPv4 as Pontiac GTO. -Hank From dot at dotat.at Thu Mar 24 09:53:42 2011 From: dot at dotat.at (Tony Finch) Date: Thu, 24 Mar 2011 14:53:42 +0000 Subject: The state-level attack on the SSL CA security model In-Reply-To: <4D8B5089.4010507@pobox.com> References: <4D8B5089.4010507@pobox.com> Message-ID: Harald Koch wrote: > > This story strikes me as a success - the certs were revoked immediately, and > it took a surprisingly short amount of time for security fixes to appear all > over the place. It would have been much easier if certificate revocation actually worked properly. http://www.imperialviolet.org/2011/03/18/revocation.html Tony. -- f.anthony.n.finch http://dotat.at/ Viking, North Utsire, South Utsire: Westerly veering northerly, 4 or 5, occasionally 6 at first. Moderate or rough. Occasional rain. Moderate or good, occasionally poor at first. From dwhite at olp.net Thu Mar 24 09:59:14 2011 From: dwhite at olp.net (Dan White) Date: Thu, 24 Mar 2011 09:59:14 -0500 Subject: The state-level attack on the SSL CA security model In-Reply-To: <4D8B5089.4010507@pobox.com> References: <4D8B5089.4010507@pobox.com> Message-ID: <20110324145914.GF4692@dan.olp.net> On 24/03/11?10:09?-0400, Harald Koch wrote: >On 3/23/2011 11:05 PM, Martin Millnert wrote: >>To my surprise, I did not see a mention in this community of the >>latest proof of the complete failure of the SSL CA model to actually >>do what it is supposed to: provide security, rather than a false sense >>of security. > >This story strikes me as a success - the certs were revoked >immediately, and it took a surprisingly short amount of time for >security fixes to appear all over the place. The point is that the 'short amount of time' should have been zero (from the time of the update of the CRL) which would have allowed an immediate announcement of the revocation to the public, with sufficient details for the public to make educated decisions about their internet usage. But because the CRL publication did not facilitate that, due to whatever deficiency there existed in the procotol or in browser implementations, announcement had to be delayed, providing a small group of attackers a larger window than necessary to compromise information. -- Dan White From morrowc.lists at gmail.com Thu Mar 24 09:59:40 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 24 Mar 2011 10:59:40 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: <20110324101947.GA11913@nike.aronius.se> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> Message-ID: On Thu, Mar 24, 2011 at 6:19 AM, Joakim Aronius wrote: > IF the speculations about a specific nation is true then there is a risk that people there run real (like physical) risks by using e.g. yahoo the last few days. They would have appreciated being informed. >> if speculation is true, then all bets are off, and telling anyone isn't necessarily going to help those under the thumb of the speculated attacker.... just sayin! (also, vote now, vote often for dane-wg to get it's work done... dns-sec secured key fingerprints for ssl certs) From richard.barnes at gmail.com Thu Mar 24 09:59:45 2011 From: richard.barnes at gmail.com (Richard Barnes) Date: Thu, 24 Mar 2011 10:59:45 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: <4D8B5089.4010507@pobox.com> Message-ID: Which is especially funny since Comodo is citing the fact that they've had no OCSP requests for the bad certs as evidence that they haven't been used. --Richard On Thu, Mar 24, 2011 at 10:53 AM, Tony Finch wrote: > Harald Koch wrote: >> >> This story strikes me as a success - the certs were revoked immediately, and >> it took a surprisingly short amount of time for security fixes to appear all >> over the place. > > It would have been much easier if certificate revocation actually worked > properly. > > http://www.imperialviolet.org/2011/03/18/revocation.html > > Tony. > -- > f.anthony.n.finch ? ?http://dotat.at/ > Viking, North Utsire, South Utsire: Westerly veering northerly, 4 or 5, > occasionally 6 at first. Moderate or rough. Occasional rain. Moderate or good, > occasionally poor at first. > > From tore.anderson at redpill-linpro.com Thu Mar 24 10:10:17 2011 From: tore.anderson at redpill-linpro.com (Tore Anderson) Date: Thu, 24 Mar 2011 16:10:17 +0100 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> Message-ID: <4D8B5ED9.605@redpill-linpro.com> * Bill Woodcock > They can only get them _at all_ if they can document need. All > receipt of address space, whether from the free-pool or through a > transfer, is needs-based. I've understood that this claim is undisputed *only* for address space that is covered by the ARIN LRSA or any other normal RIR agreement. (I have no idea if that is the case for this particular address space or not.) -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27 From ljb at merit.edu Thu Mar 24 10:10:14 2011 From: ljb at merit.edu (Larry Blunk) Date: Thu, 24 Mar 2011 11:10:14 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <20110324140636.GA28981@gweep.net> References: <20110324125757.GG23560@leitl.org> <20110324140636.GA28981@gweep.net> Message-ID: <4D8B5ED6.3040604@merit.edu> On 03/24/2011 10:06 AM, Joe Provo wrote: > On Thu, Mar 24, 2011 at 01:27:29PM +0000, Tony Finch wrote: >> Jay Nakamura wrote: >> >>> 666,624 is kind of odd number, isn't it? That comes out to a >>> /13,/15,/19,/21 and a /22. >> > From the court documents I gather that it is a collection of miscellaneous >> blocks that Nortel acquired over the years, presumable via corporate M&A. >> However there isn't (as far as I can see) a list of the actual blocks. See >> docket 5143 at http://chapter11.epiqsystems.com/NNI/docket/Default.aspx > > Exhibit B expressly indicates they were listed but filed under seal; > interesting to request that. Previous documents indicate they used a > third party to shop things around, who got a $200k retainer and is > getting paid 5% of the sale. > Docket #4435, Exhibit B has more information on the IP address broker, Addrex, Inc., of Reston, Va. Here's the president and related companies -- http://www.linkedin.com/pub/charles-m-lee/22/414/a94 http://www.denuo.com http://www.addrex.net http://www.depository.net From randy at psg.com Thu Mar 24 10:16:27 2011 From: randy at psg.com (Randy Bush) Date: Thu, 24 Mar 2011 08:16:27 -0700 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> Message-ID: > They can only get them _at all_ if they can document need. All > receipt of address space, whether from the free-pool or through a > transfer, is needs-based. Anything else would be removing a critical > resource from use. http://en.wikipedia.org/wiki/Canute From smb at cs.columbia.edu Thu Mar 24 10:34:13 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Thu, 24 Mar 2011 11:34:13 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> Message-ID: <1E6E33B2-F8B9-4AB7-96F9-8C211D1D06D2@cs.columbia.edu> On Mar 24, 2011, at 10:27 58AM, Aaron Wendel wrote: > That's a good question. Maybe they can't qualify under Arin rules. Another question will be: how is Arin going to handle it? > > Im pretty sure that the RSA says that in the event of bankruptcy ips revert to the Arin pool. I understand that these were legacy addresses but....... I wonder if the bankruptcy court agrees with that. Does it have the power to order ARIN to accept this? "Send lawyers, guns, and money"... --Steve Bellovin, http://www.cs.columbia.edu/~smb From jcurran at arin.net Thu Mar 24 10:35:28 2011 From: jcurran at arin.net (John Curran) Date: Thu, 24 Mar 2011 15:35:28 +0000 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <20110324125757.GG23560@leitl.org> References: <20110324125757.GG23560@leitl.org> Message-ID: <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> On Mar 24, 2011, at 8:57 AM, Eugen Leitl wrote: > http://blog.internetgovernance.org/blog/_archives/2011/3/23/4778509.html Read the comment at the end (attached here for reference). /John John Curran President and CEO ARIN ---- > Re: Nortel, in bankruptcy, Requests Approval of Sale of IPv4 address blocks > by John Curran on Thu 24 Mar 2011 11:31 AM EDT | Profile | Permanent Link > > Milton - > > Did you have an opportunity to review the actual docket materials, or is your "coverage" based just on your review of the referenced article? > > The parties have requested approval of a sale order from the Bankruptcy judge. There is a timeline for making filings and a hearing date. There is not an approved sale order at this time, contrary to your blog entry title. > > ARIN has a responsibility to make clear the community-developed policies by which we maintain the ARIN Whois database, and any actual transfer of number resources in compliance with such policies will be reflected in the database. > > FYI, > /John From jcurran at arin.net Thu Mar 24 10:42:35 2011 From: jcurran at arin.net (John Curran) Date: Thu, 24 Mar 2011 15:42:35 +0000 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> Message-ID: <755995FD-1964-45F6-AC4C-04CF872B4571@corp.arin.net> On Mar 24, 2011, at 11:16 AM, Randy Bush wrote: >> They can only get them _at all_ if they can document need. All >> receipt of address space, whether from the free-pool or through a >> transfer, is needs-based. Anything else would be removing a critical >> resource from use. > > http://en.wikipedia.org/wiki/Canute Thank you Randy. Give Canute a community-developed set of marching orders, and make the ocean a little more pliable and you might have something there. As usual, I will simply point out to folks that ARIN will indeed administer the policy as adopted, and will explain it as necessary in various courtrooms. I ask that the community spend its time thinking about what policies are indeed desirable, and make sure those are reflected in the adopted policies. That's the first priority in making sure that we're doing the right thing and our efforts are productive and useful to the community. /John John Curran President and CEO ARIN From mikea at mikea.ath.cx Thu Mar 24 10:43:39 2011 From: mikea at mikea.ath.cx (mikea) Date: Thu, 24 Mar 2011 10:43:39 -0500 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <1E6E33B2-F8B9-4AB7-96F9-8C211D1D06D2@cs.columbia.edu> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> <1E6E33B2-F8B9-4AB7-96F9-8C211D1D06D2@cs.columbia.edu> Message-ID: <20110324154339.GB5179@mikea.ath.cx> On Thu, Mar 24, 2011 at 11:34:13AM -0400, Steven Bellovin wrote: > > On Mar 24, 2011, at 10:27 58AM, Aaron Wendel wrote: > > > That's a good question. Maybe they can't qualify under Arin rules. Another question will be: how is Arin going to handle it? > > > > Im pretty sure that the RSA says that in the event of bankruptcy ips revert to the Arin pool. I understand that these were legacy addresses but....... > > I wonder if the bankruptcy court agrees with that. Does it have the power > to order ARIN to accept this? "Send lawyers, guns, and money"... Good question. Isn't ARIN a US corporation? Yep; incorporated in Virginia. At the very least, it might be ... interesting for a Canadian court to try to enforce an order on a US corporation with no Canadian presence. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From mikea at mikea.ath.cx Thu Mar 24 10:45:39 2011 From: mikea at mikea.ath.cx (mikea) Date: Thu, 24 Mar 2011 10:45:39 -0500 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <1E6E33B2-F8B9-4AB7-96F9-8C211D1D06D2@cs.columbia.edu> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> <1E6E33B2-F8B9-4AB7-96F9-8C211D1D06D2@cs.columbia.edu> Message-ID: <20110324154539.GC5179@mikea.ath.cx> On Thu, Mar 24, 2011 at 11:34:13AM -0400, Steven Bellovin wrote: > > On Mar 24, 2011, at 10:27 58AM, Aaron Wendel wrote: > > > That's a good question. Maybe they can't qualify under Arin rules. Another question will be: how is Arin going to handle it? > > > > Im pretty sure that the RSA says that in the event of bankruptcy ips revert to the Arin pool. I understand that these were legacy addresses but....... > > I wonder if the bankruptcy court agrees with that. Does it have the power to order ARIN to accept this? "Send lawyers, guns, and money"... Disregard previous; I see the bankruptcy is in the Delaware courts. -- Mike Andrews, W5EGO mikea at mikea.ath.cx Tired old sysadmin From owen at delong.com Thu Mar 24 11:54:45 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Mar 2011 11:54:45 -0500 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> Message-ID: <9BC1F680-B29A-4979-A151-1DABF0A9DE8C@delong.com> Actually ARIN rules don't say anything about bankruptcy. However, in the event that the organization ceases to exist and there is no successor organization taking over the network infrastructure under an 8.2 transfer, yes, the resources would revert to ARIN. The only other (legitimate) possibility is a section 8.3 transfer (which would require approval by ARIN also). In both an 8.2 and an 8.3 transfer, the recipient organization has to show justified need. The collection of blocks in question does not sound like it would be permitted under 8.3, so, perhaps Micr0$0ft is also acquiring part of Nortel's operations that are using those addresses as well. Owen Sent from my iPad On Mar 24, 2011, at 9:27 AM, "Aaron Wendel" wrote: > That's a good question. Maybe they can't qualify under Arin rules. Another question will be: how is Arin going to handle it? > > Im pretty sure that the RSA says that in the event of bankruptcy ips revert to the Arin pool. I understand that these were legacy addresses but....... > > Aaron > > Sent via DROID on Verizon Wireless > > -----Original message----- > From: Leo Bicknell > To: nanog at nanog.org > Sent: Thu, Mar 24, 2011 14:08:21 GMT+00:00 > Subject: Re: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million > > In a message written on Thu, Mar 24, 2011 at 09:32:21AM -0400, Bret Clark wrote: >> Why would Microsoft need this many IP's? I could see the benefitingservice providers much more. > > I think the more interesting question is why would Microsoft pay > $7.5 million for something they can, at least for the moment, get > for free. > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ > From xiaonan at ccpgames.com Thu Mar 24 11:58:48 2011 From: xiaonan at ccpgames.com (Xiaonan Xie) Date: Thu, 24 Mar 2011 12:58:48 -0400 Subject: Comcast contact for DNS issues Message-ID: <0EFF013ED11D6749B22914C55FFD49DE18541CBA1F@exchus.ccp.ad.local> Does anyone know or works for Comcast that can deal with DNS Issues? Please reply to me :) Thanks From randy at psg.com Thu Mar 24 12:08:42 2011 From: randy at psg.com (Randy Bush) Date: Thu, 24 Mar 2011 10:08:42 -0700 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <755995FD-1964-45F6-AC4C-04CF872B4571@corp.arin.net> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <755995FD-1964-45F6-AC4C-04CF872B4571@corp.arin.net> Message-ID: >>> They can only get them _at all_ if they can document need. All >>> receipt of address space, whether from the free-pool or through a >>> transfer, is needs-based. Anything else would be removing a critical >>> resource from use. >> http://en.wikipedia.org/wiki/Canute > Thank you Randy. Give Canute a community-developed set of marching > orders, and make the ocean a little more pliable and you might have > something there. at some point, the arin policy wonk weenies will face reality. or not. it really makes little difference. i don't particularly like the reality either, but i find it easier and more productive to align my actions and how i spend my time. not a lot of high paying jobs pushing water uphill. randy From joe.abley at icann.org Thu Mar 24 12:49:01 2011 From: joe.abley at icann.org (Joe Abley) Date: Thu, 24 Mar 2011 17:49:01 +0000 Subject: IN-ADDR.ARPA Nameserver Change Complete Message-ID: IN-ADDR.ARPA NAMESERVER CHANGE COMPLETE This is a courtesy notification of the completion of a change to the nameserver set for the IN-ADDR.ARPA zone. There is no expected impact on the functional operation of the DNS due to this change. There are no actions required by DNS server operators or end users. For more information about this work, please see . DETAIL The IN-ADDR.ARPA zone is used to provide reverse mapping (number to name) for IPv4. The servers which now provide authoritative DNS service for the IN-ADDR.ARPA zone are as follows: A.IN-ADDR-SERVERS.ARPA (operated by ARIN) B.IN-ADDR-SERVERS.ARPA (operated by ICANN) C.IN-ADDR-SERVERS.ARPA (operated by AfriNIC) D.IN-ADDR-SERVERS.ARPA (operated by LACNIC) E.IN-ADDR-SERVERS.ARPA (operated by APNIC) F.IN-ADDR-SERVERS.ARPA (operated by RIPE NCC) All root servers dropped the IN-ADDR.ARPA zone according to the schedule posted earlier, and all root servers now respond to queries under IN-ADDR.ARPA with an appropriate referral. Note that as part of this transition, the IN-ADDR.ARPA zone is now signed with DNSSEC and a complete chain of trust now exists from the root zone to the IN-ADDR.ARPA zone. IP6.ARPA, the corresponnding zone for IPv6 reverse mapping, was signed similarly some time ago. Regards, Joe Abley Director DNS Operations ICANN From bill at herrin.us Thu Mar 24 13:15:45 2011 From: bill at herrin.us (William Herrin) Date: Thu, 24 Mar 2011 14:15:45 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8B5ED9.605@redpill-linpro.com> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <4D8B5ED9.605@redpill-linpro.com> Message-ID: On Thu, Mar 24, 2011 at 11:10 AM, Tore Anderson wrote: > * Bill Woodcock >> They can only get them _at all_ if they can document need. ?All >> receipt of address space, whether from the free-pool or through a >> transfer, is needs-based. > > I've understood that this claim is undisputed *only* for address space > that is covered by the ARIN LRSA or any other normal RIR agreement. (I > have no idea if that is the case for this particular address space or not.) Tore, Legacy address transferability has been disputed before. Kremen v. ARIN. Kremen lost. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From drc at virtualized.org Thu Mar 24 13:18:47 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 24 Mar 2011 08:18:47 -1000 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <755995FD-1964-45F6-AC4C-04CF872B4571@corp.arin.net> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <755995FD-1964-45F6-AC4C-04CF872B4571@corp.arin.net> Message-ID: <4003FB0A-5598-4D3E-AE3E-61CF9D1AC4A0@virtualized.org> John, On Mar 24, 2011, at 5:42 AM, John Curran wrote: > As usual, I will simply point out to folks that ARIN will indeed > administer the policy as adopted, and will explain it as necessary in > various courtrooms. Oddly, when I said something similar a few years back, I was accused of attempting to 'destroy the Internet' by an ARIN board member. Out of curiosity, which policy declares 'legacy' space under ARIN administration, when was it adopted, and by whom? Regards, -drc From drc at virtualized.org Thu Mar 24 13:24:28 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 24 Mar 2011 08:24:28 -1000 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <4D8B5ED9.605@redpill-linpro.com> Message-ID: On Mar 24, 2011, at 8:15 AM, William Herrin wrote: > Legacy address transferability has been disputed before. Kremen v. > ARIN. Kremen lost. Yes, Kremen lost, but not based on anything related to address policy: http://blog.ericgoldman.org/archives/2007/01/kremen_loses_ch_1.htm Regards, -drc From ernesto at cs.fiu.edu Thu Mar 24 13:32:58 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 24 Mar 2011 14:32:58 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <4D8B5ED9.605@redpill-linpro.com> Message-ID: Agreed, Look at: http://ciara.fiu.edu/publications/Rubi%20-%20Property%20Rights%20in%20IP%20Numbers.pdf Even assuming Kremen was decided as ARIN says; United States District Courts can and do disagree. On Mar 24, 2011, at 2:24 PM, David Conrad wrote: > Yes, Kremen lost, but not based on anything related to address policy: From zaid at zaidali.com Thu Mar 24 13:42:28 2011 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 24 Mar 2011 11:42:28 -0700 Subject: Regional AS model Message-ID: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. Zaid From bill at herrin.us Thu Mar 24 14:05:51 2011 From: bill at herrin.us (William Herrin) Date: Thu, 24 Mar 2011 15:05:51 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <4D8B5ED9.605@redpill-linpro.com> Message-ID: On Thu, Mar 24, 2011 at 2:32 PM, Ernie Rubi wrote: > ?http://ciara.fiu.edu/publications/Rubi%20-%20Property%20Rights%20in%20IP%20Numbers.pdf > Even assuming Kremen was decided as ARIN says; United States District Courts > can and do disagree. Hi Ernie, The case you refer to was a dispute about a trademark which the a particular domain name infringed. The court's theory was that the property right in the trademark (well documented in law) covered the domain name too (fresh precedent). So while a court could disagree about IP addresses, it's not really accurate to say that one has. As you acknowledge in your paper, no such extension of existing intellectual property law has been proposed to cover any particular formulation of integers, including IP addresses. At least within the US, article I section 8 clause 8 would seem to preclude the courts from recognizing intellectual property outside the rationally extensible bounds of what the congress has defined. So it's not really clear under what theory of property law a court would choose to compel ARIN to transfer a legacy registration while retaining legacy status. Indeed, you point out that in a similar situation - telephone numbers - the courts have steadfastly refused to recognize a property interest. Finally, in the case you refer to, the result was a change in party in an explicit signed contract. No such document has been executed between ARIN and the legacy registrants or between those registrants and ARIN's predecessors. The absence of any such legal instrument sets a high bar indeed for anyone attempting to compel ARIN to change a registration outside the course of ARIN's normal policy-defined process. It can't even be tortious interference as the parties knew or should have known ARIN's stance before they began talking. Now, if congress tomorrow passes a bill that says IP addresses are a new form of intellectual property then they're property henceforward and the legal regime underpinning ARIN falls apart. But that hasn't happened yet. It hasn't even been proposed. On a technical note, your URLs will work more reliably if you don't put spaces in the file names. Although Google Gmail is probably the party at fault, your URL got translated to "+"'s instead of spaces. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From aaron at wholesaleinternet.net Thu Mar 24 14:07:53 2011 From: aaron at wholesaleinternet.net (aaron at wholesaleinternet.net) Date: Thu, 24 Mar 2011 15:07:53 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8B5ED6.3040604@merit.edu> References: "\"<20110324125757.GG23560@leitl.org>" " <20110324140636.GA28981@gweep.net> <4D8B5ED6.3040604@merit.edu> Message-ID: On Thu, 24 Mar 2011 11:10:14 -0400, Larry Blunk wrote: > On 03/24/2011 10:06 AM, Joe Provo wrote: >> On Thu, Mar 24, 2011 at 01:27:29PM +0000, Tony Finch wrote: >>> Jay Nakamura wrote: >>> >>>> 666,624 is kind of odd number, isn't it? That comes out to a >>>> /13,/15,/19,/21 and a /22. >>> > From the court documents I gather that it is a collection of >>> miscellaneous >>> blocks that Nortel acquired over the years, presumable via >>> corporate M&A. >>> However there isn't (as far as I can see) a list of the actual >>> blocks. See >>> docket 5143 at >>> http://chapter11.epiqsystems.com/NNI/docket/Default.aspx >> >> Exhibit B expressly indicates they were listed but filed under seal; >> interesting to request that. Previous documents indicate they used >> a >> third party to shop things around, who got a $200k retainer and is >> getting paid 5% of the sale. >> > > Docket #4435, Exhibit B has more information on the IP address > broker, Addrex, Inc., of Reston, Va. Here's the president and > related companies -- > > http://www.linkedin.com/pub/charles-m-lee/22/414/a94 > http://www.denuo.com > http://www.addrex.net > http://www.depository.net I actually dug back through the thread to find this e-mail. I particularly find the last link of interest. Aaron From owen at delong.com Thu Mar 24 14:26:54 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Mar 2011 13:26:54 -0600 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8B57DB.7080602@redpill-linpro.com> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> Message-ID: <360C7B4D-AF9F-43A1-955E-4E188AA614A3@delong.com> Sent from my iPad On Mar 24, 2011, at 8:40 AM, Tore Anderson wrote: > * Leo Bicknell > >> I think the more interesting question is why would Microsoft pay >> $7.5 million for something they can, at least for the moment, get >> for free. > > A very interesting question indeed! > > However, they can only get them for free from ARIN if they can document > an immediate demand. Perhaps they don't have an immediate demand, and > are simply stockpiling addresses for later use post ARIN depletion? Or > perhaps they hope to make a profit then by selling them to someone else. > > Either way, it sure seems they're speculating that the market price of > an IPv4 address is going to rise to more than US$11.25. > > -- > Tore Anderson > Redpill Linpro AS - http://www.redpill-linpro.com > Tel: +47 21 54 41 27 If they are stockpiling and can't justify need, they are doing so outside of ARIN policy and I will be surprised if that doesn't get challenged by ARIN. Owen From bill at herrin.us Thu Mar 24 14:29:34 2011 From: bill at herrin.us (William Herrin) Date: Thu, 24 Mar 2011 15:29:34 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <20110324140636.GA28981@gweep.net> <4D8B5ED6.3040604@merit.edu> Message-ID: On Thu, Mar 24, 2011 at 3:07 PM, wrote: > On Thu, 24 Mar 2011 11:10:14 -0400, Larry Blunk wrote: >> On 03/24/2011 10:06 AM, Joe Provo wrote: >>> Exhibit B expressly indicates they were listed but filed under seal; >>> interesting to request that. ?Previous documents indicate they used a >>> third party to shop things around, who got a $200k retainer and is >>> getting paid 5% of the sale. >> >> ? Docket #4435, Exhibit B has more information on the IP address >> broker, Addrex, Inc., of Reston, Va. ? Here's the president and >> related companies -- >> >> http://www.linkedin.com/pub/charles-m-lee/22/414/a94 >> http://www.denuo.com >> http://www.addrex.net >> http://www.depository.net > > I actually dug back through the thread to find this e-mail. ?I particularly > find the last link of interest. So -that's- why Peter Thimmesch was privately contacting ARIN PPML posters last month. I wondered what the guy hoped to gain; he was trying to establish legitimacy for depository.net in support of this sale. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From owen at delong.com Thu Mar 24 14:28:36 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Mar 2011 13:28:36 -0600 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <7161.1300977834@localhost> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <667a9870-5a8c-4344-991c-60ac024d3dd5@blur> <7161.1300977834@localhost> Message-ID: <093D3C8F-E8A5-491B-8110-8818599B1D8E@delong.com> Sent from my iPad On Mar 24, 2011, at 8:43 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 24 Mar 2011 09:27:58 CDT, Aaron Wendel said: >> That's a good question. Maybe they can't qualify under Arin rules. Another > >> question will be: how is Arin going to handle it? >> >> Im pretty sure that the RSA says that in the event of bankruptcy ips revert >> to the Arin pool. I understand that these were legacy addresses but....... > > The *important* question is - do they *remain* legacy addresses under the > legacy address rules after the Microsoft acquisition, and thus re-sellable at a > later date? If so, we may have seen the first case of IP address speculation, > and the start of the bubble. I don't want to see how this bubble bursts.. > In order for the transfer to be recognized by ARIN, they would not be able to remain legacy addresses. However, nothing in ARIN policy precludes resale of transferred addresses at a later date. What it does preclude, however, is acquiring the addresses without justified need. Owen From Valdis.Kletnieks at vt.edu Thu Mar 24 14:41:05 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 24 Mar 2011 15:41:05 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: Your message of "Thu, 24 Mar 2011 14:15:45 EDT." References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <4D8B5ED9.605@redpill-linpro.com> Message-ID: <23786.1300995665@localhost> On Thu, 24 Mar 2011 14:15:45 EDT, William Herrin said: > Legacy address transferability has been disputed before. Kremen v. > ARIN. Kremen lost. Yes, but Microsoft's lawyers can probably beat up ARIN's lawyers. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From owen at delong.com Thu Mar 24 14:40:23 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Mar 2011 13:40:23 -0600 Subject: Regional AS model In-Reply-To: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> Message-ID: Sent from my iPad On Mar 24, 2011, at 12:42 PM, Zaid Ali wrote: > I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. > > Zaid If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable. Owen From ernesto at cs.fiu.edu Thu Mar 24 14:43:58 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 24 Mar 2011 15:43:58 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <4D8B5ED9.605@redpill-linpro.com> Message-ID: Alright, how about this - let's wait and see what the bankruptcy judge says. Which firm do you practice for? On Mar 24, 2011, at 3:05 PM, William Herrin wrote: > On Thu, Mar 24, 2011 at 2:32 PM, Ernie Rubi wrote: >> http://ciara.fiu.edu/publications/Rubi%20-%20Property%20Rights%20in%20IP%20Numbers.pdf >> Even assuming Kremen was decided as ARIN says; United States District Courts >> can and do disagree. > > Hi Ernie, > > The case you refer to was a dispute about a trademark which the a > particular domain name infringed. The court's theory was that the > property right in the trademark (well documented in law) covered the > domain name too (fresh precedent). So while a court could disagree > about IP addresses, it's not really accurate to say that one has. > From bill at herrin.us Thu Mar 24 15:46:10 2011 From: bill at herrin.us (William Herrin) Date: Thu, 24 Mar 2011 16:46:10 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <4D8B5ED9.605@redpill-linpro.com> Message-ID: On Thu, Mar 24, 2011 at 3:43 PM, Ernie Rubi wrote: > Alright, how about this - let's wait and see what the bankruptcy judge says. With bated breath. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From patrick at ianai.net Thu Mar 24 15:47:24 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 24 Mar 2011 16:47:24 -0400 Subject: Regional AS model In-Reply-To: References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> Message-ID: <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote: > On Mar 24, 2011, at 12:42 PM, Zaid Ali wrote: > >> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. >> >> Zaid > > If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable. We disagree. Single AS worldwide is fine with or without a backbone. Which is "preferable" is up to you, your situation, and your personal tastes. (I guess one could argue that wasting AS numbers, or polluting the table with lots of AS numbers is bad or un-ashetically pleasing, but I think you should do whatever fits your situation anyway.) -- TTFN, patrick From chort at smtps.net Thu Mar 24 09:34:20 2011 From: chort at smtps.net (Brian Keefer) Date: Thu, 24 Mar 2011 07:34:20 -0700 Subject: The state-level attack on the SSL CA security model In-Reply-To: <4D8B5089.4010507@pobox.com> References: <4D8B5089.4010507@pobox.com> Message-ID: <65D98869-29C6-4CB5-9264-086F5E535E70@smtps.net> On Mar 24, 2011, at 7:09 AM, Harald Koch wrote: > On 3/23/2011 11:05 PM, Martin Millnert wrote: >> To my surprise, I did not see a mention in this community of the >> latest proof of the complete failure of the SSL CA model to actually >> do what it is supposed to: provide security, rather than a false sense >> of security. > > This story strikes me as a success - the certs were revoked immediately, and it took a surprisingly short amount of time for security fixes to appear all over the place. > > > -- > Harald I'd hardly call the fact that it required manual blacklist patches to every browser a "success". SSL is a failure if real revocation requires creating a patch for browsers and relying on users to install it. -- bk From young at jsyoung.net Thu Mar 24 16:08:42 2011 From: young at jsyoung.net (Jeffrey S. Young) Date: Fri, 25 Mar 2011 08:08:42 +1100 Subject: Regional AS model In-Reply-To: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> Message-ID: <2D7D3C28-C77A-46CC-AB52-55F9D9EFE973@jsyoung.net> Multiple AS, one per region, is about extracting maximum revenue from your client base. In 2000 we had no technical reason to do it, I can't see a technical reason to do it today. This is a layer 8/9 issue. jy On 25/03/2011, at 5:42 AM, Zaid Ali wrote: > I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. > > Zaid From woody at pch.net Thu Mar 24 16:26:35 2011 From: woody at pch.net (Bill Woodcock) Date: Thu, 24 Mar 2011 14:26:35 -0700 Subject: Regional AS model In-Reply-To: <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> Message-ID: <87675028-2B60-4A52-8EC7-0CDD010CEAF8@pch.net> On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote: > On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote: >> On Mar 24, 2011, at 12:42 PM, Zaid Ali wrote: >> >>> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. >> >> If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable. > > We disagree. > Single AS worldwide is fine with or without a backbone. > Which is "preferable" is up to you, your situation, and your personal tastes. We're with Patrick on this one. We operate a single AS across seventy-some-odd locations in dozens of countries, with very little of what an eyeball operator would call "backbone" between them, and we've never seen any potential benefit from splitting them. I think the management headache alone would be sufficient to make it unattractive to us. -Bill From rdobbins at arbor.net Thu Mar 24 16:33:27 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Thu, 24 Mar 2011 21:33:27 +0000 Subject: The state-level attack on the SSL CA security model In-Reply-To: <8239mchkc5.fsf@mid.bfk.de> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <8239mchkc5.fsf@mid.bfk.de> Message-ID: <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> On Mar 24, 2011, at 6:41 PM, Florian Weimer wrote: > Disclosure devalues information. I think this case is different, given the perception of the cert as a 'thing' to be bartered. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From franck at genius.com Thu Mar 24 16:39:16 2011 From: franck at genius.com (Franck Martin) Date: Fri, 25 Mar 2011 09:39:16 +1200 (MHT) Subject: The state-level attack on the SSL CA security model In-Reply-To: <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> Message-ID: <27726811.0.1301002752950.JavaMail.franck@Macintosh-3.local> ----- Original Message ----- > From: "Roland Dobbins" > To: "nanog group" > Sent: Friday, 25 March, 2011 9:33:27 AM > Subject: Re: The state-level attack on the SSL CA security model > On Mar 24, 2011, at 6:41 PM, Florian Weimer wrote: > > > Disclosure devalues information. > > > I think this case is different, given the perception of the cert as a > 'thing' to be bartered. > Isn't there any law that obliges company to disclose security breaches that involve consumer data? From george.herbert at gmail.com Thu Mar 24 16:44:52 2011 From: george.herbert at gmail.com (George Herbert) Date: Thu, 24 Mar 2011 14:44:52 -0700 Subject: The state-level attack on the SSL CA security model In-Reply-To: <27726811.0.1301002752950.JavaMail.franck@Macintosh-3.local> References: <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> <27726811.0.1301002752950.JavaMail.franck@Macintosh-3.local> Message-ID: On Thu, Mar 24, 2011 at 2:39 PM, Franck Martin wrote: > > > ----- Original Message ----- >> From: "Roland Dobbins" >> To: "nanog group" >> Sent: Friday, 25 March, 2011 9:33:27 AM >> Subject: Re: The state-level attack on the SSL CA security model >> On Mar 24, 2011, at 6:41 PM, Florian Weimer wrote: >> >> > ?Disclosure devalues information. >> >> >> I think this case is different, given the perception of the cert as a >> 'thing' to be bartered. >> > > Isn't there any law that obliges company to disclose security breaches that involve consumer data? I don't think SSL certs are consumer data, per se. Back on original point - if the *actual effective* model of browser security is browsers with an internal revoked cert list - then there's a case to be made that a pre-announcement in private to the browser vendors, enough time for them to spin patches, and then widespread public discussion is the most responsible model approach. The public knowing before their browser knows how to handle the bad cert isn't helpful, unless you can effectively tell people how to get their browser to actually go verify every cert. -- -george william herbert george.herbert at gmail.com From drc at virtualized.org Thu Mar 24 16:45:43 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 24 Mar 2011 11:45:43 -1000 Subject: Regional AS model In-Reply-To: <2D7D3C28-C77A-46CC-AB52-55F9D9EFE973@jsyoung.net> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <2D7D3C28-C77A-46CC-AB52-55F9D9EFE973@jsyoung.net> Message-ID: <7BDE4472-B1CC-420C-900C-A3D86E79A289@virtualized.org> On Mar 24, 2011, at 11:08 AM, Jeffrey S. Young wrote: > Multiple AS, one per region, is about extracting maximum revenue from > your client base. In 2000 we had no technical reason to do it, I can't see > a technical reason to do it today. This is a layer 8/9 issue. http://tools.ietf.org/html/draft-mcpherson-unique-origin-as-00 Regards, -drc From graham at g-rock.net Thu Mar 24 16:51:06 2011 From: graham at g-rock.net (Graham Wooden) Date: Thu, 24 Mar 2011 16:51:06 -0500 Subject: Regional AS model In-Reply-To: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> Message-ID: <20110324165106.we0qcxz88cck4ckc@webmail.g-rock.net> Quoting Zaid Ali : > I have seen age old discussions on single AS vs multiple AS for > backbone and datacenter design. I am particularly interested in > operational challenges for running AS per region e.g. one AS for US, > one EU etc or I have heard folks do one AS per DC. I particularly > don't see any advantage in doing one AS per region or datacenter > since most of the reasons I hear is to reduce the iBGP mesh. I > generally prefer one AS and making use of confederation. > > Zaid > Hi Zaid, What timing - this is fresh on my mind too as I am in the middle of doing this myself with three locations, all with independent edges with different transit providers. I actually do have a private Layer2 circuit between, with one site being in the middle. I only have one public AS, but I have selected doing the confederation approach (which some may consider to be overkill with only three edges). Each site has their own set of IPs and would originate out of their respective edge, and using EIGRP metric changes at each core to get 0.0.0.0/0 from another edge if the local fails. Each edge is then announcing each others' subnets with an extra pad or two to keep the asymmetrical routing down (the private L2 isn't as fast as my transits). Good luck with your deployment! -graham From danny at tcb.net Thu Mar 24 17:11:12 2011 From: danny at tcb.net (Danny McPherson) Date: Thu, 24 Mar 2011 18:11:12 -0400 Subject: Regional AS model In-Reply-To: <7BDE4472-B1CC-420C-900C-A3D86E79A289@virtualized.org> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <2D7D3C28-C77A-46CC-AB52-55F9D9EFE973@jsyoung.net> <7BDE4472-B1CC-420C-900C-A3D86E79A289@virtualized.org> Message-ID: On Mar 24, 2011, at 5:45 PM, David Conrad wrote: > On Mar 24, 2011, at 11:08 AM, Jeffrey S. Young wrote: >> Multiple AS, one per region, is about extracting maximum revenue from >> your client base. In 2000 we had no technical reason to do it, I can't see >> a technical reason to do it today. This is a layer 8/9 issue. > > http://tools.ietf.org/html/draft-mcpherson-unique-origin-as-00 Latest is here (which still needs a few minor comments incorporated): And the operative bits relative to this discussion are provided in the title: "Unique Per-Node Origin ASNs for Globally Anycasted Services" -danny From m.hallgren at free.fr Thu Mar 24 17:17:03 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Thu, 24 Mar 2011 23:17:03 +0100 Subject: Regional AS model In-Reply-To: <87675028-2B60-4A52-8EC7-0CDD010CEAF8@pch.net> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <87675028-2B60-4A52-8EC7-0CDD010CEAF8@pch.net> Message-ID: <1301005023.2933.14.camel@home> Le jeudi 24 mars 2011 ? 14:26 -0700, Bill Woodcock a ?crit : > On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote: > > On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote: > >> On Mar 24, 2011, at 12:42 PM, Zaid Ali wrote: > >> > >>> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. > >> > >> If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable. > > > > We disagree. > > Single AS worldwide is fine with or without a backbone. > > Which is "preferable" is up to you, your situation, and your personal tastes. > > > We're with Patrick on this one. We operate a single AS across seventy-some-odd locations in dozens of countries, with very little of what an eyeball operator would call "backbone" between them, and we've never seen any potential benefit from splitting them. I think the management headache alone would be sufficient to make it unattractive to us. > > -Bill > > Right. I think that a single AS is most often quite fine. I think our problem space is rather about how you organise the routing in your AS. Flat, route-reflection, confederations? How much policing between regions do you feel that you need? In some scenarios, I think confederations may be a pretty sound replacement of the multiple-AS approach. Policing iBGP sessions in a route-reflector topology? Limits? Thoughts? Cheers, mh > > > > From danny at spesh.com Thu Mar 24 17:29:13 2011 From: danny at spesh.com (Danny O'Brien) Date: Thu, 24 Mar 2011 15:29:13 -0700 Subject: The state-level attack on the SSL CA security model In-Reply-To: <4D8B5089.4010507@pobox.com> References: <4D8B5089.4010507@pobox.com> Message-ID: On Thu, Mar 24, 2011 at 7:09 AM, Harald Koch wrote: > On 3/23/2011 11:05 PM, Martin Millnert wrote: >> >> To my surprise, I did not see a mention in this community of the >> latest proof of the complete failure of the SSL CA model to actually >> do what it is supposed to: provide security, rather than a false sense >> of security. > > This story strikes me as a success - the certs were revoked immediately, and > it took a surprisingly short amount of time for security fixes to appear all > over the place. > >> ?In some places, failure of internet security means people die > > Those people know that using highly visible services like gmail and skype is > asking to be exposed... This is definitively not true. There is no evidence of the active use of these services (or circumvention systems to reach them) being used as evidence or an indication that a particular target should be detained, threatened or punished, in Iran in particular and actually globally. I say this, because such evidence would actually reinforce some security recommendations that I and other human rights groups have made, so I'm always on the look out for it. On the other hand, both gmail and Skype are used by many individuals on the assumption that they are more secure than the alternatives (non-SSL protected webmail or those with servers in local jurisdictions; unencrypted instant messaging clients). You can argue about whether these tools *are* more protective, but you certainly can't say that these high-risk groups use them on the understanding they can expect the same level of knowledge or retribution by their adversaries than if these systems were openly surveillable. A security breach like this makes the details of specific communications readable, which also places people who do *not* use these tools at far more risk also. I'm personally not yet convinced that the attackers in this case were the Iranian state; that's something that is incredibly hard to ascertain, and I'm surprised Comodo were so quick to draw this conclusion. Even if these attacks came from Iran, that could be for false flag reasons, plus as others have pointed out, criminals have as much interest in obtaining these certificates as the Iranian state -- although factions within the Iranian government could certainly be potential clients. Other states might have an interest too. Just because you have an organisation with CA authority within the reach of a government doesn't mean you'd want to use those signing powers when dealing with dissidents. The arguments on NANOG about why non-disclosure in this case might have been a good idea I think contribute to the debate. Nonetheless, I'd strongly urge anyone not to assume that activists and journalists at physical risk in states like Iran assume that risk by using specific tools, or that major (if temporary) failures in the PKI structure don't put them and their colleagues at far greater risk. Best, d. Danny O'Brien, Committee to Protect Journalists https://cpj.org/internet > > -- > Harald > > > > From owen at delong.com Thu Mar 24 15:26:32 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 24 Mar 2011 14:26:32 -0600 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <4D8B5ED9.605@redpill-linpro.com> Message-ID: <986BA7D8-D699-4D93-9FCC-6F44FEB52ED7@delong.com> The judge definitely ruled that the transfer had to be done in a manner that complied with ARIN policy and made it clear that the recipient was, indeed, required to sign the RSA. So, yes, Kremen also lost on the address policy basis, which I believe may have been an additional ruling subsequent to what is covered at the cited URL. Owen Sent from my iPad On Mar 24, 2011, at 12:24 PM, David Conrad wrote: > On Mar 24, 2011, at 8:15 AM, William Herrin wrote: >> Legacy address transferability has been disputed before. Kremen v. >> ARIN. Kremen lost. > > Yes, Kremen lost, but not based on anything related to address policy: > > http://blog.ericgoldman.org/archives/2007/01/kremen_loses_ch_1.htm > > Regards, > -drc > From drc at virtualized.org Thu Mar 24 18:19:56 2011 From: drc at virtualized.org (David Conrad) Date: Thu, 24 Mar 2011 13:19:56 -1000 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <986BA7D8-D699-4D93-9FCC-6F44FEB52ED7@delong.com> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <4D8B5ED9.605@redpill-linpro.com> <986BA7D8-D699-4D93-9FCC-6F44FEB52ED7@delong.com> Message-ID: <0D2AF4B6-23D4-49FA-82CC-EB9D28EFEF17@virtualized.org> Owen, I (and I presume Eric Goldman, author of the post I referenced) was looking at Judge James Ware's actual ruling (http://docs.justia.com/cases/federal/district-courts/california/candce/5:2006cv02554/181054/41/). I don't see anything in there discussing that 'the transfer had to be done in a manner that complied with ARIN policy' or Kremen was 'required to sign the RSA'. It isn't a very long document (and surprisingly easy to read for a court judgement). Not being a lawyer, I can't be certain, but all I see is "time-barred" and "statute of limitations". The only thing relevant I can see in subsequent filings is that Kremen and ARIN came to a settlement in which ARIN didn't have to do anything and Kremen wouldn't pursue the matter. Can you point to where the Judge said anything (much less definitively) about complying with ARIN policy, signing an RSA, etc.? Regards, -drc On Mar 24, 2011, at 10:26 AM, Owen DeLong wrote: > The judge definitely ruled that the transfer had to be done in a manner that > complied with ARIN policy and made it clear that the recipient was, indeed, > required to sign the RSA. > > So, yes, Kremen also lost on the address policy basis, which I believe may > have been an additional ruling subsequent to what is covered at the cited URL. > > Owen > > > Sent from my iPad > > On Mar 24, 2011, at 12:24 PM, David Conrad wrote: > >> On Mar 24, 2011, at 8:15 AM, William Herrin wrote: >>> Legacy address transferability has been disputed before. Kremen v. >>> ARIN. Kremen lost. >> >> Yes, Kremen lost, but not based on anything related to address policy: >> >> http://blog.ericgoldman.org/archives/2007/01/kremen_loses_ch_1.htm >> >> Regards, >> -drc >> > From raramasw at gmail.com Thu Mar 24 18:27:08 2011 From: raramasw at gmail.com (Ravi Ramaswamy) Date: Thu, 24 Mar 2011 19:27:08 -0400 Subject: Peering Traffic Volume Message-ID: Hi All - I am new to this mailer. Hopefully my question is posed to the correct list. I am using 2.5 Tbps as the peak volume of peering traffic over all peering points for a Tier 1 ISP, for some modeling purposes. Is that a reasonable estimate? Thanks Ravi From young at jsyoung.net Thu Mar 24 18:50:19 2011 From: young at jsyoung.net (Jeffrey S. Young) Date: Fri, 25 Mar 2011 10:50:19 +1100 Subject: Regional AS model In-Reply-To: <7BDE4472-B1CC-420C-900C-A3D86E79A289@virtualized.org> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <2D7D3C28-C77A-46CC-AB52-55F9D9EFE973@jsyoung.net> <7BDE4472-B1CC-420C-900C-A3D86E79A289@virtualized.org> Message-ID: <292C1283-B966-4184-A497-34DF6F8801AF@jsyoung.net> While it's a very interesting read and it's always nice to know what Danny is up to, the concept is a pretty extreme corner case when you consider the original question. I took the original question to be about global versus regional AS in a provider backbone. On the other hand if we'd had this capability years ago the notion of a CDN based on anycasting would be viable in a multi-provider environment. Maybe time to revive that idea? jy On 25/03/2011, at 8:45 AM, David Conrad wrote: > On Mar 24, 2011, at 11:08 AM, Jeffrey S. Young wrote: >> Multiple AS, one per region, is about extracting maximum revenue from >> your client base. In 2000 we had no technical reason to do it, I can't see >> a technical reason to do it today. This is a layer 8/9 issue. > > http://tools.ietf.org/html/draft-mcpherson-unique-origin-as-00 > > Regards, > -drc > > From jsw at inconcepts.biz Thu Mar 24 19:03:32 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 24 Mar 2011 20:03:32 -0400 Subject: Regional AS model In-Reply-To: <20110324165106.we0qcxz88cck4ckc@webmail.g-rock.net> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <20110324165106.we0qcxz88cck4ckc@webmail.g-rock.net> Message-ID: On Thu, Mar 24, 2011 at 5:51 PM, Graham Wooden wrote: > with one site being in the middle. I only have one public AS, but I have > selected doing the confederation approach (which some may consider to be > overkill with only three edges). There are really several issues to consider, one of which certainly is "overkill," but the others are: 1) in your case, you have to run allowas-in *anyway* because if your transport or your "middle POP" goes down, so will your network and its customers; so confederating isn't really buying you anything unless your backbone is really vendor L3VPN 2) confederating / clustering can add to MED headaches and similar While this is not directed at your deployment specifically, it is a common newbie mistake to confederate something that doesn't need to be, or to otherwise complicate your backbone because you think you need to turn knobs to prepare for future growth. Guess what, that growth might happen later on, but if you don't understand emergent properties of your knob-turning, your plan for the future is really a plan to fail, as you'll have to re-architect your network at some point anyway, probably right when you need that scalability you thought you engineered in early-on. List readers should be strongly discouraged from confederating unless they know they need to, understand its benefits, and understand its potential weaknesses. In general, a network with effectively three or six routers should never have a confederated backbone. The number of guys who really understand confederating / route-reflection within the backbone is very small compared to the number of guys who *think* they are knowledgeable about everything that falls under "router bgp," our beloved inter-domain routing protocol which gives the operator plenty of rope with which to hang himself (or the next guy who holds his job after he moves on.) On Thu, Mar 24, 2011 at 7:50 PM, Jeffrey S. Young wrote: > On the other hand if we'd had this capability years ago the notion > of a CDN based on anycasting would be viable in a multi-provider > environment. ?Maybe time to revive that idea? That draft doesn't identify any particular technical challenges to originating a prefix from multiple discrete origin ASNs other than the obvious fact that they'll show up in the various "inconsistent origin AS" reports such as CIDR Report, etc. It of course does identify some advantages to doing it. I imagine Danny McPherson and his colleagues have spent some time looking into this, and can probably say with confidence that there are in fact no real challenges to doing it today besides showing up in some weekly email as a possible anomaly. It seems to be a taboo topic, but once a few folks start doing it, I think it'll quickly become somewhat normal. Note that in the current IRR routing information system, it is possible to publish two route objects, each with the same prefix, and each with a different origin ASN. This is by design. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From millnert at gmail.com Thu Mar 24 19:25:15 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 24 Mar 2011 20:25:15 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> Message-ID: List, since there are IRR databases operated by non-RIRs, does one need to register a prefix in any RIR-DB at all, to see it reachable on the Internet? Have there been any presentations/research done on reachability of RIR-registered vs non-RIR-registered vs completely unregistered announcements? ( When I say RPKI below I mean the entire secure BGP routing infrastructure developments. ) I think it is pretty clear what the greatest motivation from RIRs on RPKI is: (Unregistered) legacy v4-space (ie, reaching a critical mass so that the network effect starts to apply positively for the reachability of non-RIR-registered space. John Currant has written on RPKI = certification of RIR-DB contents on this list before, but that could in all seriousness be equally accomplished simply by having a usable and trusted API-connection to query the DB itself. And that I think hardly anyone would oppose. (AFAIK ARIN has already deployed this by now; and as soon as their services has some sort of authentication (DNSSEC'ed DNS with SSL cert in it, for example? It's ~trivial to program a client for this!) a lot will have been accomplished already! What's different and unique with the RPKI effort is that it integrates this information directly into BGP itself, in an effort to claim control on what's being announced on the Internet. The former I welcome warmly, while the latter I think it remains to be seen how successful it will be. Regards, Martin On Thu, Mar 24, 2011 at 11:35 AM, John Curran wrote: > On Mar 24, 2011, at 8:57 AM, Eugen Leitl wrote: > >> http://blog.internetgovernance.org/blog/_archives/2011/3/23/4778509.html > > Read the comment at the end (attached here for reference). > /John > > John Curran > President and CEO > ARIN > > ---- >> Re: Nortel, in bankruptcy, Requests Approval of Sale of IPv4 address blocks >> by John Curran on Thu 24 Mar 2011 11:31 AM EDT | ?Profile | ?Permanent Link >> >> Milton - >> >> Did you have an opportunity to review the actual docket materials, or is your "coverage" based just on your review of the referenced article? >> >> The parties have requested approval of a sale order from the Bankruptcy judge. There is a timeline for making filings and a hearing date. There is not an approved sale order at this time, contrary to your blog entry title. >> >> ARIN has a responsibility to make clear the community-developed policies by which we maintain the ARIN Whois database, and any actual transfer of number resources in compliance with such policies will be reflected in the database. >> >> FYI, >> /John > > > From nathan at atlasnetworks.us Thu Mar 24 19:28:23 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 25 Mar 2011 00:28:23 +0000 Subject: Google Geolocation Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3E70A4@ex-mb-1.corp.atlasnetworks.us> Would someone from Google please contact me offlist? You're geolocating some of $DAYJOB's IP space to the Netherlands, and I'm not sure how to fix it. Sadly, very few of my $DAYJOB's customers in Seattle are fluent in Dutch. (If there's an obvious form somewhere to fix this, and I missed it, then I apologize for the useless post!) Nathan From andy at andy.net Thu Mar 24 19:54:25 2011 From: andy at andy.net (Andy Warner) Date: Thu, 24 Mar 2011 17:54:25 -0700 Subject: Google Geolocation In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3E70A4@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B3E70A4@ex-mb-1.corp.atlasnetworks.us> Message-ID: On Thu, Mar 24, 2011 at 5:28 PM, Nathan Eisenberg wrote: > Would someone from Google please contact me offlist? ?You're geolocating some of $DAYJOB's IP space to the Netherlands, and I'm not sure how to fix it. ?Sadly, very few of my $DAYJOB's customers in Seattle are fluent in Dutch. > > (If there's an obvious form somewhere to fix this, and I missed it, then I apologize for the useless post!) > > Nathan http://www.google.com/support/websearch/bin/answer.py?hl=en&answer=873 From wschultz at bsdboy.com Thu Mar 24 20:00:09 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Thu, 24 Mar 2011 18:00:09 -0700 Subject: Google Geolocation In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3E70A4@ex-mb-1.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C286B3E70A4@ex-mb-1.corp.atlasnetworks.us> Message-ID: <8B69CF5B-6509-4810-9C4A-1791D1047F5F@bsdboy.com> Definitely been going on for a while now. http://seclists.org/nanog/2011/Mar/108 Here's some more information: http://www.google.com/support/websearch/bin/answer.py?answer=873 Basically, going to www.google.com/ncs will enable No Country Redirect. -wil On Mar 24, 2011, at 5:28 PM, Nathan Eisenberg wrote: > Would someone from Google please contact me offlist? You're geolocating some of $DAYJOB's IP space to the Netherlands, and I'm not sure how to fix it. Sadly, very few of my $DAYJOB's customers in Seattle are fluent in Dutch. > > (If there's an obvious form somewhere to fix this, and I missed it, then I apologize for the useless post!) > > Nathan > > From bensons at queuefull.net Thu Mar 24 20:13:46 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Mar 2011 20:13:46 -0500 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> Message-ID: Hi, John. On Mar 24, 2011, at 10:35 AM, John Curran wrote: >> http://blog.internetgovernance.org/blog/_archives/2011/3/23/4778509.html > > Read the comment at the end (attached here for reference). >> Did you have an opportunity to review the actual docket materials, or is your "coverage" based just on your review of the referenced article? >> >> The parties have requested approval of a sale order from the Bankruptcy judge. There is a timeline for making filings and a hearing date. There is not an approved sale order at this time, contrary to your blog entry title. >> >> ARIN has a responsibility to make clear the community-developed policies by which we maintain the ARIN Whois database, and any actual transfer of number resources in compliance with such policies will be reflected in the database. At your suggestion, I went to the IGP blog and read the last comment. I see there is a response by Ernie Rubi to your blog comment, which captures my question so well that (with apologies to Mr Rubi) I'll quote him: "1) a non-party to a bankruptcy proceeding can intervene in a purported asset sale during said proceeding if they have an interest (i.e property-type) in the asset. 2) ARIN's position is that there is no property interest in IP addresses (LRSA, RSA, etc)." I would add that ARIN, as a non-profit business league, has no statutory or regulatory authority in this matter. It's obvious that ARIN, as well as other whois database providers, should pay attention to the proceedings. But under what premise might ARIN act as a party to this lawsuit? Cheers, -Benson From cdl at asgaard.org Thu Mar 24 20:24:03 2011 From: cdl at asgaard.org (Christopher LILJENSTOLPE) Date: Fri, 25 Mar 2011 12:24:03 +1100 Subject: Regional AS model In-Reply-To: <1301005023.2933.14.camel@home> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <87675028-2B60-4A52-8EC7-0CDD010CEAF8@pch.net> <1301005023.2933.14.camel@home> Message-ID: <4B688E41-DBC8-4E2C-9CE5-8D89E8A0FFE1@asgaard.org> On 25Mar2011, at 09.17, Michael Hallgren wrote: > Le jeudi 24 mars 2011 ? 14:26 -0700, Bill Woodcock a ?crit : >> On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote: >>> On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote: >>>> On Mar 24, 2011, at 12:42 PM, Zaid Ali wrote: >>>> >>>>> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. >>>> >>>> If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable. >>> >>> We disagree. >>> Single AS worldwide is fine with or without a backbone. >>> Which is "preferable" is up to you, your situation, and your personal tastes. >> >> >> We're with Patrick on this one. We operate a single AS across seventy-some-odd locations in dozens of countries, with very little of what an eyeball operator would call "backbone" between them, and we've never seen any potential benefit from splitting them. I think the management headache alone would be sufficient to make it unattractive to us. Experience with a major backbone in the early 2000's that spanned 50 core sites and 4 continents - single AS is not really a problem. We chose IS-IS with wide metrics as the IGP, and one-layer of route-reflection for the bgp mesh control. The only reason I could possibly see doing multi-AS in a general case is if your route policies are different in different regions (i.e. in one region a peer AS is a 'peer' and in another region the same AS is a 'transit' or 'upstream'). You CAN do it with a single AS, but it's more painful... >> >> -Bill >> >> > > Right. I think that a single AS is most often quite fine. I think our > problem space is rather about how you organise the routing in your AS. > Flat, route-reflection, confederations? How much policing between > regions do you feel that you need? In some scenarios, I think > confederations may be a pretty sound replacement of the multiple-AS > approach. Policing iBGP sessions in a route-reflector topology? Limits? > Thoughts? > > Cheers, > > mh > >> >> >> >> > > > --- ??? Check my PGP key here: https://www.asgaard.org/~cdl/cdl.asc -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 455 bytes Desc: This is a digitally signed message part URL: From jcurran at arin.net Thu Mar 24 20:24:40 2011 From: jcurran at arin.net (John Curran) Date: Fri, 25 Mar 2011 01:24:40 +0000 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> Message-ID: <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> On Mar 24, 2011, at 9:13 PM, Benson Schliesser wrote: > At your suggestion, I went to the IGP blog and read the last comment. I see there is a response by Ernie Rubi to your blog comment, which captures my question so well that (with apologies to Mr Rubi) I'll quote him: Mr. Rubi is likely already aware from his legal studies that it is imprudent to argue cases in public in advance of filing. /John John Curran President and CEO ARIN From nanog-post at rsuc.gweep.net Thu Mar 24 20:51:17 2011 From: nanog-post at rsuc.gweep.net (Joe Provo) Date: Thu, 24 Mar 2011 21:51:17 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> Message-ID: <20110325015117.GA78153@gweep.net> On Thu, Mar 24, 2011 at 08:13:46PM -0500, Benson Schliesser wrote: [snip] > It's obvious that ARIN, as well as other whois database providers, > should pay attention to the proceedings. But under what premise > might ARIN act as a party to this lawsuit? The proper question might be that if neither NNI nor MS nor the middlemen believed ARIN to be a relevant party, why would they have bothered sending notification to them? Perhaps it has something to do with one of the many points their 5% fee being hinged upon "the Internet Assets are successfully registered in the name of that buyer, along with the successful registration of related address routes." I presume fulfilling the first part if why Addrex/Denuo are trying to pitch Depository as an something more than just another IRR node (the second part), and notifying ARIN was just hedging their bets. But looping ARIN in could be interpreted as inviting them in... Cheers, Joe -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE From ernesto at cs.fiu.edu Thu Mar 24 21:26:12 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 24 Mar 2011 22:26:12 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> Message-ID: <26EC938F-51AA-44F7-8015-DB4471B4BA05@cs.fiu.edu> Kind of off topic response so apologies, Perhaps ARINs counsel has counseled you against making statements - fair enough. My question doesn't go to any privileged information, just to general ARIN policy. I'll just say, for a community driven organization, it may seem odd to be silent in such important questions and take these decisions on your own. (I.e., decisions as to whether intervene in lawsuits, what policy arguments to make and how far to go before in said lawsuits). On a personal note, I'm just a law student and barely 28 y/o, but I'll say it again - I am astounded that people in all kinds of forums have derided me, chastised me and given me the silent treatment during this entire conversation. This was an academic question to me, but apparently lots of folks think it's life or death or semi-religious. I'll be quiet now. Sent from my iPhone On Mar 24, 2011, at 9:24 PM, John Curran wrote: > On Mar 24, 2011, at 9:13 PM, Benson Schliesser wrote: > >> At your suggestion, I went to the IGP blog and read the last comment. I see there is a response by Ernie Rubi to your blog comment, which captures my question so well that (with apologies to Mr Rubi) I'll quote him: > > Mr. Rubi is likely already aware from his legal studies that it > is imprudent to argue cases in public in advance of filing. > > /John > > John Curran > President and CEO > ARIN > From mysidia at gmail.com Thu Mar 24 21:59:29 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 24 Mar 2011 21:59:29 -0500 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> Message-ID: On Thu, Mar 24, 2011 at 8:24 PM, John Curran wrote: > On Mar 24, 2011, at 9:13 PM, Benson Schliesser wrote: >> At your suggestion, I went to the IGP blog and read the last comment. ?I see there is a response by Ernie Rubi to your blog comment, which captures my question so well that (with apologies to Mr Rubi) I'll quote him: > Mr. Rubi is likely already aware from his legal studies that it > is imprudent to argue cases in public in advance of filing. > /John So I wonder.... rhetorically speaking.. what happens when a bankruptcy court accidentally sells something that doesn't actually exist, something that is 'fictional', or dead... like an appliance warranty without the appliance, or something that consisted of third parties voluntarily doing something for the original holder, without any promise to continue.... under mistaken belief the third parties had guaranteed something that could be assigned to a successor? Because that's what IP addresses are. Totally worthless unless community participants voluntarily route traffic for those IPs to the assignee. E.g. Suppose I gave my neighbors a 100% discount on widgets for their use, just because they were neighbors, it was the community thing to do or something (legacy IP addresses with no agreement, no fees, contracts, etc). One of them declared bankruptcy, came to the court, and listed as one of their assets "100% widget discounts", and went to sell it to some major retailer, who wants to get a massive number of widgets to resell for profit (my name not mentioned, just as ARIN's name not mentioned)... is there really anything the buyer actually obtains? I mean, it sounds like someone threw 7.5 million into a furnace, unless they are going specified transfer.... Perhaps they come to ARIN eventually, but ARIN should enforce their policies. Meaning if MS has an RSA in force, all their resources should be compliant with ARIN policies, and all transfer policies should be followed with regards to justified need. I have little doubt that MS will properly construct/justify the need if they are obtaining resources. It's probably an easier/cheaper task for them to justify legitimately under RIR policies than trying to find some method of fighting with the community and risking an outcome that could be unfavorable and sully their own reputation in ways that might be hard to predict. Who knows, they have plenty of resources already and might plan a renumber and return; I would not assume the worst.... -- -JH From matthew at matthew.at Thu Mar 24 22:07:18 2011 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 24 Mar 2011 20:07:18 -0700 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> Message-ID: <4D8C06E6.6020504@matthew.at> On 3/24/2011 7:59 PM, Jimmy Hess wrote: > > Because that's what IP addresses are. Totally worthless unless community > participants voluntarily route traffic for those IPs to the assignee. Note that community participants can do this with or without ARIN having updated some entries in a database. Would de-peer with Microsoft (or turn down a transit contract from them) just because they wanted to announce some Nortel address space? Would ARIN really erase the Nortel entry and move these addresses to the free pool if Microsoft doesn't play along with one of the transfer policies? Would you announce addresses someone had just obtained from ARIN that were already being announced by Microsoft? Matthew Kaufman From jsw at inconcepts.biz Thu Mar 24 22:12:33 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Thu, 24 Mar 2011 23:12:33 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <26EC938F-51AA-44F7-8015-DB4471B4BA05@cs.fiu.edu> References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> <26EC938F-51AA-44F7-8015-DB4471B4BA05@cs.fiu.edu> Message-ID: What is needed is for the networks in the transit-free club to decide they will not honor any "gray market" route advertisements resulting from extra-normal transfers of this nature, whether the announcement is from a peer or a customer. As we are all aware, no real dent was ever made in routing table growth except by Sprint deciding what it was willing to accept. The up-side to a huge, unchecked gray market benefits "bad guys," such as spammers, much more than it does ordinary operators and end-users, on this I think we can all agree. The recent thread on DFZ growth also demonstrates clearly that uncertainty as to whether or not such an unchecked gray market will be allowed to exist, or even thrive, is driving most of us to strike routers with 500k FIB from our list (many of us have been doing so for years.) This means that the uncertainty has already created cost for operators and thus end-users. The sooner the big players get together on this and decide not to allow such a gray market, the better off we will be. Since some of these big players have huge legacy address pools already, there is little disadvantage to those networks refusing to honor gray market announcements from their customers, and probably no disadvantage to accepting them from peers, as long as they are not the sole actor. I anxiously await an xtra-normal announcement forbidding extra-normal routes. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From mysidia at gmail.com Thu Mar 24 22:15:07 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Thu, 24 Mar 2011 22:15:07 -0500 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8C06E6.6020504@matthew.at> References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> <4D8C06E6.6020504@matthew.at> Message-ID: On Thu, Mar 24, 2011 at 10:07 PM, Matthew Kaufman wrote: > On 3/24/2011 7:59 PM, Jimmy Hess wrote: >> Because that's what IP addresses are. ?Totally worthless unless community >> participants voluntarily route traffic for those IPs to the assignee. > Would de-peer with Microsoft (or turn down a transit contract from them) > just because they wanted to announce some Nortel address space? Microsoft would likely be able to find someone who would not turn them down for transit. > Would ARIN really erase the Nortel entry and move these addresses to the > free pool if Microsoft doesn't play along with one of the transfer policies? Unknown. I would expect ARIN to erase entries, if the situation exists where RIR policy requires that, or to refrain from effecting the transfer in the DB, unless that transfer requested is valid under policy and and the request is made correctly with all normal requirements met. > Would you announce addresses someone had just obtained from ARIN that were > already being announced by Microsoft? Most certainly, some networks would, if assigned space in that block, probably without noticing Microsoft's announcement. -- -JH From joey.liuyq at gmail.com Thu Mar 24 22:24:53 2011 From: joey.liuyq at gmail.com (Yaoqing(Joey) Liu) Date: Thu, 24 Mar 2011 22:24:53 -0500 Subject: Question about AS Origin changes Message-ID: Hi NANOG list, I am wondering if anyone can give me possible reasons for some uncommon BGP origin change activity. What we see is that sometimes the origin for a prefix seems to change from a customer AS to it upstream provider and back. In many instances the prefix simply switches back and forth for hours or even days and sometimes very rapidly . Below I?m including an example of some of the activities I see. Prefix 202.83.96/20 on border router 154.11.98.225(AS 852) At 14:10:56 Dec 04 2010, the BGP path with AS18106 as the origin At 14:11:57, the BGP path with AS9255 as the origin At 14:14:27, the BGP path with AS18106 as the origin. Thanks, Yaoqing From rubensk at gmail.com Thu Mar 24 22:27:19 2011 From: rubensk at gmail.com (Rubens Kuhl) Date: Fri, 25 Mar 2011 00:27:19 -0300 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> <4D8C06E6.6020504@matthew.at> Message-ID: On Fri, Mar 25, 2011 at 12:15 AM, Jimmy Hess wrote: > On Thu, Mar 24, 2011 at 10:07 PM, Matthew Kaufman wrote: >> On 3/24/2011 7:59 PM, Jimmy Hess wrote: >>> Because that's what IP addresses are. ?Totally worthless unless community >>> participants voluntarily route traffic for those IPs to the assignee. > >> Would de-peer with Microsoft (or turn down a transit contract from them) >> just because they wanted to announce some Nortel address space? > > Microsoft would likely be able to find someone who would not turn them > down for transit. Microsoft cannot stop other people from dropping such announcement elsewhere on the DFZ, beyond the transit provider they are paying money to. And that's exactly what the community response should be if ARIN finds that this transaction is bogus: treat it like unallocated space that's been announced. Rubens From tme at americafree.tv Thu Mar 24 22:34:06 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 24 Mar 2011 23:34:06 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> <4D8C06E6.6020504@matthew.at> Message-ID: <3923FDCA-2B18-46F8-A19D-4CB0D2F071ED@americafree.tv> On Mar 24, 2011, at 11:15 PM, Jimmy Hess wrote: > On Thu, Mar 24, 2011 at 10:07 PM, Matthew Kaufman wrote: >> On 3/24/2011 7:59 PM, Jimmy Hess wrote: >>> Because that's what IP addresses are. Totally worthless unless community >>> participants voluntarily route traffic for those IPs to the assignee. > >> Would de-peer with Microsoft (or turn down a transit contract from them) >> just because they wanted to announce some Nortel address space? > > Microsoft would likely be able to find someone who would not turn them > down for transit. > >> Would ARIN really erase the Nortel entry and move these addresses to the >> free pool if Microsoft doesn't play along with one of the transfer policies? > > Unknown. I would expect ARIN to erase entries, if the situation exists > where RIR policy requires that, or to refrain from effecting the > transfer in the DB, unless that transfer requested is valid under policy and > and the request is made correctly with all normal requirements met. > >> Would you announce addresses someone had just obtained from ARIN that were >> already being announced by Microsoft? > > Most certainly, some networks would, if assigned space in that block, > probably without noticing Microsoft's announcement. > It that the right question ? I am sure some networks would also continue to use Microsoft's announcements in this scenario. So, it would be a mess. So, I think that the right question is something more like : If ARIN reassigned the space, and Microsoft continued to announce it anyway, would either announcing entity be have enough of a critical mass that the conflict wouldn't matter to it ? I would submit that any address assignments with continual major operational issues arising from assignment conflicts would not be very attractive. I also don't think that that would be good for the Internet. Regards Marshall > -- > -JH > > From patrick at ianai.net Thu Mar 24 22:34:34 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Thu, 24 Mar 2011 23:34:34 -0400 Subject: Peering Traffic Volume In-Reply-To: References: Message-ID: <412AB716-82AD-4152-AADA-2384144D6A02@ianai.net> On Mar 24, 2011, at 7:27 PM, Ravi Ramaswamy wrote: > Hi All - I am new to this mailer. Hopefully my question is posed to the > correct list. > > I am using 2.5 Tbps as the peak volume of peering traffic over all peering > points for a Tier 1 ISP, for some modeling purposes. Is that a reasonable > estimate? "Tier 1 ISP" is a nebulous term. The top few networks in the world (not all of them are "tier 1 ISPs" - and one is not even a network :) are much larger. The smaller "tier 1s" are probably that size or less. -- TTFN, patrick From ernesto at cs.fiu.edu Thu Mar 24 22:44:23 2011 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Thu, 24 Mar 2011 23:44:23 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> Message-ID: <5D5BFE91-44F0-4AA5-9DF3-8A6168472F22@cs.fiu.edu> Bankruptcy courts have done this with phone numbers, read my paper - the 'phone number as assets' in bankruptcy cases are cited in there. Just saying Sent from my iPhone On Mar 24, 2011, at 10:59 PM, Jimmy Hess wrote: > On Thu, Mar 24, 2011 at 8:24 PM, John Curran wrote: >> On Mar 24, 2011, at 9:13 PM, Benson Schliesser wrote: >>> At your suggestion, I went to the IGP blog and read the last comment. I see there is a response by Ernie Rubi to your blog comment, which captures my question so well that (with apologies to Mr Rubi) I'll quote him: >> Mr. Rubi is likely already aware from his legal studies that it >> is imprudent to argue cases in public in advance of filing. >> /John > > So I wonder.... rhetorically speaking.. what happens when a bankruptcy > court accidentally sells something that doesn't actually exist, > something that is 'fictional', or dead... like an appliance warranty > without the appliance, or something that consisted of third parties > voluntarily doing something for the original holder, without any > promise to continue.... under mistaken belief the third parties > had guaranteed something that could be assigned to a successor? > > Because that's what IP addresses are. Totally worthless unless community > participants voluntarily route traffic for those IPs to the assignee. > > > E.g. Suppose I gave my neighbors a 100% discount on widgets > for their use, just because they were neighbors, it was the community > thing to do or something (legacy IP addresses with no agreement, > no fees, contracts, etc). > > One of them declared bankruptcy, came to the court, and listed as one of their > assets "100% widget discounts", and went to sell it to some major retailer, > who wants to get a massive number of widgets to resell for profit > (my name not mentioned, just as ARIN's name not mentioned)... > is there really anything the buyer actually obtains? > > > I mean, it sounds like someone threw 7.5 million into a furnace, > unless they are going specified transfer.... Perhaps they come to > ARIN eventually, but ARIN should enforce their policies. > > Meaning if MS has an RSA in force, all their resources should be compliant > with ARIN policies, and all transfer policies should be followed with regards > to justified need. > > I have little doubt that MS will properly construct/justify the need if they are > obtaining resources. It's probably an easier/cheaper task for them > to justify > legitimately under RIR policies than trying to find some method of fighting > with the community and risking an outcome that could be unfavorable > and sully their own reputation in ways that might be hard to predict. > > Who knows, they have plenty of resources already and might plan a renumber > and return; I would not assume the worst.... > > -- > -JH From charles at knownelement.com Thu Mar 24 22:43:11 2011 From: charles at knownelement.com (Charles N Wyble) Date: Thu, 24 Mar 2011 22:43:11 -0500 Subject: Peering Traffic Volume In-Reply-To: <412AB716-82AD-4152-AADA-2384144D6A02@ianai.net> References: <412AB716-82AD-4152-AADA-2384144D6A02@ianai.net> Message-ID: <4D8C0F4F.7050203@knownelement.com> On 3/24/2011 10:34 PM, Patrick W. Gilmore wrote: > On Mar 24, 2011, at 7:27 PM, Ravi Ramaswamy wrote: > > "Tier 1 ISP" is a nebulous term. Indeed it is. See http://en.wikipedia.org/wiki/Peering and http://en.wikipedia.org/wiki/Tier_1_network for more information. I'm guessing you are using Tier 1 to refer to $LARGE_TELCOS (ATT/VZ/L3) and I'm guessing their sustained daily traffic volume is well over 10tb. > The top few networks in the world (not all of them are "tier 1 ISPs" - and one is not even a network :) Facebook and google probably push that much traffic daily. I used to work for a company that did 100Gbps sustained on a daily basis. > are much larger. The smaller "tier 1s" are probably that size or less. I agree. From bensons at queuefull.net Thu Mar 24 22:53:12 2011 From: bensons at queuefull.net (Benson Schliesser) Date: Thu, 24 Mar 2011 22:53:12 -0500 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> Message-ID: On Mar 24, 2011, at 9:59 PM, Jimmy Hess wrote: > So I wonder.... rhetorically speaking.. what happens when a bankruptcy > court accidentally sells something that doesn't actually exist, > ... > Because that's what IP addresses are. Totally worthless unless community > participants voluntarily route traffic for those IPs to the assignee. There are a small number of examples, of intellectual property that exists solely by convention and yet has value. But you're correct: the property structure of IP addresses is ambiguous. We never had to define it because we had free supply, but times are changing. > Meaning if MS has an RSA in force, all their resources should be compliant > with ARIN policies, and all transfer policies should be followed with regards > to justified need. If I recall correctly, the ARIN RSA only applies to resources acquired from ARIN. It's a contract for ARIN services and doesn't cover legacy blocks, blocks from other RIRs, etc - it doesn't automatically extend ARIN's authority. On Mar 24, 2011, at 10:34 PM, Marshall Eubanks wrote: > If ARIN reassigned the space, and Microsoft continued to announce it anyway, would either announcing entity be have enough of a critical mass > that the conflict wouldn't matter to it ? > > I would submit that any address assignments with continual major operational issues arising from assignment conflicts would not be very attractive. > > I also don't think that that would be good for the Internet. I agree. Which is why ARIN should keep their Whois updated with accurate data, rather than fighting for control of resources beyond RSA scope. Cheers, -Benson From zaid at zaidali.com Fri Mar 25 04:09:14 2011 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 25 Mar 2011 02:09:14 -0700 Subject: Regional AS model In-Reply-To: <1301005023.2933.14.camel@home> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <87675028-2B60-4A52-8EC7-0CDD010CEAF8@pch.net> <1301005023.2933.14.camel@home> Message-ID: <6363935D-76F6-447B-9132-31F06B529996@zaidali.com> On Mar 24, 2011, at 3:17 PM, Michael Hallgren wrote: > Le jeudi 24 mars 2011 ? 14:26 -0700, Bill Woodcock a ?crit : >> On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote: >>> On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote: >>>> On Mar 24, 2011, at 12:42 PM, Zaid Ali wrote: >>>> >>>>> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. >>>> >>>> If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable. >>> >>> We disagree. >>> Single AS worldwide is fine with or without a backbone. >>> Which is "preferable" is up to you, your situation, and your personal tastes. >> >> >> We're with Patrick on this one. We operate a single AS across seventy-some-odd locations in dozens of countries, with very little of what an eyeball operator would call "backbone" between them, and we've never seen any potential benefit from splitting them. I think the management headache alone would be sufficient to make it unattractive to us. >> >> -Bill >> >> > > Right. I think that a single AS is most often quite fine. I think our > problem space is rather about how you organise the routing in your AS. > Flat, route-reflection, confederations? How much policing between > regions do you feel that you need? In some scenarios, I think > confederations may be a pretty sound replacement of the multiple-AS > approach. Policing iBGP sessions in a route-reflector topology? Limits? > Thoughts? I always look at confederations as a longer term plan because you have some idea how your backbone is going to shape out. Knowing where you are going makes confederation planning easier. Start with RR's and then see if confeds make sense. Zaid From fweimer at bfk.de Fri Mar 25 04:21:22 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 25 Mar 2011 09:21:22 +0000 Subject: The state-level attack on the SSL CA security model In-Reply-To: <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> (Roland Dobbins's message of "Thu\, 24 Mar 2011 21\:33\:27 +0000") References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <8239mchkc5.fsf@mid.bfk.de> <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> Message-ID: <82r59va73h.fsf@mid.bfk.de> * Roland Dobbins: > On Mar 24, 2011, at 6:41 PM, Florian Weimer wrote: > >> Disclosure devalues information. > I think this case is different, given the perception of the cert as > a 'thing' to be bartered. Private keys have been traded openly for years. For instance, when your browser tells you that a web site has been verified by "Equifax" (exact phrasing in the UI may vary), it's just not true. Equifax has sold its private key to someone else long ago, and chances are that the key material has changed hands a couple of times since. I can't see how a practice that is completely acceptable at the root certificate level is a danger so significant that state-secret-like treatment is called for once end-user certificates are involved. -- 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 morrowc.lists at gmail.com Fri Mar 25 04:54:21 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 25 Mar 2011 05:54:21 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> Message-ID: On Thu, Mar 24, 2011 at 8:25 PM, Martin Millnert wrote: > List, > > since there are IRR databases operated by non-RIRs, does one need to > register a prefix in any RIR-DB at all, to see it reachable on the > Internet? > you successfully mixed up IRR and RIR in your post, care to untangle that and repost? From nick at foobar.org Fri Mar 25 06:02:20 2011 From: nick at foobar.org (Nick Hilliard) Date: Fri, 25 Mar 2011 11:02:20 +0000 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> Message-ID: <4D8C763C.2080501@foobar.org> On 25/03/2011 09:54, Christopher Morrow wrote: > On Thu, Mar 24, 2011 at 8:25 PM, Martin Millnert wrote: >> List, >> >> since there are IRR databases operated by non-RIRs, does one need to >> register a prefix in any RIR-DB at all, to see it reachable on the >> Internet? >> > > you successfully mixed up IRR and RIR in your post, care to untangle > that and repost? Looks to me like his email was semantically sound. Remember, outside ARINinstan, irrdb functionality is usually implemented as an addon feature to the whois db. btw, the answer to his question is "no, but it's a good idea to do so". Nick From morrowc.lists at gmail.com Fri Mar 25 06:03:31 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 25 Mar 2011 07:03:31 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <4D8C763C.2080501@foobar.org> References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <4D8C763C.2080501@foobar.org> Message-ID: On Fri, Mar 25, 2011 at 7:02 AM, Nick Hilliard wrote: > On 25/03/2011 09:54, Christopher Morrow wrote: >> >> On Thu, Mar 24, 2011 at 8:25 PM, Martin Millnert >> ?wrote: >>> >>> List, >>> >>> since there are IRR databases operated by non-RIRs, does one need to >>> register a prefix in any RIR-DB at all, to see it reachable on the >>> Internet? >>> >> >> you successfully mixed up IRR and RIR in your post, care to untangle >> that and repost? > > Looks to me like his email was semantically sound. ?Remember, outside > ARINinstan, irrdb functionality is usually implemented as an addon feature > to the whois db. ha! arinistan, funny! > > btw, the answer to his question is "no, but it's a good idea to do so". > > Nick > > From m.hallgren at free.fr Fri Mar 25 06:04:32 2011 From: m.hallgren at free.fr (Michael Hallgren) Date: Fri, 25 Mar 2011 12:04:32 +0100 Subject: Regional AS model In-Reply-To: <6363935D-76F6-447B-9132-31F06B529996@zaidali.com> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <87675028-2B60-4A52-8EC7-0CDD010CEAF8@pch.net> <1301005023.2933.14.camel@home> <6363935D-76F6-447B-9132-31F06B529996@zaidali.com> Message-ID: <1301051072.2933.21.camel@home> Le vendredi 25 mars 2011 ? 02:09 -0700, Zaid Ali a ?crit : > On Mar 24, 2011, at 3:17 PM, Michael Hallgren wrote: > > > Le jeudi 24 mars 2011 ? 14:26 -0700, Bill Woodcock a ?crit : > >> On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote: > >>> On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote: > >>>> On Mar 24, 2011, at 12:42 PM, Zaid Ali wrote: > >>>> > >>>>> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. > >>>> > >>>> If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable. > >>> > >>> We disagree. > >>> Single AS worldwide is fine with or without a backbone. > >>> Which is "preferable" is up to you, your situation, and your personal tastes. > >> > >> > >> We're with Patrick on this one. We operate a single AS across seventy-some-odd locations in dozens of countries, with very little of what an eyeball operator would call "backbone" between them, and we've never seen any potential benefit from splitting them. I think the management headache alone would be sufficient to make it unattractive to us. > >> > >> -Bill > >> > >> > > > > Right. I think that a single AS is most often quite fine. I think our > > problem space is rather about how you organise the routing in your AS. > > Flat, route-reflection, confederations? How much policing between > > regions do you feel that you need? In some scenarios, I think > > confederations may be a pretty sound replacement of the multiple-AS > > approach. Policing iBGP sessions in a route-reflector topology? Limits? > > Thoughts? > > I always look at confederations as a longer term plan because you have some idea how your backbone is going to shape out. Knowing where you are going makes confederation planning easier. Start with RR's and then see if confeds make sense. > Yes, I agree. Confed's is a choice, in particular if you need elaborate policies between regions of your network. Police sessions between sub-ASes, keep iBGP simple... Say, you start with RR... If or once your network is large, and having customers connected to it, migrating to conferedrations may be a challenge. Right? Thoughts? Experiences? mh > Zaid From streiner at cluebyfour.org Fri Mar 25 02:13:11 2011 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 25 Mar 2011 03:13:11 -0400 (EDT) Subject: Peering Traffic Volume In-Reply-To: References: Message-ID: On Thu, 24 Mar 2011, Ravi Ramaswamy wrote: > Hi All - I am new to this mailer. Hopefully my question is posed to the > correct list. > > I am using 2.5 Tbps as the peak volume of peering traffic over all peering > points for a Tier 1 ISP, for some modeling purposes. Is that a reasonable > estimate? Possibly. The reason I say that is because the details of many ISPs' peering arrangements are often subject to NDA, so there is often a cone of silence around those bits. jms From joakim at aronius.se Fri Mar 25 06:27:48 2011 From: joakim at aronius.se (Joakim Aronius) Date: Fri, 25 Mar 2011 12:27:48 +0100 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> <27726811.0.1301002752950.JavaMail.franck@Macintosh-3.local> Message-ID: <20110325112748.GC21480@nike.aronius.se> * George Herbert (george.herbert at gmail.com) wrote: > Back on original point - if the *actual effective* model of browser > security is browsers with an internal revoked cert list - then there's > a case to be made that a pre-announcement in private to the browser > vendors, enough time for them to spin patches, and then widespread > public discussion is the most responsible model approach. The public > knowing before their browser knows how to handle the bad cert isn't > helpful, unless you can effectively tell people how to get their > browser to actually go verify every cert. > No. In the case of a remote exploitable hole in the client OS I agree, then the user can do nothing and will benefit if there is a patch before the knowledge of the problem is spread. But in this case it is a security hole in the server side. IF users are informed they can avoid using the service and thus avoid the risk. (And if the risk is to be on the wrong end of a stick, at least I would appreciate a warning.) So what about a general warning that secure communication with site X, Y and Z could be compromised? Maybe even a big warning on the sites themself to give a warning before you login? (It could be removed by a 'man in the middle', but it would spread the word.) I wonder why that didn't happen.. /J From jamie at photon.com Fri Mar 25 06:44:20 2011 From: jamie at photon.com (Jamie Bowden) Date: Fri, 25 Mar 2011 07:44:20 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million Message-ID: <275FEA2949B48341A3B46F424B613D857BC1@WDC-MX.photon.com> Does anyone really believe MS is this na?ve? I have no doubt at all that some small bit of Nortel will be transferred to MS if that's what's required for the IPs in question to be moved in accordance with normal standards, practice, and policy. Jamie -----Original Message----- From: Matthew Kaufman [mailto:matthew at matthew.at] Sent: Thursday, March 24, 2011 11:07 PM To: Jimmy Hess Cc: John Curran; NANOG list Subject: Re: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million On 3/24/2011 7:59 PM, Jimmy Hess wrote: > > Because that's what IP addresses are. Totally worthless unless community > participants voluntarily route traffic for those IPs to the assignee. Note that community participants can do this with or without ARIN having updated some entries in a database. Would de-peer with Microsoft (or turn down a transit contract from them) just because they wanted to announce some Nortel address space? Would ARIN really erase the Nortel entry and move these addresses to the free pool if Microsoft doesn't play along with one of the transfer policies? Would you announce addresses someone had just obtained from ARIN that were already being announced by Microsoft? Matthew Kaufman From Valdis.Kletnieks at vt.edu Fri Mar 25 07:36:15 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 25 Mar 2011 08:36:15 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: Your message of "Fri, 25 Mar 2011 00:27:19 -0300." References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> <4D8C06E6.6020504@matthew.at> Message-ID: <37441.1301056575@localhost> On Fri, 25 Mar 2011 00:27:19 -0300, Rubens Kuhl said: > Microsoft cannot stop other people from dropping such announcement > elsewhere on the DFZ, beyond the transit provider they are paying > money to. And that's exactly what the community response should be if > ARIN finds that this transaction is bogus: treat it like unallocated > space that's been announced. They probably *can* stop you from dropping the announcement, by moving Windowsupdate or Hotmail or the XBox network into that address space. Or more correctly, the constantly ringing phones will make you reverse your decision... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From rdobbins at arbor.net Fri Mar 25 08:25:49 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 25 Mar 2011 13:25:49 +0000 Subject: The state-level attack on the SSL CA security model In-Reply-To: <82r59va73h.fsf@mid.bfk.de> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <8239mchkc5.fsf@mid.bfk.de> <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> <82r59va73h.fsf@mid.bfk.de> Message-ID: <75367FFE-CC1E-4966-99A3-BCA12A40DAD6@arbor.net> On Mar 25, 2011, at 5:21 PM, Florian Weimer wrote: > I can't see how a practice that is completely acceptable at the root certificate level is a danger so significant that state-secret-like > treatment is called for once end-user certificates are involved. Again, I don't know enough about what happened to form an opinion one way or another. I'm just setting forth some reasons which spring to mind for not announcing this immediately, that's all. ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From Feargal.Ledwidge at target.com Fri Mar 25 08:37:42 2011 From: Feargal.Ledwidge at target.com (Feargal.Ledwidge) Date: Fri, 25 Mar 2011 08:37:42 -0500 Subject: Google Geolocation In-Reply-To: <8B69CF5B-6509-4810-9C4A-1791D1047F5F@bsdboy.com> References: <8C26A4FDAE599041A13EB499117D3C286B3E70A4@ex-mb-1.corp.atlasnetworks.us> <8B69CF5B-6509-4810-9C4A-1791D1047F5F@bsdboy.com> Message-ID: <9243274FC956054AA56F694127E639E72684DA8285@TLEMLMBX04P.email.target.com> > > Basically, going to www.google.com/ncs will enable No Country Redirect. > I think you meant www.google.com/ncr From wschultz at bsdboy.com Fri Mar 25 08:40:52 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Fri, 25 Mar 2011 06:40:52 -0700 Subject: Google Geolocation In-Reply-To: <9243274FC956054AA56F694127E639E72684DA8285@TLEMLMBX04P.email.target.com> References: <8C26A4FDAE599041A13EB499117D3C286B3E70A4@ex-mb-1.corp.atlasnetworks.us> <8B69CF5B-6509-4810-9C4A-1791D1047F5F@bsdboy.com> <9243274FC956054AA56F694127E639E72684DA8285@TLEMLMBX04P.email.target.com> Message-ID: On Mar 25, 2011, at 6:37 AM, Feargal.Ledwidge wrote: >> >> Basically, going to www.google.com/ncs will enable No Country Redirect. >> > > I think you meant www.google.com/ncr > > Definitely. From bill at herrin.us Fri Mar 25 08:45:51 2011 From: bill at herrin.us (William Herrin) Date: Fri, 25 Mar 2011 09:45:51 -0400 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <5D5BFE91-44F0-4AA5-9DF3-8A6168472F22@cs.fiu.edu> References: <20110324125757.GG23560@leitl.org> <3E39A39D-BAC4-40ED-9D49-0583EE6899AA@arin.net> <5B2F0730-7BFC-4BAC-952E-CFF9AB084FCB@arin.net> <5D5BFE91-44F0-4AA5-9DF3-8A6168472F22@cs.fiu.edu> Message-ID: On Thu, Mar 24, 2011 at 11:44 PM, Ernie Rubi wrote: > Bankruptcy courts have done this with phone numbers, >read my paper - the 'phone number as assets' in >bankruptcy cases are cited in there. Ernie, Not exactly. Bankruptcy courts have assigned the telephone contracts which include service on a particular number to new entities. If you're aware of a case where that involved a substantive modification of the contract done without the permission of the other party to the contract, I'm all ears. > On a personal note, I'm just a law student and barely >28 y/o, but I'll say it again - I am astounded that people >in all kinds of forums have derided me, chastised me >and given me the silent treatment during this entire >conversation. This was an academic question to me, >but apparently lots of folks think it's life or death or >semi-religious. Your paper was a good read and it has a lot of interesting and relevant information. But as with the rest of us, the conclusions you've drawn are untested with important parts of how the industry does business potentially hanging in the balance. You shouldn't take that as a personal slight; it isn't. On Fri, Mar 25, 2011 at 7:44 AM, Jamie Bowden wrote: > Does anyone really believe MS is this na?ve? "Never attribute to malice that which is adequately explained by stupidity." -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From david.freedman at uk.clara.net Fri Mar 25 08:49:32 2011 From: david.freedman at uk.clara.net (David Freedman) Date: Fri, 25 Mar 2011 13:49:32 +0000 Subject: Regional AS model In-Reply-To: <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> Message-ID: > Single AS worldwide is fine with or without a backbone. > > Which is "preferable" is up to you, your situation, and your personal > tastes. (I guess one could argue that wasting AS numbers, or > polluting the table with lots of AS numbers is bad or un-ashetically > pleasing, but I think you should do whatever fits your situation > anyway.) > Depends on your routing requirements, for example, you need to rely on a default or disable as_path checks (or re-write the path) to be able to see your other clusters (if they do need to communicate)... -- David Freedman Group Network Engineering Claranet Group From fweimer at bfk.de Fri Mar 25 08:53:16 2011 From: fweimer at bfk.de (Florian Weimer) Date: Fri, 25 Mar 2011 13:53:16 +0000 Subject: Question about AS Origin changes In-Reply-To: (Yaoqing Liu's message of "Thu\, 24 Mar 2011 22\:24\:53 -0500") References: Message-ID: <828vw38fxv.fsf@mid.bfk.de> * Yaoqing Liu: > I am wondering if anyone can give me possible reasons for some uncommon BGP > origin change activity. What we see is that sometimes the origin for a > prefix seems to change from a customer AS to it upstream provider and back. > In many instances the prefix simply switches back and forth for hours or > even days and sometimes very rapidly . Below I?m including an example of > some of the activities I see. This is expected if the upstream has a static route for the prefix (or a route which redistributed from another routing protocol). This could be a leftover from a non-BGP setup with the customer. Or this could be some sort of backup procedure (perhaps prompted by the instability of the BGP link). -- 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 bora at pnl.gov Fri Mar 25 10:36:12 2011 From: bora at pnl.gov (Akyol, Bora A) Date: Fri, 25 Mar 2011 08:36:12 -0700 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> Message-ID: What other choice does the public have? By locking them into the current trust model (for good or bad), the community has created this mess. Is it far fetched to supplement the existing system with a reputation based model such as PGP? I apologize if this was discussed before. -----Original Message----- From: Dobbins, Roland [mailto:rdobbins at arbor.net] Sent: Thursday, March 24, 2011 3:28 AM To: nanog group Subject: Re: The state-level attack on the SSL CA security model ... Unfortunately, the general public neither know, understand, or care about such things. They happily click 'I Understand the Risks' or whatever the button says in their browsers of choice to accept self-signed certificates all the time. ... From mike at mtcc.com Fri Mar 25 10:54:46 2011 From: mike at mtcc.com (Michael Thomas) Date: Fri, 25 Mar 2011 08:54:46 -0700 Subject: paypal and ipv6 Message-ID: <4D8CBAC6.1050102@mtcc.com> seems that ipv4 addresses are mandatory with paypal with a stingy 15 char limit so you can't even sneak a v6 address in. we've got a long way to go. https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_nvp_r_DoDirectPayment Mike From Valdis.Kletnieks at vt.edu Fri Mar 25 11:04:59 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 25 Mar 2011 12:04:59 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: Your message of "Fri, 25 Mar 2011 08:36:12 PDT." References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> Message-ID: <21155.1301069099@localhost> On Fri, 25 Mar 2011 08:36:12 PDT, "Akyol, Bora A" said: > Is it far fetched to supplement the existing system with a reputation based > model such as PGP? I apologize if this was discussed before. That would be great, if you could ensure the following: 1) That Joe Sixpack actually knows enough somebodies who are trustable to sign stuff. (If Joe doesn't know them, then it's not a web of trust, it's just the same old CA). 2) That Joe Sixpack doesn't blindly sign stuff himself (I've had to on occasion scrape unknown signatures off my PGP key on the keyservers, when people I've never heard of before have signed my key "just because somebody they recognized signed it"). The PGP model doesn't work for users who are used to clicking everything they see, whether or not they really should... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bora at pnl.gov Fri Mar 25 11:19:52 2011 From: bora at pnl.gov (Akyol, Bora A) Date: Fri, 25 Mar 2011 09:19:52 -0700 Subject: The state-level attack on the SSL CA security model In-Reply-To: <21155.1301069099@localhost> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <21155.1301069099@localhost> Message-ID: One could argue that you could try something like the facebook model (or facebook itself). I can see it coming. Facebook web of trust app ;-) -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Friday, March 25, 2011 9:05 AM To: Akyol, Bora A Cc: Dobbins, Roland; nanog group Subject: Re: The state-level attack on the SSL CA security model On Fri, 25 Mar 2011 08:36:12 PDT, "Akyol, Bora A" said: > Is it far fetched to supplement the existing system with a reputation > based model such as PGP? I apologize if this was discussed before. That would be great, if you could ensure the following: 1) That Joe Sixpack actually knows enough somebodies who are trustable to sign stuff. (If Joe doesn't know them, then it's not a web of trust, it's just the same old CA). 2) That Joe Sixpack doesn't blindly sign stuff himself (I've had to on occasion scrape unknown signatures off my PGP key on the keyservers, when people I've never heard of before have signed my key "just because somebody they recognized signed it"). The PGP model doesn't work for users who are used to clicking everything they see, whether or not they really should... From dorn at hetzel.org Fri Mar 25 11:24:20 2011 From: dorn at hetzel.org (Dorn Hetzel) Date: Fri, 25 Mar 2011 12:24:20 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <21155.1301069099@localhost> Message-ID: Not entirely unreasonable. A button for "friend" and then one for "trusted friend" :) On Fri, Mar 25, 2011 at 12:19 PM, Akyol, Bora A wrote: > One could argue that you could try something like the facebook model (or > facebook itself). I can see it coming. > Facebook web of trust app ;-) > > > > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Friday, March 25, 2011 9:05 AM > To: Akyol, Bora A > Cc: Dobbins, Roland; nanog group > Subject: Re: The state-level attack on the SSL CA security model > > On Fri, 25 Mar 2011 08:36:12 PDT, "Akyol, Bora A" said: > > Is it far fetched to supplement the existing system with a reputation > > based model such as PGP? I apologize if this was discussed before. > > That would be great, if you could ensure the following: > > 1) That Joe Sixpack actually knows enough somebodies who are trustable to > sign stuff. (If Joe doesn't know them, then it's not a web of trust, it's > just the same old CA). > > 2) That Joe Sixpack doesn't blindly sign stuff himself (I've had to on > occasion scrape unknown signatures off my PGP key on the keyservers, when > people I've never heard of before have signed my key "just because somebody > they recognized signed it"). > > The PGP model doesn't work for users who are used to clicking everything > they see, whether or not they really should... > > > From bora at pnl.gov Fri Mar 25 11:30:48 2011 From: bora at pnl.gov (Akyol, Bora A) Date: Fri, 25 Mar 2011 09:30:48 -0700 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <21155.1301069099@localhost> Message-ID: Thanks The other point I wanted to make is that not every solution is going to work for every person. If we can improve the current state of things and make life better for say another 50% of users, that's better than what we have now. For example in Firefox 4, I could write an extension (if possible) that intercepts the certificate acceptance dialog and instead does a web query to see how many of my friends and also their friends accepted the same cert and at least allow me to decide with more information than I am presented now. And you could argue that this should also apply to certs signed by CAs that are in the trust store of the web browser too. Just thinking out loud here. ----------------------------------------------------------------------------------------------- From: Dorn Hetzel [mailto:dorn at hetzel.org] Sent: Friday, March 25, 2011 9:24 AM To: Akyol, Bora A Cc: Valdis.Kletnieks at vt.edu; nanog group Subject: Re: The state-level attack on the SSL CA security model Not entirely unreasonable. ?A button for "friend" and then one for "trusted friend" :) On Fri, Mar 25, 2011 at 12:19 PM, Akyol, Bora A wrote: One could argue that you could try something like the facebook model (or facebook itself). I can see it coming. Facebook web of trust app ;-) -----Original Message----- From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] Sent: Friday, March 25, 2011 9:05 AM To: Akyol, Bora A Cc: Dobbins, Roland; nanog group Subject: Re: The state-level attack on the SSL CA security model On Fri, 25 Mar 2011 08:36:12 PDT, "Akyol, Bora A" said: > Is it far fetched to supplement the existing system with a reputation > based ?model such as PGP? I apologize if this was discussed before. That would be great, if you could ensure the following: 1) That Joe Sixpack actually knows enough somebodies who are trustable to sign stuff. (If Joe doesn't know them, then it's not a web of trust, it's just the same old CA). 2) That Joe Sixpack doesn't blindly sign stuff himself (I've had to on occasion scrape unknown signatures off my PGP key on the keyservers, when people I've never heard of before have signed my key "just because somebody they recognized signed it"). The PGP model doesn't work for users who are used to clicking everything they see, whether or not they really should... From Valdis.Kletnieks at vt.edu Fri Mar 25 11:45:04 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 25 Mar 2011 12:45:04 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: Your message of "Fri, 25 Mar 2011 09:19:52 PDT." References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <21155.1301069099@localhost> Message-ID: <23088.1301071504@localhost> On Fri, 25 Mar 2011 09:19:52 PDT, "Akyol, Bora A" said: > One could argue that you could try something like the facebook model (or > facebook itself). I can see it coming. > Facebook web of trust app ;-) Gee thanks. I'm going to have nightmares for *weeks* now... :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Jeff.Hodges at KingsMountain.com Fri Mar 25 11:50:34 2011 From: Jeff.Hodges at KingsMountain.com (=JeffH) Date: Fri, 25 Mar 2011 09:50:34 -0700 Subject: The state-level attack on the SSL CA security model Message-ID: <4D8CC7DA.6080000@KingsMountain.com> Mozilla has now posted a more detailed accounting here.. Comodo Certificate Issue ? Follow Up 03.25.11 - 08:39am http://blog.mozilla.com/security/2011/03/25/comodo-certificate-issue-follow-up/ =JeffH From woody at pch.net Fri Mar 25 12:44:10 2011 From: woody at pch.net (Bill Woodcock) Date: Fri, 25 Mar 2011 10:44:10 -0700 Subject: Peering Traffic Volume In-Reply-To: References: Message-ID: On Mar 24, 2011, at 4:27 PM, Ravi Ramaswamy wrote: > Hi All - I am new to this mailer. Hopefully my question is posed to the > correct list. Welcome. > I am using 2.5 Tbps as the peak volume of peering traffic over all peering > points for a Tier 1 ISP, for some modeling purposes. Is that a reasonable > estimate? That's actually a very difficult research question for the academic community, and one that they've been struggling with since they lost their overview of the NSFNET backbone in ~1992. Ironically, it's quite easy for any one ISP to answer internally, but these numbers are closely held as trade-secrets. One thing you can do is look at the total volume of publicly-reported traffic across IXP switch fabrics: https://prefix.pch.net/applications/ixpdir/summary/growth-region/?sort1=bandwidth&sort2=_current&order=desc https://prefix.pch.net/applications/ixpdir/?show_active_only=0&sort=traffic&order=desc ?where you see about 8.3Tbps of overall reported traffic. Then you could do various analyses comparing IXPs where crossconnects are prevalent (Equinix Ashburn, say) to ones where they are not, and looking at which ISPs peer at each. You could also try to find out from ISPs which IXPs they use crossconnects at, and which they don't. That may be easier information for you to get than how much traffic they're doing individually. It might also be interesting to look at some of the IXPs that publish per-participant traffic figures, to see if you can develop characteristic statistical distributions for amount-each-participant-contributes-to-the-IXP, though you should be cautioned that the curve might be much heavier-tailed for a large exchange than a small one. Ultimately, if you're considering this as an academic research question, you may want to think about the utility of examining a "black box" question like this, when the answer is plainly known to other people, just not known to, or verifiable by, you. The chances of getting the answer "right" are low, and if you do get it "right" neither you nor your thesis advisor would ever find that out. There are many other classes of problem that are potentially much more rewarding, because they would contribute to our overall knowledge of how the network works: BGP route convergence and stability properties in chaotic (i.e. real-world) networks; documenting the performance and economic effects (and the tradeoff with stability) of denser peering meshes; study of the uptake of DNSSEC; study of the prevalence of different IPv4/IPv6 transition technologies... -Bill From patrick at ianai.net Fri Mar 25 12:51:02 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Fri, 25 Mar 2011 13:51:02 -0400 Subject: Peering Traffic Volume In-Reply-To: References: Message-ID: <4B46DD5F-9C83-44B4-8556-D6B9900289ED@ianai.net> On Mar 25, 2011, at 1:44 PM, Bill Woodcock wrote: > On Mar 24, 2011, at 4:27 PM, Ravi Ramaswamy wrote: >> >> I am using 2.5 Tbps as the peak volume of peering traffic over all peering >> points for a Tier 1 ISP, for some modeling purposes. Is that a reasonable >> estimate? > > That's actually a very difficult research question for the academic community, and one that they've been struggling with since they lost their overview of the NSFNET backbone in ~1992. > > Ironically, it's quite easy for any one ISP to answer internally, but these numbers are closely held as trade-secrets. > > One thing you can do is look at the total volume of publicly-reported traffic across IXP switch fabrics: > > https://prefix.pch.net/applications/ixpdir/summary/growth-region/?sort1=bandwidth&sort2=_current&order=desc > > https://prefix.pch.net/applications/ixpdir/?show_active_only=0&sort=traffic&order=desc > > ?where you see about 8.3Tbps of overall reported traffic. Then you could do various analyses comparing IXPs where crossconnects are prevalent (Equinix Ashburn, say) to ones where they are not, and looking at which ISPs peer at each. You could also try to find out from ISPs which IXPs they use crossconnects at, and which they don't. That may be easier information for you to get than how much traffic they're doing individually. IXP vs. private interconnect (be it peering or customer/transit) ratios varies dramatically with geography, scale, and even the proclivities of the various network architects. The question is whether "some data" is better than "no data". Honestly, I'm not sure. I see lots of things with 'some data' that are actually worse than guesses. But where I cannot eventually find the actual answer, I am left wanting to prefer the "some data" ones, probably because "data" sounds good. > It might also be interesting to look at some of the IXPs that publish per-participant traffic figures, to see if you can develop characteristic statistical distributions for amount-each-participant-contributes-to-the-IXP, though you should be cautioned that the curve might be much heavier-tailed for a large exchange than a small one. Even that is dangerous. For instance, some participants move traffic away from such IXPs. (That is not a guess, I know first hand that this happens - especially as I am one of those people.) -- TTFN, patrick From millnert at gmail.com Fri Mar 25 12:53:35 2011 From: millnert at gmail.com (Martin Millnert) Date: Fri, 25 Mar 2011 13:53:35 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <21155.1301069099@localhost> Message-ID: On Fri, Mar 25, 2011 at 12:19 PM, Akyol, Bora A wrote: > One could argue that you could try something like the facebook model (or facebook itself). I can see it coming. > Facebook web of trust app ;-) Indeed not very unreasonable at all, except a) it would be kind of unfortunate if Facebook would not make the data available under adequate conditions, b) Facebook can already infer level of relationships between people based on a whole lot of their other data (it's kind of what makes them spin). I agree in seeing it coming though: "Web-of-trust 2.0". soBGP takes on a similar approach to securing BGP. Not a bad idea at all at first sight, IMHO. Anyone knows why it died out and why other (perhaps poorer) ideas are floating around now? http://tools.ietf.org/html/draft-white-sobgp-architecture-02 Regards, Martin > -----Original Message----- > From: Valdis.Kletnieks at vt.edu [mailto:Valdis.Kletnieks at vt.edu] > Sent: Friday, March 25, 2011 9:05 AM > To: Akyol, Bora A > Cc: Dobbins, Roland; nanog group > Subject: Re: The state-level attack on the SSL CA security model > > On Fri, 25 Mar 2011 08:36:12 PDT, "Akyol, Bora A" said: >> Is it far fetched to supplement the existing system with a reputation >> based ?model such as PGP? I apologize if this was discussed before. > > That would be great, if you could ensure the following: > > 1) That Joe Sixpack actually knows enough somebodies who are trustable to sign stuff. (If Joe doesn't know them, then it's not a web of trust, it's just the same old CA). > > 2) That Joe Sixpack doesn't blindly sign stuff himself (I've had to on occasion scrape unknown signatures off my PGP key on the keyservers, when people I've never heard of before have signed my key "just because somebody they recognized signed it"). > > The PGP model doesn't work for users who are used to clicking everything they see, whether or not they really should... > > > From paul at paulgraydon.co.uk Fri Mar 25 13:31:21 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Fri, 25 Mar 2011 08:31:21 -1000 Subject: The growth of municipal broadband networks Message-ID: <4D8CDF79.9060404@paulgraydon.co.uk> http://arstechnica.com/tech-policy/news/2011/03/133-us-cities-now-run-their-own-broadband-networks.ars Ars Technica has a short article up about the growth of municipal networks, but principally a nice little 'hey check out this website' (http://www.muninetworks.org/communitymap) The whole scenario around municipal broadband networks in a hopefully unbiased nutshell: Increasing numbers cities and counties seem to be getting frustrated with what they see as the lack of progress in broadband speeds from their incumbent provider(s) (even after incumbent provider(s) have been approached requesting faster speeds) and are deciding to do it themselves. Chattanooga, Tennessee has become the poster child for the idea, able to offer 1Gbps to users and businesses at competitive prices ($150 pcm.) I'm curious how the feeling is on NANOG about shifting such provision towards municipal instead of corporations? I guess a rough summary of the competing views I've heard so far are: + It's fair and valid competition in the market, which is encouraging major ISPs to innovate instead of resting on their laurels and trying to do the bare minimum necessary to maintain their position and profits, an attitude that is stifling other economic growth? - Local government is sticking its nose in where it shouldn't, providing unfair competition and stifling normal market processes. Municipalities are operating on the false belief that large bandwidth will automatically bring silicon valley to them, without understanding the bigger picture. That it's time, money and resources better spent on tax incentives or other means of encouraging businesses. Paul From cscora at apnic.net Fri Mar 25 13:38:39 2011 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 26 Mar 2011 04:38:39 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201103251838.p2PIcd11006041@thyme.rand.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.rand.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 26 Mar, 2011 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 351425 Prefixes after maximum aggregation: 159549 Deaggregation factor: 2.20 Unique aggregates announced to Internet: 173538 Total ASes present in the Internet Routing Table: 37074 Prefixes per ASN: 9.48 Origin-only ASes present in the Internet Routing Table: 31157 Origin ASes announcing only one prefix: 14986 Transit ASes present in the Internet Routing Table: 4992 Transit-only ASes present in the Internet Routing Table: 129 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 31 Max AS path prepend of ASN (36992) 29 Prefixes from unregistered ASNs in the Routing Table: 451 Unregistered ASNs in the Routing Table: 217 Number of 32-bit ASNs allocated by the RIRs: 1230 Number of 32-bit ASNs visible in the Routing Table: 925 Prefixes from 32-bit ASNs in the Routing Table: 2001 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 191 Number of addresses announced to Internet: 2390772288 Equivalent to 142 /8s, 128 /16s and 74 /24s Percentage of available address space announced: 64.5 Percentage of allocated address space announced: 64.5 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 89.6 Total number of prefixes smaller than registry allocations: 145378 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 87775 Total APNIC prefixes after maximum aggregation: 29913 APNIC Deaggregation factor: 2.93 Prefixes being announced from the APNIC address blocks: 84659 Unique aggregates announced from the APNIC address blocks: 36676 APNIC Region origin ASes present in the Internet Routing Table: 4370 APNIC Prefixes per ASN: 19.37 APNIC Region origin ASes announcing only one prefix: 1214 APNIC Region transit ASes present in the Internet Routing Table: 692 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 20 Number of APNIC region 32-bit ASNs visible in the Routing Table: 45 Number of APNIC addresses announced to Internet: 600588608 Equivalent to 35 /8s, 204 /16s and 65 /24s Percentage of available APNIC address space announced: 76.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, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/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: 138605 Total ARIN prefixes after maximum aggregation: 70811 ARIN Deaggregation factor: 1.96 Prefixes being announced from the ARIN address blocks: 111045 Unique aggregates announced from the ARIN address blocks: 44885 ARIN Region origin ASes present in the Internet Routing Table: 14277 ARIN Prefixes per ASN: 7.78 ARIN Region origin ASes announcing only one prefix: 5432 ARIN Region transit ASes present in the Internet Routing Table: 1472 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN region 32-bit ASNs visible in the Routing Table: 10 Number of ARIN addresses announced to Internet: 797226496 Equivalent to 47 /8s, 132 /16s and 182 /24s Percentage of available ARIN address space announced: 63.4 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, 23/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, 53/8, 54/8, 55/8, 56/8, 57/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, 100/8, 104/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: 82875 Total RIPE prefixes after maximum aggregation: 47359 RIPE Deaggregation factor: 1.75 Prefixes being announced from the RIPE address blocks: 76234 Unique aggregates announced from the RIPE address blocks: 50044 RIPE Region origin ASes present in the Internet Routing Table: 15444 RIPE Prefixes per ASN: 4.94 RIPE Region origin ASes announcing only one prefix: 7777 RIPE Region transit ASes present in the Internet Routing Table: 2412 Average RIPE Region AS path length visible: 4.6 Max RIPE Region AS path length visible: 30 Number of RIPE region 32-bit ASNs visible in the Routing Table: 684 Number of RIPE addresses announced to Internet: 465041152 Equivalent to 27 /8s, 183 /16s and 247 /24s Percentage of available RIPE address space announced: 74.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, 56320-58367 196608-198655 RIPE Address Blocks 2/8, 5/8, 25/8, 31/8, 37/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, 185/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 32341 Total LACNIC prefixes after maximum aggregation: 7367 LACNIC Deaggregation factor: 4.39 Prefixes being announced from the LACNIC address blocks: 31251 Unique aggregates announced from the LACNIC address blocks: 16237 LACNIC Region origin ASes present in the Internet Routing Table: 1436 LACNIC Prefixes per ASN: 21.76 LACNIC Region origin ASes announcing only one prefix: 434 LACNIC Region transit ASes present in the Internet Routing Table: 265 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 19 Number of LACNIC region 32-bit ASNs visible in the Routing Table: 181 Number of LACNIC addresses announced to Internet: 81456768 Equivalent to 4 /8s, 218 /16s and 238 /24s Percentage of available LACNIC address space announced: 53.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 179/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: 7620 Total AfriNIC prefixes after maximum aggregation: 1814 AfriNIC Deaggregation factor: 4.20 Prefixes being announced from the AfriNIC address blocks: 5993 Unique aggregates announced from the AfriNIC address blocks: 1854 AfriNIC Region origin ASes present in the Internet Routing Table: 437 AfriNIC Prefixes per ASN: 13.71 AfriNIC Region origin ASes announcing only one prefix: 129 AfriNIC Region transit ASes present in the Internet Routing Table: 95 Average AfriNIC Region AS path length visible: 5.3 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC region 32-bit ASNs visible in the Routing Table: 5 Number of AfriNIC addresses announced to Internet: 22659584 Equivalent to 1 /8s, 89 /16s and 194 /24s Percentage of available AfriNIC address space announced: 33.8 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 102/8, 105/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 2409 9509 896 Korea Telecom (KIX) 7545 1553 301 83 TPG Internet Pty Ltd 4755 1481 653 159 TATA Communications formerly 17974 1455 480 33 PT TELEKOMUNIKASI INDONESIA 24560 1130 321 203 Bharti Airtel Ltd., Telemedia 9583 1055 77 493 Sify Limited 4808 1026 2096 294 CNCGROUP IP network: China169 9829 1004 868 53 BSNL National Internet Backbo 18101 938 116 142 Reliance Infocom Ltd Internet 17488 935 162 98 Hathway IP Over Cable Interne Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3673 3838 257 bellsouth.net, inc. 4323 2566 1093 401 Time Warner Telecom 1785 1786 681 131 PaeTec Communications, Inc. 18566 1606 331 195 Covad Communications 6478 1571 302 36 AT&T Worldnet Services 20115 1530 1540 650 Charter Communications 19262 1487 4935 303 Verizon Global Networks 7018 1357 6675 883 AT&T WorldNet Services 11492 1325 240 15 Cable One 22773 1285 2865 79 Cox Communications, Inc. Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6830 515 1780 318 UPC Distribution Services 3292 454 2013 391 TDC Tele Danmark 34984 454 95 205 BILISIM TELEKOM 8866 443 133 24 Bulgarian Telecommunication C 9198 422 267 15 Kazakhtelecom Data Network Ad 3320 412 7604 359 Deutsche Telekom AG 20940 411 98 317 Akamai Technologies European 8551 402 353 46 Bezeq International 12479 397 577 6 Uni2 Autonomous System 702 393 1800 307 UUNET - Commercial IP service Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 10620 1401 261 153 TVCABLE BOGOTA 28573 1248 970 83 NET Servicos de Comunicao S.A 8151 1236 2671 366 UniNet S.A. de C.V. 6503 1221 354 73 AVANTEL, S.A. 7303 923 465 148 Telecom Argentina Stet-France 14420 638 52 91 CORPORACION NACIONAL DE TELEC 22047 567 310 15 VTR PUNTO NET S.A. 3816 515 225 98 Empresa Nacional de Telecomun 13489 490 213 111 Orbitel S.A. E.S.P. 11172 487 83 80 Servicios Alestra S.A de C.V Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 843 445 11 TEDATA 24863 774 147 39 LINKdotNET AS number 15475 421 90 8 Nile Online 36992 298 271 14 Etisalat MISR 3741 265 985 227 The Internet Solution 24835 232 78 10 RAYA Telecom - Egypt 33776 230 13 5 Starcomms Nigeria Limited 6713 211 199 11 Itissalat Al-MAGHRIB 29571 192 17 11 Ci Telecom Autonomous system 16637 148 441 86 MTN Network Solutions Complete listing at http://thyme.rand.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3673 3838 257 bellsouth.net, inc. 4323 2566 1093 401 Time Warner Telecom 4766 2409 9509 896 Korea Telecom (KIX) 23456 2001 489 1093 32-bit ASN transition 1785 1786 681 131 PaeTec Communications, Inc. 18566 1606 331 195 Covad Communications 6478 1571 302 36 AT&T Worldnet Services 7545 1553 301 83 TPG Internet Pty Ltd 20115 1530 1540 650 Charter Communications 19262 1487 4935 303 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2566 2165 Time Warner Telecom 1785 1786 1655 PaeTec Communications, Inc. 6478 1571 1535 AT&T Worldnet Services 4766 2409 1513 Korea Telecom (KIX) 7545 1553 1470 TPG Internet Pty Ltd 17974 1455 1422 PT TELEKOMUNIKASI INDONESIA 18566 1606 1411 Covad Communications 4755 1481 1322 TATA Communications formerly 11492 1325 1310 Cable One 10620 1401 1248 TVCABLE BOGOTA Complete listing at http://thyme.rand.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 15132 UNALLOCATED 12.9.150.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.14.170.0/24 4323 Time Warner Telecom 13746 UNALLOCATED 12.24.56.0/24 7018 AT&T WorldNet Servic 32567 UNALLOCATED 12.25.107.0/24 4323 Time Warner Telecom 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 13317 UNALLOCATED 12.44.10.0/24 7018 AT&T WorldNet Servic Complete listing at http://thyme.rand.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 2.56.0.0/16 44559 E-Rent LLC 24.225.128.0/18 36377 Comcast Telecommunications, I 24.225.192.0/23 36377 Comcast Telecommunications, I 24.225.192.0/18 36377 Comcast Telecommunications, I 24.225.224.0/21 36377 Comcast Telecommunications, I 24.225.237.0/24 36377 Comcast Telecommunications, I 24.225.248.0/21 36377 Comcast Telecommunications, I 31.186.112.0/21 8681 Jersey Telecoms Island Networ 31.186.160.0/21 35467 DataCenter Fryslan AS 41.57.192.0/18 22750 BCSNET Complete listing at http://thyme.rand.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:19 /9:11 /10:26 /11:74 /12:218 /13:448 /14:766 /15:1370 /16:11586 /17:5699 /18:9423 /19:19078 /20:24728 /21:25237 /22:33660 /23:32188 /24:183717 /25:1131 /26:1289 /27:700 /28:40 /29:9 /30:2 /31:0 /32:6 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2267 3673 bellsouth.net, inc. 18566 1585 1606 Covad Communications 6478 1525 1571 AT&T Worldnet Services 4323 1377 2566 Time Warner Telecom 10620 1292 1401 TVCABLE BOGOTA 11492 1273 1325 Cable One 23456 1085 2001 32-bit ASN transition 7011 1063 1164 Citizens Utilities 1785 1056 1786 PaeTec Communications, Inc. 6503 997 1221 AVANTEL, S.A. Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:288 2:54 4:14 5:1 8:346 12:2020 13:1 14:429 15:15 16:3 17:8 20:9 23:3 24:1571 27:699 31:14 32:60 33:3 34:2 37:1 38:749 39:1 40:101 41:2367 44:3 46:750 47:4 49:146 50:119 52:13 55:5 56:2 57:30 58:817 59:500 60:387 61:1167 62:1005 63:1919 64:3881 65:2354 66:4375 67:1799 68:1061 69:2912 70:701 71:359 72:1900 73:1 74:2327 75:284 76:337 77:842 78:696 79:455 80:1087 81:826 82:511 83:463 84:647 85:1027 86:553 87:760 88:343 89:1567 90:176 91:3657 92:504 93:1044 94:1228 95:776 96:452 97:251 98:809 99:35 101:49 106:1 107:4 108:47 109:925 110:517 111:703 112:325 113:378 114:511 115:720 116:972 117:672 118:758 119:1096 120:281 121:760 122:1607 123:1059 124:1323 125:1256 128:234 129:171 130:173 131:564 132:101 133:20 134:216 135:49 136:212 137:142 138:299 139:112 140:485 141:173 142:380 143:391 144:476 145:52 146:440 147:192 148:634 149:271 150:167 151:187 152:298 153:180 154:3 155:389 156:185 157:347 158:131 159:377 160:313 161:208 162:278 163:165 164:493 165:350 166:501 167:413 168:721 169:155 170:776 171:70 172:2 173:1256 174:529 175:350 177:66 178:756 180:791 181:4 182:411 183:239 184:230 185:1 186:1106 187:899 188:918 189:1027 190:4732 192:5768 193:4788 194:3487 195:2939 196:1212 197:15 198:3591 199:3885 200:5581 201:1585 202:8395 203:8458 204:4114 205:2313 206:2647 207:3025 208:3907 209:3496 210:2725 211:1363 212:1953 213:1712 214:761 215:66 216:4881 217:1621 218:556 219:382 220:1192 221:478 222:317 223:103 End of report From ras at e-gerbil.net Fri Mar 25 13:39:17 2011 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Fri, 25 Mar 2011 13:39:17 -0500 Subject: Peering Traffic Volume In-Reply-To: References: Message-ID: <20110325183917.GO68199@gerbil.cluepon.net> On Thu, Mar 24, 2011 at 07:27:08PM -0400, Ravi Ramaswamy wrote: > Hi All - I am new to this mailer. Hopefully my question is posed to the > correct list. > > I am using 2.5 Tbps as the peak volume of peering traffic over all > peering points for a Tier 1 ISP, for some modeling purposes. Is that > a reasonable estimate? The largest Tier 1's, like say Level 3, and god help me for saying it but... Cogent, are certainly in or beyond that kind of ballpark. But most of the smaller ones, like say AT&T, Qwest, ATDN (if you even still want to count them), etc, not a chance in hell. And then there are plenty of non tier 1 networks (and some that aren't even actual single networks in the classic sense) that do far more traffic than that, for example some of the large CDNs like Akamai and LimeLight. On the modern Internet "most" of the traffic bypasses Tier 1 networks completely, going directly from content networks to eyeball networks, so the Tier 1's are effectively left as the higher priced and lower capacity "last resorts" for the remaining traffic. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From woody at pch.net Fri Mar 25 13:59:34 2011 From: woody at pch.net (Bill Woodcock) Date: Fri, 25 Mar 2011 11:59:34 -0700 Subject: Peering Traffic Volume In-Reply-To: <4B46DD5F-9C83-44B4-8556-D6B9900289ED@ianai.net> References: <4B46DD5F-9C83-44B4-8556-D6B9900289ED@ianai.net> Message-ID: On Mar 25, 2011, at 10:51 AM, Patrick W. Gilmore wrote: > The question is whether "some data" is better than "no data". Honestly, I'm not sure. Yes, Patrick, I was just trying to be diplomatic about saying "not such a good idea" so he'd keep reading through to the end, where I suggested some other, possibly better, research topics. I am, however, certain that other people could suggest even better research topics. Good research topics are in demonstrably short supply among networking grad-students, so if y'all want to be helpful... -Bill From millnert at gmail.com Fri Mar 25 14:04:43 2011 From: millnert at gmail.com (Martin Millnert) Date: Fri, 25 Mar 2011 15:04:43 -0400 Subject: The growth of municipal broadband networks In-Reply-To: <4D8CDF79.9060404@paulgraydon.co.uk> References: <4D8CDF79.9060404@paulgraydon.co.uk> Message-ID: Paul, On Fri, Mar 25, 2011 at 2:31 PM, Paul Graydon wrote: > http://arstechnica.com/tech-policy/news/2011/03/133-us-cities-now-run-their-own-broadband-networks.ars > > Ars Technica has a short article up about the growth of municipal networks, > but principally a nice little 'hey check out this website' > (http://www.muninetworks.org/communitymap) (snip) > I'm curious how the feeling is on NANOG about shifting such provision > towards municipal instead of corporations? ?I guess a rough summary of the > competing views I've heard so far are: (snip) With experience from Sweden, which has seen many varying incantations of these sort of networks, I have this hopefully useful bit to share: It's OK for tax-payer money to build layer-1 infrastructure if it decides so, that non-tax payer money can sell services on, but fail starts to happen the very moment they decide to go higher than that. That's... all. Regards, Martin From owen at delong.com Fri Mar 25 14:05:22 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Mar 2011 12:05:22 -0700 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <755995FD-1964-45F6-AC4C-04CF872B4571@corp.arin.net> Message-ID: <9592CE01-31D4-4866-934B-A84DF5E1665D@delong.com> On Mar 24, 2011, at 10:08 AM, Randy Bush wrote: >>>> They can only get them _at all_ if they can document need. All >>>> receipt of address space, whether from the free-pool or through a >>>> transfer, is needs-based. Anything else would be removing a critical >>>> resource from use. >>> http://en.wikipedia.org/wiki/Canute >> Thank you Randy. Give Canute a community-developed set of marching >> orders, and make the ocean a little more pliable and you might have >> something there. > > at some point, the arin policy wonk weenies will face reality. or not. > it really makes little difference. > > i don't particularly like the reality either, but i find it easier and > more productive to align my actions and how i spend my time. not a lot > of high paying jobs pushing water uphill. > > randy At some point we will see which reality actually pans out. Both the perspective of we "ARIN Policy wonk weenies" as Randy so kindly calls us, and, Randy's perspective are speculations about future events. I think both are probably equally based in reality based on different sets of experiences. Since my reality has the potential to preserve many good aspects of the internet, I hope it turns out that Randy is the one who is wrong. Owen From paul at paulstewart.org Fri Mar 25 14:10:51 2011 From: paul at paulstewart.org (Paul Stewart) Date: Fri, 25 Mar 2011 15:10:51 -0400 Subject: The growth of municipal broadband networks In-Reply-To: References: <4D8CDF79.9060404@paulgraydon.co.uk> Message-ID: <004c01cbeb20$5c363b90$14a2b2b0$@org> Highly agree with this experience being shared. We have had some dealings with municipal related fiber networks (not naming any names or giving any hints for obvious reasons) where shortly after providing the proposal to the customer, the municipal "sales vultures" went in and undercut our pricing (with Internet access included) to below what the fiber loop itself was priced at to us. Paul -----Original Message----- From: Martin Millnert [mailto:millnert at gmail.com] Sent: Friday, March 25, 2011 3:05 PM To: Paul Graydon Cc: nanog at nanog.org list Subject: Re: The growth of municipal broadband networks Paul, On Fri, Mar 25, 2011 at 2:31 PM, Paul Graydon wrote: > http://arstechnica.com/tech-policy/news/2011/03/133-us-cities-now-run-their- own-broadband-networks.ars > > Ars Technica has a short article up about the growth of municipal networks, > but principally a nice little 'hey check out this website' > (http://www.muninetworks.org/communitymap) (snip) > I'm curious how the feeling is on NANOG about shifting such provision > towards municipal instead of corporations? ?I guess a rough summary of the > competing views I've heard so far are: (snip) With experience from Sweden, which has seen many varying incantations of these sort of networks, I have this hopefully useful bit to share: It's OK for tax-payer money to build layer-1 infrastructure if it decides so, that non-tax payer money can sell services on, but fail starts to happen the very moment they decide to go higher than that. That's... all. Regards, Martin From owen at delong.com Fri Mar 25 14:33:53 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Mar 2011 12:33:53 -0700 Subject: Regional AS model In-Reply-To: <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> Message-ID: <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote: > On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote: >> On Mar 24, 2011, at 12:42 PM, Zaid Ali wrote: >> >>> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. >>> >>> Zaid >> >> If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable. > > We disagree. > > Single AS worldwide is fine with or without a backbone. > Only if you want to make use of ugly ugly BGP hacks on your routers, or, you don't care about Site A being able to hear announcements from Site B. > Which is "preferable" is up to you, your situation, and your personal tastes. (I guess one could argue that wasting AS numbers, or polluting the table with lots of AS numbers is bad or un-ashetically pleasing, but I think you should do whatever fits your situation anyway.) > I don't see any significant downside to AS number consumption given a 32-bit AS Number space. I do see significant downsides to disabling BGP loop detection. Owen From owen at delong.com Fri Mar 25 14:45:14 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Mar 2011 12:45:14 -0700 Subject: Regional AS model In-Reply-To: <87675028-2B60-4A52-8EC7-0CDD010CEAF8@pch.net> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <87675028-2B60-4A52-8EC7-0CDD010CEAF8@pch.net> Message-ID: <157A26AB-587D-4A50-B9F7-F7C481FA9A80@delong.com> On Mar 24, 2011, at 2:26 PM, Bill Woodcock wrote: > > On Mar 24, 2011, at 1:47 PM, Patrick W. Gilmore wrote: >> On Mar 24, 2011, at 3:40 PM, Owen DeLong wrote: >>> On Mar 24, 2011, at 12:42 PM, Zaid Ali wrote: >>> >>>> I have seen age old discussions on single AS vs multiple AS for backbone and datacenter design. I am particularly interested in operational challenges for running AS per region e.g. one AS for US, one EU etc or I have heard folks do one AS per DC. I particularly don't see any advantage in doing one AS per region or datacenter since most of the reasons I hear is to reduce the iBGP mesh. I generally prefer one AS and making use of confederation. >>> >>> If you have good backbone between the locations, then, it's mostly a matter of personal preference. If you have discreet autonomous sites that are not connected by internal circuits (not VPNs), then, AS per site is greatly preferable. >> >> We disagree. >> Single AS worldwide is fine with or without a backbone. >> Which is "preferable" is up to you, your situation, and your personal tastes. > > > We're with Patrick on this one. We operate a single AS across seventy-some-odd locations in dozens of countries, with very little of what an eyeball operator would call "backbone" between them, and we've never seen any potential benefit from splitting them. I think the management headache alone would be sufficient to make it unattractive to us. > > -Bill > > > > > To be clear, when I said backbone, I meant that if a packet arrives at site A destined for site B, it goes across some form of internal path and not back out to the internet. That Site A and Site B learn each other's routes via iBGP and not via third-party ASNs. If A learns B's addresses from a third party ASN, then, it is highly desirable (IMHO) to have A and B in separate ASNs. Owen From owen at delong.com Fri Mar 25 14:46:38 2011 From: owen at delong.com (Owen DeLong) Date: Fri, 25 Mar 2011 12:46:38 -0700 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> <27726811.0.1301002752950.JavaMail.franck@Macintosh-3.local> Message-ID: <520641E3-0024-4A3E-97ED-6765C06AA2CB@delong.com> On Mar 24, 2011, at 2:44 PM, George Herbert wrote: > On Thu, Mar 24, 2011 at 2:39 PM, Franck Martin wrote: >> >> >> ----- Original Message ----- >>> From: "Roland Dobbins" >>> To: "nanog group" >>> Sent: Friday, 25 March, 2011 9:33:27 AM >>> Subject: Re: The state-level attack on the SSL CA security model >>> On Mar 24, 2011, at 6:41 PM, Florian Weimer wrote: >>> >>>> Disclosure devalues information. >>> >>> >>> I think this case is different, given the perception of the cert as a >>> 'thing' to be bartered. >>> >> >> Isn't there any law that obliges company to disclose security breaches that involve consumer data? > > I don't think SSL certs are consumer data, per se. > No, but, a weak SSL cert in use by your company could disclose consumer data due to its weakness. Owen From bicknell at ufp.org Fri Mar 25 15:11:04 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 25 Mar 2011 13:11:04 -0700 Subject: The growth of municipal broadband networks In-Reply-To: <4D8CDF79.9060404@paulgraydon.co.uk> References: <4D8CDF79.9060404@paulgraydon.co.uk> Message-ID: <20110325201104.GA38866@ussenterprise.ufp.org> In a message written on Fri, Mar 25, 2011 at 08:31:21AM -1000, Paul Graydon wrote: > I'm curious how the feeling is on NANOG about shifting such provision > towards municipal instead of corporations? I guess a rough summary of > the competing views I've heard so far are: If you look at the services going into most homes, what you find are monopolies. Some are government run, some are regulated monopolies, and there are now lots of hybrid models. The funamental issue is that it is not cost effective to anyone (governments, corporations, or citizens) to build multiple gas, water, sewer, electrical, telephone or television distribution systems to every home. Remember that when these services were invisioned and first deployed telephone and television did not compete. It is only in very recent times that we have been able to overlay Internet on both cable and television, and to have television competition via satellite. To that end, I think the US would be much better off with fiber to the home on a single distribution infrastructure. That could be owned and operated by the municipality (like the water system) or owned and operated by a corporation granted an exclusive right to service an area (think telephone, at least pre CLEC). Where you immediately run into a snag is the next layer up. Should the government provide IP services, if the fiber is government owned? Should private companies be required to offer competitors access to provide IP services if the fiber is privately owned? There's a lot of space inside these questions for different models, and I think there are at least a half dozen in play in different communities. Having looked around the world I personally believe most communities would be best served if the government provided layer-1 distribution, possibly with some layer 2 switching, but then allowed any commercial entity to come in and offer layer 3 services. For simplicity of argument I like people to envision the local government fiber agency (like your water authority) dropping off a 1 port fiber 4 port copper switch in your basement. On that device they can create a layer 2 VLAN/VPN/Tunnel from any of the copper ports to any provider in the town CO. You could buy video from one, voice from one, and internet from another, on three different ports. You could buy everything from one provider. The actual deployments are a bit more complex, but I actually think if in new construction we could drop telephone and coax in the neighborhoods, and deploy fiber to the home it would be cheaper to construct, cheaper to operate in the long term, and would end up giving consumers a lot more choice. It is for all those reasons I expect any established business to be firmly against it. -- 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 cidr-report at potaroo.net Fri Mar 25 17:00:02 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Mar 2011 22:00:02 GMT Subject: BGP Update Report Message-ID: <201103252200.p2PM02iJ017047@wattle.apnic.net> BGP Update Report Interval: 17-Mar-11 -to- 24-Mar-11 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS42408 24658 1.6% 8219.3 -- TSV-AS JSC Company Transsviaz 2 - AS17224 24111 1.6% 1506.9 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 3 - AS9829 23312 1.5% 26.4 -- BSNL-NIB National Internet Backbone 4 - AS17974 20991 1.4% 25.4 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 5 - AS11492 20566 1.3% 16.4 -- CABLEONE - CABLE ONE, INC. 6 - AS9498 20249 1.3% 27.5 -- BBIL-AP BHARTI Airtel Ltd. 7 - AS3833 19462 1.3% 216.2 -- WYOMING - wyoming.com 8 - AS32528 18566 1.2% 4641.5 -- ABBOTT Abbot Labs 9 - AS35931 13636 0.9% 4545.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 10 - AS44609 12916 0.8% 4305.3 -- FNA Fars News Agency Cultural Arts Institute 11 - AS24560 12895 0.8% 11.7 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 12 - AS27984 11101 0.7% 92.5 -- Ver Tv S.A. 13 - AS27738 10714 0.7% 31.7 -- Ecuadortelecom S.A. 14 - AS17451 10166 0.7% 43.4 -- BIZNET-AS-AP BIZNET ISP 15 - AS14420 10000 0.7% 15.6 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 16 - AS25220 9703 0.6% 9703.0 -- GLOBALNOC-AS Averbo GmbH 17 - AS14522 9390 0.6% 21.9 -- Satnet 18 - AS45595 9189 0.6% 25.5 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited 19 - AS17488 7853 0.5% 12.1 -- HATHWAY-NET-AP Hathway IP Over Cable Internet 20 - AS7545 7327 0.5% 7.8 -- TPG-INTERNET-AP TPG Internet Pty Ltd TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS25220 9703 0.6% 9703.0 -- GLOBALNOC-AS Averbo GmbH 2 - AS42408 24658 1.6% 8219.3 -- TSV-AS JSC Company Transsviaz 3 - AS51280 6091 0.4% 6091.0 -- AS51280 Parsian Electronic Commerce Company 4 - AS32528 18566 1.2% 4641.5 -- ABBOTT Abbot Labs 5 - AS35931 13636 0.9% 4545.3 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS44609 12916 0.8% 4305.3 -- FNA Fars News Agency Cultural Arts Institute 7 - AS27217 4075 0.3% 4075.0 -- ACN-2 - America's Collectibles Network 8 - AS17225 1526 0.1% 1526.0 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 9 - AS17224 24111 1.6% 1506.9 -- ATT-CERFNET-BLOCK - AT&T Enhanced Network Services 10 - AS49600 1448 0.1% 1448.0 -- LASEDA La Seda de Barcelona, S.A 11 - AS17874 883 0.1% 883.0 -- NPC-AS-KR National Pension Corporation 12 - AS36912 605 0.0% 605.0 -- ORANGECM 13 - AS49042 584 0.0% 584.0 -- IPROCHIM-AS S.C. IPROCHIM S.A. 14 - AS22288 532 0.0% 532.0 -- RFBKCORP - Republic First Bancorp, Inc. 15 - AS28519 1560 0.1% 520.0 -- Universidad Autonoma de Guadalajara, A.C. 16 - AS56054 460 0.0% 460.0 -- ICON-INFOTECH-BD 5th floor, 56-57 Shareef Mention 17 - AS27771 906 0.1% 453.0 -- Instituto Venezolano de Investigaciones Cientificas 18 - AS51404 1246 0.1% 415.3 -- EULEX-AS EULEX Kosovo 19 - AS40220 391 0.0% 391.0 -- MATP - Virginia Polytechnic Institute and State Univ. 20 - AS38757 754 0.1% 377.0 -- ICONPLN-ID-AP PT. Indonesia Comnets Plus TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 79.98.204.0/22 12329 0.8% AS42408 -- TSV-AS JSC Company Transsviaz 2 - 79.98.200.0/22 12327 0.8% AS42408 -- TSV-AS JSC Company Transsviaz 3 - 202.92.235.0/24 11773 0.7% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 4 - 85.197.100.0/22 9703 0.6% AS25220 -- GLOBALNOC-AS Averbo GmbH 5 - 130.36.34.0/24 9275 0.6% AS32528 -- ABBOTT Abbot Labs 6 - 130.36.35.0/24 9274 0.6% AS32528 -- ABBOTT Abbot Labs 7 - 63.211.68.0/22 8045 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 178.22.79.0/24 6583 0.4% AS44609 -- FNA Fars News Agency Cultural Arts Institute 9 - 178.22.72.0/21 6317 0.4% AS44609 -- FNA Fars News Agency Cultural Arts Institute 10 - 212.80.25.0/24 6091 0.4% AS51280 -- AS51280 Parsian Electronic Commerce Company 11 - 198.140.43.0/24 5158 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 12 - 208.54.82.0/24 4562 0.3% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 13 - 221.121.96.0/19 4426 0.3% AS7491 -- PI-PH-AS-AP PI-PHILIPINES 14 - 207.106.153.0/24 4075 0.2% AS27217 -- ACN-2 - America's Collectibles Network 15 - 203.192.204.0/24 3415 0.2% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd. AS9498 -- BBIL-AP BHARTI Airtel Ltd. 16 - 203.192.205.0/24 3415 0.2% AS17665 -- IN2CABLE-AP AS Number of In2cable.com (India) Ltd. AS9498 -- BBIL-AP BHARTI Airtel Ltd. 17 - 68.65.152.0/22 3405 0.2% AS11915 -- TELWEST-NETWORK-SVCS-STATIC - TEL WEST COMMUNICATIONS LLC 18 - 206.184.16.0/24 3322 0.2% AS174 -- COGENT Cogent/PSI 19 - 202.153.174.0/24 3087 0.2% AS17408 -- ABOVE-AS-AP AboveNet Communications Taiwan 20 - 71.48.160.0/20 2045 0.1% AS6367 -- EMBARQ-KLLN - Embarq Corporation Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at nanog.org 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 Mar 25 17:00:00 2011 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 25 Mar 2011 22:00:00 GMT Subject: The Cidr Report Message-ID: <201103252200.p2PM009R017041@wattle.apnic.net> This report has been generated at Fri Mar 25 21:11:52 2011 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 18-03-11 352404 206330 19-03-11 352305 206075 20-03-11 352153 206215 21-03-11 352269 207080 22-03-11 353819 207152 23-03-11 354047 207333 24-03-11 354043 207499 25-03-11 354537 207882 AS Summary 37183 Number of ASes in routing system 15655 Number of ASes announcing only one prefix 3673 Largest number of prefixes announced by an AS AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc. 109187584 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'). --- 25Mar11 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 354575 207822 146753 41.4% All ASes AS6389 3673 262 3411 92.9% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 2557 405 2152 84.2% TWTC - tw telecom holdings, inc. AS4766 2409 915 1494 62.0% KIXS-AS-KR Korea Telecom AS6478 1571 167 1404 89.4% ATT-INTERNET3 - AT&T Services, Inc. AS22773 1285 88 1197 93.2% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS19262 1487 303 1184 79.6% VZGNI-TRANSIT - Verizon Online LLC AS4755 1483 369 1114 75.1% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS10620 1401 349 1052 75.1% Telmex Colombia S.A. AS1785 1789 768 1021 57.1% AS-PAETEC-NET - PaeTec Communications, Inc. AS18566 1606 628 978 60.9% COVAD - Covad Communications Co. AS28573 1250 323 927 74.2% NET Servicos de Comunicao S.A. AS6503 1226 409 817 66.6% Axtel, S.A.B. de C.V. AS7545 1554 754 800 51.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS18101 935 152 783 83.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7303 922 194 728 79.0% Telecom Argentina S.A. AS8151 1245 529 716 57.5% Uninet S.A. de C.V. AS4808 1030 332 698 67.8% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS3356 1174 485 689 58.7% LEVEL3 Level 3 Communications AS11492 1325 645 680 51.3% CABLEONE - CABLE ONE, INC. AS17488 935 279 656 70.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4780 884 233 651 73.6% SEEDNET Digital United Inc. AS17676 657 70 587 89.3% GIGAINFRA Softbank BB Corp. AS855 640 58 582 90.9% CANET-ASN-4 - Bell Aliant Regional Communications, Inc. AS17908 624 67 557 89.3% TCISL Tata Communications AS24560 1130 585 545 48.2% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS3549 921 382 539 58.5% GBLX Global Crossing Ltd. AS22047 567 30 537 94.7% VTR BANDA ANCHA S.A. AS14420 638 103 535 83.9% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP AS22561 860 327 533 62.0% DIGITAL-TELEPORT - Digital Teleport Inc. AS9498 777 262 515 66.3% BBIL-AP BHARTI Airtel Ltd. Total 38555 10473 28082 72.8% Top 30 total Possible Bogus Routes 2.56.0.0/16 AS44559 10.86.64.32/30 AS65530 -Private Use AS- 10.86.64.36/30 AS65530 -Private Use AS- 10.86.65.32/30 AS65530 -Private Use AS- 10.86.65.36/30 AS65530 -Private Use AS- 10.255.255.0/30 AS65530 -Private Use AS- 10.255.255.4/30 AS65530 -Private Use AS- 10.255.255.8/30 AS65530 -Private Use AS- 24.48.0.0/14 AS5769 VIDEOTRON - Videotron Telecom Ltee 24.225.128.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/18 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.192.0/23 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.224.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.237.0/24 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 24.225.248.0/21 AS36377 PATRIOT-MEDIA-NJ - Comcast Telecommunications, Inc. 31.187.112.0/20 AS35776 TELEOS Teleos 41.57.192.0/18 AS22750 BCSNET 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 45.127.0.0/16 AS13767 DBANK - DataBank Holdings, Ltd. 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 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.207.192.0/24 AS30304 64.207.193.0/24 AS30304 64.207.194.0/24 AS30304 64.207.195.0/24 AS30304 64.207.196.0/24 AS30304 64.207.197.0/24 AS30304 64.207.198.0/24 AS30304 64.207.200.0/24 AS30304 64.207.201.0/24 AS30304 64.207.202.0/24 AS30304 64.207.203.0/24 AS30304 64.207.204.0/24 AS30304 64.207.205.0/24 AS30304 64.207.206.0/24 AS30304 64.207.208.0/20 AS30304 66.171.32.0/20 AS16626 GNAXNET-AS - Global Net Access, LLC 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 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 71.19.134.0/23 AS3313 INET-AS I.NET S.p.A. 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 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.40.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.42.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.44.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.47.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.48.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.49.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.50.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.51.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.52.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.53.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.54.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.55.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.56.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.57.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.58.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.59.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.61.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.62.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.63.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 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 142.54.0.0/19 AS23498 CDSI - Cogeco Data Services Inc. 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 172.33.69.0/24 AS36992 ETISALAT-MISR 172.102.0.0/22 AS4812 CHINANET-SH-AP China Telecom (Group) 190.102.32.0/20 AS30058 FDCSERVERS - FDCservers.net 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.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 G-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.145.251.0/24 AS10026 PACNET Pacnet Global Ltd 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.162.18.0/24 AS31151 192.188.208.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 194.106.198.0/24 AS49544 INTERACTIVE3D-AS Interactive3D 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.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.15.4.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.15.5.0/24 AS4323 TWTC - tw telecom holdings, inc. 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 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 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.96.0/19 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.97.240.0/20 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 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.175.231.0/24 AS19262 VZGNI-TRANSIT - Verizon Online LLC 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.123.16.0/20 AS721 DNIC-ASBLK-00721-00726 - 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.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. 200.24.73.0/24 AS26061 Equant Colombia 200.24.76.0/24 AS7195 Telecorp Colombia S.A. 200.24.78.0/26 AS3549 GBLX Global Crossing Ltd. 200.24.78.64/26 AS3549 GBLX Global Crossing Ltd. 202.1.224.0/24 AS10097 FLOWCOM Flow Communications 2/541 Kent St Sydney NSW 2000 202.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.20.108.0/23 AS17885 JKTXLNET-AS-AP PT Excelcomindo Pratama 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.74.232.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.74.233.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.83.120.0/21 AS37972 202.83.124.0/24 AS37972 202.83.125.0/24 AS37972 202.83.126.0/24 AS37972 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.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.146.186.0/24 AS23655 SNAP-NZ-AS Snap Internet Limited 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 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.131.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.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.18.156.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.22.78.0/24 AS18117 HARBOURMSP-AU-AP Harbour MSP Pty. Ltd 203.23.1.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.24.38.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.27.123.0/24 AS4739 INTERNODE-AS Internode Pty Ltd 203.30.26.0/23 AS3491 BTN-ASN - Beyond The Network America, Inc. 203.30.127.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/23 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.86.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.87.0/24 AS18111 NETSPEED-AS-AP Netspeed Internet Communications 203.32.188.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone 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 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 204.9.216.0/23 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 204.10.232.0/21 AS33150 204.19.14.0/23 AS577 BACOM - Bell Canada 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.175.214.0/24 AS5583 ORANGE-BUSINESS-SERVICES-BENELUX Orange Business Services (formerly Equant) AS for BENELUX 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.207.148.0/23 AS812 ROGERS-CABLE - Rogers Cable Communications Inc. 206.72.192.0/23 AS16526 BIRCH-TELECOM - Birch Telecom, Inc. 206.72.194.0/23 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.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.64.240.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.241.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.242.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.243.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.244.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.64.247.0/24 AS13871 TELEBYTE-NW - Telebyte NW 208.73.160.0/24 AS32767 208.78.165.0/24 AS16565 208.83.53.0/24 AS40569 YGOMI-AS - Ygomi LLC 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.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.177.64.0/20 AS6461 MFNX MFN - Metromedia Fiber Network 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 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 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.105.192.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.196.0/23 AS7385 INTEGRATELECOM - Integra Telecom, Inc. 216.105.200.0/21 AS7385 INTEGRATELECOM - Integra Telecom, 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.194.160.0/20 AS13818 PHX-INTL-TELEPORT - Phoenix International Teleport 221.120.112.0/21 AS7700 SINGTEL-DVBIP-AS-AP SINGAPORE TELECOMMUNICATIONS LTD Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at nanog.org eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jra at baylink.com Fri Mar 25 20:43:44 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 25 Mar 2011 21:43:44 -0400 (EDT) Subject: The growth of municipal broadband networks In-Reply-To: <4D8CDF79.9060404@paulgraydon.co.uk> Message-ID: <19504597.398.1301103824743.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Paul Graydon" > I'm curious how the feeling is on NANOG about shifting such provision > towards municipal instead of corporations? I guess a rough summary of > the competing views I've heard so far are: Oh, look. A hobby horse. My opinion is a third: that last-mile fiber is, for several reasons, a Natural Monopoly, and having municipalities operate it, and farm their residents out as customers to any comer to the meet-me room, is the natural end-game ... and the sooner we get to it, the better. The problem is that many states have made it *illegal* for muni's to do this, encouraged, unsurprisingly, in many cases, by Verizon (who desperately needs FiOS to fly, because they've cut-to-clear in their copper plant for so many *decades* now that it's unsalvageable). Check the archives; I think I brought this up myself about 6 months ago. Cheers, -- jra From jra at baylink.com Fri Mar 25 20:46:27 2011 From: jra at baylink.com (Jay Ashworth) Date: Fri, 25 Mar 2011 21:46:27 -0400 (EDT) Subject: The growth of municipal broadband networks In-Reply-To: <20110325201104.GA38866@ussenterprise.ufp.org> Message-ID: <19158564.404.1301103987428.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Leo Bicknell" > Having looked around the world I personally believe most communities > would be best served if the government provided layer-1 distribution, > possibly with some layer 2 switching, but then allowed any commercial > entity to come in and offer layer 3 services. For simplicity of > argument I like people to envision the local government fiber agency > (like your water authority) dropping off a 1 port fiber 4 port > copper switch in your basement. On that device they can create a > layer 2 VLAN/VPN/Tunnel from any of the copper ports to any provider > in the town CO. You could buy video from one, voice from one, and > internet from another, on three different ports. You could buy > everything from one provider. +5 Cheers, -- jra From nanog at deman.com Fri Mar 25 20:54:56 2011 From: nanog at deman.com (Michael DeMan) Date: Fri, 25 Mar 2011 18:54:56 -0700 Subject: Nortel, in bankruptcy, sells IPv4 address block for $7.5 million In-Reply-To: <9592CE01-31D4-4866-934B-A84DF5E1665D@delong.com> References: <20110324125757.GG23560@leitl.org> <4D8B47E5.9010709@spectraaccess.com> <20110324140821.GA57022@ussenterprise.ufp.org> <4D8B57DB.7080602@redpill-linpro.com> <1CE5632A-F1A4-4ABA-B3AF-7C86B754B384@pch.net> <755995FD-1964-45F6-AC4C-04CF872B4571@corp.arin.net> <9592CE01-31D4-4866-934B-A84DF5E1665D@delong.com> Message-ID: <3857F449-A084-443A-BE5E-3DF334242F08@deman.com> On Mar 25, 2011, at 12:05 PM, Owen DeLong wrote: > > On Mar 24, 2011, at 10:08 AM, Randy Bush wrote: > >>>>> They can only get them _at all_ if they can document need. All >>>>> receipt of address space, whether from the free-pool or through a >>>>> transfer, is needs-based. Anything else would be removing a critical >>>>> resource from use. >>>> http://en.wikipedia.org/wiki/Canute >>> Thank you Randy. Give Canute a community-developed set of marching >>> orders, and make the ocean a little more pliable and you might have >>> something there. >> >> at some point, the arin policy wonk weenies will face reality. or not. >> it really makes little difference. >> >> i don't particularly like the reality either, but i find it easier and >> more productive to align my actions and how i spend my time. not a lot >> of high paying jobs pushing water uphill. >> >> randy > > At some point we will see which reality actually pans out. Both the perspective > of we "ARIN Policy wonk weenies" as Randy so kindly calls us, and, Randy's > perspective are speculations about future events. I think both are probably equally > based in reality based on different sets of experiences. > > Since my reality has the potential to preserve many good aspects of the internet, > I hope it turns out that Randy is the one who is wrong. > > Owen > Or possibly, if we can not sort this on our own and set a good precedent (for ARIN and the other registries as well) that we can sort this out ourselves in a way that is agreeable and beneficial to all stakeholders - we will just be adding another piece of lumber onto the ready-to-light bonfire that government needs to step in somehow? - Mike From adrian at creative.net.au Fri Mar 25 21:02:19 2011 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 26 Mar 2011 10:02:19 +0800 Subject: The growth of municipal broadband networks In-Reply-To: <20110325201104.GA38866@ussenterprise.ufp.org> References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> Message-ID: <20110326020219.GF24101@skywalker.creative.net.au> On Fri, Mar 25, 2011, Leo Bicknell wrote: > Having looked around the world I personally believe most communities > would be best served if the government provided layer-1 distribution, > possibly with some layer 2 switching, but then allowed any commercial > entity to come in and offer layer 3 services. For simplicity of > argument I like people to envision the local government fiber agency > (like your water authority) dropping off a 1 port fiber 4 port > copper switch in your basement. On that device they can create a > layer 2 VLAN/VPN/Tunnel from any of the copper ports to any provider > in the town CO. You could buy video from one, voice from one, and > internet from another, on three different ports. You could buy > everything from one provider. And the natural question is - how will this differ from the way the "government" services like water, power and transportation have been run, privatised-but-not-quite, etc? Adrian From rdunniii at mac.com Fri Mar 25 21:08:56 2011 From: rdunniii at mac.com (Richard Dunn) Date: Fri, 25 Mar 2011 19:08:56 -0700 Subject: Which internal WAN protocol? Message-ID: <57A9225B-962F-4F5F-8547-1FCC4FAF7DED@mac.com> I would appreciate it if list members could tell me which WAN routing protocol(s) you use and why? If you have changed from one to another what did you change from to and why did you make the changeover? If you use multiple protocols or same protocol redistribution for specific or other reasons if you could explain why I would appreciate it. On or off list as you prefer. Thank you. Richard From millnert at gmail.com Fri Mar 25 21:13:17 2011 From: millnert at gmail.com (Martin Millnert) Date: Fri, 25 Mar 2011 22:13:17 -0400 Subject: The growth of municipal broadband networks In-Reply-To: <19158564.404.1301103987428.JavaMail.root@benjamin.baylink.com> References: <20110325201104.GA38866@ussenterprise.ufp.org> <19158564.404.1301103987428.JavaMail.root@benjamin.baylink.com> Message-ID: Jay, On Fri, Mar 25, 2011 at 9:46 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Leo Bicknell" > >> Having looked around the world I personally believe most communities >> would be best served if the government provided layer-1 distribution, >> possibly with some layer 2 switching, but then allowed any commercial >> entity to come in and offer layer 3 services. > +5 I've seen several cases of these types of networks rolling out the MPLS cloud, oversubscribing ad infinitum, with lots of active network equipment, which all in all in the end doesn't add *anything* more to the end-user than hundredths or thousandths or even less of their end-to-end link capacity, between them and the service-offering ISPs. I'm very wary of doing more L2 than essentially required, and believe it is much more sane to invest a bit extra in the L1, and skip investments at this level in L2 entirely. Handing of L1 to providers works perfectly fine, and adds no over-subscription. The only issue with what I describe above is that it complicates the multiple-vendors-over-the-same-pipe a little bit. Voice and video works pretty fine over IP, though, last I checked. With a few new L1 network devices, the above should become even more feasible. Convincing people they can build a network infrastructure without switches is nearly fated for complete doom, though... (Perhaps giving them some LED panels with high-power fans will satisfy their need for blinkenlights?) Regards, Martin From gbonser at seven.com Fri Mar 25 21:52:22 2011 From: gbonser at seven.com (George Bonser) Date: Fri, 25 Mar 2011 19:52:22 -0700 Subject: The growth of municipal broadband networks In-Reply-To: <20110325201104.GA38866@ussenterprise.ufp.org> References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> > > It is only in very recent times that we have been able to overlay > Internet on both cable and television, and to have television > competition via satellite. In "the old days" the phone company didn't provide "content". You called someone and the people at each end provided the content or the data going over the network. The phone company simply provided the network. I still believe the biggest mistake we made was breaking up the Bell System. We should have let them be, regulated the crap out of them, and then said "no, you can't get into the business of providing content". They system should have been left as a regulated public utility. > To that end, I think the US would be much better off with fiber to the > home on a single distribution infrastructure. That could be owned and > operated by the municipality (like the water system) or owned and > operated by a corporation granted an exclusive right to service an area > (think telephone, at least pre CLEC). Yup, bring back "The Bell System". > Where you immediately run into a snag is the next layer up. Should the > government provide IP services, if the fiber is government owned? > Should private companies be required to offer competitors access to > provide IP services if the fiber is privately owned? I would say they provide network access only, not content. They would be kept out of providing content and kept in the business of reliably connecting content to consumer. That would be their focus. > Having looked around the world I personally believe most communities > would be best served if the government provided layer-1 distribution, > possibly with some layer 2 switching, but then allowed any commercial > entity to come in and offer layer 3 services. I don't. What happens when the "government" then decides what content is and is not allowed to go over their network? If one had a site that provided a view that the government didn't like, would they cut it off? I want the government very strictly limited in what they can and cannot do and I want them to have to go to an outside entity for things like lawful intercept because it is another check on their power. A private entity might insist that there is a proper warrant or subpoena while the government might simply decide to snoop first, get the paperwork later. Keeping the network at arm's length from the government helps to make sure there is another entity in the loop. > For simplicity of > argument I like people to envision the local government fiber agency > (like your water authority) dropping off a 1 port fiber 4 port copper > switch in your basement. Big difference. Water is not a good analogy. The "content" in that case is from a central source and everyone gets the same thing. With the network, you have people communicating back and forth and much of that communications is private or expected to be private (say, a phone call or a secure financial transaction). If a private entity screws up, it is much easier to fine them or fire the person responsible than it is to punish a government department or fire a government worker. Besides, we really don't need yet more people on the government payroll. Though I do agree that it is a natural monopoly. It should be managed by a regulated utility that is explicitly prohibited from providing the content, only provide access through the network. From smb at cs.columbia.edu Fri Mar 25 22:12:29 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 25 Mar 2011 23:12:29 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <21155.1301069099@localhost> Message-ID: <41AF4E08-178B-4462-A9EC-6FFAE199340B@cs.columbia.edu> On Mar 25, 2011, at 12:19 52PM, Akyol, Bora A wrote: > One could argue that you could try something like the facebook model (or facebook itself). I can see it coming. > Facebook web of trust app ;-) > Except, of course, for the fact that people tend to have hundreds of "friends", many of whom they don't know at all, and who achieved that status simply by asking. You need a much stronger notion of interaction, to say nothing of what the malware in your "friends'" computers are doing to simulate such interaction. --Steve Bellovin, http://www.cs.columbia.edu/~smb From joseph.sniderman at thoroquel.org Fri Mar 25 22:36:12 2011 From: joseph.sniderman at thoroquel.org (Joe Sniderman) Date: Fri, 25 Mar 2011 23:36:12 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: <41AF4E08-178B-4462-A9EC-6FFAE199340B@cs.columbia.edu> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <21155.1301069099@localhost> <41AF4E08-178B-4462-A9EC-6FFAE199340B@cs.columbia.edu> Message-ID: <4D8D5F2C.4050402@thoroquel.org> On 03/25/2011 11:12 PM, Steven Bellovin wrote: > > On Mar 25, 2011, at 12:19 52PM, Akyol, Bora A wrote: > >> One could argue that you could try something like the facebook >> model (or facebook itself). I can see it coming. Facebook web of >> trust app ;-) >> > Except, of course, for the fact that people tend to have hundreds of > "friends", many of whom they don't know at all, and who achieved that > status simply by asking. You need a much stronger notion of > interaction, to say nothing of what the malware in your "friends'" > computers are doing to simulate such interaction. Then again there are all the "friend us for a chance to win $prize" gimmicks... not a far jump to "friend us, _with trust bits enabled_ for a chance to win $prize" Yeah sounds like a wonderful idea. :P -- Joe Sniderman From fmartin at linkedin.com Fri Mar 25 23:21:12 2011 From: fmartin at linkedin.com (Franck Martin) Date: Sat, 26 Mar 2011 04:21:12 +0000 Subject: The state-level attack on the SSL CA security model In-Reply-To: <4D8D5F2C.4050402@thoroquel.org> Message-ID: On 3/26/11 15:36 , "Joe Sniderman" wrote: >On 03/25/2011 11:12 PM, Steven Bellovin wrote: >> >> On Mar 25, 2011, at 12:19 52PM, Akyol, Bora A wrote: >> >>> One could argue that you could try something like the facebook >>> model (or facebook itself). I can see it coming. Facebook web of >>> trust app ;-) >>> >> Except, of course, for the fact that people tend to have hundreds of >> "friends", many of whom they don't know at all, and who achieved that >> status simply by asking. You need a much stronger notion of >> interaction, to say nothing of what the malware in your "friends'" >> computers are doing to simulate such interaction. > >Then again there are all the "friend us for a chance to win $prize" >gimmicks... not a far jump to "friend us, _with trust bits enabled_ for >a chance to win $prize" > >Yeah sounds like a wonderful idea. :P Wasn't PGP based on a web of trust too? From joly at punkcast.com Sat Mar 26 00:27:57 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 26 Mar 2011 01:27:57 -0400 Subject: The growth of municipal broadband networks In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> Message-ID: aka the "separation principle" ( Tim Wu - the Master Switch) What surprised me is that when I put his point to Richard R.John at the Columbia Big media event back in Nov - John totally agreed with it, citing the precedent of the telegraph companies being locked out of the telephone business back in the day. j On Fri, Mar 25, 2011 at 10:52 PM, George Bonser wrote: > > > > It is only in very recent times that we have been able to overlay > > Internet on both cable and television, and to have television > > competition via satellite. > > In "the old days" the phone company didn't provide "content". You > called someone and the people at each end provided the content or the > data going over the network. The phone company simply provided the > network. I still believe the biggest mistake we made was breaking up > the Bell System. We should have let them be, regulated the crap out of > them, and then said "no, you can't get into the business of providing > content". They system should have been left as a regulated public > utility. > > > To that end, I think the US would be much better off with fiber to the > > home on a single distribution infrastructure. That could be owned and > > operated by the municipality (like the water system) or owned and > > operated by a corporation granted an exclusive right to service an > area > > (think telephone, at least pre CLEC). > > Yup, bring back "The Bell System". > > > > Where you immediately run into a snag is the next layer up. Should > the > > government provide IP services, if the fiber is government owned? > > Should private companies be required to offer competitors access to > > provide IP services if the fiber is privately owned? > > I would say they provide network access only, not content. They would > be kept out of providing content and kept in the business of reliably > connecting content to consumer. That would be their focus. > > > Having looked around the world I personally believe most communities > > would be best served if the government provided layer-1 distribution, > > possibly with some layer 2 switching, but then allowed any commercial > > entity to come in and offer layer 3 services. > > I don't. What happens when the "government" then decides what content > is and is not allowed to go over their network? If one had a site that > provided a view that the government didn't like, would they cut it off? > I want the government very strictly limited in what they can and cannot > do and I want them to have to go to an outside entity for things like > lawful intercept because it is another check on their power. A private > entity might insist that there is a proper warrant or subpoena while the > government might simply decide to snoop first, get the paperwork later. > Keeping the network at arm's length from the government helps to make > sure there is another entity in the loop. > > > For simplicity of > > argument I like people to envision the local government fiber agency > > (like your water authority) dropping off a 1 port fiber 4 port copper > > switch in your basement. > > Big difference. Water is not a good analogy. The "content" in that > case is from a central source and everyone gets the same thing. With > the network, you have people communicating back and forth and much of > that communications is private or expected to be private (say, a phone > call or a secure financial transaction). If a private entity screws up, > it is much easier to fine them or fire the person responsible than it is > to punish a government department or fire a government worker. Besides, > we really don't need yet more people on the government payroll. > > Though I do agree that it is a natural monopoly. It should be managed > by a regulated utility that is explicitly prohibited from providing the > content, only provide access through the network. > > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From swmike at swm.pp.se Sat Mar 26 00:35:28 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 26 Mar 2011 06:35:28 +0100 (CET) Subject: Which internal WAN protocol? In-Reply-To: <57A9225B-962F-4F5F-8547-1FCC4FAF7DED@mac.com> References: <57A9225B-962F-4F5F-8547-1FCC4FAF7DED@mac.com> Message-ID: On Fri, 25 Mar 2011, Richard Dunn wrote: > I would appreciate it if list members could tell me which WAN routing > protocol(s) you use and why? If you have changed from one to another > what did you change from to and why did you make the changeover? If you > use multiple protocols or same protocol redistribution for specific or > other reasons if you could explain why I would appreciate it. On or off > list as you prefer. If you google for "isp essentials" the first hit is a pdf from 2003. It has a lot of best common practice for ISPs and I'd say all of it is still valid. If it doesn't answer your question, after reading it at least you should be able to ask a question that is easier to answer. -- Mikael Abrahamsson email: swmike at swm.pp.se From jsw at inconcepts.biz Sat Mar 26 00:45:18 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Sat, 26 Mar 2011 01:45:18 -0400 Subject: The growth of municipal broadband networks In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> Message-ID: On Fri, Mar 25, 2011 at 10:52 PM, George Bonser wrote: > I don't. ?What happens when the "government" then decides what content > is and is not allowed to go over their network? ?If one had a site that > provided a view that the government didn't like, would they cut it off? I appreciate your argument. When asked by Uncle Sam, the major RBOCs were apparently happy to hand over customers' records and tap into their phones in direct violation of the law. *Asked* not ordered by a court or any legally-empowered person or entity. The companies and LEOs then had to fight for RETROACTIVE PROTECTION FROM THEIR WILLFUL VIOLATIONS OF THE LAW, which was granted by our federal legislature. I think we would be far, far better off, from the perspective of liberty, with a thousand small last-mile providers, some of which will hopefully be owned by cities/counties/states and some of which would hopefully be privately-operated. It's a lot harder to coerce (or just ask) a thousand small access providers to block some "objectionable" or "dangerous" content or activity without getting caught than it is to do the same if there are only a handful of access providers. Since there is no "liberty" advantage, in the real world, to a system where AT&T controls the last-mile or states, counties, or private contractors control same, I would choose the one most likely to create a competitive business environment. We already know that homes without cable television and Internet service are less valuable than homes which have access to these services. I hope that communities would develop and maintain the best last-mile networks they can in order to attract businesses and residents with the most money to spend, and the most to contribute to their tax bases, job market, and skilled labor pool. In an ideal world, I could agree with you. But you don't need a tin-foil hat anymore to be absolutely certain that big brother has over-stepped his bounds and will continue to do so even in an environment where private businesses *could* be an obstacle. Guess what, they aren't. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From swmike at swm.pp.se Sat Mar 26 00:56:10 2011 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sat, 26 Mar 2011 06:56:10 +0100 (CET) Subject: The growth of municipal broadband networks In-Reply-To: <20110325201104.GA38866@ussenterprise.ufp.org> References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> Message-ID: On Fri, 25 Mar 2011, Leo Bicknell wrote: > To that end, I think the US would be much better off with fiber to the > home on a single distribution infrastructure. That could be owned and > operated by the municipality (like the water system) or owned and > operated by a corporation granted an exclusive right to service an area > (think telephone, at least pre CLEC). +1. The layout of the old copper telephone layout is basically sound, you aggregate thousands of households via X length of cable into a single place, then you let anyone who wants to, rent space/power in there to put in their equipment and rent this fiber to the end user household/enterprise. Do this with fiber to the home, and also provide rentable long haul fiber (to the next town etc) and rent out this infrastructure at decent pricepoint, you have a situation with a very low entry-cost for new players which is great for competition and in the long run, for the end customer. -- Mikael Abrahamsson email: swmike at swm.pp.se From richard at bennett.com Sat Mar 26 01:01:01 2011 From: richard at bennett.com (Richard Bennett) Date: Fri, 25 Mar 2011 23:01:01 -0700 Subject: The growth of municipal broadband networks In-Reply-To: References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> Message-ID: <4D8D811D.9070604@bennett.com> The principle that kept telegraph and telephone apart wasn't a functional layering concept, it was a "technology silos" concept under which all communication networks were assumed to be indistinguishable from their one and only one application. If you read the Communications Act of 1934, you'll see this idea embodied in the titles of the act, each of which describes both a network and an application, as we understand the terms today. Wu wants to make law out of the OSI model, a very different enterprise than traditional telecom regulation. On 3/25/2011 10:27 PM, Joly MacFie wrote: > aka the "separation principle" ( Tim Wu - the Master Switch) > > What surprised me is that when I put his point to Richard R.John at the > Columbia Big media event back in Nov > - John totally agreed with it, citing the > precedent of the telegraph companies being locked out of the telephone > business back in the day. > > j > > > On Fri, Mar 25, 2011 at 10:52 PM, George Bonser wrote: > >>> It is only in very recent times that we have been able to overlay >>> Internet on both cable and television, and to have television >>> competition via satellite. >> In "the old days" the phone company didn't provide "content". You >> called someone and the people at each end provided the content or the >> data going over the network. The phone company simply provided the >> network. I still believe the biggest mistake we made was breaking up >> the Bell System. We should have let them be, regulated the crap out of >> them, and then said "no, you can't get into the business of providing >> content". They system should have been left as a regulated public >> utility. >> >>> To that end, I think the US would be much better off with fiber to the >>> home on a single distribution infrastructure. That could be owned and >>> operated by the municipality (like the water system) or owned and >>> operated by a corporation granted an exclusive right to service an >> area >>> (think telephone, at least pre CLEC). >> Yup, bring back "The Bell System". >> >> >>> Where you immediately run into a snag is the next layer up. Should >> the >>> government provide IP services, if the fiber is government owned? >>> Should private companies be required to offer competitors access to >>> provide IP services if the fiber is privately owned? >> I would say they provide network access only, not content. They would >> be kept out of providing content and kept in the business of reliably >> connecting content to consumer. That would be their focus. >> >>> Having looked around the world I personally believe most communities >>> would be best served if the government provided layer-1 distribution, >>> possibly with some layer 2 switching, but then allowed any commercial >>> entity to come in and offer layer 3 services. >> I don't. What happens when the "government" then decides what content >> is and is not allowed to go over their network? If one had a site that >> provided a view that the government didn't like, would they cut it off? >> I want the government very strictly limited in what they can and cannot >> do and I want them to have to go to an outside entity for things like >> lawful intercept because it is another check on their power. A private >> entity might insist that there is a proper warrant or subpoena while the >> government might simply decide to snoop first, get the paperwork later. >> Keeping the network at arm's length from the government helps to make >> sure there is another entity in the loop. >> >>> For simplicity of >>> argument I like people to envision the local government fiber agency >>> (like your water authority) dropping off a 1 port fiber 4 port copper >>> switch in your basement. >> Big difference. Water is not a good analogy. The "content" in that >> case is from a central source and everyone gets the same thing. With >> the network, you have people communicating back and forth and much of >> that communications is private or expected to be private (say, a phone >> call or a secure financial transaction). If a private entity screws up, >> it is much easier to fine them or fire the person responsible than it is >> to punish a government department or fire a government worker. Besides, >> we really don't need yet more people on the government payroll. >> >> Though I do agree that it is a natural monopoly. It should be managed >> by a regulated utility that is explicitly prohibited from providing the >> content, only provide access through the network. >> >> >> >> > -- Richard Bennett From joly at punkcast.com Sat Mar 26 01:48:09 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 26 Mar 2011 02:48:09 -0400 Subject: The growth of municipal broadband networks In-Reply-To: <4D8D811D.9070604@bennett.com> References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> <4D8D811D.9070604@bennett.com> Message-ID: I take your point, the separation was of a different order. But a separation, nonetheless. The motive is not so much different. I think we can all accept that "traditional telephone regulation" is rapidly losing its grip as the beast morphs. Now that applications outnumber networks new problems require new solutions. I've heard Allied Fiber's Hunter Newby argue convincingly that really it's about separating Level 0 - the real estate, the wires and the head end premises - from everything else, and facilitating sufficient open access to guarantee healthy competition in services. And yes, where there's a monopoly there will have to some price regulation. At least that's traditional. As we've seen in the UK, while it's not so much a stretch to impose even higher level unbundling on the telcos, when it comes to the cable industry it's going to be a very painful pulling of teeth. http://www.telecomtv.com/comspace_newsDetail.aspx?n=46077&id=e9381817-0593-417a-8639-c4c53e2a2a10 j On Sat, Mar 26, 2011 at 2:01 AM, Richard Bennett wrote: > The principle that kept telegraph and telephone apart wasn't a functional > layering concept, it was a "technology silos" concept under which all > communication networks were assumed to be indistinguishable from their one > and only one application. If you read the Communications Act of 1934, you'll > see this idea embodied in the titles of the act, each of which describes > both a network and an application, as we understand the terms today. Wu > wants to make law out of the OSI model, a very different enterprise than > traditional telecom regulation. > > > On 3/25/2011 10:27 PM, Joly MacFie wrote: > >> aka the "separation principle" ( Tim Wu - the Master Switch) >> >> What surprised me is that when I put his point to Richard R.John at the >> Columbia Big media event back in Nov >> - John totally agreed with it, citing >> the >> precedent of the telegraph companies being locked out of the telephone >> business back in the day. >> >> j >> >> >> On Fri, Mar 25, 2011 at 10:52 PM, George Bonser >> wrote: >> >> It is only in very recent times that we have been able to overlay >>>> Internet on both cable and television, and to have television >>>> competition via satellite. >>>> >>> In "the old days" the phone company didn't provide "content". You >>> called someone and the people at each end provided the content or the >>> data going over the network. The phone company simply provided the >>> network. I still believe the biggest mistake we made was breaking up >>> the Bell System. We should have let them be, regulated the crap out of >>> them, and then said "no, you can't get into the business of providing >>> content". They system should have been left as a regulated public >>> utility. >>> >>> To that end, I think the US would be much better off with fiber to the >>>> home on a single distribution infrastructure. That could be owned and >>>> operated by the municipality (like the water system) or owned and >>>> operated by a corporation granted an exclusive right to service an >>>> >>> area >>> >>>> (think telephone, at least pre CLEC). >>>> >>> Yup, bring back "The Bell System". >>> >>> >>> Where you immediately run into a snag is the next layer up. Should >>>> >>> the >>> >>>> government provide IP services, if the fiber is government owned? >>>> Should private companies be required to offer competitors access to >>>> provide IP services if the fiber is privately owned? >>>> >>> I would say they provide network access only, not content. They would >>> be kept out of providing content and kept in the business of reliably >>> connecting content to consumer. That would be their focus. >>> >>> Having looked around the world I personally believe most communities >>>> would be best served if the government provided layer-1 distribution, >>>> possibly with some layer 2 switching, but then allowed any commercial >>>> entity to come in and offer layer 3 services. >>>> >>> I don't. What happens when the "government" then decides what content >>> is and is not allowed to go over their network? If one had a site that >>> provided a view that the government didn't like, would they cut it off? >>> I want the government very strictly limited in what they can and cannot >>> do and I want them to have to go to an outside entity for things like >>> lawful intercept because it is another check on their power. A private >>> entity might insist that there is a proper warrant or subpoena while the >>> government might simply decide to snoop first, get the paperwork later. >>> Keeping the network at arm's length from the government helps to make >>> sure there is another entity in the loop. >>> >>> For simplicity of >>>> argument I like people to envision the local government fiber agency >>>> (like your water authority) dropping off a 1 port fiber 4 port copper >>>> switch in your basement. >>>> >>> Big difference. Water is not a good analogy. The "content" in that >>> case is from a central source and everyone gets the same thing. With >>> the network, you have people communicating back and forth and much of >>> that communications is private or expected to be private (say, a phone >>> call or a secure financial transaction). If a private entity screws up, >>> it is much easier to fine them or fire the person responsible than it is >>> to punish a government department or fire a government worker. Besides, >>> we really don't need yet more people on the government payroll. >>> >>> Though I do agree that it is a natural monopoly. It should be managed >>> by a regulated utility that is explicitly prohibited from providing the >>> content, only provide access through the network. >>> >>> >>> >>> >>> >> > -- > Richard Bennett > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From scott at doc.net.au Sat Mar 26 02:38:05 2011 From: scott at doc.net.au (Scott Howard) Date: Sat, 26 Mar 2011 00:38:05 -0700 Subject: [v6z] The growth of municipal broadband networks In-Reply-To: <4D8CDF79.9060404@paulgraydon.co.uk> References: <4D8CDF79.9060404@paulgraydon.co.uk> Message-ID: On Fri, Mar 25, 2011 at 11:31 AM, Paul Graydon wrote: > > http://arstechnica.com/tech-policy/news/2011/03/133-us-cities-now-run-their-own-broadband-networks.ars > > Ars Technica has a short article up about the growth of municipal networks, > but principally a nice little 'hey check out this website' ( > http://www.muninetworks.org/communitymap) > > The whole scenario around municipal broadband networks in a hopefully > unbiased nutshell: Increasing numbers cities and counties seem to be > getting frustrated with what they see as the lack of progress in broadband > speeds from their incumbent provider(s) (even after incumbent provider(s) > have been approached requesting faster speeds) and are deciding to do it > themselves. Whilst that's certainly true for some areas, it's definitely not the case for all of the areas marked on that map. The only entry for the SF Bay area is San Bruno, where the municipal-owned cable provider *is* the incumbent, and has been for the past 30 years. Not only are they the incumbent, but they are also a monopoly who have blocked competition, resulting in higher prices than in much of the rest of the bay area. Scott (Happily no longer living in San Bruno) From jra at baylink.com Sat Mar 26 08:28:26 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 26 Mar 2011 09:28:26 -0400 (EDT) Subject: The growth of municipal broadband networks In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> Message-ID: <5205226.486.1301146106523.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "George Bonser" > I would say they provide network access only, not content. They would > be kept out of providing content and kept in the business of reliably > connecting content to consumer. That would be their focus. We aren't even suggesting that, George. We're suggesting that they *provide access to people who provide network access*; we (most of us, anyway) don't even think the muni's should provide IP routing. They should provide *connectivity* to people who do that. And given how STBs work these days, those wholesale customers could even be cablecos, in addition to telcos, or IAPs. Cheers, -- jra From jra at baylink.com Sat Mar 26 08:31:06 2011 From: jra at baylink.com (Jay Ashworth) Date: Sat, 26 Mar 2011 09:31:06 -0400 (EDT) Subject: Which internal WAN protocol? In-Reply-To: Message-ID: <13940420.490.1301146266022.JavaMail.root@benjamin.baylink.com> ---- Original Message ----- > From: "Mikael Abrahamsson" > If you google for "isp essentials" the first hit is a pdf from 2003. > It has a lot of best common practice for ISPs and I'd say all of it is > still valid. Just a reminder to all: this is no longer a valid citation methodology. Given the amount to which Google customizes results these days (as Lauren Weinstein pointed out the other day), you can't assume that anyone will see the same google results as you, anymore -- at least not if one of you has a google account (I never have, but between work using Wave, and my buying a Thunderbolt this week, I'm now held at gunpoint...) Cheers, -- jra From brunner at nic-naa.net Sat Mar 26 09:26:58 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 26 Mar 2011 10:26:58 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <004a01cbe7ec$338874b0$9a995e10$@net> References: <004a01cbe7ec$338874b0$9a995e10$@net> Message-ID: <4D8DF7B2.2080906@nic-naa.net> On 3/21/11 1:19 PM, Stefan Fouant wrote: > So the days of pointless TLDs are amongst us as we've now given would-be > registrars the right to print money and companies are forced to purchase > useless domain names in order to protect their trademarks, prevent > squatting, etc. When will sanity prevail? First, not all registrars assume the credit-card risk model, or pursue the defensive registration, or ad word markets. Second, the advocates for no necessity or utility requirement, or some form of public interest test for would-be applicants, is far, far larger than the 20 to 40 registrars engaged in that advocacy agenda. An analysis that does not start with the legacy monopoly registry operator, and continue to the operators of "open" (now "standard") registries, is simply ill-informed or advocacy art, missing the Registry Stakeholders Group as a mostly unified[1] policy advocate. An analysis that does not continue from these materially interested contracted parties and include domainers, and the ideologically committed parties, whether motivated by "free trade", or "thousand flowers", is also simply ill-informed or advocacy art, missing the Non Commercial Stakeholders Group as a policy advocate. Third, an analysis that fails to observe that the Internet Service Providers Stakeholder Group has no policy agenda at ICANN is curious when offered in a network operator group. It might be reasonable when commenting on a recent development in the Law of the Sea (but see also bouys have bits), but slightly absurd when commenting on a recent development in the corporation acting as a registry of unique network identifiers, autonomous system numbers, and protocol parameters. Finally, because pancakes are calling, the very complainants of squatting and defensive registration (the 1Q million-in-revenue every applicant for an "open", now "standard" registry places in its bizplan), the Intellectual Property Stakeholder Group is also an advocate for trademark TLDs, arguing that possession of $fee and a registry platform contract (there is now a niche industry of boutique ".brand" operators-in-waiting) and a $bond establishes an absolute right to a label in the IANA root. So, rather than memorizing the digits of Pi, for some later public recitation, one could start reciting brand names, for some later public recitation, for as long as there is a single unified root. Have I managed to suggest that claims to sanity that are not exceeded by actual work are without foundation? Eric P.S. to Joel Jaeggli. You need to work harder. 20 bytes is less than sufficient to make any point usefully, and you missed .name/.pro, as well as the 2004 round .jobs/.travel as well as .asia/.tel, not as yet depurposed. [1] Exception to the RySG "no public interest" advocacy are the few sponsored registries which were not covert open registries, and are not dependent upon open registry operators for registry services, viz. .cat, .coop, and .museum. From smb at cs.columbia.edu Sat Mar 26 12:48:27 2011 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 26 Mar 2011 13:48:27 -0400 Subject: The state-level attack on the SSL CA security model In-Reply-To: References: Message-ID: <91297661-425D-4724-81BF-697294E3F1D3@cs.columbia.edu> On Mar 26, 2011, at 12:21 12AM, Franck Martin wrote: > > > On 3/26/11 15:36 , "Joe Sniderman" wrote: > >> On 03/25/2011 11:12 PM, Steven Bellovin wrote: >>> >>> On Mar 25, 2011, at 12:19 52PM, Akyol, Bora A wrote: >>> >>>> One could argue that you could try something like the facebook >>>> model (or facebook itself). I can see it coming. Facebook web of >>>> trust app ;-) >>>> >>> Except, of course, for the fact that people tend to have hundreds of >>> "friends", many of whom they don't know at all, and who achieved that >>> status simply by asking. You need a much stronger notion of >>> interaction, to say nothing of what the malware in your "friends'" >>> computers are doing to simulate such interaction. >> >> Then again there are all the "friend us for a chance to win $prize" >> gimmicks... not a far jump to "friend us, _with trust bits enabled_ for >> a chance to win $prize" >> >> Yeah sounds like a wonderful idea. :P > > Wasn't PGP based on a web of trust too? > Yes -- see Valdis' posting on that: http://mailman.nanog.org/pipermail/nanog/2011-March/034651.html --Steve Bellovin, http://www.cs.columbia.edu/~smb From ariel at post.tau.ac.il Sat Mar 26 14:33:55 2011 From: ariel at post.tau.ac.il (Ariel Biener) Date: Sat, 26 Mar 2011 21:33:55 +0200 Subject: The state-level attack on the SSL CA security model In-Reply-To: <23088.1301071504@localhost> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <21155.1301069099@localhost> <23088.1301071504@localhost> Message-ID: <4D8E3FA3.8070408@post.tau.ac.il> On 25/03/2011 6:45 PM, Valdis.Kletnieks at vt.edu wrote: > On Fri, 25 Mar 2011 09:19:52 PDT, "Akyol, Bora A" said: >> One could argue that you could try something like the facebook model (or >> facebook itself). I can see it coming. >> Facebook web of trust app ;-) > Gee thanks. I'm going to have nightmares for *weeks* now... :) Based on the Facebook model: 1. Friends - people among whom are some I most probably never knew before, or some I would not even say hello to. 2. Trusted friends - people I actually say hello to I think you'll need "Highly trusted friends" as a 3rd level :) And that will hold for about 1 month, until people will start banging on your "inner circle" virtual door, and soon enough your list of trusted and highly trusted friends will start filling up. What does "trusted" mean in this particular case ? There is no one list of criteria for being "trust worthy", and some people are more trusting that others. How would trustworthyness be measured anyhow ? How many people signed your thing, who are also trustworthy themselves (which means that their SIG was also signed by trustworthy people, see the vicious circle). And would people from a certain part of the globe or certain countries be more trust worthy based on their country trustworthyness, or maybe on their culture being more open and trusting ? If this is to become some kind of global meaningful thing, it needs to be standardized, so it will have the same meaning regardless of where this is applied, and it will have straightforward means of "measuring" trust. Is there such a standard in place ? Just for an example, we have in Israel a CA that is recognized by the government - they are allowed to issue certificates used for signing documents - and signing with certs issued by this CA is admissible in court under the electronic signatures law. The government has put up a certain standard for what a CA needs to do in order to be recognized as trustworthy. Only one CA in Israel attained this status. Does that mean they are trustworthy to you ? I don't think so. So it can't be a local thing, it needs to be a global thing, and the standard needs to be global and accepted as well. --Ariel From richard at bennett.com Sat Mar 26 15:28:35 2011 From: richard at bennett.com (Richard Bennett) Date: Sat, 26 Mar 2011 13:28:35 -0700 Subject: The growth of municipal broadband networks In-Reply-To: References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> <4D8D811D.9070604@bennett.com> Message-ID: <4D8E4C73.7050003@bennett.com> I think the motive for the traditional separation actually was completely different from the one for new separation. Silos had the effect of limiting competition for specific services, while the avowed goal of functional separation mandates is to increase competition. Opportunities for service competition between the telegraph and telephone networks were limited by technology in the first instance - you couldn't carry phone calls over the telegraph network anyway because it was a low bandwidth, steel wire system with telegraph office - to telegraph office topology - but you could carry telegrams over the phone network, but only if permitted by law. In a sense, ARPANET was telegraph network 2.0, and even used the same terminals initially. Paper tape-to-tape transfers became ftp, the telegram became email, and kids running paper messages around the office became routers switching packets. The layer 0 model has some merit, but has issues. In areas nobody wants to provide ISP services, and there is still a tendency toward market consolidation due to economies of scale in the service space. Facilities-based competition remains the most viable model in most places, as we're seeing in the UK where market structure resembles the US more than most want to admit: Their two biggest ISPs are BT and Virgin, the owners of the wire, and they have less fiber than we have in the US. Creating the conditions for network competition is a hard problem with no easy answers. RB On 3/25/2011 11:48 PM, Joly MacFie wrote: I take your point, the separation was of a different order. But a separation, nonetheless. The motive is not so much different. I think we can all accept that "traditional telephone regulation" is rapidly losing its grip as the beast morphs. Now that applications outnumber networks new problems require new solutions. I've heard Allied Fiber's Hunter Newby argue convincingly that really it's about separating Level 0 - the real estate, the wires and the head end premises - from everything else, and facilitating sufficient open access to guarantee healthy competition in services. And yes, where there's a monopoly there will have to some price regulation. At least that's traditional. As we've seen in the UK, while it's not so much a stretch to impose even higher level unbundling on the telcos, when it comes to the cable industry it's going to be a very painful pulling of teeth. [1]http://www.telecomtv.com/comspace_newsDetail.aspx?n=46077&id=e938181 7-0593-417a-8639-c4c53e2a2a10 j On Sat, Mar 26, 2011 at 2:01 AM, Richard Bennett <[2]richard at bennett.com> wrote: The principle that kept telegraph and telephone apart wasn't a functional layering concept, it was a "technology silos" concept under which all communication networks were assumed to be indistinguishable from their one and only one application. If you read the Communications Act of 1934, you'll see this idea embodied in the titles of the act, each of which describes both a network and an application, as we understand the terms today. Wu wants to make law out of the OSI model, a very different enterprise than traditional telecom regulation. On 3/25/2011 10:27 PM, Joly MacFie wrote: aka the "separation principle" ( Tim Wu - the Master Switch) What surprised me is that when I put his point to Richard R.John at the Columbia Big media event back in Nov <[3]http://isoc-ny.org/p2/?p=1563> - John totally agreed with it, citing the precedent of the telegraph companies being locked out of the telephone business back in the day. j On Fri, Mar 25, 2011 at 10:52 PM, George Bonser<[4]gbonser at seven.com> wrote: It is only in very recent times that we have been able to overlay Internet on both cable and television, and to have television competition via satellite. In "the old days" the phone company didn't provide "content". You called someone and the people at each end provided the content or the data going over the network. The phone company simply provided the network. I still believe the biggest mistake we made was breaking up the Bell System. We should have let them be, regulated the crap out of them, and then said "no, you can't get into the business of providing content". They system should have been left as a regulated public utility. To that end, I think the US would be much better off with fiber to the home on a single distribution infrastructure. That could be owned and operated by the municipality (like the water system) or owned and operated by a corporation granted an exclusive right to service an area (think telephone, at least pre CLEC). Yup, bring back "The Bell System". Where you immediately run into a snag is the next layer up. Should the government provide IP services, if the fiber is government owned? Should private companies be required to offer competitors access to provide IP services if the fiber is privately owned? I would say they provide network access only, not content. They would be kept out of providing content and kept in the business of reliably connecting content to consumer. That would be their focus. Having looked around the world I personally believe most communities would be best served if the government provided layer-1 distribution, possibly with some layer 2 switching, but then allowed any commercial entity to come in and offer layer 3 services. I don't. What happens when the "government" then decides what content is and is not allowed to go over their network? If one had a site that provided a view that the government didn't like, would they cut it off? I want the government very strictly limited in what they can and cannot do and I want them to have to go to an outside entity for things like lawful intercept because it is another check on their power. A private entity might insist that there is a proper warrant or subpoena while the government might simply decide to snoop first, get the paperwork later. Keeping the network at arm's length from the government helps to make sure there is another entity in the loop. For simplicity of argument I like people to envision the local government fiber agency (like your water authority) dropping off a 1 port fiber 4 port copper switch in your basement. Big difference. Water is not a good analogy. The "content" in that case is from a central source and everyone gets the same thing. With the network, you have people communicating back and forth and much of that communications is private or expected to be private (say, a phone call or a secure financial transaction). If a private entity screws up, it is much easier to fine them or fire the person responsible than it is to punish a government department or fire a government worker. Besides, we really don't need yet more people on the government payroll. Though I do agree that it is a natural monopoly. It should be managed by a regulated utility that is explicitly prohibited from providing the content, only provide access through the network. -- Richard Bennett -- --------------------------------------------------------------- Joly MacFie 218 565 9365 [5]Skype:punkcast WWWhatsup NYC - [6]http://wwwhatsup.com [7]http://pinstand.com - [8]http://punkcast.com VP (Admin) - ISOC-NY - [9]http://isoc-ny.org -------------------------------------------------------------- - -- Richard Bennett References 1. http://www.telecomtv.com/comspace_newsDetail.aspx?n=46077&id=e9381817-0593-417a-8639-c4c53e2a2a10 2. mailto:richard at bennett.com 3. http://isoc-ny.org/p2/?p=1563 4. mailto:gbonser at seven.com 5. Skype:punkcast 6. http://wwwhatsup.com/ 7. http://pinstand.com/ 8. http://punkcast.com/ 9. http://isoc-ny.org/ From bill at herrin.us Sat Mar 26 15:55:32 2011 From: bill at herrin.us (William Herrin) Date: Sat, 26 Mar 2011 16:55:32 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <004a01cbe7ec$338874b0$9a995e10$@net> References: <004a01cbe7ec$338874b0$9a995e10$@net> Message-ID: On Mon, Mar 21, 2011 at 1:19 PM, Stefan Fouant wrote: > So the days of pointless TLDs are amongst us as we've now given would-be > registrars the right to print money and companies are forced to purchase > useless domain names in order to protect their trademarks, prevent > squatting, etc. ?When will sanity prevail? If the creation of .xxx is a preliminary step in making the fact of your web site only being accessible by a name ending in .xxx an affirmative defense against a charge of allowing minors to access your site then a) it's not pointless, and b) sanity is prevailing. IF. But then, it has to start somewhere. Regards, Bill Herrin -- 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 Sat Mar 26 16:07:11 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 26 Mar 2011 17:07:11 -0400 Subject: The growth of municipal broadband networks In-Reply-To: <4D8E4C73.7050003@bennett.com> References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> <4D8D811D.9070604@bennett.com> <4D8E4C73.7050003@bennett.com> Message-ID: Again excellent points. And I agree, in the current UK model there appears very little opportunity for independent ISPs to offer any significantly improved service over the incumbent's own, and thereby grab market share. It's all a matter of what else one can package with it - effectively the separation principle anyway. > Creating the conditions for network competition is a hard problem with no easy answers. Where there's a will there's a way. The big question, to some extent is, is there the will? One doesn't miss one's water etc. I was cheered to see in the recent Canadian usage pricing fracas, Marc Garneau handing out buttons saying "My Internet Shouldn't Suck"[1], and also to see Susan Crawford urging students to take to the streets over the issue [2] before it's too late. But it's going to take the equivalent of 10 Tahrir Squares to overcome the incumbent clout and establishment inertia. Meanwhile we are seeing widening pre-emptive strikes like N. Carolina. the incumbents ride roughshod over everyone stating words to the effect - if we can't gouge we won't build.. There surely still have to be answers, however tough - and some kind of separation would seem to be an inescapable component. I am no techie, but alternatively I imagine what could be practically discussed is how much new technologies like cheap plastic fiber driving little wi-fi chips, mesh etc, could give those communities that haven't already been legislated out of the game an opportunity to economically and successfully build their own connectivity. [3] j [1] http://www.theglobeandmail.com/globe-investor/crtc-wont-include-retail-services-in-internet-price-hearing/article1938694/ [2] http://isoc-ny.org/p2/?p=1930 [3] I am in the process of organizing a panel to discuss same at the INET NY on Jun 14, expressions of interest welcome offlist . On Sat, Mar 26, 2011 at 4:28 PM, Richard Bennett wrote: > I think the motive for the traditional separation actually was completely > different from the one for new separation. Silos had the effect of limiting > competition for specific services, while the avowed goal of functional > separation mandates is to increase competition. > > Opportunities for service competition between the telegraph and telephone > networks were limited by technology in the first instance - you couldn't > carry phone calls over the telegraph network anyway because it was a low > bandwidth, steel wire system with telegraph office - to telegraph office > topology - but you could carry telegrams over the phone network, but only if > permitted by law. > > In a sense, ARPANET was telegraph network 2.0, and even used the same > terminals initially. Paper tape-to-tape transfers became ftp, the telegram > became email, and kids running paper messages around the office became > routers switching packets. > > The layer 0 model has some merit, but has issues. In areas nobody wants to > provide ISP services, and there is still a tendency toward market > consolidation due to economies of scale in the service space. > Facilities-based competition remains the most viable model in most places, > as we're seeing in the UK where market structure resembles the US more than > most want to admit: Their two biggest ISPs are BT and Virgin, the owners of > the wire, and they have less fiber than we have in the US. > > Creating the conditions for network competition is a hard problem with no > easy answers. > > RB > > On 3/25/2011 11:48 PM, Joly MacFie wrote: > > I take your point, the separation was of a different order. But a > separation, nonetheless. The motive is not so much different. > > I think we can all accept that "traditional telephone regulation" is > rapidly losing its grip as the beast morphs. Now that applications outnumber > networks new problems require new solutions. > > I've heard Allied Fiber's Hunter Newby argue convincingly that really > it's about separating Level 0 - the real estate, the wires and the head end > premises - from everything else, and facilitating sufficient open access to > guarantee healthy competition in services. > > And yes, where there's a monopoly there will have to some price > regulation. At least that's traditional. > > As we've seen in the UK, while it's not so much a stretch to impose even > higher level unbundling on the telcos, when it comes to the cable industry > it's going to be a very painful pulling of teeth. > > http://www.telecomtv.com/comspace_newsDetail.aspx?n=46077&id=e9381817-0593-417a-8639-c4c53e2a2a10 > > j > > > > On Sat, Mar 26, 2011 at 2:01 AM, Richard Bennett wrote: > >> The principle that kept telegraph and telephone apart wasn't a functional >> layering concept, it was a "technology silos" concept under which all >> communication networks were assumed to be indistinguishable from their one >> and only one application. If you read the Communications Act of 1934, you'll >> see this idea embodied in the titles of the act, each of which describes >> both a network and an application, as we understand the terms today. Wu >> wants to make law out of the OSI model, a very different enterprise than >> traditional telecom regulation. >> >> >> On 3/25/2011 10:27 PM, Joly MacFie wrote: >> >>> aka the "separation principle" ( Tim Wu - the Master Switch) >>> >>> What surprised me is that when I put his point to Richard R.John at the >>> Columbia Big media event back in Nov >>> - John totally agreed with it, citing >>> the >>> precedent of the telegraph companies being locked out of the telephone >>> business back in the day. >>> >>> j >>> >>> >>> On Fri, Mar 25, 2011 at 10:52 PM, George Bonser >>> wrote: >>> >>> It is only in very recent times that we have been able to overlay >>>>> Internet on both cable and television, and to have television >>>>> competition via satellite. >>>>> >>>> In "the old days" the phone company didn't provide "content". You >>>> called someone and the people at each end provided the content or the >>>> data going over the network. The phone company simply provided the >>>> network. I still believe the biggest mistake we made was breaking up >>>> the Bell System. We should have let them be, regulated the crap out of >>>> them, and then said "no, you can't get into the business of providing >>>> content". They system should have been left as a regulated public >>>> utility. >>>> >>>> To that end, I think the US would be much better off with fiber to the >>>>> home on a single distribution infrastructure. That could be owned and >>>>> operated by the municipality (like the water system) or owned and >>>>> operated by a corporation granted an exclusive right to service an >>>>> >>>> area >>>> >>>>> (think telephone, at least pre CLEC). >>>>> >>>> Yup, bring back "The Bell System". >>>> >>>> >>>> Where you immediately run into a snag is the next layer up. Should >>>>> >>>> the >>>> >>>>> government provide IP services, if the fiber is government owned? >>>>> Should private companies be required to offer competitors access to >>>>> provide IP services if the fiber is privately owned? >>>>> >>>> I would say they provide network access only, not content. They would >>>> be kept out of providing content and kept in the business of reliably >>>> connecting content to consumer. That would be their focus. >>>> >>>> Having looked around the world I personally believe most communities >>>>> would be best served if the government provided layer-1 distribution, >>>>> possibly with some layer 2 switching, but then allowed any commercial >>>>> entity to come in and offer layer 3 services. >>>>> >>>> I don't. What happens when the "government" then decides what content >>>> is and is not allowed to go over their network? If one had a site that >>>> provided a view that the government didn't like, would they cut it off? >>>> I want the government very strictly limited in what they can and cannot >>>> do and I want them to have to go to an outside entity for things like >>>> lawful intercept because it is another check on their power. A private >>>> entity might insist that there is a proper warrant or subpoena while the >>>> government might simply decide to snoop first, get the paperwork later. >>>> Keeping the network at arm's length from the government helps to make >>>> sure there is another entity in the loop. >>>> >>>> For simplicity of >>>>> argument I like people to envision the local government fiber agency >>>>> (like your water authority) dropping off a 1 port fiber 4 port copper >>>>> switch in your basement. >>>>> >>>> Big difference. Water is not a good analogy. The "content" in that >>>> case is from a central source and everyone gets the same thing. With >>>> the network, you have people communicating back and forth and much of >>>> that communications is private or expected to be private (say, a phone >>>> call or a secure financial transaction). If a private entity screws up, >>>> it is much easier to fine them or fire the person responsible than it is >>>> to punish a government department or fire a government worker. Besides, >>>> we really don't need yet more people on the government payroll. >>>> >>>> Though I do agree that it is a natural monopoly. It should be managed >>>> by a regulated utility that is explicitly prohibited from providing the >>>> content, only provide access through the network. >>>> >>>> >>>> >>>> >>>> >>> >> -- >> Richard Bennett >> >> > > > -- > --------------------------------------------------------------- > Joly MacFie 218 565 9365 Skype:punkcast > WWWhatsup NYC - http://wwwhatsup.com > http://pinstand.com - http://punkcast.com > VP (Admin) - ISOC-NY - http://isoc-ny.org > -------------------------------------------------------------- > - > > > -- > Richard Bennett > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From joly at punkcast.com Sat Mar 26 16:10:41 2011 From: joly at punkcast.com (Joly MacFie) Date: Sat, 26 Mar 2011 17:10:41 -0400 Subject: The growth of municipal broadband networks In-Reply-To: References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0C9E2A64@RWC-EX1.corp.seven.com> <4D8D811D.9070604@bennett.com> <4D8E4C73.7050003@bennett.com> Message-ID: It's all a matter of what else one can package with it - effectively the > separation principle anyway. > > effectively negating the separation principle anyway. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- - From johnl at iecc.com Sat Mar 26 16:13:28 2011 From: johnl at iecc.com (John Levine) Date: 26 Mar 2011 21:13:28 -0000 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: Message-ID: <20110326211328.54951.qmail@joyce.lan> >If the creation of .xxx is a preliminary step in making the fact of >your web site only being accessible by a name ending in .xxx an >affirmative defense against a charge of allowing minors to access your >site then A charge of what? ICM and .XXX are headquartered in Florida. Could you give some examples of the laws you're referring to, and cases where people have been convicted under them? R's, John From scott at doc.net.au Sat Mar 26 16:17:52 2011 From: scott at doc.net.au (Scott Howard) Date: Sat, 26 Mar 2011 14:17:52 -0700 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: References: <004a01cbe7ec$338874b0$9a995e10$@net> Message-ID: On Sat, Mar 26, 2011 at 1:55 PM, William Herrin wrote: > If the creation of .xxx is a preliminary step in making the fact of > your web site only being accessible by a name ending in .xxx an > affirmative defense against a charge of allowing minors to access your > site then > But do you really believe playboy are going to give up playboy.com? Or that new websites are going to register an address that will result in their website not being visible by 1/6th of the worlds population ( http://uk.ibtimes.com/articles/127009/20110325/india-blocks-xxx-domain.htm - and we all know China and several other countries won't be far behind so we're probably talking closer to half or more of the worlds population). At first glance this might sounds like a good idea, but do you know any *.travel or *.asia (etc) websites that don't also have the equivalent or similar .com version? Nobody uses these domains as their only domain, it's just yet another one that they will register - and yet more money they need to pay to the registries each year to protect their brand. Scott. From bill at herrin.us Sat Mar 26 16:26:24 2011 From: bill at herrin.us (William Herrin) Date: Sat, 26 Mar 2011 17:26:24 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <20110326211328.54951.qmail@joyce.lan> References: <20110326211328.54951.qmail@joyce.lan> Message-ID: On Sat, Mar 26, 2011 at 5:13 PM, John Levine wrote: >>If the creation of .xxx is a preliminary step in making the fact of >>your web site only being accessible by a name ending in .xxx an >>affirmative defense against a charge of allowing minors to access your >>site then > > A charge of what? ?ICM and .XXX are headquartered in Florida. ?Could > you give some examples of the laws you're referring to US Code TITLE 18 > PART I > CHAPTER 71 > ? 1470 http://www.law.cornell.edu/uscode/18/usc_sec_18_00001470----000-.html >, and cases > where people have been convicted under them? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From gbonser at seven.com Sat Mar 26 16:28:47 2011 From: gbonser at seven.com (George Bonser) Date: Sat, 26 Mar 2011 14:28:47 -0700 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: References: <004a01cbe7ec$338874b0$9a995e10$@net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> > But do you really believe playboy are going to give up playboy.com? They aren't going to give up Playboy.com but they are probably going to have to purchase playboy.xxx anyway. What bothers me is that most companies are now going to be forced to purchase .xxx domains simply to keep someone else from buying it and sullying the company's image. So it is an instant cash windfall for the domain registrars. There was no reason why we needed this. From johnl at iecc.com Sat Mar 26 16:43:11 2011 From: johnl at iecc.com (John R. Levine) Date: 26 Mar 2011 17:43:11 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: References: <20110326211328.54951.qmail@joyce.lan> Message-ID: > US Code TITLE 18 > PART I > CHAPTER 71 > ? 1470 > http://www.law.cornell.edu/uscode/18/usc_sec_18_00001470----000-.html That law includes the phrase "knowing that such other individual has not attained the age of 16 years." That's why porn sites have a home page that asks you how old you are. As far as I can tell from looking for case law, all the 1470 cases are basically child molestation cases where the 1470 count was piled on in addition to the real charges, unrelated to kids looking for porn sites. So, in short, there's no problem for .XXX to solve. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From brandon at rd.bbc.co.uk Sat Mar 26 16:47:57 2011 From: brandon at rd.bbc.co.uk (Brandon Butterworth) Date: Sat, 26 Mar 2011 21:47:57 GMT Subject: ICANN approves .XXX red-light district for the Internet Message-ID: <201103262147.VAA08732@sunf10.rd.bbc.co.uk> > What bothers me is that most companies are now going to be forced to > purchase .xxx domains simply to keep someone else from buying it That's the norm for new tld and a part of the their owners business plan. Probably most of their income given how little I see them used directly. > and sullying the company's image. In this case which would sully our name more, registering bbc.xxx ourselves or a 3rd party who is clearly not us once people see the content? brandon From brunner at nic-naa.net Sat Mar 26 17:14:56 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 26 Mar 2011 18:14:56 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: References: <004a01cbe7ec$338874b0$9a995e10$@net> Message-ID: <4D8E6560.4030905@nic-naa.net> On 3/26/11 5:17 PM, Scott Howard wrote: ... > But do you really believe playboy are going to give up playboy.com? Or that > new websites are going to register an address that will result in their > website not being visible by 1/6th of the worlds population ( > http://uk.ibtimes.com/articles/127009/20110325/india-blocks-xxx-domain.htm - > and we all know China and several other countries won't be far behind so > we're probably talking closer to half or more of the worlds population). Claim 1. That return on investment is proportional to population, overlooking the density of graphic displays, and bandwidth provisioning, which are probably not prudently overlooked from a bizplan perspective. Google metrics give 72.4 million pages in Estonian, 86.9 million pages in Hebrew and 88.1 million pages in Greek, and 108 million pages in Hindi in the .com name space, suggesting that the natural traffic for existing .com Hindi language (422 million native speakers) properties is similar to that of Hebrew (7.6 million speakers, second language speakers included), or Greek (11.3 million native speakers) or Estonian (1.3 million speakers). Overlooking differences in currency, disposable incomes, and cultural norms, which are probably not prudently overlooked from a bizplan perspective, a Hindi targeted .xxx enterprise is about as interesting as a Utah or Rhode Island targeted .xxx enterprise. To put it gently, there is more money in the metro east, Atlanta to Boston, than in India, or China, or India and China, even if the respective governments wanted revenue shares not firewalls. > At first glance this might sounds like a good idea, but do you know any > *.travel or *.asia (etc) websites that don't also have the equivalent or > similar .com version? Nobody uses these domains as their only domain, it's > just yet another one that they will register - and yet more money they need > to pay to the registries each year to protect their brand. Claim 2. That domains that have no pre-existing, or simultaneous existence in .com form a set of measure zero (or something handwavy close to that when I'm not pretending to be a mathematician). At present at least 50% of all .cat domains have no pre-existing, or simultaneous existence in .com or .es. This form of claim is highly relevant to competition policy, as it may be considered a form of "market power". In this form Verisign has "market power" relative to .travel/.asia, but has no "market power" relative to .cat. Therefore Verisign may exercise that market power over registrars selling Verisign's inventory, as well as Afilias' inventories, as well as .travel inventory. Eric From bill at herrin.us Sat Mar 26 17:21:19 2011 From: bill at herrin.us (William Herrin) Date: Sat, 26 Mar 2011 18:21:19 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: References: <20110326211328.54951.qmail@joyce.lan> Message-ID: On Sat, Mar 26, 2011 at 5:43 PM, John R. Levine wrote: >> US Code TITLE 18 > PART I > CHAPTER 71 > ? 1470 >> http://www.law.cornell.edu/uscode/18/usc_sec_18_00001470----000-.html > > That law includes the phrase "knowing that such other individual has not > attained the age of 16 years." ?That's why porn sites have a home page that > asks you how old you are. In court, willful negligence is generally the same thing as knowing. > As far as I can tell from looking for case law, > all the 1470 cases are basically child molestation cases where the 1470 > count was piled on in addition to the real charges, unrelated to kids > looking for porn sites. It gets messy because obscenity hinges on local community standards. But that's the rub -- as a porn purveyor you can't know what the community standards are in the user's community. Not many examples of web sites being taken to task for web content, not yet, but lots of examples of mail-order porn owners having a really bad year year, legally speaking. > So, in short, there's no problem for .XXX to solve. Suppose, just for the sake of the argument, that a statute or precedent came about to the effect that a community which permits access to .xxx sites (by not censoring the DNS) implicitly accepts "that kind of thing" isn't obscenity under local law. Further, suppose its found that the individual in such communities circumventing the technical safeguards in place to censor his access to .xxx is solely liable for such access, that the porn purveyor is -presumed- to have a reasonable belief that said individual's activity was lawful... merely because they access the site using the .xxx extension. Suppose, in other words, it comes to be that an internet porn purveyor is protected from local community standards for obscenity so he need only worry about staying away from stuff that's illegal in his own back yard. Where the prosecution has to support a claim that the site is accessible other than through the .xxx name in order to survive an early motion to dismiss. -Bill -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From johnl at iecc.com Sat Mar 26 17:31:24 2011 From: johnl at iecc.com (John Levine) Date: 26 Mar 2011 22:31:24 -0000 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: Message-ID: <20110326223124.74544.qmail@joyce.lan> >Suppose, just for the sake of the argument, that a statute or >precedent came about to the effect that a community which permits >access to .xxx sites (by not censoring the DNS) implicitly accepts >"that kind of thing" isn't obscenity under local law. If we're doing counterfactuals, let's suppose that everyone in the world thinks that .XXX is a great idea, and ICANN runs itself efficiently on a budget of $1M/yr. R's, John From tme at americafree.tv Sat Mar 26 18:17:19 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 26 Mar 2011 19:17:19 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <20110326223124.74544.qmail@joyce.lan> References: <20110326223124.74544.qmail@joyce.lan> Message-ID: <88CEC623-58B7-4BBF-A203-BDED22BF5CF9@americafree.tv> On Mar 26, 2011, at 6:31 PM, John Levine wrote: >> Suppose, just for the sake of the argument, that a statute or >> precedent came about to the effect that a community which permits >> access to .xxx sites (by not censoring the DNS) implicitly accepts >> "that kind of thing" isn't obscenity under local law. > > If we're doing counterfactuals, let's suppose that everyone in the > world thinks that .XXX is a great idea, and ICANN runs itself > efficiently on a budget of $1M/yr. > For some reason the aerodynamics of pigs comes to mind here. Having pigs fly is just about as likely as having ambitious Southern prosecutors give up the ability to bring meaningless, but newsworthy, porn prosecutions, ICANN's new TLD or no. Regards Marshall > R's, > John > > From brunner at nic-naa.net Sat Mar 26 18:23:33 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 26 Mar 2011 19:23:33 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <88CEC623-58B7-4BBF-A203-BDED22BF5CF9@americafree.tv> References: <20110326223124.74544.qmail@joyce.lan> <88CEC623-58B7-4BBF-A203-BDED22BF5CF9@americafree.tv> Message-ID: <4D8E7575.9040906@nic-naa.net> On 3/26/11 7:17 PM, Marshall Eubanks wrote: ... > For some reason the aerodynamics of pigs comes to mind here. Having pigs fly is > just about as likely as having ambitious Southern prosecutors > give up the ability to bring meaningless, but newsworthy, porn prosecutions, ICANN's new TLD or no. ICM retained competent counsel for the ICANN issue advocacy. I expect Stuart will retain competent counsel for the follow-on issues. Eric From tme at americafree.tv Sat Mar 26 20:41:25 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Sat, 26 Mar 2011 21:41:25 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> References: <004a01cbe7ec$338874b0$9a995e10$@net> <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> Message-ID: <823F94B4-D64E-4E56-9AFC-9E1D14F4DA46@americafree.tv> On Mar 26, 2011, at 5:28 PM, George Bonser wrote: >> But do you really believe playboy are going to give up playboy.com? > > They aren't going to give up Playboy.com but they are probably going to > have to purchase playboy.xxx anyway. > > What bothers me is that most companies are now going to be forced to > purchase .xxx domains simply to keep someone else from buying it and > sullying the company's image. So it is an instant cash windfall for the > domain registrars. > > There was no reason why we needed this. > But that is an excellent reason why someone would want it. I was involved in the IETF NEWDOM WG way back in ~1996 and heard all of these arguments then. IMHO this was snake oil 15 years ago, and it is even more snake oil now. Regards Marshall > > > From sfouant at shortestpathfirst.net Sat Mar 26 21:07:08 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sat, 26 Mar 2011 22:07:08 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <823F94B4-D64E-4E56-9AFC-9E1D14F4DA46@americafree.tv> References: <004a01cbe7ec$338874b0$9a995e10$@net> <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> <823F94B4-D64E-4E56-9AFC-9E1D14F4DA46@americafree.tv> Message-ID: <01cf01cbec23$ae1c93b0$0a55bb10$@net> > -----Original Message----- > From: Marshall Eubanks [mailto:tme at americafree.tv] > Sent: Saturday, March 26, 2011 9:41 PM > > But that is an excellent reason why someone would want it. > > I was involved in the IETF NEWDOM WG way back in ~1996 and heard all of > these arguments then. IMHO this was snake oil 15 years ago, and it is > even > more snake oil now. And I'm afraid we'll be seeing a whole heckuva lot more of this snake oil once ICANN finalizes the Generic TLD process in June: http://www.pcmag.com/article2/0,2817,2382233,00.asp Stefan Fouant From sfouant at shortestpathfirst.net Sat Mar 26 21:30:53 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sat, 26 Mar 2011 22:30:53 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <4D8E7575.9040906@nic-naa.net> References: <20110326223124.74544.qmail@joyce.lan> <88CEC623-58B7-4BBF-A203-BDED22BF5CF9@americafree.tv> <4D8E7575.9040906@nic-naa.net> Message-ID: <01d201cbec26$ffc082f0$ff4188d0$@net> > -----Original Message----- > From: Eric Brunner-Williams [mailto:brunner at nic-naa.net] > Sent: Saturday, March 26, 2011 7:24 PM > > ICM retained competent counsel for the ICANN issue advocacy. I expect > Stuart will retain competent counsel for the follow-on issues. Yes, it is certain that Stuart will retain competent counsel for all follow-on issues, I mean, the guy bragged to Bloomberg that ICM is set to make at least $200 million a year through these registrations (believe me, if I were in his position, I'd have the best lawyers money could buy). That doesn't even touch the $3-4 Billion in porn transactions ICM is hoping to process and get a cut of once they launch their payment processing service. What changed ICANN's mind between the ruling in 2007 and the ruling in 2010? ICM brings in an independent arbitrator and ICANN agrees to go along with the findings, yet for the life of me I can't find any majority who believe this was necessary. The ACLU objects because of censorship issues. Family and religious groups oppose because they believe .xxx legitimizes porn. Heck, even the porn industry itself opposes because it will increase operating costs and open the industry to more regulation. I can't seem to find anyone that would benefit from this, with the exception of Stuart and ICM's shareholders. Stefan Fouant From brunner at nic-naa.net Sat Mar 26 22:05:35 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sat, 26 Mar 2011 23:05:35 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <01d201cbec26$ffc082f0$ff4188d0$@net> References: <20110326223124.74544.qmail@joyce.lan> <88CEC623-58B7-4BBF-A203-BDED22BF5CF9@americafree.tv> <4D8E7575.9040906@nic-naa.net> <01d201cbec26$ffc082f0$ff4188d0$@net> Message-ID: <4D8EA97F.7000800@nic-naa.net> The determining question was did the application satisfy the 2004 criteria? The .cat application was the best application in the 2004 round, according to the evaluators, and the .xxx application was the next ranked application. So the point in the 2004 cycle where .xxx could have been prevented, assuming for the sake of argument that one held that as a goal, was in the admission criteria for the 2004 round. Had that criteria been extended by an additional requirement such as the sponsor's mission must have been to provide a name space for a linguistic or cultural purpose, the .xxx application, however technically competent, would have failed under the 2004 admissions criteria. Each time the issue has been before the Board, I've spoken to the issue -- the application met the stated criteria. There are no valid unstated criteria. A related problem was the subject of a recent blog post, http://crookedtimber.org/2011/03/19/the-hollowing-out-of-icann-must-be-stopped/ There are very few at ICANN now who were involved in the 2004 round, let alone the 2000 round, and so little in the way of corporate memory exists. Eric On 3/26/11 10:30 PM, Stefan Fouant wrote: >> -----Original Message----- >> From: Eric Brunner-Williams [mailto:brunner at nic-naa.net] >> Sent: Saturday, March 26, 2011 7:24 PM >> >> ICM retained competent counsel for the ICANN issue advocacy. I expect >> Stuart will retain competent counsel for the follow-on issues. > > Yes, it is certain that Stuart will retain competent counsel for all > follow-on issues, I mean, the guy bragged to Bloomberg that ICM is set to > make at least $200 million a year through these registrations (believe me, > if I were in his position, I'd have the best lawyers money could buy). That > doesn't even touch the $3-4 Billion in porn transactions ICM is hoping to > process and get a cut of once they launch their payment processing service. > > What changed ICANN's mind between the ruling in 2007 and the ruling in 2010? > ICM brings in an independent arbitrator and ICANN agrees to go along with > the findings, yet for the life of me I can't find any majority who believe > this was necessary. The ACLU objects because of censorship issues. Family > and religious groups oppose because they believe .xxx legitimizes porn. > Heck, even the porn industry itself opposes because it will increase > operating costs and open the industry to more regulation. > > I can't seem to find anyone that would benefit from this, with the exception > of Stuart and ICM's shareholders. > > Stefan Fouant > > > > From chris at getsprocket.com Sat Mar 26 23:55:07 2011 From: chris at getsprocket.com (Christopher Wolff) Date: Sat, 26 Mar 2011 21:55:07 -0700 Subject: Google security Message-ID: <4D8EC32B.50609@getsprocket.com> I have a client that acquired a domain name and affiliated company as a product of lengthy and extremely turbulent litigation. The client believes (and I have found evidence to suggest) that the previous owner is somehow interfering or interacting with the new owner's Google Analytics/Webmaster Tools/Places/Adwords accounts. Since I am representing the new owner, I am trying to find a forensics analyst or clueful contact at Google to act as an independent third party to 'certify' that in fact the previous owner is or is not interfering in the new owners Google Accounts. I've followed the standard protocol, i.e., post your question in the Google forums and wait for a response. To date the single response I've received is "change your password" which wasn't what I had in mind. If that contact or independent third-party forensics expert exists, I'd greatly appreciate any advice you can provide. Best regards, Christopher From mansaxel at besserwisser.org Sat Mar 26 23:55:43 2011 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Sun, 27 Mar 2011 06:55:43 +0200 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <01cf01cbec23$ae1c93b0$0a55bb10$@net> References: <004a01cbe7ec$338874b0$9a995e10$@net> <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> <823F94B4-D64E-4E56-9AFC-9E1D14F4DA46@americafree.tv> <01cf01cbec23$ae1c93b0$0a55bb10$@net> Message-ID: <20110327045543.GC14866@besserwisser.org> Subject: RE: ICANN approves .XXX red-light district for the Internet Date: Sat, Mar 26, 2011 at 10:07:08PM -0400 Quoting Stefan Fouant (sfouant at shortestpathfirst.net): > > From: Marshall Eubanks [mailto:tme at americafree.tv] > > even > > more snake oil now. > > And I'm afraid we'll be seeing a whole heckuva lot more of this snake oil > once ICANN finalizes the Generic TLD process in June: The only possible thing that could save anyone with a valuable meatspace (tm) from having to buy its string representation in all the new TLDen is to make TLDen ubiquitous to a degree where the TLD can't be assumed anymore. A root zone with several thousand TLDen is no technical problem. I wonder when the effect kicks in. If it does. A positive side-effect would be to enable the altroot kooks to buy a TLD (.altroot -- under which they can run their own mini-Internets) of their own, which would disable some, if not all of them. -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 An Italian is COMBING his hair in suburban DES MOINES! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From johnl at iecc.com Sat Mar 26 23:56:54 2011 From: johnl at iecc.com (John Levine) Date: 27 Mar 2011 04:56:54 -0000 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <01d201cbec26$ffc082f0$ff4188d0$@net> Message-ID: <20110327045654.82924.qmail@joyce.lan> >What changed ICANN's mind between the ruling in 2007 and the ruling in 2010? The growing certainty of an expensive and very embarassing lawsuit if they turned ICM down. Despite the clear lack of industry support for .XXX, ICM carefully jumped through every hoop, dotted every i, and crossed every t in the 2004 application process and the subsequent appeal and review processes. I expect the board and staff really really would not want to have to answer questions under oath like "who did you talk to at the US Department of Commerce about the .XXX application and what did you say?" and "why did you vote against .XXX when they followed the same rules as the TLDs you voted for?" R's, John From rdobbins at arbor.net Sun Mar 27 00:19:09 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sun, 27 Mar 2011 05:19:09 +0000 Subject: Google security In-Reply-To: <4D8EC32B.50609@getsprocket.com> References: <4D8EC32B.50609@getsprocket.com> Message-ID: <61ED5DA0-E664-4DC9-BAC0-979AD8DCD2CA@arbor.net> On Mar 27, 2011, at 11:55 AM, Christopher Wolff wrote: > To date the single response I've received is "change your password" which wasn't what I had in mind. The thing to do is to ensure that your client's machines/networks aren't compromised, and then to change the password(s) from a known good machine on a known good network. Other than that, my guess is that retaining an attorney and working through the legal system is the only additional measure to take (IANAL, of course). ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From sfouant at shortestpathfirst.net Sun Mar 27 00:39:05 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Sun, 27 Mar 2011 01:39:05 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <20110327045654.82924.qmail@joyce.lan> References: <01d201cbec26$ffc082f0$ff4188d0$@net> <20110327045654.82924.qmail@joyce.lan> Message-ID: <001401cbec41$4a3b49e0$deb1dda0$@net> > -----Original Message----- > From: John Levine [mailto:johnl at iecc.com] > Sent: Sunday, March 27, 2011 12:57 AM > > The growing certainty of an expensive and very embarassing lawsuit if > they turned ICM down. Despite the clear lack of industry support for > .XXX, ICM carefully jumped through every hoop, dotted every i, and > crossed every t in the 2004 application process and the subsequent > appeal and review processes. I expect the board and staff really > really would not want to have to answer questions under oath like "who > did you talk to at the US Department of Commerce about the .XXX > application and what did you say?" and "why did you vote against .XXX > when they followed the same rules as the TLDs you voted for?" Agreed. And ICM made damn well sure that they had the ways and the means to wage a considerable and sustained amount of legal pressure by selling over a quarter million pre-registrations at $75 each, generating over $20M in revenue... Stefan Fouant From owen at delong.com Sun Mar 27 00:53:16 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 26 Mar 2011 22:53:16 -0700 Subject: The growth of municipal broadband networks In-Reply-To: <19158564.404.1301103987428.JavaMail.root@benjamin.baylink.com> References: <19158564.404.1301103987428.JavaMail.root@benjamin.baylink.com> Message-ID: On Mar 25, 2011, at 6:46 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Leo Bicknell" > >> Having looked around the world I personally believe most communities >> would be best served if the government provided layer-1 distribution, >> possibly with some layer 2 switching, but then allowed any commercial >> entity to come in and offer layer 3 services. For simplicity of >> argument I like people to envision the local government fiber agency >> (like your water authority) dropping off a 1 port fiber 4 port >> copper switch in your basement. On that device they can create a >> layer 2 VLAN/VPN/Tunnel from any of the copper ports to any provider >> in the town CO. You could buy video from one, voice from one, and >> internet from another, on three different ports. You could buy >> everything from one provider. > > +5 > > Cheers, > -- jra +more Owen From owen at delong.com Sun Mar 27 01:05:25 2011 From: owen at delong.com (Owen DeLong) Date: Sat, 26 Mar 2011 23:05:25 -0700 Subject: The growth of municipal broadband networks In-Reply-To: <20110326020219.GF24101@skywalker.creative.net.au> References: <4D8CDF79.9060404@paulgraydon.co.uk> <20110325201104.GA38866@ussenterprise.ufp.org> <20110326020219.GF24101@skywalker.creative.net.au> Message-ID: <3BDFCDC0-2DD3-48CD-A3AA-711EBEE32D19@delong.com> On Mar 25, 2011, at 7:02 PM, Adrian Chadd wrote: > On Fri, Mar 25, 2011, Leo Bicknell wrote: > >> Having looked around the world I personally believe most communities >> would be best served if the government provided layer-1 distribution, >> possibly with some layer 2 switching, but then allowed any commercial >> entity to come in and offer layer 3 services. For simplicity of >> argument I like people to envision the local government fiber agency >> (like your water authority) dropping off a 1 port fiber 4 port >> copper switch in your basement. On that device they can create a >> layer 2 VLAN/VPN/Tunnel from any of the copper ports to any provider >> in the town CO. You could buy video from one, voice from one, and >> internet from another, on three different ports. You could buy >> everything from one provider. > > And the natural question is - how will this differ from the way the > "government" services like water, power and transportation have > been run, privatised-but-not-quite, etc? > > > > Adrian Water and Electricity are held to relatively strict standards and basically regardless of the source in the US, water is pretty much water and electricity is 110v/single phase or 220v/2 hots + neutral 60hz. (yes I'm aware of the variety of other 60Hz industrial power configurations, but, we're talking residential here). OTOH, the services offered by various L2 and L3 providers for internet connectivity vary widely in a number of significant ways. I personally would like to see LMIs (Last Mile Infrastructures) owned by the smallest applicable government entity (utility district, municipality, or county, for example) and administered either by said government entity or under contract to that entity on a cost- recovery basis where any service provider can connect to any customer and the per-customer cost of each type of connection (UTP, Co-Ax, or SMF) would be uniform to all providers making such connections. This would be a serious game-changer in the residential market because it would mean: 1. No more service provider monopolies anywhere. It would no longer be cost-prohibitive for any given provider to reach subscribers in remote areas and it would eliminate the need for monopoly/duopoly situations by having the LMI costs for a single LMI shared across all providers. 2. All providers get relatively equal footing for access to all customers. 3. The presence of real and meaningful competition would put the consumer much more in the driver's seat for the features and services that they want. As such, I'm sure that such a move would be vocally opposed by the current owners of the LMI who enjoy leveraging it to extort monopolistic pricing from substandard services. I believe Australia is starting to do something like this. So far, what I'm hearing is that consumers are loving it and Telstra is pouting. Owen From jra at baylink.com Sun Mar 27 01:36:15 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 27 Mar 2011 02:36:15 -0400 (EDT) Subject: The growth of municipal broadband networks In-Reply-To: <3BDFCDC0-2DD3-48CD-A3AA-711EBEE32D19@delong.com> Message-ID: <13648904.622.1301207775819.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Owen DeLong" > As such, I'm sure that such a move would be vocally opposed by > the current owners of the LMI who enjoy leveraging it to extort > monopolistic pricing from substandard services. As I noted, yes, that's Verizontal, and they have apparently succeeded in lobbying to have it made *illegal* in several states. I don't have citations to hand, but there are a couple sites that track muni fiber; I can find some. Cheers, -- jra From patrick at ianai.net Sun Mar 27 01:53:54 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Sun, 27 Mar 2011 02:53:54 -0400 Subject: Regional AS model In-Reply-To: <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> Message-ID: <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> On Mar 25, 2011, at 3:33 PM, Owen DeLong wrote: >> Single AS worldwide is fine with or without a backbone. >> > Only if you want to make use of ugly ugly BGP hacks on your routers, or, you don't care about Site A being > able to hear announcements from Site B. You are highly confused. Accepting default is not ugly, especially if you don't even have a backbone connecting your sites. And even if we could argue over default's aesthetic qualities (which, honestly, I don't see how we can), there is no rational person who would consider it a hack. You really should stop trying to correct the error you made in your first post. Remember the old adage about when you find yourself in a hole. Another thing to note is the people who actually run multiple discrete network nodes posting here all said it was fine to use a single AS. One even said the additional overhead of managing multiple ASes would be more trouble than it is worth, and I have to agree with that statement. Put another way, there is objective, empirical evidence that it works. In response, you have some nebulous "ugly" comment. I submit your argument is, at best, lacking sufficient definition to be considered useful. -- TTFN, patrick From owen at delong.com Sun Mar 27 02:14:25 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Mar 2011 00:14:25 -0700 Subject: The growth of municipal broadband networks In-Reply-To: <13648904.622.1301207775819.JavaMail.root@benjamin.baylink.com> References: <13648904.622.1301207775819.JavaMail.root@benjamin.baylink.com> Message-ID: <1FE6B158-60B9-4427-A80D-22AF96A2E627@delong.com> On Mar 26, 2011, at 11:36 PM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Owen DeLong" > >> As such, I'm sure that such a move would be vocally opposed by >> the current owners of the LMI who enjoy leveraging it to extort >> monopolistic pricing from substandard services. > > As I noted, yes, that's Verizontal, and they have apparently succeeded > in lobbying to have it made *illegal* in several states. I don't have > citations to hand, but there are a couple sites that track muni fiber; > I can find some. > > Cheers, > -- jra Laws can be changed if we can get enough momentum behind doing the right thing. Owen From tvhawaii at shaka.com Sun Mar 27 02:35:55 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sat, 26 Mar 2011 21:35:55 -1000 Subject: The growth of municipal broadband networks References: <13648904.622.1301207775819.JavaMail.root@benjamin.baylink.com> <1FE6B158-60B9-4427-A80D-22AF96A2E627@delong.com> Message-ID: <4DE0E80D542147239C7F416E289278FA@DELL16> Owen DeLong wrote: > On Mar 26, 2011, at 11:36 PM, Jay Ashworth wrote: > >> ----- Original Message ----- >>> From: "Owen DeLong" >> >>> As such, I'm sure that such a move would be vocally opposed by >>> the current owners of the LMI who enjoy leveraging it to extort >>> monopolistic pricing from substandard services. >> >> As I noted, yes, that's Verizontal, and they have apparently succeeded >> in lobbying to have it made *illegal* in several states. I don't have >> citations to hand, but there are a couple sites that track muni fiber; >> I can find some. >> >> Cheers, >> -- jra > > Laws can be changed if we can get enough momentum behind > doing the right thing. > > Owen http://en.wikipedia.org/wiki/Regulatory_capture From d3e3e3 at gmail.com Sun Mar 27 06:03:06 2011 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Sun, 27 Mar 2011 07:03:06 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: References: <20110326211328.54951.qmail@joyce.lan> Message-ID: See http://www.rfc-editor.org/rfc/rfc3675.txt. Thanks, Donald ============================= ?Donald E. Eastlake 3rd?? +1-508-333-2270 (cell) ?155 Beaver Street ?Milford, MA 01757 USA ?d3e3e3 at gmail.com On Sat, Mar 26, 2011 at 6:21 PM, William Herrin wrote: > On Sat, Mar 26, 2011 at 5:43 PM, John R. Levine wrote: >>> US Code TITLE 18 > PART I > CHAPTER 71 > ? 1470 >>> http://www.law.cornell.edu/uscode/18/usc_sec_18_00001470----000-.html >> >> That law includes the phrase "knowing that such other individual has not >> attained the age of 16 years." ?That's why porn sites have a home page that >> asks you how old you are. > > In court, willful negligence is generally the same thing as knowing. > > >> As far as I can tell from looking for case law, >> all the 1470 cases are basically child molestation cases where the 1470 >> count was piled on in addition to the real charges, unrelated to kids >> looking for porn sites. > > It gets messy because obscenity hinges on local community standards. > But that's the rub -- as a porn purveyor ?you can't know what the > community standards are in the user's community. Not many examples of > web sites being taken to task for web content, not yet, but lots of > examples of mail-order porn owners having a really bad year year, > legally speaking. > > >> So, in short, there's no problem for .XXX to solve. > > Suppose, just for the sake of the argument, that a statute or > precedent came about to the effect that a community which permits > access to .xxx sites (by not censoring the DNS) implicitly accepts > "that kind of thing" isn't obscenity under local law. Further, suppose > its found that the individual in such communities circumventing the > technical safeguards in place to censor his access to .xxx is solely > liable for such access, that the porn purveyor is -presumed- to have a > reasonable belief that said individual's activity was lawful... merely > because they access the site using the .xxx extension. > > Suppose, in other words, it comes to be that an internet porn purveyor > is protected from local community standards for obscenity so he need > only worry about staying away from stuff that's illegal in his own > back yard. Where the prosecution has to support a claim that the site > is accessible other than through the .xxx name in order to survive an > early motion to dismiss. > > -Bill > > > > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 > > From bill at herrin.us Sun Mar 27 06:43:28 2011 From: bill at herrin.us (William Herrin) Date: Sun, 27 Mar 2011 07:43:28 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: References: <20110326211328.54951.qmail@joyce.lan> Message-ID: On Mar 27, 2011 7:03 AM, "Donald Eastlake" wrote: > See http://www.rfc-editor.org/rfc/rfc3675.txt. Doesn't look to me like anyone is trying to mandate the use of .xxx. I would be opposed if they were. Mandate bad. Options good. -Bill From brunner at nic-naa.net Sun Mar 27 07:35:58 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 27 Mar 2011 08:35:58 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <20110327045654.82924.qmail@joyce.lan> References: <20110327045654.82924.qmail@joyce.lan> Message-ID: <4D8F2F2E.2020203@nic-naa.net> Two comments from two commenters: > I can't seem to find anyone that would benefit from this, with the exception > of Stuart and ICM's shareholders. > ... I expect the board and staff really > really would not want to have to answer questions under oath like "who > did you talk to at the US Department of Commerce about the .XXX > application and what did you say?" and "why did you vote against .XXX > when they followed the same rules as the TLDs you voted for?" The first assumes that a beneficiary should exist that is distinct from the applicant-sponsor. In the case of .aero, SITA itself ceased to exist in the form it existed at the time of application. At that time it was a non-profit cooperative "open to anyone operating aircraft for the transport of passengers, mail or cargo and to other organisations whose primary business is in the air transport industry", having 728 members in 2003, 581 of which were airlines. It is now an IT shop. The beneficiaries of the existence of .aero may be limited to Afilias and the entity known by the initials "SITA", independent of how competent the mission of .aero is executed. In the case of .travel, a 2004 round sTLD applicant ICANN approved, a post-delegation reorganization took place resulting in significant bulk sales of no observable connection to the travel industry. This situation has not drawn formal attention from ICANN for contractual compliance reasons. In the case of .jobs, also a 2004 round sTLD applicant ICANN approved, a similar situation has drawn formal attention from ICANN for contractual compliance reasons. In sum, the absence of beneficiaries other than the applicant or its successor in interest, and the registry services platform operator, for sponsored registries approved in the 2000 and 2004 new gTLD rounds is not an exceptional condition. Neither is it a universal condition, as .cat, .coop, .museum, clearly serve the beneficiaries claimed in their respective applications, and are non-profits operating in the public interest. The second assumes the principle liability that exists is specific to a single application. While possible, this fails to place a controversy in its complete context, and assumes an implied pattern of conduct by an agency of government at a point in time reflects a continuous primary issue of that agency. The Bush-Cheney Administration's lack of commitment to accountability and transparency is a matter of record, or gaps in the record, to make the obvious pun. Yet accountability and transparency have been required to implement in the transition from a MoU to a subsequent relationship between a private corporation and the Department of Commerce. The current Administration's public comments began with Deputy Assistant Secretary Anna Gomez' observation that there is "no statutory authority", and continues to Secretary Larry Strickland's observation at Silicon Flatirons that accountability and transparency must be acted upon by June of this year.[1] The liability, only in theory, untested as yet, whether the specific liability cited above, or a general liability, may include whether ICANN is exercising delegated rule making and is therefore subject to the Administrative Procedures Act of 1946, as are other 501(c)(3)s to which an agency of government has delegated rule making. Well, that's enough for a Sunday morning sermon on the beneficiaries of sTLDs, whether pew safe or not, and the cloud of liabilities that surround a corporation that manages a contract originally between the Department of Defense and SRI International. Eric [1] http://www.ntia.doc.gov/presentations/2011/siliconflatirons_02142011.html From fredr at geexology.org Sun Mar 27 09:00:12 2011 From: fredr at geexology.org (Fred Richards) Date: Sun, 27 Mar 2011 10:00:12 -0400 Subject: The growth of municipal broadband networks In-Reply-To: <4DE0E80D542147239C7F416E289278FA@DELL16> References: <13648904.622.1301207775819.JavaMail.root@benjamin.baylink.com> <1FE6B158-60B9-4427-A80D-22AF96A2E627@delong.com> <4DE0E80D542147239C7F416E289278FA@DELL16> Message-ID: I've been a geek since I was a kid, and I'm now in my mid thirties. I had worked at an ISP in Central NY for several years until my wife and I decided to move south, to warmer weather. We ended up in South Carolina where I found a job as the Senior Network Engineer for a small datacenter company. Muni networks have always been an interest of mine. Imagine my surprise a few years ago, when the switch from analog to digital television would open spectrum for wireless broadband use like WiMax. Imagine my further surprise to learn SC's education system owned all of the spectrum in the state! An awesome, state-wide muni network was sure to spring from this. You can find info for it here (http://scetv.org/about/distribution.cfm) and here (http://ebscommission.sc.gov/). The kicker is, they have until May of this year to show progress on a viable plan or else they lose the spectrum. This entire project seems to have been dropped to the floor. Notice the broken link on the first page? And no recent updates on the second? I think they fell victim to local cable and telco incumbants... It's really discouraging. -- ? ? ? ? ? ? ? ? ? ? ? Fred From fredr at geexology.org Sun Mar 27 09:05:19 2011 From: fredr at geexology.org (Fred Richards) Date: Sun, 27 Mar 2011 10:05:19 -0400 Subject: The growth of municipal broadband networks In-Reply-To: References: <13648904.622.1301207775819.JavaMail.root@benjamin.baylink.com> <1FE6B158-60B9-4427-A80D-22AF96A2E627@delong.com> <4DE0E80D542147239C7F416E289278FA@DELL16> Message-ID: It seemes like it died on the vine: http://www.free-times.com/index.php?cat=1992912064017974&ShowArticle_ID=11011108100414529 -- ? ? ? ? ? ? ? ? ? ? ? Fred From mark at bernoullinetworks.com Sun Mar 27 09:58:29 2011 From: mark at bernoullinetworks.com (Mark Leonard) Date: Sun, 27 Mar 2011 08:58:29 -0600 Subject: Using Region-X assigned IP space in =?UTF-8?Q?Region-Y=3F?= Message-ID: <0afe2c26c46055ecb27194d302b0d9a7@localhost> Hello NANOG'ers, This is a question that popped into my mind recently. So far my google-fu has not turned up anything of use. Imagine a company that has an RIR-assigned IPv4/23, and has it subnetted into a pair of /24's so that they can have replicated datacenters in two different geographical locations each running its own BGP infrastructure (using the same ASN). As far as I can see, this is all fine and good assuming that these two sites are in the same RIR's domain. Is it possible/allowable to move one of these datacenters to a different geographical region with a different RIR and keep using the same two subnets, or will a new /24 need to be requested from the new RIR? If there's a book or reference that answers this question, please let me know - I'm willing to do as much research on my own as I can. Thanks! From Valdis.Kletnieks at vt.edu Sun Mar 27 10:19:06 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 27 Mar 2011 11:19:06 -0400 Subject: Using Region-X assigned IP space in =?UTF-8?Q?Region-Y=3F?= In-Reply-To: Your message of "Sun, 27 Mar 2011 08:58:29 MDT." <0afe2c26c46055ecb27194d302b0d9a7@localhost> References: <0afe2c26c46055ecb27194d302b0d9a7@localhost> Message-ID: <40362.1301239146@localhost> On Sun, 27 Mar 2011 08:58:29 MDT, Mark Leonard said: > Is it possible/allowable to move one of these datacenters to a different > geographical region with a different RIR and keep using the same two > subnets, or will a new /24 need to be requested from the new RIR? There's only one question to be asked - will the (possibly new) upstream of the moved datacenter announce the route for the /24 or not? There's plenty of AS's that announce little chunks on different continents, as long as the upstreams will carry the announcement, you're golden. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nick at foobar.org Sun Mar 27 10:53:56 2011 From: nick at foobar.org (Nick Hilliard) Date: Sun, 27 Mar 2011 16:53:56 +0100 Subject: Regional AS model In-Reply-To: <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> Message-ID: <4D8F5D94.5050906@foobar.org> On 27/03/2011 07:53, Patrick W. Gilmore wrote: > Accepting default is not ugly, especially if you don't even have a > backbone connecting your sites. And even if we could argue over > default's aesthetic qualities (which, honestly, I don't see how we can), > there is no rational person who would consider it a hack. accepting default has one important drawback for smaller networks: it causes loose urpf not to work for transit connections, and this causes remotely triggered blackhole discards not to work as expected. Depending on your requirements, this may or may not be a concern to worry about. Nick From zaid at zaidali.com Sun Mar 27 12:10:56 2011 From: zaid at zaidali.com (Zaid Ali) Date: Sun, 27 Mar 2011 10:10:56 -0700 Subject: Using Region-X assigned IP space in Region-Y? In-Reply-To: <40362.1301239146@localhost> Message-ID: On 3/27/11 8:19 AM, "Valdis.Kletnieks at vt.edu" wrote: > On Sun, 27 Mar 2011 08:58:29 MDT, Mark Leonard said: > >> Is it possible/allowable to move one of these datacenters to a different >> geographical region with a different RIR and keep using the same two >> subnets, or will a new /24 need to be requested from the new RIR? > > There's only one question to be asked - will the (possibly new) upstream > of the moved datacenter announce the route for the /24 or not? Why would the new upstream refuse to announce the /24 assuming he has the correct information for his route objects and visible through the RIR database. Zaid From maxlarson.henry at transversal.ht Sun Mar 27 12:39:07 2011 From: maxlarson.henry at transversal.ht (Max Larson Henry) Date: Sun, 27 Mar 2011 12:39:07 -0500 Subject: Using Region-X assigned IP space in Region-Y? In-Reply-To: <0afe2c26c46055ecb27194d302b0d9a7@localhost> References: <0afe2c26c46055ecb27194d302b0d9a7@localhost> Message-ID: > > > As far as I can see, this is all fine and good assuming that these two > sites are in the same RIR's domain. > > Is it possible/allowable to move one of these datacenters to a different > geographical region with a different RIR and keep using the same two > subnets, or will a new /24 need to be requested from the new RIR? > > If there's a book or reference that answers this question, please let me > know - I'm willing to do as much research on my own as I can. - RIR Comparative Policy Overview http://www.nro.net/category/documents/rir-comparative-policy-overview and AfriNIC http://www.afrinic.net/policy.htm APNIC http://www.apnic.net/policy/current ARIN http://www.arin.net/policy LACNIC http://lacnic.net/en/politicas RIPE NCC http://www.ripe.net/ripe/policies/ -M From nanog at jima.tk Sun Mar 27 12:54:52 2011 From: nanog at jima.tk (Jima) Date: Sun, 27 Mar 2011 12:54:52 -0500 Subject: Using Region-X assigned IP space in Region-Y? In-Reply-To: References: Message-ID: <4D8F79EC.1080805@jima.tk> On 3/27/2011 12:10 PM, Zaid Ali wrote: > On 3/27/11 8:19 AM, "Valdis.Kletnieks at vt.edu" > wrote: >> There's only one question to be asked - will the (possibly new) upstream >> of the moved datacenter announce the route for the /24 or not? > > Why would the new upstream refuse to announce the /24 assuming he has the > correct information for his route objects and visible through the RIR > database. Some transit providers dislike announcing smaller networks, and thus have lower limits. Jima From zaid at zaidali.com Sun Mar 27 13:03:10 2011 From: zaid at zaidali.com (Zaid Ali) Date: Sun, 27 Mar 2011 11:03:10 -0700 Subject: Using Region-X assigned IP space in Region-Y? In-Reply-To: <4D8F79EC.1080805@jima.tk> Message-ID: On 3/27/11 10:54 AM, "Jima" wrote: > On 3/27/2011 12:10 PM, Zaid Ali wrote: >> On 3/27/11 8:19 AM, "Valdis.Kletnieks at vt.edu" >> wrote: >>> There's only one question to be asked - will the (possibly new) upstream >>> of the moved datacenter announce the route for the /24 or not? >> >> Why would the new upstream refuse to announce the /24 assuming he has the >> correct information for his route objects and visible through the RIR >> database. > > Some transit providers dislike announcing smaller networks, and thus > have lower limits. > > Jima > Then the said transit provider customer will turn off the circuit and move to the next transit provider that doesn't have a problem with /24. If you are in a monopolistic ISP environment then it is different and that is a different topicof discussion. Sadly been there done that. Zaid From jeremyparr at gmail.com Sun Mar 27 13:27:41 2011 From: jeremyparr at gmail.com (Jeremy Parr) Date: Sun, 27 Mar 2011 14:27:41 -0400 Subject: Undersea fiber contractors Message-ID: We are looking to install a few repeaterless undersea fiber runs <100miles at depths of no more than a few hundred feet. Does anyone have any leads? From johnl at iecc.com Sun Mar 27 13:35:17 2011 From: johnl at iecc.com (John Levine) Date: 27 Mar 2011 18:35:17 -0000 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <4D8F2F2E.2020203@nic-naa.net> Message-ID: <20110327183517.6073.qmail@joyce.lan> >> ... I expect the board and staff really >> really would not want to have to answer questions under oath like "who >> did you talk to at the US Department of Commerce about the .XXX >> application and what did you say?" and "why did you vote against .XXX >> when they followed the same rules as the TLDs you voted for?" > >The first assumes that a beneficiary should exist that is distinct >from the applicant-sponsor. On the contrary. Since it is clear that all of the other sTLDs have failed to attract the predicted support from their nominal communities, why should a similar lack of support for .XXX make any difference? >The second assumes the principle liability that exists is specific to >a single application. > >While possible, this fails to place a controversy in its complete >context, and assumes an implied pattern of conduct by an agency of >government at a point in time reflects a continuous primary issue of >that agency. Heck no. I expect that were a case to bring documents to light, they would show that what ICANN said to the US government was at odds with what they were saying in public. I know none of us would find that at all surprising, but we're not a judge looking at the contracts. R's, John From Valdis.Kletnieks at vt.edu Sun Mar 27 13:42:35 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 27 Mar 2011 14:42:35 -0400 Subject: Using Region-X assigned IP space in Region-Y? In-Reply-To: Your message of "Sun, 27 Mar 2011 12:54:52 CDT." <4D8F79EC.1080805@jima.tk> References: <4D8F79EC.1080805@jima.tk> Message-ID: <51116.1301251355@localhost> On Sun, 27 Mar 2011 12:54:52 CDT, Jima said: > On 3/27/2011 12:10 PM, Zaid Ali wrote: > > On 3/27/11 8:19 AM, "Valdis.Kletnieks at vt.edu" > > wrote: > >> There's only one question to be asked - will the (possibly new) upstream > >> of the moved datacenter announce the route for the /24 or not? > > > > Why would the new upstream refuse to announce the /24 assuming he has the > > correct information for his route objects and visible through the RIR > > database. > > Some transit providers dislike announcing smaller networks, and thus > have lower limits. Which is why I said you need to find a willing upstream. And yes, if Mark moving into a monopoly area, he'll probably have to do it the way the monopoly wants it done. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From brunner at nic-naa.net Sun Mar 27 15:01:07 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 27 Mar 2011 16:01:07 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <20110327183517.6073.qmail@joyce.lan> References: <20110327183517.6073.qmail@joyce.lan> Message-ID: <4D8F9783.9070708@nic-naa.net> On 3/27/11 2:35 PM, John Levine wrote: >>> ... I expect the board and staff really >>> really would not want to have to answer questions under oath like "who >>> did you talk to at the US Department of Commerce about the .XXX >>> application and what did you say?" and "why did you vote against .XXX >>> when they followed the same rules as the TLDs you voted for?" >> >> The first assumes that a beneficiary should exist that is distinct >>from the applicant-sponsor. > > On the contrary. Since it is clear that all of the other sTLDs have > failed to attract the predicted support from their nominal > communities, why should a similar lack of support for .XXX make any > difference? First, you (John Levine) are free to interpret the comments of Stephen Fouant (the author of the first comment) any way you please, his statement (below) suggested to me that he expected to find a beneficiary other than the applicant (consistent with rfc1591 aka ICP-1), and he did not also assert that beneficiaries other than the applicant do not exist for all other sTLD applicants, or perhaps all other gTLD operators. >> I can't seem to find anyone that would benefit from this, with the exception >> of Stuart and ICM's shareholders. However, you're free to assert the contrary, though to what is unclear to me. Next, on what basis do you make the claim that .coop and .cat have failed to attract the predicted support from their nominal communities? >> The second assumes the principle liability that exists is specific to >> a single application. >> >> While possible, this fails to place a controversy in its complete >> context, and assumes an implied pattern of conduct by an agency of >> government at a point in time reflects a continuous primary issue of >> that agency. > > Heck no. I expect that were a case to bring documents to light, they > would show that what ICANN said to the US government was at odds with > what they were saying in public. I know none of us would find that at > all surprising, but we're not a judge looking at the contracts. I don't think you caught the sense of my point that the transparency and accountability issue may transcend any specific case or controversy, however, as I pointed out, all theories of ICANN liability wait for a first test, and so are all equally hypothetical. Eric From johnl at iecc.com Sun Mar 27 15:36:32 2011 From: johnl at iecc.com (John Levine) Date: 27 Mar 2011 20:36:32 -0000 Subject: not really ICANN approves .XXX red-light district for the Internet In-Reply-To: <4D8F9783.9070708@nic-naa.net> Message-ID: <20110327203632.65784.qmail@joyce.lan> >Next, on what basis do you make the claim that .coop and .cat have >failed to attract the predicted support from their nominal communities? Arithmetic, mostly. There are 40,000 co-ops in the United States, 160,000 in Europe, and apparently several million world-wide, yet there are only 6700 domains in .COOP. I would find it hard to say that under 3% takeup was significant support. The population of Catalonia is about the same as that of Switzerland or Hong Kong. There are 47,000 domains in .CAT, over 200,000 in .HK, and about two million in .CH. Of those 47,000, about 7,000 have DNS on Nominalia's servers, and spot checking suggests most of those are parked. I suppose one could argue in both cases that the existence of any registrations at all shows "support", in which case .MUSEUM is a rousing success, too. R's, John PS: >I don't think you caught the sense of my point that the transparency >and accountability issue may transcend any specific case or >controversy, however, as I pointed out, all theories of ICANN >liability wait for a first test, and so are all equally hypothetical. You're certainly right that it's hypothetical, since as far as I can recall, no case against ICANN since Karl Auerbach's has gone to trial, but I don't see how this disagrees at all with my theory that ICANN fears discovery because it would be embarassing. It would show how opaque and unaccountable ICANN is. From brunner at nic-naa.net Sun Mar 27 15:59:01 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 27 Mar 2011 16:59:01 -0400 Subject: not really ICANN approves .XXX red-light district for the Internet In-Reply-To: <20110327203632.65784.qmail@joyce.lan> References: <20110327203632.65784.qmail@joyce.lan> Message-ID: <4D8FA515.5070706@nic-naa.net> On 3/27/11 4:36 PM, John Levine wrote: >> Next, on what basis do you make the claim that .coop and .cat have >> failed to attract the predicted support from their nominal communities? > > Arithmetic, mostly. There are 40,000 co-ops in the United States, > 160,000 in Europe, and apparently several million world-wide, yet > there are only 6700 domains in .COOP. I would find it hard to say > that under 3% takeup was significant support. Do you attach any significance to the restriction that the .coop operator has to use non-cooperatives as sales channels and the primary means of relations with cooperatives as registrants? I do, I thought we had an initial exemption from the registrar requirement at the Montevideo meeting, for .museum and for .coop. Additionally, do you attach any significance to the absence of a restriction on the incumbent monopoly operator from accepting or retaining registrations from cooperatives? Note, that cooperatives with registrations in the legacy monopoly name spaces could be, but are not, accounted for revenue purposes, as .coop registrants. > The population of Catalonia is about the same as that of Switzerland > or Hong Kong. There are 47,000 domains in .CAT, over 200,000 in .HK, > and about two million in .CH. Of those 47,000, about 7,000 have DNS > on Nominalia's servers, and spot checking suggests most of those are > parked. The Nominalia issue is one registrar. The .cat name space has been available for only 5 years, the .hk and .ch name spaces since 1986. The rate of growth for .cat has been 10k/yr for each of five years, and assuming no changes, will reach the relative densities of western European national name spaces. Given our difference in perspectives, and values, I'll stop now. Eric From young at jsyoung.net Sun Mar 27 16:31:11 2011 From: young at jsyoung.net (Jeffrey S. Young) Date: Mon, 28 Mar 2011 08:31:11 +1100 Subject: The growth of municipal broadband networks In-Reply-To: <4DE0E80D542147239C7F416E289278FA@DELL16> References: <13648904.622.1301207775819.JavaMail.root@benjamin.baylink.com> <1FE6B158-60B9-4427-A80D-22AF96A2E627@delong.com> <4DE0E80D542147239C7F416E289278FA@DELL16> Message-ID: <37331A5E-36EA-464D-9F05-794AC4F9504F@jsyoung.net> On 27/03/2011, at 6:35 PM, "Michael Painter" wrote: > Owen DeLong wrote: >> On Mar 26, 2011, at 11:36 PM, Jay Ashworth wrote: >>> ----- Original Message ----- >>>> From: "Owen DeLong" >>>> As such, I'm sure that such a move would be vocally opposed by >>>> the current owners of the LMI who enjoy leveraging it to extort >>>> monopolistic pricing from substandard services. >>> As I noted, yes, that's Verizontal, and they have apparently succeeded >>> in lobbying to have it made *illegal* in several states. I don't have >>> citations to hand, but there are a couple sites that track muni fiber; >>> I can find some. >>> Cheers, >>> -- jra >> Laws can be changed if we can get enough momentum behind >> doing the right thing. >> Owen > > http://en.wikipedia.org/wiki/Regulatory_capture > While I agree that laws can and should be changed and I agree that the USA's telco privatization scheme no longer fits the pace of technology, those who believe have a long way toward momentum. Those of us who believe in a muni or a national broadband infrastructure are opposed by a mountain of money (to be made) and an army of lawyers. For instance, when this army couldn't hope to have muni networking outlawed on a national basis they turned to each state legislature. They're ticking off the states one by one: http://www.cybertelecom.org/broadband/muni.htm jy From bogstad at pobox.com Sun Mar 27 16:47:38 2011 From: bogstad at pobox.com (Bill Bogstad) Date: Sun, 27 Mar 2011 17:47:38 -0400 Subject: characterizing BGP updates (research topic?) Message-ID: Under a different subject Bill Woodcock wrote: > > On Mar 25, 2011, at 10:51 AM, Patrick W. Gilmore wrote: >> The question is whether "some data" is better than "no data". ?Honestly, I'm not sure. > > Yes, Patrick, I was just trying to be diplomatic about saying "not such a good idea" so he'd keep reading through to the end, where I suggested some other, possibly better, research topics. ?I am, however, certain that other people could suggest even better research topics. ?Good research topics are in demonstrably short supply among networking grad-students, so if y'all want to be helpful... I'm currently looking for data characterizing BGP updates. This page calls out 'bad' guys: http://bgpupdates.potaroo.net/instability/bgpupd.html but I haven't found anything yet which defines the terms or methodologies used. Is there a key for this page somewhere? Are there similar data sources for BGP update stats that go into more detail? I'm personally interested in being able to tell the difference between new announcements/withdrawals of a prefix to the Internet as a whole (insufficient redundancy?) vs. changes in best path (next hop). If I can get my hands on raw BGP update traffic info, I would even consider taking a stab at doing the analysis myself. Pointers to data/previous results (as well as comments on why this is a stupid question) are welcome. Thanks, Bill Bogstad From johnl at iecc.com Sun Mar 27 16:50:31 2011 From: johnl at iecc.com (John R. Levine) Date: 27 Mar 2011 17:50:31 -0400 Subject: not really ICANN approves .XXX red-light district for the Internet In-Reply-To: <4D8FA515.5070706@nic-naa.net> References: <20110327203632.65784.qmail@joyce.lan> <4D8FA515.5070706@nic-naa.net> Message-ID: >> Arithmetic, mostly. There are 40,000 co-ops in the United States, >> 160,000 in Europe, and apparently several million world-wide, yet >> there are only 6700 domains in .COOP. I would find it hard to say >> that under 3% takeup was significant support. > > Do you attach any significance to the restriction that the .coop operator has > to use non-cooperatives as sales channels and the primary means of relations > with cooperatives as registrants? No. They knew about that when they applied. The application for .COOP is archived on the ICANN web site. They predicted with "90% confidence" that they'd have over 100,000 registrations within four years and with "50% confidence" that they'd have 300,000 registrations. They failed. > Note, that cooperatives with registrations in the legacy monopoly name spaces > could be, but are not, accounted for revenue purposes, as .coop registrants. Hmmn, counting people who've decided not to use .COOP as indications of support for .COOP. That's very creative. You sure you don't work for ICANN? > The Nominalia issue is one registrar. The .cat name space has been available > for only 5 years, the .hk and .ch name spaces since 1986. The rate of growth > for .cat has been 10k/yr for each of five years, and assuming no changes, > will reach the relative densities of western European national name spaces. Actually, if you look at the registry reports, there was a burst of about 18,000 domains in .CAT the first year, the annual growth rate has been considerably less than 10K/yr and it is if anything slowing down. From the Nov 10 report, the most recent one ICANN has published, to today, the growth is about 1000, which extrapolates to under 3500/yr, so it'll catch up with the nearby ccTLDs several centuries from now, if ever. I can't find the business plan of the .CAT application on ICANN's web site, but I'd be pretty surprised if it predicted numbers anywhere near that low. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From andrew.wallace at rocketmail.com Sun Mar 27 17:46:24 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sun, 27 Mar 2011 15:46:24 -0700 (PDT) Subject: New tsunami advisory warning - Japan Message-ID: <122834.47305.qm@web59609.mail.ac4.yahoo.com> More information from http://www.jma.go.jp/en/tsunami/ Andrew From bzs at world.std.com Sun Mar 27 18:03:35 2011 From: bzs at world.std.com (Barry Shein) Date: Sun, 27 Mar 2011 19:03:35 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <20110327045654.82924.qmail@joyce.lan> References: <01d201cbec26$ffc082f0$ff4188d0$@net> <20110327045654.82924.qmail@joyce.lan> Message-ID: <19855.49735.922344.605153@world.std.com> On March 27, 2011 at 04:56 johnl at iecc.com (John Levine) wrote: > >What changed ICANN's mind between the ruling in 2007 and the ruling in 2010? > > The growing certainty of an expensive and very embarassing lawsuit if > they turned ICM down. Despite the clear lack of industry support for > .XXX, ICM carefully jumped through every hoop, dotted every i, and > crossed every t in the 2004 application process and the subsequent > appeal and review processes. I expect the board and staff really > really would not want to have to answer questions under oath like "who > did you talk to at the US Department of Commerce about the .XXX > application and what did you say?" and "why did you vote against .XXX > when they followed the same rules as the TLDs you voted for?" This is purely speculative. The correct answer to the question vis a vis 2007-2010 is that a process specified by the ICANN by-laws was followed. This included, significantly, review by an independent non-binding arbitration panel agreed to by both parties. This took some time. Shortly after that 3 member panel issued their recommendation, 2 felt ICANN was violating their own by-laws in rejecting .XXX, one felt (all this is of course overly brief) the by-laws allowed them to reject or accept the application. Then, in December 2010 (Cartagena) the issue was referred to the GAC, ICANN's Govt Advisory Committee who had some shared power in the final decision. Or let's say what power the GAC had was then also an issue, besides their substantive recommendations. And at the San Francisco ICANN meeting earlier this month the ICANN Board of Directors approved a motion to move .XXX along (you are free to read the motion.) That's much of what happened 2007-2010. AS AN ASIDE I don't know that the mere threat of an "expensive" or "embarrassing" lawsuit would be very compelling. Most everything you allude to is practically public knowledge anyhow. For a $65M/year organization like ICANN lawsuits are perhaps not their favorite way to spend money but they're not terribly expensive, it's not a hugely complicated case and would likely only revolve around whether ICANN adhered to their own by-laws or similar (contracts and representations with ICM, prevailing law, undue influence, etc.) Maybe you meant there was a possibility of an expensive judgment? Well, a lot of things happen between the filing of a lawsuit and a judgment, including the possibility of out of court settlements of various sorts which could include simply yielding, i.e., saying ok you (ICM) can have .XXX. My guess is if ICM won such a lawsuit, they get .XXX and perhaps ICANN would have to remunerate them some expenses, and if ICM lost then they lost, they'd get nothing. But this is all counter-factual. -- -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 owen at delong.com Sun Mar 27 19:16:58 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Mar 2011 17:16:58 -0700 Subject: The growth of municipal broadband networks In-Reply-To: <4DE0E80D542147239C7F416E289278FA@DELL16> References: <13648904.622.1301207775819.JavaMail.root@benjamin.baylink.com> <1FE6B158-60B9-4427-A80D-22AF96A2E627@delong.com> <4DE0E80D542147239C7F416E289278FA@DELL16> Message-ID: <815911A3-06CC-4461-B8F8-EEA80CCA77A1@delong.com> On Mar 27, 2011, at 12:35 AM, Michael Painter wrote: > Owen DeLong wrote: >> On Mar 26, 2011, at 11:36 PM, Jay Ashworth wrote: >>> ----- Original Message ----- >>>> From: "Owen DeLong" >>>> As such, I'm sure that such a move would be vocally opposed by >>>> the current owners of the LMI who enjoy leveraging it to extort >>>> monopolistic pricing from substandard services. >>> As I noted, yes, that's Verizontal, and they have apparently succeeded >>> in lobbying to have it made *illegal* in several states. I don't have >>> citations to hand, but there are a couple sites that track muni fiber; >>> I can find some. >>> Cheers, >>> -- jra >> Laws can be changed if we can get enough momentum behind >> doing the right thing. >> Owen > > http://en.wikipedia.org/wiki/Regulatory_capture Yes, that's the reality we're faced with... The question is how do we overcome it and resolve the situation in the public interest. We can either work to resolve the problem, or, accept it as fait acompli and wear the yoke of corporate slavery for the rest of our lives. I, personally, prefer to look for alternatives. Owen From owen at delong.com Sun Mar 27 19:27:10 2011 From: owen at delong.com (Owen DeLong) Date: Sun, 27 Mar 2011 17:27:10 -0700 Subject: Using Region-X assigned IP space in Region-Y? In-Reply-To: <0afe2c26c46055ecb27194d302b0d9a7@localhost> References: <0afe2c26c46055ecb27194d302b0d9a7@localhost> Message-ID: <5C37C28C-1674-46D2-AA0F-14FEC5E52217@delong.com> On Mar 27, 2011, at 7:58 AM, Mark Leonard wrote: > Hello NANOG'ers, > > This is a question that popped into my mind recently. So far my google-fu > has not turned up anything of use. > > Imagine a company that has an RIR-assigned IPv4/23, and has it subnetted > into a pair of /24's so that they can have replicated datacenters in two > different geographical locations each running its own BGP infrastructure > (using the same ASN). > > As far as I can see, this is all fine and good assuming that these two > sites are in the same RIR's domain. > It actually doesn't matter where they are located, but, it is a lot cleaner to use different ASNs as the two networks have different routing policies. > Is it possible/allowable to move one of these datacenters to a different > geographical region with a different RIR and keep using the same two > subnets, or will a new /24 need to be requested from the new RIR? > Yes, not a problem. > If there's a book or reference that answers this question, please let me > know - I'm willing to do as much research on my own as I can. > > Thanks! As a general rule, you can get all your space from the RIR that serves the region where your company has its headquarters, or, you can get space from any region where you have equipment deployed. Owen From brunner at nic-naa.net Sun Mar 27 19:56:29 2011 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Sun, 27 Mar 2011 20:56:29 -0400 Subject: not really ICANN approves .XXX red-light district for the Internet In-Reply-To: References: <20110327203632.65784.qmail@joyce.lan> <4D8FA515.5070706@nic-naa.net> Message-ID: <4D8FDCBD.2070606@nic-naa.net> On 3/27/11 5:50 PM, John R. Levine wrote: >>> Arithmetic, mostly. There are 40,000 co-ops in the United States, >>> 160,000 in Europe, and apparently several million world-wide, yet >>> there are only 6700 domains in .COOP. I would find it hard to say >>> that under 3% takeup was significant support. >> >> Do you attach any significance to the restriction that the .coop >> operator has to use non-cooperatives as sales channels and the >> primary means of relations with cooperatives as registrants? > > No. They knew about that when they applied. You are mistaken. This was a lively subject of negotiation involving Louis Touton and the parties. I was involved as well. There was real shock when Louis came back from the Registrar Constituency with the message that rather than the initial registrar-free budget of initial registrations, the working number was _0_. > The application for .COOP is archived on the ICANN web site. They > predicted with "90% confidence" that they'd have over 100,000 > registrations within four years and with "50% confidence" that they'd > have 300,000 registrations. They failed. See above. >> Note, that cooperatives with registrations in the legacy monopoly >> name spaces could be, but are not, accounted for revenue purposes, >> as .coop registrants. > > Hmmn, counting people who've decided not to use .COOP as indications > of support for .COOP. That's very creative. You sure you don't work > for ICANN? In 2007 I consulted for the IANA function, writing some perl code to process the RT queues and generate reports for the IETF, but otherwise, no. Again, communicating is elusive. Verisign, Afilias, NeuStar and CORE all operate more than a single registry. The original SRS proposal by Kent Crispen, Dave Crocker, Roberto Gateano, and Sylvan Langenbach placed the locus of competition in the registry function. The choice to place the locus of competition in the registrar function does not prevent ICANN from revisiting that choice. The distinction between a registry as a contractual entity, and one or more back end operators, allows a registry to have a registrant as a revenue source, and a party back end operator, not necessarily the same corporate entity or an affiliate of the registry to have the same registrant as a revenue source. Just as Verisign was required to participate in the redelegation of .org, Verisign could be required to revenue share for registries its market power harms, in this case, a registry created for cooperatives. >> The Nominalia issue is one registrar. The .cat name space has been >> available for only 5 years, the .hk and .ch name spaces since 1986. >> The rate of growth for .cat has been 10k/yr for each of five years, >> and assuming no changes, will reach the relative densities of >> western European national name spaces. > > Actually, if you look at the registry reports, there was a burst of > about 18,000 domains in .CAT the first year, the annual growth rate > has been considerably less than 10K/yr and it is if anything slowing > down. From the Nov 10 report, the most recent one ICANN has published, > to today, the growth is about 1000, which extrapolates to under > 3500/yr, so it'll catch up with the nearby ccTLDs several centuries > from now, if ever. I can't find the business plan of the .CAT > application on ICANN's web site, but I'd be pretty surprised if it > predicted numbers anywhere near that low. I'll ask Nacho or Jordi tomorrow morning to comment. You could be right. Eric From Valdis.Kletnieks at vt.edu Sun Mar 27 19:59:59 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 27 Mar 2011 20:59:59 -0400 Subject: New tsunami advisory warning - Japan In-Reply-To: Your message of "Sun, 27 Mar 2011 15:46:24 PDT." <122834.47305.qm@web59609.mail.ac4.yahoo.com> References: <122834.47305.qm@web59609.mail.ac4.yahoo.com> Message-ID: <69547.1301273999@localhost> On Sun, 27 Mar 2011 15:46:24 PDT, "andrew.wallace" said: > More information from http://www.jma.go.jp/en/tsunami/ Has expired already, but only predicted a 0.5 meter crest. http://www.jma.go.jp/en/tsunami/info_04_20110328072748.html *yawn*. A foot and a half isn't going to be all *that* bad unless focused by some very strange local geography. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tvhawaii at shaka.com Sun Mar 27 20:07:37 2011 From: tvhawaii at shaka.com (Michael Painter) Date: Sun, 27 Mar 2011 15:07:37 -1000 Subject: The growth of municipal broadband networks References: <13648904.622.1301207775819.JavaMail.root@benjamin.baylink.com> <1FE6B158-60B9-4427-A80D-22AF96A2E627@delong.com> <4DE0E80D542147239C7F416E289278FA@DELL16> <815911A3-06CC-4461-B8F8-EEA80CCA77A1@delong.com> Message-ID: Owen DeLong wrote: > On Mar 27, 2011, at 12:35 AM, Michael Painter wrote: > >> Owen DeLong wrote: >>> On Mar 26, 2011, at 11:36 PM, Jay Ashworth wrote: >>>> ----- Original Message ----- >>>>> From: "Owen DeLong" >>>>> As such, I'm sure that such a move would be vocally opposed by >>>>> the current owners of the LMI who enjoy leveraging it to extort >>>>> monopolistic pricing from substandard services. >>>> As I noted, yes, that's Verizontal, and they have apparently succeeded >>>> in lobbying to have it made *illegal* in several states. I don't have >>>> citations to hand, but there are a couple sites that track muni fiber; >>>> I can find some. >>>> Cheers, >>>> -- jra >>> Laws can be changed if we can get enough momentum behind >>> doing the right thing. >>> Owen >> >> http://en.wikipedia.org/wiki/Regulatory_capture > > Yes, that's the reality we're faced with... The question is how do we > overcome it and resolve the situation in the public interest. We can > either work to resolve the problem, or, accept it as fait acompli and > wear the yoke of corporate slavery for the rest of our lives. I, personally, > prefer to look for alternatives. > > Owen Yeah, well, I have an "Anonymous" t-shirt, but clearly I'm in the minority. Maybe a 'turncoat' member of the Plutocracy, with multi-millions of $ laying around, can be persuaded to mount a Presidential campaign and try the "Change We Can Believe In" schtick again?...naaa. Your turn. --Michael From andrew.wallace at rocketmail.com Sun Mar 27 20:28:59 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Sun, 27 Mar 2011 18:28:59 -0700 (PDT) Subject: New tsunami advisory warning - Japan Message-ID: <68456.56069.qm@web59611.mail.ac4.yahoo.com> On Mon, Mar 28, 2011 at 1:59 AM,? wrote: > *yawn*.? A foot and a half isn't going to be all *that* bad Remember a wall of tsunami water travels in general at approx 970 kph (600 mph), think about it. From jra at baylink.com Sun Mar 27 20:34:35 2011 From: jra at baylink.com (Jay Ashworth) Date: Sun, 27 Mar 2011 21:34:35 -0400 (EDT) Subject: The growth of municipal broadband networks In-Reply-To: Message-ID: <10160102.732.1301276075125.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Michael Painter" > Maybe a 'turncoat' member of the Plutocracy, with multi-millions of $ > laying around, can be persuaded to mount a > Presidential campaign and try the "Change We Can Believe In" schtick > again?...naaa. Well, not a presidential campaign... but my opinion is that this is what Google Fiber is all about... Cheers, -- jra From johnl at iecc.com Sun Mar 27 21:15:23 2011 From: johnl at iecc.com (John R. Levine) Date: 27 Mar 2011 22:15:23 -0400 Subject: not really ICANN approves .XXX red-light district for the Internet In-Reply-To: <4D8FDCBD.2070606@nic-naa.net> References: <20110327203632.65784.qmail@joyce.lan> <4D8FA515.5070706@nic-naa.net> <4D8FDCBD.2070606@nic-naa.net> Message-ID: >> No. They knew about that when they applied. > > You are mistaken. This was a lively subject of negotiation involving Louis > Touton and the parties. I was involved as well. There was real shock when > Louis came back from the Registrar Constituency with the message that rather > than the initial registrar-free budget of initial registrations, the working > number was _0_. If their application was predicated on ICANN changing the rules, I can't feel very sorry for them. And in any event, it's a bit much to claim that the difference between 300,000 registrations and 6400 registrations is that people have to find a registrar. If there were really 293,600 people eager to register if they could only find a coopful registrar, I'd expect we'd have a few, >> Actually, if you look at the registry reports, there was a burst of >> about 18,000 domains in .CAT the first year, the annual growth rate >> has been considerably less than 10K/yr and it is if anything slowing >> down. From the Nov 10 report, the most recent one ICANN has published, >> to today, the growth is about 1000, which extrapolates to under >> 3500/yr, so it'll catch up with the nearby ccTLDs several centuries >> from now, if ever. I can't find the business plan of the .CAT >> application on ICANN's web site, but I'd be pretty surprised if it >> predicted numbers anywhere near that low. > > I'll ask Nacho or Jordi tomorrow morning to comment. You could be right. It's all in the reports on the ICANN web site, except for the current count which I got by grepping the zone file. No secrets there. Regards, John Levine, johnl at iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly From scott at doc.net.au Sun Mar 27 21:34:34 2011 From: scott at doc.net.au (Scott Howard) Date: Sun, 27 Mar 2011 19:34:34 -0700 Subject: [v6z] Re: New tsunami advisory warning - Japan In-Reply-To: <68456.56069.qm@web59611.mail.ac4.yahoo.com> References: <68456.56069.qm@web59611.mail.ac4.yahoo.com> Message-ID: On Sun, Mar 27, 2011 at 6:28 PM, andrew.wallace < andrew.wallace at rocketmail.com> wrote: > On Mon, Mar 28, 2011 at 1:59 AM, wrote: > > *yawn*. A foot and a half isn't going to be all *that* bad > > Remember a wall of tsunami water travels in general at approx 970 kph (600 > mph), think about it. > That's in deep water, where the height of the wave might be a few inches at most. Once it reaches shallow water the speed drops significantly and the height increases. Scott From fmartin at linkedin.com Sun Mar 27 22:05:29 2011 From: fmartin at linkedin.com (Franck Martin) Date: Mon, 28 Mar 2011 03:05:29 +0000 Subject: [v6z] Re: New tsunami advisory warning - Japan In-Reply-To: Message-ID: And then you can have lens effects, where the waves reflections on the coast, focus unto a point on the coastline. On 3/28/11 14:34 , "Scott Howard" wrote: >On Sun, Mar 27, 2011 at 6:28 PM, andrew.wallace < >andrew.wallace at rocketmail.com> wrote: > >> On Mon, Mar 28, 2011 at 1:59 AM, wrote: >> > *yawn*. A foot and a half isn't going to be all *that* bad >> >> Remember a wall of tsunami water travels in general at approx 970 kph >>(600 >> mph), think about it. >> > >That's in deep water, where the height of the wave might be a few inches >at >most. > >Once it reaches shallow water the speed drops significantly and the height >increases. > > Scott From rdobbins at arbor.net Sun Mar 27 22:44:06 2011 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 28 Mar 2011 03:44:06 +0000 Subject: Paul Baran, RIP. Message-ID: ----------------------------------------------------------------------- Roland Dobbins // The basis of optimism is sheer terror. -- Oscar Wilde From dhc2 at dcrocker.net Sun Mar 27 23:35:13 2011 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Mon, 28 Mar 2011 06:35:13 +0200 Subject: Paul Baran, RIP. In-Reply-To: References: Message-ID: <4D901001.1030904@dcrocker.net> On 3/28/2011 5:44 AM, Dobbins, Roland wrote: > > Katie Hafner's (Where Wizards Stay Up Late) obit on Paul is also quite good: -- Dave Crocker Brandenburg InternetWorking bbiw.net From Gavin.Pearce at 3seven9.com Mon Mar 28 05:43:00 2011 From: Gavin.Pearce at 3seven9.com (Gavin Pearce) Date: Mon, 28 Mar 2011 11:43:00 +0100 Subject: New tsunami advisory warning - Japan In-Reply-To: <68456.56069.qm@web59611.mail.ac4.yahoo.com> References: <68456.56069.qm@web59611.mail.ac4.yahoo.com> Message-ID: > *yawn*. A foot and a half isn't going to be all *that* bad Sorry to continue off topic: Try to imagine ... a temporary very high tide, rather than a cresting wave. In addition to the "height", it's the wave-length you have to take into account. Tsunami's rarely become towering breaking waves. [That said, tsunamis can form into a bore - a step-like wave with a steep breaking front. Likely if the tsunami moves from deep water into a shallow river / bay] 1 1/2 foot on top of an existing high tide, could easily cause further flooding in the wrong locations (although as mentioned, not to the levels already experienced). > travels in general at approx 970 kph (600 mph) True in the deepest parts of open ocean - upon reaching the shore-line it'll be travelling a lot slower. // Gav From joelja at bogus.com Mon Mar 28 06:20:23 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 28 Mar 2011 04:20:23 -0700 Subject: Creating an IPv6 addressing plan for end users In-Reply-To: References: Message-ID: <4D906EF7.8030804@bogus.com> On 3/23/11 6:14 AM, Hammer wrote: > Nathalie, > As an end customer (not a carrier) over in ARIN land I purchased a /48 > about a year ago for our future IPv6 needs. We have 4 different Internet > touchpoints (two per carrier) all rated at about 1Gbps. Recently, both > carriers told us that the minimum advertisement they would accept PER > CIRCUIT would be a /48. I was surprised to say the least. Basically a /48 > would not be enough for us. The arguement was that this was to support all > the summarization efforts and blah blah blah. Even though my space would be > unique to either carrier. So now I'm contemplating a much larger block. > Seems wasteful but I have to for the carriers. Have you heard of this > elsewhere or is this maybe just an ARIN/American thing? Both carriers told > me that in discussions with their peers that they were all doing this. there are providers that will accept more specific prefixes from the customers for internal use. since /48 is the minimum arin allocation there is observed to be general consensus on not accepting prefixes longer than /48 into the dfz. http://www.verizonbusiness.com/Products/networking/internet/ipv6/policy.xml is one such example of a transit provider that will carry longer prefixes internally. > > -Hammer- > > "I was a normal American nerd." > -Jack Herer > > > > > > On Wed, Mar 16, 2011 at 1:52 PM, Schiller, Heather A < > heather.schiller at verizonbusiness.com> wrote: > >> >> For those who don't like clicking on random bit.ly links: >> >> http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6 >> _addr_plan4.pdf >> >> --Heather >> >> -----Original Message----- >> From: Nathalie Trenaman [mailto:nathalie at ripe.net] >> Sent: Wednesday, March 16, 2011 5:05 AM >> To: nanog at nanog.org >> Subject: Creating an IPv6 addressing plan for end users >> >> Hi all, >> >> In our IPv6 courses, we often get the question: I give my customers a >> /48 (or a /56 or a /52) but they have no idea how to distribute that >> space in their network. >> In December Sander Steffann and Surfnet wrote a manual explaining >> exactly that, in clear language with nice graphics. A very useful >> document but it was in Dutch, so RIPE NCC decided to translate that >> document to English. >> >> Yesterday, we have published that document on our website and we hope >> this document is able to take away some of the fear that end users seem >> to have for these huge blocks. >> You can find this document here: >> >> http://bit.ly/IPv6addrplan (PDF) >> >> I look forward to your feedback, tips and comments. >> >> With kind regards, >> >> Nathalie Trenaman >> RIPE NCC Trainer >> >> > From jra at baylink.com Mon Mar 28 08:14:18 2011 From: jra at baylink.com (Jay Ashworth) Date: Mon, 28 Mar 2011 09:14:18 -0400 (EDT) Subject: Paul Baran, RIP. In-Reply-To: Message-ID: <14930353.820.1301318058007.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "Roland Dobbins" > Oh hell; now we'll *never* lay the ghost of "packet switching was invented to create a nuclear-war-survivable network". [ reads obit ] See? Happy Landings, Dr B. Cheers, -- jra From llynch at civil-tongue.net Mon Mar 28 08:26:29 2011 From: llynch at civil-tongue.net (Lucy Lynch) Date: Mon, 28 Mar 2011 06:26:29 -0700 (PDT) Subject: Paul Baran, RIP. In-Reply-To: <14930353.820.1301318058007.JavaMail.root@benjamin.baylink.com> References: <14930353.820.1301318058007.JavaMail.root@benjamin.baylink.com> Message-ID: On Mon, 28 Mar 2011, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Roland Dobbins" > >> > > Oh hell; now we'll *never* lay the ghost of "packet switching was > invented to create a nuclear-war-survivable network". > > [ reads obit ] > > See? The Man Who Shot Liberty Valance (1962) Ransom Stoddard: You're not going to use the story, Mr. Scott? Maxwell Scott: No, sir. This is the West, sir. When the legend becomes fact, print the legend. - Lucy > Happy Landings, Dr B. > > Cheers, > -- jra > From andrew.wallace at rocketmail.com Mon Mar 28 08:31:47 2011 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Mon, 28 Mar 2011 06:31:47 -0700 (PDT) Subject: New tsunami advisory warning - Japan Message-ID: <864710.90558.qm@web59612.mail.ac4.yahoo.com> On Mon, Mar 28, 2011 at 11:43 AM, Gavin Pearce wrote: >> travels in general at approx 970 kph (600 mph) > > True in the deepest parts of open ocean - upon reaching the shore-line > it'll be travelling a lot slower. You guys forget a lot of folks on the list are working on cabling ships and off shore platforms, its not all about what happens on shore in this industry. Andrew From nick at foobar.org Mon Mar 28 08:43:14 2011 From: nick at foobar.org (Nick Hilliard) Date: Mon, 28 Mar 2011 14:43:14 +0100 Subject: Regional AS model In-Reply-To: <4D8F5D94.5050906@foobar.org> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> <4D8F5D94.5050906@foobar.org> Message-ID: <4D909072.9020806@foobar.org> On 27/03/2011 16:53, Nick Hilliard wrote: > accepting default has one important drawback for smaller networks: it > causes loose urpf not to work for transit connections, and this causes > remotely triggered blackhole discards not to work as expected. Depending on > your requirements, this may or may not be a concern to worry about. sigh, dumbass and blindingly wrong postings like this provide the evidence of why it's best to stay in the garden reading a good book on a warm sunday afternoon, rather than distractedly replying to the occasional email on nanog. Nick From mike at mtcc.com Mon Mar 28 09:04:48 2011 From: mike at mtcc.com (Michael Thomas) Date: Mon, 28 Mar 2011 07:04:48 -0700 Subject: New tsunami advisory warning - Japan In-Reply-To: References: <68456.56069.qm@web59611.mail.ac4.yahoo.com> Message-ID: <4D909580.6060101@mtcc.com> Gavin Pearce wrote: >> *yawn*. A foot and a half isn't going to be all *that* bad > > Sorry to continue off topic: > > Try to imagine ... a temporary very high tide, rather than a cresting > wave. In addition to the "height", it's the wave-length you have to take > into account. Tsunami's rarely become towering breaking waves. > Quite right. The other part is that the water becomes a very fast moving river, especially in places where it's not normally one. Watching the footage from the Santa Cruz harbor it wasn't the height that was a particular problem, but the fact that all of a sudden you had a 5-10 knot current. And this happened at low tide, so it would have been far worse if it happened at high tide. There was a pretty spectacular photo of the tsunami that appeared to be around the Emeryville flats. Only about 6 or so inches high, but massive. Had it been at high tide, it could have probably done some nasty things... like, oh for example, the sewage treatment plant next to the Bay Bridge comes to mind. Mike From Gavin.Pearce at 3seven9.com Mon Mar 28 09:57:08 2011 From: Gavin.Pearce at 3seven9.com (Gavin Pearce) Date: Mon, 28 Mar 2011 15:57:08 +0100 Subject: New tsunami advisory warning - Japan In-Reply-To: <864710.90558.qm@web59612.mail.ac4.yahoo.com> References: <864710.90558.qm@web59612.mail.ac4.yahoo.com> Message-ID: > You guys forget a lot of folks on the list are working on cabling ships and off shore platforms, its not all about what happens on shore in this industry. Valid point ... however in deep ocean, these things are pretty imperceptible. The effect on ships on the surface are nominal, and off shore platforms are (generally) built with these things in mind: http://www.msnbc.msn.com/id/27324535/ns/technology_and_science-innovation/ At the other extreme, Lituya Bay is a good example of a Mega Tsunami (1,720 feet): http://en.wikipedia.org/wiki/1958_Lituya_Bay_megatsunami From tme at americafree.tv Mon Mar 28 10:28:29 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 28 Mar 2011 11:28:29 -0400 Subject: New tsunami advisory warning - Japan In-Reply-To: References: <864710.90558.qm@web59612.mail.ac4.yahoo.com> Message-ID: On Mar 28, 2011, at 10:57 AM, Gavin Pearce wrote: >> You guys forget a lot of folks on the list are working on cabling ships and off shore platforms, its not all about what happens on shore in this industry. > > > > Valid point ... however in deep ocean, these things are pretty imperceptible. The effect on ships on the surface are nominal, and off shore platforms are (generally) built with these things in mind: http://www.msnbc.msn.com/id/27324535/ns/technology_and_science-innovation/ > Here is a video of the recent Japanese tsunami from a JCG ship in the the open ocean. The waves (@ ~4:20 and 6:40 into the video) caused them no trouble, but they were certainly not imperceptible. Regards Marshall > > > At the other extreme, Lituya Bay is a good example of a Mega Tsunami (1,720 feet): > > http://en.wikipedia.org/wiki/1958_Lituya_Bay_megatsunami > > > > > > > > > > > > > From tme at americafree.tv Mon Mar 28 12:03:13 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 28 Mar 2011 13:03:13 -0400 Subject: New tsunami advisory warning - Japan In-Reply-To: References: <864710.90558.qm@web59612.mail.ac4.yahoo.com> Message-ID: On Mar 28, 2011, at 11:28 AM, Marshall Eubanks wrote: > > On Mar 28, 2011, at 10:57 AM, Gavin Pearce wrote: > >>> You guys forget a lot of folks on the list are working on cabling ships and off shore platforms, its not all about what happens on shore in this industry. >> >> >> >> Valid point ... however in deep ocean, these things are pretty imperceptible. The effect on ships on the surface are nominal, and off shore platforms are (generally) built with these things in mind: http://www.msnbc.msn.com/id/27324535/ns/technology_and_science-innovation/ >> > > Here is a video of the recent Japanese tsunami from a JCG ship in the the open ocean. The waves (@ ~4:20 and 6:40 into the video) caused them no trouble, but they were certainly not imperceptible. > With the video : http://www.youtube.com/watch?v=4XSBrrueVoQ&feature=player_embedded#at=19 Marshall > Regards > Marshall > >> >> >> At the other extreme, Lituya Bay is a good example of a Mega Tsunami (1,720 feet): >> >> http://en.wikipedia.org/wiki/1958_Lituya_Bay_megatsunami >> >> >> >> >> >> >> >> >> >> >> >> >> > > > From Gavin.Pearce at 3seven9.com Mon Mar 28 12:22:52 2011 From: Gavin.Pearce at 3seven9.com (Gavin Pearce) Date: Mon, 28 Mar 2011 18:22:52 +0100 Subject: New tsunami advisory warning - Japan In-Reply-To: References: <864710.90558.qm@web59612.mail.ac4.yahoo.com> Message-ID: > JCG ship in the the open ocean. Impressive video. The wave height and speed would suggest shallower waters, and that likely the ship was close to land mass when the video was filmed rather than open ocean (in the sense of being far out to sea). Not being there of course I could easily be incorrect. Anyway we digress :) Gav On Mar 28, 2011, at 11:28 AM, Marshall Eubanks wrote: > > On Mar 28, 2011, at 10:57 AM, Gavin Pearce wrote: > >>> You guys forget a lot of folks on the list are working on cabling ships and off shore platforms, its not all about what happens on shore in this industry. >> >> >> >> Valid point ... however in deep ocean, these things are pretty imperceptible. The effect on ships on the surface are nominal, and off shore platforms are (generally) built with these things in mind: http://www.msnbc.msn.com/id/27324535/ns/technology_and_science-innovatio n/ >> > > Here is a video of the recent Japanese tsunami from a JCG ship in the the open ocean. The waves (@ ~4:20 and 6:40 into the video) caused them no trouble, but they were certainly not imperceptible. > With the video : http://www.youtube.com/watch?v=4XSBrrueVoQ&feature=player_embedded#at=19 Marshall > Regards > Marshall > >> >> >> At the other extreme, Lituya Bay is a good example of a Mega Tsunami (1,720 feet): >> >> http://en.wikipedia.org/wiki/1958_Lituya_Bay_megatsunami >> From tshaw at oitc.com Mon Mar 28 12:30:55 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 28 Mar 2011 13:30:55 -0400 Subject: New tsunami advisory warning - Japan In-Reply-To: References: <864710.90558.qm@web59612.mail.ac4.yahoo.com> Message-ID: <43D3306B-7F1E-453C-A7F7-C9E58F6A0CFE@oitc.com> On Mar 28, 2011, at 1:03 PM, Marshall Eubanks wrote: > > On Mar 28, 2011, at 11:28 AM, Marshall Eubanks wrote: > >> >> On Mar 28, 2011, at 10:57 AM, Gavin Pearce wrote: >> >>>> You guys forget a lot of folks on the list are working on cabling ships and off shore platforms, its not all about what happens on shore in this industry. >>> >>> >>> >>> Valid point ... however in deep ocean, these things are pretty imperceptible. The effect on ships on the surface are nominal, and off shore platforms are (generally) built with these things in mind: http://www.msnbc.msn.com/id/27324535/ns/technology_and_science-innovation/ >>> >> >> Here is a video of the recent Japanese tsunami from a JCG ship in the the open ocean. The waves (@ ~4:20 and 6:40 into the video) caused them no trouble, but they were certainly not imperceptible. >> > > With the video : > > http://www.youtube.com/watch?v=4XSBrrueVoQ&feature=player_embedded#at=19 Didn't show much and they were near the epicenter. My friend was on her 44' sailboat about halfway between Galapagos and Easter Island went Chile's earthquake happened which caused a 10' tsunami in the Galapagos. They never noticed a thing. Tom Tom From pete at altadena.net Mon Mar 28 13:26:44 2011 From: pete at altadena.net (Pete Carah) Date: Mon, 28 Mar 2011 14:26:44 -0400 Subject: New tsunami advisory warning - Japan In-Reply-To: References: <864710.90558.qm@web59612.mail.ac4.yahoo.com> Message-ID: <4D90D2E4.6020303@altadena.net> On 03/28/2011 01:22 PM, Gavin Pearce wrote: >> JCG ship in the the open ocean. > Impressive video. The wave height and speed would suggest shallower > waters, and that likely the ship was close to land mass when the video > was filmed rather than open ocean (in the sense of being far out to > sea). Not being there of course I could easily be incorrect. > > Anyway we digress :) > > Gav > > On Mar 28, 2011, at 11:28 AM, Marshall Eubanks wrote: > >> On Mar 28, 2011, at 10:57 AM, Gavin Pearce wrote: >> >>>> You guys forget a lot of folks on the list are working on cabling > ships and off shore platforms, its not all about what happens on shore > in this industry. >>> >>> >>> Valid point ... however in deep ocean, these things are pretty > imperceptible. The effect on ships on the surface are nominal, and off > shore platforms are (generally) built with these things in mind: > http://www.msnbc.msn.com/id/27324535/ns/technology_and_science-innovatio > n/ >> Here is a video of the recent Japanese tsunami from a JCG ship in the > the open ocean. The waves (@ ~4:20 and 6:40 into the video) caused them > no trouble, but they were certainly not imperceptible. > With the video : > > http://www.youtube.com/watch?v=4XSBrrueVoQ&feature=player_embedded#at=19 Thanks for the link... Very impressive, though strong storm waves get higher. This is not an open-ocean tsunami, it is probably either direct from the quake source or reflected from the nearby coast (I'm fairly sure it is the latter, though there isn't a good time reference in the video, since there appears to be land visible in the frame; if the white mass is really land, this definitely does not qualify as open-ocean, which for tsunami purposes has to be an open-ocean wavelength or so from the nearest land or shallow water (600-800 miles; you wouldn't see the land...) Cable damage from tsunamis mostly comes from bulk motion up or down a sloping ocean bottom, or from primary or secondary turbidity currents (basically an underwater avalanche) (unless you are unlucky enough to have the fault break itself cut the cable; this isn't too likely but with this fault geometry it could have happened.) Also, this quake (the 8.9 "main" one, not either the foreshocks or aftershocks, several of each were strong enough to trigger a tsunami watch in Hawaii by themselves) had a very extended energy-release time; the ground motion went for several minutes (see the graph in http://earthquake.usgs.gov/earthquakes/eqinthenews/2011/usc0001xgp/finite_fault.php). That can complicate wave generation a lot. Various mechanisms contribute to tsunami generation; the majority of wave generation in the 1960 Chile event came from landslides secondary to the main earthquake (which was very deep and centered under land...) My memory of papers about the 1964 Alaska quake involved both ground motion and landslides as contributors. Note that in this case, the resulting waves can go different directions from the same quake. Aside: I worked for the U of Hawaii tsunami reasearch program in the 1960's for a while, we were mainly working on very early prototypes of the deep-ocean pressure sensors that are now deployed. Decent embedded microprocessors didn't exist then (for that matter, *any* microprocessors, even the 1802 or 8008, either of which would have been a grand luxury :-( Those finally made these sensors practical. (ours was set up with a write-only 7-track tape drive, using discrete-transistor logic modules (no practical ICs yet either). It was to be placed on Ocean Station November (about 2/3 of the way from San Francisco to Honolulu), kicked overboard on request from the research people (after a "suitable" earthquake), then retrieved using a low-power radio beacon a few days later when the cable release timer tripped.) Modern electronics has improved things :-) -- Pete > Marshall > > >> Regards >> Marshall >> >>> >>> At the other extreme, Lituya Bay is a good example of a Mega Tsunami > (1,720 feet): >>> http://en.wikipedia.org/wiki/1958_Lituya_Bay_megatsunami This one lists landsliding (or perhaps calving) as the generation mechanism, and both the source and the bay outlet were small enough that the wave probably didn't propagate too far once in the open ocean. > > > From paul at paulgraydon.co.uk Mon Mar 28 13:31:57 2011 From: paul at paulgraydon.co.uk (Paul Graydon) Date: Mon, 28 Mar 2011 08:31:57 -1000 Subject: Paul Baran, RIP. In-Reply-To: <14930353.820.1301318058007.JavaMail.root@benjamin.baylink.com> References: <14930353.820.1301318058007.JavaMail.root@benjamin.baylink.com> Message-ID: <4D90D41D.5070907@paulgraydon.co.uk> On 03/28/2011 03:14 AM, Jay Ashworth wrote: > ----- Original Message ----- >> From: "Roland Dobbins" >> > Oh hell; now we'll *never* lay the ghost of "packet switching was > invented to create a nuclear-war-survivable network". > > [ reads obit ] > > See? > > Happy Landings, Dr B. > If it's good enough to use as a source for Wikipedia, who's to tell what is and what isn't factual. From davet1 at gmail.com Mon Mar 28 16:13:53 2011 From: davet1 at gmail.com (Dave Temkin) Date: Mon, 28 Mar 2011 17:13:53 -0400 Subject: Regional AS model In-Reply-To: <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> Message-ID: <4D90FA11.1080802@gmail.com> On 3/27/11 2:53 AM, Patrick W. Gilmore wrote: > On Mar 25, 2011, at 3:33 PM, Owen DeLong wrote: > >>> Single AS worldwide is fine with or without a backbone. >>> >> Only if you want to make use of ugly ugly BGP hacks on your routers, or, you don't care about Site A being >> able to hear announcements from Site B. > You are highly confused. > > Accepting default is not ugly, especially if you don't even have a backbone connecting your sites. And even if we could argue over default's aesthetic qualities (which, honestly, I don't see how we can), there is no rational person who would consider it a hack. > > You really should stop trying to correct the error you made in your first post. Remember the old adage about when you find yourself in a hole. > > Another thing to note is the people who actually run multiple discrete network nodes posting here all said it was fine to use a single AS. One even said the additional overhead of managing multiple ASes would be more trouble than it is worth, and I have to agree with that statement. Put another way, there is objective, empirical evidence that it works. > > In response, you have some nebulous "ugly" comment. I submit your argument is, at best, lacking sufficient definition to be considered useful. > And in reality, is "allowas-in" *that* horrible of a hack? If used properly, I'd say not. In a network where you really are split up regionally with no backbone there's really little downside, especially versus relying on default only. -Dave From owen at delong.com Mon Mar 28 16:40:39 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Mar 2011 14:40:39 -0700 Subject: Regional AS model In-Reply-To: <4D90FA11.1080802@gmail.com> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> <4D90FA11.1080802@gmail.com> Message-ID: <2D72748A-D4FA-4D0F-AA6F-52CB99C6972F@delong.com> On Mar 28, 2011, at 2:13 PM, Dave Temkin wrote: > On 3/27/11 2:53 AM, Patrick W. Gilmore wrote: >> On Mar 25, 2011, at 3:33 PM, Owen DeLong wrote: >> >>>> Single AS worldwide is fine with or without a backbone. >>>> >>> Only if you want to make use of ugly ugly BGP hacks on your routers, or, you don't care about Site A being >>> able to hear announcements from Site B. >> You are highly confused. >> >> Accepting default is not ugly, especially if you don't even have a backbone connecting your sites. And even if we could argue over default's aesthetic qualities (which, honestly, I don't see how we can), there is no rational person who would consider it a hack. >> >> You really should stop trying to correct the error you made in your first post. Remember the old adage about when you find yourself in a hole. >> >> Another thing to note is the people who actually run multiple discrete network nodes posting here all said it was fine to use a single AS. One even said the additional overhead of managing multiple ASes would be more trouble than it is worth, and I have to agree with that statement. Put another way, there is objective, empirical evidence that it works. >> >> In response, you have some nebulous "ugly" comment. I submit your argument is, at best, lacking sufficient definition to be considered useful. >> > And in reality, is "allowas-in" *that* horrible of a hack? If used properly, I'd say not. In a network where you really are split up regionally with no backbone there's really little downside, especially versus relying on default only. > > -Dave I agree that allowas-in is not as bad as default, but, I still think that having one AS per routing policy makes a hell of a lot more sense and there's really not much downside to having an ASN for each independent site. Owen From patrick at ianai.net Mon Mar 28 16:51:41 2011 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 28 Mar 2011 17:51:41 -0400 Subject: Regional AS model In-Reply-To: <2D72748A-D4FA-4D0F-AA6F-52CB99C6972F@delong.com> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> <4D90FA11.1080802@gmail.com> <2D72748A-D4FA-4D0F-AA6F-52CB99C6972F@delong.com> Message-ID: On Mar 28, 2011, at 5:40 PM, Owen DeLong wrote: > On Mar 28, 2011, at 2:13 PM, Dave Temkin wrote: >> On 3/27/11 2:53 AM, Patrick W. Gilmore wrote: >>> On Mar 25, 2011, at 3:33 PM, Owen DeLong wrote: >>> >>>>> Single AS worldwide is fine with or without a backbone. >>>>> >>>> Only if you want to make use of ugly ugly BGP hacks on your routers, or, you don't care about Site A being >>>> able to hear announcements from Site B. >>> You are highly confused. >>> >>> Accepting default is not ugly, especially if you don't even have a backbone connecting your sites. And even if we could argue over default's aesthetic qualities (which, honestly, I don't see how we can), there is no rational person who would consider it a hack. >>> >>> You really should stop trying to correct the error you made in your first post. Remember the old adage about when you find yourself in a hole. >>> >>> Another thing to note is the people who actually run multiple discrete network nodes posting here all said it was fine to use a single AS. One even said the additional overhead of managing multiple ASes would be more trouble than it is worth, and I have to agree with that statement. Put another way, there is objective, empirical evidence that it works. >>> >>> In response, you have some nebulous "ugly" comment. I submit your argument is, at best, lacking sufficient definition to be considered useful. >>> >> And in reality, is "allowas-in" *that* horrible of a hack? If used properly, I'd say not. In a network where you really are split up regionally with no backbone there's really little downside, especially versus relying on default only. >> >> -Dave > > I agree that allowas-in is not as bad as default, but, I still think that having one AS per routing policy makes a hell of a > lot more sense and there's really not much downside to having an ASN for each independent site. I'm glad you ignored Woody and others, who actually runs a multi-site, single-as topology. How many multi-site (non)networks have you run with production traffic? -- TTFN, patrick From mike-nanog at tiedyenetworks.com Mon Mar 28 16:57:37 2011 From: mike-nanog at tiedyenetworks.com (Mike) Date: Mon, 28 Mar 2011 14:57:37 -0700 Subject: iBGP usage on a BRAS Message-ID: <4D910451.7050909@tiedyenetworks.com> Hello, I have a BRAS (Terminating several thousand PPPoE sessions), and today I use simple static routes pointing to the bras for customer routes. I want to improve this model and allow for failover and so forth, and I would like instead for my customer routes to be entered into my igp so if they move around, the routes can follow them. I was wondering if iBGP may be sutaible for this task - there will always be a steady stream of route updates as customer connect and disconnect, mostly in the range of /32's and /29's. BGP seems way superior to ospf for this because of it's excellent filtering and other capabilities, but never having done this on a large scale with the potential for updates as I said, I was hoping someone could make a clear case for or against it. The client routes would not have to be propagated all across my network so updates don't really have to go far; I could certainly summarize these routes easily at a core router 1 hop from my bras for example, with that router(s) knowing the final hop from ibgp. I just want them to be able to float between bras and I can even tolerate a few seconds of route instability (hey, if you want stability then don't keep redialing; nail the pppoe up and leave it up!) Thank you Oh wizend ones (!), Mike- From wschultz at bsdboy.com Mon Mar 28 17:18:30 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Mon, 28 Mar 2011 15:18:30 -0700 Subject: IPv6 SEO implecations? Message-ID: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> I'm attempting to find out information on the SEO implications of testing ipv6 out. A couple of concerns that come to mind are: 1) www.domain.com and ipv6.domain.com are serving the exact same content. Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only. 2) Not running ipv6 natively, or using 6to4. This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times. 3) ??? Any others that I haven't thought of ??? So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process. Thoughts? -wil From jsw at inconcepts.biz Mon Mar 28 17:37:31 2011 From: jsw at inconcepts.biz (Jeff Wheeler) Date: Mon, 28 Mar 2011 18:37:31 -0400 Subject: Regional AS model In-Reply-To: <2D72748A-D4FA-4D0F-AA6F-52CB99C6972F@delong.com> References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> <4D90FA11.1080802@gmail.com> <2D72748A-D4FA-4D0F-AA6F-52CB99C6972F@delong.com> Message-ID: On Mon, Mar 28, 2011 at 5:40 PM, Owen DeLong wrote: > I agree that allowas-in is not as bad as default, but, I still think that having one AS per routing policy makes a hell of a > lot more sense and there's really not much downside to having an ASN for each independent site. Well, let's say I'm a a medium/large transit network like Hurricane Electric, with a few far-flung POPs that have "backup transit." I've got a POP in Miami, Minneapolis, or Toronto which has single points of backbone failure, e.g. one circuit/linecard/etc might go down, while the routers at the POP remain functional, and the routers in the rest of the network remain functional. What happens? 1) with allowas-in your remote POP will still learn your customers' routes by any transit you might have in place there 2) with default route toward transit (breaking uRPF) you would not learn the routes but still be able to reach everything 3) with neither of these solutions, your single-homed customers at the broken POP could not reach single-homed customers elsewhere on your backbone, even if you have "backup transit" in place. I'm not bashing on HE for possibly having a SPOF in backbone connectivity to a remote POP. I'm asking why you don't choose to use a different ASN for these remote POPs. After all, you prefer that solution over allowas-in or default routes. Oh, that's right, sometimes you have a business and/or technical need to operate a single global AS. Vendors have given us the necessary knobs to make this work right. There's nothing wrong with using them, except in your mind. Should every organization with a backbone that has an SPOF grab some more ASNs? No. Should every organization with multiple distinct networks and no backbone use a different ASN per distinct network? IMO the answer is probably yes, but I am not going to say it's always yes. I'll agree with you in a general sense, but if your hard-and-fast rule is that every distinct network should be its own ASN, you had better start thinking about operational failure modes. Alternatively, you could allow for the possibility that allowas-in has plenty of legitimate application. -- Jeff S Wheeler Sr Network Operator? /? Innovative Network Concepts From jeroen at mompl.net Mon Mar 28 17:40:25 2011 From: jeroen at mompl.net (Jeroen van Aart) Date: Mon, 28 Mar 2011 15:40:25 -0700 Subject: New tsunami advisory warning - Japan In-Reply-To: <4D909580.6060101@mtcc.com> References: <68456.56069.qm@web59611.mail.ac4.yahoo.com> <4D909580.6060101@mtcc.com> Message-ID: <4D910E59.9070705@mompl.net> Michael Thomas wrote: > Gavin Pearce wrote: >>> *yawn*. A foot and a half isn't going to be all *that* bad >> >> Sorry to continue off topic: >> >> Try to imagine ... a temporary very high tide, rather than a cresting >> wave. In addition to the "height", it's the wave-length you have to take >> into account. Tsunami's rarely become towering breaking waves. >> > > Quite right. The other part is that the water becomes a very fast moving > river, especially in places where it's not normally one. Watching the I don't underestimate the power of even a small tsunami. I have friends rendered homeless by the Santa Cruz tsunami (their boat being their only home). Though I can understand one is underwhelmed by a mag 6.x earthquake in that region considering I believe more than 20 6+ ones happened there since the first mag 7.2 earthquake that happened 2-3 days before the mag 9 one. Most recent ones: http://earthquake.usgs.gov/earthquakes/recenteqsww/Maps/10/145_40_eqs.php -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From nenolod at systeminplace.net Mon Mar 28 17:47:10 2011 From: nenolod at systeminplace.net (William Pitcock) Date: Mon, 28 Mar 2011 17:47:10 -0500 Subject: IPv6 SEO implecations? In-Reply-To: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> Message-ID: <20110328174710.0b94d736@petrie> On Mon, 28 Mar 2011 15:18:30 -0700 Wil Schultz wrote: > I'm attempting to find out information on the SEO implications of > testing ipv6 out. > > A couple of concerns that come to mind are: > > 1) www.domain.com and ipv6.domain.com are serving the exact same > content. Typical SEO standards are to only serve good content from a > single domain so information isn't watered down and so that the > larger search engines won't penalize. So a big concern is having > search results take a hit because content is duplicated through two > different domains, even though one domain is ipv4 only and the other > is ipv6 only. > > 2) Not running ipv6 natively, or using 6to4. > This (potentially) increases hop count and will put content on a > slower GRE tunnel and add some additional time for page load times. > > 3) ??? Any others that I haven't thought of ??? If you are so concerned about SEO, just dual-stack your site. It works well for me. William From owen at delong.com Mon Mar 28 17:47:35 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Mar 2011 15:47:35 -0700 Subject: Regional AS model In-Reply-To: References: <8B604AC6-01B7-45C7-8DCD-5559758E371B@zaidali.com> <8F562261-1B99-46EC-B4D0-F9665C3DAFD9@ianai.net> <93D0AFA5-A57F-48B3-9F1B-7EDD32D920A3@delong.com> <3F4587C8-3B69-4AD4-931E-51FCC51B79E1@ianai.net> <4D90FA11.1080802@gmail.com> <2D72748A-D4FA-4D0F-AA6F-52CB99C6972F@delong.com> Message-ID: On Mar 28, 2011, at 2:51 PM, Patrick W. Gilmore wrote: > On Mar 28, 2011, at 5:40 PM, Owen DeLong wrote: >> On Mar 28, 2011, at 2:13 PM, Dave Temkin wrote: >>> On 3/27/11 2:53 AM, Patrick W. Gilmore wrote: >>>> On Mar 25, 2011, at 3:33 PM, Owen DeLong wrote: >>>> >>>>>> Single AS worldwide is fine with or without a backbone. >>>>>> >>>>> Only if you want to make use of ugly ugly BGP hacks on your routers, or, you don't care about Site A being >>>>> able to hear announcements from Site B. >>>> You are highly confused. >>>> >>>> Accepting default is not ugly, especially if you don't even have a backbone connecting your sites. And even if we could argue over default's aesthetic qualities (which, honestly, I don't see how we can), there is no rational person who would consider it a hack. >>>> >>>> You really should stop trying to correct the error you made in your first post. Remember the old adage about when you find yourself in a hole. >>>> >>>> Another thing to note is the people who actually run multiple discrete network nodes posting here all said it was fine to use a single AS. One even said the additional overhead of managing multiple ASes would be more trouble than it is worth, and I have to agree with that statement. Put another way, there is objective, empirical evidence that it works. >>>> >>>> In response, you have some nebulous "ugly" comment. I submit your argument is, at best, lacking sufficient definition to be considered useful. >>>> >>> And in reality, is "allowas-in" *that* horrible of a hack? If used properly, I'd say not. In a network where you really are split up regionally with no backbone there's really little downside, especially versus relying on default only. >>> >>> -Dave >> >> I agree that allowas-in is not as bad as default, but, I still think that having one AS per routing policy makes a hell of a >> lot more sense and there's really not much downside to having an ASN for each independent site. > > I'm glad you ignored Woody and others, who actually runs a multi-site, single-as topology. > > How many multi-site (non)networks have you run with production traffic? > Over the years, about a dozen or so. Owen From owen at delong.com Mon Mar 28 17:55:31 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Mar 2011 15:55:31 -0700 Subject: IPv6 SEO implecations? In-Reply-To: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> Message-ID: <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> On Mar 28, 2011, at 3:18 PM, Wil Schultz wrote: > I'm attempting to find out information on the SEO implications of testing ipv6 out. > > A couple of concerns that come to mind are: > > 1) www.domain.com and ipv6.domain.com are serving the exact same content. > Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only. > > 2) Not running ipv6 natively, or using 6to4. > This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times. > > 3) ??? Any others that I haven't thought of ??? > > So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process. > > Thoughts? > > -wil If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo. It's been working just fine for www.he.net for years. Owen From kauer at biplane.com.au Mon Mar 28 18:10:11 2011 From: kauer at biplane.com.au (Karl Auer) Date: Tue, 29 Mar 2011 10:10:11 +1100 Subject: IPv6 SEO implecations? In-Reply-To: <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> Message-ID: <1301353811.2810.78.camel@karl> On Mon, 2011-03-28 at 15:55 -0700, Owen DeLong wrote: > If you're worried about SEO, go with native IPv6 and then deploy AAAAs > for WWW.domain.foo. Why is native IPv6 needed? I'd have thought a tunnel would be fine, too. 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: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687 Old fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part URL: From nathan at atlasnetworks.us Mon Mar 28 18:17:28 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 28 Mar 2011 23:17:28 +0000 Subject: IPv6 SEO implecations? In-Reply-To: <1301353811.2810.78.camel@karl> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> <1301353811.2810.78.camel@karl> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3F1E65@ex-mb-1.corp.atlasnetworks.us> > Why is native IPv6 needed? I'd have thought a tunnel would be fine, too. I believe the concern is that the higher latency of a tunnel would impact SEO rankings. From tshaw at oitc.com Mon Mar 28 18:20:51 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 28 Mar 2011 19:20:51 -0400 Subject: IPv6 SEO implecations? In-Reply-To: <1301353811.2810.78.camel@karl> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> <1301353811.2810.78.camel@karl> Message-ID: On Mar 28, 2011, at 7:10 PM, Karl Auer wrote: > On Mon, 2011-03-28 at 15:55 -0700, Owen DeLong wrote: >> If you're worried about SEO, go with native IPv6 and then deploy AAAAs >> for WWW.domain.foo. > > Why is native IPv6 needed? I'd have thought a tunnel would be fine, too. So why does www A 127.0.0.1 www AAAA ::1 Preclude a tunnel? I can't get native here to my IPv6 is tunneled thru he (Thanks he) but that doesn't change dual DNS entires. (Note used loopback as an example) Tom From tshaw at oitc.com Mon Mar 28 18:21:43 2011 From: tshaw at oitc.com (TR Shaw) Date: Mon, 28 Mar 2011 19:21:43 -0400 Subject: IPv6 SEO implecations? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3F1E65@ex-mb-1.corp.atlasnetworks.us> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> <1301353811.2810.78.camel@karl> <8C26A4FDAE599041A13EB499117D3C286B3F1E65@ex-mb-1.corp.atlasnetworks.us> Message-ID: <09DEC7B0-64EA-40E4-9973-257E17DE6FE2@oitc.com> On Mar 28, 2011, at 7:17 PM, Nathan Eisenberg wrote: >> Why is native IPv6 needed? I'd have thought a tunnel would be fine, too. > > I believe the concern is that the higher latency of a tunnel would impact SEO rankings. True but you live with what you can get acces to ;-) Tom From wschultz at bsdboy.com Mon Mar 28 18:21:48 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Mon, 28 Mar 2011 16:21:48 -0700 Subject: IPv6 SEO implecations? In-Reply-To: <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> Message-ID: <2C5B138E-480E-4B3A-A5A8-7715625B459B@bsdboy.com> On Mar 28, 2011, at 3:55 PM, Owen DeLong wrote: > > On Mar 28, 2011, at 3:18 PM, Wil Schultz wrote: > >> I'm attempting to find out information on the SEO implications of testing ipv6 out. >> >> A couple of concerns that come to mind are: >> >> 1) www.domain.com and ipv6.domain.com are serving the exact same content. >> Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only. >> >> 2) Not running ipv6 natively, or using 6to4. >> This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times. >> >> 3) ??? Any others that I haven't thought of ??? >> >> So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process. >> >> Thoughts? >> >> -wil > > If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo. > > It's been working just fine for www.he.net for years. > > Owen > So far the consensus is to run dual stack natively. While this definitely is the way things should be set up in the end, I can see some valid reasons to run ipv4 and ipv6 on separate domains for a while before final configuration. For example, if I'm in an area with poor ipv6 connectivity I'd like to be given the option of explicitly going to an ipv4 site vs the ipv6 version. I'd also like to not damage SEO in the process though. ;-) -wil From nicholas at udhaonline.net Mon Mar 28 18:37:47 2011 From: nicholas at udhaonline.net (Nicholas Meredith) Date: Tue, 29 Mar 2011 09:37:47 +1000 Subject: IPv6 SEO implecations? In-Reply-To: <2C5B138E-480E-4B3A-A5A8-7715625B459B@bsdboy.com> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> <2C5B138E-480E-4B3A-A5A8-7715625B459B@bsdboy.com> Message-ID: <-8656793349984297784@unknownmsgid> I would be getting ipv6 connectivity, adding an unknown AAAA record such as ipv6 or www6; but not www, and do as many comparative ipv4 vs ipv6 tracerouts from as many route servers as possible. Then you will have the data you need to actually make an informed decision rather than just guessing how it will behave. Remove the temp record and add a real quad for www only if you liked what you saw. I assume the name servers are also available over ipv6 including glue? \n On 29/03/2011, at 9:25, Wil Schultz wrote: > On Mar 28, 2011, at 3:55 PM, Owen DeLong wrote: > >> >> On Mar 28, 2011, at 3:18 PM, Wil Schultz wrote: >> >>> I'm attempting to find out information on the SEO implications of testing ipv6 out. >>> >>> A couple of concerns that come to mind are: >>> >>> 1) www.domain.com and ipv6.domain.com are serving the exact same content. >>> Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only. >>> >>> 2) Not running ipv6 natively, or using 6to4. >>> This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times. >>> >>> 3) ??? Any others that I haven't thought of ??? >>> >>> So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process. >>> >>> Thoughts? >>> >>> -wil >> >> If you're worried about SEO, go with native IPv6 and then deploy AAAAs for WWW.domain.foo. >> >> It's been working just fine for www.he.net for years. >> >> Owen >> > > So far the consensus is to run dual stack natively. > > While this definitely is the way things should be set up in the end, I can see some valid reasons to run ipv4 and ipv6 on separate domains for a while before final configuration. For example, if I'm in an area with poor ipv6 connectivity I'd like to be given the option of explicitly going to an ipv4 site vs the ipv6 version. > > I'd also like to not damage SEO in the process though. ;-) > > -wil From Crist.Clark at globalstar.com Mon Mar 28 18:47:26 2011 From: Crist.Clark at globalstar.com (Crist Clark) Date: Mon, 28 Mar 2011 16:47:26 -0700 Subject: The state-level attack on the SSL CA security model In-Reply-To: <82r59va73h.fsf@mid.bfk.de> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <8239mchkc5.fsf@mid.bfk.de> <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net><67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> (Roland Dobbins's message of "Thu\, 24 Mar 2011 21\:33\:27 +0000") <82r59va73h.fsf@mid.bfk.de> Message-ID: <4D90BB97.33E4.0097.1@globalstar.com> >>> On 3/25/2011 at 2:21 AM, Florian Weimer wrote: > * Roland Dobbins: > >> On Mar 24, 2011, at 6:41 PM, Florian Weimer wrote: >> >>> Disclosure devalues information. > >> I think this case is different, given the perception of the cert as >> a 'thing' to be bartered. > > Private keys have been traded openly for years. For instance, when > your browser tells you that a web site has been verified by "Equifax" > (exact phrasing in the UI may vary), it's just not true. Equifax has > sold its private key to someone else long ago, and chances are that > the key material has changed hands a couple of times since. > > I can't see how a practice that is completely acceptable at the root > certificate level is a danger so significant that state-secret-like > treatment is called for once end-user certificates are involved. Any large, well funded national-level intelligence agency almost certainly has keys to a valid CA distributed with any browser or SSL package. It would be trivial for the US Gov't (and by extension, the whole AUSCANNZUKUS intelligence community) to simply form a shell company CA that could get a trusted cert in the distros or enlist a "legit" CA to do their patriotic duty (along with some $$$) and give up a key. Heck, it's so easy, private industry sells this as a product for the law enforcement community. It's an easy recipe, 1) Go start your own CA (or buying an existing one may be easier, as Florian points out). 2) Get your key put in Windows, Firefox, Opera, etc. 3) Build an appliance that uses your key to do MIM attacks on the fly. 4) Sell appliance to law enforcement (or anyone else with the money, maybe a smaller nation's intelligence apparatus?). 5) Profit! Just Google around for commercial products aimed at LI that have this capability. Commercial SSL/TLS, i.e. using built-in CAs, offers no protection against nation-states at the intelligence or law enforcement level. -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 From nathan at atlasnetworks.us Mon Mar 28 18:49:52 2011 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 28 Mar 2011 23:49:52 +0000 Subject: IPv6 SEO implecations? In-Reply-To: <-8656793349984297784@unknownmsgid> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> <2C5B138E-480E-4B3A-A5A8-7715625B459B@bsdboy.com> <-8656793349984297784@unknownmsgid> Message-ID: <8C26A4FDAE599041A13EB499117D3C286B3F1F41@ex-mb-1.corp.atlasnetworks.us> > I would be getting ipv6 connectivity, adding an unknown AAAA record such as > ipv6 or www6; but not www, and do as many comparative ipv4 vs > ipv6 tracerouts from as many route servers as possible. Then you will have the > data you need to actually make an informed decision rather than just guessing > how it will behave. Remove the temp record and add a real quad for www > only if you liked what you saw. > > I assume the name servers are also available over ipv6 including glue? Why do you even need a AAAA record to do that? Just do a traceroute to the v6 address. The temporary AAAA record seems to do nothing useful in your proposed procedure. Easiest hack to test site usability: Modify your hosts file. Don't even publish the record in DNS until you're ready. Then there's no SEO implications. :) > So far the consensus is to run dual stack natively. > > While this definitely is the way things should be set up in the end, I can see > some valid reasons to run ipv4 and ipv6 on separate domains for a while > before final configuration. For example, if I'm in an area with poor ipv6 > connectivity I'd like to be given the option of explicitly going to an ipv4 site vs > the ipv6 version. > > I'd also like to not damage SEO in the process though. ;-) If you're going to expose the site via a separate hostname (v6.bobdole.com), create a v6.robots.txt file that tells Google not to index v6.bobdole.com. Use an .htaccess rule to rewrite requests for robots.txt based on the host header, so v4 requests get the v4.robots.txt, and v6 requests get the v6.robots.txt, which tells Google not to index things. Nathan From nicholas at udhaonline.net Mon Mar 28 19:01:10 2011 From: nicholas at udhaonline.net (Nicholas Meredith) Date: Tue, 29 Mar 2011 10:01:10 +1000 Subject: IPv6 SEO implecations? In-Reply-To: <8C26A4FDAE599041A13EB499117D3C286B3F1F41@ex-mb-1.corp.atlasnetworks.us> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> <2C5B138E-480E-4B3A-A5A8-7715625B459B@bsdboy.com> <-8656793349984297784@unknownmsgid> <8C26A4FDAE599041A13EB499117D3C286B3F1F41@ex-mb-1.corp.atlasnetworks.us> Message-ID: > Why do you even need a AAAA record to do that? Just do a traceroute to the > v6 address. The temporary AAAA record seems to do nothing useful in your > proposed procedure. > > Easiest hack to test site usability: Modify your hosts file. Don't even > publish the record in DNS until you're ready. Then there's no SEO > implications. :) > You could go direct to the v6 addy, but using your hosts file for a dns record isn't going to work for the remote route servers I suggest testing from. Using a temp AAAA doesn't hurt, or lose you anything, and is technically a more accurate test, ultimatly I leave it to your discretion. \n From owen at delong.com Mon Mar 28 20:07:47 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Mar 2011 18:07:47 -0700 Subject: IPv6 SEO implecations? In-Reply-To: <1301353811.2810.78.camel@karl> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> <1301353811.2810.78.camel@karl> Message-ID: <4BDA382C-6EBF-4522-B738-CABF08DD126A@delong.com> On Mar 28, 2011, at 4:10 PM, Karl Auer wrote: > On Mon, 2011-03-28 at 15:55 -0700, Owen DeLong wrote: >> If you're worried about SEO, go with native IPv6 and then deploy AAAAs >> for WWW.domain.foo. > > Why is native IPv6 needed? I'd have thought a tunnel would be fine, too. > He was worried about the latency of tunnels creating penalties for SEO purposes, but, otherwise, yes, that works too. Since he stated a desire to avoid tunnels as an initial area of concern, I went with his original statement. Owen From owen at delong.com Mon Mar 28 20:09:28 2011 From: owen at delong.com (Owen DeLong) Date: Mon, 28 Mar 2011 18:09:28 -0700 Subject: IPv6 SEO implecations? In-Reply-To: References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> <1301353811.2810.78.camel@karl> Message-ID: <5EF891FE-9046-4AC0-AD18-CE3061E49981@delong.com> On Mar 28, 2011, at 4:20 PM, TR Shaw wrote: > > On Mar 28, 2011, at 7:10 PM, Karl Auer wrote: > >> On Mon, 2011-03-28 at 15:55 -0700, Owen DeLong wrote: >>> If you're worried about SEO, go with native IPv6 and then deploy AAAAs >>> for WWW.domain.foo. >> >> Why is native IPv6 needed? I'd have thought a tunnel would be fine, too. > > So why does > > www A 127.0.0.1 > www AAAA ::1 > > Preclude a tunnel? I can't get native here to my IPv6 is tunneled thru he (Thanks he) but that doesn't change dual DNS entires. > > (Note used loopback as an example) > > Tom > Well, hard to tunnel to a loopback address, but, using a better example: www IN A 192.0.2.50 IN AAAA 2001:db8::2:50 Would not preclude a tunnel at all. The issue is that he seemed concerned with additional latency from a tunnel resulting in SEO penalties, so, I suggested native as a resolution to that concern. Owen From bicknell at ufp.org Mon Mar 28 20:50:33 2011 From: bicknell at ufp.org (Leo Bicknell) Date: Mon, 28 Mar 2011 18:50:33 -0700 Subject: IPv6 SEO implecations? In-Reply-To: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> Message-ID: <20110329015033.GA8085@ussenterprise.ufp.org> In a message written on Mon, Mar 28, 2011 at 03:18:30PM -0700, Wil Schultz wrote: > I'm attempting to find out information on the SEO implications of testing ipv6 out. I don't run a web site where SEO is a top priority, so I don't track such things. Quite simply, who's crawling on IPv6? That is, will any of the search engines even notice? -- 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 ryan at u13.net Mon Mar 28 21:07:10 2011 From: ryan at u13.net (Ryan Rawdon) Date: Mon, 28 Mar 2011 22:07:10 -0400 Subject: IPv6 SEO implecations? In-Reply-To: <20110329015033.GA8085@ussenterprise.ufp.org> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <20110329015033.GA8085@ussenterprise.ufp.org> Message-ID: <63FEFCFB-5254-4D3D-9DF7-524B2302E23B@u13.net> On Mar 28, 2011, at 9:50 PM, Leo Bicknell wrote: > In a message written on Mon, Mar 28, 2011 at 03:18:30PM -0700, Wil Schultz wrote: >> I'm attempting to find out information on the SEO implications of testing ipv6 out. > > I don't run a web site where SEO is a top priority, so I don't track > such things. > > Quite simply, who's crawling on IPv6? That is, will any of the > search engines even notice? > > -- > Leo Bicknell - bicknell at ufp.org - CCIE 3440 > PGP keys at http://www.ufp.org/~bicknell/ The only crawling I have seen over IPv6 has come from Google - but I have only seen that on IPv6-only sites, not dual-stack sites: 2001:4860:4801:1302:0:6006:1300:b075 - - [28/Mar/2011:21:54:12 -0400] "GET /p/OWJjZD HTTP/1.1" 200 3790 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" From mysidia at gmail.com Mon Mar 28 21:22:43 2011 From: mysidia at gmail.com (Jimmy Hess) Date: Mon, 28 Mar 2011 21:22:43 -0500 Subject: IPv6 SEO implecations? In-Reply-To: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> Message-ID: On Mon, Mar 28, 2011 at 5:18 PM, Wil Schultz wrote: > I'm attempting to find out information on the SEO implications of testing ipv6 out. > A couple of concerns that come to mind are: > 1) www.domain.com and ipv6.domain.com are serving the exact same content. > Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only. The real name for SEO is Search-Engine manipulation. And the moment you indicate "typical SEO standards", the search engine developers have likely already become aware of the existence of the problem/tactic and fiddled with knobs plenty of times since then.... Sometimes search engines penalize what they see to be duplicate content in the indexes. Spammers sometimes try to include the same content in many domains or steal content from other sites to enhance page rank. Big search engines offer some method of canonicalization or selection of a preferred domain through sitemaps. Use the tools provided by your search engine to tell them ipv6.domain.com is just domain.com. If IPv4 and IPv6 are combined in one index, there is a risk that the IPv4 pages could get penalized and only the IPv6 pages show at the top (or vice-versa). You could use robots.txt to block access to one of the sites for just the robots that penalized or a rel=nofollow. If even necessary... I for one am completely unconvinced that major search engines are penalizing in this scenario currently, solely because a site was duplicated to a "ipv6" subdomain. Keep in mind there is a search engine using this practice for their own domain. Who knows... in the future they may be penalizing sites that _don't_ have an IPv6 subdomain or v6 dual-stacking (assuming they are not penalizing that / rewarding IPv6 connected sites already). In this case attempting to put old SEO tactics first may hurt visitor experience more than help. ipv6.domain.com available over IPv6 and domain.com available over IPv4 are not really "different" domains; I expect search engines may keep IPv4 and IPv6 indexes separate. At least for a time... since there are IPv4-only nodes who would not be able to access IPv6 hyperlinks in a search results page. -- -JH From tim.connolly at farecompare.com Mon Mar 28 21:31:48 2011 From: tim.connolly at farecompare.com (Tim Connolly) Date: Mon, 28 Mar 2011 21:31:48 -0500 Subject: Anyone have info on the Dallas Infomart power outage? Message-ID: <17F1B437-1C3A-410D-883F-93E407E43CFC@farecompare.com> Anyone have details? From jtk at cymru.com Mon Mar 28 22:08:20 2011 From: jtk at cymru.com (John Kristoff) Date: Mon, 28 Mar 2011 22:08:20 -0500 Subject: Paul Baran, RIP. In-Reply-To: <14930353.820.1301318058007.JavaMail.root@benjamin.baylink.com> References: <14930353.820.1301318058007.JavaMail.root@benjamin.baylink.com> Message-ID: <20110328220820.378e546c@t61p> On Mon, 28 Mar 2011 09:14:18 -0400 (EDT) Jay Ashworth wrote: > Oh hell; now we'll *never* lay the ghost of "packet switching was > invented to create a nuclear-war-survivable network". Maybe you're confusing the invention of packet switching with the creation of the ARPANET? Survivability, particular to "enemy attack", was a prime motivator for Baran's original ideas as published in he IEEE Transactions of Communications 1964 paper. ARPANET's motivation was apparently very different. The Network World article looks to be factually accurate to me. Looks like this was used as a primary source for the article: John From fred at cisco.com Tue Mar 29 00:40:27 2011 From: fred at cisco.com (Fred Baker) Date: Tue, 29 Mar 2011 07:40:27 +0200 Subject: IPv6 SEO implecations? In-Reply-To: <2C5B138E-480E-4B3A-A5A8-7715625B459B@bsdboy.com> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> <1EEAC599-1156-490C-B597-241FE84CAE4A@delong.com> <2C5B138E-480E-4B3A-A5A8-7715625B459B@bsdboy.com> Message-ID: <5B74A3E5-B9B4-4ACC-A33E-0BBEAD0A907E@cisco.com> On Mar 29, 2011, at 1:21 AM, Wil Schultz wrote: > So far the consensus is to run dual stack natively. > > While this definitely is the way things should be set up in the end, I can see some valid reasons to run ipv4 and ipv6 on separate domains for a while before final configuration. For example, if I'm in an area with poor ipv6 connectivity I'd like to be given the option of explicitly going to an ipv4 site vs the ipv6 version. > > I'd also like to not damage SEO in the process though. ;-) There has been a discussion of this in v6ops, around http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications "IPv6 AAAA DNS Whitelisting Implications", Jason Livingood, 22-Feb-11 and http://tools.ietf.org/html/draft-ietf-v6ops-happy-eyeballs "Happy Eyeballs: Trending Towards Success with Dual-Stack Hosts", Dan Wing, Andrew Yourtchenko, 14-Mar-11 In that context, you might review http://www.ietf.org/proceedings/80/slides/v6ops-12.pdf Where you find a name ipv6.example.com, such as ipv6.google.com and www.v6.facebook.com, it is generally a place where the service is testing the IPv6 configuration prior to listing both the A and the AAAA record under the same name. The up side of giving them the same name is that the same content is viewable using IPv4 and IPv6; being IP-agnostic is a good thing. Unfortunately, at least right now, there is a side-effect. The side-effect is that a temporary network problem (routing loop etc) on one technology can be fixed by using the other, and the browsers don't necessarily fall back as one would wish. This works negatively against IPv6 deployment and customer satisfaction; it is not unusual for tech support people to respond to such questions with "turn off IPv6 and you won't have that problem". Hence, content providers often separate the names to ensure that people only get the IPv6 experience if they expect it. And Google among others whitelists people for IPv6 DNS service based on their measurements of the client's path to google - if a bad experience is likely, they try to prevent it by not offering IPv6 names. In general, I don't see a lot of difference between A and AAAA accesses, but I have had glitches when there was a network glitch. On one occasion, there was an IPv6 routing loop en route to www.ietf.org, but not one on the IPv4 path. The net result was a huge delay - it took nearly two minutes to download a page. The amusing part of that was that the same routing loop got in the way of reporting the issue to HE; I wound up sending an email rather than filing a case. Once it was fixed, matters returned to normal. From fweimer at bfk.de Tue Mar 29 02:30:15 2011 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 29 Mar 2011 07:30:15 +0000 Subject: The state-level attack on the SSL CA security model In-Reply-To: <4D90BB97.33E4.0097.1@globalstar.com> (Crist Clark's message of "Mon\, 28 Mar 2011 16\:47\:26 -0700") References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <8239mchkc5.fsf@mid.bfk.de> <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> <82r59va73h.fsf@mid.bfk.de> <4D90BB97.33E4.0097.1@globalstar.com> Message-ID: <82bp0u1j08.fsf@mid.bfk.de> * Crist Clark: > Any large, well funded national-level intelligence agency > almost certainly has keys to a valid CA distributed with > any browser or SSL package. It would be trivial for the US > Gov't (and by extension, the whole AUSCANNZUKUS intelligence > community) to simply form a shell company CA that could get > a trusted cert in the distros or enlist a "legit" CA to do > their patriotic duty (along with some $$$) and give up a key. I think this is far too complicated. You just add your state PKI to the browsers, and the CPS does not require any checks on the Common Name, to verify it's actually somehow controlled by the certificate holder. Curiously, such CAs can pass Webtrust audits. Now I'm a realist and assume that the bureaucrats involved are just too incompetent to write a proper CPS (and the auditors to lazy to notice). Authoring policies and paying attention to detail, should be second nature to them, but somehow I doubt that the FPKI (say) issues certificates for non-federal entities to help with ongoing FBI investigations. (Same for the German government agencies who actually managed to get Mozilla approval for their non-CN-checking CAs.) -- 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 fmartin at linkedin.com Tue Mar 29 05:51:37 2011 From: fmartin at linkedin.com (Franck Martin) Date: Tue, 29 Mar 2011 10:51:37 +0000 Subject: IPv6 SEO implecations? In-Reply-To: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> Message-ID: On 3/29/11 10:18 , "Wil Schultz" wrote: >I'm attempting to find out information on the SEO implications of testing >ipv6 out. > > >3) ??? Any others that I haven't thought of ??? > >So basically I'd love to set up some sites for ipv6.domain.com via 6to4 >as a phase one, and at some point in the near future implement ipv6 >natively inside the datacenter, but I'm somewhat concerned about damaging >SEO reputation in the process. > >Thoughts? > Do we know which spiders run on IPv6? After all an IPv6 only site may not be indexed at all... From joe at gonetforward.com Tue Mar 29 05:52:02 2011 From: joe at gonetforward.com (Joe Renwick) Date: Tue, 29 Mar 2011 03:52:02 -0700 Subject: What is this Cisco process? Message-ID: Hello, Have a Cisco 3560 running "flash:/c3560-ipbasek9-mz.122-55.SE1.bin". Been running at 20% CPU since we started it: [image: plf-access - CPU Usage] The switch is completely layer-2... basic configuration. CPU utilization is soley based on a single process: plf-access#sh proc cpu sorted CPU utilization for five seconds: 27%/0%; one minute: 25%; five minutes: 24% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 41 232891470 1072247 217210 20.12% 18.99% 18.01% 0 SFF8472 78 2376721 123621 19225 0.95% 0.22% 0.17% 0 HULC Tcam Memory 303 299 163 1834 0.47% 0.23% 0.07% 2 SSH Process 55 106535 11303527 9 0.15% 0.02% 0.00% 0 RedEarth Tx Mana Anybody have a clue what this process is? Thanks for the time. Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From leigh.porter at ukbroadband.com Tue Mar 29 05:59:21 2011 From: leigh.porter at ukbroadband.com (Leigh Porter) Date: Tue, 29 Mar 2011 11:59:21 +0100 Subject: What is this Cisco process? In-Reply-To: References: Message-ID: You mean the RedEarth process? RedEarth Tx Mana: Microprocessor communication process From: http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/troub leshooting/cpu_util.html -- Leigh Porter UK Broadband -----Original Message----- From: Joe Renwick [mailto:joe at gonetforward.com] Sent: 29 March 2011 11:52 To: nanog at nanog.org Subject: What is this Cisco process? Hello, Have a Cisco 3560 running "flash:/c3560-ipbasek9-mz.122-55.SE1.bin". Been running at 20% CPU since we started it: [image: plf-access - CPU Usage] The switch is completely layer-2... basic configuration. CPU utilization is soley based on a single process: plf-access#sh proc cpu sorted CPU utilization for five seconds: 27%/0%; one minute: 25%; five minutes: 24% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 41 232891470 1072247 217210 20.12% 18.99% 18.01% 0 SFF8472 78 2376721 123621 19225 0.95% 0.22% 0.17% 0 HULC Tcam Memory 303 299 163 1834 0.47% 0.23% 0.07% 2 SSH Process 55 106535 11303527 9 0.15% 0.02% 0.00% 0 RedEarth Tx Mana Anybody have a clue what this process is? Thanks for the time. Cheers, -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ From tom at ninjabadger.net Tue Mar 29 06:24:03 2011 From: tom at ninjabadger.net (Tom Hill) Date: Tue, 29 Mar 2011 12:24:03 +0100 Subject: What is this Cisco process? In-Reply-To: References: Message-ID: <1301397843.1834.5.camel@teh-desktop> Hi Joe, On Tue, 2011-03-29 at 03:52 -0700, Joe Renwick wrote: > plf-access#sh proc cpu sorted > CPU utilization for five seconds: 27%/0%; one minute: 25%; five minutes: 24% > PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process > 41 232891470 1072247 217210 20.12% 18.99% 18.01% 0 SFF8472 SFF8472 is very familiar: http://en.wikipedia.org/wiki/Small_form-factor_pluggable_transceiver#Digital_Diagnostics_Monitoring I believe that might help explain a little. I also found reference to it buried in a PDF: http://bit.ly/fZZcVp So you may have some incompatible SFP there. HTH Tom From james at pixelix.co.uk Tue Mar 29 06:19:33 2011 From: james at pixelix.co.uk (James Sheridan) Date: Tue, 29 Mar 2011 12:19:33 +0100 Subject: What is this Cisco =?UTF-8?Q?process=3F?= In-Reply-To: References: Message-ID: <1d2454253bc352229543e19718d9e8f4@mail.herm.it> On Tue, 29 Mar 2011 11:59:21 +0100, "Leigh Porter" wrote: > You mean the RedEarth process? I suspect he meant the SFF8472 process, using 20% of CPU... > plf-access#sh proc cpu sorted > CPU utilization for five seconds: 27%/0%; one minute: 25%; five minutes: > 24% > PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process > 41 232891470 1072247 217210 20.12% 18.99% 18.01% 0 SFF8472 SFF-8472 is the standard for monitoring mini-GBIC/SFP modules - perhaps he has a 'bad' module in this router that's going haywire? -- James. From ido at oasis-tech.net Tue Mar 29 07:08:39 2011 From: ido at oasis-tech.net (Ido Szargel) Date: Tue, 29 Mar 2011 14:08:39 +0200 Subject: iBGP usage on a BRAS In-Reply-To: <4D910451.7050909@tiedyenetworks.com> References: <4D910451.7050909@tiedyenetworks.com> Message-ID: <7A848D4888ADA94B8A46A17296740133713F98AEA4@DEXTER.oasis-tech.local> Hi Mike, iBGP is what most ISPs would use for that, for customers with dynamic IPs simply aggregate their addresses on the BRAS, if you have several thousand IPs you really don't want them in your IGP Regards, Ido. -----Original Message----- From: Mike [mailto:mike-nanog at tiedyenetworks.com] Sent: Monday, March 28, 2011 11:58 PM To: NANOG list Subject: iBGP usage on a BRAS Hello, I have a BRAS (Terminating several thousand PPPoE sessions), and today I use simple static routes pointing to the bras for customer routes. I want to improve this model and allow for failover and so forth, and I would like instead for my customer routes to be entered into my igp so if they move around, the routes can follow them. I was wondering if iBGP may be sutaible for this task - there will always be a steady stream of route updates as customer connect and disconnect, mostly in the range of /32's and /29's. BGP seems way superior to ospf for this because of it's excellent filtering and other capabilities, but never having done this on a large scale with the potential for updates as I said, I was hoping someone could make a clear case for or against it. The client routes would not have to be propagated all across my network so updates don't really have to go far; I could certainly summarize these routes easily at a core router 1 hop from my bras for example, with that router(s) knowing the final hop from ibgp. I just want them to be able to float between bras and I can even tolerate a few seconds of route instability (hey, if you want stability then don't keep redialing; nail the pppoe up and leave it up!) Thank you Oh wizend ones (!), Mike- From zhuifeng0426 at gmail.com Tue Mar 29 07:27:09 2011 From: zhuifeng0426 at gmail.com (yifeng zhou) Date: Tue, 29 Mar 2011 15:27:09 +0300 Subject: XGMII interface Message-ID: Dears: As in IEEE 802.3 clause 46, in 10G Ethernet, RS and PCS may use XGMII interface to inter-connect. XGMII interface is a 32-bit wide, transmit & receive data path, working on frequency of 156.25HZ. So, for transmit direction, the total transmit rate should be 32*156.25=5Gbps, how 10G works with this interface? Further, on PMA, the transmit rate become 312.5M characters per lane.. how done this number come? thanks! From joelja at bogus.com Tue Mar 29 07:36:09 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 29 Mar 2011 05:36:09 -0700 Subject: XGMII interface In-Reply-To: References: Message-ID: <4D91D239.8010303@bogus.com> check your xgmii specs... it's ddr so there is a bit on both clock rise and fall. http://en.wikipedia.org/wiki/10_Gigabit_Media_Independent_Interface On 3/29/11 5:27 AM, yifeng zhou wrote: > Dears: > > As in IEEE 802.3 clause 46, in 10G Ethernet, RS and PCS may use XGMII > interface to inter-connect. > > XGMII interface is a 32-bit wide, transmit & receive data path, working on > frequency of 156.25HZ. So, for transmit direction, the total transmit rate > should be 32*156.25=5Gbps, how 10G works with this interface? > > Further, on PMA, the transmit rate become 312.5M characters per lane.. how > done this number come? > > thanks! > From zhuifeng0426 at gmail.com Tue Mar 29 07:52:28 2011 From: zhuifeng0426 at gmail.com (yifeng zhou) Date: Tue, 29 Mar 2011 15:52:28 +0300 Subject: XGMII interface In-Reply-To: <4D91D239.8010303@bogus.com> References: <4D91D239.8010303@bogus.com> Message-ID: Thanks Joel. Now i can understand :) 2011/3/29 Joel Jaeggli > check your xgmii specs... > > it's ddr so there is a bit on both clock rise and fall. > > http://en.wikipedia.org/wiki/10_Gigabit_Media_Independent_Interface > > On 3/29/11 5:27 AM, yifeng zhou wrote: > > Dears: > > > > As in IEEE 802.3 clause 46, in 10G Ethernet, RS and PCS may use XGMII > > interface to inter-connect. > > > > XGMII interface is a 32-bit wide, transmit & receive data path, working > on > > frequency of 156.25HZ. So, for transmit direction, the total transmit > rate > > should be 32*156.25=5Gbps, how 10G works with this interface? > > > > Further, on PMA, the transmit rate become 312.5M characters per lane.. > how > > done this number come? > > > > thanks! > > > > From jra at baylink.com Tue Mar 29 08:18:58 2011 From: jra at baylink.com (Jay Ashworth) Date: Tue, 29 Mar 2011 09:18:58 -0400 (EDT) Subject: Paul Baran, RIP. In-Reply-To: <20110328220820.378e546c@t61p> Message-ID: <28385642.1280.1301404738855.JavaMail.root@benjamin.baylink.com> ----- Original Message ----- > From: "John Kristoff" > On Mon, 28 Mar 2011 09:14:18 -0400 (EDT) > Jay Ashworth wrote: > > Oh hell; now we'll *never* lay the ghost of "packet switching was > > invented to create a nuclear-war-survivable network". > > Maybe you're confusing the invention of packet switching with the > creation of the ARPANET? In fact, I probably was. Sorry for the allegedly humorous noise. Cheers, -- jra From rmacharia at gmail.com Tue Mar 29 08:23:11 2011 From: rmacharia at gmail.com (Raymond Macharia) Date: Tue, 29 Mar 2011 16:23:11 +0300 Subject: IPv4 address shortage? Really? In-Reply-To: <4D759138.7080002@jima.tk> References: <1299498200.29652.40.camel@kotti.kotovnik.com> <4D759138.7080002@jima.tk> Message-ID: "misguided idea of someone who's way too invested in IPv4 and hasn't made any necessary plans or steps to implement IPv6" Lack of planning or good business? http://www.bbc.co.uk/news/technology-12859585 Raymond Macharia On Tue, Mar 8, 2011 at 5:15 AM, Jima wrote: > On 3/7/2011 5:43 AM, Vadim Antonov wrote: > >> I'm wondering (and that shows that I have nothing better to do at 3:30am >> on Monday...) how many people around here realize that the plain old >> IPv4 - as widely implemented and specified in standard RFCs can be >> easily used to connect pretty much arbitrary number (arbitrary means >> >>> 2^256) of computers WITHOUT NETWORK ADDRESS TRANSLATION. Yes, you hear >>> >> me right. >> > > This seems like either truly bizarre trolling, or the misguided idea of > someone who's way too invested in IPv4 and hasn't made any necessary plans > or steps to implement IPv6. To implement this -- which, to begin with, > seems like a bad idea to me (and judging by Mr. Andrews' response, others) > -- you'd have to overhaul software on many, many computers, routers, and > other devices. (Wait, why does this sound familiar?) Of course, the > groundwork would need to be laid out and discussed, which will probably cost > us a few years...too bad we don't have a plan that could be put into action > sooner, or maybe even was already deployed. > > Anyway, the needless ROT13 text fairly well convinced me that our messages > may be traveling over an ethernet bridge. > > Jima > " From rmacharia at gmail.com Tue Mar 29 08:35:18 2011 From: rmacharia at gmail.com (Raymond Macharia) Date: Tue, 29 Mar 2011 16:35:18 +0300 Subject: Paul Baran, RIP. In-Reply-To: References: Message-ID: it goes to show that the greatest and I must add unsung heroes have the greatest impact on our lives even when we do not know it. Regards Raymond Macharia On Mon, Mar 28, 2011 at 6:44 AM, Dobbins, Roland wrote: > > < > http://www.networkworld.com/news/2011/032811-paul-baran-packet-switching-obit.html > > > > ----------------------------------------------------------------------- > Roland Dobbins // > > The basis of optimism is sheer terror. > > -- Oscar Wilde > > > From dot at dotat.at Tue Mar 29 10:25:35 2011 From: dot at dotat.at (Tony Finch) Date: Tue, 29 Mar 2011 16:25:35 +0100 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> References: <004a01cbe7ec$338874b0$9a995e10$@net> <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> Message-ID: George Bonser wrote: > > What bothers me is that most companies are now going to be forced to > purchase .xxx domains simply to keep someone else from buying it and > sullying the company's image. Who is forcing them? Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: Southerly, veering westerly at times, 4 or 5, increasing 6 or 7 at times. Moderate or rough. Rain or showers, fog patches. Good, occasionally very poor. From dot at dotat.at Tue Mar 29 11:18:45 2011 From: dot at dotat.at (Tony Finch) Date: Tue, 29 Mar 2011 17:18:45 +0100 Subject: not really ICANN approves .XXX red-light district for the Internet In-Reply-To: <20110327203632.65784.qmail@joyce.lan> References: <20110327203632.65784.qmail@joyce.lan> Message-ID: John Levine wrote: > > I suppose one could argue in both cases that the existence of any > registrations at all shows "support", in which case .MUSEUM is a > rousing success, too. My favourite sTLD from the 2004 round is .post Tony. -- f.anthony.n.finch http://dotat.at/ Rockall, Malin, Hebrides, Bailey: Mainly southerly or southeasterly, veering westerly later in south Rockall, 4 or 5, increasing 6 at times. Moderate or rough. Rain or showers, fog patches in Rockall and Malin. Moderate or good, occasionally very poor in Rockall and Malin. From Valdis.Kletnieks at vt.edu Tue Mar 29 11:19:39 2011 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 29 Mar 2011 12:19:39 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: Your message of "Tue, 29 Mar 2011 16:25:35 BST." References: <004a01cbe7ec$338874b0$9a995e10$@net> <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> Message-ID: <10185.1301415579@localhost> On Tue, 29 Mar 2011 16:25:35 BST, Tony Finch said: > George Bonser wrote: > > > > What bothers me is that most companies are now going to be forced to > > purchase .xxx domains simply to keep someone else from buying it and > > sullying the company's image. > > Who is forcing them? Do a 'whois ibm.biz', 'ibm.info', 'ibm.org', or 'ibm.us' ('ibm.net' appears to be slightly different) and ask yourself why those registrations exist. The only reason they exist is so that IBM can stick this in the DNS: ibm.info. 86400 IN TXT "Visit www.ibm.com for information about IBM products and services" ibm.info. 86400 IN TXT "v=spf1 mx/24 -all" ibm.info. 86400 IN MX 100 ns.watson.ibm.com. ibm.info. 86400 IN SOA ns.watson.ibm.com. dnsadm.us.ibm.com. 2010073000 21600 3600 1209600 86400 ibm.info. 86400 IN A 129.42.38.1 ibm.info. 86400 IN NS ns.watson.ibm.com. ibm.info. 86400 IN NS ns.almaden.ibm.com. 1.38.42.129.in-addr.arpa. 28800 IN PTR redirect.www.ibm.com. So some miscreant can't register 'ibm.biz' for themselves for lulz and profit. You don't think miscreants would do that? Might want to look into the checkered past of 'whitehouse.com' sometime. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From tme at americafree.tv Tue Mar 29 11:32:55 2011 From: tme at americafree.tv (Marshall Eubanks) Date: Tue, 29 Mar 2011 12:32:55 -0400 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: References: <004a01cbe7ec$338874b0$9a995e10$@net> <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> Message-ID: <421753CA-DAE5-4939-A4C5-366A65C54C27@americafree.tv> On Mar 29, 2011, at 11:25 AM, Tony Finch wrote: > George Bonser wrote: >> >> What bothers me is that most companies are now going to be forced to >> purchase .xxx domains simply to keep someone else from buying it and >> sullying the company's image. > > Who is forcing them? Their lawyers. Regards Marshall > > Tony. > -- > f.anthony.n.finch http://dotat.at/ > Shannon: Southerly, veering westerly at times, 4 or 5, increasing 6 or 7 at > times. Moderate or rough. Rain or showers, fog patches. Good, occasionally > very poor. > > From joelja at bogus.com Tue Mar 29 11:41:32 2011 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 29 Mar 2011 09:41:32 -0700 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: <421753CA-DAE5-4939-A4C5-366A65C54C27@americafree.tv> References: <004a01cbe7ec$338874b0$9a995e10$@net> <5A6D953473350C4B9995546AFE9939EE0C9E2A73@RWC-EX1.corp.seven.com> <421753CA-DAE5-4939-A4C5-366A65C54C27@americafree.tv> Message-ID: <4D920BBC.5030206@bogus.com> On 3/29/11 9:32 AM, Marshall Eubanks wrote: > > On Mar 29, 2011, at 11:25 AM, Tony Finch wrote: > >> George Bonser wrote: >>> >>> What bothers me is that most companies are now going to be forced to >>> purchase .xxx domains simply to keep someone else from buying it and >>> sullying the company's image. >> >> Who is forcing them? > > Their lawyers. given that domain registration is cheaper than billable hours I don't see the problem. > Regards > Marshall > > >> >> Tony. >> -- >> f.anthony.n.finch http://dotat.at/ >> Shannon: Southerly, veering westerly at times, 4 or 5, increasing 6 or 7 at >> times. Moderate or rough. Rain or showers, fog patches. Good, occasionally >> very poor. >> >> > > From arturo.servin at gmail.com Tue Mar 29 11:41:09 2011 From: arturo.servin at gmail.com (Arturo Servin) Date: Tue, 29 Mar 2011 18:41:09 +0200 Subject: IPv6 SEO implecations? In-Reply-To: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> References: <5F63749D-6CFC-4723-89F3-3129D30888C2@bsdboy.com> Message-ID: <0AE5BB46-3BD8-4364-85DE-2C007771B50F@gmail.com> On 29 Mar 2011, at 00:18, Wil Schultz wrote: > I'm attempting to find out information on the SEO implications of testing ipv6 out. > > A couple of concerns that come to mind are: > > 1) www.domain.com and ipv6.domain.com are serving the exact same content. > Typical SEO standards are to only serve good content from a single domain so information isn't watered down and so that the larger search engines won't penalize. So a big concern is having search results take a hit because content is duplicated through two different domains, even though one domain is ipv4 only and the other is ipv6 only. > > 2) Not running ipv6 natively, or using 6to4. > This (potentially) increases hop count and will put content on a slower GRE tunnel and add some additional time for page load times. > > 3) ??? Any others that I haven't thought of ??? > > So basically I'd love to set up some sites for ipv6.domain.com via 6to4 as a phase one, and at some point in the near future implement ipv6 natively inside the datacenter, but I'm somewhat concerned about damaging SEO reputation in the process. > > Thoughts? > > -wil Twitter said: http://twitter.com/#!/look4ipv6/status/24639157611528193 Al least you would have a better page-rank in www.example.com than in ipv6.example.com with the same content. .as From wschultz at bsdboy.com Tue Mar 29 11:54:27 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Tue, 29 Mar 2011 09:54:27 -0700 Subject: IPv6 SEO implecations? In-Reply-To: References: Message-ID: <4F427F24-E9D4-4B7B-ACCF-9F9E52D8C336@bsdboy.com> On Mar 29, 2011, at 3:51 AM, Franck Martin wrote: > > > On 3/29/11 10:18 , "Wil Schultz" wrote: > >> I'm attempting to find out information on the SEO implications of testing >> ipv6 out. >> >> >> 3) ??? Any others that I haven't thought of ??? >> >> So basically I'd love to set up some sites for ipv6.domain.com via 6to4 >> as a phase one, and at some point in the near future implement ipv6 >> natively inside the datacenter, but I'm somewhat concerned about damaging >> SEO reputation in the process. >> >> Thoughts? >> > > Do we know which spiders run on IPv6? > > After all an IPv6 only site may not be indexed at all... > I haven't published any hostnames, so I don't have the entire picture... with that being said, here's what I have seen. The only big search engine I've seen at this point is google, here are the user agents I've seen to date: Googlebot-Image/1.0 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) ----------- Just FYI, Google bots all have an ipv6 suffix of 6006:1300:b075 (Google Bots, how 1337 of them!) Here are the addresses seen from google: 2001:4860:4801:1302:0:6006:1300:b075 2001:4860:4801:1303:0:6006:1300:b075 2001:4860:4801:1401:0:6006:1300:b075 2001:4860:4801:1402:0:6006:1300:b075 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1407:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 ----------- And here's a breakdown of which user agents are seen on which ip, as you can see the user-agent doesn't exactly match IP range. Googlebot-Image/1.0 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html); 2001:4860:4801:1302:0:6006:1300:b075 2001:4860:4801:1303:0:6006:1300:b075 2001:4860:4801:1401:0:6006:1300:b075 2001:4860:4801:1402:0:6006:1300:b075 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1407:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1407:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) 2001:4860:4801:1302:0:6006:1300:b075 2001:4860:4801:1401:0:6006:1300:b075 2001:4860:4801:1404:0:6006:1300:b075 2001:4860:4801:1405:0:6006:1300:b075 2001:4860:4801:1407:0:6006:1300:b075 2001:4860:4801:1408:0:6006:1300:b075 ----------- Again, I don't have the entire picture because I've not published my hostnames. The above information is just what I've seen on my selective testing. -wil From nanogwp at gmail.com Tue Mar 29 12:33:07 2011 From: nanogwp at gmail.com (Robert Lusby) Date: Tue, 29 Mar 2011 18:33:07 +0100 Subject: Ping - APAC Region Message-ID: Slightly off-topic so apologies: Looking at hosting some servers in Hong Kong, to serve the APAC region. Our client is worried that this may slow things down in their Australia region, and are wondering whether hosting the servers in an Australian data-centre would be a better option. Does anyone have any statistics on this? Or ... does anyone know of a "ping" tool we can use, hosted in Australia? Any better ideas welcome. Thanks. From Crist.Clark at globalstar.com Tue Mar 29 12:32:56 2011 From: Crist.Clark at globalstar.com (Crist Clark) Date: Tue, 29 Mar 2011 10:32:56 -0700 Subject: The state-level attack on the SSL CA security model In-Reply-To: <82bp0u1j08.fsf@mid.bfk.de> References: <3D1C9F87-F601-4924-8C08-16207172ED19@arbor.net> <20110324101947.GA11913@nike.aronius.se> <8239mchkc5.fsf@mid.bfk.de> <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> <67A80530-F81B-41B7-A7B3-5B1131A8F8C4@arbor.net> <82r59va73h.fsf@mid.bfk.de> <4D90BB97.33E4.0097.1@globalstar.com><4D90BB97.33E4.0097.1@globalstar.com> (Crist Clark's message of "Mon\, 28 Mar 2011 16\:47\:26 -0700") <82bp0u1j08.fsf@mid.bfk.de> Message-ID: <4D91B551.33E4.0097.1@globalstar.com> >>> On 3/29/2011 at 12:30 AM, Florian Weimer wrote: > * Crist Clark: > >> Any large, well funded national-level intelligence agency >> almost certainly has keys to a valid CA distributed with >> any browser or SSL package. It would be trivial for the US >> Gov't (and by extension, the whole AUSCANNZUKUS intelligence >> community) to simply form a shell company CA that could get >> a trusted cert in the distros or enlist a "legit" CA to do >> their patriotic duty (along with some $$$) and give up a key. > > I think this is far too complicated. You just add your state PKI to > the browsers, and the CPS does not require any checks on the Common > Name, to verify it's actually somehow controlled by the certificate > holder. Curiously, such CAs can pass Webtrust audits. > > Now I'm a realist and assume that the bureaucrats involved are just > too incompetent to write a proper CPS (and the auditors to lazy to > notice). Authoring policies and paying attention to detail, should be > second nature to them, but somehow I doubt that the FPKI (say) issues > certificates for non-federal entities to help with ongoing FBI > investigations. (Same for the German government agencies who actually > managed to get Mozilla approval for their non-CN-checking CAs.) I would expect intelligence agencies to not use CA certificates that are publically associated with a gov't owned or operated CA. It makes it too easy for the target to figure out they are being spied on and by whom. To a lesser extent, the same goes for law enforcement. They could not care less about being discovered after the fact, but may not want the surveillance target to know they are being watched. Here's a Wired Threat Level blog entry, from just about a year ago, about these commercially available tools for law enforcement, http://www.wired.com/threatlevel/2010/03/packet-forensics/ -- Crist Clark Network Security Specialist, Information Systems Globalstar 408 933 4387 From copraphage at gmail.com Tue Mar 29 12:39:41 2011 From: copraphage at gmail.com (Chris McDonald) Date: Tue, 29 Mar 2011 13:39:41 -0400 Subject: Ping - APAC Region In-Reply-To: References: Message-ID: pccw's lookingglass http://lookingglass.pccwglobal.com/ On Tue, Mar 29, 2011 at 1:33 PM, Robert Lusby wrote: > Slightly off-topic so apologies: > > Looking at hosting some servers in Hong Kong, to serve the APAC region. Our > client is worried that this may slow things down in their Australia region, > and are wondering whether hosting the servers in an Australian data-centre > would be a better option. > > Does anyone have any statistics on this? > > Or ... does anyone know of a "ping" tool we can use, hosted in Australia? > > Any better ideas welcome. > > Thanks. > From ebais at a2b-internet.com Tue Mar 29 12:39:55 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 29 Mar 2011 19:39:55 +0200 Subject: Ping - APAC Region In-Reply-To: References: Message-ID: <004d01cbee38$512ddad0$f3899070$@com> Did you had a look at the traceroute page from Telstra ? http://www.telstra.net/cgi-bin/trace Regards, Erik From mpalmer at hezmatt.org Tue Mar 29 13:17:16 2011 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 30 Mar 2011 05:17:16 +1100 Subject: Ping - APAC Region In-Reply-To: References: Message-ID: <20110329181716.GE28381@hezmatt.org> On Tue, Mar 29, 2011 at 06:33:07PM +0100, Robert Lusby wrote: > Looking at hosting some servers in Hong Kong, to serve the APAC region. Our > client is worried that this may slow things down in their Australia region, > and are wondering whether hosting the servers in an Australian data-centre > would be a better option. > > Does anyone have any statistics on this? No formal statistics, just a lot of experience. You may be unsurprised to learn that serving into Australia from outside Australia is slower than serving from within Australia. That being said, there's a fair bit less distance for the light to travel from Hong Kong or anywhere in the region than from the US. That is predicated on having good direct links, which is eye-wateringly expensive if you're used to US data costs (data going from China to Australia via San Jose... aaargh). Then again, hosting within Australia is similarly expensive, so splitting your presence isn't going to help you any from a cost PoV. Anyone living in this part of the world is used to everything taking a painful amount of time to load anyway, so unless you're doing something really latency-critical (online gaming and VoIP are the only things that leap to mind), hosting in a good west coast DC close to the trans-pacific links will cost you an order of magnitude less and won't have any noticeable impact on your visitor satisfaction scores. > Or ... does anyone know of a "ping" tool we can use, hosted in Australia? No shortage of APAC looking glasses / tools listed at traceroute.org. - Matt -- The most secure computer in the world is one not connected to the internet. Thats why I recommend Telstra ADSL. -- bash.org/?168859 From fmartin at linkedin.com Tue Mar 29 15:12:03 2011 From: fmartin at linkedin.com (Franck Martin) Date: Tue, 29 Mar 2011 20:12:03 +0000 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: Message-ID: Well, you don't need to wait for .xxx you have things like http://www.radio.co.ck/ On 3/30/11 3:25 , "Tony Finch" wrote: >George Bonser wrote: >> >> What bothers me is that most companies are now going to be forced to >> purchase .xxx domains simply to keep someone else from buying it and >> sullying the company's image. > >Who is forcing them? > >Tony. From fmartin at linkedin.com Tue Mar 29 15:13:52 2011 From: fmartin at linkedin.com (Franck Martin) Date: Tue, 29 Mar 2011 20:13:52 +0000 Subject: ICANN approves .XXX red-light district for the Internet In-Reply-To: Message-ID: Or http://www.budget.co.ck/ .. On 3/30/11 3:25 , "Tony Finch" wrote: >George Bonser wrote: >> >> What bothers me is that most companies are now going to be forced to >> purchase .xxx domains simply to keep someone else from buying it and >> sullying the company's image. > >Who is forcing them? From joe at gonetforward.com Tue Mar 29 15:38:04 2011 From: joe at gonetforward.com (Joe Renwick) Date: Tue, 29 Mar 2011 13:38:04 -0700 Subject: What is this Cisco process? In-Reply-To: References: <88BC6885D33A9D42A1CCB45E8749525E0149D1F3@pigeon.sandiego.nextlevelinternet.com> Message-ID: So thanks to all for the help. It was an SFP. Here is CPU with bad SFP: plf-access# plf-access#sh proc cpu sorted CPU utilization for five seconds: 11%/0%; one minute: 18%; five minutes: 21% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 41 237737055 1095169 217078 5.11% 11.74% 14.87% 0 SFF8472 Here is CPU with SFP taken out: plf-access#sh proc cpu sorted CPU utilization for five seconds: 5%/0%; one minute: 17%; five minutes: 21% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process 106 322 437 736 0.79% 0.07% 0.03% 0 Exec Confirmed it was the SFP by pulling it in and out a couple times. Processor flapped right along. Thanks again to all, Joe "Well, I have no direct experience with the 3560, but SFF-8472 is a spec that includes diagnosting monitoring of SFPs..." On Tue, Mar 29, 2011 at 1:32 PM, Joe Renwick wrote: > It was consistent... Since I started managing the device with Cacti on > Sunday it was dead red at that level. Was an SFP... going to post a > response now. > > Joe > > > On Tue, Mar 29, 2011 at 1:23 PM, Hayden Katzenellenbogen < > hayden at nextlevelinternet.com> wrote: > >> Hey Joe, >> >> Is the CPU usage consistent or fluctuating? >> >> -H >> >> -----Original Message----- >> From: Joe Renwick [mailto:joe at gonetforward.com] >> Sent: Tuesday, March 29, 2011 3:52 AM >> To: nanog at nanog.org >> Subject: What is this Cisco process? >> >> Hello, >> >> Have a Cisco 3560 running "flash:/c3560-ipbasek9-mz.122-55.SE1.bin". >> Been >> running at 20% CPU since we started it: >> >> [image: plf-access - CPU Usage] >> >> The switch is completely layer-2... basic configuration. CPU >> utilization is >> soley based on a single process: >> >> plf-access#sh proc cpu sorted >> CPU utilization for five seconds: 27%/0%; one minute: 25%; five minutes: >> 24% >> PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process >> 41 232891470 1072247 217210 20.12% 18.99% 18.01% 0 SFF8472 >> >> 78 2376721 123621 19225 0.95% 0.22% 0.17% 0 HULC Tcam >> Memory >> 303 299 163 1834 0.47% 0.23% 0.07% 2 SSH >> Process >> >> 55 106535 11303527 9 0.15% 0.02% 0.00% 0 RedEarth >> Tx >> Mana >> >> Anybody have a clue what this process is? >> >> Thanks for the time. >> >> Cheers, >> >> -- >> Joe Renwick >> IP Network Consultant, CCIE #16465 >> GO NETFORWARD! >> Direct: 619-800-2055, Emergency Support: 800-719-0504 >> Is your network moving you forward? >> > > > > -- > Joe Renwick > IP Network Consultant, CCIE #16465 > GO NETFORWARD! > Direct: 619-800-2055, Emergency Support: 800-719-0504 > Is your network moving you forward? > > > -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From joe at gonetforward.com Tue Mar 29 15:40:36 2011 From: joe at gonetforward.com (Joe Renwick) Date: Tue, 29 Mar 2011 13:40:36 -0700 Subject: What is this Cisco process? In-Reply-To: <1301396806.12859.115.camel@icts-sp-039> References: <1301396806.12859.115.camel@icts-sp-039> Message-ID: Ingen, How did you know this? And I quote "Well, I have no direct experience with the 3560, but SFF-8472 is a spec that includes diagnosting monitoring of SFPs...". Really am I missing some secret search engine? Is google not the answer? Please do let me know because if it was from an online resource I want to know what it is. Thanks again for the response... you solved my problem. Cheers, Joe On Tue, Mar 29, 2011 at 4:06 AM, Ingen Schenau, Jeroen van (ICTS) < j.vaningenschenau at utwente.nl> wrote: > Hi, > > > Have a Cisco 3560 running "flash:/c3560-ipbasek9-mz.122-55.SE1.bin". > Been > > running at 20% CPU since we started it: > > > > [image: plf-access - CPU Usage] > > > > The switch is completely layer-2... basic configuration. CPU utilization > is > > soley based on a single process: > > > > plf-access#sh proc cpu sorted > > CPU utilization for five seconds: 27%/0%; one minute: 25%; five minutes: > 24% > > PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process > > 41 232891470 1072247 217210 20.12% 18.99% 18.01% 0 SFF8472 > > Well, I have no direct experience with the 3560, but SFF-8472 is a spec > that includes diagnosting monitoring of SFPs... > > Not sure why this would take up so many cpu cycles... are you by any > chance continuously polling the switch for SFP readouts, ie optical > receive power, laser bias, SFP temperature etc? > > > Regards, > > Jeroen van Ingen > ICT Service Centre > University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands > > > -- Joe Renwick IP Network Consultant, CCIE #16465 GO NETFORWARD! Direct: 619-800-2055, Emergency Support: 800-719-0504 Is your network moving you forward? From jared at puck.nether.net Tue Mar 29 16:00:02 2011 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 29 Mar 2011 17:00:02 -0400 Subject: AS1273 contact Message-ID: <183A7B33-6EA9-4E6D-B5E7-7C35E3309911@puck.nether.net> Is there from AS1273 out there that would be willing to talk to me about a bgp problem we are observing? (Or 1239, since your routes are being sent as a customer route by 1273) Thanks, - Jared From jazzyjpz at gmail.com Tue Mar 29 17:04:20 2011 From: jazzyjpz at gmail.com (John J) Date: Tue, 29 Mar 2011 17:04:20 -0500 Subject: What is this Cisco process? In-Reply-To: References: <88BC6885D33A9D42A1CCB45E8749525E0149D1F3@pigeon.sandiego.nextlevelinternet.com> Message-ID: I wonder if you were seeing 14% CPU over 5min avg BECAUSE the SFP supported DOM or was it a bug due to DOM. In other words, maybe the fact that the SFP supported DOM just took up a bit more CPU due to the diagnostic function. Is it normal I guess is what I'm wondering... -J On Tue, Mar 29, 2011 at 3:38 PM, Joe Renwick wrote: > So thanks to all for the help. It was an SFP. Here is CPU with bad SFP: > > plf-access# > > plf-access#sh proc cpu sorted > > CPU utilization for five seconds: 11%/0%; one minute: 18%; five minutes: > 21% > > PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process > > 41 237737055 1095169 217078 5.11% 11.74% 14.87% 0 SFF8472 > > Here is CPU with SFP taken out: > > plf-access#sh proc cpu sorted > > CPU utilization for five seconds: 5%/0%; one minute: 17%; five minutes: 21% > > PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process > > 106 322 437 736 0.79% 0.07% 0.03% 0 Exec > > > Confirmed it was the SFP by pulling it in and out a couple times. > Processor > flapped right along. > > > Thanks again to all, > > > Joe > > > "Well, I have no direct experience with the 3560, but SFF-8472 is a spec > that includes diagnosting monitoring of SFPs..." > > > > On Tue, Mar 29, 2011 at 1:32 PM, Joe Renwick wrote: > > > It was consistent... Since I started managing the device with Cacti on > > Sunday it was dead red at that level. Was an SFP... going to post a > > response now. > > > > Joe > > > > > > On Tue, Mar 29, 2011 at 1:23 PM, Hayden Katzenellenbogen < > > hayden at nextlevelinternet.com> wrote: > > > >> Hey Joe, > >> > >> Is the CPU usage consistent or fluctuating? > >> > >> -H > >> > >> -----Original Message----- > >> From: Joe Renwick [mailto:joe at gonetforward.com] > >> Sent: Tuesday, March 29, 2011 3:52 AM > >> To: nanog at nanog.org > >> Subject: What is this Cisco process? > >> > >> Hello, > >> > >> Have a Cisco 3560 running "flash:/c3560-ipbasek9-mz.122-55.SE1.bin". > >> Been > >> running at 20% CPU since we started it: > >> > >> [image: plf-access - CPU Usage] > >> > >> The switch is completely layer-2... basic configuration. CPU > >> utilization is > >> soley based on a single process: > >> > >> plf-access#sh proc cpu sorted > >> CPU utilization for five seconds: 27%/0%; one minute: 25%; five minutes: > >> 24% > >> PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process > >> 41 232891470 1072247 217210 20.12% 18.99% 18.01% 0 SFF8472 > >> > >> 78 2376721 123621 19225 0.95% 0.22% 0.17% 0 HULC Tcam > >> Memory > >> 303 299 163 1834 0.47% 0.23% 0.07% 2 SSH > >> Process > >> > >> 55 106535 11303527 9 0.15% 0.02% 0.00% 0 RedEarth > >> Tx > >> Mana > >> > >> Anybody have a clue what this process is? > >> > >> Thanks for the time. > >> > >> Cheers, > >> > >> -- > >> Joe Renwick > >> IP Network Consultant, CCIE #16465 > >> GO NETFORWARD! > >> Direct: 619-800-2055, Emergency Support: 800-719-0504 > >> Is your network moving you forward? > >> > > > > > > > > -- > > Joe Renwick > > IP Network Consultant, CCIE #16465 > > GO NETFORWARD! > > Direct: 619-800-2055, Emergency Support: 800-719-0504 > > Is your network moving you forward? > > > > > > > > > -- > Joe Renwick > IP Network Consultant, CCIE #16465 > GO NETFORWARD! > Direct: 619-800-2055, Emergency Support: 800-719-0504 > Is your network moving you forward? > From jeroen at utwente.nl Wed Mar 30 05:43:33 2011 From: jeroen at utwente.nl (Jeroen van Ingen) Date: Wed, 30 Mar 2011 12:43:33 +0200 Subject: What is this Cisco process? In-Reply-To: References: <1301396806.12859.115.camel@icts-sp-039> Message-ID: <1301481813.21182.18.camel@icts-sp-039> Hi Joe, > How did you know this? And I quote "Well, I have no direct experience > with the 3560, but SFF-8472 is a spec that includes diagnosting > monitoring of SFPs...". Really am I missing some secret search > engine? Is google not the answer? Please do let me know because if > it was from an online resource I want to know what it is. Well, I was triggered by the SFF designation because I've been hacking SFP transceivers in my spare time... with the huge price markups on transceivers by the big vendors, it's getting more interesting to buy quality SFPs and alter the ID strings in a way that they are recognized as "genuine Cisco" of "genuine HP". Googling for SFF8472 will also get you hits (eg a great PDF at ftp.seagate.com), but they might not seem relevant at first glance :) > Thanks again for the response... you solved my problem. Good to hear and you're welcome :) Regards, Jeroen van Ingen ICT Service Centre University of Twente, P.O.Box 217, 7500 AE Enschede, The Netherlands From vovan at fakmoymozg.ru Wed Mar 30 11:45:53 2011 From: vovan at fakmoymozg.ru (vovan at fakmoymozg.ru) Date: Wed, 30 Mar 2011 20:45:53 +0400 Subject: Livejournal DDoS Message-ID: <3c1ee3e1b8db6921307d616089bee724@fakmoymozg.ru> Hello all, > http://livejournal.com/ is there any technical data about the attack? e.g. average traffic in Gb/s, amount of bots, etc. Cheers, Vladimir From jared at puck.nether.net Wed Mar 30 12:56:37 2011 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 30 Mar 2011 13:56:37 -0400 Subject: AS1273/AS2200 contact In-Reply-To: <183A7B33-6EA9-4E6D-B5E7-7C35E3309911@puck.nether.net> References: <183A7B33-6EA9-4E6D-B5E7-7C35E3309911@puck.nether.net> Message-ID: <986031C4-F40E-4947-BEA9-C3E4A910CD7D@puck.nether.net> Adding AS2200 to the list, as I'm sure packets should not be following this path: 192.190.234.0/24 2914 1273 2200 3356 5511 1708 traceroute to 192.190.234.0 (192.190.234.0), 64 hops max, 40 byte packets 1 * ge-5-2.r00.chcgil09.us.bb.gin.ntt.net (204.42.254.1) 0.269 ms 0.223 ms 2 ae-1.r20.chcgil09.us.bb.gin.ntt.net (129.250.4.112) 0.281 ms 0.270 ms 0.281 ms 3 ae-4.r23.nycmny01.us.bb.gin.ntt.net (129.250.2.41) 26.920 ms 26.936 ms 26.904 ms 4 ae-1.r20.asbnva02.us.bb.gin.ntt.net (129.250.2.9) 27.424 ms 28.820 ms 67.431 ms 5 ae-1.r01.asbnva02.us.bb.gin.ntt.net (129.250.3.11) 26.416 ms 33.341 ms 25.850 ms 6 xe-0-6-0-7.r01.asbnva02.us.ce.gin.ntt.net (168.143.105.10) 34.785 ms 81.159 ms 29.605 ms 7 xe-7-1-0-xcr1.prp.cw.net (195.2.25.194) 104.738 ms xe-8-2-0-xcr1.prp.cw.net (195.2.25.210) 111.156 ms xe-7-1-0-xcr1.prp.cw.net (195.2.25.194) 106.382 ms 8 renater-gw.prp.cw.net (195.10.62.26) 104.986 ms 111.808 ms 105.519 ms 9 te0-3-4-0-paris1-rtr-001.noc.renater.fr (193.51.189.5) 112.444 ms 110.855 ms 108.488 ms 10 te0-3-1-0-lyon1-rtr-001.noc.renater.fr (193.51.189.126) 138.519 ms 142.551 ms 138.228 ms 11 xe-8-0-0.edge5.Paris1.Level3.net (212.73.207.173) 114.697 ms 149.480 ms 108.317 ms 12 ae-2-52.edge4.Paris1.Level3.net (4.69.139.234) 109.181 ms 109.479 ms 114.317 ms 13 tengige0-10-0-4.pastr1.Paris.opentransit.net (193.251.252.137) 150.880 ms 81.52.179.161 (81.52.179.161) 110.601 ms - Jared On Mar 29, 2011, at 5:00 PM, Jared Mauch wrote: > Is there from AS1273 out there that would be willing to talk to me about a bgp problem we are observing? > > (Or 1239, since your routes are being sent as a customer route by 1273) > > Thanks, > > - Jared From rfg at tristatelogic.com Wed Mar 30 15:53:50 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 30 Mar 2011 13:53:50 -0700 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? Message-ID: <33111.1301518430@tristatelogic.com> I just stumbled onto this one the other day. Apparently, Spamhaus has known about this one for THREE MONTHS already: http://www.spamhaus.org/sbl/sbl.lasso?query=SBL98308 It's being routed by AS11730, aka "Circle Internet LTD", a known spammer- friendly provider that I have come across many times in the past. They in turn are getting connectivity from: AS26769 BandCon AS7385 Integra Telecom These companies are also not known for being especially scruplous either. But I mean seriously, Jesus Christ! Does ANYBODY even give a crap about blatant naked IP space hijacking anymore? Or is the entire net now on its final slow descent into utter chaos? Regards, rfg P.S. The 159.223.0.0/16 block is actually registered to the chemical company Hoechst Celanese Corporation. I'll have more to say about that in just a moment. Meanwhile listed below is some of the snowshoe spammer crud that is alive and active inside of 159.223.0.0/16, even as we speak. (I am not posting all of it because there's just too much, and posting all of it would exceed the NANOG list's 100kb limit.) 159.223.7.2 advocateagents.com 159.223.7.3 tsoppi.advocateagents.com 159.223.7.4 trudi.advocateagents.com 159.223.7.5 typist.advocateagents.com 159.223.7.6 jasmine.advocateagents.com 159.223.7.7 jimenez.advocateagents.com 159.223.7.8 korene.advocateagents.com 159.223.7.9 jece.advocateagents.com 159.223.7.10 movie.advocateagents.com 159.223.7.11 ophiucus.advocateagents.com 159.223.7.12 vljublennych.advocateagents.com 159.223.7.13 jiriki.advocateagents.com 159.223.7.14 jedediah.advocateagents.com 159.223.7.15 streetwalker.advocateagents.com 159.223.7.16 augustus.advocateagents.com 159.223.7.17 jada.advocateagents.com 159.223.7.18 earth.advocateagents.com 159.223.7.19 sugawara.advocateagents.com 159.223.7.20 herculean.advocateagents.com 159.223.7.21 takala.advocateagents.com 159.223.7.22 gradient.advocateagents.com 159.223.7.23 feddersen.advocateagents.com 159.223.7.24 messiter.advocateagents.com 159.223.7.25 polar.advocateagents.com 159.223.7.26 doughboy.advocateagents.com 159.223.7.27 chalgrin.advocateagents.com 159.223.7.28 meatball.advocateagents.com 159.223.7.29 conseil.advocateagents.com 159.223.7.30 sprotte.advocateagents.com 159.223.7.31 lackaye.advocateagents.com 159.223.7.32 maquis.advocateagents.com 159.223.7.33 freethink.advocateagents.com 159.223.7.34 morven.advocateagents.com 159.223.7.35 infimum.advocateagents.com 159.223.7.36 vasile.advocateagents.com 159.223.7.37 violey.advocateagents.com 159.223.7.38 deoxyribonucleic.advocateagents.com 159.223.7.39 buyett.advocateagents.com 159.223.7.40 gon.advocateagents.com 159.223.7.41 edra.advocateagents.com 159.223.7.42 pickwick.advocateagents.com 159.223.7.43 jimpson.advocateagents.com 159.223.7.44 trintignant.advocateagents.com 159.223.7.45 holzschuh.advocateagents.com 159.223.7.46 danish.advocateagents.com 159.223.7.47 jail.advocateagents.com 159.223.7.48 krischan.advocateagents.com 159.223.7.49 lauritz.advocateagents.com 159.223.7.50 confluent.advocateagents.com 159.223.7.51 cunegonde.advocateagents.com 159.223.7.52 comb.advocateagents.com 159.223.7.53 ndurinnor.advocateagents.com 159.223.7.54 cordoba.advocateagents.com 159.223.7.55 lenora.advocateagents.com 159.223.7.56 boatright.advocateagents.com 159.223.7.57 syenite.advocateagents.com 159.223.7.58 echo.advocateagents.com 159.223.7.59 jesli.advocateagents.com 159.223.7.60 harriette.advocateagents.com 159.223.7.61 dotting.advocateagents.com 159.223.7.62 brogan.advocateagents.com 159.223.7.63 steeplebush.advocateagents.com 159.223.7.64 basis.advocateagents.com 159.223.7.65 cardenio.advocateagents.com 159.223.7.66 lumen.advocateagents.com 159.223.7.67 pitiable.advocateagents.com 159.223.7.68 blasphemous.advocateagents.com 159.223.7.69 polopony.advocateagents.com 159.223.7.70 cesium.advocateagents.com 159.223.7.71 calvo.advocateagents.com 159.223.7.72 linkers.advocateagents.com 159.223.7.73 mette.advocateagents.com 159.223.7.74 eris.advocateagents.com 159.223.7.75 oppressive.advocateagents.com 159.223.7.76 wlodek.advocateagents.com 159.223.7.77 islamic.advocateagents.com 159.223.7.78 lucan.advocateagents.com 159.223.7.79 henpeck.advocateagents.com 159.223.7.80 savannah.advocateagents.com 159.223.7.81 lemuels.advocateagents.com 159.223.7.82 monoceros.advocateagents.com 159.223.7.83 aames.advocateagents.com 159.223.7.84 froth.advocateagents.com 159.223.7.85 shipbuild.advocateagents.com 159.223.7.86 rule.advocateagents.com 159.223.7.87 khun.advocateagents.com 159.223.7.88 crandal.advocateagents.com 159.223.7.89 mclaughlin.advocateagents.com 159.223.7.90 trumaine.advocateagents.com 159.223.7.91 albertazzi.advocateagents.com 159.223.7.92 daidoji.advocateagents.com 159.223.7.93 candlestick.advocateagents.com 159.223.7.94 southampton.advocateagents.com 159.223.7.95 paulot.advocateagents.com 159.223.7.96 rivkah.advocateagents.com 159.223.7.97 tollgate.advocateagents.com 159.223.7.98 caius.advocateagents.com 159.223.7.99 savalas.advocateagents.com 159.223.7.100 pimlico.advocateagents.com 159.223.7.101 noce.advocateagents.com 159.223.7.102 bandana.advocateagents.com 159.223.7.103 tibbett.advocateagents.com 159.223.7.104 retour.advocateagents.com 159.223.7.105 gladwin.advocateagents.com 159.223.7.106 felippa.advocateagents.com 159.223.7.107 rosie.advocateagents.com 159.223.7.108 burchnall.advocateagents.com 159.223.7.109 indispose.advocateagents.com 159.223.7.110 yeardley.advocateagents.com 159.223.7.111 soji.advocateagents.com 159.223.7.112 baseband.advocateagents.com 159.223.7.113 aguistin.advocateagents.com 159.223.7.114 akemi.advocateagents.com 159.223.7.115 morales.advocateagents.com 159.223.7.116 kirwin.advocateagents.com 159.223.7.117 longwinded.advocateagents.com 159.223.7.118 grimaldi.advocateagents.com 159.223.7.119 sheik.advocateagents.com 159.223.7.120 karageorge.advocateagents.com 159.223.7.121 gennaro.advocateagents.com 159.223.7.122 yui.advocateagents.com 159.223.7.123 posteriori.advocateagents.com 159.223.7.124 rheba.advocateagents.com 159.223.7.125 kial.advocateagents.com 159.223.7.126 flo.advocateagents.com 159.223.7.127 inhibit.advocateagents.com 159.223.7.128 province.advocateagents.com 159.223.7.129 kazumi.advocateagents.com 159.223.7.130 baptiste.advocateagents.com 159.223.7.131 borner.advocateagents.com 159.223.7.132 shamadin.advocateagents.com 159.223.7.133 pelvic.advocateagents.com 159.223.7.134 rikke.advocateagents.com 159.223.7.135 fend.advocateagents.com 159.223.7.136 does.advocateagents.com 159.223.7.137 vinyl.advocateagents.com 159.223.7.138 mutuel.advocateagents.com 159.223.7.139 mong.advocateagents.com 159.223.7.140 sting.advocateagents.com 159.223.7.141 inkilinoff.advocateagents.com 159.223.7.142 calgagni.advocateagents.com 159.223.7.143 annulled.advocateagents.com 159.223.7.144 bolen.advocateagents.com 159.223.7.145 mazurowna.advocateagents.com 159.223.7.146 daw.advocateagents.com 159.223.7.147 marusia.advocateagents.com 159.223.7.148 hydrocyanic.advocateagents.com 159.223.7.149 admonition.advocateagents.com 159.223.7.150 clearboy.advocateagents.com 159.223.7.151 borisenko.advocateagents.com 159.223.7.152 nutrice.advocateagents.com 159.223.7.153 deshe.advocateagents.com 159.223.7.154 pellow.advocateagents.com 159.223.7.155 wrote.advocateagents.com 159.223.7.156 iranian.advocateagents.com 159.223.7.157 quere.advocateagents.com 159.223.7.158 acrimonious.advocateagents.com 159.223.7.159 bundgaard.advocateagents.com 159.223.7.160 footsie.advocateagents.com 159.223.7.161 engracia.advocateagents.com 159.223.7.162 burnecker.advocateagents.com 159.223.7.163 hodiak.advocateagents.com 159.223.7.164 pinner.advocateagents.com 159.223.7.165 animator.advocateagents.com 159.223.7.166 malo.advocateagents.com 159.223.7.167 specimans.advocateagents.com 159.223.7.168 thiamin.advocateagents.com 159.223.7.169 sadayoo.advocateagents.com 159.223.7.170 fadern.advocateagents.com 159.223.7.171 druid.advocateagents.com 159.223.7.172 szilard.advocateagents.com 159.223.7.173 arlee.advocateagents.com 159.223.7.174 levasseur.advocateagents.com 159.223.7.175 barwick.advocateagents.com 159.223.7.176 quayle.advocateagents.com 159.223.7.177 rubens.advocateagents.com 159.223.7.178 vinci.advocateagents.com 159.223.7.179 yoshiki.advocateagents.com 159.223.7.180 litvinoff.advocateagents.com 159.223.7.181 sanoilov.advocateagents.com 159.223.7.182 kilojoule.advocateagents.com 159.223.7.183 kopestonsky.advocateagents.com 159.223.7.184 retainer.advocateagents.com 159.223.7.185 bernt.advocateagents.com 159.223.7.186 mirjana.advocateagents.com 159.223.7.187 jamesy.advocateagents.com 159.223.7.188 chinn.advocateagents.com 159.223.7.189 sturgeon.advocateagents.com 159.223.7.190 hay.advocateagents.com 159.223.7.191 zarimba.advocateagents.com 159.223.7.192 centrex.advocateagents.com 159.223.7.193 lifelike.advocateagents.com 159.223.7.194 finn.advocateagents.com 159.223.7.195 colorate.advocateagents.com 159.223.7.196 mclain.advocateagents.com 159.223.7.197 aba.advocateagents.com 159.223.7.198 fountainhead.advocateagents.com 159.223.7.199 sadist.advocateagents.com 159.223.7.200 gardens.advocateagents.com 159.223.7.201 sedlak.advocateagents.com 159.223.7.202 grunberg.advocateagents.com 159.223.7.203 ania.advocateagents.com 159.223.7.204 zinderneuf.advocateagents.com 159.223.7.205 sadoc.advocateagents.com 159.223.7.206 stirjanov.advocateagents.com 159.223.7.207 letizia.advocateagents.com 159.223.7.208 siluck.advocateagents.com 159.223.7.209 minutes.advocateagents.com 159.223.7.210 alysia.advocateagents.com 159.223.7.211 raizul.advocateagents.com 159.223.7.212 backes.advocateagents.com 159.223.7.213 kyoko.advocateagents.com 159.223.7.214 mudie.advocateagents.com 159.223.7.215 coltrane.advocateagents.com 159.223.7.216 soil.advocateagents.com 159.223.7.217 haig.advocateagents.com 159.223.7.218 prophetic.advocateagents.com 159.223.7.219 proofread.advocateagents.com 159.223.7.220 equate.advocateagents.com 159.223.7.221 gene.advocateagents.com 159.223.7.222 fruitful.advocateagents.com 159.223.7.223 shale.advocateagents.com 159.223.7.224 canny.advocateagents.com 159.223.7.225 scholastic.advocateagents.com 159.223.7.226 hentzau.advocateagents.com 159.223.7.227 cindie.advocateagents.com 159.223.7.228 navrat.advocateagents.com 159.223.7.229 treaty.advocateagents.com 159.223.7.230 handymen.advocateagents.com 159.223.7.231 kithnou.advocateagents.com 159.223.7.232 clubroom.advocateagents.com 159.223.7.233 incendiary.advocateagents.com 159.223.7.234 industrious.advocateagents.com 159.223.7.235 uk.advocateagents.com 159.223.7.236 czordas.advocateagents.com 159.223.7.237 raef.advocateagents.com 159.223.7.238 tre.advocateagents.com 159.223.7.239 elitsa.advocateagents.com 159.223.7.240 bombed.advocateagents.com 159.223.7.241 chutney.advocateagents.com 159.223.7.242 nurk.advocateagents.com 159.223.7.243 adipic.advocateagents.com 159.223.7.244 lesleh.advocateagents.com 159.223.7.245 allason.advocateagents.com 159.223.7.246 cia.advocateagents.com 159.223.7.247 ott.advocateagents.com 159.223.7.248 quickstep.advocateagents.com 159.223.7.249 goss.advocateagents.com 159.223.7.250 triplex.advocateagents.com 159.223.7.251 fargher.advocateagents.com 159.223.7.252 sim.advocateagents.com 159.223.7.253 florendo.advocateagents.com 159.223.7.254 knitting.advocateagents.com 159.223.11.2 smtpdri2.rolofter.info 159.223.11.3 smtpdri3.rolofter.info 159.223.11.4 smtpdri4.rolofter.info 159.223.11.5 smtpdri5.rolofter.info 159.223.11.6 smtpdri6.rolofter.info 159.223.11.7 smtpdri7.rolofter.info 159.223.11.8 smtpdri8.rolofter.info 159.223.11.9 smtpdri9.rolofter.info 159.223.11.10 smtpdri10.rolofter.info 159.223.11.11 smtpdri11.rolofter.info 159.223.11.12 smtpdri12.rolofter.info 159.223.11.13 smtpdri13.rolofter.info 159.223.11.14 smtpdri14.rolofter.info 159.223.11.15 smtpdri15.rolofter.info 159.223.11.16 smtpdri16.rolofter.info 159.223.11.17 smtpdri17.rolofter.info 159.223.11.18 smtpdri18.rolofter.info 159.223.11.19 smtpdri19.rolofter.info 159.223.11.20 smtpdri20.rolofter.info 159.223.11.21 smtpdri21.rolofter.info 159.223.11.22 smtpdri22.rolofter.info 159.223.11.23 smtpdri23.rolofter.info 159.223.11.24 smtpdri24.rolofter.info 159.223.11.25 smtpdri25.rolofter.info 159.223.11.26 smtpdri26.rolofter.info 159.223.11.27 smtpdri27.rolofter.info 159.223.11.28 smtpdri28.rolofter.info 159.223.11.29 smtpdri29.rolofter.info 159.223.11.30 smtpdri30.rolofter.info 159.223.11.31 smtpdri31.rolofter.info 159.223.11.32 smtpdri32.rolofter.info 159.223.11.33 smtpdri33.rolofter.info 159.223.11.34 smtpdri34.rolofter.info 159.223.11.35 smtpdri35.rolofter.info 159.223.11.36 smtpdri36.rolofter.info 159.223.11.37 smtpdri37.rolofter.info 159.223.11.38 smtpdri38.rolofter.info 159.223.11.39 smtpdri39.rolofter.info 159.223.11.40 smtpdri40.rolofter.info 159.223.11.41 smtpdri41.rolofter.info 159.223.11.42 smtpdri42.rolofter.info 159.223.11.43 smtpdri43.rolofter.info 159.223.11.44 smtpdri44.rolofter.info 159.223.11.45 smtpdri45.rolofter.info 159.223.11.46 smtpdri46.rolofter.info 159.223.11.47 smtpdri47.rolofter.info 159.223.11.48 smtpdri48.rolofter.info 159.223.11.49 smtpdri49.rolofter.info 159.223.11.50 smtpdri50.rolofter.info 159.223.11.51 smtpdri51.rolofter.info 159.223.11.52 smtpdri52.rolofter.info 159.223.11.53 smtpdri53.rolofter.info 159.223.11.54 smtpdri54.rolofter.info 159.223.11.55 smtpdri55.rolofter.info 159.223.11.56 smtpdri56.rolofter.info 159.223.11.57 smtpdri57.rolofter.info 159.223.11.58 smtpdri58.rolofter.info 159.223.11.59 smtpdri59.rolofter.info 159.223.11.60 smtpdri60.rolofter.info 159.223.11.61 smtpdri61.rolofter.info 159.223.11.62 smtpdri62.rolofter.info 159.223.11.63 smtpdri63.rolofter.info 159.223.11.64 smtpdri64.rolofter.info 159.223.11.65 smtpdri65.rolofter.info 159.223.11.66 smtpdri66.rolofter.info 159.223.11.67 smtpdri67.rolofter.info 159.223.11.68 smtpdri68.rolofter.info 159.223.11.69 smtpdri69.rolofter.info 159.223.11.70 smtpdri70.rolofter.info 159.223.11.71 smtpdri71.rolofter.info 159.223.11.72 smtpdri72.rolofter.info 159.223.11.73 smtpdri73.rolofter.info 159.223.11.74 smtpdri74.rolofter.info 159.223.11.75 smtpdri75.rolofter.info 159.223.11.76 smtpdri76.rolofter.info 159.223.11.77 smtpdri77.rolofter.info 159.223.11.78 smtpdri78.rolofter.info 159.223.11.79 smtpdri79.rolofter.info 159.223.11.80 smtpdri80.rolofter.info 159.223.11.81 smtpdri81.rolofter.info 159.223.11.82 smtpdri82.rolofter.info 159.223.11.83 smtpdri83.rolofter.info 159.223.11.84 smtpdri84.rolofter.info 159.223.11.85 smtpdri85.rolofter.info 159.223.11.86 smtpdri86.rolofter.info 159.223.11.87 smtpdri87.rolofter.info 159.223.11.88 smtpdri88.rolofter.info 159.223.11.89 smtpdri89.rolofter.info 159.223.11.90 smtpdri90.rolofter.info 159.223.11.91 smtpdri91.rolofter.info 159.223.11.92 smtpdri92.rolofter.info 159.223.11.93 smtpdri93.rolofter.info 159.223.11.94 smtpdri94.rolofter.info 159.223.11.95 smtpdri95.rolofter.info 159.223.11.96 smtpdri96.rolofter.info 159.223.11.97 smtpdri97.rolofter.info 159.223.11.98 smtpdri98.rolofter.info 159.223.11.99 smtpdri99.rolofter.info 159.223.11.100 smtpdri100.rolofter.info 159.223.11.101 smtpdri101.rolofter.info 159.223.11.102 smtpdri102.rolofter.info 159.223.11.103 smtpdri103.rolofter.info 159.223.11.104 smtpdri104.rolofter.info 159.223.11.105 smtpdri105.rolofter.info 159.223.11.106 smtpdri106.rolofter.info 159.223.11.107 smtpdri107.rolofter.info 159.223.11.108 smtpdri108.rolofter.info 159.223.11.109 smtpdri109.rolofter.info 159.223.11.110 smtpdri110.rolofter.info 159.223.11.111 smtpdri111.rolofter.info 159.223.11.112 smtpdri112.rolofter.info 159.223.11.113 smtpdri113.rolofter.info 159.223.11.114 smtpdri114.rolofter.info 159.223.11.115 smtpdri115.rolofter.info 159.223.11.116 smtpdri116.rolofter.info 159.223.11.117 smtpdri117.rolofter.info 159.223.11.118 smtpdri118.rolofter.info 159.223.11.119 smtpdri119.rolofter.info 159.223.11.120 smtpdri120.rolofter.info 159.223.11.121 smtpdri121.rolofter.info 159.223.11.122 smtpdri122.rolofter.info 159.223.11.123 smtpdri123.rolofter.info 159.223.11.124 smtpdri124.rolofter.info 159.223.11.125 smtpdri125.rolofter.info 159.223.11.126 smtpdri126.rolofter.info 159.223.11.127 smtpdri127.rolofter.info 159.223.11.128 smtpdri128.rolofter.info 159.223.11.129 smtpdri129.rolofter.info 159.223.11.130 smtpdri130.rolofter.info 159.223.11.131 smtpdri131.rolofter.info 159.223.11.132 smtpdri132.rolofter.info 159.223.11.133 smtpdri133.rolofter.info 159.223.11.134 smtpdri134.rolofter.info 159.223.11.135 smtpdri135.rolofter.info 159.223.11.136 smtpdri136.rolofter.info 159.223.11.137 smtpdri137.rolofter.info 159.223.11.138 smtpdri138.rolofter.info 159.223.11.139 smtpdri139.rolofter.info 159.223.11.140 smtpdri140.rolofter.info 159.223.11.141 smtpdri141.rolofter.info 159.223.11.142 smtpdri142.rolofter.info 159.223.11.143 smtpdri143.rolofter.info 159.223.11.144 smtpdri144.rolofter.info 159.223.11.145 smtpdri145.rolofter.info 159.223.11.146 smtpdri146.rolofter.info 159.223.11.147 smtpdri147.rolofter.info 159.223.11.148 smtpdri148.rolofter.info 159.223.11.149 smtpdri149.rolofter.info 159.223.11.150 smtpdri150.rolofter.info 159.223.11.151 smtpdri151.rolofter.info 159.223.11.152 smtpdri152.rolofter.info 159.223.11.153 smtpdri153.rolofter.info 159.223.11.154 smtpdri154.rolofter.info 159.223.11.155 smtpdri155.rolofter.info 159.223.11.156 smtpdri156.rolofter.info 159.223.11.157 smtpdri157.rolofter.info 159.223.11.158 smtpdri158.rolofter.info 159.223.11.159 smtpdri159.rolofter.info 159.223.11.160 smtpdri160.rolofter.info 159.223.11.161 smtpdri161.rolofter.info 159.223.11.162 smtpdri162.rolofter.info 159.223.11.163 smtpdri163.rolofter.info 159.223.11.164 smtpdri164.rolofter.info 159.223.11.165 smtpdri165.rolofter.info 159.223.11.166 smtpdri166.rolofter.info 159.223.11.167 smtpdri167.rolofter.info 159.223.11.168 smtpdri168.rolofter.info 159.223.11.169 smtpdri169.rolofter.info 159.223.11.170 smtpdri170.rolofter.info 159.223.11.171 smtpdri171.rolofter.info 159.223.11.172 smtpdri172.rolofter.info 159.223.11.173 smtpdri173.rolofter.info 159.223.11.174 smtpdri174.rolofter.info 159.223.11.175 smtpdri175.rolofter.info 159.223.11.176 smtpdri176.rolofter.info 159.223.11.177 smtpdri177.rolofter.info 159.223.11.178 smtpdri178.rolofter.info 159.223.11.179 smtpdri179.rolofter.info 159.223.11.180 smtpdri180.rolofter.info 159.223.11.181 smtpdri181.rolofter.info 159.223.11.182 smtpdri182.rolofter.info 159.223.11.183 smtpdri183.rolofter.info 159.223.11.184 smtpdri184.rolofter.info 159.223.11.185 smtpdri185.rolofter.info 159.223.11.186 smtpdri186.rolofter.info 159.223.11.187 smtpdri187.rolofter.info 159.223.11.188 smtpdri188.rolofter.info 159.223.11.189 smtpdri189.rolofter.info 159.223.11.190 smtpdri190.rolofter.info 159.223.11.191 smtpdri191.rolofter.info 159.223.11.192 smtpdri192.rolofter.info 159.223.11.193 smtpdri193.rolofter.info 159.223.11.194 smtpdri194.rolofter.info 159.223.11.195 smtpdri195.rolofter.info 159.223.11.196 smtpdri196.rolofter.info 159.223.11.197 smtpdri197.rolofter.info 159.223.11.198 smtpdri198.rolofter.info 159.223.11.199 smtpdri199.rolofter.info 159.223.11.200 smtpdri200.rolofter.info 159.223.11.201 smtpdri201.rolofter.info 159.223.11.202 smtpdri202.rolofter.info 159.223.11.203 smtpdri203.rolofter.info 159.223.11.204 smtpdri204.rolofter.info 159.223.11.205 smtpdri205.rolofter.info 159.223.11.206 smtpdri206.rolofter.info 159.223.11.207 smtpdri207.rolofter.info 159.223.11.208 smtpdri208.rolofter.info 159.223.11.209 smtpdri209.rolofter.info 159.223.11.210 smtpdri210.rolofter.info 159.223.11.211 smtpdri211.rolofter.info 159.223.11.212 smtpdri212.rolofter.info 159.223.11.213 smtpdri213.rolofter.info 159.223.11.214 smtpdri214.rolofter.info 159.223.11.215 smtpdri215.rolofter.info 159.223.11.216 smtpdri216.rolofter.info 159.223.11.217 smtpdri217.rolofter.info 159.223.11.218 smtpdri218.rolofter.info 159.223.11.219 smtpdri219.rolofter.info 159.223.11.220 smtpdri220.rolofter.info 159.223.11.221 smtpdri221.rolofter.info 159.223.11.222 smtpdri222.rolofter.info 159.223.11.223 smtpdri223.rolofter.info 159.223.11.224 smtpdri224.rolofter.info 159.223.11.225 smtpdri225.rolofter.info 159.223.11.226 smtpdri226.rolofter.info 159.223.11.227 smtpdri227.rolofter.info 159.223.11.228 smtpdri228.rolofter.info 159.223.11.229 smtpdri229.rolofter.info 159.223.11.230 smtpdri230.rolofter.info 159.223.11.231 smtpdri231.rolofter.info 159.223.11.232 smtpdri232.rolofter.info 159.223.11.233 smtpdri233.rolofter.info 159.223.11.234 smtpdri234.rolofter.info 159.223.11.235 smtpdri235.rolofter.info 159.223.11.236 smtpdri236.rolofter.info 159.223.11.237 smtpdri237.rolofter.info 159.223.11.238 smtpdri238.rolofter.info 159.223.11.239 smtpdri239.rolofter.info 159.223.11.240 smtpdri240.rolofter.info 159.223.11.241 smtpdri241.rolofter.info 159.223.11.242 smtpdri242.rolofter.info 159.223.11.243 smtpdri243.rolofter.info 159.223.11.244 smtpdri244.rolofter.info 159.223.11.245 smtpdri245.rolofter.info 159.223.11.246 smtpdri246.rolofter.info 159.223.11.247 smtpdri247.rolofter.info 159.223.11.248 smtpdri248.rolofter.info 159.223.11.249 smtpdri249.rolofter.info 159.223.11.250 smtpdri250.rolofter.info 159.223.11.251 smtpdri251.rolofter.info 159.223.11.252 smtpdri252.rolofter.info 159.223.11.253 smtpdri253.rolofter.info 159.223.12.2 abcd2.warbister.info 159.223.12.3 abcd3.warbister.info 159.223.12.4 abcd4.warbister.info 159.223.12.5 abcd5.warbister.info 159.223.12.6 abcd6.warbister.info 159.223.12.7 abcd7.warbister.info 159.223.12.8 abcd8.warbister.info 159.223.12.9 abcd9.warbister.info 159.223.12.10 abcd10.warbister.info 159.223.12.11 abcd11.warbister.info 159.223.12.12 abcd12.warbister.info 159.223.12.13 abcd13.warbister.info 159.223.12.14 abcd14.warbister.info 159.223.12.15 abcd15.warbister.info 159.223.12.16 abcd16.warbister.info 159.223.12.17 abcd17.warbister.info 159.223.12.18 abcd18.warbister.info 159.223.12.19 abcd19.warbister.info 159.223.12.20 abcd20.warbister.info 159.223.12.21 abcd21.warbister.info 159.223.12.22 abcd22.warbister.info 159.223.12.23 abcd23.warbister.info 159.223.12.24 abcd24.warbister.info 159.223.12.25 abcd25.warbister.info 159.223.12.26 abcd26.warbister.info 159.223.12.27 abcd27.warbister.info 159.223.12.28 abcd28.warbister.info 159.223.12.29 abcd29.warbister.info 159.223.12.30 abcd30.warbister.info 159.223.12.31 abcd31.warbister.info 159.223.12.32 abcd32.warbister.info 159.223.12.33 abcd33.warbister.info 159.223.12.34 abcd34.warbister.info 159.223.12.35 abcd35.warbister.info 159.223.12.36 abcd36.warbister.info 159.223.12.37 abcd37.warbister.info 159.223.12.38 abcd38.warbister.info 159.223.12.39 abcd39.warbister.info 159.223.12.40 abcd40.warbister.info 159.223.12.41 abcd41.warbister.info 159.223.12.42 abcd42.warbister.info 159.223.12.43 abcd43.warbister.info 159.223.12.44 abcd44.warbister.info 159.223.12.45 abcd45.warbister.info 159.223.12.46 abcd46.warbister.info 159.223.12.47 abcd47.warbister.info 159.223.12.48 abcd48.warbister.info 159.223.12.49 abcd49.warbister.info 159.223.12.50 abcd50.warbister.info 159.223.12.51 abcd51.warbister.info 159.223.12.52 abcd52.warbister.info 159.223.12.53 abcd53.warbister.info 159.223.12.54 abcd54.warbister.info 159.223.12.55 abcd55.warbister.info 159.223.12.56 abcd56.warbister.info 159.223.12.57 abcd57.warbister.info 159.223.12.58 abcd58.warbister.info 159.223.12.59 abcd59.warbister.info 159.223.12.60 abcd60.warbister.info 159.223.12.61 abcd61.warbister.info 159.223.12.62 abcd62.warbister.info 159.223.12.63 abcd63.warbister.info 159.223.12.64 abcd64.warbister.info 159.223.12.65 abcd65.warbister.info 159.223.12.66 abcd66.warbister.info 159.223.12.67 abcd67.warbister.info 159.223.12.68 abcd68.warbister.info 159.223.12.69 abcd69.warbister.info 159.223.12.70 abcd70.warbister.info 159.223.12.71 abcd71.warbister.info 159.223.12.72 abcd72.warbister.info 159.223.12.73 abcd73.warbister.info 159.223.12.74 abcd74.warbister.info 159.223.12.75 abcd75.warbister.info 159.223.12.76 abcd76.warbister.info 159.223.12.77 abcd77.warbister.info 159.223.12.78 abcd78.warbister.info 159.223.12.79 abcd79.warbister.info 159.223.12.80 abcd80.warbister.info 159.223.12.81 abcd81.warbister.info 159.223.12.82 abcd82.warbister.info 159.223.12.83 abcd83.warbister.info 159.223.12.84 abcd84.warbister.info 159.223.12.85 abcd85.warbister.info 159.223.12.86 abcd86.warbister.info 159.223.12.87 abcd87.warbister.info 159.223.12.88 abcd88.warbister.info 159.223.12.89 abcd89.warbister.info 159.223.12.90 abcd90.warbister.info 159.223.12.91 abcd91.warbister.info 159.223.12.92 abcd92.warbister.info 159.223.12.93 abcd93.warbister.info 159.223.12.94 abcd94.warbister.info 159.223.12.95 abcd95.warbister.info 159.223.12.96 abcd96.warbister.info 159.223.12.97 abcd97.warbister.info 159.223.12.98 abcd98.warbister.info 159.223.12.99 abcd99.warbister.info 159.223.12.100 abcd100.warbister.info 159.223.12.101 abcd101.warbister.info 159.223.12.102 abcd102.warbister.info 159.223.12.103 abcd103.warbister.info 159.223.12.104 abcd104.warbister.info 159.223.12.105 abcd105.warbister.info 159.223.12.106 abcd106.warbister.info 159.223.12.107 abcd107.warbister.info 159.223.12.108 abcd108.warbister.info 159.223.12.109 abcd109.warbister.info 159.223.12.110 abcd110.warbister.info 159.223.12.111 abcd111.warbister.info 159.223.12.112 abcd112.warbister.info 159.223.12.113 abcd113.warbister.info 159.223.12.114 abcd114.warbister.info 159.223.12.115 abcd115.warbister.info 159.223.12.116 abcd116.warbister.info 159.223.12.117 abcd117.warbister.info 159.223.12.118 abcd118.warbister.info 159.223.12.119 abcd119.warbister.info 159.223.12.120 abcd120.warbister.info 159.223.12.121 abcd121.warbister.info 159.223.12.122 abcd122.warbister.info 159.223.12.123 abcd123.warbister.info 159.223.12.124 abcd124.warbister.info 159.223.12.125 abcd125.warbister.info 159.223.12.126 abcd126.warbister.info 159.223.12.127 abcd127.warbister.info 159.223.12.128 abcd128.warbister.info 159.223.12.129 abcd129.warbister.info 159.223.12.130 abcd130.warbister.info 159.223.12.131 abcd131.warbister.info 159.223.12.132 abcd132.warbister.info 159.223.12.133 abcd133.warbister.info 159.223.12.134 abcd134.warbister.info 159.223.12.135 abcd135.warbister.info 159.223.12.136 abcd136.warbister.info 159.223.12.137 abcd137.warbister.info 159.223.12.138 abcd138.warbister.info 159.223.12.139 abcd139.warbister.info 159.223.12.140 abcd140.warbister.info 159.223.12.141 abcd141.warbister.info 159.223.12.142 abcd142.warbister.info 159.223.12.143 abcd143.warbister.info 159.223.12.144 abcd144.warbister.info 159.223.12.145 abcd145.warbister.info 159.223.12.146 abcd146.warbister.info 159.223.12.147 abcd147.warbister.info 159.223.12.148 abcd148.warbister.info 159.223.12.149 abcd149.warbister.info 159.223.12.150 abcd150.warbister.info 159.223.12.151 abcd151.warbister.info 159.223.12.152 abcd152.warbister.info 159.223.12.153 abcd153.warbister.info 159.223.12.154 abcd154.warbister.info 159.223.12.155 abcd155.warbister.info 159.223.12.156 abcd156.warbister.info 159.223.12.157 abcd157.warbister.info 159.223.12.158 abcd158.warbister.info 159.223.12.159 abcd159.warbister.info 159.223.12.160 abcd160.warbister.info 159.223.12.161 abcd161.warbister.info 159.223.12.162 abcd162.warbister.info 159.223.12.163 abcd163.warbister.info 159.223.12.164 abcd164.warbister.info 159.223.12.165 abcd165.warbister.info 159.223.12.166 abcd166.warbister.info 159.223.12.167 abcd167.warbister.info 159.223.12.168 abcd168.warbister.info 159.223.12.169 abcd169.warbister.info 159.223.12.170 abcd170.warbister.info 159.223.12.171 abcd171.warbister.info 159.223.12.172 abcd172.warbister.info 159.223.12.173 abcd173.warbister.info 159.223.12.174 abcd174.warbister.info 159.223.12.175 abcd175.warbister.info 159.223.12.176 abcd176.warbister.info 159.223.12.177 abcd177.warbister.info 159.223.12.178 abcd178.warbister.info 159.223.12.179 abcd179.warbister.info 159.223.12.180 abcd180.warbister.info 159.223.12.181 abcd181.warbister.info 159.223.12.182 abcd182.warbister.info 159.223.12.183 abcd183.warbister.info 159.223.12.184 abcd184.warbister.info 159.223.12.185 abcd185.warbister.info 159.223.12.186 abcd186.warbister.info 159.223.12.187 abcd187.warbister.info 159.223.12.188 abcd188.warbister.info 159.223.12.189 abcd189.warbister.info 159.223.12.190 abcd190.warbister.info 159.223.12.191 abcd191.warbister.info 159.223.12.192 abcd192.warbister.info 159.223.12.193 abcd193.warbister.info 159.223.12.194 abcd194.warbister.info 159.223.12.195 abcd195.warbister.info 159.223.12.196 abcd196.warbister.info 159.223.12.197 abcd197.warbister.info 159.223.12.198 abcd198.warbister.info 159.223.12.199 abcd199.warbister.info 159.223.12.200 abcd200.warbister.info 159.223.12.201 abcd201.warbister.info 159.223.12.202 abcd202.warbister.info 159.223.12.203 abcd203.warbister.info 159.223.12.204 abcd204.warbister.info 159.223.12.205 abcd205.warbister.info 159.223.12.206 abcd206.warbister.info 159.223.12.207 abcd207.warbister.info 159.223.12.208 abcd208.warbister.info 159.223.12.209 abcd209.warbister.info 159.223.12.210 abcd210.warbister.info 159.223.12.211 abcd211.warbister.info 159.223.12.212 abcd212.warbister.info 159.223.12.213 abcd213.warbister.info 159.223.12.214 abcd214.warbister.info 159.223.12.215 abcd215.warbister.info 159.223.12.216 abcd216.warbister.info 159.223.12.217 abcd217.warbister.info 159.223.12.218 abcd218.warbister.info 159.223.12.219 abcd219.warbister.info 159.223.12.220 abcd220.warbister.info 159.223.12.221 abcd221.warbister.info 159.223.12.222 abcd222.warbister.info 159.223.12.223 abcd223.warbister.info 159.223.12.224 abcd224.warbister.info 159.223.12.225 abcd225.warbister.info 159.223.12.226 abcd226.warbister.info 159.223.12.227 abcd227.warbister.info 159.223.12.228 abcd228.warbister.info 159.223.12.229 abcd229.warbister.info 159.223.12.230 abcd230.warbister.info 159.223.12.231 abcd231.warbister.info 159.223.12.232 abcd232.warbister.info 159.223.12.233 abcd233.warbister.info 159.223.12.234 abcd234.warbister.info 159.223.12.235 abcd235.warbister.info 159.223.12.236 abcd236.warbister.info 159.223.12.237 abcd237.warbister.info 159.223.12.238 abcd238.warbister.info 159.223.12.239 abcd239.warbister.info 159.223.12.240 abcd240.warbister.info 159.223.12.241 abcd241.warbister.info 159.223.12.242 abcd242.warbister.info 159.223.12.243 abcd243.warbister.info 159.223.12.244 abcd244.warbister.info 159.223.12.245 abcd245.warbister.info 159.223.12.246 abcd246.warbister.info 159.223.12.247 abcd247.warbister.info 159.223.12.248 abcd248.warbister.info 159.223.12.249 abcd249.warbister.info 159.223.12.250 abcd250.warbister.info 159.223.12.251 abcd251.warbister.info 159.223.12.252 abcd252.warbister.info 159.223.12.253 abcd253.warbister.info 159.223.13.2 advocatefulltime.com 159.223.13.3 kiele.advocatefulltime.com 159.223.13.4 volpe.advocatefulltime.com 159.223.13.5 polygonal.advocatefulltime.com 159.223.13.6 electrocardiogram.advocatefulltime.com 159.223.13.7 cabeza.advocatefulltime.com 159.223.13.8 waco.advocatefulltime.com 159.223.13.9 hammersohn.advocatefulltime.com 159.223.13.10 barbarrigo.advocatefulltime.com 159.223.13.11 sammi.advocatefulltime.com 159.223.13.12 diversion.advocatefulltime.com 159.223.13.13 clerissa.advocatefulltime.com ... From rfg at tristatelogic.com Wed Mar 30 15:58:27 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 30 Mar 2011 13:58:27 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? Message-ID: <33182.1301518707@tristatelogic.com> As I already mentioned, 159.223.0.0/16, which is actually registered to the Hoechst Celanese Corporation, has quite obviously been hijacked and is being used & abused by snowshoe spammers as we speak. And Spamhaus, at least, has known about this for more than three months already. What Spamhaus apparently didn't/doesn't know is that Hoechst Celanese has/had _another_ /16 that they abandoned also, i.e. 148.163.0.0/16 and that the same spammers have hijacked this one too, and that they are, quite apparently, using and abusing this one also. (I don't why Spamhaus didn't list this /16 as hijacked also. All I can say is that I apparently do research on cases like these which is a bit deeper than their's.) Anyway, this case is a lot more remarkable than the case of 159.223.0.0/16 for the simple reason that it isn't just some podunk little NSP that is announcing the routes to this one. Nope, in this case the company that's responsible for announcing the routes to the hijacked space would appear to be Level3. (I encourage people to double-check me on that. But I'm pretty sure that I have NOT made a mistake here.) So, um, assuming that I am correct, who the bleep was it, inside of Level3, who thought that it would be a Swell Idea to start routing hijacked /16s for snowshoe spammers? Inquiring minds want to know. (BTW, strangely, up until last night, ARIN whois knew about 148.163.0.0/16. But it seems to have developed a case of Alzheimer's overnight with respect to this one specific block. As Spock would say "Facinating." But I still have a copy of the relevant ARIN whois record for this block from last nite, and yes, it was/is registered to Hoechst Celanese Corporation.) Regards, rfg P.S. Some evidence suggests that the company that may actually be most directly responsible for both of these two big-time /16 hijackings is this one: http://www.logicnext.com/ This is apparently a non-descript little Indian "outsourcing" company trying hard to make it look like they are more than they are. There is a definite tie-in between this company and the person or persons or entity that is pro- viding reverse DNS for the various spammer snowshoe blocks within both 159.223.0.0/16 and 148.163.0.0/16. But I'm not going to elaborate further. P.P.S. Here is some of the spammer snowshoe crap that currently exists within 148.163.0.0/16: 148.163.1.3 mail.touchscreen-gloves.net 148.163.1.11 mail11.touchscreen-gloves.net 148.163.1.12 mail12.touchscreen-gloves.net 148.163.1.13 mail13.touchscreen-gloves.net 148.163.1.14 mail14.touchscreen-gloves.net 148.163.1.15 mail15.touchscreen-gloves.net 148.163.1.16 mail16.touchscreen-gloves.net 148.163.1.17 mail17.touchscreen-gloves.net 148.163.1.18 mail18.touchscreen-gloves.net 148.163.1.19 mail19.touchscreen-gloves.net 148.163.1.20 mail20.touchscreen-gloves.net 148.163.1.21 mail21.touchscreen-gloves.net 148.163.1.22 mail22.touchscreen-gloves.net 148.163.1.23 mail23.touchscreen-gloves.net 148.163.1.24 mail24.touchscreen-gloves.net 148.163.1.25 mail25.touchscreen-gloves.net 148.163.1.26 mail26.touchscreen-gloves.net 148.163.1.27 mail27.touchscreen-gloves.net 148.163.1.28 mail28.touchscreen-gloves.net 148.163.1.29 mail29.touchscreen-gloves.net 148.163.1.30 mail30.touchscreen-gloves.net 148.163.1.31 mail31.touchscreen-gloves.net 148.163.1.32 mail32.touchscreen-gloves.net 148.163.1.33 mail33.touchscreen-gloves.net 148.163.1.34 mail34.touchscreen-gloves.net 148.163.1.35 mail35.touchscreen-gloves.net 148.163.1.36 mail36.touchscreen-gloves.net 148.163.1.37 mail37.touchscreen-gloves.net 148.163.1.38 mail38.touchscreen-gloves.net 148.163.1.39 mail39.touchscreen-gloves.net 148.163.1.40 mail40.touchscreen-gloves.net 148.163.1.41 mail41.touchscreen-gloves.net 148.163.1.42 mail42.touchscreen-gloves.net 148.163.1.43 mail43.touchscreen-gloves.net 148.163.1.44 mail44.touchscreen-gloves.net 148.163.1.45 mail45.touchscreen-gloves.net 148.163.1.46 mail46.touchscreen-gloves.net 148.163.1.47 mail47.touchscreen-gloves.net 148.163.1.48 mail48.touchscreen-gloves.net 148.163.1.49 mail49.touchscreen-gloves.net 148.163.1.50 mail50.touchscreen-gloves.net 148.163.1.51 mail51.touchscreen-gloves.net 148.163.1.52 mail52.touchscreen-gloves.net 148.163.1.53 mail53.touchscreen-gloves.net 148.163.1.54 mail54.touchscreen-gloves.net 148.163.1.55 mail55.touchscreen-gloves.net 148.163.1.56 mail56.touchscreen-gloves.net 148.163.1.57 mail57.touchscreen-gloves.net 148.163.1.58 mail58.touchscreen-gloves.net 148.163.1.59 mail59.touchscreen-gloves.net 148.163.1.60 mail60.touchscreen-gloves.net 148.163.1.61 mail61.touchscreen-gloves.net 148.163.1.62 mail62.touchscreen-gloves.net 148.163.1.63 mail63.touchscreen-gloves.net 148.163.1.64 mail64.touchscreen-gloves.net 148.163.1.65 mail65.touchscreen-gloves.net 148.163.1.66 mail66.touchscreen-gloves.net 148.163.1.67 mail67.touchscreen-gloves.net 148.163.1.68 mail68.touchscreen-gloves.net 148.163.1.69 mail69.touchscreen-gloves.net 148.163.1.70 mail70.touchscreen-gloves.net 148.163.1.71 mail71.touchscreen-gloves.net 148.163.1.72 mail72.touchscreen-gloves.net 148.163.1.73 mail73.touchscreen-gloves.net 148.163.1.74 mail74.touchscreen-gloves.net 148.163.1.75 mail75.touchscreen-gloves.net 148.163.1.76 mail76.touchscreen-gloves.net 148.163.1.77 mail77.touchscreen-gloves.net 148.163.1.78 mail78.touchscreen-gloves.net 148.163.1.79 mail79.touchscreen-gloves.net 148.163.1.80 mail80.touchscreen-gloves.net 148.163.1.81 mail81.touchscreen-gloves.net 148.163.1.82 mail82.touchscreen-gloves.net 148.163.1.83 mail83.touchscreen-gloves.net 148.163.1.84 mail84.touchscreen-gloves.net 148.163.1.85 mail85.touchscreen-gloves.net 148.163.1.86 mail86.touchscreen-gloves.net 148.163.1.87 mail87.touchscreen-gloves.net 148.163.1.88 mail88.touchscreen-gloves.net 148.163.1.89 mail89.touchscreen-gloves.net 148.163.1.90 mail90.touchscreen-gloves.net 148.163.1.91 mail91.touchscreen-gloves.net 148.163.1.92 mail92.touchscreen-gloves.net 148.163.1.93 mail93.touchscreen-gloves.net 148.163.1.94 mail94.touchscreen-gloves.net 148.163.1.95 mail95.touchscreen-gloves.net 148.163.1.96 mail96.touchscreen-gloves.net 148.163.1.97 mail97.touchscreen-gloves.net 148.163.1.98 mail98.touchscreen-gloves.net 148.163.1.99 mail99.touchscreen-gloves.net 148.163.1.100 mail100.touchscreen-gloves.net 148.163.1.101 mail101.touchscreen-gloves.net 148.163.1.102 mail102.touchscreen-gloves.net 148.163.1.103 mail103.touchscreen-gloves.net 148.163.1.104 mail104.touchscreen-gloves.net 148.163.1.105 mail105.touchscreen-gloves.net 148.163.1.106 mail106.touchscreen-gloves.net 148.163.1.107 mail107.touchscreen-gloves.net 148.163.1.108 mail108.touchscreen-gloves.net 148.163.1.109 mail109.touchscreen-gloves.net 148.163.1.110 mail110.touchscreen-gloves.net 148.163.1.111 mail111.touchscreen-gloves.net 148.163.1.112 mail112.touchscreen-gloves.net 148.163.1.113 mail113.touchscreen-gloves.net 148.163.1.114 mail114.touchscreen-gloves.net 148.163.1.115 mail115.touchscreen-gloves.net 148.163.1.116 mail116.touchscreen-gloves.net 148.163.1.117 mail117.touchscreen-gloves.net 148.163.1.118 mail118.touchscreen-gloves.net 148.163.1.119 mail119.touchscreen-gloves.net 148.163.1.120 mail120.touchscreen-gloves.net 148.163.1.121 mail121.touchscreen-gloves.net 148.163.1.122 mail122.touchscreen-gloves.net 148.163.1.123 mail123.touchscreen-gloves.net 148.163.1.124 mail124.touchscreen-gloves.net 148.163.1.125 mail125.touchscreen-gloves.net 148.163.1.126 mail126.touchscreen-gloves.net 148.163.1.127 mail127.touchscreen-gloves.net 148.163.1.128 mail128.touchscreen-gloves.net 148.163.1.129 mail129.touchscreen-gloves.net 148.163.1.130 mail130.touchscreen-gloves.net 148.163.1.131 mail131.touchscreen-gloves.net 148.163.1.132 mail132.touchscreen-gloves.net 148.163.1.133 mail133.touchscreen-gloves.net 148.163.1.134 mail134.touchscreen-gloves.net 148.163.1.135 mail135.touchscreen-gloves.net 148.163.1.136 mail136.touchscreen-gloves.net 148.163.1.137 mail137.touchscreen-gloves.net 148.163.1.138 mail138.touchscreen-gloves.net 148.163.1.139 mail139.touchscreen-gloves.net 148.163.1.140 mail140.touchscreen-gloves.net 148.163.1.141 mail141.touchscreen-gloves.net 148.163.1.142 mail142.touchscreen-gloves.net 148.163.1.143 mail143.touchscreen-gloves.net 148.163.1.144 mail144.touchscreen-gloves.net 148.163.1.145 mail145.touchscreen-gloves.net 148.163.1.146 mail146.touchscreen-gloves.net 148.163.1.147 mail147.touchscreen-gloves.net 148.163.1.148 mail148.touchscreen-gloves.net 148.163.1.149 mail149.touchscreen-gloves.net 148.163.1.150 mail150.touchscreen-gloves.net 148.163.1.151 mail151.touchscreen-gloves.net 148.163.1.152 mail152.touchscreen-gloves.net 148.163.1.153 mail153.touchscreen-gloves.net 148.163.1.154 mail154.touchscreen-gloves.net 148.163.1.155 mail155.touchscreen-gloves.net 148.163.1.156 mail156.touchscreen-gloves.net 148.163.1.157 mail157.touchscreen-gloves.net 148.163.1.158 mail158.touchscreen-gloves.net 148.163.1.159 mail159.touchscreen-gloves.net 148.163.1.160 mail160.touchscreen-gloves.net 148.163.1.161 mail161.touchscreen-gloves.net 148.163.1.162 mail162.touchscreen-gloves.net 148.163.1.163 mail163.touchscreen-gloves.net 148.163.1.164 mail164.touchscreen-gloves.net 148.163.1.165 mail165.touchscreen-gloves.net 148.163.1.166 mail166.touchscreen-gloves.net 148.163.1.167 mail167.touchscreen-gloves.net 148.163.1.168 mail168.touchscreen-gloves.net 148.163.1.169 mail169.touchscreen-gloves.net 148.163.1.170 mail170.touchscreen-gloves.net 148.163.1.171 mail171.touchscreen-gloves.net 148.163.1.172 mail172.touchscreen-gloves.net 148.163.1.173 mail173.touchscreen-gloves.net 148.163.1.174 mail174.touchscreen-gloves.net 148.163.1.175 mail175.touchscreen-gloves.net 148.163.1.176 mail176.touchscreen-gloves.net 148.163.1.177 mail177.touchscreen-gloves.net 148.163.1.178 mail178.touchscreen-gloves.net 148.163.1.179 mail179.touchscreen-gloves.net 148.163.1.180 mail180.touchscreen-gloves.net 148.163.1.181 mail181.touchscreen-gloves.net 148.163.1.182 mail182.touchscreen-gloves.net 148.163.1.183 mail183.touchscreen-gloves.net 148.163.1.184 mail184.touchscreen-gloves.net 148.163.1.185 mail185.touchscreen-gloves.net 148.163.1.186 mail186.touchscreen-gloves.net 148.163.1.187 mail187.touchscreen-gloves.net 148.163.1.188 mail188.touchscreen-gloves.net 148.163.1.189 mail189.touchscreen-gloves.net 148.163.1.190 mail190.touchscreen-gloves.net 148.163.1.191 mail191.touchscreen-gloves.net 148.163.1.192 mail192.touchscreen-gloves.net 148.163.1.193 mail193.touchscreen-gloves.net 148.163.1.194 mail194.touchscreen-gloves.net 148.163.1.195 mail195.touchscreen-gloves.net 148.163.1.196 mail196.touchscreen-gloves.net 148.163.1.197 mail197.touchscreen-gloves.net 148.163.1.198 mail198.touchscreen-gloves.net 148.163.1.199 mail199.touchscreen-gloves.net 148.163.1.200 mail200.touchscreen-gloves.net 148.163.1.201 mail201.touchscreen-gloves.net 148.163.1.202 mail202.touchscreen-gloves.net 148.163.1.203 mail203.touchscreen-gloves.net 148.163.1.204 mail204.touchscreen-gloves.net 148.163.1.205 mail205.touchscreen-gloves.net 148.163.1.206 mail206.touchscreen-gloves.net 148.163.1.207 mail207.touchscreen-gloves.net 148.163.1.208 mail208.touchscreen-gloves.net 148.163.1.209 mail209.touchscreen-gloves.net 148.163.1.210 mail210.touchscreen-gloves.net 148.163.1.211 mail211.touchscreen-gloves.net 148.163.1.212 mail212.touchscreen-gloves.net 148.163.1.213 mail213.touchscreen-gloves.net 148.163.1.214 mail214.touchscreen-gloves.net 148.163.1.215 mail215.touchscreen-gloves.net 148.163.1.216 mail216.touchscreen-gloves.net 148.163.1.217 mail217.touchscreen-gloves.net 148.163.1.218 mail218.touchscreen-gloves.net 148.163.1.219 mail219.touchscreen-gloves.net 148.163.1.220 mail220.touchscreen-gloves.net 148.163.1.221 mail221.touchscreen-gloves.net 148.163.1.222 mail222.touchscreen-gloves.net 148.163.1.223 mail223.touchscreen-gloves.net 148.163.1.224 mail224.touchscreen-gloves.net 148.163.1.225 mail225.touchscreen-gloves.net 148.163.1.226 mail226.touchscreen-gloves.net 148.163.1.227 mail227.touchscreen-gloves.net 148.163.1.228 mail228.touchscreen-gloves.net 148.163.1.229 mail229.touchscreen-gloves.net 148.163.1.230 mail230.touchscreen-gloves.net 148.163.1.231 mail231.touchscreen-gloves.net 148.163.1.232 mail232.touchscreen-gloves.net 148.163.1.233 mail233.touchscreen-gloves.net 148.163.1.234 mail234.touchscreen-gloves.net 148.163.1.235 mail235.touchscreen-gloves.net 148.163.1.236 mail236.touchscreen-gloves.net 148.163.1.237 mail237.touchscreen-gloves.net 148.163.1.238 mail238.touchscreen-gloves.net 148.163.1.239 mail239.touchscreen-gloves.net 148.163.1.240 mail240.touchscreen-gloves.net 148.163.1.241 mail241.touchscreen-gloves.net 148.163.1.242 mail242.touchscreen-gloves.net 148.163.1.243 mail243.touchscreen-gloves.net 148.163.1.244 mail244.touchscreen-gloves.net 148.163.1.245 mail245.touchscreen-gloves.net 148.163.1.246 mail246.touchscreen-gloves.net 148.163.1.247 mail247.touchscreen-gloves.net 148.163.1.248 mail248.touchscreen-gloves.net 148.163.1.249 mail249.touchscreen-gloves.net 148.163.1.250 mail250.touchscreen-gloves.net 148.163.1.251 mail251.touchscreen-gloves.net 148.163.1.252 mail252.touchscreen-gloves.net 148.163.1.253 mail253.touchscreen-gloves.net 148.163.1.254 mail254.touchscreen-gloves.net 148.163.2.4 mail.ipadgloves.net 148.163.2.11 mail11.ipadgloves.net 148.163.2.12 mail12.ipadgloves.net 148.163.2.13 mail13.ipadgloves.net 148.163.2.14 mail14.ipadgloves.net 148.163.2.15 mail15.ipadgloves.net 148.163.2.16 mail16.ipadgloves.net 148.163.2.17 mail17.ipadgloves.net 148.163.2.18 mail18.ipadgloves.net 148.163.2.19 mail19.ipadgloves.net 148.163.2.20 mail20.ipadgloves.net 148.163.2.21 mail21.ipadgloves.net 148.163.2.22 mail22.ipadgloves.net 148.163.2.23 mail23.ipadgloves.net 148.163.2.24 mail24.ipadgloves.net 148.163.2.25 mail25.ipadgloves.net 148.163.2.26 mail26.ipadgloves.net 148.163.2.27 mail27.ipadgloves.net 148.163.2.28 mail28.ipadgloves.net 148.163.2.29 mail29.ipadgloves.net 148.163.2.30 mail30.ipadgloves.net 148.163.2.31 mail31.ipadgloves.net 148.163.2.32 mail32.ipadgloves.net 148.163.2.33 mail33.ipadgloves.net 148.163.2.34 mail34.ipadgloves.net 148.163.2.35 mail35.ipadgloves.net 148.163.2.36 mail36.ipadgloves.net 148.163.2.37 mail37.ipadgloves.net 148.163.2.38 mail38.ipadgloves.net 148.163.2.39 mail39.ipadgloves.net 148.163.2.40 mail40.ipadgloves.net 148.163.2.41 mail41.ipadgloves.net 148.163.2.42 mail42.ipadgloves.net 148.163.2.43 mail43.ipadgloves.net 148.163.2.44 mail44.ipadgloves.net 148.163.2.45 mail45.ipadgloves.net 148.163.2.46 mail46.ipadgloves.net 148.163.2.47 mail47.ipadgloves.net 148.163.2.48 mail48.ipadgloves.net 148.163.2.49 mail49.ipadgloves.net 148.163.2.50 mail50.ipadgloves.net 148.163.2.51 mail51.ipadgloves.net 148.163.2.52 mail52.ipadgloves.net 148.163.2.53 mail53.ipadgloves.net 148.163.2.54 mail54.ipadgloves.net 148.163.2.55 mail55.ipadgloves.net 148.163.2.56 mail56.ipadgloves.net 148.163.2.57 mail57.ipadgloves.net 148.163.2.58 mail58.ipadgloves.net 148.163.2.59 mail59.ipadgloves.net 148.163.2.60 mail60.ipadgloves.net 148.163.2.61 mail61.ipadgloves.net 148.163.2.62 mail62.ipadgloves.net 148.163.2.63 mail63.ipadgloves.net 148.163.2.64 mail64.ipadgloves.net 148.163.2.65 mail65.ipadgloves.net 148.163.2.66 mail66.ipadgloves.net 148.163.2.67 mail67.ipadgloves.net 148.163.2.68 mail68.ipadgloves.net 148.163.2.69 mail69.ipadgloves.net 148.163.2.70 mail70.ipadgloves.net 148.163.2.71 mail71.ipadgloves.net 148.163.2.72 mail72.ipadgloves.net 148.163.2.73 mail73.ipadgloves.net 148.163.2.74 mail74.ipadgloves.net 148.163.2.75 mail75.ipadgloves.net 148.163.2.76 mail76.ipadgloves.net 148.163.2.77 mail77.ipadgloves.net 148.163.2.78 mail78.ipadgloves.net 148.163.2.79 mail79.ipadgloves.net 148.163.2.80 mail80.ipadgloves.net 148.163.2.81 mail81.ipadgloves.net 148.163.2.82 mail82.ipadgloves.net 148.163.2.83 mail83.ipadgloves.net 148.163.2.84 mail84.ipadgloves.net 148.163.2.85 mail85.ipadgloves.net 148.163.2.86 mail86.ipadgloves.net 148.163.2.87 mail87.ipadgloves.net 148.163.2.88 mail88.ipadgloves.net 148.163.2.89 mail89.ipadgloves.net 148.163.2.90 mail90.ipadgloves.net 148.163.2.91 mail91.ipadgloves.net 148.163.2.92 mail92.ipadgloves.net 148.163.2.93 mail93.ipadgloves.net 148.163.2.94 mail94.ipadgloves.net 148.163.2.95 mail95.ipadgloves.net 148.163.2.96 mail96.ipadgloves.net 148.163.2.97 mail97.ipadgloves.net 148.163.2.98 mail98.ipadgloves.net 148.163.2.99 mail99.ipadgloves.net 148.163.2.100 mail100.ipadgloves.net 148.163.2.101 mail101.ipadgloves.net 148.163.2.102 mail102.ipadgloves.net 148.163.2.103 mail103.ipadgloves.net 148.163.2.104 mail104.ipadgloves.net 148.163.2.105 mail105.ipadgloves.net 148.163.2.106 mail106.ipadgloves.net 148.163.2.107 mail107.ipadgloves.net 148.163.2.108 mail108.ipadgloves.net 148.163.2.109 mail109.ipadgloves.net 148.163.2.110 mail110.ipadgloves.net 148.163.2.111 mail111.ipadgloves.net 148.163.2.112 mail112.ipadgloves.net 148.163.2.113 mail113.ipadgloves.net 148.163.2.114 mail114.ipadgloves.net 148.163.2.115 mail115.ipadgloves.net 148.163.2.116 mail116.ipadgloves.net 148.163.2.117 mail117.ipadgloves.net 148.163.2.118 mail118.ipadgloves.net 148.163.2.119 mail119.ipadgloves.net 148.163.2.120 mail120.ipadgloves.net 148.163.2.121 mail121.ipadgloves.net 148.163.2.122 mail122.ipadgloves.net 148.163.2.123 mail123.ipadgloves.net 148.163.2.124 mail124.ipadgloves.net 148.163.2.125 mail125.ipadgloves.net 148.163.2.126 mail126.ipadgloves.net 148.163.2.127 mail127.ipadgloves.net 148.163.2.128 mail128.ipadgloves.net 148.163.2.129 mail129.ipadgloves.net 148.163.2.130 mail130.ipadgloves.net 148.163.2.131 mail131.ipadgloves.net 148.163.2.132 mail132.ipadgloves.net 148.163.2.133 mail133.ipadgloves.net 148.163.2.134 mail134.ipadgloves.net 148.163.2.135 mail135.ipadgloves.net 148.163.2.136 mail136.ipadgloves.net 148.163.2.137 mail137.ipadgloves.net 148.163.2.138 mail138.ipadgloves.net 148.163.2.139 mail139.ipadgloves.net 148.163.2.140 mail140.ipadgloves.net 148.163.2.141 mail141.ipadgloves.net 148.163.2.142 mail142.ipadgloves.net 148.163.2.143 mail143.ipadgloves.net 148.163.2.144 mail144.ipadgloves.net 148.163.2.145 mail145.ipadgloves.net 148.163.2.146 mail146.ipadgloves.net 148.163.2.147 mail147.ipadgloves.net 148.163.2.148 mail148.ipadgloves.net 148.163.2.149 mail149.ipadgloves.net 148.163.2.150 mail150.ipadgloves.net 148.163.2.151 mail151.ipadgloves.net 148.163.2.152 mail152.ipadgloves.net 148.163.2.153 mail153.ipadgloves.net 148.163.2.154 mail154.ipadgloves.net 148.163.2.155 mail155.ipadgloves.net 148.163.2.156 mail156.ipadgloves.net 148.163.2.157 mail157.ipadgloves.net 148.163.2.158 mail158.ipadgloves.net 148.163.2.159 mail159.ipadgloves.net 148.163.2.160 mail160.ipadgloves.net 148.163.2.161 mail161.ipadgloves.net 148.163.2.162 mail162.ipadgloves.net 148.163.2.163 mail163.ipadgloves.net 148.163.2.164 mail164.ipadgloves.net 148.163.2.165 mail165.ipadgloves.net 148.163.2.166 mail166.ipadgloves.net 148.163.2.167 mail167.ipadgloves.net 148.163.2.168 mail168.ipadgloves.net 148.163.2.169 mail169.ipadgloves.net 148.163.2.170 mail170.ipadgloves.net 148.163.2.171 mail171.ipadgloves.net 148.163.2.172 mail172.ipadgloves.net 148.163.2.173 mail173.ipadgloves.net 148.163.2.174 mail174.ipadgloves.net 148.163.2.175 mail175.ipadgloves.net 148.163.2.176 mail176.ipadgloves.net 148.163.2.177 mail177.ipadgloves.net 148.163.2.178 mail178.ipadgloves.net 148.163.2.179 mail179.ipadgloves.net 148.163.2.180 mail180.ipadgloves.net 148.163.2.181 mail181.ipadgloves.net 148.163.2.182 mail182.ipadgloves.net 148.163.2.183 mail183.ipadgloves.net 148.163.2.184 mail184.ipadgloves.net 148.163.2.185 mail185.ipadgloves.net 148.163.2.186 mail186.ipadgloves.net 148.163.2.187 mail187.ipadgloves.net 148.163.2.188 mail188.ipadgloves.net 148.163.2.189 mail189.ipadgloves.net 148.163.2.190 mail190.ipadgloves.net 148.163.2.191 mail191.ipadgloves.net 148.163.2.192 mail192.ipadgloves.net 148.163.2.193 mail193.ipadgloves.net 148.163.2.194 mail194.ipadgloves.net 148.163.2.195 mail195.ipadgloves.net 148.163.2.196 mail196.ipadgloves.net 148.163.2.197 mail197.ipadgloves.net 148.163.2.198 mail198.ipadgloves.net 148.163.2.199 mail199.ipadgloves.net 148.163.2.200 mail200.ipadgloves.net 148.163.2.201 mail201.ipadgloves.net 148.163.2.202 mail202.ipadgloves.net 148.163.2.203 mail203.ipadgloves.net 148.163.2.204 mail204.ipadgloves.net 148.163.2.205 mail205.ipadgloves.net 148.163.2.206 mail206.ipadgloves.net 148.163.2.207 mail207.ipadgloves.net 148.163.2.208 mail208.ipadgloves.net 148.163.2.209 mail209.ipadgloves.net 148.163.2.210 mail210.ipadgloves.net 148.163.2.211 mail211.ipadgloves.net 148.163.2.212 mail212.ipadgloves.net 148.163.2.213 mail213.ipadgloves.net 148.163.2.214 mail214.ipadgloves.net 148.163.2.215 mail215.ipadgloves.net 148.163.2.216 mail216.ipadgloves.net 148.163.2.217 mail217.ipadgloves.net 148.163.2.218 mail218.ipadgloves.net 148.163.2.219 mail219.ipadgloves.net 148.163.2.220 mail220.ipadgloves.net 148.163.2.221 mail221.ipadgloves.net 148.163.2.222 mail222.ipadgloves.net 148.163.2.223 mail223.ipadgloves.net 148.163.2.224 mail224.ipadgloves.net 148.163.2.225 mail225.ipadgloves.net 148.163.2.226 mail226.ipadgloves.net 148.163.2.227 mail227.ipadgloves.net 148.163.2.228 mail228.ipadgloves.net 148.163.2.229 mail229.ipadgloves.net 148.163.2.230 mail230.ipadgloves.net 148.163.2.231 mail231.ipadgloves.net 148.163.2.232 mail232.ipadgloves.net 148.163.2.233 mail233.ipadgloves.net 148.163.2.234 mail234.ipadgloves.net 148.163.2.235 mail235.ipadgloves.net 148.163.2.236 mail236.ipadgloves.net 148.163.2.237 mail237.ipadgloves.net 148.163.2.238 mail238.ipadgloves.net 148.163.2.239 mail239.ipadgloves.net 148.163.2.240 mail240.ipadgloves.net 148.163.2.241 mail241.ipadgloves.net 148.163.2.242 mail242.ipadgloves.net 148.163.2.243 mail243.ipadgloves.net 148.163.2.244 mail244.ipadgloves.net 148.163.2.245 mail245.ipadgloves.net 148.163.2.246 mail246.ipadgloves.net 148.163.2.247 mail247.ipadgloves.net 148.163.2.248 mail248.ipadgloves.net 148.163.2.249 mail249.ipadgloves.net 148.163.2.250 mail250.ipadgloves.net 148.163.2.251 mail251.ipadgloves.net 148.163.2.252 mail252.ipadgloves.net 148.163.2.253 mail253.ipadgloves.net 148.163.2.254 mail254.ipadgloves.net 148.163.3.4 mail.minidatasystems.com 148.163.3.11 mail11.minidatasystems.com 148.163.3.12 mail12.minidatasystems.com 148.163.3.13 mail13.minidatasystems.com 148.163.3.14 mail14.minidatasystems.com 148.163.3.15 mail15.minidatasystems.com 148.163.3.16 mail16.minidatasystems.com 148.163.3.17 mail17.minidatasystems.com 148.163.3.18 mail18.minidatasystems.com 148.163.3.19 mail19.minidatasystems.com 148.163.3.20 mail20.minidatasystems.com 148.163.3.21 mail21.minidatasystems.com 148.163.3.22 mail22.minidatasystems.com 148.163.3.23 mail23.minidatasystems.com 148.163.3.24 mail24.minidatasystems.com 148.163.3.25 mail25.minidatasystems.com 148.163.3.26 mail26.minidatasystems.com 148.163.3.27 mail27.minidatasystems.com 148.163.3.28 mail28.minidatasystems.com 148.163.3.29 mail29.minidatasystems.com 148.163.3.30 mail30.minidatasystems.com 148.163.3.31 mail31.minidatasystems.com 148.163.3.32 mail32.minidatasystems.com 148.163.3.33 mail33.minidatasystems.com 148.163.3.34 mail34.minidatasystems.com 148.163.3.35 mail35.minidatasystems.com 148.163.3.36 mail36.minidatasystems.com 148.163.3.37 mail37.minidatasystems.com 148.163.3.38 mail38.minidatasystems.com 148.163.3.39 mail39.minidatasystems.com 148.163.3.40 mail40.minidatasystems.com 148.163.3.41 mail41.minidatasystems.com 148.163.3.42 mail42.minidatasystems.com 148.163.3.43 mail43.minidatasystems.com 148.163.3.44 mail44.minidatasystems.com 148.163.3.45 mail45.minidatasystems.com 148.163.3.46 mail46.minidatasystems.com 148.163.3.47 mail47.minidatasystems.com 148.163.3.48 mail48.minidatasystems.com 148.163.3.49 mail49.minidatasystems.com 148.163.3.50 mail50.minidatasystems.com 148.163.3.51 mail51.minidatasystems.com 148.163.3.52 mail52.minidatasystems.com 148.163.3.53 mail53.minidatasystems.com 148.163.3.54 mail54.minidatasystems.com 148.163.3.55 mail55.minidatasystems.com 148.163.3.56 mail56.minidatasystems.com 148.163.3.57 mail57.minidatasystems.com 148.163.3.58 mail58.minidatasystems.com 148.163.3.59 mail59.minidatasystems.com 148.163.3.60 mail60.minidatasystems.com 148.163.3.61 mail61.minidatasystems.com 148.163.3.62 mail62.minidatasystems.com 148.163.3.63 mail63.minidatasystems.com 148.163.3.64 mail64.minidatasystems.com 148.163.3.65 mail65.minidatasystems.com 148.163.3.66 mail66.minidatasystems.com 148.163.3.67 mail67.minidatasystems.com 148.163.3.68 mail68.minidatasystems.com 148.163.3.69 mail69.minidatasystems.com 148.163.3.70 mail70.minidatasystems.com 148.163.3.71 mail71.minidatasystems.com 148.163.3.72 mail72.minidatasystems.com 148.163.3.73 mail73.minidatasystems.com 148.163.3.74 mail74.minidatasystems.com 148.163.3.75 mail75.minidatasystems.com 148.163.3.76 mail76.minidatasystems.com 148.163.3.77 mail77.minidatasystems.com 148.163.3.78 mail78.minidatasystems.com 148.163.3.79 mail79.minidatasystems.com 148.163.3.80 mail80.minidatasystems.com 148.163.3.81 mail81.minidatasystems.com 148.163.3.82 mail82.minidatasystems.com 148.163.3.83 mail83.minidatasystems.com 148.163.3.84 mail84.minidatasystems.com 148.163.3.85 mail85.minidatasystems.com 148.163.3.86 mail86.minidatasystems.com 148.163.3.87 mail87.minidatasystems.com 148.163.3.88 mail88.minidatasystems.com 148.163.3.89 mail89.minidatasystems.com 148.163.3.90 mail90.minidatasystems.com 148.163.3.91 mail91.minidatasystems.com 148.163.3.92 mail92.minidatasystems.com 148.163.3.93 mail93.minidatasystems.com 148.163.3.94 mail94.minidatasystems.com 148.163.3.95 mail95.minidatasystems.com 148.163.3.96 mail96.minidatasystems.com 148.163.3.97 mail97.minidatasystems.com 148.163.3.98 mail98.minidatasystems.com 148.163.3.99 mail99.minidatasystems.com 148.163.3.100 mail100.minidatasystems.com 148.163.3.101 mail101.minidatasystems.com 148.163.3.102 mail102.minidatasystems.com 148.163.3.103 mail103.minidatasystems.com 148.163.3.104 mail104.minidatasystems.com 148.163.3.105 mail105.minidatasystems.com 148.163.3.106 mail106.minidatasystems.com 148.163.3.107 mail107.minidatasystems.com 148.163.3.108 mail108.minidatasystems.com 148.163.3.109 mail109.minidatasystems.com 148.163.3.110 mail110.minidatasystems.com 148.163.3.111 mail111.minidatasystems.com 148.163.3.112 mail112.minidatasystems.com 148.163.3.113 mail113.minidatasystems.com 148.163.3.114 mail114.minidatasystems.com 148.163.3.115 mail115.minidatasystems.com 148.163.3.116 mail116.minidatasystems.com 148.163.3.117 mail117.minidatasystems.com 148.163.3.118 mail118.minidatasystems.com 148.163.3.119 mail119.minidatasystems.com 148.163.3.120 mail120.minidatasystems.com 148.163.3.121 mail121.minidatasystems.com 148.163.3.122 mail122.minidatasystems.com 148.163.3.123 mail123.minidatasystems.com 148.163.3.124 mail124.minidatasystems.com 148.163.3.125 mail125.minidatasystems.com 148.163.3.126 mail126.minidatasystems.com 148.163.3.127 mail127.minidatasystems.com 148.163.3.128 mail128.minidatasystems.com 148.163.3.129 mail129.minidatasystems.com 148.163.3.130 mail130.minidatasystems.com 148.163.3.131 mail131.minidatasystems.com 148.163.3.132 mail132.minidatasystems.com 148.163.3.133 mail133.minidatasystems.com 148.163.3.134 mail134.minidatasystems.com 148.163.3.135 mail135.minidatasystems.com 148.163.3.136 mail136.minidatasystems.com 148.163.3.137 mail137.minidatasystems.com 148.163.3.138 mail138.minidatasystems.com 148.163.3.139 mail139.minidatasystems.com 148.163.3.140 mail140.minidatasystems.com 148.163.3.141 mail141.minidatasystems.com 148.163.3.142 mail142.minidatasystems.com 148.163.3.143 mail143.minidatasystems.com 148.163.3.144 mail144.minidatasystems.com 148.163.3.145 mail145.minidatasystems.com 148.163.3.146 mail146.minidatasystems.com 148.163.3.147 mail147.minidatasystems.com 148.163.3.148 mail148.minidatasystems.com 148.163.3.149 mail149.minidatasystems.com 148.163.3.150 mail150.minidatasystems.com 148.163.3.151 mail151.minidatasystems.com 148.163.3.152 mail152.minidatasystems.com 148.163.3.153 mail153.minidatasystems.com 148.163.3.154 mail154.minidatasystems.com 148.163.3.155 mail155.minidatasystems.com 148.163.3.156 mail156.minidatasystems.com 148.163.3.157 mail157.minidatasystems.com 148.163.3.158 mail158.minidatasystems.com 148.163.3.159 mail159.minidatasystems.com 148.163.3.160 mail160.minidatasystems.com 148.163.3.161 mail161.minidatasystems.com 148.163.3.162 mail162.minidatasystems.com 148.163.3.163 mail163.minidatasystems.com 148.163.3.164 mail164.minidatasystems.com 148.163.3.165 mail165.minidatasystems.com 148.163.3.166 mail166.minidatasystems.com 148.163.3.167 mail167.minidatasystems.com 148.163.3.168 mail168.minidatasystems.com 148.163.3.169 mail169.minidatasystems.com 148.163.3.170 mail170.minidatasystems.com 148.163.3.171 mail171.minidatasystems.com 148.163.3.172 mail172.minidatasystems.com 148.163.3.173 mail173.minidatasystems.com 148.163.3.174 mail174.minidatasystems.com 148.163.3.175 mail175.minidatasystems.com 148.163.3.176 mail176.minidatasystems.com 148.163.3.177 mail177.minidatasystems.com 148.163.3.178 mail178.minidatasystems.com 148.163.3.179 mail179.minidatasystems.com 148.163.3.180 mail180.minidatasystems.com 148.163.3.181 mail181.minidatasystems.com 148.163.3.182 mail182.minidatasystems.com 148.163.3.183 mail183.minidatasystems.com 148.163.3.184 mail184.minidatasystems.com 148.163.3.185 mail185.minidatasystems.com 148.163.3.186 mail186.minidatasystems.com 148.163.3.187 mail187.minidatasystems.com 148.163.3.188 mail188.minidatasystems.com 148.163.3.189 mail189.minidatasystems.com 148.163.3.190 mail190.minidatasystems.com 148.163.3.191 mail191.minidatasystems.com 148.163.3.192 mail192.minidatasystems.com 148.163.3.193 mail193.minidatasystems.com 148.163.3.194 mail194.minidatasystems.com 148.163.3.195 mail195.minidatasystems.com 148.163.3.196 mail196.minidatasystems.com 148.163.3.197 mail197.minidatasystems.com 148.163.3.198 mail198.minidatasystems.com 148.163.3.199 mail199.minidatasystems.com 148.163.3.200 mail200.minidatasystems.com 148.163.3.201 mail201.minidatasystems.com 148.163.3.202 mail202.minidatasystems.com 148.163.3.203 mail203.minidatasystems.com 148.163.3.204 mail204.minidatasystems.com 148.163.3.205 mail205.minidatasystems.com 148.163.3.206 mail206.minidatasystems.com 148.163.3.207 mail207.minidatasystems.com 148.163.3.208 mail208.minidatasystems.com 148.163.3.209 mail209.minidatasystems.com 148.163.3.210 mail210.minidatasystems.com 148.163.3.211 mail211.minidatasystems.com 148.163.3.212 mail212.minidatasystems.com 148.163.3.213 mail213.minidatasystems.com 148.163.3.214 mail214.minidatasystems.com 148.163.3.215 mail215.minidatasystems.com 148.163.3.216 mail216.minidatasystems.com 148.163.3.217 mail217.minidatasystems.com 148.163.3.218 mail218.minidatasystems.com 148.163.3.219 mail219.minidatasystems.com 148.163.3.220 mail220.minidatasystems.com 148.163.3.221 mail221.minidatasystems.com 148.163.3.222 mail222.minidatasystems.com 148.163.3.223 mail223.minidatasystems.com 148.163.3.224 mail224.minidatasystems.com 148.163.3.225 mail225.minidatasystems.com 148.163.3.226 mail226.minidatasystems.com 148.163.3.227 mail227.minidatasystems.com 148.163.3.228 mail228.minidatasystems.com 148.163.3.229 mail229.minidatasystems.com 148.163.3.230 mail230.minidatasystems.com 148.163.3.231 mail231.minidatasystems.com 148.163.3.232 mail232.minidatasystems.com 148.163.3.233 mail233.minidatasystems.com 148.163.3.234 mail234.minidatasystems.com 148.163.3.235 mail235.minidatasystems.com 148.163.3.236 mail236.minidatasystems.com 148.163.3.237 mail237.minidatasystems.com 148.163.3.238 mail238.minidatasystems.com 148.163.3.239 mail239.minidatasystems.com 148.163.3.240 mail240.minidatasystems.com 148.163.3.241 mail241.minidatasystems.com 148.163.3.242 mail242.minidatasystems.com 148.163.3.243 mail243.minidatasystems.com 148.163.3.244 mail244.minidatasystems.com 148.163.3.245 mail245.minidatasystems.com 148.163.3.246 mail246.minidatasystems.com 148.163.3.247 mail247.minidatasystems.com 148.163.3.248 mail248.minidatasystems.com 148.163.3.249 mail249.minidatasystems.com 148.163.3.250 mail250.minidatasystems.com 148.163.3.251 mail251.minidatasystems.com 148.163.3.252 mail252.minidatasystems.com 148.163.3.253 mail253.minidatasystems.com 148.163.3.254 mail254.minidatasystems.com 148.163.6.2 balancetutor.com 148.163.6.3 joletta.balancetutor.com 148.163.6.4 hill.balancetutor.com 148.163.6.5 papagena.balancetutor.com 148.163.6.6 guerin.balancetutor.com 148.163.6.7 laurelle.balancetutor.com 148.163.6.8 smolik.balancetutor.com 148.163.6.9 deterred.balancetutor.com 148.163.6.10 olvido.balancetutor.com 148.163.6.11 ninuza.balancetutor.com 148.163.6.12 hortono.balancetutor.com 148.163.6.13 hu.balancetutor.com 148.163.6.14 kopatski.balancetutor.com 148.163.6.15 pippi.balancetutor.com 148.163.6.16 lezlie.balancetutor.com 148.163.6.17 sobrevivientes.balancetutor.com 148.163.6.18 ramme.balancetutor.com 148.163.6.19 gullible.balancetutor.com 148.163.6.20 chandelier.balancetutor.com 148.163.6.21 lac.balancetutor.com 148.163.6.22 eigenvector.balancetutor.com 148.163.6.23 madres.balancetutor.com 148.163.6.24 marcasson.balancetutor.com 148.163.6.25 perfidy.balancetutor.com 148.163.6.26 narcisco.balancetutor.com 148.163.6.27 toumanova.balancetutor.com 148.163.6.28 toni.balancetutor.com 148.163.6.29 wabash.balancetutor.com 148.163.6.30 bencze.balancetutor.com 148.163.6.31 recrudescent.balancetutor.com 148.163.6.32 sw.balancetutor.com 148.163.6.33 blin.balancetutor.com 148.163.6.34 anthropoid.balancetutor.com 148.163.6.35 whitish.balancetutor.com 148.163.6.36 dilber.balancetutor.com 148.163.6.37 thimble.balancetutor.com 148.163.6.38 blaine.balancetutor.com 148.163.6.39 speedway.balancetutor.com 148.163.6.40 lieux.balancetutor.com 148.163.6.41 frackowiak.balancetutor.com 148.163.6.42 shih.balancetutor.com 148.163.6.43 aynesworth.balancetutor.com 148.163.6.44 partovi.balancetutor.com 148.163.6.45 painter.balancetutor.com 148.163.6.46 libertarian.balancetutor.com 148.163.6.47 frechette.balancetutor.com 148.163.6.48 square.balancetutor.com 148.163.6.49 spiry.balancetutor.com 148.163.6.50 rouverol.balancetutor.com 148.163.6.51 tedious.balancetutor.com 148.163.6.52 silvie.balancetutor.com 148.163.6.53 thomajan.balancetutor.com 148.163.6.54 macchiavelli.balancetutor.com 148.163.6.55 burpelson.balancetutor.com 148.163.6.56 orphans.balancetutor.com 148.163.6.57 shoddy.balancetutor.com 148.163.6.58 manzanita.balancetutor.com 148.163.6.59 johnette.balancetutor.com 148.163.6.60 remigio.balancetutor.com 148.163.6.61 macedonia.balancetutor.com 148.163.6.62 essence.balancetutor.com 148.163.6.63 carnie.balancetutor.com 148.163.6.64 nydia.balancetutor.com 148.163.6.65 yurka.balancetutor.com 148.163.6.66 cutters.balancetutor.com 148.163.6.67 matilde.balancetutor.com 148.163.6.68 bagashvili.balancetutor.com 148.163.6.69 exclusion.balancetutor.com 148.163.6.70 italiana.balancetutor.com 148.163.6.71 haggart.balancetutor.com 148.163.6.72 rails.balancetutor.com 148.163.6.73 suzerainty.balancetutor.com 148.163.6.74 jonsy.balancetutor.com 148.163.6.75 kuhlenbeck.balancetutor.com 148.163.6.76 frommer.balancetutor.com 148.163.6.77 harleman.balancetutor.com 148.163.6.78 oilcloth.balancetutor.com 148.163.6.79 colleen.balancetutor.com 148.163.6.80 descrieres.balancetutor.com 148.163.6.81 estrade.balancetutor.com 148.163.6.82 dittenhoffer.balancetutor.com 148.163.6.83 longhand.balancetutor.com 148.163.6.84 felic.balancetutor.com 148.163.6.85 takash.balancetutor.com 148.163.6.86 mutant.balancetutor.com 148.163.6.87 butchery.balancetutor.com 148.163.6.88 tummel.balancetutor.com 148.163.6.89 polarography.balancetutor.com 148.163.6.90 lanyan.balancetutor.com 148.163.6.91 alberty.balancetutor.com 148.163.6.92 maynes.balancetutor.com 148.163.6.93 toot.balancetutor.com 148.163.6.94 bronson.balancetutor.com 148.163.6.95 zeon.balancetutor.com 148.163.6.96 vrain.balancetutor.com 148.163.6.97 obsequious.balancetutor.com 148.163.6.98 spell.balancetutor.com 148.163.6.99 narration.balancetutor.com 148.163.6.100 mairesse.balancetutor.com 148.163.6.101 perez.balancetutor.com 148.163.6.102 dhery.balancetutor.com 148.163.6.103 lukather.balancetutor.com 148.163.6.104 genin.balancetutor.com 148.163.6.105 culliford.balancetutor.com 148.163.6.106 panamanian.balancetutor.com 148.163.6.107 biroff.balancetutor.com 148.163.6.108 pansie.balancetutor.com 148.163.6.109 meantime.balancetutor.com 148.163.6.110 dixieland.balancetutor.com 148.163.6.111 pair.balancetutor.com 148.163.6.112 minuscule.balancetutor.com 148.163.6.113 gennini.balancetutor.com 148.163.6.114 tyzack.balancetutor.com 148.163.6.115 joined.balancetutor.com 148.163.6.116 mira.balancetutor.com 148.163.6.117 ladyfern.balancetutor.com 148.163.6.118 torquil.balancetutor.com 148.163.6.119 inconvenient.balancetutor.com 148.163.6.120 survive.balancetutor.com 148.163.6.121 melisent.balancetutor.com 148.163.6.122 tabbs.balancetutor.com 148.163.6.123 herlihy.balancetutor.com 148.163.6.124 radiometer.balancetutor.com 148.163.6.125 auria.balancetutor.com 148.163.6.126 dorin.balancetutor.com 148.163.6.127 whimbrel.balancetutor.com 148.163.6.128 corps.balancetutor.com 148.163.6.129 collegiate.balancetutor.com 148.163.6.130 belli.balancetutor.com 148.163.6.131 comptroller.balancetutor.com 148.163.6.132 librate.balancetutor.com 148.163.6.133 staph.balancetutor.com 148.163.6.134 fuortes.balancetutor.com 148.163.6.135 berova.balancetutor.com 148.163.6.136 mansel.balancetutor.com 148.163.6.137 pulpit.balancetutor.com 148.163.6.138 gabriello.balancetutor.com 148.163.6.139 leondopolous.balancetutor.com 148.163.6.140 threatt.balancetutor.com 148.163.6.141 newcomer.balancetutor.com 148.163.6.142 simpkins.balancetutor.com 148.163.6.143 operand.balancetutor.com 148.163.6.144 pater.balancetutor.com 148.163.6.145 berger.balancetutor.com 148.163.6.146 grenzpostens.balancetutor.com 148.163.6.147 lucinda.balancetutor.com 148.163.6.148 svelta.balancetutor.com 148.163.6.149 guttenberg.balancetutor.com 148.163.6.150 brea.balancetutor.com 148.163.6.151 bop.balancetutor.com 148.163.6.152 komora.balancetutor.com 148.163.6.153 fipps.balancetutor.com 148.163.6.154 essie.balancetutor.com 148.163.6.155 kawsadze.balancetutor.com 148.163.6.156 haigh.balancetutor.com 148.163.6.157 handyman.balancetutor.com 148.163.6.158 hampton.balancetutor.com 148.163.6.159 canadian.balancetutor.com 148.163.6.160 infanticide.balancetutor.com 148.163.6.161 buckholder.balancetutor.com 148.163.6.162 rebelling.balancetutor.com 148.163.6.163 coypu.balancetutor.com 148.163.6.164 katherine.balancetutor.com 148.163.6.165 upriver.balancetutor.com 148.163.6.166 dagg.balancetutor.com 148.163.6.167 forslund.balancetutor.com 148.163.6.168 para.balancetutor.com 148.163.6.169 bachir.balancetutor.com 148.163.6.170 greis.balancetutor.com 148.163.6.171 jochi.balancetutor.com 148.163.6.172 jobina.balancetutor.com 148.163.6.173 moonbeam.balancetutor.com 148.163.6.174 dupe.balancetutor.com 148.163.6.175 punch.balancetutor.com 148.163.6.176 extracurricular.balancetutor.com 148.163.6.177 argibay.balancetutor.com 148.163.6.178 yida.balancetutor.com 148.163.6.179 litvinoff.balancetutor.com 148.163.6.180 threaten.balancetutor.com 148.163.6.181 sesta.balancetutor.com 148.163.6.182 castenada.balancetutor.com 148.163.6.183 interiors.balancetutor.com 148.163.6.184 plummet.balancetutor.com 148.163.6.185 finial.balancetutor.com 148.163.6.186 cuneo.balancetutor.com 148.163.6.187 hyperthermia.balancetutor.com 148.163.6.188 caspar.balancetutor.com 148.163.6.189 caucasian.balancetutor.com 148.163.6.190 penella.balancetutor.com 148.163.6.191 peg.balancetutor.com 148.163.6.192 yordanoff.balancetutor.com 148.163.6.193 bargarian.balancetutor.com 148.163.6.194 love.balancetutor.com 148.163.6.195 halleck.balancetutor.com 148.163.6.196 debouny.balancetutor.com 148.163.6.197 korry.balancetutor.com 148.163.6.198 cornea.balancetutor.com 148.163.6.199 lurk.balancetutor.com 148.163.6.200 footloose.balancetutor.com 148.163.6.201 guilbert.balancetutor.com 148.163.6.202 goes.balancetutor.com 148.163.6.203 roarke.balancetutor.com 148.163.6.204 ricardo.balancetutor.com 148.163.6.205 nuits.balancetutor.com 148.163.6.206 jacquie.balancetutor.com 148.163.6.207 peruse.balancetutor.com 148.163.6.208 finck.balancetutor.com 148.163.6.209 ambengat.balancetutor.com 148.163.6.210 joanna.balancetutor.com 148.163.6.211 nolan.balancetutor.com 148.163.6.212 braid.balancetutor.com 148.163.6.213 octopus.balancetutor.com 148.163.6.214 mcvilches.balancetutor.com 148.163.6.215 brokerage.balancetutor.com 148.163.6.216 seaboard.balancetutor.com 148.163.6.217 gandett.balancetutor.com 148.163.6.218 posey.balancetutor.com 148.163.6.219 lonette.balancetutor.com 148.163.6.220 abundant.balancetutor.com 148.163.6.221 arsenal.balancetutor.com 148.163.6.222 aleksa.balancetutor.com 148.163.6.223 kilman.balancetutor.com 148.163.6.224 drain.balancetutor.com 148.163.6.225 moory.balancetutor.com 148.163.6.226 stressful.balancetutor.com 148.163.6.227 heu.balancetutor.com 148.163.6.228 glutinous.balancetutor.com 148.163.6.229 yuichi.balancetutor.com 148.163.6.230 requena.balancetutor.com 148.163.6.231 rubin.balancetutor.com 148.163.6.232 gidon.balancetutor.com 148.163.6.233 dashboard.balancetutor.com 148.163.6.234 absolute.balancetutor.com 148.163.6.235 molieri.balancetutor.com 148.163.6.236 exotic.balancetutor.com 148.163.6.237 stooge.balancetutor.com 148.163.6.238 lloyd.balancetutor.com 148.163.6.239 mastery.balancetutor.com 148.163.6.240 idi.balancetutor.com 148.163.6.241 traviata.balancetutor.com 148.163.6.242 awl.balancetutor.com 148.163.6.243 amiss.balancetutor.com 148.163.6.244 wilhelmina.balancetutor.com 148.163.6.245 aerobic.balancetutor.com 148.163.6.246 sherrill.balancetutor.com 148.163.6.247 idelle.balancetutor.com 148.163.6.248 fekkesh.balancetutor.com 148.163.6.249 serio.balancetutor.com 148.163.6.250 pernicious.balancetutor.com 148.163.6.251 tump.balancetutor.com 148.163.6.252 jolys.balancetutor.com 148.163.6.253 limpy.balancetutor.com 148.163.6.254 dowell.balancetutor.com 148.163.8.2 determineindividualize.com 148.163.8.3 dully.determineindividualize.com 148.163.8.4 honori.determineindividualize.com 148.163.8.5 selwart.determineindividualize.com 148.163.8.6 laina.determineindividualize.com 148.163.8.7 orfeo.determineindividualize.com 148.163.8.8 gila.determineindividualize.com 148.163.8.9 eucharist.determineindividualize.com 148.163.8.10 belaieva.determineindividualize.com 148.163.8.11 conferee.determineindividualize.com 148.163.8.12 georgy.determineindividualize.com 148.163.8.13 gambelli.determineindividualize.com 148.163.8.14 dater.determineindividualize.com 148.163.8.15 trainload.determineindividualize.com 148.163.8.16 eshtor.determineindividualize.com 148.163.8.17 pertinent.determineindividualize.com 148.163.8.18 hartfield.determineindividualize.com 148.163.8.19 victorien.determineindividualize.com 148.163.8.20 lifeblood.determineindividualize.com 148.163.8.21 ifkovich.determineindividualize.com 148.163.8.22 revkah.determineindividualize.com 148.163.8.23 coessens.determineindividualize.com 148.163.8.24 throley.determineindividualize.com 148.163.8.25 chigger.determineindividualize.com 148.163.8.26 hawn.determineindividualize.com 148.163.8.27 sulfite.determineindividualize.com 148.163.8.28 eleomore.determineindividualize.com 148.163.8.29 clean.determineindividualize.com 148.163.8.30 habicht.determineindividualize.com 148.163.8.31 maurine.determineindividualize.com 148.163.8.32 gallberry.determineindividualize.com 148.163.8.33 salvesen.determineindividualize.com 148.163.8.34 tevis.determineindividualize.com 148.163.8.35 calvet.determineindividualize.com 148.163.8.36 loury.determineindividualize.com 148.163.8.37 py.determineindividualize.com 148.163.8.38 complicity.determineindividualize.com 148.163.8.39 sharif.determineindividualize.com 148.163.8.40 noteworthy.determineindividualize.com 148.163.8.41 diggers.determineindividualize.com 148.163.8.42 hellenpolis.determineindividualize.com 148.163.8.43 jarol.determineindividualize.com 148.163.8.44 shaun.determineindividualize.com 148.163.8.45 actaeon.determineindividualize.com 148.163.8.46 danika.determineindividualize.com 148.163.8.47 furtive.determineindividualize.com 148.163.8.48 convolute.determineindividualize.com 148.163.8.49 favio.determineindividualize.com 148.163.8.50 molinari.determineindividualize.com 148.163.8.51 adan.determineindividualize.com 148.163.8.52 wren.determineindividualize.com 148.163.8.53 expressman.determineindividualize.com 148.163.8.54 nielson.determineindividualize.com 148.163.8.55 puffball.determineindividualize.com 148.163.8.56 rivere.determineindividualize.com 148.163.8.57 felicitous.determineindividualize.com 148.163.8.58 juttner.determineindividualize.com 148.163.8.59 boarder.determineindividualize.com 148.163.8.60 benares.determineindividualize.com 148.163.8.61 enke.determineindividualize.com 148.163.8.62 shaefer.determineindividualize.com 148.163.8.63 oestergaard.determineindividualize.com 148.163.8.64 contort.determineindividualize.com 148.163.8.65 jacinto.determineindividualize.com 148.163.8.66 enclave.determineindividualize.com 148.163.8.67 munier.determineindividualize.com 148.163.8.68 zak.determineindividualize.com 148.163.8.69 heilmann.determineindividualize.com 148.163.8.70 golddiggers.determineindividualize.com 148.163.8.71 sugath.determineindividualize.com 148.163.8.72 mochow.determineindividualize.com 148.163.8.73 mitchael.determineindividualize.com 148.163.8.74 bambang.determineindividualize.com 148.163.8.75 ebeling.determineindividualize.com 148.163.8.76 hearne.determineindividualize.com 148.163.8.77 farmwoman.determineindividualize.com 148.163.8.78 nabbing.determineindividualize.com 148.163.8.79 revengers.determineindividualize.com 148.163.8.80 indiscreet.determineindividualize.com 148.163.8.81 beasely.determineindividualize.com 148.163.8.82 ampere.determineindividualize.com 148.163.8.83 kenobi.determineindividualize.com 148.163.8.84 janeta.determineindividualize.com 148.163.8.85 conduct.determineindividualize.com 148.163.8.86 penance.determineindividualize.com 148.163.8.87 perovic.determineindividualize.com 148.163.8.88 twa.determineindividualize.com 148.163.8.89 dubitable.determineindividualize.com 148.163.8.90 majerhofer.determineindividualize.com 148.163.8.91 contentious.determineindividualize.com 148.163.8.92 francesca.determineindividualize.com 148.163.8.93 porphyry.determineindividualize.com 148.163.8.94 terrorist.determineindividualize.com 148.163.8.95 neutronium.determineindividualize.com 148.163.8.96 brandenburg.determineindividualize.com 148.163.8.97 deyl.determineindividualize.com 148.163.8.98 mural.determineindividualize.com 148.163.8.99 decryption.determineindividualize.com 148.163.8.100 crystallography.determineindividualize.com 148.163.8.101 palmberg.determineindividualize.com 148.163.8.102 otti.determineindividualize.com 148.163.8.103 pettyjohn.determineindividualize.com 148.163.8.104 eightieth.determineindividualize.com 148.163.8.105 thermonuclear.determineindividualize.com 148.163.8.106 spione.determineindividualize.com 148.163.8.107 embassy.determineindividualize.com 148.163.8.108 korano.determineindividualize.com 148.163.8.109 khun.determineindividualize.com 148.163.8.110 angorapoulos.determineindividualize.com 148.163.8.111 tove.determineindividualize.com 148.163.8.112 turpitude.determineindividualize.com 148.163.8.113 interviewer.determineindividualize.com 148.163.8.114 anaesthetist.determineindividualize.com 148.163.8.115 declarator.determineindividualize.com 148.163.8.116 veri.determineindividualize.com 148.163.8.117 wetting.determineindividualize.com 148.163.8.118 roxiu.determineindividualize.com 148.163.8.119 fleming.determineindividualize.com 148.163.8.120 shandel.determineindividualize.com 148.163.8.121 layden.determineindividualize.com 148.163.8.122 prowl.determineindividualize.com 148.163.8.123 hatchway.determineindividualize.com 148.163.8.124 jered.determineindividualize.com 148.163.8.125 greengrocer.determineindividualize.com 148.163.8.126 oya.determineindividualize.com 148.163.8.127 amboise.determineindividualize.com 148.163.8.128 lupavinova.determineindividualize.com 148.163.8.129 basibla.determineindividualize.com 148.163.8.130 jacobian.determineindividualize.com 148.163.8.131 apostis.determineindividualize.com 148.163.8.132 laurencic.determineindividualize.com 148.163.8.133 galore.determineindividualize.com 148.163.8.134 quiere.determineindividualize.com 148.163.8.135 nesta.determineindividualize.com 148.163.8.136 morriera.determineindividualize.com 148.163.8.137 corteguay.determineindividualize.com 148.163.8.138 okamoto.determineindividualize.com 148.163.8.139 abenteuer.determineindividualize.com 148.163.8.140 tehanni.determineindividualize.com 148.163.8.141 merrin.determineindividualize.com 148.163.8.142 inanimate.determineindividualize.com 148.163.8.143 lepage.determineindividualize.com 148.163.8.144 stalk.determineindividualize.com 148.163.8.145 braden.determineindividualize.com 148.163.8.146 foolscap.determineindividualize.com 148.163.8.147 ferrovius.determineindividualize.com 148.163.8.148 tildie.determineindividualize.com 148.163.8.149 non.determineindividualize.com 148.163.8.150 karil.determineindividualize.com 148.163.8.151 liniment.determineindividualize.com 148.163.8.152 krieg.determineindividualize.com 148.163.8.153 emmie.determineindividualize.com 148.163.8.154 rembrandt.determineindividualize.com 148.163.8.155 danko.determineindividualize.com 148.163.8.156 swaef.determineindividualize.com 148.163.8.157 ghetto.determineindividualize.com 148.163.8.158 ephemerides.determineindividualize.com 148.163.8.159 scotland.determineindividualize.com 148.163.8.160 jump.determineindividualize.com 148.163.8.161 rakubian.determineindividualize.com 148.163.8.162 tripp.determineindividualize.com 148.163.8.163 orvis.determineindividualize.com 148.163.8.164 pigeon.determineindividualize.com 148.163.8.165 combinatorial.determineindividualize.com 148.163.8.166 decent.determineindividualize.com 148.163.8.167 mossy.determineindividualize.com 148.163.8.168 dieter.determineindividualize.com 148.163.8.169 laurita.determineindividualize.com 148.163.8.170 injury.determineindividualize.com 148.163.8.171 sparky.determineindividualize.com 148.163.8.172 kazuhito.determineindividualize.com 148.163.8.173 starch.determineindividualize.com 148.163.8.174 shimmele.determineindividualize.com 148.163.8.175 infant.determineindividualize.com 148.163.8.176 considerate.determineindividualize.com 148.163.8.177 berpe.determineindividualize.com 148.163.8.178 jailer.determineindividualize.com 148.163.8.179 wavenumber.determineindividualize.com 148.163.8.180 yevgraf.determineindividualize.com 148.163.8.181 brumlik.determineindividualize.com 148.163.8.182 yamashita.determineindividualize.com 148.163.8.183 cormack.determineindividualize.com 148.163.8.184 loire.determineindividualize.com 148.163.8.185 adhesive.determineindividualize.com 148.163.8.186 volsky.determineindividualize.com 148.163.8.187 mordant.determineindividualize.com 148.163.8.188 vinnette.determineindividualize.com 148.163.8.189 georgetta.determineindividualize.com 148.163.8.190 nostril.determineindividualize.com 148.163.8.191 kerwinn.determineindividualize.com 148.163.8.192 lighting.determineindividualize.com 148.163.8.193 violence.determineindividualize.com 148.163.8.194 tita.determineindividualize.com 148.163.8.195 lexicographer.determineindividualize.com 148.163.8.196 imponderable.determineindividualize.com 148.163.8.197 wegner.determineindividualize.com 148.163.8.198 gaelle.determineindividualize.com 148.163.8.199 joya.determineindividualize.com 148.163.8.200 mayll.determineindividualize.com 148.163.8.201 pram.determineindividualize.com 148.163.8.202 haghios.determineindividualize.com 148.163.8.203 yell.determineindividualize.com 148.163.8.204 tuchmann.determineindividualize.com 148.163.8.205 francisquinha.determineindividualize.com 148.163.8.206 defence.determineindividualize.com 148.163.8.207 bolne.determineindividualize.com 148.163.8.208 zarrah.determineindividualize.com 148.163.8.209 waelsungenblut.determineindividualize.com 148.163.8.210 enrage.determineindividualize.com 148.163.8.211 typhus.determineindividualize.com 148.163.8.212 shone.determineindividualize.com 148.163.8.213 laraine.determineindividualize.com 148.163.8.214 arty.determineindividualize.com 148.163.8.215 alecia.determineindividualize.com 148.163.8.216 schroedinger.determineindividualize.com 148.163.8.217 telescope.determineindividualize.com 148.163.8.218 gavrielle.determineindividualize.com 148.163.8.219 yew.determineindividualize.com 148.163.8.220 sneer.determineindividualize.com 148.163.8.221 agay.determineindividualize.com 148.163.8.222 centaur.determineindividualize.com 148.163.8.223 dipole.determineindividualize.com 148.163.8.224 remar.determineindividualize.com 148.163.8.225 frisby.determineindividualize.com 148.163.8.226 keechie.determineindividualize.com 148.163.8.227 yulin.determineindividualize.com 148.163.8.228 teters.determineindividualize.com 148.163.8.229 asylum.determineindividualize.com 148.163.8.230 kalidor.determineindividualize.com 148.163.8.231 pastorek.determineindividualize.com 148.163.8.232 bruce.determineindividualize.com 148.163.8.233 peluce.determineindividualize.com 148.163.8.234 reardon.determineindividualize.com 148.163.8.235 dobe.determineindividualize.com 148.163.8.236 ernaline.determineindividualize.com 148.163.8.237 kossoff.determineindividualize.com 148.163.8.238 ekstram.determineindividualize.com 148.163.8.239 grant.determineindividualize.com 148.163.8.240 gatewood.determineindividualize.com 148.163.8.241 zeze.determineindividualize.com 148.163.8.242 polyhedron.determineindividualize.com 148.163.8.243 philippine.determineindividualize.com 148.163.8.244 kovrin.determineindividualize.com 148.163.8.245 dueringer.determineindividualize.com 148.163.8.246 spalinger.determineindividualize.com 148.163.8.247 sallet.determineindividualize.com 148.163.8.248 alchemy.determineindividualize.com 148.163.8.249 participle.determineindividualize.com 148.163.8.250 riviera.determineindividualize.com 148.163.8.251 macnabb.determineindividualize.com 148.163.8.252 transferral.determineindividualize.com 148.163.8.253 differentiable.determineindividualize.com 148.163.8.254 diehl.determineindividualize.com From woody at pch.net Wed Mar 30 16:03:40 2011 From: woody at pch.net (Bill Woodcock) Date: Wed, 30 Mar 2011 14:03:40 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <33182.1301518707@tristatelogic.com> References: <33182.1301518707@tristatelogic.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 30, 2011, at 1:58 PM, Ronald F. Guilmette wrote: > As I already mentioned, 159.223.0.0/16, which is actually registered to > the Hoechst Celanese Corporation, has quite obviously been hijacked And have you reported this to ARIN? https://www.arin.net/public/fraud/index.xhtml Obviously it's not fraud on Celanese's part, but it certainly seems to be evidence that they don't need the space anymore. If someone who needed it more had it, they might not put up with the hijacking. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2TmqwACgkQGvQy4xTRsBGkiwCgvHVFs1qz55H+FNCj+Apwrcev sFIAoMluDV11me+X8I9MoVie611H8e9P =p+yS -----END PGP SIGNATURE----- From jim at impactbusiness.com Wed Mar 30 16:52:18 2011 From: jim at impactbusiness.com (Jim Gonzalez) Date: Wed, 30 Mar 2011 17:52:18 -0400 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <33182.1301518707@tristatelogic.com> Message-ID: <002201cbef24$c1b61d70$45225850$@com> I have a level 3 circuit with BGP. Level 3 set me up a maintainer. To communicate with this program I just send an email to the maintainer, based on my email address and the maintainer name it will allow the route I request advertisement. I don't believe any one monitors this system and I would imagine if no one complains about this company advertising hijacked routes to level 3 then it would be quite easy to advertise a network that has been abandon. -----Original Message----- From: Bill Woodcock [mailto:woody at pch.net] Sent: Wednesday, March 30, 2011 5:04 PM To: Ronald F. Guilmette Cc: nanog at nanog.org Subject: Re: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mar 30, 2011, at 1:58 PM, Ronald F. Guilmette wrote: > As I already mentioned, 159.223.0.0/16, which is actually registered to > the Hoechst Celanese Corporation, has quite obviously been hijacked And have you reported this to ARIN? https://www.arin.net/public/fraud/index.xhtml Obviously it's not fraud on Celanese's part, but it certainly seems to be evidence that they don't need the space anymore. If someone who needed it more had it, they might not put up with the hijacking. -Bill -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2TmqwACgkQGvQy4xTRsBGkiwCgvHVFs1qz55H+FNCj+Apwrcev sFIAoMluDV11me+X8I9MoVie611H8e9P =p+yS -----END PGP SIGNATURE----- From rfg at tristatelogic.com Wed Mar 30 16:59:24 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 30 Mar 2011 14:59:24 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: Message-ID: <33835.1301522364@tristatelogic.com> In message , Bill Woodcock wrote: >On Mar 30, 2011, at 1:58 PM, Ronald F. Guilmette wrote: >> As I already mentioned, 159.223.0.0/16, which is actually registered = >to >> the Hoechst Celanese Corporation, has quite obviously been hijacked > >And have you reported this to ARIN? No. Why would I? The ARIN folks have already made it abundantly clear... to me and to others... that this sort of thing is "Not our job, man." ARIN maintains a data base. If other people elect to ignore what's in that data base... well... as anybody from ARIN will be only too happy to tell you, they are not the routing police. Regards, rfg From rfg at tristatelogic.com Wed Mar 30 17:23:09 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 30 Mar 2011 15:23:09 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <002201cbef24$c1b61d70$45225850$@com> Message-ID: <34098.1301523789@tristatelogic.com> In message <002201cbef24$c1b61d70$45225850$@com>, you wrote: >I don't believe any one monitors this system and I >would imagine if no one complains about this company advertising hijacked >routes to level 3 then it would be quite easy to advertise a network that >has been abandon(sic). At this point, I do believe that you are stating the obvious. Whether it is wise, or otherwise, to leave one's company's route announcements entirely on autopilot is, I think, a remaining question. The evidence would seem to suggest not. But then again, as I think we all know, there is a non-zero costs associated with doing anything well, professionally, or (as the laywers like to say) in a "workman-like manner", and these costs are often seen as being at odds with the corporate bottom line. Personally, I just hope that Level3 accrues a sufficient quantity of bad PR from what they have done here so that they will lose a client or two, and that this in turn might have some salutary effect upon the corporate calculus. Regards, rfg From a.harrowell at gmail.com Wed Mar 30 18:39:13 2011 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Thu, 31 Mar 2011 00:39:13 +0100 Subject: IPv6 SEO implecations? In-Reply-To: <4F427F24-E9D4-4B7B-ACCF-9F9E52D8C336@bsdboy.com> References: <4F427F24-E9D4-4B7B-ACCF-9F9E52D8C336@bsdboy.com> Message-ID: <201103310039.31080.a.harrowell@gmail.com> On Tuesday 29 Mar 2011 17:54:27 Wil Schultz wrote: > On Mar 29, 2011, at 3:51 AM, Franck Martin wrote: > > > And here's a breakdown of which user agents are seen on which ip, as you can see the user-agent doesn't exactly match IP range. > > Googlebot-Image/1.0 > Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html); > DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) > SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) Interesting that there are Googlebot mobile devices! Perhaps user-experience testing of some kind? Googlers? Or IPv6 testing of the devices themselves? Although those user strings are indicative of not very recent, non-Android phones. Would be interesting to see the percentages of traffic by each user agent. -- The only thing worse than e-mail disclaimers...is people who send e-mail to lists complaining about them -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From alex-lists-nanog at yuriev.com Wed Mar 30 08:55:15 2011 From: alex-lists-nanog at yuriev.com (Alex Yuriev) Date: Wed, 30 Mar 2011 09:55:15 -0400 Subject: fiber in Philadephia metro Message-ID: <20110330135515.GB4194@corp.zubrcom.net> If anyone has contacts inside the companies that have fiber available in Philadelphia metro (especially Philadelphia itself), I'd greatly appreciate hearing about it off list. Sales pitches from sales people are welcome, provided the said sales people understand the difference between "available fiber" vs. "if you pay us a million dollars we will lay the fiber to where you want it to go so you get available fiber" Alex From wschultz at bsdboy.com Wed Mar 30 18:55:04 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Wed, 30 Mar 2011 16:55:04 -0700 Subject: IPv6 SEO implecations? In-Reply-To: <201103310039.31080.a.harrowell@gmail.com> References: <4F427F24-E9D4-4B7B-ACCF-9F9E52D8C336@bsdboy.com> <201103310039.31080.a.harrowell@gmail.com> Message-ID: On Mar 30, 2011, at 4:39 PM, Alexander Harrowell wrote: > On Tuesday 29 Mar 2011 17:54:27 Wil Schultz wrote: >> On Mar 29, 2011, at 3:51 AM, Franck Martin wrote: >> >> >> And here's a breakdown of which user agents are seen on which ip, as you can > see the user-agent doesn't exactly match IP range. >> >> Googlebot-Image/1.0 > >> Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html); > >> DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; > +http://www.google.com/bot.html) > >> SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 > UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; > +http://www.google.com/bot.html) > > Interesting that there are Googlebot mobile devices! Perhaps user-experience > testing of some kind? Googlers? Or IPv6 testing of the devices themselves? > Although those user strings are indicative of not very recent, non-Android > phones. > > Would be interesting to see the percentages of traffic by each user agent. > -- > The only thing worse than e-mail disclaimers...is people who send e-mail to > lists complaining about them I've got the logs still but I've torn down the VIP. I'll send hit count percentages tomorrow. -wil From fmartin at linkedin.com Wed Mar 30 19:22:17 2011 From: fmartin at linkedin.com (Franck Martin) Date: Thu, 31 Mar 2011 00:22:17 +0000 Subject: IPv6 SEO implecations? In-Reply-To: Message-ID: On 3/31/11 11:55 , "Wil Schultz" wrote: > > >On Mar 30, 2011, at 4:39 PM, Alexander Harrowell >wrote: > >> On Tuesday 29 Mar 2011 17:54:27 Wil Schultz wrote: >>> On Mar 29, 2011, at 3:51 AM, Franck Martin wrote: >>> >>> >>> And here's a breakdown of which user agents are seen on which ip, as >>>you can >> see the user-agent doesn't exactly match IP range. >>> >>> Googlebot-Image/1.0 >> >>> Mozilla/5.0 (compatible; Googlebot/2.1; >>>+http://www.google.com/bot.html); >> >>> DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; >> +http://www.google.com/bot.html) >> >>> SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 >> UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; >>Googlebot-Mobile/2.1; >> +http://www.google.com/bot.html) >> >> Interesting that there are Googlebot mobile devices! Perhaps >>user-experience >> testing of some kind? Googlers? Or IPv6 testing of the devices >>themselves? >> Although those user strings are indicative of not very recent, >>non-Android >> phones. >> >> Would be interesting to see the percentages of traffic by each user >>agent. >> -- >> The only thing worse than e-mail disclaimers...is people who send >>e-mail to >> lists complaining about them > >I've got the logs still but I've torn down the VIP. I'll send hit count >percentages tomorrow. Interesting: http://www.google.com/search?q=site%3Aipv6.cnn.com http://www.bing.com/search?q=site%3Aipv6.cnn.com From ops.lists at gmail.com Wed Mar 30 20:25:14 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 31 Mar 2011 06:55:14 +0530 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <002201cbef24$c1b61d70$45225850$@com> References: <33182.1301518707@tristatelogic.com> <002201cbef24$c1b61d70$45225850$@com> Message-ID: This is an old enough "technique" dating back to a few years - re-registering an expired domain that belonged to the ARIN contact, and filling out the ISP paperwork. There does seem to be something that needs to be done - its not something ARIN can easily look into, the SP is much better placed to take action. But its a gray area between the two. On Thu, Mar 31, 2011 at 3:22 AM, Jim Gonzalez wrote: > I have a level 3 circuit with BGP. Level 3 set me up a maintainer. To > communicate with this program I just send an email to the maintainer, based > on my email address and the maintainer name it will allow the route I > request advertisement. I don't believe any one monitors this system and I > would imagine if no one complains about this company advertising hijacked > routes to level 3 then it would be quite easy to advertise a network that > has been abandon. -- Suresh Ramasubramanian (ops.lists at gmail.com) From rfg at tristatelogic.com Wed Mar 30 22:26:15 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 30 Mar 2011 20:26:15 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: Message-ID: <36496.1301541975@tristatelogic.com> In message , you wrote: >This is an old enough "technique" dating back to a few years - >re-registering an expired domain that belonged to the ARIN contact, >and filling out the ISP paperwork. FYI - That does not seem to have been what occured in the two particular cases I reported on today. The e-mail contact domain for the two relevant ARIN allocation records seems to still be in use by the chemical company, Hoechst Celanese. So that _really_ begs the question... Why did Circle Internet and (apparently) Level3's customer, BANDCON, blindly accept _any_ sort of assertion that the crook who hijacked these two /16s had the right to use them? % traceroute to 148.163.5.2 (148.163.5.2), 64 hops max, 40 byte packets ... 8 ae-62-62.csw1.SanJose1.Level3.net (4.69.153.18) 42.796 ms ae-82-82.csw3.SanJose1.Level3.net (4.69.153.26) 44.268 ms ae-72-72.csw2.SanJose1.Level3.net (4.69.153.22) 43.296 ms 9 ae-4-90.edge8.SanJose1.Level3.net (4.69.152.212) 44.877 ms ae-3-80.edge8.SanJose1.Level3.net (4.69.152.148) 44.731 ms ae-1-60.edge8.SanJose1.Level3.net (4.69.152.20) 44.426 ms 10 BANDCON.edge8.SanJose1.Level3.net (4.53.30.42) 45.018 ms 45.779 ms 45.043 ms 11 148.163.5.2 (148.163.5.2) 44.820 ms 45.651 ms 44.571 ms In the case of Circle Internet, I feel sure that the check cleared, so they didn't see it as either necessary or useful to inquire further. But the question that I'd most like to get an answer to... and the one that nobody will likely ever get an answer to... is "Did BandCon likewise see that the check which was made out to them cleared, and that thus they didn't see fit to inquire any further?" Separately, Jim Gonzalez raised an interesting and related point... If I were to simply forge the sender address of an e-mail message, send it to Level3, and ask Level3 to route some arbitrary hunk of IP space for me, would Level3 just blindly do it? If so, I may perhaps see if I can have a bit of fun, at their expense, this weekend. I mean what the hay! It's pretty obvious that nobody from law enforcement has any interest in any of this crap, and that random bad actors can perpetrate whatever kinds of frauds they wish on the net with virtual impunity. So why should this hijacking crap only be a spectator's sport? Regards, rfg From bross at pobox.com Wed Mar 30 23:00:15 2011 From: bross at pobox.com (Brandon Ross) Date: Thu, 31 Mar 2011 00:00:15 -0400 (EDT) Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <36496.1301541975@tristatelogic.com> References: <36496.1301541975@tristatelogic.com> Message-ID: On Wed, 30 Mar 2011, Ronald F. Guilmette wrote: > So that _really_ begs the question... Why did Circle Internet and (apparently) > Level3's customer, BANDCON, blindly accept _any_ sort of assertion that the > crook who hijacked these two /16s had the right to use them? What makes you think it was blind? The standard industry practice is to ask someone requesting to announce a route for a letter on the owner's letter head authorizing the announcement. Is it really that hard to invent some letterhead and sign a letter? It's probably one of the easiest to circumvent "security" procedures ever. Frankly it's a giant waste of time and does nothing other than frustrate legitimate work. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From ops.lists at gmail.com Wed Mar 30 23:19:25 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 31 Mar 2011 09:49:25 +0530 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <36496.1301541975@tristatelogic.com> Message-ID: Its also a procedure that does need some due diligence done on it, to avoid attacks where a SP's netblock is stolen when its actively routed rather than abandoned. On Thu, Mar 31, 2011 at 9:30 AM, Brandon Ross wrote: > > What makes you think it was blind? ?The standard industry practice is to ask > someone requesting to announce a route for a letter on the owner's letter > head authorizing the announcement. ?Is it really that hard to invent some > letterhead and sign a letter? > > It's probably one of the easiest to circumvent "security" procedures ever. > > Frankly it's a giant waste of time and does nothing other than frustrate > legitimate work. > -- Suresh Ramasubramanian (ops.lists at gmail.com) From ross.harvey at appfolio.com Wed Mar 30 23:49:52 2011 From: ross.harvey at appfolio.com (Ross Harvey) Date: Wed, 30 Mar 2011 21:49:52 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <36496.1301541975@tristatelogic.com> Message-ID: Wait a second, I'm pretty sure that in most contexts, a signature or letterhead means not so much "this is real because it's so obviously genuine", but rather: "This is real or I am willing to take a forgery rap". As it happens, that's good enough for many if not most non-cash transactions. Now, there are societies where that doesn't work, but they don't usually have a lot of networks. On Wed, Mar 30, 2011 at 9:00 PM, Brandon Ross wrote: > > On Wed, 30 Mar 2011, Ronald F. Guilmette wrote: > >> So that _really_ begs the question... Why did Circle Internet and (apparently) >> Level3's customer, BANDCON, blindly accept _any_ sort of assertion that the >> crook who hijacked these two /16s had the right to use them? > > What makes you think it was blind? ?The standard industry practice is to ask someone requesting to announce a route for a letter on the owner's letter head authorizing the announcement. ?Is it really that hard to invent some letterhead and sign a letter? > > It's probably one of the easiest to circumvent "security" procedures ever. > > Frankly it's a giant waste of time and does nothing other than frustrate legitimate work. > > -- > Brandon Ross ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?AIM: ?BrandonNRoss > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ICQ: ?2269442 > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Skype: ?brandonross ?Yahoo: ?BrandonNRoss > From bross at pobox.com Wed Mar 30 23:53:34 2011 From: bross at pobox.com (Brandon Ross) Date: Thu, 31 Mar 2011 00:53:34 -0400 (EDT) Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <36496.1301541975@tristatelogic.com> Message-ID: On Wed, 30 Mar 2011, Ross Harvey wrote: > Wait a second, I'm pretty sure that in most contexts, a signature or > letterhead means not so much "this is real because it's so obviously > genuine", but rather: > > "This is real or I am willing to take a forgery rap". Do you think most providers check the signer's ID to make sure they actually signed their own name? How do you prove that whomever you accuse of signing it actually forged it if not? Does anyone know of there ever being even a single case where someone was convicted of forgery for this? -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From owen at delong.com Thu Mar 31 00:11:33 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 31 Mar 2011 00:11:33 -0500 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <33835.1301522364@tristatelogic.com> References: <33835.1301522364@tristatelogic.com> Message-ID: Ronald... Cleaning up the routing, true. However, this sounds like there are two issues... 1. Routing -- Would be nice if the advertising provider(s) stopped doing so. Not something ARIN can really do much about. 2. Database -- Sounds like the existing resource holder may not still be using the resource or may no longer exist. In either case, it's worth having ARIN investigate the situation and take appropriate database action if that is the case. Owen Sent from my iPad On Mar 30, 2011, at 4:59 PM, "Ronald F. Guilmette" wrote: > > In message , > Bill Woodcock wrote: > >> On Mar 30, 2011, at 1:58 PM, Ronald F. Guilmette wrote: >>> As I already mentioned, 159.223.0.0/16, which is actually registered = >> to >>> the Hoechst Celanese Corporation, has quite obviously been hijacked >> >> And have you reported this to ARIN? > > No. Why would I? > > The ARIN folks have already made it abundantly clear... to me and to others... > that this sort of thing is "Not our job, man." > > ARIN maintains a data base. If other people elect to ignore what's in that > data base... well... as anybody from ARIN will be only too happy to tell you, > they are not the routing police. > > > Regards, > rfg From owen at delong.com Thu Mar 31 00:15:38 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 31 Mar 2011 00:15:38 -0500 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <36496.1301541975@tristatelogic.com> Message-ID: <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> If they put it on letterhead and signed their own name in such a way that it purports to be an agent of the organization for which they were not an authorized agent, that is usually enough to become a criminal act, whether it is considered forgery, fraud, or something else, I'm not sure about the exact technicalities and they may vary by jurisdiction. Owen Sent from my iPad On Mar 30, 2011, at 11:53 PM, Brandon Ross wrote: > On Wed, 30 Mar 2011, Ross Harvey wrote: > >> Wait a second, I'm pretty sure that in most contexts, a signature or >> letterhead means not so much "this is real because it's so obviously >> genuine", but rather: >> >> "This is real or I am willing to take a forgery rap". > > Do you think most providers check the signer's ID to make sure they actually signed their own name? How do you prove that whomever you accuse of signing it actually forged it if not? > > Does anyone know of there ever being even a single case where someone was convicted of forgery for this? > > -- > Brandon Ross AIM: BrandonNRoss > ICQ: 2269442 > Skype: brandonross Yahoo: BrandonNRoss From fergdawgster at gmail.com Thu Mar 31 00:22:51 2011 From: fergdawgster at gmail.com (Paul Ferguson) Date: Wed, 30 Mar 2011 22:22:51 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> References: <36496.1301541975@tristatelogic.com> <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> Message-ID: On Wed, Mar 30, 2011 at 10:15 PM, Owen DeLong wrote: > If they put it on letterhead and signed their own name in such a way that it purports > to be an agent of the organization for which they were not an authorized agent, that > is usually enough to become a criminal act, whether it is considered forgery, fraud, > or something else, I'm not sure about the exact technicalities and they may vary > by jurisdiction. > So, are you saying this is okay? I guess I'm at a loss in understanding why everyone seems to be so apathetic on this issue. - ferg -- "Fergie", a.k.a. Paul Ferguson ?Engineering Architecture for the Internet ?fergdawgster(at)gmail.com ?ferg's tech blog: http://fergdawg.blogspot.com/ From ops.lists at gmail.com Thu Mar 31 00:26:34 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 31 Mar 2011 10:56:34 +0530 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> References: <36496.1301541975@tristatelogic.com> <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> Message-ID: It also needs 1. Someone to complain to law enforcement 2. Law enforcement to decide this is something worth following up on re prosecution - especially if the crook is not within their jurisdiction, it'd be FBI, and they have a minimum threshold for damage caused (higher than the few thousand dollars a /16's registration fees cost?) [not counting 7.5 million bucks paid in aftermarket deals like microsoft from nortel] --srs On Thu, Mar 31, 2011 at 10:45 AM, Owen DeLong wrote: > If they put it on letterhead and signed their own name in such a way that it purports > to be an agent of the organization for which they were not an authorized agent, that > is usually enough to become a criminal act, whether it is considered forgery, fraud, > or something else, I'm not sure about the exact technicalities and they may vary > by jurisdiction. -- Suresh Ramasubramanian (ops.lists at gmail.com) From owen at delong.com Thu Mar 31 00:57:40 2011 From: owen at delong.com (Owen DeLong) Date: Wed, 30 Mar 2011 22:57:40 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <36496.1301541975@tristatelogic.com> <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> Message-ID: <1FA9176F-1661-4242-9FBF-6FD1BA259954@delong.com> On Mar 30, 2011, at 10:26 PM, Suresh Ramasubramanian wrote: > It also needs > > 1. Someone to complain to law enforcement > True, > 2. Law enforcement to decide this is something worth following up on > re prosecution - especially if the crook is not within their > jurisdiction, it'd be FBI, and they have a minimum threshold for > damage caused (higher than the few thousand dollars a /16's > registration fees cost?) > Not necessarily... If the crook is in another county, same state, it could be simple extradition. If the crook is across state lines, it could still be handled as an extradition, but, slightly more complicated. If the crook is on the other side of an international boundary, that's a whole new ball of wax and the number of permutations of regulatory combinations involved prevents any rational enumeration here. Owen > [not counting 7.5 million bucks paid in aftermarket deals like > microsoft from nortel] > > --srs > > On Thu, Mar 31, 2011 at 10:45 AM, Owen DeLong wrote: >> If they put it on letterhead and signed their own name in such a way that it purports >> to be an agent of the organization for which they were not an authorized agent, that >> is usually enough to become a criminal act, whether it is considered forgery, fraud, >> or something else, I'm not sure about the exact technicalities and they may vary >> by jurisdiction. > > > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) From ops.lists at gmail.com Thu Mar 31 01:13:48 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 31 Mar 2011 11:43:48 +0530 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <1FA9176F-1661-4242-9FBF-6FD1BA259954@delong.com> References: <36496.1301541975@tristatelogic.com> <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> <1FA9176F-1661-4242-9FBF-6FD1BA259954@delong.com> Message-ID: Local law isnt likely to touch this at all. On Thu, Mar 31, 2011 at 11:27 AM, Owen DeLong wrote: > > If the crook is in another county, same state, it could be simple extradition. > > If the crook is across state lines, it could still be handled as an extradition, > but, slightly more complicated. > > If the crook is on the other side of an international boundary, that's a whole > new ball of wax and the number of permutations of regulatory combinations > involved prevents any rational enumeration here. -- Suresh Ramasubramanian (ops.lists at gmail.com) From woody at pch.net Thu Mar 31 03:04:53 2011 From: woody at pch.net (Bill Woodcock) Date: Thu, 31 Mar 2011 01:04:53 -0700 Subject: PCH survey on peering Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Howdy. We're conducting a statistical overview of peering sessions for a research paper. The paper we produce will be input into OECD guidelines on national communications regulatory frameworks, so we'd very much like it to accurately reflect the diversity of peering agreements out there in the world. At the same time, if we ask for too much data, people will be reluctant to answer our questions, so we've tried to keep the data we're collecting as simple as possible. Specifically, for each other Autonomous System you peer with, we'd be interested in knowing the following five pieces of information: Your ASN Your peer's ASN Whether a written and signed peering agreement exists (the alternative being that it's less formal, like a "handshake agreement") Whether the terms are roughly symmetric (the alternative being that it describes an agreement with different terms for each of the two parties, like one paying the other, or one receiving more or fewer than full customer routes) If a jurisdiction of governing law is defined The easiest way for us to take the information is as a tab-text file or spreadsheet, consisting of rows as follows: Your ASN: Integer Peer ASN: Integer Written agreement: Boolean Symmetric: Boolean Governing Law: ISO 3166 two-digit country-code, or empty For instance: 42 715 false true us 42 3856 true true us The ASNs are just there so we can avoid double-counting a single pair of peers, when we hear from both of them. As soon as we've collated the data, we'll strip the ASNs to protect privacy, and only the final aggregate statistics will be published in any case. We've currently got about 10,000 sessions documented, and would love to have as many more as possible. We'd like to finish collecting data by the end of the second week of April, two weeks from now. If you're able to help us, please email me the data in whatever form you can. If you need a non-disclosure, we're happy to sign one. Thanks for considering this, -Bill Woodcock Research Director Packet Clearing House -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) iEYEARECAAYFAk2UNaUACgkQGvQy4xTRsBG9lwCfbLFFFx0VKm7SesIkc2YPIr2s nAQAoNEusliD6nzZGoJpOKVFPGXqRt/h =RbBg -----END PGP SIGNATURE----- From rfg at tristatelogic.com Thu Mar 31 04:27:23 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 31 Mar 2011 02:27:23 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: Message-ID: <39483.1301563643@tristatelogic.com> In message , Brandon Ross wrote: >On Wed, 30 Mar 2011, Ross Harvey wrote: > >> Wait a second, I'm pretty sure that in most contexts, a signature or >> letterhead means not so much "this is real because it's so obviously >> genuine", but rather: >> >> "This is real or I am willing to take a forgery rap". > >Do you think most providers check the signer's ID to make sure they >actually signed their own name? How do you prove that whomever you accuse >of signing it actually forged it if not? > >Does anyone know of there ever being even a single case where someone was >convicted of forgery for this? Excuse me, but I think that this discussion is starting to stray rather far from either the known or the reasonably plausible facts. In the first place, I do not accept the theory that either Circle Internet or Bandcon were hoodwinked by cleverly forged letterheads, and there is no evidence I am aware of which would support that theory. Until, if ever, additional facts are forthcoming, I believe that it is just as plausible that some spammer simply came to each of these companies and said to them "Hi! I really want to hijack these two unused /16 blocks. Will you help me?" and that one, or another, or perhaps both of these companies simply replied "Yea. Sure. We didn't quite make our quarterly numbers, and we are always on the lookout for new revenue streams. So how much money do you intend to give us if we help you with this, exactly?" In the second place, this amusing "letterhead fraud" theory only holds up if one also believes that, upon being presented with a mere forged letterhead, allegedly coming in "over the transom" as it were, i.e. from a previously unknown source, along with a request to announce some routes to a couple of sizable blocks of IPv4 space, neither Circle Internet nor BandCon even bothered to pick up the bleepin' phone to call the contact number that is/was plainly visible for all to see, right there in the relevant ARIN allocation WHOIS records for the IPv4 space in question. Then there is also the small matter of the name on the _checks_... you know... the checks that _somebody_ had to write, in the first instance, before either BandcCon or Circle Internet would have been likely to provide _any_ kind of service to some new and total stranger. Or was this "duped by clever forgeries" single bullet theory that you folks have been dis- cussing also intended to include the forging of CHECKS in the name of "Hoechst Celanese Corporation"? See, no matter how you slice it, both BandCon and Circle Internet have a lot of explaining to do. At the very least, and even if this implausible "forged letterhead" theory were true... which I gravely doubt... both BandCon and Circle Internet have been rather grotesquely negligent, i.e. in accepting, without any checking whatsoever, the representations made to them by some total stranger who simply para- chutted out of the clouds one day, clutching a forged letterhead in one hand and a bag of unmarked small denomination bills in the other. So that's the very least... the companies were both, at the very least, rather stupendously negligent. At the very worst on the other hand, one or another or both of them may have been entirely "in on" and part of these hijacking schemes/scams from the get-go. I myself would tend to go with the latter theory, simply because it is the only one that would seem to make any sense, you know, logically. Ask yourself which of these theories seems the most plausible? 1) The spammer forged two checks in the name "Hoechst Celanese Corporation" and gave one each to Circle Internet and BandCon, respectively, along with similarly forged letters of introduction and requests for routing of IP space. Unless I am misremembering, this means that the spammer would have engaged in not one but TWO very serious federal fraud offenses. Even sleezy low-life spammers do not customarily accept this level of risk, e.g. just to get their hands on some IPv4 space which, we must remember, is only likely to be of value to them for a relatively brief period of time, EVEN IF they can manage to keep it routed. 2) The spammers gave Circle Internet and BandCon forged letters of introduction (on forged letterheads) and requests for routing services, and gave the two companies -zero- actually money, and nonetheless, both companies started happily announcing routes for the purported "Hoechst Celanese Corporation", even though neither company received a dime for this service, and even though they both CONTINUED to provide this service, utterly for free, apparently for at least THREE FULL MONTHS. 3) The spammers gave Circle Internet and BandCon forged letters of introduction (on forged letterheads) and requests for routing services, and gave the two companies checks that were NOT "Hoechst Celanese Corporation" checks (either forged or otherwise), and then both Circle Internet and BandCon just cashed BOTH of those two checks (which were presumably written against the account of "Joe's Fly-By-Night Spammery and Pizza Parlor") and both companies cashed these two checks without ever even looking at them or even wondering aloud why "Joe's Fly-By-Night Spammery and Pizza Parlor" would be paying for Internet services which were ACTUALLY going to be delivered to the large and internationally-known Hoechst Celanese chemical company (which is, quite obviously, perfecly capable of paying its own ISP bills, thank you very much). 4) The spammers simply went to Circle Internet and BandCon and said "We want to hijack some IP space. If you help us, we'll pay you handsomly for your trouble." and both companies simply replied "Yea. Sure. We like money. And as far as we know, nobody's ever gone to jail for hijacking IP space, so, um, what the hell! When did you want to get started?" The first three theories are, in my opinion, utterly implausible. That doesn't really leave very much to wonder about. Let me put this all to you another way. I would like to respectfully suggest that anybody who is actually taking this "forged letterhead" fairy story seriously should write to both Circle Internet and BandCon, explain to them both that either their competence or their honesty, or both, have been the subject of questions here on the NANOG list, and that they would each do well to make some sort of a clarifying comment... or, if possible, a refu- tation... here on the NANOG list. If they were merly hoodwinked, well then they should come here, admit that, explain to us all exactly how it happened (so that nobody else will get taken in in the same way in future) and thus set the record straight. Yes, it will always be a bit embarrasing to admit that you were hoodwinked, but that is still a damn sight better than being publically reputed to be outright crooked. So please, if you really think that these companies were merely hoodwinked, and that they were NOT in on the (hijacking) deal from the get-go, please invite them to come here to the NANOG list and clear the air, along with their names. I got twenty bucks that says that no verifiable official representative of either company will be making an appearance here anytime soon, or that if they do, they won't be taking any questions. Any takers? Regards, rfg From morrowc.lists at gmail.com Thu Mar 31 04:48:41 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 31 Mar 2011 11:48:41 +0200 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <1FA9176F-1661-4242-9FBF-6FD1BA259954@delong.com> References: <36496.1301541975@tristatelogic.com> <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> <1FA9176F-1661-4242-9FBF-6FD1BA259954@delong.com> Message-ID: On Thu, Mar 31, 2011 at 7:57 AM, Owen DeLong wrote: > > On Mar 30, 2011, at 10:26 PM, Suresh Ramasubramanian wrote: > >> It also needs >> >> 1. Someone to complain to law enforcement >> > True, as has been brought up in the past here... some folk rely heavily upon IRR data for route prefix filtering. if the object is in the IRR database (with the right linkages), it gets permitted in router filters automagically. -chris (being able to validate 'ownership', really authorization to route, automatically will sure be nice, eh?) From morrowc.lists at gmail.com Thu Mar 31 04:49:53 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 31 Mar 2011 11:49:53 +0200 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <36496.1301541975@tristatelogic.com> <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> <1FA9176F-1661-4242-9FBF-6FD1BA259954@delong.com> Message-ID: On Thu, Mar 31, 2011 at 11:48 AM, Christopher Morrow wrote: > On Thu, Mar 31, 2011 at 7:57 AM, Owen DeLong wrote: >> >> On Mar 30, 2011, at 10:26 PM, Suresh Ramasubramanian wrote: >> >>> It also needs >>> >>> 1. Someone to complain to law enforcement >>> >> True, > > as has been brought up in the past here... some folk rely heavily upon > IRR data for route prefix filtering. if the object is in the IRR > database (with the right linkages), it gets permitted in router > filters automagically. I forgot: $ whois -h whois.radb.net 148.163.0.0 route: 148.163.0.0/16 descr: /16 for Celanese origin: AS13767 mnt-by: DBANK-MNT changed: jpope at databank.com 20090818 source: LEVEL3 (this means l3 proxy'd in the record, I think... maybe an L3 person can speak to this bit?) > -chris > (being able to validate 'ownership', really authorization to route, > automatically will sure be nice, eh?) > From rfg at tristatelogic.com Thu Mar 31 05:11:01 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 31 Mar 2011 03:11:01 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: Message-ID: <39947.1301566261@tristatelogic.com> In message , Owen DeLong wrote: >Cleaning up the routing {is not what ARIN does or thinks it should do}, true. > >However, this sounds like there are two issues... > >1. Routing -- Would be nice if the advertising provider(s) stopped doing > so. Not something ARIN can really do much about. > >2. Database -- Sounds like the existing resource holder may not still > be using the resource or may no longer exist. In either case, it's > worth having ARIN investigate the situation and take appropriate > database action if that is the case. Worth it to whom? I can tell you quite frankly that it sure as shineola isn't worth wasting even one more additional second of _my_ time to try to beg, plead, cajole, or browbeat ARIN/Curran into cleaning up the mess that is the IPv4 allocation data base. I've been down that road already, and all I have to show for it is a couple of prominent boot marks on my ass and a couple of new enemies- for-life... neither of which I really needed. And also, frankly, I am utterly dumbfounded that you, of all people, should be the one to suggest that this particular cock-up in the IPv4 allocation data base is something that should be fixed. I mean really, WTF? Didn't you, and I, and several other people already go through all of this at least a couple of dozen times already on the ARIN public policy mailing list? And wasn't it you, in particular, who was consistantly the most vocal and avid proponent of the view that ANY effort expended on cleaning up the IPv4 allocations DB would be an utter waste of time and valuable manpower, and that ultimately, any efforts along those lines would only serve to give those procrastinating on the inevitable shift to IPv6 more time to procrastinate? Seriously, I was left with the impression that if IPv6 were a person, it would be you, and that if it were a company, you would be the majority shareholder. (Not that there would be anything wrong with that.) Now all of a sudden you actually CARE about IPv4 allocations?? I say again, WTF? Color me flabberghasted. Anyway, none of this makes any difference. If somebody (you?) wants to report either or both of these hijacked IPv4 blocks to ARIN... well... be my guest. If your plan was to wait around for me to do it, you are in for a long wait. I have more productive uses for my time just now, like counting the pennies in my change jar and checking Craigslist for mint Rolls Royces priced under a dollar. Regards, rfg From ttauber at 1-4-5.net Thu Mar 31 10:33:25 2011 From: ttauber at 1-4-5.net (Tony Tauber) Date: Thu, 31 Mar 2011 11:33:25 -0400 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <36496.1301541975@tristatelogic.com> <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> <1FA9176F-1661-4242-9FBF-6FD1BA259954@delong.com> Message-ID: I don't believe this record indicates that Level3 proxy registered the route object. It means that someone used the DBANK-MNT maintainer ID in the Level3 RR to enter a route object 18 months ago. It looks like Level3 is originating the route in AS3356, not accepting it from AS13767 (which is what the object would suggest to do.) Oops, looks like the route is now gone. Guess it got cleaned. Tony On Thu, Mar 31, 2011 at 5:49 AM, Christopher Morrow wrote: > > I forgot: > $ whois -h whois.radb.net 148.163.0.0 > route: 148.163.0.0/16 > descr: /16 for Celanese > origin: AS13767 > mnt-by: DBANK-MNT > changed: jpope at databank.com 20090818 > source: LEVEL3 > > (this means l3 proxy'd in the record, I think... maybe an L3 person > can speak to this bit?) > > > -chris > > (being able to validate 'ownership', really authorization to route, > > automatically will sure be nice, eh?) > > > > From morrowc.lists at gmail.com Thu Mar 31 11:18:08 2011 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 31 Mar 2011 18:18:08 +0200 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <36496.1301541975@tristatelogic.com> <8C81E7C3-14A4-49C8-9678-BBB5096FD015@delong.com> <1FA9176F-1661-4242-9FBF-6FD1BA259954@delong.com> Message-ID: On Thu, Mar 31, 2011 at 5:33 PM, Tony Tauber wrote: > I don't believe this record indicates that Level3 proxy registered the route > object. > It means that someone used the DBANK-MNT maintainer ID in the Level3 RR to > enter a route object 18 months ago. > possibly... > It looks like Level3 is originating the route in AS3356, not accepting it > from AS13767 (which is what the object would suggest to do.) > > Oops, looks like the route is now gone.? Guess it got cleaned. > l3 ams router says: Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, S Stale Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *>i148.163.0.0/20 4.69.181.3 0 100 0 i * i 4.69.181.3 0 100 0 i *>i148.163.64.0/20 4.69.181.3 0 100 0 i * i 4.69.181.3 0 100 0 i * 148.163.178.0/24 213.206.131.45 100000 86 0 1239 13767 i * i 4.69.185.185 100 0 13767 i *>i 4.69.185.185 100 0 13767 i * 148.163.179.0/24 213.206.131.45 100000 86 0 1239 13767 i * i 4.69.185.185 100 0 13767 i *>i 4.69.185.185 100 0 13767 i * i148.163.224.0/19 4.69.181.3 0 100 0 i *>i 4.69.181.3 0 100 0 i there's a possibility that, in this case, L3 is simply holding up the /16 for their customer, sinking junk traffic and permitting more specifics by the customer? (it's not clear here, though the above seems to show sprint propogating databank's prefixes while L3 is originating some parts of the /16 still. indicates that the 2 upstreams for databank are apparently L3 and sprint. -Chris > Tony > > On Thu, Mar 31, 2011 at 5:49 AM, Christopher Morrow > wrote: >> >> I forgot: >> $ whois -h whois.radb.net 148.163.0.0 >> route: ? ? ? ? 148.163.0.0/16 >> descr: ? ? ? ? /16 for Celanese >> origin: ? ? ? ?AS13767 >> mnt-by: ? ? ? ?DBANK-MNT >> changed: ? ? ? jpope at databank.com 20090818 >> source: ? ? ? ?LEVEL3 >> >> (this means l3 proxy'd in the record, I think... maybe an L3 person >> can speak to this bit?) >> >> > -chris >> > (being able to validate 'ownership', really authorization to route, >> > automatically will sure be nice, eh?) >> > >> > > From nanog at jima.tk Thu Mar 31 12:04:33 2011 From: nanog at jima.tk (Jima) Date: Thu, 31 Mar 2011 12:04:33 -0500 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <33111.1301518430@tristatelogic.com> References: <33111.1301518430@tristatelogic.com> Message-ID: <4D94B421.7080600@jima.tk> On 03/30/2011 03:53 PM, Ronald F. Guilmette wrote: > I just stumbled onto this one the other day. > > Apparently, Spamhaus has known about this one for THREE MONTHS already: > > http://www.spamhaus.org/sbl/sbl.lasso?query=SBL98308 > > It's being routed by AS11730, aka "Circle Internet LTD", a known spammer- > friendly provider that I have come across many times in the past. > > They in turn are getting connectivity from: > > AS26769 BandCon > AS7385 Integra Telecom > > These companies are also not known for being especially scruplous either. > But I mean seriously, Jesus Christ! Does ANYBODY even give a crap about > blatant naked IP space hijacking anymore? Or is the entire net now on > its final slow descent into utter chaos? This address space seems to be offline now. I for one forwarded info to a contact at Integra, but I can't attest to whether that had anything to do with it. I guess we can call this a victory for the community? I dunno. Jima From rooknee at gmail.com Thu Mar 31 12:12:21 2011 From: rooknee at gmail.com (rr) Date: Thu, 31 Mar 2011 10:12:21 -0700 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <4D94B421.7080600@jima.tk> References: <33111.1301518430@tristatelogic.com> <4D94B421.7080600@jima.tk> Message-ID: For the record, Integra Telecom did have LOA for said netblock. Needless to say LOA was forged on company letterhead with appropriate signatures. Once brought to our attention we attempted to contact customer to no avail, netblock has been removed until they prove otherwise. Randy Rooney On Thu, Mar 31, 2011 at 10:04 AM, Jima wrote: > On 03/30/2011 03:53 PM, Ronald F. Guilmette wrote: >> >> I just stumbled onto this one the other day. >> >> Apparently, Spamhaus has known about this one for THREE MONTHS already: >> >> ? ?http://www.spamhaus.org/sbl/sbl.lasso?query=SBL98308 >> >> It's being routed by AS11730, aka "Circle Internet LTD", a known spammer- >> friendly provider that I have come across many times in the past. >> >> They in turn are getting connectivity from: >> >> ? ?AS26769 ?BandCon >> ? ?AS7385 ? Integra Telecom >> >> These companies are also not known for being especially scruplous either. >> But I mean seriously, Jesus Christ! ?Does ANYBODY even give a crap about >> blatant naked IP space hijacking anymore? ?Or is the entire net now on >> its final slow descent into utter chaos? > > ?This address space seems to be offline now. ?I for one forwarded info to a > contact at Integra, but I can't attest to whether that had anything to do > with it. > > ?I guess we can call this a victory for the community? ?I dunno. > > ? ? Jima > > From nanog at jima.tk Thu Mar 31 12:15:35 2011 From: nanog at jima.tk (Jima) Date: Thu, 31 Mar 2011 12:15:35 -0500 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: References: <33111.1301518430@tristatelogic.com> <4D94B421.7080600@jima.tk> Message-ID: <4D94B6B7.3040704@jima.tk> On 03/31/2011 12:12 PM, rr wrote: > For the record, Integra Telecom did have LOA for said netblock. > Needless to say LOA was forged on company letterhead with appropriate > signatures. Once brought to our attention we attempted to contact > customer to no avail, netblock has been removed until they prove > otherwise. Thank you for your forthright answer. I can't speak for others, but I appreciate the clarification. Jima From mpetach at netflight.com Thu Mar 31 13:27:33 2011 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 31 Mar 2011 11:27:33 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <39947.1301566261@tristatelogic.com> References: <39947.1301566261@tristatelogic.com> Message-ID: On Thu, Mar 31, 2011 at 3:11 AM, Ronald F. Guilmette wrote: > ... > Seriously, I was left with the impression that if IPv6 were a person, it > would be you, and that if it were a company, you would be the majority > shareholder. ?(Not that there would be anything wrong with that.) I for one would put money on the table towards the "rename Owen to Mr. IPv6" effort. I think it would be wonderful to be able to honestly say "IPv6 is in da house!" every time the person formerly known as Owen walked into the room at ARIN meetings. :D Matt From mehmet at akcin.net Thu Mar 31 13:55:17 2011 From: mehmet at akcin.net (Mehmet Akcin) Date: Thu, 31 Mar 2011 11:55:17 -0700 Subject: NAP Capital Region Culpeper Message-ID: <27392489-8D59-4648-A381-1FE435BA13AD@akcin.net> Hello I am looking for people who has space and / or network in Terremark culpeper , please contact me off-list ( or people who is planning to get there sometime soon..) mehmet From sfouant at shortestpathfirst.net Thu Mar 31 14:01:55 2011 From: sfouant at shortestpathfirst.net (Stefan Fouant) Date: Thu, 31 Mar 2011 15:01:55 -0400 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <39947.1301566261@tristatelogic.com> Message-ID: <00e101cbefd6$1ba10b90$52e322b0$@net> > -----Original Message----- > From: Matthew Petach [mailto:mpetach at netflight.com] > Sent: Thursday, March 31, 2011 2:28 PM > > I for one would put money on the table towards the "rename Owen to Mr. > IPv6" > effort. I think it would be wonderful to be able to honestly say > "IPv6 is in da > house!" every time the person formerly known as Owen walked into the > room at ARIN meetings. :D +1 | That, or "The evangelist formerly known as Owen..." :p Stefan Fouant From rfg at tristatelogic.com Thu Mar 31 14:32:51 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 31 Mar 2011 12:32:51 -0700 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: Message-ID: <46473.1301599971@tristatelogic.com> In message , rr wrote: >For the record, Integra Telecom did have LOA for said netblock. >Needless to say LOA was forged on company letterhead with appropriate >signatures. Once brought to our attention we attempted to contact >customer to no avail, netblock has been removed until they prove >otherwise. > >Randy Rooney Mr. Rooney, Since you have been kind enough to drop by, you know, to help clarify what went on here, I wonder if you would mind very much just providing a couple of small additional clarifications. First, could you tell me what job title you hold at Integra Telecom please? (I wouldn't even ask, but you are apparently posting from a gmail account, and that always makes me a bit... well... leary.) Second, because I am actually an ignorant son-of-a-bitch (despite any possible appearances to the contrary), I wonder if, just for my personal edification, you could tell me exactly what "LOA" stands for in this context. (Yes, I really don't know, but would like to.) Thirdly, I'd very much like to know if your company is in the habit of providing services (e.g. transit, routing) to other parties at no charge, and for extended periods of time Lastly, assuming that your company is NOT in the habit of providing services (e.g. routing, transit) to other parties at no charge, then I think that I can speak for many here when I say that I would really appreciate it if you could tell me/us whose name was on the check that was used to pay for the services that your company apparently did provide to the 159.223.0.0/16 IP block, apparently for a period in excess of three months. If in fact the other party involved in this incident deceived and defrauded you in some way, then I hardly think that this information, i.e. the name on the check that paid for all this, is something that Integra has any special obligation to keep secret. Even if there ever had been any such obligation, leagl, ethical, or otherwise, I do believe that the other party involved has now nullified any such obligation by their very act of comitting a rather outrageous and damaging fraud upon your company. I look forward to your response. Regards, rfg From mlarson at verisign.com Thu Mar 31 15:05:19 2011 From: mlarson at verisign.com (Matt Larson) Date: Thu, 31 Mar 2011 16:05:19 -0400 Subject: Final step of .com DNSSEC deployment Message-ID: <20110331200519.GX30164@DUL1MLARSON-M2.labs.vrsn.com> As part of the deployment of DNSSEC in .com, the zone has been signed and in a "deliberately unvalidatable" state for several weeks. Late last week the .com key material was unobscured and the actual keys have been visible in the zone since March 24. The final step in the deployment was publishing the .com zone's DS record in the root zone. I am pleased to report that the root zone including a DS record for .com was published at approximately 1500 UTC today, March 31. Matt Larson, on behalf of the many people at Verisign who made this deployment possible From rooknee at gmail.com Thu Mar 31 15:24:47 2011 From: rooknee at gmail.com (rr) Date: Thu, 31 Mar 2011 13:24:47 -0700 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <46473.1301599971@tristatelogic.com> References: <46473.1301599971@tristatelogic.com> Message-ID: Hmm, thought it was a NANOG prerequisite to be able to do a google search. Should be pretty easy to find this info with that tool in your handbag. With the above tool I've got your phone # and would be happy to call you if you'd like clarification on our process. Please just reply to me off-list. Randy On Thu, Mar 31, 2011 at 12:32 PM, Ronald F. Guilmette wrote: > > In message , > rr wrote: > >>For the record, Integra Telecom did have LOA for said netblock. >>Needless to say LOA was forged on company letterhead with appropriate >>signatures. Once brought to our attention we attempted to contact >>customer to no avail, netblock has been removed until they prove >>otherwise. >> >>Randy Rooney > > > Mr. Rooney, > > Since you have been kind enough to drop by, you know, to help clarify what > went on here, I wonder if you would mind very much just providing a couple > of small additional clarifications. > > First, could you tell me what job title you hold at Integra Telecom please? > (I wouldn't even ask, but you are apparently posting from a gmail account, > and that always makes me a bit... well... leary.) > > Second, because I am actually an ignorant son-of-a-bitch (despite any > possible appearances to the contrary), I wonder if, just for my personal > edification, you could tell me exactly what "LOA" stands for in this context. > (Yes, I really don't know, but would like to.) > > Thirdly, I'd very much like to know if your company is in the habit of > providing services (e.g. transit, routing) to other parties at no charge, > and for extended periods of time > > Lastly, assuming that your company is NOT in the habit of providing services > (e.g. routing, transit) to other parties at no charge, then I think that I > can speak for many here when I say that I would really appreciate it if you > could tell me/us whose name was on the check that was used to pay for the > services that your company apparently did provide to the 159.223.0.0/16 IP > block, apparently for a period in excess of three months. > > If in fact the other party involved in this incident deceived and defrauded > you in some way, then I hardly think that this information, i.e. the name > on the check that paid for all this, is something that Integra has any > special obligation to keep secret. ?Even if there ever had been any such > obligation, leagl, ethical, or otherwise, I do believe that the other > party involved has now nullified any such obligation by their very act > of comitting a rather outrageous and damaging fraud upon your company. > > I look forward to your response. > > > Regards, > rfg > > From owen at delong.com Thu Mar 31 15:24:02 2011 From: owen at delong.com (Owen DeLong) Date: Thu, 31 Mar 2011 13:24:02 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <00e101cbefd6$1ba10b90$52e322b0$@net> References: <39947.1301566261@tristatelogic.com> <00e101cbefd6$1ba10b90$52e322b0$@net> Message-ID: On Mar 31, 2011, at 12:01 PM, Stefan Fouant wrote: >> -----Original Message----- >> From: Matthew Petach [mailto:mpetach at netflight.com] >> Sent: Thursday, March 31, 2011 2:28 PM >> >> I for one would put money on the table towards the "rename Owen to Mr. >> IPv6" >> effort. I think it would be wonderful to be able to honestly say >> "IPv6 is in da >> house!" every time the person formerly known as Owen walked into the >> room at ARIN meetings. :D > > +1 | That, or "The evangelist formerly known as Owen..." :p > > Stefan Fouant > > ROFLMAO Owen From rafael at miaminoc.com Thu Mar 31 15:34:33 2011 From: rafael at miaminoc.com (Rafael Cresci) Date: Thu, 31 Mar 2011 13:34:33 -0700 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: References: <39947.1301566261@tristatelogic.com> <00e101cbefd6$1ba10b90$52e322b0$@net> Message-ID: >> I for one would put money on the table towards the "rename Owen to Mr. >> IPv6" >> effort. I think it would be wonderful to be able to honestly say >> "IPv6 is in da >> house!" every time the person formerly known as Owen walked into the >> room at ARIN meetings. :D "Like a v6, like a v6" could be the soundtrack... :-) []s Rafael Cresci From wschultz at bsdboy.com Thu Mar 31 16:25:37 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Thu, 31 Mar 2011 14:25:37 -0700 Subject: IPv6 SEO implecations? In-Reply-To: References: <4F427F24-E9D4-4B7B-ACCF-9F9E52D8C336@bsdboy.com> <201103310039.31080.a.harrowell@gmail.com> Message-ID: <9B7B1455-5DFE-4048-8B24-27BFF03CCBA5@bsdboy.com> On Mar 30, 2011, at 4:55 PM, Wil Schultz wrote: > > > On Mar 30, 2011, at 4:39 PM, Alexander Harrowell wrote: > >> On Tuesday 29 Mar 2011 17:54:27 Wil Schultz wrote: >>> On Mar 29, 2011, at 3:51 AM, Franck Martin wrote: >>> >>> >>> And here's a breakdown of which user agents are seen on which ip, as you can >> see the user-agent doesn't exactly match IP range. >>> >>> Googlebot-Image/1.0 >> >>> Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html); >> >>> DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; >> +http://www.google.com/bot.html) >> >>> SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 >> UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; >> +http://www.google.com/bot.html) >> >> Interesting that there are Googlebot mobile devices! Perhaps user-experience >> testing of some kind? Googlers? Or IPv6 testing of the devices themselves? >> Although those user strings are indicative of not very recent, non-Android >> phones. >> >> Would be interesting to see the percentages of traffic by each user agent. >> -- >> The only thing worse than e-mail disclaimers...is people who send e-mail to >> lists complaining about them > > I've got the logs still but I've torn down the VIP. I'll send hit count percentages tomorrow. > > -wil As promised, here are some percentages. By IP, seems there are three main IP addresses: 2001:4860:4801:1302:0:6006:1300:b075 --> 0.33% 2001:4860:4801:1303:0:6006:1300:b075 --> 0.17% 2001:4860:4801:1401:0:6006:1300:b075 --> 0.31% 2001:4860:4801:1402:0:6006:1300:b075 --> 0.17% 2001:4860:4801:1404:0:6006:1300:b075 --> 1.34% 2001:4860:4801:1405:0:6006:1300:b075 --> 48.1% 2001:4860:4801:1407:0:6006:1300:b075 --> 24.82% 2001:4860:4801:1408:0:6006:1300:b075 --> 24.70% By user-agent: Googlebot-Image/1.0 --> 0.003% Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html); --> 7.26% DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) --> 0.005% SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) --> 92.73% And finally, percentages of IP to user-agent: Googlebot-Image/1.0 --> 0.003% of total 2001:4860:4801:1404:0:6006:1300:b075 30% 2001:4860:4801:1408:0:6006:1300:b075 30% 2001:4860:4801:1405:0:6006:1300:b075 40% Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html); --> 7.26% of total 2001:4860:4801:1401:0:6006:1300:b075 1.21% 2001:4860:4801:1302:0:6006:1300:b075 1.42% 2001:4860:4801:1404:0:6006:1300:b075 2.11% 2001:4860:4801:1303:0:6006:1300:b075 2.28% 2001:4860:4801:1402:0:6006:1300:b075 2.39% 2001:4860:4801:1407:0:6006:1300:b075 9.02% 2001:4860:4801:1408:0:6006:1300:b075 37.15% 2001:4860:4801:1405:0:6006:1300:b075 44.40% DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) --> 0.005% of total 2001:4860:4801:1407:0:6006:1300:b075 5.88% 2001:4860:4801:1405:0:6006:1300:b075 17.64% 2001:4860:4801:1408:0:6006:1300:b075 35.29% 2001:4860:4801:1404:0:6006:1300:b075 41.18% SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html) --> 92.73% of total 2001:4860:4801:1401:0:6006:1300:b075 0.24% 2001:4860:4801:1302:0:6006:1300:b075 0.25% 2001:4860:4801:1404:0:6006:1300:b075 1.27% 2001:4860:4801:1408:0:6006:1300:b075 23.79% 2001:4860:4801:1407:0:6006:1300:b075 26.06% 2001:4860:4801:1405:0:6006:1300:b075 48.39% -wil From rfg at tristatelogic.com Thu Mar 31 19:46:24 2011 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 31 Mar 2011 17:46:24 -0700 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: Message-ID: <49839.1301618784@tristatelogic.com> In message , rr wrote: >Hmm, thought it was a NANOG prerequisite to be able to do a google >search. Should be pretty easy to find this info with that tool in your >handbag. Which info is that, exactly? Your title at Integra Telecom? Umm... well... yes.... I guess this is you, right? http://www.linkedin.com/pub/randy-rooney/6/9ab/22a So, are you THE Engineering Manager, or merely AN Engineering Manager at Integra Telecom? I'm guessing that it is a big enough outfit that you probably have more than one. (Sorry, but I can't help snickering a bit at your _prior_ employment. As I feel sure you are already painfully aware, having that on your resume does not exactly inspire a whole lotta confidence in the notion that you are a straight shooter. The words ``cover up'' are the ones that come most immediately to mind.) >With the above tool I've got your phone # and would be happy to call >you if you'd like clarification on our process. No thanks. I didn't ask for "clarification" of your "process" (whatever the hell THAT might mean), and frankly it doesn't interest me. Your process is... well... your process. Whatever it may be, it belongs to you and you should probably keep it to yourself. (Who knows? Since business processes are now patentable, maybe someday you can get a patent on it!) I did however ask for the name of the crook whose name was on the check that paid for the hijacked space routing. Is that something you can respond to, or no? If not, why not? Was Integra Telecom _actually_ defrauded? If so, who defrauded you? Did your customer, Circle Internet defraud you? If you are claining that THEY are also an innocent party in this, then who defrauded them? Whose name was on the check that THEY cashed? It really is a rather simple question, and doesn't require an elaborate, convoluted, or lengthy digression into the details of your "process". Ya know, maybe it's just me, but it would seem to me that that if either you or your customer, Circle Internet, were in fact defrauded in this case, that both of you would be altogether ready, willing, and indeed eager to ``out'' the actual crooked perpetrator... you know... instead of, like, hiding the perp's identity and thus helping him to cover his tracks. But I guess that's just me. (When somebody cheats _me_, I am not myself in the habit of then going out of my way to protect him.) Don't misunderstand me. If your company was in fact dedrauded, then allow me to express my sincere condolences for your loss. Or would it be more accurate to say your gain? You DID cash the check right? I mean your company does NOT have a policy of granting everybody three months of free service, right? >Please just reply to me off-list. No thanks. As Jodie Foster said in the movie Contact, ``This isn't a person to person call.'' Crooks, hijacking, and mass spamming affect everybody on the whole Internet. I didn't ask for the name of the crook who signed the check just for my private or personal edification. Other ISPs should know who they need to be on the lookout for. I can assure you that just because YOU have now stopped routing space for this crook, that doesn't mean that he's going to just fold up his tent and slink quietly away into oblivion. In fact I already have evidence in hand that he's still got both IP space and snowshoe spamming domains located elsewhere (including elsewhere on Circle Internet, see below) that he is continuing to use, even as we speak. On the other hand, of course, if Integra and/or Circle Internet were in fact ``in on the game'' from the get-go, then in that case I could well and truly understand why both of your companies might now be reluctant to give up your cohort. Regards, rfg P.S. I gather that nobody at your place even so much as raised an eyebrow when tiny little Circle Internet, a company whose biggest _legitimate_ IP block prior to this incident was a mere /21, suddenly showed up on your doorstep asking to have an entire fresh new /16, belonging to an major, internationally known chemical company routed for them, correct? P.P.S. OK, so you are reluctant to give up the actual hijacker. So let's just skip that for now. Instead how about if you just tell us who owns the followng domain names which are all getting DNS from Circle Internet IP space, even as we speak. And no, I _do not_ want you to just regurgitate the fradulent bull puckey that's present within the relevant WHOIS records. (To paraphrase Red Riding Hood "My my grandma! What a lot of domains you have!" Odd that all of them were created so recently, and that none of them seem even have associated web sites. But again, I'm sure that I'm the only one in the Universe who finds any of that odd. Yea.) 208.85.32.114 dns2.virtualcheck.info pinkcreditscore.info pinkcreditreport.info pinkcreditdeals.info orangereports.info orangeoffers.info orangegifts.info orangecreditsco.info orangecreditreport.info orangecreditdeals.info onlinecredit-check.info myfreecredtiscore.info knowyourself.info healthsample.info happinessonline.info freecreditscore360.info doctors-orders.info creditscorealerts.info 208.85.32.246 ns2.rockboys1a.com yesimprove.info withoutinvestigate.info withoutcritique.info withinfocus.info withenable.info visionconsolidate.info versuscoordinate.info validateinstruct.info untilreview.info untilfocus.info unforgettableidea.info underneathunlikemeasure.info underneathunlike.info uncommonsuggestion.info uncommonguidance.info unbelievableguidance.info trumpenforce.info totutor.info topconvert.info tipsproduce.info timesenable.info throughreview.info throughoutcompare.info thansurvey.info terrificexplain.info surveydelegate.info supremeteach.info supplyindividualize.info submitteach.info submitinstruct.info strikingtrust.info strikingproposal.info staggeringlearn.info sincesurvey.info searchrecommend.info searchproduce.info searchprioritize.info retrievelive.info retrievechic.info reserveenable.info researchgrow.info remarkablesubject.info registersimulate.info registeradvise.info reducequick.info recordteach.info recordinstruct.info recordenable.info reconcilelearn.info reconcilefresh.info raresubject.info quickhandle.info projectmaxi.info projectabc.info phenomenalmentor.info pastexperiment.info outstandingprove.info orderinstil.info orderevaluate.info operateinstil.info operateevaluate.info ontostimulate.info ontoexperiment.info ontoadvise.info offconduct.info noteworthyeducation.info nearbyinvestigate.info nearbyindividualize.info moremanage.info measurenavigate.info measurecontract.info marvellousteach.info marvellousintroduce.info magnificienttell.info locatemerge.info locateimprove.info locatehire.info locatedelegate.info likesurvey.info keyinspect.info investigatereview.info investigateinspect.info inexamine.info hotappoint.info groovyrecommend.info forsimulate.info followingteach.info flexlead.info flexconsider.info filecoordinate.info fantasticlearn.info failingevaluate.info extraordinarysuggestion.info extraordinaryproposal.info extraordinarylearn.info extractterminate.info extractapprove.info experimentsecure.info executeenable.info excludingdetect.info exceptionalwisdom.info exceptionaltutor.info exceptionalinfo.info examinelead.info estimateok.info estimatedouble.info dreamsupervise.info downmeasure.info distributefocus.info determineup.info detectlead.info despiteinstruct.info dealsstrengthen.info dayinspect.info critiqueattain.info cooloversee.info conservemax.info conductimprove.info conducthandle.info conducteliminate.info concerningfocus.info concerning.info computefind.info completehire.info compiletutor.info compileevaluate.info codesimulate.info coachstimulate.info classifytrain.info classifycoordinate.info circainform.info butindividualize.info budgetover.info budgetgrow.info besthandle.info besideevaluate.info beneathsimulate.info belowexamine.info behindsimulate.info barringcoordinate.info atopsurvey.info atopextract.info atenable.info atcompare.info assistindividualize.info answersimulate.info amongextract.info againstsimulate.info advocateevaluate.info abovemotivate.info finelovewithme.com whosthefarest.com rockboys1b.com rockboys1a.com leanbackfront.com ns1.rockboys1a.com 155 yesimprove.info withoutinvestigate.info withoutcritique.info withinfocus.info withenable.info visionconsolidate.info versuscoordinate.info validateinstruct.info untilreview.info untilfocus.info unforgettableidea.info underneathunlikemeasure.info underneathunlike.info uncommonsuggestion.info uncommonguidance.info unbelievableguidance.info trumpenforce.info totutor.info topconvert.info tipsproduce.info timesenable.info throughreview.info throughoutcompare.info thansurvey.info terrificexplain.info surveydelegate.info supremeteach.info supplyindividualize.info submitteach.info submitinstruct.info strikingtrust.info strikingproposal.info staggeringlearn.info sincesurvey.info searchrecommend.info searchproduce.info searchprioritize.info retrievelive.info retrievechic.info reserveenable.info researchgrow.info remarkablesubject.info registersimulate.info registeradvise.info reducequick.info recordteach.info recordinstruct.info recordenable.info reconcilelearn.info reconcilefresh.info raresubject.info quickhandle.info projectmaxi.info projectabc.info phenomenalmentor.info pastexperiment.info outstandingprove.info orderinstil.info orderevaluate.info operateinstil.info operateevaluate.info ontostimulate.info ontoexperiment.info ontoadvise.info offconduct.info noteworthyeducation.info nearbyinvestigate.info nearbyindividualize.info moremanage.info measurenavigate.info measurecontract.info marvellousteach.info marvellousintroduce.info magnificienttell.info locatemerge.info locateimprove.info locatehire.info locatedelegate.info likesurvey.info keyinspect.info investigatereview.info investigateinspect.info inexamine.info hotappoint.info groovyrecommend.info forsimulate.info followingteach.info flexlead.info flexconsider.info filecoordinate.info fantasticlearn.info failingevaluate.info extraordinarysuggestion.info extraordinaryproposal.info extraordinarylearn.info extractterminate.info extractapprove.info experimentsecure.info executeenable.info excludingdetect.info exceptionalwisdom.info exceptionaltutor.info exceptionalinfo.info examinelead.info estimateok.info estimatedouble.info dreamsupervise.info downmeasure.info distributefocus.info determineup.info detectlead.info despiteinstruct.info dealsstrengthen.info dayinspect.info critiqueattain.info cooloversee.info conservemax.info conductimprove.info conducthandle.info conducteliminate.info concerningfocus.info concerning.info computefind.info completehire.info compiletutor.info compileevaluate.info codesimulate.info coachstimulate.info classifytrain.info classifycoordinate.info circainform.info butindividualize.info budgetover.info budgetgrow.info besthandle.info besideevaluate.info beneathsimulate.info belowexamine.info behindsimulate.info barringcoordinate.info atopsurvey.info atopextract.info atenable.info atcompare.info assistindividualize.info answersimulate.info amongextract.info againstsimulate.info advocateevaluate.info abovemotivate.info finelovewithme.com whosthefarest.com rockboys1b.com rockboys1a.com leanbackfront.com From brett at the-watsons.org Thu Mar 31 20:04:34 2011 From: brett at the-watsons.org (Brett Watson) Date: Thu, 31 Mar 2011 18:04:34 -0700 Subject: HIJACKED: 159.223.0.0/16 -- WTF? Does anybody care? In-Reply-To: <49839.1301618784@tristatelogic.com> References: <49839.1301618784@tristatelogic.com> Message-ID: <8CACADAD-19A2-4EF7-8649-E91D1BA08A9A@the-watsons.org> On Mar 31, 2011, at 5:46 PM, Ronald F. Guilmette wrote: > (Sorry, but I can't help snickering a bit at your _prior_ employment. > As I feel sure you are already painfully aware, having that on your > resume does not exactly inspire a whole lotta confidence in the notion > that you are a straight shooter. The words ``cover up'' are the ones > that come most immediately to mind.) Awww, that makes me "not a straight shooter"? I was at EBS, I just happened to join a company who's management weren't straight shooters. And what all these accusations and attacks have to do with the thread, I have no idea. From jonny.ogawa at gmail.com Thu Mar 31 20:14:03 2011 From: jonny.ogawa at gmail.com (Joao C. Mendes Ogawa) Date: Fri, 1 Apr 2011 03:14:03 +0200 Subject: Fwd: IPv4 Address Exhaustion Effects on the Earth Message-ID: FYI --Jonny Ogawa ----- Forwarded message from Stephen H. Inden ----- From: Stephen H. Inden Subject: IPv4 Address Exhaustion Effects on the Earth Date: Fri, 1 Apr 2011 00:19:08 +0200 To: Global Environment Watch (GEW) mailing list X-Mailer: Apple Mail (2.1084) X-Mailman-Version: 2.1.9 List-Id: "GEW mailing list." IPv4 Address Exhaustion Effects on the Earth By Stephen H. Inden April 1, 2011 At a ceremony held on February 3, 2011 the Internet Assigned Numbers Authority (IANA) allocated the remaining last five /8s of IPv4 address space to the Regional Internet Registries (RIRs). With this action, the free pool of available IPv4 addresses was completely depleted. Since then, several scientists have been studying the effects of this massive IPv4 usage (now at its peak) on the Earth. While measuring electromagnetic fields emanating from the world's largest IPv4 Tier-1 backbones, NASA scientists calculated how the IPv4 exhaustion is affecting the Earth's rotation, length of day and planet's shape. Dr. Ron F. Stevens, of NASA's Goddard Space Flight Center, said all packet switching based communications have some effect on the Earth's rotation. It's just they are usually barely noticeable. Until now. "Every packet affects the Earth's rotation, from a small ping to a huge multi-terabyte download. The problem with IPv4 is its variable length header and tiny address space that can cause an electromagnetic unbalance on transmission lines. The widespread adoption of Network Address Translation (NAT) on IPv4 networks is making the problem even worse, since it concentrates the electromagnetic unbalance. This problem is not noticeable with IPv6 because of its fixed header size and bigger 128 bits address space", Dr. Stevens said. Over the past few years, Dr. Stevens has been measuring the IPv4 growing effects in changing the Earth's rotation in both length of day, as well as gravitational field. When IPv4 allocation reached its peak, last February, he found out that the length of day decreased by 2.128 microseconds. The electromagnetic unbalance is also affecting the Earth's shape -- the Earth's oblateness (flattening on the top and bulging at the Equator) is decreasing by a small amount every year because of the increasing IPv4 usage. The researcher concluded that IPv4 usage has reached its peak and is causing harmful effects on the Earth: "IPv4 is, indeed, harmful. Not only 32 bits for its address space has proven too small and prone to inadequate solutions like NAT, it is now clear that its electromagnetic effects on the Earth are real and measurable." The solution? "I'm convinced that the only permanent solution is to adopt IPv6 as fast as we can", says Dr. Stevens. -- From wschultz at bsdboy.com Thu Mar 31 20:26:34 2011 From: wschultz at bsdboy.com (Wil Schultz) Date: Thu, 31 Mar 2011 18:26:34 -0700 Subject: IPv4 Address Exhaustion Effects on the Earth In-Reply-To: References: Message-ID: On Mar 31, 2011, at 6:14 PM, "Joao C. Mendes Ogawa" wrote: > FYI > > --Jonny Ogawa > > ----- Forwarded message from Stephen H. Inden ----- > > From: Stephen H. Inden > Subject: IPv4 Address Exhaustion Effects on the Earth > Date: Fri, 1 Apr 2011 00:19:08 +0200 > To: Global Environment Watch (GEW) mailing list > X-Mailer: Apple Mail (2.1084) > X-Mailman-Version: 2.1.9 > List-Id: "GEW mailing list." > > > IPv4 Address Exhaustion Effects on the Earth > > By Stephen H. Inden > April 1, 2011 > > At a ceremony held on February 3, 2011 the Internet Assigned Numbers > Authority (IANA) allocated the remaining last five /8s of IPv4 address > space to the Regional Internet Registries (RIRs). With this action, > the free pool of available IPv4 addresses was completely depleted. > > Since then, several scientists have been studying the effects of this > massive IPv4 usage (now at its peak) on the Earth. > > While measuring electromagnetic fields emanating from the world's > largest IPv4 Tier-1 backbones, NASA scientists calculated how the IPv4 > exhaustion is affecting the Earth's rotation, length of day and > planet's shape. > > Dr. Ron F. Stevens, of NASA's Goddard Space Flight Center, said all > packet switching based communications have some effect on the Earth's > rotation. It's just they are usually barely noticeable. Until now. > > "Every packet affects the Earth's rotation, from a small ping to a > huge multi-terabyte download. The problem with IPv4 is its variable > length header and tiny address space that can cause an electromagnetic > unbalance on transmission lines. The widespread adoption of Network > Address Translation (NAT) on IPv4 networks is making the problem even > worse, since it concentrates the electromagnetic unbalance. This > problem is not noticeable with IPv6 because of its fixed header size > and bigger 128 bits address space", Dr. Stevens said. > > Over the past few years, Dr. Stevens has been measuring the IPv4 > growing effects in changing the Earth's rotation in both length of > day, as well as gravitational field. When IPv4 allocation reached its > peak, last February, he found out that the length of day decreased by > 2.128 microseconds. The electromagnetic unbalance is also affecting > the Earth's shape -- the Earth's oblateness (flattening on the top and > bulging at the Equator) is decreasing by a small amount every year > because of the increasing IPv4 usage. > > The researcher concluded that IPv4 usage has reached its peak and is > causing harmful effects on the Earth: > > "IPv4 is, indeed, harmful. Not only 32 bits for its address space has > proven too small and prone to inadequate solutions like NAT, it is now > clear that its electromagnetic effects on the Earth are real and > measurable." > > The solution? > > "I'm convinced that the only permanent solution is to adopt IPv6 as > fast as we can", says Dr. Stevens. > > -- > It's all true. Alse I've been weighing my router and it's 7 lbs heavier with the addition of all these new ip addresses in it's routing table. -wil From ops.lists at gmail.com Thu Mar 31 21:12:01 2011 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Fri, 1 Apr 2011 07:42:01 +0530 Subject: HIJACKED: 148.163.0.0/16 -- WTF? Level3 is now doing IP hijacking?? In-Reply-To: <00e101cbefd6$1ba10b90$52e322b0$@net> References: <39947.1301566261@tristatelogic.com> <00e101cbefd6$1ba10b90$52e322b0$@net> Message-ID: On Fri, Apr 1, 2011 at 12:31 AM, Stefan Fouant wrote: > > +1 | That, or "The evangelist formerly known as Owen..." :p No no ... TEFKAO. -- Suresh Ramasubramanian (ops.lists at gmail.com)