IPv6 15318 226179920 2008-07-17T05:06:29Z Kbrose 3938795 [[WP:UNDO|Undid]] revision 226177288 by [[Special:Contributions/77.184.43.118|77.184.43.118]] ([[User talk:77.184.43.118|talk]]) 2001:db8::/32 is standard documentation prefix {{Copyedit|date=June 2008}} {{Refimprove|date=June 2008}} {{IPstack}} '''Internet Protocol version 6''' ('''IPv6''') is a [[network layer]] for [[packet (information technology)|packet]]-switched [[internetworking|internetworks]]. It is designated as the successor of [[IPv4]], the current version of the [[Internet Protocol]], for general use on the [[Internet]]. The main change brought by IPv6 is a much larger address space that allows greater flexibility in assigning addresses. The extended address length eliminates the need to use [[network address translation]] to avoid address exhaustion, and also simplifies aspects of address assignment and renumbering when changing providers. It is common to see examples that attempt to show that the IPv6 address space is extremely large. For example, IPv6 supports 2<sup>128</sup> (about 3.4×10<sup>38</sup>) addresses, or approximately 5×10<sup>28</sup> (roughly 2<sup>95</sup>) addresses for each of the roughly 6.5 billion (6.5×10<sup>9</sup>) people alive today.<ref>[http://www.census.gov/main/www/popclock.html U.S. Census Bureau]</ref> In a different perspective, this is 2<sup>52</sup> addresses for every star in the known universe<ref>[http://www.abc.net.au/science/news/stories/s910295.htm ABC: Number of visible stars put at 70 sextillion]</ref> &ndash; more than ten billion billion billion times as many addresses as IPv4 supported. The large number of addresses allows a hierarchical allocation of addresses that may make routing and renumbering simpler. With IPv4, complex [[Classless Inter-Domain Routing|CIDR]] techniques were developed to make the best possible use of a restricted address space. Renumbering, when changing providers, can be a major effort with IPv4, as discussed in RFC 2071 and RFC 2072. With IPv6, however, renumbering becomes largely automatic, because the host identifiers are decoupled from the network provider identifier. Separate address spaces exist for ISPs and for hosts, which are "inefficient" in address space bits but are extremely efficient for operational issues such as changing service providers. ==Introduction== By the early 1990s, it was clear that the change to a [[classless network]] introduced a decade earlier was not enough to prevent [[IPv4 address exhaustion]] and that further changes to IPv4 were needed.<ref name="rfc1752">RFC 1752: The Recommendation for the IP Next Generation Protocol</ref> By the beginning of 1992, several proposed systems were being circulated and by the end of 1992, the IETF announced a call for white papers (RFC 1650) and the creation of the "IP, the Next Generation" (IPng) area of [[working groups]].<ref name="rfc1752"/><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="rfc1752"/> 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. IPv4-only nodes (clients or servers) will not be able to communicate directly with IPv6 nodes, and will need to go through an intermediary; see [[#Transition mechanisms|Transition mechanisms]] below. ==Features and differences from IPv4== 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 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]] (NAT) 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). ===Stateless address autoconfiguration=== IPv6 hosts can be configured automatically when connected to a routed IPv6 network using [[ICMPv6]] router discovery messages. When first connected to a network, a host sends a [[link-local]] [[multicast]] ''router solicitation'' 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.<ref>RFC 4862: IPv6 Stateless Address Autoconfiguration, September 2007</ref> If IPv6 autoconfiguration is not suitable, a host can use stateful configuration ([[DHCPv6]]) or be configured manually. [[Stateless autoconfiguration]] is not completely suitable for routers, these generally must be configured manually or by other means.<ref>RFC 2894: Router Renumbering for IPv6, M. Crawford, August 2000</ref> ===Multicast=== [[Multicast]] is part of the base specifications in IPv6, unlike IPv4, where it was introduced later. 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>). Most environments, however, do not currently have their network infrastructures configured to route multicast: multicast on single subnet will work, but global multicast might not. ===Link-local addresses=== IPv6 interfaces have link-local addresses in addition to the global addresses that applications usually use. These link-local addresses are always present and never change, which simplifies the design of configuration and routing protocols. Link-local addresses are often used for network address autoconfiguration where no external source of network addressing information is available. ===Jumbograms=== In IPv4, packets are limited to 64&nbsp;[[kibibyte|KiB]] of payload. 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 used at present except for securing traffic between IPv6 [[Border Gateway Protocol]] 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 MIPv4 nor MIPv6 are widely deployed today. ===Simpler processing by routers=== IPv4 has a checksum field that covers the entire packet header. Since certain fields (such as the TTL field) change during forwarding, the checksum must be recomputed by every router. IPv6 has no error checking at the [[network layer]] but instead relies on [[link layer]] and transport protocols to perform error checking, which should make forwarding faster. ==Deployment status== As of May 2008, IPv6 accounts for a minuscule fraction of the used addresses in the publicly-accessible Internet, which is still dominated by IPv4.<ref>[http://www.ripe.net/ripe/meetings/ripe-56/presentations/Huston-Measuring_IPv6_Deployment.pdf Geoff Huston - An Update on IPv6 Deployment (RIPE 56)]</ref> With the notable exceptions of stateless auto-configuration, 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 IPv4 address space exhaustion, which has been slowed by the introduction of [[classless inter-domain routing]] (CIDR) and the extensive use of [[network address translation]] (NAT). ===IPv4 exhaustion=== {{main|IPv4 address exhaustion}} Estimates as to when the pool of available IPv4 addresses will be exhausted vary widely. 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> In September 2005 a report by [[Cisco Systems]], which is a network hardware manufacturer, reported that the pool of available addresses would be exhausted in as little as 4 to 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 2007]], a daily updated report projected that the [[Internet Assigned Numbers Authority|IANA]] pool of unallocated addresses would be exhausted in May 2010, with the various [[Regional Internet Registry|Regional Internet Registries]] using up their allocations from IANA in April 2011. <ref>[http://www.potaroo.net/tools/ipv4/ IPv4 Address Report]</ref> At the point at which the [[Regional Internet registry|RIR]] and IANA pools are exhausted, while there would still be unused IPv4 addresses, the existing mechanisms for allocating those addresses would no longer be capable of being applied, and it is at the moment unclear as to what those mechanisms might be. Mechanisms that have been discussed for allocating IPv4 addresses beyond this point have included the reclamation of unused address space, re-engineering hosts and routers to allow the use of areas of the IPv4 address space which are currently unusable for technical reasons, and the creation of a market in IPv4 addresses. ===IPv6 readiness=== The issues of IPv6 adoption are: * legacy equipment where ** the manufacturer no longer exists to provide support ** the manufacturer refuses to produce updates to support IPv6 or provides them but only at a cost that ensures most users won't purchase them. ** the software is not upgradeable, being in permanent ROM ** the device has insufficient resources to handle the IPv6 stack (usually a lack of ROM & RAM) ** the device can handle IPv6 but only at a much lower performance than IPv4 (an issue with many older routers) * manufacturers ensuring new equipment has sufficient resources to handle IPv6 * manufacturers investing in developing new software for IPv6 support * publicity to persuade end-users to prepare to upgrade existing equipment * publicity to inform end-users to create demand for IPv6-capable equipment * ISPs not investing technical resources into preparing for IPv6 There are two distinct classes of users of networking equipment, informed (mainly commercial and professional), and uninformed (mainly consumer). The former understand that network devices are specialist computers which may need software upgrades for security and performance fixes. The latter generally treat their networking equipment as appliances, which are configured only when first unboxed, if at all, and only ever undergo firmware upgrades when absolutely necessary. Inevitably it is the latter group who have no knowledge of IPv4 or v6, but who are most likely to suffer when their equipment has to be replaced, since commercial grade equipment has generally handled IPv6 for quite a few years. Most equipment such as hosts and routers require explicit IPv6 support. The main exception is equipment which only does low-level transport, such as cables, most ethernet adapters, and most layer 2 switches. As of 2007, IPv6 readiness is currently not considered in most consumer purchasing decisions. If such equipment is not IPv6-capable, it might need to be upgraded or replaced prematurely if connectivity from or to new users and to servers using IPv6 addresses is required. As with the year-2000 compatibility, IPv6 compatibility is mainly a software/firmware issue. However, unlike the year-2000 issue, there seems to be virtually no effort to ensure compatibility of older equipment and software by manufacturers. Furthermore, even compatibility of products now available is unlikely for many types of software and equipment. This is caused by only a recent realisation that IPv4 exhaustion is imminent, and the hope that we will be able to get by for a relatively long time with a combined IPv4/IPv6 situation. There is a tug-of-war going on in the internet community whether the transition will/should be rapid or long. Specifically, an important question is whether almost all internet servers should be ready to serve to new IPv6-only clients by 2012. Universal access to IPv6-only servers will be even more of a challenge. Most equipment would be fully IPv6 capable with a software/firmware update - IF the device has sufficient code and data space to support the additional protocol stack. However, as with [[64-bit Windows]] and [[Wi-Fi Protected Access]] support, manufacturers are likely try to save on development cost for hardware which they are no longer selling, and try to get more sales from new "IPv6-ready" equipment. Even when chipset makers develop new drivers for their chipsets, device manufacturers might not pass these on to the consumers. Moreover, as IPv6 gets implemented, optional features might become really important, such as IPv6 mobile. It is therefore important to check your supplier on its support record, and get guarantees if you can or need to. Examples of equipment which currently usually are not IPv6 ready, are home routers. As for the [[CableLabs]] consortium, the 160 Mbit/s [[DOCSIS]] 3.0 IPv6-ready specification for [[cable modem]]s has only been issued in August 2006. IPv6 capable Docsis 2.0b was skipped while the widely used Docsis 2.0 does not support IPv6. The new 'DOCSIS 2.0 + IPv6' standard also supports IPv6, which may on the cable modem side only require a firmware upgrade [http://www.cablemodem.com/specifications/specifications20.html] [http://www.rmv6tf.org/2008-IPv6-Summit-Presentations/Dan%20Torbet%20-%20IPv6andCablev2.pdf]. . It is expected that only 60% of cable modems' servers and 40% of cable modems will be Docsis 3.0 by 2011 <ref>{{cite press release | title=DOCSIS 3.0 Network Equipment Penetration to Reach 60% by 2011 | publisher=ABI Research | date=2007-08-23 | url=http://www.abiresearch.com/abiprdisplay.jsp?pressid=710 | language=English | accessdate=2007-09-30}}</ref>. Other equipment which is typically not IPv6-ready range from [[Skype]] and [[Session Initiation Protocol|SIP]] phones to oscilloscopes and printers. Professional network routers in use should be IPv6-ready. Most personal computers should also be IPv6-ready, because the network stack resides in the operating system. Most applications with network capabilities are not ready, but could be upgraded with support from the developers. Since February 2002, with J2SE 1.4, all applications that are 100% Java have implicit support for IPv6 addresses<ref> {{cite web | title=Networking IPv6 User Guide for JDK/JRE 5.0 | url=http://java.sun.com/j2se/1.5.0/docs/guide/net/ipv6_guide/index.html | accessdate=2007-09-30}}</ref>. For ADSL services, a problem can be that the access networks of the incumbent telephone connection are not IPv6 compatible, such that independent ADSL providers cannot provide native IPv6 connectivity. ==== IPv6 only clients ==== After [[Regional Internet registry|RIR]]s have exhausted their pool of available IPv4 addresses, it is possible that hosts, newly added to the Internet, might only have IPv6 connectivity. For these clients to have backward-compatible connectivity to existing IPv4-only resources, suitable transition technologies must be deployed. Available are IPv4-NAT, which can be used by people owning private IPv4 addresses. Also NAT-PT exists, but is regarded as deprecated and historic. ===Government incentives=== A number of governments, however, are starting to require support for IPv6 in new equipment. The [[Federal government of the United States|U.S. Government]], for example, has specified that the network backbones of all federal agencies had to be upgraded to IPv6 by [[June 30]], [[2008]], which was completed before the deadline.<ref>[http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pdf August 2005 directive from the Office of Management Budget]</ref><ref>[http://www.gcn.com/print/26_03/43045-1.html DOD to allocate its IPv6 addresses]</ref><ref>[http://www.gcn.com/print/26_15/44566-1.html Bitten by IPv6 (correction to the first report)]</ref><ref>[http://www.stsc.hill.af.mil/CrossTalk/2007/07/0707KimMacha.pdf Providing the Tools for Information Sharing]: Net-Centric Enterprise Services (Department of Defense Chief Information Officer Information Policy Directorate)</ref> Their decision should further encourage the private sector and the rest of the World to migrate as well. The [[People's Republic of China]] has a [[Five-Year Plans of China|5 year plan]] for deployment of IPv6 called the ''[[China Next Generation Internet]]''. According to Kshemendra Paul, chief architect at the U.S. Department of Justice, Asia is experiencing a huge demand for addresses and thus is one of the strongest adopters of IPv6.<ref>{{cite web|accessdate=2008-07-14|url=http://www.internetevolution.com/author.asp?section_id=466&doc_id=158680&f_src=flffour|publisher=www.InternetEvolution.com|title=Forward March to IPv6 by 2010|author=Ferraro, Nicole|date=[[July 11]] [[2008]]}}</ref> ===2008 Olympic Games IPv6 showcase=== The 2008 Summer Olympic Games website is operational on the IPv6 Internet at http://ipv6.beijing2008.cn/en (IP address: 2001:252:0:1::2008:6 and 2001:252:0:1::2008:8) and all network operations of the Games will be conducted using IPv6. This event is expected to be the largest showcase of IPv6 technology since the inception of IPv6.<ref>[http://www.ipv6.com/articles/general/IPv6-Olympics-2008.htm IPv6 and the 2008 Beijing Olympics]</ref> ===Current deployment=== {{Expand-section|date=October 2007}} In February 1999, The [[IPv6 Forum]],<ref>[http://www.ipv6forum.org/ The IPv6 Forum]</ref> a world-wide consortium of worldwide leading Internet vendors, industry subject matter experts, research and education networks was founded to promote the IPv6 technology and raise the market and industry awareness. To drive the deployment of IPv6, regional and local IPv6 Task Forces were created.<ref>[http://www.ipv6tf.org/ IPv6 Task Forces]</ref> On 20 July 2004 [[ICANN]] announced that the root DNS servers for the Internet had been upgraded to support both IPv6 and IPv4. The current integration of IPv6 on existing network infrastructures could be monitored from different sources, for example: *Regional Internet Registries (RIR) IPv6 Prefix Allocation<ref>[http://www.ripe.net/rs/ipv6/stats/ IPv6 prefix allocation]</ref> *IPv6 Transit services<ref>[http://www.sixxs.net/faq/connectivity/?faq=ipv6transit IPv6 transit]</ref> *Japan ISP IPv6 services<ref>[http://www.ipv6style.jp/en/statistics/services/index.shtml IPv6 services in Japan]</ref> In addition modern operating systems have IPv6 turned on by default. ===Per country deployment=== ====France==== * AFNIC, the [[Domain name registry|NIC]] for (among others) the [[.fr]] Top Level Domain, has implemented IPv6 operations.<ref>[http://www.afnic.fr/actu/nouvelles/general/NN20060809_en AFNIC full IPv6 ready]</ref> * [[Renater]], the french national academical network, is offering IPv6 connectivity including multicast support to their members. * [[Free (ISP)|Free]], a major French ISP rolled-out IPv6 at end of year 2007<ref>[http://iliad.fr/en/presse/2007/CP_IPv6_121207_eng.pdf IPv6 Rolled-out at ISP Free]</ref>. * [[Orange (brand)|Orange]] has done IPv6 experimentation, official support is still unclear. * [[OVH]] has implemented IPv6.<ref>[http://help.ovh.co.uk/Ipv4Ipv6 OVH : Ipv4Ipv6]</ref> ====Netherlands==== * [[SURFnet|SURFnet]], maintainer of the Dutch academical network SURFnet, introduced IPv6 to its network 1997, in the beginning using IPv6-to-IPv4 tunnels. Currently its backbone is entirely running dual-stack, supporting both native IPv4 and IPv6 to most of its users.<ref>[http://www.ipv6.surfnet.nl/ IPv6 at SURFnet]</ref>. * [[XS4All]], is a major Dutch ISP. In 2002 XS4All was the first Dutch broadband provider to introduce IPv6 to its network.<ref>[http://www.xs4all.nl/allediensten/experimenteel/IPv6.php IPv6 at XS4All]</ref>, but it was only experimental and they disabled that service again. As such they are at the moment (2008) only providing IPv6 with the help of a [[Tunnel Broker|Tunnel Broker]]. * Business-orientated Internet Provider [http://www.bit.nl BIT BV] has been providing IPv6 to all their customers (DSL, FTTH, colocated) since 2004 <ref>[http://www.bit.nl/pdf/media/Computable%20(14-05-04).pdf Computable 2004-05-14]</ref>. * [http://www.sixxs.net SixXS], of which the two founders are Dutch, has been providing IPv6 to users worldwide with tunneled connectivity since 2000, starting out as IPng.nl with a predominantly Dutch user-base. The switch to SixXS was initiated to change to be able to reach users internationally and also to be completely ISP independent.<ref>[http://www.sixxs.net/about/history/ SixXS History]</ref>. SixXS also provides various other sub-projects which contributed significantly to IPv6 adoption and stability globally. ====United Kingdom==== *[[JANET]], the UK's education and research network, is introducing IPv6 unicast support into its service level agreement by August 2008<ref>[http://www.webarchive.ja.net/development/ipv6/ JANET AND IPv6]</ref>. Several major UK universities (e.g., [[University of Cambridge|Cambridge]]) are upgrading their campus routing infrastructure during summer 2008 to provide IPv6 unicast support to their users. ====Other Countries==== {{Expand-section|date=April 2008}} ==Addressing== [[Image:Internet address spaces.svg|thumb|right|400px|Internet addressing growth map.]] ===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<sup>38</sup> 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, where each group is separated by a colon (:). 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. i.e., Given 2001:0000:0000:FFD3:0000:0000:0000:57ab, 2001::FFD3::57ab could imply 2001:0000:0000:0000:0000:FFD3:0000:57ab, 2001:0000:FFD3:0000:0000:0000:0000:57ab, or any other similar permutation. 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). This addressing scheme is convenient when dealing with the mixed environment of IPv4 and IPv6 addresses. The general notation is of the form x:x:x:x:x:x:d.d.d.d where the x's are the 6 higher order groups of hexadecimal digits whereas the d's correspond to the decimal digits of lower order [[Octet (computing)|octets]] of the address, as it is in the IPv4 format. For example, <tt>::ffff:12.34.56.78</tt> is the same address as <tt>::ffff:0c22:384e</tt> and <tt>0:0:0:0:0:ffff:0c22:384e</tt>. Usage of this notation is deprecated and unsupported by numerous applications. 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:7348]/</nowiki> This notation allows [[parsing]] a URL without confusing the IPv6 address and port number: <nowiki>https://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/</nowiki> This is not only useful but mandated when using shortform: <nowiki>https://[2001:db8::1428:57ab]: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, host addresses are sometimes followed with /128. ===Kinds of IPv6 addresses=== IPv6 addresses are divided into 3 types:<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 identifies a single network interface. A packet sent to a unicast address is delivered to that specific computer. The following types of addresses are unicast IPv6 addresses: *Global unicast addresses *Link-local addresses *[[Unique local address|Unique local IPv6 unicast addresses]] [[Multicast]] addresses are assigned to a set of interfaces that typically belong to different nodes. A packet that is sent to a multicast address is delivered to all the 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 (0x2), site-local (0x5) and global (0xE). [[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: ;Link local * <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>fe80::/10</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. ;Site local * <tt>fc00::/7</tt> &mdash; [[unique local address]]es (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. ;IPv4 * <tt>::ffff:0:0/96</tt> &mdash; this prefix is used for [[IPv4 mapped address]]es (see ''Transition mechanisms'' below). * <tt>2002::/16</tt> &mdash; this prefix is used for [[6to4]] addressing. ;Multicast * <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 in "IP Version 6 Addressing Architecture" (RFC 4291). ;Used in examples, deprecated, or obsolete * <tt>::/96</tt> &mdash; the zero prefix was used for [[IPv4-compatible address]]es; it is now obsolete. * <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>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. ;Teredo * <tt>2001::/32</tt> &mdash; Used for [[Teredo tunneling]]. ;ORCHID * <tt>2001:10::/28</tt> &mdash; ORCHID (Overlay Routable Cryptographic Hash Identifiers) as per (RFC 4843). These are non-routed IPv6 addresses used for Cryptographic Hash Identifiers. rfc There is no 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 4862): <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 its own problems because of clashing with the [[percent-encoding]] used with URIs.<ref>[http://tools.ietf.org/html/draft-fenner-literal-zone-02 Formats for IPv6 Scope Zone Identifiers in Literal Address Formats]</ref> * 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 GNU/Linux network interface configuration utilities, such as [[ifconfig]] and [[iproute2]], do not display zone IDs. <!-- TODO: Mac OS? Solaris? NetWare? HP-UX? AIX? --> Relatively few [[Comparison of IPv6 application support|IPv6-capable applications]] understand zone ID syntax, thus rendering link-local addresses unusable within them if multiple interfaces use link-local addresses. ==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]] (320 bits) of the packet and contains: * Version - version 6 (4-bit IP version). * Traffic class - packet priority (8-bits). Priority values are divided into ranges: traffic where the source provides congestion control and non-congestion control traffic. * Flow label - [[quality of service|QoS]] management (20 bits). Originally created for giving [[real-time|real-time applications]] special service, but currently unused. * Payload length - payload length in bytes (16 bits). When cleared to zero, the option is a "[[Jumbo payload]]" (hop-by-hop). * Next header - Specifies the next encapsulated protocol. The values are compatible with those specified for the IPv4 protocol field (8 bits). * Hop limit - replaces the [[time to live]] field of IPv4 (8 bits). * Source and destination addresses - 128 bits each. 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=== * RFC 2874 - DNS Extensions to Support IPv6 Address Aggregation and Renumbering - Defines the A6 record * RFC 3364 - Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) * RFC 3484 - Default Address Selection for Internet Protocol version 6 (IPv6) * RFC 3513 - Internet Protocol Version 6 (IPv6) Addressing Architecture * RFC 3596 - DNS Extensions to Support IP Version 6 - Defines the AAAA record and obsoletes RFC 1886 and RFC 3152 ==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 transition mechanisms mentioned below. ===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 known as ''[[tunneling protocol|tunneling]]'' which consists of 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]] tunneling, which uses protocol 41 encapsulation.<ref name=rfc3056>RFC 3056: Connection of IPv6 Domains via IPv4 Clouds</ref> 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>RFC 4214: Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)</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]]'' is an automatic tunneling technique that uses UDP encapsulation and is claimed to be able to cross multiple NAT boxes.<ref name=rfc4380>RFC 4380: Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)</ref> 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]] and [[Mac OS X]] Leopard and Apple's AirPort Extreme.<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>RFC 3053: IPv6 Tunnel Broker</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 uses protocol 41 in the Protocol field of the IPv4 packet. This method is also known as [[6in4]]. ===Proxying and translation=== {{Main|IPv6 translation mechanisms}} When an IPv6-only host needs to access an IPv4-only service (for example a web server), some form of translation is necessary. One form of translation is the use of a dual-stack [[proxy server|application-layer proxy]], for example a web proxy. NAT-like techniques for application-agnostic translation at the lower layers have also been proposed. Most have been found to be too unreliable in practice because of the wide range of functionality required by common application-layer protocols, and are considered by many to be obsolete. ==Major IPv6 announcements and availability== {| class="wikitable" |- ! '''Year''' || '''Announcements and availability''' |- | '''1996''' | [[Linux]] gains [[alpha software|alpha quality]] IPv6 support in [[Linux kernel|kernel]] development version 2.1.8.<ref name=linuxIPv6>[http://www.linux-ipv6.org/stable-6-ann.html Linux IPv6 Development Project]</ref> |- | rowspan=2 valign="center" | '''1997''' | In the end of [[1997]], a large number of implementations existed and were interoperable. <ref name=IETF97dec>[http://www.ietf.org/proceedings/97dec/97dec-final-53.htm IETF December 1997 Proceedings]</ref><ref name=IETFimplrep>[http://www.ietf.org/IESG/Implementations/ipv6-implementations.txt IESG: Implementation Report]</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> |- | '''1998''' | [[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 was not intended for use in a production environment. |- | rowspan=3 valign="center" | '''2000''' | 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> |- | Microsoft releases an IPv6 technology preview version for [[Windows 2000]] in March 2000.<ref name=microsoftIPv6/> |- | [[Sun Microsystems|Sun]] [[Solaris Operating System|Solaris]] has IPv6 support since Solaris 8 in February 2000.<ref name=SunSolarisIPv6>[http://www.ocf.berkeley.edu/solaris/versions/solaris/8.html Sun Solaris 8 changes from Solaris 7]</ref> |- | '''2001''' | [[Cisco Systems]] introduced IPv6 support on [[Cisco IOS]] routers and L3 switches in 2001.<ref name=CiscoIPv6>[http://www.cisco.com/en/US/products/ps6553/products_ios_technology_home.html Cisco main IPv6 site]</ref> |- | rowspan=3 valign="center" | '''2002''' | [[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> |- | IBM [[z/OS]] has supported IPv6 since version 1.4 that has been generally available since September 2002.<ref name="ibmzos">[http://www-03.ibm.com/servers/eserver/zseries/announce/zos_r4/ IBM: z/OS operating system<!-- Bot generated title -->]</ref> |- | rowspan=2 valign="center" | '''2003''' | [[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> |- | In July, [[ICANN]] announced 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. |- | '''2005''' | [[Linux]] 2.6.12 removes IPv6's "experimental" status.<ref name=linuxIPv6_2612>[http://kernelnewbies.org/Linux_2_6_12 Linux 2.6.12 changelog]</ref> |- | rowspan=2 valign="center" | '''2007''' | Microsoft [[Windows Vista]] (2007) has IPv6 supported and enabled by default.<ref name="microsoft1"/> |- | 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> |- | rowspan=2 valign="center" | '''2008''' | On February 4th 2008, IANA added AAAA records for the IPv6 addresses of six of the thirteen root name servers.<ref>[http://arstechnica.com/news.ars/post/20080102-icann-to-add-ipv6-addresses-for-root-dns-servers.html IPv6: coming to a root server near you]</ref><ref>[http://www.iana.org/reports/root-aaaa-announcement.html IANA - IPv6 Addresses for the Root Servers]</ref> With this transition, it is now possible for two internet hosts to communicate via DNS without using IPv4 at all. |- | On March 12th, 2008, [[Google]] launched an IPv6 version of www.google.com, the most visited page on the Internet, under an alternative host name ([http://ipv6.google.com/ ipv6.google.com]).<ref name=GoogleIPv6>[http://googleblog.blogspot.com/2008/05/looking-towards-ipv6.html Google - Looking Towards IPv6.]</ref> |} == Disabling == Various forums on the Internet carry reports of people disabling IPv6 because of perceived slowdowns when connecting to hosts on the Internet. This happens because of [[Domain Name System|DNS]] resolver issues. This "slow-down" results from DNS resolution failures due to broken NAT 'routers' and other DNS resolvers which don't know how to handle the [[AAAA record|AAAA]] DNS query. These DNS resolvers just drop the DNS query request for the AAAA record, instead of returning the appropriate negative DNS response. Because the request is dropped, the host sending the request has to time out, thus causing a perceived slow down when connecting to new hosts. Note that DNS queries happen over any transport available (IPv4, if only protocol); the transport is independent from the type of query. == IPv6 Test and Evaluation == A few international organizations are involved with IPv6 test and evaluation ranging from the United States Department of Defense to the University of New Hampshire. * The US DoD [[Joint Interoperability Test Command]] [[DoD IPv6 Product Certification]] Program * [[University of New Hampshire InterOperability Laboratory]] involvement in the IPv6 Ready Logo Program[http://www.ipv6ready.org] * [[SATSIX]] ==See also== * [[ICMPv6|ICMP for IPv6]] * [[Comparison of IPv6 application support]] * [[Miredo]] - [[Teredo tunneling|Teredo]] implementation, allowing IPv6 access from behind [[Network address translation|NAT]]. * [[China Next Generation Internet]] * [[IPv9]]: purported Chinese IPv6-variant from 2004. * [[List of IPv6 tunnel brokers]] * [http://www.sixxs.net/wiki/Routers A list of residential routers supporting IPv6] ==References== {{reflist|colwidth=30em}} ==Standards== ===Core specifications=== * RFC 2460: Internet Protocol, Version 6 (IPv6) Specification (obsoletes RFC 1883) * RFC 4861: Neighbor Discovery for IP Version 6 (IPv6), obsoletes RFC 2461 * RFC 4862: IPv6 Stateless Address Autoconfiguration, obsoletes RFC 2462 * RFC 4311: IPv6 Host-to-Router Load Sharing, updates RFC 2461 * 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 3587: An IPv6 Aggregatable Global Unicast Address Format ===Stateless autoconfiguration=== * RFC 4861: Neighbor Discovery for IP Version 6 (IPv6), obsoletes RFC 2461 * RFC 4862: IPv6 Stateless Address Autoconfiguration, obsoletes RFC 2462 * RFC 4941: Privacy Extensions for Stateless Address Autoconfiguration in IPv6, obsoletes RFC 3041 ===Addressing=== * RFC 4291: IP Version 6 Addressing Architecture (obsoletes RFC 3513) * RFC 3587: IPv6 Global Unicast Address Format (obsoletes RFC 2374) * RFC 4193: Unique Local IPv6 Unicast Addresses * RFC 3879: Deprecating Site Local Addresses * RFC 4007: IPv6 Scoped Address Architecture ===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) ==External links== * {{dmoz|Computers/Internet/Protocols/IP/IPv6/}} * [http://arstechnica.com/articles/paedia/IPv6.ars Everything you need to know about IPv6] from Ars Technica * [http://ipv6.nlsde.buaa.edu.cn IPv6 Backbone Network Topology] * [http://www.ict.tuwien.ac.at/skripten/datenkomm/infobase/L80-IPv6_v4-5.pdf Data Communication Lectures of Manfred Lindner - Part IPv6] * [http://www.ipv6.com IPv6.com Next Generation Internet] ===Related IETF working groups=== * [http://www.ietf.org/html.charters/6man-charter.html 6man] IPv6 Maintenance * [http://www.ietf.org/html.charters/6lowpan-charter.html 6lowpan] IPv6 over Low power WPAN * [http://www.ietf.org/html.charters/HISTORY/multi6-charter.2006-12-27.15.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]] [[Category:Internet Protocol]] [[Category:Internet Layer protocols]] [[Category:Network layer protocols]] [[ar:IPv6]] [[bs:IPv6]] [[bg:IPv6]] [[ca:IPv6]] [[cs:IPv6]] [[da:IPv6]] [[de:IPv6]] [[es:IPv6]] [[eu:IPv6]] [[fr:IPv6]] [[gl:Protocolo IPv6]] [[ko:IPv6]] [[id:Alamat IP versi 6]] [[is:IPv6]] [[it:IPv6]] [[he:IPv6]] [[hu:IPv6]] [[mk:IPv6]] [[nl:Internet Protocol Version 6]] [[ja:IPv6]] [[no:IPv6]] [[nn:IPv6]] [[pl:IPv6]] [[pt:IPv6]] [[ru:IPv6]] [[sk:IPv6]] [[sl:IPv6]] [[fi:IPv6]] [[sv:IPv6]] [[tr:IPv6]] [[uk:IPv6]] [[zh:IPv6]]