I believe the reason Linode is offering only one IPv6 address at this point is purely technical (it is easier for them to setup) and has absolutely nothing to do with the ridiculous notion that IPv6 addresses "should not be given out like candy".

IPv6 was DESIGNED with the idea that every computer will get /64 address space.

I think some people here are taking their IPv4 mindset and applying it to IPv6 as they're scared of address exhaustion. We've got to cram every user into a single /64 to save the IPv4 mess from happening again!

A single address per machine is fine, however if someone wants to start routing those IP addresses - don't think like IPv4.

If I want to tunnel my home network behind a Linode, ideally I'd need a /48. Allocate a couple of addresses inside a /64 for the Linode and my router, and then route a /64 to my home router. If your head is still allocating things the IPv4 way, say a couple of addresses for the Linode and router, and then a /112 because 65k addresses is surely enough? Oooops, now it's impossible to use radvd because you're using ridiculous netmasks.

IPv6 was designed so that all the routing goes on in the first 64 bits of an address.

Where did you get that idea from?

IPv6 official specification documents.

rfc3177 (Recommendations on IPv6 Address Allocations to Sites) recommends assignment of /48 to end consumer sites (this is significantly more than /64, just in case this needs to be explained also).

And /48 per consumer site is in fact the norm among current IPv6 ISPs and hosting providers. So if Linode gives us /64 per node they will be behind standard recommendation and accepted norms. But not as far behind as they will be if they continue with one IP per node approach.

Knowing the quality of people behind Linode I don't doubt for a second that they understand all this very well, and the current one IP per node is just a temporary solution.

A question:

Great news for the net and for new customers, but what is the improvement on switching to IPv6 for existing linode customers?

Does it worth the effort?

That RFC has been obsoleted by RFC 6177 as of March. In either case, the recommendations apply to end sites, not individual hosts. There is nothing in either RFC, to the best of my knowledge, that mandates or recommends allocating a /64 to a single host (server, workstation, toaster, etc).

ISPs and tunnelbrokers assume that they are providing connectivity to a site with multiple hosts, and as such, they purvey according to RFC 3177 (and 6177) recommendations.

Your Linode is a single host, and as it shares a single layer 2 subnet with thousands of other hosts, it can (and, for all practical purposes, must by default) achieve connectivity within the spirit and letter of IPv6 allocation standards using a single IP address within a common /64.

(Again, same thing as the point-to-point /64 of a HE tunnel, or even the IPv4 /24 your Linode already has.)

_________________

/* TODO: need to add signature to posts */

I have not understood why it worth the effort, I'm not a sys admin, I'm not really focused on this matter.

Are you saying that we "must" switch to IPv6?

Eventually, yes. There will be a point in the future when there are hosts on the internet that can only be accessed via IPv6.

No it's not. Why the hell would every single IPv6-enabled device need 18,446,744,073,709,551,616 addresses assigned to it?

Look at IPv6's built-in stateless address autoconfiguration. A device can negotiate or derive its single unique address, along with routing information. There is no mechanism in autoconf to receive anything larger than a single address. IPv6 is designed, quite deliberately, for each device to have ONE address.

What you're confused by is the encouragement to use one /64 per site or network -- like a campus, or a datacenter, or an office. And then devices within that subnet negotiate for one individual address.

-Chris

There are far more "clients" on the Internet than there are "servers", so any notion of conserving IPv6 address space on servers while every client automatically gets /48 (or at least "more than /64" as the updated document puts it) is quite frankly ridiculous.

Having abundant addresses on a typical server is extremely beneficiary. We have been running with address shortage for so long, some of us can't imagine things being done any other way.

Typical servers are comprised of multiple virtualized hosts (if you serve more than one web site from your node your server is one of them). We have worked out address conservation techniques (for some of the services) to make these multiple hosts survive on single IP (HTTP host header, SNI, NAT, etc.) but all these workarounds come at a price (performance, complexity, flexibility, etc.).

If we switch to IPv6 with it's abundant address space, it would be truly ironic if VPN on your server will continue to utilize NAT for logged in remote VPN clients because your hosting provider have given you a single IPv6 address for your node.

Some of you people are unbelievable.

I'm guessing 'caker' has a reliable xanax connection in order to keep the top of his head from blowing off dealing with some of you whiners.

IPv6 is no where near production ready. Leaving the Linode Data Center on IPv6 and you get to go where on native IPv6?

1 IPv6 is plenty to play with, and it's already been announced more will be available for a small administration fee.

Geesh people - what more do you want from a AFFORDABLE VPS host that provides top notch tech/service?

I think you are confused. The encouragement is to use "more than /64" per site or network, specifically to allow assigning /64 to every computer. The idea is that computer will no longer have to use NAT for things like connected peripherals, VPN clients, virtualized services etc.

As to "why the hell" every computer would need so many? I agree, the whole 128-bit address scheme was a definite overkill (seems they overcompensated for the previous blunder of using too little address space by using far too large), but what's done is done, we are moving to 128-bit address space, and it would be beyond ironic if our servers will end up with a single IPv6 address.

While IPv6 RAs only support 1 IPv6 address each, there's nothing stopping you from sending multiple of them. Even my home computers get 2 IPv6 addresses each, one in my 6to4 subnet and another in my HE tunnelled subnet, all automatically.

As for automatic subnet assignments, that's what DHCPv6 PD is for (read: real world ISPs already rolling this out, that's how we get our /64 at work), and you should be able to send multiple of them too, even if each related to a different RA; haven't tested the multiple DHCPv6 PD scenario yet though.

Cheers,
Antonio

I think at this point I'm going to join the incredulity bandwagon with vonskippy. How do we reach points like this, especially given Caker's earlier comment - the very first response in this thread no less! - about shared data center blocks and /64s being available down the road? Is it that horrible that out of the gate we get a single endpoint address for each Linode and does anyone really believe with the generally intelligent way Linode provides for most other resources that we won't have reasonable blocks available as the implementation proceeds?

I'm happy to be able to test native IPv6 at this point (or over the next short while depending on my Linode's data center), and expect I'm doing so earlier than if I had to wait for the controls for address block assignment, management and routing were in place. If I absolutely need to test managing a larger block, I'll stick with the HE tunnels for now, which are eminently usable for that purpose.

But it's not like I seriously expect that larger blocks won't be available if needed. To be honest I'm not really sure that I'd need a single Linode to have a /64 anyway - I find Caker's suggestion of blocks sharable among my Linodes in a single DC much more interesting, in terms of practical impact. But I'm sure others have other needs. I just think we're getting a little out there with worry at this point.

-- David

Don't forget that it's autoconfigured, and local traffic is unmetered. Hang out on IRC for awhile and see how often people end up neck deep in alligators setting up a private IPv4 address.

If they'd gone with the tunnelbroker approach(*), people'd still be riding the pitchforks because the intent and spirit of IPv6 had been violated, but we'd also be damned to an eternity of it not working right with CentOS half the time. -rt

(*) The only way to get a subnet to each customer on Day 1, really. Routers have finite resources, and given that you probably don't want to renumber when you move to a different physical host, something's going to have to keep track of every subnet...

_________________

/* TODO: need to add signature to posts */