Re: ipv6 transit over tunneled connection
On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy mulits...@acedsl.com wrote: Hello, We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? 1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris Thanks, Michael
Re: ipv6 transit over tunneled connection
On Fri, May 14, 2010 at 2:29 PM, Franck Martin fra...@genius.com wrote: I said somewhere in here... wierd quoting happened. On Thu, May 13, 2010 at 6:18 PM, Michael Ulitskiy mulits...@acedsl.com wrote: Hello, We're in the early stage of planning ipv6 deployment - learning/labbing/experimenting/etc. We've got to the point when we're also planning to request initial ipv6 allocation from ARIN. So I wonder what ipv6 transit options I have if my upstreams do not support native ipv6 connectivity? I see Hurricane Electric tunnel broker BGP tunnel. Is there anything else? Either free or commercial? 1) see gblx/ntt/sprint/twt/vzb for transit-v6 2) tunnel inside your domain (your control, your MTU issues, your alternate pathing of tunnels vs pipe) 3) don't tunnel beyond your borders, really just don't tunnels are bad, always. -chris I see so many times, that tunnels are bad for IPv6, but this is the way IPv6 has been designed to work when you cannot get direct IPv6. So I would not say tunnels are bad, but direct IPv6 is better (OECD document on IPv6 states the use of tunnels). Tunnels promote poor paths, they bring along LOTS of issues wrt PMTUD, asymmetry of paths, improper/inefficient paths (see example paths from several ripe preso's by jereon/others), longer latency. If the tunnel exits your border you can't control what happens and you can't affect that tunnels performance characteristics. it's 2010, get native v6. If the issue with tunnel is MTU, then a non-negligible part of IPv4 does not work well with MTU different of 1500. With IPv6 we bring the concept of jumbo packets, with large MTU. If we cannot work with non standard MTUs in IPv6 tunnels, how will we work with jumbo packets? a non-negligible part of the ipv6 internet doesn't work at all with 1280 mtu... due to tunnels and some other hackery :( jumbo packets are a fiction, everyone should stop 10 years ago believing they will ever work end-to-end between random sites. -Chris
Re: ipv6 transit over tunneled connection
On Fri, May 14, 2010 at 3:00 PM, Seth Mattinen se...@rollernet.us wrote: On 5/14/2010 11:49, Jared Mauch wrote: I'm curious what providers have not gotten their IPv6 plans/networks/customer ports enabled. I know that Comcast is doing their trials now (Thanks John!) and will be presenting at the upcoming NANOG about their experiences. What parts of the big I Internet are not enabled or ready? Verizon has POPs that aren't IPv6 enabled making it a pain in the ass if you're closer to one of those (currently on month 11 of waiting, I'm just letting it go because I'm curious how long it'll take), Sprint isn't doing native IPv6 with their GSR's yet, Cogent's IPv6 visibility is poor, Level3 isn't accepting new IPv6 beta connections, and ATT simply told me not available yet. Tunnels are still a necessity. twt, ntt, gblx, telia all have presence in the US, and all do v6 to customer links. vote with wallet.
Re: ipv6 transit over tunneled connection
On Fri, May 14, 2010 at 9:58 PM, Brielle Bruns br...@2mbit.com wrote: rant Just an observation, but I'm fairly sure that I'm not the only one who feels that those with rather high budgets tend to forget that not everyone has the luxury of a virtual blank check. /rant awesome, take an old 2800 or 2500, plug in a t1 to one of the providers listed (twt seems like a great choice, or atlantech, who I think also does v6 and seems to offer 300$/mon t1's regularly), run v6 ONLY on that, take the 10/100m ether out the back and v6-up the rest of your network. See, done for 300$/month... the reason I said 'find a provider that does do native v6, terminate there and tunnel or spread-out internally from there' was exactly because spending 'tens of thousands of dollars' right off the bat was probably hard to justify. thanks though. -chris
Re: ipv6 transit over tunneled connection
On Fri, May 14, 2010 at 11:25 PM, Michael Ulitskiy mulits...@acedsl.com wrote: So my question still stands: is anyone aware of a reasonable tunneled ipv6 transit service (I mean aside from HE tunnel broker)? The load will be really light. I don't expect we'll break a few Mbit/s in the nearest future and when we do then I guess it'll be the time to look for the native transit. beware the uTorrent ... (see johnb's notes about this) sixxs i think also had NYC based tunnel boxes, no? http://www.sixxs.net/pops/ usewr01 OCCAID Inc. uschi02 Your.Org, Inc. and I think kloch @carpathia was doing some of this for a time, though perhaps only ASH/PHX ? -chris
Re: Mikrotik BGP Question
On Fri, May 21, 2010 at 8:23 AM, Nick Hilliard n...@foobar.org wrote: On 21/05/2010 13:16, Lorell Hathcock wrote: each other. Just make sure your boxes have enough RAM to cope with a full dfz feed. note that you do NOT have to have a full feed on either location, if your goal is simply primary/backup links... getting default from both providers and sending your prefixes out to both (potentially preferring one with an intentionally longer aspath, or other normal tricks/config) will accomplish primary/backup just fine. Don't use a sledghammer when a push pin works. -chris
Re: txt.att.net operators
On Wed, May 26, 2010 at 11:17 AM, Mike Walter mwal...@3z.net wrote: We have been struggling to locate someone at ATT that handles the txt.att.net servers. We have clients in our data center that can no longer send emails to mobile phones via 10di...@txt.att.net. We have contacted ATT and they say there is no problem on their end. We can ping the server, but simply cannot connect to port 25. We have checked all firewalls of each client. Some ranges of IPs work and others don't. Looking for someone with a clue who can assist. this is not a guaranteed service, nor does it have an official SLA, and inbound mail/connections from louder speakers are often just dropped, either at the TCP layer, or at the application layer (even after what seems like a completed SMTP conversation.) If you depend upon SMS for things, smtp - sms gateways at the provider aren't reliable enough.
Re: FIOS Router
On Thu, May 27, 2010 at 3:40 PM, Chris Burwell cburw...@gmail.com wrote: To be honest, I'm not sure how they got the 100Mb service. The fastest service I have seen on the FiOS website is the 50/20. I can only assume that it varies by region. It does, or it used to... rumors were DFW was a good place to get the 100/100 service. As to the actiontec, just ditch it, if you have cat-5 from the ONT you've been presented with an ethernet LAN, plug that into any old switch and feed your end systems off that (presuming you have more than 1 ip address and static addressing). If you NEED a router/firewall, then get an ssg5 or use a little linux-alike box. -Chris On Thu, May 27, 2010 at 3:22 PM, Robert Enger - NANOG na...@enger.us wrote: Sadly, I have only the 50/20 FiOS service. I would love to get 100/100. Where do I sign up. My initial installation used MoCA. It would not reliably deliver 50Mbps on tcp-based download tests. (coax network brand new, very small). Test results were erratic, typically between 30 and 40Mbps. Technician told me to put up with it (not making this up). I fought with VZ and had them re-provision me to 100BaseT connection on the ONT. I immediately observed reliable, consistent download speeds at 51.8Mbps. (Since dropped to 49.2 after their speed re-provisioning a few months ago.) MoCA is a half-duplex channel with sophisticated MAC (e.g. BW reservations and so forth). The MoCA diag displays show that the STBs see each other and the Actiontech at speeds over 220Mbps. I doubt the issue is inadequate phy connection. I assume the interplay between the MoCA MAC and TCP yields poor performance. But, I did not research this. I had them take my Internet off the MoCA path and it has worked fine since. So, how I go about getting 100/100?
Re: Todd Underwood was a little late
On Thu, Jun 17, 2010 at 1:31 PM, Todd Underwood toddun...@gmail.com wrote: jon, all, i've received several questions about the context of this mail, so i thought it would be worth posting to clear up the reference. for those who missed it, i presented a lightning talk at nanog 49 in san francisco yesterday on some very early conceptual work on a really interesting strategy to dramatically extend the useful life of v4 prefixes. the talk is linked from: http://nanog.org/meetings/nanog49/agenda.php and i encourage people to take a look at it. ...nothing to see here, this is CGN's...
Re: Todd Underwood was a little late
On Mon, Jun 21, 2010 at 1:01 PM, Lee Howard l...@asgard.org wrote: P.S. At this point, the IPv6 transition has failed, unlike the Y2K transition, and For certain values of fail. The odds of a dual-stack transition as initially envisioned by the IETF are vanishingly small, but IPv6 will be a significant part of the coping strategies once RIRs allocate their last blocks of IPv4. it'd be interesting to hear michael's reasoning behind 'transition has failed' (to me at least). I agree it doesn't seem like it's moved along as anyone would (aside from Todd) have hoped, but it is moving along. Currently the only real alternative to ipv6 at the end-user (in ~2yrs) will be giant-CGN-NAT-things or ... that's about it :( I don't think we'll have (nor would we have in 2005 even) gotten an ipv7/8/9/10 up and spec'd/coded/wrung-out before ~2 yrs from now either. So, given the cards we have, ipv6 isn't all bad. -chris
Re: Todd Underwood was a little late
On Mon, Jun 21, 2010 at 3:12 PM, Michael Dillon wavetos...@googlemail.com wrote: I don't think we'll have (nor would we have in 2005 even) gotten an ipv7/8/9/10 up and spec'd/coded/wrung-out before ~2 yrs from now either. So, given the cards we have, ipv6 isn't all bad. On this we agree. The problem is not IPv6, it is the failure to deploy IPv6 soon enough. Not enough trained people, not enough testing, not enough bugs shaken out. ok, that matches pretty much exactly what I see/think. Perhaps the initial wording was just odd :) thanks! -chris
Re: no you can't configure your router w/ this
On Wed, Jun 23, 2010 at 1:45 PM, Warren Kumari war...@kumari.net wrote: On Jun 22, 2010, at 7:07 PM, Adam LaFountain wrote: sigh... where was this useful data 10 years ago! http://www.fcc.gov/worldtravel/ Even more entertaining is the reboot.fcc.gov (Beta) Bah, more like Alpha if you ask me -- I clicked link MULTIPLE times and the FCC didn't reboot -- can I file a bug somewhere? how do you know it wasn't rebooted? Did you see the lights in the building blink?
Re: ATT BGP - Advertising my network on accident
On Fri, Jun 25, 2010 at 10:12 AM, Dennis Burgess dmburg...@linktechs.net wrote: Have you found a contact at ATT to get this stopped? I'm fairly certain JayB at least reads nanog... the OP didn't mention if this was 7018, 7132 or the ATT_ENS AS with the route though :( -Original Message- From: Eric Williams [mailto:ewilli...@connectria.com] Sent: Friday, June 25, 2010 8:56 AM To: nanog@nanog.org Subject: Re: ATT BGP - Advertising my network on accident This issue has been resolved by breaking up the /22 into /24's. Thanks to all for the advise. Maybe next time I will take someone's advise and advertise one of ATT's /8's. From: Eric Williams/Connectria To: nanog@nanog.org Date: 06/24/2010 02:37 PM Subject: ATT BGP - Advertising my network on accident ATT is currently advertising my address space to the internet accidentally via BGP which they should not be. Since they are advertising my address space on accident, we are dead in the water. Does anybody out there work for ATT or know of the number I can call in order to have them stop advertising my /22 ASAP
Re: Broadband initiatives - impact to your network?
On Sun, Jun 27, 2010 at 9:03 AM, Jonathan Feldman j...@feldman.org wrote: I'm one of the reporters who covers broadband and cloud computing for InformationWeek magazine (www.informationweek.com), and it's interesting to me that one of the issues with cloud adoption has to do with the limited pipe networks available in this country. For example, it's not feasible to do a massive data load through the networks that are currently available -- you need to FedEx a hard drive to Amazon. Holy cow, it's SneakerNet for the 21st Century! is this a 'this country' bandwidth problem or the problem that moving 10tb of 'corporate data' in a 'secure fashion' from 'office' to 'cloud' really isn't a simple task? and that cutting a DB over at a point in time 'next tuesday!' is far easier done by shipping a point-in-time copy of the DB via sata-drive than 'holy cow copy this over the corp ds3, while we make sure not to kill it for mail/web/etc other corporate normal uses' ? The broadband plan stuff mostly covers consumers, not enterprises, most of the (amazon as the example here) cloud folks offer disk-delivery options for businesses. you seem to be comparing apples to oranges, no? -chris
Re: Broadband initiatives - impact to your network?
On Mon, Jun 28, 2010 at 6:26 PM, Jonathan Feldman j...@feldman.org wrote: I don't agree with you, Christopher, that the broadband plan won't affect corporate users. I know that this list _mostly_ consists of operators, but (there are a fair number of consumer network operations folks on nanog as well...) There have been plans to offer 'business' connectivity (replacing T1/T3 last-mile type things) from the likes of Verizon (FiOS) for some time. To date you can't (and they don't seem to have plans really) get a last-mile tail on FiOS with BGP for routing information (like for a redundant connection setup, or for alternate provider paths: FiOS 50mbps link from VZ + 45mbps Ds3 from ATT using BGP to manage your redundancy needs). I don't know that you could not do the same on Comcast or Cox's deployments at this time, maybe someone from these alternatives have already spoken up privately on the matter. I've gotten some offline responses to my initial query that seem to indicate that enterprise users utilize SOHO (consumer grade, but with higher speeds) Sure, lots of folks use 'consumer grade' links for out-sites, that dish on top of the Mobil station being the cannonical example. These out-sites don't generally have the data concentration of the main office, nor the bandwidth needs, nor the redundancy/resiliency needs. Using a SOHO/Consumer link in the right place is a fine solution, using it at your core site, not so fine... for various branch office needs. Also, when a technology gets consumerized it tends to create interesting effects in terms of features and price points. Still waiting for that on the FiOS space or the Comcast space (where's my 100mbps cable/FiOS link with BGP for redundancy?). I CAN get a 50mbps bidirectional FiOS link with static ip addresses (that I have to pay for the 'privilege' of having) but I can NOT use my own ip space, nor can I use a routing protocol to tell VZ or the rest of the world to prefer my alternate link to get to my office. That's suboptimal, and not 'business class' service. Think of it this way: where would corporate mobile phones be without the consumer effect? We'd still be carrying them around in bags and only corporate officers would have them. I'm not sure that the corporate smartphone usage was driven by consumers, it seems (to me) to be the other way around actually... I'm not a mobile-maven so who knows :) -Chris I appreciate everyone's response! On Jun 28, 2010, at 5:46 PM, Christopher Morrow wrote: On Sun, Jun 27, 2010 at 9:03 AM, Jonathan Feldman j...@feldman.org wrote: I'm one of the reporters who covers broadband and cloud computing for InformationWeek magazine (www.informationweek.com), and it's interesting to me that one of the issues with cloud adoption has to do with the limited pipe networks available in this country. For example, it's not feasible to do a massive data load through the networks that are currently available -- you need to FedEx a hard drive to Amazon. Holy cow, it's SneakerNet for the 21st Century! is this a 'this country' bandwidth problem or the problem that moving 10tb of 'corporate data' in a 'secure fashion' from 'office' to 'cloud' really isn't a simple task? and that cutting a DB over at a point in time 'next tuesday!' is far easier done by shipping a point-in-time copy of the DB via sata-drive than 'holy cow copy this over the corp ds3, while we make sure not to kill it for mail/web/etc other corporate normal uses' ? The broadband plan stuff mostly covers consumers, not enterprises, most of the (amazon as the example here) cloud folks offer disk-delivery options for businesses. you seem to be comparing apples to oranges, no? -chris
Re: Huawei PTN 910
On Tue, Jun 29, 2010 at 11:29 AM, Uri Joskovitch uri.joskovi...@telrad.com wrote: URGENT !!! I got into trouble with this product, any one has its user manual? Installation guide? , Other documentation? http://lmgtfy.com/?q=Huawei+PTN+910+documentation see like the 5th link down? Thanks Uri
Re: Huawei PTN 910
On Tue, Jun 29, 2010 at 3:18 PM, Jeff Harper jhar...@first-american.net wrote: Lol, you must have way too much time on your hands to make that. ;) I actually couldn't easily think of a quicker way to get the 'see the searchy thingy can find it for you, look at that pdf linked there' :( http://www.secnet.com.ua/pdf/PTN/OptiX%20PTN%20950%20Packet%20Transport%20Platform%20Product%20Brochure.pdf is the 950, the 910 guide was in something Cyrillic (possibly russian) but translate.google offered to xlate it on the fly... http://goo.gl/7jEK -chris Installation guide? , Other documentation? http://lmgtfy.com/?q=Huawei+PTN+910+documentation see like the 5th link down?
Re: Inquiries to Acquire IPs
On Fri, Jul 2, 2010 at 3:22 PM, Oscar Ricardo Silva osi...@scuff.cc.utexas.edu wrote: On 07/02/2010 01:46 PM, Crist Clark wrote: We got a strange and out of the blue inquiry from someone wishing to pay us for a chunk of our ARIN allocation, Hello, According to Whois data, you company owns the following IP address space: 206.220.220.0/24 We would like to get this block of IP addresses for our business needs. Is it possible to assign this block for our company with PI (Provider Independent) or PA (Provider Assigned) status? We ready to pay about $5,000 for the net block itself and all related procedures. Would you be interested in such an offer? The amount of compensation is subject to negotiation. We're not interested, mostly because we use our allocation, but also because I think this is not allowed by our agreement with ARIN. Seems a bit fishy. I should add the sender identified himself and his company clearly. It wasn't from some free mail account. (Although it could of course be spoofed.) Is this a new thing? IP speculation as we come upon free pool depletion? A front for spammers? Yeah, we received the same kind of offer here. Here's the message in full: ** Hello, According to Whois data, you company owns the following IP address space: 146.6.6.0/24 We would like to get this block of IP addresses for our business needs. Is it possible to assign this block for our company with PI (Provider Independent) or PA (Provider Assigned) status? We ready to pay about $5,000 for the net block itself and all related procedures. Would you be interested in such an offer? The amount of compensation is subject to negotiation. -- Kind regards, Sergey Gotsulyak http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2010/msg00038.html http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2010/msg00039.html Ideco Sales Team 280 Madison Ave, Suite 912 New York, NY 10016 Phone: (800) 715-3502 Email: g...@idecogateway.com Web: www.idecogateway.com ** Oscar
Re: PCH.net down?
On Wed, Jul 21, 2010 at 11:13 AM, Allen Bass allen_b...@comcast.net wrote: I received the same message from http://downforeveryoneorjustme.com/pch.net but if I go to the site directly from Miami it pulls up, but is slow to do everyone should take careful note... downforeveryoneorjustme.com lives ... on appeng...@google, so 'downforeveryoneorjustme' really just tests if google's network has a path to it.
Re: vpn exchange point
coughequinix ethernet exchange/cough On Wed, Jul 21, 2010 at 10:59 PM, Marshall Eubanks t...@americafree.tv wrote: On Jul 21, 2010, at 5:43 PM, Bill Woodcock wrote: On Jul 21, 2010, at 12:59 PM, William McCall wrote: OP is referencing MPLS/BGP VPNs, not like IPsec VPNs. And I'm not sure that I've (personally) ever heard of an IXP for MPLS. Isn't that what one iteration of IXP-NSP in Japan was? I seem to recall that they talked about it a lot, back when MPLS was still trendy, but I haven't heard word one about it for many years since. The TelX Video Exchange http://www.telx.com/Products-Services/telx-video-exchange.html is supposed to be a MPLS to MPLS exchange with some tailoring for H.323 (and maybe SIP/RTP) video transport. Regards -Bill
Re: PCH.net down?
On Thu, Jul 22, 2010 at 2:52 AM, Simon Horman ho...@verge.net.au wrote: Thats quite a revelation. I assumed it tested from all points of the internet other than mine :^) I suspect it simple does an equivalent of 'wget' of the hostname you enter... the appengine api doesn't really permit much more than http/s out I think :( of course it COULD run that wget to some external service that queries from 100k other points of light, but really... I bet it's just doing it to the hostname you enter. -chris
Re: vpn exchange point
On Thu, Jul 22, 2010 at 3:46 PM, Michael Dillon wavetos...@googlemail.com wrote: Do you know of any vpn exchange point implementations please? -I mean something like IXP but for mpls vpns Let's say I'm an ISP that bought or merged with many small ISPs each with it's own AS# and would like to start offering mpls vpn services end to end In the MPLS world, this type of interconnect is called NNI (Network to Network Interconnect) hey look frame-relay! (joking, sorta, not really) In almost all cases this is still done via the A version (or 1 version of 4) mpls interconnect types where each customer VPN is broken down to native-IP links (vlans most often I believe, sometimes frame dlcis! :)) and the contracted cos/qos setup is replicated on the adjacent provider's interface as well... as you (michael) pointed out though, it's pretty much only done for 'i dont want to build in XXX' places. Additionally, from my (admittedly limited involvement) understanding these sorts of connections are notoriously problematic, painful and ultimately expensive for the provider(s) in question :( boo. and it needs to take into account things like COS mappings. I don't know of anyone doing this as an exchange, But I imagine that if you had a router with a private ASN, you could always do NNI with a different ASN on each port and therefore, achieve something analogous to an IXP. the real question is why? what's the business driver? what's the support model? is it truly worthwhile? -chris
Re: IPv4 Exhaustion...
On Sat, Jul 24, 2010 at 4:48 AM, Owen DeLong o...@delong.com wrote: Rough translation: LSN + CALEA = Very Interesting Times for ISPs that deploy LSN and are subject to CALEA. why wouldn't you just do the intercept before the LSN? (also, calea and it's ilk knew this was coming, 'your failure to plan...' and all that jazz)
Re: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care?
isn't ipv3@gmail.com jim fleming? http://www.ietf.org/mail-archive/web/ietf/current/msg04279.html (for reference) pls to not be replying to the list when ipv3.com posts to nanog.. -Chris On Sat, Jul 24, 2010 at 4:17 PM, William Pitcock neno...@systeminplace.net wrote: On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote: I am very curious to see how this would play with networks that wouldn't support such a technology. How would you ensure communication between a network that supported 33-Bit addressing and one that doesn't? 33-bit is a fucking retarded choice for any addressing scheme as it's neither byte nor nibble-aligned. Infact, the 33rd bit would ensure that an IPv4 header had to have 5 byte addresses. William
Re: IPv4 Exhaustion...
On Sat, Jul 24, 2010 at 4:28 PM, valdis.kletni...@vt.edu wrote: On Sat, 24 Jul 2010 15:40:58 EDT, Christopher Morrow said: why wouldn't you just do the intercept before the LSN? That gets interesting too, when several tens of thousands of users may all be behind the same LSN. Making sure you intercept only the right user's traffic gets a lot more interesting in front of the LSN. Doing it behind the LSN means you can snarf up just the traffic heading to/from one NAT'ed IP, which is hopefully changing not all that often. Doing it in front of the LSN means you need to decide whether to capture the data in real time on a per-flow basis (consider the fun involved in catching a SYN packet outbound - what's your time budget between when the miscreant's packet leaves his host and when you have to catch it on the outbound side of the LSN)... innocent until proven guilty... plus probably a large portion of the calea things aren't for a 'miscreant' anyway but for other reasons. say, i wonder how many actual calea requests have been sent out anyway?? (I know one very large network has yet to get a single one, or so the grape vine tells me.)
Re: Question of privacy with reassigned resources
On Tue, Aug 3, 2010 at 7:40 PM, todd glassey tglas...@earthlink.net wrote: On 8/3/2010 4:07 PM, ML wrote: As an SP in the MDU (multi dwelling unit) market we dutifully SWIP netblocks for each apartment complex/condo/etc. Doing such we publically publish the physical address an IP lives (sans Apt/Unit #). Would anyone feel this is too much information for people to know? Should our SWIPs be more generic, local POP address or local corporate office, just enough for rough geolocation accuracy? I realize what ARIN prefers, this is more of an opinion gathering. -ML CALEA may come into play there meaning that there is no privacy per se. calea != ARIN policies... the above comment is a red-herring/fud. reading the policies (roughly paraphrased) I'd say you need to (depending where you line up with william's questions) A swip the block the building uses (postal address probably fine) - presumes +/29 to a building, of course B swip as 'residential' anything larger than a /29 that lands at a single dwelling being used for residential things C swip as a normal record anything larger than a /29 that lands at a single dwelling but considered a 'business' as examples of these: A - 1515 Connecticut Ave, Washington DC - The Regency Towers Apartments (fictitious apartment building) B - Private customer - Verizon Internet Services Inc. FTTP (Joe Plumber Apartment #5 inside The Regency Towers Apartments) C - Joes Plumbing and Handyman services - Apt #5 1515 Connecticut Ave (the business address at that apartment location) -chris
Re: Proxy Server
squid? On Thu, Aug 5, 2010 at 2:45 PM, Joshua William Klubi joshua.kl...@gmail.com wrote: Hi, Is there any one with an idea of an open source packeteer or bandwidth management solution like Allot NetEnforcer Bandwidth Management Appliance. Which can do proxy services and also allocate bandwidth to certain websites and staff, prevent them from viewing certain websites We currently have Microsoft TMG 2010 with GFI Web monitor 2009 installed on it, we are looking for a solution possible from open source.Which can replace it. I actually want it as a proxy server and use it to shape, allocate and restrict access to certain websites of our staff. Joshua (Ghana)
Re: off-topic: historical query concerning the Internet bubble
On Thu, Aug 5, 2010 at 6:27 PM, Dorian Kim dor...@blackrose.org wrote: Was Mike O'Dell's famous doubling every 100 days just a myth? Like any good tale, there most likely was an element of truth behind it. I think, from another list about 2 yrs ago, the person responsible for this data inside the company at the time (now not there) said someone misinterpreted his stats/numbers... -chris
Re: Google wants your Internet to be faster
On Mon, Aug 9, 2010 at 3:18 PM, Zaid Ali z...@zaidali.com wrote: The devil is always in the details. The Network management piece is quite glossed over and gives a different perception in the summary. You can't perform the proposed network management piece without deep packet inspection which violates every users privacy. how is that though? you COULD do something odd like say: Anything to zaid-ali's netblocks is preferred in queues over things to jolymacfie's netblocks. that wouldn't require any DPI at all, just a traffic classification engine on/near the endpoint, say like on the DocSIS modem, or on the handset itself... many handsets are unix-ish things with some ability to do 'firewall' things, certainly they could mark packets outbound, certainly at peering points a network could classify in simple ways and mark packets properly there as well. nothing required DPI, unless you want to delve into: That is not ssh on port 22 port 443 is the new port 80! woot! -chris
Re: (cisco, or any) acl *reducers* out there?
On Wed, Aug 18, 2010 at 8:47 PM, Dobbins, Roland rdobb...@arbor.net wrote: On Aug 19, 2010, at 7:38 AM, George Michaelson wrote: (we've got the usual acquisition of rule by accretion problem across 4 edge/core routers with a mix of public facing, internal, WiFi, guest rules, and I hate to think this is either start from scratch, or intractable. The evidence is that its FRAGILE) Attempts by various commercial solutions aside, there isn't really a workable, usable, scalable and reliable automated way to do this, AFAIK; apart from the complexity of the task itself, platform-specific ACL handling complicates matters further. To begin getting a handle on your ACLs, implement some form of revision control (RCS, CVS, subversion, whatever), and then work to modularize the ACLs by function: https://files.me.com/roland.dobbins/prguob Then take a look at whether the ACLs in question all actually belong on the edge, or whether it makes sense to break them out and instantiate the relevant policies at various points within the topology. a plug for some google-peeps: http://code.google.com/p/capirca/ potentially once you make the definitions/policy-files you can use the proto-language to sort through your mess in a saner fashion. a nice aside is you can also create (from the same policy file) cisco/juniper/iptables configurations. (tony/pete really did a nice job on this) -chris --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: (cisco, or any) acl *reducers* out there?
On Thu, Aug 19, 2010 at 11:55 AM, Cat Okita c...@reptiles.org wrote: On Thu, 19 Aug 2010, George Michaelson wrote: I have been looking at acl management s/w in the freecode space and I can find lots of tools which manage/distribute and test ACLs in routers. I'm wondering if anyone has written a parser which can construct rule-trees and get rid of the cruft, unusable, order-misorder and other issues in a large ACL pool? Something similar to this? http://www.hpl.hp.com/techreports/2008/HPL-2008-111.pdf this paper, while full of math and graphs and sh*t, doesn't make my acl management simpler, clearer or more complete... I keep trying to push my acls through the paper, no joy yet. there's code or something somewhere that implements the algorithms and graphs and sh*t that the paper shows in a pretty fashion? -Chris (btw, you owe me some neosporin to take care of all the paper cuts)
Re: (cisco, or any) acl *reducers* out there?
On Thu, Aug 19, 2010 at 2:18 PM, Cat Okita c...@reptiles.org wrote: On Thu, 19 Aug 2010, Christopher Morrow wrote: this paper, while full of math and graphs and sh*t, doesn't make my acl management simpler, clearer or more complete... I keep trying to push my acls through the paper, no joy yet. there's code or something somewhere that implements the algorithms and graphs and sh*t that the paper shows in a pretty fashion? Heh. Of course there's code associated with it -- how else would we have managed to come up with numbers from practical application :P oh! I thought perhaps on them fancy HP 37 calculators? Seriously though, in a brief read I saw it talking about checkpoint firewall policy stuff... does the code include compiling to meta-state the policy? does it handle policy from things other than checkpoint? (like juniper router firewall syntax and pix and cisco acls?) OTOH, without some idea of whether it's what he had in mind, it's pointless to push the battle to go anywhere with it. There are certainly some commercial products that do what he seemed to be asking about, as well -- but I'm failing to find references to them just now (nothing like illness and deadlines). (btw, you owe me some neosporin to take care of all the paper cuts) I've got some lovely iodine... :P excellent! I love purple skin! -chris cheers! == A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now.
Should routers send redirects by default?
Polling a little bit here, there's an active discussion going on 6...@ietf about whether or not v6 routers should: o be required to implement ip redirect functions (icmpv6 redirect) o be sending these by default Essentially 12+ years ago in RFC2461 (http://www.ietf.org/rfc/rfc2461.txt) and later in RFC4861 (http://tools.ietf.org/html/rfc4861) there are a set of message types defined and use cases discussed which seem to lead to the idea that: routers should be reqiured to implement redirect logic/functionality routers should by default be enabled to send these redirect messages. In ipv4 there's a relatively widely used practice of disabling ip redirects. secure router and secure host templates disable this functionality, and have for quite some time. There are a host of reasons for this I don't really want to debate them though :) It would be instructive to get a sense of how many folks do NOT disable this sort of thing, or how many folks RELY on these functions working in their network build today. For the 6man discussion though, I presume that in ipv4 we take a set of configs/actions because of somewhat sane reasons, I suspect we would want to have the same config/end-state in v6? One proposal is to do this with: o routers are required to be able to send redirect messages o routers should NOT do this by default With the proviso that some consenting adults may choose to enable by default on certain platforms (cabl/dsl CPE, enterprise-LAN)... if that muddies the waters it'd be nice to just hear about the proposal there and leave the hinkiness of the rest out of the picture :) I hope that folks who currently run v6 network(s) might respond, there are quite a few v6 operators here... I'm looking at you owen/jjb/au-dsl-folk... :) thanks for your time, of couse if you want to chat more directly about this the 6man list is open and at: http://www.ietf.org/mail-archive/web/ipv6/current/maillist.html -Chris
Re: Should routers send redirects by default?
On Fri, Aug 20, 2010 at 4:10 PM, Owen DeLong o...@delong.com wrote: Redirects in IPv6 are no worse nor better an idea than unauthenticated RAs for default routers with nearly identical security implications. this answered a different question... wanna try answering the question I posed originally? :) -chris Owen Sent from my iPad On Aug 20, 2010, at 10:20 AM, Christopher Morrow christopher.mor...@gmail.com wrote: Polling a little bit here, there's an active discussion going on 6...@ietf about whether or not v6 routers should: o be required to implement ip redirect functions (icmpv6 redirect) o be sending these by default Essentially 12+ years ago in RFC2461 (http://www.ietf.org/rfc/rfc2461.txt) and later in RFC4861 (http://tools.ietf.org/html/rfc4861) there are a set of message types defined and use cases discussed which seem to lead to the idea that: routers should be reqiured to implement redirect logic/functionality routers should by default be enabled to send these redirect messages. In ipv4 there's a relatively widely used practice of disabling ip redirects. secure router and secure host templates disable this functionality, and have for quite some time. There are a host of reasons for this I don't really want to debate them though :) It would be instructive to get a sense of how many folks do NOT disable this sort of thing, or how many folks RELY on these functions working in their network build today. For the 6man discussion though, I presume that in ipv4 we take a set of configs/actions because of somewhat sane reasons, I suspect we would want to have the same config/end-state in v6? One proposal is to do this with: o routers are required to be able to send redirect messages o routers should NOT do this by default With the proviso that some consenting adults may choose to enable by default on certain platforms (cabl/dsl CPE, enterprise-LAN)... if that muddies the waters it'd be nice to just hear about the proposal there and leave the hinkiness of the rest out of the picture :) I hope that folks who currently run v6 network(s) might respond, there are quite a few v6 operators here... I'm looking at you owen/jjb/au-dsl-folk... :) thanks for your time, of couse if you want to chat more directly about this the 6man list is open and at: http://www.ietf.org/mail-archive/web/ipv6/current/maillist.html -Chris
Re: Should routers send redirects by default?
On Fri, Aug 20, 2010 at 4:03 PM, Jared Mauch ja...@puck.nether.net wrote: On Aug 20, 2010, at 3:56 PM, Butch Evans wrote: On Fri, 2010-08-20 at 13:20 -0400, Christopher Morrow wrote: Polling a little bit here, there's an active discussion going on 6...@ietf about whether or not v6 routers should: o be required to implement ip redirect functions (icmpv6 redirect) o be sending these by default I do not currently have an IPv6 deployment, so my input may be lacking in real usefulness here. With IPv4, however, I have been a little irritated at a few situations where I NEEDED this to work and it did not (certain PIX routers come to mind here). There are risks involved with ANY automated type traffic to be sure, but for my money, it SHOULD be possible to configure every router to support the network needs. So for my money, I'd suggest: * routers MUST support ip redirect * default configurations irrelevant to me I do agree with one or two of the other posters that it should not be within the purview of the IETF to mandate these defaults. Each of us will learn the defaults of the particular gear we use and can adjust config templates to match, given the needs of the network we are deploying. Just my $0.02 (may be worth less than that) :-) One of the challenges is that some vendors have a poor track-record of documenting these defaults. this means unless you frequently sample and changing them... so, picking a good default I think is important. You'd prefer less config headaches I bet vs having to constantly hack templates? your network traffic, you may not see your device sending decnet mop messages, or ipv6 redirects :) Personally (and as the instigator in the ipv6/6man discussion) if the yes thanks! :) (just following a path as requested by another 6man person) vendors could be trusted to expose their default settings in their configs, i would find a default of ON to be more acceptable. As their track-record is poor, and the harm has been realized in the network we operate (at least), I am advocating that as a matter of policy enabling redirects not be a default-on policy. If people want to hang themselves that's their problem, but at least they won't come with a hidden noose around their neck. yes, that was my point as well. -chris - Jared
Re: Should routers send redirects by default?
On Fri, Aug 20, 2010 at 1:40 PM, Mikael Abrahamsson swm...@swm.pp.se wrote: On Fri, 20 Aug 2010, Jack Bates wrote: Why should the ietf dictate a default on this? Because that's what the IETF does, sets a SHOULD on best common practice after discussion in the community. Requiring implementation I could understand, but setting the default? Should the ietf also specify requirement of allowing configuration change of a default? I'd say by definition it's meaningless of talking about a default that can't be changed. As I stated in the 6man discussion, I prefer routers to by default not send redirects. We do that in our configuration template. as always, thanks! :) I am hoping we all don't have to continue to hack templates, if the option is sane to begin with and is documented in the code/config/docs by the vendor(s). -Chris
Re: Should routers send redirects by default?
I appreciate the discussion.. Eric, are you reflecting messages back to the list without additional content for a reason? list-admin folks, could we ping eric and see what's busted? On Fri, Aug 20, 2010 at 9:08 PM, Eric J. Katanich e...@onyxlight.net wrote: On 08/21/2010 02:08 AM, Brandon Ross wrote: On Fri, 20 Aug 2010, Ricky Beam wrote: I think it's almost universally disabled (by default) everywhere in IPv4 purely for security (traffic interception.) Okay, I'll ask again. Exactly how does disabling ICMP redirects on my router prevent traffic from being intercepted? As was mentioned in an other part of the thread. You disable it on the host and if no host is using it, you might as well disable it on the router as wel. Others mentioned some routers need to handle this in software instead of hardware, which is obviously slower. It might also help you notice you have a roque host when you are looking at your network-traffic and if you know your network doesn't have any ICMP-redirects normally. disabling on the host: OpenBSD: echo net.inet.icmp.rediraccept=0 /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 /etc/sysctl.conf sysctl net.inet.icmp.rediraccept=0 sysctl net.inet6.icmp6.rediraccept=0 FreeBSD: echo net.inet.icmp.drop_redirect=0 /etc/sysctl.conf echo net.inet6.icmp6.rediraccept=0 /etc/sysctl.conf sysctl net.inet.icmp.drop_redirect=0 sysctl net.inet6.icmp6.rediraccept=0 Linux: echo net.ipv4.conf.all.accept_redirects = 0 /etc/sysctl.conf echo net.ipv4.conf.all.send_redirects = 0 /etc/sysctl.conf sysctl -p /etc/sysctl.conf
Re: Should routers send redirects by default?
On Tue, Aug 24, 2010 at 4:32 PM, William Herrin b...@herrin.us wrote: On Fri, Aug 20, 2010 at 1:20 PM, Christopher Morrow christopher.mor...@gmail.com wrote: Polling a little bit here, there's an active discussion going on 6...@ietf about whether or not v6 routers should: o be required to implement ip redirect functions (icmpv6 redirect) o be sending these by default Hi Chris, If you don't mind, I'd like to ask a similar question whose answers might be instructive for the question you asked: sure :) (other folks should also chime in, or I thought that was the spirit of your question...) Forgetting all of the theoretical constructs for a moment, has anyone here personally encountered an operational scenario in which ICMP redirects solved a problem for you that you would otherwise have found difficult or intransigent? Without naming names, would you describe the scenario's details, explain the problem that would have existed absent redirects and explain how redirects solved it for you? I've never had redirects solve a problem for me.
Re: Did your BGP crash today?
On Fri, Aug 27, 2010 at 4:07 PM, Mike Gatti ekim.it...@gmail.com wrote: where's the change management process in all of this. basically now we are going to starting changing things that can potentially have an adverse affect on users without letting anyone know before hand Interesting concept. you are running bgp, you are connected to the 'internet'... congrats you are part of the experiment. I suppose one view is that at least it wasn't someone with ill intent, or a misconfigured mikrotek! (you are asking your vendors to run full bit sweeps of each protocol in a regimented manner checking for all possible edge cases and properly handling them, right?) -chris On Aug 27, 2010, at 3:33 PM, Dave Israel wrote: On 8/27/2010 3:22 PM, Jared Mauch wrote: When you are processing something, it's sometimes hard to tell if something just was mis-parsed (as I think the case is here with the missing-2-bytes) vs just getting garbage. Perhaps there should be some way to re-sync when you are having this problem, or a parallel keepalive path similar to MACA/MCAS/MIDCAS/TCAS between the devices to talk when something bad is happening. I know it wasn't there originally, and isn't mandatory now, but there is an MD5 hash that can be added to the packet. If the TCP hash checks out, then you know the packet wasn't garbled, and just contained information you didn't grok. That seems like enough evidence to be able to shrug and toss the packet without dropping the session. -Dave =+=+=+=+=+=+=+=+=+=+=+=+= Mike Gatti ekim.it...@gmail.com =+=+=+=+=+=+=+=+=+=+=+=+=
Re: Did your BGP crash today?
On Sat, Aug 28, 2010 at 6:14 AM, Florian Weimer f...@deneb.enyo.de wrote: * Christopher Morrow: (you are asking your vendors to run full bit sweeps of each protocol in a regimented manner checking for all possible edge cases and properly handling them, right?) The real issue is that both spec and current practice say you need to drop the session as soon as you encounter any unexpected data. That's sorry, I conflated two things... or didn't mean to but did anyway. 1) users of gear that does BGP really need to ask loudly and longly (and then go test for themselves) that their BGP speakers do the 'right thing' when faced with oddball scenarios. If someone sends you a previously unknown attribute... don't corrupt it and pass it on, pass if transitive, drop if not. 2) some thought and writing and code-changes need to go into how the bgp-speakers of the world deal with bad-behaving bgp speakers. Is 'send notify and reset' the right answer? is there one 'right answer' ? Should some classes of fugly exchange end with a 'dropped that update, moved along' and some end with 'pull eject handle!' ? it's doubtful that 2 can get solved here (nanog, though certainly some operational thought on the right thing would be great as guidance). i would hope that 1 can get some traction here (via folks going back to their vendors and asking: Did you run the Mu-security/Oolu-univ/etc fuzzing test suites against this code? can I see the results? I hope they match the results I'm going to be getting from my folks in ~2wks... or we'll be having a much more structured/loud conversation... another poster had a great point about 'all the world can screw with you, you have no protections other than trust that the next guy won't screw you over (inadvertently)'. There are no protections available to you if someone sets (example) bit 77 in an ipv4 update message to 1 when it should by all accounts be 0. Or (apparently) if they send a previously unknown attribute on a route :( You can put in max-prefix limits, as-path limits (length and content), prefix-filters.. but internal-message-content you are stuck hoping the vendors all followed the same playbook. With everyone saying together: Please appropriately test your implementation for all boundary cases maybe we can get to where these happen less often (or nearly never) - every 3 months is a little tedious. -chris
Re: largest OSPF core
On Thu, Sep 2, 2010 at 2:37 PM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Thu, Sep 02, 2010 at 03:20:05PM +0300, lorddoskias wrote: I'm just curious - what is the largest OSPF core (in terms of number of routers) out there? I'll admit to having seen a network with over 400 devices in an OSPF area 0, didn't design it, and in the end didn't get to work on it. I know of a large enterprise with ~4k devices in area-0, according to their vendor^H^H^H^H^Hdesigner that was all perfectly fine. Far as I know worked just fine though, no issues reported. How well your IGP scales depends a lot more on what you put in it, and how dynamic your network situation is than the protocol or number of devices. I think the only reason the one I saw worked at all was it was relatively stable. If things happened though (like say the code-red incident in ... whenever that was) the network turned into a steaming pile of fail. really, not a good plan, of course as Leo says ISIS probably gets super unhappy if a large percent of interfaces start to go bouncey-bouncey. -Chris
Re: verizon outage
On Fri, Sep 3, 2010 at 12:51 PM, James Jones ja...@freedomnet.co.nz wrote: anyone experiencing issues with verizon in western mass? o this isn't the outages list, that one MAY have more info for you o there are many verizons... which one are you talking about? (wireless, dsl/fios, fUUNET, private-line services, private-network services...) -Chris
Re: IPv6 Glue Records at Dotster / Domain.com
On Sat, Sep 4, 2010 at 2:59 PM, Ryan Shea ryans...@google.com wrote: Righto, perhaps it's not kooky. Despite the admittedly small demand, it just seems such a trivial feature to have to jump through administrative hoops of swapping registrars for. I'll do what I need to do, but of course if there is a way to make the magic happen without the pain that is great :) honestly I had thought this came up before (wrt dotster) and someone mentioned after their ordeal that some jiggery-pokery with the techsupport folks got it 'fixed'?? This problem did involve some long phone conversation where you have to reboot your 'windows only' machine a few times to be sure though, of course... -chris -Ryan On Sat, Sep 4, 2010 at 1:55 PM, Seth Mattinen se...@rollernet.us wrote: On 9/4/10 6:35 AM, Ryan Shea wrote: Anyone with a contact at Doster with the ability to make things happen? Apparently they do not support v6 glue records and they have been unresponsive to my ticket. This seems a kooky reason to change registrars. The table of registrars over at sixxs who have at least some way to get v6 glue records has been getting greener and greener, but no love from Dotster. http://www.sixxs.net/faq/dns/?faq=ipv6glue It's not kooky at all. If you need a service your current provider can't/won't provide, then find a new one that will. ~Seth
Re: IPv4 squatters on the move again?
On Tue, Sep 7, 2010 at 10:03 AM, Jon Lewis jle...@lewis.org wrote: On Tue, 7 Sep 2010, Jeffrey Lyon wrote: We see this all the time, usually it involves either a /20 or multiple-/xx that change every month. If they want frequently changing IPs, it's almost certainly for spamming. I got the impression with these people they were just trying to get a bunch of SWIPs in order to go to ARIN and request as big a block of ipv4 as they could get with the intent to chop it up and resell it in pieces as soon as ARIN runs out of IPs to satisfy normal requests. it used to be (~4-5 years ago) that the spammer code of 'voip service provider' was really 'we intend on raping proxies all over the planet' ... when you call them out on the random port traffic out of their pipe they point at their 'business' model that this is 'voip traffic, you know that rtp uses random ports, right?' I used to have some quick/dirty instructions for how to verify that the traffic was in fact proxy traffic, something like: 1) log traffic from the soon-to-be-ex-customer (acl logs are fine) 2) pick an external 'top talker' 3) route that /32 to a host you control 4) run NC on the port that /32 is being contacted on 5) rejoice (and shut now ex-customer interface) when you see: CONNECT smtp.x:25 from the connection... -Chris
Re: IPv4 squatters on the move again?
On Tue, Sep 7, 2010 at 10:35 AM, Jon Lewis jle...@lewis.org wrote: On Tue, 7 Sep 2010, Christopher Morrow wrote: I used to have some quick/dirty instructions for how to verify that the traffic was in fact proxy traffic, something like: 1) log traffic from the soon-to-be-ex-customer (acl logs are fine) 2) pick an external 'top talker' 3) route that /32 to a host you control 4) run NC on the port that /32 is being contacted on 5) rejoice (and shut now ex-customer interface) when you see: CONNECT smtp.x:25 Seems like a lot of work when you could just setup a monitor session on their port and capture a few minutes of actual spam traffic as evidence just before shutting their port. sorry, can't do monitor on a ptp oc-12 link :(
Reverse traceroute and spoofing of sources of packets?
I missed this meeting/preso when it happened (yes, 5+ meetings ago) http://www.nanog.org/meetings/nanog45/abstracts.php?pt=MTE4OCZuYW5vZzQ1nm=nanog45 I note the talks about using spoofed source packets to do some measurement, I didn't see anyone in the video say: But spoofing is bad, but you want YOU to be able to do this? what? isn't that a little hypocritical? Isn't it? and why would someone (an isp) disable BCP38 for this sort of activity? -Chris
Re: Convenience or slippery slope... or something else?
On Fri, Sep 10, 2010 at 1:05 PM, Reese re...@inkworkswell.com wrote: A friend brought this to my attention: http://ipq.co/ as an aside: https://www.nic.co/ note the cert in used for the NIC's website... surely the .CO ccTLD could use a real cert? -chris
Re: Convenience or slippery slope... or something else?
On Sat, Sep 11, 2010 at 11:39 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Sep 10, 2010 at 1:05 PM, Reese re...@inkworkswell.com wrote: A friend brought this to my attention: http://ipq.co/ as an aside: https://www.nic.co/ note the cert in used for the NIC's website... surely the .CO ccTLD could use a real cert? also it's not clear that the ipq.co service is really all that robust (if that'd matter to anyone) since ipq.co's nameservers: ;; QUESTION SECTION: ;ipq.co.IN NS ;; AUTHORITY SECTION: ipq.co. 900 IN NS A.NS.ipq.co. ipq.co. 900 IN NS B.NS.ipq.co. ;; ADDITIONAL SECTION: A.NS.ipq.co.900 IN A 212.110.169.105 B.NS.ipq.co.900 IN A 212.110.169.105 are the same host/ip.
Re: US hunters shoot down Google fibre
this was presented at the nanog in ... SF I think as well: http://www.nanog.org/meetings/nanog49/abstracts.php?pt=MTU5NSZuYW5vZzQ5nm=nanog49 not really news... On Tue, Sep 21, 2010 at 6:04 AM, Eugen Leitl eu...@leitl.org wrote: http://www.itnews.com.au/News/232831,us-hunters-shoot-down-google-fibre.aspx Repairers forced to ski in to Oregon back woods. Google has revealed that aerial fibre links to its data centre in Oregon were regularly shot down by hunters, forcing the company to put its cables underground. The search and advertising giant's network engineering manager Vijay Gill told the AusNOG conference in Sydney last week that people were trying to hit insulators on electricity distribution poles. The poles also hosted aerially-deployed fibre connected to Google's $US600 million ($A635 million) data centre in the Dalles, a small city on the Columbia River in the US state of Oregon. What people do for sport or because they're bored, they try to shoot at the insulators, Gill said. I have yet to see them actually hit the insulator, but they regularly shoot down the fibre. Every November when hunting season starts invariably we know that the fibre will be shot down, so much so that we are now building an underground path [for it]. Gill said that on one occasion, a snowstorm and avalanche prevented Google from transporting repairers and gear into the area of the cut. It usually used a helicopter or a Caterpillar D9 tractor for transport. It improvised by sending three technicians on skis to repair the fibre that got shot down. These guys had to cross country ski for three days, Gill said. [One guy] is carrying what is known as a fusion splicing kit on his backpack. He joked: These guys had to go in and fix the fibre while facing gunshots So [the] internet... [it's] more dangerous than you realise.
Re: FW: Odd BGP AS Path
On Wed, Sep 22, 2010 at 12:42 PM, Chris Hall chris.hall.l...@highwayman.com wrote: And what about the truly, madly, deeply useless AS_CONFED_SET ? [A carbuncle's carbuncle if ever I saw one.] AS_CONFED_SET is included in the next version of this draft...
Re: Routers in Data Centers
On Sun, Sep 26, 2010 at 11:02 PM, Heath Jones hj1...@gmail.com wrote: But it seems, that NetFPGA has not enough memory to hold a full view (current 340k routes). It's just a development platform for prototyping designs, not something you would use in production... I want to use it to implement and test ideas that I have, and play with some different forwarding architectures, not use it as a final product :) also, does a datacenter router/switch need a full table? isn't that the job of the peering/transit routers in your scheme?
Re: Using crypto auth for detecting corrupted IGP packets?
On Thu, Sep 30, 2010 at 11:34 PM, Manav Bhatia manavbha...@gmail.com wrote: I would be interested in knowing if operators use the cryptographic authentication for detecting the errors that i just described above. yes.
Re: AS11296 -- Hijacked?
On Fri, Oct 1, 2010 at 8:00 AM, Rich Kulawiec r...@gsp.org 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...
Re: ARIN Fraud Reporting Form ... Don't waste your time
On Fri, Oct 1, 2010 at 9:07 AM, bmann...@vacation.karoshi.com 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 - baitsushi (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
Re: Verifying route origins and ownership (Was: ARIN Fraud Reporting Form ... Don't waste your time)
On Fri, Oct 1, 2010 at 11:12 AM, Jeroen Massar jer...@unfix.org 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
Re: Using crypto auth for detecting corrupted IGP packets?
On Fri, Oct 1, 2010 at 7:26 AM, Jared Mauch ja...@puck.nether.net 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?
Re: AS11296 -- Hijacked?
On Fri, Oct 1, 2010 at 5:12 PM, George Bonser gbon...@seven.com 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
Re: ILNP and DNS (from 2010.10.04 NANOG50 day 1 morning notes)
On Tue, Oct 5, 2010 at 12:18 PM, Tony Finch d...@dotat.at 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 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 rfc which shows steps and timing to migrate an NS device/pair/set from network attachment point to network attachment point. -chris
Re: AS6517 - Reliance Globalcom -- routing three more hijacked blocks
On Thu, Oct 7, 2010 at 10:09 AM, Heath Jones hj1...@gmail.com 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.
Re: Equinix MPLS connectivity
On Sat, Oct 9, 2010 at 4:22 AM, Leo Woltz leo.wo...@gmail.com 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)
Re: Equinix MPLS connectivity
On Sat, Oct 9, 2010 at 10:39 AM, Brandon Kim brandon@brandontek.com 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.li...@gmail.com To: leo.wo...@gmail.com CC: nanog@nanog.org On Sat, Oct 9, 2010 at 4:22 AM, Leo Woltz leo.wo...@gmail.com 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)
Re: Equinix MPLS connectivity
On Sun, Oct 10, 2010 at 12:38 AM, Seth Mattinen se...@rollernet.us 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
Re: Internet in DPRK / North Korea
On Sun, Oct 10, 2010 at 8:38 PM, John R. Levine jo...@iecc.com wrote: 175.45.179.68/ once senses that the potential successor wants his twitters and facebooks...
Re: Internet in DPRK / North Korea
On Sun, Oct 10, 2010 at 8:56 PM, Christopher Morrow morrowc.li...@gmail.com wrote: On Sun, Oct 10, 2010 at 8:38 PM, John R. Levine jo...@iecc.com 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)
Re: Internet in DPRK / North Korea
On Sun, Oct 10, 2010 at 8:57 PM, jim deleskie deles...@gmail.com 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 morrowc.li...@gmail.com wrote: On Sun, Oct 10, 2010 at 8:38 PM, John R. Levine jo...@iecc.com wrote: 175.45.179.68/ once senses that the potential successor wants his twitters and facebooks...
Re: ARIN recognizes Interop for return of more than 99% of 45/8 address block
On Wed, Oct 20, 2010 at 10:43 AM, Nick Hilliard n...@foobar.org 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.
Re: ARIN recognizes Interop for return of more than 99% of 45/8 address block
On Wed, Oct 20, 2010 at 11:11 AM, Joel Esler joel.es...@me.com 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.
Re: ARIN recognizes Interop for return of more than 99% of 45/8 address block
On Wed, Oct 20, 2010 at 11:28 AM, John Curran jcur...@arin.net 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.
Re: data center locations - recommendation's
On Thu, Oct 21, 2010 at 12:16 AM, Santino Codispoti santino.codisp...@gmail.com 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
Re: IPv4 sunset date revised : 2009-02-05
(bill is a tease) On Thu, Oct 21, 2010 at 11:48 PM, bmann...@vacation.karoshi.com wrote: On Fri, Oct 22, 2010 at 11:40:29AM +0800, Adrian Chadd wrote: On Fri, Oct 22, 2010, bmann...@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 v4 from upstream #ifconfig eth0 v6 fm RIR #ifconfig eth1 ULA #ivi eth0 eth1 neat! I can install that on my ubuntu machine! http://packages.ubuntu.com/dapper/electronics/ivi 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
Re: DHS and NSA getting married?
On Fri, Oct 22, 2010 at 1:46 AM, George Bonser gbon...@seven.com 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
Re: DHS and NSA getting married?
On Fri, Oct 22, 2010 at 11:08 AM, Steven Bellovin s...@cs.columbia.edu 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
Re: DHS and NSA getting married?
On Fri, Oct 22, 2010 at 11:50 AM, George Bonser gbon...@seven.com wrote: From: christopher.mor...@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.
Re: NTP Server
On Sun, Oct 24, 2010 at 10:44 AM, Peter Lothberg r...@stupi.se 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.
Re: NTP Server
On Sun, Oct 24, 2010 at 1:24 PM, Joel Jaeggli joe...@bogus.com wrote: On 10/24/10 10:20 AM, Christopher Morrow wrote: On Sun, Oct 24, 2010 at 10:44 AM, Peter Lothberg r...@stupi.se 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?
Re: IPv6 Routing table will be bloated?
On Tue, Oct 26, 2010 at 2:19 PM, Sven Olaf Kamphuis s...@cb3rob.net 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? http://www.ripe.net/ripe/docs/ripe-481.html#lir Customers could get an end-user assignment (PA space normally or PI) http://www.ripe.net/ripe/docs/ripe-481.html#_8._IPv6_Provider (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: s...@cb3rob.net = penpen 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.
Re: Topic: Inter-AS BGP Local Preference Matrix
On Fri, Oct 29, 2010 at 7:16 PM, Matthew Petach mpet...@netflight.com 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!
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Sun, Oct 31, 2010 at 12:31 PM, Owen DeLong o...@delong.com wrote: On Oct 31, 2010, at 7:22 AM, valdis.kletni...@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.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 -Unique local addresses)
On Sun, Oct 31, 2010 at 2:01 PM, George Bonser gbon...@seven.com 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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@virtualized.org 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
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Mon, Nov 1, 2010 at 5:28 AM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: On Sun, 31 Oct 2010 21:32:39 -0400 Christopher Morrow morrowc.li...@gmail.com wrote: On Sun, Oct 31, 2010 at 3:10 PM, David Conrad d...@virtualized.org 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. Surely your not saying we ought to make getting PI easy, easy enough that the other options just don't make sense so that all residential users get PI so that if their ISP disappears their network doesn't break? all the world is not a corner case... I don't think sane folks are supportive of 'every end site gets pi', I think it's somewhat sane to believe that enterprise type folks can/should be able to get PI space to suit their needs. ULA for enterprises is really not a good solution. Cable/dsl end users can certainly apply for PI space they may even be able to justify an allocation (see owen...) I don't think they'll have much success actually getting a DSL/Cable provider to actually hold the route for them though... so I'm not sure that your pathological case matters here. -chris
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
oops, I clipped a little too much from the message before replying... On Mon, Nov 1, 2010 at 5:28 AM, Mark Smith na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org wrote: Permanent connectivity to the global IPv6 Internet, while common, should not be essential to being able to run IPv6, and neither should PI. All you should need to run IPv6 reliably is stable internal addressing. Global connectivity should be optional, and possibly only occasional. I think there are many cases where a 'disconnected' network will want ipv6, I do NOT believe they should use ULA space except in the most extreme cases. It makes more sense to just get these folks a GUA allocation of their proper size, support their DNS and registry needs. I agree that global connectivity should be optional... I've worked on more than one network that had better never see the light of day, and will most likely need (or already has?) ipv6 deployments in the coming months/years. -chris
Re: Token ring? topic hijack: was Re: Mystery open source switching
On Tue, Nov 2, 2010 at 3:43 PM, Chris Boyd cb...@gizmopartners.com wrote: On Nov 1, 2010, at 11:48 AM, Nick Hilliard wrote: And FDDI and X.25 and every single legacy protocol Are there still any commercial X.25 nets in operation? I had some peripheral involvement with Tymnet in the MCI/Concert conversion, and hear it shut down sometime in 2003-4. I think the ex-compuserve x.25 stuff is still operational... some of it was transitioned to IP links not x.25 (for the core links) but some x.25 tails existed as near as I knew (3 years ago) -chris
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Wed, Nov 3, 2010 at 6:43 PM, Mark Andrews ma...@isc.org wrote: Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA. not everyone's network requires 'routed' ... wrt the internet.
Re: Failover IPv6 with multiple PA prefixes (Was: IPv6 fc00::/7 - Unique local addresses)
On Thu, Nov 4, 2010 at 1:31 AM, Owen DeLong o...@delong.com wrote: On Nov 3, 2010, at 5:21 PM, valdis.kletni...@vt.edu wrote: On Wed, 03 Nov 2010 17:01:32 PDT, Owen DeLong said: On Nov 3, 2010, at 3:43 PM, Mark Andrews wrote: Actually PI is WORSE if you can't get it routed as it requires NAT or it requires MANUAL configuration of the address selection rules to be used with PA. It's very easy to get PIv6 routed for free, so, I don't see the issue there. It may be very easy to get it routed for free *now*. Will it be possible to get PIv6 routed for free once there's 300K entries in the IPv6 routing table? Or zillions, as everybody and their pet llama start using PI prefixes? (Hey, if you managed to get PI to use instead of using an ULA, and routing it is free, may as well go for it, right?) Hopefully by the time it gets to that point we'll have finally come up with a scaleable routing paradigm. Certainly we need to do that anyway. I'm not sure why we chose not to do that with IPv6 in the first place. because: 1) there were only going to be a limited number of ISP's b) every end site gets PA only iii) no need for pi d) all of the above
Re: Register.com DNS outages
On Sat, Nov 13, 2010 at 11:40 AM, Brandon Kim brandon@brandontek.com wrote: Thanks for the heads up. I just sent an email out to my companies staff to keep an eye on our own customers if they are noticing any issues. Times like this, makes you curious what kind of infrastructure register.com has? How does one protect against DDOS? this is not rocket sciencesrsly... http://www.verizonbusiness.com/Products/security/network-based/ as per usual, vzb's website is a poor excuse for a marketting tool (or sales tool, or information gathering tool.. ugh) but, bullet #2 is one option (that register.com I think actually was offered at one point in time...) is 3250/month cheaper than sla payouts from 3 days of running outages each year or so? -chris
Re: Level 3 Communications Issues Statement Concerning Comcast's Actions
On Mon, Nov 29, 2010 at 6:59 PM, Leo Bicknell bickn...@ufp.org wrote: No one will ever be in ratio compliance with an eyeball dominant network. Ever. Period. It's not possible via technology and TOS. Enforcing it as an eyeball network just forces content providers to aquire eyeballs, e.g. compete with you. That's bad business. see craig's report from nanog47: http://www.nanog.org/meetings/nanog47/presentations/Monday/Labovitz_ObserveReport_N47_Mon.pdf not for a time has Comcast been solely an 'eye-ball' network... or so they think. -chris (I don't disagree with leo's stance, though I'm not a peering person so I really try never to know how all of that magic works)
Re: Level 3 Communications Issues Statement Concerning Comcast's Actions
On Mon, Nov 29, 2010 at 11:03 PM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Mon, Nov 29, 2010 at 10:22:34PM -0500, Christopher Morrow wrote: see craig's report from nanog47: http://www.nanog.org/meetings/nanog47/presentations/Monday/Labovitz_ObserveReport_N47_Mon.pdf not for a time has Comcast been solely an 'eye-ball' network... or so they think. I think you are misreading the data. s/you are/Craig is/ I was just passing along a study presented at a nanog meeting about this kind of topic... I really do like to know next to nothing about peering. I have no idea in Comcast's case specifically, or in any recent case as my skin isn't in the game right now. However I am quite sure in the past I have delt with networks who wanted 2:1 on peering, but where I was nearly positive their customer base was 3:1 or 4:1. Basically the ratio became an excuse to depeer anyone they didn't like, it was all a sham. sure, there are more variables (I gather) than just bits in/out... like 'but my customers complain more if you are further away/slower/more-lossy' etc. None of those factors are in peering agreements I would bet, though clearly ratios are, so that stick is used to whack the other-guy over the head. But I come back to my fundamental beef with cable and DSL providers, when you're selling 50/5 (10:1 ratio), 25/5 (5:1 ratio), 12/2 (6:1 ratio) services, you can't expect to maintain a 2:1 or 3:1 ratio with your peers. web traffic (as a measure) seems to be ~10:1 when I look at my interface at home (vz-consumer-type), without packet-loss and over a decent sample of time. As with all of the 'peering disputes' over the last few years, it'll be a fun ride to watch from the outside :) -Chris
Re: Level 3 Communications Issues Statement Concerning Comcast'sActions
On Tue, Nov 30, 2010 at 1:52 AM, Mikael Abrahamsson swm...@swm.pp.se wrote: Considering there are mobile roaming partners that charge USD10-15 per megabyte, unfortunately that proposition is really hard to do in todays global market. but really, the 'cost' here is the same as a local wireless user for air-time traffic, then 1$/mbps to ship the bits off their network across the internet, right? So... same cost regardless of 'roaming' or 'local user', at the bit level, right? Perhaps some charge to do the LNP (or equivalent to find/locate the handset in the world) lookup but that can't be 10-15$/mb equivalent is it? -Chris
Re: Cage nuts/rack hw near SAVVIS DC3 (Sterling VA)
On Wed, Dec 1, 2010 at 10:24 AM, Cat Okita c...@reptiles.org wrote: On Wed, 1 Dec 2010, Leo Bicknell wrote: Every meeting I have with a colo provider I suggest this exact idea. Patch cables (cat5, single mode, multi-mode), fiber couplers, maybe even SFP's, velcro ties, a 10-in-1 screwdriver, etc. I'd say skip the colo provider, and look for vending machine companies. The colo provider's unlikely to go to the bother of digging up somebody to provide the vending machines and contents, but seems likely to be quite interested if the thing's provided to them as a package... the colo provider may not want to 'waste' electricity/cooling on a vending machine... -chris
Re: FUD: 15% of world's internet traffic hijacked
On Wed, Dec 1, 2010 at 3:28 PM, Randy Bush ra...@psg.com wrote: as usual i see no traffic measurements in the renesys note. i see inference of traffic based on some control plane measurements. and, has been shown, such inferences are highly suspect. it's fairly clear though that you won't get traffic information without looking at the interconnects between the offending parties, eh? I think the Arbor notes about this try to address this from a traffic perspective, though they have anonymized stats at best. conspiracy-hatalso, you won't get the traffic stats from the offending parties/conspiracy-hat -chris
Re: FUD: 15% of world's internet traffic hijacked
On Wed, Dec 1, 2010 at 3:52 PM, Randy Bush ra...@psg.com wrote: conspiracy-hatalso, you won't get the traffic stats from the offending parties/conspiracy-hat and how much traffic data does google publish? or iij or ntt? oops! cho, fukuda, esaki, kato [0] did show real traffic data from japan's largest isps. no accusations meant. just trying to keep the discussion near sea level. sometimes I love to pull your chain... :) I agree though that folks won't publish this data (in general) directly, for whatever reason. Also, right '15% of traffic' really should have been '15% of routes*' -chris (*) routes as seen in one set of perspectives... not valid in tennessee, wyoming, parts of Alabama, Albania, Germany, The ex-UK-protectorates or...
Re: Trying to Make Sense of the Comcast/Level 3 Dispute
On Thu, Dec 2, 2010 at 12:40 AM, Paul Ferguson fergdawgs...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Interesting article: http://www.freedom-to-tinker.com/blog/sjs/trying-make-sense-comcast-level-3 - -dispute Considering the fact that I received an e-mail survey request today from Netflix (I am a subscriber) which, among other questions, asked if I ever did streaming of their services on the Internet, Wii, Live TV, etc. (I don't), as well as asked if I am a Comcast subscriber (I am), among other last-mile service provider options -- I just found the timing of all of this very interesting. I suppose this is all just a smoke screen to force one/both sides to upgrade inter-links before the l3/flix cdn contract goes whole hog. A stalling tactic and one to push buttons (political/PR buttons) raising the stakes/pushing timing up on installs... is interesting though. -chris
Re: Level 3 Communications Issues Statement Concerning Comcast's Actions
On Thu, Dec 2, 2010 at 5:10 PM, Matthew Petach mpet...@netflight.com wrote: fair game for reverse billing. If it does, it's going to completely eliminate transit as a commercial offering; instead, we'll all be stuck doing settlements in every direction for traffic...and that's just *way* too much paperwork. ^_^; oh! that's the LD network.. that worked out so darned well, can we do it again? and can we have the ITU manage it for us? please? please? please? :) -chris
Re: wikileaks unreachable
On Fri, Dec 3, 2010 at 1:19 AM, Jorge Amodio jmamo...@gmail.com wrote: and this is based on what facts? Instead of tweeting about how to reach their content, or their IP 'they' is a multicast address ... dyn/everydns or wikileaks? which is the 'they' that is doing the twittering?
Re: Domain shut downs by Registrar?
On Fri, Dec 3, 2010 at 10:17 AM, John Levine jo...@iecc.com wrote: We do remember, don't we, that the domain that started this discussion were shut down by Verisign, the registry, not a registrar? what's super fun here is that often in conversations with registries about domains used for malware/spam/etc there's a conversation about: but we can't just shutdown a domain, we need the registrar to do that... legal/contractual restraints prohibit us... interesting that in THIS case the registry just took the action, was the domain registered through their registrar arm? -chris
Re: Domain shut downs by Registrar?
On Fri, Dec 3, 2010 at 10:45 AM, John R. Levine jo...@iecc.com wrote: We do remember, don't we, that the domain that started this discussion were shut down by Verisign, the registry, not a registrar? interesting that in THIS case the registry just took the action, was the domain registered through their registrar arm? They haven't had a registrar arm since they spun off Network Solutions in 2002. thanks... so, in this case, why did they take this action? why didn't they push the action to the registrar? or did they and the registrar refused to comply? (potentially because the domains weren't violating a TOS?) I suppose though, on the good side, we can expect the Verisign folks to now shutdown other domains we bring to their attention as malware/spamware/etc without protest? -chris
Re: The scale of streaming video on the Internet.
On Fri, Dec 3, 2010 at 10:47 AM, William Herrin b...@herrin.us wrote: If the instant problem is that the character of eyeball-level Internet service has shifted to include a major component of data which is more or less broadcast in nature (some with time shifting, some without). There's a purely technical approach that can resolve it: deeply deployed content caches. snip the above is essentially what Akamai (and likely other CDN products) built/build... from what I understand (purely from the threads here) Akamai lost out on the traffic-sales for NetFlix to L3's CDN. Comcast (for this example) lost the localized in-network caching when that happened. Maybe L3 will chose to deploy some of their cache's into Comcast (or other like minded networks) to make this all work out better/faster/stronger for the whole set of participants? But there's a third mechanism worth considering as well: the caching proxy. I think that's essentially what Akamai/LLNW are (not quite squid, patrick will get all uppity about me calling the akamai boxies 'supped up squid proxies' :) it's a simple model to keep in mind though) Apparently Google-Global-Cache is somewhat like this as well, no? http://www.afnog.org/afnog2008/.../Google-AFNOG-presentation-public.pdf Admittedly these are 'owner specific' solutions, but they do what you propose at the cost of a few gig links in the provider's network (or 10g links depending on the deployment) - all local and cheap interfaces, not long-haul, and close to the consumer of the data. Perhaps the eyeball networks should build, standardize and deploy a content caching system so that the popular Netflix streams (and the live broadcast streams) can usually get their traffic from a local source. Deploy a cache to the neighborhood box and a bigger one to the local backend. Then organize your peering so that it's _less convenient_ to request large bandwidths than to write your software so it employs the content caches. This brings with it an unsaid complication, the content-owner (netflix in this example) now depends upon some 'service' in the network (comcast in this example) to be up/operational/provisioned-properly for a service to the end-user (comcast customer in this example), even though NetFlix/Comcast may have no actual relationship. Expand this to PornTube/JustinTV/etc or something similar, how do these content owners assure (and measure and metric and route-around in the case of deviation from acceptable numbers?) that the SLA their customer expects is being respected by the internediate network(s)? How does this play if Comcast (in this example) ends up being just a transit network for another downstream ISP ? The owner-specific solutions today probably include some form of SLA measurement/monitoring and problem avoidance, or I think they probably do, Akamai I believe does at least. That sort of thing would have to be open/available as well in the 'content owner neutral' solutions. Oh, how do you deconflict situations where two content owners are using the 'service' in Comcast, but one is abusing the service? Should the content owners expect 'equal share'? or how does that work? resources on the cache system are obviously at a premium, if Netflix overruns (due to their customers demanding a more wide spread of higher resource required content - HD 1080p streams say with a 'less optimal' codec in use...) their share how does JustinTV deal with this? Do they then shift their streams to more direct-to-customer and not via the cache system? that increases their transit costs (potentially) and the costs on Comcast at the peering locations? -Chris
Re: The scale of streaming video on the Internet.
On Fri, Dec 3, 2010 at 11:18 AM, Leo Bicknell bickn...@ufp.org wrote: In a message written on Fri, Dec 03, 2010 at 11:08:21AM -0500, Christopher Morrow wrote: the above is essentially what Akamai (and likely other CDN products) built/build... from what I understand (purely from the threads here) Akamai lost out on the traffic-sales for NetFlix to L3's CDN. Comcast (for this example) lost the localized in-network caching when that happened. Playing devils advocate here I think the issue here is that the Akamai model saves the end user providers like Comcast a boatload of money. By putting a cluster in Fargo to serve those local users Comcast doesn't have to build a network to say, Chicago Equinix to get the traffic from peers. right. However, the convential wisdom is that the Akamai's of the world pay Comcast for this privledge; Comcast charges them for space, power, and port fees in Fargo. The irony here is that Comcast's insistance to charge Akamai customer rates for these ports in Fargo make Akamai's price to Netflix too high, and drove them to Level 3 who wants to drop off the traffic in places like Equinix Chicago. Now they get to build backbone to those locations to support it. In many ways I feel they are reaping what they sowed. right. I think the OP was actually thinking that /Comcast/ should run the caching boxes in each local market, exporting the 50-100 /32 routes sure... which was what I was addressing. If comcast runs these boxes, how does flix aim their customer 'through' them? how does flix assure their SLA with their customer is being met? how do they then avoid (and assure the traffic is properly handled) these boxes when problems arise? I get that the network operator (comcast here) has the best idea of their internal painpoints and costs, I just don't see that them running a set of boxes is going to actually happen/help. Also, do they charge the content owners (or their customers?) for data that passes through these boxes? how do they do cost-recovery operations for this new infra that they must maintain? to content peers at Equinix's and the like, but NOT the end user blocks. This becomes more symbiotic though as the content providers then need to know how to direct the end users to the Comcast caching boxes, so it's not so simple. right, that was the point(s) I was trying to make... sadly I didn't make them I guess. -chris -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
Re: wikileaks unreachable
On Fri, Dec 3, 2010 at 1:01 PM, Eric Brunner-Williams brun...@nic-naa.net wrote: there exists a free speech application for fast flux hosting networks, and its in connecticut, not china. (during the icann gnso pdp on fast flux hosting the above assertion was generally dismissed) 'fast flux hosting' == akamai, no? -chris
