You missed Windows XP (requires a one time initialisation step).
Now that home router vendors are shipping IPv6 routers it is becoming much easier. These will come down in price to match the IPv4 only boxes soon so the only impediment to switching on IPv6 will be your ISP dragging their feet.
I've been running dual stacked for 8+ years now. I don't see any hassles. If the device I want to connect to has a IPv6 address then I connect over IPv6. If it has a IPv4 address I connect over IPv4. My router handles both address types. My old IPv4 only Netgear router happily acts as a access point and passes both IPv4 and IPv6 packets.
The benefits of running dual stack is that you don't need use NAT64/DNS64 or similar transition technology to get to IPv4 only servers or have to suffer the additional breakages that occur over running straight NAT. IPv4 and IPv6 are ships in the night at the moment and I'll try to keep them as such as long as possible. If/when my ISP makes my connection IPv6 only I'll use DS-Lite or similar as the home net will most probably be dual stack for another decade unless vendors make available firmware upgrades to the existing equipment in the house.
He.net works with dynamic connections, just update the tunnel configuration using
ifconfig gif0 create >/dev/null 2>&1
ifconfig gif0 tunnel $new_ip_address 128.66.128.82
ifconfig gif0 up
ifconfig gif0 inet6 2001:DB8:1F00:FFFF::5A1 2001:DB8:1F00:FFFF::5A0 prefixlen 128
route add -inet6 default 2001:DB8:1F00:FFFF::5A0
# md5 hash of password
pass=XXXXXXXXXXXXXXXXXXXXXXXXX
# user id from main page
user_id=YYYYYYYYYYYYYYYYYYYYYYYYYY
# global tunnel id.
tunnel_id=9999999
args="ipv4b=$new_ip_address&pass=$pass&user_id=$user_id&tunnel_id=$tunnel_id"
tunnel=`/usr/bin/fetch -q -o - "https://ipv4.tunnelbroker.net/ipv4_end.php?$args"`
$LOGGER "IPv6 TUNNEL $tunnel"
No. Commercial parallel importing of a feature film (over 20 minutes) is still illegal to Australia. Private importing of a feature film is not illegal.
Books not published in Australia within 30 days of being published anywhere else in the world can be commercially parallel imported. Private importing of a book is not illegal.
http://www.ag.gov.au/Copyright/Pages/Wheniscopyrightinfringed.aspx
Or they can just throttle you when you exceed your monthly allowance. There are ISP's in the world that do this today.
Unless you sell exactly *one* item at a time you can't game this. Sell 1 coffee it's
There are many different scenarios that can be called "IPv6-only". Each of them has different impacts and potential issues.
You have the WAN link running IPv6-only.
You have the local link running IPv6-only.
You have the node running IPv6-only.
You can also be running with or without IPv6 to IPv4 translation, e.g. NAT64/DNS64. With or without IPv4 encapsulation. e.g. DS-Lite. With or without IPv4 link-local being up. With or without a IPv4 loopback interface. With or without a IPv4 capable stack.
Users and vendors need to test in all these different scenarios as each one is likely to expose different bugs or limitations that need to be addressed.
I'm going to jump all over you here. Sorry.
IPv6 is infinitely more complex than v4. Sorry. You just don't know what you're talking about when you say that it's simpler or equivalent. You're looking at it from a jaded perspective. No user will ever understand this heap of dynamic configuration. They won't be able to troubleshoot it. They'll resist switching to it, kicking and screaming all the way.
The basic trouble shooting tools are identical between IPv4 and IPv6. ping, traceroute.
Why? Well, go back to why IPv4 won out in the first place. The use of TCP/IP version 4 on the network even back in the 90s was not a given. You could run IPX or AppleTalk amongst other protocols over a wide area network. True, they sucked. I spent a few weeks at a major telco's headquarters trying to tune AppleTalk to run over a WAN. It wasn't pretty - these protocols were made for LAN use and required constant handshaking and ACKs that were relatively painless on a LAN but destroyed performance over DS-3 class WAN links. Still, it could have been done, given time and effort and coding resources. There were ways to apply the lessons of IP to these protocols.
You still running UDP/TCP/ICMP etc. above IPv6. All of these are still designed for WAN use.
Instead, everyone put the effort into writing TCP/IP stacks - or taking them from BSD, really. The reason wasn't technical superiority. The reason was that the protocol was fully intelligible to those who were working with it, given a bit of study. In comparison, the other protocols of the time were dynamically configured and hid most elements of addressing from the end user. TCP/IP was written to be simple and straightforward. The others weren't, they had different design goals - dynamic configuration aka usability by complete morons being one of them, particularly in the case of AppleTalk. IPX was no slouch in this department, though. I seem to remember pretty much the only choice in addressing required was the IPX internal network number on a Netware 2 or 3.x box.
Once people saw how easy IP was to set up, they wanted it, and the OS vendors (Apple and Microsoft, mostly) chose to embrace it rather than provide an opening for someone else.
With IPv6, the authors have pretty much come full circle. It's an almost totally dynamic protocol from the perspective of the end user. It's like someone took one of the dynamic LAN protocols of yore and made it work well in the WAN sphere. You think this is good. I think this is bad. The barrier to understanding how it works is much higher than with v4. It has duplicated functionality, a sure sign of design by dysfunctional committee. No one wants it except geeks.
IPv6 can be as dynamic or as static as you want.
The bottom line is that I see this conversion ending up like the DTV fiasco that has just concluded. It took the better part of 20 years to do that conversion.
And those boxes will need to be able to talk to IPv6 only servers elsewhere in the world and no there isn't good technology for IPv4 to IPv6 initiated connections.
Bringing up IPv6 in parallel to IPv4 will allow all those home/business machines to reach these IPv6 only servers. It's only a matter of time before such scenarios become common and not test as that are today.
Well, I don't want no stupid NAT - anywhere. I can ssh to my home machine and my work machine from anywhere in the world. No NAT at work, and portforwarding at home. I'd like to ssh to every machine at home though - without paying for more addresses. I'd like to ssh into my smartphone too (so I can turn on the gps and find out where I put it.) But that isn't even offered today. IPv6 will make all of this easy. Enough addresses, nothing to pay extra for. Except the transition.
I, too, would like to ssh into your machines at home and your smartphone.
There is no security difference between "port forwarded" ssh and "directly reachable" ssh. Just because the owner of the equipment can get it doesn't mean that others can get it.
Not to mention every single business that I've ever dealt with has some sort of proprietary in-house software for one need or another. If it's a networked application then it's running on IPv4 no doubt.
If the application developer has been worth the money you have been paying them then the in-house software should be IP version agnostic. Additionally, even if it is IPv4 only, there is no reason not to bring up IPv6 in parallel. It will then allow you to test updated versions of the in-house applications to ensure that are IP version agnostic.
Enabling IPv6 on the network has NO effect on IPv4 only equipment.
For a network administrator IPv6 is simpler that IPv4 to run. No more calculating subnet masks. No more trying to guess how many addresses you
need to assign to a subnet that needs to be externally addressable. No more having to match up internal / external addresses when debugging. No more having to configure port forwarding.
There are a few new things with IPv6, like prefix delegation, but in reality they are no more difficult than what you have been doing with IPv4 for the last decade.
At the wire level IPv4 and IPv6 are equally complicated.
For the application developer they are equally complicated.
For the home user there is basically no difference. Just make sure that the router you buy is IPv6 capable. They exist now. When you next replace your router make sure you get one that is IPv6 capable and don't forget to re-flash it when you get home. Like any other computer they need to be updated regularly. When your ISP supports IPv6, the router will get a address block from the ISP, using prefix delegation (PD) and use that prefix to give your internal machines
a second IPv6 address which it will use to talk to the world.
RFC 3007, was standardised in 2000 as a method of securing updates.
Support of RFC 2137+3007 is built into Mac OS (System Preferences -> Sharing -> Edit -> Use Dynamic Global Hostname).
For Linux, *BSD add a call to nsupdate from dhclient-exit-hooks.
if test -n "$new_ip_address"
then
nsupdate -y key:secret
update delete hostname A
update add hostname 300 A $new_ip_address
send
EOF
fi
It just will not happen. Many embedded devices build today don't even enable the IPv6 stack while it's only a configurable option away in the Linux kernel. And these devices aren't even released yet. They will after release run for a decade in the infrastructure. Sure we tell people who make them to care. Yet mostly they have more important things to care about, as for example to get them working in the first place.
An extra screen in the config box to set a static IPv6 address on an embedded device? Not seen one yet... Why? Because these embedded boxes are typically run in a seperate VLAN in the company.
For some reason you seem to think turning on IPv6 precludes running IPv4 devices or being able to reach them from IPv6. IPv6 only internal networks are still a long way away.
Corporate requirements for IPv6 are close to nonexistent, so nobody cares, nor will.
It's not that I'm against IPv6, but one has to be realistic about what to expect from the rest of the world - and a drastic change without a game-changing urgent need is not one of these things.
Lots of corporate desktops talk to machines on the outside. These machines will be a mixture of IPv4 only, IPv6 only and dual stack. The need to talk to these machines alone will result in IPv6 being deployed internally. We are starting to see ISP complaining that they can't get enough IPv4 addresses to meet their needs. It won't be long before the first forced IPv6 only sites start appearing. When that happens, offices will start to adapt by enabling IPv6 to allow the desktop machines to reach these sites.
And I'm still waiting for an example of any organization _ANY_ organization who needs to have in the order of 16 million directly communicating devices on their private network. Just a million will do as well.
Probably Google is the only organization which comes close to that order.
Pick any large ISP that manages CPE equipment. These needs to be addressed.
And even for them, there is not really an important reason why their infrastructure could not be split up between the google search cloud as one 10.x.x.x range and the gmail infrastructure as another one, for example, as direct communication between the two is probably unnecessary and managed by separate teams anyway.
Multiple routing realms are additional operational complexity. Given the choice of "deploy IPv6" or "run multiple routing realms" I'm sure many companies will pick run IPv6.
One could argue that the 'renumbering' is difficult. Yet the cluster which Google build handles server failover, swap-in and swap-out and data partitioning as one of the major features. Fail to see why they couldn't implement it on the 'private IPv4'-level either...
While I agree that on their scale, such an experiment might be valid, my guess is that it will remain as such;... an experiment with a lot of problems:
1) increased latency because of IPv6 tunneling - and Google is very latency conscious
2) less proven technology leading to exotic problems which show up even more at the Google scale - because nobody uses it
Tunnels will go away and be replaced by native connections. This is a observable trend today.
The amount of IPv6 traffic world wide is growing rapidly. The bugs in equipment will be worked out.
And for what?
To solve the 'we are too lazy to write a stupid IPv4 pool re-numbering/re-partitioning'-problem? While it can be done with a very small shell script(TM)?
There are lots of reasons to deploy IPv6. We are at a tipping point where staying with IPv4 will start to get more and more expensive. IPv6 will be seen as the cheeper alternative.
Have you actually been in a company that has deployed IPv6 internally and externally? I have.
Have you run a dual stack network? I have.
Have you dealt with the issues involved in moving from IPv4 only to IPv4 + IPv6? I have.
Have you dealt with the issues of run numbering networks? I have.
I will tell you this. I would much rather deal with the minor issues of bring up IPv6, than to repeatedly have to deal with the issues of renumbering. At least with IPv6, once you fix the problem it stays fixed.
The problems people are seeing with IPv6 are mainly lack of planning issues. Failures to build in IPv6 initially despite it being the only viable solution to address exhaustion. Failures to make IPv6 support a requirement. We are playing catchup at the moment, trying to cram what should have been 10 years of incremental development into 1 or 2 years.
For most applications that deal with IP addresses or sockets they cost to support IPv4 and IPv6 is actually minimal or zero when the application is being developed.
Most machines actually support IPv6. There are a few, memory limited, machines that can't but overall they are in the minority and are also relatively inexpensive machines to replace.
I would actually recommend that every company bring up IPv6 at the network level today and connect to the global IPv6 with a firewall that only allows reply traffic in initially. Don't add AAAA records for your servers initially. Do add them for your workstations. Add corresponding PTR records. You will find that IPv6 isn't as scary as you think it is. It also gives you a environment where you can test your servers, by adding AAAA records to the host file of the machines involved in the test. When the service is working you then add the AAAA records to the DNS and remove them from the host files. Don't forget to open up the firewall to allow external connections to the service if appropriate.
As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata"
