Worldwide IPv6 Adoption: Where Do We Stand Today?

skade88 writes "IPv4 is much like a limited natural resource; it can't last forever. The well of new IPv4 addresses is already running dry in many parts of the world. The solution to this problem, which was presented decades ago, is to switch to IPv6. With peak IPv4 far behind us, why do we still see limited IPv6 adoption? Ars takes a good look at where we are and where we are going with the future of IP addresses, the internet and you. Quoting: 'As with all technology, IPv6 gets better and cheaper over time. And just like with houses, people prefer waiting rather than buying when prices are dropping. To make matters worse, if you're the only one adopting IPv6, this buys you very little. You can only use the new protocol once the people you communicate with have upgraded as well. Worse still, you can't get rid of IPv4 until everyone you communicate with has adopted IPv6. And the pain of the shrinking IPv4 supplies versus the pain of having to upgrade equipment and software varies for different groups of Internet users. So some people want to move to IPv6 and leave IPv4 behind sooner rather than later, but others plan on sticking with IPv4 until the bitter end. As a result, we have a nasty Nash equilibrium: nobody can improve their own situation by unilaterally adopting IPv6.'"

Comments

Re:That's easy.

[Ultra64]

Not really, you just track them by their IPv6 subnet prefix instead of their full IPv4 address

The reason why is

[Anonymous Coward]

With peak IPv4 far behind us, why do we still see limited IPv6 adoption?

The reason why is simple: because we haven't run out of IPv4 addresses yet.

Re:The reason why is

[YodasEvilTwin]

This. You can't stick with IPv4 if you have no IPv4 address to use.

Re:The reason why is

[Forty Two Tenfold]

With peak IPv4 far behind us, why do we still see limited IPv6 adoption?

The reason why is simple: because we haven't run out of IPv4 addresses yet.

Close: because for the time being the costs of the transition are higher than those of maintaining the status quo.

Re:The reason why is

[Anonymous Coward]

There are lots of IPv4 addresses, many of them are wasted. I know a school that has a class B block and maybe uses 200 of them.

Also, with NAT, the address space grew massively since few people or organizations need or want a lot of publicly routable IP addresses.

Re:The reason why is

[Anonymous Coward]

True, we just need to get the assholes who don't use them to give them back!

Re:The reason why is

[unixisc]

It's not easy to return them, no matter how few they may be using. So that school that has the class B block can keep all 4096 of them.

As far as NAT goes, one level of NAT is one thing. But when you have multiple levels of NAT, the connectivity deteriorates, as the number of points of failure just escalates. Also, organizations that use IP phones do need as many publicly routable IP addresses as they have phones. Just that due to the shortage, they settle for NAT wherever they can, and use dedicated routable IP addresses where they must. Also, the most common form of NAT used is Port Address Translation, and in this one, one needs more routable IPv4 addresses - just 1 won't do. And so even NAT can't for the long run alleviate the demand on IPv4 addresses.

Re:The reason why is

[unixisc]

Problem is that those 'assholes' would have to again remap and reconfigure their entire network if they had to subnet it further and consume only what they need. Also, even if those 'assholes' were to switch to IPv6, that's no reason to give up the IPv4 addresses that they have, when they will need them for dual stacked networks.

What they can do is use those IPv4 addresses for all external facing services that must be available on both protocols. In the meantime, they can migrate internal applications that are big address consumers to IPv6 - such as internal servers, intranets and so on.

Re:The reason why is

[haruchai]

A Class B block would be 65538 addresses, not 4096.

Re:The reason why is

[haruchai]

Sigh, 65536 not 65538

Re:The reason why is

[unixisc]

Thanks. But my point remains unchanged - the school would have to redo their network mapping and configuration in order to use just a subnet of the block that it has. Assuming that they have IT resources at all to look at this issue, they should just add IPv6 support, migrate to that, and then use the class B block as a dual stack IPv4 companion to all the IPv6 stuff they have.

Re:The reason why is

[unixisc]

Actually, 65534 - the network address - .0 and broadcast address - .255 - won't be usable.

Re:The reason why is

[haruchai]

Well at most. In this day and age, a flat /16 network is not likely and they'll lose 2 addresses for every subnetwork they create.

Re:The reason why is

[petermgreen]

Also, organizations that use IP phones do need as many publicly routable IP addresses as they have phones

Only if they

1: use the braindead but sadly popular protocol called SIP that doesn't play nice with NAT.
2: try to route that protocol over the open internet directly from individual phones

If the organisation does the sensible thing and routes all phones through a PBX then this isn't really an issue. Only the PBX needs public IP space.

Also, the most common form of NAT used is Port Address Translation, and in this one, one needs more routable IPv4 addresses - just 1 won't do. And so even NAT can't for the long run alleviate the demand on IPv4 addresses.

There is a limit to the number of customers per IP address but it's high enough that most ISPs who deploy NAT won't be running out of IPs in the foreseeable future. If world population increases by orders of magnitude we may have a problem but frankly if world population increases that much we are likely to have bigger problems.

Re:The reason why is

[badkarmadayaccount]

NAT the existing addresses 1:1 with new ones from a smaller allocation, and release the block. One transparent appliance away.

IPv6 Internet is "here" for some of us

[insecuritiez]

I have a native, public, non-tunneled IPv6 address at home through my non-business Comcast cable Internet service. My computer and phone automatically use IPv6 whenever available.

I can use IPv6 at work too.

It's already here and adoption seems to be accelerating.

Re:IPv6 Internet is "here" for some of us

[Mashiki]

Must be nice. My ISP's DSL side is on IPv6, their cable side isn't because the company that they buy their headend connection through(rogers) still hasn't finished upgrading everything. My modem is good to go, and has been for over three years.

Re:IPv6 Internet is "here" for some of us

[Anonymous Coward]

Same. Though I turn it off sometimes because the latency is a little worse right now. Presumably IPv6 traffic doesn't always get the best/fastest paths yet.

Re:IPv6 Internet is "here" for some of us

[insecuritiez]

It's very nice. I was in the process of setting up a tunnel between my home gateway and a Linode machine (Linode provides native v6) and making Linode my publicly visible exit point to the Internet. A few weeks into the project Comcast implimented v6 making my tunneling efforts redundant.

Comcast currently allocates a /64 to each customer but they say they'll hand out shorter prefixes later.

I currently use "privacy addressing" with my Linux machine which I do with:
# IPv6 privacy stuff
echo 209600 > /proc/sys/net/ipv6/conf/wlan0/temp_valid_lft
echo 10800 > /proc/sys/net/ipv6/conf/wlan0/temp_prefered_lft
echo 128 > /proc/sys/net/ipv6/conf/wlan0/max_addresses
echo 2 > /proc/sys/net/ipv6/conf/wlan0/use_tempaddr

This is mostly so that I'm trying out the most extreme end of IPv6 where I'm going through addresses quickly and have up to 128 at a time.

Re:IPv6 Internet is "here" for some of us

[Mashiki]

Useful and very nice.

Re:IPv6 Internet is "here" for some of us

[Stiletto]

Say what you will about Comcast, their support for native IPV6 has been impressive

Re:IPv6 Internet is "here" for some of us

[jbgeek]

Yeah. And ironically, Comcast Business doesn't offer IPv6 yet, so I'm still tunneling. :-(

If only their "business class" service were as aggressive about it as their residential service. And more irony, the only reason I have business class I can have static IPv4 addresses.

Re:That's easy.

[Anonymous Coward]

I'm not taking any chances... I've moved our network to IPv8

Re:That's easy.

[Anonymous Coward]

...what? It makes it EASIER to track people.
Considerably easier, in fact.

Re:That's easy.

[Anonymous Coward]

How so? Many (if not most) end system addresses have the MAC address embedded in the v6 host address, so you get more information out of a v6 address than you do out of a v4 address (including the ability to trace the same device even if it changes layer-3 networks).

Since most vendors aren't supporting RFC 3972, tracking is probably going to be easier, not harder.

NAT

[Anonymous Coward]

with NAT, the ability for millions of machines to share a single IP, the immediate need for new available IPs has somewhat been averted.

Re:NAT

[Anonymous Coward]

How do you have millions of machines when there are only 65536 ports?

Re:NAT

[loufoque]

65535. 0 is reserved.

Re:NAT

[petermgreen]

Not millions

With conventional NAT reserving a port on the public side for each connection I doubt you'd want to go more than about a hundred customers per IP (and even that may be pushing it if your customer base is high activity). Dedicated high ratio nats that resused the same source port for connections to different servers may let go up to say a thousand customers per IP but

Still even a 1:10 ratio would mean that most ISPs wouldn't have to worry about exhaustion on the consumer side for a long time and on the hosting side SNI should become practical to deploy in a couple of years dramatically reducing IP space requirements for shared hosting.

I hope that ISPs will offer IPv6 before they start forcing users behind NAT but I wouldn't rely on it.

If you are designing a new deployment now I STRONGLY advise you to avoid relying on the ability to accept incoming connections to equipment located in homes or small offices and to minimise the number of public v4 addresses you need in your central facilities (could be just one to terminate IPv6 over UDP tunnels from the homes and small offices).

Re:NAT

[Anonymous Coward]

WTF?

65535 ports on each machine and ya know, you can forward via ip address and port?

Very few of the machine behind a NAT are running servers.

Re:NAT

[Anonymous Coward]

Why do you think that matters? The only limitation here is the amount of simultaneous connections to a single IP address. If traffic is coming towards me on port 1234 from 1.1.1.1:1122, I know that that should go to my client 192.168.1.1 because I saw that client send traffic to that ip and port from that port (or the port I mapped it to if more than one client tried to speak to the same ip:port from the same port) If I see traffic coming to port 1234 from 2.2.2.2:1122 at the same time, that doesn't go to 192.168.1.1 because that client didn't send traffic there; 192.168.2.2 did. And in fact, if I see traffic coming from 1.1.1.1:2233 at the same time as well, then that still wouldn't go to that first client because it would still be a different flow. And that's just sticking to ip:port pairs to keep track of the flows-- in theory one could also use other methods to classify packets as belonging to a certain flow.

The total number of connections available to a NAT box thus is pretty much limited only by available memory in said NAT box.

Re:NAT

[jbolden]

ARIN has been pretty clear they don't want carrier grade NAT. The carriers don't want carrier grade NAT. You aren't going to be forced behind a NAT. You'll have a v6 address and pool for v4 outgoing once they roll out v6.

Re:NAT

[Subjective]

each local port is linked to a list of remote hosts, differing by IP address and remote port
You fail to allocate a new connection only if you can't find a local port for which there is no entry for the specific remote IP and remote port

Re:NAT

[unixisc]

A /128 or a /64?

Re:NAT

[jbolden]

Both. Right now for example on the /128 phone system when you do v4 traffic you end up in a pool. Similarly that's the intent for home / small business when they roll out /64.

I don't think they are going to roll out /128 at the ISP level. They really aren't supposed to be doing that and if they want traffic (i.e. phone sharing with computer, iPod...) then it makes sense to let the phone have a full /64.

Re:NAT

[unixisc]

/64 is the only thing that makes sense. I'm thinking of organizations - be it companies, schools, similar organizations. Let's say they want to have a certain #IP phones, as well as tablets, laptops, cellphones, IT TVs and so on. Give then a single /64 link, and they have all the addresses that they need for all of them. If their CPE includes DHCP6 and they have IT people who can configure that, they should be able to allocate a combination of static addresses, pools of dynamic addresses, dynamic addresses for VMs in servers, static addresses for things like web servers, e-mail servers and so on. If they need separate networks, such as multiple SSIDs, different networks for different speeds and so on, that's where the ISP could give them 2 or 4 links. Practically speaking, there is only a certain number of devices that can be sharing that network before it starts to slow down.

Essentially, ISPs should just issue one or more /64 links, and then just forget about it.

Re:NAT

[jbolden]

That is exactly the plan though even larger. Since generally you would want phones and computers on a separate subnet for something like a school you might very well give the district a /56, 256 subnets. Large businesses are going to be given /48s.

Re:NAT

[petermgreen]

ARIN has been pretty clear they don't want carrier grade NAT.

Well if the RIRs didn't want it they should have put some incentives in place to deploy IPv6. If they had made new v4 allocations to ISPs conditional on making IPv6 available to all customers and supported by all new customer premisis equipment supplied by the ISP then we wouldn't be in this mess now.

Growing ISPs are going to have no choice but to deploy some kind of mechanism for users to access v4 resources without giving those users a public V4 IP. There are basically 3 choices.

1: Run an IPv6 access network and use some mechanism (NAT64 or ds-lite, some kind of tunneled port based address sharing) to make access to the IPv4 internet available over that v6 access network.
2: Run a dual stack access network with public v6 and private v4 and an ISP level NAT
3: Run a IPv4 access network with private addresses and an ISP level NAT.

Round here (UK) most mobile providers are already giving out private v4 IPs and running NAT. Landline providers are still generally giving out public v4 IPs for the moment. Few providers seem to be showing much interest in making IPv6 available to customers. Our main telco is apparently even running a broken 6to4 relay in their network on the anycast address ( http://www2.warwick.ac.uk/fac/sci/csc/people/computingstaff/jaroslaw_zachwieja/bt_fttc_ipv6/ ). Given this situation I just don't have any confidence that ISPs will go the IPv6 route.

Re:NAT

[jbolden]

Well if the RIRs didn't want it they should have put some incentives in place to deploy IPv6.

They have. They have unequivocally indicated this is the direction for the industry, attacking ideas like carrier NAT. And they have burned through the IPv4 addresses fast so that ISPs wouldn't have a choice. The result is that most carriers and ISPs are now finally working through the IPv6 issues in a serious way and we will see more and more deployments.

Growing ISPs are going to have no choice but to deploy some kind of mechanism for users to access v4 resources without giving those users a public V4 IP. There are basically 3 choices.

They aren't doing any of those 3, though (1) is close. What they are doing for home / small business is what they already do on phones.

1) Long term IPv6 address (possibly fixed)
2) Pooled IPv4 addresses which are dropped when not in use.

As they begin to privilege IPv6 public services over IPv4 services (i.e. looking for IPv6 address first on DNS, lower latency, more bandwidth...) customers will naturally start migrating towards IPv6 usage mostly. With most people getting most common services from the IPv6 network, they might be able to able to get to something like a 4::1 or 5::1 ratio of homes to pooled IPv4 addresses very quickly. But there isn't going to be any NAT. While your household is using a IPv4 addresses it is exclusively your address.

Few providers seem to be showing much interest in making IPv6 available to customers.

Understood, but it doesn't matter. Right now we need carriers and ISPs to work through IPv6 we really don't need much from end users. For 2013 IPv6 for small end users is a nice, not a needed. It is important that enterprises start getting their IPv6 connections, for testing but that's about it. The focus should be on carriers working out the remaining issues on their side.

IP6 addresses are a pain

[Viol8]

We have so many test VMs appearing and disappearing on our network that we don't bother putting them in DNS, we just give out the IP4 192.168... address for the testers and devs. I dread to think what would happen if we had to give them the line noise that is an IP6 address. Whatever other merits IP6 has, the designers REALLY didn't think it through at the manual address entry level.

Re:IP6 addresses are a pain

[Aqualung812]

the designers REALLY didn't think it through at the manual address entry level.

Yeah, they did, and they decided that the only servers that need a manual address are DNS servers and DHCP servers (if you choose to run DHCP).
Outside of those, the only other things that need manual addresses are routers.

Everything else should use Dynamic DNS.

Give me a good reason why someone shouldn't be using DNS instead of direct IP address, other than lazy programmers.

Re:IP6 addresses are a pain

[Trepidity]

I'm not sure what else you could do for a 128-bit address. The format isn't inherently any more complex, just longer: instead of four 8-bit numbers separated by dots, it's eight 16-bit numbers separated by colons.

If you have some kind of regularity in the addresses, there are also alternate formats you can use, if you find it more convenient, to try to make them shorter and easier to type. For example, you can omit segments that are 0, and collapse consecutive such segments, which is why you can write the loopback address as ::1.

Re:IP6 addresses are a pain

[tatman]

Agreed. IP4 was simple to read. just a set of number groups. And likewise, it was simple to communicate. IP6 is hex values or something (not sure whats the % is in "Reply from fe80::f9ee:eb6f:8c74:52f5%16: time1ms"). When I ping something I always turn on the IP4 switch.

Re:IP6 addresses are a pain

[PlusFiveTroll]

Your routing prefix is unlikely to change (first 48 bits)
Your subnet id says the same per 'net' and only varys if you have more then one addressable network (16 bits)
the last 64 bits are the easy part...
type :: to compress out the 12 zeros you don't need to type then start at 1 and go up to ffff

Just avoid automatic addressing for systems that you are going to access like servers. Everything else should use a automatic dns registration system when getting an IPv6

ANY 128 bit address is going to have 'human' issues at the entry level because people don't handle that many bits well.

Re:IP6 addresses are a pain

[Anonymous Coward]

Easy, to get around DNS-based censorship and blocking.

Re:IP6 addresses are a pain

[gclef]

One good reason why *servers* shouldn't be using DynamicDNS? I'll give you two.

First scenario: your server isn't responding. How do you tell the difference between a failure of the server itself and a Dynamic DNS registration failure? If you don't know it's IPv6 address, how can you tell if its fine, just not registering in DNS properly? Heck, if it's not registering properly, how do you find it at all?

Or, more fun: the server reboots & ends up with a different dynamic IPv6 address....even if it registers the new address to its name properly, clients don't always honor DNS cache times, and will keep trying the old address for a while. You've now created an outage for no good reason.

If you said that desktops don't need static DNS, I'd agree with you completely. But making server infrastructure totally reliant on a middle layer is asking for trouble...things'll work fine until you have a problem & need to troubleshoot. Then your reliance on an external system will bite you in the ass.

Re:IP6 addresses are a pain

[Viol8]

"Give me a good reason why someone shouldn't be using DNS instead of direct IP address, other than lazy programmers."

I'll give you a number of good reasons - manpower , deadlines, simplicity. When you get a proper job instead of playing around at college you might understand.

Oh , and programmers generally don't set up DNS. Just FYI.

Re:IP6 addresses are a pain

[MartinG]

You can do that with your hosts file instead. Or use an alternate DNS server. Or run your own. (etc.)

Re:IP6 addresses are a pain

[MajroMax]

If DNS/DHCP is so difficult, then you can do exactly the same address assignment with ipv6 that you do with ipv4: give out a static /64 to each group-of-VMs, and let the testers/devs themselves pick individual machine numbers from that prefix.

If you want to be really short, then generate an unique local prefix (/48) for your test networks, and subdivide from there according to whatever scheme you want, like fd8a:db80:db80:building:floor::[machine]

Re:IP6 addresses are a pain

[arth1]

For example, you can omit segments that are 0, and collapse consecutive such segments, which is why you can write the loopback address as ::1.

To be fair, you can do that with IPv4 too. Using 127.1 for the loopback address or 192.168.1 for a typical NAT gw address works just fine.

Re:IP6 addresses are a pain

[MajroMax]

It's probably the index of your machine's IP that received the echo reply. An IPv6-connected host will have many addresses of different scope, so some implementations use the "%" to distinguish which of your addresses has handled a connection.

Re:IP6 addresses are a pain

[maz2331]

Seriously, it sounds like SOMEONE can't convert between decimal and hex.

The addresses are easy once you get even slightly used to them, and once you memorize your /48 or /64 prefix is no more difficult than v4. 2001:123:45:67::2E/64 isn't hard. [2001:0123:0045:0067:0000:0000:0000:002E]. I have memorized our /48 and our usual scheme is to split it into /64s that then match the 3rd octet of our 192.168.x.x private range...so for example, I'd set up a host that is on 192.168.16.5 as 2001:123:45:10::5/64.

Or even better... just let the router on the subnet autoconfigure the hosts, or setup DHCPv6 on a server.

(Ocourse the 2001:123:45 addresses are totally made-up and fictitious... no need to give my real-world v6 netblocks on here!)

Re:IP6 addresses are a pain

[Denis Lemire]

Multicast DNS for the win.

Re:IP6 addresses are a pain

[Anonymous Coward]

Great logic. The solution which requires the least man-power automatically wins. Let's see where that would get us in all other areas... Or no, let's not.

Re:IP6 addresses are a pain

[Fred Foobar]

That address is a link-local address. The number following the percent sign is the zone index, which specifies which network interface the address is on. If it were not there, the address may be ambiguous with multiple interfaces (imagine if two hosts on two different network segments had the same IP address; neither host can talk to the other but the machine you're on can talk to both through separate interfaces). I don't think IPv4 handles this case at all. Indeed, RFC 3927 discusses address ambiguity but provides no real solution for it. IPv6 provides a solution in the form of zone indices.

Re:IP6 addresses are a pain

[Anonymous Coward]

I know. I run a Macintosh website - why are there letters?!

If anything, the new IP addresses should be shorter.

Re:IP6 addresses are a pain

[sl4shd0rk]

Give me a good reason why someone shouldn't be using DNS instead of direct IP address

Here's 4. Not trying to be a wiseass, but there are times when bypassing DNS is preferable.

1) When you cannot trust your DNS source
2) DNS is not working or too slow
3) You didn't want to/need to spend $$ registering a domain
4) Your IP changes but DNS hasn't updated yet

Re:IP6 addresses are a pain

[YodasEvilTwin]

int ip = resolve(hostname); //int ip = 192.168.0.1; connect(ip); That's really going to fuck with your deadlines?

Re:IP6 addresses are a pain

[Anonymous Coward]

Prey tell how you decide if that is...

192.168.1.0
192.168.0.1
192.0.168.1
0.192.168.1

Admitted, one of these is not a valid IPv4 addresses. But neither are yours...

Re:IP6 addresses are a pain

[Anonymous Coward]

Outside of those, the only other things that need manual addresses are routers.

And not even all routers, if you use DHCPv6-PD.

Re:IP6 addresses are a pain

[girlintraining]

Give me a good reason why someone shouldn't be using DNS instead of direct IP address, other than lazy programmers.

Not every address needs to be in DNS, or should be. DNS has no security safeguards -- it's meant to be public. Putting records in DNS can allow additional information to leak about your network, for example, the IP address of the management interfaces for your managed switches. These typically have very little in the way of access controls -- you can brute the password without audit alarms triggering in some cases. So giving everything a DNS record means every device on your network is now recorded for a potential intruder, by design.

Re:IP6 addresses are a pain

[Anonymous Coward]

real men use 0x7f.1

Re:IP6 addresses are a pain

[nabsltd]

3) You didn't want to/need to spend $$ registering a domain

You only need to register a domain if you want it in the public DNS space.

For something completely in-house, you can set your DNS server to be authoritative for any domain. The only caveat is that if it is a domain in the public DNS space, you won't know it. You would use this to do split DNS, so hosts resolve to the private IP address for internal clients, while the outside world sees the public IPs. Throw in some sub-domains that are only available inside (*.dev.example.com, *.stage.example.com, etc.), and things just work.

Re:IP6 addresses are a pain

[Anonymous Coward]

Umm... Seems you haven't understood how IPv6 addresses work. Everything starting with fd is private. So you could assign the addresses
fd00::1
fd00::2 ...
to your private VMs. Quite a bit shorter than then IPv4 192.168... madness.

Re:IP6 addresses are a pain

[gclef]

Multicast DNS for the win.

...Added complexity for the lose.

That's the entire point: adding another layer of complexity makes troubleshooting and management harder and more likely to fail in new and surprising ways. Making that new layer different (multicast DNS rather than unicast) does not solve the problem, it just moves it somewhere else. This is not better.

I have no problem with servers *using* multcast DNS, dynamic DNS, etc. I have a problem with *relying* on DNS as the only way to connect to a server. DNS fails. So does multicast DNS, and dynamic DNS. In each of those cases I should still be able to connect to my servers.

Re:IP6 addresses are a pain

[Anonymous Coward]

There is nothing accurate in your post. You should be ashamed. I know I am ashamed of you for providing such an answer. Its wrong, wrong, wrong. DNS should be used whenever possible. Only incompetent programmers would avoid DNS with very domain specific reasons.

Re:IP6 addresses are a pain

[Ultra64]

> These typically have very little in the way of access controls

I'm not sure why it's DNS' fault you bought shitty hardware.

Re:IP6 addresses are a pain

[WaffleMonster]

We have so many test VMs appearing and disappearing on our network that we don't bother putting them in DNS, we just give out the IP4 192.168... address for the testers and devs. I dread to think what would happen if we had to give them the line noise that is an IP6 address.

Whatever other merits IP6 has, the designers REALLY didn't think it through at the manual address entry level.

I know...take for example the IPv6 address of sprints public web site... It's huge...sorry I mean smaller than any possible IPv4 address.."2600::"

I think you have a choice. You can go for large unwieldy autogenerated messes of address from SLAAC or you can manually (or via DHCP) configure easy to use IPv6 address especially if it is for an internal network.

I do not think it is fair to assert both the idea manual configuration is required and IPv6 addresses are impossible to work with concurrently.

If you are manually configuring then intentionally handing out an impossible to type IPv6 address especially on an internal network does not make much sense.

Also keep in mind nobody is saying you have to dump IPv4 on an internal network EVER. Only your public facing resources EVER have to change.

Re:IP6 addresses are a pain

[Bengie]

I was going to say. My $30 network printer and Linux firewall can resolve local devices based on some standard broadcast name resolution. My firewall lists by device name+IP+MAC. If the local broadcast domain is working, name resolution should be working.

Re:IP6 addresses are a pain

[Anonymous Coward]

I don't want my servers to rely on another service to get their IP addresses, so I use fixed IPs and host files for internal stuff that doesn't see the internet.
Less complexity, fewer headaches, and no amount of beratement for being lazy is going to change those facts.

I rely on DHCP + DNS when I'm *actually* feeling lazy.

Re:IP6 addresses are a pain

[Dagger2]

The right-most octet in the abbreviated address substitutes for the right-most octets of the full address.

e.g.:
127.1 -> 127.0.0.1
192.168.1 -> 192.168.0.1
192.168.257 -> 192.168.1.1
10.65536 -> 10.1.0.0

Re:IP6 addresses are a pain

[Anonymous Coward]

So hand them static addresses. The 7th bit of any EUI-64 generated IPv6 address is always 1, quick rule for local ips is beginning the host part with "00" will avoid those clashes. Only problem would be privacy addresses which also sets the same bit to 0, but you probably wish to disable those in such controlled networks. You would still need to remember the subnet but that is longer because we sorta tried to solve a problem here.

As noted below, for internal access only, site unique addresses are possible in fd00::/8, so those special hosts could be given fd00::1, fd00::2 etc and if another subnet was necessary simply add fd01::XX. Clients only need to have their global addresses if proper routing is setup.

Re:IP6 addresses are a pain

[Anonymous Coward]

Um, are you insane?

You don't want your network servers to have a single point of failure - if the DHCP server goes, then the other servers cannot get their addresses and suddenly the entire network goes down the first time that a server reboots. Heck, and what about latency for updating DNS servers with the new addresses when DHCP assigns them (remember, DNS servers cache answers, typically for days, and if you try to turn off the caching it takes too long to get answers to your DNS queries).

IP addresses are identities - all sorts of havoc results when identities can change at random times. Anyone who has dealt with real-world networking issues knows that.

No, the problem with IPv6 was that it was an ivory tower effort. It took an idealized view of networking which simply is not realistic. In the real world one has to account for all sorts of scenarios that "shouldn't happen". Heck, IPv6 didn't even take redundant routing into account by using a hierarchial methodology for assigning global IP addresses (the carrier's prefix followed by your suffix - if you have multiple routes to the internet via multiple carriers for redundancy and fault tolerance, the IPv6 wanted to assign different IP addresses for each path which completely broke the fault tolerance model - let routers handle routing, let addresses define identity - IPv6 merged the two concepts together and broke the model).

Re:IP6 addresses are a pain

[91degrees]

Give me a good reason why someone shouldn't be using DNS instead of direct IP address, other than lazy programmers.

Why is "lazy programmers" not a good enough reason in itself? Programmers are lazy. That's why they learn to use computers. Because they don't like doing tedious repetitive work. I can plug a bunch of devices into a router and be reasonably certain that they're going to have IP addresses in the range 192.168.1.2 to 192.168.1.255. I don't need to tinker with each one individually and set up a name. I have more important things to do than fiddle around setting things up.

Re:IP6 addresses are a pain

[Anonymous Coward]

Or, more fun: the server reboots & ends up with a different dynamic IPv6 address....

Clients can use SLAAC and/or DHCPv6; perhaps using privacy extensions to prevent public tracking.

Servers can give themselves IPv6 address based on their MAC. Deterministic results, unless you change NICs... of course you can have the MAC-based address come up on the first boot, and then hardcode that in /etc somewhere.

This is not rocket surgery.

Re:IP6 addresses are a pain

[DigiShaman]

Funny thing about DNS. They solve just about as many problems as they solve in the world of IT. A double-edge sword of a solution.

Re:IP6 addresses are a pain

[cdwiegand]

Wow.. if only it were that easy! No, you don't resolve a hostname to an IP, you resolve it to a List of IPs, some of which may be IPv4 and some of which may be IPv6.

Re:IP6 addresses are a pain

[31eq]

MAC address

Re:IP6 addresses are a pain

[Anonymous Coward]

Security.

Re:IP6 addresses are a pain

[petermgreen]

I dread to think what would happen if we had to give them the line noise that is an IP6 address.

IPv6 addresses don't HAVE to look like line noise. Yes they are longer but that length gives you more freedom to maintain an addressing pattern that matches your network rather than having to pack things in a massively dense fashion. The main thing is to avoid using stateless autoconfiguration for any IP a user is likely to need to interact with.

Having said that there is really no reason to not continue using private IPv4 for logging into boxes regardless of whether they have a v6 IP to let them access resources on v6 networks (public or private).

Re:IP6 addresses are a pain

[arth1]

Admitted, one of these is not a valid IPv4 addresses.

They're all valid. One is reserved, and one is unassigned, but all are valid.

But neither are yours...

Actually, yes, they are.

127.1 = 127.0.0.1
192.168.1 = 192.168.0.1

All conforming tools will understand the short forms, including the OS resolver. Just try it - open a command prompt (whether in Linux, Windows or other) and try:
ping 127.1

Another common one is:
0 = 0.0.0.0
A system with a nameserver running on it will often have a line "namserver 0" in /etc/resolv.conf - that ensures it will use its own nameserver whether it's listening to localhost or not.

Re:IP6 addresses are a pain

[FridayBob]

... Give me a good reason why someone shouldn't be using DNS instead of direct IP address, other than lazy programmers.

From a management perspective it's a solid advantage for me to give fixed IPv6 addresses (via DHCPv6) to all of my (Linux) workstations, just as I did before and still do with IPv4. IPv6 not only allows me to access them directly via the Internet without using SSH tunnels, but fixed IP addresses in general (with both forward and reverse DNS entries) are also essential for the Kerberos authentication system that we use.

As for whether IPv6 addresses are a pain to work with, it would seem that way if only the kind of addresses that result from stateless autoconfiguration are considered. However, when using fixed IPv6 addresses it's unnecessary to make the host portion of the address so complicated. For example, with stateful autoconfiguration (using DHCPv6) we can choose to give workstations much shorter addresses, like 2001:888:abcd:25::21.

Re:IP6 addresses are a pain

[unixisc]

Doesn't DHCP6 allow you to assign static, as well as dynamic addresses, in the same way that DHCP4 does?

Re:IP6 addresses are a pain

[icebraining]

But nobody is saying we should burn all traces of IP addresses, just that manually writing them should be a negligible use case. One can just copy/paste the IP from some file if DNS happens to break.

Re:IP6 addresses are a pain

[icebraining]

if the DHCP server goes

You use the failover.

Heck, and what about latency for updating DNS servers with the new addresses when DHCP assigns them (remember, DNS servers cache answers, typically for days, and if you try to turn off the caching it takes too long to get answers to your DNS queries).

Uh, that's just public DNS. My dnsmasq instance updates in seconds, and all my clients use it directly, so there are no caches.

Re:IP6 addresses are a pain

[icebraining]

We're talking about using DNS vs manually typing IP addresses every time. Just letting stuff auto-configure is fine, but irrelevant to this particular discussion.

Re:IP6 addresses are a pain

[DarkOx]

I have this fight for a long time and some of what you say is true, but in my experience its always worked out better where my DNS rule is observed on a largish network. That is: if its not in DNS it does than it does officially not exist, that address is mine ( network admin ) to freely use as I please, and if your refer to a resource by IP directly its subject to change with minimal warning.

A proper DNS infrastructure does not just fail ( most organizations don't have that but its a different matter ). Other 'stuff' happens all the time. Companies get acquired that happen to use your same address space, services have to be moved to different sites for one reason or another, something at some subsidiary starts causing problems on the wan and you need to know what is right away etc. A solid DNS database makes it possible to find the information you need quickly both for humans and machines, and to effect changes easily without having to chase all across your 30 site nation wide WAN to fix every the address of the time server on every box. If you are not using DNS, even in ipv4 world, everywhere you possibly can I say you are doing it WRONG. That extra layer is there to help you and give you options.

Also even without DNS and DHCP most the time ipv6 is not going to require you to know any more bytes of an address than you do today. If you subnet properly the prefix should be predictable inside your organization. So you should still only need to communicate the last part of the address to all but the least clueful users

Re:IP6 addresses are a pain

[DarkOx]

What?

What crappy network hardware are you using? I have seen any commercial class hardware in the last 10 years that does not at least support an ACL on the management interface.

Split DNS - obviously you don't publish all DNS zones to everyone.

ACLs on DNS zones - Put all those management interfaces in a sub domain like management.LocalOffice.MyCompany.com. A decent DNS server supports ACLs for various request types for various zones. Maybe nothing can do an XFR for management.LocalOffice.MyCompany.com. and only clients and the local subnet and some head office subnet are allowed to do any other look ups fox example.

This is pretty basic stuff.

Re:IP6 addresses are a pain

[skids]

And then you have to check for error conditions after resolving the IP address. And deal with blocking timeouts and/or use a nonblocking API.

This is not to say that DNS is to be avoided, just that it is nowhere near as easy to do it right as most users (and unfortunately, even some programmers) seem to think.

Re:IP6 addresses are a pain

[Anonymous Coward]

reboots & ends up with a different dynamic IPv6 address

I like to tie my DNS and DHCP together

Re:IP6 addresses are a pain

[DarthBart]

That's this biggest bullshit excuse I've heard in my life, and I've heard it on multiple occasions both for forward and reverse DNS.

What does vr0-0.internal.notmydomain.com tell you about a device? Not a damn thing.
What does core1-loopback0.internal.notmydomain.com tell you? Jack and shit, other than it *might* be a loopback address.
How about switch1.notmydomain.com? Sure, its a switch. Maybe. It might be an ethernet switch. It might be a remote power unit. It might be an Asterisk based softswitch. Or it might be someone's IPv6 enabled light switch. Again, jack-point-shit. You'd still have to do a portscan of some sort against it to see what it is and if your admin is worth a shit, that won't get you anything either.

And DNS has no safeguards? Built in? Sure, no more or no less than any other protocol, but my DNS servers that serve the internal.domain.com zones are 1) Firewalled off from the outside world. 2) Also told to ignore anything not coming from an address inside my network. Now, if you're sniffing around from inside my network, I've got bigger problems, but problems that I can solve with a pair of wirecutters or a baseball bat.

Re:IP6 addresses are a pain

[CBravo]

And the funny thing is that MySQL and Java are in that list of not using the TTL.

Re:IP6 addresses are a pain

[FranTaylor]

I dread to think what would happen if we had to give them the line noise that is an IP6 address.

Gosh they might have to learn to use copy and paste.

Re:IP6 addresses are a pain

[unixisc]

In which case, IPv6 addresses should not be a problem, since you are only assigning static IP addresses once, and as far as the lower half of the address goes, you can assign anything that makes sense after designing a numbering convention for that part. Whether it's VMs, servers or whatever.

They'd be a pain if you had to constantly manually change it

Re:IP6 addresses are a pain

[unixisc]

Simpler to read ==> shorter ==> fewer addresses ==> run out of them sooner

Re:IP6 addresses are a pain

[Viol8]

C network programming isn't really your strong point is it?

Re:IP6 addresses are a pain

[cc1984_]

just so you know, the 2001:db8 is reserved as a fictitious subnet to use in documentation. You'd be better off using that instead of 2001:123:45

Re:IP6 addresses are a pain

[Anonymous Coward]

OK, you figure out how to resolve DNS in BH context, I'll be writing code

Re:IP6 addresses are a pain

[Aqualung812]

When you get a proper job instead of playing around at college you might understand.

Over 30 years with computers, and my college was me teaching myself IPX. Currently work in a multi-national with over 80,000 employees.

If you're having issues with manpower & deadlines, the last thing you want to do is a bunch of manual shit. Automation lets you get things done, or causes your job to be replaced by someone that knows what they are doing.

Oh, and I'm referring to the tons of programmers I've seen that like to hard-code IPv4 addresses. If they can't setup BIND on a test box for their test environment, they shouldn't be writing code.

Re:IP6 addresses are a pain

[Aqualung812]

All 4 of your reasons are answered by "host your own DNS server & learn how to setup DNS properly"

Re:IP6 addresses are a pain

[fa2k]

int ip = resolve(hostname); //int ip = 192.168.0.1;
connect(ip);

That's really going to fuck with your deadlines?

Ironically, it's things like storing IP addresses in ints that make it hard to move to v6. (routers have to do it, but not client software)

Re:IP6 addresses are a pain

[fa2k]

It would be nice if there was shortcut to refer to the local network. E.g. you could do things like
LOCAL/64::2
LOCAL/48:fafa::3
in configuration files and scripts

Re:IP6 addresses are a pain

[Viol8]

"If they can't setup BIND on a test box for their test environment, they shouldn't be writing code."

Don't be an ass all your life. Coders have enough to do without spending an hour reading a manual for some server app they don't need to use. Sounds to me like you've got an issue with coders - you're probably one of those network admins who wasn't good enough to do programming so you've had a chip on your shoulder about it ever since and make a big deal out of the small tasks you manage.

"Over 30 years with computers, and my college was me teaching myself IPX."

IPX? Is that it in 30 years? So what have you done with the other 29 years and 364 days?

Re:IP6 addresses are a pain

[j h woodyatt]

fc00:/7 are *not* private addresses. They are globally scoped, but non-globally routable.

Re:IP6 addresses are a pain

[Denis Lemire]

Multicast DNS doesn't just move the problem 'somewhere else' it moves it from one or more centralized places that can fail to a distributed model. Every host responds to requests for its own name - no infrastructure required. Bliss.

I agree, layers of complexity suck, that's why I don't want NAT behind NAT connecting to someone else's layers of NAT. End to end connectivity is a huge win, if that means slightly larger address space - that's well worth it. I also look forward to "What's your IP address?" having a meaningful answer, again, less complexity.

The above aside, your argument about raw addresses is barely even valid... I've memorized my important addresses. My old colocation address was 2610:78:ad::1 - easier to remember than an IPv4 addresses. My current prefix 2610:1e8:800:100::/56 isn't all that much harder. If you rely on autoconf addresses you can even determine the IP is based on the MAC and prefix - all without a DHCP service.

The future rocks, let go of your decrepit IPv4 stack and learn something new.

Re:IP6 addresses are a pain

[bogd]

The right-most octet in the abbreviated address substitutes for the right-most octets of the full address.

Do you have a reference for that? I did notice the behavior in operating systems ("ping 127.1" translates to "ping 127.0.0.1" in both Windows and Linux), but I was never able to find an RFC that talks about it.

Re:IP6 addresses are a pain

[Dagger2]

Looks like it's not a formal standard. I found this mailing list post which links to this IETF draft text which mentions them on page 5.

Re:IP6 addresses are a pain

[tlhIngan]

I agree, layers of complexity suck, that's why I don't want NAT behind NAT connecting to someone else's layers of NAT. End to end connectivity is a huge win, if that means slightly larger address space - that's well worth it. I also look forward to "What's your IP address?" having a meaningful answer, again, less complexity.

Give it up. End-to-end connectivity is gone and will not return.

Pretending that IPv6 will give you end to end connectivity is like believing NAT is a firewall. True, but with significant limitations. In fact, getting someone's IP address probably won't mean diddly and you'll spend days figuring out the issue.

The reason? Firewalls. And I suspect the next-generation of IPv6 firewalls will be outgoing connections only (a la NAT) to prevent reverse traversals. leading to exactly the same problems we have with IPv4 without the ease of knowing that someone is behind said firewall.

And when your ISP decides to give yo ua new prefix, out comes the pile of hurt when devices don't pick up on the new prefix. Explain that to your parents why the printer stopped working all of a sudden, or why their TV can't watch netflix.

NAT is handy in this instance at isolating the inner network from the outer so things inside still work. IPv6 can do this using link local and private addresses, but the internet address is completely different. Hell, I espect hilarity when some person using Dropbox over IPv6 didn't get hte latest copy of a document only because their PC mysteriously didn't sync when the prefix changed.

Sometimes, all-or-nothing is a lot better than partial connectivity that IPv6 allows.

Re:IP6 addresses are a pain

[Denis Lemire]

I have end-to-end connectivity between home, work, family members networks, everywhere I have v6. My networks, my firewalls, my rules!

Yes, stateful firewalls that block everything inbound that wasn't setup from the inside are a completely sane default. Unlike NAT we get to choose what traffic we DO allow - even if we have more than one host that needs the same port. Why is this bad?

If the new devices don't pick up a new prefix - they're broken devices. Would you keep a device that kept its IPv4 address for longer than its DHCP lease term?

Renumbering into a new prefix is way easier than re-numbering into a new IPv4 subnet. All my suffixes stay the same, learn the new prefix and you're done.

NAT is a kludge. It needs to die.

Re:IP6 addresses are a pain

[unixisc]

End to end does not mean what you think it means - no firewalls. It means that the destination address is the address of the final end point, and not some intermediate transition point, such as a NAT gateway. It means that there are no changes made to the destination address b/w the packets leaving their source to arriving @ their destination.

Also, why would ISPs need to issue new prefixes for no reason? Just issue a prefix of /64, /60, /56 or /48, as needed, and then forget about it. Other options consumers have would be to get provider independent addresses from the RIRs

Re:That's easy.

[houghi]

Governements do. ISPs don't.

Without it, they can sell IPs for nice amounts without paying for it themselves. For ISPs it would even be nice to just give everybody a 10.x.x.x address (as they do with phones) so you can not run any server, or with very much work.

It is much better and easier to control on many levels of control.

So why would they go to IPv6, which will cost money, while sticking with IPv4 will bring in money.

Vendor support sucks

[Anonymous Coward]

I'm involved with a lot of IT procurements (for an .edu, so we're ahead of most when it comes to pushing IPv6). Vendors still look at us like we have lobsters crawling out of our ears. I often got the response - "well, its a new protocol." My response IPv6 was first standardized in 1998 (https://tools.ietf.org/html/rfc2460), so if you are that far behind the standards, we probably don't want your product.

Re:Vendor support sucks

[Anonymous Coward]

I'm involved with a lot of IT procurements (for an .edu, so we're ahead of most when it comes to pushing IPv6). Vendors still look at us like we have lobsters crawling out of our ears. I often got the response - "well, its a new protocol." My response IPv6 was first standardized in 1998 (https://tools.ietf.org/html/rfc2460), so if you are that far behind the standards, we probably don't want your product.

Well, I work for one of those vendors (hence posting AC). In my company, a fortune 500 telco vendor, IPv6 only started to gain traction in 2011. Not because engineering didn't want to implement, but because management saw no business case. If customer's don't ask, it will not be implemented by a company where mgmt rules the product, that's the short story.

As long IPv6 wastes more data per hearder,

[Anonymous Coward]

we have zero reasons to use it.

Re:As long IPv6 wastes more data per hearder,

[YodasEvilTwin]

A con does not make the number of pros zero. Learn to count.

Re:As long IPv6 wastes more data per hearder,

[Ultra64]

http://www.startnetworks.info/2011/08/ipv6-and-ipv4-headers.html

"Due to all these reasons, IPv6 headers are more efficient and less CPU intense to Routers than IPv4 headers. "

Re:As long IPv6 wastes more data per hearder,

[WaffleMonster]

we have zero reasons to use it.

This is a legitimate gripe for some VoIP and assorted realtime applications with very small per-packet payloads. When I looked into this I found about a 20% increase in channel capacity would be required per VoIP stream just by switching from IPv4 to IPv6.

This however is worse case. For most the packet overhead is a pointless rounding error for data transfers and most web traffic, streaming video..etc even being if being generous and assuming minimum 1280 MTU.

In all cases this overhead is absorbed quickly by ever increasing channel capacity over time.

The alternative to not using IPv6 will eventually be CGN with latency and overall suck that will make your per-packet overhead argument look ridiculous.

The argument for upgrading was never about what you gain..it is about what you get to keep in the long term.

Re:As long IPv6 wastes more data per hearder,

[someones]

not to forget, that they removed NAT, without thinking about loadbalancing, multihoming and topology hiding at all.

thats what i like about protocols by comitee: its like politicans thinking about their own pockets first.

Re:As long IPv6 wastes more data per hearder,

[RCL]

Exactly. Now every your device will be scanned for open ports and possibly exploited.

Re:As long IPv6 wastes more data per hearder,

[Ultra64]

" Now every your device will be scanned for open ports and possibly exploited."

Yeah, it's too bad firewalls don't exist.

Re:As long IPv6 wastes more data per hearder,

[Ultra64]

"without thinking about loadbalancing, multihoming and topology hiding at all."

actually, they did think about it. Just because you are ignorant of a feature doesn't mean it doesn't exist.

End to end

[tepples]

How should a machine on the public Internet connect to one of the millions of machines behind a single IP?

Re:End to end

[isorox]

How should a machine on the public Internet connect to one of the millions of machines behind a single IP?

You and I like this facility. For everyone else "the cloud" works fine

Re:End to end

[Anonymous Coward]

That's what a proxy is for.

Anyone sane who has tons of machines behind a single public IP is running a dedicated proxy server anyway.

Re:End to end

[Kjella]

Don't call us, we'll call you. I actually had an Internet connection like that years back, entire campus hidden behind a single IP and no incoming ports. It was rather crippled but as long as the other half of the connection had a normal connection I could always connect to their servers and up/download. On modern IM services it'll even negotiate so that other people can send you files because under the hood you connect out instead. Worst case if you're both stuck behind such solutions you can always pass files via some third party file host. It's not pretty but it's not useless either, I bet enough people just browse and check their mail to not even notice.

Re:End to end

[Forty Two Tenfold]

VPN.

Re:End to end

[unixisc]

Which is normally a bitch under IPv4, since the same Class C or Class A private addresses are used in the separate networks, and so connecting the 2 and resolving the differences b/w overlapping addresses would give one a migrane. With IPv6, one could either use dedicated routable addresses, or if one needs a VPN, one could use a site-unique address.

Re:End to end

[Anonymous Coward]

Port forwarding?

Is this a trick question?

Re:End to end

[tepples]

So how should a customer apply to have the ISP forward a particular port to him?

Re:End to end

[tepples]

Worst case if you're both stuck behind such solutions you can always pass files via some third party file host.

If you are the operator of such a "third party file host", where are you going to get the IP addresses from?

Re:End to end

[Anonymous Coward]

Dumbass

Re:End to end

[Kjella]

If you are the operator of such a "third party file host", where are you going to get the IP addresses from?

As an operator you need to have a public IPv4 address but there's billions of them, it's not a that scarce resource. People just need to be able to share your files via a server, whether it's rapidshare or gmail or facebook albums or youtube or whatever doesn't matter. Hell even P2P networks will work as long as there's enough "active" hosts to talk to the passive ones. When we run out you'll probably have to pay a little to have a full IPv4 address to yourself, just like many now charge a little extra for a fixed IP and that'll be enough to free up IP space.

Using it at work, really useful

[jnelson4765]

I just rebuilt our monitoring system on Munin 2.0, which can deal with IPv6. Made life a lot easier, since punching holes in NAT routers and screwball port mappings went away.

Google and Facebook are both running ipv6, and both our office and a chunk of our datacenter are on ipv6 through a he.net tunnel. Wish native ipv6 was available, but Amazon hasn't enabled it for AWS, and the Comcast ipv6 rollout is to consumers, not to business clients.

Re:That's easy.

[Ultra64]

>Many (if not most) end system addresses have the MAC address embedded in the v6 host address,

http://en.wikipedia.org/wiki/IPv6#Privacy

Privacy extensions are enabled by default in Windows, Mac OS X (since 10.7), and iOS (since version 4.3).[39] Some Linux distributions have enabled privacy extensions as well.[40]

What about the big ones (e.g. verizon, AT&T)

[sohmc]

My FiOS ISP does not have an IPv6 address. I support it internally on my router. I imagine that the hold up is that the big guys aren't there yet. This makes sense since they have the most equipment to replace/reprogram.

I'd actually be interested in where these guys are at. I'm sure they figured it out for businesses but I'd like an IPv6 address for my house.

Still not working...

[bartjan]

bartjan@ix:~$ ping6 slashdot.org
unknown host
bartjan@ix:~$

Maybe about time to update this story from 2003??

Re:Still not working...

[gQuigs]

arstechnica.com doesn't have Native IPv6 either.

So... what is preventing slashdot and arstechnica.com from going IPv6?

Re:Still not working...

[Anonymous Coward]

No-one at Slashdot knows very much about this technology stuff. It's more about maintaining a nerd image by wearing weird glasses.

Re:Still not working...

[jones_supa]

At least Slashdot is very conservative what comes to technological improvements.

Re:Still not working...

[alanw]

I run the Firefox plugin SixOrNot. Google - a green 6. Youtube and Facebook ditto. Slashdot, a red 4. There are major sites out there running IPv6.

I have a free tunnel from Hurricane Electric. The only issue is that Google thinks I'm in the USA, which can't be a bad thing.

Now that there are no more IPv4 addresses available in Europe, it's in the interests of the established players to suppress IPv6 and lock out disruptive new startups: e.g. ISP's or Co-Lo's.

Re:Still not working...

[Anonymous Coward]

This is indeed ridiculous. No IPv6 (took me half a day to get my servers running on) and no Unicode (two days to write and test a good UTF-8 parser). And slashdot is unable to pull it off. How sad.

Re:Still not working...

[Anonymous Coward]

Only when it comes to useful technologies. They're more than willing to jam all the AJAXy, FLASHy, nonsense into their site yet still fail at supporting Unicode and IPv6.

Re:Still not working...

[someones]

get it allready, that noone cares about ipv6 ;)

its a solution to a not existent problem.

Re:Still not working...

[RCL]

It's an old, overdue solution to a problem that is largely irrelevant these days.

Better yet..

[micber]

maybe we should just say "the Internet is full!" and call it a day...there's already too much crap floating around anyway!

Re:Better yet..

[marcosdumay]

That's easy to solve. Just disconnect your computer and it won't affect you anymore.

older modems / routers are a isses as well and who

[Joe_Dragon]

older modems / routers are a issue as well and who knows what bugs are in them that will only show up with higher IPV6 use.

How meany people are useing say the modems from there ISP that may be a few years old that does not have IPV6.

Re:That's easy.

[MajroMax]

That won't work in the long-term. The problem with carrier-grade NAT is that the ISPs have to... maintain carrier-grade NAT.

Network Address Translation is a stateful protocol, and it's orders of magnitude more expensive to maintain connection tracking on a per-connection basis for your customers than it is to simply route packets between networks. Even ISPs that use Deep Packet Inspection have the luxury of looking at selected traffic flows; carrier-grade NAT has to cover everything or it doesn't work.

Re:That's easy.

[Anonymous Coward]

Good to know. Thanks. I had v6 working in Windows, then an update broke it, and the Linux distros I have played with don't have it by default.

Re:That's easy.

[Anonymous Coward]

On the contrary, IPv6 would make it MUCH easier, since every device has it's own unique identifier IP address. IPv4 address on the other hand have NAT'd addresses and those on the outside never can be sure which device is using X address at any time, all they have is the outbound gateway address.

Re:What about the big ones (e.g. verizon, AT&T

[Anonymous Coward]

Last I heard on FiOS was sometime Q1/Q2 of 2013 for IPv6 support. They have already started upgrading the firmware on their newer routers to support it but they are not assigning addresses as of yet.

IPv6?

[Anonymous Coward]

Ain't nobody got time for that!

Re:That's easy.

[Anonymous Coward]

So why would they go to IPv6, which will cost money, while sticking with IPv4 will bring in money.

Yes, and I'm certain a similar business model sat on the desk of RIM Executives...and we see just how far their "if it ain't broke, don't fix it" mentality has taken them.

If ISP's want to take this mentality, fine. Just don't expect to be in business past the next decade.

Re:That's easy.

[MajroMax]

ISPs don't want to do carrier-grade NAT, because then they have to maintain carrier-grade NAT.

CGN is a stateful protocol, meaning that each of their implementing-boxes needs to maintain and process state for each data flow to or from your devices. That's no big deal for a single home, but it's a problem for a carrier. If the boxes are too far towards the customer-end of their network, they will be small but they will also be numerous, making maintenance more frequent. If the boxes are too far towards the core of their network, an ISP will only need a few, but the hardware requirements are much heftier to provide acceptable performance. (Already, bittorrent can saturate some of the cheaper home routers).

Simply routing packets is technically far, far easier than running network address translation. Even ISPs that use deep-packet inspection have the option of turning it off if things go wrong -- the network fails open. Carrier grade NAT doesn't have that option.

Re:older modems / routers are a isses as well and

[Anonymous Coward]

older modems / routers are a issue as well and who knows what bugs are in them that will only show up with higher IPV6 use.

How meany people are useing say the modems from there ISP that may be a few years old that does not have IPV6.

Considering that IPv6 adoption from a software standpoint has literally been around for years now, I would consider this actually less of an issue, not more.

In other words, if you are still running hardware such as modems and routers that have issues with IPv6 adoption that cannot be overcome, then it's time to replace your shit, because it's as old as the IPv4 mentality keeping it there.

Maybe because Cisco still teaches IPv4?

[Anonymous Coward]

I'm taking classes to obtain my CCNA. The class still revolves around IPv4. If the admins don't know IPv6, they'll stick to what they know until they have no choice to buy a book on ipv6, learn the differences, and upgrade. In addition, most business won't want to upgrade until they have to as it is an additional expense.

IPv6 is coming. But it's not something that will be everywhere tomorrow. It will take time... As old equipment fails and is replaced with IPv6 capable hardware, slowly the internet will change over.

It will get to a point where whoever is left on IPv4 will switch over within a short time period - within a few years - but that's only after most of the equipment has already been replaced, and the networking staff have been required to read a book or take classes on the technical differences between the two so they can configure the hardware properly.

Updating Cisco CCNA to revolve mainly on IPv6 wouldn't be such a bad idea either.

Re:Maybe because Cisco still teaches IPv4?

[Anonymous Coward]

I'm taking classes to obtain my CCNA. The class still revolves around IPv4. If the admins don't know IPv6, they'll stick to what they know until they have no choice to buy a book on ipv6, learn the differences, and upgrade.

For godsakes a fucking Cisco CMTS is the reason I don't have native IPv6 right now. The dogfood thing was cute but seriously guys get your shit together.

Re:Maybe because Cisco still teaches IPv4?

[unixisc]

I decided to punt on CCNA certification until they revolve around IPv6

Re:Maybe because Cisco still teaches IPv4?

[jbolden]

It won't be that slowly. Companies that have tried have found it is a 5-7 year transition to fix everything. The internet grows exponentially. It will come come much faster than most companies expect. And with much more intensive focus.

Re:Maybe because Cisco still teaches IPv4?

[dotgain]

They have to teach IPv4, it's still under heavy use. Cisco CCIE used to test on Token Ring and FDDI for a few hundred years after they'd been long dead too.

Incentive tax

[Anonymous Coward]

And just like with houses, people prefer waiting rather than buying when prices are dropping

Easy solution then... announce an incentive tax on IPv6 that'll be brought in in 2 years time but waived if you can demonstrate working existing IPv6 functionality before the tax comes into effect. Everyone'll rush to get IPv6 before then so to minimise they adoption costs after. Write into the tax code that it's abolished after 10 years (ie long enough so companies/people aren't willing to wait that long), by which time adoption rates'll be high enough that it'll no longer be required.

But yes it's very naive... would be unfair on new companies afterwards and waiving it for them would just encourage companies to create new legal entities afterwards to evade it, and would be hard to get a good definition of functionality for all cases that doesn't just mean a single printer in the corner of a room.

Re:Incentive tax

[someones]

this can only work nationwide, not worldwide.

But go for it, if you feel like killing off your nation's internet

The Mayans predicted this....

[Anonymous Coward]

The Mayan's predicted that IPv4 addresses will be exhausted on Dec 21 2013!!!

Re:The Mayans predicted this....

[Anonymous Coward]

Back in 1992, everyone predicted that !Pv4 addresses would be exhausted by 1994.

IPv6 isn't the solution

[Alomex]

The solution to this problem, which was presented decades ago, is to switch to IPv6.

If IPv6 were the solution we would have already switched to it. IPv6 was stillborn, pretty much starting from the moment it wasn't backward compatible with IPv4. It would have been trivial to keep the current IPv4 address space and dedicate some of the multicast or reserved address space (class D and E) and a dedicated port (say the unassigned port 6) to IPv6.

A message destined to an IPv6 128 bit destination could be sent to the 32 bit prefix port 6 or up stream encapsulated to a 236.*.*.*-246.*.*.* destination.

Each node along the way is then allowed to open the encapsulated IPv4 packet to extract the IPv6 headers, if IPv6 capable, or treat it like an IPv4 packet and pass it along to its IPv4 destination which is always an IPv6 capable node.

This node then must open the encapsulated package and further process it as needed.

Re:IPv6 isn't the solution

[Dagger2]

You've pretty much just described 6to4. We have it already.

Re:IPv6 isn't the solution

[Alomex]

6to4 is an extension which is optional as opposed to an intrinsic part of the protocol. This distinction is important.

Moreover the fact that 6to4 was developed at all, after IPv6 was proposed, proves my point and shows that my criticisms of IPv6 were/are shared by many.

Re:IPv6 isn't the solution

[Anonymous Coward]

Just admit you're wrong.

Re:IPv6 isn't the solution

[Anonymous Coward]

Even if the full range of IPv4 addresses would be usable, we are still at 2^32 =~ 4,200,000,000 IPs compared to a current world pop of 7,000,000,000.

Not counting Servers
Not counting mobile devices
Not counting entertainment or educational areas

IPv6 has 2^64 Prefixes; as a bonus you get 2^64 IPs per prefix as well; but that's not what IPv6 is about. This is just needed to get stuff like SLAAC working.
So now we can have 18,446,744,073,709,551,616 "locations" with 18,446,744,073,709,551,616 IPs.*each*.

The only reason it wasn't immediately adopted is the same as with firewalls or IPS systems: It will cost money and it will not immediately create revenue. Or that's what the companies think.
Why, I ask, why does google and facebook already /have/ IPv6 then?
Think about that. For maybe 10 seconds. If you don't get a solution at that time, consider to shoot yourself. (Darwin, helping hand, you know....)

Re:IPv6 isn't the solution

[Alomex]

Again, 6to4 is a patch, not a properly designed transition interface. E.g. from wikipedia:

6to4 does not facilitate interoperation between IPv4-only hosts and IPv6-only hosts. 6to4 is simply a transparent mechanism used as a transport layer between IPv6 nodes.

Due to the high levels of misconfigured hosts and poor performance observed, an advisory about how 6to4 should be deployed was published in August 2011.

Moreover, 6to4 encapsulates IPv4 addresses in IPv6 2002: addresses, which is the reverse of what I'm suggesting.

I've been telling everyone since before the protocol was formalized that it would take a long time to be adopted the way it was designed. Then, just like now people gave silly arguments why I was wrong. Well here we are 16 or so years after I first raised these objections and IPv6 is still less than 1% of the net.

Re:IPv6 isn't the solution

[Dagger2]

6to4 does not facilitate interoperation between IPv4-only hosts and IPv6-only hosts.

Neither does your idea. It requires that v4-only hosts be taught how to speak it, the same as 6to4 does.

Moreover, 6to4 encapsulates IPv4 addresses in IPv6 2002: addresses, which is the reverse of what I'm suggesting.

Surely you are not suggesting that we encapsulate v6 addresses inside v4 addresses. That's not going to work.

Re:IPv6 isn't the solution

[Alomex]

It requires that v4-only hosts be taught how to speak it, the same as 6to4 does.

No it does not. If they don't speak IPv6 they simply route the packet as if it was IPv4. Only the host destination needs to speak IPv6 and since it is addressed to a port, it does not require the IP stack to speak IPv6, only the server listening to that port.

Surely you are not suggesting that we encapsulate v6 addresses inside v4 addresses. That's not going to work.

Of course it will work You coalesce many IPv6 addresses into a single IPv4/IPv6 node. The packet traverses then to the 4to6 gateway over IPv4 where it is opened and the rest of the IPv6 address is recovered from within the encapsulation. The gatway uses that part to route the packet for the next leg of the trip. This is the exact same trick used by virtual switching in ATM networks as well as MPLS.

Re:IPv6 isn't the solution

[WaffleMonster]

Of course it will work You coalesce many IPv6 addresses into a single IPv4/IPv6 node. The packet traverses then to the 4to6 gateway over IPv4 where it is opened and the rest of the IPv6 address is recovered from within the encapsulation.

None of these schemes are worth a hill of beans when there are no more IPv4 addresses available to serve as bearers for such an overlay network. Exhaustion has consequences.

About as productive as going off to check your email to see why the Internet is down.

Re:IPv6 isn't the solution

[WaffleMonster]

Moreover the fact that 6to4 was developed at all, after IPv6 was proposed, proves my point and shows that my criticisms of IPv6 were/are shared by many.

The fact that 6to4 was developed at all is a mistake which is being rectified.

Re:IPv6 isn't the solution

[Alomex]

None of these schemes are worth a hill of beans when there are no more IPv4 addresses available to serve as bearers for such an overlay network.

Just because you cannot engineer past the details it doesn't mean it can't be done. Since we have IPv6 on top of IPv4 we can take back most of the IPv4 addresses from every organization. Essentially only border routers need to have IPv4 addresses. Think about it, institutions which currently have thousands or even tens of thousands of IP addresses would go down to a few hundred IPv4 addresses.

Once the packet reaches the IPv4 border 4to6 router the packet traverses the rest of the journey using either intra network IPv6 addresses or private IPv4 addresses,, not unlike NATs. The difference is that you can publicize your NAT+internal_IP address as an IPv6 address to the entire world, whereas it is a bit more of a kludge to make a NAT'ed computer visible to the entire network.

Really, think about it for a moment. What I'm suggesting is a combination of existing technologies. 6to4 tunneling, MPLS switching, NAT, ATM label switching, shimming, IPv4, IPv6. All the pieces are already there, they just need to be combined in a better way.

Re:IPv6 isn't the solution

[Alomex]

If 6to4 and other tunneling technologies hadn't been developed the percentage of IPv6 traffic would round down to 0.0%. I can guarantee you that. There are very few complete end-to-end IPv6 paths currently on the public Internet. The packet is tunneled at least part of the way, often by the last mile ISP, but until recently even by some of the backbones themselves.

Heck not even slashdot or www.MIT.edu speak IPv6.

Again, think about it. This should tell you an awful lot about where things stand today.

Re:IPv6 isn't the solution

[Anonymous Coward]

> It would have been trivial to keep the current IPv4 address space and dedicate some of the multicast or reserved address space (class D and E) and a dedicated port (say the unassigned port 6) to IPv6.

That would actually not be trivial because of so much networking gear breaking on the assumption that class D is multicast (gets treated specially) and class E is reserved (unavailable for use.)

Re:IPv6 isn't the solution

[WaffleMonster]

Just because you cannot engineer past the details it doesn't mean it can't be done

Just because you can do something does not matter if it is a nonstarter operationally.

Since we have IPv6 on top of IPv4 we can take back most of the IPv4 addresses from every organization

Keep dreaming...

Essentially only border routers need to have IPv4 addresses

I'm really confused. The world is running out of IPv4 addresses and not everyone has IPv6 connectivity.

The act of removing IPv4 addresses means those on the IPv4 only network loose access to IPv4 only resources.

Additionally act of renumbering your network is essentially the same cost that would be incurred by moving to native IPv6.

Breaking the IPv4 internet while concurrently requiring everyone to renumber seems counterproductive. I'm sorry if I don't understand but I don't.

The difference is that you can publicize your NAT+internal_IP address as an IPv6 address to the entire world,

I think you mean to say the entire world that has an IPv6 address.

The problem all of these schems gloss over or otherwise pretend don't exist is that IPv4 nodes on the IPv4 only network are disconnected from IPv6 nodes on the IPv6 network! They have no way of addressing IPv6 cause their aint enough bits. At least with IPv4/IPv6 dualstack there is explicit knowledge of who can get to what via what network.

Really, think about it for a moment. What I'm suggesting is a combination of existing technologies. 6to4 tunneling, MPLS switching, NAT, ATM label switching, shimming, IPv4, IPv6. All the pieces are already there, they just need to be combined in a better way.

I think I like BGP and native IPv6 better. If I'm going to have to renumber anyway native sounds a heck of a lot better to me than tunnels/encapsulation and assorted MTU robbing machinery. As an added bonus the IPv4 Internet for IPv4 only participants is not destroyed in the process.

Re:IPv6 isn't the solution

[Alomex]

The problem all of these schems gloss over or otherwise pretend don't exist is that IPv4 nodes on the IPv4 only network are disconnected from IPv6 nodes on the IPv6 network!

Correct, which is one again a simple engineering challenge. You can use port 6 or (6666 in user space if you are not admin) to deploy an IPv6 server in your own computer. Then you can now talk IPv6 from any computer, have the local server translate into IPv4 if need be, or simply pass along as an IPv6 packet if it finds the computer to be IPv6 enabled. The translation into IPv4 uses encapsulation like in 6to4 tunneling and the packet is decoded at the other end also by an IPv6 capable server. From there is routed for the last mile to the actual destination, in a NAT-like manner.

This means that we could have all the applications talk IPv6 in no time and then let the underlying infrastructure migrate to IPv6 in due time. Currently this is clearly not happening at a fast enough rate.

Re:IPv6 isn't the solution

[Miamicanes]

Shhhh. You're forgetting that the people who really dig IPv6 get TOTALLY bent out of shape about home routers in any form.

IMHO, the nearly-religious hatred its advocates have towards NAT and routers is one of the biggest things holding IPv6 back. If they'd just humor people who want to set up an internal network with private IPv6 addresses and NAT it through their router somehow instead of trying to beat them into submission and force them to abandon their shameful backwards ways, we'd be a lot closer to having IPv6 in widespread deployment today.

The problem is, they're absolutely HELLBENT on abolishing the handy devices we mostly abuse as ghetto-fabulous firewalls. From the way they talk about routers, you'd think they cost thousands of dollars and make the internet unusable, instead of being something that most people either get for free or pay less than $50 for... maybe $150-250 if they're high-end users who want one that's hackable and can be flashed with custom firmware.

The same trick routers do to allow a dozen devices to share one public IPv4 address could transparently map public IPv6 addresses to devices who identify themselves by internal 192.168.x.x or 10.x.x.x addresses. Better, in fact, because every IPv6 address mapped to an internal IPv4 address by the user's router could enjoy the equivalent of "DMZ" mode port forwarding. Give the same user a public IPv4 address (or at least a fixed range of ports from one, a-la RFC 6346), and every IPv4-only device sitting behind his router can be made fully-accessible to the outside world via both IPv4 and IPv6.

For IPv6-native devices, it's even better. They can have their public IPv6 address, but let the router assign them a phantom 192.168.x.x address, and DMZ-forward all of its ports to their IPv6 address. Create an additional router forwarding rule forwarding port xxxx of the public IPv4 address to port yyyy of the phantom 192.168.x.x address that can be chained with the rule forwarding all of 192.168.x.x's traffic to the device's IPv6 address, and you have an IPv6 device that can be easily reached by IPv4 devices on the other side of the router, too, just like NAT'ed IPv4 devices can be. The bonus is that if IPv6 is talking to IPv6, they can drop the act and communicate directly.

The people who hate routers forget that they're a wonderful way to allow end users to embrace IPv6 at THEIR OWN pace, in ways under THEIR DIRECT control, instead of dictated by their ISP or someone else's timetable -- usually, in ways that will break expensive legacy hardware that will never work natively under IPv6.

Routers aren't going away. If anything, 10-20 years from now, we'll have legacy devices connected to the rest of the LAN through a $10 POE-powered adapter from China that sits inline between the device and the rest of the network, and acts like a single-port DMZ-forwarding NAT router dedicated to just one device. A box that lets your IPv4-only device be a:b:c:d:e:f:g:h to the rest of the world, while thinking of itself as 192.168.1.1 and never knowing the difference.

Re:IPv6 isn't the solution

[Dagger2]

If they don't speak IPv6 they simply route the packet as if it was IPv4

This is true for intermediate routers, as it is with 6to4.

Only the host destination needs to speak IPv6

The source needs to understand it too, and if you're updating the source to understand this interop method then your source is no longer v4-only.

and since it is addressed to a port, it does not require the IP stack to speak IPv6, only the server listening to that port

This doesn't even make any sense. If you could send the traffic to the server in the first place, why bother with all this tunnelling of extra bits? Just send your traffic to the server and be done with it!

The packet traverses then to the 4to6 gateway over IPv4 where it is opened and the rest of the IPv6 address is recovered from within the encapsulation

OK, so that's 6to4.

The gatway uses that part to route the packet for the next leg of the trip.

6to4.

This is the exact same trick used by virtual switching in ATM networks as well as MPLS.

And also -- you guessed it -- 6to4.

Re:IPv6 isn't the solution

[WaffleMonster]

If 6to4 and other tunneling technologies hadn't been developed the percentage of IPv6 traffic would round down to 0.0%. I can guarantee you that.

6to4 never contributed to IPv6 traffic cause default host policy says prefer IPv4 over IPv6. It only ever contributed to headaches.

The packet is tunneled at least part of the way, often by the last mile ISP, but until recently even by some of the backbones themselves.

A few ISPs are deploying 6rd at least temporarily to get past CPE/last mile issues. ISP core all native has been for awhile.

Comcast 100% native already deployed to about half of its customer base of ~20m subs? My understanding other half likely within the year and all other major US ISPs following suite.

Heck not even slashdot or www.MIT.edu speak IPv6.

Sad... going to take forever to get everyone upgraded. At least www.irs.gov has my back :(

Again, think about it. This should tell you an awful lot about where things stand today

Yea it sucks. IPv6 deployment has been dormant for a decade and a half only in the last few years have things finally started picking up. Keep in mind long tail .. handful of sites responsible for >50% of all network traffic. All already have IPv6 native deployed. Will take forever to get smaller content and subscribers with those exceptionally well made CPE PSUs to upgrade. Need flag day!

Re:IPv6 isn't the solution

[Alomex]

You are too worked up to understand any of what I'm saying. Sleep over it and come back tomorrow. Meanwhile chew on this: the scheme requires an IPv6 server at both ends if the ends are only IPv4 enabled. When you figure out why you'll understand why you don't even need an IPv6 stack locally for an application to use IPv6 (though ideally you would have one) and why we bother with the tunneling.

Re:IPv6 isn't the solution

[jbolden]

It would have been trivial to keep the current IPv4 address space

In the sense you mean, no it wouldn't. v6 and v4 routers don't work the same way.

In the sense of all software other than routers that's exactly what you do. You copying the v4 space to the local subnet to create the v4 internet inside your subnet and then address v4 traffic through a gateway. That's standard dual stack.

Re:IPv6 isn't the solution

[jbolden]

Thank you. I repeated your point.

Re:IPv6 isn't the solution

[jbolden]

There are 2^128 v6 addresses. There are 2^32 v4 addresses. The gateway can only possibly be one way.

Re:IPv6 isn't the solution

[jbolden]

So implement 200 technologies to get a system that works worse than v6 rather than implement v6?

Once you get rid of the v4 addresses what is the point?

Re:IPv6 isn't the solution

[jbolden]

Expensive legacy hardware sits on a v4 subnet which you map to part of your v6 subnet.

And v6 people don't hate routers, one of the main advantages of v6 is making routers much much faster.

Re:IPv6 isn't the solution

[Alomex]

Right, just like we cannot use a few bits to label IPv4 traffic over ATM... oh wait!

As I said, we map many IPv6 addresses into a single IPv4 and use encapsulation to encode the remaining part. Not unlike NATs which use the local address translation table to tease apart many things being mapped to a single IP address, but in this case we use the extra bits encapsulated in the packet.

Once the packet reaches a fully IPv6 capable node it gets send on IPv6 or we use private address space for the journey to complete over IPv4, again, not unlike NATs.

Re:IPv6 isn't the solution

[WaffleMonster]

Right, just like we cannot use a few bits to label IPv4 traffic over ATM... oh wait!

In these cases each layer has necessary procedures already baked in to understand what is to be done next with the data at each layer.

An IPv4 only host without some form of access to your special translation machinary is cutoff from the IPv6 universe until that changes.

This is no different than the current situation. An IPv4 only host is cutoff from IPv6 until their ISP upgrades after which it just works or any number of tunneling solutions are installed by the user or upstream ISP including the obnoxious anycast based solutions and any dynamic NAT mapping of 1918 or E space to IPv6.

The operational advantages of native dualstack deployment over the tunneling hacks boil down to minimizing risk of breakage and delivering production quality network at every step. This is critical.

First and foremost content is unwilling to deploy to anything that causes breakage, higher latency or lower throughput and availability.

It is better for everyone to just wait until their ISPs deliver native IPv6 than to encourage customers or ISPs to get IPv6 early with shortcuts only to have it not be as capable as IPv4. This will only make the customer unhappy and therefore content and ISP will also be unhappy.

It is hard to see any of the current tunnel based solutions scaling to any significant fraction of current native IPv4 utilization unless deployed as nothing more than a last mile bandaid.

In short are a lot of things that are possible. Out of those only subset of what is operationally viable actually matter.

Re:IPv6 isn't the solution

[Alomex]

An IPv4 only host is cutoff from IPv6 until their ISP upgrades after which it just works or any number of tunneling solutions are installed by the user or upstream ISP including the obnoxious anycast based solutions and any dynamic NAT mapping of 1918 or E space to IPv6.

Only because the protocol wasn't made backward compatible. One easy way to make IPv4 only nodes compatible with IPv6 applications would have been to preserve the old IPv4 prefixes. Say if an IPv6 application wants to talk to an IPv6 address X1:X2:X3:X4 where each of the Xi's is a 32 bit chunk you can pass the packet through IPv4 to destination X1 port 6. That is inside the other application domain, which has to be IPv6 aware (otherwise why are you trying to talk to it using an IPv6 app?). Then this node grabs the packet and from then on is treated as an IPv6 address within that network. Even better, if the final destination is IPv4-only aware, then the IPv6 node becomes a NAT like device which de-encapsulates the packet and passes it on to IPv4 (private) address X2.

Re:IPv6 isn't the solution

[jbolden]

Subnets would be X1:X2. There is no reason X1:0:: would know anything about X1:X2:0:: structure.

If you mean setting up arbitrary gateways via. DNS, you just pass the IPv6 packet inside an IPv4 packed and do 4over6. That's already part of the protocol, for example RFC 5747.

Re:IPv6 isn't the solution

[Alomex]

You just pointed to a recent, experimental RFC from two years ago proposing, experimentally, exactly what I'm suggesting. This proves two things (1) it is not part of the protocol and (2) I'm not alone when pointing out the flaws on the IPv6 design.

Re:IPv6 isn't the solution

[bogd]

Let's see: one person points (very accurately) one of the main reasons why IPv6 isn't widely deployed at the moment: lack of any kind of backward compatibility with IPv4. He gets modded "0, redundant". Another person mentions 6to4, and gets modded "5, insightful". Looks like the mods have been listening to way too much IPv6 marketing, and are starting to believe it.

Look a little more into the subject, and you will see that 6to4 does not offer backward compatibility in any way, shape or form. It is simply a way for IPv6 "islands" to communicate over an IPv4 network.

The real problem, however, is getting an IPv6-only host to communicate with an IPv4-only host. Until we have that, there is no backward compatibility to speak of. And so far, the only mechanism that can do that (at least partly) is a form of NAT - NAT64. And that is still in its infancy, works only one way (v6 client to v4 server), and brings with it all the disadvantages of NAT (which we are trying so hard to avoid by moving to IPv6).

Even though I do not agree with his solution to the problem (I don't think his multicast solution would have solved the problem), the OP (Alomex) is right - there is no backward compatibility built into IPv6. And this is what has hindered IPv6 adoption from the very beginning.

Re:IPv6 isn't the solution

[bogd]

It's not quite what you are suggesting. While I admit I never heard of RFC 5747 before, it seems to discuss a way for IPv4-only islands to communicate over an IPv6-only backbone (something like 6to4 in reverse). Which means it doesn't help with backward compatibility in any way (just like 6to4 doesn't).

Re:IPv6 isn't the solution

[bogd]

In the sense you mean, no it wouldn't. v6 and v4 routers don't work the same way.

Can you elaborate on that? The actual routing process is exactly the same, it's just the headers that are different.

That's standard dual stack.

And "standard dual stack" means having two separate networks - one that only speaks IPv4, and one that only speaks IPv6. With no way to communicate between the two. And this is the real issue.

Re:IPv6 isn't the solution

[jbolden]

First off I think the discussion here has more or less proven you don't know enough about IPv6 to talk about "flaws in IPv6 design". That issue about who was supposed to do the unwrapping in your routing suggestion was not a minor mistake it shows you don't really understand how routing works now or under v6. Second, every flaw you've mentioned would equally have applied to IPv4 over the protocols it replaced like ARPNet, DECNet or NetBEUI. All protocols are incompatible with most other protocols. That's not a flaw, it is just a fact. IPv6 was not designed as a minor upgrade of v4 anymore and IPv4 was not designed as a minor upgrade of ARP. Third, most of what you have described is stuff that is part of implementing any protocol. There are already people providing IPv6 over IPv4

http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers . Since 1999 tunnels have existed. Tunnels have existed in Windows since Windows 2000
ipv6 install
ipv6 rtu ::/0 2/::$ipv4a pub
ipv6 adu 2/$ipv6b

nothing had to change in IPv6 for this to exist. I just pointed to an example showing that everything you could want is already implemented in v6. You'll notice that this RFC leaves v6 alone.

Re:IPv6 isn't the solution

[Anonymous Coward]

Look, it was you who posted an experimental RFC and called it "part of the protocol". That alone takes the title as the most ignorant posting of the day.

It really takes a special type of idiot to come back after that and accuse the other person of not knowing what they are talking about.

I'm aware that tunnels were proposed a long time ago, as an after the fact fix to the fact that a proper upgrade path was not properly planned. I was there, participating in the discussions even before the IPv6 protocol got finalized, telling people that a flag day deployment could no longer be done in the modern internet, even though it had been done successfully before.

Hence the numerous patches and long deployment time of something that was meant to have gone live long ago.

You seemed surprised at the fact that IPv6 had many flaws, particularly when it comes to deployment issues, even though it currently sits at 1% adoption rate, so this shouldn't be news to anyone who is paying attention. Once again that speaks volumes to whence you talk from.

Re:IPv6 isn't the solution

[jbolden]

Can you elaborate on that? The actual routing process is exactly the same, it's just the headers that are different.

No... The routing process isn't close to the same. There is no capability in IPv6 for a routing table. That goes away. A router handling a particular route is simply implementing a particular bit. So if I'm sending a packet to you in v6 and we disagree on 37 bits there are 37 virtual routers (there may be more one virtual router implemented on a physical router) between you and I exactly. Nothing like that is true of IPv4 where you have complex routing tables. IPv6 makes routing much less complex in exchange for bring latency down. Given that we can't do much about the speed of light along the paths packets are traveling, and most of the features we want are going to involve increasing latency to reduce jitter, this is one of the few opportunities we have for total latency reduction.

And "standard dual stack" means having two separate networks - one that only speaks IPv4, and one that only speaks IPv6. With no way to communicate between the two. And this is the real issue.

Of course they communicate. There is a gateway in between. Your cell phone does this today.

IPv6 A wants to talk to IPv4 B:
1) A gets a dynamic IPv4 addresses assigned to it (unless (4) below).
2) A sends IPv4 packets wrapped inside IPv6 packets to a gateway device which unwraps those packets and sends them to B. Or the dual stack goes all the way and A is routable in which case the packet never gets wrapped.
3) B responds to the virtual IP address. When it does, the gateway wraps B's responses and sends them to A. And or if the dual stack goes all the way through and A can get the packets directly.

B wants to initiate with A.
4) Since A wanted to receive traffic it has setup its own permanent gateway with a fixed permanent v4 address
5) Everything else is like (3).

What is not the case though, what started the discussion with GP is that every v6 address is reachable by v4. As traffic moves to v6, a smaller percentage of v6 services will be offered on the v4 internet, and v4 will become a less and less functional subset of the internet. That's good, that's what we want. That's why this website is on HTML and not Gopher.

Re:IPv6 isn't the solution

[jbolden]

The GP was intermixing the use of protocol and the culture around a protocol. Most technology have associated cultures. DNS is part of IPv4 as it is used.

A proper upgrade path has been planned and is being executed. As for the 1% adoption rate. That's entirely false. Cell traffic which is mainly v6 is about 30% of the internet's traffic. What is 1% right now is v6 clients accessing v6 services and frankly that's because carriers can't handle v6 services. That has nothing to do with end users.

Re:IPv6 isn't the solution

[Dagger2]

Well, it is backwards compatible. There's a "version" field in the IP header, just set that to 4 for v4 and 6 for v6. You can run both of those over the same link and neither will break the other. Any v6 host that wants to speak to a v4 host just has to do it with v4. It's very simple.

The real problem, however, is getting an IPv6-only host to communicate with an IPv4-only host. Until we have that, there is no backward compatibility to speak of.

OK, there are two ways I could respond to this, depending on what you meant by "IPv4-only host". Did you mean a v6-capable host that has no v6 connectivity? In which case the answer is 6to4. That's how a host that understands v6 but has no v6 connectivity can send and receive packets to v6 hosts over a v4-only network.

But perhaps what you were really trying to say is that you want this communication to happen with a computer with no v6 stack (e.g. something running Linux 2.2), or with an unconfigured/disabled v6 stack. In other words, you want a way for v4 hosts to send packets using v4 to v6 addresses, and a way for v6 hosts to send packets using v6 to v4 addresses, and you want to do it without updating legacy v4-only OSs. The v6->v4 case is easy enough. The problem is the v4->v6 case. Via the pidgeon hole principle, it's fundamentally impossible to specify which v6 computer you want to send a packet to using v4 alone, because there's just not enough address bits in v4 to specify the destination.

This impossibility is why IPv6 has no way to do it.

Re:IPv6 isn't the solution

[Dagger2]

As I said, we map many IPv6 addresses into a single IPv4 and use encapsulation to encode the remaining part. Not unlike NATs which use the local address translation table to tease apart many things being mapped to a single IP address, but in this case we use the extra bits encapsulated in the packet.

Once the packet reaches a fully IPv6 capable node it gets send on IPv6

This, right here, is exactly how 6to4 works.

or we use private address space for the journey to complete over IPv4, again, not unlike NATs.

This isn't. This is basically a NAT64 (or NAT46, rather) step on top. It's not really worth it in the general case; just do native v6 over this part, unless there's some real reason you can't do v6 on the hosts (if you're still on Linux 2.2, for instance).

What I keep trying to tell you is that the ideas you're complaining we "should have done", have in fact been done already. They're not integrated directly into v6 because that would make no sense; 6to4 as a tunnelling protocol is transparent to the IPv6 side and is thus optional (and it would be very bad if it wasn't, since we'd be forced to deal with the limited space and fragmentation in v4 until the end of time -- instead we can get rid of it as each network goes native v6) and NAT46 is stateful, which is obviously not doable in a stateless L3 protocol.

These things are available, and have always been part of the intended transition mechanisms for v6.

Re:IPv6 isn't the solution

[Dagger2]

No... The routing process isn't close to the same. There is no capability in IPv6 for a routing table. That goes away. A router handling a particular route is simply implementing a particular bit.

Uhh... what. No. Routing in v6 is fundamentally the same as in v4. v6 has routing tables. Take a look at `ip -4 route show` and `ip -6 route show` on a dual-stack Linux router (or just look at the manpage for the syntax for manipulating the tables) and you'll see how similar they are.

It'll look something like this, based on the output from my own router:

~# ip -4 route show
198.51.100.0/24 dev eth1 proto kernel scope link src 198.51.100.148
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
default via 198.51.100.1 dev eth1

~# ip -6 route show
2001:470:db8:42::/64 via :: dev eth1 proto kernel metric 256 mtu 1480 advmss 1420 hoplimit 4294967295
2001:470:91f3:1::/64 dev eth0 proto kernel metric 256 mtu 1500 advmss 1440 hoplimit 4294967295
default via 2001:470:db8:42::1 dev eth1 metric 1024 mtu 1480 advmss 1420 hoplimit 4294967295

No real difference there.

Re:IPv6 isn't the solution

[jbolden]

I'm sure you can probably configure Linux to do whatever you want. It is mainly designed to allow you to split routes.But no that's not the way it is going to work.

3 bits = format prefix (right now always 001)
13 bits = TLA ID = top level identifier
8 bits = RESV reserved expansion (this is where nasty routing stuff will end up in the future)
16 bits = NLA ID identifiers within carriers / ISPs
16 bits = subnet identifier
64 bits = interface identifier

So right now it is not variable it is a series of binary calls getting you to a subnet based on those 29 key bits. Nothing like IPv4 setup with tables.

Re:IPv6 isn't the solution

[Dagger2]

Woah, woah, woah. We don't hate home routers. Routers are absolutely essential for the internet. It couldn't function at its current scale without routers. Every home should have a router on-site. Any ISP rolling out v6 in a way that prevents users from having their own routers is doing it wrong and they suck. Routers are nice. We want more routing in the world, not less!

What we don't want is ubiquous NAT on all those routers. NAT is just a pain, it breaks a huge ton of stuff without giving you any advantages in return. We need to get away from that.

That said, you can certainly do some nifty and useful things with NAT64 and NAT46, like allowing remote v6 nodes to connect to a local v4-only legacy device. I do that myself to poll my managed switch with SNMP. That's a useful ability for a router to have. But by default, just push v6 to your end hosts without using NAT. Pretty much all of them support v6 themselves just fine.

Re:IPv6 isn't the solution

[Dagger2]

That's at the administrative level, not the technical level. At the technical level, v6 routing is the same as v4 routing.

Also your table doesn't really reflect the administrative splits that we're seeing on the internet, other than the first 3 bits and the last 64 bits. For instance, many ISPs only give a /56, /60 or /64 to end users, who have a "subnet identifier" part of the address that is 8, 4 or 0 bits long.

Or similarly, ARIN allocates /32s to LIRs, but actually reserves a /29 for them -- for instance, take the allocations around 2001:470::/32: the next 7 /32s are unallocated, and the next allocation is 2001:478::/32. The next one after that is 2001:480::/32. In this case ARIN have reserved 3 bits for expansion of the /32s -- but note that this isn't nasty routing stuff, the space is being left deliberately so as to avoid nasty routing fragmentation in the future.

There's also the IANA global unicast address assignment list, which has allocations from all over the shop.

You've got the right idea in the sense that allocations are heirarchical, but the strict bit boundaries are mostly ignored. And it's all administrative anyway; the computers doing the routing couldn't care less.

Re:IPv6 isn't the solution

[bogd]

Well, it is backwards compatible. There's a "version" field in the IP header, just set that to 4 for v4 and 6 for v6.

I suggest you have a look at the term "backward compatibility", and try to understand what I am talking about. Quote: "a product or technology is backward or downward compatible if it can work with input generated by an older product or technology.".

Simply specifying a version number does NOT make a product backward compatible.

If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).

In other words, you want a way for v4 hosts to send packets using v4 to v6 addresses, and a way for v6 hosts to send packets using v6 to v4 addresses, and you want to do it without updating legacy v4-only OSs.

Exactly. Because there is no way you will update the entire Internet (or, on a smaller scale, all the components and legacy applications of an enterprise) all at once. And until you do, you will need your shiny new IPv6-enabled machine to access everything else.

The v6->v4 case is easy enough

No, it isn't (if you do not agree, please feel free to tell me how it is). And please remember that "I'll just put an IPv4 address on it" is not a solution - that will just make it an IPv4 machine as well. And then, why bother adding IPv6 to it??

It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space). Yes, there is more to it than that (you would need gateways capable of "translating" between that prefix and IPv4), but that is one idea.

Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?

Via the pigeon hole principle

Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).

If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem. It might even be an incentive for the host's owner to upgrade :) . But that case will only come into play many years later, when we actually have an IPv6-only internet.

Re:IPv6 isn't the solution

[bogd]

There is no capability in IPv6 for a routing table. That goes away.

No it doesn't. And it cannot. There still is a routing table, it's just... bigger :) (not that big as you would expect though, due to the larger subnets and better aggregation. In theory, at least).

In fact, one of the major selling points of IPv6 is that the subnetting and routing remain the same as in IPv4 (making things a bit easier to understand for administrators).

So if I'm sending a packet to you in v6 and we disagree on 37 bits there are 37 virtual routers (there may be more one virtual router implemented on a physical router) between you and I exactly.

That makes no sense to me. Do you have any kind of reference for the idea that "a bit in the address = a virtual router"?

IPv6 A wants to talk to IPv4 B:

1) A gets a dynamic IPv4 addresses assigned to it (unless (4) below).

Congratulations - your IPv6-only is now also an IPv4 host! That does not solve the original problem - getting an IPv6-only host to talk to an IPv4-only host. Aka "compatibility".

What is not the case though, what started the discussion with GP is that every v6 address is reachable by v4. As traffic moves to v6, a smaller percentage of v6 services will be offered on the v4 internet, and v4 will become a less and less functional subset of the internet. That's good, that's what we want.

I completely agree with you there (see a previous comment of mine). Getting stuff on the IPv6-only Internet might actually persuade a lot of host owners to upgrade.

Until we have an IPv6 Internet however, we need to make sure that people who move to IPv6 can still access the existing IPv4-only services. This is where the v6-to-v4 compatibility is necessary. And that compatibility was completely overlooked.

And no, "just add an IPv4 address to your host" doesn't cut it. If I'm going to have to run IPv4 to access my services, why bother with IPv6 at all?

Re:IPv6 isn't the solution

[Alomex]

This, right here, is exactly how 6to4 works.

Correct. I'm proposing a superset of 6to4 as part of the protocol.

Look, at a higher level, IPv6 was designed to be a flag day transition. When this didn't work people started proposing transition protocols like 6to4 in the hope that they would ease the transition. Fifteen years later it hasn't happened.

What I'm trying to argue is that, clearly, making IPv6 a flag day protocol was a mistake and all the patches that have been proposed (none of which cover all the things I'm proposing) should have been part of the design of the protocol from day one.

We could have made IPv6 such that all applications could go IPv6 native the next day as opposed to hosts. From then on all addresses at the app level are now treated as IPv6, have the IANA issue only IPv6 addresses from then on, and have a simple IPv6 server on the localhost take care of the translation to IPv4 if the host itself is not IPv6 native. Remember software is easy to change, hardware is expensive to upgrade,

All of the above eventually partially happened, in random order and piecemeal fashion. Is it really that difficult for you to see what is inherently wrong with that? Do you not take home any lessons from the dismal state of adoption of IPv6?

If you don't see any lessons from those facts there is little I can tell you that will change your mind.

Re:IPv6 isn't the solution

[jbolden]

getting an IPv6-only host to talk to an IPv4-only host. Aka "compatibility".

That's not the strategy, assuming by host you mean all the way up the chain. Somewhere someone has to be doing 6to4. That is the compatibility strategy that 6to4 exists for a while. And having 6to4 be a service is useful for the important reason that at some point in the future it can be turned off or become an addition fee generating service for service providers or ISPs. The way most ISPs don't support Usenet anymore even though they did a decade ago. When IPv6 hosts can't / won't talk to them, that's probably how you get the last 20% off IPv4 network. Which leaves the IPv4 network as a purely isolated legacy network that ISPs aren't supporting and the only people on it are people who desperately need to be on it for some reason.

Until we have an IPv6 Internet however, we need to make sure that people who move to IPv6 can still access the existing IPv4-only services. This is where the v6-to-v4 compatibility is necessary. And that compatibility was completely overlooked.

We don't want full compatibility you want degraded compatibility. And the reason is because it encourages those IPv4 services to move to IPv6. And that is precisely what we have today with ISPs offering 6 to 4 gateways where some important features (for services) like geolocation break.

And no, "just add an IPv4 address to your host" doesn't cut it. If I'm going to have to run IPv4 to access my services, why bother with IPv6 at all?

1) For carriers / ISPs because their growth is directly tied to their ability to allocate addresses, and the top level agencies don't have anymore to give out.
2) For cell phones / homes / small businesses because you don't have a choice in the matter and / or v4 addresses are an extra charge.
3) After step (1) For the public facing web or many B2B services because that is where your customers are. You want performance or features from being IPv6 in any IPv6 world.
4) For larger businesses eventually after (2) you have to maintain a IPv6 network that is substantial and maintaining a true dual stack is expensive and confusing. It is just easier to move most of the company over to IPv6 rather than have constant gateways.

We are between steps (1) and (2) right now. (3) will happen once the carriers and ISPs are more ready.

Re:IPv6 isn't the solution

[jbolden]

I'm not sure if I understand the distinction you are making between technical and administrative.

I have two pipes I need to push lots of stuff through:

Strategy 1: there is a particular marking that controls which pipe it goes in
Strategy 2: I read the marketing, look stuff up in a table and pick the pipe.

Strategy 2 is much slower. Right now we are build the system around 1. And Strategy 1 is one of the very few opportunities we have to cut latency. I certainly agree we could implement routing on IPv6 using strategy 2, a protocol doesn't tell you how you route. But yes, the routers do care. The simpler the routing strategy the more quickly they can decide on how to handle the packet. That allows for much "bigger" pipes per router.

Re:IPv6 isn't the solution

[Dagger2]

If you want examples of backward compatibility, take a look at IGMPv2 (take a look at section 4), or 32-bit ASNs (section 4.2). These were designed with compatibility in mind, and this is one reason why they could be deployed seamlessly (most people have no idea there ever was a transition to 32-bit ASNs).

Well, I looked at RFC 4893 section 4.2, and the very first thing it says is Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. Is that the example you were thinking about? Because it sounds like roughly the same problem, and solution, v6 and v4 have.

No, it isn't (if you do not agree, please feel free to tell me how it is). [...] It would have been possible (simple example: reserve a particular /96 prefix in IPv6 to encompass the "legacy" IPv4 address space).

That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.

Via the pigeon hole principle

Never mind that - we are talking backward compatibility in IPv6 (not forward compatibility in IPv4, which isn't important for our purposes).

If an IPv4-only host cannot talk to the IPv6-only Internet, that's not really a problem.

Um... what? No, this is a huge problem. You can't just ignore it. You need bi-directional communication or it's useless. There's no point making it possible to send packets to v4 hosts with v6 if you don't also make it possible for the v4 host to respond.

Until we get that case to work, if I move to IPv6 I simply lose connectivity to the entire Internet (99% of it being IPv4-only at the moment, and for the foreseeable future). Hell, I cannot even read slashdot! So... why would I do that?

OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack", which means that we run IPv4 and IPv6 on the same network, at the same time. You won't "move" to IPv6. What you do instead is add IPv6 to the network, which gives you the benefits of IPv6. Then, at some later date, you might remove v4 from the network. Of course you can't remove v4 from the network now, because you'll lose access to Slashdot -- but that's not a reason to not add IPv6 to the network, it's just a reason to not remove IPv4 from it.

Re:IPv6 isn't the solution

[bogd]

Well, I looked at RFC 4893 section 4.2, and the very first thing it says is Note that peering between a NEW BGP speaker and an OLD one is possible only if the NEW BGP speaker has a 2-octet AS number. Is that the example you were thinking about? Because it sounds like roughly the same problem, and solution, v6 and v4 have.

Keep reading beyond the first phrase. And you will find this: However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it).

This is called actually the important part of the transition strategy. And it is completely missing in IPv6.

That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.

And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".

No, this is a huge problem. You can't just ignore it. You need bi-directional communication or it's useless. There's no point making it possible to send packets to v4 hosts with v6 if you don't also make it possible for the v4 host to respond.

I'm not ignoring it - I'm saying that an IPv4-only host does not need to be able to address the entire IPv6 space in order to respond. There are translation mechanisms that allow bidirectional communication with only one side being able to initiate the connection. You might actually have heard about one - it's called NAT.

OK, I see, you don't know how a v6 transition works. We do a thing called "Dual Stack"

No need for sarcasm - I really don't feel the need for this to degenerate into a flame war. You seem to be confusing "transition" with "no problem, we'll just run two completely separate networks and we'll call it transition". Some day you may realize that there is a very big difference between the two.

And yes, dual stack does exactly that - run two separate networks, totally separate from each other ("ships in the night"). And think about it - if I'll have the resources, address space, knowledge and manpower to keep running that IPv4 network for as long as necessary (your misnamed "transition period"), and everybody else will keep doing that, why exactly would I bother to dedicate more resources and manpower to run an additional, separate network (IPv6)?

Re:IPv6 isn't the solution

[Dagger2]

Keep reading beyond the first phrase. And you will find this: However, this document does not assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number -- AS_TRANS could be used instead (even if a multiple Autonomous System would use it).

It sounds somewhat akin to 6to4. I'm not very familiar with BGP, but I did some thinking based on what I do know and I came to the conclusion that doing backwards compatibility the way BGP does it would be similar to the IPv4/IPv6 case if every v4 host was already aware of how to do 6to4. Since this isn't true for existing v4 hosts, and we've already established that we don't want to modify the existing hosts, it wouldn't work for IPv6.

That's what I meant; it's easy in principle because you can just map v4 into a /96 in v6.

And in principle, with sufficient thrust, pigs fly just fine. There's a very big difference between "easy in principle" and "actually doable".

Yes, that was the point I was making.

I'm not ignoring it - I'm saying that an IPv4-only host does not need to be able to address the entire IPv6 space in order to respond. There are translation mechanisms that allow bidirectional communication with only one side being able to initiate the connection. You might actually have heard about one - it's called NAT.

IPv6 is stateless. Any transition mechanism you want to integrate with it must also be stateless. NAT64 is stateful, so it doesn't count. You can run it on top, sure, and that can be a useful thing to do -- but the original point of your post was a complaint about something like it not being an integral part of the protocol, and I was attempting to explain why it's not possible.

You seem to be confusing "transition" with "no problem, we'll just run two completely separate networks and we'll call it transition". Some day you may realize that there is a very big difference between the two.

That is how we're doing the transition from a v4-only internet to a v6-only internet though. I'm not sure what else I can call it. Don't forget that computers can be present on both networks at the same time. It's not like it's an either/or choice (and indeed if it was, I'd agree that a mechanism of communicating between the two networks would be required.)

And think about it - if I'll have the resources, address space, knowledge and manpower to keep running that IPv4 network for as long as necessary, and everybody else will keep doing that, why exactly would I bother to dedicate more resources and manpower to run an additional, separate network (IPv6)?

That's a big "if"... but the answer is "because it saves you resources and manpower".

Re:IPv6 isn't the solution

[Dagger2]

Look, at a higher level, IPv6 was designed to be a flag day transition. [...] What I'm trying to argue is that, clearly, making IPv6 a flag day protocol was a mistake

IPv6 was not designed to be a flag day transition. It was designed to be transitioned to gradually. Tunnels were expected to be part of the transition.

We could have made IPv6 such that all applications could go IPv6 native the next day as opposed to hosts.

Do you realize what you're saying here? You're saying that upgrading the software is too difficult, so let's just upgrade all the software instead. This makes no sense.

We could have made IPv6 such that...

Hm, let's look at this from a different angle: how IPv6 was actually designed. IPv6 has a very simple backwards compatibility mechanism in it already. Basically, if you want to talk to a v4 host... you use v4. Adding v6 connectivity to a host does not affect its ability to use v4 at all. The host will be able to do everything it could before, plus it can also talk to v6 hosts.

Why is this insufficient?

Re:IPv6 isn't the solution

[WaffleMonster]

Only because the protocol wasn't made backward compatible.

Your comment was in direct response to my observation *UNMODIFIED* IPv4 hosts cannot access the IPv6 network no matter how IPv6 was designed.

The reason for this as myself and others have pointed out is due to the simple truth larger address space can not map 1:1 to smaller space no matter how hard you try it is impossible.

The problem is not about IPv6's lack of backwards compatibility it is about IPv4s fixed address space. Increasing IPv4s address space has the same cost as IPv6 deployment.

One easy way to make IPv4 only nodes compatible with IPv6 applications would have been to preserve the old IPv4 prefixes.

Technology allowing an IPv6 only host to access IPv4 network by way of mapping an IPv6 /96 subnet to the IPv4 universe, using a NAT translator and altering DNS response to sell the effect are currently in production use. There is some breakage but it mostly works for web sites and basic access.

It does nothing to address the unmodified IPv4 only hosts dilemma. Allowing IPv6 to access IPv4 does not in any way enable the reverse to occur.

My tour thru those transition ideas which sounded good on the surface but don't actually work is pretty exhausted at this point.. Perhaps more importantly quite pointless at this stage to be reflecting on.

Well... there might still be one lingering possibility left ...perhaps we are all just complete idiots who don't know how to count... enjoy...

http://tools.ietf.org/html/draft-terrell-math-quant-ternary-logic-of-binary-sys-05

Re:IPv6 isn't the solution

[Alomex]

Your comment was in direct response to my observation *UNMODIFIED* IPv4 hosts cannot access the IPv6 network no matter how IPv6 was designed.

Correct, and I've already explained to exhaustion that an application level IPv6 server at the host side, which is much easier to deploy that a change in the OS/network gear at a lower level would have taken care of that.

You refuse to admit this because it means that I had already thought (so far) through every one of your simplistic objections and had already devised a way around them.

Re:IPv6 isn't the solution

[WaffleMonster]

Correct, and I've already explained to exhaustion that an application level IPv6 server at the host side, which is much easier to deploy that a change in the OS/network gear at a lower level would have taken care of that.

You know what is even easier than installing software? Replacing your router with a new one when it eventually fails or becomes obsolete. Half-life of these devices is only a few years.

Most of the transition work when amortized out is in needed administrative configuration of address space and related systems.

OS and software vendors, router vendors, and ISPs bear disproprotionate burdon yet there are relatively few of them.

Regardless of what happens all need to develop the same IPv6 functionality anyway regardless of whether your solution was deployed or not to allow addressing and branching off the IPv4 core.

Currently most end-users being turned up with IPv6 have no clue it has happened.

You refuse to admit this because it means that I had already thought (so far) through every one of your simplistic objections and had already devised a way around them.

My objection is not about whether a given scheme is technically possible. Just cause you can do something it does not automatically follow it should be done.

To be viable better alternative it must provide value and incentives beyond what is being offered with the native dualstack transition.

Currently all I am hearing is nonsense talk about leveraging IPv4 resources which don't exist.

Schemes to take IPv4 allocations back with no regard for viability or the fire it would pour on routing table growth.

Schemes to take the IPv4 network down while concurrently building the IPv6 network with no regard for effect on people stuck with IPv4 only.

Re:IPv6 isn't the solution

[Anonymous Coward]

You know what is even easier than installing software? Replacing your router with a new one when it eventually fails or becomes obsolete. Half-life of these devices is only a few years.

Riiight, which is why 15 years after IPv6 was first introduced it is deployed everywhere... oh wait!

Currently all I am hearing is nonsense talk about leveraging IPv4 resources which don't exist.

There is an adage that says one shouldn't argue with someone who claims there are cows flying around as both sides end up looking equally silly.

Your assertion that IPv4 resources "don't exist" is beyond flying-cows nonsensical, so I'm signing off.

Re:IPv6 isn't the solution

[bogd]

I came to the conclusion that doing backwards compatibility the way BGP does it would be similar to the IPv4/IPv6 case if every v4 host was already aware of how to do 6to4.

In one of my previous posts, I linked to the definition of http://en.wikipedia.org/wiki/Backward_compatibility. You either didn't read it, or didn't understand it - the whole idea behind compatibility is getting the thing to work without modifying the other devices that talk to it.

I'm not saying that the exact same solution that was applied for BGP could be used for IP. They are completely different protocols, with different sets of rules. I just gave you two examples of what real compatibility looks like, since you still seem to believe that 6to4 offers it.

IPv6 is stateless. Any transition mechanism you want to integrate with it must also be stateless. NAT64 is stateful, so it doesn't count.

By your own logic, IPv4 is stateless, NAT is stateful, so NAT doesn't count. Yet the world at large disagrees with you - NAT works just fine, and it is the thing that has extended IPv4's useful life by years. Yes, it has its own set of problems, and we all would like to get rid of it - but until then, it works just fine, stateful or not.

That is how we're doing the transition from a v4-only internet to a v6-only internet though. I'm not sure what else I can call it.

Totally agree with you - it's basically the only solution we have right now. But the fact that it's the only solution doesn't make it a good one. Because this "we'll just run dual stack" thing, in the end, will not lead to an IPv6-ony Internet. It will lead to a world in which most of the computers will be forced to run both IPv4 and IPv6. With network administrators being forced to maintain and update twice the number of ACLs, QoS policies, routing protocols, and so on.

And before you say "no problem, at that point we'll just turn off IPv4!", keep in mind that this will not be possible until there is no IPv4 Internet to speak of. How long do you think that will be? My guess would be on the order of decades...

That's a big "if"... but the answer is "because it saves you resources and manpower".

A big "if", but your logic actually requires it. If we do dual stack, that means that we keep maintaining an IPv4 network. With all that it entails.

And if we're already running that network, how exactly would adding another network (Ipv6) by its side would save anything? Please don't forget that we are talking about the transition here - that transition being done by using dual stack.

Re:IPv6 isn't the solution

[bogd]

It was designed to be transitioned to gradually.

Nope. For all the reasons I explained to you previously, chief being the fact that IPv6 is 100% incompatible with IPv4 on the wire.

Tunnels were expected to be part of the transition.

True. And just as true is the fact that tunnels only solve half the problem. Yes, they help getting new IPv6 hosts to talk to each other (over a potentially non-IPv6 compliant infrastructure). But they do not solve the bigger issue - getting new IPv6 hosts to talk to existing IPv4-only hosts (like, I don't know... the entire Internet?!).

IPv6 has a very simple backwards compatibility mechanism in it already. Basically, if you want to talk to a v4 host... you use v4.

And once again, I strongly suggest that you should read and understand the term "compatibility". I'll give you a hint: "just use the old protocol at the same time" isn't it!

Why is this insufficient?

Because there are only two possibilities: a) we will be able to keep running IPv4 in the foreseeable (or at least short- and medium-term) future, or b) we will not.

In the first case, why bother to add IPv6 to it (and spend a ton of money and manpower on that)? Just because "it's cool"?

And in the second case, there's no way to do dual stack anymore - and where's your "simple mechanism" then?

I'll hazard a guess and say that you've never worked as a network administrator. Or at least not one that has to explain to non-technical people why they need to spend money on technology (in which case, you have been really lucky :) ).

Re:IPv6 isn't the solution

[WaffleMonster]

You know what is even easier than installing software? Replacing your router with a new one when it eventually fails or becomes obsolete. Half-life of these devices is only a few years.

Riiight, which is why 15 years after IPv6 was first introduced it is deployed everywhere... oh wait!

While your response ignores the specific issue concerning upgrades it is shocking people would wait till the last possible minute to make a change with little to no immediate return. Who'd have guessed? Who isn't surprised?

Your assertion that IPv4 resources "don't exist" is beyond flying-cows nonsensical, so I'm signing off.

APNIC and RIPE are already out. APNIC itself was consuming multiple /8's per month. It is not possible to make up for this type of demand by belt tightening and exchanges alone. There are practical limits on disaggregation without forcing everyone pulling a full table in DFZ to spend untold riches on router upgrades. ARIN and LACNIC to follow in the next year or two.

Only addresses left from these RIRs are in the form of small allocations to facilitiate IPv6 transition.

If your an existing ISP in APNIC or RIPE and you need more IPv4 space your only option is to find someone willing to sell you theirs or go without.

IPv6 is only now being deployed in earnest precisely because IPv4 resources for many types of deployment scenrios no longer practically exist.

Re:IPv6 isn't the solution

[Dagger2]

Administrative is how we humans pick which allocations to make. Technical is how routers see the addresses.

On the administrative side, the allocation scheme you suggest in your great-grandparent post... well, take a v4 analogy. In v4, each RIR is allocated a (or multiple) class A networks. Inside those networks, each ISPs/companies are allocated a (or multiple) class C networks. The first 8 bits are the RIR ID, the next 16 are the company ID and the last 8 are the interface identifier.

But in reality we don't actually do it like that. The RIRs get /8s, sure, but companies get /<whatever they need>, and might subnet further if they need to. You can't actually split the address up neatly into well-defined parts.

v6 is the same. The first 3 bits are "001", and we seem to have settled on /64s for subnets (mostly, but not everywhere!). But for the rest of the address? /32 is a common LIR size, unless the LIR is too big, in which case they get something bigger. And ISPs give end users anywhere from 16 to 0 subnet bits each. There is no fixed split that applies to all addresses.

On the technical side of things, the routers don't care about any of this. They scan through the routing tables looking for a match, in the same way for both v4 and v6.

v6 definitely does offer an opportunity to shorten our routing tables though. The huge address space means we can significantly reduce fragmentation -- each company only has one allocation (even if it needs to be expanded), vs needing potentially many thousands in v4. But routing happens in the same way between the two protocols.

(I'm getting quite tempted to look up the actual code that does routing in Linux, so I have something to point to as proof rather than just the circumstantial evidence of `ip` and what I've seen from using IPv6. I'll post back if I do manage to find it.)

Re:IPv6 isn't the solution

[Dagger2]

the whole idea behind compatibility is getting the thing to work without modifying the other devices that talk to it. I'm not saying that the exact same solution that was applied for BGP could be used for IP.

Right, that was where I was going. With BGP, when you pass a message to an AS (regardless of whether the destination AS is 16-bit or 32-bit, or whether or not you support 32-bit), the packet has the true destination (the IP) inside it.

It's sorta like 6to4, where the true IPv6 destination is inside the v4 packet. This style of tunneling works as backwards compatibility for BGP because BGP nodes already know how to do it, but it doesn't work for IPv6 because IPv4 nodes don't already know about it.

I believe that IPv4/IPv6 are incapable of doing this sort of backwards compatibility. The only semi-exception is...

By your own logic, IPv4 is stateless, NAT is stateful, so NAT doesn't count. Yet the world at large disagrees with you - NAT works just fine, and it is the thing that has extended IPv4's useful life by years. Yes, it has its own set of problems, and we all would like to get rid of it - but until then, it works just fine, stateful or not.

It certainly has. I wouldn't count NAT as integrated though, which was the point I was making. It's an optional thing on top.

NAT64 is the semi-exception; it's a way to get a v6 client to talk to a v4 server (but not the other way around!)

Because this "we'll just run dual stack" thing, in the end, will not lead to an IPv6-ony Internet. It will lead to a world in which most of the computers will be forced to run both IPv4 and IPv6. With network administrators being forced to maintain and update twice the number of ACLs, QoS policies, routing protocols, and so on.
...
A big "if", but your logic actually requires it. If we do dual stack, that means that we keep maintaining an IPv4 network. With all that it entails. [...] And if we're already running that network, how exactly would adding another network (Ipv6) by its side would save anything?

Definitely all true. But consider the costs involved in sticking with a v4-only network, vs a dual-stack network where you can use both v4 and v6.

(Warning: wall of text incoming.)

You've got to NAT all your traffic. This isn't free; you may need to buy some quite beefy hardware to do it fast enough. Merging two networks is a pain, because their private ranges collide. Running servers is a pain. You've got to get enough public IPs for them, which is going to start getting expensive. Or you can put them behind NAT too, but there's limits to doing that -- you can't put two DNS servers behind the same IP, say, and what are you going to do when your ISP is using CGN? You can't port forward to your servers at all then. Split DNS is a pain. Debugging problems with any of this costs money.

Having dual stack on the network allows you to side-step a lot of this. For servers that are fully internal, you don't need v4 at all. You might be able to drop v4 on servers that need external access too (maybe all the external clients are your customers, so you can force that on them -- or maybe you just don't care about losing a few viewers.) Split DNS can go away for those servers.

Merging two corporate networks? You might be able to get away without merging the v4 parts at all, if both sides have v6 -- which means no renumbering.

The less external v4 traffic you do, the less fancy your v4 NAT hardware needs to be. With v6 enabled, 50% of your traffic is v6 today. (That stat is from a big university network -- it's mostly Youtube, but still. I've heard of companies turning it on in branch offices and seeing 90% of their traffic be v6, simply because it's all internal traffic and internal servers had v6.)

Yeah, you need to keep v4 around for remote single-stack servers. But your v4 network is going to get more and more painful to manage as the ad

Re:IPv6 isn't the solution

[jbolden]

I wouldn't use the routing code in Linux. Linux isn't used for high performance routers. What you want is IOS (Cisco's not Apple's).

As far as your post I agree with most of it other than the existence of routing tables. My understanding is that there will be no complex lookups. So while it is not the case globally, it will be the case that in individual router will be making a routing decision based on very simple criteria unlike today where there is a table lookup.

Re:IPv6 isn't the solution

[WaffleMonster]

On the technical side of things, the routers don't care about any of this. They scan through the routing tables looking for a match, in the same way for both v4 and v6.

Routers with hardware associative tables do care. Most provide options to effect tradeoff between table entries and prefix length.

v6 definitely does offer an opportunity to shorten our routing tables though. The huge address space means we can significantly reduce fragmentation -- each company only has one allocation (even if it needs to be expanded), vs needing potentially many thousands in v4. But routing happens in the same way between the two protocols.

Unfortunatly much fragmentation is administrativly configured for TE reasons having nothing to do with managing non-consecutive allocations. It will certainly help but don't expect much. Any savings will be more than erased by minimum /48 prefix length for interdomain routing on the Internet.

Re:IPv6 isn't the solution

[petermgreen]

6to4 never contributed to IPv6 traffic cause default host policy says prefer IPv4 over IPv6. It only ever contributed to headaches.

This statement seems kind of contradictory to me If 6to4 is causing "headaches" that means hosts must have been using it. Googles stats also indicate that a load of clients were using it at one stage though that number has dropped off more recently

6to4 provided an easy way for people to build experience with ipv6 without having to agree to a possibly onerous list of terms from some tunnel provider and provides a way for users to access v6 only resources (which aren't very numerous yet but they can only become numerous if everyone can reach them) with only a v4 internet connection.

Having said that 6to4 does have it it's problems. Firstly running over IP directly may have made it slightly more efficient but it also meant it couldn't really be run behind a NAT box, it would have made far more sense to run it over UDP which can easilly be port forwarded. Secondly and more importantly it has performance and reliability problems because ISPs don't take it seriously. If every dual stack PoP had a 6to4 relay router then 6to4 would be fast and reliable but they don't so 6to4 traffic ends up handled by benevolent third parties who may or may not provide acceptable quality of service.

Re:IPv6 isn't the solution

[petermgreen]

a load

I should clarify, by "a load" I meant a significant proportion of total IPv6 traffic at the time, it's still of course tiny compared to IPv4 traffic and pretty small compared to total IPv4 traffic now.

Re:IPv6 isn't the solution

[petermgreen]

Look a little more into the subject, and you will see that 6to4 does not offer backward compatibility in any way, shape or form. It is simply a way for IPv6 "islands" to communicate over an IPv4 network.

Note that the "island" can be as small as one host.

The real problems with 6to4 are

1: it doesn't work behind NAT (even with manually configured port forwards) meaning a large proportion of internet hosts can't use it.
2: ISPs haven't taken it seriously leading to inefficient routing. If 6to4 was considered a requirement for a dual stack core router then it would be far more reliable than it is today.

Teredo fixes 1 but it's pretty fragile because it works against the nat rather than working with it and also has the problem of not being taken seriousy by ISPs.

Re:IPv6 isn't the solution

[petermgreen]

16 bits = NLA ID identifiers within carriers / ISPs

Assuming you are reffering to rfc2374 then that should be 24 bits.

However it doesn't really matter anyway rfc3587 says that the TLA/NLA structure defined in rfc2374 has been made historic.

The early designers of IPv6 seemed to think the internet was a heirachical network but it never was and probablly never will be. The internet is a collection of ISPs and other companies whose relationships are in a constant state of flux. No large company wants to be stuck with a single provider on pain of readdressing, nor do they want to give multiple IP addresses to each end system with a horriblly complex dns system (which has also been relegated to historic status) to manage them.

So in practice IPv6 is routed the same way IPv4 is, autonomous systems declare what prefixes they can reach over BGP and core routers build up a big table of where to send stuff.

Re:IPv6 isn't the solution

[petermgreen]

pretty small compared to total IPv4 traffic now.

Grr that shuold have said compared to total IPv6 traffic now

Re:IPv6 isn't the solution

[jbolden]

I copied this from ARIN.

As for the rest, you are making good points. Next time there is an IPv6 conference I'm going to ask. Bringing back tables strikes me as a huge tragedy. I'd rather large companies have to use variable prefixes, but you could very well be right. Do you have any cites?

Re:IPv6 isn't the solution

[Dagger2]

Except you can run both IPv4 and IPv6 over the same wire, and they won't break each other, which allows you to add IPv6 to the internet gradually. Your traffic will gradually convert from being v4 to being v6 as other people do the rollout. That's a gradual transition.

The fact that you can roll out v6 on an existing network and not lose any functionality on it, even if nobody else rolls out v6, means that it doesn't require a flag-day transition.

I guess the other way to look at it is that the lack of communication between IPv6 and IPv4 doesn't translate necessarily to a lack of communication between internet hosts, which are the things we actually care about. As such, you can't say that IPv6 is stillborn just because it doesn't integrate a means to get around the pigeon hole problem and do v4<->v6 conversations.

Plus NAT64 is a thing anyway, so if that's what you really want to do, then the option is available, with no need for it to be integrated. (Nobody uses it because dual-stack is easier, so having it available earlier wouldn't have helped v6 deployment.)

Because there are only two possibilities: a) we will be able to keep running IPv4 in the foreseeable (or at least short- and medium-term) future, or b) we will not.

You're simplifying (a) a bit too much. NAT works surprisingly well for outbound connections -- sure, we're heading towards having multiple layers of NAT, which is expensive and is going to be incredibly annoying, but in all fairness an outbound connection does tend to make it through them all.

Where is starts being a real pain is when you need inbound connections. Then it's either difficult (= expensive) or impossible to deal with NAT. (Think SIP, or multiple DNS or SMTP servers behind a single IP -- or just things like multiple web or SSH servers. Now imagine what it'll be like when your ISP puts you behind NAT, and you can't even port forward.)

So ideally, you'll be running your own servers on v6, and use the v4 purely for connecting to other people's legacy v4 servers. You can't just run your servers on v4, because the address shortage and NAT on v4 is a problem.

I think (b) is a long way out for outbound connections. But for inbound connections, it's going to be here far sooner. It's already here for some of us.

In the first case, why bother to add IPv6 to it (and spend a ton of money and manpower on that)? Just because "it's cool"?

I know you've seen it, but for thread continuity I'll link the post I made earlier, where I wall-of-text a bunch of reasons for wanting v6 even when you have v4 (the summary being that it allows you to side-step the problems in your v4 network caused by address shortages).

I'll hazard a guess and say that you've never worked as a network administrator. Or at least not one that has to explain to non-technical people why they need to spend money on technology (in which case, you have been really lucky :) ).

OK, you're right there. But I feel the start of the issue is more that the expense of dealing with NAT in v4 is ongoing and something you're already paying for, and the savings from v6 are in reducing that ongoing expense. Everybody ignores all that and concentrates on the upfront costs of a v6 rollout, because those are obvious and all they care about is next quarter's statement.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:older modems / routers are a isses as well and

[jones_supa]

Then we replace the modems.

IPV6 and Debian...

[LVSlushdat]

I recently signed up for a Xen Linux vps thru a vendor to run a mail server on, I provisioned it with Debian/squeeze, and while installing everything, I happened to notice that the apt-get sessions were talking to the Debian repos via ipv6. Was kinda startled, as I'm not used to seeing those humongous ipv6 addresses.. The vps vendor gives you at no extra charge two v4 addresses and three v6 addresses. Although I see in their blog, they are dropping the v4s to one per vps without a significant extra charge starting this month. If anybody's looking for a 512mb Xen vps at a truly awesome price, check out Virpus Networks. In the past I'd always gone with OpenVZ slices as they were the cheapest as my "projects" requiring a vps are personal, and have a VERY low budget. But I wanted to get away from some problems that my last OpenVZ vendor had, and I found Virpus offering a 512mb Xen vps for less than I'd been paying for the 512mb OpenVZ slice.. Anyway, have nothing to do with Virpus other than being a satisfied customer...

Re:IPV6 and Debian...

[unixisc]

Three /128 v6 addresses? Or three /64s?

Re:IPV6 and Debian...

[agwadude]

Those guys are doing it wrong. First, automatically assigning 2 IP addresses per VPS, no questions asked, is extremely wasteful, is part of the problem, and is actually in violation of ARIN rules which state that there must be valid justification for every IP address issued. At least they're going down to just one address by default. Linode, in stark contrast, only issues one IPv4 address by default and really puts you through the ringer if you want more. AFAIK they'll only give you extras if you're running HTTPS vhosts with distinct certificates (and they check too!).

Second, while I commend them on offering IPv6, they only give you 3 addresses??? IPv6 has been designed to support large allocations of addresses to end-users. Comcast currently routes a /64 to each customer (1 subnet, or 2^64 addresses), and many hosting companies also route /64's or larger to each server. Heck, Hurricane Electric's free IPv6 tunnel service will route you a whole /48 (65536 subnets, or 2^80 addresses).

Re:IPV6 and Debian...

[tftp]

Second, while I commend them on offering IPv6, they only give you 3 addresses???

Commerce only exists because of scarcity. ISPs would love to charge you $5 per year for each IPv6 address allocated. It makes no difference that these addresses are free to them. You are not the owner of the IP block, they are -- and they can dictate the terms.

Re:IPV6 and Debian...

[petermgreen]

And I'd love to tell those ISPs that they aren't getting my business.

Which side will get what they want depends on how much competition there is and how much each side wants it. For end user ISPs in some places there is little competition so end users may be forced to accept such terms. OTOH for hosting providers there is plenty of competition. If having a full /48 is important to you i'm sure you will be able to find hosting providers who offer it.

Re:That's easy.

[NatasRevol]

They can still find it.

Try IPv9¾

Just assign $PREFIX::$N

[ebiederm]

Manually assigned ipv6 is quite doable. It is really just a matter of assigning $PREFIX::$small_memorable_number.

There should only be one prefix you have to worry about and if you forget it you can look at any other computer on the network. Then just assign your servers each a small number.

For your case with VMs coming and going it would not be at all hard (and would probably result in better testing) to go the ISP route and assign a unique name to every address and then just report that name to your testers and devs. Reusing the name is exactly the same as reusing the ip address. Then you just have a series of machine names. testvm1, testvm2, testvm3, ... etc.

Really none of this is very hard, confusing or cumbersome. It just takes someone asking: "How do I make this work?" instead of thinking "Oh no! that is going to be horrible." and looking for excuses not to make it work.

Multicast?

[Anonymous Coward]

I've been waiting for the IPV6 killer application to show its head. Until then I don’t think Joe public will know or care what IPV6 is and why they should use it.

So I mention this here in the hopes that it will light somebodies bulb and somebody will probably correct me on this, but I always thought IPV6 included global multicast, which would make lots of new application possible. Imagine being able to stream content from your home to any number of people without the need for a costly connection. Kinda makes bit torrent look so last century.

Re:Multicast?

[tftp]

Imagine being able to stream content from your home to any number of people without the need for a costly connection.

You'd have to do the imagining from within the prison cell :-) A copyright crime is worse than murder because when a peasant kills another peasant nobody cares; but when a peasant steals content from a corporation then the sirens start wailing, and no punishment is too high for such a crime.

The Internet remains the Internet only for highly technical people. Everyone else is a consumer; and corporations do not want consumers to run servers and stream anything. If they want to do that they can always pay some small fee to a Corporation that will do this work for them, legally and with no effort. Consumers should only buy services. The majority of consumers are not even aware of those possibilities because they are not the specialists. More and more consumers switch away from general purpose computers (that could, in principle, do such things) to phones and tablets that aren't designed for advanced networking, and it would cost you way too much to stream over a wireless data connection. Those phones and tablets are often a walled garden anyway.

In other words, the IP version is not a significant factor in development of new commerce over the Internet. Skype works fine over IPv4 as it is, and the browser works. That's all that the common man cares about.

Re:Multicast?

[WaffleMonster]

In other words, the IP version is not a significant factor in development of new commerce over the Internet. Skype works fine over IPv4 as it is, and the browser works.

Most of skype is dealing with endpoints who are both behind nats and threfore unable to connect directly to each other so conversations are punted unecessarily thru other users systems with better connectivity. This creates significantly higher latency, unecessarily wastes resources of multiple parties and lowers overall reliability and quality of the communication.

With a network of peers "skype" would simply consist of an optional directory to facilitate people finding and connecting to each other.

People don't care about IP version and they don't care about network topology. What they care about is results and capabilities of the tools they use.

Delivering a network of peers enables better tools and lowers the barrier to entry for developers. You no longer need to design complex P2P schemes or operate an armada of supernode servers to facilitiate communication between people.

That's all that the common man cares about.

These sorts of arguments ignore the opportunity cost of the equation. It is not enough to simply assert x works fine so y is not needed. One should also consider what would additionally be possible if y was delivered.

Re:That's easy.

[WaffleMonster]

How so? Many (if not most) end system addresses have the MAC address embedded in the v6 host address, so you get more information out of a v6 address than you do out of a v4 address (including the ability to trace the same device even if it changes layer-3 networks).

Since most vendors aren't supporting RFC 3972, tracking is probably going to be easier, not harder.

I think you might be thinking about privacy addresses enabled by default on Windows and configurable on MAC and Linux.

Re:That's easy.

[Anonymous Coward]

Harry Potter references

killer app?

[DECula]

Unless we come up with a viable DNS RBL for ipv6, the killer app for ipv6 is going to be spam. Hey mister, wanna buy a Rolex?
I hope someone is working on services like this. I can also imagine one heckofa bot net once we get all those soda machines and
refrigerators online.
 

Re:killer app?

[KiloByte]

the killer app for ipv6 is going to be spam

Woooh... amazing! Looks like the last non-spam piece of mail my mail server received over IPv4 was three days ago, most of legitimate mail I receive comes on IPv6. On the other hand, the last piece of spam not over IPv4 was on 2012-12-26 (from 2604:e800:184::6d0e:3a91).

This seems to be a random fluke as it's quite rare to not get anything via gmail in three days (it was the culprit that broke the streak), but fluke or not, that's what's on the top of my logs right now.

Re:killer app?

[DECula]

Are you counting before or after filtering? My point is that certain filtering schemes are going to be hindered by ip6.

Re:killer app?

[jbolden]

Hopefully when we switch to IPv6 we can switch away from SMTP to one of the zillions of other options that blocks spam. If not then RBL will just work on the first 8 octets or less and ignore the last 8+ ones.

Re:killer app?

[KiloByte]

Before of course (grepping for perm rejects (734 in these three days), plus manually counting five or so spams that got through).

My point is that certain filtering schemes are going to be hindered by ip6.

And my point is that, at least at the moment, giving a message some negative spamminess score just because it came on IPv6 could be a good idea.

Re:That's easy.

[WaffleMonster]

Without it, they can sell IPs for nice amounts without paying for it themselves. For ISPs it would even be nice to just give everybody a 10.x.x.x address (as they do with phones) so you can not run any server, or with very much work.

It is much better and easier to control on many levels of control.

So why would they go to IPv6, which will cost money, while sticking with IPv4 will bring in money.

Given scale of traffic large ISPs are dealing with today it is expensive enough just for the gear to look up L3 addresses in IP header and make routing decisions in hardware associative memory.

ISPs benefit today by deploying IPv6. When they do a huge slice of their traffic (youtube, google, facebook, netflix) no longer has to go thru more expensive and headache causing carrier NAT where headers must be inspected, mangled and where state must be allocated for every transaction.

There are other benefits to the customer in overall reduced latency, issues with P2P, games and hosting servers/content without dealing with NAT barriers and assorted headaches. These benefits translate into happy customers and less support overhead for the ISP.

There are also regulatory headaches stemming from lack of ability to associate an IP with a subscriber where multiple are behind NAT for CALELA. If you think this is a good thing the workarounds are far worse.

It ain't working

[Alomex]

IPv6 ain't working. This should pretty much be clear to all, since it is not being widely adopted. The IPv6 proponents can down moderate those who point the flaws all they want but the facts speak for themselves.

A more constructive approach was to take steps to facilitate its adoption, such as tunneling, the IPv6 day and the IPv6 experiment. It didn't work. Fourteen years since it has been introduced with IPv4 address space running out rapidly and still only 1% of the internet. At this point we have to believe that nothing short of a completely new protocol will succeed.

Re:It ain't working

[WaffleMonster]

IPv6 ain't working. This should pretty much be clear to all, since it is not being widely adopted.

All major ISPs in US are in the process of testing and rolling it out.

Google, Netflix, Akami, Federal government, Facebook all on IPv6.

All major CPE vendors shipping IPv6 enabled gear.

Perhaps you know something they don't?

There will be a long tail and it will take forever to move enough for the plug to be yanked on IPv4. Nobody is saying RFC 801.

A more constructive approach was to take steps to facilitate its adoption, such as tunneling, the IPv6 day and the IPv6 experiment.

All these "steps" did was throw a wrench in the process of adoption. This is 2013 and people demand a production quality network. Tunneling does NOT provide that.

Content is not going to deploy to a shit network with no bandwidth and crappy availability that tunneling provides.

IPv6 day was necessary mostly to identify and fix what went wrong with the tunneling nonsense already deployed.

still only 1% of the internet. At this point we have to believe that nothing short of a completely new protocol will succeed.

We all get to believe what we want. I choose to believe publically available bandwidth charts showing an exponential curve and the interface statistics on my router showing ~30% of my traffic by volume is IPv6.

Re:It ain't working

[Alomex]

I choose to believe publically available bandwidth charts showing an exponential curve

Here are some charts. Hardly a success story.

http://www.labs.lacnic.net/stats/

http://www.google.com/ipv6/statistics.html

You also have to remember that total traffic is growing exponentially, so merely exponential IPv6 growth is not enough to close the gap unless the base is bigger than IPv4's.

Re:It ain't working

[jbolden]

It is being widely adopted. Virtually every major carrier on the planet has an adoption plan that is underway. In many Asian countries they are almost fully converted. In the USA the cell networks are converted with home / small business likely to be converted by end of 2014. Too slow yes. Not being adopted, no.

Re:It ain't working

[Anonymous Coward]

Really? I disagree. There's quite a bit of IPv6 traffic over at FB these days.

Re:It ain't working

[Kjella]

That IPv6 isn't adopted doesn't have anything to do with the qualities of the protocol. It's as simple as this:

1. We're not out of addresses yet. If you've been smart you've grabbed some space or if you're an international company you get some from the registries that still give them out that you don't have to worry.
2. Even when we hit that brick wall, you just buy them from somebody else. Short term it's probably cheaper than to fix your systems.

People knew that Y2K was coming waaaaaaaaaay before year 2000, yet most fixing happened in 1999 because now it couldn't be put off any longer. Guess what? People aren't going to switch to IPv6 until it's clear that doing it now has a better business case than buying some more IPv4 and waiting for the dust to settle.

Re:It ain't working

[someones]

it does!

IPv6 is bloated crap noone actually needs?

And they even removed established features like NAT, "because its an ugly hack, blablabla", not even thinking about multihoming, loadbalancing and privacy.

Well why think about using ipv6 if yopu cant even do topology hiding?

Re:It ain't working

[Alomex]

That IPv6 isn't adopted doesn't have anything to do with the qualities of the protocol.

The fact that people wouldn't switch unless forced to has everything to do with the qualities of the protocol. When technology is superior people cannot wait to move to it (e.g. CDs, DVDs, MP3 players as an audio progression, or WWW replacing gopher). Yet with IPv6 people have been dragging their feet for as long as they can. Fifteen years and counting.

Re:It ain't working

[strikethree]

It has been about a decade since 64 cpus have been available and yet we STILL can't get rid of that 32 bit crap. 32 bit was awesome in that it offered a flat memory space but that time is LONG gone. Hell, Firefox is STILL refusing to seriously consider 64 bit. The plugins can not change until the browser changes. Meh.

Re:It ain't working

[petermgreen]

Any new protocol will take years to deploy, years that we don't have.

The choices going forward at this point are IPv4 ISP level NAT, IPv4 ISP level nat in dual stack with IPv6 or IPv6 with some from of transition method (NAT64, DS-LITE etc).

Mistakes were made but they mostly weren't mistakes in the design of the core protocol, they were policy mistakes such as failing to provide any real incentive to ISPs to deploy IPv6 and doing a poor job of providing transition mechanisms for users behind v4 only NAT boxes (teredo came too late and has a fragile design). Which have resulted in lots of places leaving deployment to the last minuite.

Still big improvements have happened in recent years. A significant one was when HE very generously deployed a large number of 6to4 and teredo relays and advertised them on the public internet making those transition mechanisms far more reliable for users. Another was the implementation of the "happy eyeballs" specification in many web browsers (though sadly not in IE) to reduce delays for users with broken IPv6 connectivity and hence both reduce the chances of end users disabling IPv6 as a workaround and making website operators able to be more confident in offering AAAA records.

Re:That's easy.

[firewrought]

Privacy extensions are enabled by default in Windows, Mac OS X (since 10.7), and iOS (since version 4.3).

But it doesn't keep ISP's from moving to permanent, static IP addresses. So privacy extensions will "blur" the PC's within a single household together and keep stalking firms (um "ad agencies") from tracking you as you move between coffee shops*, but, in practice, all household traffic you generate will be branded with the same permanent, unique address.

I'm not poo-pooing IPv6, that's just an unfortunate drawback that comes with all of its advantages.

*Tracking you by IP, that is, there are still cookies, local storage, browser fingerprinting, etc.

Want to make it happen fast? Easy solution

[WindBourne]

Start removing classes for use in the IPv4 arena.

Right now, ISPs, esp. in America, are not converting because they do not need to. BUT, to speed it up, all that needs to happen is to require that 5% of the IPs be returned every year or so, starting 1 year out. That will pretty much force the situation.

And for those that will scream that this is not right, BS. It is needed. Long needed.

Re:Want to make it happen fast? Easy solution

[jbolden]

ISPs in America are converting. Those threats were useful 5 years ago. Now ARIN is out of IPs. They can't get more IPs to sell. You don't need artificial threats, the natural ones are unpleasant enough.

Re:Want to make it happen fast? Easy solution

[WindBourne]

Funny thing is that I have heard others say exactly what you are saying for the last 5 years.

Actually, ARIN still has plenty of IPs in America. We have not run out. Yet. In addition, as ISPs in other nations convert to IPv6, they will likely release IPv4 subnets. IOW, it will be possible to move subnets around shortly. In addition, I have noticed that a number of cloud systems have NOT made the jump to IPv6 yet. They are holding back to see how to simplify their own set-up.
So, the best solution is to start subtracting subnets each year. Basically, force the issue and keep it going.

Re:Want to make it happen fast? Easy solution

[jbolden]

For ARIN
2006 - 13 /8s used
2007 - 8 /8s used
2008 - 9 /8s used
2009 - 10 /8s used
2010 -- 22 /8s used
0 remain as of Feb 2011.

ARIN had small sets left and probably some stuff they can give out but we are depleted.

In terms of best solution I think the best solution is to convert. I don't know how crazy disjointed people want to make the routing tables and I don't see why other countries would give more IPv4 space to the USA rather than say Africa which needs it far more.

Re:That's easy.

[petermgreen]

Doesn't really make much difference.

Presumablly each customer will be allocated a v6 prefix just like they are allocated a v4 address now. Combine that with privicy extensions and it will be easy to track to a property but difficult to track beyond that.

Someone told me the sky is falling!

[blogagog]

"IPv4 is much like a limited natural resource; it can't last forever. The well of new IPv4 addresses is already running dry in many parts of the world." In 1998, I heard we'd run out of IP4 addresses in 1999.

Re:That's easy.

[Matt_R]

But it doesn't keep ISP's from moving to permanent, static IP addresses.

I wish my ISP could offer me static IPv6, but they currently can't do it!. Right now I have a dynamic /48....

Re:That's easy.

[Anonymous Coward]

In England, we are lucky, most geolocation services get the city info wrong, I doubt they will be geolocation services which can 100% identify a property for some time, and then it would probably be against EU law on privacy grounds.

Re:That's easy.

[unixisc]

FBSD uses the EUI-64 convention, where the MAC address is obvious. It's good to know that iOS and OS-X haven't gone w/ that.

Re:That's easy.

[unixisc]

But since an ISP will give one a whole link - be it /64, or a subnet, such as /60, /56 or /48, isn't it obvious that the decision of whether to use static or dynamic addresses (or indeed a combination) is w/ the end user? Not to forget - in IPv6 - unlike in IPv4, multiple IP addresses are allowed on a node.

DHCP6 perfect for VMs

[unixisc]

Test VMs? Why not put them in DHCP under IPv6? Have your usual prefix, followed by something like a code range to indicate that it's a VM, and then let it cycle the numbers under DHCP6? Like if one has 2001:a:b:c:add::[hhhh] where the last word is the random number assigned to the VM, which can range from 0x1 to 0xffff?

Mobile devices should have been the launching pad

[Anonymous Coward]

We missed a golden opportunity about 5 years ago. Companies such as Apple and Google should have made it a condition of publishing apps on their respective app stores - that if you want something published, it must fully support IPv6. No app would be permissible to be published if it didn't function fully with the IPv4 stack entirely disabled. Given the millions of devices that now run on mobile phones and tablets, this would have all but ensured that developers and hardware manufacturers of devices had no choice but to support IPv6.

Sadly, this didn't happen, so now we have 100s of millions of new-breed devices still stuck on IPv4.

Re:That's easy.

[DarkOx]

1998 called and they want your argument back. The fact is the sort hardware needed to build connections, store them in memory, and do the actual translation is just not that expensive anymore.

Re:older modems / routers are a isses as well and

[marcosdumay]

Last time I was out to buy a modem, I couldn't find a single one reasonably priced (within 1000% of the cheapest model's price) model that supported IPv6.

I use it as bridge, but most people will have a problem with it.

It will take decades because nobody thought about

[Anonymous Coward]

I don't because I can't - Nothing I have supports IPv6 and until someone makes a router capable of NAT'ing between IPv6 and IPv4 I'm basically stuck.

It's basically why we still use x86 even tho' it's a terrible architecture - When they designed IPv6 they didn't put any thought into forward and backward compatibility concerns, so what we have is not an upgrade but a shift to a totally new protocol standard that is 100% incompatible with no natural way of the two swapping traffic.

It would be just as difficult to move the Internet from IPv4 to IPX or NetBEUI!!

Re:That's easy.

[Cimexus]

Heh, my ISP offers a "semi-static" /56 currently to IPv6 clients. "Semi" static in that, while it hasn't changed yet after over a year of use, they offer no guarantees they won't change something in the future that makes it dynamic :)

Re:That's easy.

[Cimexus]

Well I don't know "why", but many ISPs around here offer or are starting to offer IPv6. None are thinking about doing carrier-grade NAT (with the exception of some of the cheaper mobile phone networks, and frankly, I don't really have a problem with it for phones ... not like I'm running a server on my phone, plus you can usually pay a nominal sum for a 'real' IP if required).

People want real IPs and any decent ISP will offer them. Simpler to administer for them, and not really much of a cost - they just make sure they always buy IPv6-compatible hardware and software over the course of their normal upgrade cycle, and eventually they will be able to offer IPv6.

IPv6 on AT&T DSL using 6rd

[Anonymous Coward]

AT&T DSL is quietly rolling out IPv6 : see section 3 here : http://www.att.com/esupport/article.jsp?sid=KB414401

I got it working w/ OpenWRT.

cheap easy multihoming (multi-isp failover)

[heper]

When will they come up with an easy/cheap "out of the box" solution for small/medium business so they can plug their dsl & cable modem and have some redundant connection?

Yes i know there are workarounds with NAT66. Wasn't that one of the selling points of ipv6 - not to have to use NAT ?

Re:cheap easy multihoming (multi-isp failover)

[someones]

nat66 is not a real good solution.
And not a solution for topology hiding at all.

Re:cheap easy multihoming (multi-isp failover)

[petermgreen]

mmm, that IS a problem.

There are three possible soloutions to multi-ISP operation (whether for v4 or v6), none of them great.

1: have your own IP block and advertise it over BGP. The trouble with this is that the number of people who can do it without killing the core routers is limited, so noone wants to encourage people to do it who aren't already doing so.
2: use NAT, this is what everyone does for IPv4 but it's what we are trying to get away from for v6.
3: put multiple v6 addresses on each end system. The question then becomes how quickly can you get the end systems to stop using an address block if it's associated internet connection fails.

I suspect the best compromise may be a combination of 2 and 3. Stop advertising addresses whose connectivity has failed but use NAT to bridge the gap until the clients stop using them.

Well, there's RFC 4213

[onebeaumond]

Describes the dual-stack solution where IPv4 and IPv6 coexists on the same network. This standard dates from 2005, is widely used, and works well. When the tipping point comes, the speed of transition will come as a great surprise to many. Probably within weeks rather than months.

Re:Well, there's RFC 4213

[Tough Love]

When the tipping point comes, the speed of transition will come as a great surprise to many. Probably within weeks rather than months.

Smells like wishful thinking to me.

Re:That's easy.

[petermgreen]

In England, we are lucky, most geolocation services get the city info wrong,

AIUI the free geolocation services are basically built on freely available data while the pay services supplement that with data from their own research. If the ISPs don't make the data easilly available (I don't think there is any obligation on an ISP to post where in the country and allocation is being used) the free databases won't have it. If the ISPs put users from different places in one subnet then the pay databases won't have it either.

But when I wrote that post I wasn't thinking of publically available geolocation services, I was thinking of the government (who can demand information from your ISP) and possiblly big companies (who can correlate IPs used for one activity with those used for another).

The neglected private internet space at 172.16/12

[tepples]

In my experience, most IPv4 private internets use 10/8 or 192.168/16. I haven't seen any using 172.16/12, so I guess that could be used for a VPN if one end is using 10/8 and the other 192.168/16.

Re:It will take decades because nobody thought abo

[WaffleMonster]

It's basically why we still use x86 even tho' it's a terrible architecture

x86 is a superficial interface to the underlying architecture. x86 has not dictated processor architecture for decades.

When they designed IPv6 they didn't put any thought into forward and backward compatibility concerns

Compatibility dominated the process.

have is not an upgrade but a shift to a totally new protocol standard that is 100% incompatible

In a nutshell IPv6 is the same as IPv4 with larger source and destination address fields. All upper layer and general protocol operation is unchanged. As Gaurab put it - 96 more bits no magic.

It would be just as difficult to move the Internet from IPv4 to IPX or NetBEUI!!

The jist of the problem to be solved is lack of addressing space in IPv4 header. Whatever clever way you decide to arrange fields in a protocol header still does not change the reality you are dealing with two separate universes of addresses regardless of what the protocol looks like.

This is an operationally unavoidable reality. You can't do any better without touching everything IPv4 in existance. This has the same cost as IPv6.

Re:That's easy.

[scared masked man]

Not if the subnet allocation itself changes from time to time.

IPv6 is coming, but NAT will save the day

[Anonymous Coward]

> As a result, we have a nasty Nash equilibrium: nobody can improve their own situation by unilaterally adopting IPv6.'"

The problem is that nearly everyone pushing IPv6 is so hot and bothered by NAT and the way 99.7% of people use routers that they're overlooking the most obvious way to spearhead nearly-overnight ipv6 adoption: grafting ipv6 onto NAT at the router level so the devices on the consumer side of the router can have 192.168.x.x or 10.x.x.x IP addresses, but have a public IPv6 transparently (and bidirectionally) mapped to it in a 1:1 and deterministic manner. THEN, as the mood strikes and/if they feel sufficiently motivated someday, they can take the next step & give their devices IPv6 addresses one at a time as they see fit, and transparently NAT ipv4 traffic to them with the same router.

For example, suppose your ISP assigns you the following IP addresses: a DHCP-assigned IPv4 address like 64.244.118.17, and an IPv6 /48 prefix like 2001:C80:a72d:db33::.

On day one, you have 4 internet-connected IP webcams assigned to 192.168.100.10 (port 8100), 11 (port 8110), 12 (port 8120) , and 13 (port 8130). Your router is 192.168.100.1, and your computers, tablets, and other devices have DHCP-assigned addresses between 192.168.100.100 and 192.168.100.200. Fairly normal, no? Now, enter the magic IPv6-aware router. You obviously have ports 8100, 8110, 8120, and 8130 of your public IPv4 address forwarded to the cameras. However, you ALSO have ALL ports of 2001:C80:a72d:db33:192:168:100:10 DMZ-forwarded to 192.168.100.10. Ditto for the rest:

2001:C80:a72d:db33:192:168:100:11 is DMZ-forwarded to 192.168.100.11
2001:C80:a72d:db33:192:168:100:12 is DMZ-forwarded to 192.168.100.12
2001:C80:a72d:db33:192:168:100:13 is DMZ-forwarded to 192.168.100.13

(yes, I know 192.168.100.x is decimal, and IPv6 uses hex. 100, 10, 11, and 12 also happen to be valid values for IPv6 address chunks. At the end of the day, they're mostly ornamental mnemonic tools to let our happy homeowner keep his internal, external, IPv4 and IPv6 addresses and port mappings straight, and spare him from having to try and memorize unholy and unmemorable IPv6 abominations like 2001:C80:a72d:db33:1b93:7dca:2819:ff29

OK, so admittedly, at this point, you've gone through a fair amount of manual setup labor, and played with it long enough to verify that it works. However, you discover that your favorite webcam-viewing Android app can't deal with IPv6 addreses, so you abandon the project for a few months.

The following year, your ISP announces that it's going to implement CGN. You freak out and panic. Your cameras! Sure enough, the viewer app still doesn't work properly with IPv6. But in your angry search online, you learn about RFC 6346 ( http://www.fastlaneus.com/blog/2011/10/17/ap-an-interesting-alternative-to-large-scale-nat-lsn-or-carrier-grade-nat-cgn/ ), and learn that if you call your ISP and threaten to cancel, they'll let you pay a one-time fee of $25 and set you up with 4096 ports of a public IPv4 address instead. You end up having to remap your ports (since 8100 through 8199 aren't in the block they assigned to you), but you've dodged the bullet. For now.

Two years later, your ISP announces that it's going to start charging $1/month per 16 ports allocated to you through RFC 6346. Dreading the work of remapping your stuff again, you sigh and buy a new webcam app that can work with IPv6 and try it. It works! You call your ISP and tell them to cancel the A+P service entirely.

Keep in mind, you're still using a bunch of IP webcams that will probably never themselves support IPv6... but thanks to your own router's magic, the camera who thinks of itself as 192.168.100.12 can be transparently reached directly at [2001:C80:a72d:db33:192:168:100:12]:8120. And the new IPv6 webcam you bought last year? Now you can reach it directly at 2001:c80:a72d

Re:IPv6 is coming, but NAT will save the day

[ledow]

I find that anyone that mixes NAT and IPv6 problems usually doesn't administer their own networks.

NAT saves a lot of administration for a small business or home network. You have ONE outside address, and all your Internet traffic goes through ONE machine. That ONE address is unmistakably external, can have several thousand services running over it, and can be your external address for everything all at once. As an admin, you only need to know that one address (or corresponding DNS alias), and you can be fairly sure when setting up your firewalls etc. that you know what's coming in / out, from / to where.

And then all your internal client machines? Well, their numbering is by definition none of anybody else's business, not even your ISP. It absolutely, 100% does not matter. I could be running them over token-ring and IPX for all anyone outside cares, so it honestly does not make any difference whatsoever to anyone else. And 99.99999% of networks will never, ever, ever exhaust the reserved internal ranges of IPv4, so it's easier to keep it simple internally, not have to make ANY internal changes, and have one single machine visible to the outside world handling all the "complex" stuff and horrendous addresses that are a pain to memorise, type, tell others, trace through logs with grep, etc. And if (when) the time comes that IPv4 is unsupported on a machine? You assign the gateway an internal IPv6 address, add a DHCPv6 range, and viola - it all works 100% again.

The trick to most small business network administration is to simplify changes down to their smallest possible set so as to have the least impact. You use your brain to do less work without compromising elsewhere. And using IPv4 internal and NAT'ing that to "whatever" is external is the easiest way to do that without having to risk leaving holes in your configuration for a while to come.

I don't WANT direct-accessibility to internal network ranges, that's why NAT has always been a viable option because it prevents that and that's what I WANT to do anyway. Yes, a firewall is capable of intercepting anything anyway, if I really want to, but having things go through a single machine that sanitises traffic and discards any attempt to communicate directly to machines that may not have the protection they should (e.g. random public devices on an internal Wifi connection offered as a convenience to guests). Instead of administering hundreds of individual machines and their software firewalls, plus an expensive IPv6-capable router at the border with thousands of rules in order to secure the machines, you can just NAT the whole network and secure that one external router/gateway machine to block things that were unsolicited or shouldn't be getting through to any machine.

And, given that most people would have to deploy a non-trivial configuration where they DON'T just pass external traffic direct to internal machines (whether by NAT'ing or by a complicated firewall configuration), people who complain about NAT are complaining about something that will NEVER affect them - a total side-issue that concerns almost no-one.

My networks are IPv6 compatible already. 100%. You can put an IPv6-capable host into it, get an address, and talk to all internal services and externally. You can also access remotely by IPv6, and even access IPv6 websites from an internal IPv4 client that has no support for it. It's literally a handful of lines in your existing configurations. And we have external servers with IPv6 addresses. Nobody uses them but they are there, and work.

The fact is that the entire NAT thing is a diversion to make us think we have to do entire network overhauls and upgrades to make this new-fangled thing work. It's just not true. I will no more allow internal clients to send out on SMTP ports or allow external hosts to access, well anyway internal, over IPv6 than I would over IPv4. It's just a diversion.

And a nice diversion from those sites, like Slashdot, that posts an IPv6 article about once a month

Re:IPv6 is coming, but NAT will save the day

[someones]

so NAT for topology hiding is a bad idea?
oh yeah just go with prefix translation: totally doesnt solve the needs, but its NAT.

NAT for multihoming and load balancing: nope, because you can just assign tons of ips to all of your network devices.
Because if it worked in ipv4 with just one address, its not awesome enought. well you know: more addresses for one device is the way!

Talk about nat being crap: YES, it is crap the way they did it.
It was a hack in ipv4 and they should have made it better in ipv6.
But no. instead the ipv6 guys did not think about adding nat to core: just get rid of NAT: ugly hack blah, blah blah
But hey we all know protocols by comitee are the best. ... guess that are my reasons to NOT adopt ipv6 as long as possible.
Without address level NAT it is simply a pain in the ass.

Re:IPv6 is coming, but NAT will save the day

[WaffleMonster]

I don't WANT direct-accessibility to internal network ranges, that's why NAT has always been a viable option because it prevents that and that's what I WANT to do anyway.

SPI is better in every way including being more secure than restricted cone NAT.

The fact is that the entire NAT thing is a diversion to make us think we have to do entire network overhauls and upgrades to make this new-fangled thing work. It's just not true. I will no more allow internal clients to send out on SMTP ports or allow external hosts to access, well anyway internal, over IPv6 than I would over IPv4. It's just a diversion.

Nobody is bothering to make a distinction between full and restricted cone. This is the real diversion.

People keep using the word 'NAT' like they do the word 'Cloud' like its going out of style without conveying necessary context to communicate exactly what it is their thinking.

I don't recall anyone seriously advocating you renumber your internal networks or enforce an access policy not to your liking.

And a nice diversion from those sites, like Slashdot, that posts an IPv6 article about once a month and NEVER, EVER, EVER accepts traffic or publishes IPv6 addresses for any of their services. Why? Because "it's so much work". If it's that much work, let's just work from w hat we have in the simplest possible way, eh?

Did you not get the memo? The world is running out of IPv4 addresses... we all can't have what works because their aint enough of it to go round.

As far as web sites finding it difficult to move to IPv6 thats absurd. They may have to wait for their ISP to catch up or spend time fixing internal software to store larger address fields but it aint the end of the world. When a third party can magically make any IPv4 site appear on the IPv6 network (http://slashdot.org.sixxs.org/) it is a load of crap to pile on with the lame excuse of it being too much work.

Because simple = secure, and that's just for starters.

A fully routed native IPv6 network is more simple than a duct taped IPv4 network with restricted cone NAT strung out everywhere.

Re:IPv6 is coming, but NAT will save the day

[bogd]

You can also access remotely by IPv6, and even access IPv6 websites from an internal IPv4 client that has no support for it.

How?

Troll

[fulldecent]

IPv4 is like a limited natural resource... a limited natural resource that you can divide up and each of the parts are pretty much as good as the original

Re:What about the big ones (e.g. verizon, AT&T

[jonwil]

Here in Australia, Internode is the only ISP offering full IPv6 to its customers.
Others (Telstra for one) are talking about it but have yet to actually make it available to customers.

Re:older modems / routers are a isses as well and

[jbolden]

Most older home routers don't handle. So what? Replace them.

Re: That's easy.

[LostMyBeaver]

There is still a cost on large ISPs. The holy land of carrier grade NAT would be to NAT the entire ISPs v4 network and route statics for customers who want their own addresses. Even with big iron (think ASR9k) the active translation table can be far beyond the scale of the hardware.

That said, a more conservative approach would use private IPs for the P routers and internal addresses for the PE routers. Then a VRF would provide a /30 between edges for private networking. Another VRF would carry static routes for customer subnets. Customers would be CGNATed at the PE from a single IP for multiple customers. This makes the router requirements larger at the provider edge but much easier to maintain. Then it would use 2-4 IP addresses (depending on use of /30 or /31 subnets) per PE router and completely free up the pool used for P routers. This means a national scale ISP like Comcast could probably function on a /16.

Re:older modems / routers are a isses as well and

[Anonymous Coward]

How cheap is the cheapest one? $7? You can get a Motorola 61XX for $80.

Re:That's easy.

[jbolden]

v6 doesn't allow for the complex routing tables of v4. Geolocation is going to be much better in theory. Privacy laws might mean that ISPs have to not sell this data though.

It's moving

[CAPSLOCK2000]

From what I've seen things have finally started moving. Obviously there are about three sides: the servers, the users and the backbone network between those networks.

Many hosting companies now offer IPv6 by default but most customers don't use it yet. Only very few consumers have IPv6 at home. Even fewer have IPv6 at there workplace. The only exception being a small number of universities and tech companies.
The graphs of my local internet exchange show that the daily peaks are around 9PM which supports the view that most IPv6 users are consumers.
Whenever a large party like Facebook or Youtube turns on IPv6 there is an immediate jump in traffic.

Over the last year the number of sites that offers IPv6 has grown significantly, double or even triple from only a few months ago.

IPv6 is growing on all bases and things are starting to come together.

Free Market....

[Pyrotech7]

One of the biggest hold ups to IPV6 implementation is those IP (tier 1 and above) companies that own IPV4 addresses. Now a salable commodity the IPV4 addresses are becoming more valuable as scarcity increases. The volume of IPv4 traffic makes it a more lucrative revenue stream. Implementing V6 will make those V4 addresses worthless, and so where is the incentive to change? Politics and people

give up on ipv6 already!

[someones]

it will never be adopted.
After ipv4 REALLY runs out (what still did NOT happen) IANA will recall unused ips - remember: you dont OWN but only lease an IP.
And after really really all ipv4s run out, there will be ipv8 allready out, that wont be that unreasonably bloat crap that ipv6 is.

(just my prediction - lets see in 5 years)

Re:That's easy.

[unixisc]

That is a problem. But if they have that issue, they should give /64 links to their customers, and leave the static/dynamic decision to them!

Different swarms

[tepples]

Hell even P2P networks will work as long as there's enough "active" hosts to talk to the passive ones.

It's not just enough "active" hosts (which I assume means hosts with permission to control their own port forwarding); it's also that these hosts have to be in the same swarm. Two machines downloading different files are in different swarms, and two different sessions of a multiplayer video game are in different swarms.

When we run out you'll probably have to pay a little to have a full IPv4 address to yourself, just like many now charge a little extra for a fixed IP

Go Daddy, for example, charges about $70 per year extra for a full IPv4 address, which is pretty much a requirement for HTTPS until Windows XP and Android 2.x are no longer in use. (The built-in SSL stack on those systems does not support Server Name Indication.)

Why isn't IPv6 deployed? Let's see...

[bogd]

I'm surprised nobody has posted this yet:

http://meetings.ripe.net/ripe-55/presentations/bush-ipv6-transition.pdf

It's a presentation I keep coming back to again and again (every single time somebody asks me "why don't people deploy more IPv6?").

Yes, the font and colors used will make your eyes water (I really wonder if he actually chose them that way on purpose :) ). But the actual content is just as accurate now as it was in 2007, and it comes from someone who actually has quite a bit of experience working with this stuff...

Re:older modems / routers are a isses as well and

[marcosdumay]

Around here the cheapest option costs about $40.

Re:It will take decades because nobody thought abo

[Dagger2]

I don't because I can't - Nothing I have supports IPv6 and until someone makes a router capable of NAT'ing between IPv6 and IPv4 I'm basically stuck.

Really?

Do you use Windows? Because that supports IPv6, since XP. If not, then maybe Linux? That supports IPv6, since 2.4. Or if not that, then maybe OSX, which supports IPv6 since... er, dunno, 10.something. Heck, the BSDs support IPv6, even though they've been dying for years.

I'm pretty sure you use stuff that supports IPv6.

Re:The neglected private internet space at 172.16/

[unixisc]

I think the more common issue is that since most corporate intranets are likely to use Class C private addresses, chances are that 2 totally separate entities may be using 192.168/16, and then 2 nodes on either end have the same addresses, making them much more of a pain to network.

What should be implemented, with less bloat

[Anonymous Coward]

IPxl

http://bill.herrin.us/network/ipxl.html

subnet distributions

[unixisc]

While ARIN may be pretty generous w/ doling them out (like they've been w/ IPv4), I believe that both APNIC and RIPE will give out a maximum of /56, and require a justification of one wants a /48. I think the protocol would have done well, or would do better, by having the entire top half of the address the global prefix, and split the lower half b/w the subnet and the interface ID.

Re:subnet distributions

[jbolden]

Nope. The maximum they give out to end uses is a /48, unless they meet rather complex criteria. (http://www.getipv6.info/index.php/IPv6_Addressing_Plans)

Here is the breakout:

3 bits = format prefix (right now always 001)
13 bits = TLA ID top level identifier
8 bits = RESV reserved expansion (this is where nasty routing stuff will end up in the future)
16 bits = NLA ID identifiers within carriers / ISPs
16 bits = subnet identifier
64 bits = interface identifier

Re:That's easy.

[Matt_R]

I'm guessing you use Internode? I used them when I lived in Sydney, theyr'e great.

And they've decided that everybody gets a static /56 now.

Re:That's easy.

[Matt_R]

I have a whole bunch of /64's in my /48. The problem is they keep changing every time pppoe reconnects.

Yesterday I had 2406:e000:e26c/48, today I have 2406:e000:e317::/48

Re:That's easy.

[unixisc]

Ah, but that seems to be the very nature of PPP - the IPs are dynamic and change every time. Looks like you'd have needed a static connection from your ISP.

Re:That's easy.

[petermgreen]

The ISP determines whether the prefix is allocated statically or dynamically, the end user determines whether the addresses within the prefix are allocated statically or dynamically. If the prefix is static then trackers can use it to track down to the premisis level regardless of whether the addresses within the prefix are static or dynamic. If the prefix is dynamic then it makes network administration a massive PITA.

Re:That's easy.

[petermgreen]

It's perfectly possible to run a PPP server with static mappings from logins to addresses (of course this means you can only have one client at a time per set of login details but that isn't usually too much of a problem).

Re: That's easy.

[petermgreen]

The holy land of carrier grade NAT would be to NAT the entire ISPs v4 network and route statics for customers who want their own addresses.

That sounds like a bad idea from multiple perspectives, first there is the issue of finding hardware capable of doing it (or finding load balancing hardware). Secondly it means that if routing in the ISP network chooses a different exit point then a different NAT will be used which will break existing sessions. Thirdly if the ISP provides hosting or premium connections with public IPs and a private IP user connects to them then it may not get natted which may cause problems. Fourthly having routing to multiple NATs will break many nat traversal techniques.

If NAT has to happen (and for some ISPs NAT or a similar IP sharing system WILL have to happen) it's much better if it happens near the edge where there is only really a single route. If the ISPs management systems want to see the private addresses then that can easilly be arranged which keeping the NATs near the edge by adding an exception to the NAT rule.

This means a national scale ISP like Comcast could probably function on a /16.

Comcasts problem is they want to keep a flat network for managing their devices and there simply aren't enough private v4 IPs to do that. That is why they are working to move as much as possible to IPv6.

Re:That's easy.

[petermgreen]

BS

There was a load of talk about hierarchical routing when IPv6 was being developed but what we actualy ended up with was much the same as we have with IPv4, autonomous systems advertise prefixes over BGP which combine to produce a massive routing table. The table will have less cruft than the IPv4 one both because it's newer (The IPv4 table contains a lot of cruft like legacy allocations where an equivilent allocation wouldn't be PI under current rules, multiple seperate allocations for companies whose IP space needs have grown and so-on) and because IPv6 gives the RIRs room to make allocations sparsely allowing them to extend existing allocations rather than making new ones but that isn't really relavent here..

As with IPv4 autonomous systems are able to route things as they wish within their own networks and as with IPv4 some autonomous systems span multiple continents and as with IPv4 some users traffic may pass for considerable distances over non-ip networks (or tunneled over a non-internet ip network) before entering the providers "general routing" (for example most smaller ISPs in the UK have only on PoP).

Further allocation procedures may make geolocation worse for IPv6 than IPv4. IIRC the default allocation to an ISP is a /32 so if the ISP only gives out a /56 or smaller by default they will probably never need to get any more IPs (how many ISPs really have more than 16 million customers) which means they won't need to worry too much about keeping the RIR happy. I know when I get an IP from freenet6's dutch gateway the geoipv6 database lists it as being in canada.

Re:That's easy.

[jbolden]

I would assume for geolocation regardless of what the ISP does the /64s will be cleanly marked. Unless of routing is insane the IP addresses are going to follow something like a physical infrastructure. Right now no one is bothering to geolocate IPv6 addresses since their isn't much B2C.

\As for the non table routing, maybe I am wrong on that one. Other people are saying the same.

This is horrible

[Anonymous Coward]

Sorry for the late reponse but I think we are used to those since IPv6... We stand nowhere with IPv6 adoption. It is still like it was at the start of this century. I will write this as a "tag" to those reading this message 20 years later: If there is a way to NAT IPv4 addresses then that is used. IPv6 will be used only if no other way to solve the IPv4 address exhaustion.

Have have had IPv6 solutions in software/hardware a long time already but nobody is interested. And it might well be that the SW/HW solutions have bugs that will pop up if we start to use those. It is still mostly untested technology, however. And the worst is we THINK we have SW/HW solutions which are now bitrotting. Bitrotting to the point when IPv8 will be released. Nice...

Re:That's easy.

[Matt_R]

I have a static IPv4, they just can't yet offer static v6