IPv6 deployment is gaining momentum as World IPv6 Launch on June 6 approaches …

Share this story

Some "technologies of the future" stubbornly remain in the future and resist becoming technologies of the present. Case in point: fusion energy. For a long time, IPv6 seemed to fall into that category. But now, could it finally be for real? Anyone who missed the memo: current IP addresses are 32 bits long and are running out. IPv6 fixes this with addresses that are 128 bits long. But this only works when you actually run IPv6. Last year, some big players did exactly that for one day as a test. This year, the idea is to leave it on.

I'm at the 83rd IETF meeting in Paris this week (the same Internet Engineering Task Force that created IPv6 in the first place in the 1990s). I went to my first IETF meeting in 2002. Back then there was a lot of IPv6 work going on, although there was plenty of IPv6 skepticism heard in the hallways. A decade later, IPv6 is a given. Only when I try to check Dutch news sites to see if we still have a government do I notice that I'm on the IPv6-only WiFi network. All the IETF-related pages and tools are available over IPv6 as a matter of course. That isn't to say no IPv6-related work is going on, but that work happens in maintenance and operations working groups. In fact, the IETF leadership is now thinking about chartering a "v4exit" working group to focus on an orderly shutdown of the old IPv4 protocol.

In the meantime, World IPv6 Launch looms large. It's coming to a worldwide computer network near you on June 6. Last year, Akamai was one of the prominent participants in World IPv6 Day, which failed to kill the Internet last year. There was some more work to be done, however. Akamai explained to Network World that, as of April, the content delivery network is finally ready for IPv6.

Cisco and the Internet Society (ISOC) used the Paris meeting for a near-impromptu lunch get-together, talking about what some of the big World IPv6 Launch participants are doing. ISOC's Phil Roberts, moderator of the panel, kicked things off by saying that "IPv6 'on by default' is the new normal."

IPv6 World Launch Day panel

Iljitsch van Beijnum

In response to questions from the audience, Time Warner Cable and Comcast representatives talked about what the new normal means to them. As part of World IPv6 Launch, they've committed to have one percent of their customers using IPv6 by June 6. But as 30 percent of their consumers use Windows XP (which doesn't have IPv6 enabled out of the box) and 70 percent have a non-IPv6-capable home router, they need to enable IPv6 on a rather significant number of subscriber connections to hit that seemingly unambitious one percent. New Comcast and Time Warner Cable users—and also many existing users—will gain IPv6 connectivity over the next three months, and more after that. However, different cities will get it at different times.

So far, Comcast has provided IPv6 connectivity only to Windows Vista/7 and OS X 10.7 users who connect their computer directly to a DOCSIS 3 cable modem. But they're now also going to delegate an entire range of IPv6 addresses to IPv6-capable home routers, which can then hand out these addresses on their LAN ports and over Wi-Fi. And IPv6-support is even coming to selected DOCSIS 2 modems. Both cable operators will be giving out /64 prefixes, which is the size used on a single subnet. In other words: you can't daisy chain home routers or have separate IPv6 home and office networks separated by a router or firewall. The rationale for this decision is that some home routers may be confused by a larger address block, and current ones have no use for such a bigger block, anyway. But bigger address blocks may be given out at some point in the future.

Speaking of home routers, Cisco, the new home of Linksys, has a lineup of routers that have IPv6 enabled by default. The same is true for D-Link. These IPv6-enabled home routers are set up to request a range of addresses on their WAN side and redistribute those on the LAN side. This way, IPv6-capable systems automatically get both IPv4 and IPv6, while everything else continues to use IPv4 as usual.

Last year, most of the focus of the World IPv6 Day 24-hour trial run was on big websites. These are again joining the party this year, but they won't remove their server's IPv6 addresses from the DNS again after the 24 hours is up. Google's Lorenzo Colitti is looking forward to welcoming that one percent of IPv6 users from the participating ISPs on the Google servers. He stressed that publishing IPv6 addresses in the DNS permanently this year is only realistically possible after World IPv6 Day. It showed that it was possible to enable IPv6 for the whole Internet without significant impact.

So even though ISOC has yet to get any mobile networks on board, as of early June, network operators should expect a significant increase in IPv6 traffic. And that will be just the beginning. It's the new normal, after all. Here at Ars we're going to prepare for World IPv6 Day with an article explaining how you can enable IPv6 in your own (home) network. If you have any questions about that, let us know in the comments.

Share this story

Iljitsch van Beijnum
Iljitsch is a contributing writer at Ars Technica, where he contributes articles about network protocols as well as Apple topics. He is currently finishing his Ph.D work at the telematics department at Universidad Carlos III de Madrid (UC3M) in Spain. Emaililjitsch.vanbeijnum@arstechnica.com//Twitter@iljitsch

96 Reader Comments

the transition will be hampered because IETF *failed* to define backward compatibility for IPV6. this means everyone will have to run dual-stack until everything they need to access has provided IPV6 access

while this might not appear to be the end of the world dual-stack systems have had bug problems in the past. too, as we know, complexity is the enemy of security and it remains to be seen how the hackers will manipulate the dual stack receivers into allowing un-authorized messages

another opportunity was missed when we failed to required mobil devices to use IPV6 instead of gobbling up the last of our IPV4 addresses. mobil devices are the real culprits in this.

With my current setup (AT&T DSL, FreeBSD 7.x router doing PPoE to a DSL modem), I can't keep a functional IP stack running for more than a day - often less than an hour. Each time, I need to reboot the FreeBSD box and the IPv4 address changes. (I need to go to FreeBSD 9.x - or Linux.)

If AT&T doesn't give me a FIXED /64 network, that will mean that my INTERNAL LAN connectivity will be messed up every time the link bounces - unless I continue to run IPv4 for internal connectivity.

When I had Comcast, I kept the IPv4 address for weeks - even months.

Last time I checked (last year), IPv6 plans at work are limited due to the additional load IPv6 puts on routers - and there isn't enough of a budget to replace the campus backbone routers for an upgrade (it's a big network.)

Yeah, that's a problem on your box. My access point is a FreeBSD 8.2-STABLE release box that does PPPoE to FiOS and IPv6 tunnel brokering at the same time. Current uptime: 143 days, although I have had the remote end close the connection a couple of times in those days, which gives my box a new IP address when it comes back up. If a stock FreeBSD install is crashing on you randomly like that, you may have a hardware problem, although upgrading from 7 isn't a terrible idea anyway.

For a long time, IPv6 was handled on the "slow path" on Cisco routers, but that hasn't been true for almost a decade now, so unless your Campus is clinging to some really obsolete boxes they shouldn't have that problem anymore.

As far as I know, you can't choose link local addresses, they always get autoconfigured by the interface. Also, trying to use them normally can be a bit infuriating since every interface on your box has a link local, so you have to explicitly tell every program which interface to use when you specify a link local (unless you only have one). IPv6 has a "private address space" just like the 10 net in IPv4, that would probably be a better choice. The private address range is from FEC:: to FEFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF.

To be honest though, global addresses are so easy to get for IPv6 that there is not a lot of incentive to use private address space like this.

At least we're moving into the future. The only thing I'm worried about is memorizing IP's. Seriously, 192.168.1.1 is so easy to remember, now try memorizing 2001:db8:85a3:0:0:8a2e:370:7334.

However, inside your house you can really use the link local address. If you use DHCPv6 instead of SLAAC, I assume you could provide link locals like FE80::1, FE80::2, etc.

It's only the global stuff that gets hard to remember. And if you're working with global addresses, you're probably working with domains instead of IPs anyway.

Indeed. It's all a bit like trying to learn another language by translating everything into the language you already know... tedious, confusing, and ultimately ineffective.

Once we're all fluent in v6, these concerns will fade away. And we'll have the help of current and future protocols that will eliminate much of the need to worry about the exact addresses. The system will do much of the remembering for us.

At least we're moving into the future. The only thing I'm worried about is memorizing IP's. Seriously, 192.168.1.1 is so easy to remember, now try memorizing 2001:db8:85a3:0:0:8a2e:370:7334.

However, inside your house you can really use the link local address. If you use DHCPv6 instead of SLAAC, I assume you could provide link locals like FE80::1, FE80::2, etc.

It's only the global stuff that gets hard to remember. And if you're working with global addresses, you're probably working with domains instead of IPs anyway.

Wut?

You will be working with global addresses on any device that needs to access the global network. This could be your phone, your light bulb, your TV, your computer, your tablet, your game console, etc. Every single device which needs Internet access will need a global address. That's how it works.

I've deployed IPv6 in my home and at the local hackerspace successfully.

At least we're moving into the future. The only thing I'm worried about is memorizing IP's. Seriously, 192.168.1.1 is so easy to remember, now try memorizing 2001:db8:85a3:0:0:8a2e:370:7334.

However, inside your house you can really use the link local address. If you use DHCPv6 instead of SLAAC, I assume you could provide link locals like FE80::1, FE80::2, etc.

It's only the global stuff that gets hard to remember. And if you're working with global addresses, you're probably working with domains instead of IPs anyway.

Indeed. It's all a bit like trying to learn another language by translating everything into the language you already know... tedious, confusing, and ultimately ineffective.

Once we're all fluent in v6, these concerns will fade away. And we'll have the help of current and future protocols that will eliminate much of the need to worry about the exact addresses. The system will do much of the remembering for us.

It's called DNS. There is also an IPv6 RFC, RFC6106, which supplies DNS Information in Router Announcements. However, Windows does not currently support this standard so you'll be stuck using DHCPv6 at least to supply DNS Information. Otherwise, SLAAC will/should work fine for you and everyone.

DHCPv6 is great if you need managed networks. Particularly if you do not run a Windows environment you will usually rely on your DHCP server to do dynamic updates. Windows hosts will dynamic update to Windows DNS servers, but every other OS relies on DHCP to perform that function.

At least we're moving into the future. The only thing I'm worried about is memorizing IP's. Seriously, 192.168.1.1 is so easy to remember, now try memorizing 2001:db8:85a3:0:0:8a2e:370:7334.

However, inside your house you can really use the link local address. If you use DHCPv6 instead of SLAAC, I assume you could provide link locals like FE80::1, FE80::2, etc.

It's only the global stuff that gets hard to remember. And if you're working with global addresses, you're probably working with domains instead of IPs anyway.

Indeed. It's all a bit like trying to learn another language by translating everything into the language you already know... tedious, confusing, and ultimately ineffective.

Once we're all fluent in v6, these concerns will fade away. And we'll have the help of current and future protocols that will eliminate much of the need to worry about the exact addresses. The system will do much of the remembering for us.

Also, v6 is significantly easier to deal with than v4 ever was. Despite the "long addresses". Firstly, you'll very likely remember your prefixes fairly easily. I know that off the top of my head I can recite both my home and hackerspace's /48's. But it gets easier from there.

Firstly, you no longer have to worry about host sizing. No more of this "Well, I need 512 hosts on my network so I should move to a /23, but wait, to expand, I should use a /22".

At this point you can now completely not give a rat's ass about how many individual hosts are on a given network and you no longer have to divide your network addressing scheme accordingly. This becomes increasingly frustrating if you use VLSM (which you should, you douche) because you need to make sure you don't use "too many" hosts on one network versus what your expected potential for other networks is.

Either way, not a big deal in v6. You divide your networks purely by administrative and security boundaries at this point.

You can still leverage Route Aggregation for v6 if you need to. You could take your /48 and divide it up into /52s, /56's, or /60s, or whichever you need. Learning how to do this will become more important since NAT won't/shouldn't exist to save you. This will prevent you from having to update upstream routers later on when you need an extra subnet somewhere (unless you run some sort of routing protocol, of course).

As of now, I use the following dual stack IP schemes on my hackerspace network:

Also, by design (though not through idiotic implementation), you completely avoid address space collisions while using IPv6.

Consider this:

You have a home network using 192.168.1.0/24Your small business/work network uses 192.168.1.0/24.

You want to VPN into your business.

As of right now this requires either assigning a new network prefix either network or by using NAT in creative ways, potentially killing end-to-end connectivity between devices (hint, Windows uses dynamic RPC ports for Active Directory Domains, so end-to-end connectivity is required).

We see this at my job. Our guest wifi network range matches the range of a company we work with which happens to include their NAC solution. Users who join our guest wireless are completely unable to VPN into that network because of this issue. And it's a 172 range.

With IPv6 all of that goes away provided you don't act like a tool in your network design. Let me reiterate this: Do not use FC00::/7 or FD00::/7 in your network unless you've generated a /48 off of it first, preferably using the sixxs.net tool for record keeping.

If you use say, FC00::/64 because you highly insist on NAT for security you are creating problematic ranges if you ever encounter someone else whom has done the same thing (and I know there will be more than a few of you out there).

As long as you generate a "random" ULA or just simply stick to GUA (which you should), you'll have 0 issues with this in the future.

Your local router broadcasts your prefix and the client just picks a random /64 suffix. If said random IP is in use, try again. The chance of collision is low, so that shouldn't happen often.

Unless, of course, your client was built with a library with broken random number generator, or badly seeded, such that having 4 or more clients of the same model on your network will cause them all to continuously fight over a small list of IPs.. :-)

I'm assuming there's a way to override stateless autoconfig? If I have a fileserver, I do NOT want it changing addresses unless I say so - EVER. I actually REALLY like the current NAT systems - changes to the outside networking world do not affect my internal network AT ALL. I can use 192.168.99.99 for forever and a day, even if a million other people do too in their own networks. Changes to my external IP change nothing on the inside.

Does this mean there'll be a pile of new advertising/discovery/ARP protocols for devices like printers, fileservers, routers, scanners, etc. that everyone wants to connect to that are currently handled by entering IP addresses? Entering even /64s would get old real fast.. (or, would totally remove the "address randomization" capabilities as everyone just uses <prefix>.0.0.0.0.0.0.0.1, <prefix>.0.0.0.0.0.0.0.2, etc...)

And I'm sure Apple will find a way to annoy network admins in IPv6 with their new AuRevoirV6++ protocol :-)

1) Every device will have multiple IPs. If you don't like the default, assign one via DHCP or make it static

2) DNS is your friend. There are already protocols for non-centralized name resolution. I bought an on-sale HP wireless printer, and I can ping it by name, same goes with my WII and PS3. No DNS required. Name resolution is quite standard with modern hardware.

NATs themselves provide absolutely no security. What actually adds security to a NAT is the fact that a NAT requires tracking state which is usually done by a stateful firewall. The firewall is where all of your security comes from, not the "hiding". IPv6+Firewall is at least as good as IPv4+NAT. In general, it will be better just because of the HUGE address space.

The fact that most NATs hand out a non-public address does provide security, though. Users at the university I go to get phished occasionally on not perfectly patched or older machines and may get viruses/trojans/rootkits (yes, some people have Admin rights who should not have it, I know...) on machines. The older half of the network has public addresses while the newer half has private (10.x.x.x) addresses. The ones with public addresses can be "accessed" from anywhere in the world if they get infected, but the ones with private addresses cannot. At the end of the day, you are right about the firewall or IDPS - it is the best/only way to detect/stop malicious traffic and track down infected machines.

Any semi-recent home router supports uPNP, infected machines can still be accessed from anywhere. Your Uni probably doesn't support uPNP, so users can't accept incoming connections, so yet, that is more safe. But the exact same thing can be done with IPv6.

Any security NAT can provide, a firewall can do with extremely simple basic rules that could easily be a check-box.

For those of you concerned with privacy and not having their MAC address being included in the IP address, when using autoconfiguration, you may want to take a look at RFC 4941 ( http://www.ietf.org/rfc/rfc4941.txt ).

From what I can see RFC 4941 is enabled by default in Windows, so if you wish to disable it for a particular reason you can: