From dmfh at dmfh.cx Fri Oct 1 00:22:04 2010 From: dmfh at dmfh.cx (DMFH) Date: Fri, 1 Oct 2010 01:22:04 -0400 Subject: NANOG Digest, Vol 32, Issue 119 In-Reply-To: References: Message-ID: <20101001052204.1690729599@127.0.0.1> Thu, 30 Sep 2010 14:22:07 +0000 nanog-request at nanog.org fuream loqour : >If your network is of a scale where it exceeds the utility of static, >then, it is almost certainly of a scale >and topology where it exceeds the utility of RIP. I'd agree that RIP is old, aged, and we all can probably go on with personal horror stories of how a broadcast-only-based routing protocol created a small or large pocket of disaster alone or combined with some other technology below or above its layer in the stack. However, like some other speakers in this thread mentioned, situation + simplicity + engineering = success. RIP certainly has it's place in small pockets now, I still use it in places mostly just to float a few loopbacks or statics around with old equipment, or firewalls I don't trust doing a more robust routing protocol. I see routing protocols, operating systems too, as different tools. If the tool works, fits, and rarely breaks where it's used, cool - I like simple & predictable, which includes predictable failure as well as predictable success. RIP also has the advantage of being around for a long while, so most devices will "get it right" - more complex routing protocol code, found in other IGPs, etc. - exceptions / vendor implementations still rule. I've never done a multicast network with RIP though... *winks* =) /dmfh -- __| |_ __ / _| |_ 01100100 01101101 / _` | ' \| _| ' \ 01100110 01101000 \__,_|_|_|_|_| |_||_| dmfh(-2)dmfh.cx From manavbhatia at gmail.com Fri Oct 1 00:37:58 2010 From: manavbhatia at gmail.com (Manav Bhatia) Date: Fri, 1 Oct 2010 11:07:58 +0530 Subject: Using crypto auth for detecting corrupted IGP packets? In-Reply-To: <8943BD09-32CF-4F83-9EBE-1558679E1FEF@puck.nether.net> References: <8943BD09-32CF-4F83-9EBE-1558679E1FEF@puck.nether.net> Message-ID: > > I really wish there was a good way to (generically) keep a 4-6 hour buffer of all control-plane traffic on devices. While you can do that with some, the forensic value is immense when you have a problem. > Buffering for 4-6 hours worth of control traffic is HUGE! What about mirroring your control traffic arriving on your network ports to some other dedicated port? Manav From rfg at tristatelogic.com Fri Oct 1 00:47:34 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Thu, 30 Sep 2010 22:47:34 -0700 Subject: AS11296 -- Hijacked? Message-ID: <6777.1285912054@tristatelogic.com> I received a nice email from a very polite graduate student just now, who shall remain nameless, and I decided that I wanted to give him the reply below, but also to post this all to NANOG too, so here it is. I hope this may ally some of the concern that has been expressed about me not being more forthcomeing about the details of this case. (And if anybody gives me a hard time about being ``off topic'' then I'm going to give him or her a knucke sandwich, because I was specifically asked... indeed badgered... to provide more explanation of, and more justification for my earlier posting, as the record in the archives of this list will clearly show.) The friendly graduate student wote: >I've been quietly following NANOG's little flamewar over this. I'm >interested in what techniques you used to arrive at your conclusion >regarding AS11296. > >Unfortunately for me, I'm not a network op. Instead, I am a PhD student >interested in all matters inter-domain. I hope you feel this is enough >to make me a worthy recipient. No, actually, it isn't. If I google you can I be _sure_ that you're not playing for the other team? Probably not. But the good news is that I have decided to be a bit less cagey generally, and specifically in my public comments about these things anyway, and to give out more confirming data bits anyway. And I'll be sending this letter on to the NANOG list soon, with your name redacted, of course. What follows below is information that could be gleened (if you know how) from whois.internic.net. It's all public info. I just rearrange it and print it out in a nice pretty way. (Of course knowing where to look within the vast IPv4 address space is also quite helpful, but I'm not going to get in to that.) The bottom line here is that if you get the whois records for the domains associated with the name servers in the list attached at the end, you'll see that they are all going to be ``fishy'' in some way, e.g. ``cloaked'' (aka ``privacy protected''), or else registered to some mystery fly-by night company that may or may not actually exist, or at any rate, the domains will all be registered to something sort-of stealthy... something which is intended to make the spammer behind all this a bit harder to find. Oh yea, and the snail mail addresses given in the WHOIS records for the domains will usually/often be tracable to UPS Store rental P.O. boxes... those are standard spammer favorites, because...as they well know... us spamfighters can't find out who really controls any one of those boxes without a subpoena... unlike USPS boxes, for instance. (All this is quite well known in the dank sleezy spammer undergound already, so I'm not hardly giving away any secrets here.) And in a similar vein, the contact phone numbers given in the whois records will quite typically be 1-800 or 1-888 or 1-877 or 1-866 toll-free numbers. No, the spammers are _not_ trying to save you money when you want to call them up to bitch to them about the fact that they sent you 8,372 spams in a row. Nope, again, they use the toll-free numbers for a very specific purpose, which is again to make it more difficult for anyone trying to track them down to find their actual physical location. Non-tollfree numbers are typically associated with a specific geographic vicinity (although even that is being substantially eroded by number portability). But the toll free numbers are truly and always utterly geographically anonymous. So spammers use them a lot, primarily in domain whois records. So here you are. You've got this s**t load of highly ``fishy'' name servers, and they are all planted firmly into IP space that (a) appears to have been allocated to a reputable name brand company... such as Seiko, in this case... *and* (b) the block in question, based on the RegDate: and Updated: fields of the block's ARIN whois record, apparently hasn't been touched for years... maybe even a decade or more... thus implying that the former owners of the block either have abandoned it years ago, or else they themselves went belly up and ceased to exist, probably during the Great Dot Com Crash of 2000. Add it all up and what does it spell? No, not heartburn... Hijack. See, there actually isn't any big mystery about any of this, except the part about how I came to focus on this particular set of IP blocks and/or the particular AS that was announcing routes to them. And about that part, I have nothing to say, except to tell these spammers (who are probably listening) what I always say... that spamming is THE most public of all crimes. If you really think that you an hide and be totally invisible, even while you blast MILLIONS of total strangers with your advertising, then you need to up your lithium, because the dosage you're on now clearly isn't doing the job. Oh, and one other small thing... Even though the spammers try to hide themselves, often times, they really don't try THAT hard, probably because most folks don't care enough to really learn how to track these kinds of schmucks down, so in general, they only have to be a little stealthy... not a lot stealthy, and they know that. But using hijacked space raises the bar a little. In this context, you shouldn't really use all P.O. boxes that are on your same island, just because you are too effing lazy to take a ferry to the mainland once a month to pick up your hate mail from your anonymous UPS drop box. I can't really tell you exactly who engineered the hijacking in this case. Somebody with some network savvy obviously. What I suspect I _can_ tell you is which spammer (who runs a false-front ``affiliate marketing'' operation, just as cover story for their own snowshoe spamming... as most of the serious snowshoers do these days) most probably sub-leased the IP space from whoever actually engineered the hijacking. Look at the snail-mail addresses in the whois records for the domains listed below. Yes, they are UPS boxes, but look at the general location, Victoria, BC. So now go and google for "affiliate marketing" and "Victoria". There really aren't that many probable suspects. Victoria ain't a terribly big place. Not like, e.g. Vancouver. But then the schmuck would have to take the ferry over once a month to collect his hate mail from his mainland anonymous UPS box, and he's too effing lazy to do that. That's why he's a spammer, because he's too effing lazy and untalented to get honest work, or even to learn an honest trade, you know, like male hooker. (Hey! At least it's consensual, unlike spamming.) (Nishant? I know you're listening. Now you WILL make sure that Tobyn gets a copy of this posting, won't you? That's a good boy. Thanks. Effing assholes!) Could it possibly be that I'm jumping to the Wrong Conclusion here about who the spammer is, I mean just based on something as flimsy as geographic proximity? Sure, but not bloody likely. You see that's not hardly the only evidence that I have in front of me. I'm just not talking about the rest. (And I hope it keeps the son of a bitch up nights trying to figure out how ELSE he phuked up, in addition to being lazy and using only local UPS drop boxes.) Regards, rfg P.S. Some or all of the data presented below may still be available via whois.internic.net, even though the IP blocks are no longer even routed. Try this for example: whois -h whois.internic.net 206.226.96.2 Yup. Still there. At least for now. Probably be gone by morning. P.P.S. To all of the spammers out there reading this who think that you have learned from this e-mail how to be more stealthy still, and how to hide from me even better in the future... well... enjoy your fantasy while it lasts. I can find you now, I can find you next year, and I'll be able to find you ten years from now. And do you know why? Because I'm smarter than you are. And that's not saying much. If you had any talent... any talent at all... then you'd be able to find an HONEST job. It wouldn't pay as well, but at least you wouldn't be ashamed to tell your mother what you _actually_ do for a living. In the meantime, please hurry up and die. The world will most definitely be a better place when we no longer have to carry your dead weight on the backs of humanity. Don't flatter yourselves. You make nothing. You build nothing. You contribute nothing. You just annoy people. For money. We will make sure that that exact epitaph is engraved on your headstone, so that you will be remembered properly, once you go. ================================================================ 63.247.172.3 ns1.tooplacedomain10tht.info 63.247.172.4 ns2.tooplacedomain10tht.info 63.247.181.3 ns1.steadyvolumebandw57.info 63.247.181.4 ns2.steadyvolumebandw57.info 63.247.185.19 ns1.magnumfourcompkriel.info 63.247.185.20 ns2.magnumfourcompkriel.info 199.241.95.253 fwd1.itargetdirect.net 206.226.64.4 ns1.granadacentral.info 206.226.64.5 ns2.granadacentral.info 206.226.96.2 ns1.sandpipedream.com ns1.optinletters.com ns1.notifications-mail.com ns1.mailingdaily.com ns1.blueholster.com ns1.allowingmail.com 206.226.96.3 ns2.sandpipedream.com ns2.optinletters.com ns2.notifications-mail.com ns2.mailingdaily.com ns2.blueholster.com ns2.allowingmail.com 206.226.112.2 ns1.drainagecorner.com 206.226.112.3 ns2.drainagecorner.com 206.226.112.130 ns1.calculatingdigits.com 206.226.112.131 ns2.calculatingdigits.com 206.226.112.194 ns1.mailcreatures.com 206.226.112.195 ns2.mailcreatures.com 206.226.113.2 ns1.qualitycampaigns.com 206.226.113.3 ns2.qualitycampaigns.com 206.226.113.66 ns1.onlyinstant.com 206.226.113.67 ns2.onlyinstant.com 206.226.114.194 ns1.droppedtargets.com 206.226.114.195 ns2.droppedtargets.com 206.226.115.2 ns1.dinneroutstanding.com 206.226.115.3 ns2.dinneroutstanding.com 206.226.116.130 ns1.offersenveloped.com 206.226.116.131 ns2.offersenveloped.com 206.226.117.2 ns1.sleekrange.com 206.226.117.3 ns2.sleekrange.com 206.226.117.66 ns1.thegulfofmail.com 206.226.117.67 ns2.thegulfofmail.com 206.226.118.2 ns1.mailmammals.com 206.226.118.3 ns2.mailmammals.com 206.226.118.66 ns1.trackpreference.com 206.226.118.67 ns2.trackpreference.com 206.226.119.2 ns1.platinumpermission.com 206.226.119.3 ns2.platinumpermission.com 206.226.119.130 ns1.approvedcity.com 206.226.119.131 ns2.approvedcity.com 206.226.120.130 ns1.creaturesofmail.com 206.226.120.131 ns2.creaturesofmail.com 206.226.121.2 ns1.tonnesofmail.com 206.226.121.3 ns2.tonnesofmail.com 206.226.122.2 ns1.cancellationsanytime.com 206.226.122.3 ns2.cancellationsanytime.com 206.226.123.2 ns1.hourofman.com 206.226.123.3 ns2.hourofman.com 206.226.124.2 ns1.businessneedsfilled.com 206.226.124.3 ns2.businessneedsfilled.com 206.226.124.130 ns1.underestimatedhours.com 206.226.124.131 ns2.underestimatedhours.com 206.226.126.2 ns1.companiesthatperform.com 206.226.126.3 ns2.companiesthatperform.com 206.226.126.130 ns1.pageuppleasure.com 206.226.126.131 ns2.pageuppleasure.com 206.226.127.2 ns1.transferredtraffic.com 206.226.127.3 ns2.transferredtraffic.com From gbonser at seven.com Fri Oct 1 01:34:16 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 30 Sep 2010 23:34:16 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: <6777.1285912054@tristatelogic.com> References: <6777.1285912054@tristatelogic.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Ronald F. Guilmette [mailto:rfg at tristatelogic.com] > Sent: Thursday, September 30, 2010 10:48 PM > To: nanog at nanog.org > Subject: Re: AS11296 -- Hijacked? > ================================================================ > 63.247.172.3 > ns1.tooplacedomain10tht.info > 63.247.172.4 > ns2.tooplacedomain10tht.info > 63.247.181.3 > ns1.steadyvolumebandw57.info > 63.247.181.4 > ns2.steadyvolumebandw57.info > 63.247.185.19 > ns1.magnumfourcompkriel.info > 63.247.185.20 > ns2.magnumfourcompkriel.info ... I would take more of an Occam's razor approach. If you have an AS that is supposedly an ISP in North Carolina or Ohio or wherever and first of all have only one way into their network (are they an ISP or are they simply reselling someone else's service?) and none of that connectivity traces back to their region of operation, and particularly where their name has been bought by or merged with someone else and that someone else is not announcing their AS and address blocks, then that is certainly cause for suspicion. "Hijacking" of defunct resources is probably a widespread activity. Finding the hijacked resources of companies that liquidated in fairly public fashion is probably easier than finding resources for a company that has been "laundered" through several mergers over several years where the current company doesn't even realize that they "own" the resources of a company bought by a company they bought because of personnel turnover involved with layoffs and such. To the general population of this list: Have you worked for a company that has liquidated? Are those Internet resource registrations still in whois? Maybe you should inform ARIN so those resources can be reclaimed. I did that when I noticed that a company I once worked for that evaporated still had resources in the database. That is just ASKING for someone to announce those resources and nobody is probably going to blink an eye because the upstreams rarely check to see if the entity they are talking to are actually authorized to announce that space. You tell them the ASN and net blocks, the two jibe, upstream says OK. How much address space is being wasted in this way? G From rfg at tristatelogic.com Fri Oct 1 02:14:22 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 01 Oct 2010 00:14:22 -0700 Subject: AS27626, AS6061, AS10392, AS11296 - Hijacks Gone Wild! Message-ID: <7220.1285917262@tristatelogic.com> [[ NOTE: This information is being made available to information content providers, or others, as part of the technical means to restrict access to material with may be deemed by some to be obscene, lewd, lascivious, filthy, excessively violent, harassing, or otherwise objectionable, in accordance with 47 USC 230(c)(2)(B). ]] Whew! Now that I got THAT out of the way... I _had_ planned on dribbling out this info, one AS at a time, because I thought that might yield a slightly more ponderous effect, but since another big batch of this info was already made (semi-)public today on another mailing list I'm on, there doesn't seem to be any real point in dragging this out anymore. So here is the whole enchalada... at least with respect to THIS whole interconnected mess. (Yes, there are others. We'll get to them. Be patient.) AS27626, aka Joytel of Jacksonville, Florida, would appear to be at the heart of a rather sizable AS and IP block hijacking campaign, the likes of which, in my experience, the net has never before seen. I mean the total amount of IP space that's been jacked may be smaller than some past big-time hijacks, but this one takes the cake, I think, for the number of separate different IP blocks involved... a number which has actually even been growing stedily over the past week. (These turkeys appear to be in a race to corner the market on abandoned IP blocks. Jeeeesh!) In addition to a metric buttload of jacked blocks being announced by Joytel ltself, AS27626, (see below) there are _three_ other ASes that also appear to be jacked, and each of these also appears to be separately announcing routes to yet more jacked IP blocks. But all of these machinations appear to be to be tied together, if in no other way, then at least by the common thread of the same single common snowshoe spamming company (in Victoria, BC) being the primary (but probably not the only) ultimate beneficiary of all of this hijacking. I have already reported here on two of these other ASes, i.e. AS11296 and AS10392. I now report on a third apparently hijacked AS, i.e. AS6061. See details below. Note that the routes that were being announced by AS11296 have already been withdrawn, but the old route announcements are still listed below, for the sake of completeness. Additionally, I am reporting here on three somewhat stealthy IP blocks that appear to have been legitimately obtained by Joytel... two on Level3 and one on Cogent... all of which appear to me to be infested with/by _some_ snowshoe spammer. (Perhaps someone or something other than the previously mentioned company in Victoria, BC. I haven't actually checked that yet, one way or the other.) As indicated below, the various blocks that I've annotated as "jacked" are in fact, and exclusively, very old, and most probably abandoned IP blocks. That's why they were chosen, specifically, i.e. because it was thought that nobody would miss them, and nobody would even notice that they had been ``liberated''. And that probably would have been true, if it were not for the fact that some of them were then filled up with snowshoe spam domains. As I mentioned previously, spamming is THE most public of crimes. It's hard to make any money at it unless you are annoying millions of people at a time, and thus alerting them to your presence. And when you do that, you are going to draw attention to yourself, big time. I'm not going to even make any sort of suggestion to people, this time, as to what they might want to do with all of the information below, since people gave me a hard time when I did that before. So I'll just leave it as this: You are all clever people here. Use your imagination. I have included below a very partial NS dump for one of the blocks being announced by AS10392 that shows some of the snowshoe pattern there. If people want to see the complete NS dumps for all of the blocks listed below, so that they can independently verify the snowshoey-ness of all this stuff, then ask and you shall receive. One last thing... AS11296 (Interpath) was (is?) only connected to the net via AS27524 (Xeex). Since it is no longer announcing any routes, this is moot, and a non-issue at this time. Everything else you see below all represents open issues. I would like to especially beg, plead, and cajole any customers of AS3491, aka Beyond The Network America, Inc. who may be reading this to PLEASE contact your provider and demand an answer to this simple question: WTF do they think they are doing by peering with AS6061 and AS10392, and who the bleep is actually writing them monthly checks for that? Beyond The Network America, Inc. needs to answer for this too, since they are unambiguously facilitating this ongoing crime. As regards to the ongoing situation with AS27626, aka Joytel, you can readily see here who is keeping _them_ alive and connected: http://www.robtex.com/as/as27626.html#graph AS3356 -- Level3 AS33132 -- FPL FiberNet, LLC If you are a customer of either of these providers, or even a peer, I do encourage you to contact them, and ask them WTF they are thinking. I, for one, sure would like to know. Regards, rfg ============================================================================= AS27626 (Joytel.net, Jacksonville, FL): 24.230.0.0/19 NET-24-230-0-0-1 jacked - empty 68.67.64.0/20 NET-68-67-64-0-1 legit -- GoRack, LLC (Jacksonville, FL) 192.100.5.0/24 NET-192-100-5-0-1 jacked - empty 192.100.88.0/24 NET-192-100-88-0-1 jacked - empty 192.100.134.0/24 NET-192-100-134-0-1 jacked - empty 192.100.143.0/24 NET-192-100-143-0-1 jacked - empty 192.101.177.0/24 NET-192-101-177-0-1 jacked - empty 192.101.187.0/24 NET-192-101-187-0-1 jacked - empty 192.235.32.0/19 NET-192-235-32-0-1 jacked - empty 198.13.16.0/20 NET-198-13-16-0-1 jacked - empty 198.14.16.0/20 NET-198-14-16-0-1 jacked - empty 198.143.128.0/19 NET-198-143-128-0-1 jacked - empty 198.183.32.0/19 NET-198-183-32-0-1 jacked - mucho snowshoe ns 198.210.32.0/19 NET-198-210-32-0-1 jacked - empty 198.241.64.0/18 NET-198-241-64-0-1 jacked - mucho snowshoe ns 198.252.64.0/18 NET-198-252-64-0-1 jacked - empty 199.34.128.0/18 NET-199-34-128-0-1 jacked - empty 199.46.32.0/19 NET-199-46-32-0-1 jacked - empty 199.84.64.0/19 NET-199-84-64-0-1 jacked - empty 199.198.160.0/19 NET-199-198-140-0-1 jacked - empty 204.48.64.0/19 NET-204-48-64-0-1 jacked - empty 204.107.208.0/24 NET-204-107-208-0-1 jacked - just two spammer ns'es 205.144.0.0/20 NET-205-144-0-0-1 jacked - mucho snowshoe ns 206.224.160.0/19 NET-206-224-160-0-1 jacked - empty 206.227.64.0/18 NET-206-227-64-0-1 jacked - empty 208.93.220.0/22 NET-208-93-220-0-1 Actually does belong to Joytel! 216.49.0.0/18 NET-216-49-0-0-1 jacked - empty 216.245.64.0/18 NET-216-245-64-0-1 jacked - empty ============================================================================= AS6061 (Datalytics, Inc - connected only via AS3491 -- Hijacked AS?): 198.187.64.0/18 NET-198-187-64-0-1 198.187.64.0/20 jacked - mucho snowshoe ns 198.187.80.0/20 jacked - mucho snowshoe ns 198.187.96.0/20 jacked - empty 198.187.112.0/20 jacked - empty 209.201.128.0/17 NET-209-201-128-0-1 209.201.128.0/20 jacked - empty 209.201.144.0/20 jacked - empty 209.201.160.0/20 jacked - empty 209.201.176.0/20 jacked - empty 209.201.192.0/20 jacked - empty 209.201.208.0/20 jacked - empty 209.201.224.0/20 jacked - empty 209.201.240.0/20 jacked - empty ============================================================================= AS10392 (GlassCity Internet, Inc. - connected only via AS3491): 192.171.64.0/19 NET-192-171-64-0-1 jacked - some snowshoe 204.137.224.0/19 NET-204-137-224-0-1 jacked - empty 205.164.0.0/18 NET-205-164-0-0-1 205.164.0.0/20 jacked - mucho snowshoe ns 205.164.16.0/20 jacked - empty 205.164.32.0/20 jacked - empty 205.164.48.0/20 jacked - empty 192.171.64.156 1 ns1.carnhamandassochaddel.info 6 youworkinginternationalco.info topgunandinmcb.info picallilyaframeco.info peacondeliverycopcogas.info chillonagabrainpower.info enabledsearchingforcrossco.net 192.171.64.157 1 ns2.carnhamandassochaddel.info 6 youworkinginternationalco.info topgunandinmcb.info picallilyaframeco.info peacondeliverycopcogas.info chillonagabrainpower.info enabledsearchingforcrossco.net ... ============================================================================= AS11296 (Interpath - Routed only via AS27524 Xeex aka NR Software/Nishant Ramachandran): http://www.thefreelibrary.com/USi+Completes+Restructuring,+Receives+$81+Million+Investment+From...-a086466936 http://www.att.com/gen/press-room?pid=5097&cdvn=news&newsarticleid=22973 63.247.160.0/19 NET-63-247-160-0-1 jacked - empty -- popularfh.com -- all MXes DoA 199.241.64.0/19 NET-199-241-64-0-1 jacked - snowshoe ns @ 199.241.95.253 -- no email! 206.226.64.0/18 NET-206-226-64-0-1 jacked - snowshoe ns @206.226.96.{2,3} seikotsi.com -- Grand Cayman 11-20-2009 206.226.64.0/24 206.226.65.0/24 206.226.66.0/24 206.226.67.0/24 206.226.68.0/24 206.226.69.0/24 206.226.70.0/24 206.226.71.0/24 206.226.72.0/24 206.226.73.0/24 206.226.74.0/24 206.226.75.0/24 206.226.76.0/24 206.226.77.0/24 206.226.78.0/24 206.226.79.0/24 206.226.96.0/19 ============================================================================= Legitimate semi-stealth allocations: Joytel on Level3: 8.22.200.0/21 (snowshoe) Joytel on Level3: 8.24.224.0/20 (snowshoe) Joytel on Cogent: 38.124.176.0/20 (snowshoe) ============================================================================= From rdobbins at arbor.net Fri Oct 1 02:14:53 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 1 Oct 2010 07:14:53 +0000 Subject: Using crypto auth for detecting corrupted IGP packets? In-Reply-To: References: <8943BD09-32CF-4F83-9EBE-1558679E1FEF@puck.nether.net> Message-ID: <14643A97-2A17-4859-93EB-9CC4187FDCBA@arbor.net> On Oct 1, 2010, at 11:07 AM, Manav Bhatia wrote: > Buffering for 4-6 hours worth of control traffic is HUGE! If 4-6 hours of *control-plane* traffic on a given device is 'HUGE!', for some reasonable modern value of 'HUGE!', then there's definitely a problem on the network in question. ;> ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From manavbhatia at gmail.com Fri Oct 1 02:31:48 2010 From: manavbhatia at gmail.com (Manav Bhatia) Date: Fri, 1 Oct 2010 13:01:48 +0530 Subject: Using crypto auth for detecting corrupted IGP packets? In-Reply-To: <14643A97-2A17-4859-93EB-9CC4187FDCBA@arbor.net> References: <8943BD09-32CF-4F83-9EBE-1558679E1FEF@puck.nether.net> <14643A97-2A17-4859-93EB-9CC4187FDCBA@arbor.net> Message-ID: > >> Buffering for 4-6 hours worth of control traffic is HUGE! > > If 4-6 hours of *control-plane* traffic on a given device is 'HUGE!', for some reasonable modern value of 'HUGE!', then there's definitely a problem on the network in question. With BFD alone (assuming 20 sessions, 50ms timer) you will have 400pps. In 6 hours you will have around 8000K BFD packets. Add OSPF, RSVP, BGP, LACP (for lags), dot1AG, EFM and you would really get a significant number of packets to buffer. Cheers, Manav From rdobbins at arbor.net Fri Oct 1 02:49:25 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Fri, 1 Oct 2010 07:49:25 +0000 Subject: Using crypto auth for detecting corrupted IGP packets? In-Reply-To: References: <8943BD09-32CF-4F83-9EBE-1558679E1FEF@puck.nether.net> <14643A97-2A17-4859-93EB-9CC4187FDCBA@arbor.net> Message-ID: <043AE224-2A9C-453B-B6E7-B782AC6B7C28@arbor.net> On Oct 1, 2010, at 1:01 PM, Manav Bhatia wrote: > In 6 hours you will have around 8000K BFD packets. Add OSPF, > RSVP, BGP, LACP (for lags), dot1AG, EFM and you would really get a > significant number of packets to buffer. Which isn't a 'HUGE!' amount of packets. ;> ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From luigi at net.t-labs.tu-berlin.de Fri Oct 1 02:51:05 2010 From: luigi at net.t-labs.tu-berlin.de (Luigi Iannone) Date: Fri, 1 Oct 2010 09:51:05 +0200 Subject: LISP Works - Re: Facebook Issues/Outage in Southeast? In-Reply-To: References: <20100923173347.1E6D67EA@resin06.mta.everyone.net> <1E9490CA-3AC3-43DD-AE46-051927DE4C86@instituut.net> Message-ID: <96331CEE-6647-46E6-B638-A595AE395345@net.t-labs.tu-berlin.de> On Sep 30, 2010, at 17:15 , Job W. J. Snijders wrote: > Dear Cameron & everybody, > > On Wed, Sep 29, 2010 at 8:32 PM, Job W. J. Snijders wrote: > >>>> The fact that LISP does help in IPv6 Transition solutions (due to its >>>> inherent AF agnostic design), is compelling. As you say, real end 2 end is >>>> the goal - and LISP helps here, regardless of the AF. (you'll will still >>>> want to do multi-homing in IPv6, and ingress TE, and mobility, etc.). > > Have you already joined the LISP Beta Network? All you need is a > router that can run the LISP images (871, 1841, 2821, 7200 etc) > FYI There is also an opensource version (www.openlisp.org) L. > It's completely open, and the guys behind > lisp-support at external.cisco.com can hook you up for free, provide you > with everything you need: beta image, a block of public ipv4/ipv6 > space and configuration guides, although it's only about 10 lines of > config. :-) > > You could use LISP at home, like I do, and get some hands on > experience - enjoy the net behind LISP! > > http://lisp4.cisco.com/ provides more information. > > Kind regards, > > Job Snijders > From ryan.finnesey at HarrierInvestments.com Fri Oct 1 03:45:35 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Fri, 1 Oct 2010 01:45:35 -0700 Subject: First Data Corporation? In-Reply-To: References: Message-ID: <6EFFEFBAC68377459A2E972105C759EC03009FE5@EXVBE005-2.exch005intermedia.net> I am also looking for the same info. Any luck finding a contact? Cheers Ryan -----Original Message----- From: Leo Woltz [mailto:leo.woltz at gmail.com] Sent: Wednesday, September 29, 2010 8:50 PM To: nanog at nanog.org Subject: First Data Corporation? Anyone on the list from First Data Corporation or familar with there network? From andy at nosignal.org Fri Oct 1 03:56:26 2010 From: andy at nosignal.org (Andy Davidson) Date: Fri, 1 Oct 2010 09:56:26 +0100 Subject: (cisco, or any) acl *reducers* out there? In-Reply-To: <5083397C-550D-40F9-89D2-9C076274AE55@apnic.net> References: <5F0D0E5F-2BB3-43EB-B56A-F622763D78C3@apnic.net> <5083397C-550D-40F9-89D2-9C076274AE55@apnic.net> Message-ID: On 19 Aug 2010, at 04:23, George Michaelson wrote: >>> something which can take a couple of hundred basic and extended ACLs and tell you >>> these don't work >>> these conflict >>> the remaining have a sequence and can reduce to this basic set > A reasonable call. Its probably where we'll be by default, because there isn't anything there and I think first principles upward is better than paring back. > [...] > I think its clear a tool like I asked doesn't exist, and very probably won't, anytime soon. Hello [ I'm sorry this reply is so late, holiday season ] I understand the problem and think that it is partly caused by the complexity of keeping the acl configuration on all edge ports in sync, and keeping the acl definitions/purpose documented. The way around this, is to have a configuration management system that records the detail of the ACL (description / ticket number - along with the filter specification in generic terms), which generates the configuration - or even better uses flow-specification to distribute the rules. Further procedures to review the data in this management system periodically help this scale. For the config management, this would tend to have to be locally bespoke (but simple to produce) in order to fit with existing policy and procedure, but the glue to push these rules out to routers is easy as open source tools exist :- http://labs.ripe.net/Members/thomas_mangin/content-exabgp-new-tool-interact-bgp http://bgp.exa.org.uk/ Andy From rfg at tristatelogic.com Fri Oct 1 04:22:10 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 01 Oct 2010 02:22:10 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time Message-ID: <7865.1285924930@tristatelogic.com> So ARIN put up on their web site this fancy schmancy web form that allows a person to report fraud relating to ARIN number resources. Here's what the introduction to that page says, exactly as it appears on ARIN's web site: This reporting process is to be used to notify ARIN of suspected Internet number resource abuse including the submission of falsified utilization or organization information, unauthorized changes to data in ARIN's WHOIS, hijacking of number resources in ARIN's database, or fraudulent transfers. Well, that's what it says anyway. And being naive, I actually believed that the folks at ARIN might actually give a rat's ass about all these kinds of fraud that they have enumerated above. Boy was I wrong! I just received the response attached below to one of my earlier reports using that form. And I gotta tell you, its an eye opener. Apparently the fine folks at ARIN, clever bureaucrats that they are, have subtly but substantially redefined the specific kinds of ``fraud'' they care to hear about and/or investigate, so that contrary to the above, mere hijacking of ASes or IP blocks isn't actually something that they want to hear about, much less DO anything about. Nope! Apparently, ARIN's fraud reporting form is only to be used for reporting cases where somebody has fiddled one of ARIN's whois records in a fradulent way. If somebody just waltzes in and starts announcing a bunch of routes to a bunch of hijacked IP space from a hijacked ASN (or two, or three) ARIN doesn't want to hear about it. In those rare cases where the perp is considerate enough to ALSO fiddle the relevant WHOIS records in some fradulent way, THEN (apparently) ARIN will get involved, but only to the extent of re-jiggering the WHOIS record(s). Once that's been done, they will happily leave the perp to announce all of the fradulent routes and hijacked space he wants, in perpetuity. Apparently, they consider the hijacking itself as being totally out of their charter to even look at or investigate. ONLY if a WHOIS record has been fiddled will they give a damn, and then the only one thing they will give a damn about will be the WHOIS record... and the rest of the net can go to hell, because hay! Not our problem man! Now I _know_ full well that by posting this rant here, the usual assortment of knuckle-walker throwbacks who still yearn for the wonderful rule-less frontier every-man-for-himself-and-no-sherrifs fun filled days of the old 20th Century Internet, will pipe up immediately and say `Good! Goddammit we don't want no steekin' ARIN to be ``policing'' anything at all. F**k that! Total anarchy is the best of all possible systems.' You know what? I don't care. Let them come. Let them lumber around and scream and pound their fists and try to tell me that because *I* didn't get onto the Internet until 1983 (or because their router can beat up my router) that they somehow magically outrank me, and that their opinions are God and mine are worthless. That's quite obviously horse shit. How do you have a pecking order anyway in a self-avowed anarchy? Sorry, no. The two are not compatible. I've got as much right to an opinion as you do. And until proved otherwise, mine is as valid as your's. And my opinion is that this sucks. ARIN's attitude sucks. And they are apparently redefining the word ``fraud'' in a way that will insure that they will have to do minimal work, and that they'll never ever have to do anything that might be ``hard'' in the sense of possibly being the lest bit contro- versial, you know, like telling some hijacker ``Stop doing that.'' Yes, I'm sure that there are a lot of people here who will pipe up and say that it's just wonderful that ARIN is useless and that ARIN will do nothing. Their anachronistic anarchist philosophy is not a philosophy. It's merely an abdication of responsibility, and should be seen as such. It is just a lazy man's way of avoiding having to think about how a society should be organized. It is the coward's way of avoiding making rules that some members of the group might find controversial. On the net, hijacking of IP space is just about the deepest kind of violation of the commonly accepted rules of how to behave in this shared space that I can imagine. And now, the people who _issue_ the IP space assignments say that they don't care to _police_ the very assignments that they themselves have made! Well then what's the bleeping point of even having them or their whole bloody allocation system then? I say let's disband the Federal Reserve *and* ARIN, because they are all just a bunch of useless bureaucrats at this point who are serving nobody other than themselves. If we are going to have anarchy, then bring it on! Let's not have this half-assed sort of anarchy that we have now. Let's have the real thing! I'm going out tomorrow and I'm going to buy me the biggest router than I can afford. Then I'm going to get it colocated someplace, and then I'm going to start announcing all the routes I feel like, and nobody will do shit about it... because its not their job man! And some people still wonder why this planet is so f**ked up. Geeezzz. Regards, rfg P.S. It ain't as if I'm either asking or expecting anybody from ARIN to take a plane out to that place where the hunters shot down that cable, or some exchange point in Bumf**k, Idaho, and with guns drawn, physically pull the wire out of the socket. No. I'm *not* asking for that kind of ``policing''. But Christ! They could at least take a position, instead of simply standing around with their hands in their pockets. Is that really too much to ask? They could say, to everyone involved, and to the community as a whole, ``This ain't right. *We* maintain the official allocation records. In most cases, *we* made the allocations, and that guy should NOT be announcing routes to that IP space, and he shouldn't be announcing anything at all via that AS number, because these things ain't his.'' That's all. I'd just like to see them maybe take a postion. I'm quite sure that ARIN corporate counsel has advised them to never take a position on anything... kind-of like Minister Hacker in "Yes, Minister", who often hoped that the government could have NO position on anything the least bit controversial...except with respect to things that might erode their own power, you know, like the position that IP addresses are not property, which they try desperately to maintain (against all obvious facts to the contrary) as a way of keeping courts out of the business of saying who gets what, so that they can maintain their own total and absolute sovereignty over this shit, with no annoying judges to get in their way. But you know, if they won't even take a position on a bloody blatant hijacking by low life spammer slugs and/or by others who the spammers have paid Big Bucks to, to steal the space for them, they really, like I said, what's the point of even having an allocation ``authority''? (And obviously, I am using that term very very loosely here, because they clearly only care to use their ``authority'' when it makes everybody happy, and won't use it at all when it might make even one lone spammer/hijacker sad. If there is a better definition of cowardice and abdication, I don't know what it is.) ------- Forwarded Message Replied: Fri, 01 Oct 2010 00:49:08 -0700 Replied: hostmaster at arin.net Return-Path: hostmaster at arin.net Delivery-Date: Thu Sep 30 08:30:13 2010 Return-Path: X-Original-To: rfg at tristatelogic.com Delivered-To: rfg at tristatelogic.com Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) by segfault.tristatelogic.com (Postfix) with ESMTP id 389DDBDC34 for ; Thu, 30 Sep 2010 08:30:13 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id 89AD4165331; Thu, 30 Sep 2010 11:30:07 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.2.5-arin1 (2008-06-10) on smtp1.arin.net X-Spam-Level: X-Spam-Status: No, score=-144.2 required=5.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX,USER_IN_WHITELIST autolearn=no version=3.2.5-arin1 Received: from pgp.arin.net (pgp.arin.net [192.136.136.159]) by smtp1.arin.net (Postfix) with ESMTP id 5F592165324 for ; Thu, 30 Sep 2010 11:30:07 -0400 (EDT) Received: by pgp.arin.net (Postfix, from userid 688) id 37E9F1A8069; Thu, 30 Sep 2010 11:30:07 -0400 (EDT) Received: from shell.arin.net (shell.arin.net [192.136.136.149]) by pgp.arin.net (Postfix) with ESMTP id AD3C81A8103 for ; Thu, 30 Sep 2010 11:30:06 -0400 (EDT) Received: by shell.arin.net (Postfix, from userid 2006) id C6F5D8059; Thu, 30 Sep 2010 11:30:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by shell.arin.net (Postfix) with ESMTP id C5B0A8058; Thu, 30 Sep 2010 11:30:06 -0400 (EDT) Date: Thu, 30 Sep 2010 11:30:06 -0400 (EDT) From: hostmaster at arin.net X-X-Sender: jonw at shell.arin.net To: rfg at tristatelogic.com Subject: Re: [ARIN-20100928-F683] Fraud Report Confirmed In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, Thanks for your report. > AS11296 appears to have been hijacked. > > Separately and additionally, all of the IPv4 blocks currently being > announced by AS11296 appear to have been hijacked also: > > 63.247.160.0/19 > 199.241.64.0/19 > 206.226.64.0/24 > 206.226.65.0/24 > 206.226.66.0/24 > 206.226.67.0/24 > 206.226.68.0/24 > 206.226.69.0/24 > 206.226.70.0/24 > 206.226.71.0/24 > 206.226.72.0/24 > 206.226.73.0/24 > 206.226.74.0/24 > 206.226.75.0/24 > 206.226.76.0/24 > 206.226.77.0/24 > 206.226.78.0/24 > 206.226.79.0/24 > 206.226.96.0/19 We've looked through these records and can't find any unauthorized changes. Do you have any further details regarding unauthorized changes to ARIN's Whois data? If not, we can't take action. We can investigate fraudulent changes to registration data, but we can't investigate fraudulent activity related to use of numbering resources (e.g. routing of resources by someone other than the registrant). If you have any further questions, comments, or concerns please respond to this message or contact me directly. Regards, Jon Worley Senior Resource Analyst ARIN Registration Services https://www.arin.net/ hostmaster at arin.net 703.227.0660 Are you ready for IPv6? For information on transitioning to IPv6, see: https://www.arin.net/knowledge/about_resources/v6/v6.html - -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFMpKz/ZKymzxl/LaURAvVuAJsFT6DZxoZ5O13SDRKWK6Lkz1yusgCdFt01 aMTBE0O/ucnRx+8rk8+QbEE= =qqf5 - -----END PGP SIGNATURE----- ------- End of Forwarded Message From owen at delong.com Fri Oct 1 04:21:24 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 02:21:24 -0700 Subject: RIP Justification In-Reply-To: <4CA49714.40007@brightok.net> References: <4CA49041.1080305@brightok.net> <712B5BDF-D6CC-4FE4-ABAF-C2958DF974DE@delong.com> <4CA49714.40007@brightok.net> Message-ID: <6A6C628F-0595-45D0-8ED2-63C44D760219@delong.com> On Sep 30, 2010, at 6:56 AM, Jack Bates wrote: > On 9/30/2010 8:46 AM, Owen DeLong wrote: >> I have no NAT whatsoever in my home network. RIP is not at all useful in my scenario. >> >> I have multiple routers in my home network. They use a combination of BGP and OSPFv3. >> > > Except you must configure those things. The average home user cannot. > The average home user cannot configure RIP. What is your point? >> If your network is of a scale where it exceeds the utility of static, then, it is almost certainly of a scale >> and topology where it exceeds the utility of RIP. > > While it is possible for a router to create static routes automatically based on DHCPv6 assignment information, this has no loop prevention and is suboptimal depending on the configuration that things get plugged in. I'm not talking good network design here. I'm talking, buy box, plug in wherever it fits. Things should work. > RIP has no loop prevention and is suboptimal depending on the configuration that things get plugged in. RIP breaks more often than DHCP in my experience. Owen From jtk at cymru.com Fri Oct 1 04:26:23 2010 From: jtk at cymru.com (John Kristoff) Date: Fri, 1 Oct 2010 04:26:23 -0500 Subject: Using crypto auth for detecting corrupted IGP packets? In-Reply-To: <8943BD09-32CF-4F83-9EBE-1558679E1FEF@puck.nether.net> References: <8943BD09-32CF-4F83-9EBE-1558679E1FEF@puck.nether.net> Message-ID: <20101001042623.3f5005c4@t61p> On Fri, 1 Oct 2010 00:25:34 -0400 Jared Mauch wrote: > I really wish there was a good way to (generically) keep a 4-6 hour > buffer of all control-plane traffic on devices. While you can do that > with some, the forensic value is immense when you have a problem. Not precisely what you're looking for, but you can monitor the OSPF database in other ways. See some of early OSPF work described here for instance: I had written a simple utility to grab the LSA counts and checksum values from a set of routers.when I converted a RIP network to OSPF. The network consisted of about 25 routers and 300 routes. It was invaluable to as a sanity check to see if all routers were in agreement. Packet Design's Route Explorer may be a commercial implementation of this sort of thing. I've only an early version of that at an earlier NANOG and have never used it. It seemed like cool technology at the time, but don't take that as an endorsement. Ob op note: I do recall one older IOS router where it would never have exactly the same checksum values as the other. After manually inspecting the routes I had concluded that it was an artifact of the IOS code being run, which was an old 11.x train and the only one in the net at the time. John From owen at delong.com Fri Oct 1 05:25:56 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 03:25:56 -0700 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: <14DEDC0A-D15E-49C4-8D96-33CB85761C8A@delong.com> Try asking for one of the following: 1. Farmer Line 2. Alarm Circuit I think there are a few other ways to ask for a dry pair that might circumvent the limited know-how of the people you are talking to, but, I don't recall them off the top of my head. Owen On Sep 30, 2010, at 1:52 PM, Brandon Galbraith wrote: > Has anyone had any luck lately getting dry pairs from AT&T? I'm in the > Chicago area attempting to get a dry pair between two buildings (100ft > apart) for some equipment, but when speaking to several folks at AT&T the > response I get is "You want AT&T service without the service? That's not > logical!". Had no problems 3-4 years ago getting these sorts of "circuits", > but it appears it's gone the way of the dodo now. Any emails off-list are > appreciated. > > -- > Brandon Galbraith > US Voice: 630.492.0464 From owen at delong.com Fri Oct 1 05:33:18 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 03:33:18 -0700 Subject: RIP Justification In-Reply-To: References: <20100930105357.0084eeb7@t61p> <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> <4CA4F9ED.1000007@brightok.net> Message-ID: <8E5F6739-8847-43BA-997B-651DAE5E5EE9@delong.com> On Sep 30, 2010, at 3:47 PM, Heath Jones wrote: > On 30 September 2010 22:11, Jack Carrozzo wrote: >> As it was explained to me, the main difference is that you can have $lots of >> prefixes in IS-IS without it falling over, whereas Dijkstra is far more >> resource-intensive and as such OSPF doesn't get too happy after $a_lot_less >> prefixes. Those numbers can be debated as you like, but I think if you were >> to redist bgp ospf on a lab machine you'd get the point. > > Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because > of the ISO addressing. Atleast thats my take on it.. > > RIPv2 is great for simple route injection. I'm talking really simple, > just to avoid statics. And there, my friend, is the crux of the matter. There's almost no place imagineable where injecting routes from RIPv2 is superior to statics. Owen From owen at delong.com Fri Oct 1 05:36:20 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 03:36:20 -0700 Subject: RIP Justification In-Reply-To: <1285893863.3004.5.camel@Nokia-N900> References: <1285893863.3004.5.camel@Nokia-N900> Message-ID: <403AE8FF-2D1D-4A4B-994F-9EFDDC6770A2@delong.com> Why would you run dynamic to simple CPE at all? Static route that stuff through DHCP or RADIUS and move on. If you need dynamic routing across administrative boundaries, that's not a good place for RIP, that's a good place for BGP. Owen On Sep 30, 2010, at 5:54 PM, Guerra, Ruben wrote: > I am with Scott on this one.. I took the initial question as a focus on the edge... not the CORE. RIP is perfect for the edge to commercial CPEs. Why would want to run OSPF/ISIS at the edge. I would hope that it would be common practice to not use RIP in the CORE.... > > peace > -- > Ruben Guerra > --------- Sent from my Nokia N900 > > ----- Original message ----- >> Haha It's all good :) >> You are right about IS-IS being less resource intensive than OSPF, and >> that it scales better! >> >> >> >> On 30 September 2010 23:50, Jack Carrozzo > wrote: >>> >>>> >>>> Both OSPF and IS-IS use Dijkstra. IS-IS isn't as widely used because >>>> of the ISO addressing. Atleast thats my take on it.. >>> >>> Sorry, my mistake. I'll go sit in my corner now... >>> -Jack >> > From owen at delong.com Fri Oct 1 05:45:10 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 03:45:10 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <7865.1285924930@tristatelogic.com> References: <7865.1285924930@tristatelogic.com> Message-ID: Ronald, It's not so much a matter of whether ARIN cares or whether ARIN wants to do something about your issue. It's more a matter of whether ARIN is empowered to do anything at all about your issue. ARIN is a registry. They don't run routers (outside of a small handfull of them that provide certain ARIN infrastructure). They have no control over BGP, the routing table, or anything that would be able to do anything about your particular brand of issue. What they can do something about is, indeed, things that got into the registry data through fraud, deceit, error, omission, or other unintended mechanism. I'm sorry you're not satisfied with that fact. I'm sorry that you are obviously clearly very upset by this experience. However, I think your issue stems from a fundamental misunderstanding of the role ARIN plays in the community vs. that of the ISPs. It's kind of like asking a DMV representative to arrest an auto thief. ARIN does registrations. They aren't the internet police. Owen On Oct 1, 2010, at 2:22 AM, Ronald F. Guilmette wrote: > > So ARIN put up on their web site this fancy schmancy web form that allows > a person to report fraud relating to ARIN number resources. Here's what > the introduction to that page says, exactly as it appears on ARIN's web > site: > > This reporting process is to be used to notify ARIN of suspected > Internet number resource abuse including the submission of falsified > utilization or organization information, unauthorized changes to data > in ARIN's WHOIS, hijacking of number resources in ARIN's database, or > fraudulent transfers. > > Well, that's what it says anyway. And being naive, I actually believed that > the folks at ARIN might actually give a rat's ass about all these kinds of > fraud that they have enumerated above. Boy was I wrong! > > I just received the response attached below to one of my earlier reports using > that form. And I gotta tell you, its an eye opener. > > Apparently the fine folks at ARIN, clever bureaucrats that they are, have > subtly but substantially redefined the specific kinds of ``fraud'' they > care to hear about and/or investigate, so that contrary to the above, mere > hijacking of ASes or IP blocks isn't actually something that they want > to hear about, much less DO anything about. > > Nope! Apparently, ARIN's fraud reporting form is only to be used for > reporting cases where somebody has fiddled one of ARIN's whois records > in a fradulent way. If somebody just waltzes in and starts announcing a > bunch of routes to a bunch of hijacked IP space from a hijacked ASN > (or two, or three) ARIN doesn't want to hear about it. In those rare > cases where the perp is considerate enough to ALSO fiddle the relevant > WHOIS records in some fradulent way, THEN (apparently) ARIN will get > involved, but only to the extent of re-jiggering the WHOIS record(s). > Once that's been done, they will happily leave the perp to announce > all of the fradulent routes and hijacked space he wants, in perpetuity. > > Apparently, they consider the hijacking itself as being totally out of > their charter to even look at or investigate. ONLY if a WHOIS record > has been fiddled will they give a damn, and then the only one thing they > will give a damn about will be the WHOIS record... and the rest of the > net can go to hell, because hay! Not our problem man! > > Now I _know_ full well that by posting this rant here, the usual assortment > of knuckle-walker throwbacks who still yearn for the wonderful rule-less > frontier every-man-for-himself-and-no-sherrifs fun filled days of the > old 20th Century Internet, will pipe up immediately and say `Good! > Goddammit we don't want no steekin' ARIN to be ``policing'' anything > at all. F**k that! Total anarchy is the best of all possible systems.' > > You know what? I don't care. Let them come. Let them lumber around and > scream and pound their fists and try to tell me that because *I* didn't > get onto the Internet until 1983 (or because their router can beat up > my router) that they somehow magically outrank me, and that their opinions > are God and mine are worthless. That's quite obviously horse shit. How > do you have a pecking order anyway in a self-avowed anarchy? Sorry, no. > The two are not compatible. I've got as much right to an opinion as you > do. And until proved otherwise, mine is as valid as your's. And my > opinion is that this sucks. ARIN's attitude sucks. And they are apparently > redefining the word ``fraud'' in a way that will insure that they will > have to do minimal work, and that they'll never ever have to do anything > that might be ``hard'' in the sense of possibly being the lest bit contro- > versial, you know, like telling some hijacker ``Stop doing that.'' > > Yes, I'm sure that there are a lot of people here who will pipe up and say > that it's just wonderful that ARIN is useless and that ARIN will do nothing. > Their anachronistic anarchist philosophy is not a philosophy. It's merely > an abdication of responsibility, and should be seen as such. It is just > a lazy man's way of avoiding having to think about how a society should > be organized. It is the coward's way of avoiding making rules that some > members of the group might find controversial. > > On the net, hijacking of IP space is just about the deepest kind of > violation of the commonly accepted rules of how to behave in this shared > space that I can imagine. And now, the people who _issue_ the IP space > assignments say that they don't care to _police_ the very assignments > that they themselves have made! Well then what's the bleeping point of > even having them or their whole bloody allocation system then? I say > let's disband the Federal Reserve *and* ARIN, because they are all just > a bunch of useless bureaucrats at this point who are serving nobody other > than themselves. If we are going to have anarchy, then bring it on! > Let's not have this half-assed sort of anarchy that we have now. Let's > have the real thing! I'm going out tomorrow and I'm going to buy me the > biggest router than I can afford. Then I'm going to get it colocated > someplace, and then I'm going to start announcing all the routes I feel > like, and nobody will do shit about it... because its not their job man! > > And some people still wonder why this planet is so f**ked up. Geeezzz. > > > Regards, > rfg > > > P.S. It ain't as if I'm either asking or expecting anybody from ARIN to > take a plane out to that place where the hunters shot down that cable, or > some exchange point in Bumf**k, Idaho, and with guns drawn, physically > pull the wire out of the socket. No. I'm *not* asking for that kind of > ``policing''. But Christ! They could at least take a position, instead > of simply standing around with their hands in their pockets. Is that > really too much to ask? They could say, to everyone involved, and to > the community as a whole, ``This ain't right. *We* maintain the official > allocation records. In most cases, *we* made the allocations, and that > guy should NOT be announcing routes to that IP space, and he shouldn't be > announcing anything at all via that AS number, because these things ain't > his.'' > > That's all. I'd just like to see them maybe take a postion. I'm quite > sure that ARIN corporate counsel has advised them to never take a > position on anything... kind-of like Minister Hacker in "Yes, Minister", > who often hoped that the government could have NO position on anything > the least bit controversial...except with respect to things that might > erode their own power, you know, like the position that IP addresses > are not property, which they try desperately to maintain (against all > obvious facts to the contrary) as a way of keeping courts out of the > business of saying who gets what, so that they can maintain their own > total and absolute sovereignty over this shit, with no annoying judges > to get in their way. But you know, if they won't even take a position > on a bloody blatant hijacking by low life spammer slugs and/or by others > who the spammers have paid Big Bucks to, to steal the space for them, > they really, like I said, what's the point of even having an allocation > ``authority''? (And obviously, I am using that term very very loosely > here, because they clearly only care to use their ``authority'' when it > makes everybody happy, and won't use it at all when it might make even > one lone spammer/hijacker sad. If there is a better definition of > cowardice and abdication, I don't know what it is.) > > > ------- Forwarded Message > > Replied: Fri, 01 Oct 2010 00:49:08 -0700 > Replied: hostmaster at arin.net > Return-Path: hostmaster at arin.net > Delivery-Date: Thu Sep 30 08:30:13 2010 > Return-Path: > X-Original-To: rfg at tristatelogic.com > Delivered-To: rfg at tristatelogic.com > Received: from smtp1.arin.net (smtp1.arin.net [192.149.252.33]) > by segfault.tristatelogic.com (Postfix) with ESMTP id 389DDBDC34 > for ; Thu, 30 Sep 2010 08:30:13 -0700 (PDT) > Received: by smtp1.arin.net (Postfix, from userid 323) > id 89AD4165331; Thu, 30 Sep 2010 11:30:07 -0400 (EDT) > X-Spam-Checker-Version: SpamAssassin 3.2.5-arin1 (2008-06-10) on smtp1.arin.net > X-Spam-Level: > X-Spam-Status: No, score=-144.2 required=5.0 tests=AWL,BAYES_00, > FH_DATE_PAST_20XX,USER_IN_WHITELIST autolearn=no version=3.2.5-arin1 > Received: from pgp.arin.net (pgp.arin.net [192.136.136.159]) > by smtp1.arin.net (Postfix) with ESMTP id 5F592165324 > for ; Thu, 30 Sep 2010 11:30:07 -0400 (EDT) > Received: by pgp.arin.net (Postfix, from userid 688) > id 37E9F1A8069; Thu, 30 Sep 2010 11:30:07 -0400 (EDT) > Received: from shell.arin.net (shell.arin.net [192.136.136.149]) by > pgp.arin.net (Postfix) with ESMTP id AD3C81A8103 for > ; Thu, 30 Sep 2010 11:30:06 -0400 (EDT) > Received: by shell.arin.net (Postfix, from userid 2006) id C6F5D8059; > Thu, 30 Sep 2010 11:30:06 -0400 (EDT) > Received: from localhost (localhost [127.0.0.1]) by shell.arin.net > (Postfix) with ESMTP id C5B0A8058; Thu, 30 Sep 2010 11:30:06 -0400 (EDT) > Date: Thu, 30 Sep 2010 11:30:06 -0400 (EDT) > From: hostmaster at arin.net > X-X-Sender: jonw at shell.arin.net > To: rfg at tristatelogic.com > Subject: Re: [ARIN-20100928-F683] Fraud Report Confirmed > In-Reply-To: > Message-ID: > References: > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > - -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > Thanks for your report. > >> AS11296 appears to have been hijacked. >> >> Separately and additionally, all of the IPv4 blocks currently being >> announced by AS11296 appear to have been hijacked also: >> >> 63.247.160.0/19 >> 199.241.64.0/19 >> 206.226.64.0/24 >> 206.226.65.0/24 >> 206.226.66.0/24 >> 206.226.67.0/24 >> 206.226.68.0/24 >> 206.226.69.0/24 >> 206.226.70.0/24 >> 206.226.71.0/24 >> 206.226.72.0/24 >> 206.226.73.0/24 >> 206.226.74.0/24 >> 206.226.75.0/24 >> 206.226.76.0/24 >> 206.226.77.0/24 >> 206.226.78.0/24 >> 206.226.79.0/24 >> 206.226.96.0/19 > > We've looked through these records and can't find any unauthorized > changes. Do you have any further details regarding unauthorized changes > to ARIN's Whois data? If not, we can't take action. We can investigate > fraudulent changes to registration data, but we can't investigate > fraudulent activity related to use of numbering resources (e.g. routing of > resources by someone other than the registrant). > > If you have any further questions, comments, or concerns please respond to > this message or contact me directly. > > Regards, > > Jon Worley > Senior Resource Analyst > ARIN Registration Services > https://www.arin.net/ > hostmaster at arin.net > 703.227.0660 > > Are you ready for IPv6? For information on transitioning to IPv6, see: > > https://www.arin.net/knowledge/about_resources/v6/v6.html > - -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.6 (GNU/Linux) > > iD8DBQFMpKz/ZKymzxl/LaURAvVuAJsFT6DZxoZ5O13SDRKWK6Lkz1yusgCdFt01 > aMTBE0O/ucnRx+8rk8+QbEE= > =qqf5 > - -----END PGP SIGNATURE----- > > ------- End of Forwarded Message > From hj1980 at gmail.com Fri Oct 1 05:50:58 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 11:50:58 +0100 Subject: AS11296 -- Hijacked? In-Reply-To: <6777.1285912054@tristatelogic.com> References: <6777.1285912054@tristatelogic.com> Message-ID: On 1 October 2010 06:47, Ronald F. Guilmette wrote: >?I hope this may ally some of the concern that has been expressed > about me not being more forthcomeing about the details of this case. Cheers Ron for coming forth with your reasoning, it is appreciated. Your bit of trust in me/us has gone a long way, and its good to understand your motivation and how you came to your conclusions. I'm actually quite surprised that you have found so much spam coming out of the US! I would have thought less developed countries where its easy to obtain unregulated connections, with little legal repercussion would be more popular. Then again, I personally have not done a lot of research in the field. Good luck with your endeavour. Heath From hj1980 at gmail.com Fri Oct 1 06:02:34 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 12:02:34 +0100 Subject: RIP Justification In-Reply-To: <8E5F6739-8847-43BA-997B-651DAE5E5EE9@delong.com> References: <20100930105357.0084eeb7@t61p> <8C26A4FDAE599041A13EB499117D3C28405FE046@ex-mb-2.corp.atlasnetworks.us> <4CA4F9ED.1000007@brightok.net> <8E5F6739-8847-43BA-997B-651DAE5E5EE9@delong.com> Message-ID: >> RIPv2 is great for simple route injection. I'm talking really simple, >> just to avoid statics. > And there, my friend, is the crux of the matter. There's almost no place > imagineable where injecting routes from RIPv2 is superior to statics. Well, let me stimulate your imagination.. IPVPN cloud provided by carrier. Head office is ethernet into cloud. Remote sites are DSL, so terminating on LNS within cloud, and have one or more prefixes behind CPE. Pretty simple stuff. Now, when traffic comes from head office destined for a site prefix, it hits the provider gear. That provider gear will need routing information to head to a particular site. If you wanted to use statics, you will need to fill out a form each time you add/remove a prefix for a site and the provider must manage that. Its called a 'pain in the arse'. Enter RIPv2. From rfg at tristatelogic.com Fri Oct 1 06:10:12 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 01 Oct 2010 04:10:12 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: Message-ID: <9997.1285931412@tristatelogic.com> In message , Owen DeLong wrote: >It's not so much a matter of whether ARIN cares or whether ARIN wants >to do something about your issue. It's more a matter of whether ARIN >is empowered to do anything at all about your issue. That is complete and utter horse shit, and you're just dodging the real issue by trying to change the subject. It isn't going to work. People, even people here, may be stupid, but I think that most can recognize sleight of hand when they see it. >I'm sorry you're not satisfied with that fact. I'm sorry that you are = >obviously >clearly very upset by this experience. However, I think your issue stems >from a fundamental misunderstanding of the role ARIN plays in the >community vs. that of the ISPs. No, it doesn't. I think that *your* issue stems from a fundamental inability to read what I wrote. >It's kind of like asking a DMV representative to arrest an auto thief. No, it's kind of like asking the DMV whether the car belongs to the thief or to someone else. They keep the records for Christ's sake! They *can* take a position on that rudumentary, simple, and basic question, and they should. And that is all I ask or expect them to do. But they don't even want to do that miniscule amount of work, apparently. They want to be the Keeper of the Records, but then they want to roll over and play dead, or ignorant, or agnostic, whenever somebody has the temerrity to simply ask them what the f**king records they are keeping *mean* about who actually owns what. I already said it, but I'll say it again for the benefit of those with low reading comprehension. Nobody is asking ARIN to go out, with guns drawn, and pull the plug themselves. But they can and should take a position on who owns what. That is a judicial function, not a police function. If you don't understand the distinction, then you are dumber than you think I think you are. Regards, rfg From hj1980 at gmail.com Fri Oct 1 06:16:53 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 12:16:53 +0100 Subject: BGP next-hop In-Reply-To: <3E7810CF-BF6F-4D72-8313-88B84E5D19BD@acm.org> References: <20100930140119.GA6643@ussenterprise.ufp.org> <1285862653.30784.23.camel@angel> <3E7810CF-BF6F-4D72-8313-88B84E5D19BD@acm.org> Message-ID: > Section 9.1.2.1 of RFC 4271 seems to address this. > A few points from that section: > ?- The BGP NEXT_HOP can not recursively resolve (directly or indirectly) through the BGP route. > ?- Only the longest matching route should be considered when resolving the BGP NEXT_HOP. > ?- Do not consider feasible routes that would become unresolvable if they were installed. There are 2 ways of reading that.. Perhaps i'll go and look at the it in more details. I'm trying to think of a scenario where following this or something similar would break it: - Don't use BGP prefixes to resolve next-hop. - You can use 0/0 or any route with a lower administrative distance to resolve the next-top. With that in mind, I wonder if it works with Juniper (ad = 170 vs 20 from memory).. From tim at pelican.org Fri Oct 1 06:19:13 2010 From: tim at pelican.org (Tim Franklin) Date: Fri, 1 Oct 2010 11:19:13 +0000 (GMT) Subject: RIP Justification In-Reply-To: <21684634.01285931936789.JavaMail.root@jennyfur.pelican.org> Message-ID: <17485453.21285931953713.JavaMail.root@jennyfur.pelican.org> > Now, when traffic comes from head office destined for a site prefix, > it hits the provider gear. That provider gear will need routing > information to head to a particular site. If you wanted to use > statics, you will need to fill out a form each time you add/remove a > prefix for a site and the provider must manage that. Its called a > 'pain in the arse'. > > Enter RIPv2. Or BGP. Why not? From jared at puck.nether.net Fri Oct 1 06:26:56 2010 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 1 Oct 2010 07:26:56 -0400 Subject: Using crypto auth for detecting corrupted IGP packets? In-Reply-To: <043AE224-2A9C-453B-B6E7-B782AC6B7C28@arbor.net> References: <8943BD09-32CF-4F83-9EBE-1558679E1FEF@puck.nether.net> <14643A97-2A17-4859-93EB-9CC4187FDCBA@arbor.net> <043AE224-2A9C-453B-B6E7-B782AC6B7C28@arbor.net> Message-ID: On Oct 1, 2010, at 3:49 AM, Dobbins, Roland wrote: > > On Oct 1, 2010, at 1:01 PM, Manav Bhatia wrote: > >> In 6 hours you will have around 8000K BFD packets. Add OSPF, >> RSVP, BGP, LACP (for lags), dot1AG, EFM and you would really get a >> significant number of packets to buffer. > > > Which isn't a 'HUGE!' amount of packets. > > ;> Yup, but when trying to figure out the root cause of some problem, having a few gigs of data would be helpful. In the event people have not noticed, hard drives are semi-popular in routers now, so assuming you have some variable amount of disk space greater than 8MB for an image is feasible. - Jared From hj1980 at gmail.com Fri Oct 1 06:28:47 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 12:28:47 +0100 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <9997.1285931412@tristatelogic.com> References: <9997.1285931412@tristatelogic.com> Message-ID: Come one mate, there's no need to be just outright insulting people. Sure everyone disagrees on some things, but still... Lets play out this scenario then. What would you recommend ARIN actually do? I don't mean 'take a stance' or 'have an opinion', but rather what process should in your mind they be following? There are still other avenues. I mentioned in a previous email about IETF or a working group to come up with ideas and methods to combat spam and abuse. If you put as much time into one of them as you do fighting with the spammers directly and ARIN, then you might actually end up solving the problem at the core! I really don't want to drag this anti-spam stuff out. There's been a huge amount of posting these last few days over this (of which I am a culprit also), but I do think its valuable to hit this nail on the head. In other words, perhaps other people on this list are getting a bit fed up with it, so lets just sort it out and quickly.. From hj1980 at gmail.com Fri Oct 1 06:39:07 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 12:39:07 +0100 Subject: RIP Justification In-Reply-To: <17485453.21285931953713.JavaMail.root@jennyfur.pelican.org> References: <21684634.01285931936789.JavaMail.root@jennyfur.pelican.org> <17485453.21285931953713.JavaMail.root@jennyfur.pelican.org> Message-ID: On 1 October 2010 12:19, Tim Franklin wrote: > Or BGP. ?Why not? Of course, technically you could use almost any routing protocol. OSPF and IS-IS would require more configuration and maintenance, BGP even more still. I think this is a pretty good example though of how RIPv2 is probably the most appropriate for the job. It doesnt require further configuration from the provider side as new sites are added and is very simple to set up and maintain. From rsk at gsp.org Fri Oct 1 07:00:50 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Fri, 1 Oct 2010 08:00:50 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> Message-ID: <20101001120050.GA29429@gsp.org> On Thu, Sep 30, 2010 at 11:34:16PM -0700, George Bonser wrote: > "Hijacking" of defunct resources is probably a widespread activity. It is. A number of individuals and entities have been involved in tracking these over the years, and I've seen enough to figure out that it's common because it's relatively easy, it's likely to be undetected, it's likely to be ignored if detected, there are no significant penalties, and even if it all goes south: it's easy to start over and do it again. > How much address space is being wasted in this way? A lot. Moreover, large chunks of address space are being wasted in this way: 1. Spammer sets up dummy front web-hosting/ISP company. 1a. (optional) Spammer sets up second-level dummy front. 2. Spammer gets ARIN et.al. to allocate a /20 or a /17 or whatever. 3. Spammer uses spammer-friendly registrar to purchase throwaway domains in bulk. (Sometimes the registrar IS the spammer. Cost-effective.) 4. Spammer populates the allocation with throwaway domains and commences snowshoe spamming. 4a. (optional) Spamming facilitates drive-by downloads, malware injection, browser exploits, phishing, and other attacks. 5. Anti-spam resources notice this and blacklist the allocation. So do large numbers of individual network/system/mail admins. 6. Return to step 1. It's instructive to consider who profits from each of these steps. A quick check of my (local, incomplete, barely scratch-the-surface) list of such things includes (and I've left out smaller and larger blocks, thus this is a pretty much a snapshot of the middle of the curve): /16's: 25 /17's: 20 /18's: 47 /19's: 73 /20's: 99 /21's: 88 /22's: 105 /23's: 198 /24's: 3245 for a total of about 6.6 million IP addresses. My guess is that this is likely a few percent, at best, of the real total: it just happens to be the set that brought itself to my attention by being sufficiently annoying to local resources. So I wouldn't be at all surprised to find that real total is in the 100M ballpark. So I've concluded that there really isn't an IPv4 address space shortage. Spammers have absolutely no problem getting allocation after allocation after allocation, turning each one into scorched earth and moving on. ARIN et.al. certainly have no interest in stopping them, and ICANN only cares about registrar profits, so there's no help coming from either of those. ---rsk From tonyb at go-concepts.com Fri Oct 1 07:05:27 2010 From: tonyb at go-concepts.com (Tony Bunce) Date: Fri, 1 Oct 2010 12:05:27 +0000 Subject: Frontier DSL Contact In-Reply-To: <38C452D903F47349B03EC558C5863D98691E2D@EXCH2010.gont> References: <38C452D903F47349B03EC558C5863D98691E2D@EXCH2010.gont> Message-ID: <38C452D903F47349B03EC558C5863D98692E9C@EXCH2010.gont> Thanks to everyone that contacted me off-list. I was able to get the issue resolved with Frontier's help. -Tony From jeffrey.lyon at blacklotus.net Fri Oct 1 07:20:29 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Fri, 1 Oct 2010 16:50:29 +0430 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: References: <9997.1285931412@tristatelogic.com> Message-ID: I sent an abuse complaint to Mr. Curran and the abuse helpdesk about a month or two ago. Took weeks to get an initial response from the helpdesk and i'm not certain they have actually done anything yet. Jeff On Fri, Oct 1, 2010 at 3:58 PM, Heath Jones wrote: > Come one mate, there's no need to be just outright insulting people. > Sure everyone disagrees on some things, but still... > > Lets play out this scenario then. What would you recommend ARIN actually do? > I don't mean 'take a stance' or 'have an opinion', but rather what > process should in your mind they be following? > > There are still other avenues. I mentioned in a previous email about > IETF or a working group to come up with ideas and methods to combat > spam and abuse. If you put as much time into one of them as you do > fighting with the spammers directly and ARIN, then you might actually > end up solving the problem at the core! > > I really don't want to drag this anti-spam stuff out. There's been a > huge amount of posting these last few days over this (of which I am a > culprit also), but I do think its valuable to hit this nail on the > head. In other words, perhaps other people on this list are getting a > bit fed up with it, so lets just sort it out and quickly.. > > -- 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 bill at herrin.us Fri Oct 1 07:29:04 2010 From: bill at herrin.us (William Herrin) Date: Fri, 1 Oct 2010 08:29:04 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <6777.1285912054@tristatelogic.com> References: <6777.1285912054@tristatelogic.com> Message-ID: On Fri, Oct 1, 2010 at 1:47 AM, Ronald F. Guilmette wrote: > Oh yea, and the snail mail addresses given in the WHOIS records for the > domains will usually/often be tracable to UPS Store rental P.O. boxes... > those are standard spammer favorites, because...as they well know... us > spamfighters can't find out who really controls any one of those boxes > without a subpoena... unlike USPS boxes, for instance. ?(All this is > quite well known in the dank sleezy spammer undergound already, so I'm > not hardly giving away any secrets here.) ?And in a similar vein, the > contact phone numbers given in the whois records will quite typically > be 1-800 or 1-888 or 1-877 or 1-866 toll-free numbers. ?No, the spammers > are _not_ trying to save you money when you want to call them up to bitch > to them about the fact that they sent you 8,372 spams in a row. ?Nope, > again, they use the toll-free numbers for a very specific purpose, which > is again to make it more difficult for anyone trying to track them down > to find their actual physical location. ?Non-tollfree numbers are typically > associated with a specific geographic vicinity (although even that is > being substantially eroded by number portability). ?But the toll free > numbers are truly and always utterly geographically anonymous. ?So > spammers use them a lot, primarily in domain whois records. > > So here you are. ?You've got this s**t load of highly ``fishy'' name servers, > and they are all planted firmly into IP space that (a) appears to have been > allocated to a reputable name brand company... such as Seiko, in this > case... *and* (b) the block in question, based on the RegDate: and Updated: > fields of the block's ARIN whois record, apparently hasn't been touched for > years... maybe even a decade or more... thus implying that the former owners > of the block either have abandoned it years ago, or else they themselves > went belly up and ceased to exist, probably during the Great Dot Com Crash > of 2000. ?Add it all up and what does it spell? ?No, not heartburn... Hijack. Ron, Let's try that without the diatribe: "I saw spam domains pop up associated with 199.241.95.253. 199.241.64.0/19 appears to be a defunct registration reannounced to the Internet two weeks ago by an AS11296 -- an unregistered AS number. A large quantity of spam domains popped up with the other addresses recently announced by AS11296 as well. Accordingly, I suspect that as we've seen many times before and all clearly understand, AS11296 and the addresses it advertises have been hijacked by a spammer." There. Now, would that have been so hard? Your friend was right. We don't want a "lengthy elaboration." Just a simple, concise explanation of why you believe your claim to be true. As for your secretive and ingenious detection, get over yourself. We've seen this before. More than once. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Fri Oct 1 07:33:56 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 1 Oct 2010 12:33:56 +0000 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <9997.1285931412@tristatelogic.com> References: <9997.1285931412@tristatelogic.com> Message-ID: <20101001123356.GA10880@vacation.karoshi.com.> On Fri, Oct 01, 2010 at 04:10:12AM -0700, Ronald F. Guilmette wrote: > > No, it's kind of like asking the DMV whether the car belongs to the thief > or to someone else. They keep the records for Christ's sake! They *can* > take a position on that rudumentary, simple, and basic question, and they > should. And that is all I ask or expect them to do. But they don't > even want to do that miniscule amount of work, apparently. They want to > be the Keeper of the Records, but then they want to roll over and play > dead, or ignorant, or agnostic, whenever somebody has the temerrity to > simply ask them what the f**king records they are keeping *mean* about > who actually owns what. > > I already said it, but I'll say it again for the benefit of those with > low reading comprehension. Nobody is asking ARIN to go out, with guns > drawn, and pull the plug themselves. But they can and should take a > position on who owns what. That is a judicial function, not a police > function. If you don't understand the distinction, then you are dumber > than you think I think you are. > > > Regards, > rfg R, I have a couple of questions for you... perhaps I am unclear here. are you asserting that [natural/legal] persons OWN address space? Last I checked, ARIN records a binding between a person and a "Right to Use" agreement that is reflected in the ARIN database. e.g. Bills Bait & Sushi has the right to use 168.254.0.0/16 from 01oct1999 - current(*) * registration fees are current. ARIN publishes reports from its database in two basic forms, the WHOIS (et.al.) format and the [ip6/in-addr].arpa DNS format. Are you suggesting that ARIN does _NOT_ publish data or that ARIN doesn't keep the data current, or something else? --bill From cmaurand at xyonet.com Fri Oct 1 07:36:35 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 01 Oct 2010 08:36:35 -0400 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: <4CA5D5D3.2040704@xyonet.com> I'd set up something wireless between them. Just my $0.02. --Curtis On 9/30/2010 4:52 PM, Brandon Galbraith wrote: > Has anyone had any luck lately getting dry pairs from AT&T? I'm in the > Chicago area attempting to get a dry pair between two buildings (100ft > apart) for some equipment, but when speaking to several folks at AT&T the > response I get is "You want AT&T service without the service? That's not > logical!". Had no problems 3-4 years ago getting these sorts of "circuits", > but it appears it's gone the way of the dodo now. Any emails off-list are > appreciated. > From dmiller at tiggee.com Fri Oct 1 07:47:29 2010 From: dmiller at tiggee.com (David Miller) Date: Fri, 01 Oct 2010 08:47:29 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: References: <9997.1285931412@tristatelogic.com> Message-ID: <4CA5D861.2030903@tiggee.com> As to what ARIN can 'do' about addresses that are unused/abandoned and later hijacked... ARIN delegates Reverse DNS for every allocation that they make. Address blocks that are reported, investigated, and determined to be unused/abandoned could be delegated to special ARIN name servers that merely returned the following for any reverse DNS query: z.y.x.w.in-addr.arpa. 172800 IN PTR do.not.accept.anything.from.this.abandoned.address.space This is something that ARIN *could* easily do technically. Admittedly, this would require reporting and investigation that I am uncertain whether or not ARIN is empowered/funded to do. This would also require a process be put in place for removing allocations from the delegation to the unused/abandoned reverse DNS servers... -DM On 10/1/2010 8:20 AM, Jeffrey Lyon wrote: > I sent an abuse complaint to Mr. Curran and the abuse helpdesk about a > month or two ago. Took weeks to get an initial response from the > helpdesk and i'm not certain they have actually done anything yet. > > Jeff > > > On Fri, Oct 1, 2010 at 3:58 PM, Heath Jones wrote: >> Come one mate, there's no need to be just outright insulting people. >> Sure everyone disagrees on some things, but still... >> >> Lets play out this scenario then. What would you recommend ARIN actually do? >> I don't mean 'take a stance' or 'have an opinion', but rather what >> process should in your mind they be following? >> >> There are still other avenues. I mentioned in a previous email about >> IETF or a working group to come up with ideas and methods to combat >> spam and abuse. If you put as much time into one of them as you do >> fighting with the spammers directly and ARIN, then you might actually >> end up solving the problem at the core! >> >> I really don't want to drag this anti-spam stuff out. There's been a >> huge amount of posting these last few days over this (of which I am a >> culprit also), but I do think its valuable to hit this nail on the >> head. In other words, perhaps other people on this list are getting a >> bit fed up with it, so lets just sort it out and quickly.. >> >> > > From bmanning at vacation.karoshi.com Fri Oct 1 08:07:50 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 1 Oct 2010 13:07:50 +0000 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <4CA5D861.2030903@tiggee.com> References: <9997.1285931412@tristatelogic.com> <4CA5D861.2030903@tiggee.com> Message-ID: <20101001130750.GB10880@vacation.karoshi.com.> On Fri, Oct 01, 2010 at 08:47:29AM -0400, David Miller wrote: > > As to what ARIN can 'do' about addresses that are unused/abandoned and > later hijacked... > > ARIN delegates Reverse DNS for every allocation that they make. Address > blocks that are reported, investigated, and determined to be > unused/abandoned could be delegated to special ARIN name servers that > merely returned the following for any reverse DNS query: > > z.y.x.w.in-addr.arpa. 172800 IN PTR > do.not.accept.anything.from.this.abandoned.address.space > > This is something that ARIN *could* easily do technically. Admittedly, > this would require reporting and investigation that I am uncertain > whether or not ARIN is empowered/funded to do. This would also require > a process be put in place for removing allocations from the delegation > to the unused/abandoned reverse DNS servers... > > -DM > Goodness me - I've seen that trick before. Worked for about 15 minutes before I had legal camped out in the office. Pulled it shortly there after. I -think- what you are really after is the (fairly) new rPKI pilot - where there are crypto-keys tied to each delegated prefix. If the keys are valid, then ARIN (or other RIR) has "sanctioned" thier use. No or Bad crypto, then the RIR has some concerns about the resource. the downside to this is that the RIR can effectivey cut off someone who would otherwise be in good standing. Sort of removes a level of independence in network operations. Think of what happens when (due to backhoe-fade, for instance) you -can't- get to the RIR CA to validate your prefix crypto? Do you drop the routes? Or would you prefer a more resilient and robust solution? YMMV here, depending on whom you are willing to trust as both a reputation broker -AND- as the prefix police. The idea is that the crypto is harder to forge. DNS forging is almost as easy as prefix "borrowing". --bill From Rod.Beck at hiberniaatlantic.com Fri Oct 1 08:08:23 2010 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Fri, 1 Oct 2010 14:08:23 +0100 Subject: A New TransAtlantic Cable System References: Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html?x=0&.v=1 Roderick S. Beck Director of European Sales Hibernia Atlantic Budapest, New York, and Paris http://www.hiberniaatlantic.com Landline: 36+1+784+7975 AOL Messenger: GlobalBandwidth rod.beck at hiberniaatlantic.com info at globalwholesalebandwidth.com ``Unthinking respect for authority is the greatest enemy of truth.'' Albert Einstein. From hj1980 at gmail.com Fri Oct 1 09:01:25 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 15:01:25 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> References: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> Message-ID: > http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html?x=0&.v=1 > Roderick S. Beck > Director of European Sales > Hibernia Atlantic Sales spam - but still - very close to minimum possible latency! 3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip = 55.9ms. From Valdis.Kletnieks at vt.edu Fri Oct 1 09:08:50 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 01 Oct 2010 10:08:50 -0400 Subject: A New TransAtlantic Cable System In-Reply-To: Your message of "Fri, 01 Oct 2010 15:01:25 BST." References: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> Message-ID: <82839.1285942130@localhost> On Fri, 01 Oct 2010 15:01:25 BST, Heath Jones said: > > http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html?x=0&.v=1 > Sales spam - but still - very close to minimum possible latency! > 3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip = 55.9ms. My first thought is that they've found a way to cheat on the 1.5. If you can make it work at 1.4, you get down to 52.2ms - but get it *too* low and all your photons leak out the sides. Hmm.. Unless you have a magic core that runs at 1.1 and a *cladding* that's up around 2.0? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dhetzel at gmail.com Fri Oct 1 09:11:56 2010 From: dhetzel at gmail.com (Dorn Hetzel) Date: Fri, 1 Oct 2010 10:11:56 -0400 Subject: A New TransAtlantic Cable System In-Reply-To: References: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> Message-ID: Yeah, I wonder when we're gonna see cable that's pumped down to a vacuum in the center? :) On Fri, Oct 1, 2010 at 10:01 AM, Heath Jones wrote: > > > http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html?x=0&.v=1 > > Roderick S. Beck > > Director of European Sales > > Hibernia Atlantic > > Sales spam - but still - very close to minimum possible latency! > 3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip = 55.9ms. > > From jbates at brightok.net Fri Oct 1 09:16:23 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 01 Oct 2010 09:16:23 -0500 Subject: RIP Justification In-Reply-To: <6A6C628F-0595-45D0-8ED2-63C44D760219@delong.com> References: <4CA49041.1080305@brightok.net> <712B5BDF-D6CC-4FE4-ABAF-C2958DF974DE@delong.com> <4CA49714.40007@brightok.net> <6A6C628F-0595-45D0-8ED2-63C44D760219@delong.com> Message-ID: <4CA5ED37.1000909@brightok.net> On 10/1/2010 4:21 AM, Owen DeLong wrote: > The average home user cannot configure RIP. What is your point? > Last linksys I looked at had a checkbox. All done. > RIP has no loop prevention and is suboptimal depending on the configuration > that things get plugged in. > Damn. You mean the split horizon stuff doesn't prevent loops? Granted, it's not optimal, but it works better than nothing in small homeuser networks as we roll v6 out and will need plug and play routing inside of a house. It's also, as someone else pointed out, nice for l3vpn when customers don't support BGP (ie, the very small ones). Providers hate manually having to jack with routes when customers want to rework stuff in their private networks. > RIP breaks more often than DHCP in my experience. > I'm sure it does, but they are both useful for v6 in consumer grade routers where OSPF/IS-IS/BGP won't be found. These routers sometimes even get used in L3VPN. It's not the providers job to dictate what gear the customer wants to use. I rarely care about the stability of a customer network. I strictly care that my stuff works, it provides services to the customer, and the upkeep is as low as I can make it, especially for MPLS services. Jack From hj1980 at gmail.com Fri Oct 1 09:28:51 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 15:28:51 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: References: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> Message-ID: > Yeah, I wonder when we're gonna see cable that's pumped down to a vacuum in > the center? :) Start pumping.. :) Actually, to my surprise, the refractive index in air is quite close to a vacuum - so I figured we could set up a laser link between NY and London, with 'yo mama' sitting in a boat in the middle of the Atlantic to give it the required bend... ps. that concludes my very poor attempt at humour. From dmiller at tiggee.com Fri Oct 1 09:32:40 2010 From: dmiller at tiggee.com (David Miller) Date: Fri, 01 Oct 2010 10:32:40 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <20101001130750.GB10880@vacation.karoshi.com.> References: <9997.1285931412@tristatelogic.com> <4CA5D861.2030903@tiggee.com> <20101001130750.GB10880@vacation.karoshi.com.> Message-ID: <4CA5F108.70407@tiggee.com> On 10/1/2010 9:07 AM, bmanning at vacation.karoshi.com wrote: > On Fri, Oct 01, 2010 at 08:47:29AM -0400, David Miller wrote: >> As to what ARIN can 'do' about addresses that are unused/abandoned and >> later hijacked... >> >> ARIN delegates Reverse DNS for every allocation that they make. Address >> blocks that are reported, investigated, and determined to be >> unused/abandoned could be delegated to special ARIN name servers that >> merely returned the following for any reverse DNS query: >> >> z.y.x.w.in-addr.arpa. 172800 IN PTR >> do.not.accept.anything.from.this.abandoned.address.space >> >> This is something that ARIN *could* easily do technically. Admittedly, >> this would require reporting and investigation that I am uncertain >> whether or not ARIN is empowered/funded to do. This would also require >> a process be put in place for removing allocations from the delegation >> to the unused/abandoned reverse DNS servers... >> >> -DM >> > Goodness me - I've seen that trick before. Worked for > about 15 minutes before I had legal camped out in the office. > Pulled it shortly there after. > > I -think- what you are really after is the (fairly) new rPKI > pilot - where there are crypto-keys tied to each delegated > prefix. If the keys are valid, then ARIN (or other RIR) has > "sanctioned" thier use. No or Bad crypto, then the RIR has > some concerns about the resource. > > the downside to this is that the RIR can effectivey cut off > someone who would otherwise be in good standing. Sort of > removes a level of independence in network operations. Think > of what happens when (due to backhoe-fade, for instance) you > -can't- get to the RIR CA to validate your prefix crypto? Do > you drop the routes? Or would you prefer a more resilient > and robust solution? YMMV here, depending on whom you are > willing to trust as both a reputation broker -AND- as the prefix > police. > > The idea is that the crypto is harder to forge. DNS forging > is almost as easy as prefix "borrowing". > > > --bill I am not referring to DNS forging or crypto DNS validation or route announcement validation - which are certainly good topics that are worthy of further discussion. I am merely refuting the statement, which I have heard many times in many different forums, that ARIN (or any RIR) makes address allocations and then walks away with no further active involvement in the use of these allocations. This statement is simply not true. These sorts of statements about an RIR having no ability to affect prior allocations are normally formed like: 1) RIRs have no control over the routing table or anything operationally in the path of evil people using IPs. 2) An RIR just makes allocations and then has nothing to do with IPs on a daily basis. 3) An RIR is powerless to affect anything operationally (other than reclaiming allocations) for allocations that have been made in the past. These are all untrue statements. The RIR's reverse DNS servers are queried all day every day for the reverse DNS delegations for every netblock that they allocate. This means that RIRs are, in at least this way, actively operationally involved in the use of the allocations that they make. This also means that an RIR has the technical vector to affect the active present use of the allocations that they have made in the past. From ARIN's Number Resource Policy Manual [ https://www.arin.net/policy/nrpm.html ]: ... 3.6 Annual Whois POC Validation 3.6.1 Method of Annual Verification During ARINs annual Whois POC validation, an e-mail will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy. ... 7. Reverse Mapping 7.1 Maintaining IN-ADDRs All ISPs receiving one or more distinct /16 CIDR blocks of IP addresses from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. For blocks smaller than /16, and for the segment of larger blocks smaller than /16, ARIN can maintain IN-ADDRs. 7.2 Lame Delegations in IN-ADDR.ARPA ARIN will actively identify lame DNS name server(s) for reverse address delegations associated with address blocks allocated, assigned or administered by ARIN. Upon identification of a lame delegation, ARIN shall attempt to contact the POC for that resource and resolve the issue. If, following due diligence, ARIN is unable to resolve the lame delegation, ARIN will update the Whois database records resulting in the removal of lame servers. So... ARIN has some 'investigation' power and responsibility for actively removing lame POC contacts and Reverse DNS delegations. What isn't clear to me from ARIN's policies is what happens when all POC contacts or all Reverse DNS delegations for an allocation have been removed because they are lame... This is not to single ARIN out particularly. All of the above is true for every RIR (ARIN, RIPE, APNIC, AFRINIC, LACNIC), though I haven't dug into any policies except ARIN's. -DM From morrowc.lists at gmail.com Fri Oct 1 09:45:43 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 1 Oct 2010 10:45:43 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <20101001120050.GA29429@gsp.org> References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> Message-ID: On Fri, Oct 1, 2010 at 8:00 AM, Rich Kulawiec wrote: > A quick check of my (local, incomplete, barely scratch-the-surface) list > of such things includes (and I've left out smaller and larger blocks, > thus this is a pretty much a snapshot of the middle of the curve): > > ? ? ? ?/16's: 25 > ? ? ? ?/17's: 20 > ? ? ? ?/18's: 47 > ? ? ? ?/19's: 73 > ? ? ? ?/20's: 99 > ? ? ? ?/21's: 88 > ? ? ? ?/22's: 105 > ? ? ? ?/23's: 198 > ? ? ? ?/24's: 3245 > > for a total of about 6.6 million IP addresses. ?My guess is that this > is likely a few percent, at best, of the real total: it just happens this is still less than a /8, which lasts ~3 months in ARIN region and less if you could across RIR's... From morrowc.lists at gmail.com Fri Oct 1 10:04:17 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 1 Oct 2010 11:04:17 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <20101001130750.GB10880@vacation.karoshi.com.> References: <9997.1285931412@tristatelogic.com> <4CA5D861.2030903@tiggee.com> <20101001130750.GB10880@vacation.karoshi.com.> Message-ID: On Fri, Oct 1, 2010 at 9:07 AM, wrote: \> ? ? ? ?I -think- what you are really after is the (fairly) new rPKI > ? ? ? ?pilot - where there are crypto-keys tied to each delegated > ? ? ? ?prefix. ?If the keys are valid, then ARIN (or other RIR) has > ? ? ? ?"sanctioned" thier use. ?No or Bad crypto, then the RIR has 'or anyone else in the heirarchy of certificates' (nominally: IANA -> ARIN -> LIR (uunet/701) -> bmanning-inc -> bait&sushi (endsite) ) > ? ? ? ?some concerns about the resource. or someone in the chain forgot to re-gen their cert, do the dance with resigning and such. (there are a few failure modes, but in general sure) > > ? ? ? ?the downside to this is that the RIR can effectivey cut off > ? ? ? ?someone who would otherwise be in good standing. ?Sort of this depends entirely on the model that the network operators choose to use when accepting routes. Presuming they can, on-router, decide with policy what to do if a route origin (later hopefully route-path as well as origin) is seen as invalid/non-validated/uncool/etc, there could be many outcomes (local-pref change, community marking, route-reject...) chosen. > ? ? ? ?removes a level of independence in network operations. ?Think > ? ? ? ?of what happens when (due to backhoe-fade, for instance) you > ? ? ? ?-can't- get to the RIR CA to validate your prefix crypto? ?Do > ? ? ? ?you drop the routes? ?Or would you prefer a more resilient > ? ? ? ?and robust solution? ?YMMV here, depending on whom you are > ? ? ? ?willing to trust as both a reputation broker -AND- as the prefix > ? ? ? ?police. hopefully the cache's you run are redundant (or the cache service you pay for is redundant enough), as well the cache view is not necessarily consistent (timing issues with updates and such), so some flexibility is required in the end system policy. (end-system here is the router, hopefully it is similar across an asn) I think so far the models proposed in SIDR-wg include: o more than one cert tree (trust anchor) o the provision of the main cert heirarchy NOT necessarily be the one I outlined above (iana->rir->lir->you) o operators have the ability to influence route marking based on certificate validation outcomes o low on-router crypto work o local and supportable systems to do the crypto heavy lifting, kept in sync with what seems like a reasonably well understood methodology o publication of the certification information for objects (asn's, netblocks, subnets) via existing processes (plus some crypto marking of course) > ? ? ? ?The idea is that the crypto is harder to forge. ?DNS forging > ? ? ? ?is almost as easy as prefix "borrowing". and that the crypto/certificates will help us all better automate validation of the routing information... sort of adding certificate checking to rpsl? or, for whatever process you use to generate prefix-lists today for customers, add some openssl certificate validation as well. The end state I hope is NOT just prefix-lists, but certificate checking essentially in realtime with route acceptance in to Adj-RIB-in... I believe Randy Bush has presented some of this fodder at a previous nanog meeting actually? -chris From jeroen at unfix.org Fri Oct 1 10:12:16 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 01 Oct 2010 17:12:16 +0200 Subject: Verifying route origins and ownership (Was: ARIN Fraud Reporting Form ... Don't waste your time) In-Reply-To: References: <9997.1285931412@tristatelogic.com> <4CA5D861.2030903@tiggee.com> <20101001130750.GB10880@vacation.karoshi.com.> Message-ID: <4CA5FA50.5070501@unfix.org> On 2010-10-01 17:04, Christopher Morrow wrote: [..] > I think so far the models proposed in SIDR-wg include: > o more than one cert tree (trust anchor) Why not in a similar vain as RBLs: white and black lists. One can then subscribe to the white & black lists that one trust and give positive/negative points when an entry appears on one of those lists, based on the points that a prefix/asnpath combo gets it is either accepted, rejected or operator-warned. And the good one of course is that you can setup your own repository and give that out to your own systems or to other people's, then you just score your system above the other lists and presto you can overrule decisions which would be made otherwise. If you have multiple sources you trust, you are effectively just adding redundancy to your system, all problems solved. Works for spam, should also work for this. Greets, Jeroen From morrowc.lists at gmail.com Fri Oct 1 10:15:15 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 1 Oct 2010 11:15:15 -0400 Subject: Verifying route origins and ownership (Was: ARIN Fraud Reporting Form ... Don't waste your time) In-Reply-To: <4CA5FA50.5070501@unfix.org> References: <9997.1285931412@tristatelogic.com> <4CA5D861.2030903@tiggee.com> <20101001130750.GB10880@vacation.karoshi.com.> <4CA5FA50.5070501@unfix.org> Message-ID: On Fri, Oct 1, 2010 at 11:12 AM, Jeroen Massar wrote: > On 2010-10-01 17:04, Christopher Morrow wrote: > [..] >> I think so far the models proposed in SIDR-wg include: >> ? o more than one cert tree (trust anchor) > > Why not in a similar vain as RBLs: white and black lists. > I'm sure someone will think it's a fine plan to set up a TA and sign down ROA's that indicate 'badness' or 'invalid' or something similar. There's nothing stopping that, similarly today you COULD subscribe to a BGP feed of subnets of actually seen routes rewriting the next-hop to dsc0/Null0/honeypot... I don't think this sort of thing is in the SIDR-wg's charter though... much like RBL's are not in DNS-EXT's charter? -chris From carey at ar-ballbat.org Fri Oct 1 10:22:28 2010 From: carey at ar-ballbat.org (Andrew Carey) Date: Fri, 1 Oct 2010 08:22:28 -0700 Subject: AT&T Dry Pairs? In-Reply-To: <14DEDC0A-D15E-49C4-8D96-33CB85761C8A@delong.com> References: <14DEDC0A-D15E-49C4-8D96-33CB85761C8A@delong.com> Message-ID: <28895FE0-6219-4D08-B9AB-7327CA54FE45@ar-ballbat.org> Or a (utility) telemetry circuit. None of these will necessarily get you a dry copper loop, depending on the facilities serving your two locations. Also the circuit length will undoubtedly be longer than 100ft so keep that in mind for whatever you're planning to do with it. You might also try a local CLEC. They can get dry loops from AT&T in different qualities that match your intended use from a simple dry voice grade loop to an unloaded DSL capable loop. Whether the CLEC provide it to you in that form is another matter. Even if they do so, the loops may not be straight copper all the way through. On Oct 1, 2010, at 3:25, Owen DeLong wrote: > Try asking for one of the following: > > 1. Farmer Line > 2. Alarm Circuit > > I think there are a few other ways to ask for a dry pair that might circumvent > the limited know-how of the people you are talking to, but, I don't recall > them off the top of my head. > > Owen > > On Sep 30, 2010, at 1:52 PM, Brandon Galbraith wrote: > >> Has anyone had any luck lately getting dry pairs from AT&T? I'm in the >> Chicago area attempting to get a dry pair between two buildings (100ft >> apart) for some equipment, but when speaking to several folks at AT&T the >> response I get is "You want AT&T service without the service? That's not >> logical!". Had no problems 3-4 years ago getting these sorts of "circuits", >> but it appears it's gone the way of the dodo now. Any emails off-list are >> appreciated. >> >> -- >> Brandon Galbraith >> US Voice: 630.492.0464 > > From dsparro at gmail.com Fri Oct 1 10:42:10 2010 From: dsparro at gmail.com (Dave Sparro) Date: Fri, 01 Oct 2010 11:42:10 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <7865.1285924930@tristatelogic.com> References: <7865.1285924930@tristatelogic.com> Message-ID: <4CA60152.60307@gmail.com> On 10/1/2010 5:22 AM, Ronald F. Guilmette wrote: > > really too much to ask? They could say, to everyone involved, and to > the community as a whole, ``This ain't right. *We* maintain the official > allocation records. In most cases, *we* made the allocations, and that > guy should NOT be announcing routes to that IP space, and he shouldn't be > announcing anything at all via that AS number, because these things ain't > his.'' > So what you're saying is that ARIN should publish data on the rightful users of the number resources in some online database? (maybe they could call it WHOIS) -- Dave From kowsik at gmail.com Fri Oct 1 10:57:43 2010 From: kowsik at gmail.com (kowsik) Date: Fri, 1 Oct 2010 08:57:43 -0700 Subject: Visualizing Application Flows with xtractr Message-ID: One of the challenges of troubleshooting networks with packet captures is that you quickly lose the bigger picture with the volume of data. And static reports just don't do justice to the flurry of activity on networks. We just posted a video on visualizing application flows using xtractr. You can learn more about xtractr here: http://www.pcapr.net/xtractr http://labs.mudynamics.com/2010/09/30/visualizing-application-flows-with-xtractr K. --- http://www.pcapr.net http://twitter.com/pcapr http://labs.mudynamics.com From Ruben.Guerra at arrisi.com Fri Oct 1 11:06:00 2010 From: Ruben.Guerra at arrisi.com (Guerra, Ruben) Date: Fri, 1 Oct 2010 11:06:00 -0500 Subject: RIP Justification In-Reply-To: <17485453.21285931953713.JavaMail.root@jennyfur.pelican.org> References: <21684634.01285931936789.JavaMail.root@jennyfur.pelican.org> <17485453.21285931953713.JavaMail.root@jennyfur.pelican.org> Message-ID: <8BC9AA1D1BA4494F83F8205415225CE826140815E4@CHIEXMAIL1.ARRS.ARRISI.COM> Tim hit the nail on the head. Maintaining statics on a large network would become a huge problem. Human error will eventually occur. The network scenario I am speaking of is DSL/Cable type setups, where a customer could move from router to router(DSLAM/CMTS) due to capacity re-combines. Utilizing a dynamic routing protocol makes these types of changes easier to digest. Using BGP would be overkill for most. Many small commercial customers to not want the complexity of BGP or want to spend money on extra resources (routers that actually support it) Sure for someone that needs to announce their own space or wants multi-homed connection def use BGP. -Ruben -----Original Message----- From: Tim Franklin [mailto:tim at pelican.org] Sent: Friday, October 01, 2010 6:19 AM To: nanog at nanog.org Subject: Re: RIP Justification > Now, when traffic comes from head office destined for a site prefix, > it hits the provider gear. That provider gear will need routing > information to head to a particular site. If you wanted to use > statics, you will need to fill out a form each time you add/remove a > prefix for a site and the provider must manage that. Its called a > 'pain in the arse'. > > Enter RIPv2. Or BGP. Why not? From gbonser at seven.com Fri Oct 1 11:15:00 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 09:15:00 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <4CA60152.60307@gmail.com> References: <7865.1285924930@tristatelogic.com> <4CA60152.60307@gmail.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B07A@RWC-EX1.corp.seven.com> > > So what you're saying is that ARIN should publish data on the rightful > users of the number resources in some online database? > > (maybe they could call it WHOIS) > > -- > Dave So ARIN is in the process of verifying their contacts database. Organizations with an unreachable contact might be a good place to plant a "dig here" sign. Maybe when one of us retires, we could engage in a little research project as a community service or something. A first step might be matching ASN resources to unreachable contacts. Then to collect the low hanging fruit, find the ASNs found above that are NOT in the routing table and attempt to match those up with organizations and see if those organizations even still exist. For the ones that obviously no longer exist, create a report of the ASNs and any other number resources associated with that organization and provide that information to the registrar. Then you go through the ones that ARE in the routing table. Any of those organizations that are obviously defunct would be the next higher level of fruit. This would be particularly true if a historical look at routing information shows the AS was in the table at some point, disappeared after the organization went defunct, and then suddenly appeared again in a completely different region of the planet with name resources pointing to a completely different organization than the number resources. Then if a suspicious operator is discovered, it must be reported to their upstream, the registrar with involved with the number resources, and the community. See how this goes? It takes someone working on this that has access to a lot of information and has the time to do it. It also has to be someone that isn't a "loose cannon" and can dig through it in a methodical fashion and whether or not "spam" has come from the address space really has no bearing on the process. At least it has no bearing on the process up to that point. All that is being done is to "weed" the database of defunct resources. So while the DMV doesn't go after car theft, this is more along the lines of stealing a neighbor's license plate from that old car in the back field, making a sticker to put on it, and driving around as if it is a legitimate plate. The DMV records would show who that license plate belongs to and a police officer in a traffic stop would find out in short order that the plate is defunct but the database available to internet operators is so poor that there really is no way to be sure if the data being returned is actionable or not. G From tim at pelican.org Fri Oct 1 11:28:30 2010 From: tim at pelican.org (Tim Franklin) Date: Fri, 1 Oct 2010 16:28:30 +0000 (GMT) Subject: RIP Justification In-Reply-To: <28460806.51285950096710.JavaMail.root@jennyfur.pelican.org> Message-ID: <7662474.71285950510272.JavaMail.root@jennyfur.pelican.org> ----- "Ruben Guerra" wrote: > Using BGP would be overkill for most. Many small commercial customers > to not want the complexity of BGP This one keeps coming up. Leaf-node BGP config is utterly trivial, and is much easier for the SP to configure the necessary safety devices on their side to stop you from shooting yourself in the foot and blowing up your networks - or worse, *their* network. Plus, if / when in the future you need to do something clever, you've already got the routing protocol with all the advanced knobs in place, ready for you to tweak as needed. The Enterprise guys really need to get out of the blanket "BGP is scary" mindset - running BGP for an SP with multitudes of customers, peers, transits, aggregation, filters etc and getting it right needs expertise and experience. Announcing a /24 LAN and receiving a default on a single link, not so much. > or want to spend money on extra > resources (routers that actually support it) This has a bit more weight to it, if you're at the really low end (certainly the consumer end). But a BGP-capable Cisco 800-series is, what, ?300? Regards, Tim. From scott at sberkman.net Fri Oct 1 12:58:30 2010 From: scott at sberkman.net (Scott Berkman) Date: Fri, 1 Oct 2010 13:58:30 -0400 Subject: AT&T Dry Pairs? In-Reply-To: References: Message-ID: <014501cb6192$422631f0$c67295d0$@sberkman.net> We order these all of the time ( as a CLEC) for EoC connections or DSL on our equipment. The correct terminology is usually 2-wire or 4-wire copper loops. There will be specific NC/NCI codes depending on the iLEC region you are in and LEC you are working with. Within these loops, you will generally see at least the following "types" of circuits, normally these are really just different levels of qualifications the LEC is required to meet on the copper they provide (in terms of noise, attenuation, load coils, and # feet of bridge tap): HDSL (best) ADSL UCL (Unbundled copper loop - worst) Now the main issue is that these circuits are normally provisioned between a CO and an end-user location. I don't know if you'd be able to get them directly between two sites that are not ATT facilities without going back to the CO first (greatly increasing total loop length and probably decreasing max DSL speeds). The other thing to know is that in "busy" CO's, some of these line types (especially the higher quality loops) may be "blacklisted" meaning you either can't order them at all, or you can order them a different way at a much higher rate. The last issue I can think of is that you may not be able to get these at all from ATT's retail or business side of the house. If that is the case, find a local CLEC and see if they will help you out. -Scott -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Thursday, September 30, 2010 4:53 PM To: nanog at nanog.org Subject: AT&T Dry Pairs? Has anyone had any luck lately getting dry pairs from AT&T? I'm in the Chicago area attempting to get a dry pair between two buildings (100ft apart) for some equipment, but when speaking to several folks at AT&T the response I get is "You want AT&T service without the service? That's not logical!". Had no problems 3-4 years ago getting these sorts of "circuits", but it appears it's gone the way of the dodo now. Any emails off-list are appreciated. -- Brandon Galbraith US Voice: 630.492.0464 From brandon.galbraith at gmail.com Fri Oct 1 13:00:32 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Fri, 1 Oct 2010 13:00:32 -0500 Subject: Followup and Thanks: AT&T Dry Pairs? Message-ID: I just wanted to follow up and say Thank You to everyone who responded to my email regarding getting an "alarm line" from AT&T. I've made some headway once I reached someone with clue, and everyone was extremely helpful with the information they provided. -- Brandon Galbraith US Voice: 630.492.0464 From rfg at tristatelogic.com Fri Oct 1 13:07:58 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 01 Oct 2010 11:07:58 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <20101001123356.GA10880@vacation.karoshi.com.> Message-ID: <12749.1285956478@tristatelogic.com> In message <20101001123356.GA10880 at vacation.karoshi.com.>, bmanning at vacation.karoshi.com wrote: >On Fri, Oct 01, 2010 at 04:10:12AM -0700, Ronald F. Guilmette wrote: >> >> No, it's kind of like asking the DMV whether the car belongs to the thief >> or to someone else. They keep the records for Christ's sake! They *can* >> take a position on that rudumentary, simple, and basic question, and they >> should. And that is all I ask or expect them to do. But they don't >> even want to do that miniscule amount of work, apparently. They want to >> be the Keeper of the Records, but then they want to roll over and play >> dead, or ignorant, or agnostic, whenever somebody has the temerrity to >> simply ask them what the f**king records they are keeping *mean* about >> who actually owns what. >> >> I already said it, but I'll say it again for the benefit of those with >> low reading comprehension. Nobody is asking ARIN to go out, with guns >> drawn, and pull the plug themselves. But they can and should take a >> position on who owns what. That is a judicial function, not a police >> function. If you don't understand the distinction, then you are dumber >> than you think I think you are. >... > > Are you suggesting that ARIN does _NOT_ publish data or that > ARIN doesn't keep the data current, or something else? I already said what I meant, twice, and quite clearly, I think. If you don't get it after two repetitions, then I doubt that me trying to rephrase it yet a third time is going to help your comprehension any. Regards, rfg From hj1980 at gmail.com Fri Oct 1 13:10:18 2010 From: hj1980 at gmail.com (Heath Jones) Date: Fri, 1 Oct 2010 19:10:18 +0100 Subject: RIP Justification In-Reply-To: <8BC9AA1D1BA4494F83F8205415225CE826140815E4@CHIEXMAIL1.ARRS.ARRISI.COM> References: <21684634.01285931936789.JavaMail.root@jennyfur.pelican.org> <17485453.21285931953713.JavaMail.root@jennyfur.pelican.org> <8BC9AA1D1BA4494F83F8205415225CE826140815E4@CHIEXMAIL1.ARRS.ARRISI.COM> Message-ID: > Tim hit the nail on the head. Maintaining statics on a large network would become a huge problem. Human error will eventually occur. The network scenario I am speaking of is DSL/Cable type setups, where a customer could move from router to router(DSLAM/CMTS) due to capacity re-combines. Utilizing a dynamic routing protocol makes these types of changes easier to digest. Just to be perfectly clear with the scenario I was referring to (L3VPN with all remote sites hitting provider router) that Tim was responding to.. The kit is all managed - customer has no access to it. I should have mentioned that before, as it's a pretty key point to the example, perhaps it was thought the customer could touch it? What is needed is simply one step above statics so the provider does not have to maintain them. Loops or hop count are a non-issue, and the customer sites have no redundancy. It's not even a requirement to have fast convergence. All that is required is to have the CPE say 'here is 10.0.0/24', or at a later date, '10.0.1/24' without any work on any other equipment. Nice and easy. RIPv2. Arguing that BGP should be used over RIPv2 in this scenario becomes interesting, as BGP would offer no real advantages and requires further configuration in most cases for each site deployed. It also introduces more overhead for the carrier, the same with OSPF and IS-IS. In other scenarios - of course choose a different protocol - but for this one, I think its a good example for the OP as to why RIPv2 is still used. From bill at herrin.us Fri Oct 1 13:17:32 2010 From: bill at herrin.us (William Herrin) Date: Fri, 1 Oct 2010 14:17:32 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <4CA5F108.70407@tiggee.com> References: <9997.1285931412@tristatelogic.com> <4CA5D861.2030903@tiggee.com> <20101001130750.GB10880@vacation.karoshi.com.> <4CA5F108.70407@tiggee.com> Message-ID: On Fri, Oct 1, 2010 at 10:32 AM, David Miller wrote: > I am merely refuting the statement, which I have heard many times in many > different forums, that ARIN (or any RIR) makes address allocations and then > walks away with no further active involvement in the use of these > allocations. ?This statement is simply not true. David, What *is* true is that ARIN's further involvement in the use of those allocations is regulated by the policies that you and I wrote and instructed ARIN to follow. Those policies include no actions to be taken when a hijacker announces routes contrary to ARIN's registry information. So long as ARIN's information has not been falsified, forcing or not forcing folks to obey it is left for the ISPs to resolve for themselves. Do you think ARIN should should act as a clearinghouse for action with respect to hijacked BGP announcements? Draft a policy proposal and post it on the PPML. If your colleagues agree with you, that will become one of ARIN's roles. Until then, you criticize ARIN unfairly for doing what you and I have told it to do. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bmanning at vacation.karoshi.com Fri Oct 1 13:20:11 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 1 Oct 2010 18:20:11 +0000 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <12749.1285956478@tristatelogic.com> References: <20101001123356.GA10880@vacation.karoshi.com.> <12749.1285956478@tristatelogic.com> Message-ID: <20101001182011.GB12893@vacation.karoshi.com.> On Fri, Oct 01, 2010 at 11:07:58AM -0700, Ronald F. Guilmette wrote: > > In message <20101001123356.GA10880 at vacation.karoshi.com.>, > bmanning at vacation.karoshi.com wrote: > > >On Fri, Oct 01, 2010 at 04:10:12AM -0700, Ronald F. Guilmette wrote: > >> > >> No, it's kind of like asking the DMV whether the car belongs to the thief > >> or to someone else. They keep the records for Christ's sake! They *can* > >> take a position on that rudumentary, simple, and basic question, and they > >> should. And that is all I ask or expect them to do. But they don't > >> even want to do that miniscule amount of work, apparently. They want to > >> be the Keeper of the Records, but then they want to roll over and play > >> dead, or ignorant, or agnostic, whenever somebody has the temerrity to > >> simply ask them what the f**king records they are keeping *mean* about > >> who actually owns what. > >> > >> I already said it, but I'll say it again for the benefit of those with > >> low reading comprehension. Nobody is asking ARIN to go out, with guns > >> drawn, and pull the plug themselves. But they can and should take a > >> position on who owns what. That is a judicial function, not a police > >> function. If you don't understand the distinction, then you are dumber > >> than you think I think you are. > > >... > > > > Are you suggesting that ARIN does _NOT_ publish data or that > > ARIN doesn't keep the data current, or something else? > > I already said what I meant, twice, and quite clearly, I think. > > If you don't get it after two repetitions, then I doubt that me trying > to rephrase it yet a third time is going to help your comprehension any. > > > Regards, > rfg Ok... thanks for the favor of your reply. --bill From jcurran at arin.net Fri Oct 1 13:21:48 2010 From: jcurran at arin.net (John Curran) Date: Fri, 1 Oct 2010 14:21:48 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <7865.1285924930@tristatelogic.com> References: <7865.1285924930@tristatelogic.com> Message-ID: <608B18DB-6E75-4B5E-BA42-D1F69ECE4881@arin.net> On Oct 1, 2010, at 5:22 AM, Ronald F. Guilmette wrote: > > Nope! Apparently, ARIN's fraud reporting form is only to be used for > reporting cases where somebody has fiddled one of ARIN's whois records > in a fradulent way. If somebody just waltzes in and starts announcing a > bunch of routes to a bunch of hijacked IP space from a hijacked ASN > (or two, or three) ARIN doesn't want to hear about it. Ron - You note the following: > They could say, to everyone involved, and to the community as a whole, > ``This ain't right. *We* maintain the official allocation records. > In most cases, *we* made the allocations, and that guy should NOT be > announcing routes to that IP space, and he shouldn't be announcing > anything at all via that AS number, because these things ain't his.'' At present, ARIN doesn't review the routing of address space to see if an allocation made to party is being announced by another party. >From your emails, I'm guess that you'd like ARIN to do so. I've run several several ISPs and a hosting firm, and I'm not quite sure how ARIN can definitively know that any of the AS#'s involved should or should not be routing a given network block. There are some heuristics that will suggest something is "fishy" about use of a network block, but are you actually suggesting that ARIN would revoke resources as a result of that? > In those rare > cases where the perp is considerate enough to ALSO fiddle the relevant > WHOIS records in some fradulent way, THEN (apparently) ARIN will get > involved, but only to the extent of re-jiggering the WHOIS record(s). > Once that's been done, they will happily leave the perp to announce > all of the fradulent routes and hijacked space he wants, in perpetuity. Correct. We will revoke the address space, but I'm uncertain what else you suggest we do... could you elaborate here? /John John Curran President and CEO ARIN From streiner at cluebyfour.org Fri Oct 1 13:33:55 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Fri, 1 Oct 2010 14:33:55 -0400 (EDT) Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <12749.1285956478@tristatelogic.com> References: <12749.1285956478@tristatelogic.com> Message-ID: On Fri, 1 Oct 2010, Ronald F. Guilmette wrote: >> Are you suggesting that ARIN does _NOT_ publish data or that >> ARIN doesn't keep the data current, or something else? > > I already said what I meant, twice, and quite clearly, I think. > > If you don't get it after two repetitions, then I doubt that me trying > to rephrase it yet a third time is going to help your comprehension any. Ok, it's clear that you're pretty upset about your recent dealings with ARIN. I think you've made that abundantly clear. Having said that, responding to people with snarky insults is not going to advance your position or motivate people to try to help you. This is my first and only contribution to this thread. jms From cscora at apnic.net Fri Oct 1 13:58:43 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 2 Oct 2010 04:58:43 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201010011858.o91IwhPe030180@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 02 Oct, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 332569 Prefixes after maximum aggregation: 152883 Deaggregation factor: 2.18 Unique aggregates announced to Internet: 163430 Total ASes present in the Internet Routing Table: 34884 Prefixes per ASN: 9.53 Origin-only ASes present in the Internet Routing Table: 30253 Origin ASes announcing only one prefix: 14676 Transit ASes present in the Internet Routing Table: 4631 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 3584 Unregistered ASNs in the Routing Table: 1563 Number of 32-bit ASNs allocated by the RIRs: 804 Prefixes from 32-bit ASNs in the Routing Table: 1114 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 226 Number of addresses announced to Internet: 2276381248 Equivalent to 135 /8s, 174 /16s and 210 /24s Percentage of available address space announced: 61.4 Percentage of allocated address space announced: 65.6 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 85.0 Total number of prefixes smaller than registry allocations: 157088 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 81203 Total APNIC prefixes after maximum aggregation: 27834 APNIC Deaggregation factor: 2.92 Prefixes being announced from the APNIC address blocks: 78077 Unique aggregates announced from the APNIC address blocks: 34231 APNIC Region origin ASes present in the Internet Routing Table: 4198 APNIC Prefixes per ASN: 18.60 APNIC Region origin ASes announcing only one prefix: 1168 APNIC Region transit ASes present in the Internet Routing Table: 650 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 15 Number of APNIC addresses announced to Internet: 551534112 Equivalent to 32 /8s, 223 /16s and 190 /24s Percentage of available APNIC address space announced: 78.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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: 136044 Total ARIN prefixes after maximum aggregation: 70193 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108795 Unique aggregates announced from the ARIN address blocks: 43480 ARIN Region origin ASes present in the Internet Routing Table: 13926 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix: 5321 ARIN Region transit ASes present in the Internet Routing Table: 1374 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 735644704 Equivalent to 43 /8s, 217 /16s and 12 /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, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 76257 Total RIPE prefixes after maximum aggregation: 44237 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 69692 Unique aggregates announced from the RIPE address blocks: 45701 RIPE Region origin ASes present in the Internet Routing Table: 14833 RIPE Prefixes per ASN: 4.70 RIPE Region origin ASes announcing only one prefix: 7643 RIPE Region transit ASes present in the Internet Routing Table: 2238 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 440007168 Equivalent to 26 /8s, 57 /16s and 250 /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, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 30341 Total LACNIC prefixes after maximum aggregation: 7326 LACNIC Deaggregation factor: 4.14 Prefixes being announced from the LACNIC address blocks: 28839 Unique aggregates announced from the LACNIC address blocks: 15055 LACNIC Region origin ASes present in the Internet Routing Table: 1353 LACNIC Prefixes per ASN: 21.31 LACNIC Region origin ASes announcing only one prefix: 419 LACNIC Region transit ASes present in the Internet Routing Table: 233 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 19 Number of LACNIC addresses announced to Internet: 75693952 Equivalent to 4 /8s, 130 /16s and 255 /24s Percentage of available LACNIC address space announced: 56.4 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7356 Total AfriNIC prefixes after maximum aggregation: 1891 AfriNIC Deaggregation factor: 3.89 Prefixes being announced from the AfriNIC address blocks: 5662 Unique aggregates announced from the AfriNIC address blocks: 1688 AfriNIC Region origin ASes present in the Internet Routing Table: 407 AfriNIC Prefixes per ASN: 13.91 AfriNIC Region origin ASes announcing only one prefix: 125 AfriNIC Region transit ASes present in the Internet Routing Table: 91 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 17 Number of AfriNIC addresses announced to Internet: 20910336 Equivalent to 1 /8s, 63 /16s and 17 /24s Percentage of available AfriNIC address space announced: 62.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1861 9436 505 Korea Telecom (KIX) 7545 1409 297 82 TPG Internet Pty Ltd 4755 1357 368 163 TATA Communications formerly 17488 1347 155 124 Hathway IP Over Cable Interne 17974 1251 301 85 PT TELEKOMUNIKASI INDONESIA 24560 1040 303 179 Bharti Airtel Ltd., Telemedia 9583 1029 77 495 Sify Limited 4808 936 1714 261 CNCGROUP IP network: China169 18101 882 100 132 Reliance Infocom Ltd Internet 9829 820 692 33 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3775 3666 277 bellsouth.net, inc. 4323 2712 1106 389 Time Warner Telecom 19262 1821 4708 285 Verizon Global Networks 1785 1796 698 131 PaeTec Communications, Inc. 20115 1491 1530 650 Charter Communications 7018 1490 5731 956 AT&T WorldNet Services 6478 1354 275 136 AT&T Worldnet Services 2386 1297 555 915 AT&T Data Communications Serv 11492 1218 229 78 Cable One 22773 1200 2858 61 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 448 2026 389 TDC Tele Danmark 8866 417 117 21 Bulgarian Telecommunication C 702 405 1869 319 UUNET - Commercial IP service 8551 402 353 46 Bezeq International 34984 379 90 185 BILISIM TELEKOM 3301 377 1688 333 TeliaNet Sweden 30890 374 79 203 Evolva Telecom 3320 371 7328 322 Deutsche Telekom AG 12479 368 576 5 Uni2 Autonomous System 31148 352 18 77 FreeNet ISP Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1339 2559 367 UniNet S.A. de C.V. 10620 1324 248 149 TVCABLE BOGOTA 28573 1168 893 92 NET Servicos de Comunicao S.A 7303 810 424 102 Telecom Argentina Stet-France 6503 755 223 258 AVANTEL, S.A. 14420 563 39 81 CORPORACION NACIONAL DE TELEC 22047 561 310 15 VTR PUNTO NET S.A. 3816 483 210 94 Empresa Nacional de Telecomun 7738 477 922 30 Telecomunicacoes da Bahia S.A 11172 445 99 76 Servicios Alestra S.A de C.V Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1008 445 10 TEDATA 24863 737 147 39 LINKdotNET AS number 36992 652 279 181 Etisalat MISR 3741 266 906 224 The Internet Solution 6713 203 199 12 Itissalat Al-MAGHRIB 29571 203 19 11 Ci Telecom Autonomous system 2018 197 277 64 Tertiary Education Network 33776 196 12 14 Starcomms Nigeria Limited 24835 163 78 9 RAYA Telecom - Egypt 16637 154 440 92 MTN Network Solutions Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3775 3666 277 bellsouth.net, inc. 4323 2712 1106 389 Time Warner Telecom 4766 1861 9436 505 Korea Telecom (KIX) 19262 1821 4708 285 Verizon Global Networks 1785 1796 698 131 PaeTec Communications, Inc. 20115 1491 1530 650 Charter Communications 7018 1490 5731 956 AT&T WorldNet Services 7545 1409 297 82 TPG Internet Pty Ltd 4755 1357 368 163 TATA Communications formerly 6478 1354 275 136 AT&T Worldnet Services Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2712 2323 Time Warner Telecom 1785 1796 1665 PaeTec Communications, Inc. 19262 1821 1536 Verizon Global Networks 4766 1861 1356 Korea Telecom (KIX) 7545 1409 1327 TPG Internet Pty Ltd 17488 1347 1223 Hathway IP Over Cable Interne 6478 1354 1218 AT&T Worldnet Services 4755 1357 1194 TATA Communications formerly 10620 1324 1175 TVCABLE BOGOTA 17974 1251 1166 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 40331 UNALLOCATED 8.11.167.0/24 7018 AT&T WorldNet Servic 11946 UNALLOCATED 8.12.155.0/24 40913 Quality Technology S 15040 UNALLOCATED 8.12.156.0/24 3356 Level 3 Communicatio 33084 UNALLOCATED 8.15.195.0/24 3356 Level 3 Communicatio 18826 UNALLOCATED 8.17.208.0/20 2828 XO Communications 16734 UNALLOCATED 8.18.204.0/24 26914 Global Netoptex, Inc 53562 UNALLOCATED 8.19.94.0/24 3356 Level 3 Communicatio 23200 UNALLOCATED 8.20.243.0/24 25653 Pegasus Web Technolo 22015 UNALLOCATED 8.22.137.0/24 14989 Broadview Networks 46856 UNALLOCATED 8.22.184.0/22 3356 Level 3 Communicatio Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 41.223.199.0/24 36990 Alkan Telecom Ltd 46.16.64.0/22 28703 Joint Stock Company "UralInte Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:25 /11:67 /12:203 /13:422 /14:732 /15:1325 /16:11292 /17:5465 /18:9287 /19:18481 /20:23594 /21:23820 /22:31164 /23:30460 /24:173233 /25:1021 /26:1138 /27:584 /28:170 /29:47 /30:3 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2403 3775 bellsouth.net, inc. 4766 1478 1861 Korea Telecom (KIX) 4323 1369 2712 Time Warner Telecom 1785 1259 1796 PaeTec Communications, Inc. 10620 1212 1324 TVCABLE BOGOTA 11492 1105 1218 Cable One 17488 1087 1347 Hathway IP Over Cable Interne 18566 1068 1087 Covad Communications 24560 941 1040 Bharti Airtel Ltd., Telemedia 8452 922 1008 TEDATA Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:74 2:15 4:13 8:309 12:2014 13:8 14:13 15:20 16:3 17:9 20:8 24:1376 27:354 31:1 32:61 33:12 38:700 40:97 41:2467 44:3 46:140 47:10 49:4 52:12 55:5 56:2 57:29 58:827 59:505 60:478 61:1087 62:1045 63:1970 64:3727 65:2290 66:4043 67:1843 68:1138 69:2832 70:741 71:375 72:1944 73:2 74:2312 75:289 76:322 77:870 78:677 79:421 80:1016 81:800 82:505 83:454 84:680 85:1038 86:432 87:681 88:325 89:1557 90:104 91:3072 92:430 93:1004 94:1092 95:728 96:398 97:219 98:633 99:32 101:3 108:64 109:709 110:432 111:596 112:295 113:288 114:476 115:600 116:1105 117:659 118:531 119:971 120:178 121:716 122:1549 123:916 124:1228 125:1273 128:228 129:157 130:172 131:558 132:257 133:20 134:207 135:46 136:224 137:140 138:275 139:109 140:480 141:196 142:348 143:352 144:482 145:54 146:429 147:169 148:628 149:304 150:152 151:233 152:291 153:171 154:3 155:367 156:169 157:335 158:112 159:357 160:315 161:190 162:267 163:165 164:417 165:366 166:467 167:409 168:677 169:156 170:719 171:62 172:2 173:1086 174:558 175:176 176:1 177:1 178:518 180:677 181:1 182:228 183:258 184:156 186:685 187:501 188:825 189:805 190:4134 192:5776 193:4738 194:3432 195:2828 196:1202 198:3557 199:3591 200:5411 201:1581 202:8079 203:8302 204:4016 205:2396 206:2529 207:3040 208:3888 209:3496 210:2559 211:1283 212:1777 213:1701 214:665 215:66 216:4742 217:1569 218:491 219:401 220:1170 221:427 222:341 223:46 End of report From jcurran at arin.net Fri Oct 1 14:21:23 2010 From: jcurran at arin.net (John Curran) Date: Fri, 1 Oct 2010 15:21:23 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <20101001120050.GA29429@gsp.org> References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> Message-ID: <548966B9-A42F-429A-A125-06A80A008A26@arin.net> On Oct 1, 2010, at 8:00 AM, Rich Kulawiec wrote: > > Spammers have absolutely no problem getting allocation after allocation > after allocation, turning each one into scorched earth and moving on. Materially correct, despite the fact that we look into the company registrations, principal parties involved, and mailing addresses at the time of a new request. It is simply too easy to create a complete illusion of a valid organization. > ARIN et.al. certainly have no interest in stopping them, Hmm... An interesting assumption, and one that is quite incorrect. Rich - How do suggest dealing with this problem? If you can suggest a straightforward way of vetting a new organization which the community will support, I'll happily have it implemented asap. /John John Curran President and CEO ARIN From jfbeam at gmail.com Fri Oct 1 14:59:51 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Fri, 01 Oct 2010 15:59:51 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: References: <7865.1285924930@tristatelogic.com> Message-ID: On Fri, 01 Oct 2010 06:45:10 -0400, Owen DeLong wrote: > It's not so much a matter of whether ARIN cares or whether ARIN wants > to do something about your issue. It's more a matter of whether ARIN > is empowered to do anything at all about your issue. EXACTLY. Ron, what exactly do you expect ARIN to do? Where is the magic wand one would wave to erase routes from the internet? ARIN (in fact NO ONE) has no actual means to block or recend any route announcement. Do you suggest they sue whomever is involved? That won't be very fast, or even an option outside the US. The only reason this sort of shit happens is because of bad network operators who allow it and participate in it. Responsible operators ask for and verify one's rights to address space before accepting it. (AS path and prefix filtering can only go so far.) --Ricky From dmiller at tiggee.com Fri Oct 1 15:32:34 2010 From: dmiller at tiggee.com (David Miller) Date: Fri, 01 Oct 2010 16:32:34 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: References: <9997.1285931412@tristatelogic.com> <4CA5D861.2030903@tiggee.com> <20101001130750.GB10880@vacation.karoshi.com.> <4CA5F108.70407@tiggee.com> Message-ID: <4CA64562.8020404@tiggee.com> On 10/1/2010 2:17 PM, William Herrin wrote: > On Fri, Oct 1, 2010 at 10:32 AM, David Miller wrote: >> I am merely refuting the statement, which I have heard many times in many >> different forums, that ARIN (or any RIR) makes address allocations and then >> walks away with no further active involvement in the use of these >> allocations. This statement is simply not true. > David, > > What *is* true is that ARIN's further involvement in the use of those > allocations is regulated by the policies that you and I wrote and > instructed ARIN to follow. Those policies include no actions to be > taken when a hijacker announces routes contrary to ARIN's registry > information. So long as ARIN's information has not been falsified, > forcing or not forcing folks to obey it is left for the ISPs to > resolve for themselves. > > Do you think ARIN should should act as a clearinghouse for action with > respect to hijacked BGP announcements? Draft a policy proposal and > post it on the PPML. If your colleagues agree with you, that will > become one of ARIN's roles. > > Until then, you criticize ARIN unfairly for doing what you and I have > told it to do. > > Regards, > Bill Herrin > I apologize if I was unclear. I stated in my first message regarding the possibility that RIRs could delegate abandoned/hijacked space to provide reverse DNS answers - "This is something that ARIN *could* easily do technically. Admittedly, this would require reporting and investigation that I am uncertain whether or not ARIN is empowered/funded to do. This would also require a process be put in place for removing allocations from the delegation to the unused/abandoned reverse DNS servers... " The word 'could' was chosen by me instead of the word 'should' for a reason. In my second message on this topic I in fact quoted the parts of ARIN's Number Resource Policy Manual regarding POC and reverse DNS delegation validation / removal. I am well aware of ARIN's policies and the process for changing them. To be clear, my point is merely that RIRs do not make address allocations and then walk away with no day to day involvement with these addresses on some technical level. To reiterate: "The RIR's reverse DNS servers are queried all day every day for the reverse DNS delegations for every netblock that they allocate. This means that RIRs are, in at least this way, actively operationally involved in the use of the allocations that they make. This also means that an RIR has the technical vector to affect the active present use of the allocations that they have made in the past." This was meant in no way to criticize RIRs (or any RIR in particular) or proscribe actions that I believe RIRs should take. This was meant to correct anyone that incorrectly states that RIRs allocate addresses and then walk away or do nothing but maintain whois records. Reverse DNS delegation is a technical vector that could be used by RIRs to affect the active present use of the allocations that they have made in the past. I understand that reverse DNS would not affect route announcements/hijacks, but it would/could/might affect spam coming from these abandoned address spaces - which was the original topic for this discussion. I agree that little/nothing is proscribed for RIRs at a policy level. The policies and procedures regarding this could be written. I agree that these policies and procedures do not exist now. -DM From gbonser at seven.com Fri Oct 1 16:12:46 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 14:12:46 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: References: <6777.1285912054@tristatelogic.com><5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com><20101001120050.GA29429@gsp.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Christopher Morrow > Sent: Friday, October 01, 2010 7:46 AM > To: Rich Kulawiec > Cc: nanog at nanog.org > Subject: Re: AS11296 -- Hijacked? > > this is still less than a /8, which lasts ~3 months in ARIN region and > less if you could across RIR's... Which is sort of like saying: Citizen: "Hello, police? There is a crate of M-16's and a truckload of ammunition just sitting here on the corner" Police: "That is less than the Army goes through in 3 months ... *click*" While true, it is orthogonal to the point being made which is if you collect those resources and issue them to legitimate operators, those are some 6.6 million unique hosts addresses than cannot be used for various nefarious activities. From bill at herrin.us Fri Oct 1 16:26:57 2010 From: bill at herrin.us (William Herrin) Date: Fri, 1 Oct 2010 17:26:57 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> Message-ID: On Fri, Oct 1, 2010 at 5:12 PM, George Bonser wrote: >> this is still less than a /8, which lasts ~3 months in ARIN region and >> less if you could across RIR's... > > Which is sort of like saying: > > Citizen: "Hello, police? ?There is a crate of M-16's and a truckload of > ammunition just sitting here on the corner" > Police: ?"That is less than the Army goes through in 3 months ... > *click*" Death by IP address? -Bill -- 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 Fri Oct 1 16:27:47 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 14:27:47 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: References: <7865.1285924930@tristatelogic.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B09E@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Ricky Beam > Sent: Friday, October 01, 2010 1:00 PM > To: nanog at nanog.org > Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time > > On Fri, 01 Oct 2010 06:45:10 -0400, Owen DeLong > wrote: > > It's not so much a matter of whether ARIN cares or whether ARIN wants > > to do something about your issue. It's more a matter of whether ARIN > > is empowered to do anything at all about your issue. > > EXACTLY. > > Ron, what exactly do you expect ARIN to do? Where is the magic wand > one > would wave to erase routes from the internet? ARIN (in fact NO ONE) > has > no actual means to block or recend any route announcement. Do you > suggest > they sue whomever is involved? That won't be very fast, or even an > option > outside the US. The problem as I see it is that ARIN is responsible for issuing number resources but is not responsible for any maintenance of the number space. It seems they have no requirement/method/need to revoke assignments once the assigned entity no longer exists. I am not looking for perfection but there should be some sort of diligence requirement that the most obvious of the low hanging fruit (or fruit that falls right off the tree into their lap) be dealt with in some way. If an entity liquidates, then their resources should be reclaimed. How many entities does ARIN have who have not made a payment for 2 or more consecutive years but still have resources assigned? It is my personal opinion that ARIN (and the other registrars) must have the authority and the mechanism to reclaim community resources when the entity they were issued to disappears. That seems like a fairly easy concept. Note I am not talking about misuse here, just the fact that if a community resource is issued to an entity and that entity no longer exists, those resources should be reclaimed by the community within some reasonable amount of time. G From gbonser at seven.com Fri Oct 1 16:31:51 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 14:31:51 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> > -----Original Message----- > From: wherrin at gmail.com > Herrin > Sent: Friday, October 01, 2010 2:27 PM > To: George Bonser > Cc: Christopher Morrow; nanog at nanog.org > Subject: Re: AS11296 -- Hijacked? > > > Death by IP address? > > -Bill Quite possible if one is using it to distribute a virus. RE: Spanair flight JK-5022 http://www.monstersandcritics.com/news/europe/news/article_1578877.php/C omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash From jcurran at arin.net Fri Oct 1 16:32:47 2010 From: jcurran at arin.net (John Curran) Date: Fri, 1 Oct 2010 17:32:47 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> Message-ID: <19DC2CB6-8AD6-4730-BD3D-DA69CE684E8E@arin.net> George - Full agreement; the next step is defining a deterministic process for identifying these specific resources which are hijacked, and then making a policy for ARIN to act. We have a duty of stewardship, so addressing this problem is a priority if the community directs us to do so via policy. /John On Oct 1, 2010, at 5:12 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Christopher Morrow >> Sent: Friday, October 01, 2010 7:46 AM >> To: Rich Kulawiec >> Cc: nanog at nanog.org >> Subject: Re: AS11296 -- Hijacked? >> >> this is still less than a /8, which lasts ~3 months in ARIN region and >> less if you could across RIR's... > > Which is sort of like saying: > > Citizen: "Hello, police? There is a crate of M-16's and a truckload of > ammunition just sitting here on the corner" > Police: "That is less than the Army goes through in 3 months ... > *click*" > > While true, it is orthogonal to the point being made which is if you > collect those resources and issue them to legitimate operators, those > are some 6.6 million unique hosts addresses than cannot be used for > various nefarious activities. > > From gbonser at seven.com Fri Oct 1 16:35:39 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 14:35:39 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> References: <6777.1285912054@tristatelogic.com><5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com><20101001120050.GA29429@gsp.org><5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0A0@RWC-EX1.corp.seven.com> Try this link instead http://tinyurl.com/2cngbx6 > -----Original Message----- > From: George Bonser [mailto:gbonser at seven.com] > Sent: Friday, October 01, 2010 2:32 PM > To: William Herrin > Cc: nanog at nanog.org > Subject: RE: AS11296 -- Hijacked? > > > > > -----Original Message----- > > From: wherrin at gmail.com > > Herrin > > Sent: Friday, October 01, 2010 2:27 PM > > To: George Bonser > > Cc: Christopher Morrow; nanog at nanog.org > > Subject: Re: AS11296 -- Hijacked? > > > > > > Death by IP address? > > > > -Bill > > Quite possible if one is using it to distribute a virus. RE: Spanair > flight JK-5022 > > http://www.monstersandcritics.com/news/europe/news/article_1578877.php/ > C > omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash > > From jcurran at arin.net Fri Oct 1 16:43:47 2010 From: jcurran at arin.net (John Curran) Date: Fri, 1 Oct 2010 17:43:47 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B09E@RWC-EX1.corp.seven.com> References: <7865.1285924930@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B09E@RWC-EX1.corp.seven.com> Message-ID: <67EF8EE2-8B1E-45F9-892E-9E6B88ADB727@arin.net> On Oct 1, 2010, at 5:27 PM, George Bonser wrote: > > The problem as I see it is that ARIN is responsible for issuing number > resources but is not responsible for any maintenance of the number > space. It seems they have no requirement/method/need to revoke > assignments once the assigned entity no longer exists. I am not looking > for perfection but there should be some sort of diligence requirement > that the most obvious of the low hanging fruit (or fruit that falls > right off the tree into their lap) be dealt with in some way. If an > entity liquidates, then their resources should be reclaimed. Resources being used by actual defunct organizations we will reclaim if reported. > How many entities does ARIN have who have not made a payment for 2 or > more consecutive years but still have resources assigned? It is my > personal opinion that ARIN (and the other registrars) must have the > authority and the mechanism to reclaim community resources when the > entity they were issued to disappears. We already do this type of reclamation. > That seems like a fairly easy > concept. Note I am not talking about misuse here, just the fact that if > a community resource is issued to an entity and that entity no longer > exists, those resources should be reclaimed by the community within some > reasonable amount of time Agreed, /John John Curran President and CEO ARIN From bill at herrin.us Fri Oct 1 16:50:28 2010 From: bill at herrin.us (William Herrin) Date: Fri, 1 Oct 2010 17:50:28 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> Message-ID: On Fri, Oct 1, 2010 at 5:31 PM, George Bonser wrote: > Quite possible if one is using it to distribute a virus. RE: Spanair > flight JK-5022 > > http://www.monstersandcritics.com/news/europe/news/article_1578877.php/C > omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash Hi George, That's been debunked. http://www.zdnet.com/blog/bott/fact-check-malware-did-not-bring-down-a-passenger-jet/2354?tag=nl.e550 "A computer at the airline?s maintenance headquarters [...] was infected with some sort of malware. [...] That same computer is used to record incident reports submitted by mechanics and is programmed to raise an alarm if the same problem occurs three times on the same aircraft. On the day of the crash, the plane returned to the gate after the crew noticed a problem. The mechanics at the airport identified the issue and cleared the plane for takeoff. They apparently didn?t know that this was the third report of a similar problem in a two-day period. But even if the headquarters office had maintained its PC perfectly, the plane would still have taken off. The mechanics were still entering their report at the time of the crash." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cidr-report at potaroo.net Fri Oct 1 17:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Oct 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201010012200.o91M02TS088757@wattle.apnic.net> BGP Update Report Interval: 23-Sep-10 -to- 30-Sep-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8151 24582 2.3% 12.3 -- Uninet S.A. de C.V. 2 - AS3464 21803 2.0% 484.5 -- ASC-NET - Alabama Supercomputer Network 3 - AS32528 17249 1.6% 2156.1 -- ABBOTT Abbot Labs 4 - AS5536 15687 1.5% 146.6 -- Internet-Egypt 5 - AS35931 13325 1.2% 4441.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS5800 12818 1.2% 59.3 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 7 - AS8452 9632 0.9% 9.7 -- TE-AS TE-AS 8 - AS3816 9132 0.9% 24.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 9 - AS10620 9023 0.8% 6.8 -- Telmex Colombia S.A. 10 - AS4771 8955 0.8% 25.7 -- NZTELECOM Netgate 11 - AS14420 8319 0.8% 13.7 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 12 - AS27738 7444 0.7% 35.4 -- Ecuadortelecom S.A. 13 - AS2764 7225 0.7% 21.2 -- AAPT AAPT Limited 14 - AS7552 6856 0.6% 10.6 -- VIETEL-AS-AP Vietel Corporation 15 - AS3475 6692 0.6% 291.0 -- LANT-AFLOAT - Navy Network Information Center (NNIC) 16 - AS9498 6370 0.6% 14.1 -- BBIL-AP BHARTI Airtel Ltd. 17 - AS21017 6184 0.6% 618.4 -- VSI-AS VSI AS 18 - AS9829 6149 0.6% 24.0 -- BSNL-NIB National Internet Backbone 19 - AS15399 5871 0.6% 65.2 -- WANANCHI-KE 20 - AS36992 5846 0.6% 11.7 -- ETISALAT-MISR TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35931 13325 1.2% 4441.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS32528 17249 1.6% 2156.1 -- ABBOTT Abbot Labs 3 - AS22753 1896 0.2% 1896.0 -- REDHAT-STUTTGART REDHAT Stuttgart 4 - AS53532 1037 0.1% 1037.0 -- KINGMETALS - King Architectural Metals 5 - AS45600 948 0.1% 948.0 -- UPM-AS-AP University of the Philippines, Manila 6 - AS38531 828 0.1% 828.0 -- SULLCROM-HK Sullivan & Cromwell LLP, Hong Kong Site, International Law Firm. 7 - AS11613 702 0.1% 702.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 8 - AS53327 685 0.1% 685.0 -- CO-OPERATIVE-INSURANCE-COMPANIES - Co-operative Insurance Companies, inc. 9 - AS14294 638 0.1% 638.0 -- LIBERTYTEL - Liberty Telecom, LLC 10 - AS15984 622 0.1% 622.0 -- The Joint-Stock Commercial Bank CentroCredit. 11 - AS21017 6184 0.6% 618.4 -- VSI-AS VSI AS 12 - AS31055 579 0.1% 579.0 -- CONSULTIX-AS Consultix GmbH 13 - AS33775 4398 0.4% 549.8 -- NITEL-AS 14 - AS3 540 0.1% 333.0 -- STOFANET Stofa A/S 15 - AS27027 538 0.1% 538.0 -- ANBELL ASN-ANBELL 16 - AS3464 21803 2.0% 484.5 -- ASC-NET - Alabama Supercomputer Network 17 - AS37204 3385 0.3% 483.6 -- TELONE 18 - AS37065 462 0.0% 462.0 -- ZOOM-AS 19 - AS703 381 0.0% 381.0 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 20 - AS9556 1745 0.2% 349.0 -- ADAM-AS-AP Adam Internet Pty Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.0.0/17 10808 0.9% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.128.0/17 10804 0.9% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 130.36.34.0/24 8616 0.7% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 8616 0.7% AS32528 -- ABBOTT Abbot Labs 5 - 201.134.18.0/24 8420 0.7% AS8151 -- Uninet S.A. de C.V. 6 - 63.211.68.0/22 7886 0.7% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - 198.140.43.0/24 5327 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 190.65.228.0/22 5307 0.5% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 9 - 216.126.136.0/22 4645 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 10 - 148.204.141.0/24 4249 0.4% AS8151 -- Uninet S.A. de C.V. 11 - 95.32.192.0/18 3326 0.3% AS21017 -- VSI-AS VSI AS 12 - 206.184.16.0/24 3062 0.3% AS174 -- COGENT Cogent/PSI 13 - 216.118.245.0/24 3008 0.3% AS25747 -- VSC-SATELLITE-CO - VSC Satellite Co. 14 - 95.32.128.0/18 2824 0.2% AS21017 -- VSI-AS VSI AS 15 - 202.92.235.0/24 2535 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 16 - 64.86.26.0/23 2473 0.2% AS37204 -- TELONE 17 - 41.238.176.0/23 1985 0.2% AS8452 -- TE-AS TE-AS 18 - 66.187.234.0/24 1896 0.2% AS22753 -- REDHAT-STUTTGART REDHAT Stuttgart 19 - 138.116.134.0/24 1369 0.1% AS7018 -- ATT-INTERNET4 - AT&T WorldNet Services 20 - 205.90.224.0/20 1159 0.1% AS3475 -- LANT-AFLOAT - Navy Network Information Center (NNIC) 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 Oct 1 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 1 Oct 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201010012200.o91M0030088752@wattle.apnic.net> This report has been generated at Fri Oct 1 21:12:03 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 24-09-10 336850 207985 25-09-10 336997 207887 26-09-10 337000 208528 27-09-10 337205 208311 28-09-10 337437 208418 29-09-10 337629 208515 30-09-10 337929 208442 01-10-10 337368 208582 AS Summary 35515 Number of ASes in routing system 15117 Number of ASes announcing only one prefix 4480 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 96837376 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'). --- 01Oct10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 337851 208477 129374 38.3% All ASes AS6389 3776 282 3494 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4480 1946 2534 56.6% TWTC - tw telecom holdings, inc. AS19262 1822 286 1536 84.3% VZGNI-TRANSIT - Verizon Online LLC AS4766 1861 519 1342 72.1% KIXS-AS-KR Korea Telecom AS22773 1199 66 1133 94.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1357 290 1067 78.6% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1347 297 1050 78.0% HATHWAY-NET-AP Hathway IP Over Cable Internet AS18566 1087 63 1024 94.2% COVAD - Covad Communications Co. AS5668 1080 95 985 91.2% AS-5668 - CenturyTel Internet Holdings, Inc. AS10620 1324 344 980 74.0% Telmex Colombia S.A. AS6478 1354 426 928 68.5% ATT-INTERNET3 - AT&T WorldNet Services AS1785 1796 962 834 46.4% AS-PAETEC-NET - PaeTec Communications, Inc. AS13343 1385 633 752 54.3% SCRR-13343 - Road Runner HoldCo LLC AS7303 810 114 696 85.9% Telecom Argentina S.A. AS8452 1009 345 664 65.8% TE-AS TE-AS AS7545 1414 757 657 46.5% TPG-INTERNET-AP TPG Internet Pty Ltd AS8151 1338 691 647 48.4% Uninet S.A. de C.V. AS18101 882 247 635 72.0% RIL-IDC Reliance Infocom Ltd Internet Data Centre, AS4808 936 303 633 67.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS4804 665 75 590 88.7% MPX-AS Microplex PTY LTD AS28573 1161 601 560 48.2% NET Servicos de Comunicao S.A. AS7018 1488 959 529 35.6% ATT-INTERNET4 - AT&T WorldNet Services AS4780 706 180 526 74.5% SEEDNET Digital United Inc. AS17676 607 81 526 86.7% GIGAINFRA Softbank BB Corp. AS24560 1040 517 523 50.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS7552 648 137 511 78.9% VIETEL-AS-AP Vietel Corporation AS9443 575 77 498 86.6% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 1157 667 490 42.4% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 561 82 479 85.4% VTR BANDA ANCHA S.A. AS14420 564 102 462 81.9% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP Total 39429 12144 27285 69.2% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.20.80.0/20 AS40028 SPD-NETWORK-1 - SPD NETWORK 64.21.192.0/20 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.212.0/22 AS11610 INETNEBR-1 - Internet Nebraska Corporation 64.21.216.0/21 AS11610 INETNEBR-1 - Internet Nebraska Corporation 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.234.0.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, 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. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 91.198.217.0/24 AS50877 INSTANTEXCHANGER-AS InstantExchanger Ltd. 96.45.160.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 96.47.48.0/20 AS3257 TINET-BACKBONE Tinet SpA 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. 114.142.160.0/21 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.160.0/22 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.168.0/21 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.168.0/23 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.171.0/24 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.172.0/24 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 115.42.0.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.5.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.6.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.11.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.20.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.29.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.31.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.43.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 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 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 173.225.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 190.102.32.0/20 AS30058 ACTIVO-SYSTEMS-AS30058 ACTIVO-SYSTEMS-AS30058 192.9.0.0/16 AS11479 BRM-SUN-AS - Sun Microsystems, Inc 192.64.85.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.69.108.0/24 AS1759 TSF-IP-CORE TeliaSonera Finland IP Network 192.101.46.0/24 AS6503 Axtel, S.A.B. de C.V. 192.101.64.0/21 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.70.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.71.0/24 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 192.101.72.0/24 AS702 AS702 Verizon Business EMEA - Commercial IP service provider in Europe 192.101.74.0/24 AS1239 SPRINTLINK - Sprint 192.124.252.0/22 AS680 DFN-IP service X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.58.113.0/24 AS19161 202.61.75.0/24 AS9927 PHILCOMNET-PH A Multihomed ISP Company 202.66.128.0/18 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/19 AS9584 GENESIS-AP Diyixian.com Limited 202.66.160.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.176.0/20 AS9584 GENESIS-AP Diyixian.com Limited 202.66.184.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.186.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.188.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.189.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.66.190.0/24 AS9584 GENESIS-AP Diyixian.com Limited 202.73.144.0/20 AS4788 TMNET-AS-AP TM Net, Internet Service Provider 202.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.174.125.128/26 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.98.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.99.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.103.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.175.110.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication 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 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 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.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.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 209.236.96.0/20 AS3257 TINET-BACKBONE Tinet SpA 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 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.47.32.0/20 AS3257 TINET-BACKBONE Tinet SpA 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From jcurran at arin.net Fri Oct 1 17:18:44 2010 From: jcurran at arin.net (John Curran) Date: Fri, 1 Oct 2010 18:18:44 -0400 Subject: ARIN Fraud Reporting Form ... Don't waste your time (more re: recovered resources) In-Reply-To: <67EF8EE2-8B1E-45F9-892E-9E6B88ADB727@arin.net> References: <7865.1285924930@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B09E@RWC-EX1.corp.seven.com> <67EF8EE2-8B1E-45F9-892E-9E6B88ADB727@arin.net> Message-ID: On Oct 1, 2010, at 5:43 PM, John Curran wrote: > > Resources being used by actual defunct organizations we will reclaim if reported. Folks - It occurred to me that I could have been clearer, so here I am replying to myself... When we at ARIN can readily determine that an organization is defunct and has no apparent successor, we will reclaim resources. This generally happens because someone attempts a fraudulent transfer of those resources but can also be a result of other investigations. We give a report of returned, revoked, and reclaimed number resources at each member meeting - last April's report can be found here: https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Wednesday/Nobile_RSD.pdf Obviously, we'll be presenting updated statistics this upcoming week in Atlanta; there's been a bit of a surge of activity in this area. /John John Curran President and CEO ARIN From springer at inlandnet.com Fri Oct 1 17:25:43 2010 From: springer at inlandnet.com (John Springer) Date: Fri, 1 Oct 2010 15:25:43 -0700 (PDT) Subject: ARIN Fraud Reporting Form ... Don't waste your time (more re: recovered resources) In-Reply-To: References: <7865.1285924930@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B09E@RWC-EX1.corp.seven.com> <67EF8EE2-8B1E-45F9-892E-9E6B88ADB727@arin.net> Message-ID: <20101001152349.S4415@mail.inlandnet.com> Thanks John, On Fri, 1 Oct 2010, John Curran wrote: > On Oct 1, 2010, at 5:43 PM, John Curran wrote: >> >> Resources being used by actual defunct organizations we will reclaim if reported. > > Folks - > > It occurred to me that I could have been clearer, so here I am replying > to myself... > > When we at ARIN can readily determine that an organization is defunct > and has no apparent successor, we will reclaim resources. This generally > happens because someone attempts a fraudulent transfer of those resources > but can also be a result of other investigations. > > We give a report of returned, revoked, and reclaimed number resources at > each member meeting - last April's report can be found here: > https://www.arin.net/participate/meetings/reports/ARIN_XXV/PDF/Wednesday/Nobile_RSD.pdf Is the information on Leslie's slide 5 at the above link available broken down by year? It might be informative to see any trends. Thanks again, John Springer > Obviously, we'll be presenting updated statistics this upcoming week in > Atlanta; there's been a bit of a surge of activity in this area. > > /John > > John Curran > President and CEO > ARIN > > > > > From Bryan at bryanfields.net Fri Oct 1 17:26:00 2010 From: Bryan at bryanfields.net (Bryan Fields) Date: Fri, 01 Oct 2010 18:26:00 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> References: <6777.1285912054@tristatelogic.com><5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com><20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> Message-ID: <4CA65FF8.90304@bryanfields.net> On 10/1/2010 17:12, George Bonser wrote: > Citizen: "Hello, police? There is a crate of M-16's and a truckload of > ammunition just sitting here on the corner" > Police: "That is less than the Army goes through in 3 months ... > *click*" You'd have better luck calling the ATF, they are the ones empowered to enforce the tax on machine guns. The local police do not have any authority to enforce those taxes, and could get sued if they tried to. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net From gbonser at seven.com Fri Oct 1 17:39:39 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 15:39:39 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0A6@RWC-EX1.corp.seven.com> > -----Original Message----- > From: wherrin at gmail.com On Behalf Of William > Herrin > Sent: Friday, October 01, 2010 2:50 PM > To: George Bonser > Cc: nanog at nanog.org > Subject: Re: AS11296 -- Hijacked? > > On Fri, Oct 1, 2010 at 5:31 PM, George Bonser > wrote: > > Quite possible if one is using it to distribute a virus. RE: Spanair > > flight JK-5022 > > > > > http://www.monstersandcritics.com/news/europe/news/article_1578877.php/ > C > > omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash > > Hi George, > > That's been debunked. Good. Ok, now shall we move on to Stuxnet which now seems to be infiltrating China. We don't know yet if that will cause any problems or not. The idea that there are fairly significant amounts of address space that could be used for practically anything at any time is probably a bigger issue in 2010 than it was in 1995 simply because we have more infrastructure that is either directly or indirectly exposed to it. Malware distributed on the internet can find its way onto a laptop and from there a thumb drive and from there to a computer used for medical purposes or at a chemical plant is more plausible of a scenario these days. Why make it EASY to distribute such things? Why do you seem to be defending the idea that it is somehow good to have lots of unaccounted for address space out there? Do you use it for something? G From nathan at atlasnetworks.us Fri Oct 1 17:43:50 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 1 Oct 2010 22:43:50 +0000 Subject: AS11296 -- Hijacked? In-Reply-To: <4CA65FF8.90304@bryanfields.net> References: <6777.1285912054@tristatelogic.com><5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com><20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> <4CA65FF8.90304@bryanfields.net> Message-ID: <8C26A4FDAE599041A13EB499117D3C2840600241@ex-mb-2.corp.atlasnetworks.us> > > Citizen: "Hello, police? There is a crate of M-16's and a truckload > > of ammunition just sitting here on the corner" > > Police: "That is less than the Army goes through in 3 months ... > > *click*" > > You'd have better luck calling the ATF, they are the ones empowered to > enforce the tax on machine guns. The local police do not have any authority > to enforce those taxes, and could get sued if they tried to. Why are we diverting the topic from 'draft a proposal to empower ARIN to deal with these sorts of problems' to 'arguing with meaningless analogies that do nothing except make the author feel good'? This is an operations list, not a debate team. Nathan From jcdill.lists at gmail.com Fri Oct 1 17:48:34 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Fri, 01 Oct 2010 15:48:34 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: <4CA65FF8.90304@bryanfields.net> References: <6777.1285912054@tristatelogic.com><5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com><20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> <4CA65FF8.90304@bryanfields.net> Message-ID: <4CA66542.9090000@gmail.com> Bryan Fields wrote: > On 10/1/2010 17:12, George Bonser wrote: > >> Citizen: "Hello, police? There is a crate of M-16's and a truckload of >> ammunition just sitting here on the corner" >> Police: "That is less than the Army goes through in 3 months ... >> *click*" >> > > You'd have better luck calling the ATF, they are the ones empowered to enforce > the tax on machine guns. The local police do not have any authority to > enforce those taxes, and could get sued if they tried to. > Here's an incident where the "local authorities" didn't know what to do about a possibly very worrisome incident at SJC (San Jose International Airport): The problem is that people don't *think* - they just follow orders, follow their training. No one had thought about or trained for this type of incident. Fortunately, in this case, the people were not terrorists. Meanwhile, TSA confiscates bottles of shampoo and water. jc From owen at delong.com Fri Oct 1 18:00:51 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 16:00:51 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> Message-ID: <8CC300ED-C243-4186-A9BE-C36EF854145D@delong.com> On Oct 1, 2010, at 2:31 PM, George Bonser wrote: > > >> -----Original Message----- >> From: wherrin at gmail.com >> Herrin >> Sent: Friday, October 01, 2010 2:27 PM >> To: George Bonser >> Cc: Christopher Morrow; nanog at nanog.org >> Subject: Re: AS11296 -- Hijacked? >> >> >> Death by IP address? >> >> -Bill > > Quite possible if one is using it to distribute a virus. RE: Spanair > flight JK-5022 > > http://www.monstersandcritics.com/news/europe/news/article_1578877.php/C > omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash > > http://aircrewbuzz.com/2008/10/officials-release-preliminary-report-on.html A more recent Interim report: http://www.fomento.es/NR/rdonlyres/AADDBF93-690C-4186-983C-8D897F09EAA5/75736/2008_032_A_INTERINO_01_ENG.pdf The crew apparently skipped the step where they were supposed to deploy the slats/flaps prior to takeoff. Additionally, the warning system on the aircraft which should have alerted the crew to the failure to extend the flaps/slats also failed to sound. A computer virus may have had a small contribution to the failure to detect the warning system failure in the maintenance process, but, it did not cause the accident. The accident is clearly the result of pilot error, specifically the failure to properly configure the aircraft for takeoff and failure to take remedial action upon activation of the stall warning system during the initial climb. Owen (who is also a pilot with a commercial rating) From morrowc.lists at gmail.com Fri Oct 1 18:08:34 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 1 Oct 2010 19:08:34 -0400 Subject: Using crypto auth for detecting corrupted IGP packets? In-Reply-To: References: <8943BD09-32CF-4F83-9EBE-1558679E1FEF@puck.nether.net> <14643A97-2A17-4859-93EB-9CC4187FDCBA@arbor.net> <043AE224-2A9C-453B-B6E7-B782AC6B7C28@arbor.net> Message-ID: On Fri, Oct 1, 2010 at 7:26 AM, Jared Mauch wrote: > > On Oct 1, 2010, at 3:49 AM, Dobbins, Roland wrote: > >> >> On Oct 1, 2010, at 1:01 PM, Manav Bhatia wrote: >> >>> In 6 hours you will have around 8000K BFD packets. Add OSPF, >>> RSVP, BGP, LACP (for lags), dot1AG, EFM and you would really get a >>> significant number of packets to buffer. >> >> >> Which isn't a 'HUGE!' amount of packets. >> >> ;> > > > Yup, but when trying to figure out the root cause of some problem, having a few gigs of data would be helpful. > > In the event people have not noticed, hard drives are semi-popular in routers now, so assuming you have some variable amount of disk space greater than 8MB for an image is feasible. on at least one platform you can get some details with traceoptions, no? From owen at delong.com Fri Oct 1 18:03:56 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 16:03:56 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B09E@RWC-EX1.corp.seven.com> References: <7865.1285924930@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B09E@RWC-EX1.corp.seven.com> Message-ID: On Oct 1, 2010, at 2:27 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Ricky Beam >> Sent: Friday, October 01, 2010 1:00 PM >> To: nanog at nanog.org >> Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time >> >> On Fri, 01 Oct 2010 06:45:10 -0400, Owen DeLong >> wrote: >>> It's not so much a matter of whether ARIN cares or whether ARIN > wants >>> to do something about your issue. It's more a matter of whether ARIN >>> is empowered to do anything at all about your issue. >> >> EXACTLY. >> >> Ron, what exactly do you expect ARIN to do? Where is the magic wand >> one >> would wave to erase routes from the internet? ARIN (in fact NO ONE) >> has >> no actual means to block or recend any route announcement. Do you >> suggest >> they sue whomever is involved? That won't be very fast, or even an >> option >> outside the US. > > > The problem as I see it is that ARIN is responsible for issuing number > resources but is not responsible for any maintenance of the number > space. It seems they have no requirement/method/need to revoke > assignments once the assigned entity no longer exists. I am not looking They do, indeed, for space that is/was issued by ARIN. That space is subject to annual fees and there is a clear and consistent method for doing so. The bigger problem is with legacy space (most of the space listed in the complaint we are discussing, if not all). In the case of legacy space, it's actually very hard for ARIN to even identify the status of the organization in question, let alone take any sort of action with respect to said space. > for perfection but there should be some sort of diligence requirement > that the most obvious of the low hanging fruit (or fruit that falls > right off the tree into their lap) be dealt with in some way. If an > entity liquidates, then their resources should be reclaimed. > Again, for space issued by ARIN, yes. For legacy space, this is a much more complicated problem. The good news is that this is limited to IPv4. Since there are no Pre-RIR IPv6 allocations or assignments, it is a non-issue in IPv6. > How many entities does ARIN have who have not made a payment for 2 or > more consecutive years but still have resources assigned? It is my I suspect not many. (Unless you are including those organizations that do not pay fees because of their legacy status). Owen From morrowc.lists at gmail.com Fri Oct 1 18:16:02 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 1 Oct 2010 19:16:02 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> Message-ID: On Fri, Oct 1, 2010 at 5:12 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Christopher Morrow >> this is still less than a /8, which lasts ~3 months in ARIN region and >> less if you could across RIR's... > > Which is sort of like saying: > no, the point is/was that the number of addresses isn't likely the really important point you don't care about reclaiming addresses because of the size of the allocations. you care to reclaim because of improper use/abuse and/or "theft" of the resource. Nathan is correct though, propose some policy text that the community can get behind? probably also do that on ppml.... -Chris -chris From owen at delong.com Fri Oct 1 18:16:16 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 16:16:16 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: <4CA66542.9090000@gmail.com> References: <6777.1285912054@tristatelogic.com><5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com><20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> <4CA65FF8.90304@bryanfields.net> <4CA66542.9090000@gmail.com> Message-ID: On Oct 1, 2010, at 3:48 PM, JC Dill wrote: > Bryan Fields wrote: >> On 10/1/2010 17:12, George Bonser wrote: >> >>> Citizen: "Hello, police? There is a crate of M-16's and a truckload of >>> ammunition just sitting here on the corner" >>> Police: "That is less than the Army goes through in 3 months ... >>> *click*" >>> >> >> You'd have better luck calling the ATF, they are the ones empowered to enforce >> the tax on machine guns. The local police do not have any authority to >> enforce those taxes, and could get sued if they tried to. >> > Here's an incident where the "local authorities" didn't know what to do about a possibly very worrisome incident at SJC (San Jose International Airport): > > > > The problem is that people don't *think* - they just follow orders, follow their training. No one had thought about or trained for this type of incident. Fortunately, in this case, the people were not terrorists. Meanwhile, TSA confiscates bottles of shampoo and water. > > jc > > > > Having now read that article, it really strikes me as much ado about nothing. The men were not concealing the lawfully carried weapons. They were carrying the weapons in a lawful manner. I suspect that all of their permits were in order. They did not shoot anyone. No animals were harmed in the making of this farce. Turns out they were legitimate armed guards from US DoE on legitimate business. Frankly, I'd be much more worried about the safety of whatever was in that man's luggage being on the flight than about the guards carrying assault rifles in the non-secure area of the airport. Heck, we let SJPD carry guns in that area, why shouldn't the general public? Owen From franck at genius.com Fri Oct 1 18:39:29 2010 From: franck at genius.com (Franck Martin) Date: Fri, 1 Oct 2010 16:39:29 -0700 (PDT) Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: Message-ID: <24405525.271.1285976366914.JavaMail.franck@linko-biatch-6.genius.local> A yearly challenge response for legacy space contacts, could be useful. I think there is a plan like this in some RIRs ----- Original Message ----- From: "Owen DeLong" To: "George Bonser" Cc: nanog at nanog.org Sent: Friday, 1 October, 2010 4:03:56 PM Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time On Oct 1, 2010, at 2:27 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Ricky Beam >> Sent: Friday, October 01, 2010 1:00 PM >> To: nanog at nanog.org >> Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time >> In the case of legacy space, it's actually very hard for ARIN to even identify the status of the organization in question, let alone take any sort of action with respect to said space. Owen From rfg at tristatelogic.com Fri Oct 1 19:08:27 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 01 Oct 2010 17:08:27 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <608B18DB-6E75-4B5E-BA42-D1F69ECE4881@arin.net> Message-ID: <15149.1285978107@tristatelogic.com> In message <608B18DB-6E75-4B5E-BA42-D1F69ECE4881 at arin.net>, John Curran wrote: >You note the following: > >> They could say, to everyone involved, and to the community as a whole, >> ``This ain't right. *We* maintain the official allocation records. >> In most cases, *we* made the allocations, and that guy should NOT be >> announcing routes to that IP space, and he shouldn't be announcing >> anything at all via that AS number, because these things ain't his.'' > >At present, ARIN doesn't review the routing of address space to see >if an allocation made to party is being announced by another party. >From your emails, I'm guess that you'd like ARIN to do so. John, First, let me say thanks for your personal response. Second let me also say that I am pleased to know, at least, that my serious efforts to express myself clearly were not lost on everyone. You have grasped my meaning clearly. (But not everyone here has done likewise.) >I've run several several ISPs and a hosting firm, and I'm not quite >sure how ARIN can definitively know that any of the AS#'s involved >should or should not be routing a given network block. Please allow me to attempt to refute what you just said. I think that I can do so, briefly, in (at least) two different ways. 1) You folks _are_ already (apparently) making some efforts... at least as of this last summer, but perhaps also earlier... to ``validate'' (is that the word you would use?) POC contacts. I know because I've lately seen quite a number of your POC contact records (from the WHOIS data base) that have a very helpful annotation attached to them, saying quite directly and explicitly, that ARIN has been unable to verify or make contact with this POC or that POC. So you are already passing judgement on the validity and/or probable invalidity of things in your data base. And more, you are making your determinations public, via the data base itself. I'm not quite sure how it constitutes such a big leap to merely extend what you are already doing in the way of validating POCs and just impute the exact same level of confidence, or lack thereof, to IP block and/or AS records which are associated with unverifiable/uncontactable POCs... a set which you are already making serious efforts to delineate anyway. If you can put an annotation into a whois records for a POC, saying explicity that you can't get ahold of this person, then it would seem to me to be a rather trivial matter of programming to transplant a very similar sort of annotation into each and every IP block or AS record that has that same specific POC record as one of its associated POC records, either Admin, or Technical, or whatever. You could just say, you know, something like ``We have been tring to contact the Technical POC for this since XX-XX-2010, and we've been unable to do so.'' Well, not those words exactly, but I hope you get the general idea. Just take the determinations that you folks are _already_ making, for the POC records, and just impute them to, and include them in, also, to the relevant block and/or AS records. Or alternatively, you could stop using verbage altogether and just switch over to a system based on simple, universally understood icons: http://farm2.static.flickr.com/1082/820306671_6a0520fe17_m.jpg http://farm2.static.flickr.com/1382/1263977902_d0e9a43821_o.jpg Now, you may perhaps be tempted to quibble with my point here, and repeat again what you said above, I.e. that ARIN cannot make ``definitive'' determinations. Please don't yield to any such temptation. Quite frankly, to the best of my knowledge, no living human can reliably make any truly ``definitive'' determinations about anything at all. Only God can do that. (And frankly, I harbor lingering suspicions that even He gets it wrong a fair percentage of the time.) Nobody expects you to have the infallibility of God... or even of the Pope. And nobody is asking you to display such a level of infinite perfection, least of all me. But ya know, even in the abundant absence of certainty in our day-to-day lives, we all still drag ourselves out of bed in the morning and do the best that we can. And that's all that either I or anybody else has any right to ask of you/ARIN or to expect of you/ARIN. Just do the best you can. Are your deteminations that this POC or that POC cannot be contacted, or cannot currently be verified ``definitive''? No, that's probably too stong a word. But you/ARIN have the good sense and the courtesy to publish the information you have gathered regarding the contactability of POCs anyway, and it's appreciated. It helps. Please just do more of it. This is not an all-or-nothing ``We can't say anything definitively so we can't say anything at all, ever'' kind of situation, I think. 2) You are already (apparently) processing _some_ certain flavors of ``fraud reports'' that come in to you via that nice fancy web form you folks built and put up on the ARIN web site... you know... the one with the nice (and misleading) introduction that entices people like me to take the time to use it enter reports about incidents that have traditionally been called around these parts ``hijacking''. (Note: That's the word that _you_ used on your web site to say what should be reported via the form. Was I a fool to take you at your word? Let me be clear... I am *not* *not* *not* encouraging you to simply redact/delete that word from your web site. No no! Rather I hope to encourage you/ARIN to actually accept and at least investigate reports of _all_ flavors of what we around here used to call good old fashioned ``hijacking'', regardless of whether the perp was gracious enough to also make your choice clearer by dicking with the relevant WHOIS records or not.) So anyway, you are already, obviously, geared up to do ``investigations''. And you _are_ already doing them. Yes? And you are not doing these investigatons just for your health, as the saying goes, correct? I mean you have a goal when you do these investigations... an end goal. Right? And what is that goal? What comes out the other end when you feed the raw facts into the top of this process and then turn the crank? What do you have at the end of the day, eh? Do you have a... ahhh.. conclusion? Might one even say that at the end of the process, ARIN reaches a ``determination''? Would you characterize these determinations... which you obviously use as a basis for further action... as ``definitive detrminations''? (If not, why not? And if you use these determinations as a basis for further action, and yet you claim that they are not actually ``defininite determinations'', then aren't you placing ARIN at great risk of a lawsuit by so doing?) I think you can see where I'm going with this. You have, I think, tried to demur (is that the right word?) on ARIN's behalf, from _either_ investigating or, subsequently, from issuing any kind of ``determination'' as regards to whether a given block is being routed by the party or parties who ought to be routing it, or by some uninvited interloper. And you have done so on that basis of your very reasonable sounding claim that ARIN cannot make ``definitive'' determinations about such things. I would argue that this claim simply does not wash for two reasons: 1) ARIN is _already_, apparently, conducting investigations and thence making ``definitive'' determinations, presumably on a routine and ongoing basis, about things relating to the allocations that it, and it alone, is the official Keeper of Records for. And ARIN is already doing this, even in the absence of God-like certainty about the conclusions it reaches, and which it subsequently uses as a basis for further action. 2) If you (ARIN) claim to be utterly unable to make definitive determina- tions about what blocks belong to who, or who should be routing what, then (a) what exactly are we paying you for?? ... just kidding... *I* am not personally paying you... but more importantly (b) if even *you guys* cannot make definitive determinations about these things, then God help the rest of us! Because we mere mortals out here have a lot less data, knowledge, expertise, and experience than you ARIN folks have, and if you folks say you can't ``definitively'' figure out what belongs to who, then it sounds from where I'm sitting like you're saying that things inside of ARIN are just as bad as they were inside AIG the day _it_ went belly up... papers scattered all over the floors, and nobody even knows what all they actually own. Do I think that this is what you are trying to tell me? No. Do I even for a moment imagine that the inside of your shop... ARIN... is a confused and tangled mess like AIG was in its last days? No. No way. Not at all. Quiet the opposite. I think you folks... as the official Keepers of the Records... can... and apparently _do_ routinely make ``definitive'' determinations about the proper interpretation of the records that you yourselves keep. I'd just like to see you get on with it. Just saying that you can't ever know anything, definitively, because you're not God, is not a compelling argument to support the view that you should never do anything, or say anything, because you are not omniscient. None of us are. But we still get up in the morning and go to work. One does one's best, and leave the rest to history. >There are >some heuristics that will suggest something is "fishy" about use of >a network block... SOME??? Try a lot. (I'll be more than happy to share with you folks anything and everything that I, bloodhound-like, manage to gleen. All I ask is that you at least accept it... which the response I received earlier seemed to indicate that you were not even willing to do. The teeny little one-inch by two-inch data entry window you have on your fraud reporting form doesn't help much either, and is very off-putting in a way that makes it seem like it was intended to be that way.) >but are you actually suggesting that ARIN would >revoke resources as a result of that? Did I say that? Again, I have tried to be clear, but in this case it seems that I may have failed. No, I *do not* expect ARIN to go out, guns drawn, and start choping people's wires. No, I *do not* expect ARIN do do whatever might be implied by this terminology you are using now, which is entirely foreign to me. I have no real idea what sorts of hot-pokers-up-the-backside you may be implying by your use of this terminology "revoke resources", but whatever it means, it certainly sounds terribly ominous and foreboding, and rather like something that I wouldn't wish on my worst enemy... especially given the context and the way you phrased your question. So no, please *do not* go around ``revoking resources''... whatever the hell that means. Certainly, if some half-dead, left-for-dead dot-bomb company has a /18, and if your records still say that they have a /18, then they still have a /18. Period. And if then, some hijacker punk criminal comes along and starts routing that /18... well... he's a shmuck, and ought to be dealt with. But the old Dot-Bomb semi-defunct company still does ``own'' (please excuse my use of that terminology, which I'm sure you won't approve) that block. So you shouldn't be ``revoking'' anything. That's not what any of this is about. All I want from ARIN, and all I expect from ARIN, in cases like these are (a) at least some willingness and effort expended to investigate and (2) at least *some sort* of (perhaps minimalist) public statement to the effect of ``Look folks, we've looked at this, and in our opinion, what's going on here just doesn't look kosher.'' I would be satisfied if that ``minimalist public statement'' would be in the form of a discrete little annotation within the relevant WHOIS record(s)... you know... rather like what you folks are _already_ attaching to POC records, only maybe worded a little stronger than that, when you can see some really clear hanky panky going on... as in the cases I have publicised here recently. Of course, that said, that's kind-of my minimum request. If it were entirely up to me, you guys would call a big press conference, with CNN, MSNBC (and of course, Comedy Central, BUT NOT FIXED NEWS!) every time you caught another one of these fly-by-night hijacker jokers red-handed... as it would appear I just have, in at least two of the cases I've reported on. (I infer that, with a high level of certainty, from the fact that these nitwits already stopped announcing routes to the space they had so obviously stolen. If it was really your's in the first place, then you wouldn't just give it back the minute somebody yelled ``thief'', now would you?) And after the press conference, everyone would be invited to come out by the pool for free beer and sandwiches, and a good time would be had by all, as we collectively burned the hijacker in effigy. But you know, I'm not really expecting all of that, so just however much of it you can manage to put together would be just fine by me. (Hell! I'll even volunteer to spring for, and bring, the beer and the sandwiches. Did I mention I was from California? I guess it's kind-of obvious now, huh?) So anyway, have I managed, successfully, to make my desires more clear and apparent now? I hope so. No, I neither want nor expect ARIN to be pulling plugs out of sockets, or to be diddling the global routing table, or to be ``revoking'' anything... least of all any allocations previously made to some perfectly legit company who, through only the minor sin of inattention, got their stuff hijacked out from under them. Revoking _their_ right-to-use would simply be adding insult to injury. Don't you agree? I'd just like to see investigations and some form of public statement(s) at the ends of those. And I won't even mind if you have corporate counsel water down the public statement so much that it ends up looking like the verbal equivalent of barely raising an eyebrow. I do understand that ARIN, like the rest of us, has to somehow survive and get by in this litigous environ- ment. So I don't even care what the public statements say, or even what subtle or un-subtle forms they take. Just so long as it is understood, within the community, that (wink wink nod nod) whenever ARIN says that ``Some evidence suggests that the routing for this block may be non-normative, as per Paragraph B, Subsection F, of the Addendum to the Bylaws of the Regulations, updated, (c)1947, (c)1972, revised Sept 27th, 2007, with respect to E.12 in sum and overview, as pertaining to all parts or to the sum of the parts, together, when viewed as a unit.'' we all know and understand that this really means ``hijacked''. (Ask your corporate counsel. I'm sure that he'll be able to suggest some equally obscure and convoluted way of saying ``hijacked'' without ever actually using that word itself. That's what they are best at, after all... making simple English statements utterly imponderable.[1]) Whatever doesn't get you sued is fine by me. As long as you investigate and then say _something_ about these kinds of cases. >> In those rare >> cases where the perp is considerate enough to ALSO fiddle the relevant >> WHOIS records in some fradulent way, THEN (apparently) ARIN will get >> involved, but only to the extent of re-jiggering the WHOIS record(s). >> Once that's been done, they will happily leave the perp to announce >> all of the fradulent routes and hijacked space he wants, in perpetuity. > >Correct. We will revoke the address space, but I'm uncertain what else >you suggest we do... could you elaborate here? See above. Investigate. Then somehow... in watered-down words, and burried in the WHOIS records, if necessary... tell us what you found out. As I've said, I really don't think I'm asking for much. And I'll say again too, you guys are the Keepers of the Records. If even you guys can't say what they mean or how that meaning might or might not comport with current existing objective reality (as known to us all via looking glass servers) they God help us all! Because in that case, I think we are REALLY screwed, and nobody knows anything, and the next stop is canibalism. Regards, rfg P.S. I meant to also inquire about those POC unable-to-contact annotations. What should be infered frm those, exactly? Could you please enumerate the ways in which your staff try (and sometimes, apparently, fail) to make contact with these POCs? Is it all sytrictly done via e-mail? Do your people ever try to _telephone_ any of these folks at the numbers you force them to give ou as part of establishing a POC record in the first place? Do your people ever try contacting the POCs via snail-mail? I hope you see where I'm headed. If some poor fool with too much time on his hands... you know... like me... submits something via your fraud reporting form... I mean... you know...after you fix it so that the amount of info that can be sent to you folks via the form is somewhat bigger than this: http://www.active-robots.com/products/intelligent-displays/lcd/16x2lcd-750.jpg ...then my hope is that you would *not* just ``investigate'' by sending off an e-mail to the purported POC e-mail address, and then waiting a week to see if anything comes back. There's this wonderful new invention... you may have heard of it, although in my experience, an awful lot of Internet geeks refuse to use it. Why, I don't really know. Actually, here is a rare photo of a geek actually using one: http://farm1.static.flickr.com/5/5040260_a2c426a753.jpg So, you know, if you get a hijacking report, maybe, just maybe, could you please, please, please pick up the phone and make a call and just even try to see if the POC is alive or dead? http://farm4.static.flickr.com/3433/3176717757_20515698bf.jpg ======= [1] See also: "Sir Humphrey Appleby" From gbonser at seven.com Fri Oct 1 19:28:01 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 17:28:01 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: References: <7865.1285924930@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B09E@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0B5@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Owen DeLong > Sent: Friday, October 01, 2010 4:04 PM > To: George Bonser > Cc: Ricky Beam; nanog at nanog.org > Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time > > > On Oct 1, 2010, at 2:27 PM, George Bonser wrote: > > They do, indeed, for space that is/was issued by ARIN. That space is > subject to annual fees and there is a clear and consistent method > for doing so. The bigger problem is with legacy space (most of the > space listed in the complaint we are discussing, if not all). > > In the case of legacy space, it's actually very hard for ARIN to even > identify the status of the organization in question, let alone take > any sort of action with respect to said space. Maybe this is a teachable moment for me. According to my reading of the Legacy RSA: " For purposes of this Legacy Agreement, the term "Services" may include, without limitation, the inclusion of the legacy IP address space, and/or Autonomous System numbers ("ASNs") previously issued to Legacy Applicant in the ARIN "WHOIS" database, inverse addressing on network blocks, maintenance of resource records, and administration of IP address space related to Included Number Resources issued prior to ARIN's inception on December 22, 1997 in its service area. IP address space and ASNs shall be defined as "number resources." " ... " If Legacy Applicant does not pay the Annual Legacy Maintenance Fee or other fees that may be owed ARIN hereunder, ARIN shall provide written notification to the Legacy Applicant approximately thirty (30) days following the date on which the payment is not made. If Legacy Applicant fails to make payment in response to the notice of delinquency, ARIN shall provide Legacy Applicant with an additional written notice, by certified or registered mail, return receipt requested, (as appropriate in each country), and, when possible, by e-mail and telephone. If the Legacy Applicant has not made payment within 12 months of the due date and/or ARIN is unable to contact the Legacy Applicant during those 12 months, ARIN has the right to: (i) stop providing Services, or (ii) terminate this Legacy Agreement and revoke the Included Number Resources." Or is this some other sort of "legacy" thing? From owen at delong.com Fri Oct 1 19:35:19 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 17:35:19 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <24405525.271.1285976366914.JavaMail.franck@linko-biatch-6.genius.local> References: <24405525.271.1285976366914.JavaMail.franck@linko-biatch-6.genius.local> Message-ID: I refer you to NRPM section 12 and the current draft policy 2010-11 Required Resource Reviews. Owen On Oct 1, 2010, at 4:39 PM, Franck Martin wrote: > A yearly challenge response for legacy space contacts, could be useful. I think there is a plan like this in some RIRs > > ----- Original Message ----- > From: "Owen DeLong" > To: "George Bonser" > Cc: nanog at nanog.org > Sent: Friday, 1 October, 2010 4:03:56 PM > Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time > > > On Oct 1, 2010, at 2:27 PM, George Bonser wrote: > >> >> >>> -----Original Message----- >>> From: Ricky Beam >>> Sent: Friday, October 01, 2010 1:00 PM >>> To: nanog at nanog.org >>> Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time >>> > > In the case of legacy space, it's actually very hard for ARIN to even > identify the status of the organization in question, let alone take > any sort of action with respect to said space. > > > > Owen > > From gbonser at seven.com Fri Oct 1 19:42:36 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 17:42:36 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: References: <7865.1285924930@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B09E@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0B7@RWC-EX1.corp.seven.com> > > They do, indeed, for space that is/was issued by ARIN. That space is > subject to annual fees and there is a clear and consistent method > for doing so. The bigger problem is with legacy space (most of the > space listed in the complaint we are discussing, if not all). > > In the case of legacy space, it's actually very hard for ARIN to even > identify the status of the organization in question, let alone take > any sort of action with respect to said space. Ok, I think I have a solution that is workable. A second database ... call it "whoisnt" ... of number resources and their points of contact that have not signed the legacy RSA and allow the community members to decide individually if they wish to continue to provide unfettered access from those resources. It might also provide maybe even some small amount of community pressure on the holders of those resources to place them under the legacy RSA. From gbonser at seven.com Fri Oct 1 19:52:22 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 17:52:22 -0700 Subject: AS11296 -- Hijacked? In-Reply-To: References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0B8@RWC-EX1.corp.seven.com> Try this one on for size: http://tinyurl.com/2aoqpmk Sent from my somethingorother. > -----Original Message----- > From: On Behalf Of William > Herrin > Sent: Friday, October 01, 2010 2:50 PM > To: George Bonser > Cc: nanog at nanog.org > Subject: Re: AS11296 -- Hijacked? > > Stuff about ip bullets or something ... From rfg at tristatelogic.com Fri Oct 1 20:15:02 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 01 Oct 2010 18:15:02 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <67EF8EE2-8B1E-45F9-892E-9E6B88ADB727@arin.net> Message-ID: <15691.1285982102@tristatelogic.com> In message <67EF8EE2-8B1E-45F9-892E-9E6B88ADB727 at arin.net>, John Curran wrote: >Resources being used by actual defunct organizations we will reclaim if >reported. Well, fortunately, Joytel and some of their fellow travelers have just recently gone 'round and identified a whole pantload of these for you: 24.230.0.0/19 NET-24-230-0-0-1 hijacked - empty 68.67.64.0/20 NET-68-67-64-0-1 legit -- GoRack, LLC (Jacksonville, FL) 192.100.5.0/24 NET-192-100-5-0-1 hijacked - empty 192.100.88.0/24 NET-192-100-88-0-1 hijacked - empty 192.100.134.0/24 NET-192-100-134-0-1 hijacked - empty 192.100.143.0/24 NET-192-100-143-0-1 hijacked - empty 192.101.177.0/24 NET-192-101-177-0-1 hijacked - empty 192.101.187.0/24 NET-192-101-187-0-1 hijacked - empty ... Do you want me to repost the whole list, or have you seen it already? Do I need to do something else to turn this into whatever qualifies at your place as a formal report? (Note: The whole list is too long to fit into the tiny little window you provide for fraud reporting on your web site. Should I print it all out as hardcopy and FedEx it to you in a shoebox?) Regards, rfg From rfg at tristatelogic.com Fri Oct 1 20:45:01 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 01 Oct 2010 18:45:01 -0700 Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B07A@RWC-EX1.corp.seven.com> Message-ID: <15866.1285983901@tristatelogic.com> In message <5A6D953473350C4B9995546AFE9939EE0A52B07A at RWC-EX1.corp.seven.com>, "George Bonser" wrote: >So ARIN is in the process of verifying their contacts database. >Organizations with an unreachable contact might be a good place to plant >a "dig here" sign. Fyi -- They (ARIN) already _are_ putting up ``dig here'' signs... in the POC records. Unfortunately, it would now appear that the folks doing the digging in those exact spots, are the hijackers, like Joytel. (Unless I'm mistaken, every last one of the blocks that Joytel grabbed had one of those little annotations on the associated POC record(s)). Talk about the Law of Unintended Conseqences! Oh well. It all comes out in the wash. Those POC annotations may perhaps have helped Joytel to identify easy takeover targets, but then they also helped _me_ to find the specific blocks that Joytel had jacked. On balance, I say it is better to have them than to not have them. Even if they might occasionally give those with sinister intent a small leg up. Regards, rfg P.S. I hope that everybody knows that the jerk behind Joytel also, apparently, tried to screw the taxpayers out of about $11+ million of ``stimulus'' money... undoubtedly for yet another useless make-work ``shovel ready'' project. http://jacksonville.bizjournals.com/jacksonville/stories/2009/11/30/story1.html# No word on whether he ever actually got his hoped-for $11.8 million payoff. Knowing how ga-ga the Obama administration is over anything that has the word ``broadband'' in it however, I wouldn't put it past them, and they probably did give this schmuck the cash. (They also really like the words ``young entrepreneur''. Sounds great to the unwashed masses in a press release.) If companies want to move here, they have a great labor force, great quality of life and affordable office space, said Mark Anthony Marques, Joytel president and CEO. What we lack is a good enough connection to the Internet infrastructure. The company expects to know by mid-December whether it will receive funding for the project, which has the support of key players including Mayor John Peyton, U.S. Sen. Bill Nelson and U.S. Reps. Corrine Brown and Ander Crenshaw. About 400 gigabytes of high-speed Internet capacity will be available to providers by mid-2010 if funding is received. That is enough capacity to transfer the entire contents of the Library of Congress within five minutes. ... or alternatively, to spam every person on the planet, twice, in under twenty minutes. From jcurran at arin.net Fri Oct 1 21:40:33 2010 From: jcurran at arin.net (John Curran) Date: Fri, 1 Oct 2010 22:40:33 -0400 Subject: ARIN Fraud Reporting Form ... (Resource listings yes, resource routing no) In-Reply-To: <15149.1285978107@tristatelogic.com> References: <15149.1285978107@tristatelogic.com> Message-ID: <4DB05053-FCD4-4459-B226-991435E90C65@arin.net> On Oct 1, 2010, at 8:08 PM, Ronald F. Guilmette wrote: > 1) You folks _are_ already (apparently) making some efforts... at least > as of this last summer, but perhaps also earlier... to ``validate'' (is > that the word you would use?) POC contacts. I know because I've lately > seen quite a number of your POC contact records (from the WHOIS data base) > that have a very helpful annotation attached to them, saying quite > directly and explicitly, that ARIN has been unable to verify or make > contact with this POC or that POC. So you are already passing judgement > on the validity and/or probable invalidity of things in your data base. Yes, we're attempting to validate contacts per the policy which the community set (ARIN Network Resource Policy Manual, section 3.6 - https://www.arin.net/policy/nrpm.html#three6) > And more, you are making your determinations public, via the data base > itself. I'm not quite sure how it constitutes such a big leap to merely > extend what you are already doing in the way of validating POCs and just > impute the exact same level of confidence, or lack thereof, to IP block > and/or AS records which are associated with unverifiable/uncontactable > POCs... a set which you are already making serious efforts to delineate > anyway. We will shortly be providing a "list of number resources with no valid POC" for those who desire it (per the current bulk Whois policy.) > If you can put an annotation into a whois records for a POC, > saying explicity that you can't get ahold of this person, then it would > seem to me to be a rather trivial matter of programming to transplant > a very similar sort of annotation into each and every IP block or AS > record that has that same specific POC record as one of its associated > POC records, either Admin, or Technical, or whatever. Also a nice idea, and one that I've taken as a formal suggestion for improvement. > ... > > 2) You are already (apparently) processing _some_ certain flavors of > ``fraud reports'' that come in to you via that nice fancy web form you > folks built and put up on the ARIN web site... you know... the one with > the nice (and misleading) introduction that entices people like me to > take the time to use it enter reports about incidents that have traditionally > been called around these parts ``hijacking''. > > (Note: That's the word that _you_ used on your web site to say what > should be reported via the form. Was I a fool to take you at your word? > Let me be clear... I am *not* *not* *not* encouraging you to simply > redact/delete that word from your web site. No no! Rather I hope to > encourage you/ARIN to actually accept and at least investigate reports > of _all_ flavors of what we around here used to call good old fashioned > ``hijacking'', regardless of whether the perp was gracious enough to > also make your choice clearer by dicking with the relevant WHOIS records > or not.) Your understanding of our fraud process is correct, and presently the only form of "hijacking" which we have the ability to correct is address blocks where the organization have been changed contrary to policy. To address your follow-on question, our determinations are indeed definitive and we correct the WHOIS database accordingly. > I think you can see where I'm going with this. You have, I think, tried to > demur (is that the right word?) on ARIN's behalf, from _either_ investigating > or, subsequently, from issuing any kind of ``determination'' as regards to > whether a given block is being routed by the party or parties who ought to > be routing it, or by some uninvited interloper. Incorrect. We determine whether an entry for an address block in WHOIS has been changed contrary to community-adopted policy. This means carefully reviewing the information supplied on the associated change requests and various corresponding public records. *None of it related to whether a given party should be routing a given address block* > ... > So no, please *do not* go around ``revoking resources''... whatever the hell > that means. Certainly, if some half-dead, left-for-dead dot-bomb company > has a /18, and if your records still say that they have a /18, then they still > have a /18. Period. And if then, some hijacker punk criminal comes along > and starts routing that /18... well... he's a shmuck, and ought to be dealt > with. But the old Dot-Bomb semi-defunct company still does ``own'' (please > excuse my use of that terminology, which I'm sure you won't approve) that > block. So you shouldn't be ``revoking'' anything. That's not what any of > this is about. Semi-defunct firms may hold address blocks, but address blocks assigned to fully defunct organizations are returned to the free pool per community policy. > All I want from ARIN, and all I expect from ARIN, in cases like these are > (a) at least some willingness and effort expended to investigate and (2) > at least *some sort* of (perhaps minimalist) public statement to the effect > of ``Look folks, we've looked at this, and in our opinion, what's going on > here just doesn't look kosher.'' The good news is that if you're referring to investigation of errant entries in WHOIS, we currently do expend effort to investigate and correct. In order for ARIN to investigate and annotate address blocks according to their state in the routing tables, it would take a very clear mandate from the community. You can suggest such a policy if you feel strongly about this; the process to to so is shown here: https://www.arin.net/policy/pdp_appendix_b.html /John John Curran President and CEO ARIN From gbonser at seven.com Fri Oct 1 22:20:35 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 1 Oct 2010 20:20:35 -0700 Subject: ARIN Fraud Reporting Form ... (Resource listings yes, resourcerouting no) In-Reply-To: <4DB05053-FCD4-4459-B226-991435E90C65@arin.net> References: <15149.1285978107@tristatelogic.com> <4DB05053-FCD4-4459-B226-991435E90C65@arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0C0@RWC-EX1.corp.seven.com> > We will shortly be providing a "list of number resources with no valid > POC" > for those who desire it (per the current bulk Whois policy.) > > > If you can put an annotation into a whois records for a POC, > > saying explicity that you can't get ahold of this person, then it > would > > seem to me to be a rather trivial matter of programming to transplant > > a very similar sort of annotation into each and every IP block or AS > > record that has that same specific POC record as one of its > associated > > POC records, either Admin, or Technical, or whatever. > > Also a nice idea, and one that I've taken as a formal suggestion for > improvement. > Those two things would be enough for me for the numbers covered by agreement, the legacy issue is a tougher nut. There should be some sort of requirement that any network being announced have a valid point of contact. Whose jurisdiction that would fall under for a global Internet beats me. From rfg at tristatelogic.com Sat Oct 2 00:26:32 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 01 Oct 2010 22:26:32 -0700 Subject: ARIN Fraud Reporting Form ... (Resource listings yes, resource routing no) In-Reply-To: <4DB05053-FCD4-4459-B226-991435E90C65@arin.net> Message-ID: <17104.1285997192@tristatelogic.com> John, Let me thank you yet again for devoting your personal time (on a Friday night no less) to responding to me concerns. I may not always agree with you, but I appreciate the effort, and the consideration. In message <4DB05053-FCD4-4459-B226-991435E90C65 at arin.net>, John Curran wrote: >We will shortly be providing a "list of number resources with no valid POC" >for those who desire it (per the current bulk Whois policy.) But I think you understand that I was suggesting something that's readily accessible, even to the Great Unwashed Masses, within the individual WHOIS records... not exclusive to just your ordained bulk whois clientel. You did get that, right? >> If you can put an annotation into a whois records for a POC, >> saying explicity that you can't get ahold of this person, then it would >> seem to me to be a rather trivial matter of programming to transplant >> a very similar sort of annotation into each and every IP block or AS >> record that has that same specific POC record as one of its associated >> POC records, either Admin, or Technical, or whatever. > >Also a nice idea, and one that I've taken as a formal suggestion for >improvement. Thank you. >Your understanding of our fraud process is correct, and presently the only >form of "hijacking" which we have the ability to correct... Well, now, as Ronald Regan used to say ``There you go again!'' I've tried to be clear. I'll try again. Many many many people have told me, off-list, and even before this conver- sation, that you folks can't change the routing table, and that even if you could, most probably would never want you to exercise that authority. So I do fully understand where the weight of public opinion falls along that particular axis. Believe me, I do. But please do try to understand me. I was not asking you to ``correct'' any hijacking incident. You can't. So let's just agree on that, and also agree that that is not what we are even talking about. What I said was ``annotate'' and/or ``announce'' and/or ``make _some_ sort of public statement or comment''. This, I think, would not be straying so substantially outside of your charter than anybody would ever beat you up over it, especially if you folks exercised the kind of caution and careful investigation which I believe you are more than capable of, and if you thence only made public ``This is really fishy looking'' type comments when your internal investigations have shown that yes, indeed, this one really looks, smells, and tastes pretty darn awful. (And frankly, I think this would apply to all four of the cases I have written about here recently.) So have I been unambiguously clear now? I neither want nor expect you to ``correct'' anything. That sort of thing, I would agree, is not your job. But I don't think that fact implies that either you personally, or ARIN as an organization have any kind of formal responsibility to behave as blind deaf mutes with no opinions whatsoever, at any time, about anything. Some people would tell you that its a free country, and that you have a right to an opinion. I guess what I'm saying is that when it comes to ARIN, and allegations of hijacking of number resources that you have been chartered to administer, you have not merely a right, but actually a _responsibility_ to an opinion. And you should formulate it, and state it, publically, when the need arises, which is to say whenever you receive a credible allegation of the misappropriation of number resources that lie within your portfolio. >> I think you can see where I'm going with this. You have, I think, tried to >> demur (is that the right word?) on ARIN's behalf, from _either_ investigating >> or, subsequently, from issuing any kind of ``determination'' as regards to >> whether a given block is being routed by the party or parties who ought to >> be routing it, or by some uninvited interloper. > >Incorrect. We determine whether an entry for an address block in WHOIS has >been changed contrary to community-adopted policy. This means carefully >reviewing the information supplied on the associated change requests and >various corresponding public records. *None of it related to whether a >given party should be routing a given address block* Right. You may perhaps not have realized it, but I do believe that you actually just _agreed_ completely with what I said just above. At present, you decline to even look at things that don't involve the fiddling of WHOIS records. Somebody could be murdered in the next room, and you would decline to investigate that too, because the community hasn't explicitly chartered you to do that. I understand your position, and I think I may even understand what motivates it... like maybe years and years of having your own constituency beat you about the head and neck whenever you try to do even the smallest, kindest, and most generous and well-meaning things if they... the herd of cats... haven't explicity approved of you doing it, themselves, in writing, and in triplicate. But to say I understand your position, and to say that I can even under- stand what I believe motivates it, is not to say that I agree with it. I don't in this case. I think you are perhaps not in quite such a tightly fitting straight-jacket... created for you by your primary constiuency, the ISPs... as you make out, and that you do actually have some freedom to Do The Right Thing, especially in cases like these blatant hijacking incidents. But I also believe that you have made a private personal and concious decision not to touch any of this with a ten foot pole, because years of surviving in the kind of highly politically contentious job you have has taught you to never stick your neck out, even a little bit, even for an unambiguously good cause, unless what you plan to do or say (or what you plan to eat for lunch, or when you plan to breath) has already been approved, in triplicate, by the whole of the ARIN membership. I'm quite sure that that is the only practical and viable way to survive, long term, in a highly political job like your's. However I am equally sure that it is unhealthy for any human being to live in a straight-jacket for years at time, with no let-up. So despite you protestations to the contrary, I will say again that I think you have not only a right, but a responsibility to express an opinion on matters critically affecting the number resources that you are tasked to shepard... matters such as blatant hijacking of those resources by crooks... and that the same goes for ARIN, as an organization, and that furthermore, you do a disservice to the community, to your office, and yes, even to yourself as an intelligent, concious, living, growing human being when you hold your tongue on important matters simply because you have not been officially and formally bidden to speak. And you _don't_ always do that, consistantly and always, anyway. In fact right now, within this very exchange you and I have been having, you have expressed yourself in ways that, I feel sure, were not explicitly or specifically sanctioned by your board or your membership, yes? But you have shown yourself to be fully fit and able to express these opinions of your's anyway, as part of your reasonable exercise of your executive discretion, in your pursuit of what you believe to be the community's best interests. That is correct, isn't it? That's why you are here, arguing with me on a Friday evening, when we both should probably be doing something else. You are expressing your opinion, about certain matters relating to your job, and you are doing so in ways that you feel are supportive of the community which you serve... not with every sylable you utter having to have been be pre-approved... not with your corporate counsel looking over your shoulder at every keystroke. You're a bright guy, and a leader among men. You have an opinion, and you are expressing it, for the good of the community. Marvlous! I say Bravo! Just please explain to me how you taking a public position here, tonite, in this conversation with me... a position which you take and speak about and defend as part of your executive discretion, as the leader of ARIN, in what you hope will be its best interests and those of the community... is really all that different from what _I_ have requested you to do? i.e. take a position... a public position... on matters affecting your job and the resources you oversee, in the best interests of the community. I think you get my drift, because it isn't really all that subtle a point I am making. I don't think that you can have it both ways. I don't think that you can express your opinions, forcefully and eloquently, here with me, on a Friday night... as I believe you are free to do, within the limits of your executive discretion... but then go in to work on Monday morning and claim that you have been obliged to check all of your opinions at the door on the way in, and that both your and your organization are likewise obliged by protocol to remain utterly mute until cocktail hour, when you are off the clock and on your own time, even when it comes to matters as serious as raw blatant theft and hijacking... acts which deface and besmirch the very community you are sworn to protect. (Well, ok. Please _do_ allow me just a tiny bit of literary license, alright? They have Richard III on the IFC channel just now, and Shakespere in my general vicinity always makes my prose rather prolix.) Sigh. I feel sure that I haven't convinced you to bite off even just this tiny additional bit of authority/responsibility and stake it out as part of the turf that goes quite naturally with your executive discretion... discretion which you must be afforded, like it or not, by your constituency, in order for you to do your job. I'm sure that you have thought too long and too hard about your job, and what it takes to survive in it, long term, to be beguiled at this point by even the most evocative of retorical flourishes. But I will count myself as having been successful if I have at least caused you to think a bit more... not about what freedom you have to ``do'', but about what freedom I believe you have to speak, and to speak and express opinions in ways that benefit the community far more than your silence would (or does). >>``Look folks, we've looked at this, and in our opinion, what's going on >> here just doesn't look kosher.'' > >The good news is that if you're referring to investigation of errant entries >in WHOIS, we currently do expend effort to investigate and correct. In order >for ARIN to investigate and annotate address blocks according to their state in the routing tables, it would take a very clear mandate from the community. So you have said. So you have repeated. I am still not buying that you are nearly as handcuffed as you say you are, because if nothing else, you would have found it impossible to type this e-mail that I am responding to if you had actually been wearing the kinds of handcuffs you claim, i.e. ones which prevent you from even just expressing opinions on important and relevant matters. >You can suggest such a policy if you feel strongly about this; the process to >to so is shown here: https://www.arin.net/policy/pdp_appendix_b.html Thank you. I may perhaps do so. But I am not at all heartened to believe that doing so would be likely to have any effect, given that you have not evinced even the slightest hint, during this exchange of any actual desire to have your portfolio enhanced in this specific way. (And I think that your vote would, quite rightly, outweigh any others when it comes to such questions, i.e. those affecting the scope of your authority and responsibility.) In short, I leave discouraged, but unbowed. At least I know who _not_ to expend time reporting certain very naughty things to now, and I guess that is a small step forward, as it will save me some time which I can better spend actually chasing more of these hijacking weasles to ground. Regards, rfg From owen at delong.com Sat Oct 2 00:57:16 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 1 Oct 2010 22:57:16 -0700 Subject: ARIN Fraud Reporting Form ... (Resource listings yes, resourcerouting no) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B0C0@RWC-EX1.corp.seven.com> References: <15149.1285978107@tristatelogic.com> <4DB05053-FCD4-4459-B226-991435E90C65@arin.net> <5A6D953473350C4B9995546AFE9939EE0A52B0C0@RWC-EX1.corp.seven.com> Message-ID: <74CCA03E-5121-41E0-8A2D-87A0EA9B9DAB@delong.com> On Oct 1, 2010, at 8:20 PM, George Bonser wrote: > > >> We will shortly be providing a "list of number resources with no valid >> POC" >> for those who desire it (per the current bulk Whois policy.) >> >>> If you can put an annotation into a whois records for a POC, >>> saying explicity that you can't get ahold of this person, then it >> would >>> seem to me to be a rather trivial matter of programming to > transplant >>> a very similar sort of annotation into each and every IP block or AS >>> record that has that same specific POC record as one of its >> associated >>> POC records, either Admin, or Technical, or whatever. >> >> Also a nice idea, and one that I've taken as a formal suggestion for >> improvement. >> > > Those two things would be enough for me for the numbers covered by > agreement, the legacy issue is a tougher nut. There should be some sort > of requirement that any network being announced have a valid point of > contact. Whose jurisdiction that would fall under for a global Internet > beats me. > > It's an individual decision of each organization choosing to accept and further pass along the route. Like it or not, there is not "THE INTERNET" there is a set of independent networks operating under a commonly agreed framework of protocols. Each network operator is free to accept, deny, or otherwise handle any traffic they wish on any basis they choose. This is the greatest strength of the internet. It is also it's most exploitable weakness in some ways. However, changing it would fundamentally destroy much of it's usefulness and resilience as a tool for the democratization of communication. As such, I must oppose any such move to apply greater central authority. Owen From goemon at anime.net Sat Oct 2 01:13:58 2010 From: goemon at anime.net (goemon at anime.net) Date: Fri, 1 Oct 2010 23:13:58 -0700 (PDT) Subject: ARIN Fraud Reporting Form ... Don't waste your time In-Reply-To: <24405525.271.1285976366914.JavaMail.franck@linko-biatch-6.genius.local> References: <24405525.271.1285976366914.JavaMail.franck@linko-biatch-6.genius.local> Message-ID: Yearly? I say every 30 days. mailing lists do the c-r every 30 days. surely correct arin registration data is more important than a single email address on a mailing list. -Dan On Fri, 1 Oct 2010, Franck Martin wrote: > A yearly challenge response for legacy space contacts, could be useful. I think there is a plan like this in some RIRs > > ----- Original Message ----- > From: "Owen DeLong" > To: "George Bonser" > Cc: nanog at nanog.org > Sent: Friday, 1 October, 2010 4:03:56 PM > Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time > > > On Oct 1, 2010, at 2:27 PM, George Bonser wrote: > >> >> >>> -----Original Message----- >>> From: Ricky Beam >>> Sent: Friday, October 01, 2010 1:00 PM >>> To: nanog at nanog.org >>> Subject: Re: ARIN Fraud Reporting Form ... Don't waste your time >>> > > In the case of legacy space, it's actually very hard for ARIN to even > identify the status of the organization in question, let alone take > any sort of action with respect to said space. > > > > Owen > > > From imranmoin at gmail.com Sat Oct 2 02:17:06 2010 From: imranmoin at gmail.com (Imran Moin) Date: Sat, 2 Oct 2010 00:17:06 -0700 Subject: ARIN IP/AS Assignment Message-ID: Hello All, I was wondering how long it is taking ARIN these days to assign new IP block and AS Number. We are a new startup and looking to build our network over the next few months. Thanks, Imran. From Rod.Beck at hiberniaatlantic.com Sat Oct 2 04:52:40 2010 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Sat, 2 Oct 2010 10:52:40 +0100 Subject: A New TransAtlantic Cable System References: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB039584B8@bert.HiberniaAtlantic.local> Is that a straight line calculation or did you take into account that a straight line is not the shortest path on a curved surface? -----Original Message----- From: dorn at hetzel.org on behalf of Dorn Hetzel Sent: Fri 10/1/2010 3:11 PM To: Heath Jones Cc: Rod Beck; nanog at nanog.org Subject: Re: A New TransAtlantic Cable System Yeah, I wonder when we're gonna see cable that's pumped down to a vacuum in the center? :) On Fri, Oct 1, 2010 at 10:01 AM, Heath Jones wrote: > > > http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html?x=0&.v=1 > > Roderick S. Beck > > Director of European Sales > > Hibernia Atlantic > > Sales spam - but still - very close to minimum possible latency! > 3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip = 55.9ms. > > From hj1980 at gmail.com Sat Oct 2 05:17:04 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sat, 2 Oct 2010 11:17:04 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB039584B8@bert.HiberniaAtlantic.local> References: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> <1E8B940C5E21014AB8BE70B975D40EDB039584B8@bert.HiberniaAtlantic.local> Message-ID: On 2 October 2010 10:52, Rod Beck wrote: > Is that a straight line calculation or did you take into account that a > straight line is not the shortest path on a curved surface? Well that is pretty obvious to most, but no - I didn't go to the effort of factoring in curvature of the earth - especially given that 1.5 is very rough figure anyway for RI of glass. If anything, my comment was compliment to your network being close to minimum possible latency! From bclark at spectraaccess.com Sat Oct 2 05:19:32 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Sat, 02 Oct 2010 06:19:32 -0400 Subject: ARIN IP/AS Assignment In-Reply-To: References: Message-ID: <4CA70734.70001@spectraaccess.com> We just had to get another new block, took about 5 days. On 10/02/2010 03:17 AM, Imran Moin wrote: > Hello All, > > I was wondering how long it is taking ARIN these days to assign new IP block > and AS Number. We are a new startup and looking to build our network over > the next few months. > > Thanks, > Imran. > From hj1980 at gmail.com Sat Oct 2 05:20:53 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sat, 2 Oct 2010 11:20:53 +0100 Subject: ARIN IP/AS Assignment In-Reply-To: References: Message-ID: On 2 October 2010 08:17, Imran Moin wrote: > Hello All, > > I was wondering how long it is taking ARIN these days to assign new IP block > and AS Number. We are a new startup and looking to build our network over > the next few months. I think they are a bit preoccupied at the moment... ;) ps. I'm not really sure of their timescales.. From joelja at bogus.com Sat Oct 2 07:21:01 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 2 Oct 2010 05:21:01 -0700 Subject: ARIN IP/AS Assignment In-Reply-To: <4CA70734.70001@spectraaccess.com> References: <4CA70734.70001@spectraaccess.com> Message-ID: <12C072EC-3D34-4320-B19A-7E4795A0C345@bogus.com> The longest part of our 2009 prefix assignment was getting our accounts payable system to handle the additional supplier. If you have all of you documentation in order you can easily run through the process in two weeks. Joel's widget number 2 On Oct 2, 2010, at 3:19, Bret Clark wrote: > We just had to get another new block, took about 5 days. > > On 10/02/2010 03:17 AM, Imran Moin wrote: >> Hello All, >> >> I was wondering how long it is taking ARIN these days to assign new IP block >> and AS Number. We are a new startup and looking to build our network over >> the next few months. >> >> Thanks, >> Imran. >> > > From bill at herrin.us Sat Oct 2 08:28:47 2010 From: bill at herrin.us (William Herrin) Date: Sat, 2 Oct 2010 09:28:47 -0400 Subject: ARIN IP/AS Assignment In-Reply-To: References: Message-ID: On Sat, Oct 2, 2010 at 3:17 AM, Imran Moin wrote: > I was wondering how long it is taking ARIN these days to assign new IP block > and AS Number. We are a new startup and looking to build our network over > the next few months. Imran, The last few times I ran through the process, the hardest part was getting ARIN to accept the ORG registration.One time we'd let the state business registration expire by mistake. And the state registration name didn't exactly match the business name. ARIN's much more rigid about that sort of thing than any other supplier you'll ever deal with. Separately, I had all kinds of fun registering myself as an organization so I could get an AS number to route my legacy /23. ARIN asked for proof of the organization's legal existence so I faxed them a copy of my driver's license. On the plus side, you don't have to have your network plans done to start the org registration. So start it early. Getting addresses after that was relatively straightforward. I did find it useful to have a friendly eye from one of my upstreams look over the request document and make suggestions. Say things the right way the first time so you don't raise any red flags and you tend to get what you ask for. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From meekjt at gmail.com Sat Oct 2 09:31:33 2010 From: meekjt at gmail.com (Jon Meek) Date: Sat, 2 Oct 2010 10:31:33 -0400 Subject: A New TransAtlantic Cable System In-Reply-To: References: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> <1E8B940C5E21014AB8BE70B975D40EDB039584B8@bert.HiberniaAtlantic.local> Message-ID: One of the ways that I have tormented WAN vendors over the years is with a plot of RTT vs. great circle distance between the end points of a circuit. Most RTTs usually sit at some constant offset above that Physics limit straight line. Circuits taking a less than ideal have their RTT far above the Physics limit line and we have used that information to get routes fixed. Using my great circle program that accounts for the non-spherical Earth for locations we have West of London and North of NYC, assuming a 1.5 index of refraction I get: One way distance: 5520.6 km Round Trip Delay: 55.2 ms So Heath's estimate is right on, although depending on where he got the distance maybe it does account for the shape of the Earth. Jon On Sat, Oct 2, 2010 at 6:17 AM, Heath Jones wrote: > On 2 October 2010 10:52, Rod Beck wrote: >> Is that a straight line calculation or did you take into account that a >> straight line is not the shortest path on a curved surface? > > Well that is pretty obvious to most, but no - I didn't go to the > effort of factoring in curvature of the earth - especially given that > 1.5 is very rough figure anyway for RI of glass. If anything, my > comment was compliment to your network being close to minimum possible > latency! > > From bruns at 2mbit.com Sat Oct 2 11:32:22 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 02 Oct 2010 10:32:22 -0600 Subject: ARIN IP/AS Assignment In-Reply-To: References: Message-ID: <4CA75E96.4070800@2mbit.com> On 10/2/10 1:17 AM, Imran Moin wrote: > Hello All, > > I was wondering how long it is taking ARIN these days to assign new IP block > and AS Number. We are a new startup and looking to build our network over > the next few months. > It took only a few days to be assigned our AS number, but that was after hair pulling, head banging on desk, and i-want-to-drink-every-night-after-work for a week or two while we figured out how to work around the circular "You need to have two upstreams first before we will assign an AS" rule but providers can't/won't peer with you without one in the first place reality. I wish you luck :) -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From gbonser at seven.com Sat Oct 2 11:56:42 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 2 Oct 2010 09:56:42 -0700 Subject: ARIN Fraud Reporting Form ... (Resource listings yes, resourcerouting no) In-Reply-To: <74CCA03E-5121-41E0-8A2D-87A0EA9B9DAB@delong.com> References: <15149.1285978107@tristatelogic.com> <4DB05053-FCD4-4459-B226-991435E90C65@arin.net> <5A6D953473350C4B9995546AFE9939EE0A52B0C0@RWC-EX1.corp.seven.com> <74CCA03E-5121-41E0-8A2D-87A0EA9B9DAB@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0C2@RWC-EX1.corp.seven.com> > > It's an individual decision of each organization choosing to accept and > further pass along the route. > > Like it or not, there is not "THE INTERNET" there is a set of > independent > networks operating under a commonly agreed framework of protocols. > Each network operator is free to accept, deny, or otherwise handle > any traffic they wish on any basis they choose. > > This is the greatest strength of the internet. It is also it's most > exploitable > weakness in some ways. However, changing it would fundamentally > destroy much of it's usefulness and resilience as a tool for the > democratization of communication. As such, I must oppose any > such move to apply greater central authority. > > Owen Of course, and I absolutely agree with that so long as the individual operators have the information they need to make those individual decisions. And that is the goal. Having information as to which resource have no valid points of contact and what other resources are associated with that invalid POC might be useful to some when some traffic crosses their net or reaches their other resources that causes problems. From jlewis at lewis.org Sat Oct 2 11:59:04 2010 From: jlewis at lewis.org (Jon Lewis) Date: Sat, 2 Oct 2010 12:59:04 -0400 (EDT) Subject: ARIN IP/AS Assignment In-Reply-To: <4CA75E96.4070800@2mbit.com> References: <4CA75E96.4070800@2mbit.com> Message-ID: On Sat, 2 Oct 2010, Brielle Bruns wrote: > It took only a few days to be assigned our AS number, but that was after hair > pulling, head banging on desk, and i-want-to-drink-every-night-after-work for > a week or two while we figured out how to work around the circular "You need > to have two upstreams first before we will assign an AS" rule but providers > can't/won't peer with you without one in the first place reality. It's been a while since I've applied for an ASN...but used to be you just put on the form that you've ordered connectivity from multiple providers with the intent of multihoming, and that was good enough for ARIN. If that's no longer good enough, I would think any understanding provider would let you setup the peering connection first, assign it a /30, and then wait for you to get your ASN to do the BGP part. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From owen at delong.com Sat Oct 2 12:22:58 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 2 Oct 2010 10:22:58 -0700 Subject: ARIN IP/AS Assignment In-Reply-To: <4CA75E96.4070800@2mbit.com> References: <4CA75E96.4070800@2mbit.com> Message-ID: Usually this is easily solved with letters of intent to peer upon AS issuance from the two providers. Most providers will do this for you fairly easily. Owen On Oct 2, 2010, at 9:32 AM, Brielle Bruns wrote: > On 10/2/10 1:17 AM, Imran Moin wrote: >> Hello All, >> >> I was wondering how long it is taking ARIN these days to assign new IP block >> and AS Number. We are a new startup and looking to build our network over >> the next few months. >> > > It took only a few days to be assigned our AS number, but that was after hair pulling, head banging on desk, and i-want-to-drink-every-night-after-work for a week or two while we figured out how to work around the circular "You need to have two upstreams first before we will assign an AS" rule but providers can't/won't peer with you without one in the first place reality. > > I wish you luck :) > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org From jeffrey.lyon at blacklotus.net Sat Oct 2 12:35:24 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 2 Oct 2010 22:05:24 +0430 Subject: ARIN IP/AS Assignment In-Reply-To: References: <4CA75E96.4070800@2mbit.com> Message-ID: We received our ASN in 2004 with a justification of "intend to multihome." Jeff On Sat, Oct 2, 2010 at 9:29 PM, Jon Lewis wrote: > On Sat, 2 Oct 2010, Brielle Bruns wrote: > >> It took only a few days to be assigned our AS number, but that was after >> hair pulling, head banging on desk, and >> i-want-to-drink-every-night-after-work for a week or two while we figured >> out how to work around the circular "You need to have two upstreams first >> before we will assign an AS" rule but providers can't/won't peer with you >> without one in the first place reality. > > It's been a while since I've applied for an ASN...but used to be you just > put on the form that you've ordered connectivity from multiple providers > with the intent of multihoming, and that was good enough for ARIN. ?If > that's no longer good enough, I would think any understanding provider would > let you setup the peering connection first, assign it a /30, and then wait > for you to get your ASN to do the BGP part. > > ---------------------------------------------------------------------- > ?Jon Lewis, MCP :) ? ? ? ? ? | ?I route > ?Senior Network Engineer ? ? | ?therefore you are > ?Atlantic Net ? ? ? ? ? ? ? ?| > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > -- 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 sra at isc.org Sat Oct 2 13:03:27 2010 From: sra at isc.org (Rob Austein) Date: Sat, 02 Oct 2010 14:03:27 -0400 Subject: Active Directory requires Microsoft DNS? In-Reply-To: <20100924174508.GQ31091@macbook.catpipe.net> References: <4C9CDD1C.5090609@bitfreak.org> <20100924174508.GQ31091@macbook.catpipe.net> Message-ID: <20101002180327.2F33B22829@thrintun.hactrn.net> At Fri, 24 Sep 2010 19:45:09 +0200, Phil Regnauld wrote: > > What about dynamic updates of the client ? It's usually not > a problem in this direction (Windows client -> BIND DNS), but as you > say it won't be secure (GSS-TSIG). Recent versions of BIND 9 include GSS-TSIG support. It's harder to use than it should be, partly due to lack of documentation (mea culpa), and has some limitations, but does work for the basic task of letting clients (Windows or otherwise) in an Active Directory environment perform DDNS updates using GSS-TSIG authentication. See https://lists.isc.org/pipermail/bind-users/ for recent discussion. From jcurran at arin.net Sat Oct 2 13:26:35 2010 From: jcurran at arin.net (John Curran) Date: Sat, 2 Oct 2010 14:26:35 -0400 Subject: ARIN IP/AS Assignment In-Reply-To: References: Message-ID: <4F078798-D290-4940-AEC3-5D9BB9856202@arin.net> On Oct 2, 2010, at 9:28 AM, William Herrin wrote: > The last few times I ran through the process, the hardest part was > getting ARIN to accept the ORG registration.One time we'd let the > state business registration expire by mistake. And the state > registration name didn't exactly match the business name. ARIN's much > more rigid about that sort of thing than any other supplier you'll > ever deal with. The compliment is received and appreciated. :-) /John From kris.foster at gmail.com Sat Oct 2 13:28:02 2010 From: kris.foster at gmail.com (kris foster) Date: Sat, 2 Oct 2010 11:28:02 -0700 Subject: A New TransAtlantic Cable System In-Reply-To: References: <1E8B940C5E21014AB8BE70B975D40EDB039584B7@bert.HiberniaAtlantic.local> <1E8B940C5E21014AB8BE70B975D40EDB039584B8@bert.HiberniaAtlantic.local> Message-ID: http://www.gcmap.com/mapui?P=lga-lhr -- kris On Oct 2, 2010, at 7:31 AM, Jon Meek wrote: > One of the ways that I have tormented WAN vendors over the years is > with a plot of RTT vs. great circle distance between the end points of > a circuit. Most RTTs usually sit at some constant offset above that > Physics limit straight line. Circuits taking a less than ideal have > their RTT far above the Physics limit line and we have used that > information to get routes fixed. > > Using my great circle program that accounts for the non-spherical > Earth for locations we have West of London and North of NYC, assuming > a 1.5 index of refraction I get: > > One way distance: 5520.6 km Round Trip Delay: 55.2 ms > > So Heath's estimate is right on, although depending on where he got > the distance maybe it does account for the shape of the Earth. > > Jon > > On Sat, Oct 2, 2010 at 6:17 AM, Heath Jones wrote: >> On 2 October 2010 10:52, Rod Beck wrote: >>> Is that a straight line calculation or did you take into account that a >>> straight line is not the shortest path on a curved surface? >> >> Well that is pretty obvious to most, but no - I didn't go to the >> effort of factoring in curvature of the earth - especially given that >> 1.5 is very rough figure anyway for RI of glass. If anything, my >> comment was compliment to your network being close to minimum possible >> latency! >> >> > From bonomi at mail.r-bonomi.com Sat Oct 2 15:03:52 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Sat, 2 Oct 2010 15:03:52 -0500 (CDT) Subject: AS11296 -- Hijacked? Message-ID: <201010022003.o92K3qSa029992@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Fri Oct 1 16:33:09 2010 > From: John Curran > To: George Bonser > Date: Fri, 1 Oct 2010 17:32:47 -0400 > Subject: Re: AS11296 -- Hijacked? > Cc: "nanog at nanog.org" > > George - > Full agreement; the next step is defining a deterministic process for id= > entifying these specific resources which are hijacked, That _seems_ fairly simple -- can you trace a 'continuity of ownership from the party that they were -originally- allocatd to to the party presently using them. If yes, legiitmate, if no, hijacked. With most States corporation records on-line, tracing corporate continuity is fairly straight foruard. As long as you recognize that a corpoation 'abadoned', 'dissolved' (or similar) in one state is *NOT* the 'parent' of a same-/similarly-named corporation established in another state. And that "documents" surfacing 'long after' a resource-holder has 'disappeared', puporting to show a transfer of those resources 'at the time of disappearance', are "highly suspect", and really require confirmation from someone who can be -independantly- verified as part of the 'old' organization at the time of the transfer. This isn't rocket science, it's straightforward corporate forensics, and the establishment of "provenence", or the equivalent of an 'abstract of title' for real-estate. "Somebody", either IANA, or the RIRs _should_ have been keeping track of what prefixes are announced, and _by_whom_, as a minimal check on utilization when an existing AS submits a request for additional space. A netblock (meaing an entire allocation, not just some sub-set thereof) that's been 'missing' for an extended period, and then shows up in an geographically distant locale is 'suspicious' to start with. All the more so it it was multi-homed, and now has only a single upstream. From jcurran at arin.net Sat Oct 2 15:41:00 2010 From: jcurran at arin.net (John Curran) Date: Sat, 2 Oct 2010 16:41:00 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <201010022003.o92K3qSa029992@mail.r-bonomi.com> References: <201010022003.o92K3qSa029992@mail.r-bonomi.com> Message-ID: <54ED4B73-B9D9-4922-8A67-C3D37318DA55@arin.net> On Oct 2, 2010, at 4:03 PM, Robert Bonomi wrote: > That _seems_ fairly simple -- can you trace a 'continuity of ownership from > the party that they were -originally- allocatd to to the party presently using > them. If yes, legiitmate, if no, hijacked. With most States corporation > records on-line, tracing corporate continuity is fairly straight foruard. > As long as you recognize that a corpoation 'abadoned', 'dissolved' (or > similar) in one state is *NOT* the 'parent' of a same-/similarly-named > corporation established in another state. And that "documents" surfacing > 'long after' a resource-holder has 'disappeared', puporting to show a transfer > of those resources 'at the time of disappearance', are "highly suspect", and > really require confirmation from someone who can be -independantly- verified > as part of the 'old' organization at the time of the transfer. Robert - You are matching nearly verbatim from ARIN's actual procedures for recognizing a transfer via merger or acquisition. The problem is compounded because often the parties appear years later, don't have access to the legal documentation of the merger, and there is no "corporate" surviving entity to contact. Many parties abandon these transfers mid-process, leaving us to wonder whether they were exactly as claimed but simply lacking needed documentation, or whether they were optimistic attempts to hijack. /John John Curran President and CEO ARIN From bill at herrin.us Sat Oct 2 15:46:49 2010 From: bill at herrin.us (William Herrin) Date: Sat, 2 Oct 2010 16:46:49 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <201010022003.o92K3qSa029992@mail.r-bonomi.com> References: <201010022003.o92K3qSa029992@mail.r-bonomi.com> Message-ID: On Sat, Oct 2, 2010 at 4:03 PM, Robert Bonomi wrote: > That _seems_ fairly simple [...] it's straightforward corporate > forensics, and the establishment of "provenence", or the > equivalent of an 'abstract of title' for real-estate. Hi Robert, It may seem simple but it only seems that way. The legacy registrants (pre-arin registrants) in particular were not necessarily legal entities. Like trademarks with a TM instead of a Circle-R, they were nothing more than unverified names asserted by the individuals requesting IP addresses. In some cases they were obviously corporations but in many others there are only ambiguous forensics to examine. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From bruns at 2mbit.com Sat Oct 2 16:17:26 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 02 Oct 2010 15:17:26 -0600 Subject: ARIN IP/AS Assignment In-Reply-To: References: <4CA75E96.4070800@2mbit.com> Message-ID: <4CA7A166.8030001@2mbit.com> On 10/2/10 10:59 AM, Jon Lewis wrote: > On Sat, 2 Oct 2010, Brielle Bruns wrote: > >> It took only a few days to be assigned our AS number, but that was >> after hair pulling, head banging on desk, and >> i-want-to-drink-every-night-after-work for a week or two while we >> figured out how to work around the circular "You need to have two >> upstreams first before we will assign an AS" rule but providers >> can't/won't peer with you without one in the first place reality. > > It's been a while since I've applied for an ASN...but used to be you > just put on the form that you've ordered connectivity from multiple > providers with the intent of multihoming, and that was good enough for > ARIN. If that's no longer good enough, I would think any understanding > provider would let you setup the peering connection first, assign it a > /30, and then wait for you to get your ASN to do the BGP part. > Long story, but the short of it is we were planning our IPv6 deployment, and because of several issues couldn't get native ipv6 to our main cabinet. Given our low budget nature, another drop was not feasable just to appease the ARIN rules, so it took time to brainstorm a plan of action. To do things the right way, yeah it made it harder and required coordination and the help of the guys at HE. But, the key being we followed the rules and didn't try to game the system - we're multihomed now, just not in the traditional way. :) This comes back to the whole thing where the people who try do things the right way always seem to have the biggest hassle, yet while those are who are less honest, seem to get everything. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From frank at fttx.org Sat Oct 2 17:09:39 2010 From: frank at fttx.org (Frank A. Coluccio) Date: Sat, 2 Oct 2010 15:09:39 -0700 Subject: A New TransAtlantic Cable System Message-ID: <20101002150939.1E79C00B@resin16.mta.everyone.net> Hi All. It appears we're discussing theoretical limits of silica-based glass here. The Press Release assertion talks about what a trader might experience. Hm. I would ask Rob Beck to clarify this point and inform whether the stated objective in the release accounts for the many o-e and e-o conversions on the overland part of the end-to-end trader connection, including the handoffs that occur in the NY and London metros. I know that terrestrially, i.e., here in the US, some brokerage firms and large banks (is there any longer a distinction between those two today?:) have used their clout to secure links that are virtually entirely optical in nature on routes that are under a thousand miles, but this is not an option on a submarine system that's intrinsically populated with electronics, never mind the tail sections that assume multiple service providers getting into the act. Rob? Anyone? FAC --- Valdis.Kletnieks at vt.edu wrote: From: Valdis.Kletnieks at vt.edu To: Heath Jones Cc: nanog at nanog.org Subject: Re: A New TransAtlantic Cable System Date: Fri, 01 Oct 2010 10:08:50 -0400 On Fri, 01 Oct 2010 15:01:25 BST, Heath Jones said: > > http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html ?x=0&.v=1 > Sales spam - but still - very close to minimum possible latency! > 3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip = 55.9ms. My first thought is that they've found a way to cheat on the 1.5. If you can make it work at 1.4, you get down to 52.2ms - but get it *too* low and all your photons leak out the sides. Hmm.. Unless you have a magic core that runs at 1.1 and a *cladding* that's up around 2.0? From smb at cs.columbia.edu Sat Oct 2 17:47:01 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Sat, 2 Oct 2010 18:47:01 -0400 Subject: AS11296 -- Hijacked? In-Reply-To: <8CC300ED-C243-4186-A9BE-C36EF854145D@delong.com> References: <6777.1285912054@tristatelogic.com> <5A6D953473350C4B9995546AFE9939EE0A52B069@RWC-EX1.corp.seven.com> <20101001120050.GA29429@gsp.org> <5A6D953473350C4B9995546AFE9939EE0A52B09B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0A52B09F@RWC-EX1.corp.seven.com> <8CC300ED-C243-4186-A9BE-C36EF854145D@delong.com> Message-ID: <64ACF6C2-FDE0-464E-89F3-DCE44B16E0FB@cs.columbia.edu> On Oct 1, 2010, at 7:00 51PM, Owen DeLong wrote: > > On Oct 1, 2010, at 2:31 PM, George Bonser wrote: > >> >> >>> -----Original Message----- >>> From: wherrin at gmail.com >>> Herrin >>> Sent: Friday, October 01, 2010 2:27 PM >>> To: George Bonser >>> Cc: Christopher Morrow; nanog at nanog.org >>> Subject: Re: AS11296 -- Hijacked? >>> >>> >>> Death by IP address? >>> >>> -Bill >> >> Quite possible if one is using it to distribute a virus. RE: Spanair >> flight JK-5022 >> >> http://www.monstersandcritics.com/news/europe/news/article_1578877.php/C >> omputer-viruses-may-have-contributed-to-Spanish-2008-plane-crash >> >> > > http://aircrewbuzz.com/2008/10/officials-release-preliminary-report-on.html > > A more recent Interim report: > > http://www.fomento.es/NR/rdonlyres/AADDBF93-690C-4186-983C-8D897F09EAA5/75736/2008_032_A_INTERINO_01_ENG.pdf > > The crew apparently skipped the step where they were supposed to deploy > the slats/flaps prior to takeoff. > > Additionally, the warning system on the aircraft which should have alerted > the crew to the failure to extend the flaps/slats also failed to sound. > > A computer virus may have had a small contribution to the failure to detect > the warning system failure in the maintenance process, but, it did not cause > the accident. > > The accident is clearly the result of pilot error, specifically the failure to > properly configure the aircraft for takeoff and failure to take remedial > action upon activation of the stall warning system during the initial > climb. > There's more to the story than that. There was a problem with a sensor -- the heater for it was running when the plane was on the ground, which it shouldn't do. The mechanic couldn't reproduce the problem; since there was no icing likely and the heater was only needed if there was icing, the pilot flipped the breaker to disable it. (The virus-infected computer was the one that should have been used to log two previous reports of that same heater problem, but no one even tried entering the reports until after the crash, so the virus wasn't at all the problem.) Because of the distractions -- the return to the gate, the co-pilot making a call to cancel dinner planes, a third person in the cockpit, the pilots indeed forgot to set the flaps -- and just breezed through the checklist item (which they did recite) rather than actually paying attention to it. However... the accident investigators learned that in almost all previous instances, worldwide, of that heater problem, the cause was a failed relay in the "I'm on the ground" circuit. That same relay was used to activate the Takeoff Configuration Warning System -- which didn't alert the pilots to the flaps problem because the relay failed again after the plane left the gate for the second time. In other words, a crucial safety system had a single point of failure -- and that failure also contributed to the distraction that led to the pre-takeoff pilot error. --Steve Bellovin, http://www.cs.columbia.edu/~smb From franck at genius.com Sat Oct 2 18:23:13 2010 From: franck at genius.com (Franck Martin) Date: Sat, 2 Oct 2010 16:23:13 -0700 (PDT) Subject: router lifetime Message-ID: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> How long do you keep a router in production? What is your cycle for replacement of equipment? For a PC, you usually depreciate it over 3 years, and can make it last 5 years, but then you are stretching the functionality, especially if you upgrade the OS, tho it is not uncommon to see companies still on XP and IE6. I'm wondering what is the rule of thumb for routing hardware? Same shelf life as a PC or you keep the hardware much longer? From rfg at tristatelogic.com Sat Oct 2 18:24:43 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 02 Oct 2010 16:24:43 -0700 Subject: AS14202 - 'jacked routes... Whoa! This is just getting silly now! Message-ID: <24459.1286061883@tristatelogic.com> Somebody else on another mailing list I'm on actually found the following new 'jacking incident. Count 'em... one hundred and eighty three (183) separate jacked blocks. I can't take any credit. I wanted to include, in this posting, the name of the guy who actually found this stuff, and give him full credit for finding this, but he's asked me not to. These announcements may not be around very long. We'll see. Regards, rfg P.S. If ARIN actually does want to clean up and reclaim old abandoned blocks... well... it would appear that some nice helpful fellow has already catefully surveyed both 204/8 and 205/8 for such things, on their behalf. See below. AS14202: 198.153.0.0/21 199.5.152.0/23 199.253.192.0/21 200.1.184.0/21 200.4.32.0/20 200.41.240.0/22 204.17.128.0/23 204.17.250.0/23 204.17.252.0/23 204.19.124.0/23 204.19.126.0/23 204.19.132.0/23 204.19.180.0/22 204.19.226.0/23 204.19.234.0/23 204.52.148.0/22 204.57.8.0/21 204.57.16.0/20 204.58.132.0/23 204.58.250.0/23 204.58.252.0/23 204.61.16.0/21 204.61.24.0/22 204.61.28.0/23 204.62.148.0/23 204.62.168.0/23 204.63.144.0/21 204.63.152.0/21 204.63.168.0/22 204.63.172.0/23 204.68.232.0/23 204.75.148.0/23 204.75.240.0/23 204.76.16.0/21 204.76.24.0/22 204.76.158.0/23 204.76.160.0/22 204.76.164.0/23 204.76.198.0/23 204.76.200.0/23 204.76.214.0/23 204.76.216.0/22 204.76.230.0/23 204.76.232.0/22 204.76.236.0/23 204.76.246.0/23 204.76.248.0/22 204.76.252.0/23 204.79.130.0/23 204.80.66.0/23 204.80.68.0/22 204.80.72.0/21 204.80.80.0/22 204.80.84.0/23 204.86.0.0/21 204.86.8.0/22 204.86.104.0/21 204.86.112.0/22 204.89.0.0/21 204.89.134.0/23 204.110.184.0/23 204.115.136.0/21 204.124.4.0/22 204.124.68.0/22 204.124.72.0/22 204.124.76.0/22 204.126.180.0/23 204.126.184.0/23 204.126.244.0/23 204.147.192.0/21 204.152.16.0/23 204.152.36.0/23 204.152.52.0/23 204.152.72.0/23 204.152.120.0/23 204.152.122.0/23 204.152.136.0/23 204.152.160.0/22 204.152.164.0/23 204.153.164.0/22 204.153.180.0/22 204.153.224.0/22 204.174.48.0/23 204.174.52.0/23 204.174.76.0/22 204.174.204.0/23 204.187.50.0/23 204.187.52.0/23 204.187.96.0/23 204.187.106.0/23 204.187.108.0/22 204.187.112.0/22 204.187.116.0/23 204.194.16.0/22 204.194.48.0/21 204.194.192.0/21 204.194.200.0/22 204.194.208.0/22 204.194.216.0/22 204.194.220.0/23 204.209.30.0/23 204.209.86.0/23 204.225.184.0/23 204.225.226.0/23 204.225.234.0/23 204.231.242.0/23 204.231.244.0/23 204.239.126.0/23 204.239.176.0/23 204.239.192.0/23 204.239.200.0/23 205.132.88.0/22 205.132.92.0/23 205.132.136.0/21 205.132.152.0/21 205.142.4.0/23 205.142.32.0/22 205.142.40.0/22 205.142.68.0/22 205.142.84.0/22 205.142.132.0/22 205.142.136.0/22 205.142.140.0/22 205.142.144.0/22 205.142.160.0/22 205.142.204.0/22 205.142.208.0/22 205.142.212.0/22 205.143.8.0/21 205.143.56.0/21 205.153.4.0/22 205.153.32.0/22 205.153.72.0/22 205.153.108.0/22 205.153.124.0/22 205.153.132.0/22 205.153.164.0/22 205.153.168.0/22 205.153.184.0/22 205.153.200.0/22 205.153.216.0/22 205.153.252.0/22 205.167.12.0/23 205.167.20.0/23 205.167.32.0/23 205.167.38.0/23 205.167.50.0/23 205.167.66.0/23 205.167.72.0/23 205.167.82.0/23 205.167.98.0/23 205.167.112.0/23 205.167.160.0/23 205.167.172.0/23 205.167.178.0/23 205.167.190.0/23 205.167.194.0/23 205.167.204.0/23 205.167.228.0/23 205.167.236.0/23 205.167.246.0/23 205.172.32.0/22 205.172.36.0/22 205.172.116.0/22 205.172.120.0/21 205.172.128.0/22 205.172.140.0/22 205.172.152.0/22 205.172.176.0/22 205.172.244.0/22 205.172.252.0/22 205.173.184.0/21 205.189.74.0/23 205.189.78.0/23 205.189.118.0/23 205.189.120.0/23 205.189.222.0/23 205.189.224.0/23 206.53.128.0/21 206.82.96.0/21 206.208.72.0/21 206.220.0.0/22 207.45.96.0/21 From hj1980 at gmail.com Sat Oct 2 18:34:40 2010 From: hj1980 at gmail.com (Heath Jones) Date: Sun, 3 Oct 2010 00:34:40 +0100 Subject: router lifetime In-Reply-To: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> References: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: > How long do you keep a router in production? > What is your cycle for replacement of equipment? Hi Franck It really depends on the type of network you are running, the rate at which new features & bandwidth are required, and the availability of software and hardware upgrades. Also, in a lot of cases it is vendor driven - devices that are still very much in production are forced to be replaced because of vendor product lifecycle and the phasing out of support, even when serving their requirements well. Care to elaborate a little more on your planned scenario? Cheers Heath From brandon.kim at brandontek.com Sat Oct 2 18:49:12 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sat, 2 Oct 2010 19:49:12 -0400 Subject: router lifetime In-Reply-To: References: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local>, Message-ID: Don't have much to add other than Heath's response is pretty much what I would have said. It really all depends on your business needs as well as policy, or standards you need to meet.... > Date: Sun, 3 Oct 2010 00:34:40 +0100 > Subject: Re: router lifetime > From: hj1980 at gmail.com > To: franck at genius.com > CC: nanog at nanog.org > > > How long do you keep a router in production? > > What is your cycle for replacement of equipment? > > Hi Franck > > It really depends on the type of network you are running, the rate at > which new features & bandwidth are required, and the availability of > software and hardware upgrades. Also, in a lot of cases it is vendor > driven - devices that are still very much in production are forced to > be replaced because of vendor product lifecycle and the phasing out of > support, even when serving their requirements well. > > > Care to elaborate a little more on your planned scenario? > > > Cheers > Heath > From mysidia at gmail.com Sat Oct 2 18:59:01 2010 From: mysidia at gmail.com (James Hess) Date: Sat, 2 Oct 2010 18:59:01 -0500 Subject: AS11296 -- Hijacked? In-Reply-To: <54ED4B73-B9D9-4922-8A67-C3D37318DA55@arin.net> References: <201010022003.o92K3qSa029992@mail.r-bonomi.com> <54ED4B73-B9D9-4922-8A67-C3D37318DA55@arin.net> Message-ID: On Sat, Oct 2, 2010 at 3:41 PM, John Curran wrote: > On Oct 2, 2010, at 4:03 PM, Robert Bonomi wrote: > Robert - > ? ?You are matching nearly verbatim from ARIN's actual procedures for recognizing a transfer via merger or acquisition. ? The problem is compounded because often the parties appear years later, don't have access to the legal documentation of the merger, and there is no "corporate" surviving entity to contact. ? Many parties abandon these transfers mid-process, leaving us to wonder whether they were exactly as claimed but simply lacking needed documentation, or whether they were optimistic attempts to hijack. > /John Hm.. just a thought... if an org doesn't have and are unable to obtain any good written documentation at all, from even the public record, then aren't they (as far as the operator community should be concerned) not the same registrant, or authorized? Where would a person be if they were trying to claim the right to a certain piece of land, and someone else (an opportunist/scammer) also claimed ownership using "papers" they had created, but the 'rightful' owner had neither a deed, nor a transfer agreement, proof of their use of that land, nor other certified document, and the local authority did not have any record of a transfer from the now defunct original owner? --- So, I wonder why only ARIN itself is singled out.. Have other RIRs found something much better to do with fraud reports? This matters, because scammers can concentrate on whichever IP blocks are easiest to hijack. If ARIN somehow creates a hostile environment for scammers, they can concentrate on APNIC/RIPE/AfriNic/LACNIC-administered IP ranges instead. Assume scanners don't care or need to be undetected for long at all, they just need to stay off 'hijacked IP lists' for a very brief time, perhaps a week, until they are blacklisted by major RBLs for spamming, stop using the range, find a new one, under a new manufactured identity, lather, rinse, .... Even with excellent RIR detection and reclaiming of defunct ranges, the most capable anti-scammer mechanisms may still be independent Bogon lists and RBLs. Watch the global visibility of prefixes, and detect when part of a completely unannounced RIR assigned prefix starts being announced or when an entire RIR prefix stops being announced for more than a couple days or so. And it doesn't fall into the category of 'newly registered prefix' . Those should be additional "triggers" for defunct contact detection / additional verification, and anti-fraud detection by RIRs and others. Because address ranges can become defunct at any time.... Something really should be watching for a previously defunct range re-appearing from a different AS or from a completely different place net-wise. -- -J From franck at genius.com Sat Oct 2 19:09:20 2010 From: franck at genius.com (Franck Martin) Date: Sat, 2 Oct 2010 17:09:20 -0700 (PDT) Subject: router lifetime In-Reply-To: Message-ID: <6672656.613.1286064555265.JavaMail.franck@franck-martins-macbook-pro.local> I'm looking at various scenario, but basically it is looking at IPv6 in fact. It seems to me, that using a router/network appliance today for IPv6 will need to be replaced in 3 years or less. Looking at past, anything older than 3 years is not a viable solution for deploying IPv6. So I feel that routing/network appliance equipment have a life cycle similar to a PC, despite the fact as someone pointed out, they will run fine for many many years. ----- Original Message ----- From: "Heath Jones" To: "Franck Martin" Cc: nanog at nanog.org Sent: Saturday, 2 October, 2010 4:34:40 PM Subject: Re: router lifetime > How long do you keep a router in production? > What is your cycle for replacement of equipment? Hi Franck It really depends on the type of network you are running, the rate at which new features & bandwidth are required, and the availability of software and hardware upgrades. Also, in a lot of cases it is vendor driven - devices that are still very much in production are forced to be replaced because of vendor product lifecycle and the phasing out of support, even when serving their requirements well. Care to elaborate a little more on your planned scenario? Cheers Heath From brandon.kim at brandontek.com Sat Oct 2 20:22:27 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sat, 2 Oct 2010 21:22:27 -0400 Subject: router lifetime In-Reply-To: <6672656.613.1286064555265.JavaMail.franck@franck-martins-macbook-pro.local> References: , <6672656.613.1286064555265.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: Well a lot of routers even 3 years ago support IPv6. You can dual-stack pretty much any router today if you have the right IOS. But I do understand your concern, if you want to future proof your purchase, I'd think any modern router today with a good support contract will take care of you for quite some time. Make sure it's not close to EOL. What kind of router are you considering? Is this for a large network? What are the network needs? > Date: Sat, 2 Oct 2010 17:09:20 -0700 > From: franck at genius.com > To: nanog at nanog.org > Subject: Re: router lifetime > > I'm looking at various scenario, but basically it is looking at IPv6 in fact. > > It seems to me, that using a router/network appliance today for IPv6 will need to be replaced in 3 years or less. > > Looking at past, anything older than 3 years is not a viable solution for deploying IPv6. > > So I feel that routing/network appliance equipment have a life cycle similar to a PC, despite the fact as someone pointed out, they will run fine for many many years. > > ----- Original Message ----- > From: "Heath Jones" > To: "Franck Martin" > Cc: nanog at nanog.org > Sent: Saturday, 2 October, 2010 4:34:40 PM > Subject: Re: router lifetime > > > How long do you keep a router in production? > > What is your cycle for replacement of equipment? > > Hi Franck > > It really depends on the type of network you are running, the rate at > which new features & bandwidth are required, and the availability of > software and hardware upgrades. Also, in a lot of cases it is vendor > driven - devices that are still very much in production are forced to > be replaced because of vendor product lifecycle and the phasing out of > support, even when serving their requirements well. > > > Care to elaborate a little more on your planned scenario? > > > Cheers > Heath > From deleskie at gmail.com Sat Oct 2 20:27:32 2010 From: deleskie at gmail.com (jim deleskie) Date: Sat, 2 Oct 2010 22:27:32 -0300 Subject: router lifetime In-Reply-To: References: <6672656.613.1286064555265.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: If you can do a business case to support replacing routers every 3years you doing much better then most. IMO a router should last 5 yrs on the book, but I expect to get more life then then from it. You core today is tomorrow's edge. I've seen more then one network with 10 yo kit still being used. -jim On Sat, Oct 2, 2010 at 10:22 PM, Brandon Kim wrote: > > Well a lot of routers even 3 years ago support IPv6. You can dual-stack > pretty much any router today if you have > the right IOS. But I do understand your concern, if you want to future > proof your purchase, I'd think any modern > router today with a good support contract will take care of you for quite > some time. > Make sure it's not close to EOL. > > What kind of router are you considering? Is this for a large network? What > are the network needs? > > > > > Date: Sat, 2 Oct 2010 17:09:20 -0700 > > From: franck at genius.com > > To: nanog at nanog.org > > Subject: Re: router lifetime > > > > I'm looking at various scenario, but basically it is looking at IPv6 in > fact. > > > > It seems to me, that using a router/network appliance today for IPv6 will > need to be replaced in 3 years or less. > > > > Looking at past, anything older than 3 years is not a viable solution for > deploying IPv6. > > > > So I feel that routing/network appliance equipment have a life cycle > similar to a PC, despite the fact as someone pointed out, they will run fine > for many many years. > > > > ----- Original Message ----- > > From: "Heath Jones" > > To: "Franck Martin" > > Cc: nanog at nanog.org > > Sent: Saturday, 2 October, 2010 4:34:40 PM > > Subject: Re: router lifetime > > > > > How long do you keep a router in production? > > > What is your cycle for replacement of equipment? > > > > Hi Franck > > > > It really depends on the type of network you are running, the rate at > > which new features & bandwidth are required, and the availability of > > software and hardware upgrades. Also, in a lot of cases it is vendor > > driven - devices that are still very much in production are forced to > > be replaced because of vendor product lifecycle and the phasing out of > > support, even when serving their requirements well. > > > > > > Care to elaborate a little more on your planned scenario? > > > > > > Cheers > > Heath > > > > From gbonser at seven.com Sat Oct 2 20:35:47 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 2 Oct 2010 18:35:47 -0700 Subject: router lifetime In-Reply-To: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> References: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0C8@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Franck Martin > Sent: Saturday, October 02, 2010 4:23 PM > To: nanog at nanog.org > Subject: router lifetime > > How long do you keep a router in production? It depends on its purpose in the network, the change in requirements for that purpose over time, and the vendor's support of the device. A router handing 10Meg of traffic between offices might last until the vendor abandons all support of the unit. A router in a segment where traffic rates are changing rapidly might need replacement sooner. Sometimes it is the introduction of some new technology that drives a change in equipment if the new feature provides some overall benefit. > > What is your cycle for replacement of equipment? No set in stone replacement cycle. From gbonser at seven.com Sat Oct 2 20:50:56 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 2 Oct 2010 18:50:56 -0700 Subject: AS14202 - 'jacked routes... Whoa! This is just getting silly now! In-Reply-To: <24459.1286061883@tristatelogic.com> References: <24459.1286061883@tristatelogic.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0C9@RWC-EX1.corp.seven.com> - > P.S. If ARIN actually does want to clean up and reclaim old abandoned > blocks... well... it would appear that some nice helpful fellow has > already catefully surveyed both 204/8 and 205/8 for such things, on > their behalf. See below. > > > AS14202: > So a supposed Columbian ISP has its only Internet connectivity at a Toronto, Ontario colo? Am I digging that out correctly? From jcurran at arin.net Sat Oct 2 21:05:41 2010 From: jcurran at arin.net (John Curran) Date: Sat, 2 Oct 2010 22:05:41 -0400 Subject: AS11296 -- Hijacked? (ARIN region & hijacking) In-Reply-To: References: <201010022003.o92K3qSa029992@mail.r-bonomi.com> <54ED4B73-B9D9-4922-8A67-C3D37318DA55@arin.net> Message-ID: On Oct 2, 2010, at 7:59 PM, James Hess wrote: > So, I wonder why only ARIN itself is singled out.. Have other RIRs > found something much better to do with fraud reports? This matters, > because scammers can concentrate on whichever IP blocks are easiest to hijack. The reason: approximately 15000 legacy address blocks which ARIN become the successor registry for at its formation, many of which hadn't been updated since they were allocated. In the other regions, there are significantly fewer early allocations where the holders haven't also involved ongoing in the combined registry/operator forum in the region. Two particular quicks of this region is that the registry is not combined with the operator forum, and many of the assignments from the earliest days of the Internet are in this region, made with minimal documentation, and were often forgotten or never put into publicly routed use... Ergo, when a party appears and says that they'd like to update the contacts on their WHOIS record, and we see an organization which exists back to the original allocation, it is fairly straightforward to make it happen and know that we're not facilitating a hijacking. For this reason, legacy holders are allowed to change anything except the organization name without requiring documentation. It gets more challenging when you instead have a different organization name XYX, which states it is the rightful holder of NET-ABC123 because it acquired JKL company which in theory had earlier bought the right piece of company ABC which is now defunct but never updated any of IP records post business deal, and no one from ABC or JKL can be found and the public records may indeed show that JKL bought some part of ABC but most assuredly don't say anything about networks or as#'s... Circumstances such as the aformentioned are regretfully the rule, not the exception. (As an aside, I'll note that we do also look at the historical routing of the address block, since that provides some insight which often can corroborate an otherwise weak documentary record.) Now, we really want folks to come in and update their records but when it comes to updating the actual organization name for an address block, we either need to hold the line on legal/commercial documents (which reduces hijacking but almost sends some legitimate but underdocumented legacy folks away) or we can simply have folks attest to their view of reality and update the records accordingly (which will get us much more current Whois records but with "current" not necessarily implying any more accurate records...) This is *your* (the collective "your") WHOIS database, and ARIN will administer it per any policy which adopted by the community. /John John Curran President and CEO ARIN P.S. I will note that we fully have the potential to recreate this problem in IPv6 if we're not careful, and establishing some very clear record keeping requirements for IPv6 with both RIRs and ISPs/LIRs is going to be very important if we ever hope to determine the party using a given IPv6 block in just a few short years... From hank at efes.iucc.ac.il Sun Oct 3 00:01:00 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 3 Oct 2010 07:01:00 +0200 (IST) Subject: router lifetime In-Reply-To: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> References: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Sat, 2 Oct 2010, Franck Martin wrote: > How long do you keep a router in production? > > What is your cycle for replacement of equipment? > > For a PC, you usually depreciate it over 3 years, and can make it last 5 years, but then you are stretching the functionality, especially if you upgrade the OS, tho it is not uncommon to see companies still on XP and IE6. > > I'm wondering what is the rule of thumb for routing hardware? Same shelf life as a PC or you keep the hardware much longer? Short answer: 8 years Long answer: we are an academic network and when we upgrade the routers we buy top of the line routers with speeds far in excess of what we need then. If and when we need to upgrade, we usually pull out the main card and upgrade to the latest processor. We never buy a router with just 2x the horse power and slots we need. When we buy we buy with 10-15x the horsepower we need. -Hank From patrick at excalibursystems.net Sun Oct 3 00:02:19 2010 From: patrick at excalibursystems.net (Patrick Stueck) Date: Sun, 3 Oct 2010 00:02:19 -0500 Subject: router lifetime In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0A52B0C8@RWC-EX1.corp.seven.com> References: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> <5A6D953473350C4B9995546AFE9939EE0A52B0C8@RWC-EX1.corp.seven.com> Message-ID: I still have a few Cisco 2600 Series routers in service from 9 years ago. Some of those here soon are being replaced with the 2800/3800 series integrated service routers. These routers don't handle a lot as far as traffic, so even the 2600 series routers are still performing the tasks at hand very well. Only moving to the newer series routers to get everything in one "package". -- *__________________________ Patrick Stueck Director of Operations* Microsoft Certified Professional | Web and Software Developer | Systems Engineer *Confidentiality Notice: *This e-mail and any attachments may contain confidential and privileged information. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this e-mail and destroy any copies. Any dissemination or use of this information by a person other than the intended recipient is unauthorized and may be illegal. From gbonser at seven.com Sun Oct 3 00:02:59 2010 From: gbonser at seven.com (George Bonser) Date: Sat, 2 Oct 2010 22:02:59 -0700 Subject: AS11296 -- Hijacked? (ARIN region & hijacking) In-Reply-To: References: <201010022003.o92K3qSa029992@mail.r-bonomi.com><54ED4B73-B9D9-4922-8A67-C3D37318DA55@arin.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0A52B0CB@RWC-EX1.corp.seven.com> > > This is *your* (the collective "your") WHOIS database, and ARIN will > administer > it per any policy which adopted by the community. > > /John > > John Curran > President and CEO > ARIN > > P.S. I will note that we fully have the potential to recreate this > problem > in IPv6 if we're not careful, and establishing some very clear > record > keeping requirements for IPv6 with both RIRs and ISPs/LIRs is > going to > be very important if we ever hope to determine the party using a > given > IPv6 block in just a few short years... > So then the question is, what can we as a community (note that is not ARIN specific) do that makes it more difficult for someone to fraudulently announce number resources they aren't really entitled to? On the reactive side, we could have more people actively searching for such abuse. What can be done on the proactive side to make it more difficult to do it in the first place? From franck at genius.com Sun Oct 3 02:29:27 2010 From: franck at genius.com (Franck Martin) Date: Sun, 3 Oct 2010 00:29:27 -0700 (PDT) Subject: router lifetime In-Reply-To: Message-ID: <7283831.782.1286090963775.JavaMail.franck@franck-martins-macbook-pro.local> From: "Brandon Kim" To: franck at genius.com, nanog at nanog.org Sent: Saturday, 2 October, 2010 6:22:27 PM Subject: RE: router lifetime Well a lot of routers even 3 years ago support IPv6. You can dual-stack pretty much any router today if you have the right IOS. But I do understand your concern, if you want to future proof your purchase, I'd think any modern router today with a good support contract will take care of you for quite some time. Make sure it's not close to EOL. What kind of router are you considering? Is this for a large network? What are the network needs? Well it is not for me really. It is a kind of a survey. In your environment, how often do you replace your gear? I found out that switch gear from cisco with layer 3 routing, which are EOL today do not do IPv6 (at layer 3). Cisco Firewalls do not support well IPv6 unless you have upgraded this year, and for load balancers, you are out of luck. So basically anything which is EOL today has IPv6 issues while still much in use in production environment. Is that a fair assessment? I found out also that some gear with fancy IPv4 stuff do not do the same in IPv6, What about Juniper? Then there is the IPv6 is not done at hardware level, because software is fast enough for the current IPv6 bandwidth, but then if you expect to keep your gear for 8 years... Will you have to replace it much earlier than expected? It seems to me on the desktop/server, IPv6 is there free of charge (enabled by default), but on the network, switching to IPv6 is not free nor trivial. From rfg at tristatelogic.com Sun Oct 3 02:51:56 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 03 Oct 2010 00:51:56 -0700 Subject: NEVERMIND! (was: ARIN Fraud Reporting Form ... ) In-Reply-To: <17104.1285997192@tristatelogic.com> Message-ID: <27952.1286092316@tristatelogic.com> In message <17104.1285997192 at tristatelogic.com>, I wrote: >>> If you can put an annotation into a whois records for a POC, >>> saying explicity that you can't get ahold of this person, then it would >>> seem to me to be a rather trivial matter of programming to transplant >>> a very similar sort of annotation into each and every IP block or AS >>> record that has that same specific POC record as one of its associated >>> POC records, either Admin, or Technical, or whatever. >> >>Also a nice idea, and one that I've taken as a formal suggestion for >>improvement. I see now that I really need to back up a couple of steps here and ask John for something which is, in a way, entirely different from what I have asked for so far. (See above.) And in fact, this one ought to be as EASY AS PIE for ARIN to implement, since it would appear that they are ALREADY DOING IT. I asked John for a ``new'' kind of ``this is not quite right'' annotation within AS and IP block whois records. *And* I asked him to make these annotations public, right within the public WHOIS records... *not* just within some special, semi-secret feed of some special, semi-secret version of the WHOIS data base. So while I was looking at the WHOIS records for the set of blocks that were (apparently now past tense) being 'jacked by AS14202 earlier today (Saturday) I happened to come across the following annotation in one of the relevant IP block WHOIS records (but _only_ one): Comment: The information for this network has been reported to Comment: be invalid. ARIN has attempted to obtain updated data, but has Comment: been unsuccessful. To provide current contact information, Comment: please e-mail hostmaster at arin.net. YESSS! This is exactly the kind of thing I have been asking for! But more to the point, this is the exact kind of thing that (very bizzarely) John Curran just told me that he would accept as, in effect, and enhancement request... AS IF IT DIDN'T ALREADY EXIST, or as if ARIN wasn't already doing this exact thing. (See the WHOIS for NET-204-89-0-0-1, which, as we speak, contains the above helpful annotation.) So OK, John... Can you explain yourself... please? Why did you say you were accepting my request into your suggestion box, when it appears that ARIN has already been doing exactly the thing I asked for... even if only haphazardly, in a disorganized way, and only within a limited number of cases? I googled for some of the verbage in the above notice, and I got over 9,000 hits. So obviously, this notice that's present within the WHOIS record for NET-204-89-0-0-1... and many many many others... isn't a ``one off''. You ARIN folks have apparently already placed that same annotaion in lots and lots of AS and IP block records. Maybe you haven't been doing it _lately_ or perhaps maybe you haven't been doing it _consistantly_, but that's a hell of a different thing that just playing dumb and/or saying (or implying) that ARIN has never done it at all, don't you agree John? So let's get down to brass tacks here. John, you can see the annotation that's present within the WHOIS record for NET-204-89-0-0-1 just as well as I can. And you obviously don't have any trouble with understanding the English language, and the annotation is clear and straightforward. ARIN has been unable to verify the POC. And this annotation is _not_ just on the POC record itself. It is on an IP block WHOIS record. This is _exactly_ what I was asking for. ARIN has clearly already been doing it, so there's no need for a whole new study committee, an environmental impact statement, circulation of proposals, sub-committee delegation, advancement of the proposal back to the super-committee for re-review, recirculation, republication, balloting, re-balloting, amendment, etc., etc., etc., in other words all of the bullshit bureaucratic stumbling blocks that bureaucrats... like my favorite, Sir Humphrey Appleby... put up as road- blocks to even the smallest and simplest bit of forward movement. I'll say it again, because I don't want there to be any misunderstanding: Clearly, ARIN has already been doing this... putting in these WHOIS record annotations. I have LOTS of example of that. So now, John, did someone ever expressely *withdraw* ARIN's permission to create and attach these exact sorts of annotations? If so, who, and when? If not, then the ball's in your court John, and your choice is simple, I think: Do you want to do something simple... something that ARIN quite obviously already has permission to do... or do you want to be Sir Humphrey Appleby and smother this small simple idea in its crib with layer upon layer of bureaucracy? If the latter, then I have every confidence that you are skilled enough to succeed at erecting an impenetrable wall of bureaucracy. If the former however, then when should we expect to start seeing these annotations in _all_ of the IP block and AS WHOIS records that have uncontactable POCs... a set which ARIN has, apparently, already identified, in spades. (If your staff can't get this done in a week, then please do contact me off list, because I'm quite sure that _I_ can do it in a half an hour, in Perl... and I'd be only too happy to volunteer my time for this good cause.) You might well ask ``What would be the point of all this? What would be the use?'' The point and the usefulness is that if these kinds of annotations are present within AS and IP block WHOIS records, then guys like the poor overworked, well-meaning manager of Colosseum.com (AS19842) who I spoke to earlier today about his customer, AS14202, and all of the hijacked IP space it was announcing would be able to see at a glance that something isn't right. And who knows? Maybe even if those annotations were in there for all of the blocks that are _still_ being hijacked by AS6061 and AS10392, even as we speak, then maybe it would be just a little less easy for companies like Beyond The Network America to play dumb, and to act like they don't know exactly what's really going on here. And that would be helpful. Regards, rfg From jcurran at arin.net Sun Oct 3 03:18:40 2010 From: jcurran at arin.net (John Curran) Date: Sun, 3 Oct 2010 04:18:40 -0400 Subject: NEVERMIND! (was: ARIN Fraud Reporting Form ... ) In-Reply-To: <27952.1286092316@tristatelogic.com> References: <27952.1286092316@tristatelogic.com> Message-ID: <3070D3C0-513D-4CB9-8EC2-EB22CA52AE59@arin.net> On Oct 3, 2010, at 3:51 AM, Ronald F. Guilmette wrote: > So while I was looking at the WHOIS records for the set of blocks that were > (apparently now past tense) being 'jacked by AS14202 earlier today (Saturday) > I happened to come across the following annotation in one of the relevant > IP block WHOIS records (but _only_ one): > > Comment: The information for this network has been reported to > Comment: be invalid. ARIN has attempted to obtain updated data, but has > Comment: been unsuccessful. To provide current contact information, > Comment: please e-mail hostmaster at arin.net. > > YESSS! This is exactly the kind of thing I have been asking for! > > But more to the point, this is the exact kind of thing that (very bizzarely) > John Curran just told me that he would accept as, in effect, and enhancement > request... AS IF IT DIDN'T ALREADY EXIST, or as if ARIN wasn't already doing > this exact thing. (See the WHOIS for NET-204-89-0-0-1, which, as we speak, > contains the above helpful annotation.) While I knew that we were building the list (as required by policy) of netblocks without any valid contact info, I was not aware that the entries would also be nicely annotated in WHOIS as shown above. Congrats, Ron, whatever your favorite holiday is, it comes early this year. /John John Curran President and CEO ARIN From rfg at tristatelogic.com Sun Oct 3 04:15:00 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 03 Oct 2010 02:15:00 -0700 Subject: NEVERMIND! (was: ARIN Fraud Reporting Form ... ) In-Reply-To: <3070D3C0-513D-4CB9-8EC2-EB22CA52AE59@arin.net> Message-ID: <28570.1286097300@tristatelogic.com> In message <3070D3C0-513D-4CB9-8EC2-EB22CA52AE59 at arin.net>, John Curran wrote: >On Oct 3, 2010, at 3:51 AM, Ronald F. Guilmette wrote: >> Comment: The information for this network has been reported to >> Comment: be invalid. ARIN has attempted to obtain updated data, but has >> Comment: been unsuccessful. To provide current contact information, >> Comment: please e-mail hostmaster at arin.net. >... >While I knew that we were building the list (as required by policy) >of netblocks without any valid contact info, I was not aware that >the entries would also be nicely annotated in WHOIS as shown above. > >Congrats, Ron, whatever your favorite holiday is, it comes early >this year. Sorry to be so dense, but I need to ask this explicitly: So is that a "yes"? Is that a "Yes, ARIN will begin immeditely putting these annotations into all of the AS and IP records associated with POCs we already know are uncontactable" ? If so, can you provide a rough time estimate for completion? (Note that I said ``rough''. Whatever you might say, I won't hold you to it. I'd just sort-of like to know that this isn't going to be dead last on the priority list at your place... because, as I think you can tell, I certainly believe that it is important, and very very timely, because the recent evidence suggests that the hijacking epidemic is getting out of control, and this might help to staunch the bleeding a little bit.) Regards, rfg P.S. To be entirely honest, the only instances I have seen so far of the annotation above look to me to have been placed in the relevant WHOIS records perhaps six or more years ago. I'm just saying John that if what I posted makes you believe that your staff are creating/installing these annotations _today_ ... well... check with them before assuming that, because the only ones I've seen look to be kinda old. I certainly hope that if this is something that ARIN _was_ doing and then _stopped_ doing that you'll start up again, in a very big way. But like I say, I'm not really sure that your people have created any of these things _recently_, i.e. in the past several years (but if that's true, I sure hope you'll change that toot sweet). P.P.S. If you can get this one thing done, then I'll sing your praises and take back all of the bad things I said when I was in the mood to rant and rave. This isn't as good as having a cop sitting there watching the global routing table all day, but it would be a damn good second place prize, and something I could live with (and not bitch so much). And of course, it has the great advantage of being something that actually looks do-able, politically (which, as everybody and his brother has explained to me, having a ``cop'' to watch the global routing table isn't). From jcurran at arin.net Sun Oct 3 06:02:23 2010 From: jcurran at arin.net (John Curran) Date: Sun, 3 Oct 2010 07:02:23 -0400 Subject: NEVERMIND! (was: ARIN Fraud Reporting Form ... ) In-Reply-To: <28570.1286097300@tristatelogic.com> References: <28570.1286097300@tristatelogic.com> Message-ID: On Oct 3, 2010, at 5:15 AM, Ronald F. Guilmette wrote: > Is that a "Yes, ARIN will begin immeditely putting these annotations into > all of the AS and IP records associated with POCs we already know are > uncontactable" ? That's a "No". I'd say "Yes" to "Is ARIN is implementing the policy at NRPM 3.6, Annual Whois POC Validation?" > If so, can you provide a rough time estimate for completion? We will provide an update for implementation of policy NRPM 3.6 at Public Policy & Meeting on this week, and I'd be happy to email you same if you don't have a chance to participate onsite or remotely. /John John Curran President and CEO ARIN From rfg at tristatelogic.com Sun Oct 3 06:24:51 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 03 Oct 2010 04:24:51 -0700 Subject: NEVERMIND! (was: ARIN Fraud Reporting Form ... ) In-Reply-To: Message-ID: <30653.1286105091@tristatelogic.com> In message , John Curran wrote: >On Oct 3, 2010, at 5:15 AM, Ronald F. Guilmette wrote: > >> Is that a "Yes, ARIN will begin immeditely putting these annotations into >> all of the AS and IP records associated with POCs we already know are >> uncontactable" ? > >That's a "No". > >I'd say "Yes" to "Is ARIN is implementing the policy at NRPM 3.6, >Annual Whois POC Validation?" Congratulations John. That's just about the best non-answer I've ever heard. I'm sitting here looking at your NRPM 3.6 and it says: Unresponsive POC email addresses shall be marked as such in the database. OK, Fine. So do you have a problem with ``marking those in the data base'' and specifically within the associated AS and IP block records? And if so why? And if you have a problem with that, they please explain when and why you suddenly developed a problem with it, because clearly ARIN _was_ doing this before, at some point. (And it sure looks like you are NOT doing it now.) I'd really like to know when and why ARIN stopped putting these annotations into the AS and IP block records associated with un-contactable POCs. Can you just answer me that? I mean, you know, without directing my attention to some document which also doesn't answer the question? Regards, rfg From wavetossed at googlemail.com Sun Oct 3 07:52:20 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Sun, 3 Oct 2010 13:52:20 +0100 Subject: NEVERMIND! (was: ARIN Fraud Reporting Form ... ) In-Reply-To: <27952.1286092316@tristatelogic.com> References: <17104.1285997192@tristatelogic.com> <27952.1286092316@tristatelogic.com> Message-ID: > So OK, John... Can you explain yourself... please? Why did you say you > were accepting my request into your suggestion box, when it appears that > ARIN has already been doing exactly the thing I asked for... even if only > haphazardly, in a disorganized way, and only within a limited number of > cases? A) It is not John's suggestion box, it is ARIN's suggestion box. John is just one of the board of trustees of ARIN. B) You do not have to abuse the NANOG mailing list to make suggestions. Anyone can go to the ARIN website and make suggestions right here: https://www.arin.net/participate/acsp/index.html C) Speaking of haphazard and disorganized, you might want to review a few of your recent NANOG messages. D) ARIN runs by rules which are made in a transparent process and any member of the Internet community, can propose changes to those rules, or policies. Lots of info on the ARIN website and in the PPML mailing list where people discuss proposed policies. > ARIN has clearly already been doing it, > so there's no need for a whole new study committee, an environmental impact > statement, circulation of proposals, sub-committee delegation, advancement > of the proposal back to the super-committee for re-review, recirculation, > republication, balloting, re-balloting, amendment, etc., etc., etc., > in other words all of the bullshit bureaucratic stumbling blocks that > bureaucrats... like my favorite, Sir Humphrey Appleby... put up as road- > blocks to even the smallest and simplest bit of forward movement. Ah yes, forward movement. Wouldn't it be great if the powers that be just shut you up without any due process. You don't appear to know very much about how ARIN operates which is strange for someone who claims to be an expert in decoding IP address registrations. > If not, then the ball's in your court John, and your choice is simple, Indeed it is. John should refuse to post any more messages on this list about this topic because it has absolutely nothing to do with network operations. By the way, if you try to post messages like this on the ARIN PPML list full of innuendo and character attacks, you will be booted out of there too. --Michael Dillon From brandon.kim at brandontek.com Sun Oct 3 08:56:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 3 Oct 2010 09:56:51 -0400 Subject: router lifetime In-Reply-To: <7283831.782.1286090963775.JavaMail.franck@franck-martins-macbook-pro.local> References: , <7283831.782.1286090963775.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: I'm tasked to replace our core switches which run Extreme 6800's. You are right that some older gear says they support IPv6, but then you find out it's not 100% fully compliant. Our switch is about 6-8 years old I beleive so it's time to update them. We're thinking about the Cisco 6504e. Anything that is pretty modern that we feel will yield us another 6-8 years. I only have a handful of juniper firewalls laying around for lab equipment, so I don't really have that much experience with them. We also need to get IPv6 space from ARIN so that we can fully support IPv6 natively. Our plan is to dual-stack our edge routers, so it is ultimately up to the endpoints to support IPv6. We don't want to deal with any tunneling protocols like Teredo for IPV6. > Date: Sun, 3 Oct 2010 00:29:27 -0700 > From: franck at genius.com > To: nanog at nanog.org > Subject: Re: router lifetime > > > > > > From: "Brandon Kim" > To: franck at genius.com, nanog at nanog.org > Sent: Saturday, 2 October, 2010 6:22:27 PM > Subject: RE: router lifetime > > Well a lot of routers even 3 years ago support IPv6. You can dual-stack pretty much any router today if you have > the right IOS. But I do understand your concern, if you want to future proof your purchase, I'd think any modern > router today with a good support contract will take care of you for quite some time. > Make sure it's not close to EOL. > > What kind of router are you considering? Is this for a large network? What are the network needs? > > > Well it is not for me really. It is a kind of a survey. In your environment, how often do you replace your gear? > > I found out that switch gear from cisco with layer 3 routing, which are EOL today do not do IPv6 (at layer 3). Cisco Firewalls do not support well IPv6 unless you have upgraded this year, and for load balancers, you are out of luck. So basically anything which is EOL today has IPv6 issues while still much in use in production environment. Is that a fair assessment? I found out also that some gear with fancy IPv4 stuff do not do the same in IPv6, What about Juniper? > > Then there is the IPv6 is not done at hardware level, because software is fast enough for the current IPv6 bandwidth, but then if you expect to keep your gear for 8 years... Will you have to replace it much earlier than expected? > > It seems to me on the desktop/server, IPv6 is there free of charge (enabled by default), but on the network, switching to IPv6 is not free nor trivial. > > From pauldotwall at gmail.com Sun Oct 3 11:16:51 2010 From: pauldotwall at gmail.com (Paul WALL) Date: Sun, 3 Oct 2010 12:16:51 -0400 Subject: AS14202 - 'jacked routes... Whoa! This is just getting silly now! In-Reply-To: <24459.1286061883@tristatelogic.com> References: <24459.1286061883@tristatelogic.com> Message-ID: Ronald, A better channel for your anger would be the transit providers: AS3257 Tinet SpA AS3549 Global Crossing AS577 Bell Canada Have you tipped them off? Why are they continuing to accept and re-advertise these prefixes? ARIN's done nothing wrong or counter to their policies. If you don't like the rules, go propose some new ones on PPML. Drive Slow, Paul Wall On Sat, Oct 2, 2010 at 7:24 PM, Ronald F. Guilmette wrote: > > Somebody else on another mailing list I'm on actually found the > following new 'jacking incident. > > Count 'em... one hundred and eighty three (183) separate jacked blocks. > > I can't take any credit. ?I wanted to include, in this posting, the > name of the guy who actually found this stuff, and give him full > credit for finding this, but he's asked me not to. > > These announcements may not be around very long. ?We'll see. > > > Regards, > rfg > > > P.S. If ARIN actually does want to clean up and reclaim old abandoned > blocks... well... it would appear that some nice helpful fellow has > already catefully surveyed both 204/8 and 205/8 for such things, on > their behalf. ?See below. > > > AS14202: > > 198.153.0.0/21 > 199.5.152.0/23 > 199.253.192.0/21 > 200.1.184.0/21 > 200.4.32.0/20 > 200.41.240.0/22 > 204.17.128.0/23 > 204.17.250.0/23 > 204.17.252.0/23 > 204.19.124.0/23 > 204.19.126.0/23 > 204.19.132.0/23 > 204.19.180.0/22 > 204.19.226.0/23 > 204.19.234.0/23 > 204.52.148.0/22 > 204.57.8.0/21 > 204.57.16.0/20 > 204.58.132.0/23 > 204.58.250.0/23 > 204.58.252.0/23 > 204.61.16.0/21 > 204.61.24.0/22 > 204.61.28.0/23 > 204.62.148.0/23 > 204.62.168.0/23 > 204.63.144.0/21 > 204.63.152.0/21 > 204.63.168.0/22 > 204.63.172.0/23 > 204.68.232.0/23 > 204.75.148.0/23 > 204.75.240.0/23 > 204.76.16.0/21 > 204.76.24.0/22 > 204.76.158.0/23 > 204.76.160.0/22 > 204.76.164.0/23 > 204.76.198.0/23 > 204.76.200.0/23 > 204.76.214.0/23 > 204.76.216.0/22 > 204.76.230.0/23 > 204.76.232.0/22 > 204.76.236.0/23 > 204.76.246.0/23 > 204.76.248.0/22 > 204.76.252.0/23 > 204.79.130.0/23 > 204.80.66.0/23 > 204.80.68.0/22 > 204.80.72.0/21 > 204.80.80.0/22 > 204.80.84.0/23 > 204.86.0.0/21 > 204.86.8.0/22 > 204.86.104.0/21 > 204.86.112.0/22 > 204.89.0.0/21 > 204.89.134.0/23 > 204.110.184.0/23 > 204.115.136.0/21 > 204.124.4.0/22 > 204.124.68.0/22 > 204.124.72.0/22 > 204.124.76.0/22 > 204.126.180.0/23 > 204.126.184.0/23 > 204.126.244.0/23 > 204.147.192.0/21 > 204.152.16.0/23 > 204.152.36.0/23 > 204.152.52.0/23 > 204.152.72.0/23 > 204.152.120.0/23 > 204.152.122.0/23 > 204.152.136.0/23 > 204.152.160.0/22 > 204.152.164.0/23 > 204.153.164.0/22 > 204.153.180.0/22 > 204.153.224.0/22 > 204.174.48.0/23 > 204.174.52.0/23 > 204.174.76.0/22 > 204.174.204.0/23 > 204.187.50.0/23 > 204.187.52.0/23 > 204.187.96.0/23 > 204.187.106.0/23 > 204.187.108.0/22 > 204.187.112.0/22 > 204.187.116.0/23 > 204.194.16.0/22 > 204.194.48.0/21 > 204.194.192.0/21 > 204.194.200.0/22 > 204.194.208.0/22 > 204.194.216.0/22 > 204.194.220.0/23 > 204.209.30.0/23 > 204.209.86.0/23 > 204.225.184.0/23 > 204.225.226.0/23 > 204.225.234.0/23 > 204.231.242.0/23 > 204.231.244.0/23 > 204.239.126.0/23 > 204.239.176.0/23 > 204.239.192.0/23 > 204.239.200.0/23 > 205.132.88.0/22 > 205.132.92.0/23 > 205.132.136.0/21 > 205.132.152.0/21 > 205.142.4.0/23 > 205.142.32.0/22 > 205.142.40.0/22 > 205.142.68.0/22 > 205.142.84.0/22 > 205.142.132.0/22 > 205.142.136.0/22 > 205.142.140.0/22 > 205.142.144.0/22 > 205.142.160.0/22 > 205.142.204.0/22 > 205.142.208.0/22 > 205.142.212.0/22 > 205.143.8.0/21 > 205.143.56.0/21 > 205.153.4.0/22 > 205.153.32.0/22 > 205.153.72.0/22 > 205.153.108.0/22 > 205.153.124.0/22 > 205.153.132.0/22 > 205.153.164.0/22 > 205.153.168.0/22 > 205.153.184.0/22 > 205.153.200.0/22 > 205.153.216.0/22 > 205.153.252.0/22 > 205.167.12.0/23 > 205.167.20.0/23 > 205.167.32.0/23 > 205.167.38.0/23 > 205.167.50.0/23 > 205.167.66.0/23 > 205.167.72.0/23 > 205.167.82.0/23 > 205.167.98.0/23 > 205.167.112.0/23 > 205.167.160.0/23 > 205.167.172.0/23 > 205.167.178.0/23 > 205.167.190.0/23 > 205.167.194.0/23 > 205.167.204.0/23 > 205.167.228.0/23 > 205.167.236.0/23 > 205.167.246.0/23 > 205.172.32.0/22 > 205.172.36.0/22 > 205.172.116.0/22 > 205.172.120.0/21 > 205.172.128.0/22 > 205.172.140.0/22 > 205.172.152.0/22 > 205.172.176.0/22 > 205.172.244.0/22 > 205.172.252.0/22 > 205.173.184.0/21 > 205.189.74.0/23 > 205.189.78.0/23 > 205.189.118.0/23 > 205.189.120.0/23 > 205.189.222.0/23 > 205.189.224.0/23 > 206.53.128.0/21 > 206.82.96.0/21 > 206.208.72.0/21 > 206.220.0.0/22 > 207.45.96.0/21 > > From alexb at ripe.net Sun Oct 3 12:06:10 2010 From: alexb at ripe.net (Alex Band) Date: Sun, 3 Oct 2010 19:06:10 +0200 Subject: RPKI Resource Certification: building features Message-ID: <43675D42-4C2C-4B16-A4DF-46F53DF6E8F7@ripe.net> Most of the discussions around RPKI Resource Certification that have been held up to now have largely revolved around infrastructure and policy topics. I would like to move away from that here and discuss what kind of value and which features can be offered with Certification for network administrators around the world. Because in the end, the goal is to make Internet routing more robust and create a more reliable method for network operators to make routing decisions. We all know about the shortcomings of the IRR system and that just half of all prefixes on the Internet have a route object associated with them (http://bgpmon.net/blog/?p=140). However, it does mean that there is ton of valuable information in the IRRs, whereas the Certification system needs to start from scratch. Based on many discussion I've had with members and the Community, here is my idea for a Route Origin Authorisation** (ROA) wizard that retrieves IRR information, compares it to real world routing and uses that for the creation of ROA Specifications. This has a number of benefits: - Network operators don't have to create their routing policy in the Certification system from scratch - Because a comparison between is done the IRR and RIS (http://ripe.net/ris/), only accurate up-to-date information is added to the Certification system - The accuracy of the IRR is increased as a bonus, and is achieved without leaving the wizard Ideally, a network operator should be able to manage and publish their routing policy ? both for the IRR and Certification ? from one single interface. Here are the basic steps for the wizard after a certificate is generated: 1. Start ROA Wizard 2. Detect IRR information using the AS numbers in the Certificate, like for example: http://www.db.ripe.net/whois?searchtext=AS286&inverse_attributes=origin&form_type=simple 3: Compare results with RIS using RRCC/Netsense, like for example: http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=AS286 4: Allow user to flag which ROA specifications they would actually like to create, based on the IRR and RRCC/Netsense results. 5: Allow user to create additional ROA Specifications 6: Detect which maintainer is used for the route objects in the IRR 7: Allow user to specify maintainer password/pgp key, so all route objects are updated/removed/added based on the ROAs that were created. This makes sure the data in the IRR and the Certification system is consistent. 8: Save and publish ROAs and route objects Do you think there is value in creating a system like this? Are there any glaring holes that I missed, or something that could be added? I'm looking forward to your feedback. Alex Band RIPE NCC http://ripe.net/certification ** The certification system largely revolves around three main elements: (1) the Certificate, that offers validated proof of holdership of an Internet Resource, (2) the Route Orgin Authorisation Object (ROA), a standardised document that states that the holder of a certain prefix authorises a particular AS to announce that prefix and (3) the Validator, which relying parties, i.e. your peers, can use to validate certificates and ROAs. From rekoil at semihuman.com Sun Oct 3 14:26:22 2010 From: rekoil at semihuman.com (Chris Woodfield) Date: Sun, 3 Oct 2010 12:26:22 -0700 Subject: router lifetime In-Reply-To: References: , <6672656.613.1286064555265.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: Ability to route IPv6 != ability to route IPv6 as well as IPv4. Depending on the hardware, there will always be unavoidable tradeoffs, which tend to be either in reduced throughput capacity, typically noticed on particularly on software-switching platforms, or the number of routes/ACLs/etc you can put in the CAM of a hardware-switching box. Most hardware sold today has plenty of headroom to do both, but don't forget that flinging v6 packets around is inherently more resource-intensive than flinging v4. -C On Oct 2, 2010, at 6:22 27PM, Brandon Kim wrote: > > Well a lot of routers even 3 years ago support IPv6. You can dual-stack pretty much any router today if you have > the right IOS. But I do understand your concern, if you want to future proof your purchase, I'd think any modern > router today with a good support contract will take care of you for quite some time. > Make sure it's not close to EOL. > > What kind of router are you considering? Is this for a large network? What are the network needs? > > > >> Date: Sat, 2 Oct 2010 17:09:20 -0700 >> From: franck at genius.com >> To: nanog at nanog.org >> Subject: Re: router lifetime >> >> I'm looking at various scenario, but basically it is looking at IPv6 in fact. >> >> It seems to me, that using a router/network appliance today for IPv6 will need to be replaced in 3 years or less. >> >> Looking at past, anything older than 3 years is not a viable solution for deploying IPv6. >> >> So I feel that routing/network appliance equipment have a life cycle similar to a PC, despite the fact as someone pointed out, they will run fine for many many years. >> >> ----- Original Message ----- >> From: "Heath Jones" >> To: "Franck Martin" >> Cc: nanog at nanog.org >> Sent: Saturday, 2 October, 2010 4:34:40 PM >> Subject: Re: router lifetime >> >>> How long do you keep a router in production? >>> What is your cycle for replacement of equipment? >> >> Hi Franck >> >> It really depends on the type of network you are running, the rate at >> which new features & bandwidth are required, and the availability of >> software and hardware upgrades. Also, in a lot of cases it is vendor >> driven - devices that are still very much in production are forced to >> be replaced because of vendor product lifecycle and the phasing out of >> support, even when serving their requirements well. >> >> >> Care to elaborate a little more on your planned scenario? >> >> >> Cheers >> Heath >> > From jcurran at arin.net Sun Oct 3 15:19:11 2010 From: jcurran at arin.net (John Curran) Date: Sun, 3 Oct 2010 16:19:11 -0400 Subject: NEVERMIND! (was: ARIN Fraud Reporting Form ... ) Message-ID: <2FB9DEB1-95B5-4A26-8723-35F157F98807@arin.net> On Oct 3, 2010, at 7:24 AM, "Ronald F. Guilmette" wrote: > I'm sitting here looking at your NRPM 3.6 and it says: > > Unresponsive POC email addresses shall be marked as such in the database. > > OK, Fine. So do you have a problem with ``marking those in the data base'' > and specifically within the associated AS and IP block records? And if so why? There is no problem with also marking resource records which have no valid POC's (even if not specifically stated by policy). It is an operational question not a resource policy question, and we generally handle those by informing the community of the plans to change practices through the ARIN consultation and suggestion process (https://www.arin.net/participate/acsp/index.html) > And if you have a problem with that, they please explain when and why you > suddenly developed a problem with it, because clearly ARIN _was_ doing this > before, at some point. (And it sure looks like you are NOT doing it now.) > > I'd really like to know when and why ARIN stopped putting these annotations > into the AS and IP block records associated with un-contactable POCs. > > Can you just answer me that? I mean, you know, without directing my > attention to some document which also doesn't answer the question? Amazingly, you are my customer; i.e. I do indeed work for you and the rest of the community. So, I'm happy to try and address your questions (even if at times it appears more of an inquisition than constructive engagement...) The ARIN staff has been putting those notations in manually for net blocks which lack valid contacts, but doing so is not required by policy and has been resource intensive since the contact verification portion was manual. We are now looking (as a result of your fine suggestion) at automating this process of marking resource blocks with no valid contacts as an inherent part of the new automated POC verification process. /John John Curran President & CEO ARIN From rfg at tristatelogic.com Sun Oct 3 17:01:37 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 03 Oct 2010 15:01:37 -0700 Subject: NEVERMIND! (was: ARIN Fraud Reporting Form ... ) In-Reply-To: <2FB9DEB1-95B5-4A26-8723-35F157F98807@arin.net> Message-ID: <33687.1286143297@tristatelogic.com> In message <2FB9DEB1-95B5-4A26-8723-35F157F98807 at arin.net>, John Curran wrote: >There is no problem with also marking resource records which have no valid >POC's (even if not specifically stated by policy). It is an operational qu >estion >not a resource policy question, and we generally handle those by informing >the >community of the plans to change practices through the ARIN consultation >and suggestion process (https://www.arin.net/participate/acsp/index.html) Ok, and so that part... the ``informing the community'' part... has been done already, correct? Because you folks _were_ installing those annotations before, right? So there is no new or additional bureaucratic hurdle to cross here, yes? >Amazingly, you are my customer; i.e. I do indeed work for you and the rest Well, yes, actually, I knew that. But I'm not your _direct_ customer, and I'm aware of that, and what I think may be the probable implications of that also. (POTUS, in theory, also works for me, but as far as I can tell, he doesn't give two shakes about _my_ little opinion.) >of the community. So, I'm happy to try and address your questions (even if >at times it appears more of an inquisition than constructive engagement...) That's a fair comment, and I apologize for the tone. But I think you probably understand John and that (a) you _did_ elect to step into the conversation when I was already ranting and raving and also (b) that I'm mad as hell about what these low-life scum hijackers seem to be getting away with, and you just happen to be the closest target for my wrath at the moment (*and* also you're the only person I know who might have the ability to materially affect the outcome of this hijacking problem, long term). >The ARIN staff has been putting those notations in manually for net blocks >which lack valid contacts, but doing so is not required by policy and has >been resource intensive since the contact verification portion was manual. OK. Yea. But follow along with me here for a moment... What you are doing now, which I think is rather obviously going to be highly resource-intensive, is you folks are, apparently, working to make contact with POCs, and failing that, you are putting the ``can't contact'' annotation into the POC records. OK, I grant you, this all may be labor intensive... although to the extent that you're doing the POC validation/verification just via e-mail, it would seem that even this part of the process could be rather entirely automated (but of course, that also would take work... to get that process automated). But now we are talking about something altogether different, i.e. sweeping through the AS and IP block records within your data base, and then, for each one, just doing a fetch on the assocated POC record(s) and then checking those to see if they _already_ have the ``cannot contact'' annotation in them, and then, if they do, just putting that other style of ``this may not be kosher'' annotation into the associated AS or IP block record. This is what I said I think I could do in Perl in a half an hour. This part certainly doesn't have to be labor intensive. It is readily amenable to complete automation, and if you are trying to do this part of the process in any sort of ``labor intensive'' manner, then I would argue that you aren't doing it right. (Of course, that's just one man's opinion, but it is an informed opinion, because I actually _am_ a software engineer, and I've successfully automated a lot of things, over time.) >We are now looking (as a result of your fine suggestion) at automating >this process of marking resource blocks with no valid contacts as an >inherent part of the new automated POC verification process. OK, well, that is a profoundly Good Thing, in my opinion. And if I had any real brains, I'd quit now, while I'm ahead. But... I have to tell you that what you just said reminds me of a really funny story that an old friend of mine told me... Thirty years ago, I was working for some hardware company or another down in silicon valley, and my good friend Kurt was working for a little hole-in-the-wall company of about 15 people or so that built and sold PDP-11 clones, based upon DEC's LSI-11 chip. (He apparently actually witnessed this.) One day, a VERY irate customer of the company called up and asked to speak to the service manager... another guy at the commany named Everett, who was a good friend of Kurt's. So Everett gets on the phone with the irate customer, and the customer is screaming at him... ``God dammit! I sent in my board for RMA six weeks ago! So where the hell is it???'' So Everett says ``I don't know. If you'll hang on a minute, I'll go and check.'' So then Everett goes way way back in the back room, way behind the resoldering stations, back to the very back of the place, and there, underneath a dusty old work table with a bunch of unused crap old spare parts lying on top of it, Everett sees the customer's board, with the RMA tag on it, and the thing is covered in cobwebs, because it has been sitting there being ignored for so long. So what does he do? Well, Everett grabs the board, dusts it off, and gets back on the phone with the irate customer. But before he says anything, he motions to one of the mimimum-wage line workers to come over to where he is standing. So the guy comes over, and Everett points at the board. Naturally, the line worker looks at the board. So then Everett gets back on the phone with the irate customer and says ``Yea, we got a guy looking at that right now.'' :-) Sorry. For the last thirty+ years, every time somebody tells me that they are ``looking at'' something, I am reminded of that story. I'm going to try to shut up now, and I'm going to try to be a little patient, although it is quite obviously not my nature. But this whole hijacking problem quite obviously isn't going away anytime soon, and so I feel quite sure that the hijackers will give me a reason to keep watching and see if you've managed to follow through on getting these annotations into the AS and IP block records, where they'll do the most good. Obviously, my hope is that it won't take that long, because as I've also made clear, it doesn't appear to me to be a very hard problem, technically anyway. All that seems to be required is a willingness to go and do it. Regards, rfg From bmanning at vacation.karoshi.com Sun Oct 3 17:59:09 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Sun, 3 Oct 2010 22:59:09 +0000 Subject: closing 'lazy mans NW research" Message-ID: <20101003225909.GA28478@vacation.karoshi.com.> I ask: On Wed, Sep 29, 2010 at 5:47 PM, wrote: > i find myself in need of a multiport (8-16) 1 Gig ethernet HUB. > or a switch smart enough to do transparant port mirroring to at least > four ports. and the following suggestions were made: http://www.datacomsystems.com/products/details.asp?prod=5&itm=1&cat=3 http://www.dual-comm.com/gigabit_port-mirroring-LAN_switch.htm http://www.netoptics.com/products/product_family_details.asp?cid=1&pid=54&Section=products&menuitem=1 ftp://ftp2.zyxel.com/GS-1524/user_guide/GS-1524_1.12_Ed2.pdf Of these, it looks like the datacomsystems.com tap will be a good fit. --bill From randy at psg.com Sun Oct 3 21:26:27 2010 From: randy at psg.com (Randy Bush) Date: Mon, 04 Oct 2010 11:26:27 +0900 Subject: [ncc-services-wg] RPKI Resource Certification: building features In-Reply-To: References: Message-ID: > Do you think there is value in creating a system like this? yes. though, given issues of errors and deliberate falsifications, i am not entirely comfortable with the whois/bgp combo being considered formally authoritative. but we have to do something. > Are there any glaring holes that I missed yes. the operator should be able to hold the private key to their certificate(s) or the meaning of 'private key' and the security structure of the [ripe part of the] rpki is a broken. randy From owen at delong.com Sun Oct 3 21:38:52 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 3 Oct 2010 19:38:52 -0700 Subject: [ncc-services-wg] RPKI Resource Certification: building features In-Reply-To: References: Message-ID: <76B62F3C-730C-4E20-A83B-5AFD41A851A7@delong.com> On Oct 3, 2010, at 7:26 PM, Randy Bush wrote: >> Do you think there is value in creating a system like this? > > yes. though, given issues of errors and deliberate falsifications, i am > not entirely comfortable with the whois/bgp combo being considered > formally authoritative. but we have to do something. > >> Are there any glaring holes that I missed > > yes. the operator should be able to hold the private key to their > certificate(s) or the meaning of 'private key' and the security > structure of the [ripe part of the] rpki is a broken. > > randy I'll go a step further and say that the resource holder should be the ONLY holder of the private key for their resources. Owen From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sun Oct 3 21:49:16 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Mon, 4 Oct 2010 13:19:16 +1030 Subject: router lifetime In-Reply-To: References: <6672656.613.1286064555265.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <20101004131916.221827d2@opy.nosense.org> On Sat, 2 Oct 2010 22:27:32 -0300 jim deleskie wrote: > If you can do a business case to support replacing routers every 3years you > doing much better then most. IMO a router should last 5 yrs on the book, > but I expect to get more life then then from it. You core today > is tomorrow's edge. I've seen more then one network with 10 yo kit still > being used. > Agree. If you're large enough to have your own pool of replacement hardware for anything critical, then using it until it fails isn't a bad strategy. That being said, support for fixing of software security bugs has probably shortened the production life of a lot of perfectly useful hardware. One risk people haven't mentioned is the risk of leaving it in production so long that people think it is fake ;-) http://groups.google.com.au/group/comp.dcom.sys.cisco/browse_thread/thread/7f74397a10380a7a/66c3dfb0f280e830?hl=enBc3dfb0f280e830 > -jim > > On Sat, Oct 2, 2010 at 10:22 PM, Brandon Kim wrote: > > > > > Well a lot of routers even 3 years ago support IPv6. You can dual-stack > > pretty much any router today if you have > > the right IOS. But I do understand your concern, if you want to future > > proof your purchase, I'd think any modern > > router today with a good support contract will take care of you for quite > > some time. > > Make sure it's not close to EOL. > > > > What kind of router are you considering? Is this for a large network? What > > are the network needs? > > > > > > > > > Date: Sat, 2 Oct 2010 17:09:20 -0700 > > > From: franck at genius.com > > > To: nanog at nanog.org > > > Subject: Re: router lifetime > > > > > > I'm looking at various scenario, but basically it is looking at IPv6 in > > fact. > > > > > > It seems to me, that using a router/network appliance today for IPv6 will > > need to be replaced in 3 years or less. > > > > > > Looking at past, anything older than 3 years is not a viable solution for > > deploying IPv6. > > > > > > So I feel that routing/network appliance equipment have a life cycle > > similar to a PC, despite the fact as someone pointed out, they will run fine > > for many many years. > > > > > > ----- Original Message ----- > > > From: "Heath Jones" > > > To: "Franck Martin" > > > Cc: nanog at nanog.org > > > Sent: Saturday, 2 October, 2010 4:34:40 PM > > > Subject: Re: router lifetime > > > > > > > How long do you keep a router in production? > > > > What is your cycle for replacement of equipment? > > > > > > Hi Franck > > > > > > It really depends on the type of network you are running, the rate at > > > which new features & bandwidth are required, and the availability of > > > software and hardware upgrades. Also, in a lot of cases it is vendor > > > driven - devices that are still very much in production are forced to > > > be replaced because of vendor product lifecycle and the phasing out of > > > support, even when serving their requirements well. > > > > > > > > > Care to elaborate a little more on your planned scenario? > > > > > > > > > Cheers > > > Heath > > > > > > > From rdobbins at arbor.net Sun Oct 3 21:51:04 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 4 Oct 2010 02:51:04 +0000 Subject: Request for participation - Arbor 2010 Worldwide Infrastructure Security Report. Message-ID: <166C3AA0-8A84-4919-BBB0-DD9BF2312B22@arbor.net> Request for participation - Arbor 2010 Worldwide Infrastructure Security Report. ----- Folks, We're in the process of collecting feedback for the 2010 Worldwide Infrastructure Security Report (WWISR); this is the Sixth Edition of the report, and we'd really be grateful for your participation! This is the only security-focused survey we're aware of which is specifically oriented towards those who design, build, operate, and defend public-facing network infrastructure/applications/services, and provides the opportunity to share your experiences and perspectives with your peers in the operational community, as well as to benefit from their experiences and perspectives. The 2010 Infrastructure Security Survey is up and available for your input. You can register to complete the survey via this URL, which will redirect your browser to the survey tool (the survey is accessed via http/s): Once again, we've added several insightful questions from past participants. Feedback collection will end as soon as we've reached the desired number of respondents (ideally, 100+). The results will be published in the 2010 Worldwide Infrastructure Security Report in January of 2011. Also, please note that NO personally- or organizationally-identifiable information will be shared in any manner. The 2009 edition of the survey is available here (registration required): Thanks in advance! ----- ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From alexb at ripe.net Mon Oct 4 03:29:50 2010 From: alexb at ripe.net (Alex Band) Date: Mon, 4 Oct 2010 10:29:50 +0200 (CEST) Subject: [ncc-services-wg] RPKI Resource Certification: building features In-Reply-To: <76B62F3C-730C-4E20-A83B-5AFD41A851A7@delong.com> References: <76B62F3C-730C-4E20-A83B-5AFD41A851A7@delong.com> Message-ID: <56603.2001:67c:2e8:13:223:6cff:fe97:77dc.1286180990.squirrel@webmail.ripe.net> On Mon, October 4, 2010 04:38, Owen DeLong wrote: > > On Oct 3, 2010, at 7:26 PM, Randy Bush wrote: > >>> Do you think there is value in creating a system like this? >> >> yes. though, given issues of errors and deliberate falsifications, i am >> not entirely comfortable with the whois/bgp combo being considered >> formally authoritative. but we have to do something. But blindly considering whois/BGP authoritative is not what I am proposing. I want to confront the network operator with what is registered in the IRR and what is seen in BGP, and let the human element make decisions and corrections, improving data quality in the process. >>> Are there any glaring holes that I missed >> >> yes. the operator should be able to hold the private key to their >> certificate(s) or the meaning of 'private key' and the security >> structure of the [ripe part of the] rpki is a broken. >> >> randy In the hosted implementation the RIPE NCC currently has, only a registered contact for an LIR with whom we have a business relationship has access to the secured LIR Portal in which the Certification system is embedded. The reason to offer a hosted system initially, is to take away the burden from an LIR of having to run their own Certificate Authority. We offer a service that makes the entry barrier for Certification as low as possible. Properly running your own CA, with all the crypto aspects, is no small feat for a lot of LIRs (technically, but perhaps more psychologically). You may argue that it's easy and cheap to do yourself, but just look at adoption rates and levels of IPv6 and DNSSEC *at an LIR level* to see what reality is like. After the production launch on 1 January 2011, the next step we will take is to implement the up/down protocol, allowing people to run their own Certificate Authority if they choose to do so. We plan to roll this out in the first half of 2011. We'll go one step further by having our software certified by an external independent company, and releasing it as open source to the Community, so they can be sure they adopt a robust system if they choose our package. So in the end our implementation is not 'broken' as you say, it is in he middle of a planned, phased approach. Not everything is possible yet and that is a deliberate decision. > I'll go a step further and say that the resource holder should be > the ONLY holder of the private key for their resources. > > Owen If you're saying that ISPs can only participate in an RPKI scheme if they run their own Certificate Authority, then I think that would practically ruin the chances of Certification actually ever taking off on a large scale. -Alex From alexb at ripe.net Mon Oct 4 03:54:50 2010 From: alexb at ripe.net (Alex Band) Date: Mon, 4 Oct 2010 10:54:50 +0200 Subject: RPKI Resource Certification: building features In-Reply-To: <43675D42-4C2C-4B16-A4DF-46F53DF6E8F7@ripe.net> References: <43675D42-4C2C-4B16-A4DF-46F53DF6E8F7@ripe.net> Message-ID: The thread got a bit torn apart due to some cross posting, so here are Randy and Owen's replies to keep it all together: On Oct 3, 2010, at 7:26 PM, Randy Bush wrote: >> Do you think there is value in creating a system like this? > > yes. though, given issues of errors and deliberate falsifications, i > am not entirely comfortable with the whois/bgp combo being > considered formally authoritative. but we have to do something. >> Are there any glaring holes that I missed > > yes. the operator should be able to hold the private key to their > certificate(s) or the meaning of 'private key' and the security > structure of the [ripe part of the] rpki is a broken. > randy I'll go a step further and say that the resource holder should be the ONLY holder of the private key for their resources. Owen On 3 Oct 2010, at 19:06, Alex Band wrote: > Most of the discussions around RPKI Resource Certification that have > been held up to now have largely revolved around infrastructure and > policy topics. I would like to move away from that here and discuss > what kind of value and which features can be offered with > Certification for network administrators around the world. Because > in the end, the goal is to make Internet routing more robust and > create a more reliable method for network operators to make routing > decisions. > > We all know about the shortcomings of the IRR system and that just > half of all prefixes on the Internet have a route object associated > with them (http://bgpmon.net/blog/?p=140). However, it does mean > that there is ton of valuable information in the IRRs, whereas the > Certification system needs to start from scratch. Based on many > discussion I've had with members and the Community, here is my idea > for a Route Origin Authorisation** (ROA) wizard that retrieves IRR > information, compares it to real world routing and uses that for the > creation of ROA Specifications. This has a number of benefits: > > - Network operators don't have to create their routing policy in the > Certification system from scratch > - Because a comparison between is done the IRR and RIS (http://ripe.net/ris/ > ), only accurate up-to-date information is added to the > Certification system > - The accuracy of the IRR is increased as a bonus, and is achieved > without leaving the wizard > > Ideally, a network operator should be able to manage and publish > their routing policy ? both for the IRR and Certification ? from one > single interface. > > Here are the basic steps for the wizard after a certificate is > generated: > > 1. Start ROA Wizard > > 2. Detect IRR information using the AS numbers in the Certificate, > like for example: > http://www.db.ripe.net/whois?searchtext=AS286&inverse_attributes=origin&form_type=simple > > 3: Compare results with RIS using RRCC/Netsense, like for example: > http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=AS286 > > 4: Allow user to flag which ROA specifications they would actually > like to create, based on the IRR and RRCC/Netsense results. > > 5: Allow user to create additional ROA Specifications > > 6: Detect which maintainer is used for the route objects in the IRR > > 7: Allow user to specify maintainer password/pgp key, so all route > objects are updated/removed/added based on the ROAs that were > created. This makes sure the data in the IRR and the Certification > system is consistent. > > 8: Save and publish ROAs and route objects > > Do you think there is value in creating a system like this? Are > there any glaring holes that I missed, or something that could be > added? I'm looking forward to your feedback. > > Alex Band > RIPE NCC > http://ripe.net/certification > > > ** The certification system largely revolves around three main > elements: (1) the Certificate, that offers validated proof of > holdership of an Internet Resource, (2) the Route Orgin > Authorisation Object (ROA), a standardised document that states that > the holder of a certain prefix authorises a particular AS to > announce that prefix and (3) the Validator, which relying parties, > i.e. your peers, can use to validate certificates and ROAs. > From alexb at ripe.net Mon Oct 4 04:04:19 2010 From: alexb at ripe.net (Alex Band) Date: Mon, 4 Oct 2010 11:04:19 +0200 Subject: RPKI Resource Certification: building features In-Reply-To: References: <43675D42-4C2C-4B16-A4DF-46F53DF6E8F7@ripe.net> Message-ID: And here is my reply to them... On Mon, October 4, 2010 04:38, Owen DeLong wrote: > > On Oct 3, 2010, at 7:26 PM, Randy Bush wrote: > >>> Do you think there is value in creating a system like this? >> >> yes. though, given issues of errors and deliberate falsifications, >> i am >> not entirely comfortable with the whois/bgp combo being considered >> formally authoritative. but we have to do something. But blindly considering whois/BGP authoritative is not what I am proposing. I want to confront the network operator with what is registered in the IRR and what is seen in BGP, and let the human element make decisions and corrections, improving data quality in the process. >>> Are there any glaring holes that I missed >> >> yes. the operator should be able to hold the private key to their >> certificate(s) or the meaning of 'private key' and the security >> structure of the [ripe part of the] rpki is a broken. >> >> randy In the hosted implementation the RIPE NCC currently has, only a registered contact for an LIR with whom we have a business relationship has access to the secured LIR Portal in which the Certification system is embedded. The reason to offer a hosted system initially, is to take away the burden from an LIR of having to run their own Certificate Authority. We offer a service that makes the entry barrier for Certification as low as possible. Properly running your own CA, with all the crypto aspects, is no small feat for a lot of LIRs (technically, but perhaps more psychologically). You may argue that it's easy and cheap to do yourself, but just look at adoption rates and levels of IPv6 and DNSSEC *at an LIR level* to see what reality is like. After the production launch on 1 January 2011, the next step we will take is to implement the up/down protocol, allowing people to run their own Certificate Authority if they choose to do so. We plan to roll this out in the first half of 2011. We'll go one step further by having our software certified by an external independent company, and releasing it as open source to the Community, so they can be sure they adopt a robust system if they choose our package. So in the end our implementation is not 'broken' as you say, it is in he middle of a planned, phased approach. Not everything is possible yet and that is a deliberate decision. > I'll go a step further and say that the resource holder should be > the ONLY holder of the private key for their resources. > > Owen If you're saying that ISPs can only participate in an RPKI scheme if they run their own Certificate Authority, then I think that would practically ruin the chances of Certification actually ever taking off on a large scale. -Alex On 4 Oct 2010, at 10:54, Alex Band wrote: > The thread got a bit torn apart due to some cross posting, so here > are Randy and Owen's replies to keep it all together: > > On Oct 3, 2010, at 7:26 PM, Randy Bush wrote: >>> Do you think there is value in creating a system like this? >> >> yes. though, given issues of errors and deliberate falsifications, >> i am not entirely comfortable with the whois/bgp combo being >> considered formally authoritative. but we have to do something. >>> Are there any glaring holes that I missed >> >> yes. the operator should be able to hold the private key to their >> certificate(s) or the meaning of 'private key' and the security >> structure of the [ripe part of the] rpki is a broken. >> randy > I'll go a step further and say that the resource holder should be > the ONLY holder of the private key for their resources. > Owen > > On 3 Oct 2010, at 19:06, Alex Band wrote: > >> Most of the discussions around RPKI Resource Certification that >> have been held up to now have largely revolved around >> infrastructure and policy topics. I would like to move away from >> that here and discuss what kind of value and which features can be >> offered with Certification for network administrators around the >> world. Because in the end, the goal is to make Internet routing >> more robust and create a more reliable method for network operators >> to make routing decisions. >> >> We all know about the shortcomings of the IRR system and that just >> half of all prefixes on the Internet have a route object associated >> with them (http://bgpmon.net/blog/?p=140). However, it does mean >> that there is ton of valuable information in the IRRs, whereas the >> Certification system needs to start from scratch. Based on many >> discussion I've had with members and the Community, here is my idea >> for a Route Origin Authorisation** (ROA) wizard that retrieves IRR >> information, compares it to real world routing and uses that for >> the creation of ROA Specifications. This has a number of benefits: >> >> - Network operators don't have to create their routing policy in >> the Certification system from scratch >> - Because a comparison between is done the IRR and RIS (http://ripe.net/ris/ >> ), only accurate up-to-date information is added to the >> Certification system >> - The accuracy of the IRR is increased as a bonus, and is achieved >> without leaving the wizard >> >> Ideally, a network operator should be able to manage and publish >> their routing policy ? both for the IRR and Certification ? from >> one single interface. >> >> Here are the basic steps for the wizard after a certificate is >> generated: >> >> 1. Start ROA Wizard >> >> 2. Detect IRR information using the AS numbers in the Certificate, >> like for example: >> http://www.db.ripe.net/whois?searchtext=AS286&inverse_attributes=origin&form_type=simple >> >> 3: Compare results with RIS using RRCC/Netsense, like for example: >> http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=AS286 >> >> 4: Allow user to flag which ROA specifications they would actually >> like to create, based on the IRR and RRCC/Netsense results. >> >> 5: Allow user to create additional ROA Specifications >> >> 6: Detect which maintainer is used for the route objects in the IRR >> >> 7: Allow user to specify maintainer password/pgp key, so all route >> objects are updated/removed/added based on the ROAs that were >> created. This makes sure the data in the IRR and the Certification >> system is consistent. >> >> 8: Save and publish ROAs and route objects >> >> Do you think there is value in creating a system like this? Are >> there any glaring holes that I missed, or something that could be >> added? I'm looking forward to your feedback. >> >> Alex Band >> RIPE NCC >> http://ripe.net/certification >> >> >> ** The certification system largely revolves around three main >> elements: (1) the Certificate, that offers validated proof of >> holdership of an Internet Resource, (2) the Route Orgin >> Authorisation Object (ROA), a standardised document that states >> that the holder of a certain prefix authorises a particular AS to >> announce that prefix and (3) the Validator, which relying parties, >> i.e. your peers, can use to validate certificates and ROAs. >> > > > From owen at delong.com Mon Oct 4 04:59:53 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Oct 2010 02:59:53 -0700 Subject: [ncc-services-wg] RPKI Resource Certification: building features In-Reply-To: <56603.2001:67c:2e8:13:223:6cff:fe97:77dc.1286180990.squirrel@webmail.ripe.net> References: <76B62F3C-730C-4E20-A83B-5AFD41A851A7@delong.com> <56603.2001:67c:2e8:13:223:6cff:fe97:77dc.1286180990.squirrel@webmail.ripe.net> Message-ID: > >> I'll go a step further and say that the resource holder should be >> the ONLY holder of the private key for their resources. >> >> Owen > > If you're saying that ISPs can only participate in an RPKI scheme if they > run their own Certificate Authority, then I think that would practically > ruin the chances of Certification actually ever taking off on a large > scale. > > -Alex No... I'm saying that if ISPs aren't the only entities that hold their private keys, then they aren't the only entities that can sign their resources. If you choose to delegate the CA role for signing your resources to someone else, then, obviously, you have to give them a valid private key with which to sign those resources. However, in doing that, you've created a situation where your signature is now much easier to forge. Kind of like automatic signing machines for checks. Benefit: The accounting department can sign thousands of checks and the CFO doesn't have to. Draw-back... The accounting department can sign thousands of checks without the CFO knowing they did so. Owen From owen at delong.com Mon Oct 4 07:03:26 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Oct 2010 05:03:26 -0700 Subject: [ncc-services-wg] RPKI Resource Certification: building features In-Reply-To: <4CA9BD07.9020901@ripe.net> References: <76B62F3C-730C-4E20-A83B-5AFD41A851A7@delong.com> <56603.2001:67c:2e8:13:223:6cff:fe97:77dc.1286180990.squirrel@webmail.ripe.net> <4CA9BD07.9020901@ripe.net> Message-ID: <1AF7E02F-3EA0-4DBB-AF53-D87210996928@delong.com> >> >> No... I'm saying that if ISPs aren't the only entities that hold their >> private keys, then they aren't the only entities that can sign their >> resources. > > The hosted system that we created uses Hardware Signing Modules (HSM) > for generating keys and signing operations. By design it is impossible > to retrieve the private keys. Any process or feature that would involve > the transferral of keys cannot be implemented. > In other words, not only do you hold the resource holders private key, but, they do not. This means that the ability to sign their resources is 100% under your control and 0% under their control except to the extent that you allow it. While I'm not accusing RIPE of nefarious conduct and do not believe that there is any malicious intent in the system, I do believe that it is a security model that any rational provider would likely consider untenable. The fact that you cannot retrieve the key is of little relevance, since you have full use of the key without retrieving it. > Access to the *use* of the keys is a different thing though. This is > controlled by the software. Although we cannot extract the keys, we can > instruct the HSM to create a new key, or use an existing key to sign > something. > Exactly... > Our hosted software controls all (activated) hosted member certificate > authorities. The process has potential access to the *use* of *all* keys > in the system. However, other security layers are implemented to ensure > that for a given LIR only those users that have the 'certification' > group enabled are *authorised* to use the hosted system -- and thereby > the applicable keys. > But by the very nature, the administrators of the system have the ability to make themselves members of the certification group. While I'm not saying that I think RIPE would do such a thing, the reality is that using this hosted solution is placing a tremendous amount of trust in the system and the administrators of the system. I have no problem with LIRs that choose to do this, so long as they are making an informed decision and understand the risks. I think the risks have been substantially down-played. >> >> If you choose to delegate the CA role for signing your resources >> to someone else, then, obviously, you have to give them a valid >> private key with which to sign those resources. >> > > > Given this setup a member can authorise any person to use the system by > creating an LIR Portal account for them and enabling the certification > group. Only the LIR's admin user can do this. > Really? There's no way for any member of RIPE staff to make corrections to an LIR's admin account such that it would be possible to bypass this? I tend to doubt that any sustainable system could be built in such a manner. Again, I am not accusing RIPE of doing so, but, pointing out that for such a hosted solution to remain functional over time, there must be certain compromises in the trust model. These compromises should at least give one pause and be carefully considered prior to handing over that level of trust. >> However, in doing that, you've created a situation where your >> signature is now much easier to forge. Kind of like automatic >> signing machines for checks. Benefit: The accounting department >> can sign thousands of checks and the CFO doesn't have to. >> Draw-back... The accounting department can sign thousands of >> checks without the CFO knowing they did so. >> > > The current system has an audit history page that shows all the commands > executed by users. It includes details like the name of the user, the > time of the change and further details: e.g. in case of the modification > of a ROA specification the complete new specification is visible in the > history. > So at least if someone does something horrible, assuming the system integrity is not compromised in the process, we can tell what happened and either who did it, or, at least who they chose to impersonate. That's good, but, by itself it is not enough. > There is currently no additional notification mechanism implemented but > that would be fairly trivial to add if there is a demand. > That would be a good additional safety feature. > > Non-hosted: > ===== > > Of course we put a lot of effort into maintaining security and quality > of the implementation we built. But we can well imagine that for some > people it is a matter of principle that they want full local access to > their own private keys and important configuration objects such as ROAs > -- and don't want to be hosted on a shared system outside of their > control. Other members may not mind so much about this and choose to > trust and use the hosted services. > Exactly my point... Such a choice should be an informed decision and if it is not a matter of choice made by the organization holding the resource (as is currently the case), then, there are issues. > There is standard that is close to completion in the SIDR WG in the IETF > that defines a protocol by which a parent and child Certificate > Authority can communicate. > > http://tools.ietf.org/html/draft-ietf-sidr-rescerts-provisioning-06 > Which is a major step forward in this area. > In our case the RIPE NCC system could function as the parent CA for a > non-hosted LIR child CA. The LIR can then deploy anything they see fit > themselves. They would have full access to their own private keys and > everything else in their system and can delegate as they see fit. And > add new features of course. > Another alternative in the meantime would be for the resource holder to maintain their private key and have transactions accomplished through a CSR process, but, obviously, this comes with a different set of tradeoffs, not the least of which is a certain amount of manual and mechanical complexity. > But.. > 1) We have not implemented support for this yet. We plan to go live with > the fully hosted version first and extend it with support for non-hosted > systems around Q2/Q3 2011. > > 2) It can take considerable effort for LIRs to set up their own > non-hosted solution from scratch. We know that ISC is developing an open > source solution (rpkid) that may be useful for LIRs that want to run > their own instance. From our side we will make sure that we test > interoperation with this system when we implement this protocol in our > system. > I think that's a good plan. However, Randy's criticisms of the hosted solution are not without merit. While I am glad to see that the RIPE hosted solution is not such a scheme, my comments were based on the fact that other schemes I have seen for other certificate systems involved the user holding their private key after it was given to them by the hosted system. Such a system would obviously the worst of all worlds from a security standpoint. Owen From mkarir at merit.edu Mon Oct 4 07:37:35 2010 From: mkarir at merit.edu (mkarir) Date: Mon, 4 Oct 2010 08:37:35 -0400 Subject: [ncc-services-wg] RPKI Resource Certification: building features In-Reply-To: <20101004100003.31688.11292.Mailman@postboy.ripe.net> References: <20101004100003.31688.11292.Mailman@postboy.ripe.net> Message-ID: Hi Alex, We are trying to tackle a similar problem with the RADB. The approach we have taken is to build into the object management web portal an alerting system that provides alerts to a user when there is a mismatch between what is in the IRR and what is observed in BGP. Right next to the alert will be a button that they can click on to "fix" their own IRR information or to flag an object as "conflict - needs review" to allow Merit to manually review and resolve conflicting IRR information. If it indeed is a hijack then they can take other steps. A second piece of this is a historical origin database we have built where we attempt to learn from history what a valid origin might be for a given prefix. Lots of complications here with moas and newly announced prefixes but some heuristics can help here. Once again this db becomes a source of validation information like the IRR database. Not for use in rejecting/accepting routes but for generating alerts that allow a user to fix/monitor their routing assets. So in both these cases we take what is reported in BGP and compare it with sources of possible validation and generates alerts for users on mismatches. The final piece of the puzzle which is a link with roa is something that we are still working on integrating into the RADB. The piece that is currently in place add roa-uri tag to irrd which allows a user to specify in the IRR a URI pointer to a roa for that prefix. Currently we dont use it in any validation. However we have a modified rpki-whois that at the end of the whois query will perform roa validation and tell the user whether the roa was valid or in in addition to the usual whois reponse. -manish On Oct 4, 2010, at 6:00 AM, routing-wg-request at ripe.net wrote: > > Message: 1 > From: Alex Band > Date: Sun, 3 Oct 2010 19:08:33 +0200 > To: ncc-services-wg at ripe.net, > routing-wg at ripe.net > Subject: [routing-wg] RPKI Resource Certification: building features > > Most of the discussions around RPKI Resource Certification that have = > been held up to now have largely revolved around infrastructure and = > policy topics. I would like to move away from that here and discuss > what = > kind of value and which features can be offered with Certification > for = > network administrators around the world. Because in the end, the > goal is = > to make Internet routing more robust and create a more reliable > method = > for network operators to make routing decisions. > > We all know about the shortcomings of the IRR system and that just > half = > of all prefixes on the Internet have a route object associated with > them = > (http://bgpmon.net/blog/?p=3D140). However, it does mean that there > is = > ton of valuable information in the IRRs, whereas the Certification = > system needs to start from scratch. Based on many discussion I've > had = > with members and the Community, here is my idea for a Route Origin = > Authorisation** (ROA) wizard that retrieves IRR information, > compares it = > to real world routing and uses that for the creation of ROA = > Specifications. This has a number of benefits: > > - Network operators don't have to create their routing policy in the = > Certification system from scratch > - Because a comparison between is done the IRR and RIS = > (http://ripe.net/ris/), only accurate up-to-date information is > added to = > the Certification system > - The accuracy of the IRR is increased as a bonus, and is achieved = > without leaving the wizard > > Ideally, a network operator should be able to manage and publish > their = > routing policy =96 both for the IRR and Certification =96 from one = > single interface.=20 > > Here are the basic steps for the wizard after a certificate is = > generated: > > 1. Start ROA Wizard > > 2. Detect IRR information using the AS numbers in the Certificate, > like = > for example: > = > http://www.db.ripe.net/whois?searchtext=3DAS286&inverse_attributes=3Dorigi= > n&form_type=3Dsimple > > 3: Compare results with RIS using RRCC/Netsense, like for example: > http://www.ris.ripe.net/cgi-bin/rrccng/query.cgi?target=3DAS286 > > 4: Allow user to flag which ROA specifications they would actually > like = > to create, based on the IRR and RRCC/Netsense results. > > 5: Allow user to create additional ROA Specifications > > 6: Detect which maintainer is used for the route objects in the IRR > > 7: Allow user to specify maintainer password/pgp key, so all route = > objects are updated/removed/added based on the ROAs that were > created. = > This makes sure the data in the IRR and the Certification system is = > consistent.=20 > > 8: Save and publish ROAs and route objects > > Do you think there is value in creating a system like this? Are > there = > any glaring holes that I missed, or something that could be added? > I'm = > looking forward to your feedback. > > Alex Band > RIPE NCC > http://ripe.net/certification > > > ** The certification system largely revolves around three main > elements: = > (1) the Certificate, that offers validated proof of holdership of an = > Internet Resource, (2) the Route Orgin Authorisation Object (ROA), a = > standardised document that states that the holder of a certain > prefix = > authorises a particular AS to announce that prefix and (3) the = > Validator, which relying parties, i.e. your peers, can use to > validate = > certificates and ROAs.= > > From cmaurand at xyonet.com Mon Oct 4 07:54:44 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 04 Oct 2010 08:54:44 -0400 Subject: router lifetime In-Reply-To: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> References: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4CA9CE94.807@xyonet.com> On 10/2/2010 7:23 PM, Franck Martin wrote: > How long do you keep a router in production? > > What is your cycle for replacement of equipment? > > For a PC, you usually depreciate it over 3 years, and can make it last 5 years, but then you are stretching the functionality, especially if you upgrade the OS, tho it is not uncommon to see companies still on XP and IE6. Hell, we still have Windows 2000 and IE6. --Curtis From jlewis at lewis.org Mon Oct 4 09:25:03 2010 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 4 Oct 2010 10:25:03 -0400 (EDT) Subject: router lifetime In-Reply-To: <4CA9CE94.807@xyonet.com> References: <26584318.604.1286061791081.JavaMail.franck@franck-martins-macbook-pro.local> <4CA9CE94.807@xyonet.com> Message-ID: On Mon, 4 Oct 2010, Curtis Maurand wrote: > On 10/2/2010 7:23 PM, Franck Martin wrote: >> How long do you keep a router in production? >> >> What is your cycle for replacement of equipment? >> >> For a PC, you usually depreciate it over 3 years, and can make it last 5 >> years, but then you are stretching the functionality, especially if you >> upgrade the OS, tho it is not uncommon to see companies still on XP and >> IE6. > Hell, we still have Windows 2000 and IE6. People tend to want/expect faster graphics performance, faster CPUs, more RAM for bigger (or more bloated) applications. A router handling T1 aggregation (i.e. cisco 7206, PA-MC-T3, M13 mux) 10 years ago will still handle T1 aggregation today (assuming you still have T1 customers). Over that time period, the only major change is that with routing table growth, routers that were able to handle full routes no longer can...so you either have to upgrade the NPE board to one that can hold 512MB or more or give up full routes. And with the widebank28 muxes, you just have to replace the mux controller cards every few years as they tend to burn out. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mpetach at netflight.com Mon Oct 4 09:58:31 2010 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 4 Oct 2010 07:58:31 -0700 Subject: 2010.10.03 NANOG50 NANOG Community meeting nots Message-ID: Here's my notes from the community meeting from last night; sorry about being a bit late with them, the meeting ran long, and we dashed straight out from it to the social, which had already started by the time we wrapped up. ^_^;; Apologies for any typos still in the notes, I did a quick proofread this morning while jotting down this morning's notes, so it wasn't terribly thorough. Bcc'ing to nanog-futures@ as well, as it is germaine to both lists. Notes are also available online at http://kestrel3.netflight.com/2010.10.03-NANOG50-community-meeting.txt Matt NANOG50 2010.10.03 community meeting notes AGENDA: Steering committee report -- steve feldman Progream committee report dave meyer Communicatons commitee report This is a dialog, not a lecture; come to the mic with questions, comments, etc. steering committee report -- steve feldman blue badges are steering committee highlights since nanog49: day-to-day nanog stuff has Just Been Working thanks to hosts and merit for that! prep for 2010 election Postel network operator's scholarship preoparation for this and future meetings, through 2011 and the transition After NANOG50 select new PC members select new CC members (nominations still open) start on planning for 2012 meetings and the transition Mailing lists...look at website for list. Dave Meyers, Program Committee Report PC has yellow badges; if you like things on program, come let yellow badge people know. PC members really pull the conference together. PC committee member list Communications Committee Report, Mike Smith Red target badges! List of CC members is shown. They try to take a light hand when running the list; nanog-futures is a great forum, please do speak up. They are very much in need of more people, so make sure to nominate your friends (or enemies!)! Marketing Working Group -- Cat Hoffman members listed.. Full sponsorship attendance at NANOG49 sponsorship appreciation lunch and pre-promotion for NANOG50 Atlanta NANOG50 full sponsorship promotion attendance pre-promotion of NANOG51 Vendor Collaboration check it out in Chastain Room (may be called NOG room) Merit Report -- Andy R. Thanks to meeting host, TelX network connectivity, engineering power in general session onsite meeting staffing 2 socials! Other contributors for logistics Break sponsors, breakfasts, etc. Beer and Gear is Monday evening, they double as breakfast sponsors as well. Vendor collaboration is Comcast, Arris, A10, [and one more I missed] Merit Network Team Larry Blunk, David Bilbertson , DSue Joiner ,Dawn Khan, Rob Levitt, Carl Wadsworth. Pete Hoffswell NANOG 49, SF Attendance 607 total (record!) 505 PAID 102 WAIVED 199 newcomers (32.7%) 9 students 26 countries 31 US states plus DC NANOG49 revenue 409,061 expense, 423,340 balance -14,279 hosting was 184,221; SF was about 80,000 more than previous meetings; expense place to host, about 34% more than other locations. 2 big staff transitions at the beginning of the year, from Merit, put against the revenue from meetings, cost of about 40,000. 2 meetings upcoming NANOG51 Jan30-Feb2, Miami FL, Terremark NANOG52, June 12-15, 2011 Denver, CO, Alcatel, Lucent NANOG Election election process SC candidates NANOG charter amendment NewNOG charter Election slide, giving eligibility instructions should be on NANOG page; you can vote any time up to Weds morning. Announced Weds at lunch. Please, if you have opinion, please vote! SC candidates, 5 for 3 positions Thanks to Joe Provo who is aging out after 4 years. Rob Seastrom Richarch Steenbergen John Osmon Michael K Smith Patrick Gilmore Order is random, don't read anything into it. Rob Seastrom starts off with his statement, listing his experiences and background; his position statement is on the web, you can read it there. He'd like to help make Nanog stand on its own, and has some 501(3c) experience. Richard Steenbergen is up next; he's been on PC for 4 years, he's termed out there, so now he's running for SC. He thinks NANOG's been doing good job on the reform process that last 4 years; he'd like to help make the transition go smoothly, keep mailing list on topic, make it a good place for engineers to get information. And if you vote for him, you get custom-printed M&Ms. :) Michael K. Smith--chair of communications committee; been on SC as non-voting member for past year, working to make newNOG a success. Has been working on doing business modelling for the organization, and wants to keep doing it! Patrick Gilmore--he helped start newNOG, and wants to see it through; there's five really good candidates, so whomever you pick, newNOG will be in good hands. If you like what he's done, vote him back; otherwise, vote him off and signal a desire for change. SC members will become newNOG board members, btw. New Charter Amendment on Ballot Lets Merit wind down, and newNOG wind up; it's an endorsement for newNOG organization. If you're in favour of it, vote for it. :) There is also a newNOG election happening at the same time; everyone from NANOG will be eligible to vote for newNOG as well. Merit is running that as well. Shall we adopt the new bylaws as drafted by Steve Gibbard? Yes/No? Otherwise, the hastily done ones from Steve stay in effect. Bylaws do allow for amendments, so mistakes in either case can be rectified over time. That's it for the NANOG section of meeting. Now over to Sylvie's slides. Transition report--newNOG that's a placeholder name, once we have rights to a better name, we'll use a better name. milestones next activities reports from WGs created 5 working groups membership WG (kris foster) governance (steve gibbard) development (chris quesada)--getting revenue stream finance (dan golding) -- budget to spend the revenue technical (richard steenbergen)--support technical needs of the organization Sept 24, applied for 501(c)(3) with IRS; that will take many weeks, as it was a very, very thick sheaf of documents. Loan by ARIN to fund an executive director position Merit has loaned money to hire the executive director newNOG treasury income: donations: 11,125.00 other income 102.11 Expenses: hotel deposit 5,000.00 IRS application [get rest of numbers online] Executive director search accepting applications until Oct 15th http://www.newnog.org/ Form an RFP working group get involved!! send mail to board at newnog.org Issue RFP by end of Oct to contract Association management services IT services Conference Management services Membership-wg at newnog.org Ren got drafted to do this. But Joe can stand in for her. membership-wg, hammered out membership structure to fold into the bylaws Basic overview of different member models used in different organizations following nanog49 (thanks Janine!) fine print listing of qualifications for newNOG membership is put up. There was discussion on newnog-futures about the types of memberships. Steve Gibbard, governance working group, notes that the life member was no longer 10x, it's now at board discretion. Joel Jaegli, on 9/2, failed to get a rise, he's not sure he'll vote against them, he would have preferred different language in them. The other bearded one is not here to voice his thoughts. Joe agrees that this will be an iterative process over time. Joel notes that once success from last time around was that we left a lot up to the discretion of the various orgs responsible for them; that is a useful model to consider going forward, such as membership models and dues. Kevin Oberman, ESnet, he's been here for many years; the logo used to be a drawing of a necktie with the words "official member"--those who had an interest paid their money, and showed up. Why do we need to have requirements for demonstrated professional competence as part of the requirements? Why can't we simply let anyone who wants to pay, show up to the meetings? Why can't we let it be as open as possible? Joe notes that the openness idea is to have paid attendance separate from 'membership' status. Dan Golding--not part of membership working group; the weasel words were so that anyone who wanted to join could; you need to have some definition for membership for non-profits for IRS. Otherwise, you have to list it as "those with interest in topic area X". Some are happy with outcome, some are unhappy. We got the best output we could from 14 person team; with larger group, it's hard to come up with output everyone likes, or is comfortable. When you have larger working groups, concensus is challenging. Also, membership working group was pretty vague, pie-in-the-sky for its goals. Lessons learned; fewer people, more input from the board, more constrained choices. Fellow members selected by board, for outstanding service to the community. Board doesn't have to actually *add* any fellows, but the option is there; it can be dropped if people don't think it's useful. Martin Hannigan, man who wears many hats. Neutral with respect to NANOG to newNOG; not subscribed to futures mailing list; heard that randy made some interesting comments about it. He doesn't really support it; he appreciates it's hard work; but it sounds kind of obnoxious. A good deal of his advancement came from NANOG, and it would have been much harder without access to it. Joe: boilerplate was from IEEE, the front loading of the lifetime membership was to build the bank. difficulty with travel allows for people who can't make the meetings to still participate. the membership is to establish an eligible pool for voting on corporate matters, not limit meeting attendance. it also establishes a revenue stream. And a way to recognize one's peers. fundamentally: Need members who can vote Need revenue stream from members John Springer--are we all members? At present, yes, for the first member. After the first election, you have to join to be a voting member. So, as of Wednesday, if we pass this, then we all cease to be members. Current interim bylaws leave it up to the board. Bill Norton asks--the vote for bylaws is thumbs up or down; it's an all or nothing vote right now, no way to vote down on membership. RS asks Martin Hannigan about his question; turns out he was asking why we needed a membership structure at all? Turns out that for non-profit organizations, you must satisfy some prerequisites to become a member, like for a credit union, you must belong to a legally qualified category to qualify for voting. Martin is happy to understand that, and will vote yes, as he thinks that this group can pluck a turd out of a punchbowl; but he thinks that membership qualifications are problematic, and would be happy to have one that's just pay $50 to get a membership card. Steve notes that there's sufficient disagreement on the topic, we'll probably need to go back and adjust the membership topic some more. Matt Petach from Yahoo asks how we vote for changes to membership rules if we pass the new bylaws, and cease to be members at that point? If we pass the new bylaws, people will have to pay the $100 to become members again in order to vote for changes. Better is the enemy of good enough; are we moving in a positive direction, as we refine this, year over year? David Farmer, UofMinn--this is eligibility for voting that we're talking about; when he first looked at it, it wasn't clear it was about voting, it seemed that applied to those who could participate. We need to be very clear what the restrictions on membership imply, and what participation people can or cannot engage in. The IEEE model is *not* that way, so we need to be clear if we point to it as the boilerplate that we used for this. Michael Sinatra, UCB, is there an intent to provide discount for meeting fees for NANOG members? It has certain negative impacts; perhaps extend earlybird pricing for members? Once we have membership, we need to streamline it, and codify the benefits that paid membership brings with it. If you are going to do that, you have to be very careful that there is decoupling between membership and participant status, so that we don't put participants disenfranchised or feel turned away. Perhaps, but we do want to make people want to become members. Dan Golding notes there was some discussion about the breakeven point between membership and meeting costs. Joel Jaegli notes there are people who participate who do not attend meetings; this will allow them to participate more in the process. Financial slides will be online after this. How can you help? participate in the process; it's expected to be iterative, there will be refinements as we go along. Governance working group, Steve Gibbard herding cats to get bylaws drafted. The working group was thrown open to everyone who wanted to join, and got a large list. He puts up a list of the major contributors. Draft by-laws were written up; but they didn't write up the membership section, that was the membership wg. :D rest of section was mainly merging NANOG charter with interim newNOG charter. Took structure from existing charter. There is an elected board that has actual power; executive director will serve as board member, for tie breaking, and to keep voting the same. Executive director selected by elected members of the board; the board can remove the executive director. Added some extra committees: membership/development budget/finance Amendability--by majority of membership or temporarily by the full board. Assumption that we got a lot of things wrong, so goal was to make it as amendable as possible. The ability of board to temporarily amend was mainly done to allow for adjusting rules to make IRS happy for the first year; after the first year, it expires unless specifically revoked. It sounds like there's a lot of concern about the membership rules, but not as much about the rest of the bylaws. If the new bylaws are passed, we have a provision to allow the new members to vote them out or to change them over the coming year. Bill Norton notes that we're putting faith in the steering committee to make changes to the membership rules. If we vote thumbs up on bylaws, we note that we may have the board changing the rules over time; if people pay lifetime membership now, will they be immune to changes in the future, based on their payment? The fellows, setting of fees, etc. was all left to the board. The board could decline to set a fee, or set the fee so high nobody wants to pay it, if they want to take it off the table. Could people be amended out of their membership? That depends on what the board says, and what amendments people bring to the table. Patrick notes that it's a membership org; so there's nothing stopping the members from voting to change the structure after you buy your lifetime dues. If you don't have faith in the org, pay the annual dues; if you do have faith in the org and your fellow members, then go ahead and pay it. It really comes down to a matter of how much you trust the other people in the room. Don Welch, Merit networks; if the ED serves at behest of board, it will be with some longevity, while board cycles out. The ED and assistant will have institutional knowledge, compared to short term limits of the board. Patrick notes the ED will be very powerful, as they will have a seat on the board, as well as outlasting the rest of the board. It's a matter of making the right choice; the membership can make an amendment to remove the ED if they can get a majority to approve it. development wg; Chris couldn't be here, but Sylvie can talk about it. Betty Burke, Chris Quesada, Valerie Wittkopf sponsorship highlights: additional sponsorship programs little change from attendee perspective beer and gear, breaks stay same, marketing, sales, still limited more flexibility for sponsors multiple sponsorship program, sponsors can provide for a calendar year, rather than just a single break or event. Finance working group, with Dan Golding Dan Golding, Bill Norton, Michael Smith, Tom Daly, Duane Wessels, Board liason. Remit: Budget--create cash budget for now through 2012, a cash budget based on sponsorship, revenues, etc. Budget is done, waiting for board approval create financial controls and systems to make sure finances are being handled properly. Budget is complete, submitted with IRS application, board will review and vote on it this meeting. Efforts ongoing for financial controls and systems. Budget determined by looking at membership structures, determine probable membership and meeting attendance. provided a sounding board for development WG as they created sponsorship models for 2011 and 2012 conferences. (models were very conservative, we should be able to hit those numbers). Expense side; pretty limited data on what it costs to run a conference; we have aggregate totals, but specific breakdowns. Extremely conservative expense model, buffer for all line items, and assumes no discounts. Some areas will not be clear until we've run a conference. still pretty confident. This was done as openly as possible; only requirement was financial or accounting knowledge all volunteers accepted lots of collaboration with other working groups If you are dissatisfied with this, please step up and volunteer. Small group, but everyone contributed spectacularly to the overall effort. most difficult issues: which sponsorship model to use shift from traditional "ala carte" to industry typical "bronze/silver/gold" model should make sponsors happier and easier to budget for. Staffing level of the organization small staff (ED), augmented by event assistants "Hooks" in budget for association mangement an option Is the newNOG org financially viable? Yes, though this was not a starting assumption. If everything comes together, sponsorships, membership in reasonable numbers, etc. This should be viable for 6 figures a year, which should be enough to keep us afloat in case of bad events, acts of god, and horrible conferences. David Farmer, UofMinn--association management; are they looking for a for-profit or non-profit doing it, some other organization do it? this will be part of RFP going out; it will be open, it could be for profit, non-profit, etc; there's no preconceived notions around who may apply. We'll be looking for someone who is very good at doing it. Martin Hannigan--if buckets don't fill, what's the contingency plan; do we have a line of credit, so that the meeting can still happen in spite of poor revenue stream? A: Dan notes that was one of the biggest concerns about this. ARIN provided a good sized loan to fund the ED position, thank you ARIN, that will get the ED piece off the ground. But for the conference numbers were put in, they were worse than what we are achieving today. We tried to be as disciplined as possible about any assumptions. Between the ARIN loan and the conservative assumptions, we should be OK. Holly Jacobson, Cisco, this is great; one caveat, there are some organizations that like to host events in their home town; IETF has that kind of issue. A: Chris Quesada is pretty good about this; if you want that type of privilege, you'd really pay for it. So, if someone wants it that badly, they can get it, but it'll really cost them. Right now, NANOG gets what's left for sponsorship budgets, since we don't plan in advance. Now that we're planning more than a year in advance, we should be able to get into people's budgets well in advance. Mike Hughes, Google, there's often some provision to restrict signing authority for the ED; they're likely to have primary signing authority. There don't seem to be any financial restrictions or expiration terms around it. A: we'll probably add those in within a separate document, requiring a second signature from someone else in the org above a certain threshold. Steve Gibbard jumps in to note intent in bylaws was that board was final authority, and would decide on what those limits were. Patrick notes those limits aren't meaningful, since ED can sign binding contract in spite of limits in the bylaws. John Curran said ARIN put a quarterly note at 30,000 note, 2%, payments begin 25 months after initiation. Each quarterly payment is contingent upon report of progress, including financial controls; so an ED that goes haywire will find that the payment 90 days out will simply not happen. The controls ask for audited financial statements, etc. The ARIN note amortization is shown on screen. Pat P. financially strapped student; right now, membership only buys you a vote; he's unlikely to be able to spend the money. Dan Golding notes he shouldn't get a membership; $100/year for a vote is probably not a good tradeoff. But those who feel really strongly about it, may make the choice. Right now, the assumption is 100 members to start with, topping out at 250 in 2012. There's probably 40-50 people just in the steering committee, program committee, working groups, and the recently rehabilitated. At end of first year, end of 2011, 100 members, 2012, 250, 2013, 500 were the target member counts. Social started 10 minutes ago. Joel Jaegli noted a student served on the program committee, so we should not count them out. We should consider a discounted rate for students. Election for bylaws; donny roiseman; vote is for bylaws in full; in section 9, lists four committees, but details five; how do we deal with errors like that? Look at controlling section of it; 2 mechanisms to fix them; board can make adjustments with unanimous vote; or wait a year and put it through the full process; depends on severity of the error, and community support. Dan Golding: When charter came out in 2005, there were at least as many errors, and over next 24 months, they were slowly corrected. with any effort like this, there's going to be errors that we'll find over time, it's part and parcel with this process. Louis Lee, will be a member for sure! OK, we'll wrap up and go (late) to the social! We wrap up at 1729 hours Pacific time. From Greg.Whynott at oicr.on.ca Mon Oct 4 11:47:52 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 4 Oct 2010 12:47:52 -0400 Subject: do you use SPF TXT RRs? (RFC4408) Message-ID: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake.. how many of you are using SPF records? Do you have an opinion on their use/non use of? take care, greg From nathan at atlasnetworks.us Mon Oct 4 11:53:42 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 4 Oct 2010 16:53:42 +0000 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: <8C26A4FDAE599041A13EB499117D3C28406050F1@ex-mb-2.corp.atlasnetworks.us> > how many of you are using SPF records? Do you have an opinion on their > use/non use of? We use SPF on most client domains. On inbound filtering, we add no score for a lack of SPF record, and we reject mail if the SPF record hardfails. We've seen it reduce domain-imposter spam. It's not the ultimate spam fighting tool, but it does give you some control over your own domain for whoever will listen to it, which is handy. The only 'DoS Mitigation' I can think of is that the presence of a hardfail record would help keep your domain off the various DBLs. You could call "getting a domain blacklisted" a denial of service, I suppose. Nathan From jna at retina.net Mon Oct 4 11:54:22 2010 From: jna at retina.net (John Adams) Date: Mon, 4 Oct 2010 09:54:22 -0700 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: Without proper SPF records your mail stands little chance of making it through some of the larger providers, like gmail, if you are sending in any high volume. You should be using SPF, DK, and DKIM signing. I don't really understand how your security company related SPF to DoS though. They're unrelated, with the exception of backscatter. -j On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott wrote: > > A partner had a security audit done on their site. ?The report said they were at risk of a DoS due to the fact they didn't have a SPF record. > > I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, ?I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. ?When a client's email doesn't arrive somewhere, ?we will hear about it quickly, ?and its investigated/reported upon. ? ? ?I'm not opposed to putting one in our DNS, ?and probably will now - for completeness/best practice sake.. > > > how many of you are using SPF records? ?Do you have an opinion on their use/non use of? > > take care, > greg > > > > > > > From mpetach at netflight.com Mon Oct 4 11:56:56 2010 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 4 Oct 2010 09:56:56 -0700 Subject: 2010.10.04 NANOG50 day 1 morning notes posted Message-ID: For those who might care, I've put version 1.0 of my notes from the morning session up at http://kestrel3.netflight.com/2010.10.04-NANOG50-morning-notes.txt and I bounced apache on the box, since it seemed to have gotten hung--sorry about that, for those who were puzzled at the timing out URL from earlier. ^_^;; Matt From nick at brevardwireless.com Mon Oct 4 12:00:06 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Mon, 4 Oct 2010 13:00:06 -0400 Subject: do you use SPF TXT RRs? (RFC4408) Message-ID: <21dbffa3$3ee26ecf$6d324c0c$@com> We use SPF. Lots of the bigger guys require it. Along with DK/DKIM signing. In our spam weight based filtering, if it hardfails it drops it, softfail(no spf record) we don't add or remove points at all. If it passes SPF we remove a few points of the spam weight. Nick Olsen Network Operations (877) 804-3001 x106 ---------------------------------------- From: "Greg Whynott" Sent: Monday, October 04, 2010 12:48 PM To: "nanog at nanog.org list" Subject: do you use SPF TXT RRs? (RFC4408) A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake.. how many of you are using SPF records? Do you have an opinion on their use/non use of? take care, greg From mike at mtcc.com Mon Oct 4 12:02:48 2010 From: mike at mtcc.com (Michael Thomas) Date: Mon, 04 Oct 2010 10:02:48 -0700 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: <4CAA08B8.6060009@mtcc.com> On 10/04/2010 09:54 AM, John Adams wrote: > Without proper SPF records your mail stands little chance of making it > through some of the larger providers, like gmail, if you are sending > in any high volume. You should be using SPF, DK, and DKIM signing. There should really be no reason to sign with DK too. It's historic. > I don't really understand how your security company related SPF to DoS > though. They're unrelated, with the exception of backscatter. Me either. Mike > > -j > > > On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott wrote: >> >> A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. >> >> I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake.. >> >> >> how many of you are using SPF records? Do you have an opinion on their use/non use of? >> >> take care, >> greg >> >> >> >> >> >> >> From mir at ripe.net Mon Oct 4 12:03:24 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 04 Oct 2010 19:03:24 +0200 Subject: Geoff Huston's study on IPv6 Background Radiation - now on RIPE Labs Message-ID: <4CAA08DC.1090605@ripe.net> Hi, Earlier today, Geoff Huston presented the following at NANOG 50 in Atlanta: Background Radiation in IPv6. You can read the full story now on RIPE Labs: https://labs.ripe.net/Members/mirjam/background-radiation-in-ipv6 Kind Regards, Mirjam Kuehne RIPE NCC From bmanning at vacation.karoshi.com Mon Oct 4 12:04:28 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 4 Oct 2010 17:04:28 +0000 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: <20101004170428.GC2117@vacation.karoshi.com.> On Mon, Oct 04, 2010 at 12:47:52PM -0400, Greg Whynott wrote: > > A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. that does not follow at all. > > I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake.. > > > how many of you are using SPF records? Do you have an opinion on their use/non use of? I don't use them. --bill > > take care, > greg > > > > > > From jna at retina.net Mon Oct 4 12:05:29 2010 From: jna at retina.net (John Adams) Date: Mon, 4 Oct 2010 10:05:29 -0700 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <4CAA08B8.6060009@mtcc.com> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> <4CAA08B8.6060009@mtcc.com> Message-ID: We've seen percentage gains when signing with DK, and we carefully monitor our mail acceptance percentages with ReturnPath. It's around 4-6%. I'd like to stop using it, but some people still check DK. -j On Mon, Oct 4, 2010 at 10:02 AM, Michael Thomas wrote: > On 10/04/2010 09:54 AM, John Adams wrote: >> >> Without proper SPF records your mail stands little chance of making it >> through some of the larger providers, like gmail, if you are sending >> in any high volume. You should be using SPF, DK, and DKIM signing. > > There should really be no reason to sign with DK too. It's historic. > >> I don't really understand how your security company related SPF to DoS >> though. They're unrelated, with the exception of backscatter. > > Me either. > > Mike > >> >> -j >> >> >> On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott >> ?wrote: >>> >>> A partner had a security audit done on their site. ?The report said they >>> were at risk of a DoS due to the fact they didn't have a SPF record. >>> >>> I commented to his team that the SPF idea has yet to see anything near >>> mass deployment and of the millions of emails leaving our environment >>> yearly, ?I doubt any of them have ever been dropped due to us not having an >>> SPF record in our DNS. ?When a client's email doesn't arrive somewhere, ?we >>> will hear about it quickly, ?and its investigated/reported upon. ? ? ?I'm >>> not opposed to putting one in our DNS, ?and probably will now - for >>> completeness/best practice sake.. >>> >>> >>> how many of you are using SPF records? ?Do you have an opinion on their >>> use/non use of? >>> >>> take care, >>> greg >>> >>> >>> >>> >>> >>> >>> > > From nathan at atlasnetworks.us Mon Oct 4 12:05:46 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 4 Oct 2010 17:05:46 +0000 Subject: Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted) Message-ID: <8C26A4FDAE599041A13EB499117D3C284060517F@ex-mb-2.corp.atlasnetworks.us> http://kestrel3.netflight.com/2010.10.04-NANOG50-morning-notes.txt " Whois traffic has been going through the roof; they added more proxies in front to support it. Apparently, there's IP management packages that do whois queries. It would be good to find out who is doing it, and talk to ARIN engineering, to find a better way of handling it. We can't keep up if so many machines on the internet keep doing it like this. Source addresses are all over, they're all over, not sign of bots; could be a DLL or mac system startup that's doing it. Please, don't embed whois lookups in everyone's computers like this!! " The only thing I know of is that packages like fail2ban that perform WHOIS lookups when blocking IPs to generate abuse POC notification emails. So more SSH bruteforce attacks = more whois lookups. Nathan ? > For those who might care, I've put version 1.0 of my notes from the morning > session up at http://kestrel3.netflight.com/2010.10.04-NANOG50-morning-notes.txt From Greg.Whynott at oicr.on.ca Mon Oct 4 12:06:39 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 4 Oct 2010 13:06:39 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: <5AD877E2-0CFA-4110-8C81-37DAD3A83404@oicr.on.ca> it was the backskatter they were referring to, where spamers forge your domain as the source of the email. Thanks John for your comments, -g On Oct 4, 2010, at 12:54 PM, John Adams wrote: > Without proper SPF records your mail stands little chance of making it > through some of the larger providers, like gmail, if you are sending > in any high volume. You should be using SPF, DK, and DKIM signing. > > I don't really understand how your security company related SPF to DoS > though. They're unrelated, with the exception of backscatter. > > -j > > > On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott wrote: >> >> A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. >> >> I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake.. >> >> >> how many of you are using SPF records? Do you have an opinion on their use/non use of? >> >> take care, >> greg >> >> >> >> >> >> >> From Rod.Beck at hiberniaatlantic.com Mon Oct 4 12:07:43 2010 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 4 Oct 2010 18:07:43 +0100 Subject: A New TransAtlantic Cable System References: <20101002150939.1E79C00B@resin16.mta.everyone.net> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> Hi Frank, Yes it does include all the O-E conversions. By the way, my recollection is the undersea regenerators do purely optical regeneration. There is no O-E conversions undersea, only at the landing stations and terrestrial components. Since the system is just in the planning stage, the latency estimate is conversative. It is better to surprise than disappoint ... Hi All. It appears we're discussing theoretical limits of silica-based glass here. The Press Release assertion talks about what a trader might experience. Hm. I would ask Rob Beck to clarify this point and inform whether the stated objective in the release accounts for the many o-e and e-o conversions on the overland part of the end-to-end trader connection, including the handoffs that occur in the NY and London metros. I know that terrestrially, i.e., here in the US, some brokerage firms and large banks (is there any longer a distinction between those two today?:) have used their clout to secure links that are virtually entirely optical in nature on routes that are under a thousand miles, but this is not an option on a submarine system that's intrinsically populated with electronics, never mind the tail sections that assume multiple service providers getting into the act. Rob? Anyone? FAC --- Valdis.Kletnieks at vt.edu wrote: From: Valdis.Kletnieks at vt.edu To: Heath Jones Cc: nanog at nanog.org Subject: Re: A New TransAtlantic Cable System Date: Fri, 01 Oct 2010 10:08:50 -0400 On Fri, 01 Oct 2010 15:01:25 BST, Heath Jones said: > > http://finance.yahoo.com/news/Hibernia-Atlantic-to-bw-3184701710.html ?x=0&.v=1 > Sales spam - but still - very close to minimum possible latency! > 3471 miles @ 186,282 miles/s * 1.5 in glass * 2 round trip = 55.9ms. My first thought is that they've found a way to cheat on the 1.5. If you can make it work at 1.4, you get down to 52.2ms - but get it *too* low and all your photons leak out the sides. Hmm.. Unless you have a magic core that runs at 1.1 and a *cladding* that's up around 2.0? From nathan at atlasnetworks.us Mon Oct 4 12:08:25 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Mon, 4 Oct 2010 17:08:25 +0000 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <21dbffa3$3ee26ecf$6d324c0c$@com> References: <21dbffa3$3ee26ecf$6d324c0c$@com> Message-ID: <8C26A4FDAE599041A13EB499117D3C28406051A6@ex-mb-2.corp.atlasnetworks.us> > If it passes SPF we remove a few points of the spam weight. I would rethink this practice. Many spammers publish SPF valid records these days precisely because of this. Nathan From mike at mtcc.com Mon Oct 4 12:16:48 2010 From: mike at mtcc.com (Michael Thomas) Date: Mon, 04 Oct 2010 10:16:48 -0700 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> <4CAA08B8.6060009@mtcc.com> Message-ID: <4CAA0C00.6020106@mtcc.com> On 10/04/2010 10:05 AM, John Adams wrote: > We've seen percentage gains when signing with DK, and we carefully > monitor our mail acceptance percentages with ReturnPath. It's around > 4-6%. I'd like to stop using it, but some people still check DK. Sigh. I was hoping not to hear that. It's been about 5 years since the issue of rfc4871. It might be helpful to name and shame. Mike > > -j > > > On Mon, Oct 4, 2010 at 10:02 AM, Michael Thomas wrote: >> On 10/04/2010 09:54 AM, John Adams wrote: >>> >>> Without proper SPF records your mail stands little chance of making it >>> through some of the larger providers, like gmail, if you are sending >>> in any high volume. You should be using SPF, DK, and DKIM signing. >> >> There should really be no reason to sign with DK too. It's historic. >> >>> I don't really understand how your security company related SPF to DoS >>> though. They're unrelated, with the exception of backscatter. >> >> Me either. >> >> Mike >> >>> >>> -j >>> >>> >>> On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott >>> wrote: >>>> >>>> A partner had a security audit done on their site. The report said they >>>> were at risk of a DoS due to the fact they didn't have a SPF record. >>>> >>>> I commented to his team that the SPF idea has yet to see anything near >>>> mass deployment and of the millions of emails leaving our environment >>>> yearly, I doubt any of them have ever been dropped due to us not having an >>>> SPF record in our DNS. When a client's email doesn't arrive somewhere, we >>>> will hear about it quickly, and its investigated/reported upon. I'm >>>> not opposed to putting one in our DNS, and probably will now - for >>>> completeness/best practice sake.. >>>> >>>> >>>> how many of you are using SPF records? Do you have an opinion on their >>>> use/non use of? >>>> >>>> take care, >>>> greg >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> >> From sethm at rollernet.us Mon Oct 4 12:25:29 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 04 Oct 2010 10:25:29 -0700 Subject: Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted) In-Reply-To: <8C26A4FDAE599041A13EB499117D3C284060517F@ex-mb-2.corp.atlasnetworks.us> References: <8C26A4FDAE599041A13EB499117D3C284060517F@ex-mb-2.corp.atlasnetworks.us> Message-ID: <4CAA0E09.2020406@rollernet.us> On 10/4/2010 10:05, Nathan Eisenberg wrote: > http://kestrel3.netflight.com/2010.10.04-NANOG50-morning-notes.txt > > " > Whois traffic has been going through the roof; they > added more proxies in front to support it. > Apparently, there's IP management packages that do > whois queries. It would be good to find out who is > doing it, and talk to ARIN engineering, to find a better > way of handling it. > We can't keep up if so many machines on the internet > keep doing it like this. > Source addresses are all over, they're all over, not > sign of bots; could be a DLL or mac system startup > that's doing it. > Please, don't embed whois lookups in everyone's computers > like this!! > " > > The only thing I know of is that packages like fail2ban that perform WHOIS lookups when blocking IPs to generate abuse POC notification emails. So more SSH bruteforce attacks = more whois lookups. > Or the new whois doesn't scale as well as the old one. ~Seth From hj1980 at gmail.com Mon Oct 4 12:24:51 2010 From: hj1980 at gmail.com (Heath Jones) Date: Mon, 4 Oct 2010 18:24:51 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> Message-ID: > By the way, my recollection is the undersea regenerators do purely optical regeneration. > There is no O-E conversions undersea, only at the landing stations and terrestrial components. I'm not clever enough to know of some way that you could do optical regeneration without converting the signal to electrical and retransmitting back as optical.. How is that done? From hj1980 at gmail.com Mon Oct 4 12:24:51 2010 From: hj1980 at gmail.com (Heath Jones) Date: Mon, 4 Oct 2010 18:24:51 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> Message-ID: > By the way, my recollection is the undersea regenerators do purely optical regeneration. > There is no O-E conversions undersea, only at the landing stations and terrestrial components. I'm not clever enough to know of some way that you could do optical regeneration without converting the signal to electrical and retransmitting back as optical.. How is that done? From jared at puck.nether.net Mon Oct 4 12:34:54 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 4 Oct 2010 13:34:54 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28406051A6@ex-mb-2.corp.atlasnetworks.us> References: <21dbffa3$3ee26ecf$6d324c0c$@com> <8C26A4FDAE599041A13EB499117D3C28406051A6@ex-mb-2.corp.atlasnetworks.us> Message-ID: <52027A60-ABD3-4EE7-BC07-4C69AD97D412@puck.nether.net> I've found lots of domains with +all which really should be -all since they were all spam. Jared Mauch On Oct 4, 2010, at 1:08 PM, Nathan Eisenberg wrote: >> If it passes SPF we remove a few points of the spam weight. > > I would rethink this practice. Many spammers publish SPF valid records these days precisely because of this. > > Nathan > > From nicholas.hatch at gmail.com Mon Oct 4 12:37:35 2010 From: nicholas.hatch at gmail.com (nick hatch) Date: Mon, 4 Oct 2010 10:37:35 -0700 Subject: A New TransAtlantic Cable System In-Reply-To: References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> Message-ID: On Mon, Oct 4, 2010 at 10:24 AM, Heath Jones wrote: > > I'm not clever enough to know of some way that you could do optical > regeneration without converting the signal to electrical and > retransmitting back as optical.. How is that done? > > I'm not sure how it's done in practice, but check out doped fiber amplifiers for one possibility. One has to grok laser fundamentals to get what's going on, but it's not an especially complex topic. -Nick From patrick at zill.net Mon Oct 4 12:41:16 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Mon, 04 Oct 2010 13:41:16 -0400 Subject: A New TransAtlantic Cable System In-Reply-To: References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> Message-ID: <4CAA11BC.3010606@zill.net> On 10/4/2010 1:24 PM, Heath Jones wrote: >> By the way, my recollection is the undersea regenerators do purely optical regeneration. >> There is no O-E conversions undersea, only at the landing stations and terrestrial components. > > I'm not clever enough to know of some way that you could do optical > regeneration without converting the signal to electrical and > retransmitting back as optical.. How is that done? > > A halfway-decent description of the physics of how this is done, is covered in Neal Stephenson's excellent article on Wired: http://www.wired.com/wired/archive/4.12/ffglass.html The specific page covering optical regeneration: http://www.wired.com/wired/archive/4.12/ffglass.html?pg=6&topic= quote: ==== These signals begin to fade after they have traveled a certain distance, so it's necessary to build amplifiers into the cable every so often. In the case of FLAG, the spacing of these amplifiers ranges from 45 to 85 kilometers. They work on a strikingly simple and elegant principle. Each amplifier contains an approximately 10-meter-long piece of special fiber that has been doped with erbium ions, making it capable of functioning as a laser medium. A separate semiconductor laser built into the amplifier generates powerful light at 1,480 nm - close to the same frequency as the signal beam, but not close enough to interfere with it. This light, directed into the doped fiber, pumps the electrons orbiting around those erbium ions up to a higher energy level. The signal coming down the FLAG cable passes through the doped fiber and causes it to lase, i.e., the excited electrons drop back down to a lower energy level, emitting light that is coherent with the incoming signal - which is to say that it is an exact copy of the incoming signal, except more powerful. ==== Cordially Patrick Giagnocavo patrick at zill.net From rsk at gsp.org Mon Oct 4 12:49:38 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Mon, 4 Oct 2010 13:49:38 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: <20101004174938.GA20695@gsp.org> On Mon, Oct 04, 2010 at 12:47:52PM -0400, Greg Whynott wrote: > how many of you are using SPF records? Do you have an opinion on their use/non use of? 1. Not using them, and don't have any (observed) problems despite years of closely monitoring mail logs looking for just such issues. 2. Note that they don't stop spam, don't stop forgery, and don't prevent backscatter (aka outscatter). [Similar/related technologies have similar/related problems, so these points aren't really SPF-specific.] 3. As others have pointed out, you can just easily be DoS'd when using them as you could be without. ---Rsk From dotis at mail-abuse.org Mon Oct 4 12:50:41 2010 From: dotis at mail-abuse.org (Douglas Otis) Date: Mon, 04 Oct 2010 13:50:41 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: <4CAA13F1.5070108@mail-abuse.org> On 10/4/10 12:47 PM, Greg Whynott wrote: > A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. > > I commented to his team that the SPF idea has yet to see anything near mass deployment and of the millions of emails leaving our environment yearly, I doubt any of them have ever been dropped due to us not having an SPF record in our DNS. When a client's email doesn't arrive somewhere, we will hear about it quickly, and its investigated/reported upon. I'm not opposed to putting one in our DNS, and probably will now - for completeness/best practice sake.. > > > how many of you are using SPF records? Do you have an opinion on their use/non use of? It is ironic to see recommendations requiring use of SPF due to DoS concerns. SPF is a macro language expanded by recipients that may combine cached DNS information with MailFrom local-parts to synthesize >100 DNS transactions targeting any arbitrary domain unrelated to those seen within any email message. A free >300x DDoS attack while spamming. SPF permits the use of 10 mechanisms that then require targets to be resolved which introduces a 10x multiplier. The record could end with "+all", where in the end, any message would pass. Since SPF based attacks are unlikely to target email providers, it seems few recommending SPF consider that resolving these records containing active content might also be a problem. -Doug From jaitken at aitken.com Mon Oct 4 13:08:58 2010 From: jaitken at aitken.com (Jeff Aitken) Date: Mon, 4 Oct 2010 18:08:58 +0000 Subject: RIP Justification In-Reply-To: <7662474.71285950510272.JavaMail.root@jennyfur.pelican.org> References: <28460806.51285950096710.JavaMail.root@jennyfur.pelican.org> <7662474.71285950510272.JavaMail.root@jennyfur.pelican.org> Message-ID: <20101004180858.GB75718@eagle.aitken.com> On Fri, Oct 01, 2010 at 04:28:30PM +0000, Tim Franklin wrote: > Leaf-node BGP config is utterly trivial [...] > > The Enterprise guys really need to get out of the blanket "BGP is scary" > mindset It's not just "enterprise" mindset. Over the years I've seen a lot of deployed gear that either didn't support BGP at all or for which it was a significant extra cost. At least in the past this applied to many firewalls and load-balancers, and until recently, even one of the major CMTS vendors didn't support BGP. I agree that edge-node BGP is simple, but finding gear that supports it isn't necessarily so. --Jeff From Rod.Beck at hiberniaatlantic.com Mon Oct 4 13:19:58 2010 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Mon, 4 Oct 2010 19:19:58 +0100 Subject: A New TransAtlantic Cable System References: <20101002150939.1E79C00B@resin16.mta.everyone.net><1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB039584CF@bert.HiberniaAtlantic.local> > By the way, my recollection is the undersea regenerators do purely optical regeneration. > There is no O-E conversions undersea, only at the landing stations and terrestrial components. I'm not clever enough to know of some way that you could do optical regeneration without converting the signal to electrical and retransmitting back as optical.. How is that done? Erbium doped fibers. From ops.lists at gmail.com Mon Oct 4 13:38:42 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 4 Oct 2010 14:38:42 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: On Mon, Oct 4, 2010 at 12:47 PM, Greg Whynott wrote: > > A partner had a security audit done on their site. ?The report said they were at risk of a DoS due to the fact they didn't have a SPF record. This is pure unadulterated BS from someone who doesnt understand either DDOS mitigation, or SPF .. or more likely both. -- Suresh Ramasubramanian (ops.lists at gmail.com) From bill at herrin.us Mon Oct 4 13:48:47 2010 From: bill at herrin.us (William Herrin) Date: Mon, 4 Oct 2010 14:48:47 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: On Mon, Oct 4, 2010 at 12:47 PM, Greg Whynott wrote: > A partner had a security audit done on their site. >The report said they were at risk of a DoS due to >the fact they didn't have a SPF record. > > how many of you are using SPF records? ?Do you > have an opinion on their use/non use of? I use your SPF records (if you offer any) to prevent my servers from slamming your servers with backscatter from someone forging your address and sending me undeliverable email. Without SPF records, you'll receive an undeliverable report for messages "from" you that I can't deliver -- just like the RFC says I "must." Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Greg.Whynott at oicr.on.ca Mon Oct 4 13:54:15 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Mon, 4 Oct 2010 14:54:15 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: <0D5571DF-33E7-4573-B20B-564322C6B151@oicr.on.ca> i think it was an observation they made, and suggestions to make things better. I don't think the message was "fix this or you'll be off the air one day.". if they have a 56k port speed(stuck in the 80's), there is potential there for a DoS from a large volume of spam back splatter.. 8) over all, I'm inclined to accept your assumptions. -g On Oct 4, 2010, at 2:38 PM, Suresh Ramasubramanian wrote: > On Mon, Oct 4, 2010 at 12:47 PM, Greg Whynott wrote: >> >> A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. > > This is pure unadulterated BS from someone who doesnt understand > either DDOS mitigation, or SPF .. or more likely both. > > -- > Suresh Ramasubramanian (ops.lists at gmail.com) From dot at dotat.at Mon Oct 4 14:05:53 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 4 Oct 2010 20:05:53 +0100 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: On Mon, 4 Oct 2010, Greg Whynott wrote: > > A partner had a security audit done on their site. The report said they > were at risk of a DoS due to the fact they didn't have a SPF record. Bullshit. > I commented to his team that the SPF idea has yet to see anything near > mass deployment and of the millions of emails leaving our environment > yearly, I doubt any of them have ever been dropped due to us not having > an SPF record in our DNS. In my experience the presence of SPF records causes more problems than the absence, because it is incompatible with forwarded mail. If you are forced to use it, don't use -all unless that's the entirety of the record. > Do you have an opinion on their use/non use of? It's easiest to just ignore them. The whole idea was wrong-headed from the start. Use DKIM instead. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From robert at ufl.edu Mon Oct 4 14:50:49 2010 From: robert at ufl.edu (Scott, Robert D.) Date: Mon, 4 Oct 2010 19:50:49 +0000 Subject: Akamai Traffic Spikes Message-ID: <95373584CA10E7429E1D6B07CF2AD46401EC0F09@UFEXCH-MBXN04.ad.ufl.edu> We were trying to diagnose an issue we had around 1 PM EDST, and were looking at net flow data. The data indicated a significant change in our traffic patterns, all coming from Akamai address space. The Akamai utilization graphs show a near doubling of retail traffic in the same time period that we had traffic spikes. Does anybody have any idea what caused such a major surge in traffic? http://www.akamai.com/html/technology/nui/retail/charts.html 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-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell 3216630421 at messaging.sprintpcs.com From surfer at mauigateway.com Mon Oct 4 14:57:03 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Mon, 4 Oct 2010 12:57:03 -0700 Subject: Request for participation - Arbor 2010 Worldwide Infrastructure Security Report. Message-ID: <20101004125703.1E781391@resin17.mta.everyone.net> --- rdobbins at arbor.net wrote: From: "Dobbins, Roland" The 2009 edition of the survey is available here (registration required): -------------------------------------------- Why are we required to register to look at the survey? scott From jcurran at arin.net Mon Oct 4 14:58:24 2010 From: jcurran at arin.net (John Curran) Date: Mon, 4 Oct 2010 15:58:24 -0400 Subject: Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted) In-Reply-To: <4CAA0E09.2020406@rollernet.us> References: <8C26A4FDAE599041A13EB499117D3C284060517F@ex-mb-2.corp.atlasnetworks.us> <4CAA0E09.2020406@rollernet.us> Message-ID: On Oct 4, 2010, at 1:25 PM, Seth Mattinen wrote: > > > Or the new whois doesn't scale as well as the old one. Seth - New WHOIS scales much better than the old one; it would have extremely challenging to assemble enough equipment to handle the current query rate. Look at the NANOG presentation slide for the exact query rate graph, but we're handling orders of magnitude more queries at present. /John From patrick at ianai.net Mon Oct 4 14:59:43 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 4 Oct 2010 15:59:43 -0400 Subject: Akamai Traffic Spikes In-Reply-To: <95373584CA10E7429E1D6B07CF2AD46401EC0F09@UFEXCH-MBXN04.ad.ufl.edu> References: <95373584CA10E7429E1D6B07CF2AD46401EC0F09@UFEXCH-MBXN04.ad.ufl.edu> Message-ID: <66930B27-F2EF-4942-AAB0-1E8628763954@ianai.net> On Oct 4, 2010, at 3:50 PM, Scott, Robert D. wrote: > We were trying to diagnose an issue we had around 1 PM EDST, and were looking at net flow data. The data indicated a significant change in our traffic patterns, all coming from Akamai address space. The Akamai utilization graphs show a near doubling of retail traffic in the same time period that we had traffic spikes. Does anybody have any idea what caused such a major surge in traffic? > > http://www.akamai.com/html/technology/nui/retail/charts.html Akamai is happy to discuss traffic to individual ASes with those ASes. Please be sure to send e-mail from a verifiable address in that AS if you want information about that AS. If you are a peer, the standard peering at akamai.com address works. If you have Akamai boxes on your network, you can open a ticket with the Network Support group at NetSupport-tix at akamai.com. Our 24/7 NOC, noc at akamai.com, can help with emergency problems, such as a congested link. However, you will have to reach one of the other groups for in-depth, historical traffic investigation. Or you can find one of the Akamai people at NANOG. :) As for this specific problem, I haven't an idea what happened. I can tell you Akamai's global traffic at 1300 EDT / 1700 UTC today was actually lower than yesterday's traffic at the same time. Not sure if that means anything, though. -- TTFN, patrick From nick at brevardwireless.com Mon Oct 4 15:17:50 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Mon, 4 Oct 2010 16:17:50 -0400 Subject: Akamai Traffic Spikes Message-ID: <67d7571c$21f831b1$5c13377b$@com> Didn't see any spikes here, But from the looks of that graph something sure happened. It was huge, And only for a short period, Strange. Nick Olsen Network Operations (877) 804-3001 x106 ---------------------------------------- From: "Scott, Robert D." Sent: Monday, October 04, 2010 3:51 PM To: "nanog at nanog.org" Subject: Akamai Traffic Spikes We were trying to diagnose an issue we had around 1 PM EDST, and were looking at net flow data. The data indicated a significant change in our traffic patterns, all coming from Akamai address space. The Akamai utilization graphs show a near doubling of retail traffic in the same time period that we had traffic spikes. Does anybody have any idea what caused such a major surge in traffic? http://www.akamai.com/html/technology/nui/retail/charts.html 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-392-9440 FAX Florida Lambda Rail 352-294-3571 FLR NOC Gainesville, FL 32611 321-663-0421 Cell 3216630421 at messaging.sprintpcs.com From john_brzozowski at cable.comcast.com Mon Oct 4 15:25:19 2010 From: john_brzozowski at cable.comcast.com (John Jason Brzozowski) Date: Mon, 4 Oct 2010 16:25:19 -0400 Subject: NANOG50 VCR (Vendor Collaboration Room) Message-ID: Hopefully you are all aware of the NANOG50 VCR, please visit the following page for additional information: http://www.nanog.org/meetings/nanog50/vcr.php We wanted to send you a quick email and provide some additional information about the VCR. When in or near the VCR feel free to connect any of the wireless networks. Each is native dual stack enabled. Most are powered by residential home networking equipment. Thanks again and please let us know if you have any questions. Regards, John ========================================= John Jason Brzozowski Comcast Cable e) mailto:john_brzozowski at cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net ========================================= From owen at delong.com Mon Oct 4 15:30:55 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Oct 2010 13:30:55 -0700 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <4CAA0C00.6020106@mtcc.com> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> <4CAA08B8.6060009@mtcc.com> <4CAA0C00.6020106@mtcc.com> Message-ID: <738F7E85-F572-4422-812C-CA48A0952994@delong.com> On Oct 4, 2010, at 10:16 AM, Michael Thomas wrote: > On 10/04/2010 10:05 AM, John Adams wrote: >> We've seen percentage gains when signing with DK, and we carefully >> monitor our mail acceptance percentages with ReturnPath. It's around >> 4-6%. I'd like to stop using it, but some people still check DK. > > Sigh. I was hoping not to hear that. It's been about 5 years since > the issue of rfc4871. It might be helpful to name and shame. > > Mike > At least in that case, the spammer has to have control of the sending domain. SPF is not intended to protect from that case. It is intended to protect from the case where spammers Joe-job domains they can't control. Removing a few points probably isn't a bad idea so long as you have a list of domains for which points should be added. Owen >> >> -j >> >> >> On Mon, Oct 4, 2010 at 10:02 AM, Michael Thomas wrote: >>> On 10/04/2010 09:54 AM, John Adams wrote: >>>> >>>> Without proper SPF records your mail stands little chance of making it >>>> through some of the larger providers, like gmail, if you are sending >>>> in any high volume. You should be using SPF, DK, and DKIM signing. >>> >>> There should really be no reason to sign with DK too. It's historic. >>> >>>> I don't really understand how your security company related SPF to DoS >>>> though. They're unrelated, with the exception of backscatter. >>> >>> Me either. >>> >>> Mike >>> >>>> >>>> -j >>>> >>>> >>>> On Mon, Oct 4, 2010 at 9:47 AM, Greg Whynott >>>> wrote: >>>>> >>>>> A partner had a security audit done on their site. The report said they >>>>> were at risk of a DoS due to the fact they didn't have a SPF record. >>>>> >>>>> I commented to his team that the SPF idea has yet to see anything near >>>>> mass deployment and of the millions of emails leaving our environment >>>>> yearly, I doubt any of them have ever been dropped due to us not having an >>>>> SPF record in our DNS. When a client's email doesn't arrive somewhere, we >>>>> will hear about it quickly, and its investigated/reported upon. I'm >>>>> not opposed to putting one in our DNS, and probably will now - for >>>>> completeness/best practice sake.. >>>>> >>>>> >>>>> how many of you are using SPF records? Do you have an opinion on their >>>>> use/non use of? >>>>> >>>>> take care, >>>>> greg >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > From drc at virtualized.org Mon Oct 4 15:58:06 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 4 Oct 2010 10:58:06 -1000 Subject: Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted) In-Reply-To: References: <8C26A4FDAE599041A13EB499117D3C284060517F@ex-mb-2.corp.atlasnetworks.us> <4CAA0E09.2020406@rollernet.us> Message-ID: <4A689784-1DE9-48FA-878A-5CE3963CA45E@virtualized.org> On Oct 4, 2010, at 9:58 AM, John Curran wrote: > On Oct 4, 2010, at 1:25 PM, Seth Mattinen wrote: >> Or the new whois doesn't scale as well as the old one. > New WHOIS scales much better than the old one; it would have > extremely challenging to assemble enough equipment to handle > the current query rate. Look at the NANOG presentation slide > for the exact query rate graph, but we're handling orders of > magnitude more queries at present. Looking at the graph on your 3 slide, it looks like ARIN is getting around 3200 whois queries per second. How much of that query load is a result of non-port 43 queries (that is, making use of the REST features in the new server)? It looks like the exponentiation in query load started around the same time the Whois-RWS was deployed... Regards, -drc From Valdis.Kletnieks at vt.edu Mon Oct 4 15:59:08 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 04 Oct 2010 16:59:08 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: Your message of "Mon, 04 Oct 2010 13:30:55 PDT." <738F7E85-F572-4422-812C-CA48A0952994@delong.com> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> <4CAA08B8.6060009@mtcc.com> <4CAA0C00.6020106@mtcc.com> <738F7E85-F572-4422-812C-CA48A0952994@delong.com> Message-ID: <27834.1286225948@localhost> On Mon, 04 Oct 2010 13:30:55 PDT, Owen DeLong said: > Removing a few points probably isn't a bad idea so long as you have a list of > domains for which points should be added. 140 million .coms. Throw-away domains. I do believe that Marcus Ranum had "trying to enumerate badness" on his list of "Six stupidest security ideas". This won't scale as long as you have more spammers adding new domains faster than your NOC staff can add them to the blacklist. (And even centralized blacklists run by dedicated organizations haven't solved the problem yet, so I'm not holding my breath waiting for that to work out...) From ops.lists at gmail.com Mon Oct 4 16:05:12 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Mon, 4 Oct 2010 17:05:12 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <27834.1286225948@localhost> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> <4CAA08B8.6060009@mtcc.com> <4CAA0C00.6020106@mtcc.com> <738F7E85-F572-4422-812C-CA48A0952994@delong.com> <27834.1286225948@localhost> Message-ID: dig throwaway1.com NS dig throwaway2.com NS etc etc ... and then check_sender_ns_access in postfix, for example. Scales much better than whackamoling one domain after the other on the same NS On Mon, Oct 4, 2010 at 4:59 PM, wrote: > > 140 million .coms. Throw-away domains. I do believe that Marcus Ranum had > "trying to enumerate badness" on his list of "Six stupidest security ideas". > This won't scale as long as you have more spammers adding new domains faster > than your NOC staff can add them to the blacklist. > > (And even centralized blacklists run by dedicated organizations haven't solved > the problem yet, so I'm not holding my breath waiting for that to work out...) -- Suresh Ramasubramanian (ops.lists at gmail.com) From randy at psg.com Mon Oct 4 16:18:29 2010 From: randy at psg.com (Randy Bush) Date: Tue, 05 Oct 2010 06:18:29 +0900 Subject: [ncc-services-wg] RPKI Resource Certification: building features In-Reply-To: <4CA9BD07.9020901@ripe.net> References: <76B62F3C-730C-4E20-A83B-5AFD41A851A7@delong.com> Message-ID: > 1) We have not implemented support for this yet. We plan to go live > with the fully hosted version first and extend it with support for > non-hosted systems around Q2/Q3 2011. this is a significant slip from the 1q11 we were told in prague. care to explain. > Randy Bush who is cc-ed may be able to provide some more insight in > the features offered by the ISC rpkid. I don't know whether the > features mentioned by Alex in his first message will be supported by > this system. calling it isc's is a bit incorrect, but no difference. it is an open source, bsd license, i.e. free as in free, implementation of all of the rpki protocols, provisioning, up/down, publication, relying party, proto-gui to manage your resources, ... the full monty. it has been operational in a testbed with isp players from asia, the states, europe, ... for some time. randy From Valdis.Kletnieks at vt.edu Mon Oct 4 16:28:11 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 04 Oct 2010 17:28:11 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: Your message of "Mon, 04 Oct 2010 17:05:12 EDT." References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> <4CAA08B8.6060009@mtcc.com> <4CAA0C00.6020106@mtcc.com> <738F7E85-F572-4422-812C-CA48A0952994@delong.com> <27834.1286225948@localhost> Message-ID: <29127.1286227691@localhost> On Mon, 04 Oct 2010 17:05:12 EDT, Suresh Ramasubramanian said: > dig throwaway1.com NS > dig throwaway2.com NS > > etc etc ... and then check_sender_ns_access in postfix, for example. Yes, that *is* better than whack-a-mole on the same DNS server, but... The NANOG lurker in the next cubicle used to do that. Turned out the bang-for-buck wasn't as good as we hoped - it doesn't take too many false-positive errors blocking 20,000 domains hosted on the same DNS server as one spammer before the collateral damage becomes too painful. Our cost of dealing with a false positive is a lot higher than a false negative, especially once you factor in goodwill - people don't like spam, but a false positive on something they consider important causes more ire than 10x as many false negatives. That, and when our block list hit 150K entries or so, its size caused *other* issues with various things that were never designed for block lists quite that big... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From markk at arin.net Mon Oct 4 16:29:45 2010 From: markk at arin.net (Mark Kosters) Date: Mon, 4 Oct 2010 21:29:45 +0000 Subject: Whois lookups (was: 2010.10.04 NANOG50 day 1 morning notes posted) In-Reply-To: <4A689784-1DE9-48FA-878A-5CE3963CA45E@virtualized.org> Message-ID: On 10/4/10 4:58 PM, "David Conrad" wrote: > On Oct 4, 2010, at 9:58 AM, John Curran wrote: >> On Oct 4, 2010, at 1:25 PM, Seth Mattinen wrote: >>> Or the new whois doesn't scale as well as the old one. >> New WHOIS scales much better than the old one; it would have >> extremely challenging to assemble enough equipment to handle >> the current query rate. Look at the NANOG presentation slide >> for the exact query rate graph, but we're handling orders of >> magnitude more queries at present. > > Looking at the graph on your 3 slide, it looks like ARIN is getting around > 3200 whois queries per second. How much of that query load is a result of > non-port 43 queries (that is, making use of the REST features in the new > server)? It looks like the exponentiation in query load started around the > same time the Whois-RWS was deployed... Traffic increases a lot over the course of a day and follows a diurnal pattern. Right now we are seeing close to 7,000 queries per second during the height of the day. The original Whois cluster that Whois-RWS replaced could not serve more than 800 queries per second. There were two spikes. The first was right after we deployed Whois-RWS. For two months, we saw a consistent load maxing at 2400 queries per second. The second spike happened on Sept 6. At that point, traffic jumped almost 3x to the current max of 7,000 queries per second and has been pretty consistent over the past month. The patterns that we see are interesting. Most interesting is the spike asking for ip addresses login servers for the likes of Facebook, AOL, and Yahoo. This pattern emerged on Sept 6. Various people have been looking at this but no good explanation has yet been found. Your guess is good as mine what the cause of this query growth. Regards, Mark From mpetach at netflight.com Mon Oct 4 16:58:48 2010 From: mpetach at netflight.com (Matthew Petach) Date: Mon, 4 Oct 2010 14:58:48 -0700 Subject: 2010.10.04 NANOG50 Monday afternoon notes Message-ID: Here's my notes from the Monday afternoon presentations. Apologies for the gaps where I nodded off in post-lunch food coma, as well as for the typos and misspellings that snuck in. Notes are posted at http://kestrel3.netflight.com/2010.10.04-NANOG50-afternoon-notes.txt Off to Bear and Gear now. ^_^ Matt From feldman at twincreeks.net Mon Oct 4 17:03:36 2010 From: feldman at twincreeks.net (Steve Feldman) Date: Mon, 4 Oct 2010 18:03:36 -0400 Subject: [NANOG-announce] Election reminder Message-ID: <6FBCFA36-C1C4-4D35-9C0A-1E92EF4163F3@twincreeks.net> Everyone who registered for a NANOG meeting in 2009 or 2010 is eligible to vote in this year's combined NANOG/NewNOG election. If you are eligible and have not already done so, please go to http://www.nanog.org/governance/elections/2010elections/ to review the election materials and vote. Note that there are two ballots, one for the NANOG Steering Committee and charter amendment, and one for the NewNOG Bylaws ratification. Please follow both links to vote. Thanks, Steve Feldman, SC Chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From hj1980 at gmail.com Mon Oct 4 17:05:14 2010 From: hj1980 at gmail.com (Heath Jones) Date: Mon, 4 Oct 2010 23:05:14 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: <4CAA11BC.3010606@zill.net> References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> <4CAA11BC.3010606@zill.net> Message-ID: What's that quote again...? Oh, that's it: "The more you know, the more you know you don't." It feels very appropriate now :) Cheers Patrick for that great info & to everyone who contacted me off-list also! > A halfway-decent description of the physics of how this is done, is > covered in Neal Stephenson's excellent article on Wired: > http://www.wired.com/wired/archive/4.12/ffglass.html From dhetzel at gmail.com Mon Oct 4 17:22:58 2010 From: dhetzel at gmail.com (Dorn Hetzel) Date: Mon, 4 Oct 2010 18:22:58 -0400 Subject: A New TransAtlantic Cable System In-Reply-To: <4CAA11BC.3010606@zill.net> References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> <4CAA11BC.3010606@zill.net> Message-ID: With regards to the Wired Article, I still have my copy of that issue and would consider that article perhaps my favorite magazine article of all time. On Mon, Oct 4, 2010 at 1:41 PM, Patrick Giagnocavo wrote: > On 10/4/2010 1:24 PM, Heath Jones wrote: > >> By the way, my recollection is the undersea regenerators do purely > optical regeneration. > >> There is no O-E conversions undersea, only at the landing stations and > terrestrial components. > > > > I'm not clever enough to know of some way that you could do optical > > regeneration without converting the signal to electrical and > > retransmitting back as optical.. How is that done? > > > > > > A halfway-decent description of the physics of how this is done, is > covered in Neal Stephenson's excellent article on Wired: > > http://www.wired.com/wired/archive/4.12/ffglass.html > > The specific page covering optical regeneration: > > http://www.wired.com/wired/archive/4.12/ffglass.html?pg=6&topic= > > quote: > > ==== > These signals begin to fade after they have traveled a certain distance, > so it's necessary to build amplifiers into the cable every so often. In > the case of FLAG, the spacing of these amplifiers ranges from 45 to 85 > kilometers. They work on a strikingly simple and elegant principle. Each > amplifier contains an approximately 10-meter-long piece of special fiber > that has been doped with erbium ions, making it capable of functioning > as a laser medium. A separate semiconductor laser built into the > amplifier generates powerful light at 1,480 nm - close to the same > frequency as the signal beam, but not close enough to interfere with it. > This light, directed into the doped fiber, pumps the electrons orbiting > around those erbium ions up to a higher energy level. > > The signal coming down the FLAG cable passes through the doped fiber and > causes it to lase, i.e., the excited electrons drop back down to a lower > energy level, emitting light that is coherent with the incoming signal - > which is to say that it is an exact copy of the incoming signal, except > more powerful. > > ==== > > Cordially > > Patrick Giagnocavo > patrick at zill.net > > From mloftis at wgops.com Mon Oct 4 17:24:55 2010 From: mloftis at wgops.com (Michael Loftis) Date: Mon, 04 Oct 2010 16:24:55 -0600 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: --On Monday, October 04, 2010 9:54 AM -0700 John Adams wrote: > Without proper SPF records your mail stands little chance of making it > through some of the larger providers, like gmail, if you are sending > in any high volume. You should be using SPF, DK, and DKIM signing. > > I don't really understand how your security company related SPF to DoS > though. They're unrelated, with the exception of backscatter. FUD most likely, that's the stock in trade for almost all "security audit" firms. > > -j From randy at psg.com Mon Oct 4 17:27:46 2010 From: randy at psg.com (Randy Bush) Date: Tue, 05 Oct 2010 07:27:46 +0900 Subject: A New TransAtlantic Cable System In-Reply-To: References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> <4CAA11BC.3010606@zill.net> Message-ID: > With regards to the Wired Article, I still have my copy of that issue > and would consider that article perhaps my favorite magazine article > of all time. i too thought that a great article and often point folk to it. sadly, the copy on the wired web site does not have the figures :( randy From kevin at steadfast.net Mon Oct 4 17:55:28 2010 From: kevin at steadfast.net (Kevin Stange) Date: Mon, 04 Oct 2010 17:55:28 -0500 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> Message-ID: <4CAA5B60.8000001@steadfast.net> On 10/04/2010 11:47 AM, Greg Whynott wrote: > > A partner had a security audit done on their site. The report said they were at risk of a DoS due to the fact they didn't have a SPF record. We publish a ~all record for our domain. I think it's bad practice to publish any other result because you're making assertions which are almost definitely untrue. +all implies that anywhere on the internet is a valid origination, and -all implies you are certain nothing else could ever send an email on behalf of your domain. The most common situation where another host sends on your domain's behalf is a forwarding MTA, such as NANOG's mailing list. A lot of MTAs will only trust that the final MTA handling the message is a source host. In the case of a mailing list, that's NANOG's server. All previous headers are untrustworthy and could easily be forged. I'd bet few, if any, people have NANOG's servers listed in their SPF, and delivering a -all result in your SPF could easily cause blocked mail for anyone that drops hard failing messages. If you're going to filter using SPFs, I believe best practice is to consider all mail from a +all or neutral record the same as mail that soft or hard fails a ~all or -all record. By filtering, I mean I would simply subject those messages to additional testing, but never block exclusively based upon an SPF result. I would just ignore SPF and that's what I do on MTAs I configure. All you'll really be preventing with SPF is some backscatter and messages which forge the source information for domains that have even bothered to publish accurate records. A huge amount of the spam you get will pass SPF (or return neutral) and possibly pass DKIM as well because the big spam operations register new domains and set up SPF before they start spamming. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From randy at psg.com Mon Oct 4 18:39:42 2010 From: randy at psg.com (Randy Bush) Date: Tue, 05 Oct 2010 08:39:42 +0900 Subject: [Nanog-futures] Memberships, Bylaws and other election matters In-Reply-To: References: <4CAA5724.8050506@west.net> Message-ID: >> personally, i am not strongly against it, but am sceptical. it may get >> a cash infusion now, but what will it do to income down the road when >> folk don't need to renew? [0] > > Furthermore, your opposition will surely depress demand even more, > because now folks are saying "why would I pay for a life membership > that Randy, for reasons that are largely inexplicable, would attempt > to revoke, leaving me with no recourse"* first, i find your characterizing my being sceptical as opposition to be almost offensive. i dared to question your oh so wise authority. given the ad hominem defense, i now am far more sceptical and suspicious. second, i have never said i would attempt to revoke it. again you grossly and unjustifiably wildly distort my statement. what i said was i recommended against passing it, and asked steve if he would include it in the "we won't do until consensus is reached" list. i said that very clearly because i thought it unwindable, quite the opposite of what you are attempting to put in my mouth. i used to think you credible. i no longer do. but my opinions and 15 cents will get you on the subway. well, you may also need a time machine. > I get the fellow thing, even if I think its silly. The opposition to > student membership - I even understand that, although I respectfully > disagree. just charge 'em a different fee. > your opposition to life memberships is starting to sound like > reflexive opposition because you feel like being ornery. then try q-tips. >> does newnog actually need the infusion up front? are there other ways >> to deal with the financial problem that the attempt to create of this >> class of membership implies? > Yes, we do. I have done a complete analysis, which I offered to share with > everyone at the community meeting. some of us asked for the pro forma financials to be published many months ago. and now i missed my opportunity by going to kyoto for icnp instead of going to atlanta. damn! and no, the 'budget' on the web site is far from sufficient. > * Of course there IS a recourse if life membership is canceled. Its > called "refund the unused portion of the life membership on a > pro-rated basis". not really good. you made a contract. stick to it. we're not a credit card company or google's so called privacy policy. randy From randy at psg.com Mon Oct 4 19:34:25 2010 From: randy at psg.com (Randy Bush) Date: Tue, 05 Oct 2010 09:34:25 +0900 Subject: [Nanog-futures] Memberships, Bylaws and other election matters In-Reply-To: References: <4CAA5724.8050506@west.net> Message-ID: > Short term cash supply is important; we have a decent lag between now > and NANOG 52 where there will be a significant outflow of cash for > salaries, hotel contracts, etc. without any meeting revenue. yes, the published data do show that plan. and i guess it is not outrageous. a choice between borrowing from other organizations or borrowing from members. unless, of course, one can get gifts. but that's not something on which i would play bet the company. randy From rdobbins at arbor.net Mon Oct 4 20:21:07 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Tue, 5 Oct 2010 01:21:07 +0000 Subject: Request for participation - Arbor 2010 Worldwide Infrastructure Security Report. In-Reply-To: <20101004125703.1E781391@resin17.mta.everyone.net> References: <20101004125703.1E781391@resin17.mta.everyone.net> Message-ID: <5E2AC3D9-1C51-48BA-8503-C5100C045172@arbor.net> On Oct 5, 2010, at 1:27 AM, Scott Weeks wrote: > Why are we required to register to look at the survey? That's how it's set up by the biz folks who provide the funding and resources which allow us to conduct the survey, analyze the responses, and then write and publish the report free of charge each year as a public service to the operational community. If registering to download the report is unduly burdensome, feel free to email me 1:1 and I can provide a copy for you, thanks! ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From Jonathon.Exley at kordia.co.nz Tue Oct 5 00:56:58 2010 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Tue, 5 Oct 2010 18:56:58 +1300 Subject: RIP Justification In-Reply-To: References: <21684634.01285931936789.JavaMail.root@jennyfur.pelican.org> <17485453.21285931953713.JavaMail.root@jennyfur.pelican.org> Message-ID: <035FE016D625174BA7C7A9FA83E6C179871482BDA9@winexmp02> It also scales better from the SP point of view. If you have 1000 L3VPN services on your PE node using OSPF to the customer that would require a lot of memory for the multiple LSDBs and a lot of CPU for the SPF calculations. BGP is nicer but the reality is that many enterprises don't have the know-how. Jonathon -----Original Message----- From: Heath Jones [mailto:hj1980 at gmail.com] Sent: Saturday, 2 October 2010 12:39 a.m. To: Tim Franklin Cc: nanog at nanog.org Subject: Re: RIP Justification On 1 October 2010 12:19, Tim Franklin wrote: > Or BGP. ?Why not? Of course, technically you could use almost any routing protocol. OSPF and IS-IS would require more configuration and maintenance, BGP even more still. I think this is a pretty good example though of how RIPv2 is probably the most appropriate for the job. It doesnt require further configuration from the provider side as new sites are added and is very simple to set up and maintain. This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From owen at delong.com Tue Oct 5 02:45:46 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Oct 2010 00:45:46 -0700 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <27834.1286225948@localhost> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> <4CAA08B8.6060009@mtcc.com> <4CAA0C00.6020106@mtcc.com> <738F7E85-F572-4422-812C-CA48A0952994@delong.com> <27834.1286225948@localhost> Message-ID: <967F5BE7-21F5-492F-9527-044048BC37C4@delong.com> On Oct 4, 2010, at 1:59 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 04 Oct 2010 13:30:55 PDT, Owen DeLong said: > >> Removing a few points probably isn't a bad idea so long as you have a list of >> domains for which points should be added. > > 140 million .coms. Throw-away domains. I do believe that Marcus Ranum had > "trying to enumerate badness" on his list of "Six stupidest security ideas". > This won't scale as long as you have more spammers adding new domains faster > than your NOC staff can add them to the blacklist. > Yes, getting rid of domain tasting and taking some other steps to bring sanity to the domain name process would really help, IMHO. > (And even centralized blacklists run by dedicated organizations haven't solved > the problem yet, so I'm not holding my breath waiting for that to work out...) Fair enough. It's not a panacea, but, it can be a component of a solution. Owen From owen at delong.com Tue Oct 5 02:59:20 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Oct 2010 00:59:20 -0700 Subject: RIP Justification In-Reply-To: <035FE016D625174BA7C7A9FA83E6C179871482BDA9@winexmp02> References: <21684634.01285931936789.JavaMail.root@jennyfur.pelican.org> <17485453.21285931953713.JavaMail.root@jennyfur.pelican.org> <035FE016D625174BA7C7A9FA83E6C179871482BDA9@winexmp02> Message-ID: <2CCE2A12-1039-4885-AF14-3CBFA778E359@delong.com> The knowhow for BGP in that environment is all of about 30 minutes worth of training. They should find a way to get it, IMHO. Owen On Oct 4, 2010, at 10:56 PM, Jonathon Exley wrote: > It also scales better from the SP point of view. If you have 1000 L3VPN services on your PE node using OSPF to the customer that would require a lot of memory for the multiple LSDBs and a lot of CPU for the SPF calculations. > BGP is nicer but the reality is that many enterprises don't have the know-how. > > Jonathon > > -----Original Message----- > From: Heath Jones [mailto:hj1980 at gmail.com] > Sent: Saturday, 2 October 2010 12:39 a.m. > To: Tim Franklin > Cc: nanog at nanog.org > Subject: Re: RIP Justification > > On 1 October 2010 12:19, Tim Franklin wrote: >> Or BGP. Why not? > > Of course, technically you could use almost any routing protocol. > OSPF and IS-IS would require more configuration and maintenance, BGP even more still. > > I think this is a pretty good example though of how RIPv2 is probably the most appropriate for the job. It doesnt require further configuration from the provider side as new sites are added and is very simple to set up and maintain. > > This email and attachments: are confidential; may be protected by > privilege and copyright; if received in error may not be used,copied, > or kept; are not guaranteed to be virus-free; may not express the > views of Kordia(R); do not designate an information system; and do not > give rise to any liability for Kordia(R). > From alexb at ripe.net Tue Oct 5 03:51:04 2010 From: alexb at ripe.net (Alex Band) Date: Tue, 5 Oct 2010 10:51:04 +0200 Subject: [ncc-services-wg] RPKI Resource Certification: building features In-Reply-To: References: <76B62F3C-730C-4E20-A83B-5AFD41A851A7@delong.com> Message-ID: <253F6328-8289-4D2B-9847-5E00D5E1FC38@ripe.net> On 4 Oct 2010, at 23:18, Randy Bush wrote: >> 1) We have not implemented support for this yet. We plan to go live >> with the fully hosted version first and extend it with support for >> non-hosted systems around Q2/Q3 2011. > > this is a significant slip from the 1q11 we were told in prague. care > to explain. Let me run you through the roadmap and the motivation for our choices at RIPE61. In short, everything we do is about providing *value* for our membership and the community. This means that with the resources we have, we have to make a choice between (1) offering a solution with every feature under the sun, but contains little value and usability or (2) we choose to do a phased approach where the entry barrier into the system is low, hassle is taken away from the operator, value and user-friendlyness is high while still being standards compliant and keeping the operator in the driver's seat. Soon we'll get to the full package where all options, like running your own CA, are available. It perhaps just isn't done in the order that a purist would like to see. Let me illustrate with two examples: I've delivered full day training courses on Routing Registry and DNSSEC. With the RR course, by the time I was done explaining how to use the IRRToolset to aid in making routing decisions based on the IRR, people had given up and decided that doing it manually was easier. Like you said at RIPE60: "people are voting with their feet." In the DNSSEC training, by the time I was done explaining how to do a manual key roll-over, most LIRs decided 'this is not for me, the cure is worse than the disease'. This is why I want to get back to my original point, Randy. You agreed in your first reply to me that something has to be done to create an easy way to get started with the system. We can provide a full, standards-compliant solution with up/down and every other feature, but how is that going to get all ~350,000 prefixes and ~35,000 ASs into the system with ROAs? Manually? I proposed an IRR+BGP import system as a value-added tool to help a network operator get started making ROAs. That's a pretty good starting point. Where do you suggest we go from here? Of course I appreciate everyone else's response to this thread as well! :) Cheers, -Alex From nick at foobar.org Tue Oct 5 05:01:14 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 05 Oct 2010 11:01:14 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> Message-ID: <4CAAF76A.4040101@foobar.org> On 04/10/2010 18:24, Heath Jones wrote: > I'm not clever enough to know of some way that you could do optical > regeneration without converting the signal to electrical and > retransmitting back as optical.. How is that done? Wikipedia has a useful article on this: http://en.wikipedia.org/wiki/EDFA Nick From randy at psg.com Tue Oct 5 06:10:46 2010 From: randy at psg.com (Randy Bush) Date: Tue, 05 Oct 2010 20:10:46 +0900 Subject: [ncc-services-wg] RPKI Resource Certification: building features In-Reply-To: <253F6328-8289-4D2B-9847-5E00D5E1FC38@ripe.net> References: <76B62F3C-730C-4E20-A83B-5AFD41A851A7@delong.com> <253F6328-8289-4D2B-9847-5E00D5E1FC38@ripe.net> Message-ID: alex, i am not gonna argue with you. 96% of your users will be happy for you to do everything for them, despite the fact that the wrong holder has the keys (and, as john says, the liability). but 96% of your address space, i.e. the large holders, will want to hold their own keys and talk up/down to you and deal with publication points. kinda like the irr. so write back when you have done the full job. randy From stb at lassitu.de Tue Oct 5 07:37:07 2010 From: stb at lassitu.de (Stefan Bethke) Date: Tue, 5 Oct 2010 14:37:07 +0200 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <4CAA5B60.8000001@steadfast.net> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> <4CAA5B60.8000001@steadfast.net> Message-ID: Am 05.10.2010 um 00:55 schrieb Kevin Stange: > The most common situation where another host sends on your domain's > behalf is a forwarding MTA, such as NANOG's mailing list. Proper mailing lists don't do that (i. e. nanog with Mailman): Return-Path: -- Stefan Bethke Fon +49 151 14070811 From jloiacon at csc.com Tue Oct 5 08:08:06 2010 From: jloiacon at csc.com (Joe Loiacono) Date: Tue, 5 Oct 2010 09:08:06 -0400 Subject: A New TransAtlantic Cable System In-Reply-To: References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> <4CAA11BC.3010606@zill.net> Message-ID: Dorn Hetzel wrote on 10/04/2010 06:22:58 PM: > With regards to the Wired Article, I still have my copy of that issue and > would consider that article perhaps my favorite magazine article of all > time. Same here. A classic. From hj1980 at gmail.com Tue Oct 5 08:52:19 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 5 Oct 2010 14:52:19 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> <4CAA11BC.3010606@zill.net> Message-ID: >> What's that quote again...? >> Oh, that's it: "The more you know, the more you know you don't." >> It feels very appropriate now :) > I was wondering for quite some time if there was a scientific term for that > effect, since many of us seem to run into the opposite quite often. It turns > out that it's the Dunning-Kruger effect: > http://en.wikipedia.org/wiki/Dunning-Kruger_effect Ignorant bliss! :) From deric.kwok2000 at gmail.com Tue Oct 5 09:01:19 2010 From: deric.kwok2000 at gmail.com (Deric Kwok) Date: Tue, 5 Oct 2010 10:01:19 -0400 Subject: Anyone can share the Network card experience Message-ID: Hi Anyone can share the Network card experience ls onborad PCI Expresscard better or Plug in slot PCI Express card good? How are their performance in Gig transfer rate? Thank you so much From ctracy at es.net Tue Oct 5 09:09:23 2010 From: ctracy at es.net (Chris Tracy) Date: Tue, 5 Oct 2010 10:09:23 -0400 Subject: A New TransAtlantic Cable System In-Reply-To: References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> Message-ID: <84B0201D-8843-4DD8-926C-CBD2B400A29F@es.net> Heath, >> By the way, my recollection is the undersea regenerators do purely optical regeneration. >> There is no O-E conversions undersea, only at the landing stations and terrestrial components. > > I'm not clever enough to know of some way that you could do optical > regeneration without converting the signal to electrical and > retransmitting back as optical.. How is that done? Erbium Doped Fiber Amplifiers (EDFAs) do not re-shape or re-time the signals (the last 2 R's in 3R -- re-amplification, re-shaping, and re-timing). Raman is another popular amplification technology, widely used in long-haul WDM. Some systems have the flexibility of using EDFA and Raman amps on the same spans. EDFAs amplify a band of spectrum (C- and/or L-band, depending on the device) -- signal *and* noise. The amplified noise floor is clearly visible if you connect an optical spectrum analyzer to the output of an EDFA -- you see a big wide bump across the entire amplified band with spikes for each wavelength. An optical signal can only go through so many EDFAs before it becomes too degraded to be accurately converted back to an electrical signal by the receiver -- either due to dispersion (especially if uncompensated) or noise, tolerances of which are different for every device...(EDFAs introduce some amount of noise, so OSNR before EDFA != OSNR after EDFA :-) ) That being said, one can find examples of all-optical regeneration [1], but I do not know of any transport vendors who have integrated this capability into currently shipping products. (Some have developed various tricks like electronic dispersion compensation, but IIRC, these work by pre-distorting the signal.) Getting back to the original post from this thread -- when I first read it, I immediately wondered whether the vendor might be using coherent optical receivers which have much higher dispersion tolerances, allowing the optical signal to travel much further without OEO conversions (see [2] and [3] for some background). Unfortunately, I could not find any evidence one way or the other about what Hibernia is doing. In fact, Per Hansen from Ciena just so happens to be talking about coherent receiver technology [DP-QPSK encoding & DSP analysis] as I write this e-mail... Cheers, -Chris [1] 3R optical regeneration: an all-optical solution with BER improvement, http://www.opticsinfobase.org/abstract.cfm?URI=oe-14-14-6414 [2] Coherent receivers enable next-generation transport, http://www.lightwaveonline.com/about-us/lightwave-issue-archives/issue/coherent-receivers-enable-next-generation-transport-53426202.html [3] Optical hybrid, http://en.wikipedia.org/wiki/Optical_hybrid -- Chris Tracy Energy Sciences Network (ESnet) Lawrence Berkeley National Laboratory From nick at brevardwireless.com Tue Oct 5 09:09:17 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Tue, 5 Oct 2010 10:09:17 -0400 Subject: Anyone can share the Network card experience Message-ID: <2b4a1576$53008cec$731c06c5$@com> IMHO, Nothing beats a good intel NIC. I'm a big fan of the intel pro/1000GT. In terms of performance, I think it is more determined by the card chipset. Nick Olsen Network Operations (877) 804-3001 x106 ---------------------------------------- From: "Deric Kwok" Sent: Tuesday, October 05, 2010 10:01 AM To: "nanog list" Subject: Anyone can share the Network card experience Hi Anyone can share the Network card experience ls onborad PCI Expresscard better or Plug in slot PCI Express card good? How are their performance in Gig transfer rate? Thank you so much From hj1980 at gmail.com Tue Oct 5 09:13:00 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 5 Oct 2010 15:13:00 +0100 Subject: Anyone can share the Network card experience In-Reply-To: References: Message-ID: It depends on the speed of the PCI slot. In saying that, you are only trying to transfer 1Gb/s. http://en.wikipedia.org/wiki/PCI_Express Note the thoughts on there about full duplex.. "PCI Express 1.0a In 2003, PCI-SIG introduced PCIe 1.0a, with a data rate of 250 MB/s and a transfer rate of 2.5 GT/s." "PCI Express 2.0 PCI-SIG announced the availability of the PCI Express Base 2.0 specification on 15 January 2007.[9] The PCIe 2.0 standard doubles the per-lane throughput from the PCIe 1.0 standard's 250 MB/s to 500 MB/s. This means a 32-lane PCI connector (x32) can support throughput up to 16 GB/s aggregate. The PCIe 2.0 standard uses a base clock speed of 5.0 GHz, while the first version operates at 2.5 GHz." I can't give you practical advice, but its a good place to start your reading... Cheers Heath On 5 October 2010 15:01, Deric Kwok wrote: > Hi > > Anyone can share the Network card experience > > ls onborad PCI Expresscard better or Plug in slot PCI Express card good? > > How are their performance in Gig transfer rate? > > Thank you so much > > From eric at roxanne.org Tue Oct 5 09:25:11 2010 From: eric at roxanne.org (Eric Gauthier) Date: Tue, 5 Oct 2010 10:25:11 -0400 Subject: Rough cost for monitoring Message-ID: <20101005142511.GA19330@roxanne.org> Heya, I'm trying to quickly pull together some very rough budget numbers for purchasing a full monitoring system (network, server, security, facilities). Is there a source for rough unit costs? If not, does anyone have recent RFI pricing that they'd be willing to share? Eric :0 From Greg.Whynott at oicr.on.ca Tue Oct 5 09:36:16 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Tue, 5 Oct 2010 10:36:16 -0400 Subject: Rough cost for monitoring In-Reply-To: <20101005142511.GA19330@roxanne.org> References: <20101005142511.GA19330@roxanne.org> Message-ID: <9C15EEAA-4AE8-46DF-8E10-DAE54B63FD62@oicr.on.ca> get a VAR involved, it'll be more efficient and accurate than asking here. things change weekly. -g On Oct 5, 2010, at 10:25 AM, Eric Gauthier wrote: > Heya, > > I'm trying to quickly pull together some very rough > budget numbers for purchasing a full monitoring > system (network, server, security, facilities). Is > there a source for rough unit costs? If not, does > anyone have recent RFI pricing that they'd be willing > to share? > > Eric :0 > From dotis at mail-abuse.org Tue Oct 5 09:43:23 2010 From: dotis at mail-abuse.org (Douglas Otis) Date: Tue, 05 Oct 2010 10:43:23 -0400 Subject: do you use SPF TXT RRs? (RFC4408) In-Reply-To: <4CAA5B60.8000001@steadfast.net> References: <9C9322AB-CB58-405A-ADA5-A74B2238A2B3@oicr.on.ca> <4CAA5B60.8000001@steadfast.net> Message-ID: <4CAB398B.3050009@mail-abuse.org> On 10/4/10 6:55 PM, Kevin Stange wrote: > The most common situation where another host sends on your domain's > behalf is a forwarding MTA, such as NANOG's mailing list. A lot of MTAs > will only trust that the final MTA handling the message is a source > host. In the case of a mailing list, that's NANOG's server. All > previous headers are untrustworthy and could easily be forged. I'd bet > few, if any, people have NANOG's servers listed in their SPF, and > delivering a -all result in your SPF could easily cause blocked mail for > anyone that drops hard failing messages. Kevin, nanog.org nor mail-abuse.org publish spf or txt records containing spf content. If your MTA expects a message's MailFrom or EHLO be confirmed using spf, then you will not receive this message, refuting "a lot of MTAs ...". This also confuses SPF with Sender-ID. SPF confirms the EHLO and MailFrom, whereas Sender-ID confirms the PRA. However, the PRA selection is flawed since it permits forged headers most consider to be the originator. To prevent Sender-ID from misleading recipients or failing lists such as nanog.org, replicate SPF version 2 records at the same node declaring mfrom. This is required but doubles the DNS payload. :^( Many consider -all to be an ideal, but this reduces delivery integrity. MailFrom local-part tagging or message id techniques can instead reject spoofed bounces without a reduction in delivery integrity. -Doug From Greg.Whynott at oicr.on.ca Tue Oct 5 09:50:57 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Tue, 5 Oct 2010 10:50:57 -0400 Subject: Anyone can share the Network card experience In-Reply-To: References: Message-ID: the question of which is better, onboard vrs plug in would in part be determined by the type (make/model) of motherboard you are speaking of. How they have IRQs allocated (which is something you may be able to adjust), where it is attached to the bus etc? Also, what comes with the main board is what you get. You can purchase option NICs with extra processors (TOE for example) which offload your main CPU. For 10Gbit we use Intel cards for production service machines, and ConnextX/Intel in the HPC cluster. -g On Oct 5, 2010, at 10:01 AM, Deric Kwok wrote: > Hi > > Anyone can share the Network card experience > > ls onborad PCI Expresscard better or Plug in slot PCI Express card good? > > How are their performance in Gig transfer rate? > > Thank you so much > From hj1980 at gmail.com Tue Oct 5 09:59:56 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 5 Oct 2010 15:59:56 +0100 Subject: Anyone can share the Network card experience In-Reply-To: References: Message-ID: > For 10Gbit we use Intel cards for production service machines, ?and ConnextX/Intel in the HPC cluster. Greg - I've not been exposed to 10G on the server side.. Does the server handle the traffic load well (even with offloading) - that's a LOT of web requests / app queries per second! Or are you using 10G mainly for iSCSI / file serving / static content? Cheers From Charles at knownelement.com Tue Oct 5 10:01:12 2010 From: Charles at knownelement.com (Charles n wyble) Date: Tue, 05 Oct 2010 08:01:12 -0700 Subject: Rough cost for monitoring In-Reply-To: <20101005142511.GA19330@roxanne.org> References: <20101005142511.GA19330@roxanne.org> Message-ID: <6cc4410c-84b6-4ab6-887c-45a1c8a87fcb@email.android.com> One would need to know a lot more about the specifics of your requirements. My suggestion would be to invest money in qualified people to watch over something like opennms or (my favorite) a combination of alienvault and opsview. "Eric Gauthier" wrote: >Heya, > >I'm trying to quickly pull together some very rough >budget numbers for purchasing a full monitoring >system (network, server, security, facilities). Is >there a source for rough unit costs? If not, does >anyone have recent RFI pricing that they'd be willing >to share? > >Eric :0 > -- from the desk of Charles wyble ceo & president known element enterprises xmpp/sip/smtp: charles at knownelement.com legacy pstn: 818 280 7059 From ctracy at es.net Tue Oct 5 10:02:47 2010 From: ctracy at es.net (Chris Tracy) Date: Tue, 5 Oct 2010 11:02:47 -0400 Subject: Anyone can share the Network card experience In-Reply-To: <2b4a1576$53008cec$731c06c5$@com> References: <2b4a1576$53008cec$731c06c5$@com> Message-ID: <9F675EC5-C905-4BAE-BBD2-DEA4A790E681@es.net> >> Anyone can share the Network card experience >> ls onborad PCI Expresscard better or Plug in slot PCI Express card good? >> How are their performance in Gig transfer rate? > IMHO, Nothing beats a good intel NIC. > I'm a big fan of the intel pro/1000GT. > In terms of performance, I think it is more determined by the card chipset. The e1000 & e1000e linux driver docs include READMEs which detail some of the diffs between the various chipsets used by these NICs: http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=9180&keyword=e1000&lang=eng http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=15817&keyword=e1000e&lang=eng Some support jumbo frames, some do not. I've seen some server motherboards come with two different on-board 8257x chipsets on the same board -- one that supports jumbo and one that does not (yikes!) The driver can make a huge difference in performance. If your driver sucks, don't expect performance to be much better. e1000/e1000e in Linux has a lot of tweakables, and getting these running at line-rate in a LAN is not that difficult. You motherboard manual (bus topology) and output of 'lspci -tv' can help you determine the best PCI slot to stick the card into to avoid contention. Some cards support checksum offloading, 'ethtool -S' can often tell you whether that's working or not, etc. -Chris -- Chris Tracy Energy Sciences Network (ESnet) Lawrence Berkeley National Laboratory From Greg.Whynott at oicr.on.ca Tue Oct 5 10:23:07 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Tue, 5 Oct 2010 11:23:07 -0400 Subject: Anyone can share the Network card experience In-Reply-To: References: Message-ID: Hi, most of our traffic is heading directly into memory, not hitting the local disks, on the HPC end of things. Our file servers are feeding the network with around 24 x 10Gibit (active/active clusters), and regularly run at over 80 percent on all ports during runs.. this is all HPC / file movement traffic. we have instruments which generate over 6TB of data per run, every 3 days, 7/365. we have about 20 of these instruments. so most of the data on 10Gbit is indeed static, or to/from a file server to/from HPC clusters. iSCSI we run on its own network hardware, autonomous from the 'data' network. its not in wide deployment here, only the file server is connected via 10Gbit, the hosts using iSCIS (predominately KVM and Vmware clusters) are being feed over multiple 1Gbit links for their iSCIS requirements. Our external internet servers are connected to the internet via 1Gbit links, not 10Gibt, but apparently that is coming next year. The type of traffic they'll see will not be very chatty/interactive. it'll be researchers downloading data sets ranging in size from a few hundred megs, to a few TB.. take care, -g On Oct 5, 2010, at 10:59 AM, Heath Jones wrote: >> For 10Gbit we use Intel cards for production service machines, and ConnextX/Intel in the HPC cluster. > > Greg - I've not been exposed to 10G on the server side.. > Does the server handle the traffic load well (even with offloading) - > that's a LOT of web requests / app queries per second! > > Or are you using 10G mainly for iSCSI / file serving / static content? > > Cheers From hj1980 at gmail.com Tue Oct 5 10:33:08 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 5 Oct 2010 16:33:08 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: <84B0201D-8843-4DD8-926C-CBD2B400A29F@es.net> References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> <84B0201D-8843-4DD8-926C-CBD2B400A29F@es.net> Message-ID: > Erbium Doped Fiber Amplifiers (EDFAs) do not re-shape or re-time the signals (the last 2 R's in 3R -- re-amplification, re-shaping, and re-timing).... Thanks Chris - even more reading to do :) It's interesting stuff that's for sure. This is also pretty cool: http://en.wikipedia.org/wiki/Chirped-pulse_amplification I just had a thought about EFDA - please forgive my lack of terminology though, i'll try to explain: Say you have signal coming in to EFDA, the signal is just amplified (as you said, also noise - the whole source signal). Would it be possible to extract via PLL or similar the source clock and use that to modulate the amplifier power? Does it work with QPSK / whatever keying is used? Would that even help with the noise issue at all, or am I waaaaay off? Cheers From michael at rancid.berkeley.edu Tue Oct 5 10:55:40 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 05 Oct 2010 08:55:40 -0700 Subject: ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes) Message-ID: <4CAB4A7C.2080500@rancid.berkeley.edu> > Michael Sinatra, UCB; what are thoughts around best practices for > auth DNS server in ILNP world, and how do you handle updates for > locator values to the auth servers when a link changes? > A: you need > DNSsec to be running, you make updates, you check authenticity of the > update, etc. How will other networks know about the changes. The initial answer to my question didn't quite get the point of the question, so I followed up. I think ILNP is very interesting because it attempts to create a true I/L split via naming semantics. However, it relies on DNS to do this. Somewhere, there has to be an authoritative DNS server(s) that have the prefix list and preferences for the site. (In ILNP, each host can have its own list of preferred prefixes in the form of L64 records, or they can defer to a site-wide L64 RRset with the LP record.) I acknowledge that this requires a secure dynamic update mechanism (presumably with the border routers doing the updates), and it requires very low ttls to improve convergence. Where this becomes interesting from an operational perspective is when I think about how to address authoritative DNS servers in an ILNP world. The DNS server itself has to be reachable, and the prefix list for the DNS server must be updated when the network topology changes. Hence the question: How should I provision authoritative DNS servers, given that the prefix information is provided via DNS--including the prefix information for the DNS servers themselves--leading to a chicken-and-egg problem. In addition, I would assume that I need something similar to glue records (instead of A or AAAA glue, I need L64 or LP glue). I think one answer would be to have all of my authoritative servers in someone else's network, where they could maintain all of the L64 records completely independent of my DNS infrastructure. With the DNS servers in my network, I don't think there's an answer to the chicken-and-egg problem. Of course, if one of their upstreams dies, my DNS may suffer if I can't withdraw my partner's network's prefixes from the L64 record for my DNS server. This blends into Danny's comment about routing relying on DNS and DNS relying on routing, and to Dave's comment on the binding between the identity and locator being a critical (and difficult) component of the I/L split. I realize that the distinction between operations and protocol development in this discussion may be subject to interpretation, but I also think it's important to understand the operational implications of developing protocols early on. michael From dot at dotat.at Tue Oct 5 11:18:58 2010 From: dot at dotat.at (Tony Finch) Date: Tue, 5 Oct 2010 17:18:58 +0100 Subject: ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes) In-Reply-To: <4CAB4A7C.2080500@rancid.berkeley.edu> References: <4CAB4A7C.2080500@rancid.berkeley.edu> Message-ID: On Tue, 5 Oct 2010, Michael Sinatra wrote: > > Hence the question: How should I provision authoritative DNS servers, > given that the prefix information is provided via DNS--including the > prefix information for the DNS servers themselves--leading to a > chicken-and-egg problem. In addition, I would assume that I need > something similar to glue records (instead of A or AAAA glue, I need L64 > or LP glue). Isn't glue the answer to your question? Your name servers get their prefixes from the networks they are connected to, and they do dynamic updates to their parent zone as well as their own zone's master. Then other sites can find them using the usual referral chasing. I am assuming that the name server's name is in a zone for which it is authoritative. If not, it doesn't appear in glue so it doesn't need to update the parent zone. This implies that the name a DNS server uses to refer to itself (i.e. the name for which it performs dynamic updates for its prefix) must be used by all NS records that refer to the name server, so that resolvers can find the server's up-to-date prefix recods. This is stricter than is common in the current DNS - for example, the NS records for my domain do not use the names chosen by those servers' admins. I do this because I think in-bailiwick name server names are a good idea. I don't know if or how much DNSSEC might change the balance of opinion in this area. One thing it doesn't change is the quite astounding amounts of transitive trust that can be introduced by outsourcing your DNS including the nameserver names. http://shinobi.dempsky.org/~matthew/dnstrust/graphs/ So I don't think your question is relevant for most zones. It *is* relevant for the root. ILNP will have to come up with a new scheme for the root zone hints. I haven't looked at it in enough detail to see if they already have a plan. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From florin at futurefreedom.ro Tue Oct 5 11:41:53 2010 From: florin at futurefreedom.ro (Florin Veres) Date: Tue, 5 Oct 2010 19:41:53 +0300 Subject: Level3 filter updates Message-ID: Hey guys, Anyone knows how often does Level3 update their filters? I have a prefix in Europe which has a route-obj from Sunday, it's accepted in Level3 Europe from Monday, but in the US it's still not accepted. Thanks, Florin From pstewart at nexicomgroup.net Tue Oct 5 11:50:16 2010 From: pstewart at nexicomgroup.net (Paul Stewart) Date: Tue, 5 Oct 2010 12:50:16 -0400 Subject: Level3 filter updates In-Reply-To: References: Message-ID: Normally it's done every night (overnight)... that's been our experience... Paul -----Original Message----- From: Florin Veres [mailto:florin at futurefreedom.ro] Sent: Tuesday, October 05, 2010 12:42 PM To: nanog at nanog.org Subject: Level3 filter updates Hey guys, Anyone knows how often does Level3 update their filters? I have a prefix in Europe which has a route-obj from Sunday, it's accepted in Level3 Europe from Monday, but in the US it's still not accepted. Thanks, Florin From morrowc.lists at gmail.com Tue Oct 5 11:52:49 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 5 Oct 2010 12:52:49 -0400 Subject: ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes) In-Reply-To: References: <4CAB4A7C.2080500@rancid.berkeley.edu> Message-ID: On Tue, Oct 5, 2010 at 12:18 PM, Tony Finch wrote: > On Tue, 5 Oct 2010, Michael Sinatra wrote: >> >> Hence the question: How should I provision authoritative DNS servers, >> given that the prefix information is provided via DNS--including the >> prefix information for the DNS servers themselves--leading to a >> chicken-and-egg problem. ?In addition, I would assume that I need >> something similar to glue records (instead of A or AAAA glue, I need L64 >> or LP glue). > > Isn't glue the answer to your question? Your name servers get their > prefixes from the networks they are connected to, and they do dynamic If i have my NS in my network, which is 'ILNP enabled' (if there would be such a thing), I think Michael's question is ... how do I tell DNS where my NS is if my NS is moving and doesn't have a single long-lived stable address ? Some of the answer may be: "Don't do that!", or "plan your moves properly, follow rfcXXXX which shows steps and timing to migrate an NS device/pair/set from network attachment point to network attachment point". -chris From bclark at spectraaccess.com Tue Oct 5 11:55:55 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 05 Oct 2010 12:55:55 -0400 Subject: Level3 filter updates In-Reply-To: References: Message-ID: <4CAB589B.90704@spectraaccess.com> I was told every 48 hours when I recently dealt with Level3 on a similar thing about a month ago. On 10/05/2010 12:50 PM, Paul Stewart wrote: > Normally it's done every night (overnight)... that's been our experience... > > Paul > > > -----Original Message----- > From: Florin Veres [mailto:florin at futurefreedom.ro] > Sent: Tuesday, October 05, 2010 12:42 PM > To: nanog at nanog.org > Subject: Level3 filter updates > > Hey guys, > > Anyone knows how often does Level3 update their filters? > I have a prefix in Europe which has a route-obj from Sunday, it's accepted > in Level3 Europe from Monday, but in the US it's still not accepted. > > Thanks, > Florin > From ctracy at es.net Tue Oct 5 12:05:14 2010 From: ctracy at es.net (Chris Tracy) Date: Tue, 5 Oct 2010 13:05:14 -0400 Subject: A New TransAtlantic Cable System In-Reply-To: References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> <84B0201D-8843-4DD8-926C-CBD2B400A29F@es.net> Message-ID: <1E696AE6-F5AB-41E7-A235-F234CAC930F7@es.net> Heath, > I just had a thought about EFDA - please forgive my lack of > terminology though, i'll try to explain: > Say you have signal coming in to EFDA, the signal is just amplified > (as you said, also noise - the whole source signal). > Would it be possible to extract via PLL or similar the source clock > and use that to modulate the amplifier power? > Does it work with QPSK / whatever keying is used? > Would that even help with the noise issue at all, or am I waaaaay off? Although you can amplify just a single wavelength with an EDFA (has to be in the 1550nm range, not 1310nm), most deployments are using EDFAs in a DWDM environment. The C-band alone consists of ~5THz (5000GHz) of spectrum between 191.00-195.95 Thz. Some systems pack 40 wavelengths into this space at 100GHz spacing, some 80 channels @ 50GHz spacing, others 160 @ 25GHz. Each of these signals is independent, they can each be using different modulation/bitrate/etc. The amplifiers are completely ignorant to what is going on with each channel, only the devices performing conversion back to the electrical domain need to care about these details (after the incoming light has been demultiplexed into individual signals, of course). Re: amplifier power... Amplifier gain should really stay constant unless new wavelengths are added/removed from the fiber. There are fixed-gain and variable-gain amps. VGAs have the advantage that engineers do not need to manually re-balance power levels whenever a large number of wavelengths are added or removed from a span, they adjust automatically. Newer DWDM systems should all have VGAs whereas a lot of earlier generation DWDM systems still use fixed-gain amps. With the older fixed-gain amps, you had to have the input power just right -- hence the need to re-balance if your aggregate signal changes a lot -- too low and the EDFA would not kick on at all, too high and you'd saturate the amp. -Chris -- Chris Tracy Energy Sciences Network (ESnet) Lawrence Berkeley National Laboratory From mpetach at netflight.com Tue Oct 5 12:07:44 2010 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 5 Oct 2010 10:07:44 -0700 Subject: 2010.10.05 NANOG50 Tuesday morning notes Message-ID: Notes from NANOG50 day 2 (Tuesday) morning session are now posted at http://kestrel3.netflight.com/2010.10.05-NANOG50-morning-notes.txt Again, apologies for misspelled names, typos, etc. I'm dashing to lunch now, but can fix things when I get back. ^_^;; Matt From hj1980 at gmail.com Tue Oct 5 12:32:46 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 5 Oct 2010 18:32:46 +0100 Subject: A New TransAtlantic Cable System In-Reply-To: <1E696AE6-F5AB-41E7-A235-F234CAC930F7@es.net> References: <20101002150939.1E79C00B@resin16.mta.everyone.net> <1E8B940C5E21014AB8BE70B975D40EDB039584C3@bert.HiberniaAtlantic.local> <84B0201D-8843-4DD8-926C-CBD2B400A29F@es.net> <1E696AE6-F5AB-41E7-A235-F234CAC930F7@es.net> Message-ID: >> Would it be possible to extract via PLL or similar the source clock >> and use that to modulate the amplifier power? > Although you can amplify just a single wavelength with an EDFA (has to be in the 1550nm range, not 1310nm), most deployments are using EDFAs in a DWDM environment. ?The C-band alone consists of ~5THz (5000GHz) of spectrum between 191.00-195.95 Thz. ?Some systems pack 40 wavelengths into this space at 100GHz spacing, some 80 channels @ 50GHz spacing, others 160 @ 25GHz. ?Each of these signals is independent, they can each be using different modulation/bitrate/etc. ?The amplifiers are completely ignorant to what is going on with each channel, only the devices performing conversion back to the electrical domain need to care about these details (after the incoming light has been demultiplexed into individual signals, of course). I'm wondering if it could be done per wavelength? I guess that would be pretty ridiculous having demux + 160 * decoder + 160 * efda + mux.. Just wondering if the theory works though? From powerzone7 at gmail.com Tue Oct 5 12:57:56 2010 From: powerzone7 at gmail.com (powerzone7 at gmail.com) Date: Tue, 5 Oct 2010 13:57:56 -0400 Subject: Level3 filter updates Message-ID: Level 3 updates their filters every night. I used to work @ level3 From michael at rancid.berkeley.edu Tue Oct 5 13:52:28 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 05 Oct 2010 11:52:28 -0700 Subject: ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes) In-Reply-To: References: <4CAB4A7C.2080500@rancid.berkeley.edu> Message-ID: <4CAB73EC.1030204@rancid.berkeley.edu> On 10/5/10 9:18 AM, Tony Finch wrote: > On Tue, 5 Oct 2010, Michael Sinatra wrote: >> >> Hence the question: How should I provision authoritative DNS servers, >> given that the prefix information is provided via DNS--including the >> prefix information for the DNS servers themselves--leading to a >> chicken-and-egg problem. In addition, I would assume that I need >> something similar to glue records (instead of A or AAAA glue, I need L64 >> or LP glue). > > Isn't glue the answer to your question? Your name servers get their > prefixes from the networks they are connected to, and they do dynamic > updates to their parent zone as well as their own zone's master. Then > other sites can find them using the usual referral chasing. Which then implies that parent zones must use DDNS, and must enable secure updates from the child (from wherever the child's DDNS updates are sourced). In addition, the LP and/or L64 records must have very low TTLs, which is very different from the way we do glue today. > I am assuming that the name server's name is in a zone for which it is > authoritative. If not, it doesn't appear in glue so it doesn't need to > update the parent zone. Yes. That's what I was implying. [snip] > So I don't think your question is relevant for most zones. It *is* > relevant for the root. ILNP will have to come up with a new scheme for the > root zone hints. I haven't looked at it in enough detail to see if they > already have a plan. My question was essentially whether this has been thought out from the DNS perspective. The root hints are one issue. Having (for example) .com able to accept dynamic updates from foo.com's BGP-speaking border router whenever foo.com's routing changes (i.e. dropping an upstream because a link went down), having very low ttls (<60sec) on L64 "glue" records which must be queried in order to reach the authoritative nameserver, and having the infrastructure be able to keep up with such queries may also be an issue. Does ILNP have a solution/recommendation for this? From michael at rancid.berkeley.edu Tue Oct 5 14:03:41 2010 From: michael at rancid.berkeley.edu (Michael Sinatra) Date: Tue, 05 Oct 2010 12:03:41 -0700 Subject: ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes) In-Reply-To: References: <4CAB4A7C.2080500@rancid.berkeley.edu> Message-ID: <4CAB768D.8060804@rancid.berkeley.edu> On 10/5/10 9:52 AM, Christopher Morrow wrote: > On Tue, Oct 5, 2010 at 12:18 PM, Tony Finch wrote: >> On Tue, 5 Oct 2010, Michael Sinatra wrote: >>> >>> Hence the question: How should I provision authoritative DNS servers, >>> given that the prefix information is provided via DNS--including the >>> prefix information for the DNS servers themselves--leading to a >>> chicken-and-egg problem. In addition, I would assume that I need >>> something similar to glue records (instead of A or AAAA glue, I need L64 >>> or LP glue). >> >> Isn't glue the answer to your question? Your name servers get their >> prefixes from the networks they are connected to, and they do dynamic > > If i have my NS in my network, which is 'ILNP enabled' (if there would > be such a thing), I think Michael's question is ... how do I tell DNS > where my NS is if my NS is moving and doesn't have a single long-lived > stable address ? > > Some of the answer may be: "Don't do that!", or "plan your moves > properly, follow rfcXXXX which shows steps and timing to migrate an NS > device/pair/set from network attachment point to network attachment > point". If I am multi-homed and my NS is in my ILNP-enabled network, then it is subject to "moving" at any time. If I lose an upstream due to a sudden failure (such as a link failure), then I need to signal that the lost upstream's prefix should no longer be used. This requires a DDNS update to my L64 record(s). The issue is how should I deal with the situation that you need to know the correct L64 record to get to my network (without waiting for a timeout if you try the broken prefix first) and the way to know what the correct prefixes are is to query a nameserver that's in my network. But to get to my network, you need to know the correct L64 record...etc. So I need to keep nameservers out of my network or have the ability to update an L64 "glue" record on-the-fly in the parent (which also implies a very low ttl on the parent L64 glue record). michael From dot at dotat.at Tue Oct 5 14:23:07 2010 From: dot at dotat.at (Tony Finch) Date: Tue, 5 Oct 2010 20:23:07 +0100 Subject: ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes) In-Reply-To: <4CAB73EC.1030204@rancid.berkeley.edu> References: <4CAB4A7C.2080500@rancid.berkeley.edu> <4CAB73EC.1030204@rancid.berkeley.edu> Message-ID: On Tue, 5 Oct 2010, Michael Sinatra wrote: > > Which then implies that parent zones must use DDNS, and must enable secure > updates from the child (from wherever the child's DDNS updates are sourced). Yes, well if the authentication can be sorted out this would be much better than having to mess around with a registrar's crappy web interface. Authoritative nameservers could automatically ensure that their glue is in sync. > In addition, the LP and/or L64 records must have very low TTLs, which is very > different from the way we do glue today. It's likely that if you have fairly static connectivity you can leave longish TTLS in your DNS, on the knowledge that if there is an outage things will come back with the same setup as before. This will work for multihoming but not mobility. However this requires that higher level protocols have good connection setup code that can try multiple paths concurrently (so you don't have to wait for a timeout if one is down) and good failover support (SCTP?). Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From morrowc.lists at gmail.com Tue Oct 5 14:23:11 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 5 Oct 2010 15:23:11 -0400 Subject: Level3 filter updates In-Reply-To: References: Message-ID: On Tue, Oct 5, 2010 at 1:57 PM, powerzone7 at gmail.com wrote: > Level 3 updates their filters every night. I used to work @ level3 this comes up a few times a year I think... I wonder if the onesc.net folks would include this on their bgp cheat sheets :) (hint-charlie-hint) -chris From jbates at brightok.net Tue Oct 5 15:43:18 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 05 Oct 2010 15:43:18 -0500 Subject: ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes) In-Reply-To: <4CAB768D.8060804@rancid.berkeley.edu> References: <4CAB4A7C.2080500@rancid.berkeley.edu> <4CAB768D.8060804@rancid.berkeley.edu> Message-ID: <4CAB8DE6.3090202@brightok.net> On 10/5/2010 2:03 PM, Michael Sinatra wrote: > > The issue is how should I deal with the situation that you need to know > the correct L64 record to get to my network (without waiting for a > timeout if you try the broken prefix first) and the way to know what the > correct prefixes are is to query a nameserver that's in my network. But > to get to my network, you need to know the correct L64 record...etc. So > I need to keep nameservers out of my network or have the ability to > update an L64 "glue" record on-the-fly in the parent (which also implies > a very low ttl on the parent L64 glue record). My recommendation is that you assign multiple networks. I realize this will possibly take the nameservers out of the ILNP space, but it is the effective method. Then you can reference the nameservers by both addresses, and one timing out will still get you to the other. I'm not up to speed on ILNP, but I'd presume that dual addressing would be required for this to handle failures (if you wanted all nameservers to respond at all times). Jack From mpetach at netflight.com Tue Oct 5 18:15:13 2010 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 5 Oct 2010 16:15:13 -0700 Subject: 2010.10.05 NANOG50 Tuesday afternoon notes Message-ID: I've posted the Tuesday afternoon notes at http://kestrel3.netflight.com/2010.10.05-NANOG50-afternoon-notes.txt and now I'm dashing to the social, because they're turning out the lights on me in the hall here. ^_^;; Matt From kris.foster at gmail.com Tue Oct 5 18:32:29 2010 From: kris.foster at gmail.com (kris foster) Date: Tue, 5 Oct 2010 16:32:29 -0700 Subject: 2010.10.05 NANOG50 Tuesday afternoon notes In-Reply-To: References: Message-ID: <95EA48C4-A2F8-44E1-AA10-7A5E2CF69171@gmail.com> On Oct 5, 2010, at 4:15 PM, Matthew Petach wrote: > I've posted the Tuesday afternoon notes at > http://kestrel3.netflight.com/2010.10.05-NANOG50-afternoon-notes.txt > > and now I'm dashing to the social, because they're turning out the lights > on me in the hall here. ^_^;; Thanks Matt, your notes during NANOG are always appreciated! -- kris From james at smithwaysecurity.com Tue Oct 5 23:44:47 2010 From: james at smithwaysecurity.com (James Smith) Date: Wed, 6 Oct 2010 01:44:47 -0300 Subject: Facebook down!! Alert! Message-ID: At 1:20am here in Canada, NB our networks are showing that facebook is down. Please confirm in the USA. ~SmithwaySecurity Sent from my iPhone From mike.lyon at gmail.com Tue Oct 5 23:46:43 2010 From: mike.lyon at gmail.com (Mike Lyon) Date: Tue, 5 Oct 2010 21:46:43 -0700 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: Same here in SF Bay Area.... On Tue, Oct 5, 2010 at 9:44 PM, James Smith wrote: > At 1:20am here in Canada, NB our networks are showing that facebook is > down. > Please confirm in the USA. > > > > ~SmithwaySecurity > > Sent from my iPhone > > From lostinmoscow at gmail.com Tue Oct 5 23:47:08 2010 From: lostinmoscow at gmail.com (Quinn Kuzmich) Date: Tue, 5 Oct 2010 22:47:08 -0600 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: Down here in Denver CO On Tue, Oct 5, 2010 at 10:44 PM, James Smith wrote: > At 1:20am here in Canada, NB our networks are showing that facebook is > down. > Please confirm in the USA. > > > > ~SmithwaySecurity > > Sent from my iPhone > > From michiel.muhlenbaumer at atratoip.net Tue Oct 5 23:47:26 2010 From: michiel.muhlenbaumer at atratoip.net (Michiel Muhlenbaumer) Date: Wed, 6 Oct 2010 06:47:26 +0200 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: Hi James, On 6 okt 2010, at 06:44, James Smith wrote: > At 1:20am here in Canada, NB our networks are showing that facebook is down. > Please confirm in the USA. No reason to panic over here (.nl) --- Michiel Muhlenbaumer Atrato IP Networks From doon.bulk at inoc.net Tue Oct 5 23:47:59 2010 From: doon.bulk at inoc.net (Patrick Muldoon) Date: Wed, 6 Oct 2010 00:47:59 -0400 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: <6691A052-90CD-4C5F-B359-B5F9B74DFB31@inoc.net> On Oct 6, 2010, at 12:44 AM, James Smith wrote: > At 1:20am here in Canada, NB our networks are showing that facebook is down. > Please confirm in the USA. http://downforeveryoneorjustme.com/facebook.com looks like it isn't just you .. Down from here as well. Looks like a productive night of hacking awaits me ... -Patrick -- Patrick Muldoon Network/Software Engineer INOC (http://www.inoc.net) PGPKEY (http://www.inoc.net/~doon) Key ID: 0x370D752C Please send all spam to my main address, root at localhost From mhofman at shearwater.com.au Tue Oct 5 23:49:00 2010 From: mhofman at shearwater.com.au (Mark Hofman) Date: Wed, 6 Oct 2010 15:49:00 +1100 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: Ditto In AU and from other reports US. Guess productivity will go up ;-) On 06/10/2010, at 15:46, "James Smith" wrote: > At 1:20am here in Canada, NB our networks are showing that facebook is down. > Please confirm in the USA. > > > > ~SmithwaySecurity > > Sent from my iPhone > From joly at punkcast.com Tue Oct 5 23:49:38 2010 From: joly at punkcast.com (Joly MacFie) Date: Wed, 6 Oct 2010 00:49:38 -0400 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: Down , down, down in NYC. On Wed, Oct 6, 2010 at 12:46 AM, Mike Lyon wrote: > Same here in SF Bay Area.... > > On Tue, Oct 5, 2010 at 9:44 PM, James Smith >wrote: > > > At 1:20am here in Canada, NB our networks are showing that facebook is > > down. > > Please confirm in the USA. > > > > > > > > ~SmithwaySecurity > > > > Sent from my iPhone > > > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From jlewis at lewis.org Tue Oct 5 23:54:57 2010 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 6 Oct 2010 00:54:57 -0400 (EDT) Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: On Wed, 6 Oct 2010, James Smith wrote: > At 1:20am here in Canada, NB our networks are showing that facebook is down. > Please confirm in the USA. Down from FL...but like last time, www.lisp4.facebook.com works fine. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From strizhov at cs.colostate.edu Tue Oct 5 23:56:36 2010 From: strizhov at cs.colostate.edu (Mikhail Strizhov) Date: Tue, 05 Oct 2010 22:56:36 -0600 Subject: Facebook down!! Alert! In-Reply-To: <6691A052-90CD-4C5F-B359-B5F9B74DFB31@inoc.net> References: <6691A052-90CD-4C5F-B359-B5F9B74DFB31@inoc.net> Message-ID: <4CAC0184.5000104@cs.colostate.edu> Works fine here, Northern Colorado. -- Sincerely, Mikhail Strizhov On 10/05/2010 10:47 PM, Patrick Muldoon wrote: > On Oct 6, 2010, at 12:44 AM, James Smith wrote: > >> At 1:20am here in Canada, NB our networks are showing that facebook is down. >> Please confirm in the USA. > > > http://downforeveryoneorjustme.com/facebook.com > > looks like it isn't just you .. > > Down from here as well. Looks like a productive night of hacking awaits me ... > > -Patrick > > -- > Patrick Muldoon > Network/Software Engineer > INOC (http://www.inoc.net) > PGPKEY (http://www.inoc.net/~doon) > Key ID: 0x370D752C > > Please send all spam to my main address, root at localhost > > > From zaid at zaidali.com Wed Oct 6 02:57:31 2010 From: zaid at zaidali.com (Zaid Ali) Date: Wed, 06 Oct 2010 00:57:31 -0700 Subject: Facebook down!! Alert! In-Reply-To: Message-ID: I think the Outages mailing list is more appropriate for this. On 10/5/10 9:46 PM, "Mike Lyon" wrote: > Same here in SF Bay Area.... > > On Tue, Oct 5, 2010 at 9:44 PM, James Smith wrote: > >> At 1:20am here in Canada, NB our networks are showing that facebook is >> down. >> Please confirm in the USA. >> >> >> >> ~SmithwaySecurity >> >> Sent from my iPhone >> >> From james at jamesstewartsmith.com Tue Oct 5 23:59:11 2010 From: james at jamesstewartsmith.com (James Smith) Date: Wed, 6 Oct 2010 00:59:11 -0400 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: Seems to be working just fine here in Toronto. On Wed, Oct 6, 2010 at 12:49 AM, Mark Hofman wrote: > Ditto In AU and from other reports US. > Guess productivity will go up ;-) > > > > > On 06/10/2010, at 15:46, "James Smith" wrote: > > > At 1:20am here in Canada, NB our networks are showing that facebook is > down. > > Please confirm in the USA. > > > > > > > > ~SmithwaySecurity > > > > Sent from my iPhone > > > > -- James Smith From mark at edgewire.sg Wed Oct 6 00:00:00 2010 From: mark at edgewire.sg (Mark) Date: Wed, 6 Oct 2010 13:00:00 +0800 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: <9C0A9F8E-110D-4232-85FB-EF17C5996CBE@edgewire.sg> It's back up. There goes that short burst of productivity. On Oct 6, 2010, at 12:49 PM, Mark Hofman wrote: > Ditto In AU and from other reports US. > Guess productivity will go up ;-) > > > > > On 06/10/2010, at 15:46, "James Smith" > wrote: > >> At 1:20am here in Canada, NB our networks are showing that facebook >> is down. >> Please confirm in the USA. >> >> >> >> ~SmithwaySecurity >> >> Sent from my iPhone >> > From larry-lists at maxqe.com Wed Oct 6 00:05:35 2010 From: larry-lists at maxqe.com (Larry Brower) Date: Wed, 06 Oct 2010 00:05:35 -0500 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: <4CAC039F.2010001@maxqe.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Smith wrote: > At 1:20am here in Canada, NB our networks are showing that facebook is down. > Please confirm in the USA. > > > > ~SmithwaySecurity > > Sent from my iPhone > We need "Alert" and ! in the subject? seriously? Sorry, but I don't see a reason to get all excited. FB is down, omg, alert the media. geez -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJMrAOfAAoJEPXCUD/44PWqa2sP/AuUU0WnM4UUtAO3mazyRPIa gJ/xuguEgYWNbl7j/EZgHEu7fSYgkbo+Y/H+T2F5nl0PO3UqJz5sjyfD654OSy0h FAERgpR2syfRFM17EaLai4VgHsiVdm82Fzqs8xXwumu9OVfQAbk/eWsg6d0wOzp8 cuO7OUmb06i66VHbmWrSSJKmJKkhYvxf89o3NbPI6i0eIqr0wADJLIRbDQLLTt1i YnCj1urxClGnw9ChoCe0meNITllKx9nluzKEDy6P1eRWxTMGCn9xOnWlKHW2/6Rs sW/klZeOFxLDFEkufNLPr6w9vWxee648j0fjkCU6PGn6GRxaS6Qq0je1e/15f8cI MlfA1CCO/hNvSA07EBbpz9th2wyx69ninnv7Y3mjly//YB0EY/9H2j21wCDsDoJ4 SY/ttYOKQEZ3XoTAKa0RLzRmkR/GQwVsnGUfa//kA1Msf541VG8i98dYF6tpqFVt RJ0SDEHv53XSP+tuT4HdCyj8BtgwqIQTlughqynPM74kbYc6jYrZ6mxHxfhJkeXD wsYoJmHVcUgg/WKsa0eGk7sPhHEgR1alW5KnBYAjBtsStO9sLmESSTculvEQ7VXS OvuYUTfqgl3mkRtW0ttJvB/b5VvCQ70eUIkcmRUEvrX30WJldjupFxkyCaJtB3s4 Cq0MnisvbZZcpLoAJ0Qp =HLWx -----END PGP SIGNATURE----- From mdodd at doddserver.com Wed Oct 6 00:06:16 2010 From: mdodd at doddserver.com (Matthew Dodd) Date: Wed, 6 Oct 2010 01:06:16 -0400 Subject: Facebook down!! Alert! In-Reply-To: <4CAC0184.5000104@cs.colostate.edu> References: <6691A052-90CD-4C5F-B359-B5F9B74DFB31@inoc.net> <4CAC0184.5000104@cs.colostate.edu> Message-ID: <475E1133-7E38-4D5D-A85D-666CEAF3DAF0@doddserver.com> Still up here in Massachusetts over v4 and v6. Since 11:45am (that is PST, I believe) there is still an ongoing issue with "real-time updates" according to the Live Status page. http://developers.facebook.com/live_status Visiting that page just now, the latest API response time graphs are definitely indicative of what looks like serious new problems. Also, Facebook is hosting an event Wednesday where they're rumored to be rolling out a large update-- coincidence?!? http://techcrunch.com/2010/10/05/facebook-redesign-lockdown/ -Matt Dodd On Oct 6, 2010, at 12:56 AM, Mikhail Strizhov wrote: > Works fine here, Northern Colorado. > > > -- > Sincerely, > Mikhail Strizhov > > > > > On 10/05/2010 10:47 PM, Patrick Muldoon wrote: >> On Oct 6, 2010, at 12:44 AM, James Smith wrote: >> >>> At 1:20am here in Canada, NB our networks are showing that facebook is down. >>> Please confirm in the USA. >> >> >> http://downforeveryoneorjustme.com/facebook.com >> >> looks like it isn't just you .. >> >> Down from here as well. Looks like a productive night of hacking awaits me ... >> >> -Patrick >> >> -- >> Patrick Muldoon >> Network/Software Engineer >> INOC (http://www.inoc.net) >> PGPKEY (http://www.inoc.net/~doon) >> Key ID: 0x370D752C >> >> Please send all spam to my main address, root at localhost >> >> >> > > From joly at punkcast.com Wed Oct 6 00:09:26 2010 From: joly at punkcast.com (Joly MacFie) Date: Wed, 6 Oct 2010 01:09:26 -0400 Subject: Facebook down!! Alert! In-Reply-To: <4CAC0184.5000104@cs.colostate.edu> References: <6691A052-90CD-4C5F-B359-B5F9B74DFB31@inoc.net> <4CAC0184.5000104@cs.colostate.edu> Message-ID: Yeah it's back. On Wed, Oct 6, 2010 at 12:56 AM, Mikhail Strizhov wrote: > Works fine here, Northern Colorado. > > > -- > Sincerely, > Mikhail Strizhov > > > > > > On 10/05/2010 10:47 PM, Patrick Muldoon wrote: > >> On Oct 6, 2010, at 12:44 AM, James Smith wrote: >> >> At 1:20am here in Canada, NB our networks are showing that facebook is >>> down. >>> Please confirm in the USA. >>> >> >> >> http://downforeveryoneorjustme.com/facebook.com >> >> looks like it isn't just you .. >> >> Down from here as well. Looks like a productive night of hacking awaits >> me ... >> >> -Patrick >> >> -- >> Patrick Muldoon >> Network/Software Engineer >> INOC (http://www.inoc.net) >> PGPKEY (http://www.inoc.net/~doon ) >> Key ID: 0x370D752C >> >> Please send all spam to my main address, root at localhost >> >> >> >> > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From sethm at rollernet.us Wed Oct 6 01:11:21 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Tue, 05 Oct 2010 23:11:21 -0700 Subject: Facebook down!! Alert! In-Reply-To: <4CAC039F.2010001@maxqe.com> References: <4CAC039F.2010001@maxqe.com> Message-ID: <4CAC1309.6040406@rollernet.us> On 10/5/10 10:05 PM, Larry Brower wrote: > James Smith wrote: >> At 1:20am here in Canada, NB our networks are showing that facebook is down. >> Please confirm in the USA. > > > >> ~SmithwaySecurity > >> Sent from my iPhone > > > We need "Alert" and ! in the subject? seriously? > Sorry, but I don't see a reason to get all excited. FB is down, omg, > alert the media. geez Correction, that's "alert" and a total of three exclamation points. Not a peep on outages. ~Seth From damien.saucez at uclouvain.be Wed Oct 6 01:12:45 2010 From: damien.saucez at uclouvain.be (Damien Saucez) Date: Wed, 6 Oct 2010 08:12:45 +0200 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: Hello, Is www.lisp4.facebook.com working for places where www.facebook.com is down? Damien Saucez On 06 Oct 2010, at 06:47, Michiel Muhlenbaumer wrote: > Hi James, > > On 6 okt 2010, at 06:44, James Smith wrote: > >> At 1:20am here in Canada, NB our networks are showing that facebook is down. >> Please confirm in the USA. > > No reason to panic over here (.nl) > > --- > Michiel Muhlenbaumer > Atrato IP Networks > From rfg at tristatelogic.com Wed Oct 6 06:14:46 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 06 Oct 2010 04:14:46 -0700 Subject: New hijacking - Done via via good old-fashioned Identity Theft Message-ID: <30427.1286363686@tristatelogic.com> [[ Note: There are three more apparently hijacked blocks that are related to the 75 specific blocks I am reporting on herein. I'll be reporting on those other three blocks later on, but right now I just want to keep it simple and report on just the ones relating to directnet.net. ]] So anyway, presented below, as Rod Serling would have said, "... for your approval..." you will find a collection of 75 separate IP blocks, all of which appear to have been hijacked in one big gulp. One /21, plus seventy four /24s. This case was done, quite neatly, the good old fashioned way.... apparently by trivial identity theft. (And I should say that no fault whatsoever accrues in any way to ARIN in this case. They were not even involved in the slightest, since all of the relevant WHOIS records have remained utterly unchanged throughout this entire hijacking.) The identity theft: A company that was responsible for one /21 block and 74 separate /24 blocks (all of the latter of which had been originally allocated for various U.S. elementary schools, middle schools, and high schools) apparently went out of business. In due time, the company's domain name (directnet.net) came up for sale. It was purchased for $4,000, sometime between May 31, 2010 and June 13, 2010: http://www.dnjournal.com/archive/domainsales/2010/20100623.htm Subsequently, the domain name was transferred to an anonymizing registrar in the Cayman Islands. Sometime before or after that purchase, whoever had purchased the directnet.net domain convinced the fine folks at Reliance Globalcom Services, Inc., (AS6517) to announce routes to 100% of this rather cleverly hijacked IP space. (See complete IP block list attached below.) Sometime after that, the IP blocks in question began to fill up with snowshoe name servers and snowshoe spam domains. The entire set of relevant ARIN WHOIS records for the hijacked IP blocks, along with the new WHOIS record for the newly re-registered directnet.net domain, and also a listing of the snowshoe domains and name servers that have been created in, or moved into these hijacked IP blocks are all avaliable here: http://www.47-usc-230c2.org/hijacked-schools/ Although it is impossible to be absolutely certain who engineered this clever hijacking, some of the evidence available to me at this time suggests that a particular company listed on Spamhaus' ROKSO list may possibly have either either had a hand in engineeering the hijacking, or else may possibly have benefitted from it, after the fact, i.e. obtaining IP space which they could then sub-lease to their space-hungry customers. Certainly, fine folks at Reliance Globalcom Services, Inc. could tell us who is paying them to connect these hijacked blocks to their network, but I rather doubt that they are actually going to come clean and do that. Regards, rfg Hijacked blocks: 204.194.184.0/21 205.196.1.0/24 205.196.14.0/24 205.196.28.0/24 205.196.29.0/24 205.196.30.0/24 205.196.31.0/24 205.196.32.0/24 205.196.33.0/24 205.196.34.0/24 205.196.35.0/24 205.196.36.0/24 205.196.37.0/24 205.196.38.0/24 205.196.40.0/24 205.196.41.0/24 205.196.42.0/24 205.196.43.0/24 205.196.44.0/24 205.196.45.0/24 205.196.46.0/24 205.196.47.0/24 205.196.49.0/24 205.196.51.0/24 205.196.52.0/24 205.196.53.0/24 205.196.54.0/24 205.196.55.0/24 205.196.56.0/24 205.196.57.0/24 205.196.58.0/24 205.196.59.0/24 205.196.60.0/24 205.196.61.0/24 205.196.62.0/24 205.196.67.0/24 205.196.68.0/24 205.196.69.0/24 205.196.71.0/24 205.196.72.0/24 205.196.73.0/24 205.196.75.0/24 205.196.76.0/24 205.196.96.0/24 205.196.97.0/24 205.196.99.0/24 205.196.100.0/24 205.196.101.0/24 205.196.102.0/24 205.196.103.0/24 205.196.104.0/24 205.196.105.0/24 205.196.106.0/24 205.196.107.0/24 205.196.108.0/24 205.196.109.0/24 205.196.111.0/24 205.196.112.0/24 205.196.113.0/24 205.196.114.0/24 205.196.115.0/24 205.196.116.0/24 205.196.161.0/24 205.196.162.0/24 205.196.163.0/24 205.196.164.0/24 205.196.165.0/24 205.196.192.0/24 205.196.193.0/24 205.196.194.0/24 205.196.196.0/24 205.196.197.0/24 205.196.198.0/24 205.196.199.0/24 205.196.200.0/24 From hj1980 at gmail.com Wed Oct 6 06:39:06 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 6 Oct 2010 12:39:06 +0100 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <30427.1286363686@tristatelogic.com> References: <30427.1286363686@tristatelogic.com> Message-ID: > Certainly, fine folks at Reliance Globalcom Services, Inc. could tell > us who is paying them to connect these hijacked blocks to their network, > but I rather doubt that they are actually going to come clean and do > that. Ron, I haven't been following this anti-spam stuff much since it went political with ARIN but I do have a few quick questions (relating to US law and spam). 1) Is spamming from within the US criminal activity? What constitutes spam in that case? 2) If you could justify the incoming spam as a DOS, is that criminal activity? Could you justify it as a DOS? 3) Is providing ARIN with bogus information just to get around their processes criminal activity? 4) Is obtaining disused IP space / AS allocations from assigned entity, and not updating ARIN criminal activity? 5) Is advertising Prefixes or AS number assigned to another entity criminal activity? 6) If any of the above could be classed as criminal activity, are Reliance Globalcom (in this case) legally obligated to cut them off?, or just help by switching on a packet capture (new law coming into effect i think??) Cheers Heath From brunner at nic-naa.net Wed Oct 6 08:08:43 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 06 Oct 2010 09:08:43 -0400 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <30427.1286363686@tristatelogic.com> References: <30427.1286363686@tristatelogic.com> Message-ID: <4CAC74DB.8010803@nic-naa.net> so ... should domains associated with asn(s) and addr block allocations be subject to some expiry policy other than "it goes into the drop pool and one of {enom,pool,...} acquire it (and the associated non-traffic assets) for any interested party at $50 per /24"? Eric From ben at adversary.org Wed Oct 6 08:35:06 2010 From: ben at adversary.org (Ben McGinnes) Date: Thu, 07 Oct 2010 00:35:06 +1100 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <4CAC74DB.8010803@nic-naa.net> References: <30427.1286363686@tristatelogic.com> <4CAC74DB.8010803@nic-naa.net> Message-ID: <4CAC7B0A.1080208@adversary.org> On 7/10/10 12:08 AM, Eric Brunner-Williams wrote: > so ... should domains associated with asn(s) and addr block allocations > be subject to some expiry policy other than "it goes into the drop pool > and one of {enom,pool,...} acquire it (and the associated non-traffic > assets) for any interested party at $50 per /24"? Interesting idea, but how do you apply it to ccTLD domains with widely varying policies. All it takes is whois records being legitimately updated to use domain contacts using a ccTLD domain to circumvent. Sounds like more of a stop-gap measure. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From joelja at bogus.com Wed Oct 6 08:57:29 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 06 Oct 2010 09:57:29 -0400 Subject: Anyone can share the Network card experience In-Reply-To: References: Message-ID: <4CAC8049.1070106@bogus.com> On 10/5/10 10:01 AM, Deric Kwok wrote: > Hi > > Anyone can share the Network card experience > > ls onborad PCI Expresscard better or Plug in slot PCI Express card good? both are likely to be pci-e x1 interfaces if it's a single or dual port chipset. > How are their performance in Gig transfer rate? should be a 100% in an appropiately fast machine. you'll find that most 4 port gig or 10gig cards have x4 or x8 connectors. > Thank you so much > From mhuff at ox.com Wed Oct 6 09:29:08 2010 From: mhuff at ox.com (Matthew Huff) Date: Wed, 6 Oct 2010 10:29:08 -0400 Subject: Scam telemarketers spoofing our NOC phone number for callerid Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> We have recently gotten complaints of harrassing and high pressure sales scams orginating from our NOC's phone number. Since the number is a virtual number on the PBX, it can't be used for outgoing calls. I assume the scammers choose the number from the whois db. Anyone else seen this happening? Any suggestions on whom we should contact? ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: text/x-vcard Size: 1612 bytes Desc: Matthew Huff.vcf URL: From owen at delong.com Wed Oct 6 09:34:20 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Oct 2010 07:34:20 -0700 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <4CAC7B0A.1080208@adversary.org> References: <30427.1286363686@tristatelogic.com> <4CAC74DB.8010803@nic-naa.net> <4CAC7B0A.1080208@adversary.org> Message-ID: On Oct 6, 2010, at 6:35 AM, Ben McGinnes wrote: > On 7/10/10 12:08 AM, Eric Brunner-Williams wrote: >> so ... should domains associated with asn(s) and addr block allocations >> be subject to some expiry policy other than "it goes into the drop pool >> and one of {enom,pool,...} acquire it (and the associated non-traffic >> assets) for any interested party at $50 per /24"? > > Interesting idea, but how do you apply it to ccTLD domains with widely > varying policies. All it takes is whois records being legitimately > updated to use domain contacts using a ccTLD domain to circumvent. > Sounds like more of a stop-gap measure. > > > Regards, > Ben > > Number resources are not and should not be associated with domain resources at the policy level. This would make absolutely no sense whatsoever. Owen From dwhite at olp.net Wed Oct 6 09:37:35 2010 From: dwhite at olp.net (Dan White) Date: Wed, 6 Oct 2010 09:37:35 -0500 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> Message-ID: <20101006143735.GA3425@dan.olp.net> On 06/10/10?10:29?-0400, Matthew Huff wrote: >We have recently gotten complaints of harrassing and high pressure sales scams orginating from our NOC's phone number. Since the number is a virtual number on the PBX, it can't be used for outgoing calls. I assume the scammers choose the number from the whois db. Anyone else seen this happening? Any suggestions on whom we should contact? Could be Caller ID spoofing. If so, have a recipient of the call perform a trap and trace to find the originator of the call (doing so may require you to file a police report to find who's making the calls, depending on your jurisdiction). If your PBX is SIP based, you might be victim of a SIP registration hijack, which are on the rise, based on traffic we've been seeing in our network. -- Dan White From bill at herrin.us Wed Oct 6 10:15:25 2010 From: bill at herrin.us (William Herrin) Date: Wed, 6 Oct 2010 11:15:25 -0400 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: <20101006143735.GA3425@dan.olp.net> References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> Message-ID: On Wed, Oct 6, 2010 at 10:37 AM, Dan White wrote: > If your PBX is SIP based, you might be victim of a SIP registration hijack, > which are on the rise, based on traffic we've been seeing in our network. I had my unpublished asterisk box up for all of two days before getting half a megabit per second worth of false SIP registration attempts. Filled /var/log. I had to write a script to dynamically filter source IPs with too many failures. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From mhuff at ox.com Wed Oct 6 10:20:03 2010 From: mhuff at ox.com (Matthew Huff) Date: Wed, 6 Oct 2010 11:20:03 -0400 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2C7B80772@PUR-EXCH07.ox.com> Our system is PRI based, not sip. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: wherrin at gmail.com [mailto:wherrin at gmail.com] On Behalf Of William Herrin > Sent: Wednesday, October 06, 2010 11:15 AM > To: Dan White > Cc: Matthew Huff; (nanog at nanog.org) > Subject: Re: Scam telemarketers spoofing our NOC phone number for callerid > > On Wed, Oct 6, 2010 at 10:37 AM, Dan White wrote: > > If your PBX is SIP based, you might be victim of a SIP registration hijack, > > which are on the rise, based on traffic we've been seeing in our network. > > I had my unpublished asterisk box up for all of two days before > getting half a megabit per second worth of false SIP registration > attempts. Filled /var/log. I had to write a script to dynamically > filter source IPs with too many failures. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin at dirtside.com? bill at herrin.us > 3005 Crane Dr. ...................... Web: > Falls Church, VA 22042-3004 -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: text/x-vcard Size: 1612 bytes Desc: Matthew Huff.vcf URL: From jlewis at lewis.org Wed Oct 6 10:33:48 2010 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 6 Oct 2010 11:33:48 -0400 (EDT) Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2C7B80772@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> <483E6B0272B0284BA86D7596C40D29F9E2C7B80772@PUR-EXCH07.ox.com> Message-ID: On Wed, 6 Oct 2010, Matthew Huff wrote: > Our system is PRI based, not sip. PRI for origination and termination...but what are your phones? Old school or VOIP/SIP? If your phone system supports SIP clients, it really ought to be IP restricted to only allow your phones access, or use something like fail2ban to stop the SIP scanners from eventually gaining access. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From mhuff at ox.com Wed Oct 6 10:43:49 2010 From: mhuff at ox.com (Matthew Huff) Date: Wed, 6 Oct 2010 11:43:49 -0400 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> <483E6B0272B0284BA86D7596C40D29F9E2C7B80772@PUR-EXCH07.ox.com> Message-ID: <483E6B0272B0284BA86D7596C40D29F9E2C7B80778@PUR-EXCH07.ox.com> Digital all the way through. No sip. No outside access to the PBX subnet either. Just a mininute ago our telco has verified that the calls are not orginating from out phone system. It's a simple caller id spoofing. People don't realize that caller id can be spoofed and therefore are 100% sure that we are makign the harrasing calls. Just wanted nanog to be aware of this since the only two numbers that this has happened with are the ones in our ARIN whois records. ---- Matthew Huff?????? | One Manhattanville Rd OTA Management LLC | Purchase, NY 10577 http://www.ox.com | Phone: 914-460-4039 aim: matthewbhuff? | Fax:?? 914-460-4139 > -----Original Message----- > From: Jon Lewis [mailto:jlewis at lewis.org] > Sent: Wednesday, October 06, 2010 11:34 AM > To: Matthew Huff > Cc: '(nanog at nanog.org)' > Subject: RE: Scam telemarketers spoofing our NOC phone number for callerid > > On Wed, 6 Oct 2010, Matthew Huff wrote: > > > Our system is PRI based, not sip. > > PRI for origination and termination...but what are your phones? Old > school or VOIP/SIP? If your phone system supports SIP clients, it really > ought to be IP restricted to only allow your phones access, or use > something like fail2ban to stop the SIP scanners from eventually gaining > access. > > ---------------------------------------------------------------------- > Jon Lewis, MCP :) | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ -------------- next part -------------- A non-text attachment was scrubbed... Name: Matthew Huff.vcf Type: text/x-vcard Size: 1612 bytes Desc: Matthew Huff.vcf URL: From mpetach at netflight.com Wed Oct 6 10:53:51 2010 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 6 Oct 2010 08:53:51 -0700 Subject: 2010.10.06 NANOG50 day 3, Wednesday morning notes Message-ID: Thanks to everyone for a wonderful conference--this wraps the last of NANOG50--see you all in Miami! Notes from this morning's session are posted at http://kestrel3.netflight.com/2010.10.06-NANOG50-morning-notes.txt sorry about the gaps, I kinda nodded off now and then--only got 2 hours of sleep last night. ^_^;; Apologies for typos, misspellings, etc. Thanks again for a wonderful conference!! :) Matt From bruns at 2mbit.com Wed Oct 6 10:54:44 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 06 Oct 2010 09:54:44 -0600 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2C7B80778@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> <483E6B0272B0284BA86D7596C40D29F9E2C7B80772@PUR-EXCH07.ox.com> <483E6B0272B0284BA86D7596C40D29F9E2C7B80778@PUR-EXCH07.ox.com> Message-ID: <4CAC9BC4.5090305@2mbit.com> On 10/6/10 9:43 AM, Matthew Huff wrote: > Digital all the way through. No sip. No outside access to the PBX > subnet either. Just a mininute ago our telco has verified that the > calls are not orginating from out phone system. It's a simple caller > id spoofing. People don't realize that caller id can be spoofed and > therefore are 100% sure that we are makign the harrasing calls. > > Just wanted nanog to be aware of this since the only two numbers that > this has happened with are the ones in our ARIN whois records. > > I'm currently dealing with an engineering firm in Florida that I believe is having the same issue. Getting calls at 2am, 3am MDT and at the exact same time 12 hours later to one of my numbers which has call screening. Left a message with their IT department, so hoping they follow up and return my call. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From jlewis at lewis.org Wed Oct 6 10:55:32 2010 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 6 Oct 2010 11:55:32 -0400 (EDT) Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2C7B80778@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> <483E6B0272B0284BA86D7596C40D29F9E2C7B80772@PUR-EXCH07.ox.com> <483E6B0272B0284BA86D7596C40D29F9E2C7B80778@PUR-EXCH07.ox.com> Message-ID: On Wed, 6 Oct 2010, Matthew Huff wrote: > Digital all the way through. No sip. No outside access to the PBX subnet > either. Just a mininute ago our telco has verified that the calls are > not orginating from out phone system. It's a simple caller id spoofing. > People don't realize that caller id can be spoofed and therefore are > 100% sure that we are makign the harrasing calls. Some do. Anyone with control of a phone system with digital lines (i.e. asterisk with PRI) can trivially set callerID to whatever they want. There are perfectly legitimate, and not so legitimate uses for this. However, SIP scanning and brute forcing has become really common, so it's about as likely that a phone system has been compromised as someone is forging callerID to one of its numbers. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jgreco at ns.sol.net Wed Oct 6 11:38:39 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Wed, 6 Oct 2010 11:38:39 -0500 (CDT) Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: Message-ID: <201010061638.o96GcdSb010448@aurora.sol.net> > On Wed, 6 Oct 2010, Matthew Huff wrote: > > > Digital all the way through. No sip. No outside access to the PBX subnet > > either. Just a mininute ago our telco has verified that the calls are > > not orginating from out phone system. It's a simple caller id spoofing. > > People don't realize that caller id can be spoofed and therefore are > > 100% sure that we are makign the harrasing calls. > > Some do. Anyone with control of a phone system with digital lines (i.e. > asterisk with PRI) can trivially set callerID to whatever they want. That's not correct; what is true is that *some* LEC's do not filter the callerID submitted and so this is *sometimes* true. There are many examples where a LEC does not accept random callerID's from a PRI customer. Sometimes this is even problematic, for example, when the LEC helpfully inserts the callerID *they* think is correct and it's actually wrong. > There are perfectly legitimate, and not so legitimate uses for this. Yes. It's very useful, for example, to be able to generate your cell phone's callerID from your PBX, since people have a habit of dialing you from the number you called, even if you specifically asked them to use a different callback number. > However, SIP scanning and brute forcing has become really common, so it's > about as likely that a phone system has been compromised as someone is > forging callerID to one of its numbers. Correct. ... 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 drc at virtualized.org Wed Oct 6 11:42:00 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 6 Oct 2010 06:42:00 -1000 Subject: 2010.10.06 NANOG50 day 3, Wednesday morning notes In-Reply-To: References: Message-ID: <554C2326-1CB0-4A6E-B0EF-ABF389DBD1A6@virtualized.org> On Oct 6, 2010, at 5:53 AM, Matthew Petach wrote: > Thanks again for a wonderful conference!! :) Thanks very much for the notes! Regards, -drc From sil at infiltrated.net Wed Oct 6 11:50:01 2010 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 06 Oct 2010 12:50:01 -0400 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> Message-ID: <4CACA8B9.3040108@infiltrated.net> William Herrin wrote: > On Wed, Oct 6, 2010 at 10:37 AM, Dan White wrote: > >> If your PBX is SIP based, you might be victim of a SIP registration hijack, >> which are on the rise, based on traffic we've been seeing in our network. >> > > I had my unpublished asterisk box up for all of two days before > getting half a megabit per second worth of false SIP registration > attempts. Filled /var/log. I had to write a script to dynamically > filter source IPs with too many failures. > > Regards, > Bill Herrin > > "A Simple Asterisk Based Toll Fraud Prevention Script" http://www.infiltrated.net/asterisk-ips.html Cheap marketing of a free RBL for VoIP: http://www.infiltrated.net/voipabuse Anyhow, I spoke about this last week (toll fraud abuse via IP PBX tricksters). Show # 275 http://www.talkshoe.com/talkshoe/web/talkCast.jsp?masterId=22622&cmd=tc http://voipsa.org/blog/2010/09/29/voip-attackers-sometimes-they-come-back/ http://voipsa.org/blog/2010/09/28/voip-abuse-project/ -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From Ruben.Guerra at arrisi.com Wed Oct 6 11:49:59 2010 From: Ruben.Guerra at arrisi.com (Guerra, Ruben) Date: Wed, 6 Oct 2010 11:49:59 -0500 Subject: 2010.10.06 NANOG50 day 3, Wednesday morning notes In-Reply-To: References: Message-ID: <8BC9AA1D1BA4494F83F8205415225CE82614FD26A9@CHIEXMAIL1.ARRS.ARRISI.COM> Thanks for the notes Matt! :) -----Original Message----- From: Matthew Petach [mailto:mpetach at netflight.com] Sent: Wednesday, October 06, 2010 10:54 AM To: nanog at nanog.org Subject: 2010.10.06 NANOG50 day 3, Wednesday morning notes Thanks to everyone for a wonderful conference--this wraps the last of NANOG50--see you all in Miami! Notes from this morning's session are posted at http://kestrel3.netflight.com/2010.10.06-NANOG50-morning-notes.txt sorry about the gaps, I kinda nodded off now and then--only got 2 hours of sleep last night. ^_^;; Apologies for typos, misspellings, etc. Thanks again for a wonderful conference!! :) Matt From deleskie at gmail.com Wed Oct 6 12:03:04 2010 From: deleskie at gmail.com (jim deleskie) Date: Wed, 6 Oct 2010 14:03:04 -0300 Subject: 2010.10.06 NANOG50 day 3, Wednesday morning notes In-Reply-To: <8BC9AA1D1BA4494F83F8205415225CE82614FD26A9@CHIEXMAIL1.ARRS.ARRISI.COM> References: <8BC9AA1D1BA4494F83F8205415225CE82614FD26A9@CHIEXMAIL1.ARRS.ARRISI.COM> Message-ID: +1 On Wed, Oct 6, 2010 at 1:49 PM, Guerra, Ruben wrote: > Thanks for the notes Matt! :) > > > > -----Original Message----- > From: Matthew Petach [mailto:mpetach at netflight.com] > Sent: Wednesday, October 06, 2010 10:54 AM > To: nanog at nanog.org > Subject: 2010.10.06 NANOG50 day 3, Wednesday morning notes > > Thanks to everyone for a wonderful conference--this wraps > the last of NANOG50--see you all in Miami! > > Notes from this morning's session are posted at > > http://kestrel3.netflight.com/2010.10.06-NANOG50-morning-notes.txt > > sorry about the gaps, I kinda nodded off now and then--only got 2 hours > of sleep last night. ^_^;; > > Apologies for typos, misspellings, etc. > > Thanks again for a wonderful conference!! :) > > Matt > > > From ASTONGE at travelers.com Wed Oct 6 12:44:27 2010 From: ASTONGE at travelers.com (St. Onge,Adam) Date: Wed, 6 Oct 2010 13:44:27 -0400 Subject: Mobile Looking Glass? Message-ID: <768FB653686AE54A9B4FB9A1503F03F51D02AE1F3F@TENK7MVB.prod.travp.net> Anyone know of an iPhone application for checking public Looking Glass servers? Boss called me in a panic when I was out for lunch to check on something and would make my life much easier but searching for stuff on iTunes is awful. ============================================================================== This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies. From jared at puck.nether.net Wed Oct 6 12:56:53 2010 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 6 Oct 2010 13:56:53 -0400 Subject: Mobile Looking Glass? In-Reply-To: <768FB653686AE54A9B4FB9A1503F03F51D02AE1F3F@TENK7MVB.prod.travp.net> References: <768FB653686AE54A9B4FB9A1503F03F51D02AE1F3F@TENK7MVB.prod.travp.net> Message-ID: <7291705D-30F4-4FFA-8564-D98678ACCF7C@puck.nether.net> I have found the iSSH application (iPhone + iPad) works well. You can ssh tunnel for things (eg: VNC) with ssh keys, etc.. - Jared link: http://itunes.apple.com/us/app/issh-ssh-vnc-console/id287765826?mt=8 On Oct 6, 2010, at 1:44 PM, St. Onge,Adam wrote: > Anyone know of an iPhone application for checking public Looking Glass servers? > > Boss called me in a panic when I was out for lunch to check on something and would make my life much easier but searching for stuff on iTunes is awful. > > ============================================================================== > This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies. From thomas at habets.pp.se Wed Oct 6 13:17:29 2010 From: thomas at habets.pp.se (Thomas Habets) Date: Wed, 6 Oct 2010 20:17:29 +0200 (CEST) Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: On Wed, 6 Oct 2010, Mark Hofman wrote: > Guess productivity will go up ;-) You'd think so, but my experience is that when Facebook goes down the whole company will leave their desks and go to the networking people to get them to fix the Facebook. And they won't leave until Facebook is back. --------- typedef struct me_s { char name[] = { "Thomas Habets" }; char email[] = { "thomas at habets.pp.se" }; char kernel[] = { "Linux" }; char *pgpKey[] = { "http://www.habets.pp.se/pubkey.txt" }; char pgp[] = { "A8A3 D1DD 4AE0 8467 7FDE 0945 286A E90A AD48 E854" }; char coolcmd[] = { "echo '. ./_&. ./_'>_;. ./_" }; } me_t; From ck at sandcastl.es Wed Oct 6 13:20:51 2010 From: ck at sandcastl.es (christian koch) Date: Wed, 6 Oct 2010 11:20:51 -0700 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: +1 On Wed, Oct 6, 2010 at 12:57 AM, Zaid Ali wrote: > I think the Outages mailing list is more appropriate for this. > > > On 10/5/10 9:46 PM, "Mike Lyon" wrote: > > > Same here in SF Bay Area.... > > > > On Tue, Oct 5, 2010 at 9:44 PM, James Smith >wrote: > > > >> At 1:20am here in Canada, NB our networks are showing that facebook is > >> down. > >> Please confirm in the USA. > >> > >> > >> > >> ~SmithwaySecurity > >> > >> Sent from my iPhone > >> > >> > > > > From jlewis at lewis.org Wed Oct 6 13:30:39 2010 From: jlewis at lewis.org (Jon Lewis) Date: Wed, 6 Oct 2010 14:30:39 -0400 (EDT) Subject: Mobile Looking Glass? In-Reply-To: <7291705D-30F4-4FFA-8564-D98678ACCF7C@puck.nether.net> References: <768FB653686AE54A9B4FB9A1503F03F51D02AE1F3F@TENK7MVB.prod.travp.net> <7291705D-30F4-4FFA-8564-D98678ACCF7C@puck.nether.net> Message-ID: googling iphone bgp, this result looked promising, but don't waste your time. It appears to be more or less totally broken. http://grid5.wordpress.com/2009/02/04/bgp-released/ On Wed, 6 Oct 2010, Jared Mauch wrote: > I have found the iSSH application (iPhone + iPad) works well. > > You can ssh tunnel for things (eg: VNC) with ssh keys, etc.. > > - Jared > > link: > > http://itunes.apple.com/us/app/issh-ssh-vnc-console/id287765826?mt=8 > > On Oct 6, 2010, at 1:44 PM, St. Onge,Adam wrote: > >> Anyone know of an iPhone application for checking public Looking Glass servers? >> >> Boss called me in a panic when I was out for lunch to check on something and would make my life much easier but searching for stuff on iTunes is awful. >> >> ============================================================================== >> This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies. > > > ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From bclark at spectraaccess.com Wed Oct 6 14:07:21 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Wed, 06 Oct 2010 15:07:21 -0400 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: <4CACC8E9.9030800@spectraaccess.com> I have to agree on this as well. I can understand when a service provider is having problems and people questioning it since that can affect many of us who depend on backbone connections, but sites like facebook and twitter being down should not be posted here but on the "sitesemployeeswastetimeon.org" [\sarcasm off] On 10/06/2010 02:20 PM, christian koch wrote: > +1 > > > > On Wed, Oct 6, 2010 at 12:57 AM, Zaid Ali wrote: > > >> I think the Outages mailing list is more appropriate for this. >> >> >> On 10/5/10 9:46 PM, "Mike Lyon" wrote: >> >> >>> Same here in SF Bay Area.... >>> >>> On Tue, Oct 5, 2010 at 9:44 PM, James Smith>> wrote: >>> >>> >>>> At 1:20am here in Canada, NB our networks are showing that facebook is >>>> down. >>>> Please confirm in the USA. >>>> >>>> >>>> >>>> ~SmithwaySecurity >>>> >>>> Sent from my iPhone >>>> >>>> >>>> >> >> >> >> From graham at apolix.co.za Wed Oct 6 14:16:04 2010 From: graham at apolix.co.za (Graham Beneke) Date: Wed, 06 Oct 2010 21:16:04 +0200 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> Message-ID: <4CACCAF4.40609@apolix.co.za> On 06/10/2010 17:15, William Herrin wrote: > I had my unpublished asterisk box up for all of two days before > getting half a megabit per second worth of false SIP registration > attempts. The script kiddies and botnets seem to by trying hard. I started announcing a brand new RIR allocation about 4 days ago and decided to tcpdump the background noise on the prefix before it gets used in production. About 80% of the traffic is systematic scanning on port 5060 across the entire prefix. -- Graham Beneke From Greg.Whynott at oicr.on.ca Wed Oct 6 14:21:42 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Wed, 6 Oct 2010 15:21:42 -0400 Subject: Facebook down!! Alert! In-Reply-To: References: Message-ID: <5D478BB5-7E53-40C1-9186-8CBA2D7A62FE@oicr.on.ca> Especially for Facebook alerts.. You are propagating a false perception that everyone cares. -g On Oct 6, 2010, at 2:20 PM, christian koch wrote: > +1 > > > > On Wed, Oct 6, 2010 at 12:57 AM, Zaid Ali wrote: > >> I think the Outages mailing list is more appropriate for this. >> >> >> On 10/5/10 9:46 PM, "Mike Lyon" wrote: >> >>> Same here in SF Bay Area.... >>> >>> On Tue, Oct 5, 2010 at 9:44 PM, James Smith >> wrote: >>> >>>> At 1:20am here in Canada, NB our networks are showing that facebook is >>>> down. >>>> Please confirm in the USA. >>>> >>>> >>>> >>>> ~SmithwaySecurity >>>> >>>> Sent from my iPhone >>>> >>>> >> >> >> >> From scott at doc.net.au Wed Oct 6 14:26:21 2010 From: scott at doc.net.au (Scott Howard) Date: Wed, 6 Oct 2010 12:26:21 -0700 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> <483E6B0272B0284BA86D7596C40D29F9E2C7B80772@PUR-EXCH07.ox.com> <483E6B0272B0284BA86D7596C40D29F9E2C7B80778@PUR-EXCH07.ox.com> Message-ID: On Wed, Oct 6, 2010 at 8:55 AM, Jon Lewis wrote: > Some do. Anyone with control of a phone system with digital lines (i.e. > asterisk with PRI) can trivially set callerID to whatever they want. There > are perfectly legitimate, and not so legitimate uses for this. > You don't even need the PRI. There's a number of SIP providers that will allow you to set CallerID. In some cases they do some level of verification first, but in many cases it's just a free-for-all. There were some laws passed recently which makes "faking" caller-id illegal, although I'm not sure exactly what the details are (eg, I'm fairly sure sending your cell phone number from a desk phone is fine as you own both of them). Scott. From brunner at nic-naa.net Wed Oct 6 14:28:57 2010 From: brunner at nic-naa.net (Eric Brunner-Williams) Date: Wed, 06 Oct 2010 15:28:57 -0400 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: References: <30427.1286363686@tristatelogic.com> <4CAC74DB.8010803@nic-naa.net> <4CAC7B0A.1080208@adversary.org> Message-ID: <4CACCDF9.90801@nic-naa.net> On 10/6/10 10:34 AM, Owen DeLong wrote: > > On Oct 6, 2010, at 6:35 AM, Ben McGinnes wrote: > >> On 7/10/10 12:08 AM, Eric Brunner-Williams wrote: >>> so ... should domains associated with asn(s) and addr block allocations >>> be subject to some expiry policy other than "it goes into the drop pool >>> and one of {enom,pool,...} acquire it (and the associated non-traffic >>> assets) for any interested party at $50 per /24"? >> >> Interesting idea, but how do you apply it to ccTLD domains with widely >> varying policies. All it takes is whois records being legitimately >> updated to use domain contacts using a ccTLD domain to circumvent. >> Sounds like more of a stop-gap measure. >> >> >> Regards, >> Ben >> >> > > Number resources are not and should not be associated with domain > resources at the policy level. This would make absolutely no sense > whatsoever. hmm. ... "are not" ... so the event complained of ... didn't happen? From drais at icantclick.org Wed Oct 6 14:31:16 2010 From: drais at icantclick.org (david raistrick) Date: Wed, 6 Oct 2010 15:31:16 -0400 (EDT) Subject: Facebook down!! Alert! In-Reply-To: <4CACC8E9.9030800@spectraaccess.com> References: <4CACC8E9.9030800@spectraaccess.com> Message-ID: On Wed, 6 Oct 2010, Bret Clark wrote: > I have to agree on this as well. I can understand when a service provider is you've forgotten that facebook (and indeed twitter too) are service providers that provide business-critical services. just because you don't want to play facebook games doesn't make a facebook outage any less operationally relevant than, say, an akamai or limelight outage. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From mjo at dojo.mi.org Wed Oct 6 14:32:17 2010 From: mjo at dojo.mi.org (Mike O'Connor) Date: Wed, 6 Oct 2010 19:32:17 +0000 Subject: Mobile Looking Glass? In-Reply-To: <768FB653686AE54A9B4FB9A1503F03F51D02AE1F3F@TENK7MVB.prod.travp.net> References: <768FB653686AE54A9B4FB9A1503F03F51D02AE1F3F@TENK7MVB.prod.travp.net> Message-ID: <20101006193217.GA16765@dojo.mi.org> :Anyone know of an iPhone application for checking public Looking Glass servers? : :Boss called me in a panic when I was out for lunch to check on something and would make my life much easier but searching for stuff on iTunes is awful. If you have an AIM or Jabber client on your iPhone, there's bgpbotz: http://software.merit.edu/bgpbotz/ I've used it successfully via AIM on my phone a couple times -- worked like a champ. -- Michael J. O'Connor mjo at dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "YOU MUST OBEY ME BECAUSE I'M LOUD!" -Dogbert From sil at infiltrated.net Wed Oct 6 14:38:34 2010 From: sil at infiltrated.net (J. Oquendo) Date: Wed, 06 Oct 2010 15:38:34 -0400 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> <483E6B0272B0284BA86D7596C40D29F9E2C7B80772@PUR-EXCH07.ox.com> <483E6B0272B0284BA86D7596C40D29F9E2C7B80778@PUR-EXCH07.ox.com> Message-ID: <4CACD03A.4000201@infiltrated.net> Scott Howard wrote: > On Wed, Oct 6, 2010 at 8:55 AM, Jon Lewis wrote: > > >> Some do. Anyone with control of a phone system with digital lines (i.e. >> asterisk with PRI) can trivially set callerID to whatever they want. There >> are perfectly legitimate, and not so legitimate uses for this. >> >> > > You don't even need the PRI. There's a number of SIP providers that will > allow you to set CallerID. In some cases they do some level of verification > first, but in many cases it's just a free-for-all. > > There were some laws passed recently which makes "faking" caller-id illegal, > although I'm not sure exactly what the details are (eg, I'm fairly sure > sending your cell phone number from a desk phone is fine as you own both of > them). > > Scott. > > It's HR 1258 the Truth in Caller ID Act however, means nothing to someone outside the United States and this is where the issue seems to stem from (a huge portion). So imagine the following: YourCompany --> VoIP_Peer --> Euro_Company Someone compromises something in Euro_Company, unbeknownst to that company, they're sending YOU traffic which you in turn pass (remember you trusted them here). Guess what? Euro_Company's PBX was sending false Caller ID. Should you be the one held liable as an ITSP? Further consideration: You --> Call Dell Support --> call re-routes to West Bumfork India --> Callee gets your callback Yourphone --> ring ring ring --> CID: Dell 12125551234 Where is the truth there? Anyhow, I don't know if Obama signed this into law yet. On my phone right now, I set the caller ID to the main number of my company so that clients take the appropriate steps in going through Customer Service. Guess what? When I'm at home and on-call my Caller-ID is set to my company's main number so that clients don't call me at home on a Sunday morning. Am I committing a "despicable" act by doing this? Is it any different than unplugging my Snom, Cisco or Polycom and bringing it home which yields the same results. While I do recognize the abuse (spammers, telemarketers, etc), I don't see how a bill is going to stop this from occurring. Who knows maybe blacklisting ITSP providers. Should we play a guessing game: "Well, it is coming from Global Crossing..." -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo SGFA, SGFE, C|EH, CNDA, CHFI, OSCP, CPT "It takes 20 years to build a reputation and five minutes to ruin it. If you think about that, you'll do things differently." - Warren Buffett 227C 5D35 7DCB 0893 95AA 4771 1DCE 1FD1 5CCD 6B5E http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E From baldwinmathew at gmail.com Wed Oct 6 15:06:51 2010 From: baldwinmathew at gmail.com (Matt Baldwin) Date: Wed, 6 Oct 2010 13:06:51 -0700 Subject: Facebook down!! Alert! In-Reply-To: References: <4CACC8E9.9030800@spectraaccess.com> Message-ID: I would imagine more businesses benefit from a FB outage in terms of a tick up in productivity versus businesses harmed by a FB outage, e.g. Zygna. So, net net a FB outage could be seen as a positive thing in the course of a work day. -matt On Wed, Oct 6, 2010 at 12:31 PM, david raistrick wrote: > On Wed, 6 Oct 2010, Bret Clark wrote: > >> I have to agree on this as well. I can understand when a service provider >> is > > > you've forgotten that facebook (and indeed twitter too) are service > providers that provide business-critical services. > > just because you don't want to play facebook games doesn't make a facebook > outage any less operationally relevant than, say, an akamai or limelight > outage. > > > > > > -- > david raistrick ? ? ? ?http://www.netmeister.org/news/learn2quote.html > drais at icantclick.org ? ? ? ? ? ? http://www.expita.com/nomime.html > > > From axs8091 at g.rit.edu Wed Oct 6 15:13:31 2010 From: axs8091 at g.rit.edu (axs8091 at g.rit.edu) Date: Wed, 6 Oct 2010 16:13:31 -0400 Subject: Mobile Looking Glass? In-Reply-To: <20101006193217.GA16765@dojo.mi.org> References: <768FB653686AE54A9B4FB9A1503F03F51D02AE1F3F@TENK7MVB.prod.travp.net> <20101006193217.GA16765@dojo.mi.org> Message-ID: I've use the app "Traceroute" before which aggregates most of the major ISP's looking glass sites and seems to be pretty good about keeping on top of it to clean up the broken ones. http://remarkablepixels.com/traceroute On Wed, Oct 6, 2010 at 3:32 PM, Mike O'Connor wrote: > :Anyone know of an iPhone application for checking public Looking Glass > servers? > : > :Boss called me in a panic when I was out for lunch to check on something > and would make my life much easier but searching for stuff on iTunes is > awful. > > If you have an AIM or Jabber client on your iPhone, there's bgpbotz: > > http://software.merit.edu/bgpbotz/ > > I've used it successfully via AIM on my phone a couple times -- worked > like a champ. > > -- > Michael J. O'Connor > mjo at dojo.mi.org > > =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= > "YOU MUST OBEY ME BECAUSE I'M LOUD!" > -Dogbert > > From Greg.Whynott at oicr.on.ca Wed Oct 6 15:22:34 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Wed, 6 Oct 2010 16:22:34 -0400 Subject: Facebook down!! Alert! In-Reply-To: References: <4CACC8E9.9030800@spectraaccess.com> Message-ID: > just because you don't want to play facebook games doesn't make a facebook > outage any less operationally relevant than, say, an akamai or limelight > outage. IMO which may be way off base, when akamai goes off the air, people lose potential sales/revenue. when facebook goes off the air, a greater number of companies become more efficient than those who suffer productivity loss. yes, it is worth mention, but else where, like twitter or on your wall. -g From jharper at well.com Wed Oct 6 15:33:10 2010 From: jharper at well.com (Jeff Harper) Date: Wed, 6 Oct 2010 13:33:10 -0700 (PDT) Subject: Facebook down!! Alert! In-Reply-To: <9C0A9F8E-110D-4232-85FB-EF17C5996CBE@edgewire.sg> Message-ID: <1139312017.1648.1286397190854.JavaMail.root@zimbra.well.com> > From: "Mark" > It's back up. There goes that short burst of productivity. > > > On Oct 6, 2010, at 12:49 PM, Mark Hofman wrote: > > > Ditto In AU and from other reports US. > > Guess productivity will go up ;-) The irony is that the short burst of productivity was spent troubleshooting if Facebook was up or down. From drais at icantclick.org Wed Oct 6 15:33:51 2010 From: drais at icantclick.org (david raistrick) Date: Wed, 6 Oct 2010 16:33:51 -0400 (EDT) Subject: Facebook down!! Alert! In-Reply-To: References: <4CACC8E9.9030800@spectraaccess.com> Message-ID: On Wed, 6 Oct 2010, Greg Whynott wrote: > >> just because you don't want to play facebook games doesn't make a facebook >> outage any less operationally relevant than, say, an akamai or limelight >> outage. > > IMO which may be way off base, when akamai goes off the air, people lose > potential sales/revenue. when facebook goes off the air, a greater > number of companies become more efficient than those who suffer > productivity loss. so the majority defines operational now, huh? wow. nice to know that network service providers outnumber other companies these days... (of course, those service providers also make their money from facebook consumers....) -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From drais at icantclick.org Wed Oct 6 15:34:54 2010 From: drais at icantclick.org (david raistrick) Date: Wed, 6 Oct 2010 16:34:54 -0400 (EDT) Subject: Facebook down!! Alert! In-Reply-To: References: <4CACC8E9.9030800@spectraaccess.com> Message-ID: On Wed, 6 Oct 2010, Matt Baldwin wrote: > I would imagine more businesses benefit from a FB outage in terms of a > tick up in productivity versus businesses harmed by a FB outage, e.g. Perhaps, then, we should instead be discussing the business benefits of blocking facebook so companies can regain productivity? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From trelane at trelane.net Wed Oct 6 15:39:03 2010 From: trelane at trelane.net (Andrew Kirch) Date: Wed, 06 Oct 2010 16:39:03 -0400 Subject: Facebook down!! Alert! In-Reply-To: References: <4CACC8E9.9030800@spectraaccess.com> Message-ID: <4CACDE67.6040209@trelane.net> On 10/6/2010 4:33 PM, david raistrick wrote: > > so the majority defines operational now, huh? wow. nice to know that > network service providers outnumber other companies these days... (of > course, those service providers also make their money from facebook > consumers....) No, the majority does not define what "operational" means. Facebook is not a mission critical internet resource (such as a fiber cut, power loss at a peering point, DoS attack. Please let's end this thread (And others of its ilk here and now). From MAdcock at hisna.com Wed Oct 6 15:39:41 2010 From: MAdcock at hisna.com (Adcock, Matt [HISNA]) Date: Wed, 6 Oct 2010 13:39:41 -0700 Subject: Facebook down!! Alert! References: <4CACC8E9.9030800@spectraaccess.com> Message-ID: <6AB0A22CB81B784A8CFF7B9A3AF11A2E420B94@hkeexm03v.hke.local> OpenDNS is my favorite for blocking things like FB and all sorts of other productivity killers. The information in this email and any attachments are for the sole use of the intended recipient and may contain privileged and confidential information.?If you are not the intended recipient, any use, disclosure, copying or distribution of this message or attachment is strictly prohibited.??We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message.?We cannot accept liability for any loss or damage caused by software viruses.?If you believe that you have received this email in error, please contact the sender immediately and delete the email and all of its attachments From: david raistrick [mailto:drais at icantclick.org] Sent: Wed 10/6/2010 3:34 PM To: Matt Baldwin Cc: nanog at nanog.org Subject: Re: Facebook down!! Alert! On Wed, 6 Oct 2010, Matt Baldwin wrote: > I would imagine more businesses benefit from a FB outage in terms of a > tick up in productivity versus businesses harmed by a FB outage, e.g. Perhaps, then, we should instead be discussing the business benefits of blocking facebook so companies can regain productivity? -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html ? From Ruben.Guerra at arrisi.com Wed Oct 6 15:47:14 2010 From: Ruben.Guerra at arrisi.com (Guerra, Ruben) Date: Wed, 6 Oct 2010 15:47:14 -0500 Subject: Facebook down!! Alert! In-Reply-To: <4CACDE67.6040209@trelane.net> References: <4CACC8E9.9030800@spectraaccess.com> <4CACDE67.6040209@trelane.net> Message-ID: <8BC9AA1D1BA4494F83F8205415225CE82614FD2719@CHIEXMAIL1.ARRS.ARRISI.COM> Passes Andrew the shotgun... Please kill all FB threads with it. :) The only thing I noticed being down last night is battle.net ;). Guess you know where my priorities are. Lol -Rg -----Original Message----- From: Andrew Kirch [mailto:trelane at trelane.net] Sent: Wednesday, October 06, 2010 3:39 PM To: nanog at nanog.org Subject: Re: Facebook down!! Alert! On 10/6/2010 4:33 PM, david raistrick wrote: > > so the majority defines operational now, huh? wow. nice to know that > network service providers outnumber other companies these days... (of > course, those service providers also make their money from facebook > consumers....) No, the majority does not define what "operational" means. Facebook is not a mission critical internet resource (such as a fiber cut, power loss at a peering point, DoS attack. Please let's end this thread (And others of its ilk here and now). From drais at icantclick.org Wed Oct 6 15:51:28 2010 From: drais at icantclick.org (david raistrick) Date: Wed, 6 Oct 2010 16:51:28 -0400 (EDT) Subject: Facebook down!! Alert! In-Reply-To: <4CACDE67.6040209@trelane.net> References: <4CACC8E9.9030800@spectraaccess.com> <4CACDE67.6040209@trelane.net> Message-ID: On Wed, 6 Oct 2010, Andrew Kirch wrote: > No, the majority does not define what "operational" means. Facebook is > not a mission critical internet resource (such as a fiber cut, power not a mission critical internet resource -to you- -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From nathan at atlasnetworks.us Wed Oct 6 15:54:38 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 6 Oct 2010 20:54:38 +0000 Subject: Facebook down!! Alert! In-Reply-To: <8BC9AA1D1BA4494F83F8205415225CE82614FD2719@CHIEXMAIL1.ARRS.ARRISI.COM> References: <4CACC8E9.9030800@spectraaccess.com> <4CACDE67.6040209@trelane.net> <8BC9AA1D1BA4494F83F8205415225CE82614FD2719@CHIEXMAIL1.ARRS.ARRISI.COM> Message-ID: <8C26A4FDAE599041A13EB499117D3C284060AF3B@ex-mb-2.corp.atlasnetworks.us> > -----Original Message----- > From: Guerra, Ruben [mailto:Ruben.Guerra at arrisi.com] > Sent: Wednesday, October 06, 2010 1:47 PM > To: nanog at nanog.org > Subject: RE: Facebook down!! Alert! > > Passes Andrew the shotgun... Please kill all FB threads with it. :) > > The only thing I noticed being down last night is battle.net ;). Guess you > know where my priorities are. Lol > > -Rg Minecraft.net keeps going down, maybe we should start a thread about that, too! Nathan From drais at icantclick.org Wed Oct 6 16:05:10 2010 From: drais at icantclick.org (david raistrick) Date: Wed, 6 Oct 2010 17:05:10 -0400 (EDT) Subject: Facebook down!! Alert! In-Reply-To: References: <4CACC8E9.9030800@spectraaccess.com> <4CACDE67.6040209@trelane.net> Message-ID: On Wed, 6 Oct 2010, david raistrick wrote: > On Wed, 6 Oct 2010, Andrew Kirch wrote: > >> No, the majority does not define what "operational" means. Facebook is >> not a mission critical internet resource (such as a fiber cut, power > > not a mission critical internet resource -to you- to be clear, I could give a damn about if we talk about this on nanog or not. (and I agree that outages is the right place to announce outages, and outage-discuss to discuss them). my point is that facebook has moved beyond being a pure content provider, and (much like, say, google) provide both content AND service. I have dependancies on facebook's (as do many many others who perhaps dont yet hire folks who even know what nanog is but someday will) services. without them, my teams can't work and my employeer loses signiicant figures of revenue per day. so facebook is very much operationally relevant for my network, and that these mixed content/service providers will be more and more relevant as time goes on and we as a community should figure out how to deal with their transition from pure content to perhaps some day pure service. -- david raistrick http://www.netmeister.org/news/learn2quote.html drais at icantclick.org http://www.expita.com/nomime.html From trelane at trelane.net Wed Oct 6 16:13:15 2010 From: trelane at trelane.net (Andrew Kirch) Date: Wed, 06 Oct 2010 17:13:15 -0400 Subject: Facebook down!! Alert! In-Reply-To: References: <4CACC8E9.9030800@spectraaccess.com> <4CACDE67.6040209@trelane.net> Message-ID: <4CACE66B.2020707@trelane.net> On 10/6/2010 5:05 PM, david raistrick wrote: > > > to be clear, I could give a damn about if we talk about this on nanog > or not. (and I agree that outages is the right place to announce > outages, and outage-discuss to discuss them). > > > my point is that facebook has moved beyond being a pure content > provider, and (much like, say, google) provide both content AND > service. I have dependancies on facebook's (as do many many others > who perhaps dont yet hire folks who even know what nanog is but > someday will) services. without them, my teams can't work and my > employeer loses signiicant figures of revenue per day. > > so facebook is very much operationally relevant for my network, and > that these mixed content/service providers will be more and more > relevant as time goes on and we as a community should figure out how > to deal with their transition from pure content to perhaps some day > pure service. My company buys firearms, so I am going to start posting to nanog every time my service providers go down (Springfield Armory, Rock River Arms, Volkmann Custom, and Benelli). Certainly they're a website, but without that website I can't order the firearms which costs me significant figures of revenue per day. Perhaps your company buys widgets of some sort? That is not however a core networking issue. Facebook outages may be important to your company, and I do some business on there as well, but NANOG is not a list where non-bandwidth vendor outages should be reported. (unless you like guns too!) Andrew From Valdis.Kletnieks at vt.edu Wed Oct 6 16:17:08 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 06 Oct 2010 17:17:08 -0400 Subject: Facebook down!! Alert! In-Reply-To: Your message of "Wed, 06 Oct 2010 16:39:03 EDT." <4CACDE67.6040209@trelane.net> References: <4CACC8E9.9030800@spectraaccess.com> <4CACDE67.6040209@trelane.net> Message-ID: <47668.1286399828@localhost> On Wed, 06 Oct 2010 16:39:03 EDT, Andrew Kirch said: > No, the majority does not define what "operational" means. Facebook is > not a mission critical internet resource (such as a fiber cut, power > loss at a peering point, DoS attack. Yes, but anytime something spikes the number of calls at my help desk, that *is* an operational issue, even if it's something stupid in the eyes of the savvy network engineers that hang out here... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From FEARGAL_LEDWIDGE at CRGL-THIRDPARTY.COM Wed Oct 6 16:22:50 2010 From: FEARGAL_LEDWIDGE at CRGL-THIRDPARTY.COM (FEARGAL_LEDWIDGE at CRGL-THIRDPARTY.COM) Date: Wed, 6 Oct 2010 16:22:50 -0500 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> <20101006143735.GA3425@dan.olp.net> <483E6B0272B0284BA86D7596C40D29F9E2C7B80772@PUR-EXCH07.ox.com> <483E6B0272B0284BA86D7596C40D29F9E2C7B80778@PUR-EXCH07.ox.com> Message-ID: From: scott at doc.net.au [mailto:scott at doc.net.au] Sent: Wednesday, October 06, 2010 2:26 PM Subject: Re: Scam telemarketers spoofing our NOC phone number for callerid >There were some laws passed recently which makes "faking" caller-id illegal, >although I'm not sure exactly what the details are (eg, I'm fairly sure >sending your cell phone number from a desk phone is fine as you own both of >them). In the US - it's not quite law yet. The bill in question is H.R. 1258: Truth in Caller ID Act of 2010. It was passed by the house in April 2010 - but has not yet been passed by the Senate. A similar bill was passed by the Senate previously - so it's only a matter of time. Specifically - the bill will make it illegal "to cause any caller ID service to transmit misleading or inaccurate caller ID information." Changing your caller-id for legitimate non-nefarious purposes will still be allowed. Feargal From dwhite at olp.net Wed Oct 6 16:24:05 2010 From: dwhite at olp.net (Dan White) Date: Wed, 6 Oct 2010 16:24:05 -0500 Subject: Facebook down!! Alert! In-Reply-To: References: <4CACC8E9.9030800@spectraaccess.com> <4CACDE67.6040209@trelane.net> Message-ID: <20101006212405.GL3425@dan.olp.net> On 06/10/10?17:05?-0400, david raistrick wrote: >my point is that facebook has moved beyond being a pure content >provider, and (much like, say, google) provide both content AND >service. I have dependancies on facebook's (as do many many others >who perhaps dont yet hire folks who even know what nanog is but >someday will) services. without them, my teams can't work and my >employeer loses signiicant figures of revenue per day. Why can't your teams work? Do they have email? I'm trying to imagine what operational scenarios are involved between the technical staff in a company that depend on Facebook being up, unless you're working for Facebook. Even if I were not email inclined, I'd set up a local XMPP server do to my communication. >so facebook is very much operationally relevant for my network, and >that these mixed content/service providers will be more and more >relevant as time goes on and we as a community should figure out how >to deal with their transition from pure content to perhaps some day >pure service. How we deal with it is to create a viable distributed version of it. -- Dan White From rfg at tristatelogic.com Wed Oct 6 17:01:45 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 06 Oct 2010 15:01:45 -0700 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: Message-ID: <35125.1286402505@tristatelogic.com> In message , Heath Jones wrote: >> Certainly, fine folks at Reliance Globalcom Services, Inc. could tell >> us who is paying them to connect these hijacked blocks to their network, >> but I rather doubt that they are actually going to come clean and do >> that. > >Ron, I haven't been following this anti-spam stuff much since it went >political with ARIN but I do have a few quick questions (relating to >US law and spam). > >1) Is spamming from within the US criminal activity? Sadly, it appears not. In many cases it is however actionable. (And in other cases involving actual criminal activity, e.g. as prohibited by 18 USC 1030, `Fraud and related activity in connection with computers', it may, I think, be considered as an aggravating factor in determining punishments.) >What constitutes spam in that case? Are you asking what I think? Or what the majority of netizens think? Or are you asking what U.S. courts think? Those are three different answers. >2) If you could justify the incoming spam as a DOS, is that criminal >activity? Could you justify it as a DOS? Yes. No. >3) Is providing ARIN with bogus information just to get around their >processes criminal activity? In this case, nobody provided ARIN with *any* bogus information, ever. (So your question is utterly irrelevant to this particular case.) >4) Is obtaining disused IP space / AS allocations from assigned >entity, and not updating ARIN criminal activity? In this particular case, nobody appears to have ``obtained'' IP space from the various High Schools, Middle Schools, and Elementary schools involved, other than via deceit, trickery, and fraud. Were the various schools involved here ripped off? I would say yes. Does the fraud in this case rise to the level of being either criminal or actionable? I am not a lawyer, but my guess is that the answer is probably yes to both... *IF* anybody cared enough to persue it. I base that opinion stictly and only on the definition of the English language word `fraud' as given at www.merriam-webster.com. As regards to updating ARIN, or the lack thereof, the _absence_ of such ``updating'', in this case... i.e. the absence of any notice to ARIN that these blocks were being glomed onto... is part of the overall pattern of fraud in this case which, as I have said, I believe to be potentially both criminal and actionable... if anybody cared enough to persue it. But that's just my opinion, and I am not a lawyer. >5) Is advertising Prefixes or AS number assigned to another entity >criminal activity? If it constitutes criminal fraud which deprives some party of some property, or some right, or the full enjoyment of some property or some right, to which they are otherwise entitled, under law, then yes, although I am not a lawyer, my limited understanding of the law in these United States indicates to me that yes, most probably such activity may well be considered criminal, in at least some circumstances, perhaps including the ones being discussed in this thread. >6) If any of the above could be classed as criminal activity, are >Reliance Globalcom (in this case) legally obligated to cut them off?, The answer to that depends, I think, upon whether they are _knowing_ participants in the fraud. If they merely got duped... which is indeed what is suggested by that fact that somebody paid $4,000 to get a specific domain name so that they could then dupe _somebody_ (where that somebody who was to be duped, in this case was clearly _not_ ARIN)... then in that case, Reliance Globalcom is just another one of the victims, and not one of the perpetrators. Hypothetically, if, once they have been duly informed that this particular fraud is ongoing, they do nothing, and continue announcing the routes even after allowing them a reasonable amount of time to properly investigate what is going on here, then at that point I think that yes, then they might in fact be criminally liable, civilly liable, or both. >or just help by switching on a packet capture What would be the point of that?? I can already tell you what the blocks in question are most probably being used for, and have done so already, I think. Regards, rfg From tammy-lists at wiztech.biz Wed Oct 6 17:08:53 2010 From: tammy-lists at wiztech.biz (Tammy A. Wisdom) Date: Wed, 6 Oct 2010 16:08:53 -0600 (MDT) Subject: Facebook down!! Alert! In-Reply-To: Message-ID: <684680241.389.1286402933799.JavaMail.root@lordsofacid.wiztech.biz> ----- Original Message ----- > From: "david raistrick" > To: "Andrew Kirch" > Cc: nanog at nanog.org > Sent: Wednesday, October 6, 2010 3:05:10 PM > Subject: Re: Facebook down!! Alert! > On Wed, 6 Oct 2010, david raistrick wrote: > > > On Wed, 6 Oct 2010, Andrew Kirch wrote: > > > >> No, the majority does not define what "operational" means. Facebook > >> is > >> not a mission critical internet resource (such as a fiber cut, > >> power > > > > not a mission critical internet resource -to you- > > > to be clear, I could give a damn about if we talk about this on nanog > or > not. (and I agree that outages is the right place to announce outages, > and outage-discuss to discuss them). > > > my point is that facebook has moved beyond being a pure content > provider, > and (much like, say, google) provide both content AND service. I have > dependancies on facebook's (as do many many others who perhaps dont > yet > hire folks who even know what nanog is but someday will) services. > without them, my teams can't work and my employeer loses signiicant > figures of revenue per day. > > so facebook is very much operationally relevant for my network, and > that > these mixed content/service providers will be more and more relevant > as > time goes on and we as a community should figure out how to deal with > their transition from pure content to perhaps some day pure service. > This thread proves too me yet again that nanog is the internets equivalent of a giant panty raid. This isn't the outages list & I am rather annoyed that we must discuss junk social media sites such as facebook. Just because you are panicing does not mean that the thousands of people on this list give a flying rats ass that facebook is down! Can we please discuss relevant topics such as running networks? (for instance NOT @#$@#$ing FACEBOOK!) This list over the last year has just gone soo far downhill that I am most likely going to unsubscribe from it as I don't get any technical benefit from the garbage that is discussed on this list 99.999999999999999% of the time. --Tammy -- Tammy A Wisdom The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org ****************************************************************************** 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 lostinmoscow at gmail.com Wed Oct 6 17:11:54 2010 From: lostinmoscow at gmail.com (Quinn Kuzmich) Date: Wed, 6 Oct 2010 16:11:54 -0600 Subject: Facebook down!! Alert! In-Reply-To: <684680241.389.1286402933799.JavaMail.root@lordsofacid.wiztech.biz> References: <684680241.389.1286402933799.JavaMail.root@lordsofacid.wiztech.biz> Message-ID: Giant Panty Raid. Now I know what I'll be calling my weekend/overnight shifts. Who says being a Network Engineer can't be fun? Q On Wed, Oct 6, 2010 at 4:08 PM, Tammy A. Wisdom wrote: > > > This thread proves too me yet again that nanog is the internets equivalent > of a giant panty raid. This isn't the outages list & I am rather annoyed > that we must discuss junk social media sites such as facebook. Just because > you are panicing does not mean that the thousands of people on this list > give a flying rats ass that facebook is down! > Can we please discuss relevant topics such as running networks? (for > instance NOT @#$@#$ing FACEBOOK!) > This list over the last year has just gone soo far downhill that I am most > likely going to unsubscribe from it as I don't get any technical benefit > from the garbage that is discussed on this list 99.999999999999999% of the > time. > > --Tammy > From mehmet at akcin.net Wed Oct 6 17:14:38 2010 From: mehmet at akcin.net (Mehmet Akcin) Date: Wed, 6 Oct 2010 18:14:38 -0400 Subject: Los Angeles Internet Exchanges Message-ID: Hello, if you are somewhat involved with technical or non technical operations of IX points within Los Angeles / Orange County area, could you please contact me off-list? thank you. mehmet From randy at psg.com Wed Oct 6 17:16:15 2010 From: randy at psg.com (Randy Bush) Date: Thu, 07 Oct 2010 07:16:15 +0900 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> Message-ID: not directly related, but i get occasional harrassing calls from mental/emotional children who are using whois. it's amusing but basically pathetic. randy From hj1980 at gmail.com Wed Oct 6 17:23:46 2010 From: hj1980 at gmail.com (Heath Jones) Date: Wed, 6 Oct 2010 23:23:46 +0100 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <35125.1286402505@tristatelogic.com> References: <35125.1286402505@tristatelogic.com> Message-ID: >>1) Is spamming from within the US criminal activity? > > Sadly, it appears not. > > In many cases it is however actionable. ?(And in other cases involving > actual criminal activity, e.g. as prohibited by 18 USC 1030, `Fraud and > related activity in connection with computers', it may, I think, be > considered as an aggravating factor in determining punishments.) Wouldn't it have to be illegal before punishments could be determined? Isn't this kind of key to the whole issue of fighting spam?? (Is there even a point if you cant nail them for it?) >>What constitutes spam in that case? > > Are you asking what I think? ?Or what the majority of netizens think? > Or are you asking what U.S. courts think? > > Those are three different answers. With regards to US court. >>2) If you could justify the incoming spam as a DOS, is that criminal >>activity? Could you justify it as a DOS? > > Yes. ?No. Ok. >>3) Is providing ARIN with bogus information just to get around their >>processes criminal activity? > > In this case, nobody provided ARIN with *any* bogus information, ever. > (So your question is utterly irrelevant to this particular case.) Not at all irrelevant, I'm talking generically here (not specific to this case). Trying to cover all bases. >>4) Is obtaining disused IP space / AS allocations from assigned >>entity, and not updating ARIN criminal activity? > > In this particular case, nobody appears to have ``obtained'' IP space > from the various High Schools, Middle Schools, and Elementary schools > involved, other than via deceit, trickery, and fraud. ?Were the various > schools involved here ripped off? ?I would say yes. ?Does the fraud in > this case rise to the level of being either criminal or actionable? > I am not a lawyer, but my guess is that the answer is probably yes to > both... *IF* anybody cared enough to persue it. ?I base that opinion > stictly and only on the definition of the English language word `fraud' > as given at www.merriam-webster.com. > > As regards to updating ARIN, or the lack thereof, the _absence_ of such > ``updating'', in this case... i.e. the absence of any notice to ARIN > that these blocks were being glomed onto... is part of the overall > pattern of fraud in this case which, as I have said, I believe to be > potentially both criminal and actionable... if anybody cared enough to > persue it. > > But that's just my opinion, and I am not a lawyer. Perhaps there is a method of class action, as opposed to individual companies trying to sue? >>5) Is advertising Prefixes or AS number assigned to another entity >>criminal activity? > > If it constitutes criminal fraud which deprives some party of some property, > or some right, or the full enjoyment of some property or some right, to which > they are otherwise entitled, under law, then yes, although I am not a > lawyer, my limited understanding of the law in these United States indicates > to me that yes, most probably such activity may well be considered criminal, > in at least some circumstances, perhaps including the ones being discussed > in this thread. Well that might possibly be a start of a legal avenue..? >>6) If any of the above could be classed as criminal activity, are >>Reliance Globalcom (in this case) legally obligated to cut them off?, > > The answer to that depends, I think, upon whether they are _knowing_ > participants in the fraud. ?If they merely got duped... which is indeed > what is suggested by that fact that somebody paid $4,000 to get a specific > domain name so that they could then dupe _somebody_ (where that somebody > who was to be duped, in this case was clearly _not_ ARIN)... then in > that case, Reliance Globalcom is just another one of the victims, and not > one of the perpetrators. > > Hypothetically, if, once they have been duly informed that this particular > fraud is ongoing, they do nothing, and continue announcing the routes even > after allowing them a reasonable amount of time to properly investigate what > is going on here, then at that point I think that yes, then they might in > fact be criminally liable, civilly liable, or both. Might be worth pointing that out to them? Most companies don't like risk.. >>or just help by switching on a packet capture > > What would be the point of that?? > > I can already tell you what the blocks in question are most probably being > used for, and have done so already, I think. I was referring to new legislation coming into effect that gives the FBI? the power to say 'flick the switch on now' and they then can log traffic.. All in all, it just seems pretty pointless trying to fight spam if the law isnt backing you. Filtering yes, fighting no.. Perhaps the law is what needs to be worked on? (As a general comment to all) Cheers Heath From bclark at spectraaccess.com Wed Oct 6 17:24:57 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Wed, 06 Oct 2010 18:24:57 -0400 Subject: Facebook down!! Alert! In-Reply-To: <684680241.389.1286402933799.JavaMail.root@lordsofacid.wiztech.biz> References: <684680241.389.1286402933799.JavaMail.root@lordsofacid.wiztech.biz> Message-ID: <4CACF739.2010800@spectraaccess.com> On 10/06/2010 06:08 PM, Tammy A. Wisdom wrote: > This thread proves too me yet again that nanog is the internets equivalent of a giant panty raid. This isn't the outages list& I am rather annoyed that we must discuss junk social media sites such as facebook. Just because you are panicing does not mean that the thousands of people on this list give a flying rats ass that facebook is down! > Can we please discuss relevant topics such as running networks? (for instance NOT @#$@#$ing FACEBOOK!) > This list over the last year has just gone soo far downhill that I am most likely going to unsubscribe from it as I don't get any technical benefit from the garbage that is discussed on this list 99.999999999999999% of the time. > > --Tammy > > I've always looked at the nanog list representing issues up to layer 4 of the OSI model; mostly layer 3/4. Maybe a new mailing list could be made called the North American Network Applications Group (nanag)...there might be a pun there :). Bret From sven at cb3rob.net Wed Oct 6 17:14:27 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Wed, 6 Oct 2010 22:14:27 +0000 (UTC) Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <35125.1286402505@tristatelogic.com> References: <35125.1286402505@tristatelogic.com> Message-ID: - Exactly when and where did RIR whois databases gain any legal status as an authoritive source of information, rather than just an internal tool for network operators? (as far as i see, the rirs are legally nothing more than a collective of network operators, not an authority in any way). - Exactly when and where did RIR whois entries, or rather the lack thereof prohibit any other use of those ranges (as in: blatantly announcing them, not having a registered AS number or someone elses AS number). - Exactly since when and where did IP addresses become property? (Ok, there are some court verdicts identifying them as "personal details" (although they identify a node on a network, not a person ;) - If they are indeed personal details, they are not allowed to be in public whois in the first place without the consent of the end-end-end user (privacy laws) And furthermore, if you want to stop spam on that shitty old SMTP protocol, i suggest you stop wasting time on blacklisting ips, and start working on a standard to issue all your "buddies" with a unique password so your mailserver accepts their mail and nobody elses. EVERY MODERN PROTOCOL (skype, msn) does it -that- way, and -that- works. for which it is required that: 1: a standard header is created thats discared on forwards "Password: " 2: mailinglists, online shops, etc, anyone who does not have your businesscard with a unique password on it, add a field for this. (keep in mind, each sender gets a unique password from the receiver, this can be stored in the address book along with the email address itself). - You "Spam fighters" have effectively KILLED smtp by: - blacklists - your anti open relay crap - motivating eyeball isps to block port 25 - graylisting makes it so damn slow nobody wants to use it anymore anyway all of this has resulted in: SMTP no longer being used on the actual workstations Therefore not operating in a p2p and real-time fashion and did you manage to stop spam? -> NO, you just managed to make it completely un workable and unreliable. did you manage to make people choose other protocols such as Skype and MSN: yes! (if email was still used in a p2p fashion people would not -need- instant messengers in the first place, as their wintendo computer would just talk smtp and store directly to the inbox) Imap, pop2, pop3 and all that other crap could have been skipped. -- 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 ========================================================================= 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. On Wed, 6 Oct 2010, Ronald F. Guilmette wrote: > > In message , > Heath Jones wrote: > >>> Certainly, fine folks at Reliance Globalcom Services, Inc. could tell >>> us who is paying them to connect these hijacked blocks to their network, >>> but I rather doubt that they are actually going to come clean and do >>> that. >> >> Ron, I haven't been following this anti-spam stuff much since it went >> political with ARIN but I do have a few quick questions (relating to >> US law and spam). >> >> 1) Is spamming from within the US criminal activity? > > Sadly, it appears not. > > In many cases it is however actionable. (And in other cases involving > actual criminal activity, e.g. as prohibited by 18 USC 1030, `Fraud and > related activity in connection with computers', it may, I think, be > considered as an aggravating factor in determining punishments.) > >> What constitutes spam in that case? > > Are you asking what I think? Or what the majority of netizens think? > Or are you asking what U.S. courts think? > > Those are three different answers. > >> 2) If you could justify the incoming spam as a DOS, is that criminal >> activity? Could you justify it as a DOS? > > Yes. No. > >> 3) Is providing ARIN with bogus information just to get around their >> processes criminal activity? > > In this case, nobody provided ARIN with *any* bogus information, ever. > (So your question is utterly irrelevant to this particular case.) > >> 4) Is obtaining disused IP space / AS allocations from assigned >> entity, and not updating ARIN criminal activity? > > In this particular case, nobody appears to have ``obtained'' IP space > from the various High Schools, Middle Schools, and Elementary schools > involved, other than via deceit, trickery, and fraud. Were the various > schools involved here ripped off? I would say yes. Does the fraud in > this case rise to the level of being either criminal or actionable? > I am not a lawyer, but my guess is that the answer is probably yes to > both... *IF* anybody cared enough to persue it. I base that opinion > stictly and only on the definition of the English language word `fraud' > as given at www.merriam-webster.com. > > As regards to updating ARIN, or the lack thereof, the _absence_ of such > ``updating'', in this case... i.e. the absence of any notice to ARIN > that these blocks were being glomed onto... is part of the overall > pattern of fraud in this case which, as I have said, I believe to be > potentially both criminal and actionable... if anybody cared enough to > persue it. > > But that's just my opinion, and I am not a lawyer. > >> 5) Is advertising Prefixes or AS number assigned to another entity >> criminal activity? > > If it constitutes criminal fraud which deprives some party of some property, > or some right, or the full enjoyment of some property or some right, to which > they are otherwise entitled, under law, then yes, although I am not a > lawyer, my limited understanding of the law in these United States indicates > to me that yes, most probably such activity may well be considered criminal, > in at least some circumstances, perhaps including the ones being discussed > in this thread. > >> 6) If any of the above could be classed as criminal activity, are >> Reliance Globalcom (in this case) legally obligated to cut them off?, > > The answer to that depends, I think, upon whether they are _knowing_ > participants in the fraud. If they merely got duped... which is indeed > what is suggested by that fact that somebody paid $4,000 to get a specific > domain name so that they could then dupe _somebody_ (where that somebody > who was to be duped, in this case was clearly _not_ ARIN)... then in > that case, Reliance Globalcom is just another one of the victims, and not > one of the perpetrators. > > Hypothetically, if, once they have been duly informed that this particular > fraud is ongoing, they do nothing, and continue announcing the routes even > after allowing them a reasonable amount of time to properly investigate what > is going on here, then at that point I think that yes, then they might in > fact be criminally liable, civilly liable, or both. > >> or just help by switching on a packet capture > > What would be the point of that?? > > I can already tell you what the blocks in question are most probably being > used for, and have done so already, I think. > > > Regards, > rfg > From jvanoppen at spectrumnet.us Wed Oct 6 20:15:21 2010 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 7 Oct 2010 01:15:21 +0000 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> Message-ID: We get people calling our noc numbers pretty often trying to report abuse for other people's networks... that is always fun John van Oppen / AS11404 -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Sent: Wednesday, October 06, 2010 3:16 PM To: Matthew Huff Cc: ' (nanog at nanog.org)' Subject: Re: Scam telemarketers spoofing our NOC phone number for callerid not directly related, but i get occasional harrassing calls from mental/emotional children who are using whois. it's amusing but basically pathetic. randy From jvanoppen at spectrumnet.us Wed Oct 6 20:20:40 2010 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 7 Oct 2010 01:20:40 +0000 Subject: Facebook down!! Alert! In-Reply-To: <20101006212405.GL3425@dan.olp.net> References: <4CACC8E9.9030800@spectraaccess.com> <4CACDE67.6040209@trelane.net> <20101006212405.GL3425@dan.olp.net> Message-ID: The only way in which I can see facebook as required for operations is when one is hosting apps that must interact with the facbook API. Facebook is a site we keep an eye on from our NOC simply because it is important to a lot our larger transit customers due to them having apps that require facebook API access. We tend to also get calls from the .edu sites we service when it has outages. That being said, facebook outages are not really an internal problem for us and it would seem odd to trust bussness proccesses to free social network site. John / AS11404 -----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: Wednesday, October 06, 2010 2:24 PM To: david raistrick Cc: nanog at nanog.org Subject: Re: Facebook down!! Alert! On 06/10/10?17:05?-0400, david raistrick wrote: >my point is that facebook has moved beyond being a pure content >provider, and (much like, say, google) provide both content AND >service. I have dependancies on facebook's (as do many many others >who perhaps dont yet hire folks who even know what nanog is but >someday will) services. without them, my teams can't work and my >employeer loses signiicant figures of revenue per day. Why can't your teams work? Do they have email? I'm trying to imagine what operational scenarios are involved between the technical staff in a company that depend on Facebook being up, unless you're working for Facebook. Even if I were not email inclined, I'd set up a local XMPP server do to my communication. >so facebook is very much operationally relevant for my network, and >that these mixed content/service providers will be more and more >relevant as time goes on and we as a community should figure out how >to deal with their transition from pure content to perhaps some day >pure service. How we deal with it is to create a viable distributed version of it. -- Dan White From randy at psg.com Wed Oct 6 20:20:41 2010 From: randy at psg.com (Randy Bush) Date: Thu, 07 Oct 2010 10:20:41 +0900 Subject: Scam telemarketers spoofing our NOC phone number for callerid In-Reply-To: References: <483E6B0272B0284BA86D7596C40D29F9E2C7B8076F@PUR-EXCH07.ox.com> Message-ID: > We get people calling our noc numbers pretty often trying to report > abuse for other people's networks... that is always fun >> not directly related, but i get occasional harrassing calls from >> mental/emotional children who are using whois. it's amusing but >> basically pathetic. no, i mean classic children's behavior pretending they are the police or whatever. randy From gbonser at seven.com Wed Oct 6 20:25:39 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 6 Oct 2010 18:25:39 -0700 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: References: <35125.1286402505@tristatelogic.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C0C6@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Heath Jones > Sent: Wednesday, October 06, 2010 3:24 PM > To: nanog at nanog.org > Subject: Re: New hijacking - Done via via good old-fashioned Identity > Theft > > Wouldn't it have to be illegal before punishments could be determined? > Isn't this kind of key to the whole issue of fighting spam?? (Is there > even a point if you cant nail them for it?) This conversation isn't really about spam. It is about being able to obtain the number resources of a defunct organization by masquerading as that organization by registering an identical business entity or operating name. So foo.com has legitimately obtained number resources. Foo.com goes broke and those resources are no longer in use. Joe Blow registers an operation he calls foo.com and claims the right to use those number resources. I don't care if those resources are being used for spam or giving away free money to the needy, that is beside the point. The issue as I see it is to raise awareness that just because foo.com wants to announce resources and just because that WHOIS says those resources belong to foo.com, it doesn't mean that the two are the same foo.com Having an organization come to you wanting to announce a /18 of network space (that was allocated 10 years ago) and their domain was only created a week ago might be a clue. G From ben at adversary.org Wed Oct 6 21:44:49 2010 From: ben at adversary.org (Ben McGinnes) Date: Thu, 07 Oct 2010 13:44:49 +1100 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <4CACCDF9.90801@nic-naa.net> References: <30427.1286363686@tristatelogic.com> <4CAC74DB.8010803@nic-naa.net> <4CAC7B0A.1080208@adversary.org> <4CACCDF9.90801@nic-naa.net> Message-ID: <4CAD3421.4000006@adversary.org> On 7/10/10 6:28 AM, Eric Brunner-Williams wrote: > On 10/6/10 10:34 AM, Owen DeLong wrote: >> >> Number resources are not and should not be associated with domain >> resources at the policy level. This would make absolutely no sense >> whatsoever. > > hmm. ... "are not" ... so the event complained of ... didn't happen? The key issue here is more the "should not" aspect, which I agree with, but that these records are frequently used by netops to verify a request. There really needs to be a greater standardised level of due diligence regarding advertisement requests that checks more than whether a request is coming from a seemingly legitimate email address. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From rsk at gsp.org Wed Oct 6 22:12:24 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Wed, 6 Oct 2010 23:12:24 -0400 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: References: <35125.1286402505@tristatelogic.com> Message-ID: <20101007031224.GA10137@gsp.org> On Wed, Oct 06, 2010 at 10:14:27PM +0000, Sven Olaf Kamphuis wrote: > (keep in mind, each sender gets a unique password from the receiver, > this can be stored in the address book along with the email address > itself). I'd like to see the I-D which explains how this is going to work, with particular attention to (a) how the passwords will be exchanged without using email (b) how it's going to handle the O(N^2) scaling and (c) how it's going to work in an environment with at least a hundred million compromised systems -- that is, systems that are now owned by the enemy, who thus also owns the contents of all the address books stored on them...including all the passwords. I think once these issues are addressed it will be only a small matter of implementation to convince everyone to swiftly move to a different protocol for mail. ---rsk From rfg at tristatelogic.com Wed Oct 6 22:36:13 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Wed, 06 Oct 2010 20:36:13 -0700 Subject: AS6517 - Reliance Globalcom -- routing three more hijacked blocks Message-ID: <37614.1286422573@tristatelogic.com> Has anybody ever succeeded at sending any e-mail to the address? It doesn't seem to work for me. I just get undeliverable bounces. I'd like to, you know, at least inform them about all of these hijacked routes that _they_ are announcing, but I guess I need to do that via smoke signal or something. Well, anyway, here's three more hijacked blocks that they (AS6517) are routing. This is in addition to the 75 such blocks I've already reported. (I guess that makes 78 hijacked blocks for them, in total.) 198.99.245.0/24 NET-198-99-245-0-1 (wjhoreni.com - domain registered 2009-10-30) 198.151.138.0/24 NET-198-151-138-0-1 (crescentnets.com - registered 07-09-2010, in the Cayman Islands) 207.45.56.0/21 NET-207-45-56-0-1 (crescentnets.com - see above) Name server dump of the above blocks, illustrating snowshoe spam domains: -------------------------------------------------------------------------- 198.99.245.2 ns1.heypamperedpet.com heypamperedpet.com ns1.bestpamperedpooch.com bestpamperedpooch.com ns1.pamperedpetgift.com pamperedpetgift.com ns1.superpamperedpooch.com superpamperedpooch.com ns1.pamperedpethouse.com pamperedpethouse.com ns1.littlepamperedpooch.com littlepamperedpooch.com ns1.pamperedpethaven.com pamperedpethaven.com ns1.pamperedpethomes.com pamperedpethomes.com ns1.pamperedpetbeds.com pamperedpetbeds.com ns1.pamperedpoochpatrol.com pamperedpoochpatrol.com ns1.pamperedbellapooch.com pamperedbellapooch.com ns1.pamperedpetinc.com pamperedpetinc.com ns1.pamperedpetmotel.com pamperedpetmotel.com ns1.pamperedpetllc.com pamperedpetllc.com ns1.pamperedpoochworld.com pamperedpoochworld.com ns1.yourpetexpo.com yourpetexpo.com ns1.thepetbond.com thepetbond.com ns1.thespoiledspouse.com thespoiledspouse.com ns1.spoileddoggies.com spoileddoggies.com ns1.pamperedanimal.com pamperedanimal.com ns1.thewelfarefund.com thewelfarefund.com ns1.animalwelfarejournal.com animalwelfarejournal.com ns1.animalwelfarealliance.com animalwelfarealliance.com ns1.richwelfare.com richwelfare.com ns1.companionbailout.com companionbailout.com ns1.poochproductsguide.com poochproductsguide.com ns1.poochadvocate.com poochadvocate.com ns1.socialwelfaretrust.com socialwelfaretrust.com ns1.prosperouswelfare.com prosperouswelfare.com ns1.childwelfarereview.com childwelfarereview.com ns1.wjhoreni.com wjhoreni.com 198.99.245.3 ns2.heypamperedpet.com heypamperedpet.com ns2.bestpamperedpooch.com bestpamperedpooch.com ns2.pamperedpetgift.com pamperedpetgift.com ns2.superpamperedpooch.com superpamperedpooch.com ns2.littlepamperedpooch.com littlepamperedpooch.com ns2.pamperedpethaven.com pamperedpethaven.com ns2.pamperedpetbeds.com pamperedpetbeds.com ns2.pamperedpoochpatrol.com pamperedpoochpatrol.com ns2.pamperedpetinc.com pamperedpetinc.com ns2.pamperedpetmotel.com pamperedpetmotel.com ns2.yourpetexpo.com yourpetexpo.com ns2.pamperedpethouse.com pamperedpethouse.com ns2.thepetbond.com thepetbond.com ns2.pamperedpethomes.com pamperedpethomes.com ns2.pamperedanimal.com pamperedanimal.com ns2.thewelfarefund.com thewelfarefund.com ns2.pamperedbellapooch.com pamperedbellapooch.com ns2.animalwelfarejournal.com animalwelfarejournal.com ns2.pamperedpetllc.com pamperedpetllc.com ns2.animalwelfarealliance.com animalwelfarealliance.com ns2.pamperedpoochworld.com pamperedpoochworld.com ns2.richwelfare.com richwelfare.com ns2.thespoiledspouse.com thespoiledspouse.com ns2.spoileddoggies.com spoileddoggies.com ns2.companionbailout.com companionbailout.com ns2.poochproductsguide.com poochproductsguide.com ns2.poochadvocate.com poochadvocate.com ns2.socialwelfaretrust.com socialwelfaretrust.com ns2.prosperouswelfare.com prosperouswelfare.com ns2.childwelfarereview.com childwelfarereview.com ns2.wjhoreni.com wjhoreni.com 198.151.138.3 ns2.pressedflowerarrangement.com pressedflowerarrangement.com ns2.pressedflowerdelivery.com pressedflowerdelivery.com ns2.pressedflowerplants.com pressedflowerplants.com ns2.pressedflowercard.com pressedflowercard.com ns2.pressedflowernames.com pressedflowernames.com ns2.pressedflowergirl.com pressedflowergirl.com ns2.pressedflowerimages.com pressedflowerimages.com ns2.pressedflowerfields.com pressedflowerfields.com ns2.pressedflowerstore.com pressedflowerstore.com ns2.pressedflowercolor.com pressedflowercolor.com ns2.pressedflowerguide.com pressedflowerguide.com ns2.coldpressedflower.com coldpressedflower.com ns2.pressedflowerlady.com pressedflowerlady.com ns2.pressedflowerfarm.com pressedflowerfarm.com ns2.pressedflowergift.com pressedflowergift.com ns2.pressedflowertips.com pressedflowertips.com ns2.pressedfloweraffair.com pressedfloweraffair.com ns2.pressedflowergifts.com pressedflowergifts.com ns2.pressedflowerseed.com pressedflowerseed.com ns2.pressedflowerphotos.com pressedflowerphotos.com ns2.pressedflowercolors.com pressedflowercolors.com ns2.pressedflowerseeds.com pressedflowerseeds.com ns2.pressedflowerbeds.com pressedflowerbeds.com ns2.pressedflowerbasket.com pressedflowerbasket.com ns2.pressedflowershops.com pressedflowershops.com ns2.pressedtreeseeds.com pressedtreeseeds.com ns2.pressedtreeleaf.com pressedtreeleaf.com ns2.pressedtreedoctor.com pressedtreedoctor.com ns2.pressedtreebranch.com pressedtreebranch.com ns2.pressedtreephotos.com pressedtreephotos.com ns2.pressedtreewounds.com pressedtreewounds.com ns2.pressedtreeimages.com pressedtreeimages.com ns2.pressedtreeexperts.com pressedtreeexperts.com ns2.pressedtreebranches.com pressedtreebranches.com ns2.coldpressedtree.com coldpressedtree.com ns2.pressedtreefarms.com pressedtreefarms.com ns2.pressedtreeroots.com pressedtreeroots.com ns2.pressedtreeremoval.com pressedtreeremoval.com ns2.pressedtreespecies.com pressedtreespecies.com ns2.pressedtreefarm.com pressedtreefarm.com ns2.pressedtreeplanting.com pressedtreeplanting.com ns2.pressedtree.com pressedtree.com ns2.pressedflowerdatabase.com pressedflowerdatabase.com ns2.pressedflowerdistrict.com pressedflowerdistrict.com ns2.pressedflowerexperts.com pressedflowerexperts.com ns2.pressedflowerkingdom.com pressedflowerkingdom.com ns2.pressedflowerphotography.com pressedflowerphotography.com ns2.pressedflowercottage.com pressedflowercottage.com ns2.pressedflowerdirectory.com pressedflowerdirectory.com ns2.pressedflowerarrangements.com pressedflowerarrangements.com 198.151.138.5 ns1.winterclassicsteamclean.com winterclassicsteamclean.com ns2.winterclassicsteamclean.com winterclassicsteamclean.com ns1.typicalvaporclean.com typicalvaporclean.com ns2.typicalvaporclean.com typicalvaporclean.com ns1.typicalsteamwash.com typicalsteamwash.com ns2.typicalsteamwash.com typicalsteamwash.com ns1.typicalsteampure.com typicalsteampure.com ns2.typicalsteampure.com typicalsteampure.com ns1.typicalsteamfresh.com typicalsteamfresh.com ns2.typicalsteamfresh.com typicalsteamfresh.com ns1.typicalsteamclear.com typicalsteamclear.com ns2.typicalsteamclear.com typicalsteamclear.com ns1.typicalsteamcleansolutions.com typicalsteamcleansolutions.com ns2.typicalsteamcleansolutions.com typicalsteamcleansolutions.com ns1.typicalsteamclean.com typicalsteamclean.com ns2.typicalsteamclean.com typicalsteamclean.com ns1.typicalmistclean.com typicalmistclean.com ns2.typicalmistclean.com typicalmistclean.com ns1.typicalhazeclean.com typicalhazeclean.com ns2.typicalhazeclean.com typicalhazeclean.com ns1.typicalgasreservesfresh.com typicalgasreservesfresh.com ns2.typicalgasreservesfresh.com typicalgasreservesfresh.com ns1.typicalgasreservesclean.com typicalgasreservesclean.com ns2.typicalgasreservesclean.com typicalgasreservesclean.com ns1.typicalgasclean.com typicalgasclean.com ns2.typicalgasclean.com typicalgasclean.com ns1.typicalfogclean.com typicalfogclean.com ns2.typicalfogclean.com typicalfogclean.com ns1.typicalcloudclean.com typicalcloudclean.com ns2.typicalcloudclean.com typicalcloudclean.com ns1.twinprimesteamclear.com twinprimesteamclear.com ns2.twinprimesteamclear.com twinprimesteamclear.com ns1.twinprimesteamclean.com twinprimesteamclean.com ns2.twinprimesteamclean.com twinprimesteamclean.com ns1.superiorvaporclean.com superiorvaporclean.com ns2.superiorvaporclean.com superiorvaporclean.com ns1.superiorsteamwash.com superiorsteamwash.com ns2.superiorsteamwash.com superiorsteamwash.com ns1.superiorsteampure.com superiorsteampure.com ns2.superiorsteampure.com superiorsteampure.com ns1.superiorsteamfresh.com superiorsteamfresh.com ns2.superiorsteamfresh.com superiorsteamfresh.com ns1.superiorsteamclear.com superiorsteamclear.com ns2.superiorsteamclear.com superiorsteamclear.com ns1.superiorsteamcleansolutions.com superiorsteamcleansolutions.com ns2.superiorsteamcleansolutions.com superiorsteamcleansolutions.com ns1.superiormistclean.com superiormistclean.com ns2.superiormistclean.com superiormistclean.com ns1.superiorhazeclean.com superiorhazeclean.com ns2.superiorhazeclean.com superiorhazeclean.com ns1.superiorgasreservesfresh.com superiorgasreservesfresh.com ns2.superiorgasreservesfresh.com superiorgasreservesfresh.com ns1.superiorgasreservesclean.com superiorgasreservesclean.com ns2.superiorgasreservesclean.com superiorgasreservesclean.com ns1.superiorgasclean.com superiorgasclean.com ns2.superiorgasclean.com superiorgasclean.com ns1.superiorfogclean.com superiorfogclean.com ns2.superiorfogclean.com superiorfogclean.com ns1.superiorcloudclean.com superiorcloudclean.com ns2.superiorcloudclean.com superiorcloudclean.com ns1.standardvaporclean.com standardvaporclean.com ns2.standardvaporclean.com standardvaporclean.com ns1.standardsteamwash.com standardsteamwash.com ns2.standardsteamwash.com standardsteamwash.com ns1.standardsteampure.com standardsteampure.com ns2.standardsteampure.com standardsteampure.com ns1.standardsteamfresh.com standardsteamfresh.com ns2.standardsteamfresh.com standardsteamfresh.com ns1.standardsteamclear.com standardsteamclear.com ns2.standardsteamclear.com standardsteamclear.com ns1.standardsteamcleansolutions.com standardsteamcleansolutions.com ns2.standardsteamcleansolutions.com standardsteamcleansolutions.com ns1.standardsteamclean.com standardsteamclean.com ns2.standardsteamclean.com standardsteamclean.com ns1.standardmistclean.com standardmistclean.com ns2.standardmistclean.com standardmistclean.com ns1.standardhazeclean.com standardhazeclean.com ns2.standardhazeclean.com standardhazeclean.com ns1.standardgasclean.com standardgasclean.com ns2.standardgasclean.com standardgasclean.com ns1.standardfogclean.com standardfogclean.com ns2.standardfogclean.com standardfogclean.com ns1.standardcloudclean.com standardcloudclean.com ns2.standardcloudclean.com standardcloudclean.com ns1.primevaporclean.com primevaporclean.com ns2.primevaporclean.com primevaporclean.com ns1.primesteamwash.com primesteamwash.com ns2.primesteamwash.com primesteamwash.com ns1.primesteamtrappure.com primesteamtrappure.com ns2.primesteamtrappure.com primesteamtrappure.com ns1.primesteamtrapfresh.com primesteamtrapfresh.com ns2.primesteamtrapfresh.com primesteamtrapfresh.com ns1.primesteamtrapclear.com primesteamtrapclear.com ns2.primesteamtrapclear.com primesteamtrapclear.com ns1.primesteamtrapclean.com primesteamtrapclean.com ns2.primesteamtrapclean.com primesteamtrapclean.com ns1.primesteamtrainpure.com primesteamtrainpure.com ns2.primesteamtrainpure.com primesteamtrainpure.com ns1.primesteamroomspure.com primesteamroomspure.com ns2.primesteamroomspure.com primesteamroomspure.com ns1.primesteamrallypure.com primesteamrallypure.com ns2.primesteamrallypure.com primesteamrallypure.com ns1.primesteampurecolor.com primesteampurecolor.com ns2.primesteampurecolor.com primesteampurecolor.com ns1.primesteampure.com primesteampure.com ns2.primesteampure.com primesteampure.com ns1.primesteampipepure.com primesteampipepure.com ns2.primesteampipepure.com primesteampipepure.com ns1.primesteampipefresh.com primesteampipefresh.com ns2.primesteampipefresh.com primesteampipefresh.com ns1.primesteampipeclear.com primesteampipeclear.com ns2.primesteampipeclear.com primesteampipeclear.com ns1.primesteampipeclean.com primesteampipeclean.com ns2.primesteampipeclean.com primesteampipeclean.com ns1.primesteamironpure.com primesteamironpure.com ns2.primesteamironpure.com primesteamironpure.com ns1.primesteamironfresh.com primesteamironfresh.com ns2.primesteamironfresh.com primesteamironfresh.com ns1.primesteamironclear.com primesteamironclear.com ns2.primesteamironclear.com primesteamironclear.com ns1.primesteamironclean.com primesteamironclean.com ns2.primesteamironclean.com primesteamironclean.com ns1.primesteamheatpure.com primesteamheatpure.com ns2.primesteamheatpure.com primesteamheatpure.com ns1.primesteamheatfresh.com primesteamheatfresh.com ns2.primesteamheatfresh.com primesteamheatfresh.com ns1.primesteamheatclear.com primesteamheatclear.com ns2.primesteamheatclear.com primesteamheatclear.com ns1.primesteamheatclean.com primesteamheatclean.com ns2.primesteamheatclean.com primesteamheatclean.com ns1.primesteamfreshmeat.com primesteamfreshmeat.com ns2.primesteamfreshmeat.com primesteamfreshmeat.com ns1.primesteamfreshfish.com primesteamfreshfish.com ns2.primesteamfreshfish.com primesteamfreshfish.com ns1.primesteamfresh.com primesteamfresh.com ns2.primesteamfresh.com primesteamfresh.com ns1.primesteamforumpure.com primesteamforumpure.com ns2.primesteamforumpure.com primesteamforumpure.com ns1.primesteamcloudpure.com primesteamcloudpure.com ns2.primesteamcloudpure.com primesteamcloudpure.com ns1.primesteamclearlake.com primesteamclearlake.com ns2.primesteamclearlake.com primesteamclearlake.com ns1.primesteamclearblue.com primesteamclearblue.com ns2.primesteamclearblue.com primesteamclearblue.com ns1.primesteamclear.com primesteamclear.com ns2.primesteamclear.com primesteamclear.com ns1.primesteamcleansolutions.com primesteamcleansolutions.com ns2.primesteamcleansolutions.com primesteamcleansolutions.com ns1.primesteamcleanpure.com primesteamcleanpure.com ns2.primesteamcleanpure.com primesteamcleanpure.com ns1.primesteamclean.com primesteamclean.com ns2.primesteamclean.com primesteamclean.com ns1.primesteamchestpure.com primesteamchestpure.com ns2.primesteamchestpure.com primesteamchestpure.com ns1.primesteamcarsfresh.com primesteamcarsfresh.com ns2.primesteamcarsfresh.com primesteamcarsfresh.com ns1.primesteamcarsclear.com primesteamcarsclear.com ns2.primesteamcarsclear.com primesteamcarsclear.com ns1.primesteamcarsclean.com primesteamcarsclean.com ns2.primesteamcarsclean.com primesteamcarsclean.com ns1.primesteamboatspure.com primesteamboatspure.com ns2.primesteamboatspure.com primesteamboatspure.com ns1.primesteamboatpure.com primesteamboatpure.com ns2.primesteamboatpure.com primesteamboatpure.com ns1.primesteamboatfresh.com primesteamboatfresh.com ns2.primesteamboatfresh.com primesteamboatfresh.com ns1.primesteamboatclear.com primesteamboatclear.com ns2.primesteamboatclear.com primesteamboatclear.com ns1.primesteamboatclean.com primesteamboatclean.com ns2.primesteamboatclean.com primesteamboatclean.com ns1.primesteambathpure.com primesteambathpure.com ns2.primesteambathpure.com primesteambathpure.com ns1.primesteambathfresh.com primesteambathfresh.com ns2.primesteambathfresh.com primesteambathfresh.com ns1.primesteambathclear.com primesteambathclear.com ns2.primesteambathclear.com primesteambathclear.com ns1.primesteambathclean.com primesteambathclean.com ns2.primesteambathclean.com primesteambathclean.com ns1.primesteamautowash.com primesteamautowash.com ns2.primesteamautowash.com primesteamautowash.com ns1.primemistclean.com primemistclean.com ns2.primemistclean.com primemistclean.com ns1.primehazeclean.com primehazeclean.com ns2.primehazeclean.com primehazeclean.com ns1.primegasclean.com primegasclean.com ns2.primegasclean.com primegasclean.com ns1.modelsteampurecolor.com modelsteampurecolor.com ns2.modelsteampurecolor.com modelsteampurecolor.com ns1.primefogclean.com primefogclean.com ns2.primefogclean.com primefogclean.com ns1.primefloorsteampure.com primefloorsteampure.com ns2.primefloorsteampure.com primefloorsteampure.com ns1.primefloorsteamfresh.com primefloorsteamfresh.com ns2.primefloorsteamfresh.com primefloorsteamfresh.com ns1.primefloorsteamclear.com primefloorsteamclear.com ns2.primefloorsteamclear.com primefloorsteamclear.com ns1.primeflashsteampure.com primeflashsteampure.com ns2.primeflashsteampure.com primeflashsteampure.com ns1.primecloudclean.com primecloudclean.com ns2.primecloudclean.com primecloudclean.com ns1.motorclassicfogpure.com motorclassicfogpure.com ns2.motorclassicfogpure.com motorclassicfogpure.com ns1.modelvaporclean.com modelvaporclean.com ns2.modelvaporclean.com modelvaporclean.com ns1.modelsteamwash.com modelsteamwash.com ns2.modelsteamwash.com modelsteamwash.com ns1.modelsteamtrainpure.com modelsteamtrainpure.com ns2.modelsteamtrainpure.com modelsteamtrainpure.com ns1.modelsteampurestyle.com modelsteampurestyle.com ns2.modelsteampurestyle.com modelsteampurestyle.com ns1.modelsteampure.com modelsteampure.com ns2.modelsteampure.com modelsteampure.com ns1.modelsteamfreshmeat.com modelsteamfreshmeat.com ns2.modelsteamfreshmeat.com modelsteamfreshmeat.com ns1.modelsteamfreshfish.com modelsteamfreshfish.com ns2.modelsteamfreshfish.com modelsteamfreshfish.com ns1.modelsteamfresh.com modelsteamfresh.com ns2.modelsteamfresh.com modelsteamfresh.com ns1.modelsteamclearlake.com modelsteamclearlake.com ns2.modelsteamclearlake.com modelsteamclearlake.com ns1.modelsteamclearblue.com modelsteamclearblue.com ns2.modelsteamclearblue.com modelsteamclearblue.com ns1.modelsteamclear.com modelsteamclear.com ns2.modelsteamclear.com modelsteamclear.com ns1.modelsteamcleansolutions.com modelsteamcleansolutions.com ns2.modelsteamcleansolutions.com modelsteamcleansolutions.com ns1.modelsteamclean.com modelsteamclean.com ns2.modelsteamclean.com modelsteamclean.com ns1.modelsteamautowash.com modelsteamautowash.com ns2.modelsteamautowash.com modelsteamautowash.com ns1.modelscalesteampure.com modelscalesteampure.com ns2.modelscalesteampure.com modelscalesteampure.com ns1.modelmistclean.com modelmistclean.com ns2.modelmistclean.com modelmistclean.com ns1.modelhazeclean.com modelhazeclean.com ns2.modelhazeclean.com modelhazeclean.com ns1.modelgasclean.com modelgasclean.com ns2.modelgasclean.com modelgasclean.com ns1.modelfogclean.com modelfogclean.com ns2.modelfogclean.com modelfogclean.com ns1.modelfloorsteampure.com modelfloorsteampure.com ns2.modelfloorsteampure.com modelfloorsteampure.com ns1.modelflashsteampure.com modelflashsteampure.com ns2.modelflashsteampure.com modelflashsteampure.com ns1.modelcloudclean.com modelcloudclean.com ns2.modelcloudclean.com modelcloudclean.com ns1.golfclassicmistwash.com golfclassicmistwash.com ns2.golfclassicmistwash.com golfclassicmistwash.com ns1.golfclassicmistpure.com golfclassicmistpure.com ns2.golfclassicmistpure.com golfclassicmistpure.com ns1.golfclassichazewash.com golfclassichazewash.com ns2.golfclassichazewash.com golfclassichazewash.com ns1.golfclassichazepure.com golfclassichazepure.com ns2.golfclassichazepure.com golfclassichazepure.com ns1.golfclassicgasfresh.com golfclassicgasfresh.com ns2.golfclassicgasfresh.com golfclassicgasfresh.com ns1.golfclassicgasclear.com golfclassicgasclear.com ns2.golfclassicgasclear.com golfclassicgasclear.com ns1.golfclassicgasclean.com golfclassicgasclean.com ns2.golfclassicgasclean.com golfclassicgasclean.com ns1.golfclassicfogpure.com golfclassicfogpure.com ns2.golfclassicfogpure.com golfclassicfogpure.com ns1.golfclassicfogfresh.com golfclassicfogfresh.com ns2.golfclassicfogfresh.com golfclassicfogfresh.com ns1.golfclassicfogclear.com golfclassicfogclear.com ns2.golfclassicfogclear.com golfclassicfogclear.com ns1.golfclassicfogclean.com golfclassicfogclean.com ns2.golfclassicfogclean.com golfclassicfogclean.com ns1.excellentvaporclean.com excellentvaporclean.com ns2.excellentvaporclean.com excellentvaporclean.com ns1.excellentsteamwash.com excellentsteamwash.com ns2.excellentsteamwash.com excellentsteamwash.com ns1.excellentsteampure.com excellentsteampure.com ns2.excellentsteampure.com excellentsteampure.com ns1.excellentsteamfresh.com excellentsteamfresh.com ns2.excellentsteamfresh.com excellentsteamfresh.com ns1.excellentsteamclear.com excellentsteamclear.com ns2.excellentsteamclear.com excellentsteamclear.com ns1.excellentsteamcleansolutions.com excellentsteamcleansolutions.com ns2.excellentsteamcleansolutions.com excellentsteamcleansolutions.com ns1.excellentsteamclean.com excellentsteamclean.com ns2.excellentsteamclean.com excellentsteamclean.com ns1.excellentmistclean.com excellentmistclean.com ns2.excellentmistclean.com excellentmistclean.com ns1.excellenthazeclean.com excellenthazeclean.com ns2.excellenthazeclean.com excellenthazeclean.com ns1.excellentgasclean.com excellentgasclean.com ns2.excellentgasclean.com excellentgasclean.com ns1.excellentfogclean.com excellentfogclean.com ns2.excellentfogclean.com excellentfogclean.com ns1.excellentcloudclean.com excellentcloudclean.com ns2.excellentcloudclean.com excellentcloudclean.com ns1.colorclassicfogpure.com colorclassicfogpure.com ns2.colorclassicfogpure.com colorclassicfogpure.com ns1.classicwarmmistwash.com classicwarmmistwash.com ns2.classicwarmmistwash.com classicwarmmistwash.com ns1.classicwarmmistpure.com classicwarmmistpure.com ns2.classicwarmmistpure.com classicwarmmistpure.com ns1.classicvaporwash.com classicvaporwash.com ns2.classicvaporwash.com classicvaporwash.com ns1.classicvaporpure.com classicvaporpure.com ns2.classicvaporpure.com classicvaporpure.com ns1.classicvaporfresh.com classicvaporfresh.com ns2.classicvaporfresh.com classicvaporfresh.com ns1.classicvaporclear.com classicvaporclear.com ns2.classicvaporclear.com classicvaporclear.com ns1.classicvaporclean.com classicvaporclean.com ns2.classicvaporclean.com classicvaporclean.com ns1.classicthinfogpure.com classicthinfogpure.com ns2.classicthinfogpure.com classicthinfogpure.com ns1.classicthinfogfresh.com classicthinfogfresh.com ns2.classicthinfogfresh.com classicthinfogfresh.com ns1.classicthinfogclear.com classicthinfogclear.com ns2.classicthinfogclear.com classicthinfogclear.com ns1.classicthinfogclean.com classicthinfogclean.com ns2.classicthinfogclean.com classicthinfogclean.com ns1.classicsteamwash.com classicsteamwash.com ns2.classicsteamwash.com classicsteamwash.com ns1.classicsteampure.com classicsteampure.com ns2.classicsteampure.com classicsteampure.com ns1.classicsteamplantsclean.com classicsteamplantsclean.com ns2.classicsteamplantsclean.com classicsteamplantsclean.com ns1.classicsteamoutputclean.com classicsteamoutputclean.com ns2.classicsteamoutputclean.com classicsteamoutputclean.com ns1.classicsteamlaunchclean.com classicsteamlaunchclean.com ns2.classicsteamlaunchclean.com classicsteamlaunchclean.com ns1.classicsteamgenerationclean.com classicsteamgenerationclean.com ns2.classicsteamgenerationclean.com classicsteamgenerationclean.com ns1.classicsteamgreenclean.com classicsteamgreenclean.com ns2.classicsteamgreenclean.com classicsteamgreenclean.com ns1.classicsteamfresh.com classicsteamfresh.com ns2.classicsteamfresh.com classicsteamfresh.com ns1.classicsteamfogwash.com classicsteamfogwash.com ns2.classicsteamfogwash.com classicsteamfogwash.com ns1.classicsteamfogpure.com classicsteamfogpure.com ns2.classicsteamfogpure.com classicsteamfogpure.com ns1.classicsteamdistributionclean.com classicsteamdistributionclean.com ns2.classicsteamdistributionclean.com classicsteamdistributionclean.com ns1.classicsteamclientclean.com classicsteamclientclean.com ns2.classicsteamclientclean.com classicsteamclientclean.com ns1.classicsteamclear.com classicsteamclear.com ns2.classicsteamclear.com classicsteamclear.com ns1.classicsteamcarsclean.com classicsteamcarsclean.com ns2.classicsteamcarsclean.com classicsteamcarsclean.com ns1.classicpuremistwash.com classicpuremistwash.com ns2.classicpuremistwash.com classicpuremistwash.com ns1.classicsmellgaspure.com classicsmellgaspure.com ns2.classicsmellgaspure.com classicsmellgaspure.com ns1.classicohiogaspure.com classicohiogaspure.com ns2.classicohiogaspure.com classicohiogaspure.com ns1.classicmistwash.com classicmistwash.com ns2.classicmistwash.com classicmistwash.com ns1.classicmistpure.com classicmistpure.com ns2.classicmistpure.com classicmistpure.com ns1.classicmistfresh.com classicmistfresh.com ns2.classicmistfresh.com classicmistfresh.com ns1.classicmistfanswash.com classicmistfanswash.com ns2.classicmistfanswash.com classicmistfanswash.com ns1.classicmistfanspure.com classicmistfanspure.com ns2.classicmistfanspure.com classicmistfanspure.com ns1.classicmistclear.com classicmistclear.com ns2.classicmistclear.com classicmistclear.com ns1.classicmistclean.com classicmistclean.com ns2.classicmistclean.com classicmistclean.com ns1.classicidealgaspure.com classicidealgaspure.com ns2.classicidealgaspure.com classicidealgaspure.com ns1.classicheathazewash.com classicheathazewash.com ns2.classicheathazewash.com classicheathazewash.com ns1.classicheathazepure.com classicheathazepure.com ns2.classicheathazepure.com classicheathazepure.com ns1.classichazewash.com classichazewash.com ns2.classichazewash.com classichazewash.com ns1.classichazepure.com classichazepure.com ns2.classichazepure.com classichazepure.com ns1.classichazegraywash.com classichazegraywash.com ns2.classichazegraywash.com classichazegraywash.com ns1.classichazegraypure.com classichazegraypure.com ns2.classichazegraypure.com classichazegraypure.com ns1.classichazefresh.com classichazefresh.com ns2.classichazefresh.com classichazefresh.com ns1.classichazeclear.com classichazeclear.com ns2.classichazeclear.com classichazeclear.com ns1.classichazeclean.com classichazeclean.com ns2.classichazeclean.com classichazeclean.com ns1.classicgaswash.com classicgaswash.com ns2.classicgaswash.com classicgaswash.com ns1.classicgastankfresh.com classicgastankfresh.com ns2.classicgastankfresh.com classicgastankfresh.com ns1.classicgastankclear.com classicgastankclear.com ns2.classicgastankclear.com classicgastankclear.com ns1.classicgastankclean.com classicgastankclean.com ns2.classicgastankclean.com classicgastankclean.com ns1.classicgasreservesfresh.com classicgasreservesfresh.com ns2.classicgasreservesfresh.com classicgasreservesfresh.com ns1.classicgasreservesclean.com classicgasreservesclean.com ns2.classicgasreservesclean.com classicgasreservesclean.com ns1.classicgaspurestyle.com classicgaspurestyle.com ns2.classicgaspurestyle.com classicgaspurestyle.com ns1.classicgaspurecolor.com classicgaspurecolor.com ns2.classicgaspurecolor.com classicgaspurecolor.com ns1.classicgaspure.com classicgaspure.com ns2.classicgaspure.com classicgaspure.com ns1.classicgaspumpfresh.com classicgaspumpfresh.com ns2.classicgaspumpfresh.com classicgaspumpfresh.com ns1.classicgaspumpclear.com classicgaspumpclear.com ns2.classicgaspumpclear.com classicgaspumpclear.com ns1.classicgaspumpclean.com classicgaspumpclean.com ns2.classicgaspumpclean.com classicgaspumpclean.com ns1.classicgaspipefresh.com classicgaspipefresh.com ns2.classicgaspipefresh.com classicgaspipefresh.com ns1.classicgaspipeclear.com classicgaspipeclear.com ns2.classicgaspipeclear.com classicgaspipeclear.com ns1.classicgaspipeclean.com classicgaspipeclean.com ns2.classicgaspipeclean.com classicgaspipeclean.com ns1.classicgaspainfresh.com classicgaspainfresh.com ns2.classicgaspainfresh.com classicgaspainfresh.com ns1.classicgaspainclear.com classicgaspainclear.com ns2.classicgaspainclear.com classicgaspainclear.com ns1.classicgaspainclean.com classicgaspainclean.com ns2.classicgaspainclean.com classicgaspainclean.com ns1.classicgasheatfresh.com classicgasheatfresh.com ns2.classicgasheatfresh.com classicgasheatfresh.com ns1.classicgasheatclear.com classicgasheatclear.com ns2.classicgasheatclear.com classicgasheatclear.com ns1.classicgasheatclean.com classicgasheatclean.com ns2.classicgasheatclean.com classicgasheatclean.com ns1.classicgasgridfresh.com classicgasgridfresh.com ns2.classicgasgridfresh.com classicgasgridfresh.com ns1.classicgasgridclear.com classicgasgridclear.com ns2.classicgasgridclear.com classicgasgridclear.com ns1.classicgasgridclean.com classicgasgridclean.com ns2.classicgasgridclean.com classicgasgridclean.com ns1.classicgasfresh.com classicgasfresh.com ns2.classicgasfresh.com classicgasfresh.com ns1.classicgasclear.com classicgasclear.com ns2.classicgasclear.com classicgasclear.com ns1.classicgasclean.com classicgasclean.com ns2.classicgasclean.com classicgasclean.com ns1.classicfuelgaspure.com classicfuelgaspure.com ns2.classicfuelgaspure.com classicfuelgaspure.com ns1.classicfogwash.com classicfogwash.com ns2.classicfogwash.com classicfogwash.com ns1.classicfogsealwash.com classicfogsealwash.com ns2.classicfogsealwash.com classicfogsealwash.com ns1.classicfogsealpure.com classicfogsealpure.com ns2.classicfogsealpure.com classicfogsealpure.com ns1.classicfogsealfresh.com classicfogsealfresh.com ns2.classicfogsealfresh.com classicfogsealfresh.com ns1.classicfogsealclear.com classicfogsealclear.com ns2.classicfogsealclear.com classicfogsealclear.com ns1.classicfogsealclean.com classicfogsealclean.com ns2.classicfogsealclean.com classicfogsealclean.com ns1.classicfogpurecolor.com classicfogpurecolor.com ns2.classicfogpurecolor.com classicfogpurecolor.com ns1.classicfogpure.com classicfogpure.com ns2.classicfogpure.com classicfogpure.com ns1.classicfoglayerwash.com classicfoglayerwash.com ns2.classicfoglayerwash.com classicfoglayerwash.com ns1.classicfoglayerpure.com classicfoglayerpure.com ns2.classicfoglayerpure.com classicfoglayerpure.com ns1.classicfogjuicewash.com classicfogjuicewash.com ns2.classicfogjuicewash.com classicfogjuicewash.com ns1.classicfoginfowash.com classicfoginfowash.com ns2.classicfoginfowash.com classicfoginfowash.com ns1.classicfoginfopure.com classicfoginfopure.com ns2.classicfoginfopure.com classicfoginfopure.com ns1.classicfoginfofresh.com classicfoginfofresh.com ns2.classicfoginfofresh.com classicfoginfofresh.com ns1.classicfoginfoclean.com classicfoginfoclean.com ns2.classicfoginfoclean.com classicfoginfoclean.com ns1.classicfogfreshmeat.com classicfogfreshmeat.com ns2.classicfogfreshmeat.com classicfogfreshmeat.com ns1.classicfogfreshfish.com classicfogfreshfish.com ns2.classicfogfreshfish.com classicfogfreshfish.com ns1.classicfogfresh.com classicfogfresh.com ns2.classicfogfresh.com classicfogfresh.com ns1.classicfogfluidwash.com classicfogfluidwash.com ns2.classicfogfluidwash.com classicfogfluidwash.com ns1.classicfogfluidpure.com classicfogfluidpure.com ns2.classicfogfluidpure.com classicfogfluidpure.com ns1.classicfogcolorpure.com classicfogcolorpure.com ns2.classicfogcolorpure.com classicfogcolorpure.com ns1.classicfogjuicepure.com classicfogjuicepure.com ns2.classicfogjuicepure.com classicfogjuicepure.com ns1.classicfoginfoclear.com classicfoginfoclear.com ns2.classicfoginfoclear.com classicfoginfoclear.com ns1.classicfogcoatwash.com classicfogcoatwash.com ns2.classicfogcoatwash.com classicfogcoatwash.com ns1.classicfogcoatpure.com classicfogcoatpure.com ns2.classicfogcoatpure.com classicfogcoatpure.com ns1.classicfogcoatfresh.com classicfogcoatfresh.com ns2.classicfogcoatfresh.com classicfogcoatfresh.com ns1.classicfogcoatclear.com classicfogcoatclear.com ns2.classicfogcoatclear.com classicfogcoatclear.com ns1.classicfogcoatclean.com classicfogcoatclean.com ns2.classicfogcoatclean.com classicfogcoatclean.com ns1.classicfogcloudwash.com classicfogcloudwash.com ns2.classicfogcloudwash.com classicfogcloudwash.com ns1.classicfogcloudpure.com classicfogcloudpure.com ns2.classicfogcloudpure.com classicfogcloudpure.com ns1.classicfogclearlake.com classicfogclearlake.com ns2.classicfogclearlake.com classicfogclearlake.com ns1.classicfogclearblue.com classicfogclearblue.com ns2.classicfogclearblue.com classicfogclearblue.com ns1.classicfogclear.com classicfogclear.com ns2.classicfogclear.com classicfogclear.com ns1.classicfogcleantech.com classicfogcleantech.com ns2.classicfogcleantech.com classicfogcleantech.com ns1.classicfogcleanfuel.com classicfogcleanfuel.com ns2.classicfogcleanfuel.com classicfogcleanfuel.com ns1.classicfogcleancoal.com classicfogcleancoal.com ns2.classicfogcleancoal.com classicfogcleancoal.com ns1.classicfogcleancars.com classicfogcleancars.com ns2.classicfogcleancars.com classicfogcleancars.com ns1.classicfogclean.com classicfogclean.com ns2.classicfogclean.com classicfogclean.com ns1.classicfogbellwash.com classicfogbellwash.com ns2.classicfogbellwash.com classicfogbellwash.com ns1.classicfogbellpure.com classicfogbellpure.com ns2.classicfogbellpure.com classicfogbellpure.com ns1.classicfogbellfresh.com classicfogbellfresh.com ns2.classicfogbellfresh.com classicfogbellfresh.com ns1.classicfogbellclear.com classicfogbellclear.com ns2.classicfogbellclear.com classicfogbellclear.com ns1.classicfogbellclean.com classicfogbellclean.com ns2.classicfogbellclean.com classicfogbellclean.com ns1.classicerichazewash.com classicerichazewash.com ns2.classicerichazewash.com classicerichazewash.com ns1.classicerichazepure.com classicerichazepure.com ns2.classicerichazepure.com classicerichazepure.com ns1.classiccoolmistwash.com classiccoolmistwash.com ns2.classiccoolmistwash.com classiccoolmistwash.com ns1.classiccoolmistpure.com classiccoolmistpure.com ns2.classiccoolmistpure.com classiccoolmistpure.com ns1.classiccloudwash.com classiccloudwash.com ns2.classiccloudwash.com classiccloudwash.com ns1.classiccloudpure.com classiccloudpure.com ns2.classiccloudpure.com classiccloudpure.com ns1.classiccloudfresh.com classiccloudfresh.com ns2.classiccloudfresh.com classiccloudfresh.com ns1.classiccloudclear.com classiccloudclear.com ns2.classiccloudclear.com classiccloudclear.com ns1.classiccloudclean.com classiccloudclean.com ns2.classiccloudclean.com classiccloudclean.com ns1.classiccheapgaspure.com classiccheapgaspure.com ns2.classiccheapgaspure.com classiccheapgaspure.com ns1.classiccapehazewash.com classiccapehazewash.com ns2.classiccapehazewash.com classiccapehazewash.com ns1.classiccapehazepure.com classiccapehazepure.com ns2.classiccapehazepure.com classiccapehazepure.com ns1.classicbrainfogpure.com classicbrainfogpure.com ns2.classicbrainfogpure.com classicbrainfogpure.com ns1.classicbluemistpure.com classicbluemistpure.com ns2.classicbluemistpure.com classicbluemistpure.com ns1.classicbluehazewash.com classicbluehazewash.com ns2.classicbluehazewash.com classicbluehazewash.com ns1.classicbluehazepure.com classicbluehazepure.com ns2.classicbluehazepure.com classicbluehazepure.com ns1.classicacidgaspure.com classicacidgaspure.com ns2.classicacidgaspure.com classicacidgaspure.com ns1.classicacidfogwash.com classicacidfogwash.com ns2.classicacidfogwash.com classicacidfogwash.com ns1.classicacidfogpure.com classicacidfogpure.com ns2.classicacidfogpure.com classicacidfogpure.com ns1.classicacidfogfresh.com classicacidfogfresh.com ns2.classicacidfogfresh.com classicacidfogfresh.com ns1.classicacidfogclear.com classicacidfogclear.com ns2.classicacidfogclear.com classicacidfogclear.com ns1.classicacidfogclean.com classicacidfogclean.com ns2.classicacidfogclean.com classicacidfogclean.com ns1.soccerclassicsteamclean.com soccerclassicsteamclean.com ns2.soccerclassicsteamclean.com soccerclassicsteamclean.com ns1.motorclassicsteamclean.com motorclassicsteamclean.com ns2.motorclassicsteamclean.com motorclassicsteamclean.com ns1.golfclassicsteamclean.com golfclassicsteamclean.com ns2.golfclassicsteamclean.com golfclassicsteamclean.com ns1.colorclassicsteamclean.com colorclassicsteamclean.com ns2.colorclassicsteamclean.com colorclassicsteamclean.com ns1.classicsteamtrapclean.com classicsteamtrapclean.com ns2.classicsteamtrapclean.com classicsteamtrapclean.com ns1.classicsteamtrainsclean.com classicsteamtrainsclean.com ns2.classicsteamtrainsclean.com classicsteamtrainsclean.com ns1.classicsteamtrainclean.com classicsteamtrainclean.com ns2.classicsteamtrainclean.com classicsteamtrainclean.com ns1.classicsteamtablesclean.com classicsteamtablesclean.com ns2.classicsteamtablesclean.com classicsteamtablesclean.com ns1.classicsteamshowerclean.com classicsteamshowerclean.com ns2.classicsteamshowerclean.com classicsteamshowerclean.com ns1.classicsteamroomsclean.com classicsteamroomsclean.com ns2.classicsteamroomsclean.com classicsteamroomsclean.com ns1.classicsteamrallyclean.com classicsteamrallyclean.com ns2.classicsteamrallyclean.com classicsteamrallyclean.com ns1.classicsteamrailwayclean.com classicsteamrailwayclean.com ns2.classicsteamrailwayclean.com classicsteamrailwayclean.com ns1.classicsteampoweredclean.com classicsteampoweredclean.com ns2.classicsteampoweredclean.com classicsteampoweredclean.com ns1.classicsteampipeclean.com classicsteampipeclean.com ns2.classicsteampipeclean.com classicsteampipeclean.com ns1.classicsteammuseumclean.com classicsteammuseumclean.com ns2.classicsteammuseumclean.com classicsteammuseumclean.com ns1.classicsteammodelsclean.com classicsteammodelsclean.com ns2.classicsteammodelsclean.com classicsteammodelsclean.com ns1.classicsteamironclean.com classicsteamironclean.com ns2.classicsteamironclean.com classicsteamironclean.com ns1.classicsteamheatingclean.com classicsteamheatingclean.com ns2.classicsteamheatingclean.com classicsteamheatingclean.com ns1.classicsteamheatclean.com classicsteamheatclean.com ns2.classicsteamheatclean.com classicsteamheatclean.com ns1.classicsteamforumclean.com classicsteamforumclean.com ns2.classicsteamforumclean.com classicsteamforumclean.com ns1.classicsteamfestivalclean.com classicsteamfestivalclean.com ns2.classicsteamfestivalclean.com classicsteamfestivalclean.com ns1.classicsteamenginesclean.com classicsteamenginesclean.com ns2.classicsteamenginesclean.com classicsteamenginesclean.com ns1.classicsteamengineersclean.com classicsteamengineersclean.com ns2.classicsteamengineersclean.com classicsteamengineersclean.com ns1.classicsteamengineeringclean.com classicsteamengineeringclean.com ns2.classicsteamengineeringclean.com classicsteamengineeringclean.com ns1.classicsteamengineclean.com classicsteamengineclean.com ns2.classicsteamengineclean.com classicsteamengineclean.com ns1.classicsteamcloudclean.com classicsteamcloudclean.com ns2.classicsteamcloudclean.com classicsteamcloudclean.com ns1.classicsteamcleansolutions.com classicsteamcleansolutions.com ns2.classicsteamcleansolutions.com classicsteamcleansolutions.com ns1.classicsteamcleaningclean.com classicsteamcleaningclean.com ns2.classicsteamcleaningclean.com classicsteamcleaningclean.com ns1.classicsteamcleanclean.com classicsteamcleanclean.com ns2.classicsteamcleanclean.com classicsteamcleanclean.com ns1.classicsteamcleancarpet.com classicsteamcleancarpet.com ns2.classicsteamcleancarpet.com classicsteamcleancarpet.com ns1.classicsteamchestclean.com classicsteamchestclean.com ns2.classicsteamchestclean.com classicsteamchestclean.com ns1.classicsteamcarpetclean.com classicsteamcarpetclean.com ns2.classicsteamcarpetclean.com classicsteamcarpetclean.com ns1.classicsteambathclean.com classicsteambathclean.com ns2.classicsteambathclean.com classicsteambathclean.com ns1.classicsteamboatsclean.com classicsteamboatsclean.com ns2.classicsteamboatsclean.com classicsteamboatsclean.com ns1.classicsteamboatclean.com classicsteamboatclean.com ns2.classicsteamboatclean.com classicsteamboatclean.com ns1.pressedflowerarrangement.com pressedflowerarrangement.com ns1.pressedflowerdelivery.com pressedflowerdelivery.com ns1.pressedflowerplants.com pressedflowerplants.com ns1.pressedflowercard.com pressedflowercard.com ns1.pressedflowernames.com pressedflowernames.com ns1.pressedflowergirl.com pressedflowergirl.com ns1.pressedflowerimages.com pressedflowerimages.com ns1.pressedflowerfields.com pressedflowerfields.com ns1.pressedflowerstore.com pressedflowerstore.com ns1.pressedflowercolor.com pressedflowercolor.com ns1.pressedflowerguide.com pressedflowerguide.com ns1.coldpressedflower.com coldpressedflower.com ns1.pressedflowerlady.com pressedflowerlady.com ns1.pressedflowerfarm.com pressedflowerfarm.com ns1.pressedflowergift.com pressedflowergift.com ns1.pressedflowertips.com pressedflowertips.com ns1.pressedfloweraffair.com pressedfloweraffair.com ns1.pressedflowergifts.com pressedflowergifts.com ns1.pressedflowerseed.com pressedflowerseed.com ns1.pressedflowerphotos.com pressedflowerphotos.com ns1.pressedflowercolors.com pressedflowercolors.com ns1.pressedflowerseeds.com pressedflowerseeds.com ns1.pressedflowerbeds.com pressedflowerbeds.com ns1.pressedflowerbasket.com pressedflowerbasket.com ns1.pressedflowershops.com pressedflowershops.com ns1.pressedtreeseeds.com pressedtreeseeds.com ns1.pressedtreeleaf.com pressedtreeleaf.com ns1.pressedtreedoctor.com pressedtreedoctor.com ns1.pressedtreebranch.com pressedtreebranch.com ns1.pressedtreephotos.com pressedtreephotos.com ns1.pressedtreewounds.com pressedtreewounds.com ns1.pressedtreeimages.com pressedtreeimages.com ns1.pressedtreeexperts.com pressedtreeexperts.com ns1.pressedtreebranches.com pressedtreebranches.com ns1.coldpressedtree.com coldpressedtree.com ns1.pressedtreefarms.com pressedtreefarms.com ns1.pressedtreeroots.com pressedtreeroots.com ns1.pressedtreeremoval.com pressedtreeremoval.com ns1.pressedtreespecies.com pressedtreespecies.com ns1.pressedtreefarm.com pressedtreefarm.com ns1.pressedtreeplanting.com pressedtreeplanting.com ns1.pressedtree.com pressedtree.com ns1.pressedflowerdatabase.com pressedflowerdatabase.com ns1.pressedflowerdistrict.com pressedflowerdistrict.com ns1.pressedflowerexperts.com pressedflowerexperts.com ns1.pressedflowerkingdom.com pressedflowerkingdom.com ns1.pressedflowerphotography.com pressedflowerphotography.com ns1.pressedflowercottage.com pressedflowercottage.com ns1.pressedflowerdirectory.com pressedflowerdirectory.com ns1.pressedflowerarrangements.com pressedflowerarrangements.com dns02.crescentnets.com crescentnets.com dns01.crescentnets.com crescentnets.com From peter.rudasingwa at altechstream.rw Thu Oct 7 03:24:18 2010 From: peter.rudasingwa at altechstream.rw (Peter Rudasingwa) Date: Thu, 07 Oct 2010 10:24:18 +0200 Subject: P2P link over STM-1 Message-ID: <4CAD83B2.9050204@altechstream.rw> I have clients who want a P2P link over STM-1. How can I achieve this? What kind of equipment do I need. At the moment I have a cisco 6500 and 7200VXR Thanks, Peter R. From drew.weaver at thenap.com Thu Oct 7 06:47:00 2010 From: drew.weaver at thenap.com (Drew Weaver) Date: Thu, 7 Oct 2010 07:47:00 -0400 Subject: DNS/Proxy based DDoS protection Message-ID: Hi, Over the last several years I've noticed there seems to be no limit to the number of proxy/DNS based DDoS protection services springing up all over the place so I am wondering if anyone has any insights on what sorts of tools, etc these companies use to provide this service (Open Source, Commercial?) and if anyone has any thoughts or experiences regarding the effectiveness of these types of services to protect HTTP services. thanks, -Drew From sven at cb3rob.net Thu Oct 7 07:10:37 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Thu, 7 Oct 2010 12:10:37 +0000 (UTC) Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <20101007031224.GA10137@gsp.org> References: <35125.1286402505@tristatelogic.com> <20101007031224.GA10137@gsp.org> Message-ID: we have run a simular system for a while, the problem is still with mailinglists and online shops (by lack of a standardised field the password was put anywhere in the email, all email not containing a password was rejected with a message to call sales) a) you print unique passwords on each businesscard, and simply give them to your clients through other means (sales telephone number, etc) b) there is no O(N^2) scaling. you currently have an email address, and maybe a name for everyone you want to email in your address book, or your database, all thats required is another field with the password they gave you. c) totally fine, with us, it stopped 100% of all undesired email (normally 1500 a day just for me alone ;) If what you're asking under point c is "what happens if a system that contains such a password for your email address gets compromised" the answer is simple, you remove that specific password from your approved passwords list (note that on the receiver side, the password is not linked to the source email address, senders can use any source email address they want, as long as one of the currently active/accepted passwords is in the email) remaining problems with this system are: by lack of a standard header for Password: which should be supported by all clients, address books, online shops, mailinglists, we put the password in the email, which means, that on Cc:'s and forwards etc the password got forwarded along with the email, potentially giving other people the password too. Now, this is -100%- spam stopping, smtp can be as open relay and you want, the internet can be full of compromised windows boxes chunking out tons of crap, but you won't get any spam, just mail from people YOU choose to deal with, by actively -giving- them a password yourself, which you can also -revoke-. (the initial contact, the equivalent of "accept contact" in skype simply needs to be done through other channels, but really, people that don't know you have no business mailing you anyway ;) We have been watching these so-called "spam fighters" for a while now, and all they managed to do over the past 20 years or so is completely fuck up the smtp protocol itself, first they fucked up the concept of open relays, then it was stupid and unnessesary delays (graylisting), then there were all kinds of blacklists run by arrogant fools that gladly blacklisted all of level 3 because of one spammer, etc, and you still got spammed, and still get spammed today. If i have to wait for 20 minutes for an email, i've started skype already.. You know what, why don't we simply turn the smtp servers -off- and use skype and msn for everything... saves electricity :P It may be a bit too late to fix the protocol itself to be real-time and peer-to-peer again, but this time without spam ofcourse, as the market has been flooded with better protocols already anyway (the problem with these however is that they're propriatory and vendor dependant). -- 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 ========================================================================= 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. On Wed, 6 Oct 2010, Rich Kulawiec wrote: > On Wed, Oct 06, 2010 at 10:14:27PM +0000, Sven Olaf Kamphuis wrote: >> (keep in mind, each sender gets a unique password from the receiver, >> this can be stored in the address book along with the email address >> itself). > > I'd like to see the I-D which explains how this is going to work, > with particular attention to (a) how the passwords will be exchanged > without using email (b) how it's going to handle the O(N^2) scaling and > (c) how it's going to work in an environment with at least a hundred > million compromised systems -- that is, systems that are now owned by > the enemy, who thus also owns the contents of all the address books > stored on them...including all the passwords. I think once these > issues are addressed it will be only a small matter of implementation > to convince everyone to swiftly move to a different protocol for mail. > > ---rsk > From schmid at dfn.de Thu Oct 7 07:23:52 2010 From: schmid at dfn.de (Thomas Schmid) Date: Thu, 07 Oct 2010 14:23:52 +0200 Subject: reachability problems Europe->US? Message-ID: <4CADBBD8.1080906@dfn.de> Hi, any known problems with reachability from europe to US? We have customer complaints that they can't reach US-based sites like microsoft and others. Seems to be only source-prefix-based, but several ISPs in europe are affected. Or is the same problem visible in the states? Regards, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5816 bytes Desc: S/MIME Cryptographic Signature URL: From hj1980 at gmail.com Thu Oct 7 07:35:35 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 7 Oct 2010 13:35:35 +0100 Subject: reachability problems Europe->US? In-Reply-To: <4CADBBD8.1080906@dfn.de> References: <4CADBBD8.1080906@dfn.de> Message-ID: >Seems to be only source-prefix-based, but several ISPs in europe are affected. Can you post source and destination IP's ? From mpetach at netflight.com Thu Oct 7 08:06:15 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 7 Oct 2010 06:06:15 -0700 Subject: P2P link over STM-1 In-Reply-To: <4CAD83B2.9050204@altechstream.rw> References: <4CAD83B2.9050204@altechstream.rw> Message-ID: On Thu, Oct 7, 2010 at 1:24 AM, Peter Rudasingwa wrote: > I have clients who want a P2P link over STM-1. > > How can I achieve this? What kind of equipment do I need. > > At the moment I have a cisco 6500 and 7200VXR > > Thanks, > > Peter R. Aren't STM-1 links, by their very nature, point-to-point links? I don't think it's very clear what it is you're trying to do that's out of the ordinary here--can you clarify what it is you're trying to achieve? Thanks! Matt From schmid at dfn.de Thu Oct 7 08:09:42 2010 From: schmid at dfn.de (Thomas Schmid) Date: Thu, 07 Oct 2010 15:09:42 +0200 Subject: reachability problems Europe->US? In-Reply-To: References: <4CADBBD8.1080906@dfn.de> Message-ID: <4CADC696.9020009@dfn.de> Hi, On 07.10.2010 14:35, Heath Jones wrote: >> Seems to be only source-prefix-based, but several ISPs in europe are affected. > Can you post source and destination IP's ? source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21, destination: 65.122.178.73, 63.228.223.104 traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets 1 er-rz-gig-3-3.stw-bonn.de (131.220.99.62) 1.792 ms 1.275 ms 1.125 ms 2 xr-bon1-te2-3.x-win.dfn.de (188.1.233.193) 0.705 ms 2.132 ms 0.755 ms 3 xr-bir1-te2-3.x-win.dfn.de (188.1.144.9) 1.477 ms 1.936 ms 1.051 ms 4 zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46) 4.034 ms 3.734 ms 4.957 ms 5 64.213.78.237 (64.213.78.237) 3.866 ms 3.295 ms 26.854 ms 6 jfk-brdr-04.inet.qwest.net (63.146.26.225) 119.511 ms 92.735 ms 99.019 ms 7 * * * or quote from DE-CIX tech-list: [www.microsoft.com] ----------- We also have some connectivity problems to ms, changing the bgp routing to another tier 1 carrier don t resolve the problem ----------- Cheers, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5816 bytes Desc: S/MIME Cryptographic Signature URL: From Valdis.Kletnieks at vt.edu Thu Oct 7 08:44:29 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 07 Oct 2010 09:44:29 -0400 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: Your message of "Thu, 07 Oct 2010 12:10:37 -0000." References: <35125.1286402505@tristatelogic.com> <20101007031224.GA10137@gsp.org> Message-ID: <81349.1286459069@localhost> On Thu, 07 Oct 2010 12:10:37 -0000, Sven Olaf Kamphuis said: > If what you're asking under point c is "what happens if a system that > contains such a password for your email address gets compromised" the > answer is simple, you remove that specific password from your approved > passwords list 140 million or so compromised systems. You may be spending a lot of time removing compromised passwords from your list - and even more problematic, notifying everybody of the *new* password(s) they should use to e-mail to you. So far this month, I've seen 4,964 mails from 1,090 different From: lines (mostly due to a subscription to the linux-kernel list, which is a true fire hose), and some 250 different SMTP MAIL FROM: sources. > (note that on the receiver side, the password is not linked > to the source email address, senders can use any source email address they > want, as long as one of the currently active/accepted passwords is in the > email) We'll overlook the fact that if the password isn't linked to the source address, then *any* sender can use any source they want, as long as as it's known that *some* sender used '97%-chicken-teriyaki' as a password. And with 140 million compromised boxes, there's a basically never-ending supply of credentials to be stolen and used. > remaining problems with this system are: > by lack of a standard header for Password: which should be supported by > all clients, address books, online shops, mailinglists, we put the > password in the email, which means, that on Cc:'s and forwards etc > the password got forwarded along with the email, potentially giving other > people the password too. And you recognize that your scheme leaks said passwords, but that's not a fatal problem. > Now, this is -100%- spam stopping, smtp can be as open relay and you want, > the internet can be full of compromised windows boxes chunking out tons of > crap, but you won't get any spam, just mail from people YOU choose to deal > with, by actively -giving- them a password yourself, which you can also > -revoke-. So explain to me in *detail* - you're in the To: line of this mail. I don't believe I've sent to you in the past. I acquire a password valid to send you this e-mail, how, exactly? After all, I can't e-mail you and ask for one... After that, explain how a Hotmail user migrates to GMail (or vice versa) and retains their ability to contact everybody they used to contact. You might want to look at this: http://www.rhyolite.com/anti-spam/you-might-be.html and see how many of the entries in the list apply to your proposal. (Nothing personal - I don't think *any* realistic anti-spam proposal can get much traction unless they've at least *thought* about every single bullet point on that list). Further discussion is probably best on SPAM-L. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From schmid at dfn.de Thu Oct 7 08:50:15 2010 From: schmid at dfn.de (Thomas Schmid) Date: Thu, 07 Oct 2010 15:50:15 +0200 Subject: reachability problems Europe->US? In-Reply-To: <4CADC696.9020009@dfn.de> References: <4CADBBD8.1080906@dfn.de> <4CADC696.9020009@dfn.de> Message-ID: <4CADD017.8060307@dfn.de> an update: On 07.10.2010 15:09, Thomas Schmid wrote: > Hi, > > On 07.10.2010 14:35, Heath Jones wrote: >>> Seems to be only source-prefix-based, but several ISPs in europe are >>> affected. >> Can you post source and destination IP's ? > > source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21, > destination: 65.122.178.73, 63.228.223.104 > > traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets > 1 er-rz-gig-3-3.stw-bonn.de (131.220.99.62) 1.792 ms 1.275 ms 1.125 ms > 2 xr-bon1-te2-3.x-win.dfn.de (188.1.233.193) 0.705 ms 2.132 ms 0.755 ms > 3 xr-bir1-te2-3.x-win.dfn.de (188.1.144.9) 1.477 ms 1.936 ms 1.051 ms > 4 zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46) 4.034 ms 3.734 ms 4.957 ms > 5 64.213.78.237 (64.213.78.237) 3.866 ms 3.295 ms 26.854 ms > 6 jfk-brdr-04.inet.qwest.net (63.146.26.225) 119.511 ms 92.735 ms 99.019 ms > 7 * * * > > or quote from DE-CIX tech-list: > > [www.microsoft.com] > ----------- > We also have some connectivity problems to ms, changing the bgp routing to > another tier 1 carrier don t resolve the problem > ----------- > we shut down GBLX and routing now goes via Telia. Seems this helped. Looks like there is an issue in the path GBLX - Qwest - ? Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5816 bytes Desc: S/MIME Cryptographic Signature URL: From jason at i6ix.com Thu Oct 7 08:59:53 2010 From: jason at i6ix.com (Jason Bertoch) Date: Thu, 07 Oct 2010 09:59:53 -0400 Subject: AS6517 - Reliance Globalcom -- routing three more hijacked blocks In-Reply-To: <37614.1286422573@tristatelogic.com> References: <37614.1286422573@tristatelogic.com> Message-ID: <4CADD259.4020903@i6ix.com> On 2010/10/06 11:36 PM, Ronald F. Guilmette wrote: > Well, anyway, here's three more hijacked blocks that they (AS6517) > are routing. This is in addition to the 75 such blocks I've already > reported. (I guess that makes 78 hijacked blocks for them, in total.) Out of curiosity, are you also reporting these blocks to Spamhaus? I expect their DROP list maintainers would be interested. -- /Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5578 bytes Desc: S/MIME Cryptographic Signature URL: From hj1980 at gmail.com Thu Oct 7 09:06:40 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 7 Oct 2010 15:06:40 +0100 Subject: reachability problems Europe->US? In-Reply-To: <4CADC696.9020009@dfn.de> References: <4CADBBD8.1080906@dfn.de> <4CADC696.9020009@dfn.de> Message-ID: >>> Seems to be only source-prefix-based, but several ISPs in europe are >>> affected. > source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21, > destination: 65.122.178.73, 63.228.223.104 > traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets > ?1 ?er-rz-gig-3-3.stw-bonn.de (131.220.99.62) ?1.792 ms ?1.275 ms ?1.125 ms > ?2 ?xr-bon1-te2-3.x-win.dfn.de (188.1.233.193) ?0.705 ms ?2.132 ms ?0.755 ms > ?3 ?xr-bir1-te2-3.x-win.dfn.de (188.1.144.9) ?1.477 ms ?1.936 ms ?1.051 ms > ?4 ?zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46) ?4.034 ms ?3.734 ms ?4.957 > ms > ?5 ?64.213.78.237 (64.213.78.237) ?3.866 ms ?3.295 ms ?26.854 ms > ?6 ?jfk-brdr-04.inet.qwest.net (63.146.26.225) ?119.511 ms ?92.735 ms > ?99.019 ms Based on all that, it looks like Qwest is not propogating your routes within their network. I was going to recommend route-views, but it might not reflect that now if you have dropped GBLX. Historical routing updates will show though if Qwest were advertising reachability to you (which would be a good indicator if they were filtering at their edge) From hj1980 at gmail.com Thu Oct 7 09:09:23 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 7 Oct 2010 15:09:23 +0100 Subject: AS6517 - Reliance Globalcom -- routing three more hijacked blocks In-Reply-To: <4CADD259.4020903@i6ix.com> References: <37614.1286422573@tristatelogic.com> <4CADD259.4020903@i6ix.com> Message-ID: >> Well, anyway, here's three more hijacked blocks that they (AS6517) >> are routing. ?This is in addition to the 75 such blocks I've already >> reported. ?(I guess that makes 78 hijacked blocks for them, in total.) > > Out of curiosity, are you also reporting these blocks to Spamhaus? ?I expect > their DROP list maintainers would be interested. With an IP space of just 2^32, I'd suspect they are better off maintaining a whitelist ;) From feldman at twincreeks.net Thu Oct 7 09:21:01 2010 From: feldman at twincreeks.net (Steve Feldman) Date: Thu, 7 Oct 2010 10:21:01 -0400 Subject: [NANOG-announce] NANOG election results and other news Message-ID: <54A3EEBA-6A0B-455C-B7F4-F12C4C3B8559@twincreeks.net> As usual for our October meetings, there has been a lot happening, with more to come over the next few days. Our annual election was held during NANOG 50, with these results: - Patrick Gilmore, Robert Seastrom, and Richard Steenbergen were elected to two-year terms on the NANOG SC (and also therefore to the NewNOG Board.) - The charter amendment to transition NANOG activities from Merit to NewNOG passed with 210 votes in favor, 16 votes against. - In the NewNOG election, the measure to adopt the Bylaws passed with 169 votes in favor, 26 against. I have been elected by the SC to serve again as Chair for the coming year, and Sylvie LaPerriere was elected as Vice-Chair. The Program Committee selection process is underway, and the results will be announced in the next day so. Nominations are still open for Communications Committee positions. I would like to encourage any of you who regularly participate in the mailing list and are interested in maintaining list quality and in building new forms of communication for the community to consider volunteering. Please see: http://www.nanog.org/governance/elections/2010elections/ for further information on the selection process. For the Steering Committee, Steve Feldman, chair _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From morrowc.lists at gmail.com Thu Oct 7 09:25:54 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 7 Oct 2010 10:25:54 -0400 Subject: AS6517 - Reliance Globalcom -- routing three more hijacked blocks In-Reply-To: References: <37614.1286422573@tristatelogic.com> <4CADD259.4020903@i6ix.com> Message-ID: On Thu, Oct 7, 2010 at 10:09 AM, Heath Jones wrote: >>> Well, anyway, here's three more hijacked blocks that they (AS6517) >>> are routing. ?This is in addition to the 75 such blocks I've already >>> reported. ?(I guess that makes 78 hijacked blocks for them, in total.) >> >> Out of curiosity, are you also reporting these blocks to Spamhaus? ?I expect >> their DROP list maintainers would be interested. > > With an IP space of just 2^32, I'd suspect they are better off > maintaining a whitelist ;) in stabbing around today on the ARIN online website I noticed this: " ARIN provides access to a list of number resources in the database which have no valid POC data. A POC handle is marked invalid by ARIN staff when the POC has not been modified in more than one year and the POC fails to respond to ARIN's annual request to validate their POC information. In order to access this report, NRPM Policy 3.6.1 requires that you meet the criteria specified in ARIN?s Bulk Whois policy, including signing an Acceptable Use Policy (AUP). Complete information on Bulk Whois, including the AUP and data request form can be found here. " one wonders if this sort of thing could be useful to folks maintaining lists of numbers that are used to affect other folks business plans. From sven at cb3rob.net Thu Oct 7 09:16:00 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Thu, 7 Oct 2010 14:16:00 +0000 (UTC) Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <81349.1286459069@localhost> References: <35125.1286402505@tristatelogic.com> <20101007031224.GA10137@gsp.org> <81349.1286459069@localhost> Message-ID: you just give contacts for the passwords with which you have received a new one. each potential person that can send email to your email address, gets a unique password from you. sending person/maillist 1 gets password abcdefg to send to bla at example.com (no matter from which email address) sending person/maillist 2 gets password 123545 to send to bla at example.com (no matter from which email address) email clients should be modified to include the password: field both in the email itself and in the header entry field (to: from: subjecT: or just store them together with the destination address in the address book mailservers (the maildrop part) should be modified to parse the Password: header, compare it to the list of currently allowed passwords for the destination email address and then either drop to the mailbox, or bounce. (we did this in our test setup by simply parsing the entire email, so the password could be -anywhere- in the email :P ofcourse the Password: line should be only sent to the recipient, not to other Cc: or Bcc: target addresses of the same email, the first stmp server in the chain should solve this bit. actually, durign our tests, we turned off all the header verifications, RBL's, etc on our smtpds, and the only spam that got through were emails that accidentially contained the password string in a binary attachment (as we parsed the entire email .. we should not do that, just teh Password: line in the final version :P and stuff where we gave, for example, nanog, the password "nanog" and then nanog is cc'ed in a spam both of which cases can be solved with the standardization of the Password: field once this is in place, all smtpds can go open relay again, port 25 can be opened again on eyeball networks, RBLs and graylisting can remain at home, and the SMTP email system will be 100% spam free and reliable and real-time. (there are several other features which have been removed from most smtpds to "stop spam" such as accepting ip addresses rather than domain names in the target email address, which can then return) all the other stuff never stopped spam, it just made smtp email unreliable slow and no longer an option for 99% of the things where email was used for before, and skype, msn and facebook are used for today. this system -does- stop spam, but the disadvantage to this system is that by implementing it, smtp email is no longer suitable for "initial contact" (well you could ofcourse place passwords in whois and on your website for your hostmaster/sales box so random people can still make initial contact over smtp, or simply accept all passwords on those boxes, on which then there WILL be spam.. ;) i'd say, smtp no longer being "open for any random idiot to mail any other random idiot without knowing each other first" is less of a disadvantage than taking the whole thing slowly die by making it less and less attractive as a means of communications (slow, unreliable and not real-time, and still with spam coming in by the 1000s, which it is due to "conventional" attempts to stop spam) -- 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 ========================================================================= 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. On Thu, 7 Oct 2010, Valdis.Kletnieks at vt.edu wrote: > On Thu, 07 Oct 2010 12:10:37 -0000, Sven Olaf Kamphuis said: >> If what you're asking under point c is "what happens if a system that >> contains such a password for your email address gets compromised" the >> answer is simple, you remove that specific password from your approved >> passwords list > > 140 million or so compromised systems. You may be spending a lot of time > removing compromised passwords from your list - and even more problematic, > notifying everybody of the *new* password(s) they should use to e-mail to you. > So far this month, I've seen 4,964 mails from 1,090 different From: lines > (mostly due to a subscription to the linux-kernel list, which is a true fire > hose), and some 250 different SMTP MAIL FROM: sources. > >> (note that on the receiver side, the password is not linked >> to the source email address, senders can use any source email address they >> want, as long as one of the currently active/accepted passwords is in the >> email) > > We'll overlook the fact that if the password isn't linked to the source > address, then *any* sender can use any source they want, as long as as it's > known that *some* sender used '97%-chicken-teriyaki' as a password. And with > 140 million compromised boxes, there's a basically never-ending supply of > credentials to be stolen and used. > >> remaining problems with this system are: >> by lack of a standard header for Password: which should be supported by >> all clients, address books, online shops, mailinglists, we put the >> password in the email, which means, that on Cc:'s and forwards etc >> the password got forwarded along with the email, potentially giving other >> people the password too. > > And you recognize that your scheme leaks said passwords, but that's not a fatal > problem. > >> Now, this is -100%- spam stopping, smtp can be as open relay and you want, >> the internet can be full of compromised windows boxes chunking out tons of >> crap, but you won't get any spam, just mail from people YOU choose to deal >> with, by actively -giving- them a password yourself, which you can also >> -revoke-. > > So explain to me in *detail* - you're in the To: line of this mail. I don't > believe I've sent to you in the past. I acquire a password valid to send you > this e-mail, how, exactly? After all, I can't e-mail you and ask for one... > > After that, explain how a Hotmail user migrates to GMail (or vice versa) and > retains their ability to contact everybody they used to contact. > > You might want to look at this: > > http://www.rhyolite.com/anti-spam/you-might-be.html > > and see how many of the entries in the list apply to your proposal. (Nothing > personal - I don't think *any* realistic anti-spam proposal can get much > traction unless they've at least *thought* about every single bullet point on > that list). > > Further discussion is probably best on SPAM-L. > > From sven at cb3rob.net Thu Oct 7 09:19:59 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Thu, 7 Oct 2010 14:19:59 +0000 (UTC) Subject: AS6517 - Reliance Globalcom -- routing three more hijacked blocks In-Reply-To: References: <37614.1286422573@tristatelogic.com> <4CADD259.4020903@i6ix.com> Message-ID: On Thu, 7 Oct 2010, Heath Jones wrote: >>> Well, anyway, here's three more hijacked blocks that they (AS6517) >>> are routing. ?This is in addition to the 75 such blocks I've already >>> reported. ?(I guess that makes 78 hijacked blocks for them, in total.) >> >> Out of curiosity, are you also reporting these blocks to Spamhaus? ?I expect >> their DROP list maintainers would be interested. > > With an IP space of just 2^32, I'd suspect they are better off > maintaining a whitelist ;) > I'd say people that hijack space have a legitimate need for it or they would not be doing it. as long as spamming is not "criminal activity" i see no need to filter them actually, on the other hand, we spend a lot of time filtering MPAA/RIAA member ranges. I can has blacklist for those? (those are the real enemies of the internet industry, not the spammers :P From jcurran at arin.net Thu Oct 7 09:35:08 2010 From: jcurran at arin.net (John Curran) Date: Thu, 7 Oct 2010 10:35:08 -0400 Subject: AS6517 - Reliance Globalcom -- routing three more hijacked blocks - bulk Whois In-Reply-To: References: <37614.1286422573@tristatelogic.com> <4CADD259.4020903@i6ix.com> Message-ID: <265AA82B-1BBA-48C2-A366-B0FC6229E621@arin.net> On Oct 7, 2010, at 10:25 AM, Christopher Morrow wrote: > > in stabbing around today on the ARIN online website I noticed this: > > " ARIN provides access to a list of number resources in the database > which have no valid POC data. A POC handle is marked invalid by ARIN > staff when the POC has not been modified in more than one year and the > POC fails to respond to ARIN's annual request to validate their POC > information. In order to access this report, NRPM Policy 3.6.1 > requires that you meet the criteria specified in ARIN?s Bulk Whois > policy, including signing an Acceptable Use Policy (AUP). Complete > information on Bulk Whois, including the AUP and data request form can > be found here. " > > one wonders if this sort of thing could be useful to folks maintaining > lists of numbers that are used to affect other folks business plans. Chris - Very timely... I should advise the community that a revised ARIN Bulk WHOIS policy will be sent for community consultation shortly, and folks should take a chance to comment on the valid uses of access to this data. More information on how ARIN processes incoming suggestions and consultations is available here: FYI, /John John Curran President and CEO ARIN From Valdis.Kletnieks at vt.edu Thu Oct 7 10:07:51 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Thu, 07 Oct 2010 11:07:51 -0400 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: Your message of "Thu, 07 Oct 2010 14:16:00 -0000." References: <35125.1286402505@tristatelogic.com> <20101007031224.GA10137@gsp.org> <81349.1286459069@localhost> Message-ID: <14431.1286464071@localhost> On Thu, 07 Oct 2010 14:16:00 -0000, Sven Olaf Kamphuis said: > you just give contacts for the passwords with which you have received a > new one. > > each potential person that can send email to your email address, gets a > unique password from you. You missed the point. How does person37 at gmail.com ask me for a password, if I don't accept his e-mail without one? (Hold this thought, we'll be back to this) > sending person/maillist 1 gets password abcdefg to send to bla at example.com > (no matter from which email address) > > sending person/maillist 2 gets password 123545 to send to bla at example.com > (no matter from which email address) And if I've assigned 123545 to duct-tape-2010 at yahoo.com, but he's since moved to clawhammer101 at gmail.com, how do I securely notify him of the new password, keeping in mind that I'm probably changing the password *because the enemy already has access to the old password*? "Hey Joe - somebody has enough access to your system to get 123545 - so use fuzzy-wombat instead". What's wrong with this picture? With 140 million compromised boxes where sending the new password is basically e-mailing to the enemy, and the scheme leaking new passwords to boot, "revoke and issue a new credential" simply doesn't scale. In other words, the only sane response is "revoke and don't bother setting new one". At which point the person has to contact me and ask for a new password. "Hey, this is duct-tape-2010, my password doesn't work, give me a new one". Given that his old password doesn't work because I revoked it when a spammer got hold of it, how do I know that I'm not giving the new password directly to the spammer and the esteemed Mr Tape has no idea any of this happened? Further discussion probably belongs on SPAM-L. -------------- 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 Thu Oct 7 10:11:18 2010 From: nick at foobar.org (Nick Hilliard) Date: Thu, 07 Oct 2010 16:11:18 +0100 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: References: <35125.1286402505@tristatelogic.com> <20101007031224.GA10137@gsp.org> Message-ID: <4CADE316.8020609@foobar.org> On 07/10/2010 13:10, Sven Olaf Kamphuis wrote: > You know what, why don't we simply turn the smtp servers -off- This is an excellent idea. I invite you to do everyone a favour and turn yours off first. Nick From jvanoppen at spectrumnet.us Thu Oct 7 10:59:12 2010 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 7 Oct 2010 15:59:12 +0000 Subject: reachability problems Europe->US? In-Reply-To: <4CADC696.9020009@dfn.de> References: <4CADBBD8.1080906@dfn.de> <4CADC696.9020009@dfn.de> Message-ID: Global crossing is having major issues (since yesterday actually) in Seattle. Every path I see to dfn.de is via gblx and Microsoft hosts most of those sites out of the seattle area so they may be seeing the same issue. Based on what we can see gblx has a broken port-channel or something similar here as random traffic (into) their network via our transit link gets black-holed. We could not even reach global crossing's own name servers for a while. We gave up and turned down BGP yesterday until we hear from them. Based on graphs at the time things broke they appeared to be black-holing roughly 1/4 of what we were sending them. Thanks, John van Oppen Spectrum Networks / AS 11404 -----Original Message----- From: Thomas Schmid [mailto:schmid at dfn.de] Sent: Thursday, October 07, 2010 6:10 AM To: Heath Jones Cc: nanog at nanog.org Subject: Re: reachability problems Europe->US? Hi, On 07.10.2010 14:35, Heath Jones wrote: >> Seems to be only source-prefix-based, but several ISPs in europe are affected. > Can you post source and destination IP's ? source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21, destination: 65.122.178.73, 63.228.223.104 traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets 1 er-rz-gig-3-3.stw-bonn.de (131.220.99.62) 1.792 ms 1.275 ms 1.125 ms 2 xr-bon1-te2-3.x-win.dfn.de (188.1.233.193) 0.705 ms 2.132 ms 0.755 ms 3 xr-bir1-te2-3.x-win.dfn.de (188.1.144.9) 1.477 ms 1.936 ms 1.051 ms 4 zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46) 4.034 ms 3.734 ms 4.957 ms 5 64.213.78.237 (64.213.78.237) 3.866 ms 3.295 ms 26.854 ms 6 jfk-brdr-04.inet.qwest.net (63.146.26.225) 119.511 ms 92.735 ms 99.019 ms 7 * * * or quote from DE-CIX tech-list: [www.microsoft.com] ----------- We also have some connectivity problems to ms, changing the bgp routing to another tier 1 carrier don t resolve the problem ----------- Cheers, Thomas From tim at pelican.org Thu Oct 7 11:12:16 2010 From: tim at pelican.org (Tim Franklin) Date: Thu, 7 Oct 2010 16:12:16 +0000 (GMT) Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <29659284.21286467764430.JavaMail.root@jennyfur.pelican.org> Message-ID: <5804618.41286467936068.JavaMail.root@jennyfur.pelican.org> > If i have to wait for 20 minutes for an email, i've started skype > already.. You know what, why don't we simply turn the smtp servers > -off- and use skype and msn for everything... saves electricity :P By that argument, why don't we turn off the Internet and use SMS for everything? > It may be a bit too late to fix the protocol itself to be real-time > and peer-to-peer again, but this time without spam ofcourse, as the > market has been flooded with better protocols already anyway (the > problem with these however is that they're propriatory and vendor > dependant). When was email *ever* expected to be real-time? If you need real time, use IM (the clue is in the "I"), or pick up the phone. Part of the beauty of email is that it doesn't require all participants to be connected at the same time, and everyone can deal with it when it's convenient to *them*, not convenient to the sender. Use the right communication tool for the right job. I can remember email being batch-transferred over dial-up lines, hop-by-hop, and taking hours or even days to cross the globe - and I'm a long way from being an Internet "old-timer". Regards, Tim. From hj1980 at gmail.com Thu Oct 7 11:22:01 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 7 Oct 2010 17:22:01 +0100 Subject: reachability problems Europe->US? In-Reply-To: References: <4CADBBD8.1080906@dfn.de> <4CADC696.9020009@dfn.de> Message-ID: >... random traffic (into) their network via our transit link gets black-holed. So for the same source & destination, sometimes it works, sometimes it doesn't? From ryan.finnesey at HarrierInvestments.com Thu Oct 7 11:24:14 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Thu, 7 Oct 2010 09:24:14 -0700 Subject: Amazon - Flexible Payments Service (Amazon FPS) Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300A517@EXVBE005-2.exch005intermedia.net> Would someone from Amazon mind contacting me off-list. I have some questions on the best way to pass traffic to Flexible Payments Service (Amazon FPS) and my e-mails to the contacts within peeringdb.com have gone unanswered. Cheers Ryan From hj1980 at gmail.com Thu Oct 7 11:24:25 2010 From: hj1980 at gmail.com (Heath Jones) Date: Thu, 7 Oct 2010 17:24:25 +0100 Subject: reachability problems Europe->US? In-Reply-To: References: <4CADBBD8.1080906@dfn.de> <4CADC696.9020009@dfn.de> Message-ID: It seemed from the symptoms OP was seeing, that Qwest was the issue. Has GLBX reported to you that they are having a fault? If not, perhaps try tagging your exported routes to GLBX with 8010 as per this: http://onesc.net/communities/as3549/ On 7 October 2010 16:59, John van Oppen wrote: > Global crossing is having major issues (since yesterday actually) in Seattle. ? ?Every path I see to dfn.de is via gblx and Microsoft hosts most of those sites out of the seattle area so they may be seeing the same issue. > > Based on what we can see gblx has a broken port-channel or something similar here as random traffic (into) their network via our transit link gets black-holed. ? We could not even reach global crossing's own name servers for a while. ? ?We gave up and turned down BGP yesterday until we hear from them. ? Based on graphs at the time things broke they appeared to be black-holing roughly 1/4 of what we were sending them. > > > Thanks, > John van Oppen > Spectrum Networks / AS 11404 > > > -----Original Message----- > From: Thomas Schmid [mailto:schmid at dfn.de] > Sent: Thursday, October 07, 2010 6:10 AM > To: Heath Jones > Cc: nanog at nanog.org > Subject: Re: reachability problems Europe->US? > > Hi, > > On 07.10.2010 14:35, Heath Jones wrote: >>> Seems to be only source-prefix-based, but several ISPs in europe are affected. >> Can you post source and destination IP's ? > > source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21, > destination: 65.122.178.73, 63.228.223.104 > > traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets > ?1 ?er-rz-gig-3-3.stw-bonn.de (131.220.99.62) ?1.792 ms ?1.275 ms ?1.125 ms > ?2 ?xr-bon1-te2-3.x-win.dfn.de (188.1.233.193) ?0.705 ms ?2.132 ms ?0.755 ms > ?3 ?xr-bir1-te2-3.x-win.dfn.de (188.1.144.9) ?1.477 ms ?1.936 ms ?1.051 ms > ?4 ?zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46) ?4.034 ms ?3.734 ms ?4.957 ms > ?5 ?64.213.78.237 (64.213.78.237) ?3.866 ms ?3.295 ms ?26.854 ms > ?6 ?jfk-brdr-04.inet.qwest.net (63.146.26.225) ?119.511 ms ?92.735 ms ?99.019 ms > ?7 ?* * * > > or quote from DE-CIX tech-list: > > [www.microsoft.com] > ----------- > We also have some connectivity problems to ms, changing the bgp routing to > another tier 1 carrier don t resolve the problem > ----------- > > Cheers, > > ?Thomas > > From jvanoppen at spectrumnet.us Thu Oct 7 11:44:11 2010 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 7 Oct 2010 16:44:11 +0000 Subject: reachability problems Europe->US? In-Reply-To: References: <4CADBBD8.1080906@dfn.de> <4CADC696.9020009@dfn.de> Message-ID: I know for certain it was gblx, noc confirmed, we saw this to multiple destinations all with the outbound towards gblx (not just DFN). We are on the same GBLX pop the sites they are talking about are connected to (westin) and almost every path I see back to dfn (from seven upstreams in seattle) was via gblx not qwest, the only exceptions were level3's and Savvis' routes which are via AS1299. I think the asymmetric routing was obfuscating the problem a bit for the guys attached to DFN. John -----Original Message----- From: Heath Jones [mailto:hj1980 at gmail.com] Sent: Thursday, October 07, 2010 9:24 AM To: John van Oppen Cc: Thomas Schmid; nanog at nanog.org Subject: Re: reachability problems Europe->US? It seemed from the symptoms OP was seeing, that Qwest was the issue. Has GLBX reported to you that they are having a fault? If not, perhaps try tagging your exported routes to GLBX with 8010 as per this: http://onesc.net/communities/as3549/ On 7 October 2010 16:59, John van Oppen wrote: > Global crossing is having major issues (since yesterday actually) in Seattle. ? ?Every path I see to dfn.de is via gblx and Microsoft hosts most of those sites out of the seattle area so they may be seeing the same issue. > > Based on what we can see gblx has a broken port-channel or something similar here as random traffic (into) their network via our transit link gets black-holed. ? We could not even reach global crossing's own name servers for a while. ? ?We gave up and turned down BGP yesterday until we hear from them. ? Based on graphs at the time things broke they appeared to be black-holing roughly 1/4 of what we were sending them. > > > Thanks, > John van Oppen > Spectrum Networks / AS 11404 > > > -----Original Message----- > From: Thomas Schmid [mailto:schmid at dfn.de] > Sent: Thursday, October 07, 2010 6:10 AM > To: Heath Jones > Cc: nanog at nanog.org > Subject: Re: reachability problems Europe->US? > > Hi, > > On 07.10.2010 14:35, Heath Jones wrote: >>> Seems to be only source-prefix-based, but several ISPs in europe are affected. >> Can you post source and destination IP's ? > > source: 131.220.0.0/16, 212.201.68.0/22, 212.201.72.0/21, > destination: 65.122.178.73, 63.228.223.104 > > traceroute to 65.122.178.73 (65.122.178.73), 30 hops max, 40 byte packets > ?1 ?er-rz-gig-3-3.stw-bonn.de (131.220.99.62) ?1.792 ms ?1.275 ms ?1.125 ms > ?2 ?xr-bon1-te2-3.x-win.dfn.de (188.1.233.193) ?0.705 ms ?2.132 ms ?0.755 ms > ?3 ?xr-bir1-te2-3.x-win.dfn.de (188.1.144.9) ?1.477 ms ?1.936 ms ?1.051 ms > ?4 ?zr-fra1-te0-7-0-5.x-win.dfn.de (188.1.145.46) ?4.034 ms ?3.734 ms ?4.957 ms > ?5 ?64.213.78.237 (64.213.78.237) ?3.866 ms ?3.295 ms ?26.854 ms > ?6 ?jfk-brdr-04.inet.qwest.net (63.146.26.225) ?119.511 ms ?92.735 ms ?99.019 ms > ?7 ?* * * > > or quote from DE-CIX tech-list: > > [www.microsoft.com] > ----------- > We also have some connectivity problems to ms, changing the bgp routing to > another tier 1 carrier don t resolve the problem > ----------- > > Cheers, > > ?Thomas > > From jvanoppen at spectrumnet.us Thu Oct 7 11:46:39 2010 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Thu, 7 Oct 2010 16:46:39 +0000 Subject: reachability problems Europe->US? In-Reply-To: References: <4CADBBD8.1080906@dfn.de> <4CADC696.9020009@dfn.de> Message-ID: It looked like a broken aggregated Ethernet bundle or something similar... Most annoying was that the issue moved around a bit, over about five hours all the broken test IPs we had started working again and then other destinations started failing. All was well when we turned down gblx. As of now though we are seeing the issue as fixed and turned up GBLX again. Thanks, John -----Original Message----- From: Heath Jones [mailto:hj1980 at gmail.com] Sent: Thursday, October 07, 2010 9:22 AM To: John van Oppen Cc: Thomas Schmid; nanog at nanog.org Subject: Re: reachability problems Europe->US? >... random traffic (into) their network via our transit link gets black-holed. So for the same source & destination, sometimes it works, sometimes it doesn't? From schmid at dfn.de Thu Oct 7 12:12:33 2010 From: schmid at dfn.de (Thomas Schmid) Date: Thu, 07 Oct 2010 19:12:33 +0200 Subject: reachability problems Europe->US? In-Reply-To: References: <4CADBBD8.1080906@dfn.de> <4CADC696.9020009@dfn.de> Message-ID: <4CADFF81.7090508@dfn.de> Am 07.10.2010 18:46, schrieb John van Oppen: > It looked like a broken aggregated Ethernet bundle or something similar... Most annoying was that the issue moved around a bit, over about five hours all the broken test IPs we had started working again and then other destinations started failing. All was well when we turned down gblx. As of now though we are seeing the issue as fixed and turned up GBLX again. > yes, I can confirm that situation is back to normal now after we re-enabled the GBLX session. I heared from others that it was again a broken LSP problem in GBLX (unconfirmed :) ) Cheers, Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5816 bytes Desc: S/MIME Cryptographic Signature URL: From Bryan.Welch at arrisi.com Thu Oct 7 13:26:42 2010 From: Bryan.Welch at arrisi.com (Welch, Bryan) Date: Thu, 7 Oct 2010 11:26:42 -0700 Subject: P2P link over STM-1 In-Reply-To: <4CAD83B2.9050204@altechstream.rw> References: <4CAD83B2.9050204@altechstream.rw> Message-ID: I politely suggest a call into your Cisco account team so they can help you spec the equipment you require. Otherwise a quick google for Cisco+OC-48 would help you out tremendously. Bryan -----Original Message----- From: Peter Rudasingwa [mailto:peter.rudasingwa at altechstream.rw] Sent: Thursday, October 07, 2010 1:24 AM To: nanog at nanog.org Subject: P2P link over STM-1 I have clients who want a P2P link over STM-1. How can I achieve this? What kind of equipment do I need. At the moment I have a cisco 6500 and 7200VXR Thanks, Peter R. From ras at e-gerbil.net Thu Oct 7 14:07:16 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Thu, 7 Oct 2010 14:07:16 -0500 Subject: reachability problems Europe->US? In-Reply-To: <4CADFF81.7090508@dfn.de> References: <4CADBBD8.1080906@dfn.de> <4CADC696.9020009@dfn.de> <4CADFF81.7090508@dfn.de> Message-ID: <20101007190716.GI24854@gerbil.cluepon.net> On Thu, Oct 07, 2010 at 07:12:33PM +0200, Thomas Schmid wrote: > yes, I can confirm that situation is back to normal now after we > re-enabled the GBLX session. I heared from others that it was again a > broken LSP problem in GBLX (unconfirmed :) ) Global Crossing recently started deploying Foundry/Brocade XMR's in their MPLS core, as a lower cost alternative to their old T640/OC192 MPLS core model. Unfortunately these boxes are buggy as all hell, and seem to blackhole LSPs somewhere in their network on at least a weekly basis. I think we've seen at least a dozen issues similar to this over the last couple months, though most of them were out of LA, so I didn't know they had actually done a Seattle deployment. Honestly GX deserves what they get on this one. I'm not aware of any other large network who has ever done a serious MPLS deployment using these boxes (and if you're thinking of replying to this and saying "hey we do some vll's between 2 routers and it seems to work", stop and think about what I might mean when I say a SERIOUS mpls deployment first :P), so this was pretty much to be expected. I'll also say that I'm remarkably underwhelmed by their response to this issue, and suggest that anyone who doesn't want their packets blackholed by the Floundrys be prepared to vote with their wallet. -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From sven at cb3rob.net Thu Oct 7 14:23:07 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Thu, 7 Oct 2010 19:23:07 +0000 (UTC) Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <5804618.41286467936068.JavaMail.root@jennyfur.pelican.org> References: <5804618.41286467936068.JavaMail.root@jennyfur.pelican.org> Message-ID: > > When was email *ever* expected to be real-time? If you need real time, use IM (the clue is in the "I"), or pick up the phone. if you simply run the smtpd on port 25 of the little boxy thing with the blinking lights and the big shiney apple on it on your desk (which has for most applications replaced the big dusty mainframe in the basement to which your (real-time interactive!) terminal on your desk connected.. and give it a "real" ip, its pretty much real time. and that's how it was meant to be used, yet made impossible by those dusty old self-declared 'spam fighters', with their clearly non working methods. From carlosm3011 at gmail.com Thu Oct 7 14:39:00 2010 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Thu, 7 Oct 2010 15:39:00 -0400 Subject: P2P link over STM-1 In-Reply-To: <4CAD83B2.9050204@altechstream.rw> References: <4CAD83B2.9050204@altechstream.rw> Message-ID: As said above, STM-1s are by their very nature point to point links. You just need an STM-1 interface on your side and another on the customer side. Which one will depend on the router models you will be using. Also, as said above, you will need to engage the help of your local Cisco partner for this. >From your side (I mean the service provider side) you can also have a channelized STM-4 or STM-16 and use one STM-1 channel for this. This would be a good idea if you plan to have more than one customer of this nature. Beware that these interfaces can be quite expensive. Hope this helps, Carlos On Thu, Oct 7, 2010 at 4:24 AM, Peter Rudasingwa < peter.rudasingwa at altechstream.rw> wrote: > I have clients who want a P2P link over STM-1. > > How can I achieve this? What kind of equipment do I need. > > At the moment I have a cisco 6500 and 7200VXR > > Thanks, > > Peter R. > -- -- ========================= Carlos M. Martinez-Cagnazzo http://cagnazzo.name ========================= From mksmith at adhost.com Thu Oct 7 15:05:03 2010 From: mksmith at adhost.com (Michael K. Smith - Adhost) Date: Thu, 7 Oct 2010 13:05:03 -0700 Subject: P2P link over STM-1 In-Reply-To: <4CAD83B2.9050204@altechstream.rw> References: <4CAD83B2.9050204@altechstream.rw> Message-ID: <17838240D9A5544AAA5FF95F8D520316091939DB@ad-exh01.adhost.lan> > -----Original Message----- > From: Peter Rudasingwa [mailto:peter.rudasingwa at altechstream.rw] > Sent: Thursday, October 07, 2010 1:24 AM > To: nanog at nanog.org > Subject: P2P link over STM-1 > > I have clients who want a P2P link over STM-1. > > How can I achieve this? What kind of equipment do I need. > > At the moment I have a cisco 6500 and 7200VXR > > Thanks, > > Peter R. AFAIK you can get a channelized STM-1 card and offer your customers E-1's, etc. Or, if you are looking to do Ethernet you would have to move into the 15454 type chassis. Mike From jharper at well.com Thu Oct 7 17:48:51 2010 From: jharper at well.com (Jeff Harper) Date: Thu, 7 Oct 2010 15:48:51 -0700 (PDT) Subject: Facebook down!! Alert! In-Reply-To: <4CACF739.2010800@spectraaccess.com> Message-ID: <656056380.1591.1286491731174.JavaMail.root@zimbra.well.com> ----- Original Message ----- > From: "Bret Clark" > I've always looked at the nanog list representing issues up to layer 4 > of the OSI model; mostly layer 3/4. Maybe a new mailing list could be > made called the North American Network Applications Group > (nanag)...there might be a pun there :). Perhaps, but Facebook being down is usually a "Layer 8" issue. (Layer 8 being the Human involved ;) From leen at consolejunkie.net Thu Oct 7 18:00:46 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Fri, 08 Oct 2010 01:00:46 +0200 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: References: <35125.1286402505@tristatelogic.com> <20101007031224.GA10137@gsp.org> <81349.1286459069@localhost> Message-ID: <4CAE511E.9090205@consolejunkie.net> On 10/07/2010 04:16 PM, Sven Olaf Kamphuis wrote: > you just give contacts for the passwords with which you have received > a new one. > Hi Sven/others, This very much sounds like TMDA: http://tmda.net/ http://en.wikipedia.org/wiki/Tagged_Message_Delivery_Agent Where by each person that needs to contact you, you give a unique e-mail address. So you give out key1 at domain.tld to user1 and key2 at domain.tld to user2. That way when you registered at that webshop or mailinglist and that e-mail address gets used for spam, you just delete that one unique key (and maybe, if you still want to communicate with them, a new unique key). There are 2 variants if I remember correctly: key at domain.tld for when you have a personal domain key-user at domain.tld for when you have a server which understand address extensions While there is software for that, I've been doing something similair to this by hand for a long time for a lot of contacts. The good thing about using a unique e-mail address instead of a password is that you can block at the SMTP-level, without even receiving an e-mail body. Have a nice day, Leen. > each potential person that can send email to your email address, gets > a unique password from you. > > sending person/maillist 1 gets password abcdefg to send to > bla at example.com (no matter from which email address) > > sending person/maillist 2 gets password 123545 to send to > bla at example.com (no matter from which email address) > > email clients should be modified to include the password: field both > in the email itself and in the header entry field (to: from: subjecT: > or just store them together with the destination address in the > address book > > mailservers (the maildrop part) should be modified to parse the > Password: header, compare it to the list of currently allowed > passwords for the destination email address and then either drop to > the mailbox, or bounce. (we did this in our test setup by simply > parsing the entire email, so the password could be -anywhere- in the > email :P > > ofcourse the Password: line should be only sent to the recipient, not > to other Cc: or Bcc: target addresses of the same email, the first > stmp server in the chain should solve this bit. > > actually, durign our tests, we turned off all the header > verifications, RBL's, etc on our smtpds, and the only spam that got > through were emails that accidentially contained the password string > in a binary attachment (as we parsed the entire email .. we should not > do that, just teh Password: line in the final version :P and stuff > where we gave, for example, nanog, the password "nanog" and then nanog > is cc'ed in a spam > both of which cases can be solved with the standardization of the > Password: field > > once this is in place, all smtpds can go open relay again, port 25 can > be opened again on eyeball networks, RBLs and graylisting can remain > at home, and the SMTP email system will be 100% spam free and reliable > and real-time. (there are several other features which have been > removed from most smtpds to "stop spam" such as accepting ip addresses > rather than domain names in the target email address, which can then > return) > > all the other stuff never stopped spam, it just made smtp email > unreliable slow and no longer an option for 99% of the things where > email was used for before, and skype, msn and facebook are used for > today. > > this system -does- stop spam, but the disadvantage to this system is > that by implementing it, smtp email is no longer suitable for "initial > contact" > > (well you could ofcourse place passwords in whois and on your website > for your hostmaster/sales box so random people can still make initial > contact over smtp, or simply accept all passwords on those boxes, on > which then there WILL be spam.. ;) > > i'd say, smtp no longer being "open for any random idiot to mail any > other random idiot without knowing each other first" is less of a > disadvantage than taking the whole thing slowly die by making it less > and less attractive as a means of communications (slow, unreliable and > not real-time, and still with spam coming in by the 1000s, which it is > due to "conventional" attempts to stop spam) > > From ben at adversary.org Thu Oct 7 23:38:12 2010 From: ben at adversary.org (Ben McGinnes) Date: Fri, 08 Oct 2010 15:38:12 +1100 Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <4CAE511E.9090205@consolejunkie.net> References: <35125.1286402505@tristatelogic.com> <20101007031224.GA10137@gsp.org> <81349.1286459069@localhost> <4CAE511E.9090205@consolejunkie.net> Message-ID: <4CAEA034.40501@adversary.org> On 8/10/10 10:00 AM, Leen Besselink wrote: > > key at domain.tld for when you have a personal domain > key-user at domain.tld for when you have a server which understand address > extensions Actually I think it's user+key at domain.tld for the second one. At least that's what I've seen for Postfix. Not so sure about other MTAs. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature URL: From mike-nanog at tiedyenetworks.com Fri Oct 8 00:07:22 2010 From: mike-nanog at tiedyenetworks.com (Mike) Date: Thu, 07 Oct 2010 22:07:22 -0700 Subject: Yahoo! security contact needed Message-ID: <4CAEA70A.9090801@tiedyenetworks.com> Greetings, I need to get a hold of Yahoo! security and the online submission form doesn't seem to work for me. Anyone got a good contact? Thank you. From pelle at hemmop.com Fri Oct 8 01:05:41 2010 From: pelle at hemmop.com (Per Carlson) Date: Fri, 8 Oct 2010 08:05:41 +0200 Subject: P2P link over STM-1 In-Reply-To: <4CAD83B2.9050204@altechstream.rw> References: <4CAD83B2.9050204@altechstream.rw> Message-ID: If it's a full STM-1, your client might be thinking of POS (packet over sonet/sdh). This is (were) a very common high bandwidth technology some years ago. At least the 7200 do have cheap POS interfaces. -- Pelle (sorry about the top-posting, I'm on a mobile device) From bonomi at mail.r-bonomi.com Fri Oct 8 03:55:13 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Fri, 8 Oct 2010 03:55:13 -0500 (CDT) Subject: New hijacking - Done via via good old-fashioned Identity Theft Message-ID: <201010080855.o988tDIR027803@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Thu Oct 7 23:37:29 2010 > Date: Fri, 08 Oct 2010 15:38:12 +1100 > From: Ben McGinnes > To: Leen Besselink > Subject: Re: New hijacking - Done via via good old-fashioned Identity Theft > Cc: nanog at nanog.org > > This is an OpenPGP/MIME signed message (RFC 2440 and 3156) > --------------enigE085D76E6AF9BB6CCE824E1F > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > On 8/10/10 10:00 AM, Leen Besselink wrote: > >=20 > > key at domain.tld for when you have a personal domain > > key-user at domain.tld for when you have a server which understand address= > > > extensions > > Actually I think it's user+key at domain.tld for the second one. At least > that's what I've seen for Postfix. Not so sure about other MTAs. SendmMail 'invented' the 'plussed' extenstion to an address. Other MTAs mimic SendMail's behavior The '+key' is ignored for purposes of selecting the delivery mailbox username+anything gets handed to the LDA for final delivery to mailbox 'username',, _with_ the 'plus part' (i.e. 'anything, from above) available as an extra parameter. To selectively accept/discard on the plussed portion of the address, you either do it in th LDA (procmail, for example, makes this really easy), or you have to run a 'milter' that knows which plussed parts are valid for which users. For a mailserver that does -not- understand 'plussed' addresses, you can usually fake it out by putting the key as an extra elemnt of the host-name. e.g. user at key.some.dom.ain.tld. AFAIK eveery MTA accepts mail with a more-specific name than a name it has been explicitly told to accept (either for local delivry, or for forwarding) mail for. From jgreco at ns.sol.net Fri Oct 8 08:00:30 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Fri, 8 Oct 2010 08:00:30 -0500 (CDT) Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <4CAE511E.9090205@consolejunkie.net> Message-ID: <201010081300.o98D0VJX041598@aurora.sol.net> > On 10/07/2010 04:16 PM, Sven Olaf Kamphuis wrote: > > you just give contacts for the passwords with which you have received > > a new one. > > Hi Sven/others, > > This very much sounds like TMDA: > > http://tmda.net/ > http://en.wikipedia.org/wiki/Tagged_Message_Delivery_Agent > > Where by each person that needs to contact you, you give a unique e-mail > address. > > So you give out key1 at domain.tld to user1 and key2 at domain.tld to user2. That's a good start, but for general use, if I'm handing out an address like "sven at jgreco.net" to Sven, and "leen at jgreco.net" to Leen, the real problem here is predictability. If Sven is a bad guy, he can cause trouble by guessing that I'd use "leen at jgreco.net" for Leen and proceed to pass that address out to spammers, making Leen look like a bad guy. That particular problem is reduced by generating random tokens for the LHS, however, doing so introduces new problems, such as the fact that "23ycs7ia877oij at jgreco.net" is no longer obviously associated with Sven. I've been very successfully using a much better tagging system here. Take a user-specified identifier, such as, say, "sven". You run this through a one-way crypto function, such as MD5: md5=`echo "${1}/SomeMagicSecret" | md5` f8=`echo "${md5}" | sed "s:^\(........\).*:\1:"` echo "${1}@${f8}.demo.jgreco.net" This results in something like nanog at e6ecd2ea.demo.jgreco.net Now this has a bunch of interesting properties. 1) You make *.demo.jgreco.net a DNS wildcard zone that is rewritten to your actual mailbox address. If and when a problematic address is issued, you can add at the DNS level an MX (or whatever nasty you prefer) for the particular domain name that's troubling you; for example, set e6ecd2ea.demo.jgreco.net to NS from 127.0.0.1. Never even touches the mail server. Of course MTA or procmail deny works too. 2) By using a separate zone, it makes it trivial to configure your mail system so that these addresses blow completely by any normal spam filtering; the problem of false positives for things like transactional e-mail that spam filters often find "spammy" vanishes completely. 3) You need not keep a database of valid tokens; you can simply re-validate the LHS in Procmail. This means that you can do things like write a mobile app or web app that doesn't have to have access to your mail server's innards. The primary downside is that you need some way to compute the crypto-signed bit. 4) You can keep a database of issued tokens along with when and why they were issued. 5) If you make it a habit of using a LHS that's descriptive, it's hard for a sender to argue that the tag was not assigned to them. It's particularly entertaining for things like e-pending because it will reveal which companies you will no longer choose to do business with. This turns out to be very powerful and very flexible. It can be extended to include functionality such as single-use addresses or limited-age addresses, etc. The big trick is to leverage the e-mail address field itself rather than trying to add a password or something like that in the body. ... 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 carlosm3011 at gmail.com Fri Oct 8 09:02:05 2010 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Fri, 8 Oct 2010 10:02:05 -0400 Subject: P2P link over STM-1 In-Reply-To: References: <4CAD83B2.9050204@altechstream.rw> Message-ID: In addition, you can use either PPP or HDLC as L2 over POS. On Fri, Oct 8, 2010 at 2:05 AM, Per Carlson wrote: > If it's a full STM-1, your client might be thinking of POS (packet over > sonet/sdh). This is (were) a very common high bandwidth technology some > years ago. > > At least the 7200 do have cheap POS interfaces. > -- > Pelle > (sorry about the top-posting, I'm on a mobile device) > -- -- ========================= Carlos M. Martinez-Cagnazzo http://cagnazzo.name ========================= From cscora at apnic.net Fri Oct 8 14:12:02 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 9 Oct 2010 05:12:02 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201010081912.o98JC2qt005943@thyme.apnic.net> This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-stats at lists.apnic.net For historical data, please see http://thyme.apnic.net. If you have any comments please contact Philip Smith . Routing Table Report 04:00 +10GMT Sat 09 Oct, 2010 Report Website: http://thyme.apnic.net Detailed Analysis: http://thyme.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 332924 Prefixes after maximum aggregation: 152886 Deaggregation factor: 2.18 Unique aggregates announced to Internet: 163608 Total ASes present in the Internet Routing Table: 34937 Prefixes per ASN: 9.53 Origin-only ASes present in the Internet Routing Table: 30306 Origin ASes announcing only one prefix: 14711 Transit ASes present in the Internet Routing Table: 4631 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 3825 Unregistered ASNs in the Routing Table: 1691 Number of 32-bit ASNs allocated by the RIRs: 809 Prefixes from 32-bit ASNs in the Routing Table: 1141 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 217 Number of addresses announced to Internet: 2278375680 Equivalent to 135 /8s, 205 /16s and 65 /24s Percentage of available address space announced: 61.5 Percentage of allocated address space announced: 65.6 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 85.1 Total number of prefixes smaller than registry allocations: 136876 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 81350 Total APNIC prefixes after maximum aggregation: 27868 APNIC Deaggregation factor: 2.92 Prefixes being announced from the APNIC address blocks: 78281 Unique aggregates announced from the APNIC address blocks: 34323 APNIC Region origin ASes present in the Internet Routing Table: 4200 APNIC Prefixes per ASN: 18.64 APNIC Region origin ASes announcing only one prefix: 1172 APNIC Region transit ASes present in the Internet Routing Table: 647 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 551177312 Equivalent to 32 /8s, 218 /16s and 76 /24s Percentage of available APNIC address space announced: 78.2 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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: 135954 Total ARIN prefixes after maximum aggregation: 70173 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108553 Unique aggregates announced from the ARIN address blocks: 43351 ARIN Region origin ASes present in the Internet Routing Table: 13936 ARIN Prefixes per ASN: 7.79 ARIN Region origin ASes announcing only one prefix: 5326 ARIN Region transit ASes present in the Internet Routing Table: 1381 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 737000992 Equivalent to 43 /8s, 237 /16s and 190 /24s Percentage of available ARIN address space announced: 62.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 76620 Total RIPE prefixes after maximum aggregation: 44371 RIPE Deaggregation factor: 1.73 Prefixes being announced from the RIPE address blocks: 70070 Unique aggregates announced from the RIPE address blocks: 45843 RIPE Region origin ASes present in the Internet Routing Table: 14868 RIPE Prefixes per ASN: 4.71 RIPE Region origin ASes announcing only one prefix: 7661 RIPE Region transit ASes present in the Internet Routing Table: 2235 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 440693376 Equivalent to 26 /8s, 68 /16s and 114 /24s Percentage of available RIPE address space announced: 77.3 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 30164 Total LACNIC prefixes after maximum aggregation: 7163 LACNIC Deaggregation factor: 4.21 Prefixes being announced from the LACNIC address blocks: 28958 Unique aggregates announced from the LACNIC address blocks: 15115 LACNIC Region origin ASes present in the Internet Routing Table: 1361 LACNIC Prefixes per ASN: 21.28 LACNIC Region origin ASes announcing only one prefix: 429 LACNIC Region transit ASes present in the Internet Routing Table: 235 Average LACNIC Region AS path length visible: 3.9 Max LACNIC Region AS path length visible: 17 Number of LACNIC addresses announced to Internet: 76059264 Equivalent to 4 /8s, 136 /16s and 146 /24s Percentage of available LACNIC address space announced: 56.7 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7442 Total AfriNIC prefixes after maximum aggregation: 1892 AfriNIC Deaggregation factor: 3.93 Prefixes being announced from the AfriNIC address blocks: 5735 Unique aggregates announced from the AfriNIC address blocks: 1696 AfriNIC Region origin ASes present in the Internet Routing Table: 406 AfriNIC Prefixes per ASN: 14.13 AfriNIC Region origin ASes announcing only one prefix: 123 AfriNIC Region transit ASes present in the Internet Routing Table: 92 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 17 Number of AfriNIC addresses announced to Internet: 20856320 Equivalent to 1 /8s, 62 /16s and 62 /24s Percentage of available AfriNIC address space announced: 62.2 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1865 9437 510 Korea Telecom (KIX) 7545 1412 297 82 TPG Internet Pty Ltd 4755 1367 380 158 TATA Communications formerly 17488 1360 156 122 Hathway IP Over Cable Interne 17974 1258 302 79 PT TELEKOMUNIKASI INDONESIA 24560 1045 303 180 Bharti Airtel Ltd., Telemedia 9583 1033 77 497 Sify Limited 4808 936 1714 261 CNCGROUP IP network: China169 18101 885 100 132 Reliance Infocom Ltd Internet 9829 816 692 33 BSNL National Internet Backbo Complete listing at http://thyme.apnic.net/current/data-ASnet-APNIC ARIN Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3774 3667 278 bellsouth.net, inc. 4323 2612 1108 390 Time Warner Telecom 1785 1795 698 131 PaeTec Communications, Inc. 19262 1779 4833 279 Verizon Global Networks 20115 1501 1519 649 Charter Communications 7018 1468 5729 941 AT&T WorldNet Services 6478 1368 277 109 AT&T Worldnet Services 2386 1309 555 923 AT&T Data Communications Serv 11492 1222 230 71 Cable One 22773 1204 2858 61 Cox Communications, Inc. Complete listing at http://thyme.apnic.net/current/data-ASnet-ARIN RIPE Region per AS prefix count summary --------------------------------------- ASN No of nets /20 equiv MaxAgg Description 3292 450 2028 391 TDC Tele Danmark 8866 419 119 24 Bulgarian Telecommunication C 702 404 1869 318 UUNET - Commercial IP service 8551 402 353 46 Bezeq International 34984 379 91 186 BILISIM TELEKOM 3301 378 1688 334 TeliaNet Sweden 3320 377 7329 328 Deutsche Telekom AG 30890 374 79 203 Evolva Telecom 12479 372 576 5 Uni2 Autonomous System 31148 353 19 77 FreeNet ISP Complete listing at http://thyme.apnic.net/current/data-ASnet-RIPE LACNIC Region per AS prefix count summary ----------------------------------------- ASN No of nets /20 equiv MaxAgg Description 8151 1342 2571 368 UniNet S.A. de C.V. 10620 1333 247 150 TVCABLE BOGOTA 28573 1175 909 87 NET Servicos de Comunicao S.A 7303 805 440 90 Telecom Argentina Stet-France 6503 759 223 259 AVANTEL, S.A. 27947 566 64 92 Telconet S.A 22047 558 310 15 VTR PUNTO NET S.A. 14420 540 39 78 CORPORACION NACIONAL DE TELEC 3816 484 210 95 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A Complete listing at http://thyme.apnic.net/current/data-ASnet-LACNIC AfriNIC Region per AS prefix count summary ------------------------------------------ ASN No of nets /20 equiv MaxAgg Description 8452 1046 445 10 TEDATA 24863 738 147 39 LINKdotNET AS number 36992 651 279 174 Etisalat MISR 3741 266 906 224 The Internet Solution 6713 203 199 12 Itissalat Al-MAGHRIB 29571 203 19 11 Ci Telecom Autonomous system 2018 197 277 64 Tertiary Education Network 33776 196 12 14 Starcomms Nigeria Limited 16637 170 440 92 MTN Network Solutions 24835 165 78 9 RAYA Telecom - Egypt Complete listing at http://thyme.apnic.net/current/data-ASnet-AFRINIC Global Per AS prefix count summary ---------------------------------- ASN No of nets /20 equiv MaxAgg Description 6389 3774 3667 278 bellsouth.net, inc. 4323 2612 1108 390 Time Warner Telecom 4766 1865 9437 510 Korea Telecom (KIX) 1785 1795 698 131 PaeTec Communications, Inc. 19262 1779 4833 279 Verizon Global Networks 20115 1501 1519 649 Charter Communications 7018 1468 5729 941 AT&T WorldNet Services 7545 1412 297 82 TPG Internet Pty Ltd 6478 1368 277 109 AT&T Worldnet Services 4755 1367 380 158 TATA Communications formerly Complete listing at http://thyme.apnic.net/current/data-ASnet Global Per AS Maximum Aggr summary ---------------------------------- ASN No of nets Net Savings Description 4323 2612 2222 Time Warner Telecom 1785 1795 1664 PaeTec Communications, Inc. 19262 1779 1500 Verizon Global Networks 4766 1865 1355 Korea Telecom (KIX) 7545 1412 1330 TPG Internet Pty Ltd 6478 1368 1259 AT&T Worldnet Services 17488 1360 1238 Hathway IP Over Cable Interne 4755 1367 1209 TATA Communications formerly 10620 1333 1183 TVCABLE BOGOTA 17974 1258 1179 PT TELEKOMUNIKASI INDONESIA Complete listing at http://thyme.apnic.net/current/data-CIDRnet List of Unregistered Origin ASNs (Global) ----------------------------------------- Bad AS Designation Network Transit AS Description 40331 UNALLOCATED 8.11.167.0/24 7018 AT&T WorldNet Servic 11946 UNALLOCATED 8.12.155.0/24 40913 Quality Technology S 15040 UNALLOCATED 8.12.156.0/24 3356 Level 3 Communicatio 53317 UNALLOCATED 8.14.38.0/24 3356 Level 3 Communicatio 33084 UNALLOCATED 8.15.195.0/24 3356 Level 3 Communicatio 18826 UNALLOCATED 8.17.208.0/20 2828 XO Communications 16734 UNALLOCATED 8.18.204.0/24 26914 Global Netoptex, Inc 53562 UNALLOCATED 8.19.94.0/24 3356 Level 3 Communicatio 23200 UNALLOCATED 8.20.243.0/24 25653 Pegasus Web Technolo 22015 UNALLOCATED 8.22.137.0/24 14989 Broadview Networks Complete listing at http://thyme.apnic.net/current/data-badAS Advertised Unallocated Addresses -------------------------------- Network Origin AS Description 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 41.223.196.0/24 36990 Alkan Telecom Ltd 41.223.197.0/24 36990 Alkan Telecom Ltd 41.223.198.0/24 36990 Alkan Telecom Ltd 41.223.199.0/24 36990 Alkan Telecom Ltd 46.16.160.0/24 43584 RIPE Network Coordination Cen Complete listing at http://thyme.apnic.net/current/data-add-IANA Number of prefixes announced per prefix length (Global) ------------------------------------------------------- /1:0 /2:0 /3:0 /4:0 /5:0 /6:0 /7:0 /8:19 /9:10 /10:25 /11:67 /12:203 /13:419 /14:733 /15:1327 /16:11300 /17:5483 /18:9304 /19:18494 /20:23668 /21:23842 /22:31149 /23:30417 /24:173673 /25:983 /26:1080 /27:564 /28:143 /29:12 /30:2 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2337 3774 bellsouth.net, inc. 4323 1408 2612 Time Warner Telecom 6478 1332 1368 AT&T Worldnet Services 10620 1221 1333 TVCABLE BOGOTA 11492 1179 1222 Cable One 1785 1075 1795 PaeTec Communications, Inc. 7011 1056 1156 Citizens Utilities 18566 1039 1058 Covad Communications 8452 957 1046 TEDATA 19262 905 1779 Verizon Global Networks Complete listing at http://thyme.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:78 2:17 4:13 8:313 12:2003 13:8 14:33 15:20 16:3 17:9 20:8 24:1379 27:361 31:1 32:61 33:12 38:701 40:97 41:2509 44:3 46:151 47:11 49:4 52:12 55:5 56:2 57:30 58:830 59:501 60:480 61:1087 62:1031 63:1974 64:3738 65:2329 66:4065 67:1847 68:1146 69:2849 70:755 71:375 72:1935 73:2 74:2308 75:288 76:322 77:876 78:696 79:432 80:1042 81:818 82:502 83:459 84:687 85:1039 86:433 87:693 88:323 89:1565 90:106 91:3098 92:437 93:1027 94:1109 95:746 96:385 97:220 98:630 99:32 101:3 108:64 109:715 110:436 111:584 112:293 113:288 114:475 115:603 116:1111 117:655 118:534 119:973 120:203 121:717 122:1565 123:914 124:1230 125:1270 128:227 129:157 130:170 131:559 132:273 133:20 134:207 135:46 136:214 137:140 138:276 139:109 140:478 141:196 142:348 143:384 144:479 145:54 146:428 147:173 148:616 149:305 150:148 151:233 152:295 153:172 154:3 155:368 156:169 157:317 158:113 159:359 160:313 161:190 162:269 163:166 164:422 165:368 166:468 167:418 168:679 169:157 170:708 171:63 172:2 173:1005 174:558 175:176 176:1 177:1 178:534 180:676 181:1 182:235 183:228 184:126 186:733 187:502 188:839 189:823 190:4124 192:5770 193:4739 194:3431 195:2830 196:1192 198:3544 199:3600 200:5408 201:1579 202:8172 203:8316 204:4019 205:2319 206:2542 207:3038 208:3882 209:3482 210:2553 211:1283 212:1762 213:1716 214:667 215:66 216:4786 217:1583 218:491 219:401 220:1168 221:427 222:341 223:51 End of report From cidr-report at potaroo.net Fri Oct 8 17:00:01 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Oct 2010 22:00:01 GMT Subject: BGP Update Report Message-ID: <201010082200.o98M01Of025907@wattle.apnic.net> BGP Update Report Interval: 30-Sep-10 -to- 07-Oct-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS8151 23388 1.5% 9.1 -- Uninet S.A. de C.V. 2 - AS3464 23141 1.5% 525.9 -- ASC-NET - Alabama Supercomputer Network 3 - AS32528 17215 1.1% 2151.9 -- ABBOTT Abbot Labs 4 - AS8452 15644 1.0% 11.0 -- TE-AS TE-AS 5 - AS35931 15579 1.0% 2596.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - AS5536 13583 0.9% 122.4 -- Internet-Egypt 7 - AS23216 10747 0.7% 41.8 -- MEGADATOS S.A. 8 - AS3816 10130 0.7% 20.8 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 9 - AS4771 9846 0.6% 27.7 -- NZTELECOM Netgate 10 - AS33363 9712 0.6% 7.1 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 11 - AS9829 9611 0.6% 11.7 -- BSNL-NIB National Internet Backbone 12 - AS5778 9117 0.6% 52.4 -- EMBARQ-RCMT - Embarq Corporation 13 - AS4323 9027 0.6% 2.0 -- TWTC - tw telecom holdings, inc. 14 - AS5800 8824 0.6% 43.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 15 - AS11830 8556 0.6% 19.8 -- Instituto Costarricense de Electricidad y Telecom. 16 - AS28573 8483 0.6% 7.1 -- NET Servicos de Comunicao S.A. 17 - AS2764 8301 0.5% 22.4 -- AAPT AAPT Limited 18 - AS45464 7811 0.5% 260.4 -- NEXTWEB-AS-AP Room 201, TGU Bldg 19 - AS27738 7674 0.5% 36.7 -- Ecuadortelecom S.A. 20 - AS45595 6750 0.4% 17.7 -- PKTELECOM-AS-PK Pakistan Telecom Company Limited TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS35931 15579 1.0% 2596.5 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 2 - AS32528 17215 1.1% 2151.9 -- ABBOTT Abbot Labs 3 - AS45606 6274 0.4% 1254.8 -- 101GLOBAL-AS-AP 101 Global Co.,Ltd. 4 - AS22753 3478 0.2% 869.5 -- REDHAT-STUTTGART REDHAT Stuttgart 5 - AS44228 5270 0.3% 658.8 -- DATA-AS DATA CoLTD 6 - AS21017 6561 0.4% 656.1 -- VSI-AS VSI AS 7 - AS5311 648 0.0% 648.0 -- DNIC-ASBLK-05120-05376 - DoD Network Information Center 8 - AS13813 1239 0.1% 619.5 -- BROADSOFT-INC-NORTH-AMERICA - BroadSoft, Inc. 9 - AS24035 566 0.0% 566.0 -- MOFA-AS-VN Ministry of Foreign Affairs of Vietnam - MOFA 10 - AS3464 23141 1.5% 525.9 -- ASC-NET - Alabama Supercomputer Network 11 - AS11613 518 0.0% 518.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 12 - AS18163 2053 0.1% 513.2 -- JINJU18163-AS-KR jinju national university 13 - AS29544 644 0.0% 322.0 -- MAURITEL-AS 14 - AS27771 614 0.0% 307.0 -- Instituto Venezolano de Investigaciones Cientificas 15 - AS43634 290 0.0% 290.0 -- YALTA-RS-AS Yalta Radio Systems 16 - AS45598 1396 0.1% 279.2 -- BLUEMEDIACOM-PH Unit 503 5th Floor Net One Center 17 - AS18025 5796 0.4% 276.0 -- ACE-1-WIFI-AS-AP Ace-1 Wifi Network 18 - AS45292 274 0.0% 274.0 -- LIPI-AS-ID Lembaga Ilmu Pengetahuan Indonesia - LIPI 19 - AS45464 7811 0.5% 260.4 -- NEXTWEB-AS-AP Room 201, TGU Bldg 20 - AS27027 520 0.0% 260.0 -- ANBELL ASN-ANBELL TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 129.66.0.0/17 11497 0.7% AS3464 -- ASC-NET - Alabama Supercomputer Network 2 - 129.66.128.0/17 11495 0.7% AS3464 -- ASC-NET - Alabama Supercomputer Network 3 - 63.211.68.0/22 10143 0.6% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - 130.36.34.0/24 8604 0.5% AS32528 -- ABBOTT Abbot Labs 5 - 130.36.35.0/24 8601 0.5% AS32528 -- ABBOTT Abbot Labs 6 - 201.134.18.0/24 6419 0.4% AS8151 -- Uninet S.A. de C.V. 7 - 190.65.228.0/22 6184 0.4% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 8 - 198.140.43.0/24 5349 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 9 - 216.126.136.0/22 3911 0.2% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 10 - 41.238.176.0/23 3595 0.2% AS8452 -- TE-AS TE-AS 11 - 72.31.122.0/24 3541 0.2% AS13343 -- SCRR-13343 - Road Runner HoldCo LLC AS33363 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 12 - 66.187.234.0/24 3474 0.2% AS22753 -- REDHAT-STUTTGART REDHAT Stuttgart 13 - 95.32.192.0/18 3437 0.2% AS21017 -- VSI-AS VSI AS 14 - 206.184.16.0/24 3197 0.2% AS174 -- COGENT Cogent/PSI 15 - 95.32.128.0/18 3094 0.2% AS21017 -- VSI-AS VSI AS 16 - 216.118.245.0/24 2910 0.2% AS25747 -- VSC-SATELLITE-CO - VSC Satellite Co. 17 - 71.44.14.0/23 2308 0.1% AS33363 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 18 - 72.31.98.0/24 2282 0.1% AS13343 -- SCRR-13343 - Road Runner HoldCo LLC AS33363 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 19 - 202.92.235.0/24 2099 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 20 - 200.50.174.0/24 1891 0.1% AS10697 -- Interlink S.R.L. 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 Oct 8 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 8 Oct 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201010082200.o98M005S025902@wattle.apnic.net> This report has been generated at Fri Oct 8 21:11:50 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 01-10-10 337368 208491 02-10-10 337924 208506 03-10-10 337877 208789 04-10-10 337819 208799 05-10-10 337616 209221 06-10-10 338174 209629 07-10-10 338124 209707 08-10-10 338202 209567 AS Summary 35577 Number of ASes in routing system 15168 Number of ASes announcing only one prefix 4486 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 96837376 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'). --- 08Oct10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 338232 209580 128652 38.0% All ASes AS6389 3774 282 3492 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4486 1984 2502 55.8% TWTC - tw telecom holdings, inc. AS19262 1779 279 1500 84.3% VZGNI-TRANSIT - Verizon Online LLC AS4766 1865 525 1340 71.8% KIXS-AS-KR Korea Telecom AS22773 1204 66 1138 94.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1367 285 1082 79.2% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1360 308 1052 77.4% HATHWAY-NET-AP Hathway IP Over Cable Internet AS5668 1063 93 970 91.3% AS-5668 - CenturyTel Internet Holdings, Inc. AS10620 1333 376 957 71.8% Telmex Colombia S.A. AS6478 1368 427 941 68.8% ATT-INTERNET3 - AT&T Services, Inc. AS18566 1058 175 883 83.5% COVAD - Covad Communications Co. AS1785 1794 1012 782 43.6% AS-PAETEC-NET - PaeTec Communications, Inc. AS7545 1418 696 722 50.9% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 799 101 698 87.4% Telecom Argentina S.A. AS8452 1046 371 675 64.5% TE-AS TE-AS AS8151 1342 690 652 48.6% Uninet S.A. de C.V. AS33363 1376 736 640 46.5% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS18101 885 249 636 71.9% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS4808 936 303 633 67.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS28573 1175 604 571 48.6% NET Servicos de Comunicao S.A. AS7552 650 120 530 81.5% VIETEL-AS-AP Vietel Corporation AS4780 707 182 525 74.3% SEEDNET Digital United Inc. AS7018 1470 945 525 35.7% ATT-INTERNET4 - AT&T Services, Inc. AS17676 606 82 524 86.5% GIGAINFRA Softbank BB Corp. AS24560 1045 523 522 50.0% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 575 75 500 87.0% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 1156 668 488 42.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 558 82 476 85.3% VTR BANDA ANCHA S.A. AS4804 665 205 460 69.2% MPX-AS Microplex PTY LTD AS36992 651 196 455 69.9% ETISALAT-MISR Total 39511 12640 26871 68.0% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 41.223.196.0/24 AS36990 41.223.197.0/24 AS36990 41.223.198.0/24 AS36990 41.223.199.0/24 AS36990 62.61.220.0/24 AS24974 TACHYON-EU Tachyon Europe BV 62.61.221.0/24 AS24974 TACHYON-EU Tachyon Europe BV 64.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 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.234.0.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, 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. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.160.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 96.47.48.0/20 AS3257 TINET-BACKBONE Tinet SpA 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. 114.142.160.0/21 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.160.0/22 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.168.0/21 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.168.0/23 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.171.0/24 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.172.0/24 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 115.42.0.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.5.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.6.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.11.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.20.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.29.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.31.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.43.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 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 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 173.225.112.0/20 AS3257 TINET-BACKBONE Tinet SpA 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 180.94.34.0/23 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.52.33.0/24 AS55536 MIHK-HK ------------------------------- 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.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.174.125.128/26 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.98.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.99.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.103.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.175.110.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication 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 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 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.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.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 209.236.96.0/20 AS3257 TINET-BACKBONE Tinet SpA 210.5.128.0/20 AS4837 CHINA169-BACKBONE CNCGROUP China169 Backbone 210.56.150.0/23 AS38138 INTECH-TRANSIT-BD InTech Online Limited, INTERNET SERVICE LIMITED 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 212.35.160.0/19 AS12369 212.35.160.0/20 AS12369 212.35.174.0/24 AS12369 212.35.176.0/20 AS12369 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 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.47.32.0/20 AS3257 TINET-BACKBONE Tinet SpA 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From leo.woltz at gmail.com Sat Oct 9 03:22:25 2010 From: leo.woltz at gmail.com (Leo Woltz) Date: Sat, 9 Oct 2010 04:22:25 -0400 Subject: Equinix MPLS connectivity Message-ID: We are looking for some MPLS connectivity between Equinix Ashburn and Equinix San Jose who would the group recommend? From sfischer1967 at gmail.com Sat Oct 9 05:22:59 2010 From: sfischer1967 at gmail.com (Steven Fischer) Date: Sat, 9 Oct 2010 06:22:59 -0400 Subject: Equinix MPLS connectivity In-Reply-To: References: Message-ID: as much contempt as I have at times for Verizon, they've not been a bad carrier with respect to reliability. Our MPLS cloud has been pretty stable On Sat, Oct 9, 2010 at 4:22 AM, Leo Woltz wrote: > We are looking for some MPLS connectivity between Equinix Ashburn and > Equinix San Jose who would the group recommend? > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From morrowc.lists at gmail.com Sat Oct 9 09:24:16 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 9 Oct 2010 10:24:16 -0400 Subject: Equinix MPLS connectivity In-Reply-To: References: Message-ID: On Sat, Oct 9, 2010 at 4:22 AM, Leo Woltz wrote: > We are looking for some MPLS connectivity between Equinix Ashburn ?and > Equinix San Jose ?who would the group recommend? why not just buy a wave on someone's dwdm system? (why mpls, I suppose, for what sounds like a ptp application) From brandon.kim at brandontek.com Sat Oct 9 09:39:21 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sat, 9 Oct 2010 10:39:21 -0400 Subject: Equinix MPLS connectivity In-Reply-To: References: , Message-ID: Hi Leo: Just trying to understand the lingo. What do you mean by buying a "wave" on someone's dwdm system? And what is dwdm? Thanks for the heads up! > Date: Sat, 9 Oct 2010 10:24:16 -0400 > Subject: Re: Equinix MPLS connectivity > From: morrowc.lists at gmail.com > To: leo.woltz at gmail.com > CC: nanog at nanog.org > > On Sat, Oct 9, 2010 at 4:22 AM, Leo Woltz wrote: > > We are looking for some MPLS connectivity between Equinix Ashburn and > > Equinix San Jose who would the group recommend? > > why not just buy a wave on someone's dwdm system? (why mpls, I > suppose, for what sounds like a ptp application) > From morrowc.lists at gmail.com Sat Oct 9 11:12:16 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 9 Oct 2010 12:12:16 -0400 Subject: Equinix MPLS connectivity In-Reply-To: References: Message-ID: On Sat, Oct 9, 2010 at 10:39 AM, Brandon Kim wrote: > Hi Leo: since you are addressing my comment, probably you meant 'chris' there... > Just trying to understand the lingo. What do you mean by buying a "wave" on > someone's dwdm system? And what is dwdm? 'wave' - wavelength, one optical path (though a single wavelength used not many) 'dwdm' - dense wave division multiplexing, many optical transport systems today multiplex different optical wavelengths on a single fiber. Most optical transport vendors will sell you one wavelength from point to point on their system, or many waves if you need more than one wave's capacity. -chris > > Thanks for the heads up! > > > >> Date: Sat, 9 Oct 2010 10:24:16 -0400 >> Subject: Re: Equinix MPLS connectivity >> From: morrowc.lists at gmail.com >> To: leo.woltz at gmail.com >> CC: nanog at nanog.org >> >> On Sat, Oct 9, 2010 at 4:22 AM, Leo Woltz wrote: >> > We are looking for some MPLS connectivity between Equinix Ashburn ?and >> > Equinix San Jose ?who would the group recommend? >> >> why not just buy a wave on someone's dwdm system? (why mpls, I >> suppose, for what sounds like a ptp application) >> > From jared at puck.nether.net Sat Oct 9 11:27:55 2010 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 9 Oct 2010 12:27:55 -0400 Subject: Equinix MPLS connectivity In-Reply-To: References: Message-ID: I assume you mean some l2 circuit. That is something we can do here at ntt. www.us.ntt.net should get you to the right place. Jared Mauch On Oct 9, 2010, at 4:22 AM, Leo Woltz wrote: > We are looking for some MPLS connectivity between Equinix Ashburn and > Equinix San Jose who would the group recommend? From brandon.kim at brandontek.com Sat Oct 9 11:56:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sat, 9 Oct 2010 12:56:51 -0400 Subject: Equinix MPLS connectivity In-Reply-To: References: , , , Message-ID: My apologies! I was still finishing up my morning coffee so it hasn't kicked in yet..... Thank you for the explanation however! =) > Date: Sat, 9 Oct 2010 12:12:16 -0400 > Subject: Re: Equinix MPLS connectivity > From: morrowc.lists at gmail.com > To: brandon.kim at brandontek.com > CC: leo.woltz at gmail.com; nanog at nanog.org > > On Sat, Oct 9, 2010 at 10:39 AM, Brandon Kim wrote: > > Hi Leo: > > since you are addressing my comment, probably you meant 'chris' there... > > > Just trying to understand the lingo. What do you mean by buying a "wave" on > > someone's dwdm system? And what is dwdm? > > 'wave' - wavelength, one optical path (though a single wavelength used not many) > 'dwdm' - dense wave division multiplexing, many optical transport > systems today multiplex different optical wavelengths on a single > fiber. Most optical transport vendors will sell you one wavelength > from point to point on their system, or many waves if you need more > than one wave's capacity. > > -chris > > > > > Thanks for the heads up! > > > > > > > >> Date: Sat, 9 Oct 2010 10:24:16 -0400 > >> Subject: Re: Equinix MPLS connectivity > >> From: morrowc.lists at gmail.com > >> To: leo.woltz at gmail.com > >> CC: nanog at nanog.org > >> > >> On Sat, Oct 9, 2010 at 4:22 AM, Leo Woltz wrote: > >> > We are looking for some MPLS connectivity between Equinix Ashburn and > >> > Equinix San Jose who would the group recommend? > >> > >> why not just buy a wave on someone's dwdm system? (why mpls, I > >> suppose, for what sounds like a ptp application) > >> > > From ras at e-gerbil.net Sat Oct 9 12:49:27 2010 From: ras at e-gerbil.net (Richard A Steenbegen) Date: Sat, 9 Oct 2010 12:49:27 -0500 Subject: Equinix MPLS connectivity In-Reply-To: References: Message-ID: <20101009174927.GB1949@gerbil.cluepon.net> On Sat, Oct 09, 2010 at 10:24:16AM -0400, Christopher Morrow wrote: > why not just buy a wave on someone's dwdm system? (why mpls, I > suppose, for what sounds like a ptp application) The native wavelength for most longhaul DWDM systems is 10G, and not everybody needs to buy bandwidth in 10Gbps increments. Waves are also unprotected, and you're expected to buy multiple diverse paths and manage your own protection if you'd like the service to stay up. In this type of situation, where the customer doesn't have much economy of scale and needs to buy 2x10G of waves just to get 10G of protected bandwidth, MPLS transport can often be a cheaper, more reliable, and more flexible solution, even for point to point applications between major points on commodity routes. In this particular scenario, if they need less than say 4-5 Gbps, need to be burstable, or are after specific latency and/or protection goals, MPLS would probably be a clear winner over waves. But note that I still have enough shame not to spam the list with pointers to the MPLS transport services my company offers. :) -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From sven at cb3rob.net Sat Oct 9 18:42:48 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Sat, 9 Oct 2010 23:42:48 +0000 (UTC) Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: <201010081300.o98D0VJX041598@aurora.sol.net> References: <201010081300.o98D0VJX041598@aurora.sol.net> Message-ID: no, not the email address is the key, rather a unique string issued by the receiver to each potentuial sender. the email address does not stop spam originating from lets say, hacked windows boxes. -- 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 ========================================================================= 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. On Fri, 8 Oct 2010, Joe Greco wrote: >> On 10/07/2010 04:16 PM, Sven Olaf Kamphuis wrote: >>> you just give contacts for the passwords with which you have received >>> a new one. >> >> Hi Sven/others, >> >> This very much sounds like TMDA: >> >> http://tmda.net/ >> http://en.wikipedia.org/wiki/Tagged_Message_Delivery_Agent >> >> Where by each person that needs to contact you, you give a unique e-mail >> address. >> >> So you give out key1 at domain.tld to user1 and key2 at domain.tld to user2. > > That's a good start, but for general use, if I'm handing out an > address like "sven at jgreco.net" to Sven, and "leen at jgreco.net" to Leen, > the real problem here is predictability. If Sven is a bad guy, he > can cause trouble by guessing that I'd use "leen at jgreco.net" for Leen > and proceed to pass that address out to spammers, making Leen look like > a bad guy. > > That particular problem is reduced by generating random tokens for the > LHS, however, doing so introduces new problems, such as the fact that > "23ycs7ia877oij at jgreco.net" is no longer obviously associated with Sven. > > I've been very successfully using a much better tagging system here. > > Take a user-specified identifier, such as, say, "sven". > > You run this through a one-way crypto function, such as MD5: > > md5=`echo "${1}/SomeMagicSecret" | md5` > f8=`echo "${md5}" | sed "s:^\(........\).*:\1:"` > echo "${1}@${f8}.demo.jgreco.net" > > This results in something like > > nanog at e6ecd2ea.demo.jgreco.net > > > Now this has a bunch of interesting properties. > > 1) You make *.demo.jgreco.net a DNS wildcard zone that is rewritten to > your actual mailbox address. > > If and when a problematic address is issued, you can add at the DNS > level an MX (or whatever nasty you prefer) for the particular domain > name that's troubling you; for example, set e6ecd2ea.demo.jgreco.net > to NS from 127.0.0.1. Never even touches the mail server. Of course > MTA or procmail deny works too. > > 2) By using a separate zone, it makes it trivial to configure your mail > system so that these addresses blow completely by any normal spam > filtering; the problem of false positives for things like transactional > e-mail that spam filters often find "spammy" vanishes completely. > > 3) You need not keep a database of valid tokens; you can simply re-validate > the LHS in Procmail. This means that you can do things like write a > mobile app or web app that doesn't have to have access to your mail > server's innards. The primary downside is that you need some way to > compute the crypto-signed bit. > > 4) You can keep a database of issued tokens along with when and why they > were issued. > > 5) If you make it a habit of using a LHS that's descriptive, it's hard > for a sender to argue that the tag was not assigned to them. It's > particularly entertaining for things like e-pending because it will > reveal which companies you will no longer choose to do business with. > > This turns out to be very powerful and very flexible. It can be extended > to include functionality such as single-use addresses or limited-age > addresses, etc. The big trick is to leverage the e-mail address field > itself rather than trying to add a password or something like that in the > body. > > ... 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 ryan.finnesey at HarrierInvestments.com Sat Oct 9 19:08:25 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 9 Oct 2010 17:08:25 -0700 Subject: Mobile Operator Connectivity In-Reply-To: <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> References: <4CA0FAFD.30802@rollernet.us> <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300A6AF@EXVBE005-2.exch005intermedia.net> I have been working on a similar project and I am finding it very hard to get the mobile operators to understand why we want as little latency as possible and they are not very open to people peering with their "wireless" backbone. I hope this will change with more and more eyeballs going wireless. -----Original Message----- From: Holmes,David A [mailto:dholmes at mwdh2o.com] Sent: Monday, September 27, 2010 9:42 PM To: Seth Mattinen; nanog at nanog.org Subject: RE: Mobile Operator Connectivity Some large telcos with wireless and wireline operations in the US maintain 2 separate backbones: one that I call "wired", that corresponds to traditional wired access where commerce servers are usually located; and one that I call a "wireless" backbone, where GSM/CDMA wireless devices are used to aggregate access-layer traffic. Both backbones consist of national fiber-optic, BGP-based networks. Surprisingly, some large telcos have a presence of both wireline and wireless backbones in the same colos, but the 2 backbone networks are interconnected, not in that colo, but at a single geographic location (with perhaps a single hot standby interconnection site), located, for example in northern Virginia. So, the worst case is that if the servers and GSM/CDMA devices are located in Southern California, even though the telco has a wireline and wireless presence in the local LA colo, GSM/CDMA access-layer traffic must traverse the continental US to northern Virginia and back to get to the server. -----Original Message----- From: Seth Mattinen [mailto:sethm at rollernet.us] Sent: Monday, September 27, 2010 1:14 PM To: nanog at nanog.org Subject: Re: Mobile Operator Connectivity On 9/25/2010 13:37, Leo Woltz wrote: > I am looking for some guidance from the list. We will soon be deploying > wireless payment devices (CDMA/GSM). We are looking at options on where to > locate the servers that will run the backend payment gateways; we would like > the least amount of latency between the servers and the wireless networks as > possible. The wireless networks we will be deploying the devices on are: > > > Sprint PCS > For Sprint you can get a circuit to AS1239 and just take customer routes. Their PCS network is AS10507, but as far as I know the closest you can get to it is 1239. ~Seth From ryan.finnesey at HarrierInvestments.com Sat Oct 9 19:08:27 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 9 Oct 2010 17:08:27 -0700 Subject: Mobile Operator Connectivity In-Reply-To: References: <4CA0FAFD.30802@rollernet.us><485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300A6B0@EXVBE005-2.exch005intermedia.net> What is the IPX service? -----Original Message----- From: Jared Geiger [mailto:jared at compuwizz.net] Sent: Tuesday, September 28, 2010 9:58 AM To: nanog at nanog.org Subject: Re: Mobile Operator Connectivity I would suggest getting on the GRX network. As an enterprise you should be able to get IPX service from any number of providers. Belgacom, Syniverse, and Sybase365 all offer IP data service onto the GRX. Then you aren't limited to just the US carriers, you'll be able to reach most all carriers globally. ~Jared From ryan.finnesey at HarrierInvestments.com Sat Oct 9 19:08:28 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 9 Oct 2010 17:08:28 -0700 Subject: Mobile Operator Connectivity In-Reply-To: References: <4CA0FAFD.30802@rollernet.us><485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300A6B1@EXVBE005-2.exch005intermedia.net> I think the service Equinix hosts is for data roaming -----Original Message----- From: Leo Woltz [mailto:leo.woltz at gmail.com] Sent: Tuesday, September 28, 2010 2:16 PM To: Jared Geiger Cc: nanog at nanog.org Subject: Re: Mobile Operator Connectivity Hi Jared Is this different then the service at Equinix? Leo On Tue, Sep 28, 2010 at 9:57 AM, Jared Geiger wrote: > I would suggest getting on the GRX network. As an enterprise you > should be able to get IPX service from any number of providers. > Belgacom, Syniverse, and Sybase365 all offer IP data service onto the > GRX. Then you aren't limited to just the US carriers, you'll be able > to reach most all carriers globally. > > ~Jared > > From ryan.finnesey at HarrierInvestments.com Sat Oct 9 19:08:29 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 9 Oct 2010 17:08:29 -0700 Subject: Mobile Operator Connectivity In-Reply-To: References: <4CA0FAFD.30802@rollernet.us><485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300A6B2@EXVBE005-2.exch005intermedia.net> >From the research I have been doing the only mobile operator I have found open to peering is Vodafone I hope this is helpful. -----Original Message----- From: Cameron Byrne [mailto:cb.list6 at gmail.com] Sent: Tuesday, September 28, 2010 2:33 PM To: Jared Geiger Cc: nanog at nanog.org Subject: Re: Mobile Operator Connectivity On Tue, Sep 28, 2010 at 6:57 AM, Jared Geiger wrote: > I would suggest getting on the GRX network. As an enterprise you > should be able to get IPX service from any number of providers. > Belgacom, Syniverse, and Sybase365 all offer IP data service onto the > GRX. Then you aren't limited to just the US carriers, you'll be able > to reach most all carriers globally. Folks, GRX is for data roaming between mobile providers, not for connecting eye balls and content. Only mobile operators are members of the GRX, not customers of mobile operators or content of any sort. http://en.wikipedia.org/wiki/GPRS_Roaming_Exchange Here's an example, I am a T-Mobile USA subscriber. I travel to Canada and roam on to Rogers's network. When i start a data session on my mobile phone, Rogers passes all the data traffic back to T-Mobile via the GRX peering exchange. When in Canada, my HTTP traffic does not exit in Canada, it is tunneled back via GRX peering to T-Mobile in the USA and exit's in the USA. The roamed into network (Roger's in my example) is just an access network to reach the network that i subscriber to (T-Mobile USA). As someone else may have noted, your best best is to figure out where the mobile providers peer out on the Internet and purchase access in the same region and ISP as the mobile provider. Also, as someone else noted, some mobile providers do a lot of aggregation that adds latency, other mobile providers are more distributed and punt to the ISP closer to the user. Regards, Cameron ======== http://groups.google.com/group/tmoipv6beta ======== From ryan.finnesey at HarrierInvestments.com Sat Oct 9 19:08:30 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 9 Oct 2010 17:08:30 -0700 Subject: Equinix MPLS connectivity In-Reply-To: References: Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300A6B3@EXVBE005-2.exch005intermedia.net> We have been looking into Sprint but one issue we are running into is lack of IPv6 support. So we are looking into Level3 and Global. I think Equinix may also have its own connectivity they can sell you. -----Original Message----- From: Leo Woltz [mailto:leo.woltz at gmail.com] Sent: Saturday, October 09, 2010 4:22 AM To: nanog at nanog.org Subject: Equinix MPLS connectivity We are looking for some MPLS connectivity between Equinix Ashburn and Equinix San Jose who would the group recommend? From jgreco at ns.sol.net Sat Oct 9 19:36:33 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Sat, 9 Oct 2010 19:36:33 -0500 (CDT) Subject: New hijacking - Done via via good old-fashioned Identity Theft In-Reply-To: Message-ID: <201010100036.o9A0aXp2062265@aurora.sol.net> > no, not the email address is the key, rather a unique string > issued by the receiver to each potentuial sender. In the system I describe, the email address *is* "a unique string issued by the receiver to each potent[u]ial sender." This has the charming property of working very well with the existing e-mail system and without having to have each correspondent manage a directory of "key" words for each person they want to correspond with, updates to that directory, etc. > the email address does not stop spam originating from lets say, hacked > windows boxes. No system does. The point is to be able to tell who leaked/abused/etc it, and more importantly, to be able to trivially terminate the sender's ability to use the address, making that entry on their list completely useless, or better yet, annoying them by clogging up their mail server, if you do sufficiently BOFHish things. ... 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 mehmet at icann.org Sat Oct 9 23:16:48 2010 From: mehmet at icann.org (Mehmet Akcin) Date: Sat, 9 Oct 2010 21:16:48 -0700 Subject: Routeviews Message-ID: <8BDBC2FD-C810-4C31-BBFB-96680F718D39@icann.org> hello, anyone from university of oregon or routeviews project ( routeviews.org ) here ? please contact me off-list please. thanks mehmet From sethm at rollernet.us Sat Oct 9 23:38:03 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sat, 09 Oct 2010 21:38:03 -0700 Subject: Equinix MPLS connectivity In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0300A6B3@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC0300A6B3@EXVBE005-2.exch005intermedia.net> Message-ID: <4CB1432B.4010708@rollernet.us> On 10/9/10 5:08 PM, Ryan Finnesey wrote: > We have been looking into Sprint but one issue we are running into is > lack of IPv6 support. So we are looking into Level3 and Global. I > think Equinix may also have its own connectivity they can sell you. > Um, if you order an MPLS connection between two distant sites, doesn't the provider normally (in my experience) just hand you ports that are effectively layer 2? IPvAnything doesn't even factor in. ~Seth From morrowc.lists at gmail.com Sat Oct 9 23:58:02 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 10 Oct 2010 00:58:02 -0400 Subject: Equinix MPLS connectivity In-Reply-To: <4CB1432B.4010708@rollernet.us> References: <6EFFEFBAC68377459A2E972105C759EC0300A6B3@EXVBE005-2.exch005intermedia.net> <4CB1432B.4010708@rollernet.us> Message-ID: On Sun, Oct 10, 2010 at 12:38 AM, Seth Mattinen wrote: > On 10/9/10 5:08 PM, Ryan Finnesey wrote: >> We have been looking into Sprint but one issue we are running into is >> lack of IPv6 support. ?So we are looking into Level3 and Global. ?I >> think Equinix may also have its own connectivity they can sell you. >> > > Um, if you order an MPLS connection between two distant sites, doesn't > the provider normally (in my experience) just hand you ports that are > effectively layer 2? IPvAnything doesn't even factor in. oh, so it occurs to me that when I read the original post I read it as 'mpls network' not 'mpls p2p link', I suppose if the OP was looking for an L2 circuit emulated across an MPLS network ... that's the same thing as a wave (basically) at the customer hand off. -chris From swmike at swm.pp.se Sun Oct 10 01:20:04 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Sun, 10 Oct 2010 08:20:04 +0200 (CEST) Subject: Equinix MPLS connectivity In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC0300A6B3@EXVBE005-2.exch005intermedia.net> <4CB1432B.4010708@rollernet.us> Message-ID: On Sun, 10 Oct 2010, Christopher Morrow wrote: > oh, so it occurs to me that when I read the original post I read it as > 'mpls network' not 'mpls p2p link', I suppose if the OP was looking for > an L2 circuit emulated across an MPLS network ... that's the same thing > as a wave (basically) at the customer hand off. That's why one never should use "MPLS" when talking about customer connections, unless they're actually carriers carrier or something like that. L2 or L3 VPN is fine, that is a service, MPLS is a way to produce that service. Asking for "MPLS connectivity" is just asking for misunderstandings. -- Mikael Abrahamsson email: swmike at swm.pp.se From joelja at bogus.com Sun Oct 10 12:42:08 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 10 Oct 2010 10:42:08 -0700 Subject: Mobile Operator Connectivity In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0300A6AF@EXVBE005-2.exch005intermedia.net> References: <4CA0FAFD.30802@rollernet.us> <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> <6EFFEFBAC68377459A2E972105C759EC0300A6AF@EXVBE005-2.exch005intermedia.net> Message-ID: <4CB1FAF0.5000107@bogus.com> On 10/9/10 5:08 PM, Ryan Finnesey wrote: > I have been working on a similar project and I am finding it very hard > to get the mobile operators to understand why we want as little latency > as possible and they are not very open to people peering with their > "wireless" backbone. Possibly because the way that they tunnel GTP to the GGSN and the locations of GGSN devices relative to the handsets served preclude as little latency as possible. > I hope this will change with more and more > eyeballs going wireless. LTE provides an opportunity to move the bottleneck. > > -----Original Message----- > From: Holmes,David A [mailto:dholmes at mwdh2o.com] > Sent: Monday, September 27, 2010 9:42 PM > To: Seth Mattinen; nanog at nanog.org > Subject: RE: Mobile Operator Connectivity > > Some large telcos with wireless and wireline operations in the US > maintain 2 separate backbones: one that I call "wired", that corresponds > to traditional wired access where commerce servers are usually located; > and one that I call a "wireless" backbone, where GSM/CDMA wireless > devices are used to aggregate access-layer traffic. Both backbones > consist of national fiber-optic, BGP-based networks. Surprisingly, some > large telcos have a presence of both wireline and wireless backbones in > the same colos, but the 2 backbone networks are interconnected, not in > that colo, but at a single geographic location (with perhaps a single > hot standby interconnection site), located, for example in northern > Virginia. > > So, the worst case is that if the servers and GSM/CDMA devices are > located in Southern California, even though the telco has a wireline and > wireless presence in the local LA colo, GSM/CDMA access-layer traffic > must traverse the continental US to northern Virginia and back to get to > the server. > > -----Original Message----- > From: Seth Mattinen [mailto:sethm at rollernet.us] > Sent: Monday, September 27, 2010 1:14 PM > To: nanog at nanog.org > Subject: Re: Mobile Operator Connectivity > > On 9/25/2010 13:37, Leo Woltz wrote: >> I am looking for some guidance from the list. We will soon be > deploying >> wireless payment devices (CDMA/GSM). We are looking at options on > where to >> locate the servers that will run the backend payment gateways; we > would like >> the least amount of latency between the servers and the wireless > networks as >> possible. The wireless networks we will be deploying the devices on > are: >> > >> >> Sprint PCS >> > > For Sprint you can get a circuit to AS1239 and just take customer > routes. Their PCS network is AS10507, but as far as I know the closest > you can get to it is 1239. > > ~Seth > > > > From joelja at bogus.com Sun Oct 10 12:44:41 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 10 Oct 2010 10:44:41 -0700 Subject: Routeviews In-Reply-To: <8BDBC2FD-C810-4C31-BBFB-96680F718D39@icann.org> References: <8BDBC2FD-C810-4C31-BBFB-96680F718D39@icann.org> Message-ID: <4CB1FB89.50802@bogus.com> help at routeviews.org is known to work. joel On 10/9/10 9:16 PM, Mehmet Akcin wrote: > hello, > > anyone from university of oregon or routeviews project ( routeviews.org ) here ? please contact me off-list please. > > thanks > > mehmet > From david.freedman at uk.clara.net Sun Oct 10 13:47:04 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Sun, 10 Oct 2010 19:47:04 +0100 Subject: Internet in DPRK / North Korea Message-ID: http://unplugged.rcrwireless.com/index.php/20101010/news/4100/north-korea-al lows-first-uncensored-net-connections/ And http://thenextweb.com/asia/2010/10/09/north-korea-reportedly-opens-its-first -website-to-the-outside-world/ Perm connection from China Netcom? Does anybody have any more info about this? -- David Freedman Claranet http://www.clara.net From cb.list6 at gmail.com Sun Oct 10 14:38:54 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Sun, 10 Oct 2010 12:38:54 -0700 Subject: Mobile Operator Connectivity In-Reply-To: <4CB1FAF0.5000107@bogus.com> References: <4CA0FAFD.30802@rollernet.us> <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> <6EFFEFBAC68377459A2E972105C759EC0300A6AF@EXVBE005-2.exch005intermedia.net> <4CB1FAF0.5000107@bogus.com> Message-ID: On Sun, Oct 10, 2010 at 10:42 AM, Joel Jaeggli wrote: > On 10/9/10 5:08 PM, Ryan Finnesey wrote: >> I have been working on a similar project and I am finding it very hard >> to get the mobile operators to understand why we want as little latency >> as possible and they are not very open to people peering with their >> "wireless" backbone. > > Possibly because the way that they tunnel GTP to the GGSN and the > locations of GGSN devices relative to the handsets served preclude as > little latency as possible. > Yes. Some mobile providers are more heavily aggregated than others. I have been pushing for decreasing the architectural latency in the mobile architecture with IPv6 http://www.youtube.com/watch?v=1GlRgaFriYU#t=29m45 But there are a lot of roadblocks, some more technical than others. Also, the wireless providers generally don't have a point of presence in the peering NAPs. I have run this business case a few times for my company and it generally is a financial wash, and therefore not worth the effort to deploy and support additional transport and nodes at the peering locations. It's simpler and cheaper to just punt the Internet traffic out of the wireless networks as soon as possible to an ISP, and those ISP frequently own the fiber transport as well. But, like anything, you can always ask your B2B account manager for a special setup. There are special setups that i know for corporate customers. >> I hope this will change with more and more >> eyeballs going wireless. > > LTE provides an opportunity to move the bottleneck. > LTE provides some latency benefits on the wireless interface, but the actual packet core architecture is very similar to GSM / UMTS. For those concerned about latency, the key is working with the wireless operator to find where the mobility aggregation points are and how they are connected to the Internet. More advanced applications at large scale can justify direct peering, but i don't imagine that achieves much real latency benefits over just being properly coordinated with the locations and ISPs. Cameron ======= http://groups.google.com/group/tmoipv6beta ======= From joelja at bogus.com Sun Oct 10 15:39:52 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 10 Oct 2010 13:39:52 -0700 Subject: Mobile Operator Connectivity In-Reply-To: References: <4CA0FAFD.30802@rollernet.us> <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> <6EFFEFBAC68377459A2E972105C759EC0300A6AF@EXVBE005-2.exch005intermedia.net> <4CB1FAF0.5000107@bogus.com> Message-ID: <4CB22498.9020902@bogus.com> On 10/10/10 12:38 PM, Cameron Byrne wrote: > On Sun, Oct 10, 2010 at 10:42 AM, Joel Jaeggli wrote: >> On 10/9/10 5:08 PM, Ryan Finnesey wrote: >> LTE provides an opportunity to move the bottleneck. >> > > LTE provides some latency benefits on the wireless interface, but the > actual packet core architecture is very similar to GSM / UMTS. right, renaming the the GPRS Core Network to SAE doesn't really impart much magic to it. the air interface is certainly better. If the PDN gateways in an LTE deployment are located solely in the same locations as the former GGSNS then yeah your topoly is going to look almost identical. > For those concerned about latency, the key is working with the > wireless operator to find where the mobility aggregation points are > and how they are connected to the Internet. More advanced > applications at large scale can justify direct peering, but i don't > imagine that achieves much real latency benefits over just being > properly coordinated with the locations and ISPs. > > Cameron > ======= > http://groups.google.com/group/tmoipv6beta > ======= > From johnl at iecc.com Sun Oct 10 18:57:42 2010 From: johnl at iecc.com (John Levine) Date: 10 Oct 2010 23:57:42 -0000 Subject: Internet in DPRK / North Korea In-Reply-To: Message-ID: <20101010235742.52964.qmail@joyce.lan> >Perm connection from China Netcom? Does anybody have any more info about >this? http://175.45.179.68/ R's, John From tme at americafree.tv Sun Oct 10 19:09:50 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 10 Oct 2010 20:09:50 -0400 Subject: Internet in DPRK / North Korea In-Reply-To: <20101010235742.52964.qmail@joyce.lan> References: <20101010235742.52964.qmail@joyce.lan> Message-ID: <8A4C3C49-8821-4E8C-A72F-739ED2E6A7F4@americafree.tv> On Oct 10, 2010, at 7:57 PM, John Levine wrote: >> Perm connection from China Netcom? Does anybody have any more info about >> this? > > http://175.45.179.68/ > If that's in the DPRK, you may have "slashdotted" an entire country. Regards Marshall > R's, > John > > From johnl at iecc.com Sun Oct 10 19:38:30 2010 From: johnl at iecc.com (John R. Levine) Date: 10 Oct 2010 20:38:30 -0400 Subject: Internet in DPRK / North Korea In-Reply-To: <8A4C3C49-8821-4E8C-A72F-739ED2E6A7F4@americafree.tv> References: <20101010235742.52964.qmail@joyce.lan> <8A4C3C49-8821-4E8C-A72F-739ED2E6A7F4@americafree.tv> Message-ID: >> http://175.45.179.68/ > > If that's in the DPRK, you may have "slashdotted" an entire country. Ooh. Maybe they'll be thrilled, or maybe they'll figure that it's an attack. Probably both. 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 morrowc.lists at gmail.com Sun Oct 10 19:56:16 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 10 Oct 2010 20:56:16 -0400 Subject: Internet in DPRK / North Korea In-Reply-To: References: <20101010235742.52964.qmail@joyce.lan> <8A4C3C49-8821-4E8C-A72F-739ED2E6A7F4@americafree.tv> Message-ID: On Sun, Oct 10, 2010 at 8:38 PM, John R. Levine wrote: > 175.45.179.68/ once senses that the potential successor wants his twitters and facebooks... From morrowc.lists at gmail.com Sun Oct 10 19:57:10 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 10 Oct 2010 20:57:10 -0400 Subject: Internet in DPRK / North Korea In-Reply-To: References: <20101010235742.52964.qmail@joyce.lan> <8A4C3C49-8821-4E8C-A72F-739ED2E6A7F4@americafree.tv> Message-ID: On Sun, Oct 10, 2010 at 8:56 PM, Christopher Morrow wrote: > On Sun, Oct 10, 2010 at 8:38 PM, John R. Levine wrote: >> 175.45.179.68/ > > > once senses that the potential successor wants his twitters and facebooks... (also nice to see they are rockin' the 4byte asn) From deleskie at gmail.com Sun Oct 10 19:57:48 2010 From: deleskie at gmail.com (jim deleskie) Date: Sun, 10 Oct 2010 21:57:48 -0300 Subject: Internet in DPRK / North Korea In-Reply-To: References: <20101010235742.52964.qmail@joyce.lan> <8A4C3C49-8821-4E8C-A72F-739ED2E6A7F4@americafree.tv> Message-ID: and his 3g's and his wifi's? :) On Sun, Oct 10, 2010 at 9:56 PM, Christopher Morrow wrote: > On Sun, Oct 10, 2010 at 8:38 PM, John R. Levine wrote: > > 175.45.179.68/ > > > once senses that the potential successor wants his twitters and > facebooks... > > From morrowc.lists at gmail.com Sun Oct 10 20:01:29 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 10 Oct 2010 21:01:29 -0400 Subject: Internet in DPRK / North Korea In-Reply-To: References: <20101010235742.52964.qmail@joyce.lan> <8A4C3C49-8821-4E8C-A72F-739ED2E6A7F4@americafree.tv> Message-ID: On Sun, Oct 10, 2010 at 8:57 PM, jim deleskie wrote: > and his 3g's and his wifi's? :) that's just crazy talk. > On Sun, Oct 10, 2010 at 9:56 PM, Christopher Morrow > wrote: >> >> On Sun, Oct 10, 2010 at 8:38 PM, John R. Levine wrote: >> > 175.45.179.68/ >> >> >> once senses that the potential successor wants his twitters and >> facebooks... >> > > From jeffrey.lyon at blacklotus.net Sun Oct 10 23:00:13 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 11 Oct 2010 08:30:13 +0430 Subject: Internet in DPRK / North Korea In-Reply-To: References: <20101010235742.52964.qmail@joyce.lan> <8A4C3C49-8821-4E8C-A72F-739ED2E6A7F4@americafree.tv> Message-ID: I love the hard hitting, unbiased reports. Jeff On Mon, Oct 11, 2010 at 5:31 AM, Christopher Morrow wrote: > On Sun, Oct 10, 2010 at 8:57 PM, jim deleskie wrote: >> and his 3g's and his wifi's? :) > > that's just crazy talk. > >> On Sun, Oct 10, 2010 at 9:56 PM, Christopher Morrow >> wrote: >>> >>> On Sun, Oct 10, 2010 at 8:38 PM, John R. Levine wrote: >>> > 175.45.179.68/ >>> >>> >>> once senses that the potential successor wants his twitters and >>> facebooks... >>> >> >> > > -- 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 kowsik at gmail.com Sun Oct 10 23:58:55 2010 From: kowsik at gmail.com (kowsik) Date: Sun, 10 Oct 2010 21:58:55 -0700 Subject: iPhone, meet Wireshark... Message-ID: If you wanted to see what the apps on your mobile device are up to (especially operators trying to understand the impact of mobile apps on their infrastructure), current instructions on the web involve jail-breaking, setting up access-points and hubs and what not. It's gotta be lot simpler than that. Blog: http://bit.ly/cBFvDd Code: http://github.com/pcapr/l2bridge A couple of things you can do with the packets you capture: . Use http://www.pcapr.net/xtractr to analyze the apps, generate reports and charts and go to town . Be nice and share non-sensitive application traffic back to the pcapr community May the packets be with you! Thanks, The Pcapr Team http://www.pcapr.net/ http://twitter.com/pcapr http://labs.mudynamics.com From jlewis at lewis.org Mon Oct 11 09:23:29 2010 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 11 Oct 2010 10:23:29 -0400 (EDT) Subject: Level3 leaking routes? Message-ID: Has anyone else seen this, starting about midnight EDT last Friday night / Saturday morning? I advertise a few [more specific] routes to Level3 tagged with 65000:0 for TE. This is something that's worked for years. Either some of Level3's peers have become customers, or there's something wrong with Level3's route propagation filters that broke last Friday night. customer traffic engineering communities - Suppression -------------------------------------------------------- 64960:XXX - announce to AS XXX if 65000:0 65000:0 - announce to customers but not to peers 65000:XXX - do not announce at peerings to AS XXX ---------------------------------------------------------------------- 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 Mon Oct 11 09:53:20 2010 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 11 Oct 2010 10:53:20 -0400 (EDT) Subject: neglected route-servers Message-ID: Guess what happens when you run a 7206VXR (NPE300) as a route server with 3 full feeds? It took me a minute to figure out why my routes that TWTelecom isn't supposed to see were showing up on route-server.twtelecom.net, but were seemingly randomly alternating between Network not in table and showing up. If anyone from TWTelecom is here, it's probably time to swap out that NPE300 for something with more than 256MB RAM. It's running out of RAM and resetting all the BGP sessions before they finish getting full routes. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hj1980 at gmail.com Mon Oct 11 10:08:00 2010 From: hj1980 at gmail.com (Heath Jones) Date: Mon, 11 Oct 2010 16:08:00 +0100 Subject: neglected route-servers In-Reply-To: References: Message-ID: > If anyone from TWTelecom is here, it's probably time to swap out that NPE300 > for something with more than 256MB RAM. It's running out of RAM and > resetting all the BGP sessions before they finish getting full routes. And they have CDP turned on for you? From jlewis at lewis.org Mon Oct 11 10:20:57 2010 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 11 Oct 2010 11:20:57 -0400 (EDT) Subject: neglected route-servers In-Reply-To: References: Message-ID: On Mon, 11 Oct 2010, Heath Jones wrote: >> If anyone from TWTelecom is here, it's probably time to swap out that NPE300 >> for something with more than 256MB RAM. It's running out of RAM and >> resetting all the BGP sessions before they finish getting full routes. > > And they have CDP turned on for you? You can telnet into it and watch the sessions come up, the memory run out, and the sessions reset. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hj1980 at gmail.com Mon Oct 11 10:24:40 2010 From: hj1980 at gmail.com (Heath Jones) Date: Mon, 11 Oct 2010 16:24:40 +0100 Subject: neglected route-servers In-Reply-To: References: Message-ID: > You can telnet into it and watch the sessions come up, the memory run out, > and the sessions reset. -smacks self over head with fish- I thought you were referring to your eBGP peer. duh. From deepak at ai.net Mon Oct 11 13:08:53 2010 From: deepak at ai.net (Deepak Jain) Date: Mon, 11 Oct 2010 14:08:53 -0400 Subject: AT&T/L3 interconnect? Message-ID: While jumping on the wagon of poking at a particular 175.x.x.x address, I noticed something in my trace: 10 5 ms 5 ms 5 ms att-level3-30G.washingtondc.level3.net [4.68.62.30] 11 73 ms 72 ms 73 ms cr2.wswdc.ip.att.net [12.122.84.82] 12 74 ms 74 ms 75 ms cr1.cgcil.ip.att.net [12.122.18.21] 13 72 ms 72 ms 72 ms cr2.dvmco.ip.att.net [12.122.31.85] 14 73 ms 72 ms 73 ms cr1.slkut.ip.att.net [12.122.30.25] 15 73 ms 72 ms 72 ms cr2.la2ca.ip.att.net [12.122.30.30] 16 72 ms 72 ms 72 ms cr84.la2ca.ip.att.net [12.123.30.249] 17 73 ms 73 ms 73 ms gar1.lsrca.ip.att.net [12.122.129.121] Does anyone happen to know where the other end of this tunnel is that magically everything from a DC-DC hop to a DC-LA hop are all exactly 73ms? thanks, DJ From adam at davenpro.com Mon Oct 11 13:21:55 2010 From: adam at davenpro.com (Adam Davenport) Date: Mon, 11 Oct 2010 14:21:55 -0400 Subject: AT&T/L3 interconnect? In-Reply-To: References: Message-ID: http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf On Mon, Oct 11, 2010 at 2:08 PM, Deepak Jain wrote: > > While jumping on the wagon of poking at a particular 175.x.x.x address, I > noticed something in my trace: > > 10 5 ms 5 ms 5 ms att-level3-30G.washingtondc.level3.net[4.68.62.30] > 11 73 ms 72 ms 73 ms cr2.wswdc.ip.att.net [12.122.84.82] > 12 74 ms 74 ms 75 ms cr1.cgcil.ip.att.net [12.122.18.21] > 13 72 ms 72 ms 72 ms cr2.dvmco.ip.att.net [12.122.31.85] > 14 73 ms 72 ms 73 ms cr1.slkut.ip.att.net [12.122.30.25] > 15 73 ms 72 ms 72 ms cr2.la2ca.ip.att.net [12.122.30.30] > 16 72 ms 72 ms 72 ms cr84.la2ca.ip.att.net [12.123.30.249] > 17 73 ms 73 ms 73 ms gar1.lsrca.ip.att.net [12.122.129.121] > > Does anyone happen to know where the other end of this tunnel is that > magically everything from a DC-DC hop to a DC-LA hop are all exactly 73ms? > > thanks, > > DJ > > From deepak at ai.net Mon Oct 11 13:48:00 2010 From: deepak at ai.net (Deepak Jain) Date: Mon, 11 Oct 2010 14:48:00 -0400 Subject: AT&T/L3 interconnect? In-Reply-To: References: Message-ID: <4CB35BE0.9050405@ai.net> > http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf I'd have thought I didn't need to provide credentials in NANOG, but apparently one stays quiet too long and you're a noob. First, to those who have given me basic mpls, traceroute and ip primers by off list email, thank you. It's not necessary. I appreciate your willingness to help out the community. Second, I *know* that the traceroute I pasted a bit of has to do with mpls magic (or similar). That's why I used the word tunnel. I wasn't asking *how* it was done. I'm quiet capable of performing the same magic. I just wanted to know if anyone off the top of their head knew *where* the packets were magically popping back into the ether... LA, Nevada, Denver. That's all. A physical location or a router IP would have been a perfectly wonderful answer. Again, thank you (all) for your time. Apologies for the distraction. If you aren't someone who knows this very specific piece of information, my message probably wasn't for you. DJ From ras at e-gerbil.net Mon Oct 11 14:55:52 2010 From: ras at e-gerbil.net (Richard A Steenbergen) Date: Mon, 11 Oct 2010 14:55:52 -0500 Subject: AT&T/L3 interconnect? In-Reply-To: <4CB35BE0.9050405@ai.net> References: <4CB35BE0.9050405@ai.net> Message-ID: <20101011195552.GR1949@gerbil.cluepon.net> On Mon, Oct 11, 2010 at 02:48:00PM -0400, Deepak Jain wrote: > > > http://www.nanog.org/meetings/nanog45/presentations/Sunday/RAS_traceroute_N45.pdf > > I'd have thought I didn't need to provide credentials in NANOG, but > apparently one stays quiet too long and you're a noob. > > First, to those who have given me basic mpls, traceroute and ip primers > by off list email, thank you. It's not necessary. I appreciate your > willingness to help out the community. > > Second, I *know* that the traceroute I pasted a bit of has to do with > mpls magic (or similar). That's why I used the word tunnel. I wasn't > asking *how* it was done. I'm quiet capable of performing the same > magic. I just wanted to know if anyone off the top of their head knew > *where* the packets were magically popping back into the ether... LA, > Nevada, Denver. That's all. A physical location or a router IP would > have been a perfectly wonderful answer. Hey Deepak, Sorry, but they're actually right. Read the section on icmp tunneling, it explains exactly how and why you're seeing this behavior. :) The return packets pop our at the end of the lsp, which is clearly in LA (or thereabouts, whatever lsrca is probably). -- Richard A Steenbergen http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) From scott.brim at gmail.com Mon Oct 11 18:18:40 2010 From: scott.brim at gmail.com (Scott Brim) Date: Mon, 11 Oct 2010 19:18:40 -0400 Subject: Mobile Operator Connectivity In-Reply-To: References: <4CA0FAFD.30802@rollernet.us> <485ED9BA02629E4BBBA53AC892EDA50E0BBCB490@usmsxt104.mwd.h2o> <6EFFEFBAC68377459A2E972105C759EC0300A6AF@EXVBE005-2.exch005intermedia.net> <4CB1FAF0.5000107@bogus.com> Message-ID: <4CB39B50.90905@gmail.com> Cameron Byrne allegedly wrote on 10/10/2010 15:38 EDT: > LTE provides some latency benefits on the wireless interface, but the > actual packet core architecture is very similar to GSM / UMTS. and it's going to be a long time before Local Breakout gets noticeably deployed. From rfg at tristatelogic.com Tue Oct 12 04:01:32 2010 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Tue, 12 Oct 2010 02:01:32 -0700 Subject: AS22558 - Routing apparently hijacked space Message-ID: <17059.1286874092@tristatelogic.com> I can't take credit for finding this one. Somebody else on another mailing list I'm on actually found it. AS22558 itself _does not_ appear to be hijacked. Rather this is a relatively new (2009) AS, but the AS itself is very odd indeed. It's contact phone number isn't working, it apparently has no web site associated with its domain name (mpgnetworks.com) and although the whois record clearly indicates that the company behind this AS is located in California, the California Secretary of State's web site has no record of any "MPG Networks, LLC" operating legally within California. ===================================================================== ASNumber: 22558 ASName: MPGNET ASHandle: AS22558 RegDate: 2010-01-27 Updated: 2010-01-27 Ref: http://whois.arin.net/rest/asn/AS22558 OrgName: MPG Networks, LLC OrgId: MPGNE Address: 707 Wilshire, suite 411 City: Los Angeles StateProv: CA PostalCode: 90017 Country: US RegDate: 2009-11-03 Updated: 2009-11-03 Ref: http://whois.arin.net/rest/org/MPGNE OrgTechHandle: MNA72-ARIN OrgTechName: MPG Networks Admin OrgTechPhone: +1-213-867-3652 OrgTechEmail: admin at mpgnetworks.com OrgTechRef: http://whois.arin.net/rest/poc/MNA72-ARIN ===================================================================== So anyway, this AS appears to currently be routing what looks an awful lot like a whole lot of abandoned legacy IP address space, to wit: 66.119.224.0/20 192.101.208.0/20 192.101.224.0/20 192.112.112.0/22 192.112.116.0/22 192.112.120.0/22 192.112.124.0/22 198.13.0.0/22 198.13.4.0/22 198.13.8.0/22 198.13.12.0/22 198.162.208.0/20 198.178.64.0/22 198.178.68.0/22 198.178.72.0/22 198.178.76.0/22 198.178.80.0/20 206.201.48.0/20 Furthermore, looking at the name server data for these blocks, what I see in them sure as heck looks an awful lot like snowshoe spam domains to me. (See listing attached below.) Last but not least, robtex.com indicates that this entire AS is only connected to the Internet via a single other AS, i.e. AS3491, aka "Beyond The Network America, Inc." And I'd just like to take this opportunity to remind everyone that AS3491 is also still the only connection to the Internet for two other hijacked ASes (and all of the apparently hijacked address space that each of those is announcing), i.e. AS6061 and AS10392. In short, it does appear that the crooks are now officially running the Internet. (And yes, I _did_ properly inform the fine folks at Beyond The Network America, Inc. last week that they were aiding and abetting the effective theft of IP address space by whoever has hijacked AS6061 and AS10392, _and_ I _did_ get an acknowledgement back from them, indicating clearly that some live human there had read my message. But no, apparently they don't give a rat's ass, and they are perfectly fine with aiding & abetting the hijacker(s) in this case... presumably as long as whoever it is keeps on sending them checks every month.) Regards, rfg =============================================================== 66.119.224.2 ns1.reliancethanks.com reliancethanks.com aftermathinformational.com 66.119.224.3 ns2.reliancethanks.com reliancethanks.com aftermathinformational.com 66.119.225.239 ns.uberslinger.org 66.119.230.2 ns1.sectionalplacement.com sectionalplacement.com 66.119.230.3 ns2.sectionalplacement.com sectionalplacement.com 66.119.236.2 ns1.sundayexceeding.com precisionwedge.com printablediscovered.com positivelyrecently.com platinumshall.com productionweekday.com sundayexceeding.com 66.119.236.3 ns2.sundayexceeding.com precisionwedge.com printablediscovered.com positivelyrecently.com platinumshall.com productionweekday.com sundayexceeding.com 192.101.239.253 fwd2.select1media.com fgty232oflyaway.com xswe321oracetrack.com asefo221shortness.com puth123ofreely.com jqtyo313outofbounds.com muiuo332consistent.com mjui332owalked.com etye112olightup.com ukkho121greatwin.com jlkk231believableo.com fthno223majority.com cddgo113longway.com select1media.com hngeo131intouch.com cdtu223leadingo.com zipi121ointhezone.com bhtq222oroadtrip.com sfewo331advantage.com cftho232likely.com qaxs221odarkness.com wefro212permanent.com fwd1.select1media.com fgty232oflyaway.com xswe321oracetrack.com asefo221shortness.com puth123ofreely.com jqtyo313outofbounds.com muiuo332consistent.com mjui332owalked.com etye112olightup.com ukkho121greatwin.com jlkk231believableo.com fthno223majority.com cddgo113longway.com select1media.com hngeo131intouch.com cdtu223leadingo.com zipi121ointhezone.com bhtq222oroadtrip.com sfewo331advantage.com cftho232likely.com qaxs221odarkness.com wefro212permanent.com 198.13.2.1 ns1.publicidad3d.info 198.162.208.4 ns1.dnsdeguyana.info unawareofthesubject.info toshowphilosopherof.info seekfromartbeauty.info passivelydiscoveredthinkabout.info ofartshakespeareanwhichour.info moonoftenprofessto.info lightetudetothe.info itsnormativesidenothing.info inpersonaladornmentbe.info hearsayintheworld.info betterworksofart.info besurecuttingwood.info aparttheart.info anotheruglyaestheticpurpose.info afewexamplesobjectjust.info itmustbebrought.com isbeyondtheprovince.com tastefinallyofselfscrutiny.com notexistforan.com theskepticorthe.com maylessentheprobabilities.com 198.162.208.5 ns2.dnsdeguyana.info unawareofthesubject.info toshowphilosopherof.info seekfromartbeauty.info passivelydiscoveredthinkabout.info ofartshakespeareanwhichour.info moonoftenprofessto.info lightetudetothe.info itsnormativesidenothing.info inpersonaladornmentbe.info hearsayintheworld.info betterworksofart.info besurecuttingwood.info aparttheart.info anotheruglyaestheticpurpose.info afewexamplesobjectjust.info itmustbebrought.com isbeyondtheprovince.com tastefinallyofselfscrutiny.com notexistforan.com theskepticorthe.com maylessentheprobabilities.com 198.178.64.4 ns1.barranquilla-dns.info thelesscanbe.info theirachievedrelationshe.info subjecttocorrectionjudgments.info psychologyinterestinbeauty.info principlesislessenthe.info primitivemenbeautyitself.info partofthesubject.info ourownpurposesabsolutely.info ofacriticrelations.info methodofobservationas.info lackofunderstandingof.info forusoftenprofess.info correctionthepathwayhimself.info andfunctionstheoreticalanalysis.info allappreciationofparticular.info accurateinjudgmentis.info 198.178.64.5 ns2.barranquilla-dns.info thelesscanbe.info theirachievedrelationshe.info subjecttocorrectionjudgments.info psychologyinterestinbeauty.info principlesislessenthe.info primitivemenbeautyitself.info partofthesubject.info ourownpurposesabsolutely.info ofacriticrelations.info methodofobservationas.info lackofunderstandingof.info forusoftenprofess.info correctionthepathwayhimself.info andfunctionstheoreticalanalysis.info allappreciationofparticular.info accurateinjudgmentis.info 206.201.50.2 ns1.respectivemotive.com pensplaces.com interviewedseller.com generallyrumored.com regulatorsstretches.com mailedmission.com forecasterpanic.com generosityamount.com itemprep.com fascinatingfixings.com schemepowerful.com scotlandwonderful.com fontvaried.com grindstonesocal.com exitingfuturists.com respectivemotive.com itemsupporting.com silkbid.com operationstudent.com listenmotivation.com necessitysupplies.com locationquadruple.com looksutility.com 206.201.50.3 ns2.respectivemotive.com pensplaces.com interviewedseller.com generallyrumored.com regulatorsstretches.com mailedmission.com forecasterpanic.com generosityamount.com itemprep.com fascinatingfixings.com schemepowerful.com scotlandwonderful.com fontvaried.com grindstonesocal.com exitingfuturists.com respectivemotive.com itemsupporting.com silkbid.com operationstudent.com listenmotivation.com necessitysupplies.com locationquadruple.com looksutility.com 206.201.57.2 ns1.shelfbuying.com venezuelaexpire.com styleoutput.com threadbarestabilizes.com reducesreoffering.com unawareneed.com bookscourtesy.com bannerswardrobe.com arenaformula.com architecturetougher.com broaderbasedvalidity.com citiesunderstood.com buddingprimary.com assistscontext.com certificatetransactions.com allocatereported.com althoughacquire.com advancednautical.com sponsorshipguidance.com withdrawsspoken.com sketchnecessarily.com technicalbestseller.com providingonline.com shelfbuying.com purchasetrial.com trainedmonumental.com promisecombinations.com 206.201.57.3 ns2.shelfbuying.com venezuelaexpire.com styleoutput.com threadbarestabilizes.com reducesreoffering.com unawareneed.com bookscourtesy.com bannerswardrobe.com arenaformula.com architecturetougher.com broaderbasedvalidity.com citiesunderstood.com buddingprimary.com assistscontext.com certificatetransactions.com allocatereported.com althoughacquire.com advancednautical.com sponsorshipguidance.com withdrawsspoken.com sketchnecessarily.com technicalbestseller.com providingonline.com shelfbuying.com purchasetrial.com trainedmonumental.com promisecombinations.com From ihatesorbs at gmail.com Tue Oct 12 07:35:11 2010 From: ihatesorbs at gmail.com (iHate SORBS) Date: Tue, 12 Oct 2010 05:35:11 -0700 Subject: Network Operators Unite Against SORBS Message-ID: Network Operators Unite Against SORBS Do you, or have you had problems with SORBS? Tired of being able to do nothing about it? Sick of opening a trouble ticket, only to get delisted weeks later? I am calling on all Network Operators to stand up and stop routing dnsbl.sorbs.net until that time they can commit to making real changes. -Operator From darcy at druid.net Tue Oct 12 08:35:41 2010 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Tue, 12 Oct 2010 09:35:41 -0400 Subject: Network Operators Unite Against SORBS In-Reply-To: References: Message-ID: <20101012093541.17921bcf.darcy@druid.net> On Tue, 12 Oct 2010 05:35:11 -0700 iHate SORBS wrote: > I am calling on all Network Operators to stand up and stop routing > dnsbl.sorbs.net until that time they can commit to making real changes. This doesn't seem like a network issue. You probably want the mailops list. Network operators aren't going to stop routing something that mail operators want. You are going to have to convince mail operators not to want it. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From Valdis.Kletnieks at vt.edu Tue Oct 12 10:11:12 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 12 Oct 2010 11:11:12 -0400 Subject: Network Operators Unite Against SORBS In-Reply-To: Your message of "Tue, 12 Oct 2010 05:35:11 PDT." References: Message-ID: <13959.1286896272@localhost> On Tue, 12 Oct 2010 05:35:11 PDT, iHate SORBS said: > I am calling on all Network Operators to stand up and stop routing > dnsbl.sorbs.net until that time they can commit to making real changes. You *do* realize your beef isn't with SORBS, it's with the mail operators that are using that as part of their input when deciding whether or not to accept mail, right? And they'll probably continue using it, because they're not the ones who feel the pain of being listed incorrectly. That won't change unless you can make a clear and logical business case of why using SORBS is counter-productive for *them*. That probably will mean that you have to demonstrate that your mail (and all the other SORBS false-positives) is worth more to their organization than the benefits they get from using SORBS (namely, a reduction in the amount of abusive mail they get). Unfortunately, unless you're trying to e-mail them a purchase order for an amount that's bigger than their anti-abuse team's budget, that probably will be a hard case to make. Further discussion is probably better suited for mailops or spam-l. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From bruns at 2mbit.com Tue Oct 12 10:37:36 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Tue, 12 Oct 2010 15:37:36 +0000 Subject: Network Operators Unite Against SORBS Message-ID: <923716214-1286897848-cardhu_decombobulator_blackberry.rim.net-288507815-@bda900.bisx.prod.on.blackberry> How about... Network Operators Against Whiny Mail Operators Who Have Nothing Better To Do With Their Time But Carry Out Personal Vendettas? NOAWMOWHNBTDWTRBCOPV ------Original Message------ From: iHate SORBS To: nanog at nanog.org Subject: Network Operators Unite Against SORBS Sent: Oct 12, 2010 6:35 AM Network Operators Unite Against SORBS Do you, or have you had problems with SORBS? Tired of being able to do nothing about it? Sick of opening a trouble ticket, only to get delisted weeks later? I am calling on all Network Operators to stand up and stop routing dnsbl.sorbs.net until that time they can commit to making real changes. -Operator -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From trelane at trelane.net Tue Oct 12 10:39:58 2010 From: trelane at trelane.net (Andrew Kirch) Date: Tue, 12 Oct 2010 11:39:58 -0400 Subject: Network Operators Unite Against SORBS In-Reply-To: References: Message-ID: <4CB4814E.4000405@trelane.net> On 10/12/2010 8:35 AM, iHate SORBS wrote: > Network Operators Unite Against SORBS > > > > Do you, or have you had problems with SORBS? > > Tired of being able to do nothing about it? > > Sick of opening a trouble ticket, only to get delisted weeks later? > > > > I am calling on all Network Operators to stand up and stop routing > dnsbl.sorbs.net until that time they can commit to making real changes. > > > > -Operator Well, You can't post under your real name, this at best a tired rant, and quite honestly if you did, I think it'd be more likely that your upstream would stop routing you. Have a nice day! From tglassey at earthlink.net Tue Oct 12 10:47:02 2010 From: tglassey at earthlink.net (todd glassey) Date: Tue, 12 Oct 2010 08:47:02 -0700 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE Message-ID: <4CB482F6.5040506@earthlink.net> Mike Leber - I have been waiting for a response from Melissa in your accounting department since she insisted I sign the VISA release in order to refund our money after your company violated the Co-Lo agreement and shut the power down to ROW 4 in Suite 1200 with no warning or Customer Service Response... How long is this going to take to process? Todd Glassey -- //----------------------------------------------------------------- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From jharper at well.com Tue Oct 12 10:52:50 2010 From: jharper at well.com (Jeff Harper) Date: Tue, 12 Oct 2010 08:52:50 -0700 (PDT) Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: <4CB482F6.5040506@earthlink.net> Message-ID: <510908426.374.1286898770145.JavaMail.root@zimbra.well.com> http://tinyurl.com/275rhhu ----- Original Message ----- > From: "todd glassey" > To: nanog at nanog.org, mike at he.net, "Hurricane Electric LLC" > Sent: Tuesday, October 12, 2010 10:47:02 AM > Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into > legal actions against HE > Mike Leber - I have been waiting for a response from Melissa in your > accounting department since she insisted I sign the VISA release in > order to refund our money after your company violated the Co-Lo > agreement and shut the power down to ROW 4 in Suite 1200 with no > warning > or Customer Service Response... > > How long is this going to take to process? > > > Todd Glassey > > > -- > //----------------------------------------------------------------- > > > This message may contain confidential and/or privileged information. > If you are not the addressee or authorized to receive this for the > addressee, you must not use, copy, disclose or take any action based > on this message or any information herein. If you have received this > message in error, please advise the sender immediately by reply e-mail > and delete this message. > > Thank you for your cooperation. From jack at crepinc.com Tue Oct 12 11:00:30 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 12 Oct 2010 12:00:30 -0400 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: <510908426.374.1286898770145.JavaMail.root@zimbra.well.com> References: <4CB482F6.5040506@earthlink.net> <510908426.374.1286898770145.JavaMail.root@zimbra.well.com> Message-ID: Clearly we should all care deeply about this. -J On Tue, Oct 12, 2010 at 11:52 AM, Jeff Harper wrote: > http://tinyurl.com/275rhhu > > ----- Original Message ----- > > From: "todd glassey" > > To: nanog at nanog.org, mike at he.net, "Hurricane Electric LLC" < > melissah at he.net> > > Sent: Tuesday, October 12, 2010 10:47:02 AM > > Subject: Hey Leber - you think Melissa is going to issue that refund > properly or do we need to escalate this into > > legal actions against HE > > Mike Leber - I have been waiting for a response from Melissa in your > > accounting department since she insisted I sign the VISA release in > > order to refund our money after your company violated the Co-Lo > > agreement and shut the power down to ROW 4 in Suite 1200 with no > > warning > > or Customer Service Response... > > > > How long is this going to take to process? > > > > > > Todd Glassey > > > > > > -- > > //----------------------------------------------------------------- > > > > > > This message may contain confidential and/or privileged information. > > If you are not the addressee or authorized to receive this for the > > addressee, you must not use, copy, disclose or take any action based > > on this message or any information herein. If you have received this > > message in error, please advise the sender immediately by reply e-mail > > and delete this message. > > > > Thank you for your cooperation. > > From jeffrey.lyon at blacklotus.net Tue Oct 12 11:22:52 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Tue, 12 Oct 2010 20:52:52 +0430 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: <4CB482F6.5040506@earthlink.net> References: <4CB482F6.5040506@earthlink.net> Message-ID: They should shut down your power again for that one. Regards, Jeff On Tue, Oct 12, 2010 at 8:17 PM, todd glassey wrote: > Mike Leber - I have been waiting for a response from Melissa in your > accounting department since she insisted I sign the VISA release in > order to refund our money after your company violated the Co-Lo > agreement and shut the power down to ROW 4 in Suite 1200 with no warning > or Customer Service Response... > > How long is this going to take to process? > > > Todd Glassey > > > -- > //----------------------------------------------------------------- > > > This message may contain confidential and/or privileged information. > If you are not the addressee or authorized to receive this for the > addressee, you must not use, copy, disclose or take any action based > on this message or any information herein. If you have received this > message in error, please advise the sender immediately by reply e-mail > and delete this message. > > 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 scott at doc.net.au Tue Oct 12 11:25:23 2010 From: scott at doc.net.au (Scott Howard) Date: Tue, 12 Oct 2010 09:25:23 -0700 Subject: Network Operators Unite Against SORBS In-Reply-To: References: Message-ID: On Tue, Oct 12, 2010 at 5:35 AM, iHate SORBS wrote: > I am calling on all Network Operators to stand up and stop routing > dnsbl.sorbs.net until that time they can commit to making real changes. > What sort of changes are you suggesting? Suggesting a block unless they make undisclosed changes is simply asinine. I'm no fan of SORBS, but at the end of the day (ignoring the issues like they had last week) they do what they say they do. The problem with SORBS is not SORBS itself, but the mail admins that are stupid enough to use it - or at least stupid enough to use it as a straight blacklist (as opposed to a scoring blacklist). Start up a campaign against those if you like - perhaps an RBL of people who are using the SORBS RBL - but asking people to stop "routing" a DNS domain just because you don't like their clearly stated listing criteria simply isn't going to fly. Scott. From lists at billfehring.com Tue Oct 12 11:36:23 2010 From: lists at billfehring.com (Bill Fehring) Date: Tue, 12 Oct 2010 09:36:23 -0700 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: References: <4CB482F6.5040506@earthlink.net> Message-ID: +1 I don't think anyone is going to take your side after that maneuver, Todd. -Bill On Tue, Oct 12, 2010 at 09:22, Jeffrey Lyon wrote: > > They should shut down your power again for that one. > > Regards, Jeff > From oberman at es.net Tue Oct 12 11:44:28 2010 From: oberman at es.net (Kevin Oberman) Date: Tue, 12 Oct 2010 09:44:28 -0700 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: Your message of "Tue, 12 Oct 2010 09:36:23 PDT." Message-ID: <20101012164428.9F9B61CC3E@ptavv.es.net> Pardon me, but did I miss the announcement of "Whine on NANOG day"? Between this thread and "Network Operators Unite Against SORBS", I assume that I must have missed the announcement while I was in the road last week. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From dseagrav at humancapitaldev.com Tue Oct 12 11:46:27 2010 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Tue, 12 Oct 2010 11:46:27 -0500 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: <4CB482F6.5040506@earthlink.net> References: <4CB482F6.5040506@earthlink.net> Message-ID: On Oct 12, 2010, at 10:47 AM, todd glassey wrote: > Mike Leber - I have been waiting for a response from Melissa in your > accounting department... I have a collection of stuffed bunnies and Hello Kitty paraphernalia, and I still think jokes about farts are funny, but even I'm not childish enough to think pulling this kind of a stunt is even remotely acceptable. Now if you'll excuse me, I have a bunch of pictures of cute kittens that need copy-pasting. From patrick at ianai.net Tue Oct 12 11:46:40 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Tue, 12 Oct 2010 12:46:40 -0400 Subject: Network Operators Unite Against SORBS In-Reply-To: References: Message-ID: <9BFF0BE7-632F-47E1-8D0E-5B07A2A15C8E@ianai.net> On Oct 12, 2010, at 12:25 PM, Scott Howard wrote: > On Tue, Oct 12, 2010 at 5:35 AM, iHate SORBS wrote: > >> I am calling on all Network Operators to stand up and stop routing >> dnsbl.sorbs.net until that time they can commit to making real changes. >> > > What sort of changes are you suggesting? Suggesting a block unless they > make undisclosed changes is simply asinine. > > I'm no fan of SORBS, but at the end of the day (ignoring the issues like > they had last week) they do what they say they do. > > The problem with SORBS is not SORBS itself, but the mail admins that are > stupid enough to use it - or at least stupid enough to use it as a straight > blacklist (as opposed to a scoring blacklist). Start up a campaign against > those if you like - perhaps an RBL of people who are using the SORBS RBL - > but asking people to stop "routing" a DNS domain just because you don't like > their clearly stated listing criteria simply isn't going to fly. I kinda-sortta feel like many others who have posted here. This is a mail thing, not netops. Grow a pair and post under your own name. Is it even on-topic for NANOG? Etc. I even started typing a message to the effect of: "even though I don't like SORBS, they should be allowed to publish a list and let others do as they please". But then I realized, that is all this anonymous person is asking. Or at least it could be. If "iHate SORBS" wants to create a (another?) list of prefixes which should not be routed, and put SORBS on it, he (she?) should be allowed, just as SORBS should be allowed to have a list of mail servers SORBS doesn't like. Then each operator can decide whether to implement a block based on the list or not. Your network, your decision. Of course, I fully expect no one to implement the block. But that is no reason to deny the ability to create the list. Now, I feel like quoting Pastor Niem?ller so we can end this thread. :) -- TTFN, patrick From carlosm3011 at gmail.com Tue Oct 12 11:49:37 2010 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Tue, 12 Oct 2010 14:49:37 -0200 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: <20101012164428.9F9B61CC3E@ptavv.es.net> References: <20101012164428.9F9B61CC3E@ptavv.es.net> Message-ID: Maybe that's why they shut the power off in the first place... :-) I just could not resist, sorry! BTW, who's Leber? He/she doesn't seem to be CCed. I have more mailing lists to suggest where he/she might be found... I could not resist, Take II. cheers, Carlos -- -- ========================= Carlos M. Martinez-Cagnazzo http://cagnazzo.name ========================= From Greg.Whynott at oicr.on.ca Tue Oct 12 11:52:01 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Tue, 12 Oct 2010 12:52:01 -0400 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: <20101012164428.9F9B61CC3E@ptavv.es.net> References: <20101012164428.9F9B61CC3E@ptavv.es.net> Message-ID: <830C195D-C544-4C1F-922F-5023B6FAAE15@oicr.on.ca> its sad that the list apparently has become a sounding board for these 'operators' who think others care about their plights and opinions which have nothing to do with L1/2/3 issues. *i'm taking my ball and going home!* -g On Oct 12, 2010, at 12:44 PM, Kevin Oberman wrote: > Pardon me, but did I miss the announcement of "Whine on NANOG day"? > > -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From ken at sizone.org Tue Oct 12 11:54:41 2010 From: ken at sizone.org (Ken Chase) Date: Tue, 12 Oct 2010 12:54:41 -0400 Subject: Network Operators Unite Against SORBS In-Reply-To: References: Message-ID: <20101012165441.GJ5470@sizone.org> On Tue, Oct 12, 2010 at 09:25:23AM -0700, Scott Howard said: >I'm no fan of SORBS, but at the end of the day (ignoring the issues like >they had last week) they do what they say they do. Disagree. I have followed all the quasi RFC's Mich* Sullivan quotes to get my blocks unlisted, and after a good 20 hours work over a few weeks, with everything 100% compliant and all my reverses now with *.static.* and *.colo.* and whatever else (I've tried multiples), they're still not delisted. I run racks of gear in a colo, not broadband. Go figure. We hashed it out in a long thread on the list here to no avail. SORBS doenst do what it says it does, for many there's no way to get off their list except changing IPs. As much as you guys hate the noise here, I see other noises that I tolerate on the list for everyone's mutual eventual benefit. Im SURE someone could 'contact a yahoo network admin' in some other fashion than Nanog, Nanog is just the easiest way at that point to get ahold of someone. Talking about SORBS on Nanog is in the same boat at times. I'd tolerate it until the issue is fixed. /kc -- Ken Chase - ken at heavycomputing.ca - +1 416 897 6284 - Toronto CANADA Heavy Computing - Clued bandwidth, colocation and managed linux VPS @151 Front St. W. From hardenrm at uiuc.edu Tue Oct 12 11:55:58 2010 From: hardenrm at uiuc.edu (Ryan Harden) Date: Tue, 12 Oct 2010 11:55:58 -0500 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: References: <20101012164428.9F9B61CC3E@ptavv.es.net> Message-ID: <4CB4931E.5040405@uiuc.edu> I suspect "Leber" has either a first or last name that starts with "na" or "nan" and this poor guy is the victim of auto-complete failure. But this is NANOG, so I expect nothing but jumping to conclusions and overreactions. Thanks for solidifying my expectations! /Ryan On 10/12/2010 11:49 AM, Carlos Martinez-Cagnazzo wrote: > BTW, who's Leber? He/she doesn't seem to be CCed. I have more mailing lists > to suggest where he/she might be found... > -- Ryan M. Harden, BS, KC9IHX Office: 217-265-5192 CITES - Network Engineering Cell: 217-689-1363 2130 Digital Computer Lab Fax: 217-244-7089 1304 W. Springfield email: hardenrm at illinois.edu Urbana, IL 61801 University of Illinois at Urbana/Champaign - AS38 University of Illinois - ICCN - AS40387 From bclark at spectraaccess.com Tue Oct 12 11:57:55 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Tue, 12 Oct 2010 12:57:55 -0400 Subject: Network Operators Unite Against SORBS In-Reply-To: <9BFF0BE7-632F-47E1-8D0E-5B07A2A15C8E@ianai.net> References: <9BFF0BE7-632F-47E1-8D0E-5B07A2A15C8E@ianai.net> Message-ID: <4CB49393.9080700@spectraaccess.com> On 10/12/2010 12:46 PM, Patrick W. Gilmore wrote: > > I kinda-sortta feel like many others who have posted here. This is a mail thing, not netops. Grow a pair and post under your own name. Is it even on-topic for NANOG? Etc. > > I even started typing a message to the effect of: "even though I don't like SORBS, they should be allowed to publish a list and let others do as they please". But then I realized, that is all this anonymous person is asking. Or at least it could be. > > If "iHate SORBS" wants to create a (another?) list of prefixes which should not be routed, and put SORBS on it, he (she?) should be allowed, just as SORBS should be allowed to have a list of mail servers SORBS doesn't like. Then each operator can decide whether to implement a block based on the list or not. Your network, your decision. > > Of course, I fully expect no one to implement the block. But that is no reason to deny the ability to create the list. > > Now, I feel like quoting Pastor Niem?ller so we can end this thread. :) > > Not to mention it's bad enough with congress trying to pass laws to make us network operators police the Internet, I don't need to police SORBS on top of it! Bret From bmanning at vacation.karoshi.com Tue Oct 12 11:58:13 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 12 Oct 2010 16:58:13 +0000 Subject: Hey Leber In-Reply-To: References: <20101012164428.9F9B61CC3E@ptavv.es.net> Message-ID: <20101012165813.GA2013@vacation.karoshi.com.> On Tue, Oct 12, 2010 at 02:49:37PM -0200, Carlos Martinez-Cagnazzo wrote: > Maybe that's why they shut the power off in the first place... :-) > BTW, who's Leber? He/she doesn't seem to be CCed. I have more mailing lists > to suggest where he/she might be found... > Leber is a corruption of the mythic deity of the IPv4 Morlocks. it _should_ be "Take me to your Leader" --bill From jgreco at ns.sol.net Tue Oct 12 12:01:30 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 12 Oct 2010 12:01:30 -0500 (CDT) Subject: Hey Leber - you think Melissa is going to issue that refund In-Reply-To: Message-ID: <201010121701.o9CH1Umx002531@aurora.sol.net> > They should shut down your power again for that one. It's like asking for them to cycle your power on and off until your stuff starts letting out the magic smoke around event number 100,000. :-) ... 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 tagno25 at gmail.com Tue Oct 12 12:06:37 2010 From: tagno25 at gmail.com (Philip Dorr) Date: Tue, 12 Oct 2010 12:06:37 -0500 Subject: Hey Leber - you think Melissa is going to issue that refund properly or do we need to escalate this into legal actions against HE In-Reply-To: <4CB4931E.5040405@uiuc.edu> References: <20101012164428.9F9B61CC3E@ptavv.es.net> <4CB4931E.5040405@uiuc.edu> Message-ID: Or more likely Leber's first name is Mike. On Tue, Oct 12, 2010 at 11:55 AM, Ryan Harden wrote: > I suspect "Leber" has either a first or last name that starts with "na" > or "nan" and this poor guy is the victim of auto-complete failure. > > But this is NANOG, so I expect nothing but jumping to conclusions and > overreactions. Thanks for solidifying my expectations! > > /Ryan > > On 10/12/2010 11:49 AM, Carlos Martinez-Cagnazzo wrote: > >> BTW, who's Leber? He/she doesn't seem to be CCed. I have more mailing lists >> to suggest where he/she might be found... >> > > > -- > Ryan M. Harden, BS, KC9IHX ? ? ? ? ? ? ?Office: 217-265-5192 > CITES - Network Engineering ? ? ? ? ? ? Cell: ? 217-689-1363 > 2130 Digital Computer Lab ? ? ? ? ? ? ? Fax: ? ?217-244-7089 > 1304 W. Springfield ? ? ? ? ? ? ? ? ? ? email: ?hardenrm at illinois.edu > Urbana, IL ?61801 > > ? ? ?University of Illinois at Urbana/Champaign - AS38 > ? ? ? ? ? University of Illinois - ICCN - AS40387 > > From jna at retina.net Tue Oct 12 12:13:14 2010 From: jna at retina.net (John Adams) Date: Tue, 12 Oct 2010 10:13:14 -0700 Subject: Network Operators Unite Against SORBS In-Reply-To: <4CB49393.9080700@spectraaccess.com> References: <9BFF0BE7-632F-47E1-8D0E-5B07A2A15C8E@ianai.net> <4CB49393.9080700@spectraaccess.com> Message-ID: Really the best thing to do is to just leave SORBS alone. The more idiotic bans they put into place with demands for "$50 per IP per incident", the less trustworthy of an RBL they become. Most large network operations will end up ignoring them, or if they do use the data from their RBL, they will take it at a far lower metric in their overall anti-spam equasion. -j On Tue, Oct 12, 2010 at 9:57 AM, Bret Clark wrote: > On 10/12/2010 12:46 PM, Patrick W. Gilmore wrote: >> >> I kinda-sortta feel like many others who have posted here. ?This is a mail >> thing, not netops. ?Grow a pair and post under your own name. ?Is it even >> on-topic for NANOG? ?Etc. >> >> I even started typing a message to the effect of: "even though I don't >> like SORBS, they should be allowed to publish a list and let others do as >> they please". ?But then I realized, that is all this anonymous person is >> asking. ?Or at least it could be. >> >> If "iHate SORBS" wants to create a (another?) list of prefixes which >> should not be routed, and put SORBS on it, he (she?) should be allowed, just >> as SORBS should be allowed to have a list of mail servers SORBS doesn't >> like. ?Then each operator can decide whether to implement a block based on >> the list or not. ?Your network, your decision. >> >> Of course, I fully expect no one to implement the block. ?But that is no >> reason to deny the ability to create the list. >> >> Now, I feel like quoting Pastor Niem?ller so we can end this thread. :) >> >> > > Not to mention it's bad enough with congress trying to pass laws to make us > network operators police the Internet, I don't need to police SORBS on top > of it! > Bret > > From jlewis at lewis.org Tue Oct 12 12:37:50 2010 From: jlewis at lewis.org (Jon Lewis) Date: Tue, 12 Oct 2010 13:37:50 -0400 (EDT) Subject: neglected route-servers In-Reply-To: References: Message-ID: On Mon, 11 Oct 2010, Jon Lewis wrote: > Guess what happens when you run a 7206VXR (NPE300) as a route server with 3 > full feeds? It took me a minute to figure out why my routes that TWTelecom > isn't supposed to see were showing up on route-server.twtelecom.net, but were > seemingly randomly alternating between Network not in table and showing up. > > If anyone from TWTelecom is here, it's probably time to swap out that NPE300 > for something with more than 256MB RAM. It's running out of RAM and > resetting all the BGP sessions before they finish getting full routes. Well, if nothing else, it's good to see this message woke someone up at TWTelecom. They seem to have done some magic (10 year old IOS:) to make 3 full views fit in an NPE300 with 32mb RAM to spare. I finally got a call back on the ticket I opened with TWT yesterday morning...last night at 11:30PM!...a good 11 hours after I'd resolved the problem. Good thing it wasn't important. Apparently 65000:0 no longer works with them because they've become a Level3 customer...so it wasn't a Level3 route leak "problem"...it was by design. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From ryan.finnesey at HarrierInvestments.com Tue Oct 12 23:28:42 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 12 Oct 2010 21:28:42 -0700 Subject: T-Mobile USA - Peering Policy Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300A923@EXVBE005-2.exch005intermedia.net> Can someone on the list from T-Mobile USA please contact me. I have tried sending a message to admin at tmodns.net but the message bounces back and the mailbox for arintechcontact at t-mobile.com is full. I am trying to find out information regarding there peering policy. Cheers Ryan From ryan.finnesey at HarrierInvestments.com Tue Oct 12 23:42:05 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 12 Oct 2010 21:42:05 -0700 Subject: T-Mobile USA - Peering Policy In-Reply-To: <051389FB-7C01-4724-BAA4-CB3AB717A0EF@gmail.com> References: <6EFFEFBAC68377459A2E972105C759EC0300A923@EXVBE005-2.exch005intermedia.net> <051389FB-7C01-4724-BAA4-CB3AB717A0EF@gmail.com> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300A926@EXVBE005-2.exch005intermedia.net> I looked into Deutsche Telekom and T-System but the AS I have for T-Mobile USA does not seem to be connected to either network which is odd because Deutsche Telekom owns T-Mobile USA but thank you for the recommendation. Cheers Ryan -----Original Message----- From: kris foster [mailto:kris.foster at gmail.com] Sent: Wednesday, October 13, 2010 12:36 AM To: Ryan Finnesey Subject: Re: T-Mobile USA - Peering Policy You're looking for Deutsche Telekom http://as3320.peeringdb.com On Oct 12, 2010, at 9:28 PM, Ryan Finnesey wrote: > Can someone on the list from T-Mobile USA please contact me. I have > tried sending a message to admin at tmodns.net but the message bounces back > and the mailbox for arintechcontact at t-mobile.com is full. I am trying > to find out information regarding there peering policy. > > Cheers > Ryan > > From randy at psg.com Wed Oct 13 00:26:57 2010 From: randy at psg.com (Randy Bush) Date: Wed, 13 Oct 2010 08:26:57 +0300 Subject: AS22558 - Routing apparently hijacked space In-Reply-To: <17059.1286874092@tristatelogic.com> References: <17059.1286874092@tristatelogic.com> Message-ID: > I can't take credit for finding this one. plonk From gbonser at seven.com Wed Oct 13 01:17:57 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 12 Oct 2010 23:17:57 -0700 Subject: T-Mobile USA - Peering Policy In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0300A926@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC0300A923@EXVBE005-2.exch005intermedia.net><051389FB-7C01-4724-BAA4-CB3AB717A0EF@gmail.com> <6EFFEFBAC68377459A2E972105C759EC0300A926@EXVBE005-2.exch005intermedia.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C23E@RWC-EX1.corp.seven.com> Ryan, might want to have a look at pages 4 and 5 of this document on a peering conference presentation in Asia in 2004 AS3320 does appear to be what you need: http://www.apricot.net/apricot2004/doc/cd_content/26th%20February%202004 /Asia%20Pacific%20Peering%20Conference/03%20-%20Erasmus%20Ng/Apricot2004 %20T-Systems%20Peering.PDF > -----Original Message----- > From: Ryan Finnesey [mailto:ryan.finnesey at HarrierInvestments.com] > Sent: Tuesday, October 12, 2010 9:42 PM > To: nanog at nanog.org > Subject: RE: T-Mobile USA - Peering Policy > > I looked into Deutsche Telekom and T-System but the AS I have for > T-Mobile USA does not seem to be connected to either network which is > odd because Deutsche Telekom owns T-Mobile USA but thank you for the > recommendation. > Cheers > Ryan > > > -----Original Message----- > From: kris foster [mailto:kris.foster at gmail.com] > Sent: Wednesday, October 13, 2010 12:36 AM > To: Ryan Finnesey > Subject: Re: T-Mobile USA - Peering Policy > > You're looking for Deutsche Telekom > > http://as3320.peeringdb.com > > On Oct 12, 2010, at 9:28 PM, Ryan Finnesey wrote: > > > Can someone on the list from T-Mobile USA please contact me. I have > > tried sending a message to admin at tmodns.net but the message bounces > back > > and the mailbox for arintechcontact at t-mobile.com is full. I am > trying > > to find out information regarding there peering policy. > > > > Cheers > > Ryan > > > > > From ryan.finnesey at HarrierInvestments.com Wed Oct 13 01:57:58 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 12 Oct 2010 23:57:58 -0700 Subject: T-Mobile USA - Peering Policy In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C23E@RWC-EX1.corp.seven.com> References: <6EFFEFBAC68377459A2E972105C759EC0300A923@EXVBE005-2.exch005intermedia.net><051389FB-7C01-4724-BAA4-CB3AB717A0EF@gmail.com> <6EFFEFBAC68377459A2E972105C759EC0300A926@EXVBE005-2.exch005intermedia.net> <5A6D953473350C4B9995546AFE9939EE0B14C23E@RWC-EX1.corp.seven.com> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300A92A@EXVBE005-2.exch005intermedia.net> Hi George It is late on the east coast and maybe I am missing something but I do not see T-Systems connected to the T-Mobile USA network. I do see it connected to most of the T-Mobile networks across Europe but I will ping the contacts listed in peerdb for AS3320. Cheers Ryan -----Original Message----- From: George Bonser [mailto:gbonser at seven.com] Sent: Wednesday, October 13, 2010 2:18 AM To: Ryan Finnesey; nanog at nanog.org Subject: RE: T-Mobile USA - Peering Policy Ryan, might want to have a look at pages 4 and 5 of this document on a peering conference presentation in Asia in 2004 AS3320 does appear to be what you need: http://www.apricot.net/apricot2004/doc/cd_content/26th%20February%202004 /Asia%20Pacific%20Peering%20Conference/03%20-%20Erasmus%20Ng/Apricot2004 %20T-Systems%20Peering.PDF > -----Original Message----- > From: Ryan Finnesey [mailto:ryan.finnesey at HarrierInvestments.com] > Sent: Tuesday, October 12, 2010 9:42 PM > To: nanog at nanog.org > Subject: RE: T-Mobile USA - Peering Policy > > I looked into Deutsche Telekom and T-System but the AS I have for > T-Mobile USA does not seem to be connected to either network which is > odd because Deutsche Telekom owns T-Mobile USA but thank you for the > recommendation. > Cheers > Ryan > > > -----Original Message----- > From: kris foster [mailto:kris.foster at gmail.com] > Sent: Wednesday, October 13, 2010 12:36 AM > To: Ryan Finnesey > Subject: Re: T-Mobile USA - Peering Policy > > You're looking for Deutsche Telekom > > http://as3320.peeringdb.com > > On Oct 12, 2010, at 9:28 PM, Ryan Finnesey wrote: > > > Can someone on the list from T-Mobile USA please contact me. I have > > tried sending a message to admin at tmodns.net but the message bounces > back > > and the mailbox for arintechcontact at t-mobile.com is full. I am > trying > > to find out information regarding there peering policy. > > > > Cheers > > Ryan > > > > > From hank at efes.iucc.ac.il Wed Oct 13 03:25:09 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 13 Oct 2010 10:25:09 +0200 Subject: Dutch Hotels Must Register As ISPs Message-ID: <5.1.0.14.2.20101013102446.00bfa7b0@efes.iucc.ac.il> http://yro.slashdot.org/story/10/10/13/0044233/Dutch-Hotels-Must-Register-As -ISPs From jeroen at unfix.org Wed Oct 13 03:41:03 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 13 Oct 2010 10:41:03 +0200 Subject: Dutch Hotels Must Register As ISPs In-Reply-To: <5.1.0.14.2.20101013102446.00bfa7b0@efes.iucc.ac.il> References: <5.1.0.14.2.20101013102446.00bfa7b0@efes.iucc.ac.il> Message-ID: <4CB5709F.1010102@unfix.org> On 2010-10-13 10:25, Hank Nussbacher wrote: > http://yro.slashdot.org/story/10/10/13/0044233/Dutch-Hotels-Must-Register-As > -ISPs I don't see the problem here, they are generally already outsourcing the "ISP" part anyway to a company, and that company is generally already a ISP. The only thing that might happen because of the wiretapping is that they cannot stick everybody behind a NAT anymore and thus maybe service might improve...... (wishful thinking eh ;) Greets, Jeroen From henk at ripe.net Wed Oct 13 04:04:19 2010 From: henk at ripe.net (Henk Uijterwaal) Date: Wed, 13 Oct 2010 11:04:19 +0200 Subject: Dutch Hotels Must Register As ISPs In-Reply-To: <4CB5709F.1010102@unfix.org> References: <5.1.0.14.2.20101013102446.00bfa7b0@efes.iucc.ac.il> <4CB5709F.1010102@unfix.org> Message-ID: <4CB57613.7090601@ripe.net> On 13/10/2010 10:41, Jeroen Massar wrote: > On 2010-10-13 10:25, Hank Nussbacher wrote: >> http://yro.slashdot.org/story/10/10/13/0044233/Dutch-Hotels-Must-Register-As >> -ISPs > > I don't see the problem here, they are generally already outsourcing the > "ISP" part anyway to a company, and that company is generally already a ISP. If I read the various links in the articles (most of them in Dutch), then one of the questions is if reselling services from an ISP, makes the reseller itself an ISP. The telecom regulatory body (OPTA) says yes, the association of hotel owners (KHN) says no. There are legal arguments either way. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.xs4all.nl/~henku P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ I confirm today what I denied yesterday. Anonymous Politician. From web at typo.org Wed Oct 13 04:17:03 2010 From: web at typo.org (Wayne E. Bouchard) Date: Wed, 13 Oct 2010 02:17:03 -0700 Subject: Dutch Hotels Must Register As ISPs In-Reply-To: <4CB57613.7090601@ripe.net> References: <5.1.0.14.2.20101013102446.00bfa7b0@efes.iucc.ac.il> <4CB5709F.1010102@unfix.org> <4CB57613.7090601@ripe.net> Message-ID: <20101013091703.GA78375@typo.org> Okay, if we go down that road, that makes Starbucks, Borders, a number of restaurants, and any other place that offers publically accessible wifi (free or otherwise) an ISP. If they start to increase the burden on these businesses, expect to see wifi hotspots diminish. IMO, that classification would be a bad thing. On Wed, Oct 13, 2010 at 11:04:19AM +0200, Henk Uijterwaal wrote: > On 13/10/2010 10:41, Jeroen Massar wrote: > > On 2010-10-13 10:25, Hank Nussbacher wrote: > >> http://yro.slashdot.org/story/10/10/13/0044233/Dutch-Hotels-Must-Register-As > >> -ISPs > > > > I don't see the problem here, they are generally already outsourcing the > > "ISP" part anyway to a company, and that company is generally already a ISP. > > If I read the various links in the articles (most of them in Dutch), then > one of the questions is if reselling services from an ISP, makes the > reseller itself an ISP. The telecom regulatory body (OPTA) says yes, the > association of hotel owners (KHN) says no. There are legal arguments either > way. > > Henk > > -- > ------------------------------------------------------------------------------ > Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net > RIPE Network Coordination Centre http://www.xs4all.nl/~henku > P.O.Box 10096 Singel 258 Phone: +31.20.5354414 > 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 > The Netherlands The Netherlands Mobile: +31.6.55861746 > ------------------------------------------------------------------------------ > > I confirm today what I denied yesterday. Anonymous Politician. --- Wayne Bouchard web at typo.org Network Dude http://www.typo.org/~web/ From cb.list6 at gmail.com Wed Oct 13 08:43:39 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Wed, 13 Oct 2010 06:43:39 -0700 Subject: T-Mobile USA - Peering Policy In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC0300A923@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC0300A923@EXVBE005-2.exch005intermedia.net> Message-ID: On Tue, Oct 12, 2010 at 9:28 PM, Ryan Finnesey wrote: > Can someone on the list from T-Mobile USA please contact me. ?I have > tried sending a message to admin at tmodns.net but the message bounces back > and the mailbox for arintechcontact at t-mobile.com is full. ? I am trying > to find out information regarding there peering policy. > You can contact me off-list for T-Mobile USA questions. Cameron From jcurran at arin.net Wed Oct 13 10:31:23 2010 From: jcurran at arin.net (John Curran) Date: Wed, 13 Oct 2010 11:31:23 -0400 Subject: Vote Now for the ARIN 2010 Board and AC Elections References: <4CB5CD90.4090401@arin.net> Message-ID: <7DBBDAE9-18FA-4A64-8226-5FF7AA994332@arin.net> NANOG Community - Apologies for the cross-post, but the outcome of the ARIN Advisory Council and Board of Trustees elections can significantly effect both the policies and operations of ARIN in the future, with corresponding effects on this community. I've spared this community numerous announcements of the election process, but I would be remiss if we did not post one reminder about the election to this community: ** To the extent that you are an ARIN Member, please participate in these elections ASAP! You have just over 72 hours to do so! Further information is attached for reference. Thanks! /John John Curran President and CEO ARIN --- Begin forwarded message: From: ARIN > Date: October 13, 2010 11:17:36 AM EDT To: arin-announce at arin.net Subject: [arin-announce] Vote Now for the 2010 Board and AC Elections The polls remain open for the election to fill two (2) seats on the ARIN Board of Trustees and five (5) seats on ARIN Advisory Council. The polls will close at 3:00 PM EDT on 16 October. You must be the designated member representative (DMR) from a General Member in good standing to vote. As stated in previous announcements, the deadline for establishing voter eligibility was 21 September 2010. Brief candidate biographies, a link to submit or view statements of support, videos of candidate speeches, and the voting "booth" itself can be found through ARIN Election Headquarters at: https://www.arin.net/app/election/ The online election is a two-step process. Step 1. Register to vote using the DMR email on file with ARIN?s Member Services Department. The email address must include the DMR?s name or initials and organization?s domain name. Step 2. Vote and confirm the vote via the online voting booth. Only confirmed votes will be counted. Designated member representatives must cast and confirm their ballots by 3:00 EDT, 16 October. Don?t wait until the last minute to cast your vote. If you have any questions about voting or encounter problems with the system, please contact us at info at arin.net. Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-Announce From jamesmartin at ieee.org Wed Oct 13 10:32:00 2010 From: jamesmartin at ieee.org (James Martin) Date: Wed, 13 Oct 2010 11:32:00 -0400 Subject: Google Mail Contact Message-ID: Hi: Can someone from Google's mail/blacklist/whitelist group contact me offlist? Thanks, James Martin From bzs at world.std.com Wed Oct 13 11:42:10 2010 From: bzs at world.std.com (Barry Shein) Date: Wed, 13 Oct 2010 12:42:10 -0400 Subject: Dutch Hotels Must Register As ISPs In-Reply-To: <20101013091703.GA78375@typo.org> References: <5.1.0.14.2.20101013102446.00bfa7b0@efes.iucc.ac.il> <4CB5709F.1010102@unfix.org> <4CB57613.7090601@ripe.net> <20101013091703.GA78375@typo.org> Message-ID: <19637.57698.894086.238970@world.std.com> It really seems like a case of "if my grandmother had wheels she'd be a trolley car". -- -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 manavbhatia at gmail.com Wed Oct 13 11:43:39 2010 From: manavbhatia at gmail.com (Manav Bhatia) Date: Wed, 13 Oct 2010 22:13:39 +0530 Subject: Using crypto auth for detecting corrupted IGP packets? In-Reply-To: References: Message-ID: Hi, I received 7 replies of which 3 stated that they were using crypto to only detect the issues that i have described in my email below. Another 3 said that they were using it for authentication and 1 person replied saying that they were using crypto for both authentication and integrity. Folks who are using cryptographic authentication mechanisms only for integrity may want to look at http://www.ietf.org/id/draft-jakma-ospf-integrity-00.txt Cheers, Manav On Fri, Oct 1, 2010 at 9:04 AM, Manav Bhatia wrote: > Hi, > > I believe, based on what i have heard, ?that some operators turn on > cryptographic authentication because the internet checksum that OSPF, > etc use for packet sanity is quite weak and offers trifle little > protection against lot of known errors like: > > - re-ordering of 2-byte aligned words > - various bit flips that keep the 1s complement sum the same (e.g. > 0x0000 to 0xffff and vice versa) > > So a corrupted packet could still pass the ethernet CRC checks and IP > and OSPF checksums. Or it could be valid till the ethernet CRC check > is done and gets corrupted after that (PCI transmission errors, DMA > errors, memory issues, line card corruption and last but not the > least, CRCs and internet checksums could miss wire-corrupted packets) > > Currently an operator can do the following: > > - Use the poor internet checksum OR > > - Turn on cryptographic authentication in the routing protocols to > catch all such bit errors which could be caused by line card > corruption, etc. > > One can go through http://portal.acm.org/citation.cfm?id=294357.294364 > to understand the issues with the internet ?checksums. > > I would be interested in knowing if operators use the cryptographic > authentication for detecting the errors that i just described above. > You could send me a mail offline and i will consolidate the responses > and send a summary on the list in a few days time. > > Cheers, Manav > From bonomi at mail.r-bonomi.com Wed Oct 13 12:19:45 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Wed, 13 Oct 2010 12:19:45 -0500 (CDT) Subject: AS22558 - Routing apparently hijacked space Message-ID: <201010131719.o9DHJj5q001340@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Tue Oct 12 04:00:19 2010 > To: nanog at nanog.org > Subject: AS22558 - Routing apparently hijacked space > Date: Tue, 12 Oct 2010 02:01:32 -0700 > From: "Ronald F. Guilmette" > > > I can't take credit for finding this one. Somebody else on another > mailing list I'm on actually found it. > > AS22558 itself _does not_ appear to be hijacked. Rather this is > a relatively new (2009) AS, but the AS itself is very odd indeed. > > It's contact phone number isn't working, it apparently has no web site > associated with its domain name (mpgnetworks.com) and although the whois > record clearly indicates that the company behind this AS is located in > California, the California Secretary of State's web site has no record > of any "MPG Networks, LLC" operating legally within California. The whois record is also suspect. A little bird tells me tht there is is no 'suite 411' at 707 Wilshire. > ===================================================================== > ASNumber: 22558 > ASName: MPGNET > ASHandle: AS22558 > RegDate: 2010-01-27 > Updated: 2010-01-27 > Ref: http://whois.arin.net/rest/asn/AS22558 > > OrgName: MPG Networks, LLC > OrgId: MPGNE > Address: 707 Wilshire, suite 411 > City: Los Angeles > StateProv: CA > PostalCode: 90017 > Country: US > RegDate: 2009-11-03 > Updated: 2009-11-03 From fw at deneb.enyo.de Wed Oct 13 14:20:30 2010 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 13 Oct 2010 21:20:30 +0200 Subject: Dutch Hotels Must Register As ISPs In-Reply-To: <20101013091703.GA78375@typo.org> (Wayne E. Bouchard's message of "Wed, 13 Oct 2010 02:17:03 -0700") References: <5.1.0.14.2.20101013102446.00bfa7b0@efes.iucc.ac.il> <4CB5709F.1010102@unfix.org> <4CB57613.7090601@ripe.net> <20101013091703.GA78375@typo.org> Message-ID: <87pqvdnblt.fsf@mid.deneb.enyo.de> * Wayne E. Bouchard: > Okay, if we go down that road, that makes Starbucks, Borders, a number > of restaurants, and any other place that offers publically accessible > wifi (free or otherwise) an ISP. The funny thing is that you actually want to be recognized as an ISP if you have transit traffic because it tends to shield you from liability if your customer does something stupid. From JArchambeau at core3solutions.com Wed Oct 13 14:54:57 2010 From: JArchambeau at core3solutions.com (Jeff Archambeau) Date: Wed, 13 Oct 2010 15:54:57 -0400 Subject: Request : Yahoo contact Message-ID: <445CE0F813207E41812C59E9DD933D0A66E02AFB5F@HERMES.core3solutions.local> I am having an email issue with yahoo's email blacklists and their auto-responses have been less than helpful. If there is a yahoo mail administrator on this list, would you please contact me off-list so we can discuss the issue and help me resolve this? Thanks. Jeff Archambeau Core3 Solutions LLC jarchambeau at core3solutions.com Technology: Undivided www.core3solutions.com 248.530.1001 (Ext. 108) :: Office 248.498.6098 :: Fax 248.530.1001 :: Helpdesk From ryanshea at google.com Wed Oct 13 20:19:19 2010 From: ryanshea at google.com (Ryan Shea) Date: Wed, 13 Oct 2010 21:19:19 -0400 Subject: Request : Yahoo contact In-Reply-To: <445CE0F813207E41812C59E9DD933D0A66E02AFB5F@HERMES.core3solutions.local> References: <445CE0F813207E41812C59E9DD933D0A66E02AFB5F@HERMES.core3solutions.local> Message-ID: Jeff I had the same situation last week. Yahoo! was nice enough to send a survey after ignoring my questions and concerns. It may be interesting to others (or at least me) how you fare in your adventure to get removed from their blacklist. -Ryan On Wed, Oct 13, 2010 at 3:54 PM, Jeff Archambeau < JArchambeau at core3solutions.com> wrote: > I am having an email issue with yahoo's email blacklists and their > auto-responses have been less than helpful. If there is a yahoo mail > administrator on this list, would you please contact me off-list so we can > discuss the issue and help me resolve this? > > Thanks. > > Jeff Archambeau > Core3 Solutions LLC > jarchambeau at core3solutions.com > > Technology: Undivided > www.core3solutions.com > 248.530.1001 (Ext. 108) :: Office > 248.498.6098 :: Fax > 248.530.1001 :: Helpdesk > > From ops.lists at gmail.com Thu Oct 14 00:57:41 2010 From: ops.lists at gmail.com (Suresh Ramasubramanian) Date: Thu, 14 Oct 2010 11:27:41 +0530 Subject: Dutch Hotels Must Register As ISPs In-Reply-To: <20101013091703.GA78375@typo.org> References: <5.1.0.14.2.20101013102446.00bfa7b0@efes.iucc.ac.il> <4CB5709F.1010102@unfix.org> <4CB57613.7090601@ripe.net> <20101013091703.GA78375@typo.org> Message-ID: Oh I dont know. There's lots of hotels that charge something like 20 Euro for a day's worth of wifi [the same with paris airport] You can get a month's worth of high speed dsl for 20 euro. So, what's sauce for the goose is sauce for the gander, or however that translates into dutch. On Wed, Oct 13, 2010 at 2:47 PM, Wayne E. Bouchard wrote: > Okay, if we go down that road, that makes Starbucks, Borders, a number > of restaurants, and any other place that offers publically accessible > wifi (free or otherwise) an ISP. If they start to increase the burden > on these businesses, expect to see wifi hotspots diminish. IMO, that > classification would be a bad thing. -- Suresh Ramasubramanian (ops.lists at gmail.com) From andrew.wallace at rocketmail.com Thu Oct 14 05:53:13 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 14 Oct 2010 03:53:13 -0700 (PDT) Subject: Google groups outage Message-ID: <275019.96155.qm@web59604.mail.ac4.yahoo.com> 500 server error for a long time. http://groups.google.com/ Andrew From hank at efes.iucc.ac.il Thu Oct 14 06:03:24 2010 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 14 Oct 2010 13:03:24 +0200 Subject: Google groups outage In-Reply-To: <275019.96155.qm@web59604.mail.ac4.yahoo.com> Message-ID: <5.1.0.14.2.20101014125836.0357b928@efes.iucc.ac.il> At 03:53 14/10/2010 -0700, andrew.wallace wrote: >500 server error for a long time. > >http://groups.google.com/ > >Andrew Google Groups is the most poor managed project in Google. No one really cares much about it inside Google (my view as an external user). Go try to find some of the older Usenet postings they imported years ago after they bought out Dejanews. You won't find much. I've reported bugs (search function, language search, etc.) over the past 3 years to them via their Groups forums and other means and basically they all end up in dev/null. -Hank From andrew.wallace at rocketmail.com Thu Oct 14 06:03:28 2010 From: andrew.wallace at rocketmail.com (andrew.wallace) Date: Thu, 14 Oct 2010 04:03:28 -0700 (PDT) Subject: Google groups outage Message-ID: <664423.62984.qm@web59609.mail.ac4.yahoo.com> Issue is corrected, apologies. ----- Original Message ---- From: andrew.wallace To: nanog at nanog.org Sent: Thu, 14 October, 2010 11:53:13 Subject: Google groups outage 500 server error for a long time. http://groups.google.com/ Andrew From jcdill.lists at gmail.com Thu Oct 14 09:27:38 2010 From: jcdill.lists at gmail.com (JC Dill) Date: Thu, 14 Oct 2010 07:27:38 -0700 Subject: Google groups outage In-Reply-To: <5.1.0.14.2.20101014125836.0357b928@efes.iucc.ac.il> References: <5.1.0.14.2.20101014125836.0357b928@efes.iucc.ac.il> Message-ID: <4CB7135A.30001@gmail.com> Hank Nussbacher wrote: > > Google Groups is the most poor managed project in Google. No one > really cares much about it inside Google (my view as an external > user). Go try to find some of the older Usenet postings they imported > years ago after they bought out Dejanews. You won't find much. I've > reported bugs (search function, language search, etc.) over the past 3 > years to them via their Groups forums and other means and basically > they all end up in dev/null. This is true for many of Google's projects. I believe it's an artifact of their "20%" policy. People are given work assignments on projects that Google wants improvements on, and then in 20% of their time they can work on projects of their own choosing. I believe that many (most?) of Google's abandoned projects were 20% projects, and their supporters did the first 90%[1] then got bored (lazy) and moved on to something new(er) and more exciting. I'm pretty sure Orkut and Google Groups were both 20% projects that have since been essentially abandoned. And don't get me started on Android. The mapping and navigation software on Android sucks so many different ways that I'm surprised that Google allowed it out into the real world, nevermind providing it on shipping products. It's been this broken for over a year, so obviously there isn't anyone inside Google who cares to fix the obvious problems. Whoever it was that developed these aps to this 90% state, has moved on to some new(er) and more exciting 20% project. jc [1] http://en.wikipedia.org/wiki/Ninety-ninety_rule From dylan.ebner at crlmed.com Thu Oct 14 09:53:37 2010 From: dylan.ebner at crlmed.com (Dylan Ebner) Date: Thu, 14 Oct 2010 14:53:37 +0000 Subject: Co-Lo and Connectivity options in Kuwait Message-ID: <017265BF3B9640499754DD48777C3D206A0E90C998@MBX9.EXCHPROD.USA.NET> Does anyone have any experience with Co-lo and connectivity in Kuwait. This would be my first time depolying in the middle east. Any advice, experiences anyone wishes to share is welcome. Thanks Dylan Ebner From joe at riversidecg.com Thu Oct 14 09:42:21 2010 From: joe at riversidecg.com (Joe Johnson) Date: Thu, 14 Oct 2010 09:42:21 -0500 Subject: Google groups outage In-Reply-To: <4CB7135A.30001@gmail.com> References: <5.1.0.14.2.20101014125836.0357b928@efes.iucc.ac.il> <4CB7135A.30001@gmail.com> Message-ID: My favorite is my Droid telling me I'm not driving on a road while on one of the biggest expressways in Chicago. Then, sometimes it decides to route me through Kansas to get somewhere less than a mile from my house. Joe Johnson Chief Information Officer Riverside Consulting Group, Ltd. Innovative Technology Solutions 365 Addison Road Riverside, Illinois 60546 Phone: 708.442.6033 x3456 Fax: 708.442.9722 joe at riversidecg.com www.riversidecg.com -----Original Message----- From: JC Dill [mailto:jcdill.lists at gmail.com] Sent: Thursday, October 14, 2010 9:28 AM Cc: nanog at nanog.org Subject: Re: Google groups outage Hank Nussbacher wrote: > > Google Groups is the most poor managed project in Google. No one > really cares much about it inside Google (my view as an external > user). Go try to find some of the older Usenet postings they imported > years ago after they bought out Dejanews. You won't find much. I've > reported bugs (search function, language search, etc.) over the past 3 > years to them via their Groups forums and other means and basically > they all end up in dev/null. This is true for many of Google's projects. I believe it's an artifact of their "20%" policy. People are given work assignments on projects that Google wants improvements on, and then in 20% of their time they can work on projects of their own choosing. I believe that many (most?) of Google's abandoned projects were 20% projects, and their supporters did the first 90%[1] then got bored (lazy) and moved on to something new(er) and more exciting. I'm pretty sure Orkut and Google Groups were both 20% projects that have since been essentially abandoned. And don't get me started on Android. The mapping and navigation software on Android sucks so many different ways that I'm surprised that Google allowed it out into the real world, nevermind providing it on shipping products. It's been this broken for over a year, so obviously there isn't anyone inside Google who cares to fix the obvious problems. Whoever it was that developed these aps to this 90% state, has moved on to some new(er) and more exciting 20% project. jc [1] http://en.wikipedia.org/wiki/Ninety-ninety_rule From johndole at hush.ai Thu Oct 14 11:03:23 2010 From: johndole at hush.ai (johndole at hush.ai) Date: Thu, 14 Oct 2010 12:03:23 -0400 Subject: How to have open more than 65k concurrent connections? Message-ID: <20101014160323.895591B507A@smtp.hushmail.com> Hi, I am somewhat new to networking. I have interest in running a Bittorrent tracker. I ran one for a bit, and my one Linux box running Opentracker gets overloaded. My connection is good, and most of it isn't being used. Just a lot of people connect, and use up all the 65k "free connections". I tried messing with the sysctls, but it didn't help too much (and just degraded the connection quality for everyone). It is not a malicious attack either as there is only a few connections per IP and they are sending proper Bittorrent tracker requests... So what can I do? How can I have have open more than 65k concurrent connections on standard GNU/Linux? Thanks for any ideas and suggestions. -John From jmamodio at gmail.com Thu Oct 14 11:32:21 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Thu, 14 Oct 2010 11:32:21 -0500 Subject: How to have open more than 65k concurrent connections? In-Reply-To: <20101014160323.895591B507A@smtp.hushmail.com> References: <20101014160323.895591B507A@smtp.hushmail.com> Message-ID: you have only 16-bits for port numbers. -J From swmike at swm.pp.se Thu Oct 14 11:39:17 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Thu, 14 Oct 2010 18:39:17 +0200 (CEST) Subject: How to have open more than 65k concurrent connections? In-Reply-To: <20101014160323.895591B507A@smtp.hushmail.com> References: <20101014160323.895591B507A@smtp.hushmail.com> Message-ID: On Thu, 14 Oct 2010, johndole at hush.ai wrote: > So what can I do? How can I have have open more than 65k concurrent > connections on standard GNU/Linux? This is not a networking (=moving IP packets) problem, this is a Linux problem. I'm sure it can be done, but nanog is not the place to look for it. -- Mikael Abrahamsson email: swmike at swm.pp.se From regnauld at nsrc.org Thu Oct 14 11:41:10 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 14 Oct 2010 18:41:10 +0200 Subject: How to have open more than 65k concurrent connections? In-Reply-To: References: <20101014160323.895591B507A@smtp.hushmail.com> Message-ID: <20101014164109.GP23238@macbook.catpipe.net> Jorge Amodio (jmamodio) writes: > you have only 16-bits for port numbers. 65k port numbers != number of connections. The number of open connections (if we're talking TCP) is limited by the number of max file descriptors in the kernel (fs.file_max). See also: http://www.network-builders.com/maximum-simultaneous-network-connections-t56317.html You could have hundreds of thousands of connections to the same (destination IP, destination port). In practice, there are other limitations: http://www.kegel.com/c10k.html is good reading, even though it is a few years old. From darcy at druid.net Thu Oct 14 11:42:04 2010 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Thu, 14 Oct 2010 12:42:04 -0400 Subject: How to have open more than 65k concurrent connections? In-Reply-To: References: <20101014160323.895591B507A@smtp.hushmail.com> Message-ID: <20101014124204.8cd08314.darcy@druid.net> On Thu, 14 Oct 2010 11:32:21 -0500 Jorge Amodio wrote: > you have only 16-bits for port numbers. Hint: That gives you 65K connections *per interface*. You can listen on more than one interface. This is probably off topic for this list though. The OP needs to find a network *programming* mailing list or forum. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From joelja at bogus.com Thu Oct 14 11:53:21 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 14 Oct 2010 09:53:21 -0700 Subject: How to have open more than 65k concurrent connections? In-Reply-To: <20101014160323.895591B507A@smtp.hushmail.com> References: <20101014160323.895591B507A@smtp.hushmail.com> Message-ID: <4CB73581.5040107@bogus.com> An incoming connection chews up an file descripter but does not require an ephemeral port. You can trivially have more that 65k incoming connections on a linux box, but you've only got 64511 ports per ip on the box, to use for outgoing connections. I've seen boxes supporting more than a million connections with tuning in the course of normal operation. On 10/14/10 9:03 AM, johndole at hush.ai wrote: > Hi, > > I am somewhat new to networking. I have interest in running a > Bittorrent tracker. I ran one for a bit, and my one Linux box > running Opentracker gets overloaded. My connection is good, and > most of it isn't being used. Just a lot of people connect, and use > up all the 65k "free connections". I tried messing with the > sysctls, but it didn't help too much (and just degraded the > connection quality for everyone). It is not a malicious attack > either as there is only a few connections per IP and they are > sending proper Bittorrent tracker requests... > > So what can I do? How can I have have open more than 65k concurrent > connections on standard GNU/Linux? > > Thanks for any ideas and suggestions. > > -John > > From Greg.Whynott at oicr.on.ca Thu Oct 14 11:54:05 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Thu, 14 Oct 2010 12:54:05 -0400 Subject: How to have open more than 65k concurrent connections? In-Reply-To: <20101014124204.8cd08314.darcy@druid.net> References: <20101014160323.895591B507A@smtp.hushmail.com> <20101014124204.8cd08314.darcy@druid.net> Message-ID: this has nothing to do with ports. as others have said, think of a web server. httpd listens on tcp80 (maybe 443 too) and all the facebooker's on earth hit that port. could be hundreds of thousands, and only one port. Available memory and open files will be the limiting factor as to how many established connections you can maintain with one host, providing there are not any external limitations such as port speed. On Oct 14, 2010, at 12:42 PM, D'Arcy J.M. Cain wrote: > > Hint: That gives you 65K connections *per interface*. You can listen > on more than one interface. -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From if at xip.at Thu Oct 14 12:01:31 2010 From: if at xip.at (Ingo Flaschberger) Date: Thu, 14 Oct 2010 19:01:31 +0200 (CEST) Subject: How to have open more than 65k concurrent connections? In-Reply-To: References: <20101014160323.895591B507A@smtp.hushmail.com> <20101014124204.8cd08314.darcy@druid.net> Message-ID: and do not forget the ulimit and select limit of maximum open selects - but can be tuned. From simon.perreault at viagenie.ca Thu Oct 14 12:07:15 2010 From: simon.perreault at viagenie.ca (Simon Perreault) Date: Thu, 14 Oct 2010 13:07:15 -0400 Subject: How to have open more than 65k concurrent connections? In-Reply-To: <4CB73581.5040107@bogus.com> References: <20101014160323.895591B507A@smtp.hushmail.com> <4CB73581.5040107@bogus.com> Message-ID: <4CB738C3.6010505@viagenie.ca> On 2010-10-14 12:53, Joel Jaeggli wrote: > you've only got 64511 ports per ip on the box, to use for > outgoing connections. As long as you're not connecting to the same destination IP/port pair, the same source IP/port pair can be reused. So even for outgoing connections there is virtually no limit. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From linkconnect at googlemail.com Thu Oct 14 12:33:20 2010 From: linkconnect at googlemail.com (Wayne Lee) Date: Thu, 14 Oct 2010 18:33:20 +0100 Subject: How to have open more than 65k concurrent connections? In-Reply-To: <4CB738C3.6010505@viagenie.ca> References: <20101014160323.895591B507A@smtp.hushmail.com> <4CB73581.5040107@bogus.com> <4CB738C3.6010505@viagenie.ca> Message-ID: > On 2010-10-14 12:53, Joel Jaeggli wrote: >> you've only got 64511 ports per ip ?on the box, to use for >> outgoing connections. > > As long as you're not connecting to the same destination IP/port pair, > the same source IP/port pair can be reused. So even for outgoing > connections there is virtually no limit. I suspect it has more to do with NAT connection tracking on his DSL router. Wayne From bpfankuch at cpgreeley.com Thu Oct 14 12:37:29 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Thu, 14 Oct 2010 11:37:29 -0600 Subject: How to have open more than 65k concurrent connections? In-Reply-To: <4CB738C3.6010505@viagenie.ca> References: <20101014160323.895591B507A@smtp.hushmail.com> <4CB73581.5040107@bogus.com> <4CB738C3.6010505@viagenie.ca> Message-ID: <01759D50DC387C45A018FE1817CE27D77E3DFDD2FD@CPExchange1.cpgreeley.com> I believe the original poster was specifically requesting how to increase the File descriptor limits (ulimit -n) past 65k. This is where the limitation would come in most likely for connections he is talking about. As someone else said, probably not the best place for this, however you can look at /etc/security/limits.conf and play with soft and hard nofile limits. Try unlimited maybe. -----Original Message----- From: Simon Perreault [mailto:simon.perreault at viagenie.ca] Sent: Thursday, October 14, 2010 11:07 AM To: nanog at nanog.org Subject: Re: How to have open more than 65k concurrent connections? On 2010-10-14 12:53, Joel Jaeggli wrote: > you've only got 64511 ports per ip on the box, to use for outgoing > connections. As long as you're not connecting to the same destination IP/port pair, the same source IP/port pair can be reused. So even for outgoing connections there is virtually no limit. Simon -- NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From Rod.Beck at hiberniaatlantic.com Thu Oct 14 13:34:18 2010 From: Rod.Beck at hiberniaatlantic.com (Rod Beck) Date: Thu, 14 Oct 2010 19:34:18 +0100 Subject: Co-Lo and Connectivity options in Kuwait References: <017265BF3B9640499754DD48777C3D206A0E90C998@MBX9.EXCHPROD.USA.NET> Message-ID: <1E8B940C5E21014AB8BE70B975D40EDB0395855B@bert.HiberniaAtlantic.local> Good luck. }The Middle East is generally a horror. Prices are sky high. Roderick S. Beck Director of European Sales Hibernia Atlantic Budapest, New York, and Paris -----Original Message----- From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] Sent: Thu 10/14/2010 3:53 PM To: nanog at nanog.org Subject: Co-Lo and Connectivity options in Kuwait Does anyone have any experience with Co-lo and connectivity in Kuwait. This would be my first time depolying in the middle east. Any advice, experiences anyone wishes to share is welcome. Thanks Dylan Ebner From bkowalewicz at hostopia.com Thu Oct 14 13:41:26 2010 From: bkowalewicz at hostopia.com (bkowalewicz at hostopia.com) Date: Thu, 14 Oct 2010 14:41:26 -0400 Subject: Gmail Contact needed Message-ID: <20101014144126.oy3msv99u6800cck@webmail.hostopia.com> ? Hello, I am hoping to get in contact with a mail admin for Gmail/Google. We are having problems with spam/bulk filtering. Can someone contact me off list? ? Thanks, ? Brian Kowalewicz Abuse and Postmaster Services bkowalewicz at hostopia.com ? From jeffrey.lyon at blacklotus.net Thu Oct 14 13:48:45 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Thu, 14 Oct 2010 23:18:45 +0430 Subject: Co-Lo and Connectivity options in Kuwait In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB0395855B@bert.HiberniaAtlantic.local> References: <017265BF3B9640499754DD48777C3D206A0E90C998@MBX9.EXCHPROD.USA.NET> <1E8B940C5E21014AB8BE70B975D40EDB0395855B@bert.HiberniaAtlantic.local> Message-ID: I had a GSM connection to Wataniya. Awesome speeds locally, horrendous speeds to other parts of the world. Downloads from Iran were the only ones I remember being even relatively high speed. Jeff On Thu, Oct 14, 2010 at 11:04 PM, Rod Beck wrote: > Good luck. }The Middle East is generally a horror. Prices are sky high. > > Roderick S. Beck > Director of European Sales > Hibernia Atlantic > Budapest, New York, and Paris > > -----Original Message----- > From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] > Sent: Thu 10/14/2010 3:53 PM > To: nanog at nanog.org > Subject: Co-Lo and Connectivity options in Kuwait > > Does anyone have any experience with Co-lo and connectivity in Kuwait. This would be my first time depolying in the middle east. Any advice, experiences anyone wishes to share is welcome. > > Thanks > > > > Dylan Ebner > > > -- 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 simon at darkmere.gen.nz Thu Oct 14 13:49:37 2010 From: simon at darkmere.gen.nz (Simon Lyall) Date: Fri, 15 Oct 2010 07:49:37 +1300 (NZDT) Subject: How to have open more than 65k concurrent connections? In-Reply-To: <20101014160323.895591B507A@smtp.hushmail.com> References: <20101014160323.895591B507A@smtp.hushmail.com> Message-ID: On Thu, 14 Oct 2010, johndole at hush.ai wrote: > So what can I do? How can I have have open more than 65k concurrent > connections on standard GNU/Linux? Google around for "C500K" ( a reference to the old C10K ) which urbanairship recently posted about. Here are a few of the articles that should put you on the right track: http://blog.urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/ http://blog.urbanairship.com/blog/2010/09/29/linux-kernel-tuning-for-c500k/ http://news.ycombinator.com/item?id=1740823 -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT. From darcy at druid.net Thu Oct 14 14:58:41 2010 From: darcy at druid.net (D'Arcy J.M. Cain) Date: Thu, 14 Oct 2010 15:58:41 -0400 Subject: How to have open more than 65k concurrent connections? In-Reply-To: References: <20101014160323.895591B507A@smtp.hushmail.com> <20101014124204.8cd08314.darcy@druid.net> Message-ID: <20101014155841.a7329ba7.darcy@druid.net> On Thu, 14 Oct 2010 12:54:05 -0400 Greg Whynott wrote: > this has nothing to do with ports. as others have said, think of > a web server. httpd listens on tcp80 (maybe 443 too) and all the > facebooker's on earth hit that port. could be hundreds of thousands, > and only one port. Available memory and open files will be the > limiting factor as to how many established connections you can maintain > with one host, providing there are not any external limitations such > as port speed. You are correct. Brain fart here. I actually had to pull Stevens off the shelf for a quick refresher. Of course, every TCP connection is different but only includes one port on the server. The five-tuple that defines the connection includes the remote host (client) and port which is always unique at any one time. Other than local resource limits the total combinations is technically 256**6, i.e. every IP address times the number of ports. That's not even including IPV6. Still off-topic here though. The OP still needs to find the correct group to figure out his real problem. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner. From zaid at zaidali.com Thu Oct 14 18:12:10 2010 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 14 Oct 2010 16:12:10 -0700 Subject: MsgSent statistics question Message-ID: I am trying to troubleshoot an odd v6 peering connection issue. Does anyone know at what point is MsgSent in BGP summary or neighbor summary calculated? Does the MsgSent include initial TCP connections before establishment? Thanks, Zaid From rjubio at gmail.com Fri Oct 15 00:49:49 2010 From: rjubio at gmail.com (Rod James Bio) Date: Fri, 15 Oct 2010 13:49:49 +0800 Subject: IPv6 Stateless Configuration Message-ID: Hi, First time poster here. I would just like to ask what are the flags on router advertisement to enable a host to autoconfigure its IPv6 address. There is this device that I'm configuring that I cant get RA to work. I was able to work out the connectivity from the device to the IPv6 internet, but the problem is host behind this device is not getting its unique global ipv6 address. The device is a cyberoam UTM. Thanks! Rod Bio. From franck at genius.com Fri Oct 15 02:04:54 2010 From: franck at genius.com (Franck Martin) Date: Fri, 15 Oct 2010 19:04:54 +1200 Subject: IPv6 Stateless Configuration In-Reply-To: References: Message-ID: You need all to be part of the same Ethernet network. So if this UTM can act as a bridge/switch you should be ok. Otherwise the RA broadcasts need to reach your device so it guesses the network and add it's Mac address to the network and make an ipv6 address. I would say RA is a bit like DHCP in your case in terms of network topology but beside that RA is simpler (no leases table). Toute connaissance est une r?ponse ? une question On 15/10/2010, at 17:49, Rod James Bio wrote: > Hi, > > First time poster here. I would just like to ask what are the flags on > router advertisement to enable a host to autoconfigure its IPv6 address. > There is this device that I'm configuring that I cant get RA to work. I was > able to work out the connectivity from the device to the IPv6 internet, but > the problem is host behind this device is not getting its unique global ipv6 > address. The device is a cyberoam UTM. > > Thanks! Rod Bio. From rjubio at gmail.com Fri Oct 15 02:11:07 2010 From: rjubio at gmail.com (Rod James Bio) Date: Fri, 15 Oct 2010 15:11:07 +0800 Subject: IPv6 Stateless Configuration In-Reply-To: References: Message-ID: That's my setup right now. The problem is the machine is not configuring its IPv6 address with RA already turned on. I'm guessing that the flag set on the UTM router advertisement messages is wrong. May I know the default flags use on a cisco router? Thanks. On Fri, Oct 15, 2010 at 3:04 PM, Franck Martin wrote: > You need all to be part of the same Ethernet network. So if this UTM can > act as a bridge/switch you should be ok. Otherwise the RA broadcasts need to > reach your device so it guesses the network and add it's Mac address to the > network and make an ipv6 address. > > I would say RA is a bit like DHCP in your case in terms of network topology > but beside that RA is simpler (no leases table). > > Toute connaissance est une r?ponse ? une question > > On 15/10/2010, at 17:49, Rod James Bio wrote: > > > Hi, > > > > First time poster here. I would just like to ask what are the flags on > > router advertisement to enable a host to autoconfigure its IPv6 address. > > There is this device that I'm configuring that I cant get RA to work. I > was > > able to work out the connectivity from the device to the IPv6 internet, > but > > the problem is host behind this device is not getting its unique global > ipv6 > > address. The device is a cyberoam UTM. > > > > Thanks! Rod Bio. > From swmike at swm.pp.se Fri Oct 15 02:19:19 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 15 Oct 2010 09:19:19 +0200 (CEST) Subject: IPv6 Stateless Configuration In-Reply-To: References: Message-ID: On Fri, 15 Oct 2010, Rod James Bio wrote: > That's my setup right now. The problem is the machine is not configuring its > IPv6 address with RA already turned on. I'm guessing that the flag set on > the UTM router advertisement messages is wrong. May I know the default flags > use on a cisco router? Thanks. The default is that M and O bits are off, ie hosts should do SLAAC and there is no DHCPv6 info to be had. -- Mikael Abrahamsson email: swmike at swm.pp.se From franck at genius.com Fri Oct 15 02:21:41 2010 From: franck at genius.com (Franck Martin) Date: Fri, 15 Oct 2010 19:21:41 +1200 (FJT) Subject: IPv6 Stateless Configuration In-Reply-To: Message-ID: <5162546.34.1287127297832.JavaMail.franck@franck-martins-macbook-pro.local> I have seen layer 2 devices not forwarding IPv6 packets (while forwarding IPv4 packets)... I would put a packet capture, and see if I see the RA packets coming from the router. On a Cisco router, RA is enabled by default and does not require any setting. ----- Original Message ----- From: "Rod James Bio" To: "Franck Martin" Cc: nanog at nanog.org Sent: Friday, 15 October, 2010 7:11:07 PM Subject: Re: IPv6 Stateless Configuration That's my setup right now. The problem is the machine is not configuring its IPv6 address with RA already turned on. I'm guessing that the flag set on the UTM router advertisement messages is wrong. May I know the default flags use on a cisco router? Thanks. On Fri, Oct 15, 2010 at 3:04 PM, Franck Martin < franck at genius.com > wrote: You need all to be part of the same Ethernet network. So if this UTM can act as a bridge/switch you should be ok. Otherwise the RA broadcasts need to reach your device so it guesses the network and add it's Mac address to the network and make an ipv6 address. I would say RA is a bit like DHCP in your case in terms of network topology but beside that RA is simpler (no leases table). Toute connaissance est une r?ponse ? une question On 15/10/2010, at 17:49, Rod James Bio < rjubio at gmail.com > wrote: > Hi, > > First time poster here. I would just like to ask what are the flags on > router advertisement to enable a host to autoconfigure its IPv6 address. > There is this device that I'm configuring that I cant get RA to work. I was > able to work out the connectivity from the device to the IPv6 internet, but > the problem is host behind this device is not getting its unique global ipv6 > address. The device is a cyberoam UTM. > > Thanks! Rod Bio. From pzhao at live.com Fri Oct 15 02:35:55 2010 From: pzhao at live.com (Zhao Ping) Date: Fri, 15 Oct 2010 15:35:55 +0800 Subject: IPv6 Stateless Configuration In-Reply-To: <5162546.34.1287127297832.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: Pay attention to the special layer 2 multicast address for the RA packet. On 10/15/10 3:21 PM, "Franck Martin" wrote: >I have seen layer 2 devices not forwarding IPv6 packets (while forwarding >IPv4 packets)... > >I would put a packet capture, and see if I see the RA packets coming from >the router. > >On a Cisco router, RA is enabled by default and does not require any >setting. > >----- Original Message ----- >From: "Rod James Bio" >To: "Franck Martin" >Cc: nanog at nanog.org >Sent: Friday, 15 October, 2010 7:11:07 PM >Subject: Re: IPv6 Stateless Configuration > >That's my setup right now. The problem is the machine is not configuring >its IPv6 address with RA already turned on. I'm guessing that the flag >set on the UTM router advertisement messages is wrong. May I know the >default flags use on a cisco router? Thanks. > > >On Fri, Oct 15, 2010 at 3:04 PM, Franck Martin < franck at genius.com > >wrote: > > >You need all to be part of the same Ethernet network. So if this UTM can >act as a bridge/switch you should be ok. Otherwise the RA broadcasts need >to reach your device so it guesses the network and add it's Mac address >to the network and make an ipv6 address. > >I would say RA is a bit like DHCP in your case in terms of network >topology but beside that RA is simpler (no leases table). > >Toute connaissance est une r?ponse ? une question > > > > >On 15/10/2010, at 17:49, Rod James Bio < rjubio at gmail.com > wrote: > >> Hi, >> >> First time poster here. I would just like to ask what are the flags on >> router advertisement to enable a host to autoconfigure its IPv6 >>address. >> There is this device that I'm configuring that I cant get RA to work. I >>was >> able to work out the connectivity from the device to the IPv6 internet, >>but >> the problem is host behind this device is not getting its unique global >>ipv6 >> address. The device is a cyberoam UTM. >> >> Thanks! Rod Bio. > > > From rjubio at gmail.com Fri Oct 15 02:45:53 2010 From: rjubio at gmail.com (Rod James Bio) Date: Fri, 15 Oct 2010 15:45:53 +0800 Subject: IPv6 Stateless Configuration In-Reply-To: References: Message-ID: Got it now. The preferredlifetime should be less than the value of the validlifetime option. Thanks BTW! :D On Fri, Oct 15, 2010 at 3:19 PM, Mikael Abrahamsson wrote: > On Fri, 15 Oct 2010, Rod James Bio wrote: > > That's my setup right now. The problem is the machine is not configuring >> its >> IPv6 address with RA already turned on. I'm guessing that the flag set on >> the UTM router advertisement messages is wrong. May I know the default >> flags >> use on a cisco router? Thanks. >> > > The default is that M and O bits are off, ie hosts should do SLAAC and > there is no DHCPv6 info to be had. > > -- > Mikael Abrahamsson email: swmike at swm.pp.se > From isabeldias1 at yahoo.com Fri Oct 15 09:39:22 2010 From: isabeldias1 at yahoo.com (isabel dias) Date: Fri, 15 Oct 2010 07:39:22 -0700 (PDT) Subject: MsgSent statistics question In-Reply-To: References: Message-ID: <841126.23717.qm@web52601.mail.re2.yahoo.com> http://hen.cs.ucl.ac.uk/library/hardware/routers/procket/20fcs/routing_protocols/bgp.verify19.html http://www.inetdaemon.com/tutorials/internet/ip/routing/bgp/operation/finite_state_model.shtml http://www.cymru.com/Documents/barry2.pdf I would check the latest version of the RFC and also the?IOS/BGP version you are running.......... ________________________________ From: Zaid Ali To: NANOG list Sent: Fri, October 15, 2010 12:12:10 AM Subject: MsgSent statistics question I am trying to troubleshoot an odd v6 peering connection issue. Does anyone know at what point is MsgSent in BGP summary or neighbor summary calculated? Does the MsgSent include initial TCP connections before establishment? Thanks, Zaid From cscora at apnic.net Fri Oct 15 13:29:12 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 16 Oct 2010 04:29:12 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201010151829.o9FITCS4022273@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 16 Oct, 2010 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 333673 Prefixes after maximum aggregation: 153173 Deaggregation factor: 2.18 Unique aggregates announced to Internet: 163976 Total ASes present in the Internet Routing Table: 34973 Prefixes per ASN: 9.54 Origin-only ASes present in the Internet Routing Table: 30332 Origin ASes announcing only one prefix: 14721 Transit ASes present in the Internet Routing Table: 4641 Transit-only ASes present in the Internet Routing Table: 102 Average AS path length visible in the Internet Routing Table: 3.6 Max AS path length visible: 24 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 334 Unregistered ASNs in the Routing Table: 124 Number of 32-bit ASNs allocated by the RIRs: 819 Prefixes from 32-bit ASNs in the Routing Table: 1161 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 216 Number of addresses announced to Internet: 2280874400 Equivalent to 135 /8s, 243 /16s and 97 /24s Percentage of available address space announced: 61.5 Percentage of allocated address space announced: 65.7 Percentage of available address space allocated: 93.7 Percentage of address space in use by end-sites: 85.3 Total number of prefixes smaller than registry allocations: 137157 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 81624 Total APNIC prefixes after maximum aggregation: 27931 APNIC Deaggregation factor: 2.92 Prefixes being announced from the APNIC address blocks: 78535 Unique aggregates announced from the APNIC address blocks: 34462 APNIC Region origin ASes present in the Internet Routing Table: 4204 APNIC Prefixes per ASN: 18.68 APNIC Region origin ASes announcing only one prefix: 1175 APNIC Region transit ASes present in the Internet Routing Table: 644 Average APNIC Region AS path length visible: 3.7 Max APNIC Region AS path length visible: 16 Number of APNIC addresses announced to Internet: 551962912 Equivalent to 32 /8s, 230 /16s and 73 /24s Percentage of available APNIC address space announced: 78.3 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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: 136292 Total ARIN prefixes after maximum aggregation: 70287 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108891 Unique aggregates announced from the ARIN address blocks: 43464 ARIN Region origin ASes present in the Internet Routing Table: 13949 ARIN Prefixes per ASN: 7.81 ARIN Region origin ASes announcing only one prefix: 5337 ARIN Region transit ASes present in the Internet Routing Table: 1381 Average ARIN Region AS path length visible: 3.4 Max ARIN Region AS path length visible: 22 Number of ARIN addresses announced to Internet: 737739008 Equivalent to 43 /8s, 249 /16s and 1 /24s Percentage of available ARIN address space announced: 62.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 76685 Total RIPE prefixes after maximum aggregation: 44471 RIPE Deaggregation factor: 1.72 Prefixes being announced from the RIPE address blocks: 70114 Unique aggregates announced from the RIPE address blocks: 45929 RIPE Region origin ASes present in the Internet Routing Table: 14880 RIPE Prefixes per ASN: 4.71 RIPE Region origin ASes announcing only one prefix: 7660 RIPE Region transit ASes present in the Internet Routing Table: 2244 Average RIPE Region AS path length visible: 3.9 Max RIPE Region AS path length visible: 24 Number of RIPE addresses announced to Internet: 441326464 Equivalent to 26 /8s, 78 /16s and 27 /24s Percentage of available RIPE address space announced: 77.4 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 30306 Total LACNIC prefixes after maximum aggregation: 7173 LACNIC Deaggregation factor: 4.23 Prefixes being announced from the LACNIC address blocks: 28998 Unique aggregates announced from the LACNIC address blocks: 15164 LACNIC Region origin ASes present in the Internet Routing Table: 1368 LACNIC Prefixes per ASN: 21.20 LACNIC Region origin ASes announcing only one prefix: 429 LACNIC Region transit ASes present in the Internet Routing Table: 237 Average LACNIC Region AS path length visible: 4.0 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 76206464 Equivalent to 4 /8s, 138 /16s and 209 /24s Percentage of available LACNIC address space announced: 56.8 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7350 Total AfriNIC prefixes after maximum aggregation: 1867 AfriNIC Deaggregation factor: 3.94 Prefixes being announced from the AfriNIC address blocks: 5664 Unique aggregates announced from the AfriNIC address blocks: 1769 AfriNIC Region origin ASes present in the Internet Routing Table: 405 AfriNIC Prefixes per ASN: 13.99 AfriNIC Region origin ASes announcing only one prefix: 120 AfriNIC Region transit ASes present in the Internet Routing Table: 92 Average AfriNIC Region AS path length visible: 3.8 Max AfriNIC Region AS path length visible: 17 Number of AfriNIC addresses announced to Internet: 20834560 Equivalent to 1 /8s, 61 /16s and 233 /24s Percentage of available AfriNIC address space announced: 62.1 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1872 9437 510 Korea Telecom (KIX) 7545 1412 297 80 TPG Internet Pty Ltd 4755 1373 382 157 TATA Communications formerly 17488 1364 156 121 Hathway IP Over Cable Interne 17974 1246 303 79 PT TELEKOMUNIKASI INDONESIA 9583 1034 77 497 Sify Limited 24560 1020 303 179 Bharti Airtel Ltd., Telemedia 4808 977 1739 267 CNCGROUP IP network: China169 18101 888 100 134 Reliance Infocom Ltd Internet 9829 822 694 27 BSNL National Internet Backbo 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 3770 3667 279 bellsouth.net, inc. 4323 2616 1119 393 Time Warner Telecom 1785 1797 698 130 PaeTec Communications, Inc. 19262 1777 4833 279 Verizon Global Networks 20115 1505 1526 647 Charter Communications 7018 1462 5728 935 AT&T WorldNet Services 6478 1384 280 121 AT&T Worldnet Services 2386 1307 555 923 AT&T Data Communications Serv 11492 1235 231 74 Cable One 22773 1205 2858 61 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 3292 449 2028 390 TDC Tele Danmark 8866 422 119 24 Bulgarian Telecommunication C 702 404 1869 318 UUNET - Commercial IP service 8551 402 353 46 Bezeq International 34984 381 91 184 BILISIM TELEKOM 3320 380 7332 331 Deutsche Telekom AG 3301 379 1688 335 TeliaNet Sweden 30890 375 80 204 Evolva Telecom 12479 374 576 5 Uni2 Autonomous System 31148 357 19 78 FreeNet ISP 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 8151 1341 2581 371 UniNet S.A. de C.V. 10620 1332 247 150 TVCABLE BOGOTA 28573 1182 909 88 NET Servicos de Comunicao S.A 7303 831 441 107 Telecom Argentina Stet-France 6503 761 223 259 AVANTEL, S.A. 22047 559 310 15 VTR PUNTO NET S.A. 14420 544 39 76 CORPORACION NACIONAL DE TELEC 3816 484 210 95 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A 14117 448 32 27 Telefonica del Sur 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 976 445 10 TEDATA 24863 712 146 44 LINKdotNET AS number 36992 641 278 167 Etisalat MISR 3741 266 906 224 The Internet Solution 6713 203 199 12 Itissalat Al-MAGHRIB 29571 203 19 11 Ci Telecom Autonomous system 2018 197 277 64 Tertiary Education Network 33776 196 12 14 Starcomms Nigeria Limited 24835 174 78 9 RAYA Telecom - Egypt 16637 154 440 91 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 3770 3667 279 bellsouth.net, inc. 4323 2616 1119 393 Time Warner Telecom 4766 1872 9437 510 Korea Telecom (KIX) 1785 1797 698 130 PaeTec Communications, Inc. 19262 1777 4833 279 Verizon Global Networks 20115 1505 1526 647 Charter Communications 7018 1462 5728 935 AT&T WorldNet Services 7545 1412 297 80 TPG Internet Pty Ltd 6478 1384 280 121 AT&T Worldnet Services 4755 1373 382 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 2616 2223 Time Warner Telecom 1785 1797 1667 PaeTec Communications, Inc. 19262 1777 1498 Verizon Global Networks 4766 1872 1362 Korea Telecom (KIX) 7545 1412 1332 TPG Internet Pty Ltd 6478 1384 1263 AT&T Worldnet Services 17488 1364 1243 Hathway IP Over Cable Interne 4755 1373 1216 TATA Communications formerly 10620 1332 1182 TVCABLE BOGOTA 17974 1246 1167 PT TELEKOMUNIKASI INDONESIA 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 7018 AT&T WorldNet Servic 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 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 46.20.224.0/20 39451 Melbourne Network Solutions c 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.21.192.0/20 11610 Internet Nebraska Corporation 64.21.212.0/22 11610 Internet Nebraska Corporation 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:10 /10:25 /11:67 /12:203 /13:420 /14:735 /15:1330 /16:11315 /17:5488 /18:9329 /19:18494 /20:23679 /21:23911 /22:31328 /23:30531 /24:173949 /25:983 /26:1102 /27:581 /28:153 /29:12 /30:2 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2334 3770 bellsouth.net, inc. 4323 1407 2616 Time Warner Telecom 6478 1346 1384 AT&T Worldnet Services 10620 1220 1332 TVCABLE BOGOTA 11492 1192 1235 Cable One 1785 1077 1797 PaeTec Communications, Inc. 18566 1069 1088 Covad Communications 7011 1056 1156 Citizens Utilities 19262 903 1777 Verizon Global Networks 8452 882 976 TEDATA Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:87 2:14 4:13 8:311 12:2011 13:8 14:34 15:20 16:3 17:9 20:9 24:1383 27:389 31:1 32:61 33:12 38:695 40:97 41:2454 44:3 46:163 47:11 49:4 50:1 52:12 55:3 56:2 57:29 58:832 59:500 60:479 61:1111 62:1027 63:1964 64:3746 65:2336 66:4062 67:1850 68:1144 69:2846 70:758 71:375 72:1940 73:2 74:2321 75:293 76:324 77:869 78:698 79:445 80:1043 81:805 82:493 83:450 84:685 85:1035 86:431 87:689 88:322 89:1556 90:105 91:3107 92:427 93:1020 94:1107 95:739 96:389 97:223 98:639 99:32 101:3 108:64 109:699 110:423 111:583 112:298 113:296 114:477 115:606 116:1115 117:658 118:541 119:979 120:196 121:722 122:1589 123:917 124:1228 125:1269 128:227 129:158 130:170 131:557 132:274 133:20 134:207 135:46 136:207 137:140 138:278 139:109 140:478 141:197 142:348 143:386 144:500 145:54 146:429 147:190 148:619 149:306 150:146 151:232 152:294 153:174 154:3 155:369 156:169 157:333 158:113 159:357 160:312 161:198 162:269 163:166 164:423 165:349 166:470 167:418 168:678 169:154 170:716 171:63 172:2 173:1029 174:554 175:212 176:1 177:1 178:537 180:683 181:1 182:244 183:231 184:131 186:733 187:513 188:842 189:806 190:4133 192:5771 193:4738 194:3430 195:2828 196:1205 198:3544 199:3615 200:5421 201:1582 202:8138 203:8299 204:4033 205:2326 206:2566 207:3036 208:3899 209:3478 210:2554 211:1282 212:1780 213:1706 214:678 215:66 216:4809 217:1561 218:522 219:401 220:1177 221:429 222:342 223:53 End of report From zaid at zaidali.com Fri Oct 15 14:26:13 2010 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 15 Oct 2010 12:26:13 -0700 Subject: Choice of network space when numbering interfaces with IPv6 Message-ID: SO I have been turning up v6 with multiple providers now and notice that some choose /64 for numbering interfaces but one I came across use a /126. A /126 is awfully large (for interface numbering) and I am curious if there is some rationale behind using a /126 instead of a /64. Zaid From jeroen at unfix.org Fri Oct 15 14:32:56 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Fri, 15 Oct 2010 21:32:56 +0200 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: References: Message-ID: <4CB8AC68.2070507@unfix.org> On 2010-10-15 21:26, Zaid Ali wrote: > SO I have been turning up v6 with multiple providers now and notice that > some choose /64 for numbering interfaces but one I came across use a /126. A > /126 is awfully large (for interface numbering) and I am curious if there is > some rationale behind using a /126 instead of a /64. You mean to say that a /126 is 'small' actually as it is only 2^(128-126) = 2^2 = 4 IP addresses while a /64 is...... For this discussion, please go through the archives. In short: Personal preference of operators involved. Greets, Jeroen From scott at doc.net.au Fri Oct 15 14:35:11 2010 From: scott at doc.net.au (Scott Howard) Date: Fri, 15 Oct 2010 12:35:11 -0700 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: References: Message-ID: http://www.google.com/search?q=nanog+126+64 would be a good place to start... (And I'm guessing you mean that /64 is "awfully large", not /126) Scott. On Fri, Oct 15, 2010 at 12:26 PM, Zaid Ali wrote: > SO I have been turning up v6 with multiple providers now and notice that > some choose /64 for numbering interfaces but one I came across use a /126. > A > /126 is awfully large (for interface numbering) and I am curious if there > is > some rationale behind using a /126 instead of a /64. > > Zaid > > > > From nick at foobar.org Fri Oct 15 14:37:20 2010 From: nick at foobar.org (Nick Hilliard) Date: Fri, 15 Oct 2010 20:37:20 +0100 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: References: Message-ID: <4CB8AD70.4060808@foobar.org> On 15/10/2010 20:26, Zaid Ali wrote: > SO I have been turning up v6 with multiple providers now and notice that > some choose /64 for numbering interfaces but one I came across use a /126. A > /126 is awfully large (for interface numbering) and I am curious if there is > some rationale behind using a /126 instead of a /64. There are 4 general choices of netmask for ipv6 point to point interface numbering schemes: /64: the default ipv4 subnet. many people feel that this is a waste of addressing space. others feel that there is so much ipv6 address space out there that it's simpler to keep all interfaces on /64. /112: /112 is 16-bit aligned, which means that it's easy to read because 16 bits implies that the last 4 octets are link-specific. Also, your entire PoP point-to-point addressing scheme can be held within a single /64, which means good address conservation /126: this is the same as we use in ipv4: it's less easy to read, as the link-specific digits are not octet-aligned. Your entire PoP point-to-point addressing scheme can be held within a single /64, which means good address conservation /127: this is used on POS links where there is no link-layer address resolution protocol available (like ARP/ND) and consequently you can end up with unknown traffic looping between each side if you're not careful. None of these is the right or the wrong approach, unless you're using POS/STM. Otherwise all of them have their merits and demerits. Nick From zaid at zaidali.com Fri Oct 15 15:02:22 2010 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 15 Oct 2010 13:02:22 -0700 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: Message-ID: Bahh had my head turned around and brain fried on a Friday. I was more curious about /64 vs /126 from management perspective. Thanks everyone for answering offline as well, I got my questions answered. Zaid On 10/15/10 12:26 PM, "Zaid Ali" wrote: > SO I have been turning up v6 with multiple providers now and notice that > some choose /64 for numbering interfaces but one I came across use a /126. A > /126 is awfully large (for interface numbering) and I am curious if there is > some rationale behind using a /126 instead of a /64. > > Zaid > > > From cidr-report at potaroo.net Fri Oct 15 17:00:03 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Oct 2010 22:00:03 GMT Subject: BGP Update Report Message-ID: <201010152200.o9FM03e9058756@wattle.apnic.net> BGP Update Report Interval: 07-Oct-10 -to- 14-Oct-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS7315 26671 2.8% 398.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 2 - AS9476 25085 2.6% 8361.7 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 3 - AS32528 16777 1.8% 8388.5 -- ABBOTT Abbot Labs 4 - AS8151 16633 1.8% 8.0 -- Uninet S.A. de C.V. 5 - AS5800 15094 1.6% 74.0 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS5536 14977 1.6% 220.2 -- Internet-Egypt 7 - AS33363 13794 1.4% 160.4 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 8 - AS7552 13058 1.4% 42.3 -- VIETEL-AS-AP Vietel Corporation 9 - AS3464 13011 1.4% 289.1 -- ASC-NET - Alabama Supercomputer Network 10 - AS35931 12719 1.3% 4239.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 11 - AS8452 8376 0.9% 9.4 -- TE-AS TE-AS 12 - AS6517 7978 0.8% 57.4 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 13 - AS3816 7655 0.8% 29.7 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 14 - AS14420 7590 0.8% 14.0 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 15 - AS14522 6366 0.7% 33.9 -- Satnet 16 - AS21017 6326 0.7% 632.6 -- VSI-AS VSI AS 17 - AS17819 5835 0.6% 114.4 -- ASN-EQUINIX-AP Equinix Asia Pacific 18 - AS19029 5651 0.6% 5.0 -- NEWEDGENETS - New Edge Networks 19 - AS9829 5493 0.6% 18.0 -- BSNL-NIB National Internet Backbone 20 - AS12332 5295 0.6% 86.8 -- PRIMORYE-AS Open Joint Stock Company "Far East Telecommunications Company" TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS32528 16777 1.8% 8388.5 -- ABBOTT Abbot Labs 2 - AS9476 25085 2.6% 8361.7 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 3 - AS22753 4662 0.5% 4662.0 -- REDHAT-STUTTGART REDHAT Stuttgart 4 - AS35931 12719 1.3% 4239.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS17904 866 0.1% 866.0 -- SLTASUL-LK Sri Lankan Airlines 6 - AS21017 6326 0.7% 632.6 -- VSI-AS VSI AS 7 - AS24035 593 0.1% 593.0 -- MOFA-AS-VN Ministry of Foreign Affairs of Vietnam - MOFA 8 - AS11613 539 0.1% 539.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 9 - AS43058 473 0.1% 473.0 -- SKLEPY-KOMFORT-ASN Sklepy Komfort S.A. 10 - AS27027 432 0.1% 432.0 -- ANBELL ASN-ANBELL 11 - AS9556 1645 0.2% 411.2 -- ADAM-AS-AP Adam Internet Pty Ltd 12 - AS7315 26671 2.8% 398.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 13 - AS4862 1982 0.2% 396.4 -- EQUANT-ASIA Equant AS for Asian Region covering Japan 14 - AS55311 382 0.0% 382.0 -- LIENVIETBANK-AS-VN LienViet Joint Stock Commercial Bank 15 - AS28175 2163 0.2% 360.5 -- 16 - AS18163 1420 0.1% 355.0 -- JINJU18163-AS-KR jinju national university 17 - AS11868 342 0.0% 342.0 -- CRUZAZUL-NET - La Cruz Azul de Puerto Rico, Inc. 18 - AS10445 1684 0.2% 336.8 -- HTG - Huntleigh Telcom 19 - AS16416 336 0.0% 336.0 -- MYCOMAX 20 - AS4033 333 0.0% 333.0 -- TACASN - 754th Electronic Systems Group TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.1.14.0/24 13771 1.3% AS9476 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 2 - 203.1.13.0/24 11313 1.1% AS9476 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 3 - 130.36.34.0/24 8389 0.8% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 8388 0.8% AS32528 -- ABBOTT Abbot Labs 5 - 63.211.68.0/22 8103 0.8% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 76.74.88.0/23 7381 0.7% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 7 - 129.66.128.0/17 6457 0.6% AS3464 -- ASC-NET - Alabama Supercomputer Network 8 - 129.66.0.0/17 6445 0.6% AS3464 -- ASC-NET - Alabama Supercomputer Network 9 - 72.31.122.0/24 6385 0.6% AS33363 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 10 - 72.31.98.0/24 6326 0.6% AS33363 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 11 - 201.134.18.0/24 5901 0.6% AS8151 -- Uninet S.A. de C.V. 12 - 190.65.228.0/22 5757 0.6% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 13 - 66.187.234.0/24 4662 0.5% AS22753 -- REDHAT-STUTTGART REDHAT Stuttgart 14 - 198.140.43.0/24 4606 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 15 - 95.32.192.0/18 3254 0.3% AS21017 -- VSI-AS VSI AS 16 - 95.32.128.0/18 3056 0.3% AS21017 -- VSI-AS VSI AS 17 - 206.184.16.0/24 2974 0.3% AS174 -- COGENT Cogent/PSI 18 - 202.167.253.0/24 2893 0.3% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 19 - 202.177.223.0/24 2893 0.3% AS17819 -- ASN-EQUINIX-AP Equinix Asia Pacific 20 - 202.92.235.0/24 2770 0.3% AS9498 -- BBIL-AP BHARTI Airtel Ltd. Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From cidr-report at potaroo.net Fri Oct 15 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 15 Oct 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201010152200.o9FM00cC058750@wattle.apnic.net> This report has been generated at Fri Oct 15 21:11:45 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 08-10-10 338202 209571 09-10-10 338249 209643 10-10-10 338190 209887 11-10-10 338445 210633 12-10-10 338652 210524 13-10-10 338465 209416 14-10-10 338701 209568 15-10-10 338841 210541 AS Summary 35645 Number of ASes in routing system 15190 Number of ASes announcing only one prefix 4488 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 96837888 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'). --- 15Oct10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 338934 210402 128532 37.9% All ASes AS6389 3770 283 3487 92.5% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4488 1979 2509 55.9% TWTC - tw telecom holdings, inc. AS19262 1777 279 1498 84.3% VZGNI-TRANSIT - Verizon Online LLC AS22773 1205 66 1139 94.5% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1373 283 1090 79.4% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1364 324 1040 76.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4766 1872 866 1006 53.7% KIXS-AS-KR Korea Telecom AS6478 1384 385 999 72.2% ATT-INTERNET3 - AT&T Services, Inc. AS5668 1057 94 963 91.1% AS-5668 - CenturyTel Internet Holdings, Inc. AS18566 1088 193 895 82.3% COVAD - Covad Communications Co. AS10620 1332 469 863 64.8% Telmex Colombia S.A. AS1785 1798 1015 783 43.5% AS-PAETEC-NET - PaeTec Communications, Inc. AS7545 1421 707 714 50.2% TPG-INTERNET-AP TPG Internet Pty Ltd AS7303 831 119 712 85.7% Telecom Argentina S.A. AS4808 977 318 659 67.5% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS33363 1393 737 656 47.1% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS8151 1339 692 647 48.3% Uninet S.A. de C.V. AS18101 888 249 639 72.0% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS8452 984 374 610 62.0% TE-AS TE-AS AS28573 1182 634 548 46.4% NET Servicos de Comunicao S.A. AS11492 1235 688 547 44.3% CABLEONE - CABLE ONE, INC. AS7552 642 102 540 84.1% VIETEL-AS-AP Vietel Corporation AS4780 709 184 525 74.0% SEEDNET Digital United Inc. AS17676 607 83 524 86.3% GIGAINFRA Softbank BB Corp. AS7018 1463 940 523 35.7% ATT-INTERNET4 - AT&T Services, Inc. AS24560 1020 507 513 50.3% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS9443 575 75 500 87.0% INTERNETPRIMUS-AS-AP Primus Telecommunications AS7011 1156 668 488 42.2% FRONTIER-AND-CITIZENS - Frontier Communications of America, Inc. AS22047 559 82 477 85.3% VTR BANDA ANCHA S.A. AS4804 665 212 453 68.1% MPX-AS Microplex PTY LTD Total 40154 13607 26547 66.1% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 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 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 66.245.176.0/20 AS19318 NJIIX-AS-1 - NEW JERSEY INTERNATIONAL INTERNET EXCHANGE LLC 68.234.0.0/20 AS40430 COLO4JAX-AS - colo4jax, LLC 68.234.16.0/20 AS40430 COLO4JAX-AS - colo4jax, 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. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 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. 114.142.160.0/21 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.160.0/22 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.168.0/21 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.168.0/23 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.171.0/24 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 114.142.172.0/24 AS38595 OCEAN-AS-AU Ocean Broadband - Wireless Broadband Internet provider, Perth 115.42.0.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.5.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.6.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.11.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.20.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.29.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.31.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.43.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 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 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 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 180.94.34.0/23 AS17494 BTTB-AS-AP Telecom Operator & Internet Service Provider as well 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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 X-WiN 192.131.233.0/24 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 192.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.52.33.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 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.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 203.175.98.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.99.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.103.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 203.175.107.0/24 AS45595 PKTELECOM-AS-PK Pakistan Telecom Company Limited 203.175.110.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication 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 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 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.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.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 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 216.250.116.0/24 AS36066 UNI-MARKETING-ALLIANCE - Webhost4life.com Please see http://www.cidr-report.org for the full report ------------------------------------ Copies of this report are mailed to: nanog at merit.edu eof-list at ripe.net apops at apops.net routing-wg at ripe.net afnog at afnog.org From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Oct 15 17:21:03 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 16 Oct 2010 08:51:03 +1030 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: References: Message-ID: <20101016085103.08268bbb@opy.nosense.org> Hi, On Fri, 15 Oct 2010 12:26:13 -0700 Zaid Ali wrote: > SO I have been turning up v6 with multiple providers now and notice that > some choose /64 for numbering interfaces but one I came across use a /126. A > /126 is awfully large (for interface numbering) and I am curious if there is > some rationale behind using a /126 instead of a /64. > If you're not going to follow the IPv6 Addressing Architecture, which says /64s for everything, then the prefix length decision is pretty much arbitrary - there is nothing that special about /112s, /126s, /127s or /128s (or /120s or /80s) - they all break something in the existing IPv6 RFCs so once you've passed that threshold then you're really only choosing your poison. If you're going to go down that latter path, I'd suggest reserving a /64 for each link, and then using a longer prefix length out of that /64 when you configure the addressing, to make it easier if you decided to change back to /64s at a later time. Regards, Mark. From franck at genius.com Fri Oct 15 17:38:18 2010 From: franck at genius.com (Franck Martin) Date: Sat, 16 Oct 2010 10:38:18 +1200 (FJT) Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: <20101016085103.08268bbb@opy.nosense.org> Message-ID: <22318139.8.1287182294069.JavaMail.franck@franck-martins-macbook-pro.local> but then, can't we use ip unumbered on p2p links on cisco? ----- Original Message ----- From: "Mark Smith" To: "Zaid Ali" Cc: "NANOG list" Sent: Saturday, 16 October, 2010 10:21:03 AM Subject: Re: Choice of network space when numbering interfaces with IPv6 Hi, On Fri, 15 Oct 2010 12:26:13 -0700 Zaid Ali wrote: > SO I have been turning up v6 with multiple providers now and notice that > some choose /64 for numbering interfaces but one I came across use a /126. A > /126 is awfully large (for interface numbering) and I am curious if there is > some rationale behind using a /126 instead of a /64. > If you're not going to follow the IPv6 Addressing Architecture, which says /64s for everything, then the prefix length decision is pretty much arbitrary - there is nothing that special about /112s, /126s, /127s or /128s (or /120s or /80s) - they all break something in the existing IPv6 RFCs so once you've passed that threshold then you're really only choosing your poison. If you're going to go down that latter path, I'd suggest reserving a /64 for each link, and then using a longer prefix length out of that /64 when you configure the addressing, to make it easier if you decided to change back to /64s at a later time. Regards, Mark. From oberman at es.net Fri Oct 15 18:15:14 2010 From: oberman at es.net (Kevin Oberman) Date: Fri, 15 Oct 2010 16:15:14 -0700 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: Your message of "Sat, 16 Oct 2010 08:51:03 +1030." <20101016085103.08268bbb@opy.nosense.org> Message-ID: <20101015231514.AE8D61CC3E@ptavv.es.net> > Date: Sat, 16 Oct 2010 08:51:03 +1030 > From: Mark Smith > > Hi, > > On Fri, 15 Oct 2010 12:26:13 -0700 > Zaid Ali wrote: > > > SO I have been turning up v6 with multiple providers now and notice that > > some choose /64 for numbering interfaces but one I came across use a /126. A > > /126 is awfully large (for interface numbering) and I am curious if there is > > some rationale behind using a /126 instead of a /64. > > > > If you're not going to follow the IPv6 Addressing Architecture, which > says /64s for everything, then the prefix length decision is > pretty much arbitrary - there is nothing that special > about /112s, /126s, /127s or /128s (or /120s or /80s) - they all break > something in the existing IPv6 RFCs so once you've passed that threshold > then you're really only choosing your poison. If you're going to go > down that latter path, I'd suggest reserving a /64 for each link, and > then using a longer prefix length out of that /64 when you configure > the addressing, to make it easier if you decided to change back to /64s > at a later time. If you listen to the NANOG "debate" on IPv6 on P2P links, you will discover that the participants (Igor of Yahoo and Rob Seastrom of Affilias) agreed that the proper way to do this was to allocate a /64 for the link but to configure it as a /127. This was to avoid ping-pong DOS attacks. I believe that the session has already been cited, but see Igor's presentation at: http://nanog.org/meetings/nanog48/presentations/Tuesday/Gashinsky_LinkNumb_N48.pdf -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From david.hooton at platformnetworks.net Fri Oct 15 21:41:52 2010 From: david.hooton at platformnetworks.net (David Hooton) Date: Sat, 16 Oct 2010 13:41:52 +1100 Subject: Media Sentry Contact Message-ID: <55058BF2-5263-4E84-9FCD-7A4F0A9BC848@platformnetworks.net> Does anyone have a working and responsive contact for the Media Sentry team that send copyright notices? I've been trying to contact them for about 6 months regarding an operational issue using all the contact information in their emails, but they clearly don't want any assistance because they have never responded to my emails. Kind Regards, David Hooton Managing Director Platform Networks www.platformnetworks.net From rjoffe at centergate.com Fri Oct 15 21:51:34 2010 From: rjoffe at centergate.com (Rodney Joffe) Date: Fri, 15 Oct 2010 19:51:34 -0700 Subject: 12 years ago today... Message-ID: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> On October 16th, we lost a real friend and hero. Sigh.... http://www.apps.ietf.org/rfc/rfc2468.html From jmamodio at gmail.com Fri Oct 15 22:38:17 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 15 Oct 2010 22:38:17 -0500 Subject: 12 years ago today... In-Reply-To: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> Message-ID: On Fri, Oct 15, 2010 at 9:51 PM, Rodney Joffe wrote: > On October 16th, we lost a real friend and hero. Sigh.... > > http://www.apps.ietf.org/rfc/rfc2468.html Amen. Long Live Jon Postel !! From zaid at zaidali.com Sat Oct 16 00:44:06 2010 From: zaid at zaidali.com (Zaid Ali) Date: Fri, 15 Oct 2010 22:44:06 -0700 Subject: 12 years ago today... In-Reply-To: Message-ID: On 10/15/10 8:38 PM, "Jorge Amodio" wrote: > On Fri, Oct 15, 2010 at 9:51 PM, Rodney Joffe wrote: >> On October 16th, we lost a real friend and hero. Sigh.... >> >> http://www.apps.ietf.org/rfc/rfc2468.html > > Amen. Long Live Jon Postel !! > And you can sometimes hear his comments http://www.facebook.com/jon.postel :) From trelane at trelane.net Sat Oct 16 01:00:45 2010 From: trelane at trelane.net (Andrew Kirch) Date: Sat, 16 Oct 2010 02:00:45 -0400 Subject: apologies for a recent reply Message-ID: <4CB93F8D.1040107@trelane.net> Apparently I have replied to someone who has been banned from NANOG unknowingly. My humble apologies to all, this person has been killfiled. Andrew From sterbeats at gmail.com Sat Oct 16 03:43:35 2010 From: sterbeats at gmail.com (Ali S) Date: Sat, 16 Oct 2010 01:43:35 -0700 Subject: 12 years ago today... In-Reply-To: References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> Message-ID: <3998D283-D969-4176-985F-869D09F04D57@gmail.com> He should have been better known for his work. The intertubes will miss you Sent via mobile. On Oct 15, 2010, at 8:38 PM, Jorge Amodio wrote: > On Fri, Oct 15, 2010 at 9:51 PM, Rodney Joffe wrote: >> On October 16th, we lost a real friend and hero. Sigh.... >> >> http://www.apps.ietf.org/rfc/rfc2468.html > > Amen. Long Live Jon Postel !! > From wbailey at gci.com Sat Oct 16 04:02:35 2010 From: wbailey at gci.com (Warren Bailey) Date: Sat, 16 Oct 2010 01:02:35 -0800 Subject: 12 years ago today... In-Reply-To: <3998D283-D969-4176-985F-869D09F04D57@gmail.com> References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> <3998D283-D969-4176-985F-869D09F04D57@gmail.com> Message-ID: I bet it was terribly hard for Vint to write that. Was really nice to read though, and to know that he had a good enough friend to express his deep sorrow so publicly. While we are on the subject of "the godfathers of the Internet", when is a documentary coming out that tells the story? There was a really long documentary done on the BBS, surely someone (myself included) would find it interesting. //warren Sent from a mobile phone with a small keyboard, please excuse my mistakes. On Oct 16, 2010, at 12:45 AM, "Ali S" wrote: > He should have been better known for his work. The intertubes will miss you > > Sent via mobile. > > On Oct 15, 2010, at 8:38 PM, Jorge Amodio wrote: > >> On Fri, Oct 15, 2010 at 9:51 PM, Rodney Joffe wrote: >>> On October 16th, we lost a real friend and hero. Sigh.... >>> >>> http://www.apps.ietf.org/rfc/rfc2468.html >> >> Amen. Long Live Jon Postel !! >> > From wbailey at gci.com Sat Oct 16 04:17:26 2010 From: wbailey at gci.com (Warren Bailey) Date: Sat, 16 Oct 2010 01:17:26 -0800 Subject: Internet in DPRK / North Korea In-Reply-To: References: <20101010235742.52964.qmail@joyce.lan> <8A4C3C49-8821-4E8C-A72F-739ED2E6A7F4@americafree.tv> Message-ID: <3BC00E74-88C5-435D-9B51-63A8B233B627@gci.com> All of the DPRK elite use satellite connections which terminate in Iran. Wonder if they'll be pissed off when their search for "imperialist America" is blocked and they can't seem to figure out tor? Sent from a mobile phone with a small keyboard, please excuse my mistakes. On Oct 10, 2010, at 8:01 PM, "Jeffrey Lyon" wrote: > I love the hard hitting, unbiased reports. > > Jeff > > On Mon, Oct 11, 2010 at 5:31 AM, Christopher Morrow > wrote: >> On Sun, Oct 10, 2010 at 8:57 PM, jim deleskie wrote: >>> and his 3g's and his wifi's? :) >> >> that's just crazy talk. >> >>> On Sun, Oct 10, 2010 at 9:56 PM, Christopher Morrow >>> wrote: >>>> >>>> On Sun, Oct 10, 2010 at 8:38 PM, John R. Levine wrote: >>>>> 175.45.179.68/ >>>> >>>> >>>> once senses that the potential successor wants his twitters and >>>> facebooks... >>>> >>> >>> >> >> > > > > -- > 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 ken.gilmour at gmail.com Sat Oct 16 05:03:20 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sat, 16 Oct 2010 12:03:20 +0200 Subject: Enterprise DNS providers Message-ID: Hello any weekend workers :) We are looking at urgently deploying an outsourced DNS provider for a critical domain which is currently unavailable but are having some difficulty. I've tried contacting UltraDNS who only allow customers from US / Canada to sign up (we are in Malta) and their Sales dept are closed, and Easy DNS who don't have .com.mt as an option in the dropdown for transferring domain names (and also support is closed). Black Lotus looks like the next best contender, has anyone had experience with these or any other recommendations for how we can transfer a .com.mt to a reliable hosting provider during the weekend? Thanks! Ken From ken.gilmour at gmail.com Sat Oct 16 06:21:53 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Sat, 16 Oct 2010 13:21:53 +0200 Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: Thanks everyone for the fast and offline responses! Black Lotus contacted me directly (almost instantly) and helped me set up an account straight away so I will give them a try. On 16 October 2010 12:03, Ken Gilmour wrote: > Hello any weekend workers :) > > We are looking at urgently deploying an outsourced DNS provider for a > critical domain which is currently unavailable but are having some > difficulty. I've tried contacting UltraDNS who only allow customers from US > / Canada to sign up (we are in Malta) and their Sales dept are closed, and > Easy DNS who don't have .com.mt as an option in the dropdown for > transferring domain names (and also support is closed). > > Black Lotus looks like the next best contender, has anyone had experience > with these or any other recommendations for how we can transfer a .com.mtto a reliable hosting provider during the weekend? > > Thanks! > > Ken > From randy at psg.com Sat Oct 16 06:31:22 2010 From: randy at psg.com (Randy Bush) Date: Sat, 16 Oct 2010 12:31:22 +0100 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: References: Message-ID: http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt From randy at psg.com Sat Oct 16 07:10:15 2010 From: randy at psg.com (Randy Bush) Date: Sat, 16 Oct 2010 13:10:15 +0100 Subject: isoc moves to hollywood Message-ID: isoc has made some movies trying to explain to normal humans what the fate of internet access might become. http://www.isoc.org/tools/blogs/scenarios/ imiho, message quality varies. but in general i like what they are trying to do. randy From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Oct 16 09:10:41 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 17 Oct 2010 00:40:41 +1030 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: References: Message-ID: <20101017004041.7f19f304@opy.nosense.org> On Sat, 16 Oct 2010 12:31:22 +0100 Randy Bush wrote: > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt > Drafts are drafts, and nothing more, aren't they? From dhc2 at dcrocker.net Sat Oct 16 10:33:14 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Sat, 16 Oct 2010 11:33:14 -0400 Subject: 12 years ago today... In-Reply-To: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> Message-ID: <4CB9C5BA.40300@dcrocker.net> On 10/15/2010 10:51 PM, Rodney Joffe wrote: > On October 16th, we lost a real friend and hero. Sigh.... > http://www.apps.ietf.org/rfc/rfc2468.html Quite a few of us felt compelled to remark on his life and effect on us. They've been nicely collected at postel.org: Speak softly and carry a big registry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From brandon.kim at brandontek.com Sat Oct 16 10:36:13 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sat, 16 Oct 2010 11:36:13 -0400 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <20101017004041.7f19f304@opy.nosense.org> References: , , <20101017004041.7f19f304@opy.nosense.org> Message-ID: Since we are on the topic of IPv6. I'd like to know if anyone has books/articles they recommend on fully understanding IPv6 adoption in the work place. I will need to contact ARIN shortly to request a v6 block. I'm assuming I would be asking for a /64 being an ISP. But I'd like to read up as much as possible before requesting the block.... I think our approach will be to use dual-stack on the routers and let the clients themselves handle how they want to use IPv6... Ultimately, it is up to them, their network, and their applications on how to use v6... Thanks guys! From gordslater at ieee.org Sat Oct 16 10:39:18 2010 From: gordslater at ieee.org (gordon b slater) Date: Sat, 16 Oct 2010 16:39:18 +0100 Subject: 12 years ago today... In-Reply-To: <3998D283-D969-4176-985F-869D09F04D57@gmail.com> References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> <3998D283-D969-4176-985F-869D09F04D57@gmail.com> Message-ID: <1287243558.23425.159.camel@ub-g-d2> On Sat, 2010-10-16 at 01:43 -0700, Ali S wrote: > He should have been better known for his work. The intertubes will miss you One day I hope he'll be featured in school history lessons. An amazing legacy - something approaching 1/3rd of the planet's population uses it every time they use the 'nets. Gord -- History repeating itself? tcpdump the STP to figure out why. From owen at delong.com Sat Oct 16 10:49:22 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 16 Oct 2010 08:49:22 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: , , <20101017004041.7f19f304@opy.nosense.org> Message-ID: <1C62FCE8-F152-428E-A52D-43EACBA5F08E@delong.com> On Oct 16, 2010, at 8:36 AM, Brandon Kim wrote: > > Since we are on the topic of IPv6. I'd like to know if anyone has books/articles they recommend on fully > understanding IPv6 adoption in the work place. I will need to contact ARIN shortly to request a v6 block. > > I'm assuming I would be asking for a /64 being an ISP. But I'd like to read up as much as possible before > requesting the block.... > No, as an ISP, you should get at least a /32. A /64 is a single subnet in IPv6. > I think our approach will be to use dual-stack on the routers and let the clients themselves handle how they want to use IPv6... > Seems reasonable. FWIW, you should plan for assigning clients a /48 per end-site. > Ultimately, it is up to them, their network, and their applications on how to use v6... > Yep. Owen From joelja at bogus.com Sat Oct 16 10:56:00 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sat, 16 Oct 2010 08:56:00 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: , , <20101017004041.7f19f304@opy.nosense.org> Message-ID: <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com> Joel's widget number 2 On Oct 16, 2010, at 8:36, Brandon Kim wrote: > > Since we are on the topic of IPv6. I'd like to know if anyone has books/articles they recommend on fully > understanding IPv6 adoption in the work place. I will need to contact ARIN shortly to request a v6 block. > > I'm assuming I would be asking for a /64 being an ISP. But I'd like to read up as much as possible before > requesting the block.... An ISP requesting an assignment would typically request a /32 For policy, I'd read the ARIN nrpm's section on v6 assignment. https://www.arin.net/policy/nrpm.html#six I'd also get a book, for background, something like: http://www.amazon.com/Running-IPv6-Iljitsch-van-Beijnum/dp/1590595270/ref=sr_1_3?ie=UTF8&qid=1287244118&sr=8-3#reader_1590595270 Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. > I think our approach will be to use dual-stack on the routers and let the clients themselves handle how they want to use IPv6... > > Ultimately, it is up to them, their network, and their applications on how to use v6... > > Thanks guys! > > From rjoffe at centergate.com Sat Oct 16 11:09:29 2010 From: rjoffe at centergate.com (Rodney Joffe) Date: Sat, 16 Oct 2010 09:09:29 -0700 Subject: 12 years ago today... In-Reply-To: References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> <3998D283-D969-4176-985F-869D09F04D57@gmail.com> Message-ID: <4986CDF9-B97D-45F5-BB90-EF679EF72076@centergate.com> I'm not sure about a documentary, but a group of us are working on identifying all the different independent archives that have records from "the early years" with the idea of creating a Smithsonian/national archive collection at some point. We'll probably issue an rfc early next year. On Oct 16, 2010, at 2:02 AM, Warren Bailey wrote: > I bet it was terribly hard for Vint to write that. Was really nice to read though, and to know that he had a good enough friend to express his deep sorrow so publicly. > > While we are on the subject of "the godfathers of the Internet", when is a documentary coming out that tells the story? There was a really long documentary done on the BBS, surely someone (myself included) would find it interesting. > > //warren > > Sent from a mobile phone with a small keyboard, please excuse my mistakes. > > On Oct 16, 2010, at 12:45 AM, "Ali S" wrote: > >> He should have been better known for his work. The intertubes will miss you >> >> Sent via mobile. >> >> On Oct 15, 2010, at 8:38 PM, Jorge Amodio wrote: >> >>> On Fri, Oct 15, 2010 at 9:51 PM, Rodney Joffe wrote: >>>> On October 16th, we lost a real friend and hero. Sigh.... >>>> >>>> http://www.apps.ietf.org/rfc/rfc2468.html >>> >>> Amen. Long Live Jon Postel !! >>> >> > > From rdobbins at arbor.net Sat Oct 16 11:09:43 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Sat, 16 Oct 2010 16:09:43 +0000 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com> References: , , <20101017004041.7f19f304@opy.nosense.org> <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com> Message-ID: On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: > Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From brandon.kim at brandontek.com Sat Oct 16 15:58:57 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sat, 16 Oct 2010 16:58:57 -0400 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: ,,, <20101017004041.7f19f304@opy.nosense.org>, , <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com>, Message-ID: Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction.... Thanks again especially on a Saturday weekend! > From: rdobbins at arbor.net > To: nanog at nanog.org > Date: Sat, 16 Oct 2010 16:09:43 +0000 > Subject: Re: Definitive Guide to IPv6 adoption > > > On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: > > > Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. > > > Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): > > > > > > ----------------------------------------------------------------------- > Roland Dobbins // > > Sell your computer and buy a guitar. > > > > > From ryan.finnesey at HarrierInvestments.com Sat Oct 16 17:05:00 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Sat, 16 Oct 2010 15:05:00 -0700 Subject: T-Mobile USA - Peering Policy In-Reply-To: References: <6EFFEFBAC68377459A2E972105C759EC0300A923@EXVBE005-2.exch005intermedia.net> Message-ID: <6EFFEFBAC68377459A2E972105C759EC0300ABDD@EXVBE005-2.exch005intermedia.net> I wanted to thank everyone for their helpful on-list and off-list reply's. Cheers Ryan -----Original Message----- From: Cameron Byrne [mailto:cb.list6 at gmail.com] Sent: Wednesday, October 13, 2010 9:44 AM To: Ryan Finnesey Cc: nanog at nanog.org Subject: Re: T-Mobile USA - Peering Policy On Tue, Oct 12, 2010 at 9:28 PM, Ryan Finnesey wrote: > Can someone on the list from T-Mobile USA please contact me. ?I have > tried sending a message to admin at tmodns.net but the message bounces > back and the mailbox for arintechcontact at t-mobile.com is full. ? I am > trying to find out information regarding there peering policy. > You can contact me off-list for T-Mobile USA questions. Cameron From oberman at es.net Sat Oct 16 17:26:54 2010 From: oberman at es.net (Kevin Oberman) Date: Sat, 16 Oct 2010 15:26:54 -0700 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: Your message of "Sun, 17 Oct 2010 00:40:41 +1030." <20101017004041.7f19f304@opy.nosense.org> Message-ID: <20101016222654.728261CC3E@ptavv.es.net> > Date: Sun, 17 Oct 2010 00:40:41 +1030 > From: Mark Smith > > On Sat, 16 Oct 2010 12:31:22 +0100 > Randy Bush wrote: > > > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt > > > > Drafts are drafts, and nothing more, aren't they? Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a handful have ever been designated as "Standards". I hope this becomes one of those in the hope it will be taken seriously. (It already is by anyone with a large network running IPv6.) The point is to READ the draft arguments and see why /127s are the right way to address P2P circuits. Also, you might note the contributors to the draft. They are people well know on this list who have real, honest to goodness operational experience in running networks and really understand that a /64 on a P2P connection is a serious security problem. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From bogstad at pobox.com Sat Oct 16 18:52:31 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Sat, 16 Oct 2010 19:52:31 -0400 Subject: Choice of network space when numbering interfaces with IPv6 (IPv6 STANDARDS) Message-ID: On Sat, Oct 16, 2010 at 6:26 PM, Kevin Oberman wrote: >> Date: Sun, 17 Oct 2010 00:40:41 +1030 >> From: Mark Smith >> >> On Sat, 16 Oct 2010 12:31:22 +0100 >> Randy Bush wrote: >> >> > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt >> > >> >> Drafts are drafts, and nothing more, aren't they? > > Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a > handful have ever been designated as "Standards". I hope this becomes > one of those in the hope it will be taken seriously. (It already is by > anyone with a large network running IPv6.) And none of the listed IETF "full standards" are IPv6 related. That seems a little bit odd to me given that everyone is supposed to have implemented them by now. Bill Bogstad From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Oct 16 18:54:41 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 17 Oct 2010 10:24:41 +1030 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: <20101016222654.728261CC3E@ptavv.es.net> References: <20101017004041.7f19f304@opy.nosense.org> <20101016222654.728261CC3E@ptavv.es.net> Message-ID: <20101017102441.79fb4caf@opy.nosense.org> On Sat, 16 Oct 2010 15:26:54 -0700 "Kevin Oberman" wrote: > > Date: Sun, 17 Oct 2010 00:40:41 +1030 > > From: Mark Smith > > > > On Sat, 16 Oct 2010 12:31:22 +0100 > > Randy Bush wrote: > > > > > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt > > > > > > > Drafts are drafts, and nothing more, aren't they? > > Drafts are drafts. Even most RFCs are RFCs and nothing more. No, drafts are documents that can be submitted by anybody, and can say anything, where as RFCs have been through an IETF evaluation process. > Only a > handful have ever been designated as "Standards". I hope this becomes > one of those in the hope it will be taken seriously. (It already is by > anyone with a large network running IPv6.) > > The point is to READ the draft arguments and see why /127s are the right > way to address P2P circuits. I suggest you search the v6ops mailing list, as I've read it multiple times, including all revisions, and have pointed out multiple issues with it. > Also, you might note the contributors to the > draft. They are people well know on this list who have real, honest to > goodness operational experience in running networks and really understand > that a /64 on a P2P connection is a serious security problem. As do I. You can see my analysis of the issue, and how I think it should be fixed properly, not mitigated for one type of link at the following URLs. http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00543.html http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Oct 16 18:57:11 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 17 Oct 2010 10:27:11 +1030 Subject: Choice of network space when numbering interfaces with IPv6 (IPv6 STANDARDS) In-Reply-To: References: Message-ID: <20101017102711.49381f5e@opy.nosense.org> On Sat, 16 Oct 2010 19:52:31 -0400 Bill Bogstad wrote: > On Sat, Oct 16, 2010 at 6:26 PM, Kevin Oberman wrote: > >> Date: Sun, 17 Oct 2010 00:40:41 +1030 > >> From: Mark Smith > >> > >> On Sat, 16 Oct 2010 12:31:22 +0100 > >> Randy Bush wrote: > >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt > >> > > >> > >> Drafts are drafts, and nothing more, aren't they? > > > > Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a > > handful have ever been designated as "Standards". I hope this becomes > > one of those in the hope it will be taken seriously. (It already is by > > anyone with a large network running IPv6.) > > And none of the listed IETF "full standards" are IPv6 related. That > seems a little bit odd to me given that everyone is supposed to have > implemented them by now. > The IETF standards process is different to other standards organisations - publication of an RFC doesn't make it a standard. It is much more pragmatic, as operational history is also used as an input into the decision. > Bill Bogstad From franck at genius.com Sat Oct 16 19:22:38 2010 From: franck at genius.com (Franck Martin) Date: Sun, 17 Oct 2010 12:22:38 +1200 (FJT) Subject: Definitive Guide to IPv6 adoption In-Reply-To: Message-ID: <28523038.168.1287274957037.JavaMail.franck@franck-martins-macbook-pro.local> You give a /64 to the end users (home/soho), and /48 to multi homed organization (or bigger orgs that use more than one network internally) and get a /32 if you are an ISP. See also the discussion about what to use in p2p links. ----- Original Message ----- From: "Brandon Kim" To: nanog at nanog.org Sent: Sunday, 17 October, 2010 8:58:57 AM Subject: RE: Definitive Guide to IPv6 adoption Thanks everyone who responded. This list is such a valuable wealth of information. Apparently I was wrong about the /64 as that should be /32 so thanks for that correction.... Thanks again especially on a Saturday weekend! > From: rdobbins at arbor.net > To: nanog at nanog.org > Date: Sat, 16 Oct 2010 16:09:43 +0000 > Subject: Re: Definitive Guide to IPv6 adoption > > > On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: > > > Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. > > > Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): > > > > > > ----------------------------------------------------------------------- > Roland Dobbins // > > Sell your computer and buy a guitar. > > > > > From bogstad at pobox.com Sat Oct 16 19:26:28 2010 From: bogstad at pobox.com (Bill Bogstad) Date: Sat, 16 Oct 2010 20:26:28 -0400 Subject: Choice of network space when numbering interfaces with IPv6 (IPv6 STANDARDS) In-Reply-To: <20101017102711.49381f5e@opy.nosense.org> References: <20101017102711.49381f5e@opy.nosense.org> Message-ID: On Sat, Oct 16, 2010 at 7:57 PM, Mark Smith wrote: > On Sat, 16 Oct 2010 19:52:31 -0400 > Bill Bogstad wrote: > >> On Sat, Oct 16, 2010 at 6:26 PM, Kevin Oberman wrote: >> >> Date: Sun, 17 Oct 2010 00:40:41 +1030 >> >> From: Mark Smith >> >> >> >> On Sat, 16 Oct 2010 12:31:22 +0100 >> >> Randy Bush wrote: >> >> >> >> > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt >> >> > >> >> >> >> Drafts are drafts, and nothing more, aren't they? >> > >> > Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a >> > handful have ever been designated as "Standards". I hope this becomes >> > one of those in the hope it will be taken seriously. (It already is by >> > anyone with a large network running IPv6.) >> >> And none of the listed IETF "full standards" are IPv6 related. ?That >> seems a little bit odd to me given that everyone is supposed to have >> implemented them by now. >> > > The IETF standards process is different to other standards > organisations - publication of an RFC doesn't make it a standard. It is > much more pragmatic, as operational history is also used as an input > into the decision. I read my first RFC sometime in 1984. I still find it odd that after something like a decade of development/operational history NONE of the IPv6 related RFCs have made it all the way to full standard status. This might be a minor point but I think that not making at least some of the base IPv6 RFCs full standards probably slowed down deployment. OTOH, now that people are convinced that they won't be able to get more IPv4 addresses in the near future; a possible perception that IPv6 was "experimental" may no longer matter... Bill Bogstad From randy at psg.com Sat Oct 16 19:56:28 2010 From: randy at psg.com (Randy Bush) Date: Sun, 17 Oct 2010 01:56:28 +0100 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: <20101016222654.728261CC3E@ptavv.es.net> References: <20101017004041.7f19f304@opy.nosense.org> <20101016222654.728261CC3E@ptavv.es.net> Message-ID: >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt >> Drafts are drafts, and nothing more, aren't they? must be some blowhard i have plonked > Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a > handful have ever been designated as "Standards". I hope this becomes > one of those in the hope it will be taken seriously. (It already is by > anyone with a large network running IPv6.) juniper and cisco implement today randy From oberman at es.net Sat Oct 16 21:55:19 2010 From: oberman at es.net (Kevin Oberman) Date: Sat, 16 Oct 2010 19:55:19 -0700 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: Your message of "Sun, 17 Oct 2010 01:56:28 BST." Message-ID: <20101017025519.EB7C91CC3E@ptavv.es.net> > Date: Sun, 17 Oct 2010 01:56:28 +0100 > From: Randy Bush > > >>> http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt > >> Drafts are drafts, and nothing more, aren't they? > > must be some blowhard i have plonked > > > Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a > > handful have ever been designated as "Standards". I hope this becomes > > one of those in the hope it will be taken seriously. (It already is by > > anyone with a large network running IPv6.) > > juniper and cisco implement today Unfortunately, a couple of other router vendors whose top of the line units I have tested recently did not. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From oberman at es.net Sat Oct 16 22:13:22 2010 From: oberman at es.net (Kevin Oberman) Date: Sat, 16 Oct 2010 20:13:22 -0700 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: Your message of "Sun, 17 Oct 2010 10:24:41 +1030." <20101017102441.79fb4caf@opy.nosense.org> Message-ID: <20101017031322.664961CC3E@ptavv.es.net> > Date: Sun, 17 Oct 2010 10:24:41 +1030 > From: Mark Smith > > On Sat, 16 Oct 2010 15:26:54 -0700 > "Kevin Oberman" wrote: > > > > Date: Sun, 17 Oct 2010 00:40:41 +1030 > > > From: Mark Smith > > > > > > On Sat, 16 Oct 2010 12:31:22 +0100 > > > Randy Bush wrote: > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt > > > > > > > > > > Drafts are drafts, and nothing more, aren't they? > > > > Drafts are drafts. Even most RFCs are RFCs and nothing more. > > No, drafts are documents that can be submitted by anybody, and can say > anything, where as RFCs have been through an IETF evaluation process. > > > Only a > > handful have ever been designated as "Standards". I hope this becomes > > one of those in the hope it will be taken seriously. (It already is by > > anyone with a large network running IPv6.) > > > > The point is to READ the draft arguments and see why /127s are the right > > way to address P2P circuits. > > I suggest you search the v6ops mailing list, as I've read it multiple > times, including all revisions, and have pointed out multiple issues > with it. > > > Also, you might note the contributors to the > > draft. They are people well know on this list who have real, honest to > > goodness operational experience in running networks and really understand > > that a /64 on a P2P connection is a serious security problem. > > As do I. You can see my analysis of the issue, and how I think it > should be fixed properly, not mitigated for one type of link at the > following URLs. > > http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00543.html > > > http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html I don't entirely agree with your arguments, but the approach looks, at first glance, to be quite interesting and could quite possibly fix the problem. I'll need to digest it a bit better. Have you or someone else authored a draft on this proposal? In the meantime, I still support /127s for P2P links. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Oct 16 23:06:01 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 17 Oct 2010 14:36:01 +1030 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: <20101017031322.664961CC3E@ptavv.es.net> References: <20101017102441.79fb4caf@opy.nosense.org> <20101017031322.664961CC3E@ptavv.es.net> Message-ID: <20101017143601.39d470c0@opy.nosense.org> Hi Kevin, On Sat, 16 Oct 2010 20:13:22 -0700 "Kevin Oberman" wrote: > > Date: Sun, 17 Oct 2010 10:24:41 +1030 > > From: Mark Smith > > > > On Sat, 16 Oct 2010 15:26:54 -0700 > > "Kevin Oberman" wrote: > > > > > > Date: Sun, 17 Oct 2010 00:40:41 +1030 > > > > From: Mark Smith > > > > > > > > On Sat, 16 Oct 2010 12:31:22 +0100 > > > > Randy Bush wrote: > > > > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt > > > > > > > > > > > > > Drafts are drafts, and nothing more, aren't they? > > > > > > Drafts are drafts. Even most RFCs are RFCs and nothing more. > > > > No, drafts are documents that can be submitted by anybody, and can say > > anything, where as RFCs have been through an IETF evaluation process. > > > > > Only a > > > handful have ever been designated as "Standards". I hope this becomes > > > one of those in the hope it will be taken seriously. (It already is by > > > anyone with a large network running IPv6.) > > > > > > The point is to READ the draft arguments and see why /127s are the right > > > way to address P2P circuits. > > > > I suggest you search the v6ops mailing list, as I've read it multiple > > times, including all revisions, and have pointed out multiple issues > > with it. > > > > > Also, you might note the contributors to the > > > draft. They are people well know on this list who have real, honest to > > > goodness operational experience in running networks and really understand > > > that a /64 on a P2P connection is a serious security problem. > > > > As do I. You can see my analysis of the issue, and how I think it > > should be fixed properly, not mitigated for one type of link at the > > following URLs. > > > > http://www.ops.ietf.org/lists/v6ops/v6ops.2010/msg00543.html > > > > > > http://www.ietf.org/mail-archive/web/ipv6/current/msg12400.html > > I don't entirely agree with your arguments, but the approach looks, at > first glance, to be quite interesting and could quite possibly fix the > problem. I'll need to digest it a bit better. > > Have you or someone else authored a draft on this proposal? I've started writing one on the nonce solution, as it can be made to interoperate with existing deployed ND NS/NA mechanisms. Regards, Mark. > In the > meantime, I still support /127s for P2P links. > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From daydomes at gmail.com Sat Oct 16 23:46:52 2010 From: daydomes at gmail.com (Day Domes) Date: Sun, 17 Oct 2010 00:46:52 -0400 Subject: network name 101100010100110.net Message-ID: I have been tasked with coming up with a new name for are transit data network.? I am thinking of using 101100010100110.net does anyone see any issues with this? From joe at nethead.com Sat Oct 16 23:59:41 2010 From: joe at nethead.com (Joe Hamelin) Date: Sat, 16 Oct 2010 21:59:41 -0700 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: On Saturday night, Day Domes postulated: > I am thinking of using 101100010100110.net does anyone see > any issues with this? It's truly unsigned? (15 bit) -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From daydomes at gmail.com Sun Oct 17 00:02:30 2010 From: daydomes at gmail.com (Day Domes) Date: Sun, 17 Oct 2010 01:02:30 -0400 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: On Sun, Oct 17, 2010 at 12:59 AM, Joe Hamelin wrote: > On Saturday night, Day Domes postulated: >> I am thinking of using 101100010100110.net does anyone see >> any issues with this? > > > It's truly unsigned? > (15 bit) > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > unsigned? From joe at nethead.com Sun Oct 17 00:04:26 2010 From: joe at nethead.com (Joe Hamelin) Date: Sat, 16 Oct 2010 22:04:26 -0700 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: 16 bit integers. Ok, a lame joke. 22694.NET and 58A6.NET are available. What are you trying to name? -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Sat, Oct 16, 2010 at 10:02 PM, Day Domes wrote: > On Sun, Oct 17, 2010 at 12:59 AM, Joe Hamelin wrote: >> On Saturday night, Day Domes postulated: >>> I am thinking of using 101100010100110.net does anyone see >>> any issues with this? >> >> >> It's truly unsigned? >> (15 bit) >> >> -- >> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >> > > unsigned? > From daydomes at gmail.com Sun Oct 17 00:24:25 2010 From: daydomes at gmail.com (Day Domes) Date: Sun, 17 Oct 2010 01:24:25 -0400 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: On Sun, Oct 17, 2010 at 1:03 AM, Joe Hamelin wrote: > 16 bit integers. ?Ok, a lame joke. > > 22694.NET and 58A6.NET are available. ?What are you trying to name? > > > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > > On Sat, Oct 16, 2010 at 10:01 PM, Day Domes wrote: >> unsigned? >> >> On Sun, Oct 17, 2010 at 12:59 AM, Joe Hamelin wrote: >>> On Saturday night, Day Domes postulated: >>>> I am thinking of using 101100010100110.net does anyone see >>>> any issues with this? >>> >>> >>> It's truly unsigned? >>> (15 bit) >>> >>> -- >>> Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 >>> >> > A new network that we are going to use to connect all are global data centers and also use to peer with other networks to push data to the Internet From pelle at hemmop.com Sun Oct 17 01:07:41 2010 From: pelle at hemmop.com (Per Carlson) Date: Sun, 17 Oct 2010 08:07:41 +0200 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: Technically, no. But you probably fancy annoying people. I wouldn't imaging anyone typing that right on the first attempt. On 17 Oct 2010 06:47, "Day Domes" wrote: > I have been tasked with coming up with a new name for are transit data > network. I am thinking of using 101100010100110.net does anyone see > any issues with this? > From mpalmer at hezmatt.org Sun Oct 17 01:25:34 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sun, 17 Oct 2010 17:25:34 +1100 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: <20101017062534.GQ11984@hezmatt.org> On Sun, Oct 17, 2010 at 08:07:41AM +0200, Per Carlson wrote: > On 17 Oct 2010 06:47, "Day Domes" wrote: > > I have been tasked with coming up with a new name for are transit data > > network. I am thinking of using 101100010100110.net does anyone see > > any issues with this? > > Technically, no. > > But you probably fancy annoying people. I wouldn't imaging anyone typing > that right on the first attempt. And imagine answering the phones... - Matt From joe at nethead.com Sun Oct 17 01:35:41 2010 From: joe at nethead.com (Joe Hamelin) Date: Sat, 16 Oct 2010 23:35:41 -0700 Subject: network name 101100010100110.net In-Reply-To: <20101017062534.GQ11984@hezmatt.org> References: <20101017062534.GQ11984@hezmatt.org> Message-ID: Matthew said: And imagine answering the phones... Bender's Big Score. Is this for Jewish Hospital (AS 22694)? And many years ago I had jh.org, but domains were $70 back then and my wife thought I had too many... -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From owen at delong.com Sun Oct 17 09:56:40 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Oct 2010 07:56:40 -0700 Subject: Choice of network space when numbering interfaces with IPv6 (IPv6 STANDARDS) In-Reply-To: References: Message-ID: <6B84A01C-953D-4F2C-B015-57602E1C33B7@delong.com> On Oct 16, 2010, at 4:52 PM, Bill Bogstad wrote: > On Sat, Oct 16, 2010 at 6:26 PM, Kevin Oberman wrote: >>> Date: Sun, 17 Oct 2010 00:40:41 +1030 >>> From: Mark Smith >>> >>> On Sat, 16 Oct 2010 12:31:22 +0100 >>> Randy Bush wrote: >>> >>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt >>>> >>> >>> Drafts are drafts, and nothing more, aren't they? >> >> Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a >> handful have ever been designated as "Standards". I hope this becomes >> one of those in the hope it will be taken seriously. (It already is by >> anyone with a large network running IPv6.) > > And none of the listed IETF "full standards" are IPv6 related. That > seems a little bit odd to me given that everyone is supposed to have > implemented them by now. > > Bill Bogstad IPv4 was much further along in deployment than IPv6 is now when the first IPv4 STDs were published as STDs. Usually RFCs bake for quite a while in the real world before becoming STDs. Owen From owen at delong.com Sun Oct 17 09:58:52 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 17 Oct 2010 07:58:52 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <28523038.168.1287274957037.JavaMail.franck@franck-martins-macbook-pro.local> References: <28523038.168.1287274957037.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <3DA24C84-432A-445D-A366-F7BAE263407F@delong.com> On Oct 16, 2010, at 5:22 PM, Franck Martin wrote: > You give a /64 to the end users (home/soho), and /48 to multi homed organization (or bigger orgs that use more than one network internally) and get a /32 if you are an ISP. > Please DON'T do that. End users (home/soho) should get at least a /56 and ideally a /48. The standards and the RIR policies both allow for end-users/sites to get /48s. If you are an ISP, you get AT LEAST a /32. > See also the discussion about what to use in p2p links. > Yep. Personally, I like the /64 per subnet including p2p link approach. Others have different opinions. Owen > ----- Original Message ----- > From: "Brandon Kim" > To: nanog at nanog.org > Sent: Sunday, 17 October, 2010 8:58:57 AM > Subject: RE: Definitive Guide to IPv6 adoption > > > Thanks everyone who responded. This list is such a valuable wealth of information. > > Apparently I was wrong about the /64 as that should be /32 so thanks for that correction.... > > Thanks again especially on a Saturday weekend! > > > >> From: rdobbins at arbor.net >> To: nanog at nanog.org >> Date: Sat, 16 Oct 2010 16:09:43 +0000 >> Subject: Re: Definitive Guide to IPv6 adoption >> >> >> On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: >> >>> Then move on to the Internet which as with most things is where the most cuurent if not helpful information resides. >> >> >> Eric Vyncke's IPv6 security book is definitely worthwhile, as well, in combination with Schudel & Smith's infrastructure security book (the latter isn't IPv6-specific, but is the best book out there on infrastructure security): >> >> >> >> >> >> ----------------------------------------------------------------------- >> Roland Dobbins // >> >> Sell your computer and buy a guitar. >> >> >> >> >> > From dwhite at olp.net Sun Oct 17 19:05:37 2010 From: dwhite at olp.net (Dan White) Date: Sun, 17 Oct 2010 19:05:37 -0500 Subject: 12 years ago today... In-Reply-To: <4986CDF9-B97D-45F5-BB90-EF679EF72076@centergate.com> References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> <3998D283-D969-4176-985F-869D09F04D57@gmail.com> <4986CDF9-B97D-45F5-BB90-EF679EF72076@centergate.com> Message-ID: <20101018000535.GB6827@dan.olp.net> On 16/10/10?09:09?-0700, Rodney Joffe wrote: >I'm not sure about a documentary, but a group of us are working on identifying all the different independent archives that have records from "the early years" with the idea of creating a Smithsonian/national archive collection at some point. We'll probably issue an rfc early next year. Hopefully someone remembers to call it the Postel Historical Institute[*]. [*] RFC 1607 -- Dan White From warren at kumari.net Sun Oct 17 21:07:53 2010 From: warren at kumari.net (Warren Kumari) Date: Sun, 17 Oct 2010 22:07:53 -0400 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: <20101017025519.EB7C91CC3E@ptavv.es.net> References: <20101017025519.EB7C91CC3E@ptavv.es.net> Message-ID: <449A0E3D-F234-4F4E-8BB5-7554F2D2B437@kumari.net> On Oct 16, 2010, at 10:55 PM, Kevin Oberman wrote: >> Date: Sun, 17 Oct 2010 01:56:28 +0100 >> From: Randy Bush >> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt >>>> Drafts are drafts, and nothing more, aren't they? >> >> must be some blowhard i have plonked >> >>> Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a >>> handful have ever been designated as "Standards". I hope this becomes >>> one of those in the hope it will be taken seriously. (It already is by >>> anyone with a large network running IPv6.) >> >> juniper and cisco implement today > > Unfortunately, a couple of other router vendors whose top of the line > units I have tested recently did not. Simple Matter of Programming ;-) Please suggest to said vendors that they implement this -- IMO it's the right way to do it... W > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 > From mysidia at gmail.com Sun Oct 17 21:16:04 2010 From: mysidia at gmail.com (James Hess) Date: Sun, 17 Oct 2010 21:16:04 -0500 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: On Sat, Oct 16, 2010 at 11:46 PM, Day Domes wrote: > I have been tasked with coming up with a new name for are transit data > network.? I am thinking of using 101100010100110.net does anyone see > any issues with this? The domain-name starts with a digit, which is not really recommended, RFC 1034, due to the fact a valid actual hostname cannot start with a digit, and, for example, some MTAs/MUAs, that comply with earlier versions of standards still in use, will possibly have a problem sending e-mail to the flat domain, even if the actual hostname is something legal such as mail.101100010100110.net. Which goes back to one of the standard-provided definitions of domain name syntax used by RFC 821 page 29: ::= | "." ::= | "#" | "[" "]" ::= "@" ... ::= ... ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case ::= any one of the ten digits 0 through 9 -- -Jh From oberman at es.net Sun Oct 17 21:37:23 2010 From: oberman at es.net (Kevin Oberman) Date: Sun, 17 Oct 2010 19:37:23 -0700 Subject: Choice of network space when numbering interfaces with IPv6 In-Reply-To: Your message of "Sun, 17 Oct 2010 22:07:53 EDT." <449A0E3D-F234-4F4E-8BB5-7554F2D2B437@kumari.net> Message-ID: <20101018023723.AA3781CC42@ptavv.es.net> > From: Warren Kumari > Date: Sun, 17 Oct 2010 22:07:53 -0400 > > On Oct 16, 2010, at 10:55 PM, Kevin Oberman wrote: > > >> Date: Sun, 17 Oct 2010 01:56:28 +0100 > >> From: Randy Bush > >> > >>>>> http://www.ietf.org/internet-drafts/draft-ietf-6man-prefixlen-p2p-00.txt > >>>> Drafts are drafts, and nothing more, aren't they? > >> > >> must be some blowhard i have plonked > >> > >>> Drafts are drafts. Even most RFCs are RFCs and nothing more. Only a > >>> handful have ever been designated as "Standards". I hope this becomes > >>> one of those in the hope it will be taken seriously. (It already is by > >>> anyone with a large network running IPv6.) > >> > >> juniper and cisco implement today > > > > Unfortunately, a couple of other router vendors whose top of the line > > units I have tested recently did not. > > Simple Matter of Programming ;-) > > Please suggest to said vendors that they implement this -- IMO it's > the right way to do it... Rest assured that I did so during the debrief on our evaluation. I know one promised a fix quickly. I don't recall on the other as that problem was not very significant compared to other issues with that unit. These evals are so much fun. I had to listen to a sales type explain that mBGP was incomplete for MY benefit. It might confuse me to be able to run multiple address families over a single peering session. I am so touched for this sort of concern. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From bmanning at vacation.karoshi.com Sun Oct 17 21:40:21 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 18 Oct 2010 02:40:21 +0000 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: <20101018024021.GC8924@vacation.karoshi.com.> On Sun, Oct 17, 2010 at 09:16:04PM -0500, James Hess wrote: > On Sat, Oct 16, 2010 at 11:46 PM, Day Domes wrote: > > I have been tasked with coming up with a new name for are transit data > > network. I am thinking of using 101100010100110.net does anyone see > > any issues with this? > > The domain-name starts with a digit, which is not really recommended, RFC 1034, > due to the fact a valid actual hostname cannot start with a digit, > and, for example, > some MTAs/MUAs, that comply with earlier versions of standards still in use, > will possibly have a problem sending e-mail to the flat domain, even > if the actual hostname is > something legal such as mail.101100010100110.net. if there is code that old still out there, it desrves to die. the leading character restriction was lifted when the company 3com was created. its been nearly 18 years since that advice held true. > > Which goes back to one of the standard-provided definitions of domain > name syntax used by RFC 821 page 29: > > ::= | "." > ::= | "#" | "[" "]" > ::= "@" > ... > ::= > ... > ::= any one of the 52 alphabetic characters A through Z > in upper case and a through z in lower case > ::= any one of the ten digits 0 through 9 at least three times in the past decade, the issues of RFC 821 vs Domain lables has come up on the DNSEXT mailing list in the IETF (or its predacessor). RFC 821 hostnames are not the convention for Domain Labels, esp as we enter the age of Non-Ascii labels. That said, the world was much simpler last century. --bill > -- > -Jh > From steve at blighty.com Sun Oct 17 21:48:57 2010 From: steve at blighty.com (Steve Atkins) Date: Sun, 17 Oct 2010 19:48:57 -0700 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: <005DE1CA-6449-4835-85DB-B4E8FE6F7EE4@blighty.com> On Oct 17, 2010, at 7:16 PM, James Hess wrote: > On Sat, Oct 16, 2010 at 11:46 PM, Day Domes wrote: >> I have been tasked with coming up with a new name for are transit data >> network. I am thinking of using 101100010100110.net does anyone see >> any issues with this? > > The domain-name starts with a digit, which is not really recommended, RFC 1034, > due to the fact a valid actual hostname cannot start with a digit, A valid actual hostname can start with a digit. Many do. I'm guessing 3com may have had something to do with that trend. RFC 1123 2.1 clarified that a couple of decades ago, so I doubt you'll find any running software that doesn't agree. > and, for example, > some MTAs/MUAs, that comply with earlier versions of standards still in use, > will possibly have a problem sending e-mail to the flat domain, even > if the actual hostname is > something legal such as mail.101100010100110.net. > > Which goes back to one of the standard-provided definitions of domain > name syntax used by RFC 821 page 29: There are several less obsolete RFCs that specify email addresses, they're all quite specific about what a valid hostname is in an email sense. 5321 is the latest, I think, section 4.1.2. Cheers, Steve From marka at isc.org Sun Oct 17 22:18:53 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 18 Oct 2010 14:18:53 +1100 Subject: network name 101100010100110.net In-Reply-To: Your message of "Mon, 18 Oct 2010 02:40:21 -0000." <20101018024021.GC8924@vacation.karoshi.com.> References: <20101018024021.GC8924@vacation.karoshi.com.> Message-ID: <20101018031853.51F0F5C3EF5@drugs.dv.isc.org> In message <20101018024021.GC8924 at vacation.karoshi.com.>, bmanning at vacation.kar oshi.com writes: > On Sun, Oct 17, 2010 at 09:16:04PM -0500, James Hess wrote: > > On Sat, Oct 16, 2010 at 11:46 PM, Day Domes wrote: > > > I have been tasked with coming up with a new name for are transit data > > > network. I am thinking of using 101100010100110.net does anyone see > > > any issues with this? > > > > The domain-name starts with a digit, which is not really recommended, RFC > 1034, > > due to the fact a valid actual hostname cannot start with a digit, > > and, for example, > > some MTAs/MUAs, that comply with earlier versions of standards still in us > e, > > will possibly have a problem sending e-mail to the flat domain, even > > if the actual hostname is > > something legal such as mail.101100010100110.net. > > if there is code that old still out there, it desrves to die. > the leading character restriction was lifted when the company > 3com was created. its been nearly 18 years since that advice > held true. > > > Which goes back to one of the standard-provided definitions of domain > > name syntax used by RFC 821 page 29: > > > > ::= | "." > > ::= | "#" | "[" "]" > > ::= "@" > > ... > > ::= > > ... > > ::= any one of the 52 alphabetic characters A through Z > > in upper case and a through z in lower case > > ::= any one of the ten digits 0 through 9 > > at least three times in the past decade, the issues of RFC 821 > vs Domain lables has come up on the DNSEXT mailing list in the > IETF (or its predacessor). RFC 821 hostnames are not the > convention for Domain Labels, esp as we enter the age of > Non-Ascii labels. Correct but if you want to be able to send email to them then you *also* need to follow RFC 821 as modified by RFC 1123 so effectively you are limited to "**{.**}+". If you want to buy "!#$%^&*.com" go ahead but please don't expect anyone to change their mail software to support "bill@!#$%^&*.com" as a email address. The DNS has very liberal labels (any octet stream up to 63 octets in length). If you want to store information about a host, in the DNS, using its name then you still need to abide by the rules for naming hosts. Yes this is spelt out in RFC 1035. There are lots of RFCs which confuse "domain name" with "domain style host name". Or confuse "domain name" with "a host name stored in the DNS". Mark > That said, the world was much simpler last century. > > --bill > > > -- > > -Jh > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joe at nethead.com Sun Oct 17 22:24:30 2010 From: joe at nethead.com (Joe Hamelin) Date: Sun, 17 Oct 2010 20:24:30 -0700 Subject: network name 101100010100110.net In-Reply-To: <20101018031853.51F0F5C3EF5@drugs.dv.isc.org> References: <20101018024021.GC8924@vacation.karoshi.com.> <20101018031853.51F0F5C3EF5@drugs.dv.isc.org> Message-ID: That's why 3M registered mmm.com back in 1988. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 On Sun, Oct 17, 2010 at 8:18 PM, Mark Andrews wrote: > > In message <20101018024021.GC8924 at vacation.karoshi.com.>, bmanning at vacation.kar > oshi.com writes: >> On Sun, Oct 17, 2010 at 09:16:04PM -0500, James Hess wrote: >> > On Sat, Oct 16, 2010 at 11:46 PM, Day Domes wrote: >> > > I have been tasked with coming up with a new name for are transit data >> > > network. ?I am thinking of using 101100010100110.net does anyone see >> > > any issues with this? >> > >> > The domain-name starts with a digit, which is not really recommended, ?RFC >> 1034, >> > due to the fact a valid actual hostname ?cannot start with a digit, >> > and, for example, >> > some MTAs/MUAs, ?that comply with earlier versions of standards still in us >> e, >> > will possibly have a problem ?sending e-mail to the flat domain, even >> > if the actual hostname is >> > something legal such as mail.101100010100110.net. >> >> ? ? ? if there is code that old still out there, it desrves to die. >> ? ? ? the leading character restriction was lifted when the company >> ? ? ? 3com was created. ?its been nearly 18 years since that advice >> ? ? ? held true. >> >> > Which goes back to one of the standard-provided definitions of domain >> > name syntax used by RFC 821 page 29: >> > >> > ::= ? | "." >> > ::= | "#" | "[" "]" >> > ::= "@" >> > ... >> > ::= >> > ... >> > ::= any one of the 52 alphabetic characters A through Z >> > ? ? ? ? ? ? in upper case and a through z in lower case >> > ::= any one of the ten digits 0 through 9 >> >> ? ? ? at least three times in the past decade, the issues of RFC 821 >> ? ? ? vs Domain lables has come up on the DNSEXT mailing list in the >> ? ? ? IETF (or its predacessor). ? RFC 821 hostnames are not the >> ? ? ? convention for Domain Labels, esp as we enter the age of >> ? ? ? Non-Ascii labels. > > Correct but if you want to be able to send email to them then you > *also* need to follow RFC 821 as modified by RFC 1123 so effectively > you are limited to "**{.**}+". > > If you want to buy "!#$%^&*.com" go ahead but please don't expect > anyone to change their mail software to support "bill@!#$%^&*.com" > as a email address. > > The DNS has very liberal labels (any octet stream up to 63 octets > in length). ?If you want to store information about a host, in the > DNS, using its name then you still need to abide by the rules for > naming hosts. ?Yes this is spelt out in RFC 1035. > > There are lots of RFCs which confuse "domain name" with "domain > style host name". ?Or confuse "domain name" with "a host name stored > in the DNS". > > Mark > >> ? ? ? That said, the world was much simpler last century. >> >> --bill >> >> > -- >> > -Jh >> > >> > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 ? ? ? ? ? ? ? ? INTERNET: marka at isc.org > > From leo.vegoda at icann.org Sun Oct 17 23:22:25 2010 From: leo.vegoda at icann.org (Leo Vegoda) Date: Sun, 17 Oct 2010 21:22:25 -0700 Subject: 36/8 and 42/8 allocated to APNIC Message-ID: <1DED98D5-81AF-4C5C-A8EF-9F539E901675@icann.org> Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in October 2010: 36/8 and 42/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt The complete list of IPv4 /8s allocated so far this year is: 1/8 14/8 27/8 31/8 36/8 42/8 49/8 50/8 101/8 107/8 176/8 177/8 181/8 223/8 Please update your filters as appropriate. The IANA free pool contains 12 unallocated unicast IPv4 /8s. Regards, Leo Vegoda Number Resources Manager, IANA ICANN From jonas at bjorklund.cn Sun Oct 17 23:53:49 2010 From: jonas at bjorklund.cn (=?UTF-8?Q?Jonas_Bj=F6rklund?=) Date: Mon, 18 Oct 2010 06:53:49 +0200 (CEST) Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: On Sat, 16 Oct 2010, Ken Gilmour wrote: > Hello any weekend workers :) > > We are looking at urgently deploying an outsourced DNS provider for a > critical domain which is currently unavailable but are having some > difficulty. I've tried contacting UltraDNS who only allow customers from US > / Canada to sign up (we are in Malta) and their Sales dept are closed, and > Easy DNS who don't have .com.mt as an option in the dropdown for > transferring domain names (and also support is closed). I have worked for one of the biggest poker networks and we used UltraDNS. The company was first operated from Sweden and later Austria. /Jonas From jeffrey.lyon at blacklotus.net Mon Oct 18 00:28:59 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 18 Oct 2010 09:58:59 +0430 Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: We're using Afilias now, we had nothing short of a horrendous experience dealing with Neustar / UltraDNS and their uninformed, blood hungry sales team. Best regards, Jeff On Mon, Oct 18, 2010 at 9:23 AM, Jonas Bj?rklund wrote: > > On Sat, 16 Oct 2010, Ken Gilmour wrote: > >> Hello any weekend workers :) >> >> We are looking at urgently deploying an outsourced DNS provider for a >> critical domain which is currently unavailable but are having some >> difficulty. I've tried contacting UltraDNS who only allow customers from >> US >> / Canada to sign up (we are in Malta) and their Sales dept are closed, and >> Easy DNS who don't have .com.mt as an option in the dropdown for >> transferring domain names (and also support is closed). > > I have worked for one of the biggest poker networks and we used UltraDNS. > The company was first operated from Sweden and later Austria. > > /Jonas > > -- 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 ken.gilmour at gmail.com Mon Oct 18 01:17:52 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Mon, 18 Oct 2010 08:17:52 +0200 Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: On 18 October 2010 06:53, Jonas Bj?rklund wrote: > > I have worked for one of the biggest poker networks and we used UltraDNS. > The company was first operated from Sweden and later Austria. > > /Jonas > I would tend to agree... I have also used UltraDNS in the past for other companies, however we needed them urgently and someone else responded faster and they seem to be doing a good job so far. Regards, Ken From joelja at bogus.com Mon Oct 18 01:33:13 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 17 Oct 2010 23:33:13 -0700 Subject: network name 101100010100110.net In-Reply-To: References: <20101018024021.GC8924@vacation.karoshi.com.> <20101018031853.51F0F5C3EF5@drugs.dv.isc.org> Message-ID: <4CBBEA29.4010805@bogus.com> On 10/17/10 8:24 PM, Joe Hamelin wrote: > That's why 3M registered mmm.com back in 1988. and not just because minnestoaminingandmanufacturing.com is hard to type... they've since officially change the name of the company to 3m... > -- > Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 > > > > On Sun, Oct 17, 2010 at 8:18 PM, Mark Andrews wrote: >> >> In message <20101018024021.GC8924 at vacation.karoshi.com.>, bmanning at vacation.kar >> oshi.com writes: >>> On Sun, Oct 17, 2010 at 09:16:04PM -0500, James Hess wrote: >>>> On Sat, Oct 16, 2010 at 11:46 PM, Day Domes wrote: >>>>> I have been tasked with coming up with a new name for are transit data >>>>> network. I am thinking of using 101100010100110.net does anyone see >>>>> any issues with this? >>>> >>>> The domain-name starts with a digit, which is not really recommended, RFC >>> 1034, >>>> due to the fact a valid actual hostname cannot start with a digit, >>>> and, for example, >>>> some MTAs/MUAs, that comply with earlier versions of standards still in us >>> e, >>>> will possibly have a problem sending e-mail to the flat domain, even >>>> if the actual hostname is >>>> something legal such as mail.101100010100110.net. >>> >>> if there is code that old still out there, it desrves to die. >>> the leading character restriction was lifted when the company >>> 3com was created. its been nearly 18 years since that advice >>> held true. >>> >>>> Which goes back to one of the standard-provided definitions of domain >>>> name syntax used by RFC 821 page 29: >>>> >>>> ::= | "." >>>> ::= | "#" | "[" "]" >>>> ::= "@" >>>> ... >>>> ::= >>>> ... >>>> ::= any one of the 52 alphabetic characters A through Z >>>> in upper case and a through z in lower case >>>> ::= any one of the ten digits 0 through 9 >>> >>> at least three times in the past decade, the issues of RFC 821 >>> vs Domain lables has come up on the DNSEXT mailing list in the >>> IETF (or its predacessor). RFC 821 hostnames are not the >>> convention for Domain Labels, esp as we enter the age of >>> Non-Ascii labels. >> >> Correct but if you want to be able to send email to them then you >> *also* need to follow RFC 821 as modified by RFC 1123 so effectively >> you are limited to "**{.**}+". >> >> If you want to buy "!#$%^&*.com" go ahead but please don't expect >> anyone to change their mail software to support "bill@!#$%^&*.com" >> as a email address. >> >> The DNS has very liberal labels (any octet stream up to 63 octets >> in length). If you want to store information about a host, in the >> DNS, using its name then you still need to abide by the rules for >> naming hosts. Yes this is spelt out in RFC 1035. >> >> There are lots of RFCs which confuse "domain name" with "domain >> style host name". Or confuse "domain name" with "a host name stored >> in the DNS". >> >> Mark >> >>> That said, the world was much simpler last century. >>> >>> --bill >>> >>>> -- >>>> -Jh >>>> >>> >> -- >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka at isc.org >> >> > > From shacolby at bluejeansnet.com Mon Oct 18 02:13:14 2010 From: shacolby at bluejeansnet.com (Shacolby Jackson) Date: Mon, 18 Oct 2010 00:13:14 -0700 Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: I have used UltraDNS before. They are decent. I am however evaluating Dynect (www.dyn.com) who are very popular with social media companies like Twitter. On Sun, Oct 17, 2010 at 11:17 PM, Ken Gilmour wrote: > On 18 October 2010 06:53, Jonas Bj?rklund wrote: > > > > > I have worked for one of the biggest poker networks and we used UltraDNS. > > The company was first operated from Sweden and later Austria. > > > > /Jonas > > > > I would tend to agree... I have also used UltraDNS in the past for other > companies, however we needed them urgently and someone else responded > faster > and they seem to be doing a good job so far. > > Regards, > > Ken > From joe at nethead.com Mon Oct 18 02:20:53 2010 From: joe at nethead.com (Joe Hamelin) Date: Mon, 18 Oct 2010 00:20:53 -0700 Subject: network name 101100010100110.net In-Reply-To: <4CBBEA29.4010805@bogus.com> References: <20101018024021.GC8924@vacation.karoshi.com.> <20101018031853.51F0F5C3EF5@drugs.dv.isc.org> <4CBBEA29.4010805@bogus.com> Message-ID: Joel said: and not just because minnestoaminingandmanufacturing.com is hard to type... Also back then you could only have eight letters in your domain name. But it was free and only took 6-8 weeks to get. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From nanog at deman.com Mon Oct 18 02:36:33 2010 From: nanog at deman.com (Michael DeMan) Date: Mon, 18 Oct 2010 00:36:33 -0700 Subject: Terminology Request, WAS: Enterprise DNS providers In-Reply-To: References: Message-ID: Hi, I have been following this thread, and am mostly curious - can somebody (or preferably several folks) define what is meant by 'Enterprise DNS' ? Thanks, - Mike On Oct 16, 2010, at 3:03 AM, Ken Gilmour wrote: > Hello any weekend workers :) > > We are looking at urgently deploying an outsourced DNS provider for a > critical domain which is currently unavailable but are having some > difficulty. I've tried contacting UltraDNS who only allow customers from US > / Canada to sign up (we are in Malta) and their Sales dept are closed, and > Easy DNS who don't have .com.mt as an option in the dropdown for > transferring domain names (and also support is closed). > > Black Lotus looks like the next best contender, has anyone had experience > with these or any other recommendations for how we can transfer a .com.mt to > a reliable hosting provider during the weekend? > > Thanks! > > Ken From mansaxel at besserwisser.org Mon Oct 18 03:21:29 2010 From: mansaxel at besserwisser.org (Mans Nilsson) Date: Mon, 18 Oct 2010 10:21:29 +0200 Subject: Terminology Request, WAS: Enterprise DNS providers In-Reply-To: References: Message-ID: <20101018082129.GC4746@besserwisser.org> Subject: Terminology Request, WAS: Enterprise DNS providers Date: Mon, Oct 18, 2010 at 12:36:33AM -0700 Quoting Michael DeMan (nanog at deman.com): > Hi, > > I have been following this thread, and am mostly curious - can somebody (or preferably several folks) define what is meant by 'Enterprise DNS' ? "Quality DNS operations for people with lots of money and not so lots of operational capacity (dare I say clue?)" -- M?ns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... I'm IMAGINING a sensuous GIRAFFE, CAVORTING in the BACK ROOM of a KOSHER DELI -- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available URL: From daydomes at gmail.com Mon Oct 18 05:02:56 2010 From: daydomes at gmail.com (Day Domes) Date: Mon, 18 Oct 2010 06:02:56 -0400 Subject: Network Operators Europe? Message-ID: What is the name of the mailing list for Network Operators Europe? From jeroen at unfix.org Mon Oct 18 05:47:50 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 18 Oct 2010 12:47:50 +0200 Subject: Network Operators Europe? In-Reply-To: References: Message-ID: <4CBC25D6.5010504@unfix.org> On 2010-10-18 12:02, Day Domes wrote: > What is the name of the mailing list for Network Operators Europe? RIPE which has several mailing lists on a subject basis. Most simply use nanog though ;) and per-country there are several other *NOGs too. See Wikipedia for an extended list. Greets, Jeroen From pica8.org at gmail.com Mon Oct 18 06:25:23 2010 From: pica8.org at gmail.com (Lin Pica8) Date: Mon, 18 Oct 2010 13:25:23 +0200 Subject: Pica8 - Open Source Cloud Switch Message-ID: Hello, We are starting to distribute Pica8 Open Source Cloud Switches : http://www.pica8.com/ Especially, a Pica8 Switch with the following specifications (including Open Source Firmware) : -HW : 48x1Gbps + 4x10 Gbps -Firmware : L2/L3 management for VLAN, LACP, STP/RSTP, LLDP, OSPF, RIP, static route, PIM-SM, VRRP, IGMP, IGMP Snooping, IPv6, Radius/Tacacs+ as well as OpenFlow 1.0 would compete with a Cisco Catalyst 2960-S, Model WS-C2960S-48TD-L for half the price (~2k USD). Mail : pica8.org at gmail.com From jeffrey.lyon at blacklotus.net Mon Oct 18 06:29:31 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 18 Oct 2010 15:59:31 +0430 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: References: Message-ID: Cool story bro. On Mon, Oct 18, 2010 at 3:55 PM, Lin Pica8 wrote: > Hello, > > We are starting to distribute Pica8 Open Source Cloud Switches : > > http://www.pica8.com/ > > Especially, a Pica8 Switch with the following specifications > (including Open Source Firmware) : > > -HW : 48x1Gbps + 4x10 Gbps > > -Firmware : ?L2/L3 management for VLAN, LACP, STP/RSTP, LLDP, OSPF, > RIP, static route, PIM-SM, VRRP, IGMP, IGMP Snooping, IPv6, > Radius/Tacacs+ as well as OpenFlow 1.0 > > would compete with a Cisco Catalyst 2960-S, Model WS-C2960S-48TD-L for > half the price (~2k USD). > > Mail : pica8.org 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 mir at ripe.net Mon Oct 18 06:41:08 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 18 Oct 2010 13:41:08 +0200 Subject: Network Operators Europe? In-Reply-To: References: Message-ID: <4CBC3254.9070307@ripe.net> Day Domes wrote: > What is the name of the mailing list for Network Operators Europe? > Hi Day, As Jeroen pointed out, the European operators group is called RIPE. You can find information about the mailing list here: http://www.ripe.net/mailman/listinfo/ripe-list There are also a bunch of works groups on various topics (IPv6, routing, dns etc.). See a list here: http://www.ripe.net/ripe/wg Regards, Mirjam From jeroen at unfix.org Mon Oct 18 06:44:40 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 18 Oct 2010 13:44:40 +0200 Subject: Only 5x IPv4 /8 remaining at IANA Message-ID: <4CBC3328.7090205@unfix.org> APNIC just got another IPv4 /8 thus only 5 left: http://www.nro.net/media/remaining-ipv4-address-below-5.html (And the spammers will take the rest...) So, if your company is not doing IPv6 yet, you really are really getting late now. Greets, Jeroen (PS: There seems to be a trend for people calling themselves"IPv6 Pioneers" as they recently did something with IPv6, if you didn't play in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years late) From sds at dcs.gla.ac.uk Mon Oct 18 06:51:04 2010 From: sds at dcs.gla.ac.uk (Stephen D. Strowes) Date: Mon, 18 Oct 2010 12:51:04 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3328.7090205@unfix.org> References: <4CBC3328.7090205@unfix.org> Message-ID: <1287402664.28720.1.camel@carney> On Mon, 2010-10-18 at 12:44 +0100, Jeroen Massar wrote: > APNIC just got another IPv4 /8 thus only 5 left: Thought it was the other way around. There are 12 remaining: 7 will be allocated normally, with the remaining 5 split across the five RIRs. -S. From dot at dotat.at Mon Oct 18 06:57:23 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 18 Oct 2010 12:57:23 +0100 Subject: network name 101100010100110.net In-Reply-To: <20101018024021.GC8924@vacation.karoshi.com.> References: <20101018024021.GC8924@vacation.karoshi.com.> Message-ID: On Mon, 18 Oct 2010, bmanning at vacation.karoshi.com wrote: > On Sun, Oct 17, 2010 at 09:16:04PM -0500, James Hess wrote: > > > > Which goes back to one of the standard-provided definitions of domain > > name syntax used by RFC 821 page 29: RFC 821 defines the syntax for mail domains, not domain names in general. > RFC 821 hostnames are not the convention for Domain Labels, esp as we > enter the age of Non-Ascii labels. Host names are not mail domains. RFC 952 defined the syntax for host names. RFC 1034 recommends that labels in the DNS follow either 822 or 952 syntax (which are mostly the same). All of these were updated by RFC 1123 to allow leading digits. Internationalized domain names do not affect the restrictions on the syntax of what is put in the DNS. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From prt at prt.org Mon Oct 18 07:01:56 2010 From: prt at prt.org (Paul Thornton) Date: Mon, 18 Oct 2010 13:01:56 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3328.7090205@unfix.org> References: <4CBC3328.7090205@unfix.org> Message-ID: <4CBC3734.6090806@prt.org> Jeroen Massar wrote: > APNIC just got another IPv4 /8 thus only 5 left: > > http://www.nro.net/media/remaining-ipv4-address-below-5.html > (And the spammers will take the rest...) Just for clarification, that article says 5% left, not 5x /8. According to Leo's E-mail earlier, they have 12 /8s left in the free pool. And +1 on the "pioneers" comment too. Paul. From will at harg.net Mon Oct 18 07:03:54 2010 From: will at harg.net (Will Hargrave) Date: Mon, 18 Oct 2010 13:03:54 +0100 Subject: 12 years ago today... In-Reply-To: References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> <3998D283-D969-4176-985F-869D09F04D57@gmail.com> Message-ID: <4CBC37AA.4020809@harg.net> On 16/10/10 10:02, Warren Bailey wrote: > While we are on the subject of "the godfathers of the Internet", when is a > documentary coming out that tells the story? There was a really long > documentary done on the BBS, surely someone (myself included) would find it > interesting. I can recommend "Where Wizards Stay Up Late" by Katie Hafner http://www.amazon.com/Where-Wizards-Stay-Up-Late/dp/0684832674 A really good read IMHO. Will From ml at kenweb.org Mon Oct 18 07:16:32 2010 From: ml at kenweb.org (ML) Date: Mon, 18 Oct 2010 08:16:32 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3734.6090806@prt.org> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> Message-ID: <4CBC3AA0.9040607@kenweb.org> > And +1 on the "pioneers" comment too. > > Paul. > IPv6 Hipsters..Doing it before it was cool. From nick at foobar.org Mon Oct 18 07:21:29 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 18 Oct 2010 13:21:29 +0100 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: References: Message-ID: <4CBC3BC9.7070803@foobar.org> On 18/10/2010 12:25, Lin Pica8 wrote: > We are starting to distribute Pica8 Open Source Cloud Switches : Sounds interesting. What chipset does this run on? Also, what's a cloud switch? Is this a switch which forwards L2 traffic, or did I miss something? Nick From cmaurand at xyonet.com Mon Oct 18 07:28:09 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Mon, 18 Oct 2010 08:28:09 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3AA0.9040607@kenweb.org> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> Message-ID: <4CBC3D59.3010401@xyonet.com> On 10/18/2010 8:16 AM, ML wrote: > > And +1 on the "pioneers" comment too. >> >> Paul. >> > > IPv6 Hipsters..Doing it before it was cool. > > > IPV4 ->easy(); IPV6->really().Really().Difficult(); From lists at quux.de Mon Oct 18 07:28:47 2010 From: lists at quux.de (Jens Link) Date: Mon, 18 Oct 2010 14:28:47 +0200 Subject: Definitive Guide to IPv6 adoption In-Reply-To: (Roland Dobbins's message of "Sat, 16 Oct 2010 16:09:43 +0000") References: <20101017004041.7f19f304@opy.nosense.org> <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com> Message-ID: <87wrpfelc0.fsf@oban.berlin.quux.de> "Dobbins, Roland" writes: > Eric Vyncke's IPv6 security book is definitely worthwhile, > > A good companion to Eric's book is Deploying IPv6 Networks Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From hb-nanog at bsws.de Mon Oct 18 07:30:48 2010 From: hb-nanog at bsws.de (Henning Brauer) Date: Mon, 18 Oct 2010 14:30:48 +0200 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: References: Message-ID: <20101018123046.GU10815@nudo.bsws.de> * Lin Pica8 [2010-10-18 13:27]: > We are starting to distribute Pica8 Open Source Cloud Switches : open source? you gotta be joking. "Currently, the Pica8 driver is released in binary form" none of the interesting low-level drivers is open. none. zero. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From lists at quux.de Mon Oct 18 07:41:36 2010 From: lists at quux.de (Jens Link) Date: Mon, 18 Oct 2010 14:41:36 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3328.7090205@unfix.org> (Jeroen Massar's message of "Mon, 18 Oct 2010 13:44:40 +0200") References: <4CBC3328.7090205@unfix.org> Message-ID: <87k4lfekqn.fsf@oban.berlin.quux.de> Jeroen Massar writes: > So, if your company is not doing IPv6 yet, you really are really getting > late now. They won't listen. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From jeffrey.lyon at blacklotus.net Mon Oct 18 08:15:16 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 18 Oct 2010 17:45:16 +0430 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <87k4lfekqn.fsf@oban.berlin.quux.de> References: <4CBC3328.7090205@unfix.org> <87k4lfekqn.fsf@oban.berlin.quux.de> Message-ID: I'll listen, but I need my vendors, carriers, etc. to all get on board first. Jeff On Mon, Oct 18, 2010 at 5:11 PM, Jens Link wrote: > Jeroen Massar writes: > >> So, if your company is not doing IPv6 yet, you really are really getting >> late now. > > They won't listen. > > Jens > -- > ------------------------------------------------------------------------- > | Foelderichstr. 40 ? | 13595 Berlin, Germany ? ?| +49-151-18721264 ? ? | > | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- ?| > ------------------------------------------------------------------------- > > -- 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 franck at genius.com Mon Oct 18 08:22:29 2010 From: franck at genius.com (Franck Martin) Date: Tue, 19 Oct 2010 01:22:29 +1200 (FJT) Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: Message-ID: <26885469.843.1287408149659.JavaMail.franck@franck-martins-macbook-pro.local> Nah... Get IPv6 for your clients today, think about your servers for later... Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc.... ----- Original Message ----- From: "Jeffrey Lyon" To: "Jens Link" Cc: nanog at nanog.org Sent: Tuesday, 19 October, 2010 1:15:16 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA I'll listen, but I need my vendors, carriers, etc. to all get on board first. Jeff On Mon, Oct 18, 2010 at 5:11 PM, Jens Link wrote: > Jeroen Massar writes: > >> So, if your company is not doing IPv6 yet, you really are really getting >> late now. > > They won't listen. From brandon.kim at brandontek.com Mon Oct 18 08:27:03 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 18 Oct 2010 09:27:03 -0400 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <4CBC3BC9.7070803@foobar.org> References: , <4CBC3BC9.7070803@foobar.org> Message-ID: Good question Nick, what is a cloud switch? Is this like VSS in cisco where you have a virtual chassis? > Date: Mon, 18 Oct 2010 13:21:29 +0100 > From: nick at foobar.org > To: pica8.org at gmail.com > Subject: Re: Pica8 - Open Source Cloud Switch > CC: nanog at nanog.org > > On 18/10/2010 12:25, Lin Pica8 wrote: > > We are starting to distribute Pica8 Open Source Cloud Switches : > > Sounds interesting. What chipset does this run on? > > Also, what's a cloud switch? Is this a switch which forwards L2 traffic, > or did I miss something? > > Nick > > From jeffrey.lyon at blacklotus.net Mon Oct 18 08:39:27 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 18 Oct 2010 18:09:27 +0430 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <26885469.843.1287408149659.JavaMail.franck@franck-martins-macbook-pro.local> References: <26885469.843.1287408149659.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: My clients can't use IPv6 when my infrastructure and carriers don't support it. Jeff On Mon, Oct 18, 2010 at 5:52 PM, Franck Martin wrote: > Nah... > > Get IPv6 for your clients today, think about your servers for later... > > Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc.... > > ----- Original Message ----- > From: "Jeffrey Lyon" > To: "Jens Link" > Cc: nanog at nanog.org > Sent: Tuesday, 19 October, 2010 1:15:16 AM > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > I'll listen, but I need my vendors, carriers, etc. to all get on board first. > > Jeff > > On Mon, Oct 18, 2010 at 5:11 PM, Jens Link wrote: >> Jeroen Massar writes: >> >>> So, if your company is not doing IPv6 yet, you really are really getting >>> late now. >> >> They won't listen. > -- 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 patrick at ianai.net Mon Oct 18 08:57:18 2010 From: patrick at ianai.net (Patrick W. Gilmore) Date: Mon, 18 Oct 2010 09:57:18 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <26885469.843.1287408149659.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <5B8DFF38-7325-491C-93DA-FFC5BFFF6FEF@ianai.net> On Oct 18, 2010, at 9:39 AM, Jeffrey Lyon wrote: > My clients can't use IPv6 when my infrastructure and carriers don't support it. Smells like a business opportunity to steal your customers. Thanx! -- TTFN, patrick > On Mon, Oct 18, 2010 at 5:52 PM, Franck Martin wrote: >> Nah... >> >> Get IPv6 for your clients today, think about your servers for later... >> >> Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc.... >> >> ----- Original Message ----- >> From: "Jeffrey Lyon" >> To: "Jens Link" >> Cc: nanog at nanog.org >> Sent: Tuesday, 19 October, 2010 1:15:16 AM >> Subject: Re: Only 5x IPv4 /8 remaining at IANA >> >> I'll listen, but I need my vendors, carriers, etc. to all get on board first. >> >> Jeff >> >> On Mon, Oct 18, 2010 at 5:11 PM, Jens Link wrote: >>> Jeroen Massar writes: >>> >>>> So, if your company is not doing IPv6 yet, you really are really getting >>>> late now. >>> >>> They won't listen. >> > > > > -- > 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 jeffrey.lyon at blacklotus.net Mon Oct 18 09:12:14 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Mon, 18 Oct 2010 18:42:14 +0430 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <5B8DFF38-7325-491C-93DA-FFC5BFFF6FEF@ianai.net> References: <26885469.843.1287408149659.JavaMail.franck@franck-martins-macbook-pro.local> <5B8DFF38-7325-491C-93DA-FFC5BFFF6FEF@ianai.net> Message-ID: Only if you're prepared for the bloody onslaught of DDoS. Jeff On Mon, Oct 18, 2010 at 6:27 PM, Patrick W. Gilmore wrote: > On Oct 18, 2010, at 9:39 AM, Jeffrey Lyon wrote: > >> My clients can't use IPv6 when my infrastructure and carriers don't support it. > > Smells like a business opportunity to steal your customers. > > Thanx! > > -- > TTFN, > patrick > > >> On Mon, Oct 18, 2010 at 5:52 PM, Franck Martin wrote: >>> Nah... >>> >>> Get IPv6 for your clients today, think about your servers for later... >>> >>> Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc.... >>> >>> ----- Original Message ----- >>> From: "Jeffrey Lyon" >>> To: "Jens Link" >>> Cc: nanog at nanog.org >>> Sent: Tuesday, 19 October, 2010 1:15:16 AM >>> Subject: Re: Only 5x IPv4 /8 remaining at IANA >>> >>> I'll listen, but I need my vendors, carriers, etc. to all get on board first. >>> >>> Jeff >>> >>> On Mon, Oct 18, 2010 at 5:11 PM, Jens Link wrote: >>>> Jeroen Massar writes: >>>> >>>>> So, if your company is not doing IPv6 yet, you really are really getting >>>>> late now. >>>> >>>> They won't listen. >>> >> >> >> >> -- >> Jeffrey Lyon, Leadership Team >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net >> Black Lotus Communications - AS32421 >> First and Leading in DDoS Protection Solutions >> > > > -- 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 nick at foobar.org Mon Oct 18 09:13:35 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 18 Oct 2010 15:13:35 +0100 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: References: , <4CBC3BC9.7070803@foobar.org> Message-ID: <4CBC560F.70708@foobar.org> On 18/10/2010 14:27, Brandon Kim wrote: > Good question Nick, what is a cloud switch? Is this like VSS in cisco > where you have a virtual chassis? The vss is virtual management software for a virtual switch. This box looks like a piece of hardware that you can plug things into, so I'm just wondering what makes this a cloud switch and some other piece of kit not a cloud switch. Nick From MatlockK at exempla.org Mon Oct 18 09:26:29 2010 From: MatlockK at exempla.org (Matlock, Kenneth L) Date: Mon, 18 Oct 2010 08:26:29 -0600 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <4CBC560F.70708@foobar.org> References: , <4CBC3BC9.7070803@foobar.org> <4CBC560F.70708@foobar.org> Message-ID: <4288131ED5E3024C9CD4782CECCAD2C70B9A2EB2@LMC-MAIL2.exempla.org> Because 'cloud computing' is the latest buzzword, and their marketing department thought that by attaching that buzzword to it, that would increase sales? :) Nevermind that clouds contain nothing but vapor..... Ken Matlock Network Analyst Exempla Healthcare (303) 467-4671 matlockk at exempla.org -----Original Message----- From: Nick Hilliard [mailto:nick at foobar.org] Sent: Monday, October 18, 2010 8:14 AM To: Brandon Kim Cc: nanog at nanog.org Subject: Re: Pica8 - Open Source Cloud Switch On 18/10/2010 14:27, Brandon Kim wrote: > Good question Nick, what is a cloud switch? Is this like VSS in cisco > where you have a virtual chassis? The vss is virtual management software for a virtual switch. This box looks like a piece of hardware that you can plug things into, so I'm just wondering what makes this a cloud switch and some other piece of kit not a cloud switch. Nick From jim at reptiles.org Mon Oct 18 09:43:07 2010 From: jim at reptiles.org (Jim Mercer) Date: Mon, 18 Oct 2010 10:43:07 -0400 Subject: Co-Lo and Connectivity options in Kuwait In-Reply-To: <1E8B940C5E21014AB8BE70B975D40EDB0395855B@bert.HiberniaAtlantic.local> References: <017265BF3B9640499754DD48777C3D206A0E90C998@MBX9.EXCHPROD.USA.NET> <1E8B940C5E21014AB8BE70B975D40EDB0395855B@bert.HiberniaAtlantic.local> Message-ID: <20101018144307.GA30894@reptiles.org> On Thu, Oct 14, 2010 at 07:34:18PM +0100, Rod Beck wrote: > Good luck. }The Middle East is generally a horror. Prices are sky high. i was generally happy with my co-lo with etisalat in Dubai. that would also provide connectivity to kuwait and other places in the region as etisalat/emix seem to be pretty core to the connectivity in the middle east. email me if you need help working yoru way throught their maze. --jim > > Roderick S. Beck > Director of European Sales > Hibernia Atlantic > Budapest, New York, and Paris > > -----Original Message----- > From: Dylan Ebner [mailto:dylan.ebner at crlmed.com] > Sent: Thu 10/14/2010 3:53 PM > To: nanog at nanog.org > Subject: Co-Lo and Connectivity options in Kuwait > > Does anyone have any experience with Co-lo and connectivity in Kuwait. This would be my first time depolying in the middle east. Any advice, experiences anyone wishes to share is welcome. > > Thanks > > > > Dylan Ebner > -- Jim Mercer jim at reptiles.org +1 416 410-5633 You are more likely to be arrested as a terrorist than you are to be blown up by one. -- Dianora From joelja at bogus.com Mon Oct 18 09:50:01 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 18 Oct 2010 07:50:01 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3AA0.9040607@kenweb.org> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> Message-ID: <4CBC5E99.7010309@bogus.com> On 10/18/10 5:16 AM, ML wrote: > > And +1 on the "pioneers" comment too. >> >> Paul. >> > > IPv6 Hipsters..Doing it before it was cool. Late to the party... The hipsters have already moved on having grown bored with their v6 deployments around 2004. > > From brandon.kim at brandontek.com Mon Oct 18 09:58:05 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 18 Oct 2010 10:58:05 -0400 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70B9A2EB2@LMC-MAIL2.exempla.org> References: , <4CBC3BC9.7070803@foobar.org> <4CBC560F.70708@foobar.org>, <4288131ED5E3024C9CD4782CECCAD2C70B9A2EB2@LMC-MAIL2.exempla.org> Message-ID: Has our industry ever really fundamentally defined what is "cloud computing"????? Even though "MPLS" is sort of a buzzword too, we can define it, how it works, it's protocol and such... But cloud computing? > Subject: RE: Pica8 - Open Source Cloud Switch > Date: Mon, 18 Oct 2010 08:26:29 -0600 > From: MatlockK at exempla.org > To: nick at foobar.org; brandon.kim at brandontek.com > CC: nanog at nanog.org > > Because 'cloud computing' is the latest buzzword, and their marketing > department thought that by attaching that buzzword to it, that would > increase sales? :) > > Nevermind that clouds contain nothing but vapor..... > > Ken Matlock > Network Analyst > Exempla Healthcare > (303) 467-4671 > matlockk at exempla.org > > > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Monday, October 18, 2010 8:14 AM > To: Brandon Kim > Cc: nanog at nanog.org > Subject: Re: Pica8 - Open Source Cloud Switch > > On 18/10/2010 14:27, Brandon Kim wrote: > > Good question Nick, what is a cloud switch? Is this like VSS in cisco > > where you have a virtual chassis? > > The vss is virtual management software for a virtual switch. This box > looks like a piece of hardware that you can plug things into, so I'm > just > wondering what makes this a cloud switch and some other piece of kit not > a > cloud switch. > > Nick > From jmamodio at gmail.com Mon Oct 18 10:07:35 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Mon, 18 Oct 2010 10:07:35 -0500 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: References: <4CBC3BC9.7070803@foobar.org> <4CBC560F.70708@foobar.org> <4288131ED5E3024C9CD4782CECCAD2C70B9A2EB2@LMC-MAIL2.exempla.org> Message-ID: > But cloud computing? Yes, it is distributed high performance computing on a rainy day with a 99% chance of marketing hype and a 100% chance of non interoperability between clouds ... forecast may vary in your area. -J From nanog-poster at axu.tm Mon Oct 18 10:07:32 2010 From: nanog-poster at axu.tm (Aleksi Suhonen) Date: Mon, 18 Oct 2010 18:07:32 +0300 Subject: Only 5x IPv4 /8 remaining at IANA Message-ID: <4CBC62B4.9080301@axu.tm> Hello, ML wrote: > IPv6 Hipsters..Doing it before it was cool. I'm afraid I'm still doing it before it's cool. )-; -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail From xenophage at godshell.com Mon Oct 18 10:09:34 2010 From: xenophage at godshell.com (Jason 'XenoPhage' Frisvold) Date: Mon, 18 Oct 2010 11:09:34 -0400 Subject: [Nanog] Re: 12 years ago today... In-Reply-To: <4CBC37AA.4020809@harg.net> References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> <3998D283-D969-4176-985F-869D09F04D57@gmail.com> <4CBC37AA.4020809@harg.net> Message-ID: <4CBC632E.5010309@godshell.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/18/2010 08:03 AM, Will Hargrave wrote: > I can recommend "Where Wizards Stay Up Late" by Katie Hafner > > http://www.amazon.com/Where-Wizards-Stay-Up-Late/dp/0684832674 > > A really good read IMHO. An excellent read, highly recommended! Also check out Steven Levy's Hackers. It goes a bit beyond the Internet, but the first part is definitely relevant. I would love to see an actual documentary put together, though. Surely there has to be footage out there of the early days. > Will - -- - --------------------------- Jason 'XenoPhage' Frisvold xenophage at godshell.com - --------------------------- "Any sufficiently advanced magic is indistinguishable from technology." - - Niven's Inverse of Clarke's Third Law -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAky8Yy4ACgkQ8CjzPZyTUTRKAACglM2TermfAYHX/Mo6nIqDpQ4M oTsAn2dxeZXDhBdET2QHwYBFPiOHVwPQ =sZ3V -----END PGP SIGNATURE----- From gbonser at seven.com Mon Oct 18 10:17:09 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 18 Oct 2010 08:17:09 -0700 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: References: , <4CBC3BC9.7070803@foobar.org><4CBC560F.70708@foobar.org>, <4288131ED5E3024C9CD4782CECCAD2C70B9A2EB2@LMC-MAIL2.exempla.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C35B@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Brandon Kim > Sent: Monday, October 18, 2010 7:58 AM > > Cc: nanog at nanog.org > Subject: RE: Pica8 - Open Source Cloud Switch > > > Has our industry ever really fundamentally defined what is "cloud > computing"????? > > Even though "MPLS" is sort of a buzzword too, we can define it, how it > works, it's protocol and such... > > But cloud computing? My take on "cloud computing" is simply the provisioning servers or virtual servers (say, VMWare or KVM) on the fly as needed. So you would have a "pool" of servers. When load for one application rises, more servers for that application are taken from the pool and added to the mix as needed. When load drops, that instances are removed from the rotation handling that application and returned to the pool of free (virtual) servers. Providers of network gear have been working on applications that monitor the gear in the application delivery path (e.g. metrics on load balancers) and automatically deploy instances as needed to handle that application. This would be more of interest to providers of "bursty" applications where they might have high load sometimes but a relatively low "base" load. It could also be of interest to people who serve customers in different time zones, such as the US and Europe where the US application can be turned down at night and an application serving Europe loaded up during their business day. It could also be of interest for someone who is expecting a temporary "surge" of activity. It leads, though, to a completely different kind of attack called the "denial of sustainability" attack where a cloud-based provider is hit with a flood of "legitimate" transactions causing the "cloud" management to kick in more servers to handle the additional load. If that cloud is rented, a content provider could be hit with a huge bill. From owen at delong.com Mon Oct 18 10:17:17 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 08:17:17 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3328.7090205@unfix.org> References: <4CBC3328.7090205@unfix.org> Message-ID: <7FDFCCBA-762F-4074-B401-D05A17B8FB27@delong.com> Uh.... that would be 12 left -- 7 general distribution and 5 reserved for the global end allocation policy. That's 5%, not 5 /8s. Owen On Oct 18, 2010, at 4:44 AM, Jeroen Massar wrote: > APNIC just got another IPv4 /8 thus only 5 left: > > http://www.nro.net/media/remaining-ipv4-address-below-5.html > (And the spammers will take the rest...) > > So, if your company is not doing IPv6 yet, you really are really getting > late now. > > Greets, > Jeroen > > (PS: There seems to be a trend for people calling themselves"IPv6 > Pioneers" as they recently did something with IPv6, if you didn't play > in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years > late) From owen at delong.com Mon Oct 18 10:18:57 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 08:18:57 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3D59.3010401@xyonet.com> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> Message-ID: <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> On Oct 18, 2010, at 5:28 AM, Curtis Maurand wrote: > On 10/18/2010 8:16 AM, ML wrote: >> > And +1 on the "pioneers" comment too. >>> >>> Paul. >>> >> >> IPv6 Hipsters..Doing it before it was cool. >> >> >> > IPV4 ->easy(); > IPV6->really().Really().Difficult(); > Have you done IPv6? I have... It's not even difficult(), let alone really().Really().Difficult(). Owen From owen at delong.com Mon Oct 18 10:21:03 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 08:21:03 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <87k4lfekqn.fsf@oban.berlin.quux.de> Message-ID: <3918EDDB-41B6-4A08-A3B1-EF985BFDFA19@delong.com> If you aren't telling your existing vendors that you need IPv6 now, you need to be. If your vendors aren't getting the message, it's well past time to take action and start looking for other vendors. Owen On Oct 18, 2010, at 6:15 AM, Jeffrey Lyon wrote: > I'll listen, but I need my vendors, carriers, etc. to all get on board first. > > Jeff > > On Mon, Oct 18, 2010 at 5:11 PM, Jens Link wrote: >> Jeroen Massar writes: >> >>> So, if your company is not doing IPv6 yet, you really are really getting >>> late now. >> >> They won't listen. >> >> Jens >> -- >> ------------------------------------------------------------------------- >> | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | >> | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | >> ------------------------------------------------------------------------- >> >> > > > > -- > 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 jjn at nuge.com Mon Oct 18 10:37:29 2010 From: jjn at nuge.com (Jay Nugent) Date: Mon, 18 Oct 2010 11:37:29 -0400 (EDT) Subject: [Nanog] Re: 12 years ago today... In-Reply-To: <4CBC632E.5010309@godshell.com> Message-ID: Greetings, On Mon, 18 Oct 2010, Jason 'XenoPhage' Frisvold wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/18/2010 08:03 AM, Will Hargrave wrote: > > I can recommend "Where Wizards Stay Up Late" by Katie Hafner > > > > http://www.amazon.com/Where-Wizards-Stay-Up-Late/dp/0684832674 > > > > A really good read IMHO. > > An excellent read, highly recommended! Also check out Steven Levy's > Hackers. It goes a bit beyond the Internet, but the first part is > definitely relevant. > > I would love to see an actual documentary put together, though. Surely > there has to be footage out there of the early days. I have video footage of the ANS / NSFnet NOC in the days of the T1 and T3 NSFnet. Also have many early network maps of NSFnet. And stored away in my collection are 9 of the IBM RT's that were used in the T1 NSFnet, some still with their original software and configurations, along with all the Token Ring gear and cables. One of these RT's was the software development machine used by Merit to develop rcp-routed, with all the source code still on the hard drive. And hanging on my wall in my office is the backdrop used in a promotional video (when ANS was bidding for the T3-NSFnet grant). This consisted of a view of mostly the Northern hemisphere, with blinky lights, and arrows, and lines showing the first T3 link between Ann Arbor and Virginia(?). I know of one other ex-ANS employee who "collected" old hardware and documentation, as well. Guess we both figured it was something that shouldn't be lost to the dumpster... --- Jay Nugent +------------------------------------------------------------------------+ | Jay Nugent jjn at nuge.com (734)484-5105 (734)649-0850/Cell | | Nugent Telecommunications [www.nuge.com] | | Internet Consulting/Linux SysAdmin/Engineering & Design/ISP Reseller | | ISP Monitoring [www.ispmonitor.org] ISP & Modem Performance Monitoring | | Web-Pegasus [www.webpegasus.com] Web Hosting/DNS Hosting/Shell Accts| +------------------------------------------------------------------------+ 11:01am up 40 days, 19:11, 3 users, load average: 0.64, 0.20, 0.13 From hb-nanog at bsws.de Mon Oct 18 10:35:51 2010 From: hb-nanog at bsws.de (Henning Brauer) Date: Mon, 18 Oct 2010 17:35:51 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> Message-ID: <20101018153551.GA28093@nudo.bsws.de> * Owen DeLong [2010-10-18 17:27]: > Have you done IPv6? > I have... It's not even difficult(), let alone really().Really().Difficult(). maybe not from a users standpoint (that comes later when it misbehaves again). from an implementors (I have written a lot of kernel-side networking code and networking related daemons, including a full-blown bgpd, and that unfortunately included having to deal with v6) viewpoint - IPv6 is a desaster. Why people take up that crap is beyond me, instead of working on a viable alternative that doesn't suck. Which is certainly possible. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From jared at puck.nether.net Mon Oct 18 10:41:02 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 18 Oct 2010 11:41:02 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> Message-ID: Owen, He did not display the return values of these functions. I think his IPv6 one returns FALSE; - Jared On Oct 18, 2010, at 11:18 AM, Owen DeLong wrote: > > On Oct 18, 2010, at 5:28 AM, Curtis Maurand wrote: > >> On 10/18/2010 8:16 AM, ML wrote: >>>> And +1 on the "pioneers" comment too. >>>> >>>> Paul. >>>> >>> >>> IPv6 Hipsters..Doing it before it was cool. >>> >>> >>> >> IPV4 ->easy(); >> IPV6->really().Really().Difficult(); >> > Have you done IPv6? > > I have... It's not even difficult(), let alone really().Really().Difficult(). > > Owen > From jared at puck.nether.net Mon Oct 18 10:41:50 2010 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 18 Oct 2010 11:41:50 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101018153551.GA28093@nudo.bsws.de> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> Message-ID: <7552585D-C471-4EB5-9F57-363D09F2C6A5@puck.nether.net> On Oct 18, 2010, at 11:35 AM, Henning Brauer wrote: > * Owen DeLong [2010-10-18 17:27]: >> Have you done IPv6? >> I have... It's not even difficult(), let alone really().Really().Difficult(). > > maybe not from a users standpoint (that comes later when it misbehaves > again). from an implementors (I have written a lot of kernel-side > networking code and networking related daemons, including a full-blown > bgpd, and that unfortunately included having to deal with v6) > viewpoint - IPv6 is a desaster. Why people take up that crap is beyond > me, instead of working on a viable alternative that doesn't suck. > Which is certainly possible. Most of that junk can honestly be ignored. :) - Jared From gbonser at seven.com Mon Oct 18 10:47:06 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 18 Oct 2010 08:47:06 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101018153551.GA28093@nudo.bsws.de> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org><4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com><3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Henning Brauer > Sent: Monday, October 18, 2010 8:36 AM > To: nanog at nanog.org > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > instead of working on a viable alternative that doesn't suck. > Which is certainly possible. I would say that at this point it is too late to resist v6 deployment but it might be a good time to work on the "next thing" and use v6 as an example of how not to do it next time. It certainly is going to present some security challenges for some folks, particularly the ones that have been using dynamic nat pools to, in effect, block inbound connections. Firewall vendors are going to see a windfall from v6, I think. G From brandon.kim at brandontek.com Mon Oct 18 10:50:42 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Mon, 18 Oct 2010 11:50:42 -0400 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C35B@RWC-EX1.corp.seven.com> References: , <4CBC3BC9.7070803@foobar.org><4CBC560F.70708@foobar.org>, <4288131ED5E3024C9CD4782CECCAD2C70B9A2EB2@LMC-MAIL2.exempla.org> , <5A6D953473350C4B9995546AFE9939EE0B14C35B@RWC-EX1.corp.seven.com> Message-ID: George: Nice answer. Do you think cloud services is based on an oversubscription model? Where they hope those who purchase servers don't actually max them out memory/CPU wise? Do you also believer that cloud services should never have any downtime? To me, cloud services is synonymous with redundancy.... > Subject: RE: Pica8 - Open Source Cloud Switch > Date: Mon, 18 Oct 2010 08:17:09 -0700 > From: gbonser at seven.com > To: brandon.kim at brandontek.com > CC: nanog at nanog.org > > > -----Original Message----- > > From: Brandon Kim > > Sent: Monday, October 18, 2010 7:58 AM > > > > Cc: nanog at nanog.org > > Subject: RE: Pica8 - Open Source Cloud Switch > > > > > > Has our industry ever really fundamentally defined what is "cloud > > computing"????? > > > > Even though "MPLS" is sort of a buzzword too, we can define it, how it > > works, it's protocol and such... > > > > But cloud computing? > > My take on "cloud computing" is simply the provisioning servers or > virtual servers (say, VMWare or KVM) on the fly as needed. So you would > have a "pool" of servers. When load for one application rises, more > servers for that application are taken from the pool and added to the > mix as needed. > > When load drops, that instances are removed from the rotation handling > that application and returned to the pool of free (virtual) servers. > > Providers of network gear have been working on applications that monitor > the gear in the application delivery path (e.g. metrics on load > balancers) and automatically deploy instances as needed to handle that > application. This would be more of interest to providers of "bursty" > applications where they might have high load sometimes but a relatively > low "base" load. It could also be of interest to people who serve > customers in different time zones, such as the US and Europe where the > US application can be turned down at night and an application serving > Europe loaded up during their business day. > > It could also be of interest for someone who is expecting a temporary > "surge" of activity. It leads, though, to a completely different kind > of attack called the "denial of sustainability" attack where a > cloud-based provider is hit with a flood of "legitimate" transactions > causing the "cloud" management to kick in more servers to handle the > additional load. If that cloud is rented, a content provider could be > hit with a huge bill. > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Oct 18 10:57:37 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 19 Oct 2010 02:27:37 +1030 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <4CBC3BC9.7070803@foobar.org> References: <4CBC3BC9.7070803@foobar.org> Message-ID: <20101019022737.1fed70a6@opy.nosense.org> On Mon, 18 Oct 2010 13:21:29 +0100 Nick Hilliard wrote: > On 18/10/2010 12:25, Lin Pica8 wrote: > > We are starting to distribute Pica8 Open Source Cloud Switches : > > Sounds interesting. What chipset does this run on? > > Also, what's a cloud switch? Is this a switch which forwards L2 traffic, > or did I miss something? > "Cloud" is the new mainframe i.e. "it's running somewhere else ... " And the Emperor is naked ... ;-) From jamel at cin.ufpe.br Mon Oct 18 11:02:56 2010 From: jamel at cin.ufpe.br (Djamel Sadok) Date: Mon, 18 Oct 2010 13:02:56 -0300 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <4288131ED5E3024C9CD4782CECCAD2C70B9A2EB2@LMC-MAIL2.exempla.org> References: <4CBC3BC9.7070803@foobar.org> <4CBC560F.70708@foobar.org> <4288131ED5E3024C9CD4782CECCAD2C70B9A2EB2@LMC-MAIL2.exempla.org> Message-ID: How does it compare to the OpenFlow design ideas? Djamel On Mon, Oct 18, 2010 at 11:26 AM, Matlock, Kenneth L wrote: > Because 'cloud computing' is the latest buzzword, and their marketing > department thought that by attaching that buzzword to it, that would > increase sales? :) > > Nevermind that clouds contain nothing but vapor..... > > Ken Matlock > Network Analyst > Exempla Healthcare > (303) 467-4671 > matlockk at exempla.org > > > -----Original Message----- > From: Nick Hilliard [mailto:nick at foobar.org] > Sent: Monday, October 18, 2010 8:14 AM > To: Brandon Kim > Cc: nanog at nanog.org > Subject: Re: Pica8 - Open Source Cloud Switch > > On 18/10/2010 14:27, Brandon Kim wrote: > > Good question Nick, what is a cloud switch? Is this like VSS in cisco > > where you have a virtual chassis? > > The vss is virtual management software for a virtual switch. This box > looks like a piece of hardware that you can plug things into, so I'm > just > wondering what makes this a cloud switch and some other piece of kit not > a > cloud switch. > > Nick > > > From seph at directionless.org Mon Oct 18 11:03:16 2010 From: seph at directionless.org (seph) Date: Mon, 18 Oct 2010 12:03:16 -0400 Subject: Enterprise DNS providers In-Reply-To: (Jeffrey Lyon's message of "Mon, 18 Oct 2010 09:58:59 +0430") References: Message-ID: I haven't used UltraDNS, but given some of their unsavory sales tactics, I'm pretty biased against them. They spend awhile spamming people, and calling up CTOs. seph Jeffrey Lyon writes: > We're using Afilias now, we had nothing short of a horrendous > experience dealing with Neustar / UltraDNS and their uninformed, blood > hungry sales team. > > Best regards, Jeff > > > On Mon, Oct 18, 2010 at 9:23 AM, Jonas Bj?rklund wrote: >> >> On Sat, 16 Oct 2010, Ken Gilmour wrote: >> >>> Hello any weekend workers :) >>> >>> We are looking at urgently deploying an outsourced DNS provider for a >>> critical domain which is currently unavailable but are having some >>> difficulty. I've tried contacting UltraDNS who only allow customers from >>> US >>> / Canada to sign up (we are in Malta) and their Sales dept are closed, and >>> Easy DNS who don't have .com.mt as an option in the dropdown for >>> transferring domain names (and also support is closed). >> >> I have worked for one of the biggest poker networks and we used UltraDNS. >> The company was first operated from Sweden and later Austria. >> >> /Jonas >> >> > > > > -- > 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 joelja at bogus.com Mon Oct 18 11:09:23 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 18 Oct 2010 09:09:23 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101018153551.GA28093@nudo.bsws.de> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> Message-ID: <4CBC7133.6050807@bogus.com> On 10/18/10 8:35 AM, Henning Brauer wrote: > * Owen DeLong [2010-10-18 17:27]: >> Have you done IPv6? >> I have... It's not even difficult(), let alone really().Really().Difficult(). > > maybe not from a users standpoint (that comes later when it misbehaves > again). from an implementors (I have written a lot of kernel-side > networking code and networking related daemons, including a full-blown > bgpd, and that unfortunately included having to deal with v6) > viewpoint - IPv6 is a desaster. Why people take up that crap is beyond > me, instead of working on a viable alternative that doesn't suck. > Which is certainly possible. Wait, and OpenBSD developer that thinks everyone else's work is crap? Shocking... I encourage you to build and deploy your viable alternative... thanks joel From jgreco at ns.sol.net Mon Oct 18 11:20:00 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 18 Oct 2010 11:20:00 -0500 (CDT) Subject: Pica8 - Open Source Cloud Switch In-Reply-To: Message-ID: <201010181620.o9IGK09V098786@aurora.sol.net> > George: > > Nice answer. Do you think cloud services is based on an oversubscription mo= > del? > Where they hope those who purchase servers don't actually max them out memo= > ry/CPU wise? > > Do you also believer that cloud services should never have any downtime? To= > me=2C cloud services is synonymous with redundancy.... That's an interesting question, and really points more to the fact that "cloud" is rather poorly defined. For example, consider the T-Mobile Sidekick Danger server crash/disaster. This is frequently pointed to as a "failure of the cloud", but in reality, it appears to have been trusting data to a company that wasn't exercising proper care in maintaining its servers. People glommed onto the concept that it was a failure of the "cloud." However, one could argue that quite often, anytime something magically disappears into a part of the Internet we don't have physical control over... I've been toying with defining cloud in a different direction. We have dedicated servers. You get a 10 GHz 24-core CPU with 1TB of RAM. That's pretty clear and familiar to server geeks. We have virtual servers. You get (up to) M GHz and N cores of that same machine. Oversubscription is possible, but not required. In many cases, oversubscription is desirable because that's where the capex and opex savings of less hardware comes in. In both those cases, we get tied up in the specifics of hertz and cores and amount of memory. In the virtual server case, we make some progress towards a model where a VM could be migrated around onto more suitable hardware. This is useful for allowing the proper sizing of a virtual server, for redundancy, upgrades, etc. It seems, though, that ultimately what people seem to be thinking of when they think of the cloud, is the ability to just have stuff "run" without necessarily having to worry so much about the details. In some cases, they're looking for redundancy, or reliability. In many cases, they just want something to be out there without so much effort on their part. They want it to run fast if it gets busy, and don't care if the CPU is oversubscribed ... as long as they can get what they're paying for when they need it. I don't think cloud service purchasers will ultimately be that interested in worrying about whether they "max out" memory/CPU. I think they don't want to have to worry about it too much, though they probably want to be protected from bill shock. That means a model where their server might actually be hosted on a large host with a few hundred other mostly idle VM's, when their VM is idle, and then get migrated onto other hardware if demand spiked. We have technology that can even power on additional host hardware, so there are ways to save on power/cooling during non-peak times. I think you'd find such models are harder to implement if you're too focused on the "evil" of oversubscription. I think what you want to avoid are providers who are unable to maintain sufficient spare capacity to cope with peak demand. ... 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 tb at tburke.us Mon Oct 18 11:23:41 2010 From: tb at tburke.us (Tim Burke) Date: Mon, 18 Oct 2010 11:23:41 -0500 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3328.7090205@unfix.org> References: <4CBC3328.7090205@unfix.org> Message-ID: <88E0B7FF-45AF-4C66-90D6-0F4FBB604105@tburke.us> I'm wondering how long it'll be until HE starts spamming their IPv6 service... Tim Burke (815) 556-2000 Sent from my iPhone On Oct 18, 2010, at 6:44, Jeroen Massar wrote: > APNIC just got another IPv4 /8 thus only 5 left: > > http://www.nro.net/media/remaining-ipv4-address-below-5.html > (And the spammers will take the rest...) > > So, if your company is not doing IPv6 yet, you really are really getting > late now. > > Greets, > Jeroen > > (PS: There seems to be a trend for people calling themselves"IPv6 > Pioneers" as they recently did something with IPv6, if you didn't play > in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years > late) > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Oct 18 11:27:25 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 19 Oct 2010 02:57:25 +1030 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> Message-ID: <20101019025725.4070ac73@opy.nosense.org> On Mon, 18 Oct 2010 08:18:57 -0700 Owen DeLong wrote: > > On Oct 18, 2010, at 5:28 AM, Curtis Maurand wrote: > > > On 10/18/2010 8:16 AM, ML wrote: > >> > And +1 on the "pioneers" comment too. > >>> > >>> Paul. > >>> > >> > >> IPv6 Hipsters..Doing it before it was cool. > >> > >> > >> > > IPV4 ->easy(); > > IPV6->really().Really().Difficult(); > > > Have you done IPv6? > > I have... It's not even difficult(), let alone really().Really().Difficult(). > A lot of things are hard if you've never dealt with anything else. If, OTOH, you'd dealt with IPX or Appletalk before IPv4, then IPv4 was quite hard (why the complexity?! I do know now, but only after having looked into the history of IPv4 - it's a just series of neat hacks!) ... Regards, Mark. From owen at delong.com Mon Oct 18 11:25:22 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 09:25:22 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org><4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com><3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> Message-ID: On Oct 18, 2010, at 8:47 AM, George Bonser wrote: > > >> -----Original Message----- >> From: Henning Brauer >> Sent: Monday, October 18, 2010 8:36 AM >> To: nanog at nanog.org >> Subject: Re: Only 5x IPv4 /8 remaining at IANA >> >> instead of working on a viable alternative that doesn't suck. >> Which is certainly possible. > > I would say that at this point it is too late to resist v6 deployment > but it might be a good time to work on the "next thing" and use v6 as an > example of how not to do it next time. > > It certainly is going to present some security challenges for some > folks, particularly the ones that have been using dynamic nat pools to, > in effect, block inbound connections. Firewall vendors are going to see > a windfall from v6, I think. > > G Nobody is using dynamic nat pools to block inbound connections. Many people are using dynamic NAT on top of stateful inspection where stateful inspection blocks inbound connections. The good news is that stateful inspection doesn't go away in IPv6. It works just fine. All that goes away is the header mangling. It's really unfortunate that most people don't understand the distinction. If they did, it would help them to realize that NAT doesn't actually do anything for security, it just helps with address conservation (although it has some limits there, as well). IPv6 with SI is no less secure than IPv4 with SI+NAT. If you're worried about address and/or topological obfuscation, then, IPv6 offers you privacy addresses with rotating numbers. However, that's more a privacy issue than a security issue, unless you believe in the idea of security through obscurity which is pretty well proven false. Owen From alh-ietf at tndh.net Mon Oct 18 11:33:59 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 18 Oct 2010 09:33:59 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: , , , <20101017004041.7f19f304@opy.nosense.org>, , <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com>, Message-ID: <02dd01cb6ee2$5ac0a530$1041ef90$@net> This 'get a /32' BAD ADVICE has got to stop. There are way too many people trying to force fit their customers into a block that is intended for a start-up with ZERO customers. Develop a plan for /48 per customer, then go to ARIN and get that size block. Figure out exactly what you are going to assign to customers later, but don't tie your hands by asking for a block that is way too small to begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and if they got one either trade it in or put it in a lab and get a REAL block. Tony > -----Original Message----- > From: Brandon Kim [mailto:brandon.kim at brandontek.com] > Sent: Saturday, October 16, 2010 1:59 PM > To: nanog at nanog.org > Subject: RE: Definitive Guide to IPv6 adoption > > > Thanks everyone who responded. This list is such a valuable wealth of > information. > > Apparently I was wrong about the /64 as that should be /32 so thanks > for that correction.... > > Thanks again especially on a Saturday weekend! > > > > > From: rdobbins at arbor.net > > To: nanog at nanog.org > > Date: Sat, 16 Oct 2010 16:09:43 +0000 > > Subject: Re: Definitive Guide to IPv6 adoption > > > > > > On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: > > > > > Then move on to the Internet which as with most things is where the > most cuurent if not helpful information resides. > > > > > > Eric Vyncke's IPv6 security book is definitely worthwhile, as well, > in combination with Schudel & Smith's infrastructure security book (the > latter isn't IPv6-specific, but is the best book out there on > infrastructure security): > > > > > > > > > > > > --------------------------------------------------------------------- > -- > > Roland Dobbins // > > > > Sell your computer and buy a guitar. > > > > > > > > > > > = From alh-ietf at tndh.net Mon Oct 18 11:47:29 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 18 Oct 2010 09:47:29 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org><4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com><3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> Message-ID: <02e401cb6ee4$28fcdc10$7af69430$@net> Owen DeLong wrote: > ... > > It's really unfortunate that most people don't understand the > distinction. > If they did, it would help them to realize that NAT doesn't actually do > anything for security, it just helps with address conservation > (although > it has some limits there, as well). Actually nat does something for security, it decimates it. Any 'real' security system (physical, technology, ...) includes some form of audit trail. NAT explicitly breaks any form of audit trail, unless you are the one operating the header mangling device. Given that there is no limit to the number of nat devices along a path, there can be no limit to the number of people operating them. This means there is no audit trail, and therefore NO SECURITY. > > IPv6 with SI is no less secure than IPv4 with SI+NAT. If you're worried > about address and/or topological obfuscation, then, IPv6 offers you > privacy addresses with rotating numbers. However, that's more a > privacy issue than a security issue, unless you believe in the idea > of security through obscurity which is pretty well proven false. A different way to look at this is less about obscurity, and more about reducing your overall attack surface. A node using a temporal address is vulnerable while that address is live, but as soon as it is released that attack vector goes away. Attackers that harvest addresses through the variety of transactions that a node my conduct will have a limited period of time to try to exploit that. This is not to say that you don't want stateful controls, just that if something inside the stateful firewall has been compromised there will be a limited period of time to use the dated knowledge. Tony From rcarpen at network1.net Mon Oct 18 11:47:49 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 18 Oct 2010 12:47:49 -0400 (EDT) Subject: Definitive Guide to IPv6 adoption In-Reply-To: <02dd01cb6ee2$5ac0a530$1041ef90$@net> Message-ID: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> Unfortunately, it is not as easy as that in practice. I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > This 'get a /32' BAD ADVICE has got to stop. There are way too many > people > trying to force fit their customers into a block that is intended for > a > start-up with ZERO customers. > > Develop a plan for /48 per customer, then go to ARIN and get that size > block. Figure out exactly what you are going to assign to customers > later, > but don't tie your hands by asking for a block that is way too small > to > begin with. Any ISP with more than 30k customers SHOULD NOT have a > /32, and > if they got one either trade it in or put it in a lab and get a REAL > block. > > Tony > > > > -----Original Message----- > > From: Brandon Kim [mailto:brandon.kim at brandontek.com] > > Sent: Saturday, October 16, 2010 1:59 PM > > To: nanog at nanog.org > > Subject: RE: Definitive Guide to IPv6 adoption > > > > > > Thanks everyone who responded. This list is such a valuable wealth > > of > > information. > > > > Apparently I was wrong about the /64 as that should be /32 so thanks > > for that correction.... > > > > Thanks again especially on a Saturday weekend! > > > > > > > > > From: rdobbins at arbor.net > > > To: nanog at nanog.org > > > Date: Sat, 16 Oct 2010 16:09:43 +0000 > > > Subject: Re: Definitive Guide to IPv6 adoption > > > > > > > > > On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: > > > > > > > Then move on to the Internet which as with most things is where > > > > the > > most cuurent if not helpful information resides. > > > > > > > > > Eric Vyncke's IPv6 security book is definitely worthwhile, as > > > well, > > in combination with Schudel & Smith's infrastructure security book > > (the > > latter isn't IPv6-specific, but is the best book out there on > > infrastructure security): > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > -- > > > Roland Dobbins // > > > > > > > > > Sell your computer and buy a guitar. > > > > > > > > > > > > > > > > > = From owen at delong.com Mon Oct 18 11:45:06 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 09:45:06 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <02dd01cb6ee2$5ac0a530$1041ef90$@net> References: , , , <20101017004041.7f19f304@opy.nosense.org>, , <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com>, <02dd01cb6ee2$5ac0a530$1041ef90$@net> Message-ID: <119D2D29-21D6-497A-90F5-8A8FF24B6553@delong.com> On Oct 18, 2010, at 9:33 AM, Tony Hain wrote: > This 'get a /32' BAD ADVICE has got to stop. There are way too many people > trying to force fit their customers into a block that is intended for a > start-up with ZERO customers. > +1 > Develop a plan for /48 per customer, then go to ARIN and get that size > block. Figure out exactly what you are going to assign to customers later, More accurately... A /48 per customer end-site... > but don't tie your hands by asking for a block that is way too small to > begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and > if they got one either trade it in or put it in a lab and get a REAL block. > But otherwise, yes, Tony is right. Owen From joelja at bogus.com Mon Oct 18 11:53:02 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 18 Oct 2010 09:53:02 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <02dd01cb6ee2$5ac0a530$1041ef90$@net> References: , , , <20101017004041.7f19f304@opy.nosense.org>, , <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com>, <02dd01cb6ee2$5ac0a530$1041ef90$@net> Message-ID: <4CBC7B6E.6000409@bogus.com> On 10/18/10 9:33 AM, Tony Hain wrote: > This 'get a /32' BAD ADVICE has got to stop. There are way too many people > trying to force fit their customers into a block that is intended for a > start-up with ZERO customers. > > Develop a plan for /48 per customer, then go to ARIN and get that size > block. Develop a plan, consider the prior art, consider the possibly that you might deploy 6rd, consider what your peers are doing, consider the projections for your business. Go to arin with a request that meets your current and anticipated needs and that is defensible. don't decide without thinking it through that you're assigning a customer a /64 a /60 a /56 or even /48. this should be defensible as part of a business plan, otherwise what's the point? > Figure out exactly what you are going to assign to customers later, > but don't tie your hands by asking for a block that is way too small to > begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and > if they got one either trade it in or put it in a lab and get a REAL block. > > Tony > > >> -----Original Message----- >> From: Brandon Kim [mailto:brandon.kim at brandontek.com] >> Sent: Saturday, October 16, 2010 1:59 PM >> To: nanog at nanog.org >> Subject: RE: Definitive Guide to IPv6 adoption >> >> >> Thanks everyone who responded. This list is such a valuable wealth of >> information. >> >> Apparently I was wrong about the /64 as that should be /32 so thanks >> for that correction.... >> >> Thanks again especially on a Saturday weekend! >> >> >> >>> From: rdobbins at arbor.net >>> To: nanog at nanog.org >>> Date: Sat, 16 Oct 2010 16:09:43 +0000 >>> Subject: Re: Definitive Guide to IPv6 adoption >>> >>> >>> On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: >>> >>>> Then move on to the Internet which as with most things is where the >> most cuurent if not helpful information resides. >>> >>> >>> Eric Vyncke's IPv6 security book is definitely worthwhile, as well, >> in combination with Schudel & Smith's infrastructure security book (the >> latter isn't IPv6-specific, but is the best book out there on >> infrastructure security): >>> >>> >>> >>> >>> >>> --------------------------------------------------------------------- >> -- >>> Roland Dobbins // >>> >>> Sell your computer and buy a guitar. >>> >>> >>> >>> >>> >> = > > From jbates at brightok.net Mon Oct 18 11:59:05 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 18 Oct 2010 11:59:05 -0500 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> Message-ID: <4CBC7CD9.8050506@brightok.net> On 10/18/2010 11:47 AM, Randy Carpenter wrote: > > Unfortunately, it is not as easy as that in practice. > > I recently worked with a customer that has ~60,000 customers > currently. We tried to get a larger block, but were denied. ARIN said > they would only issue a /32, unless immediate usage could be shown > that required more than that. Their guidelines also state /56 for > end-users. I am a big proponent of nibble boundaries, too. I think if > you are too big to use only a /32, you should get a /28, /24, and so > forth. It would make routing so much nicer to deal with. /31 and > such is just nasty. > > ARIN does reservations (unsure at what length, but at least down to /31). If you were to fill the /32 quickly, you could easily request the next block. To my knowledge, they've only handed out 1 or 2 networks shorter than /32. Correct me if I'm wrong, but isn't 60,000 customers at /56 2^24 assignments from a /32? Seems plenty. Even at /48 assignments, you'd get 65,536 assignments. So how can you justify more than a /32? Jack From jf at probe-networks.de Mon Oct 18 12:03:06 2010 From: jf at probe-networks.de (Jonas Frey (Probe Networks)) Date: Mon, 18 Oct 2010 19:03:06 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <26885469.843.1287408149659.JavaMail.franck@franck-martins-macbook-pro.local> <5B8DFF38-7325-491C-93DA-FFC5BFFF6FEF@ianai.net> Message-ID: <1287421386.15871.35.camel@wks02> How do you want to do that without IPv6 connectivity? :-) -Jonas Am Montag, den 18.10.2010, 18:42 +0430 schrieb Jeffrey Lyon: > Only if you're prepared for the bloody onslaught of DDoS. > > Jeff > > On Mon, Oct 18, 2010 at 6:27 PM, Patrick W. Gilmore wrote: > > On Oct 18, 2010, at 9:39 AM, Jeffrey Lyon wrote: > > > >> My clients can't use IPv6 when my infrastructure and carriers don't support it. > > > > Smells like a business opportunity to steal your customers. > > > > Thanx! > > > > -- > > TTFN, > > patrick > > > > > >> On Mon, Oct 18, 2010 at 5:52 PM, Franck Martin wrote: > >>> Nah... > >>> > >>> Get IPv6 for your clients today, think about your servers for later... > >>> > >>> Then you will be able to ask all the right questions and apply the right pressure to your vendors, carriers, etc.... > >>> > >>> ----- Original Message ----- > >>> From: "Jeffrey Lyon" > >>> To: "Jens Link" > >>> Cc: nanog at nanog.org > >>> Sent: Tuesday, 19 October, 2010 1:15:16 AM > >>> Subject: Re: Only 5x IPv4 /8 remaining at IANA > >>> > >>> I'll listen, but I need my vendors, carriers, etc. to all get on board first. > >>> > >>> Jeff > >>> > >>> On Mon, Oct 18, 2010 at 5:11 PM, Jens Link wrote: > >>>> Jeroen Massar writes: > >>>> > >>>>> So, if your company is not doing IPv6 yet, you really are really getting > >>>>> late now. > >>>> > >>>> They won't listen. > >>> > >> > >> > >> > >> -- > >> Jeffrey Lyon, Leadership Team > >> jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > >> Black Lotus Communications - AS32421 > >> First and Leading in DDoS Protection Solutions > >> > > > > > > > > > -------------- 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 jbates at brightok.net Mon Oct 18 12:10:19 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 18 Oct 2010 12:10:19 -0500 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <119D2D29-21D6-497A-90F5-8A8FF24B6553@delong.com> References: , , , <20101017004041.7f19f304@opy.nosense.org>, , <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com>, <02dd01cb6ee2$5ac0a530$1041ef90$@net> <119D2D29-21D6-497A-90F5-8A8FF24B6553@delong.com> Message-ID: <4CBC7F7B.8050600@brightok.net> On 10/18/2010 11:45 AM, Owen DeLong wrote: > > More accurately... A /48 per customer end-site... > Define end0-site. Residential customers, for example, don't need more than a /56. More would just be obscene. Most small businesses don't need more than a /56 either, especially if you are breaking them up into different sites (versus assigning a /48 to customer and dividing that block up to different sites). Jack From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Oct 18 12:15:03 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 19 Oct 2010 03:45:03 +1030 Subject: 12 years ago today... In-Reply-To: <4CBC37AA.4020809@harg.net> References: <0F4B164E-1CBD-4193-AE15-177E8B35C723@centergate.com> <3998D283-D969-4176-985F-869D09F04D57@gmail.com> <4CBC37AA.4020809@harg.net> Message-ID: <20101019034503.40603af9@opy.nosense.org> On Mon, 18 Oct 2010 13:03:54 +0100 Will Hargrave wrote: > On 16/10/10 10:02, Warren Bailey wrote: > > > While we are on the subject of "the godfathers of the Internet", when is a > > documentary coming out that tells the story? There was a really long > > documentary done on the BBS, surely someone (myself included) would find it > > interesting. > > I can recommend "Where Wizards Stay Up Late" by Katie Hafner > > http://www.amazon.com/Where-Wizards-Stay-Up-Late/dp/0684832674 > > A really good read IMHO. > As is RFC2468 (Who do we appreciate!) - "I REMEMBER IANA" > Will > From dmm at 1-4-5.net Mon Oct 18 12:16:35 2010 From: dmm at 1-4-5.net (David Meyer) Date: Mon, 18 Oct 2010 10:16:35 -0700 Subject: [NANOG-announce] NANOG 51 Call For Presentations now open Message-ID: Folks, Please take a look at the NANOG 51 Call For Presentations ( http://nanog.org/meetings/nanog51/callforpresent.php): he North American Network Operators' Group (NANOG) will hold its 51st meeting in Miami on January 30 to February 2, 2011. NANOG51will be hosted by Terremark . The NANOG Program Committee is now seeking proposals for presentations, panels, tutorials, tracks sessions, and keynote materials for the NANOG51 program. We invite presentations highlighting issues relating to technology already deployed or soon-to-be deployed in the Internet. Vendors are encouraged to work with operators to present real-world deployment experiences with the vendor's products and interoperability. NANOG51 submissions are welcome at http://pc.nanog.org. Acceptance notifications for NANOG51 will be sent by the Program Committee starting December 9, 2010, and will continue through January 13, 2011. Time to start thinking about the talk(s) you want to give in Miami! Thanks, Dave -------------- next part -------------- _______________________________________________ NANOG-announce mailing list NANOG-announce at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog-announce From joelja at bogus.com Mon Oct 18 12:25:10 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 18 Oct 2010 10:25:10 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBC7F7B.8050600@brightok.net> References: , , , <20101017004041.7f19f304@opy.nosense.org>, , <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com>, <02dd01cb6ee2$5ac0a530$1041ef90$@net> <119D2D29-21D6-497A-90F5-8A8FF24B6553@delong.com> <4CBC7F7B.8050600@brightok.net> Message-ID: <4CBC82F6.4060703@bogus.com> On 10/18/10 10:10 AM, Jack Bates wrote: > On 10/18/2010 11:45 AM, Owen DeLong wrote: >> >> More accurately... A /48 per customer end-site... >> > > Define end0-site. Residential customers, for example, don't need more > than a /56. This is a matter of opinion not gospel. larger, this size, or smaller needs to be justified by your deployment plan. > More would just be obscene. Most small businesses don't need > more than a /56 either, especially if you are breaking them up into > different sites (versus assigning a /48 to customer and dividing that > block up to different sites). business customers can and will do whatever is necessary to support their model. I have sought and received a /43 direct assignment for a business will multiple sites. I have no trouble imagining that my upstreams would accommodate requests for PA /48s for each location as well. joel > > Jack > From brandon.galbraith at gmail.com Mon Oct 18 12:30:12 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Mon, 18 Oct 2010 12:30:12 -0500 Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: Working with a previous client about 1.5 years ago, we asked Dyn and UltraDNS to send proposals over. UltraDNS was 3x the Dyn quote, and we were satisfied from personal experience with Dyn before. When I explained to the UltraDNS rep why we went with Dyn, they said "Oh, I thought you were looking for an enterprise provide". Another vendor I don't plan on ever using (or even considering) again. On Mon, Oct 18, 2010 at 11:03 AM, seph wrote: > I haven't used UltraDNS, but given some of their unsavory sales tactics, > I'm pretty biased against them. They spend awhile spamming people, and > calling up CTOs. > > seph > > Jeffrey Lyon writes: > > > We're using Afilias now, we had nothing short of a horrendous > > experience dealing with Neustar / UltraDNS and their uninformed, blood > > hungry sales team. > > > > Best regards, Jeff > > > > > > On Mon, Oct 18, 2010 at 9:23 AM, Jonas Bj?rklund > wrote: > >> > >> On Sat, 16 Oct 2010, Ken Gilmour wrote: > >> > >>> Hello any weekend workers :) > >>> > >>> We are looking at urgently deploying an outsourced DNS provider for a > >>> critical domain which is currently unavailable but are having some > >>> difficulty. I've tried contacting UltraDNS who only allow customers > from > >>> US > >>> / Canada to sign up (we are in Malta) and their Sales dept are closed, > and > >>> Easy DNS who don't have .com.mt as an option in the dropdown for > >>> transferring domain names (and also support is closed). > >> > >> I have worked for one of the biggest poker networks and we used > UltraDNS. > >> The company was first operated from Sweden and later Austria. > >> > >> /Jonas > >> > >> > > > > > > > > -- > > Jeffrey Lyon, Leadership Team > > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net > > Black Lotus Communications - AS32421 > > First and Leading in DDoS Protection Solutions > > -- Brandon Galbraith US Voice: 630.492.0464 From bzs at world.std.com Mon Oct 18 12:27:23 2010 From: bzs at world.std.com (Barry Shein) Date: Mon, 18 Oct 2010 13:27:23 -0400 Subject: network name 101100010100110.net In-Reply-To: References: <20101018024021.GC8924@vacation.karoshi.com.> <20101018031853.51F0F5C3EF5@drugs.dv.isc.org> Message-ID: <19644.33659.845227.66898@world.std.com> On October 17, 2010 at 20:24 joe at nethead.com (Joe Hamelin) wrote: > That's why 3M registered mmm.com back in 1988. When BU joined the internet and promptly brought down about a third of it with their host table entries one of the problems was a host named 3b (.bu.edu, it was an AT&T 3B5) which caused a 4bsd script to go into an infinite loop filling roots (/tmp) which back then crashed systems. Also, one-letter hostnames (a.bu.edu as an alias for bucsa.bu.edu, etc.) I know because basically it was my fault. -- -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 beckman at angryox.com Mon Oct 18 12:43:04 2010 From: beckman at angryox.com (Peter Beckman) Date: Mon, 18 Oct 2010 13:43:04 -0400 Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: On Sat, 16 Oct 2010, Ken Gilmour wrote: > We are looking at urgently deploying an outsourced DNS provider for a > critical domain which is currently unavailable but are having some > difficulty. I've tried contacting UltraDNS who only allow customers from US > / Canada to sign up (we are in Malta) and their Sales dept are closed, and > Easy DNS who don't have .com.mt as an option in the dropdown for > transferring domain names (and also support is closed). Just throwing my hat in the ring. DNSmadeEasy has handled my DNS traffic, both personal and professional, for several years with an uptime of 99.9999%* over 8 years of service (I've been with them for at least 4). Very honest, very responsive, great service, and very good pricing for an Enterprise Anycasted DNS network. Beckman * They were DDOSed recently with an enormous amount of traffic. First outage in their 8 year history. www.dnsmadeeasy.com --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From gbonser at seven.com Mon Oct 18 12:52:18 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 18 Oct 2010 10:52:18 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org><4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com><3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Monday, October 18, 2010 9:25 AM > To: George Bonser > Cc: Henning Brauer; nanog at nanog.org > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > > > Nobody is using dynamic nat pools to block inbound connections. > > Many people are using dynamic NAT on top of stateful inspection where > stateful inspection blocks inbound connections. > > The good news is that stateful inspection doesn't go away in IPv6. It > works > just fine. All that goes away is the header mangling. Exactly true but there are people out there who experience it as "dynamic nat prevents inbound connections". And the extent to which state is inspected varies widely on different gear (is it just looking for an ACK flag to determine an "established" connection or is it making sure that at least one packet has gone in the other direction first?). At least with dynamic (overload) NAT, a packet had to travel in the opposite (outbound) direction in order to establish the NAT in the first place. Then with an "established" acl, the two things give you fairly decent assurance that things went as planned but are still not a substitute for packet inspection. > It's really unfortunate that most people don't understand the > distinction. Concur. > > IPv6 with SI is no less secure than IPv4 with SI+NAT. Yup, the difference is going to be the extent to which the state is inspected in various gear. Again, I believe firewall vendors are going to see a windfall here. And to address your comment in an email subsequent to this one about accounting, I wholeheartedly agree. NAT can make it much more difficult to find what is causing a problem or even who is talking to whom. From clapidus at gmail.com Mon Oct 18 12:57:37 2010 From: clapidus at gmail.com (Claudio Lapidus) Date: Mon, 18 Oct 2010 14:57:37 -0300 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: Day, > does anyone see any issues with this? Please, I strongly urge you to consider the ergonomics in question. That name is REALLY hard to read, spell, pronounce, type, recognize, etc. Agreed that there are no technical roadblocks, but again, please use common sense and choose something that doesn't make everybody's life more complicated. A domain name is something that sticks for many years and is of daily use in many many areas, and even more when it is for designating a transit ISP. my 2 cents, cl. From darren at bolding.org Mon Oct 18 13:03:49 2010 From: darren at bolding.org (Darren Bolding) Date: Mon, 18 Oct 2010 11:03:49 -0700 Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: I have been quite happy with Dynect so far. They were very flexbile on a number of items and the service has been great. On Mon, Oct 18, 2010 at 12:13 AM, Shacolby Jackson < shacolby at bluejeansnet.com> wrote: > I have used UltraDNS before. They are decent. I am however evaluating > Dynect > (www.dyn.com) who are very popular with social media companies like > Twitter. > > > On Sun, Oct 17, 2010 at 11:17 PM, Ken Gilmour > wrote: > > > On 18 October 2010 06:53, Jonas Bj?rklund wrote: > > > > > > > > I have worked for one of the biggest poker networks and we used > UltraDNS. > > > The company was first operated from Sweden and later Austria. > > > > > > /Jonas > > > > > > > I would tend to agree... I have also used UltraDNS in the past for other > > companies, however we needed them urgently and someone else responded > > faster > > and they seem to be doing a good job so far. > > > > Regards, > > > > Ken > > > -- -- Darren Bolding -- -- darren at bolding.org -- From owen at delong.com Mon Oct 18 13:03:46 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 11:03:46 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> Message-ID: On Oct 18, 2010, at 9:47 AM, Randy Carpenter wrote: > > Unfortunately, it is not as easy as that in practice. > > I recently worked with a customer that has ~60,000 customers currently. We tried to get a larger block, but were denied. ARIN said they would only issue a /32, unless immediate usage could be shown that required more than that. Their guidelines also state /56 for end-users. I am a big proponent of nibble boundaries, too. I think if you are too big to use only a /32, you should get a /28, /24, and so forth. It would make routing so much nicer to deal with. /31 and such is just nasty. > ARIN policy allows for a /48 per end user. There are guidelines included in the policy that allow for a /56 per end-user, but, they are explicitly called out as just guidelines, not policy. I am working on changing the ARIN policy (I've currently circulated a draft to some co-authors and expect to be posting it to policy at arin.net and ppml at arin.net within the next couple of weeks) along the lines you mention. I think that IPv4think is a largely temporary problem, but, it is a problem even at the RIRs. Owen > > -Randy > > -- > | Randy Carpenter > | Vice President, IT Services > | Red Hat Certified Engineer > | First Network Group, Inc. > | (419)739-9240, x1 > ---- > > ----- Original Message ----- >> This 'get a /32' BAD ADVICE has got to stop. There are way too many >> people >> trying to force fit their customers into a block that is intended for >> a >> start-up with ZERO customers. >> >> Develop a plan for /48 per customer, then go to ARIN and get that size >> block. Figure out exactly what you are going to assign to customers >> later, >> but don't tie your hands by asking for a block that is way too small >> to >> begin with. Any ISP with more than 30k customers SHOULD NOT have a >> /32, and >> if they got one either trade it in or put it in a lab and get a REAL >> block. >> >> Tony >> >> >>> -----Original Message----- >>> From: Brandon Kim [mailto:brandon.kim at brandontek.com] >>> Sent: Saturday, October 16, 2010 1:59 PM >>> To: nanog at nanog.org >>> Subject: RE: Definitive Guide to IPv6 adoption >>> >>> >>> Thanks everyone who responded. This list is such a valuable wealth >>> of >>> information. >>> >>> Apparently I was wrong about the /64 as that should be /32 so thanks >>> for that correction.... >>> >>> Thanks again especially on a Saturday weekend! >>> >>> >>> >>>> From: rdobbins at arbor.net >>>> To: nanog at nanog.org >>>> Date: Sat, 16 Oct 2010 16:09:43 +0000 >>>> Subject: Re: Definitive Guide to IPv6 adoption >>>> >>>> >>>> On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: >>>> >>>>> Then move on to the Internet which as with most things is where >>>>> the >>> most cuurent if not helpful information resides. >>>> >>>> >>>> Eric Vyncke's IPv6 security book is definitely worthwhile, as >>>> well, >>> in combination with Schudel & Smith's infrastructure security book >>> (the >>> latter isn't IPv6-specific, but is the best book out there on >>> infrastructure security): >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>> -- >>>> Roland Dobbins // >>>> >>>> >>>> Sell your computer and buy a guitar. >>>> >>>> >>>> >>>> >>>> >>> = From owen at delong.com Mon Oct 18 13:07:43 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 11:07:43 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBC7CD9.8050506@brightok.net> References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> Message-ID: <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> On Oct 18, 2010, at 9:59 AM, Jack Bates wrote: > > > On 10/18/2010 11:47 AM, Randy Carpenter wrote: >> >> Unfortunately, it is not as easy as that in practice. >> >> I recently worked with a customer that has ~60,000 customers >> currently. We tried to get a larger block, but were denied. ARIN said >> they would only issue a /32, unless immediate usage could be shown >> that required more than that. Their guidelines also state /56 for >> end-users. I am a big proponent of nibble boundaries, too. I think if >> you are too big to use only a /32, you should get a /28, /24, and so >> forth. It would make routing so much nicer to deal with. /31 and >> such is just nasty. >> >> > > ARIN does reservations (unsure at what length, but at least down to /31). If you were to fill the /32 quickly, you could easily request the next block. To my knowledge, they've only handed out 1 or 2 networks shorter than /32. > Not any more... ARIN now uses allocation by bisection. > Correct me if I'm wrong, but isn't 60,000 customers at /56 2^24 assignments from a /32? Seems plenty. Even at /48 assignments, you'd get 65,536 assignments. So how can you justify more than a /32? > The customers should get /48s. The /56 guideline is merely that and only for the smallest of sites. It's also subsequently turned out to be bad advice. 60,000 customers may well be more than 65,536 end sites. Also, you need to leave room for numbering infrastructure, sizing POPs to prefixes, etc. It's much more complex than just number of customers = number of /48s. Unfortunately, current policy doesn't recognize that other than HD ratio. However, 60,000 customers each with a /48 would far exceed the .94 HD ratio requirement for larger than a /32. IIRC, under current policy it would justify a /30 or possibly a /29. Owen From owen at delong.com Mon Oct 18 13:05:26 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 11:05:26 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBC7B6E.6000409@bogus.com> References: , , , <20101017004041.7f19f304@opy.nosense.org>, , <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com>, <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> Message-ID: On Oct 18, 2010, at 9:53 AM, Joel Jaeggli wrote: > On 10/18/10 9:33 AM, Tony Hain wrote: >> This 'get a /32' BAD ADVICE has got to stop. There are way too many people >> trying to force fit their customers into a block that is intended for a >> start-up with ZERO customers. >> >> Develop a plan for /48 per customer, then go to ARIN and get that size >> block. > > Develop a plan, consider the prior art, consider the possibly that you > might deploy 6rd, consider what your peers are doing, consider the > projections for your business. Go to arin with a request that meets your > current and anticipated needs and that is defensible. > > don't decide without thinking it through that you're assigning a > customer a /64 a /60 a /56 or even /48. this should be defensible as > part of a business plan, otherwise what's the point? > A /48 is defensible. It's the architecturally intended end-site configuration, it is allowed by policy, and, it is a reasonable starting point. There is no real reason to assign less than a /48 to any end-site other than hyper- conservatism due to IPv4-think. Owen >> Figure out exactly what you are going to assign to customers later, >> but don't tie your hands by asking for a block that is way too small to >> begin with. Any ISP with more than 30k customers SHOULD NOT have a /32, and >> if they got one either trade it in or put it in a lab and get a REAL block. >> >> Tony >> >> >>> -----Original Message----- >>> From: Brandon Kim [mailto:brandon.kim at brandontek.com] >>> Sent: Saturday, October 16, 2010 1:59 PM >>> To: nanog at nanog.org >>> Subject: RE: Definitive Guide to IPv6 adoption >>> >>> >>> Thanks everyone who responded. This list is such a valuable wealth of >>> information. >>> >>> Apparently I was wrong about the /64 as that should be /32 so thanks >>> for that correction.... >>> >>> Thanks again especially on a Saturday weekend! >>> >>> >>> >>>> From: rdobbins at arbor.net >>>> To: nanog at nanog.org >>>> Date: Sat, 16 Oct 2010 16:09:43 +0000 >>>> Subject: Re: Definitive Guide to IPv6 adoption >>>> >>>> >>>> On Oct 16, 2010, at 10:56 PM, Joel Jaeggli wrote: >>>> >>>>> Then move on to the Internet which as with most things is where the >>> most cuurent if not helpful information resides. >>>> >>>> >>>> Eric Vyncke's IPv6 security book is definitely worthwhile, as well, >>> in combination with Schudel & Smith's infrastructure security book (the >>> latter isn't IPv6-specific, but is the best book out there on >>> infrastructure security): >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>> -- >>>> Roland Dobbins // >>>> >>>> Sell your computer and buy a guitar. >>>> >>>> >>>> >>>> >>>> >>> = >> >> > From owen at delong.com Mon Oct 18 13:09:43 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 11:09:43 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBC7F7B.8050600@brightok.net> References: , , , <20101017004041.7f19f304@opy.nosense.org>, , <1D9EE9A2-551C-4576-9995-A983307D3DD5@bogus.com>, <02dd01cb6ee2$5ac0a530$1041ef90$@net> <119D2D29-21D6-497A-90F5-8A8FF24B6553@delong.com> <4CBC7F7B.8050600@brightok.net> Message-ID: On Oct 18, 2010, at 10:10 AM, Jack Bates wrote: > On 10/18/2010 11:45 AM, Owen DeLong wrote: >> >> More accurately... A /48 per customer end-site... >> > > Define end0-site. Residential customers, for example, don't need more than a /56. More would just be obscene. Most small businesses don't need more than a /56 either, especially if you are breaking them up into different sites (versus assigning a /48 to customer and dividing that block up to different sites). > > You are wrong. Residential customers should get /48s. /56s seemed like a good idea at the time, but, they aren't. It's not just about counting subnets. There's also the issue of needing bits for self-defining hierarchical topologies. 8 bits isn't enough for that. 16 is. Seriously... This isn't IPv4. The scarcity mentality is causing harm and driving decisions that will have a limiting effect on innovation that is already in progress. Owen From drc at virtualized.org Mon Oct 18 13:18:26 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 18 Oct 2010 08:18:26 -1000 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBC7CD9.8050506@brightok.net> References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> Message-ID: <8453F6E1-9632-4740-9AC4-68522EDE86B0@virtualized.org> On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: > ARIN does reservations (unsure at what length, but at least down to /31). Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... Regards, -drc From jlewis at lewis.org Mon Oct 18 13:18:55 2010 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 18 Oct 2010 14:18:55 -0400 (EDT) Subject: Definitive Guide to IPv6 adoption In-Reply-To: <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> Message-ID: On Mon, 18 Oct 2010, Owen DeLong wrote: > The customers should get /48s. The /56 guideline is merely that and only > for the smallest of sites. It's also subsequently turned out to be bad > advice. Can you elaborate on why /56 is "bad advice" and if you're saying it only for this case or if you're saying assignment of /56 to any customers is a bad idea? Dealing with a data center where customer machines typically get by today with a /29 of IPv4, is a /56 really not enough for their forseeable future? I realize our /32 could support more customers than we're likely to fit in the data center at /48 per customer, but is that enough of a reason to assign 65k /64 subnets to each customer machine? ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From hb-nanog at bsws.de Mon Oct 18 13:19:04 2010 From: hb-nanog at bsws.de (Henning Brauer) Date: Mon, 18 Oct 2010 20:19:04 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> Message-ID: <20101018181904.GE28093@nudo.bsws.de> * Owen DeLong [2010-10-18 18:29]: > The good news is that stateful inspection doesn't go away in IPv6. that is right. > It works just fine. All that goes away is the header mangling. that is partially true. it can work just fine, but all the bloat in v6 makes it way harder to implement the state tracking than it should be. > It's really unfortunate that most people don't understand the distinction. > If they did, it would help them to realize that NAT doesn't actually do > anything for security, it just helps with address conservation (although > it has some limits there, as well). right. > IPv6 with SI is no less secure than IPv4 with SI+NAT. well, it is. the extension headers are horrible. the v4 mapping horror is an insane trap, too. link-local is the most horrid concept ever. all hail 160 bit addresses. all that leads to bugs in the implementations (while the bugs are really in the specification, I'd claim). the RH0 desaster was just the beginning. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From owen at delong.com Mon Oct 18 13:16:30 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 11:16:30 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org><4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com><3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> Message-ID: <37C8B453-0361-43E6-9001-861CD51FB196@delong.com> On Oct 18, 2010, at 10:52 AM, George Bonser wrote: > > >> -----Original Message----- >> From: Owen DeLong [mailto:owen at delong.com] >> Sent: Monday, October 18, 2010 9:25 AM >> To: George Bonser >> Cc: Henning Brauer; nanog at nanog.org >> Subject: Re: Only 5x IPv4 /8 remaining at IANA >> >> >> >> Nobody is using dynamic nat pools to block inbound connections. >> >> Many people are using dynamic NAT on top of stateful inspection where >> stateful inspection blocks inbound connections. >> >> The good news is that stateful inspection doesn't go away in IPv6. It >> works >> just fine. All that goes away is the header mangling. > > Exactly true but there are people out there who experience it as > "dynamic nat prevents inbound connections". And the extent to which > state is inspected varies widely on different gear (is it just looking > for an ACK flag to determine an "established" connection or is it making > sure that at least one packet has gone in the other direction first?). Looking for an ACK flag isn't Stateful inspection. Stateful inspection involves comparison against a state table of known connections. People perceive many things that are combined as having the systemic effect without understanding which component actually performs which underlying function. In cases where that doesn't matter, it's not an issue. In IPv4, it didn't matter if people understood the difference between security provided by stateful inspection and security eliminated by NAT. Now, it matters because some people are claiming IPv6 is less secure as a result of the lack of NAT. This claim comes from the misunderstanding you have restated above. > At least with dynamic (overload) NAT, a packet had to travel in the > opposite (outbound) direction in order to establish the NAT in the first > place. Then with an "established" acl, the two things give you fairly This is true of stateful inspection as well. Stateful inspection != static packet filters. It's not the same thing. The ACK flag test you describe above is a static packet filter, not stateful inspection. > decent assurance that things went as planned but are still not a > substitute for packet inspection. > Again, this doesn't come form the overloaded NAT. It comes from the state table mechanism and the comparison of the packet against known flows in the state table. While NAT requires this underlying state table to function, there is nothing preventing implementation of that state table without NAT. Such an implementation is equally secure without NAT. In fact, it's slightly better because NAT destroys audit trail while SI without NAT does not. >> It's really unfortunate that most people don't understand the >> distinction. > > Concur. > >> >> IPv6 with SI is no less secure than IPv4 with SI+NAT. > > Yup, the difference is going to be the extent to which the state is > inspected in various gear. Again, I believe firewall vendors are going > to see a windfall here. > You are confusing SI with Packet Filters. The technologies are different and it is, also, important to understand this distinction as well. > And to address your comment in an email subsequent to this one about > accounting, I wholeheartedly agree. NAT can make it much more difficult > to find what is causing a problem or even who is talking to whom. Actually, that was Tony Hain's comment, but, yes, he's correct. Owen From sthaug at nethelp.no Mon Oct 18 13:20:20 2010 From: sthaug at nethelp.no (sthaug at nethelp.no) Date: Mon, 18 Oct 2010 20:20:20 +0200 (CEST) Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> Message-ID: <20101018.202020.41637336.sthaug@nethelp.no> > > don't decide without thinking it through that you're assigning a > > customer a /64 a /60 a /56 or even /48. this should be defensible as > > part of a business plan, otherwise what's the point? > > > A /48 is defensible. It's the architecturally intended end-site configuration, > it is allowed by policy, and, it is a reasonable starting point. There is no > real reason to assign less than a /48 to any end-site other than hyper- > conservatism due to IPv4-think. I still haven't seen any good argument for why residential users need /48s. No, I don't think "that makes all the address assignments the same size" is a particularly relevant or convincing argument. We're doing /56 for residential users, and have no plans to change this. Steinar Haug, Nethelp consulting, sthaug at nethelp.no From jfbeam at gmail.com Mon Oct 18 13:25:16 2010 From: jfbeam at gmail.com (Ricky Beam) Date: Mon, 18 Oct 2010 14:25:16 -0400 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <20101018123046.GU10815@nudo.bsws.de> References: <20101018123046.GU10815@nudo.bsws.de> Message-ID: On Mon, 18 Oct 2010 08:30:48 -0400, Henning Brauer wrote: > "Currently, the Pica8 driver is released in binary form" > > none of the interesting low-level drivers is open. none. zero. If it's based on a Broadcom chip, trust me, they are doing the world a favor by not exposing you to the SoC SDK. (It's so horribly un-documented that it took a week to figure out how to build it and another two weeks to actually get it to build something that could be used.) From bygg at cafax.se Mon Oct 18 20:26:20 2010 From: bygg at cafax.se (Johnny Eriksson) Date: Mon, 18 Oct 2010 20:26:20 WET DST Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: Your message of Mon, 18 Oct 2010 09:47:29 -0700 Message-ID: "Tony Hain" wrote: > Actually nat does something for security, it decimates it. Any 'real' > security system (physical, technology, ...) includes some form of audit > trail. NAT explicitly breaks any form of audit trail, unless you are the one > operating the header mangling device. Given that there is no limit to the > number of nat devices along a path, there can be no limit to the number of > people operating them. This means there is no audit trail, and therefore NO > SECURITY. So an audit trail implies security? I don't agree. It may make post-mortem analysis easier, thou. Does end-to-end crypto break security? Which security? The security of the endpoints or the security of someone else who cannot now audit the communication in question fully? > Tony --Johnny From sethm at rollernet.us Mon Oct 18 13:30:28 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 18 Oct 2010 11:30:28 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101018181904.GE28093@nudo.bsws.de> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <20101018181904.GE28093@nudo.bsws.de> Message-ID: <4CBC9244.1060402@rollernet.us> On 10/18/2010 11:19, Henning Brauer wrote: > * Owen DeLong [2010-10-18 18:29]: >> The good news is that stateful inspection doesn't go away in IPv6. > > that is right. > >> It works just fine. All that goes away is the header mangling. > > that is partially true. it can work just fine, but all the bloat in v6 > makes it way harder to implement the state tracking than it should be. > What bloat? Larger address space? ~Seth From gbonser at seven.com Mon Oct 18 13:41:09 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 18 Oct 2010 11:41:09 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <37C8B453-0361-43E6-9001-861CD51FB196@delong.com> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org><4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com><3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <37C8B453-0361-43E6-9001-861CD51FB196@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C36B@RWC-EX1.corp.seven.com> > > > You are confusing SI with Packet Filters. The technologies are > different > and it is, also, important to understand this distinction as well. I don't think I am "confusing" the two. I am saying that I have seen people use them and think they are secure when they aren't. IPv6 is going to make it a little harder for people to make this mistake (or easier to make it, I haven't decided yet which way it will go) and you will see more people purchasing equipment that does real state inspection which is my reason for predicting an increase in firewall sales. They won't have that dynamic NAT that lulls some into a false sense of security. Also, I believe the "fire suit" approach will become more important to people rather than the "fire wall" approach with IPv6. G From ken.gilmour at gmail.com Mon Oct 18 13:53:47 2010 From: ken.gilmour at gmail.com (Ken Gilmour) Date: Mon, 18 Oct 2010 20:53:47 +0200 Subject: Terminology Request, WAS: Enterprise DNS providers In-Reply-To: <20101018082129.GC4746@besserwisser.org> References: <20101018082129.GC4746@besserwisser.org> Message-ID: On 18 October 2010 10:21, Mans Nilsson wrote: > Subject: Terminology Request, WAS: Enterprise DNS providers Date: Mon, Oct > 18, 2010 at 12:36:33AM -0700 Quoting Michael DeMan (nanog at deman.com): > > Hi, > > > > I have been following this thread, and am mostly curious - can somebody > (or preferably several folks) define what is meant by 'Enterprise DNS' ? > > "Quality DNS operations for people with lots of money and not so lots > of operational capacity (dare I say clue?)" Or maybe for some random company who doesn't have the burstable capacity to handle a multi-gigabit network attack with a couple of office DNS servers. Or maybe just a company who requires a guaranteed SLA... etc... Had we moved to a free provider I have no doubt they would have gone down as well which is not a very nice thing for us to do, so we moved to someone who could shout at us and we could shout at. From jcurran at arin.net Mon Oct 18 13:55:49 2010 From: jcurran at arin.net (John Curran) Date: Mon, 18 Oct 2010 14:55:49 -0400 Subject: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation In-Reply-To: <8453F6E1-9632-4740-9AC4-68522EDE86B0@virtualized.org> References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <8453F6E1-9632-4740-9AC4-68522EDE86B0@virtualized.org> Message-ID: On Oct 18, 2010, at 2:18 PM, David Conrad wrote: > On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: >> ARIN does reservations (unsure at what length, but at least down to /31). > > Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... ARIN is doing the same (the 'bisection' method) with our IPv6 management since January 2010: we refer to the "sparse allocation" approach and it was requested by the community during the ARIN/NANOG Dearborn meeting. FYI, /John John Curran President and CEO ARIN From owen at delong.com Mon Oct 18 14:02:23 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 12:02:23 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <8453F6E1-9632-4740-9AC4-68522EDE86B0@virtualized.org> References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <8453F6E1-9632-4740-9AC4-68522EDE86B0@virtualized.org> Message-ID: On Oct 18, 2010, at 11:18 AM, David Conrad wrote: > On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: >> ARIN does reservations (unsure at what length, but at least down to /31). > > Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... > > Regards, > -drc > No, ARIN converted to bisection quite some time ago. Owen From owen at delong.com Mon Oct 18 14:02:00 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 12:02:00 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101018181904.GE28093@nudo.bsws.de> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <20101018181904.GE28093@nudo.bsws.de> Message-ID: On Oct 18, 2010, at 11:19 AM, Henning Brauer wrote: > * Owen DeLong [2010-10-18 18:29]: >> The good news is that stateful inspection doesn't go away in IPv6. > > that is right. > >> It works just fine. All that goes away is the header mangling. > > that is partially true. it can work just fine, but all the bloat in v6 > makes it way harder to implement the state tracking than it should be. > Actually, the state tracking in IPv6 requires a little more memory, but, it's actually easier on the silicon and has significant improvements over IPv4 for ASIC parsing of the headers. >> It's really unfortunate that most people don't understand the distinction. >> If they did, it would help them to realize that NAT doesn't actually do >> anything for security, it just helps with address conservation (although >> it has some limits there, as well). > > right. > >> IPv6 with SI is no less secure than IPv4 with SI+NAT. > > well, it is. the extension headers are horrible. the v4 mapping horror > is an insane trap, too. link-local is the most horrid concept ever. > all hail 160 bit addresses. > We can agree to disagree. Owen From owen at delong.com Mon Oct 18 14:00:25 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 12:00:25 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> Message-ID: On Oct 18, 2010, at 11:18 AM, Jon Lewis wrote: > On Mon, 18 Oct 2010, Owen DeLong wrote: > >> The customers should get /48s. The /56 guideline is merely that and only for the smallest of sites. It's also subsequently turned out to be bad advice. > > Can you elaborate on why /56 is "bad advice" and if you're saying it only for this case or if you're saying assignment of /56 to any customers is a bad idea? Dealing with a data center where customer machines typically get by today with a /29 of IPv4, is a /56 really not enough for their forseeable future? > I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking. In a datacenter environment, you might want to actually assign /64s to needed subnets, but, in a situation where you are serving remote end-sites, a /48 per end-site is, IMHO, the minimum size that should be issued. > I realize our /32 could support more customers than we're likely to fit in the data center at /48 per customer, but is that enough of a reason to assign 65k /64 subnets to each customer machine? > Datacenter is a whole different ball of wax. Nothing wrong with giving your customers /48s, but, the right size in a datacenter may well depend on a lot of things about your business model, the nature of your customers, etc. Certainly I would not deny a /48 to any customer that requested one. Owen From rcarpen at network1.net Mon Oct 18 14:08:23 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 18 Oct 2010 15:08:23 -0400 (EDT) Subject: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation In-Reply-To: Message-ID: <1271449430.11285.1287428903668.JavaMail.root@zimbra.network1.net> John, Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations? -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > On Oct 18, 2010, at 2:18 PM, David Conrad wrote: > > On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: > >> ARIN does reservations (unsure at what length, but at least down to > >> /31). > > > > Do they still do that? Back when I was at IANA, one of the > > justifications the RIRs gave for the /12s they received was that > > they were going to be using the 'bisection' method of allocation > > which removes the need for reservation. Last I heard, APNIC was > > using the bisection method... > > ARIN is doing the same (the 'bisection' method) with our IPv6 > management > since January 2010: we refer to the "sparse allocation" approach and > it > was requested by the community during the ARIN/NANOG Dearborn meeting. > > FYI, > /John > > John Curran > President and CEO > ARIN From owen at delong.com Mon Oct 18 14:05:16 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 12:05:16 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: Message-ID: <2EF322EA-C21C-4B8E-9623-3A1655B36B8A@delong.com> On Oct 18, 2010, at 12:26 PM, Johnny Eriksson wrote: > "Tony Hain" wrote: > >> Actually nat does something for security, it decimates it. Any 'real' >> security system (physical, technology, ...) includes some form of audit >> trail. NAT explicitly breaks any form of audit trail, unless you are the one >> operating the header mangling device. Given that there is no limit to the >> number of nat devices along a path, there can be no limit to the number of >> people operating them. This means there is no audit trail, and therefore NO >> SECURITY. > > So an audit trail implies security? I don't agree. It may make post-mortem > analysis easier, thou. > An audit trail improves security because post-mortem analysis of breaches is an important tool in improving security. > Does end-to-end crypto break security? Which security? The security of > the endpoints or the security of someone else who cannot now audit the > communication in question fully? > No, end-to-end crypto does not, by itself, break security. Arguably, end-to-end crypto MAY bypass security in some environments, but, those environments do have controls available to disable end-to-end crypto. Owen From dr at cluenet.de Mon Oct 18 14:22:43 2010 From: dr at cluenet.de (Daniel Roesen) Date: Mon, 18 Oct 2010 21:22:43 +0200 Subject: Network Operators Europe? In-Reply-To: References: Message-ID: <20101018192243.GA19905@srv03.cluenet.de> On Mon, Oct 18, 2010 at 06:02:56AM -0400, Day Domes wrote: > What is the name of the mailing list for Network Operators Europe? The closest one to that is RIPE's European Operators Forum WG mailing list, but that one has zero traffic. http://www.ripe.net/ripe/wg/eof/index.html Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From jcurran at arin.net Mon Oct 18 14:27:39 2010 From: jcurran at arin.net (John Curran) Date: Mon, 18 Oct 2010 15:27:39 -0400 Subject: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation In-Reply-To: <1271449430.11285.1287428903668.JavaMail.root@zimbra.network1.net> References: <1271449430.11285.1287428903668.JavaMail.root@zimbra.network1.net> Message-ID: Randy - We'll likely put that out to the ARIN community for consultation at the point in time when becomes a potential issue. I expect we will have plenty of time before that needs to be considered at the present rate of allocation. /John John Curran President and CEO ARIN On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote: > John, > > Can you tell us at what degree the bisection stops? i.e. does it keep going until there are no spaces left, or will you leave some space in between each one to leave some room for future needs for orgs that already have allocations? > > > -Randy > > -- > | Randy Carpenter > | Vice President, IT Services > | Red Hat Certified Engineer > | First Network Group, Inc. > | (419)739-9240, x1 > ---- > > ----- Original Message ----- >> On Oct 18, 2010, at 2:18 PM, David Conrad wrote: >>> On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: >>>> ARIN does reservations (unsure at what length, but at least down to >>>> /31). >>> >>> Do they still do that? Back when I was at IANA, one of the >>> justifications the RIRs gave for the /12s they received was that >>> they were going to be using the 'bisection' method of allocation >>> which removes the need for reservation. Last I heard, APNIC was >>> using the bisection method... >> >> ARIN is doing the same (the 'bisection' method) with our IPv6 >> management >> since January 2010: we refer to the "sparse allocation" approach and >> it >> was requested by the community during the ARIN/NANOG Dearborn meeting. >> >> FYI, >> /John >> >> John Curran >> President and CEO >> ARIN From rcarpen at network1.net Mon Oct 18 14:42:17 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 18 Oct 2010 15:42:17 -0400 (EDT) Subject: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation In-Reply-To: Message-ID: <1790150026.11324.1287430937213.JavaMail.root@zimbra.network1.net> I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. thanks, -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > Randy - > > We'll likely put that out to the ARIN community for consultation > at the point in time when becomes a potential issue. I expect we > will have plenty of time before that needs to be considered at the > present rate of allocation. > > /John > > John Curran > President and CEO > ARIN > > On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote: > > > John, > > > > Can you tell us at what degree the bisection stops? i.e. does it > > keep going until there are no spaces left, or will you leave some > > space in between each one to leave some room for future needs for > > orgs that already have allocations? > > > > > > -Randy > > > > -- > > | Randy Carpenter > > | Vice President, IT Services > > | Red Hat Certified Engineer > > | First Network Group, Inc. > > | (419)739-9240, x1 > > ---- > > > > ----- Original Message ----- > >> On Oct 18, 2010, at 2:18 PM, David Conrad wrote: > >>> On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: > >>>> ARIN does reservations (unsure at what length, but at least down > >>>> to > >>>> /31). > >>> > >>> Do they still do that? Back when I was at IANA, one of the > >>> justifications the RIRs gave for the /12s they received was that > >>> they were going to be using the 'bisection' method of allocation > >>> which removes the need for reservation. Last I heard, APNIC was > >>> using the bisection method... > >> > >> ARIN is doing the same (the 'bisection' method) with our IPv6 > >> management > >> since January 2010: we refer to the "sparse allocation" approach > >> and > >> it > >> was requested by the community during the ARIN/NANOG Dearborn > >> meeting. > >> > >> FYI, > >> /John > >> > >> John Curran > >> President and CEO > >> ARIN From jbates at brightok.net Mon Oct 18 15:10:35 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 18 Oct 2010 15:10:35 -0500 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <20101018.202020.41637336.sthaug@nethelp.no> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> Message-ID: <4CBCA9BB.8000202@brightok.net> On 10/18/2010 1:20 PM, sthaug at nethelp.no wrote: > > I still haven't seen any good argument for why residential users need > /48s. No, I don't think "that makes all the address assignments the > same size" is a particularly relevant or convincing argument. > > We're doing /56 for residential users, and have no plans to change > this. +1 This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy. Jack From joelja at bogus.com Mon Oct 18 15:13:58 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 18 Oct 2010 13:13:58 -0700 Subject: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation In-Reply-To: <1790150026.11324.1287430937213.JavaMail.root@zimbra.network1.net> References: <1790150026.11324.1287430937213.JavaMail.root@zimbra.network1.net> Message-ID: <4CBCAA86.3000305@bogus.com> On 10/18/10 12:42 PM, Randy Carpenter wrote: > > I have a few customers whose allocations are /29 away from their > nearest neighbor (half a nibble). That seems a little close > considering there is a lot of talk about doing nibble boundaries, and > there doesn't seem to be consensus yet. > > For these customers, I don't think they will need more than a /29, > but if we collectively decide that a /28 is the next step from a /32, > how will the older allocations be dealt with? This is pretty much a > rhetorical question at this point, and I suppose the proper thing to > do is to channel these questions toward the PPML for discussion as > potential policy. back in the distant past we were issued a /35, policy changed, we returned it and on 2001 7/11 we were issued our current /32 > thanks, -Randy > > -- | Randy Carpenter | Vice President, IT Services | Red Hat > Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 > ---- > > ----- Original Message ----- >> Randy - >> >> We'll likely put that out to the ARIN community for consultation at >> the point in time when becomes a potential issue. I expect we will >> have plenty of time before that needs to be considered at the >> present rate of allocation. >> >> /John >> >> John Curran President and CEO ARIN >> >> On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote: >> >>> John, >>> >>> Can you tell us at what degree the bisection stops? i.e. does it >>> keep going until there are no spaces left, or will you leave >>> some space in between each one to leave some room for future >>> needs for orgs that already have allocations? >>> >>> >>> -Randy >>> >>> -- | Randy Carpenter | Vice President, IT Services | Red Hat >>> Certified Engineer | First Network Group, Inc. | (419)739-9240, >>> x1 ---- >>> >>> ----- Original Message ----- >>>> On Oct 18, 2010, at 2:18 PM, David Conrad wrote: >>>>> On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: >>>>>> ARIN does reservations (unsure at what length, but at least >>>>>> down to /31). >>>>> >>>>> Do they still do that? Back when I was at IANA, one of the >>>>> justifications the RIRs gave for the /12s they received was >>>>> that they were going to be using the 'bisection' method of >>>>> allocation which removes the need for reservation. Last I >>>>> heard, APNIC was using the bisection method... >>>> >>>> ARIN is doing the same (the 'bisection' method) with our IPv6 >>>> management since January 2010: we refer to the "sparse >>>> allocation" approach and it was requested by the community >>>> during the ARIN/NANOG Dearborn meeting. >>>> >>>> FYI, /John >>>> >>>> John Curran President and CEO ARIN > From franck at genius.com Mon Oct 18 15:38:21 2010 From: franck at genius.com (Franck Martin) Date: Tue, 19 Oct 2010 08:38:21 +1200 (FJT) Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC62B4.9080301@axu.tm> Message-ID: <2811134.7.1287434296118.JavaMail.franck@franck-martins-macbook-pro.local> I'm an IPv6 pioneer, because I did it the year, you could really go IPv6 only. That was when ICANN put IPv6 glue in the root zone, which fell a few days before the IETF did an IPv4 blackout. I thank Russ to come up with this IPv4 blackout, because it certainly encouraged ICANN to get its act and Google to do ipv6.google.com. I'm not sure which came first in this story, but for me IPv6 left research to production on that year. The problem it should have happened 5 years earlier, now everyone is struggling to catch up... This is the year also IETF (and carriers, vendors,...) started to realize all the issues that were left to tackle. People before that were Mavericks! ----- Original Message ----- From: "Aleksi Suhonen" To: nanog at nanog.org Sent: Tuesday, 19 October, 2010 3:07:32 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA Hello, ML wrote: > IPv6 Hipsters..Doing it before it was cool. I'm afraid I'm still doing it before it's cool. )-; -- Aleksi Suhonen () ascii ribbon campaign /\ support plain text e-mail From franck at genius.com Mon Oct 18 15:41:09 2010 From: franck at genius.com (Franck Martin) Date: Tue, 19 Oct 2010 08:41:09 +1200 (FJT) Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <1287421386.15871.35.camel@wks02> Message-ID: <14846086.11.1287434469185.JavaMail.franck@franck-martins-macbook-pro.local> Tunnels! OECD and many others recommends to do tunnels if your upstream is "uncooperative" They work well... This is why I say, get your clients first, think servers later... ----- Original Message ----- From: "Jonas Frey (Probe Networks)" To: "Jeffrey Lyon" Cc: "NANOG list" Sent: Tuesday, 19 October, 2010 5:03:06 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA How do you want to do that without IPv6 connectivity? :-) -Jonas From franck at genius.com Mon Oct 18 15:51:06 2010 From: franck at genius.com (Franck Martin) Date: Tue, 19 Oct 2010 08:51:06 +1200 (FJT) Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBCA9BB.8000202@brightok.net> Message-ID: <3041529.15.1287435062708.JavaMail.franck@franck-martins-macbook-pro.local> So they can't run their own services from home and have to request premium connectivity from you? Beside the IPv4 scarcity mentality we have the Telco mentality to fight... Happy days still ahead... ----- Original Message ----- From: "Jack Bates" To: sthaug at nethelp.no Cc: nanog at nanog.org Sent: Tuesday, 19 October, 2010 8:10:35 AM Subject: Re: Definitive Guide to IPv6 adoption On 10/18/2010 1:20 PM, sthaug at nethelp.no wrote: > > I still haven't seen any good argument for why residential users need > /48s. No, I don't think "that makes all the address assignments the > same size" is a particularly relevant or convincing argument. > > We're doing /56 for residential users, and have no plans to change > this. +1 This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy. Jack From joelja at bogus.com Mon Oct 18 15:58:57 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Mon, 18 Oct 2010 13:58:57 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <2811134.7.1287434296118.JavaMail.franck@franck-martins-macbook-pro.local> References: <2811134.7.1287434296118.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4CBCB511.30700@bogus.com> On 10/18/10 1:38 PM, Franck Martin wrote: > I'm an IPv6 pioneer, because I did it the year, you could really go > IPv6 only. That was when ICANN put IPv6 glue in the root zone, which > fell a few days before the IETF did an IPv4 blackout. > > I thank Russ to come up with this IPv4 blackout, because it certainly > encouraged ICANN to get its act and Google to do ipv6.google.com. Insofar as I am aware the first "ipv6 hour" was the brainchild of Randy Bush and Mark Tinka at apricot 2008. Not experienced first at the IETF. > I'm > not sure which came first in this story, but for me IPv6 left > research to production on that year. The problem it should have > happened 5 years earlier, now everyone is struggling to catch up... > > This is the year also IETF (and carriers, vendors,...) started to > realize all the issues that were left to tackle. > > People before that were Mavericks! > > ----- Original Message ----- From: "Aleksi Suhonen" > To: nanog at nanog.org Sent: Tuesday, 19 October, > 2010 3:07:32 AM Subject: Re: Only 5x IPv4 /8 remaining at IANA > > Hello, > > ML wrote: >> IPv6 Hipsters..Doing it before it was cool. > > I'm afraid I'm still doing it before it's cool. )-; > > From owen at delong.com Mon Oct 18 15:54:37 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Oct 2010 13:54:37 -0700 Subject: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation In-Reply-To: <1790150026.11324.1287430937213.JavaMail.root@zimbra.network1.net> References: <1790150026.11324.1287430937213.JavaMail.root@zimbra.network1.net> Message-ID: <8F957B67-CCBF-4BF2-86C5-686C034D9FE8@delong.com> Generally the older allocations would be left in place until deprecated by attrition. At least that's what I plan to advocate in my policy proposal. Owen Sent from my iPad On Oct 18, 2010, at 12:42 PM, Randy Carpenter wrote: > > I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. > > For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. > > thanks, > -Randy > > -- > | Randy Carpenter > | Vice President, IT Services > | Red Hat Certified Engineer > | First Network Group, Inc. > | (419)739-9240, x1 > ---- > > ----- Original Message ----- >> Randy - >> >> We'll likely put that out to the ARIN community for consultation >> at the point in time when becomes a potential issue. I expect we >> will have plenty of time before that needs to be considered at the >> present rate of allocation. >> >> /John >> >> John Curran >> President and CEO >> ARIN >> >> On Oct 18, 2010, at 3:08 PM, Randy Carpenter wrote: >> >>> John, >>> >>> Can you tell us at what degree the bisection stops? i.e. does it >>> keep going until there are no spaces left, or will you leave some >>> space in between each one to leave some room for future needs for >>> orgs that already have allocations? >>> >>> >>> -Randy >>> >>> -- >>> | Randy Carpenter >>> | Vice President, IT Services >>> | Red Hat Certified Engineer >>> | First Network Group, Inc. >>> | (419)739-9240, x1 >>> ---- >>> >>> ----- Original Message ----- >>>> On Oct 18, 2010, at 2:18 PM, David Conrad wrote: >>>>> On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: >>>>>> ARIN does reservations (unsure at what length, but at least down >>>>>> to >>>>>> /31). >>>>> >>>>> Do they still do that? Back when I was at IANA, one of the >>>>> justifications the RIRs gave for the /12s they received was that >>>>> they were going to be using the 'bisection' method of allocation >>>>> which removes the need for reservation. Last I heard, APNIC was >>>>> using the bisection method... >>>> >>>> ARIN is doing the same (the 'bisection' method) with our IPv6 >>>> management >>>> since January 2010: we refer to the "sparse allocation" approach >>>> and >>>> it >>>> was requested by the community during the ARIN/NANOG Dearborn >>>> meeting. >>>> >>>> FYI, >>>> /John >>>> >>>> John Curran >>>> President and CEO >>>> ARIN From jbates at brightok.net Mon Oct 18 16:12:04 2010 From: jbates at brightok.net (Jack Bates) Date: Mon, 18 Oct 2010 16:12:04 -0500 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <3041529.15.1287435062708.JavaMail.franck@franck-martins-macbook-pro.local> References: <3041529.15.1287435062708.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <4CBCB824.9050905@brightok.net> On 10/18/2010 3:51 PM, Franck Martin wrote: > So they can't run their own services from home and have to request premium connectivity from you? > > Beside the IPv4 scarcity mentality we have the Telco mentality to fight... > > Happy days still ahead... > Of course they can run their own services at home. How does renumber effect that (outside of poor v6 implementations at this late stage)? v6 is designed to support multiple prefixes and the ability to change from one prefix to another with limited disruption, especially if I give 24 hours to complete the transition. If servers and services can't handle this, I'd say they need to improve, or the customer will need a static allocation, which we may or may not charge for (depending on how automated we make it). A sane default of rotation is appropriate for us, though, and no amount of fighting by anyone will make the Telco think that google or others have the right to track their users. It's unfair for our users who block cookies, do due diligence to not be tracked, and then we throw them to the wolves with a constant trackable prefix. Jack (knew this would start an argument. *sigh*) From Valdis.Kletnieks at vt.edu Mon Oct 18 16:15:14 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 18 Oct 2010 17:15:14 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: Your message of "Mon, 18 Oct 2010 14:41:36 +0200." <87k4lfekqn.fsf@oban.berlin.quux.de> References: <4CBC3328.7090205@unfix.org> <87k4lfekqn.fsf@oban.berlin.quux.de> Message-ID: <83271.1287436514@localhost> On Mon, 18 Oct 2010 14:41:36 +0200, Jens Link said: > Jeroen Massar writes: > > > So, if your company is not doing IPv6 yet, you really are really getting > > late now. > > They won't listen. Consider it evolution in action. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From franck at genius.com Mon Oct 18 16:15:21 2010 From: franck at genius.com (Franck Martin) Date: Tue, 19 Oct 2010 09:15:21 +1200 (FJT) Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBCB511.30700@bogus.com> Message-ID: <32699037.24.1287436241305.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Joel Jaeggli" > To: "Franck Martin" > Cc: nanog at nanog.org > Sent: Tuesday, 19 October, 2010 8:58:57 AM > Subject: Re: Only 5x IPv4 /8 remaining at IANA > On 10/18/10 1:38 PM, Franck Martin wrote: > > I'm an IPv6 pioneer, because I did it the year, you could really go > > IPv6 only. That was when ICANN put IPv6 glue in the root zone, which > > fell a few days before the IETF did an IPv4 blackout. > > > > I thank Russ to come up with this IPv4 blackout, because it > > certainly > > encouraged ICANN to get its act and Google to do ipv6.google.com. > > Insofar as I am aware the first "ipv6 hour" was the brainchild of > Randy > Bush and Mark Tinka at apricot 2008. Not experienced first at the > IETF. > https://wiki.tools.isoc.org/IETF71_IPv4_Outage March 2008 Apricot 2008 was in Feb 2008 there was also an IPv6 hour at NANOG 42 in February 2008 But Russ spoke about it in 2007, knowing there will be resistance... And they must have been all talking to each others, so I'm not sure who to credit for the idea, but I can credit Russ for his IETF leadership in making it happen there. ICANN had just put the glue in February. Google decided to make it in time, seeing the opportunity and convergence of will. Anyhow the year it all happened was 2008, there was a convergence of ideas. So I would say since 2008 we have made great progress on IPv6 deployment, but we started very late... From dougb at dougbarton.us Mon Oct 18 16:39:19 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 18 Oct 2010 14:39:19 -0700 (PDT) Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> Message-ID: On Mon, 18 Oct 2010, Owen DeLong wrote: > I think it's generally a bad idea. /48 is the design architecture for > IPv6. It allows for significant innovation in the SOHO arena that we > haven't accounted for in some of our current thinking. Q: Why are /48s everywhere a good idea? A: Because it's the design! Q: Why are /48s everywhere in the design? A? Because it's a good idea! This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place. The model I've been advocating is for ISPs (who have enough space) to start off reserving a /48 per customer and then assigning the first /56 from it. If after real operational experience it turns out /48 is the right answer, you're all set. If /56 turns out to be sufficient, when you use up all of the first /56s you can start on the first /56 in the second /49, etc. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From dougb at dougbarton.us Mon Oct 18 16:40:49 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 18 Oct 2010 14:40:49 -0700 (PDT) Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <201010181620.o9IGK09V098786@aurora.sol.net> References: <201010181620.o9IGK09V098786@aurora.sol.net> Message-ID: On Mon, 18 Oct 2010, Joe Greco wrote: > For example, consider the T-Mobile Sidekick Danger server crash/disaster. > This is frequently pointed to as a "failure of the cloud", but in reality, > it appears to have been trusting data to a company that wasn't exercising > proper care in maintaining its servers. In at least one sense I think that those are the same thing. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From dorian at blackrose.org Mon Oct 18 16:40:57 2010 From: dorian at blackrose.org (Dorian Kim) Date: Mon, 18 Oct 2010 17:40:57 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <2811134.7.1287434296118.JavaMail.franck@franck-martins-macbook-pro.local> References: <2811134.7.1287434296118.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <0027A2AF-54A7-4DA0-BD87-A182F4BD8264@blackrose.org> Wouldn't it be better to leave such labels and judgements to future generations? I'm sure they'll be the best judge of who led them to paradise /ruin. -dorian From sethm at rollernet.us Mon Oct 18 16:44:59 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 18 Oct 2010 14:44:59 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> Message-ID: <4CBCBFDB.6040409@rollernet.us> On 10/18/2010 14:39, Doug Barton wrote: > On Mon, 18 Oct 2010, Owen DeLong wrote: > >> I think it's generally a bad idea. /48 is the design architecture for >> IPv6. It allows for significant innovation in the SOHO arena that we >> haven't accounted for in some of our current thinking. > > Q: Why are /48s everywhere a good idea? > A: Because it's the design! > > Q: Why are /48s everywhere in the design? > A? Because it's a good idea! > > This kind of crap is one of the reasons people get frustrated with IPv6 > zealotry. If people are actually interested in deploying IPv6 then by > all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the > wrong allocation to end users are fixable, especially given that the > vast majority of end user assignments are dynamic in the first place. Dynamic under IPv4, that is. It could be argued that IPv6 brings back the ability to go static everywhere again. ~Seth From Valdis.Kletnieks at vt.edu Mon Oct 18 16:46:04 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Mon, 18 Oct 2010 17:46:04 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: Your message of "Mon, 18 Oct 2010 10:52:18 PDT." <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> Message-ID: <84764.1287438364@localhost> On Mon, 18 Oct 2010 10:52:18 PDT, George Bonser said: > > From: Owen DeLong [mailto:owen at delong.com] > > The good news is that stateful inspection doesn't go away in IPv6. It works > > just fine. All that goes away is the header mangling. > > Exactly true but there are people out there who experience it as > "dynamic nat prevents inbound connections". Those people are next on my hit list, after we've finally eliminated those who still talk about class A/B/C addresses. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Mon Oct 18 17:15:31 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Tue, 19 Oct 2010 08:45:31 +1030 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> Message-ID: <20101019084531.701c1cc8@opy.nosense.org> On Mon, 18 Oct 2010 14:39:19 -0700 (PDT) Doug Barton wrote: > On Mon, 18 Oct 2010, Owen DeLong wrote: > > > I think it's generally a bad idea. /48 is the design architecture for > > IPv6. It allows for significant innovation in the SOHO arena that we > > haven't accounted for in some of our current thinking. > > Q: Why are /48s everywhere a good idea? > A: Because it's the design! > > Q: Why are /48s everywhere in the design? > A? Because it's a good idea! > > This kind of crap is one of the reasons people get frustrated with IPv6 > zealotry. If people are actually interested in deploying IPv6 then by > all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the > wrong allocation to end users are fixable, especially given that the > vast majority of end user assignments are dynamic in the first place. > > The model I've been advocating is for ISPs (who have enough space) to > start off reserving a /48 per customer and then assigning the first /56 > from it. If after real operational experience it turns out /48 is the > right answer, you're all set. If /56 turns out to be sufficient, when > you use up all of the first /56s you can start on the first /56 in the > second /49, etc. > While I like the idea of /48s per customer ("per-nearly everybody"), I do think this approach is a good, slightly more conservative approach. Regards, Mark. From hb-nanog at bsws.de Mon Oct 18 17:42:04 2010 From: hb-nanog at bsws.de (Henning Brauer) Date: Tue, 19 Oct 2010 00:42:04 +0200 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: References: <20101018123046.GU10815@nudo.bsws.de> Message-ID: <20101018224204.GC17339@nudo.bsws.de> * Ricky Beam [2010-10-18 21:32]: > On Mon, 18 Oct 2010 08:30:48 -0400, Henning Brauer > wrote: > >"Currently, the Pica8 driver is released in binary form" > > > >none of the interesting low-level drivers is open. none. zero. > > If it's based on a Broadcom chip, trust me, they are doing the world > a favor by not exposing you to the SoC SDK. broadcom being too ashamed to show their code would not surprise me at all. however, that is no excuse. especially not when they try to market this as an "open source" switch. -- Henning Brauer, hb at bsws.de, henning at openbsd.org BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting From jcurran at arin.net Mon Oct 18 19:14:18 2010 From: jcurran at arin.net (John Curran) Date: Mon, 18 Oct 2010 20:14:18 -0400 Subject: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation In-Reply-To: <1790150026.11324.1287430937213.JavaMail.root@zimbra.network1.net> References: <1790150026.11324.1287430937213.JavaMail.root@zimbra.network1.net> Message-ID: <328B32D3-B012-4C90-A1D6-C7236607439E@arin.net> On Oct 18, 2010, at 3:42 PM, Randy Carpenter wrote: > > I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. > > For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. Just for reference regarding existing IPv6 sparse practice: Our current plan is to use the sparse allocation block (currently a /14) until we fill it up. Bisection done at the /28 boundary which leaves a fairly large reserve. If an organization needs an allocation larger than a /28, we have set aside a /15 block for those larger ISPs. The orgs that already have allocations (/32s from /29s) also have a reserve. If they need additional space, they can either request from their /29 reserve, or if they need more than a /29, can request a new block. Obviously, this can be changed if the community wishes it so. Bring any obvious suggestions to the ARIN suggestion process, and anything which might be contentious or affect allocations to the policy process. Thanks! /John John Curran President and CEO ARIN From rs at seastrom.com Mon Oct 18 19:16:59 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 18 Oct 2010 20:16:59 -0400 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <20101018.202020.41637336.sthaug@nethelp.no> (sthaug@nethelp.no's message of "Mon, 18 Oct 2010 20:20:20 +0200 (CEST)") References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> Message-ID: <86aambhw90.fsf@seastrom.com> sthaug at nethelp.no writes: > I still haven't seen any good argument for why residential users need > /48s. No, I don't think "that makes all the address assignments the > same size" is a particularly relevant or convincing argument. > > We're doing /56 for residential users, and have no plans to change > this. If we were to give a /48 to every human on the face of the planet, we would use about .000025 of the total available IPv6 address space. You are to be commended for your leadership in conserving space. Our children will surely be grateful that thanks to your efforts they have 99.99999% of IPv6 space left to work with rather than the paltry 99.9975% that might have been their inheritance were it not for your efforts. Bravo! -r From rcarpen at network1.net Mon Oct 18 19:43:43 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Mon, 18 Oct 2010 20:43:43 -0400 (EDT) Subject: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation In-Reply-To: <328B32D3-B012-4C90-A1D6-C7236607439E@arin.net> Message-ID: <1657729872.11442.1287449023222.JavaMail.root@zimbra.network1.net> John, Thank you very much. That clarification helps out quite a bit. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > On Oct 18, 2010, at 3:42 PM, Randy Carpenter wrote: > > > > I have a few customers whose allocations are /29 away from their > > nearest neighbor (half a nibble). That seems a little close > > considering there is a lot of talk about doing nibble boundaries, > > and there doesn't seem to be consensus yet. > > > > For these customers, I don't think they will need more than a /29, > > but if we collectively decide that a /28 is the next step from a > > /32, how will the older allocations be dealt with? This is pretty > > much a rhetorical question at this point, and I suppose the proper > > thing to do is to channel these questions toward the PPML for > > discussion as potential policy. > > Just for reference regarding existing IPv6 sparse practice: > > Our current plan is to use the sparse allocation block (currently a > /14) > until we fill it up. Bisection done at the /28 boundary which leaves a > fairly large reserve. > > If an organization needs an allocation larger than a /28, we have set > aside a /15 block for those larger ISPs. > > The orgs that already have allocations (/32s from /29s) also have a > reserve. If they need additional space, they can either request from > their /29 reserve, or if they need more than a /29, can request a new > block. > > Obviously, this can be changed if the community wishes it so. Bring > any obvious suggestions to the ARIN suggestion process, and anything > which might be contentious or affect allocations to the policy > process. > > Thanks! > /John > > John Curran > President and CEO > ARIN From tme at americafree.tv Mon Oct 18 19:45:30 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Mon, 18 Oct 2010 20:45:30 -0400 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <86aambhw90.fsf@seastrom.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> Message-ID: <35804BC3-9EFE-4CE4-B13A-F2E15C420EFA@americafree.tv> On Oct 18, 2010, at 8:16 PM, Robert E. Seastrom wrote: > > sthaug at nethelp.no writes: > >> I still haven't seen any good argument for why residential users need >> /48s. No, I don't think "that makes all the address assignments the >> same size" is a particularly relevant or convincing argument. >> >> We're doing /56 for residential users, and have no plans to change >> this. > > If we were to give a /48 to every human on the face of the planet, we > would use about .000025 of the total available IPv6 address space. > > You are to be commended for your leadership in conserving space. Our > children will surely be grateful that thanks to your efforts they have > 99.99999% of IPv6 space left to work with rather than the paltry > 99.9975% that might have been their inheritance were it not for your > efforts. Bravo! > It makes a bigger difference if everyone starts using 6RD - to give out a /48 effectively requires a /16, and the number of /16s is by no means approximately infinite. Regards Marshall > -r > > > From rs at seastrom.com Mon Oct 18 19:56:02 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 18 Oct 2010 20:56:02 -0400 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <35804BC3-9EFE-4CE4-B13A-F2E15C420EFA@americafree.tv> (Marshall Eubanks's message of "Mon, 18 Oct 2010 20:45:30 -0400") References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <35804BC3-9EFE-4CE4-B13A-F2E15C420EFA@americafree.tv> Message-ID: <8639s3hufx.fsf@seastrom.com> Marshall Eubanks writes: > It makes a bigger difference if everyone starts using 6RD - to give > out a /48 effectively requires a /16, and the number of /16s is by > no means approximately infinite. Don't I know it! Poorly designed protocol, but what're we gonna do? I was of the "a /56 was bad enough, don't let the standard what-people-expect slip to a /60" school. I'm pleased that the ARIN AC passed 2010-12 with provision for getting a /24. Keeps the damage from getting worse. But for native deployment, absolutely just provision the /48. -r From kuniaki at bugest.net Mon Oct 18 20:24:11 2010 From: kuniaki at bugest.net (Kuniaki Kondo) Date: Tue, 19 Oct 2010 10:24:11 +0900 Subject: Network Operators Europe? In-Reply-To: References: Message-ID: <20101019102411.2253.FBED8E4F@bugest.net> On Mon, 18 Oct 2010 06:02:56 -0400 Day Domes wrote: > What is the name of the mailing list for Network Operators Europe? there is a nogs list. http://www.bugest.net/nogs.html - kuniaki From bonomi at mail.r-bonomi.com Mon Oct 18 20:23:45 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 18 Oct 2010 20:23:45 -0500 (CDT) Subject: network name 101100010100110.net Message-ID: <201010190123.o9J1Njra013666@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Sun Oct 17 22:23:13 2010 > Date: Sun, 17 Oct 2010 20:24:30 -0700 > Subject: Re: network name 101100010100110.net > From: Joe Hamelin > To: Mark Andrews > Cc: bmanning at vacation.karoshi.com, nanog at nanog.org > > That's why 3M registered mmm.com back in 1988. Not to mention the fact that the company was originally _named_ "Minnesota Mining & Manufacturing", and that '3M' was *just* a logo and trademark. From drc at virtualized.org Mon Oct 18 20:25:49 2010 From: drc at virtualized.org (David Conrad) Date: Mon, 18 Oct 2010 15:25:49 -1000 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <86aambhw90.fsf@seastrom.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> Message-ID: <65CE49EB-1CD4-4B9F-A516-4AC14E722848@virtualized.org> RS, On Oct 18, 2010, at 2:16 PM, Robert E. Seastrom wrote: > If we were to give a /48 to every human on the face of the planet, we > would use about .000025 of the total available IPv6 address space. Sure. I once did the math that suggested that even if you multiplied the current IPv4 consumption rate by 1000 and applied that consumption rate to IPv6 /48s, the 1/8th of the IPv6 address space used for global unicast would last over 100 years. The problem is that allocation policy depends on who shows up at RIR meetings. Marshall has pointed out the (potential) implications of that policy with respect to 6rd. My math didn't take 6rd into account. Simply, there is no finite resource that people can't figure out a way to waste in an insane fashion. Since IPv6 is a finite resource, I personally think it makes sense for folks to be reasonably conservative in assignment to customers. Regards, -drc From bonomi at mail.r-bonomi.com Mon Oct 18 20:26:28 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 18 Oct 2010 20:26:28 -0500 (CDT) Subject: network name 101100010100110.net Message-ID: <201010190126.o9J1QSG5013690@mail.r-bonomi.com> > Date: Sun, 17 Oct 2010 23:33:13 -0700 > From: Joel Jaeggli > Subject: Re: network name 101100010100110.net > > On 10/17/10 8:24 PM, Joe Hamelin wrote: > > That's why 3M registered mmm.com back in 1988. > > and not just because minnestoaminingandmanufacturing.com is hard to type... Like they had that choice _then_. 14 character limit. > > they've since officially change the name of the company to 3m... > From trelane at trelane.net Mon Oct 18 20:29:14 2010 From: trelane at trelane.net (Andrew Kirch) Date: Mon, 18 Oct 2010 21:29:14 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <84764.1287438364@localhost> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> Message-ID: <4CBCF46A.2010109@trelane.net> On 10/18/2010 5:46 PM, Valdis.Kletnieks at vt.edu wrote: > On Mon, 18 Oct 2010 10:52:18 PDT, George Bonser said: > Those people are next on my hit list, after we've finally eliminated those > who still talk about class A/B/C addresses. :) > IPv6 isn't going to make class-based routing obsolete... is it? *ducks* cheers! Andrew From marka at isc.org Mon Oct 18 20:32:05 2010 From: marka at isc.org (Mark Andrews) Date: Tue, 19 Oct 2010 12:32:05 +1100 Subject: Definitive Guide to IPv6 adoption In-Reply-To: Your message of "Mon, 18 Oct 2010 20:45:30 EDT." <35804BC3-9EFE-4CE4-B13A-F2E15C420EFA@americafree.tv> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com><35804BC3-9EFE-4CE4-B13A-F2E15C420EFA@americafree.tv> Message-ID: <20101019013205.733E55E2280@drugs.dv.isc.org> In message <35804BC3-9EFE-4CE4-B13A-F2E15C420EFA at americafree.tv>, Marshall Euba nks writes: > It makes a bigger difference if everyone starts using 6RD - to give out = > a /48 effectively=20 > requires a /16, and the number of /16s is by no means approximately = > infinite.=20 > > Regards > Marshall Only if you deploy 6rd in a naive manner. Encoding all of IPv4 into the IPv6 prefix you hand your customers in naive. The best way is to just have a table that matches 6rd prefixes to IPv4 blocks you have assigned. This table only changes when you add or remove a IPv4 assignments from RIRs. You don't change existing entries in the table. The entries are static for the life of the IPv4 allocation. <6rdPrefix1><6rdPefixLen1> <6rdPrefix2><6rdPefixLen2> <6rdPrefix3><6rdPefixLen3> When you configure a IPv4 DHCP pool and associated router interface you find the covering IPv4 prefix and plug in the values from the table. The next best way is to have a similar table but per covering IPv4/8 you have allocated. This is very wasteful but not as having a IPv4PrefixLen of 0. <6rdPrefix1><6rdPefixLen><192.0.0.0><8> <6rdPrefix2><6rdPefixLen><202.0.0.0><8> For the global naive case the table degenerates to a single row. <6rdPrefix><6rdPefixLen><0.0.0.0><0> As a exercise the first table was ~20 entries for Comcast Cable and the second table about ~10 entries if I did the lookup correctly so we are not talking about a lot of prefixes and they don't change very often. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bonomi at mail.r-bonomi.com Mon Oct 18 20:33:05 2010 From: bonomi at mail.r-bonomi.com (Robert Bonomi) Date: Mon, 18 Oct 2010 20:33:05 -0500 (CDT) Subject: Pica8 - Open Source Cloud Switch Message-ID: <201010190133.o9J1X5mV013760@mail.r-bonomi.com> > From nanog-bounces+bonomi=mail.r-bonomi.com at nanog.org Mon Oct 18 09:13:13 2010 > Date: Mon, 18 Oct 2010 15:13:35 +0100 > From: Nick Hilliard > To: Brandon Kim > Subject: Re: Pica8 - Open Source Cloud Switch > Cc: nanog at nanog.org > > On 18/10/2010 14:27, Brandon Kim wrote: > > Good question Nick, what is a cloud switch? Is this like VSS in cisco > > where you have a virtual chassis? > > The vss is virtual management software for a virtual switch. This box > looks like a piece of hardware that you can plug things into, so I'm just > wondering what makes this a cloud switch and some other piece of kit not a > cloud switch. Maybe it has to do with whether the magic smoke is on the inside or the outside of the box. From dougb at dougbarton.us Mon Oct 18 21:24:13 2010 From: dougb at dougbarton.us (Doug Barton) Date: Mon, 18 Oct 2010 19:24:13 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <86aambhw90.fsf@seastrom.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> Message-ID: <4CBD014D.8060408@dougbarton.us> On 10/18/2010 5:16 PM, Robert E. Seastrom wrote: > > sthaug at nethelp.no writes: > >> I still haven't seen any good argument for why residential users need >> /48s. No, I don't think "that makes all the address assignments the >> same size" is a particularly relevant or convincing argument. >> >> We're doing /56 for residential users, and have no plans to change >> this. > > If we were to give a /48 to every human on the face of the planet, we > would use about .000025 of the total available IPv6 address space. I'm confused. The "hand out /48s everywhere" crowd keeps saying that we need to do that because we haven't yet anticipated everything that end users might want to do with a /48 on their CPE. On the wider issue of "we don't yet understand everything that can be done with the space" I think we're in agreement. However my conclusion is that "therefore we should be careful to preserve the maximum flexibility possible." After we have some operational experience with IPv6 we will be in a position to make better decisions; but we have to GET operational experience first. Grousing about lack of adherence to holy writ in that deployment doesn't help anybody. And now I'm repeating myself, so that's all for tonight ... Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From ml at kenweb.org Mon Oct 18 22:58:34 2010 From: ml at kenweb.org (ML) Date: Mon, 18 Oct 2010 23:58:34 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBCF46A.2010109@trelane.net> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <4CBCF46A.2010109@trelane.net> Message-ID: <4CBD176A.5040907@kenweb.org> > IPv6 isn't going to make class-based routing obsolete... is it? > *ducks* > > cheers! > > Andrew Of course not. My users are already asking for some Class G networks (/56) to use. From gbonser at seven.com Mon Oct 18 23:27:21 2010 From: gbonser at seven.com (George Bonser) Date: Mon, 18 Oct 2010 21:27:21 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <86aambhw90.fsf@seastrom.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com><20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C38E@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Robert E. Seastrom > Sent: Monday, October 18, 2010 5:17 PM > To: sthaug at nethelp.no > Cc: nanog at nanog.org > Subject: Re: Definitive Guide to IPv6 adoption > You are to be commended for your leadership in conserving space. Our > children will surely be grateful that thanks to your efforts they have > 99.99999% of IPv6 space left to work with rather than the paltry > 99.9975% that might have been their inheritance were it not for your > efforts. Bravo! > > -r > I have a feeling that IP addresses will now be used in ways that people have not envisioned them being used before. Given a surplus of any resource, people find creative ways of using it. From jbates at brightok.net Tue Oct 19 00:53:43 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 19 Oct 2010 00:53:43 -0500 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <86aambhw90.fsf@seastrom.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> Message-ID: <4CBD3267.7070103@brightok.net> On 10/18/2010 7:16 PM, Robert E. Seastrom wrote: > You are to be commended for your leadership in conserving space. Our > children will surely be grateful that thanks to your efforts they have > 99.99999% of IPv6 space left to work with rather than the paltry > 99.9975% that might have been their inheritance were it not for your > efforts. Bravo! Thanks. Actually, I think people are following the RIR example. ARIN handed out a /32 as standard for an ISP, so a /32 is the framework even a medium sized ISP will use. Our routing/IP Numbering Plan: /40 regional assignment supporting 256 regional assignments /44 for only 16 pop assignments? /48 to customer for only 16 customers per pop assignment? Perhaps another view /40 regional assignment supporting 256 regional assignments /44 still for 16 pop assignments /56 to customer for 4096 customer assignments I'm sorry, but I just couldn't find a way to make /48 to customers work appropriately, and ARIN seems to think a /32 is fair, yet I have to design an IP assignment plan up front to make for more efficient routing. I actually expect a /42-/43 per pop, and /38 per region even in the /56 to customer model. Jack From eugen at leitl.org Tue Oct 19 03:18:11 2010 From: eugen at leitl.org (Eugen Leitl) Date: Tue, 19 Oct 2010 10:18:11 +0200 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C38E@RWC-EX1.corp.seven.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <86aambhw90.fsf@seastrom.com> <5A6D953473350C4B9995546AFE9939EE0B14C38E@RWC-EX1.corp.seven.com> Message-ID: <20101019081811.GK28998@leitl.org> On Mon, Oct 18, 2010 at 09:27:21PM -0700, George Bonser wrote: > I have a feeling that IP addresses will now be used in ways that people > have not envisioned them being used before. Given a surplus of any > resource, people find creative ways of using it. Encoding high-resolution geographic coordinates, for multiple bodies in the solar system. From gbonser at seven.com Tue Oct 19 03:41:14 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Oct 2010 01:41:14 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <20101019081811.GK28998@leitl.org> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <86aambhw90.fsf@seastrom.com><5A6D953473350C4B9995546AFE9939EE0B14C38E@RWC-EX1.corp.seven.com> <20101019081811.GK28998@leitl.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C398@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Eugen Leitl > Sent: Tuesday, October 19, 2010 1:18 AM > To: nanog at nanog.org > Subject: Re: Definitive Guide to IPv6 adoption > > On Mon, Oct 18, 2010 at 09:27:21PM -0700, George Bonser wrote: > > > I have a feeling that IP addresses will now be used in ways that > people > > have not envisioned them being used before. Given a surplus of any > > resource, people find creative ways of using it. > > Encoding high-resolution geographic coordinates, for multiple bodies > in the solar system. I was thinking more along the lines of dynamic IP assignment on server hosts and mapping client 64-bit GUIDs to ip addresses for directing traffic to the host with the client state information. From owen at delong.com Tue Oct 19 03:54:21 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 01:54:21 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBCA9BB.8000202@brightok.net> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <4CBCA9BB.8000202@brightok.net> Message-ID: <3699102B-01D5-40CA-83F9-FA3072B8E810@delong.com> On Oct 18, 2010, at 1:10 PM, Jack Bates wrote: > On 10/18/2010 1:20 PM, sthaug at nethelp.no wrote: >> >> I still haven't seen any good argument for why residential users need >> /48s. No, I don't think "that makes all the address assignments the >> same size" is a particularly relevant or convincing argument. >> >> We're doing /56 for residential users, and have no plans to change >> this. > > +1 > > This not only makes pop assignments easier, it gives a much larger prefix rotation pool. Don't start the flame on rotating prefixes being evil. It's my implementation to at least give customers some chance at prefix privacy. > What if your customers don't want prefix privacy and prefer, instead, to have the option of accessing their resources remotely, setting up mobile-IP home gateways, and any of the other functions that come from static prefixes? Finally, no, /56 isn't a great idea for other reasons. Sure, it will meet today's needs, but, it ignores a future in which households aren't simple flat topologies, but, instead have multiple layers of routers dynamically determining hierarchies and building topologies to meet a variety of needs not yet addressable due to the current limitations of IPv4. This isn't pie in the sky science fiction. Most of the technology exists today and all that is left is the deployment of sufficient address resources to the consumer and some integration work at the vendor level. Owen From owen at delong.com Tue Oct 19 03:55:56 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 01:55:56 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <14846086.11.1287434469185.JavaMail.franck@franck-martins-macbook-pro.local> References: <14846086.11.1287434469185.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: Servers work just fine over tunnels if necessary too. Get your public-facing content and services on IPv6 as fast as possible. Make IPv6 available to your customers as quickly as possible too. Finally, your internal IT resources (other than your support department(s)) can probably wait a little while. Owen On Oct 18, 2010, at 1:41 PM, Franck Martin wrote: > Tunnels! > > OECD and many others recommends to do tunnels if your upstream is "uncooperative" > > They work well... > > This is why I say, get your clients first, think servers later... > > ----- Original Message ----- > From: "Jonas Frey (Probe Networks)" > To: "Jeffrey Lyon" > Cc: "NANOG list" > Sent: Tuesday, 19 October, 2010 5:03:06 AM > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > How do you want to do that without IPv6 connectivity? :-) > > > -Jonas > From owen at delong.com Tue Oct 19 04:06:16 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 02:06:16 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> Message-ID: <9C7FBB46-097A-4134-A2B6-772733280234@delong.com> On Oct 18, 2010, at 2:39 PM, Doug Barton wrote: > On Mon, 18 Oct 2010, Owen DeLong wrote: > >> I think it's generally a bad idea. /48 is the design architecture for IPv6. It allows for significant innovation in the SOHO arena that we haven't accounted for in some of our current thinking. > > Q: Why are /48s everywhere a good idea? > A: Because it's the design! > > Q: Why are /48s everywhere in the design? > A? Because it's a good idea! > Which of course ignores the second half of my comment... > This kind of crap is one of the reasons people get frustrated with IPv6 zealotry. If people are actually interested in deploying IPv6 then by all means, STOP BITCHING AT THEM ABOUT HOW THEY DO IT. Problems like the wrong allocation to end users are fixable, especially given that the vast majority of end user assignments are dynamic in the first place. > Unless those problems become endemic and start reducing the lowest common denominator to which vendors feel they must implement. There are advantages to being able to use 16 bits to build various forms of hierarchical topology on a dynamic basis within a SOHO environment. If we reduce that to 8 bits, we will block innovations that are currently underway in this space. > The model I've been advocating is for ISPs (who have enough space) to start off reserving a /48 per customer and then assigning the first /56 from it. If after real operational experience it turns out /48 is the right answer, you're all set. If /56 turns out to be sufficient, when you use up all of the first /56s you can start on the first /56 in the second /49, etc. > Uh, yeah, why not just get your /32 (or whatever larger prefix you started with) expanded or get an additional prefix to put the additional customers into? Then, you're still set and you haven't had to block or reduce capabilities your customers should be able to accept. Owen From owen at delong.com Tue Oct 19 04:16:58 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 02:16:58 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <35804BC3-9EFE-4CE4-B13A-F2E15C420EFA@americafree.tv> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <35804BC3-9EFE-4CE4-B13A-F2E15C420EFA@americafree.tv> Message-ID: <0ECDC1D1-F10B-4C55-B1DE-404F474FC1C9@delong.com> On Oct 18, 2010, at 5:45 PM, Marshall Eubanks wrote: > > On Oct 18, 2010, at 8:16 PM, Robert E. Seastrom wrote: > >> >> sthaug at nethelp.no writes: >> >>> I still haven't seen any good argument for why residential users need >>> /48s. No, I don't think "that makes all the address assignments the >>> same size" is a particularly relevant or convincing argument. >>> >>> We're doing /56 for residential users, and have no plans to change >>> this. >> >> If we were to give a /48 to every human on the face of the planet, we >> would use about .000025 of the total available IPv6 address space. >> >> You are to be commended for your leadership in conserving space. Our >> children will surely be grateful that thanks to your efforts they have >> 99.99999% of IPv6 space left to work with rather than the paltry >> 99.9975% that might have been their inheritance were it not for your >> efforts. Bravo! >> > > It makes a bigger difference if everyone starts using 6RD - to give out a /48 effectively > requires a /16, and the number of /16s is by no means approximately infinite. > That is why the AC chose to allow for a /56 per end-site in the transitional technology policy (6rd is a transitional technology) and why we call for them to be issued from a distinct prefix separate from native IPv6 deployments. In this way, 6rd can be deployed sooner rather than later, but, we have the ability to move forward to a cleaner native IPv6 deployment and deprecate 6rd when it is no longer needed. Owen From owen at delong.com Tue Oct 19 04:23:37 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 02:23:37 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBD014D.8060408@dougbarton.us> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <4CBD014D.8060408@dougbarton.us> Message-ID: <8B810EC0-73FE-492C-9DCC-80DCF4E36F15@delong.com> On Oct 18, 2010, at 7:24 PM, Doug Barton wrote: > On 10/18/2010 5:16 PM, Robert E. Seastrom wrote: >> >> sthaug at nethelp.no writes: >> >>> I still haven't seen any good argument for why residential users need >>> /48s. No, I don't think "that makes all the address assignments the >>> same size" is a particularly relevant or convincing argument. >>> >>> We're doing /56 for residential users, and have no plans to change >>> this. >> >> If we were to give a /48 to every human on the face of the planet, we >> would use about .000025 of the total available IPv6 address space. > > I'm confused. The "hand out /48s everywhere" crowd keeps saying that we need to do that because we haven't yet anticipated everything that end users might want to do with a /48 on their CPE. On the wider issue of "we don't yet understand everything that can be done with the space" I think we're in agreement. However my conclusion is that "therefore we should be careful to preserve the maximum flexibility possible." > Right... Giving /48s to end users for native IPv6 deployments still preserves 99.9975% (or more) of the IPv6 space while not stifling innovation on the CPE side. Maximum flexibility is preserved on both sides of the ISP/customer boundary. Giving customers less doesn't really increase meaningful flexibility for the providers, it just keeps more address space on the shelf gathering dust. > After we have some operational experience with IPv6 we will be in a position to make better decisions; but we have to GET operational experience first. Grousing about lack of adherence to holy writ in that deployment doesn't help anybody. > Some of us actually have some operational experience with IPv6. As such, I'm not grousing about holy writ, I'm talking about real consequences of real actions in real world implementations. Owen From owen at delong.com Tue Oct 19 04:19:48 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 02:19:48 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <65CE49EB-1CD4-4B9F-A516-4AC14E722848@virtualized.org> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <65CE49EB-1CD4-4B9F-A516-4AC14E722848@virtualized.org> Message-ID: <7CA5212D-235F-4AC9-B151-32AF99392374@delong.com> On Oct 18, 2010, at 6:25 PM, David Conrad wrote: > RS, > > On Oct 18, 2010, at 2:16 PM, Robert E. Seastrom wrote: >> If we were to give a /48 to every human on the face of the planet, we >> would use about .000025 of the total available IPv6 address space. > > Sure. I once did the math that suggested that even if you multiplied the current IPv4 consumption rate by 1000 and applied that consumption rate to IPv6 /48s, the 1/8th of the IPv6 address space used for global unicast would last over 100 years. > > The problem is that allocation policy depends on who shows up at RIR meetings. Marshall has pointed out the (potential) implications of that policy with respect to 6rd. My math didn't take 6rd into account. > > Simply, there is no finite resource that people can't figure out a way to waste in an insane fashion. Since IPv6 is a finite resource, I personally think it makes sense for folks to be reasonably conservative in assignment to customers. > > Regards, > -drc > Agreed. /48 is reasonably conservative in native IPv6 deployments. 6rd cannot be done in a reasonably conservative fashion, so, we're kind of stuck with giving /24s to ISPs to give /56s to their customers and living with the consequences. Owen From owen at delong.com Tue Oct 19 04:29:27 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 02:29:27 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBD3267.7070103@brightok.net> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <4CBD3267.7070103@brightok.net> Message-ID: <5D5F72DE-5CA8-4EB9-BEFE-B6C56EA943FB@delong.com> On Oct 18, 2010, at 10:53 PM, Jack Bates wrote: > On 10/18/2010 7:16 PM, Robert E. Seastrom wrote: >> You are to be commended for your leadership in conserving space. Our >> children will surely be grateful that thanks to your efforts they have >> 99.99999% of IPv6 space left to work with rather than the paltry >> 99.9975% that might have been their inheritance were it not for your >> efforts. Bravo! > > Thanks. Actually, I think people are following the RIR example. ARIN handed out a /32 as standard for an ISP, so a /32 is the framework even a medium sized ISP will use. > No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger. > Our routing/IP Numbering Plan: > > > /40 regional assignment supporting 256 regional assignments > /44 for only 16 pop assignments? > /48 to customer for only 16 customers per pop assignment? > Or, better...If you're that large... Start with a /28 /36 regional assignment supporting 256 regional assignments /40 for 16 pops per region /48 for 256 customer end-sites per POP or, if you have larger POPs, start with a /24 and /32 regional assignment supporting 256 regional assignments /36 for 16 pops per region /48 for 4,096 customer end-sites per POP or, if you have larger regions and more POPs per region /28 regional assignment supporting 16 regions /36 for 256 pops per region /48 for 4,096 customer end-sites per POP > Perhaps another view > > /40 regional assignment supporting 256 regional assignments > /44 still for 16 pop assignments > /56 to customer for 4096 customer assignments > > I'm sorry, but I just couldn't find a way to make /48 to customers work appropriately, and ARIN seems to think a /32 is fair, yet I have to design an IP assignment plan up front to make for more efficient routing. I actually expect a /42-/43 per pop, and /38 per region even in the /56 to customer model. > ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space. Owen From rs at seastrom.com Tue Oct 19 05:52:40 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Tue, 19 Oct 2010 06:52:40 -0400 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C38E@RWC-EX1.corp.seven.com> (George Bonser's message of "Mon, 18 Oct 2010 21:27:21 -0700") References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <5A6D953473350C4B9995546AFE9939EE0B14C38E@RWC-EX1.corp.seven.com> Message-ID: <86fww21mkn.fsf@seastrom.com> "George Bonser" writes: >> You are to be commended for your leadership in conserving space. Our >> children will surely be grateful that thanks to your efforts they have >> 99.99999% of IPv6 space left to work with rather than the paltry >> 99.9975% that might have been their inheritance were it not for your >> efforts. Bravo! > > I have a feeling that IP addresses will now be used in ways that people > have not envisioned them being used before. Given a surplus of any > resource, people find creative ways of using it. Which just reinforces the argument that we ought to give people /48s rather than /56es, /60s, or /64s even though those with a failure of imagination may not be able to figure out a reason anyone would need that much space. -r From ben.butler at c2internet.net Tue Oct 19 06:25:49 2010 From: ben.butler at c2internet.net (Ben Butler) Date: Tue, 19 Oct 2010 12:25:49 +0100 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <86fww21mkn.fsf@seastrom.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com><20101018.202020.41637336.sthaug@nethelp.no><86aambhw90.fsf@seastrom.com><5A6D953473350C4B9995546AFE9939EE0B14C38E@RWC-EX1.corp.seven.com> <86fww21mkn.fsf@seastrom.com> Message-ID: Hi, Another way of looking at it would be what would the world population need to be in order to exhaust all of the space v6 based on /48s /56s or /64s per head / household - and is this population number ever going to happen in what time conceivable time frame. Another interesting calculation would be to divide the land mass area by that population figure - let alone the habital area. 2 to 48 = 281,474,976,710,658 or 280K Billion separate /48s assignments. (Current world population 6.7 Billion forecast 14 Billion in 2100) World Landmass (Total All Areas): 148.94 million sq km So Each Person at the point of IPv6 exhaustion will have 0.53 sq meters to stand on while using all their IPv6 devices. I think it is safe to say that the world will be facing other more significant problems long long long before we get anywhere near having to worry about running out of IPv6 space because we are assigning each individual a /48. There are surely technical benefits from a routing perspective if all the end user assignments are the same size - therefore should the technical considerations here not override any argument about conservation of space seeing as the above hopefully proves the fallacy of needing to conserve IPv6 address space???? Ben -----Original Message----- From: Robert E. Seastrom [mailto:rs at seastrom.com] Sent: 19 October 2010 11:53 To: George Bonser Cc: nanog at nanog.org Subject: Re: Definitive Guide to IPv6 adoption "George Bonser" writes: >> You are to be commended for your leadership in conserving space. Our >> children will surely be grateful that thanks to your efforts they have >> 99.99999% of IPv6 space left to work with rather than the paltry >> 99.9975% that might have been their inheritance were it not for your >> efforts. Bravo! > > I have a feeling that IP addresses will now be used in ways that people > have not envisioned them being used before. Given a surplus of any > resource, people find creative ways of using it. Which just reinforces the argument that we ought to give people /48s rather than /56es, /60s, or /64s even though those with a failure of imagination may not be able to figure out a reason anyone would need that much space. -r -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. From ler762 at gmail.com Tue Oct 19 06:30:00 2010 From: ler762 at gmail.com (Lee) Date: Tue, 19 Oct 2010 07:30:00 -0400 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <3699102B-01D5-40CA-83F9-FA3072B8E810@delong.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <4CBCA9BB.8000202@brightok.net> <3699102B-01D5-40CA-83F9-FA3072B8E810@delong.com> Message-ID: On 10/19/10, Owen DeLong wrote: > > On Oct 18, 2010, at 1:10 PM, Jack Bates wrote: > >> On 10/18/2010 1:20 PM, sthaug at nethelp.no wrote: >>> >>> I still haven't seen any good argument for why residential users need >>> /48s. No, I don't think "that makes all the address assignments the >>> same size" is a particularly relevant or convincing argument. >>> >>> We're doing /56 for residential users, and have no plans to change >>> this. >> >> +1 >> >> This not only makes pop assignments easier, it gives a much larger prefix >> rotation pool. Don't start the flame on rotating prefixes being evil. It's >> my implementation to at least give customers some chance at prefix >> privacy. >> > > What if your customers don't want prefix privacy and prefer, instead, to > have the option of accessing their resources remotely, setting up mobile-IP > home gateways, and any of the other functions that come from static > prefixes? Why does it have to be one or the other? Isn't it possible to hand out a static assignment so that users can access their resources remotely as well as handing out a rotating prefix that changes every so often so that users have 'some chance at prefix privacy.' Lee From ben.butler at c2internet.net Tue Oct 19 06:47:58 2010 From: ben.butler at c2internet.net (Ben Butler) Date: Tue, 19 Oct 2010 12:47:58 +0100 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <02dd01cb6ee2$5ac0a530$1041ef90$@net><4CBC7B6E.6000409@bogus.com><20101018.202020.41637336.sthaug@nethelp.no><86aambhw90.fsf@seastrom.com><5A6D953473350C4B9995546AFE9939EE0B14C38E@RWC-EX1.corp.seven.com><86fww21mkn.fsf@seastrom.com> Message-ID: Hi, Maybe we should reserve the first couple of bits to serve as a planet identifier, so that once we have colonized the heavens Star Trek Federation style we can route to all of those Billions of life forms. Routing convergence times shouldn?t be too much of an issue even with light version 1 (while we wait for FTL transport mechanisms) as I suspect there wont be too many interplanetary transit providers to have worry about in the routing mesh. But again in all seriousness - surely this is a problem for the distant future (sadly and Stephen Hawking would agree about our species' need for colonization to ensure survival) and in the meantime we just get on as quickly as possible with getting IPv6 rolled out and adhering to standards of how we do it so we don't create yet another inconsistent mess with everyone following different "standard" best practices. Ben -----Original Message----- From: Ben Butler [mailto:ben.butler at c2internet.net] Sent: 19 October 2010 12:26 To: nanog at nanog.org Subject: RE: Definitive Guide to IPv6 adoption Hi, Another way of looking at it would be what would the world population need to be in order to exhaust all of the space v6 based on /48s /56s or /64s per head / household - and is this population number ever going to happen in what time conceivable time frame. Another interesting calculation would be to divide the land mass area by that population figure - let alone the habital area. 2 to 48 = 281,474,976,710,658 or 280K Billion separate /48s assignments. (Current world population 6.7 Billion forecast 14 Billion in 2100) World Landmass (Total All Areas): 148.94 million sq km So Each Person at the point of IPv6 exhaustion will have 0.53 sq meters to stand on while using all their IPv6 devices. I think it is safe to say that the world will be facing other more significant problems long long long before we get anywhere near having to worry about running out of IPv6 space because we are assigning each individual a /48. There are surely technical benefits from a routing perspective if all the end user assignments are the same size - therefore should the technical considerations here not override any argument about conservation of space seeing as the above hopefully proves the fallacy of needing to conserve IPv6 address space???? Ben -----Original Message----- From: Robert E. Seastrom [mailto:rs at seastrom.com] Sent: 19 October 2010 11:53 To: George Bonser Cc: nanog at nanog.org Subject: Re: Definitive Guide to IPv6 adoption "George Bonser" writes: >> You are to be commended for your leadership in conserving space. Our >> children will surely be grateful that thanks to your efforts they have >> 99.99999% of IPv6 space left to work with rather than the paltry >> 99.9975% that might have been their inheritance were it not for your >> efforts. Bravo! > > I have a feeling that IP addresses will now be used in ways that people > have not envisioned them being used before. Given a surplus of any > resource, people find creative ways of using it. Which just reinforces the argument that we ought to give people /48s rather than /56es, /60s, or /64s even though those with a failure of imagination may not be able to figure out a reason anyone would need that much space. -r -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. From lists at quux.de Tue Oct 19 06:49:10 2010 From: lists at quux.de (Jens Link) Date: Tue, 19 Oct 2010 13:49:10 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <84764.1287438364@localhost> (Valdis Kletnieks's message of "Mon, 18 Oct 2010 17:46:04 -0400") References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> Message-ID: <87iq0yqu6h.fsf@oban.berlin.quux.de> Valdis.Kletnieks at vt.edu writes: > Those people are next on my hit list, after we've finally eliminated those > who still talk about class A/B/C addresses. :) You are going to kill about 90% of all net-/sysadmins? SCNR Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From dot at dotat.at Tue Oct 19 07:21:45 2010 From: dot at dotat.at (Tony Finch) Date: Tue, 19 Oct 2010 13:21:45 +0100 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <9C7FBB46-097A-4134-A2B6-772733280234@delong.com> References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> <9C7FBB46-097A-4134-A2B6-772733280234@delong.com> Message-ID: On Tue, 19 Oct 2010, Owen DeLong wrote: > > There are advantages to being able to use 16 bits to build various forms > of hierarchical topology on a dynamic basis within a SOHO environment. > If we reduce that to 8 bits, we will block innovations that are > currently underway in this space. Can you give us some examples of these innovations that are currently underway? Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From pica8.org at gmail.com Tue Oct 19 07:33:37 2010 From: pica8.org at gmail.com (Lin Pica8) Date: Tue, 19 Oct 2010 14:33:37 +0200 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: References: Message-ID: Hello, To have a better overview of a Cloud (or OpenFlow) Switch, I would greatly appreciate to invite you to a further reading of the presentation entitled "FI technologies on cloud computing and trusty networking" from our partner, Chunghwa Telecom (Leading ISP in Taiwan) : http://www.asiafi.net/meeting/2010/summerschool/p/chu.pdf Mail : pica8.org at gmail.com 2010/10/18 Lin Pica8 : > Hello, > > We are starting to distribute Pica8 Open Source Cloud Switches : > > http://www.pica8.com/ > > Especially, a Pica8 Switch with the following specifications > (including Open Source Firmware) : > > -HW : 48x1Gbps + 4x10 Gbps > > -Firmware : ?L2/L3 management for VLAN, LACP, STP/RSTP, LLDP, OSPF, > RIP, static route, PIM-SM, VRRP, IGMP, IGMP Snooping, IPv6, > Radius/Tacacs+ as well as OpenFlow 1.0 > > would compete with a Cisco Catalyst 2960-S, Model WS-C2960S-48TD-L for > half the price (~2k USD). > > Mail : pica8.org at gmail.com > From lists at internetpolicyagency.com Tue Oct 19 07:38:53 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Tue, 19 Oct 2010 13:38:53 +0100 Subject: network name 101100010100110.net In-Reply-To: <201010190123.o9J1Njra013666@mail.r-bonomi.com> References: <201010190123.o9J1Njra013666@mail.r-bonomi.com> Message-ID: In article <201010190123.o9J1Njra013666 at mail.r-bonomi.com>, Robert Bonomi writes >Not to mention the fact that the company was originally _named_ >"Minnesota Mining & Manufacturing", and that '3M' was *just* a >logo and trademark. I recall that in the UK, before Nominet deregulated the name space, it was forbidden to have a domain name which wasn't virtually identical to your company name. Product names and trademarks weren't allowed. The example used at the time was "you can have kelloggs.co.uk, but not cornflakes.co.uk". 3m.co.uk wasn't registered until 1997 (a year after Nominet's birth). -- Roland Perry From netfortius at gmail.com Tue Oct 19 07:42:22 2010 From: netfortius at gmail.com (Stefan) Date: Tue, 19 Oct 2010 07:42:22 -0500 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <20101019022737.1fed70a6@opy.nosense.org> References: <4CBC3BC9.7070803@foobar.org> <20101019022737.1fed70a6@opy.nosense.org> Message-ID: On Mon, Oct 18, 2010 at 10:57 AM, Mark Smith wrote: > On Mon, 18 Oct 2010 13:21:29 +0100 > Nick Hilliard wrote: > >> On 18/10/2010 12:25, Lin Pica8 wrote: >> > We are starting to distribute Pica8 Open Source Cloud Switches : >> >> Sounds interesting. ?What chipset does this run on? >> >> Also, what's a cloud switch? ?Is this a switch which forwards L2 traffic, >> or did I miss something? >> > > "Cloud" is the new mainframe i.e. "it's running somewhere else ... " > > > > > > And the Emperor is naked ... ;-) Coming back to the subject of cloud impact, from a network perspective, here is an over-one-year-old recording on the subject (Doug Gourlay's comment: "Cloud could break the Internet if not deployed on capable networks"): http://www.infra20.com/post.cfm/fire-infrastructure-2-0-panel-now-viewable-online#ixzz12o8QYPu1 ***Stefan Mititelu http://twitter.com/netfortius http://www.linkedin.com/in/netfortius From lists at internetpolicyagency.com Tue Oct 19 07:40:49 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Tue, 19 Oct 2010 13:40:49 +0100 Subject: network name 101100010100110.net In-Reply-To: <20101018024021.GC8924@vacation.karoshi.com.?> References: <20101018024021.GC8924@vacation.karoshi.com.?> Message-ID: In article <20101018024021.GC8924 at vacation.karoshi.com.?>, bmanning at vacation.karoshi.com writes > the leading character restriction was lifted when the company > 3com was created. its been nearly 18 years since that advice > held true. And was the first all-numeric name 101.com (1995)? Dalmatians, not binary five. -- Roland Perry From Valdis.Kletnieks at vt.edu Tue Oct 19 08:12:21 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Tue, 19 Oct 2010 09:12:21 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: Your message of "Tue, 19 Oct 2010 13:49:10 +0200." <87iq0yqu6h.fsf@oban.berlin.quux.de> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> Message-ID: <80879.1287493941@localhost> On Tue, 19 Oct 2010 13:49:10 +0200, Jens Link said: > Valdis.Kletnieks at vt.edu writes: > > > Those people are next on my hit list, after we've finally eliminated those > > who still talk about class A/B/C addresses. :) > > You are going to kill about 90% of all net-/sysadmins? Do you *really* want somebody working on your network that gets confused by a reference to 213/8 because it's in Class-C space? Either they haven't taken the 20 minutes it takes to learn how CIDR works, or they're unable to learn it. Either way, they shouldn't be working on your network. And "Cisco is still teaching it" is *not* an excuse - I'd expect a competent network engineer to show enough intellectual curiosity to say "I keep seeing references to 199.14/19, what the heck is that?" Heck, I've had Oracle DBAs ask me about "What's this /22 network mask all about?" and explained it in under 5 minutes. (Hint to Cisco and others - any training course that includes 'Class A/B/C' is likely to be perceived as "dangerously last-century oriented". We had a 3rd-party training class on some Cisco fiberchannel directors, and the instructor mentioned class A/B/C - and immediately lost a whole chunk of credibility, making us wonder what *else* was being mis-taught). Class A/B/C - modern networking's version of a brown M&M backstage at a Van Halen concert. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dwhite at olp.net Tue Oct 19 08:24:30 2010 From: dwhite at olp.net (Dan White) Date: Tue, 19 Oct 2010 08:24:30 -0500 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBD014D.8060408@dougbarton.us> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <4CBD014D.8060408@dougbarton.us> Message-ID: <20101019132430.GA2771@dan.olp.net> On 18/10/10?19:24?-0700, Doug Barton wrote: >On 10/18/2010 5:16 PM, Robert E. Seastrom wrote: >> >>sthaug at nethelp.no writes: >> >>>I still haven't seen any good argument for why residential users need >>>/48s. No, I don't think "that makes all the address assignments the >>>same size" is a particularly relevant or convincing argument. >>> >>>We're doing /56 for residential users, and have no plans to change >>>this. >> >>If we were to give a /48 to every human on the face of the planet, we >>would use about .000025 of the total available IPv6 address space. > >I'm confused. The "hand out /48s everywhere" crowd keeps saying that >we need to do that because we haven't yet anticipated everything that >end users might want to do with a /48 on their CPE. On the wider >issue of "we don't yet understand everything that can be done with >the space" I think we're in agreement. However my conclusion is that >"therefore we should be careful to preserve the maximum flexibility >possible." > >After we have some operational experience with IPv6 we will be in a >position to make better decisions; but we have to GET operational >experience first. Grousing about lack of adherence to holy writ in >that deployment doesn't help anybody. I agree with you, but have come to a different conclusion. I would fall under the /48s crowd, except that I'm not really interested in an attempt to standardize /48 deployments. But I still feel strongly that a /48 assignment model for residential customers is right for our environment. With v4 assignments, we have a different philosophy. When we received our v4 assignments from ARIN, is was natural for us to take a conservative approach when handing out addresses... by default we assign one dynamic address to each customer and provide one or more static addresses for a nominal fee to customers, not because we want to make money from it, but because we want to be good stewards of those addresses. That's our 'fail safe' approach to v4 distribution (1 per customer). With v6, our 'fail safe' approach, without strong operational experience, is to assign larger blocks rather than smaller. A cycle in our staff in 5 or 10 years is likely to appreciate that decision, and we can't really justify a /56-rather-than-/48 decision based on address constraints. We really do have the addresses to support /48 deployments for the foreseeable future, and would expect future staff to request more addresses when they're needed. -- Dan White From jbates at brightok.net Tue Oct 19 09:09:35 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 19 Oct 2010 09:09:35 -0500 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <5D5F72DE-5CA8-4EB9-BEFE-B6C56EA943FB@delong.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <4CBD3267.7070103@brightok.net> <5D5F72DE-5CA8-4EB9-BEFE-B6C56EA943FB@delong.com> Message-ID: <4CBDA69F.1010401@brightok.net> On 10/19/2010 4:29 AM, Owen DeLong wrote: >> > No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger. > ME: I really need larger space ARIN: We don't see how you can justify it, and we hardly ever give larger than /32 THE END > or, if you have larger POPs, start with a /24 and > /32 regional assignment supporting 256 regional assignments > /36 for 16 pops per region > /48 for 4,096 customer end-sites per POP Ideal solution, but don't see it happening > ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space. See above. You think I asked for a /32? While I'd probably desire a /24 for ease of routing and management, I'd only asked for a /31 and was turned down with the "Very few will get more than a /32." Hey, perhaps I'm wrong. Perhaps I asked too early, even though I purposefully delayed asking. and from your other reply: > Yep... Best not to argue with Jack... A much better strategy, IMHO, is to better serve his former customers. Good luck on that. My customers like my service and the lengths we go for them. Obviously, there are always those who are discontent, but we listen to what they want and need, and we make it happen. Feel free to come to rural Oklahoma and compete. The prefix rotation argument has been covered before, which is why I'd rather keep it to the original argument and probably shouldn't have mentioned it since it always creates a side topic. Jack From david.freedman at uk.clara.net Tue Oct 19 09:42:51 2010 From: david.freedman at uk.clara.net (David Freedman) Date: Tue, 19 Oct 2010 15:42:51 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <80879.1287493941@localhost> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> Message-ID: > Do you *really* want somebody working on your network that gets confused by a > reference to 213/8 because it's in Class-C space? Or spots an address which uses letters and colons and looks syntactically incorrect to them? Do you really want untrained people working on your network? -- David Freedman Group Network Engineering Claranet Group From matthew at walster.org Tue Oct 19 09:52:43 2010 From: matthew at walster.org (Matthew Walster) Date: Tue, 19 Oct 2010 15:52:43 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <80879.1287493941@localhost> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> Message-ID: On 19 October 2010 14:12, wrote: > Do you *really* want somebody working on your network that gets confused by a > reference to 213/8 because it's in Class-C space? I've met people who just assume anything with a 24-bit netmask is a Class C network. For instance: "Can I have another Class C out of 83.x please?" No, and neither can anyone else... What's more is that they'll not use .0, .255, .1 (because apparently only routers are supposed to use that), .254 (who knows...) M From Peter.AshwoodSmith at huawei.com Tue Oct 19 10:00:23 2010 From: Peter.AshwoodSmith at huawei.com (Peter Ashwood-Smith) Date: Tue, 19 Oct 2010 11:00:23 -0400 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <20101018224204.GC17339@nudo.bsws.de> Message-ID: <020301cb6f9e$5b66f0e0$ba85c10a@china.huawei.com> Yes "cloud computing" is a vastly overused term that is hard to nail down. That is why I try to get people to use the specific technology term they are talking about. Basically in my world "cloud computing" is the vision of having computation and storage just 'out there' without having to worry about it and just paying for a bit more or less as you go... but its not a "technology". Sometimes it helps to flip the term ... for example "desktop computing" is sort of the inverse .. again its not a "technology" really either... just a broad term but we all kind of know what it means by now, like "laptop computing". There seem to be too major views on technologies to make this "cloud computing" happen. Their view on scale/transparency is considerably different. a) bigger layer 2 networks with Vmware type mobility and no IP address changes. Technolgies in this space are much more than just L2 switching, its L2 switching on larger scales with encapsulation, multipathing etc. This is where technologies like IEEE 802.1aq Shortest Path Bridging, IEEE 802.1ah mac-in-mac come to play. These tend to be appropriate for existing enterprise applications (or complete virtual desktops) and simply make existing DC L2 fabrics bigger and availale for virtualization. No application software changes required, its done under them and end hosts can't tell whats happening. b) All new applications/environments that don't care if their IP address changes and deal with it transparently. In this model you can make an application run anywhere, move it around etc without any special infrastructure .. the smarts are between the application and its hosts. Basically dumb infrastructure and smart applications a.k.a over the top stuff. I suppose the hot movement of one of these applications requires co-ordination by the application itself while if its done below as in a) it can be transparent. So depending on where you sit, generically run something anywhere v.s. run specific things anywhere you end up with slightly different underlying technologies... both with the overused moniker 'cloud'. Ok .. flame away .. ;) Peter From jvanoppen at spectrumnet.us Tue Oct 19 10:15:06 2010 From: jvanoppen at spectrumnet.us (John van Oppen) Date: Tue, 19 Oct 2010 15:15:06 +0000 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> Message-ID: I would say for most of our customers, especially in the hosting space, a "class C" is a /24, they just don't know networking at all and build their hosting lans using /24s for each vlan. Very few of the requests that we get are submitted using CIDR notation. Personally, I think this is a big reason for random table bloat, I have had so many arguments about customers being able to aggregate announcements for BGP it is not even funny... the "I want to announce the blocks as a class Cs" request is irritatingly common. John -----Original Message----- From: Matthew Walster [mailto:matthew at walster.org] Sent: Tuesday, October 19, 2010 7:53 AM To: nanog list Subject: Re: Only 5x IPv4 /8 remaining at IANA On 19 October 2010 14:12, wrote: > Do you *really* want somebody working on your network that gets confused by a > reference to 213/8 because it's in Class-C space? I've met people who just assume anything with a 24-bit netmask is a Class C network. For instance: "Can I have another Class C out of 83.x please?" No, and neither can anyone else... What's more is that they'll not use .0, .255, .1 (because apparently only routers are supposed to use that), .254 (who knows...) M From andyring at inebraska.com Tue Oct 19 10:16:47 2010 From: andyring at inebraska.com (Andy Ringsmuth) Date: Tue, 19 Oct 2010 10:16:47 -0500 Subject: AT&T or AT&T Wireless contact Message-ID: Any chance there's someone buried deep within AT&T or AT&T Wireless that could contact me off-list? Specifically with regards to wireless and caller-ID? I've got an issue I've pursued through several channels and am making zero progress despite assurances to the contrary. --- Andy Ringsmuth (402) 304-0083 andyring at inebraska.com From d3e3e3 at gmail.com Tue Oct 19 10:23:39 2010 From: d3e3e3 at gmail.com (Donald Eastlake) Date: Tue, 19 Oct 2010 11:23:39 -0400 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <020301cb6f9e$5b66f0e0$ba85c10a@china.huawei.com> References: <20101018224204.GC17339@nudo.bsws.de> <020301cb6f9e$5b66f0e0$ba85c10a@china.huawei.com> Message-ID: On Tue, Oct 19, 2010 at 11:00 AM, Peter Ashwood-Smith wrote: > ... > > a) bigger layer 2 networks with Vmware type mobility and no IP address > changes. Technolgies in this space are much more than just L2 switching, its > L2 switching on larger scales with encapsulation, multipathing etc. This is > where technologies like IEEE 802.1aq Shortest Path Bridging, IEEE 802.1ah > mac-in-mac come to play. These tend to be appropriate for existing > enterprise applications (or complete virtual desktops) and simply make > existing DC L2 fabrics bigger and availale for virtualization. No > application software changes required, its done under them and end hosts > can't tell whats happening. And the IETF TRILL protocol. Donald > ... > > Peter From dshaw at jabberwocky.com Tue Oct 19 10:39:06 2010 From: dshaw at jabberwocky.com (David Shaw) Date: Tue, 19 Oct 2010 11:39:06 -0400 Subject: network name 101100010100110.net In-Reply-To: References: <20101018024021.GC8924@vacation.karoshi.com.?> Message-ID: On Oct 19, 2010, at 8:40 AM, Roland Perry wrote: > In article <20101018024021.GC8924 at vacation.karoshi.com.?>, bmanning at vacation.karoshi.com writes > >> the leading character restriction was lifted when the company >> 3com was created. its been nearly 18 years since that advice >> held true. > > And was the first all-numeric name 101.com (1995)? > > Dalmatians, not binary five. I always thought it was 2600.com (03-Feb-1994 according to whois). David From dougb at dougbarton.us Tue Oct 19 11:38:36 2010 From: dougb at dougbarton.us (Doug Barton) Date: Tue, 19 Oct 2010 09:38:36 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <20101019132430.GA2771@dan.olp.net> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <4CBD014D.8060408@dougbarton.us> <20101019132430.GA2771@dan.olp.net> Message-ID: <4CBDC98C.4010008@dougbarton.us> On 10/19/2010 6:24 AM, Dan White wrote: > But I still feel strongly that a /48 assignment model for residential > customers is right for our environment. Perfectly reasonable. If you've analyzed your situation and come to that conclusion who am I to argue? Please note, I'm NOT saying, "You must use /56 for residential!" I'm saying that reasonable minds can differ, and that trying to jam everyone into the /48 mold does more harm than good. Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From mpetach at netflight.com Tue Oct 19 11:47:05 2010 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 19 Oct 2010 09:47:05 -0700 Subject: IPv6 BGP MIB Message-ID: Apologies in advance for the question, as network monitoring is only slightly relevant to network operations... I've been digging and poking and scratching my head, and from what I've been able to find, there doesn't seem to be an IPv6-aware BGP4 MIB in existence. The closest item I could find was a draft MIB that has already expired: http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-10 It also seems to be missing an identifier for where it would sit within the MIB tree, as noted by this section which just leaves it as "XXX": DESCRIPTION "The MIB module for the BGP-4 protocol. Copyright (C) The IETF Trust (2010). This version of this MIB module is part of RFC XXX; see the RFC itself for full legal notices." -- RFC Editor - replace XXX with RFC number REVISION "201002010000Z" DESCRIPTION "This MIB updates and replaces the BGP MIB defined in RFC 4273." ::= { mib-2 XXX } Does anyone know if there is a working variant of this lurking out there that can be used for tracking IPv6 BGP neighbor information, or is everyone running their v6 networks blindly, as compared to their v4 networks? Any pointers for working or semi-working implementations, especially on Juniper platforms, would be greatly appreciated. Thanks! Matt From heather.schiller at verizonbusiness.com Tue Oct 19 11:53:30 2010 From: heather.schiller at verizonbusiness.com (Schiller, Heather A (HeatherSkanks)) Date: Tue, 19 Oct 2010 16:53:30 +0000 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBCB824.9050905@brightok.net> References: <3041529.15.1287435062708.JavaMail.franck@franck-martins-macbook-pro.local> <4CBCB824.9050905@brightok.net> Message-ID: -----Original Message----- From: Jack Bates [mailto:jbates at brightok.net] Sent: Monday, October 18, 2010 5:12 PM To: Franck Martin Cc: nanog at nanog.org Subject: Re: Definitive Guide to IPv6 adoption On 10/18/2010 3:51 PM, Franck Martin wrote: > So they can't run their own services from home and have to request premium connectivity from you? > > Beside the IPv4 scarcity mentality we have the Telco mentality to fight... > > Happy days still ahead... > Of course they can run their own services at home. How does renumber effect that (outside of poor v6 implementations at this late stage)? v6 is designed to support multiple prefixes and the ability to change from one prefix to another with limited disruption, especially if I give 24 hours to complete the transition. If servers and services can't handle this, I'd say they need to improve, or the customer will need a static allocation, which we may or may not charge for (depending on how automated we make it). A sane default of rotation is appropriate for us, though, and no amount of fighting by anyone will make the Telco think that google or others have the right to track their users. It's unfair for our users who block cookies, do due diligence to not be tracked, and then we throw them to the wolves with a constant trackable prefix. HS: Where customers = spammers? The only folks I have seen ask to do 'address rotation' have either been spammers or copyright monitoring services. I have never seen a request for 'address rotation' to protect a customer from Google. Wouldn't you just tell them not to use Google's services? The *typical* residential user doesn't know and probably doesn't care whether their prefix is dynamic or static. Dynamic allocation of address space was, in part, meant to help conserve space - if the prefix was only needed for a couple hours, it could in theory be released and reused... allowing more efficient utilization of space. Now though, with always-on connections and folks wanting to access their content remotely - it makes sense to statically allocate prefixes... and the availability of addresses in IPv6 gives us the room to do this. Jack (knew this would start an argument. *sigh*) From deepak at ai.net Tue Oct 19 12:21:34 2010 From: deepak at ai.net (Deepak Jain) Date: Tue, 19 Oct 2010 13:21:34 -0400 Subject: network name 101100010100110.net In-Reply-To: References: <20101018024021.GC8924@vacation.karoshi.com.?> Message-ID: > On Oct 19, 2010, at 8:40 AM, Roland Perry wrote: > > > In article <20101018024021.GC8924 at vacation.karoshi.com.?>, > bmanning at vacation.karoshi.com writes > > > >> the leading character restriction was lifted when the company > >> 3com was created. its been nearly 18 years since that advice > >> held true. > > > > And was the first all-numeric name 101.com (1995)? > > > > Dalmatians, not binary five. > > I always thought it was 2600.com (03-Feb-1994 according to whois). > I'm assuming we aren't making jokes here, but 3com.com was created in 1986: Domain Name: 3COM.COM Registrar: SAFENAMES LTD Whois Server: whois.safenames.net Referral URL: http://www.safenames.net Name Server: DNS2.IDP365.NET Name Server: NS1.3COM.COM Name Server: NS2.3COM.COM Status: ok Updated Date: 05-oct-2010 Creation Date: 11-dec-1986 Expiration Date: 10-dec-2013 If I've missed the joke, sorry. :) Deepak From nathan at atlasnetworks.us Tue Oct 19 12:24:58 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Tue, 19 Oct 2010 17:24:58 +0000 Subject: network name 101100010100110.net In-Reply-To: References: <20101018024021.GC8924@vacation.karoshi.com.?> Message-ID: <8C26A4FDAE599041A13EB499117D3C28406262FC@ex-mb-2.corp.atlasnetworks.us> > I'm assuming we aren't making jokes here, but 3com.com was created in > 1986: I'm confused. 3com.com would not appear to be entirely numerical. Or maybe someone spiked my coffee this morning. Best Regards, Nathan Eisenberg From ctracy at es.net Tue Oct 19 12:33:36 2010 From: ctracy at es.net (Chris Tracy) Date: Tue, 19 Oct 2010 13:33:36 -0400 Subject: IPv6 BGP MIB In-Reply-To: References: Message-ID: <89DC44C0-57B6-4943-8658-4F30E6A6D4EA@es.net> Hi Matt, > I've been digging and poking and scratching my head, and from what > I've been able to find, there doesn't seem to be an IPv6-aware BGP4 > MIB in existence. The closest item I could find was a draft MIB that > has already expired: http://tools.ietf.org/html/draft-ietf-idr-bgp4-mibv2-10 > ...[snip]... > Does anyone know if there is a working variant of this lurking out there > that can be used for tracking IPv6 BGP neighbor information, or is everyone > running their v6 networks blindly, as compared to their v4 networks? I looked for this about a year ago and my search for a standard largely ended at the I-D you referenced above. However, I did find that Juniper has a proprietary implementation of this draft -- search for mib-jnx-bgpmib2.txt. -Chris -- Chris Tracy Energy Sciences Network (ESnet) Lawrence Berkeley National Laboratory From bmanning at vacation.karoshi.com Tue Oct 19 12:40:09 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Tue, 19 Oct 2010 17:40:09 +0000 Subject: network name 101100010100110.net In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28406262FC@ex-mb-2.corp.atlasnetworks.us> References: <20101018024021.GC8924@vacation.karoshi.com.?> <8C26A4FDAE599041A13EB499117D3C28406262FC@ex-mb-2.corp.atlasnetworks.us> Message-ID: <20101019174009.GA25268@vacation.karoshi.com.> On Tue, Oct 19, 2010 at 05:24:58PM +0000, Nathan Eisenberg wrote: > > I'm assuming we aren't making jokes here, but 3com.com was created in > > 1986: > > I'm confused. 3com.com would not appear to be entirely numerical. Or maybe someone spiked my coffee this morning. > > Best Regards, > Nathan Eisenberg its not. the thread started with a response that claimed that LEADING numerics were illegal per some old RFCs. I commented that 3com.com was the "test case" that caused the relaxation of the original advice. others has since followed up w/ a variety of observations. --bill From owen at delong.com Tue Oct 19 12:51:45 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 10:51:45 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com><20101018.202020.41637336.sthaug@nethelp.no><86aambhw90.fsf@seastrom.com><5A6D953473350C4B9995546AFE9939EE0B14C38E@RWC-EX1.corp.seven.com> <86fww21mkn.fsf@seastrom.com> Message-ID: <57A073C2-1FB6-4895-AA53-0389EED0EE19@delong.com> On Oct 19, 2010, at 4:25 AM, Ben Butler wrote: > Hi, > > Another way of looking at it would be what would the world population need to be in order to exhaust all of the space v6 based on /48s /56s or /64s per head / household - and is this population number ever going to happen in what time conceivable time frame. > > Another interesting calculation would be to divide the land mass area by that population figure - let alone the habital area. > > 2 to 48 = 281,474,976,710,658 or 280K Billion separate /48s assignments. > > (Current world population 6.7 Billion forecast 14 Billion in 2100) > > World Landmass (Total All Areas): 148.94 million sq km > > So Each Person at the point of IPv6 exhaustion will have 0.53 sq meters to stand on while using all their IPv6 devices. > > I think it is safe to say that the world will be facing other more significant problems long long long before we get anywhere near having to worry about running out of IPv6 space because we are assigning each individual a /48. > This does, of course, assume that the population remains earthbound beyond 2100. I think that is not entirely likely. > There are surely technical benefits from a routing perspective if all the end user assignments are the same size - therefore should the technical considerations here not override any argument about conservation of space seeing as the above hopefully proves the fallacy of needing to conserve IPv6 address space???? > Yes... The technical considerations should override silly efforts to keep more than 99.99% of all IPv6 space in reserve for some unprojected need since we have real projected needs for the 0.001% now. Owen > Ben > > > > > -----Original Message----- > From: Robert E. Seastrom [mailto:rs at seastrom.com] > Sent: 19 October 2010 11:53 > To: George Bonser > Cc: nanog at nanog.org > Subject: Re: Definitive Guide to IPv6 adoption > > > "George Bonser" writes: > >>> You are to be commended for your leadership in conserving space. Our >>> children will surely be grateful that thanks to your efforts they have >>> 99.99999% of IPv6 space left to work with rather than the paltry >>> 99.9975% that might have been their inheritance were it not for your >>> efforts. Bravo! >> >> I have a feeling that IP addresses will now be used in ways that people >> have not envisioned them being used before. Given a surplus of any >> resource, people find creative ways of using it. > > Which just reinforces the argument that we ought to give people /48s > rather than /56es, /60s, or /64s even though those with a failure of > imagination may not be able to figure out a reason anyone would need > that much space. > > -r > > > > > > -------------------------------------------------------------------------- > BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} > Ben Butler > Director Tel: 0333 666 3332 > Fax: 0333 666 3331 > C2 Business Networking Ltd > The Paddock, London Road, Nantwich, Cheshire, CW5 7JL > http://www.c2internet.net/ > > Part of the Atlas Business Group of Companies plc > Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 > This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. > > > From owen at delong.com Tue Oct 19 13:03:30 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 11:03:30 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <1778891850.11261.1287420469464.JavaMail.root@zimbra.network1.net> <4CBC7CD9.8050506@brightok.net> <73010009-A52E-42B8-93D2-CDA1F9547F86@delong.com> <9C7FBB46-097A-4134-A2B6-772733280234@delong.com> Message-ID: On Oct 19, 2010, at 5:21 AM, Tony Finch wrote: > On Tue, 19 Oct 2010, Owen DeLong wrote: >> >> There are advantages to being able to use 16 bits to build various forms >> of hierarchical topology on a dynamic basis within a SOHO environment. >> If we reduce that to 8 bits, we will block innovations that are >> currently underway in this space. > > Can you give us some examples of these innovations that are currently > underway? > I have, and, Tony Hain does a better job, but, here goes: Imagine any or all of the following possibilities: Sensor networks within appliances with the appliance acting as a router Each home entertainment center is a collection of networked components with a router fronting each center. Kids networks with different filtration and security policies from those used by the adults in the house. Guest wireless networks. Groceries coming with RFID tags that your refrigerator and cabinets can use to identify their contents. A web server embedded in your kitchen router that fronts these networks can be queried from your cell phone while you are at the store to find out what you are running low on in real time. I'm sure there are more, but, these are things that could be done relatively easily with existing technology. Owen From jbates at brightok.net Tue Oct 19 13:10:57 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 19 Oct 2010 13:10:57 -0500 Subject: Definitive Guide to IPv6 adoption In-Reply-To: References: <3041529.15.1287435062708.JavaMail.franck@franck-martins-macbook-pro.local> <4CBCB824.9050905@brightok.net> Message-ID: <4CBDDF31.2090909@brightok.net> On 10/19/2010 11:53 AM, Schiller, Heather A (HeatherSkanks) wrote: > HS: Where customers = spammers? The only folks I have seen ask > to do 'address rotation' have either been spammers or copyright > monitoring services. I have never seen a request for 'address rotation' > to protect a customer from Google. Wouldn't you just tell them not to > use Google's services? The *typical* residential user doesn't know and > probably doesn't care whether their prefix is dynamic or static. > The typical resident often doesn't know, but when asked, they do want privacy, and they don't want to be tracked by various databases for marketing or geoIP tracking. Some customers prefer static, but to date, the only reason customers have asked for static in v4 is because it was necessary. If v6 continues to support application and design for renumbering, such statics won't be necessary and I'll have even fewer requests. > Dynamic allocation of address space was, in part, meant to help > conserve space - if the prefix was only needed for a couple hours, it > could in theory be released and reused... allowing more efficient > utilization of space. Now though, with always-on connections and folks > wanting to access their content remotely - it makes sense to statically > allocate prefixes... and the availability of addresses in IPv6 gives us > the room to do this. With the new capabilities of multiple prefixes and renumbering capabilities and the various methodologies which will be used to easily switch between providers (or balance traffic between multiple providers using multiple prefixes), rotating prefixes every 24 hours shouldn't be a big deal. The customer will still gain remote access to their content, while also remaining a moving target. Customer's care about privacy, even when they don't realize if they truly have it or not. M$ considered privacy extensions on by default to be a good thing. I'm just extending it to the prefix. You can change nic cards as easily as you change ISPs (easier out here, actually). As customers actually notice or care that they are using v6, I'm sure I'll have more static requests as well, which we'll probably automate. Jack From owen at delong.com Tue Oct 19 13:21:28 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 11:21:28 -0700 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4CBDA69F.1010401@brightok.net> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <4CBD3267.7070103@brightok.net> <5D5F72DE-5CA8-4EB9-BEFE-B6C56EA943FB@delong.com> <4CBDA69F.1010401@brightok.net> Message-ID: <4DCA91E5-52FB-44B0-BD6E-801270AE4C6C@delong.com> On Oct 19, 2010, at 7:09 AM, Jack Bates wrote: > On 10/19/2010 4:29 AM, Owen DeLong wrote: >>> >> No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for larger. >> > > ME: I really need larger space > ARIN: We don't see how you can justify it, and we hardly ever give larger than /32 > Did you send them a customer count exceeding about 25,000 customers and point out that you were giving /48s to each of them? If you did, they would not have had a leg to stand on. However, there has been a bit of a learning curve with ARIN staff and IPv6, so, there have been some errant denials. I'm working on policy to further expand their ability to approve larger allocations. Expect to see it posted in the next week or so. > THE END > >> or, if you have larger POPs, start with a /24 and >> /32 regional assignment supporting 256 regional assignments >> /36 for 16 pops per region >> /48 for 4,096 customer end-sites per POP > > Ideal solution, but don't see it happening > Why not? >> ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs have received larger than /32 and all you need to do is show a reasonable justification for the space. > > See above. You think I asked for a /32? While I'd probably desire a /24 for ease of routing and management, I'd only asked for a /31 and was turned down with the "Very few will get more than a /32." > When did you ask? If it was more than 6 months ago, then, I would suggest asking again. If it was less than 6 months ago, can you send me any or all of the correspondence so I can address it with Leslie and try and get whatever training issues remain resolved? > Hey, perhaps I'm wrong. Perhaps I asked too early, even though I purposefully delayed asking. > If ARIN is incorrectly denying requests, I'll definitely work on getting that resolved. > and from your other reply: > >> Yep... Best not to argue with Jack... A much better strategy, IMHO, is to better serve his former customers. > > Good luck on that. My customers like my service and the lengths we go for them. Obviously, there are always those who are discontent, but we listen to what they want and need, and we make it happen. Feel free to come to rural Oklahoma and compete. The prefix rotation argument has been covered before, which is why I'd rather keep it to the original argument and probably shouldn't have mentioned it since it always creates a side topic. > The beauty is that we don't have to come to rural OK to compete. We can just let them use whatever stingy amount of address space you provide to get a tunnel to us. Owen From franck at genius.com Tue Oct 19 13:30:40 2010 From: franck at genius.com (Franck Martin) Date: Wed, 20 Oct 2010 06:30:40 +1200 (FJT) Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: Message-ID: <7143471.382.1287513038403.JavaMail.franck@franck-martins-macbook-pro.local> No, no.... Putting your servers on IPv6 is a major task. Load balancers, proprietary code, log analysis, database records... all that needs to be reviewed to see if it is compatible with IPv6 (and a few equipments need recent upgrades if even they can do IPv6 today). Putting your client machines (ie internal network) to IPv6 is relatively easy. Enable IPv6 on the border router, you don't need failover (can built it later) as anyhow the clients will failover to IPv4 if IPv6 fails... So as failover is not needed you can have a separate simple IPv6 network infrastructure on top of your IPv4 Infrastructure. So my advocacy, is get your client (I'm not talking about customers here, but client as client/server) machines on IPv6, get your engineers, support staff,.. to be familiar with IPv6, then all together you can better understand how to migrate your servers infrastructure to IPv6 (and your customers to IPv6 if you are an ISP). If you do that, you will see migration to IPv6 is made much easier, and much faster. ----- Original Message ----- From: "Owen DeLong" To: "Franck Martin" Cc: "Jonas Frey (Probe Networks)" , "Jeffrey Lyon" , "NANOG list" Sent: Tuesday, 19 October, 2010 8:55:56 PM Subject: Re: Only 5x IPv4 /8 remaining at IANA Servers work just fine over tunnels if necessary too. Get your public-facing content and services on IPv6 as fast as possible. Make IPv6 available to your customers as quickly as possible too. Finally, your internal IT resources (other than your support department(s)) can probably wait a little while. Owen On Oct 18, 2010, at 1:41 PM, Franck Martin wrote: From jbates at brightok.net Tue Oct 19 13:37:15 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 19 Oct 2010 13:37:15 -0500 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4DCA91E5-52FB-44B0-BD6E-801270AE4C6C@delong.com> References: <02dd01cb6ee2$5ac0a530$1041ef90$@net> <4CBC7B6E.6000409@bogus.com> <20101018.202020.41637336.sthaug@nethelp.no> <86aambhw90.fsf@seastrom.com> <4CBD3267.7070103@brightok.net> <5D5F72DE-5CA8-4EB9-BEFE-B6C56EA943FB@delong.com> <4CBDA69F.1010401@brightok.net> <4DCA91E5-52FB-44B0-BD6E-801270AE4C6C@delong.com> Message-ID: <4CBDE55B.3080902@brightok.net> On 10/19/2010 1:21 PM, Owen DeLong wrote: > When did you ask? If it was more than 6 months ago, then, I would suggest asking again. If it was less than 6 > months ago, can you send me any or all of the correspondence so I can address it with Leslie and try and > get whatever training issues remain resolved? > RegDate: 2009-01-16 Haven't read anything on changes in the announcements, except the "we're sending this to PPML (think that's right?)", but no announcement on a change of opinion/policy. I have enough mailing lists. > If ARIN is incorrectly denying requests, I'll definitely work on getting that resolved. > We'll see. I've asked for a do-over, or whatever they called it. /24 seemed a bit much, so I slimmed down to /27, thinking it more appropriate for a 5 year plan (which is what they asked). > The beauty is that we don't have to come to rural OK to compete. We can just let them use whatever stingy amount > of address space you provide to get a tunnel to us. Sure they'll love the latency. I know I currently do with the mess that is core routing. Anyone who would actually care, probably would request a static, which we are much more lenient with IPv6 than IPv4. However, I can't issue /48 to everyone as things stand. We'll see how it goes with ARIN, now that I know I can ask again and not go through the hassle for nothing. Jack From owen at delong.com Tue Oct 19 14:00:01 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Oct 2010 12:00:01 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <7143471.382.1287513038403.JavaMail.franck@franck-martins-macbook-pro.local> References: <7143471.382.1287513038403.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: On Oct 19, 2010, at 11:30 AM, Franck Martin wrote: > No, no.... > > Putting your servers on IPv6 is a major task. Load balancers, proprietary code, log analysis, database records... all that needs to be reviewed to see if it is compatible with IPv6 (and a few equipments need recent upgrades if even they can do IPv6 today). > No, it really isn't so bad in most cases. Yes, if you're using load balancers, you need IPv6 capable LB. That's about 90% of the LB market now. Log analysis, yeah, you're going to need to update your parsers, OR, configure your LB to do 6->4 translation. (Of course you lose something in the translation in that case). Yes, you _MAY_ need to update database records, but, most servers don't actually. > Putting your client machines (ie internal network) to IPv6 is relatively easy. Enable IPv6 on the border router, you don't need failover (can built it later) as anyhow the clients will failover to IPv4 if IPv6 fails... So as failover is not needed you can have a separate simple IPv6 network infrastructure on top of your IPv4 Infrastructure. > Depends on your environment, actually. Most IT environments it turns out to be a pretty major challenge, if, for no other reason than the fact that most Firewall/IDS/IPS vendors are terribly lagging in their IPv6 products. > So my advocacy, is get your client (I'm not talking about customers here, but client as client/server) machines on IPv6, get your engineers, support staff,.. to be familiar with IPv6, then all together you can better understand how to migrate your servers infrastructure to IPv6 (and your customers to IPv6 if you are an ISP). > We can agree to disagree. I have found that it is far more important (and generally easier) to get your servers on to IPv6 so that when the first IPv6-only eyeballs start to emerge (approximately June, 2011, btw), you're able to serve those customers without having to limit them to LSN/CGN/NAT64/etc. access to your services. > If you do that, you will see migration to IPv6 is made much easier, and much faster. > Hasn't been my experience doing a number of IPv6 migrations. Owen > ----- Original Message ----- > From: "Owen DeLong" > To: "Franck Martin" > Cc: "Jonas Frey (Probe Networks)" , "Jeffrey Lyon" , "NANOG list" > Sent: Tuesday, 19 October, 2010 8:55:56 PM > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > Servers work just fine over tunnels if necessary too. > > Get your public-facing content and services on IPv6 as fast as possible. > Make IPv6 available to your customers as quickly as possible too. > > Finally, your internal IT resources (other than your support department(s)) can > probably wait a little while. > > Owen > > On Oct 18, 2010, at 1:41 PM, Franck Martin wrote: From zaid at zaidali.com Tue Oct 19 14:27:14 2010 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 19 Oct 2010 12:27:14 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <7143471.382.1287513038403.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: If you run Cisco ACE load balancers and start with your web server farm I can assure you that you will be stuck because ACE loaad balancers do not support v6 and don't plan to until mid next year and not without a new card/cost. If you run ACE in non routed mode then you a doubly stuck because you can't even by bypass the loadbalancer to reach one of your webservers since the ACE doesn't pass v6 traffic! So I agree, don't start there instead get the corporate LAN, learn from it then move onto your production facing networks. Also get white listed for Google NS so you can see more user traffic. Zaid On 10/19/10 11:30 AM, "Franck Martin" wrote: > No, no.... > > Putting your servers on IPv6 is a major task. Load balancers, proprietary > code, log analysis, database records... all that needs to be reviewed to see > if it is compatible with IPv6 (and a few equipments need recent upgrades if > even they can do IPv6 today). > > Putting your client machines (ie internal network) to IPv6 is relatively easy. > Enable IPv6 on the border router, you don't need failover (can built it later) > as anyhow the clients will failover to IPv4 if IPv6 fails... So as failover is > not needed you can have a separate simple IPv6 network infrastructure on top > of your IPv4 Infrastructure. > > So my advocacy, is get your client (I'm not talking about customers here, but > client as client/server) machines on IPv6, get your engineers, support > staff,.. to be familiar with IPv6, then all together you can better understand > how to migrate your servers infrastructure to IPv6 (and your customers to IPv6 > if you are an ISP). > > If you do that, you will see migration to IPv6 is made much easier, and much > faster. > > ----- Original Message ----- > From: "Owen DeLong" > To: "Franck Martin" > Cc: "Jonas Frey (Probe Networks)" , "Jeffrey Lyon" > , "NANOG list" > Sent: Tuesday, 19 October, 2010 8:55:56 PM > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > Servers work just fine over tunnels if necessary too. > > Get your public-facing content and services on IPv6 as fast as possible. > Make IPv6 available to your customers as quickly as possible too. > > Finally, your internal IT resources (other than your support department(s)) > can > probably wait a little while. > > Owen > > On Oct 18, 2010, at 1:41 PM, Franck Martin wrote: > > From jbates at brightok.net Tue Oct 19 14:29:34 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 19 Oct 2010 14:29:34 -0500 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: Message-ID: <4CBDF19E.6000004@brightok.net> On 10/19/2010 2:27 PM, Zaid Ali wrote: > If you run Cisco ACE load balancers and start with your web server farm I > can assure you that you will be stuck because ACE loaad balancers do not That's not the only product with issues. As previously discussed on list, there's also issues with DR support for v6 in a variety of v6 ready load balancers. Shifting from DR to NAT is an undertaking and often not desired. We have a long ways to go. Jack From hj1980 at gmail.com Tue Oct 19 14:35:26 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 19 Oct 2010 20:35:26 +0100 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: References: Message-ID: > We are starting to distribute Pica8 Open Source Cloud Switches : > http://www.pica8.com/ Seeing as you claim they are opensource, could you please point to the documentation of the hardware? Specifically, I am looking for information regarding the FPGA/ASIC's used for forwarding & circuit diagrams. Cheers Heath From hj1980 at gmail.com Tue Oct 19 14:41:31 2010 From: hj1980 at gmail.com (Heath Jones) Date: Tue, 19 Oct 2010 20:41:31 +0100 Subject: Pica8 - Open Source Cloud Switch In-Reply-To: <201010181620.o9IGK09V098786@aurora.sol.net> References: <201010181620.o9IGK09V098786@aurora.sol.net> Message-ID: > We have dedicated servers. ?You get a 10 GHz 24-core CPU with 1TB of > RAM. ?That's pretty clear and familiar to server geeks. Is that 10 as in Ten? From kevin at steadfast.net Tue Oct 19 14:55:42 2010 From: kevin at steadfast.net (Kevin Stange) Date: Tue, 19 Oct 2010 14:55:42 -0500 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> Message-ID: <4CBDF7BE.8060502@steadfast.net> On 10/19/2010 10:15 AM, John van Oppen wrote: > I would say for most of our customers, especially in the hosting space, a "class C" is a /24, they just don't know networking at all and build their hosting lans using /24s for each vlan. > > Very few of the requests that we get are submitted using CIDR notation. Personally, I think this is a big reason for random table bloat, I have had so many arguments about customers being able to aggregate announcements for BGP it is not even funny... the "I want to announce the blocks as a class Cs" request is irritatingly common. It's been our general policy to always respond in CIDR notation whenever we get a request in class notation and to hope that our customers either figure out what that means on their own or ask us for clarification and learn something. IPv6 is helping because a lot of people seem to be making the connection that the "slash" notation is related between the two. -- Kevin Stange Chief Technology Officer Steadfast Networks http://steadfast.net Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 261 bytes Desc: OpenPGP digital signature URL: From andre.edwards at gmail.com Tue Oct 19 14:57:42 2010 From: andre.edwards at gmail.com (=?ISO-8859-1?Q?Andr=E9_Edwards?=) Date: Tue, 19 Oct 2010 15:57:42 -0400 Subject: Caribbean Network Operators Group 2nd Regional Gathering in St Lucia Oct 31st to Nov 3rd 2010 Message-ID: *Dear Colleagues, members of the Nanog Community and CaribNOG* Supporters, The Caribbean Network Operators Group (CARIBNOG) has the pleasure of announcing and inviting you to participate in the second 2nd Regional CaribNOG meeting, CARIBNOG 2, from Sunday October 31st ? Wednesday November 3rd, 2010 in St. Lucia. The 3 day event is being jointly hosted by the Caribbean Telecommunications Union and the Government of St Lucia. *CaribNOG* meetings place heavy emphasis on building Caribbean technical capacity by providing targeted training facilitated by industry experts. At the same time these gatherings afford participants a unique forum for exchanging ideas, sharing experiences and building the relationships so essential to creating a truly regional technical community. *CaribNOG 2* will build on the content of the inaugural meeting and offer a more in-depth treatment of Routing, LINUX and VoIP. The meeting will also continue to promote: 1) the establishment of CSIRTs at the national and regional level; 2) greater technical understanding of Internet Exchange Points; and 3) regional awareness of and participation in groups such as ISOC, ARIN, LACNIC and ICANN. Admission to the meeting will be free of charge and open Internet Service Providers, Network Administrators, Computer Engineers, Technology Researchers and ICT Consultants and other interested stakeholders. This allows regional ICT practitioners a unique opportunity to benefit from the expertise of some of the top minds in the industry. *Location*: Bay Gardens Inn, Rodney Bay, Castries http://www.baygardenshotel.com/ Interested participants who are unfamiliar with the tropical paradise of St Lucia are invited to visit www.stlucia.org *CARIBNOG 2 Agenda*: http://www.caribnog.org/caribnog2/agenda-2/ *Registration* is available on the CARIBNOG website at this link: http://www.caribnog.org/caribnog2/registration/ Regards, _______________________ Andre Edwards CARIBNOG 2 Program Committee Email: andre.edwards at gmail.com Web: http://www.caribnog.org Facebook: http://www.facebook.com/pages/Caribnog/143643545668920?ref=ts From lists at quux.de Tue Oct 19 15:24:02 2010 From: lists at quux.de (Jens Link) Date: Tue, 19 Oct 2010 22:24:02 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <80879.1287493941@localhost> (Valdis Kletnieks's message of "Tue, 19 Oct 2010 09:12:21 -0400") References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> Message-ID: <877hhehqxp.fsf@oban.berlin.quux.de> Valdis.Kletnieks at vt.edu writes: >> You are going to kill about 90% of all net-/sysadmins? > > Do you *really* want somebody working on your network that gets confused by a > reference to 213/8 because it's in Class-C space? Don't get me wrong. I like the idea. Especially after the discussion I had with someone this afternoon. > And "Cisco is still teaching it" is *not* an excuse Windows and Linux ifconfig are still using it. Enter a Class-A/B/C address and take a look at the mask they suggest. Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From jgreco at ns.sol.net Tue Oct 19 15:46:37 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Tue, 19 Oct 2010 15:46:37 -0500 (CDT) Subject: Pica8 - Open Source Cloud Switch In-Reply-To: Message-ID: <201010192046.o9JKkbtT020485@aurora.sol.net> > > We have dedicated servers. ?You get a 10 GHz 24-core CPU with 1TB of > > RAM. ?That's pretty clear and familiar to server geeks. > > Is that 10 as in Ten? Yes. It's not meant to be quite "real", it's meant as an example that any server geek ought to be able to figure out what sort of power that represents compared to a given task. ... 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 randy at psg.com Tue Oct 19 15:49:25 2010 From: randy at psg.com (Randy Bush) Date: Tue, 19 Oct 2010 13:49:25 -0700 Subject: abha Message-ID: nine years From marka at isc.org Tue Oct 19 16:37:31 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 20 Oct 2010 08:37:31 +1100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: Your message of "Tue, 19 Oct 2010 12:27:14 PDT." References: Message-ID: <20101019213732.0631F5E9382@drugs.dv.isc.org> In message , Zaid Ali writes: > If you run Cisco ACE load balancers and start with your web server farm I > can assure you that you will be stuck because ACE loaad balancers do not > support v6 and don't plan to until mid next year and not without a new > card/cost. So stick a router in parallel and just route IPv6 over it. So stick in a IPv6->IPv4 proxy and send that traffic through the load balancer. > If you run ACE in non routed mode then you a doubly stuck because > you can't even by bypass the loadbalancer to reach one of your webservers > since the ACE doesn't pass v6 traffic! So I agree, don't start there instead > get the corporate LAN, learn from it then move onto your production facing > networks. Also get white listed for Google NS so you can see more user > traffic. > > Zaid > > > On 10/19/10 11:30 AM, "Franck Martin" wrote: > > > No, no.... > > > > Putting your servers on IPv6 is a major task. Load balancers, proprietary > > code, log analysis, database records... all that needs to be reviewed to se > e > > if it is compatible with IPv6 (and a few equipments need recent upgrades if > > even they can do IPv6 today). > > > > Putting your client machines (ie internal network) to IPv6 is relatively ea > sy. > > Enable IPv6 on the border router, you don't need failover (can built it lat > er) > > as anyhow the clients will failover to IPv4 if IPv6 fails... So as failover > is > > not needed you can have a separate simple IPv6 network infrastructure on to > p > > of your IPv4 Infrastructure. > > > > So my advocacy, is get your client (I'm not talking about customers here, b > ut > > client as client/server) machines on IPv6, get your engineers, support > > staff,.. to be familiar with IPv6, then all together you can better underst > and > > how to migrate your servers infrastructure to IPv6 (and your customers to I > Pv6 > > if you are an ISP). > > > > If you do that, you will see migration to IPv6 is made much easier, and muc > h > > faster. > > > > ----- Original Message ----- > > From: "Owen DeLong" > > To: "Franck Martin" > > Cc: "Jonas Frey (Probe Networks)" , "Jeffrey Lyon" > > , "NANOG list" > > Sent: Tuesday, 19 October, 2010 8:55:56 PM > > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > > > Servers work just fine over tunnels if necessary too. > > > > Get your public-facing content and services on IPv6 as fast as possible. > > Make IPv6 available to your customers as quickly as possible too. > > > > Finally, your internal IT resources (other than your support department(s)) > > can > > probably wait a little while. > > > > Owen > > > > On Oct 18, 2010, at 1:41 PM, Franck Martin wrote: > > > > > > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From DLasher at newedgenetworks.com Tue Oct 19 16:38:30 2010 From: DLasher at newedgenetworks.com (Lasher, Donn) Date: Tue, 19 Oct 2010 14:38:30 -0700 Subject: abha In-Reply-To: References: Message-ID: Still missed....worth sharing the still-working links... http://www.afnog.org/abha_ahuja_bursary/ http://rathe.mur.com/~kobi/abha/ http://www.mur.com/~kobi/abhaold/ http://www.neebu.net/~khuon/abha/ http://gallery.tch.org/main.php?g2_itemId=1951 http://www.nanog.org/scholarships/abha.php -----Original Message----- From: Randy Bush [mailto:randy at psg.com] Subject: abha nine years From zaid at zaidali.com Tue Oct 19 16:53:21 2010 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 19 Oct 2010 14:53:21 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101019213732.0631F5E9382@drugs.dv.isc.org> Message-ID: On 10/19/10 2:37 PM, "Mark Andrews" wrote: > > So stick a router in parallel and just route IPv6 over it. > So stick in a IPv6->IPv4 proxy and send that traffic through the > load balancer. Nah considering v6 traffic is small I have a simpler solution, I prefer to set up a temporary web service running v6 native outside LB's and offer experimental service, that way I can keep yelling at Vendors to get their act together because if they don't hear user requests then v6 will not be a priority for them. The last thing you want to go is build a kluge and stay silent. Zaid From marka at isc.org Tue Oct 19 17:58:21 2010 From: marka at isc.org (Mark Andrews) Date: Wed, 20 Oct 2010 09:58:21 +1100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: Your message of "Tue, 19 Oct 2010 14:53:21 PDT." References: Message-ID: <20101019225821.D042F5E95BF@drugs.dv.isc.org> In message , Zaid Ali writes: > > On 10/19/10 2:37 PM, "Mark Andrews" wrote: > > > > So stick a router in parallel and just route IPv6 over it. > > So stick in a IPv6->IPv4 proxy and send that traffic through the > > load balancer. > > Nah considering v6 traffic is small I have a simpler solution, I prefer to > set up a temporary web service running v6 native outside LB's and offer > experimental service, that way I can keep yelling at Vendors to get their > act together because if they don't hear user requests then v6 will not be a > priority for them. The last thing you want to go is build a kluge and stay > silent. > > Zaid I wasn't saying don't complain. Adding is seperate IPv6 server is a work around and runs the risk of being overloaded. A proxy should be able to handle a much bigger load as it is just shuffling bits. You should be able to just turn on the IPv6 interfaces on your existing web servers and have them service request over IPv4 and IPv6. That way it doesn't matter about which transport the client picked, they get the same level of service. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From zaid at zaidali.com Tue Oct 19 18:25:12 2010 From: zaid at zaidali.com (Zaid Ali) Date: Tue, 19 Oct 2010 16:25:12 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101019225821.D042F5E95BF@drugs.dv.isc.org> Message-ID: On 10/19/10 3:58 PM, "Mark Andrews" wrote: > Adding is seperate IPv6 server is a work around and runs the risk > of being overloaded. And what a wonderful problem to have! You can show a CFO a nice cacti graph of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A CFO will never act unless there is a real business problem. There are some of us here who have management with clue but there are many that don't, sadly this is the majority and a large contributor to the slow adoption of IPv6. Zaid From mpetach at netflight.com Tue Oct 19 18:48:49 2010 From: mpetach at netflight.com (Matthew Petach) Date: Tue, 19 Oct 2010 16:48:49 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <20101019225821.D042F5E95BF@drugs.dv.isc.org> Message-ID: On Tue, Oct 19, 2010 at 4:25 PM, Zaid Ali wrote: > On 10/19/10 3:58 PM, "Mark Andrews" wrote: >> Adding is seperate IPv6 server is a work around and runs the risk >> of being overloaded. > > And what a wonderful problem to have! You can show a CFO a nice cacti graph > of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A > CFO will never act unless there is a real business problem. There are some > of us here who have management with clue but there are many that don't, > sadly this is the majority and a large contributor to the slow adoption of > IPv6. > > Zaid I fully expect to see information about IPv6 readiness start becoming a required item on quarterly SEC filings for publicly owned companies that depend on additional IP space being available in order to grow their business. In light of the recent financial meltdowns, and post-Enron SOx compliance requirements, no public company is going to want to face charges that they knowingly mislead their shareholders about the future viability of their company, and of their stock, if they based their business growth around the availability of IPv4 addresses, knowing that supply was on the verge of running out. I'll wager that within 18 months, if you're at a publicly traded company, your CFO will be coming to *you* (or your IP administrator) on a quarterly basis to validate the viability of your IP address plan before signing off on the SEC filings and annual audits of the company, to make sure they're not the ones holding the bag in case the company suddenly can't sign on any new customers. Matt From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Oct 19 19:05:11 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 20 Oct 2010 10:35:11 +1030 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <20101019225821.D042F5E95BF@drugs.dv.isc.org> Message-ID: <20101020103511.0ff2c4d2@opy.nosense.org> On Tue, 19 Oct 2010 16:25:12 -0700 Zaid Ali wrote: > > On 10/19/10 3:58 PM, "Mark Andrews" wrote: > > > Adding is seperate IPv6 server is a work around and runs the risk > > of being overloaded. > > And what a wonderful problem to have! You can show a CFO a nice cacti graph > of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A > CFO will never act unless there is a real business problem. When did CFOs run the company? If you're taking this decision to C level management, the CIO, CTO or the CEO should be the ones making the decision. They direct where money goes, not the CFO. The easy business case for IPv6 is insurance. At some point in the relatively near future there may be content or services that are only available over IPv6. Investing in IPv6 deployment now is insurance against not being able to access that content when you may need to in the future. Do your management want to miss out on being able to access the next IPv6-only Google, Salesforce.com, etc., when it is critical to the business? Somebody in the organisation will have responsibility for ensuring continued and reliable access to services the company needs, and if that includes Internet access, then IPv6 is going to become an essential part of that continued and reliable Internet access. > There are some > of us here who have management with clue but there are many that don't, > sadly this is the majority and a large contributor to the slow adoption of > IPv6. > > Zaid > > > From nanog at studio442.com.au Tue Oct 19 19:18:55 2010 From: nanog at studio442.com.au (Julien Goodwin) Date: Wed, 20 Oct 2010 11:18:55 +1100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> Message-ID: <4CBE356F.7090707@studio442.com.au> On 20/10/10 01:52, Matthew Walster wrote: > No, and neither can anyone else... What's more is that they'll not use > .0, .255, .1 (because apparently only routers are supposed to use > that), .254 (who knows...) There's actually a good reason for that. MS Windows (at least 2k3 server) will simply drop packets with a source address of .0 or .255 coming from the legacy class C space, this hit us with some Win 2k3 servers that for a bunch of stupid reasons needed to be connected to from natted hosts, and the next pool IP off the pile was a .255 address somewhere in 192.168.0.0/16. Took quite a while to diagnose as wireshark on the host wouldn't see the packet, but eventually we could verify the packet made it all the way to the machine. The fact that this may be UI in 2010 is very depressing, and a prime example of why there's no way the "class-E" space will ever be generally usable. Julien From cb.list6 at gmail.com Tue Oct 19 19:33:27 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Tue, 19 Oct 2010 17:33:27 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101020103511.0ff2c4d2@opy.nosense.org> References: <20101019225821.D042F5E95BF@drugs.dv.isc.org> <20101020103511.0ff2c4d2@opy.nosense.org> Message-ID: On Tue, Oct 19, 2010 at 5:05 PM, Mark Smith wrote: > On Tue, 19 Oct 2010 16:25:12 -0700 > Zaid Ali wrote: > >> >> On 10/19/10 3:58 PM, "Mark Andrews" wrote: >> >> > Adding is seperate IPv6 server is a work around and runs the risk >> > of being overloaded. >> >> And what a wonderful problem to have! You can show a CFO a nice cacti graph >> of IPv6 growth so you can justify him/her to sign off on IPv6 expenses. A >> CFO will never act unless there is a real business problem. > > When did CFOs run the company? If you're taking this decision to C > level management, the CIO, CTO or the CEO should be the ones making the > decision. They direct where money goes, not the CFO. > True. But, i will say, at my employer, the CFO does control the corporate risk management group that oversees the business continuity strategy. Without IP addresses, we can't grow the business, and that's a problem. So, the CFO is a stake holder where i work. Along the lines of IPv6 for business continuity, i usually point people to this ARIN link which is very official and makes it clear the IPv4 addresses are running out, there is a risk to manage. The CFO tries to make sure the money we spend is spent wisely, IPv6 does not directly drive new revenues, but it does diffuse the IP exhaust crisis. It's simply about business continuity. That is something all the CxOs can understand clearly. https://www.arin.net/knowledge/about_resources/ceo_letter.pdf > The easy business case for IPv6 is insurance. At some point in the > relatively near future there may be content or services that are only > available over IPv6. Investing in IPv6 deployment now is insurance > against not being able to access that content when you may need to in > the future. Do your management want to miss out on being able to > access the next IPv6-only Google, Salesforce.com, etc., when it is > critical to the business? Somebody in the organisation will have > responsibility for ensuring continued and reliable access to services > the company needs, and if that includes Internet access, then IPv6 is > going to become an essential part of that continued and reliable > Internet access. > Agreed. But, I'll flip it around on you. Same idea, but many mobile eyeballs are going IPv6-only. If you are a content provider and you want to make sure people can see your website, then you will want to be on IPv6. >> There are some >> of us here who have management with clue but there are many that don't, >> sadly this is the majority and a large contributor to the slow adoption of >> IPv6. It's the old story, pay a little now to have an IPv6 plan and get the wheels moving. Or, be caught flat footed, and pay a lot later in forklift upgrades and lost customers. Cameron ====== http://groups.google.com/group/tmoipv6beta ====== From leslien at arin.net Tue Oct 19 20:59:24 2010 From: leslien at arin.net (Leslie Nobile) Date: Tue, 19 Oct 2010 21:59:24 -0400 Subject: Definitive Guide to IPv6 adoption In-Reply-To: <4DCA91E5-52FB-44B0-BD6E-801270AE4C6C@delong.com> Message-ID: Quick FYI - ARIN has a documented appeals process that an organization can use if they believe that ARIN staff did not follow community-established policies in the review of their resource request. Here is the link: https://www.arin.net/resources/resource_requests/appeal_process.html Regards, Leslie Leslie Nobile Director, Registration Services American Registry for Internet Numbers On 10/19/10 2:21 PM, "Owen DeLong" wrote: > > On Oct 19, 2010, at 7:09 AM, Jack Bates wrote: > >> On 10/19/2010 4:29 AM, Owen DeLong wrote: >>>> >>> No... ARIN hands out a MINIMUM /32. A medium sized ISP should be asking for >>> larger. >>> >> >> ME: I really need larger space >> ARIN: We don't see how you can justify it, and we hardly ever give larger >> than /32 >> > Did you send them a customer count exceeding about 25,000 customers and point > out that > you were giving /48s to each of them? If you did, they would not have had a > leg to stand on. > > However, there has been a bit of a learning curve with ARIN staff and IPv6, > so, there have > been some errant denials. I'm working on policy to further expand their > ability to approve > larger allocations. Expect to see it posted in the next week or so. > >> THE END >> >>> or, if you have larger POPs, start with a /24 and >>> /32 regional assignment supporting 256 regional assignments >>> /36 for 16 pops per region >>> /48 for 4,096 customer end-sites per POP >> >> Ideal solution, but don't see it happening >> > Why not? > >>> ARIN thinks a /32 is the MINIMUM for an ISP. Not the Maximum. Several ISPs >>> have received larger than /32 and all you need to do is show a reasonable >>> justification for the space. >> >> See above. You think I asked for a /32? While I'd probably desire a /24 for >> ease of routing and management, I'd only asked for a /31 and was turned down >> with the "Very few will get more than a /32." >> > When did you ask? If it was more than 6 months ago, then, I would suggest > asking again. If it was less than 6 > months ago, can you send me any or all of the correspondence so I can address > it with Leslie and try and > get whatever training issues remain resolved? > >> Hey, perhaps I'm wrong. Perhaps I asked too early, even though I purposefully >> delayed asking. >> > If ARIN is incorrectly denying requests, I'll definitely work on getting that > resolved. > >> and from your other reply: >> >>> Yep... Best not to argue with Jack... A much better strategy, IMHO, is to >>> better serve his former customers. >> >> Good luck on that. My customers like my service and the lengths we go for >> them. Obviously, there are always those who are discontent, but we listen to >> what they want and need, and we make it happen. Feel free to come to rural >> Oklahoma and compete. The prefix rotation argument has been covered before, >> which is why I'd rather keep it to the original argument and probably >> shouldn't have mentioned it since it always creates a side topic. >> > The beauty is that we don't have to come to rural OK to compete. We can just > let them use whatever stingy amount > of address space you provide to get a tunnel to us. > > Owen > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Oct 19 23:20:24 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 20 Oct 2010 14:50:24 +1030 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C36B@RWC-EX1.corp.seven.com> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <37C8B453-0361-43E6-9001-861CD51FB196@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C36B@RWC-EX1.corp.seven.com> Message-ID: <20101020145024.50f81996@opy.nosense.org> On Mon, 18 Oct 2010 11:41:09 -0700 "George Bonser" wrote: > > > > > You are confusing SI with Packet Filters. The technologies are > > different > > and it is, also, important to understand this distinction as well. > > I don't think I am "confusing" the two. I am saying that I have seen > people use them and think they are secure when they aren't. IPv6 is > going to make it a little harder for people to make this mistake (or > easier to make it, I haven't decided yet which way it will go) and you > will see more people purchasing equipment that does real state > inspection which is my reason for predicting an increase in firewall > sales. They won't have that dynamic NAT that lulls some into a false > sense of security. > > Also, I believe the "fire suit" approach will become more important to > people rather than the "fire wall" approach with IPv6. > That's a great way of saying "host based security". With mobile Internet devices (smart phones, laptops (which outsold desktops last year apparently) etc.) becoming the dominant Internet access device, I think host based firewalling will become the primary "firewalling" mechanism. Network located firewalls will perform a secondary and assistant role, because hosts can't be sure they're there when the hosts have wired, wifi, bluetooth etc. interfaces that can all be actively connected to the Internet at the same time. Regards, Mark. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Oct 19 23:24:18 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 20 Oct 2010 14:54:18 +1030 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <877hhehqxp.fsf@oban.berlin.quux.de> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de> Message-ID: <20101020145418.69f12048@opy.nosense.org> On Tue, 19 Oct 2010 22:24:02 +0200 Jens Link wrote: > Valdis.Kletnieks at vt.edu writes: > > >> You are going to kill about 90% of all net-/sysadmins? > > > > Do you *really* want somebody working on your network that gets confused by a > > reference to 213/8 because it's in Class-C space? > > Don't get me wrong. I like the idea. Especially after the discussion I had > with someone this afternoon. > > > And "Cisco is still teaching it" is *not* an excuse > > Windows and Linux ifconfig are still using it. Enter a Class-A/B/C > address and take a look at the mask they suggest. > Under Linux, ifconfig is probably deprecated, and just being left around for people who're used to it. iproute2 a.k.a. the 'ip' utility is the way to access/configure far more of the IP stack settings under linux. Regards, Mark. From ryan.finnesey at HarrierInvestments.com Tue Oct 19 23:54:53 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 19 Oct 2010 21:54:53 -0700 Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: <6EFFEFBAC68377459A2E972105C759EC030F32BD@EXVBE005-2.exch005intermedia.net> I do not know much about their sales tactics but I can say I used them years ago for a project and had no technical problems. Cheers Ryan -----Original Message----- From: seph [mailto:seph at directionless.org] Sent: Monday, October 18, 2010 12:03 PM To: Subject: Re: Enterprise DNS providers I haven't used UltraDNS, but given some of their unsavory sales tactics, I'm pretty biased against them. They spend awhile spamming people, and calling up CTOs. seph Jeffrey Lyon writes: > We're using Afilias now, we had nothing short of a horrendous > experience dealing with Neustar / UltraDNS and their uninformed, blood > hungry sales team. > > Best regards, Jeff > > > On Mon, Oct 18, 2010 at 9:23 AM, Jonas Bj?rklund wrote: >> >> On Sat, 16 Oct 2010, Ken Gilmour wrote: >> >>> Hello any weekend workers :) >>> >>> We are looking at urgently deploying an outsourced DNS provider for >>> a critical domain which is currently unavailable but are having some >>> difficulty. I've tried contacting UltraDNS who only allow customers >>> from US / Canada to sign up (we are in Malta) and their Sales dept >>> are closed, and Easy DNS who don't have .com.mt as an option in the >>> dropdown for transferring domain names (and also support is closed). >> >> I have worked for one of the biggest poker networks and we used UltraDNS. >> The company was first operated from Sweden and later Austria. >> >> /Jonas >> >> > > > > -- > 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 ryan.finnesey at HarrierInvestments.com Tue Oct 19 23:54:53 2010 From: ryan.finnesey at HarrierInvestments.com (Ryan Finnesey) Date: Tue, 19 Oct 2010 21:54:53 -0700 Subject: Enterprise DNS providers In-Reply-To: References: Message-ID: <6EFFEFBAC68377459A2E972105C759EC030F32BE@EXVBE005-2.exch005intermedia.net> Maybe this is a new business opportunity. What do "Enterprise" DNS providers change? Cheers Ryan -----Original Message----- From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] Sent: Monday, October 18, 2010 1:30 PM To: seph Cc: nanog at nanog.org Subject: Re: Enterprise DNS providers Working with a previous client about 1.5 years ago, we asked Dyn and UltraDNS to send proposals over. UltraDNS was 3x the Dyn quote, and we were satisfied from personal experience with Dyn before. When I explained to the UltraDNS rep why we went with Dyn, they said "Oh, I thought you were looking for an enterprise provide". Another vendor I don't plan on ever using (or even considering) again. On Mon, Oct 18, 2010 at 11:03 AM, seph wrote: > I haven't used UltraDNS, but given some of their unsavory sales > tactics, I'm pretty biased against them. They spend awhile spamming > people, and calling up CTOs. > > seph > > Jeffrey Lyon writes: > > > We're using Afilias now, we had nothing short of a horrendous > > experience dealing with Neustar / UltraDNS and their uninformed, > > blood hungry sales team. > > > > Best regards, Jeff > > > > > > On Mon, Oct 18, 2010 at 9:23 AM, Jonas Bj?rklund > > > wrote: > >> > >> On Sat, 16 Oct 2010, Ken Gilmour wrote: > >> > >>> Hello any weekend workers :) > >>> > >>> We are looking at urgently deploying an outsourced DNS provider > >>> for a critical domain which is currently unavailable but are > >>> having some difficulty. I've tried contacting UltraDNS who only > >>> allow customers > from > >>> US > >>> / Canada to sign up (we are in Malta) and their Sales dept are > >>> closed, > and > >>> Easy DNS who don't have .com.mt as an option in the dropdown for > >>> transferring domain names (and also support is closed). > >> > >> I have worked for one of the biggest poker networks and we used > UltraDNS. > >> The company was first operated from Sweden and later Austria. > >> > >> /Jonas > >> > >> > > > > > > > > -- > > Jeffrey Lyon, Leadership Team > > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus > > Communications - AS32421 First and Leading in DDoS Protection > > Solutions > > -- Brandon Galbraith US Voice: 630.492.0464 From joelja at bogus.com Wed Oct 20 00:01:48 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Tue, 19 Oct 2010 22:01:48 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101020145418.69f12048@opy.nosense.org> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de> <20101020145418.69f12048@opy.nosense.org> Message-ID: <4CBE77BC.2050501@bogus.com> On 10/19/10 9:24 PM, Mark Smith wrote: > On Tue, 19 Oct 2010 22:24:02 +0200 > Jens Link wrote: > >> Valdis.Kletnieks at vt.edu writes: >> >>>> You are going to kill about 90% of all net-/sysadmins? >>> >>> Do you *really* want somebody working on your network that gets confused by a >>> reference to 213/8 because it's in Class-C space? >> >> Don't get me wrong. I like the idea. Especially after the discussion I had >> with someone this afternoon. >> >>> And "Cisco is still teaching it" is *not* an excuse >> >> Windows and Linux ifconfig are still using it. Enter a Class-A/B/C >> address and take a look at the mask they suggest. Of course ifconfig will also happily take whatever mask you feed it in your choice of notation so it's not exactly a bronze age tool. > > Under Linux, ifconfig is probably deprecated, and just being left > around for people who're used to it. iproute2 a.k.a. the 'ip' utility > is the way to access/configure far more of the IP stack settings under > linux. > > Regards, > Mark. > From bmanning at vacation.karoshi.com Wed Oct 20 00:17:04 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 20 Oct 2010 05:17:04 +0000 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: <4CBE77BC.2050501@bogus.com> References: <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de> <20101020145418.69f12048@opy.nosense.org> <4CBE77BC.2050501@bogus.com> Message-ID: <20101020051704.GB27873@vacation.karoshi.com.> On Tue, Oct 19, 2010 at 10:01:48PM -0700, Joel Jaeggli wrote: > > Of course ifconfig will also happily take whatever mask you feed it in > your choice of notation so it's not exactly a bronze age tool. > > first - IPv6 isn't 5x IPv4, its only 4x... :) and the idea f "bronze-age" tools is generally appealing. I'm tempted to make the argument that when we are fulling using the IPv4 space, we make the general statement that the "Internet" is fully deployed. IPv4 == the Internet. IPv6 == the next big thing... to borrow a phrase - the polyphonic-net IPv4 has many decades of work, refinement, and general ammalgamation into/with what many/most of us are comfortable with wrt business models. IPv6 - while it has just over a decade of work, still has a long way to go to fulfill its promise. For the oldtimers, remember that it took IP a couple of decades to "gel" at version 4. Sure, we can (and in some cases - MUST) cram the "Internet" model on IPv6, but that is a genuine waste of opportunity. So ... can we let an IPv6-based "polyphonic-net" embrace, and subsume the old, last century Internet? Or is that asking too much of the sales/marketing droids? --bill manning From jeffrey.lyon at blacklotus.net Wed Oct 20 01:03:13 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Wed, 20 Oct 2010 10:33:13 +0430 Subject: Enterprise DNS providers In-Reply-To: <6EFFEFBAC68377459A2E972105C759EC030F32BE@EXVBE005-2.exch005intermedia.net> References: <6EFFEFBAC68377459A2E972105C759EC030F32BE@EXVBE005-2.exch005intermedia.net> Message-ID: It depends on the provider. Some are decently priced. Neustar / UltraDNS is exponentially more expensive than their equally capable competitors. I've seen they're pricing at $50 - 500 per 1M queries, depending on how bad you are at negotiating. You'll need to spend at least a few thousand per month to get below the $100 per 1M. Pretty much everyone else is < $100 per 1M with much lower commits. My major beef with Neustar, outside of stupid high pricing, is that they changed the way all of their services were billed back in early 2009 and then arbitrarily applied the new overage calculations to existing accounts, resulting in thousands of dollars in overage to the account I had with them at the time. Their ethically questionable sales staff used this as an opportunity to force an upgrade in order to accommodate a "courtesy" fee waiver. We're using Afilias now and the difference has been night and day. Best regards, Jeff On Wed, Oct 20, 2010 at 9:24 AM, Ryan Finnesey wrote: > Maybe this is a new business opportunity. ?What do "Enterprise" DNS providers change? > Cheers > Ryan > > > -----Original Message----- > From: Brandon Galbraith [mailto:brandon.galbraith at gmail.com] > Sent: Monday, October 18, 2010 1:30 PM > To: seph > Cc: nanog at nanog.org > Subject: Re: Enterprise DNS providers > > Working with a previous client about 1.5 years ago, we asked Dyn and UltraDNS to send proposals over. UltraDNS was 3x the Dyn quote, and we were satisfied from personal experience with Dyn before. When I explained to the UltraDNS rep why we went with Dyn, they said "Oh, I thought you were looking for an enterprise provide". Another vendor I don't plan on ever using (or even considering) again. > > On Mon, Oct 18, 2010 at 11:03 AM, seph wrote: > >> I haven't used UltraDNS, but given some of their unsavory sales >> tactics, I'm pretty biased against them. They spend awhile spamming >> people, and calling up CTOs. >> >> seph >> >> Jeffrey Lyon writes: >> >> > We're using Afilias now, we had nothing short of a horrendous >> > experience dealing with Neustar / UltraDNS and their uninformed, >> > blood hungry sales team. >> > >> > Best regards, Jeff >> > >> > >> > On Mon, Oct 18, 2010 at 9:23 AM, Jonas Bj?rklund >> > >> wrote: >> >> >> >> On Sat, 16 Oct 2010, Ken Gilmour wrote: >> >> >> >>> Hello any weekend workers :) >> >>> >> >>> We are looking at urgently deploying an outsourced DNS provider >> >>> for a critical domain which is currently unavailable but are >> >>> having some difficulty. I've tried contacting UltraDNS who only >> >>> allow customers >> from >> >>> US >> >>> / Canada to sign up (we are in Malta) and their Sales dept are >> >>> closed, >> and >> >>> Easy DNS who don't have .com.mt as an option in the dropdown for >> >>> transferring domain names (and also support is closed). >> >> >> >> I have worked for one of the biggest poker networks and we used >> UltraDNS. >> >> The company was first operated from Sweden and later Austria. >> >> >> >> /Jonas >> >> >> >> >> > >> > >> > >> > -- >> > Jeffrey Lyon, Leadership Team >> > jeffrey.lyon at blacklotus.net | http://www.blacklotus.net Black Lotus >> > Communications - AS32421 First and Leading in DDoS Protection >> > Solutions >> >> > > > -- > Brandon Galbraith > US Voice: 630.492.0464 > -- 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 gordslater at ieee.org Wed Oct 20 01:32:10 2010 From: gordslater at ieee.org (gordon b slater) Date: Wed, 20 Oct 2010 07:32:10 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBE356F.7090707@studio442.com.au> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> <4CBE356F.7090707@studio442.com.au> Message-ID: <1287556330.27978.93.camel@ub-g-d2> On Wed, 2010-10-20 at 11:18 +1100, Julien Goodwin wrote: > MS Windows (at least 2k3 server) will simply drop packets with a > source > address of .0 or .255 coming from the legacy class C space, this hit > us > with some Win 2k3 servers that for a bunch of stupid reasons needed to > be connected to from natted hosts, and the next pool IP off the pile > was > a .255 address somewhere in 192.168.0.0/16. Took quite a while to thanks for explaining the reason for a total waste of 3 hours of my life recently, on a /22 in my case, after a large-scale merger of 1918's I had to replace it with a netinst + Postfix install to get stuff moving again. Did MS understand classless in '03? do they now? From gbonser at seven.com Wed Oct 20 01:37:50 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 19 Oct 2010 23:37:50 -0700 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: <20101020051704.GB27873@vacation.karoshi.com.> References: <20101018153551.GA28093@nudo.bsws.de><5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com><84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de><80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de><20101020145418.69f12048@opy.nosense.org><4CBE77BC.2050501@bogus.com> <20101020051704.GB27873@vacation.karoshi.com.> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C3BB@RWC-EX1.corp.seven.com> > -----Original Message----- > > IPv6 - while it has just over a decade of work, still has a long > way > to go to fulfill its promise. For the oldtimers, remember that it > took > IP a couple of decades to "gel" at version 4. Sure, we can (and > in > some cases - MUST) cram the "Internet" model on IPv6, but that is > a > genuine waste of opportunity. > > > So ... can we let an IPv6-based "polyphonic-net" embrace, and > subsume > the old, last century Internet? Or is that asking too much of > the > sales/marketing droids? Most of the problems I have seen with v6 really aren't v6 problems. Programs and their various libraries, for example, that parse an address with a colon as a hostname is one example. Now I could even work around that by populating the local default dns domain with records that resolve to AAAA records ... if I could put a colon in a hostname (e.g. someone enters fe80::1e:dead:beef:cafe, the program looks up fe80::1e:dead:beef:cafe.my.local-domain rather than trying to connect to fe80:1e:dead:beef:cafe and dns returns with the AAAA record, that problem fixed, but I can't, so it isn't.) And even that would only work for a few commonly accessed hosts. Programs that rely on multicast will be a little different but that can be handled in dual-stack, at least in the local internal net. Now the problems with things like load balancing is real. Our vendor supports front end v6 VIPs balanced to backend v4 servers, but it requires a code update that must be tested before deployment and an outage scheduled once it has been tested. It isn't something that can just be thrown out there on a whim. The biggest cultural change is coming out of RFC1918 dungeons into the light of internet routable space and how people deal with that. It will be a very interesting time for networks, their vendors, and the engineers/techs/administrators. From owen at delong.com Wed Oct 20 02:16:20 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Oct 2010 00:16:20 -0700 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C3BB@RWC-EX1.corp.seven.com> References: <20101018153551.GA28093@nudo.bsws.de><5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com><84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de><80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de><20101020145418.69f12048@opy.nosense.org><4CBE77BC.2050501@bogus.com> <20101020051704.GB27873@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C3BB@RWC-EX1.corp.seven.com> Message-ID: <8D07B04F-825E-4EC4-9068-D8767839A1A0@delong.com> On Oct 19, 2010, at 11:37 PM, George Bonser wrote: > > >> -----Original Message----- >> >> IPv6 - while it has just over a decade of work, still has a long >> way >> to go to fulfill its promise. For the oldtimers, remember that > it >> took >> IP a couple of decades to "gel" at version 4. Sure, we can (and >> in >> some cases - MUST) cram the "Internet" model on IPv6, but that > is >> a >> genuine waste of opportunity. >> >> >> So ... can we let an IPv6-based "polyphonic-net" embrace, and >> subsume >> the old, last century Internet? Or is that asking too much of >> the >> sales/marketing droids? > > Most of the problems I have seen with v6 really aren't v6 problems. > Programs and their various libraries, for example, that parse an address > with a colon as a hostname is one example. Now I could even work around > that by populating the local default dns domain with records that > resolve to AAAA records ... if I could put a colon in a hostname (e.g. > someone enters fe80::1e:dead:beef:cafe, the program looks up > fe80::1e:dead:beef:cafe.my.local-domain rather than trying to connect to > fe80:1e:dead:beef:cafe and dns returns with the AAAA record, that > problem fixed, but I can't, so it isn't.) And even that would only work > for a few commonly accessed hosts. > Most likely a program that parses a : as a host name indicator wouldn't be able to handle the return of an AAAA record anyway. There are code changes required for IPv6 support and it is unlikely that any software which has been thus updated would have the problem you describe. > > Now the problems with things like load balancing is real. Our vendor > supports front end v6 VIPs balanced to backend v4 servers, but it > requires a code update that must be tested before deployment and an > outage scheduled once it has been tested. It isn't something that can > just be thrown out there on a whim. > Sure, it lies somewhere between whim and major undertaking. Where on that path depends on the quality of your vendors' support for IPv6 and how early you start planning. > The biggest cultural change is coming out of RFC1918 dungeons into the > light of internet routable space and how people deal with that. It will > be a very interesting time for networks, their vendors, and the > engineers/techs/administrators. > The light is good. Yes, it requires some adaptation if you've been living in the darkness of 1918 space for some time, but, once you adapt (and the adaptation is not that painful), it's actually a very useful thing. Owen From gbonser at seven.com Wed Oct 20 02:29:47 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 20 Oct 2010 00:29:47 -0700 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: <8D07B04F-825E-4EC4-9068-D8767839A1A0@delong.com> References: <20101018153551.GA28093@nudo.bsws.de><5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com><84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de><80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de><20101020145418.69f12048@opy.nosense.org><4CBE77BC.2050501@bogus.com> <20101020051704.GB27873@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C3BB@RWC-EX1.corp.seven.com> <8D07B04F-825E-4EC4-9068-D8767839A1A0@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C3BD@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Owen DeLong > Sent: Wednesday, October 20, 2010 12:16 AM > To: George Bonser > Subject: Re: Only 5x IPv4 ... WRONG! :) > > > On Oct 19, 2010, at 11:37 PM, George Bonser wrote: > Sure, it lies somewhere between whim and major undertaking. > Where on that path depends on the quality of your vendors' support > for IPv6 and how early you start planning. Even that really isn't a v6 issue so much as other changes that are often tossed in when a vendor issues a new release. Sometimes commands are deprecated, new features added, old features might clash with new ones, or features behave in slightly different ways in a new release. Sometimes the entire command syntax will change and any automation that has been done to manage/generate configurations needs to change. Again, those aren't really v6 issues, just the other odds and ends that surround upgrading stuff in order to get the needed v6 support than can impact an operation in unexpected ways. The point being that it can turn into a can of worms when you simply need the v6 feature on a bunch of stuff (hey, ever been through migrating to 8.3 Cisco ASA configuration changes?) Then there's other odds and ends like DAD not working on Ubuntu kernel 2.6.32-24-server #41 but it worked fine on 2.6.32-24-server #39 (machine responds to its own DAD probes and reports any IP you attempt to program as being "in use"). So you want to solve just one problem ... just get IPv6 on the darned net, and pretty soon you have a half-dozen projects blocking deployment. It isn't "easy" but it isn't the fault of "v6" in most cases. From gbonser at seven.com Wed Oct 20 04:09:37 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 20 Oct 2010 02:09:37 -0700 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C3BD@RWC-EX1.corp.seven.com> References: <20101018153551.GA28093@nudo.bsws.de><5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com><84764.1287438364@localhost><87iq0yqu6h.fsf@oban.berlin.quux.de><80879.1287493941@localhost><877hhehqxp.fsf@oban.berlin.quux.de><20101020145418.69f12048@opy.nosense.org><4CBE77BC.2050501@bogus.com><20101020051704.GB27873@vacation.karoshi.com.><5A6D953473350C4B9995546AFE9939EE0B14C3BB@RWC-EX1.corp.seven.com><8D07B04F-825E-4EC4-9068-D8767839A1A0@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C3BD@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C3C1@RWC-EX1.corp.seven.com> > -----Original Message----- > From: George Bonser > Sent: Wednesday, October 20, 2010 12:30 AM > To: Owen DeLong > Cc: nanog at nanog.org > Subject: RE: Only 5x IPv4 ... WRONG! :) > > It isn't "easy" but it isn't the fault of "v6" in most cases. > Put another way, the set of challenges facing the enterprise/production operator (the people who use that network to facilitate the delivery of a product ... either on the transmitting or receiving end of that delivery) is quite different from the set of challenges that face a pure network operator. And what seems so easy for one may not be so easy for the other. Dual stacking network gear is less of a problem than dual stacking hundreds or thousands of servers, special purpose appliances, software, etc. of different vendors, ages, and complexity. From owen at delong.com Wed Oct 20 04:49:49 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Oct 2010 02:49:49 -0700 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C3C1@RWC-EX1.corp.seven.com> References: <20101018153551.GA28093@nudo.bsws.de><5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com><84764.1287438364@localhost><87iq0yqu6h.fsf@oban.berlin.quux.de><80879.1287493941@localhost><877hhehqxp.fsf@oban.berlin.quux.de><20101020145418.69f12048@opy.nosense.org><4CBE77BC.2050501@bogus.com><20101020051704.GB27873@vacation.karoshi.com.><5A6D953473350C4B9995546AFE9939EE0B14C3BB@RWC-EX1.corp.seven.com><8D07B04F-825E-4EC4-9068-D8767839A1A0@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C3BD@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C3C1@RWC-EX1.corp.seven.com> Message-ID: On Oct 20, 2010, at 2:09 AM, George Bonser wrote: > > >> -----Original Message----- >> From: George Bonser >> Sent: Wednesday, October 20, 2010 12:30 AM >> To: Owen DeLong >> Cc: nanog at nanog.org >> Subject: RE: Only 5x IPv4 ... WRONG! :) >> >> It isn't "easy" but it isn't the fault of "v6" in most cases. >> > > Put another way, the set of challenges facing the enterprise/production > operator (the people who use that network to facilitate the delivery of > a product ... either on the transmitting or receiving end of that > delivery) is quite different from the set of challenges that face a pure > network operator. And what seems so easy for one may not be so easy for > the other. > > Dual stacking network gear is less of a problem than dual stacking > hundreds or thousands of servers, special purpose appliances, software, > etc. of different vendors, ages, and complexity. > I'm not sure why you assume that network operators don't have hundreds or thousands of servers, special purpose appliances, software, etc. of different vendors, ages, and complexity. Yes, it's easier to dual-stack the backbone of an ISP than the entire enterprise of an ISP. That's no surprise since dual-stacking the backbone of an enterprise would be easier than dual-stacking the entire enterprise as well. However, other than some very limited exceptions, HE has dual-stacked their entire enterprise, not just their backbone. All of our public facing servers are fully dual-stacked with published AAAA records. Our customers can freely run IPv4, IPv6, or both on our managed servers and/or their own equipment in our colos. All of our IP connectivity clients have access to dual-stack services, and, we actually provide economic incentives for customers to do dual-stack rather than IPv4 only connections to us. Migrating from IPv4 to dual stack isn't going to get significantly easier by procrastinating at this point. It's only going to get more urgent. Doing something hard on a schedule is hard. Doing something hard in a rush because you failed to schedule it is harder. Owen From matthew at walster.org Wed Oct 20 05:07:35 2010 From: matthew at walster.org (Matthew Walster) Date: Wed, 20 Oct 2010 11:07:35 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBE34CF.5010607@studio442.com.au> References: <4CBC3328.7090205@unfix.org> <4CBC3734.6090806@prt.org> <4CBC3AA0.9040607@kenweb.org> <4CBC3D59.3010401@xyonet.com> <3D837220-6F32-46CE-899B-D77E23C58455@delong.com> <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> <4CBE34CF.5010607@studio442.com.au> Message-ID: On 20 October 2010 01:16, Julien Goodwin wrote: > MS Windows (at least 2k3 server) will simply drop packets with a source > address of .0 or .255 coming from the legacy class C space, I did say in 83.x, but it's good to know that there are problems with old Class-C addresses. It pains me to type that, it really does :S M From jcurran at arin.net Wed Oct 20 08:34:52 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 09:34:52 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block Message-ID: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> FYI, /John ---- https://www.arin.net/announcements/2010/20101020.html Posted: Wednesday, 20 October 2010 ARIN today recognizes Interop, an organization with a long-standing presence in the Internet industry, for returning its unneeded Internet Protocol version 4 (IPv4) address space. Interop was originally allocated a /8 before ARIN's existence and the availability of smaller-sized address blocks. The organization recently realized it was only using a small portion of its address block and that returning the remainder to ARIN would be for the greater good of the Internet community. ARIN will accept the returned space and not reissue it for a short period, per existing operational procedure. After the hold period, ARIN will follow global policy at that time and return it to the global free pool or distribute the space to those organizations in the ARIN region with documented need, as appropriate. With less than 5% of the IPv4 address space left in the global free pool, ARIN warns that Interop's return will not significantly extend the life of IPv4. ARIN continues to emphasize the need for all Internet stakeholders to adopt the next generation of Internet Protocol, IPv6. Regards, Communications and Member Services American Registry for Internet Numbers From randy at psg.com Wed Oct 20 09:13:15 2010 From: randy at psg.com (Randy Bush) Date: Wed, 20 Oct 2010 07:13:15 -0700 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> Message-ID: i think this is cool, but ... > ARIN will follow global policy at that time and return it to the > global free pool or distribute the space to those organizations in the > ARIN region with documented need, as appropriate. i know the us has the world series, but global > arin region randy From jcurran at arin.net Wed Oct 20 09:20:14 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 10:20:14 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> Message-ID: <63DD1A65-E28E-46A7-AB2B-A76587F9D8A9@arin.net> On Oct 20, 2010, at 10:13 AM, Randy Bush wrote: > i think this is cool, but ... > >> ARIN will follow global policy at that time and return it to the >> global free pool or distribute the space to those organizations in the >> ARIN region with documented need, as appropriate. > > i know the us has the world series, but global > arin region The problem is that we haven't been able to get a global policy for returned address space, i.e. IANA has no policy on how to assign less than full /8's. The first global policy 2009-3 did not reach consensus on the same text in all regions, and 2010-10 is still under discussion. So, there's no way to know if there's a global policy which would allow the space to be returned to the IANA, but I'm optimistic... /John From dot at dotat.at Wed Oct 20 09:22:45 2010 From: dot at dotat.at (Tony Finch) Date: Wed, 20 Oct 2010 15:22:45 +0100 Subject: network name 101100010100110.net In-Reply-To: <8C26A4FDAE599041A13EB499117D3C28406262FC@ex-mb-2.corp.atlasnetworks.us> References: <20101018024021.GC8924@vacation.karoshi.com.?> <8C26A4FDAE599041A13EB499117D3C28406262FC@ex-mb-2.corp.atlasnetworks.us> Message-ID: On Tue, 19 Oct 2010, Nathan Eisenberg wrote: > > I'm assuming we aren't making jokes here, but 3com.com was created in > > 1986: > > I'm confused. 3com.com would not appear to be entirely numerical. Or > maybe someone spiked my coffee this morning. Once leading digits became permitted, the syntax was relaxed to allow all-numeric labels. See RFC 1123. Tony. -- f.anthony.n.finch http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD. From randy at psg.com Wed Oct 20 09:25:08 2010 From: randy at psg.com (Randy Bush) Date: Wed, 20 Oct 2010 07:25:08 -0700 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <63DD1A65-E28E-46A7-AB2B-A76587F9D8A9@arin.net> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <63DD1A65-E28E-46A7-AB2B-A76587F9D8A9@arin.net> Message-ID: >>> ARIN will follow global policy at that time and return it to the >>> global free pool or distribute the space to those organizations in the >>> ARIN region with documented need, as appropriate. >> >> i know the us has the world series, but global > arin region > > The problem is that we haven't been able to get a global policy > for returned address space, i.e. IANA has no policy on how to > assign less than full /8's. The first global policy 2009-3 did > not reach consensus on the same text in all regions, and 2010-10 > is still under discussion. > > So, there's no way to know if there's a global policy which would > allow the space to be returned to the IANA, but I'm optimistic... ahh. my problem. lack of coffee. i missed the "OR." sorry. i would guess iana would take it. randy From nick at foobar.org Wed Oct 20 09:43:06 2010 From: nick at foobar.org (Nick Hilliard) Date: Wed, 20 Oct 2010 15:43:06 +0100 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> Message-ID: <4CBEFFFA.1030002@foobar.org> Thank you Interop - for performing an outstanding act of altruism. John, could you provide more details at this stage on how much address space was returned to ARIN? Nick On 20/10/2010 14:34, John Curran wrote: > FYI, > /John > > ---- > https://www.arin.net/announcements/2010/20101020.html > > > Posted: Wednesday, 20 October 2010 > > ARIN today recognizes Interop, an organization with a long-standing presence in the Internet industry, for returning its unneeded Internet Protocol version 4 (IPv4) address space. > > Interop was originally allocated a /8 before ARIN's existence and the availability of smaller-sized address blocks. The organization recently realized it was only using a small portion of its address block and that returning the remainder to ARIN would be for the greater good of the Internet community. > > ARIN will accept the returned space and not reissue it for a short period, per existing operational procedure. After the hold period, ARIN will follow global policy at that time and return it to the global free pool or distribute the space to those organizations in the ARIN region with documented need, as appropriate. > > With less than 5% of the IPv4 address space left in the global free pool, ARIN warns that Interop's return will not significantly extend the life of IPv4. ARIN continues to emphasize the need for all Internet stakeholders to adopt the next generation of Internet Protocol, IPv6. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers > From joel.esler at me.com Wed Oct 20 10:11:18 2010 From: joel.esler at me.com (Joel Esler) Date: Wed, 20 Oct 2010 11:11:18 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBEFFFA.1030002@foobar.org> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: Now, if we could get everyone that has these gigantic /8's (or multiple of them) that aren't using them to give some back, that'd be great. Thank you interop for setting the example. Joel On Oct 20, 2010, at 10:43 AM, Nick Hilliard wrote: > Thank you Interop - for performing an outstanding act of altruism. > > John, could you provide more details at this stage on how much address space was returned to ARIN? > > Nick > > On 20/10/2010 14:34, John Curran wrote: >> FYI, >> /John >> >> ---- >> https://www.arin.net/announcements/2010/20101020.html >> >> >> Posted: Wednesday, 20 October 2010 >> >> ARIN today recognizes Interop, an organization with a long-standing presence in the Internet industry, for returning its unneeded Internet Protocol version 4 (IPv4) address space. >> >> Interop was originally allocated a /8 before ARIN's existence and the availability of smaller-sized address blocks. The organization recently realized it was only using a small portion of its address block and that returning the remainder to ARIN would be for the greater good of the Internet community. >> >> ARIN will accept the returned space and not reissue it for a short period, per existing operational procedure. After the hold period, ARIN will follow global policy at that time and return it to the global free pool or distribute the space to those organizations in the ARIN region with documented need, as appropriate. >> >> With less than 5% of the IPv4 address space left in the global free pool, ARIN warns that Interop's return will not significantly extend the life of IPv4. ARIN continues to emphasize the need for all Internet stakeholders to adopt the next generation of Internet Protocol, IPv6. >> >> Regards, >> >> Communications and Member Services >> American Registry for Internet Numbers >> > > -- Joel Esler http://www.joelesler.net From jcurran at arin.net Wed Oct 20 10:16:44 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 11:16:44 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBEFFFA.1030002@foobar.org> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: <1F0E8D6A-D7E6-4D7E-91E7-1E07792A8D8E@arin.net> On Oct 20, 2010, at 10:43 AM, Nick Hilliard wrote: > Thank you Interop - for performing an outstanding act of altruism. > > John, could you provide more details at this stage on how much address space was returned to ARIN? INTEROP is retaining 2 /16 blocks for existing usage; i.e. more than 99% of the /8 block is being returned. To the extent that parties have unused address space beyond their usage and foreseeable need, we encourage them to return the space so it may be reissued to those parties with need. This is in keeping with global policies on Internet address space management. /John John Curran President and CEO ARIN From merkel at metalink.net Wed Oct 20 10:24:41 2010 From: merkel at metalink.net (Eric Merkel) Date: Wed, 20 Oct 2010 11:24:41 -0400 Subject: Recommendations for Metro-Ethernet Equipment Message-ID: <022801cb706a$ead9d5e0$c08d81a0$@net> I've been tasked with making a recommendation for the core and access equipment for a small metro-ethernet network. We're probably talking at max 200-300 subs split between two termination points. Most customers will probably be at speeds of 100M or less. We'd like the backbone to be 10G and be MPLS capable. That being said some of the companies we've been looking at are Cisco Extreme Brocade Adtran Occam Zhone We're looking to build the network in a cost effective manner so we're not opposed to doing using aftermarket or refurbished equipment but we don't want to start off with equipment that has no future of expanding. Any suggestions, success or horror stories are appreciated. ;) Eric ===== Eric Merkel MetaLINK Technologies, Inc. Email: merkel at metalink.net From jeroen at unfix.org Wed Oct 20 10:24:46 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 20 Oct 2010 17:24:46 +0200 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: <4CBF09BE.50507@unfix.org> [John, is 45.127.0.0/16 one of the two blocks they keep, or is it hijacked already? :) ] On 2010-10-20 17:11, Joel Esler wrote: > Now, if we could get everyone that has these gigantic /8's (or multiple of them) > that aren't using them to give some back, that'd be great. The problem with that is indeed in that little part about "aren't using them", if even only 50% is in use because one allocated it quite sparsely you won't be able to quickly clean it up and return it. > Thank you interop for setting the example. For delaying the inevitable by what, a month!? It is indeed really great that they took the effort to do so, but then again, they where not always using this prefix, only during events, thus it must have been quite empty. The fact that RIPE's RIS hasn't even seen the prefix announced ever says enough about that part. Doesn't mean it is not being used by other parties though: 45.127.0.0/16 13767 DBANK - DataBank Holdings, Ltd. 2009-04-10 15:43:59 UTC 2010-10-20 14:11:43 UTC One can of course wonder if they are supposed to use that or not. The fact that they do not have reverse DNS delegation for it says quite a bit already of course. Maybe that is one of the two /16's that they are keeping to themselves, seems to be used that way for over a year already. I assume L(3) did proper checking. Greets, Jeroen From morrowc.lists at gmail.com Wed Oct 20 10:26:27 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 20 Oct 2010 11:26:27 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBEFFFA.1030002@foobar.org> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: On Wed, Oct 20, 2010 at 10:43 AM, Nick Hilliard wrote: > Thank you Interop - for performing an outstanding act of altruism. > > John, could you provide more details at this stage on how much address space > was returned to ARIN? less than 3 months supply at the going drain rate. From morrowc.lists at gmail.com Wed Oct 20 10:27:41 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 20 Oct 2010 11:27:41 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: On Wed, Oct 20, 2010 at 11:11 AM, Joel Esler wrote: > Now, if we could get everyone that has these gigantic /8's (or multiple of them) that aren't using them to give some back, that'd be great. it's nice that interop did a nice thing here, but seriously, this is ~3 months of usage... there is no saving the move to v6, the bottom's going to fall out on or about june 2011 it seems. From jcurran at arin.net Wed Oct 20 10:28:44 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 11:28:44 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: On Oct 20, 2010, at 11:26 AM, Christopher Morrow wrote: > On Wed, Oct 20, 2010 at 10:43 AM, Nick Hilliard wrote: >> Thank you Interop - for performing an outstanding act of altruism. >> >> John, could you provide more details at this stage on how much address space >> was returned to ARIN? > > less than 3 months supply at the going drain rate. Not to be depressing, but a /8 (or 99% of one :-) is potentially less than one month's drain on the global IPv4 free pool, if one considers the allocations over the last 12 months to be predictive. /John John Curran President and CEO ARIN From cmaurand at xyonet.com Wed Oct 20 10:29:58 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Wed, 20 Oct 2010 11:29:58 -0400 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: <022801cb706a$ead9d5e0$c08d81a0$@net> References: <022801cb706a$ead9d5e0$c08d81a0$@net> Message-ID: <4CBF0AF6.9030207@xyonet.com> I'd add Alcatel to that list. On 10/20/2010 11:24 AM, Eric Merkel wrote: > I've been tasked with making a recommendation for the core and access > equipment for a small metro-ethernet network. We're probably talking at max > 200-300 subs split between two termination points. Most customers will > probably be at speeds of 100M or less. We'd like the backbone to be 10G and > be MPLS capable. That being said some of the companies we've been looking at > are > > > > Cisco > > Extreme > > Brocade > > Adtran > > Occam > > Zhone > > > > We're looking to build the network in a cost effective manner so we're not > opposed to doing using aftermarket or refurbished equipment but we don't > want to start off with equipment that has no future of expanding. > > > > Any suggestions, success or horror stories are appreciated. ;) > > > > Eric > > > > ===== > > Eric Merkel > > MetaLINK Technologies, Inc. > > Email: merkel at metalink.net > From jcurran at arin.net Wed Oct 20 10:33:01 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 11:33:01 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: On Oct 20, 2010, at 11:27 AM, Christopher Morrow wrote: > > it's nice that interop did a nice thing here, but seriously, this is > ~3 months of usage... there is no saving the move to v6, the bottom's > going to fall out on or about june 2011 it seems. I agree with Chris; this (and any other returns) won't change the IPv4 depletion/IPv6 deployment timeline substantially, but it's also true we have folks who are just now realizing IPv4 depletion is happening and returned address space may make the difference for those who need just a bit more time... /John John Curran President and CEO ARIN From morrowc.lists at gmail.com Wed Oct 20 10:35:19 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Wed, 20 Oct 2010 11:35:19 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: On Wed, Oct 20, 2010 at 11:28 AM, John Curran wrote: > On Oct 20, 2010, at 11:26 AM, Christopher Morrow wrote: >> less than 3 months supply at the going drain rate. > > Not to be depressing, but a /8 (or 99% of one :-) is potentially less > than one month's drain on the global IPv4 free pool, if one considers > the allocations over the last 12 months to be predictive. yes, sorry.. since this was returned to ARIN, I assumed the ARIN region drain rate. From jcurran at arin.net Wed Oct 20 10:37:55 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 11:37:55 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBF09BE.50507@unfix.org> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF09BE.50507@unfix.org> Message-ID: On Oct 20, 2010, at 11:24 AM, Jeroen Massar wrote: > > The problem with that is indeed in that little part about "aren't using > them", if even only 50% is in use because one allocated it quite > sparsely you won't be able to quickly clean it up and return it. Correct. It might make sense to do so, if you could recover the costs of the work involved. This is the reasoning behind the Specified Transfer policy that was recently adopted; it allows (once we're at depletion) for parties to free up address space and get compensated. It's goal is not to provide a windfall for those holding unused space; in theory, those with unused address space should be returning it already if they can easily do so. > One can of course wonder if they are supposed to use that or not. > The fact that they do not have reverse DNS delegation for it says quite > a bit already of course. One of the other benefits of improved utilization for returned space is less space which is "sitting idle" and available to be hijacked. /John John Curran President and CEO ARIN From jcurran at arin.net Wed Oct 20 10:40:57 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 11:40:57 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: On Oct 20, 2010, at 11:35 AM, Christopher Morrow wrote: > yes, sorry.. since this was returned to ARIN, I assumed the ARIN > region drain rate. Ah, good point. It may end up in the global pool, so comparison to either drain rate is quite reasonable. /John From jmaimon at ttec.com Wed Oct 20 10:45:20 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Wed, 20 Oct 2010 11:45:20 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: <4CBF0E90.6070403@ttec.com> Christopher Morrow wrote: > On Wed, Oct 20, 2010 at 10:43 AM, Nick Hilliard wrote: >> Thank you Interop - for performing an outstanding act of altruism. >> >> John, could you provide more details at this stage on how much address space >> was returned to ARIN? > > less than 3 months supply at the going drain rate. > So would it be more logical for all those willing to return do so only after depletion when the impact and resulting appreciation is likely to be greater? Plus, those less altruistic could weigh the options better after real value is associated with the scarce resource. Joe From francois at menards.ca Wed Oct 20 11:02:16 2010 From: francois at menards.ca (Francois Menard) Date: Wed, 20 Oct 2010 12:02:16 -0400 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: <4CBF0AF6.9030207@xyonet.com> References: <022801cb706a$ead9d5e0$c08d81a0$@net> <4CBF0AF6.9030207@xyonet.com> Message-ID: We just bought a fair amount of MRV Optiswitches for that same purpose. F. On 2010-10-20, at 11:29 AM, Curtis Maurand wrote: > I'd add Alcatel to that list. > > On 10/20/2010 11:24 AM, Eric Merkel wrote: >> I've been tasked with making a recommendation for the core and access >> equipment for a small metro-ethernet network. We're probably talking at max >> 200-300 subs split between two termination points. Most customers will >> probably be at speeds of 100M or less. We'd like the backbone to be 10G and >> be MPLS capable. That being said some of the companies we've been looking at >> are >> >> >> >> Cisco >> >> Extreme >> >> Brocade >> >> Adtran >> >> Occam >> >> Zhone >> >> >> >> We're looking to build the network in a cost effective manner so we're not >> opposed to doing using aftermarket or refurbished equipment but we don't >> want to start off with equipment that has no future of expanding. >> >> >> >> Any suggestions, success or horror stories are appreciated. ;) >> >> >> >> Eric >> >> >> >> ===== >> >> Eric Merkel >> >> MetaLINK Technologies, Inc. >> >> Email: merkel at metalink.net >> > > From streiner at cluebyfour.org Wed Oct 20 11:03:46 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Wed, 20 Oct 2010 12:03:46 -0400 (EDT) Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: On Wed, 20 Oct 2010, Joel Esler wrote: > Now, if we could get everyone that has these gigantic /8's (or multiple > of them) that aren't using them to give some back, that'd be great. > > Thank you interop for setting the example. Sure, it would be a nice gesture if MIT/HP/Ford/Xerox/Halliburton/etc gave back the chunks of the /8s they weren't using, but it wouldn't significantly affect when the IPv4 well runs dry. Also, without knowing how those organizations have used the space internally, such an altruistic gesture could also come at the cost of having to de-aggregate a bunch of advertisements in BGP. The law of diminishing returns comes into play. jms > On Oct 20, 2010, at 10:43 AM, Nick Hilliard wrote: > >> Thank you Interop - for performing an outstanding act of altruism. >> >> John, could you provide more details at this stage on how much address space was returned to ARIN? >> >> Nick >> >> On 20/10/2010 14:34, John Curran wrote: >>> FYI, >>> /John >>> >>> ---- >>> https://www.arin.net/announcements/2010/20101020.html >>> >>> >>> Posted: Wednesday, 20 October 2010 >>> >>> ARIN today recognizes Interop, an organization with a long-standing presence in the Internet industry, for returning its unneeded Internet Protocol version 4 (IPv4) address space. >>> >>> Interop was originally allocated a /8 before ARIN's existence and the availability of smaller-sized address blocks. The organization recently realized it was only using a small portion of its address block and that returning the remainder to ARIN would be for the greater good of the Internet community. >>> >>> ARIN will accept the returned space and not reissue it for a short period, per existing operational procedure. After the hold period, ARIN will follow global policy at that time and return it to the global free pool or distribute the space to those organizations in the ARIN region with documented need, as appropriate. >>> >>> With less than 5% of the IPv4 address space left in the global free pool, ARIN warns that Interop's return will not significantly extend the life of IPv4. ARIN continues to emphasize the need for all Internet stakeholders to adopt the next generation of Internet Protocol, IPv6. >>> >>> Regards, >>> >>> Communications and Member Services >>> American Registry for Internet Numbers >>> >> >> > > -- > Joel Esler > http://www.joelesler.net > > > From ernesto at cs.fiu.edu Wed Oct 20 11:04:29 2010 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Wed, 20 Oct 2010 12:04:29 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBF0E90.6070403@ttec.com> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF0E90.6070403@ttec.com> Message-ID: <107A762E-D0A0-4CBA-92D8-376FCD6E266B@cs.fiu.edu> I don't think ARIN (or any other RIR) wants people to think this way. Appreciation and value are words that most folks at ICANN don't want network engineers to associate with IP addresses. "The real value is in routing"; is the party line. STLS to me is kind of double speak, ARIN says: "this isn't a capital resource", but yet if you go through us and list your 'unused' blocks in this space, we don't care what financial transaction happens behind the scenes. Maybe John can shed more light on this. For some background, go over to the Internet-history mailing list, which included a very lively discussion of "ownership interest" in IP addresses. Ernie On Oct 20, 2010, at 11:45 AM, Joe Maimon wrote: > > So would it be more logical for all those willing to return do so only after depletion when the impact and resulting appreciation is likely to be greater? > > Plus, those less altruistic could weigh the options better after real value is associated with the scarce resource. From cgrundemann at gmail.com Wed Oct 20 11:14:36 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Wed, 20 Oct 2010 10:14:36 -0600 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: <4CBF0AF6.9030207@xyonet.com> References: <022801cb706a$ead9d5e0$c08d81a0$@net> <4CBF0AF6.9030207@xyonet.com> Message-ID: On Wed, Oct 20, 2010 at 09:29, Curtis Maurand wrote: > ?I'd add Alcatel to that list. yep, and also (depending on specific needs/topologies): Ciena Cyan Fujitsu Corrigent Adva Rad Data Juniper (in no particular order) Good luck, ~Chris > > On 10/20/2010 11:24 AM, Eric Merkel wrote: >> >> I've been tasked with making a recommendation for the core and access >> equipment for a small metro-ethernet network. We're probably talking at >> max >> 200-300 subs split between two termination points. Most customers will >> probably be at speeds of 100M or less. We'd like the backbone to be 10G >> and >> be MPLS capable. That being said some of the companies we've been looking >> at >> are >> >> >> >> Cisco >> >> Extreme >> >> Brocade >> >> Adtran >> >> Occam >> >> Zhone >> >> >> >> We're looking to build the network in a cost effective manner so we're not >> opposed to doing using aftermarket or refurbished equipment but we don't >> want to start off with equipment that has no future of expanding. >> >> >> >> Any suggestions, success or horror stories are appreciated. ;) >> >> >> >> Eric >> >> >> >> ===== >> >> Eric Merkel >> >> MetaLINK Technologies, Inc. >> >> Email: merkel at metalink.net >> > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From gbonser at seven.com Wed Oct 20 11:11:18 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 20 Oct 2010 09:11:18 -0700 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: References: <20101018153551.GA28093@nudo.bsws.de><5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com><84764.1287438364@localhost><87iq0yqu6h.fsf@oban.berlin.quux.de><80879.1287493941@localhost><877hhehqxp.fsf@oban.berlin.quux.de><20101020145418.69f12048@opy.nosense.org><4CBE77BC.2050501@bogus.com><20101020051704.GB27873@vacation.karoshi.com.><5A6D953473350C4B9995546AFE9939EE0B14C3BB@RWC-EX1.corp.seven.com><8D07B04F-825E-4EC4-9068-D8767839A1A0@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C3BD@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C3C1@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C3C8@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Wednesday, October 20, 2010 2:50 AM > To: George Bonser > Cc: nanog at nanog.org > Subject: Re: Only 5x IPv4 ... WRONG! :) > > > On Oct 20, 2010, at 2:09 AM, George Bonser wrote: > > > > > > >> -----Original Message----- > >> From: George Bonser > >> Sent: Wednesday, October 20, 2010 12:30 AM > >> To: Owen DeLong > >> Cc: nanog at nanog.org > >> Subject: RE: Only 5x IPv4 ... WRONG! :) > >> > >> It isn't "easy" but it isn't the fault of "v6" in most cases. > >> > > > > Put another way, the set of challenges facing the > enterprise/production > > operator (the people who use that network to facilitate the delivery > of > > a product ... either on the transmitting or receiving end of that > > delivery) is quite different from the set of challenges that face a > pure > > network operator. And what seems so easy for one may not be so easy > for > > the other. > > > > Dual stacking network gear is less of a problem than dual stacking > > hundreds or thousands of servers, special purpose appliances, > software, > > etc. of different vendors, ages, and complexity. > > > I'm not sure why you assume that network operators don't have hundreds > or thousands of servers, special purpose appliances, software, etc. > of different vendors, ages, and complexity. > Huh? I didn't assume anything. I simply said that an operation that is a pure network play is going have a different experience than an operation that has a lot of other stuff and where network is a smaller part of the overall picture. And even that is going to vary from one organization or even at different locations within an organization. A location with older gear might have a more difficult time of it. > However, other than some very limited exceptions, HE has dual-stacked > their entire enterprise, not just their backbone. All of our public > facing > servers are fully dual-stacked with published AAAA records. Our > customers can freely run IPv4, IPv6, or both on our managed servers > and/or their own equipment in our colos. All of our IP connectivity > clients have access to dual-stack services, and, we actually provide > economic incentives for customers to do dual-stack rather than IPv4 > only connections to us. Yes, HE has made considerable investment in v6 and is a tremendous asset to the community in raising awareness, offering encouragement, education, and support in getting people to move to v6 and they "eat their own dog food". All great attributes. It is very apparent that HE "gets it" and has made a major commitment in that area. Other organizations are going to see varying amounts of traction. Hearing things like "we aren't fork lifting all the gear, it isn't like v4 is going away, that facility isn't growing, we will worry about v6 on our next buildout" aren't uncommon. I also hear things like "oh, yeah, we have talked about v6 but don't have a specific plan". > Migrating from IPv4 to dual stack isn't going to get significantly > easier > by procrastinating at this point. It's only going to get more urgent. Absolutely agree. Everything anyone builds new at this point should be v6 capable. At least one shouldn't, in my opinion, let things get worse. > Doing something hard on a schedule is hard. Particularly true if you already run a lean shop and have aggressive work schedules as it is for managing the operation. Telling another department that they are going to need to upgrade the OS (or OSes) on several hundred machines in order to accommodate what they might not perceive as a pressing need is going to depend on the level of support the effort has from the top levels of management. Other organizations are going to see the value in getting it done earlier rather than later. Fundamentally it seems that the extent to which an organization moves on this will depend on many factors and one that is pretty important is their current rate of change in relation to their current size. A large operation that is cruising along with what they have or is maybe shrinking might not want to invest a lot of time, effort, money into changing. One that is growing quickly will have less of a problem rolling out v6 in their new facilities and installing it in the older ones as they quickly outgrow that infrastructure. > > Doing something hard in a rush because you failed to schedule it > is harder. Absolutely. What is driving this is an understanding on my part that the extent to which organizations adopt v6 is going to vary widely and so will the reasons for it. I interface with other organizations on a daily basis and I see the entire spectrum of v6 readiness and reasons why it is where it is with those organizations. When I hear someone say "v6 is ..." followed by something or another it has to be tempered with the understanding that while they might be making an absolute statement, that statement is relative to their situation and that same "truth" isn't going to hold for someone else. I would join you in encouraging people get things moving. If you don't at least have a plan, you need one. Now. Really. Because an increasingly large number of customers, peers, and partners are going to be operating v6 native or at least v6 capable and accommodating v4 is going to become an increasingly large pain in the hips for them. > Owen G From jcurran at arin.net Wed Oct 20 11:19:13 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 12:19:13 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <107A762E-D0A0-4CBA-92D8-376FCD6E266B@cs.fiu.edu> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF0E90.6070403@ttec.com> <107A762E-D0A0-4CBA-92D8-376FCD6E266B@cs.fiu.edu> Message-ID: <4AEEA834-00CC-4270-9FDE-99F62A5FFCBE@arin.net> On Oct 20, 2010, at 12:04 PM, Ernie Rubi wrote: > I don't think ARIN (or any other RIR) wants people to think this way. Ernie - ARIN doesn't have a view on how people should think. It does have an interest in making sure that number resources policies that are adopted by community are followed. > STLS to me is kind of double speak, ARIN says: "this isn't a capital resource", but yet if you go through us and list your 'unused' blocks in this space, we don't care what financial transaction happens behind the scenes. > > Maybe John can shed more light on this. Specified Transfer Listing Service (STLS) is a service, not a policy. You don't need to use the STLS to make use of the Specified Transfer policy. The Specified Transfer policy lets parties to free up address space (that might not otherwise be available) and then arrange transfer to another party. Given that a lot of IPv4 address space may be readily available given a little work to renumber, it was felt to be a reasonable compromise in encouraging better utilization once we've run out of the IP4 free pool. Parties which receive under the specified transfer policy still must meet all of the normal address allocation requirements, including documented need. /John John Curran President and CEO ARIN From jcurran at arin.net Wed Oct 20 11:20:01 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 12:20:01 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBF0E90.6070403@ttec.com> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF0E90.6070403@ttec.com> Message-ID: <80D30303-2863-4E26-86FF-CCA4C7385243@arin.net> On Oct 20, 2010, at 11:45 AM, Joe Maimon wrote: > > So would it be more logical for all those willing to return do so only after depletion when the impact and resulting appreciation is likely to be greater? It would be best for folks who can return address space to do so as soon as possible, since that space could then be made available under existing allocation policies. It is likely that there are many organizations which would qualify under current need-based policy which may not have any meaningful chance to receive address space post-depletion. > Plus, those less altruistic could weigh the options better after real value is associated with the scarce resource. Parties that could return space now and are holding it entirely to profiteer are not envisioned in RFC 2050. ARIN recognizes that such parties could use the specified transfer policy to receive compensation despite being able to return the space, but overall the community recommended proceeding because the benefit to overall utilization was deemed worthwhile. /John John Curran President and CEO ARIN From jcurran at arin.net Wed Oct 20 11:19:13 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 12:19:13 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <107A762E-D0A0-4CBA-92D8-376FCD6E266B@cs.fiu.edu> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF0E90.6070403@ttec.com> <107A762E-D0A0-4CBA-92D8-376FCD6E266B@cs.fiu.edu> Message-ID: <4AEEA834-00CC-4270-9FDE-99F62A5FFCBE@arin.net> On Oct 20, 2010, at 12:04 PM, Ernie Rubi wrote: > I don't think ARIN (or any other RIR) wants people to think this way. Ernie - ARIN doesn't have a view on how people should think. It does have an interest in making sure that number resources policies that are adopted by community are followed. > STLS to me is kind of double speak, ARIN says: "this isn't a capital resource", but yet if you go through us and list your 'unused' blocks in this space, we don't care what financial transaction happens behind the scenes. > > Maybe John can shed more light on this. Specified Transfer Listing Service (STLS) is a service, not a policy. You don't need to use the STLS to make use of the Specified Transfer policy. The Specified Transfer policy lets parties to free up address space (that might not otherwise be available) and then arrange transfer to another party. Given that a lot of IPv4 address space may be readily available given a little work to renumber, it was felt to be a reasonable compromise in encouraging better utilization once we've run out of the IP4 free pool. Parties which receive under the specified transfer policy still must meet all of the normal address allocation requirements, including documented need. /John John Curran President and CEO ARIN From jbates at brightok.net Wed Oct 20 11:27:40 2010 From: jbates at brightok.net (Jack Bates) Date: Wed, 20 Oct 2010 11:27:40 -0500 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <80D30303-2863-4E26-86FF-CCA4C7385243@arin.net> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF0E90.6070403@ttec.com> <80D30303-2863-4E26-86FF-CCA4C7385243@arin.net> Message-ID: <4CBF187C.10201@brightok.net> On 10/20/2010 11:20 AM, John Curran wrote: > ARIN recognizes that such parties could use the specified > transfer policy to receive compensation despite being able > to return the space, but overall the community recommended > proceeding because the benefit to overall utilization was > deemed worthwhile. > Speaking of which, has any research been done on determining the likelihood that PE pools (which probably consist of a huge number of blocks) will be returned as IPv6 is adopted at the edge? I'm curious, as I suspect that the second I have no choice but to put a single customer as v6 only using nat64, at that point, I might as well convert all customers so that troubleshooting problems is uniform and reduce the support costs. Of course, I'm still waiting on decent equipment that will handle this mass transition, but luckily I'm not to that point yet. Returns like this buy us time before the real hard choices come into play (which gives vendors and ISPs time for development). Jack From sds at dcs.gla.ac.uk Wed Oct 20 11:29:02 2010 From: sds at dcs.gla.ac.uk (Stephen D. Strowes) Date: Wed, 20 Oct 2010 17:29:02 +0100 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> Message-ID: <1287592142.11548.7.camel@carney> Interested to know how this will show in the IANA v4 address space registry. Will 045/8 soon appear as belonging to ARIN, since it is now not Interop's? Also makes me wonder if there are historical versions of this registry available. If reclamation of large blocks such as this becomes commonplace, will many of the legacy allocations simply become footnotes? (In the registry document, as well as in history?) -S. On Wed, 2010-10-20 at 14:34 +0100, John Curran wrote: > FYI, > /John > > ---- > https://www.arin.net/announcements/2010/20101020.html > > > Posted: Wednesday, 20 October 2010 > > ARIN today recognizes Interop, an organization with a long-standing presence in the Internet industry, for returning its unneeded Internet Protocol version 4 (IPv4) address space. > > Interop was originally allocated a /8 before ARIN's existence and the availability of smaller-sized address blocks. The organization recently realized it was only using a small portion of its address block and that returning the remainder to ARIN would be for the greater good of the Internet community. > > ARIN will accept the returned space and not reissue it for a short period, per existing operational procedure. After the hold period, ARIN will follow global policy at that time and return it to the global free pool or distribute the space to those organizations in the ARIN region with documented need, as appropriate. > > With less than 5% of the IPv4 address space left in the global free pool, ARIN warns that Interop's return will not significantly extend the life of IPv4. ARIN continues to emphasize the need for all Internet stakeholders to adopt the next generation of Internet Protocol, IPv6. > > Regards, > > Communications and Member Services > American Registry for Internet Numbers From jcurran at arin.net Wed Oct 20 11:40:03 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 12:40:03 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <1287592142.11548.7.camel@carney> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <1287592142.11548.7.camel@carney> Message-ID: On Oct 20, 2010, at 12:29 PM, Stephen D. Strowes wrote: > Interested to know how this will show in the IANA v4 address space > registry. Will 045/8 soon appear as belonging to ARIN, since it is now > not Interop's? Correct. Also note that the concept of a single RIR managing each /8 only applies under certain circumstances; there are many cases where multiple RIR's manage resources under a given block and work together to make sure that things like in-addr (and RPKI) function. This could easily be the case with this particular address block at some future time, depending on the state of global return policy. > Also makes me wonder if there are historical versions of this registry > available. If reclamation of large blocks such as this becomes > commonplace, will many of the legacy allocations simply become > footnotes? (In the registry document, as well as in history?) This has already happened in many cases; address blocks previously held by US DoD, BBN, Stanford were returned, held for a period, and then reissued. /John John Curran President and CEO ARIN From bruns at 2mbit.com Wed Oct 20 11:47:57 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 20 Oct 2010 10:47:57 -0600 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> Message-ID: <4CBF1D3D.6000108@2mbit.com> On 10/20/10 7:34 AM, John Curran wrote: > With less than 5% of the IPv4 address space left in the global free > pool, ARIN warns that Interop's return will not significantly extend > the life of IPv4. ARIN continues to emphasize the need for all > Internet stakeholders to adopt the next generation of Internet > Protocol, IPv6. Not to stir an already boiling over pot and all, but is there any kind of report or documentation on releasing of space from countries other then the North American region? I'd hate to think that the rest of the world thinks that the US should be the one to give up all their space so that they can continue to hand out space like candy... -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From sds at dcs.gla.ac.uk Wed Oct 20 11:52:00 2010 From: sds at dcs.gla.ac.uk (Stephen D. Strowes) Date: Wed, 20 Oct 2010 17:52:00 +0100 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <1287592142.11548.7.camel@carney> Message-ID: <1287593520.11548.15.camel@carney> On Wed, 2010-10-20 at 17:40 +0100, John Curran wrote: > > Also makes me wonder if there are historical versions of this registry > > available. If reclamation of large blocks such as this becomes > > commonplace, will many of the legacy allocations simply become > > footnotes? (In the registry document, as well as in history?) > > This has already happened in many cases; address blocks previously > held by US DoD, BBN, Stanford were returned, held for a period, > and then reissued. Indeed yes. And these returned blocks aren't noted in the IANA registry (for good reason I guess; the registry is meant to be current.) Is this historical information noted anywhere? -S. From dougb at dougbarton.us Wed Oct 20 12:06:33 2010 From: dougb at dougbarton.us (Doug Barton) Date: Wed, 20 Oct 2010 10:06:33 -0700 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> Message-ID: <4CBF2199.4010700@dougbarton.us> On 10/20/2010 7:13 AM, Randy Bush wrote: > i think this is cool, but ... > >> ARIN will follow global policy at that time and return it to the >> global free pool or distribute the space to those organizations in the >> ARIN region with documented need, as appropriate. > > i know the us has the world series, but global> arin region I would like to join the chorus of applause for Interop's generosity. I agree with those who've said that this only buys us a little more time, but they did the right thing, and we should applaud them for that; along with the DOD and others who have returned their unneeded space. As for the fact that the block was released to ARIN as opposed to going back in the free pool, the effect may ultimately be the same. Allocations from IANA to the RIRs happen under the policy posted at http://www.icann.org/en/general/allocation-IPv4-rirs.html. The determination of when to allocate a new /8 is based on the amount of free space that the RIR has on hand at the time of the request. There are 12 /8s remaining atm, and 5 of those will automatically be allocated 1 per RIR when the other 7 have been allocated under the normal policy. I am confident that ARIN will also do the right thing here and include the /8 from Interop in their free space calculation before requesting an allocation of one of the 7 /8s in the free pool. hth, Doug -- Breadth of IT experience, and | Nothin' ever doesn't change, depth of knowledge in the DNS. | but nothin' changes much. Yours for the right price. :) | -- OK Go http://SupersetSolutions.com/ From jcurran at arin.net Wed Oct 20 12:34:22 2010 From: jcurran at arin.net (John Curran) Date: Wed, 20 Oct 2010 13:34:22 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBF1D3D.6000108@2mbit.com> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBF1D3D.6000108@2mbit.com> Message-ID: <62EADAE5-5D10-4749-AD1F-9343A457FC5A@arin.net> On Oct 20, 2010, at 12:47 PM, Brielle Bruns wrote: > > Not to stir an already boiling over pot and all, but is there any kind of report or documentation on releasing of space from countries other then the North American region? You're not going to find a lot of large allocations which are unused in other regions, predominantly because these allocations where made at the earliest time of the Internet to organizations that were mostly in the ARIN region. > I'd hate to think that the rest of the world thinks that the US should be the one to give up all their space so that they can continue to hand out space like candy... While it is true that some regions seem to be experiencing a real surge in IPv4 demand recently, it's also important to remember that *all* of the address space is for the Internet community at large, based on documented need, on a first-come, first-serve basis. It's actually "global Internet address space"; this is a fundamental principle of the Internet Registry system as noted in RFC 2050. /John John Curran President and CEO ARIN From rudi.daniel at gmail.com Wed Oct 20 12:41:19 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 20 Oct 2010 13:41:19 -0400 Subject: NANOG Digest, Vol 33, Issue 91 In-Reply-To: References: Message-ID: We all are waiving flags about the return of one solitary /8 to ARIN, (which is a good thing) but should we not waive flags about new v6 networks too? Let us waive the flags also for the v6 adopters...I think we need to evangelize v6 even more than we are already doing. RD > Date: Wed, 20 Oct 2010 11:27:41 -0400 > From: Christopher Morrow > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: Joel Esler > Cc: John Curran , "nanog at nanog.org" > > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Oct 20, 2010 at 11:11 AM, Joel Esler wrote: > > Now, if we could get everyone that has these gigantic /8's (or multiple > of them) that aren't using them to give some back, that'd be great. > > it's nice that interop did a nice thing here, but seriously, this is > ~3 months of usage... there is no saving the move to v6, the bottom's > going to fall out on or about june 2011 it seems. > > > > ------------------------------ > > Message: 2 > Date: Wed, 20 Oct 2010 11:28:44 -0400 > From: John Curran > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: Christopher Morrow > Cc: "nanog at nanog.org Operators Group" > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On Oct 20, 2010, at 11:26 AM, Christopher Morrow wrote: > > > On Wed, Oct 20, 2010 at 10:43 AM, Nick Hilliard wrote: > >> Thank you Interop - for performing an outstanding act of altruism. > >> > >> John, could you provide more details at this stage on how much address > space > >> was returned to ARIN? > > > > less than 3 months supply at the going drain rate. > > Not to be depressing, but a /8 (or 99% of one :-) is potentially less > than one month's drain on the global IPv4 free pool, if one considers > the allocations over the last 12 months to be predictive. > > /John > > John Curran > President and CEO > ARIN > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 20 Oct 2010 11:29:58 -0400 > From: Curtis Maurand > Subject: Re: Recommendations for Metro-Ethernet Equipment > To: nanog at nanog.org > Message-ID: <4CBF0AF6.9030207 at xyonet.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I'd add Alcatel to that list. > > On 10/20/2010 11:24 AM, Eric Merkel wrote: > > I've been tasked with making a recommendation for the core and access > > equipment for a small metro-ethernet network. We're probably talking at > max > > 200-300 subs split between two termination points. Most customers will > > probably be at speeds of 100M or less. We'd like the backbone to be 10G > and > > be MPLS capable. That being said some of the companies we've been looking > at > > are > > > > > > > > Cisco > > > > Extreme > > > > Brocade > > > > Adtran > > > > Occam > > > > Zhone > > > > > > > > We're looking to build the network in a cost effective manner so we're > not > > opposed to doing using aftermarket or refurbished equipment but we don't > > want to start off with equipment that has no future of expanding. > > > > > > > > Any suggestions, success or horror stories are appreciated. ;) > > > > > > > > Eric > > > > > > > > ===== > > > > Eric Merkel > > > > MetaLINK Technologies, Inc. > > > > Email: merkel at metalink.net > > > > > > > ------------------------------ > > Message: 4 > Date: Wed, 20 Oct 2010 11:33:01 -0400 > From: John Curran > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: Christopher Morrow > Cc: "nanog at nanog.org Operators Group" > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On Oct 20, 2010, at 11:27 AM, Christopher Morrow wrote: > > > > it's nice that interop did a nice thing here, but seriously, this is > > ~3 months of usage... there is no saving the move to v6, the bottom's > > going to fall out on or about june 2011 it seems. > > I agree with Chris; this (and any other returns) won't change the IPv4 > depletion/IPv6 deployment timeline substantially, but it's also true > we have folks who are just now realizing IPv4 depletion is happening > and returned address space may make the difference for those who need > just a bit more time... > > /John > > John Curran > President and CEO > ARIN > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 20 Oct 2010 11:35:19 -0400 > From: Christopher Morrow > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: John Curran > Cc: "nanog at nanog.org Operators Group" > Message-ID: > > > > Content-Type: text/plain; charset=ISO-8859-1 > > On Wed, Oct 20, 2010 at 11:28 AM, John Curran wrote: > > On Oct 20, 2010, at 11:26 AM, Christopher Morrow wrote: > > >> less than 3 months supply at the going drain rate. > > > > Not to be depressing, but a /8 (or 99% of one :-) is potentially less > > than one month's drain on the global IPv4 free pool, if one considers > > the allocations over the last 12 months to be predictive. > > yes, sorry.. since this was returned to ARIN, I assumed the ARIN > region drain rate. > > > > ------------------------------ > > Message: 6 > Date: Wed, 20 Oct 2010 11:37:55 -0400 > From: John Curran > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: Jeroen Massar > Cc: "nanog at nanog.org Operators Group" > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On Oct 20, 2010, at 11:24 AM, Jeroen Massar wrote: > > > > The problem with that is indeed in that little part about "aren't using > > them", if even only 50% is in use because one allocated it quite > > sparsely you won't be able to quickly clean it up and return it. > > Correct. It might make sense to do so, if you could recover the costs of > the work involved. This is the reasoning behind the Specified Transfer > policy that was recently adopted; it allows (once we're at depletion) for > parties to free up address space and get compensated. It's goal is not to > provide a windfall for those holding unused space; in theory, those with > unused address space should be returning it already if they can easily do > so. > > > One can of course wonder if they are supposed to use that or not. > > The fact that they do not have reverse DNS delegation for it says quite > > a bit already of course. > > One of the other benefits of improved utilization for returned space > is less space which is "sitting idle" and available to be hijacked. > > /John > > John Curran > President and CEO > ARIN > > > > > ------------------------------ > > Message: 7 > Date: Wed, 20 Oct 2010 11:40:57 -0400 > From: John Curran > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: Christopher Morrow > Cc: "nanog at nanog.org Operators Group" > Message-ID: > Content-Type: text/plain; charset="us-ascii" > > On Oct 20, 2010, at 11:35 AM, Christopher Morrow wrote: > > > yes, sorry.. since this was returned to ARIN, I assumed the ARIN > > region drain rate. > > Ah, good point. It may end up in the global pool, so comparison to > either drain rate is quite reasonable. > > /John > > > > ------------------------------ > > Message: 8 > Date: Wed, 20 Oct 2010 11:45:20 -0400 > From: Joe Maimon > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: Christopher Morrow > Cc: John Curran , "nanog at nanog.org" > > Message-ID: <4CBF0E90.6070403 at ttec.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > Christopher Morrow wrote: > > On Wed, Oct 20, 2010 at 10:43 AM, Nick Hilliard wrote: > >> Thank you Interop - for performing an outstanding act of altruism. > >> > >> John, could you provide more details at this stage on how much address > space > >> was returned to ARIN? > > > > less than 3 months supply at the going drain rate. > > > > So would it be more logical for all those willing to return do so only > after depletion when the impact and resulting appreciation is likely to > be greater? > > Plus, those less altruistic could weigh the options better after real > value is associated with the scarce resource. > > > Joe > > > > > ------------------------------ > > Message: 9 > Date: Wed, 20 Oct 2010 12:02:16 -0400 > From: Francois Menard > Subject: Re: Recommendations for Metro-Ethernet Equipment > To: Curtis Maurand > Cc: nanog at nanog.org > Message-ID: > Content-Type: text/plain; charset=us-ascii > > We just bought a fair amount of MRV Optiswitches for that same purpose. > > F. > > On 2010-10-20, at 11:29 AM, Curtis Maurand wrote: > > > I'd add Alcatel to that list. > > > > On 10/20/2010 11:24 AM, Eric Merkel wrote: > >> I've been tasked with making a recommendation for the core and access > >> equipment for a small metro-ethernet network. We're probably talking at > max > >> 200-300 subs split between two termination points. Most customers will > >> probably be at speeds of 100M or less. We'd like the backbone to be 10G > and > >> be MPLS capable. That being said some of the companies we've been > looking at > >> are > >> > >> > >> > >> Cisco > >> > >> Extreme > >> > >> Brocade > >> > >> Adtran > >> > >> Occam > >> > >> Zhone > >> > >> > >> > >> We're looking to build the network in a cost effective manner so we're > not > >> opposed to doing using aftermarket or refurbished equipment but we don't > >> want to start off with equipment that has no future of expanding. > >> > >> > >> > >> Any suggestions, success or horror stories are appreciated. ;) > >> > >> > >> > >> Eric > >> > >> > >> > >> ===== > >> > >> Eric Merkel > >> > >> MetaLINK Technologies, Inc. > >> > >> Email: merkel at metalink.net > >> > > > > > > > > > > > ------------------------------ > > Message: 10 > Date: Wed, 20 Oct 2010 12:03:46 -0400 (EDT) > From: "Justin M. Streiner" > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: "nanog at nanog.org" > Message-ID: > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Wed, 20 Oct 2010, Joel Esler wrote: > > > Now, if we could get everyone that has these gigantic /8's (or multiple > > of them) that aren't using them to give some back, that'd be great. > > > > Thank you interop for setting the example. > > Sure, it would be a nice gesture if MIT/HP/Ford/Xerox/Halliburton/etc gave > back the chunks of the /8s they weren't using, but it wouldn't > significantly affect when the IPv4 well runs dry. Also, without knowing > how those organizations have used the space internally, such an > altruistic gesture could also come at the cost of having to de-aggregate > a bunch of advertisements in BGP. > > The law of diminishing returns comes into play. > jms > > > On Oct 20, 2010, at 10:43 AM, Nick Hilliard wrote: > > > >> Thank you Interop - for performing an outstanding act of altruism. > >> > >> John, could you provide more details at this stage on how much address > space was returned to ARIN? > >> > >> Nick > >> > >> On 20/10/2010 14:34, John Curran wrote: > >>> FYI, > >>> /John > >>> > >>> ---- > >>> https://www.arin.net/announcements/2010/20101020.html > >>> > >>> > >>> Posted: Wednesday, 20 October 2010 > >>> > >>> ARIN today recognizes Interop, an organization with a long-standing > presence in the Internet industry, for returning its unneeded Internet > Protocol version 4 (IPv4) address space. > >>> > >>> Interop was originally allocated a /8 before ARIN's existence and the > availability of smaller-sized address blocks. The organization recently > realized it was only using a small portion of its address block and that > returning the remainder to ARIN would be for the greater good of the > Internet community. > >>> > >>> ARIN will accept the returned space and not reissue it for a short > period, per existing operational procedure. After the hold period, ARIN will > follow global policy at that time and return it to the global free pool or > distribute the space to those organizations in the ARIN region with > documented need, as appropriate. > >>> > >>> With less than 5% of the IPv4 address space left in the global free > pool, ARIN warns that Interop's return will not significantly extend the > life of IPv4. ARIN continues to emphasize the need for all Internet > stakeholders to adopt the next generation of Internet Protocol, IPv6. > >>> > >>> Regards, > >>> > >>> Communications and Member Services > >>> American Registry for Internet Numbers > >>> > >> > >> > > > > -- > > Joel Esler > > http://www.joelesler.net > > > > > > > > > > ------------------------------ > > Message: 11 > Date: Wed, 20 Oct 2010 12:04:29 -0400 > From: Ernie Rubi > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: Joe Maimon > Cc: John Curran , "nanog at nanog.org" > > Message-ID: <107A762E-D0A0-4CBA-92D8-376FCD6E266B at cs.fiu.edu> > Content-Type: text/plain; charset=us-ascii > > I don't think ARIN (or any other RIR) wants people to think this way. > > Appreciation and value are words that most folks at ICANN don't want > network engineers to associate with IP addresses. > > "The real value is in routing"; is the party line. > > STLS to me is kind of double speak, ARIN says: "this isn't a capital > resource", but yet if you go through us and list your 'unused' blocks in > this space, we don't care what financial transaction happens behind the > scenes. > > Maybe John can shed more light on this. > > For some background, go over to the Internet-history mailing list, which > included a very lively discussion of "ownership interest" in IP addresses. > > Ernie > > On Oct 20, 2010, at 11:45 AM, Joe Maimon wrote: > > > > > So would it be more logical for all those willing to return do so only > after depletion when the impact and resulting appreciation is likely to be > greater? > > > > Plus, those less altruistic could weigh the options better after real > value is associated with the scarce resource. > > > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 33, Issue 91 > ************************************* > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * From bruns at 2mbit.com Wed Oct 20 12:53:12 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Wed, 20 Oct 2010 11:53:12 -0600 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <62EADAE5-5D10-4749-AD1F-9343A457FC5A@arin.net> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBF1D3D.6000108@2mbit.com> <62EADAE5-5D10-4749-AD1F-9343A457FC5A@arin.net> Message-ID: <4CBF2C88.1070603@2mbit.com> On 10/20/10 11:34 AM, John Curran wrote: > On Oct 20, 2010, at 12:47 PM, Brielle Bruns wrote: >>> >>> Not to stir an already boiling over pot and all, but is there any >>> kind of report or documentation on releasing of space from >>> countries other then the North American region? > You're not going to find a lot of large allocations which are unused > in other regions, predominantly because these allocations where made > at the earliest time of the Internet to organizations that were > mostly in the ARIN region. True, I didn't take that into account. :) > >>> I'd hate to think that the rest of the world thinks that the US >>> should be the one to give up all their space so that they can >>> continue to hand out space like candy... > While it is true that some regions seem to be experiencing a real > surge in IPv4 demand recently, it's also important to remember > that*all* of the address space is for the Internet community at > large, based on documented need, on a first-come, first-serve basis. > It's actually "global Internet address space"; this is a fundamental > principle of the Internet Registry system as noted in RFC 2050. Understood, I'm just expressing concern over the current situation of IPv4 exhaustion. As a spam fighter, I tend to see bursts of spam from newly allocated space in various regions which leaves me scratching my head as to why some places keep asking for more space and getting it so easily. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From will at harg.net Wed Oct 20 12:53:45 2010 From: will at harg.net (Will Hargrave) Date: Wed, 20 Oct 2010 18:53:45 +0100 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBF1D3D.6000108@2mbit.com> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBF1D3D.6000108@2mbit.com> Message-ID: <4CBF2CA9.8040507@harg.net> On 20/10/10 17:47, Brielle Bruns wrote: > Not to stir an already boiling over pot and all, but is there any kind of > report or documentation on releasing of space from countries other then the > North American region? Really it's mainly US govt agencies, defence contractors, etc from the dawn of the Internet who hold legacy class A space of this type. This space was pre-RIR which means it was not assigned on the same (broadly similar) global policies as the majority of address space in the modern era. On that basis, there's nothing big for other regions to 'give up'. One exception is the UK government with two /8s. http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.txt http://en.wikipedia.org/wiki/List_of_assigned_/8_IPv4_address_blocks From rudi.daniel at gmail.com Wed Oct 20 13:18:08 2010 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 20 Oct 2010 14:18:08 -0400 Subject: NANOG Digest, Vol 33, Issue 93 In-Reply-To: References: Message-ID: I believe that the vast majority of the legacy space is in fact in the US. RD > Not to stir an already boiling over pot and all, but is there any kind > of report or documentation on releasing of space from countries other > then the North American region? > > I'd hate to think that the rest of the world thinks that the US should > be the one to give up all their space so that they can continue to hand > out space like candy... > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > > > > ------------------------------ > > Message: 2 > Date: Wed, 20 Oct 2010 17:52:00 +0100 > From: "Stephen D. Strowes" > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: John Curran > Cc: "nanog at nanog.org" > Message-ID: <1287593520.11548.15.camel at carney> > Content-Type: text/plain; charset="UTF-8" > > On Wed, 2010-10-20 at 17:40 +0100, John Curran wrote: > > > Also makes me wonder if there are historical versions of this registry > > > available. If reclamation of large blocks such as this becomes > > > commonplace, will many of the legacy allocations simply become > > > footnotes? (In the registry document, as well as in history?) > > > > This has already happened in many cases; address blocks previously > > held by US DoD, BBN, Stanford were returned, held for a period, > > and then reissued. > > Indeed yes. And these returned blocks aren't noted in the IANA registry > (for good reason I guess; the registry is meant to be current.) Is this > historical information noted anywhere? > > > -S. > > > > > > ------------------------------ > > Message: 3 > Date: Wed, 20 Oct 2010 10:06:33 -0700 > From: Doug Barton > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: nanog at nanog.org > Message-ID: <4CBF2199.4010700 at dougbarton.us> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/20/2010 7:13 AM, Randy Bush wrote: > > i think this is cool, but ... > > > >> ARIN will follow global policy at that time and return it to the > >> global free pool or distribute the space to those organizations in the > >> ARIN region with documented need, as appropriate. > > > > i know the us has the world series, but global> arin region > > I would like to join the chorus of applause for Interop's generosity. I > agree with those who've said that this only buys us a little more time, > but they did the right thing, and we should applaud them for that; along > with the DOD and others who have returned their unneeded space. > > As for the fact that the block was released to ARIN as opposed to going > back in the free pool, the effect may ultimately be the same. > Allocations from IANA to the RIRs happen under the policy posted at > http://www.icann.org/en/general/allocation-IPv4-rirs.html. The > determination of when to allocate a new /8 is based on the amount of > free space that the RIR has on hand at the time of the request. There > are 12 /8s remaining atm, and 5 of those will automatically be allocated > 1 per RIR when the other 7 have been allocated under the normal policy. > I am confident that ARIN will also do the right thing here and include > the /8 from Interop in their free space calculation before requesting an > allocation of one of the 7 /8s in the free pool. > > > hth, > > Doug > > -- > > Breadth of IT experience, and | Nothin' ever doesn't change, > depth of knowledge in the DNS. | but nothin' changes much. > Yours for the right price. :) | -- OK Go > http://SupersetSolutions.com/ > > > > ------------------------------ > > Message: 4 > Date: Wed, 20 Oct 2010 13:34:22 -0400 > From: John Curran > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: Brielle Bruns > Cc: "nanog at nanog.org" > Message-ID: <62EADAE5-5D10-4749-AD1F-9343A457FC5A at arin.net> > Content-Type: text/plain; charset="us-ascii" > > On Oct 20, 2010, at 12:47 PM, Brielle Bruns wrote: > > > > Not to stir an already boiling over pot and all, but is there any kind of > report or documentation on releasing of space from countries other then the > North American region? > > You're not going to find a lot of large allocations which are unused in > other regions, predominantly because these allocations where made at the > earliest time of the Internet to organizations that were mostly in the > ARIN region. > > > I'd hate to think that the rest of the world thinks that the US should be > the one to give up all their space so that they can continue to hand out > space like candy... > > While it is true that some regions seem to be experiencing a real surge > in IPv4 demand recently, it's also important to remember that *all* of the > address space is for the Internet community at large, based on documented > need, on a first-come, first-serve basis. It's actually "global Internet > address space"; this is a fundamental principle of the Internet Registry > system as noted in RFC 2050. > > /John > > John Curran > President and CEO > ARIN > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 20 Oct 2010 13:41:19 -0400 > From: Rudolph Daniel > Subject: Re: NANOG Digest, Vol 33, Issue 91 > To: nanog at nanog.org > Message-ID: > > > > Content-Type: text/plain; charset=ISO-8859-1 > > We all are waiving flags about the return of one solitary /8 to ARIN, > (which > is a good thing) but should we not waive flags about new v6 networks too? > > Let us waive the flags also for the v6 adopters...I think we need to > evangelize v6 even more than we are already doing. > > RD > > > > > Date: Wed, 20 Oct 2010 11:27:41 -0400 > > From: Christopher Morrow > > Subject: Re: ARIN recognizes Interop for return of more than 99% of > > 45/8 address block > > To: Joel Esler > > Cc: John Curran , "nanog at nanog.org" > > > > Message-ID: > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Wed, Oct 20, 2010 at 11:11 AM, Joel Esler wrote: > > > Now, if we could get everyone that has these gigantic /8's (or multiple > > of them) that aren't using them to give some back, that'd be great. > > > > it's nice that interop did a nice thing here, but seriously, this is > > ~3 months of usage... there is no saving the move to v6, the bottom's > > going to fall out on or about june 2011 it seems. > > > > > > > > ------------------------------ > > > > Message: 2 > > Date: Wed, 20 Oct 2010 11:28:44 -0400 > > From: John Curran > > Subject: Re: ARIN recognizes Interop for return of more than 99% of > > 45/8 address block > > To: Christopher Morrow > > Cc: "nanog at nanog.org Operators Group" > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > > > On Oct 20, 2010, at 11:26 AM, Christopher Morrow wrote: > > > > > On Wed, Oct 20, 2010 at 10:43 AM, Nick Hilliard > wrote: > > >> Thank you Interop - for performing an outstanding act of altruism. > > >> > > >> John, could you provide more details at this stage on how much address > > space > > >> was returned to ARIN? > > > > > > less than 3 months supply at the going drain rate. > > > > Not to be depressing, but a /8 (or 99% of one :-) is potentially less > > than one month's drain on the global IPv4 free pool, if one considers > > the allocations over the last 12 months to be predictive. > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > > > > > > > > ------------------------------ > > > > Message: 3 > > Date: Wed, 20 Oct 2010 11:29:58 -0400 > > From: Curtis Maurand > > Subject: Re: Recommendations for Metro-Ethernet Equipment > > To: nanog at nanog.org > > Message-ID: <4CBF0AF6.9030207 at xyonet.com> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > I'd add Alcatel to that list. > > > > On 10/20/2010 11:24 AM, Eric Merkel wrote: > > > I've been tasked with making a recommendation for the core and access > > > equipment for a small metro-ethernet network. We're probably talking at > > max > > > 200-300 subs split between two termination points. Most customers will > > > probably be at speeds of 100M or less. We'd like the backbone to be 10G > > and > > > be MPLS capable. That being said some of the companies we've been > looking > > at > > > are > > > > > > > > > > > > Cisco > > > > > > Extreme > > > > > > Brocade > > > > > > Adtran > > > > > > Occam > > > > > > Zhone > > > > > > > > > > > > We're looking to build the network in a cost effective manner so we're > > not > > > opposed to doing using aftermarket or refurbished equipment but we > don't > > > want to start off with equipment that has no future of expanding. > > > > > > > > > > > > Any suggestions, success or horror stories are appreciated. ;) > > > > > > > > > > > > Eric > > > > > > > > > > > > ===== > > > > > > Eric Merkel > > > > > > MetaLINK Technologies, Inc. > > > > > > Email: merkel at metalink.net > > > > > > > > > > > > > ------------------------------ > > > > Message: 4 > > Date: Wed, 20 Oct 2010 11:33:01 -0400 > > From: John Curran > > Subject: Re: ARIN recognizes Interop for return of more than 99% of > > 45/8 address block > > To: Christopher Morrow > > Cc: "nanog at nanog.org Operators Group" > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > > > On Oct 20, 2010, at 11:27 AM, Christopher Morrow wrote: > > > > > > it's nice that interop did a nice thing here, but seriously, this is > > > ~3 months of usage... there is no saving the move to v6, the bottom's > > > going to fall out on or about june 2011 it seems. > > > > I agree with Chris; this (and any other returns) won't change the IPv4 > > depletion/IPv6 deployment timeline substantially, but it's also true > > we have folks who are just now realizing IPv4 depletion is happening > > and returned address space may make the difference for those who need > > just a bit more time... > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > > > > > > > > ------------------------------ > > > > Message: 5 > > Date: Wed, 20 Oct 2010 11:35:19 -0400 > > From: Christopher Morrow > > Subject: Re: ARIN recognizes Interop for return of more than 99% of > > 45/8 address block > > To: John Curran > > Cc: "nanog at nanog.org Operators Group" > > Message-ID: > > > > > > > > > > Content-Type: text/plain; charset=ISO-8859-1 > > > > On Wed, Oct 20, 2010 at 11:28 AM, John Curran wrote: > > > On Oct 20, 2010, at 11:26 AM, Christopher Morrow wrote: > > > > >> less than 3 months supply at the going drain rate. > > > > > > Not to be depressing, but a /8 (or 99% of one :-) is potentially less > > > than one month's drain on the global IPv4 free pool, if one considers > > > the allocations over the last 12 months to be predictive. > > > > yes, sorry.. since this was returned to ARIN, I assumed the ARIN > > region drain rate. > > > > > > > > ------------------------------ > > > > Message: 6 > > Date: Wed, 20 Oct 2010 11:37:55 -0400 > > From: John Curran > > Subject: Re: ARIN recognizes Interop for return of more than 99% of > > 45/8 address block > > To: Jeroen Massar > > Cc: "nanog at nanog.org Operators Group" > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > > > On Oct 20, 2010, at 11:24 AM, Jeroen Massar wrote: > > > > > > The problem with that is indeed in that little part about "aren't using > > > them", if even only 50% is in use because one allocated it quite > > > sparsely you won't be able to quickly clean it up and return it. > > > > Correct. It might make sense to do so, if you could recover the costs of > > the work involved. This is the reasoning behind the Specified Transfer > > policy that was recently adopted; it allows (once we're at depletion) for > > parties to free up address space and get compensated. It's goal is not > to > > provide a windfall for those holding unused space; in theory, those with > > unused address space should be returning it already if they can easily do > > so. > > > > > One can of course wonder if they are supposed to use that or not. > > > The fact that they do not have reverse DNS delegation for it says quite > > > a bit already of course. > > > > One of the other benefits of improved utilization for returned space > > is less space which is "sitting idle" and available to be hijacked. > > > > /John > > > > John Curran > > President and CEO > > ARIN > > > > > > > > > > ------------------------------ > > > > Message: 7 > > Date: Wed, 20 Oct 2010 11:40:57 -0400 > > From: John Curran > > Subject: Re: ARIN recognizes Interop for return of more than 99% of > > 45/8 address block > > To: Christopher Morrow > > Cc: "nanog at nanog.org Operators Group" > > Message-ID: > > Content-Type: text/plain; charset="us-ascii" > > > > On Oct 20, 2010, at 11:35 AM, Christopher Morrow wrote: > > > > > yes, sorry.. since this was returned to ARIN, I assumed the ARIN > > > region drain rate. > > > > Ah, good point. It may end up in the global pool, so comparison to > > either drain rate is quite reasonable. > > > > /John > > > > > > > > ------------------------------ > > > > Message: 8 > > Date: Wed, 20 Oct 2010 11:45:20 -0400 > > From: Joe Maimon > > Subject: Re: ARIN recognizes Interop for return of more than 99% of > > 45/8 address block > > To: Christopher Morrow > > Cc: John Curran , "nanog at nanog.org" > > > > Message-ID: <4CBF0E90.6070403 at ttec.com> > > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > > > > > > > Christopher Morrow wrote: > > > On Wed, Oct 20, 2010 at 10:43 AM, Nick Hilliard > wrote: > > >> Thank you Interop - for performing an outstanding act of altruism. > > >> > > >> John, could you provide more details at this stage on how much address > > space > > >> was returned to ARIN? > > > > > > less than 3 months supply at the going drain rate. > > > > > > > So would it be more logical for all those willing to return do so only > > after depletion when the impact and resulting appreciation is likely to > > be greater? > > > > Plus, those less altruistic could weigh the options better after real > > value is associated with the scarce resource. > > > > > > Joe > > > > > > > > > > ------------------------------ > > > > Message: 9 > > Date: Wed, 20 Oct 2010 12:02:16 -0400 > > From: Francois Menard > > Subject: Re: Recommendations for Metro-Ethernet Equipment > > To: Curtis Maurand > > Cc: nanog at nanog.org > > Message-ID: > > Content-Type: text/plain; charset=us-ascii > > > > We just bought a fair amount of MRV Optiswitches for that same purpose. > > > > F. > > > > On 2010-10-20, at 11:29 AM, Curtis Maurand wrote: > > > > > I'd add Alcatel to that list. > > > > > > On 10/20/2010 11:24 AM, Eric Merkel wrote: > > >> I've been tasked with making a recommendation for the core and access > > >> equipment for a small metro-ethernet network. We're probably talking > at > > max > > >> 200-300 subs split between two termination points. Most customers will > > >> probably be at speeds of 100M or less. We'd like the backbone to be > 10G > > and > > >> be MPLS capable. That being said some of the companies we've been > > looking at > > >> are > > >> > > >> > > >> > > >> Cisco > > >> > > >> Extreme > > >> > > >> Brocade > > >> > > >> Adtran > > >> > > >> Occam > > >> > > >> Zhone > > >> > > >> > > >> > > >> We're looking to build the network in a cost effective manner so we're > > not > > >> opposed to doing using aftermarket or refurbished equipment but we > don't > > >> want to start off with equipment that has no future of expanding. > > >> > > >> > > >> > > >> Any suggestions, success or horror stories are appreciated. ;) > > >> > > >> > > >> > > >> Eric > > >> > > >> > > >> > > >> ===== > > >> > > >> Eric Merkel > > >> > > >> MetaLINK Technologies, Inc. > > >> > > >> Email: merkel at metalink.net > > >> > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > Message: 10 > > Date: Wed, 20 Oct 2010 12:03:46 -0400 (EDT) > > From: "Justin M. Streiner" > > Subject: Re: ARIN recognizes Interop for return of more than 99% of > > 45/8 address block > > To: "nanog at nanog.org" > > Message-ID: > > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > > On Wed, 20 Oct 2010, Joel Esler wrote: > > > > > Now, if we could get everyone that has these gigantic /8's (or multiple > > > of them) that aren't using them to give some back, that'd be great. > > > > > > Thank you interop for setting the example. > > > > Sure, it would be a nice gesture if MIT/HP/Ford/Xerox/Halliburton/etc > gave > > back the chunks of the /8s they weren't using, but it wouldn't > > significantly affect when the IPv4 well runs dry. Also, without knowing > > how those organizations have used the space internally, such an > > altruistic gesture could also come at the cost of having to de-aggregate > > a bunch of advertisements in BGP. > > > > The law of diminishing returns comes into play. > > jms > > > > > On Oct 20, 2010, at 10:43 AM, Nick Hilliard wrote: > > > > > >> Thank you Interop - for performing an outstanding act of altruism. > > >> > > >> John, could you provide more details at this stage on how much address > > space was returned to ARIN? > > >> > > >> Nick > > >> > > >> On 20/10/2010 14:34, John Curran wrote: > > >>> FYI, > > >>> /John > > >>> > > >>> ---- > > >>> https://www.arin.net/announcements/2010/20101020.html > > >>> > > >>> > > >>> Posted: Wednesday, 20 October 2010 > > >>> > > >>> ARIN today recognizes Interop, an organization with a long-standing > > presence in the Internet industry, for returning its unneeded Internet > > Protocol version 4 (IPv4) address space. > > >>> > > >>> Interop was originally allocated a /8 before ARIN's existence and the > > availability of smaller-sized address blocks. The organization recently > > realized it was only using a small portion of its address block and that > > returning the remainder to ARIN would be for the greater good of the > > Internet community. > > >>> > > >>> ARIN will accept the returned space and not reissue it for a short > > period, per existing operational procedure. After the hold period, ARIN > will > > follow global policy at that time and return it to the global free pool > or > > distribute the space to those organizations in the ARIN region with > > documented need, as appropriate. > > >>> > > >>> With less than 5% of the IPv4 address space left in the global free > > pool, ARIN warns that Interop's return will not significantly extend the > > life of IPv4. ARIN continues to emphasize the need for all Internet > > stakeholders to adopt the next generation of Internet Protocol, IPv6. > > >>> > > >>> Regards, > > >>> > > >>> Communications and Member Services > > >>> American Registry for Internet Numbers > > >>> > > >> > > >> > > > > > > -- > > > Joel Esler > > > http://www.joelesler.net > > > > > > > > > > > > > > > > > ------------------------------ > > > > Message: 11 > > Date: Wed, 20 Oct 2010 12:04:29 -0400 > > From: Ernie Rubi > > Subject: Re: ARIN recognizes Interop for return of more than 99% of > > 45/8 address block > > To: Joe Maimon > > Cc: John Curran , "nanog at nanog.org" > > > > Message-ID: <107A762E-D0A0-4CBA-92D8-376FCD6E266B at cs.fiu.edu> > > Content-Type: text/plain; charset=us-ascii > > > > I don't think ARIN (or any other RIR) wants people to think this way. > > > > Appreciation and value are words that most folks at ICANN don't want > > network engineers to associate with IP addresses. > > > > "The real value is in routing"; is the party line. > > > > STLS to me is kind of double speak, ARIN says: "this isn't a capital > > resource", but yet if you go through us and list your 'unused' blocks in > > this space, we don't care what financial transaction happens behind the > > scenes. > > > > Maybe John can shed more light on this. > > > > For some background, go over to the Internet-history mailing list, which > > included a very lively discussion of "ownership interest" in IP > addresses. > > > > Ernie > > > > On Oct 20, 2010, at 11:45 AM, Joe Maimon wrote: > > > > > > > > So would it be more logical for all those willing to return do so only > > after depletion when the impact and resulting appreciation is likely to > be > > greater? > > > > > > Plus, those less altruistic could weigh the options better after real > > value is associated with the scarce resource. > > > > > > > > > > > > ------------------------------ > > > > _______________________________________________ > > NANOG mailing list > > NANOG at nanog.org > > https://mailman.nanog.org/mailman/listinfo/nanog > > > > End of NANOG Digest, Vol 33, Issue 91 > > ************************************* > > > > > > -- > > Rudi Daniel > *danielcharles consulting< > http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774 > > > **1-784 498 8277< > http://www.facebook.com/pages/Kingstown-Saint-Vincent-and-the-Grenadines/DanielCharles/153611257984774 > > > * > * > * > > > ------------------------------ > > Message: 6 > Date: Wed, 20 Oct 2010 11:53:12 -0600 > From: Brielle Bruns > Subject: Re: ARIN recognizes Interop for return of more than 99% of > 45/8 address block > To: "nanog at nanog.org" > Message-ID: <4CBF2C88.1070603 at 2mbit.com> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 10/20/10 11:34 AM, John Curran wrote: > > On Oct 20, 2010, at 12:47 PM, Brielle Bruns wrote: > >>> > >>> Not to stir an already boiling over pot and all, but is there any > >>> kind of report or documentation on releasing of space from > >>> countries other then the North American region? > > You're not going to find a lot of large allocations which are unused > > in other regions, predominantly because these allocations where made > > at the earliest time of the Internet to organizations that were > > mostly in the ARIN region. > > > True, I didn't take that into account. :) > > > > >>> I'd hate to think that the rest of the world thinks that the US > >>> should be the one to give up all their space so that they can > >>> continue to hand out space like candy... > > While it is true that some regions seem to be experiencing a real > > surge in IPv4 demand recently, it's also important to remember > > that*all* of the address space is for the Internet community at > > large, based on documented need, on a first-come, first-serve basis. > > It's actually "global Internet address space"; this is a fundamental > > principle of the Internet Registry system as noted in RFC 2050. > > Understood, I'm just expressing concern over the current situation of > IPv4 exhaustion. As a spam fighter, I tend to see bursts of spam from > newly allocated space in various regions which leaves me scratching my > head as to why some places keep asking for more space and getting it so > easily. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG at nanog.org > https://mailman.nanog.org/mailman/listinfo/nanog > > End of NANOG Digest, Vol 33, Issue 93 > ************************************* > -- Rudi Daniel *danielcharles consulting **1-784 498 8277 * * * From mpetach at netflight.com Wed Oct 20 14:48:40 2010 From: mpetach at netflight.com (Matthew Petach) Date: Wed, 20 Oct 2010 12:48:40 -0700 Subject: NANOG Digest, Vol 33, Issue 91 In-Reply-To: References: Message-ID: On Wed, Oct 20, 2010 at 10:41 AM, Rudolph Daniel wrote: > We all are waiving flags about the return of one solitary /8 to ARIN, (which > is a good thing) ?but should we not waive flags about new v6 networks too? > > Let us waive the flags also for the v6 adopters...I think we need to > evangelize v6 even more than we are already doing. > > RD *heh* If we're going to waive anything, let it be fees. ;D Waving, on the other hand, would be an exercise best left to the flags. ^_^; Matt (*takes off the pedant hat, and slips back into the darkest corner of the room*) From jeroen at mompl.net Wed Oct 20 14:51:09 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 20 Oct 2010 12:51:09 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3328.7090205@unfix.org> References: <4CBC3328.7090205@unfix.org> Message-ID: <4CBF482D.3030601@mompl.net> Jeroen Massar wrote: > (And the spammers will take the rest...) I am afraid so too. > (PS: There seems to be a trend for people calling themselves"IPv6 > Pioneers" as they recently did something with IPv6, if you didn't play > in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years > late) Who died and made you boss of "Pioneer Naming Authority"? Greetings, Jeroen (IPv6 Pioneer, Network Engineer, Software Engineer, Linux Guru, Steve Jobs fanboy (ok, that was a lie ;-)) -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From jason at lixfeld.ca Wed Oct 20 14:57:19 2010 From: jason at lixfeld.ca (Jason Lixfeld) Date: Wed, 20 Oct 2010 15:57:19 -0400 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: <022801cb706a$ead9d5e0$c08d81a0$@net> References: <022801cb706a$ead9d5e0$c08d81a0$@net> Message-ID: On 2010-10-20, at 11:24 AM, Eric Merkel wrote: > Any suggestions, success or horror stories are appreciated. ;) I've been going through pretty much the same exercise looking for a decent PE for almost two years. Our requirements were for a PE device that had between 12-24 ports (in a perfect world, mixed mode 10/100/1000 copper + SFP), 10G uplinks, EoMPLS, MPLS VPN, DHCP server, port-protect/UNI (or similar) capabilities, DC power and a small footprint (1RU) Of all the ones we looked at (Juniper, Cisco, Extreme, Brocade, MRV, Alcatel) initially, MRV was the only contender. The rest either didn't have a product, or their offering didn't meet various points within our criteria. As such, we bought a bunch of MRVs in early 2009 and after four months of trial and error, we yanked every single one out of the network. From a physical perspective, the box was perfect. Port density was perfect, mixed-mode ports, promised a 10G uplink product soon, size was perfect, power was perfect, we thought we had it nailed. Unfortunately there are no words to describe how terrible the software was. The CLI took a little getting used to, which is pretty much par for the course when you're dealing with a new vendor, but the code itself was just absolutely broken, everywhere. Duplex issues, LDP constantly crashing taking the box with it, OSPF issues, the list went on and on. To their credit, they flew engineers up from the US and they were quite committed to making stuff work, but at the end of the day, they just couldn't make it go. We pulled the plug in May 2009 and I haven't heard a thing about their product since then, so maybe they've got it all together. While meeting with Juniper a few months later about a different project, they said they had a product that might fit our needs. The EX4200. As such, we had a few of these loaned to our lab for a few months to put through their paces, from a features and interoperability perspective. They work[1] and they seem to work well. The show stopper was provisioning[1] and size. The box is massive, albeit it is still 1U. [1] (I'm not a Juniper guy, so my recollection on specific terms and jargon may be a bit off kilter) they only support ccc, which makes provisioning an absolute nightmare. From my experience with Cisco and MRV, you only have to configure the EoMPLS vc. On the EX4200, you have to create the LSPs as well. To get a ccc working, the JunOS code block was far larger and much more involved per vc than the single line Cisco equivalent. To create the LSPs was, I believe, two more equally large sized code blocks. At the end of the day, it was just too involved. We needed something simpler. About the same time that we started to evaluate the EX4200, Cisco had pitched us on their (then alpha) Whales platform. It looked promising (MRV still had the best form factor) and we expressed our interest in getting a beta unit in as soon as we were able to. This is now known as the ME3600 and ME3800 platform and we've been testing a beta unit in our lab for the past few months. This is the platform we have chosen. It's not perfect, but our gripes have more to do with form factor (it's 1RU, but it's a bit deeper than what we'd like) and port densities (no mixed mode ports) than software or features. We've been pretty pleased with it's feature set and performance, but this hasn't seen any real world action, so who knows how that will turn out. If you're asking more about a P router or P/PE hybrid, we've also just ordered a few ASR9000s under try-and-buy as P/PEs to close up the chains of ME3600s that will start to be deployed in our remote sites. A Juniper MX would certainly work well here too, and it seems to interoperate rather well with the ME3600s, so that's certainly an option, but for us, we think it will work more in our favor to go with the ASRs in the core, but if not, we'd ship them back under the try-and-buy and get Junipers instead. Hope that helps. From joelja at bogus.com Wed Oct 20 15:19:43 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 20 Oct 2010 13:19:43 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBF482D.3030601@mompl.net> References: <4CBC3328.7090205@unfix.org> <4CBF482D.3030601@mompl.net> Message-ID: <4CBF4EDF.5070603@bogus.com> On 10/20/10 12:51 PM, Jeroen van Aart wrote: > Jeroen Massar wrote: >> (And the spammers will take the rest...) > > I am afraid so too. > >> (PS: There seems to be a trend for people calling themselves"IPv6 >> Pioneers" as they recently did something with IPv6, if you didn't play >> in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years >> late) Oddly the nameserver in my closet seems to still have /var/named/reverse/3.1.8.e.f.f.3.ip6.arpa in it's collection of zones. > Who died and made you boss of "Pioneer Naming Authority"? If you remember it, you weren't there. > Greetings, > Jeroen (IPv6 Pioneer, Network Engineer, Software Engineer, Linux Guru, > Steve Jobs fanboy (ok, that was a lie ;-)) > From bmanning at vacation.karoshi.com Wed Oct 20 15:43:11 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Wed, 20 Oct 2010 20:43:11 +0000 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBF4EDF.5070603@bogus.com> References: <4CBC3328.7090205@unfix.org> <4CBF482D.3030601@mompl.net> <4CBF4EDF.5070603@bogus.com> Message-ID: <20101020204311.GA32417@vacation.karoshi.com.> On Wed, Oct 20, 2010 at 01:19:43PM -0700, Joel Jaeggli wrote: > On 10/20/10 12:51 PM, Jeroen van Aart wrote: > > Jeroen Massar wrote: > >> (And the spammers will take the rest...) > > > > I am afraid so too. > > > >> (PS: There seems to be a trend for people calling themselves"IPv6 > >> Pioneers" as they recently did something with IPv6, if you didn't play > >> in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years > >> late) > > Oddly the nameserver in my closet seems to still have > /var/named/reverse/3.1.8.e.f.f.3.ip6.arpa in it's collection of zones. uncoving old battle scars... f.5.ip6.int. is still hanging around.. > > Who died and made you boss of "Pioneer Naming Authority"? > > If you remember it, you weren't there. > i may not remember, but the zone files are still here. --bill From bross at pobox.com Wed Oct 20 15:47:21 2010 From: bross at pobox.com (Brandon Ross) Date: Wed, 20 Oct 2010 16:47:21 -0400 (EDT) Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBF09BE.50507@unfix.org> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF09BE.50507@unfix.org> Message-ID: On Wed, 20 Oct 2010, Jeroen Massar wrote: > [John, is 45.127.0.0/16 one of the two blocks they keep, or is it > hijacked already? :) ] I can authoritatively say, yes it is. We (Interop) are not announcing any part of 45/8 at the moment, and don't plan to do so until the return is complete. I'll attempt to contact the players involved here and get 45.127/16 taken down. If anyone is listening that can help, it would be appreciated. I'm not subcribed to NANOG with the official address, but I can be reached at bross at interop.net as well. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From joel.esler at me.com Wed Oct 20 15:55:39 2010 From: joel.esler at me.com (Joel Esler) Date: Wed, 20 Oct 2010 16:55:39 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBF0E90.6070403@ttec.com> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF0E90.6070403@ttec.com> Message-ID: <824BB3F5-A58F-4FD1-9461-E26662183409@me.com> On Oct 20, 2010, at 11:45 AM, Joe Maimon wrote: > Christopher Morrow wrote: >> On Wed, Oct 20, 2010 at 10:43 AM, Nick Hilliard wrote: >>> Thank you Interop - for performing an outstanding act of altruism. >>> >>> John, could you provide more details at this stage on how much address space >>> was returned to ARIN? >> >> less than 3 months supply at the going drain rate. >> > > So would it be more logical for all those willing to return do so only after depletion when the impact and resulting appreciation is likely to be greater? That was my overall point. There are lots of places that /8, and multiple ones at that that aren't using them. I'm not saying it'll put off going to v6 for years, but it'll help in our current time. -- Joel Esler http://www.joelesler.net From drc at virtualized.org Wed Oct 20 15:58:18 2010 From: drc at virtualized.org (David Conrad) Date: Wed, 20 Oct 2010 13:58:18 -0700 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <824BB3F5-A58F-4FD1-9461-E26662183409@me.com> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF0E90.6070403@ttec.com> <824BB3F5-A58F-4FD1-9461-E26662183409@me.com> Message-ID: <3E11F5DD-D97D-4D15-8E0B-211E2B2C61FB@virtualized.org> Joel, On Oct 20, 2010, at 1:55 PM, Joel Esler wrote: > There are lots of places that /8, and multiple ones at that that aren't using them. Which /8s are those? Thanks, -drc From sikandar.raman at gmail.com Wed Oct 20 16:24:31 2010 From: sikandar.raman at gmail.com (Ramanpreet Singh) Date: Wed, 20 Oct 2010 14:24:31 -0700 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: References: <022801cb706a$ead9d5e0$c08d81a0$@net> Message-ID: 7600's/ASR 1k Have you looked in to Ciso ME 3600X/ME 3800X series? Without a bias these are the top notch products in the market for Metro E. -Raman On Wed, Oct 20, 2010 at 12:57 PM, Jason Lixfeld wrote: > On 2010-10-20, at 11:24 AM, Eric Merkel wrote: > >> Any suggestions, success or horror stories are appreciated. ;) > > I've been going through pretty much the same exercise looking for a decent PE for almost two years. ?Our requirements were for a PE device that had between 12-24 ports (in a perfect world, mixed mode 10/100/1000 copper + SFP), 10G uplinks, EoMPLS, MPLS VPN, DHCP server, port-protect/UNI (or similar) capabilities, DC power and a small footprint (1RU) > > Of all the ones we looked at (Juniper, Cisco, Extreme, Brocade, MRV, Alcatel) initially, MRV was the only contender. ?The rest either didn't have a product, or their offering didn't meet various points within our criteria. > > As such, we bought a bunch of MRVs in early 2009 and after four months of trial and error, we yanked every single one out of the network. ?From a physical perspective, the box was perfect. ?Port density was perfect, mixed-mode ports, promised a 10G uplink product soon, size was perfect, power was perfect, we thought we had it nailed. ?Unfortunately there are no words to describe how terrible the software was. ?The CLI took a little getting used to, which is pretty much par for the course when you're dealing with a new vendor, but the code itself was just absolutely broken, everywhere. ?Duplex issues, LDP constantly crashing taking the box with it, OSPF issues, the list went on and on. ?To their credit, they flew engineers up from the US and they were quite committed to making stuff work, but at the end of the day, they just couldn't make it go. ?We pulled the plug in May 2009 and I haven't heard a thing about their product since then, so maybe they've got it all together. > > While meeting with Juniper a few months later about a different project, they said they had a product that might fit our needs. ?The EX4200. ?As such, we had a few of these loaned to our lab for a few months to put through their paces, from a features and interoperability perspective. ?They work[1] and they seem to work well. ?The show stopper was provisioning[1] and size. ?The box is massive, albeit it is still 1U. > > [1] (I'm not a Juniper guy, so my recollection on specific terms and jargon may be a bit off kilter) they only support ccc, which makes provisioning an absolute nightmare. ?From my experience with Cisco and MRV, you only have to configure the EoMPLS vc. ?On the EX4200, you have to create the LSPs as well. ?To get a ccc working, the JunOS code block was far larger and much more involved per vc than the single line Cisco equivalent. ?To create the LSPs was, I believe, two more equally large sized code blocks. ?At the end of the day, it was just too involved. ?We needed something simpler. > > About the same time that we started to evaluate the EX4200, Cisco had pitched us on their (then alpha) Whales platform. ?It looked promising (MRV still had the best form factor) and we expressed our interest in getting a beta unit in as soon as we were able to. ?This is now known as the ME3600 and ME3800 platform and we've been testing a beta unit in our lab for the past few months. ?This is the platform we have chosen. ?It's not perfect, but our gripes have more to do with form factor (it's 1RU, but it's a bit deeper than what we'd like) and port densities (no mixed mode ports) than software or features. ?We've been pretty pleased with it's feature set and performance, but this hasn't seen any real world action, so who knows how that will turn out. > > If you're asking more about a P router or P/PE hybrid, we've also just ordered a few ASR9000s under try-and-buy as P/PEs to close up the chains of ME3600s that will start to be deployed in our remote sites. ?A Juniper MX would certainly work well here too, and it seems to interoperate rather well with the ME3600s, so that's certainly an option, but for us, we think it will work more in our favor to go with the ASRs in the core, but if not, we'd ship them back under the try-and-buy and get Junipers instead. > > Hope that helps. > From bross at pobox.com Wed Oct 20 16:26:25 2010 From: bross at pobox.com (Brandon Ross) Date: Wed, 20 Oct 2010 17:26:25 -0400 (EDT) Subject: NANOG Digest, Vol 33, Issue 91 In-Reply-To: References: Message-ID: On Wed, 20 Oct 2010, Rudolph Daniel wrote: > We all are waiving flags about the return of one solitary /8 to ARIN, (which > is a good thing) but should we not waive flags about new v6 networks too? Then I would also like to point out that Interop is fully dual-stacked both for exhibitors and the attendee wireless network. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From bross at pobox.com Wed Oct 20 16:47:25 2010 From: bross at pobox.com (Brandon Ross) Date: Wed, 20 Oct 2010 17:47:25 -0400 (EDT) Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF09BE.50507@unfix.org> Message-ID: On Wed, 20 Oct 2010, Brandon Ross wrote: > On Wed, 20 Oct 2010, Jeroen Massar wrote: > >> [John, is 45.127.0.0/16 one of the two blocks they keep, or is it >> hijacked already? :) ] > > I can authoritatively say, yes it is. I spoke too soon. It is not hijacked, it's simply old cruft from an old show that we didn't have removed. We'll take care of it shortly. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From jeroen at mompl.net Wed Oct 20 16:48:47 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 20 Oct 2010 14:48:47 -0700 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCUIFVuaXF1ZSBsb2NhbCBhZGRyZXNzZXM=?= Message-ID: <4CBF63BF.2000101@mompl.net> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an fc00::/7 address includes a 40-bit pseudo random number: "fc00::/7 ? Unique local addresses (ULA's) are intended for local communication. They are routable only within a set of cooperating sites (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing prefix intended to minimize the risk of conflicts if sites merge or packets are misrouted into the Internet. Despite the restricted, local usage of these addresses, their address scope is global, i.e. they are expected to be globally unique." I am trying to set up a local IPv6 network and am curious why all the examples I come accross do not seem to use the 40-bit pseudorandom number? What should I do? Use something like fd00::1234, or incorporate something like the interface's MAC address into the address? It'd make the address quite unreadable though. Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From jay-ford at uiowa.edu Wed Oct 20 16:54:43 2010 From: jay-ford at uiowa.edu (Jay Ford) Date: Wed, 20 Oct 2010 16:54:43 -0500 (CDT) Subject: =?UTF-8?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=E2=80=94_Unique_local_addresses?= In-Reply-To: <4CBF63BF.2000101@mompl.net> References: <4CBF63BF.2000101@mompl.net> Message-ID: On Wed, 20 Oct 2010, Jeroen van Aart wrote: > According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an > fc00::/7 address includes a 40-bit pseudo random number: > > "fc00::/7 ? Unique local addresses (ULA's) are intended for local > communication. They are routable only within a set of cooperating sites > (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of > IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing > prefix intended to minimize the risk of conflicts if sites merge or packets > are misrouted into the Internet. Despite the restricted, local usage of these > addresses, their address scope is global, i.e. they are expected to be > globally unique." > > I am trying to set up a local IPv6 network and am curious why all the > examples I come accross do not seem to use the 40-bit pseudorandom number? > What should I do? Use something like fd00::1234, or incorporate something > like the interface's MAC address into the address? It'd make the address > quite unreadable though. Use the cool tool at http://www.sixxs.net/tools/grh/ula/ to generate a ULA, then use it for local-scope stuff. Slick. ________________________________________________________________________ Jay Ford, Network Engineering Group, Information Technology Services University of Iowa, Iowa City, IA 52242 email: jay-ford at uiowa.edu, phone: 319-335-5555, fax: 319-335-2951 From joel.esler at me.com Wed Oct 20 16:55:54 2010 From: joel.esler at me.com (Joel Esler) Date: Wed, 20 Oct 2010 17:55:54 -0400 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <3E11F5DD-D97D-4D15-8E0B-211E2B2C61FB@virtualized.org> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF0E90.6070403@ttec.com> <824BB3F5-A58F-4FD1-9461-E26662183409@me.com> <3E11F5DD-D97D-4D15-8E0B-211E2B2C61FB@virtualized.org> Message-ID: <1C27279B-6910-4BB3-BED7-3F12FE63ABB1@me.com> On Oct 20, 2010, at 4:58 PM, David Conrad wrote: > On Oct 20, 2010, at 1:55 PM, Joel Esler wrote: >> There are lots of places that /8, and multiple ones at that that aren't using them. > > Which /8s are those? As someone else mentioned the Gov't has /8's they aren't using the whole of. -- Joel Esler http://www.joelesler.net From rcarpen at network1.net Wed Oct 20 17:00:25 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Wed, 20 Oct 2010 18:00:25 -0400 (EDT) Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <1C27279B-6910-4BB3-BED7-3F12FE63ABB1@me.com> Message-ID: <2112091227.11887.1287612025067.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > On Oct 20, 2010, at 4:58 PM, David Conrad wrote: > > On Oct 20, 2010, at 1:55 PM, Joel Esler wrote: > >> There are lots of places that /8, and multiple ones at that that > >> aren't using them. > > > > Which /8s are those? > > > As someone else mentioned the Gov't has /8's they aren't using the > whole of. That would be incredibly fun to try to recover. I would imagine converting to IPv6, then coming up with a new standard, and converting to that would be an order of magnitude easier than figuring out a way to recover IPv4 space from the US government. -Randy From jeroen at mompl.net Wed Oct 20 17:23:48 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 20 Oct 2010 15:23:48 -0700 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <1F0E8D6A-D7E6-4D7E-91E7-1E07792A8D8E@arin.net> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <1F0E8D6A-D7E6-4D7E-91E7-1E07792A8D8E@arin.net> Message-ID: <4CBF6BF4.8060404@mompl.net> John Curran wrote: > On Oct 20, 2010, at 10:43 AM, Nick Hilliard wrote: > >> Thank you Interop - for performing an outstanding act of altruism. >> >> John, could you provide more details at this stage on how much address space was returned to ARIN? > > INTEROP is retaining 2 /16 blocks for existing usage; > i.e. more than 99% of the /8 block is being returned. I remember writing (complaining) about it in a thread back in April, appreciated. Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From franck at genius.com Wed Oct 20 17:24:04 2010 From: franck at genius.com (Franck Martin) Date: Thu, 21 Oct 2010 10:24:04 +1200 (FJT) Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <2112091227.11887.1287612025067.JavaMail.root@zimbra.network1.net> Message-ID: <13180774.191.1287613443571.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Randy Carpenter" > To: "Joel Esler" > Cc: "North American Network Operators Group" > Sent: Thursday, 21 October, 2010 10:00:25 AM > Subject: Re: ARIN recognizes Interop for return of more than 99% of 45/8 address block > ----- Original Message ----- > > On Oct 20, 2010, at 4:58 PM, David Conrad wrote: > > > On Oct 20, 2010, at 1:55 PM, Joel Esler wrote: > > >> There are lots of places that /8, and multiple ones at that that > > >> aren't using them. > > > > > > Which /8s are those? > > > > > > As someone else mentioned the Gov't has /8's they aren't using the > > whole of. > > That would be incredibly fun to try to recover. I would imagine > converting to IPv6, then coming up with a new standard, and converting > to that would be an order of magnitude easier than figuring out a way > to recover IPv4 space from the US government. > Ask a russian spammer to recover it, may be? From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 20 18:01:09 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 09:31:09 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: <4CBF63BF.2000101@mompl.net> References: <4CBF63BF.2000101@mompl.net> Message-ID: <20101021093109.06a50ea2@opy.nosense.org> On Wed, 20 Oct 2010 14:48:47 -0700 Jeroen van Aart wrote: > > > According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses > an fc00::/7 address includes a 40-bit pseudo random number: > > "fc00::/7 ? Unique local addresses (ULA's) are intended for local > communication. They are routable only within a set of cooperating sites > (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 > of IPv4).[12] The addresses include a 40-bit pseudorandom number in the > routing prefix intended to minimize the risk of conflicts if sites merge > or packets are misrouted into the Internet. Despite the restricted, > local usage of these addresses, their address scope is global, i.e. they > are expected to be globally unique." > > I am trying to set up a local IPv6 network and am curious why all the > examples I come accross do not seem to use the 40-bit pseudorandom > number? What should I do? Use a pseudo random number, not follow bad examples. Where are these examples? I'd be curious as to what they say regarding why they haven't followed the pseudo random number requirement. > Use something like fd00::1234, or incorporate > something like the interface's MAC address into the address? It'd make > the address quite unreadable though. > DNS (including dynamic DNS, multicast DNS, and DNS service discovery) is intended to be used far more often in IPv6 than it was in IPv4. It was never going to be that possible to expand the size of the address space significantly without trading off 'rememberability'. The best way to understand ULAs is to read the RFC. It'd probably take about 15 to 20 minutes, and is quite readable (as are most if not all RFCs) Unique Local IPv6 Unicast Addresses http://tools.ietf.org/rfc/rfc4193.txt You may also wish to subscribe to the ipv6-ops mailing list for IPv6 focused operations discussions. http://lists.cluenet.de/mailman/listinfo/ipv6-ops Regards, Mark. From ulf at Alameda.net Wed Oct 20 18:37:19 2010 From: ulf at Alameda.net (Ulf Zimmermann) Date: Wed, 20 Oct 2010 16:37:19 -0700 Subject: XO BGP routing engineer? Message-ID: <20101020233719.GY62987@evil.alameda.net> Anyone from XO, could you please contact me off list for a routing problem I have inside of XO Fremont Datacenter, trying to file a ticket with XO isn't working as nobody is answering the phones. -- 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 deepak at ai.net Wed Oct 20 18:39:19 2010 From: deepak at ai.net (Deepak Jain) Date: Wed, 20 Oct 2010 19:39:19 -0400 Subject: =?utf-8?B?UkU6IElQdjYgZmMwMDo6Lzcg4oCUIFVuaXF1ZSBsb2NhbCBhZGRyZXNzZXM=?= In-Reply-To: <20101021093109.06a50ea2@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> Message-ID: > Use a pseudo random number, not follow bad examples. Where are these > examples? I'd be curious as to what they say regarding why they haven't > followed the pseudo random number requirement. > > > Use something like fd00::1234, or incorporate > > something like the interface's MAC address into the address? It'd > make > > the address quite unreadable though. > > > Unique Local IPv6 Unicast Addresses > http://tools.ietf.org/rfc/rfc4193.txt > [snipped a bunch of stuff above]. According to the RFC: 3.2 The local assignments are self-generated and do not need any central coordination or assignment, but have an extremely high probability of being unique. 3.2.1. Locally Assigned Global IDs Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM]. Section 3.2.2 describes a suggested algorithm. It is important that all sites generating Global IDs use a functionally similar algorithm to ensure there is a high probability of uniqueness. The use of a pseudo-random algorithm to generate Global IDs in the locally assigned prefix gives an assurance that any network numbered using such a prefix is highly unlikely to have that address space clash with any other network that has another locally assigned prefix allocated to it. This is a particularly useful property when considering a number of scenarios including networks that merge, overlapping VPN address space, or hosts mobile between such networks. ---- Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick. Deepak From dan at beanfield.com Wed Oct 20 18:50:09 2010 From: dan at beanfield.com (Dan Armstrong) Date: Wed, 20 Oct 2010 19:50:09 -0400 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: References: <022801cb706a$ead9d5e0$c08d81a0$@net> Message-ID: <5294CF7C-E618-41E5-ACFB-E299CD25A5E5@beanfield.com> I think that's what Jason just said. :-) On 2010-10-20, at 5:24 PM, Ramanpreet Singh wrote: > 7600's/ASR 1k > > Have you looked in to Ciso ME 3600X/ME 3800X series? > > Without a bias these are the top notch products in the market for Metro E. > > -Raman > > On Wed, Oct 20, 2010 at 12:57 PM, Jason Lixfeld wrote: >> On 2010-10-20, at 11:24 AM, Eric Merkel wrote: >> >>> Any suggestions, success or horror stories are appreciated. ;) >> >> I've been going through pretty much the same exercise looking for a decent PE for almost two years. Our requirements were for a PE device that had between 12-24 ports (in a perfect world, mixed mode 10/100/1000 copper + SFP), 10G uplinks, EoMPLS, MPLS VPN, DHCP server, port-protect/UNI (or similar) capabilities, DC power and a small footprint (1RU) >> >> Of all the ones we looked at (Juniper, Cisco, Extreme, Brocade, MRV, Alcatel) initially, MRV was the only contender. The rest either didn't have a product, or their offering didn't meet various points within our criteria. >> >> As such, we bought a bunch of MRVs in early 2009 and after four months of trial and error, we yanked every single one out of the network. From a physical perspective, the box was perfect. Port density was perfect, mixed-mode ports, promised a 10G uplink product soon, size was perfect, power was perfect, we thought we had it nailed. Unfortunately there are no words to describe how terrible the software was. The CLI took a little getting used to, which is pretty much par for the course when you're dealing with a new vendor, but the code itself was just absolutely broken, everywhere. Duplex issues, LDP constantly crashing taking the box with it, OSPF issues, the list went on and on. To their credit, they flew engineers up from the US and they were quite committed to making stuff work, but at the end of the day, they just couldn't make it go. We pulled the plug in May 2009 and I haven't heard a thing about their product since then, so maybe they've got it all together. >> >> While meeting with Juniper a few months later about a different project, they said they had a product that might fit our needs. The EX4200. As such, we had a few of these loaned to our lab for a few months to put through their paces, from a features and interoperability perspective. They work[1] and they seem to work well. The show stopper was provisioning[1] and size. The box is massive, albeit it is still 1U. >> >> [1] (I'm not a Juniper guy, so my recollection on specific terms and jargon may be a bit off kilter) they only support ccc, which makes provisioning an absolute nightmare. From my experience with Cisco and MRV, you only have to configure the EoMPLS vc. On the EX4200, you have to create the LSPs as well. To get a ccc working, the JunOS code block was far larger and much more involved per vc than the single line Cisco equivalent. To create the LSPs was, I believe, two more equally large sized code blocks. At the end of the day, it was just too involved. We needed something simpler. >> >> About the same time that we started to evaluate the EX4200, Cisco had pitched us on their (then alpha) Whales platform. It looked promising (MRV still had the best form factor) and we expressed our interest in getting a beta unit in as soon as we were able to. This is now known as the ME3600 and ME3800 platform and we've been testing a beta unit in our lab for the past few months. This is the platform we have chosen. It's not perfect, but our gripes have more to do with form factor (it's 1RU, but it's a bit deeper than what we'd like) and port densities (no mixed mode ports) than software or features. We've been pretty pleased with it's feature set and performance, but this hasn't seen any real world action, so who knows how that will turn out. >> >> If you're asking more about a P router or P/PE hybrid, we've also just ordered a few ASR9000s under try-and-buy as P/PEs to close up the chains of ME3600s that will start to be deployed in our remote sites. A Juniper MX would certainly work well here too, and it seems to interoperate rather well with the ME3600s, so that's certainly an option, but for us, we think it will work more in our favor to go with the ASRs in the core, but if not, we'd ship them back under the try-and-buy and get Junipers instead. >> >> Hope that helps. >> > From marka at isc.org Wed Oct 20 18:58:14 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Oct 2010 10:58:14 +1100 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: Your message of "Thu, 21 Oct 2010 09:31:09 +1030." <20101021093109.06a50ea2@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net><20101021093109.06a50ea2@opy.nosense.org> Message-ID: <20101020235814.111DD5EF4F2@drugs.dv.isc.org> In message <20101021093109.06a50ea2 at opy.nosense.org>, Mark Smith writes: > On Wed, 20 Oct 2010 14:48:47 -0700 > Jeroen van Aart wrote: > > > > >=20 > > According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses= > =20 > > an fc00::/7 address includes a 40-bit pseudo random number: > >=20 > > "fc00::/7 =E2=80=94 Unique local addresses (ULA's) are intended for local= > =20 > > communication. They are routable only within a set of cooperating sites=20 > > (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16= > =20 > > of IPv4).[12] The addresses include a 40-bit pseudorandom number in the=20 > > routing prefix intended to minimize the risk of conflicts if sites merge= > =20 > > or packets are misrouted into the Internet. Despite the restricted,=20 > > local usage of these addresses, their address scope is global, i.e. they= > =20 > > are expected to be globally unique." > >=20 > > I am trying to set up a local IPv6 network and am curious why all the=20 > > examples I come accross do not seem to use the 40-bit pseudorandom=20 > > number? What should I do? > > Use a pseudo random number, not follow bad examples. Where are these > examples? I'd be curious as to what they say regarding why they haven't > followed the pseudo random number requirement. Here is a real life example of the use of ULA's. I used the following command to get the 40 random bits in the prefix (92:7065:b8e). dd if=/dev/random bs=5 count=1 | od -t x1 The border router is configured to block ULA traffic, gif0 is the external interface on the border router. // ULA border filter add unreach admin all from any to fc00::/7 via gif0 add unreach admin all from fc00::/7 to any via gif0 If your OS supports it. You configure the address selection rules to prefer your ULA prefix when talking to your ULA prefix and then to prefer non ULA to non ULA over general ULA to general ULA. That way you use ULA addresses for internal communication and non ULA addresses for external communication. en0: flags=8863 mtu 1500 ether e8:06:88:f3:4f:9c inet6 fe80::ea06:88ff:fef3:4f9c%en0 prefixlen 64 scopeid 0x4 inet6 fd92:7065:b8e::ea06:88ff:fef3:4f9c prefixlen 64 autoconf inet6 2001:470:1f00:820:ea06:88ff:fef3:4f9c prefixlen 64 autoconf inet 192.168.191.240 netmask 0xffffff00 broadcast 192.168.191.255 media: autoselect (10baseT/UTP ) status: active > > Use something like fd00::1234, or incorporate=20 > > something like the interface's MAC address into the address? It'd make=20 > > the address quite unreadable though. > >=20 > > DNS (including dynamic DNS, multicast DNS, and DNS service discovery) is > intended to be used far more often in IPv6 than it was in IPv4. It was > never going to be that possible to expand the size of the address space > significantly without trading off 'rememberability'. > > > The best way to understand ULAs is to read the RFC. It'd probably take > about 15 to 20 minutes, and is quite readable (as are most if not all > RFCs) > > Unique Local IPv6 Unicast Addresses > http://tools.ietf.org/rfc/rfc4193.txt > > You may also wish to subscribe to the ipv6-ops mailing list for IPv6 > focused operations discussions. > > http://lists.cluenet.de/mailman/listinfo/ipv6-ops > > Regards, > Mark. > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From mysidia at gmail.com Wed Oct 20 19:07:57 2010 From: mysidia at gmail.com (James Hess) Date: Wed, 20 Oct 2010 19:07:57 -0500 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <4CBF63BF.2000101@mompl.net> References: <4CBF63BF.2000101@mompl.net> Message-ID: On Wed, Oct 20, 2010 at 4:48 PM, Jeroen van Aart wrote: > > these addresses, their address scope is global, i.e. they are expected to be > globally unique." The ULA /48s are hoped to only be globally unique, but this only has a good chance of happening if all users pick good random numbers as required, which will often be 'hard to read'. should any two networks pick non-random numbers, they could easily conflict, breaking expectations. My suspicion is that in the future it is going to happen routinely, esp. if ULA becomes to IPv6 what RFC1918 space is to IPv4, with most end user networks implementing NAT66 to translate "private" /48 ULAs to their site's "public" /48 assignment from their ISP. I can imagine generic $50 IPv6 broadband routers getting distributed en-masse that hardcode all bits 0 ULA NAT66 by default, and expect the user to change the LAN IP subnet / NAT config from the defaults, sometime while they're setting it up, probably at the same time they change the admin password. You know... the type of router a residential user plugs in, and they "just work", and if the user forgets to follow any setup or config directions, just pulls an IP via DHCP and sticks with some insecure defaults. But it would still be a big improvement from what is available with V4. -- -Jh From furry13 at gmail.com Wed Oct 20 19:10:30 2010 From: furry13 at gmail.com (Jen Linkova) Date: Thu, 21 Oct 2010 11:10:30 +1100 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <4CBF63BF.2000101@mompl.net> References: <4CBF63BF.2000101@mompl.net> Message-ID: Hi Jeroen, On Thu, Oct 21, 2010 at 8:48 AM, Jeroen van Aart wrote: > According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an > fc00::/7 address includes a 40-bit pseudo random number: > > "fc00::/7 ? Unique local addresses (ULA's) are intended for local > communication. They are routable only within a set of cooperating sites > (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of > IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing > prefix intended to minimize the risk of conflicts if sites merge or packets > are misrouted into the Internet. Despite the restricted, local usage of > these addresses, their address scope is global, i.e. they are expected to be > globally unique." > > I am trying to set up a local IPv6 network and am curious why all the > examples I come accross do not seem to use the 40-bit pseudorandom number? > What should I do? Use something like fd00::1234, or incorporate something > like the interface's MAC address into the address? It'd make the address > quite unreadable though. RFC4193 specifies a suggested algorithm to do it: http://tools.ietf.org/html/rfc4193#section-3.2.2 The section 3.2.1 also states that "Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM]. Section 3.2.2 describes a suggested algorithm. It is important that all sites generating Global IDs use a functionally similar algorithm to ensure there is a high probability of uniqueness." I'm not sure where did you find the examples you've mentioned. If it's just a documentation example - seems to be fine. If someone is doing it in real networks - that's just not right.. -- SY, Jen Linkova aka Furry From jeroen at mompl.net Wed Oct 20 19:21:22 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Wed, 20 Oct 2010 17:21:22 -0700 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCUIFVuaXF1ZSBsb2NhbCBhZGRyZXNzZXM=?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> Message-ID: <4CBF8782.2040301@mompl.net> Deepak Jain wrote: > According to the RFC: > 3.2.1. Locally Assigned Global IDs > > Locally assigned Global IDs MUST be generated with a pseudo-random > algorithm consistent with [RANDOM]. Section 3.2.2 describes a > Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick. All thanks for the information. I'll be using the "40 bit pseudo random thing" since it seems to be the smart thing to do, using the SIXXS tool. One may hope that something will become the "official" way to generate these numbers (perhaps the above mentioned tool). Someone advised me to use GUA instead of ULA. But since for my purposes this is used for an IPv6 LAN would ULA not be the better choice? Thanks, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From msa at latt.net Wed Oct 20 19:29:22 2010 From: msa at latt.net (Majdi S. Abbas) Date: Wed, 20 Oct 2010 17:29:22 -0700 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: <4CBF6BF4.8060404@mompl.net> References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <1F0E8D6A-D7E6-4D7E-91E7-1E07792A8D8E@arin.net> <4CBF6BF4.8060404@mompl.net> Message-ID: <20101021002922.GA98038@puck.nether.net> On Wed, Oct 20, 2010 at 03:23:48PM -0700, Jeroen van Aart wrote: > I remember writing (complaining) about it in a thread back in April, > appreciated. I still don't know why anyone would complain, although I do thank Interop for their generosity. Here's some truth: 1) At most, we buy ourselves a few months. 2) Specified transfer is really just a way for those that would have to renumber to free up space, to be compensated for their expense in doing so. 3) We can reclaim parts of every /8 we want, and the only thing we'll do is give those that are slow to migrate to v6 an excuse to stall a bit longer. We're gonna hit the wall. Delaying the inevitable, is not really in anyone's interest. The sooner we hit the wall, the sooner that v6 deployment clue is imparted.* --msa * And I say this as one of the people that spent many years bitching about v6's flaws -- however, we no longer have time to debate them, or try to switch horses midstream, 6rd style. That ship sailed. Suck it up and go native, already. Sheesh. If you work for an MSO, I am *really* talking to you, especially if your name starts with a C and ends with an x. Thanks for listening. From alh-ietf at tndh.net Wed Oct 20 19:28:12 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Wed, 20 Oct 2010 17:28:12 -0700 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> Message-ID: <002d01cb70b6$e331ed90$a995c8b0$@net> John Curran wrote: > On Oct 20, 2010, at 11:35 AM, Christopher Morrow wrote: > > > yes, sorry.. since this was returned to ARIN, I assumed the ARIN > > region drain rate. > > Ah, good point. It may end up in the global pool, so comparison to > either drain rate is quite reasonable. For what it's worth, at this point it really doesn't matter much if 45/8 stays at ARIN or goes back to IANA. RIPE is due for a pair around 12/15 -->> IANA @ 10 APnic burned through the last 2 in 67 days, so given end of year slowing they should be back for another pair around 1/2/11. -->> IANA @ 8 If 45/8 goes back to IANA, ARIN is due to get a pair around 2/1. -->> IANA @ 6 + 45/8 APnic comes back for the last one + 45/8 around 3/1 -->> IANA @ 5 triggers end of pool. If ARIN keeps 45/8, the only difference would be they would probably not qualify for the estimated 2/1/11 allocation, so that event would be delayed and when 45/8 was used up so they would qualify, there would only be 1 left because APnic would have gotten their pair around 3/1 first. Any way you cut it, around 3/1/11 APnic/ARIN/RIPE will each be holding around 4 /8's + their remaining share of 'Various Registries' (ARIN's last one could sit at IANA for an additional couple of weeks, but they would still be next in line unless they take too long). The wild card to the above scenario is Afrinic. They are close enough for an unusual event to qualify them for another /8 from IANA within this timeframe. If that happens, the disposition of 45/8 could impact how many APnic is holding around 3/1/11. Given that APnic is burning through a /8 on an accelerating pace currently at 33 days, +/- one will impact how soon the address market takes off. If Afrinic gets one and 45/8 stays at ARIN, APnic will pick up the last pair at IANA around 3/1 and be completely out within 6 months. If 45/8 goes back, ARIN picks up 2 in early Feb, so with Afrinic getting one there would only be one left for APnic. Tony From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 20 19:29:01 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 10:59:01 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> Message-ID: <20101021105901.7f708b16@opy.nosense.org> On Wed, 20 Oct 2010 19:39:19 -0400 Deepak Jain wrote: > > Use a pseudo random number, not follow bad examples. Where are these > > examples? I'd be curious as to what they say regarding why they haven't > > followed the pseudo random number requirement. > > > > > Use something like fd00::1234, or incorporate > > > something like the interface's MAC address into the address? It'd > > make > > > the address quite unreadable though. > > > > > Unique Local IPv6 Unicast Addresses > > http://tools.ietf.org/rfc/rfc4193.txt > > > > [snipped a bunch of stuff above]. > > According to the RFC: > > 3.2 > > The local assignments are self-generated and do not need any central > coordination or assignment, but have an extremely high probability of > being unique. > > 3.2.1. Locally Assigned Global IDs > > Locally assigned Global IDs MUST be generated with a pseudo-random > algorithm consistent with [RANDOM]. Section 3.2.2 describes a > suggested algorithm. It is important that all sites generating > Global IDs use a functionally similar algorithm to ensure there is a > high probability of uniqueness. > > The use of a pseudo-random algorithm to generate Global IDs in the > locally assigned prefix gives an assurance that any network numbered > using such a prefix is highly unlikely to have that address space > clash with any other network that has another locally assigned prefix > allocated to it. This is a particularly useful property when > considering a number of scenarios including networks that merge, > overlapping VPN address space, or hosts mobile between such networks. > > ---- > > Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. The chance of collision is dependent on both the randomness of 40 bits *and* how interconnected the ULA domains are. You'll have to sin a lot to be that unlucky. Here's the table from the RFC showing the odds of collision based on interconnectedness - The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field. Connections Probability of Collision 2 1.81*10^-12 10 4.54*10^-11 100 4.54*10^-09 1000 4.54*10^-07 10000 4.54*10^-05 Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs. > Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick. > One thing I'm not keen on that sixxs have done is to create a voluntary registry of the non-central ULAs. By creating a registry, I think some people who use it will then think that their ULA prefix is now guaranteed globally unique and is theirs forever. If there ever was a collision, those people are likely to point to that completely voluntary registry and say "I had it first" and are likely to refuse to accept that the voluntary registry has no status or authority over the random ULA address space. There also doesn't seem to be any limiting of the number of prefixes. In an isolated network, which is where ULAs are supposed to be used, it's far less of a problem, because the only time the chance of collision occurs is if you interconnect with somebody else's ULA domain. However, as this sixxs registry implies it is a global one, and therefore there is a single instance of the fd::/8 address space, limiting the number of prefixes that are assigned would seem to me to be good idea. When I see examples such as - fddd:7927:58e::/48 Steven Sorel Deticon Networks http://deticon.net fd85:5d1d:c00b::/48 Steven Sorel Deticon Networks http://deticon.net fda1:9347:699f::/48 Steven Sorel Deticon Networks http://deticon.net fd41:eda2:4b7b::/48 Steven Sorel Deticon Networks http://deticon.net fd58:fe0f:8706::/48 Steven Sorel Deticon Networks http://deticon.net fd6a:3128:2a1d::/48 Steven Sorel Deticon Networks http://deticon.net fdb0:8025:2463::/48 Steven Sorel Deticon Networks http://deticon.net or 458 752 subnets, and http://deticon.net isn't reachable via IPv6 or IPv4 (and hasn't been for quite a while - I checked a few months ago when I discovered the registry), it seems to me that people have already misunderstood what it's purpose is, and that the database is already polluted with invalid entries that can't be verified for existence, and which also can't be expired via some invalidation mechanism, such as lack of payment of annual fees. Regards, Mark. From marka at isc.org Wed Oct 20 19:37:33 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Oct 2010 11:37:33 +1100 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: Your message of "Wed, 20 Oct 2010 19:07:57 CDT." References: <4CBF63BF.2000101@mompl.net> Message-ID: <20101021003733.D90EA5EFB1D@drugs.dv.isc.org> In message , Jame s Hess writes: > On Wed, Oct 20, 2010 at 4:48 PM, Jeroen van Aart wrote: > > > > > these addresses, their address scope is global, i.e. they are expected to b > e > > globally unique." > > The ULA /48s are hoped to only be globally unique, but this only has > a good chance of happening > if all users pick good random numbers as required, which will > often be 'hard to read'. > should any two networks pick non-random numbers, they could easily > conflict, breaking expectations. > > My suspicion is that in the future it is going to happen routinely, > esp. if ULA becomes to IPv6 what > RFC1918 space is to IPv4, with most end user networks implementing > NAT66 to translate "private" > /48 ULAs to their site's "public" /48 assignment from their ISP. Way to much "IPv4 think" here. Just use multiple prefixes. It just works. You talk to the external world using the prefix your ISP provides and you talk to your internal machines using the ULA prefix you choose. No need for NAT66. You move to a new ISP the machines just add a AAAA record to the DNS for themselves and remove the old AAAA record. > I can imagine generic $50 IPv6 broadband routers getting > distributed en-masse that hardcode all bits 0 > ULA NAT66 by default, and expect the user to change the LAN IP subnet > / NAT config from the defaults, > sometime while they're setting it up, probably at the same time they > change the admin password. Or just have the CPE generate a ULA prefix correctly and write it to NVRAM so you don't need to re-generate it. The internal prefix / addresses *WILL* leak. We know this from our experiences with RFC 1918 addresses. Any CPE vendor that fails to generate random ULA prefixes should be shot. > You know... the type of router a residential user plugs in, and they > "just work", > and if the user forgets to follow any setup or config directions, > just pulls an IP via DHCP and > sticks with some insecure defaults. > > But it would still be a big improvement from what is available with V4. > -- > -Jh -- 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 Wed Oct 20 19:41:52 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Oct 2010 17:41:52 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <4CBF8782.2040301@mompl.net> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> Message-ID: On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote: > Deepak Jain wrote: >> According to the RFC: > >> 3.2.1. Locally Assigned Global IDs >> Locally assigned Global IDs MUST be generated with a pseudo-random >> algorithm consistent with [RANDOM]. Section 3.2.2 describes a > >> Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick. > > All thanks for the information. I'll be using the "40 bit pseudo random thing" since it seems to be the smart thing to do, using the SIXXS tool. One may hope that something will become the "official" way to generate these numbers (perhaps the above mentioned tool). > I believe the above mentioned tool uses the OFFICIAL way documented in the RFC. There is an official way to do it. It is documented in the RFC. > Someone advised me to use GUA instead of ULA. But since for my purposes this is used for an IPv6 LAN would ULA not be the better choice? > IMHO, no. There's no disadvantage to using GUA and I personally don't think ULA really serves a purpose. If you want to later connect this LAN to the internet or something that connects to something that connects to something that connects to the internet or whatever, GUA provides the following advantages: + Guaranteed uniqueness (not just statistically probable uniqueness) + You can route it if you later desire to Since ULA offers no real advantages, I don't really see the point. Owen From owen at delong.com Wed Oct 20 19:53:36 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Oct 2010 17:53:36 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101021003733.D90EA5EFB1D@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net> <20101021003733.D90EA5EFB1D@drugs.dv.isc.org> Message-ID: <0114C9A5-3E8F-421B-80FE-BD1D619F1058@delong.com> > > Or just have the CPE generate a ULA prefix correctly and write it > to NVRAM so you don't need to re-generate it. The internal prefix > / addresses *WILL* leak. We know this from our experiences with > RFC 1918 addresses. Any CPE vendor that fails to generate random > ULA prefixes should be shot. > Any CPE vendor that refuses to implement any special provisions whatsoever for ULA and leave that entirely to the user with strong discouragement should be applauded. Owen From owen at delong.com Wed Oct 20 19:51:11 2010 From: owen at delong.com (Owen DeLong) Date: Wed, 20 Oct 2010 17:51:11 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101021105901.7f708b16@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> Message-ID: <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> On Oct 20, 2010, at 5:29 PM, Mark Smith wrote: > On Wed, 20 Oct 2010 19:39:19 -0400 > Deepak Jain wrote: > >>> Use a pseudo random number, not follow bad examples. Where are these >>> examples? I'd be curious as to what they say regarding why they haven't >>> followed the pseudo random number requirement. >>> >>>> Use something like fd00::1234, or incorporate >>>> something like the interface's MAC address into the address? It'd >>> make >>>> the address quite unreadable though. >>>> >>> Unique Local IPv6 Unicast Addresses >>> http://tools.ietf.org/rfc/rfc4193.txt >>> >> >> [snipped a bunch of stuff above]. >> >> According to the RFC: >> >> 3.2 >> >> The local assignments are self-generated and do not need any central >> coordination or assignment, but have an extremely high probability of >> being unique. >> >> 3.2.1. Locally Assigned Global IDs >> >> Locally assigned Global IDs MUST be generated with a pseudo-random >> algorithm consistent with [RANDOM]. Section 3.2.2 describes a >> suggested algorithm. It is important that all sites generating >> Global IDs use a functionally similar algorithm to ensure there is a >> high probability of uniqueness. >> >> The use of a pseudo-random algorithm to generate Global IDs in the >> locally assigned prefix gives an assurance that any network numbered >> using such a prefix is highly unlikely to have that address space >> clash with any other network that has another locally assigned prefix >> allocated to it. This is a particularly useful property when >> considering a number of scenarios including networks that merge, >> overlapping VPN address space, or hosts mobile between such networks. >> >> ---- >> >> Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. > > The chance of collision is dependent on both the randomness of 40 bits > *and* how interconnected the ULA domains are. You'll have to sin a lot to be that unlucky. > > Here's the table from the RFC showing the odds of collision based on interconnectedness - > > The following table shows the probability of a collision for a range > of connections using a 40-bit Global ID field. > > Connections Probability of Collision > > 2 1.81*10^-12 > 10 4.54*10^-11 > 100 4.54*10^-09 > 1000 4.54*10^-07 > 10000 4.54*10^-05 > > Based on this analysis, the uniqueness of locally generated Global > IDs is adequate for sites planning a small to moderate amount of > inter-site communication using locally generated Global IDs. > > >> Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick. >> > > One thing I'm not keen on that sixxs have done is to create a voluntary > registry of the non-central ULAs. By creating a registry, I think some > people who use it will then think that their ULA prefix is now > guaranteed globally unique and is theirs forever. If there ever was a > collision, those people are likely to point to that completely > voluntary registry and say "I had it first" and are likely to refuse > to accept that the voluntary registry has no status or authority over > the random ULA address space. > Which is part one of the three things that have to happen to make ULA really bad for the internet. Part 2 will be when the first provider accepts a large sum of money to route it within their public network between multiple sites owned by the same customer. Part 3 will be when that same provider (or some other provider in the same boat) takes the next step and starts trading routes of ULA space with other provider(s). At that point, ULA = GUA without policy = very bad thing (tm). Since feature creep of this form is kind of a given in internet history, I have no reason to believe it won't happen eventually with ULA. Owen From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 20 20:20:21 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 11:50:21 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: <20101021115021.2dc77ce6@opy.nosense.org> On Wed, 20 Oct 2010 19:07:57 -0500 James Hess wrote: > On Wed, Oct 20, 2010 at 4:48 PM, Jeroen van Aart wrote: > > > > > these addresses, their address scope is global, i.e. they are expected to be > > globally unique." > > The ULA /48s are hoped to only be globally unique, but this only has > a good chance of happening > if all users pick good random numbers as required, which will > often be 'hard to read'. > should any two networks pick non-random numbers, they could easily > conflict, breaking expectations. > Do you realise that one of the reasons why the ID is random is to discourage global routing of them, so they don't aggregate well? They're for internal addressing. The only time some of your local ULA address space would be seen externally to your network is via a backdoor connection to e.g. a business partner via a VPN. ULAs should never and are prohibited from appearing in the global route table. The probably shouldn't also appear in a multilateral peering fabric. To make it clear, as it seems to be quite misunderstood, you'd have both ULA and global addressing in your network. For internal destinations ULA addresses are used. For global destinations, global addresses are used. ULAs serve the purpose of providing an internally stable address space independent of your upstream transit provider's global address space, assuming you have one. In IPv4, RFC1918 served this purpose, although not as well, as it couldn't be used concurrently with a global address space (one of the differences between IPv4 and IPv6 is proper, by-design, support for nodes having multiple valid addresses), and also required NAT when interconnecting two overlapping RFC1918 address domains. > My suspicion is that in the future it is going to happen routinely, > esp. if ULA becomes to IPv6 what > RFC1918 space is to IPv4, with most end user networks implementing > NAT66 to translate "private" > /48 ULAs to their site's "public" /48 assignment from their ISP. > > I can imagine generic $50 IPv6 broadband routers getting > distributed en-masse that hardcode all bits 0 > ULA NAT66 by default, and expect the user to change the LAN IP subnet > / NAT config from the defaults, > sometime while they're setting it up, probably at the same time they > change the admin password. > > You know... the type of router a residential user plugs in, and they > "just work", > and if the user forgets to follow any setup or config directions, > just pulls an IP via DHCP and > sticks with some insecure defaults. > > But it would still be a big improvement from what is available with V4. > -- > -Jh > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 20 20:36:48 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 12:06:48 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> Message-ID: <20101021120648.1872981a@opy.nosense.org> Hi Owen, On Wed, 20 Oct 2010 17:51:11 -0700 Owen DeLong wrote: > > On Oct 20, 2010, at 5:29 PM, Mark Smith wrote: > > > On Wed, 20 Oct 2010 19:39:19 -0400 > > Deepak Jain wrote: > > > >>> Use a pseudo random number, not follow bad examples. Where are these > >>> examples? I'd be curious as to what they say regarding why they haven't > >>> followed the pseudo random number requirement. > >>> > >>>> Use something like fd00::1234, or incorporate > >>>> something like the interface's MAC address into the address? It'd > >>> make > >>>> the address quite unreadable though. > >>>> > >>> Unique Local IPv6 Unicast Addresses > >>> http://tools.ietf.org/rfc/rfc4193.txt > >>> > >> > >> [snipped a bunch of stuff above]. > >> > >> According to the RFC: > >> > >> 3.2 > >> > >> The local assignments are self-generated and do not need any central > >> coordination or assignment, but have an extremely high probability of > >> being unique. > >> > >> 3.2.1. Locally Assigned Global IDs > >> > >> Locally assigned Global IDs MUST be generated with a pseudo-random > >> algorithm consistent with [RANDOM]. Section 3.2.2 describes a > >> suggested algorithm. It is important that all sites generating > >> Global IDs use a functionally similar algorithm to ensure there is a > >> high probability of uniqueness. > >> > >> The use of a pseudo-random algorithm to generate Global IDs in the > >> locally assigned prefix gives an assurance that any network numbered > >> using such a prefix is highly unlikely to have that address space > >> clash with any other network that has another locally assigned prefix > >> allocated to it. This is a particularly useful property when > >> considering a number of scenarios including networks that merge, > >> overlapping VPN address space, or hosts mobile between such networks. > >> > >> ---- > >> > >> Global ID in this case means the 40 bit pseudo random thing. The point here is, we are all supposed to pick our own poison and pray that we are unique. > > > > The chance of collision is dependent on both the randomness of 40 bits > > *and* how interconnected the ULA domains are. You'll have to sin a lot to be that unlucky. > > > > Here's the table from the RFC showing the odds of collision based on interconnectedness - > > > > The following table shows the probability of a collision for a range > > of connections using a 40-bit Global ID field. > > > > Connections Probability of Collision > > > > 2 1.81*10^-12 > > 10 4.54*10^-11 > > 100 4.54*10^-09 > > 1000 4.54*10^-07 > > 10000 4.54*10^-05 > > > > Based on this analysis, the uniqueness of locally generated Global > > IDs is adequate for sites planning a small to moderate amount of > > inter-site communication using locally generated Global IDs. > > > > > >> Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. Anyway, the SIXXS tool seems pretty slick. > >> > > > > One thing I'm not keen on that sixxs have done is to create a voluntary > > registry of the non-central ULAs. By creating a registry, I think some > > people who use it will then think that their ULA prefix is now > > guaranteed globally unique and is theirs forever. If there ever was a > > collision, those people are likely to point to that completely > > voluntary registry and say "I had it first" and are likely to refuse > > to accept that the voluntary registry has no status or authority over > > the random ULA address space. > > > Which is part one of the three things that have to happen to make ULA > really bad for the internet. > > Part 2 will be when the first provider accepts a large sum of money to > route it within their public network between multiple sites owned by > the same customer. > That same customer is also going to have enough global address space to be able to reach other global destinations, at least enough space for all nodes that are permitted to access the Internet, if not more. Proper global address space ensures that if a global destination is reachable, then there is a high probability of successfully reaching it. The scope of external ULA reachability, regardless of how much money is thrown at the problem, isn't going to be as good as proper global addresses. For private site interconnect, I'd think it more likely that the provider would isolate the customers traffic and ULA address space via something like a VPN service e.g. MPLS, IPsec. > Part 3 will be when that same provider (or some other provider in the > same boat) takes the next step and starts trading routes of ULA space > with other provider(s). > > At that point, ULA = GUA without policy = very bad thing (tm). > > Since feature creep of this form is kind of a given in internet history, > I have no reason to believe it won't happen eventually with ULA. > So I'm not sure I can see much benefit would be of paying a huge amount of money to have ULA address space put in only a limited part/domain of the global route table. The only way to have ULA = GUA is to pay everybody on the Internet to carry it, and that is assuming that everybody would be willing to accept the money in the first place. That'd be far more expensive than just using GUA addresses for global reachability. Regards, Mark. From bill at herrin.us Wed Oct 20 20:39:12 2010 From: bill at herrin.us (William Herrin) Date: Wed, 20 Oct 2010 21:39:12 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <4CBF63BF.2000101@mompl.net> References: <4CBF63BF.2000101@mompl.net> Message-ID: On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart wrote: > I am trying to set up a local IPv6 network and am curious why all the > examples I come accross do not seem to use the 40-bit pseudorandom number? > What should I do? Use something like fd00::1234, or incorporate something > like the interface's MAC address into the address? It'd make the address > quite unreadable though. Jeroen, I see it like this: You can pick anything in fd00::/8 that you want, but if you don't follow the random selection rules in the RFC then it's *your fault* when you go to connect a VPN to someone else who picked the same network. Also, the DNS is your friend, even more so with IPv6 than with IPv4. 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 Wed Oct 20 20:39:55 2010 From: bill at herrin.us (William Herrin) Date: Wed, 20 Oct 2010 21:39:55 -0400 Subject: network name 101100010100110.net In-Reply-To: References: Message-ID: On Sun, Oct 17, 2010 at 12:46 AM, Day Domes wrote: > I have been tasked with coming up with a new name for are transit data > network.? I am thinking of using 101100010100110.net does anyone see > any issues with this? Two helpful rules of thumb when picking a domain name: 1. Minimize spoken syllables. 2. Does it spell like it sounds? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From matthew at matthew.at Wed Oct 20 20:46:34 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 20 Oct 2010 18:46:34 -0700 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: <20101021115021.2dc77ce6@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> Message-ID: <4CBF9B7A.1000500@matthew.at> On 10/20/2010 6:20 PM, Mark Smith wrote: > > To make it clear, as it seems to be quite misunderstood, you'd have > both ULA and global addressing in your network. Right. Just like to multihome with IPv6 you would have both PA addresses from provider #1 and PA addresses from provider #2 in your network. Only nobody wants to do that either. Matthew Kaufman From marka at isc.org Wed Oct 20 20:48:45 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Oct 2010 12:48:45 +1100 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: Your message of "Wed, 20 Oct 2010 17:51:11 PDT." <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org><585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> Message-ID: <20101021014845.C4A895F0112@drugs.dv.isc.org> In message <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9 at delong.com>, Owen DeLong write s: > > On Oct 20, 2010, at 5:29 PM, Mark Smith wrote: > > > On Wed, 20 Oct 2010 19:39:19 -0400 > > Deepak Jain wrote: > >=20 > >>> Use a pseudo random number, not follow bad examples. Where are these > >>> examples? I'd be curious as to what they say regarding why they = > haven't > >>> followed the pseudo random number requirement. > >>>=20 > >>>> Use something like fd00::1234, or incorporate > >>>> something like the interface's MAC address into the address? It'd > >>> make > >>>> the address quite unreadable though. > >>>>=20 > >>> Unique Local IPv6 Unicast Addresses > >>> http://tools.ietf.org/rfc/rfc4193.txt > >>>=20 > >>=20 > >> [snipped a bunch of stuff above].=20 > >>=20 > >> According to the RFC:=20 > >>=20 > >> 3.2 > >>=20 > >> The local assignments are self-generated and do not need any = > central > >> coordination or assignment, but have an extremely high probability = > of > >> being unique. > >>=20 > >> 3.2.1. Locally Assigned Global IDs > >>=20 > >> Locally assigned Global IDs MUST be generated with a pseudo-random > >> algorithm consistent with [RANDOM]. Section 3.2.2 describes a > >> suggested algorithm. It is important that all sites generating > >> Global IDs use a functionally similar algorithm to ensure there is = > a > >> high probability of uniqueness. > >>=20 > >> The use of a pseudo-random algorithm to generate Global IDs in the > >> locally assigned prefix gives an assurance that any network = > numbered > >> using such a prefix is highly unlikely to have that address space > >> clash with any other network that has another locally assigned = > prefix > >> allocated to it. This is a particularly useful property when > >> considering a number of scenarios including networks that merge, > >> overlapping VPN address space, or hosts mobile between such = > networks. > >>=20 > >> ---- > >>=20 > >> Global ID in this case means the 40 bit pseudo random thing. The = > point here is, we are all supposed to pick our own poison and pray that = > we are unique. > >=20 > > The chance of collision is dependent on both the randomness of 40 bits > > *and* how interconnected the ULA domains are. You'll have to sin a lot = > to be that unlucky. > >=20 > > Here's the table from the RFC showing the odds of collision based on = > interconnectedness - > >=20 > > The following table shows the probability of a collision for a range > > of connections using a 40-bit Global ID field. > >=20 > > Connections Probability of Collision > >=20 > > 2 1.81*10^-12 > > 10 4.54*10^-11 > > 100 4.54*10^-09 > > 1000 4.54*10^-07 > > 10000 4.54*10^-05 > >=20 > > Based on this analysis, the uniqueness of locally generated Global > > IDs is adequate for sites planning a small to moderate amount of > > inter-site communication using locally generated Global IDs. > >=20 > >=20 > >> Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. = > Anyway, the SIXXS tool seems pretty slick. > >>=20 > >=20 > > One thing I'm not keen on that sixxs have done is to create a = > voluntary > > registry of the non-central ULAs. By creating a registry, I think some > > people who use it will then think that their ULA prefix is now > > guaranteed globally unique and is theirs forever. If there ever was a > > collision, those people are likely to point to that completely > > voluntary registry and say "I had it first" and are likely to refuse > > to accept that the voluntary registry has no status or authority over > > the random ULA address space. > >=20 > Which is part one of the three things that have to happen to make ULA > really bad for the internet. > > Part 2 will be when the first provider accepts a large sum of money to > route it within their public network between multiple sites owned by > the same customer. They can do that without needing to pay. They just setup tunnels between the sites. Alternatively the ISP provides virtual circuits between the sites for a small on going fee to cover the additional administrative costs and bills on the aggregate traffic across all the circuits to each site. The ISP doesn't need to accept ULA routes to cross connect the sites. It's not like ISP's don't provide virtual circuits today to cross connect parts of companies. Or companies don't run VPN tunnels between sites today. > Part 3 will be when that same provider (or some other provider in the > same boat) takes the next step and starts trading routes of ULA space > with other provider(s). > > At that point, ULA =3D GUA without policy =3D very bad thing (tm). > > Since feature creep of this form is kind of a given in internet history, > I have no reason to believe it won't happen eventually with ULA. > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From matthew at matthew.at Wed Oct 20 20:49:54 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 20 Oct 2010 18:49:54 -0700 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> Message-ID: <4CBF9C42.3050608@matthew.at> On 10/20/2010 5:51 PM, Owen DeLong wrote: > > Part 2 will be when the first provider accepts a large sum of money to > route it within their public network between multiple sites owned by > the same customer. Is this happening now with RFC 1918 addresses and IPv4? > Part 3 will be when that same provider (or some other provider in the > same boat) takes the next step and starts trading routes of ULA space > with other provider(s). Is this happening now with RFC 1918 addresses and IPv4? If not, do you predict that it will soon, and if so, why? Matthew Kaufman From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 20 20:53:04 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 12:23:04 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: <4CBF9B7A.1000500@matthew.at> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> Message-ID: <20101021122304.5968b555@opy.nosense.org> On Wed, 20 Oct 2010 18:46:34 -0700 Matthew Kaufman wrote: > On 10/20/2010 6:20 PM, Mark Smith wrote: > > > > To make it clear, as it seems to be quite misunderstood, you'd have > > both ULA and global addressing in your network. > > Right. Just like to multihome with IPv6 you would have both PA addresses > from provider #1 and PA addresses from provider #2 in your network. > > Only nobody wants to do that either. > So you speak for everybody? I can do that too. Nobody wants to run NAT anymore either. From frnkblk at iname.com Wed Oct 20 21:05:35 2010 From: frnkblk at iname.com (Frank Bulk) Date: Wed, 20 Oct 2010 21:05:35 -0500 Subject: ARIN recognizes Interop for return of more than 99% of 45/8 address block In-Reply-To: References: <6FBCF35F-50E6-4EC4-97ED-424E5C09E767@arin.net> <4CBEFFFA.1030002@foobar.org> <4CBF09BE.50507@unfix.org> Message-ID: I wonder if we'll see a decrease in hijacked space because there's less unassigned space, or if because of the IPv4 block scarcity, it will occur more often. I can see aggressive hijackers looking for unused (but assigned) blocks as small as a /24 and advertising them. Frank -----Original Message----- From: John Curran [mailto:jcurran at arin.net] Sent: Wednesday, October 20, 2010 10:38 AM To: Jeroen Massar Cc: nanog at nanog.org Operators Group Subject: Re: ARIN recognizes Interop for return of more than 99% of 45/8 address block On Oct 20, 2010, at 11:24 AM, Jeroen Massar wrote: > > The problem with that is indeed in that little part about "aren't using > them", if even only 50% is in use because one allocated it quite > sparsely you won't be able to quickly clean it up and return it. Correct. It might make sense to do so, if you could recover the costs of the work involved. This is the reasoning behind the Specified Transfer policy that was recently adopted; it allows (once we're at depletion) for parties to free up address space and get compensated. It's goal is not to provide a windfall for those holding unused space; in theory, those with unused address space should be returning it already if they can easily do so. > One can of course wonder if they are supposed to use that or not. > The fact that they do not have reverse DNS delegation for it says quite > a bit already of course. One of the other benefits of improved utilization for returned space is less space which is "sitting idle" and available to be hijacked. /John John Curran President and CEO ARIN From mysidia at gmail.com Wed Oct 20 21:15:35 2010 From: mysidia at gmail.com (James Hess) Date: Wed, 20 Oct 2010 21:15:35 -0500 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <4CBF9B7A.1000500@matthew.at> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> Message-ID: On Wed, Oct 20, 2010 at 8:46 PM, Matthew Kaufman wrote: > On 10/20/2010 6:20 PM, Mark Smith wrote: > Right. Just like to multihome with IPv6 you would have both PA addresses > from provider #1 and PA addresses from provider #2 in your network. > Only nobody wants to do that either. A perfectly valid way to multihome, right? Setup each host with two IP addresses, one in each PA range. Use multiple DNS records, to indicate all the host's pairs of IPs. If an ISP link goes down, all the clients' should automatically try resend the unack'ed packets to the DNS name's other IPs in 10 or 11 seconds, and recover, without having to reconnect, right? right?? [ No :( ] Automatic failover to other multihomed IPs seems to always have been left missing from the TCP protocols, for some reason or another. Probably good reasons, but that multihoming strategy isn't a very good one, for now, due to the disruption of active connections, and bad client programs that won't look for other DNS records, even when trying to establish a new connection. Perhaps one day, there will be a truly reliable transport protocol, and an API that allows a bind() against multiple IPs and a connect() to all a target host's IPs instead of just one, so both hosts can learn of each other's IP addresses that are offered to be used for that connection, then "multiple PA IP addresses" would be a technically viable multi-homing strategy. -- -Jh From marka at isc.org Wed Oct 20 21:22:24 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Oct 2010 13:22:24 +1100 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: Your message of "Wed, 20 Oct 2010 18:46:34 PDT." <4CBF9B7A.1000500@matthew.at> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org><4CBF9B7A.1000500@matthew.at> Message-ID: <20101021022224.88FEC5F0352@drugs.dv.isc.org> In message <4CBF9B7A.1000500 at matthew.at>, Matthew Kaufman writes: > On 10/20/2010 6:20 PM, Mark Smith wrote: > > > > To make it clear, as it seems to be quite misunderstood, you'd have > > both ULA and global addressing in your network. > > Right. Just like to multihome with IPv6 you would have both PA addresses > from provider #1 and PA addresses from provider #2 in your network. > > Only nobody wants to do that either. Only because there isn't good support for it yet. ULA + PA actually works today. The IP stack can do the address selection without worrying about reachability. The chances of the ULA being unreachable and the PA being reachable between two nodes in the same ULA prefix are negligable. If I'm talking to a ULA address I'll use my ULA address. If I'm talking to a non-ULA address I'll use my PA addresses. PA + PA is a problem because you need to worry about source address selection and that is driven by reachability. You also need to worry about egress points due to source address filtering. etc. > Matthew Kaufman -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 20 21:27:30 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 12:57:30 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> Message-ID: <20101021125730.3bb576b4@opy.nosense.org> On Wed, 20 Oct 2010 21:15:35 -0500 James Hess wrote: > On Wed, Oct 20, 2010 at 8:46 PM, Matthew Kaufman wrote: > > On 10/20/2010 6:20 PM, Mark Smith wrote: > > Right. Just like to multihome with IPv6 you would have both PA addresses > > from provider #1 and PA addresses from provider #2 in your network. > > Only nobody wants to do that either. > > A perfectly valid way to multihome, right? Setup each host with two > IP addresses, > one in each PA range. Use multiple DNS records, to indicate all > the host's pairs of IPs. > If an ISP link goes down, all the clients' should automatically try > resend the unack'ed packets to the > DNS name's other IPs in 10 or 11 seconds, and recover, without having > to reconnect, right? right?? [ No :( ] > > Automatic failover to other multihomed IPs seems to always have been > left missing from the TCP protocols, for some reason or another. > > Probably good reasons, but that multihoming strategy isn't a very > good one, for now, > due to the disruption of active connections, and bad client > programs that won't look for other DNS records, > even when trying to establish a new connection. > > Perhaps one day, there will be a truly reliable transport protocol, > and an API that allows a bind() > against multiple IPs and a connect() * Stream Control Transport Protocol, first spec'd in 2000 (couldn't be deployed widely in IPv4 because of NATs) * "TCP Extensions for Multipath Operation with Multiple Addresses" https://datatracker.ietf.org/doc/draft-ietf-mptcp-multiaddressed/ and "Architectural Guidelines for Multipath TCP Development" https://datatracker.ietf.org/doc/draft-ietf-mptcp-architecture/ > to all a target host's IPs instead of just one, so both hosts can > learn of each other's IP addresses > that are offered to be used for that connection, then "multiple PA > IP addresses" > would be a technically viable multi-homing strategy. > > > -- > -Jh From matthew at matthew.at Wed Oct 20 21:45:43 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 20 Oct 2010 19:45:43 -0700 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> Message-ID: <4CBFA957.1030609@matthew.at> On 10/20/2010 7:15 PM, James Hess wrote: > > Perhaps one day, there will be a truly reliable transport protocol, > and an API that allows a bind() > against multiple IPs and a connect() > to all a target host's IPs instead of just one, so both hosts can > learn of each other's IP addresses > that are offered to be used for that connection, then "multiple PA > IP addresses" > would be a technically viable multi-homing strategy. That protocol already exists and is installed on almost every personal computer in the world... but there's alas there's still a lot of TCP out there. By the way, the problems you listed are some, but not all, of the reasons why it isn't really a viable multi-homing strategy... but yours also include some of the reasons why having ULA + globally-routed space both active would be a problem for many applications. Matthew Kaufman From matthew at matthew.at Wed Oct 20 21:47:23 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 20 Oct 2010 19:47:23 -0700 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: <20101021022224.88FEC5F0352@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org><4CBF9B7A.1000500@matthew.at> <20101021022224.88FEC5F0352@drugs.dv.isc.org> Message-ID: <4CBFA9BB.9030100@matthew.at> On 10/20/2010 7:22 PM, Mark Andrews wrote: > In message<4CBF9B7A.1000500 at matthew.at>, Matthew Kaufman writes: >> On 10/20/2010 6:20 PM, Mark Smith wrote: >>> To make it clear, as it seems to be quite misunderstood, you'd have >>> both ULA and global addressing in your network. >> Right. Just like to multihome with IPv6 you would have both PA addresses >> from provider #1 and PA addresses from provider #2 in your network. >> >> Only nobody wants to do that either. > Only because there isn't good support for it yet. Too bad that support didn't come first, or all the issues with address allocation and routing table size being discussed elsewhere wouldn't be a problem for operators. > ULA + PA actually works today. The IP stack can do the address > selection without worrying about reachability. The chances of the > ULA being unreachable and the PA being reachable between two nodes > in the same ULA prefix are negligable. If I'm talking to a ULA > address I'll use my ULA address. If I'm talking to a non-ULA address > I'll use my PA addresses. > > PA + PA is a problem because you need to worry about source address > selection and that is driven by reachability. You also need to > worry about egress points due to source address filtering. etc. ULA + PA can have the same problems, especially if your ULA is inter-organization ULA, which was one of the cases under discussion. Matthew Kaufman From matthew at matthew.at Wed Oct 20 21:50:06 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 20 Oct 2010 19:50:06 -0700 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: <20101021125730.3bb576b4@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> <20101021125730.3bb576b4@opy.nosense.org> Message-ID: <4CBFAA5E.8000308@matthew.at> On 10/20/2010 7:27 PM, Mark Smith wrote: > > * Stream Control Transport Protocol, first spec'd in 2000 (couldn't > be deployed widely in IPv4 because of NATs) "because of NATs" s/b "because certain parties refused to acknowledge that encapsulation of SCTP in UDP would have operational advantages sufficient to outweigh the disadvantages". SCTP only gets you 90% of the way there, but it is a lot closer than today's TCP is. Matthew Kaufman From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 20 22:18:29 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 13:48:29 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: <4CBFAA5E.8000308@matthew.at> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> <20101021125730.3bb576b4@opy.nosense.org> <4CBFAA5E.8000308@matthew.at> Message-ID: <20101021134829.28153f37@opy.nosense.org> On Wed, 20 Oct 2010 19:50:06 -0700 Matthew Kaufman wrote: > On 10/20/2010 7:27 PM, Mark Smith wrote: > > > > * Stream Control Transport Protocol, first spec'd in 2000 (couldn't > > be deployed widely in IPv4 because of NATs) > "because of NATs" s/b "because certain parties refused to acknowledge > that encapsulation of SCTP in UDP would have operational advantages > sufficient to outweigh the disadvantages". > > SCTP only gets you 90% of the way there, but it is a lot closer than > today's TCP is. > Which is why there is also work going on at the network layer, both on the end-hosts via HIP or Shim6, and in the network, such as LISP. Ultimately, this is a hard problem to solve. There is no easy solution, otherwise it'd already exist, and have existed at least 10 years ago - as that is at least how long people have been working on trying to solve it. As there is no easy and perfect solution, then we need to accept that we're going to have to make trade offs to be able to get closer to solving it. In other words, a better solution, even if it isn't perfect, is better. The question is what trade offs are acceptable to make? We know and have experienced the many drawbacks of NAT, including such things as restricting deployment of new and better transport protocols like SCTP, DCCP, and maybe multipath TCP if the NAT boxes inspect and drop unknown TCP options, and forcing the nature of Internet applications to be client-server, even when a peer-to-peer application communications architecture would be far more reliable, scalable and secure. As NAT ultimately was about conserving address space, and IPv6 solves that problem, it is worth exploring other options that weren't possible with IPv4 and/or IPv4 NAT. Regards, Mark. From gbonser at seven.com Wed Oct 20 22:12:11 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 20 Oct 2010 20:12:11 -0700 Subject: =?UTF-8?B?UkU6IElQdjYgZmMwMDo6Lzcg4oCUIFVuaXF1ZSBsb2NhbA==?= =?UTF-8?B?IGFkZHJlc3Nlcw==?= In-Reply-To: <20101021125730.3bb576b4@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net><20101021115021.2dc77ce6@opy.nosense.org><4CBF9B7A.1000500@matthew.at> <20101021125730.3bb576b4@opy.nosense.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C3EF@RWC-EX1.corp.seven.com> > > * Stream Control Transport Protocol, first spec'd in 2000 (couldn't > be deployed widely in IPv4 because of NATs) I would dearly love to see SCTP take off. There are so many great potential applications for that protocol that it can boggle. Any type of connection between two things that might have several different kinds of data going back and forth at the same time could greatly benefit. From marka at isc.org Wed Oct 20 22:29:11 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Oct 2010 14:29:11 +1100 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: Your message of "Wed, 20 Oct 2010 19:47:23 PDT." <4CBFA9BB.9030100@matthew.at> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org><4CBF9B7A.1000500@matthew.at> <20101021022224.88FEC5F0352@drugs.dv.isc.org><4CBFA9BB.9030100@matthew.at> Message-ID: <20101021032911.C735F5F076F@drugs.dv.isc.org> In message <4CBFA9BB.9030100 at matthew.at>, Matthew Kaufman writes: > ULA + PA can have the same problems, especially if your ULA is > inter-organization ULA, which was one of the cases under discussion. Which still isn't a problem. Presumably you want your inter-organization traffic to use ULA addresses to talk to each other so you setup the address selection rules to do just that. That requires new rules being distributed to all nodes that need to talk to the other site. Presumable DHCPv6 could do this. If there isn't yet a DHCP option to request address selection rules we need to define one. Use a VPN between the organisations so you fate share. If you have a private interconnect then the VPN becomes the backup. > Matthew Kaufman > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 20 22:31:59 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 14:01:59 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: <20101021032911.C735F5F076F@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> <20101021022224.88FEC5F0352@drugs.dv.isc.org> <4CBFA9BB.9030100@matthew.at> <20101021032911.C735F5F076F@drugs.dv.isc.org> Message-ID: <20101021140159.10ba6790@opy.nosense.org> On Thu, 21 Oct 2010 14:29:11 +1100 Mark Andrews wrote: > > In message <4CBFA9BB.9030100 at matthew.at>, Matthew Kaufman writes: > > ULA + PA can have the same problems, especially if your ULA is > > inter-organization ULA, which was one of the cases under discussion. > > Which still isn't a problem. Presumably you want your inter-organization > traffic to use ULA addresses to talk to each other so you setup the > address selection rules to do just that. That requires new rules > being distributed to all nodes that need to talk to the other site. > Presumable DHCPv6 could do this. If there isn't yet a DHCP option > to request address selection rules we need to define one. One is being defined - https://datatracker.ietf.org/doc/draft-fujisaki-6man-addr-select-opt/ > Use a > VPN between the organisations so you fate share. If you have a > private interconnect then the VPN becomes the backup. > > > Matthew Kaufman > > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From patrick at zill.net Wed Oct 20 22:36:43 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Wed, 20 Oct 2010 23:36:43 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBC3328.7090205@unfix.org> References: <4CBC3328.7090205@unfix.org> Message-ID: <4CBFB54B.9010707@zill.net> On 10/18/2010 7:44 AM, Jeroen Massar wrote: > APNIC just got another IPv4 /8 thus only 5 left: > > http://www.nro.net/media/remaining-ipv4-address-below-5.html > (And the spammers will take the rest...) > > So, if your company is not doing IPv6 yet, you really are really getting > late now. > Actually for those of my clients in one location, it served as an impetus to extend a contract with Level3 for another 3 years - with their existing allocation of a /24 of IPv4 addresses included. IPv6 is for those who are "late" in getting IPv4 space! ( grinning, ducking, and running )... --Patrick From santino.codispoti at gmail.com Wed Oct 20 23:16:26 2010 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Thu, 21 Oct 2010 00:16:26 -0400 Subject: data center locations - recommendation's Message-ID: I am hoping the list can help me out. We need to setup a few data center locations and I was looking for recommendation?s on City?s and possible providers to rent space from. I was thinking two within the US to service North America and possibility also South America. Then also two within Europe. We would replicate data between the two in Europe and the two within the US but we would not replicate Europe to US. From morrowc.lists at gmail.com Wed Oct 20 23:30:12 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Oct 2010 00:30:12 -0400 Subject: data center locations - recommendation's In-Reply-To: References: Message-ID: On Thu, Oct 21, 2010 at 12:16 AM, Santino Codispoti wrote: > I am hoping the list can help me out. ?We need to setup a few data center > locations and I was looking for recommendation?s on City?s and possible > providers to rent space from. ?I was thinking two within the US to service North > America and possibility also South America. ?Then also two within Europe. ?We > would replicate data between the two in Europe and the two within the US but we > would not replicate Europe to US. o where are your customers? o what sort of colo do you really need? (space + power + ethernet + ? how much roughly...) o what sort of latency is acceptable to the customers for the applications in question? -chris From graham at apolix.co.za Wed Oct 20 23:30:08 2010 From: graham at apolix.co.za (Graham Beneke) Date: Thu, 21 Oct 2010 06:30:08 +0200 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> Message-ID: <4CBFC1D0.60808@apolix.co.za> On 21/10/2010 02:41, Owen DeLong wrote: > On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote: >> Someone advised me to use GUA instead of ULA. But since for my purposes this is used for an IPv6 LAN would ULA not be the better choice? >> > IMHO, no. There's no disadvantage to using GUA and I personally don't think ULA really serves a purpose. If you want to later connect this > LAN to the internet or something that connects to something that connects to something that connects to the internet or whatever, GUA provides > the following advantages: > + Guaranteed uniqueness (not just statistically probable uniqueness) > + You can route it if you later desire to > > Since ULA offers no real advantages, I don't really see the point. Someone insisted to me yesterday the RFC1918-like address space was the only way to provide a 'friendly' place for people to start their journey in playing with IPv6. I think that the idea of real routable IPs on a lab network daunts many people. I've been down the road with ULA a few years back and I have to agree with Owen - rather just do it on GUA. I was adding IPv6 to a fairly large experimental network and started using ULA. The local NREN then invited me to peer with them but I couldn't announce my ULA to them. They are running a 'public Internet' network and have a backbone that will just filter them. I think that the biggest thing that trips people up is that they think that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting your own GUA from an RIR isn't tough - rather just do it. -- Graham Beneke From graham at apolix.co.za Wed Oct 20 23:38:33 2010 From: graham at apolix.co.za (Graham Beneke) Date: Thu, 21 Oct 2010 06:38:33 +0200 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: <4CBF9C42.3050608@matthew.at> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> Message-ID: <4CBFC3C9.706@apolix.co.za> On 21/10/2010 03:49, Matthew Kaufman wrote: > On 10/20/2010 5:51 PM, Owen DeLong wrote: >> >> Part 2 will be when the first provider accepts a large sum of money to >> route it within their public network between multiple sites owned by >> the same customer. > > Is this happening now with RFC 1918 addresses and IPv4? I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN. >> Part 3 will be when that same provider (or some other provider in the >> same boat) takes the next step and starts trading routes of ULA space >> with other provider(s). > > Is this happening now with RFC 1918 addresses and IPv4? I've seen this too. Once again small providers who pretty quickly get caught out by collisions. The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess. -- Graham Beneke From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Wed Oct 20 23:41:13 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 15:11:13 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C3EF@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> <20101021125730.3bb576b4@opy.nosense.org> <5A6D953473350C4B9995546AFE9939EE0B14C3EF@RWC-EX1.corp.seven.com> Message-ID: <20101021151113.122f9b37@opy.nosense.org> On Wed, 20 Oct 2010 20:12:11 -0700 "George Bonser" wrote: > > > > * Stream Control Transport Protocol, first spec'd in 2000 (couldn't > > be deployed widely in IPv4 because of NATs) > > I would dearly love to see SCTP take off. There are so many great potential applications for that protocol that it can boggle. Any type of connection between two things that might have several different kinds of data going back and forth at the same time could greatly benefit. > I agree. One application I'd though of was end-to-end Instant Messaging, where, when you wish to transfer a file to the other participant, a new SCTP stream is created for the file transfer within the existing SCTP connection. Not all that novel, but something that would be much easier to do with SCTP than TCP. Regards, Mark. From adrian at creative.net.au Wed Oct 20 23:44:40 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Thu, 21 Oct 2010 12:44:40 +0800 Subject: IPv6 fc00::/7 ? Unique local addresses In-Reply-To: <4CBFC3C9.706@apolix.co.za> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> <4CBFC3C9.706@apolix.co.za> Message-ID: <20101021044440.GI3573@skywalker.creative.net.au> On Thu, Oct 21, 2010, Graham Beneke wrote: > I've seen this too. Once again small providers who pretty quickly get > caught out by collisions. > > The difference is that ULA could take years or even decades to catch > someone out with a collision. By then we'll have a huge mess. You assume that people simply select ULA prefixes randomly and don't start doing linear allocations from the beginning of the ULA range. Adrian From santino.codispoti at gmail.com Wed Oct 20 23:56:53 2010 From: santino.codispoti at gmail.com (Santino Codispoti) Date: Thu, 21 Oct 2010 00:56:53 -0400 Subject: data center locations - recommendation's In-Reply-To: References: Message-ID: Please see inline On Thu, Oct 21, 2010 at 12:30 AM, Christopher Morrow wrote: > On Thu, Oct 21, 2010 at 12:16 AM, Santino Codispoti > wrote: >> I am hoping the list can help me out. ?We need to setup a few data center >> locations and I was looking for recommendation?s on City?s and possible >> providers to rent space from. ?I was thinking two within the US to service North >> America and possibility also South America. ?Then also two within Europe. ?We >> would replicate data between the two in Europe and the two within the US but we >> would not replicate Europe to US. > > o where are your customers? Are customers are global > o what sort of colo do you really need? (space + power + ethernet + ? > how much roughly...) This is not completely know yet but I would say less then 10 racks > o what sort of latency is acceptable to the customers for the > applications in question? I would like in most cases less then 70ms total but some customers will be accessing the solution from mobile hand sets so it may be a bit more due to to delay on GSM networks > > -chris > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Oct 21 00:07:02 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 15:37:02 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: <4CBFC3C9.706@apolix.co.za> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> <4CBFC3C9.706@apolix.co.za> Message-ID: <20101021153702.425ee89e@opy.nosense.org> On Thu, 21 Oct 2010 06:38:33 +0200 Graham Beneke wrote: > On 21/10/2010 03:49, Matthew Kaufman wrote: > > On 10/20/2010 5:51 PM, Owen DeLong wrote: > >> > >> Part 2 will be when the first provider accepts a large sum of money to > >> route it within their public network between multiple sites owned by > >> the same customer. > > > > Is this happening now with RFC 1918 addresses and IPv4? > > I have seen this in some small providers. Doesn't last long since the > chance of collision is high. It then becomes a VPN. > > >> Part 3 will be when that same provider (or some other provider in the > >> same boat) takes the next step and starts trading routes of ULA space > >> with other provider(s). > > > > Is this happening now with RFC 1918 addresses and IPv4? > > I've seen this too. Once again small providers who pretty quickly get > caught out by collisions. > > The difference is that ULA could take years or even decades to catch > someone out with a collision. By then we'll have a huge mess. > I don't think there is a difference. The very small providers are the ones who make the stupid mistakes, it's the larger ones that do the right thing because it is in their operational interests. Operational competence, and the resulting increased reliability, is one of the attributes customers of ISPs value highly. If any of the Tier-1s don't route ULA address space, then it is useless compared to global addresses that *are* routed by *all* the Tier-1s. As the Tier-1s also hire competent networking people, they'll also understand the scaling issues of the ULA address space, and why it shouldn't be globally routed. Competent networking people also exist at the lower tiers as well. If operators just blindly accept and implement what sales people tell them to, then those operators aren't operators. They're mindless drones - and the rest of the people operating the Internet will protect the Internet from them. Darwin eventually gets rid of those operators and the ISP that employ them. Since ULAs could be used as DoS attack sources, they'll also likely be filtered out by most people as per BCP38. Regards, Mark. From joelja at bogus.com Thu Oct 21 00:12:44 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Wed, 20 Oct 2010 22:12:44 -0700 Subject: IPv6 fc00::/7 ? Unique local addresses In-Reply-To: <20101021044440.GI3573@skywalker.creative.net.au> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> <4CBFC3C9.706@apolix.co.za> <20101021044440.GI3573@skywalker.creative.net.au> Message-ID: <4CBFCBCC.50902@bogus.com> On 10/20/10 9:44 PM, Adrian Chadd wrote: > On Thu, Oct 21, 2010, Graham Beneke wrote: > >> I've seen this too. Once again small providers who pretty quickly get >> caught out by collisions. >> >> The difference is that ULA could take years or even decades to catch >> someone out with a collision. By then we'll have a huge mess. having merged datacenters with multiple overlapping v4 prefixes I'll just observe that this is inevitable in v4, you can take steps that make it less likely to impact you in v6. > You assume that people simply select ULA prefixes randomly and don't > start doing linear allocations from the beginning of the ULA range. actually I assume they're going to just assign the whole botton half to themselves like they do with 10/8 since using fc01::/8 is clearly more work. If you do assign randomly the probability of someone deliberately assigning the same /48 for use in their network seems pretty low, you're a heck of a lot better off than with rfc 1918. > > > > Adrian > > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Oct 21 00:17:02 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Thu, 21 Oct 2010 15:47:02 +1030 Subject: IPv6 fc00::/7 ? Unique local addresses In-Reply-To: <20101021044440.GI3573@skywalker.creative.net.au> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> <4CBFC3C9.706@apolix.co.za> <20101021044440.GI3573@skywalker.creative.net.au> Message-ID: <20101021154702.1d15ca98@opy.nosense.org> On Thu, 21 Oct 2010 12:44:40 +0800 Adrian Chadd wrote: > On Thu, Oct 21, 2010, Graham Beneke wrote: > > > I've seen this too. Once again small providers who pretty quickly get > > caught out by collisions. > > > > The difference is that ULA could take years or even decades to catch > > someone out with a collision. By then we'll have a huge mess. > > You assume that people simply select ULA prefixes randomly and don't > start doing linear allocations from the beginning of the ULA range. > > Any time there is a parameter that can be configured, there is a possibility that people will misconfigure it. The only way to completely prevent that being a possibility is to eliminate the parameter. We can prevent people from getting addressing wrong by not putting addresses in the IP header - but I, and I suspect most people, would prefer their computers not to be a dumb terminal connected to a mainframe. Or we can make the network robust against misconfiguration, and put in place things like BCP38. This is all starting to sound a bit like Chicken Little. Regards, Mark. From marka at isc.org Thu Oct 21 00:28:52 2010 From: marka at isc.org (Mark Andrews) Date: Thu, 21 Oct 2010 16:28:52 +1100 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: Your message of "Thu, 21 Oct 2010 06:30:08 +0200." <4CBFC1D0.60808@apolix.co.za> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> Message-ID: <20101021052852.A46E75F0E6C@drugs.dv.isc.org> In message <4CBFC1D0.60808 at apolix.co.za>, Graham Beneke writes: > On 21/10/2010 02:41, Owen DeLong wrote: > > On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote: > >> Someone advised me to use GUA instead of ULA. But since for my purposes th > is is used for an IPv6 LAN would ULA not be the better choice? > >> > > IMHO, no. There's no disadvantage to using GUA and I personally don't think > ULA really serves a purpose. If you want to later connect this > > LAN to the internet or something that connects to something that connects t > o something that connects to the internet or whatever, GUA provides > > the following advantages: > > + Guaranteed uniqueness (not just statistically probable uniquene > ss) > > + You can route it if you later desire to > > > > Since ULA offers no real advantages, I don't really see the point. > > Someone insisted to me yesterday the RFC1918-like address space was the > only way to provide a 'friendly' place for people to start their journey > in playing with IPv6. I think that the idea of real routable IPs on a > lab network daunts many people. > > I've been down the road with ULA a few years back and I have to agree > with Owen - rather just do it on GUA. Your throwing the baby out with the bath water here. ULA, by itself, is a painful especially when you have global IPv4 reachability as you end up with lots of timeouts. This is similar to have a bad 6to4 upsteam link. Just don't go there. ULA + PA works and provides stable internal addresses when your upstream link in down the same way as RFC 1918 provides stable internal addressing for IPv4 when your upstream link is down. You talk to the world using PA addresses, directly for IPv6 and indirectly via PNAT for IPv4. These can change over time. Similarly, ULA + 6to4 works well provided the 6to4 works when you are connected. When your IPv4 connection is renumbered you have a new external addresses but the internal addresses stay the same. > I was adding IPv6 to a fairly large experimental network and started > using ULA. The local NREN then invited me to peer with them but I > couldn't announce my ULA to them. They are running a 'public Internet' > network and have a backbone that will just filter them. > > I think that the biggest thing that trips people up is that they think > that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting > your own GUA from an RIR isn't tough - rather just do it. If your big enough to get your own GUA and have the dollars to get it routed then do that. If you are forced to use PA (think home networks) then having a ULA prefix as well is a good thing. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From matthew at matthew.at Thu Oct 21 00:38:56 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Wed, 20 Oct 2010 22:38:56 -0700 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: <4CBFC1D0.60808@apolix.co.za> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> Message-ID: <4CBFD1F0.1010300@matthew.at> On 10/20/2010 9:30 PM, Graham Beneke wrote: > > Someone insisted to me yesterday the RFC1918-like address space was > the only way to provide a 'friendly' place for people to start their > journey in playing with IPv6. I think that the idea of real routable > IPs on a lab network daunts many people. I once worked at a place that really *really* didn't want "real routable IPs" on their giant disk-protocols-over-IP network and wanted to start playing with IPv6 in those labs. What they wanted address space they knew no other company they ever merged with might be using, but which also would never, ever be on the public IPv6 Internet. At the time, there was no solution but to misuse ULA space. They're probably still doing just that. > > I've been down the road with ULA a few years back and I have to agree > with Owen - rather just do it on GUA. > > I was adding IPv6 to a fairly large experimental network and started > using ULA. The local NREN then invited me to peer with them but I > couldn't announce my ULA to them. They are running a 'public Internet' > network and have a backbone that will just filter them. > > I think that the biggest thing that trips people up is that they think > that they'll just fix-it-with-NAT to get onto the GUA Internet. > Getting your own GUA from an RIR isn't tough - rather just do it. > It isn't tough, but it isn't free either. I have an experimental network that I'd love to run IPv6 with my own GUAs on (for the aforementioned sorts of reasons, like what happens when you want to interconnect with others), but it wouldn't be connected (for quite some time) to the public IPv6 Internet and there are *zero* funds available for the fees for PI space. It just isn't like 1992 (or even 1994) was for IPv4. Matthew Kaufman From gbonser at seven.com Thu Oct 21 00:41:20 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 20 Oct 2010 22:41:20 -0700 Subject: =?UTF-8?B?UkU6IElQdjYgZmMwMDo6Lzcg4oCUIFVuaXF1ZSBsb2NhbA==?= =?UTF-8?B?IGFkZHJlc3Nlcw==?= In-Reply-To: <20101021151113.122f9b37@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net><20101021115021.2dc77ce6@opy.nosense.org><4CBF9B7A.1000500@matthew.at><20101021125730.3bb576b4@opy.nosense.org><5A6D953473350C4B9995546AFE9939EE0B14C3EF@RWC-EX1.corp.seven.com> <20101021151113.122f9b37@opy.nosense.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C3F5@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Mark Smith > [mailto:nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] > Sent: Wednesday, October 20, 2010 9:41 PM > To: George Bonser > Cc: nanog at nanog.org > Subject: Re: IPv6 fc00::/7 ? Unique local addresses > > I agree. One application I'd though of was end-to-end Instant > Messaging, where, when you wish to transfer a file to the other > participant, a new SCTP stream is created for the file transfer within > the existing SCTP connection. Not all that novel, but something that > would be much easier to do with SCTP than TCP. The absolute win is the elimination of "head of line" blocking. So if you have a large transfer going, that little short IM or even email notification or whatever gets sent immediately by being multiplexed into the data stream instead of being dumped in at the end of a buffer full of other stuff. By having streams for different sorts of content, it has the potential to conserve considerable resources. Rather than having a separate connection for each type of content, you have only one. Now if they would figure out a good way to load balance SCTP, we would be all set. But the real win is where you have a mix of bulk data streams and interactive small data transfers. The bulk transfer doesn't interfere with the interactive experience. And there are so many other potential applications like maybe persistent VOIP "trunks" between branch offices over a long-lived SCTP connection with each of those "trunks" being a stream within one connection. The applications are potentially killer but nobody has really tapped into that area yet. Heck, multicast hasn't really lived up to its potential, either. From owen at delong.com Thu Oct 21 02:46:00 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 00:46:00 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101021120648.1872981a@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <20101021120648.1872981a@opy.nosense.org> Message-ID: >>> >> Which is part one of the three things that have to happen to make ULA >> really bad for the internet. >> >> Part 2 will be when the first provider accepts a large sum of money to >> route it within their public network between multiple sites owned by >> the same customer. >> > > That same customer is also going to have enough global address > space to be able to reach other global destinations, at least enough > space for all nodes that are permitted to access the Internet, if not > more. Proper global address space ensures that if a global destination > is reachable, then there is a high probability of successfully reaching > it. The scope of external ULA reachability, regardless of how much > money is thrown at the problem, isn't going to be as good as proper > global addresses. > _IF_ they implement as intended and as documented. As you've noted there's a lot of confusion and a lot of people not reading the documents, latching onto ULA and deciding ti's good. It's not a big leap for some company to do a huge ULA deployment saying "this will never connect to the intarweb thingy" and 5-10 years later not want to redeploy all their addressing, so, they start throwing money at getting providers to do what they shouldn't instead of readdressing their networks. > For private site interconnect, I'd think it more likely that the > provider would isolate the customers traffic and ULA address space via > something like a VPN service e.g. MPLS, IPsec. > One would hope, but, I bet laziness and misunderstanding trumps reason and adherence to RFCs over the long term. Since ULA won't get hard-coded into routers as unroutable (it can't), when people do bad stuff with it, it will work and since it works, they won't go read the documentation explaining that what works is a bad idea. >> Part 3 will be when that same provider (or some other provider in the >> same boat) takes the next step and starts trading routes of ULA space >> with other provider(s). >> >> At that point, ULA = GUA without policy = very bad thing (tm). >> >> Since feature creep of this form is kind of a given in internet history, >> I have no reason to believe it won't happen eventually with ULA. >> > > So I'm not sure I can see much benefit would be of paying a > huge amount of money to have ULA address space put in only a > limited part/domain of the global route table. The only way to > have ULA = GUA is to pay everybody on the Internet to carry it, and > that is assuming that everybody would be willing to accept the money > in the first place. That'd be far more expensive than just using GUA > addresses for global reachability. > No... The way it will work is that use of ULA as pseudo-GUA will spread slowly like cancer through the network. When provider A and provider B both have customers throwing lots of money at them to route their ULA, provider A and provider B will swallow hard and agree to exchange those routes in both directions. I wish I had your confidence in people doing the right thing, but, there are enough examples of RFC-1918 space in the GRT that I simply can't share your belief that it won't happen with ULA which doesn't have the reliability problems that RFC-1918 had. Owen From owen at delong.com Thu Oct 21 02:57:11 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 00:57:11 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <4CBF9B7A.1000500@matthew.at> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> Message-ID: On Oct 20, 2010, at 6:46 PM, Matthew Kaufman wrote: > On 10/20/2010 6:20 PM, Mark Smith wrote: >> >> To make it clear, as it seems to be quite misunderstood, you'd have >> both ULA and global addressing in your network. > > Right. Just like to multihome with IPv6 you would have both PA addresses from provider #1 and PA addresses from provider #2 in your network. > Or PI addresses from an RIR. > Only nobody wants to do that either. > There are lots of good reasons not to want to do that. Owen From owen at delong.com Thu Oct 21 03:28:14 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 01:28:14 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBFB54B.9010707@zill.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> Message-ID: On Oct 20, 2010, at 8:36 PM, Patrick Giagnocavo wrote: > On 10/18/2010 7:44 AM, Jeroen Massar wrote: >> APNIC just got another IPv4 /8 thus only 5 left: >> >> http://www.nro.net/media/remaining-ipv4-address-below-5.html >> (And the spammers will take the rest...) >> >> So, if your company is not doing IPv6 yet, you really are really getting >> late now. >> > > Actually for those of my clients in one location, it served as an > impetus to extend a contract with Level3 for another 3 years - with > their existing allocation of a /24 of IPv4 addresses included. All well and good until some of their customers are on IPv6... Then what? Owen From owen at delong.com Thu Oct 21 03:35:55 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 01:35:55 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <4CBFC3C9.706@apolix.co.za> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> <4CBFC3C9.706@apolix.co.za> Message-ID: On Oct 20, 2010, at 9:38 PM, Graham Beneke wrote: > On 21/10/2010 03:49, Matthew Kaufman wrote: >> On 10/20/2010 5:51 PM, Owen DeLong wrote: >>> >>> Part 2 will be when the first provider accepts a large sum of money to >>> route it within their public network between multiple sites owned by >>> the same customer. >> >> Is this happening now with RFC 1918 addresses and IPv4? > > I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN. > Correct... The only reason it isn't is because of the high chance of collision. Due to virtually guaranteed overlapping address conflicts, it doesn't work with RFC-1918. ULA solves that "problem" by providing probably unique addresses. >>> Part 3 will be when that same provider (or some other provider in the >>> same boat) takes the next step and starts trading routes of ULA space >>> with other provider(s). >> >> Is this happening now with RFC 1918 addresses and IPv4? > > I've seen this too. Once again small providers who pretty quickly get caught out by collisions. > > The difference is that ULA could take years or even decades to catch someone out with a collision. By then we'll have a huge mess. > Exactly. Owen From owen at delong.com Thu Oct 21 03:33:59 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 01:33:59 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <4CBFC1D0.60808@apolix.co.za> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> Message-ID: <6B22AD72-01DE-46A0-BA7E-C3A62BE62434@delong.com> On Oct 20, 2010, at 9:30 PM, Graham Beneke wrote: > On 21/10/2010 02:41, Owen DeLong wrote: >> On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote: >>> Someone advised me to use GUA instead of ULA. But since for my purposes this is used for an IPv6 LAN would ULA not be the better choice? >>> >> IMHO, no. There's no disadvantage to using GUA and I personally don't think ULA really serves a purpose. If you want to later connect this >> LAN to the internet or something that connects to something that connects to something that connects to the internet or whatever, GUA provides >> the following advantages: >> + Guaranteed uniqueness (not just statistically probable uniqueness) >> + You can route it if you later desire to >> >> Since ULA offers no real advantages, I don't really see the point. > > Someone insisted to me yesterday the RFC1918-like address space was the only way to provide a 'friendly' place for people to start their journey in playing with IPv6. I think that the idea of real routable IPs on a lab network daunts many people. > They should get less daunted. You can always put a firewall with a deny all policy or an air-gap in front of it if you don't want to talk to the internet. > I've been down the road with ULA a few years back and I have to agree with Owen - rather just do it on GUA. > Thanks. > I was adding IPv6 to a fairly large experimental network and started using ULA. The local NREN then invited me to peer with them but I couldn't announce my ULA to them. They are running a 'public Internet' network and have a backbone that will just filter them. > Uh huh. Now, imagine if, instead of a small experimental deployment, you had a fortune 500 enterprise and instead of an NREN it was an ISP for whom you were a major customer... Any bets on which side of that equation gets the policy change? > I think that the biggest thing that trips people up is that they think that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting your own GUA from an RIR isn't tough - rather just do it. > I completely agree. Owen From owen at delong.com Thu Oct 21 03:42:23 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 01:42:23 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101021153702.425ee89e@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> <4CBFC3C9.706@apolix.co.za> <20101021153702.425ee89e@opy.nosense.org> Message-ID: <4D05AD49-7318-4D2B-B654-5C1BCD72744E@delong.com> On Oct 20, 2010, at 10:07 PM, Mark Smith wrote: > On Thu, 21 Oct 2010 06:38:33 +0200 > Graham Beneke wrote: > >> On 21/10/2010 03:49, Matthew Kaufman wrote: >>> On 10/20/2010 5:51 PM, Owen DeLong wrote: >>>> >>>> Part 2 will be when the first provider accepts a large sum of money to >>>> route it within their public network between multiple sites owned by >>>> the same customer. >>> >>> Is this happening now with RFC 1918 addresses and IPv4? >> >> I have seen this in some small providers. Doesn't last long since the >> chance of collision is high. It then becomes a VPN. >> >>>> Part 3 will be when that same provider (or some other provider in the >>>> same boat) takes the next step and starts trading routes of ULA space >>>> with other provider(s). >>> >>> Is this happening now with RFC 1918 addresses and IPv4? >> >> I've seen this too. Once again small providers who pretty quickly get >> caught out by collisions. >> >> The difference is that ULA could take years or even decades to catch >> someone out with a collision. By then we'll have a huge mess. >> > > I don't think there is a difference. The very small providers are > the ones who make the stupid mistakes, it's the larger ones that do the > right thing because it is in their operational interests. Operational > competence, and the resulting increased reliability, is one of the > attributes customers of ISPs value highly. > > If any of the Tier-1s don't route ULA address space, then it is useless > compared to global addresses that *are* routed by *all* the Tier-1s. As > the Tier-1s also hire competent networking people, they'll also > understand the scaling issues of the ULA address space, and why it > shouldn't be globally routed. Competent networking people also exist at > the lower tiers as well. > Ah, but, since statistically probable Uniqueness is present, I'm betting eventually some combination of Tier-1s will get bought off to route ULA and then the flood gates open. Tier-1s are famous for having their sales and accounting departments override good engineering practices on a somewhat regular basis. With RFC-1918 this couldn't happen because collisions meant it simply wouldn't work. ULA has no such impediment. > If operators just blindly accept and implement what sales people tell > them to, then those operators aren't operators. They're mindless drones > - and the rest of the people operating the Internet will protect the > Internet from them. Darwin eventually gets rid of those operators > and the ISP that employ them. > There's a difference between blind acceptance and adherence to a direct overriding order from the guy that signs your paycheck. I'm sure they will attempt to fight the good fight, but, in the end, $$ tend to trump good engineering unless what the $$ want simply can't be made to work. > Since ULAs could be used as DoS attack sources, they'll also likely be > filtered out by most people as per BCP38. > Maybe... Given what I've seen with RFC-1918 and other BCP38 violations, I lack your faith. Owen From owen at delong.com Thu Oct 21 03:46:55 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 01:46:55 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101021052852.A46E75F0E6C@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> Message-ID: <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> On Oct 20, 2010, at 10:28 PM, Mark Andrews wrote: > > In message <4CBFC1D0.60808 at apolix.co.za>, Graham Beneke writes: >> On 21/10/2010 02:41, Owen DeLong wrote: >>> On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote: >>>> Someone advised me to use GUA instead of ULA. But since for my purposes th >> is is used for an IPv6 LAN would ULA not be the better choice? >>>> >>> IMHO, no. There's no disadvantage to using GUA and I personally don't think >> ULA really serves a purpose. If you want to later connect this >>> LAN to the internet or something that connects to something that connects t >> o something that connects to the internet or whatever, GUA provides >>> the following advantages: >>> + Guaranteed uniqueness (not just statistically probable uniquene >> ss) >>> + You can route it if you later desire to >>> >>> Since ULA offers no real advantages, I don't really see the point. >> >> Someone insisted to me yesterday the RFC1918-like address space was the >> only way to provide a 'friendly' place for people to start their journey >> in playing with IPv6. I think that the idea of real routable IPs on a >> lab network daunts many people. >> >> I've been down the road with ULA a few years back and I have to agree >> with Owen - rather just do it on GUA. > > Your throwing the baby out with the bath water here. > > ULA, by itself, is a painful especially when you have global IPv4 > reachability as you end up with lots of timeouts. This is similar > to have a bad 6to4 upsteam link. Just don't go there. > > ULA + PA works and provides stable internal addresses when your > upstream link in down the same way as RFC 1918 provides stable > internal addressing for IPv4 when your upstream link is down. > I keep hearing this and it never makes sense to me. If your provider will assign you a static /48, then, you have stable addresses when your provider link is down in GUA. Who needs ULA? > You talk to the world using PA addresses, directly for IPv6 and > indirectly via PNAT for IPv4. These can change over time. > Or, if you don't want your IPv6 addresses to change over time, you can get a prefix from your friendly RIR. > Similarly, ULA + 6to4 works well provided the 6to4 works when you > are connected. When your IPv4 connection is renumbered you have a > new external addresses but the internal addresses stay the same. > That's a big "provided that"... One over which you have little or no control unless you are running a 6to4 gateway of your own and can guarantee that nobody pretends to be one that is topologically closer to any of your users. >> I was adding IPv6 to a fairly large experimental network and started >> using ULA. The local NREN then invited me to peer with them but I >> couldn't announce my ULA to them. They are running a 'public Internet' >> network and have a backbone that will just filter them. >> >> I think that the biggest thing that trips people up is that they think >> that they'll just fix-it-with-NAT to get onto the GUA Internet. Getting >> your own GUA from an RIR isn't tough - rather just do it. > > If your big enough to get your own GUA and have the dollars to get > it routed then do that. If you are forced to use PA (think home > networks) then having a ULA prefix as well is a good thing. > home network: 2620:0:930::/48 Try again. Owen From jeroen at unfix.org Thu Oct 21 06:03:28 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 21 Oct 2010 13:03:28 +0200 Subject: =?UTF-8?B?U2l4WFMgVUxBIFJlZ2lzdHJ5IGNsYXJpZmljYXRpb25zIC8gcXVlc3Q=?= =?UTF-8?B?aW9ucyAvIGNvbW1lbnRzIChXYXM6IElQdjYgZmMwMDo6Lzcg4oCUIFVuaXF1ZSA=?= =?UTF-8?B?bG9jYWwgYWRkcmVzc2VzKQ==?= In-Reply-To: <20101021105901.7f708b16@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> Message-ID: <4CC01E00.4000007@unfix.org> [subject changes, such a useful way to indicate something different ;) ] On 2010-10-21 02:29, Mark Smith wrote: > On Wed, 20 Oct 2010 19:39:19 -0400 > Deepak Jain wrote: [..] >> Though an algorithm is suggested in 3.2.2. Perhaps SIXXS uses it. As stated at the bottom of the page: "This page uses the Unique Local Address (RFC4193) Generator by SUZUKI Shinsuke and Holger Zuleger. It uses oui.txt from the IEEE OUI Database file." > Anyway, the SIXXS tool seems pretty slick. Thanks, but it effectively is just a call to the generator script as mentioned above + a insert into SQL... thus nothing fancy there ;) Thus thanks should go mostly to the above authors for their script that generates the numbers properly (linked from the page of course) > One thing I'm not keen on that sixxs have done is to create a voluntary > registry of the non-central ULAs. By creating a registry, I think some > people who use it will then think that their ULA prefix is now > guaranteed globally unique and is theirs forever. As the page mentions under Notes: "If everybody uses this registry though, the chance for collisions should be near nil." Indeed when somebody opts to not use this "registry", quite a big chance that they do, or use some other "registry", then the system fails. Still this just increases the probability of collisions, nothing else. (no math to prove that though, like in the RFC :) > If there ever was a > collision, those people are likely to point to that completely > voluntary registry and say "I had it first" and are likely to refuse > to accept that the voluntary registry has no status or authority over > the random ULA address space. And then it becomes a fight to who is right, nothing that can be done about that. > There also doesn't seem to be any limiting of the number of prefixes. Should there be? How would we limit anything? > In an isolated network, which is where ULAs are supposed to be used, > it's far less of a problem, because the only time the chance of > collision occurs is if you interconnect with somebody else's ULA > domain. However, as this sixxs registry implies it is a global one, and > therefore there is a single instance of the fd::/8 address space, > limiting the number of prefixes that are assigned would seem to me to > be good idea. When I see examples such as - Is there a problem that one entity has 7 /48's out of (2**(128-8-48)) possible ones... no I am not going to write out that number or write it out in a percentage ;) [..] > or 458 752 subnets, and http://deticon.net isn't reachable via IPv6 Maybe because ULA is *LOCAL* address space. For that matter, as a great example: you won't find 9.0.0.0/8 easily on the internet either, I can tell you though that it is quite heavily used and completely filled up, so far even that there are a lot more prefixes that that organization uses for other purposes. [..] > IPv4 (and hasn't been for quite a while - I checked a few months ago > when I discovered the registry), it seems to me that people have > already misunderstood what it's purpose is, and that the database is > already polluted with invalid entries that can't be verified for > existence, and which also can't be expired via some invalidation > mechanism, such as lack of payment of annual fees. You want us to charge for virtual numbers which don't really exist? :) For all entries we have an email address, at the time of registration that email address was tested at least as having a proper configuration. We could always, if we wanted but I don't see why, start spamming people and ask them if their registration data is still correct. If you really think that the list is polluted by some entries then don't hesitate to mail info at sixxs.net and next to all the other things we do we might be able to look into it. There really are enough /48's in that /8 for everybody. At this moment there are 1024 of them in there, I don't even think there is a percentage number for that yet. I don't even think you are able to generate a single ULA that will clash with one of the entries in the list unless you generate a really large amount of them, cause well, that is the whole point of the ULA generation algorithm in the first place. As long though as there are this few entries, I really cannot see the point for this. If you want guaranteed globally unique address space there is a simple way for you to already get this today and actually for the last 10 years: You go to your favorite RIR and you get a prefix. Please remember that a prefix you get from the RIRs does not have a requirement of being announced on the Internet, you can also use it to interconnect between your own local networks. This is also the reason why fc00::/8 will never be used, as it will be exactly the same as what the RIRs are doing today already with 2000::/3. Greets, Jeroen From owen at delong.com Thu Oct 21 06:23:33 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 04:23:33 -0700 Subject: =?windows-1252?Q?Re:_SixXS_ULA_Registry_clarifications_/_questio?= =?windows-1252?Q?ns_/_comments_=28Was:_IPv6_fc00::/7_=97_Unique_?= =?windows-1252?Q?local_addresses=29?= In-Reply-To: <4CC01E00.4000007@unfix.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <4CC01E00.4000007@unfix.org> Message-ID: <6D69D2A5-4DAB-4F8E-8BD6-3B73EE1E76B8@delong.com> > > Is there a problem that one entity has 7 /48's out of (2**(128-8-48)) > possible ones... no I am not going to write out that number or write it > out in a percentage ;) > Your math is incorrect... It's 2^40, not 2^(128-8-48) 8 fd00::/8 -- preassigned. 40 Randomly generated 16 Locally assigned 64 Host identifieers ---- 128 Of that, only the 40 randomly generated provide ULA prefix uniqueness. Still... 2^40 is ~1 Trillion prefixes. If 7 Billion people all grab 7 prefixes, that's still only 49 Billion prefixes. However, since there's no reclamation at death, and, we're not just talking about people, but, people+orgs+whatever, I can see the potential for the sixxs registry to get harvested and ULA exhausted in less than 50 years with concerted effort. However, running out of ULA is, IMHO, the least of our problems with such a registry and its practices. > [..] >> or 458 752 subnets, and http://deticon.net isn't reachable via IPv6 > > Maybe because ULA is *LOCAL* address space. For that matter, as a great > example: you won't find 9.0.0.0/8 easily on the internet either, I can > tell you though that it is quite heavily used and completely filled up, > so far even that there are a lot more prefixes that that organization > uses for other purposes. > He didn't say he couldn't find the prefix on the net. He said he couldn't find the domain name. I believe ibm.com is quite easy to find on the internet. > [..] >> IPv4 (and hasn't been for quite a while - I checked a few months ago >> when I discovered the registry), it seems to me that people have >> already misunderstood what it's purpose is, and that the database is >> already polluted with invalid entries that can't be verified for >> existence, and which also can't be expired via some invalidation >> mechanism, such as lack of payment of annual fees. > > You want us to charge for virtual numbers which don't really exist? :) > It is the only (so far) mechanism anyone has identified for being able to reliably confirm continued utilization of resources. If you have some other mechanism, go for it. If not, then you've just created a whole new class of swamp space and I will point you to the legacy address issues surrounding these same problems with IPv4 as an example of why this is a bad idea. > For all entries we have an email address, at the time of registration > that email address was tested at least as having a proper configuration. > We could always, if we wanted but I don't see why, start spamming people > and ask them if their registration data is still correct. > If the domain shown in the record isn't resolvable, it's a pretty good indication that the email address probably won't work, no? Deprecating someones registration just because they don't respond to email is, well, not something people have wanted the RIRs to do, so, likely SIXXS will have similar problems. > If you really think that the list is polluted by some entries then don't > hesitate to mail info at sixxs.net and next to all the other things we do > we might be able to look into it. > ROFLMAO... > There really are enough /48's in that /8 for everybody. At this moment > there are 1024 of them in there, I don't even think there is a > percentage number for that yet. I don't even think you are able to 1024 is roughly 1/1,000,000,000th of the space. 40 bits is roughly a trillion. > generate a single ULA that will clash with one of the entries in the > list unless you generate a really large amount of them, cause well, that > is the whole point of the ULA generation algorithm in the first place. > Yep. And the primary reason that ULA is a much worse idea than RFC-1918. > As long though as there are this few entries, I really cannot see the > point for this. > And so they created a new copy of the IPv4 swamp in IPv6 land, because they could, and, because they could not learn the lessons of history and were thus doomed to repeat them. > > Please remember that a prefix you get from the RIRs does not have a > requirement of being announced on the Internet, you can also use it to > interconnect between your own local networks. This is also the reason > why fc00::/8 will never be used, as it will be exactly the same as what > the RIRs are doing today already with 2000::/3. > Exactly, so, why even have this ULA confusion in fd00::/8 to begin with? Owen From rps at maine.edu Thu Oct 21 06:33:37 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 07:33:37 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <4CBF63BF.2000101@mompl.net> References: <4CBF63BF.2000101@mompl.net> Message-ID: For for all intents and purposes if you're looking for RFC1918 style space in IPv6 you should consider the block FD00::/8 not FC00::/7 as the FC00::/8 space is reserved in ULA for assignment by a central authority (who knows why, but with that much address space nobody really cares). People may throw a fit at this, but as far as I'm concerned FD00::/8 will never leave the edge of our network (we null route ULA space before it can leak out, just like you would with RFC1918 space). So you can pretty much use it has you see fit. If you want to keep your ULA space short there is nothing stopping you from using something like FD00::1 as a valid address. You could embed your ASN into it or some other identifier if you want to avoid conflicts with other non-routed address space which should never enter or leave your network from the outside, but I'm just not seeing the practical application for this. On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart wrote: > > > According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an > fc00::/7 address includes a 40-bit pseudo random number: > > "fc00::/7 ? Unique local addresses (ULA's) are intended for local > communication. They are routable only within a set of cooperating sites > (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of > IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing > prefix intended to minimize the risk of conflicts if sites merge or packets > are misrouted into the Internet. Despite the restricted, local usage of > these addresses, their address scope is global, i.e. they are expected to be > globally unique." > > I am trying to set up a local IPv6 network and am curious why all the > examples I come accross do not seem to use the 40-bit pseudorandom number? > What should I do? Use something like fd00::1234, or incorporate something > like the interface's MAC address into the address? It'd make the address > quite unreadable though. > > Thanks, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From jeroen at unfix.org Thu Oct 21 06:41:26 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 21 Oct 2010 13:41:26 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CBF4EDF.5070603@bogus.com> References: <4CBC3328.7090205@unfix.org> <4CBF482D.3030601@mompl.net> <4CBF4EDF.5070603@bogus.com> Message-ID: <4CC026E6.1000701@unfix.org> On 2010-10-20 22:19, Joel Jaeggli wrote: > On 10/20/10 12:51 PM, Jeroen van Aart wrote: >> Jeroen Massar wrote: >>> (And the spammers will take the rest...) >> >> I am afraid so too. >> >>> (PS: There seems to be a trend for people calling themselves"IPv6 >>> Pioneers" as they recently did something with IPv6, if you didn't play >>> in the 6bone/early-RIR allocs you are not a pioneer as you are 10 years >>> late) > > Oddly the nameserver in my closet seems to still have > /var/named/reverse/3.1.8.e.f.f.3.ip6.arpa in it's collection of zones. That must be a pretty new nameserver then you have there, seeing that first of all it all started out with ip6.int and 3ffe::/16 was the second interration of the 6bone, before that we actually used 5f00::/8 with, if I recall correctly, the 16 bit ASN going after the first 8 bits and then some reserved bits and the IPv4 /24 where the host was, some bits for the subnet and then finally 48bits for the MAC (not EUI-64) address. Thanks for Surfnet.nl for giving me a chunk out of that and hooking me up to the rest of the 6bone ;) And the e.f.f.3.ip6.arpa took a long time to materialize actually, thus it is a miracle that you have a zone file for that as it was only used for only a year or so. >> Who died and made you boss of "Pioneer Naming Authority"? > > If you remember it, you weren't there. (I don't see how one can forget a death when you are present at the location) Nevertheless, the internet is a global thing, thus 'there' is what we call Earth. The answer is much simpler, there is no boss, just a lot of people who are doing a lot of things for a long time already. But as you wonder who died in the process of IPv6 getting here while doing major contributions: Jun-ichiro "itojun" Itoh Hagino - the IPv6 Samurai Jim Bound - who did an amazing amount of work for IPv6 RIP guys... Greets, Jeroen From jeroen at unfix.org Thu Oct 21 06:47:13 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 21 Oct 2010 13:47:13 +0200 Subject: =?UTF-8?B?V2h5IFVMQTogbG93IGNvbGxpc2lvbiBjaGFuY2UgKFdhczogSVB2NiA=?= =?UTF-8?B?ZmMwMDo6Lzcg4oCUIFVuaXF1ZSBsb2NhbCBhZGRyZXNzZXMp?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: <4CC02841.3040407@unfix.org> On 2010-10-21 13:33, Ray Soucy wrote: [..] > People may throw a fit at this, but as far as I'm concerned FD00::/8 > will never leave the edge of our network (we null route ULA space > before it can leak out, just like you would with RFC1918 space). So > you can pretty much use it has you see fit. If you want to keep your > ULA space short there is nothing stopping you from using something > like FD00::1 as a valid address. And then your company gets bought and you need to merge networks, that is: renumber as they picked the same prefix. There is nothing wrong with RFC1918 per se, the big problem with it is that everybody else uses the same prefix, thus when you need to merge two networks you have collisions. I at one time also though that 'merging networks' and 'renumbering' is easy, till I heard stories from folks who where doing that for really large networks, who basically told that they where introducing 7+ layers of NAT to solve that issue, as renumbering is simply not doable if you have a global organization and if you are merging things like banks, for some magic reason they want to be able to talk to eachother. That is why there is ULA: low chance of collisions if one wants to stay in the RFC1918 mindset. And if you want a guarantee of no collisions: go to your favorite RIR and get a prefix from them. Greets, Jeroen From owen at delong.com Thu Oct 21 06:47:13 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 04:47:13 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: <9AC359C4-C168-45E2-ADC2-A340B85EEC54@delong.com> On Oct 21, 2010, at 4:33 AM, Ray Soucy wrote: > For for all intents and purposes if you're looking for RFC1918 style > space in IPv6 you should consider the block FD00::/8 not FC00::/7 as > the FC00::/8 space is reserved in ULA for assignment by a central > authority (who knows why, but with that much address space nobody > really cares). > > People may throw a fit at this, but as far as I'm concerned FD00::/8 > will never leave the edge of our network (we null route ULA space > before it can leak out, just like you would with RFC1918 space). So > you can pretty much use it has you see fit. If you want to keep your > ULA space short there is nothing stopping you from using something > like FD00::1 as a valid address. > I have no problem with that. My concern is that people will use FD00::/8 space in OTHER ways, and, since it has potential uniqueness if you follow the RFC, it has greater potential for undesired success than RFC-1918. > You could embed your ASN into it or some other identifier if you want > to avoid conflicts with other non-routed address space which should > never enter or leave your network from the outside, but I'm just not > seeing the practical application for this. > That only avoids conflicts if everyone within the networks to which you may communicate uses the same system of uniqueness. Think beyond today to the future possibility of M&A of other companies also using ULA, etc. Owen > On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart wrote: >> >> >> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an >> fc00::/7 address includes a 40-bit pseudo random number: >> >> "fc00::/7 ? Unique local addresses (ULA's) are intended for local >> communication. They are routable only within a set of cooperating sites >> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of >> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing >> prefix intended to minimize the risk of conflicts if sites merge or packets >> are misrouted into the Internet. Despite the restricted, local usage of >> these addresses, their address scope is global, i.e. they are expected to be >> globally unique." >> >> I am trying to set up a local IPv6 network and am curious why all the >> examples I come accross do not seem to use the 40-bit pseudorandom number? >> What should I do? Use something like fd00::1234, or incorporate something >> like the interface's MAC address into the address? It'd make the address >> quite unreadable though. >> >> Thanks, >> Jeroen >> >> -- >> http://goldmark.org/jeff/stupid-disclaimers/ >> http://linuxmafia.com/~rick/faq/plural-of-virus.html >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ From rps at maine.edu Thu Oct 21 06:59:37 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 07:59:37 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: Sorry for the double post. From re-reading the thread it doesn't sound like you might want ULA at all. The mindset of using RFC1918 space, throwing everything behind a NAT box, and not having to re-configure systems when you change ISP doesn't exist in IPv6. There is no IPv6 NAT (yet). If you wanted to setup an "island" of IPv6 that would never talk to the Internet, then you could use ULA, but that would only be needed if you plan on routing between LANs. Remember that by default every IPv6 host has a link-local address allowing it to talk to any directly connected hosts without configuration. So if you're simply looking for some sort of ad-hoc network, it's likely already there. As much as I hate NAT and want to see it go away. I think the biggest transition mechanism for people to get online with IPv6 will be some sort of appliance that does NAT of global IPv6 addresses to private IPv4 addresses to keep all the people living in the NAT world from having to redesign their networks. It's ugly, but its the path of least resistance and that's likely what will happen when we see IPv6 become required to do business... at least as a stepping stone. The idea to use multiple PA IPv6 allocations and have multiple GUAs for each host wasn't a bad one. It would certainly make the Internet routing table a lot more stable to not have everyone touching BGP... But they failed to fix DNS in a way that would make it possible. We already have priority for MX records. If we had priority for all records, and resolvers would remember when one was unreachable for a short time, then yes, you could have www.yourdomain.com point to multiple PA GUAs and if one was down users would nicely fail-over to the other. Unfortunately, if you have a host record with multiple AAAAs and one of them is unreachable, it will just mean that for some users the request will time out (as its just doing a round-robin and not trying others when things don't respond). In theory, you could try to get around the limitation by having a TTL of 30 seconds or something on your records, and have a system that would update DNS records when a connection dropped, but that's assuming people aren't deciding to set minimum cache times of their own. I think the best model possible with existing technology that's available is to separate L2 and L3 and use provider redundancy at L2 (multiple ME transport providers to your single, redundant, L3 transit provider). If you need more redundancy that that, you're likely using BGP for IPv4 already, anyway. The real problem never goes away, though. People like the operational control and simplicity that they get with NAT. If the provider goes down, they still work internally, if they have multiple providers, the internal network doesn't care which is active, and if they need to host services, they usually go with a hosting company off-site. I really don't think it will be long before we see some magic IPv6 NAT boxes start to pop up, whether or not standards exist for them, and it will be and ugly nightmare. IPv6 is simple enough for larger networks (like universities and governments) but very little attention has been giving to the SMB community and their needs with IPv6. On Thu, Oct 21, 2010 at 7:33 AM, Ray Soucy wrote: > For for all intents and purposes if you're looking for RFC1918 style > space in IPv6 you should consider the block FD00::/8 not FC00::/7 as > the FC00::/8 space is reserved in ULA for assignment by a central > authority (who knows why, but with that much address space nobody > really cares). > > People may throw a fit at this, but as far as I'm concerned FD00::/8 > will never leave the edge of our network (we null route ULA space > before it can leak out, just like you would with RFC1918 space). ?So > you can pretty much use it has you see fit. ?If you want to keep your > ULA space short there is nothing stopping you from using something > like FD00::1 as a valid address. > > You could embed your ASN into it or some other identifier if you want > to avoid conflicts with other non-routed address space which should > never enter or leave your network from the outside, but I'm just not > seeing the practical application for this. > > On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart wrote: >> >> >> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an >> fc00::/7 address includes a 40-bit pseudo random number: >> >> "fc00::/7 ? Unique local addresses (ULA's) are intended for local >> communication. They are routable only within a set of cooperating sites >> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of >> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing >> prefix intended to minimize the risk of conflicts if sites merge or packets >> are misrouted into the Internet. Despite the restricted, local usage of >> these addresses, their address scope is global, i.e. they are expected to be >> globally unique." >> >> I am trying to set up a local IPv6 network and am curious why all the >> examples I come accross do not seem to use the 40-bit pseudorandom number? >> What should I do? Use something like fd00::1234, or incorporate something >> like the interface's MAC address into the address? It'd make the address >> quite unreadable though. >> >> Thanks, >> Jeroen >> >> -- >> http://goldmark.org/jeff/stupid-disclaimers/ >> http://linuxmafia.com/~rick/faq/plural-of-virus.html >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From lists at quux.de Thu Oct 21 06:59:05 2010 From: lists at quux.de (Jens Link) Date: Thu, 21 Oct 2010 13:59:05 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: (Owen DeLong's message of "Thu, 21 Oct 2010 01:28:14 -0700") References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> Message-ID: <87ocanbvue.fsf@oban.berlin.quux.de> Owen DeLong writes: > All well and good until some of their customers are on IPv6... > Then what? Someone will build an appliance to deal with this problem. ;-) Jens -- ------------------------------------------------------------------------- | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 | | http://blog.quux.de | jabber: jenslink at guug.de | ------------------- | ------------------------------------------------------------------------- From owen at delong.com Thu Oct 21 07:12:16 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 05:12:16 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <87ocanbvue.fsf@oban.berlin.quux.de> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <87ocanbvue.fsf@oban.berlin.quux.de> Message-ID: <3D61CC68-0D37-4C59-BC37-93069EDBDFA3@delong.com> On Oct 21, 2010, at 4:59 AM, Jens Link wrote: > Owen DeLong writes: > >> All well and good until some of their customers are on IPv6... >> Then what? > > Someone will build an appliance to deal with this problem. ;-) > And I estimate that the user experience through such appliances will be poor or worse, driving their former customers to their competitors that implemented native IPv6. Owen From rps at maine.edu Thu Oct 21 07:14:57 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 08:14:57 -0400 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance_=28Was=3A_IPv6_fc00=3A=3A=2F?= =?windows-1252?Q?7_=97_Unique_local_addresses=29?= In-Reply-To: <4CC02841.3040407@unfix.org> References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> Message-ID: That's assuming ULA would be the primary addressing scheme used. If that became the norm, I agree, the extra uniqueness would be desirable, perhaps to the point that you should be asking an authority for FC00::/8 space to be assigned. But then why wouldn't you just ask for a GUA at that point. You could still randomly get "0", and if you don't think people will keep cycling through random numbers until they get something pretty you're underestimating human will to control everything ;-) I see ULA falling into the role of things like embedded device management and sandbox networks, more than production, but who knows what will become "the way" to engineer the IPv6 network of the next decade. We've only applied ULA to things like web-based network registration and device management for devices that should never be accessed from off the network (but even there, we've been more in the mindset of using GUA with ACLs or null routes, etc to restrict access). It's really more of a utility address IMHO. On Thu, Oct 21, 2010 at 7:47 AM, Jeroen Massar wrote: > On 2010-10-21 13:33, Ray Soucy wrote: > [..] >> People may throw a fit at this, but as far as I'm concerned FD00::/8 >> will never leave the edge of our network (we null route ULA space >> before it can leak out, just like you would with RFC1918 space). ?So >> you can pretty much use it has you see fit. ?If you want to keep your >> ULA space short there is nothing stopping you from using something >> like FD00::1 as a valid address. > > And then your company gets bought and you need to merge networks, that > is: renumber as they picked the same prefix. > > There is nothing wrong with RFC1918 per se, the big problem with it is > that everybody else uses the same prefix, thus when you need to merge > two networks you have collisions. > > I at one time also though that 'merging networks' and 'renumbering' is > easy, till I heard stories from folks who where doing that for really > large networks, who basically told that they where introducing 7+ layers > of NAT to solve that issue, as renumbering is simply not doable if you > have a global organization and if you are merging things like banks, for > some magic reason they want to be able to talk to eachother. > > That is why there is ULA: > ?low chance of collisions if one wants to stay in the RFC1918 mindset. > > And if you want a guarantee of no collisions: > ?go to your favorite RIR and get a prefix from them. > > Greets, > ?Jeroen > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Thu Oct 21 07:21:54 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 08:21:54 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <9AC359C4-C168-45E2-ADC2-A340B85EEC54@delong.com> References: <4CBF63BF.2000101@mompl.net> <9AC359C4-C168-45E2-ADC2-A340B85EEC54@delong.com> Message-ID: I guess my point is that as soon as you introduced the human element into ULA with no accountability, it became a lost cause. People can't be trusted to respect the RFC once they know it's non-routed address space, and I suspect most won't. Just like countless vendors still use 1.1.1.1 as a baked-in management address even though there was never a time when that was allowed. It was a nice idea, but as soon as you let people "choose" the "random" number, well... there you go. At least if you stay within the FD space we have a chance at using FC correctly. On Thu, Oct 21, 2010 at 7:47 AM, Owen DeLong wrote: > > On Oct 21, 2010, at 4:33 AM, Ray Soucy wrote: > >> For for all intents and purposes if you're looking for RFC1918 style >> space in IPv6 you should consider the block FD00::/8 not FC00::/7 as >> the FC00::/8 space is reserved in ULA for assignment by a central >> authority (who knows why, but with that much address space nobody >> really cares). >> >> People may throw a fit at this, but as far as I'm concerned FD00::/8 >> will never leave the edge of our network (we null route ULA space >> before it can leak out, just like you would with RFC1918 space). ?So >> you can pretty much use it has you see fit. ?If you want to keep your >> ULA space short there is nothing stopping you from using something >> like FD00::1 as a valid address. >> > I have no problem with that. My concern is that people will use FD00::/8 > space in OTHER ways, and, since it has potential uniqueness if you > follow the RFC, it has greater potential for undesired success than > RFC-1918. > >> You could embed your ASN into it or some other identifier if you want >> to avoid conflicts with other non-routed address space which should >> never enter or leave your network from the outside, but I'm just not >> seeing the practical application for this. >> > That only avoids conflicts if everyone within the networks to which > you may communicate uses the same system of uniqueness. > Think beyond today to the future possibility of M&A of other companies > also using ULA, etc. > > Owen > >> On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart wrote: >>> >>> >>> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an >>> fc00::/7 address includes a 40-bit pseudo random number: >>> >>> "fc00::/7 ? Unique local addresses (ULA's) are intended for local >>> communication. They are routable only within a set of cooperating sites >>> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of >>> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing >>> prefix intended to minimize the risk of conflicts if sites merge or packets >>> are misrouted into the Internet. Despite the restricted, local usage of >>> these addresses, their address scope is global, i.e. they are expected to be >>> globally unique." >>> >>> I am trying to set up a local IPv6 network and am curious why all the >>> examples I come accross do not seem to use the 40-bit pseudorandom number? >>> What should I do? Use something like fd00::1234, or incorporate something >>> like the interface's MAC address into the address? It'd make the address >>> quite unreadable though. >>> >>> Thanks, >>> Jeroen >>> >>> -- >>> http://goldmark.org/jeff/stupid-disclaimers/ >>> http://linuxmafia.com/~rick/faq/plural-of-virus.html >>> >>> >> >> >> >> -- >> Ray Soucy >> >> Epic Communications Specialist >> >> Phone: +1 (207) 561-3526 >> >> Networkmaine, a Unit of the University of Maine System >> http://www.networkmaine.net/ > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Thu Oct 21 07:26:13 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 05:26:13 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: On Oct 21, 2010, at 4:59 AM, Ray Soucy wrote: > Sorry for the double post. From re-reading the thread it doesn't > sound like you might want ULA at all. > > The mindset of using RFC1918 space, throwing everything behind a NAT > box, and not having to re-configure systems when you change ISP > doesn't exist in IPv6. There is no IPv6 NAT (yet). > And hopefully there never will be... > If you wanted to setup an "island" of IPv6 that would never talk to > the Internet, then you could use ULA, but that would only be needed if > you plan on routing between LANs. Remember that by default every IPv6 > host has a link-local address allowing it to talk to any directly > connected hosts without configuration. So if you're simply looking > for some sort of ad-hoc network, it's likely already there. > You may want non-LL space even if you aren't routing, since for LL, the destination address has to include the outbound interface name or it doesn't work. > As much as I hate NAT and want to see it go away. I think the biggest > transition mechanism for people to get online with IPv6 will be some > sort of appliance that does NAT of global IPv6 addresses to private > IPv4 addresses to keep all the people living in the NAT world from > having to redesign their networks. It's ugly, but its the path of > least resistance and that's likely what will happen when we see IPv6 > become required to do business... at least as a stepping stone. > NAT64 already exists, although generally not for that application. I'm not convinced it is the path of least resistance, technically. If you mean politically, then, yes, but, making engineering decisions based on the political path of least resistance tends to cause more damage than it resolves. You don't actually have to redesign your IPv4 NAT network to put IPv6 on it in parallel. You just need to recognize that the IPv6 stateful firewall now provides your IPv6 security without needing to mangle the packet header in the process. You should be able to put all the same exact policies in place, without the nasty address translation bits. > The idea to use multiple PA IPv6 allocations and have multiple GUAs > for each host wasn't a bad one. It would certainly make the Internet If it worked, it would be a great one, but... > routing table a lot more stable to not have everyone touching BGP... > But they failed to fix DNS in a way that would make it possible. We Not just DNS... It would have impacted TCP, to some extent, UDP, applications, etc. > already have priority for MX records. If we had priority for all > records, and resolvers would remember when one was unreachable for a > short time, then yes, you could have www.yourdomain.com point to The resolver doesn't have any way to know the reachability status of a given address from the resolver client. The information simply isn't available to the resolver. I suppose you could design a mechanism for the client to send feedback to the resolver, but, that's pretty hokey. > multiple PA GUAs and if one was down users would nicely fail-over to > the other. Unfortunately, if you have a host record with multiple > AAAAs and one of them is unreachable, it will just mean that for some > users the request will time out (as its just doing a round-robin and > not trying others when things don't respond). > Actually, unless the client software is exceptionally poorly written, it won't time out, but, the delay before trying the next host is exceedingly long (30 seconds) if you don't get an unreachable message back about the first attempt(s). > In theory, you could try to get around the limitation by having a TTL > of 30 seconds or something on your records, and have a system that > would update DNS records when a connection dropped, but that's > assuming people aren't deciding to set minimum cache times of their > own. > We already know that M$ absolutely breaks this across the board. > I think the best model possible with existing technology that's > available is to separate L2 and L3 and use provider redundancy at L2 > (multiple ME transport providers to your single, redundant, L3 transit > provider). If you need more redundancy that that, you're likely using > BGP for IPv4 already, anyway. > You can get exactly the same reliability from IPv6 as you have in IPv4 using pretty much exactly the same tactics. If you're using IPv4 with multiple providers giving you different NAT pools, then, you're looking at outbound, not inbound resiliency and the DNS stuff you described is irrelevant. As long as your outbound gateway(s) have some way to detect provider down-ness (all the same tactics that work for IPv4 here work for IPv6 with pretty much the same flaws), you can do the same thing. The difference is that in IPv6, you have to tell the hosts which IPv6 source prefix to use. The easy way to do that is to alter the desired/valid lifetimes in your internal RAs accordingly. This isn't hard to script. If you're using IPv4 with BGP and advertising the same prefix(es) to multiple providers, the same thing works in IPv6 with nearly identical processes. If you've got meaningful in-bound resiliency in IPv4, then, you're using IPv4 with BGP and advertising the same prefix(es) to multiple providers anyway. If you're doing something else in IPv4, then, you're pretending to have resiliency and it will work just as poorly in IPv6, most likely. > The real problem never goes away, though. People like the operational > control and simplicity that they get with NAT. If the provider goes Huh? I don't see what NAT gives you for EITHER of those things. > down, they still work internally, if they have multiple providers, the There's no reason that can't be true with IPv6. NOTHING says your IPv6 prefix use internally has to be affected by your provider going down. > internal network doesn't care which is active, and if they need to > host services, they usually go with a hosting company off-site. I This is achievable in IPv6, too. If you have multiple providers, that's sufficient justification to obtain an IPv6 prefix from most RIRs. Once you do that, your internal network doesn't care which provider is active. > really don't think it will be long before we see some magic IPv6 NAT > boxes start to pop up, whether or not standards exist for them, and it > will be and ugly nightmare. > I really really really hope you are wrong about that. > IPv6 is simple enough for larger networks (like universities and > governments) but very little attention has been giving to the SMB > community and their needs with IPv6. > I disagree... Please let me know where you think IPv6 falls short for SMB and I will be happy to show you feasible solutions. Owen 2620:0:930::/48 ARIN direct assignment, multihomed through (relatively) cheap connectivity at my house. > On Thu, Oct 21, 2010 at 7:33 AM, Ray Soucy wrote: >> For for all intents and purposes if you're looking for RFC1918 style >> space in IPv6 you should consider the block FD00::/8 not FC00::/7 as >> the FC00::/8 space is reserved in ULA for assignment by a central >> authority (who knows why, but with that much address space nobody >> really cares). >> >> People may throw a fit at this, but as far as I'm concerned FD00::/8 >> will never leave the edge of our network (we null route ULA space >> before it can leak out, just like you would with RFC1918 space). So >> you can pretty much use it has you see fit. If you want to keep your >> ULA space short there is nothing stopping you from using something >> like FD00::1 as a valid address. >> >> You could embed your ASN into it or some other identifier if you want >> to avoid conflicts with other non-routed address space which should >> never enter or leave your network from the outside, but I'm just not >> seeing the practical application for this. >> >> On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart wrote: >>> >>> >>> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an >>> fc00::/7 address includes a 40-bit pseudo random number: >>> >>> "fc00::/7 ? Unique local addresses (ULA's) are intended for local >>> communication. They are routable only within a set of cooperating sites >>> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of >>> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing >>> prefix intended to minimize the risk of conflicts if sites merge or packets >>> are misrouted into the Internet. Despite the restricted, local usage of >>> these addresses, their address scope is global, i.e. they are expected to be >>> globally unique." >>> >>> I am trying to set up a local IPv6 network and am curious why all the >>> examples I come accross do not seem to use the 40-bit pseudorandom number? >>> What should I do? Use something like fd00::1234, or incorporate something >>> like the interface's MAC address into the address? It'd make the address >>> quite unreadable though. >>> >>> Thanks, >>> Jeroen >>> >>> -- >>> http://goldmark.org/jeff/stupid-disclaimers/ >>> http://linuxmafia.com/~rick/faq/plural-of-virus.html >>> >>> >> >> >> >> -- >> Ray Soucy >> >> Epic Communications Specialist >> >> Phone: +1 (207) 561-3526 >> >> Networkmaine, a Unit of the University of Maine System >> http://www.networkmaine.net/ >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ From rps at maine.edu Thu Oct 21 07:49:26 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 08:49:26 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: See... You're falling into the same elitist mindset that I was trapped in a year ago. Perception is a powerful thing. And Joe IT guy at Mom and Pop dot com (who's network experience involves setting up a Linksys at home) loves his magical NAT box firewall appliance. Over the last year I've been trying to fight the NAT war and have gotten pretty beat down. It doesn't matter if *we* know NAT is wrong, undesirable, and breaks the Internet... we all live in the large scale, multi-homed, BGP, mega Internet land. Start working with smaller shops, and you'll find the typical setup is a bunch of switches and a "VPN Firewall" picked up from Best Buy, or maybe a Sonicwall or something. These guys couldn't manage public IPv4 let alone public IPv6, because the term "private" gives them that warm and fuzzy false sense of security and lets them change their ISP without reconfiguring a single thing (they often wouldn't know where to start anyway). They *will* fight you, and tell you to your face that if you want to take NAT away from them it will be from their cold dead hands. Why? Because we've had 10 years of "consultants" selling NAT as the best thing for security since sliced bread. Maybe we could get them to do it the right way if they had some sort of IPv6 appliance that dumbed things down, but it simply doesn't exist yet. When it is created, it will be created by the people with the NAT mindset wishing to maintain the status quo. At least that's my prediction... We need to keep in mind that most on this list is likely at a completely different level than anything you'd find in the SMB community. They can't afford to hire "networking" people, they hire "IT" people who are tasked with anything related to technology and usually completely understaffed. Thus they want the quick, painless, easy solution. On Thu, Oct 21, 2010 at 8:26 AM, Owen DeLong wrote: > > On Oct 21, 2010, at 4:59 AM, Ray Soucy wrote: > >> Sorry for the double post. ?From re-reading the thread it doesn't >> sound like you might want ULA at all. >> >> The mindset of using RFC1918 space, throwing everything behind a NAT >> box, and not having to re-configure systems when you change ISP >> doesn't exist in IPv6. ?There is no IPv6 NAT (yet). >> > And hopefully there never will be... > >> If you wanted to setup an "island" of IPv6 that would never talk to >> the Internet, then you could use ULA, but that would only be needed if >> you plan on routing between LANs. ?Remember that by default every IPv6 >> host has a link-local address allowing it to talk to any directly >> connected hosts without configuration. ?So if you're simply looking >> for some sort of ad-hoc network, it's likely already there. >> > You may want non-LL space even if you aren't routing, since for LL, > the destination address has to include the outbound interface name > or it doesn't work. > >> As much as I hate NAT and want to see it go away. ?I think the biggest >> transition mechanism for people to get online with IPv6 will be some >> sort of appliance that does NAT of global IPv6 addresses to private >> IPv4 addresses to keep all the people living in the NAT world from >> having to redesign their networks. ?It's ugly, but its the path of >> least resistance and that's likely what will happen when we see IPv6 >> become required to do business... at least as a stepping stone. >> > NAT64 already exists, although generally not for that application. > > I'm not convinced it is the path of least resistance, technically. If > you mean politically, then, yes, but, making engineering decisions > based on the political path of least resistance tends to cause more > damage than it resolves. > > You don't actually have to redesign your IPv4 NAT network to > put IPv6 on it in parallel. You just need to recognize that the > IPv6 stateful firewall now provides your IPv6 security without > needing to mangle the packet header in the process. You should > be able to put all the same exact policies in place, without the > nasty address translation bits. > >> The idea to use multiple PA IPv6 allocations and have multiple GUAs >> for each host wasn't a bad one. ?It would certainly make the Internet > > If it worked, it would be a great one, but... > >> routing table a lot more stable to not have everyone touching BGP... >> But they failed to fix DNS in a way that would make it possible. ?We > > Not just DNS... It would have impacted TCP, to some extent, UDP, > applications, etc. > >> already have priority for MX records. ?If we had priority for all >> records, and resolvers would remember when one was unreachable for a >> short time, then yes, you could have www.yourdomain.com point to > > The resolver doesn't have any way to know the reachability status of > a given address from the resolver client. The information simply isn't > available to the resolver. I suppose you could design a mechanism for > the client to send feedback to the resolver, but, that's pretty hokey. > >> multiple PA GUAs and if one was down users would nicely fail-over to >> the other. ?Unfortunately, if you have a host record with multiple >> AAAAs and one of them is unreachable, it will just mean that for some >> users the request will time out (as its just doing a round-robin and >> not trying others when things don't respond). >> > Actually, unless the client software is exceptionally poorly written, it > won't time out, but, the delay before trying the next host is exceedingly > long (30 seconds) if you don't get an unreachable message back about > the first attempt(s). > >> In theory, you could try to get around the limitation by having a TTL >> of 30 seconds or something on your records, and have a system that >> would update DNS records when a connection dropped, but that's >> assuming people aren't deciding to set minimum cache times of their >> own. >> > We already know that M$ absolutely breaks this across the board. > >> I think the best model possible with existing technology that's >> available is to separate L2 and L3 and use provider redundancy at L2 >> (multiple ME transport providers to your single, redundant, L3 transit >> provider). ?If you need more redundancy that that, you're likely using >> BGP for IPv4 already, anyway. >> > You can get exactly the same reliability from IPv6 as you have in IPv4 > using pretty much exactly the same tactics. > > If you're using IPv4 with multiple providers giving you different NAT > pools, then, you're looking at outbound, not inbound resiliency and > the DNS stuff you described is irrelevant. As long as your outbound > gateway(s) have some way to detect provider down-ness (all the > same tactics that work for IPv4 here work for IPv6 with pretty much > the same flaws), you can do the same thing. The difference is that > in IPv6, you have to tell the hosts which IPv6 source prefix to use. > The easy way to do that is to alter the desired/valid lifetimes in > your internal RAs accordingly. This isn't hard to script. > > If you're using IPv4 with BGP and advertising the same prefix(es) > to multiple providers, the same thing works in IPv6 with nearly > identical processes. > > If you've got meaningful in-bound resiliency in IPv4, then, you're > using IPv4 with BGP and advertising the same prefix(es) to > multiple providers anyway. If you're doing something else in IPv4, > then, you're pretending to have resiliency and it will work just > as poorly in IPv6, most likely. > >> The real problem never goes away, though. ?People like the operational >> control and simplicity that they get with NAT. ?If the provider goes > > Huh? > > I don't see what NAT gives you for EITHER of those things. > >> down, they still work internally, if they have multiple providers, the > > There's no reason that can't be true with IPv6. NOTHING says > your IPv6 prefix use internally has to be affected by your provider > going down. > >> internal network doesn't care which is active, and if they need to >> host services, they usually go with a hosting company off-site. ?I > > This is achievable in IPv6, too. If you have multiple providers, that's > sufficient justification to obtain an IPv6 prefix from most RIRs. Once > you do that, your internal network doesn't care which provider is active. > >> really don't think it will be long before we see some magic IPv6 NAT >> boxes start to pop up, whether or not standards exist for them, and it >> will be and ugly nightmare. >> > I really really really hope you are wrong about that. > >> IPv6 is simple enough for larger networks (like universities and >> governments) but very little attention has been giving to the SMB >> community and their needs with IPv6. >> > I disagree... Please let me know where you think IPv6 falls short for > SMB and I will be happy to show you feasible solutions. > > Owen > 2620:0:930::/48 ARIN direct assignment, multihomed through (relatively) > ? ? ? ?cheap connectivity at my house. > >> On Thu, Oct 21, 2010 at 7:33 AM, Ray Soucy wrote: >>> For for all intents and purposes if you're looking for RFC1918 style >>> space in IPv6 you should consider the block FD00::/8 not FC00::/7 as >>> the FC00::/8 space is reserved in ULA for assignment by a central >>> authority (who knows why, but with that much address space nobody >>> really cares). >>> >>> People may throw a fit at this, but as far as I'm concerned FD00::/8 >>> will never leave the edge of our network (we null route ULA space >>> before it can leak out, just like you would with RFC1918 space). ?So >>> you can pretty much use it has you see fit. ?If you want to keep your >>> ULA space short there is nothing stopping you from using something >>> like FD00::1 as a valid address. >>> >>> You could embed your ASN into it or some other identifier if you want >>> to avoid conflicts with other non-routed address space which should >>> never enter or leave your network from the outside, but I'm just not >>> seeing the practical application for this. >>> >>> On Wed, Oct 20, 2010 at 5:48 PM, Jeroen van Aart wrote: >>>> >>>> >>>> According to http://en.wikipedia.org/wiki/IPv6_address#Special_addresses an >>>> fc00::/7 address includes a 40-bit pseudo random number: >>>> >>>> "fc00::/7 ? Unique local addresses (ULA's) are intended for local >>>> communication. They are routable only within a set of cooperating sites >>>> (analogous to the private address ranges 10/8, 172.16/12, and 192.168/16 of >>>> IPv4).[12] The addresses include a 40-bit pseudorandom number in the routing >>>> prefix intended to minimize the risk of conflicts if sites merge or packets >>>> are misrouted into the Internet. Despite the restricted, local usage of >>>> these addresses, their address scope is global, i.e. they are expected to be >>>> globally unique." >>>> >>>> I am trying to set up a local IPv6 network and am curious why all the >>>> examples I come accross do not seem to use the 40-bit pseudorandom number? >>>> What should I do? Use something like fd00::1234, or incorporate something >>>> like the interface's MAC address into the address? It'd make the address >>>> quite unreadable though. >>>> >>>> Thanks, >>>> Jeroen >>>> >>>> -- >>>> http://goldmark.org/jeff/stupid-disclaimers/ >>>> http://linuxmafia.com/~rick/faq/plural-of-virus.html >>>> >>>> >>> >>> >>> >>> -- >>> Ray Soucy >>> >>> Epic Communications Specialist >>> >>> Phone: +1 (207) 561-3526 >>> >>> Networkmaine, a Unit of the University of Maine System >>> http://www.networkmaine.net/ >>> >> >> >> >> -- >> Ray Soucy >> >> Epic Communications Specialist >> >> Phone: +1 (207) 561-3526 >> >> Networkmaine, a Unit of the University of Maine System >> http://www.networkmaine.net/ > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From bill at herrin.us Thu Oct 21 08:02:53 2010 From: bill at herrin.us (William Herrin) Date: Thu, 21 Oct 2010 09:02:53 -0400 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance_=28Was=3A_IPv6_fc00=3A=3A=2F?= =?windows-1252?Q?7_=97_Unique_local_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> Message-ID: On Thu, Oct 21, 2010 at 8:14 AM, Ray Soucy wrote: > That's assuming ULA would be the primary addressing scheme used. ?If > that became the norm, I agree, the extra uniqueness would be > desirable, perhaps to the point that you should be asking an authority > for FC00::/8 space to be assigned. ?But then why wouldn't you just ask > for a GUA at that point. Because you might want space that doesn't route on the Internet so that if your routes accidentally leak external folks still can't reach you? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From patrick at zill.net Thu Oct 21 09:59:08 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Thu, 21 Oct 2010 10:59:08 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> Message-ID: <4CC0553C.8060202@zill.net> On 10/21/2010 4:28 AM, Owen DeLong wrote: >> Actually for those of my clients in one location, it served as an >> impetus to extend a contract with Level3 for another 3 years - with >> their existing allocation of a /24 of IPv4 addresses included. > > All well and good until some of their customers are on IPv6... > Then what? I'm sorry, can you expand on exactly what you mean by this? Are IPv6 connected machines unable to access IPv4 addresses? Or is this more IPV6 fanboi-ism? --Patrick From ben.butler at c2internet.net Thu Oct 21 10:07:26 2010 From: ben.butler at c2internet.net (Ben Butler) Date: Thu, 21 Oct 2010 16:07:26 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC0553C.8060202@zill.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> Message-ID: Hi, Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only. I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two. Or are the two simply not inter-communicable? Ben -----Original Message----- From: Patrick Giagnocavo [mailto:patrick at zill.net] Sent: 21 October 2010 15:59 To: Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA On 10/21/2010 4:28 AM, Owen DeLong wrote: >> Actually for those of my clients in one location, it served as an >> impetus to extend a contract with Level3 for another 3 years - with >> their existing allocation of a /24 of IPv4 addresses included. > > All well and good until some of their customers are on IPv6... > Then what? I'm sorry, can you expand on exactly what you mean by this? Are IPv6 connected machines unable to access IPv4 addresses? Or is this more IPV6 fanboi-ism? --Patrick -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. From jeroen at unfix.org Thu Oct 21 10:08:10 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 21 Oct 2010 17:08:10 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC0553C.8060202@zill.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> Message-ID: <4CC0575A.4030305@unfix.org> On 2010-10-21 16:59, Patrick Giagnocavo wrote: > On 10/21/2010 4:28 AM, Owen DeLong wrote: > >>> Actually for those of my clients in one location, it served as an >>> impetus to extend a contract with Level3 for another 3 years - with >>> their existing allocation of a /24 of IPv4 addresses included. >> >> All well and good until some of their customers are on IPv6... >> Then what? > > I'm sorry, can you expand on exactly what you mean by this? > > Are IPv6 connected machines unable to access IPv4 addresses? Unless you put a application/protocol translation in the middle IPv6 can't talk to IPv4. yahoo("IVI","Ecdysis NAT64") for two possibilities one have for that, oh and yahoo("IPv6Gate") for a ready-to-use HTTP specific one. But if you didn't know that fact, you might want to invest in a proper book about IPv6 and read up quite a bit. As this is NANOG, a good operational book is "Running IPv6". Greets, Jeroen From patrick at zill.net Thu Oct 21 10:26:55 2010 From: patrick at zill.net (Patrick Giagnocavo) Date: Thu, 21 Oct 2010 11:26:55 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC0575A.4030305@unfix.org> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <4CC0575A.4030305@unfix.org> Message-ID: <4CC05BBF.1010009@zill.net> On 10/21/2010 11:08 AM, Jeroen Massar wrote: >> On 2010-10-21 16:59, Patrick Giagnocavo wrote: >> Are IPv6 connected machines unable to access IPv4 addresses? > > Unless you put a application/protocol translation in the middle IPv6 > can't talk to IPv4. yahoo("IVI","Ecdysis NAT64") for two possibilities > one have for that, oh and yahoo("IPv6Gate") for a ready-to-use HTTP > specific one. > > But if you didn't know that fact, you might want to invest in a proper > book about IPv6 and read up quite a bit. As this is NANOG, a good > operational book is "Running IPv6". > Thank you for the book recommendation; however, I was trying to get an admission that any IPv6-connected end users or corporate connections, will be accessing IPv4-only resources for a long time to come, i.e. years and years. And that the responsibility for IPv6 to v4 connection won't have to be handled by my client with a few racks. Cordially Patrick From dwhite at olp.net Thu Oct 21 10:30:12 2010 From: dwhite at olp.net (Dan White) Date: Thu, 21 Oct 2010 10:30:12 -0500 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> Message-ID: <20101021153012.GE2843@dan.olp.net> On 21/10/10?16:07?+0100, Ben Butler wrote: >Hi, > >Showing my ignorance here, but this is one of the things I have wondered, >given that we run both v4 and v6 for a period of time on the Internet, >presumably at one time or another a particular resource may only be able >in v4 land, then v4 and v6, then finally v6 only. > >I have never been particularly clear how an end network that exists only >in v4 or v6 address space is able to access a resource that only exists in >the other. Is can sort of see some freaking huge NAT box type thing that >summarizes v6 in a v4 address scope or contains the v4 address range at >some point inside the v6 address space - but how can a v4 host get to a >hot in v6 world that sits outside this without going through some form of >proxy / nat gateway between the two. > >Or are the two simply not inter-communicable? I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up? From an accounting and cost recovery stand point, that probably makes sense in some environments. However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only. That date is starting to become a bit more predictable too. Those v6 only sites won't be Google or Yahoo, but they will be entrepreneurs with good ideas and new services that your customers will be asking to get access to. We're pursuing a dual stacking model today because we anticipate that the dual-stacking process itself will take a while to deploy, and we want to anticipate customer demand for access to v6 only sites. We could hold off on that deployment, and then spend money on work at the moment of truth, but that approach is not very appealing to us. -- Dan White From stephen at sprunk.org Thu Oct 21 10:53:35 2010 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 21 Oct 2010 10:53:35 -0500 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> Message-ID: <4CC061FF.70802@sprunk.org> On 21 Oct 2010 10:07, Ben Butler wrote: > Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only. That's what NAT-PT is for. Oh wait, the IETF deprecated it... S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3646 bytes Desc: S/MIME Cryptographic Signature URL: From matthew at matthew.at Thu Oct 21 11:06:22 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Thu, 21 Oct 2010 09:06:22 -0700 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> <4CBF9B7A.1000500@matthew.at> Message-ID: <4CC064FE.8020101@matthew.at> On 10/21/2010 12:57 AM, Owen DeLong wrote: > On Oct 20, 2010, at 6:46 PM, Matthew Kaufman wrote: > >> On 10/20/2010 6:20 PM, Mark Smith wrote: >>> To make it clear, as it seems to be quite misunderstood, you'd have >>> both ULA and global addressing in your network. >> Right. Just like to multihome with IPv6 you would have both PA addresses from provider #1 and PA addresses from provider #2 in your network. >> > Or PI addresses from an RIR. One set of PI addresses and BGP multihoming shouldn't be necessary (but is). The remaining parts of the protocol stack should (but don't) work just fine if you have two sets of PA addresses. They also should (but don't) work just fine if you have one GUA and one ULA, for many of the same reasons. (There are subtle differences that make this case slightly better in some ways, slightly worse in others) >> Only nobody wants to do that either. >> > There are lots of good reasons not to want to do that. Agreed. That was my point here, and above. Matthew Kaufman From lazlor at lotaris.org Thu Oct 21 11:29:40 2010 From: lazlor at lotaris.org (Allen Smith) Date: Thu, 21 Oct 2010 10:29:40 -0600 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: Hi All, I've inherited a small network with a couple of Internet connections through different providers, I'll call them Slow and Fast. We use RFC 1918 space internally and have a pair of external firewalls that handle NAT and such. Due to internal policy (read money), some users default to the Slow connection and some default to Fast. Using probes and policy routing, a failure of one of the ISPs is generally transparent, outside of the usual session resets for things like ssh or remote control sessions). Looking forward to the next 12 months, we may have clients that are living in IPv6 space. Our ISPs are happy to give us IPv6 allocations and our network gear vendors either have GA IPv6 code now or will soon. We have been somewhat spoiled by our firewall/NAT boxes, the stuff just works for our needs and the combination of NAT and policy routing keeps people on the circuits they are paying for. Am trying to decide how I would implement this kind of policy in the new world of globally trackable^H^H^H^H^H^H^H routable IPs for my desktops. Solutions seem to be: 1) Purchase some BGP capable routers, grab PI space. Here I can obv choose outbound path, but we are typical in that our inbound to outbound is 6 or 7 to 1. 2) Assign PA space from the ISPs to the appropriate devices. What do I do when I loose a provider? 3) Make loud noises to my firewall vendor to include equivalent NAT/ISP failover functionality (even 6to6 NAT would be fine). Anyway, another sample of 1, but I do work for a managed services provider and see many small orgs facing similary choices. I personally am happy to use globally routable addresses and will work through the privacy and perceived security implications of NAT/nonat, I just want the same ease of use and flexibility I have today in a SMB environment. Cheers, -Allen From ben.butler at c2internet.net Thu Oct 21 11:34:25 2010 From: ben.butler at c2internet.net (Ben Butler) Date: Thu, 21 Oct 2010 17:34:25 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101021153012.GE2843@dan.olp.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> Message-ID: Hi, I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations. The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years. You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river. My 2c. Ben -----Original Message----- From: Dan White [mailto:dwhite at olp.net] Sent: 21 October 2010 16:30 To: Ben Butler Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA On 21/10/10 16:07 +0100, Ben Butler wrote: >Hi, > >Showing my ignorance here, but this is one of the things I have wondered, >given that we run both v4 and v6 for a period of time on the Internet, >presumably at one time or another a particular resource may only be able >in v4 land, then v4 and v6, then finally v6 only. > >I have never been particularly clear how an end network that exists only >in v4 or v6 address space is able to access a resource that only exists in >the other. Is can sort of see some freaking huge NAT box type thing that >summarizes v6 in a v4 address scope or contains the v4 address range at >some point inside the v6 address space - but how can a v4 host get to a >hot in v6 world that sits outside this without going through some form of >proxy / nat gateway between the two. > >Or are the two simply not inter-communicable? I think that's the $64K question. Do you wait to roll out v6 until you start seeing v6-only hosts start popping up? From an accounting and cost recovery stand point, that probably makes sense in some environments. However, consider the fact that there will be v6 only hosts popping up after IANA/RIR/ISP exhaustion. There will be new entrants in the public internet space that cannot obtain v4 addresses and will be reachable via v6 only. That date is starting to become a bit more predictable too. Those v6 only sites won't be Google or Yahoo, but they will be entrepreneurs with good ideas and new services that your customers will be asking to get access to. We're pursuing a dual stacking model today because we anticipate that the dual-stacking process itself will take a while to deploy, and we want to anticipate customer demand for access to v6 only sites. We could hold off on that deployment, and then spend money on work at the moment of truth, but that approach is not very appealing to us. -- Dan White -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. From bross at pobox.com Thu Oct 21 11:34:41 2010 From: bross at pobox.com (Brandon Ross) Date: Thu, 21 Oct 2010 12:34:41 -0400 (EDT) Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: <4CBFC3C9.706@apolix.co.za> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> <4CBFC3C9.706@apolix.co.za> Message-ID: On Thu, 21 Oct 2010, Graham Beneke wrote: > On 21/10/2010 03:49, Matthew Kaufman wrote: >> On 10/20/2010 5:51 PM, Owen DeLong wrote: >>> >>> Part 2 will be when the first provider accepts a large sum of money to >>> route it within their public network between multiple sites owned by >>> the same customer. >> >> Is this happening now with RFC 1918 addresses and IPv4? > > I have seen this in some small providers. Doesn't last long since the chance > of collision is high. It then becomes a VPN. I know for a fact that an extremely large tier 1 routed RFC1918 address space for an extremely large cable company at one time (and no, I don't mean 2547 or anything like that). I have no idea if this is still occurring, but when this very large cable company needed to use more private addresses they actually would ask the tier 1 for an assignment in order to avoid collision. I don't see the problem with ULA though, sure, someone will route it, but not everyone, just those getting paid to. It's actually the perfect solution to routing table bloat as there is a financial relationship between the parties that announce space and the networks that carry it. -- Brandon Ross AIM: BrandonNRoss ICQ: 2269442 Skype: brandonross Yahoo: BrandonNRoss From jeroen at unfix.org Thu Oct 21 11:57:13 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 21 Oct 2010 18:57:13 +0200 Subject: =?UTF-8?B?RmFpbG92ZXIgSVB2NiB3aXRoIG11bHRpcGxlIFBBIHByZWZpeGVzICg=?= =?UTF-8?B?V2FzOiBJUHY2IGZjMDA6Oi83IOKAlCBVbmlxdWUgbG9jYWwgYWRkcmVzc2VzKQ==?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: <4CC070E9.7090709@unfix.org> [Oh wow, that subject field, so handy to indicate a topic change! ;) ] On 2010-10-21 18:29, Allen Smith wrote: [... well described situation about having two/multiple IPv4 upstreams, enabling dual-stack at both, but wanting to failover between them without doing NATv6 ...] Short answer: you announce both PA prefixes using Router Advertisement (RA) inside the network. You pull the RA when a uplink goes down/breaks. Sessions break indeed, but because there is the other prefix they fall over to that and build up new sessions from there. Most RA "daemons" will properly send a 0-lifetime announcement to pull the prefix thus all hosts are automatically informed that the prefix has become invalid. Of course you can also make the router's IP address unreachable as then Neighbor Discovery will take care of failing over too. To address your 'we have multiple groups of people some use slow some use fast', put them in separate (V)LANs and presto. You could effectively live with using one prefix per group and only failing over to the other prefix when the primary one goes down; that is only RA the prefix to those VLANs when you really need it. You should be getting a /48 from both ISPs and here comes the reason for always getting a /48 and nothing else: you have the same numbering plan for all of them. Now the problem with such a setup is the many locations where you actually are hardcoding the IP addresses/prefixes into: firewalls, DNS etc. That is the hard part to solve, especially when these services are managed by other parties. Greets, Jeroen From regnauld at nsrc.org Thu Oct 21 12:02:59 2010 From: regnauld at nsrc.org (Phil Regnauld) Date: Thu, 21 Oct 2010 19:02:59 +0200 Subject: Failover IPv6 with =?utf-8?Q?multiple_?= =?utf-8?Q?PA_prefixes_=28Was=3A_IPv6_fc00=3A=3A=2F7_?= =?utf-8?B?4oCU?= Unique local addresses) In-Reply-To: <4CC070E9.7090709@unfix.org> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> Message-ID: <20101021170258.GE61771@macbook.catpipe.net> Jeroen Massar (jeroen) writes: > > Now the problem with such a setup is the many locations where you > actually are hardcoding the IP addresses/prefixes into: firewalls, DNS > etc. That is the hard part to solve, especially when these services are > managed by other parties. And probably the reason why most won't deploy RA and multiple prefixes. Hardcode and NAT, baby! From tme at americafree.tv Thu Oct 21 12:09:21 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 21 Oct 2010 13:09:21 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> Message-ID: <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> On Oct 21, 2010, at 12:34 PM, Ben Butler wrote: > Hi, > > I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of And how would you propose to achieve that ? Regards Marshall > responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations. > > The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years. > > You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river. > > My 2c. > > Ben > > -----Original Message----- > From: Dan White [mailto:dwhite at olp.net] > Sent: 21 October 2010 16:30 > To: Ben Butler > Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > On 21/10/10 16:07 +0100, Ben Butler wrote: >> Hi, >> >> Showing my ignorance here, but this is one of the things I have wondered, >> given that we run both v4 and v6 for a period of time on the Internet, >> presumably at one time or another a particular resource may only be able >> in v4 land, then v4 and v6, then finally v6 only. >> >> I have never been particularly clear how an end network that exists only >> in v4 or v6 address space is able to access a resource that only exists in >> the other. Is can sort of see some freaking huge NAT box type thing that >> summarizes v6 in a v4 address scope or contains the v4 address range at >> some point inside the v6 address space - but how can a v4 host get to a >> hot in v6 world that sits outside this without going through some form of >> proxy / nat gateway between the two. >> >> Or are the two simply not inter-communicable? > > I think that's the $64K question. Do you wait to roll out v6 until you > start seeing v6-only hosts start popping up? From an accounting and cost > recovery stand point, that probably makes sense in some environments. > > However, consider the fact that there will be v6 only hosts popping up > after IANA/RIR/ISP exhaustion. There will be new entrants in the public > internet space that cannot obtain v4 addresses and will be reachable via v6 > only. That date is starting to become a bit more predictable too. Those v6 > only sites won't be Google or Yahoo, but they will be entrepreneurs with > good ideas and new services that your customers will be asking to get > access to. > > We're pursuing a dual stacking model today because we anticipate that > the dual-stacking process itself will take a while to deploy, and we want > to anticipate customer demand for access to v6 only sites. We could hold > off on that deployment, and then spend money on work at the moment of > truth, but that approach is not very appealing to us. > > -- > Dan White > > > > -------------------------------------------------------------------------- > BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} > Ben Butler > Director Tel: 0333 666 3332 > Fax: 0333 666 3331 > C2 Business Networking Ltd > The Paddock, London Road, Nantwich, Cheshire, CW5 7JL > http://www.c2internet.net/ > > Part of the Atlas Business Group of Companies plc > Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 > This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. > > > > > From ben.butler at c2internet.net Thu Oct 21 12:17:46 2010 From: ben.butler at c2internet.net (Ben Butler) Date: Thu, 21 Oct 2010 18:17:46 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> Message-ID: Hi, What is the consequence of not managing to transition the v4 network and having to maintain it indefinitely. I think if the cost / limitations that this may place on things is great enough then the "how" will reveal itself with the interested parties. Is there a downside to being stuck with both address spaces rather than just 6, idk, you tell me, but there seems to be from what I can tell. I am not suggesting any form of timeframe in the exact number of years / decades, just that a timeframe should exist where after a certain date - whatever that is - we can say ok, now we are turning off v4. In the absence of any form of timeframe what is the operational benefit of any existing v4 user migrating to v6 if the service provider is going to make magic happen that enables them to talk to v6 only host via some mysterious bridging box. I can see none, which tells me they are not going to bother spending there time and money renumbering and deploying v6 - ever! There needs to be a technical, commercial or operational reason for them to want to go through the change. Ben -----Original Message----- From: Marshall Eubanks [mailto:tme at americafree.tv] Sent: 21 October 2010 18:09 To: Ben Butler Cc: 'Dan White'; NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA On Oct 21, 2010, at 12:34 PM, Ben Butler wrote: > Hi, > > I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of And how would you propose to achieve that ? Regards Marshall > responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations. > > The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years. > > You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river. > > My 2c. > > Ben > > -----Original Message----- > From: Dan White [mailto:dwhite at olp.net] > Sent: 21 October 2010 16:30 > To: Ben Butler > Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > On 21/10/10 16:07 +0100, Ben Butler wrote: >> Hi, >> >> Showing my ignorance here, but this is one of the things I have wondered, >> given that we run both v4 and v6 for a period of time on the Internet, >> presumably at one time or another a particular resource may only be able >> in v4 land, then v4 and v6, then finally v6 only. >> >> I have never been particularly clear how an end network that exists only >> in v4 or v6 address space is able to access a resource that only exists in >> the other. Is can sort of see some freaking huge NAT box type thing that >> summarizes v6 in a v4 address scope or contains the v4 address range at >> some point inside the v6 address space - but how can a v4 host get to a >> hot in v6 world that sits outside this without going through some form of >> proxy / nat gateway between the two. >> >> Or are the two simply not inter-communicable? > > I think that's the $64K question. Do you wait to roll out v6 until you > start seeing v6-only hosts start popping up? From an accounting and cost > recovery stand point, that probably makes sense in some environments. > > However, consider the fact that there will be v6 only hosts popping up > after IANA/RIR/ISP exhaustion. There will be new entrants in the public > internet space that cannot obtain v4 addresses and will be reachable via v6 > only. That date is starting to become a bit more predictable too. Those v6 > only sites won't be Google or Yahoo, but they will be entrepreneurs with > good ideas and new services that your customers will be asking to get > access to. > > We're pursuing a dual stacking model today because we anticipate that > the dual-stacking process itself will take a while to deploy, and we want > to anticipate customer demand for access to v6 only sites. We could hold > off on that deployment, and then spend money on work at the moment of > truth, but that approach is not very appealing to us. > > -- > Dan White > > > > -------------------------------------------------------------------------- > BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} > Ben Butler > Director Tel: 0333 666 3332 > Fax: 0333 666 3331 > C2 Business Networking Ltd > The Paddock, London Road, Nantwich, Cheshire, CW5 7JL > http://www.c2internet.net/ > > Part of the Atlas Business Group of Companies plc > Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 > This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. > > > > > From bill at herrin.us Thu Oct 21 12:23:24 2010 From: bill at herrin.us (William Herrin) Date: Thu, 21 Oct 2010 13:23:24 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <4CBF9C42.3050608@matthew.at> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> Message-ID: On Wed, Oct 20, 2010 at 9:49 PM, Matthew Kaufman wrote: > On 10/20/2010 5:51 PM, Owen DeLong wrote: >> Part 2 will be when the first provider accepts a large sum of money to >> route it within their public network between multiple sites owned by >> the same customer. > > Is this happening now with RFC 1918 addresses and IPv4? Some designs for the "carrier NATs" that are supposed to tide us over from from v4 depletion through v6 deployment would seem to be an open door for this scenario. >> Part 3 will be when that same provider (or some other provider in the >> same boat) takes the next step and starts trading routes of ULA space >> with other provider(s). > > Is this happening now with RFC 1918 addresses and IPv4? No. There's too much complexity associated with multiple ISPs negotiating private routing policies while VPNs work very well without needing special services from the ISP. Owen has this notion that there's a natural evolutionary path that will bring about some circumstance where two particular ISPs find it advantageous to swap ULA routes. That same driving force would presumably lead those ISPs to interact with a third and so on until the use of ULA addresses on the public Internet was a defacto standard. If there's a credible scenario where two ISPs and the folks paying them would find such a course of action preferable to the myriad other options for solving the given problem, I haven't heard it yet. If such a scenario exists, it's not obvious. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From cb.list6 at gmail.com Thu Oct 21 12:25:21 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 21 Oct 2010 10:25:21 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> Message-ID: On Thu, Oct 21, 2010 at 8:07 AM, Ben Butler wrote: > Hi, > > Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only. > > I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. ?Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two. > > Or are the two simply not inter-communicable? > > Ben > > -----Original Message----- > From: Patrick Giagnocavo [mailto:patrick at zill.net] > Sent: 21 October 2010 15:59 > To: Owen DeLong; NANOG > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > On 10/21/2010 4:28 AM, Owen DeLong wrote: > >>> Actually for those of my clients in one location, it served as an >>> impetus to extend a contract with Level3 for another 3 years - with >>> their existing allocation of a /24 of IPv4 addresses included. >> >> All well and good until some of their customers are on IPv6... >> Then what? > > I'm sorry, can you expand on exactly what you mean by this? > > Are IPv6 connected machines unable to access IPv4 addresses? IPv6->IPv4 is called NAT64, and it works today pretty well. Most things work very well (web, email, ...), somethings don't (skype ..) http://www.youtube.com/watch?v=AmjlptEva4Y#t=1h32m26s http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful-12 http://ecdysis.viagenie.ca/ As your major NAT vendor, they probably have NAT64 in the road map for the next 6 to 12 months. IPv4->IPv6 initiated connection are a lost cause that cannot scale in any good way. Cameron From cb.list6 at gmail.com Thu Oct 21 12:33:55 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Thu, 21 Oct 2010 10:33:55 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC05BBF.1010009@zill.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <4CC0575A.4030305@unfix.org> <4CC05BBF.1010009@zill.net> Message-ID: On Thu, Oct 21, 2010 at 8:26 AM, Patrick Giagnocavo wrote: > On 10/21/2010 11:08 AM, Jeroen Massar wrote: >>> On 2010-10-21 16:59, Patrick Giagnocavo wrote: >>> Are IPv6 connected machines unable to access IPv4 addresses? >> >> Unless you put a application/protocol translation in the middle IPv6 >> can't talk to IPv4. yahoo("IVI","Ecdysis NAT64") for two possibilities >> one have for that, oh and yahoo("IPv6Gate") for a ready-to-use HTTP >> specific one. >> >> But if you didn't know that fact, you might want to invest in a proper >> book about IPv6 and read up quite a bit. As this is NANOG, a good >> operational book is "Running IPv6". >> > > Thank you for the book recommendation; however, I was trying to get an > admission that any IPv6-connected end users or corporate connections, > will be accessing IPv4-only resources for a long time to come, i.e. > years and years. > > And that the responsibility for IPv6 to v4 connection won't have to be > handled by my client with a few racks. That depends if your clients application and content works well via NAT64. If you are just serving web pages and you always use FQDNS, great. You are pretty set for a long time. If not, you use IPv4 literals, you may end up on this list, http://groups.google.com/group/ipv4literals and you will have to either modify your application to work via NAT64 or enable IPv6 natively on your side or... have some portion of the internet not reach your services. The better long term strategy is to go ipv6 and take the risk out of all this hedging against the inevitable of LSN / CGN / AFTR. That is what Google, Facebook, and many others are already doing. If a major service provider rolls out IPv6-only devices and services (and they are / will, because IPv4 is out) they will not make a special case for you. So, what you really need to do is figure out if your applications and content work via NAT64 and come up with a good plan for going IPv6 in the long run. It's all about your risk tolerance Cameron ========= http://groups.google.com/group/tmoipv6beta ========= From gbonser at seven.com Thu Oct 21 12:36:29 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 10:36:29 -0700 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C402@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Ray Soucy > Sent: Thursday, October 21, 2010 5:00 AM > To: Jeroen van Aart > Cc: NANOG list > Subject: Re: IPv6 fc00::/7 - Unique local addresses > The mindset of using RFC1918 space, throwing everything behind a NAT > box, and not having to re-configure systems when you change ISP > doesn't exist in IPv6. There is no IPv6 NAT (yet). And that is one of the real challenges here. An office that is not multihomed and has only a short commit to a provider may be reluctant to number their network in that provider's PA space if they really do not want to remain "sticky" to that provider. I can understand that position as I tend not to want to be "sticky" to a provider either. Things change quickly in the world and market rates for connectivity can change rapidly. Short term agreements that give the user the flexibility to move easily to a different provider can be desirable but it might also be impossible to convince the CFO that they need to obtain two providers in order to get their own address block. The issue driving many small networks to multihome isn't really so much that they NEED to multihome, it is because they really want to be able to change providers without renumbering their network/services. RFC-1918 with NAT gave them that flexibility with v4. LUA doesn't really give them that as it currently stands. You can number your networks with both, but that can lead to some interesting RA configurations and can be fun to watch depending on what gear is in place. > > If you wanted to setup an "island" of IPv6 that would never talk to > the Internet, then you could use ULA, but that would only be needed if > you plan on routing between LANs. Remember that by default every IPv6 > host has a link-local address allowing it to talk to any directly > connected hosts without configuration. So if you're simply looking > for some sort of ad-hoc network, it's likely already there. The problem is in putting such link local addresses into the local DNS so hosts can find each other. I generally consider link local IPs in DNS to be a "bad idea" unless it is in a subdomain dedicated that that specific subnet. Given a flat network that isn't routed and is used for clustering machines together, it is a "flat" layer 2 net with no layer3 interfaces except for the hosts themselves (no router interfaces on the network) then having a subdomain just for the hosts on that specific subnet that include the link local IPs on that specific subnet might work. But that is the right application of ULA. That subnet will never get routed off the site so what the heck. In fact, it will never get routed at all. > As much as I hate NAT and want to see it go away. I think the biggest > transition mechanism for people to get online with IPv6 will be some > sort of appliance that does NAT of global IPv6 addresses to private > IPv4 addresses to keep all the people living in the NAT world from > having to redesign their networks. It's ugly, but its the path of > least resistance and that's likely what will happen when we see IPv6 > become required to do business... at least as a stepping stone. That is going to be a tough sell to the network operators. The enterprise guys are all going to say "we need stable addressing that is not tied to a provider" the network operators are going to say "multihome and get your own block" and the enterprise guys are going to say "we already have two connections to our primary provider and can tolerate an outage, this isn't a business killing critical network and it would take a major failure of our current provider or the TELCO to cause us to be completely unreachable, we can't make the business case to justify two transit provider contracts but we DO need stable address space because there are just so many problems with autoconfiguration that we can't make that work in a reliable way". And maybe fixing autoconfiguration is where the key lies to this problem. Having RA announce multiple prefixes is a challenge, though, and as far as I know there is no standard way of saying: "get all available prefixes from the router and use that prefix to mask this host address". For example, say I have configured the host with a "static host mask", for lack of a better name, that uses a ULA address as the mask. Say the mask is fdf7:77d7:b935:123:1b The router is announcing fd11:d148:570f:aaaa:/64 (a ULA subnet), and 2001:200:c000:f473::/64 (some random thing I pulled out of BGP plus some randomness representing some assigned space). So I overlay those prefixes onto the "default" host IP mask. I end up configuring fd11:d148:570f:aaaa:123:1b/64 2001:200:c000:f473:123:1b/64. As I am applying a unique local mask to either a unique local or unique global prefix, I should end up with a unique address either way and can then configure my interface in several subnets in a stable manner that doesn't change over time no matter what provider prefixes I might have and it won't care what the mask is of the subnet prefix being announced by the router as long as it is longer than a /8, I am ok. I route f700::/7 via fd11:d148:570f:aaaa::/64 net gateway and ::/0 via the 2001:200:c000:f473::/64 gateway and I am all set. If my provider changes in the future, I change the prefixes announced from the router and up/down the interface and I am done. The problem is in getting autoconfiguration and RA to do all that exactly the same way with all hosts and all routers of all vendors. Having autoconfig on the host with an option to use a "default address mask" in addition to being able to calculate an EUI-64 can provide a network with some stability and predictability. As for the other problem with trying to use two separate PA blocks, forget it. If you are multihomed, get your own block. That is the only good way forward. From gbonser at seven.com Thu Oct 21 12:38:39 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 10:38:39 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <3D61CC68-0D37-4C59-BC37-93069EDBDFA3@delong.com> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net><87ocanbvue.fsf@oban.berlin.quux.de> <3D61CC68-0D37-4C59-BC37-93069EDBDFA3@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C403@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Owen DeLong > Sent: Thursday, October 21, 2010 5:12 AM > To: Jens Link > Cc: NANOG > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > > On Oct 21, 2010, at 4:59 AM, Jens Link wrote: > > > Owen DeLong writes: > > > >> All well and good until some of their customers are on IPv6... > >> Then what? > > > > Someone will build an appliance to deal with this problem. ;-) > > > And I estimate that the user experience through such appliances will > be poor or worse, driving their former customers to their competitors > that implemented native IPv6. > > Owen > And it will be an expensive operation when someone is pushing multiple gigabits or tens of gigabits of traffic. NAT is probably one of the more expensive operations in a large network facing the Internet that handles a lot of traffic. From ben at bjencks.net Thu Oct 21 12:39:02 2010 From: ben at bjencks.net (Ben Jencks) Date: Thu, 21 Oct 2010 13:39:02 -0400 Subject: =?UTF-8?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=E2=80=94_Unique_local_addresses?= In-Reply-To: <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> Message-ID: On Thu, Oct 21, 2010 at 04:46, Owen DeLong wrote: > > On Oct 20, 2010, at 10:28 PM, Mark Andrews wrote: >> If your big enough to get your own GUA and have the dollars to get >> it routed then do that. ?If you are forced to use PA (think home >> networks) then having a ULA prefix as well is a good thing. >> > home network: 2620:0:930::/48 > > Try again. How do you justify that to ARIN? My reading of the NRPM 6.5.8 ("qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect") and 4.3 (v4 /24 minimum for multihoming, 50% utilization) is that you need at least 128 devices to get a multihoming allocation. That's quite a home network you have. In a related vein, I'm looking at IPv6-numbering a non-connected private network of a few hundred hosts, and while a GUA assignment would be ideal, it looks like I need at least 2048 (50% of a v4 /20) devices to qualify for a non-multihomed v6 assignment. Am I missing something? -Ben From jared at puck.nether.net Thu Oct 21 12:42:54 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 21 Oct 2010 13:42:54 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> Message-ID: How would you respond if that were announced? Carriers have been doing technology transitions for years. Cidr to classless. Amps to CDMA or gsm... This is not new. I do agree the incentives and technology don't exist in a desirable environment but the "ip" feature creep we've seen make a solution for everyone difficult without breaking something. If I were king for a day, there are many things along these lines that I would consider. Sent from my iThing On Oct 21, 2010, at 1:17 PM, Ben Butler wrote: > Hi, > > What is the consequence of not managing to transition the v4 network and having to maintain it indefinitely. I think if the cost / limitations that this may place on things is great enough then the "how" will reveal itself with the interested parties. > > Is there a downside to being stuck with both address spaces rather than just 6, idk, you tell me, but there seems to be from what I can tell. > > I am not suggesting any form of timeframe in the exact number of years / decades, just that a timeframe should exist where after a certain date - whatever that is - we can say ok, now we are turning off v4. > > In the absence of any form of timeframe what is the operational benefit of any existing v4 user migrating to v6 if the service provider is going to make magic happen that enables them to talk to v6 only host via some mysterious bridging box. I can see none, which tells me they are not going to bother spending there time and money renumbering and deploying v6 - ever! There needs to be a technical, commercial or operational reason for them to want to go through the change. > > Ben > > -----Original Message----- > From: Marshall Eubanks [mailto:tme at americafree.tv] > Sent: 21 October 2010 18:09 > To: Ben Butler > Cc: 'Dan White'; NANOG > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > > On Oct 21, 2010, at 12:34 PM, Ben Butler wrote: > >> Hi, >> >> I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of > > And how would you propose to achieve that ? > > Regards > Marshall > > >> responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations. >> >> The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years. >> >> You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river. >> >> My 2c. >> >> Ben >> >> -----Original Message----- >> From: Dan White [mailto:dwhite at olp.net] >> Sent: 21 October 2010 16:30 >> To: Ben Butler >> Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG >> Subject: Re: Only 5x IPv4 /8 remaining at IANA >> >> On 21/10/10 16:07 +0100, Ben Butler wrote: >>> Hi, >>> >>> Showing my ignorance here, but this is one of the things I have wondered, >>> given that we run both v4 and v6 for a period of time on the Internet, >>> presumably at one time or another a particular resource may only be able >>> in v4 land, then v4 and v6, then finally v6 only. >>> >>> I have never been particularly clear how an end network that exists only >>> in v4 or v6 address space is able to access a resource that only exists in >>> the other. Is can sort of see some freaking huge NAT box type thing that >>> summarizes v6 in a v4 address scope or contains the v4 address range at >>> some point inside the v6 address space - but how can a v4 host get to a >>> hot in v6 world that sits outside this without going through some form of >>> proxy / nat gateway between the two. >>> >>> Or are the two simply not inter-communicable? >> >> I think that's the $64K question. Do you wait to roll out v6 until you >> start seeing v6-only hosts start popping up? From an accounting and cost >> recovery stand point, that probably makes sense in some environments. >> >> However, consider the fact that there will be v6 only hosts popping up >> after IANA/RIR/ISP exhaustion. There will be new entrants in the public >> internet space that cannot obtain v4 addresses and will be reachable via v6 >> only. That date is starting to become a bit more predictable too. Those v6 >> only sites won't be Google or Yahoo, but they will be entrepreneurs with >> good ideas and new services that your customers will be asking to get >> access to. >> >> We're pursuing a dual stacking model today because we anticipate that >> the dual-stacking process itself will take a while to deploy, and we want >> to anticipate customer demand for access to v6 only sites. We could hold >> off on that deployment, and then spend money on work at the moment of >> truth, but that approach is not very appealing to us. >> >> -- >> Dan White >> >> >> >> -------------------------------------------------------------------------- >> BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} >> Ben Butler >> Director Tel: 0333 666 3332 >> Fax: 0333 666 3331 >> C2 Business Networking Ltd >> The Paddock, London Road, Nantwich, Cheshire, CW5 7JL >> http://www.c2internet.net/ >> >> Part of the Atlas Business Group of Companies plc >> Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 >> This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. >> >> >> >> >> > > From dhc2 at dcrocker.net Thu Oct 21 12:52:19 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Thu, 21 Oct 2010 10:52:19 -0700 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> Message-ID: <4CC07DD3.6060400@dcrocker.net> On 10/21/2010 10:42 AM, Jared Mauch wrote: > How would you respond if that were announced? ... > If I were king for a day, But you aren't. No one is. The core requirement for such announcements is that there be a real enforcement arm. The best that can be done with respect to declaring a IPv4 sunset date is localized pockets of such control. One could, of course, imagine a federation of such pockets... d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From msa at latt.net Thu Oct 21 12:59:38 2010 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 21 Oct 2010 10:59:38 -0700 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <4CC07DD3.6060400@dcrocker.net> References: <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> Message-ID: <20101021175937.GD13414@puck.nether.net> On Thu, Oct 21, 2010 at 10:52:19AM -0700, Dave CROCKER wrote: > But you aren't. No one is. > > The core requirement for such announcements is that there be a real > enforcement arm. If a couple of large carriers set their own flag dates, and turn off v4 at that point, it will be effectively enforced. Plenty of people aren't particularly 'local' pockets of control. You don't need an enforcement arm -- it just needs to stop making economic sense to support two parallel networks. Since it's automatically wasteful, once enough of the traffic is v6, that may come sooner than you realize. Or, just start charging an arm and a leg for v4 transit until people take the hint... --msa From streiner at cluebyfour.org Thu Oct 21 12:58:46 2010 From: streiner at cluebyfour.org (Justin M. Streiner) Date: Thu, 21 Oct 2010 13:58:46 -0400 (EDT) Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> Message-ID: On Thu, 21 Oct 2010, Jared Mauch wrote: > How would you respond if that were announced? Carriers have been doing > technology transitions for years. Cidr to classless. Amps to CDMA or > gsm... This is not new. My next question would be "How many times will that get extended/pushed back because somebody screams loudly enough?". It will probably sunset around the time that v6 starts to run out of gas and people start thinking about IPv8 (assuming IPv7 would be treated like odd-numbered Linux kernel releases like 2.3.x, 2.5.x, etc - never to see the light of day) :) jms From rps at maine.edu Thu Oct 21 13:19:14 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 14:19:14 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: One thing to keep in mind is that your IPv6 router and IP router can be completely different devices. There is no need to forklift your firewall or current setup if you can easily add an IPv6 router to the network. Using multiple ISPs is still something that is a bit tricky. A lot of people have gotten used to the Dual-WAN Firewall appliance boxes that accept connections from two ISPs and handle the failover, depending on NAT to maintain the functionality of the Internal network. Larger organizations can arrange to have IPv6 transit and announce a single prefix over BGP. Most providers won't want to see this setup for an SMB so they're out of luck. One thing that has changed, though, is Metro Ethernet offerings have gotten a lot better. I would say the most painless way to go would be to use one ISP for L3, and two ME providers to give diverse L2 paths to that L3 ISP. It means dealing with more companies, and moving failover to L2, but it's pretty rare that the cause of a connection problem is at the ISP these days (it's more often a bad connection between you and the ISP), so just having redundancy at L2 might be enough. Sadly, that model doesn't really exist in the US right now, and it might take quite a bit of work convincing providers to coordinate to make it all work. The other option, which was the intent of IPv6 when being designed (but that was 10 years ago or so) was that every PC would have a separate address from each ISP. In this situation you could depend on ULA (local addressing) for access to all internal services so that if one of the global prefixes goes away it doesn't impact internal operation, but it does require a device to kind of coordinate that- such a device doesn't exist yet, and there are some issues with getting PCs to handle address selection correctly. I suspect if this does happen (and it could, it's not a horrible model) it will take a few more years before it's "easy". It's too bad they axed the site local scope for this kind of environment. For now, I would recommend just going with a single IPv6 provider since I have yet to encounter IPv6-only content that is mission critical. That will at least give you access to the IPv6 internet now, but give the IPv6 market time to come around to meet the needs of SMB and wanting redundancy in IPv6 access. I'm not aware of any appliance that does a good job at IPv6, yet... If it were me I would build up a Linux box as a IPv6 firewall, router, etc. It's really too bad that there isn't such an appliance yet. You could just use a Cisco ISR (like an 1841) as your IPv6 on a stick router, but the problem is that you really want to keep in mind that once you give out global addresses to hosts they're not behind your NAT firewall for IPv6. So you'll want to implement some sort of stateful firewall for IPv6, or enable host-based IPv6 firewalls. We've decided to disable SLAAC (State-Less Address Auto-Configuration) on almost all our IPv6 networks and use DHCPv6 exclusively. This allows us to only respond with DHCPv6 to the hosts we want to get an IPv6 address instead of enabling it network-wide and crossing your fingers. The disadvantage here is that DHCPv6 client support is still limited (OS X has none for example). The argument is that IPv6 isn't mission critical yet, so we're waiting to see if vendors will come around and include DHCPv6 client support in the future. Another thing you want to do is block rogue RA. RA-Guard is the feature name, but nobody has a working implementation yet. If you have switches that can do port-based access-lists with IPv6 you can create ingress filters to block out incoming RA on a per-port basis which is what we have done. It works rather well. On Thu, Oct 21, 2010 at 12:29 PM, Allen Smith wrote: > Hi All, > > I've inherited a small network with a couple of Internet connections through > different providers, I'll call them Slow and Fast. > > We use RFC 1918 space internally and have a pair of external firewalls that > handle NAT and such. > > Due to internal policy (read money), some users default to the Slow > connection and some default to Fast. Using probes and policy routing, a > failure of one of the ISPs is generally transparent, outside of the usual > session resets for things like ssh or remote control sessions). > > Looking forward to the next 12 months, we may have clients that are living > in IPv6 space. Our ISPs are happy to give us IPv6 allocations and our > network gear vendors either have GA IPv6 code now or will soon. > > We have been somewhat spoiled by our firewall/NAT boxes, the stuff just > works for our needs and the combination of NAT and policy routing keeps > people on the circuits they are paying for. Am trying to decide how I would > implement this kind of policy in the new world of globally > trackable^H^H^H^H^H^H^H routable IPs for my desktops. Solutions seem to be: > > 1) Purchase some BGP capable routers, grab PI space. Here I can obv choose > outbound path, but we are typical in that our inbound to outbound is 6 or 7 > to 1. > > 2) Assign PA space from the ISPs to the appropriate devices. What do I do > when I loose a provider? > > 3) Make loud noises to my firewall vendor to include equivalent NAT/ISP > failover functionality (even 6to6 NAT would be fine). > > Anyway, another sample of 1, but I do work for a managed services provider > and see many small orgs facing similary choices. I personally am happy to > use globally routable addresses and will work through the privacy and > perceived security implications of NAT/nonat, I just want the same ease of > use and flexibility I have today in a SMB environment. > > Cheers, > -Allen > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From cjeker at diehard.n-r-g.com Thu Oct 21 13:19:30 2010 From: cjeker at diehard.n-r-g.com (Claudio Jeker) Date: Thu, 21 Oct 2010 20:19:30 +0200 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <20101021175937.GD13414@puck.nether.net> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <20101021175937.GD13414@puck.nether.net> Message-ID: <20101021181930.GD15591@diehard.n-r-g.com> On Thu, Oct 21, 2010 at 10:59:38AM -0700, Majdi S. Abbas wrote: > On Thu, Oct 21, 2010 at 10:52:19AM -0700, Dave CROCKER wrote: > > But you aren't. No one is. > > > > The core requirement for such announcements is that there be a real > > enforcement arm. > > If a couple of large carriers set their own flag dates, and > turn off v4 at that point, it will be effectively enforced. Plenty > of people aren't particularly 'local' pockets of control. They would be out of business the day they turn IPv4 off. So it will not happen. > You don't need an enforcement arm -- it just needs to stop > making economic sense to support two parallel networks. Since it's > automatically wasteful, once enough of the traffic is v6, that may > come sooner than you realize. I doubt it. > Or, just start charging an arm and a leg for v4 transit until > people take the hint... and change the ISP. Before you can even start to think about moving away from v4 you need to ensure that everybody is reachable via v6. The problem is that the key organizations try everything to make this not happen. -- :wq Claudio From gbonser at seven.com Thu Oct 21 13:27:25 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 11:27:25 -0700 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C411@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Owen DeLong [mailto:owen at delong.com] > Sent: Thursday, October 21, 2010 5:26 AM > To: Ray Soucy > Cc: NANOG list > > If you're using IPv4 with multiple providers giving you different NAT > pools, then, you're looking at outbound, not inbound resiliency and > the DNS stuff you described is irrelevant. As long as your outbound > gateway(s) have some way to detect provider down-ness (all the > same tactics that work for IPv4 here work for IPv6 with pretty much > the same flaws), you can do the same thing. The difference is that > in IPv6, you have to tell the hosts which IPv6 source prefix to use. > The easy way to do that is to alter the desired/valid lifetimes in > your internal RAs accordingly. This isn't hard to script. That doesn't really work because both of your providers may be "up" but one of them is not reachable by the network at the other end. You cannot predict ahead of time which address a remote network will be able to reach. Being multihomed with one block of addresses solves that problem in that as long as the distant end is getting routing information originated by either of the upstreams, you are good. Also, announcing two network blocks for the same service is a bad idea. If one becomes unreachable while a transaction is in progress, you can't fail over until the connection times out and it reconnects on the other IP. And of the application at the other end is some "secure" java application, it might cache that unreachable IP forever until the application is bounced or until its default cache TTL expires which might be a different TTL than in the DNS information. > If you're using IPv4 with BGP and advertising the same prefix(es) > to multiple providers, the same thing works in IPv6 with nearly > identical processes. Yeah, that's the only way that really works. > > I don't see what NAT gives you for EITHER of those things. Ok, say you have your machines multinetted with two GUA nets on the same interface. Which IP does the application choose to source traffic from when it originates an outbound connection to the world? You can't predict which one is "broken" somewhere along the path. Load balancing inbound is a much simpler model than load balancing outbound and unless you want to push your entire BGP table down to the host, well, it just doesn't work. What *does* work is having your internal net addressed in some stable way that doesn't change when your upstream changes and in IPv4 you simply change your NAT pools to reflect the change. Done, your entire network is "renumbered" as far as the Internet is concerned. If your hosts are numbered in PA space, changing providers means potentially touching the configurations of all machines. A network provider will love that because it discourages customers from changing providers and makes the customer stickier to them. A customer might not feel so comfortable about that and want more independence of the provider's network. From jloiacon at csc.com Thu Oct 21 13:33:23 2010 From: jloiacon at csc.com (Joe Loiacono) Date: Thu, 21 Oct 2010 14:33:23 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> Message-ID: "Justin M. Streiner" wrote on 10/21/2010 01:58:46 PM: > My next question would be "How many times will that get extended/pushed > back because somebody screams loudly enough?". It will probably sunset > around the time that v6 starts to run out of gas and people start thinking > about IPv8 ... Oooh. Did someone say IPv8? http://mailman.apnic.net/mailing-lists/apnic-talk/archive/1998/02/msg00030.html Joe From smeuse at mara.org Thu Oct 21 13:46:59 2010 From: smeuse at mara.org (Steve Meuse) Date: Thu, 21 Oct 2010 14:46:59 -0400 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <20101021115021.2dc77ce6@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <20101021115021.2dc77ce6@opy.nosense.org> Message-ID: <20101021184659.GA9305@mara.org> Mark Smith expunged (nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org): > ULAs should never and are prohibited from appearing in the global route table The problem with this statement is that everyone thinks their own table isn't the "Global Routing Table." -Steve From nathan at atlasnetworks.us Thu Oct 21 13:52:14 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Thu, 21 Oct 2010 18:52:14 +0000 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> Message-ID: <8C26A4FDAE599041A13EB499117D3C284062A32E@ex-mb-2.corp.atlasnetworks.us> ? > Oooh. Did someone say IPv8? > No god! Not this again! Nathan Eisenberg From jmaimon at ttec.com Thu Oct 21 13:53:44 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 21 Oct 2010 14:53:44 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101021153012.GE2843@dan.olp.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> Message-ID: <4CC08C38.80409@ttec.com> Dan White wrote: >> Or are the two simply not inter-communicable? > > I think that's the $64K question. Do you wait to roll out v6 until you > start seeing v6-only hosts start popping up? When do you think that will happen and in what percentages of your target populations to matter? > From an accounting and cost > recovery stand point, that probably makes sense in some environments. > > However, consider the fact that there will be v6 only hosts popping up > after IANA/RIR/ISP exhaustion. There is a phase you are missing between depletion and v6 only hosts. That would be continual and increasing difficulties of obtaining new v4 access and degradation of the quality of that service, hopefully along with a direct inverse effect on the quality and resultant value of v6 service. The time line and gradations of that phase are far less clear than depletion. That would explain why so many do not concern themselves with it at this time. Especially those who do not consider themselves to be the party initially responsible for resolving those issues. http://www.dilbert.com/fast/2006-07-30/ Joe From deepak at ai.net Thu Oct 21 13:59:29 2010 From: deepak at ai.net (Deepak Jain) Date: Thu, 21 Oct 2010 14:59:29 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <20101021181930.GD15591@diehard.n-r-g.com> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <20101021175937.GD13414@puck.nether.net> <20101021181930.GD15591@diehard.n-r-g.com> Message-ID: > They would be out of business the day they turn IPv4 off. So it will > not > happen. IMO, this will not be a decision made by ICANN or a network provider. This will be made by a platform/OS company. Basically, once IPv6 is presumed ubiquitous (it doesn't have to be actually ubiquitous) -- just if you can't reach something by IPv6 you assume it's the far-side's problem -- IPv4 becomes a relic from a business point-of-view, because anyone who doesn't support it is not presumed to be at fault. Microsoft, Apple, or gee-whiz-new-gadget guy simply has to come out with the next revision of their killer product that has dropped support for it. Many may complain, but with those that have sufficient market power to not see a significant affect (and can justify retasking their internal development resources who no longer have to regression test IPv4 stuff against any perceived customer loss) will do it -- they'll probably call it an upgrade. It's been done before. It'll happen again. This doesn't mean IPv4 will disappear. Just like the 20+ year old machines that are still on the net via IPv4 -> legacy protocol gateways, pockets of IPv4 may exist for decades via similar devices -- but at that point, we just dismiss those guys as crackpots. Anyone have an IPv6 coke machine yet? Deepak From gbonser at seven.com Thu Oct 21 13:58:51 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 11:58:51 -0700 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C413@RWC-EX1.corp.seven.com> > From: Ray Soucy > Sent: Thursday, October 21, 2010 5:49 AM > To: Owen DeLong > Cc: NANOG list > Subject: Re: IPv6 fc00::/7 - Unique local addresses > > See... You're falling into the same elitist mindset that I was trapped > in a year ago. > > Perception is a powerful thing. And Joe IT guy at Mom and Pop dot com > (who's network experience involves setting up a Linksys at home) loves > his magical NAT box firewall appliance. Over the last year I've been > trying to fight the NAT war and have gotten pretty beat down. It > doesn't matter if *we* know NAT is wrong, undesirable, and breaks the > Internet... we all live in the large scale, multi-homed, BGP, mega > Internet land. And BetaMAX was a much better format than VHS, too, from a technical standpoint. It doesn't matter which is "better", it matters what people want. Telling people they can't have what they want leads to someone somewhere providing them with what they want and making a fortune on it. > Start working with smaller shops, and you'll find the typical setup is > a bunch of switches and a "VPN Firewall" picked up from Best Buy, or > maybe a Sonicwall or something. These guys couldn't manage public > IPv4 let alone public IPv6, because the term "private" gives them that > warm and fuzzy false sense of security and lets them change their ISP > without reconfiguring a single thing (they often wouldn't know where > to start anyway). I am not sure there really is a such thing as a "secure" network. If you can somehow get a host inside a network to send the first packet to you, you are in. Yeah, all those filters and NATs prevent you from being able to send the first packet, but as long as people are dragging in laptops, thumb drives, opening email attachments, and browsing the web, there is no such thing as a "secure" network if it has internet access. Even the deepest packet inspection won't make you secure of the traffic going back and forth abides by the protocol rules. Is that really a file upload and download going on, or is it a bi-directional tunnel disguised as file transfers that never end and is someone now doing a complete scan of your network from one of your employee's workstations? Having a lock on the door is fine, but for a door to be useful, you must be able to open it from the inside. And when you take a delivery, are you sure what is in that box is what is really on the packing slip? And if you take it out of the box and look on it, is it still *really* what it says on the packing slip? Sort of like a birthday cake arriving at a prison. > They *will* fight you, and tell you to your face that if you want to > take NAT away from them it will be from their cold dead hands. And it isn't NAT in and of itself that is attractive. Those people aren't talking about static NAT where you are just translating the network prefix. They are talking dynamic port-based PAT so that the translation doesn't exist until the first packet goes in the outbound direction. Like it or not, that DOES provide some barrier of entry to someone outside wishing to initiate a connection from the outside. You cannot predict in advance what outside address/port will be associated with which inside address/port or if any such association even exists and a lot of people have already made up their minds that the breakage that causes for various things is offset by the perceived benefit of that barrier and worth the price of dealing with that breakage. > Why? Because we've had 10 years of "consultants" selling NAT as the > best thing for security since sliced bread. > > Maybe we could get them to do it the right way if they had some sort > of IPv6 appliance that dumbed things down, but it simply doesn't exist > yet. When it is created, it will be created by the people with the > NAT mindset wishing to maintain the status quo. > > At least that's my prediction... I tend to agree with that. Not saying that I think that is the best way to go, mind you, just saying that I can see such a thing happening and all the jumping up and down on NANOG isn't going to change that because it is the end user that decides in the end what gets built and what doesn't. So either put into the protocol a specific prohibition of NAT, engineer the protocol so NAT can't possibly work, or get ready to accept that you are going to be dealing with it. > We need to keep in mind that most on this list is likely at a > completely different level than anything you'd find in the SMB > community. I have tried making that point privately to many individuals but it doesn't seem to click and is taken as if I am "defending" or somehow rationalizing that "dumbed down" behavior when I am simply acknowledging the existence of it. Sort of like when your daughter starts dating that ne'er-do-well up the street. Sometimes it just is what it is and you can point out the potential problems until the cows come home but it isn't really going to matter. There are billions more of "them" than there are of "us" to put it in tribal terms. In fact, I will say that the lack of such NAT features is exactly WHY IPv6 hasn't caught on in many networks. They can't afford to hire "networking" people, they hire > "IT" people who are tasked with anything related to technology and > usually completely understaffed. Thus they want the quick, painless, > easy solution. If it doesn't have a GUI checkbox, it doesn't exist. So they configure a NAT pool, and maybe put a packet filter on the router ahead of it and they are "done" as far as they are concerned. Changing providers means touching the network in two places. From merkel at metalink.net Thu Oct 21 14:05:37 2010 From: merkel at metalink.net (Eric Merkel) Date: Thu, 21 Oct 2010 15:05:37 -0400 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: <5294CF7C-E618-41E5-ACFB-E299CD25A5E5@beanfield.com> References: <022801cb706a$ead9d5e0$c08d81a0$@net> <5294CF7C-E618-41E5-ACFB-E299CD25A5E5@beanfield.com> Message-ID: <042e01cb7152$f285e7f0$d791b7d0$@net> Thanks to everyone who responded. Just got done talking with Extreme which no one really mentioned. Seems like decent gear reasonably priced. Anyone care to comment on them specifically or have them used them a metro Ethernet build? ===== Eric Merkel MetaLINK Technologies, Inc. Email: merkel at metalink.net -----Original Message----- From: Dan Armstrong [mailto:dan at beanfield.com] Sent: 2010-10-20 19:50 To: Ramanpreet Singh Cc: Jason Lixfeld; nanog at nanog.org Subject: Re: Recommendations for Metro-Ethernet Equipment I think that's what Jason just said. :-) On 2010-10-20, at 5:24 PM, Ramanpreet Singh wrote: > 7600's/ASR 1k > > Have you looked in to Ciso ME 3600X/ME 3800X series? > > Without a bias these are the top notch products in the market for Metro E. > > -Raman > > On Wed, Oct 20, 2010 at 12:57 PM, Jason Lixfeld wrote: >> On 2010-10-20, at 11:24 AM, Eric Merkel wrote: >> >>> Any suggestions, success or horror stories are appreciated. ;) >> >> I've been going through pretty much the same exercise looking for a decent PE for almost two years. Our requirements were for a PE device that had between 12-24 ports (in a perfect world, mixed mode 10/100/1000 copper + SFP), 10G uplinks, EoMPLS, MPLS VPN, DHCP server, port-protect/UNI (or similar) capabilities, DC power and a small footprint (1RU) >> >> Of all the ones we looked at (Juniper, Cisco, Extreme, Brocade, MRV, Alcatel) initially, MRV was the only contender. The rest either didn't have a product, or their offering didn't meet various points within our criteria. >> >> As such, we bought a bunch of MRVs in early 2009 and after four months of trial and error, we yanked every single one out of the network. From a physical perspective, the box was perfect. Port density was perfect, mixed-mode ports, promised a 10G uplink product soon, size was perfect, power was perfect, we thought we had it nailed. Unfortunately there are no words to describe how terrible the software was. The CLI took a little getting used to, which is pretty much par for the course when you're dealing with a new vendor, but the code itself was just absolutely broken, everywhere. Duplex issues, LDP constantly crashing taking the box with it, OSPF issues, the list went on and on. To their credit, they flew engineers up from the US and they were quite committed to making stuff work, but at the end of the day, they just couldn't make it go. We pulled the plug in May 2009 and I haven't heard a thing about their product since then, so maybe they've got it all together. >> >> While meeting with Juniper a few months later about a different project, they said they had a product that might fit our needs. The EX4200. As such, we had a few of these loaned to our lab for a few months to put through their paces, from a features and interoperability perspective. They work[1] and they seem to work well. The show stopper was provisioning[1] and size. The box is massive, albeit it is still 1U. >> >> [1] (I'm not a Juniper guy, so my recollection on specific terms and jargon may be a bit off kilter) they only support ccc, which makes provisioning an absolute nightmare. From my experience with Cisco and MRV, you only have to configure the EoMPLS vc. On the EX4200, you have to create the LSPs as well. To get a ccc working, the JunOS code block was far larger and much more involved per vc than the single line Cisco equivalent. To create the LSPs was, I believe, two more equally large sized code blocks. At the end of the day, it was just too involved. We needed something simpler. >> >> About the same time that we started to evaluate the EX4200, Cisco had pitched us on their (then alpha) Whales platform. It looked promising (MRV still had the best form factor) and we expressed our interest in getting a beta unit in as soon as we were able to. This is now known as the ME3600 and ME3800 platform and we've been testing a beta unit in our lab for the past few months. This is the platform we have chosen. It's not perfect, but our gripes have more to do with form factor (it's 1RU, but it's a bit deeper than what we'd like) and port densities (no mixed mode ports) than software or features. We've been pretty pleased with it's feature set and performance, but this hasn't seen any real world action, so who knows how that will turn out. >> >> If you're asking more about a P router or P/PE hybrid, we've also just ordered a few ASR9000s under try-and-buy as P/PEs to close up the chains of ME3600s that will start to be deployed in our remote sites. A Juniper MX would certainly work well here too, and it seems to interoperate rather well with the ME3600s, so that's certainly an option, but for us, we think it will work more in our favor to go with the ASRs in the core, but if not, we'd ship them back under the try-and-buy and get Junipers instead. >> >> Hope that helps. >> > From dwhite at olp.net Thu Oct 21 14:15:43 2010 From: dwhite at olp.net (Dan White) Date: Thu, 21 Oct 2010 14:15:43 -0500 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC08C38.80409@ttec.com> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <4CC08C38.80409@ttec.com> Message-ID: <20101021191543.GM2843@dan.olp.net> On 21/10/10?14:53?-0400, Joe Maimon wrote: > > >Dan White wrote: > >>>Or are the two simply not inter-communicable? >> >>I think that's the $64K question. Do you wait to roll out v6 until you >>start seeing v6-only hosts start popping up? > >When do you think that will happen and in what percentages of your >target populations to matter? I could guess, but I'd probably be wrong. I'd like to be wrong in the right direction :) >>From an accounting and cost >>recovery stand point, that probably makes sense in some environments. >> >>However, consider the fact that there will be v6 only hosts popping up >>after IANA/RIR/ISP exhaustion. > >There is a phase you are missing between depletion and v6 only hosts. > >That would be continual and increasing difficulties of obtaining new >v4 access and degradation of the quality of that service, hopefully >along with a direct inverse effect on the quality and resultant value >of v6 service. You're thinking in the big picture. I'm thinking of the specific scenario where my customers start calling me up because they can't get to *one* really important site that couldn't get v4 addresses. I view that as the drop dead date for implementing dual-stack for us. >The time line and gradations of that phase are far less clear than >depletion. > >That would explain why so many do not concern themselves with it at >this time. Especially those who do not consider themselves to be the >party initially responsible for resolving those issues. > >http://www.dilbert.com/fast/2006-07-30/ I understand the idea that there's going to be a sliding curve of adoption for those with the resources to purchase v4 transfer. I just don't buy into the idea that that's going to push back v6 adoption very much. That's going to be a game for the rich and the richer. In a way, it's kind of like the credit crunch of a year or two ago. The large banks and federal reserve colluded to make sure that credit kept flowing for small businesses and entrepreneurs, even though the current conditions of the market couldn't support it, because restricted access to credit by startups with good ideas would have been a rock to the head of the economy. I think the press are going to rip into the 'dinosaurs' and 'monopolies' who don't move quickly enough to support the nimble expansion of new services based around v6. -- Dan White From gbonser at seven.com Thu Oct 21 14:25:18 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 12:25:18 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <20101021153012.GE2843@dan.olp.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net><4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C415@RWC-EX1.corp.seven.com> > From: Dan White > Sent: Thursday, October 21, 2010 8:30 AM > To: Ben Butler > Cc: NANOG > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > > I think that's the $64K question. Do you wait to roll out v6 until you > start seeing v6-only hosts start popping up? From an accounting and > cost > recovery stand point, that probably makes sense in some environments. And so everyone is waiting for everyone else to see IPv6 traffic. Which is sort of where we are now. Everyone is standing around the pool waiting for everyone else to jump in. The usual "early adopters" are in there but people are still waiting for "Mikey" to see if he likes it. > However, consider the fact that there will be v6 only hosts popping up > after IANA/RIR/ISP exhaustion. There will be new entrants in the public > internet space that cannot obtain v4 addresses and will be reachable > via v6 > only ... Yep, you can't do NAT64 if you don't have "4". But that said, just because ARIN is exhausted doesn't mean PA space is exhausted so there will be addresses available though it will be tight. From leen at consolejunkie.net Thu Oct 21 14:33:46 2010 From: leen at consolejunkie.net (Leen Besselink) Date: Thu, 21 Oct 2010 21:33:46 +0200 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C415@RWC-EX1.corp.seven.com> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net><4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <5A6D953473350C4B9995546AFE9939EE0B14C415@RWC-EX1.corp.seven.com> Message-ID: <4CC0959A.3060603@consolejunkie.net> On 10/21/2010 09:25 PM, George Bonser wrote: >> However, consider the fact that there will be v6 only hosts popping up >> after IANA/RIR/ISP exhaustion. There will be new entrants in the > public >> internet space that cannot obtain v4 addresses and will be reachable >> via v6 >> only ... > Yep, you can't do NAT64 if you don't have "4". But that said, just > because ARIN is exhausted doesn't mean PA space is exhausted so there > will be addresses available though it will be tight. > > That is exactly what the last 5 /8's are for as I understand it. The last 5 /8's will be allocated to each RIR immediately and I think by now every RIR has a policy for that last /8 which pretty much says: only for transitional purposes From morrowc.lists at gmail.com Thu Oct 21 14:33:58 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Thu, 21 Oct 2010 15:33:58 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <20101021181930.GD15591@diehard.n-r-g.com> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <20101021175937.GD13414@puck.nether.net> <20101021181930.GD15591@diehard.n-r-g.com> Message-ID: On Thu, Oct 21, 2010 at 2:19 PM, Claudio Jeker wrote: > On Thu, Oct 21, 2010 at 10:59:38AM -0700, Majdi S. Abbas wrote: >> On Thu, Oct 21, 2010 at 10:52:19AM -0700, Dave CROCKER wrote: >> > But you aren't. ?No one is. >> > >> > The core requirement for such announcements is that there be a real >> > enforcement arm. > I doubt it. > >> ? ? ? Or, just start charging an arm and a leg for v4 transit until >> people take the hint... > > and change the ISP. Before you can even start to think about moving away > from v4 you need to ensure that everybody is reachable via v6. The problem > is that the key organizations try everything to make this not happen. ;; QUESTION SECTION: ;bbiw.net. IN ANY ;; ANSWER SECTION: bbiw.net. 285 IN A 72.52.113.67 indeed.... From gbonser at seven.com Thu Oct 21 14:35:35 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 12:35:35 -0700 Subject: =?UTF-8?B?UkU6IEZhaWxvdmVyIElQdjYgd2l0aCBtdWx0aXBsZSA=?= =?UTF-8?B?UEEgcHJlZml4ZXMgKFdhczogSVB2NiBmYzAwOjovNyA=?= =?UTF-8?B?4oCUIFVuaXF1ZSBsb2NhbCBhZGRyZXNzZXMp?= In-Reply-To: <4CC070E9.7090709@unfix.org> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> > From: Jeroen Massar > Sent: Thursday, October 21, 2010 9:57 AM > To: Allen Smith > Cc: NANOG list > Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 ? > Unique local addresses) > > [Oh wow, that subject field, so handy to indicate a topic change! ;) ] > > Short answer: you announce both PA prefixes using Router Advertisement > (RA) inside the network. You pull the RA when a uplink goes > down/breaks. That assumes importing some sort of routing state into your RA config. Sort of a conditional RA. Can that be done today by anyone? > Sessions break indeed, but because there is the other prefix they fall > over to that and build up new sessions from there. This still doesn?t address breakage that happens AFTER your link to your upstream. What if your upstream has a peering issue or their peer has a peering issue? How do you detect that the distant end has a route back to that prefix but doesn't to the other? You can't. From bit.gossip at chello.nl Thu Oct 21 14:43:00 2010 From: bit.gossip at chello.nl (Luca Tosolini) Date: Thu, 21 Oct 2010 21:43:00 +0200 Subject: IPv6 fc00::/7 =?UTF-8?Q?=E2=80=94?= Unique local addresses In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: <1287690180.2395.48.camel@localhost> On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote: > We've decided to disable SLAAC (State-Less Address Auto-Configuration) > on almost all our IPv6 networks and use DHCPv6 exclusively. This > allows us to only respond with DHCPv6 to the hosts we want to get an > IPv6 address instead of enabling it network-wide and crossing your > fingers. The disadvantage here is that DHCPv6 client support is still > limited (OS X has none for example). The argument is that IPv6 isn't > mission critical yet, so we're waiting to see if vendors will come > around and include DHCPv6 client support in the future. > Ray, how do you convey the default-router information with DHCPv6 only. AFAIK there is no such field in DHCPv6... Luca. From jeroen at unfix.org Thu Oct 21 14:51:49 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 21 Oct 2010 21:51:49 +0200 Subject: =?UTF-8?B?UmU6IEZhaWxvdmVyIElQdjYgd2l0aCBtdWx0aXBsZSBQQSBwcmVmaXg=?= =?UTF-8?B?ZXMgKFdhczogSVB2NiBmYzAwOjovNyDigJQgVW5pcXVlIGxvY2FsIGFkZHJlc3M=?= =?UTF-8?B?ZXMp?= In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> Message-ID: <4CC099D5.3010401@unfix.org> On 2010-10-21 21:35, George Bonser wrote: > > >> From: Jeroen Massar > Sent: Thursday, October 21, 2010 9:57 AM >> To: Allen Smith >> Cc: NANOG list >> Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 ? >> Unique local addresses) >> >> [Oh wow, that subject field, so handy to indicate a topic change! ;) ] >> >> Short answer: you announce both PA prefixes using Router Advertisement >> (RA) inside the network. You pull the RA when a uplink goes >> down/breaks. > > That assumes importing some sort of routing state into your RA config. > Sort of a conditional RA. Can that be done today by anyone? Should be possible with any vendor that supports IPv6. If you take a vendor C box and the box dies (just pull the power plug to test this or configure it with something funky ;), Neighbor Discovery starts failing and every IPv6 stack that I know will deprecate the routes over that gateway, and stuff fails over. For 'production usage', let your monitor script login to your router, whatever brand/make/model that is, and unconfigure the RA or heck kill the radvd daemon. >> Sessions break indeed, but because there is the other prefix they fall >> over to that and build up new sessions from there. > > This still doesn?t address breakage that happens AFTER your link to your upstream. > What if your upstream has a peering issue or their peer has a peering issue? > How do you detect that the distant end has a route back to that prefix but > doesn't to the other? You can't. Solve it the way you solve it with PI: - Get an SLA with every destination you want to reach Indeed, that is a more or less unsolveable problem. You can of course monitor all the destinations you want to reach and based on that to use the prefix or not. Greets, Jeroen From gbonser at seven.com Thu Oct 21 14:53:51 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 12:53:51 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net><4CC0553C.8060202@zill.net><20101021153012.GE2843@dan.olp.net><7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com> > From: Ben Butler > Sent: Thursday, October 21, 2010 10:18 AM > To: 'Marshall Eubanks' > Cc: NANOG > Subject: RE: Only 5x IPv4 /8 remaining at IANA > > Hi, > > What is the consequence of not managing to transition the v4 network > and having to maintain it indefinitely. I think if the cost / > limitations that this may place on things is great enough then the > "how" will reveal itself with the interested parties. > > Is there a downside to being stuck with both address spaces rather than > just 6, idk, you tell me, but there seems to be from what I can tell. > > I am not suggesting any form of timeframe in the exact number of years > / decades, just that a timeframe should exist where after a certain > date - whatever that is - we can say ok, now we are turning off v4. The first step will be a registrar saying "after this date, we will no longer issue any IPv4 addresses for whatever reason" and at the same time, getting very aggressive in reclaiming space from dead entities, hijackers, etc. As time goes by, the amount of v4 space being routed declines through natural attrition. It is a combination of liberal v6 assignment coupled with aggressive v4 reclamation. At some point the network operators themselves will announce their own "drop dead" dates for supporting v4. When the amount of v4 traffic drops to some point where the infrastructure required to support it becomes unreasonable, they will stop supporting it. As v4 becomes harder to route, it will become harder to find v4 providers ... sort of like v6 is not available from *all* providers in a native sense today. Sure, there will probably be people out there who will offer v4 over v6 tunnels long after most providers have stopped routing it sort of like 6 over 4 is offered today, but even those will become scarce at some point. Once no more addresses are issued for any reason and once people stop handling the traffic natively, it will die its own natural death and kids entering the networking field will look at a v4 config and wonder why it is even there. > In the absence of any form of timeframe what is the operational benefit > of any existing v4 user migrating to v6 if the service provider is > going to make magic happen that enables them to talk to v6 only host > via some mysterious bridging box. Yeah, that does delay things but is required glue for the moment. > I can see none, which tells me they > are not going to bother spending there time and money renumbering and > deploying v6 - ever! Yes they will, see above. > There needs to be a technical, commercial or > operational reason for them to want to go through the change. > > Ben Yeah, the "we decided to make a completely incompatible protocol with really no other immediate technical benefit other than more address space ... and each route takes up 4x more router resources" decision was probably a bad call. Heck, simply expanding the number of ports from 16 bit to 32 bit would have greatly reduced ip address requirements from people having to add IPs to NAT pools and other source NATs due to port exhaustion. From rps at maine.edu Thu Oct 21 14:59:13 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 15:59:13 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <1287690180.2395.48.camel@localhost> References: <4CBF63BF.2000101@mompl.net> <1287690180.2395.48.camel@localhost> Message-ID: I think you're misunderstanding how DHCPv6 works. Don't think of it like DHCP that you're used to. DHCPv6 requires an IPv6 router advertisement to work. There are three flags of interest in a router advertisement. One of them is the "A" (autonomous) flag which is enabled by default in almost every implementation I've seen. This is what signals a host that it is permitted to use stateless configuration with the prefix. There are also "M" (managed) and "O" other flags. The "M" flag being set signals the host that it should start a DHCPv6 client and make a request for an address, the "O" flag signals that the host should ask for "other" or additional configuration information through DHCPv6 (e.g. DNS servers). None of the flags are exclusive, so you can enable DHCPv6 by setting the M flag, but unless you disable the A flag, hosts will still use stateless configuration (in addition to DHCPv6 and receive two addresses) If you want a DHCPv6-only environment, you simply disable the A flag on the router advertisement. This will stop hosts from using stateless with the advertised prefix. The default gateway for the network is learned through the router advertisement, not through DHCPv6, which is why it doesn't exist in DHCPv6. Example IOS configuration: interface Vlan123 description Test IPv6 Network ipv6 address FD00:1234:5678:9ABC::1/64 no ipv6 unreachables ipv6 nd prefix default 2592000 604800 no-autoconfig ipv6 nd managed-config-flag ipv6 nd other-config-flag ipv6 nd router-preference High no ipv6 redirects ipv6 verify unicast source reachable-via rx ipv6 eigrp 123 ipv6 dhcp relay destination FD00:1234:5678:9ABC::2 ipv6 dhcp relay destination FD00:1234:5678:9ABC::3 The "ipv6 nd prefix ... no-autoconfig" statement is what you're looking for. You need to type out timers to be able to get to it. The values shown are just the Cisco defaults. On Thu, Oct 21, 2010 at 3:43 PM, Luca Tosolini wrote: > On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote: > >> We've decided to disable SLAAC (State-Less Address Auto-Configuration) >> on almost all our IPv6 networks and use DHCPv6 exclusively. ?This >> allows us to only respond with DHCPv6 to the hosts we want to get an >> IPv6 address instead of enabling it network-wide and crossing your >> fingers. ?The disadvantage here is that DHCPv6 client support is still >> limited (OS X has none for example). ? The argument is that IPv6 isn't >> mission critical yet, so we're waiting to see if vendors will come >> around and include DHCPv6 client support in the future. >> > > Ray, > how do you convey the default-router information with DHCPv6 only. AFAIK > there is no such field in DHCPv6... > > Luca. > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Thu Oct 21 15:08:38 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 16:08:38 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <1287690180.2395.48.camel@localhost> Message-ID: Also, Keep in mind that DHCPv6 uses a DUID for host identification and not a MAC address. Here is an example ISC DHCPd configuration for an IPv6 network without open pool allocation (it will only respond for hosts in the config). # subnet6 for each network subnet6 FD00:1234:5678:9ABC::/64 { option dhcp6.name-servers FD00:1234:5678:9ABC::2, FD00:1234:5678:9ABC::3; } # host for each host host soucy-desktop.domain.net { host-identifier option dhcp6.client-id 00:01:00:01:11:ee:71:12:00:1a:a0:da:ba:7f; fixed-address6 FD00:1234:5678:9ABC::A; } I believe the new version of ISC DHCPd has added code to be able to determine the MAC address instead of using a DUID, but I haven't tested it personally. On Thu, Oct 21, 2010 at 3:59 PM, Ray Soucy wrote: > I think you're misunderstanding how DHCPv6 works. ?Don't think of it > like DHCP that you're used to. > > DHCPv6 requires an IPv6 router advertisement to work. ?There are three > flags of interest in a router advertisement. > > One of them is the "A" (autonomous) flag which is enabled by default > in almost every implementation I've seen. ?This is what signals a host > that it is permitted to use stateless configuration with the prefix. > > There are also "M" (managed) and "O" other flags. ?The "M" flag being > set signals the host that it should start a DHCPv6 client and make a > request for an address, the "O" flag signals that the host should ask > for "other" or additional configuration information through DHCPv6 > (e.g. DNS servers). > > None of the flags are exclusive, so you can enable DHCPv6 by setting > the M flag, but unless you disable the A flag, hosts will still use > stateless configuration (in addition to DHCPv6 and receive two > addresses) > > If you want a DHCPv6-only environment, you simply disable the A flag > on the router advertisement. ?This will stop hosts from using > stateless with the advertised prefix. > > The default gateway for the network is learned through the router > advertisement, not through DHCPv6, which is why it doesn't exist in > DHCPv6. > > Example IOS configuration: > > interface Vlan123 > ?description Test IPv6 Network > ?ipv6 address FD00:1234:5678:9ABC::1/64 > ?no ipv6 unreachables > ?ipv6 nd prefix default 2592000 604800 no-autoconfig > ?ipv6 nd managed-config-flag > ?ipv6 nd other-config-flag > ?ipv6 nd router-preference High > ?no ipv6 redirects > ?ipv6 verify unicast source reachable-via rx > ?ipv6 eigrp 123 > ?ipv6 dhcp relay destination FD00:1234:5678:9ABC::2 > ?ipv6 dhcp relay destination FD00:1234:5678:9ABC::3 > > The "ipv6 nd prefix ... no-autoconfig" statement is what you're > looking for. ?You need to type out timers to be able to get to it. > The values shown are just the Cisco defaults. > > > > On Thu, Oct 21, 2010 at 3:43 PM, Luca Tosolini wrote: >> On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote: >> >>> We've decided to disable SLAAC (State-Less Address Auto-Configuration) >>> on almost all our IPv6 networks and use DHCPv6 exclusively. ?This >>> allows us to only respond with DHCPv6 to the hosts we want to get an >>> IPv6 address instead of enabling it network-wide and crossing your >>> fingers. ?The disadvantage here is that DHCPv6 client support is still >>> limited (OS X has none for example). ? The argument is that IPv6 isn't >>> mission critical yet, so we're waiting to see if vendors will come >>> around and include DHCPv6 client support in the future. >>> >> >> Ray, >> how do you convey the default-router information with DHCPv6 only. AFAIK >> there is no such field in DHCPv6... >> >> Luca. >> >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Thu Oct 21 15:43:37 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 16:43:37 -0400 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: <20101020051704.GB27873@vacation.karoshi.com.> References: <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de> <20101020145418.69f12048@opy.nosense.org> <4CBE77BC.2050501@bogus.com> <20101020051704.GB27873@vacation.karoshi.com.> Message-ID: On Wed, Oct 20, 2010 at 1:17 AM, wrote: > ?first - IPv6 isn't 5x IPv4, its only 4x... :) Couldn't let this one slide... Bits grow exponentially. Saying IPv6 is 4x IPv4 isn't really accurate unless you're counting bits. A 128-bit address space gives you over 340 undecillion (3.4 * 10^38) unique values compared to the pathetic 6 billion or so of a 32-bit address space. Certainly more than 4 or 5x ;-) -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From rps at maine.edu Thu Oct 21 15:50:19 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 16:50:19 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <1287690180.2395.48.camel@localhost> Message-ID: And since someone asked me for it off-list, example PACL for IOS to filter RAs and DHCPv6 server traffic on incoming ports: On each switch: ipv6 access-list RA_Guard deny icmp any any router-advertisement deny udp any eq 547 any eq 546 permit any any end And on each switchport: ipv6 traffic-filter RA_Guard in Your mileage may vary. This was written for Catalyst 3560s and 3750s. Obviously you wouldn't apply it on the port your uplink is on. On Thu, Oct 21, 2010 at 4:08 PM, Ray Soucy wrote: > Also, > > Keep in mind that DHCPv6 uses a DUID for host identification and not a > MAC address. > > Here is an example ISC DHCPd configuration for an IPv6 network without > open pool allocation (it will only respond for hosts in the config). > > # subnet6 for each network > subnet6 FD00:1234:5678:9ABC::/64 { option dhcp6.name-servers > FD00:1234:5678:9ABC::2, FD00:1234:5678:9ABC::3; } > > # host for each host > host soucy-desktop.domain.net { host-identifier option dhcp6.client-id > 00:01:00:01:11:ee:71:12:00:1a:a0:da:ba:7f; fixed-address6 > FD00:1234:5678:9ABC::A; } > > I believe the new version of ISC DHCPd has added code to be able to > determine the MAC address instead of using a DUID, but I haven't > tested it personally. > > On Thu, Oct 21, 2010 at 3:59 PM, Ray Soucy wrote: >> I think you're misunderstanding how DHCPv6 works. ?Don't think of it >> like DHCP that you're used to. >> >> DHCPv6 requires an IPv6 router advertisement to work. ?There are three >> flags of interest in a router advertisement. >> >> One of them is the "A" (autonomous) flag which is enabled by default >> in almost every implementation I've seen. ?This is what signals a host >> that it is permitted to use stateless configuration with the prefix. >> >> There are also "M" (managed) and "O" other flags. ?The "M" flag being >> set signals the host that it should start a DHCPv6 client and make a >> request for an address, the "O" flag signals that the host should ask >> for "other" or additional configuration information through DHCPv6 >> (e.g. DNS servers). >> >> None of the flags are exclusive, so you can enable DHCPv6 by setting >> the M flag, but unless you disable the A flag, hosts will still use >> stateless configuration (in addition to DHCPv6 and receive two >> addresses) >> >> If you want a DHCPv6-only environment, you simply disable the A flag >> on the router advertisement. ?This will stop hosts from using >> stateless with the advertised prefix. >> >> The default gateway for the network is learned through the router >> advertisement, not through DHCPv6, which is why it doesn't exist in >> DHCPv6. >> >> Example IOS configuration: >> >> interface Vlan123 >> ?description Test IPv6 Network >> ?ipv6 address FD00:1234:5678:9ABC::1/64 >> ?no ipv6 unreachables >> ?ipv6 nd prefix default 2592000 604800 no-autoconfig >> ?ipv6 nd managed-config-flag >> ?ipv6 nd other-config-flag >> ?ipv6 nd router-preference High >> ?no ipv6 redirects >> ?ipv6 verify unicast source reachable-via rx >> ?ipv6 eigrp 123 >> ?ipv6 dhcp relay destination FD00:1234:5678:9ABC::2 >> ?ipv6 dhcp relay destination FD00:1234:5678:9ABC::3 >> >> The "ipv6 nd prefix ... no-autoconfig" statement is what you're >> looking for. ?You need to type out timers to be able to get to it. >> The values shown are just the Cisco defaults. >> >> >> >> On Thu, Oct 21, 2010 at 3:43 PM, Luca Tosolini wrote: >>> On Thu, 2010-10-21 at 14:19 -0400, Ray Soucy wrote: >>> >>>> We've decided to disable SLAAC (State-Less Address Auto-Configuration) >>>> on almost all our IPv6 networks and use DHCPv6 exclusively. ?This >>>> allows us to only respond with DHCPv6 to the hosts we want to get an >>>> IPv6 address instead of enabling it network-wide and crossing your >>>> fingers. ?The disadvantage here is that DHCPv6 client support is still >>>> limited (OS X has none for example). ? The argument is that IPv6 isn't >>>> mission critical yet, so we're waiting to see if vendors will come >>>> around and include DHCPv6 client support in the future. >>>> >>> >>> Ray, >>> how do you convey the default-router information with DHCPv6 only. AFAIK >>> there is no such field in DHCPv6... >>> >>> Luca. >>> >>> >> >> >> >> -- >> Ray Soucy >> >> Epic Communications Specialist >> >> Phone: +1 (207) 561-3526 >> >> Networkmaine, a Unit of the University of Maine System >> http://www.networkmaine.net/ >> > > > > -- > Ray Soucy > > Epic Communications Specialist > > Phone: +1 (207) 561-3526 > > Networkmaine, a Unit of the University of Maine System > http://www.networkmaine.net/ > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From chrismcc at gmail.com Thu Oct 21 15:53:49 2010 From: chrismcc at gmail.com (Christopher McCrory) Date: Thu, 21 Oct 2010 13:53:49 -0700 Subject: ipv6 vs. LAMP Message-ID: <1287694429.4968.96.camel@wednesday> Hello... I've been following the recent IPv6 threads with interest. I decided to test the M in LAMP for IPv6 support (Although it was really a FreeBSD server not Linux). It seems than only newer versions (5.5 rc) of MySQL support IPv6 network connections. Worse is that although it will accept a network connection via IPv6, the grant tables do not work. To successfully get data out of the database, the grants would have to be open to the world. After a few google searches, it seems that PostgreSQL is in a similar situation. Network operations content: Will "We're running MySQL and Postgress servers that do not support IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or hosting providers? Have any hosting providers network people talked the the DBA people to tell them that they might have a problem soon? With RedHat, CentOS, Ubuntu all shipping databases that will not work correctly with IPv6, I suspect some people are in for a rude awakening next year. Furthermore, why would Oracle want to 'fix' MySQL? It seems to me that for medium to large content providers IPv6 would be great. Have racks and racks of LAMP servers on IPv6, only a few hosts and load balancers would need to be dual stack. But if the database servers must be IPv4 only, then there is zero benefit to add IPv6 anywhere else. note: by LAMP I really mean Linux/FreeBSD/Solaris , Apache/nginx/etc, MySQL/PostgressSQL/etc, and php/perl/python/ruby. And thanks to the FreeBSD people for making 6to4 so easy to setup for initial IPv6 testing. -- Christopher McCrory To the optimist, the glass is half full. To the pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be. From bmanning at vacation.karoshi.com Thu Oct 21 15:55:01 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Thu, 21 Oct 2010 20:55:01 +0000 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de> <20101020145418.69f12048@opy.nosense.org> <4CBE77BC.2050501@bogus.com> <20101020051704.GB27873@vacation.karoshi.com.> Message-ID: <20101021205501.GC4789@vacation.karoshi.com.> On Thu, Oct 21, 2010 at 04:43:37PM -0400, Ray Soucy wrote: > On Wed, Oct 20, 2010 at 1:17 AM, wrote: > > first - IPv6 isn't 5x IPv4, its only 4x... :) > > Couldn't let this one slide... > > Bits grow exponentially. Saying IPv6 is 4x IPv4 isn't really accurate > unless you're counting bits. tada! 128 == 4x32 --bill From bzs at world.std.com Thu Oct 21 15:56:56 2010 From: bzs at world.std.com (Barry Shein) Date: Thu, 21 Oct 2010 16:56:56 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <4CC07DD3.6060400@dcrocker.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> Message-ID: <19648.43288.915332.173143@world.std.com> Well, if the DNS root servers ceased IPv4 service it'd be pretty much a fait accompli as far as the public internet is concerned. And, of course, the RIRs could just cancel all the IPv4 route announcements, whatever they do if someone doesn't pay or whatever. I'm not sure why any would do that since both versions of the protocol can exist on the same wire. -- -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 msa at latt.net Thu Oct 21 16:00:39 2010 From: msa at latt.net (Majdi S. Abbas) Date: Thu, 21 Oct 2010 14:00:39 -0700 Subject: ipv6 vs. LAMP In-Reply-To: <1287694429.4968.96.camel@wednesday> References: <1287694429.4968.96.camel@wednesday> Message-ID: <20101021210038.GA13091@puck.nether.net> On Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote: > Network operations content: > > Will "We're running MySQL and Postgress servers that do not support > IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or > hosting providers? First, it's not like the flag day is tomorrow. And then, I think if you're running SQL over the public Internet, you have bigger problems than whether or not you're going to be able to get v4 addressing and transit. --msa From jbates at brightok.net Thu Oct 21 16:09:57 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Oct 2010 16:09:57 -0500 Subject: ipv6 vs. LAMP In-Reply-To: <1287694429.4968.96.camel@wednesday> References: <1287694429.4968.96.camel@wednesday> Message-ID: <4CC0AC25.50706@brightok.net> On 10/21/2010 3:53 PM, Christopher McCrory wrote: > Network operations content: > > Will "We're running MySQL and Postgress servers that do not support > IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or > hosting providers? > Why not have v4 and v6? There's never a reason to reject v6, only the possible need for v4. That being said, MySQL and Postgres often reside close enough to the node that needs them that they should have v4 connectivity (or run v4 over v6 ipsec tunnels). > Have any hosting providers network people talked the the DBA people to > tell them that they might have a problem soon? > Many hosting providers have db on the same server as the web server until they reach a certain size, in which case it is on a private network behind the content servers and not visible from global routing anyways. > With RedHat, CentOS, Ubuntu all shipping databases that will not work > correctly with IPv6, I suspect some people are in for a rude awakening > next year. Furthermore, why would Oracle want to 'fix' MySQL? > I doubt anyone will notice that matters. > It seems to me that for medium to large content providers IPv6 would be > great. Have racks and racks of LAMP servers on IPv6, only a few hosts > and load balancers would need to be dual stack. But if the database > servers must be IPv4 only, then there is zero benefit to add IPv6 > anywhere else. Only need v4 on the private network behind the content hosts. Even geographically distributed applications don't normally make calls across public net directly to a database. If the database itself isn't distributed, one might consider using vpn's to interconnect the sites, but I believe that is a rarity. Perhaps someone with a larger deployment can enlighten us. Jack From joelja at bogus.com Thu Oct 21 16:12:06 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 21 Oct 2010 14:12:06 -0700 Subject: ipv6 vs. LAMP In-Reply-To: <20101021210038.GA13091@puck.nether.net> References: <1287694429.4968.96.camel@wednesday> <20101021210038.GA13091@puck.nether.net> Message-ID: <4CC0ACA6.8000506@bogus.com> On 10/21/10 2:00 PM, Majdi S. Abbas wrote: > On Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote: >> Network operations content: >> >> Will "We're running MySQL and Postgress servers that do not support >> IPv6" be a valid reason for rejecting IPv6 addresses from ISPs or >> hosting providers? > > First, it's not like the flag day is tomorrow. > > And then, I think if you're running SQL over the public Internet, > you have bigger problems than whether or not you're going to be able > to get v4 addressing and transit. patches were available to do it as early as 2005 the work to do it in and official way was done back in 2008 leading up to the death of mysql6, it was in 5.5beta... > --msa > From wavetossed at googlemail.com Thu Oct 21 16:24:57 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 21 Oct 2010 22:24:57 +0100 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <4CC07DD3.6060400@dcrocker.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> Message-ID: >> How would you respond if that were announced? > >> If I were king for a day, > > But you aren't. ?No one is. > > The core requirement for such announcements is that there be a real > enforcement arm. Not necessarily. If you announce that YOU will treat that date as a sunset date for IPv4 and invite other organizations to sign up for the declaration, you might be able to get a movement going. Alice's Restaurant comes to mind as does the Cluetrain Manifesto. > The best that can be done with respect to declaring a IPv4 sunset date is > localized pockets of such control. > > One could, of course, imagine a federation of such pockets... That is too top down, and sounds too much like the ITU, a federation of governments. I don't think that would work but a voluntary manifesto that people could sign up to would work. --Michael Dillon From franck at genius.com Thu Oct 21 16:31:03 2010 From: franck at genius.com (Franck Martin) Date: Fri, 22 Oct 2010 09:31:03 +1200 (FJT) Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: Message-ID: <30072938.423.1287696660193.JavaMail.franck@franck-martins-macbook-pro.local> Putting a sunset clause will happen but when it won't matter much. We are not there yet. However, I could see it also coming from a vendor as a way to get customers to upgrade (after that date we will not support IPv4 anymore and provide patches for IPv4). ----- Original Message ----- From: "Michael Dillon" To: "NANOG" Sent: Friday, 22 October, 2010 9:24:57 AM Subject: Re: IPv4 sunset date set for 2019-12-31 >> How would you respond if that were announced? > >> If I were king for a day, > > But you aren't. ?No one is. > > The core requirement for such announcements is that there be a real > enforcement arm. Not necessarily. If you announce that YOU will treat that date as a sunset date for IPv4 and invite other organizations to sign up for the declaration, you might be able to get a movement going. Alice's Restaurant comes to mind as does the Cluetrain Manifesto. > The best that can be done with respect to declaring a IPv4 sunset date is > localized pockets of such control. > > One could, of course, imagine a federation of such pockets... That is too top down, and sounds too much like the ITU, a federation of governments. I don't think that would work but a voluntary manifesto that people could sign up to would work. --Michael Dillon From wavetossed at googlemail.com Thu Oct 21 16:31:17 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 21 Oct 2010 22:31:17 +0100 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <20101021175937.GD13414@puck.nether.net> <20101021181930.GD15591@diehard.n-r-g.com> Message-ID: > This doesn't mean IPv4 will disappear. Just like the 20+ year old machines that are still on the net via IPv4 -> legacy protocol gateways, pockets of IPv4 may exist for decades via similar devices -- but at that point, we just dismiss those guys as crackpots. Maybe not quite crackpots, but you are right that a sunset date is really a marketing device, and if done as a manifesto, would gain a lot of publicity. If the manifesto has a clause that allows a signatory to keep running IPv4 for specialist purposes that are not core to the public Internet, then what will happen is that the public will force the sunset to happen. But behind the scenes people will still be using it just as they are still running X.25 networks today, out of the glare of the public eye. For this to work you need a team of sensible people to put some effort into crafting a workable manifesto that network operators would actually be willing to sign. 2019 seems like a date the people could actually commit to, in fact even 2016 may be workable and is perhaps desirable because it will be within the planning horizon of a lot of folks starting next year. --Michael Dillon From bicknell at ufp.org Thu Oct 21 16:43:54 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 21 Oct 2010 14:43:54 -0700 Subject: ipv6 vs. LAMP In-Reply-To: <1287694429.4968.96.camel@wednesday> References: <1287694429.4968.96.camel@wednesday> Message-ID: <20101021214354.GA76784@ussenterprise.ufp.org> In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote: > open to the world. After a few google searches, it seems that > PostgreSQL is in a similar situation. I don't know when PostgreSQL first supported IPv6, but it works just fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres 8.4 port with no changes, and viola: postgresql# netstat -a Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 localhost.postgresql *.* LISTEN tcp6 0 0 localhost.postgresql *.* LISTEN $ psql -h ::1 psql (8.4.4) Type "help" for help. pgsql=# \l List of databases Name | Owner | Encoding | Collation | Ctype | Access privileges -----------+-------+----------+-----------+-------+------------------- pgsql | pgsql | UTF8 | C | C | postgres | pgsql | UTF8 | C | C | template0 | pgsql | UTF8 | C | C | =c/pgsql : pgsql=CTc/pgsql template1 | pgsql | UTF8 | C | C | =c/pgsql : pgsql=CTc/pgsql (4 rows) ~pgsql/data/pg_hba.conf contains: # CIDR-ADDRESS specifies the set of hosts the record matches. # It is made up of an IP address and a CIDR mask that is an integer # (between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that specifies # the number of significant bits in the mask. Alternatively, you can write # an IP address and netmask in separate columns to specify the set of hosts. And later: # "local" is for Unix domain socket connections only local all all trust # IPv4 local connections: host all all 127.0.0.1/32 trust # IPv6 local connections: host all all ::1/128 trust So of your "LAMP" stack, I'm pretty sure all the L's are in good shape (Linux/FreeBSD/NetBSD/etc), the A is in good shape, been working fine for years. Perhaps the M needs some work on the MySQL side, but I'm fairly sure PostgreSQL is solid. I'm not exactly sure how the P would need IPv6 support, but I think it's generally a non-issue there other than updating software that acutally stores IPv4 addresses... -- 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 wavetossed at googlemail.com Thu Oct 21 16:46:50 2010 From: wavetossed at googlemail.com (Michael Dillon) Date: Thu, 21 Oct 2010 22:46:50 +0100 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: References: <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de> <20101020145418.69f12048@opy.nosense.org> <4CBE77BC.2050501@bogus.com> <20101020051704.GB27873@vacation.karoshi.com.> Message-ID: > Couldn't let this one slide... > > Bits grow exponentially. ?Saying IPv6 is 4x IPv4 isn't really accurate > unless you're counting bits. Yep. IPv6 is 128 bits and IPv4 is 32 bits. Lots of folks can get an IPv4 /16 which gives then 16 bits to play with for subnetting. But only network operators can play this game and get this kind of allocation. Switch to IPv6 with its /64 Interface Identifier and every mom and pop can get a /48 which gives them 16 bits to play with for subnetting. In fact, their ISP with a /32 or better, also gets 16 bits for subnetting no matter how small their business. Riches upon riches for everyone to use as they please. We are all oil millionaires with IPv6 and must learn to forget the hardships of living in the dusty dunes of IPv4. There are enough bits for almost everyone to build a network that makes the most sense for their physical topology without worrying about growth, because you can leave space for growth at every level of your addressing architecture. It is only the very largest organizations who still have to be careful not to run out of subnetting bits because they can reasonably expect to justify a /20 today, but require a /18 in 5 years of growth and acquisition. On the other hand, they tend to have better people and already know how to manage IPv6. There is not much that we can teach them in this discussion, but the smaller network operators and enterprise folks would do well to pay attention and shift their thinking out of the IPv4 world and into the abundant world of IPv6. In the IPv4 world, people had to deal with the results of their own mistakes. In the IPv6 world, it will be your grandchildren and great-grandchildren who will have to deal with your mistakes and they will thank you for leaving them some real challenges and not trying to engineer away their choices. --Michael Dillon From dwhite at olp.net Thu Oct 21 16:53:00 2010 From: dwhite at olp.net (Dan White) Date: Thu, 21 Oct 2010 16:53:00 -0500 Subject: ipv6 vs. LAMP In-Reply-To: <20101021214354.GA76784@ussenterprise.ufp.org> References: <1287694429.4968.96.camel@wednesday> <20101021214354.GA76784@ussenterprise.ufp.org> Message-ID: <20101021215259.GS2843@dan.olp.net> On 21/10/10?14:43?-0700, Leo Bicknell wrote: >In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher McCrory wrote: >> open to the world. After a few google searches, it seems that >> PostgreSQL is in a similar situation. > >I don't know when PostgreSQL first supported IPv6, but it works just >fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres >8.4 port with no changes, and viola: All this is pretty moot point if you run a localized copy of your database (mysql or postgres) and connect via unix domains sockets. -- Dan White From brandon.galbraith at gmail.com Thu Oct 21 16:59:52 2010 From: brandon.galbraith at gmail.com (Brandon Galbraith) Date: Thu, 21 Oct 2010 16:59:52 -0500 Subject: ipv6 vs. LAMP In-Reply-To: <20101021215259.GS2843@dan.olp.net> References: <1287694429.4968.96.camel@wednesday> <20101021214354.GA76784@ussenterprise.ufp.org> <20101021215259.GS2843@dan.olp.net> Message-ID: On Thu, Oct 21, 2010 at 4:53 PM, Dan White wrote: > On 21/10/10 14:43 -0700, Leo Bicknell wrote: > >> In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher >> McCrory wrote: >> >>> open to the world. After a few google searches, it seems that >>> PostgreSQL is in a similar situation. >>> >> >> I don't know when PostgreSQL first supported IPv6, but it works just >> fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres >> 8.4 port with no changes, and viola: >> > > All this is pretty moot point if you run a localized copy of your database > (mysql or postgres) and connect via unix domains sockets. > > True. It mostly affects shared/smaller hosting providers who have customers that want direct access to the database remotely over the public network (and don't want to use some local admin tool such as phpMyAdmin). -brandon -- Brandon Galbraith US Voice: 630.492.0464 From sikandar.raman at gmail.com Thu Oct 21 17:05:16 2010 From: sikandar.raman at gmail.com (Ramanpreet Singh) Date: Thu, 21 Oct 2010 15:05:16 -0700 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: <042e01cb7152$f285e7f0$d791b7d0$@net> References: <022801cb706a$ead9d5e0$c08d81a0$@net> <5294CF7C-E618-41E5-ACFB-E299CD25A5E5@beanfield.com> <042e01cb7152$f285e7f0$d791b7d0$@net> Message-ID: I used Extreme 6808 and 6816 in the core and Summit 24's at the edge/telemetry . The hardware was real flaky. We had lot of issues with the Line cards. Lot of H?w replacements. Make sure if they can provide you some statistics of RMA's. To be fair, Our hardware was EOL, I am not sure if they have improved but then we migrated all our equiment in 2008-2009. -Raman On Thu, Oct 21, 2010 at 12:05 PM, Eric Merkel wrote: > Thanks to everyone who responded. Just got done talking with Extreme which > no one really mentioned. Seems like decent gear reasonably priced. Anyone > care to comment on them specifically or have them used them a metro Ethernet > build? > > > ===== > Eric Merkel > MetaLINK Technologies, Inc. > Email: merkel at metalink.net > > > -----Original Message----- > From: Dan Armstrong [mailto:dan at beanfield.com] > Sent: 2010-10-20 19:50 > To: Ramanpreet Singh > Cc: Jason Lixfeld; nanog at nanog.org > Subject: Re: Recommendations for Metro-Ethernet Equipment > > I think that's what Jason just said. :-) > > > > > On 2010-10-20, at 5:24 PM, Ramanpreet Singh wrote: > >> 7600's/ASR 1k >> >> Have you looked in to Ciso ME 3600X/ME 3800X series? >> >> Without a bias these are the top notch products in the market for Metro E. >> >> -Raman >> >> On Wed, Oct 20, 2010 at 12:57 PM, Jason Lixfeld wrote: >>> On 2010-10-20, at 11:24 AM, Eric Merkel wrote: >>> >>>> Any suggestions, success or horror stories are appreciated. ;) >>> >>> I've been going through pretty much the same exercise looking for a > decent PE for almost two years. ?Our requirements were for a PE device that > had between 12-24 ports (in a perfect world, mixed mode 10/100/1000 copper + > SFP), 10G uplinks, EoMPLS, MPLS VPN, DHCP server, port-protect/UNI (or > similar) capabilities, DC power and a small footprint (1RU) >>> >>> Of all the ones we looked at (Juniper, Cisco, Extreme, Brocade, MRV, > Alcatel) initially, MRV was the only contender. ?The rest either didn't have > a product, or their offering didn't meet various points within our criteria. >>> >>> As such, we bought a bunch of MRVs in early 2009 and after four months of > trial and error, we yanked every single one out of the network. ?From a > physical perspective, the box was perfect. ?Port density was perfect, > mixed-mode ports, promised a 10G uplink product soon, size was perfect, > power was perfect, we thought we had it nailed. ?Unfortunately there are no > words to describe how terrible the software was. ?The CLI took a little > getting used to, which is pretty much par for the course when you're dealing > with a new vendor, but the code itself was just absolutely broken, > everywhere. ?Duplex issues, LDP constantly crashing taking the box with it, > OSPF issues, the list went on and on. ?To their credit, they flew engineers > up from the US and they were quite committed to making stuff work, but at > the end of the day, they just couldn't make it go. ?We pulled the plug in > May 2009 and I haven't heard a thing about their product since then, so > maybe they've got it all together. >>> >>> While meeting with Juniper a few months later about a different project, > they said they had a product that might fit our needs. ?The EX4200. ?As > such, we had a few of these loaned to our lab for a few months to put > through their paces, from a features and interoperability perspective. ?They > work[1] and they seem to work well. ?The show stopper was provisioning[1] > and size. ?The box is massive, albeit it is still 1U. >>> >>> [1] (I'm not a Juniper guy, so my recollection on specific terms and > jargon may be a bit off kilter) they only support ccc, which makes > provisioning an absolute nightmare. ?From my experience with Cisco and MRV, > you only have to configure the EoMPLS vc. ?On the EX4200, you have to create > the LSPs as well. ?To get a ccc working, the JunOS code block was far larger > and much more involved per vc than the single line Cisco equivalent. ?To > create the LSPs was, I believe, two more equally large sized code blocks. > At the end of the day, it was just too involved. ?We needed something > simpler. >>> >>> About the same time that we started to evaluate the EX4200, Cisco had > pitched us on their (then alpha) Whales platform. ?It looked promising (MRV > still had the best form factor) and we expressed our interest in getting a > beta unit in as soon as we were able to. ?This is now known as the ME3600 > and ME3800 platform and we've been testing a beta unit in our lab for the > past few months. ?This is the platform we have chosen. ?It's not perfect, > but our gripes have more to do with form factor (it's 1RU, but it's a bit > deeper than what we'd like) and port densities (no mixed mode ports) than > software or features. ?We've been pretty pleased with it's feature set and > performance, but this hasn't seen any real world action, so who knows how > that will turn out. >>> >>> If you're asking more about a P router or P/PE hybrid, we've also just > ordered a few ASR9000s under try-and-buy as P/PEs to close up the chains of > ME3600s that will start to be deployed in our remote sites. ?A Juniper MX > would certainly work well here too, and it seems to interoperate rather well > with the ME3600s, so that's certainly an option, but for us, we think it > will work more in our favor to go with the ASRs in the core, but if not, > we'd ship them back under the try-and-buy and get Junipers instead. >>> >>> Hope that helps. >>> >> > > > > > > From mpetach at netflight.com Thu Oct 21 17:07:38 2010 From: mpetach at netflight.com (Matthew Petach) Date: Thu, 21 Oct 2010 15:07:38 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com> Message-ID: On Thu, Oct 21, 2010 at 12:53 PM, George Bonser wrote: > The first step will be a registrar saying "after this date, we will no > longer issue any IPv4 addresses for whatever reason" and at the same > time, getting very aggressive in reclaiming space from dead entities, > hijackers, etc. ?As time goes by, the amount of v4 space being routed > declines through natural attrition. ?It is a combination of liberal v6 > assignment coupled with aggressive v4 reclamation. Why on earth would a registrar aggressively reclaim space from entities if they're no longer issuing it back out? Are we planning on recommending policies into the ARIN AC that turn ARIN into an IPv4 space reclamation entity, to hoard up v4 addresses? As it now stands, the amount of v4 space being routed will trend towards the asymptote of maximal organizational utilization, and will *not* decline. Any organization that moves resources off v4 and frees up address space will either hold that space as an ongoing resource to be used for future expansions, or will sell it off on the transfer market for short-term cash infusions; the new holders, having paid good cash for it, will have a strong incentive to get it routed and carrying traffic as quickly as possible, to pay back their investment. There is *nothing* in the system driving towards a natural attrition of IPv4 usage, even after runout; we simply change the allocation model from purely needs based, to needs+cash based. Unless ISPs state that they will charge additional money to assign v4 addresses to customers, over what they charge to v6 customers, there is no real pressure in the marketplace for the amount of v4 routing to decline. So long as the end user sees the same cost, and same service for using v4 as v6, there is no pressure towards a v6-only world. So...uh...who's going to be first to step up and tell their customers "look, you get a v6 /56 for free with your account, but if you want v4 addresses, it's going to cost an extra $50/month." ?? Matt From joelja at bogus.com Thu Oct 21 17:06:18 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 21 Oct 2010 15:06:18 -0700 Subject: ipv6 vs. LAMP In-Reply-To: References: <1287694429.4968.96.camel@wednesday> <20101021214354.GA76784@ussenterprise.ufp.org> <20101021215259.GS2843@dan.olp.net> Message-ID: <4CC0B95A.8070003@bogus.com> On 10/21/10 2:59 PM, Brandon Galbraith wrote: > On Thu, Oct 21, 2010 at 4:53 PM, Dan White wrote: > >> On 21/10/10 14:43 -0700, Leo Bicknell wrote: >> >>> In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, Christopher >>> McCrory wrote: >>> >>>> open to the world. After a few google searches, it seems that >>>> PostgreSQL is in a similar situation. >>>> >>> >>> I don't know when PostgreSQL first supported IPv6, but it works just >>> fine. I just fired up a stock FreeBSD 8.1 system and built the Postgres >>> 8.4 port with no changes, and viola: >>> >> >> All this is pretty moot point if you run a localized copy of your database >> (mysql or postgres) and connect via unix domains sockets. >> >> > True. It mostly affects shared/smaller hosting providers who have customers > that want direct access to the database remotely over the public network > (and don't want to use some local admin tool such as phpMyAdmin). linux/unix machines can trivially build ip-tunnels of several flavors. > -brandon > From marka at isc.org Thu Oct 21 17:15:39 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 22 Oct 2010 09:15:39 +1100 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: Your message of "Thu, 21 Oct 2010 00:46:00 PDT." References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <20101021120648.1872981a@opy.nosense.org> Message-ID: <20101021221539.1E52A5F3641@drugs.dv.isc.org> In message , Owen DeLong write s: > >>> > >> Which is part one of the three things that have to happen to make ULA > >> really bad for the internet. > >> > >> Part 2 will be when the first provider accepts a large sum of money to > >> route it within their public network between multiple sites owned by > >> the same customer. > >> > > > > That same customer is also going to have enough global address > > space to be able to reach other global destinations, at least enough > > space for all nodes that are permitted to access the Internet, if not > > more. Proper global address space ensures that if a global destination > > is reachable, then there is a high probability of successfully reaching > > it. The scope of external ULA reachability, regardless of how much > > money is thrown at the problem, isn't going to be as good as proper > > global addresses. > > > _IF_ they implement as intended and as documented. As you've > noted there's a lot of confusion and a lot of people not reading the > documents, latching onto ULA and deciding ti's good. > > It's not a big leap for some company to do a huge ULA deployment > saying "this will never connect to the intarweb thingy" and 5-10 years > later not want to redeploy all their addressing, so, they start throwing > money at getting providers to do what they shouldn't instead of > readdressing their networks. IPv4 think. You don't re-address you add a new address to every node. IPv6 is designed for multiple addresses. > > For private site interconnect, I'd think it more likely that the > > provider would isolate the customers traffic and ULA address space via > > something like a VPN service e.g. MPLS, IPsec. > > > One would hope, but, I bet laziness and misunderstanding trumps > reason and adherence to RFCs over the long term. Since ULA > won't get hard-coded into routers as unroutable (it can't), Actually it can be. You just need a easy switch to turn it off. The router can even work itself out many times. Configure multiple interfaces from the same ULA /48 and you pass traffic for the /48 between those interfaces. You also pass routes for that /48 via those interfaces. > when > people do bad stuff with it, it will work and since it works, they won't > go read the documentation explaining that what works is a bad > idea. > > >> Part 3 will be when that same provider (or some other provider in the > >> same boat) takes the next step and starts trading routes of ULA space > >> with other provider(s). > >> > >> At that point, ULA = GUA without policy = very bad thing (tm). > >> > >> Since feature creep of this form is kind of a given in internet history, > >> I have no reason to believe it won't happen eventually with ULA. > >> > > > > So I'm not sure I can see much benefit would be of paying a > > huge amount of money to have ULA address space put in only a > > limited part/domain of the global route table. The only way to > > have ULA = GUA is to pay everybody on the Internet to carry it, and > > that is assuming that everybody would be willing to accept the money > > in the first place. That'd be far more expensive than just using GUA > > addresses for global reachability. > > > > No... The way it will work is that use of ULA as pseudo-GUA will > spread slowly like cancer through the network. > > When provider A and provider B both have customers throwing lots > of money at them to route their ULA, provider A and provider B will > swallow hard and agree to exchange those routes in both directions. > > I wish I had your confidence in people doing the right thing, but, > there are enough examples of RFC-1918 space in the GRT that > I simply can't share your belief that it won't happen with ULA > which doesn't have the reliability problems that RFC-1918 had. > > Owen > > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From jmaimon at ttec.com Thu Oct 21 17:29:56 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Thu, 21 Oct 2010 18:29:56 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com> Message-ID: <4CC0BEE4.80302@ttec.com> Matthew Petach wrote: > So...uh...who's going to be first to step up and tell their customers > "look, you get a v6 /56 for free with your account, but if you want > v4 addresses, it's going to cost an extra $50/month." ?? > > Matt > Either the telephone company or the cable company. Probably both. Give me a harder one. Joe From joelja at bogus.com Thu Oct 21 17:27:53 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 21 Oct 2010 15:27:53 -0700 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance?= =?windows-1252?Q?_=28Was=3A_IPv6_fc00=3A=3A/7_=97_Unique_loc?= =?windows-1252?Q?al_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> Message-ID: <4CC0BE69.8050207@bogus.com> On 10/21/10 6:02 AM, William Herrin wrote: > On Thu, Oct 21, 2010 at 8:14 AM, Ray Soucy wrote: >> That's assuming ULA would be the primary addressing scheme used. If >> that became the norm, I agree, the extra uniqueness would be >> desirable, perhaps to the point that you should be asking an authority >> for FC00::/8 space to be assigned. But then why wouldn't you just ask >> for a GUA at that point. > > Because you might want space that doesn't route on the Internet so > that if your routes accidentally leak external folks still can't reach > you? Announce your gua and then blackhole it and monitor your prefix. you can tell if you're leaking. it's generally pretty hard to tell if you're leaking rfc 1918 since your advertisement may well work depending on the filters of your peers but not very far. > Regards, > Bill Herrin > > > > > > From jbates at brightok.net Thu Oct 21 17:42:47 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Oct 2010 17:42:47 -0500 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance?= =?windows-1252?Q?_=28Was=3A_IPv6_fc00=3A=3A/7_=97_Unique_loc?= =?windows-1252?Q?al_addresses=29?= In-Reply-To: <4CC0BE69.8050207@bogus.com> References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> Message-ID: <4CC0C1E7.6010104@brightok.net> On 10/21/2010 5:27 PM, Joel Jaeggli wrote: > > Announce your gua and then blackhole it and monitor your prefix. you can > tell if you're leaking. it's generally pretty hard to tell if you're > leaking rfc 1918 since your advertisement may well work depending on the > filters of your peers but not very far. This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone. I personally could understand the fear of wondering if your stateful firewall is properly working and doing it's job and how a simple mistake could have disastrous effects that NAT systems usually don't have. ULA w/ NAT very well may become the norm. Jack From bblackford at gmail.com Thu Oct 21 17:50:24 2010 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 21 Oct 2010 15:50:24 -0700 Subject: A10 Message-ID: Anyone on list have any experience with A10 app performance products? How do they compare with F5, CSS, Netscaler, etc. In particular, stability, throughput, how they handle affinity, stickiness, pools (adding, removing nodes live), load balancing algorithms, SSL accel, reports/stats, etc. Thanks in advance for any input -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From gbonser at seven.com Thu Oct 21 17:51:58 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 15:51:58 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org><4CBFB54B.9010707@zill.net><4CC0553C.8060202@zill.net><20101021153012.GE2843@dan.olp.net><7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv><5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C41D@RWC-EX1.corp.seven.com> > Sent: Thursday, October 21, 2010 3:08 PM > To: George Bonser > Cc: Ben Butler; NANOG > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > On Thu, Oct 21, 2010 at 12:53 PM, George Bonser > wrote: > > The first step will be a registrar saying "after this date, we will > no > > longer issue any IPv4 addresses for whatever reason" and at the same > > time, getting very aggressive in reclaiming space from dead entities, > > hijackers, etc. ?As time goes by, the amount of v4 space being routed > > declines through natural attrition. ?It is a combination of liberal > v6 > > assignment coupled with aggressive v4 reclamation. > > Why on earth would a registrar aggressively reclaim space from > entities if they're no longer issuing it back out? To reduce the pool of available IPs, to reduce the reselling, transfer, hijacking of the space. As the amount of available v4 space declines, it becomes harder to obtain those resources for an operator either refusing to move or not wanting to move. It increases the incentive to move to v6 by making it increasingly difficult to operate in v4. I wouldn't recommend stopping the issuing of v4 space NOW, but maybe 5 years after runout. > Are we planning on recommending policies into the ARIN AC > that turn ARIN into an IPv4 space reclamation entity, to hoard > up v4 addresses? Ok, lets say runout occurs in 2011. Set a date, say 2016 after which ARIN will allocate IPv6 only. The idea isn't to hoard v4 addresses, the idea is to stop the allocation of new blocks. > As it now stands, the amount of v4 space being routed will trend > towards the asymptote of maximal organizational utilization, and will > *not* decline. Any organization that moves resources off v4 and > frees up address space will either hold that space as an ongoing > resource to be used for future expansions, or will sell it off on the > transfer market for short-term cash infusions; the new holders, > having paid good cash for it, will have a strong incentive to get it > routed and carrying traffic as quickly as possible, to pay back > their investment. For a while that is true. But what will the traffic look like 5 years from now? If most of the major user networks are migrated to v6 by that time and most of the major content providers are v6, and the amount of native v4 traffic declines, who is going to want v4 space for anything new? Servicing legacy stuff makes sense but in 2016 who is going to roll out new deployments in v4 space? And ARIN wouldn't be preventing them from doing that, they just wouldn't be able to get the addresses from ARIN. In other words, it would be a PITA to do that and much easier to roll out a new deployment with v6. By continuing to allocate v4 space, they would be enabling the running of v4 forever. > There is *nothing* in the system driving towards a natural attrition > of IPv4 usage, even after runout; we simply change the allocation > model from purely needs based, to needs+cash based. > > Unless ISPs state that they will charge additional money to > assign v4 addresses to customers, over what they charge > to v6 customers, there is no real pressure in the marketplace > for the amount of v4 routing to decline. So long as the end user > sees the same cost, and same service for using v4 as v6, there > is no pressure towards a v6-only world. Maybe. But look at it this way. Imagine 5 years from now a provider notices that only 1% of their traffic in a particular data center is v4. Rather than having to maintain dual-stack configurations on all the gear, they decide to allocate a pair of routers to v4 and go pure native v6 on all their customer facing stuff. Now maybe if the few people still using v4 want it, they can have it by tunneling 4 over 6 to that pair of routers. Now the vast majority of stuff in that provider's network is v6 only with only a couple of internal routers running v4 carrying the tunnels to their users who still use that space. Maybe 5 years after THAT in 2021 the amount of v4 traffic no longer justifies running v4 at all. Customers can still run v4 if they wish by tunneling to a v4 provider someplace else. Maybe even give the customers 5 MORE years to return their PA blocks, so now we are at 15 years from runout, the provider has reclaimed all their v4 space from their customers and returns it (maybe they have returned portions of that space before then) to ARIN and the provider no longer offers v4 services. So I wasn't talking about doing such a thing immediately, I had more of a phased approach in mind. 5 years from runout, ARIN stops issuing IPs. Within 10 years of runout, providers begin to shrink their v4 support, possibly tunneling the traffic to a single pair of routers in their network, 15 years after runout, most providers can't be bothered with v4 support but if you absolutely have to have it, someone can get it to you over a tunnel from someplace. 20 years from runout most providers have reclaimed all their PA space and have returned it to ARIN. > So...uh...who's going to be first to step up and tell their customers > "look, you get a v6 /56 for free with your account, but if you want > v4 addresses, it's going to cost an extra $50/month." ?? I wasn't talking about PA space allocated to a provider who in turn allocates that to customers. Providers could still issue/reclaim their own space as they wish. At some point, though, the tiny amount of traffic in that space begins to make it hard to justify having full v4 BGP tables at so many places. When the traffic dies to the point where all the provider's v4 traffic can be handled on a single pair of routers, it probably will be which will free up resources on the rest of the routers running native v6. From marka at isc.org Thu Oct 21 17:52:02 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 22 Oct 2010 09:52:02 +1100 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: Your message of "Thu, 21 Oct 2010 01:46:55 PDT." <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> Message-ID: <20101021225202.CE2205F376D@drugs.dv.isc.org> In message <859028C2-9ED9-43FF-AAF9-6E2574048016 at delong.com>, Owen DeLong write s: > > On Oct 20, 2010, at 10:28 PM, Mark Andrews wrote: > > >=20 > > In message <4CBFC1D0.60808 at apolix.co.za>, Graham Beneke writes: > >> On 21/10/2010 02:41, Owen DeLong wrote: > >>> On Oct 20, 2010, at 5:21 PM, Jeroen van Aart wrote: > >>>> Someone advised me to use GUA instead of ULA. But since for my = > purposes th > >> is is used for an IPv6 LAN would ULA not be the better choice? > >>>>=20 > >>> IMHO, no. There's no disadvantage to using GUA and I personally = > don't think > >> ULA really serves a purpose. If you want to later connect this > >>> LAN to the internet or something that connects to something that = > connects t > >> o something that connects to the internet or whatever, GUA provides > >>> the following advantages: > >>> + Guaranteed uniqueness (not just statistically probable = > uniquene > >> ss) > >>> + You can route it if you later desire to > >>>=20 > >>> Since ULA offers no real advantages, I don't really see the point. > >>=20 > >> Someone insisted to me yesterday the RFC1918-like address space was = > the=20 > >> only way to provide a 'friendly' place for people to start their = > journey=20 > >> in playing with IPv6. I think that the idea of real routable IPs on a=20= > > >> lab network daunts many people. > >>=20 > >> I've been down the road with ULA a few years back and I have to agree=20= > > >> with Owen - rather just do it on GUA. > >=20 > > Your throwing the baby out with the bath water here. > >=20 > > ULA, by itself, is a painful especially when you have global IPv4 > > reachability as you end up with lots of timeouts. This is similar > > to have a bad 6to4 upsteam link. Just don't go there. > >=20 > > ULA + PA works and provides stable internal addresses when your > > upstream link in down the same way as RFC 1918 provides stable > > internal addressing for IPv4 when your upstream link is down. > >=20 > I keep hearing this and it never makes sense to me. > > If your provider will assign you a static /48, then, you have stable > addresses when your provider link is down in GUA. Who needs ULA? You used the word "if". Reverse the sense of the "if" and see if it still doesn't makes sense to use ULA addresses. I get a mostly stable IPv4 address from my cable provider (DHCP). That address changes without notice about once a year. I can configure a 6to4 prefix based on that address (effectively a PA prefix). I use ULA addresses internally and 6to4 (PA) externally. Same for 6rd. Same for PD. DHCP derived 6to4, DHCP derived 6rd, DHCP derived Terado and PD all give you leased prefixes. They are not guarenteed to be STABLE. For internal communication you really do want stable prefixes. ULA gives you those stable prefixes. > > You talk to the world using PA addresses, directly for IPv6 and > > indirectly via PNAT for IPv4. These can change over time. > >=20 > Or, if you don't want your IPv6 addresses to change over time, you can > get a prefix from your friendly RIR. You really think I'm going to go to my RIR and get a addresses block for my home network then my cable provider will route it for me? > > Similarly, ULA + 6to4 works well provided the 6to4 works when you > > are connected. When your IPv4 connection is renumbered you have a > > new external addresses but the internal addresses stay the same. > >=20 > That's a big "provided that"... Not really. It works for lots of people. > One over which you have little or no control unless you are running > a 6to4 gateway of your own and can guarantee that nobody pretends > to be one that is topologically closer to any of your users. > > >> I was adding IPv6 to a fairly large experimental network and started=20= > > >> using ULA. The local NREN then invited me to peer with them but I=20 > >> couldn't announce my ULA to them. They are running a 'public = > Internet'=20 > >> network and have a backbone that will just filter them. > >>=20 > >> I think that the biggest thing that trips people up is that they = > think=20 > >> that they'll just fix-it-with-NAT to get onto the GUA Internet. = > Getting=20 > >> your own GUA from an RIR isn't tough - rather just do it. > >=20 > > If your big enough to get your own GUA and have the dollars to get > > it routed then do that. If you are forced to use PA (think home > > networks) then having a ULA prefix as well is a good thing. > >=20 > home network: 2620:0:930::/48 > > Try again. And you expect the routing system to cope when 2 billion homes do the same thing? > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joe at nethead.com Thu Oct 21 17:52:18 2010 From: joe at nethead.com (Joe Hamelin) Date: Thu, 21 Oct 2010 15:52:18 -0700 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance_=28Was=3A_IPv6_fc00=3A=3A=2F?= =?windows-1252?Q?7_=97_Unique_local_addresses=29?= In-Reply-To: <4CC0C1E7.6010104@brightok.net> References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> Message-ID: Ray said: ".. But then why wouldn't you just ask for a GUA at that point." What's the cost for a /48 GUA from ARIN these days? Why pay for something that you're not going to "use"? I agree with you but as long as the RIRs charge for integers people will make up their own if they can find a way. If a small shop guy is looking at ether paying for GUA space or affording a more expensive switch that will do SNMP, he's going to get the switch. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From gbonser at seven.com Thu Oct 21 17:56:15 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 15:56:15 -0700 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: <20101021221539.1E52A5F3641@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net><20101021093109.06a50ea2@opy.nosense.org><20101021105901.7f708b16@opy.nosense.org><585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com><20101021120648.1872981a@opy.nosense.org> <20101021221539.1E52A5F3641@drugs.dv.isc.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C41E@RWC-EX1.corp.seven.com> > Sent: Thursday, October 21, 2010 3:16 PM > To: Owen DeLong > Cc: NANOG list > Subject: Re: Re: IPv6 fc00::/7 - Unique local addresses > > IPv4 think. > > You don't re-address you add a new address to every node. IPv6 is > designed for multiple addresses. > How does your application on the host decide which address to use when sourcing an outbound connection if you have two different subnets that are globally routable? From kauer at biplane.com.au Thu Oct 21 17:59:34 2010 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 22 Oct 2010 09:59:34 +1100 Subject: IPv6 fc00::/7 =?UTF-8?Q?=E2=80=94?= Unique local addresses In-Reply-To: <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> Message-ID: <1287701974.10216.63.camel@karl> On Thu, 2010-10-21 at 01:46 -0700, Owen DeLong wrote: > > If your big enough to get your own GUA and have the dollars to get > > it routed then do that. If you are forced to use PA (think home > > networks) then having a ULA prefix as well is a good thing. > > > home network: 2620:0:930::/48 In Oz it costs real money to get IPv6 address space from the RIR (APNIC). Around AUD$6K in the first year, around AUD$1100 each year thereafter. Your /48, according to the ARIN website, cost you US$625 this year, will cost US$937.50 next year, and $1250 every year thereafter. Fairly trivial amounts for most commercial entities, but prohibitive for all but the most enthusiastic home user. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF 1 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jbates at brightok.net Thu Oct 21 18:05:13 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Oct 2010 18:05:13 -0500 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C41E@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net><20101021093109.06a50ea2@opy.nosense.org><20101021105901.7f708b16@opy.nosense.org><585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com><20101021120648.1872981a@opy.nosense.org> <20101021221539.1E52A5F3641@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0B14C41E@RWC-EX1.corp.seven.com> Message-ID: <4CC0C729.5090300@brightok.net> On 10/21/2010 5:56 PM, George Bonser wrote: > > How does your application on the host decide which address to use when > sourcing an outbound connection if you have two different subnets that > are globally routable? > Many systems generally will go with the closest source address bitwise to the destination address. Not perfect, but works. This assumes that the source addresses are equal on other metrics. Jack From Skeeve at eintellego.net Thu Oct 21 18:10:29 2010 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Fri, 22 Oct 2010 10:10:29 +1100 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: <1287701974.10216.63.camel@karl> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <1287701974.10216.63.camel@karl> Message-ID: <292AF25E62B8894C921B893B53A19D9739AF595C7D@BUSINESSEX.business.ad> Karl, Where does the 6K come from? AUD$4,175 is the amount - It consists of the "Associate Member Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500) Then AUD1180 for a /48 each year. ...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 www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Arista - > -----Original Message----- > From: Karl Auer [mailto:kauer at biplane.com.au] > Sent: Friday, 22 October 2010 10:00 AM > To: nanog at nanog.org > Subject: Re: IPv6 fc00::/7 - Unique local addresses > > On Thu, 2010-10-21 at 01:46 -0700, Owen DeLong wrote: > > > If your big enough to get your own GUA and have the dollars to get > > > it routed then do that. If you are forced to use PA (think home > > > networks) then having a ULA prefix as well is a good thing. > > > > > home network: 2620:0:930::/48 > > In Oz it costs real money to get IPv6 address space from the RIR > (APNIC). Around AUD$6K in the first year, around AUD$1100 each year > thereafter. > > Your /48, according to the ARIN website, cost you US$625 this year, will > cost US$937.50 next year, and $1250 every year thereafter. > > Fairly trivial amounts for most commercial entities, but prohibitive for > all but the most enthusiastic home user. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF > 1 From brandon.kim at brandontek.com Thu Oct 21 18:44:01 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Thu, 21 Oct 2010 19:44:01 -0400 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: <042e01cb7152$f285e7f0$d791b7d0$@net> References: <022801cb706a$ead9d5e0$c08d81a0$@net> , <5294CF7C-E618-41E5-ACFB-E299CD25A5E5@beanfield.com>, <042e01cb7152$f285e7f0$d791b7d0$@net> Message-ID: We use quite a bit of extreme switches. I personally don't have anything against them other than their purple color and that I don't really know their IOS that well. But to be fair, they have worked just fine..... In the future I hope we can migrate over to cisco switches because I'm bias..... =) > From: merkel at metalink.net > To: nanog at nanog.org > Subject: RE: Recommendations for Metro-Ethernet Equipment > Date: Thu, 21 Oct 2010 15:05:37 -0400 > > Thanks to everyone who responded. Just got done talking with Extreme which > no one really mentioned. Seems like decent gear reasonably priced. Anyone > care to comment on them specifically or have them used them a metro Ethernet > build? > > > ===== > Eric Merkel > MetaLINK Technologies, Inc. > Email: merkel at metalink.net > > > -----Original Message----- > From: Dan Armstrong [mailto:dan at beanfield.com] > Sent: 2010-10-20 19:50 > To: Ramanpreet Singh > Cc: Jason Lixfeld; nanog at nanog.org > Subject: Re: Recommendations for Metro-Ethernet Equipment > > I think that's what Jason just said. :-) > > > > > On 2010-10-20, at 5:24 PM, Ramanpreet Singh wrote: > > > 7600's/ASR 1k > > > > Have you looked in to Ciso ME 3600X/ME 3800X series? > > > > Without a bias these are the top notch products in the market for Metro E. > > > > -Raman > > > > On Wed, Oct 20, 2010 at 12:57 PM, Jason Lixfeld wrote: > >> On 2010-10-20, at 11:24 AM, Eric Merkel wrote: > >> > >>> Any suggestions, success or horror stories are appreciated. ;) > >> > >> I've been going through pretty much the same exercise looking for a > decent PE for almost two years. Our requirements were for a PE device that > had between 12-24 ports (in a perfect world, mixed mode 10/100/1000 copper + > SFP), 10G uplinks, EoMPLS, MPLS VPN, DHCP server, port-protect/UNI (or > similar) capabilities, DC power and a small footprint (1RU) > >> > >> Of all the ones we looked at (Juniper, Cisco, Extreme, Brocade, MRV, > Alcatel) initially, MRV was the only contender. The rest either didn't have > a product, or their offering didn't meet various points within our criteria. > >> > >> As such, we bought a bunch of MRVs in early 2009 and after four months of > trial and error, we yanked every single one out of the network. From a > physical perspective, the box was perfect. Port density was perfect, > mixed-mode ports, promised a 10G uplink product soon, size was perfect, > power was perfect, we thought we had it nailed. Unfortunately there are no > words to describe how terrible the software was. The CLI took a little > getting used to, which is pretty much par for the course when you're dealing > with a new vendor, but the code itself was just absolutely broken, > everywhere. Duplex issues, LDP constantly crashing taking the box with it, > OSPF issues, the list went on and on. To their credit, they flew engineers > up from the US and they were quite committed to making stuff work, but at > the end of the day, they just couldn't make it go. We pulled the plug in > May 2009 and I haven't heard a thing about their product since then, so > maybe they've got it all together. > >> > >> While meeting with Juniper a few months later about a different project, > they said they had a product that might fit our needs. The EX4200. As > such, we had a few of these loaned to our lab for a few months to put > through their paces, from a features and interoperability perspective. They > work[1] and they seem to work well. The show stopper was provisioning[1] > and size. The box is massive, albeit it is still 1U. > >> > >> [1] (I'm not a Juniper guy, so my recollection on specific terms and > jargon may be a bit off kilter) they only support ccc, which makes > provisioning an absolute nightmare. From my experience with Cisco and MRV, > you only have to configure the EoMPLS vc. On the EX4200, you have to create > the LSPs as well. To get a ccc working, the JunOS code block was far larger > and much more involved per vc than the single line Cisco equivalent. To > create the LSPs was, I believe, two more equally large sized code blocks. > At the end of the day, it was just too involved. We needed something > simpler. > >> > >> About the same time that we started to evaluate the EX4200, Cisco had > pitched us on their (then alpha) Whales platform. It looked promising (MRV > still had the best form factor) and we expressed our interest in getting a > beta unit in as soon as we were able to. This is now known as the ME3600 > and ME3800 platform and we've been testing a beta unit in our lab for the > past few months. This is the platform we have chosen. It's not perfect, > but our gripes have more to do with form factor (it's 1RU, but it's a bit > deeper than what we'd like) and port densities (no mixed mode ports) than > software or features. We've been pretty pleased with it's feature set and > performance, but this hasn't seen any real world action, so who knows how > that will turn out. > >> > >> If you're asking more about a P router or P/PE hybrid, we've also just > ordered a few ASR9000s under try-and-buy as P/PEs to close up the chains of > ME3600s that will start to be deployed in our remote sites. A Juniper MX > would certainly work well here too, and it seems to interoperate rather well > with the ME3600s, so that's certainly an option, but for us, we think it > will work more in our favor to go with the ASRs in the core, but if not, > we'd ship them back under the try-and-buy and get Junipers instead. > >> > >> Hope that helps. > >> > > > > > > > From kauer at biplane.com.au Thu Oct 21 18:48:05 2010 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 22 Oct 2010 10:48:05 +1100 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: <292AF25E62B8894C921B893B53A19D9739AF595C7D@BUSINESSEX.business.ad> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <1287701974.10216.63.camel@karl> <292AF25E62B8894C921B893B53A19D9739AF595C7D@BUSINESSEX.business.ad> Message-ID: <1287704885.10216.90.camel@karl> On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote: > Where does the 6K come from? > > AUD$4,175 is the amount - It consists of the "Associate Member > Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500) > > Then AUD1180 for a /48 each year. Er - apologies. Yes, the initial fee covers the first year's annual fee, so it's $4175 in the first year ans $1100 in subsequent years. The point still stands though - that's WAY too much for home users. While for Owen such costs might be doable, for the vast majority of home users in the AP region the only viable alternatives for internal addressing will be PA or ULA. Even with the lower costs that ARIN users pay, the prices are still IMHO too high for home users to be using PI in any significant numbers. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Thu Oct 21 18:43:02 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 16:43:02 -0700 Subject: =?windows-1252?Q?Re:_Why_ULA:_low_collision_chance_=28Was:_IPv6_?= =?windows-1252?Q?fc00::/7_=97_Unique_local_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> Message-ID: <6E5DB83F-ABB2-4E11-A4D0-06E456F879AC@delong.com> On Oct 21, 2010, at 6:02 AM, William Herrin wrote: > On Thu, Oct 21, 2010 at 8:14 AM, Ray Soucy wrote: >> That's assuming ULA would be the primary addressing scheme used. If >> that became the norm, I agree, the extra uniqueness would be >> desirable, perhaps to the point that you should be asking an authority >> for FC00::/8 space to be assigned. But then why wouldn't you just ask >> for a GUA at that point. > > Because you might want space that doesn't route on the Internet so > that if your routes accidentally leak external folks still can't reach > you? > That is, at best, a false sense of security which is worse than no security. Owen From owen at delong.com Thu Oct 21 18:57:59 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 16:57:59 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC05BBF.1010009@zill.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <4CC0575A.4030305@unfix.org> <4CC05BBF.1010009@zill.net> Message-ID: <592B76BF-EB49-463E-AF3B-C9C2F937606C@delong.com> On Oct 21, 2010, at 8:26 AM, Patrick Giagnocavo wrote: > On 10/21/2010 11:08 AM, Jeroen Massar wrote: >>> On 2010-10-21 16:59, Patrick Giagnocavo wrote: >>> Are IPv6 connected machines unable to access IPv4 addresses? >> >> Unless you put a application/protocol translation in the middle IPv6 >> can't talk to IPv4. yahoo("IVI","Ecdysis NAT64") for two possibilities >> one have for that, oh and yahoo("IPv6Gate") for a ready-to-use HTTP >> specific one. >> >> But if you didn't know that fact, you might want to invest in a proper >> book about IPv6 and read up quite a bit. As this is NANOG, a good >> operational book is "Running IPv6". >> > > Thank you for the book recommendation; however, I was trying to get an > admission that any IPv6-connected end users or corporate connections, > will be accessing IPv4-only resources for a long time to come, i.e. > years and years. > > And that the responsibility for IPv6 to v4 connection won't have to be > handled by my client with a few racks. > Noone can confirm that for you because it is largely untrue. IPv6-connected end users MAY have some ability to reach your IPv4-only site. This will be through something that looks like a LSN device at best so you won't have working things like: Geolocation UPNP reverse connection mapping Most forms of NAT-T Most forms of P2P Logs that represent unique IP addresses visiting your site in a meaningful manner. etc. Owen From owen at delong.com Thu Oct 21 18:55:14 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 16:55:14 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> Message-ID: <4E59C25B-0C7A-4EC9-AC64-4A8CAE1D2DFF@delong.com> As long as there are IPv4 clients, you need IPv4 servers to serve them. Software written (well) for IPv6 can serve both IPv4 and IPv6 from the same socket, so long as you set the socket option IPV6_V6ONLY correctly (default except for errant BSD code), but, the machine needs to have a working IPv4 address to do this. In its natural state, IPv4 and IPv6 cannot talk to each other. They are separate protocols just as IP and IPX and Appletalk are separate. (ignoring the IPX/Appletalk over IP things for the time being). There are some ways to build some translation facilities, but, it's not trivial and there are no translation facilities that work even in all the same cases that NAT44 currently works. If you want to talk to both IPv4 and IPv6, you'll need dual stack. Thus, we should dual-stack as much of the existing infrastructure before IPv4 runout as possible and dual stack the rest as quickly as possible thereafter. After runout, all new stuff will be effectively IPv6 only, or, IPv6 with very degraded IPv4 capabilities. If you're stuff needs reachability with those new IPv6 only members of the internet (both clients and servers, although clients will dominate the numbers initially), then, you really need dual stack. Owen On Oct 21, 2010, at 8:07 AM, Ben Butler wrote: > Hi, > > Showing my ignorance here, but this is one of the things I have wondered, given that we run both v4 and v6 for a period of time on the Internet, presumably at one time or another a particular resource may only be able in v4 land, then v4 and v6, then finally v6 only. > > I have never been particularly clear how an end network that exists only in v4 or v6 address space is able to access a resource that only exists in the other. Is can sort of see some freaking huge NAT box type thing that summarizes v6 in a v4 address scope or contains the v4 address range at some point inside the v6 address space - but how can a v4 host get to a hot in v6 world that sits outside this without going through some form of proxy / nat gateway between the two. > > Or are the two simply not inter-communicable? > > Ben > > -----Original Message----- > From: Patrick Giagnocavo [mailto:patrick at zill.net] > Sent: 21 October 2010 15:59 > To: Owen DeLong; NANOG > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > On 10/21/2010 4:28 AM, Owen DeLong wrote: > >>> Actually for those of my clients in one location, it served as an >>> impetus to extend a contract with Level3 for another 3 years - with >>> their existing allocation of a /24 of IPv4 addresses included. >> >> All well and good until some of their customers are on IPv6... >> Then what? > > I'm sorry, can you expand on exactly what you mean by this? > > Are IPv6 connected machines unable to access IPv4 addresses? > > Or is this more IPV6 fanboi-ism? > > --Patrick > > > > > -------------------------------------------------------------------------- > BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} > Ben Butler > Director Tel: 0333 666 3332 > Fax: 0333 666 3331 > C2 Business Networking Ltd > The Paddock, London Road, Nantwich, Cheshire, CW5 7JL > http://www.c2internet.net/ > > Part of the Atlas Business Group of Companies plc > Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 > This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. > > > From sparctacus at gmail.com Thu Oct 21 19:03:51 2010 From: sparctacus at gmail.com (Bryan Irvine) Date: Thu, 21 Oct 2010 17:03:51 -0700 Subject: Only 5x IPv4 ... WRONG! :) In-Reply-To: References: <20101018153551.GA28093@nudo.bsws.de> <5A6D953473350C4B9995546AFE9939EE0B14C35C@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C361@RWC-EX1.corp.seven.com> <84764.1287438364@localhost> <87iq0yqu6h.fsf@oban.berlin.quux.de> <80879.1287493941@localhost> <877hhehqxp.fsf@oban.berlin.quux.de> <20101020145418.69f12048@opy.nosense.org> <4CBE77BC.2050501@bogus.com> <20101020051704.GB27873@vacation.karoshi.com.> Message-ID: > In the IPv4 world, people had to deal with the results of their own > mistakes. In the IPv6 world, it will be your grandchildren and > great-grandchildren who will have to deal with your mistakes and they > will thank you for leaving them some real challenges and not trying to > engineer away their choices. Nah, they'll be routing their packets over facebook. http://tools.ietf.org/html/rfc5514 -B From bill at herrin.us Thu Oct 21 19:09:16 2010 From: bill at herrin.us (William Herrin) Date: Thu, 21 Oct 2010 20:09:16 -0400 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance_=28Was=3A_IPv6_fc00=3A=3A=2F?= =?windows-1252?Q?7_=97_Unique_local_addresses=29?= In-Reply-To: <4CC0BE69.8050207@bogus.com> References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> Message-ID: On Thu, Oct 21, 2010 at 6:27 PM, Joel Jaeggli wrote: > On 10/21/10 6:02 AM, William Herrin wrote: >> On Thu, Oct 21, 2010 at 8:14 AM, Ray Soucy wrote: >>> That's assuming ULA would be the primary addressing scheme used. ?If >>> that became the norm, I agree, the extra uniqueness would be >>> desirable, perhaps to the point that you should be asking an authority >>> for FC00::/8 space to be assigned. ?But then why wouldn't you just ask >>> for a GUA at that point. >> >> Because you might want space that doesn't route on the Internet so >> that if your routes accidentally leak external folks still can't reach >> you? > > Announce your gua and then blackhole it and monitor your prefix. you can > tell if you're leaking. it's generally pretty hard to tell if you're > leaking rfc 1918 since your advertisement may well work depending on the > filters of your peers but not very far. Joel, I have a condensate overflow pan under my computer room air conditioner that collects water if it leaks. I also have an alarm that alerts me if there's a leak and careful maintenance to prevent it from leaking in the first place. But I still have the pan. Even though a leak could fill the pan and overflow, I insist on having a pan there to try to catch the water. How many guesses do you need to figure out why? Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From Skeeve at eintellego.net Thu Oct 21 19:14:48 2010 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Fri, 22 Oct 2010 11:14:48 +1100 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: <1287704885.10216.90.camel@karl> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <1287701974.10216.63.camel@karl> <292AF25E62B8894C921B893B53A19D9739AF595C7D@BUSINESSEX.business.ad> <1287704885.10216.90.camel@karl> Message-ID: <292AF25E62B8894C921B893B53A19D9739AF595C88@BUSINESSEX.business.ad> Small correction - there is no annual fee in the first year ;-) But I agree.. it is too much, and APNIC have been reviewing the Initial allocation fee for a while now, but haven't made any move on it. I'd like to see a new class of membership - 'Individual' which had a small allocation (well, in comparison) and had a cheaper membership level and was not required to be multi-homed, but was portable - and a small, if any initial allocation fee. ...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 www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Arista - > -----Original Message----- > From: Karl Auer [mailto:kauer at biplane.com.au] > Sent: Friday, 22 October 2010 10:48 AM > To: nanog at nanog.org > Subject: RE: IPv6 fc00::/7 - Unique local addresses > > On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote: > > Where does the 6K come from? > > > > AUD$4,175 is the amount - It consists of the "Associate Member > > Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500) > > > > Then AUD1180 for a /48 each year. > > Er - apologies. Yes, the initial fee covers the first year's annual fee, > so it's $4175 in the first year ans $1100 in subsequent years. > > The point still stands though - that's WAY too much for home users. > > While for Owen such costs might be doable, for the vast majority of home > users in the AP region the only viable alternatives for internal > addressing will be PA or ULA. > > Even with the lower costs that ARIN users pay, the prices are still IMHO > too high for home users to be using PI in any significant numbers. > > Regards, K. > > -- > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) > http://www.biplane.com.au/kauer/ +61-428-957160 (mob) > > GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 > Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF From owen at delong.com Thu Oct 21 19:17:17 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 17:17:17 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <4CBF9C42.3050608@matthew.at> <4CBFC3C9.706@apolix.co.za> Message-ID: On Oct 21, 2010, at 9:34 AM, Brandon Ross wrote: > On Thu, 21 Oct 2010, Graham Beneke wrote: > >> On 21/10/2010 03:49, Matthew Kaufman wrote: >>> On 10/20/2010 5:51 PM, Owen DeLong wrote: >>>> Part 2 will be when the first provider accepts a large sum of money to >>>> route it within their public network between multiple sites owned by >>>> the same customer. >>> Is this happening now with RFC 1918 addresses and IPv4? >> >> I have seen this in some small providers. Doesn't last long since the chance of collision is high. It then becomes a VPN. > > I know for a fact that an extremely large tier 1 routed RFC1918 address space for an extremely large cable company at one time (and no, I don't mean 2547 or anything like that). I have no idea if this is still occurring, but when this very large cable company needed to use more private addresses they actually would ask the tier 1 for an assignment in order to avoid collision. > > I don't see the problem with ULA though, sure, someone will route it, but not everyone, just those getting paid to. It's actually the perfect solution to routing table bloat as there is a financial relationship between the parties that announce space and the networks that carry it. > Only until there are two parties getting paid by two other parties to route it and they agree to exchange those routes without compensation in order to benefit their mutual customers who want to reach each other. From there, the problem mushrooms rapidly. Owen From owen at delong.com Thu Oct 21 19:15:50 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 17:15:50 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: On Oct 21, 2010, at 9:29 AM, Allen Smith wrote: > Hi All, > > I've inherited a small network with a couple of Internet connections through > different providers, I'll call them Slow and Fast. > > We use RFC 1918 space internally and have a pair of external firewalls that > handle NAT and such. > > Due to internal policy (read money), some users default to the Slow > connection and some default to Fast. Using probes and policy routing, a > failure of one of the ISPs is generally transparent, outside of the usual > session resets for things like ssh or remote control sessions). > > Looking forward to the next 12 months, we may have clients that are living > in IPv6 space. Our ISPs are happy to give us IPv6 allocations and our > network gear vendors either have GA IPv6 code now or will soon. > > We have been somewhat spoiled by our firewall/NAT boxes, the stuff just > works for our needs and the combination of NAT and policy routing keeps > people on the circuits they are paying for. Am trying to decide how I would > implement this kind of policy in the new world of globally > trackable^H^H^H^H^H^H^H routable IPs for my desktops. Solutions seem to be: > My suggestion: 1. Get a /48 from your friendly neighborhood RIR. 2. Get an ASN to go with it. 3. Accept that your inbound is going to get topologically divided between the two links rather than customer-specific. If that's not an option, then: 1. Get /48s from both providers. 2. Provide appropriate RAs to your users so that the users that should prefer provider SLOW get RAs with a higher preference to provider SLOW and the users that should prefer provider FAST get RAs with a higher preference for provider FAST. 3. Update your probes/policy routing scripts so that they will deprecate the broken RA (you can do this by sending a poisoned final RA with a very short valid time to the all hosts multicast address of each subnet). Option 3 is a very bad idea and I hope your vendor would refuse. Owen > 1) Purchase some BGP capable routers, grab PI space. Here I can obv choose > outbound path, but we are typical in that our inbound to outbound is 6 or 7 > to 1. > > 2) Assign PA space from the ISPs to the appropriate devices. What do I do > when I loose a provider? > > 3) Make loud noises to my firewall vendor to include equivalent NAT/ISP > failover functionality (even 6to6 NAT would be fine). > > Anyway, another sample of 1, but I do work for a managed services provider > and see many small orgs facing similary choices. I personally am happy to > use globally routable addresses and will work through the privacy and > perceived security implications of NAT/nonat, I just want the same ease of > use and flexibility I have today in a SMB environment. > > Cheers, > -Allen From owen at delong.com Thu Oct 21 19:18:50 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 17:18:50 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> Message-ID: <8FA09953-A986-4ECD-A5D7-5DB61721C070@delong.com> I think what you will see is ever increasing fees for IPv4 transit rather than a hard deprecation date. As IPv4 becomes more expensive than IPv6, people will migrate to save money. Owen On Oct 21, 2010, at 9:34 AM, Ben Butler wrote: > Hi, > > I can live with running dual stack for a number of years as long as IPv4 has a turn off date, much like analogue TV services, thus putting onus of responsibility onto the customer to also have a vested interest in migrating from v4 to v6. If there is no end data - then all the service providers are going to get stuck running dual stack and providing 4to6 and 6to4 gateways to bridge traffic to the pool of established v4 only customers. Presumably the evil that is NAT will have to be run on these gateways meaning we have to endure yet more decades of many applications being undeployable for practical purposes as stun cant fix everything in the mish mash of different NAT implementations. > > The problem is there is no commercial incentive for the v4 customer to want to move to v6 and there is no way for the ISP to force them to without loosing the customer. However, if the RIRs or IANA turned around and said as of xxxx date we are revoking all ipv4 allocations. Then we might be able to transition to a v6 only network in some decent timeframe without ending up going down the road of a broken dual level 4/6 half way in between broken internet for the next 25 years. > > You either cross the bridge and get to the other side, or you tell all the people waiting to cross they are too late and tough luck but we have run out and you cant join the party, but the last thing we want to do is get half way across the bridge and need to straddle both sides of the river. > > My 2c. > > Ben > > -----Original Message----- > From: Dan White [mailto:dwhite at olp.net] > Sent: 21 October 2010 16:30 > To: Ben Butler > Cc: 'Patrick Giagnocavo'; Owen DeLong; NANOG > Subject: Re: Only 5x IPv4 /8 remaining at IANA > > On 21/10/10 16:07 +0100, Ben Butler wrote: >> Hi, >> >> Showing my ignorance here, but this is one of the things I have wondered, >> given that we run both v4 and v6 for a period of time on the Internet, >> presumably at one time or another a particular resource may only be able >> in v4 land, then v4 and v6, then finally v6 only. >> >> I have never been particularly clear how an end network that exists only >> in v4 or v6 address space is able to access a resource that only exists in >> the other. Is can sort of see some freaking huge NAT box type thing that >> summarizes v6 in a v4 address scope or contains the v4 address range at >> some point inside the v6 address space - but how can a v4 host get to a >> hot in v6 world that sits outside this without going through some form of >> proxy / nat gateway between the two. >> >> Or are the two simply not inter-communicable? > > I think that's the $64K question. Do you wait to roll out v6 until you > start seeing v6-only hosts start popping up? From an accounting and cost > recovery stand point, that probably makes sense in some environments. > > However, consider the fact that there will be v6 only hosts popping up > after IANA/RIR/ISP exhaustion. There will be new entrants in the public > internet space that cannot obtain v4 addresses and will be reachable via v6 > only. That date is starting to become a bit more predictable too. Those v6 > only sites won't be Google or Yahoo, but they will be entrepreneurs with > good ideas and new services that your customers will be asking to get > access to. > > We're pursuing a dual stacking model today because we anticipate that > the dual-stacking process itself will take a while to deploy, and we want > to anticipate customer demand for access to v6 only sites. We could hold > off on that deployment, and then spend money on work at the moment of > truth, but that approach is not very appealing to us. > > -- > Dan White > > > > -------------------------------------------------------------------------- > BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} > Ben Butler > Director Tel: 0333 666 3332 > Fax: 0333 666 3331 > C2 Business Networking Ltd > The Paddock, London Road, Nantwich, Cheshire, CW5 7JL > http://www.c2internet.net/ > > Part of the Atlas Business Group of Companies plc > Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 > This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. > > > From owen at delong.com Thu Oct 21 19:20:26 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 17:20:26 -0700 Subject: =?windows-1252?Q?Re:_Failover_IPv6_with_multiple_PA_prefixes_=28?= =?windows-1252?Q?Was:_IPv6_fc00::/7_=97_Unique_local_addresses?= =?windows-1252?Q?=29?= In-Reply-To: <20101021170258.GE61771@macbook.catpipe.net> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <20101021170258.GE61771@macbook.catpipe.net> Message-ID: <65C8672D-F78D-4657-B50B-6BE90D43D908@delong.com> On Oct 21, 2010, at 10:02 AM, Phil Regnauld wrote: > Jeroen Massar (jeroen) writes: >> >> Now the problem with such a setup is the many locations where you >> actually are hardcoding the IP addresses/prefixes into: firewalls, DNS >> etc. That is the hard part to solve, especially when these services are >> managed by other parties. > > And probably the reason why most won't deploy RA and multiple prefixes. > Hardcode and NAT, baby! If you want to hardcode, do it with PI and not NAT. Owen From marka at isc.org Thu Oct 21 19:33:12 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 22 Oct 2010 11:33:12 +1100 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: Your message of "Thu, 21 Oct 2010 15:56:15 PDT." <5A6D953473350C4B9995546AFE9939EE0B14C41E@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net><20101021093109.06a50ea2@opy.nosense.org><20101021105901.7f708b16@opy.nosense.org><585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com><20101021120648.1872981a@opy.nosense.org> <20101021221539.1E52A5F3641@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0B14C41E@RWC-EX1.corp.seven.com> Message-ID: <20101022003312.17B345F4205@drugs.dv.isc.org> In message <5A6D953473350C4B9995546AFE9939EE0B14C41E at RWC-EX1.corp.seven.com>, " George Bonser" writes: > > Sent: Thursday, October 21, 2010 3:16 PM > > To: Owen DeLong > > Cc: NANOG list > > Subject: Re: Re: IPv6 fc00::/7 - Unique local addresses > >=20 > > IPv4 think. > >=20 > > You don't re-address you add a new address to every node. IPv6 is > > designed for multiple addresses. > >=20 > > How does your application on the host decide which address to use when > sourcing an outbound connection if you have two different subnets that > are globally routable? But ULAs aren't globally routable. ULA addresses are easy to identify and guess what IPv6 stacks know how to select different source address depending apon the destination address. They also know how to order the addresses returned to the application such that reachable ULA's are returned first and non-reachable ULAs are returned last. You can do the same thing with a RIR assigned prefix for internal communication but it requires more explict configuration. With ULA's the IPv6 stack can auto configure itself as you have a well known identifier. Any node that supports RFC3484 (February 2003) can do this for you though you may need to override the defaults. If your OS doesn't yet support it complain. The ability to set this site wide is also coming. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From rcarpen at network1.net Thu Oct 21 19:34:21 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Thu, 21 Oct 2010 20:34:21 -0400 (EDT) Subject: =?utf-8?Q?Re:_IPv6_fc00::/7_=E2=80=94_Unique_local_addresses?= In-Reply-To: <1287701974.10216.63.camel@karl> Message-ID: <729869904.12087.1287707661100.JavaMail.root@zimbra.network1.net> > > In Oz it costs real money to get IPv6 address space from the RIR > (APNIC). Around AUD$6K in the first year, around AUD$1100 each year > thereafter. > > Your /48, according to the ARIN website, cost you US$625 this year, > will > cost US$937.50 next year, and $1250 every year thereafter. Correction: For endusers it is $1250 initially, and $100 per year thereafter. Much closer to affordable. That same $100 also covers an ASN if you have one. ISPs are charged the large yearly fee. > Fairly trivial amounts for most commercial entities, but prohibitive > for > all but the most enthusiastic home user. Justification aside, it is quote affordable for a typical power user. -Randy From joe at nethead.com Thu Oct 21 19:40:55 2010 From: joe at nethead.com (Joe Hamelin) Date: Thu, 21 Oct 2010 17:40:55 -0700 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <729869904.12087.1287707661100.JavaMail.root@zimbra.network1.net> References: <1287701974.10216.63.camel@karl> <729869904.12087.1287707661100.JavaMail.root@zimbra.network1.net> Message-ID: On Thu, Oct 21, 2010 at 5:34 PM, Randy Carpenter wrote: > Justification aside, it is quote affordable for a typical power user. For large values of affordable. -- Joe Hamelin, W7COM, Tulalip, WA, 360-474-7474 From niels=nanog at bakker.net Thu Oct 21 19:53:22 2010 From: niels=nanog at bakker.net (Niels Bakker) Date: Fri, 22 Oct 2010 02:53:22 +0200 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <19648.43288.915332.173143@world.std.com> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> Message-ID: <20101022005322.GS45727@burnout.tpb.net> * bzs at world.std.com (Barry Shein) [Thu 21 Oct 2010, 22:59 CEST]: >And, of course, the RIRs could just cancel all the IPv4 route >announcements, whatever they do if someone doesn't pay or whatever. I think you're mistaking the default-free zone for Usenet. The DFZ doesn't have 'cmsg cancel' messages. -- Niels. -- "It's amazing what people will do to get their name on the internet, which is odd, because all you really need is a Blogspot account." -- roy edroso, alicublog.blogspot.com From owen at delong.com Thu Oct 21 19:49:19 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 17:49:19 -0700 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> Message-ID: <7B6334C7-45DE-4407-8EC6-1F0EB9E9DF6E@delong.com> On Oct 21, 2010, at 10:58 AM, Justin M. Streiner wrote: > On Thu, 21 Oct 2010, Jared Mauch wrote: > >> How would you respond if that were announced? Carriers have been doing technology transitions for years. Cidr to classless. Amps to CDMA or gsm... This is not new. > > My next question would be "How many times will that get extended/pushed back because somebody screams loudly enough?". It will probably sunset around the time that v6 starts to run out of gas and people start thinking about IPv8 (assuming IPv7 would be treated like odd-numbered Linux kernel releases like 2.3.x, 2.5.x, etc - never to see the light of day) :) > > jms I'll point out that the FCC sort of tried that with the NTSC->ATSC move. Finally the broadcasters said "Screw that... You can tell us when we have to turn on ATSC, but, you can't actually prevent us from turning off NTSC. Click!" Owen From owen at delong.com Thu Oct 21 20:01:37 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:01:37 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: > Using multiple ISPs is still something that is a bit tricky. A lot of > people have gotten used to the Dual-WAN Firewall appliance boxes that > accept connections from two ISPs and handle the failover, depending on > NAT to maintain the functionality of the Internal network. > > Larger organizations can arrange to have IPv6 transit and announce a > single prefix over BGP. Most providers won't want to see this setup > for an SMB so they're out of luck. > Actually, ANY size organization can do this. Most providers won't want to set this up over native DSL, CMTS, or PON cheap circuits. There are options there. Do BGP over tunnels using your native circuits as L2 transport, for one. (This is working quite well for me and hasn't been all that hard to implement). > One thing that has changed, though, is Metro Ethernet offerings have > gotten a lot better. I would say the most painless way to go would be > to use one ISP for L3, and two ME providers to give diverse L2 paths > to that L3 ISP. It means dealing with more companies, and moving > failover to L2, but it's pretty rare that the cause of a connection > problem is at the ISP these days (it's more often a bad connection > between you and the ISP), so just having redundancy at L2 might be > enough. > I'm not convinced that's the best approach. If I were doing that, I'd use the two metro-E connections to reach different providers and run BGP. It's just not that hard. Especially if your BGP is accept default, advertise _myroute_. > Sadly, that model doesn't really exist in the US right now, and it > might take quite a bit of work convincing providers to coordinate to > make it all work. > Another argument in favor of the L2/L3 topologies matching. (There are also reliability and simplicity arguments to favor doing so). > The other option, which was the intent of IPv6 when being designed > (but that was 10 years ago or so) was that every PC would have a > separate address from each ISP. In this situation you could depend on > ULA (local addressing) for access to all internal services so that if > one of the global prefixes goes away it doesn't impact internal > operation, but it does require a device to kind of coordinate that- > such a device doesn't exist yet, and there are some issues with > getting PCs to handle address selection correctly. I suspect if this > does happen (and it could, it's not a horrible model) it will take a > few more years before it's "easy". It's too bad they axed the site > local scope for this kind of environment. > Please stop promulgating the fiction that IPv6 addressing from your provider depends on reachability to your provider to continue functioning on your internal network. It simply isn't true unless you are getting those addresses via DHCPv6 or SLAAC. If you have a topology, SLAAC is a non-starter and it would have to be DHCPv6-PD or static. If you have static, there's no need whatsoever for ULA. No sane business would go for having their IPv6 addresses delivered to them via DHCPv6-PD. > For now, I would recommend just going with a single IPv6 provider > since I have yet to encounter IPv6-only content that is mission > critical. That will at least give you access to the IPv6 internet > now, but give the IPv6 market time to come around to meet the needs of > SMB and wanting redundancy in IPv6 access. > This is a very solvable problem to day, but, it does require a tiny amount of training/learning to implement the solution. > I'm not aware of any appliance that does a good job at IPv6, yet... > Depends on your definition of Appliance. If you would consider an SRX-100 an appliance, it works reasonably well. It cost less than several of the other appliances in my house. > If it were me I would build up a Linux box as a IPv6 firewall, router, > etc. It's really too bad that there isn't such an appliance yet. You > could just use a Cisco ISR (like an 1841) as your IPv6 on a stick > router, but the problem is that you really want to keep in mind that > once you give out global addresses to hosts they're not behind your > NAT firewall for IPv6. So you'll want to implement some sort of > stateful firewall for IPv6, or enable host-based IPv6 firewalls. > Linux box is a fine alternative, ip6tables works well, but, Linux box vs. SRX-100, the cost difference isn't that large. > We've decided to disable SLAAC (State-Less Address Auto-Configuration) > on almost all our IPv6 networks and use DHCPv6 exclusively. This Ouch... Sounds painful. > allows us to only respond with DHCPv6 to the hosts we want to get an > IPv6 address instead of enabling it network-wide and crossing your > fingers. The disadvantage here is that DHCPv6 client support is still > limited (OS X has none for example). The argument is that IPv6 isn't > mission critical yet, so we're waiting to see if vendors will come > around and include DHCPv6 client support in the future. > It also means that you are even more subject to the issues of rogue RA and RA Spoofing. > Another thing you want to do is block rogue RA. RA-Guard is the > feature name, but nobody has a working implementation yet. If you > have switches that can do port-based access-lists with IPv6 you can > create ingress filters to block out incoming RA on a per-port basis > which is what we have done. > You must have a really hostile user base. I agree RA-Guard is a good idea and it does work on some switches. Where it is most glaringly lacking is in Wireless configurations, meaning that having a real RA is actually a limited measure of protection vs. having no RA. > Owen From owen at delong.com Thu Oct 21 20:07:43 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:07:43 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC08C38.80409@ttec.com> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <4CC08C38.80409@ttec.com> Message-ID: On Oct 21, 2010, at 11:53 AM, Joe Maimon wrote: > > > Dan White wrote: > >>> Or are the two simply not inter-communicable? >> >> I think that's the $64K question. Do you wait to roll out v6 until you >> start seeing v6-only hosts start popping up? > > When do you think that will happen and in what percentages of your target populations to matter? > Shortly after runout and that depends on the nature of the growth in your userbase. >> From an accounting and cost >> recovery stand point, that probably makes sense in some environments. >> >> However, consider the fact that there will be v6 only hosts popping up >> after IANA/RIR/ISP exhaustion. > > There is a phase you are missing between depletion and v6 only hosts. > Not really. > That would be continual and increasing difficulties of obtaining new v4 access and degradation of the quality of that service, hopefully along with a direct inverse effect on the quality and resultant value of v6 service. > That phase will be short-lived and steep. > The time line and gradations of that phase are far less clear than depletion. > Less clear, yes. Far less? I'm not so sure about that. > That would explain why so many do not concern themselves with it at this time. Especially those who do not consider themselves to be the party initially responsible for resolving those issues. > I think a more accurate explanation would be a behavior common to Ostriches when experiencing fear. Tony Hain has a pretty good slide on the stages of IPv6 grief. It seems many engineers and organizations are somehow still in denial and few have moved to rationalization or acceptance. > http://www.dilbert.com/fast/2006-07-30/ > Cute, but, remember, Mr. Adams used to be a Pacific Bell employee. Not exactly the shining example of a forward thinking or innovative company. So much not so that they ended up being acquired by SBC which later bought and renamed itself AT&T. Owen From jbates at brightok.net Thu Oct 21 20:13:21 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Oct 2010 20:13:21 -0500 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <20101022005322.GS45727@burnout.tpb.net> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <20101022005322.GS45727@burnout.tpb.net> Message-ID: <4CC0E531.3010508@brightok.net> On 10/21/2010 7:53 PM, Niels Bakker wrote: > * bzs at world.std.com (Barry Shein) [Thu 21 Oct 2010, 22:59 CEST]: >> And, of course, the RIRs could just cancel all the IPv4 route >> announcements, whatever they do if someone doesn't pay or whatever. > > I think you're mistaking the default-free zone for Usenet. The DFZ > doesn't have 'cmsg cancel' messages. > The "whatever they do if someone doesn't pay" is a nightmare. I suspect such a recourse wouldn't work for stopping IPv4. Jack From owen at delong.com Thu Oct 21 20:12:44 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:12:44 -0700 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C413@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net> <5A6D953473350C4B9995546AFE9939EE0B14C413@RWC-EX1.corp.seven.com> Message-ID: > >> They *will* fight you, and tell you to your face that if you want to >> take NAT away from them it will be from their cold dead hands. > > And it isn't NAT in and of itself that is attractive. Those people > aren't talking about static NAT where you are just translating the > network prefix. They are talking dynamic port-based PAT so that the > translation doesn't exist until the first packet goes in the outbound > direction. Like it or not, that DOES provide some barrier of entry to > someone outside wishing to initiate a connection from the outside. You > cannot predict in advance what outside address/port will be associated > with which inside address/port or if any such association even exists > and a lot of people have already made up their minds that the breakage > that causes for various things is offset by the perceived benefit of > that barrier and worth the price of dealing with that breakage. > Ah... You've actually just pointed out that it is _NOT_ the NAT that does that, but, the stateful inspection that happens before the NAT. Stateful inspection can occur and require a matching state table entry to permit inbound packets with or without the header-mangling that we call NAT, NPAT, NAPT, PAT, etc. True, overloaded NAT cannot exist without stateful inspection, but, that's largely irrelevant to security. What is relevant is the need for a good stateful inspection engine with a default-deny-inbound policy. Owen From owen at delong.com Thu Oct 21 20:15:23 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:15:23 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC0959A.3060603@consolejunkie.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net><4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <5A6D953473350C4B9995546AFE9939EE0B14C415@RWC-EX1.corp.seven.com> <4CC0959A.3060603@consolejunkie.net> Message-ID: <5E00D91C-BD38-443F-8C95-1C0AC2FACA21@delong.com> On Oct 21, 2010, at 12:33 PM, Leen Besselink wrote: > On 10/21/2010 09:25 PM, George Bonser wrote: >>> However, consider the fact that there will be v6 only hosts popping up >>> after IANA/RIR/ISP exhaustion. There will be new entrants in the >> public >>> internet space that cannot obtain v4 addresses and will be reachable >>> via v6 >>> only ... >> Yep, you can't do NAT64 if you don't have "4". But that said, just >> because ARIN is exhausted doesn't mean PA space is exhausted so there >> will be addresses available though it will be tight. >> >> > That is exactly what the last 5 /8's are for as I understand it. > Not necessarily. It's up to each RIR's policy. ARIN has no such policy. The other regions generally do not have such a policy. > The last 5 /8's will be allocated to each RIR immediately and I > think by now every RIR has a policy for that last /8 which pretty > much says: only for transitional purposes > Nope... No registry has such a policy that I know of. Owen From owen at delong.com Thu Oct 21 20:18:02 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:18:02 -0700 Subject: =?windows-1252?Q?Re:_Failover_IPv6_with_multiple_PA_prefixes_=28?= =?windows-1252?Q?Was:_IPv6_fc00::/7_=97_Unique_local_addresses?= =?windows-1252?Q?=29?= In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> Message-ID: On Oct 21, 2010, at 12:35 PM, George Bonser wrote: > > >> From: Jeroen Massar > Sent: Thursday, October 21, 2010 9:57 AM >> To: Allen Smith >> Cc: NANOG list >> Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 ? >> Unique local addresses) >> >> [Oh wow, that subject field, so handy to indicate a topic change! ;) ] >> >> Short answer: you announce both PA prefixes using Router Advertisement >> (RA) inside the network. You pull the RA when a uplink goes >> down/breaks. > > That assumes importing some sort of routing state into your RA config. Sort of a conditional RA. Can that be done today by anyone? > It can be done with some clever JunOScript or a few other mechanisms. Of course, it can also be done on a linux-based router fairly easily using whatever scripting language you like. >> Sessions break indeed, but because there is the other prefix they fall >> over to that and build up new sessions from there. > > This still doesn?t address breakage that happens AFTER your link to your upstream. What if your upstream has a peering issue or their peer has a peering issue? How do you detect that the distant end has a route back to that prefix but doesn't to the other? You can't. > How do you do that for IPv4... There's nothing new here. The failure modes are identical and your NAT box in IPv4 doesn't protect you from this any better. In fact, even multihomed BGP doesn't protect you from this unless you're taking a full table (which is a lot more practical in IPv6 than IPv4). Owen From marka at isc.org Thu Oct 21 20:22:40 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 22 Oct 2010 12:22:40 +1100 Subject: Failover IPv6 with =?utf-8?Q?multiple_?= =?utf-8?Q?PA_prefixes_=28Was=3A_IPv6_fc00=3A=3A=2F7_?= =?utf-8?B?4oCU?= Unique local addresses) In-Reply-To: Your message of "Thu, 21 Oct 2010 19:02:59 +0200." <20101021170258.GE61771@macbook.catpipe.net> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <20101021170258.GE61771@macbook.catpipe.net> Message-ID: <20101022012240.829855F4C73@drugs.dv.isc.org> In message <20101021170258.GE61771 at macbook.catpipe.net>, Phil Regnauld writes: > Jeroen Massar (jeroen) writes: > > Now the problem with such a setup is the many locations where you > > actually are hardcoding the IP addresses/prefixes into: firewalls, DNS > > etc. That is the hard part to solve, especially when these services are > > managed by other parties. > > And probably the reason why most won't deploy RA and multiple prefixes. > Hardcode and NAT, baby! Well have the hosts update their own addresses in the DNS. That's one of the problems addressed. There are at least two commercial OSs which will do this for you. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bzs at world.std.com Thu Oct 21 20:33:54 2010 From: bzs at world.std.com (Barry Shein) Date: Thu, 21 Oct 2010 21:33:54 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <20101022005322.GS45727@burnout.tpb.net> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <20101022005322.GS45727@burnout.tpb.net> Message-ID: <19648.59906.909113.690761@world.std.com> I think the words you're looking for are "revoked", "reclaimed", and "returned" address space. On October 22, 2010 at 02:53 niels=nanog at bakker.net (Niels Bakker) wrote: > * bzs at world.std.com (Barry Shein) [Thu 21 Oct 2010, 22:59 CEST]: > >And, of course, the RIRs could just cancel all the IPv4 route > >announcements, whatever they do if someone doesn't pay or whatever. > > I think you're mistaking the default-free zone for Usenet. The DFZ > doesn't have 'cmsg cancel' messages. > > > -- Niels. > > -- > "It's amazing what people will do to get their name on the internet, > which is odd, because all you really need is a Blogspot account." > -- roy edroso, alicublog.blogspot.com -- -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 Thu Oct 21 20:38:27 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:38:27 -0700 Subject: =?windows-1252?Q?Re:_Why_ULA:_low_collision_chance_=28Was:_IPv6_?= =?windows-1252?Q?fc00::/7_=97_Unique_local_addresses=29?= In-Reply-To: <4CC0C1E7.6010104@brightok.net> References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> Message-ID: On Oct 21, 2010, at 3:42 PM, Jack Bates wrote: > On 10/21/2010 5:27 PM, Joel Jaeggli wrote: >> >> Announce your gua and then blackhole it and monitor your prefix. you can >> tell if you're leaking. it's generally pretty hard to tell if you're >> leaking rfc 1918 since your advertisement may well work depending on the >> filters of your peers but not very far. > > This is always the argument I hear from corporate customers concerning wanting NAT. If mistake is made, the RFC 1918 space isn't routable. They often desire the same out of v6 for that reason alone. > Given the number of times and the distance over which I have seen RFC-1918 routes propagate, this belief is false to begin with, so, removing this false sense of security is not necessarily a bad thing. > I personally could understand the fear of wondering if your stateful firewall is properly working and doing it's job and how a simple mistake could have disastrous effects that NAT systems usually don't have. ULA w/ NAT very well may become the norm. > I tend to doubt that it will... Hopefully there will be enough proper deployments that developers will not eschew improvements that depend on an end-to-end model and there will be real features unavailable to any network that deploys such relatively quickly. The tragedy won't be networks deploying NAT. I'm all for allowing you to buy a gun, ammunition, and aim at your foot or head as you wish. The tragedy will be if enough networks do this to hobble development of truly useful tools that depend on a NAT-free environment to work. Owen From owen at delong.com Thu Oct 21 20:34:59 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:34:59 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC0BEE4.80302@ttec.com> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com> <4CC0BEE4.80302@ttec.com> Message-ID: <5127C77A-8A2E-4C24-9FD1-50A1C0E17C93@delong.com> On Oct 21, 2010, at 3:29 PM, Joe Maimon wrote: > > > Matthew Petach wrote: > >> So...uh...who's going to be first to step up and tell their customers >> "look, you get a v6 /56 for free with your account, but if you want >> v4 addresses, it's going to cost an extra $50/month." ?? >> >> Matt >> > > Either the telephone company or the cable company. Probably both. Give me a harder one. > > Joe > ROFL, Comcast is already telling their residential customers that if they want a static IPv4 address it will cost them an extra ~$60/month. (Delta between residential and business: ~$55/month, single static IPv4 address on business circuit: $5/month) Owen From owen at delong.com Thu Oct 21 20:33:56 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:33:56 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101021221539.1E52A5F3641@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <20101021120648.1872981a@opy.nosense.org> <20101021221539.1E52A5F3641@drugs.dv.isc.org> Message-ID: <4BC01459-B53A-4B2C-B75B-47D89550DFC5@delong.com> On Oct 21, 2010, at 3:15 PM, Mark Andrews wrote: > > In message , Owen DeLong write > s: >>>>> >>>> Which is part one of the three things that have to happen to make ULA >>>> really bad for the internet. >>>> >>>> Part 2 will be when the first provider accepts a large sum of money to >>>> route it within their public network between multiple sites owned by >>>> the same customer. >>>> >>> >>> That same customer is also going to have enough global address >>> space to be able to reach other global destinations, at least enough >>> space for all nodes that are permitted to access the Internet, if not >>> more. Proper global address space ensures that if a global destination >>> is reachable, then there is a high probability of successfully reaching >>> it. The scope of external ULA reachability, regardless of how much >>> money is thrown at the problem, isn't going to be as good as proper >>> global addresses. >>> >> _IF_ they implement as intended and as documented. As you've >> noted there's a lot of confusion and a lot of people not reading the >> documents, latching onto ULA and deciding ti's good. >> >> It's not a big leap for some company to do a huge ULA deployment >> saying "this will never connect to the intarweb thingy" and 5-10 years >> later not want to redeploy all their addressing, so, they start throwing >> money at getting providers to do what they shouldn't instead of >> readdressing their networks. > > IPv4 think. > > You don't re-address you add a new address to every node. IPv6 is > designed for multiple addresses. > That's a form of re-addressing. It's not removing the old addresses, but, it is a major undertaking just the same in a large deployment. >>> For private site interconnect, I'd think it more likely that the >>> provider would isolate the customers traffic and ULA address space via >>> something like a VPN service e.g. MPLS, IPsec. >>> >> One would hope, but, I bet laziness and misunderstanding trumps >> reason and adherence to RFCs over the long term. Since ULA >> won't get hard-coded into routers as unroutable (it can't), > > Actually it can be. You just need a easy switch to turn it off. The > router can even work itself out many times. Configure multiple interfaces > from the same ULA /48 and you pass traffic for the /48 between those > interfaces. You also pass routes for that /48 via those interfaces. > If you have an easy switch to turn it off, it will get used, thus meaning that it isn't hard coded, it's just default. > Owen From rps at maine.edu Thu Oct 21 20:39:45 2010 From: rps at maine.edu (Ray Soucy) Date: Thu, 21 Oct 2010 21:39:45 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: (Response inline). On Thu, Oct 21, 2010 at 9:01 PM, Owen DeLong wrote: >> We've decided to disable SLAAC (State-Less Address Auto-Configuration) >> on almost all our IPv6 networks and use DHCPv6 exclusively. ?This > > Ouch... Sounds painful. Really? I don't know. Maybe as a consultant you don't see it, but I can't run a non-trivial network without having control over which hosts get an IPv6 address (and knowing which address they get) without creating a lot more work running around putting out fires. From a "buy-in" standpoint, SLAAC was a non-starter, giving people an option where they could enable IPv6 on a host-by-host basis ended up being the quickest path to adoption without IPv6 getting a black eye because of a security issue that couldn't be quickly dealt with, or older systems (RHEL 3 comes to mind) having an IPv6 bug triggered and crashing. IPAM is a critical component of IPv6 for any non-trivial deployment IMHO, I know Apple disagrees, but OK. >> allows us to only respond with DHCPv6 to the hosts we want to get an >> IPv6 address instead of enabling it network-wide and crossing your >> fingers. ?The disadvantage here is that DHCPv6 client support is still >> limited (OS X has none for example). ? The argument is that IPv6 isn't >> mission critical yet, so we're waiting to see if vendors will come >> around and include DHCPv6 client support in the future. >> > It also means that you are even more subject to the issues of rogue > RA and RA Spoofing. How so? We still have RA (with a high priority) that's the only way DHCPv6 works. I guess there is a lot of misunderstanding about how DHCPv6 works, even among the experts... >> Another thing you want to do is block rogue RA. ?RA-Guard is the >> feature name, but nobody has a working implementation yet. ?If you >> have switches that can do port-based access-lists with IPv6 you can >> create ingress filters to block out incoming RA on a per-port basis >> which is what we have done. >> > You must have a really hostile user base. I agree RA-Guard is a good > idea and it does work on some switches. Where it is most glaringly > lacking is in Wireless configurations, meaning that having a real RA > is actually a limited measure of protection vs. having no RA. Again, it sounds like you think DHCPv6 means no RA? This is not the case. I consider filtering RA (accidental or malicious) critical for any network, regardless of whether IPv6 is deployed or not. Just above you were complaining about me having problems with rogue RA... Now you're saying I'm being paranoid? I know you work for HE and everything, but really? If you don't block RA, you can get mis-configured hosts (Windows ICS comes to mind) hijacking traffic without even knowing about it on networks that you don't have IPv6 deployed on. That's the accidental side, though. On the malicious side, I consider IPv6 one of todays most effective attack vectors. I can easily jump on a network that doesn't even monitor IPv6, declare myself as a router, advertise myself as IPv6 DNS, and proxy all traffic on a network, often without setting off alarms. Remember, hosts by default usually have IPv6 enabled, and usually prefer IPv6 over IP. In the case of servers, most administrators who are diligent about making sure host-based firewalls are in place completely forget about IPv6, because they haven't deployed it yet. Just because you haven't deployed IPv6 doesn't mean it's not running on your network. This is especially true in an academic setting where people bring their own computers on to your network. Not filtering rogue RA seems a little insane, IMHO. I'm still shocked that RA-Guard hasn't become the default in modern switching... but if you don't think it's a problem, that works too. What are the odds that there will be a virus, worm, or tojan that decides to turn infected hosts into IPv6 routers, anyway... I really don't buy the argument that "advertising IPv6 yourself with a high priority will mitigate the impact of rogue RA". As mentioned, DHCPv6 still requires RA to work... by design, so your point is moot. But regardless, that mindset only protects against accidental rogue RA, not malicious RA, which is a significant security threat and _should_ be filtered as a best practice when possible. I would go as far as to argue it's worth pushing up switch upgrades to make sure you have hardware capable of doing so, but maybe I am just being paranoid. -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From owen at delong.com Thu Oct 21 20:43:46 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:43:46 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101021225202.CE2205F376D@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <20101021225202.CE2205F376D@drugs.dv.isc.org> Message-ID: >>> >> I keep hearing this and it never makes sense to me. >> >> If your provider will assign you a static /48, then, you have stable >> addresses when your provider link is down in GUA. Who needs ULA? > > You used the word "if". Reverse the sense of the "if" and see if > it still doesn't makes sense to use ULA addresses. I get a mostly > stable IPv4 address from my cable provider (DHCP). That address > changes without notice about once a year. I can configure a 6to4 > prefix based on that address (effectively a PA prefix). I use ULA > addresses internally and 6to4 (PA) externally. Same for 6rd. Same > for PD. > I use the dynamic address from my cable provider to terminate a set of GRE tunnels to my colo routers. I use the static address from my DSL provider to terminate other GRE tunnels to my colo routers. The DSL tunnels are all carrying both IPv4 and IPv6. When the cable address changes, the BGP sessions over those GRE tunnels drop and my network connection slows down. When I repair the tunnels with the new end-point address, everything goes back to fast. > DHCP derived 6to4, DHCP derived 6rd, DHCP derived Terado and PD all > give you leased prefixes. They are not guarenteed to be STABLE. > For internal communication you really do want stable prefixes. ULA > gives you those stable prefixes. > Yep... Makes much more sense to have at least one provider with static and do native IPv6 than to use 6to4, 6rd, Teredo, or PD. >>> You talk to the world using PA addresses, directly for IPv6 and >>> indirectly via PNAT for IPv4. These can change over time. >>> =20 >> Or, if you don't want your IPv6 addresses to change over time, you can >> get a prefix from your friendly RIR. > > You really think I'm going to go to my RIR and get a addresses block > for my home network then my cable provider will route it for me? > No... I think you might go to your RIR and get an address block for your home network then find a way to use your cable provider for L2 transport and route it. That solution works quite well for me. >>> Similarly, ULA + 6to4 works well provided the 6to4 works when you >>> are connected. When your IPv4 connection is renumbered you have a >>> new external addresses but the internal addresses stay the same. >>> =20 >> That's a big "provided that"... > > Not really. It works for lots of people. > Then how come I hear a lot more 6to4 horror stories than 6to4 success stories? It's not like I don't talk to lots of people using these protocols on a daily basis. >> > > And you expect the routing system to cope when 2 billion homes do the > same thing? > As a matter of fact, I think the routing system damn well better start planning to cope with just that scenario. I think it is inevitable in one form or another. Owen From bblackford at gmail.com Thu Oct 21 20:47:56 2010 From: bblackford at gmail.com (Bill Blackford) Date: Thu, 21 Oct 2010 18:47:56 -0700 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: References: <022801cb706a$ead9d5e0$c08d81a0$@net> <5294CF7C-E618-41E5-ACFB-E299CD25A5E5@beanfield.com> <042e01cb7152$f285e7f0$d791b7d0$@net> Message-ID: Unrelated, but... I use Extreme Summit in low-touch, user access areas because of it's low cost and stacking capability as compared to J and C. I figure you get what you pay for. The interface stats, ease of functionality for some of the features I frequent, are seriously lacking. I've been told that I could write a script to get close to the same functionality that I get by default with my other two vendor choices, but I find that unacceptable. I experienced that the LLDP-MED seems to require a "re-config" occasionally to work consistently, so,....... this vendor would not be my first choice to venture into a new technology. Others posters [YMMV]. Now, the Extreme cost/benefit, small form factor and features such as their proprietary ring protocol (similar to Cisco REP), may make them a contender for MEF applications. I can't say. For high-touch, high visibility purposes, I'm making other choices. -b -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... an their purple color > and that I don't really know their IOS that well. But to be fair, they have worked just fine..... > > In the future I hope we can migrate over to cisco switches because I'm bias..... =) > > > >> From: merkel at metalink.net >> To: nanog at nanog.org >> Subject: RE: Recommendations for Metro-Ethernet Equipment >> Date: Thu, 21 Oct 2010 15:05:37 -0400 >> >> Thanks to everyone who responded. Just got done talking with Extreme which >> no one really mentioned. Seems like decent gear reasonably priced. Anyone >> care to comment on them specifically or have them used them a metro Ethernet >> build? >> >> >> ===== >> Eric Merkel >> MetaLINK Technologies, Inc. >> Email: merkel at metalink.net >> >> >> -----Original Message----- >> From: Dan Armstrong [mailto:dan at beanfield.com] >> Sent: 2010-10-20 19:50 >> To: Ramanpreet Singh >> Cc: Jason Lixfeld; nanog at nanog.org >> Subject: Re: Recommendations for Metro-Ethernet Equipment >> >> I think that's what Jason just said. :-) >> >> >> >> >> On 2010-10-20, at 5:24 PM, Ramanpreet Singh wrote: >> >> > 7600's/ASR 1k >> > >> > Have you looked in to Ciso ME 3600X/ME 3800X series? >> > >> > Without a bias these are the top notch products in the market for Metro E. >> > >> > -Raman >> > >> > On Wed, Oct 20, 2010 at 12:57 PM, Jason Lixfeld wrote: >> >> On 2010-10-20, at 11:24 AM, Eric Merkel wrote: >> >> >> >>> Any suggestions, success or horror stories are appreciated. ;) >> >> >> >> I've been going through pretty much the same exercise looking for a >> decent PE for almost two years. ?Our requirements were for a PE device that >> had between 12-24 ports (in a perfect world, mixed mode 10/100/1000 copper + >> SFP), 10G uplinks, EoMPLS, MPLS VPN, DHCP server, port-protect/UNI (or >> similar) capabilities, DC power and a small footprint (1RU) >> >> >> >> Of all the ones we looked at (Juniper, Cisco, Extreme, Brocade, MRV, >> Alcatel) initially, MRV was the only contender. ?The rest either didn't have >> a product, or their offering didn't meet various points within our criteria. >> >> >> >> As such, we bought a bunch of MRVs in early 2009 and after four months of >> trial and error, we yanked every single one out of the network. ?From a >> physical perspective, the box was perfect. ?Port density was perfect, >> mixed-mode ports, promised a 10G uplink product soon, size was perfect, >> power was perfect, we thought we had it nailed. ?Unfortunately there are no >> words to describe how terrible the software was. ?The CLI took a little >> getting used to, which is pretty much par for the course when you're dealing >> with a new vendor, but the code itself was just absolutely broken, >> everywhere. ?Duplex issues, LDP constantly crashing taking the box with it, >> OSPF issues, the list went on and on. ?To their credit, they flew engineers >> up from the US and they were quite committed to making stuff work, but at >> the end of the day, they just couldn't make it go. ?We pulled the plug in >> May 2009 and I haven't heard a thing about their product since then, so >> maybe they've got it all together. >> >> >> >> While meeting with Juniper a few months later about a different project, >> they said they had a product that might fit our needs. ?The EX4200. ?As >> such, we had a few of these loaned to our lab for a few months to put >> through their paces, from a features and interoperability perspective. ?They >> work[1] and they seem to work well. ?The show stopper was provisioning[1] >> and size. ?The box is massive, albeit it is still 1U. >> >> >> >> [1] (I'm not a Juniper guy, so my recollection on specific terms and >> jargon may be a bit off kilter) they only support ccc, which makes >> provisioning an absolute nightmare. ?From my experience with Cisco and MRV, >> you only have to configure the EoMPLS vc. ?On the EX4200, you have to create >> the LSPs as well. ?To get a ccc working, the JunOS code block was far larger >> and much more involved per vc than the single line Cisco equivalent. ?To >> create the LSPs was, I believe, two more equally large sized code blocks. >> At the end of the day, it was just too involved. ?We needed something >> simpler. >> >> >> >> About the same time that we started to evaluate the EX4200, Cisco had >> pitched us on their (then alpha) Whales platform. ?It looked promising (MRV >> still had the best form factor) and we expressed our interest in getting a >> beta unit in as soon as we were able to. ?This is now known as the ME3600 >> and ME3800 platform and we've been testing a beta unit in our lab for the >> past few months. ?This is the platform we have chosen. ?It's not perfect, >> but our gripes have more to do with form factor (it's 1RU, but it's a bit >> deeper than what we'd like) and port densities (no mixed mode ports) than >> software or features. ?We've been pretty pleased with it's feature set and >> performance, but this hasn't seen any real world action, so who knows how >> that will turn out. >> >> >> >> If you're asking more about a P router or P/PE hybrid, we've also just >> ordered a few ASR9000s under try-and-buy as P/PEs to close up the chains of >> ME3600s that will start to be deployed in our remote sites. ?A Juniper MX >> would certainly work well here too, and it seems to interoperate rather well >> with the ME3600s, so that's certainly an option, but for us, we think it >> will work more in our favor to go with the ASRs in the core, but if not, >> we'd ship them back under the try-and-buy and get Junipers instead. >> >> >> >> Hope that helps. >> >> >> > >> >> >> >> >> > -- Bill Blackford Network Engineer Logged into reality and abusing my sudo privileges..... From owen at delong.com Thu Oct 21 20:48:40 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:48:40 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <1287701974.10216.63.camel@karl> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <1287701974.10216.63.camel@karl> Message-ID: <82AF7E03-CCDD-4D15-B1B3-546A7F9F248D@delong.com> On Oct 21, 2010, at 3:59 PM, Karl Auer wrote: > On Thu, 2010-10-21 at 01:46 -0700, Owen DeLong wrote: >>> If your big enough to get your own GUA and have the dollars to get >>> it routed then do that. If you are forced to use PA (think home >>> networks) then having a ULA prefix as well is a good thing. >>> >> home network: 2620:0:930::/48 > > In Oz it costs real money to get IPv6 address space from the RIR > (APNIC). Around AUD$6K in the first year, around AUD$1100 each year > thereafter. > > Your /48, according to the ARIN website, cost you US$625 this year, will > cost US$937.50 next year, and $1250 every year thereafter. > Uh, no... You're misreading it. It cost me $625 (or possibly less) one-time when I first got it. After that, the annual $100/year has been part of the same $100/year I've been paying for my IPv4 resources. > Fairly trivial amounts for most commercial entities, but prohibitive for > all but the most enthusiastic home user. > Agreed, but, at $100/year that I was already paying for IPv4, it seemed pretty trivial. I bet you spend more than that at Starbucks each year. Owen From bzs at world.std.com Thu Oct 21 20:51:41 2010 From: bzs at world.std.com (Barry Shein) Date: Thu, 21 Oct 2010 21:51:41 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <4CC0E531.3010508@brightok.net> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <20101022005322.GS45727@burnout.tpb.net> <4CC0E531.3010508@brightok.net> Message-ID: <19648.60973.790463.902867@world.std.com> On October 21, 2010 at 20:13 jbates at brightok.net (Jack Bates) wrote: > On 10/21/2010 7:53 PM, Niels Bakker wrote: > > * bzs at world.std.com (Barry Shein) [Thu 21 Oct 2010, 22:59 CEST]: > >> And, of course, the RIRs could just cancel all the IPv4 route > >> announcements, whatever they do if someone doesn't pay or whatever. > > > > I think you're mistaking the default-free zone for Usenet. The DFZ > > doesn't have 'cmsg cancel' messages. > > > > The "whatever they do if someone doesn't pay" is a nightmare. I suspect > such a recourse wouldn't work for stopping IPv4. Well, along with no more IPv4 DNS and it'd be pretty effective (I suggested both for a reason.) The idea isn't to make it impossible to run an ipv4 connection, tho at some point it'd have to be encapsulated in IPv6 to get routed across the public infrastructure, the idea is to declare it dead and stop expending (shared) resources on it. I guess I just answered my own question: "Why bother?" So we can stop expending resources on IPv4 like managing address space allocations, route announcements, firefighting, DNS, all the wonky this inside that encapsulation schemes, etc. I'd let folks like the RIRs and DNS root managers speak to how much of a win that would be tho it would affect others, particularly the firefighting part. If IPv4 is maintained forever then one presumes it works reasonably well forever and that's kinda why everyone here is here, no? Anyhow, it might be an interesting topic to discuss in the appropriate venues, IETF, "What is the cost of maintaining IPv4 forever?" but it's getting a little ahead of ourselves in terms of any pressing need. So...it wasn't a dumb question to raise, just perhaps a bit premature. -- -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 Thu Oct 21 20:46:58 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:46:58 -0700 Subject: =?windows-1252?Q?Re:_Why_ULA:_low_collision_chance_=28Was:_IPv6_?= =?windows-1252?Q?fc00::/7_=97_Unique_local_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> Message-ID: <6B559FCB-3222-4447-8418-4E35FF83066B@delong.com> On Oct 21, 2010, at 3:52 PM, Joe Hamelin wrote: > Ray said: ".. But then why wouldn't you just ask for a GUA at that point." > > What's the cost for a /48 GUA from ARIN these days? Why pay for > something that you're not going to "use"? > $1250 initial and $100/year thereafter. If you have any other end-user resources, it's part of the same $100/year you're already paying, so, it might be effectively free after the initial payment. Assuming you use it for 10 years, that amortizes out to $125/year. I don't know if there are still discounts on end-user assignments or not. I know that when I got mine, there was a partial fee waiver program in effect and I paid quite a bit less than $1250. > I agree with you but as long as the RIRs charge for integers people > will make up their own if they can find a way. > The RIRs don't charge for integers. The RIRs charge for making globally guaranteed unique registrations of integers and maintaining the associated records in several databases. > If a small shop guy is looking at ether paying for GUA space or > affording a more expensive switch that will do SNMP, he's going to get > the switch. > There are places to get legitimate GUA space other than RIRs. Some of them are free. Owen (KB6MER, btw) From owen at delong.com Thu Oct 21 20:53:37 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Oct 2010 18:53:37 -0700 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: <1287704885.10216.90.camel@karl> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <1287701974.10216.63.camel@karl> <292AF25E62B8894C921B893B53A19D9739AF595C7D@BUSINESSEX.business.ad> <1287704885.10216.90.camel@karl> Message-ID: <3D230C80-E7CC-4B73-9E47-780DF5FA33AC@delong.com> On Oct 21, 2010, at 4:48 PM, Karl Auer wrote: > On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote: >> Where does the 6K come from? >> >> AUD$4,175 is the amount - It consists of the "Associate Member >> Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500) >> >> Then AUD1180 for a /48 each year. > > Er - apologies. Yes, the initial fee covers the first year's annual fee, > so it's $4175 in the first year ans $1100 in subsequent years. > > The point still stands though - that's WAY too much for home users. > > While for Owen such costs might be doable, for the vast majority of home > users in the AP region the only viable alternatives for internal > addressing will be PA or ULA. > This is NANOG. To the best of my knowledge, no part of the NA in NANOG is in the APNIC service area. ARIN pricing is significantly better at US$100/year for ALL end-user resources, so, only the $1250 up-front fee would apply and apparently the partial fee-waiver for that is still in effect if your previous posting was correct. > Even with the lower costs that ARIN users pay, the prices are still IMHO > too high for home users to be using PI in any significant numbers. > Really? $100/year is too much? Really? I guess that depends on whether you think addresses are worth more than coffee. ;-) Owen From jbates at brightok.net Thu Oct 21 20:55:48 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Oct 2010 20:55:48 -0500 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance?= =?windows-1252?Q?_=28Was=3A_IPv6_fc00=3A=3A/7_=97_Unique_loc?= =?windows-1252?Q?al_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> Message-ID: <4CC0EF24.9020004@brightok.net> On 10/21/2010 8:38 PM, Owen DeLong wrote: > Given the number of times and the distance over which I have seen RFC-1918 > routes propagate, this belief is false to begin with, so, removing this false sense > of security is not necessarily a bad thing. > I don't think it's really a propagation issue. As the ISP, I don't actually route RFC-1918 space to my corporate customers, many of which maintain static assignments (no routing protocol). While they can leak packets out, there will never be a return of packets to them. They view this as a feature.The tragedy won't be networks deploying NAT. I'm all for allowing you to buy > a gun, ammunition, and aim at your foot or head as you wish. > > The tragedy will be if enough networks do this to hobble development of truly > useful tools that depend on a NAT-free environment to work. I think we should respect the different types of networks, and their administrative goals. I have customers who manage large educational networks. Their engineers have a strong belief in free speech and openness. They have very few filters, don't utilize NAT, and have a reactionary security policy. I also have corporate customers who run extreme nat, don't allow access to social network sites, proxy every communication in and out, and generally don't care that they break 90%+ of the applications that work over the Internet, especially when it's not business related. That being said, I've seen corporate networks change, altering their security policy and the way they do things in order to support applications which they desire. So I wouldn't be surprised if a tight NAT dwelling network suddenly shifted to routing global addressing to meet new applications needs. Jack From jbates at brightok.net Thu Oct 21 21:05:35 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Oct 2010 21:05:35 -0500 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> Message-ID: <4CC0F16F.2060706@brightok.net> On 10/21/2010 8:39 PM, Ray Soucy wrote: > > How so? We still have RA (with a high priority) that's the only way > DHCPv6 works. I guess there is a lot of misunderstanding about how > DHCPv6 works, even among the experts... Actually, the last I checked, there are implementation of DHCPv6 without RA. Jack From jared at puck.nether.net Thu Oct 21 21:09:39 2010 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 21 Oct 2010 22:09:39 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <19648.60973.790463.902867@world.std.com> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <20101022005322.GS45727@burnout.tpb.net> <4CC0E531.3010508@brightok.net> <19648.60973.790463.902867@world.std.com> Message-ID: <5AD6430A-A58E-4F60-8F1C-47EAA858D7ED@puck.nether.net> On Oct 21, 2010, at 9:51 PM, Barry Shein wrote: > Anyhow, it might be an interesting topic to discuss in the appropriate > venues, IETF, "What is the cost of maintaining IPv4 forever?" but it's > getting a little ahead of ourselves in terms of any pressing need. This is an interesting question. In talking to your vendors with your checklist of capabilities a device CAN/SHOULD/MUST have, what if you no longer needed to carry 350k/512k routes of IPv4 and only needed 256k of IPv6 ? Instead of 6pe think of 4pe with ipv6 core. I've been reminding vendors that IPv6 should get new features *first* vs IPv4. The end of IPv4 is near, but that doesn't mean the end of the Internet is here. The next chapter gets a new page turned. Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world. Either way, it's an interesting time to be an edge operator that worries about CPE stuff. those that think mostly about core this is a big fat *yawn* imho. Expect application developers to face some interesting challenges. me? I'm waiting until I see the "NOW WITH IPv6" sticker on things at the store. - Jared From aaron.glenn at gmail.com Thu Oct 21 21:15:28 2010 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Thu, 21 Oct 2010 21:15:28 -0500 Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: References: <022801cb706a$ead9d5e0$c08d81a0$@net> <4CBF0AF6.9030207@xyonet.com> Message-ID: On Wed, Oct 20, 2010 at 11:14 AM, Chris Grundemann wrote: > > Corrigent if anyone on the list has experience with their gear in the field I'd love to hear your experiences off-list. I'll even buy you a beer if you're in the nyc area. thanks! From gbonser at seven.com Thu Oct 21 21:21:41 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 19:21:41 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> > How do you do that for IPv4... There's nothing new here. The failure > modes > are identical and your NAT box in IPv4 doesn't protect you from this > any > better. With IPv4 I don't generally use two sets of prefixes for the same traffic from the same site to the Internet unless there is some sort of appliance in the path that somehow decides the "best" one to use for NAT and even then I am not convinced of such a device's utility in a general purpose sense. There might be corner cases where such an option is useful, though. I was making the point that trying to use two prefixes for the same traffic from the same site as some sort of redundancy doesn't really offer it because it only offers relief if your link to the provider drops. There are all sorts of other problems that can happen out on "the net" to make one prefix reachable but the other one not reachable from a remote site. Multihoming the same prefix from two providers is generally more reliable because if the remote network can "see" either provider, you are good and traffic can "fail over" from provider A to provider B in the course of a transaction without disruption. To recap, this tangent of the original thread was about the typical practice at small offices without a lot of network savvy to number the network in 1918 space and use a NAT at the Internet edge. To change providers, you simply change the NAT pool and you are done. With v6, while changing prefixes is easy for some gear, other gear is not so easy. If you number your entire network in Provider A's space, you might have more trouble renumbering into Provider B's space because now you have to change your DHCP ranges, probably visit printers, fax machines, wireless gateways, etc. and renumber those, etc. And some production boxes that you might have in the office data center are probably best left at a static IP address, particularly if they are fronted by a load balancer where their IP is manually configured. The complaint was that there is no equivalent in v6 and that someone is probably going to build and sell one and we will be right back in the same situation with v6 with networks in ULA space being NATed at the edge. People aren't going to want very much of their network infrastructure support tied to a provider's IP space. The small operation of which there are millions in this country, cannot justify the expense of multihoming for the sole reason of having an IP address range that doesn't change. As soon as the same configuration currently used is available for v6, you will see mass adoption of it. The lack of this currently in the market is probably one of the major drags on the adoption of v6 in the small office environment. People just do not want to number their internal network into PA space and can't justify the requirements to get PI space. > In fact, even multihomed BGP doesn't protect you from this unless > you're > taking a full table (which is a lot more practical in IPv6 than IPv4). > > Owen From jbates at brightok.net Thu Oct 21 21:29:45 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Oct 2010 21:29:45 -0500 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <5AD6430A-A58E-4F60-8F1C-47EAA858D7ED@puck.nether.net> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <20101022005322.GS45727@burnout.tpb.net> <4CC0E531.3010508@brightok.net> <19648.60973.790463.902867@world.std.com> <5AD6430A-A58E-4F60-8F1C-47EAA858D7ED@puck.nether.net> Message-ID: <4CC0F719.1030407@brightok.net> On 10/21/2010 9:09 PM, Jared Mauch wrote: > > Either way, it's an interesting time to be an edge operator that worries about CPE stuff. those that think mostly about core this is a big fat *yawn* imho. Expect application developers to face some interesting challenges. me? I'm waiting until I see the "NOW WITH IPv6" sticker on things at the store. > 1. Core routing/BGP check 2. Servers check 3. load balancers? oops, semi-check 4. edge check 5. Telco maintained CPE check (There's a reason we didn't do pppoe), for others, fail 6. Customer provided CPE/routers/etc fail It took off the shelf CPEs some time to get it right at autodetecting and handling the numerous Provider Edge setups. v6 actually adds a whole new arsenal of setups that can exist at the Provider Edge. People are crazy if they think the provider will adjust to a billion different setups. The cheap routers have a long ways to go to support this new variety of setups. I'm personally partial to DHCPv6 TA addressing (SLAAC at provider edge is cool, but there are too many issues with it, especially when trying to track users) with 86400 preferred and 172800 valid and NAK the renewal, combined with DHCPv6-PD with 86400 preferred and 172800 valid and NAK the renewal. This gives a 24 hour prefix rotation for new connections and a 24 hour hold time for old connections. Combined with privacy extensions, it should pollute geo IP databases with horribly wrong information and make it more difficult for certain types of malicious network attacks. :) Jack From gbonser at seven.com Thu Oct 21 21:32:38 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 19:32:38 -0700 Subject: =?UTF-8?B?UkU6IEZhaWxvdmVyIElQdjYgd2l0aCBtdWx0aXBsZSA=?= =?UTF-8?B?UEEgcHJlZml4ZXMgKFdhczogSVB2NiBmYzAwOjovNyA=?= =?UTF-8?B?4oCUIFVuaXF1ZSBsb2NhbCBhZGRyZXNzZXMp?= In-Reply-To: <20101022012240.829855F4C73@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net><4CC070E9.7090709@unfix.org><20101021170258.GE61771@macbook.catpipe.net> <20101022012240.829855F4C73@drugs.dv.isc.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C424@RWC-EX1.corp.seven.com> > > Well have the hosts update their own addresses in the DNS. That's > one of the problems addressed. There are at least two commercial > OSs which will do this for you. > > Mark But they sometimes don't check to make sure there aren't stale DNS entries for their hostname before they add the new one! I have run into that problem often. A machine that has been "bounced" several times recently might have a dozen A records for its hostname in DNS. I won't mention any names but their initials are MICROSOFT. For many of our machines, there are load balancers, even in the office data center with hard coded IP addresses for the backend servers. Dynamic address assignment isn't really an option but works fine for things like user machines in the cubes. You aren't going to be looking those up by A record anyway. Static assignment by DHCP is possible for the devices that do that, you just have to remember to change it if you change a NIC (or if the interfaces are bound together on the box, such as with linux bonding, the "master" interface of the bond changes for some reason like a failure of the previous master). Static hard coding of the IP address is actually easier to manage in the colo than DHCP or autoconfiguration. From jbates at brightok.net Thu Oct 21 21:45:37 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Oct 2010 21:45:37 -0500 Subject: =?UTF-8?B?UmU6IEZhaWxvdmVyIElQdjYgd2l0aCBtdWx0aXBsZSBQQSBwcmVmaXg=?= =?UTF-8?B?ZXMgKFdhczogSVB2NiBmYzAwOjovNyDigJQgVW5pcXVlIGxvY2FsIGFkZHJlc3M=?= =?UTF-8?B?ZXMp?= In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C424@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net><4CC070E9.7090709@unfix.org><20101021170258.GE61771@macbook.catpipe.net> <20101022012240.829855F4C73@drugs.dv.isc.org> <5A6D953473350C4B9995546AFE9939EE0B14C424@RWC-EX1.corp.seven.com> Message-ID: <4CC0FAD1.7090907@brightok.net> On 10/21/2010 9:32 PM, George Bonser wrote: > > But they sometimes don't check to make sure there aren't stale DNS entries for their hostname before they add the new one! I have run into that problem often. A machine that has been "bounced" several times recently might have a dozen A records for its hostname in DNS. I won't mention any names but their initials are MICROSOFT. For many of our machines, there are load balancers, even in the office data center with hard coded IP addresses for the backend servers. Dynamic address assignment isn't really an option but works fine for things like user machines in the cubes. You aren't going to be looking those up by A record anyway. Static assignment by DHCP is possible for the devices that do that, you just have to remember to change it if you change a NIC (or if the interfaces are bound together on the box, such as with linux bonding, the "master" interface of the bond changes for some reason like a failure of the previous master). Static hard coding of the IP address is actually easier to manage in the colo than DHCP or autoconfiguration. > Many of these problems are application/implementation issues. Many devices need support for dynamic prefix specifications "hey, my destination for the load balancer is $prefix:blah", and some devices still need support for just setting their IP with RA (though all my servers do it fine). At this time, there are many situations where static assignment is probably the only option. Multiple assignments may not be out of the question. However, this is due to the shortage of what IPv6 *could* be. We are missing so many support protocols and applications that could truly make it far superior to IPv4. Then again, I think SCTP is superior to udp/tcp, and I don't think I have a single app using it. Jack From bicknell at ufp.org Thu Oct 21 21:53:20 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 21 Oct 2010 19:53:20 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> Message-ID: <20101022025320.GA94206@ussenterprise.ufp.org> In a message written on Thu, Oct 21, 2010 at 07:21:41PM -0700, George Bonser wrote: > With v6, while changing prefixes is easy for some gear, other gear is > not so easy. If you number your entire network in Provider A's space, > you might have more trouble renumbering into Provider B's space because > now you have to change your DHCP ranges, probably visit printers, fax > machines, wireless gateways, etc. and renumber those, etc. And some > production boxes that you might have in the office data center are > probably best left at a static IP address, particularly if they are > fronted by a load balancer where their IP is manually configured. > > The complaint was that there is no equivalent in v6 and that someone is > probably going to build and sell one and we will be right back in the > same situation with v6 with networks in ULA space being NATed at the > edge. People aren't going to want very much of their network > infrastructure support tied to a provider's IP space. It would seem to me there is a market for a "new sort of NAT" with IPv6. That is the technology is not new, but it's a model we can't do in IPv4. If you could number your internal network out of some IPv6 space (possibly 1918 style, possibly not), probably a /48, and then get from your two (or more) upstreams /48's of PA space you could do 1:1 NAT. No PAT, just pure address translation, 1:1. You can "renumber" by configuring a new outside translation. The NAT box can do the load distribution functions discussed here, some users out one provider, others out the second provider. There is no port complication, so incoming connections are much simpler. It's a vast improvement over the port based mess we have now, and provides an interesting way to "multihome" at the edge. If we could get a simple protocol, in the model of UDLD to go NAT box to Provider router to establish that it was up, and a little bit of DNS software magic to make it easier to manage the external addresses appearing in DNS for exposed services this could solve the vast majority of small site multihoming needs. What makes it all possible is the same prefix length internally and from all providers. It's a reason why /48 could be important. Given all effort put into "better" multihoming in IPv6 I'm really surprised this simple solution which basically exists in code today (porting an IPv4 NAT to IPv6, if there is no PAT, is easy). -- 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 dwhite at olp.net Thu Oct 21 22:03:56 2010 From: dwhite at olp.net (Dan White) Date: Thu, 21 Oct 2010 22:03:56 -0500 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <5127C77A-8A2E-4C24-9FD1-50A1C0E17C93@delong.com> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com> <4CC0BEE4.80302@ttec.com> <5127C77A-8A2E-4C24-9FD1-50A1C0E17C93@delong.com> Message-ID: <20101022030356.GA2648@dan.olp.net> Step 1: On 21/10/10?18:34?-0700, Owen DeLong wrote: >ROFL, Comcast is already telling their residential customers that if they want a static >IPv4 address it will cost them an extra ~$60/month. > >(Delta between residential and business: ~$55/month, single static IPv4 address on business circuit: $5/month) > >Owen Step 2: http://lists.arin.net/pipermail/arin-issued/2010-October/000675.html ~$ whois 50.128.0.0 | grep 'NetRange\|OrgName' NetRange: 50.128.0.0 - 50.255.255.255 OrgName: Comcast Cable Communications Holdings, Inc Step 3: Profit! -- Dan White From marka at isc.org Thu Oct 21 22:06:15 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 22 Oct 2010 14:06:15 +1100 Subject: IPv6 fc00::/7 - Unique local addresses In-Reply-To: Your message of "Thu, 21 Oct 2010 18:53:37 PDT." <3D230C80-E7CC-4B73-9E47-780DF5FA33AC@delong.com> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <1287701974.10216.63.camel@karl> <292AF25E62B8894C921B893B53A19D9739AF595C7D@BUSINESSEX.business.ad> <1287704885.10216.90.camel@karl> <3D230C80-E7CC-4B73-9E47-780DF5FA33AC@delong.com> Message-ID: <20101022030615.5DD045F6039@drugs.dv.isc.org> In message <3D230C80-E7CC-4B73-9E47-780DF5FA33AC at delong.com>, Owen DeLong write s: > > On Oct 21, 2010, at 4:48 PM, Karl Auer wrote: > > > On Fri, 2010-10-22 at 10:10 +1100, Skeeve Stevens wrote: > >> Where does the 6K come from? > >> > >> AUD$4,175 is the amount - It consists of the "Associate Member > >> Fee" (AUD 675) and the IP Resource Application Fee (AUD 3,500) > >> > >> Then AUD1180 for a /48 each year. > > > > Er - apologies. Yes, the initial fee covers the first year's annual fee, > > so it's $4175 in the first year ans $1100 in subsequent years. > > > > The point still stands though - that's WAY too much for home users. > > > > While for Owen such costs might be doable, for the vast majority of home > > users in the AP region the only viable alternatives for internal > > addressing will be PA or ULA. > > > This is NANOG. To the best of my knowledge, no part of the NA in NANOG > is in the APNIC service area. > > ARIN pricing is significantly better at US$100/year for ALL end-user > resources, so, only the $1250 up-front fee would apply and apparently > the partial fee-waiver for that is still in effect if your previous posting > was correct. Which is still too expensive for the home user. > > Even with the lower costs that ARIN users pay, the prices are still IMHO > > too high for home users to be using PI in any significant numbers. > > > Really? $100/year is too much? Really? I guess that depends on whether > you think addresses are worth more than coffee. ;-) $100/year for a address block that nobody will route and requires someone to setup the address selection rules compared to a ULA at $0 that the OS vendors will make work well by default. > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From gbonser at seven.com Thu Oct 21 22:20:25 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 20:20:25 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses) In-Reply-To: <20101022025320.GA94206@ussenterprise.ufp.org> References: <4CBF63BF.2000101@mompl.net><4CC070E9.7090709@unfix.org><5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <20101022025320.GA94206@ussenterprise.ufp.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C426@RWC-EX1.corp.seven.com> > From: Leo Bicknell > Sent: Thursday, October 21, 2010 7:53 PM > To: NANOG list > Subject: Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 > fc00::/7 -Unique local addresses) > > What makes it all possible is the same prefix length internally and > from all providers. It's a reason why /48 could be important. Right. /48 is the secret sauce in that. What you could do is: Assume a new connection to a destination you have not spoken to yet. SYN arrives from the inside machine trying to connect out. NAT box sends a SYN from each of the NATed IPs for the upstream providers. The one that returns first "wins" and that is the prefix you use to NAT that connection, the other one gets RST. You remember which upstream is associated with that connection for some period of time and reuse it. After some period of time elapses you would "forget" and test again on a new connection attempt. That at least gives you assurance the remote site has a path back to that IP and you are going with the higher performing path. You might even have an option to "nail" certain inside IPs to a certain path or certain remote destinations to a certain path. > Given all effort put into "better" multihoming in IPv6 I'm really > surprised this simple solution which basically exists in code today > (porting an IPv4 NAT to IPv6, if there is no PAT, is easy). It would seem that simply translating the source /48 would be simple enough but would probably break something. Might break some Microsoft secure connection protocols where the IP in the header doesn't match the reported IP inside the packet, though, but that could probably be fixed, too. From marka at isc.org Thu Oct 21 22:25:53 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 22 Oct 2010 14:25:53 +1100 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: Your message of "Thu, 21 Oct 2010 18:33:56 PDT." <4BC01459-B53A-4B2C-B75B-47D89550DFC5@delong.com> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <20101021120648.1872981a@opy.nosense.org> <20101021221539.1E52A5F3641@drugs.dv.isc.org> <4BC01459-B53A-4B2C-B75B-47D89550DFC5@delong.com> Message-ID: <20101022032553.E5C3A5F635F@drugs.dv.isc.org> In message <4BC01459-B53A-4B2C-B75B-47D89550DFC5 at delong.com>, Owen DeLong write s: > > On Oct 21, 2010, at 3:15 PM, Mark Andrews wrote: > > >=20 > > In message , Owen = > DeLong write > > s: > >>>>>=20 > >>>> Which is part one of the three things that have to happen to make = > ULA > >>>> really bad for the internet. > >>>>=20 > >>>> Part 2 will be when the first provider accepts a large sum of money = > to > >>>> route it within their public network between multiple sites owned = > by > >>>> the same customer. > >>>>=20 > >>>=20 > >>> That same customer is also going to have enough global address > >>> space to be able to reach other global destinations, at least enough > >>> space for all nodes that are permitted to access the Internet, if = > not > >>> more. Proper global address space ensures that if a global = > destination > >>> is reachable, then there is a high probability of successfully = > reaching > >>> it. The scope of external ULA reachability, regardless of how much > >>> money is thrown at the problem, isn't going to be as good as proper > >>> global addresses. > >>>=20 > >> _IF_ they implement as intended and as documented. As you've > >> noted there's a lot of confusion and a lot of people not reading the > >> documents, latching onto ULA and deciding ti's good. > >>=20 > >> It's not a big leap for some company to do a huge ULA deployment > >> saying "this will never connect to the intarweb thingy" and 5-10 = > years > >> later not want to redeploy all their addressing, so, they start = > throwing > >> money at getting providers to do what they shouldn't instead of > >> readdressing their networks. > >=20 > > IPv4 think. > >=20 > > You don't re-address you add a new address to every node. IPv6 is > > designed for multiple addresses. > >=20 > That's a form of re-addressing. It's not removing the old addresses, = > but, > it is a major undertaking just the same in a large deployment. I don't see any major difference in the amount of work required to go from disconnected ULA to ULA + PA/PI or ULA + NAT compared to disconnected PI to connected PI. Whether the machines have one or two address is inconsequential in the grand scheme of things. > >>> For private site interconnect, I'd think it more likely that the > >>> provider would isolate the customers traffic and ULA address space = > via > >>> something like a VPN service e.g. MPLS, IPsec. > >>>=20 > >> One would hope, but, I bet laziness and misunderstanding trumps > >> reason and adherence to RFCs over the long term. Since ULA > >> won't get hard-coded into routers as unroutable (it can't), > >=20 > > Actually it can be. You just need a easy switch to turn it off. The > > router can even work itself out many times. Configure multiple = > interfaces > > from the same ULA /48 and you pass traffic for the /48 between those > > interfaces. You also pass routes for that /48 via those interfaces. > >=20 > If you have an easy switch to turn it off, it will get used, thus = > meaning that > it isn't hard coded, it's just default. On by default will create a effective deterrent. > >=20 > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bmanning at vacation.karoshi.com Thu Oct 21 22:32:27 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Oct 2010 03:32:27 +0000 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> Message-ID: <20101022033227.GA7557@vacation.karoshi.com.> The IPv4 space here was retired in 2009. We love the IVI translator code. Whats keeping the rest of you? --bill From adrian at creative.net.au Thu Oct 21 22:38:42 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 22 Oct 2010 11:38:42 +0800 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: <20101022025320.GA94206@ussenterprise.ufp.org> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <20101022025320.GA94206@ussenterprise.ufp.org> Message-ID: <20101022033842.GA17822@skywalker.creative.net.au> On Thu, Oct 21, 2010, Leo Bicknell wrote: > If you could number your internal network out of some IPv6 space > (possibly 1918 style, possibly not), probably a /48, and then get > from your two (or more) upstreams /48's of PA space you could do > 1:1 NAT. No PAT, just pure address translation, 1:1. > > You can "renumber" by configuring a new outside translation. The > NAT box can do the load distribution functions discussed here, some > users out one provider, others out the second provider. There is > no port complication, so incoming connections are much simpler. You assume the protocol(s) don't include IP addresses inside the payload. You also assume the protocol(s) don't do things like checksum application payloads, which include IP addresses. Both of which I've seen, today. Some of which I occasionally see inside, hm, "over-enthusiastic" HTTP procotol/application designers. NAT's going to be needed, but it's going to be more stateful inspection-y than most of the vocal nanog+ipv6 people desire. :) Adrian From adrian at creative.net.au Thu Oct 21 22:40:29 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Fri, 22 Oct 2010 11:40:29 +0800 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <20101022033227.GA7557@vacation.karoshi.com.> References: <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> Message-ID: <20101022034029.GB17822@skywalker.creative.net.au> On Fri, Oct 22, 2010, bmanning at vacation.karoshi.com wrote: > The IPv4 space here was retired in 2009. We love the IVI > translator code. Whats keeping the rest of you? Just hazarding a guess: router# conf t router(config)# ipv6 ivi enable router(config)# ^Z Adrian From bmanning at vacation.karoshi.com Thu Oct 21 22:43:08 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Oct 2010 03:43:08 +0000 Subject: cost of IPv4 In-Reply-To: <5AD6430A-A58E-4F60-8F1C-47EAA858D7ED@puck.nether.net> References: <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <20101022005322.GS45727@burnout.tpb.net> <4CC0E531.3010508@brightok.net> <19648.60973.790463.902867@world.std.com> <5AD6430A-A58E-4F60-8F1C-47EAA858D7ED@puck.nether.net> Message-ID: <20101022034308.GB7557@vacation.karoshi.com.> On Thu, Oct 21, 2010 at 10:09:39PM -0400, Jared Mauch wrote: > > On Oct 21, 2010, at 9:51 PM, Barry Shein wrote: > > > Anyhow, it might be an interesting topic to discuss in the appropriate > > venues, IETF, "What is the cost of maintaining IPv4 forever?" but it's > > getting a little ahead of ourselves in terms of any pressing need. > > > This is an interesting question. > > In talking to your vendors with your checklist of capabilities a device CAN/SHOULD/MUST have, what if you no longer needed to carry 350k/512k routes of IPv4 and only needed 256k of IPv6 ? > > Instead of 6pe think of 4pe with ipv6 core. when did Cisco stop supporting DECNET? Chaosnet? why? > I've been reminding vendors that IPv6 should get new features *first* vs IPv4. it will, when/if there are things IPv6 can do that IPv4 can't. the problem is, most folks have tied down, castrated and otherwise crippled IPv6 unique capabilities so that it would be "IPv4 with larger addresses". > The end of IPv4 is near, but that doesn't mean the end of the Internet is here. The next chapter gets a new page turned. Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world. you predict the end of IPv4 ... and someone will take your money unless you go out a few years. > > Either way, it's an interesting time to be an edge operator that worries about CPE stuff. those that think mostly about core this is a big fat *yawn* imho. Expect application developers to face some interesting challenges. me? I'm waiting until I see the "NOW WITH IPv6" sticker on things at the store. IPv6-ready logos exist. > > - Jared From bmanning at vacation.karoshi.com Thu Oct 21 22:48:04 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Oct 2010 03:48:04 +0000 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <20101022034029.GB17822@skywalker.creative.net.au> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> Message-ID: <20101022034804.GC7557@vacation.karoshi.com.> On Fri, Oct 22, 2010 at 11:40:29AM +0800, Adrian Chadd wrote: > On Fri, Oct 22, 2010, bmanning at vacation.karoshi.com wrote: > > > The IPv4 space here was retired in 2009. We love the IVI > > translator code. Whats keeping the rest of you? > > Just hazarding a guess: > > router# conf t > router(config)# ipv6 ivi enable > router(config)# ^Z not so much - it runs on linux instead of a closed OS. #ifconfig eth0 #ifconfig eth0 #ifconfig eth1 #ivi eth0 eth1 & gets me native IPv6 to IPv6 speakers and translates back into the Internet for those stuck in the smallisher Internet. --bill > > > > Adrian From kauer at biplane.com.au Thu Oct 21 22:51:54 2010 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 22 Oct 2010 14:51:54 +1100 Subject: IPv6 fc00::/7 =?UTF-8?Q?=E2=80=94?= Unique local addresses In-Reply-To: <82AF7E03-CCDD-4D15-B1B3-546A7F9F248D@delong.com> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <1287701974.10216.63.camel@karl> <82AF7E03-CCDD-4D15-B1B3-546A7F9F248D@delong.com> Message-ID: <1287719514.10216.121.camel@karl> On Thu, 2010-10-21 at 18:48 -0700, Owen DeLong wrote: > Uh, no... You're misreading it. Yes - I read the ISP bit, not the end user bit. > It cost me $625 (or possibly less) one-time when I first got it. That was with the waivers in force. It will soon cost a one-time US $1250. We could argue till the cows come home about what proportion of the population would consider that "prohibitive" but I'm guessing that even in the USA that's a heck of an entry fee, and that the vast majority of non-corporate end users will not be willing to pay it. Which is the actual point, rather than quibbling about the precise price. > I bet you spend more than [US$100] at Starbucks each year. You lose! The nearest Starbucks to me[1] is approximately 700km distant :-) Please transfer AUS$4175 immediately, bank details under separate cover :-) Regards, K. [1] According to the online Starbucks store locator... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From jbates at brightok.net Thu Oct 21 22:52:32 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 21 Oct 2010 22:52:32 -0500 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <20101022034804.GC7557@vacation.karoshi.com.> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> Message-ID: <4CC10A80.8070009@brightok.net> On 10/21/2010 10:48 PM, bmanning at vacation.karoshi.com wrote: > > not so much - it runs on linux instead of a closed OS. I think you missed the point. Many are waiting for it to be supported on their brand of routers. Not everyone has huge numbers of servers sitting around acting as translation gateways (or spying on traffic). Jack From marka at isc.org Thu Oct 21 22:57:49 2010 From: marka at isc.org (Mark Andrews) Date: Fri, 22 Oct 2010 14:57:49 +1100 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: Your message of "Thu, 21 Oct 2010 18:43:46 PDT." References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <20101021225202.CE2205F376D@drugs.dv.isc.org> Message-ID: <20101022035749.BBA285F64A2@drugs.dv.isc.org> In message , Owen DeLong write s: > >>> > >> I keep hearing this and it never makes sense to me. > >> > >> If your provider will assign you a static /48, then, you have stable > >> addresses when your provider link is down in GUA. Who needs ULA? > > > > You used the word "if". Reverse the sense of the "if" and see if > > it still doesn't makes sense to use ULA addresses. I get a mostly > > stable IPv4 address from my cable provider (DHCP). That address > > changes without notice about once a year. I can configure a 6to4 > > prefix based on that address (effectively a PA prefix). I use ULA > > addresses internally and 6to4 (PA) externally. Same for 6rd. Same > > for PD. > > > I use the dynamic address from my cable provider to terminate a set > of GRE tunnels to my colo routers. < > I use the static address from my DSL provider to terminate other > GRE tunnels to my colo routers. > > The DSL tunnels are all carrying both IPv4 and IPv6. > > When the cable address changes, the BGP sessions over those > GRE tunnels drop and my network connection slows down. > When I repair the tunnels with the new end-point address, > everything goes back to fast. You've gone way past what the average home user can or should be expected to handle here. Your well into advanced user territory. I've done the same sort of thing but I don't see myself as a average home user. The average home user should be able to plug in a home router into the network connection from the ISP. Plug that into a 10/100/1000 switch or turn on WiFi and plug in there hosts / enable WiFi on the hosts and have the network work regardless of whether the upstream is working or not. If they have bought the multi-upstream router then plug all isps in (Cable/DSL/WiMax/....) and have the whole thing work regardless of how many upstream links are working. > > DHCP derived 6to4, DHCP derived 6rd, DHCP derived Terado and PD all > > give you leased prefixes. They are not guarenteed to be STABLE. > > For internal communication you really do want stable prefixes. ULA > > gives you those stable prefixes. > > Yep... Makes much more sense to have at least one provider with static > and do native IPv6 than to use 6to4, 6rd, Teredo, or PD. Well when you can get agreements from all the residential ISPs to provide static IPv6 address come back to me. In the meantime I'm going to plan how to handle non static assignments, > >>> You talk to the world using PA addresses, directly for IPv6 and > >>> indirectly via PNAT for IPv4. These can change over time. > >>> =3D20 > >> Or, if you don't want your IPv6 addresses to change over time, you = > can > >> get a prefix from your friendly RIR. > > > > You really think I'm going to go to my RIR and get a addresses block > > for my home network then my cable provider will route it for me? > > > No... I think you might go to your RIR and get an address block > for your home network then find a way to use your cable provider > for L2 transport and route it. That solution works quite well for me. You still had to have someone route it somewhere be it the cable provider or someone else you reach over the cable provider. > >>> Similarly, ULA + 6to4 works well provided the 6to4 works when you > >>> are connected. When your IPv4 connection is renumbered you have a > >>> new external addresses but the internal addresses stay the same. > >>> > >> That's a big "provided that"... > > > > Not really. It works for lots of people. > > > Then how come I hear a lot more 6to4 horror stories than 6to4 > success stories? It's not like I don't talk to lots of people using > these protocols on a daily basis. Because people complain when things break. They are silent when things work. > > And you expect the routing system to cope when 2 billion homes do the > > same thing? > > As a matter of fact, I think the routing system damn well better start > planning to cope with just that scenario. I think it is inevitable in > one form or another. > > Owen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From bmanning at vacation.karoshi.com Thu Oct 21 23:10:08 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Oct 2010 04:10:08 +0000 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <4CC10A80.8070009@brightok.net> References: <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <4CC10A80.8070009@brightok.net> Message-ID: <20101022041008.GA7662@vacation.karoshi.com.> On Thu, Oct 21, 2010 at 10:52:32PM -0500, Jack Bates wrote: > On 10/21/2010 10:48 PM, bmanning at vacation.karoshi.com wrote: > > > > not so much - it runs on linux instead of a closed OS. > I think you missed the point. Many are waiting for it to be supported on > their brand of routers. Not everyone has huge numbers of servers sitting > around acting as translation gateways (or spying on traffic). true dat. but there was also a subtext on CPE kit. not all of us are big telcos or buy IP service from same. to paraphrase Dave, if ATT decides to drop IPv4 support, sigh its a pita, but I don't -NEED- ATT IP services. I can get much/most of what I want/need w/ a little work/elbow greese. if the goal was to scare people w/ a very public "retirement" date for IPv4 - then maybe it worked. As for me, the retirement date was a year or so back. No worries here. if folks fit the model described above, the rock is new/untested code (IPv6 support) and the hard place is NAT (still going to need it in a mixed v4/v6 world) ... If there are NAT functions w/ tested code paths that have already passed QA, then that becomes an easier sell to mgmt - no? And ATT realises that 99.982% of its customers could care less if its IPv4 or IPv6 or IPX... They just know (cause ATT told them) that the Internet grew out of the World Wide Web... and that is what they need with their i[fone/pad/pod/tv]. ATT will find a way to keep its costs down and provide the functionality demanded by its customers. > > > Jack From tme at americafree.tv Thu Oct 21 23:27:46 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 22 Oct 2010 00:27:46 -0400 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <20101022041008.GA7662@vacation.karoshi.com.> References: <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <4CC10A80.8070009@brightok.net> <20101022041008.GA7662@vacation.karoshi.com.> Message-ID: On Oct 22, 2010, at 12:10 AM, bmanning at vacation.karoshi.com wrote: > On Thu, Oct 21, 2010 at 10:52:32PM -0500, Jack Bates wrote: >> On 10/21/2010 10:48 PM, bmanning at vacation.karoshi.com wrote: >>> >>> not so much - it runs on linux instead of a closed OS. >> I think you missed the point. Many are waiting for it to be supported on >> their brand of routers. Not everyone has huge numbers of servers sitting >> around acting as translation gateways (or spying on traffic). > > true dat. but there was also a subtext on CPE kit. > > not all of us are big telcos or buy IP service from same. > > to paraphrase Dave, if ATT decides to drop IPv4 support, > sigh its a pita, but I don't -NEED- ATT IP services. > I can get much/most of what I want/need w/ a little work/elbow > greese. > > if the goal was to scare people w/ a very public "retirement" date > for IPv4 - then maybe it worked. As for me, the retirement date > was a year or so back. No worries here. > > if folks fit the model described above, the rock is new/untested > code (IPv6 support) and the hard place is NAT (still going to need > it in a mixed v4/v6 world) ... If there are NAT functions w/ > tested code paths that have already passed QA, then that becomes > an easier sell to mgmt - no? > > And ATT realises that 99.982% of its customers > could care less if its IPv4 or IPv6 or IPX... They just know > (cause ATT told them) that the Internet grew out of the World > Wide Web... and that is what they need with their i[fone/pad/pod/tv]. > > ATT will find a way to keep its costs down and provide the functionality > demanded by its customers. It seems to me that it would be very scary for AT&T for AT&T to say, "we will shut off IPv4 in X years, prepare now" - what if provider X starts running ads saying "AT&T doesn't want your business, but we do and will keep you happy." So, unless one provider really becomes dominate in 10-15 years, I don't see that happening. If providers X, Y and Z band together to do this, I see anti-Trust issues (although IANAL). I can't see an SDO like the IETF doing this (and the IETF is not immune to anti-trust, either). So, if we go down this road, the only real path I see involves some government (US, EU, maybe in 15 years even the PRC) or some set of governments mandating it. Whether that would be a good thing is left as an exercise to the reader. Regards Marshall >> >> >> Jack > > From morrowc.lists at gmail.com Thu Oct 21 23:48:35 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 22 Oct 2010 00:48:35 -0400 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <20101022034804.GC7557@vacation.karoshi.com.> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> Message-ID: (bill is a tease) On Thu, Oct 21, 2010 at 11:48 PM, wrote: > On Fri, Oct 22, 2010 at 11:40:29AM +0800, Adrian Chadd wrote: >> On Fri, Oct 22, 2010, bmanning at vacation.karoshi.com wrote: >> >> > The IPv4 space here was retired in 2009. ?We love the IVI >> > translator code. ?Whats keeping the rest of you? >> >> Just hazarding a guess: >> >> router# conf t >> router(config)# ipv6 ivi enable >> router(config)# ^Z > > > ? ? ? ?not so much - it runs on linux instead of a closed OS. > > ? ? ? ?#ifconfig eth0 ? > ? ? ? ?#ifconfig eth0 ? > ? ? ? ?#ifconfig eth1 ? > > ? ? ? ?#ivi eth0 eth1 & > neat! I can install that on my ubuntu machine! wee! (now I'm teasing.. .Bill where's your docs on this fantastic new teknowlogie?) > ? ? ? ?gets me native IPv6 to IPv6 speakers and translates back into > ? ? ? ?the Internet for those stuck in the smallisher Internet. > > --bill > >> >> >> >> Adrian > > From kauer at biplane.com.au Thu Oct 21 23:52:08 2010 From: kauer at biplane.com.au (Karl Auer) Date: Fri, 22 Oct 2010 15:52:08 +1100 Subject: IPv6 fc00::/7 =?UTF-8?Q?=E2=80=94?= Unique local addresses In-Reply-To: <4CC0F16F.2060706@brightok.net> References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> Message-ID: <1287723128.10216.182.camel@karl> On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote: > On 10/21/2010 8:39 PM, Ray Soucy wrote: > > > > How so? We still have RA (with a high priority) that's the only way > > DHCPv6 works. I guess there is a lot of misunderstanding about how > > DHCPv6 works, even among the experts... > > Actually, the last I checked, there are implementation of DHCPv6 without RA. I'll go out on a limb here and say that RA is not needed for DHCPv6. A DHCPv6 client multicasts all its messages to the well-known all-relays-and-servers address. A client needs only its link-local address to do this. The relay (or server if it happens to be on the same link) can thus talk to the client in the complete absence of RA. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From joelja at bogus.com Fri Oct 22 00:20:05 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Thu, 21 Oct 2010 22:20:05 -0700 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance?= =?windows-1252?Q?_=28Was=3A_IPv6_fc00=3A=3A/7_=97_Unique_loc?= =?windows-1252?Q?al_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> Message-ID: <4CC11F05.50109@bogus.com> On 10/21/10 6:38 PM, Owen DeLong wrote: > > On Oct 21, 2010, at 3:42 PM, Jack Bates wrote: > >> On 10/21/2010 5:27 PM, Joel Jaeggli wrote: >>> >>> Announce your gua and then blackhole it and monitor your prefix. >>> you can tell if you're leaking. it's generally pretty hard to >>> tell if you're leaking rfc 1918 since your advertisement may well >>> work depending on the filters of your peers but not very far. >> >> This is always the argument I hear from corporate customers >> concerning wanting NAT. If mistake is made, the RFC 1918 space >> isn't routable. They often desire the same out of v6 for that >> reason alone. the rfc 1918 space is being routed inside almost all your adjacent networks, so if their ingress filtering is working as expected, great, but you're only a filter away from leaking. > Given the number of times and the distance over which I have seen > RFC-1918 routes propagate, this belief is false to begin with, so, > removing this false sense of security is not necessarily a bad > thing. this happened this morning in a pop we have in the far east... packets ended up in atlanta. what's more, the return path was natted. >> I personally could understand the fear of wondering if your >> stateful firewall is properly working and doing it's job and how a >> simple mistake could have disastrous effects that NAT systems >> usually don't have. ULA w/ NAT very well may become the norm. >> > > I tend to doubt that it will... Hopefully there will be enough proper > deployments that developers will not eschew improvements that depend > on an end-to-end model and there will be real features unavailable to > any network that deploys such relatively quickly. > > The tragedy won't be networks deploying NAT. I'm all for allowing you > to buy a gun, ammunition, and aim at your foot or head as you wish. > > The tragedy will be if enough networks do this to hobble development > of truly useful tools that depend on a NAT-free environment to work. > > Owen > > > From gbonser at seven.com Fri Oct 22 00:20:16 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 22:20:16 -0700 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: References: <4CC0553C.8060202@zill.net><20101021153012.GE2843@dan.olp.net><7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv><20101022033227.GA7557@vacation.karoshi.com.><20101022034029.GB17822@skywalker.creative.net.au><20101022034804.GC7557@vacation.karoshi.com.> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM > To: bmanning > Cc: NANOG > Subject: Re: IPv4 sunset date revised : 2009-02-05 > > (now I'm teasing.. .Bill where's your docs on this fantastic new > teknowlogie?) > I found it here: http://www.ivi2.org/ But the readme is a bit confusing: http://www.ivi2.org/code/00-ivi0.5-README Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix assuming the mapping is to be 1-1 It seems the docs are a bit sparse and the kernel version is rather ancient (patches against 2.6.18) From gbonser at seven.com Fri Oct 22 00:46:30 2010 From: gbonser at seven.com (George Bonser) Date: Thu, 21 Oct 2010 22:46:30 -0700 Subject: DHS and NSA getting married? Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> An agreement signed this month with the Department of Homeland Security and an earlier initiative to protect companies in the defense industrial base make it likely that the military will be a key part of any response to a cyber attack. While the Department of Homeland Security officially remains the lead government agency on cyber defense, the new agreement "sets up an opportunity for DHS to take advantage of the expertise" in the Pentagon, and particularly the secretive electronic spying agency, the National Security Agency, said Butler, who is a deputy assistant defense secretary. The two agencies - Defense and Homeland Security - "will help each other in more tangible ways then they have in the past," Butler told a group of defense reporters. Among other things, a senior DHS cyber official and other DHS employees will move to the NSA to be closer to the heart of the military's cyber defense capability. Closer collaboration provides "an opportunity to look at new ways that we can do national cyber incident response, he said. http://www.defensenews.com/story.php?i=4939254&c=AME&s=TOP From swmike at swm.pp.se Fri Oct 22 01:34:46 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 22 Oct 2010 08:34:46 +0200 (CEST) Subject: Recommendations for Metro-Ethernet Equipment In-Reply-To: References: <022801cb706a$ead9d5e0$c08d81a0$@net> <5294CF7C-E618-41E5-ACFB-E299CD25A5E5@beanfield.com> <042e01cb7152$f285e7f0$d791b7d0$@net> Message-ID: On Thu, 21 Oct 2010, Ramanpreet Singh wrote: > To be fair, Our hardware was EOL, I am not sure if they have improved > but then we migrated all our equiment in 2008-2009. Extreme Networks had a lot of memory chip problems for equipment manufacturered ~2000-2002. They improved a lot after that. -- Mikael Abrahamsson email: swmike at swm.pp.se From swmike at swm.pp.se Fri Oct 22 01:36:09 2010 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 22 Oct 2010 08:36:09 +0200 (CEST) Subject: =?UTF-8?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=E2=80=94_Unique_local_addresses?= In-Reply-To: <1287701974.10216.63.camel@karl> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <4CBF8782.2040301@mompl.net> <4CBFC1D0.60808@apolix.co.za> <20101021052852.A46E75F0E6C@drugs.dv.isc.org> <859028C2-9ED9-43FF-AAF9-6E2574048016@delong.com> <1287701974.10216.63.camel@karl> Message-ID: On Fri, 22 Oct 2010, Karl Auer wrote: > Fairly trivial amounts for most commercial entities, but prohibitive for > all but the most enthusiastic home user. Perfect. Let's not pollute DFZ more than needed. -- Mikael Abrahamsson email: swmike at swm.pp.se From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Oct 22 02:31:24 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 22 Oct 2010 18:01:24 +1030 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <5AD6430A-A58E-4F60-8F1C-47EAA858D7ED@puck.nether.net> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <20101022005322.GS45727@burnout.tpb.net> <4CC0E531.3010508@brightok.net> <19648.60973.790463.902867@world.std.com> <5AD6430A-A58E-4F60-8F1C-47EAA858D7ED@puck.nether.net> Message-ID: <20101022180124.6cdc6aa4@opy.nosense.org> On Thu, 21 Oct 2010 22:09:39 -0400 Jared Mauch wrote: > > On Oct 21, 2010, at 9:51 PM, Barry Shein wrote: > > > Anyhow, it might be an interesting topic to discuss in the appropriate > > venues, IETF, "What is the cost of maintaining IPv4 forever?" but it's > > getting a little ahead of ourselves in terms of any pressing need. > > > This is an interesting question. > > In talking to your vendors with your checklist of capabilities a device CAN/SHOULD/MUST have, what if you no longer needed to carry 350k/512k routes of IPv4 and only needed 256k of IPv6 ? > > Instead of 6pe think of 4pe with ipv6 core. > > I've been reminding vendors that IPv6 should get new features *first* vs IPv4. The end of IPv4 is near, but that doesn't mean the end of the Internet is here. The next chapter gets a new page turned. Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world. > > Either way, it's an interesting time to be an edge operator that worries about CPE stuff. those that think mostly about core this is a big fat *yawn* imho. Expect application developers to face some interesting challenges. me? I'm waiting until I see the "NOW WITH IPv6" sticker on things at the store. > If you go into the right store, you'll see one. http://forums.whirlpool.net.au/forum-replies.cfm?t=1470849&p=5#r83 > - Jared From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Oct 22 02:55:18 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 22 Oct 2010 18:25:18 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: <1287723128.10216.182.camel@karl> References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> Message-ID: <20101022182518.64924b44@opy.nosense.org> On Fri, 22 Oct 2010 15:52:08 +1100 Karl Auer wrote: > On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote: > > On 10/21/2010 8:39 PM, Ray Soucy wrote: > > > > > > How so? We still have RA (with a high priority) that's the only way > > > DHCPv6 works. I guess there is a lot of misunderstanding about how > > > DHCPv6 works, even among the experts... > > > > Actually, the last I checked, there are implementation of DHCPv6 without RA. > > I'll go out on a limb here and say that RA is not needed for DHCPv6. > RAs are still needed to convey the M/O bit values, so that end-nodes know they need to use DHCPv6 if necessary. As there are two address configuration methods, there is always going to be a need to express a policy to end-nodes as to which one they need to use. > A DHCPv6 client multicasts all its messages to the well-known > all-relays-and-servers address. A client needs only its link-local > address to do this. The relay (or server if it happens to be on the same > link) can thus talk to the client in the complete absence of RA. > There isn't a method to specify a default gateway in DHCPv6. Some people want it, however it seems a bit pointless to me if you're going to have RAs announcing M/O bits anyway - you may as well use those RAs to announce a default router too. Regards, Mark. From owen at delong.com Fri Oct 22 03:10:08 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 22 Oct 2010 01:10:08 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101022182518.64924b44@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> Message-ID: On Oct 22, 2010, at 12:55 AM, Mark Smith wrote: > On Fri, 22 Oct 2010 15:52:08 +1100 > Karl Auer wrote: > >> On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote: >>> On 10/21/2010 8:39 PM, Ray Soucy wrote: >>>> >>>> How so? We still have RA (with a high priority) that's the only way >>>> DHCPv6 works. I guess there is a lot of misunderstanding about how >>>> DHCPv6 works, even among the experts... >>> >>> Actually, the last I checked, there are implementation of DHCPv6 without RA. >> >> I'll go out on a limb here and say that RA is not needed for DHCPv6. >> > > RAs are still needed to convey the M/O bit values, so that end-nodes > know they need to use DHCPv6 if necessary. As there are two address > configuration methods, there is always going to be a need to express a > policy to end-nodes as to which one they need to use. > You can actually force a client to assume the M bit if you cause it to launch a DHCPv6 client through other means. You don't have to have RA for that. Policy can be expressed by RA, or, it can be expressed by other means. >> A DHCPv6 client multicasts all its messages to the well-known >> all-relays-and-servers address. A client needs only its link-local >> address to do this. The relay (or server if it happens to be on the same >> link) can thus talk to the client in the complete absence of RA. >> > > There isn't a method to specify a default gateway in DHCPv6. Some > people want it, however it seems a bit pointless to me if you're going > to have RAs announcing M/O bits anyway - you may as well use those RAs > to announce a default router too. > Actually, it's not pointless at all. The RA system assumes that all routers capable of announcing RAs are default routers and that virtually all routers are created equal (yes, you have high/medium/low, but, really, since you have to use high for everything in any reasonable deployment...) There are real environments where it's desirable to have a way to tell different clients on a network to use different default gateways or default gateway sets. Owen From jmamodio at gmail.com Fri Oct 22 06:39:36 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Fri, 22 Oct 2010 06:39:36 -0500 Subject: cost of IPv4 In-Reply-To: <20101022034308.GB7557@vacation.karoshi.com.> References: <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <20101022005322.GS45727@burnout.tpb.net> <4CC0E531.3010508@brightok.net> <19648.60973.790463.902867@world.std.com> <5AD6430A-A58E-4F60-8F1C-47EAA858D7ED@puck.nether.net> <20101022034308.GB7557@vacation.karoshi.com.> Message-ID: >> The end of IPv4 is near, but that doesn't mean the end of the Internet is here. ?The next chapter gets a new page turned. ?Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world. IMHO, there is no such thing like "the end of IPv4 is near", what is near is the exhaustion of the IPv4 address space for new allocations. Unfortunately, as Bill mentioned, IPv6 does not offer much more than an expanded address space, quite a different situation with the proprietary protocols you mentioned, then there is no much benefit/motivation for many to switch in a hurry. No doubt that we need to move forward and keep pushing to get IPv6 deployed, but it will coexist for many many years with IPv4 which will probably never go 100% away. My .02 Jorge From mpetach at netflight.com Fri Oct 22 07:05:23 2010 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 22 Oct 2010 05:05:23 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <5127C77A-8A2E-4C24-9FD1-50A1C0E17C93@delong.com> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com> <4CC0BEE4.80302@ttec.com> <5127C77A-8A2E-4C24-9FD1-50A1C0E17C93@delong.com> Message-ID: On Thu, Oct 21, 2010 at 6:34 PM, Owen DeLong wrote: > On Oct 21, 2010, at 3:29 PM, Joe Maimon wrote: >> Matthew Petach wrote: >> >>> So...uh...who's going to be first to step up and tell their customers >>> "look, you get a v6 /56 for free with your account, but if you want >>> v4 addresses, it's going to cost an extra $50/month." ?? >>> >>> Matt >>> >> >> Either the telephone company or the cable company. Probably both. Give me a harder one. >> >> Joe >> > > ROFL, Comcast is already telling their residential customers that if they want a static > IPv4 address it will cost them an extra ~$60/month. > > (Delta between residential and business: ~$55/month, single static IPv4 address on business circuit: $5/month) > > Owen *sigh* But what's the delta for getting the equivalent IPv6 resource? You're comparing apples to oranges. If comcast says "you get a static /56 of v6 for free, but a static v4 address costs $55/month", then I can see you point. But right now, the delta is between dynamic v4 (free) and static v4 ($55), with no delta between dynamic v4 (free) and dynamic v6 (free), and no option that I've seen for static v4 ($55) vs static v6 ($???). It's those last two cases that would drive the deprecation of v4 over time; and *that* is the step I don't foresee any provider wanting to do; certainly, not being first up to the plate to do. Matt From rps at maine.edu Fri Oct 22 07:12:36 2010 From: rps at maine.edu (Ray Soucy) Date: Fri, 22 Oct 2010 08:12:36 -0400 Subject: =?windows-1252?Q?Re=3A_IPv6_fc00=3A=3A=2F7_=97_Unique_local_addresses?= In-Reply-To: <4CC0F16F.2060706@brightok.net> References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> Message-ID: The design of IPv6 is that DHCPv6 and RA work together. This is why there is no method to express the default gateway using DHCPv6, that task is handled by the RA. I suppose you could run DHCPv6 on a subnet to give hosts addresses but never give them a default gateway, but that would be a little useless no? Please stop confusing people about DHCPv6. There is already enough misinformation out there. It's starting to feel like Fox News here, next there will be another post citing yours saying "experts on NANOG have said that DHCPv6 doesn't require RA" and make users spend hours looking for how to set the gateway address. On Thu, Oct 21, 2010 at 10:05 PM, Jack Bates wrote: > On 10/21/2010 8:39 PM, Ray Soucy wrote: >> >> How so? We still have RA (with a high priority) that's the only way >> DHCPv6 works. ?I guess there is a lot of misunderstanding about how >> DHCPv6 works, even among the experts... > > Actually, the last I checked, there are implementation of DHCPv6 without RA. > > > Jack > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From bill at herrin.us Fri Oct 22 07:25:10 2010 From: bill at herrin.us (William Herrin) Date: Fri, 22 Oct 2010 08:25:10 -0400 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance_=28Was=3A_IPv6_fc00=3A=3A=2F?= =?windows-1252?Q?7_=97_Unique_local_addresses=29?= In-Reply-To: <4CC11F05.50109@bogus.com> References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> <4CC11F05.50109@bogus.com> Message-ID: On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli wrote: > On 10/21/10 6:38 PM, Owen DeLong wrote: >> On Oct 21, 2010, at 3:42 PM, Jack Bates wrote: >>> On 10/21/2010 5:27 PM, Joel Jaeggli wrote: >>>> >>>> Announce your gua and then blackhole it and monitor your prefix. >>>> you can tell if you're leaking. it's generally pretty hard to >>>> tell if you're leaking rfc 1918 since your advertisement may well >>>> work depending on the filters of your peers but not very far. >>> >>> This is always the argument I hear from corporate customers >>> concerning wanting NAT. If ?mistake is made, the RFC 1918 space >>> isn't routable. They often desire the same out of v6 for that >>> reason alone. > > the rfc 1918 space is being routed inside almost all your adjacent > networks, so if their ingress filtering is working as expected, great, > but you're only a filter away from leaking. A filter away from leaking to -one- of the millions of entities on the internet. Two filters away from leaking to two. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From jmaimon at ttec.com Fri Oct 22 08:24:34 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 22 Oct 2010 09:24:34 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com> <4CC0BEE4.80302@ttec.com> <5127C77A-8A2E-4C24-9FD1-50A1C0E17C93@delong.com> Message-ID: <4CC19092.7000207@ttec.com> Matthew Petach wrote: > On Thu, Oct 21, 2010 at 6:34 PM, Owen DeLong wrote: >> On Oct 21, 2010, at 3:29 PM, Joe Maimon wrote: >>> Matthew Petach wrote: >>> >>>> So...uh...who's going to be first to step up and tell their customers >>>> "look, you get a v6 /56 for free with your account, but if you want >>>> v4 addresses, it's going to cost an extra $50/month." ?? >>>> >>>> Matt >>>> >>> >>> Either the telephone company or the cable company. Probably both. Give me a harder one. >>> >>> Joe >>> >> >> ROFL, Comcast is already telling their residential customers that if they want a static >> IPv4 address it will cost them an extra ~$60/month. >> >> (Delta between residential and business: ~$55/month, single static IPv4 address on business circuit: $5/month) >> >> Owen > > *sigh* > > But what's the delta for getting the equivalent IPv6 resource? > You're comparing apples to oranges. > > If comcast says "you get a static /56 of v6 for free, but a static v4 > address costs $55/month", > then I can see you point. > > But right now, the delta is between dynamic v4 (free) and static v4 ($55), > with no delta between dynamic v4 (free) and dynamic v6 (free), and no > option that I've seen for static v4 ($55) vs static v6 ($???). > > It's those last two cases that would drive the deprecation of v4 over time; and > *that* is the step I don't foresee any provider wanting to do; certainly, not > being first up to the plate to do. > > Matt > How about when they put new users behind CGN/LSN? Depending on how successful that is (for them), the delta can change dramatically. It would be private v4 free, public v6 free (we hope), public v4 (static or dynamic) for $(?+). Further dependent is what they will do to existing users. I can see them choosing to be fair and making all users suffer equivalently. I can further see a potential result of huge swathes of v4 resources reusable by these companies, probably dwarfing the reclaimable resources most any other provider without a similar customer profile will have. Joe From mick at motion-wise.net Fri Oct 22 08:31:26 2010 From: mick at motion-wise.net (Mick) Date: Sat, 23 Oct 2010 00:31:26 +1100 Subject: NANOG Digest, Vol 33, Issue 122 In-Reply-To: References: Message-ID: <004501cb71ed$6e8aa940$4b9ffbc0$@motion-wise.net> Hi Jorge, What if the move to IPv6 was not too hard? What if the move to IPv6 did have some positive results? What if the move to IPv6 meant the reliance on IPv4 was significantly diminished? Would that be OK with you? Thanks, Mick -----Original Message----- From: nanog-request at nanog.org [mailto:nanog-request at nanog.org] Sent: Friday, 22 October 2010 11:00 PM To: nanog at nanog.org Subject: NANOG Digest, Vol 33, Issue 122 Send NANOG mailing list submissions to nanog at nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-request at nanog.org You can reach the person managing the list at nanog-owner at nanog.org When replying, please edit your Subject line so it is more specific than "Re: Contents of NANOG digest..." Today's Topics: 1. Re: cost of IPv4 (Jorge Amodio) ---------------------------------------------------------------------- Message: 1 Date: Fri, 22 Oct 2010 06:39:36 -0500 From: Jorge Amodio Subject: Re: cost of IPv4 To: nanog at nanog.org Message-ID: Content-Type: text/plain; charset=ISO-8859-1 >> The end of IPv4 is near, but that doesn't mean the end of the Internet is here. ?The next chapter gets a new page turned. ?Maybe we will determine that IPv6 needs to go the way of IPX/Decnet/AppleTalk and some new system (non-IP even) will take over the world. IMHO, there is no such thing like "the end of IPv4 is near", what is near is the exhaustion of the IPv4 address space for new allocations. Unfortunately, as Bill mentioned, IPv6 does not offer much more than an expanded address space, quite a different situation with the proprietary protocols you mentioned, then there is no much benefit/motivation for many to switch in a hurry. No doubt that we need to move forward and keep pushing to get IPv6 deployed, but it will coexist for many many years with IPv4 which will probably never go 100% away. My .02 Jorge ------------------------------ _______________________________________________ NANOG mailing list NANOG at nanog.org https://mailman.nanog.org/mailman/listinfo/nanog End of NANOG Digest, Vol 33, Issue 122 ************************************** From bicknell at ufp.org Fri Oct 22 08:38:04 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 22 Oct 2010 06:38:04 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <20101022182518.64924b44@opy.nosense.org> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> Message-ID: <20101022133804.GA49113@ussenterprise.ufp.org> In a message written on Fri, Oct 22, 2010 at 06:25:18PM +1030, Mark Smith wrote: > There isn't a method to specify a default gateway in DHCPv6. Some > people want it, however it seems a bit pointless to me if you're going > to have RAs announcing M/O bits anyway - you may as well use those RAs > to announce a default router too. There are some folks (like me) who advocate a DHCPv6 that can convey a default gateway AND the ability to turn off RA's entirely. That is make it work like IPv4. There are pros, and cons; but I can think of a number of deployment scenarios where it would be a vast improvement and beleive strongly operators should have the choice. Unfortunately the folks in the IETF don't even want to listen, to the point a working group chair when I tried to explain why I wanted such a feater told the rest of the group "He's an operator and thus doesn't understand how any of this works, ignore him." That's when I gave up on the IETF, and started working on my vendor for the solution. -- 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 jbates at brightok.net Fri Oct 22 08:55:49 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 22 Oct 2010 08:55:49 -0500 Subject: IPv6 fc00::/7 =?windows-1252?Q?=97_Unique_local_addres?= =?windows-1252?Q?ses?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> Message-ID: <4CC197E5.10202@brightok.net> On 10/22/2010 7:12 AM, Ray Soucy wrote: > The design of IPv6 is that DHCPv6 and RA work together. This is why > there is no method to express the default gateway using DHCPv6, that > task is handled by the RA. I suppose you could run DHCPv6 on a subnet > to give hosts addresses but never give them a default gateway, but > that would be a little useless no? > Works great when you don't need routing. DHCPv6 doesn't have an option for a default gateway/router There. No confusion. RA isn't the only way to load a route. It's just the most supported. Jack From carlosm3011 at gmail.com Fri Oct 22 09:02:15 2010 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Fri, 22 Oct 2010 12:02:15 -0200 Subject: ipv6 vs. LAMP In-Reply-To: <4CC0B95A.8070003@bogus.com> References: <1287694429.4968.96.camel@wednesday> <20101021214354.GA76784@ussenterprise.ufp.org> <20101021215259.GS2843@dan.olp.net> <4CC0B95A.8070003@bogus.com> Message-ID: IMHO you should never, ever make your MySQL accesible over the public Internet, which renders the issue of MySQL not supporting IPv6 correctly mostly irrelevant. You could even run your MySQL behind your web backend using RFC1918 space (something I do recommend). Moreover, if you need direct access to the engine, you can trivially create an SSH tunnel (You can even do this in a point-and-click way using the latest MySQL Workbench). SSH works over IPv6 just fine. And for the LAMP stack, as long as the "A" fully supports IPv6 (which it does), we are fine. Warm regards, Carlos On Thu, Oct 21, 2010 at 8:06 PM, Joel Jaeggli wrote: > On 10/21/10 2:59 PM, Brandon Galbraith wrote: > > On Thu, Oct 21, 2010 at 4:53 PM, Dan White wrote: > > > >> On 21/10/10 14:43 -0700, Leo Bicknell wrote: > >> > >>> In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, > Christopher > >>> McCrory wrote: > >>> > >>>> open to the world. After a few google searches, it seems that > >>>> PostgreSQL is in a similar situation. > >>>> > >>> > >>> I don't know when PostgreSQL first supported IPv6, but it works just > >>> fine. I just fired up a stock FreeBSD 8.1 system and built the > Postgres > >>> 8.4 port with no changes, and viola: > >>> > >> > >> All this is pretty moot point if you run a localized copy of your > database > >> (mysql or postgres) and connect via unix domains sockets. > >> > >> > > True. It mostly affects shared/smaller hosting providers who have > customers > > that want direct access to the database remotely over the public network > > (and don't want to use some local admin tool such as phpMyAdmin). > > linux/unix machines can trivially build ip-tunnels of several flavors. > > > -brandon > > > > > -- -- ========================= Carlos M. Martinez-Cagnazzo http://cagnazzo.name ========================= From jbates at brightok.net Fri Oct 22 09:06:54 2010 From: jbates at brightok.net (Jack Bates) Date: Fri, 22 Oct 2010 09:06:54 -0500 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <20101022133804.GA49113@ussenterprise.ufp.org> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101022133804.GA49113@ussenterprise.ufp.org> Message-ID: <4CC19A7E.7040406@brightok.net> On 10/22/2010 8:38 AM, Leo Bicknell wrote: > Unfortunately the folks in the IETF don't even want to listen, to the > point a working group chair when I tried to explain why I wanted such a > feater told the rest of the group "He's an operator and thus doesn't > understand how any of this works, ignore him." That's when I gave up > on the IETF, and started working on my vendor for the solution. > It's popped around multiple times. The drafts won't stop until it's implemented. The lack of it in DHCPv6, despite obvious desire for it, seems to indicate a bias on the part of the IETF. Here's a current draft http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05 Jack From morrowc.lists at gmail.com Fri Oct 22 10:04:37 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 22 Oct 2010 11:04:37 -0400 Subject: DHS and NSA getting married? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> Message-ID: On Fri, Oct 22, 2010 at 1:46 AM, George Bonser wrote: > An agreement signed this month with the Department of Homeland Security > and an earlier initiative to protect companies in the defense industrial > base make it likely that the military will be a key part of any response > to a cyber attack. are any of the civilian agencies really prepared/capable of dealing with 'cyber attack'? it seems fairly natural that a 'cyber attack' (on the gov't, or it's pieces/parts) is equivalent to an 'attack' on same. We don't arm the NIST folks with Ar-15's and send them over the hill, we do that with marines. -chris From smb at cs.columbia.edu Fri Oct 22 10:08:43 2010 From: smb at cs.columbia.edu (Steven Bellovin) Date: Fri, 22 Oct 2010 11:08:43 -0400 Subject: DHS and NSA getting married? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> Message-ID: <01D3B1BF-5CFE-4A64-8545-C420E32C687F@cs.columbia.edu> On Oct 22, 2010, at 11:04 37AM, Christopher Morrow wrote: > On Fri, Oct 22, 2010 at 1:46 AM, George Bonser wrote: >> An agreement signed this month with the Department of Homeland Security >> and an earlier initiative to protect companies in the defense industrial >> base make it likely that the military will be a key part of any response >> to a cyber attack. > > are any of the civilian agencies really prepared/capable of dealing > with 'cyber attack'? it seems fairly natural that a 'cyber attack' (on > the gov't, or it's pieces/parts) is equivalent to an 'attack' on same. > We don't arm the NIST folks with Ar-15's and send them over the hill, > we do that with marines. > Is it a cyberattack, a clumsy criminal, or a bored teenager? From http://www.nap.edu/openbook.php?record_id=12651&page=142 : In the words of a former Justice Department official involved with critical infrastructure protection, ?I have seen too many situations where government officials claimed a high degree of confidence as to the source, intent, and scope of an attack, and it turned out they were wrong on every aspect of it. That is, they were often wrong, but never in doubt.? --Steve Bellovin, http://www.cs.columbia.edu/~smb From jeffshultz at wvi.com Fri Oct 22 10:17:32 2010 From: jeffshultz at wvi.com (Jeff Shultz) Date: Fri, 22 Oct 2010 08:17:32 -0700 Subject: DHS and NSA getting married? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> Message-ID: <4CC1AB0C.8040403@wvi.com> On 10/21/2010 10:46 PM, George Bonser wrote: > Among other things, a senior DHS cyber official and other DHS employees > will move to the NSA to be closer to the heart of the military's cyber > defense capability. Closer collaboration provides "an opportunity to > look at new ways that we can do national cyber incident response, he > said. > > http://www.defensenews.com/story.php?i=4939254&c=AME&s=TOP Okay, so the Feds have set up a way to not duplicate effort (and waste money at the same) between agencies. Don't really see the downside here. Full disclosure: Assigned to Army TCAE at Ft. Meade in the NSA compound for a couple years in the late 90s - assigned for awhile with the unit that is probably now associated with this. -- Jeff Shultz From morrowc.lists at gmail.com Fri Oct 22 10:32:38 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 22 Oct 2010 11:32:38 -0400 Subject: DHS and NSA getting married? In-Reply-To: <01D3B1BF-5CFE-4A64-8545-C420E32C687F@cs.columbia.edu> References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> <01D3B1BF-5CFE-4A64-8545-C420E32C687F@cs.columbia.edu> Message-ID: On Fri, Oct 22, 2010 at 11:08 AM, Steven Bellovin wrote: > ? ? ? ?In the words of a former Justice Department official involved with critical infrastructure protection, ?I have seen too many situations where government officials claimed a high degree of confidence as to the source, intent, and scope of an attack, and it turned out they were wrong on every aspect of it. That is, they were often wrong, but never in doubt.? this happens with non-cyber things as well... all the time. Point being: "cyber-attack" follows down the path of 'send the people that deal with "attacks" to deal with this'. -chris From ben.butler at c2internet.net Fri Oct 22 10:39:56 2010 From: ben.butler at c2internet.net (Ben Butler) Date: Fri, 22 Oct 2010 16:39:56 +0100 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: <4CC19092.7000207@ttec.com> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net><4CC0553C.8060202@zill.net><20101021153012.GE2843@dan.olp.net><7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv><5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com><4CC0BEE4.80302@ttec.com><5127C77A-8A2E-4C24-9FD1-50A1C0E17C93@delong.com> <4CC19092.7000207@ttec.com> Message-ID: " see a potential result of huge swathes of v4 resources reusable by these companies, probably dwarfing the reclaimable resources most any other provider without a similar customer profile will have." See this is at the hub of it as well, is it a reusable resource, or is it an obsolete one? Should it be getting resused for multi-homeing or content providers, or should it be retired by the ISP that has migrated their subs onto v6? I think if we continue with a mind set that v4 is a previous resource and once I have freed it up by moving to v6 I must hang onto it and of course if I have got some free I best deploy it again for a new customer - this seems completely circular to me. I think the question is: 1> Are we attempting to migrate from IPv4 to IPv6 and end up at a place ultimately where IPv4 is fully intended to be retired. Or 2> Are we simply intending to extend the address space with IPv6 and continue to pretty much carry on business as normal with existing IPv4 deployments in any meaningly foreseeable time frame and run a dual stack network. Further more that it is ok to reutilize any free up IPv4 space along the way as we are never planning on retiring it anyway. I personally think it should be the first of those, but my opinion doesn't really count for squat. Ultimately I would rather we be clear about what we are wishing / aspiring / trying to achieve and then set about achieving it collectively. If the collective view is that it is not a migration but a co-existence that we are aiming for then ok, lets stop pretending otherwise, if however the collective direction is migration then can we please collectively do our best to facilitate and encourage the migration. As opposed to having various tactics to drag out the migration as long as possible as some think that if they drag their feet in perpetuity that the v4 to v6 bridging magic will become the duty of the service provider to make it work for content providers and subscribers that don't want to update CPE routers or rewrite code where nessacery. If we, as a community of operators are going to get on and deploy IPv6 and we agree it's a migration the lets get doing and set some targets dates / BCP for when it is reasonably expected that net/sys admins will have completed the rollout and by whatever contractual or commercial / technical means migrated their customers. If, however, we as a community don't want migration but cohabitation then lets do that. Which one do we ultimately want? Ben -----Original Message----- From: Joe Maimon [mailto:jmaimon at ttec.com] Sent: 22 October 2010 14:25 To: Matthew Petach Cc: NANOG Subject: Re: Only 5x IPv4 /8 remaining at IANA -------------------------------------------------------------------------- BODY { MARGIN: 0px}.footerdark { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #001a35; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.blackcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.bluecopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #29aae2; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none}.address { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #000000; FONT-SIZE: 10px; TEXT-DECORATION: none}.footerlight { LINE-HEIGHT: 13px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #667891; FONT-SIZE: 9px; FONT-WEIGHT: normal; TEXT-DECORATION: none}.pinkcopy { LINE-HEIGHT: 12px; FONT-FAMILY: Arial, Helvetica, sans-serif; COLOR: #ed174d; FONT-SIZE: 10px; FONT-WEIGHT: bold; TEXT-DECORATION: none} Ben Butler Director Tel: 0333 666 3332 Fax: 0333 666 3331 C2 Business Networking Ltd The Paddock, London Road, Nantwich, Cheshire, CW5 7JL http://www.c2internet.net/ Part of the Atlas Business Group of Companies plc Registered in England: 07102986 Registered Address: Datum House, Electra Way, Crewe CW1 6ZF Vat Registration No: 712 9503 48 This message is confidential and intended for the use only of the person to whom it is addressed. If you are not the intended recipient you are strictly prohibited from reading, disseminating, copying, printing, re-transmitting or using this message or its contents in any way. Opinions, conclusions and other information expressed in this message are not given or authorised by the Company unless otherwise indicated by an authorised representative independent of this message. The Company does not accept liability for any data corruption, interception or amendment to any e-mail or the consequences thereof.Emails addressed to individuals may not necessarily be read by that person unless they are in the office.Calls to and from any of the Atlas Business Group of Companies may be recorded for the purposes of training, monitoring of quality and customer services. From tme at americafree.tv Fri Oct 22 10:40:16 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Fri, 22 Oct 2010 11:40:16 -0400 Subject: DHS and NSA getting married? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> <01D3B1BF-5CFE-4A64-8545-C420E32C687F@cs.columbia.edu> Message-ID: On Oct 22, 2010, at 11:32 AM, Christopher Morrow wrote: > On Fri, Oct 22, 2010 at 11:08 AM, Steven Bellovin wrote: > >> In the words of a former Justice Department official involved with critical infrastructure protection, ?I have seen too many situations where government officials claimed a high degree of confidence as to the source, intent, and scope of an attack, and it turned out they were wrong on every aspect of it. That is, they were often wrong, but never in doubt.? > > this happens with non-cyber things as well... all the time. Point > being: "cyber-attack" follows down the path of 'send the people that > deal with "attacks" to deal with this'. And for those people, being highly confident is typically viewed as a positive feature. Regards Marshall > > -chris > > From owen at delong.com Fri Oct 22 10:40:35 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 22 Oct 2010 08:40:35 -0700 Subject: =?windows-1252?Q?Re:_Why_ULA:_low_collision_chance_=28Was:_IPv6_?= =?windows-1252?Q?fc00::/7_=97_Unique_local_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> <4CC11F05.50109@bogus.com> Message-ID: On Oct 22, 2010, at 5:25 AM, William Herrin wrote: > On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli wrote: >> On 10/21/10 6:38 PM, Owen DeLong wrote: >>> On Oct 21, 2010, at 3:42 PM, Jack Bates wrote: >>>> On 10/21/2010 5:27 PM, Joel Jaeggli wrote: >>>>> >>>>> Announce your gua and then blackhole it and monitor your prefix. >>>>> you can tell if you're leaking. it's generally pretty hard to >>>>> tell if you're leaking rfc 1918 since your advertisement may well >>>>> work depending on the filters of your peers but not very far. >>>> >>>> This is always the argument I hear from corporate customers >>>> concerning wanting NAT. If mistake is made, the RFC 1918 space >>>> isn't routable. They often desire the same out of v6 for that >>>> reason alone. >> >> the rfc 1918 space is being routed inside almost all your adjacent >> networks, so if their ingress filtering is working as expected, great, >> but you're only a filter away from leaking. > > A filter away from leaking to -one- of the millions of entities on the > internet. Two filters away from leaking to two. > This underestimates the transitive property of leakage. Owen From dhc2 at dcrocker.net Fri Oct 22 10:48:43 2010 From: dhc2 at dcrocker.net (Dave CROCKER) Date: Fri, 22 Oct 2010 08:48:43 -0700 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <19648.43288.915332.173143@world.std.com> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> Message-ID: <4CC1B25B.2050504@dcrocker.net> On 10/21/2010 1:56 PM, Barry Shein wrote: > Well, if the DNS root servers ceased IPv4 service it'd be pretty much > a fait accompli as far as the public internet is concerned. Given the reality of fragmenting the DNS -- including its root -- that's an action that well might backfire. Current fragmentation is constrained; this could plausibly motivate more people to pursue other paths and thereby blow things up. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net From gbonser at seven.com Fri Oct 22 10:50:46 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 22 Oct 2010 08:50:46 -0700 Subject: DHS and NSA getting married? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C437@RWC-EX1.corp.seven.com> > From: christopher.morrow at gmail.com > Sent: Friday, October 22, 2010 8:05 AM > To: George Bonser > Cc: NANOG > Subject: Re: DHS and NSA getting married? > > are any of the civilian agencies really prepared/capable of dealing > with 'cyber attack'? it seems fairly natural that a 'cyber attack' (on > the gov't, or it's pieces/parts) is equivalent to an 'attack' on same. > We don't arm the NIST folks with Ar-15's and send them over the hill, > we do that with marines. > > -chris "cyber attack" wasn't what caught my eye. It was the notion of NSA having a domestic role defined in policy that I thought was different here. I do believe there are a lot of people who are afraid of "cyber attack" but aren't exactly sure what that would look like. A cyber attack might go completely unnoticed until it is too late. The enabling pieces of such an attack might already be deployed on computers and inside various devices people are buying, who knows. The notion that you are going to stop some invading army of packets might be completely off the mark. It might look more like millions of pieces of equipment suddenly going dark or misbehaving for no apparent reason or might be coordinated with some physical action. A lot of people got caught short with those AT&T cable cuts in the SF Bay a while back. From jmaimon at ttec.com Fri Oct 22 10:58:13 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 22 Oct 2010 11:58:13 -0400 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net><4CC0553C.8060202@zill.net><20101021153012.GE2843@dan.olp.net><7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv><5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com><4CC0BEE4.80302@ttec.com><5127C77A-8A2E-4C24-9FD1-50A1C0E17C93@delong.com> <4CC19092.7000207@ttec.com> Message-ID: <4CC1B495.4060203@ttec.com> Ben Butler wrote: > > If we, as a community of operators are going to get on and deploy IPv6 and we agree it's a migration the lets get doing and set some targets dates / BCP for when it is reasonably expected that net/sys admins will have completed the rollout and by whatever contractual or commercial / technical means migrated their customers. If, however, we as a community don't want migration but cohabitation then lets do that. Which one do we ultimately want? > > Ben > The key word in the phrase collective self interest is self. Solve that first, the rest comes along for the ride. There is no cabal. Joe From jmaimon at ttec.com Fri Oct 22 11:01:08 2010 From: jmaimon at ttec.com (Joe Maimon) Date: Fri, 22 Oct 2010 12:01:08 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <4CC1B25B.2050504@dcrocker.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <4CC1B25B.2050504@dcrocker.net> Message-ID: <4CC1B544.80501@ttec.com> Dave CROCKER wrote: > > On 10/21/2010 1:56 PM, Barry Shein wrote: >> Well, if the DNS root servers ceased IPv4 service it'd be pretty much >> a fait accompli as far as the public internet is concerned. > > > Given the reality of fragmenting the DNS -- including its root -- that's > an action that well might backfire. Current fragmentation is > constrained; this could plausibly motivate more people to pursue other > paths and thereby blow things up. > > > d/ Luckily we have already prepared the cure for that disease. Apparently DNSSEC is catching on right about now. Joe From rps at maine.edu Fri Oct 22 11:07:41 2010 From: rps at maine.edu (Ray Soucy) Date: Fri, 22 Oct 2010 12:07:41 -0400 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance_=28Was=3A_IPv6_fc00=3A=3A=2F?= =?windows-1252?Q?7_=97_Unique_local_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> <4CC11F05.50109@bogus.com> Message-ID: It's amazing how much of a problem you think leaking of prefixes is... I don't know about you, but I'm pretty strict about what prefixes I allow to be advertised up to me from people we service. I'm not sure having a random private prefix will make much of a difference, since it sounds like fat-fingering a GUA and hijacking a real prefix is just as (or even more) likely. I think the original point was that if you do decide to use ULA, then stay in FD00::/8 and not FC00::/7, there is no way to force people to follow the RFC for something thats non-routed unless we involve vendors. If it sounds like a good idea to include the random 40-bit segment and you can tolerate having non-routed addresses be a little more difficult to remember, then go for it. If you don't follow the RFC and it bites you because of a merger in the future, then it's your own fault and you haven't affected anyone. In the vast majority of environments, even if this space did leak out into the global table and wasn't filtered at all, you would probably still maintain normal operation because your non-routed networks would be a shorter path than anything advertised back down to you. Do we really need 80 messages talking about the dangers of leaking? Perhaps you should see your doctor if its that big of a problem. I think there are some drugs to fix that problem these days... The obvious assumption is that anyone who is providing IPv6 transit is already protecting themselves appropriately, just as they already do in the IP world. On Fri, Oct 22, 2010 at 11:40 AM, Owen DeLong wrote: > > On Oct 22, 2010, at 5:25 AM, William Herrin wrote: > >> On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli wrote: >>> On 10/21/10 6:38 PM, Owen DeLong wrote: >>>> On Oct 21, 2010, at 3:42 PM, Jack Bates wrote: >>>>> On 10/21/2010 5:27 PM, Joel Jaeggli wrote: >>>>>> >>>>>> Announce your gua and then blackhole it and monitor your prefix. >>>>>> you can tell if you're leaking. it's generally pretty hard to >>>>>> tell if you're leaking rfc 1918 since your advertisement may well >>>>>> work depending on the filters of your peers but not very far. >>>>> >>>>> This is always the argument I hear from corporate customers >>>>> concerning wanting NAT. If ?mistake is made, the RFC 1918 space >>>>> isn't routable. They often desire the same out of v6 for that >>>>> reason alone. >>> >>> the rfc 1918 space is being routed inside almost all your adjacent >>> networks, so if their ingress filtering is working as expected, great, >>> but you're only a filter away from leaking. >> >> A filter away from leaking to -one- of the millions of entities on the >> internet. Two filters away from leaking to two. >> > This underestimates the transitive property of leakage. > > Owen > > > -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/ From gbonser at seven.com Fri Oct 22 11:07:46 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 22 Oct 2010 09:07:46 -0700 Subject: Only 5x IPv4 /8 remaining at IANA In-Reply-To: References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net><4CC0553C.8060202@zill.net><20101021153012.GE2843@dan.olp.net><7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv><5A6D953473350C4B9995546AFE9939EE0B14C417@RWC-EX1.corp.seven.com><4CC0BEE4.80302@ttec.com><5127C77A-8A2E-4C24-9FD1-50A1C0E17C93@delong.com><4CC19092.7000207@ttec.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C439@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Ben Butler [mailto:ben.butler at c2internet.net] > Sent: Friday, October 22, 2010 8:40 AM > To: NANOG > Subject: RE: Only 5x IPv4 /8 remaining at IANA > > " see a potential result of huge swathes of v4 resources reusable by > these companies, probably dwarfing the reclaimable resources most any > other provider without a similar customer profile will have." > > See this is at the hub of it as well, is it a reusable resource, or is > it an obsolete one? Should it be getting resused for multi-homeing or > content providers, or should it be retired by the ISP that has migrated > their subs onto v6? > > I think if we continue with a mind set that v4 is a previous resource > and once I have freed it up by moving to v6 I must hang onto it and of > course if I have got some free I best deploy it again for a new > customer - this seems completely circular to me. I think the question > is: > > 1> Are we attempting to migrate from IPv4 to IPv6 and end up at a place > ultimately where IPv4 is fully intended to be retired. > > Or > > 2> Are we simply intending to extend the address space with IPv6 and > continue to pretty much carry on business as normal with existing IPv4 > deployments in any meaningly foreseeable time frame and run a dual > stack network. Further more that it is ok to reutilize any free up > IPv4 space along the way as we are never planning on retiring it > anyway. If, after run out, most new deployments are done in v6 and if end users are being migrated to v6 wholesale by such organizations as the Comcasts of the world, who would *want* to deploy a new operation in v4 space? If the native packets of the users need to be translated in some way to v4 in order to reach you, the apparent performance of someone's operation is ultimately limited by the performance of whatever is doing that translation, wherever that device is (either at your end or the other end). The migration out of v4 will go pretty quickly once there is a compelling business reason for that to take place such as the people buying your product or the people who you want to buy your product are on v6 or your partners with whom you need to transact are on v6. Once a few large groups of users are native v6, once v4 has run out, once enough popular destinations are v6 capable, there is no longer a justification for deploying v4 in new operations. The problem changes from having to justify v6 to having to justify v4. Once THAT takes place, there is no need to issue more v4 space as the total v4 traffic across the internet will quickly drop and people who are not v6 capable at that point will be scrambling to catch up. From morrowc.lists at gmail.com Fri Oct 22 11:08:59 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Fri, 22 Oct 2010 12:08:59 -0400 Subject: DHS and NSA getting married? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C437@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C437@RWC-EX1.corp.seven.com> Message-ID: On Fri, Oct 22, 2010 at 11:50 AM, George Bonser wrote: > > > >> From: christopher.morrow at gmail.com >> Sent: Friday, October 22, 2010 8:05 AM >> To: George Bonser >> Cc: NANOG >> Subject: Re: DHS and NSA getting married? >> >> are any of the civilian agencies really prepared/capable of dealing >> with 'cyber attack'? it seems fairly natural that a 'cyber attack' (on >> the gov't, or it's pieces/parts) is equivalent to an 'attack' on same. >> We don't arm the NIST folks with Ar-15's and send them over the hill, >> we do that with marines. >> >> -chris > > "cyber attack" wasn't what caught my eye. ?It was the notion of NSA > having a domestic role defined in policy that I thought was different > here. not all packets have source addresses in the US, not all facilities in the US Gov't cares about are in the Us. From sreed at nwwnet.net Fri Oct 22 11:32:15 2010 From: sreed at nwwnet.net (Scott Reed) Date: Fri, 22 Oct 2010 12:32:15 -0400 Subject: ipv6 vs. LAMP In-Reply-To: References: <1287694429.4968.96.camel@wednesday> <20101021214354.GA76784@ussenterprise.ufp.org> <20101021215259.GS2843@dan.olp.net> <4CC0B95A.8070003@bogus.com> Message-ID: <4CC1BC8F.6040705@nwwnet.net> Public or not, if someone wants to run IPv6 only, they shouldn't have to have the v4 stack just for the database. Databases must work on the v6 stack. On 10/22/2010 10:02 AM, Carlos Martinez-Cagnazzo wrote: > IMHO you should never, ever make your MySQL accesible over the public > Internet, which renders the issue of MySQL not supporting IPv6 correctly > mostly irrelevant. You could even run your MySQL behind your web backend > using RFC1918 space (something I do recommend). > > Moreover, if you need direct access to the engine, you can trivially create > an SSH tunnel (You can even do this in a point-and-click way using the > latest MySQL Workbench). SSH works over IPv6 just fine. > > And for the LAMP stack, as long as the "A" fully supports IPv6 (which it > does), we are fine. > > Warm regards, > > Carlos > > On Thu, Oct 21, 2010 at 8:06 PM, Joel Jaeggli wrote: > >> On 10/21/10 2:59 PM, Brandon Galbraith wrote: >>> On Thu, Oct 21, 2010 at 4:53 PM, Dan White wrote: >>> >>>> On 21/10/10 14:43 -0700, Leo Bicknell wrote: >>>> >>>>> In a message written on Thu, Oct 21, 2010 at 01:53:49PM -0700, >> Christopher >>>>> McCrory wrote: >>>>> >>>>>> open to the world. After a few google searches, it seems that >>>>>> PostgreSQL is in a similar situation. >>>>>> >>>>> I don't know when PostgreSQL first supported IPv6, but it works just >>>>> fine. I just fired up a stock FreeBSD 8.1 system and built the >> Postgres >>>>> 8.4 port with no changes, and viola: >>>>> >>>> All this is pretty moot point if you run a localized copy of your >> database >>>> (mysql or postgres) and connect via unix domains sockets. >>>> >>>> >>> True. It mostly affects shared/smaller hosting providers who have >> customers >>> that want direct access to the database remotely over the public network >>> (and don't want to use some local admin tool such as phpMyAdmin). >> linux/unix machines can trivially build ip-tunnels of several flavors. >> >>> -brandon >>> >> >> > -- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060 From mpetach at netflight.com Fri Oct 22 11:37:15 2010 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 22 Oct 2010 09:37:15 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <4CC19A7E.7040406@brightok.net> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101022133804.GA49113@ussenterprise.ufp.org> <4CC19A7E.7040406@brightok.net> Message-ID: On Fri, Oct 22, 2010 at 7:06 AM, Jack Bates wrote: > On 10/22/2010 8:38 AM, Leo Bicknell wrote: >> >> Unfortunately the folks in the IETF don't even want to listen, to the >> point a working group chair when I tried to explain why I wanted such a >> feater told the rest of the group "He's an operator and thus doesn't >> understand how any of this works, ignore him." ?That's when I gave up >> on the IETF, and started working on my vendor for the solution. >> > It's popped around multiple times. The drafts won't stop until it's > implemented. The lack of it in DHCPv6, despite obvious desire for it, seems > to indicate a bias on the part of the IETF. The interesting thing is that while the IETF may have a certain bias, the hardware manufacturers have a different bias; they do what needs to be done to sell hardware. And while we may be 'just operators', if we tell vendors we won't buy their hardware unless they support draft-X-Y-Z, you can believe they'll listen to that a lot more closely than they will the IETF. The IETF has teeth only so long as those with money to spend on vendors support their decisions. When a vendor is forced to choose between complying with the IETF, or getting a $5M purchase order from a customer, they're going to look long and hard at what the customer is requesting. We've gotten knobs added to software that go explicitly against standards that way; they're off by default, they're hidden, and they have ugly names like "enable broken-ass-feature-for-customer-X" but the vendors *do* put them in, because without them, they don't get paid. Matt > Here's a current draft > http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05 > > Jack From cb.list6 at gmail.com Fri Oct 22 11:42:50 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 22 Oct 2010 09:42:50 -0700 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> Message-ID: On Thu, Oct 21, 2010 at 10:20 PM, George Bonser wrote: > > >> -----Original Message----- >> From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM >> To: bmanning >> Cc: NANOG >> Subject: Re: IPv4 sunset date revised : 2009-02-05 > > >> >> (now I'm teasing.. .Bill where's your docs on this fantastic new >> teknowlogie?) >> > > I found it here: > > http://www.ivi2.org/ > > But the readme is a bit confusing: > > http://www.ivi2.org/code/00-ivi0.5-README > > Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix > assuming the mapping is to be 1-1 > Right, 1 to 1 does not solve any IPv4 exhaustion problems. Going back to the title of the thread, IVI does not help you sunset IPv4 since the same amount of IPv4 is required. NAT64 is the protocol that helps you "sunset" IPv4 by providing native IPv6 to the user and doing a protocol translation similar to NAPT to IPv4 destination. Thusly, IPv6 end to end applications benefit from not having a middle box and experience more features (e2e) and less flaky NAPT, ... keep in mind that NAPT is the status quo in many places, especially in mobile wireless, end to end IPv6 is an upgrade. This is pretty impactful since major internet destinations like Google, Netflix, Facebook have IPv6 deployments in place today. For many, this is a ~50% reduction in NAT which is ~50% increase in E2E communication (less cost, better quality). Since economics and user experience are involved, this is a real path to migrating from IPv4 to IPv6. The right incentive structure is in place for both the service provider who is out of addresses and the consumer who wants rich e2e communication. Shameless plug, i have it working here for over 9 months http://groups.google.com/group/tmoipv6beta Cameron From steve at ipv6canada.com Fri Oct 22 12:00:09 2010 From: steve at ipv6canada.com (Steve Bertrand) Date: Fri, 22 Oct 2010 13:00:09 -0400 Subject: Issues with MSN and Rogers Blackberry Message-ID: <4CC1C319.4090903@ipv6canada.com> Hi all, I have a good friend who is on the Rogers network with a Blackberry Bold 9700. Frequently, but not always, MSN will dump with the following error: "There is a problem with the server. Please try again later.(100)". The 'net is littered with these complaints, and it appears to only affect Verizon/Rogers networks. Does anyone know of a workaround, or are there any Rogers/MSN engineers who can contact me off list to try to figure it out? Thanks, Steve From bzs at world.std.com Fri Oct 22 12:13:28 2010 From: bzs at world.std.com (Barry Shein) Date: Fri, 22 Oct 2010 13:13:28 -0400 Subject: IPv4 sunset date set for 2019-12-31 In-Reply-To: <4CC1B25B.2050504@dcrocker.net> References: <4CBC3328.7090205@unfix.org> <4CBFB54B.9010707@zill.net> <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <4CC07DD3.6060400@dcrocker.net> <19648.43288.915332.173143@world.std.com> <4CC1B25B.2050504@dcrocker.net> Message-ID: <19649.50744.735071.669653@world.std.com> On October 22, 2010 at 08:48 dhc2 at dcrocker.net (Dave CROCKER) wrote: > > On 10/21/2010 1:56 PM, Barry Shein wrote: > > Well, if the DNS root servers ceased IPv4 service it'd be pretty much > > a fait accompli as far as the public internet is concerned. > > > Given the reality of fragmenting the DNS -- including its root -- that's an > action that well might backfire. Current fragmentation is constrained; this > could plausibly motivate more people to pursue other paths and thereby blow > things up. > I wouldn't suggest doing it without A LOT of coordination with stakeholders. While we're on the subject, someone else suggested that one source of authority would be the Tier-1 vendors, the other would be governments. Tying the two sub-threads together I believe there's sufficient authority vested in the DNS management and RIRs to accomplish a transition to an, effectively, all-IPv6 internet without either of the above leading tho they would have to follow of course. -- -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 nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Fri Oct 22 12:18:34 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sat, 23 Oct 2010 03:48:34 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> Message-ID: <20101023034834.15fec97c@opy.nosense.org> On Fri, 22 Oct 2010 01:10:08 -0700 Owen DeLong wrote: > > On Oct 22, 2010, at 12:55 AM, Mark Smith wrote: > > > On Fri, 22 Oct 2010 15:52:08 +1100 > > Karl Auer wrote: > > > >> On Thu, 2010-10-21 at 21:05 -0500, Jack Bates wrote: > >>> On 10/21/2010 8:39 PM, Ray Soucy wrote: > >>>> > >>>> How so? We still have RA (with a high priority) that's the only way > >>>> DHCPv6 works. I guess there is a lot of misunderstanding about how > >>>> DHCPv6 works, even among the experts... > >>> > >>> Actually, the last I checked, there are implementation of DHCPv6 without RA. > >> > >> I'll go out on a limb here and say that RA is not needed for DHCPv6. > >> > > > > RAs are still needed to convey the M/O bit values, so that end-nodes > > know they need to use DHCPv6 if necessary. As there are two address > > configuration methods, there is always going to be a need to express a > > policy to end-nodes as to which one they need to use. > > > You can actually force a client to assume the M bit if you cause it to launch > a DHCPv6 client through other means. You don't have to have RA for that. > Policy can be expressed by RA, or, it can be expressed by other means. > We used to hand wind cars to start them. We don't have to anymore. An RA is single, periodic, in the order of 100s of seconds, multicast packet. If you're arguing against the cost of that, then I think you're being a bit too precious with your packets. Any argument for manual configuration is an argument for increasing complexity and opportunity for error. > >> A DHCPv6 client multicasts all its messages to the well-known > >> all-relays-and-servers address. A client needs only its link-local > >> address to do this. The relay (or server if it happens to be on the same > >> link) can thus talk to the client in the complete absence of RA. > >> > > > > There isn't a method to specify a default gateway in DHCPv6. Some > > people want it, however it seems a bit pointless to me if you're going > > to have RAs announcing M/O bits anyway - you may as well use those RAs > > to announce a default router too. > > > Actually, it's not pointless at all. The RA system assumes that all routers > capable of announcing RAs are default routers and that virtually all routers > are created equal (yes, you have high/medium/low, but, really, since you > have to use high for everything in any reasonable deployment...) > No it doesn't. You can set the router lifetime to zero, which indicates to the end-node that the RA isn't announcing a default router. In this case, it may be announcing M/O bit, prefix or other parameters. > There are real environments where it's desirable to have a way to tell > different clients on a network to use different default gateways or > default gateway sets. > > Owen > From mmaberry at gmail.com Fri Oct 22 12:24:11 2010 From: mmaberry at gmail.com (Mike Maberry) Date: Fri, 22 Oct 2010 10:24:11 -0700 Subject: Issues with Wild Blue Internet Services Message-ID: All, We are receiving reports that customers using Wild Blue ISP are having trouble reaching our network. We have asked customers to provide us with packet captures and are still waiting on them. Our troubleshooting has not revealed any reason why customers can not access us from that ISP. The same customers report that from other networks they can reach us. I was wondering if any of you have had similar experiences with this ISP or could shed some light on what might be happening. Thanks for your valuable time, Mike From bzs at world.std.com Fri Oct 22 12:28:24 2010 From: bzs at world.std.com (Barry Shein) Date: Fri, 22 Oct 2010 13:28:24 -0400 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: References: <4CC0553C.8060202@zill.net> <20101021153012.GE2843@dan.olp.net> <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> Message-ID: <19649.51640.224298.319039@world.std.com> It occurs to me that there is some pressing need to investigate this all-IPv6 internet -- motivated by the cost of (not) maintaining IPv4 forever. Right now we can observe essentially an all-IPv4 internet (99%, whatever.) In a very few years, possibly as few as two, the picture might become much more muddied and it could become more difficult to extract IPv4 specific costs from mixed IPv4/IPv6 costs. For example, I'd imagine the RIRs are just at the cusp of ceasing to spend all their address management efforts on IPv4. In two years more and more of their expenses might be difficult to distinguish as exclusively IPv4 or IPv6. Also, when IPv4 addresses do run out then more effort will be spent on that new environment where they move from fulfilling needs (i.e., just making new IPv4 allocations) to mitigating needs -- revocation, reclamation, and return, and subsequent allocation no doubt by new policies. So, this might be roughly our last chance to get some measurements on the management of an all IPv4 network, and monitor the transition as it happens. -- -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 bmanning at vacation.karoshi.com Fri Oct 22 12:54:03 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Oct 2010 17:54:03 +0000 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: References: <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> Message-ID: <20101022175403.GA11762@vacation.karoshi.com.> On Fri, Oct 22, 2010 at 09:42:50AM -0700, Cameron Byrne wrote: > On Thu, Oct 21, 2010 at 10:20 PM, George Bonser wrote: > > > > > >> -----Original Message----- > >> From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM > >> To: bmanning > >> Cc: NANOG > >> Subject: Re: IPv4 sunset date revised : 2009-02-05 > > > > > >> > >> (now I'm teasing.. .Bill where's your docs on this fantastic new > >> teknowlogie?) > >> > > > > I found it here: > > > > http://www.ivi2.org/ > > > > But the readme is a bit confusing: > > > > http://www.ivi2.org/code/00-ivi0.5-README > > > > Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix > > assuming the mapping is to be 1-1 > > > > Right, 1 to 1 does not solve any IPv4 exhaustion problems. ah... but the trick is to only need enough IPv4 in the pool to dynamically talk to the Internet. Native v6 to Native v6 never has to drop back to the Internet, It uses native v6 paths. So the larger the v6 uptake, the fewer Internet addreses you'll need to keep around in your pool. > Going back to the title of the thread, IVI does not help you sunset > IPv4 since the same amount of IPv4 is required. See above. > Cameron From bmanning at vacation.karoshi.com Fri Oct 22 13:03:26 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Oct 2010 18:03:26 +0000 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <19649.51640.224298.319039@world.std.com> References: <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> <19649.51640.224298.319039@world.std.com> Message-ID: <20101022180326.GB11762@vacation.karoshi.com.> On Fri, Oct 22, 2010 at 01:28:24PM -0400, Barry Shein wrote: > > It occurs to me that there is some pressing need to investigate this > all-IPv6 internet -- motivated by the cost of (not) maintaining IPv4 > forever. > > Right now we can observe essentially an all-IPv4 internet (99%, > whatever.) > > -- > -Barry Shein For this, you need to leave the comfort of NANOG and look at the CERNnet network over the past ten years. They have been running a large, all IPv6 network for some time now. http://www.authorstream.com/Presentation/Cannes-19148-IPv6-development-China-Outline-Efforts-CERNET-History-Testbed-1-2-3-4-5-Next-Generation-Inter-in-as-Entertainment-ppt-powerpoint/ www.cs.princeton.edu/~yiwang/papers/iscc05.pdf http://www.cernet2.edu.cn/en/char.htm --bill From tglassey at earthlink.net Fri Oct 22 13:08:51 2010 From: tglassey at earthlink.net (todd glassey) Date: Fri, 22 Oct 2010 11:08:51 -0700 Subject: DHS and NSA getting married? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> Message-ID: <4CC1D333.3030403@earthlink.net> On 10/22/2010 8:04 AM, Christopher Morrow wrote: > On Fri, Oct 22, 2010 at 1:46 AM, George Bonser wrote: >> An agreement signed this month with the Department of Homeland Security >> and an earlier initiative to protect companies in the defense industrial >> base make it likely that the military will be a key part of any response >> to a cyber attack. > > are any of the civilian agencies really prepared/capable of dealing > with 'cyber attack'? Yes... it seems fairly natural that a 'cyber attack' (on > the gov't, or it's pieces/parts) is equivalent to an 'attack' on same. true... > We don't arm the NIST folks with Ar-15's and send them over the hill, > we do that with marines. So you clearly have never been on a DDCC S&D Raid I can tell. Todd > > -chris > > -- //----------------------------------------------------------------- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From cb.list6 at gmail.com Fri Oct 22 13:21:36 2010 From: cb.list6 at gmail.com (Cameron Byrne) Date: Fri, 22 Oct 2010 11:21:36 -0700 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <20101022175403.GA11762@vacation.karoshi.com.> References: <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> <20101022175403.GA11762@vacation.karoshi.com.> Message-ID: On Fri, Oct 22, 2010 at 10:54 AM, wrote: > On Fri, Oct 22, 2010 at 09:42:50AM -0700, Cameron Byrne wrote: >> On Thu, Oct 21, 2010 at 10:20 PM, George Bonser wrote: >> > >> > >> >> -----Original Message----- >> >> From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM >> >> To: bmanning >> >> Cc: NANOG >> >> Subject: Re: IPv4 sunset date revised : 2009-02-05 >> > >> > >> >> >> >> (now I'm teasing.. .Bill where's your docs on this fantastic new >> >> teknowlogie?) >> >> >> > >> > I found it here: >> > >> > http://www.ivi2.org/ >> > >> > But the readme is a bit confusing: >> > >> > http://www.ivi2.org/code/00-ivi0.5-README >> > >> > Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix >> > assuming the mapping is to be 1-1 >> > >> >> Right, 1 to 1 does not solve any IPv4 exhaustion problems. > > > ? ? ? ?ah... but the trick is to only need enough IPv4 in the pool > ? ? ? ?to dynamically talk to the Internet. ?Native v6 to Native v6 > ? ? ? ?never has to drop back to the Internet, It uses native v6 > ? ? ? ?paths. ?So the larger the v6 uptake, the fewer Internet addreses > ? ? ? ?you'll need to keep around in your pool. > > >> Going back to the title of the thread, IVI does not help you sunset >> IPv4 since the same amount of IPv4 is required. > > ? ? ? ?See above. > So works, just not at a large scale. For larger scale, you need address sharing like NAT64. From bpfankuch at cpgreeley.com Fri Oct 22 13:23:27 2010 From: bpfankuch at cpgreeley.com (Blake Pfankuch) Date: Fri, 22 Oct 2010 12:23:27 -0600 Subject: VPN issue, and possible cBeyond Engineer request Message-ID: <01759D50DC387C45A018FE1817CE27D77E3DFDDA8F@CPExchange1.cpgreeley.com> Howdy, So I'm fighting a VPN issue, trying to establish a Client to Firewall VPN for remote access with 3 of my customers. Customer is using a Sonicwall firewall (TZ210 or NSA240 with similar issues). We have ruled out the firewall being the issue by terminating the internet connection to a switch, static IPing a laptop outside the firewall and successfully establishing a tunnel. DHCP information is properly processed by the firewall every time, but under 25% of the time it is not received by the client. Any thoughts as to what might be intermittently eating this information? Alternatively anyone useful from cBeyond who might be able to assist me? This works perfectly fine for 50+ customers however we have 3 customers on cBeyond service that it does not work with. Again, we can bypass the cBeyond circuit and VPN client connections work as expected. Any other ideas? Blake Pfankuch From bmanning at vacation.karoshi.com Fri Oct 22 13:37:39 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Oct 2010 18:37:39 +0000 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: References: <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> <20101022175403.GA11762@vacation.karoshi.com.> Message-ID: <20101022183739.GC11762@vacation.karoshi.com.> On Fri, Oct 22, 2010 at 11:21:36AM -0700, Cameron Byrne wrote: > On Fri, Oct 22, 2010 at 10:54 AM, wrote: > > On Fri, Oct 22, 2010 at 09:42:50AM -0700, Cameron Byrne wrote: > >> On Thu, Oct 21, 2010 at 10:20 PM, George Bonser wrote: > >> > > >> > > >> >> -----Original Message----- > >> >> From: Christopher Morrow > Sent: Thursday, October 21, 2010 9:49 PM > >> >> To: bmanning > >> >> Cc: NANOG > >> >> Subject: Re: IPv4 sunset date revised : 2009-02-05 > >> > > >> > > >> >> > >> >> (now I'm teasing.. .Bill where's your docs on this fantastic new > >> >> teknowlogie?) > >> >> > >> > > >> > I found it here: > >> > > >> > http://www.ivi2.org/ > >> > > >> > But the readme is a bit confusing: > >> > > >> > http://www.ivi2.org/code/00-ivi0.5-README > >> > > >> > Trying to figure out how they map a /70 v6 prefix to a /30 v4 prefix > >> > assuming the mapping is to be 1-1 > >> > > >> > >> Right, 1 to 1 does not solve any IPv4 exhaustion problems. > > > > > > ah... but the trick is to only need enough IPv4 in the pool > > to dynamically talk to the Internet. Native v6 to Native v6 > > never has to drop back to the Internet, It uses native v6 > > paths. So the larger the v6 uptake, the fewer Internet addreses > > you'll need to keep around in your pool. > > > > > >> Going back to the title of the thread, IVI does not help you sunset > >> IPv4 since the same amount of IPv4 is required. > > > > See above. > > > > So works, just not at a large scale. For larger scale, you need > address sharing like NAT64. depends on your definition of "large" scale. for cernet2 --- "The grid over IPv6 covers 20 universities distributed in 13 cities, and the aggregation capability is high above 15 trillion time/sec, and the storage capability above 150TB." "CNGI-CERNET2 backbone runs IPv6 protocol and connects 25 PoPs distributed in 20 cities in China with the speed of 2.5Gbps/10Gbps. Meanwhile, the transmission rate of Beijing-Wuhan-Guangzhou and Wuhan-Nanjing-Shanghai is 10Gbps. Each PoP provides the 1Gbps/2.5Gbps/10Gbps access capacity for the access network. "Since the opening in 2004, CNGI-CERNET2 backbone has connected more than 200 IPv6 access networks of universities and R&D institutes in China, supported technical trials and application demonstration, and provided excellent environment for world-wide next generation Internet research." So, yeah... for these smaller, regional networks, its a good fit. For you big guys, you may need something else. --bill From cscora at apnic.net Fri Oct 22 13:51:43 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 23 Oct 2010 04:51:43 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201010221851.o9MIphJ8002016@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 23 Oct, 2010 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 334429 Prefixes after maximum aggregation: 152752 Deaggregation factor: 2.19 Unique aggregates announced to Internet: 164630 Total ASes present in the Internet Routing Table: 35103 Prefixes per ASN: 9.53 Origin-only ASes present in the Internet Routing Table: 30270 Origin ASes announcing only one prefix: 14793 Transit ASes present in the Internet Routing Table: 4833 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: 309 Unregistered ASNs in the Routing Table: 130 Number of 32-bit ASNs allocated by the RIRs: 829 Prefixes from 32-bit ASNs in the Routing Table: 0 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 196 Number of addresses announced to Internet: 2290781856 Equivalent to 136 /8s, 138 /16s and 142 /24s Percentage of available address space announced: 61.8 Percentage of allocated address space announced: 65.4 Percentage of available address space allocated: 94.6 Percentage of address space in use by end-sites: 85.3 Total number of prefixes smaller than registry allocations: 137383 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 81988 Total APNIC prefixes after maximum aggregation: 27957 APNIC Deaggregation factor: 2.93 Prefixes being announced from the APNIC address blocks: 78894 Unique aggregates announced from the APNIC address blocks: 34579 APNIC Region origin ASes present in the Internet Routing Table: 4218 APNIC Prefixes per ASN: 18.70 APNIC Region origin ASes announcing only one prefix: 1178 APNIC Region transit ASes present in the Internet Routing Table: 675 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 17 Number of APNIC addresses announced to Internet: 560261152 Equivalent to 33 /8s, 100 /16s and 232 /24s Percentage of available APNIC address space announced: 75.9 APNIC AS Blocks 4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079 55296-56319, 131072-132095 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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: 137432 Total ARIN prefixes after maximum aggregation: 71024 ARIN Deaggregation factor: 1.94 Prefixes being announced from the ARIN address blocks: 108852 Unique aggregates announced from the ARIN address blocks: 43520 ARIN Region origin ASes present in the Internet Routing Table: 13992 ARIN Prefixes per ASN: 7.78 ARIN Region origin ASes announcing only one prefix: 5369 ARIN Region transit ASes present in the Internet Routing Table: 1478 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 737933824 Equivalent to 43 /8s, 251 /16s and 250 /24s Percentage of available ARIN address space announced: 62.8 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 76974 Total RIPE prefixes after maximum aggregation: 44606 RIPE Deaggregation factor: 1.73 Prefixes being announced from the RIPE address blocks: 70398 Unique aggregates announced from the RIPE address blocks: 46166 RIPE Region origin ASes present in the Internet Routing Table: 14926 RIPE Prefixes per ASN: 4.72 RIPE Region origin ASes announcing only one prefix: 7695 RIPE Region transit ASes present in the Internet Routing Table: 2306 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 30 Number of RIPE addresses announced to Internet: 442325120 Equivalent to 26 /8s, 93 /16s and 88 /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, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 30290 Total LACNIC prefixes after maximum aggregation: 7185 LACNIC Deaggregation factor: 4.22 Prefixes being announced from the LACNIC address blocks: 28964 Unique aggregates announced from the LACNIC address blocks: 15428 LACNIC Region origin ASes present in the Internet Routing Table: 1371 LACNIC Prefixes per ASN: 21.13 LACNIC Region origin ASes announcing only one prefix: 427 LACNIC Region transit ASes present in the Internet Routing Table: 238 Average LACNIC Region AS path length visible: 4.3 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 76358016 Equivalent to 4 /8s, 141 /16s and 33 /24s Percentage of available LACNIC address space announced: 56.9 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7519 Total AfriNIC prefixes after maximum aggregation: 1866 AfriNIC Deaggregation factor: 4.03 Prefixes being announced from the AfriNIC address blocks: 5824 Unique aggregates announced from the AfriNIC address blocks: 1725 AfriNIC Region origin ASes present in the Internet Routing Table: 410 AfriNIC Prefixes per ASN: 14.20 AfriNIC Region origin ASes announcing only one prefix: 124 AfriNIC Region transit ASes present in the Internet Routing Table: 91 Average AfriNIC Region AS path length visible: 5.2 Max AfriNIC Region AS path length visible: 31 Number of AfriNIC addresses announced to Internet: 20921088 Equivalent to 1 /8s, 63 /16s and 59 /24s Percentage of available AfriNIC address space announced: 62.3 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1875 9453 513 Korea Telecom (KIX) 7545 1417 299 78 TPG Internet Pty Ltd 4755 1373 382 158 TATA Communications formerly 17488 1364 156 121 Hathway IP Over Cable Interne 17974 1274 304 79 PT TELEKOMUNIKASI INDONESIA 24560 1051 309 180 Bharti Airtel Ltd., Telemedia 9583 1030 76 493 Sify Limited 4808 977 1722 266 CNCGROUP IP network: China169 18101 892 116 134 Reliance Infocom Ltd Internet 9829 827 694 27 BSNL National Internet Backbo 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 3765 3667 278 bellsouth.net, inc. 4323 2621 1103 394 Time Warner Telecom 1785 1794 698 130 PaeTec Communications, Inc. 19262 1777 4833 279 Verizon Global Networks 20115 1506 1528 647 Charter Communications 7018 1437 5692 920 AT&T WorldNet Services 6478 1387 279 98 AT&T Worldnet Services 2386 1311 556 927 AT&T Data Communications Serv 11492 1236 231 74 Cable One 22773 1207 2859 62 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 3292 444 2027 389 TDC Tele Danmark 8866 420 133 25 Bulgarian Telecommunication C 8551 402 353 46 Bezeq International 702 397 1866 311 UUNET - Commercial IP service 34984 381 91 188 BILISIM TELEKOM 3301 379 1688 335 TeliaNet Sweden 3320 377 7332 330 Deutsche Telekom AG 30890 376 80 205 Evolva Telecom 12479 364 576 5 Uni2 Autonomous System 31148 359 19 79 FreeNet ISP 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 1332 247 150 TVCABLE BOGOTA 8151 1327 2597 363 UniNet S.A. de C.V. 28573 1220 920 84 NET Servicos de Comunicao S.A 7303 831 441 107 Telecom Argentina Stet-France 6503 785 223 258 AVANTEL, S.A. 22047 564 310 15 VTR PUNTO NET S.A. 14420 545 39 76 CORPORACION NACIONAL DE TELEC 3816 484 210 95 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A 14117 448 32 27 Telefonica del Sur 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 1060 445 10 TEDATA 24863 742 147 39 LINKdotNET AS number 36992 639 278 159 Etisalat MISR 3741 268 907 225 The Internet Solution 24835 210 78 10 RAYA Telecom - Egypt 6713 203 199 12 Itissalat Al-MAGHRIB 29571 203 19 11 Ci Telecom Autonomous system 2018 197 277 64 Tertiary Education Network 33776 196 12 14 Starcomms Nigeria Limited 16637 154 440 91 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 3765 3667 278 bellsouth.net, inc. 4323 2621 1103 394 Time Warner Telecom 4766 1875 9453 513 Korea Telecom (KIX) 1785 1794 698 130 PaeTec Communications, Inc. 19262 1777 4833 279 Verizon Global Networks 20115 1506 1528 647 Charter Communications 7018 1437 5692 920 AT&T WorldNet Services 7545 1417 299 78 TPG Internet Pty Ltd 6478 1387 279 98 AT&T Worldnet Services 4755 1373 382 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 2621 2227 Time Warner Telecom 1785 1794 1664 PaeTec Communications, Inc. 19262 1777 1498 Verizon Global Networks 4766 1875 1362 Korea Telecom (KIX) 7545 1417 1339 TPG Internet Pty Ltd 6478 1387 1289 AT&T Worldnet Services 17488 1364 1243 Hathway IP Over Cable Interne 4755 1373 1215 TATA Communications formerly 17974 1274 1195 PT TELEKOMUNIKASI INDONESIA 10620 1332 1182 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 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 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.21.192.0/20 11610 Internet Nebraska Corporation 64.21.212.0/22 11610 Internet Nebraska Corporation 64.21.216.0/21 11610 Internet Nebraska Corporation 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:10 /10:25 /11:68 /12:207 /13:420 /14:744 /15:1345 /16:11370 /17:5497 /18:9345 /19:18553 /20:23802 /21:23849 /22:31438 /23:30643 /24:174207 /25:999 /26:1129 /27:583 /28:155 /29:12 /30:2 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2330 3765 bellsouth.net, inc. 4323 1410 2621 Time Warner Telecom 6478 1349 1387 AT&T Worldnet Services 10620 1220 1332 TVCABLE BOGOTA 11492 1193 1236 Cable One 1785 1077 1794 PaeTec Communications, Inc. 18566 1069 1088 Covad Communications 7011 1058 1159 Citizens Utilities 8452 967 1060 TEDATA 19262 903 1777 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:87 2:12 4:13 8:313 12:2010 13:8 14:44 15:20 16:3 17:9 20:9 24:1386 27:383 31:1 32:61 33:12 38:696 40:97 41:2563 44:3 46:164 47:10 49:4 50:1 52:12 55:5 56:2 57:31 58:837 59:498 60:480 61:1112 62:1012 63:1964 64:3748 65:2344 66:4066 67:1819 68:1139 69:2850 70:757 71:376 72:1937 73:2 74:2334 75:295 76:326 77:868 78:691 79:445 80:1047 81:805 82:499 83:453 84:690 85:1020 86:433 87:694 88:326 89:1569 90:110 91:3125 92:431 93:1019 94:1110 95:700 96:395 97:222 98:628 99:33 101:3 108:64 109:708 110:434 111:608 112:305 113:305 114:483 115:607 116:1137 117:662 118:541 119:983 120:164 121:720 122:1596 123:917 124:1226 125:1270 128:228 129:152 130:167 131:566 132:275 133:20 134:207 135:46 136:212 137:139 138:280 139:109 140:479 141:198 142:347 143:383 144:498 145:55 146:432 147:174 148:621 149:308 150:146 151:231 152:293 153:175 154:3 155:369 156:166 157:334 158:112 159:361 160:313 161:198 162:271 163:166 164:424 165:349 166:469 167:424 168:683 169:154 170:718 171:61 172:2 173:1042 174:496 175:241 176:1 177:1 178:542 180:682 181:1 182:240 183:236 184:131 186:740 187:541 188:850 189:804 190:4189 192:5761 193:4752 194:3434 195:2826 196:1199 198:3542 199:3632 200:5419 201:1575 202:8158 203:8282 204:4008 205:2316 206:2566 207:3028 208:3907 209:3476 210:2559 211:1281 212:1798 213:1719 214:686 215:66 216:4769 217:1558 218:521 219:401 220:1182 221:429 222:343 223:58 End of report From lists.james.edwards at gmail.com Fri Oct 22 14:15:23 2010 From: lists.james.edwards at gmail.com (james edwards) Date: Fri, 22 Oct 2010 13:15:23 -0600 Subject: Optical Wireless Message-ID: I am looking for some vendors that make PtP optical wireless (laser) gear. I have a project where I have to link 2 buildings separated by a 5 lane road. Buildings are at least 10 stories high. Multiple reasons why RF (WiFi) or fiber under the street will not work, plus some layer 8 issues. I need 100 mbs, Ethernet is the protocol transported. PoE would be nice but not a show stopper. Anyone have experience with this kind of gear and can suggest a vendor ? Thanks, -- James H. Edwards Network Systems Administrator Judicial Information Division jedwards at nmcourts.gov From gbonser at seven.com Fri Oct 22 14:20:45 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 22 Oct 2010 12:20:45 -0700 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <20101022175403.GA11762@vacation.karoshi.com.> References: <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> <20101022175403.GA11762@vacation.karoshi.com.> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C44C@RWC-EX1.corp.seven.com> > From: bmanning at vacation.karoshi.com > > > ah... but the trick is to only need enough IPv4 in the pool > to dynamically talk to the Internet. Native v6 to Native v6 > never has to drop back to the Internet, It uses native v6 > paths. So the larger the v6 uptake, the fewer Internet addreses > you'll need to keep around in your pool. Ok, it wasn't clear in the docs that it was a dynamic translation from v6 to a smaller pool of v4 IPs, it implied it was a direct translation. G From bclark at spectraaccess.com Fri Oct 22 14:29:46 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Fri, 22 Oct 2010 15:29:46 -0400 Subject: Optical Wireless In-Reply-To: References: Message-ID: <4CC1E62A.1060408@spectraaccess.com> RF in general or you don't want to use wi-fi which is understandable? For our telcom back-haul needs which needs to meet carrier class grade we have found Ceregon, Redline, and Dragonwave to work flawlessly. Redline and Dragon are PoE, Ceregon use coax. Unfortunately we don't use laser because the weather would be a problem for us. Bret On 10/22/2010 03:15 PM, james edwards wrote: > I am looking for some vendors that make PtP optical wireless (laser) gear. I > have a project where I have to link 2 buildings separated by a 5 lane road. > Buildings are at least 10 stories high. Multiple reasons why RF (WiFi) or > fiber under the street will not work, plus some layer 8 issues. > I need 100 mbs, Ethernet is the protocol transported. PoE would be nice but > not a show stopper. Anyone have experience with this kind of gear and can > suggest a vendor ? > > > Thanks, > > From Justin.Dixon at BBandT.com Fri Oct 22 14:34:56 2010 From: Justin.Dixon at BBandT.com (Dixon, Justin) Date: Fri, 22 Oct 2010 15:34:56 -0400 Subject: Optical Wireless In-Reply-To: References: Message-ID: <91864382B2433640BA2A447041B3DBC31185CFB0@wil-exmb01.bbtnet.com> I am looking for some vendors that make PtP optical wireless (laser) gear. I have a project where I have to link 2 buildings separated by a 5 lane road. Buildings are at least 10 stories high. Multiple reasons why RF (WiFi) or fiber under the street will not work, plus some layer 8 issues. I need 100 mbs, Ethernet is the protocol transported. PoE would be nice but not a show stopper. Anyone have experience with this kind of gear and can suggest a vendor ? Thanks, -- James H. Edwards Network Systems Administrator Judicial Information Division jedwards at nmcourts.gov ----------------------------------------- Something like this???? From Justin.Dixon at BBandT.com Fri Oct 22 14:35:27 2010 From: Justin.Dixon at BBandT.com (Dixon, Justin) Date: Fri, 22 Oct 2010 15:35:27 -0400 Subject: Optical Wireless In-Reply-To: References: Message-ID: <91864382B2433640BA2A447041B3DBC31185CFB1@wil-exmb01.bbtnet.com> http://www.lightpointe.com/downloads/datasheets/FlightStrata155E_G.pdf -----Original Message----- From: james edwards [mailto:lists.james.edwards at gmail.com] Sent: Friday, October 22, 2010 15:15 To: nanog at nanog.org Subject: Optical Wireless I am looking for some vendors that make PtP optical wireless (laser) gear. I have a project where I have to link 2 buildings separated by a 5 lane road. Buildings are at least 10 stories high. Multiple reasons why RF (WiFi) or fiber under the street will not work, plus some layer 8 issues. I need 100 mbs, Ethernet is the protocol transported. PoE would be nice but not a show stopper. Anyone have experience with this kind of gear and can suggest a vendor ? Thanks, -- James H. Edwards Network Systems Administrator Judicial Information Division jedwards at nmcourts.gov From cmaurand at xyonet.com Fri Oct 22 14:36:35 2010 From: cmaurand at xyonet.com (Curtis Maurand) Date: Fri, 22 Oct 2010 15:36:35 -0400 Subject: Optical Wireless In-Reply-To: References: Message-ID: <4CC1E7C3.6060400@xyonet.com> Canon. Canobeam laser systems. Very nice, very fast. I've heard of installations going around a mile and stayed up in a snow storm. Cheers, Curtis On 10/22/2010 3:15 PM, james edwards wrote: > I am looking for some vendors that make PtP optical wireless (laser) gear. I > have a project where I have to link 2 buildings separated by a 5 lane road. > Buildings are at least 10 stories high. Multiple reasons why RF (WiFi) or > fiber under the street will not work, plus some layer 8 issues. > I need 100 mbs, Ethernet is the protocol transported. PoE would be nice but > not a show stopper. Anyone have experience with this kind of gear and can > suggest a vendor ? > > > Thanks, > From aaron.glenn at gmail.com Fri Oct 22 14:58:08 2010 From: aaron.glenn at gmail.com (Aaron Glenn) Date: Fri, 22 Oct 2010 14:58:08 -0500 Subject: ipv6 vs. LAMP In-Reply-To: <4CC1BC8F.6040705@nwwnet.net> References: <1287694429.4968.96.camel@wednesday> <20101021214354.GA76784@ussenterprise.ufp.org> <20101021215259.GS2843@dan.olp.net> <4CC0B95A.8070003@bogus.com> <4CC1BC8F.6040705@nwwnet.net> Message-ID: On Fri, Oct 22, 2010 at 11:32 AM, Scott Reed wrote: > Public or not, if someone wants to run IPv6 only, they shouldn't have to > have the v4 stack just for the database. ?Databases must work on the v6 > stack. amen. so isn't that a dba issue and not a netop issue? I subscribe to postgresql-* lists for my dba fill (: From bmanning at vacation.karoshi.com Fri Oct 22 15:36:40 2010 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 22 Oct 2010 20:36:40 +0000 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C44C@RWC-EX1.corp.seven.com> References: <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> <20101022175403.GA11762@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C44C@RWC-EX1.corp.seven.com> Message-ID: <20101022203640.GD11762@vacation.karoshi.com.> On Fri, Oct 22, 2010 at 12:20:45PM -0700, George Bonser wrote: > > > > From: bmanning at vacation.karoshi.com > > > > > > ah... but the trick is to only need enough IPv4 in the pool > > to dynamically talk to the Internet. Native v6 to Native v6 > > never has to drop back to the Internet, It uses native v6 > > paths. So the larger the v6 uptake, the fewer Internet addreses > > you'll need to keep around in your pool. > > Ok, it wasn't clear in the docs that it was a dynamic translation from > v6 to a smaller pool of v4 IPs, it implied it was a direct translation. > > G i think it started out that way. one of my students tweeked DHCP to do the right thing wrt IP assignment from the pool (can't use the MAC, must use the v6 address) and then dynamic DNS update. Others have looked at and built higher capacity tools - you could ask Charlie Perkins about his experiences. End of the day, this isn't rocket science, isn't new, and there are communities of folks who have, in their own quiet way, made the switch already. for some, a flag day may occur. I think it will be rare, but it could happen. for the aware, moving to IPv6 was something we planned on and executed over the past few years. for the less aware, they are just waking up and are concerned. some are still sleeping. paraphrasing N.Maxwell; "$Diety does not use the voice of thunder when a still small voice will do." anyone still not paying attention? (read the CERNET2 reports on the costs of dual-stack...) Native may be your best long term bet. --bill From nathan at atlasnetworks.us Fri Oct 22 16:05:47 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Fri, 22 Oct 2010 21:05:47 +0000 Subject: Optical Wireless In-Reply-To: <4CC1E7C3.6060400@xyonet.com> References: <4CC1E7C3.6060400@xyonet.com> Message-ID: <8C26A4FDAE599041A13EB499117D3C284062D12B@ex-mb-2.corp.atlasnetworks.us> > > I am looking for some vendors that make PtP optical wireless (laser) > > gear. > Any reason you want an optical wavelength link, rather than a 23, 38, 60 or 80Ghz Microwave link? Best Regards, Nathan Eisenberg From cidr-report at potaroo.net Fri Oct 22 17:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Oct 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201010222200.o9MM02Ml070701@wattle.apnic.net> BGP Update Report Interval: 14-Oct-10 -to- 21-Oct-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9476 26169 3.5% 6542.2 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 2 - AS7315 19372 2.6% 289.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 3 - AS8151 19228 2.6% 11.4 -- Uninet S.A. de C.V. 4 - AS4538 16669 2.3% 3.3 -- ERX-CERNET-BKB China Education and Research Network Center 5 - AS3464 15267 2.1% 545.2 -- ASC-NET - Alabama Supercomputer Network 6 - AS14420 12815 1.7% 23.5 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 7 - AS23700 12012 1.6% 82.3 -- BM-AS-ID PT. Broadband Multimedia, Tbk 8 - AS32528 10980 1.5% 2745.0 -- ABBOTT Abbot Labs 9 - AS6128 10200 1.4% 5.2 -- CABLE-NET-1 - Cablevision Systems Corp. 10 - AS5536 8971 1.2% 263.9 -- Internet-Egypt 11 - AS33363 7755 1.1% 72.5 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 12 - AS7552 7303 1.0% 28.9 -- VIETEL-AS-AP Vietel Corporation 13 - AS9829 7242 1.0% 27.3 -- BSNL-NIB National Internet Backbone 14 - AS12332 7154 1.0% 117.3 -- PRIMORYE-AS Open Joint Stock Company "Far East Telecommunications Company" 15 - AS6517 6521 0.9% 114.4 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 16 - AS5800 6238 0.8% 28.9 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 17 - AS3549 5663 0.8% 59.0 -- GBLX Global Crossing Ltd. 18 - AS35931 5426 0.7% 1808.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 19 - AS3586 5192 0.7% 432.7 -- UWI ASN-UWI 20 - AS24863 4757 0.6% 10.0 -- LINKdotNET-AS TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9476 26169 3.5% 6542.2 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 2 - AS32528 10980 1.5% 2745.0 -- ABBOTT Abbot Labs 3 - AS21017 4310 0.6% 2155.0 -- VSI-AS VSI AS 4 - AS35931 5426 0.7% 1808.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 5 - AS5863 1467 0.2% 733.5 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 6 - AS22753 1335 0.2% 667.5 -- REDHAT-STUTTGART REDHAT Stuttgart 7 - AS3464 15267 2.1% 545.2 -- ASC-NET - Alabama Supercomputer Network 8 - AS15984 542 0.1% 542.0 -- The Joint-Stock Commercial Bank CentroCredit. 9 - AS28175 1073 0.1% 536.5 -- 10 - AS17904 470 0.1% 470.0 -- SLTASUL-LK Sri Lankan Airlines 11 - AS3586 5192 0.7% 432.7 -- UWI ASN-UWI 12 - AS55311 368 0.1% 368.0 -- LIENVIETBANK-AS-VN LienViet Joint Stock Commercial Bank 13 - AS19174 355 0.1% 355.0 -- CNC-USA - China Netcom (USA) Operations Ltd. 14 - AS17029 348 0.1% 348.0 -- CHP-NET - California Highway Patrol 15 - AS38759 339 0.1% 339.0 -- AIX-NAP-AS2-ID TRANSMEDIA INDONESIA, PT 16 - AS7315 19372 2.6% 289.1 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 17 - AS38825 264 0.0% 264.0 -- BELLPOTTER-AP Bell Potter Securities 18 - AS5536 8971 1.2% 263.9 -- Internet-Egypt 19 - AS10445 1210 0.2% 242.0 -- HTG - Huntleigh Telcom 20 - AS31055 483 0.1% 241.5 -- CONSULTIX-AS Consultix GmbH TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.1.14.0/24 14513 1.8% AS9476 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 2 - 203.1.13.0/24 11650 1.4% AS9476 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 3 - 129.66.0.0/17 7836 0.9% AS3464 -- ASC-NET - Alabama Supercomputer Network 4 - 129.66.128.0/17 7352 0.9% AS3464 -- ASC-NET - Alabama Supercomputer Network 5 - 76.74.88.0/23 6411 0.8% AS6517 -- RELIANCEGLOBALCOM - Reliance Globalcom Services, Inc 6 - 130.36.34.0/24 5482 0.7% AS32528 -- ABBOTT Abbot Labs 7 - 130.36.35.0/24 5482 0.7% AS32528 -- ABBOTT Abbot Labs 8 - 201.134.18.0/24 4272 0.5% AS8151 -- Uninet S.A. de C.V. 9 - 190.65.228.0/22 3894 0.5% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 10 - 72.31.122.0/24 3761 0.5% AS33363 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 11 - 72.31.98.0/24 3725 0.5% AS33363 -- BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC 12 - 63.211.68.0/22 3601 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - 208.54.82.0/24 2486 0.3% AS701 -- UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 14 - 95.32.192.0/18 2267 0.3% AS21017 -- VSI-AS VSI AS 15 - 202.92.235.0/24 2158 0.3% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 16 - 95.32.128.0/18 2043 0.2% AS21017 -- VSI-AS VSI AS 17 - 198.140.43.0/24 1779 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 18 - 206.184.16.0/24 1489 0.2% AS174 -- COGENT Cogent/PSI 19 - 214.15.65.0/24 1390 0.2% AS5863 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - 66.187.234.0/24 1334 0.2% AS22753 -- REDHAT-STUTTGART REDHAT Stuttgart 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 Oct 22 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 22 Oct 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201010222200.o9MM00fV070685@wattle.apnic.net> This report has been generated at Fri Oct 22 21:11:51 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 15-10-10 338841 210332 16-10-10 338847 210836 17-10-10 339053 210881 18-10-10 339193 210990 19-10-10 339234 194438 20-10-10 334281 194640 21-10-10 334260 197374 22-10-10 335372 198943 AS Summary 35652 Number of ASes in routing system 15266 Number of ASes announcing only one prefix 4491 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 101038848 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'). --- 22Oct10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 335665 199028 136637 40.7% All ASes AS6389 3763 289 3474 92.3% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4491 1503 2988 66.5% TWTC - tw telecom holdings, inc. AS19262 1776 281 1495 84.2% VZGNI-TRANSIT - Verizon Online LLC AS4766 1732 530 1202 69.4% KIXS-AS-KR Korea Telecom AS22773 1206 64 1142 94.7% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS4755 1373 276 1097 79.9% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS17488 1364 270 1094 80.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS1785 1797 770 1027 57.2% AS-PAETEC-NET - PaeTec Communications, Inc. AS24560 1052 201 851 80.9% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS28573 1202 359 843 70.1% NET Servicos de Comunicao S.A. AS6478 1387 550 837 60.3% ATT-INTERNET3 - AT&T Services, Inc. AS5668 1003 178 825 82.3% AS-5668 - CenturyTel Internet Holdings, Inc. AS10620 1329 509 820 61.7% Telmex Colombia S.A. AS18566 1060 260 800 75.5% COVAD - Covad Communications Co. AS18101 891 136 755 84.7% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS7545 1426 711 715 50.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS3356 1171 468 703 60.0% LEVEL3 Level 3 Communications AS8452 1062 396 666 62.7% TE-AS TE-AS AS33363 1416 753 663 46.8% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS8151 1338 686 652 48.7% Uninet S.A. de C.V. AS4808 919 270 649 70.6% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7303 832 235 597 71.8% Telecom Argentina S.A. AS17676 638 66 572 89.7% GIGAINFRA Softbank BB Corp. AS11492 1237 681 556 44.9% CABLEONE - CABLE ONE, INC. AS4780 707 169 538 76.1% SEEDNET Digital United Inc. AS22047 564 30 534 94.7% VTR BANDA ANCHA S.A. AS20115 1506 981 525 34.9% CHARTER-NET-HKY-NC - Charter Communications AS7552 646 131 515 79.7% VIETEL-AS-AP Vietel Corporation AS7018 1432 925 507 35.4% ATT-INTERNET4 - AT&T Services, Inc. AS4804 581 75 506 87.1% MPX-AS Microplex PTY LTD Total 40901 12753 28148 68.8% Top 30 total Possible Bogus Routes 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 41.222.79.0/24 AS36938 AMSCOTELECOMS Amsco Telecommunications Nigeria Limited 41.223.92.0/22 AS36936 CELTEL-GABON Celtel Gabon Internet Service 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 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 CSI-NET - C D C A. CHARMING SHOPPES OF DELAWARE, INC. 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. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 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.0.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.5.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.6.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.11.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.20.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.29.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.31.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.43.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 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 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 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 177.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 181.1.8.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.201.248.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.249.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.250.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.251.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.253.0/24 AS30991 SAHANNET Sahannet AS Network 196.201.255.0/24 AS30991 SAHANNET Sahannet AS Network 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.10.0.0/16 AS721 DNIC-ASBLK-00721-00726 - DoD Network Information Center 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.52.33.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 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.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.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 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 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 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.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.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 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 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 kauer at biplane.com.au Fri Oct 22 17:27:44 2010 From: kauer at biplane.com.au (Karl Auer) Date: Sat, 23 Oct 2010 09:27:44 +1100 Subject: IPv6 fc00::/7 =?UTF-8?Q?=E2=80=94?= Unique local addresses In-Reply-To: <20101023034834.15fec97c@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101023034834.15fec97c@opy.nosense.org> Message-ID: <1287786464.4887.6.camel@karl> On Sat, 2010-10-23 at 03:48 +1030, Mark Smith wrote: > An RA is single, periodic, in the order of 100s of seconds, multicast > packet. If you're arguing against the cost of that, then I think you're > being a bit too precious with your packets. Just to be clear on this: I was taking issue solely with the idea that DHCPv6 requires RA. It doesn't. Regards, K. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (kauer at biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: From owen at delong.com Fri Oct 22 17:42:41 2010 From: owen at delong.com (Owen DeLong) Date: Fri, 22 Oct 2010 15:42:41 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101023034834.15fec97c@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101023034834.15fec97c@opy.nosense.org> Message-ID: <61A50C47-4D70-426E-949B-12678E792471@delong.com> >>> >> Actually, it's not pointless at all. The RA system assumes that all routers >> capable of announcing RAs are default routers and that virtually all routers >> are created equal (yes, you have high/medium/low, but, really, since you >> have to use high for everything in any reasonable deployment...) >> > > No it doesn't. You can set the router lifetime to zero, which indicates > to the end-node that the RA isn't announcing a default router. In this > case, it may be announcing M/O bit, prefix or other parameters. > DHCPv6 can selectively give different information to different hosts on the same wire segment. RA cannot. >> There are real environments where it's desirable to have a way to tell >> different clients on a network to use different default gateways or >> default gateway sets. >> >> Owen >> From brandon at burn.net Fri Oct 22 17:44:23 2010 From: brandon at burn.net (Brandon Applegate) Date: Fri, 22 Oct 2010 18:44:23 -0400 (EDT) Subject: Sprint BGP/routing engineer needed Message-ID: If you have visibility and can fix things - I would greatly appreciate an off-list contact. We have a reachability issue through Level3, but it's on the Sprint side of a specific peer and the Level3 support person can't fit the pieces together mentally. We are still pursuing our ticket and trying to do it 'by the book' (we are a Level3 customer) but an off-list contact would be very much appreciated. -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." From mpalmer at hezmatt.org Fri Oct 22 17:57:03 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Sat, 23 Oct 2010 09:57:03 +1100 Subject: DHS and NSA getting married? In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> <01D3B1BF-5CFE-4A64-8545-C420E32C687F@cs.columbia.edu> Message-ID: <20101022225703.GE11984@hezmatt.org> On Fri, Oct 22, 2010 at 11:32:38AM -0400, Christopher Morrow wrote: > On Fri, Oct 22, 2010 at 11:08 AM, Steven Bellovin wrote: > > > ? ? ? ?In the words of a former Justice Department official involved with critical infrastructure protection, ?I have seen too many situations where government officials claimed a high degree of confidence as to the source, intent, and scope of an attack, and it turned out they were wrong on every aspect of it. That is, they were often wrong, but never in doubt.? > > this happens with non-cyber things as well... all the time. Point > being: "cyber-attack" follows down the path of 'send the people that > deal with "attacks" to deal with this'. For non-cyber things, that would be "the police" almost every time. We don't send a squad of marines out after every mugger (although it'd have an interesting deterrent effect...) - Matt From lostinmoscow at gmail.com Fri Oct 22 18:07:46 2010 From: lostinmoscow at gmail.com (Quinn Kuzmich) Date: Fri, 22 Oct 2010 17:07:46 -0600 Subject: DHS and NSA getting married? In-Reply-To: <20101022225703.GE11984@hezmatt.org> References: <5A6D953473350C4B9995546AFE9939EE0B14C42B@RWC-EX1.corp.seven.com> <01D3B1BF-5CFE-4A64-8545-C420E32C687F@cs.columbia.edu> <20101022225703.GE11984@hezmatt.org> Message-ID: You know, if my tax dollars paid for that I'd probably sit back with a video camera and laugh. Q On Fri, Oct 22, 2010 at 4:57 PM, Matthew Palmer wrote: > On Fri, Oct 22, 2010 at 11:32:38AM -0400, Christopher Morrow wrote: > > On Fri, Oct 22, 2010 at 11:08 AM, Steven Bellovin > wrote: > > > > > In the words of a former Justice Department official involved > with critical infrastructure protection, ?I have seen too many situations > where government officials claimed a high degree of confidence as to the > source, intent, and scope of an attack, and it turned out they were wrong on > every aspect of it. That is, they were often wrong, but never in doubt.? > > > > this happens with non-cyber things as well... all the time. Point > > being: "cyber-attack" follows down the path of 'send the people that > > deal with "attacks" to deal with this'. > > For non-cyber things, that would be "the police" almost every time. We > don't send a squad of marines out after every mugger (although it'd have an > interesting deterrent effect...) > > - Matt > > From dr at cluenet.de Fri Oct 22 18:37:15 2010 From: dr at cluenet.de (Daniel Roesen) Date: Sat, 23 Oct 2010 01:37:15 +0200 Subject: IPv6 fc00::/7 ? Unique local addresses In-Reply-To: <4CC197E5.10202@brightok.net> References: <4CC0F16F.2060706@brightok.net> <4CC197E5.10202@brightok.net> Message-ID: <20101022233715.GA21900@srv03.cluenet.de> On Fri, Oct 22, 2010 at 08:55:49AM -0500, Jack Bates wrote: >> I suppose you could run DHCPv6 on a subnet to give hosts addresses >> but never give them a default gateway, but that would be a little >> useless no? > > Works great when you don't need routing. Or the default route should point out a different interface. Think e.g. of DHCP used for a management network. You don't want a default route, but in case of a routed management network, signal a set of specific routes. http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-05, there we go. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From brandon at burn.net Fri Oct 22 18:38:36 2010 From: brandon at burn.net (Brandon Applegate) Date: Fri, 22 Oct 2010 19:38:36 -0400 (EDT) Subject: Sprint BGP/routing engineer needed In-Reply-To: References: Message-ID: One of our guys navigated a Sprint phone tree and hit a deposit of clue. Issue is fixed, it was indeed on the Sprint side. Thanks to Sprint for responding and fixing this, especially when we aren't even your customer (yet). -- Brandon Applegate - CCIE 10273 PGP Key fingerprint: 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 "SH1-0151. This is the serial number, of our orbital gun." On Fri, 22 Oct 2010, Brandon Applegate wrote: > If you have visibility and can fix things - I would greatly appreciate an > off-list contact. We have a reachability issue through Level3, but it's on > the Sprint side of a specific peer and the Level3 support person can't fit > the pieces together mentally. > > We are still pursuing our ticket and trying to do it 'by the book' (we are a > Level3 customer) but an off-list contact would be very much appreciated. > > -- > Brandon Applegate - CCIE 10273 > PGP Key fingerprint: > 7407 DC86 AA7B A57F 62D1 A715 3C63 66A1 181E 6996 > "SH1-0151. This is the serial number, of our orbital gun." > > > From bill at herrin.us Fri Oct 22 20:10:21 2010 From: bill at herrin.us (William Herrin) Date: Fri, 22 Oct 2010 21:10:21 -0400 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance_=28Was=3A_IPv6_fc00=3A=3A=2F?= =?windows-1252?Q?7_=97_Unique_local_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> <4CC11F05.50109@bogus.com> Message-ID: On Fri, Oct 22, 2010 at 11:40 AM, Owen DeLong wrote: > On Oct 22, 2010, at 5:25 AM, William Herrin wrote: >> On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli wrote: >>> On 10/21/10 6:38 PM, Owen DeLong wrote: >>>> On Oct 21, 2010, at 3:42 PM, Jack Bates wrote: >>>>> On 10/21/2010 5:27 PM, Joel Jaeggli wrote: >>>>>> >>>>>> Announce your gua and then blackhole it and monitor your prefix. >>>>>> you can tell if you're leaking. it's generally pretty hard to >>>>>> tell if you're leaking rfc 1918 since your advertisement may well >>>>>> work depending on the filters of your peers but not very far. >>>>> >>>>> This is always the argument I hear from corporate customers >>>>> concerning wanting NAT. If ?mistake is made, the RFC 1918 space >>>>> isn't routable. They often desire the same out of v6 for that >>>>> reason alone. >>> >>> the rfc 1918 space is being routed inside almost all your adjacent >>> networks, so if their ingress filtering is working as expected, great, >>> but you're only a filter away from leaking. >> >> A filter away from leaking to -one- of the millions of entities on the >> internet. Two filters away from leaking to two. >> > This underestimates the transitive property of leakage. Owen, Just for grins, let's put some rough math to that assertion. The average percentage of the Internet reached by a ULA or RFC1918 leak will be close to: (1-A)^C A = the probability of any given organization filtering private address announcements and/or private address packets at their borders B = the average width of the Internet in organizations (which should be slightly higher than the width in ASes) So filling in example numbers for the equation, if 50% filter announcements or packets and the Internet is an average of 10 organizations wide then the scope of an address leak is: (1-0.5)^10 = 0.5 ^ 10 = 0.1% of the Internet reached by the leak. In that scenario, the leak is in a very real sense one thousandth as serious as if the leak had been from GUA space which all of the organizations make an effort to carry. And that's assuming that fully half the organizations on the Internet just don't bother trying to filter RFC1918 or ULA use from their public networks. If 75% filter then a whopping 0.0001% of the Internet is reached by the leak. Now, if only 10% filter then your leak reaches a largish 6% of the Internet. That's a worry for someone hoping for some security benefits to not using GUA space but it's far too little to support this bizarre concern that ULA space would somehow supplant GUA space on the public Internet and explode the routers. Of course, I make no claim to know what the correct two constants are in that equation. Perhaps the Internet is thinner. Perhaps nobody filters egress packets despite years of proselytizing. Perhaps the ISP peering interconnectedness corrupts the combinatorics I used to derive the equation in a more substantial fashion than is obvious. Or perhaps your worry about route leakage from non-GUA space really is as overblown as the math suggests. 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 Oct 23 00:57:25 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 22 Oct 2010 22:57:25 -0700 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <20101022203640.GD11762@vacation.karoshi.com.> References: <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> <20101022175403.GA11762@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C44C@RWC-EX1.corp.seven.com> <20101022203640.GD11762@vacation.karoshi.com.> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C464@RWC-EX1.corp.seven.com> > Sent: Friday, October 22, 2010 1:37 PM > To: George Bonser > Cc: bmanning > Subject: Re: IPv4 sunset date revised : 2009-02-05 > > anyone still not paying attention? (read the CERNET2 reports > on the costs of dual-stack...) Native may be your best long > term bet. > > --bill That is a point I have made with people at times, too. If you are struggling holding the current table of 32-bit routes, what is the addition of a bunch of 128-bit routes going to do? Full routes dual-stack is going to hurt people in a lot of places. This was another reason for aggressively reclaiming unused IP addresses without issuing any new, it would reduce the extent to which v4 could continue to frag. It will be sort of like a bulge moving through a snake for a while as the v6 table begins to grow with multihomed /48's and the v4 table also grows with increased fragmentation. And "Katy, bar the door" if they take away the multihomed restriction for GU /48's. From owen at delong.com Sat Oct 23 02:07:41 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Oct 2010 00:07:41 -0700 Subject: =?windows-1252?Q?Re:_Why_ULA:_low_collision_chance_=28Was:_IPv6_?= =?windows-1252?Q?fc00::/7_=97_Unique_local_addresses=29?= In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> <4CC11F05.50109@bogus.com> Message-ID: <4D073B8A-E29A-430E-8CA4-0FBE19D9A054@delong.com> On Oct 22, 2010, at 6:10 PM, William Herrin wrote: > On Fri, Oct 22, 2010 at 11:40 AM, Owen DeLong wrote: >> On Oct 22, 2010, at 5:25 AM, William Herrin wrote: >>> On Fri, Oct 22, 2010 at 1:20 AM, Joel Jaeggli wrote: >>>> On 10/21/10 6:38 PM, Owen DeLong wrote: >>>>> On Oct 21, 2010, at 3:42 PM, Jack Bates wrote: >>>>>> On 10/21/2010 5:27 PM, Joel Jaeggli wrote: >>>>>>> >>>>>>> Announce your gua and then blackhole it and monitor your prefix. >>>>>>> you can tell if you're leaking. it's generally pretty hard to >>>>>>> tell if you're leaking rfc 1918 since your advertisement may well >>>>>>> work depending on the filters of your peers but not very far. >>>>>> >>>>>> This is always the argument I hear from corporate customers >>>>>> concerning wanting NAT. If mistake is made, the RFC 1918 space >>>>>> isn't routable. They often desire the same out of v6 for that >>>>>> reason alone. >>>> >>>> the rfc 1918 space is being routed inside almost all your adjacent >>>> networks, so if their ingress filtering is working as expected, great, >>>> but you're only a filter away from leaking. >>> >>> A filter away from leaking to -one- of the millions of entities on the >>> internet. Two filters away from leaking to two. >>> >> This underestimates the transitive property of leakage. > > Owen, > > Just for grins, let's put some rough math to that assertion. The > average percentage of the Internet reached by a ULA or RFC1918 leak > will be close to: > > (1-A)^C > > A = the probability of any given organization filtering private > address announcements and/or private address packets at their borders > B = the average width of the Internet in organizations (which should > be slightly higher than the width in ASes) > I'll note that you don't have a B in your equation and didn't define C, so, I'll presume that C= the average width... > So filling in example numbers for the equation, if 50% filter > announcements or packets and the Internet is an average of 10 > organizations wide then the scope of an address leak is: > > (1-0.5)^10 = 0.5 ^ 10 = 0.1% of the Internet reached by the leak. > I think your estimation of 50% is highly optimistic. I also think you underestimate the diameter of the internet, being much closer to 25 than 10 from what I can see. Filling in more realistic (based on my observations) numbers of 5% and 25, my numbers come out as: (1-0.05)^25 = 0.95 ^ 25 = 0.27 = a little more than 1/4 of the internet. > In that scenario, the leak is in a very real sense one thousandth as > serious as if the leak had been from GUA space which all of the > organizations make an effort to carry. And that's assuming that fully > half the organizations on the Internet just don't bother trying to > filter RFC1918 or ULA use from their public networks. > With more realistic numbers, it's closer to 1/4 of the impact of a leak from GUA where you both leaked the route and failed your IP filter and didn't null-route the prefix at your border. (Gee, that seems like three mistakes you need to make for the GUA problem to take effect instead of just the "two" you claimed for ULA). > If 75% filter then a whopping 0.0001% of the Internet is reached by the leak. > ROFLMAO... Yeah, and if Ostriches had 15 times the wing surface area they could probably fly. > Now, if only 10% filter then your leak reaches a largish 6% of the > Internet. That's a worry for someone hoping for some security benefits > to not using GUA space but it's far too little to support this bizarre > concern that ULA space would somehow supplant GUA space on the public > Internet and explode the routers. > ULA won't supplant GUA, it will be much more insidious than that. Most people will still use GUA for GUA purposes. However, deliberate routing of ULA will start small and slowly spread over time like a slow-growing cancer. You won't even really detect it until it has metastasized to such an extent that nothing can be done about it. You can't talk about the impact of an accidental leak and compare that to the impact of a deliberate choice to do something. They are two entirely different effects. > > Of course, I make no claim to know what the correct two constants are > in that equation. Perhaps the Internet is thinner. Perhaps nobody > filters egress packets despite years of proselytizing. Perhaps the ISP > peering interconnectedness corrupts the combinatorics I used to derive > the equation in a more substantial fashion than is obvious. > I think that the internet is actually much wider and that the actual filtration rate is much closer to 5%. I also think that the peering combinatorics do probably corrupt your equation, but, I'm not sure in which direction or to what extent. It would be pretty hard to estimate, so, I'm willing to go with it for now. > Or perhaps your worry about route leakage from non-GUA space really is > as overblown as the math suggests. > I'm not worried about leakage. You're claiming that a low probability of leakage provides a security benefit, I'm claiming that your security benefit is actually a false sense of security. (i.e. The benefit claimed for ULA is somewhere between small and non-existent). In a separate topic, I believe that DELIBERATE routing of ULA will be a very likely outcome of current policies eventually resulting in ULA being ubiquitously routed just as GUA is intended to be. This unfortunate end result of the combination of human nature to do the expedient rather than the correct will eventually remove any perceive benefits to ULA and cause additional problems as ULA becomes a globally routable resource not subject to RIR policy. The two issues are related, but, very different problems. (Actually, the first issue isn't really a problem unless you are depending on ULA to provide some form of security benefit). In my opinion, the far more secure thing to do is to use GUA. Put the hosts you want to be reachable from the outside in specific ranges of your GUA. For example: 2620:0db8:532a::/48 Total assignment for end site 2620:0db8:532a::/56 Space reserved for externally reachable Configure the following on your border routers: Routes: 2620:0db8:532a::/56 dynamic or static routes to correct destinations. 2620:0db8:532a:100::/55 -> null 2620:0db8:532a:200::/54 -> null 2620:0db8:532a:400::/53 -> null 2620:0db8:532a:800::/52 -> null 2620:0db8:532a:1000::/51 -> null 2620:0db8:532a:2000::/50 -> null 2620:0db8:532a:4000::/49 -> null 2620:0db8:532a:8000::/48 -> null Route filters: From internal interfaces: Accept 2620:0db8:532a::/56 or longer Deny 2620:0db8:532a:: ge /48 le /55 Packet filters: Stateful (outbound to internet): Permit any Default Deny any any Stateful (inbound from internet): Permit Permit Deny any 2620:0db8:532a::/48 Default deny inbound Static (outbound to internal interfaces) permit any 2620:0db8:532a::/56 deny any any Static (inbound from internal interfaces) permit any deny any any (Assuming a router capable of stateful and static filters where a packet must be permitted by both in order to be forwarded. This is the case for JunOS. I'm not sure about Cisco or others. If you can only do stateless on your router, then, you lose one layer of defense, but, not all). Presumably you have stateful firewall(s) inside your border with appropriate full stateful policies. Now, in order to reach one of the hosts in the GUA space being used for the internal-only communications, one needs to make the following unauthorized or errant changes: 1. Override the null route. (either a static route or an unauthorized change to the dynamic filter + a dynamic route generated by or through the firewall). 2. Override the stateful Packet filter. 3. Override the Static packet filter. 4. Permit the flow on the firewall. Or, the easier approach: 1. Configure the host with an externally reachable address in the public accessible host range. 2. Plug the host into one of the publicly reachable networks rather than an internal network. 3. Add inbound permits to the stateful packet filter. 4. Add inbound permits to the firewall. Eiher way, it takes at least four acts of fat-fingered or malicious activity on hosts that have a security border role in order to achieve a meaningful leak, not the single error you claimed. Owen From jbates at brightok.net Sat Oct 23 08:54:35 2010 From: jbates at brightok.net (Jack Bates) Date: Sat, 23 Oct 2010 08:54:35 -0500 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance?= =?windows-1252?Q?_=28Was=3A_IPv6_fc00=3A=3A/7_=97_Unique_loc?= =?windows-1252?Q?al_addresses=29?= In-Reply-To: <4D073B8A-E29A-430E-8CA4-0FBE19D9A054@delong.com> References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> <4CC11F05.50109@bogus.com> <4D073B8A-E29A-430E-8CA4-0FBE19D9A054@delong.com> Message-ID: <4CC2E91B.8070700@brightok.net> On 10/23/2010 2:07 AM, Owen DeLong wrote: > However, deliberate routing of ULA will start small and slowly spread > over time like a slow-growing cancer. You won't even really detect it > until it has metastasized to such an extent that nothing can be done > about it. Which is why all v6 templates really need to get this in as a discard/filter/etc, just as we do with RFC-1918. I'm not saying it is perfect, but based on how much bogon lists have hurt legitimate traffic, we know the templates are at least used. Jack From bill at herrin.us Sat Oct 23 09:07:09 2010 From: bill at herrin.us (William Herrin) Date: Sat, 23 Oct 2010 10:07:09 -0400 Subject: =?windows-1252?Q?Re=3A_Why_ULA=3A_low_collision_chance_=28Was=3A_IPv6_fc00=3A=3A=2F?= =?windows-1252?Q?7_=97_Unique_local_addresses=29?= In-Reply-To: <4D073B8A-E29A-430E-8CA4-0FBE19D9A054@delong.com> References: <4CBF63BF.2000101@mompl.net> <4CC02841.3040407@unfix.org> <4CC0BE69.8050207@bogus.com> <4CC0C1E7.6010104@brightok.net> <4CC11F05.50109@bogus.com> <4D073B8A-E29A-430E-8CA4-0FBE19D9A054@delong.com> Message-ID: On Sat, Oct 23, 2010 at 3:07 AM, Owen DeLong wrote: >> On Oct 22, 2010, at 6:10 PM, William Herrin wrote: >> Just for grins, let's put some rough math to that assertion. The >> average percentage of the Internet reached by a ULA or RFC1918 leak >> will be close to: >> >> (1-A)^B >> >> A = the probability of any given organization filtering private >> address announcements and/or private address packets at their borders >> B = the average width of the Internet in organizations (which should >> be slightly higher than the width in ASes) > > I think your estimation of 50% is highly optimistic. I also think > you underestimate the diameter of the internet, being much > closer to 25 than 10 from what I can see. Filling in more > realistic (based on my observations) numbers of 5% and 25, > my numbers?come out as: > (1-0.05)^25 = 0.95 ^ 25 = 0.27 = a little more than 1/4 of the internet. Owen, I see. In trying to pick those numbers, my current (today) experience is this: I filter. Two of the three ISPs I interact with personally filter. My employer filters. Three of the five ISPs they deal with filter. Total: 7 of 10 filter. What experience of yours leads you to believe that something closer to 1 in 20 organizations choose to filter out RFC1918 and/or ULA at their borders? Do *you* filter border-crossing RFC1918 traffic? Does your employer, HE? > ULA won't supplant GUA, it will be much more insidious than that. Most > people will still use GUA for GUA purposes. > However, deliberate routing of ULA will start small and slowly spread > over time like a slow-growing cancer. You won't even really detect it > until it has metastasized to such an extent that nothing can be done > about it. > I believe that DELIBERATE routing of ULA will > be a very likely outcome of current policies eventually resulting in > ULA being ubiquitously routed just as GUA is intended to be. This > unfortunate end result of the combination of human nature to do > the expedient rather than the correct will eventually remove any > perceive benefits to ULA and cause additional problems as ULA > becomes a globally routable resource not subject to RIR policy. You need to back that up with something. This sort of thing doesn't just magically happen. Spin at least one scenario leading there in which the step-by-step choices by each of the participants are at least arguably rational. > In my opinion, the far more secure thing to do is to use GUA. > Put the hosts you want to be reachable from the outside in > specific ranges of your GUA. > For example: > Route filters: > From internal interfaces: > Accept 2620:0db8:532a::/56 or longer > Deny 2620:0db8:532a:: ge /48 le /55 Fat finger the second line (interpose the b and the d) and misconnect one ethernet cable so that your firewall interior protocol can touch your firewall exterior protocol. In comes a set of formerly interior routes ranging from /56 to /64, more specific routes that override your nulls. You're done. Your entire internal network is now firewall-free on the Internet. You've never typed in a line wrong in a router config or plugged a cable in to the wrong jack, right? And you've never tasked network setup work to a junior engineer whose networking sophistication is less than your own. BTW, in your opinionated security process you forgot to install RA guard. Without RA guard on every switch port that doesn't connect to an intentional router, some idiot user can plug a 4G modem into their laptop and every damn device sharing the network will assign itself an additional GUA address and route through him. Two IPv4 dhcp servers tended to conflict with each other so the result was an outage. IPv6's designers considered that a bug and made it go away so that there's a good chance you won't notice the breach. We have not yet begun to reach the depths of SLAAC's badness. Regards, Bill Herrin -- William D. Herrin ................ herrin at dirtside.com? bill at herrin.us 3005 Crane Dr. ...................... Web: Falls Church, VA 22042-3004 From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Sat Oct 23 09:26:29 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Sun, 24 Oct 2010 00:56:29 +1030 Subject: IPv6 fc00::/7 =?UTF-8?B?4oCU?= Unique local addresses In-Reply-To: <61A50C47-4D70-426E-949B-12678E792471@delong.com> References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101023034834.15fec97c@opy.nosense.org> <61A50C47-4D70-426E-949B-12678E792471@delong.com> Message-ID: <20101024005629.1b8ed49a@opy.nosense.org> On Fri, 22 Oct 2010 15:42:41 -0700 Owen DeLong wrote: > >>> > >> Actually, it's not pointless at all. The RA system assumes that all routers > >> capable of announcing RAs are default routers and that virtually all routers > >> are created equal (yes, you have high/medium/low, but, really, since you > >> have to use high for everything in any reasonable deployment...) > >> > > > > No it doesn't. You can set the router lifetime to zero, which indicates > > to the end-node that the RA isn't announcing a default router. In this > > case, it may be announcing M/O bit, prefix or other parameters. > > > DHCPv6 can selectively give different information to different hosts > on the same wire segment. > > RA cannot. > That was not the assertion you made. You said that "The RA system assumes that all routers > >> capable of announcing RAs are default routers" and I said, no, that is not the case if you set the RA lifetime to zero. To cite explicitly, RFC4861 says, Router Lifetime 16-bit unsigned integer. The lifetime associated with the default router in units of seconds. The field can contain values up to 65535 and receivers should handle any value, while the sending rules in Section 6 limit the lifetime to 9000 seconds. A Lifetime of 0 indicates that the router is not a default router and SHOULD NOT appear on the default Narten, et al. Standards Track [Page 20] ^L RFC 4861 Neighbor Discovery in IPv6 September 2007 router list. The Router Lifetime applies only to the router's usefulness as a default router; it does not apply to information contained in other message fields or options. Options that need time limits for their information include their own lifetime fields. I was not making any statements about whether DHCPv6 could be selective about providing certain options to selected end-nodes. You might think I'm being overlay pedantic, however changing the question to then disagree with answer that doesn't agree with yours is being disingenuous. > >> There are real environments where it's desirable to have a way to tell > >> different clients on a network to use different default gateways or > >> default gateway sets. > >> I wouldn't necessarily disagree, although in my experience they're really quite rare, to the point where segmenting them into a separate subnet, via e.g. a different VLAN, becomes a somewhat better and easier option. Regards, Mark. From owen at delong.com Sat Oct 23 09:45:23 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Oct 2010 07:45:23 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101024005629.1b8ed49a@opy.nosense.org> References: <4CBF63BF.2000101@mompl.net> <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101023034834.15fec97c@opy.nosense.org> <61A50C47-4D70-426E-949B-12678E792471@delong.com> <20101024005629.1b8ed49a@opy.nosense.org> Message-ID: On Oct 23, 2010, at 7:26 AM, Mark Smith wrote: > On Fri, 22 Oct 2010 15:42:41 -0700 > Owen DeLong wrote: > >>>>> >>>> Actually, it's not pointless at all. The RA system assumes that all routers >>>> capable of announcing RAs are default routers and that virtually all routers >>>> are created equal (yes, you have high/medium/low, but, really, since you >>>> have to use high for everything in any reasonable deployment...) >>>> >>> >>> No it doesn't. You can set the router lifetime to zero, which indicates >>> to the end-node that the RA isn't announcing a default router. In this >>> case, it may be announcing M/O bit, prefix or other parameters. >>> >> DHCPv6 can selectively give different information to different hosts >> on the same wire segment. >> >> RA cannot. >> > > That was not the assertion you made. > > You said that > > "The RA system assumes that all routers >>>> capable of announcing RAs are default routers" > > and I said, no, that is not the case if you set the RA lifetime to > zero. To cite explicitly, RFC4861 says, > Right... I oversimplified the point I was attempting to make and you called me on it... Move on. > Router Lifetime > 16-bit unsigned integer. The lifetime associated > with the default router in units of seconds. The > field can contain values up to 65535 and receivers > should handle any value, while the sending rules in > Section 6 limit the lifetime to 9000 seconds. A > Lifetime of 0 indicates that the router is not a > default router and SHOULD NOT appear on the default > > > > Narten, et al. Standards Track [Page 20] > ^L > RFC 4861 Neighbor Discovery in IPv6 September 2007 > > > router list. The Router Lifetime applies only to > the router's usefulness as a default router; it > does not apply to information contained in other > message fields or options. Options that need time > limits for their information include their own > lifetime fields. > > > I was not making any statements about whether DHCPv6 could be > selective about providing certain options to selected end-nodes. > > You might think I'm being overlay pedantic, however changing the > question to then disagree with answer that doesn't agree with yours is > being disingenuous. > >>>> There are real environments where it's desirable to have a way to tell >>>> different clients on a network to use different default gateways or >>>> default gateway sets. >>>> > > I wouldn't necessarily disagree, although in my experience they're > really quite rare, to the point where segmenting them into a separate > subnet, via e.g. a different VLAN, becomes a somewhat better and easier > option. > While I would agree with you operationally, sometimes they involve software that discovers other devices by broadcast and does not permit other mechanisms. I've seen environments where they're able to deal with this in IPv4 because of this flexibility in DHCPv4 and would be limited to static addressing in IPv6 because it lacks this ability. Owen From carlosm3011 at gmail.com Sat Oct 23 09:53:55 2010 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Sat, 23 Oct 2010 12:53:55 -0200 Subject: ipv6 vs. LAMP In-Reply-To: <4CC1DD7A.5040004@altzman.com> References: <1287694429.4968.96.camel@wednesday> <20101021214354.GA76784@ussenterprise.ufp.org> <20101021215259.GS2843@dan.olp.net> <4CC0B95A.8070003@bogus.com> <4CC1DD7A.5040004@altzman.com> Message-ID: Hi all, the replication point is a good one, I did not think about that. However, I still believe that on the road to v6 adoption, databases are far from being our most pressing roadblock. Thanks all! Carlos On Fri, Oct 22, 2010 at 4:52 PM, Jerry B. Altzman wrote: > Only to you. > on 10/22/2010 10:02 AM Carlos Martinez-Cagnazzo said the following: > > IMHO you should never, ever make your MySQL accesible over the public >> Internet, which renders the issue of MySQL not supporting IPv6 correctly >> mostly irrelevant. You could even run your MySQL behind your web backend >> using RFC1918 space (something I do recommend). >> > > Except for those of us who have to support applications based upon MySQL > replication...in that case, we use IP-based access rules on a firewall in > front, and on the host, and on the MySQL server itself. But we still need IP > access to it. > > We could shade it all by using IPSec or VPN tunnels, but that's more > administrative overhead, and MySQL replication is fragile enough without > adding that. > > > Moreover, if you need direct access to the engine, you can trivially >> create >> an SSH tunnel (You can even do this in a point-and-click way using the >> latest MySQL Workbench). SSH works over IPv6 just fine. >> > > See above about replication. > > Carlos >> > > //jbaltz > -- > jerry b. altzman jbaltz at altzman.com www.jbaltz.com > thank you for contributing to the heat death of the universe. > -- -- ========================= Carlos M. Martinez-Cagnazzo http://cagnazzo.name ========================= From pica8.org at gmail.com Sat Oct 23 10:01:35 2010 From: pica8.org at gmail.com (Lin Pica8) Date: Sat, 23 Oct 2010 17:01:35 +0200 Subject: nocproject.org Message-ID: Hello, For your information : http://www.nocproject.org NOC is an Operation Support System (OSS) for the Telco, Service provider and Enterprise Network Operation Centers (NOC). Written using Python language and utilizing the power of Django framework and PosgtreSQL database. NOC is open source and released under the terms of BSD LICENSE. Mail : pica8.org at gmail.com From carlosm3011 at gmail.com Sat Oct 23 10:03:55 2010 From: carlosm3011 at gmail.com (Carlos Martinez-Cagnazzo) Date: Sat, 23 Oct 2010 13:03:55 -0200 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <20101022133804.GA49113@ussenterprise.ufp.org> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101022133804.GA49113@ussenterprise.ufp.org> Message-ID: Amen! On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell wrote: > > There are some folks (like me) who advocate a DHCPv6 that can convey > a default gateway AND the ability to turn off RA's entirely. That > is make it work like IPv4. > > I'd also love to turn off stateless autoconfig altogether and not be coerced to assign /64s to single LANs, which I am becoming convinced that it was a poor decision on the IETFs part. Stateless autoconfig works very well, It would be just perfect if the network boundary was configurable (like say /64 if you really want it, or /80 - /96 for the rest of us) cheers Carlos -- -- ========================= Carlos M. Martinez-Cagnazzo http://cagnazzo.name ========================= From bzs at world.std.com Sat Oct 23 11:21:16 2010 From: bzs at world.std.com (Barry Shein) Date: Sat, 23 Oct 2010 12:21:16 -0400 Subject: IPv4 sunset date revised : 2009-02-05 In-Reply-To: <20101022180326.GB11762@vacation.karoshi.com.> References: <7E7ABAE4-700E-4C45-A45C-BB0EB39338D5@americafree.tv> <20101022033227.GA7557@vacation.karoshi.com.> <20101022034029.GB17822@skywalker.creative.net.au> <20101022034804.GC7557@vacation.karoshi.com.> <5A6D953473350C4B9995546AFE9939EE0B14C429@RWC-EX1.corp.seven.com> <19649.51640.224298.319039@world.std.com> <20101022180326.GB11762@vacation.karoshi.com.> Message-ID: <19651.2940.253220.527954@world.std.com> The idea was to observe and measure an (almost) all IPv4 network and its management/infrastructure costs, namely the one we got, not an IPv6 one, before the transition starts to muddy the waters significantly. -b On October 22, 2010 at 18:03 bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) wrote: > On Fri, Oct 22, 2010 at 01:28:24PM -0400, Barry Shein wrote: > > > > It occurs to me that there is some pressing need to investigate this > > all-IPv6 internet -- motivated by the cost of (not) maintaining IPv4 > > forever. > > > > Right now we can observe essentially an all-IPv4 internet (99%, > > whatever.) > > > > -- > > -Barry Shein > > > For this, you need to leave the comfort of NANOG and look > at the CERNnet network over the past ten years. They have > been running a large, all IPv6 network for some time now. > > > http://www.authorstream.com/Presentation/Cannes-19148-IPv6-development-China-Outline-Efforts-CERNET-History-Testbed-1-2-3-4-5-Next-Generation-Inter-in-as-Entertainment-ppt-powerpoint/ > > www.cs.princeton.edu/~yiwang/papers/iscc05.pdf > > http://www.cernet2.edu.cn/en/char.htm > > > --bill -- -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 nathan at atlasnetworks.us Sat Oct 23 14:42:00 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Sat, 23 Oct 2010 19:42:00 +0000 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101022133804.GA49113@ussenterprise.ufp.org> Message-ID: <8C26A4FDAE599041A13EB499117D3C284062E284@ex-mb-2.corp.atlasnetworks.us> > Stateless autoconfig works very well, It would be just perfect if the > network boundary was configurable (like say /64 if you really want it, > or > /80 - /96 for the rest of us) Why do you feel it's a poor decision to assign /64's to individual LANs? Best Regards, Nathan Eisenberg From owen at delong.com Sat Oct 23 19:23:14 2010 From: owen at delong.com (Owen DeLong) Date: Sat, 23 Oct 2010 17:23:14 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101022133804.GA49113@ussenterprise.ufp.org> Message-ID: <9F1872BB-F736-4914-B201-60671C821620@delong.com> On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote: > Amen! > > On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell wrote: > >> >> There are some folks (like me) who advocate a DHCPv6 that can convey >> a default gateway AND the ability to turn off RA's entirely. That >> is make it work like IPv4. >> >> > I'd also love to turn off stateless autoconfig altogether and not be coerced > to assign /64s to single LANs, which I am becoming convinced that it was a > poor decision on the IETFs part. > Nah... The /64 thing is fine. If they hadn't done that, we likely would have only a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are fine. What would be nice would be if we changed the semantics a bit and made it 16+48+64 where the first 16 of the dest+source could be re-assembled into the destination ASN for the packet and the remaining 48 identified a particular subnet globally with 64 for the host. Unfortunately, that ship has probably sailed. > Stateless autoconfig works very well, It would be just perfect if the > network boundary was configurable (like say /64 if you really want it, or > /80 - /96 for the rest of us) > There really is no need for anything smaller than /64. What, exactly, do you think you gain from a smaller netmask? Owen From gbonser at seven.com Sun Oct 24 02:27:49 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 24 Oct 2010 00:27:49 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <9F1872BB-F736-4914-B201-60671C821620@delong.com> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl><20101022182518.64924b44@opy.nosense.org><20101022133804.GA49113@ussenterprise.ufp.org> <9F1872BB-F736-4914-B201-60671C821620@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C47F@RWC-EX1.corp.seven.com> > > What would be nice would be if we changed the semantics a bit and made > it 16+48+64 where the first 16 of the dest+source could be re-assembled > into the destination ASN for the packet and the remaining 48 identified > a particular subnet globally with 64 for the host. Unfortunately, that > ship > has probably sailed. Well, since ASNs are now 32-bit, yeah. From gbonser at seven.com Sun Oct 24 05:05:47 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 24 Oct 2010 03:05:47 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <9F1872BB-F736-4914-B201-60671C821620@delong.com> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl><20101022182518.64924b44@opy.nosense.org><20101022133804.GA49113@ussenterprise.ufp.org> <9F1872BB-F736-4914-B201-60671C821620@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C481@RWC-EX1.corp.seven.com> > > What would be nice would be if we changed the semantics a bit and made > it 16+48+64 where the first 16 of the dest+source could be re-assembled > into the destination ASN for the packet and the remaining 48 identified > a particular subnet globally with 64 for the host. Unfortunately, that > ship > has probably sailed. On the other hand, it probably would have been easier (and more widely adopted already) to simply go to an "internet of internets" model where you break the planet up into 32-bit regions, each with their own 32-bit "internets" and just use what amounts to IPIP tunneling between them and enlarge the standard MTU from 1500 to accommodate that without further packet fragmentation. And speaking of changing MTU, is there any reason why private exchanges shouldn't support jumbo frames? Is there any reason nowadays that things that are ethernet end to end can't be MTU 9000 instead of 1500? It certainly would improve performance and reduce the packets/sec and increase performance on latent links. Why are we still using 1500 MTU when peering? Is there any gear at peering points that DOESN'T support jumbo frames these days? From bicknell at ufp.org Sun Oct 24 08:48:57 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 24 Oct 2010 06:48:57 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <9F1872BB-F736-4914-B201-60671C821620@delong.com> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101022133804.GA49113@ussenterprise.ufp.org> <9F1872BB-F736-4914-B201-60671C821620@delong.com> Message-ID: <20101024134857.GA41659@ussenterprise.ufp.org> In a message written on Sat, Oct 23, 2010 at 05:23:14PM -0700, Owen DeLong wrote: > On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote: > > On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell wrote: > >> There are some folks (like me) who advocate a DHCPv6 that can convey > >> a default gateway AND the ability to turn off RA's entirely. That > >> is make it work like IPv4. > >> > > I'd also love to turn off stateless autoconfig altogether and not be coerced > > to assign /64s to single LANs, which I am becoming convinced that it was a > > poor decision on the IETFs part. > > > Nah... The /64 thing is fine. If they hadn't done that, we likely would have only > a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are > fine. I think the 64-bit boundry is fine (from a DHCP perspective). I do think if we're going to update the DHCP spec it should support a netmask option, just because leaving it out is short sighted to the future, but I would use it with /64's today. > There really is no need for anything smaller than /64. What, exactly, do you > think you gain from a smaller netmask? There is a slippery slope here, if users make do with smaller providers may give out smaller blocks, and so on. That said, if a provider does hand out a /64, I would very much like technology to make 16 bits of subnet + 48 bits of host, with EUI-48 used directly for autoconf as an option. Particularly when we talk about 6rd and other things that use a lot of space this option would be huge. Users would still get 16 bits of subnet, and host space so big they could never fill 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 owen at delong.com Sun Oct 24 09:04:42 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 24 Oct 2010 07:04:42 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <20101024134857.GA41659@ussenterprise.ufp.org> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl> <20101022182518.64924b44@opy.nosense.org> <20101022133804.GA49113@ussenterprise.ufp.org> <9F1872BB-F736-4914-B201-60671C821620@delong.com> <20101024134857.GA41659@ussenterprise.ufp.org> Message-ID: <6CAE2E7F-A17B-4B5E-8551-DD05B3C3D94D@delong.com> On Oct 24, 2010, at 6:48 AM, Leo Bicknell wrote: > In a message written on Sat, Oct 23, 2010 at 05:23:14PM -0700, Owen DeLong wrote: >> On Oct 23, 2010, at 8:03 AM, Carlos Martinez-Cagnazzo wrote: >>> On Fri, Oct 22, 2010 at 11:38 AM, Leo Bicknell wrote: >>>> There are some folks (like me) who advocate a DHCPv6 that can convey >>>> a default gateway AND the ability to turn off RA's entirely. That >>>> is make it work like IPv4. >>>> >>> I'd also love to turn off stateless autoconfig altogether and not be coerced >>> to assign /64s to single LANs, which I am becoming convinced that it was a >>> poor decision on the IETFs part. >>> >> Nah... The /64 thing is fine. If they hadn't done that, we likely would have only >> a 64-bit address space total. 64-bit lans with 64-bit routing identifiers are >> fine. > > I think the 64-bit boundry is fine (from a DHCP perspective). I > do think if we're going to update the DHCP spec it should support > a netmask option, just because leaving it out is short sighted to > the future, but I would use it with /64's today. > My understanding was DHCPv6 did support prefixes other than /64. >> There really is no need for anything smaller than /64. What, exactly, do you >> think you gain from a smaller netmask? > > There is a slippery slope here, if users make do with smaller > providers may give out smaller blocks, and so on. > Yeah, that could be worse than neutral. Still there's no gain to smaller than /64, only loss... > That said, if a provider does hand out a /64, I would very much > like technology to make 16 bits of subnet + 48 bits of host, with > EUI-48 used directly for autoconf as an option. Particularly when > we talk about 6rd and other things that use a lot of space this > option would be huge. Users would still get 16 bits of subnet, and > host space so big they could never fill it. > I think that ship has pretty well sailed, but, it might be a good future workaround if providers start doing stupid pet tricks like assigning single /64s to end customers. Owen From brandon.kim at brandontek.com Sun Oct 24 10:34:12 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 24 Oct 2010 11:34:12 -0400 Subject: NTP Server Message-ID: Hey guys: I wanted to open up this question regarding NTP server. I recalled someone had created a posting of this quite awhile back. >From a service provider/ISP standpoint, does anyone think that having a local NTP server is really necessary? I've asked some of my fellow engineers at work and many of them gives me the same response, "Can't we just use free ones out on the internet?" 1) How necessary do you believe in local NTP servers? Do you really need the logs to be perfectly accurate? 2) If you do have a local NTP server, is it only for local internal use, or do you provide this NTP server to your clients as an added service? 3) If you do have a local NTP server, do you have a standby local NTP server or do you use the internet as your standby server? Thoughts? Thanks in advance, and this list is such a valuable wealth of resource.... Brandon From brandon.kim at brandontek.com Sun Oct 24 10:34:12 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 24 Oct 2010 11:34:12 -0400 Subject: NTP Server Message-ID: Hey guys: I wanted to open up this question regarding NTP server. I recalled someone had created a posting of this quite awhile back. >From a service provider/ISP standpoint, does anyone think that having a local NTP server is really necessary? I've asked some of my fellow engineers at work and many of them gives me the same response, "Can't we just use free ones out on the internet?" 1) How necessary do you believe in local NTP servers? Do you really need the logs to be perfectly accurate? 2) If you do have a local NTP server, is it only for local internal use, or do you provide this NTP server to your clients as an added service? 3) If you do have a local NTP server, do you have a standby local NTP server or do you use the internet as your standby server? Thoughts? Thanks in advance, and this list is such a valuable wealth of resource.... Brandon From roll at Stupi.SE Sun Oct 24 17:44:05 2010 From: roll at Stupi.SE (Peter Lothberg) Date: Sun, 24 Oct 2010 17:44:05 CEST Subject: NTP Server In-Reply-To: Message-ID: > 1) How necessary do you believe in local NTP servers? Do you really need th= > e logs to be perfectly accurate? > 2) If you do have a local NTP server=2C is it only for local internal use= > =2C or do you provide this NTP server to your clients as an added service? > 3) If you do have a local NTP server=2C do you have a standby local NTP ser= > ver or do you use the internet as your standby server? > Thoughts? How do you knew that your local NTP server knew what time it is? (for sure) -P From ben at adversary.org Sun Oct 24 10:51:24 2010 From: ben at adversary.org (Ben McGinnes) Date: Mon, 25 Oct 2010 02:51:24 +1100 Subject: NTP Server In-Reply-To: References: Message-ID: <4CC455FC.4010601@adversary.org> On 24/10/10 5:44 PM, Peter Lothberg wrote: > > How do you knew that your local NTP server knew what time it is? (for sure) By polling as many stratum 1 and 2 time servers as possible. Having your own stratum 2 server(s) beats nebulous NTP servers out in the big bad Internet every time. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From eugen at leitl.org Sun Oct 24 10:55:22 2010 From: eugen at leitl.org (Eugen Leitl) Date: Sun, 24 Oct 2010 17:55:22 +0200 Subject: NTP Server In-Reply-To: <4CC455FC.4010601@adversary.org> References: <4CC455FC.4010601@adversary.org> Message-ID: <20101024155522.GT28998@leitl.org> On Mon, Oct 25, 2010 at 02:51:24AM +1100, Ben McGinnes wrote: > > How do you knew that your local NTP server knew what time it is? (for sure) > > By polling as many stratum 1 and 2 time servers as possible. Having > your own stratum 2 server(s) beats nebulous NTP servers out in the big > bad Internet every time. For those you care about that: http://leapsecond.com/time-nuts.htm From jbates at brightok.net Sun Oct 24 11:09:28 2010 From: jbates at brightok.net (Jack Bates) Date: Sun, 24 Oct 2010 11:09:28 -0500 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C481@RWC-EX1.corp.seven.com> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl><20101022182518.64924b44@opy.nosense.org><20101022133804.GA49113@ussenterprise.ufp.org> <9F1872BB-F736-4914-B201-60671C821620@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C481@RWC-EX1.corp.seven.com> Message-ID: <4CC45A38.8080201@brightok.net> On 10/24/2010 5:05 AM, George Bonser wrote: > > And speaking of changing MTU, is there any reason why private exchanges > shouldn't support jumbo frames? Is there any reason nowadays that things > that are ethernet end to end can't be MTU 9000 instead of 1500? It > certainly would improve performance and reduce the packets/sec and > increase performance on latent links. Why are we still using 1500 MTU > when peering? Is there any gear at peering points that DOESN'T support > jumbo frames these days? > > Probably no reason at all, though probably little perceived benefit. 1492 is common enough that google/youtube already runs lower MTU's just to avoid common broken PPPoE setups (which often could run higher MTU, but weren't configured that way). Not uncommon for cell companies to request 1600 MTU or more for their layer 2 transport, which one vendor had to custom patch 1648 into their gear to even support that much. Of course, it will be lowered by a variety of tags/tunnels/etc by the time it gets to the cell phone. It cracks me up that SONET interfaces default 4470, and ethernet still defaults to 1500. I've yet to see an MTU option in standard circuit setup forms, which would indicate to me that asking for a higher MTU might get me one extra link before dropping back to 1500ish. Jack From ben at adversary.org Sun Oct 24 11:13:27 2010 From: ben at adversary.org (Ben McGinnes) Date: Mon, 25 Oct 2010 03:13:27 +1100 Subject: NTP Server In-Reply-To: <20101024155522.GT28998@leitl.org> References: <4CC455FC.4010601@adversary.org> <20101024155522.GT28998@leitl.org> Message-ID: <4CC45B27.9020200@adversary.org> On 25/10/10 2:55 AM, Eugen Leitl wrote: > > For those you care about that: > > http://leapsecond.com/time-nuts.htm Wow ... that's a lot more effort than I'm willing to put in on a time server. Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From brandon.kim at brandontek.com Sun Oct 24 11:26:52 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 24 Oct 2010 12:26:52 -0400 Subject: NTP Server In-Reply-To: <156884471-1287935530-cardhu_decombobulator_blackberry.rim.net-1141047724-@bda588.bisx.prod.on.blackberry> References: <156884471-1287935530-cardhu_decombobulator_blackberry.rim.net-1141047724-@bda588.bisx.prod.on.blackberry> Message-ID: Wow that is amazing and quite impressive that you even run the antenna lines....interesting......do you have to pay for the GPS service? > Subject: Re: NTP Server > To: brandon.kim at brandontek.com > From: jkrejci at usinternet.com > Date: Sun, 24 Oct 2010 15:52:03 +0000 > > Internet ntp is not as reliable as local ntp due to either reachability or tampering. We run a pair of GPS ntp servers with antennas ran to the roof of the building. We make them available to our customers as well as for our own use. > > > ------Original Message------ > From: Brandon Kim > To: nanog at nanog.org > Subject: NTP Server > Sent: Oct 24, 2010 10:34 AM > > > Hey guys: > > I wanted to open up this question regarding NTP server. I recalled someone had created a posting of this quite awhile back. > >From a service provider/ISP standpoint, does anyone think that having a local NTP server is really necessary? > > I've asked some of my fellow engineers at work and many of them gives me the same response, "Can't we just use free ones out on the internet?" > > 1) How necessary do you believe in local NTP servers? Do you really need the logs to be perfectly accurate? > 2) If you do have a local NTP server, is it only for local internal use, or do you provide this NTP server to your clients as an added service? > 3) If you do have a local NTP server, do you have a standby local NTP server or do you use the internet as your standby server? > > > Thoughts? > > Thanks in advance, and this list is such a valuable wealth of resource.... > > Brandon > > > > > > > Sent via BlackBerry from T-Mobile From brandon.kim at brandontek.com Sun Oct 24 11:29:05 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 24 Oct 2010 12:29:05 -0400 Subject: NTP Server In-Reply-To: <20101024155522.GT28998@leitl.org> References: , <4CC455FC.4010601@adversary.org>, <20101024155522.GT28998@leitl.org> Message-ID: I guess what I'm trying to understand is, is having your own NTP server just a luxury? I personally would like to have my own, I just need to pitch its advantages to my company. Unless everyone here on the NANOG group clearly spells it out to me that it's a luxury. I can see it as an added service/benefit though to our customers..... > Date: Sun, 24 Oct 2010 17:55:22 +0200 > From: eugen at leitl.org > To: nanog at nanog.org > Subject: Re: NTP Server > > On Mon, Oct 25, 2010 at 02:51:24AM +1100, Ben McGinnes wrote: > > > > How do you knew that your local NTP server knew what time it is? (for sure) > > > > By polling as many stratum 1 and 2 time servers as possible. Having > > your own stratum 2 server(s) beats nebulous NTP servers out in the big > > bad Internet every time. > > For those you care about that: > > http://leapsecond.com/time-nuts.htm > From sethm at rollernet.us Sun Oct 24 11:49:31 2010 From: sethm at rollernet.us (Seth Mattinen) Date: Sun, 24 Oct 2010 09:49:31 -0700 Subject: NTP Server In-Reply-To: References: <156884471-1287935530-cardhu_decombobulator_blackberry.rim.net-1141047724-@bda588.bisx.prod.on.blackberry> Message-ID: <4CC4639B.4090608@rollernet.us> On 10/24/2010 09:26, Brandon Kim wrote: > > Wow that is amazing and quite impressive that you even run the antenna lines....interesting......do you have to pay for the GPS service? > Make your own simple GPS NTP clock source: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm ~Seth From bruns at 2mbit.com Sun Oct 24 12:03:18 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Sun, 24 Oct 2010 11:03:18 -0600 Subject: NTP Server In-Reply-To: References: Message-ID: <4CC466D6.5020701@2mbit.com> On 10/24/10 9:34 AM, Brandon Kim wrote: > I wanted to open up this question regarding NTP server. I recalled > someone had created a posting of this quite awhile back. >> From a service provider/ISP standpoint, does anyone think that >> having a local NTP server is really necessary? > It may not be necessary, but it certainly is not a bad thing. Not having to depend on third parties for a service is a good thing. > I've asked some of my fellow engineers at work and many of them gives > me the same response, "Can't we just use free ones out on the > internet?" > > 1) How necessary do you believe in local NTP servers? Do you really > need the logs to be perfectly accurate? Perfectly accurate is very helpful when trying to associate several incidents going on at the same time or when trying to figure out the timeline leading up to why a machine had a kernel panic, for example. > 2) If you do have a local NTP > server, is it only for local internal use, or do you provide this NTP > server to your clients as an added service? Our master stratum 1 GPS clock only has ipv6 access to the outside world. Our two 'public' ntp servers can talk directly to it over ipv4 or ipv6, and those are are publicly available via ipv4 or ipv6. > 3) If you do have a local > NTP server, do you have a standby local NTP server or do you use the > internet as your standby server? If the stratum 1 becomes unavailable (its 500 miles away on a different network), the two public NTP servers are peered with one another, and both have a different outside third-party NTP server to sync with (may it be an upstream provider's ntp server, or one of the pool ones from ntp.org). Never had a problem with this setup, and its worked rather well. -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From bicknell at ufp.org Sun Oct 24 12:07:51 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 24 Oct 2010 10:07:51 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <4CC45A38.8080201@brightok.net> References: <9F1872BB-F736-4914-B201-60671C821620@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C481@RWC-EX1.corp.seven.com> <4CC45A38.8080201@brightok.net> Message-ID: <20101024170751.GA56348@ussenterprise.ufp.org> In a message written on Sun, Oct 24, 2010 at 11:09:28AM -0500, Jack Bates wrote: > variety of tags/tunnels/etc by the time it gets to the cell phone. It > cracks me up that SONET interfaces default 4470, and ethernet still > defaults to 1500. I've yet to see an MTU option in standard circuit > setup forms, which would indicate to me that asking for a higher MTU > might get me one extra link before dropping back to 1500ish. I've had pretty good luck asking for higher MTU's on both customer and peering links. I'd say about an 80% success rate for dedicated GigE's. It's generally not on the forms though, and sometimes you get what I consider weird responses. For instance I know several providers who won't going higher than 4470 on ethernet. If more folks asked for higher MTUs it might become part of the standard forms... -- 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 randy at psg.com Sun Oct 24 12:09:25 2010 From: randy at psg.com (Randy Bush) Date: Sun, 24 Oct 2010 10:09:25 -0700 Subject: NTP Server In-Reply-To: References: Message-ID: > 1) How necessary do you believe in local NTP servers? Do you really > need the logs to be perfectly accurate? what is "perfectly accurate?" perfection is not very realistic. to what use do you put these logs? what precision and jitter are required for that use? imiho, if you are just comparing router and server log files, run off public. if you are trying to do fine-grained measurement, you are going to invest a lot in clock and propagation research. > 2) If you do have a local NTP server, is it only for local internal > use, or do you provide this NTP server to your clients as an added > service? i would generally let customers chime off routers which are strat 2 or 3. if a customer has other needs, then they can deal. if they are really concerned, they should not bet on me anyway. > 3) If you do have a local NTP server, do you have a standby local NTP > server or do you use the internet as your standby server? again, depends on your needs. randy From james.cutler at consultant.com Sun Oct 24 12:12:40 2010 From: james.cutler at consultant.com (Cutler James R) Date: Sun, 24 Oct 2010 13:12:40 -0400 Subject: NTP Server In-Reply-To: References: , <4CC455FC.4010601@adversary.org>, <20101024155522.GT28998@leitl.org> Message-ID: <982B535E-4038-47A2-8A7A-F72105FE3C0B@consultant.com> Time Service is more complicated than just having a single NTP server. But it can be useful and is not really a luxury. Two primary reasons for local time service are to reliably serve a network that is relatively or completely isolated from the general internet, and, to provide a local time source for "dumb" clients that is closer (less jitter) in network terms. Other reasons can include policy (everything in the network uses the same identical time service), policy (the time service is locally controlled), operational simplicity (the routers don't need to run NTP), and, separation of functions/operational responsibility (your run your servers, they run the backbone, I tell you the time. Implementing a local time service is actually fairly simple, but fewer than four servers is wasted effort. I can't explain in just a few words how the servers interact and compute delays and jitter to come to an "accurate" time. Take my word or ask David Mills for all that. Implementation of an internet-referenced time service involves the following: 1. Select a set of stratum one servers - pick open access servers or get permission to use limited access servers. Four to six should do. 2. Select a set local hosts on your network - DNS servers, for example. These should be well distributed. Four to six should do. The actual NTP load is small compared to DNS queries. 3. Configure the local hosts as peers using the stratum one set as servers. Use crypto authentication if you feel the need. 4. Add NTP monitoring to your network management process. 5. Advertise the local time servers to your network - DHCP, word of mouth, configuration requirements, configuration scripts, standard builds, etc. It is simple enough to do for a five node home network. It is almost that simple for a network with hundreds of thousands of client nodes. I've done both. On Oct 24, 2010, at 12:29 PM, Brandon Kim wrote: > > I guess what I'm trying to understand is, is having your own NTP server just a luxury? > > I personally would like to have my own, I just need to pitch its advantages to my company. Unless everyone here on the NANOG group > clearly spells it out to me that it's a luxury. > > I can see it as an added service/benefit though to our customers..... > > > >> Date: Sun, 24 Oct 2010 17:55:22 +0200 >> From: eugen at leitl.org >> To: nanog at nanog.org >> Subject: Re: NTP Server >> >> On Mon, Oct 25, 2010 at 02:51:24AM +1100, Ben McGinnes wrote: >> >>>> How do you knew that your local NTP server knew what time it is? (for sure) >>> >>> By polling as many stratum 1 and 2 time servers as possible. Having >>> your own stratum 2 server(s) beats nebulous NTP servers out in the big >>> bad Internet every time. >> >> For those you care about that: >> >> http://leapsecond.com/time-nuts.htm >> > = James R. Cutler james.cutler at consultant.com From jack at crepinc.com Sun Oct 24 12:14:05 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Sun, 24 Oct 2010 13:14:05 -0400 Subject: NTP Server In-Reply-To: References: Message-ID: More than likely, it's more important that all your machines are synced accurately in time to each other, vs. a wider sync range that's statistically closer to the 'real' value. -Jack Carrozzo On Sun, Oct 24, 2010 at 1:09 PM, Randy Bush wrote: > > 1) How necessary do you believe in local NTP servers? Do you really > > need the logs to be perfectly accurate? > > what is "perfectly accurate?" perfection is not very realistic. to > what use do you put these logs? what precision and jitter are required > for that use? > > imiho, if you are just comparing router and server log files, run off > public. if you are trying to do fine-grained measurement, you are going > to invest a lot in clock and propagation research. > > > 2) If you do have a local NTP server, is it only for local internal > > use, or do you provide this NTP server to your clients as an added > > service? > > i would generally let customers chime off routers which are strat 2 or > 3. if a customer has other needs, then they can deal. if they are > really concerned, they should not bet on me anyway. > > > 3) If you do have a local NTP server, do you have a standby local NTP > > server or do you use the internet as your standby server? > > again, depends on your needs. > > randy > > From morrowc.lists at gmail.com Sun Oct 24 12:20:20 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 24 Oct 2010 13:20:20 -0400 Subject: NTP Server In-Reply-To: References: Message-ID: On Sun, Oct 24, 2010 at 10:44 AM, Peter Lothberg wrote: >> 1) How necessary do you believe in local NTP servers? Do you really need th= >> e logs to be perfectly accurate? >> 2) If you do have a local NTP server=2C is it only for local internal use= >> =2C or do you provide this NTP server to your clients as an added service? >> 3) If you do have a local NTP server=2C do you have a standby local NTP ser= >> ver or do you use the internet as your standby server? >> Thoughts? > > How do you knew that your local NTP server knew what time it is? ?(for sure) this question is a trap. From bicknell at ufp.org Sun Oct 24 12:20:22 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 24 Oct 2010 10:20:22 -0700 Subject: NTP Server In-Reply-To: References: Message-ID: <20101024172022.GA56786@ussenterprise.ufp.org> In a message written on Sun, Oct 24, 2010 at 11:34:12AM -0400, Brandon Kim wrote: >From a service provider/ISP standpoint, does anyone think that having a local NTP server is really necessary? Do you provide NTP to your customers? If you do there is probably an obligation there to make a reasonable effort to have accurate times. I'm not sure relying on random servers across the internet rises to that standard. I think you should have at least four clocks getting time not from the internet to compare. For instance, for a couple of thousand dollars you can get a Symmetricom appliance that will do GPS timing with analog dial backup to NIST. That gives you two non-internet sources at relatively low cost and low effort. Deploy four in different POP's and you have redundancy on your own network, and can market that you provide high quality NTP to your customers. It's nearly fire and forget, and a check for alarms from the box and make sure you watch for patches, that's about it. If you don't offer NTP to your customers whatever you need for your own internal logging is fine. Generally as long as they all sync to the same set of servers they will be accurate to each other, so you can compare times across servers. Set up 4 NTP servers, let them sync to the outside world, let all of your internal boxes sync to them. Notice in both cases I said deploy 4. If you understand the protocol, and in particular the decision process that really is the minimum number to have high quality NTP. Syncing everything to one or two NTP servers really doesn't work so 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 bclark at spectraaccess.com Sun Oct 24 12:21:32 2010 From: bclark at spectraaccess.com (Bret Clark) Date: Sun, 24 Oct 2010 13:21:32 -0400 Subject: NTP Server In-Reply-To: References: , <4CC455FC.4010601@adversary.org>, <20101024155522.GT28998@leitl.org> Message-ID: <4CC46B1C.7010000@spectraaccess.com> On 10/24/2010 12:29 PM, Brandon Kim wrote: > I guess what I'm trying to understand is, is having your own NTP server just a luxury? > > I personally would like to have my own, I just need to pitch its advantages to my company. Unless everyone here on the NANOG group > clearly spells it out to me that it's a luxury. > > I can see it as an added service/benefit though to our customers..... > > > We have one internally because we use private IP'S on some of our own equipment for security reasons and those systems are unable to poll an external NTP server on the Internet. Plus some of our equipment only accepts a single NTP server and in the past we occasionally found external NTP servers to not be up, at least with our own server we know if it's accessible or not. As for pitching one to your company, not sure why that's an issue...talking about 500K app that can run on $50 pc with Linux from ebay Bret From sfischer1967 at gmail.com Sun Oct 24 12:23:29 2010 From: sfischer1967 at gmail.com (Steven Fischer) Date: Sun, 24 Oct 2010 13:23:29 -0400 Subject: NTP Server In-Reply-To: <982B535E-4038-47A2-8A7A-F72105FE3C0B@consultant.com> References: <4CC455FC.4010601@adversary.org> <20101024155522.GT28998@leitl.org> <982B535E-4038-47A2-8A7A-F72105FE3C0B@consultant.com> Message-ID: James -- Well said. I was going to submit the exact same thing. This is what we we do at my company and it works extremely well - we only use three stratum-1 time servers, and three internal servers to go get the time from the three externals, via a one-to-one correspondence. Once all three internals have acquired the time from the three stratum-1 clocks, they all poll each other for the average. every host in the network is pointed to one of the three internals. On Sun, Oct 24, 2010 at 1:12 PM, Cutler James R wrote: > Time Service is more complicated than just having a single NTP server. But > it can be useful and is not really a luxury. > > Two primary reasons for local time service are to reliably serve a network > that is relatively or completely isolated from the general internet, and, to > provide a local time source for "dumb" clients that is closer (less jitter) > in network terms. Other reasons can include policy (everything in the > network uses the same identical time service), policy (the time service is > locally controlled), operational simplicity (the routers don't need to run > NTP), and, separation of functions/operational responsibility (your run your > servers, they run the backbone, I tell you the time. > > Implementing a local time service is actually fairly simple, but fewer than > four servers is wasted effort. I can't explain in just a few words how the > servers interact and compute delays and jitter to come to an "accurate" > time. Take my word or ask David Mills for all that. > > Implementation of an internet-referenced time service involves the > following: > 1. Select a set of stratum one servers - pick open access servers or get > permission to use limited access servers. Four to six should do. > 2. Select a set local hosts on your network - DNS servers, for example. > These should be well distributed. Four to six should do. The actual NTP load > is small compared to DNS queries. > 3. Configure the local hosts as peers using the stratum one set as servers. > Use crypto authentication if you feel the need. > 4. Add NTP monitoring to your network management process. > 5. Advertise the local time servers to your network - DHCP, word of mouth, > configuration requirements, configuration scripts, standard builds, etc. > > It is simple enough to do for a five node home network. It is almost that > simple for a network with hundreds of thousands of client nodes. I've done > both. > > > On Oct 24, 2010, at 12:29 PM, Brandon Kim wrote: > > > > > I guess what I'm trying to understand is, is having your own NTP server > just a luxury? > > > > I personally would like to have my own, I just need to pitch its > advantages to my company. Unless everyone here on the NANOG group > > clearly spells it out to me that it's a luxury. > > > > I can see it as an added service/benefit though to our customers..... > > > > > > > >> Date: Sun, 24 Oct 2010 17:55:22 +0200 > >> From: eugen at leitl.org > >> To: nanog at nanog.org > >> Subject: Re: NTP Server > >> > >> On Mon, Oct 25, 2010 at 02:51:24AM +1100, Ben McGinnes wrote: > >> > >>>> How do you knew that your local NTP server knew what time it is? (for > sure) > >>> > >>> By polling as many stratum 1 and 2 time servers as possible. Having > >>> your own stratum 2 server(s) beats nebulous NTP servers out in the big > >>> bad Internet every time. > >> > >> For those you care about that: > >> > >> http://leapsecond.com/time-nuts.htm > >> > > = > > James R. Cutler > james.cutler at consultant.com > > > > > > -- To him who is able to keep you from falling and to present you before his glorious presence without fault and with great joy From joelja at bogus.com Sun Oct 24 12:24:59 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 24 Oct 2010 10:24:59 -0700 Subject: NTP Server In-Reply-To: References: Message-ID: <4CC46BEB.9040400@bogus.com> On 10/24/10 10:20 AM, Christopher Morrow wrote: > On Sun, Oct 24, 2010 at 10:44 AM, Peter Lothberg wrote: >>> 1) How necessary do you believe in local NTP servers? Do you really need th= >>> e logs to be perfectly accurate? >>> 2) If you do have a local NTP server=2C is it only for local internal use= >>> =2C or do you provide this NTP server to your clients as an added service? >>> 3) If you do have a local NTP server=2C do you have a standby local NTP ser= >>> ver or do you use the internet as your standby server? >>> Thoughts? >> >> How do you knew that your local NTP server knew what time it is? (for sure) > > this question is a trap. a man with one watch knows what time it is, a man with two is never sure. > From jtk at cymru.com Sun Oct 24 12:25:18 2010 From: jtk at cymru.com (John Kristoff) Date: Sun, 24 Oct 2010 12:25:18 -0500 Subject: NTP Server In-Reply-To: References: Message-ID: <20101024122518.59950ee5@t61p> On Sun, 24 Oct 2010 11:34:12 -0400 Brandon Kim wrote: > I wanted to open up this question regarding NTP server. I recalled > someone had created a posting of this quite awhile back. > >From a service provider/ISP standpoint, does anyone think that > >having a local NTP server is really necessary? It's not strictly necessary, but I think any serious and reasonably-sized ISP should probably have their own set of time sources. This thread might be useful to review for some suggestions, but in particular Michael's comments are relevant: > 1) How necessary do you believe in local NTP servers? Do you really > need the logs to be perfectly accurate? 2) If you do have a local NTP > server, is it only for local internal use, or do you provide this NTP > server to your clients as an added service? 3) If you do have a local > NTP server, do you have a standby local NTP server or do you use the > internet as your standby server? The "perfect accuracy" of log files might be hard to justify and quantify. I'd say it's more about having your own trustworthy and reliable source that you can ensure is operational, reachable and correct. That said, it is perfectly fine and probably useful to use external sources in addition to your own for backup and time redundancy in your design. You probably don't need to provide time to your customers unless you have a good reason to do so or they've been asking, which I'd find surprising these days for new installations. The default Microsoft time service and the pool.ntp.org servers probably work fine for the majority of end users. We have some NTP configuration templates here if it helps any: John From morrowc.lists at gmail.com Sun Oct 24 12:28:41 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 24 Oct 2010 13:28:41 -0400 Subject: NTP Server In-Reply-To: <4CC46BEB.9040400@bogus.com> References: <4CC46BEB.9040400@bogus.com> Message-ID: On Sun, Oct 24, 2010 at 1:24 PM, Joel Jaeggli wrote: > On 10/24/10 10:20 AM, Christopher Morrow wrote: >> On Sun, Oct 24, 2010 at 10:44 AM, Peter Lothberg wrote: >>> How do you knew that your local NTP server knew what time it is? ?(for sure) >> >> this question is a trap. > > a man with one watch knows what time it is, a man with two is never sure. how about a man with 7? From joelja at bogus.com Sun Oct 24 12:37:29 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 24 Oct 2010 10:37:29 -0700 Subject: NTP Server In-Reply-To: <20101024122518.59950ee5@t61p> References: <20101024122518.59950ee5@t61p> Message-ID: <4CC46ED9.8060300@bogus.com> On 10/24/10 10:25 AM, John Kristoff wrote: > The "perfect accuracy" of log files might be hard to justify and > quantify. more to the point what's the minimum resolution of a counter in a log file, if it's 1s or 1ms it's a bit different than if it's 1us. From roll at Stupi.SE Sun Oct 24 19:37:41 2010 From: roll at Stupi.SE (Peter Lothberg) Date: Sun, 24 Oct 2010 19:37:41 CEST Subject: NTP Server In-Reply-To: Message-ID: > acquired the time from the three stratum-1 clocks, they all poll each other > for the average. How many clocks/servers do you need to average from to knew that you are within say 1ms of UTC(nist)? -P From brandon.kim at brandontek.com Sun Oct 24 12:38:51 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 24 Oct 2010 13:38:51 -0400 Subject: NTP Server In-Reply-To: References: , Message-ID: Just for log purposes and possibly providing it to our clients as an added service at no charge of course. I don't see us needing to get very granular in the details of the times on the logs.... > Date: Sun, 24 Oct 2010 10:09:25 -0700 > From: randy at psg.com > To: brandon.kim at brandontek.com > CC: nanog at nanog.org > Subject: Re: NTP Server > > > 1) How necessary do you believe in local NTP servers? Do you really > > need the logs to be perfectly accurate? > > what is "perfectly accurate?" perfection is not very realistic. to > what use do you put these logs? what precision and jitter are required > for that use? > > imiho, if you are just comparing router and server log files, run off > public. if you are trying to do fine-grained measurement, you are going > to invest a lot in clock and propagation research. > > > 2) If you do have a local NTP server, is it only for local internal > > use, or do you provide this NTP server to your clients as an added > > service? > > i would generally let customers chime off routers which are strat 2 or > 3. if a customer has other needs, then they can deal. if they are > really concerned, they should not bet on me anyway. > > > 3) If you do have a local NTP server, do you have a standby local NTP > > server or do you use the internet as your standby server? > > again, depends on your needs. > > randy From brandon.kim at brandontek.com Sun Oct 24 12:41:06 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 24 Oct 2010 13:41:06 -0400 Subject: NTP Server In-Reply-To: <4CC466D6.5020701@2mbit.com> References: , <4CC466D6.5020701@2mbit.com> Message-ID: Looks like you have a pretty good setup. What vendor equipment are you using? You can let me know offline so it doesn't sound like you're advertising them.... > Date: Sun, 24 Oct 2010 11:03:18 -0600 > From: bruns at 2mbit.com > To: nanog at nanog.org > Subject: Re: NTP Server > > On 10/24/10 9:34 AM, Brandon Kim wrote: > > I wanted to open up this question regarding NTP server. I recalled > > someone had created a posting of this quite awhile back. > >> From a service provider/ISP standpoint, does anyone think that > >> having a local NTP server is really necessary? > > > > It may not be necessary, but it certainly is not a bad thing. Not > having to depend on third parties for a service is a good thing. > > > > I've asked some of my fellow engineers at work and many of them gives > > me the same response, "Can't we just use free ones out on the > > internet?" > > > > 1) How necessary do you believe in local NTP servers? Do you really > > need the logs to be perfectly accurate? > > Perfectly accurate is very helpful when trying to associate several > incidents going on at the same time or when trying to figure out the > timeline leading up to why a machine had a kernel panic, for example. > > > 2) If you do have a local NTP > > server, is it only for local internal use, or do you provide this NTP > > server to your clients as an added service? > > > Our master stratum 1 GPS clock only has ipv6 access to the outside > world. Our two 'public' ntp servers can talk directly to it over ipv4 > or ipv6, and those are are publicly available via ipv4 or ipv6. > > > > > 3) If you do have a local > > NTP server, do you have a standby local NTP server or do you use the > > internet as your standby server? > > If the stratum 1 becomes unavailable (its 500 miles away on a different > network), the two public NTP servers are peered with one another, and > both have a different outside third-party NTP server to sync with (may > it be an upstream provider's ntp server, or one of the pool ones from > ntp.org). > > Never had a problem with this setup, and its worked rather well. > > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From gbonser at seven.com Sun Oct 24 12:46:26 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 24 Oct 2010 10:46:26 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <4CC45A38.8080201@brightok.net> References: <4CC0F16F.2060706@brightok.net> <1287723128.10216.182.camel@karl><20101022182518.64924b44@opy.nosense.org><20101022133804.GA49113@ussenterprise.ufp.org> <9F1872BB-F736-4914-B201-60671C821620@delong.com><5A6D953473350C4B9995546AFE9939EE0B14C481@RWC-EX1.corp.seven.com> <4CC45A38.8080201@brightok.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C485@RWC-EX1.corp.seven.com> > Probably no reason at all, though probably little perceived benefit. > 1492 is common enough that google/youtube already runs lower MTU's just > to avoid common broken PPPoE setups (which often could run higher MTU, > but weren't configured that way). I run into that already with people doing various things inside their net (MPLS, GRE, IPIP?) that shorten the effective MTU but they block the ICMP unreachable packets and break PMTU discovery. That blanket blocking of ICMP unreachable type 3 code 4 is evil, in my opinion. If your traffic passes through a Cisco ASA series device (and maybe other vendors, too) your MTU is effectively 1380 anyway as that is the maximum MSS that it advertises (or can even be configured to advertise) when it establishes an outbound connection and in some versions of its code will drop a packet from an endpoint that doesn't honor the advertised MSS. It is a real performance killer across the Internet in my opinion and better performance could be had, particularly for long distance links where you are limited by the number of "in flight" packets if those packets could be bigger. The problem is that even if you have two end points that are jumbo capable, the networks in the path don't seem to support >1500 MTU. If everyone configured their peering and internal gear to support a 9216 byte frame size and set their MTUs to 9000, that change would be transparent to the connections flowing though it and people who wanted to send larger frames could do so without impacting anyone using a shorter size. From dga at cs.cmu.edu Sun Oct 24 13:18:18 2010 From: dga at cs.cmu.edu (David Andersen) Date: Sun, 24 Oct 2010 14:18:18 -0400 Subject: NTP Server In-Reply-To: References: Message-ID: On Oct 24, 2010, at 1:09 PM, Randy Bush wrote: >> 1) How necessary do you believe in local NTP servers? Do you really >> need the logs to be perfectly accurate? > > what is "perfectly accurate?" perfection is not very realistic. to > what use do you put these logs? what precision and jitter are required > for that use? > > imiho, if you are just comparing router and server log files, run off > public. if you are trying to do fine-grained measurement, you are going > to invest a lot in clock and propagation research. As one of the aforementioned "time-nuts", I'd strongly second Randy's recommendation. It's hard to find a middle ground in timing: Most of the network-accessible stratum {1, 2} clocks are good enough for many uses. If you find yourself needing really precise time with good guarantees, you're not just talking about buying one GPS unit -- you can easily go down a rathole of finding multiple units with good holdover. (And if you don't need that, then ask yourself why public isn't good enough). Possible very reasonable answers include needing to do one-way delay measurements; others include wanting to depend on time for authentication protocols or other protocols and not have an external dependency (assuming you're not high-value enough for someone to try to spoof GPS at you). The problem is that once you have a timing device or two, you've added to the set of crap you have to manage and monitor. I use a lot of CDMA-based time receivers so that I can throw them in machine rooms with no sky access, and every year or two, I have to go upgrade a lot of firmware because some cellular company has changed their protocols. I find a lot of cellular base stations that keep the wrong time (suggesting that their GPS-based time sync is fubared in some way). Yadda, yadda. Nothing is free. -Dave From gbonser at seven.com Sun Oct 24 13:26:27 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 24 Oct 2010 11:26:27 -0700 Subject: NTP Server In-Reply-To: References: Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C487@RWC-EX1.corp.seven.com> > i would generally let customers chime off routers which are strat 2 or > 3. if a customer has other needs, then they can deal. if they are > really concerned, they should not bet on me anyway. > > > 3) If you do have a local NTP server, do you have a standby local NTP > > server or do you use the internet as your standby server? I agree. Someone downstream from you who is *really* concerned about time can either do it themselves or pay you to do it. If you are just date stamping logfiles, you are probably better off running a few servers that sync up externally to one of the free pools (http://www.pool.ntp.org/en/ ) in your region (they generally round-robin IPs to several different servers) and sync your internal stuff to your internal servers. The main reason for that is that the "free" servers won't remain "free" if every single individual host on the Internet is hitting them. By running your own internal servers a stratum down you offload that traffic from the public servers and preserve that resource. NTP is a great candidate for v4 anycast, too, so you can have a common configuration at all your locations if you want. From beckman at angryox.com Sun Oct 24 13:32:30 2010 From: beckman at angryox.com (Peter Beckman) Date: Sun, 24 Oct 2010 14:32:30 -0400 Subject: NTP Server In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C487@RWC-EX1.corp.seven.com> References: <5A6D953473350C4B9995546AFE9939EE0B14C487@RWC-EX1.corp.seven.com> Message-ID: On Sun, 24 Oct 2010, George Bonser wrote: > The main reason for that is that the "free" servers won't remain "free" > if every single individual host on the Internet is hitting them. By > running your own internal servers a stratum down you offload that > traffic from the public servers and preserve that resource. NTP is a > great candidate for v4 anycast, too, so you can have a common > configuration at all your locations if you want. It sure would be nice if datacenter facilities offered an independent NTP time source as a benefit for hosting with them. It would also be great if ISPs would offer this on the local network as well for their customers, as likely they are already have one in several regions. time.windows.com and time.apple.com are also fine, though I'm not sure either has published their NTP source, whether it is a device or they are simply using the same ntp.org pool as many of us. I've never had a problem with the public NTP sources, but as George said, "free" may not always be "free." Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ --------------------------------------------------------------------------- From gbonser at seven.com Sun Oct 24 13:33:28 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 24 Oct 2010 11:33:28 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <20101024170751.GA56348@ussenterprise.ufp.org> References: <9F1872BB-F736-4914-B201-60671C821620@delong.com><5A6D953473350C4B9995546AFE9939EE0B14C481@RWC-EX1.corp.seven.com><4CC45A38.8080201@brightok.net> <20101024170751.GA56348@ussenterprise.ufp.org> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C488@RWC-EX1.corp.seven.com> > > I've had pretty good luck asking for higher MTU's on both customer and > peering links. I'd say about an 80% success rate for dedicated GigE's. > It's generally not on the forms though, and sometimes you get what I > consider weird responses. For instance I know several providers who > won't going higher than 4470 on ethernet. > > If more folks asked for higher MTUs it might become part of the > standard forms... That is what I am thinking as well. For example, in the past week I have seen someone here asking about data center locations and mentioned data replication between them. If you are on both coasts of the US and are backing up or otherwise replicating data between the two, even going to a MTU of 3000 is a measurable win depending on the amount of data you are moving and the protocols you are using. Load on routers and even hosts is generally caused by packets per second, not bits per second. If you cut the number of packets in half you reduce the load on every single piece of gear in the path. Gee, I wonder how much energy consumption that would save on a global basis if everyone did that. Coming across Phil Dykstra's paper from 1999 is what got me thinking about it (well, that and moving a lot of data between Europe and the West coast of the US). http://sd.wareonearth.com/~phil/jumbo.html http://staff.psc.edu/mathis/MTU/ From sean at donelan.com Sun Oct 24 13:42:24 2010 From: sean at donelan.com (Sean Donelan) Date: Sun, 24 Oct 2010 14:42:24 -0400 (EDT) Subject: NTP Server In-Reply-To: References: Message-ID: On Sun, 24 Oct 2010, Brandon Kim wrote: > 1) How necessary do you believe in local NTP servers? Do you really > need the logs to be perfectly accurate? > 2) If you do have a local NTP server, is it only for local internal > use, or do you provide this NTP server to your clients as an added > service? > 3) If you do have a local NTP server, do you have a standby local NTP > server or do you use the internet as your standby server? First terminology. What do you mean by a local NTP server? Almost any Cisco/Juniper router, Unix server and some recent Windows servers have NTP server software and can synchronize clocks in your network. So you may already have a NTP server capable device. You just need to configure it, and give it a good source of time. It would be a Stratum 2 or greater NTP server because the good source of time is another NTP server. Left to itself, NTP is pretty good at keeping clocks in arbitrary networks synchronized with each other. But most people are also interested in synchronizing clocks with some official time source. The Network Time Protocol doesn't really have the notion of a "standby" server. It uses multiple time sources together, and works best with about four time sources. But for many end-systems, the Simple Network Time Protocol with a single time source may be sufficient. If you are in a regulated industry (stock broker, electric utility, 9-1-1 answering point, etc) there are specific time and frequency standards you must follow. On the other hand, are you are asking about a local clock receiver (radio, satellite, etc) for a stratum 1 NTP server? Clock receivers are getting cheaper, the problem is usually the antenna location. Or on the third hand, are you asking about local primary reference clock (caesium, rubium, etc) for a stratum 1 NTP server? These are still relatively expensive up to extremely expensive. Or on the fourth hand, are you a time scientist working to improve international time standards. If you are one of these folks, you already know. Most major ISPs use NTP across their router backbone, and incidently provide it to their customers. The local ISP router connected to your circuit probably has NTP enabled. Required accuracy is in the eye of the beholder. NASDAQ requires brokers to have their clocks synchronized within 3 seconds of UTC(NIST). 9-1-1 centers are required to have their clocks synchronized within 0.5 seconds of UTC. Kerberos/Active Directory requires clocks to be synchronized within 5 minutes of each other. If your log files have a resolution of 1 second, you probably won't see much benefit of sub-second clock precision or accuracy. If you are conducting distributed measurements with sub-microsecond resolution, you probably will want something more. From gbonser at seven.com Sun Oct 24 13:55:35 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 24 Oct 2010 11:55:35 -0700 Subject: NTP Server In-Reply-To: References: <5A6D953473350C4B9995546AFE9939EE0B14C487@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C48B@RWC-EX1.corp.seven.com> > From: Peter Beckman > Sent: Sunday, October 24, 2010 11:33 AM > To: North American Network Operators Group > Subject: RE: NTP Server > > On Sun, 24 Oct 2010, George Bonser wrote: > It sure would be nice if datacenter facilities offered an independent > NTP > time source as a benefit for hosting with them. One provider I worked with in the past used to offer it but stopped because customers apparently had a wide variety of expectations on what that should be. It turned into a complaint generator when people would demand stratum 1 or if one of the servers was down for a bit so they just shut it off. It provided no benefit as far as they were concerned and it cost them time, effort, and power to provide it. They reasoned that the customer could provide their own time servers and own the issues themselves. That is probably an exercise in properly setting expectations at the start, though. Provide a stratum 3 service and tell people that one of the sources is subject to disappearing from time to time as a function of regular maintenance and folks should be fine with that or do it themselves. From mpetach at netflight.com Sun Oct 24 15:48:35 2010 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 24 Oct 2010 13:48:35 -0700 Subject: NTP Server In-Reply-To: References: Message-ID: On Sun, Oct 24, 2010 at 8:34 AM, Brandon Kim wrote: > > Hey guys: > > I wanted to open up this question regarding NTP server. I recalled someone had created a posting of this quite awhile back. > >From a service provider/ISP standpoint, ?does anyone think that having a local NTP server is really necessary? > > I've asked some of my fellow engineers at work and many of them gives me the same response, "Can't we just use free ones out on the internet?" Depends on how much you trust other people. NTP can potentially be used as a DoS vector by your upstream clocks, if you're not running your own. I've seen 50,000 servers panic in the blink of an eye when the NTP source issued a leap second, and the kernel wasn't patched to handle it properly; and that's a forward leap second. Nobody's tested reverse leap seconds yet; who knows what would happen to your hosts if your upstream NTP servers decided to issue a reverse leap second towards you? Granted, if you choose enough diverse upstream clocks, that becomes more difficult for someone to exploit; but it's not impossible, and you can't count on keeping your upstream clock sources secret, given the bidirectional communication that can take place between NTP servers. *shrug* It's cheap enough to run your own clock sources, once you're above a certain size, and it's one less potential attack vector from the outside; why wouldn't you want to secure your edge against it? Matt From tme at americafree.tv Sun Oct 24 15:58:02 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Sun, 24 Oct 2010 16:58:02 -0400 Subject: NTP Server In-Reply-To: References: Message-ID: <0C7FCE41-3C30-44D8-8581-C3CE49219523@americafree.tv> On Oct 24, 2010, at 4:48 PM, Matthew Petach wrote: > On Sun, Oct 24, 2010 at 8:34 AM, Brandon Kim wrote: >> >> Hey guys: >> >> I wanted to open up this question regarding NTP server. I recalled someone had created a posting of this quite awhile back. >>> From a service provider/ISP standpoint, does anyone think that having a local NTP server is really necessary? >> >> I've asked some of my fellow engineers at work and many of them gives me the same response, "Can't we just use free ones out on the internet?" > > Depends on how much you trust other people. > NTP can potentially be used as a DoS vector by your upstream clocks, > if you're not running your own. > > I've seen 50,000 servers panic in the blink of an eye when the NTP source > issued a leap second, and the kernel wasn't patched to handle it properly; > and that's a forward leap second. Nobody's tested reverse leap seconds > yet; who knows what would happen to your hosts if your upstream NTP > servers decided to issue a reverse leap second towards you? Negative leap seconds are certainly possible, and 20 years ago (when I was working for the USNO Directorate of Time) I thought that the currents down in the core might be going to give us a few; I have often wondered how many systems would choke on this. Regards Marshall > Granted, if > you choose enough diverse upstream clocks, that becomes more difficult > for someone to exploit; but it's not impossible, and you can't count on > keeping your upstream clock sources secret, given the bidirectional > communication that can take place between NTP servers. > > *shrug* It's cheap enough to run your own clock sources, once you're > above a certain size, and it's one less potential attack vector from the > outside; why wouldn't you want to secure your edge against it? > > Matt > > From sjh at waroffice.net Sun Oct 24 16:14:39 2010 From: sjh at waroffice.net (Steven Hill) Date: Sun, 24 Oct 2010 22:14:39 +0100 (BST) Subject: NTP Server In-Reply-To: References: Message-ID: On Sun, 24 Oct 2010, Christopher Morrow wrote: >> How do you knew that your local NTP server knew what time it is? ?(for sure) > > this question is a trap. Quite. We had 2 HP 5071s,(+ several GPS standards) and at the time being the definition of a second, either could be correct at any time. When I took a moment to think about it, and discovered both standards were correct, and yet disagreed, my brain fell out. -- Steven Hill "Women and cats will do as they please, and men and dogs should relax and get used to the idea." - Robert A. Heinlein From tglassey at earthlink.net Sun Oct 24 18:35:11 2010 From: tglassey at earthlink.net (todd glassey) Date: Sun, 24 Oct 2010 16:35:11 -0700 Subject: NTP Server In-Reply-To: References: Message-ID: <4CC4C2AF.3050703@earthlink.net> On 10/24/2010 2:14 PM, Steven Hill wrote: > On Sun, 24 Oct 2010, Christopher Morrow wrote: > >>> How do you knew that your local NTP server knew what time it is? >>> (for sure) Because you got the time service from an authoritative source who did the rest of the work to make sure that the NTP evidence practice worked. This means you are a partner of the time-provider and you do both client and peering type time-service events. It also means you address the issues of certainty and the need to say absolutely what time it is in the US or where ever at any given instance. Let me be blunt... The NTP Evidence Model was designed for a totally unrelated purpose and doesn't make the needed hurdle today. In fact there are a number of related NTP Services necessary to create a complete service model and not all of them are compatible with running a NTP Service as a daemon unless you can do time-queries through NTPDATE or other tools on separate ports. Todd Glassey >> >> this question is a trap. > > Quite. > > We had 2 HP 5071s,(+ several GPS standards) and at the time being the > definition of a second, either could be correct at any time. When I took > a moment to think about it, and discovered both standards were correct, > and yet disagreed, my brain fell out. > -- //----------------------------------------------------------------- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From tglassey at earthlink.net Sun Oct 24 18:44:32 2010 From: tglassey at earthlink.net (todd glassey) Date: Sun, 24 Oct 2010 16:44:32 -0700 Subject: NTP Server In-Reply-To: References: Message-ID: <4CC4C4E0.7060309@earthlink.net> On 10/24/2010 7:37 PM, Peter Lothberg wrote: >> acquired the time from the three stratum-1 clocks, they all poll each other >> for the average. > > How many clocks/servers do you need to average from to knew that you > are within say 1ms of UTC(nist)? What type of evidence model do you need to prove this with? - The NIST servers located around the US are mostly operated out of people like our operations (we have seven of them now and Atlanta coming online in about three weeks as well.) NTP has some foibles most are probably unaware of - that is it must have three (3) competent sources defined so that it can vote. We like to also say all three voices need to be coming from the same subnet so that the network latency and other physical aspects which control the policy-implementation are reliable as well. If you take one server from multiple sites you will be stuck with multiple network latency overhead factors polluting the resolution and certainty in the 'small bits' of your time-attestation. The real issue is how you prove the time-setting took. Or better yet - that you allow Applications to make their own NTP queries of reference time servers - that's really where the rubber meets the road in time-centric trust models. Todd Glassey > > -P > > -- //----------------------------------------------------------------- This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. From brandon.kim at brandontek.com Sun Oct 24 19:15:56 2010 From: brandon.kim at brandontek.com (Brandon Kim) Date: Sun, 24 Oct 2010 20:15:56 -0400 Subject: NTP Server In-Reply-To: References: , Message-ID: Hi Sean: By local I meant in-house, on-site in our datacenter. As far as what applications could use our NTP service, I would leave that up to each client and what they are running. For my own personal purposes, it would just be for log purposes. (error logs, syslogs, etc etc) I have heard that routers don't make good NTP servers since they weren't designed to keep track of time. This, I have read from a Cisco source. Can't remember where though. Or maybe they were just referring to older less powerful routers like 2500 series... Brandon > Date: Sun, 24 Oct 2010 14:42:24 -0400 > From: sean at donelan.com > To: nanog at nanog.org > Subject: Re: NTP Server > > On Sun, 24 Oct 2010, Brandon Kim wrote: > > 1) How necessary do you believe in local NTP servers? Do you really > > need the logs to be perfectly accurate? > > 2) If you do have a local NTP server, is it only for local internal > > use, or do you provide this NTP server to your clients as an added > > service? > > 3) If you do have a local NTP server, do you have a standby local NTP > > server or do you use the internet as your standby server? > > First terminology. What do you mean by a local NTP server? > > Almost any Cisco/Juniper router, Unix server and some recent Windows > servers have NTP server software and can synchronize clocks in your > network. So you may already have a NTP server capable device. You just > need to configure it, and give it a good source of time. It would be a > Stratum 2 or greater NTP server because the good source of time is > another NTP server. Left to itself, NTP is pretty good at keeping clocks > in arbitrary networks synchronized with each other. But most people are > also interested in synchronizing clocks with some official time source. > > The Network Time Protocol doesn't really have the notion of a "standby" > server. It uses multiple time sources together, and works best with about > four time sources. But for many end-systems, the Simple Network Time > Protocol with a single time source may be sufficient. > > If you are in a regulated industry (stock broker, electric utility, 9-1-1 > answering point, etc) there are specific time and frequency standards you > must follow. > > On the other hand, are you are asking about a local clock receiver (radio, > satellite, etc) for a stratum 1 NTP server? Clock receivers are getting > cheaper, the problem is usually the antenna location. > > Or on the third hand, are you asking about local primary reference clock > (caesium, rubium, etc) for a stratum 1 NTP server? These are still > relatively expensive up to extremely expensive. > > Or on the fourth hand, are you a time scientist working to improve > international time standards. If you are one of these folks, you already > know. > > > Most major ISPs use NTP across their router backbone, and incidently > provide it to their customers. The local ISP router connected to your > circuit probably has NTP enabled. > > Required accuracy is in the eye of the beholder. NASDAQ requires brokers > to have their clocks synchronized within 3 seconds of UTC(NIST). 9-1-1 > centers are required to have their clocks synchronized within 0.5 seconds > of UTC. Kerberos/Active Directory requires clocks to be synchronized > within 5 minutes of each other. > > If your log files have a resolution of 1 second, you probably won't see > much benefit of sub-second clock precision or accuracy. If you are > conducting distributed measurements with sub-microsecond resolution, you > probably will want something more. > > > From james.cutler at consultant.com Sun Oct 24 19:43:50 2010 From: james.cutler at consultant.com (Cutler James R) Date: Sun, 24 Oct 2010 20:43:50 -0400 Subject: NTP Server In-Reply-To: References: , Message-ID: Regarding leap seconds: A modern OS kernel using the NTP daemon to control time will always experience monotonic time. Negative leap seconds should result in the local clock slowing slightly until the local time matches the NTP-derived time. This is in strong contrast to what can happen when ntpdate or similar queries are used to adjust system time, as in the following example from a popular CPE log where the local CPU clock tended to run fast: Oct 24 04:27:59 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 05:28:00 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 06:28:00 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 07:28:01 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 08:28:01 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 09:28:02 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 10:28:03 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 11:28:04 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 12:28:04 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 13:28:05 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 14:28:05 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 15:28:05 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 16:28:06 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 17:28:07 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 18:28:08 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Oct 24 19:28:08 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted +0 seconds). Oct 24 20:28:09 192.168.1.1 HomeN ntp: Clock synchronized to network time server time.apple.com (adjusted -1 seconds). Regarding local time servers: This is the situation in which local clients, at least those with UNIX or UNIX-like OS can take advantage of ntpd and local time servers to have consistent and monotonic time across your network with a measure of insulation from external vagaries. Yes, I have run ntpd on Windows systems, but have no quotable experience with the current Windows version (Windows 7). James R. Cutler james.cutler at consultant.com From gbonser at seven.com Sun Oct 24 19:52:00 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 24 Oct 2010 17:52:00 -0700 Subject: IPv6 fc00::/7 ??? Unique local addresses In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C488@RWC-EX1.corp.seven.com> References: <9F1872BB-F736-4914-B201-60671C821620@delong.com><5A6D953473350C4B9995546AFE9939EE0B14C481@RWC-EX1.corp.seven.com><4CC45A38.8080201@brightok.net><20101024170751.GA56348@ussenterprise.ufp.org> <5A6D953473350C4B9995546AFE9939EE0B14C488@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C496@RWC-EX1.corp.seven.com> > > Coming across Phil Dykstra's paper from 1999 is what got me thinking > about it (well, that and moving a lot of data between Europe and the > West coast of the US). > > http://sd.wareonearth.com/~phil/jumbo.html > > http://staff.psc.edu/mathis/MTU/ > > Found more good information here: http://noc.net.internet2.edu/i2network/maps--documentation/policy-statem ents.html#Jumbo%20Frames It might not be a bad idea to take some of what is learned on Inet2 and backport it to the 'net where possible. I also discovered that Linux will do RFC4821 PMTU discovery if you set /proc/sys/net/ipv4/tcp_mtu_probing to the proper value. It is turned off by default. Solaris is on by default it appears. From rdobbins at arbor.net Sun Oct 24 21:09:59 2010 From: rdobbins at arbor.net (Dobbins, Roland) Date: Mon, 25 Oct 2010 02:09:59 +0000 Subject: NTP Server In-Reply-To: References: Message-ID: <2D93D9F1-6239-446B-ACA4-C97D86AE48CC@arbor.net> On Oct 25, 2010, at 3:48 AM, Matthew Petach wrote: > NTP can potentially be used as a DoS vector by your upstream clocks, if you're not running your own. +1 Also, if you experience a network partition event for any reason (DDoS attack, backhoe attack, et. al.) which disrupts communications between your network and the one(s) on the Internet where the public ntp servers you're using live, the accuracy of your time-hack becomes a concern just at the moment when you need it the most for combinatorial analysis of multiple forms of telemetry. And of course, time services for your infrastructure/services/apps ought to run across your DCN, anyways, which should be kept isolated from your production network (you don't want to rely upon proxies to enable something as critical as time service, IMHO). As Sean pointed out, all your routers from modern vendors are ntp-capable, and getting a couple of radio cards for servers to sync with WWVB isn't very expensive, assuming you can plug into an aerial which gets good reception: ----------------------------------------------------------------------- Roland Dobbins // Sell your computer and buy a guitar. From james.cutler at consultant.com Sun Oct 24 21:39:33 2010 From: james.cutler at consultant.com (Cutler James R) Date: Sun, 24 Oct 2010 22:39:33 -0400 Subject: NTP Server Message-ID: <94241BD8-C05B-420A-AC9C-C7B42627F3E7@consultant.com> Routers are not a good choice for time servers as it complicates configuration and, to some extent, constrains deployment methodology for routers to be effective with time service. We don't run DNS on routers, it is a service. Time service via NTP is a service as well. The NTP daemon in a router is not implemented in hardware and requires CPU resources better dedicated to RIB management. In my experience, a reliable NTP peer group can be implemented on the same set of boxes as DNS (bind, etc.) with little or no impact on DNS performance. If you can count to four or more, you can make a reliable peer group of time servers. On Oct 24, 2010, at 8:15 PM, Brandon Kim wrote: > > Hi Sean: > > By local I meant in-house, on-site in our datacenter. As far as what applications could use our NTP service, I would > leave that up to each client and what they are running. For my own personal purposes, it would just be for log purposes. > (error logs, syslogs, etc etc) > > I have heard that routers don't make good NTP servers since they weren't designed to keep track of time. This, I have read > from a Cisco source. Can't remember where though. Or maybe they were just referring to older less powerful routers like 2500 series... > > Brandon > > > > > > >> Date: Sun, 24 Oct 2010 14:42:24 -0400 >> From: sean at donelan.com >> To: nanog at nanog.org >> Subject: Re: NTP Server >> >> On Sun, 24 Oct 2010, Brandon Kim wrote: >>> 1) How necessary do you believe in local NTP servers? Do you really >>> need the logs to be perfectly accurate? >>> 2) If you do have a local NTP server, is it only for local internal >>> use, or do you provide this NTP server to your clients as an added >>> service? >>> 3) If you do have a local NTP server, do you have a standby local NTP >>> server or do you use the internet as your standby server? >> >> First terminology. What do you mean by a local NTP server? >> >> Almost any Cisco/Juniper router, Unix server and some recent Windows >> servers have NTP server software and can synchronize clocks in your >> network. So you may already have a NTP server capable device. You just >> need to configure it, and give it a good source of time. It would be a >> Stratum 2 or greater NTP server because the good source of time is >> another NTP server. Left to itself, NTP is pretty good at keeping clocks >> in arbitrary networks synchronized with each other. But most people are >> also interested in synchronizing clocks with some official time source. >> >> The Network Time Protocol doesn't really have the notion of a "standby" >> server. It uses multiple time sources together, and works best with about >> four time sources. But for many end-systems, the Simple Network Time >> Protocol with a single time source may be sufficient. >> >> If you are in a regulated industry (stock broker, electric utility, 9-1-1 >> answering point, etc) there are specific time and frequency standards you >> must follow. >> >> On the other hand, are you are asking about a local clock receiver (radio, >> satellite, etc) for a stratum 1 NTP server? Clock receivers are getting >> cheaper, the problem is usually the antenna location. >> >> Or on the third hand, are you asking about local primary reference clock >> (caesium, rubium, etc) for a stratum 1 NTP server? These are still >> relatively expensive up to extremely expensive. >> >> Or on the fourth hand, are you a time scientist working to improve >> international time standards. If you are one of these folks, you already >> know. >> >> >> Most major ISPs use NTP across their router backbone, and incidently >> provide it to their customers. The local ISP router connected to your >> circuit probably has NTP enabled. >> >> Required accuracy is in the eye of the beholder. NASDAQ requires brokers >> to have their clocks synchronized within 3 seconds of UTC(NIST). 9-1-1 >> centers are required to have their clocks synchronized within 0.5 seconds >> of UTC. Kerberos/Active Directory requires clocks to be synchronized >> within 5 minutes of each other. >> >> If your log files have a resolution of 1 second, you probably won't see >> much benefit of sub-second clock precision or accuracy. If you are >> conducting distributed measurements with sub-microsecond resolution, you >> probably will want something more. >> >> >> > = James R. Cutler james.cutler at consultant.com From jmamodio at gmail.com Sun Oct 24 22:48:12 2010 From: jmamodio at gmail.com (Jorge Amodio) Date: Sun, 24 Oct 2010 22:48:12 -0500 Subject: NTP Server In-Reply-To: <2D93D9F1-6239-446B-ACA4-C97D86AE48CC@arbor.net> References: <2D93D9F1-6239-446B-ACA4-C97D86AE48CC@arbor.net> Message-ID: Nowadays is not that difficult to get off the shelf solutions for different applications. Just to point to one: http://www.symmetricom.com/products/ntp-servers/ntp-network-appliances/ Regards Jorge From sean at donelan.com Mon Oct 25 00:01:24 2010 From: sean at donelan.com (Sean Donelan) Date: Mon, 25 Oct 2010 01:01:24 -0400 (EDT) Subject: NTP Server In-Reply-To: <2D93D9F1-6239-446B-ACA4-C97D86AE48CC@arbor.net> References: <2D93D9F1-6239-446B-ACA4-C97D86AE48CC@arbor.net> Message-ID: On Mon, 25 Oct 2010, Dobbins, Roland wrote:> > On Oct 25, 2010, at 3:48 AM, Matthew Petach wrote: >> NTP can potentially be used as a DoS vector by your upstream clocks, >if you're not running your own. > +1 > > Also, if you experience a network partition event for any reason (DDoS > attack, backhoe attack, et. al.) which disrupts communications between > your network and the one(s) on the Internet where the public ntp servers > you're using live, the accuracy of your time-hack becomes a concern just > at the moment when you need it the most for combinatorial analysis of > multiple forms of telemetry. Modern versions of NTP have a relatively long polling interval once the clock is stable. Unless you are already using specialized timing hardware, your tolorance of the clock drift on off-the-shelf computers and routers is not going to be an immediate issue during short-term or even medium-term network problems. Any clock source can have an indeterminate outage. Generally the longer the hold time, the more expensive the clock hardware. > And of course, time services for your infrastructure/services/apps > ought to run across your DCN, anyways, which should be kept isolated > from your production network (you don't want to rely upon proxies to > enable something as critical as time service, IMHO). NTP started on Fuzzball routers. Its very light-weight on any hardware. There are lots of reasons not to have customers accessing your infrastructure devices. Lots of NTP queries can overload any device. Although your infrastructure devices should still have synchronized clocks with the rest of your infrastructure. If you have an enterprise network dependent on firewalls, another pin-hole through the firewall for NTP port 123 is also an another opportunity for mischief. There are lots of different ways to measure time. But I've noticed some people seem to create extreme Rube Goldberg contraptions. Figure out what precision and accuracy you really need. Time is always just an estimate. From M.Hotze at hotze.com Mon Oct 25 00:16:27 2010 From: M.Hotze at hotze.com (Martin Hotze) Date: Mon, 25 Oct 2010 05:16:27 +0000 Subject: NTP Server In-Reply-To: References: Message-ID: <2EAA64100D553F448A3BC8EAEB3D0FDA1475C8@EXSRV.hotzecom.local> > Date: Sun, 24 Oct 2010 14:18:18 -0400 > From: David Andersen > Subject: Re: NTP Server (...) > If you find yourself needing really precise time with good guarantees, > you're not just talking about buying one GPS unit -- you can easily go > down a rathole of finding multiple units with good holdover And you have to trust one single source: the US military. Having my network outside the US and having read NOTAMs (notice to airmen) while preparing a flight stating that due to military ops the GPS signal was screwed up in that area I would not rely on GPS as my single NTP source for my network. #m From sean at donelan.com Mon Oct 25 00:18:01 2010 From: sean at donelan.com (Sean Donelan) Date: Mon, 25 Oct 2010 01:18:01 -0400 (EDT) Subject: NTP Server In-Reply-To: <94241BD8-C05B-420A-AC9C-C7B42627F3E7@consultant.com> References: <94241BD8-C05B-420A-AC9C-C7B42627F3E7@consultant.com> Message-ID: On Sun, 24 Oct 2010, Cutler James R wrote: > In my experience, a reliable NTP peer group can be implemented on the > same set of boxes as DNS (bind, etc.) with little or no impact on DNS > performance. If you can count to four or more, you can make a reliable > peer group of time servers. There are lots of alternatives. CableLabs' designs tend to tie together DHCP, DNS, NTP, TFTP and headends. DSL forum designs tend to split them apart. If you have a set of systems which are already configured and accessed by end-user systems, such as DNS or DHCP or Active Directory, then NTP is just one more protocol with many of the same risks on those systems. Shared fate also makes trouble shooting easier, because a problem will usually affect all of the services. Other alternatives such as multicast NTP tend to work better with a device on each LAN (such as a router). And still other alternatives tend to work better with specialized servers if you need hardware assist or auditing. But again, it comes back to what are your requirements. For some people, the built-in WindowsTime service meets their needs. Other people need specialized clock hardware connected directly to their systems. From Joel.Snyder at Opus1.COM Mon Oct 25 00:41:09 2010 From: Joel.Snyder at Opus1.COM (Joel M Snyder) Date: Mon, 25 Oct 2010 07:41:09 +0200 Subject: [WOB] RE: NTP Server Message-ID: <4CC51875.20505@Opus1.COM> Complete WOB, but I whenever people start talking about NTP, I always start trying to figure out how I could justify one of these for the data center: http://www.inovasolutions.com/network-clocks/products/analog-network-clocks.htm (PoE, SNTP, ANALOG clock) jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Senior Partner, Opus One Phone: +1 520 324 0494 jms at Opus1.COM http://www.opus1.com/jms From sean at donelan.com Mon Oct 25 00:50:03 2010 From: sean at donelan.com (Sean Donelan) Date: Mon, 25 Oct 2010 01:50:03 -0400 (EDT) Subject: NTP Server In-Reply-To: References: , Message-ID: On Sun, 24 Oct 2010, Brandon Kim wrote: > By local I meant in-house, on-site in our datacenter. What do you think it means to have a NTP server in-house, on-site in your datacenter? There all many different levels of NTP servers. Putting some free software on a spare computer, and synchronizing it to a few public NTP servers on the Internet? Or buying a $5,000 specialized NTP hardware device (or more if you want backups) and installing an external antenna to pick up a radio reference clock source from a satellite or radio station? If you already provide DNS/DHCP and other services in your datacenter, its usually not that much effort to add the NTP service. In many cases, the software is already part of the base operating system package, or easily added to most modern systems. But in most cases, NTP seems to be treated as an unsupported service. If it works, great. If it doesn't, don't complain. If the person who cared about NTP leaves, no one else even knows it exists. If you need traceable time, or have some other regulatory requirement, its going to be more work. My point is there isn't one answer. From jtk at cymru.com Mon Oct 25 02:07:17 2010 From: jtk at cymru.com (John Kristoff) Date: Mon, 25 Oct 2010 02:07:17 -0500 Subject: NTP Server In-Reply-To: References: Message-ID: <20101025020717.6336673f@t61p> On Sun, 24 Oct 2010 20:15:56 -0400 Brandon Kim wrote: > I have heard that routers don't make good NTP servers since they > weren't designed to keep track of time. This, I have read from a > Cisco source. Can't remember where though. Or maybe they were just > referring to older less powerful routers like 2500 series... I've implemented a two separate sets of stratum-2 services in two different academic networks using retired Cisco router gear. As far as I know they are still operating fine, providing time primarily to the institution's other infrastructure and server devices. They only provide time services. I had done some rudimentary stress testing and benchmarking at the time. They performed sufficiently. The advantage of this setup was that they were simple to setup, easy to manage and cheap to replace with the same retired gear we had an abundance of. Maybe the clock resolution isn't as precise as some other hardware, but for the purposes I had used it for it seemed fine. I doubt the underlying code has changed all that much, but at one time David Mills gave his stamp of approval: On another note, contrary to another's position, I'd advocate not implementing public NTP service along with your DNS infrastrucure if at all possible. Co-mingling of critical network services such as naming, routing and time not only with themselves, but also with other less critical network infrastructure subsystems (e.g. web, mail) should generally be avoided in all, but the most resource constrained environments. John From mir at ripe.net Mon Oct 25 03:16:17 2010 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 25 Oct 2010 10:16:17 +0200 Subject: New and Improved RIPE Registry Global Resource Service Message-ID: <4CC53CD1.7010901@ripe.net> [Apologies for duplicate emails] Hi, We have redesigned and improved the way we mirror other databases (Thanks to the RIPE NCC Database staff!). We now have a method of translating the operational data from other registries (for instance from other RIRs or the RADb) into the RIPE Database structure. This means the RIPE Database will contain the most complete set of operational data in (RIPE) RPSL format. Read more on RIPE Labs: http://labs.ripe.net/Members/Paul_P_/ripe-registry-global-resource-service Kind Regards, Mirjam Kuehne RIPE NCC From rs at seastrom.com Mon Oct 25 07:00:43 2010 From: rs at seastrom.com (Robert E. Seastrom) Date: Mon, 25 Oct 2010 08:00:43 -0400 Subject: NTP Server In-Reply-To: <20101024172022.GA56786@ussenterprise.ufp.org> (Leo Bicknell's message of "Sun, 24 Oct 2010 10:20:22 -0700") References: <20101024172022.GA56786@ussenterprise.ufp.org> Message-ID: <8639ru5vo4.fsf@seastrom.com> Leo Bicknell writes: > For instance, for a couple of thousand dollars you can get a > Symmetricom appliance that will do GPS timing with analog dial > backup to NIST. That gives you two non-internet sources at relatively > low cost and low effort. Deploy four in different POP's and you > have redundancy on your own network, and can market that you provide > high quality NTP to your customers. It's nearly fire and forget, > and a check for alarms from the box and make sure you watch for > patches, that's about it. > ... > Notice in both cases I said deploy 4. If you understand the protocol, > and in particular the decision process that really is the minimum > number to have high quality NTP. Syncing everything to one or two > NTP servers really doesn't work so well. You can deploy four, which is the appropriate minimum number to deploy if you're doing it in-house, but four of the same brand and model does not protect you against *other* failure modes, like the problem we all experienced with TrueTime almost 9 years ago. A brief review is here: http://groups.google.com/group/comp.protocols.time.ntp/msg/5f4e774dccf34c47 Not only is it wise to have more than one chipset in play (I have Motorola and Garmin here), but it is good to have time sources from more than one place. Sure, the odds of the GPS C/A code getting it wrong on a global scale are pretty small and if it happens will create an enormous news event... Here in the future, we've taken an enormous step backwards in terms of precision time sources. Here, I only have GPS and WWVB as sources, and WWVB is not a 24-hour source (a better antenna might help this after I move, but the signal strength is not particularly good here on the east coast). Remember GOES? It's gone. LORAN? Canceled and shut down. GLONASS is fully restored to service as of last month after a bad multi-year post-Soviet hit, but good luck finding commodity-priced chipsets or reasonably priced NTP appliances that talk to it. It looks like Duke Nukem Forever may finally ship next year, but until it does I'll continue to draw unfavorable comparisons between it and Galileo. In answer to the original question, running a small constellation (four is the right number) of local stratum 2 servers in each datacenter is a no-brainer. A strong case can be made for running your own stratum 1 servers. They do not have to be on the same subnet as has been suggested (and in fact, you don't want that kind of non-redundancy as a general rule), but NTP really does want the path to the server to be symmetric, which is a big argument in favor of your own inside your network. The folks at NRC in Canada will do cryptographically authenticated NTP with you for an annual fee. I have no idea if there is something similar available from NIST in the US, but if they do I sure hope it doesn't go over the same links as time-a and time-b - from my location anyway, those two get tossed out as falsetickers on weekday afternoon due to too much jitter. -r From jgreco at ns.sol.net Mon Oct 25 09:56:29 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 25 Oct 2010 09:56:29 -0500 (CDT) Subject: NTP Server In-Reply-To: Message-ID: <201010251456.o9PEuT13017358@aurora.sol.net> > On Sun, 24 Oct 2010, George Bonser wrote: > > The main reason for that is that the "free" servers won't remain "free" > > if every single individual host on the Internet is hitting them. By > > running your own internal servers a stratum down you offload that > > traffic from the public servers and preserve that resource. NTP is a > > great candidate for v4 anycast, too, so you can have a common > > configuration at all your locations if you want. > > It sure would be nice if datacenter facilities offered an independent NTP > time source as a benefit for hosting with them. It would also be great if > ISPs would offer this on the local network as well for their customers, as > likely they are already have one in several regions. > > time.windows.com and time.apple.com are also fine, though I'm not sure > either has published their NTP source, whether it is a device or they are > simply using the same ntp.org pool as many of us. > > I've never had a problem with the public NTP sources, but as George said, > "free" may not always be "free." That's particularly true given what some of the free servers have been made to endure. For example, Netgear caused UW Madison a ton of trouble with a defective product that caused a traffic flood: http://pages.cs.wisc.edu/~plonka/netgear-sntp/ NTP is not that hard to provide. Set up four servers. If you only care about relatively stable time, they probably need only be stratum two, this is easy, just go and sync each one with two different stratum one servers, monitor them, and tell customers that it's a free service you make a reasonable attempt to keep running accurate to the second, and that your goal is to keep three operational at any time. Your internal servers can then run NTP to sync with those servers; the use of four will make the failure of up to two (one offline, one with the wrong time, for example) fairly tolerable. Some customers will not care to listen to instructions to sync to four clocks. You have to consider how to make their failure to listen to you to be their own problem. Four is, IMHO, the best number of servers to have. They do not need to be fast or modern machines. You can use something cheap like a pile of old Intel ISP1100's (~40-50 watts each) which might even be doing something else like DNS, monitoring, etc. if you have to. Speaking of which, if anyone is in need of some nice Intel ISP1100's, we are retiring some. Great low power platform for basic services like NTP, proc speeds up to 1GHz, memory up to 1GB, two PCI slots, serial console capable, etc. Available fairly cheap. Great for things like NTP, DNS, we've got one for our FTP archive, Asterisk PBX, etc. ... 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 matthias at leisi.net Mon Oct 25 13:20:15 2010 From: matthias at leisi.net (Matthias Leisi) Date: Mon, 25 Oct 2010 20:20:15 +0200 Subject: Change of dnswl.org operating model Message-ID: Hi, As announced earlier, dnswl.org will change it's operating model. "Heavy users" (defined as those doing > 100'000 queries/24 hours on the public nameservers) and vendors of anti-spam products and services will need a paid subscription. We are now ready to implement the model and will gradually start to enforce it. Since we do not know the current users (all we have are IPs and sometimes hostnames), we will also need to "cut off" users if our attempts at identifying and notifying them fail. The "cut off" may have two of effects: 1) rsync suddenly stops working 2) queries on the public nameservers are refused. We may be able to reinstate access on a case by case basis. As usual, we can be reached at admins/at/dnswl.org (or office/at/dnswl.org for direct access to the people handling the subscriptions). All details are available from http://www.dnswl.org/ -- Matthias From nick at foobar.org Mon Oct 25 13:53:48 2010 From: nick at foobar.org (Nick Hilliard) Date: Mon, 25 Oct 2010 19:53:48 +0100 Subject: NTP Server In-Reply-To: <201010251456.o9PEuT13017358@aurora.sol.net> References: <201010251456.o9PEuT13017358@aurora.sol.net> Message-ID: <4CC5D23C.5080509@foobar.org> On 25/10/2010 15:56, Joe Greco wrote: > Four is, IMHO, the best number of servers to have. They do not need to be > fast or modern machines. They do need to have a somewhat unbroken internal clock. This tends to mean that running ntp on a VM is not generally a good idea. Nick From tony at lava.net Mon Oct 25 15:38:16 2010 From: tony at lava.net (Antonio Querubin) Date: Mon, 25 Oct 2010 10:38:16 -1000 (HST) Subject: .mil DNS problems? Message-ID: Anyone else having trouble resolving .mil hostnames today? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From jgreco at ns.sol.net Mon Oct 25 16:01:53 2010 From: jgreco at ns.sol.net (Joe Greco) Date: Mon, 25 Oct 2010 16:01:53 -0500 (CDT) Subject: NTP Server In-Reply-To: <4CC5D23C.5080509@foobar.org> Message-ID: <201010252101.o9PL1rMt021406@aurora.sol.net> > On 25/10/2010 15:56, Joe Greco wrote: > > Four is, IMHO, the best number of servers to have. They do not need to be > > fast or modern machines. > > They do need to have a somewhat unbroken internal clock. That's a good point. > This tends to mean that running ntp on a VM is not generally a good idea. Running it on a busy host of any kind is not generally a good idea. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples. From dot at dotat.at Mon Oct 25 16:34:44 2010 From: dot at dotat.at (Tony Finch) Date: Mon, 25 Oct 2010 22:34:44 +0100 Subject: NTP Server In-Reply-To: References: <4CC46BEB.9040400@bogus.com> Message-ID: On 24 Oct 2010, at 18:28, Christopher Morrow wrote: > On Sun, Oct 24, 2010 at 1:24 PM, Joel Jaeggli wrote: >> On 10/24/10 10:20 AM, Christopher Morrow wrote: >>> On Sun, Oct 24, 2010 at 10:44 AM, Peter Lothberg wrote: > >>>> How do you knew that your local NTP server knew what time it is? (for sure) >>> >>> this question is a trap. >> >> a man with one watch knows what time it is, a man with two is never sure. > > how about a man with 7? He calibrates them against each other to find out which ones run fast and which slow. Tony. -- f.anthony.n.finch http://dotat.at/ From alex at blastro.com Mon Oct 25 20:13:13 2010 From: alex at blastro.com (Alex Thurlow) Date: Mon, 25 Oct 2010 20:13:13 -0500 Subject: Tools for teaching users online safety Message-ID: <4CC62B29.4040104@blastro.com> I'm trying to find out if there are currently any resources available for teaching people how to be safe online. As in, how to not get a virus, how to pick out phishing emails, how to recognize scams. I'm sure everyone on this list knows these things, but a lot of end users don't. I'm trying to find a way to teach these things to people who aren't too technically savvy. It seems to me that the fewer end users that have issues, the easier our lives will be. So what I'm trying to figure out is, is there a good site or set of sites for this stuff, or is there anyone out there interested in helping to build a unified list of instructions, videos, etc. for all this? -- Alex Thurlow Blastro Networks http://www.blastro.com http://www.roxwel.com http://www.yallwire.com From rubensk at gmail.com Mon Oct 25 20:30:45 2010 From: rubensk at gmail.com (Rubens Kuhl) Date: Mon, 25 Oct 2010 23:30:45 -0200 Subject: Tools for teaching users online safety In-Reply-To: <4CC62B29.4040104@blastro.com> References: <4CC62B29.4040104@blastro.com> Message-ID: One can start with http://antispam.br/videos/english/ Rubens On Mon, Oct 25, 2010 at 11:13 PM, Alex Thurlow wrote: > I'm trying to find out if there are currently any resources available for > teaching people how to be safe online. ?As in, how to not get a virus, how > to pick out phishing emails, how to recognize scams. ?I'm sure everyone on > this list knows these things, but a lot of end users don't. ?I'm trying to > find a way to teach these things to people who aren't too technically savvy. > > It seems to me that the fewer end users that have issues, the easier our > lives will be. > > So what I'm trying to figure out is, is there a good site or set of sites > for this stuff, or is there anyone out there interested in helping to build > a unified list of instructions, videos, etc. for all this? > > -- > Alex Thurlow > Blastro Networks > > http://www.blastro.com > http://www.roxwel.com > http://www.yallwire.com > > > From andre at operations.net Mon Oct 25 20:37:04 2010 From: andre at operations.net (Andre Gironda) Date: Mon, 25 Oct 2010 18:37:04 -0700 Subject: Tools for teaching users online safety In-Reply-To: <4CC62B29.4040104@blastro.com> References: <4CC62B29.4040104@blastro.com> Message-ID: On Mon, Oct 25, 2010 at 6:13 PM, Alex Thurlow wrote: > I'm trying to find out if there are currently any resources available for > teaching people how to be safe online. ?As in, how to not get a virus, how > to pick out phishing emails, how to recognize scams. ?I'm sure everyone on > this list knows these things, but a lot of end users don't. ?I'm trying to > find a way to teach these things to people who aren't too technically savvy. I found this one to be good, especially when targeted at teenagers: "Own Your Space--Keep Yourself and Your Stuff Safe Online" Digital Book for Teens by Linda McCarthy http://www.microsoft.com/downloads/en/details.aspx?FamilyID=87583728-ef14-4703-a649-0fd34bd19d13&displayLang=en If you are teaching Enterprise or college-level end-users, I suggest purchasing ACM membership which will give you access to the Security Awareness videos from ElementK. The SafariBooksOnline library subscription also contains numerous high-quality books and videos on the subject. From pfunix at gmail.com Mon Oct 25 20:40:56 2010 From: pfunix at gmail.com (Beavis) Date: Mon, 25 Oct 2010 19:40:56 -0600 Subject: Tools for teaching users online safety In-Reply-To: <4CC62B29.4040104@blastro.com> References: <4CC62B29.4040104@blastro.com> Message-ID: I use this for the kids.. http://www.hectorsworld.com/island/index.html On Mon, Oct 25, 2010 at 7:13 PM, Alex Thurlow wrote: > I'm trying to find out if there are currently any resources available for > teaching people how to be safe online. ?As in, how to not get a virus, how > to pick out phishing emails, how to recognize scams. ?I'm sure everyone on > this list knows these things, but a lot of end users don't. ?I'm trying to > find a way to teach these things to people who aren't too technically savvy. > > It seems to me that the fewer end users that have issues, the easier our > lives will be. > > So what I'm trying to figure out is, is there a good site or set of sites > for this stuff, or is there anyone out there interested in helping to build > a unified list of instructions, videos, etc. for all this? > > -- > Alex Thurlow > Blastro Networks > > http://www.blastro.com > http://www.roxwel.com > http://www.yallwire.com > > > -- ()? ascii ribbon campaign - against html e-mail /\? www.asciiribbon.org?? - against proprietary attachments From marcus at blazingdot.com Mon Oct 25 21:02:53 2010 From: marcus at blazingdot.com (Marcus Reid) Date: Mon, 25 Oct 2010 19:02:53 -0700 Subject: NTP Server In-Reply-To: <4CC4639B.4090608@rollernet.us> References: <156884471-1287935530-cardhu_decombobulator_blackberry.rim.net-1141047724-@bda588.bisx.prod.on.blackberry> <4CC4639B.4090608@rollernet.us> Message-ID: <20101026020253.GA71910@blazingdot.com> On Sun, Oct 24, 2010 at 09:49:31AM -0700, Seth Mattinen wrote: > On 10/24/2010 09:26, Brandon Kim wrote: > > > > Wow that is amazing and quite impressive that you even run the antenna lines....interesting......do you have to pay for the GPS service? > > > > > Make your own simple GPS NTP clock source: > > http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm Or if the serial port introduces too much jitter for you: http://www.febo.com/time-freq/ntp/soekris/index.html Marcus From ted at pat.io.com Mon Oct 25 23:06:00 2010 From: ted at pat.io.com (Ted Hatfield) Date: Mon, 25 Oct 2010 23:06:00 -0500 (CDT) Subject: Tools for teaching users online safety In-Reply-To: <4CC62B29.4040104@blastro.com> References: <4CC62B29.4040104@blastro.com> Message-ID: On Mon, 25 Oct 2010, Alex Thurlow wrote: > I'm trying to find out if there are currently any resources available for > teaching people how to be safe online. As in, how to not get a virus, how to > pick out phishing emails, how to recognize scams. I'm sure everyone on this > list knows these things, but a lot of end users don't. I'm trying to find a > way to teach these things to people who aren't too technically savvy. > > It seems to me that the fewer end users that have issues, the easier our > lives will be. > > So what I'm trying to figure out is, is there a good site or set of sites for > this stuff, or is there anyone out there interested in helping to build a > unified list of instructions, videos, etc. for all this? > Whatever instructional plan you put together make certain it includes instructions on applying security patches and keeping your system up to date. Probably the best thing most users can do to keep their systems clean. Ted Hatfield From mjwise at kapu.net Tue Oct 26 00:15:53 2010 From: mjwise at kapu.net (Michael J Wise) Date: Mon, 25 Oct 2010 22:15:53 -0700 Subject: Tools for teaching users online safety In-Reply-To: References: <4CC62B29.4040104@blastro.com> Message-ID: <2CBA4D76-040C-460B-98E5-951942D8F53C@kapu.net> On Oct 25, 2010, at 9:06 PM, Ted Hatfield wrote: > Whatever instructional plan you put together make certain it includes instructions on applying security patches and keeping your system up to date. Probably the best thing most users can do to keep their systems clean. That, and ... NEVER ever type your password into the body of an outgoing email. Ever. Aloha, Michael. -- "Please have your Internet License http://kapu.net/~mjwise/ and Usenet Registration handy..." From owen at delong.com Tue Oct 26 00:32:43 2010 From: owen at delong.com (Owen DeLong) Date: Mon, 25 Oct 2010 22:32:43 -0700 Subject: =?windows-1252?Q?Re:_IPv6_fc00::/7_=97_Unique_local_addresses?= In-Reply-To: <20101022032553.E5C3A5F635F@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net> <20101021093109.06a50ea2@opy.nosense.org> <20101021105901.7f708b16@opy.nosense.org> <585A7AD9-E6D6-4477-B8DC-4A09539F0EB9@delong.com> <20101021120648.1872981a@opy.nosense.org> <20101021221539.1E52A5F3641@drugs.dv.isc.org> <4BC01459-B53A-4B2C-B75B-47D89550DFC5@delong.com> <20101022032553.E5C3A5F635F@drugs.dv.isc.org> Message-ID: On Oct 21, 2010, at 8:25 PM, Mark Andrews wrote: > > In message <4BC01459-B53A-4B2C-B75B-47D89550DFC5 at delong.com>, Owen DeLong write > s: >> >> On Oct 21, 2010, at 3:15 PM, Mark Andrews wrote: >> >>> =20 >>> In message , Owen = >> DeLong write >>> s: >>>>>>> =20 >>>>>> Which is part one of the three things that have to happen to make = >> ULA >>>>>> really bad for the internet. >>>>>> =20 >>>>>> Part 2 will be when the first provider accepts a large sum of money = >> to >>>>>> route it within their public network between multiple sites owned = >> by >>>>>> the same customer. >>>>>> =20 >>>>> =20 >>>>> That same customer is also going to have enough global address >>>>> space to be able to reach other global destinations, at least enough >>>>> space for all nodes that are permitted to access the Internet, if = >> not >>>>> more. Proper global address space ensures that if a global = >> destination >>>>> is reachable, then there is a high probability of successfully = >> reaching >>>>> it. The scope of external ULA reachability, regardless of how much >>>>> money is thrown at the problem, isn't going to be as good as proper >>>>> global addresses. >>>>> =20 >>>> _IF_ they implement as intended and as documented. As you've >>>> noted there's a lot of confusion and a lot of people not reading the >>>> documents, latching onto ULA and deciding ti's good. >>>> =20 >>>> It's not a big leap for some company to do a huge ULA deployment >>>> saying "this will never connect to the intarweb thingy" and 5-10 = >> years >>>> later not want to redeploy all their addressing, so, they start = >> throwing >>>> money at getting providers to do what they shouldn't instead of >>>> readdressing their networks. >>> =20 >>> IPv4 think. >>> =20 >>> You don't re-address you add a new address to every node. IPv6 is >>> designed for multiple addresses. >>> =20 >> That's a form of re-addressing. It's not removing the old addresses, = >> but, >> it is a major undertaking just the same in a large deployment. > > I don't see any major difference in the amount of work required to > go from disconnected ULA to ULA + PA/PI or ULA + NAT compared to > disconnected PI to connected PI. Whether the machines have one or > two address is inconsequential in the grand scheme of things. > If it's all SLAAC, you're right. Most people have some servers and some other machines that get static addresses. In those cases, those machines have to be touched to facilitate the transition if you start with ULA. If you start with GUA, then, it's just a matter of changing the firewall policies and the router filters, and, possibly some routes. >>>>> For private site interconnect, I'd think it more likely that the >>>>> provider would isolate the customers traffic and ULA address space = >> via >>>>> something like a VPN service e.g. MPLS, IPsec. >>>>> =20 >>>> One would hope, but, I bet laziness and misunderstanding trumps >>>> reason and adherence to RFCs over the long term. Since ULA >>>> won't get hard-coded into routers as unroutable (it can't), >>> =20 >>> Actually it can be. You just need a easy switch to turn it off. The >>> router can even work itself out many times. Configure multiple = >> interfaces >>> from the same ULA /48 and you pass traffic for the /48 between those >>> interfaces. You also pass routes for that /48 via those interfaces. >>> =20 >> If you have an easy switch to turn it off, it will get used, thus = >> meaning that >> it isn't hard coded, it's just default. > > On by default will create a effective deterrent. > We can agree to disagree about that. However, there's enough code out there already that isn't on by default that I think that ship has sailed. Owen From Serg at Macomnet.net Tue Oct 26 06:51:36 2010 From: Serg at Macomnet.net (Serg Shubenkov) Date: Tue, 26 Oct 2010 15:51:36 +0400 (MSD) Subject: DDOS attack via as702 87.118.210.122 Message-ID: <20101026154527.G38880@dry.macomnet.ru> Hello, list. Please send me off-list abuse contact for as702. -- Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department phone: +7 495 7969392/9079, +7 916 5316625, mailto:serg at macomnet.net icq uin: 101964103, Skype: serg.v.shubenkov From jack at crepinc.com Tue Oct 26 08:22:57 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 26 Oct 2010 09:22:57 -0400 Subject: DDOS attack via as702 87.118.210.122 In-Reply-To: <20101026154527.G38880@dry.macomnet.ru> References: <20101026154527.G38880@dry.macomnet.ru> Message-ID: Whois is hard, let's go shopping: jackc at anna ~ $ whois as701 # # The following results may also be obtained via: # http://whois.arin.net/rest/asns;q=as701?showDetails=true # ASNumber: 701 - 705 ASName: UUNET ASHandle: AS701 RegDate: 1990-08-03 Updated: 2008-07-24 Ref: http://whois.arin.net/rest/asn/AS701 OrgName: MCI Communications Services, Inc. d/b/a Verizon Business OrgId: MCICS Address: 22001 Loudoun County Pkwy City: Ashburn StateProv: VA PostalCode: 20147 Country: US RegDate: 2006-05-30 Updated: 2009-12-07 Ref: http://whois.arin.net/rest/org/MCICS OrgTechHandle: JHU140-ARIN OrgTechName: Huffines, Jody OrgTechPhone: +1-703-886-6093 OrgTechEmail: Jody.Huffines at verizonbusiness.com OrgTechRef: http://whois.arin.net/rest/poc/JHU140-ARIN OrgAbuseHandle: ABUSE3-ARIN OrgAbuseName: abuse OrgAbusePhone: +1-800-900-0241 OrgAbuseEmail: abuse-mail at verizonbusiness.com OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3-ARIN OrgNOCHandle: OA12-ARIN OrgNOCName: UUnet Technologies, Inc., Technologies OrgNOCPhone: +1-800-900-0241 OrgNOCEmail: help4u at verizonbusiness.com OrgNOCRef: http://whois.arin.net/rest/poc/OA12-ARIN OrgTechHandle: SWIPP-ARIN OrgTechName: swipper OrgTechPhone: +1-800-900-0241 OrgTechEmail: swipper at verizonbusiness.com OrgTechRef: http://whois.arin.net/rest/poc/SWIPP-ARIN -Jack Carrozzo On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov wrote: > > Hello, list. > > Please send me off-list abuse contact for as702. > > -- > Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department > phone: +7 495 7969392/9079, +7 916 5316625, mailto:serg at macomnet.net > icq uin: 101964103, Skype: serg.v.shubenkov > > > > From james.cutler at consultant.com Tue Oct 26 08:54:17 2010 From: james.cutler at consultant.com (Cutler James R) Date: Tue, 26 Oct 2010 09:54:17 -0400 Subject: DDOS attack via as702 87.118.210.122 In-Reply-To: References: <20101026154527.G38880@dry.macomnet.ru> Message-ID: Jack, I agree that whois is hard. Please explain how you knew to query AS701 when Serg asked about AS702. computer:~ me$ whois as702 No match for "AS702". >>> Last update of whois database: Tue, 26 Oct 2010 13:47:47 UTC <<< Regards. Cutler On Oct 26, 2010, at 9:22 AM, Jack Carrozzo wrote: > Whois is hard, let's go shopping: > > jackc at anna ~ $ whois as701 > > > -Jack Carrozzo > > On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov wrote: > >> >> Hello, list. >> >> Please send me off-list abuse contact for as702. >> >> -- >> Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department >> phone: +7 495 7969392/9079, +7 916 5316625, mailto:serg at macomnet.net >> icq uin: 101964103, Skype: serg.v.shubenkov >> >> >> >> James R. Cutler james.cutler at consultant.com From jbates at brightok.net Tue Oct 26 08:57:41 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 26 Oct 2010 08:57:41 -0500 Subject: IPv6 Routing table will be bloated? Message-ID: <4CC6DE55.7000901@brightok.net> So, the best that I can tell (still not through debating with RIR), the IPv6 routing table will see lots of bloat. Here's my reasoning so far: 1) RIR (ARIN in this case, don't know other RIR interpretations) only does initial assignments to barely cover the minimum. If you need more due to routing, you'll need to provide every pop, counts per pop, etc, to show how v6 will require more than just the minimums (full routing plan and customer counts to justify routing plan). HD-Ratio has NO bearing on initial allocation, and while policy dictates that it doesn't matter how an ISP assigns to customer so long as HD-Ratio is met, that is not the case when providing justification for the initial allocation. 2) Subsequent requests only double in size according to policy (so just keep going back over and over since HD is met immediately due to the minimalist initial assignment?) So I conclude that since I get a bare minimum, I can only assign a bare minimum. Since everything is quickly maxed out, I must request more (but only double), which in turn I can assign, but my customer assignments (Telcos/ISPs in this case) will be non-contiguous due to the limited available space I have to hand out. This will lead to IGP bloat, and in cases of multi-homed customers whom I provide address space for, BGP bloat. I'm small, so my bloat factor is small, but I can quickly see this developing exactly as my v4 network did (if it was years ago when I first got my v4 allocation, growing to today, for each allocation I got for v4, I'd expect similar out of v6). Sure, the end user gets loads of space with those nice /48's, but the space within ISPs and their ISP customers is force limited by initial allocations which will create fragmentation of address space. This is brought about due to the dual standard of initial vs subsequent allocations (just enough to cover existing vs HD Ratio). As an example, Using HD-Ratios as an initial assignment metric can warrant a /27, whereas the minimalist approach may only warrant a heavily utilized /30. 3 bits doesn't seem like much, but it's a huge difference in growth room. Bare minimums, as provided by me, only included the /24 IPv4 DHCP pools converted with a raw conversion as /32 IPv4 = /48 IPv6 network Am I missing something, or is this minimalist approach going to cause issues in BGP the same as v4 did? Jack From trejrco at gmail.com Tue Oct 26 09:06:58 2010 From: trejrco at gmail.com (TJ) Date: Tue, 26 Oct 2010 10:06:58 -0400 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC6DE55.7000901@brightok.net> References: <4CC6DE55.7000901@brightok.net> Message-ID: Quick comment: IGP bloat != BGP bloat. Your customers cannot announce the space you gave them externally - unless ~/32s, i.e. forced aggregation. Also, your customers shouldn't need to come back for more very often and ideally you have some reservations for them a well :). /TJ PS - apologies for top posting. On Oct 26, 2010 9:59 AM, "Jack Bates" wrote: > So, the best that I can tell (still not through debating with RIR), the > IPv6 routing table will see lots of bloat. Here's my reasoning so far: > > 1) RIR (ARIN in this case, don't know other RIR interpretations) only > does initial assignments to barely cover the minimum. If you need more > due to routing, you'll need to provide every pop, counts per pop, etc, > to show how v6 will require more than just the minimums (full routing > plan and customer counts to justify routing plan). HD-Ratio has NO > bearing on initial allocation, and while policy dictates that it doesn't > matter how an ISP assigns to customer so long as HD-Ratio is met, that > is not the case when providing justification for the initial allocation. > > 2) Subsequent requests only double in size according to policy (so just > keep going back over and over since HD is met immediately due to the > minimalist initial assignment?) > > So I conclude that since I get a bare minimum, I can only assign a bare > minimum. Since everything is quickly maxed out, I must request more (but > only double), which in turn I can assign, but my customer assignments > (Telcos/ISPs in this case) will be non-contiguous due to the limited > available space I have to hand out. This will lead to IGP bloat, and in > cases of multi-homed customers whom I provide address space for, BGP bloat. > > I'm small, so my bloat factor is small, but I can quickly see this > developing exactly as my v4 network did (if it was years ago when I > first got my v4 allocation, growing to today, for each allocation I got > for v4, I'd expect similar out of v6). Sure, the end user gets loads of > space with those nice /48's, but the space within ISPs and their ISP > customers is force limited by initial allocations which will create > fragmentation of address space. This is brought about due to the dual > standard of initial vs subsequent allocations (just enough to cover > existing vs HD Ratio). > > As an example, Using HD-Ratios as an initial assignment metric can > warrant a /27, whereas the minimalist approach may only warrant a > heavily utilized /30. 3 bits doesn't seem like much, but it's a huge > difference in growth room. Bare minimums, as provided by me, only > included the /24 IPv4 DHCP pools converted with a raw conversion as /32 > IPv4 = /48 IPv6 network > > Am I missing something, or is this minimalist approach going to cause > issues in BGP the same as v4 did? > > > Jack > From adrian at creative.net.au Tue Oct 26 09:07:18 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Tue, 26 Oct 2010 22:07:18 +0800 Subject: DDOS attack via as702 87.118.210.122 In-Reply-To: References: <20101026154527.G38880@dry.macomnet.ru> Message-ID: <20101026140718.GH19110@skywalker.creative.net.au> On Tue, Oct 26, 2010, Cutler James R wrote: > Jack, > > I agree that whois is hard. Please explain how you knew to query AS701 when Serg asked about AS702. Brainfart. I understand why people confuse 701 with 702. $ whois -h whois.ripe.net AS702 % Information related to 'AS702' aut-num: AS702 as-name: AS702 descr: Verizon Business EMEA - Commercial IP service provider in Europe ... Adrian > > computer:~ me$ whois as702 > > No match for "AS702". > >>> Last update of whois database: Tue, 26 Oct 2010 13:47:47 UTC <<< > > Regards. > > Cutler > > On Oct 26, 2010, at 9:22 AM, Jack Carrozzo wrote: > > > Whois is hard, let's go shopping: > > > > jackc at anna ~ $ whois as701 > > > > > > -Jack Carrozzo > > > > On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov wrote: > > > >> > >> Hello, list. > >> > >> Please send me off-list abuse contact for as702. > >> > >> -- > >> Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department > >> phone: +7 495 7969392/9079, +7 916 5316625, mailto:serg at macomnet.net > >> icq uin: 101964103, Skype: serg.v.shubenkov > >> > >> > >> > >> > > James R. Cutler > james.cutler at consultant.com > > > > -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA - From jeroen at unfix.org Tue Oct 26 09:08:15 2010 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 26 Oct 2010 16:08:15 +0200 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC6DE55.7000901@brightok.net> References: <4CC6DE55.7000901@brightok.net> Message-ID: <4CC6E0CF.5090109@unfix.org> On 2010-10-26 15:57, Jack Bates wrote: [..] > Am I missing something, or is this minimalist approach going to cause > issues in BGP the same as v4 did? You are missing the point of making a proper plan which can justify address space for your business for the next years. If done properly, you have successfully justified it and you will never ever have to go back to any of the five years. Now what will cause routing bloat is folks who keep on doing the same methods of "load balancing" and "chunking out of PA" and announcing that in BGP. Oh and then there are of course the various organizations who do not know/understand what RPSL is and who do not understand what filtering and aggregation means... Greets, Jeroen From jackson.tim at gmail.com Tue Oct 26 09:09:07 2010 From: jackson.tim at gmail.com (Tim Jackson) Date: Tue, 26 Oct 2010 09:09:07 -0500 Subject: DDOS attack via as702 87.118.210.122 In-Reply-To: References: <20101026154527.G38880@dry.macomnet.ru> Message-ID: Whois really isn't that hard.... Maybe reading: ASNumber: 701 - 705 is though.. tim at shitbox:/var/log$ whois a 702 -h whois.arin.net # # The following results may also be obtained via: # http://whois.arin.net/rest/asns;q=702?showDetails=true # ASNumber: 701 - 705 ASName: UUNET ASHandle: AS701 RegDate: 1990-08-03 Updated: 2008-07-24 Ref: http://whois.arin.net/rest/asn/AS701 OrgName: MCI Communications Services, Inc. d/b/a Verizon Business OrgId: MCICS Address: 22001 Loudoun County Pkwy City: Ashburn StateProv: VA PostalCode: 20147 Country: US RegDate: 2006-05-30 Updated: 2009-12-07 Ref: http://whois.arin.net/rest/org/MCICS OrgTechHandle: JHU140-ARIN OrgTechName: Huffines, Jody OrgTechPhone: +1-703-886-6093 OrgTechEmail: Jody.Huffines at verizonbusiness.com OrgTechRef: http://whois.arin.net/rest/poc/JHU140-ARIN OrgNOCHandle: OA12-ARIN OrgNOCName: UUnet Technologies, Inc., Technologies OrgNOCPhone: +1-800-900-0241 OrgNOCEmail: help4u at verizonbusiness.com OrgNOCRef: http://whois.arin.net/rest/poc/OA12-ARIN OrgTechHandle: SWIPP-ARIN OrgTechName: swipper OrgTechPhone: +1-800-900-0241 OrgTechEmail: swipper at verizonbusiness.com OrgTechRef: http://whois.arin.net/rest/poc/SWIPP-ARIN OrgAbuseHandle: ABUSE3-ARIN OrgAbuseName: abuse OrgAbusePhone: +1-800-900-0241 OrgAbuseEmail: abuse-mail at verizonbusiness.com OrgAbuseRef: http://whois.arin.net/rest/poc/ABUSE3-ARIN # # ARIN WHOIS data and services are subject to the Terms of Use # available at: https://www.arin.net/whois_tou.html # On Tue, Oct 26, 2010 at 8:54 AM, Cutler James R wrote: > Jack, > > I agree that whois is hard. Please explain how you knew to query AS701 when Serg asked about AS702. > > computer:~ me$ whois as702 > > No match for "AS702". >>>> Last update of whois database: Tue, 26 Oct 2010 13:47:47 UTC <<< > > Regards. > > ? ? ? ?Cutler From lists at internetpolicyagency.com Tue Oct 26 09:08:50 2010 From: lists at internetpolicyagency.com (Roland Perry) Date: Tue, 26 Oct 2010 15:08:50 +0100 Subject: Tools for teaching users online safety In-Reply-To: <4CC62B29.4040104@blastro.com> References: <4CC62B29.4040104@blastro.com> Message-ID: In article <4CC62B29.4040104 at blastro.com>, Alex Thurlow writes >I'm trying to find out if there are currently any resources available >for teaching people how to be safe online. As in, how to not get a >virus, how to pick out phishing emails, how to recognize scams. I'm >sure everyone on this list knows these things, but a lot of end users >don't. I'm trying to find a way to teach these things to people who >aren't too technically savvy. There's quite a bit of information (UK-orientated) at www.e-victims.org, which was intended to cover a wide range of issues but after three years of operation is now focussing on anti-social behaviour rather than scams. But there's a quite a lot of material there about avoiding scams, and advice on what to do if you've been caught. The generic preventative advice is mainly aimed at teenagers. Disclaimer: I'm related to the owner. -- Roland Perry From jbates at brightok.net Tue Oct 26 09:12:25 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 26 Oct 2010 09:12:25 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC6E0CF.5090109@unfix.org> References: <4CC6DE55.7000901@brightok.net> <4CC6E0CF.5090109@unfix.org> Message-ID: <4CC6E1C9.90401@brightok.net> On 10/26/2010 9:08 AM, Jeroen Massar wrote: > You are missing the point of making a proper plan which can justify > address space for your business for the next years. According to ARIN, initial allocations due NOT allot for growth, only for the existing infrastructure. > If done properly, you have successfully justified it and you will never > ever have to go back to any of the five years. > I'd have to lie about existing counts to plan for 5 years. I don't like lying. > Now what will cause routing bloat is folks who keep on doing the same > methods of "load balancing" and "chunking out of PA" and announcing that > in BGP. > I have customers who use my space and multihome. There is no reason or requirement for them to go to ARIN for this space. They can easily use my own. Ideally they would have (and I would have) large enough space for a single aggregate leaving their network, but with a minimal approach (vs HD-Ratio aligned assignment up front), that won't be possible. Jack From jack at crepinc.com Tue Oct 26 09:12:58 2010 From: jack at crepinc.com (Jack Carrozzo) Date: Tue, 26 Oct 2010 10:12:58 -0400 Subject: DDOS attack via as702 87.118.210.122 In-Reply-To: <20101026140718.GH19110@skywalker.creative.net.au> References: <20101026154527.G38880@dry.macomnet.ru> <20101026140718.GH19110@skywalker.creative.net.au> Message-ID: Well, I whois'd 702, got no match, said "hm, I see 701 all over the place, lemmy take a look" and found: ASNumber: 701 - 705 ASName: UUNET etc. Sorry, it was left as an exercise to the reader - didn't mean to be flippant. -Jack CArrozzo On Tue, Oct 26, 2010 at 10:07 AM, Adrian Chadd wrote: > On Tue, Oct 26, 2010, Cutler James R wrote: > > Jack, > > > > I agree that whois is hard. Please explain how you knew to query AS701 > when Serg asked about AS702. > > Brainfart. I understand why people confuse 701 with 702. > > $ whois -h whois.ripe.net AS702 > > % Information related to 'AS702' > > aut-num: AS702 > as-name: AS702 > descr: Verizon Business EMEA - Commercial IP service provider in > Europe > > ... > > > > Adrian > > > > > > computer:~ me$ whois as702 > > > > No match for "AS702". > > >>> Last update of whois database: Tue, 26 Oct 2010 13:47:47 UTC <<< > > > > Regards. > > > > Cutler > > > > On Oct 26, 2010, at 9:22 AM, Jack Carrozzo wrote: > > > > > Whois is hard, let's go shopping: > > > > > > jackc at anna ~ $ whois as701 > > > > > > > > > -Jack Carrozzo > > > > > > On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov > wrote: > > > > > >> > > >> Hello, list. > > >> > > >> Please send me off-list abuse contact for as702. > > >> > > >> -- > > >> Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department > > >> phone: +7 495 7969392/9079, +7 916 5316625, mailto:serg at macomnet.net > > >> icq uin: 101964103, Skype: serg.v.shubenkov > > >> > > >> > > >> > > >> > > > > James R. Cutler > > james.cutler at consultant.com > > > > > > > > > > -- > - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid > Support - > - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA > - > > From jbates at brightok.net Tue Oct 26 09:15:06 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 26 Oct 2010 09:15:06 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <4CC6DE55.7000901@brightok.net> Message-ID: <4CC6E26A.4010909@brightok.net> On 10/26/2010 9:06 AM, TJ wrote: > Quick comment: > IGP bloat != BGP bloat. Your customers cannot announce the space you > gave them externally - unless ~/32s, i.e. forced aggregation. > Still waiting on ARIN to get back to my argument that I am allowed to assign /32s to my subtending ISPs who are of X size or are multihomed. > Also, your customers shouldn't need to come back for more very often and > ideally you have some reservations for them a well :). If the initial allocation from ARIN is only for current infrastructure and customers (the bare minimum), there is no room for reservation, nor will customers have room to grow in the initial allocation. This is the problem with minimal on initial instead of HD-Ratio (which is what the rest of the policy is based on), but it could lead to fragmented networks. Jack From Steve.Adcock at ioko.com Tue Oct 26 09:18:29 2010 From: Steve.Adcock at ioko.com (Steve Adcock) Date: Tue, 26 Oct 2010 15:18:29 +0100 Subject: DDOS attack via as702 87.118.210.122 In-Reply-To: References: <20101026154527.G38880@dry.macomnet.ru> Message-ID: Must admit I thought what Jack supplied said between AS 701 - 705 which is MCI/Verizon and correct? ASNumber: 701 - 705 ASName: UUNET ASHandle: AS701 RegDate: 1990-08-03 Updated: 2008-07-24 Ref: http://whois.arin.net/rest/asn/AS701 If you done some manual work like a bit of ripe/cidr-report and used network tools for a whois you would get the answer. Cheers Steven -----Original Message----- From: Cutler James R [mailto:james.cutler at consultant.com] Sent: 26 October 2010 14:54 To: nanog at merit.edu Subject: Re: DDOS attack via as702 87.118.210.122 Jack, I agree that whois is hard. Please explain how you knew to query AS701 when Serg asked about AS702. computer:~ me$ whois as702 No match for "AS702". >>> Last update of whois database: Tue, 26 Oct 2010 13:47:47 UTC <<< Regards. Cutler On Oct 26, 2010, at 9:22 AM, Jack Carrozzo wrote: > Whois is hard, let's go shopping: > > jackc at anna ~ $ whois as701 > > > -Jack Carrozzo > > On Tue, Oct 26, 2010 at 7:51 AM, Serg Shubenkov wrote: > >> >> Hello, list. >> >> Please send me off-list abuse contact for as702. >> >> -- >> Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department >> phone: +7 495 7969392/9079, +7 916 5316625, mailto:serg at macomnet.net >> icq uin: 101964103, Skype: serg.v.shubenkov >> >> >> >> James R. Cutler james.cutler at consultant.com -------------- next part -------------- An embedded message was scrubbed... From: Jack Carrozzo Subject: Re: DDOS attack via as702 87.118.210.122 Date: Tue, 26 Oct 2010 14:22:57 +0100 Size: 5487 URL: From pfunix at gmail.com Tue Oct 26 09:19:18 2010 From: pfunix at gmail.com (Beavis) Date: Tue, 26 Oct 2010 08:19:18 -0600 Subject: DDOS attack via as702 87.118.210.122 In-Reply-To: <20101026154527.G38880@dry.macomnet.ru> References: <20101026154527.G38880@dry.macomnet.ru> Message-ID: whois on 702(Verizon) http://www.robtex.com/as/as702.html goodluck. On Tue, Oct 26, 2010 at 5:51 AM, Serg Shubenkov wrote: > > Hello, list. > > Please send me off-list abuse contact for as702. > > -- > Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department > phone: +7 495 7969392/9079, +7 916 5316625, mailto:serg at macomnet.net > icq uin: 101964103, Skype: serg.v.shubenkov > > > > -- ()? ascii ribbon campaign - against html e-mail /\? www.asciiribbon.org?? - against proprietary attachments From cgrundemann at gmail.com Tue Oct 26 10:14:14 2010 From: cgrundemann at gmail.com (Chris Grundemann) Date: Tue, 26 Oct 2010 09:14:14 -0600 Subject: Tools for teaching users online safety In-Reply-To: <4CC62B29.4040104@blastro.com> References: <4CC62B29.4040104@blastro.com> Message-ID: On Mon, Oct 25, 2010 at 19:13, Alex Thurlow wrote: > I'm trying to find out if there are currently any resources available for > teaching people how to be safe online. ?As in, how to not get a virus, how > to pick out phishing emails, how to recognize scams. ?I'm sure everyone on > this list knows these things, but a lot of end users don't. ?I'm trying to > find a way to teach these things to people who aren't too technically savvy. > > It seems to me that the fewer end users that have issues, the easier our > lives will be. > > So what I'm trying to figure out is, is there a good site or set of sites > for this stuff, or is there anyone out there interested in helping to build > a unified list of instructions, videos, etc. for all this? The Colorado Chapter of the Internet Society (CO ISOC) is in the process of launching a project to do just that. We are calling it (fairly obviously) the Internet User Best Common Practices. As stated on the project's wiki landing page (http://wiki.coisoc.org/index.php/UserBCP): The idea is to start here on the wiki by gathering and creating a repository of information on how to be a good Netizen. That is, how to be a safe and responsible Internet user. We want to use this information, once gathered and verified, to create simple and accessible resources for the general population. I invite you and everyone who reads this to participate, all input is welcome! Thanks, ~Chris (founding chair, CO ISOC) > -- > Alex Thurlow > Blastro Networks > > http://www.blastro.com > http://www.roxwel.com > http://www.yallwire.com > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.coisoc.org From fweimer at bfk.de Tue Oct 26 10:20:27 2010 From: fweimer at bfk.de (Florian Weimer) Date: Tue, 26 Oct 2010 15:20:27 +0000 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC6DE55.7000901@brightok.net> (Jack Bates's message of "Tue\, 26 Oct 2010 08\:57\:41 -0500") References: <4CC6DE55.7000901@brightok.net> Message-ID: <82k4l5q8uc.fsf@mid.bfk.de> * Jack Bates: > So, the best that I can tell (still not through debating with RIR), > the IPv6 routing table will see lots of bloat. Here's my reasoning so > far: > > 1) RIR (ARIN in this case, don't know other RIR interpretations) only > does initial assignments to barely cover the minimum. If you need more > due to routing, you'll need to provide every pop, counts per pop, etc, > to show how v6 will require more than just the minimums (full routing > plan and customer counts to justify routing plan). If you get better routing and reachability from not filtering at the /32 boundary, network operators will stop filtering at the /32 boundary. So this issue will likely go away pretty soon because you can use our initial assignment to gain the routing flexibility you need. -- 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 harbor235 at gmail.com Tue Oct 26 10:46:43 2010 From: harbor235 at gmail.com (harbor235) Date: Tue, 26 Oct 2010 11:46:43 -0400 Subject: Cell sites Message-ID: I am hoping someone can guide me to a internet resource that provides information on newly contstructed cell sites and what provider they are affiliated with? I did some google fu and found a couple sites like antennasearch,towersource etc .... still no joy, in all cases this new tower does not exist. thanx in advance, harbor235 ;} From nick at brevardwireless.com Tue Oct 26 10:53:02 2010 From: nick at brevardwireless.com (Nick Olsen) Date: Tue, 26 Oct 2010 11:53:02 -0400 Subject: Cell sites Message-ID: <46def66b$496a4318$1fb10752$@com> Well, I'm not sure if there is a database of who is actually colo'ed on a tower. But as for who a tower is owned by, The FCC database works. They also have a cool google earth file that will show you the location of all of them http://www.fccinfo.com/fccinfo_google_earth.php Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "harbor235" Sent: Tuesday, October 26, 2010 11:47 AM To: "NANOG list" Subject: Cell sites I am hoping someone can guide me to a internet resource that provides information on newly contstructed cell sites and what provider they are affiliated with? I did some google fu and found a couple sites like antennasearch,towersource etc .... still no joy, in all cases this new tower does not exist. thanx in advance, harbor235 ;} From alh-ietf at tndh.net Tue Oct 26 11:02:00 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 26 Oct 2010 09:02:00 -0700 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC6DE55.7000901@brightok.net> References: <4CC6DE55.7000901@brightok.net> Message-ID: <021601cb7527$22320970$66961c50$@net> You didn't miss anything, past ARIN practice has been broken, though using sparse allocation it is not quite as bad as you project. In any case, ISP's with more than 10k customers should NEVER get a /32, yet that is what ARIN insisted on giving even the largest providers in the region. Every ISP should go back to ARIN, turn in the lame /32 nonsense they were given (that allocation size is for a startup ISP with 0 customers), follow that with an 'initial allocation' request that is based on your pop structure with a /48 per customer including projected growth. I don't care what you actually allocate to your customers at this point, just get a large enough block to begin with that you could give everyone a /48 the way policy allows. There is absolutely no reason to have to grovel at ARIN's feet every few months as you grow your IPv6 deployment. Get a 'real block' up front. Tony > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > Sent: Tuesday, October 26, 2010 6:58 AM > To: nanog at nanog.org > Subject: IPv6 Routing table will be bloated? > > So, the best that I can tell (still not through debating with RIR), the > IPv6 routing table will see lots of bloat. Here's my reasoning so far: > > 1) RIR (ARIN in this case, don't know other RIR interpretations) only > does initial assignments to barely cover the minimum. If you need more > due to routing, you'll need to provide every pop, counts per pop, etc, > to show how v6 will require more than just the minimums (full routing > plan and customer counts to justify routing plan). HD-Ratio has NO > bearing on initial allocation, and while policy dictates that it > doesn't > matter how an ISP assigns to customer so long as HD-Ratio is met, that > is not the case when providing justification for the initial > allocation. > > 2) Subsequent requests only double in size according to policy (so just > keep going back over and over since HD is met immediately due to the > minimalist initial assignment?) > > So I conclude that since I get a bare minimum, I can only assign a bare > minimum. Since everything is quickly maxed out, I must request more > (but > only double), which in turn I can assign, but my customer assignments > (Telcos/ISPs in this case) will be non-contiguous due to the limited > available space I have to hand out. This will lead to IGP bloat, and in > cases of multi-homed customers whom I provide address space for, BGP > bloat. > > I'm small, so my bloat factor is small, but I can quickly see this > developing exactly as my v4 network did (if it was years ago when I > first got my v4 allocation, growing to today, for each allocation I got > for v4, I'd expect similar out of v6). Sure, the end user gets loads of > space with those nice /48's, but the space within ISPs and their ISP > customers is force limited by initial allocations which will create > fragmentation of address space. This is brought about due to the dual > standard of initial vs subsequent allocations (just enough to cover > existing vs HD Ratio). > > As an example, Using HD-Ratios as an initial assignment metric can > warrant a /27, whereas the minimalist approach may only warrant a > heavily utilized /30. 3 bits doesn't seem like much, but it's a huge > difference in growth room. Bare minimums, as provided by me, only > included the /24 IPv4 DHCP pools converted with a raw conversion as /32 > IPv4 = /48 IPv6 network > > Am I missing something, or is this minimalist approach going to cause > issues in BGP the same as v4 did? > > > Jack From jordi.palet at consulintel.es Tue Oct 26 11:10:08 2010 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Tue, 26 Oct 2010 11:10:08 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: <021601cb7527$22320970$66961c50$@net> Message-ID: Totally agree. In IPv6, polices are in some RIRs and MUST be in all them, balancing conservation and aggregation, but in case of conflict aggregation is the top priority. I can read it at the NRPM: 6.3.8. Conflict of goals The goals described above will often conflict with each other, or with the needs of individual IRs or end users. All IRs evaluating requests for allocations and assignments must make judgments, seeking to balance the needs of the applicant with the needs of the Internet community as a whole. In IPv6 address policy, the goal of aggregation is considered to be the most important. Regards, Jordi > From: Tony Hain > Reply-To: > Date: Tue, 26 Oct 2010 09:02:00 -0700 > To: 'Jack Bates' , > Subject: RE: IPv6 Routing table will be bloated? > > You didn't miss anything, past ARIN practice has been broken, though using > sparse allocation it is not quite as bad as you project. In any case, ISP's > with more than 10k customers should NEVER get a /32, yet that is what ARIN > insisted on giving even the largest providers in the region. Every ISP > should go back to ARIN, turn in the lame /32 nonsense they were given (that > allocation size is for a startup ISP with 0 customers), follow that with an > 'initial allocation' request that is based on your pop structure with a /48 > per customer including projected growth. I don't care what you actually > allocate to your customers at this point, just get a large enough block to > begin with that you could give everyone a /48 the way policy allows. There > is absolutely no reason to have to grovel at ARIN's feet every few months as > you grow your IPv6 deployment. Get a 'real block' up front. > > Tony > > >> -----Original Message----- >> From: Jack Bates [mailto:jbates at brightok.net] >> Sent: Tuesday, October 26, 2010 6:58 AM >> To: nanog at nanog.org >> Subject: IPv6 Routing table will be bloated? >> >> So, the best that I can tell (still not through debating with RIR), the >> IPv6 routing table will see lots of bloat. Here's my reasoning so far: >> >> 1) RIR (ARIN in this case, don't know other RIR interpretations) only >> does initial assignments to barely cover the minimum. If you need more >> due to routing, you'll need to provide every pop, counts per pop, etc, >> to show how v6 will require more than just the minimums (full routing >> plan and customer counts to justify routing plan). HD-Ratio has NO >> bearing on initial allocation, and while policy dictates that it >> doesn't >> matter how an ISP assigns to customer so long as HD-Ratio is met, that >> is not the case when providing justification for the initial >> allocation. >> >> 2) Subsequent requests only double in size according to policy (so just >> keep going back over and over since HD is met immediately due to the >> minimalist initial assignment?) >> >> So I conclude that since I get a bare minimum, I can only assign a bare >> minimum. Since everything is quickly maxed out, I must request more >> (but >> only double), which in turn I can assign, but my customer assignments >> (Telcos/ISPs in this case) will be non-contiguous due to the limited >> available space I have to hand out. This will lead to IGP bloat, and in >> cases of multi-homed customers whom I provide address space for, BGP >> bloat. >> >> I'm small, so my bloat factor is small, but I can quickly see this >> developing exactly as my v4 network did (if it was years ago when I >> first got my v4 allocation, growing to today, for each allocation I got >> for v4, I'd expect similar out of v6). Sure, the end user gets loads of >> space with those nice /48's, but the space within ISPs and their ISP >> customers is force limited by initial allocations which will create >> fragmentation of address space. This is brought about due to the dual >> standard of initial vs subsequent allocations (just enough to cover >> existing vs HD Ratio). >> >> As an example, Using HD-Ratios as an initial assignment metric can >> warrant a /27, whereas the minimalist approach may only warrant a >> heavily utilized /30. 3 bits doesn't seem like much, but it's a huge >> difference in growth room. Bare minimums, as provided by me, only >> included the /24 IPv4 DHCP pools converted with a raw conversion as /32 >> IPv4 = /48 IPv6 network >> >> Am I missing something, or is this minimalist approach going to cause >> issues in BGP the same as v4 did? >> >> >> Jack > > ********************************************** The IPv6 Portal: http://www.ipv6tf.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owen at delong.com Tue Oct 26 11:23:28 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Oct 2010 09:23:28 -0700 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <4CC6DE55.7000901@brightok.net> Message-ID: On Oct 26, 2010, at 7:06 AM, TJ wrote: > Quick comment: > IGP bloat != BGP bloat. Your customers cannot announce the space you gave > them externally - unless ~/32s, i.e. forced aggregation. > He's talking about the bloat that comes from ISPs getting slow-started and then only being able to increase their network in increments of 2x each time, so, effectively ISP gets: 1 x /32 Initial Fills that up, gets 1 x /32 First subsequent Then 1 x /31 then 1 x /30 etc. Probably not quite as bad as IPv4, but, potentially close. > Also, your customers shouldn't need to come back for more very often and > ideally you have some reservations for them a well :). > Consider the scenario where you're dealing with an ISP that provides services to other ISPs as his downstream customers and the above statement doesn't hold true like you think it should. Owen > /TJ > PS - apologies for top posting. > On Oct 26, 2010 9:59 AM, "Jack Bates" wrote: >> So, the best that I can tell (still not through debating with RIR), the >> IPv6 routing table will see lots of bloat. Here's my reasoning so far: >> >> 1) RIR (ARIN in this case, don't know other RIR interpretations) only >> does initial assignments to barely cover the minimum. If you need more >> due to routing, you'll need to provide every pop, counts per pop, etc, >> to show how v6 will require more than just the minimums (full routing >> plan and customer counts to justify routing plan). HD-Ratio has NO >> bearing on initial allocation, and while policy dictates that it doesn't >> matter how an ISP assigns to customer so long as HD-Ratio is met, that >> is not the case when providing justification for the initial allocation. >> >> 2) Subsequent requests only double in size according to policy (so just >> keep going back over and over since HD is met immediately due to the >> minimalist initial assignment?) >> >> So I conclude that since I get a bare minimum, I can only assign a bare >> minimum. Since everything is quickly maxed out, I must request more (but >> only double), which in turn I can assign, but my customer assignments >> (Telcos/ISPs in this case) will be non-contiguous due to the limited >> available space I have to hand out. This will lead to IGP bloat, and in >> cases of multi-homed customers whom I provide address space for, BGP > bloat. >> >> I'm small, so my bloat factor is small, but I can quickly see this >> developing exactly as my v4 network did (if it was years ago when I >> first got my v4 allocation, growing to today, for each allocation I got >> for v4, I'd expect similar out of v6). Sure, the end user gets loads of >> space with those nice /48's, but the space within ISPs and their ISP >> customers is force limited by initial allocations which will create >> fragmentation of address space. This is brought about due to the dual >> standard of initial vs subsequent allocations (just enough to cover >> existing vs HD Ratio). >> >> As an example, Using HD-Ratios as an initial assignment metric can >> warrant a /27, whereas the minimalist approach may only warrant a >> heavily utilized /30. 3 bits doesn't seem like much, but it's a huge >> difference in growth room. Bare minimums, as provided by me, only >> included the /24 IPv4 DHCP pools converted with a raw conversion as /32 >> IPv4 = /48 IPv6 network >> >> Am I missing something, or is this minimalist approach going to cause >> issues in BGP the same as v4 did? >> >> >> Jack >> From rsk at gsp.org Tue Oct 26 11:41:10 2010 From: rsk at gsp.org (Rich Kulawiec) Date: Tue, 26 Oct 2010 12:41:10 -0400 Subject: Cell sites In-Reply-To: References: Message-ID: <20101026164110.GA24751@gsp.org> You may find this site helpful: http://www.cellreception.com/towers/ ---rsk From michael.holstein at csuohio.edu Tue Oct 26 11:46:29 2010 From: michael.holstein at csuohio.edu (Michael Holstein) Date: Tue, 26 Oct 2010 12:46:29 -0400 Subject: Cell sites In-Reply-To: References: Message-ID: <4CC705E5.9000302@csuohio.edu> > I am hoping someone can guide me to a internet resource that provides > information > on newly contstructed cell sites and what provider they are affiliated with? > http://wireless2.fcc.gov/UlsApp/UlsSearch/searchGeographic.jsp You can do a coordinate search among other things. Note .. this will tell you who has radios on the tower. If it's an empty steel mast, it doesn't need to be in the FCC license database. Depending on how tall it as and/or proximity to airports, it might also be here (FAA required registrations) even if it's empty : http://wireless2.fcc.gov/UlsApp/AsrSearch/towairSearch.jsp Regards, Michael Holstein Cleveland State University From sven at cb3rob.net Tue Oct 26 11:52:51 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 26 Oct 2010 16:52:51 +0000 (UTC) Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <4CC6DE55.7000901@brightok.net> Message-ID: dusty old routers with ram problems... solution there: re-think the way you do your routing and compare the price of ram versus cpu cycles. (as well as having custom hardware developed to do it on, intel simply does not offer enough address bus lines to maintain bigass tables and address them linearily so you can keep entries for each ip or mac address out there and counters with them to automatically "migitate" ddos attacks and give every communications partner their own fair share on the outgoing interface's capacity). (and no, we're not talking linux/bsd here... just dedicated routing firmware on let's say ibm's power-6/power-7 platform) instead of buying the same old shit from juniper/cisco/foundry again which doesn't even have enough ram to announce /30's ipv4 (if everyone would do so ;), let alone properly prevent ddos attacks from even being possible -- 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 ========================================================================= 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. On Tue, 26 Oct 2010, Owen DeLong wrote: > > On Oct 26, 2010, at 7:06 AM, TJ wrote: > >> Quick comment: >> IGP bloat != BGP bloat. Your customers cannot announce the space you gave >> them externally - unless ~/32s, i.e. forced aggregation. >> > He's talking about the bloat that comes from ISPs getting slow-started and then > only being able to increase their network in increments of 2x each time, so, > effectively ISP gets: > > 1 x /32 Initial > Fills that up, gets > 1 x /32 First subsequent > Then > 1 x /31 > then > 1 x /30 > etc. > > Probably not quite as bad as IPv4, but, potentially close. > >> Also, your customers shouldn't need to come back for more very often and >> ideally you have some reservations for them a well :). >> > Consider the scenario where you're dealing with an ISP that provides > services to other ISPs as his downstream customers and the above > statement doesn't hold true like you think it should. > > Owen > >> /TJ >> PS - apologies for top posting. >> On Oct 26, 2010 9:59 AM, "Jack Bates" wrote: >>> So, the best that I can tell (still not through debating with RIR), the >>> IPv6 routing table will see lots of bloat. Here's my reasoning so far: >>> >>> 1) RIR (ARIN in this case, don't know other RIR interpretations) only >>> does initial assignments to barely cover the minimum. If you need more >>> due to routing, you'll need to provide every pop, counts per pop, etc, >>> to show how v6 will require more than just the minimums (full routing >>> plan and customer counts to justify routing plan). HD-Ratio has NO >>> bearing on initial allocation, and while policy dictates that it doesn't >>> matter how an ISP assigns to customer so long as HD-Ratio is met, that >>> is not the case when providing justification for the initial allocation. >>> >>> 2) Subsequent requests only double in size according to policy (so just >>> keep going back over and over since HD is met immediately due to the >>> minimalist initial assignment?) >>> >>> So I conclude that since I get a bare minimum, I can only assign a bare >>> minimum. Since everything is quickly maxed out, I must request more (but >>> only double), which in turn I can assign, but my customer assignments >>> (Telcos/ISPs in this case) will be non-contiguous due to the limited >>> available space I have to hand out. This will lead to IGP bloat, and in >>> cases of multi-homed customers whom I provide address space for, BGP >> bloat. >>> >>> I'm small, so my bloat factor is small, but I can quickly see this >>> developing exactly as my v4 network did (if it was years ago when I >>> first got my v4 allocation, growing to today, for each allocation I got >>> for v4, I'd expect similar out of v6). Sure, the end user gets loads of >>> space with those nice /48's, but the space within ISPs and their ISP >>> customers is force limited by initial allocations which will create >>> fragmentation of address space. This is brought about due to the dual >>> standard of initial vs subsequent allocations (just enough to cover >>> existing vs HD Ratio). >>> >>> As an example, Using HD-Ratios as an initial assignment metric can >>> warrant a /27, whereas the minimalist approach may only warrant a >>> heavily utilized /30. 3 bits doesn't seem like much, but it's a huge >>> difference in growth room. Bare minimums, as provided by me, only >>> included the /24 IPv4 DHCP pools converted with a raw conversion as /32 >>> IPv4 = /48 IPv6 network >>> >>> Am I missing something, or is this minimalist approach going to cause >>> issues in BGP the same as v4 did? >>> >>> >>> Jack >>> > > From nick at foobar.org Tue Oct 26 12:04:08 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 26 Oct 2010 18:04:08 +0100 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <4CC6DE55.7000901@brightok.net> Message-ID: <4CC70A08.2060304@foobar.org> On 26/10/2010 17:23, Owen DeLong wrote: > He's talking about the bloat that comes from ISPs getting slow-started and then > only being able to increase their network in increments of 2x each time, so, > effectively ISP gets: [...] > Probably not quite as bad as IPv4, but, potentially close. In theory, yes, it's bad. In practice, the RIRs are implementing sparse allocation which makes it possible to aggregate subsequent allocations. I.e. not as bad as it may seem. ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if you get an initial allocation of /32, then find you need more, your subsequent allocations will be taken from the same /29, allowing aggregation up to /29. APNIC seem to be delegating on /22 boundaries, and LACNIC on /28. Nick From jbates at brightok.net Tue Oct 26 12:19:30 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 26 Oct 2010 12:19:30 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC70A08.2060304@foobar.org> References: <4CC6DE55.7000901@brightok.net> <4CC70A08.2060304@foobar.org> Message-ID: <4CC70DA2.6020906@brightok.net> On 10/26/2010 12:04 PM, Nick Hilliard wrote: > In practice, the RIRs are implementing sparse allocation which makes it > possible to aggregate subsequent allocations. I.e. not as bad as it may > seem. > Except, if you are given bare minimums, and you are assigning out to subtending ISPs bare minimums, those subtending ISPs will end up with multiple networks. Some of them are BGP speakers. I can't use sparse allocation because I was given minimum space and not the HD-Ratio threshold space. > ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if > you get an initial allocation of /32, then find you need more, your > subsequent allocations will be taken from the same /29, allowing > aggregation up to /29. > My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To not be given the threshold space means no reservations for subtending ISPs, no room for subtending ISPs to grow, and multiple assignments. If ARIN only does /29 boundaries, I'll also be getting multiple /29's, and not just working within a /27 per the HD-Ratio guidelines. It's the mixed viewpoint that is the problem. HD-Ratio is useless as a justification and as a metric which promotes route conservation/aggregation if it is not used for initial allocations. Initial allocations (including those handed out to subtending ISPs) should all be as large as the immediate use HD Ratio permits. ie, If you are immediately assigning X /56 blocks, your assignment should have a length one less than the highest threshold you crossed. To assign any less is to constrain the assignments, not allow for growth, and to increase routing table size. It also circumvents and completely destroys the concept of HD Ratio (as the initial assignments all are well in excess of the thresholds for requesting much larger blocks). Jack From nick at foobar.org Tue Oct 26 12:22:22 2010 From: nick at foobar.org (Nick Hilliard) Date: Tue, 26 Oct 2010 18:22:22 +0100 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC70DA2.6020906@brightok.net> References: <4CC6DE55.7000901@brightok.net> <4CC70A08.2060304@foobar.org> <4CC70DA2.6020906@brightok.net> Message-ID: <4CC70E4E.8060401@foobar.org> On 26/10/2010 18:19, Jack Bates wrote: > My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To not > be given the threshold space means no reservations for subtending ISPs, no > room for subtending ISPs to grow, and multiple assignments. If ARIN only > does /29 boundaries, I'll also be getting multiple /29's, and not just > working within a /27 per the HD-Ratio guidelines. If the policy is broken, then submit a policy proposal to fix it. Nick From rcarpen at network1.net Tue Oct 26 12:31:18 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 26 Oct 2010 13:31:18 -0400 (EDT) Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC70A08.2060304@foobar.org> Message-ID: <1455908465.13159.1288114278546.JavaMail.root@zimbra.network1.net> I think ARIN is now doing sparse allocations on /28 boundaries. My personal opinion is that it should be even more sparse, and that allocations should be done on nibble boundaries. Any reasonably-sized ISP should get at least a /28. I deal with many small-ish ISPs, and most are 5,000-10,000 users. Those are probably served by a /32 for quite some time. When you get into the ones that are 20,000-50,000, it gets tricker to deal with. Those should get a /28. The mega-ISPs should get a /24, or even a /20. Another problem is that the allocations from IANA to the RIRs are too small to begin with. If there are 5 RIRs, why does there have to be so much fragmentation? It is too late for that, though. Anyway, I think there are some proposals floating around (Owen? ;-) ) That would make the /32,/28,/24 (nibble boundary) idea into policy. We'll have to wait and see what happens. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > On 26/10/2010 17:23, Owen DeLong wrote: > > He's talking about the bloat that comes from ISPs getting > > slow-started and then > > only being able to increase their network in increments of 2x each > > time, so, > > effectively ISP gets: > [...] > > Probably not quite as bad as IPv4, but, potentially close. > > In theory, yes, it's bad. > > In practice, the RIRs are implementing sparse allocation which makes > it > possible to aggregate subsequent allocations. I.e. not as bad as it > may seem. > > ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if > you > get an initial allocation of /32, then find you need more, your > subsequent > allocations will be taken from the same /29, allowing aggregation up > to /29. > > APNIC seem to be delegating on /22 boundaries, and LACNIC on /28. > > Nick From mysidia at gmail.com Tue Oct 26 12:40:52 2010 From: mysidia at gmail.com (James Hess) Date: Tue, 26 Oct 2010 12:40:52 -0500 Subject: DDOS attack via as702 87.118.210.122 In-Reply-To: References: <20101026154527.G38880@dry.macomnet.ru> <20101026140718.GH19110@skywalker.creative.net.au> Message-ID: On Tue, Oct 26, 2010 at 9:12 AM, Jack Carrozzo wrote: > Well, I whois'd 702, got no match, said "hm, I see 701 all over the place, > lemmy take a look" and found: There is a match... I think "WHOIS as702" is erroneous WHOIS query syntax, typing "asXXXXX" not being the way to search for an AS number. See the full WHOIS help for the details about how to use all the flags, Try searching for the number and use an 'a' search type instead of searching for 'as702'. Try telnet whois.arin.net nicname Escape character is '^]'. a 702 "a 702" Gives a match... "as702" does not. "as701" does; probably because there is the "ASHANDLE" field or something else in the record that matches that query other than the AS number itself. > ASNumber: ? ? ? 701 - 705 > ASName: ? ? ? ? UUNET -- -JH From rcarpen at network1.net Tue Oct 26 13:01:06 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 26 Oct 2010 14:01:06 -0400 (EDT) Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC70DA2.6020906@brightok.net> Message-ID: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> ----- Original Message ----- > On 10/26/2010 12:04 PM, Nick Hilliard wrote: > > In practice, the RIRs are implementing sparse allocation which makes > > it > > possible to aggregate subsequent allocations. I.e. not as bad as it > > may > > seem. > > > > Except, if you are given bare minimums, and you are assigning out to > subtending ISPs bare minimums, those subtending ISPs will end up with > multiple networks. Some of them are BGP speakers. I can't use sparse > allocation because I was given minimum space and not the HD-Ratio > threshold space. Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- From heather.schiller at verizonbusiness.com Tue Oct 26 13:08:38 2010 From: heather.schiller at verizonbusiness.com (Schiller, Heather A) Date: Tue, 26 Oct 2010 18:08:38 +0000 Subject: DDOS attack via as702 87.118.210.122 In-Reply-To: <20101026154527.G38880@dry.macomnet.ru> References: <20101026154527.G38880@dry.macomnet.ru> Message-ID: See my sig.. Did you try calling your local customer support team? While we do have a 24x7 team that handles DoS attacks, we don't have a 24x7 team that reads every post to nanog ;-) The local support offices have a process to contact us, you should be able to get assistance reasonably quick. --Heather ~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~* Heather Schiller Network Security - Verizon Business 1.800.900.0241 security at verizonbusiness.com -----Original Message----- From: Serg Shubenkov [mailto:Serg at Macomnet.net] Sent: Tuesday, October 26, 2010 7:52 AM To: nanog at merit.edu Subject: DDOS attack via as702 87.118.210.122 Hello, list. Please send me off-list abuse contact for as702. -- Serg Shubenkov, MAcomnet, Internet Dept., Head of Inet Department phone: +7 495 7969392/9079, +7 916 5316625, mailto:serg at macomnet.net icq uin: 101964103, Skype: serg.v.shubenkov From sven at cb3rob.net Tue Oct 26 13:19:39 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 26 Oct 2010 18:19:39 +0000 (UTC) Subject: IPv6 Routing table will be bloated? In-Reply-To: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> Message-ID: On Tue, 26 Oct 2010, Randy Carpenter wrote: > ----- Original Message ----- >> On 10/26/2010 12:04 PM, Nick Hilliard wrote: >>> In practice, the RIRs are implementing sparse allocation which makes >>> it >>> possible to aggregate subsequent allocations. I.e. not as bad as it >>> may >>> seem. >>> >> >> Except, if you are given bare minimums, and you are assigning out to >> subtending ISPs bare minimums, those subtending ISPs will end up with >> multiple networks. Some of them are BGP speakers. I can't use sparse >> allocation because I was given minimum space and not the HD-Ratio >> threshold space. > > Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? > > -Randy to my knowledge, RIPE still does not issue ipv6 PI space. so giving them their own space, is "problematic" to say the least. -- 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 ========================================================================= 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 jbates at brightok.net Tue Oct 26 13:22:46 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 26 Oct 2010 13:22:46 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> Message-ID: <4CC71C76.9090702@brightok.net> On 10/26/2010 1:01 PM, Randy Carpenter wrote: > > Wait... If you are issuing space to ISPs that are multihomed, they > should be getting their own addresses. Even if they aren't > multihomed, they should probably be getting their own addresses. Why > would you be supplying them with address space if they are an ISP? > Because they are my customer. They don't know much about RIRs, paying membership fees, etc. They just know they want address space, and I provide that. 1) Policy doesn't state that only a RIR can hand address space to an ISP 2) You don't have to be multihomed to be considered an ISP or qualify for space from RIR (you just have to be larger if you aren't multihomed) 3) It has been this way for many years in IPv4, with all of my customers being ISPs from small to medium size and several of them even having their own subtending ISPs (some of which are even larger than my customer ISP in consumer customer counts). Jack From wmaton at ryouko.imsb.nrc.ca Tue Oct 26 13:28:04 2010 From: wmaton at ryouko.imsb.nrc.ca (William F. Maton Sotomayor) Date: Tue, 26 Oct 2010 14:28:04 -0400 (EDT) Subject: NTP Server In-Reply-To: <8639ru5vo4.fsf@seastrom.com> References: <20101024172022.GA56786@ussenterprise.ufp.org> <8639ru5vo4.fsf@seastrom.com> Message-ID: On Mon, 25 Oct 2010, Robert E. Seastrom wrote: > The folks at NRC in Canada will do cryptographically authenticated NTP > with you for an annual fee. I have no idea if there is something Robert, Thanks for the shout. NRC does do this, more info here: http://www.nrc-cnrc.gc.ca/eng/services/inms/time-services/network-time.html You can use the services as well for non-auth. I should also point out to folks on this list that the NRC NTP servers have renumbered, but I still see quite a bit of traffic from what appears to be ISP infrastructure looking for the old addresses. wfms From eugen at imacandi.net Tue Oct 26 13:28:54 2010 From: eugen at imacandi.net (Eugeniu Patrascu) Date: Tue, 26 Oct 2010 21:28:54 +0300 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> Message-ID: On Tue, Oct 26, 2010 at 21:19, Sven Olaf Kamphuis wrote: > On Tue, 26 Oct 2010, Randy Carpenter wrote: > >> ----- Original Message ----- >>> >>> On 10/26/2010 12:04 PM, Nick Hilliard wrote: >>>> >>>> In practice, the RIRs are implementing sparse allocation which makes >>>> it >>>> possible to aggregate subsequent allocations. I.e. not as bad as it >>>> may >>>> seem. >>>> >>> >>> Except, if you are given bare minimums, and you are assigning out to >>> subtending ISPs bare minimums, those subtending ISPs will end up with >>> multiple networks. Some of them are BGP speakers. I can't use sparse >>> allocation because I was given minimum space and not the HD-Ratio >>> threshold space. >> >> Wait... If you are issuing space to ISPs that are multihomed, they should >> be getting their own addresses. Even if they aren't multihomed, they should >> probably be getting their own addresses. Why would you be supplying them >> with address space if they are an ISP? >> >> -Randy > > to my knowledge, RIPE still does not issue ipv6 PI space. > so giving them their own space, is "problematic" to say the least. I got a /48 PI from RIPE a few months back. Maybe your knowledge needs to be a little bit refreshed regarding RIPE allocation policies :) From sven at cb3rob.net Tue Oct 26 13:30:51 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 26 Oct 2010 18:30:51 +0000 (UTC) Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> Message-ID: > On Tue, Oct 26, 2010 at 21:19, Sven Olaf Kamphuis wrote: >> On Tue, 26 Oct 2010, Randy Carpenter wrote: >> >>> ----- Original Message ----- >>>> >>>> On 10/26/2010 12:04 PM, Nick Hilliard wrote: >>>>> >>>>> In practice, the RIRs are implementing sparse allocation which makes >>>>> it >>>>> possible to aggregate subsequent allocations. I.e. not as bad as it >>>>> may >>>>> seem. >>>>> >>>> >>>> Except, if you are given bare minimums, and you are assigning out to >>>> subtending ISPs bare minimums, those subtending ISPs will end up with >>>> multiple networks. Some of them are BGP speakers. I can't use sparse >>>> allocation because I was given minimum space and not the HD-Ratio >>>> threshold space. >>> >>> Wait... If you are issuing space to ISPs that are multihomed, they should >>> be getting their own addresses. Even if they aren't multihomed, they should >>> probably be getting their own addresses. Why would you be supplying them >>> with address space if they are an ISP? >>> >>> -Randy >> >> to my knowledge, RIPE still does not issue ipv6 PI space. >> so giving them their own space, is "problematic" to say the least. > > I got a /48 PI from RIPE a few months back. > Maybe your knowledge needs to be a little bit refreshed regarding RIPE > allocation policies :) > Magically, indeed, an ipv6 pi request form showed up in the lirportal. amazing! From morrowc.lists at gmail.com Tue Oct 26 13:43:26 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Tue, 26 Oct 2010 14:43:26 -0400 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> Message-ID: On Tue, Oct 26, 2010 at 2:19 PM, Sven Olaf Kamphuis wrote: > On Tue, 26 Oct 2010, Randy Carpenter wrote: > >> ----- Original Message ----- >>> >>> On 10/26/2010 12:04 PM, Nick Hilliard wrote: >>>> >>>> In practice, the RIRs are implementing sparse allocation which makes >>>> it >>>> possible to aggregate subsequent allocations. I.e. not as bad as it >>>> may >>>> seem. >>>> >>> >>> Except, if you are given bare minimums, and you are assigning out to >>> subtending ISPs bare minimums, those subtending ISPs will end up with >>> multiple networks. Some of them are BGP speakers. I can't use sparse >>> allocation because I was given minimum space and not the HD-Ratio >>> threshold space. >> >> Wait... If you are issuing space to ISPs that are multihomed, they should >> be getting their own addresses. Even if they aren't multihomed, they should >> probably be getting their own addresses. Why would you be supplying them >> with address space if they are an ISP? >> >> -Randy > > to my knowledge, RIPE still does not issue ipv6 PI space. > so giving them their own space, is "problematic" to say the least. ISP's get an LIR assignemnt from RIPE, no? Customers could get an end-user assignment (PA space normally or PI) (ripe PI assignment policies) -chris > > -- > 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 > > ========================================================================= > > 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 owen at delong.com Tue Oct 26 14:16:50 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Oct 2010 12:16:50 -0700 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> Message-ID: <9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> On Oct 26, 2010, at 11:19 AM, Sven Olaf Kamphuis wrote: > On Tue, 26 Oct 2010, Randy Carpenter wrote: > >> ----- Original Message ----- >>> On 10/26/2010 12:04 PM, Nick Hilliard wrote: >>>> In practice, the RIRs are implementing sparse allocation which makes >>>> it >>>> possible to aggregate subsequent allocations. I.e. not as bad as it >>>> may >>>> seem. >>>> >>> >>> Except, if you are given bare minimums, and you are assigning out to >>> subtending ISPs bare minimums, those subtending ISPs will end up with >>> multiple networks. Some of them are BGP speakers. I can't use sparse >>> allocation because I was given minimum space and not the HD-Ratio >>> threshold space. >> >> Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? >> >> -Randy > > to my knowledge, RIPE still does not issue ipv6 PI space. > so giving them their own space, is "problematic" to say the least. > RIPE issues PI space in a couple of different forms... 1. Sponsoring LIR can pay 50 Euros/year and subsequently bill the recipient whatever they choose for the PI space. 2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs). 3. This is NANOG. NA != EU. Owen From gbonser at seven.com Tue Oct 26 14:20:19 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 26 Oct 2010 12:20:19 -0700 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC71C76.9090702@brightok.net> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <4CC71C76.9090702@brightok.net> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C502@RWC-EX1.corp.seven.com> > -----Original Message----- > From: Jack Bates [mailto:jbates at brightok.net] > Sent: Tuesday, October 26, 2010 11:23 AM > To: Randy Carpenter > Cc: nanog at nanog.org > Subject: Re: IPv6 Routing table will be bloated? > > On 10/26/2010 1:01 PM, Randy Carpenter wrote: > > > > Wait... If you are issuing space to ISPs that are multihomed, they > > should be getting their own addresses. Even if they aren't > > multihomed, they should probably be getting their own addresses. Why > > would you be supplying them with address space if they are an ISP? > > > > Because they are my customer. They don't know much about RIRs, paying > membership fees, etc. They just know they want address space, and I > provide that. If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such. Something isn't passing the smell test here. From ikiris at gmail.com Tue Oct 26 14:26:10 2010 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 26 Oct 2010 14:26:10 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C502@RWC-EX1.corp.seven.com> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <4CC71C76.9090702@brightok.net> <5A6D953473350C4B9995546AFE9939EE0B14C502@RWC-EX1.corp.seven.com> Message-ID: On Tue, Oct 26, 2010 at 14:20, George Bonser wrote: > > > > -----Original Message----- > > From: Jack Bates [mailto:jbates at brightok.net] > > On 10/26/2010 1:01 PM, Randy Carpenter wrote: > > > > > > Wait... If you are issuing space to ISPs that are multihomed, they > > > should be getting their own addresses. Even if they aren't > > > multihomed, they should probably be getting their own addresses. Why > > > would you be supplying them with address space if they are an ISP? > > > > > > > Because they are my customer. They don't know much about RIRs, paying > > membership fees, etc. They just know they want address space, and I > > provide that. > > If they are ISPs and don't know much about RIRs, can you please name them > and provide their ASNs ... oh, wait ... they won't have an ASN if they don't > know about RIRs and fees and such. > > Something isn't passing the smell test here. > > This is actually not that uncommon. You see it a lot in the smaller level. I had several such clients at my last job. They want to be multi-homed for redundancy, but either don't have enough space, or don't want to pay full time people, so they use a small to midsize ISP and their space and assistance to set up. -Blake From sven at cb3rob.net Tue Oct 26 14:37:51 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 26 Oct 2010 19:37:51 +0000 (UTC) Subject: IPv6 Routing table will be bloated? In-Reply-To: <9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> Message-ID: 2. RIPE has always issued PI space to LIRs (ISPs are by definition LIRs). ISPs are not per-se LIRs. LIRs register IP space on behalf of customers customers that do not make delegations themselves (i'm quite sure you don't put each and every one of your access customers into whois, for one thing because that would violate privacy laws :P do not need to be a LIR, and can just do so on PI space. Shared hosting ISPs also do not make subdelegations and generally don't even uses the ips on a one-specific-customer-per-ip basis. So no, ISP's do not have to be a LIR, and LIRs do not have to be an ISP. (in fact, we are considering moving our LIR activities to a completely seperate legal entity from our internet activities). as a LIR is just a buro that issues IP space and does not nessesarily own or operate a network. -- 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 ========================================================================= 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. On Tue, 26 Oct 2010, Owen DeLong wrote: > > On Oct 26, 2010, at 11:19 AM, Sven Olaf Kamphuis wrote: > >> On Tue, 26 Oct 2010, Randy Carpenter wrote: >> >>> ----- Original Message ----- >>>> On 10/26/2010 12:04 PM, Nick Hilliard wrote: >>>>> In practice, the RIRs are implementing sparse allocation which makes >>>>> it >>>>> possible to aggregate subsequent allocations. I.e. not as bad as it >>>>> may >>>>> seem. >>>>> >>>> >>>> Except, if you are given bare minimums, and you are assigning out to >>>> subtending ISPs bare minimums, those subtending ISPs will end up with >>>> multiple networks. Some of them are BGP speakers. I can't use sparse >>>> allocation because I was given minimum space and not the HD-Ratio >>>> threshold space. >>> >>> Wait... If you are issuing space to ISPs that are multihomed, they should be getting their own addresses. Even if they aren't multihomed, they should probably be getting their own addresses. Why would you be supplying them with address space if they are an ISP? >>> >>> -Randy >> >> to my knowledge, RIPE still does not issue ipv6 PI space. >> so giving them their own space, is "problematic" to say the least. >> > RIPE issues PI space in a couple of different forms... > > 1. Sponsoring LIR can pay 50 Euros/year and subsequently > bill the recipient whatever they choose for the PI space. > > 2. RIPE has always issued PI space to LIRs (ISPs are by > definition LIRs). > > 3. This is NANOG. NA != EU. > > Owen > > From sven at cb3rob.net Tue Oct 26 14:40:54 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 26 Oct 2010 19:40:54 +0000 (UTC) Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> Message-ID: HAHA that would totally make the MAFIAA's day... entering all your dialup and adsl customers into whois as they would be "end users" :P quite sure the EU would not agree on that definition of what constitutes an end-user, and therefore, its quite possible to provide access services on PI space (as you don't make sub delegations anyway) On Tue, 26 Oct 2010, Sven Olaf Kamphuis wrote: > 2. RIPE has always issued PI space to LIRs (ISPs are by > definition LIRs). > > ISPs are not per-se LIRs. > > LIRs register IP space on behalf of customers > > customers that do not make delegations themselves (i'm quite sure you don't > put each and every one of your access customers into whois, for one thing > because that would violate privacy laws :P do not need to be a LIR, and can > just do so on PI space. > > Shared hosting ISPs also do not make subdelegations and generally don't even > uses the ips on a one-specific-customer-per-ip basis. > > So no, ISP's do not have to be a LIR, and LIRs do not have to be an ISP. > (in fact, we are considering moving our LIR activities to a completely > seperate legal entity from our internet activities). > > as a LIR is just a buro that issues IP space and does not nessesarily own or > operate a network. > > -- > 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 > > ========================================================================= > > 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. > > > On Tue, 26 Oct 2010, Owen DeLong wrote: > >> >> On Oct 26, 2010, at 11:19 AM, Sven Olaf Kamphuis wrote: >> >>> On Tue, 26 Oct 2010, Randy Carpenter wrote: >>> >>>> ----- Original Message ----- >>>>> On 10/26/2010 12:04 PM, Nick Hilliard wrote: >>>>>> In practice, the RIRs are implementing sparse allocation which makes >>>>>> it >>>>>> possible to aggregate subsequent allocations. I.e. not as bad as it >>>>>> may >>>>>> seem. >>>>>> >>>>> >>>>> Except, if you are given bare minimums, and you are assigning out to >>>>> subtending ISPs bare minimums, those subtending ISPs will end up with >>>>> multiple networks. Some of them are BGP speakers. I can't use sparse >>>>> allocation because I was given minimum space and not the HD-Ratio >>>>> threshold space. >>>> >>>> Wait... If you are issuing space to ISPs that are multihomed, they should >>>> be getting their own addresses. Even if they aren't multihomed, they >>>> should probably be getting their own addresses. Why would you be >>>> supplying them with address space if they are an ISP? >>>> >>>> -Randy >>> >>> to my knowledge, RIPE still does not issue ipv6 PI space. >>> so giving them their own space, is "problematic" to say the least. >>> >> RIPE issues PI space in a couple of different forms... >> >> 1. Sponsoring LIR can pay 50 Euros/year and subsequently >> bill the recipient whatever they choose for the PI space. >> >> 2. RIPE has always issued PI space to LIRs (ISPs are by >> definition LIRs). >> >> 3. This is NANOG. NA != EU. >> >> Owen >> >> > From gbonser at seven.com Tue Oct 26 14:45:45 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 26 Oct 2010 12:45:45 -0700 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net><9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> > > Shared hosting ISPs also do not make subdelegations and generally don't > even uses the ips on a one-specific-customer-per-ip basis. But how do they multihome without an ASN? If they have an ASN, how did they get it without going to an RIR and paying a fee? From tony at lava.net Tue Oct 26 14:51:32 2010 From: tony at lava.net (Antonio Querubin) Date: Tue, 26 Oct 2010 09:51:32 -1000 (HST) Subject: IPv6 Routing table will be bloated? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net><9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: On Tue, 26 Oct 2010, George Bonser wrote: > To: Sven Olaf Kamphuis >> Shared hosting ISPs also do not make subdelegations and generally > don't >> even uses the ips on a one-specific-customer-per-ip basis. > > But how do they multihome without an ASN? > If they have an ASN, how did they get it without going to an RIR and > paying a fee? Legacy ASN assignment? Antonio Querubin 808-545-5282 x3003 e-mail/xmpp: tony at lava.net From ikiris at gmail.com Tue Oct 26 14:57:02 2010 From: ikiris at gmail.com (Blake Dunlap) Date: Tue, 26 Oct 2010 14:57:02 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: On Tue, Oct 26, 2010 at 14:45, George Bonser wrote: > > > > Shared hosting ISPs also do not make subdelegations and generally > don't > > even uses the ips on a one-specific-customer-per-ip basis. > > But how do they multihome without an ASN? > If they have an ASN, how did they get it without going to an RIR and > paying a fee? > > Its not that hard to get an ASN, and all the work can be done by said ISP on behaf of the client, especially many years ago. The extent of one client's knowledge was to turn off a provider router if they were having problems, anything else was handled by us, even with the other ISPs of the client. -Blake From sven at cb3rob.net Tue Oct 26 15:01:36 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 26 Oct 2010 20:01:36 +0000 (UTC) Subject: IPv6 Routing table will be bloated? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net><9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: eh don't know about you americans but here in europe you just go to a LIR and ask them to register an AS for you. there are ofcourse maintenance fees nowadays. On Tue, 26 Oct 2010, George Bonser wrote: >> >> Shared hosting ISPs also do not make subdelegations and generally > don't >> even uses the ips on a one-specific-customer-per-ip basis. > > But how do they multihome without an ASN? > If they have an ASN, how did they get it without going to an RIR and > paying a fee? > > From sven at cb3rob.net Tue Oct 26 15:03:36 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 26 Oct 2010 20:03:36 +0000 (UTC) Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: We also have various customers that only obtain LIR registration services and have no network links whatsoever with us (so just PI and/or AS registration, no transit or whatever) which -is- what a LIR does.. operating a network has nothing to do with being a LIR per-se. On Tue, 26 Oct 2010, Blake Dunlap wrote: > On Tue, Oct 26, 2010 at 14:45, George Bonser wrote: > >>> >>> Shared hosting ISPs also do not make subdelegations and generally >> don't >>> even uses the ips on a one-specific-customer-per-ip basis. >> >> But how do they multihome without an ASN? >> If they have an ASN, how did they get it without going to an RIR and >> paying a fee? >> >> > Its not that hard to get an ASN, and all the work can be done by said ISP on > behaf of the client, especially many years ago. > > The extent of one client's knowledge was to turn off a provider router if > they were having problems, anything else was handled by us, even with the > other ISPs of the client. > > -Blake > From cboyd at gizmopartners.com Tue Oct 26 15:08:07 2010 From: cboyd at gizmopartners.com (Chris Boyd) Date: Tue, 26 Oct 2010 15:08:07 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net><9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: On Oct 26, 2010, at 2:45 PM, George Bonser wrote: > But how do they multihome without an ASN? > If they have an ASN, how did they get it without going to an RIR and > paying a fee? I beleive Jack said that they have redundant connections to his network. I took that to mean that they did not multihome to different AS. Such arrangements are not uncommon. Sprint seems to have done very well selling this sort of near-turnkey service to rural DSL carriers, tiny single town MSOs and the like. --Chris From jbates at brightok.net Tue Oct 26 15:16:16 2010 From: jbates at brightok.net (Jack Bates) Date: Tue, 26 Oct 2010 15:16:16 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <4CC71C76.9090702@brightok.net> <5A6D953473350C4B9995546AFE9939EE0B14C502@RWC-EX1.corp.seven.com> Message-ID: <4CC73710.7070600@brightok.net> On 10/26/2010 2:26 PM, Blake Dunlap wrote: > This is actually not that uncommon. You see it a lot in the smaller > level. I had several such clients at my last job. They want to be > multi-homed for redundancy, but either don't have enough space, or > don't want to pay full time people, so they use a small to midsize ISP > and their space and assistance to set up. Some aren't multihomed, but they use larger than /20 of v4 space and so still qualify. Others are smaller and multihomed and with my permission (since I configured the BGP for them), use my ASN and routing tricks. Since they have grown this way, they often have no desires to renumber, and most have no desire to even bother with an ASN. However, given the price of an ASN vs price of an ASN and ISP v6 /32; I know exactly which they'll choose. They'll let me pay the higher membership fees, and just get space from me. Jack From sven at cb3rob.net Tue Oct 26 15:22:37 2010 From: sven at cb3rob.net (Sven Olaf Kamphuis) Date: Tue, 26 Oct 2010 20:22:37 +0000 (UTC) Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net><9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: what's the problem anyway with 32bit ASN's there should be enough AS namespace to give everyone that wants to multihome their ipv6/ipv4 PI their own AS number... should pretty much be the de-facto standard (unless ofcourse you want to tie your customers to your internet-provider-activities by making it hard to leave) maybe we should have made AS numbers 64 bit as well... so there would be one for every /64 end user as for the rest of it: get routers with more ram (i don't want to hear any "my border routers have less than 8GB of ram") arguments, that stuff is -old-, it's got gray hair and a beard and belongs in a museum, not on the internet) The internet will grow, you can't expect it to grow less fast or to "aggregate" routes just because your technically outdated stuff doesn't have enough ram to handle the growing route table size. (preferably offset-based rather than with a sort/lookup mechanism) if a customer has a /64 and wants to announce that /64 himself, i see no reason not to give it to them, especially not if hte only reason would be that some people run still routers that have less ram than my eeepc. (and some suppliers still think that's "OK" to sell) On Tue, 26 Oct 2010, Chris Boyd wrote: > > On Oct 26, 2010, at 2:45 PM, George Bonser wrote: > >> But how do they multihome without an ASN? >> If they have an ASN, how did they get it without going to an RIR and >> paying a fee? > > I beleive Jack said that they have redundant connections to his network. I took that to mean that they did not multihome to different AS. > > Such arrangements are not uncommon. Sprint seems to have done very well selling this sort of near-turnkey service to rural DSL carriers, tiny single town MSOs and the like. > > --Chris > > From sreed at nwwnet.net Tue Oct 26 15:25:39 2010 From: sreed at nwwnet.net (Scott Reed) Date: Tue, 26 Oct 2010 16:25:39 -0400 Subject: IPv6 Routing table will be bloated? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C502@RWC-EX1.corp.seven.com> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <4CC71C76.9090702@brightok.net> <5A6D953473350C4B9995546AFE9939EE0B14C502@RWC-EX1.corp.seven.com> Message-ID: <4CC73943.7040707@nwwnet.net> Why would the assumption be the ISP = knowledgeable or even caring about RIRs, etc.? When I started my ISP 6 years ago I knew someone issued IP addresses to my upstream provider, but I really didn't care who that was. The upstream took care of everything related to getting and assigning addresses as far as I was concerned. Even when I changed upstream providers they took care of the addresses. It was at that time I realized I need to learn more about the whole IP address assignment process so I wouldn't have to renumber next time I changed providers. I dug far enough to find that my ISP was not big enough to get an assignment and the required fee was more than the cost to renumber, so I didn't look any farther. So, as a log of start-ups and small businesses do, I learned enough to make what I needed work, but not everything that may have been beneficial. On 10/26/2010 3:20 PM, George Bonser wrote: > >> -----Original Message----- >> From: Jack Bates [mailto:jbates at brightok.net] >> Sent: Tuesday, October 26, 2010 11:23 AM >> To: Randy Carpenter >> Cc: nanog at nanog.org >> Subject: Re: IPv6 Routing table will be bloated? >> >> On 10/26/2010 1:01 PM, Randy Carpenter wrote: >>> Wait... If you are issuing space to ISPs that are multihomed, they >>> should be getting their own addresses. Even if they aren't >>> multihomed, they should probably be getting their own addresses. Why >>> would you be supplying them with address space if they are an ISP? >>> >> Because they are my customer. They don't know much about RIRs, paying >> membership fees, etc. They just know they want address space, and I >> provide that. > If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such. > > Something isn't passing the smell test here. > -- Scott Reed Owner NewWays Networking, LLC Wireless Networking Network Design, Installation and Administration Mikrotik Advanced Certified www.nwwnet.net (765) 855-1060 From msa at latt.net Tue Oct 26 15:32:06 2010 From: msa at latt.net (Majdi S. Abbas) Date: Tue, 26 Oct 2010 13:32:06 -0700 Subject: IPv6 Routing table will be bloated? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: <20101026203206.GD59079@puck.nether.net> On Tue, Oct 26, 2010 at 12:45:45PM -0700, George Bonser wrote: > But how do they multihome without an ASN? Well, get space from one of your providers, and an LOA to get the other to announce the deaggregate for you. Or they've got legacy space, and never had an AS; just get their providers to announce it for them. > If they have an ASN, how did they get it without going to an RIR and > paying a fee? Legacy assignment...acquisition... And maybe they did, but just because they pay their RIR for an ASN doesn't mean they want to step up into the fees and documentation headaches of getting their own space. ($$$$) Some are even singlehomed with an ASN. (I can think of at least two regional providers that had an ASN while being singlehomed because they had downstream BGP speaking customers.) Just because you don't do it, doesn't mean someone else doesn't. It's a big world. --msa From gbonser at seven.com Tue Oct 26 15:35:48 2010 From: gbonser at seven.com (George Bonser) Date: Tue, 26 Oct 2010 13:35:48 -0700 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net><9DE76765-96E0-4BB9-AD73-115467A61331@delong.com><5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C50B@RWC-EX1.corp.seven.com> > From: Chris Boyd > Sent: Tuesday, October 26, 2010 1:08 PM > To: NANOG > Subject: Re: IPv6 Routing table will be bloated? > > > I beleive Jack said that they have redundant connections to his > network. I took that to mean that they did not multihome to different > AS. Ok, that is where my mental disconnect came from. I saw the word "multihomed" and took that to mean homed to two different providers, not dual connections to the same. > Such arrangements are not uncommon. Indeed. We do that in a couple of places, too. From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Oct 26 15:44:20 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 27 Oct 2010 07:14:20 +1030 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC70DA2.6020906@brightok.net> References: <4CC6DE55.7000901@brightok.net> <4CC70A08.2060304@foobar.org> <4CC70DA2.6020906@brightok.net> Message-ID: <20101027071420.3c935c47@opy.nosense.org> On Tue, 26 Oct 2010 12:19:30 -0500 Jack Bates wrote: > On 10/26/2010 12:04 PM, Nick Hilliard wrote: > > In practice, the RIRs are implementing sparse allocation which makes it > > possible to aggregate subsequent allocations. I.e. not as bad as it may > > seem. > > > > Except, if you are given bare minimums, and you are assigning out to > subtending ISPs bare minimums, Why aren't those subtending ISPs getting their own PI (/32s)? > those subtending ISPs will end up with > multiple networks. Some of them are BGP speakers. I can't use sparse > allocation because I was given minimum space and not the HD-Ratio > threshold space. > > > ARIN, RIPE and AfriNIC, for example, allocate on /29 boundaries. So if > > you get an initial allocation of /32, then find you need more, your > > subsequent allocations will be taken from the same /29, allowing > > aggregation up to /29. > > > > My minimum /30 allocation per ARIN met a /27 in HD-Ratio thresholds. To > not be given the threshold space means no reservations for subtending > ISPs, no room for subtending ISPs to grow, and multiple assignments. If > ARIN only does /29 boundaries, I'll also be getting multiple /29's, and > not just working within a /27 per the HD-Ratio guidelines. > > It's the mixed viewpoint that is the problem. HD-Ratio is useless as a > justification and as a metric which promotes route > conservation/aggregation if it is not used for initial allocations. > Initial allocations (including those handed out to subtending ISPs) > should all be as large as the immediate use HD Ratio permits. ie, If you > are immediately assigning X /56 blocks, your assignment should have a > length one less than the highest threshold you crossed. To assign any > less is to constrain the assignments, not allow for growth, and to > increase routing table size. It also circumvents and completely destroys > the concept of HD Ratio (as the initial assignments all are well in > excess of the thresholds for requesting much larger blocks). > > > Jack > From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Tue Oct 26 15:53:12 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Wed, 27 Oct 2010 07:23:12 +1030 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC73943.7040707@nwwnet.net> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net> <4CC71C76.9090702@brightok.net> <5A6D953473350C4B9995546AFE9939EE0B14C502@RWC-EX1.corp.seven.com> <4CC73943.7040707@nwwnet.net> Message-ID: <20101027072312.6f67550f@opy.nosense.org> On Tue, 26 Oct 2010 16:25:39 -0400 Scott Reed wrote: > Why would the assumption be the ISP = knowledgeable or even caring about > RIRs, etc.? > > When I started my ISP 6 years ago I knew someone issued IP addresses to > my upstream provider, but I really didn't care who that was. The > upstream took care of everything related to getting and assigning > addresses as far as I was concerned. Even when I changed upstream > providers they took care of the addresses. It was at that time I > realized I need to learn more about the whole IP address assignment > process so I wouldn't have to renumber next time I changed providers. I > dug far enough to find that my ISP was not big enough to get an > assignment and the required fee was more than the cost to renumber, so I > didn't look any farther. > > So, as a log of start-ups and small businesses do, I learned enough to > make what I needed work, but not everything that may have been beneficial. > So maybe to state the obvious, IPv4 != IPv6, and therefore in Jack's situation something different needs to be done, such as those ISPs learning about RIRs, LIRs etc. sooner rather than later. > > On 10/26/2010 3:20 PM, George Bonser wrote: > > > >> -----Original Message----- > >> From: Jack Bates [mailto:jbates at brightok.net] > >> Sent: Tuesday, October 26, 2010 11:23 AM > >> To: Randy Carpenter > >> Cc: nanog at nanog.org > >> Subject: Re: IPv6 Routing table will be bloated? > >> > >> On 10/26/2010 1:01 PM, Randy Carpenter wrote: > >>> Wait... If you are issuing space to ISPs that are multihomed, they > >>> should be getting their own addresses. Even if they aren't > >>> multihomed, they should probably be getting their own addresses. Why > >>> would you be supplying them with address space if they are an ISP? > >>> > >> Because they are my customer. They don't know much about RIRs, paying > >> membership fees, etc. They just know they want address space, and I > >> provide that. > > If they are ISPs and don't know much about RIRs, can you please name them and provide their ASNs ... oh, wait ... they won't have an ASN if they don't know about RIRs and fees and such. > > > > Something isn't passing the smell test here. > > > > -- > Scott Reed > Owner > NewWays Networking, LLC > Wireless Networking > Network Design, Installation and Administration > Mikrotik Advanced Certified > www.nwwnet.net > (765) 855-1060 > > > From franck at genius.com Tue Oct 26 16:36:19 2010 From: franck at genius.com (Franck Martin) Date: Wed, 27 Oct 2010 09:36:19 +1200 (FJT) Subject: IPv6 Routing table will be bloated? In-Reply-To: <1455908465.13159.1288114278546.JavaMail.root@zimbra.network1.net> Message-ID: <15066436.8.1288128976615.JavaMail.franck@franck-martins-macbook-pro.local> I think APNIC has a policy that defines the minimum IPv6 allocation based on your current IPv4 allocation/usage. This would fix the problem? ----- Original Message ----- From: "Randy Carpenter" To: "Nick Hilliard" Cc: nanog at nanog.org Sent: Wednesday, 27 October, 2010 6:31:18 AM Subject: Re: IPv6 Routing table will be bloated? I think ARIN is now doing sparse allocations on /28 boundaries. My personal opinion is that it should be even more sparse, and that allocations should be done on nibble boundaries. Any reasonably-sized ISP should get at least a /28. I deal with many small-ish ISPs, and most are 5,000-10,000 users. Those are probably served by a /32 for quite some time. When you get into the ones that are 20,000-50,000, it gets tricker to deal with. Those should get a /28. The mega-ISPs should get a /24, or even a /20. Another problem is that the allocations from IANA to the RIRs are too small to begin with. If there are 5 RIRs, why does there have to be so much fragmentation? It is too late for that, though. Anyway, I think there are some proposals floating around (Owen? ;-) ) That would make the /32,/28,/24 (nibble boundary) idea into policy. We'll have to wait and see what happens. From rcarpen at network1.net Tue Oct 26 16:48:13 2010 From: rcarpen at network1.net (Randy Carpenter) Date: Tue, 26 Oct 2010 17:48:13 -0400 (EDT) Subject: IPv6 Routing table will be bloated? In-Reply-To: <15066436.8.1288128976615.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: <1190710313.13228.1288129693692.JavaMail.root@zimbra.network1.net> It would be nice as a start, but does not really take into consideration future expansion needs. I would think that you could draw some parallels, though. Something like: v4 /16 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24 I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base. -Randy -- | Randy Carpenter | Vice President, IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (419)739-9240, x1 ---- ----- Original Message ----- > I think APNIC has a policy that defines the minimum IPv6 allocation > based on your current IPv4 allocation/usage. This would fix the > problem? > > ----- Original Message ----- > From: "Randy Carpenter" > To: "Nick Hilliard" > Cc: nanog at nanog.org > Sent: Wednesday, 27 October, 2010 6:31:18 AM > Subject: Re: IPv6 Routing table will be bloated? > > > I think ARIN is now doing sparse allocations on /28 boundaries. > > My personal opinion is that it should be even more sparse, and that > allocations should be done on nibble boundaries. Any reasonably-sized > ISP should get at least a /28. > > I deal with many small-ish ISPs, and most are 5,000-10,000 users. > Those are probably served by a /32 for quite some time. When you get > into the ones that are 20,000-50,000, it gets tricker to deal with. > Those should get a /28. The mega-ISPs should get a /24, or even a /20. > > Another problem is that the allocations from IANA to the RIRs are too > small to begin with. If there are 5 RIRs, why does there have to be so > much fragmentation? It is too late for that, though. > > Anyway, I think there are some proposals floating around (Owen? ;-) ) > That would make the /32,/28,/24 (nibble boundary) idea into policy. > We'll have to wait and see what happens. From franck at genius.com Tue Oct 26 17:00:51 2010 From: franck at genius.com (Franck Martin) Date: Wed, 27 Oct 2010 10:00:51 +1200 (FJT) Subject: IPv6 Routing table will be bloated? In-Reply-To: <1190710313.13228.1288129693692.JavaMail.root@zimbra.network1.net> Message-ID: <5046804.16.1288130425389.JavaMail.franck@franck-martins-macbook-pro.local> Yes indeed, but you don't have to justify much if you only ask for the minimum, if you want more you need to ask... Also, and this I like less, your membership is calculated from the number of IPs you have... I think in short $$=max(1180x1.3(log2(Addresses in /32)-8),Feev6 = 1180x1.3(log2(Addresses in /56)-22) http://www.apnic.net/services/apply-for-resources/check-your-eligibility/check-ipv6 http://www.apnic.net/services/become-a-member/how-much-does-it-cost ----- Original Message ----- From: "Randy Carpenter" To: "Franck Martin" Cc: nanog at nanog.org, "Nick Hilliard" Sent: Wednesday, 27 October, 2010 10:48:13 AM Subject: Re: IPv6 Routing table will be bloated? It would be nice as a start, but does not really take into consideration future expansion needs. I would think that you could draw some parallels, though. Something like: v4 /16 ~ v6 /32 v4 /12 ~ v6 /28 v4 /8 ~ v6 /24 I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base. From owen at delong.com Tue Oct 26 17:48:58 2010 From: owen at delong.com (Owen DeLong) Date: Tue, 26 Oct 2010 15:48:58 -0700 Subject: IPv6 Routing table will be bloated? In-Reply-To: <5046804.16.1288130425389.JavaMail.franck@franck-martins-macbook-pro.local> References: <5046804.16.1288130425389.JavaMail.franck@franck-martins-macbook-pro.local> Message-ID: It's very interesting to me that wee keep discussing RIRs other than ARIN when talking about allocation policies and issues for NANOG. The NA in NANOG puts the vast majority of it within the ARIN service region. The only other RIR which has territory within NA has not even been mentioned until now and that is LACNIC. (I'm afraid I am not yet familiar with their current IPv6 policies or practices). Owen On Oct 26, 2010, at 3:00 PM, Franck Martin wrote: > Yes indeed, but you don't have to justify much if you only ask for the minimum, if you want more you need to ask... > > Also, and this I like less, your membership is calculated from the number of IPs you have... I think in short $$=max(1180x1.3(log2(Addresses in /32)-8),Feev6 = 1180x1.3(log2(Addresses in /56)-22) > > http://www.apnic.net/services/apply-for-resources/check-your-eligibility/check-ipv6 > http://www.apnic.net/services/become-a-member/how-much-does-it-cost > > ----- Original Message ----- > From: "Randy Carpenter" > To: "Franck Martin" > Cc: nanog at nanog.org, "Nick Hilliard" > Sent: Wednesday, 27 October, 2010 10:48:13 AM > Subject: Re: IPv6 Routing table will be bloated? > > > It would be nice as a start, but does not really take into consideration future expansion needs. > > I would think that you could draw some parallels, though. > > Something like: > > v4 /16 ~ v6 /32 > v4 /12 ~ v6 /28 > v4 /8 ~ v6 /24 > > I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base. From franck at genius.com Tue Oct 26 18:03:54 2010 From: franck at genius.com (Franck Martin) Date: Wed, 27 Oct 2010 11:03:54 +1200 (FJT) Subject: IPv6 Routing table will be bloated? In-Reply-To: Message-ID: <4269440.27.1288134176382.JavaMail.franck@franck-martins-macbook-pro.local> ----- Original Message ----- > From: "Owen DeLong" > To: "Franck Martin" > Cc: "Randy Carpenter" , nanog at nanog.org > Sent: Wednesday, 27 October, 2010 11:48:58 AM > Subject: Re: IPv6 Routing table will be bloated? > It's very interesting to me that wee keep discussing RIRs other than > ARIN when > talking about allocation policies and issues for NANOG. > > The NA in NANOG puts the vast majority of it within the ARIN service > region. The > only other RIR which has territory within NA has not even been > mentioned until > now and that is LACNIC. (I'm afraid I am not yet familiar with their > current IPv6 > policies or practices). > "Cute but not too bright" The Oracle (The Matrix) From jdfalk-lists at cybernothing.org Tue Oct 26 19:04:47 2010 From: jdfalk-lists at cybernothing.org (J.D. Falk) Date: Tue, 26 Oct 2010 17:04:47 -0700 Subject: Tools for teaching users online safety In-Reply-To: <4CC62B29.4040104@blastro.com> References: <4CC62B29.4040104@blastro.com> Message-ID: On Oct 25, 2010, at 6:13 PM, Alex Thurlow wrote: > I'm trying to find out if there are currently any resources available for teaching people how to be safe online. As in, how to not get a virus, how to pick out phishing emails, how to recognize scams. I'm sure everyone on this list knows these things, but a lot of end users don't. I'm trying to find a way to teach these things to people who aren't too technically savvy. > > It seems to me that the fewer end users that have issues, the easier our lives will be. > > So what I'm trying to figure out is, is there a good site or set of sites for this stuff, or is there anyone out there interested in helping to build a unified list of instructions, videos, etc. for all this? http://staysafeonline.org/ has recently emerged as the primary site for all of that kind of information, supported by DHS and a lot of big companies (including many who send people to NANOG meetings.) From mpalmer at hezmatt.org Tue Oct 26 19:11:40 2010 From: mpalmer at hezmatt.org (Matthew Palmer) Date: Wed, 27 Oct 2010 11:11:40 +1100 Subject: IPv6 Routing table will be bloated? In-Reply-To: <1190710313.13228.1288129693692.JavaMail.root@zimbra.network1.net> References: <15066436.8.1288128976615.JavaMail.franck@franck-martins-macbook-pro.local> <1190710313.13228.1288129693692.JavaMail.root@zimbra.network1.net> Message-ID: <20101027001140.GY11984@hezmatt.org> On Tue, Oct 26, 2010 at 05:48:13PM -0400, Randy Carpenter wrote: > Someone who Randy didn't attribute wrote: > > I think APNIC has a policy that defines the minimum IPv6 allocation > > based on your current IPv4 allocation/usage. This would fix the > > problem? > It would be nice as a start, but does not really take into consideration future expansion needs. > > I would think that you could draw some parallels, though. > > Something like: > > v4 /16 ~ v6 /32 > v4 /12 ~ v6 /28 > v4 /8 ~ v6 /24 > > I know it we don't want to equate v4 and v6, but it may help as a guideline for the size of the customer base. I don't think it's a particularly good metric, either, because it doesn't take into account the "conversion rate" of IPv4 to IPv6 addresses, which is wildly different in different networks. Fer instance, $JOB[-1] is a colo/hosting business, with a fair chunk of IPv4 allocated, and the standard IPv6 /32. I did the initial IPv6 address plan, and I'm pretty confident in saying that they'll *never* need any more than that /32 of IPv6, because their business model means that they pack their /64s relatively (hah!) densely (typically there's at least one /24 of IPv4 per /64 of IPv6). However, anyone doing network access is likely to be replacing an IPv4 /32 with an IPv6 /48, which results in a lot more address space usage. Direct conversion between IPv4 and IPv6 will either result in many places being starved of IPv6 (very bad, as the OP of this thread pointed out), or space will be massively overallocated (also, not real hot). - Matt From randy at psg.com Tue Oct 26 20:43:51 2010 From: randy at psg.com (Randy Bush) Date: Wed, 27 Oct 2010 10:43:51 +0900 Subject: IPv6 Routing table will be bloated? In-Reply-To: <4CC6DE55.7000901@brightok.net> References: <4CC6DE55.7000901@brightok.net> Message-ID: > So, the best that I can tell (still not through debating with RIR), the > IPv6 routing table will see lots of bloat. 96 more bits, no magic From joly at punkcast.com Tue Oct 26 23:01:54 2010 From: joly at punkcast.com (Joly MacFie) Date: Wed, 27 Oct 2010 00:01:54 -0400 Subject: Tools for teaching users online safety In-Reply-To: References: <4CC62B29.4040104@blastro.com> Message-ID: Also the FTC has set up a comprehensive site to protect kids, including a guide for parents on kid's use of social networks. http://www.onguardonline.gov/ j On Tue, Oct 26, 2010 at 8:04 PM, J.D. Falk wrote: > On Oct 25, 2010, at 6:13 PM, Alex Thurlow wrote: > > > I'm trying to find out if there are currently any resources available for > teaching people how to be safe online. As in, how to not get a virus, how > to pick out phishing emails, how to recognize scams. I'm sure everyone on > this list knows these things, but a lot of end users don't. I'm trying to > find a way to teach these things to people who aren't too technically savvy. > > > > It seems to me that the fewer end users that have issues, the easier our > lives will be. > > > > So what I'm trying to figure out is, is there a good site or set of sites > for this stuff, or is there anyone out there interested in helping to build > a unified list of instructions, videos, etc. for all this? > > http://staysafeonline.org/ has recently emerged as the primary site for > all of that kind of information, supported by DHS and a lot of big companies > (including many who send people to NANOG meetings.) > > > -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com Secretary - ISOC-NY - http://isoc-ny.org --------------------------------------------------------------- From ben at adversary.org Wed Oct 27 06:32:08 2010 From: ben at adversary.org (Ben McGinnes) Date: Wed, 27 Oct 2010 22:32:08 +1100 Subject: Tools for teaching users online safety In-Reply-To: References: <4CC62B29.4040104@blastro.com> Message-ID: <4CC80DB8.50805@adversary.org> On 27/10/10 3:01 PM, Joly MacFie wrote: > Also the FTC has set up a comprehensive site to protect kids, including a > guide for parents on kid's use of social networks. > > http://www.onguardonline.gov/ The Australian version has kids, parents and libraries as the primary focus: http://www.cybersmart.gov.au/ I'm sure it's pretty similar otherwise (except for the links to report "offensive" websites for the national blacklist). Regards, Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 259 bytes Desc: OpenPGP digital signature URL: From jaap at NLnetLabs.nl Wed Oct 27 07:40:14 2010 From: jaap at NLnetLabs.nl (Jaap Akkerhuis) Date: Wed, 27 Oct 2010 14:40:14 +0200 Subject: Tools for teaching users online safety In-Reply-To: References: <4CC62B29.4040104@blastro.com> Message-ID: <201010271240.o9RCeEDd088911@bartok.nlnetlabs.nl> Also the FTC has set up a comprehensive site to protect kids, including a guide for parents on kid's use of social networks. http://www.onguardonline.gov/ Other places to look are http://www.safeinternet.org/ and http://www.saferinternet.org/. Yes, these are different organisations. jaap From jcurran at arin.net Wed Oct 27 09:07:49 2010 From: jcurran at arin.net (John Curran) Date: Wed, 27 Oct 2010 10:07:49 -0400 Subject: IPv6 Routing table will be bloated? In-Reply-To: <1455908465.13159.1288114278546.JavaMail.root@zimbra.network1.net> References: <1455908465.13159.1288114278546.JavaMail.root@zimbra.network1.net> Message-ID: On Oct 26, 2010, at 1:31 PM, Randy Carpenter wrote: > > I think ARIN is now doing sparse allocations on /28 boundaries. Yes (two NANOG messages attached from earlier this month) /John Begin forwarded message: > From: John Curran > Date: October 18, 2010 2:55:49 PM EDT > To: David Conrad > Cc: North American Network Operators Group > Subject: Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation > > On Oct 18, 2010, at 2:18 PM, David Conrad wrote: >> On Oct 18, 2010, at 6:59 AM, Jack Bates wrote: >>> ARIN does reservations (unsure at what length, but at least down to /31). >> >> Do they still do that? Back when I was at IANA, one of the justifications the RIRs gave for the /12s they received was that they were going to be using the 'bisection' method of allocation which removes the need for reservation. Last I heard, APNIC was using the bisection method... > > ARIN is doing the same (the 'bisection' method) with our IPv6 management > since January 2010: we refer to the "sparse allocation" approach and it > was requested by the community during the ARIN/NANOG Dearborn meeting. > > FYI, > /John > > John Curran > President and CEO > ARIN > Begin forwarded message: > From: John Curran > Date: October 18, 2010 8:14:18 PM EDT > To: North American Network Operators Group > Subject: Re: Definitive Guide to IPv6 adoption - Sparse IPv6 allocation > > On Oct 18, 2010, at 3:42 PM, Randy Carpenter wrote: >> >> I have a few customers whose allocations are /29 away from their nearest neighbor (half a nibble). That seems a little close considering there is a lot of talk about doing nibble boundaries, and there doesn't seem to be consensus yet. >> >> For these customers, I don't think they will need more than a /29, but if we collectively decide that a /28 is the next step from a /32, how will the older allocations be dealt with? This is pretty much a rhetorical question at this point, and I suppose the proper thing to do is to channel these questions toward the PPML for discussion as potential policy. > > Just for reference regarding existing IPv6 sparse practice: > > Our current plan is to use the sparse allocation block (currently a /14) > until we fill it up. Bisection done at the /28 boundary which leaves a > fairly large reserve. > > If an organization needs an allocation larger than a /28, we have set > aside a /15 block for those larger ISPs. > > The orgs that already have allocations (/32s from /29s) also have a > reserve. If they need additional space, they can either request from > their /29 reserve, or if they need more than a /29, can request a new > block. > > Obviously, this can be changed if the community wishes it so. Bring > any obvious suggestions to the ARIN suggestion process, and anything > which might be contentious or affect allocations to the policy process. > > Thanks! > /John > > John Curran > President and CEO > ARIN > From gbonser at seven.com Wed Oct 27 12:06:50 2010 From: gbonser at seven.com (George Bonser) Date: Wed, 27 Oct 2010 10:06:50 -0700 Subject: IPv6 Routing table will be bloated? In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net><9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C54F@RWC-EX1.corp.seven.com> > Subject: RE: IPv6 Routing table will be bloated? > But how do they multihome without an ASN? > If they have an ASN, how did they get it without going to an RIR and > paying a fee? > > Just wanted to note that after exchanging email off list with Jack, I have a better understanding of what he is up against and what he needs makes sense. I retract the "smell test" comment as it was based on my lack of clarity into what exactly the context was. G From ernesto at cs.fiu.edu Wed Oct 27 14:45:56 2010 From: ernesto at cs.fiu.edu (Ernie Rubi) Date: Wed, 27 Oct 2010 15:45:56 -0400 Subject: NSF.gov Unavailable Message-ID: <2157E100-9FAA-46F6-9FA8-F9DC2EF773F0@cs.fiu.edu> Um, down for everyone reports it as down for everyone. Any news as to what may be causing it? Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From sp446 at georgetown.edu Wed Oct 27 14:58:53 2010 From: sp446 at georgetown.edu (Samuel Petreski) Date: Wed, 27 Oct 2010 15:58:53 -0400 Subject: NSF.gov Unavailable In-Reply-To: <2157E100-9FAA-46F6-9FA8-F9DC2EF773F0@cs.fiu.edu> References: <2157E100-9FAA-46F6-9FA8-F9DC2EF773F0@cs.fiu.edu> Message-ID: <023001cb7611$61e859d0$25b90d70$@georgetown.edu> I think they had a fire in the building. --Samuel -- Samuel Petreski Sr. Security Analyst Georgetown University -----Original Message----- From: Ernie Rubi [mailto:ernesto at cs.fiu.edu] Sent: Wednesday, October 27, 2010 3:46 PM To: nanog at nanog.org Subject: NSF.gov Unavailable Um, down for everyone reports it as down for everyone. Any news as to what may be causing it? Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From dga at cs.cmu.edu Wed Oct 27 15:33:20 2010 From: dga at cs.cmu.edu (David Andersen) Date: Wed, 27 Oct 2010 16:33:20 -0400 Subject: NSF.gov Unavailable In-Reply-To: <023001cb7611$61e859d0$25b90d70$@georgetown.edu> References: <2157E100-9FAA-46F6-9FA8-F9DC2EF773F0@cs.fiu.edu> <023001cb7611$61e859d0$25b90d70$@georgetown.edu> Message-ID: <95C8C49E-C01B-4E3B-B172-FFA4F254CEFD@cs.cmu.edu> http://www.arlnow.com/2010/10/27/nsf-building-evacuated-in-ballston-after-apparent-lightning-strike/ lightning strike -> electrical fire -Dave On Oct 27, 2010, at 3:58 PM, Samuel Petreski wrote: > I think they had a fire in the building. > > --Samuel > > -- > Samuel Petreski > Sr. Security Analyst > Georgetown University > > > -----Original Message----- > From: Ernie Rubi [mailto:ernesto at cs.fiu.edu] > Sent: Wednesday, October 27, 2010 3:46 PM > To: nanog at nanog.org > Subject: NSF.gov Unavailable > > Um, down for everyone reports it as down for everyone. > > Any news as to what may be causing it? > > Ernesto M. Rubi > Sr. Network Engineer > AMPATH/CIARA > Florida International Univ, Miami > Reply-to: ernesto at cs.fiu.edu > Cell: 786-282-6783 > > > > > > > From nathan at atlasnetworks.us Wed Oct 27 15:55:20 2010 From: nathan at atlasnetworks.us (Nathan Eisenberg) Date: Wed, 27 Oct 2010 20:55:20 +0000 Subject: NSF.gov Unavailable In-Reply-To: <95C8C49E-C01B-4E3B-B172-FFA4F254CEFD@cs.cmu.edu> References: <2157E100-9FAA-46F6-9FA8-F9DC2EF773F0@cs.fiu.edu> <023001cb7611$61e859d0$25b90d70$@georgetown.edu> <95C8C49E-C01B-4E3B-B172-FFA4F254CEFD@cs.cmu.edu> Message-ID: <8C26A4FDAE599041A13EB499117D3C284063425E@ex-mb-2.corp.atlasnetworks.us> > http://www.arlnow.com/2010/10/27/nsf-building-evacuated-in-ballston- > after-apparent-lightning-strike/ > > lightning strike -> electrical fire > > -Dave At the science foundation. Nature has a sense of irony. From diogo.montagner at gmail.com Wed Oct 27 18:32:35 2010 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Thu, 28 Oct 2010 07:32:35 +0800 Subject: Ethernet performance tests Message-ID: Hello everyone, I am looking for performance test methodology for ethernet-based circuits. These ethernet circuits can be: dark-fiber, l2circuit (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet circuit can be a mix of these technologies, like below: CPE <-> metro-e <-> l2circuit <-> l2vpn <-> l2circuit <-> metro-e <-> CPE The goal is verify the performance end-to-end. I am looking for tools that can check at least the following parameters: - loss - latency - jitter - bandwidth - out-of-order delivery At this moment I have been used IPerf to achieve these results. But I would like to check if there is some test devices that can be used in situations like that to verify the ethernet-based circuit performance. The objective of these tests is to verify the signed SLAs of each circuit before the customer start to use it. I checked all MEF specifications and I only find something related to performance for Circuit Emulation over Metro-E (which is not my case). Appreciate your comments. Thanks! ./diogo -montagner From tate at baumrucker.org Wed Oct 27 18:37:39 2010 From: tate at baumrucker.org (C. Tate Baumrucker) Date: Wed, 27 Oct 2010 19:37:39 -0400 Subject: Ethernet performance tests In-Reply-To: References: Message-ID: <4CC8B7C3.3050706@baumrucker.org> many switch and routing vendors provide such functionality in their os. this data can then be collected via SNMP, stored for reports and forwarded as events, when necessary. tate On 10/27/2010 7:32 PM, Diogo Montagner wrote: > Hello everyone, > > I am looking for performance test methodology for ethernet-based > circuits. These ethernet circuits can be: dark-fiber, l2circuit > (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet > circuit can be a mix of these technologies, like below: > > CPE<-> metro-e<-> l2circuit<-> l2vpn<-> l2circuit<-> metro-e<-> CPE > > The goal is verify the performance end-to-end. > > I am looking for tools that can check at least the following parameters: > > - loss > - latency > - jitter > - bandwidth > - out-of-order delivery > > At this moment I have been used IPerf to achieve these results. But I > would like to check if there is some test devices that can be used in > situations like that to verify the ethernet-based circuit performance. > > The objective of these tests is to verify the signed SLAs of each > circuit before the customer start to use it. > > I checked all MEF specifications and I only find something related to > performance for Circuit Emulation over Metro-E (which is not my case). > > Appreciate your comments. > > Thanks! > ./diogo -montagner > > From Jonathon.Exley at kordia.co.nz Wed Oct 27 19:11:09 2010 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Thu, 28 Oct 2010 13:11:09 +1300 Subject: Ethernet performance tests In-Reply-To: References: Message-ID: <035FE016D625174BA7C7A9FA83E6C17987172C84C8@winexmp02> For comissioning testing, you can use a hardware packet generator to send packets to an Ethernet demarcation with a MAC-swap loopback, and analyse the returned traffic. For ongoing performance monitoring, having Y.1731 capable CPE is highly desirable. Jonathon. -----Original Message----- From: Diogo Montagner [mailto:diogo.montagner at gmail.com] Sent: Thursday, 28 October 2010 12:33 p.m. To: nanog at nanog.org Subject: Ethernet performance tests Hello everyone, I am looking for performance test methodology for ethernet-based circuits. These ethernet circuits can be: dark-fiber, l2circuit (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet circuit can be a mix of these technologies, like below: CPE <-> metro-e <-> l2circuit <-> l2vpn <-> l2circuit <-> metro-e <-> CPE The goal is verify the performance end-to-end. I am looking for tools that can check at least the following parameters: - loss - latency - jitter - bandwidth - out-of-order delivery At this moment I have been used IPerf to achieve these results. But I would like to check if there is some test devices that can be used in situations like that to verify the ethernet-based circuit performance. The objective of these tests is to verify the signed SLAs of each circuit before the customer start to use it. I checked all MEF specifications and I only find something related to performance for Circuit Emulation over Metro-E (which is not my case). Appreciate your comments. Thanks! ./diogo -montagner This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From pauldotwall at gmail.com Wed Oct 27 19:49:13 2010 From: pauldotwall at gmail.com (Paul WALL) Date: Wed, 27 Oct 2010 20:49:13 -0400 Subject: NSF.gov Unavailable In-Reply-To: <8C26A4FDAE599041A13EB499117D3C284063425E@ex-mb-2.corp.atlasnetworks.us> References: <2157E100-9FAA-46F6-9FA8-F9DC2EF773F0@cs.fiu.edu> <023001cb7611$61e859d0$25b90d70$@georgetown.edu> <95C8C49E-C01B-4E3B-B172-FFA4F254CEFD@cs.cmu.edu> <8C26A4FDAE599041A13EB499117D3C284063425E@ex-mb-2.corp.atlasnetworks.us> Message-ID: On Wed, Oct 27, 2010 at 4:55 PM, Nathan Eisenberg wrote: >> http://www.arlnow.com/2010/10/27/nsf-building-evacuated-in-ballston- >> after-apparent-lightning-strike/ >> >> lightning strike -> electrical fire > > At the science foundation. ?Nature has a sense of irony. The real irony is that the folks who brought you the NSFnet apparently didn't get the memo vis-a-vis geographic diversity in one's secondary nameservers (rfc 2182 et al). Always good for a few yuks when ill-mannered MTAs start getting unhappy and dropping mail on the floor rather than queueing because they can't resolve the name rather than can't can't connect to the destination (which just about everyone handles fairly well). nsf.gov. 86400 IN NS swirl.nsf.gov. nsf.gov. 86400 IN NS TWISTER.nsf.gov. nsf.gov. 86400 IN NS WHIRL.nsf.gov. ;; Received 139 bytes from 66.207.175.172#53(f.usadotgov.net) in 70 ms dig: couldn't get address for 'WHIRL.nsf.gov': not found % This happened to the University of Eastern Kentucky a couple of years back during the floods there, and I'm sure it happens to other lower-profile sites on a daily basis. I think there is a lesson in here for the community. Drive Slow, Paul From jackson.tim at gmail.com Wed Oct 27 20:54:20 2010 From: jackson.tim at gmail.com (Tim Jackson) Date: Wed, 27 Oct 2010 20:54:20 -0500 Subject: Ethernet performance tests In-Reply-To: References: Message-ID: We dispatch a technician to an end-site and perform tests either head->head with another test set, or to a loop at a far-end.. We do ITU-T Y.156sam/EtherSAM and/or RFC2544 tests depending on the customer requirements. (some customers require certain tests for x minutes) http://www.exfo.com/en/Products/Products.aspx?Id=370 ^--All of our technicians are equipped with those EXFO sets and that module. Also covers SONET/DS1/DS3 testing as well in a single easy(er) to carry set.. -- Tim On Wed, Oct 27, 2010 at 6:32 PM, Diogo Montagner wrote: > Hello everyone, > > I am looking for performance test methodology for ethernet-based > circuits. These ethernet circuits can be: dark-fiber, l2circuit > (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet > circuit can be a mix of these technologies, like below: > > CPE <-> metro-e <-> l2circuit <-> l2vpn <-> l2circuit <-> metro-e <-> CPE > > The goal is verify the performance end-to-end. > > I am looking for tools that can check at least the following parameters: > > - loss > - latency > - jitter > - bandwidth > - out-of-order delivery > > At this moment I have been used IPerf to achieve these results. But I > would like to check if there is some test devices that can be used in > situations like that to verify the ethernet-based circuit performance. > > The objective of these tests is to verify the signed SLAs of each > circuit before the customer start to use it. > > I checked all MEF specifications and I only find something related to > performance for Circuit Emulation over Metro-E (which is not my case). > > Appreciate your comments. > > Thanks! > ./diogo -montagner > > From jbates at brightok.net Wed Oct 27 21:27:09 2010 From: jbates at brightok.net (Jack Bates) Date: Wed, 27 Oct 2010 21:27:09 -0500 Subject: Ethernet performance tests In-Reply-To: References: Message-ID: <4CC8DF7D.6090304@brightok.net> On 10/27/2010 8:54 PM, Tim Jackson wrote: > We do ITU-T Y.156sam/EtherSAM and/or RFC2544 tests depending on the > customer requirements. (some customers require certain tests for x > minutes) > +1 Think JDSU also has some nice boxes. There's a few rack systems you can use which can either generate packets or provide a home base loop system for the end node test sets depending on your requirements. Jack From mmainer at tekinside.com Wed Oct 27 21:31:53 2010 From: mmainer at tekinside.com (Mike Mainer) Date: Wed, 27 Oct 2010 19:31:53 -0700 Subject: Ethernet performance tests In-Reply-To: References: Message-ID: Exfo, JDSU, Fluke all offer hand held test sets that can run a rfc2544 ( http://www.ietf.org/rfc/rfc2544.txt) test. Do you own the path between cpe <-> cpe? Remeber that for each km of fiber distance add about 4.9ms (one way) of latency. Do basline tests on your cpe gear so you know what you are working with from the being. Different tests at different speeds/cpe hand off (1Gig fiber, 10Gig fiber, Copper @ 10/100/1000) so that all varations are captured. Did this at a pervious company, had to test everything in everything deployable state. On Wed, Oct 27, 2010 at 6:54 PM, Tim Jackson wrote: > We dispatch a technician to an end-site and perform tests either > head->head with another test set, or to a loop at a far-end.. > > We do ITU-T Y.156sam/EtherSAM and/or RFC2544 tests depending on the > customer requirements. (some customers require certain tests for x > minutes) > > http://www.exfo.com/en/Products/Products.aspx?Id=370 > ^--All of our technicians are equipped with those EXFO sets and that > module. Also covers SONET/DS1/DS3 testing as well in a single easy(er) > to carry set.. > > -- > Tim > > On Wed, Oct 27, 2010 at 6:32 PM, Diogo Montagner > wrote: > > Hello everyone, > > > > I am looking for performance test methodology for ethernet-based > > circuits. These ethernet circuits can be: dark-fiber, l2circuit > > (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet > > circuit can be a mix of these technologies, like below: > > > > CPE <-> metro-e <-> l2circuit <-> l2vpn <-> l2circuit <-> metro-e <-> CPE > > > > The goal is verify the performance end-to-end. > > > > I am looking for tools that can check at least the following parameters: > > > > - loss > > - latency > > - jitter > > - bandwidth > > - out-of-order delivery > > > > At this moment I have been used IPerf to achieve these results. But I > > would like to check if there is some test devices that can be used in > > situations like that to verify the ethernet-based circuit performance. > > > > The objective of these tests is to verify the signed SLAs of each > > circuit before the customer start to use it. > > > > I checked all MEF specifications and I only find something related to > > performance for Circuit Emulation over Metro-E (which is not my case). > > > > Appreciate your comments. > > > > Thanks! > > ./diogo -montagner > > > > > > -- -Mike Mainer From jackson.tim at gmail.com Wed Oct 27 21:35:19 2010 From: jackson.tim at gmail.com (Tim Jackson) Date: Wed, 27 Oct 2010 21:35:19 -0500 Subject: Ethernet performance tests In-Reply-To: References: Message-ID: Each KM does not ad 4.9ms...... More like ~1msec per 100km... 1/4/msec usually per OEO conversion (depends on the box)... -- Tim On Wed, Oct 27, 2010 at 9:31 PM, Mike Mainer wrote: > Exfo, JDSU, Fluke all offer hand held test sets that?can run a rfc2544 > (http://www.ietf.org/rfc/rfc2544.txt)?test.? Do you own the path between cpe > <-> cpe?? Remeber that for each km of fiber distance add about 4.9ms (one > way) of latency.? Do basline tests on your cpe gear so you know what you are > working with from the being.? Different tests at different speeds/cpe hand > off (1Gig fiber, 10Gig fiber, Copper @ 10/100/1000) so that all varations > are captured. > > Did this at a pervious company, had to test everything in everything > deployable state. > > > On Wed, Oct 27, 2010 at 6:54 PM, Tim Jackson wrote: >> >> We dispatch a technician to an end-site and perform tests either >> head->head with another test set, or to a loop at a far-end.. >> >> We do ITU-T Y.156sam/EtherSAM and/or RFC2544 tests depending on the >> customer requirements. (some customers require certain tests for x >> minutes) >> >> http://www.exfo.com/en/Products/Products.aspx?Id=370 >> ^--All of our technicians are equipped with those EXFO sets and that >> module. Also covers SONET/DS1/DS3 testing as well in a single easy(er) >> to carry set.. >> >> -- >> Tim >> >> On Wed, Oct 27, 2010 at 6:32 PM, Diogo Montagner >> wrote: >> > Hello everyone, >> > >> > I am looking for performance test methodology for ethernet-based >> > circuits. These ethernet circuits can be: dark-fiber, l2circuit >> > (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet >> > circuit can be a mix of these technologies, like below: >> > >> > CPE <-> metro-e <-> l2circuit <-> l2vpn <-> l2circuit <-> metro-e <-> >> > CPE >> > >> > The goal is verify the performance end-to-end. >> > >> > I am looking for tools that can check at least the following parameters: >> > >> > - loss >> > - latency >> > - jitter >> > - bandwidth >> > - out-of-order delivery >> > >> > At this moment I have been used IPerf to achieve these results. But I >> > would like to check if there is some test devices that can be used in >> > situations like that to verify the ethernet-based circuit performance. >> > >> > The objective of these tests is to verify the signed SLAs of each >> > circuit before the customer start to use it. >> > >> > I checked all MEF specifications and I only find something related to >> > performance for Circuit Emulation over Metro-E (which is not my case). >> > >> > Appreciate your comments. >> > >> > Thanks! >> > ./diogo -montagner >> > >> > >> > > > > -- > -Mike Mainer > From diogo.montagner at gmail.com Wed Oct 27 21:45:50 2010 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Thu, 28 Oct 2010 10:45:50 +0800 Subject: Ethernet performance tests In-Reply-To: References: Message-ID: Hello everyone!!! Thank you for all answers. These answers are really what I was looking for!!!! Regards ./diogo -montagner On Thu, Oct 28, 2010 at 10:35 AM, Tim Jackson wrote: > Each KM does not ad 4.9ms...... > > More like ~1msec per 100km... > > 1/4/msec usually per OEO conversion (depends on the box)... > > -- > Tim > > On Wed, Oct 27, 2010 at 9:31 PM, Mike Mainer wrote: >> Exfo, JDSU, Fluke all offer hand held test sets that?can run a rfc2544 >> (http://www.ietf.org/rfc/rfc2544.txt)?test.? Do you own the path between cpe >> <-> cpe?? Remeber that for each km of fiber distance add about 4.9ms (one >> way) of latency.? Do basline tests on your cpe gear so you know what you are >> working with from the being.? Different tests at different speeds/cpe hand >> off (1Gig fiber, 10Gig fiber, Copper @ 10/100/1000) so that all varations >> are captured. >> >> Did this at a pervious company, had to test everything in everything >> deployable state. >> >> >> On Wed, Oct 27, 2010 at 6:54 PM, Tim Jackson wrote: >>> >>> We dispatch a technician to an end-site and perform tests either >>> head->head with another test set, or to a loop at a far-end.. >>> >>> We do ITU-T Y.156sam/EtherSAM and/or RFC2544 tests depending on the >>> customer requirements. (some customers require certain tests for x >>> minutes) >>> >>> http://www.exfo.com/en/Products/Products.aspx?Id=370 >>> ^--All of our technicians are equipped with those EXFO sets and that >>> module. Also covers SONET/DS1/DS3 testing as well in a single easy(er) >>> to carry set.. >>> >>> -- >>> Tim >>> >>> On Wed, Oct 27, 2010 at 6:32 PM, Diogo Montagner >>> wrote: >>> > Hello everyone, >>> > >>> > I am looking for performance test methodology for ethernet-based >>> > circuits. These ethernet circuits can be: dark-fiber, l2circuit >>> > (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet >>> > circuit can be a mix of these technologies, like below: >>> > >>> > CPE <-> metro-e <-> l2circuit <-> l2vpn <-> l2circuit <-> metro-e <-> >>> > CPE >>> > >>> > The goal is verify the performance end-to-end. >>> > >>> > I am looking for tools that can check at least the following parameters: >>> > >>> > - loss >>> > - latency >>> > - jitter >>> > - bandwidth >>> > - out-of-order delivery >>> > >>> > At this moment I have been used IPerf to achieve these results. But I >>> > would like to check if there is some test devices that can be used in >>> > situations like that to verify the ethernet-based circuit performance. >>> > >>> > The objective of these tests is to verify the signed SLAs of each >>> > circuit before the customer start to use it. >>> > >>> > I checked all MEF specifications and I only find something related to >>> > performance for Circuit Emulation over Metro-E (which is not my case). >>> > >>> > Appreciate your comments. >>> > >>> > Thanks! >>> > ./diogo -montagner >>> > >>> > >>> >> >> >> >> -- >> -Mike Mainer >> > From Skeeve at eintellego.net Wed Oct 27 22:32:37 2010 From: Skeeve at eintellego.net (Skeeve Stevens) Date: Thu, 28 Oct 2010 14:32:37 +1100 Subject: DSL (or other similar) Connection in Singapore Message-ID: <292AF25E62B8894C921B893B53A19D9739AF595D21@BUSINESSEX.business.ad> Hey all, I have an urgent (today/tomorrow) requirement for how to deliver a normal internet service in Singapore... most likely the downtown area. Has anyone got any contacts or links to pricing - also maybe someone who can install a router configured in Australia. I'm looking for a good download limit includes, or flat rate, with static IP a must. Please reply off-list. PS.. I realise this is NANog, but I assume people on this list may service international offices for their organisations. ...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 www.linkedin.com/in/skeeve ; facebook.com/eintellego -- eintellego - The Experts that the Experts call - Juniper - HP Networking - Cisco - Arista - Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. From randy at psg.com Wed Oct 27 22:56:19 2010 From: randy at psg.com (Randy Bush) Date: Thu, 28 Oct 2010 12:56:19 +0900 Subject: DSL (or other similar) Connection in Singapore In-Reply-To: <292AF25E62B8894C921B893B53A19D9739AF595D21@BUSINESSEX.business.ad> References: <292AF25E62B8894C921B893B53A19D9739AF595D21@BUSINESSEX.business.ad> Message-ID: > Disclaimer: Limits of Liability and Disclaimer: This message is for the named person's use only. It may contain sensitive and private proprietary or legally privileged information. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. eintellego Pty Ltd and each legal entity in the Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail communications through its networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity. Any reference to costs, fee quotations, contractual transactions and variations to contract terms is subject to separate confirmation in writing signed by an authorised representative of eintellego. Whilst all efforts are made to safeguard inbound and outbound e-mails, we cannot guarantee that attachments are virus-free or compatible with your systems and do not accept any liability in respect of viruses or computer problems experienced. you have sent a message to me which seems to contain a legal warning on who can read it, or how it may be distributed, or whether it may be archived, etc. i do not accept such email. my mail user agent detected a legal notice when i was opening your mail, and automatically deleted it. so do not expect further response. yes, i know your mail environment automatically added the legal notice. well, my mail environment automatically detected it, deleted it, and sent this message to you. so don't expect a lot of sympathy. and if you choose to work for some enterprise clueless enough to think that they can force this silliness on the world, use gmail, hotmail, ... randy From uri.joskovitch at telrad.com Wed Oct 27 23:34:34 2010 From: uri.joskovitch at telrad.com (Uri Joskovitch) Date: Thu, 28 Oct 2010 06:34:34 +0200 Subject: NSF.gov Unavailable Message-ID: <147c01cb7659$c3c3a08a$b03a5a3e@Telrad.co.il> Ernie Rubi ???? ?? ???: Um, down for everyone reports it as down for everyone. Any news as to what may be causing it? Ernesto M. Rubi Sr. Network Engineer AMPATH/CIARA Florida International Univ, Miami Reply-to: ernesto at cs.fiu.edu Cell: 786-282-6783 From diogo.montagner at gmail.com Thu Oct 28 05:12:16 2010 From: diogo.montagner at gmail.com (Diogo Montagner) Date: Thu, 28 Oct 2010 18:12:16 +0800 Subject: DSL (or other similar) Connection in Singapore In-Reply-To: <292AF25E62B8894C921B893B53A19D9739AF595D21@BUSINESSEX.business.ad> References: <292AF25E62B8894C921B893B53A19D9739AF595D21@BUSINESSEX.business.ad> Message-ID: I think you can try Singtel. Rgs On 10/28/10, Skeeve Stevens wrote: > Hey all, > > I have an urgent (today/tomorrow) requirement for how to deliver a normal > internet service in Singapore... most likely the downtown area. > > Has anyone got any contacts or links to pricing - also maybe someone who can > install a router configured in Australia. > > I'm looking for a good download limit includes, or flat rate, with static IP > a must. > > Please reply off-list. > > PS.. I realise this is NANog, but I assume people on this list may service > international offices for their organisations. > > ...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 > www.linkedin.com/in/skeeve ; facebook.com/eintellego > -- > eintellego - The Experts that the Experts call > - Juniper - HP Networking - Cisco - Arista - > > Disclaimer: Limits of Liability and Disclaimer: This message is for the > named person's use only. It may contain sensitive and private proprietary or > legally privileged information. You must not, directly or indirectly, use, > disclose, distribute, print, or copy any part of this message if you are not > the intended recipient. eintellego Pty Ltd and each legal entity in the > Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail > communications through its networks. Any views expressed in this message > are those of the individual sender, except where the message states > otherwise and the sender is authorised to state them to be the views of any > such entity. Any reference to costs, fee quotations, contractual > transactions and variations to contract terms is subject to separate > confirmation in writing signed by an authorised representative of > eintellego. Whilst all efforts are made to safeguard inbound and outbound > e-mails, we cannot guarantee that attachments are virus-free or compatible > with your systems and do not accept any liability in respect of viruses or > computer problems experienced. > > -- Sent from my mobile device ./diogo -montagner From sgridelli at gmail.com Thu Oct 28 07:07:37 2010 From: sgridelli at gmail.com (Stefano Gridelli) Date: Thu, 28 Oct 2010 08:07:37 -0400 Subject: Ethernet performance tests In-Reply-To: References: Message-ID: Hi Diogo We use ixchariot endpoints installed on linux laptops to test sites for voice readiness. Ixchariot calculates for you the MOS score and, depending from the NIC, can also push close to 1 Gig of traffic. For larger bandwidth tests (I believe 6-7 Gig) and fast re-route testing (ms failover) we use ixia hardware. Ciao On 10/27/10, Diogo Montagner wrote: > Hello everyone!!! > > Thank you for all answers. These answers are really what I was looking > for!!!! > > Regards > ./diogo -montagner > > > > On Thu, Oct 28, 2010 at 10:35 AM, Tim Jackson wrote: >> Each KM does not ad 4.9ms...... >> >> More like ~1msec per 100km... >> >> 1/4/msec usually per OEO conversion (depends on the box)... >> >> -- >> Tim >> >> On Wed, Oct 27, 2010 at 9:31 PM, Mike Mainer >> wrote: >>> Exfo, JDSU, Fluke all offer hand held test sets that?can run a rfc2544 >>> (http://www.ietf.org/rfc/rfc2544.txt)?test.? Do you own the path between >>> cpe >>> <-> cpe?? Remeber that for each km of fiber distance add about 4.9ms (one >>> way) of latency.? Do basline tests on your cpe gear so you know what you >>> are >>> working with from the being.? Different tests at different speeds/cpe >>> hand >>> off (1Gig fiber, 10Gig fiber, Copper @ 10/100/1000) so that all varations >>> are captured. >>> >>> Did this at a pervious company, had to test everything in everything >>> deployable state. >>> >>> >>> On Wed, Oct 27, 2010 at 6:54 PM, Tim Jackson >>> wrote: >>>> >>>> We dispatch a technician to an end-site and perform tests either >>>> head->head with another test set, or to a loop at a far-end.. >>>> >>>> We do ITU-T Y.156sam/EtherSAM and/or RFC2544 tests depending on the >>>> customer requirements. (some customers require certain tests for x >>>> minutes) >>>> >>>> http://www.exfo.com/en/Products/Products.aspx?Id=370 >>>> ^--All of our technicians are equipped with those EXFO sets and that >>>> module. Also covers SONET/DS1/DS3 testing as well in a single easy(er) >>>> to carry set.. >>>> >>>> -- >>>> Tim >>>> >>>> On Wed, Oct 27, 2010 at 6:32 PM, Diogo Montagner >>>> wrote: >>>> > Hello everyone, >>>> > >>>> > I am looking for performance test methodology for ethernet-based >>>> > circuits. These ethernet circuits can be: dark-fiber, l2circuit >>>> > (martini), l2vpn (kompella), vpls or ng-vpls. Sometimes, the ethernet >>>> > circuit can be a mix of these technologies, like below: >>>> > >>>> > CPE <-> metro-e <-> l2circuit <-> l2vpn <-> l2circuit <-> metro-e <-> >>>> > CPE >>>> > >>>> > The goal is verify the performance end-to-end. >>>> > >>>> > I am looking for tools that can check at least the following >>>> > parameters: >>>> > >>>> > - loss >>>> > - latency >>>> > - jitter >>>> > - bandwidth >>>> > - out-of-order delivery >>>> > >>>> > At this moment I have been used IPerf to achieve these results. But I >>>> > would like to check if there is some test devices that can be used in >>>> > situations like that to verify the ethernet-based circuit performance. >>>> > >>>> > The objective of these tests is to verify the signed SLAs of each >>>> > circuit before the customer start to use it. >>>> > >>>> > I checked all MEF specifications and I only find something related to >>>> > performance for Circuit Emulation over Metro-E (which is not my case). >>>> > >>>> > Appreciate your comments. >>>> > >>>> > Thanks! >>>> > ./diogo -montagner >>>> > >>>> > >>>> >>> >>> >>> >>> -- >>> -Mike Mainer >>> >> > > -- Sent from my mobile device From tme at americafree.tv Thu Oct 28 13:16:25 2010 From: tme at americafree.tv (Marshall Eubanks) Date: Thu, 28 Oct 2010 14:16:25 -0400 Subject: Bandwidth into Haiti Message-ID: Can anyone update me on the status of fiber bandwidth into Haiti ? Has the landing station been repaired yet after last years earthquake ? Regards Marshall Eubanks From bruns at 2mbit.com Thu Oct 28 13:55:56 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Thu, 28 Oct 2010 12:55:56 -0600 Subject: Odd cableone traceroute with 0.0.0.0 in path Message-ID: <4CC9C73C.3010702@2mbit.com> Okay, so this has my head hurting a bit just trying to figure out just how this is possible and what kind of equipment would pull this stunt. Tracing from here (cableone cable modem) to the outside world, I end up with the following at the beginning of my traceroute. 1 192.168.1.1 (192.168.1.1) 2.759 ms 0.803 ms 0.769 ms 2 0.0.0.0 (0.0.0.0) 10.462 ms 9.543 ms 8.043 ms 3 192.168.32.65 (192.168.32.65) 9.984 ms 9.654 ms 9.570 ms 4 te-4-4.car2.seattle1.level3.net (4.53.146.117) 25.960 ms 21.798 ms 24.144 ms .... etc 0.0.0.0 as one of the hops. So, I pulled out LFT to make sure traceroute isn't going nuts. Layer Four Traceroute (LFT) version 3.1 Using device en1, 192.168.1.101:53 TTL LFT trace to 207.70.17.213:80/tcp 1 192.168.1.1 0.9/0.9ms 2 /9.8/10.3ms 3 192.168.32.65 9.7/8.3ms 4 10.255.255.1 9.1/8.4ms 5 te-4-4.car2.seattle1.level3.net (4.53.146.117) 29.0/20.2ms Fun, no entry for hop 2, plus there's an extra hop at #4. Lets use verbose. Layer Four Traceroute (LFT) version 3.1 ... (verbosity level 2) Using device en1, 192.168.1.101:53 SENT TCP TTL=1 SEQ=648736948 FLAGS=0x2 ( SYN ) SENT TCP TTL=2 SEQ=648736949 FLAGS=0x2 ( SYN ) RCVD ICMP SEQ=648736948 SRC=192.168.1.1 PTTL=1 PSEQ=648736948 SENT TCP TTL=3 SEQ=648736950 FLAGS=0x2 ( SYN ) SENT TCP TTL=4 SEQ=648736951 FLAGS=0x2 ( SYN ) SENT TCP TTL=5 SEQ=648736952 FLAGS=0x2 ( SYN ) SENT TCP TTL=6 SEQ=648736953 FLAGS=0x2 ( SYN ) RCVD ICMP SEQ=648736949 SRC=0.0.0.0 PTTL=2 PSEQ=648736949 SENT TCP TTL=7 SEQ=648736954 FLAGS=0x2 ( SYN ) RCVD ICMP SEQ=648736950 SRC=192.168.32.65 PTTL=3 PSEQ=648736950 RCVD ICMP SEQ=648736951 SRC=10.255.255.1 PTTL=4 PSEQ=648736951 RCVD ICMP SEQ=648736953 SRC=4.68.105.30 PTTL=6 PSEQ=648736953 Am I going nuts, or is something really messed up somewhere upstream from the cable modem? To quote someone from IRC who's just as confused, "the null route just talked to me". -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org From zaid at zaidali.com Thu Oct 28 15:08:02 2010 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 28 Oct 2010 13:08:02 -0700 Subject: Interesting IPv6 viral video Message-ID: Not quite accurate and a bit too dramatic on the panic side but the approach is interesting to put C-Level folks in the hot seat about v6. Would be interesting also to see if folks here get asked by C-Level folks bout IPv6. http://www.youtube.com/watch?v=eYffYT2y-Iw Zaid From nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org Thu Oct 28 15:14:58 2010 From: nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org (Mark Smith) Date: Fri, 29 Oct 2010 06:44:58 +1030 Subject: Odd cableone traceroute with 0.0.0.0 in path In-Reply-To: <4CC9C73C.3010702@2mbit.com> References: <4CC9C73C.3010702@2mbit.com> Message-ID: <20101029064458.454d1f3c@opy.nosense.org> On Thu, 28 Oct 2010 12:55:56 -0600 Brielle Bruns wrote: > Okay, so this has my head hurting a bit just trying to figure out just > how this is possible and what kind of equipment would pull this stunt. > My initial guess was that somebody put "0.0.0.0" text as the DNS PTR RR value for that hop, however that isn't the case as both the name and the IP address of the hop are 0.0.0.0. My guess is that the ICMP error that traceroute uses to detect hops is being sourced from 0.0.0.0 for some reason. Your cable modem wouldn't be performing any RPF on incoming traffic, so there is nothing to filter out 0.0.0.0 as an invalid source address (or it may actually be valid for these ICMP errors - it's the "unspecified" address.) > > Tracing from here (cableone cable modem) to the outside world, I end up > with the following at the beginning of my traceroute. > > > 1 192.168.1.1 (192.168.1.1) 2.759 ms 0.803 ms 0.769 ms > 2 0.0.0.0 (0.0.0.0) 10.462 ms 9.543 ms 8.043 ms > 3 192.168.32.65 (192.168.32.65) 9.984 ms 9.654 ms 9.570 ms > 4 te-4-4.car2.seattle1.level3.net (4.53.146.117) 25.960 ms 21.798 > ms 24.144 ms > .... etc > > 0.0.0.0 as one of the hops. So, I pulled out LFT to make sure > traceroute isn't going nuts. > > Layer Four Traceroute (LFT) version 3.1 > Using device en1, 192.168.1.101:53 > TTL LFT trace to 207.70.17.213:80/tcp > 1 192.168.1.1 0.9/0.9ms > 2 /9.8/10.3ms > 3 192.168.32.65 9.7/8.3ms > 4 10.255.255.1 9.1/8.4ms > 5 te-4-4.car2.seattle1.level3.net (4.53.146.117) 29.0/20.2ms > > Fun, no entry for hop 2, plus there's an extra hop at #4. Lets use verbose. > > Layer Four Traceroute (LFT) version 3.1 ... (verbosity level 2) > Using device en1, 192.168.1.101:53 > SENT TCP TTL=1 SEQ=648736948 FLAGS=0x2 ( SYN ) > SENT TCP TTL=2 SEQ=648736949 FLAGS=0x2 ( SYN ) > RCVD ICMP SEQ=648736948 SRC=192.168.1.1 PTTL=1 PSEQ=648736948 > SENT TCP TTL=3 SEQ=648736950 FLAGS=0x2 ( SYN ) > SENT TCP TTL=4 SEQ=648736951 FLAGS=0x2 ( SYN ) > SENT TCP TTL=5 SEQ=648736952 FLAGS=0x2 ( SYN ) > SENT TCP TTL=6 SEQ=648736953 FLAGS=0x2 ( SYN ) > RCVD ICMP SEQ=648736949 SRC=0.0.0.0 PTTL=2 PSEQ=648736949 > SENT TCP TTL=7 SEQ=648736954 FLAGS=0x2 ( SYN ) > RCVD ICMP SEQ=648736950 SRC=192.168.32.65 PTTL=3 PSEQ=648736950 > RCVD ICMP SEQ=648736951 SRC=10.255.255.1 PTTL=4 PSEQ=648736951 > RCVD ICMP SEQ=648736953 SRC=4.68.105.30 PTTL=6 PSEQ=648736953 > > > Am I going nuts, or is something really messed up somewhere upstream > from the cable modem? To quote someone from IRC who's just as confused, > "the null route just talked to me". > > -- > Brielle Bruns > The Summit Open Source Development Group > http://www.sosdg.org / http://www.ahbl.org > From mike at sentex.net Thu Oct 28 14:17:17 2010 From: mike at sentex.net (Mike Tancsa) Date: Thu, 28 Oct 2010 15:17:17 -0400 Subject: Odd cableone traceroute with 0.0.0.0 in path In-Reply-To: <4CC9C73C.3010702@2mbit.com> References: <4CC9C73C.3010702@2mbit.com> Message-ID: <201010281917.o9SJHNAi055771@lava.sentex.ca> At 02:55 PM 10/28/2010, Brielle Bruns wrote: >Okay, so this has my head hurting a bit just trying to figure out >just how this is possible and what kind of equipment would pull this stunt. misconfig of a p2p addr somewhere ? perhaps someone used 0.0.0.0/30 as a p2p addr for kicks. e.g. I just tried this at home. on a next hop router, # ifconfig igb1 0.0.0.0/30 alias on a node/workstation behind the above router 0(i5)# ifconfig em0 0.0.0.1/30 alias 0(i5)# route add 173.194.32.104 0.0.0.0 0(i5)# telnet -s 10.255.255.27 173.194.32.104 80 Trying 173.194.32.104... Connected to yyz06s05-in-f104.1e100.net. Escape character is '^]'. And looking for the arp who has, it is indeed asking for 0.0.0.0's MAC addr for the next hop. 15:07:38.308758 00:15:17:ed:36:e5 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: Request who-has 0.0.0.0 tell 0.0.0.1, length 46 15:07:38.308764 00:30:48:94:88:21 > 00:15:17:ed:36:e5, ethertype ARP (0x0806), length 42: Reply 0.0.0.0 is-at 00:30:48:94:88:21, length 28 ---Mike >Tracing from here (cableone cable modem) to the outside world, I end >up with the following at the beginning of my traceroute. > > 1 192.168.1.1 (192.168.1.1) 2.759 ms 0.803 ms 0.769 ms > 2 0.0.0.0 (0.0.0.0) 10.462 ms 9.543 ms 8.043 ms > 3 192.168.32.65 (192.168.32.65) 9.984 ms 9.654 ms 9.570 ms > 4 te-4-4.car2.seattle1.level3.net (4.53.146.117) 25.960 > ms 21.798 ms 24.144 ms >.... etc > >0.0.0.0 as one of the hops. So, I pulled out LFT to make sure >traceroute isn't going nuts. > >Layer Four Traceroute (LFT) version 3.1 >Using device en1, 192.168.1.101:53 >TTL LFT trace to 207.70.17.213:80/tcp > 1 192.168.1.1 0.9/0.9ms > 2 /9.8/10.3ms > 3 192.168.32.65 9.7/8.3ms > 4 10.255.255.1 9.1/8.4ms > 5 te-4-4.car2.seattle1.level3.net (4.53.146.117) 29.0/20.2ms > >Fun, no entry for hop 2, plus there's an extra hop at #4. Lets use verbose. > >Layer Four Traceroute (LFT) version 3.1 ... (verbosity level 2) >Using device en1, 192.168.1.101:53 >SENT TCP TTL=1 SEQ=648736948 FLAGS=0x2 ( SYN ) >SENT TCP TTL=2 SEQ=648736949 FLAGS=0x2 ( SYN ) >RCVD ICMP SEQ=648736948 SRC=192.168.1.1 PTTL=1 PSEQ=648736948 >SENT TCP TTL=3 SEQ=648736950 FLAGS=0x2 ( SYN ) >SENT TCP TTL=4 SEQ=648736951 FLAGS=0x2 ( SYN ) >SENT TCP TTL=5 SEQ=648736952 FLAGS=0x2 ( SYN ) >SENT TCP TTL=6 SEQ=648736953 FLAGS=0x2 ( SYN ) >RCVD ICMP SEQ=648736949 SRC=0.0.0.0 PTTL=2 PSEQ=648736949 >SENT TCP TTL=7 SEQ=648736954 FLAGS=0x2 ( SYN ) >RCVD ICMP SEQ=648736950 SRC=192.168.32.65 PTTL=3 PSEQ=648736950 >RCVD ICMP SEQ=648736951 SRC=10.255.255.1 PTTL=4 PSEQ=648736951 >RCVD ICMP SEQ=648736953 SRC=4.68.105.30 PTTL=6 PSEQ=648736953 > > >Am I going nuts, or is something really messed up somewhere upstream >from the cable modem? To quote someone from IRC who's just as >confused, "the null route just talked to me". > >-- >Brielle Bruns >The Summit Open Source Development Group >http://www.sosdg.org / http://www.ahbl.org -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike at sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From oberman at es.net Thu Oct 28 15:59:16 2010 From: oberman at es.net (Kevin Oberman) Date: Thu, 28 Oct 2010 13:59:16 -0700 Subject: Interesting IPv6 viral video In-Reply-To: Your message of "Thu, 28 Oct 2010 13:08:02 PDT." Message-ID: <20101028205916.B07111CC45@ptavv.es.net> > Date: Thu, 28 Oct 2010 13:08:02 -0700 > From: Zaid Ali > > Not quite accurate and a bit too dramatic on the panic side but the approach > is interesting to put C-Level folks in the hot seat about v6. Would be > interesting also to see if folks here get asked by C-Level folks bout IPv6. > > http://www.youtube.com/watch?v=eYffYT2y-Iw Cute. Silly, but cute. I think I see Tony Hain's hand somewhere in this. Tony??? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owen at delong.com Thu Oct 28 16:04:49 2010 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Oct 2010 14:04:49 -0700 Subject: Interesting IPv6 viral video In-Reply-To: References: Message-ID: On Oct 28, 2010, at 1:08 PM, Zaid Ali wrote: > Not quite accurate and a bit too dramatic on the panic side but the approach > is interesting to put C-Level folks in the hot seat about v6. Would be > interesting also to see if folks here get asked by C-Level folks bout IPv6. > > http://www.youtube.com/watch?v=eYffYT2y-Iw > > Zaid > > ROFLMAO... Yeah, it's overstated and ridiculous, but, I especially laughed at the follow-on video for "ignore the benefits of IPv6". Owen From bicknell at ufp.org Thu Oct 28 16:11:28 2010 From: bicknell at ufp.org (Leo Bicknell) Date: Thu, 28 Oct 2010 14:11:28 -0700 Subject: Interesting IPv6 viral video In-Reply-To: References: Message-ID: <20101028211128.GA71763@ussenterprise.ufp.org> In a message written on Thu, Oct 28, 2010 at 01:08:02PM -0700, Zaid Ali wrote: > Not quite accurate and a bit too dramatic on the panic side but the approach > is interesting to put C-Level folks in the hot seat about v6. Would be > interesting also to see if folks here get asked by C-Level folks bout IPv6. If you have been trying to get your C-Level folks to understand the problem for months or years and they won't listen, yet they come to you after watching this Cisco video then you should go visit www.monster.com, or www.careerbuilder.com. -- 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 Jonathon.Exley at kordia.co.nz Thu Oct 28 16:16:40 2010 From: Jonathon.Exley at kordia.co.nz (Jonathon Exley) Date: Fri, 29 Oct 2010 10:16:40 +1300 Subject: Ethernet performance tests In-Reply-To: References: Message-ID: <035FE016D625174BA7C7A9FA83E6C17987172C87D8@winexmp02> How smooth is the Ixchariot data stream? When Chariot was a NetIQ product it seemed to generate regular spikes as the algorithm tried to correct the total throughput over a time interval. It's not a problem for slow data rates but when testing near the limit of a circuit's capacity the spikes could sometimes overflow the buffers of Ethernet media converters and give false results. Jonathon -----Original Message----- From: Stefano Gridelli [mailto:sgridelli at gmail.com] Sent: Friday, 29 October 2010 1:08 a.m. To: Diogo Montagner; Tim Jackson; nanog at nanog.org Subject: Re: Ethernet performance tests Hi Diogo We use ixchariot endpoints installed on linux laptops to test sites for voice readiness. Ixchariot calculates for you the MOS score and, depending from the NIC, can also push close to 1 Gig of traffic. For larger bandwidth tests (I believe 6-7 Gig) and fast re-route testing (ms failover) we use ixia hardware. Ciao This email and attachments: are confidential; may be protected by privilege and copyright; if received in error may not be used,copied, or kept; are not guaranteed to be virus-free; may not express the views of Kordia(R); do not designate an information system; and do not give rise to any liability for Kordia(R). From pfunix at gmail.com Thu Oct 28 16:24:15 2010 From: pfunix at gmail.com (Beavis) Date: Thu, 28 Oct 2010 15:24:15 -0600 Subject: Interesting IPv6 viral video In-Reply-To: References: Message-ID: lol... Is this video by cisco? what a funny way to mis-inform non-tech folks. On Thu, Oct 28, 2010 at 2:08 PM, Zaid Ali wrote: > Not quite accurate and a bit too dramatic on the panic side but the approach > is interesting to put C-Level folks in the hot seat about v6. Would be > interesting also to see if folks here get asked by C-Level folks bout IPv6. > > http://www.youtube.com/watch?v=eYffYT2y-Iw > > Zaid > > > > -- ()? ascii ribbon campaign - against html e-mail /\? www.asciiribbon.org?? - against proprietary attachments From zaid at zaidali.com Thu Oct 28 16:29:45 2010 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 28 Oct 2010 14:29:45 -0700 Subject: Interesting IPv6 viral video In-Reply-To: <20101028211128.GA71763@ussenterprise.ufp.org> Message-ID: On 10/28/10 2:11 PM, "Leo Bicknell" wrote: > If you have been trying to get your C-Level folks to understand the > problem for months or years and they won't listen, yet they come > to you after watching this Cisco video then you should go visit > www.monster.com, or www.careerbuilder.com. I don't have this problem thankfully but I know many do and it is probably the major reason why v6 adoption is slow. Many networks needs money invested to upgrade for v6 readiness. The message is do it now before the costs dramatically increase. The problem with C-level folks is not they don't want to do it but there is no financial incentive for them to do it, if there is no direct benefit to drive revenue then why put the money? The barrier for v6 is not technical it is purely financial, some understand the economics and some don't. Finance people usually think that the longer you can put off expenses the better it looks for your balance sheet. This is really the crux of the problem. Zaid From zaid at zaidali.com Thu Oct 28 16:32:06 2010 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 28 Oct 2010 14:32:06 -0700 Subject: Interesting IPv6 viral video In-Reply-To: Message-ID: On 10/28/10 2:24 PM, "Beavis" wrote: > lol... Is this video by cisco? what a funny way to mis-inform non-tech folks. Yes it is. When do marketing people get it right? I actually think the fun hasn't begun yet. Wait till CNN/FOX etc makes this a big issue and claim the internet is going to come to an end then folks with clue will have to go on TV and calm the hysteria. Zaid From alh-ietf at tndh.net Thu Oct 28 16:33:29 2010 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 28 Oct 2010 14:33:29 -0700 Subject: Interesting IPv6 viral video In-Reply-To: <20101028205916.B07111CC45@ptavv.es.net> References: Your message of "Thu, 28 Oct 2010 13:08:02 PDT." <20101028205916.B07111CC45@ptavv.es.net> Message-ID: <091101cb76e7$c41dee90$4c59cbb0$@net> No idea where this came from, and no I didn't have any part in it. If I had, the rental rates on addresses would have been much more in the range of extortion... ;) > -----Original Message----- > From: Kevin Oberman [mailto:oberman at es.net] > Sent: Thursday, October 28, 2010 1:59 PM > To: Zaid Ali > Cc: NANOG list > Subject: Re: Interesting IPv6 viral video > > > Date: Thu, 28 Oct 2010 13:08:02 -0700 > > From: Zaid Ali > > > > Not quite accurate and a bit too dramatic on the panic side but the > approach > > is interesting to put C-Level folks in the hot seat about v6. Would > be > > interesting also to see if folks here get asked by C-Level folks bout > IPv6. > > > > http://www.youtube.com/watch?v=eYffYT2y-Iw > > Cute. Silly, but cute. I think I see Tony Hain's hand somewhere in > this. > > Tony??? > -- > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: oberman at es.net Phone: +1 510 486-8634 > Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From jay at west.net Thu Oct 28 16:38:03 2010 From: jay at west.net (Jay Hennigan) Date: Thu, 28 Oct 2010 14:38:03 -0700 Subject: Interesting IPv6 viral video In-Reply-To: References: Message-ID: <4CC9ED3B.4060808@west.net> On 10/28/10 2:32 PM, Zaid Ali wrote: > > On 10/28/10 2:24 PM, "Beavis" wrote: > >> lol... Is this video by cisco? what a funny way to mis-inform non-tech folks. > > Yes it is. When do marketing people get it right? I actually think the fun > hasn't begun yet. Wait till CNN/FOX etc makes this a big issue and claim the > internet is going to come to an end then folks with clue will have to go on > TV and calm the hysteria. Like this? http://www.youtube.com/watch?v=QAUyaELfwBo -- Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net Impulse Internet Service - http://www.impulse.net/ Your local telephone and internet company - 805 884-6323 - WB6RDV From jbates at brightok.net Thu Oct 28 16:38:51 2010 From: jbates at brightok.net (Jack Bates) Date: Thu, 28 Oct 2010 16:38:51 -0500 Subject: Interesting IPv6 viral video In-Reply-To: References: Message-ID: <4CC9ED6B.3050101@brightok.net> On 10/28/2010 4:32 PM, Zaid Ali wrote: > Yes it is. When do marketing people get it right? I actually think the fun > hasn't begun yet. Wait till CNN/FOX etc makes this a big issue and claim the > internet is going to come to an end then folks with clue will have to go on > TV and calm the hysteria. > Why would someone with clue want to calm the hysteria? I've had hysterical moments dealing with v6 transitions. Come to and end? Nah. Be a really rough ride? Unless things change, probably. Jack From pfunix at gmail.com Thu Oct 28 16:53:11 2010 From: pfunix at gmail.com (Beavis) Date: Thu, 28 Oct 2010 15:53:11 -0600 Subject: Interesting IPv6 viral video In-Reply-To: <4CC9ED3B.4060808@west.net> References: <4CC9ED3B.4060808@west.net> Message-ID: haha... definitely like this!!! :D On Thu, Oct 28, 2010 at 3:38 PM, Jay Hennigan wrote: > On 10/28/10 2:32 PM, Zaid Ali wrote: >> >> On 10/28/10 2:24 PM, "Beavis" wrote: >> >>> lol... Is this video by cisco? what a funny way to mis-inform non-tech folks. >> >> Yes it is. When do marketing people get it right? I actually think the fun >> hasn't begun yet. Wait till CNN/FOX etc makes this a big issue and claim the >> internet is going to come to an end then folks with clue will have to go on >> TV and calm the hysteria. > > Like this? > > http://www.youtube.com/watch?v=QAUyaELfwBo > > -- > Jay Hennigan - CCIE #7880 - Network Engineering - jay at impulse.net > Impulse Internet Service ?- ?http://www.impulse.net/ > Your local telephone and internet company - 805 884-6323 - WB6RDV > > -- ()? ascii ribbon campaign - against html e-mail /\? www.asciiribbon.org?? - against proprietary attachments From dseagrav at humancapitaldev.com Thu Oct 28 16:54:14 2010 From: dseagrav at humancapitaldev.com (Daniel Seagraves) Date: Thu, 28 Oct 2010 16:54:14 -0500 Subject: Interesting IPv6 viral video In-Reply-To: <4CC9ED6B.3050101@brightok.net> References: <4CC9ED6B.3050101@brightok.net> Message-ID: <80C192A6-418F-47C5-A14B-5DAA723C9B5A@humancapitaldev.com> On Oct 28, 2010, at 4:38 PM, Jack Bates wrote: > On 10/28/2010 4:32 PM, Zaid Ali wrote: >> Yes it is. When do marketing people get it right? I actually think the fun >> hasn't begun yet. Wait till CNN/FOX etc makes this a big issue and claim the >> internet is going to come to an end then folks with clue will have to go on >> TV and calm the hysteria. >> > > Why would someone with clue want to calm the hysteria? I've had hysterical moments dealing with v6 transitions. Come to and end? Nah. Be a really rough ride? Unless things change, probably. Wait, if there's no transition to ipv6, the internet will end? And all our piracy and information control problems will end with it? That's just grand! Quick, pass a law against ipv6 adoption! Mandatory death penalty! Why didn't anyone think of this sooner? (NOW who says you can't put the genie back in the bottle? Stupid eggheads! :) From surfer at mauigateway.com Thu Oct 28 18:06:32 2010 From: surfer at mauigateway.com (Scott Weeks) Date: Thu, 28 Oct 2010 16:06:32 -0700 Subject: Interesting IPv6 viral video Message-ID: <20101028160632.EFD9F6CB@resin14.mta.everyone.net> --- zaid at zaidali.com wrote: Wait till CNN/FOX etc makes this a big issue and claim the internet is going to come to an end --------------------------------------------- http://www.argee.net/chickenlittleagenda/CLA%2072.jpg scott From zaid at zaidali.com Thu Oct 28 18:47:16 2010 From: zaid at zaidali.com (Zaid Ali) Date: Thu, 28 Oct 2010 16:47:16 -0700 Subject: Interesting IPv6 viral video In-Reply-To: <20101028160632.EFD9F6CB@resin14.mta.everyone.net> Message-ID: On 10/28/10 4:06 PM, "Scott Weeks" wrote: > > > --- zaid at zaidali.com wrote: > Wait till CNN/FOX etc makes this a big issue and claim the > internet is going to come to an end > --------------------------------------------- > > > http://www.argee.net/chickenlittleagenda/CLA%2072.jpg > > scott We have all seen the trend set by the Cyberwar news reports. Zaid From randy at psg.com Thu Oct 28 18:52:03 2010 From: randy at psg.com (Randy Bush) Date: Fri, 29 Oct 2010 08:52:03 +0900 Subject: Interesting IPv6 viral video In-Reply-To: <20101028160632.EFD9F6CB@resin14.mta.everyone.net> References: <20101028160632.EFD9F6CB@resin14.mta.everyone.net> Message-ID: > Wait till CNN/FOX etc makes this a big issue and claim the > internet is going to come to an end press frenzy in the '93 '94 era was what forced the ipv6 design, to solve the problem. and it did, the press shut up. problem is it did not solve the needed technical problems. but that is only pain for us, who cares? randy From sgridelli at gmail.com Fri Oct 29 00:25:23 2010 From: sgridelli at gmail.com (Stefano Gridelli) Date: Fri, 29 Oct 2010 01:25:23 -0400 Subject: Ethernet performance tests In-Reply-To: <035FE016D625174BA7C7A9FA83E6C17987172C87D8@winexmp02> References: <035FE016D625174BA7C7A9FA83E6C17987172C87D8@winexmp02> Message-ID: I tried the "ultra high throughput" script just for fun to see how much I could push ... I got a solid 920 mbps stream for the entire time I run the test (circa 30-60 seconds) with not spikes. The hardware in that case were two IBM hs-20 blades with broadcom chipsets. I said for fun because if we use ixchariot for throughput tests usually is just for small T1 sites (max 3xT1) so I have never seen the issue you mentioned. Usually on the same T1, we fill the data VLAN with traffic and then we run x voice pairs on the voice vlan to validate QoS (MOS score). On Thu, Oct 28, 2010 at 5:16 PM, Jonathon Exley wrote: > How smooth is the Ixchariot data stream? When Chariot was a NetIQ product > it seemed to generate regular spikes as the algorithm tried to correct the > total throughput over a time interval. > It's not a problem for slow data rates but when testing near the limit of a > circuit's capacity the spikes could sometimes overflow the buffers of > Ethernet media converters and give false results. > > Jonathon > > -----Original Message----- > From: Stefano Gridelli [mailto:sgridelli at gmail.com] > Sent: Friday, 29 October 2010 1:08 a.m. > To: Diogo Montagner; Tim Jackson; nanog at nanog.org > Subject: Re: Ethernet performance tests > > Hi Diogo > > We use ixchariot endpoints installed on linux laptops to test sites for > voice readiness. Ixchariot calculates for you the MOS score and, depending > from the NIC, can also push close to 1 Gig of traffic. For larger bandwidth > tests (I believe 6-7 Gig) and fast re-route testing (ms failover) we use > ixia hardware. > > Ciao > > > This email and attachments: are confidential; may be protected by > privilege and copyright; if received in error may not be used,copied, > or kept; are not guaranteed to be virus-free; may not express the > views of Kordia(R); do not designate an information system; and do not > give rise to any liability for Kordia(R). > > > From mlarson at verisign.com Fri Oct 29 09:47:24 2010 From: mlarson at verisign.com (Matt Larson) Date: Fri, 29 Oct 2010 10:47:24 -0400 Subject: .com/.net DNSSEC operational message Message-ID: <20101029144724.GE24263@DUL1MLARSON-M1.labs.vrsn.com> Over the next several months, VeriSign will deploy DNSSEC in the .net and .com zones. This message contains operational information related to the deployment that might be of interest to the Internet operational community. The .net DNSSEC deployment consists of the following major milestones: September 25, 2010: The .net registry system was upgraded to allow ICANN-accredited registrars to submit DS records for domains under .net. These DS records will not be published in the .net zone until the .net zone is actually signed. Each registrar will implement support for DNSSEC on its own schedule, and some registrars might be accepting DS records for .net domains now. October 29, 2010: A deliberately unvalidatable .net zone will be published. Following the successful use of this technique with the root DNSSEC deployment, VeriSign will publish a signed .net zone with the key material deliberately obscured so that it cannot be used for validation. Any DS records for .net domains that have been submitted by registrars will be published in the deliberately unvalidatable zone. December 9, 2010: The .net key material will be unobscured and the .net zone will be usable for DNSSEC validation. DS records for .net will appear in the root zone shortly thereafter. The .com DNSSEC deployment will occur in the first quarter of 2011 and will consist of the following major milestones: February, 2011: The .com registry system will be upgraded to allow ICANN-accredited registrars to submit DS records for domains under .com. These DS records will not be published in the .com zone until the .com zone is actually signed. March, 2011: A deliberately unvalidatable .com zone will be published. Any DS records for .com that have been submitted by registrars will be published in the deliberately unvalidatable zone. March, 2011: The .com key material will be unobscured and the .com zone will be usable for DNSSEC validation. DS records for .com will appear in the root zone shortly thereafter. If you have any questions or comments, please send email to info at verisign-grs.com or reply to this message. From joe.abley at icann.org Fri Oct 29 11:31:05 2010 From: joe.abley at icann.org (Joe Abley) Date: Fri, 29 Oct 2010 16:31:05 +0000 Subject: Root Zone DNSSEC KSK Ceremony 3 Message-ID: KSK CEREMONY 3 The third KSK ceremony for the root zone will take place in Culpeper, VA, USA on Monday 2010-11-01. The ceremony is scheduled to begin at 1300 local time (1700 UTC) and is expected to end by 1900 local time (2300 UTC). Video from Ceremony 3 will be recorded for audit purposes. Video and associated audit materials will be published 1 to 2 weeks after the ceremony, and will be available as usual by following the "KSK Ceremony Materials" link at . ICANN will operate a separate camera whose video will not be retained for audit purposes, but which will instead be streamed live in order to provide remote observers an opportunity to watch the ceremony. The live stream will be provided on a best-effort basis. The live video stream will be available at . Ceremony 3 will include processing of a Key Signing Request (KSR) generated by VeriSign, and the resulting Signed Key Response (SKR) will contain signatures for Q1 2011, for use in the root zone between 2011-01-01 and 2011-02-28. CONTACT INFORMATION We'd like to hear from you. If you have feedback for us, please send it to rootsign at icann.org. From Brian.Rettke at cableone.biz Fri Oct 29 11:55:06 2010 From: Brian.Rettke at cableone.biz (Rettke, Brian) Date: Fri, 29 Oct 2010 09:55:06 -0700 Subject: Topic: Inter-AS BGP Local Preference Matrix In-Reply-To: References: Message-ID: <96CA80CDCD822B4F9B41FB3A109C9359A3E64802CF@E2K7MAILBOX1.corp.cableone.net> My company is building a national backbone network, leveraging leased lines and dark fiber from Tier 1/2/3 providers. What we've found is that when we buy IP in the major markets, our traffic does not flow deterministically with AS-Path as the metric. This is because most of the major providers give their customers one local preference value, and their peers another, in an effort to ensure SLAs are met by keeping customer traffic on-net for as long as possible. There are varying values assigned, and some vendors don't offer community values to neutralize this effect. I'm wondering if anyone has dealt with this in the past, or if it would be possible to have some sort of agreement on local preference manipulation. Something similar to the below: 1. All vendors must offer at least 5 community values for local preference. This is to allow for customer-based multivendor traffic engineering. 2. All vendors must offer a local preference community value greater than their best default metric. 3. All vendors must offer a local preference community value lesser than their worst default metric. 4. All vendors should offer a range of community values both above and below local preference 100. 5. All vendors should make an effort to standardize the values/value ranges offered with other vendors. 6. All vendors should offer a local preference matrix to their customers, listing the changes made to a specific AS (e.g. another vendor) to aid the customer in making an intelligent routing decision for load balancing and traffic engineering in a multivendor BGP environment. It's obviously something that each of us would need to do individually, but I'm wondering if there is any way this could become a de facto standard, or could be a method that the community at large could enforce somehow. Sincerely, Brian A . Rettke RHCT, CCDP, CCNP, CCIP Network Engineer, CableONE Internet Services From srgqwerty at gmail.com Fri Oct 29 12:42:53 2010 From: srgqwerty at gmail.com (srg) Date: Fri, 29 Oct 2010 19:42:53 +0200 Subject: BGP support on ASA5585-X Message-ID: <1288374173.4032.11.camel@ping01> Hi: At this moment we know that ASA5585-X does not support BGP. Does anybody know if BGP support in the ASA5585-X is in roadmap? More precisely... MP-BGP support in the ASA5585-X? Any "oficial" link in the Cisco website about this? (I did't find it) Thanks a lot and best regards From davidd at corp.nac.net Fri Oct 29 12:45:23 2010 From: davidd at corp.nac.net (David DiGiacomo) Date: Fri, 29 Oct 2010 13:45:23 -0400 Subject: BGP support on ASA5585-X In-Reply-To: <1288374173.4032.11.camel@ping01> References: <1288374173.4032.11.camel@ping01> Message-ID: I would seriously doubt it. Think of it from Cisco's point of view; If the ASA ran BGP, you wouldn't need to buy a router. ____________________ Dave Joel DiGiacomo "davidd at corp.nac.net" Network Engineer / Peering Coordinator Net Access Corp Network Operations Center 973-590-5050 -----Original Message----- From: srg [mailto:srgqwerty at gmail.com] Sent: Friday, October 29, 2010 1:43 PM To: nanog at nanog.org Subject: BGP support on ASA5585-X Hi: At this moment we know that ASA5585-X does not support BGP. Does anybody know if BGP support in the ASA5585-X is in roadmap? More precisely... MP-BGP support in the ASA5585-X? Any "oficial" link in the Cisco website about this? (I did't find it) Thanks a lot and best regards From gschwim at gmail.com Fri Oct 29 12:46:05 2010 From: gschwim at gmail.com (Greg Schwimer) Date: Fri, 29 Oct 2010 10:46:05 -0700 Subject: Wildblue to the WCP Message-ID: Would someone at Wildblue please contact me off list. Thanks! Greg Schwimer GoDaddy.com From Greg.Whynott at oicr.on.ca Fri Oct 29 12:44:36 2010 From: Greg.Whynott at oicr.on.ca (Greg Whynott) Date: Fri, 29 Oct 2010 13:44:36 -0400 Subject: BGP support on ASA5585-X In-Reply-To: <1288374173.4032.11.camel@ping01> References: <1288374173.4032.11.camel@ping01> Message-ID: probably going out on a limb here, but i suspect you'll never see BGP support in any of Cisco's firewall products. In routers which have FW bits included, yes, but not in an ASA product. perhaps the marketing thinking is 'if you can afford an asa 558x, you can afford one of our fine router products too.' -g ________________________________________ From: srg [srgqwerty at gmail.com] Sent: Friday, October 29, 2010 1:42 PM To: nanog at nanog.org Subject: BGP support on ASA5585-X Hi: At this moment we know that ASA5585-X does not support BGP. Does anybody know if BGP support in the ASA5585-X is in roadmap? More precisely... MP-BGP support in the ASA5585-X? Any "oficial" link in the Cisco website about this? (I did't find it) Thanks a lot and best regards -- This message and any attachments may contain confidential and/or privileged information for the sole use of the intended recipient. Any review or distribution by anyone other than the person for whom it was originally intended is strictly prohibited. If you have received this message in error, please contact the sender and delete all copies. Opinions, conclusions or other information contained in this message may not be that of the organization. From reygue at htg.ht Fri Oct 29 13:10:55 2010 From: reygue at htg.ht (Reynold Guerrier) Date: Fri, 29 Oct 2010 13:10:55 -0500 Subject: Bandwidth into Haiti In-Reply-To: References: Message-ID: The fiber has been repaired by NATCOM that took over Teleco operations in Haiti, but with very limited traffic flowing on. NATCOM is a Vietnamese (Viettel) company that had acquired 60% of the incumbent telecommunications company in Haiti. Reynold On Thu, Oct 28, 2010 at 1:16 PM, Marshall Eubanks wrote: > Can anyone update me on the status of fiber bandwidth into Haiti ? > Has the landing station been repaired yet after last years earthquake ? > > Regards > Marshall Eubanks > > -- =================================== Reynold Guerrier Business Developer Haiti Technology Group 509-3446-0099 IM: reygue at hotmail.com Skype: reygji From cscora at apnic.net Fri Oct 29 13:25:01 2010 From: cscora at apnic.net (Routing Analysis Role Account) Date: Sat, 30 Oct 2010 04:25:01 +1000 (EST) Subject: Weekly Routing Table Report Message-ID: <201010291825.o9TIP1gQ023542@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 30 Oct, 2010 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary ---------------- BGP routing table entries examined: 334884 Prefixes after maximum aggregation: 153059 Deaggregation factor: 2.19 Unique aggregates announced to Internet: 164990 Total ASes present in the Internet Routing Table: 35132 Prefixes per ASN: 9.53 Origin-only ASes present in the Internet Routing Table: 30301 Origin ASes announcing only one prefix: 14792 Transit ASes present in the Internet Routing Table: 4831 Transit-only ASes present in the Internet Routing Table: 116 Average AS path length visible in the Internet Routing Table: 4.3 Max AS path length visible: 30 Max AS path prepend of ASN (41664) 21 Prefixes from unregistered ASNs in the Routing Table: 299 Unregistered ASNs in the Routing Table: 126 Number of 32-bit ASNs allocated by the RIRs: 855 Prefixes from 32-bit ASNs in the Routing Table: 4 Special use prefixes present in the Routing Table: 0 Prefixes being announced from unallocated address space: 190 Number of addresses announced to Internet: 2326677152 Equivalent to 138 /8s, 174 /16s and 70 /24s Percentage of available address space announced: 62.8 Percentage of allocated address space announced: 66.4 Percentage of available address space allocated: 94.6 Percentage of address space in use by end-sites: 85.7 Total number of prefixes smaller than registry allocations: 137440 APNIC Region Analysis Summary ----------------------------- Prefixes being announced by APNIC Region ASes: 82239 Total APNIC prefixes after maximum aggregation: 28016 APNIC Deaggregation factor: 2.94 Prefixes being announced from the APNIC address blocks: 79141 Unique aggregates announced from the APNIC address blocks: 34694 APNIC Region origin ASes present in the Internet Routing Table: 4221 APNIC Prefixes per ASN: 18.75 APNIC Region origin ASes announcing only one prefix: 1175 APNIC Region transit ASes present in the Internet Routing Table: 674 Average APNIC Region AS path length visible: 4.4 Max APNIC Region AS path length visible: 19 Number of APNIC addresses announced to Internet: 560662560 Equivalent to 33 /8s, 107 /16s and 8 /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, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/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: 137395 Total ARIN prefixes after maximum aggregation: 71132 ARIN Deaggregation factor: 1.93 Prefixes being announced from the ARIN address blocks: 108801 Unique aggregates announced from the ARIN address blocks: 43651 ARIN Region origin ASes present in the Internet Routing Table: 14008 ARIN Prefixes per ASN: 7.77 ARIN Region origin ASes announcing only one prefix: 5372 ARIN Region transit ASes present in the Internet Routing Table: 1485 Average ARIN Region AS path length visible: 4.0 Max ARIN Region AS path length visible: 23 Number of ARIN addresses announced to Internet: 738378752 Equivalent to 44 /8s, 2 /16s and 196 /24s Percentage of available ARIN address space announced: 62.9 ARIN AS Blocks 1-1876, 1902-2042, 2044-2046, 2048-2106 (pre-ERX allocations) 2138-2584, 2615-2772, 2823-2829, 2880-3153 3354-4607, 4865-5119, 5632-6655, 6912-7466 7723-8191, 10240-12287, 13312-15359, 16384-17407 18432-20479, 21504-23551, 25600-26591, 26624-27647, 29696-30719, 31744-33791 35840-36863, 39936-40959, 46080-47103 53248-55295, 393216-394239 ARIN Address Blocks 3/8, 4/8, 6/8, 7/8, 8/8, 9/8, 11/8, 12/8, 13/8, 15/8, 16/8, 17/8, 18/8, 19/8, 20/8, 21/8, 22/8, 24/8, 26/8, 28/8, 29/8, 30/8, 32/8, 33/8, 34/8, 35/8, 38/8, 40/8, 44/8, 45/8, 47/8, 48/8, 50/8, 52/8, 54/8, 55/8, 56/8, 63/8, 64/8, 65/8, 66/8, 67/8, 68/8, 69/8, 70/8, 71/8, 72/8, 73/8, 74/8, 75/8, 76/8, 96/8, 97/8, 98/8, 99/8, 107/8, 108/8, 173/8, 174/8, 184/8, 199/8, 204/8, 205/8, 206/8, 207/8, 208/8, 209/8, 214/8, 215/8, 216/8, RIPE Region Analysis Summary ---------------------------- Prefixes being announced by RIPE Region ASes: 77241 Total RIPE prefixes after maximum aggregation: 44695 RIPE Deaggregation factor: 1.73 Prefixes being announced from the RIPE address blocks: 70713 Unique aggregates announced from the RIPE address blocks: 46395 RIPE Region origin ASes present in the Internet Routing Table: 14930 RIPE Prefixes per ASN: 4.74 RIPE Region origin ASes announcing only one prefix: 7688 RIPE Region transit ASes present in the Internet Routing Table: 2300 Average RIPE Region AS path length visible: 4.4 Max RIPE Region AS path length visible: 30 Number of RIPE addresses announced to Internet: 443077376 Equivalent to 26 /8s, 104 /16s and 211 /24s Percentage of available RIPE address space announced: 77.7 RIPE AS Blocks 1877-1901, 2043, 2047, 2107-2136, 2585-2614 (pre-ERX allocations) 2773-2822, 2830-2879, 3154-3353, 5377-5631 6656-6911, 8192-9215, 12288-13311, 15360-16383 20480-21503, 24576-25599, 28672-29695 30720-31743, 33792-35839, 38912-39935 40960-45055, 47104-52223, 196608-197631 RIPE Address Blocks 2/8, 25/8, 31/8, 46/8, 51/8, 62/8, 77/8, 78/8, 79/8, 80/8, 81/8, 82/8, 83/8, 84/8, 85/8, 86/8, 87/8, 88/8, 89/8, 90/8, 91/8, 92/8, 93/8, 94/8, 95/8, 109/8, 176/8, 178/8, 193/8, 194/8, 195/8, 212/8, 213/8, 217/8, LACNIC Region Analysis Summary ------------------------------ Prefixes being announced by LACNIC Region ASes: 30226 Total LACNIC prefixes after maximum aggregation: 7219 LACNIC Deaggregation factor: 4.19 Prefixes being announced from the LACNIC address blocks: 28913 Unique aggregates announced from the LACNIC address blocks: 15358 LACNIC Region origin ASes present in the Internet Routing Table: 1377 LACNIC Prefixes per ASN: 21.00 LACNIC Region origin ASes announcing only one prefix: 428 LACNIC Region transit ASes present in the Internet Routing Table: 238 Average LACNIC Region AS path length visible: 4.4 Max LACNIC Region AS path length visible: 18 Number of LACNIC addresses announced to Internet: 76766720 Equivalent to 4 /8s, 147 /16s and 94 /24s Percentage of available LACNIC address space announced: 57.2 LACNIC AS Blocks 26592-26623, 27648-28671, 52224-53247, 262144-263167 plus ERX transfers LACNIC Address Blocks 177/8, 181/8, 186/8, 187/8, 189/8, 190/8, 200/8, 201/8, AfriNIC Region Analysis Summary ------------------------------- Prefixes being announced by AfriNIC Region ASes: 7554 Total AfriNIC prefixes after maximum aggregation: 1877 AfriNIC Deaggregation factor: 4.02 Prefixes being announced from the AfriNIC address blocks: 5871 Unique aggregates announced from the AfriNIC address blocks: 1719 AfriNIC Region origin ASes present in the Internet Routing Table: 415 AfriNIC Prefixes per ASN: 14.15 AfriNIC Region origin ASes announcing only one prefix: 129 AfriNIC Region transit ASes present in the Internet Routing Table: 89 Average AfriNIC Region AS path length visible: 5.1 Max AfriNIC Region AS path length visible: 21 Number of AfriNIC addresses announced to Internet: 21458176 Equivalent to 1 /8s, 71 /16s and 109 /24s Percentage of available AfriNIC address space announced: 64.0 AfriNIC AS Blocks 36864-37887, 327680-328703 & ERX transfers AfriNIC Address Blocks 41/8, 197/8, APNIC Region per AS prefix count summary ---------------------------------------- ASN No of nets /20 equiv MaxAgg Description 4766 1867 9453 512 Korea Telecom (KIX) 7545 1424 299 78 TPG Internet Pty Ltd 4755 1380 379 158 TATA Communications formerly 17488 1364 156 121 Hathway IP Over Cable Interne 17974 1277 304 82 PT TELEKOMUNIKASI INDONESIA 24560 1053 309 173 Bharti Airtel Ltd., Telemedia 9583 1030 76 491 Sify Limited 4808 976 1720 265 CNCGROUP IP network: China169 18101 894 116 133 Reliance Infocom Ltd Internet 9829 826 694 27 BSNL National Internet Backbo 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 3760 3666 279 bellsouth.net, inc. 4323 2611 1104 393 Time Warner Telecom 1785 1792 698 130 PaeTec Communications, Inc. 19262 1776 4833 278 Verizon Global Networks 20115 1507 1528 644 Charter Communications 7018 1420 5691 909 AT&T WorldNet Services 6478 1398 280 76 AT&T Worldnet Services 2386 1317 556 932 AT&T Data Communications Serv 11492 1237 231 74 Cable One 22773 1225 2859 62 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 3292 447 2028 391 TDC Tele Danmark 8866 426 133 25 Bulgarian Telecommunication C 8551 402 353 46 Bezeq International 702 397 1866 311 UUNET - Commercial IP service 34984 381 91 188 BILISIM TELEKOM 3301 379 1696 336 TeliaNet Sweden 3320 377 7332 330 Deutsche Telekom AG 30890 375 80 206 Evolva Telecom 12479 366 576 5 Uni2 Autonomous System 31148 360 19 82 FreeNet ISP 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 1330 248 155 TVCABLE BOGOTA 8151 1326 2597 366 UniNet S.A. de C.V. 28573 1206 928 84 NET Servicos de Comunicao S.A 7303 832 441 108 Telecom Argentina Stet-France 6503 794 225 259 AVANTEL, S.A. 22047 564 310 15 VTR PUNTO NET S.A. 14420 554 42 82 CORPORACION NACIONAL DE TELEC 3816 485 210 96 Empresa Nacional de Telecomun 7738 478 922 30 Telecomunicacoes da Bahia S.A 14117 448 32 27 Telefonica del Sur 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 1112 445 10 TEDATA 24863 744 147 39 LINKdotNET AS number 36992 643 278 160 Etisalat MISR 3741 268 907 225 The Internet Solution 24835 209 78 10 RAYA Telecom - Egypt 6713 203 199 12 Itissalat Al-MAGHRIB 29571 203 19 11 Ci Telecom Autonomous system 2018 197 277 64 Tertiary Education Network 33776 196 12 14 Starcomms Nigeria Limited 16637 152 440 89 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 3760 3666 279 bellsouth.net, inc. 4323 2611 1104 393 Time Warner Telecom 4766 1867 9453 512 Korea Telecom (KIX) 1785 1792 698 130 PaeTec Communications, Inc. 19262 1776 4833 278 Verizon Global Networks 20115 1507 1528 644 Charter Communications 7545 1424 299 78 TPG Internet Pty Ltd 7018 1420 5691 909 AT&T WorldNet Services 6478 1398 280 76 AT&T Worldnet Services 4755 1380 379 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 2611 2218 Time Warner Telecom 1785 1792 1662 PaeTec Communications, Inc. 19262 1776 1498 Verizon Global Networks 4766 1867 1355 Korea Telecom (KIX) 7545 1424 1346 TPG Internet Pty Ltd 6478 1398 1322 AT&T Worldnet Services 17488 1364 1243 Hathway IP Over Cable Interne 4755 1380 1222 TATA Communications formerly 17974 1277 1195 PT TELEKOMUNIKASI INDONESIA 10620 1330 1175 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 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 31.0.0.0/16 12654 RIPE NCC RIS Project 31.1.0.0/21 12654 RIPE NCC RIS Project 31.1.24.0/24 12654 RIPE NCC RIS Project 36.0.0.0/8 237 Merit Network 41.222.79.0/24 36938 >>UNKNOWN<< 41.223.92.0/22 36936 >>UNKNOWN<< 42.0.0.0/8 237 Merit Network 62.61.220.0/24 24974 Tachyon Europe BV - Wireless 62.61.221.0/24 24974 Tachyon Europe BV - Wireless 64.21.192.0/20 11610 Internet Nebraska Corporation 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:21 /9:10 /10:25 /11:68 /12:206 /13:420 /14:744 /15:1346 /16:11369 /17:5534 /18:9378 /19:18596 /20:23846 /21:23863 /22:31488 /23:30659 /24:174487 /25:974 /26:1098 /27:580 /28:151 /29:12 /30:2 /31:0 /32:7 Advertised prefixes smaller than registry allocations ----------------------------------------------------- ASN No of nets Total ann. Description 6389 2325 3760 bellsouth.net, inc. 4323 1402 2611 Time Warner Telecom 6478 1360 1398 AT&T Worldnet Services 10620 1222 1330 TVCABLE BOGOTA 11492 1194 1237 Cable One 1785 1074 1792 PaeTec Communications, Inc. 18566 1069 1088 Covad Communications 7011 1059 1160 Citizens Utilities 8452 1008 1112 TEDATA 19262 902 1776 Verizon Global Networks Complete listing at http://thyme.rand.apnic.net/current/data-sXXas-nos Number of /24s announced per /8 block (Global) ---------------------------------------------- 1:92 2:13 4:13 5:1 8:312 12:1995 13:8 14:53 15:18 16:3 17:8 20:9 24:1402 27:394 31:1 32:61 33:11 38:697 40:101 41:2618 44:3 46:199 47:10 49:4 50:3 52:12 55:5 56:2 57:29 58:834 59:501 60:480 61:1122 62:1003 63:1964 64:3746 65:2344 66:4069 67:1809 68:1123 69:2878 70:753 71:376 72:1894 73:2 74:2324 75:295 76:326 77:855 78:683 79:443 80:1060 81:795 82:513 83:454 84:684 85:1020 86:472 87:694 88:329 89:1572 90:109 91:3144 92:438 93:983 94:1120 95:704 96:396 97:222 98:632 99:32 100:1 101:3 108:64 109:724 110:426 111:619 112:308 113:306 114:478 115:615 116:1142 117:660 118:556 119:999 120:164 121:715 122:1606 123:950 124:1224 125:1270 128:229 129:152 130:168 131:564 132:275 133:20 134:207 135:46 136:211 137:142 138:279 139:109 140:485 141:198 142:347 143:361 144:500 145:55 146:427 147:173 148:619 149:308 150:146 151:231 152:293 153:175 154:3 155:362 156:166 157:338 158:112 159:361 160:312 161:199 162:274 163:163 164:426 165:349 166:469 167:426 168:681 169:155 170:718 171:62 172:2 173:1074 174:484 175:242 176:1 178:562 180:688 182:255 183:238 184:155 186:751 187:560 188:855 189:806 190:4185 192:5764 193:4751 194:3440 195:2839 196:1196 198:3519 199:3629 200:5409 201:1583 202:8177 203:8297 204:4016 205:2326 206:2569 207:3009 208:3885 209:3456 210:2557 211:1278 212:1805 213:1729 214:675 215:66 216:4742 217:1571 218:526 219:401 220:1184 221:428 222:343 223:59 End of report From cidr-report at potaroo.net Fri Oct 29 17:00:02 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Oct 2010 22:00:02 GMT Subject: BGP Update Report Message-ID: <201010292200.o9TM02Ra017140@wattle.apnic.net> BGP Update Report Interval: 21-Oct-10 -to- 28-Oct-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS4795 40639 2.7% 145.7 -- INDOSATM2-ID INDOSATM2 ASN 2 - AS5800 28981 1.9% 140.7 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 3 - AS9476 26184 1.8% 13092.0 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 4 - AS23700 23256 1.6% 51.9 -- BM-AS-ID PT. Broadband Multimedia, Tbk 5 - AS32528 19752 1.3% 2469.0 -- ABBOTT Abbot Labs 6 - AS35931 14608 1.0% 2434.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 7 - AS24560 12028 0.8% 12.4 -- AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services 8 - AS8151 9464 0.6% 7.4 -- Uninet S.A. de C.V. 9 - AS4755 8816 0.6% 6.8 -- TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 10 - AS14420 8514 0.6% 15.5 -- CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP 11 - AS3816 8204 0.6% 16.7 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 12 - AS18111 7442 0.5% 232.6 -- NETSPEED-AS-AP Netspeed Internet Communications 13 - AS9829 7328 0.5% 11.1 -- BSNL-NIB National Internet Backbone 14 - AS7552 7188 0.5% 10.8 -- VIETEL-AS-AP Vietel Corporation 15 - AS30890 6953 0.5% 18.5 -- EVOLVA Evolva Telecom s.r.l. 16 - AS23756 6945 0.5% 204.3 -- PADINET-AS-ID PADINET - Padi Internet 17 - AS3586 6704 0.5% 558.7 -- UWI ASN-UWI 18 - AS6316 6577 0.4% 49.5 -- AS-PAETEC-NET - PaeTec Communications, Inc. 19 - AS28571 6156 0.4% 143.2 -- Universidade de Sao Paulo - USP 20 - AS17974 5888 0.4% 4.7 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS9476 26184 1.8% 13092.0 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 2 - AS32528 19752 1.3% 2469.0 -- ABBOTT Abbot Labs 3 - AS35931 14608 1.0% 2434.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS15984 2236 0.1% 2236.0 -- The Joint-Stock Commercial Bank CentroCredit. 5 - AS49975 1059 0.1% 1059.0 -- FOTON-AS OOO FOTON 6 - AS22753 4170 0.3% 1042.5 -- REDHAT-STUTTGART REDHAT Stuttgart 7 - AS27771 1883 0.1% 941.5 -- Instituto Venezolano de Investigaciones Cientificas 8 - AS49600 626 0.0% 626.0 -- LASEDA La Seda de Barcelona, S.A 9 - AS3586 6704 0.5% 558.7 -- UWI ASN-UWI 10 - AS21017 5486 0.4% 548.6 -- VSI-AS VSI AS 11 - AS45947 1094 0.1% 547.0 -- SECUREPAY-AS-AP SecurePay Pty Ltd. Payment Gateway 12 - AS11652 2646 0.2% 529.2 -- TFCL-2 - TERRA FIRMA COMMUNICATIONS, LLC 13 - AS28193 1501 0.1% 500.3 -- 14 - AS55311 466 0.0% 466.0 -- LIENVIETBANK-AS-VN LienViet Joint Stock Commercial Bank 15 - AS17904 867 0.1% 433.5 -- SLTASUL-LK Sri Lankan Airlines 16 - AS38825 410 0.0% 410.0 -- BELLPOTTER-AP Bell Potter Securities 17 - AS18112 1027 0.1% 342.3 -- KSNET-ID-AS-AP PT. Sejuta Jaring Global 18 - AS31055 1361 0.1% 340.2 -- CONSULTIX-AS Consultix GmbH 19 - AS39224 340 0.0% 340.0 -- NIC-AS NEMAR INFO CONSTRUCT SRL 20 - AS46047 301 0.0% 301.0 -- POLSRI-AS-ID Politeknik Negeri Sriwijaya TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 203.1.14.0/24 14674 0.9% AS9476 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 2 - 203.1.13.0/24 11510 0.7% AS9476 -- INTRAPOWER-AS-AP IntraPower Pty. Ltd. 3 - 130.36.35.0/24 9867 0.6% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.34.0/24 9864 0.6% AS32528 -- ABBOTT Abbot Labs 5 - 63.211.68.0/22 8401 0.5% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 6 - 216.126.136.0/22 6336 0.4% AS6316 -- AS-PAETEC-NET - PaeTec Communications, Inc. 7 - 198.140.43.0/24 6182 0.4% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 8 - 190.65.228.0/22 5232 0.3% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 9 - 66.187.234.0/24 4161 0.3% AS22753 -- REDHAT-STUTTGART REDHAT Stuttgart 10 - 95.32.128.0/18 3558 0.2% AS21017 -- VSI-AS VSI AS 11 - 201.134.18.0/24 3318 0.2% AS8151 -- Uninet S.A. de C.V. 12 - 206.184.16.0/24 3273 0.2% AS174 -- COGENT Cogent/PSI 13 - 189.85.51.0/24 2339 0.1% AS28175 -- 14 - 129.66.128.0/17 2311 0.1% AS3464 -- ASC-NET - Alabama Supercomputer Network 15 - 129.66.0.0/17 2305 0.1% AS3464 -- ASC-NET - Alabama Supercomputer Network 16 - 202.92.235.0/24 2270 0.1% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 17 - 217.67.0.0/20 2236 0.1% AS15984 -- The Joint-Stock Commercial Bank CentroCredit. 18 - 202.83.96.0/20 2014 0.1% AS18106 -- VIEWQWEST-SG-AP Viewqwest Pte Ltd AS9255 -- CONNECTPLUS-AS Singapore Telecom 19 - 95.32.192.0/18 1890 0.1% AS21017 -- VSI-AS VSI AS 20 - 203.24.144.0/24 1703 0.1% AS4802 -- ASN-IINET iiNet Limited 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 Oct 29 17:00:00 2010 From: cidr-report at potaroo.net (cidr-report at potaroo.net) Date: Fri, 29 Oct 2010 22:00:00 GMT Subject: The Cidr Report Message-ID: <201010292200.o9TM00AS017134@wattle.apnic.net> This report has been generated at Fri Oct 29 21:11:34 2010 AEST. The report analyses the BGP Routing Table of AS2.0 router and generates a report on aggregation potential within the table. Check http://www.cidr-report.org for a current version of this report. Recent Table History Date Prefixes CIDR Agg 22-10-10 335372 199107 23-10-10 335626 199437 24-10-10 335464 200676 25-10-10 335999 201471 26-10-10 336020 202330 27-10-10 336420 203303 28-10-10 336698 204259 29-10-10 336648 204467 AS Summary 35744 Number of ASes in routing system 15278 Number of ASes announcing only one prefix 4497 Largest number of prefixes announced by an AS AS4323 : TWTC - tw telecom holdings, inc. 101039104 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'). --- 29Oct10 --- ASnum NetsNow NetsAggr NetGain % Gain Description Table 336912 204485 132427 39.3% All ASes AS6389 3760 331 3429 91.2% BELLSOUTH-NET-BLK - BellSouth.net Inc. AS4323 4497 1591 2906 64.6% TWTC - tw telecom holdings, inc. AS19262 1775 293 1482 83.5% VZGNI-TRANSIT - Verizon Online LLC AS4766 1727 551 1176 68.1% KIXS-AS-KR Korea Telecom AS22773 1226 76 1150 93.8% ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. AS17488 1364 270 1094 80.2% HATHWAY-NET-AP Hathway IP Over Cable Internet AS4755 1377 402 975 70.8% TATACOMM-AS TATA Communications formerly VSNL is Leading ISP AS24560 1053 193 860 81.7% AIRTELBROADBAND-AS-AP Bharti Airtel Ltd., Telemedia Services AS18101 893 132 761 85.2% RELIANCE-COMMUNICATIONS-IN Reliance Communications Ltd.DAKC MUMBAI AS10620 1330 591 739 55.6% Telmex Colombia S.A. AS1785 1795 1060 735 40.9% AS-PAETEC-NET - PaeTec Communications, Inc. AS28573 1190 460 730 61.3% NET Servicos de Comunicao S.A. AS8452 1112 427 685 61.6% TE-AS TE-AS AS33363 1420 745 675 47.5% BHN-TAMPA - BRIGHT HOUSE NETWORKS, LLC AS6478 1398 732 666 47.6% ATT-INTERNET3 - AT&T Services, Inc. AS8151 1337 690 647 48.4% Uninet S.A. de C.V. AS4808 920 274 646 70.2% CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network AS7545 1437 818 619 43.1% TPG-INTERNET-AP TPG Internet Pty Ltd AS5668 875 260 615 70.3% AS-5668 - CenturyTel Internet Holdings, Inc. AS18566 1064 465 599 56.3% COVAD - Covad Communications Co. AS7303 830 239 591 71.2% Telecom Argentina S.A. AS17676 638 66 572 89.7% GIGAINFRA Softbank BB Corp. AS3356 1175 633 542 46.1% LEVEL3 Level 3 Communications AS22047 564 34 530 94.0% VTR BANDA ANCHA S.A. AS7552 651 140 511 78.5% VIETEL-AS-AP Vietel Corporation AS4804 580 75 505 87.1% MPX-AS Microplex PTY LTD AS9443 574 78 496 86.4% INTERNETPRIMUS-AS-AP Primus Telecommunications AS4780 712 220 492 69.1% SEEDNET Digital United Inc. AS6503 794 306 488 61.5% Axtel, S.A.B. de C.V. AS14420 559 98 461 82.5% CORPORACION NACIONAL DE TELECOMUNICACIONES - CNT EP Total 38627 12250 26377 68.3% Top 30 total Possible Bogus Routes 5.4.3.0/24 AS12025 IO-DATA-CENTERS - IO Data Centers 27.126.176.0/24 AS38186 FTG-AS-AP Forewin Telecom Group Limited, ISP at HK 31.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 31.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 36.0.0.0/8 AS237 MERIT-AS-14 - Merit Network Inc. 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/8 AS237 MERIT-AS-14 - Merit Network Inc. 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 66.180.239.0/24 AS35888 VIGNETTE - VIGNETTE CORPORATION 66.206.32.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.33.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.34.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.35.0/24 AS17787 PSEB-AS-PK Pakistan Software Export Board 66.206.47.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 66.207.32.0/20 AS23011 66.230.240.0/20 AS27286 CSI-NET - C D C A. CHARMING SHOPPES OF DELAWARE, INC. 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. 71.19.160.0/23 AS4648 NZIX-2 Netgate 72.22.32.0/19 AS33150 72.22.61.0/24 AS33150 72.22.62.0/24 AS33150 76.77.32.0/19 AS2828 XO-AS15 - XO Communications 80.88.10.0/24 AS33774 DJAWEB 80.88.12.0/24 AS33779 wataniya-telecom-as 96.45.161.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.162.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.163.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.164.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.165.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.166.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.167.0/24 AS3257 TINET-BACKBONE Tinet SpA 96.45.168.0/21 AS3257 TINET-BACKBONE Tinet SpA 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.0.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.5.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.6.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.11.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.20.0/24 AS24541 FORTYFIVERU-AS-AU 45RU Pty Ltd. Internet Service Provider, Perth, Western Australia. 115.42.28.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.29.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.30.0/24 AS1221 ASN-TELSTRA Telstra Pty Ltd 115.42.31.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.43.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 116.68.136.0/21 AS28045 Pantel Communications 117.120.56.0/21 AS4755 TATACOMM-AS TATA Communications formerly VSNL is Leading ISP 121.46.0.0/16 AS4134 CHINANET-BACKBONE No.31,Jin-rong Street 121.50.168.0/21 AS9931 CAT-AP The Communication Authoity of Thailand, CAT 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 176.0.0.0/16 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.0.0/21 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 176.1.24.0/24 AS12654 RIPE-NCC-RIS-AS RIPE NCC RIS project 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.154.32.0/19 AS81 NCREN - MCNC 192.154.64.0/19 AS81 NCREN - MCNC 192.188.208.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 196.2.224.0/22 AS24863 LINKdotNET-AS 196.6.108.0/24 AS5713 SAIX-NET 196.13.201.0/24 AS2018 TENET-1 196.13.202.0/24 AS2018 TENET-1 196.13.203.0/24 AS2018 TENET-1 196.13.204.0/24 AS2018 TENET-1 196.110.105.0/24 AS8513 SKYVISION SkyVision Network Services 196.202.224.0/21 AS8818 TELE Greenland Autonomous System 198.1.2.0/24 AS4761 INDOSAT-INP-AP INDOSAT Internet Network Provider 198.23.26.0/24 AS4390 BELLATLANTIC-COM - Bell Atlantic, Inc. 198.73.210.0/24 AS21570 ACI-1 - Accelerated Connections Inc. 198.74.38.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.39.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.74.40.0/24 AS16966 SBCIDC-LSAN03 - AT&T Internet Services 198.97.72.0/21 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.96.0/19 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.97.240.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 198.99.241.0/24 AS11797 AC-NIELSEN-AS AC NIELSEN 198.161.87.0/24 AS6539 GT-BELL - Bell Canada 198.163.214.0/24 AS21804 ACCESS-SK - Access Communications Co-operative Limited 198.167.0.0/16 AS7456 INTERHOP - Interhop Network SERVICES Inc. 198.168.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 198.169.0.0/16 AS803 SASKTEL - Saskatchewan Telecommunications 198.180.198.0/24 AS23715 SEOUL-INTGW-GXS-AP Global Exchange Services 198.182.235.0/24 AS3356 LEVEL3 Level 3 Communications 199.16.32.0/19 AS6389 BELLSOUTH-NET-BLK - BellSouth.net Inc. 199.121.0.0/16 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.123.16.0/20 AS27064 DNIC-ASBLK-27032-27159 - DoD Network Information Center 199.185.130.0/23 AS19662 UNISERVE-ONLINE - Uniserve On Line 199.202.0.0/16 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 199.202.216.0/21 AS577 BACOM - Bell Canada 199.233.92.0/24 AS26896 D102-ITC - Data 102, LLC 199.246.116.0/24 AS813 UUNET-CANADA - MCI Communications Services, Inc. d/b/a Verizon Business 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.9.55.0/24 AS2764 AAPT AAPT Limited 202.9.57.0/24 AS2764 AAPT AAPT Limited 202.38.63.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.52.33.0/24 AS55536 MIHK-HK Pacswitch Globe Telecom 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.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.86.252.0/22 AS4748 RESOLINK-AS-AP Resources Link Network Limited 202.86.252.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.253.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.254.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.86.255.0/24 AS9304 HUTCHISON-AS-AP Hutchison Global Communications 202.94.1.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.133.37.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.133.70.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.133.73.0/24 AS38616 WORLDCALL-AS-KHI Worldcall Telecom Limited 202.136.254.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.136.255.0/24 AS4808 CHINA169-BJ CNCGROUP IP network China169 Beijing Province Network 202.150.227.0/24 AS17727 NAPINFO-AS-AP PT. NAP Info Lintas Nusa 202.174.70.0/24 AS21175 WIS WIS S.A. : WIND International Services 202.174.125.0/24 AS9498 BBIL-AP BHARTI Airtel Ltd. 202.176.1.0/24 AS9942 COMINDICO-AP SOUL Converged Communications Australia 202.179.130.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.131.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.133.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.134.0/24 AS23966 LDN-AS-PK LINKdotNET Telecom Limited 202.179.144.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.149.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.179.150.0/24 AS17557 PKTELECOM-AS-PK Pakistan Telecommunication Company Limited 202.181.32.0/24 AS4645 ASN-HKNET-AP HKNet Co. Ltd 203.12.45.0/24 AS4854 NETSPACE-AS-AP Netspace Online Systems 203.62.0.0/17 AS7575 AARNET-AS-AP Australian Academic and Reasearch Network (AARNet) 203.78.48.0/20 AS9299 IPG-AS-AP Philippine Long Distance Telephone Company 203.80.136.0/21 AS4759 EVOSERVE-AS-AP EvoServe is a content and online access Internet provider company 203.112.111.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.113.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.114.0/24 AS4802 ASN-IINET iiNet Limited 203.112.116.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.117.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.118.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.119.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.120.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.121.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.112.127.0/24 AS7474 OPTUSCOM-AS01-AU SingTel Optus Pty Ltd 203.128.128.0/24 AS23849 CNNIC-NET263-AP Beijing Capital-online science development Co.,Ltd. 203.142.219.0/24 AS45149 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 204.28.104.0/21 AS25973 MZIMA - Mzima Networks, Inc. 204.209.114.0/24 AS13768 PEER1 - Peer 1 Network Inc. 204.238.70.0/24 AS36826 205.150.0.0/15 AS701 UUNET - MCI Communications Services, Inc. d/b/a Verizon Business 205.189.134.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 205.196.24.0/22 AS33724 BIZNESSHOSTING - VOLICO 205.210.145.0/24 AS11814 DISTRIBUTEL-AS11814 - DISTRIBUTEL COMMUNICATIONS LTD. 206.72.192.0/23 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.200.0/22 AS11730 CIL-ASN - Circle Internet LTD 208.64.240.0/21 AS13871 TELEBYTE-NW - Telebyte NW 208.78.165.0/24 AS16565 208.92.196.0/22 AS10929 NETELLIGENT - Netelligent Hosting Services Inc. 208.92.199.0/24 AS26198 3MENATWORK - 3Men at Work Integrated Networks, Inc. 209.54.123.0/24 AS6062 NETPLEX - NETPLEX 209.105.224.0/19 AS20074 209.165.239.0/24 AS209 ASN-QWEST - Qwest Communications Company, LLC 209.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 210.247.224.0/19 AS7496 WEBCENTRAL-AS WebCentral 216.10.235.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.10.236.0/24 AS13780 NTNCOMMUNICATIONS - NTN 216.21.196.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.201.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.202.0/24 AS12251 INVISION - Invision.com, Inc. 216.21.206.0/23 AS12251 INVISION - Invision.com, Inc. 216.58.192.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.197.0/24 AS22702 X5SOLUTIONS - X5 Solutions, Inc. 216.58.200.0/24 AS18530 ISOMEDIA-1 - Isomedia Inc. 216.172.198.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.172.199.0/24 AS22773 ASN-CXA-ALL-CCI-22773-RDC - Cox Communications Inc. 216.250.112.0/20 AS7296 ALCHEMYNET - Alchemy Communications, Inc. 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 mpetach at netflight.com Fri Oct 29 18:16:55 2010 From: mpetach at netflight.com (Matthew Petach) Date: Fri, 29 Oct 2010 16:16:55 -0700 Subject: Topic: Inter-AS BGP Local Preference Matrix In-Reply-To: <96CA80CDCD822B4F9B41FB3A109C9359A3E64802CF@E2K7MAILBOX1.corp.cableone.net> References: <96CA80CDCD822B4F9B41FB3A109C9359A3E64802CF@E2K7MAILBOX1.corp.cableone.net> Message-ID: On Fri, Oct 29, 2010 at 9:55 AM, Rettke, Brian wrote: > My company is building a national backbone network, leveraging leased lines and dark fiber from Tier 1/2/3 providers. What we've found is that when we buy IP in the major markets, our traffic does not flow deterministically with AS-Path as the metric. This is because most of the major providers give their customers one local preference value, and their peers another, in an effort to ensure SLAs are met by keeping customer traffic on-net for as long as possible. There are varying values assigned, and some vendors don't offer community values to neutralize this effect. > I think you mean "provider" rather than "vendor"; by and large, all hardware vendors provide some knob to allow for changing localpreference values across the full range of allowable values. Providers, on the other hand, only allow customers to request a change of local preference values, and then only among a very small set of values, usually ranging from "above normal customer localpref", "default customer localpref", and "below customer localpref". If you're really lucky, they might allow you to set "peer localpref" and "below peer localpref". > I'm wondering if anyone has dealt with this in the past, or if it would be possible to have some sort of agreement on local preference manipulation. Something similar to the below: > > 1. All vendors must offer at least 5 community values for local preference. This is to allow for customer-based multivendor traffic engineering. > 2. All vendors must offer a local preference community value greater than their best default metric. > 3. All vendors must offer a local preference community value lesser than their worst default metric. > 4. All vendors should offer a range of community values both above and below local preference 100. Not everybody uses 100 as their default value, so that requirement could be at odds with the rest of the requirements. I'd recommend dropping that from your list, to make the barrier to adoption lower. > 5. All vendors should make an effort to standardize the values/value ranges offered with other vendors. > 6. All vendors should offer a local preference matrix to their customers, listing the changes made to a specific AS (e.g. another vendor) to aid the customer in making an intelligent routing decision for load balancing and traffic engineering in a multivendor BGP environment. > > It's obviously something that each of us would need to do individually, but I'm wondering if there is any way this could become a de facto standard, or could be a method that the community at large could enforce somehow. > I'm not sure what incentive there would be for the providers to coordinate like this; it would mean quite a bit more work for them, with no appreciable gain in revenue for it. Matt > Sincerely, > > Brian A . Rettke > RHCT, CCDP, CCNP, CCIP > Network Engineer, CableONE Internet Services From jeroen at mompl.net Fri Oct 29 20:06:32 2010 From: jeroen at mompl.net (Jeroen van Aart) Date: Fri, 29 Oct 2010 18:06:32 -0700 Subject: IPv6 rDNS Message-ID: <4CCB6F98.6090103@mompl.net> I battled for a few hours getting IPv6 rDNS to work. The following tool proved to be quite helpful: http://www.fpsn.net/?pg=tools&tool=ipv6-inaddr Just in case anyone else would run into similar problems. It's not as straightforward as IPv4 rDNS. Greetings, Jeroen -- http://goldmark.org/jeff/stupid-disclaimers/ http://linuxmafia.com/~rick/faq/plural-of-virus.html From franck at genius.com Fri Oct 29 20:09:41 2010 From: franck at genius.com (Franck Martin) Date: Sat, 30 Oct 2010 14:09:41 +1300 (FJST) Subject: IPv6 rDNS In-Reply-To: <4CCB6F98.6090103@mompl.net> Message-ID: <23299513.199.1288400976973.JavaMail.franck@franck-martins-macbook-pro.local> Yes, you need to be able to spell Hex backward ;) ----- Original Message ----- From: "Jeroen van Aart" To: "NANOG list" Sent: Saturday, 30 October, 2010 2:06:32 PM Subject: IPv6 rDNS I battled for a few hours getting IPv6 rDNS to work. The following tool proved to be quite helpful: http://www.fpsn.net/?pg=tools&tool=ipv6-inaddr Just in case anyone else would run into similar problems. It's not as straightforward as IPv4 rDNS. From gem at rellim.com Fri Oct 29 20:20:21 2010 From: gem at rellim.com (Gary E. Miller) Date: Fri, 29 Oct 2010 18:20:21 -0700 (PDT) Subject: IPv6 rDNS In-Reply-To: <4CCB6F98.6090103@mompl.net> References: <4CCB6F98.6090103@mompl.net> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yo Jeroen! On Fri, 29 Oct 2010, Jeroen van Aart wrote: > I battled for a few hours getting IPv6 rDNS to work. See also sipcalc. # sipcalc -r 2001:470:b:4a:230:48ff:fe35:d1bc - -[ipv6 : 2001:470:b:4a:230:48ff:fe35:d1bc] - 0 [IPV6 DNS] Reverse DNS (ip6.arpa) - c.b.1.d.5.3.e.f.f.f.8.4.0.3.2.0.a.4.0.0.b.0.0.0.0.7.4.0.1.0.0.2.ip6.arpa. RGDS GARY - --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFMy3LeBmnRqz71OvMRAoaxAJ9XrEpV8+QLwJDenMwn4oCTmu6D9gCgpeEb nszaFE+jTA1rn4ZgTDFCanQ= =NNMg -----END PGP SIGNATURE----- From marka at isc.org Fri Oct 29 20:23:10 2010 From: marka at isc.org (Mark Andrews) Date: Sat, 30 Oct 2010 12:23:10 +1100 Subject: IPv6 rDNS In-Reply-To: Your message of "Fri, 29 Oct 2010 18:06:32 PDT." <4CCB6F98.6090103@mompl.net> References: <4CCB6F98.6090103@mompl.net> Message-ID: <20101030012310.1E3A1622FF9@drugs.dv.isc.org> In message <4CCB6F98.6090103 at mompl.net>, Jeroen van Aart writes: > I battled for a few hours getting IPv6 rDNS to work. The following tool > proved to be quite helpful: > http://www.fpsn.net/?pg=tools&tool=ipv6-inaddr > > Just in case anyone else would run into similar problems. It's not as > straightforward as IPv4 rDNS. How so? It's just longer owner names. There are enough tools that will covert IPv6 addresses to the corresponding reverse name. You most probably already have the tools on your machines. dig, nslookup, arpaname And if you are running Mac OS or Windows they will add the PTR records for themselves. I just wish all the other OS's did that so I don't have to do them by hand. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From colbycciestudy at gmail.com Fri Oct 29 21:21:20 2010 From: colbycciestudy at gmail.com (Colby Glass) Date: Fri, 29 Oct 2010 22:21:20 -0400 Subject: Weird Nexus AD Message-ID: We're seeing an AD of 2 on some routes on our Nexus 7k. I can't find anything (Google) to indicate where this value is coming from. Also unable to find out what "am" mean (adjacency module?). Does anyone have an explanation for this one? * via 192.168.21.49, Vlan13, [2/0], 00:44:52, am* Thanks -- Colby Glass Network Engineer http://blog.alwaysthenetwork.com From randy at psg.com Fri Oct 29 22:12:35 2010 From: randy at psg.com (Randy Bush) Date: Sat, 30 Oct 2010 12:12:35 +0900 Subject: IPv6 rDNS In-Reply-To: <4CCB6F98.6090103@mompl.net> References: <4CCB6F98.6090103@mompl.net> Message-ID: > http://www.fpsn.net/?pg=tools&tool=ipv6-inaddr windows mentality, wrap it all in a complex gui that also washes your car. use simple hack that just takes an ipv6 address and makes the bleeping reversed dotted to death lhs of the ptr record. rmac.psg.com:/Users/randy> host 2001:418:1::61 Host 1.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.8.1.4.0.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN) randy From adrian at creative.net.au Fri Oct 29 22:18:18 2010 From: adrian at creative.net.au (Adrian Chadd) Date: Sat, 30 Oct 2010 11:18:18 +0800 Subject: IPv6 rDNS In-Reply-To: References: <4CCB6F98.6090103@mompl.net> Message-ID: <20101030031818.GA32071@skywalker.creative.net.au> On Sat, Oct 30, 2010, Randy Bush wrote: > > http://www.fpsn.net/?pg=tools&tool=ipv6-inaddr > > windows mentality, wrap it all in a complex gui that also washes your > car. > > use simple hack that just takes an ipv6 address and makes the bleeping > reversed dotted to death lhs of the ptr record. > > rmac.psg.com:/Users/randy> host 2001:418:1::61 > Host 1.6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.0.8.1.4.0.1.0.0.2.ip6.arpa not found: 3(NXDOMAIN) > But Randy, everyone has a web browser installed. Not everyone has perl, python, cc, or such installed. :-) Adrian (I wonder if FreeBSD-1.0's complete, non-X install footprint (sub-40meg) was smaller than an install of Firefox. :-) From randy at psg.com Fri Oct 29 22:32:22 2010 From: randy at psg.com (Randy Bush) Date: Sat, 30 Oct 2010 12:32:22 +0900 Subject: IPv6 rDNS In-Reply-To: <20101030031818.GA32071@skywalker.creative.net.au> References: <4CCB6F98.6090103@mompl.net> <20101030031818.GA32071@skywalker.creative.net.au> Message-ID: > But Randy, everyone has a web browser installed. Not everyone has > perl, python, cc, or such installed. and i thought this was an operators' list. silly me. randy, who did see the smiley From gbonser at seven.com Fri Oct 29 22:43:23 2010 From: gbonser at seven.com (George Bonser) Date: Fri, 29 Oct 2010 20:43:23 -0700 Subject: IPv6 rDNS In-Reply-To: <20101030031818.GA32071@skywalker.creative.net.au> References: <4CCB6F98.6090103@mompl.net> <20101030031818.GA32071@skywalker.creative.net.au> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C63C@RWC-EX1.corp.seven.com> > > But Randy, everyone has a web browser installed. Not everyone has perl, > python, > cc, or such installed. > > :-) apt-get install ipv6calc ipv6calc -q --out revnibbles.arpa 2001::1 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.0.2.ip6.arpa . :-) From ck at sandcastl.es Fri Oct 29 23:04:24 2010 From: ck at sandcastl.es (christian koch) Date: Fri, 29 Oct 2010 21:04:24 -0700 Subject: Weird Nexus AD In-Reply-To: References: Message-ID: in x/y, x= preference, y= metric am= adjacency module, *= best unicast route a better place to have asked this would be c-nsp hth -ck On Fri, Oct 29, 2010 at 7:21 PM, Colby Glass wrote: > We're seeing an AD of 2 on some routes on our Nexus 7k. I can't find > anything (Google) to indicate where this value is coming from. Also unable > to find out what "am" mean (adjacency module?). Does anyone have an > explanation for this one? > > * via 192.168.21.49, Vlan13, [2/0], 00:44:52, am* > > Thanks > > -- > Colby Glass > Network Engineer > http://blog.alwaysthenetwork.com > From khatfield at socllc.net Fri Oct 29 23:27:22 2010 From: khatfield at socllc.net (khatfield at socllc.net) Date: Sat, 30 Oct 2010 00:27:22 -0400 (EDT) Subject: BGP support on ASA5585-X In-Reply-To: References: <1288374173.4032.11.camel@ping01> Message-ID: <1288412842.995426538@192.168.2.229> None of the ASA's support BGP. I didn't think so but I went ahead and did the research for you: http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/glossary.html#wp1027964 he security appliance does not support BGP. -Kevin -----Original Message----- From: "David DiGiacomo" Sent: Friday, October 29, 2010 1:45pm To: "srg" , "nanog at nanog.org" Subject: RE: BGP support on ASA5585-X I would seriously doubt it. Think of it from Cisco's point of view; If the ASA ran BGP, you wouldn't need to buy a router. ____________________ Dave Joel DiGiacomo "davidd at corp.nac.net" Network Engineer / Peering Coordinator Net Access Corp Network Operations Center 973-590-5050 -----Original Message----- From: srg [mailto:srgqwerty at gmail.com] Sent: Friday, October 29, 2010 1:43 PM To: nanog at nanog.org Subject: BGP support on ASA5585-X Hi: At this moment we know that ASA5585-X does not support BGP. Does anybody know if BGP support in the ASA5585-X is in roadmap? More precisely... MP-BGP support in the ASA5585-X? Any "oficial" link in the Cisco website about this? (I did't find it) Thanks a lot and best regards From colbycciestudy at gmail.com Fri Oct 29 23:36:35 2010 From: colbycciestudy at gmail.com (Colby Glass) Date: Sat, 30 Oct 2010 00:36:35 -0400 Subject: Weird Nexus AD In-Reply-To: References: Message-ID: system: version 4.2(2a) I've read that am = adjacency module or adjacency manager. The words mean less to me than why I seem to be learning this route from a phantom module/manager/interface with no visible explanation. I can try on c-nsp as well. Thought NANOG might be a better choice. Colby On Sat, Oct 30, 2010 at 12:04 AM, christian koch wrote: > in x/y, x= preference, y= metric > > am= adjacency module, *= best unicast route > > a better place to have asked this would be c-nsp > > hth > > -ck > > > On Fri, Oct 29, 2010 at 7:21 PM, Colby Glass wrote: > >> We're seeing an AD of 2 on some routes on our Nexus 7k. I can't find >> anything (Google) to indicate where this value is coming from. Also unable >> to find out what "am" mean (adjacency module?). Does anyone have an >> explanation for this one? >> >> * via 192.168.21.49, Vlan13, [2/0], 00:44:52, am* >> >> Thanks >> >> -- >> Colby Glass >> Network Engineer >> http://blog.alwaysthenetwork.com >> > > -- Colby Glass Network Engineer http://blog.alwaysthenetwork.com From will at loopfree.net Fri Oct 29 23:57:29 2010 From: will at loopfree.net (Will Orton) Date: Fri, 29 Oct 2010 21:57:29 -0700 Subject: IPv6 rDNS In-Reply-To: <4CCB6F98.6090103@mompl.net> References: <4CCB6F98.6090103@mompl.net> Message-ID: <20101030045729.GA528@loopfree.net> We developed a web/mysql-based front-end that our noc uses for all DNS ops, so the NOC never touches zone files directly. So it was easy to just add a feature that provides additional syntax for ipv6 PTRs... So for example in zone 0.0.0.0.d.c.b.a.8.B.D.0.1.0.0.2.ip6.arpa we can enter 0000:0000:0000:0003 PTR foo.com. and it will reverse the nibbles/remove the ":"s and put in the "."s and get generated into a zone file as needed: 3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.d.c.b.a.8.B.D.0.1.0.0.2.ip6.arpa PTR foo.com. (of course you can enter x.x.x.x... syntax too) Having a front-end also lets you do all sorts of other sanity-checking with instant feedback to avoid choking up BIND, depending on the skill level of your target "DNS admin". -Will On Fri, Oct 29, 2010 at 06:06:32PM -0700, Jeroen van Aart wrote: > Date: Fri, 29 Oct 2010 18:06:32 -0700 > From: Jeroen van Aart > To: NANOG list > Subject: IPv6 rDNS > > I battled for a few hours getting IPv6 rDNS to work. The following tool > proved to be quite helpful: > http://www.fpsn.net/?pg=tools&tool=ipv6-inaddr > > Just in case anyone else would run into similar problems. It's not as > straightforward as IPv4 rDNS. > > Greetings, > Jeroen > > -- > http://goldmark.org/jeff/stupid-disclaimers/ > http://linuxmafia.com/~rick/faq/plural-of-virus.html From jeffrey.lyon at blacklotus.net Sat Oct 30 01:01:02 2010 From: jeffrey.lyon at blacklotus.net (Jeffrey Lyon) Date: Sat, 30 Oct 2010 10:31:02 +0430 Subject: BGP support on ASA5585-X In-Reply-To: <1288412842.995426538@192.168.2.229> References: <1288374173.4032.11.camel@ping01> <1288412842.995426538@192.168.2.229> Message-ID: Juniper Netscreen does, in case the OP is looking for alternatives. Best regards, Jeff On Sat, Oct 30, 2010 at 8:57 AM, wrote: > None of the ASA's support BGP. I didn't think so but I went ahead and did the research for you: > http://www.cisco.com/en/US/docs/security/asa/asa80/configuration/guide/glossary.html#wp1027964 > > he security appliance does not support BGP. > > -Kevin > > -----Original Message----- > From: "David DiGiacomo" > Sent: Friday, October 29, 2010 1:45pm > To: "srg" , "nanog at nanog.org" > Subject: RE: BGP support on ASA5585-X > > I would seriously doubt it. Think of it from Cisco's point of view; If the ASA ran BGP, you wouldn't need to buy a router. > > ____________________ > > Dave Joel DiGiacomo "davidd at corp.nac.net" > Network Engineer / Peering Coordinator > Net Access Corp > Network Operations Center > 973-590-5050 > > -----Original Message----- > From: srg [mailto:srgqwerty at gmail.com] > Sent: Friday, October 29, 2010 1:43 PM > To: nanog at nanog.org > Subject: BGP support on ASA5585-X > > Hi: > > At this moment we know that ASA5585-X does not support BGP. > > Does anybody know if BGP support in the ASA5585-X is in roadmap? > More precisely... MP-BGP support in the ASA5585-X? > Any "oficial" link in the Cisco website about this? (I did't find it) > > Thanks a lot and best regards > > > > > > > -- 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 morrowc.lists at gmail.com Sat Oct 30 01:16:18 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sat, 30 Oct 2010 02:16:18 -0400 Subject: Topic: Inter-AS BGP Local Preference Matrix In-Reply-To: References: <96CA80CDCD822B4F9B41FB3A109C9359A3E64802CF@E2K7MAILBOX1.corp.cableone.net> Message-ID: On Fri, Oct 29, 2010 at 7:16 PM, Matthew Petach wrote: >> 5. All vendors should make an effort to standardize the values/value ranges offered with other vendors. >> 6. All vendors should offer a local preference matrix to their customers, listing the changes made to a specific AS (e.g. another vendor) to aid the customer in making an intelligent routing decision for load balancing and traffic engineering in a multivendor BGP environment. >> >> It's obviously something that each of us would need to do individually, but I'm wondering if there is any way this could become a de facto standard, or could be a method that the community at large could enforce somehow. >> > > I'm not sure what incentive there would be for the providers to > coordinate like this; > it would mean quite a bit more work for them, with no appreciable gain > in revenue > for it. not to mention the sloshing of traffic to get to a standard... weee! From tstevens at cisco.com Sat Oct 30 08:35:10 2010 From: tstevens at cisco.com (Tim Stevenson) Date: Sat, 30 Oct 2010 06:35:10 -0700 Subject: Weird Nexus AD In-Reply-To: References: Message-ID: <201010301335.o9UDZYCJ017848@sj-core-2.cisco.com> am = adjacency manager. Since NXOS is a modular OS, different processes/services source routes to the URIB, and AM is one of them. OSPF, BGP, other RPs, HSRP, etc also feed their routes to the URIB. AM really only feeds directly connected host prefixes (/32) to the RIB (ie, for each resolved ARP entry). These entries are not shown in sh ip route by default (unless you're running very old code) - I assume you are using sh ip route am to see these? If so, completely expected. We can take the discussion to cisco-nsp or offline if you need more information. Hope that helps, Tim At 09:36 PM 10/29/2010, Colby Glass uttered: > system: version 4.2(2a) > >I've read that am = adjacency module or adjacency manager. The words mean >less to me than why I seem to be learning this route from a phantom >module/manager/interface with no visible explanation. > >I can try on c-nsp as well. Thought NANOG might be a better choice. > >Colby > >On Sat, Oct 30, 2010 at 12:04 AM, christian koch wrote: > > > in x/y, x= preference, y= metric > > > > am= adjacency module, *= best unicast route > > > > a better place to have asked this would be c-nsp > > > > hth > > > > -ck > > > > > > On Fri, Oct 29, 2010 at 7:21 PM, Colby Glass > wrote: > > > >> We're seeing an AD of 2 on some routes on our Nexus 7k. I can't find > >> anything (Google) to indicate where this value is coming from. Also unable > >> to find out what "am" mean (adjacency module?). Does anyone have an > >> explanation for this one? > >> > >> * via 192.168.21.49, Vlan13, [2/0], 00:44:52, am* > >> > >> Thanks > >> > >> -- > >> Colby Glass > >> Network Engineer > >> http://blog.alwaysthenetwork.com > >> > > > > > > >-- >Colby Glass >Network Engineer >http://blog.alwaysthenetwork.com Tim Stevenson, tstevens at cisco.com Routing & Switching CCIE #5561 Distinguished Technical Marketing Engineer, Cisco Nexus 7000 Cisco - http://www.cisco.com IP Phone: 408-526-6759 ******************************************************** The contents of this message may be *Cisco Confidential* and are intended for the specified recipients only. From pica8.org at gmail.com Sat Oct 30 09:42:36 2010 From: pica8.org at gmail.com (Lin Pica8) Date: Sat, 30 Oct 2010 16:42:36 +0200 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) Message-ID: Hello, For your information : http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1 Mail : pica8.org at gmail.com 2010/10/19 Lin Pica8 : > Hello, > > To have a better overview of a Cloud (or OpenFlow) Switch, I would > greatly appreciate to invite you to a further reading of the > presentation entitled "FI technologies on cloud computing and trusty > networking" from our partner, Chunghwa Telecom (Leading ISP in Taiwan) > : > > http://www.asiafi.net/meeting/2010/summerschool/p/chu.pdf > > Mail : pica8.org at gmail.com > > 2010/10/18 Lin Pica8 : >> Hello, >> >> We are starting to distribute Pica8 Open Source Cloud Switches : >> >> http://www.pica8.com/ >> >> Especially, a Pica8 Switch with the following specifications >> (including Open Source Firmware) : >> >> -HW : 48x1Gbps + 4x10 Gbps >> >> -Firmware : ?L2/L3 management for VLAN, LACP, STP/RSTP, LLDP, OSPF, >> RIP, static route, PIM-SM, VRRP, IGMP, IGMP Snooping, IPv6, >> Radius/Tacacs+ as well as OpenFlow 1.0 >> >> would compete with a Cisco Catalyst 2960-S, Model WS-C2960S-48TD-L for >> half the price (~2k USD). >> >> Mail : pica8.org at gmail.com >> > From randy at psg.com Sat Oct 30 13:04:24 2010 From: randy at psg.com (Randy Bush) Date: Sun, 31 Oct 2010 03:04:24 +0900 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: Message-ID: > Hello, > > For your information : > > http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1 your spam is getting annoying randy From pica8.org at gmail.com Sat Oct 30 13:08:21 2010 From: pica8.org at gmail.com (Lin Pica8) Date: Sat, 30 Oct 2010 20:08:21 +0200 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: Message-ID: plonk 2010/10/30 Randy Bush : >> Hello, >> >> For your information : >> >> http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1 > > your spam is getting annoying > > randy > From cmadams at hiwaay.net Sat Oct 30 13:24:26 2010 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 30 Oct 2010 13:24:26 -0500 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: Message-ID: <20101030182426.GB29924@hiwaay.net> Once upon a time, Randy Bush said: > > Hello, > > > > For your information : > > > > http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1 > > your spam is getting annoying Me too I've received direct spam as well about this crap as well, presumably from list address harvesting from NANOG or other similar list. The way to sell stuff to net admins is not to spam them; I have a special mail folder that I store all such vendor spam to make sure I never accidentally buy from them in the future. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From gordslater at ieee.org Sat Oct 30 13:26:20 2010 From: gordslater at ieee.org (gordon b slater) Date: Sat, 30 Oct 2010 19:26:20 +0100 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: Message-ID: <1288463180.29653.67.camel@ub-g-d2> On Sat, 2010-10-30 at 20:08 +0200, Lin Pica8 wrote: > plonk ... goes your custom Marketing by annoyance, smoke, and mirrors? Gotta love the strategy cya From randy at psg.com Sat Oct 30 13:28:25 2010 From: randy at psg.com (Randy Bush) Date: Sun, 31 Oct 2010 03:28:25 +0900 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: <1288463180.29653.67.camel@ub-g-d2> References: <1288463180.29653.67.camel@ub-g-d2> Message-ID: >> plonk > ... goes your custom > Marketing by annoyance, smoke, and mirrors? Gotta love the strategy do not buy from spammers From lyndon at orthanc.ca Sat Oct 30 13:30:50 2010 From: lyndon at orthanc.ca (Lyndon Nerenberg (VE6BBM/VE7TFX)) Date: Sat, 30 Oct 2010 11:30:50 -0700 Subject: Mystery open source switching company claims top-of-rack price In-Reply-To: <1288463180.29653.67.camel@ub-g-d2> Message-ID: <5a4be26b9cc673697e7b62f583ab69d4@gandalf.orthanc.ca> > Marketing by annoyance, smoke, and mirrors? Gotta love the strategy But as was demonstrated by the link they posted earlier today, they make a good filter for determining "news" organizations that operate on the theory of "news by press release." Think of them as a honeypot feed :-P --lyndon From tammy-lists at wiztech.biz Sat Oct 30 13:40:06 2010 From: tammy-lists at wiztech.biz (Tammy A Wisdom) Date: Sat, 30 Oct 2010 18:40:06 +0000 Subject: Mystery open source switching company claims top-of-rack price edge(was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: Message-ID: <1969681627-1288464015-cardhu_decombobulator_blackberry.rim.net-961813133-@bda399.bisx.prod.on.blackberry> Put down the crackpipe. Your product isn't that great the b& should be dropped on u shortly Ps welcome to the ahbl tard Tammy Tammy A Wisdom Summit Open Source Development Group -----Original Message----- From: Lin Pica8 Date: Sat, 30 Oct 2010 16:42:36 To: Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) Hello, For your information : http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1 Mail : pica8.org at gmail.com 2010/10/19 Lin Pica8 : > Hello, > > To have a better overview of a Cloud (or OpenFlow) Switch, I would > greatly appreciate to invite you to a further reading of the > presentation entitled "FI technologies on cloud computing and trusty > networking" from our partner, Chunghwa Telecom (Leading ISP in Taiwan) > : > > http://www.asiafi.net/meeting/2010/summerschool/p/chu.pdf > > Mail : pica8.org at gmail.com > > 2010/10/18 Lin Pica8 : >> Hello, >> >> We are starting to distribute Pica8 Open Source Cloud Switches : >> >> http://www.pica8.com/ >> >> Especially, a Pica8 Switch with the following specifications >> (including Open Source Firmware) : >> >> -HW : 48x1Gbps + 4x10 Gbps >> >> -Firmware : ?L2/L3 management for VLAN, LACP, STP/RSTP, LLDP, OSPF, >> RIP, static route, PIM-SM, VRRP, IGMP, IGMP Snooping, IPv6, >> Radius/Tacacs+ as well as OpenFlow 1.0 >> >> would compete with a Cisco Catalyst 2960-S, Model WS-C2960S-48TD-L for >> half the price (~2k USD). >> >> Mail : pica8.org at gmail.com >> > From bruns at 2mbit.com Sat Oct 30 13:40:43 2010 From: bruns at 2mbit.com (Brielle Bruns) Date: Sat, 30 Oct 2010 18:40:43 +0000 Subject: Mystery open source switching company claims top-of-rack priceedge (was Re: Pica8 - Open Source Cloud Switch) Message-ID: <969772788-1288464045-cardhu_decombobulator_blackberry.rim.net-465501981-@bda400.bisx.prod.on.blackberry> Welcome to the AHBL, pica8. Hope you enjoy your stay, and don't expect us to be recommending your products to our data center clients. Nothing pisses me off more then a company claiming to support open source software that spams. ------Original Message------ From: Lin Pica8 To: Randy Bush Cc: nanog at nanog.org Subject: Re: Mystery open source switching company claims top-of-rack priceedge (was Re: Pica8 - Open Source Cloud Switch) Sent: Oct 30, 2010 12:08 PM plonk 2010/10/30 Randy Bush : >> Hello, >> >> For your information : >> >> http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1 > > your spam is getting annoying > > randy > -- Brielle Bruns http://www.sosdg.org / http://www.ahbl.org From pica8.org at gmail.com Sat Oct 30 13:44:18 2010 From: pica8.org at gmail.com (Lin Pica8) Date: Sat, 30 Oct 2010 20:44:18 +0200 Subject: Mystery open source switching company claims top-of-rack price edge(was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: <1969681627-1288464015-cardhu_decombobulator_blackberry.rim.net-961813133-@bda399.bisx.prod.on.blackberry> References: <1969681627-1288464015-cardhu_decombobulator_blackberry.rim.net-961813133-@bda399.bisx.prod.on.blackberry> Message-ID: plonk NANOGers are only followers. We are 1 second ahead of you. Mail : pica8.org@ 2010/10/30 Tammy A Wisdom : > Put down the crackpipe. Your product isn't that great > the b& should be dropped on u shortly > Ps welcome to the ahbl tard > Tammy > > Tammy A Wisdom > Summit Open Source Development Group > > > -----Original Message----- > From: Lin Pica8 > Date: Sat, 30 Oct 2010 16:42:36 > To: > Subject: Mystery open source switching company claims top-of-rack price edge > ? ? ? ?(was Re: Pica8 - Open Source Cloud Switch) > > Hello, > > For your information : > > http://www.networkworld.com/news/2010/102810-pica8-opensource-switching.html?page=1 > > Mail : pica8.org at gmail.com > > 2010/10/19 Lin Pica8 : >> Hello, >> >> To have a better overview of a Cloud (or OpenFlow) Switch, I would >> greatly appreciate to invite you to a further reading of the >> presentation entitled "FI technologies on cloud computing and trusty >> networking" from our partner, Chunghwa Telecom (Leading ISP in Taiwan) >> : >> >> http://www.asiafi.net/meeting/2010/summerschool/p/chu.pdf >> >> Mail : pica8.org at gmail.com >> >> 2010/10/18 Lin Pica8 : >>> Hello, >>> >>> We are starting to distribute Pica8 Open Source Cloud Switches : >>> >>> http://www.pica8.com/ >>> >>> Especially, a Pica8 Switch with the following specifications >>> (including Open Source Firmware) : >>> >>> -HW : 48x1Gbps + 4x10 Gbps >>> >>> -Firmware : ?L2/L3 management for VLAN, LACP, STP/RSTP, LLDP, OSPF, >>> RIP, static route, PIM-SM, VRRP, IGMP, IGMP Snooping, IPv6, >>> Radius/Tacacs+ as well as OpenFlow 1.0 >>> >>> would compete with a Cisco Catalyst 2960-S, Model WS-C2960S-48TD-L for >>> half the price (~2k USD). >>> >>> Mail : pica8.org at gmail.com >>> >> > > From gordslater at ieee.org Sat Oct 30 13:54:01 2010 From: gordslater at ieee.org (gordon b slater) Date: Sat, 30 Oct 2010 19:54:01 +0100 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: <1288463180.29653.67.camel@ub-g-d2> Message-ID: <1288464841.29653.88.camel@ub-g-d2> On Sun, 2010-10-31 at 03:28 +0900, Randy Bush wrote: > >> plonk > > ... goes your custom > > Marketing by annoyance, smoke, and mirrors? Gotta love the strategy > > do not buy from spammers ...goes without saying. I'm just wondering if this a guerilla launch for some new Oracle product or project, or what, exactly? I'm _very_ confused. Maybe Paul K. can clear it all up, but apparently he's out of the office right now. Meanwhile, I'm failing to see a product, figures, source code, or more to the point, any operational aspect at all in any of these ad-spam posts. Consider this a formal request for root-plink, before we have a major corp try to sell us a database solution or proprietary kernel via the list. Gord -- From pica8.org at gmail.com Sat Oct 30 14:05:23 2010 From: pica8.org at gmail.com (Lin Pica8) Date: Sat, 30 Oct 2010 21:05:23 +0200 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: <1288464841.29653.88.camel@ub-g-d2> References: <1288463180.29653.67.camel@ub-g-d2> <1288464841.29653.88.camel@ub-g-d2> Message-ID: Buy you glasses and a book about network engineering ;) ! > Meanwhile, I'm failing to see a product http://www.pica8.org/products/pronto-3780 > source code http://sourceforge.net/p/xorplus/home/ > or more to the point, any operational aspect at all in any of these ad-spam posts. Pica natively runs Linux and the code is Open Source. So, you can not only run 3rd party code (like with Cisco AXP, Juniper Junos SDK or Arista EOS), but also modify the Networking Stack according to your needs that is a very interesting feature from an Operational point of view and something that is not possible with closed source OS like EOS, JUNOS and IOS. Vyatta tries to make also an Open-Source Networking product but the bottleneck is *the performance*. The target is to attack Cisco by the bottom. Especially, there are a lot of small operators (like the members of the NANOG) who are interested by low-cost gear. To be more precise, Cisco doesn't loose any significant Market Share due to the second market (used equipment) that is worth many billions each year according to the UNEDA (United Network Equipment Dealer Association). They can't buy the latest Cisco gear but they are still used to Cisco, because they buy refurbished Cisco gear. Pica8 provides its first significant breakthrough there : to have an access to the latest networking gear for the price of the refurbished one. That is *$ 200 per 10G port* or half the price of the closest competitor, Blade Network Technologies. We definitely believe that a new networking product should only focus on the Capex in the first place then think about the Opex in a second step (OpenFlow). Mail : pica8.org at gmail.com 2010/10/30 gordon b slater : > On Sun, 2010-10-31 at 03:28 +0900, Randy Bush wrote: >> >> plonk >> > ... goes your custom >> > Marketing by annoyance, smoke, and mirrors? Gotta love the strategy >> >> do not buy from spammers > > > ...goes without saying. > > I'm just wondering if this a guerilla launch for some new Oracle product > or project, or what, exactly? I'm _very_ confused. > > Maybe Paul K. can clear it all up, but apparently he's out of the office > right now. > > Meanwhile, I'm failing to see a product, figures, source code, or more > to the point, any operational aspect at all in any of these ad-spam > posts. > > Consider this a formal request for root-plink, before we have a major > corp try to sell us a database solution or proprietary kernel via the > list. > > > > Gord > -- > > > From gordslater at ieee.org Sat Oct 30 14:24:23 2010 From: gordslater at ieee.org (gordon b slater) Date: Sat, 30 Oct 2010 20:24:23 +0100 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: <1288463180.29653.67.camel@ub-g-d2> <1288464841.29653.88.camel@ub-g-d2> Message-ID: <1288466663.29653.91.camel@ub-g-d2> On Sat, 2010-10-30 at 21:05 +0200, Lin Pica8 wrote: > Buy you glasses and a book about network engineering ;) ! eat your own words "in any of these ad-spam posts" Now get out, and stay out, of my NOCs Gord From grobe0ba at gmail.com Sat Oct 30 14:32:35 2010 From: grobe0ba at gmail.com (Atticus) Date: Sat, 30 Oct 2010 15:32:35 -0400 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: <1288466663.29653.91.camel@ub-g-d2> References: <1288463180.29653.67.camel@ub-g-d2> <1288464841.29653.88.camel@ub-g-d2> <1288466663.29653.91.camel@ub-g-d2> Message-ID: What interests me is that they can't even be bothered to set up their own mail server, or at the very least to use Google Apps for mail. From frnkblk at iname.com Sat Oct 30 16:14:56 2010 From: frnkblk at iname.com (Frank Bulk - iName.com) Date: Sat, 30 Oct 2010 16:14:56 -0500 Subject: IPv6 Routing table will be bloated? In-Reply-To: References: <41122024.13163.1288116066323.JavaMail.root@zimbra.network1.net><9DE76765-96E0-4BB9-AD73-115467A61331@delong.com> <5A6D953473350C4B9995546AFE9939EE0B14C504@RWC-EX1.corp.seven.com> Message-ID: A combo WISP and pre-DOCSIS cable system we bought four years ago in a relatively rural area had exactly such a setup with Sprint and UUNet/Verizon/MCI. They had just one T-1 with each provider and a very simple BGP configuration. I just checked, and see that their ASN has been reused. Frank -----Original Message----- From: Chris Boyd [mailto:cboyd at gizmopartners.com] Sent: Tuesday, October 26, 2010 3:08 PM To: NANOG Subject: Re: IPv6 Routing table will be bloated? On Oct 26, 2010, at 2:45 PM, George Bonser wrote: > But how do they multihome without an ASN? > If they have an ASN, how did they get it without going to an RIR and > paying a fee? I beleive Jack said that they have redundant connections to his network. I took that to mean that they did not multihome to different AS. Such arrangements are not uncommon. Sprint seems to have done very well selling this sort of near-turnkey service to rural DSL carriers, tiny single town MSOs and the like. --Chris From oberman at es.net Sat Oct 30 16:26:21 2010 From: oberman at es.net (Kevin Oberman) Date: Sat, 30 Oct 2010 14:26:21 -0700 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: Your message of "Sun, 31 Oct 2010 03:28:25 +0900." Message-ID: <20101030212621.460611CC45@ptavv.es.net> > Date: Sun, 31 Oct 2010 03:28:25 +0900 > From: Randy Bush > > >> plonk > > ... goes your custom > > Marketing by annoyance, smoke, and mirrors? Gotta love the strategy > > do not buy from spammers I might also mention that I received private SPAM from a name we all know and loath. (Hint: He's been banned from NANOG for VERY good reason and his name is of French derivation.) I just added a filter to block any mail mentioning pica8 and will see no more of this thread or their spam. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman at es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From gih at apnic.net Sat Oct 30 18:24:42 2010 From: gih at apnic.net (Geoff Huston) Date: Sun, 31 Oct 2010 10:24:42 +1100 Subject: Route hijacking Message-ID: <529666E9-802F-434B-A6A6-8FE3E2522E23@apnic.net> My bgp monitor tells me: *> 1.2.3.0/24 203.119.76.3 0 4608 1221 4637 3561 1299 12025 ? *> 5.4.3.0/24 202.12.28.1 0 4777 2516 1239 1299 12025 ? These are _not_ authorized announcements, so could AS3561 Savvis AS1299 Telia AS1239 Sprintlink kindly DROP these unauthorized route advertisements (and clean up their route acceptance processes so that they stop announcing unauthorized noise to the rest of the Internet). And could the folk who run AS12025 IO-DATA-CENTERS - IO Data Centers kindly stop route hijacking? thanks, Geoff From Valdis.Kletnieks at vt.edu Sun Oct 31 09:21:44 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 31 Oct 2010 10:21:44 -0400 Subject: Topic: Inter-AS BGP Local Preference Matrix In-Reply-To: Your message of "Fri, 29 Oct 2010 09:55:06 PDT." <96CA80CDCD822B4F9B41FB3A109C9359A3E64802CF@E2K7MAILBOX1.corp.cableone.net> References: <96CA80CDCD822B4F9B41FB3A109C9359A3E64802CF@E2K7MAILBOX1.corp.cableone.net> Message-ID: <171552.1288534904@localhost> On Fri, 29 Oct 2010 09:55:06 PDT, "Rettke, Brian" said: > It's obviously something that each of us would need to do individually, but > I'm wondering if there is any way this could become a de facto standard, > or could be a method that the community at large could enforce somehow. Alice's Restaurant. If one customer asks for it, if two ask for it, if 50 ask for it... Just put your requirements into the RFP, and make it clear your $$ are going to the outfit that does the best on your list of 6 requirements. Remind the losers of this. Get 49 of your friends to put it in RFP's too. The providers are *not* going to do something like this unless there's a good economic basis for doing it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Sun Oct 31 09:22:32 2010 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Sun, 31 Oct 2010 10:22:32 -0400 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: Your message of "Thu, 21 Oct 2010 19:21:41 PDT." <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> Message-ID: <171584.1288534952@localhost> On Thu, 21 Oct 2010 19:21:41 PDT, George Bonser said: > With v6, while changing prefixes is easy for some gear, other gear is > not so easy. If you number your entire network in Provider A's space, > you might have more trouble renumbering into Provider B's space because > now you have to change your DHCP ranges, probably visit printers, fax > machines, wireless gateways, etc. and renumber those, etc. And some > production boxes that you might have in the office data center are > probably best left at a static IP address, particularly if they are > fronted by a load balancer where their IP is manually configured. "If Woody had gone straight to a ULA prefix, this would never have happened..." If a site is numbering their internal IPv4 stuff to avoid having to renumber on a provider change, then why would they number their IPv6 stuff from provider space rather than ULA space? And remember - (a) IPv6 allows machine to easily support multiple addresses and (b) if you have a provider address and a ULA, changing providers only means renumbering a *partial* renumber of the hosts that require external visibility - your internal hosts can continue talking to each other on a ULA as if nothing happened. Sure beats the mayhem if your company buys an organization and the 1918 spaces the 2 groups use overlap... Yee-hah. ;) -------------- 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 Sun Oct 31 11:31:47 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 31 Oct 2010 09:31:47 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: <171584.1288534952@localhost> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> Message-ID: On Oct 31, 2010, at 7:22 AM, Valdis.Kletnieks at vt.edu wrote: > On Thu, 21 Oct 2010 19:21:41 PDT, George Bonser said: > >> With v6, while changing prefixes is easy for some gear, other gear is >> not so easy. If you number your entire network in Provider A's space, >> you might have more trouble renumbering into Provider B's space because >> now you have to change your DHCP ranges, probably visit printers, fax >> machines, wireless gateways, etc. and renumber those, etc. And some >> production boxes that you might have in the office data center are >> probably best left at a static IP address, particularly if they are >> fronted by a load balancer where their IP is manually configured. > > "If Woody had gone straight to a ULA prefix, this would never have happened..." > Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. > If a site is numbering their internal IPv4 stuff to avoid having to renumber > on a provider change, then why would they number their IPv6 stuff from > provider space rather than ULA space? > Which gains what vs. PI? > And remember - (a) IPv6 allows machine to easily support multiple addresses and > (b) if you have a provider address and a ULA, changing providers only means > renumbering a *partial* renumber of the hosts that require external visibility > - your internal hosts can continue talking to each other on a ULA as if nothing > happened. > If you have PI space, changing providers can be even easier and you can leave multiple providers running in parallel. Owen From morrowc.lists at gmail.com Sun Oct 31 11:45:05 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 31 Oct 2010 12:45:05 -0400 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> Message-ID: On Sun, Oct 31, 2010 at 12:31 PM, Owen DeLong wrote: > > On Oct 31, 2010, at 7:22 AM, Valdis.Kletnieks at vt.edu wrote: > >> On Thu, 21 Oct 2010 19:21:41 PDT, George Bonser said: >> >>> With v6, while changing prefixes is easy for some gear, other gear is >>> not so easy. ?If you number your entire network in Provider A's space, >>> you might have more trouble renumbering into Provider B's space because >>> now you have to change your DHCP ranges, probably visit printers, fax >>> machines, wireless gateways, etc. and renumber those, etc. ?And some >>> production boxes that you might have in the office data center are >>> probably best left at a static IP address, particularly if they are >>> fronted by a load balancer where their IP is manually configured. >> >> "If Woody had gone straight to a ULA prefix, this would never have happened..." >> > Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, > either. ula really never should an option... except for a short lived lab, nothing permanent. From matthew at matthew.at Sun Oct 31 12:26:46 2010 From: matthew at matthew.at (Matthew Kaufman) Date: Sun, 31 Oct 2010 10:26:46 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> Message-ID: <4CCDA6D6.8030408@matthew.at> On 10/31/2010 9:31 AM, Owen DeLong wrote: > > Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, > either. > And he can justify PI when he first deploys IPv6 with a single provider under which policy? (Assume he is in the ARIN region and that his IPv4 space is currently provider-assigned from a couple of different providers and he's using NAT to do his IPv4 failover management) 1. Quite possibly does not qualify for an IPv4 assigned under the current IPv4 policy (certainly not in a few more months, when *nobody* will qualify except for some transition-space requests) 2. Definitely can't show efficient utilization of all direct IPv4 assignments, as he has none. 3. He's not a community network. So he can't go "straight to PI". He either needs to go PA with the first provider, then through renumbering pain (which he knows all too well about from IPv4, and none of the problems like "change the address of the intranet wiki server in the internal DNS servers" change with IPv6), or use something internal like ULA for things he doesn't want to renumber. >> If a site is numbering their internal IPv4 stuff to avoid having to renumber >> on a provider change, then why would they number their IPv6 stuff from >> provider space rather than ULA space? >> > Which gains what vs. PI? Nothing, but PI isn't available to him. See above. >> And remember - (a) IPv6 allows machine to easily support multiple addresses and >> (b) if you have a provider address and a ULA, changing providers only means >> renumbering a *partial* renumber of the hosts that require external visibility >> - your internal hosts can continue talking to each other on a ULA as if nothing >> happened. >> > If you have PI space, changing providers can be even easier and you can leave > multiple providers running in parallel. That's a big IF, given the above. He doesn't qualify for PI space, thanks to ARIN policies set by people who want routing tables to stay as small as possible, so PI space to be as difficult as possible to obtain for people like him. Matthew Kaufman From mpetach at netflight.com Sun Oct 31 12:58:27 2010 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 31 Oct 2010 10:58:27 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: <4CCDA6D6.8030408@matthew.at> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> <4CCDA6D6.8030408@matthew.at> Message-ID: On Sun, Oct 31, 2010 at 10:26 AM, Matthew Kaufman wrote: > On 10/31/2010 9:31 AM, Owen DeLong wrote: >> If you have PI space, changing providers can be even easier and you can >> leave >> multiple providers running in parallel. > > That's a big IF, given the above. He doesn't qualify for PI space, thanks to > ARIN policies set by people who want routing tables to stay as small as > possible, so PI space to be as difficult as possible to obtain for people > like him. Would it help if ARIN's policies were changed to allow anyone and everyone to obtain PI space directly from them (for the appropriate fee, of course), and then it was left up to the operating community to decide whether or not to route the smaller chunks of space? Right now, we're trying to keep the two communities somewhat in alignment, so that when people obtain IP space, they have a relatively good feeling about it being routed correctly. If we let the ARIN policies stray too far from what the router operators can/will accept, we're going to end up with an ugly, fragmented internet in which organizations are given PI GUA space, only to discover it's not actually useful for reaching large swaths of the internet. I'd hazard a guess that people would consider that to be a worse scenario than the one in which we limit who can get PI space so that there's a reasonably good probability that when the space is issued and announced via BGP, it will be reachable from most of the rest of the internet...that is to say, our current modus operandi. > Matthew Kaufman Matt From gbonser at seven.com Sun Oct 31 13:01:56 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 31 Oct 2010 11:01:56 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net><4CC070E9.7090709@unfix.org><5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com><171584.1288534952@localhost> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C653@RWC-EX1.corp.seven.com> > ula really never should an option... except for a short lived lab, > nothing permanent. I have a few candidate networks for it. Mostly networks used for clustering or database access where they are just a flat LAN with no "gateway". No layer 3 gets routed off that subnet and the only things talking on it are directly attached to it. From gbonser at seven.com Sun Oct 31 13:13:45 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 31 Oct 2010 11:13:45 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net><4CC070E9.7090709@unfix.org><5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com><171584.1288534952@localhost><4CCDA6D6.8030408@matthew.at> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C654@RWC-EX1.corp.seven.com> > Would it help if ARIN's policies were changed to allow anyone and > everyone > to obtain PI space directly from them (for the appropriate fee, of > course), and > then it was left up to the operating community to decide whether or not > to > route the smaller chunks of space? I would probably support something like that with a few caveats. One being that we try to keep things as aggregated as possible. If someone grows out of a /48, they get say, a /46 and don't get additional discontiguous /48 nets. Also, we should wait a while to do that. Once a significant portion of traffic has moved to v6, people might want to make decisions to mitigate routing table bloat with v4. Once v6 traffic exceeds v4 traffic, some of those decisions become easier to make (accept v4 routes from peers and shove any other traffic out to transit with a default, for example, rather than take full v4 routes from multiple transit peers.). I might be willing to accept some sub-optimal routing for v4 once v6 exceeds v4. Maybe others would be willing to, as well. From gustkiller at gmail.com Sun Oct 31 13:48:11 2010 From: gustkiller at gmail.com (Gustavo Santos) Date: Sun, 31 Oct 2010 15:48:11 -0300 Subject: Management , Provisioning , Fault detection and management for ISPs? Message-ID: Hi, I?m looking for some books, best common pratices and stuff like that for ISPs. We have an ISP that?s having a fast growth and we?re having some problems because lack of procedures. For an example two days ago we have a broadcast storm that coused a lot of problem and was harsh to find who is causing that issue , couse one of our clients made a self install ( not authorized in one of our multipoint access point) and somehow caused a loop. we have some types of circuit delivery to our customers like point to point licensed microwave , t1/e1 , fiber optic, and point to multipoint wireless. How you large ISPs deal with that kind of problem or that?s never happen becouse all your circuits are delivered in a private vlan, qinq, serial interfaces, point to point ? Thanks! -- Gustavo Santos Analista de Redes CCNA , MTCNA , JUNCIA-ER From owen at delong.com Sun Oct 31 14:01:40 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 31 Oct 2010 12:01:40 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> <4CCDA6D6.8030408@matthew.at> Message-ID: On Oct 31, 2010, at 10:58 AM, Matthew Petach wrote: > On Sun, Oct 31, 2010 at 10:26 AM, Matthew Kaufman wrote: >> On 10/31/2010 9:31 AM, Owen DeLong wrote: >>> If you have PI space, changing providers can be even easier and you can >>> leave >>> multiple providers running in parallel. >> >> That's a big IF, given the above. He doesn't qualify for PI space, thanks to >> ARIN policies set by people who want routing tables to stay as small as >> possible, so PI space to be as difficult as possible to obtain for people >> like him. > > Would it help if ARIN's policies were changed to allow anyone and everyone > to obtain PI space directly from them (for the appropriate fee, of course), and > then it was left up to the operating community to decide whether or not to > route the smaller chunks of space? > I really don't expect this to be as much of an issue in IPv6. > Right now, we're trying to keep the two communities somewhat in alignment, > so that when people obtain IP space, they have a relatively good feeling about > it being routed correctly. If we let the ARIN policies stray too far > from what the > router operators can/will accept, we're going to end up with an ugly, fragmented > internet in which organizations are given PI GUA space, only to > discover it's not > actually useful for reaching large swaths of the internet. > PI GUA is at least as useful in that context as ULA. > I'd hazard a guess that people would consider that to be a worse scenario > than the one in which we limit who can get PI space so that there's a reasonably > good probability that when the space is issued and announced via BGP, it will be > reachable from most of the rest of the internet...that is to say, our > current modus > operandi. > Not if they are turning to ULA. Owen From drc at virtualized.org Sun Oct 31 14:10:18 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 31 Oct 2010 09:10:18 -1000 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> Message-ID: On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote: >>> "If Woody had gone straight to a ULA prefix, this would never have happened..." >> Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. > ula really never should an option... except for a short lived lab, nothing permanent. Seems to me the options are: 1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell. My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers. That would seem to leave (3). Am I missing an option? Regards, -drc From drc at virtualized.org Sun Oct 31 14:12:27 2010 From: drc at virtualized.org (David Conrad) Date: Sun, 31 Oct 2010 09:12:27 -1000 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> <4CCDA6D6.8030408@matthew.at> Message-ID: On Oct 31, 2010, at 9:01 AM, Owen DeLong wrote: >> Would it help if ARIN's policies were changed to allow anyone and everyone >> to obtain PI space directly from them (for the appropriate fee, of course), and >> then it was left up to the operating community to decide whether or not to >> route the smaller chunks of space? > I really don't expect this to be as much of an issue in IPv6. Why would the commercial interests that have driven ISPs to remove long prefix length filters in IPv4 not apply to IPv6? Regards, -drc From gbonser at seven.com Sun Oct 31 14:23:10 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 31 Oct 2010 12:23:10 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net><4CC070E9.7090709@unfix.org><5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com><171584.1288534952@localhost> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C656@RWC-EX1.corp.seven.com> > > Seems to me the options are: > > 1) PI, resulting in no renumbering costs, but RIR costs and routing > table bloat > 2) PA w/o ULA, resulting in full site renumbering cost, no routing > table bloat > 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no > routing table bloat > In my particular case, IPv6 offers no advantage when it comes to renumbering. It is just exactly as difficult to renumber with v6 as it is with v4. I do understand that in a lot of cases where end nodes are autoconfiguring based on RA it makes it easy but in many places that really isn't an option. From kilobit at gmail.com Sun Oct 31 17:59:27 2010 From: kilobit at gmail.com (bas) Date: Sun, 31 Oct 2010 23:59:27 +0100 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: <20101030212621.460611CC45@ptavv.es.net> References: <20101030212621.460611CC45@ptavv.es.net> Message-ID: Hi, On Sat, Oct 30, 2010 at 11:26 PM, Kevin Oberman wrote: > I might also mention that I received private SPAM from a name we all > know and loath. (Hint: He's been banned from NANOG for VERY good > reason and his name is of French derivation.) I just added a filter to > block any mail mentioning pica8 and will see no more of this thread or > their spam. Same here. He harvests email addresses from peeringdb. (I have slight typo's in my peeringdb record to recognize harvested spams.) Bas From eric at roxanne.org Sun Oct 31 19:45:49 2010 From: eric at roxanne.org (Eric Gauthier) Date: Sun, 31 Oct 2010 20:45:49 -0400 Subject: Optical Wireless In-Reply-To: <4CC1E7C3.6060400@xyonet.com> References: <4CC1E7C3.6060400@xyonet.com> Message-ID: <20101101004549.GA2340@roxanne.org> Hello, > Canon. Canobeam laser systems. Very nice, very fast. I've heard of > installations going around a mile and stayed up in a snow storm. We swapped out our Canobeams a while ago for units by Bridgewave (http://www.bridgewave.com/) Eric :) From pauldotwall at gmail.com Sun Oct 31 20:07:01 2010 From: pauldotwall at gmail.com (Paul WALL) Date: Sun, 31 Oct 2010 21:07:01 -0400 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: <20101030212621.460611CC45@ptavv.es.net> Message-ID: I don't know what the big deal is. I've rolled at least 20 of these switches into my network, and not only are they more stable than the Centillion switches that they replaced, they only cost half as much. Most of the money I dropped was on converting my stations from token ring to ethernet. On Sun, Oct 31, 2010 at 6:59 PM, bas wrote: > Hi, > > On Sat, Oct 30, 2010 at 11:26 PM, Kevin Oberman wrote: >> I might also mention that I received private SPAM from a name we all >> know and loath. (Hint: He's been banned from NANOG for VERY good >> reason and his name is of French derivation.) I just added a filter to >> block any mail mentioning pica8 and will see no more of this thread or >> their spam. > > Same here. > He harvests email addresses from peeringdb. (I have slight typo's in > my peeringdb record to recognize harvested spams.) > > Bas > > From morrowc.lists at gmail.com Sun Oct 31 20:29:27 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 31 Oct 2010 21:29:27 -0400 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses) In-Reply-To: <5A6D953473350C4B9995546AFE9939EE0B14C653@RWC-EX1.corp.seven.com> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> <5A6D953473350C4B9995546AFE9939EE0B14C653@RWC-EX1.corp.seven.com> Message-ID: On Sun, Oct 31, 2010 at 2:01 PM, George Bonser wrote: >> ula really never should an option... except for a short lived lab, >> nothing permanent. > > I have a few candidate networks for it. ?Mostly networks used for > clustering or database access where they are just a flat LAN with no > "gateway". ?No layer 3 gets routed off that subnet and the only things > talking on it are directly attached to it. why not just use link-local then? eventually you'll have to connect that network with another one, chances of overlap (if the systems support real revenue) are likely too high to want to pay the renumbering costs, so even link-local isn't a 100% win :( globally-unique is really the best option all around. -chris From morrowc.lists at gmail.com Sun Oct 31 20:32:39 2010 From: morrowc.lists at gmail.com (Christopher Morrow) Date: Sun, 31 Oct 2010 21:32:39 -0400 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> Message-ID: On Sun, Oct 31, 2010 at 3:10 PM, David Conrad wrote: > On Oct 31, 2010, at 6:45 AM, Christopher Morrow wrote: >>>> "If Woody had gone straight to a ULA prefix, this would never have happened..." >>> Or better yet, if Woody had gone straight to PI, he wouldn't have this problem, either. >> ula really never should an option... except for a short lived lab, nothing permanent. > > Seems to me the options are: > > 1) PI, resulting in no renumbering costs, but RIR costs and routing table bloat > 2) PA w/o ULA, resulting in full site renumbering cost, no routing table bloat > 3) PA w/ ULA, resulting in externally visible-only renumbering cost, no routing table bloat > > Folks appear to have voted with their feet that (2) isn't really viable -- they got that particular T-shirt with IPv4 and have been uniformly against getting the IPv6 version, at last as far as I can tell. > > My impression (which may be wrong) is that with respect to (1), a) most folks can't justify a PI request to the RIR, b) most folks don't want to deal with the RIR administrative hassle, c) most ISPs would prefer to not have to replace their routers. > > That would seem to leave (3). > > Am I missing an option? I don't think so, though I'd add 2 bits to your 1 and 3 options: 1) we ought to make getting PI easy, easy enough that the other options just don't make sense. 2) ULA brings with it (as do any options that include multiple addresses) host-stack complexity and address-selection issues... 'do I use ULA here or GUA when talking to the remote host?' -chris From gbonser at seven.com Sun Oct 31 20:49:10 2010 From: gbonser at seven.com (George Bonser) Date: Sun, 31 Oct 2010 18:49:10 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net><4CC070E9.7090709@unfix.org><5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com><5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com><171584.1288534952@localhost><5A6D953473350C4B9995546AFE9939EE0B14C653@RWC-EX1.corp.seven.com> Message-ID: <5A6D953473350C4B9995546AFE9939EE0B14C65C@RWC-EX1.corp.seven.com> > > why not just use link-local then? eventually you'll have to connect > that network with another one, chances of overlap (if the systems > support real revenue) are likely too high to want to pay the > renumbering costs, so even link-local isn't a 100% win :( > globally-unique is really the best option all around. > > -chris Routing mostly on the end host is why. If I have 10 clustering vlans (which will never get routed outside the cluster) and they all have the same link local address (if the vlan interfaces are configured on the same ethernet device, they will all have the same link local address), how do they know which vlan interface to send the packet out? All of them will have exactly the same link local address. And I have an aversion to putting link local IPs in DNS as everyone thinks the hostname is on the local link in case of some kind of dns screwup. From maxlarson.henry at mtptc.gouv.ht Sun Oct 31 20:57:26 2010 From: maxlarson.henry at mtptc.gouv.ht (Max Larson Henry) Date: Sun, 31 Oct 2010 21:57:26 -0400 Subject: Bandwidth into Haiti In-Reply-To: References: Message-ID: > Has the landing station been repaired yet after last years earthquake ? > - Yes It's now in operation -M From kilobit at gmail.com Sun Oct 31 21:25:53 2010 From: kilobit at gmail.com (bas) Date: Mon, 1 Nov 2010 03:25:53 +0100 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: <20101030212621.460611CC45@ptavv.es.net> Message-ID: Hi Paul, On Mon, Nov 1, 2010 at 2:07 AM, Paul WALL wrote: > I don't know what the big deal is. ?I've rolled at least 20 of these > switches into my network, and not only are they more stable than the > Centillion switches that they replaced, they only cost half as much. > Most of the money I dropped was on converting my stations from token > ring to ethernet. All of the people that responded to this thread are not complaining about the hardware. They are complaining about Guillaume's spam strategy. Other than that are you comparing apples to apples when you compare Nortel ATM switches (with EOL somewhere in 2004) with new ethernet hardware? Bas From jeff-kell at utc.edu Sun Oct 31 21:34:49 2010 From: jeff-kell at utc.edu (Jeff Kell) Date: Sun, 31 Oct 2010 22:34:49 -0400 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: <20101030212621.460611CC45@ptavv.es.net> Message-ID: <4CCE2749.3070509@utc.edu> On 10/31/2010 10:25 PM, bas wrote: > Other than that are you comparing apples to apples when you compare > Nortel ATM switches (with EOL somewhere in 2004) with new ethernet > hardware? Nortel Centillion... had a cold chill run up my spine just thinking back about it... shadows of Synoptics... and Bay... sheesh... :-) Is this a commemorative Scary Halloween Ghost story? Watch y'er language folks :-) Jeff From marka at isc.org Sun Oct 31 21:43:39 2010 From: marka at isc.org (Mark Andrews) Date: Mon, 01 Nov 2010 13:43:39 +1100 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses) In-Reply-To: Your message of "Sun, 31 Oct 2010 21:29:27 EDT." References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> <5A6D953473350C4B9995546AFE9939EE0B14C653@RWC-EX1.corp.seven.com> Message-ID: <20101101024339.B716B62B8AB@drugs.dv.isc.org> In message , Chri stopher Morrow writes: > On Sun, Oct 31, 2010 at 2:01 PM, George Bonser wrote: > >> ula really never should an option... except for a short lived lab, > >> nothing permanent. > > > > I have a few candidate networks for it. =A0Mostly networks used for > > clustering or database access where they are just a flat LAN with no > > "gateway". =A0No layer 3 gets routed off that subnet and the only things > > talking on it are directly attached to it. > > why not just use link-local then? If you had actually every tried to use link-local then you would know why you don't use link-local. > eventually you'll have to connect > that network with another one, chances of overlap (if the systems > support real revenue) are likely too high to want to pay the > renumbering costs, so even link-local isn't a 100% win :( > globally-unique is really the best option all around. 2^40 is 1099511627776. The chances of collision are so low that one really shouldn't worry about it. You are millions of times more likely of dieing from a asteroid 1-in-500,000[1]. If you merge thousands of ULA and don't consolidate then you start to have a reasonable chance of collision. Even if you do have colliding ULA prefixes you don't necessarially have colliding subnets when merging companies. Just allocate subnet randomly. It's not like 2^16 internal subnets is going to be a major routing problem. Mark [1] http://www.livescience.com/environment/050106_odds_of_dying.html -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka at isc.org From joelja at bogus.com Sun Oct 31 21:51:20 2010 From: joelja at bogus.com (Joel Jaeggli) Date: Sun, 31 Oct 2010 19:51:20 -0700 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: <20101030212621.460611CC45@ptavv.es.net> Message-ID: On Oct 31, 2010, at 19:25, bas wrote: > Hi Paul, > > On Mon, Nov 1, 2010 at 2:07 AM, Paul WALL wrote: >> I don't know what the big deal is. I've rolled at least 20 of these >> switches into my network, and not only are they more stable than the >> Centillion switches that they replaced, they only cost half as much. >> Most of the money I dropped was on converting my stations from token >> ring to ethernet. > > All of the people that responded to this thread are not complaining > about the hardware. > They are complaining about Guillaume's spam strategy. > > Other than that are you comparing apples to apples when you compare > Nortel ATM switches (with EOL somewhere in 2004) with new ethernet > hardware? DJ Paul Wall only recently upgraded from FDDI... > Bas > > From owen at delong.com Sun Oct 31 23:05:54 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 31 Oct 2010 21:05:54 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses) In-Reply-To: References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> <4CCDA6D6.8030408@matthew.at> Message-ID: On Oct 31, 2010, at 12:12 PM, David Conrad wrote: > On Oct 31, 2010, at 9:01 AM, Owen DeLong wrote: >>> Would it help if ARIN's policies were changed to allow anyone and everyone >>> to obtain PI space directly from them (for the appropriate fee, of course), and >>> then it was left up to the operating community to decide whether or not to >>> route the smaller chunks of space? >> I really don't expect this to be as much of an issue in IPv6. > > Why would the commercial interests that have driven ISPs to remove long prefix length filters in IPv4 not apply to IPv6? > I don't expect the IPv6 routing table to be long enough to drive prefix filtration in the foreseeable future. Owen From randy at psg.com Sun Oct 31 23:28:38 2010 From: randy at psg.com (Randy Bush) Date: Mon, 01 Nov 2010 12:28:38 +0800 Subject: Mystery open source switching company claims top-of-rack price edge (was Re: Pica8 - Open Source Cloud Switch) In-Reply-To: References: <20101030212621.460611CC45@ptavv.es.net> Message-ID: > Other than that are you comparing apples to apples when you compare > Nortel ATM switches (with EOL somewhere in 2004) with new ethernet > hardware? arista rulz tos From owen at delong.com Sun Oct 31 23:25:33 2010 From: owen at delong.com (Owen DeLong) Date: Sun, 31 Oct 2010 21:25:33 -0700 Subject: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses) In-Reply-To: <20101101024339.B716B62B8AB@drugs.dv.isc.org> References: <4CBF63BF.2000101@mompl.net> <4CC070E9.7090709@unfix.org> <5A6D953473350C4B9995546AFE9939EE0B14C416@RWC-EX1.corp.seven.com> <5A6D953473350C4B9995546AFE9939EE0B14C423@RWC-EX1.corp.seven.com> <171584.1288534952@localhost> <5A6D953473350C4B9995546AFE9939EE0B14C653@RWC-EX1.corp.seven.com> <20101101024339.B716B62B8AB@drugs.dv.isc.org> Message-ID: On Oct 31, 2010, at 7:43 PM, Mark Andrews wrote: > > In message , Chri > stopher Morrow writes: >> On Sun, Oct 31, 2010 at 2:01 PM, George Bonser wrote: >>>> ula really never should an option... except for a short lived lab, >>>> nothing permanent. >>> >>> I have a few candidate networks for it. =A0Mostly networks used for >>> clustering or database access where they are just a flat LAN with no >>> "gateway". =A0No layer 3 gets routed off that subnet and the only things >>> talking on it are directly attached to it. >> >> why not just use link-local then? > > If you had actually every tried to use link-local then you would know why > you don't use link-local. > I use link local often for many things. Try again. >> eventually you'll have to connect >> that network with another one, chances of overlap (if the systems >> support real revenue) are likely too high to want to pay the >> renumbering costs, so even link-local isn't a 100% win :( >> globally-unique is really the best option all around. > > 2^40 is 1099511627776. The chances of collision are so low that > one really shouldn't worry about it. You are millions of times > more likely of dieing from a asteroid 1-in-500,000[1]. > There are almost 7,000,000,000 people on the planet. We have not had anywhere near 14,000 people killed by asteroids, I think their calculation is off. > If you merge thousands of ULA and don't consolidate then you start > to have a reasonable chance of collision. Even if you do have > colliding ULA prefixes you don't necessarially have colliding subnets > when merging companies. Just allocate subnet randomly. It's not > like 2^16 internal subnets is going to be a major routing problem. > This is, of course, assuming many things: 1. Everyone follows the same random ULA allocation algorithm. 2. The algorithm is not flawed and yields relatively smooth distribution without significant hot-spots. 3. People are not lazy 4. People read instructions Assumption 1 depends on assumptions 3 and 4. Assumption 2 is still relatively unknown as we don't have enough operational experience with it. Assumption 3 is pretty well provably false. Assumption 4 is virtually guaranteed to fail. Since Assumptions 3 and 4 are non-starters, assumption 1 is seriously flawed at best. Owen From jonny at jonnynet.net Sun Oct 31 08:02:54 2010 From: jonny at jonnynet.net (Jonny Martin) Date: Sun, 31 Oct 2010 09:02:54 -0400 Subject: APRICOT 2011 Call For Papers Message-ID: <70E12B7D-CBF2-4977-B40F-FA49F9012EE2@jonnynet.net> Asia Pacific Regional Internet Conference on Operational Technologies (APRICOT) 15 - 25 February 2011, Hong Kong http://www.apricot2011.net CALL FOR PAPERS =============== The APRICOT 2011 Programme Committee is now seeking contributions for Presentations and Tutorials for APRICOT 2011. We are looking for people and proposals that would: - Offer a technical tutorial on an appropriate topic; and/or - Participate in the technical conference sessions as a speaker; and/or - Convene and chair a Birds of a Feather (BOF) session. Please submit proposals on-line at http://www.apricot2011.net/call-for-papers/submission CONFERENCE MILESTONES --------------------- Call for Papers Opens: 29 October 2010 First Deadline for Submissions: 29 November 2010 First Draft Programme Published: 6 December 2010 Final Deadline for Submissions: 4 February 2011 Final Programme Published: 11 February 2011 Final Slides Received: 19 February 2011 PROGRAM MATERIAL ---------------- The APRICOT Programme is organised in three parts, including workshops, tutorials and the conference. The APNIC Policy SIG and Annual Members Meeting will be held during the APRICOT conference. Topics for tutorials and conference would include amongst others relevant to Internet Operations and Technologies: - IPv4 / IPv6 Routing and operations - IPv4 address runout / IPv6 deployment and transition technologies - Backbone operations - ISP and Carrier services - Network security issues (NSP-SEC, DDoS Anti-Spam, Anti-Malware) - Peering / IXPs - DNS / DNSSEC - Internet policy (Security, Regulation, Content Management, Addressing, etc) - Access and Transport Technologies, including broadband deployment, Cable/DSL, wireless, WiMax, metro ethernet, fiber network, MPLS - Content & Service Delivery (Multicast, Voice, Video, "telepresence", Gaming) CFP SUBMISSION -------------- Draft slides for both tutorials and conference sessions MUST be provided with CFP submissions otherwise the Programme Committee will be unable to review the submission. For work in progress, the most current information available at time of submission is acceptable. Final slides are to be provided by the specified deadline for publication on the APRICOT website. While the majority of speaking slots will be filled by the first submission deadline, a limited number of slots may be available up to the final submission deadline for presentations that are exceptionally timely, important, or of critical operational importance. Please submit on-line at http://www.apricot2011.net/call-for-papers/submission Any questions or concerns should be addressed to the Programme Committee by e-mail. We look forward to receiving your presentation proposals. Jonny Martin & Mark Tinka Co-Chairs, APRICOT Programme Committee program at apricot.net