Re: EQUINIX
Here's the list pricing we received about a year ago for 60 Hudson/111 8th in NYC: (24 month contract) Single cab: $800/mo + $1000 setup 20A @ 208V: $605/mo + $500 setup XC - Coax: $225/mo + $500 setup XC - Fiber: $325/mo + $500 setup XC - POTS: $25/mo + $100 setup XC - T1/E1: $225/mo + $500 setup PAIX 1gig: $1000/mo + $2000 setup PAIX 10gig: $2500/mo + $4000 setup Obviously, much negotiation was in order. As others have said, the cab, and even power, is somewhat reasonable. But the cross connects kill the whole thing. -Chris On Thu, Jan 17, 2013 at 10:55 AM, PC paul4...@gmail.com wrote: My experience has been that the monthly rack rental fee will be a comparative bargain to basic power and a couple in-building cross connects, which will often more than double the cost. When shopping for any provider, make sure you price out all the options you need in addition to the rack space itself. On Thu, Jan 17, 2013 at 8:04 AM, Rodrick Brown rodrick.br...@gmail.com wrote: On Thu, Jan 17, 2013 at 8:39 AM, ML m...@kenweb.org wrote: On 1/17/2013 4:49 AM, Ryan Finnesey wrote: What's the going rate now a days for a rack within EQUINIX? Cheers Ryan I would imagine this varies greatly by market and maybe even suite within the building And also power/cooling requirements. -- Regards, Chris Rogers CEO, Inerail +1.302.357.3696 x2110 http://inerail.net/
Re: Suggestions for the future on your web site: (was cookies, and before that Re: Dreamhost hijacking my prefix...)
On 17 January 2013 23:38, Matt Palmer mpal...@hezmatt.org wrote: .. By the way, if anyone *does* know of a good and reliable way to prevent CSRF without the need for any cookies or persistent server-side session state, I'd love to know how. Ten minutes with Google hasn't provided any useful information. I think many people create forms with a secret code that is different and hopefully can't be predicted by the attackers. form method=post input type=hidden name=id_user value=33 input type=hidden name=action value=delete_user input type=hidden name=secret value=5ebe2294ecd0e0f08eab7690d2a6ee69 input type=submit value=Delete user /from The easy way to do this is to generate secret from the md5 if time in miliseconds + a salt string, and store the secret generated serverside. But if you don't want to store this secret key anywhere in the server, you can relie in security by obscurity, and generate it by a predictible algorithm, like md5( year + _SALT_ + id_user +day_of_year). A attacker can figure out the algorithm, or it can be leaked, but if your site is small, and don't protect anything important, it will stop the 100% of the attackers anyway. -- -- ℱin del ℳensaje.
[NANOG-announce] NANOG 57 Agenda and Meeting Registration Reminder
Hi Everyone: A final reminder. You will not want to miss out... the NANOG 57 program is going to great. We have Monday morning Tutorials, Monday afternoon Keynote, Welcome Social, great content for 3 days! Check-out the NANOG 57 agendahttp://www.nanog.org/meetings/nanog57/agenda.phpas it continues to be updated. The Renaissance Orlando at Seaworld, *NANOG blockhttps://resweb.passkey.com/Resweb.do?mode=welcome_gi_newgroupID=10487120 Group Rate Expires Saturday, January 19, 2013, do not delay in make your reservation.* Last chance to save on your registration fee! *The current registration rate will expire on Friday, January 18, 2013.* You can register, manage your registration, and retrieve receipts from the NANOGportal (ARO)http://nanog.org/login . To create a new account, or recover your password, click herehttps://secretariat.nanog.org/ibin/c5i?rid=48 . Be sure to Join NANOG http://www.nanog.org/membership_main.html today and receive a $25 discount on standard registration fees for any NANOG conference as well as have a voice in guiding future NANOG activities. See you Orlando! Should you have any questions, please send them along to nanog-support@nanog .org. All best. Betty -- Betty Burke NANOG Executive Director 48377 Fremont Boulevard, Suite 117 Fremont, CA 94538 Tel: +1 510 492 4030 ___ NANOG-announce mailing list nanog-annou...@mailman.nanog.org http://mailman.nanog.org/mailman/listinfo/nanog-announce
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin muren...@gmail.com wrote: IPv6 is obviously the solution, but I think CGN poses more technological and legal problems for the carriers as opposed to their clients or the general-purpose non-server non-p2p application developers. Correct. The most significant challenges to CGN are legal compliance issues. NAT complicates the process of determining who did what using the public IP at this timestamp. CGN developers have designed some novel solutions to that problem, such as dedicating port ranges to particular interior addresses and logging the range once instead of trying to log every connection. So, don't expect it to be a show stopper for long. On the technical side, enterprises have been doing large-scale NAT for more than a decade now without any doomsday consequences. CGN is not different. CGN breaks the internet, but it doesn't break non-p2p VoIP at all whatsoever. Also correct. The primary impacts from CGN are folks who want to host a game server, folks running bit torrent and folks who want to use Skype. Skype's not stupid and voip relays are easy so after minor growing pains that'll cease to be an issue too. Make opting out of CGN simple and cheap. The relatively few folks who would be impacted will opt out with no particular animus towards you and you'll recover the IP addresses you had dedicated to the rest. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 18-1-2013 15:03, William Herrin wrote: On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin muren...@gmail.com wrote: On the technical side, enterprises have been doing large-scale NAT for more than a decade now without any doomsday consequences. CGN is not different. Well yeah, but everything is under control of the IT department to setup rules and forwards. That's not the same as a end user that wants a port forward to host a xbox 360 game on their fiber connection and can't set it up. I've tried getting the firewall disabled that denies ALL incoming traffic on my 3G stick and it's simply not possible, that is the sort of flexibility that the market is selling. Most of the ISPs I have personally and professionally worked with have the flexibility of a piece of mahogany. I'm pretty sure that some of the dedicated online game hosters are looking forward to this. Those investments should turn out great. Regards, Seth
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
(resending with nanog-approved address..) On 18. jan. 2013 01:30, Jeff Kell wrote: On 1/17/2013 6:50 PM, Owen DeLong wrote: Vonage will, in most cases fail through CGN as will Skype, Xbox-360, and many of the other IM clients. Not sure about Vonage, but Skype, Xbox, and just about everything else imaginable (other than hosting a server) works just fine over NAT with default-deny inbound here, and we have several thousand students in the dorms that bang the heck out of those services. Most applications have adapted to the SOHO NATing router that is prevalent today on broadband internet. And if it didn't work, believe me, I'd hear about it :) Your users must have fairly low expectations :-) That snide comment aside, a single level of NAT44 works OK now for most current consumer level applications. But this is about multiple levels of NAT, where the usual hacks with UPNP IGD/NAT-PMP to get inbound ports are not likely to work. Even if you dont support these tricks on your end today, its likely that it is supported at the other side. Most p2p traffic like Skype only needs the mapping to work at one end, as they have to signal/negotiate addresses and portnumbers through some third party anyway. So currently, even double NAT at one end, it is likely to work out (within the current expectations of users.) When CGN gets to critical mass, where both ends of a connection is likely to be even more crippled than today*, things change. Now you have to bounce all the data of some third party, like a DC, maybe not even on the same continent. When Skype fails to map ports at both ends today the experience is pretty horrible actually, at least over here, even with the backing of Microsofts infrastructure. Also makes me wonder how expensive running such services will become (Only feasable for Google and Microsoft?) * Some support for mapping ports at CGN is in development, but requires new or updated CPE/home gateways, software support/awareness and support for it in the CGN (riiight.)
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Owen DeLong wrote: Clearly we have run out of trickery as multiple layers of NAT stumps even the finest of our tricksters. Yes, we can dedicate thousands more developer hours to making yet more extensions to code to work around yet more NAT and maybe make it sort of kind of work almost as poorly as it does now. Or we could pour a fraction of those developer hours into implementing IPv6 in those same applications and have the problem solved in perpetuity. There is no we People will follow their personal motivations. If that includes improving their application experience in the face of prevalent CGN technology, I expect many of them to decide to put in the effort no matter what either your or I have to say about it. My hope is that we will realize at some point that this is a badly loosing proposition, but, my fear is that we will actually find ways to make it work and worse yet, dedicate resources to doing so. IMHO, having it fail miserably is the best case scenario. The alternatives are far worse. See above. The internet is not top down. It is a potpourri of interacting influences. Nobody takes marching orders from either of us. I'd believe 50% or maybe even 65%, but 75% stretches credibility. See above for a partial list of the various things I expect they are doing with those addresses. So a provider to have a one to one relationship between infrastructure addresses and subscribers is somehow plausible to you? Anyone else? Not to me. Not even if you count every single employees and every single corporate server and device, of which the vast majority are not even using globally unique addresses. Which is what we are discussing. And suppose they are. A corporation like that can re-use 50% of their IPv4 by converting internally to NAT (and IPv6 we hope). How about much simpler math. Assume 75% IP in any provider organization are for subscribers. Assume an average 5-10 subscribers per CGN IP. I don't believe the first assumption and I think that more than about 3 is rather optimistic for the second one, actually. Especially in the face of dedicated port range CGN proposed by most of the ISPs I know have real plans to implement CGN rather than just a yeah, we'll do that when we have to approach. Most NAT44 implementations have absolutely no issue scaling to low hundreds of users with ONE IP address. 3 is absolutely ridiculously low. 3 of the above, maybe. However, even at 3, that means that they can double their subscriber base with their existing addresses. So unless their existing base took 2 months to acquire, that is a deal more than 4 month stop gap you claim. And since you believe that it is plausible for such an organization to have a one to one infrastructure/subscriber relationship, going private (and we hope ipv6) internally, gives them another 3x subscriber base. Clearly, CGN can provide enough address re-use to stave off exhausting in a provider's subscriber base for years. But only if the technology scales and is not immediately rejected by 30-60% of the subscriber base. This is why we view the testing of CGN as newsworthy. Clearly, that organization's subscriber growth will be limited by CGN technology, not by address scarcity. Why? Does it not scale linearly? If not, why not? I dont particularly like a multilayered NAT internet any more than you. However it is coming and will stay for as long as it is needed and useful for those who operate it. Which is likely to be far longer then either of us like. We only differ in one point. You believe it will be so bad that it will immediately drive ipv6 adoption and be viewed as a short term expensive boondoggle of a misguided experiment. I am not so confident in its failure. I think we are heading toward a new norm. Think locally for a bit. Addresses are not instantaneously fungible across the internet. Any provider who can pull this off will have far more then a 4-month stop-gap. They may even have enough to peddle on the market. I think that's very optimistic. With your numbers, a provider can double or triple (actually quadruple or sextuple using your ratio) their subscriber base by converting to CGN. Were you being overly optimistic? Or were my estimates, starting at quadrupling or more, overly optimistic? I'm not sure why you say they are not instantaneously fungible. Owen Because nobody deploying CGN is going to flag day convert entire subscriber bases. Because the addresses they free up will be reused internally. Because if you are not one of these entities with low hanging fruit such as easily convertible to CGN subscriber bases, you are NOT going to directly benefit from the efforts of those who do. Unless they peddle it (or return it). Joe
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 1/17/13 6:21 PM, William Herrin b...@herrin.us wrote: On Thu, Jan 17, 2013 at 11:01 AM, Lee Howard l...@asgard.org wrote: On 1/17/13 9:54 AM, William Herrin b...@herrin.us wrote: On Thu, Jan 17, 2013 at 5:06 AM, . oscar.vi...@gmail.com wrote: The people on this list have a influence in how the Internet run, hope somebody smart can figure how we can avoid going there, because there is frustrating and unfun. Free network-based firewall to be installed next month. OPT OUT HERE if you don't want it. I haven't heard anyone talking about carrier-grade firewalls. To make CGN work a little, you have to enable full-cone NAT, which means as long as you're connected to anything on IPv4, anyone can reach you (and for a timeout period after that). And most CGN wireline deployments will have some kind of bulk port assignment, so the same ports always go to the same users. NAT != security, and if you try to make it, you will lose more customers than I predicted. Hi Lee, Then it's a firewall that mildly enhances protection by obstructing 90% of the port scanning attacks which happen against your computer. It's a free country so you're welcome to believe that the presence or absence of NAT has no impact on the probability of a given machine being compromised. Of course, you're also welcome to join the flat earth society. As for me, the causative relationship between the rise of the DSL router implementing negligible security except NAT and the fall of port scanning as a credible attack vector seems blatant enough. CGNs are not identical to home NAT functionality. Home NATs are frequently restricted cone NATs, which is why uPNP or manual port-forwarding are required. CGNs for residential deployments are full cone NATs, so that this problematic applications are less problematic. See http://en.wikipedia.org/wiki/Network_address_translation and draft-donley-nat444-impacts. It's not a hard problem. There are yet plenty of IPv4 addresses to go around for all the people who actually care whether or not they're behind a NAT. I doubt that very much, and look forward to your analysis supporting that statement. If you have the data I'll be happy to crunch it but I'm afraid I'll have to leave the data collection to someone who is paid to do that very exhaustive work. I don't have any data that might support your assertion, which is why I'm calling you on it. Nevertheless, I'll be happy to document my assumptions and show you where they lead. I assume that fewer than 1 in 10 eyeballs would find Internet service behind a NAT unsatisfactory. Eyeballs are the consumers of content, the modem, cable modem, residential DSL customers. Some few of them are running game servers, web servers, etc. but 9 in 10 are the email, vonage and netflix variety who are basically not impacted by NAT. Netflix seems to have some funny interactions with some gateways and CGN. [nat444-impacts] What about p2p? I assume that 75% or more of the IPv4 addresses which are employed in any use (not sitting idle) are employed by eyeball customers. Verizon Wireless has - remind me - how many /8's compared to, say, Google? The same number: 0. I don't know how many addresses VZW has, but I could look it up in Whois if I knew the orgID. How'd you get 75%? If you count from the explosion of interest in the Internet in 1995 to now, it took 18 years to consume all the IPv4 addresses. Call it consumption of 1/18th of the address space per year. You're going with linear growth? See nro.net/statistics. Is it more like 1 in 5 customers would cough up an extra $5 rather than use a NAT address? The nearest comparable would be your ratio of dynamic to static IP assignments. Does your data support that being higher than 1 in 10? I'd bet the broad data sets don't. If an ISP is so close to running out of addresses that they need CGN, let's say they have 1 year of addresses remaining. Given how many ports apps use, recommendations are running to 10:1 user:address (but I could well imagine that increasing to 50:1). That means that for every user you NAT, you get 1/10 of an address. Example: An 10,000-user ISP is growing at 10% annually. They have 1,000 addresses left, so they implement CGN. You say to assuming 90% of them can be NATted, so next year, 100 get a unique IPv4 address, the other 900 share 90 addresses. At 190 addresses per year, CGN bought you five years. I think your 90% is high. If it's 70%, you burn 370 per year. That doesn't include the fact the increased support costs, or alienated customer cancellations, or any of the stuff I talked about in TCO of CGN. Lee
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 1/18/13 9:03 AM, William Herrin b...@herrin.us wrote: On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin muren...@gmail.com wrote: IPv6 is obviously the solution, but I think CGN poses more technological and legal problems for the carriers as opposed to their clients or the general-purpose non-server non-p2p application developers. Correct. The most significant challenges to CGN are legal compliance issues. NAT complicates the process of determining who did what using the public IP at this timestamp. CGN developers have designed some novel solutions to that problem, such as dedicating port ranges to particular interior addresses and logging the range once instead of trying to log every connection. So, don't expect it to be a show stopper for long. Many servers don't log source port. Doesn't matter if the CGN operator has a log, if you can't provide enough data to find the right entry in the log. On the technical side, enterprises have been doing large-scale NAT for more than a decade now without any doomsday consequences. CGN is not different. Even if the implementation was the same (it's not), that doesn't mean the operation is the same in a a different environment. Residential users have different applications and expectations than enterprise users (not a lot of game consoles or BitTorrent on corporate networks). The legal issue is different, too: a different level of response is appropriate from a corporate net admin than an ISP. CGN breaks the internet, but it doesn't break non-p2p VoIP at all whatsoever. Also correct. The primary impacts from CGN are folks who want to host a game server, folks running bit torrent and folks who want to use Skype. Skype's not stupid and voip relays are easy so after minor growing pains that'll cease to be an issue too. voip relays are easy? To what scale, for a free service? Make opting out of CGN simple and cheap. The relatively few folks who would be impacted will opt out with no particular animus towards you and you'll recover the IP addresses you had dedicated to the rest. You are welcome to deploy it if you choose to. Part of the reason I'm arguing against it is that if everyone deploys it, then everyone has to deploy it. If it is seen as an alternative to IPv6 by some, then others' deployment of IPv6 is made less useful: network effect. Also, spending money on CGN seems misguided; if you agree that you're going to deploy IPv6 anyway, why spend the money for IPv6 *and also* for CGN? Lee
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Sent from my iPad On Jan 18, 2013, at 4:03 AM, William Herrin b...@herrin.us wrote: On Thu, Jan 17, 2013 at 11:15 PM, Constantine A. Murenin muren...@gmail.com wrote: IPv6 is obviously the solution, but I think CGN poses more technological and legal problems for the carriers as opposed to their clients or the general-purpose non-server non-p2p application developers. Correct. The most significant challenges to CGN are legal compliance issues. NAT complicates the process of determining who did what using the public IP at this timestamp. CGN developers have designed some novel solutions to that problem, such as dedicating port ranges to particular interior addresses and logging the range once instead of trying to log every connection. So, don't expect it to be a show stopper for long. On the technical side, enterprises have been doing large-scale NAT for more than a decade now without any doomsday consequences. CGN is not different. Yes it is... In the enterprise, whatever the security team decides isn't supposed to be supported on the enterprise LAN, the end-users just sort of have to accept. In the residential ISP world, unless every ISP in a given service area degrades all of their customers in the exact same way, you have a very different situation. CGN breaks the internet, but it doesn't break non-p2p VoIP at all whatsoever. Also correct. The primary impacts from CGN are folks who want to host a game server, folks running bit torrent and folks who want to use Skype. Skype's not stupid and voip relays are easy so after minor growing pains that'll cease to be an issue too. Make opting out of CGN simple and cheap. The relatively few folks who would be impacted will opt out with no particular animus towards you and you'll recover the IP addresses you had dedicated to the rest. An interesting theory, but I don't think it will be so few. Owen
Zero-Touch Deployment Remote Office solution?
We have a bunch of small remote offices where we deploy cheap routers with VPN tunnels back to the central office. This is a very static process with high overhead… we have to manage each remote router separately, and the offices do not have tech personnel that can handle local office issues. We're looking for a more centrally managed and automated zero-touch remote office solution, like the Cisco Virtual Office, where the local non-clueful people don't have to do much. http://www.cisco.com/en/US/netsol/ns855/index.html Does anyone have any experience / feeback for this Cisco Virtual Office solution or have recommendations for alternative solutions. - Matt
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Lee Howard wrote: You are welcome to deploy it if you choose to. Part of the reason I'm arguing against it is that if everyone deploys it, then everyone has to deploy it. If it is seen as an alternative to IPv6 by some, then others' deployment of IPv6 is made less useful: network effect. Also, spending money on CGN seems misguided; if you agree that you're going to deploy IPv6 anyway, why spend the money for IPv6 *and also* for CGN? Lee Suppose a provider fully deploys v6, they will still need CGN so long as they have customers who want to access the v4 internet. Unfortunately, that may have the side effect of undercutting some portion of v6's value proposition, inversely related to its suckage. Joe
Device specifically made for high capacity GRE tunnels for dozens of sites
Hello, Can anyone recommend a device that will allow for multiple gigabit gre tunnels with ability to handle up to a million pps? I know it can be done on a bsd or nix box , or something running junos but Im looking for something specifically made and tailored for GRE tunnels. Thanks, Ameen
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Sent from my iPad On Jan 18, 2013, at 5:57 AM, Joe Maimon jmai...@ttec.com wrote: Owen DeLong wrote: Clearly we have run out of trickery as multiple layers of NAT stumps even the finest of our tricksters. Yes, we can dedicate thousands more developer hours to making yet more extensions to code to work around yet more NAT and maybe make it sort of kind of work almost as poorly as it does now. Or we could pour a fraction of those developer hours into implementing IPv6 in those same applications and have the problem solved in perpetuity. There is no we People will follow their personal motivations. If that includes improving their application experience in the face of prevalent CGN technology, I expect many of them to decide to put in the effort no matter what either your or I have to say about it. There most certainly is a WE. WE may not get to make the decision about how any of this turns out, but WE will suffer the consequences of those collective decisions. My hope is that we will realize at some point that this is a badly loosing proposition, but, my fear is that we will actually find ways to make it work and worse yet, dedicate resources to doing so. IMHO, having it fail miserably is the best case scenario. The alternatives are far worse. See above. The internet is not top down. It is a potpourri of interacting influences. Nobody takes marching orders from either of us. Right, but everybody suffers the consequences of the decisions made by those interacting influences. As such, I am at least attempting to educate as many of the decision makers along the way in the hopes of getting some reasonable outcome somewhere down the road rather than watching the internet fall to pieces in NAT hell. I'd believe 50% or maybe even 65%, but 75% stretches credibility. See above for a partial list of the various things I expect they are doing with those addresses. So a provider to have a one to one relationship between infrastructure addresses and subscribers is somehow plausible to you? Anyone else? Subscribers, no, subscriber addresses in a wireless environment, yeah. Not to me. Not even if you count every single employees and every single corporate server and device, of which the vast majority are not even using globally unique addresses. Which is what we are discussing. And suppose they are. A corporation like that can re-use 50% of their IPv4 by converting internally to NAT (and IPv6 we hope). There are many ways we can sabotage our infrastructure in order to squeeze more NAT out of many places. Personally, I would not advocate putting that effort into such an obviously losing proposition, but obviously I may well be in the minority there. How about much simpler math. Assume 75% IP in any provider organization are for subscribers. Assume an average 5-10 subscribers per CGN IP. I don't believe the first assumption and I think that more than about 3 is rather optimistic for the second one, actually. Especially in the face of dedicated port range CGN proposed by most of the ISPs I know have real plans to implement CGN rather than just a yeah, we'll do that when we have to approach. Most NAT44 implementations have absolutely no issue scaling to low hundreds of users with ONE IP address. We're not talking NAT44... We're talking NAT444 and you don't get nearly the multiplier at the second layer that you can get at the first level. You've already concentrated those low hundreds of users into the port range of a single address at the first level. Now you're inflicting a second level where you can't get nearly that level of compression. 3 is absolutely ridiculously low. 3 of the above, maybe. However, even at 3, that means that they can double their subscriber base with their existing addresses. So unless their existing base took 2 months to acquire, that is a deal more than 4 month stop gap you claim. Or not. At 3 they can double their subscriber base if they don't need any additional external facing infrastructure to support all of this and get a 100% efficient conversion of users from their existing connectivity to CGN. And since you believe that it is plausible for such an organization to have a one to one infrastructure/subscriber relationship, going private (and we hope ipv6) internally, gives them another 3x subscriber base. Clearly, CGN can provide enough address re-use to stave off exhausting in a provider's subscriber base for years. But only if the technology scales and is not immediately rejected by 30-60% of the subscriber base. Which assumes many facts not in evidence and is contrary to the research and testing that has been done so far. This is why we view the testing of CGN as newsworthy. draft-donnely anyone? Clearly, that organization's subscriber growth will be limited by CGN technology, not by address scarcity. Why? Does it not scale
Re: Device specifically made for high capacity GRE tunnels for dozens of sites
The new Cloud Core routers from Mikrotik might be able to handle this... Granted they are new, and the ROS (6.0) is not fully baked, But based on the Specs, these may have enough CPU Ram oumph to handle what you are asking for. YMMV. Regards. Faisal Imtiaz Snappy Internet Telecom On 1/18/2013 12:51 PM, A. Pishdadi wrote: Hello, Can anyone recommend a device that will allow for multiple gigabit gre tunnels with ability to handle up to a million pps? I know it can be done on a bsd or nix box , or something running junos but Im looking for something specifically made and tailored for GRE tunnels. Thanks, Ameen
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Sent from my iPad On Jan 18, 2013, at 7:48 AM, Joe Maimon jmai...@ttec.com wrote: Lee Howard wrote: You are welcome to deploy it if you choose to. Part of the reason I'm arguing against it is that if everyone deploys it, then everyone has to deploy it. If it is seen as an alternative to IPv6 by some, then others' deployment of IPv6 is made less useful: network effect. Also, spending money on CGN seems misguided; if you agree that you're going to deploy IPv6 anyway, why spend the money for IPv6 *and also* for CGN? Lee Suppose a provider fully deploys v6, they will still need CGN so long as they have customers who want to access the v4 internet. Actually, NAT64/DNS64 is a much better alternative in that situation. The bigger issue is customers who still have v4-only devices and some reasonable expectation that those will continue to be supported. Unfortunately, that may have the side effect of undercutting some portion of v6's value proposition, inversely related to its suckage. Which is why I consider the consumer electronics industry to be the important frontier in getting IPv6 support at this point. All of these smart TVs, DVD players, receivers, etc. that don't support IPv6 are going to be the real problem in deploying non-IPv4 service to residential customers in the coming years. Owen
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Lee Howard wrote: If an ISP is so close to running out of addresses that they need CGN, let's say they have 1 year of addresses remaining. Given how many ports apps use, recommendations are running to 10:1 user:address (but I could well imagine that increasing to 50:1). That means that for every user you NAT, you get 1/10 of an address. Example: An 10,000-user ISP is growing at 10% annually. They have 1,000 addresses left, so they implement CGN. You say to assuming 90% of them can be NATted, so next year, 100 get a unique IPv4 address, the other 900 share 90 addresses. At 190 addresses per year, CGN bought you five years. I think your 90% is high. If it's 70%, you burn 370 per year. That doesn't include the fact the increased support costs, or alienated customer cancellations, or any of the stuff I talked about in TCO of CGN. Lee 2-5 years from a currently one year supply? Factor in the current base and growth for at least another decade is assured. If it works for the new subscribers, it will work for the existing ones. Does anybody doubt that successful CGN deployment easily translates into many years more of v4? We understand that there are hosts of theoretical and practical impacts. What we do not yet know is how the public and providers at large will react or adapt to these impacts. If just the right balance of CGN negativity and resulting v6 adoption is the result, then we will all muddle through more or less ok. Otherwise we will be seeing either frantic v6 migration everywhere or even slower pace then what we have now. Joe
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Fri, Jan 18, 2013 at 12:20 PM, Lee Howard l...@asgard.org wrote: On 1/17/13 6:21 PM, William Herrin b...@herrin.us wrote: Then it's a firewall that mildly enhances protection by obstructing 90% of the port scanning attacks which happen against your computer. It's a free country so you're welcome to believe that the presence or absence of NAT has no impact on the probability of a given machine being compromised. Of course, you're also welcome to join the flat earth society. As for me, the causative relationship between the rise of the DSL router implementing negligible security except NAT and the fall of port scanning as a credible attack vector seems blatant enough. CGNs are not identical to home NAT functionality. Didn't say they were. What I said was that claiming NAT has no security impact was false on its face. Home NATs are frequently restricted cone NATs, which is why uPNP or manual port-forwarding are required. CGNs for residential deployments are full cone NATs, CGNs are most certainly not full cone NATs. Full cone NATs guarantee that any traffic which arrives at the external address is mapped to the internal address at the same port, functionality which requires a 1:1 mapping between external addresses and active internal addresses. Were they full-cone, with a 1:1 IP address mapping, CGNs would be completely useless for the stated purpose of reducing consumption of global addresses. I'm given to understand that they do try to restrict a given internal address to emitting packets on a particular range of ports on a particular external address but that's functionality on top of a restricted-port cone NAT, not a fundamentally different kind of NAT. I assume that fewer than 1 in 10 eyeballs would find Internet service behind a NAT unsatisfactory. Eyeballs are the consumers of content, the modem, cable modem, residential DSL customers. Some few of them are running game servers, web servers, etc. but 9 in 10 are the email, vonage and netflix variety who are basically not impacted by NAT. Netflix seems to have some funny interactions with some gateways and CGN. [nat444-impacts] Some NATs have serious bugs that aren't obvious until you try to stack them. What about p2p? If it worked with CGNs there'd be a whole lot less than 1 in 10 folks needing to opt out. How'd you get 75%? It's a SWAG, hence an assumption. You're going with linear growth? See nro.net/statistics. I'm guessing sublinear given the major backpressure from having to purchase or transfer IP addresses from other uses instead of getting fresh ones from a registry but the evidence isn't in yet so I'll conservatively estimate it at linear. Is it more like 1 in 5 customers would cough up an extra $5 rather than use a NAT address? The nearest comparable would be your ratio of dynamic to static IP assignments. Does your data support that being higher than 1 in 10? I'd bet the broad data sets don't. If an ISP is so close to running out of addresses that they need CGN, let's say they have 1 year of addresses remaining. Given how many ports apps use, recommendations are running to 10:1 user:address (but I could well imagine that increasing to 50:1). That means that for every user you NAT, you get 1/10 of an address. So at 10:1 you get 9/10ths of an address back from each of the 9 in 10 eyeballs who converts to NAT. At a more likely ratio of 30:1 you get 29/30ths back. I'd have to rerun my numbers but that shaves something on the order of 1 year off my 37 year estimate. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Device specifically made for high capacity GRE tunnels for dozens of sites
On Fri, Jan 18, 2013 at 12:51 PM, A. Pishdadi apishd...@gmail.com wrote: Hello, Can anyone recommend a device that will allow for multiple gigabit gre tunnels with ability to handle up to a million pps? I know it can be done on a bsd or nix box , or something running junos but Im looking for something specifically made and tailored for GRE tunnels. dedicate an MPC on an MX box? 10gbps of gre, weee!
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Sent from my iPad On Jan 18, 2013, at 8:06 AM, William Herrin b...@herrin.us wrote: On Fri, Jan 18, 2013 at 12:20 PM, Lee Howard l...@asgard.org wrote: On 1/17/13 6:21 PM, William Herrin b...@herrin.us wrote: Then it's a firewall that mildly enhances protection by obstructing 90% of the port scanning attacks which happen against your computer. It's a free country so you're welcome to believe that the presence or absence of NAT has no impact on the probability of a given machine being compromised. Of course, you're also welcome to join the flat earth society. As for me, the causative relationship between the rise of the DSL router implementing negligible security except NAT and the fall of port scanning as a credible attack vector seems blatant enough. CGNs are not identical to home NAT functionality. Didn't say they were. What I said was that claiming NAT has no security impact was false on its face. Even I have never claimed that. I think everyone pretty well understands at this point just how injurious NAT is to actual security. CGNs are most certainly not full cone NATs. Full cone NATs guarantee that any traffic which arrives at the external address is mapped to the internal address at the same port, functionality which requires a 1:1 mapping between external addresses and active internal addresses. Were they full-cone, with a 1:1 IP address mapping, CGNs would be completely useless for the stated purpose of reducing consumption of global addresses. I'm given to understand that they do try to restrict a given internal address to emitting packets on a particular range of ports on a particular external address but that's functionality on top of a restricted-port cone NAT, not a fundamentally different kind of NAT. Actually, as I understand it, it's a hybrid. It's full cone (sort of) in that any packet that arrives within the port range will be translated to the corresponding internal address. It's restricted cone in that it's a port range instead of all ports. I'm not sure how the interior device is constrained to emitting only within the port range unless they are customizing all of the CPE in order to support that. I assume that fewer than 1 in 10 eyeballs would find Internet service behind a NAT unsatisfactory. Eyeballs are the consumers of content, the modem, cable modem, residential DSL customers. Some few of them are running game servers, web servers, etc. but 9 in 10 are the email, vonage and netflix variety who are basically not impacted by NAT. Netflix seems to have some funny interactions with some gateways and CGN. [nat444-impacts] Some NATs have serious bugs that aren't obvious until you try to stack them. Which in itself is a pretty strong argument against CGN. What about p2p? If it worked with CGNs there'd be a whole lot less than 1 in 10 folks needing to opt out. So you are assuming 10% of the internet currently uses any p2p technology? Interesting. You're going with linear growth? See nro.net/statistics. I'm guessing sublinear given the major backpressure from having to purchase or transfer IP addresses from other uses instead of getting fresh ones from a registry but the evidence isn't in yet so I'll conservatively estimate it at linear. I don't think that backpressure really works against having new subscribers or towards reducing churn in the market place where there is competition. As such, I don't see how that would apply. Is it more like 1 in 5 customers would cough up an extra $5 rather than use a NAT address? The nearest comparable would be your ratio of dynamic to static IP assignments. Does your data support that being higher than 1 in 10? I'd bet the broad data sets don't. If an ISP is so close to running out of addresses that they need CGN, let's say they have 1 year of addresses remaining. Given how many ports apps use, recommendations are running to 10:1 user:address (but I could well imagine that increasing to 50:1). That means that for every user you NAT, you get 1/10 of an address. So at 10:1 you get 9/10ths of an address back from each of the 9 in 10 eyeballs who converts to NAT. At a more likely ratio of 30:1 you get 29/30ths back. I'd have to rerun my numbers but that shaves something on the order of 1 year off my 37 year estimate. Actually, at 10:1, you get back 10/11ths, not 9/10ths. However, if CGN's limitations pick up some bad press in the early days, that ratio may well convert to more like 1:10 where you get back 1/11th instead of 10/11ths. This all remains to be seen. Remember, the public will go much more with the emotional reaction to the first press accounts than it will go with rational or well thought out technical argument. Owen
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 1/18/13 12:48 PM, Joe Maimon jmai...@ttec.com wrote: Lee Howard wrote: You are welcome to deploy it if you choose to. Part of the reason I'm arguing against it is that if everyone deploys it, then everyone has to deploy it. If it is seen as an alternative to IPv6 by some, then others' deployment of IPv6 is made less useful: network effect. Also, spending money on CGN seems misguided; if you agree that you're going to deploy IPv6 anyway, why spend the money for IPv6 *and also* for CGN? Lee Suppose a provider fully deploys v6, they will still need CGN so long as they have customers who want to access the v4 internet. Not necessarily. Maybe they need CGN, but they need NAT64, not NAT44. Or IVI. Or maybe they should just hold their noses and buy addresses for a year or a few. What they need a transition strategy; it doesn't necessarily have to be CGN. Years ago, I asked, Why are we stuck with NAT? I still ask that. I believe that the reason we're stuck with it is that so many of us believe we're stuck with it--we're resigned to failure, so we don't do anything about it. One of the largest problems we have with this transition is that no one believes they have any influence on it: I'm stuck with IPv4 until every single other host on the Internet is using IPv6, and maybe for a while after that, depending on happy eyeballs. There are many levers of influence, but the most important ones to use are those that shift externalities. The cost in transition, either in IPv6 or in CGN (or both) will be incurred disproportionately by ISPs. Content providers who care most about quality experience (and usefulness of IP address information) now support IPv6. If you think creatively, you might come up with several levers that could shift the expense from it's up to ISPs to translate to content and devices manufacturer businesses are at risk if they don't support IPv6. Then there's the question--how do you know when you're done? Every single host on the Internet is running IPv6? All but 100? A million? A billion? Probably somewhere in between, but each operator has to decide. Everyone else has to decide when to support IPv6--and hope it's before operators call the transition complete, because then it's too late, because consumers will choose the competitor's product or service that works (on IPv6). If Wordpress doesn't work because there's no IPv6, but Blogspot and Blogger do, maybe consumers just switch. Lee
Re: Device specifically made for high capacity GRE tunnels for dozens of sites
I don't think you are going to find something made just for terminating GRE tunnels but the Cisco ASR1000 and the Juniper MX5-MX80 or SRX line can do what you want. -Phil On 1/18/13 12:51 PM, A. Pishdadi apishd...@gmail.com wrote: Hello, Can anyone recommend a device that will allow for multiple gigabit gre tunnels with ability to handle up to a million pps? I know it can be done on a bsd or nix box , or something running junos but Im looking for something specifically made and tailored for GRE tunnels. Thanks, Ameen
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 1/18/13 1:03 PM, Joe Maimon jmai...@ttec.com wrote: Lee Howard wrote: If an ISP is so close to running out of addresses that they need CGN, let's say they have 1 year of addresses remaining. Given how many ports apps use, recommendations are running to 10:1 user:address (but I could well imagine that increasing to 50:1). That means that for every user you NAT, you get 1/10 of an address. Example: An 10,000-user ISP is growing at 10% annually. They have 1,000 addresses left, so they implement CGN. You say to assuming 90% of them can be NATted, so next year, 100 get a unique IPv4 address, the other 900 share 90 addresses. At 190 addresses per year, CGN bought you five years. I think your 90% is high. If it's 70%, you burn 370 per year. That doesn't include the fact the increased support costs, or alienated customer cancellations, or any of the stuff I talked about in TCO of CGN. Lee 2-5 years from a currently one year supply? Factor in the current base and growth for at least another decade is assured. If it works for the new subscribers, it will work for the existing ones. It is difficult to change an existing customer's service. Good luck. Does anybody doubt that successful CGN deployment easily translates into many years more of v4? Yes, I doubt it. Although if you define successful as many more years of IPv4 my doubts vanish solipsistically. We understand that there are hosts of theoretical and practical impacts. What we do not yet know is how the public and providers at large will react or adapt to these impacts. If just the right balance of CGN negativity and resulting v6 adoption is the result, then we will all muddle through more or less ok. Otherwise we will be seeing either frantic v6 migration everywhere or even slower pace then what we have now. Fear, uncertainty, doubt. Possible frantic migration. These sound bad to me. Lee Joe
Weekly Routing Table Report
This is an automated weekly mailing describing the state of the Internet Routing Table as seen from APNIC's router in Japan. The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG, LacNOG, TRNOG, CaribNOG and the RIPE Routing Working Group. Daily listings are sent to bgp-st...@lists.apnic.net For historical data, please see http://thyme.rand.apnic.net. If you have any comments please contact Philip Smith pfsi...@gmail.com. Routing Table Report 04:00 +10GMT Sat 19 Jan, 2013 Report Website: http://thyme.rand.apnic.net Detailed Analysis: http://thyme.rand.apnic.net/current/ Analysis Summary BGP routing table entries examined: 438891 Prefixes after maximum aggregation: 181575 Deaggregation factor: 2.42 Unique aggregates announced to Internet: 216035 Total ASes present in the Internet Routing Table: 43066 Prefixes per ASN: 10.19 Origin-only ASes present in the Internet Routing Table: 34033 Origin ASes announcing only one prefix: 15897 Transit ASes present in the Internet Routing Table:5730 Transit-only ASes present in the Internet Routing Table:135 Average AS path length visible in the Internet Routing Table: 4.5 Max AS path length visible: 32 Max AS path prepend of ASN ( 28730) 25 Prefixes from unregistered ASNs in the Routing Table: 378 Unregistered ASNs in the Routing Table: 127 Number of 32-bit ASNs allocated by the RIRs: 3668 Number of 32-bit ASNs visible in the Routing Table:3303 Prefixes from 32-bit ASNs in the Routing Table:9072 Special use prefixes present in the Routing Table: 16 Prefixes being announced from unallocated address space:190 Number of addresses announced to Internet: 2628231852 Equivalent to 156 /8s, 167 /16s and 162 /24s Percentage of available address space announced: 71.0 Percentage of allocated address space announced: 71.0 Percentage of available address space allocated: 100.0 Percentage of address space in use by end-sites: 94.1 Total number of prefixes smaller than registry allocations: 154509 APNIC Region Analysis Summary - Prefixes being announced by APNIC Region ASes: 105723 Total APNIC prefixes after maximum aggregation: 32993 APNIC Deaggregation factor:3.20 Prefixes being announced from the APNIC address blocks: 106736 Unique aggregates announced from the APNIC address blocks:43694 APNIC Region origin ASes present in the Internet Routing Table:4816 APNIC Prefixes per ASN: 22.16 APNIC Region origin ASes announcing only one prefix: 1244 APNIC Region transit ASes present in the Internet Routing Table:811 Average APNIC Region AS path length visible:4.5 Max APNIC Region AS path length visible: 23 Number of APNIC region 32-bit ASNs visible in the Routing Table:411 Number of APNIC addresses announced to Internet: 717390240 Equivalent to 42 /8s, 194 /16s and 129 /24s Percentage of available APNIC address space announced: 83.8 APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431 (pre-ERX allocations) 23552-24575, 37888-38911, 45056-46079, 55296-56319, 58368-59391, 131072-133119 APNIC Address Blocks 1/8, 14/8, 27/8, 36/8, 39/8, 42/8, 43/8, 49/8, 58/8, 59/8, 60/8, 61/8, 101/8, 103/8, 106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8, 116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8, 123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8, 163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8, 203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8, 222/8, 223/8, ARIN Region Analysis Summary Prefixes being announced by ARIN Region ASes:155380 Total ARIN prefixes after maximum aggregation:78597 ARIN Deaggregation factor: 1.98 Prefixes being announced from the ARIN address blocks: 156021 Unique aggregates announced from the ARIN address blocks: 70747 ARIN Region origin ASes present in the Internet Routing Table:15392 ARIN Prefixes per ASN:10.14 ARIN Region origin
Re: Device specifically made for high capacity GRE tunnels for dozens of sites
mx80 (or similar) or ASR. The MX would probably be my preference for just pushing huge amounts of GRE packets and scales nicely in a single box solution. On Fri, Jan 18, 2013 at 11:21 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jan 18, 2013 at 12:51 PM, A. Pishdadi apishd...@gmail.com wrote: Hello, Can anyone recommend a device that will allow for multiple gigabit gre tunnels with ability to handle up to a million pps? I know it can be done on a bsd or nix box , or something running junos but Im looking for something specifically made and tailored for GRE tunnels. dedicate an MPC on an MX box? 10gbps of gre, weee!
Re: Zero-Touch Deployment Remote Office solution?
I handle this a different way. I'm not saying it's the easiest solution, but its very scalable to many thousands of endpoints. I take a small router and I set the WAN side to DHCP. I use client-intiated L2TP tunnels w/ ipsec protection to build a tunnel to the head end. The beauty of this is: 1) It works on any internet connection. NAT and dynamic IPs are not a problem. Since it's all UDP encapsulated and client intiated, they just need to supply internet access via DHCP. 2) It's stateful. The username/password defined on the remote client decides what IP block is routed to the client. All configuration is done from the head end based on the radius file. Routed IP blocks. Access lists. DNS settings. You name it. A report off the IP list data file builds the radius file. If PPP/IPCP and virtual-templating can do it, you are good. 4) It supports all your standard routing protocols, and multicast, if desired. 5) The only thing needing provisioning on the remote side is username/password. Configs are pre-seeded with a special username/password that provides enough access for the head office to login, change it to the final value, and reload. Now, I know there's several more mainstream solutions than this, and while this removes technical complexity from the branch office, it does add some to the headquarters. If you're looking for a more out of the box solution, Cisco has an EZ-VPN solution, amongst others. On Fri, Jan 18, 2013 at 10:41 AM, Matthew Craig matcr...@nmsu.edu wrote: We have a bunch of small remote offices where we deploy cheap routers with VPN tunnels back to the central office. This is a very static process with high overhead… we have to manage each remote router separately, and the offices do not have tech personnel that can handle local office issues. We're looking for a more centrally managed and automated zero-touch remote office solution, like the Cisco Virtual Office, where the local non-clueful people don't have to do much. http://www.cisco.com/en/US/netsol/ns855/index.html Does anyone have any experience / feeback for this Cisco Virtual Office solution or have recommendations for alternative solutions. - Matt
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Thu, 17 Jan 2013 18:21:28 -0500, William Herrin said: Then it's a firewall that mildly enhances protection by obstructing 90% of the port scanning attacks which happen against your computer. It's a free country so you're welcome to believe that the presence or absence of NAT has no impact on the probability of a given machine being compromised. Of course, you're also welcome to join the flat earth society. As for me, the causative relationship between the rise of the DSL router implementing negligible security except NAT and the fall of port scanning as a credible attack vector seems blatant enough. Oddly enough, the drop in portscanning attacks maps even more closely to the shipping of XP SP2, which turned on the onboard firewall by default. Remember that some of the really big worm hits were when they managed to get loose inside corporate networks behind the NAT... Also, a NAT doesn't stop a Java or Adobe exploit in the least, as anybody with security clue will tell you pgpvpOLTHF9Gk.pgp Description: PGP signature
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Fri, 18 Jan 2013 09:03:31 -0500, William Herrin said: On the technical side, enterprises have been doing large-scale NAT for more than a decade now without any doomsday consequences. CGN is not different. Corporate enterprises have been pushing GPO to the desktop for more than a decade as well. Feel free to try to push GPO to Joe Sixpack's PC, let me know how that works out for you. pgp81csYx_pei.pgp Description: PGP signature
Re: Zero-Touch Deployment Remote Office solution?
I wrote to him privately.. But will post on the list too.. Meraki is pretty rad for doing just this. From my Android phone on T-Mobile. The first nationwide 4G network. Original message From: PC paul4...@gmail.com Date: 01/18/2013 11:34 AM (GMT-08:00) To: Matthew Craig matcr...@nmsu.edu Cc: nanog@nanog.org Subject: Re: Zero-Touch Deployment Remote Office solution? I handle this a different way. I'm not saying it's the easiest solution, but its very scalable to many thousands of endpoints. I take a small router and I set the WAN side to DHCP. I use client-intiated L2TP tunnels w/ ipsec protection to build a tunnel to the head end. The beauty of this is: 1) It works on any internet connection. NAT and dynamic IPs are not a problem. Since it's all UDP encapsulated and client intiated, they just need to supply internet access via DHCP. 2) It's stateful. The username/password defined on the remote client decides what IP block is routed to the client. All configuration is done from the head end based on the radius file. Routed IP blocks. Access lists. DNS settings. You name it. A report off the IP list data file builds the radius file. If PPP/IPCP and virtual-templating can do it, you are good. 4) It supports all your standard routing protocols, and multicast, if desired. 5) The only thing needing provisioning on the remote side is username/password. Configs are pre-seeded with a special username/password that provides enough access for the head office to login, change it to the final value, and reload. Now, I know there's several more mainstream solutions than this, and while this removes technical complexity from the branch office, it does add some to the headquarters. If you're looking for a more out of the box solution, Cisco has an EZ-VPN solution, amongst others. On Fri, Jan 18, 2013 at 10:41 AM, Matthew Craig matcr...@nmsu.edu wrote: We have a bunch of small remote offices where we deploy cheap routers with VPN tunnels back to the central office. This is a very static process with high overhead… we have to manage each remote router separately, and the offices do not have tech personnel that can handle local office issues. We're looking for a more centrally managed and automated zero-touch remote office solution, like the Cisco Virtual Office, where the local non-clueful people don't have to do much. http://www.cisco.com/en/US/netsol/ns855/index.html Does anyone have any experience / feeback for this Cisco Virtual Office solution or have recommendations for alternative solutions. - Matt
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Should NAT become prevalent and prevent innovation because of its limitations, this means that innovation will happen only with IPv6 which means the next must have viral applications will require IPv6 and this may spur the move away from an IPv4 that has been crippled by NAT everywhere.
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Fri, Jan 18, 2013 at 1:28 PM, Lee Howard l...@asgard.org wrote: Years ago, I asked, Why are we stuck with NAT? I still ask that. I believe that the reason we're stuck with it is that so many of us believe we're stuck with it--we're resigned to failure, so we don't do anything about it. Hi Lee, We're stuck with NAT because -enterprise- network security folks universally accept NAT's efficacy as a lynchpin component in their system security architecture. They accept it because the reasoning in support of the proposition makes sense and they consider the fact of its efficacy to have been satisfactorily demonstrated in practice. You can chase any other reasons for using NAT to the ends of the Earth and you'll never achieve a network where NAT's use can be discontinued. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
The Cidr Report
This report has been generated at Fri Jan 18 21:13:11 2013 AEST.
The report analyses the BGP Routing Table of AS2.0 router
and generates a report on aggregation potential within the table.
Check http://www.cidr-report.org for a current version of this report.
Recent Table History
Date PrefixesCIDR Agg
11-01-13440154 253400
12-01-13440403 253197
13-01-13440389 253276
14-01-13440516 253616
15-01-13440137 253644
16-01-13439836 253072
17-01-13439489 253809
18-01-13441174 253980
AS Summary
43157 Number of ASes in routing system
17954 Number of ASes announcing only one prefix
3104 Largest number of prefixes announced by an AS
AS6389 : BELLSOUTH-NET-BLK - BellSouth.net Inc.
115815136 Largest address span announced by an AS (/32s)
AS4134 : CHINANET-BACKBONE No.31,Jin-rong Street
Aggregation Summary
The algorithm used in this report proposes aggregation only
when there is a precise match using the AS path, so as
to preserve traffic transit policies. Aggregation is also
proposed across non-advertised address space ('holes').
--- 18Jan13 ---
ASnumNetsNow NetsAggr NetGain % Gain Description
Table 441433 253908 18752542.5% All ASes
AS6389 3104 126 297895.9% BELLSOUTH-NET-BLK -
BellSouth.net Inc.
AS28573 2267 79 218896.5% NET Servicos de Comunicao S.A.
AS4766 2939 937 200268.1% KIXS-AS-KR Korea Telecom
AS17974 2474 481 199380.6% TELKOMNET-AS2-AP PT
Telekomunikasi Indonesia
AS22773 1960 228 173288.4% ASN-CXA-ALL-CCI-22773-RDC -
Cox Communications Inc.
AS18566 2081 423 165879.7% COVAD - Covad Communications
Co.
AS10620 2290 673 161770.6% Telmex Colombia S.A.
AS2118 1432 49 138396.6% RELCOM-AS OOO NPO Relcom
AS7303 1670 400 127076.0% Telecom Argentina S.A.
AS4323 1605 400 120575.1% TWTC - tw telecom holdings,
inc.
AS4755 1668 555 111366.7% TATACOMM-AS TATA
Communications formerly VSNL
is Leading ISP
AS7029 2286 1275 101144.2% WINDSTREAM - Windstream
Communications Inc
AS7552 1149 172 97785.0% VIETEL-AS-AP Vietel
Corporation
AS18101 1016 170 84683.3% RELIANCE-COMMUNICATIONS-IN
Reliance Communications
Ltd.DAKC MUMBAI
AS8151 1540 719 82153.3% Uninet S.A. de C.V.
AS1785 1947 1163 78440.3% AS-PAETEC-NET - PaeTec
Communications, Inc.
AS4808 1125 352 77368.7% CHINA169-BJ CNCGROUP IP
network China169 Beijing
Province Network
AS13977 844 118 72686.0% CTELCO - FAIRPOINT
COMMUNICATIONS, INC.
AS18881 741 26 71596.5% Global Village Telecom
AS855718 52 66692.8% CANET-ASN-4 - Bell Aliant
Regional Communications, Inc.
AS35908 906 258 64871.5% VPLSNET - Krypt Technologies
AS17676 715 95 62086.7% GIGAINFRA Softbank BB Corp.
AS3356 1105 498 60754.9% LEVEL3 Level 3 Communications
AS22561 1048 445 60357.5% DIGITAL-TELEPORT - Digital
Teleport Inc.
AS24560 1037 437 60057.9% AIRTELBROADBAND-AS-AP Bharti
Airtel Ltd., Telemedia
Services
AS3549 1038 439 59957.7% GBLX Global Crossing Ltd.
AS19262 1001 405 59659.5% VZGNI-TRANSIT - Verizon Online
LLC
AS9808 609 38 57193.8% CMNET-GD Guangdong Mobile
Communication Co.Ltd.
AS36998 774 221 55371.4% SDN-MOBITEL
AS22047 583 31 55294.7% VTR BANDA ANCHA S.A.
Total 43672112653240774.2% Top 30 total
Possible Bogus Routes
10.86.64.32/30 AS65530
BGP Update Report
BGP Update Report Interval: 10-Jan-13 -to- 17-Jan-13 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASNUpds % Upds/PfxAS-Name 1 - AS982954752 3.5% 64.5 -- BSNL-NIB National Internet Backbone 2 - AS840248237 3.1% 30.1 -- CORBINA-AS OJSC Vimpelcom 3 - AS390941757 2.7%2783.8 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - AS462335104 2.2% 11701.3 -- CHEVALIER-AS01 Chevalier (Internet) Limited autonomous system #1 5 - AS755228799 1.8% 31.2 -- VIETEL-AS-AP Vietel Corporation 6 - AS29256 27702 1.8% 839.5 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 7 - AS163724934 1.6% 194.8 -- DNIC-AS-01637 - Headquarters, USAISC 8 - AS474822935 1.5%7645.0 -- RESOLINK-AS-AP Resources Link Network Limited 9 - AS17974 13524 0.9% 6.6 -- TELKOMNET-AS2-AP PT Telekomunikasi Indonesia 10 - AS27594 13181 0.8%6590.5 -- UTSA - University of Texas at San Antonio 11 - AS269711146 0.7% 105.2 -- ERX-ERNET-AS Education and Research Network 12 - AS671310941 0.7% 22.5 -- IAM-AS 13 - AS28573 10646 0.7% 9.8 -- NET Servicos de Comunicao S.A. 14 - AS845210543 0.7% 21.4 -- TE-AS TE-AS 15 - AS10620 10298 0.7% 8.0 -- Telmex Colombia S.A. 16 - AS4847 9793 0.6% 13.0 -- CNIX-AP China Networks Inter-Exchange 17 - AS7029 9146 0.6% 4.4 -- WINDSTREAM - Windstream Communications Inc 18 - AS5800 8311 0.5% 32.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 19 - AS2708 7484 0.5% 99.8 -- Universidad de Guanajuato 20 - AS6629 7434 0.5%7434.0 -- NOAA-AS - NOAA TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASNUpds % Upds/PfxAS-Name 1 - AS462335104 2.2% 11701.3 -- CHEVALIER-AS01 Chevalier (Internet) Limited autonomous system #1 2 - AS474822935 1.5%7645.0 -- RESOLINK-AS-AP Resources Link Network Limited 3 - AS6629 7434 0.5%7434.0 -- NOAA-AS - NOAA 4 - AS2033 7245 0.5%7245.0 -- PANIX - Panix Network Information Center 5 - AS27594 13181 0.8%6590.5 -- UTSA - University of Texas at San Antonio 6 - AS579182875 0.2%2875.0 -- ACOD-AS ACOD CJSC 7 - AS6174 5701 0.4%2850.5 -- SPRINTLINK8 - Sprint 8 - AS390941757 2.7%2783.8 -- QWEST-AS-3908 - Qwest Communications Company, LLC 9 - AS194064090 0.3%2045.0 -- TWRS-MA - Towerstream I, Inc. 10 - AS172933896 0.2%1948.0 -- VTXC - VTX Communications 11 - AS146805031 0.3%1677.0 -- REALE-6 - Auction.com 12 - AS6197 1463 0.1%1463.0 -- BATI-ATL - BellSouth Network Solutions, Inc 13 - AS9950 4011 0.3%1337.0 -- PUBNETPLUS2-AS-KR DACOM 14 - AS1562 1005 0.1%1005.0 -- DNIC-ASBLK-01550-01601 - DoD Network Information Center 15 - AS47316 924 0.1% 924.0 -- ENGINE-NETWORKS-AS Engine Networks S.R.L. 16 - AS53700 845 0.1% 845.0 -- DRANGRID - DRAN Grid Networks, LLC 17 - AS29256 27702 1.8% 839.5 -- INT-PDN-STE-AS Syrian Telecommunications Establishment 18 - AS33976 759 0.1% 759.0 -- AFTONBLADET-SE aftonbladet.se 19 - AS32753 734 0.1% 734.0 -- GLOBEOP-FINANCIAL-SERVICES-NYC1 - GlobeOp Financial Services 20 - AS2 714 0.1% 207.0 -- ORPL-AS-AP OrionVM Retail Pty Ltd TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 151.118.255.0/24 13855 0.8% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 2 - 151.118.254.0/24 13855 0.8% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 3 - 151.118.18.0/24 13801 0.8% AS3909 -- QWEST-AS-3908 - Qwest Communications Company, LLC 4 - 202.77.0.0/24 11702 0.7% AS4623 -- CHEVALIER-AS01 Chevalier (Internet) Limited autonomous system #1 5 - 202.77.1.0/24 11701 0.7% AS4623 -- CHEVALIER-AS01 Chevalier (Internet) Limited autonomous system #1 6 - 202.77.2.0/24 11701 0.7% AS4623 -- CHEVALIER-AS01 Chevalier (Internet) Limited autonomous system #1 7 - 203.161.4.0/22 9932 0.6% AS4748 -- RESOLINK-AS-AP Resources Link Network Limited 8 - 203.84.0.0/18 9930 0.6% AS4748 -- RESOLINK-AS-AP Resources Link Network Limited 9 - 202.41.70.0/24 8445 0.5% AS2697 -- ERX-ERNET-AS Education and Research Network 10 - 202.86.252.0/228290 0.5% AS4748 -- RESOLINK-AS-AP Resources Link Network Limited AS9304 -- HUTCHISON-AS-AP Hutchison Global Communications 11 - 192.58.232.0/247434 0.4% AS6629 -- NOAA-AS - NOAA 12 -
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On Fri, Jan 18, 2013 at 4:46 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: Should NAT become prevalent and prevent innovation because of its limitations, this means that innovation will happen only with IPv6 which means the next must have viral applications will require IPv6 and this may spur the move away from an IPv4 that has been crippled by NAT everywhere. It won't happen and I'll tell you why not. Client to client communication block diagrams: Without NAT: Client-Router-Router-Router-Router-Router-Client With NAT: Client-Router-Router-Relay-Router-Router-Client At a high level, the two communication diagrams are virtually identical. Add killer app. By it's nature, a killer app is something folks will pay good money for. This means that 100% of killer apps have sufficient funding to install those specialty relays. Odds of a killer app where one router can't be replaced with a specialty relay while maintaining the intended function: not bloody likely. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 13-01-18 17:00, William Herrin wrote: Odds of a killer app where one router can't be replaced with a specialty relay while maintaining the intended function: not bloody likely. Back in the late 1980s, large computer manufacturers such as Digital, HP, IBM were pressured to adopt the future in networking: OSI as transport and X.400 for emails. These stacks were eventually developped and implemented. However, the much simpler and more cost effective Internet ended up winning and it didn't take that long for governments to remove the requirements to be OSI compliant and accepted IPv4 and SMTP as the new standard. OSI and X.400 never gained much of a foothole and the millenium generation probably never heard of them. Is it possible that the same fate awaits IPv6 ? There is pressure to go to IPv6, but if solutions are found for IPv4 which are simpler and more easily deployed, won't that kill any/all efforts to move to IPv6 ?
Re: For those who may use a projector in the NOC
- Original Message - From: Eric Adler To: Michael Painter Cc: nanog@nanog.org Sent: Thursday, January 17, 2013 4:19 PM Subject: Re: For those who may use a projector in the NOC This appears to be an Epson / 3LCD marketing campaign. snip - Eric Adler Broadcast Engineer Hi Eric In case you didn't see it at the avs forum: Obviously brightness is only one metric, but a useful one if there is any ambient light or if you're going after a large screen. You might recognize my name.it's the one on the four page document highlighted above and available at www.colorlightoutput.com I'm a product manager for 3LCD. I'm a little surprised by the comments suggesting we were trying to hide the identity of 3LCD behind the site. Clearly the site doesn't scream3LCD.it wasn't supposed to. The Hero of the site is Color Light Output. The purpose is to provide information about this new measurement methodology.not present the technical details of 3LCD. I thought the 'feedback' page fairly well spells out who was behind it. That said, I will take these comments and make adjustment so that's it's clearer who is supporting the site. Regarding the projectors selected for testing in table 2 of the document. It is true that all of these projectors are single chip models with color wheels. Why is that? As Scott points out above, an RGB 3-path projector will always have equal parts of WLO and CLO. I know already how an NEC LCD projectors is going to perform. Only single chip projectors were tested in order to better understand how each Color Wheel design impacted CLO. I do admit that the list is heavily leaning towards the biz/ed side of the projection market.that's due to the makeup of sales volumes; only about 10% of projectors are sold into home theater. I hope, regardless of the company on my business card, that you'll agree with me that providing the customer this additional data is a good thing. My aim here is to get all manufacturers to list CLO as a supported metric.
Re: Intermittent incorrect DNS resolution?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/16/2013 7:16 PM, Jay Ashworth wrote: Just an FYI... Every version of Windows since Windows 2000 (sans Windows Me) has had the DNS Client service which maintained this caching function. This was by design due to the massive dependency on DNS resolution which Active Directory has had since its creation. It greatly reduced the amount of repetitive lookups required thereby speeding up AD based functions and lessening the load on DNS servers. It still exists today up through Windows 8. You can disable the service, but it will also break DDNS updates unless your DHCP server registers hostnames on behalf of your clients. - -Vinny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlD5z4wACgkQUyX7ywEAl3ojggCfb/ad2MZ9wp31M3g9zM89mHUo ODcAnjbgTCNV4Qr2fX8thhsj5jXIOiCu =xN4+ -END PGP SIGNATURE-
Re: Intermittent incorrect DNS resolution?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 1/16/2013 7:16 PM, Jay Ashworth wrote: - Original Message - From: Erik Levinson erik.levin...@uberflip.com I'm having an unusual DNS problem and would appreciate feedback. For the zones in question, primary DNS is provided by GoDaddy and secondary DNS by DNS Made Easy. Over a week ago we made changes to several A records (including wildcards on two different zones), all already having a TTL no greater than one hour. The new IPs on those A records have taken many millions of requests since the changes. Occasionally, a small amount of traffic appears at the old IPs that those A records had. This is HTTP traffic. Packet captures of this traffic show various Host headers. I'm a touch surprised to find that no one has mentioned the facet of Windows OSs that requires ipconfig /flushdns in some such circumstances... Not only may *browsers* be caching DNS lookups without regard to TTLs, the *OS* might be doing it to you too, in circumstances I was never quite able to get a handle on. XP was known to do this, as late as SP3; I'm not sure about V or 7. Just an FYI... Every version of Windows since Windows 2000 (sans Windows Me) has had the DNS Client service which maintained this caching function. This was by design due to the massive dependency on DNS resolution which Active Directory has had since its creation. It greatly reduced the amount of repetitive lookups required thereby speeding up AD based functions and lessening the load on DNS servers. It still exists today up through Windows 8. You can disable the service, but it will also break DDNS updates unless your DHCP server registers hostnames on behalf of your clients. - -Vinny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iEYEARECAAYFAlD5z5QACgkQUyX7ywEAl3q4BACgtzaKz1U2+kWn9ExJoQaNy7+s +mIAoLUjActGoFIKNUqzDDpdx14p/X/x =4qXs -END PGP SIGNATURE-
Re: Intermittent incorrect DNS resolution?
- Original Message - From: Vinny Abello vi...@abellohome.net Just an FYI... Every version of Windows since Windows 2000 (sans Windows Me) has had the DNS Client service which maintained this caching function. This was by design due to the massive dependency on DNS resolution which Active Directory has had since its creation. It greatly reduced the amount of repetitive lookups required thereby speeding up AD based functions and lessening the load on DNS servers. It still exists today up through Windows 8. You can disable the service, but it will also break DDNS updates unless your DHCP server registers hostnames on behalf of your clients. Microsoft broke the Internet just to make their internal networking work properly? I'm shocked; *shocked* I tell... yes, just put the money right over there; *shocked* I say. You can't imagine how much time that lost me in diagnoses when it first came out, until we finally located it somewhere on the Internet. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
Re: Intermittent incorrect DNS resolution?
On 1/18/2013 5:46 PM, Jay Ashworth wrote: - Original Message - From: Vinny Abello vi...@abellohome.net Just an FYI... Every version of Windows since Windows 2000 (sans Windows Me) has had the DNS Client service which maintained this caching function. This was by design due to the massive dependency on DNS resolution which Active Directory has had since its creation. It greatly reduced the amount of repetitive lookups required thereby speeding up AD based functions and lessening the load on DNS servers. It still exists today up through Windows 8. You can disable the service, but it will also break DDNS updates unless your DHCP server registers hostnames on behalf of your clients. Microsoft broke the Internet just to make their internal networking work properly? I'm shocked; *shocked* I tell... yes, just put the money right over there; *shocked* I say. You can't imagine how much time that lost me in diagnoses when it first came out, until we finally located it somewhere on the Internet. LOL... I don't know that they so much broke anything other than people's sanity and expectations. I can't say this with certainty, but I was always under the assumption that the DNS Client also respected TTL's of all RR's it cached. Maybe that was an incorrect assumption, but if that was correct then at most all they did was give everyone a caching stub resolver built into their OS. I don't feel this is much different than many *nix distributions installing BIND with a default recursive configuration and /etc/resolv.conf pointing to ::1 or 127.0.0.1... other than the obvious differences that it's doing recursion and you can *ASK* BIND what it's doing in a myriad of ways. That's always been my biggest gripe with the DNS Client. Either way, I wonder what the load on various DNS infrastructure throughout the world would look like if this mechanism didn't exist. I take it most recursive servers would just be answering a lot more queries from cache and burning cycles. For the record, Mac OS X also caches DNS queries. You can flush with the cache with dscacheutil -flushcache up through Snow Leopard, or using killall -HUP mDNSResponder via sudo or equivalent root rights on Lion and Mountain Lion. -Vinny
Re: Intermittent incorrect DNS resolution?
Jay Ashworth wrote: Microsoft broke the Internet just to make their internal networking work properly? I'm shocked; *shocked* I tell... yes, just put the money right over there; *shocked* I say. You can't imagine how much time that lost me in diagnoses when it first came out, until we finally located it somewhere on the Internet. Yeah, SUNW did it even before MSFT. Ever heard about 'nscd'?! It gets installed [but disabled by default] in any Linux distro derived from Red Hat Linux as well. If activated, will keep resolved records in an in-memory cache for an hour with all default settings. -- andrei
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 18 January 2013 14:00, William Herrin b...@herrin.us wrote: On Fri, Jan 18, 2013 at 4:46 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca wrote: Should NAT become prevalent and prevent innovation because of its limitations, this means that innovation will happen only with IPv6 which means the next must have viral applications will require IPv6 and this may spur the move away from an IPv4 that has been crippled by NAT everywhere. It won't happen and I'll tell you why not. Client to client communication block diagrams: Without NAT: Client-Router-Router-Router-Router-Router-Client With NAT: Client-Router-Router-Relay-Router-Router-Client At a high level, the two communication diagrams are virtually identical. Add killer app. By it's nature, a killer app is something folks will pay good money for. This means that 100% of killer apps have sufficient funding to install those specialty relays. Odds of a killer app where one router can't be replaced with a specialty relay while maintaining the intended function: not bloody likely. Regards, Bill Herrin The killer app of the internet is called p2p. Don't we already have a shortage of IPv4 addresses to start abandoning p2p, and requiring every service to be server-based, wasting extra precious IPv4 addresses? Where's the logic behind this: make it impossible for two computers to community directly because we have a shortage of addresses, yet introduce a third machine with, again, rather limited resources, to waste another IPv4 address? Wasting all kinds of extra resources and adding extra latency? That's not a killer app, that's the inefficiency of capitalism. C.
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 16 January 2013 08:12, fredrik danerklint fredan-na...@fredan.se wrote: From the article: Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage. http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carrier-grade-nat-instead-of-ipv6 I'm only here to bring you the news. So don't complain to me... It is obvious that implementing CGN requires a lot of extra resources and a lot of hardware/firmware support for both CPE and operator equipment (the latter from both technical and legal-compliance reasons, and both the former and the latter in order to implement some kind of UPnP-compatible support to still allow some kind of p2p apps to somehow function). And this is at a time when a lot of the world internet traffic has already moved to IPv6, and all major content providers that account for most of the traffic today already support native IPv6: Google, YouTube and FB. Wouldn't it be better instead of the untested, unscalable and dead-end IPv4 CGN to massively start implementing single-stacked IPv6 with NAT64 at the ISP and *464XLAT* within the CPE RG? (With 464XLAT, you wouldn't even need a potentially troublesome DNS64.) This way, instead of having to account for subscriber growth presenting scalability issues on your limited IPv4 resources and CGN-related concerns, you can instead account for the content growth of IPv6-enabled sites, and, basically, have to plan for just about no extra IPv4 scaling budget whatsoever, since with every X subscribers that still need IPv4, you'll have every XX old subscribers that will be moving closer to being IPv6-only. And with every year, a single IPv4 address used for NAT64 will be perfectly able to scale up to serve more and more customers, since fewer and fewer people will need IPv4 connections. So: With CGN, we get to the same old chicken-and-egg story: lack of IPv6 deployment and content/app support, yet an even more imminent shortage of IPv4 addresses (and with every new customer you'll be so much more closer to it) and the scalability and legal issues. With 464XLAT on the CPE RG and NAT64 at the carrier instead, you get all the benefits of CGN (namely, all non-p2p IPv4-only apps and services will still work perfectly fine), but only a couple of the drawbacks. And it'll actually put the correct pressure for both content and application developers to immediately switch to IPv6, and avoid you, the operator, from having to be spending the extra resources and having extra headaches on the IPv4 address shortage. It really makes no sense that any company would still want to invest a single dime into CGN when instead they could be investing in IPv6 with NAT64 and CPE RGs with 464XLAT. I honestly think that 464XLAT can potentially solve all the chicken and egg problems that the big players have been having. Supposedly, that's how T-Mobile USA is planning to move their network forward. (I'm certainly looking towards the day when I could finally enable IPv6 on a Google Nexus on T-Mo.) On the other hand, it's really strange that 464XLAT is so brand bloody new when IPv6 itself, as well as even NAT64 and DNS64, have been there for ages. The idea of 464XLAT is just so ingeniously straight and simple! Somewhat similar to 6rd, I guess. I think that instead of any kind of CGN, all residential (and mobile) broadband connections should be IPv6-only with NAT64 and 464XLAT. That'll basically solve all the actual problems with one stone: lack of IPv6 deployment from content publishers and IPv6 application support (from app developers with no IPv6), and the immediate shortage of the IPv4 addresses. Cheers, Constantine.
Re: Fwd: Mark Crispin - MRC - Inventor of IMAP and a friend for decades, has died at 56
On 01/08/2013 08:36 AM, Rich Kulawiec wrote: - Forwarded message from Lauren Weinsteinlau...@vortex.com - Date: Mon, 7 Jan 2013 10:35:59 -0800 From: Lauren Weinsteinlau...@vortex.com To: nnsq...@nnsquad.org Subject: [ NNSquad ] Mark Crispin - MRC - Inventor of IMAP and a friend for decades, has died at 56 Mark Crispin - MRC - Inventor of IMAP and a friend for decades, has died at 56 Lauren was also kind enough to provide a link to a posting on Google+ which provides more information: https://plus.google.com/114753028665775786510/posts/4YvWfnneTyN Mark did an awful, awful lot for all of us and for huge numbers of people who'll never know his name. Thanks for that, only just read it now... I fully agree and am saddened by his death. I enjoyed reading his insightful emails (and occasional email exchanges with him). He wasn't afraid of expressing a strong opinion, supported by valid arguments and facts. I will miss that. Jeroen -- Earthquake Magnitude: 4.6 Date: Friday, January 18, 2013 14:05:53 UTC Location: Unimak Island region, Alaska Latitude: 53.9296; Longitude: -163.2348 Depth: 11.60 km
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
Constantine, On Fri, Jan 18, 2013 at 6:56 PM, Constantine A. Murenin muren...@gmail.com wrote: On 16 January 2013 08:12, fredrik danerklint fredan-na...@fredan.se wrote: From the article: Faced with the shortage of IPv4 addresses and the failure of IPv6 to take off, British ISP PlusNet is testing carrier-grade network address translation CG-NAT, where potentially all the ISP's customers could be sharing one IP address, through a gateway. The move is controversial as it could make some Internet services fail, but PlusNet says it is inevitable, and only a test at this stage. http://tech.slashdot.org/story/13/01/16/1417244/uk-isp-plusnet-testing-carrier-grade-nat-instead-of-ipv6 I'm only here to bring you the news. So don't complain to me... It is obvious that implementing CGN requires a lot of extra resources and a lot of hardware/firmware support for both CPE and operator equipment (the latter from both technical and legal-compliance reasons, and both the former and the latter in order to implement some kind of UPnP-compatible support to still allow some kind of p2p apps to somehow function). And this is at a time when a lot of the world internet traffic has already moved to IPv6, and all major content providers that account for most of the traffic today already support native IPv6: Google, YouTube and FB. Wouldn't it be better instead of the untested, unscalable and dead-end IPv4 CGN to massively start implementing single-stacked IPv6 with NAT64 at the ISP and *464XLAT* within the CPE RG? (With 464XLAT, you wouldn't even need a potentially troublesome DNS64.) This way, instead of having to account for subscriber growth presenting scalability issues on your limited IPv4 resources and CGN-related concerns, you can instead account for the content growth of IPv6-enabled sites, and, basically, have to plan for just about no extra IPv4 scaling budget whatsoever, since with every X subscribers that still need IPv4, you'll have every XX old subscribers that will be moving closer to being IPv6-only. And with every year, a single IPv4 address used for NAT64 will be perfectly able to scale up to serve more and more customers, since fewer and fewer people will need IPv4 connections. So: With CGN, we get to the same old chicken-and-egg story: lack of IPv6 deployment and content/app support, yet an even more imminent shortage of IPv4 addresses (and with every new customer you'll be so much more closer to it) and the scalability and legal issues. With 464XLAT on the CPE RG and NAT64 at the carrier instead, you get all the benefits of CGN (namely, all non-p2p IPv4-only apps and services will still work perfectly fine), but only a couple of the drawbacks. And it'll actually put the correct pressure for both content and application developers to immediately switch to IPv6, and avoid you, the operator, from having to be spending the extra resources and having extra headaches on the IPv4 address shortage. It really makes no sense that any company would still want to invest a single dime into CGN when instead they could be investing in IPv6 with NAT64 and CPE RGs with 464XLAT. Brilliant so far ... I honestly think that 464XLAT can potentially solve all the chicken and egg problems that the big players have been having. Supposedly, that's how T-Mobile USA is planning to move their network forward. (I'm certainly looking towards the day when I could finally enable IPv6 on a Google Nexus on T-Mo.) OK... i am wading into dangerous territory now: Why are you waiting? This page has the 464XLAT software and procedure for Nexus S, Galaxy Nexus, as well as apk for any rooted Android that can handle IPv6 on cellular http://dan.drown.org/android/clat/ Or for the more pure IPv6-only NAT64/DNS64 out-of-the-box experience https://sites.google.com/site/tmoipv6/lg-mytouch On the other hand, it's really strange that 464XLAT is so brand bloody new when IPv6 itself, as well as even NAT64 and DNS64, have been there for ages. The idea of 464XLAT is just so ingeniously straight and simple! Somewhat similar to 6rd, I guess. Well, i certainly fought it as long as i could. I was really drinking the Kool-Aid that apps that could not support IPv6 would be de-selected since they were unfit for the internet. I figured evolution would win, but inertia was certainly making things too slow, thus we needed a way to make IPv4-apps (cough cough Skype, Netflix Android App, ...) work on IPv6. I think that instead of any kind of CGN, all residential (and mobile) broadband connections should be IPv6-only with NAT64 and 464XLAT. That'll basically solve all the actual problems with one stone: lack of IPv6 deployment from content publishers and IPv6 application support (from app developers with no IPv6), and the immediate shortage of the IPv4 addresses. Cheers, Constantine. Rock on. I have been on IPv6-only + NAT64/DNS64 for 2 years on mobile full-time, works fine
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
There is no suckerage to V6. Really, it's not that hard. While CGN is the reality, we need to keep focused on the ultimate goal -- a single long term solution. Imagine a day where there is no dual stack, no IPv4, and no more band-aids. It will be amazing. david. On Fri, Jan 18, 2013 at 9:48 AM, Joe Maimon jmai...@ttec.com wrote: Lee Howard wrote: You are welcome to deploy it if you choose to. Part of the reason I'm arguing against it is that if everyone deploys it, then everyone has to deploy it. If it is seen as an alternative to IPv6 by some, then others' deployment of IPv6 is made less useful: network effect. Also, spending money on CGN seems misguided; if you agree that you're going to deploy IPv6 anyway, why spend the money for IPv6 *and also* for CGN? Lee Suppose a provider fully deploys v6, they will still need CGN so long as they have customers who want to access the v4 internet. Unfortunately, that may have the side effect of undercutting some portion of v6's value proposition, inversely related to its suckage. Joe
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 01/18/2013 02:07 PM, Jean-Francois Mezei wrote: OSI and X.400 never gained much of a foothole and the millenium generation probably never heard of them. Is it possible that the same fate awaits IPv6 ? There is pressure to go to IPv6, but if solutions are found for IPv4 which are simpler and more easily deployed, won't that kill any/all efforts to move to IPv6 ? No, because NAT-like solutions to perpetuate v4 only handle the client side of the transaction. At some point there will not be any more v4 address to assign/allocate to content provider networks. They have seen the writing on the wall, and many of the largest (both by traffic and market share) have already moved to providing their content over v6. Doug
Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6
On 19 January 2013 04:48, Doug Barton do...@dougbarton.us wrote: No, because NAT-like solutions to perpetuate v4 only handle the client side of the transaction. At some point there will not be any more v4 address to assign/allocate to content provider networks. They have seen the writing on the wall, and many of the largest (both by traffic and market share) have already moved to providing their content over v6. Potentially another source of IPv4 addresses - every content network (/hosting provider/etc) that decides they don't want to give their customers IPv6 reachability is a future bankrupt ISP with a load of IPv4 to sell off :) - Mike
Re: Device specifically made for high capacity GRE tunnels for dozens of sites
Another (somewhat cheaper) Juniper option if you meet its limits is the EX[34]200's which now do GRE in hardware: http://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/gre-tunnel-services.html On 19/01/13 05:36, PC wrote: mx80 (or similar) or ASR. The MX would probably be my preference for just pushing huge amounts of GRE packets and scales nicely in a single box solution. On Fri, Jan 18, 2013 at 11:21 AM, Christopher Morrow morrowc.li...@gmail.com wrote: On Fri, Jan 18, 2013 at 12:51 PM, A. Pishdadi apishd...@gmail.com wrote: Hello, Can anyone recommend a device that will allow for multiple gigabit gre tunnels with ability to handle up to a million pps? I know it can be done on a bsd or nix box , or something running junos but Im looking for something specifically made and tailored for GRE tunnels. dedicate an MPC on an MX box? 10gbps of gre, weee!
