USENIX Update

"IPv6: No Longer Optional", by Owen DeLong, Hurricane Electric Internet Services **Disclaimer: The views and opinions expressed in this video are those of the speaker(s) and do not necessarily reflect the views of the USENIX Association.** This is a talk about the need to move forward with IPv6 or become increasingly disconnected from the Internet. Topics covered will include: a brief history of IPv4 run-out; why IPv6?; how do I get started with IPv6?; an introduction to IPv6 on Linux as an example of a POSIX-like system.

The Internet is facing a slowly-unfolding crisis. The Internet Assigned Numbers Authority (IANA) ran out of assignable IP address blocks in April of this year. APNIC ran out of its allocation in April as well. The other regional registries have only a few years’ worth of addresses to issue. There is an obvious need for the larger address space that IPv6 provides, yet adoption remains low. Shumon Huque’s training session on Tuesday afternoon aimed to fix that.

Many IPv4 concepts have IPv6 analogues, although the two protocols are not compatible. There are some differences, however. For one, there is a greater emphasis on the client self-configuring. Machines that do not have static addresses set can obtain configuration via Stateless Address Autoconfiguration (SLAAC) or with DHCPv6. This does make it more difficult to control what devices can connect to the network. Some organizations prefer to use DHCPv6 because it allows pre-creating DNS records for the address pool. Automated configuration makes heavy use of ICMP, so it’s important to be judicious when crafting firewall rules.

Most operating systems have out-of-the box support for IPv6, and many have it turned on by default. Major applications have IPv6 support as well, including web browsers, IMAP servers, and instant messaging applications. (A large, but incomplete list of applications with IPv6 support can be found at http://www.ipv6-to-standard.org/) So where’s the holdup? There seems to be a lack of support for IPv6 in consumer-grade modems and routers, and lSPs and CDNs are slow to roll IPv6 to customers.

Comcast and Time Warner have begun limited IPv6 rollouts to friendly customers, and Akami claims to be the first CDN with IPv6 support. In the meantime, people interested in using IPv6 can set up tunneling through 6to4 or Taredo, or with a managed tunnel like the ones provided by Hurricane Electric, Freenet6, and Sixxs.

IPv6 adoption will be forced eventually, as the remaining IPv4 addresses are taken. But IPv4 will continue to coexist with IPv6 for many years to come. There are still issues to work out with IPv6, including user and admin training. Additionally, DHCP failover will need to be added to DCHPv6 before some sites will be willing to make the transition. In addition, network appliances like intrusion detection and intrusion prevention services will need to mature their IPv6 support.

Until then, expect to see IPv6 training remain a LISA staple.

 

The Internet is running out of addresses.  Current projections indicate the last available blocks will be assigned to regional registrars in May of next year, and that pool will be exhausted in January of 2012.  Clearly, there should be some urgency to begin the move to IPv6, but many sites appear to be in no hurry.  This generally seems to be due to the questions surrounding the 4-to-6 transition, which is why Rudi van Drunen‘s new IPv6 course was filled to capacity.

The first part of the course focused on some of the differences between IPv4 and IPv6.  Apart from the fact that IPv6 has many times the number of addresses, there are other technical changes.  For instance, IPv6 has a simplified header, reducing the number of fields from 12 to 8.  However, due to the longer source and destination addresses, the IPv6 header is twice the 20-byte length of its predecessor.

In addition to the under-the-hood changes, there are differences that require a change in the thoughts and habits of both administrators and programmers.  One potentially annoying change is that the 128-bit address length will make the memorization of IP addresses very difficult.  DNS will be even more critical in the IPv6 world.

A more interesting paradigm shift is the loss of NAT.  For better or for worse, sites both large and small have used NAT not only as a way to expand their available address space, but also to provide some degree of pseudo-firewall.  In some places, especially in the consumer universe, the wireless router is all that prevents outside traffic from reaching hosts.  The default routing configuration of IPv6-supporting consumer grade routers will be a key factor in how secure home users will be.

In addition to hardware and OS support, application-level support of IPv6 is another factor in the adoption process.  Network-aware applications that do any parsing or processing of IP addresses will need to have IPv6 support added.

There are clearly many factors that help explain why IPv6 uptake has been so slow.  Monday’s tutorial helped to clear up some of the confusion, although it didn’t necessarily encourage everyone.  Twitter user @jrwoodman said “aside from the magic factor, I no longer fear implementing IPv6 on a trial-to-production basis.”  However, one attendee commented in the chat that he “need[s] to find some new gig before IPv4 runs out because [he] honestly hate[s] this protocol.”

For those who remain uncertain about IPv6, LISA 10 offers several more opportunities this week.  An Invited Talks session at 11am Wednesday focuses on IPv6, and on Thursday at 11am, a Practice and Experience report focuses on IPv6 at ARIN.  At 2pm on Thursday, The (IPv6) Guru is In.

If you’re ready to start implementing IPv6, Rudi has given the following homework assignments:

• Get a tunnel and a subnet to use over the tunnel
• Set up the firewall and subnet autoconfiguration
• Turn on IPv6
• Adapt DNS to support IPv6
• Get native IPv6 from your ISP

The first three steps should be done by the end of this year, Rudi suggests, with the last two done by the end of 2012.  This way, you’ll be ready for IPv6 before the last of the IPv4 address space gets assigned.

It’s Monday afternoon, and LISA is chugging right along! I’m well into my second day of training, and having a great time, and learning a ton that I’m going to take back to work.

After lunch, I’ve signed up for a training course that sounds great: “Beginning IPv6”. It’s something that I’ve been very vocal about in the past. I’m convinced that by the time it’s obvious that everyone should implement IPv6, it will be too late to do it effectively. The most compelling argument to me is that the emerging markets of the world are going to be coming online using IPv6, because in short order, unassigned IPv4 blocks will all be assigned. That isn’t to say that providers aren’t sitting on blocks, but that it’s going to be harder and more expensive, therefore people who can’t buy them will go with the cheaper alternative that IPv6 will offer. They’re going to be your (and my!) future customers. I want to be ready in a couple of years, so I’m going out of my way to learn now. I didn’t learn IPv4 overnight, and I suspect the case will be made for IPv6 as well.

Rudi van Drunen started his presentation not with technical graphs of dwindling IP addresses. He started it with a slide with headers that said “Numbers run out” and “I need this turtle to dance”, and indeed, there was a CGI turtle. It wasn’t dancing. The turtle is from the KAME project. If you visit http://www.kame.net/ with IPv4, the turtle just sits there, but if you connect with IPv6, you get a dancing turtle. As Rudi said, let the dancing turtle be your incentive to implement IPv6.

As I mentioned, IPv4 addresses are running out. NAT has slowed the expansion, but it won’t be enough to quell the tide. IPv4 addresses are running out, and the internet is still expanding and smart phone use is exploding. We need more and more IP addresses. At this rate, our refrigerators are never going to get on the internet. And neither will the children of tomorrow.

In “IPv6…”, we went over the major changes from the IPv4 that we all know and love. The biggest change is undoubtedly the increase in IP address size. IPv4 uses 32 bit addresses. This provides just over four billion addresses. That sounds like a lot, but the 128 bit address space of IPv6 provides for 3.04×10^38 addresses. THAT is a lot of addresses.

Other changes that will influence networking are maximum transmission units (MTUs). The reason is that the typical MTU is 1500 bytes. With the previous IPv4 header taking up a scant 20 bytes, the larger IPv6 addresses double the header to 40 bytes. At least. Unlike the old version, IPv6 headers have multiple optional header additions. Looking at them from the outside in, each header holds a description of the next header inside of it. This provides the ability of nearly limitless plugins. This also leads to large headers, which can begin to take up an increasingly greedy chunk of the 1500 byte MTU. I forsee jumbo frames becoming more and more important as IPv6 becomes more prevalent and additional layers are implemented.

Speaking of additional layers, IPv6 provides the ability to add features into the protocol itself, through the use of these flexible headers. Where as IPv4 required specific packets to build and tear down IPsec tunnels, IPv6 has an optional header for ESP, encapsulating security packets. In other words, encryption. The header itself specifies that the packet contains encrypted information, rather than relying on encryption-protocol specific packets. This is exciting, and definitely makes me wonder about what new implementations will take effect once the protocol becomes more wide spread.

Overall, I’m still convinced that IPv6 is the future, and we’re going to need to learn it. The conversion isn’t going to happen overnight, and it’s going to take time to absorb the new environment. Why not start now with a lab environment and start learning? It’s not time wasted, it’s time invested in your future.

-
By Matt Simmons, author of the Standalone Sysadmin blog