Stack-Hacker Itojun Talks About IPv6 87
Alert reader Sin Yuhara writes: "I've encountered [an interview in which] Jun-ichiro "itojun"
Ogino(KAME Project Core/NetBSD Core/FreeBSD Comitter)
talks about IPv6. The KAME IPv6 [?] stack is very well
known in the BSD world and beyond. I'm sure IPv6 and
related stuff must deploy, and this article may help all
people." It's a really good read -- itojun talks about the IPv6 tools that are already integrated into the various BSD systems, about the need for ever more testing, and about why Japan rocks.
Re:Cel Phones + IPV6??? (Score:1)
Seems the memory usage issues are being addressed for devices where it is an issue.
-Rusty
Re:Total FUD. (Score:1)
And the killer app is ... (Score:1)
Re: Not using NAT, are ISPs going to become nicer. (Score:1)
IPv6 mentioned in policy speech by prime minister (Score:1)
Re:Whatever (Talk to the Hand!) (Score:1)
--------------------
Re:Reality Check (Score:1)
Microsoft has ipv6 drivers for win 2k (Score:1)
Re:Whatever (Talk to the Hand!) (Score:1)
--------------------
Re:Total FUD. (Score:2)
Win2k german does NOT have build-in IPv6 support ! Really ! I DID test it
There's an addon on the micro$oft website, which you can install to have IPv6, but IIRC it was still labeled BETA the last time I did ceck it out ! (it was about 4 months ago !)
So please stop spreading FUD!
Re:Not using NAT, are ISPs going to become nicer. (Score:2)
Re:What about applications? (Score:1)
Re: Not using NAT, are ISPs going to become nicer. (Score:2)
That might be how it's supposed to be used, but that has little effect on how ISPs will actually configure their networks. What if an ISP defines all their customers to be part of one
Re:IPv6 and QoS (Score:2)
Deploying IPv4 QoS is possible today - I work for a company that makes software to enable QoS in routers, amongst other things, and am helping customers do this. The key approaches are DiffServ (easy to deploy, softer QoS), and RSVP (harder to deploy, harder QoS, and I don't know any real networks that have deployed this).
The IPv6 flow label reduces the load on core routers where RSVP has been deployed, by caching the result of an earlier classification decision (i.e. matching packets against IP adddresses, port numbers, etc). However, it's hardly a big step forward for QoS if you are using DiffServ as most networks do.
What's more important for QoS is that IPv6 will (eventually) make NATs much less popular. Trying to classify NATed traffic is a nightmare, of course, and IPv6 should make things easier.
My company also does MPLS stuff - interestingly, this will help IPv6 deployment, because the big fast core routers will NOT need to have their forwarding hardware upgraded to forward IPv6 packets. MPLS labels packets near the edge of the network, and once labelled the packets are forwarded using ONLY the 32 bit MPLS label. Hence the IPv6 headers are only inspected on the edge router for the MPLS network.
The result is that the core routers only need to run IPv6 routing software, not IPv6 forwarding - hence no need to replace those ASICs. The edge routers are typically small enough that they should be able to run IPv6 forwarding in software.
Of course, as someone else already pointed out, there is still a lot of work before the ISPs' routers get fully upgraded with the entire set of add-on protocols - routing, multicast, PPP, RADIUS, IP-over-ATM, and so on.
Security without NAT (Score:3)
Until people manage their host and firewall security a lot better, many sites may just stick with NAT because it's what they know, removing a key benefit of using IPv6. So perhaps improved security processes and technology are a prerequisite for IPv6 deployments.
Re:What about applications? (Score:2)
MPLS makes IPv6 work on core routers (Score:5)
The vast majority of IPv6 packets will not have options - yes, they need to be looked at if present, but in that case you just dump the packet into a slow path. Also, MPLS will help here (see below) - the packet should only hit the slow path on lower end routers.
As for core routers that use forwarding ASICs - the answer is to implement MPLS, starting on edge routers that forward IPv6 in software, and attach MPLS labels. The core routers ONLY see the 32 bit MPLS label, so there is no problem about forwarding IPv6 just as efficiently as IPv4, once it is MPLS labelled. The core routers need to run IPv6 routing processes, but that's just on the main CPU.
MPLS is already deployed in ISP and telco IP networks - it is currently used for traffic engineering (balancing traffic loads over the network) and MPLS VPNs, and the same technique will be used to carry ATM, Frame Relay, Ethernet and SONET.
In the longer term, new routers will come on the market with smart enough ASICs and network processors to handle IPv6 with no reduction in forwarding rates, but MPLS will be useful for those ISPs that want its extra features.
Re:IPv6 Benifit? (Score:1)
Everyone supporting it happen sooner if you supported it. Assuming you're part of "everyone," that is.
Re:Not using NAT, are ISPs going to become nicer. (Score:2)
One of the reasons to have 2^64 host addresses is so that you can use globally unique EUI64 host addresses (for example, for Ethernet, based on the hardware MAC address) to allow immediate auto-configuration on any network anywhere in the world without any chance of an IP address conflict or having to do manual assignments. (Manual assignments are also supported, though.)
There's more than one kind of efficiency; part of the idea of IPv6 is to make routing simpler to gain speed and avoid abominations like NAT. Anyway, only 15% of the address space has even been defined so far; 85% is still reserved for future uses! I wish people would bother to learn about things before commenting.
Re:OpenBSD (Score:2)
Re:OpenBSD (Score:1)
Re:OpenBSD (Score:1)
Moderators, what the hell are you doing? How can he get a +1 on something I just said, which did'nt get anything, and my first post still got nothing, which I think is "informative".
His post is -1 redundant.
Bizare.
Not using NAT, are ISPs going to become nicer. (Score:3)
IPv6 in Linux (Score:1)
Re:Where's the beef? (Score:1)
--
Japan is ahead of us in IPv6 (Score:4)
Go, Japan!
Re: Not using NAT, are ISPs going to become nicer. (Score:1)
Re:Not using NAT, are ISPs going to become nicer. (Score:1)
Re:No mention of 6to4? (Score:2)
- Hubert
Re:Won't help IPv6 take off (Score:1)
I'm not that old, but I remember internet before windows95. Win3.1 didn't have tcp/ip, so I had to load this "trumpet winsock" program (the icon was blue) before I could use netscape to look at web sites (mostly porn. I was 14).
I bet AOL CDs (diskettes?) had a program like that. And I bet the lack of tcp/ip on windows didn't stop them from giving them away like crazy.
Maybe we should have more porn websites running on ipv6.. That should motivate everyone. :-)
--
need NT, NOT. (Score:1)
Re:Not using NAT, are ISPs going to become nicer. (Score:1)
IPv6 routing doesn't fit well in hardware (Score:3)
IPv4 is much nicer. Only the first few hundreds bits in the packets really matter. Sure, an IPv4 header can be much bigger with options. It's just that nobody expects those options to be implemented. With IPv6, ignoring options is not
The reason is that the IPv6 effort was started in the early 90s at a time when IP routers where basically a bunch of interfaces and DMA engines around a shared packet buffer with a CPU in the middle chopping and tweaking the headers to route the packets. All the decisions were made by software, and, sometime in low cost routers, the CPU even performed the data transfers with the interfaces, no DMA. The IPv6 was built with this architecture in mind and requires the routers to do a lot of smart gee whiz things on the headers. That clean architectural model is alas obsolete.
Nowadays, routers' CPUs nearly never see a packet. All the routing is completely done in hardware. The CPUs just do housekeeping, maintaining the routing tables, collecting and processing statistics, that kind of stuff. The only packets they ever see are those for network maintenance, SNMP, etc, and routing protocols, OSPF, IGRP, BGP, you name it.
In serious routers, the real stuff happens between the switch fabric and the routing processors. The switch fabric, centralized or distributed, handles the bulk of the data transfers, receiving and sending packets between the interfaces and the packet buffers. Here, the unit is the gigabit per seconds (a few tens or hundreds of Gb/s or even Tb/s). When the switch fabric receives a packet, it stores it in a buffer and at the same time extract a few hundred bits of the header and forwards that to routing processors, a huge pipeline of table lookups and processing, 100% hard-coded in silicon.
After a while, the routing processors spit an answer to the switch fabric to flush or forward the packet with updated data for the variable fields (the TTL for instance, or even the whole header on NAT or multicast), or to create new packets. For instance, ISMP packets on TTL timeout can be completely generated in hardware! The unit there is the 100s of millions of packets per second. Go do that with CPUs... Worst of all, the IPv6 headers are highly variable and that completely screws up pipeline design where it's much better to handle bounded amount of data.
So, on current routers, IPv6 is supported
Oh well
Re:Not using NAT, are ISPs going to become nicer. (Score:1)
Re:And the killer app is ... (Score:1)
Sorry, I should have been more clear in my initial comments.
Heh. (Score:4)
Thanks, *BSD, for continuing to be the research arm of the software community...
Who the fuck is "us"? (Score:1)
Why?
What will it take for IPv6 to take off? (Score:1)
Re:Cel Phones + IPV6??? (Score:1)
Bah. (Score:1)
Seen many INLINE
...and when was that supposed to be the new standard?
I rest my case.
- Slashdot Cynic
Re:Not using NAT, are ISPs going to become nicer. (Score:2)
You've completely left out the efficiency factor from your calculation. While it is true that IPv6 allows a standard metric buttload of addresses, the system is set up to assign those addresses quite inefficiently.
For example, the standard assignment for an individual end user is likely to be a /64, which has appriximately 16E18 addresses in it, of which only one will be used, typically. Small ISP's like myself are currently assigned a /48, which has enough addresses for 65K end users, of which only a fraction will ever get used.
Of course, should the address space starts to become exhausted, what will happen is what always happens when a nonrenewable resource becomes scarce: conservation, but for right now IPv6 addresses in freaking huge blocks are easy to get. I've got 2^80 addresses, myself.
To answer the question asked in the subject, the reason the blocks are so large is because the routing tables would quickly become huge if the assigned blocks were smaller. That means that ISP's will likely assign blocks to end users and not worry about whether or not those end users assign those addresses to multiple computers. It's more work than it's worth to keep track of those addresses individually. NAT will still be around, though, because people like the additional security offered by it.
IPv4 isn't that large (Score:1)
Moreover, there is no need to implement all of IPv6 in a small device, only the bare bones functionality should suffice.
As a side note, CPUs are getting faster and less power consuming, and memory is getting cheaper so in the near future our cell phones will be nearly as powerful as yesterday's PCs.
Re:Heh. (Score:1)
--
Reality check: the killer app (Score:2)
Well, of course there is the traditional killer app that can tip the balance real quickly. For example, RIPE (the European IP address agency) received a phone call one day from a cellphone operator that they needed two class A address ranges, and when could they get them?
Of course, those guys were sent back to the drawing board. But if one of the bigger handset manufacturers starts deploying IPV6 (and IPV6 is complete enough to do that right now), the balance of power would shift and a lot of folks would be forced to keep up with the Joneses.
As you say, my concern is with the infrastructure more than with client support. Microsoft has been mentioned a lot in this thread, and I would be greatly surprised if they didn't have something in the wings to at least work around lack of native IPV6 support for existing clients (like 6to4 support).
Re:Heh. (Score:1)
That is the one thing I truly have to thank BSD for; without them, we wouldn't have networking as we know it today.
Won't help IPv6 take off (Score:1)
I think MS is biding its time to see if there is some way they can benefit from holding back IPv6. Because of the way the IPv4 address space is divided up, we will run out of IP addresses in a world where every person has multiple IP-enabled devices (including cell phones and PDAs). Such a world is just a few years away. MS knows they could prevent a shortage of IP addresses from happening by including IPv6 support in a consumer-level OS, but they are probably waiting to see if there is some way to make more money by letting that happen.
In a few years we may be hearing: "You want your own IP address? You'll have to sign up for MSN, in that case..."
Re:Where's the beef? (Score:1)
I think the AC might be right: CPRM
Re:Where's the beef? (Score:1)
If you can explain to me how this relates to Hard Disk Drives, I'll be greatly impressed.
However, if you wish to plot a curve of densities, and create "Pubpib's Law", I'll be all for it.
Re:WTF? (Score:1)
--------------------
Re:Where's the beef? (Score:1)
Re:Not using NAT, are ISPs going to become nicer. (Score:1)
Hard to say, really. I believe the reason ISPs charge for extra IP addresses these days is that IPv4 addresses are relatively scarce. IPv6 has 128-bit addresses, which works out to, hell, probably enough for every atom on/in the planet to be uniquely Internet-addressable. :-)
After the IPv6, ISPs will probably still charge for extra IP addresses for a while, simply because they're addicted to the extra money, but it seems to me a savvy ISP could start giving out IP addresses like candy at a parade to gain a competitive advantage.
IPv6 Benifit? (Score:1)
Re:Total FUD. (Score:1)
That is not totally true. Win2k can use IPv6 but install a technology preview of IPv6 that you have to download from the MSDN developer site.
OpenBSD (Score:1)
http://www.openbsd.org/errata.html#ipsec_ah
yesterday.
Re:OpenBSD (Score:2)
Re:Not using NAT, are ISPs going to become nicer. (Score:2)
Re: Not using NAT, are ISPs going to become nicer. (Score:1)
The idea is to get ISPs out of the business of evaluating your need for address space.
Re:Heh. (Score:1)
Nah, we don't want to be 14m3 and use the same IP stack that Microsoft uses.
Re:And the killer app is ... (Score:1)
Re:need NT, NOT. (Score:3)
Unfortunately, you are wrong. Microsoft® WindowsNT® and Windows2000® products can give you a reliability guarantee that no other products, certainly not this supposedly 'free' software, can provide. That's right, the nine fives promise. You heard it correctly. Microsoft will guarantee an uptime of %55.5555555. Yes: More than half of the time, your servers will be up and running, allowing you to take advantage of the new, electronic economy. With that kind of power, you can transform your business. That's the kind of leverage Microsoft provides.
War3 doo u w4nt 2 g0 70d@y!!!1©
IPv6 and IPsec for MacOS X (Score:1)
I don't know if it's in the public beta or will be in 1.0
ARIN's IPv6 Fee Policy Has Changed (Score:2)
Oh really? (Score:2)
"IPv6 encodes IP header options in a way that streamlines the forwarding process. Optional IPv6 header information is conveyed in independent "extension headers" located after the IPv6 header and before the transport-layer header in each packet. Most IPv6 extension headers are not examined or processed by intermediate nodes (in contrast with IPv4). This enables a big improvement in the deployability of optional IPv6 features, compared to IPv4 where IP options typically cause a major performance loss for the packet at every intermediate router."
Microsoft IPv6 Support (Score:1)
Yes. (Score:2)
It is ENTIRELY possible, and will be commonly done, to assign large blocks to each user, so as many devices as they want can be online, AS IT SHOULD BE.
Two things. (Score:2)
2) Your summary is essentially correct, but the root cause of the way ISP's charge is.... that's their business model. They don't care about charging for bandwidth, because the vast majority of their customers have the same usage habits. Someone who actually uses the bandwidth they pay for is a 'bad net citizen' or an 'abuser'.
That is why ISP's will invariably, eventually, shift to a model where you pay for what you use.
I tell you, if @home would come to me when I use lots of bandwidth and say 'look, you use three times the bandwdith of our averagesubscriber... so we want you to pay 3 times as much' I'd probably say 'Okay.. sounds fair'. But they don't, they just cut you off.
Re:MPLS makes IPv6 work on core routers (Score:1)
Why do both of you say that you need to look at all the options in an IPv6 header? I was under the impression that the following passage from RFC 2460 was correct:
As far as I can tell this means that any intermediate router only needs to check for a zero in the next-header field of the first header, and the vast majority of IPv6 packets will not contain that option. In fact, RFC 2460 doesn't define any actual options for the hop-by-hop header, so one could reasonably expect that it would almost never be used except in error. A packet with hop-by-hop options could be easily directed to software processing by IPv6 routing hardware.
What am I missing? Why does every option header need to be examined? IPv6 was specifically designed to eliminate that problem with IPv4 (among other things) so who screwed it up!?
It occurs to me that perhaps you mean "hop-by-hop options" when you say "options". Please tell me this is true and restore my faith in humanity :-)
Reality Check (Score:1)
Simple fact is that there are a LOT of devices out there that make your little "internet" work every day and no one ever seems to realize how incredibly large this network is.
The fact is the majority of protocols used by routers today have NOT been updated to support IPv6, so even if your little BSD box supports it, the thousands of routers that UUNet/Sprint/ATT/BBN/etc have in place will take a LONG time to be upgraded.
A LOT of protocols make things work, not just TCP and IP.. and if any of you expect ever major internet carrier to completely switch to IPv6 in the next 8 years you are delusional.
Until BGP, OSPF, and IS-IS all FULLY support IPv6 don't expect ANYONE to even begin a migration.
Total FUD. (Score:2)
Its just a matter of what kernel they were working from. 2000's supported it, 98's didnt.
They are already dropping support for 98+98se, I really dont think ME is far behind.
They arent holding ANYTHING up.
Re:IPv6 in Linux (Score:1)
For those of you who don't know what IPv6 is (Score:1)
http://www.ipv6.org/ [ipv6.org]
http://playground.sun.com/pub/ipng/html/ipng-main. html [sun.com]
http://www.ipv6forum.com/ [ipv6forum.com]
http://www.bieringer.de/linux/IPv6/IPv6-HOWTO/IPv6 -HOWTO.html [bieringer.de]
Unfortunately, ipv6.org is currently down.
r. ghaffari
(25/M/Baltimore, MD)
Re:Cel Phones + IPV6??? (Score:1)
Whatever (Talk to the Hand!) (Score:1)
It doesn't work that way in the real world. The cops should still come down hard on hackers like this guy 'Itojun'. And what the hell kind of name is that anyway? What's with all these white kids who are 'haxx0r' wannabes calling themselves japanese and other weird names?
Re:Not using NAT, are ISPs going to become nicer. (Score:1)
They're not just getting more scarce, they're much harder to get allocated (for ISPs). These days the IP orgs (such as ARIN) require ISPs signing up for new blocks to make absolutely sure they're not overusing right now, to justify their current usage (even requireing moving to name based hosting).
IPv6 and QoS (Score:1)
Re:Not using NAT, are ISPs going to become nicer. (Score:1)
What about applications? (Score:1)
If I set up an IPv6 network at home, can I set up apache to answer on an IPv6 address? What about mySQL? Postgres? Will Netscape access such addresses?
ICANN Pricing obstacle to IPv6 (Score:5)
It's not totally stupid - one of the problems that does need to be solved by any widespread replacement of the current IPv4 stack is routing table size for the Big Internet, as BGP usage continues to multiply. IPv6 has some support for efficiency and consolidation, but there's still a lot of work to be done.
Re:Japan is ahead of us in IPv6 (Score:1)
And Japan has an awesome group of *BSD hackers. Most of the mobile stuff for FreeBSD comes from Japanese hackers (PAO [freebsd.org]. (The Japanese are really crazy about mobile computing.) I love this quote from Warner Losh:
(Read the whole article at DDJ: A Roundtable on BSD, Security, and Quality [ddj.com])---
In a hundred-mile march,
Re:MPLS makes IPv6 work on core routers (Score:1)
No rev 1 - The fact that IPv4 headers are messy does not matter when they are extracted in hardware. Picking a bit out of a stream is just wiring a register to the right bit lane. It doesn't matter if overall, the bit mapping is straight through or involve a lot of SHIFT 5 and ROT 13 and double forward scratch spin with loop jump. The hardware is there anyway. At worst, the control FSM is a bit messier. It's not the same for a CPU that must process dword by dword and where the fields' layout matters. IPv6 headers are simply big and variable, which means that a lot of data has to go back forth between the switch fabric and the routing processor, and that it screws up the pipeline. You can't say anymore 1 header = 1 clock cycle. Also it doesn't mix well with existing headers processing and ramps up the cost of Ethernet or IPv4 switching just to accommodate a few IPv6 packets there and there. It's a big issue for the cost of equipment used during the IPv4 / IPv6 transition.
No rev 2- You assume that software switching is still used at the edge of the network, and here we're go with MPLS tagging from there. That's not true anymore. I'm currently working on a family of L2-L4 wiring cabinet switches that routing at up to 80Gb/s cross-section and 150 Mpkt/s. It's an edge router, PCs and workstations directly attach to it, and it's 100% hardware routing. The previous family is already doing that. When you have a 100Mb/s connection to each terminal devices, software routing is not an option. So, at first all IPv6 routing will be handled as a software exception, and latter there will be a dedicated routing processor with its own data path., but even then it won't have the performance of IPv4.
No rev 3 - MPLS is not the solution. Or you end up with something that is not an IP router but an MPLS switch. That's not just hairsplitting. All a MPLS switch does is to shove packets from an interface to another based on the tag with strictly no idea of what's inside. By many aspects, MPLS is the terminal stage of virtual circuit networking from X25 with Frame Relay and ATM as the intermediate stages. What's lost with MPLS is the fine visibility on things like QoS, traffic segregation or packet ordering on multi-link load balancing in the core network. I don't know MPLS well enough to be definitive and I imagine it's possible to assign multiple tags to a single path to discriminate between different classes of traffic. So, is full IP routing at every node needed anyway? Frankly, I think so but I won't bet my head on that. So far, it has not mattered and doing that on the edge of a MPLS blob has been enough. So if ISPs think that MPLS is good enough, long life to MPLS. I'm just not convinced that this solution meant for bulk data transfers will work well for mixed traffic of bulk data and real-time stuff , VoIP and video, (although I'm pretty much sure some VoIP operators must use it, but on networks that only carry VoIP and that makes a serious difference).
I rate this one at $0.20. Inflation lurks! Where's Greenspan?
Re:Where's the beef? (Score:2)
As data gets more and more tightly packed onto the platters, the energy that holds the magnetic spin on each bit (determining whether it's a 0 or a 1) gets less and less significant, and now it is so close to the ambient thermal energy that bits are randomly flipping and corrupting data.
So they're looking at a lot of different techniques, but instead of my trying to explain them, let me just show you the Scientific American article [sciam.com] where this is all coming from.
--------------------------------
Re:MPLS makes IPv6 work on core routers (Score:2)
Re:MPLS makes IPv6 work on core routers (Score:2)
Re edge routers in software vs. hardware - I'm mainly talking about ISP's existing provider-edge routers (7500s and so on, quite often). Most of the deployed routers are software-based, so they are covered by the MPLS approach.
Of course, there are many hardware-based provider-edge routers as well, but these will be covered by hardware updates before too long (see http://www.cisco.com/warp/public/732/ipv6/IP_Vers
Once you have CEFv6, most IPv6 traffic should have the performance of IPv4 - not sure how the hop-by-hop options headers will affect this but I don't believe these will be common.
Re MPLS - it's not quite 'the terminal stage of virtual circuit networking'! It re-uses the data plane (i.e. label-based forwarding) but the control plane is normally just an IP routing process (some see this as a way of turning ATM switches into IP routers...). By default, MPLS is NOT circuit based at all - labels are assigned using LDP (label distribution protocol), which piggybacks on the IP routing protocol you are using. This lack of circuits is one reason why MPLS VPNs are very scalable (see www.orchestream.com, my company's site, for lots more info here).
You can use MPLS for traffic engineering, which requires laying down circuits, but you ONLY create circuits as the exception, to direct traffic somewhere other than the shortest-path route. Most traffic in a traffic engineered MPLS network may still be IP routed using MPLS labels that are not attached to circuits (aka label switched paths). See www.mplsforum.com.
MPLS does let you do quite a bit more than IP - it's really just a very thin encapsulation technology (i.e. a 32 bit label is the encapsulation overhead), so you can use it for VPNs (much more scalable than GRE tunnels or meshes of FR PVCs), Voice over MPLS (lower overhead than IP/UDP/RTP), Frame over MPLS (more scalable), and so on.
In particular, MPLS has a 3 bit EXP field that is used for CoS levels (i.e. DiffServ style QoS) - most MPLS edge nodes should copy the IP Precedence into the EXP field. If this is not enough, you can steer traffic onto different labels depending on CoS levels, and with MPLS traffic engineering you can reserve bandwidth for a given MPLS label switched path ('circuit') if needed.
You do need IP routing on every MPLS node, but only on the control plane - IP forwarding is only needed on edge nodes. I wouldn't suggest MPLS is necessarily the best or only way to deploy IPv6, but it is a great way to scale IPv6 backbones in the absence of IPv6-specific forwarding hardware, and it does have useful features that will apply to IPv4 and IPv6 traffic identically (hence MPLS can be justified for existing IPv4 traffic while enabling IPv6).
Cel Phones + IPV6??? (Score:1)
I can just see it - adding IPV6 to my handspring - 100K of onboard apps and 7.9 MB of IP stack...
As bad as WAP is, at least it can be feasibly implemented on small hardware.
Cyano
PS - not to diss IPV6 - thats all good to me, its just not going to solve all our problems
Re:Not using NAT, are ISPs going to become nicer. (Score:1)
If you know how to do the legwork, it's not all that hard to justify allocation of more IP addresses...
No mention of 6to4? (Score:5)
I know someone is going to mention that freenet6 or the 6bone is also easy to use, but they're much less efficient than 6to4.
Re:What will it take for IPv6 to take off? (Score:1)
IP6 is basically an extension on IP4 anyway, as far as IP addresses are concerned, so the old IP addresses are still valid and recognized under IPv6.
It will get a push here REAL soon, as the v4 pool is getting really short, and with all the consumer devices flooding the market now that are Internet ready. NAT is helping bridge the gap right now between supply and demand on v4 IP's, but NAT sucks.