IPv6

IPv6, or Internet Protocol version 6, is a data-oriented network layer standard used by electronic devices to communicate data across a packet-switched internetwork. Following IPv4, it's the second version of the Internet Protocol to be formally adopted for general use. Although there was an IPv5, it was not a successor to IPv4; rather, it was an experimental flow-oriented streaming protocol, intended to support voice, video, and audio.

Purpose

IPv6 is intended to address the concern of IPv4 address exhaustion. There are too few IP addresses available for the future demand of device connectivity (especially cell phones and mobile devices). IPv4 supports 4.2 billion (256⁴ ≈ 4.294 × 10⁹) addresses, which is inadequate for giving even one address to every living person, much less support the burgeoning market for connective devices. IPv6 addresses this problem by supporting 340 undecillion (65536⁸ ≈ 3.4 × 10³⁸) addresses. For scale, this would allow an average of about 430 quintillion (4.3 × 10²⁰) unique addresses per square inch, or 670 quadrillion (6.7 × 10¹⁷) per square millimeter, of the Earth's surface. In other terms, assuming a population of about 6.5 billion humans, there are enough IPv6 addresses such that every atom of every person on Earth could be assigned 7 unique addresses with enough to spare (assuming 7 × 10²⁷ atoms per human).

Currently, IPv6 is most useful for mobility, quality of service, privacy extension, and so forth. It is expected that IPv4 will be supported until at least 2025, to allow time for bugs and system errors in IPv6 to be corrected.

History

Invented by Steve Deering and Craig Mudge at Xerox PARC, IPv6 was adopted by the Internet Engineering Task Force in 1994, when it was called "IP Next Generation" (IPng).

The adoption of IPv6 has been slowed by the introduction of network address translation (NAT), which partially alleviates the problem of address exhaustion. However, NAT makes it difficult or impossible to use some peer-to-peer applications, such as Voice over Internet Protocol (VoIP) and online games. IPv6 currently accounts for just a few percent of the addresses in the publicly-accessible Internet, which is still dominated by IPv4. The U.S. Government has specified that all federal agencies must deploy IPv6 by 2008.

Addressing

128-bit length

The primary change from IPv4 to IPv6 is the length of network addresses, with IPv6 addresses being 128 bits long (as defined by RFC 2373 and RFC 2374). This corresponds to 32 hexadecimal digits, which are normally used when writing IPv6 addresses. Each hexadecimal digit can take 16 values (see combinatorics), resulting in a total of 16³² (340 undecillion) addresses.

IPv6 addresses are usually 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. However, 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. This is seen as an improvement over IPv4, where a great number of discrete netblocks are often assigned to one organization.

Notation

IPv6 addresses are normally written as eight groups of four hexadecimal digits. These are often followed by a slash and the prefix length (called a CIDR range), which turns them into a range of IPv6 addresses. For example, 2001:0db8:85a3:08d3:1319:8a2e:0370:7334/64 is a valid IPv6 address.

If a four-digit group is 0000, the zeros may be omitted. For example, 2001:0db8:85a3:0000:1319:8a2e:0370:7344/64 can be shortened as 2001:0db8:85a3::1319:8a2e:0370:7344/64. Following this rule, any group of consecutive 0000 groups may be reduced to two colons, as long as there is only one double colon used in an address. Thus, the lines below are all valid and equivalent.

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

However, 2001::25de::cade/64 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/64 may be shortened to 2001:DB8:2de::e13/64.

IPv4 addresses in IPv6 format

IPv4 addresses are easily converted to IPv6 format. Three methods exist to do this: standard IPv6 hexadecimal, hybrid IPv4-compatible address, and IPv4-mapped address.

For standard IPv6 hexadecimal, the IPv4 address 192.0.2.52 translates into hexadecimal as 0xC0000234, and is thus converted to an IPv6 address as 0000:0000:0000:0000:0000:0000:C000:0234 or ::C000:234.

For the sake of readability, the same IPv4 address can also be noted with decimal numbers as a hybrid IPv4-compatible address, in which case the address becomes ::192.0.2.52. However, regardless of the notation used, IPv4-compatible addresses are being deprecated, because IPv6 transition mechanisms no longer use them. The respective RFCs will reflect this shortly.

For an IPv4-mapped address, the last 32 bits of a standard IPv6 address may be written in decimal. Thus, ::ffff:192.0.2.9 is the same as ::ffff:c000:209.

Special addresses

There are a number of addresses with special meaning in IPv6 (see 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 localhost address which echoes back all the packets sent to it (corresponding to 127.0.0.1 in IPv4).
fc00::/7 – Unique Local IPv6 Unicast Addresses are only routable within a set of cooperating sites. They were defined in RFC 4193 as a replacement for site-local addresses (see below). The addresses include a 40-bit pseudorandom number that minimizes the risk of conflicts if sites merge or packets somehow leak out.
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 is only valid inside the local organisation. 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. Note that broadcast as in IPv4 is not supported in IPv6; multicast should be used instead.

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). The payload 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 that 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, for example, the 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 standardised on in August 2002 by RFC 3363 (with further discussion of the pros and cons of both schemes in RFC 3364).

IPv6 deployment

In February 1999, The IPv6 Forum was founded by the IETF Deployment WG to drive deployment worldwide creating by now over 30 IPv6 Country Fora and IPv6 Task Forces IPv6 FORUM. On 20 July 2004 ICANN announced[1] that the root DNS servers for the Internet had been modified to support both IPv6 and IPv4.

Benefits:

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 cannot 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 will be necessary to use transition mechanisms to integrate IPv6 and IPv4 nodes smoothly and seamlessly. In general, the transition mechanisms can be categorized into four groups:

Dual-stack
Tunneling
Translation
Gateway

Dual-stack is also referred to as the dual-stack IP layer solution (RFC2893)[2], which implements both the IPv4 and IPv6 protocol stacks in every node of the network. Each dual-stack node in the network will have both an IPv4 address and an IPv6 address.

Pros: Easy to deploy; widely supported.
Cons: Network topology may require two routing tables and two routing processes. Every node in the network needs to be updated to be dual-stack.

Tunneling is also referred to as IPv6 over IPv4 tunneling. Most of these tunnel mechanisms work by encapsulating IPv6 packets into IPv4 packets with IP next-layer protocol number 41, hence the name proto-41. This way, IPv6 packets can be sent over the IPv4 infrastructure. There are many tunneling technologies available. The key difference is in the method the encapsulating node uses to determine the address of the exit of the tunnel.

Some tunneling technologies are designed to allow the transmission of IPv6 packets through an internal IPv4-only networking infrastructure:

6over4 [6]
ISATAP [7]

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[8] or AYIYA protocols which encapsulates IPv6 over IPv4's User Datagram Protocol (UDP).

Translation is required when an IPv4-only node attempts to communicate with an IPv6-only node. The translation mechanisms can divided into two groups based on whether or not state information is kept:

Stateful: NAT-PT [9], TCP-UDP Relay [10], Socks-based Gateway [11]
Stateless: Bump-in-the-Stack,Bump-in-the-API [12]

Gateway is used when one computer is using IPv4 and another is using IPv6. The client connects to the gateway using IPv4 or IPv6, and the gateway connects to the server using the other protocol, sending the packets back to the client. One gateway service is provided by SixXS, and allows an IPv6 user to view IPv4 websites or vice-versa, by using a special URL. Another gateway service is 6gate, and allows IPv4-only websites to be viewed by clients using IPv6. Gateways (or proxies) are typically application-layer specific (for example 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 IPv6 Backbone
ipng IP Next Generation (concluded)
ipv6 IP Version 6
ipv6mib IPv6 MIB (concluded)
multi6 Site Multihoming in IPv6
shim6 Site Multihoming by IPv6 Intermediation
v6ops IPv6 Operations

Links: Misc

IPv6 READY LOGO ... Driving Interoperability
Japan IPv6 Promotion Council
Open Contributors' Corporation for Advanced Internet Development
SixXS - IPv6 Deployment & Tunnel Broker
Moonv6
A site automatically that will tell you your IPv6 Address

Links: Address Space

IANA Address Assignments
GRH SixXS's Ghost Route Hunter (Looking Glass + Address Usage overview)
A Pragmatic Report on IPv4 Address Space Consumption
Exhaustion of IP resources
Understanding IP Addressing Everything You Ever Wanted To Know Detailed explanation of IPv4/6 implementation.

Links: Software (Operating Systems + Applications)

KAME BSD IPv6 Stack
USAGI Linux IPv6 Stack
FreeSWAN IPSEC Stack
DeepSpace6 - Current Status of Applications supporting IPv6 / Linux IPv6 Info
Overview of IPng/IPv6 (provided by one of the co-chairs of the SIPP working group)
IPng Implementations Host and Router Implementations (mostly outdated)

Links: IPv6 Task Forces

Links: Relevant News/Reports

Template:Link FA