If you are a ISP you don't talk to IANA and as a ISP you will continue to need the IPv4 addresses for quite a few years more so why would you want to give them back?
As for paying more to give each customer a/48 you would pay 8.1 times more in the APNIC region. If you choose to give your customers a/56 you would pay $0 more in the APNIC region. Most residential ISP's are looking to hand out/56's or/60's. When you look at it on a per customer basis with a million customers you have: IPv4: 1180*1.3^(20-8) = 27376.0 AUD (2c/customer) IPv6: 1180*1.3^(28-8) = 224200.0 AUD (21c/customer)
If you are not happy with the pricing model you can lobby to have it changed.
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.
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.
Unless you sell exactly *one* item at a time you can't game this. Sell 1 coffee it's.99 (-> 1.00), 2 it's 1.98 (-> 2.00), 3 it's 2.97 (-> 2.95), 4 it's 3.96 (-> 3.95) as you do the rounding on the final balance.
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.
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.
Do you have any idea how expensive it is to continually re-size networks just so you can fit all your machines into a allocation that is in reality too small for your company? The fact that you say:
Bad subnet planning; yes!
means you just don't understand. One really shouldn't have to think about subnet sizes. That is one of the advantages of IPv6. You don't have to think about subnet sizes. You just subnet at the/64 and you have a subnet big enough for any conceivable use. No more juggling, No more getting it "wrong". No more renumbering because you need more space.
Actually the article is telling you that you need to start to move to IPv6 today. Turning on IPv6 at the network layer is trivial. If you want all your application to work with IPv4 and IPv6 then you need to invest the effort to test and possibly fix them. With a large company with lots of non standard applications and tools this takes time. Remember you don't have to have everything working to begin with. You can bring services up one at a time.
While you may not believe it, there are companies with over 17 million devices that need to be connected and directly addressed. Once you get up to those numbers RFC 1918 no longer is big enough to address all the machines (RFC 1918 covers 17891328 addresses). Add to that the need for rational sub netting and you can start to run out of address with less that a million machines.
What this means is that even if ISPs were incredibly wasteful and basically trashed 99.9% of the address space due to bad practices, you'd still have millions of addresses for every person in the world.
And yet, according to the Comcast announcement, if you are paying for just one device, you get just one IPv6 address. They call it "directly connected CPE". Yes, on my home network, I have one directly connected device -- the NAT router.
But you have lots on indirectly connected equipment. This stage if for customers that only have directly connected CPE equipment.
The next stage is for those that have routers as their CPE equipment. The routers, after getting themselves a IPv6 address, will request a prefix (using DHCPv6) and Comcast's DHCPv6 servers will return a/64 prefix for use on the internal network. The router will then configure itself to send router announcements (RA) to the internal network with this prefix. Your internal machine will see these RAs and given themselves a IPv6 address (using SLAAC) and point the default IPv6 route to the router. Alternatively you will configure your router to use stateful DHCPv6 internally for address assignment , the router will send RA with the M bit set to 1, and your machines will then talk DHCPv6 to the router to get a address similar to IPv4.
At this stage you internal machines will have both a IPv4 address and a IPv6 address. The IPv4 address will be a RFC 1918 address. The IPv6 address is a globally unique address. When you talk to a machine over IPv4 you will use the IPv4 address. When you talk to a IPv6 machine you will use the IPv6 address. By default, if the machine you are trying to talk to has both IPv4 and IPv6 address you will attempt to use IPv6 then, if that fails, IPv4.
I'm also confused by their statement that the device must understand "stateful DHCP6". Why?
Because Comcast is not supporting SLAAC for address assignment to CPEs. They are doing managed address assignment.
The cable modem gets assigned one IPv6 address on the cable side
This is a management address for the modem. It has nothing to do with addresses assigned to customers
, and it serves one IPvX address via DHCP to the CPE. What changes? Why not make the cable modem the IPv6 to IPv4 gate and simply use good old DHCP on the CPE side?
This change does not remove IPv4. It just adds IPv6. At some point in the future Comcast will stop handing out IPv4 address to customers and you will need to use something like DS-Lite or DNS64/NAT64 to reach IPv4 machines but this is still a while off. All Comcast is trying to do at the moment is to bring up IPv6 in parallel to IPv4.
Just configure your Linux box to use DHCPv6. There are DHCPv6 clients out there. They do run on Linux and *BSD. Comcast are using bog stand protocols. This is no different than when ISP's said "We only support Windows". You would plug your Linux / *BSD box in and it would work.
Windows XP has dual stack support. You just need to enable it. There are a couple caveats, like it needs access to a IPv4 recursive nameserver as it doesn't make DNS queries over IPv6, but for the most part it "just works".
Actually they are only illegal in host names and mail domains. The DNS doesn't have a problem with underscores. The reason COM banned underscores was to prevent the complaints about about them not working for some clients which actually enforce the host name and mail domain rules. That was the argument I presented to them when COM solicited my opinion before they instituted the ban on hyphens.
Gerber-xxx.com is also perfectly legal as a host name or mail domain. I've never understood the desire to use underscores when hyphens work perfectly fine as in label separators.
Slashdot Mirror
If you are a ISP you don't talk to IANA and as a ISP you will continue to need the IPv4 addresses for quite a few years more so why would you want to give them back?
As for paying more to give each customer a /48 you would pay 8.1 times more in the APNIC region. If you choose to give your customers a /56 you would pay $0 more in the APNIC region. Most residential ISP's are looking to hand out /56's or /60's. When you look at it on a per customer basis with a million customers you have:
IPv4: 1180*1.3^(20-8) = 27376.0 AUD (2c/customer)
IPv6: 1180*1.3^(28-8) = 224200.0 AUD (21c/customer)
If you are not happy with the pricing model you can lobby to have it changed.
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 /etc/dhclient-exit-hooks. The following is a FreeBSD example.
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 .99 (-> 1.00), 2 it's 1.98 (-> 2.00), 3 it's 2.97 (-> 2.95), 4 it's 3.96 (-> 3.95) as you do the rounding on the final balance.
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.
Do you have any idea how expensive it is to continually re-size networks just so you can fit all your machines into a allocation that is in reality too small for your company? The fact that you say:
Bad subnet planning; yes!
means you just don't understand. One really shouldn't have to think about subnet sizes. That is one of the advantages of IPv6. You don't have to think about subnet sizes. You just subnet at the /64 and you have a subnet big enough for any conceivable use. No more juggling, No more getting it "wrong". No more renumbering because you need more space.
You may not believe it, but it part of my day job to support such companies.
Actually the article is telling you that you need to start to move to IPv6 today. Turning on IPv6 at the network layer is trivial. If you want all your application to work with IPv4 and IPv6 then you need to invest the effort to test and possibly fix them. With a large company with lots of non standard applications and tools this takes time. Remember you don't have to have everything working to begin with. You can bring services up one at a time.
While you may not believe it, there are companies with over 17 million devices that need to be connected and directly addressed. Once you get up to those numbers RFC 1918 no longer is big enough to address all the machines (RFC 1918 covers 17891328 addresses). Add to that the need for rational sub netting and you can start to run out of address with less that a million machines.
and "ipv6 install" in really early versions of XP.
You can install from the command line using "netsh interface ipv6 install".
What this means is that even if ISPs were incredibly wasteful and basically trashed 99.9% of the address space due to bad practices, you'd still have millions of addresses for every person in the world.
And yet, according to the Comcast announcement, if you are paying for just one device, you get just one IPv6 address. They call it "directly connected CPE". Yes, on my home network, I have one directly connected device -- the NAT router.
But you have lots on indirectly connected equipment. This stage if for customers that only have directly connected CPE equipment.
The next stage is for those that have routers as their CPE equipment. The routers, after getting themselves a IPv6 address, will request a prefix (using DHCPv6) and Comcast's DHCPv6 servers will return a /64 prefix for use on the internal network. The router will then configure itself to send router announcements (RA) to the internal network with this prefix. Your internal machine will see these RAs and given themselves a IPv6 address (using SLAAC) and point the default IPv6 route to the router. Alternatively you will configure your router to use stateful DHCPv6 internally for address assignment , the router will send RA with the M bit set to 1, and your machines will then talk DHCPv6 to the router to get a address similar to IPv4.
At this stage you internal machines will have both a IPv4 address and a IPv6 address. The IPv4 address will be a RFC 1918 address. The IPv6 address is a globally unique address. When you talk to a machine over IPv4 you will use the IPv4 address. When you talk to a IPv6 machine you will use the IPv6 address. By default, if the machine you are trying to talk to has both IPv4 and IPv6 address you will attempt to use IPv6 then, if that fails, IPv4.
I'm also confused by their statement that the device must understand "stateful DHCP6". Why?
Because Comcast is not supporting SLAAC for address assignment to CPEs. They are doing managed address assignment.
The cable modem gets assigned one IPv6 address on the cable side
This is a management address for the modem. It has nothing to do with addresses assigned to customers
, and it serves one IPvX address via DHCP to the CPE. What changes? Why not make the cable modem the IPv6 to IPv4 gate and simply use good old DHCP on the CPE side?
This change does not remove IPv4. It just adds IPv6. At some point in the future Comcast will stop handing out IPv4 address to customers
and you will need to use something like DS-Lite or DNS64/NAT64 to reach IPv4 machines but this is still a while off. All Comcast is trying to do at the moment is to bring up IPv6 in parallel to IPv4.
Just configure your Linux box to use DHCPv6. There are DHCPv6 clients out there. They do run on Linux and *BSD. Comcast are using bog stand protocols. This is no different than when ISP's said "We only support Windows". You would plug your Linux / *BSD box in and it would work.
Windows XP has dual stack support. You just need to enable it. There are a couple caveats, like it needs access to a IPv4 recursive nameserver as it doesn't make DNS queries over IPv6, but for the most part it "just works".
Actually they are only illegal in host names and mail domains. The DNS doesn't have a problem with underscores. The reason COM banned underscores was to prevent the complaints about about them not working for some clients which actually enforce the host name and mail domain rules. That was the argument I presented to them when COM solicited my opinion before they instituted the ban on hyphens.
Gerber-xxx.com is also perfectly legal as a host name or mail domain. I've never understood the desire to use underscores when hyphens work perfectly fine as in label separators.