What's Your Timeline for IPv6 Migration?
SgtChaireBourne asks: "IPv4 has, over the last 20 years, seen unexpectedly wide adoption. During this time it's proven to be both flexible and robust, but also several problems, though once small, have grown. IPv6 looks to solve some scalability problems, add needed privacy and authentication mechanisms, address quality of service, and provide better routing and addressing capabilities. What kind of timeline does your site/institution/business have for rolling out IPv6 and how?" Those interested in IPv6 migration may also be interested in this article, from a year ago.
Here are some helpful links:
IPv4 Policies
IPv6 Policies
IPv6 is also available for Win2k, which doesn't make it such an unbelievable proposition... anyone running anything less than Win2k (that is, if they're running Windows) has to be out of their mind. (That or tied to old hardware and OSes by shitty software)
using namespace slashdot;
troll::post();
The best reason for IPv6 wasn't even mentioned in the blurb. Multicasting is like Bittorrent on steroids. I don't know how all of the money for the bandwidth changes hands, but imagine being able to download the latest iso for your favorite linux distro, the first hour it is available. Better yet, imagine being able to host that iso from your own whimpy machine. Better still, imagine a world free from the dreaded slashdot effect.
you can use ipv6 with win2k if you install an ipv6 stack. Check this link for more info: http://msdn.microsoft.com/downloads/sdks/platform/ tpipv6.asp
[shameless plug]
We provide IPv6 ready testing tools for L2 through L7 testing that are seeing great interest and buyers in the market.
[/shameless plug]
Judging from the response we're seeing, IPv6 is quickly being implemented by the network equipment manufacutrers (NEMs) - though the rollout at ISPs and businesses is probably not as fast as one would hope due to the general market conditions and lack of rollout pressure due to IPv4 addresses still being available.
One way they can switch without significant down time is to roll out the changes over time. Essentially they have two options: Dual stack: routers that support both IPv4 and IPv6. The routers speak v4 to v4 routers, and v6 to other routers. Encapsulation: routers can encapsulate IPv6 packets in IPv4 packets and then tunnel the encapsulated packet to other IPv6 routers via IPv4 routers.
A large number of providers offer IPv6 support today. NTT/Verio has been offering this as a Commercial Service for quite some time, as well as through the domestic provider OCN and the OCN DSL services. As the 6bone tunneled networks go away, there is ongoing native support being added to networks. IETF and other conferences have been supporting providers that offer native IPv6 services. Aside from the always behind the ball DSL/Cable providers in the edge provider space of multicast, IPv6, etc.. you can contact any of the Tier-1 networks to obtain IPv6 services. Likely for free and not out of the 3FFE space. Build IPv6 into your kernels, ask your service providers for IPv6 and encourage them to provide these to you for little/no additional cost. Juniper and Cisco routers currently offer IPv6 in their current software releases. Now that Cisco has acquired Linksys, hopefully they will assist in providing support for these services in the edge-router space.
IPv6 is also available for Win2k, which doesn't make it such an unbelievable proposition...
Except that the IPv6 stack from Microsoft for Win2k can't query IPv6-only DNS servers. It understands AAAA records, but you still need your DNS server accessible over IPv4 in order to actually query them...
What does NAT give you that a regular firewall would not?
Just because IPv6 means computers on a LAN have public IP addresses does not mean there is no control over the data that is sent/received to/from them. What data is transferred and how quickly it is transferred is controlled by using a decent firewall / traffic shaping solution (e.g. a linux box running iptables / shaper).
Stupid admins these days seem to think that NAT is good for security / traffic shaping / whatever else - it's not - it just causes problems with many apps and is a kludge required because of the lack of IPv4 address space.
The sooner IPv6 adoption gets more widespread, and people begin to realise losing NAT is a good thing, the better.
The major operating systems out there are now deployable with IPv6 support. The major infrastructure vendors (Cisco and the like) are ready. The big limitation as I see it right now is software. More network-aware software needs to be address family agnostic.
The path forward for software developers is fairly straightforward:
Making software address-family agile should not impact your IPv4 users at all. Why not do it the right way now so you don't have to re-do it later?
It is coming.
I'm mostly there. My network and systems are all dual IPv4 and IPv6. The problem I've been running up against is that there are no DSL or small-office/home-office-type providers in my area that support IPv6! Most of the people I speak to at my current ISP (SBC) don't even know what it is (had to call them, my 4 or 5 e-mails about it have all gone totally unanswered), and finally when I get ahold of someone in the "emerging products" group, they say they have no idea if/when it will ever be available. I can't even sign up to help test it.
So for now I'm stuck working through a tunnel broker with terrible latency. Basically, I'm still doing everything with IPv4 that's not on the LAN.
Microsoft is well ahead there. They have been doing IPv6 stuff for years. Of course you still can't do anything with it and there is no DNS support and nobody seems to have a transition plan worth a damn, but you cannot blame Microsoft.
The real blame for IPv6, DNSSEC and IPSEC being nowhere is the IETF. And before ACs come back telling me that IPSEC is widely used for VPNs, yes I know, but a VPN is not what IPSEC is designed for. IPSEC was intended to be INTERNET security.
Rough Consensus and running code may have been fine when the IETF bigwigs were in their 20s and 30s. These days they are in their 50s and 60s and it really shows. The place has been a talking shop for has beens for years.
What is interesting is the number of folk who are NOT involved with IETF anymore. I have not seen Vint Cerf there for years, nor David Clark or Ron Rivest. Tim Berners-Lee has not been there for at least eight years and it is four years since I saw any W3C staff there. The hip venue these days is OASIS, you can get a spec finished in less than 2 years in OASIS - and when it is done it does not look like some shite that came off a teletype.
The folk in charge at the IETF these days are the second stringers, not the visionaries. They simply do not have what it takes to deploy IPv6 and they are scared of making a bad choice so they make no choices at all which is usually the worst choice.
The only major companies still involved in IETF in a big way are CISCO and Microsoft. And Microsoft is only there because they feel they need the cover. There are some Sun engineers still attending, but that seems to be as much as anything to keep their visibility up and their resume looking fresh.
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Sun had had it since at least Solaris 8 including IPv4 over IPv6 tunnels and vice-versa.
Even mid-sized to fairly large organizations can get away with a surprisingly small number of IPs for those servers/services which just HAVE to be Internet visible.
Considering that most broadband ISP user agreements forbid servers of any kind, most non-commercial users don't actually need their own Internet-routable IP address either... unless they run some kind of p2p app (which would be forbidden by half the ISPs anyhow.)
Nope, Try ::1
What about RFC 1886?
BIND can support AAAA records, it is a matter of wider adoption, but there certainly is support. I once wrote a zone file editor that included plenty of support for v6.
You're right, I can't imagine how dynamic length addressing would be implemented.
:) 128 bit addresses will last until either we expand into space, or individual parts on a chip get their own global addresses!
Besides, you will have a hard time fitting around 1000 microwave oven bells or light switches in 1 sq meter, which is what IPv6 provides
There are evident, unsolved, pragmatic problems with native IP multicast. For instance, there is no proven, support inter-domain multicast routing system, and thus no way for multicast groups to sync up between different ISPs.
There are application-layer problems with multicast. For instance, nobody has come up with a reliability scheme with a service model other than "streaming video" or "big fucking file transfer" (as opposed to, say, web page download).
But even if you believe that problems like these are close to being solved, there is a fundamental, intensely painful scaleability problem with global native IP multicast: rather than asking the Internet backbone to route entities that represent hosts (a hard enough problem), native multicast demands that the backbone route entities that effectively represent pieces of content. As in, web pages.
Most of the benefits of multicast will come from overlay systems, both centralized (like the one Akamai built) and decentralized (like peer-to-peer file sharing networks). There's no evidence that the problems Deering-model multicast aims to solve can't be solved more easily at a higher layer.
It's just another example of the end to end principle in action.
- Lack of authentication. Joe Blow from down the road can claim to be Bill Gates, and the mail system won't know any different.
- Lack of robustness. It is still completely possible for an email to be sent, vanish into the ether, and never be seen again. No bounce, nothing. (Yes, it's possible to set mail systems up to do this deliberately -- but it can happen even without deliberate configuration.)
- Poor handling of eight bit data in some cases. Base 64 encoding should not be necessary, but too many sites barf (or mangle data) without it.
That's off the top of my head. There may be (probably are) more. SMTP was designed in a time when the network was trusted -- everybody on the network would Do The Right Thing(tm). You can't tell me that that's still the case nowadays.Ever heard of MSDP? Not perfect, but there's plenty of work going on here.
Who ever said that it needed to support something other than real-time (read audio/video)?
There are some real life applications in use today that a couple of large cable operators use to redistribute things like VoD content to multiple sites.
The Nasdaq uses mcast on the trading floor for live video, and also to remote sites.
While it's largely an enterprise type application, there are some areas where ISP's can benefit from it especially as we start to see more and more streaming applications.
You have to just jump in! I too am already using IPv6 comfortably alongside my routed IPv4 network. I actually forced myself to start using it just 'cause, and it's wonderful. The autoconfiguration features are worth it alone. And I have a mixed network of Linux, AIX, HP-UX, Windows 2000, and Cisco. My bind/DNS is configured for IPv6, my sendmail is configured for IPv6, and so on. But the underlying IPv4 network is still there right along side. There's really no reason to not go ahead and start experimenting with IPv6, to get comfortable with it before you depend on it.
Actually my excuse to start playing with it was I was developing an application which could make use of multicasting. And let me tell you, IPv6 multicasting is a dream come true when compared with IPv4! And the sockets-API is much more sane and complete, after all the IETF learned from the shortcomings of the IPv4 API. See these wonderful resources and just jump in!
So now that I'm enjoying it, I've been seeking out open source applications that use IPv4 and providing assistance to the developers to get them compatible with IPv6. A lot of the smaller projects in particular could use help, as some of them are unnecessarily tied to the IPv4 stack and probably don't even know it nor know anything about IPv6. I also suggest that anybody with some expertise to lend a hand as well. The open source/free software community can not find itself falling being here.
I've IPv6 enabled on all my machines, my upstream provider offers IPv6, and most of my former clients have IPv6 rolled out internally. It doesn't buy much for the moment, but I've noticed a large surge in interest over the last year in the techie community to learn all they can about IPv6. I know one guy who is staking his whole future on being the IPv6 guru.
Having been at several RIPE meetings and national Net Operator Group meetings, the biggest problem is getting peering and transit connections negotiated. IPv6 requires many things which were optional in IPv4, like multicast support end-to-end. Many of the clued ISPs and carriers in Europe now have IPv6 internally, and offer it to their clients. Larger ISPs are naturally lagging behind, because the techies have no voice in the business operations of big telcos, and the suits haven't heard enough to start asking their customers if they want it.
There was a chicken and egg problem, where ISPs weren't asking their customers about wanting IPv6, and customers not implementing it because it wasn't offered by IPSs. This has changed quite a bit in the last year, for two reasons. Big telcos rolling out 2.5G/3G mobile phone systems are using IPv6 internally, and smaller ISPs are looking for an edge in these lean times. My upstream ISP made a few announcements on internal mailing lists about offering IPv6 over IPv4 tunnels for testing purposes, and was overwhelmed by the response. They now have a few dedicated cisco routers, and allow a full IPv6 login without needing tunnels. The last I heard, almost 20% of their customers have taken up IPv6, mostly the businesses with clued techies and home experimenters. Other ISPs are now looking to roll out IPv6 soon, but the biggest problem is hammering out the peering/transit issues, not in the offer to customers.
The other delay is waiting for the IPv6 working groups at RIPE to get the registry database objects well defined and implemented, and a few other technical services like route servers and DNSSEC implemented. But the work is ongoing and will take a while until the backend issues get ironed out.
My bet is that, at least in Europe, there will be some mainstream buzz about IPv6 starting in 12 to 18 months. The early adopters like myself already run IPv6 alongside IPv4, most systems have it built in ready to go, and ISPs are getting up to speed.
the AC
Leaving for Barcelona friday
Hemos is like...sci-fi fans;he thinks technology is cool, but he hasn't bothered to understand the science it's based on