IPv6 and Wikipedia:Sandbox/Archive: Difference between pages

Revision as of 22:34, 23 June 2007

Revision as of 18:18, 13 July 2007

Line 1:

{{Please leave this line alone (sandbox heading)}}

{{IPstack}} <!-- Edit the stack image at: Template:IPstack -->

<!-- Hello! Feel free to try your formatting and editing skills below this line. As this page is for editing experiments, this page will automatically be cleaned every 12 hours. -->

'''Internet Protocol version 6''' ('''IPv6''') is a [[network layer]] protocol for [[packet]]-switched [[internetwork]]s. It is designated as the successor of [[IPv4]], the current version of the [[Internet Protocol]], for general use on the Internet.

| image = [[Image:DolphinBoonex.png|180px]]

{ddddd{dddddd}dddddddd}

What does "undo" do exactly?

The main improvement brought by IPv6 is the increase in the number of addresses available for networked devices, allowing, for example, each mobile phone and mobile electronic device to have its own address. IPv4 supports 2³² (about 4.3 billion) addresses, which is inadequate for giving even one address to every living person, let alone supporting embedded and portable devices. IPv6, however, supports 2¹²⁸ (about 340 billion billion billion billion) addresses, or approximately 5×10²⁸ addresses for ''each'' of the roughly 6.5 billion people alive today. With such a large address space available, IPv6 nodes can have as many universally scoped addresses as they need, and [[network address translation]] is not required.

==Introduction==

By the early 1990s, it was clear that the change to a [[classless network]] introduced a decade earlier was not enough to prevent the [[IP address starvation|IPv4 address exhaustion]] and that further changes to IPv4 were needed.<ref name="rfc1750">[http://tools.ietf.org/html/rfc1750 RFC 1750]</ref> By the winter of 1992, several proposed systems were being circulated and by the fall of 1993, the IETF announced a call for white papers (RFC 1550) and the creation of the "IPng Area" of [[working groups]].<ref name="rfc1750"/><ref>[http://playground.sun.com/ipv6/doc/history.html History of the IPng Effort]</ref>

IPng was adopted by the [[Internet Engineering Task Force]] on [[July 25]], [[1994]] with the formation of several "IP Next Generation" (IPng) [[working group]]s.<ref name="rfc1750"/> By 1996, a series of [[Request for comments|RFCs]] were released defining IPv6, starting with RFC 2460. (Incidentally, [[IPv5]] was not a successor to IPv4, but an experimental flow-oriented [[streaming media|streaming]] protocol intended to support video and audio.)

It is expected that IPv4 will be supported alongside IPv6 for the foreseeable future. However, IPv4-only clients/servers will not be able to communicate directly with IPv6 clients/servers, and will require service-specific intermediate servers or NAT-PT protocol-translation servers. Free Ipv4 addresses will exhaust around 2010, which is within the depreciation time of equipment currently being acquired.

==Features of IPv6==

To a great extent, IPv6 is a conservative extension of IPv4. Most transport- and application-layer protocols need little or no change to work over IPv6; exceptions are applications protocols that embed network-layer addresses (such as [[File Transfer Protocol|FTP]] or [[Network Time Protocol|NTPv3]]).

Applications, however, usually need small changes and a recompile in order to run over IPv6.

===Larger address space===

The main feature of IPv6 that is driving adoption today is the larger address space: addresses in IPv6 are 128 bits long versus 32 bits in IPv4.

The larger address space avoids the potential exhaustion of the IPv4 address space without the need for [[network_address_translation|network address translation]] and other devices that break the [[end-to-end]] nature of Internet traffic. It also makes administration of medium and large networks simpler, by avoiding the need for complex [[subnetting]] schemes. Subnetting will, ideally, revert to its purpose of logical segmentation of an [[IP network]] for optimal [[routing]] and access.

The drawback of the large address size is that IPv6 carries some bandwidth overhead over IPv4, which may hurt regions where bandwidth is limited ([[ROHC|header compression]] can sometimes be used to alleviate this problem). The address size also lacks the immediate memorability of the more familiar, shorter IPv4 address.

===Stateless autoconfiguration of hosts===

IPv6 hosts can be configured automatically when connected to a routed IPv6 network. When first connected to a network, a host sends a [[link-local]] [[multicast]] ([[Broadcasting (networks)|broadcast]]) request for its configuration parameters; if configured suitably, routers respond to such a request with a ''router advertisement'' packet that contains network-layer configuration parameters.

If IPv6 autoconfiguration is not suitable, a host can use stateful autoconfiguration ([[DHCPv6]]) or be configured manually.

Stateless autoconfiguration is only suitable for hosts: routers must be configured manually or by other means.

===Multicast===

[[Multicast]] is part of the base protocol suite in IPv6. This is in opposition to IPv4, where multicast is optional.

Most environments do not currently have their network infrastructures configured to route multicast; that is &mdash; the link-scoped aspect of multicast will work but the site-scope, organization-scope and global-scope multicast will not be routed.

IPv6 does not have a link-local broadcast facility; the same effect can be achieved by multicasting to the all-hosts group (<tt>FF02::1</tt>).

The [http://www.m6bone.net m6bone] is catering for deployment of a global IPv6 Multicast network.

===Jumbograms===

In IPv4, packets are limited to 64&nbsp;[[Kibibyte|KiB]] of payload. When used between capable communication partners and on communication links with a [[maximum transmission unit]] larger than 65,576 octets, IPv6 has optional support for packets over this limit, referred to as [[jumbogram]]s which can be as large as 4&nbsp;[[Gibibyte|GiB]]. The use of jumbograms may improve performance over high-[[Maximum transmission unit|MTU]] networks.

===Network-layer security===

[[IPsec]], the protocol for IP network-layer encryption and authentication, is an integral part of the base protocol suite in IPv6; this is unlike IPv4, where it is optional (but usually implemented). [[IPsec]], however, is not widely deployed except for securing traffic between IPv6 [[BGP]] routers.

===Mobility===

Unlike mobile IPv4, [[Mobile IPv6]] (MIPv6) avoids [[triangular routing]] and is therefore as efficient as normal IPv6. This advantage is mostly hypothetical, as neither MIP nor MIPv6 are widely deployed today.

==Deployment status==

[[As of 2005|As of December 2005]], IPv6 accounts for a tiny percentage of the live addresses in the publicly-accessible Internet, which is still dominated by IPv4. The adoption of IPv6 has been slowed by the introduction of [[classless inter-___domain routing]] (CIDR) and [[network address translation]] (NAT), each of which has partially alleviated the impact of [[address space]] exhaustion. Estimates as to when the pool of available IPv4 addresses will be exhausted vary &mdash; in 2003, Paul Wilson (director of [[APNIC]]) stated that, based on then-current rates of deployment, the available space would last until 2023,<ref>[http://news.zdnet.com/2100-1009_22-1020653.html Exec: No shortage of Net addresses] By John Lui, CNETAsia </ref>. December 21, 2004 [[Nortel]] became the first networking company to complete the University of New Hampshire IPv6 phase II testing. In September 2005 a report by [[Cisco Systems]] reported that the pool of available addresses would be exhausted in as little as 4&ndash;5 years.<ref>[http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_8-3/ipv4.html A Pragmatic Report on IPv4 Address Space Consumption] by Tony Hain, Cisco Systems</ref> [[As of November 2006]], a regularly updated report projected that the [[Internet Assigned Numbers Authority|IANA]] pool of unallocated addresses would be exhausted in May 2011, with the various [[Regional Internet Registry|Regional Internet Registries]] using up their allocations from IANA in August 2012.<ref>[http://www.potaroo.net/tools/ipv4/ IPv4 Address Report]</ref> This report also argues that, if assigned but unused addresses were reclaimed and used to meet continuing demand, allocation of IPv4 addresses could continue until 2024. The [[Federal government of the United States|U.S. Government]] has specified that the network backbones of all federal agencies must deploy IPv6 by [[2008]].<ref>[http://www.gcn.com/print/25_16/41051-1.html CIO council adds to IPv6 transition primer]</ref> But there are two specific challenges to this requirement. 1) There is no special federal funding available for IPv6 transitions. Thus agencies are expected to make the migration via their ongoing equipment purchases and network updates. Most agencies now have their transition plan in place, but surveys have noted that many are lagging when it comes to making that transition a reality. <ref>[http://www.govitwiki.com/wiki/IPv6_for_Gov#Current_Situation IPv6 for government - Current Situation]</ref>. 2) Agency IT budgets are tight at the moment, especially since the current 2007 IT Budget has been stalled, thanks to the Continuing Resolution.

Meanwhile [[Peoples Republic of China|China]] is planning to get a head start implementing IPv6 with their [[5 year plan]] for the [[China Next Generation Internet]].

With the notable exceptions of stateless autoconfiguration, more flexible addressing and [[Secure Neighbor Discovery]] (SEND), many of the features of IPv6 have been ported to IPv4 in a more or less elegant manner. Thus IPv6 deployment is primarily driven by address space exhaustion.

==Addressing==

===128-bit length===

<!--IPv4 supports 4,294,967,296 address -->

The primary change from IPv4 to IPv6 is the length of network addresses. IPv6 addresses are 128 bits long (as defined by RFC 4291), whereas IPv4 addresses are 32 bits; where the IPv4 address space contains roughly 4 billion addresses, IPv6 has enough room for 3.4×10³⁸ unique addresses.

IPv6 addresses are typically composed of two logical parts: a 64-bit (sub-)network prefix, and a 64-bit host part, which is either automatically generated from the interface's [[MAC address]] or assigned sequentially. Because the globally unique MAC addresses offer an opportunity to track user equipment, and so users, across time and IPv6 address changes, RFC 3041 was developed to reduce the prospect of user identity being permanently tied to an IPv6 address, thus restoring some of the possibilities of anonymity existing at IPv4. RFC 3041 specifies a mechanism by which time-varying random bit strings can be used as interface circuit identifiers, replacing unchanging and traceable MAC addresses.

===Notation===

IPv6 addresses 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 one or more four-digit group(s) is 0000, the zeros may be omitted and replaced with two colons(::). For example, 2001:0db8:0000:0000:0000:0000:1428:57ab can be shortened to 2001:0db8::1428:57ab. Following this rule, any number of consecutive 0000 groups may be reduced to two colons, as long as there is only one double colon used in an address. Leading zeros in a group can also be omitted (as in ::1 for localhost). Thus, the addresses below are all valid and equivalent:

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

2001:db8::1428:57ab

Having more than one double-colon abbreviation in an address is invalid, as it would make the notation ambiguous.

A sequence of 4 bytes at the end of an IPv6 address can also be written in decimal, using dots as separators. This notation is often used with compatibility addresses (see below). Thus, <tt>::ffff:1.2.3.4</tt> is the same address as <tt>::ffff:0102:0304</tt> and <tt>0:0:0:0:0:ffff:0102:0304</tt>, and <tt>::ffff:15.16.18.31</tt> is the same address as <tt>::ffff:0f10:121f</tt> and <tt>0:0:0:0:0:ffff:0f10:121f</tt>.

Additional information can be found in RFC 4291 - IP Version 6 Addressing Architecture.

===Literal IPv6 Addresses in URLs===

In a [[Uniform Resource Locator|URL]] the IPv6-Address is enclosed in brackets.

Example:

<nowiki>http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/</nowiki>

This notation allows [[parsing]] a URL without confusing the IPv6 address and port number:

<nowiki>http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/</nowiki>

Additional information can be found in "RFC 2732 - Format for Literal IPv6 Addresses in URL's" and "RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax"

===Network notation===

IPv6 networks are written using [[Classless Inter-Domain Routing#CIDR notation|CIDR notation]].

An IPv6 network (or subnet) is a contiguous group of IPv6 addresses the size of which must be a power of two; the initial bits of addresses, which are identical for all hosts in the network, are called the network's prefix.

A network is denoted by the first address in the network and the size in bits of the prefix (in decimal), separated with a slash. For example, <tt>2001:0db8:1234::/48</tt> stands for the network with addresses <tt>2001:0db8:1234:0000:0000:0000:0000:0000</tt> through <tt>2001:0db8:1234:FFFF:FFFF:FFFF:FFFF:FFFF</tt>

Because a single host can be seen as a network with a 128-bit prefix, you will sometimes see host addresses written followed with /128.

===Kinds of IPv6 addresses===

IPv6 addresses are divided into 3 categories <ref name=rfc2373>[http://tools.ietf.org/html/rfc2373 RFC 2373 - ''IP Version 6 Addressing Architecture'']</ref> :

* Unicast Addresses

* Multicast Addresses

* Anycast Addresses

A Unicast address defines a single interface. It identifies a single network interface. A packet sent to a unicast address is delivered to that specific computer.

[[Multicast]] addresses are used to define a set of interfaces that typically belong to different nodes instead of just one. When a packet is sent to a multicast address, the protocol delivers the packet to all interfaces identified by that address. Multicast addresses begin with the prefix FF00::/8, and their second octet identifies the addresses ''scope'', i.e. the range over which the multicast address is propagated. Commonly used scopes include link-local (2), site-local (5) and global (E).

[[Anycast]] addresses, are also assigned to more than one interface, belonging to different nodes. However, a packet sent to an anycast address is delivered to just one of the member interfaces, typically the “nearest” according to the routing protocol’s idea of distance. Anycast addresses cannot be identified easily: they have the structure of normal unicast addresses, and differ only by being injected into the routing protocol at multiple points in the network.

===Special addresses===

There are a number of addresses with special meaning in IPv6:

* <tt>::/128</tt> &mdash; the address with all zeros is an unspecified address, and is to be used only in software.

* <tt>::1/128</tt> &mdash; the [[loopback]] address is a [[localhost]] address. If an application in a host sends packets to this address, the IPv6 stack will loop these packets back to the same host (corresponding to [[127.0.0.1]] in IPv4).

* <tt>::/96</tt> &mdash; the zero prefix was used for [[IPv4-compatible address]]es; it is now obsolete.

* <tt>::ffff:0:0/96</tt> &mdash; this prefix is used for [[IPv4 mapped address]]es (see ''Transition mechanisms'' below).

* <tt>2001:db8::/32</tt> &mdash; this prefix is used in documentation (RFC 3849). Anywhere where an example IPv6 address is given, addresses from this prefix should be used.

* <tt>2002::/16</tt> &mdash; this prefix is used for [[6to4]] addressing.

* <tt>fc00::/7</tt> &mdash; Unique Local Addresses (ULA) are routable only 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. This address space is split into two parts:

** <tt>fc00::/8</tt> &mdash; - ULA Central, currently not used as the draft is expired.

** <tt>fd00::/8</tt> &mdash; - ULA, as per RFC 4193, [http://www.sixxs.net/tools/grh/ula/ Generator and unofficial registry].

* <tt>fe80::/64</tt> &mdash; The link-local prefix specifies that the address only is valid in the local physical link. This is analogous to the Autoconfiguration IP address <tt>169.254.0.0/16</tt> in IPv4.

* <tt>fec0::/10</tt> &mdash; The site-local prefix specifies that the address is valid only inside the local organisation. Its use has been deprecated in September 2004 by RFC 3879 and systems must not support this special type of address.

* <tt>ff00::/8</tt> &mdash; The multicast prefix is used for [[multicast address]]es<ref name=ipv6multicast>[http://www.iana.org/assignments/ipv6-multicast-addresses IP Version 6 multicast address]</ref> as defined by in "IP Version 6 Addressing Architecture" (RFC 4291).

There are no address ranges reserved for broadcast in IPv6 &mdash; applications use multicast to the ''all-hosts'' group instead. IANA maintains the official [http://www.iana.org/assignments/ipv6-address-space list of the IPv6 address space]. Global unicast assignments can be found at the various RIR's or at the [http://www.sixxs.net/tools/grh/dfp/all/ GRH DFP pages].

===Zone Indices===

Link-local addresses present a particular problem for systems with multiple interfaces. Because each interface may be connected to different networks and the addresses all appear to be on the same [[Classless Inter-Domain Routing|subnet]], an ambiguity arises that cannot be solved by routing tables.

For example, host A has two interfaces which automatically receive link-local addresses when activated (per RFC 2462): <tt>fe80::1/64</tt> and <tt>fe80::2/64</tt>, only one of which is connected to the same physical network as host B which has address <tt>fe80::3/64</tt>, if host A attempts to contact <tt>fe80:3</tt> how does it know which interface (fe80::1 or fe80::2) to use?

The solution defined by RFC 4007 is the addition of a unique zone index for the local interface, represented textually in the form <tt><nowiki><address>%<zone_id></nowiki></tt>, for example: <tt><nowiki>http://[fe80::1122:33ff:fe11:2233%eth0]:80/</nowiki></tt> - this however may cause it's own problems due to clashing with the [[percent-encoding]] used with URIs. [http://tools.ietf.org/html/draft-fenner-literal-zone-02]

* Microsoft Windows IPv6 stack uses numeric zone IDs: <tt>fe80::3%1</tt>

* BSD applications typically use the interface name as a zone ID: <tt>fe80::3%pcn0</tt>

* Linux applications also typically use the interface name as a zone ID: <tt>fe80::3%eth0</tt>, although Linux [[ifconfig]] as of version 1.42 (part of net-tools 1.60) does not display zone IDs.

<!-- TODO: Mac OS? Solaris? NetWare? HP-UX? AIX? -->

Relatively few IPv6-capable applications understand zone ID syntax (with the notable exception of [[OpenSSH]]), thus rendering link-local addresses unusable within them.

==IPv6 packet==

[[Image:IPv6 header rv1.svg|right|thumb|410px|The structure of an IPv6 packet header.]]

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

The header is in the first 40 [[Octet (computing)|octets]]/[[Byte |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, [[Quality of service|QoS]] management), payload length in bytes (16 bits), next header (8 bits), and hop limit (8 bits, [[Time to Live|time to live]]). The payload can be up to 64[[Kibibyte|KiB]] in size in standard mode, or larger with a "jumbo payload" option.

[[IPv4#Fragmentation and reassembly|Fragmentation]] is handled only in the sending host in IPv6: routers never fragment a packet, and hosts are expected to use [[PMTU]] discovery.

The ''protocol'' field of IPv4 is replaced with a ''Next Header'' field. This field usually specifies the transport layer protocol used by a packet's payload.

In the presence of options, however, the Next Header field specifies the presence of an extra ''options'' header, which then follows the IPv6 header; the payload's protocol itself is specified in a field of the options header.

This insertion of an extra header to carry options is analogous to the handling of AH and ESP in [[IPsec]] for both IPv4 and IPv6.

==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; [[reverse DNS lookup|reverse lookup]]s take place under <tt>ip6[[.arpa]]</tt> (previously <tt>ip6[[.int]]</tt>), where address space is delegated on [[nibble]] boundaries. This scheme, which is a straightforward adaptation of the familiar [[A record]] and ''in-addr.arpa'' schemes, 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, designed to facilitate network renumbering, 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 (with further discussion of the pros and cons of both schemes in RFC 3364).

{| class="wikitable" style="margin: 1em auto 1em auto"

|+ '''AAAA record fields'''

|-

|NAME||Domain name

|-

|TYPE||AAAA (28)

|-

|CLASS||Internet (1)

|-

|[[Time to live|TTL]]||Time to live in seconds

|-

|RDLENGTH||Length of RDATA field

|-

|RDATA||String form of the IPV6 address as described in RFC 3513

|}

RFC 3484 specifies how applications should select an IPv6 or IPv4 address for use, including addresses retrieved from DNS.

===IPv6 and DNS RFCs===

* DNS Extensions to support IP version 6 - RFC 1886

* DNS Extensions to Support IPv6 Address Aggregation and Renumbering - RFC 2874

* Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) - RFC 3364

* Default Address Selection for Internet Protocol version 6 (IPv6) - RFC 3484

* Internet Protocol Version 6 (IPv6) Addressing Architecture - RFC 3513

* DNS Extensions to Support IP Version 6 (Obsoletes 1886 and 3152) - RFC 3596

==IPv6 scope==

IPv6 defines 3 unicast address scopes: global, site, and link.

Site-local addresses are non-link-local addresses that are valid within the scope of an administratively-defined site and cannot be exported beyond it.

Site-local addresses are deprecated by RFC 3879. Note that this does not deprecate other site-scoped address types (e.g. site-scoped multicast).

Companion IPv6 specifications further define that only link-local addresses can be used when generating ICMP Redirect Messages [ND] and as next-hop addresses in most routing protocols.

These restrictions do imply that an IPv6 router must have a link-local next-hop address for all directly connected routes (routes for which the given router and the next-hop router share a common subnet prefix).

==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 <ref name=ipv6forum>[http://www.ipv6forum.org IPv6 FORUM]</ref>.

On [[20 July]] [[2004]] [[ICANN]] announced<ref name=icann1>[http://icann.org/announcements/announcement-20jul04.htm Next-generation IPv6 Address Added to the Internet's Root DNS Zone 20 July 2004]</ref> that the root [[Domain Name System|DNS]] servers for the Internet had been modified to support both IPv6 and IPv4.

A global view into the IPv6 routing tables, which displays also which ISPs are already deploying IPv6, can be found by looking at the [http://www.sixxs.net/tools/grh/dfp/all/ SixXS Ghost Route Hunter] pages: these pages display a list of all allocated IPv6 prefixes and give colors to the ones that are actually being announced in [[Border Gateway Protocol|BGP]]. When a prefix is announced, that means that the ISP at least can receive IPv6 packets for their prefix. They might then actually also offer IPv6 services, maybe even to end users/sites directly.

ISPs that provide IPv6 connectivity to their customers can be found in the [http://www.sixxs.net/faq/connectivity/?faq=native Where can I get native IPv6 FAQ].

The mandate by the United States Government to move to an IPv6 platform for all civilian and defense vendors by summer 2008 will greatly boost deployment. The awarding of over $150 billion in contracts in spring of 2007 by the General Services Administration will in itself come close to the total amount spent on the [[Y2K]] upgrade of the previous decade, and total cost will swell far beyond that, to as much as $500 billion.<ref>{{cite news |url= http://www.businessweek.com/magazine/content/06_45/b4008080.htm?chan=search |date=2006-11-06 |title=More Elbow Room On The Net|accessdate=2006-12-27|publisher=[[BusinessWeek Online]]}}</ref>

The [[OLPC|One Laptop Per Child]] project plans to assign IPv6 addresses to each of its laptops, due to the inadequacies of the IPv4 address space. When deployed, the OLPC mesh network will constitute several million IPv6 hosts.

==Transition mechanisms==

Until IPv6 completely supplants IPv4, which is not likely to happen in the foreseeable future, a number of so-called ''transition mechanisms'' are needed to enable IPv6-only hosts to reach IPv4 services and to allow isolated IPv6 hosts and networks to reach the IPv6 Internet over the IPv4 infrastructure. <ref name=sixxs>[http://www.sixxs.net/faq/connectivity/?faq=comparison IPv6 Transition Mechanism / Tunneling Comparison]</ref> contains an overview of the below mentioned transition mechanisms.

===Dual stack===

Since IPv6 is a conservative extension of IPv4, it is relatively easy to write a network stack that supports both IPv4 and IPv6 while sharing most of the code. Such an implementation is called a ''dual stack'', and a host implementing a dual stack is called a ''dual-stack host''. This approach is described in RFC 4213.

Most current implementations of IPv6 use a dual-stack. Some early experimental implementations used independent IPv4 and IPv6 stacks. There are no known implementations that implement IPv6 only.

===Tunneling===

In order to reach the IPv6 Internet, an isolated host or network must be able to use the existing IPv4 infrastructure to carry IPv6 packets. This is done using a technique somewhat misleadingly known as ''[[tunneling protocol|tunnelling]]'' which consists in encapsulating IPv6 packets within IPv4, in effect using IPv4 as a link layer for IPv6.

IPv6 packets can be directly encapsulated within IPv4 packets using protocol number 41. They can also be encapsulated within UDP packets e.g. in order to cross a router or NAT device that blocks protocol 41 traffic. They can of course also use generic encapsulation schemes, such as [[AYIYA]] or [[Generic Routing Encapsulation|GRE]].

====Automatic tunneling====

''Automatic tunneling'' refers to a technique where the tunnel endpoints are automatically determined by the routing infrastructure. The recommended technique for automatic tunneling is [[6to4]]<ref name=rfc3056>[http://tools.ietf.org/html/rfc3056 RFC 3056]</ref> tunneling, which uses protocol 41 encapsulation. Tunnel endpoints are determined by using a well-known IPv4 anycast address on the remote side, and embedding IPv4 address information within IPv6 addresses on the local side. 6to4 is widely deployed today.

Another automatic tunneling mechanism is [[ISATAP]]<ref name=rfc4214>[http://www.ietf.org/rfc/rfc4214.txt RFC 4214]</ref>. This protocol treats the IPv4 network as a virtual IPv6 local link, with mappings from each IPv4 address to a link-local IPv6 address.

''[[Teredo tunneling|Teredo]]'' <ref name=rfc4380>[http://tools.ietf.org/html/rfc4380 RFC 4380]</ref> is an automatic tunneling technique that uses UDP encapsulation and is claimed to be able to cross multiple NAT boxes. Teredo is not widely deployed today, but an experimental version of Teredo is installed with the Windows XP SP2 IPv6 stack. IPv6, 6to4 and Teredo are enabled by default in [[Windows Vista]] <ref name=vista>[http://msdn2.microsoft.com/en-us/library/aa480152.aspx The Windows Vista Developer Story: Application Compatibility Cookbook]</ref>.

====Configured tunneling====

''Configured tunneling'' is a technique where the tunnel endpoints are configured explicitly, either by a human operator or by an automatic service known as a [[Tunnel Broker]]<ref name=rfc3053>[http://tools.ietf.org/html/rfc3053 RFC 3053]</ref>. Configured tunneling is usually more deterministic and easier to debug than automatic tunneling, and is therefore recommended for large, well-administered networks.

Configured tunneling typically uses either protocol 41 (recommended) or raw UDP encapsulation.

=== Proxying and translation ===

When an IPv6-only host needs to access an IPv4-only service (for example a web server), some form of translation is necessary. The one form of translation that actually works is the use of a dual-stack [[Proxy server|application-layer proxy]], for example a web proxy.

Techniques for application-agnostic translation at the lower layers have also been proposed, but they have been found to be too unreliable in practice due to the wide range of functionality required by common application-layer protocols, and are commonly considered to be obsolete. See for example [[Stateless IP/ICMP Translation algorithm|SIIT]]<ref name=rfc2765>[http://tools.ietf.org/html/rfc2765 RFC 2765]</ref>,

[[NAT-PT]]<ref name=rfc2766>[http://tools.ietf.org/html/rfc2766 RFC 2766]</ref>,

[[TCP-UDP Relay]]<ref name=rfc3142>[http://tools.ietf.org/html/rfc3142 RFC 3142]</ref>,

Socks-based Gateway<ref name=rfc3089>[http://tools.ietf.org/html/rfc3089 RFC 3089]</ref>,

[[Bump-in-the-Stack]] or [[Bump-in-the-API]]<ref name=rfc2767>[http://tools.ietf.org/html/rfc2767 RFC 2767]</ref>.

==Major IPv6 announcements and availability==

*[[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.

*[[Apple Inc.|Apple]] [[Mac OS X v10.3|Mac OS X v10.3 "Panther"]] (2003) has IPv6 supported and enabled by default.<ref name=macos>[http://docs.info.apple.com/article.html?artnum=152309 Mac OS X 10.3 Using IPv6]</ref>

*[[Microsoft Research]]<ref name=microsoftIPv6>[http://research.microsoft.com/msripv6/ Internet Protocol Version 6 (old Microsoft Research IPv6 release)]</ref> first released an experimental IPv6 stack in 1998. This support is not intended for use in a production environment.

*[[Microsoft]] [[Windows NT 4.0]] and [[Windows 2000]] SP1 had limited IPv6 support for research and testing since at least 2002.

*Microsoft [[Windows XP]] (2001) had IPv6 support for developmental purposes. In [[Windows XP]] SP1 (2002) and [[Windows Server 2003]], IPv6 is included as a core networking technology, suitable for commercial deployment.<ref name="microsoft1">[http://www.microsoft.com/technet/network/ipv6/default.mspx Microsofts main IPv6 site]</ref>

*Microsoft [[Windows Vista]] (2007) has IPv6 supported and enabled by default.<ref name="microsoft1"/>

*Production-quality BSD support for IPv6 has been generally available since early to mid-2000 in [[FreeBSD]], [[OpenBSD]], and [[NetBSD]] via the [[KAME project]]<ref>[http://www.kame.net/ KAME project]</ref>.

*[[Linux]] support has been available since version 2.1.8, released in 1996. As of [[Linux kernel|kernel]] 2.6.10, the Linux IPv6 stack was approved by the IPv6 Forum in the IPv6 Ready Logo Phase-1 Program. Development still continues on improving the stack.<ref name=linuxIPv6>[http://www.linux-ipv6.org/stable-6-ann.html Linux IPv6 Development Project ]</ref>

* In the end of [[1997]] [[IBM]]'s [[IBM AIX (operating system)|AIX]] 4.3 was the first commercial platform that supported IPv6 <ref name=AIXipV6>[http://dict.regex.info/ipv6/6bone/6bone.mail-1998-01/0022.html IPv6 support shipping in AIX 3.3]</ref><ref name=AIXipV62>[http://dict.regex.info/ipv6/6bone/6bone.mail-1998-01/0024.html Its AIX 4.3.]</ref>

* Apple's [[AirPort Extreme]] 802.11n base station is an IPv6 gateway in its default configuration. It uses 6to4 tunneling and can optionally route through a manually configured IPv4 tunnel.<ref name=AppleAirPortExtreme>[http://www.apple.com/airportextreme/specs.html Apple AirPort Extreme technical specifications.]</ref>

* [[Sun_Microsystem|Sun]] [[Solaris_Operating_System|Solaris]] has IPv6 support since version 8 <ref name=SunSolarisIPv6>[http://www.ocf.berkeley.edu/solaris/versions/solaris/8.html Sun Solaris 8 changes from Solaris 7]</ref>

* Microsoft [[Windows Server 2008]] (2008) has IPv6 supported and enabled by default.<ref name="microsoft1"/>

==See also==

* [[China Next Generation Internet]]

* [[ICMPv6|ICMP for IPv6]]

* [[Comparison of IPv6 application support]]

==Notes and references==

<references/>

==Further reading==

=== Core specifications ===

* RFC 2460: Internet Protocol, Version 6 (IPv6) Specification (obsoletes RFC 1883)

* RFC 2461/RFC 4311: Neighbor Discovery for IP Version 6 (IPv6) (4311 updates)

* RFC 2462: IPv6 Stateless Address Autoconfiguration

* RFC 4443: Internet Control Message Protocol (ICMPv6) for the IPv6 Specification (obsoletes RFC 2463)

* RFC 2464: Transmission of IPv6 Packets over Ethernet Networks

* RFC 4291: Internet Protocol Version 6 (IPv6) Addressing Architecture (obsoletes RFC 3513)

* RFC 3041: MAC address use replacement option

* RFC 3587: An IPv6 Aggregatable Global Unicast Address Format

=== Stateless autoconfiguration ===

* RFC 2461: Neighbor Discovery for IP Version 6 (IPv6)

* RFC 2462: IPv6 Stateless Address Autoconfiguration

=== Programming ===

* RFC 3493: Basic Socket Interface Extensions for IPv6 (obsoletes RFC 2553)

* RFC 3542: Advanced Sockets Application Program Interface (API) for IPv6 (obsoletes RFC 2292)

* RFC 4038: Application Aspects of IPv6 Transition

* RFC 3484: Default Address Selection for Internet Protocol version 6 (IPv6)

=== Books ===

There are a number of IPv6 books:

* ISBN 0-12-370479-0 IPv6 Advanced Protocols Implementation (April 2007)

* ISBN 0-12-447751-8 IPv6 Core Protocols Implementation (October 2006)

* ISBN 0-471-49892-0 Migrating to IPv6: A Practical Guide to Implementing IPv6 in Mobile and Fixed Networks (2006)

* ISBN 1-59059-527-0 Running IPv6 (2006)

* ISBN 0-596-00934-8 IPv6 Network Administration (2005)

* ISBN 3-9522942-0-9 IPv6 - Grundlagen, Funktionalität, Integration by Silvia Hagen (German Edition, 2004)

* ISBN 0-596-10058-2 IPv6 Essentials, 2nd Edition by Silvia Hagen (English, 2006)

* ISBN 1-55558-318-0 IPv6 network programming by Jun-ichiro itojun Hagino (English, 2004)

* ISBN 957-527-727-9 IPv6 network programming by Jun-ichiro itojun Hagino (Traditional Chinese, 2004)

* ISBN 4-7561-4236-2 IPv6 network programming by Jun-ichiro itojun Hagino (Japanese, 2003)

* ISBN 0-13-241936-X IPv6: The New Internet Protocol by Christian Huitema (1998) (The original IPv6 bible)

==External links==

* [http://www.ipv6tf.org IPv6 News, info and more] Daily updated

* [http://www.ipv6-to-standard.org Data base of standard compliant services, hardware and software]

* [http://www.ipv6day.org 6Bone is gone] Info about configuration of IPv6 in several platforms

* {{dmoz|Computers/Internet/Protocols/IP/IPv6/}}

* [http://arstechnica.com/articles/paedia/IPv6.ars Everything you need to know about IPv6] from Ars Technica

* [http://iac.dtic.mil/iatac/download/Vol7_No3.pdf IPv6 - The Next Generation Internet Protocol (IATAC ''IAnewsletter'' 7-3 (Fall/Winter 2004/2005))]

* [http://www.ipv6tf.org/ European and World Wide IPv6 Task Forces]

* [http://doc.tavian.com/ipv6util/ IPv6 address utility]

* [[Nortel]] [http://www.nortel.com/corporate/news/newsreleases/2004d/12_21_04_ipv6_certification.html First to Achieve Next Generation Internet Protocol Qualification]

===Related IETF working groups===

* [http://www.ietf.org/html.charters/OLD/6bone-charter.html 6bone] IPv6 Backbone (concluded)

* [http://www.ietf.org/html.charters/OLD/ipngwg-charter.html ipng] IP Next Generation (concluded)

* [http://www.ietf.org/html.charters/ipv6-charter.html ipv6] IP Version 6

* [http://www.ietf.org/html.charters/OLD/ipv6mib-charter.html ipv6mib] IPv6 MIB (concluded)

* [http://www.ietf.org/html.charters/multi6-charter.html multi6] Site Multihoming in IPv6

* [http://www.ietf.org/html.charters/shim6-charter.html shim6] Site Multihoming by IPv6 Intermediation

* [http://www.ietf.org/html.charters/v6ops-charter.html v6ops] IPv6 Operations

[[Category:IPv6| ]]

{{Link FA|de}}

[[ar:IPv6]]

[[bs:IPv6]]

[[ca:IPv6]]

[[da:IPv6]]

[[de:IPv6]]

[[es:IPv6]]

[[eu:IPv6]]

[[fr:IPv6]]

[[gl:Protocolo IPv6]]

[[ko:IPv6]]

[[id:Alamat IP versi 6]]

[[it:IPv6]]

[[he:IPv6]]

[[mk:IPv6]]

[[nl:Internet Protocol Version 6]]

[[ja:IPv6]]

[[no:IPv6]]

[[nn:IPv6]]

[[pl:IPv6]]

[[pt:IPv6]]

[[ru:IPv6]]

[[sk:IPv6]]

[[fi:IPv6]]

[[sv:IPv6]]

[[tr:IPv6]]

[[zh:IPv6]]