IPv6

IPv6, or Internet Protocol version 6, is a network layer standard; i.e., it governs the addressing and routing of data packets through a network.

IPv6 is intended to replace the IPv4 standard, whose limits on network addresses are beginning to restrict Internet growth and use, especially in China, India, and other heavily populated Asian countries. But the new standard will improve service all around the globe; for example, by providing future cell phones and mobile devices with their own unique and permanent addresses.

IPv4 supports about 4 billion (4 × 10⁹) addresses, while IPv6 supports about 3.4 × 10³⁸ (340 undecillion) addresses -- about 4.3 × 10²⁰ (430 quintillion) addresses per square inch (6.7 × 10¹⁷ (670 quadrillion) addresses/mm²) of the Earth's surface.

Adopted by the Internet Engineering Task Force in 1994 (when it was called "IP Next Generation" or IPng), IPv6 accounts so far for just a few percent [1] (http://bgp.potaroo.net/index-v6.html) of the addresses in the publicly-accessible Internet, which is still dominated by IPv4 [2] (http://bgp.potaroo.net/index-bgp.html). The adoption of IPv6 has been slowed by the introduction of network address translation (NAT), which partially alleviates the problem of address exhaustion. But NAT makes it difficult or impossible to use some peer-to-peer applications, such as VoIP and multi-user games. Currently, the big drive for IPv6 is new uses, such as mobility, quality of service, privacy extension and so on. The U.S. Department of Defense has also specified that all of its networked devices use the IPv6 standard by 2010.

It is expected that IPv4 will be supported until at least 2025, to allow time for bugs and system errors to be corrected.

IPv6 is the second version of the Internet Protocol to be formally adopted for general use. (There was also an IPv5, but it was not a successor to IPv4; rather, it was an experimental flow-oriented streaming protocol, intended to support voice, video, and audio.)

Contents

1 IPv6 addressing 1.1 Notation for IPv6 addresses 1.2 Special addresses 2 IPv6 packet 3 IPv6 and the Domain Name System 4 IPv6 deployment 4.1 Transition mechanisms 5 Major IPv6 announcements 6 Related IETF working groups 7 Further reading 8 External links

IPv6 addressing

The most dramatic change from IPv4 to IPv6 is the length of network addresses. IPv6 addresses, as defined by RFC 2373 and RFC 2374, are 128 bits long; this corresponds to 32 hexadecimal digits, which are normally used when writing IPv6 addresses, as described in the following section.

The number of possible addresses in IPv6 is 2¹²⁸ ≈ 3.4 x 10³⁸. The number of IPv6 addresses can also be thought of as 16³² as each of the 32 hexadecimal digits can take 16 values (see combinatorics).

In many situations, IPv6 addresses are composed of two logical parts: a 64-bit network prefix, and a 64-bit host-addressing part, which is often automatically generated from the interface MAC address.

It is often argued that 128-bit addresses are overkill, and that the Internet will never need that many. It should be noted that the rationale for the 128-bit address space is not primarily to make sure that addresses never run out, but rather to ensure that routing can be handled smoothly by keeping the address space unfragmented, rather than as the current situation is with IPv4, where a great number of discrete netblocks can be, and often are, assigned to one organization.

Notation for IPv6 addresses

IPv6 addresses, which are 128 bits long, are normally written as eight groups of four hexadecimal digits.

For example,

2001:0db8:85a3:08d3:1319:8a2e:0370:7334

is a valid IPv6 address.

If a four-digit group is 0000, it may be omitted. For example,

2001:0db8:85a3:0000:1319:8a2e:0370:7344  

is the same IPv6 address as

2001:0db8:85a3::1319:8a2e:0370:7344

Following this rule, if more than two consecutive colons result from this omission, they may be reduced to two colons, as long as there is only one group of two or more consecutive colons. Thus

2001:0DB8:0000:0000:0000:0000:1428:57ab 
2001:0DB8:0000:0000:0000::1428:57ab 
2001:0DB8:0:0:0:0:1428:57ab
2001:0DB8:0::0:1428:57ab
2001:0DB8::1428:57ab  

are all valid and mean the same thing, but

2001::25de::cade 

is invalid because it is not clear how many 0000 groups are on each side.

Leading zeros in a group can be omitted. Thus

2001:0DB8:02de::0e13

is the same thing as

2001:DB8:2de::e13

If the address is an IPv4 address in disguise, the last 32 bits may be written in decimal; thus

::ffff:192.168.89.9 is the same as 
::ffff:c0a8:5909, but not the same as
::192.168.89.9 or
::c0a8:5909.

The ::ffff:1.2.3.4 format is called an IPv4-mapped address. The ::1.2.3.4 format is an IPv4-compatible address.

IPv4 addresses are easily converted to IPv6 format. For instance, if the decimal IPv4 address was 135.75.43.52 (in hexadecimal, 0x874B2B34), it could be converted to 0000:0000:0000:0000:0000:0000:874B:2B34 or ::874B:2B34. Then again, one could use the hybrid notation (IPv4-compatible address), in which case the address would be ::135.75.43.52. These IPv4-compatible addresses are being deprecated, because IPv6 transition mechanisms no longer use them. The respective RFCs will reflect this shortly.

Special addresses

There are a number of addresses with special meaning in IPv6. This is a brief table of these, in CIDR notation.

•  ::/128 – the address with all zeroes is used to specify any address, and is only to be used in software.
•  ::1/128 – the loopback address is a host-local address which echoes back all the packets sent to it (corresponding to 127.0.0.1 in IPv4).
•  ::/96 – The IPv4-compatible address is used as a transition mechanism in dual IPv4/IPv6 networks.
•  ::ffff/96 – The IPv4-mapped address is used as a transition mechanism in dual-stack hosts.
• fe80::/10 – The link-local prefix specifies that the address only is valid in the local physical link.
• fec0::/10 – The site-local prefix specifies that the address only is valid inside the local organization. Its use has been deprecated in September 2004 by RFC 3879 and future systems must not implement any support for this special type of address anymore.
• ff00::/8 – The multicast prefix is used for multicast addresses.

IPv6 packet

The IPv6 packet is composed of two main parts: the header and the payload.

The header is in the first 40 bytes of the packet and contains both source and destination addresses (128 bits each), as well as the version (4-bit IP version), traffic class (8 bits, Packet Priority), flow label (20 bits, QoS management), payload length (16 bits), next header (8 bits), and hop limit (8 bits, time to live). Next comes the payload, which can be up to 64k in size in standard mode, or larger with a "jumbo payload" option.

There have been two slightly different versions of IPv6. The now-obsolete initial version, described in RFC 1883, differs from the current proposed standard version, described in RFC 2460, in two fields: 4 bits have been reassigned from flow label to traffic class. All other differences are minor.

Fragmentation is handled in the host only in IPv6. In IPv6, options also move out of the standard header and are specified by the Next Header field, similar in function to IPv4's Protocol field. A handwaving example: in IPv4 one would add a Strict Source and Record Routing (SSRR) option to the IPv4 header itself in order to enforce a certain route for the packet, but in IPv6 one would make the Next Header field indicate that a Routing header comes next. The Routing header would then specify the additional routing information for the packet, and then indicate that the, for example, TCP header comes next. This is analogous to the handling of AH and ESP in IPSec for IPv4 (which applies to IPv6 as well, of course).

IPv6 and the Domain Name System

IPv6 addresses are represented in the Domain Name System by AAAA records (so-called quad-A records) for forward lookups (by analogy with A records for IPv4); reverse lookups take place under ip6.arpa (previously ip6.int), where address space is delegated on nibble boundaries. This scheme is defined in RFC 3596.

The AAAA scheme was one of two proposals at the time the IPv6 architecture was being designed. The other proposal would have had A6 records for the forward lookup and a number of other innovations such as bit-string labels and DNAME records. It is defined in the experimental RFC 2874 and its references.

While the AAAA scheme is a simple generalisation of the IPv4 DNS, the A6 scheme was an overhaul of the DNS to be more general, and hence more complex:

• A6 records allowed a single IPv6 address to be broken across several records, perhaps held in different zones; this allowed in principle for rapid renumbering of networks, for example.
• Address delegation by use of NS records was largely replaced with DNAME records (analogous to the existing CNAME but renaming an entire tree). This permitted related forward and reverse components to be managed together.
• A new data type called the bit label was introduced to domain names, primarily for reverse lookups.

The AAAA scheme was effectively standardized on in August 2002 by RFC 3363 (with further discussion of the pros and cons of both schemes in RFC 3364).

IPv6 deployment

On 20 July 2004 ICANN announced[3] (http://icann.org/announcements/announcement-20jul04.htm) that the root DNS servers for the Internet had been modified to support both IPv6 and IPv4.

Disadvantages:

• the need for roll out of pervasive support for IPv6 throughout the Internet and its connected devices
• to be reachable from the IPv4 universe during the transition phase, you still need an IPv4-address or some kind of NAT (=shared IP-address) in the gateway routers (IPv6<-->IPv4) which adds complexity there and means the large address space promised by the specification can't be immediately used effectively.
• remaining architectural problems, such as the lack of agreement for proper support for IPv6 multihoming.
• 6bone
• ICMPv6

Transition mechanisms

Until IPv6 native connectivity becomes widely available and supported by the routing infrastructure, it is necessary to use transition mechanisms to tunnel IPv6 through IPv4 networks. That can be achieved with:

• configured static IPv6-in-IP tunnels between two dual-stack nodes, or
• 6to4, which is an automatic and asymmetric tunnel mechanism.

These tunnels work by encapsulating IPv6 packets into IPv4 packets with IP next-layer protocol number 41, hence the name proto-41. Similarly, ISATAP allows the transmission of IPv6 packets through an internal IPv4-only networking infrastructure. It also uses protocol number 41.

When IPv6 connectivity is desired from behind a NAT device, many of which do not forward proto-41 packets properly, one may use the Teredo protocol which encapsulates IPv6 over UDP over IPv4. It is also possible to use IPv6-to-IPv4 and IPv6-to-IPv6 proxies, though that is typically application-layer specific (eg. HTTP).

Major IPv6 announcements

• In 2003, Nihon Keizai Shimbun (as cited in CNET Asia Staff, 2003) reported that Japan, China, and South Korea claimed to have made themselves determined to become the leading nations in internet technology, which would partially take the form of jointly developing IPv6, and completely adopting IPv6 starting in 2005.
• ICANN announced on 20 July 2004 that the IPv6 AAAA records for the Japan (.jp) and Korea (.kr) country code Top Level Domain (ccTLD) nameservers became visible in the DNS root server zone files with serial number 2004072000. The IPv6 records for France (.fr) were added a little later. This made IPv6 operational in a public fashion.

Related IETF working groups

• 6bone (http://www.ietf.org/html.charters/OLD/6bone-charter.html) IPv6 Backbone
• ipng (http://www.ietf.org/html.charters/OLD/ipngwg-charter.html) IP Next Generation (concluded)
• ipv6 (http://www.ietf.org/html.charters/ipv6-charter.html) IP Version 6
• ipv6mib (http://www.ietf.org/html.charters/OLD/ipv6mib-charter.html) IPv6 MIB (concluded)
• multi6 (http://www.ietf.org/html.charters/multi6-charter.html) Site Multihoming in IPv6
• v6ops (http://www.ietf.org/html.charters/v6ops-charter.html) IPv6 Operations

Further reading

• RFC 2553 - Basic Socket Interface Extensions for IPv6
• RFC 2460 - Internet Protocol, Version 6
• RFC 1883 - Obsolete - Internet Protocol, Version 6

External links

• IPv6 Task Forces & The IPv6 Portal (http://www.ipv6tf.org)
• Why you want IPv6 (http://linuxreviews.org/features/ipv6/) (linuxreviews.org)
• http://www.iana.org/assignments/ipv6-address-space
• http://www.kame.net/
• http://www.freeswan.org/
• CNET Asia Staff. (2003). Report: Japan, China, S. Korea developing next Net. Retrieved January 14, 2003. (http://news.com.com/2100-1032_3-5134110.html?tag=nefd_top)
• http://www.moonv6.org/
• IPng Implementations (http://playground.sun.com/pub/ipng/html/ipng-implementations.html) (Host and Router Implementations)
• IPv6 & Linux - Current Status (http://www.bieringer.de/linux/IPv6/status/IPv6+Linux-status-distributions.html)
• Overview of IPng/IPv6, provided by one of the co-chairs of the SIPP working group. (http://playground.sun.com/pub/ipng/html/INET-IPng-Paper.html)da:IPv6

de:IPv6 es:IPv6 fr:IPv6 ko:IPv6 it:IPv6 nl:Internet Protocol Version 6 ja:IPv6 no:IPv6 pl:IPv6 pt:IPv6 ru:IPv6 sk:IPv6 fi:IPv6 zh:IPv6