Internet Protocol version 6 (IPv6) is the most recent version of the
Internet Protocol (IP), the communications protocol that provides an
identification and location system for computers on networks and
routes traffic across the Internet.
IPv6 was developed by the Internet
Engineering Task Force (IETF) to deal with the long-anticipated
IPv4 address exhaustion.
IPv6 is intended to replace
IPv6 became a Draft Standard in December 1998, but did not
formally become an
Internet Standard until 14 July 2017.
Every device on the
Internet is assigned a unique
IP address for
identification and location definition. With the rapid growth of the
Internet after commercialization in the 1990s, it became evident that
far more addresses would be needed to connect devices than the IPv4
address space had available. By 1998, the
Internet Engineering Task
Force (IETF) had formalized the successor protocol.
IPv6 uses a
128-bit address, theoretically allowing 2128, or approximately
7038340000000000000♠3.4×1038 addresses. The actual number is
slightly smaller, as multiple ranges are reserved for special use or
completely excluded from use. The total number of possible IPv6
addresses is more than 7028790000000000000♠7.9×1028 times as many
as IPv4, which uses 32-bit addresses and provides approximately 4.3
billion addresses. The two protocols are not designed to be
interoperable, complicating the transition to IPv6. However, several
IPv6 transition mechanisms
IPv6 transition mechanisms have been devised to permit communication
IPv6 provides other technical benefits in addition to a larger
addressing space. In particular, it permits hierarchical address
allocation methods that facilitate route aggregation across the
Internet, and thus limit the expansion of routing tables. The use of
multicast addressing is expanded and simplified, and provides
additional optimization for the delivery of services. Device mobility,
security, and configuration aspects have been considered in the design
of the protocol.
IPv6 addresses are represented as eight groups of four hexadecimal
digits with the groups being separated by colons, for example
2001:0db8:0000:0042:0000:8a2e:0370:7334, but methods to abbreviate
this full notation exist.
1 Main features
2 Motivation and origin
2.2 Working-group proposals
3 Comparison with IPv4
3.1 Larger address space
3.3 Stateless address autoconfiguration (SLAAC)
3.4 Network-layer security
3.5 Simplified processing by routers
3.7 Options extensibility
4 Packet format
5.1 Address representation
5.2 Address uniqueness
5.3 Link-local address
5.4 Global addressing
IPv6 in the Domain Name System
7 Transition mechanisms
7.1 Dual-stack IP implementation
7.2.1 Automatic tunneling
7.2.2 Configured and automated tunneling (6in4)
7.3 Proxying and translation for IPv6-only hosts
8.2 Hardware and embedded systems
8.3 Shadow networks
11 See also
13 External links
Decomposition of the
IPv6 address representation into its binary form
IPv6 is an
Internet Layer protocol for packet-switched internetworking
and provides end-to-end datagram transmission across multiple IP
networks, closely adhering to the design principles developed in the
previous version of the protocol,
Internet Protocol Version 4 (IPv4).
IPv6 was first formally described in
Internet standard document
RFC 1883, published in December 1995. That RFC was obsoleted
and replaced by RFC 2460, published in December 1998. In July
2017 this specification was obsoleted and replaced by RFC 8200.
In addition to offering more addresses,
IPv6 also implements features
not present in IPv4. It simplifies aspects of address assignment
(stateless address autoconfiguration), network renumbering, and router
announcements when changing network connectivity providers. It
simplifies processing of packets in routers by placing the
responsibility for packet fragmentation into the end points. The IPv6
subnet size is standardized by fixing the size of the host identifier
portion of an address to 64 bits to facilitate an automatic mechanism
for forming the host identifier from link layer addressing information
Network security was a design requirement of the IPv6
architecture, and included the original specification of IPsec.
IPv6 does not specify interoperability features with IPv4, but
essentially creates a parallel, independent network. Exchanging
traffic between the two networks requires translator gateways
employing one of several transition mechanisms, such as NAT64, or a
tunneling protocol like 6to4, 6in4, or Teredo.
Motivation and origin
Decomposition of the quad-dotted
IPv4 address representation to its
Internet Protocol Version 4 (IPv4) was the first publicly used version
IPv4 was developed as a research project by
the Defense Advanced Research Projects Agency (DARPA), a United States
Department of Defense agency, before becoming the foundation for the
Internet and the World Wide Web. It is currently described by IETF
publication RFC 791 (September 1981), which replaced an earlier
definition (RFC 760, January 1980).
IPv4 included an addressing
system that used numerical identifiers consisting of 32 bits. These
addresses are typically displayed in quad-dotted notation as decimal
values of four octets, each in the range 0 to 255, or 8 bits per
IPv4 provides an addressing capability of 232 or
approximately 4.3 billion addresses. Address exhaustion was not
initially a concern in
IPv4 as this version was originally presumed to
be a test of DARPA's networking concepts. During the first decade
of operation of the Internet, it became apparent that methods had to
be developed to conserve address space. In the early 1990s, even after
the redesign of the addressing system using a classless network model,
it became clear that this would not suffice to prevent
exhaustion, and that further changes to the
The last unassigned top-level address blocks of 16 million IPv4
addresses were allocated in February 2011 by the
Numbers Authority (IANA) to the five regional
(RIRs). However, each RIR still has available address pools and is
expected to continue with standard address allocation policies until
Classless Inter-Domain Routing
Classless Inter-Domain Routing (CIDR) block remains. After
that, only blocks of 1024 addresses (/22) will be provided from the
RIRs to a local
Internet registry (LIR). As of September 2015, all of
Asia-Pacific Network Information Centre
Asia-Pacific Network Information Centre (APNIC), the Réseaux IP
Européens Network Coordination Centre (RIPE_NCC), Latin America and
Caribbean Network Information Centre (LACNIC), and American Registry
Internet Numbers (ARIN) have reached this stage. This
leaves African Network Information Center (AFRINIC) as the sole
regional internet registry that is still using the normal protocol for
By the beginning of 1992, several proposals appeared for an expanded
Internet addressing system and by the end of 1992 the
IETF announced a
call for white papers. In September 1993, the
IETF created a
temporary, ad-hoc IP Next Generation (IPng) area to deal specifically
with such issues. The new area was led by Allison Mankin and Scott
Bradner, and had a directorate with 15 engineers from diverse
backgrounds for direction-setting and preliminary document
review: The working-group members were
J. Allard (Microsoft),
Steve Bellovin (AT&T), Jim Bound (Digital Equipment Corporation),
Ross Callon (Wellfleet), Brian Carpenter (CERN), Dave Clark (MIT),
John Curran (NEARNET),
Steve Deering (Xerox), Dino Farinacci (Cisco),
Paul Francis (NTT), Eric Fleischmann (Boeing), Mark Knopper
(Ameritech), Greg Minshall (Novell), Rob Ullmann (Lotus), and Lixia
Internet Engineering Task Force adopted the IPng model on 25 July
1994, with the formation of several IPng working groups. By 1996, a
series of RFCs was released defining
Internet Protocol version 6
(IPv6), starting with RFC 1883. (Version 5 was used by the
Internet Stream Protocol.)
It is widely expected that the
Internet will use
IPv4 alongside IPv6
for the foreseeable future. Direct communication between the
IPv6 network protocols is not possible; therefore, intermediary
trans-protocol systems are needed as a communication conduit between
IPv6 whether on a single device or among network nodes.
Comparison with IPv4
On the Internet, data is transmitted in the form of network packets.
IPv6 specifies a new packet format, designed to minimize packet header
processing by routers. Because the headers of
IPv4 packets and
IPv6 packets are significantly different, the two protocols are not
interoperable. However, in most respects,
IPv6 is an extension of
IPv4. Most transport and application-layer protocols need little or no
change to operate over IPv6; exceptions are application protocols that
embed Internet-layer addresses, such as
File Transfer Protocol
File Transfer Protocol (FTP)
Network Time Protocol
Network Time Protocol (NTP), where the new address format may
cause conflicts with existing protocol syntax.
Larger address space
The main advantage of
IPv4 is its larger address space. The
length of an
IPv6 address is 128 bits, compared with 32 bits in
IPv4. The address space therefore has 2128 or approximately
In addition, the
IPv4 address space is poorly allocated; in 2011,
approximately 14% of all available addresses were utilized. While
these numbers are large, it was not the intent of the designers of the
IPv6 address space to assure geographical saturation[clarification
needed] with usable addresses. Rather, the longer addresses simplify
allocation of addresses, enable efficient route aggregation, and allow
implementation of special addressing features. In IPv4, complex
Classless Inter-Domain Routing
Classless Inter-Domain Routing (CIDR) methods were developed to make
the best use of the small address space. The standard size of a subnet
IPv6 is 264 addresses, the square of the size of the entire IPv4
address space. Thus, actual address space utilization rates will be
small in IPv6, but network management and routing efficiency are
improved by the large subnet space and hierarchical route aggregation.
Renumbering an existing network for a new connectivity provider with
different routing prefixes is a major effort with IPv4. With
IPv6, however, changing the prefix announced by a few routers can in
principle renumber an entire network, since the host identifiers (the
least-significant 64 bits of an address) can be independently
self-configured by a host.
Multicasting, the transmission of a packet to multiple destinations in
a single send operation, is part of the base specification in IPv6. In
IPv4 this is an optional although commonly implemented feature.
IPv6 multicast addressing shares common features and protocols with
IPv4 multicast, but also provides changes and improvements by
eliminating the need for certain protocols.
IPv6 does not implement
traditional IP broadcast, i.e. the transmission of a packet to all
hosts on the attached link using a special broadcast address, and
therefore does not define broadcast addresses. In IPv6, the same
result can be achieved by sending a packet to the link-local all nodes
multicast group at address ff02::1, which is analogous to IPv4
multicasting to address 220.127.116.11.
IPv6 also provides for new
multicast implementations, including embedding rendezvous point
addresses in an
IPv6 multicast group address, which simplifies the
deployment of inter-domain solutions.
IPv4 it is very difficult for an organization to get even one
globally routable multicast group assignment, and the implementation
of inter-domain solutions is arcane.
Unicast address assignments
by a local
Internet registry for
IPv6 have at least a 64-bit routing
prefix, yielding the smallest subnet size available in
IPv6 (also 64
bits). With such an assignment it is possible to embed the unicast
address prefix into the
IPv6 multicast address format, while still
providing a 32-bit block, the least significant bits of the address,
or approximately 4.2 billion multicast group identifiers. Thus each
user of an
IPv6 subnet automatically has available a set of globally
routable source-specific multicast groups for multicast
Stateless address autoconfiguration (SLAAC)
IPv6 address § Stateless address autoconfiguration
IPv6 hosts can configure themselves automatically when connected to an
IPv6 network using the
Neighbor Discovery Protocol via Internet
Control Message Protocol version 6 (ICMPv6) router discovery messages.
When first connected to a network, a host sends a link-local router
solicitation multicast request for its configuration parameters;
routers respond to such a request with a router advertisement packet
Internet Layer configuration parameters.
IPv6 stateless address auto-configuration is unsuitable for an
application, a network may use stateful configuration with the Dynamic
Host Configuration Protocol version 6 (DHCPv6) or hosts may be
configured manually using static methods.
Routers present a special case of requirements for address
configuration, as they often are sources of autoconfiguration
information, such as router and prefix advertisements. Stateless
configuration of routers can be achieved with a special router
Internet Protocol Security (IPsec) was originally developed for IPv6,
but found widespread deployment first in IPv4, for which it was
IPsec was a mandatory specification of the base IPv6
protocol suite, but has since been made optional.
Simplified processing by routers
In IPv6, the packet header and the process of packet forwarding have
been simplified. Although
IPv6 packet headers are at least twice the
IPv4 packet headers, packet processing by routers is generally
more efficient, because less processing is required in routers due to
the headers being aligned to match common word sizes. Moreover,
IPv6 doesn't implement a header checksum, in contrast to IPv4. This
furthers the end-to-end principle of
Internet design, which envisioned
that most processing in the network occurs in the leaf nodes.
The packet header in
IPv6 is simpler than the
IPv4 header. Many rarely
used fields have been moved to optional header extensions.
IPv6 routers do not perform IP fragmentation.
IPv6 hosts are required
to either perform path MTU discovery, perform end-to-end
fragmentation, or to send packets no larger than the default Maximum
transmission unit (MTU), which is 1280 octets.
IPv6 header is not protected by a checksum. Integrity protection
is assumed to be assured by both the link layer or error detection and
correction methods in higher-layer protocols, such as TCP and UDP. In
IPv4, UDP may actually have a checksum of 0, indicating no checksum;
IPv6 requires a checksum in UDP. Therefore,
IPv6 routers do not need
to recompute a checksum when header fields change, such as the time to
live (TTL) or hop count.
The TTL field of
IPv4 has been renamed to Hop Limit in IPv6,
reflecting the fact that routers are no longer expected to compute the
time a packet has spent in a queue.
Unlike mobile IPv4, mobile
IPv6 avoids triangular routing and is
therefore as efficient as native IPv6.
IPv6 routers may also allow
entire subnets to move to a new router connection point without
IPv6 packet header has a minimum size of 40 octets. Options are
implemented as extensions. This provides the opportunity to extend the
protocol in the future without affecting the core packet structure.
However, a study in 2015 indicated that there was still widespread
IPv6 packets containing extension headers.
IPv4 limits packets to 65,535 (216−1) octets of payload. An IPv6
node can optionally handle packets over this limit, referred to as
jumbograms, which can be as large as 4,294,967,295 (232−1) octets.
The use of jumbograms may improve performance over high-MTU links. The
use of jumbograms is indicated by the Jumbo Payload Option header.
IPv6 supports globally unique IP addresses by which the
network activity of each device can potentially be tracked. The design
IPv6 intended to re-emphasize the end-to-end principle of network
design that was originally conceived during the establishment of the
early Internet. In this approach each device on the network has a
unique address globally reachable directly from any other location on
Network prefix tracking is less of a concern if the user's ISP assigns
a dynamic network prefix via DHCP. Privacy extensions do
little to protect the user from tracking if the ISP assigns a static
network prefix. In this scenario, the network prefix is the unique
identifier for tracking and the interface identifier is secondary.
IPv4 the effort to conserve address space with network address
translation (NAT) obfuscates network address spaces, hosts, and
IPv6 when using address auto-configuration, the
Interface Identifier (MAC address) of an interface port is used to
make its public
IP address unique, exposing the type of hardware used
and providing a unique handle for a user's online activity.
It is not a requirement for
IPv6 hosts to use address
auto-configuration, however. Yet, even when an address is not based on
the MAC address, the interface's address is globally unique, in
contrast to NAT-masqueraded private networks. Privacy extensions for
IPv6 have been defined to address these privacy concerns, although
Silvia Hagen describes these as being largely due to
"misunderstanding". When privacy extensions are enabled, the
operating system generates random host identifiers to combine with the
assigned network prefix. These ephemeral addresses are used to
communicate with remote hosts making it more difficult to track a
Privacy extensions are enabled by default in Windows (since XP SP1),
OS X (since 10.7), and iOS (since version 4.3). Some Linux
distributions have enabled privacy extensions as well.
In addition to the temporary address assignments, interfaces also
receive a stable address. Interface Identifiers are generated such
that they are stable for each subnet, but change as a host moves from
one network to another. In this way it is difficult to track a host as
it moves from network to network, but within a particular network it
will always have the same address (unless the state used in generating
the address is reset and the algorithm is run again) so that network
access controls and auditing can potentially be configured.
The traditional method of generating interface identifiers in use for
unique address assignments was based on MAC addressing. In favor of
better privacy protection, this method has been deprecated in some
operating systems with newly established methods of RFC 7217.
Privacy extensions do not protect the user from other forms of
tracking at other layers, e.g. Application Layer: tracking cookies or
browser fingerprinting and Link Layer:
IMSI-catcher or iBeacon
IPv6 packet header
IPv6 packet has two parts: a header and payload.
The header consists of a fixed portion with minimal functionality
required for all packets and may be followed by optional extensions to
implement special features.
The fixed header occupies the first 40 octets (320 bits) of the
IPv6 packet. It contains the source and destination addresses, traffic
classification options, a hop counter, and the type of the optional
extension or payload which follows the header. This Next Header field
tells the receiver how to interpret the data which follows the header.
If the packet contains options, this field contains the option type of
the next option. The "Next Header" field of the last option, points to
the upper-layer protocol that is carried in the packet's payload.
Extension headers carry options that are used for special treatment of
a packet in the network, e.g., for routing, fragmentation, and for
security using the
Without special options, a payload must be less than 64KB. With a
Jumbo Payload option (in a Hop-By-Hop Options extension header), the
payload must be less than 4 GB.
Unlike with IPv4, routers never fragment a packet. Hosts are expected
Path MTU Discovery to make their packets small enough to reach
the destination without needing to be fragmented. See
IPv6 addresses have 128 bits. The design of the
IPv6 address space
implements a very different design philosophy than in IPv4, in which
subnetting was used to improve the efficiency of utilization of the
small address space. In IPv6, the address space is deemed large enough
for the foreseeable future, and a local area subnet always uses 64
bits for the host portion of the address, designated as the interface
identifier, while the most-significant 64 bits are used as the routing
The identifier is only unique within the subnet to which a host is
IPv6 has a mechanism for automatic address detection,
so that address autoconfiguration always produces unique assignments.
The 128 bits of an
IPv6 address are represented in 8 groups of 16 bits
each. Each group is written as four hexadecimal digits (sometimes
called hextets) and the groups are separated by colons (:). An
example of this representation is
For convenience, an
IPv6 address may be abbreviated to shorter
notations by application of the following rules.
One or more leading zeroes from any groups of hexadecimal digits are
removed; this is usually done to either all or none of the leading
zeroes. For example, the group 0042 is converted to 42.
Consecutive sections of zeroes are replaced with a double colon (::).
The double colon may only be used once in an address, as multiple use
would render the address indeterminate. RFC 5952 recommends that
a double colon not be used to denote an omitted single section of
An example of application of these rules:
Initial address: 2001:0db8:0000:0000:0000:ff00:0042:8329
After removing all leading zeroes in each group:
After omitting consecutive sections of zeroes: 2001:db8::ff00:42:8329
The loopback address, 0000:0000:0000:0000:0000:0000:0000:0001, may be
abbreviated to ::1 by using both rules.
IPv6 address may have more than one representation, the
issued a proposed standard for representing them in text.
Hosts verify the uniqueness of addresses assigned by sending a
neighbor solicitation message asking for the Link Layer address of the
IP address. If any other host is using that address, it responds.
However, MAC addresses are designed to be unique on each network card
which minimizes chances of duplication.
The host first determines if the network is connected to any routers
at all, because if not, then all nodes are reachable using the
link-local address that already is assigned to the host. The host will
send out a Router Solicitation message to the all-routers
multicast group with its link-local address as source. If there is no
answer after a predetermined number of attempts, the host concludes
that no routers are connected. If it does get a response from a
router, there will be network information inside that is needed to
create a globally unique address. There are also two flag bits that
tell the host whether it should use DHCP to get further information
The Manage bit, that indicates whether or not the host should use DHCP
to obtain additional addresses
The Other bit, that indicates whether or not the host should obtain
other information through DHCP. The other information consists of one
or more prefix information options for the subnets that the host is
attached to, a lifetime for the prefix, and two flags:
On-link: If this flag is set, the host will treat all addresses on the
specific subnet as being on-link, and send packets directly to them
instead of sending them to a router for the duration of the given
Address: This is the flag that tells the host to actually create a
All interfaces of
IPv6 hosts require a link-local address. A
link-local address is derived from the
MAC address of the interface
and the prefix fe80::/10. The process involves filling the address
space with prefix bits left-justified to the most-significant bit, and
MAC address in EUI-64 format into the least-significant
bits. If any bits remain to be filled between the two parts, those are
set to zero.
The uniqueness of the address on the subnet is tested with the
Duplicate Address Detection (DAD) method.
The assignment procedure for global addresses is similar to local
address construction. The prefix is supplied from router
advertisements on the network. Multiple prefix announcements cause
multiple addresses to be configured.
Stateless address autoconfiguration (SLAAC) requires a /64 address
block, as defined in RFC 4291. Local
Internet registries are
assigned at least /32 blocks, which they divide among subordinate
networks. The initial recommendation stated assignment of a /48
subnet to end-consumer sites (RFC 3177). This was replaced by
RFC 6177, which "recommends giving home sites significantly more
than a single /64, but does not recommend that every home site be
given a /48 either". /56s are specifically considered. It remains to
be seen if ISPs will honor this recommendation. For example, during
Comcast customers were given a single /64 network.
IPv6 addresses are classified by three types of networking
methodologies: unicast addresses identify each network interface,
anycast addresses identify a group of interfaces, usually at different
locations of which the nearest one is automatically selected, and
multicast addresses are used to deliver one packet to many interfaces.
The broadcast method is not implemented in IPv6. Each
IPv6 address has
a scope, which specifies in which part of the network it is valid and
unique. Some addresses are unique only on the local (sub-)network.
Others are globally unique.
IPv6 addresses are reserved for special purposes, such as
6to4 tunneling, and Teredo tunneling, as outlined in
RFC 5156. Also, some address ranges are considered special, such
as link-local addresses for use on the local link only, Unique local
addresses (ULA), as described in RFC 4193, and solicited-node
multicast addresses used in the Neighbor Discovery Protocol.
IPv6 in the Domain Name System
In the Domain Name System, hostnames are mapped to
IPv6 addresses by
AAAA resource records, so-called quad-A records. For reverse
IETF reserved the domain ip6.arpa, where the name
space is hierarchically divided by the 1-digit hexadecimal
representation of nibble units (4 bits) of the
IPv6 address. This
scheme is defined in RFC 3596.
At the design stage of the
IPv6 DNS architecture, the AAAA scheme
faced a rival proposal. This alternate approach, designed to
facilitate network renumbering, uses A6 records for the forward lookup
and a number of other innovations such as bit-string labels and DNAME
records. It is defined in RFC 2874 and its references (with
further discussion of the pros and cons of both schemes in
RFC 3364), but has been deprecated to experimental status
IPv6 transition mechanism
IPv6 is not foreseen to supplant
IPv4 instantaneously. Both protocols
will continue to operate simultaneously for some time. Therefore, some
IPv6 transition mechanisms
IPv6 transition mechanisms are needed to enable
IPv6 hosts to reach
IPv4 services and to allow isolated
IPv6 hosts and networks to reach
each other over
Many of these transition mechanisms use tunneling to encapsulate IPv6
IPv4 networks. This is an imperfect solution, which
reduces the maximum transmission unit (MTU) of a link and therefore
complicates Path MTU Discovery, and may increase latency.
Tunneling protocols are a temporary solution for networks that do not
support native dual-stack, where both
IPv4 run independently.
Dual-stack IP implementation
Dual-stack IP implementations provide complete
stacks in the same network node on top of common physical layer
implementation, such as Ethernet. This permits dual-stack hosts to
IPv4 networks simultaneously. The method is
defined in RFC 4213.
Dual-stack configuration is the most desirable
during the transition from
IPv4 to IPv6, as it avoids the complexities
of tunneling and security considerations, increased latency,
management overhead, and a reduced path MTU. However, it is not
always possible when outdated network equipment may not support IPv6.
Dual-stack configurations, however, might introduce additional
security issues as hosts could be subject to attacks from both IPv4
IPv6 networks. It has been argued that the dual-stack architecture
could ultimately overburden the global networking infrastructure by
requiring routers to support
IPv6 routing simultaneously.
Dual-stack implementation still requires an
IPv4 address on every
node, which is limited by
IPv4 address exhaustion, one of the main
motivations for IPv6. To address this, Dual-stack Lite (DS-Lite) was
introduced, which uses network address translation and tunneling to
IPv4 packets in
IPv6 transport, then deliver them to their
Internet users do not have
IPv6 dual-stack support, and
thus cannot reach
IPv6 sites directly. Instead, they must use IPv4
infrastructure to carry
IPv6 packets. This is done using a technique
known as tunneling, which encapsulates
IPv6 packets within IPv4, in
IPv4 as a link layer for IPv6.
IP protocol 41 indicates
IPv4 packets which encapsulate IPv6
datagrams. Some routers or network address translation devices may
block protocol 41. To pass through these devices, UDP packets may be
used to encapsulate
IPv6 datagrams. Other encapsulation schemes, such
AYIYA or Generic Routing Encapsulation, are also popular.
Conversely, on IPv6-only
Internet links, when access to
facilities is needed, tunneling of
IPv6 protocol occurs,
IPv6 as a link layer for IPv4.
Automatic tunneling refers to a technique by which the routing
infrastructure automatically determines the tunnel endpoints. Some
automatic tunneling techniques are below.
6to4 is recommended by RFC 3056. It uses protocol 41
encapsulation. Tunnel endpoints are determined by using a
IPv4 anycast address on the remote side, and embedding IPv4
address information within
IPv6 addresses on the local side.
the most common tunnel protocol currently deployed.
Teredo is an automatic tunneling technique that uses UDP encapsulation
and can allegedly cross multiple NAT nodes. IPv6, including 6to4
and Teredo tunneling, are enabled by default in Windows Vista and
Windows 7. Most Unix systems implement only 6to4, but Teredo can be
provided by third-party software such as Miredo.
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) uses the
IPv4 network as a virtual
IPv6 local link, with mappings from each
IPv4 address to a link-local
IPv6 address. Unlike
6to4 and Teredo,
which are inter-site tunneling mechanisms,
ISATAP is an intra-site
mechanism, meaning that it is designed to provide
between nodes within a single organization.
Configured and automated tunneling (6in4)
6in4 tunneling requires the tunnel endpoints to be explicitly
configured, either by an administrator manually or the operating
system's configuration mechanisms, or by an automatic service known as
a tunnel broker; this is also referred to as automated tunneling.
Configured tunneling is usually more deterministic and easier to debug
than automatic tunneling, and is therefore recommended for large,
well-administered networks. Automated tunneling provides a compromise
between the ease of use of automatic tunneling and the deterministic
behavior of configured tunneling.
Raw encapsulation of
IPv6 packets using
IPv4 protocol number 41 is
recommended for configured tunneling; this is sometimes known as 6in4
tunneling. As with automatic tunneling, encapsulation within UDP may
be used in order to cross NAT boxes and firewalls.
Proxying and translation for IPv6-only hosts
After the regional
Internet registries have exhausted their pools of
IPv4 addresses, it is likely 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,
IPv6 transition mechanisms
IPv6 transition mechanisms must be deployed.
One form of address translation is the use of a dual-stack
application-layer proxy server, for example a web proxy.
NAT-like techniques for application-agnostic translation at the lower
layers in routers and gateways have been proposed. The NAT-PT standard
was dropped because of criticisms; however, more recently, the
continued low adoption of
IPv6 has prompted a new standardization
effort of a technology called NAT64.
IPv6 networking is mainly a software or firmware
issue. However, much of the older hardware that could in principle be
upgraded is likely to be replaced instead. In 2010, the American
Internet Numbers (ARIN) suggested that all Internet
servers be prepared to serve IPv6-only clients by January 2012.
Host software may have only
IPv4 or only
IPv6 networking software, or
it may support dual-stack, or hybrid dual-stack operation. The
majority of personal computers running recent operating system
versions support IPv6. Many popular applications with networking
capabilities are compliant.
Some software transitioning mechanisms are outlined in RFC 4038,
RFC 3493, and RFC 3542.
Hybrid dual-stack IPv6/
IPv4 implementations recognize a special class
of addresses, the IPv4-mapped
IPv6 addresses. These addresses consist
of an 80-bit prefix of zeros, the next 16 bits are ones, and the
remaining, least-significant 32 bits contain the
IPv4 address. These
addresses are typically written with a 96-bit prefix in the standard
IPv6 format, and the remaining 32 bits written in the customary
dot-decimal notation of IPv4. For example, ::ffff:192.0.2.128
IPv4 address 192.0.2.128. A deprecated format for
IPv6 addresses is ::192.0.2.128.
Because of the significant internal differences between
IPv4 and IPv6,
some of the lower-level functionality available to programmers in the
IPv6 stack does not work the same when used with IPv4-mapped
addresses. Some common
IPv6 stacks do not implement the IPv4-mapped
address feature, either because the
IPv4 stacks are separate
Microsoft Windows 2000, XP, and Server 2003),
or because of security concerns (OpenBSD). On these operating
systems, a program must open a separate socket for each IP protocol it
uses. On some systems, e.g., the Linux kernel, NetBSD, and FreeBSD,
this feature is controlled by the socket option IPV6_V6ONLY, as
specified in RFC 3493.
Hardware and embedded systems
CableLabs consortium published the 160 Mbit/s
IPv6-ready specification for cable modems in August 2006.
was updated as
DOCSIS 2.0 +
IPv6 to provide
IPv6 support, which may be
available with a firmware upgrade.
The addition of nodes having
IPv6 enabled by default by the software
manufacturer, may result in the inadvertent creation of shadow
IPv6 traffic flowing into networks having only IPv4
security management in place. This may also occur with operating
system upgrades, when the newer operating system enables
default, while the older one did not. Failing to update the security
infrastructure to accommodate
IPv6 can lead to
IPv6 traffic bypassing
it. Shadow networks have occurred on business networks in which
enterprises are replacing
Windows XP systems that do not have an IPv6
stack enabled by default, with
Windows 7 systems, that do. Some
IPv6 stack implementors have therefore recommended disabling IPv4
mapped addresses and instead using a dual-stack network where
IPv6 is necessary.
Research has shown that the use of fragmentation can be leveraged to
evade network security controls. As a result, RFC 7112 requires
that the first fragment of an
IPv6 packet contains the entire IPv6
header chain, such that some very pathological fragmentation cases are
forbidden. Additionally, as a result of research on the evasion of
RA-Guard in RFC 7113, RFC 6980 has deprecated the use of
fragmentation with Neighbor Discovery, and discouraged the use of
Secure Neighbor Discovery (SEND).
The 1993 introduction of
Classless Inter-Domain Routing
Classless Inter-Domain Routing (CIDR) in the
IP address allocation for the Internet, and the extensive
use of network address translation (NAT), delayed
exhaustion. The final phase of exhaustion started on 3 February
2011. However, despite a decade long development and
implementation history as a Standards Track protocol, general
worldwide deployment of
IPv6 is increasing slowly. As of September
2013[update], about 4% of domain names and 16.2% of the networks on
IPv6 protocol support.
IPv6 has been implemented on all major operating systems in use in
commercial, business, and home consumer environments. Since 2008, the
domain name system can be used in IPv6.
IPv6 was first used in a major
world event during the 2008 Summer Olympic Games, the largest
IPv6 technology since the inception of IPv6. Some
governments including the
Federal government of the United States
Federal government of the United States and
China have issued guidelines and requirements for
In 2009, Verizon mandated
IPv6 operation, and reduced
IPv4 to an
optional capability, for LTE cellular hardware. As of June
2012[update], T-Mobile USA also supports external
As of 2014,
IPv4 still carried more than 99% of worldwide Internet
Internet exchange in Amsterdam and Seattle are
the only large exchanges that publicly show
IPv6 traffic statistics,
which as of December 2017 are tracking at about 2.1% and 8.8%, growing
at about 0.9% and 4.0% per year, respectively. As of
31 December 2017[update], the percentage of users reaching
Google services with
IPv6 reached 22.6% for the first time in regular
measurements, growing at about 5.8% per year, although varying widely
by region. As of December 2017[update] about 33% of Alexa Top
500 web servers support IPv6.
China Next Generation Internet
IPv6 support in operating systems
IPv6 support in common applications
IPv6 product certification
IPv6 tunnel brokers
University of New Hampshire InterOperability Laboratory
^ New Zealand
IPv6 Task Force. "FAQs". Retrieved 26 October
^ Siddiqui, Aftab (17 July 2017). "RFC 8200 –
IPv6 has been
Internet Society. Retrieved 25 February 2018.
^ S. Deering; R. Hinden (December 1995),
Internet Protocol, Version 6
Internet Engineering Task Force (IETF),
^ a b c d e f S. Deering; R. Hinden (December 1998), Internet
Protocol, Version 6 (IPv6) Specification,
Internet Engineering Task
Force (IETF), RFC 2460 Obsoletes RFC 1883.
^ S. Deering; R. Hinden (July 2017),
Internet Protocol, Version 6
Internet Engineering Task Force (IETF),
ISSN 2070-1721, RFC 8200 Obsoletes RFC 2460.
IPv6 Conference 2008: What will the
Internet look like?.
Event occurs at 13:35.
^ a b c Bradner, S.; Mankin, A. (January 1995). The Recommendation for
the IP Next Generation Protocol. IETF. doi:10.17487/RFC1752. RFC 1752.
^ Rashid, Fahmida. "
IPv4 Address Exhaustion Not Instant Cause for
IPv6 in Wings". eWeek. Retrieved 23 June 2012.
^ Ward, Mark. "Europe hits old internet address limits". BBC.
Retrieved 15 September 2012.
^ Huston, Geoff. "IPV4 Address Report".
^ Bradner, S.; Mankin, A. (December 1993). "IP: Next Generation (IPng)
White Paper Solicitation". RFC 1550 .
^ "History of the IPng Effort". Sun.
^ "The Recommendation for the IP Next Generation Protocol – Appendix
B". RFC 1752 .
^ a b Partridge, C.; Kastenholz, F. (December 1994). "Technical
Criteria for Choosing IP The Next Generation (IPng)".
RFC 1726 .
^ "Moving to IPv6: Now for the hard part (FAQ)". Deep Tech. CNET News.
Retrieved 3 February 2011.
^ Ferguson, P.; Berkowitz, H. (January 1997). "Network Renumbering
Overview: Why would I want it and what is it anyway?".
RFC 2071 .
^ Berkowitz, H. (January 1997). "Router Renumbering Guide".
RFC 2072 .
^ a b Thomson, S.; Narten, T.; Jinmei, T. (September 2007). "IPv6
Stateless Address Autoconfiguration". RFC 4862 .
^ RFC 1112, Host extensions for IP multicasting, S. Deering
^ RFC 3956, Embedding the Rendezvous Point (RP) Address in an
Multicast Address, P. Savola, B. Haberman (November 2004)
^ RFC 2908, The
Multicast Address Allocation
Architecture, D. Thaler, M. Handley, D. Estrin (September 2000)
^ RFC 3306, Unicast-Prefix-based
Multicast Addresses, B.
Haberman, D. Thaler (August 2002)
^ RFC 2894, Router Renumbering for IPv6, M. Crawford, August
^ RFC 4301, "
IPv6 Node Requirements", J. Loughney (April 2006)
^ RFC 6434, "
IPv6 Node Requirements", E. Jankiewicz, J. Loughney,
T. Narten (December 2011)
^ RFC 3963, Network Mobility (NEMO) Basic Protocol Support, V.
Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert (January 2005)
^ Gont, F.; Linkova, J.; Chown, T.; Liu, S. (October 2015).
"Observations on the Dropping of Packets with
IPv6 Extension Headers
in the Real World". draft-ietf-v6ops-ipv6-ehs-in-real-world-01.
^ RFC 2675,
IPv6 Jumbograms, D. Borman, S. Deering, R. Hinden
^ Statement on
IPv6 Address Privacy,
Steve Deering & Bob Hinden,
Co-Chairs of the IETF's IP Next Generation Working Group, 6 November
^ "Neues Internet-Protokoll erschwert anonymes Surfen". Spiegel.de.
Retrieved 19 February 2012.
^ Marten, T; Draves, R (January 2001). Privacy Extensions for
Stateless Address Autoconfiguration in IPv6.
IPv6 Essentials by Silvia Hagen, p. 28, chapter 3.5.
^ Privacy Extensions (IPv6), Elektronik Kompendium.
^ Overview of the Advanced Networking Pack for Windows XP, Revision:
^ IPv6: Privacy Extensions einschalten, Reiko Kaps, 13 April 2011
^ "Comment #61 : Bug #176125 : Bugs: "procps" package:
Ubuntu". Bugs.launchpad.net. Retrieved 19 February 2012.
^ Gont, F (April 2014). A Method for Generating Semantically Opaque
Interface Identifiers with
IPv6 Stateless Address Autoconfiguration
(SLAAC). doi:10.17487/RFC7217. RFC 7217.
^ Fernando Gont (September 2016). "Recommendation on Stable IPv6
^ RFC 4291, p. 9
^ a b RFC 3315, R. Droms, J. Bound, B. Volz, T. Lemon, C.
Perkins, and M. Carney,
Dynamic Host Configuration Protocol
Dynamic Host Configuration Protocol for IPv6
(DHCPv6), July 2003 (Proposed Standard)
^ Graziani, Rick (2012).
IPv6 Fundamentals: A Straightforward Approach
to Understanding IPv6. Cisco Press. p. 55.
^ Coffeen, Tom (2014).
IPv6 Address Planning: Designing an Address
Plan for the Future. O'Reilly Media. p. 170.
^ S. Kawamura (August 2010). "A Recommendation for
IPv6 Address Text
Representation". section 4.2.2. RFC 5952 .
^ S. Kawamura (August 2010). "A Recommendation for
IPv6 Address Text
Representation". RFC 5952 . Missing or empty url= (help)
^ a b c Narten, T. (August 1999). "Neighbor discovery and stateless
autoconfiguration in IPv6". IEEE
Internet Computing. 3 (4): 54–62.
^ S. Thomson (September 2007). "
IPv6 Stateless Address
Autoconfiguration". section 5.5.1. RFC 4862 .
^ T. Narten (September 2007). "Neighbor Discovery for IP version 6
(IPv6)". section 6.3.7. RFC 4861 .
^ S. Thomson; T. Narten; T. Jinmei (September 2007). "
Address Autoconfiguration". RFC 4862 .
IPv6 Address Allocation and Assignment Policy". RIPE NCC. 8
February 2011. Retrieved 27 March 2011.
Comcast Activates First Users With
IPv6 Native Dual Stack Over
DOCSIS". Comcast.com. Comcast. 31 January 2011.
IPv6 Transition Mechanism / Tunneling Comparison". Sixxs.net.
Retrieved 20 January 2012.
^ "Advisory Guidelines for
6to4 Deployment". IETF.
RFC 6343 . Missing or empty url= (help); access-date=
requires url= (help)
^ "Basic Transition Mechanisms for
IPv6 Hosts and Routers". IETF.
RFC 4213 . Missing or empty url= (help); access-date=
requires url= (help)
^ "IPv6: Dual stack where you can; tunnel where you must".
www.networkworld.com. 5 September 2007. Retrieved 27 November
^ Sun, Charles C. (1 May 2014). "Stop using
Internet Protocol Version
^ "DS-Lite –
IPv6 and NAT". 2012-03-22.
^ RFC 3056, Connection of
IPv6 Domains via
IPv4 Clouds, B.
Carpenter, February 2001.
^ RFC 4380, Teredo: Tunneling
IPv6 over UDP through Network
Address Translations (NATs), C. Huitema, Februari 2006
Windows Vista Developer Story: Application Compatibility
Cookbook". Msdn2.microsoft.com. 24 April 2006. Retrieved 20 January
^ RFC 5214, Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP), F. Templin, T. Gleeson, D. Thaler, March 2008.
^ RFC 3053,
IPv6 Tunnel Broker, A. Durand, P. Fasano, I.
Guardini, D. Lento (January 2001)
^ RFC 4966, Reasons to Move the Network Address
Translator-Protocol Translator (NAT-PT) to Historic Status
^ "Web sites must support
IPv6 by 2012, expert warns". Network World.
21 January 2010. Retrieved 30 September 2010.
^ "IP Version 6 Addressing Architecture". IETF. February 2006.
RFC 4291 . Retrieved 2017-11-28.
^ inet6(4) –
OpenBSD Kernel Interfaces Manual
^ "Basic Socket Interface Extensions for IPv6". IETF. February 2003.
p. 22. RFC 3493 . Retrieved 2017-11-28.
DOCSIS 2.0 Interface". Cablemodem.com. 29 October 2007. Archived
from the original on 4 September 2009. Retrieved 31 August 2009.
^ "RMV6TF.org" (PDF). Archived from the original (PDF) on 5 January
2012. Retrieved 20 January 2012.
^ Mullins, Robert (April 5, 2012), Shadow Networks: an Unintended IPv6
Side Effect, retrieved March 2, 2013
^ Cicileo, Guillermo; Gagliano, Roque; O’Flaherty, Christian; et al.
IPv6 For All: A Guide for
IPv6 Usage and Application
in Different Environments (PDF). p. 5. Retrieved March 2,
^ Jun-ichiro itojun Hagino (October 2003). "IPv4-Mapped Addresses on
the Wire Considered Harmful".
IPv4 Address Report". Potaroo.net. Retrieved 20 January 2012.
^ Mike Leber (2 October 2010). "Global
IPv6 Deployment Progress
Report". Hurricane Electric. Retrieved 19 October 2011.
^ "Beijing2008.cn leaps to next-generation Net" (Press release). The
Beijing Organizing Committee for the Games of the XXIX Olympiad. 30
May 2008. Archived from the original on 4 February 2009.
^ Das, Kaushik (2008). "
IPv6 and the 2008 Beijing Olympics". IPv6.com.
Retrieved 15 August 2008. As thousands of engineers, technologists
have worked for a significant time to perfect this (IPv6) technology,
there is no doubt, this technology brings considerable promises but
this is for the first time that it will showcase its strength when in
use for such a mega-event.
^ Derek Morr (9 June 2009). "Verizon Mandates
IPv6 Support for
Next-Gen Cell Phones". CircleID.
^ theipv6guy (31 July 2012). "T-Mobile USA Launches External IPv6".
T-Mobile. Archived from the original on 19 October 2013.
^ van Beijnum, Iljitsch. "
IPv6 adoption starting to add up to real
numbers: 0.6 percent". Ars Technica. Retrieved 9 April 2015.
^ David Frost (20 April 2011). "Ipv6 traffic volumes going backwards".
iTWire. Retrieved 19 February 2012.
^ "Traffic Graphs www.seattleix.net". www.seattleix.net. Retrieved
Internet Exchange Ether Type". ams-ix.net. Retrieved
Google Statistics. Google. Retrieved 27 April 2015.
IPv6 website". 6lab.cisco.com. Retrieved 2015-01-28.
Wikiversity has learning resources about IPv6
IPv6 in the Linux Kernel by Rami Rosen.
Free Pool of
IPv4 Address Space Depleted
An Introduction and Statistics about IPV6
Internet Protocol version 6
IPv6 Day and World
IPv6 Launch Day
IPv6 support in operating systems
IPv6 tunnel brokers
IPv4 address exhaustion
IPv6 transition mechanism
Neighbor Discovery Protocol
Multicast Listener Discovery
Secure Neighbor Discovery
Multicast router discovery
Site Multihoming by