Linode launches native IPv6 support(blog.linode.com)
blog.linode.com
Linode launches native IPv6 support
http://blog.linode.com/2011/05/03/linode-launches-native-ipv6-support/
12 comments
For perspective: IANA instructs RIRs to allocate no less than a /32 to each customer. That leaves 32 bits for those customers to resell smaller subnets, usually /64. 32 bits is as much as the entire IPv4 Internet, so they can sell as many /64 subnets as there are individual computers on the IPv4 Internet. So even if Linode only bought 1 of these /64 subnets, they would have 64 bits of address space to allocate to their customers. I think they can spare more than one :)
Note: in your case, customer means ISP.
From what I remember, the instructions were that ISPs receive no less than /32, which should provide end-users either /48 or /56. End users use the remaining 8-16 bits to partition their networks in /64 subnets. /64 is the minimum routeable prefix, and is the prefix used for automatic configuration.
Linode offering /128 for free and /64 at a cost is ridiculous. Users will have problems to forward since that would require breaking the /64 into smaller networks (to have at least one distinct subnet at each end of the tunnel), which is not possible for radvd.
From what I remember, the instructions were that ISPs receive no less than /32, which should provide end-users either /48 or /56. End users use the remaining 8-16 bits to partition their networks in /64 subnets. /64 is the minimum routeable prefix, and is the prefix used for automatic configuration.
Linode offering /128 for free and /64 at a cost is ridiculous. Users will have problems to forward since that would require breaking the /64 into smaller networks (to have at least one distinct subnet at each end of the tunnel), which is not possible for radvd.
And it's not just academic, consider if you want to run lots of https and support browsers that don't support https on one address. Not to mention all the applications for many addresses that should develop if/when ipv6 is widespread.
As a further datapoint, I have two systems with native ipv6, and each have a /64.
As a further datapoint, I have two systems with native ipv6, and each have a /64.
Linode has a /30: http://whois.arin.net/rest/net/NET6-2600-3C00-1
That's equivalent to 4 /32 subnets, or 2^34 = 17,179,869,184 /64 subnets. I think they could afford to give each customer a /64.
IPv6 subnets don't really get smaller than /64. The way the routing is configured, the first 64 bits are "network address" and the last 64 bits are the "interface address". One /64 subnet has 2^64 addresses, about 18.4 quintillion.
IPv6 subnets don't really get smaller than /64. The way the routing is configured, the first 64 bits are "network address" and the last 64 bits are the "interface address". One /64 subnet has 2^64 addresses, about 18.4 quintillion.
Sure, but remember each /64 takes up space in their router's routing table. Assigning every linode a /64 would take up quite a lot of memory, then.
What you're saying implies that they have a single routing entry for all their /128s currently, otherwise that would be the same number of routing entries. So, why can't they just have a single routing entry that aggregates all the /64s?
I really hope it is some sort of mistake, arpnetworks give you a /48 but I believe you are limited to /64 by default.
Even so though tunnel brokers give out /64's and having to pay for that with native support would be rather silly.
Even so though tunnel brokers give out /64's and having to pay for that with native support would be rather silly.
[deleted]
Well they also give you a single IPv4 address, and they scale it proportionally for IPv6. This is just like having one IPv4 address times one IPv4 address times one IPv4 address times one IPv4 address.
> Can I get more than one IPv6 address?
>
> A single IPv6 address can be assigned to your Linode for free.
I think we should give Linode the benefit of the doubt on this for now.
Depending on how their instances are isolated from each other, it may be difficult to handle prefix delegation all the way down through the individual hosts into the guests.
Even Google had some hacks when they first started bringing up IPv6 support. For example, GMail would display class E addresses instead of the v6 addresses when you viewed last account activity. It was a temporary hack to shoe-horn v6 addresses into their management system.
Depending on how their instances are isolated from each other, it may be difficult to handle prefix delegation all the way down through the individual hosts into the guests.
Even Google had some hacks when they first started bringing up IPv6 support. For example, GMail would display class E addresses instead of the v6 addresses when you viewed last account activity. It was a temporary hack to shoe-horn v6 addresses into their management system.
As I understand it, they don't yet have any automation for setting up /64 prefix routes yet, so every /64 deployed has to be manually added to the router configs. Anyway, you're free to set up your own routing rules using that /64 to forward subnets of it on to different linodes.
Can someone dumb down this explanation for me? Why this is a step backwards? I realize there is an absurd amount of IPv6 address space, but my Linode account only gets one IPv4 address for free, why is this different?
It's actually more work to give you one address (a /128) than to assign you a /64.
Everything in ipv6 assumes a /64 is the basic unit of allocation. For example, the stateless autoconfiguration system that replaces much of DHCP assumes it has a /64 to work with.
Linode probably has 4 billion /64s to play with (with options on trillions more if they should need it), why not give out one per customer?
Everything in ipv6 assumes a /64 is the basic unit of allocation. For example, the stateless autoconfiguration system that replaces much of DHCP assumes it has a /64 to work with.
Linode probably has 4 billion /64s to play with (with options on trillions more if they should need it), why not give out one per customer?
I'm actually puzzled by all the Linode-bashing here. I'm not personally a Linode customer (or associated with them in any way) but this seems like a good thing.
To my knowledge (and I may have missed something) Linode is one of the first VPS providers to do IPV6. So I thought this was awesome.
If lots of other VPS providers start doing IPV6, and don't charge for a /64, or charge less than Linode does, Linode will have to change their fees or lose customers. But until that happens, why bash Linode for an as-yet unspecified charge?
To my knowledge (and I may have missed something) Linode is one of the first VPS providers to do IPV6. So I thought this was awesome.
If lots of other VPS providers start doing IPV6, and don't charge for a /64, or charge less than Linode does, Linode will have to change their fees or lose customers. But until that happens, why bash Linode for an as-yet unspecified charge?
Is there a guide somewhere to get HE working with Linode?
Just follow the HE tunnel setup instructions like you would for any non-linode host or border router.
The Linode Library has some instructions: http://library.linode.com/networking/ipv6-tunnels
No only does HE give you a full /64, but they'll also route you an entire /48 if you click the "allocate" button on the tunnel properties page.
This will soon be the biggest barrier to support of IPv6: the cash they make from leasing and selling their allocated IPv4 address space.
The owner of Linode (caker) has clarified on IRC stating that the /128 will be provided to each node, however they will also provide a /64 per datacenter, per account upon request for a nominal fee. The /64 will be routed to your /128 so that you can control how the addresses in your /64 are handed out. The fee has not been disclosed, yet.
So in short it isn't a misunderstanding and they want to charge you per item for something that, for all intents and purposes, is like a single drop of water in an ocean.
Be aware that IPv4 is also still /extremely cheap/ - way less than $1/ip/year if you have any volume at all.
When people charge you for IP addresses, the money is for the effort required to deal with justifying them to your rir, setting them up, routing, and maybe to cover abuse (my experience has been that the amount of abuse work i have to put in to a customer correlates somewhat to the number of IP addresses they have) And yeah, probably a good chunk of profit.
The price of an IP, right now, has almost nothing to do with it's scarcity.
When people charge you for IP addresses, the money is for the effort required to deal with justifying them to your rir, setting them up, routing, and maybe to cover abuse (my experience has been that the amount of abuse work i have to put in to a customer correlates somewhat to the number of IP addresses they have) And yeah, probably a good chunk of profit.
The price of an IP, right now, has almost nothing to do with it's scarcity.
They want to charge you for the drop, the space in their RIB to store the drop, the maintenance effort required to keep the RIB entry configured correctly, and the ongoing support costs of people who do things with their Linode boxes that require more than one IPv6 address.
The cost of maintaining a /64 is the same as maintaining a /128, and might even be less.
/64 is the basic unit of allocation in IPv6 and all of the tools and allocation protocols assume it.
/64 is the basic unit of allocation in IPv6 and all of the tools and allocation protocols assume it.
The cost isn't the same if /128s select for high-maintenance customers.
A drop of water compared to the volume of Earth's oceans is about one part in 2^84, so your analogy is a bit of an exaggeration, as there are only 2^64 /64s to be handed out. Still, there are plenty of allotment sizes larger than /128 that are still not scarce enough to bother charging for unless you have some other leverage (lock-in or a unique advantage on some related product).
They want to charge you for the static route you've added to their (finite) router memory, and the administrative overhead for adding it when they don't have the process automated yet.
Looks like this is somewhat dependent on their data center providers:
This will be a phased roll-out across the facilities, starting with immediate availability in Fremont, Newark in a week or so, followed by Dallas.
From the FAQ[1] page:
This will be a phased roll-out across the facilities, starting with immediate availability in Fremont, Newark in a week or so, followed by Dallas.
From the FAQ[1] page:
Fremont, CA: Yes
Dallas, TX: Soon
Atlanta, GA: No ETA
Newark, NJ: About a week
London, UK: Q4 2011
I'm really glad to see IPv6. I dearly love Linode. But only one address?
On the same day that Slicehost announced that it will move into Rackspace because of the transition to IPv6… What are the odds?
It might be related, but from the release schedule it seems pretty clear that at most Slicehost prompted Linode to release this feature a few months earlier than planned.
Not so subtle dig at slicehost/rackspace...
"Does this affect existing and new Linodes?
Nope. Not at all. No forced migrations here. "
Native isn't available in their London DC yet. Doesn't matter though. I've been using a free IPv6 tunnel broker whos end point is less than 1ms away from my Linode:
http://tunnelbroker.net/
http://tunnelbroker.net/
Considering Linode's main datacenter is he.net in Fremont, CA I don't see why they are billing for ipv6 as it's free for them. Also he.net in fremont has ridiculously cheap bandwidth and colo pricing with routes a bit better than cogent which isn't really saying much.
Their 'main' datacenter? All 5 DCs are actively used. In fact, if any DC were to be called their main DC, I suppose it would be the Softlayer (formerly The Planet) DC in Dallas.
While the geek in me thinks this is really super cool, the realist in me wonders why on earth I would need an IPV6 address _now_. All though we're "out" of IPV4 addresses, no hosting company has run out (I can still get all the IPV4 based VPS's & dedicated servers I want). Maybe I care 4 years from now, but I'm not sure I really care now... except it is really cool.
The point of dual-stack servers is to more efficiently serve the imminent DS-Lite clients where IPv6 is more efficient than IPv4.
"DS-Lite"?
http://en.wikipedia.org/wiki/IPv6_transition_mechanisms#Dual...
(What a shame; they gave this protocol an un-Googleable name.)
(What a shame; they gave this protocol an un-Googleable name.)
Phew! I was hoping it wasn't something to do with Nintendo! Thanks!
This is the perfect time to get practice using IPv6, so you're not scrambling when it _does_ get scarce :)
That's a really good point. Although if it's just for practice I's rather wait for it to come to EC2 and just pay by the hour to practice.
Are they just thumbing the nose at rackspace/slicehost here? I'm amused either way. They should offer a credit or discount for switching right now. I think it'd convert like mad.
Not really. Ipv6 support has been an open and much-discussed wishlist feature on the Linode forums for ages, and a few months ago they finally committed to providing it ASAP.
That is awesome news!
Any Aussies wanting good quality ipv6 vps hosting should check out networkpresence.com.au they rock
Granted, you're paying for addresses pooled among hosts with failover, which could be well worth paying for.
But come on Linode, a single IPv6 address allocation is ridiculous.
Update: Found this post by caker (linode guy) http://forum.linode.com/viewtopic.php?t=7055&highlight=i...
He mentions a third option involving a /64, does not mention if it will cost extra:
"We'll also be rolling out support to have an entire /64 routed to one of your IPv6 Linodes, which you can then route wherever you please."