Re: Weekend Gedankenexperiment - The Kill Switch
No - at least some links were still up. I saw both IPVPNs and leased lines still working during the event. aj -Original Message- From: Ryan Finnesey ryan.finne...@harrierinvestments.com Date: Sat, 5 Feb 2011 23:58:35 To: Fred Bakerf...@cisco.com; Hayden Katzenellenbogenhay...@nextlevelinternet.com Cc: NANOG listnanog@nanog.org Subject: RE: Weekend Gedankenexperiment - The Kill Switch Does anyone know when they took down connectivity in Egypt did they also bring down the MPLS networks global companies use? Cheers Ryan -Original Message- From: Fred Baker [mailto:f...@cisco.com] Sent: Saturday, February 05, 2011 9:43 AM To: Hayden Katzenellenbogen Cc: NANOG list Subject: Re: Weekend Gedankenexperiment - The Kill Switch On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: Not sure if it has been said already but wasn't one of the key point for the creation of the internet to create and infrastructure that would survive in the case of all out war and massive destruction. (strategic nuclear strikes) Urban legend, although widely believed. Someone probably made the observation. Does it not bode ill for national security if any party could take out a massive communication system by destroying/pressuring a few choke points? You mean, like drop a couple of trade towers and take out three class five switches, causing communication outages throughout New England and New Jersey, and affecting places as far away as Chicago? Nope. Couldn't happen. More seriously, yes, one could in fact take out any connectivity one wants by withdrawing routes (which is reportedly what Egypt did), and if you hit enough interchange points that could get serious. At the risk of sounding naive and pollyanna-ish, we have a few more of those interchange points in the US than they have in Egypt. In theory, yes. Making it actually happen could be quite an operation. -Original Message- From: JC Dill [mailto:jcdill.li...@gmail.com] Sent: Thursday, February 03, 2011 11:39 PM To: NANOG list Subject: Re: Weekend Gedankenexperiment - The Kill Switch On 03/02/11 10:38 PM, Paul Ferguson wrote: And as an aside, governments will always believe that that they can control the flow of information, when push comes to shove. This has always been a hazard, and will always continue to be so. As technologists, we need to be cognizant of that fact. In the US, by accident (surely not by design) we are lucky that our network of networks does not have the convenient 4 chokepoints that the Egyptian network had, making it easy for the government to shut off the entier internet by putting pressure on just 4 companies. Where we *really* need to be fighting this battle is in the laws and policies that are producing a duopoly in much of the US where consumers have 2 choices, the ILEC for DSL or their local cableco for Cable Internet. As theses companies push smaller competing ISPs out of business, and as they consolidate (e.g. Cablecos buying each other up, resulting in fewer and fewer cablecos over time), we head down the direction of Egypt, where pressure on just a few companies CAN shut down the entire internet. Otherwise we end up with a few companies that will play Visa and PayPal and roll over and play dead when a government official says Wikileaks is bad - and equally easily will shut down their entire networks for national security. If you *really* believe that the TSA is effective, you would be in favor of an Internet Kill Switch. If you understand that this is really security theater, and despite all the inconvenience we aren't really any safer, then you should equally be very concerned that someone ever has the power to order that the internet be shut down for our safety. jc
RE: Post-Exhaustion-phase punishment for early adopters
-Original Message- From: Jimmy Hess [mailto:mysi...@gmail.com] The most important thing to ensure usage is recognized is that the entire address space is announced plus routed, I don't speak on behalf of a community, but in the past there have been people reminding the ARIN community that there are valid uses for address space, contemplated by rfc2050, in addition to routing on the public Internet. You might look into the option of signing the Legacy RSA: https://www.arin.net/resources/legacy/ Available until Dec 2011; If your allocation predated ARIN. Yes. You might decide you don't like some provision, but it would be careless not to look into it. I doubt the community is going to scour through all the /24 allocations and try to reclaim them, however. It's not that legacy /24 allocations don't matter, if they are entirely derelict, but the /8s are the ones that sort of matter... sort of, because a /8 reclaimed could provide a few months of IP addresses for a RIR. Agree; according to https://www.arin.net/knowledge/statistics/index.html ARIN has been issuing 20,000 - 50,000 /24 per month for the past few months. A /24 wouldn't extend runout time by a full minute. It's not likely but conceivable, that the RIRs could decide to make a policy of reviewing legacy resources and revoking allocations with bad contact info, or apply an efficient usage criterion requiring return/renumbering, for legacy resource holders who have no RSA. That would be an exciting debate. Lee
RE: quietly....
The end-to-end model is about If my packet is permitted by policy and delivered to the remote host, I expect it to arrive as sent, without unexpected modifications. Well, it's about communications integrity being the responsibility of the endpoint. It is therefore expected that the network not mess with the communication. See http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf Nobody wants to get rid of firewalls. Several people want to get rid of firewalls. Consistent with the end-to-end principle, hosts should provide their own policy enforcement. See expired draft-vyncke-advanced-ipv6-security-01 Unfortunately, the approach described doesn't work in state-of-the-art residential CPE, and relies heavily on endpoint security protection, which is weak in most Internet hosts. We want to get rid of NAT. Firewalls work great without NAT and by having firewalls without NAT, we gain back the end-to-end model while preserving the ability to enforce policy on end-to-end connectivity. I would rather see hosts protect themselves from badness, and network security appliances be limited to protecting against network threats (a DDOS is a network threat; a service DOS is an application threat). NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more difficult that turning on a firewall does. It doesn't break anything that isn't trying to announce itself - and imo, applications that want to announce themselves seem like a pretty big security hole. Service discovery is an Internet weakness. NAT does destroy end-to-end. Firewalls do not. Firewalls merely constrict it. Not that I advocate against the use of firewalls; in fact, I think I'm agreeing with you, and extending the argument a little further, that we should move from NAT to firewalls, then from stateful firewalls to secure hosts and network security appliances. Lee
Re: quietly....
sure From: Lee Howard l...@asgard.org To: Owen DeLong o...@delong.com; david raistrick dr...@icantclick.org Cc: nanog@nanog.org Sent: Sun, February 6, 2011 2:16:35 PM Subject: RE: quietly The end-to-end model is about If my packet is permitted by policy and delivered to the remote host, I expect it to arrive as sent, without unexpected modifications. Well, it's about communications integrity being the responsibility of the endpoint. It is therefore expected that the network not mess with the communication. See http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf Nobody wants to get rid of firewalls. Several people want to get rid of firewalls. Consistent with the end-to-end principle, hosts should provide their own policy enforcement. See expired draft-vyncke-advanced-ipv6-security-01 Unfortunately, the approach described doesn't work in state-of-the-art residential CPE, and relies heavily on endpoint security protection, which is weak in most Internet hosts. We want to get rid of NAT. Firewalls work great without NAT and by having firewalls without NAT, we gain back the end-to-end model while preserving the ability to enforce policy on end-to-end connectivity. I would rather see hosts protect themselves from badness, and network security appliances be limited to protecting against network threats (a DDOS is a network threat; a service DOS is an application threat). NAT doesn't destroy end-to-end. It just makes it slightly more difficult. But no more difficult that turning on a firewall does. It doesn't break anything that isn't trying to announce itself - and imo, applications that want to announce themselves seem like a pretty big security hole. Service discovery is an Internet weakness. NAT does destroy end-to-end. Firewalls do not. Firewalls merely constrict it. Not that I advocate against the use of firewalls; in fact, I think I'm agreeing with you, and extending the argument a little further, that we should move from NAT to firewalls, then from stateful firewalls to secure hosts and network security appliances. Lee
Top webhosters offering v6 too?
Which of the big boys are doing it? Tim
Re: Weekend Gedankenexperiment - The Kill Switch
do you have a satellite dish? what are your dish pointing coordinates..we just need to find out what is going on the air interface ... From: Ryan Wilkins r...@deadfrog.net To: Jay Ashworth j...@baylink.com Cc: NANOG nanog@nanog.org Sent: Fri, February 4, 2011 4:46:47 AM Subject: Re: Weekend Gedankenexperiment - The Kill Switch On Feb 3, 2011, at 10:10 PM, Jay Ashworth wrote: Original Message - What do you do when you get home to put it back on the air -- let's say email as a base service, since it is -- do you have the gear laying around, and how long would it take? Focus on this part, BTW, folks; let's ignore the politics behind the shutdown. :-) So if I get what you're saying, I could have something operational from scratch in a few hours. I've got a variety of Cisco routers and switches, Linux and Mac OS X boxes in various shapes and sizes, and a five CPE + one AP 5 GHz Mikrotik RouterOS-based radio system, 802.11b/g wireless AP, 800' of Cat 5e cable, connectors, and crimpers. The radios, if well placed, could allow me to connect up several strategic locations, or perhaps use them to connect to other sources of Internet access, if available. If it really came down to it, I could probably gather enough satellite communications gear from the office to allow me to stand up satellite Internet to someone. Of course, the trick would be to talk to that someone to coordinate connectivity over the satellite which may be hard to do given the communications outage you described. I wouldn't be so worried about transmitting to the satellite, in this case I'd just transmit without authorization, but someone needs to be receiving my transmission and vice versa for this to be useful. At a minimum, I could enable communications between my neighbors. Regards, Ryan Wilkins
Re: Using IPv6 with prefixes shorter than a /64 on a LAN
On 2/5/2011 11:57 PM, Mark Andrews wrote: Rationalising to power of 2 allocations shouldn't result in requiring 256 times the space you were claiming with the 8 bits of shift on average. A couple of bits will allow that. I didn't claim 8 bit average (if I accidentally did, my apologies). I claimed a minimum of 8 bits. Somewhere between 12 and 16 is more likely. However, with new ARIN proposals, we will see shorter shifts (yet still over 8 bit shifts) as it does nibble allocations for everything (pop assignments nibble aligned, ISP allocations nibble aligned, ISP to ISP reallocation policies). It treats utilization as a 75% bar with nibble alignments to allow for proper growth at the ISP level. So for me, my /30 will at least expand out to a /28, though I will have to reanalyze the pop allocations with the new rules, as it's possible I may bump to a /24 (if I end up expanding to a /27 of actual current usage). You need to look very closely at any ISP that only shifts 8 bits going from IPv4 to IPv6, something dodgy is probably going on. This is not to say it is deliberately dodgy. Currently, I agree. It should be between 12 and 16 normally. However, new policy proposals are designed in such a way that the bit shift may only be 8. However, this also depends on the ISP. As ISPs do look towards dropping v4 in priority, they will also look at redesigning some of their pop layouts. This is actually a case for me. Due to growth and utilization issues on IPv4, I've concentrated pops into supernodes to better utilize the v4 I have (95% utilization of pools which cover much larger customer sets, versus a bunch of smaller utilized pools which have less utilization rates as the pops don't grow at the same rate). However, I have areas this is reaching a critical point, and the IPv6 model is dividing up into smaller pop nodes. Since I don't have address space concerns for IPv6, structuring the network and customer termination into a better layout is more appropriate. What's more, in most cases, I can accomplish v4 supernodes and v6 separation at the same time; and I'll see the benefits as more customers shift to actual v6 connectivity. Jack
Re: Weekend Gedankenexperiment - The Kill Switch
- Original Message - From: isabel dias isabeldi...@yahoo.com do you have a satellite dish? what are your dish pointing coordinates..we just need to find out what is going on the air interface ... Well, either iDirect or SCPC... Cheers, -- jra
What's really needed is a routing slot market (was: Using IPv6 with prefixes shorter than a /64 on a LAN)
On Feb 5, 2011, at 9:40 PM, Mark Andrews wrote: What's really needed is seperate the routing slot market from the address allocation market. Bingo! In fact, having an efficient market for obtaining routing of a given prefix, combined with IPv6 vast identifier space, could actually satisfy the primary goals that we hold for a long-term scalable address architecture, and enable doing it in a highly distributed, automatable fashion: Aggregation would be encouraged, since use of non-aggregatable address space would entail addition costs. These costs might be seen as minimal for some organizations that desire addressing autonomy, but others might decide treating their address space portable and routable results in higher cost than is desired. Decisions about changing prefixes with ISPs can be made based on a rational tradeoff of costs, rather than in a thicket of ISP and registry policies. Conservation would actually be greatly improved, since address space would only be sought after because of the need for additional unique identifiers, rather than obtaining an address block of a given size to warrant implied routability. In light of IPv6's vast address space, it actually would be possible to provide minimally-sized but assured unique prefixes automatically via nearly any mechanism (i.e. let your local user or trade association be a registry if they want) With a significantly reduced policy framework, Registration could be fully automated, with issuance being as simple as assurance the right level of verification of requester identity (You might even get rid of this, if you can assure that ISPs obtain clear identity of clients before serving them but that would preclude any form of reputation systems based on IP address prefix such as we have in use today...) Just think: the savings in storage costs alone (from the reduction in address policy-related email on all our mailing lists) could probably fund the system. :-) Oh well, one project at a time... /John
Re: quietly....
Firewalls merely constrict it. Not that I advocate against the use of firewalls; in fact, I think I'm agreeing with you, and extending the argument a little further, that we should move from NAT to firewalls, then from stateful firewalls to secure hosts and network security appliances. Lee I would be fine with that. However, in terms of the art of the possible with the tools available today, IPv6 has no need of NAT, but, firewalls cannot yet be safely removed from the equation. Owen
Re: Top webhosters offering v6 too?
Tim Chown writes: Which of the big boys are doing it? Google - although there don't call themselves a web hoster, they can be used for hosting web sites using services such as Sites or App Engine. Both support IPv6, either using the opt-in mechanism or by using an alternate CNAME (ghs46 instead of ghs.google.com). That's what I use. None of the other large cloud providers seems to support IPv6 for their users yet. In particular, neither Amazon's AWS not Microsoft Azure have much visible activity in this direction. Rackspace have announced IPv6 support for the first half of 2011. Concerning the more traditional webhosting offerings, I have no idea about the big boys. Here in Switzerland, a few smaller hosters support IPv6. And I saw IPv6 mentioned in ads for some German server hosting offering. Germany is interesting because it has a well-developed hosting ecosystem with some really big players. -- Simon.
Re: Top webhosters offering v6 too?
I ran across this link a while back, it shows, of the top 100k websites (according to Alexa), which ones are IPv6 enabled: http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=true On Sun, Feb 6, 2011 at 11:43 AM, Simon Leinen simon.lei...@switch.ch wrote: Tim Chown writes: Which of the big boys are doing it? Google - although there don't call themselves a web hoster, they can be used for hosting web sites using services such as Sites or App Engine. Both support IPv6, either using the opt-in mechanism or by using an alternate CNAME (ghs46 instead of ghs.google.com). That's what I use. None of the other large cloud providers seems to support IPv6 for their users yet. In particular, neither Amazon's AWS not Microsoft Azure have much visible activity in this direction. Rackspace have announced IPv6 support for the first half of 2011. Concerning the more traditional webhosting offerings, I have no idea about the big boys. Here in Switzerland, a few smaller hosters support IPv6. And I saw IPv6 mentioned in ads for some German server hosting offering. Germany is interesting because it has a well-developed hosting ecosystem with some really big players. -- Simon. -- Fred
Re: What's really needed is a routing slot market
On 2/6/11 8:00 AM, John Curran wrote: On Feb 5, 2011, at 9:40 PM, Mark Andrews wrote: What's really needed is seperate the routing slot market from the address allocation market. Bingo! In fact, having an efficient market for obtaining routing of a given prefix, combined with IPv6 vast identifier space, could actually satisfy the primary goals that we hold for a long-term scalable address architecture, and enable doing it in a highly distributed, automatable fashion: So assuming this operates on a pollution model the victims of routing table bloat are compensated by the routing table pollutors for the use of the slots which they have to carry. so I take the marginal cost of the slots that I need subtract the royalities I recieve from the other participants and if I'm close to the mean number of slots per participant then it nets out to zero. Routing table growth continues but with some illusion of fairness and the cost of maintaining an elaborate system which no-one needs. Yay? Aggregation would be encouraged, since use of non-aggregatable address space would entail addition costs. These costs might be seen as minimal for some organizations that desire addressing autonomy, but others might decide treating their address space portable and routable results in higher cost than is desired. Decisions about changing prefixes with ISPs can be made based on a rational tradeoff of costs, rather than in a thicket of ISP and registry policies. Conservation would actually be greatly improved, since address space would only be sought after because of the need for additional unique identifiers, rather than obtaining an address block of a given size to warrant implied routability. In light of IPv6's vast address space, it actually would be possible to provide minimally-sized but assured unique prefixes automatically via nearly any mechanism (i.e. let your local user or trade association be a registry if they want) With a significantly reduced policy framework, Registration could be fully automated, with issuance being as simple as assurance the right level of verification of requester identity (You might even get rid of this, if you can assure that ISPs obtain clear identity of clients before serving them but that would preclude any form of reputation systems based on IP address prefix such as we have in use today...) Just think: the savings in storage costs alone (from the reduction in address policy-related email on all our mailing lists) could probably fund the system. :-) Oh well, one project at a time... /John
Re: Top webhosters offering v6 too?
I have used both softlayer and arpnetworks. Both have v6 by default, but only softlayer can be considered a big boy... multiple sites. Cloud and dedicated servers ... softlayer is a class act with v6 added for free
Re: What's really needed is a routing slot market
On Feb 6, 2011, at 12:15 PM, Joel Jaeggli wrote: So assuming this operates on a pollution model the victims of routing table bloat are compensated by the routing table pollutors for the use of the slots which they have to carry. so I take the marginal cost of the slots that I need subtract the royalities I recieve from the other participants and if I'm close to the mean number of slots per participant then it nets out to zero. Routing table growth continues but with some illusion of fairness and the cost of maintaining an elaborate system which no-one needs. One hopes that the costs of consuming routing table slots creates backpressure to discourage needless use, and that the royalities receive offset the costs of carrying any additional routing table slots. Note that our present system lacks both consistent backpressure on consumption of routing table slots and compensation for carrying additional routes. /John p.s. While I do believe there would be a net benefit, it also should be noted that there is no apparent way to transition to such a model in any case, i.e., it could have been done that way from the beginning, but a large scale economic reengineering effort at this point might be impossible.
Re: quietly....
In article 85d304ba-6c4e-4b86-9717-2adb542b8...@delong.com, Owen DeLong o...@delong.com writes Part of the problem is knowing in advance what ISPs will and won't do. It's all very well saying one shouldn't patronise an ISP that blocks port 25, for example, but where is that documented before you buy? If they don't document partial internet access blockage in the contract and the contract says they are providing internet access, then, they are in breach and you are free to depart without a termination fee and in most cases, demand a refund for service to date. You may be right about enforcing that in the USA (is it an FCC thing?), but it won't fly in most other places. Admittedly, I'm not over-fussed about email on my phone and I don't use a tether device at this point. The 3G I'm discussing is a dongle intended for general access. I mostly expect 3G and 4G networks to be broken internet anyway. I was more speaking in terms of land-line providers. Apparently there are something like three times as many people with mobile phones in the world, as with Internet access. And a lot of network expansion is expected to be based on mobile connectivity as a result. -- Roland Perry
Re: What's really needed is a routing slot market
On 2/6/11 9:32 AM, John Curran wrote: One hopes that the costs of consuming routing table slots creates backpressure to discourage needless use, and that the royalities receive offset the costs of carrying any additional routing table slots. Note that our present system lacks both consistent backpressure on consumption of routing table slots and compensation for carrying additional routes. The costs of carrying routes is unevenly distributed. when I have to carry 2 million routes in my fib on few hundred 120Gb/s line cards it's a bit different than someone with a software router who just has to make sure they have 4GB of ram... That has very attractive properties along some dimensions. e.g. the cost at the margin of connecting a new participant to the internet is rather low.
Re: quietly....
In article 20110205131510.be13e9b5...@drugs.dv.isc.org, Mark Andrews ma...@isc.org writes And when my vendor is Sipura, or Sony[1], how does an individual small enterprise attract their attention and get the features added? You return the equipment as not suitable for the advertised purpose and demand your money back. Renumbering is expected to occur with IPv6, part of renumbering is getting the name to address mappings right. With DHCP the DHCP server normally does it. With SLAAC the host has to do it as there is no other choice. Here in Australia it is Repair/Replace/Refund if the product purchased is faulty. That applies to all products. If the milk is off when we get home we go back and get it replaced and if the store is out of stock we get a refund. I've returned and had replaced plenty of stuff over the years. I think you are just confirming my view that moving from IPv4 to IPv6 will involve more than the ISP doing some magic that's transparent to the majority of users. And good luck returning a 3 year old PS/3 for a refund on the basis it doesn't support IPv6. -- Roland Perry
Re: quietly....
On Feb 6, 2011, at 9:49 AM, Roland Perry wrote: In article 20110205131510.be13e9b5...@drugs.dv.isc.org, Mark Andrews ma...@isc.org writes And when my vendor is Sipura, or Sony[1], how does an individual small enterprise attract their attention and get the features added? You return the equipment as not suitable for the advertised purpose and demand your money back. Renumbering is expected to occur with IPv6, part of renumbering is getting the name to address mappings right. With DHCP the DHCP server normally does it. With SLAAC the host has to do it as there is no other choice. Here in Australia it is Repair/Replace/Refund if the product purchased is faulty. That applies to all products. If the milk is off when we get home we go back and get it replaced and if the store is out of stock we get a refund. I've returned and had replaced plenty of stuff over the years. I think you are just confirming my view that moving from IPv4 to IPv6 will involve more than the ISP doing some magic that's transparent to the majority of users. And good luck returning a 3 year old PS/3 for a refund on the basis it doesn't support IPv6. -- Roland Perry I'm pretty sure the PS3 will get resolved through a software update. Yes, there will be user-visible disruptions in this transition. No, it can't be 100% magic on the part of the service provider. It still has to happen. There is no viable alternative. Owen
Re: quietly....
- Original Message - From: Owen DeLong o...@delong.com I'm pretty sure the PS3 will get resolved through a software update. Yes, there will be user-visible disruptions in this transition. No, it can't be 100% magic on the part of the service provider. It still has to happen. There is no viable alternative. There will be *lots* of user visible disruptions. And if you believe, as it appears you do from the integration of your messages on this thread, that anyone anywhere will be able through any legal theory to *force* Sony to make that older PS3 work on IPv6, then the term for your opinion, in *my* opinion, has changed from optimistic to nutsabago. :-) From up here at 30,000ft, the entire deployment of IPv6 has been cripplingly mismanaged, or we wouldn't be having all these conversations, still, now. Having had them 5 years ago would have been well more than good enough. And it will start to bite, hard, very shortly. Cheers, -- jra
Re: What's really needed is a routing slot market
On Sun, Feb 6, 2011 at 11:15 AM, Joel Jaeggli joe...@bogus.com wrote: So assuming this operates on a pollution model the victims of routing table bloat are compensated by the routing table pollutors for the use of the slots which they have to carry. so I take the marginal cost of In this case the victims are the other ASes, and the pollutors are the ASes that announce lots of blocks. However, the pollution is also something the victims need, so it's not really pollution at all, unless an excessive number of slots are used it's more meat than trash, the pollution model doesn't exactly make sense; the basic announced routes for connectivity are not like pollution. They are more like fertilizer... nutrients that are absolutely essential when utilized in appropriate quantities, but harmful in excessive quantity. And if too many use them in excessive quantity, then polluted runoff is released as a side-effect. There is an assumption that waste is so rampant, that a per-slot cost would lead to efficiency, and no loss of connectivity or stability, but there appears to be lack of data validating the suggestion. Private routing slot markets could be a huge can of worms... and we thought peering spats were bad. Some $BIG_DSL_PROVIDER is going to refuse to pay some $BIG_HOSTING_PROVIDER (or anyone else) for their routing slots, they will know that their size makes it too unpallatable for anyone else on the market to _not give them_ the slots, even if they are one of the larger polluters with numerous announcements. Other providers simply can't afford to be the provider whose customers can't reach $HIGHLY_POPULAR_WEB_SITE. If $BIG_HOSTING_PROVIDER's routers do not have $BIG_DSL_PROVIDER's routes, $BIG_HOSTING_PROVIDER's customers will scream, and jump ship for $other_hosting_provider that has $big_dsl_provider routability. There will be other $BIG_COMPANYs that as well have superior negotiating position, and noone else will be in a position to discard their routes, when they refuse to pay, or negotiate a price that reflects their superior position (rather than one reflecting cost of their excessive use of routing slots). So first of all... if there's a buying and selling of routing slots a market. It cannot be a voluntary market, or it will simply lead to a chaotic situation where numerous big providers get free routes, and everyone else has to pay the big providers extortionate/disproportionately high fees because they _have to have those slots_ due to so many of their hosting customers requiring $big_provider connectivity. To ascertain a market in the first place... need to know How is the number of slots that will be on the market determined? Who gets to initialize the market; create and sell paid 'routing slots', and what will give them the power to enforce all users of routing slots buy from them... Are these one-time purchases... or do 'routing slot' purchases incur maintenance fees? How would the 'ownership' of a slot get verified, when a route is announced? How is it decided how much cost 'repayment' each AS gets? Who is going to make sure each AS fully populates their table with each routing slot they have been paid to fill and they do not populate any slots that were not purchased by the originator on the open market? The idea of 'ownership' of other people's things (slots on other people's routers) generally requires the AS owning those things to sell them. That would suggest each announcer of routes having to go to each AS and paying each AS a fee for slots on their routers --- not only would it be expensive, but the communication overhead required would be massive. So clearly any market would need to be centralized; transactions would need to happen through one entity. One buy/sell transaction for a routing slot on _all_ participating ASes. Seems like a tall order the slots that I need subtract the royalities I recieve from the other participants and if I'm close to the mean number of slots per participant then it nets out to zero. -- -JH
Re: Top webhosters offering v6 too?
Many virtual private server companies (I have 2 BurstNET VPS servers in Scranton and Los Angeles) will give you a /64 of IPv6 addresses. This is always an option.
802.11g with WPA-PSK
Im not familiar with wpa_supplicant, but you can preface external commands to execute in ifconfig.* with ! On Feb 6, 2011 1:08 PM, Andrew Ball ab...@students.prairiestate.edu wrote: Hello, I have a NetBSD host that I would like to connect to an existing wireless LAN using a rum(4) interface (Belkin F5D7050B USB 802.11g adaptor). I have tried configuring wpa_supplicant via rc.conf but it does not seem to start and I don't know why. Is there some other way to launch wpa_supplicant, perhaps via ifconfig.rum0? - Andy Ball
Re: quietly....
On Feb 6, 2011, at 1:15 PM, Owen DeLong wrote: If you advertise a product as internet access, then, providing limited or partial access to the internet does not fulfill the terms of the contract unless you have the appropriate disclaimers. And in nearly every ISP's terms-of-service, which you agree to the terms and conditions of by becoming a customer, there's invariably clauses in there that give them all sorts of rights to filter traffic at their discretion, etc., etc. D
Re: quietly....
On Feb 6, 2011, at 10:34 AM, Jay Ashworth wrote: - Original Message - From: Owen DeLong o...@delong.com I'm pretty sure the PS3 will get resolved through a software update. Yes, there will be user-visible disruptions in this transition. No, it can't be 100% magic on the part of the service provider. It still has to happen. There is no viable alternative. There will be *lots* of user visible disruptions. And if you believe, as it appears you do from the integration of your messages on this thread, that anyone anywhere will be able through any legal theory to *force* Sony to make that older PS3 work on IPv6, then the term for your opinion, in *my* opinion, has changed from optimistic to nutsabago. :-) No. I believe I can force through legal choices hotel providers to refund my internet access charges if they block certain ports. I've done so. I believe that Sony will offer IPv6 software upgrades for the PS-3 because they will eventually realize that failing to do so is bad for future sales. From up here at 30,000ft, the entire deployment of IPv6 has been cripplingly mismanaged, or we wouldn't be having all these conversations, still, now. Having had them 5 years ago would have been well more than good enough. And it will start to bite, hard, very shortly. An interesting perspective. The problem with that theory is that nobody actually manages the internet. It is a collection of independently managed networks that happen to coordinate, cooperate, and collaborate on a limited basis to make certain things work. I agree with you that many organizations and individuals could have acted differently to achieve a more optimal transition. However, they didn't and we are where we are. As a result, I think it is far more productive to move forward and make the transition as quickly and effectively as possible than to dwell on claims of mismanagement which lack both a meaningful target and any form of useful resolution. Owen
Re: Weekend Gedankenexperiment - The Kill Switch
On February 5, 2011 at 18:11 d...@dcrocker.net (Dave CROCKER) wrote: On 2/5/2011 6:43 AM, Fred Baker wrote: On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: Not sure if it has been said already but wasn't one of the key point for the creation of the internet to create and infrastructure that would survive in the case of all out war and massive destruction. (strategic nuclear strikes) Urban legend, although widely believed. Someone probably made the observation. Maybe not quite an UL... http://www.rand.org/about/history/baran.html On the average, The Rand Corp is extremely careful about what it publishes, yet here it is, repeating the claim. I agree with Dave, I think this idea that it's an urban legend has now become an urban legend. If you focus it down very sharply like this: DARPA specified (or, perhaps, the project was sold to DARPA with a promise...) that the network being designed in the late 1960s should be resistant to a nuclear attack. That's probably an urban legend, who knows, it's probably not all that interesting. But was it observed over and over from the early on that a packet network, versus the then predominant technology of virtual (or even real) circuit networks, would be resistant to damage of all sorts? Yes. Another early motivation which isn't often mentioned in these discussions was the sharing of supercomputer resources. Supercomputers generally cost tens of millions of dollars back then, approaching $100 million if you took the infrastructure into account. I worked on a $100M supercomputer proposal as it evolved into 50 tons of chilled water on the roof to shoring up the roof to hold that much water, to running a private gigawatt power line from the local utility thru Boston...etc. And the sort of people who needed access to those supercomputers were spread across the country (and world of course.) It was becoming a matter of whether to move the researchers, not very practical (how many finite element analysis experts do you really need at one university?), or buy each of them a supercomputer (kind of expensive), or try to hook them up remotely. At first dial-up seemed plausible but data visualization, graphical access, became more and more important even in the late 1970s and early 80s. Researchers were shipping large cartons of magtape so they could use local computers to generate graphical results of their computations. It was unwieldy to be kind. The internet was a good answer to that problem, and that vision of high-speed (for the era) remote access certainly factored into proposals such as the JVNC-era proposals, NSFnet, etc. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: Weekend Gedankenexperiment - The Kill Switch
On 2/6/2011 10:47 AM, Barry Shein wrote: If you focus it down very sharply like this: DARPA specified (or, perhaps, the project was sold to DARPA with a promise...) that the network being designed in the late 1960s should be resistant to a nuclear attack. That's probably an urban legend, who knows, it's probably not all that interesting. But was it observed over and over from the early on that a packet network, versus the then predominant technology of virtual (or even real) circuit networks, would be resistant to damage of all sorts? Yes. Sorry, but I think the technical implications of a goal to survive 'hostile battlefield conditions' versus 'nuclear attack' are (small pun) massively different. Hence I think the actual language used matters. And the fact that the common language around the net during the '70s was the former and not the latter matters. Which is why it would be helpful to get some credible documentation about use of the latter. I'd expect the major difference in the two terms is the scale of the outage. A few square miles, versus possibly thousands. To that end, I remember an anecdote about van Jacobson from the 1989 quake in California that might provide some insight about a large-scale outage:[1] He was living in Berkeley but was visiting Stanford when the quake hit and he wanted to check that his girlfriend was safe. Of course, the phone didn't work.[2] Out of sheer frustration and the need to do /something/ he sent her an email. He got a response within a few minutes. Surprised that the net was still working (and working quite well), he did a traceroute from the Stanford system to the one his girlfriend was using.[3] Not surprisingly, the path did not cross the San Francisco Bay, as it normally would have. Instead it went down to Los Angeles, across the southern US, up the East Coast and back across the Northern U.S. Although the outage was fairly small-scale, the scale of the re-routing suggests that a larger, 'regional' outage from something like a nuclear event would adapt readily. (We can ignore the additional question of EMP effects, since that only affects the scale of the outage.) And, of course, there have been other test cases since then... d/ [1] This is anecdotal; I've never confirmed the story with him. [2] That does not automatically indicate a system failure, given the switch to an emergency mode for the phone system that restricts access during major events like these. [3] Van created traceroute. http://en.wikipedia.org/wiki/Traceroute -- Dave Crocker Brandenburg InternetWorking bbiw.net
Re: quietly....
On Sun, Feb 06, 2011 at 10:43:18AM -0800, Owen DeLong wrote: I believe that Sony will offer IPv6 software upgrades for the PS-3 because they will eventually realize that failing to do so is bad for future sales. Sony appears quite willing to file eye-openingly broad discovery requests in its OtherOS/geohotz lawsuit(s). Related, but separate, Sony appears to be unconcerned with the removal of OtherOS in the first place, a documented feature and selling point that's made some people unhappy (e.g. USAF). And Sony appears completely unconcerned about the Sony RootKit fiasco (Most people, I think, don't even know what a Rootkit is, so why should they care about it?). Technical impediments (lack of ipV6) in their product(s) do not necessarily correlate with what they think of future sales prospects. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York he...@aegis00.com (800) 234-4700
Seeking IPv6 services (was: Random Port Blocking at Hotels)
On Feb 5, 2011, at 9:06 PM, John R. Levine wrote: Sure. Bet you ten bucks that no hotel in North America offers IPv6 this year in the wifi they provide to customers. (Conference networks don't count.) That could easily be the case this year... However, it's not going to stay that way for long, particularly if corporate buyers specify IPv6 in their RFPs for hotel room blocks. As of January 1st, 2012, ARIN considers IPv4 and IPv6 both necessary for something to be available via the Internet per our procurement policy, and we're in the process of informing our service providers (including such things as hotels, payroll and benefit services with web portals, vendors with online support, etc) of that requirement. Note - we're not going to let lack of IPv6 in hotel rooms prevent us from holding a Public Policy Meeting, but making it clear that we'll prefer compliant vendors if there's a viable choice has a real effect on getting attention to the requirement by those in charge. I'm certain that others folks out there also buy things, but I'm only in charge of ARIN. FWIW, /John John Curran President and CEO ARIN
Re: 802.11g with WPA-PSK
if it's running a recent net80211 stack, you'll need to create a vap sttion interface first eg, ifconfig wlan0 create wlandev rum0 then do stuff to wlan0, not rum0. Adrian On Sun, Feb 06, 2011, Atticus wrote: Im not familiar with wpa_supplicant, but you can preface external commands to execute in ifconfig.* with ! On Feb 6, 2011 1:08 PM, Andrew Ball ab...@students.prairiestate.edu wrote: Hello, I have a NetBSD host that I would like to connect to an existing wireless LAN using a rum(4) interface (Belkin F5D7050B USB 802.11g adaptor). I have tried configuring wpa_supplicant via rc.conf but it does not seem to start and I don't know why. Is there some other way to launch wpa_supplicant, perhaps via ifconfig.rum0? - Andy Ball -- - Xenion - http://www.xenion.com.au/ - VPS Hosting - Commercial Squid Support - - $24/pm+GST entry-level VPSes w/ capped bandwidth charges available in WA -
Re: NANOG Digest, Vol 37, Issue 93
Is anyone on this list aware of any IPv6 ready networks in the English speaking caribbean? Rudi Daniel On Sun, Feb 6, 2011 at 2:19 PM, nanog-requ...@nanog.org wrote: Send NANOG mailing list submissions to nanog@nanog.org To subscribe or unsubscribe via the World Wide Web, visit https://mailman.nanog.org/mailman/listinfo/nanog or, via email, send a message with subject or body 'help' to nanog-requ...@nanog.org You can reach the person managing the list at nanog-ow...@nanog.org When replying, please edit your Subject line so it is more specific than Re: Contents of NANOG digest... Today's Topics: 1. Re: quietly (Owen DeLong) 2. Re: Top webhosters offering v6 too? (Simon Leinen) 3. Re: Top webhosters offering v6 too? (Fred Richards) 4. Re: What's really needed is a routing slot market (Joel Jaeggli) 5. Re: Top webhosters offering v6 too? (Cameron Byrne) 6. Re: What's really needed is a routing slot market (John Curran) 7. Re: quietly (Roland Perry) 8. Re: What's really needed is a routing slot market (Joel Jaeggli) 9. Re: quietly (Roland Perry) 10. Re: quietly (Owen DeLong) -- Message: 1 Date: Sun, 6 Feb 2011 08:22:55 -0800 From: Owen DeLong o...@delong.com Subject: Re: quietly To: Lee Howard l...@asgard.org Cc: nanog@nanog.org Message-ID: be9e6edb-4c0b-4313-ba18-d38f8c881...@delong.com Content-Type: text/plain; charset=us-ascii Firewalls merely constrict it. Not that I advocate against the use of firewalls; in fact, I think I'm agreeing with you, and extending the argument a little further, that we should move from NAT to firewalls, then from stateful firewalls to secure hosts and network security appliances. Lee I would be fine with that. However, in terms of the art of the possible with the tools available today, IPv6 has no need of NAT, but, firewalls cannot yet be safely removed from the equation. Owen -- Message: 2 Date: Sun, 06 Feb 2011 17:43:04 +0100 From: Simon Leinen simon.lei...@switch.ch Subject: Re: Top webhosters offering v6 too? To: Tim Chown t...@ecs.soton.ac.uk Cc: NANOG list nanog@nanog.org Message-ID: aatyghjeqv@macsl.switch.ch Content-Type: text/plain; charset=us-ascii Tim Chown writes: Which of the big boys are doing it? Google - although there don't call themselves a web hoster, they can be used for hosting web sites using services such as Sites or App Engine. Both support IPv6, either using the opt-in mechanism or by using an alternate CNAME (ghs46 instead of ghs.google.com). That's what I use. None of the other large cloud providers seems to support IPv6 for their users yet. In particular, neither Amazon's AWS not Microsoft Azure have much visible activity in this direction. Rackspace have announced IPv6 support for the first half of 2011. Concerning the more traditional webhosting offerings, I have no idea about the big boys. Here in Switzerland, a few smaller hosters support IPv6. And I saw IPv6 mentioned in ads for some German server hosting offering. Germany is interesting because it has a well-developed hosting ecosystem with some really big players. -- Simon. -- Message: 3 Date: Sun, 6 Feb 2011 11:49:06 -0500 From: Fred Richards fr...@geexology.org Subject: Re: Top webhosters offering v6 too? To: NANOG list nanog@nanog.org Message-ID: aanlktiksv84+tsm80ajyxg-xzdfx3ngjz1fjm0kq6...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 I ran across this link a while back, it shows, of the top 100k websites (according to Alexa), which ones are IPv6 enabled: http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=true On Sun, Feb 6, 2011 at 11:43 AM, Simon Leinen simon.lei...@switch.ch wrote: Tim Chown writes: Which of the big boys are doing it? Google - although there don't call themselves a web hoster, they can be used for hosting web sites using services such as Sites or App Engine. Both support IPv6, either using the opt-in mechanism or by using an alternate CNAME (ghs46 instead of ghs.google.com). ?That's what I use. None of the other large cloud providers seems to support IPv6 for their users yet. ?In particular, neither Amazon's AWS not Microsoft Azure have much visible activity in this direction. ?Rackspace have announced IPv6 support for the first half of 2011. Concerning the more traditional webhosting offerings, I have no idea about the big boys. ?Here in Switzerland, a few smaller hosters support IPv6. ?And I saw IPv6 mentioned in ads for some German server hosting offering. ?Germany is interesting because it has a well-developed hosting ecosystem with some really big players. -- Simon. -- ? ? ? ? ? ? ? ? ? ? ? Fred -- Message: 4
Re: quietly....
On Feb 6, 2011, at 11:11 AM, Henry Yen wrote: On Sun, Feb 06, 2011 at 10:43:18AM -0800, Owen DeLong wrote: I believe that Sony will offer IPv6 software upgrades for the PS-3 because they will eventually realize that failing to do so is bad for future sales. Sony appears quite willing to file eye-openingly broad discovery requests in its OtherOS/geohotz lawsuit(s). Related, but separate, Sony appears to be unconcerned with the removal of OtherOS in the first place, a documented feature and selling point that's made some people unhappy (e.g. USAF). And Sony appears completely unconcerned about the Sony RootKit fiasco (Most people, I think, don't even know what a Rootkit is, so why should they care about it?). Technical impediments (lack of ipV6) in their product(s) do not necessarily correlate with what they think of future sales prospects. While Sony is, indeed, showing surprising market ignorance and bad judgment at the moment, I think that the market will eventually teach them a lesson in these regards. Time will tell. Owen
Re: quietly....
Once upon a time, Henry Yen he...@aegisinfosys.com said: On Sun, Feb 06, 2011 at 10:43:18AM -0800, Owen DeLong wrote: I believe that Sony will offer IPv6 software upgrades for the PS-3 because they will eventually realize that failing to do so is bad for future sales. Technical impediments (lack of ipV6) in their product(s) do not necessarily correlate with what they think of future sales prospects. Also, lack of functionality in the current generation can be seen by management as _good_ for future sales (of the PS4, the Xbox 720, WiiToo, etc.). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Leasing of space via non-connectivity providers
On Feb 6, 2011, at 2:16 PM, David Conrad wrote: As you're aware, RFC 2050 was a group effort, so focusing on Jon's intent seems questionable particularly given he sadly isn't around to provide corrections. While it may have been a group effort, Jon was the IANA. With regards to specific language, you reference section 2.1.1. You'll note that this is in a section talking about guidelines for how ISPs should deal with address space. It is saying ISPs should treat assignments to their customers like loans. Section 2.1.3 is talking about two different things as indicated by the terminology used. The future _allocations_ may be impacted is talking about allocations made from the RIR to the ISP. The existing _loans_ may be impacted is saying the RIR could ignore assignments the ISP has made to its customers (making it a bit difficult for the ISP to get new space). Interesting viewpoint in separating the two, as the full context is: If the information is not available, future allocations may be impacted. In extreme cases, existing loans may be impacted. Your suggestion that existing loans may be impacted means to be ignored for evaluating future allocations does seems a bit superfluous when taken in full context, but obviously must be considered as you are one of the authors. One wonders why it just doesn't repeat future allocations may be impacted for the second sentence. Do you have any similar suggestions for how to reinterpret the transfer section, i.e. The transfer of IP addresses from one party to another must be approved by the regional registries. or The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR. ? So, if you believe ARIN policy applies to all space, you're saying that ARIN at one time violated the section of RFC 2050 you quoted and that later, ARIN changed that policy. This sort of policy evolution is exactly what was envisioned when we wrote RFC 2050. We assumed policies would change over time, and as such RFC 2050 was merely documenting the current practice as it was in 1996. This is why I always find your referencing 2050 as if it is sacred text curious. It's fairly difficult to have a consistent global registry framework that the regional registries operate under unless its actually followed by the regional registries. What would have been best would have been to separate the document into two; one for the overall Internet Registry requirements technically necessary, and then one with the current view on appropriate allocation policy. I wasn't there, so I can't say why the two are combined. In the particular instance you point out, I'm happy to say ARIN is back in alignment with RFC 2050 as written. In thinking about this, since RFC 2050 was focused on IPv4 allocation policy and there is no more IPv4 to allocate, 2050 should probably be moved to historic. It certainly would be worth considering revising to maintain the portions which are an inherent technical requirements from IAB/IETF versus those which are a snapshot of registry policy at the time. It also is interesting to consider which forum(s) such an activity should take place in, since it's clear that an overall framework is necessary for the system to keep working globally. /John John Curran President and CEO ARIN
Re: quietly....
On Feb 6, 2011, at 2:28 PM, Owen DeLong wrote: While Sony is, indeed, showing surprising market ignorance and bad judgment at the moment, I think that the market will eventually teach them a lesson in these regards. Time will tell. It is worth correlating that there seems to be some agreement to surprising market ignorance in the feature set and implementation of IPv6 as it pertains to the demands of its myriad actual consumers, and that the market will eventually teach the designers of IPv6 a lesson in that regard. That sword has edges on both sides, my friend. :-) cheers, D
Re: Weekend Gedankenexperiment - The Kill Switch
the authoritative and secondary servers for the ميسر. zone were unreachable, a circumstance which existed a year ago for the .ht zone. the authoritative and secondary servers for the .eg zone were mutually unreachable. wireline dialtone was prevalent during the prefix withdrawal period. suggestions for oob control, 56kb tech and (signed) zone transfer would be useful. graceful conversion to a sparse 56kb and vsat connectivity regime may be a general form of robustness.
Re: What's really needed is a routing slot market
What's really needed is seperate the routing slot market from the address allocation market. Bingo! In fact, having an efficient market for obtaining routing of a given prefix, combined with IPv6 vast identifier space, could actually satisfy the primary goals that we hold for a long-term scalable address architecture, and enable doing it in a highly distributed, automatable fashion This is not unlike the oft made comment that if you could just charge a fraction of a cent for every mail message, there would be no spam problem. They're both bad ideas that just won't go away. Here's some thought experiments: 1) You get a note from the owner of jidaw.com, a large ISP in Nigeria, telling you that they have two defaultless routers so they'd like a share of the route fees. Due to the well known fraud problem in Nigeria, please pay them into the company's account in the Channel Islands. What do you do? (Helpful hint: there are plenty of legitimate reasons for non-residents to have accounts in the Channel Islands. I have a few.) 2) Google says here's our routes, we won't be paying anything. What do you do? 2a) If you insist no pay, no route, what do you tell your users when they call and complain? 2b) If you make a special case for Google, what do you do when Yahoo, AOL, and Baidu do the same thing? I can imagine some technical backpressure, particularly against networks that don't aggregate their routes, but money? Forget about it, unless perhaps you want to mix them into the peering/transit negotiations. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly
Re: What's really needed is a routing slot market
On Sun, Feb 6, 2011 at 12:15 PM, Joel Jaeggli joe...@bogus.com wrote: On 2/6/11 8:00 AM, John Curran wrote: On Feb 5, 2011, at 9:40 PM, Mark Andrews wrote: What's really needed is seperate the routing slot market from the address allocation market. Bingo! In fact, having an efficient market for obtaining routing of a given prefix, combined with IPv6 vast identifier space, could actually satisfy the primary goals that we hold for a long-term scalable address architecture, and enable doing it in a highly distributed, automatable fashion: So assuming this operates on a pollution model the victims of routing table bloat are compensated by the routing table pollutors for the use of the slots which they have to carry. so I take the marginal cost of the slots that I need subtract the royalities I recieve from the other participants and if I'm close to the mean number of slots per participant then it nets out to zero. Hi Joel, It couldn't and wouldn't work that way. Here's how it could work: Part 1: The Promise. If paid to carry a particular route (consisting one specific network and netmask, no others) then barring a belief that a particular received route announcement is fraudulent, a given AS: A. Will announce that route to each neighbor AS which pays for Internet access if received from any neighbor AS, unless the specific neighbor AS has asked to receive a restricted set of routes. B. Will announce that route to every neighbor AS if received from any neighbor AS who pays for Internet access, unless the specific neighbor AS has asked to receive a restricted set of routes. C. Will not ask any neighbor AS to filter the given route or any superset from the list of routes offered on that connection. D. Will assure sufficient internal carriage of the route within the AS's network to reasonably meet responsibilities A, B and C, and extend the route or a sufficient covering route to every non-BGP customer of the network. Part 2: The Payment. Each AS who wishes to do so will offer to execute The Promise for any set of networks/netmasks requested by the legitimate origin AS for a reasonable and non-discriminatory (RAND) price selected by the AS based on reasonable estimates of the routing slot costs. The preceding not withstanding, an AS may determine that a particular route or AS is not eligible for carriage at any price due to violations of that AS's terms of service. If such is determined, the AS will not accept payment for carrying the route and will refund any payments made for service during the period in which carriage is not made. Needless to say, the origin AS with two routers can offer a RAND fee to carry routes, but not many will take them up on it. They'll have to carry the route or institute a default route if they want to remain fully connected. The folks who will get paid are the ones who collectively are the backbone where you, as the origin, can't afford for your route not to be carried. These are, of course, the same folks who are presently the victims of routing pollution who pay the lion's share of the $2B/yr routing slot costs yet have little choice but to carry the routes. Part 3: The Arbiter. One or several route payment centers collects the RAND offerings and makes them available to origin ASes in bulk sets. You write one check each month to the Arbiter and he collects your routes with his other customers and makes the appropriate Payments for the Promises. Part 4: The Covering Routes. ARIN and the other RIRs auction the rights to offer a covering route for particular /8's. The winner announces the whole /8 but gets to break the RAND rule in the Payment for covered routes. An origin AS can still choose to have everybody carry his routes. But he can also choose to have just the paid paths to the AS with the Covering Route carried, or some fraction of ASes that includes those paid paths. Or he could buy transit tunnels from the Covering Route AS anchored to PA addresses from his individual ISPs. Or he could do a mix of the two. Regardless, the origin AS ends up with full reachability without needing his explicit route to be carried the breadth of the Internet. Note that I use the term auction very loosely. The winner could be the qualified AS willing to pay a fixed nominal fee and promise the lowest carriage fee / 95th percentile tunnel transit fee. At any rate, you get a healthy potential for route aggregation through payment selection by the origin AS. If more precise routing is worth the money, they'll pay the slot cost. If not, they'll rely on the covers. Or if it works out that a router costs $5M because it has to carry 10M routes, who cares as long as you're being paid what it costs? Yay? Yay! 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: What's really needed is a routing slot market
1) You get a note from the owner of jidaw.com, a large ISP in Nigeria, telling you that they have two defaultless routers so they'd like a share of the route fees. Due to the well known fraud problem in Nigeria, please pay them into the company's account in the Channel Islands. What do you do? (Helpful hint: there are plenty of legitimate reasons for non-residents to have accounts in the Channel Islands. I have a few.) If I peer with them or sell them transit or buy transit from them then we have a reason to talk, otherwise, not so much. 2) Google says here's our routes, we won't be paying anything. What do you do? There's a cost to taking the routes from Google, and a benefit to having those routes. As long as the benefit exceeds the cost, no worries. 2a) If you insist no pay, no route, what do you tell your users when they call and complain? 2b) If you make a special case for Google, what do you do when Yahoo, AOL, and Baidu do the same thing? Back to the cost/benefit balance above. I can imagine some technical backpressure, particularly against networks that don't aggregate their routes, but money? Forget about it, unless perhaps you want to mix them into the peering/transit negotiations. I think the only way it works, presuming anyone wanted to do it, is as a property of transit and peering. If I buy transit from you and want to send you a mess of routes, you might charge me more for my transit on account of that. Perhaps I get one free prefix announcement per x amount of bandwidth I am buying ? If we are peering then prefix balance might join traffic balance as a way to think about whether the arrangement is good for both peers. All of these arrangements occur between directly peering or transit providing neighbors. If I buy transit from you, I expect you to pay any costs needed to get my routes out to the world (and probably to charge me accordingly).
Re: quietly....
On 2/6/2011 2:53 PM, Derek J. Balling wrote: It is worth correlating that there seems to be some agreement to surprising market ignorance in the feature set and implementation of IPv6 as it pertains to the demands of its myriad actual consumers, and that the market will eventually teach the designers of IPv6 a lesson in that regard. I don't think it's a concern or issue. Everyone will just have to buy an xbox. M$ can't claim ignorance. :) Jack
Re: What's really needed is a routing slot market
On 2/6/2011 3:16 PM, John Levine wrote: I can imagine some technical backpressure, particularly against networks that don't aggregate their routes, but money? Forget about it, unless perhaps you want to mix them into the peering/transit negotiations. On the other hand, the ESPN3 extortion worked quite well. Jack
Re: Top webhosters offering v6 too?
In message aanlktiksv84+tsm80ajyxg-xzdfx3ngjz1fjm0kq6...@mail.gmail.com, Fred Richards writes: I ran across this link a while back, it shows, of the top 100k websites (according to Alexa), which ones are IPv6 enabled: http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=3Dt= rue And 1.5% of lookups, in the Alexa top 100, fail as the SOA is in the wrong section or the wrong SOA is returned or timeout or return NXDOMAIN when A returns a answer. GLB vendors have a lot to answer for as almost all of these errors involve a GLB being installed. Either their products are broken or their documentation is so poor that people can't configure their boxes properly. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: Leasing of space via non-connectivity providers
On Feb 6, 2011, at 9:53 AM, John Curran wrote: Your suggestion that existing loans may be impacted means to be ignored for evaluating future allocations does seems a bit superfluous when taken in full context, but obviously must be considered as you are one of the authors. I believe (it has been 15 years after all) the idea was that if an ISP didn't update the registry with new assignments, the RIR could in extreme cases remove previously submitted reassignment information as punishment (the theory being that this would cause the ISP's customers to take action). Again, this wording is in a section that is discussing sub-delegation guidelines for ISPs who received an allocation from the RIRs. How are you reinterpreting section 2.1.3? Do you have any similar suggestions for how to reinterpret the transfer section, i.e. The transfer of IP addresses from one party to another must be approved by the regional registries. or The party trying to obtain the IP address must meet the same criteria as if they were requesting an IP address directly from the IR. ? As opposed to section 2, section 4.7 seems pretty unambiguous to me: it was an attempt by the registries at the time to conserve the remaining IPv4 free pool by disallowing the bypassing of registry allocation restrictions. Do you reinterpret it differently? It certainly would be worth considering revising to maintain the portions which are an inherent technical requirements from IAB/IETF versus those which are a snapshot of registry policy at the time. I hear Mark McFadden, since he hated his life, was working on 2050bis... :-) More seriously, RFC 2050 was an attempt to document the then current (in 1996) practices for allocating IPv4 addresses. Instead of revising that 15 year old document, I'd think a document that describes the role and responsibilities of the registries in a post-IPv4 free pool world would be much more valuable. My impression is that there is a bit of a disconnect between the folks who go to RIR meetings and the folks who have IP addresses (particularly those folks who received their addresses prior to the existence of the RIRs). Might be useful to remedy this. It also is interesting to consider which forum(s) such an activity should take place in, since it's clear that an overall framework is necessary for the system to keep working globally. Yeah, too bad no one set up an organization whose By-Laws and Mission is to coordinate, at an overall level, the global Internet's systems of unique identifiers capable of providing such a forum. Regards, -drc
Re: quietly....
In message 23119638.5335.1297017284299.javamail.r...@benjamin.baylink.com, Ja y Ashworth writes: - Original Message - From: Owen DeLong o...@delong.com I'm pretty sure the PS3 will get resolved through a software update. Yes, there will be user-visible disruptions in this transition. No, it can't be 100% magic on the part of the service provider. It still has to happen. There is no viable alternative. There will be *lots* of user visible disruptions. And if you believe, as it appears you do from the integration of your messages on this thread, that anyone anywhere will be able through any legal theory to *force* Sony to make that older PS3 work on IPv6, then the term for your opinion, in *my* opinion, has changed from optimistic to nutsabago. :-) From up here at 30,000ft, the entire deployment of IPv6 has been cripplingly mismanaged, or we wouldn't be having all these conversations, still, now. Having had them 5 years ago would have been well more than good enough. And it will start to bite, hard, very shortly. Cheers, -- jra PS3 will only be a problem if it doesn't work through double NAT or there is no IPv4 path available. Homes will be dual stacked for the next 10 years or so even if the upstream is IPv6 only. DS-Lite or similar will provide a IPv4 path. The DS-Lite service can be supplied by anyone anywhere on the IPv6 Internet that has public IPv4 addresses. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
On 2/6/2011 4:44 PM, Mark Andrews wrote: PS3 will only be a problem if it doesn't work through double NAT or there is no IPv4 path available. Homes will be dual stacked for the next 10 years or so even if the upstream is IPv6 only. DS-Lite or similar will provide a IPv4 path. The DS-Lite service can be supplied by anyone anywhere on the IPv6 Internet that has public IPv4 addresses. I could be wrong, but I believe the PS3, like many game systems, has trouble with double NAT and supports end node game hosting, which will break with double NAT on both ends; we'll see double NAT commonly on both end points as we move forward if IPv4 is bothered to be supported for long, especially if ds-lite doesn't become more prevalent in CPEs. Jack
Re: quietly....
In message 4d4f27e4.6080...@brightok.net, Jack Bates writes: On 2/6/2011 4:44 PM, Mark Andrews wrote: PS3 will only be a problem if it doesn't work through double NAT or there is no IPv4 path available. Homes will be dual stacked for the next 10 years or so even if the upstream is IPv6 only. DS-Lite or similar will provide a IPv4 path. The DS-Lite service can be supplied by anyone anywhere on the IPv6 Internet that has public IPv4 addresses. I could be wrong, but I believe the PS3, like many game systems, has trouble with double NAT and supports end node game hosting, which will break with double NAT on both ends; we'll see double NAT commonly on both end points as we move forward if IPv4 is bothered to be supported for long, especially if ds-lite doesn't become more prevalent in CPEs. Note the CPE doesn't have to be the box they is offering the IPv4 connectivity to the net. Any dual stack box on the net could do the job provided it supports the B4 component. Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
Re: quietly....
On 2011-02-03, at 18:37, Paul Graydon wrote: On 02/02/2011 06:31 PM, Jay Ashworth wrote: I, personally, have been waiting to hear what happens when network techs discover that they can't carry IP addresses around in their heads anymore. That sounds trivial, perhaps, but I don't think it will be. Absolutely, it's certainly one thing I'm dreading. I'm not sure this is the nightmare people think it will be. In my (admittedly fairly small-scale) experience with operating v6 on real networks, being able to figure out a prefix from a schema such as ARIN:ARIN:SITE:VLAN::/64 makes things a lot easier. Having to remember ...::1, or ...::2, or ...:3 for the statically-numbered routers on the VLAN doesn't exactly make things much harder. Mix in some special cases (e.g. VLAN=0 for loopbacks) and you have a recipe that's pretty trivial to remember. [This is how Stephen Stuart and Paul Vixie set things up within 2001:4f8::/32 back when I was chasing packets at ISC, and I've followed the model ever since.] It's easier to figure out 2607:f2c0:1::1 in these terms than it is to remember 206.248.155.244. For me, at least :-) I appreciate the full mess of EUI-64 for devices using autoconf requires cut and paste, but that's why you hard-wire the host bits for things you refer to frequently. Joe
Re: Weekend Gedankenexperiment - The Kill Switch
On Feb 6, 2011, at 8:57 AM, isabel dias wrote: do you have a satellite dish? what are your dish pointing coordinates..we just need to find out what is going on the air interface ... I don't personally have one but of of the companies that I contract to is in the satellite networks business. It wouldn't take much to pack up a 1.2m antenna, LNB, BUC, iDirect router, cables, and be on the air. The 3.8m would be a bit more difficult to pack up. ;-) As for pointing, pick a Ku-band satellite viewable from Chicago and I could be on it. There's a bunch of them. The iDirect 7350 router will do iDirect TDMA or SCPC. Regards, Ryan Wilkins
Re: quietly....
On 2/6/2011 6:13 PM, Joe Abley wrote: I'm not sure this is the nightmare people think it will be. In my (admittedly fairly small-scale) experience with operating v6 on real networks, being able to figure out a prefix from a schema such as ARIN:ARIN:SITE:VLAN::/64 makes things a lot easier. Having to remember ...::1, or ...::2, or ...:3 for the statically-numbered routers on the VLAN doesn't exactly make things much harder. Mix in some special cases (e.g. VLAN=0 for loopbacks) and you have a recipe that's pretty trivial to remember. As an ISP, we reserved the first /48 of several of our /32's for specific purposes, which makes it even easier. Our helpdesk will be running ping by number tests (for detecting IPv6 connectivity but DNS being broken) using: ARIN:ARIN::/64 Which makes it as easy as IPv4. This was made easier by the fact that our allocation has no letters. Jack
Re: Leasing of space via non-connectivity providers
it is both amusing and horrifying to watch two old dogs argue about details of written rules as if common sense had died in october 1998. what is good for the internet? what is simple? what is pragmatic? if the answer is not simple and obvious, we should go break something else. randy
Re: Leasing of space via non-connectivity providers
On Feb 6, 2011, at 7:51 PM, Randy Bush wrote: it is both amusing and horrifying to watch two old dogs argue about details of written rules as if common sense had died in october 1998. what is good for the internet? what is simple? what is pragmatic? if the answer is not simple and obvious, we should go break something else. Actually, I'm in full agreement with you: the goal needs to be to keep the Internet running. Alas, I've run a few networks, but that's a few years back, and I'll be the first to admit that my particular graybeard views on what is best for the Internet lacks current operational insights. Also note that, as CEO of ARIN, it is not my role to preempt discussion by proposing solutions, but instead to encourage good discussion of the issues. So, what exactly is broken and needs to be changed? I do know that we can't have the basic premises of the system completely set on a regional basis, but we also have to allow for regional differences in policy since operators face different challenges. While the discussion is ongoing, we're keeping to the principles of aggregation, conservation, and registration, and looking forward to any consensus that emerges from the operator community to change these principles. /John John Curran President and CEO ARIN
Re: Top webhosters offering v6 too?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/06/2011 02:15 PM, Mark Andrews wrote: In message aanlktiksv84+tsm80ajyxg-xzdfx3ngjz1fjm0kq6...@mail.gmail.com, Fred Richards writes: I ran across this link a while back, it shows, of the top 100k websites (according to Alexa), which ones are IPv6 enabled: http://www.atoomnet.net/ipv6_enabled_popular_websites.php?complete_list=3Dt= rue And 1.5% of lookups, in the Alexa top 100, fail as the SOA is in the wrong section or the wrong SOA is returned or timeout or return NXDOMAIN when A returns a answer. GLB vendors have a lot to answer for as almost all of these errors involve a GLB being installed. Either their products are broken or their documentation is so poor that people can't configure their boxes properly. Given that v6 is probably an afterthought for these vendors, I'm guessing the documentation is at fault. I know the docs for some of the brands I've worked with were bad enough for tier-1 features. Bah. I'm in the process of putting together a fully software based system to do GLB. Presenting on it in a couple of weeks in the Los Angeles area. Hit me off list for details. It seems fairly straightforward to put the system together. Spent this weekend doing the research and architecture design for it. I'll send the slide link to the list after I give the talk. Maybe I'll present it in person at one of the upcoming NANOG meetings if I can get my employer to sponsor travel. :) Unfortunately it will be all v4. I have v6 turned up via he.net (as I alluded to a while back), but it's not at the same level as v4 is. I'm currently going through the learning process with v6. However that's an incredibly high priority for me, and I hope to be at parity with v4 by end of Q1. I'll probably do a separate ipv6 for datacenter/application operators presentation at some point in Q2. I know there will be one at SCALE this year, by one of our frequent v6 posters. :) - -- Charles N Wyble (char...@knownelement.com) Systems craftsman for the stars http://www.knownelement.com Mobile: 626 539 4344 Office: 310 929 8793 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNT0rqAAoJEMvvG/TyLEAtURcP+wbsYil0YufyEWsOlbtqcWDF kpoBgikyCPSazH/aM8trKsPFdWpo7HPX2RDHh+aJwRN3WEOPAdMzN+uchD28bvj8 1X0W4oJ+Tyrq0770iy7kcNmN0YJL7DpJlfiA8401lsPmsHBWrE55hEjcDz/lXjHA kfu7NOygoQ9PtQS8XgOrIpPVZ3Juv9ae/XUuwYEPkvGuwhn8ZdIBTKzSEIujPYOV dpMOxrXkaKrZILybUd9tmaFAKk4jML3+IqcziWYaDiJUWrrjLK18jMDOVr4WM8Pb TK8kz86B3oTNworxeVT9/oWyWMoPf0FDSCWCeEgdj4YvvlPlbq7skC2djvRvpPBE DtdOqw1gz8Buw3wvIrUfFsZgvOIrDRBCeXVvG0MoErpK18TubA79ZM8x58/aXAAY 3bnoiIfdJQGCnO5IscMEOijmPq60UI9fl1u4KTGd30nIEVFN1jPPKXXWDBPEFSA4 ylEJLKRP6CKNETURcfiMo9hi25IMiVjf4GvWGz1VPTqBhewh7ZxCEJkXrdQ7cAnh uZhbX76e/AGkeSiBvWdSDPlrUkFES5utoghswwZ8yCPaQguoF4NUMaDtMNfwlk8X F3YR8ocCn9HKvBhAEPezkvR4n0SMy+ybAJJkUsJ0QVZifWCNFdz0oJLuy7OVtmGt Uw2dQluyXu8c24UfuIhI =nX8D -END PGP SIGNATURE-
Re: Leasing of space via non-connectivity providers
On Sun, Feb 06, 2011 at 04:51:26PM -0800, Randy Bush wrote: it is both amusing and horrifying to watch two old dogs argue about details of written rules as if common sense had died in october 1998. what is good for the internet? what is simple? what is pragmatic? if the answer is not simple and obvious, we should go break something else. Randy, I'll bite. I'll take Who cares? Let's keep on' keepin' on... for $200. Deck chairs indeed. --msa
Re: Top webhosters offering v6 too?
We (voxel.net, AS 29791) offer dual-stack on all server and cloud products. As others have pointed out, SoftLayer is an excellent example of a hosting provider that Gets It on a large scale. Sadly, v6 support on popular cloud-only services is suspiciously absent. Terremark vCoudExpress, Savvis, Amazon EC2, among others don't support it today, or on any public roadmaps... -a
Re: Top webhosters offering v6 too?
On 2/6/11 7:08 PM, Adam Rothschild wrote: We (voxel.net, AS 29791) offer dual-stack on all server and cloud products. As others have pointed out, SoftLayer is an excellent example of a hosting provider that Gets It on a large scale. Sadly, v6 support on popular cloud-only services is suspiciously absent. Terremark vCoudExpress, Savvis, Amazon EC2, among others don't support it today, or on any public roadmaps... It's worth noting that the address space used in the large public clouds almost certainly overlaps with one's own private numbering plan, and having had to interconnect with some public cloud I can tell you that I do not appreciate having to 1:1 nat several thousand potential systems. I poked several about v6 support it would be greately appreciated if other people would likewise contact your account reps. -a
Re: Top webhosters offering v6 too?
On Sun, Feb 6, 2011 at 7:21 PM, Joel Jaeggli joe...@bogus.com wrote: On 2/6/11 7:08 PM, Adam Rothschild wrote: We (voxel.net, AS 29791) offer dual-stack on all server and cloud products. As others have pointed out, SoftLayer is an excellent example of a hosting provider that Gets It on a large scale. Sadly, v6 support on popular cloud-only services is suspiciously absent. Terremark vCoudExpress, Savvis, Amazon EC2, among others don't support it today, or on any public roadmaps... It's worth noting that the address space used in the large public clouds almost certainly overlaps with one's own private numbering plan, and having had to interconnect with some public cloud I can tell you that I do not appreciate having to 1:1 nat several thousand potential systems. I poked several about v6 support it would be greately appreciated if other people would likewise contact your account reps. No need friend. The AWS support thread on IPv6 goes back to 2007 ... and still no support. I'd give up and move on ... just like an ISP that does not support IPv6 today. It's a fight not worth picking. Between Voxel and Softlayer, i assume nearly any need can be met ... and the VPS market is pretty cut throat and customers can move quick. We cannot talk blue in the face about how people should support IPv6, that time has passed. Many organizations do support IPv6, they have had the forethought, and we should really vote with our dollars and not yet another round of posturing about how important v6 is and how X company should add IPv6 to their roadmap. Cloud and mobile are 2 very fast growing edges ... and you cannot do any level of network planning for these fast growing edges and overlook IPv6. Cameron T-Mobile USA IPv6 Beta http://groups.google.com/group/tmoipv6beta
RE: Top webhosters offering v6 too?
Here's one list: http://www.sixxs.net/wiki/IPv6_Enabled_Hosting Frank -Original Message- From: Tim Chown [mailto:t...@ecs.soton.ac.uk] Sent: Sunday, February 06, 2011 8:53 AM To: NANOG list Subject: Top webhosters offering v6 too? Which of the big boys are doing it? Tim
Re: Top webhosters offering v6 too?
BlueHost, which while maybe not a great quality web host, by all measures is a big one, not only does not support IPv6 but they denied my request to create a record pointing to a friend's IPv6 page for a domain I host there. BH, are you listening??? -. Carlos On Sun, Feb 6, 2011 at 7:58 PM, Frank Bulk frnk...@iname.com wrote: Here's one list: http://www.sixxs.net/wiki/IPv6_Enabled_Hosting Frank -Original Message- From: Tim Chown [mailto:t...@ecs.soton.ac.uk] Sent: Sunday, February 06, 2011 8:53 AM To: NANOG list Subject: Top webhosters offering v6 too? Which of the big boys are doing it? Tim -- -- = Carlos M. Martinez-Cagnazzo http://www.labs.lacnic.net =
Re: Top webhosters offering v6 too?
On Sun, Feb 06, 2011 at 22:08:32PM -0500, Adam Rothschild wrote: As others have pointed out, SoftLayer is an excellent example of a hosting provider that Gets It on a large scale. An excellent example of a provider that Spams on a large scale, too. -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York he...@aegis00.com (800) 234-4700
Re: Weekend Gedankenexperiment - The Kill Switch
On 02-05-11 8:29 PM, Fred Baker wrote: On Feb 5, 2011, at 6:11 PM, Dave CROCKER wrote: On 2/5/2011 6:43 AM, Fred Baker wrote: On Feb 4, 2011, at 9:49 PM, Hayden Katzenellenbogen wrote: Not sure if it has been said already but wasn't one of the key point for the creation of the internet to create and infrastructure that would survive in the case of all out war and massive destruction. (strategic nuclear strikes) Urban legend, although widely believed. Someone probably made the observation. Maybe not quite an UL... http://www.rand.org/about/history/baran.html On the average, The Rand Corp is extremely careful about what it publishes, yet here it is, repeating the claim. But Len Kleinrock adamantly disputes it. Back in the '70s, I always heard survive hostile battlefield conditions and never heard anyone talk about comms survival of a nuclear event, but I wasn't in any interesting conversations, such as in front of funding agencies... To survive an EMP, electronics needs some fancy circuitry. I've never worked with a bit of equipment that had it. It would therefore have to have been through path redundancy. For more specifics from Paul Baran himself, you may read his interview with Stewart Brand. Lots of good stuff circa late 50s - early 60s. http://www.wired.com/wired/archive/9.03/baran_pr.html one fun excerpt, re: asking the phone co to build a packet switch: SB: How seriously did ATT look at the proposal? PB: The response was most interesting. The story I tell is of the time I went over to ATT headquarters - one of many, many times - and there's a group of old graybeards. I start describing how this works. One stops me and says, Wait a minute, son. Are you trying to tell us that you open the switch up in the middle of the conversation? I say, Yes. His eyeballs roll as he looks at his associates and shakes his head. We just weren't on the same wavelength. Paul's memory is backed up by his meticulous records. I worked at Com21 1997-2K and heard similar recounts from Paul over Com21 BBQ lunches at the company's Tasman site. I wished for a while he'd write a history but came to understand he's always been a doer not a historian. Cheers, - Michael
Re: Top webhosters offering v6 too?
On 2/6/11 8:21 PM, Carlos Martinez-Cagnazzo wrote: BlueHost, which while maybe not a great quality web host, by all measures is a big one, not only does not support IPv6 but they denied my request to create a record pointing to a friend's IPv6 page for a domain I host there. BH, are you listening??? There are plenty of providers that support IPv6 and would be happy to have a new customer that's interested in IPv6. If your current host does not support it and you want it, just drop them already and move on to one that does. ~Seth
Re: Top webhosters offering v6 too?
Oxilion, dutch based provider (AS48539), also provides cloud services based on RHEV. They do provide IPv6 also. See for a redhat notice about this: http://www.redhat.com/about/news/prarchive/2010/oxilion.html Their site is mostly dutch, however this one is in English also http://oxilion.nl/virtual-datacenter-en regards, Igor
