To read original PDF of the print article, click here.
Internet Appliance Design
Ready or Not: IPv6 is Coming
The World Wide Web is no longer just workstations, servers, and PCs. It's now also PDAs, cell phones, and automobiles. The old protocols of the Internet cannot handle these millions of devices. IPv6 is coming and you're going to have to be ready.
The Internet, and many smaller, private networks, use the Internet Protocol version 4, IPv4, as the network layer upon which other protocols, such as TCP, reside. Developed in the late '70s, it became apparent by the early '90s that IPv4 was reaching the end of its useful life.
The Internet Software Consortium's annual survey of Domain Name Servers indicates incredible growth on the Internet. The latest numbers represent an annual growth rate of over 65%, and that includes only those systems that are publicly advertised. Private nodes are not included in this count. In fact, it was the fear of running out of IP addresses that first prompted the look into a new version of IP.
Four major changes were made in version 6:
Larger address space
One way to understand how many addresses 128 bits represents is to think of a book that describes every possible Internet node address with 100 node descriptions per page. If each page was 0.1mm thick and was printed double-sided, the book to describe all possible IPv4 addresses would be 2,000 meters thick.
This may sound like a big book, but the book describing all possible IPv6 addresses would be 2×1016 light-years thick. To date, the farthest sight seen by the Hubble telescope is less than 2×1013 light-years.2
You may recall that IPv4 uses a “dotted decimal” notation. For example, 126.96.36.199. IPv6 addresses are instead represented by hexadecimal 16-bit quantities separated by colons, for example, FF02:0:0:0:0:1:200E:8C6C (with the exception noted below). A double colon (::) can be used as a type of shorthand for a string of zeroes. The address FF02::1:200E:8C6C is, therefore, equivalent to the previous IPv6 address. The double colon can only be used once in an address.There is also the notion of an IPv4-compatible address, that has the 96 high-order bits set to zero. This can be represented as 0:0:0:0:0:0:0:188.8.131.52 or ::184.108.40.206. Whenever there is a case where a colon would cause confusion, a literal IPv6 address can be quoted using square brackets. For example, a URL may look like http://[fec0::55:a00:20ff:fe90:58f8]:80/index.html.
Authentication and privacy
The authentication header provides strong integrity and strong authentication for packets. The encapsulating security payload provides confidentiality by encrypting the payload of the packets.Autoconfiguration
IPv6 addresses are longer than IPv4 addresses, and much more awkward for people to work with. One of the goals of the IPv6 standards was to simplify the management of addresses.
Toward that end, IPv6 offers autoconfiguration, which gives IPv6 machines plug-and-play connectivity. Two types of autoconfiguration are available: stateless and stateful.
With stateless autoconfiguration, hosts automatically compute their own IP address by combining the network prefix obtained by the local router with their own Ethernet MAC address. Stateless autoconfiguration is described in RFC 2462. 6
Because some people view the use of a MAC address as an invasion of privacy, a new draft proposes a way for hosts to compute their own IP address based on a random number.7 Using a random number makes it harder for eavesdroppers and other information collectors to identify machines.
Stateful autoconfiguration is done with the DHCPv6 protocol.8 ,9 This is similar to the current DHCP protocol that is used to parcel out addresses and service information to individual machines. One advantage of using DHCPv6, instead of stateless autoconfiguration, is that DHCPv6 gives you the ability to configure dynamic updates to DNS. Another advantage is security. With stateless autoconfiguration, any node can connect to your network and start running. With DHCPv6 servers, you can maintain tighter control over which nodes can be configured for the network. The only nodes that can be configured through the DHCP server are those that you have explicitly authorized.
Converting from IPv4
This means you can code for IPv6 today, even if you still only use IPv4! The API, and your application, will still work. When you enable IPv6 in your network, the applications should continue to run with no changes.
The changes described in RFC 2553 for IPv6 cover four areas:
Core socket functions
Note that this applies only if you are using a sockets API, which may not be the case in an embedded system. Similarly, the application code changes I'm about to describe will only make sense if you're using a sockets or sockets-like networking API. If you are using such an API, you may be able to take advantage of a “socket scrubber” developed at Sun (www.sun.com/software/solaris/ipv6).
Address data structures
IPv6 also has a new address family, AF_INET6, a new protocol family, PF_INET6, and a new structure for holding a single IPv6 address, in6_addr. These are used in a way that is similar to IPv4's AF_INET, PF_INET, and in_addr.
Name-to-address translation functions
There's also a function to perform the reverse. Given a node name, getnameinfo() looks up an IP address.
Address conversion functions
When the IETF started working on IPv6, one of the requirements was to allow for a slow migration from IPv4 to IPv6. Obviously, an abrupt cutover from one protocol to another would be impossible. To make IPv6 successful, it would have to work on the Internet simultaneously with IPv4. RFC 1933, “Transition Mechanisms for IPv6 Hosts and Routers,” defines several methods for deploying IPv6 devices.13
In reality, “dual-stack” is a misnomer. Actually, only one IP module handles both IPv4 and IPv6. The socket layer, based on the AF_INET or AF_INET6 parameter, knows which protocol is being used. If IPv4 is being used, it constructs an IPv4-mapped address, where the 80 high-order bits are zero, the next 16 bits are 0xffff, and the 32 low-order bits are the IPv4 address, for example, ::FFFF:220.127.116.11. Thus, the IP module always receives a 128-bit address from the upper layer.
When the IP module receives an IPv4-mapped address, it assembles the IPv4 headers. When it receives a non-IPv4-mapped address, it assembles the IPv6 headers. Either way, the same module does the work of both protocols, so there really is only one stack.
The dual-stack router on one end of the communication takes IPv6 packets from the sender, encapsulates them within IPv4 packets, then forwards the packets across the IPv4 Internet. Another dual-stack router on the other side receives the IPv4 packets, extracts the IPv6 packets inside, and forwards the IPv6 packets to their proper destination.
Configuring tunnels can be a little tricky. To make life easier, the IETF draft, “IPv6 Tunnel Broker,” describes a way to automatically manage tunnels. A tunnel broker is a dual-stack machine that creates, modifies, or deletes tunnels for you. To dig a tunnel, you simply give the tunnel broker the following information:
See the IETF draft or more details on how a tunnel broker works.14 Communicating with IPv4 machinesSeveral mechanisms have been defined by the IETF for IPv6 applications to talk with IPv4 applications. See the referenced documents for more detailed information.
TCP/UDP Relay 17
Do your systems need to support both IPv4 and IPv6, or just IPv6? That depends. If your systems will run in a private network, IPv6 alone is enough. The extra memory required by the IPv4 portion of the stack can be eliminated if your systems will never talk to IPv4-only applications. Even if your applications connect to the Internet, they can use tunnels to communicate with other IPv6-only applications. The dual-stack can be relegated to the routers connecting your private network to the Internet.
In practice, the memory consumed by the IPv4 portion of the stack is relatively small, approximately 15KB for most implementations. Including it makes a nice insurance policy, especially since the majority of the Internet will still be IPv4 for a while. With the dual-stack approach, you will be guaranteed that your applications will work today and tomorrow, regardless of the mix of IPv4 and IPv6 machines on the network.
Not if, but when
Stephen Harpster is the engineering manager for IPv6 at Sun Microsystems Inc. He earned his BS in computer science at the Georgia Institute of Technology in 1982, and his MS in computer science/electrical engineering at Northwestern University in 1987. You can reach him via e-mail at .
1. RFC 1287, “Towards the Future Internet Architecture,” D. Clark, L. Chapin, V. Cerf, R. Braden, and R. Hobby, December 1991.
2. IPv6 and the Future of the Internet, Sun Microsystems, Inc., 1999. Available at www.sun.com/software/white-papers/wp-ipv6/ipv6wp.pdf.
3. RFC 1883, “Internet Protocol, Version 6 (IPv6) Specification,” S. Deering and R. Hinden, December 1995.
4. RFC 1826, “IP Authentication Header,” R. Atkinson, August 1995.
5. RFC 1827, “IP Encapsulating Security Payload (ESP),” R. Atkinson, August 1995.
6. RFC 2462, “IPv6 Stateless Address Autoconfiguration,” S. Thomson and T. Narten, December 1998.
7. Draft-ietf-ipngwg-addrconf-privacy-01, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” T. Narten and R. Draves, October 1999.
8. Draft-ietf-dhc-dhcpv6-15, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” J. Bound, M. Carney, and C. Perkins, May 2000.
9. Draft-ietf-dhc-dhcpv6exts-12, “Extensions for the Dynamic Host Configuration Protocol for IPv6,” J. Bound, M. Carney, and C. Perkins, May 2000.
10. RFC 2553, “Basic Socket Interface Extensions for IPv6,” R. Gilligan, S. Thomson, J. Bound, and W. Stevens, March 1999.
11. IEEE, “Protocol Independent Interfaces,” IEEE Std. 1003.1g, 1997.
12. Porting Networking Applications to the IPv6 APIs, Sun Microsystems, Inc., October 1999. Available at www.sun.com/software/solaris/ipv6/porting_guide_ipv6.pdf.
13. RFC 1933, “Transition Mechanisms for IPv6 Hosts and Routers,” R. Gilligan and E. Nordmark, April 1996.
14. Draft-ietf-ngtrans-broker-02, “IPv6 Tunnel Broker,” A. Durand, P. Fasano, I. Guardini, and D. Lento, October 1999.
15. RFC 2765, “Stateless IP/ICMP Translation Algorithm (SIIT),” E. Nordmark, February 2000.
16. RFC 2766, “Network Address Translation – Protocol Translation (NAT-PT),” G. Tsirtsis and P. Srisuresh, February 2000.
17. Draft-ietf-ngtrans-tcpudp-relay-00, “An IPv6-to-IPv4 Transport Relay Translator,” J. Hagino and K. Yamamoto, January 2000.
18. Draft-ietf-ngtrans-dstm-01, “Dual Stack Transition Mechanism (DSTM),” J. Bound, L. Toutain, and H. Afifi, March 2000.
19. Draft-ietf-ngtrans-6to4-05.txt, “Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels,” B. Carpenter and K. Moore, May 2000.
20. RFC 2529, “Transmission of IPv6 over IPv4 Domains without Explicit Tunnels, ” B. Carpenter and C. Jung, March 1999.
Additional IPv6 resources
This set of web pages provides good generic information on IPv6: playground.sun.com/pub/ipng/html/
This document outlines the business and technical case for IPv6:www.ietf.org/internet-drafts/draft-iab-case-for-ipv6-05.txt
This is a geographic map that gives an idea of worldwide deployment: noc.ntua.gr/~adamo/6bone/
The IPv6 Forum is a world-wide consortium of Internet vendors: www.ipv6forum.com/
Click on image to enlarge.