IPv6
From ClueWiki
Internet Protocol version 6 (IPv6) is a w:network layer for packet-switched internetworks. It is designated as the successor of w:IPv4, the current version of the w:Internet Protocol, for general use on the w: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 w:network address translation to avoid address exhaustion, and also simplifies aspects of address assignment and renumbering when changing providers. It was not the intention of IPv6 designers, however, to give permanent unique addresses to every individual and every computer.
It is common to see examples that attempt to show that the IPv6 address space is absurdly large. For example, IPv6 supports 2128 (about 3.4×1038) addresses, or approximately 5×1028 addresses for each of the roughly 6.5 billion people[1] alive today. In a different perspective, this is 252 addresses for every star in the known universe [1] - a million times as many addresses per star than IPv4 supported for our single planet.
The large number of addresses allows a hierarchical allocation of addresses that may make routing and renumbering simpler. With IPv4, complex 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.
Contents |
[edit] Introduction
By the early 1990s, it was clear that the change to a w:classless network introduced a decade earlier was not enough to prevent w:IPv4 address exhaustion and that further changes to IPv4 were needed.[2] 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 w:working groups.[2][3]
IPng was adopted by the w:Internet Engineering Task Force on w:July 25, w:1994 with the formation of several "IP Next Generation" (IPng) w:working groups.[2] By 1996, a series of RFCs were released defining IPv6, starting with RFC 2460. (Incidentally, w:IPv5 was not a successor to IPv4, but an experimental flow-oriented 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 below.
[edit] 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 FTP or NTPv3).
Applications, however, usually need small changes and a recompile in order to run over IPv6.
[edit] 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 w:network address translation (NAT) and other devices that break the w:end-to-end nature of Internet traffic. NAT may still be necessary in rare cases, but Internet engineers recognize that it will be difficult in IPv6 and are trying to avoid it whenever possible. It also makes administration of medium and large networks simpler, by avoiding the need for complex w:subnetting schemes. Subnetting will, ideally, revert to its purpose of logical segmentation of an w:IP network for optimal w: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 (header compression can sometimes be used to alleviate this problem). This also makes human memorisation of IPv6 addresses much harder compared to IPv4 addresses, often impossible due to their length; use of the w:Domain Name System (DNS) is necessary.
[edit] Stateless address autoconfiguration (SLAAC)
IPv6 hosts can be configured automatically when connected to a routed IPv6 network using w:ICMPv6 router discovery messages. When first connected to a network, a host sends a w:link-local w: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.[4]
If IPv6 autoconfiguration is not suitable, a host can use stateful configuration (w:DHCPv6) or be configured manually. Stateless autoconfiguration is only suitable for hosts: routers must be configured manually or by other means.[5]
[edit] Multicast
w: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 (FF02::1).
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.
[edit] 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.
[edit] Jumbograms
In IPv4, packets are limited to 64 KiB of payload. When used between capable communication partners and on communication links with a w:maximum transmission unit (MTU) larger than 65,576 octets (65536 + 40 for the header), IPv6 has optional support for packets over this limit, referred to as w:jumbograms which can be as large as 4 GiB. The use of jumbograms may improve performance over high-MTU networks.
[edit] Network-layer security
w: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). w:IPsec, however, is not widely used at present except for securing traffic between IPv6 w:Border Gateway Protocol routers.
[edit] Mobility
Unlike mobile IPv4, w:Mobile IPv6 (MIPv6) avoids w:triangular routing and is therefore as efficient as normal IPv6. This advantage is mostly hypothetical, as neither MIP nor MIPv6 are widely deployed today.
[edit] Lack of a checksum
IPv4 has a checksum field that uses all the bits of the header to create and check. Since certain fields (such as the TTL field) could or would change between each router, the checksum has to be recomputed in every router. It is believed that errors are very rare in today's network. For this reason, IPv6 has no error checking in its protocol but instead relies on link layer protocols to perform error checking. In the event that the header is corrupted, the worst that can happen is that the packet is sent to the wrong host.
[edit] Deployment status
The IPv6 Forum [2]has been created as a spin-off of the IETF IPv6 Deployment WG that was led by Jim Bound in July 1999.
As of November 2007, IPv6 accounts for a minuscule percentage of the live addresses in the publicly-accessible Internet, which is still dominated by IPv4.
With the notable exceptions of stateless auto-configuration, more flexible addressing and w: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 w:classless inter-domain routing (CIDR) and the extensive use of w:network address translation (NAT).
[edit] IPv4 exhaustion
Estimates as to when the pool of available IPv4 addresses will be exhausted vary widely, and should be taken with caution. In 2003, Paul Wilson (director of w:APNIC) stated that, based on then-current rates of deployment, the available space would last until 2023.[6] In September 2005 a report by w:Cisco Systems reported that the pool of available addresses would be exhausted in as little as 4 to 5 years.[7] w:As of November 2007, a daily updated report projected that the IANA pool of unallocated addresses would be exhausted in May 2010, with the various Regional Internet Registries using up their allocations from IANA in April 2011.[8] This report also argues that, if assigned but unused addresses were reclaimed and used to meet continuing demand, allocation of IPv4 addresses could continue until 2017.
[edit] Government incentives
A number of governments, however, are starting to require support for IPv6 in new equipment. The U.S. Government, for example, has specified that the network backbones of all federal agencies must deploy IPv6 by w:2008,[9] and spent the money to acquire a /16 block 281 trillion network addresses to start the deployment.[10][11] [12]
The w:Peoples Republic of China has a 5 year plan for deployment of IPv6 called the w:China Next Generation Internet.
[edit] Current deployment
In February 1999, The IPv6 Forum [13] was founded by the IETF Deployment WG to drive deployment worldwide, creating by now over 45 IPv6 Country Forums and IPv6 Task Forces[14]. On 20 July 2004 w:ICANN announced that the root DNS servers for the Internet had been modified to support both IPv6 and IPv4.
[edit] Addressing
[edit] 128-bit length
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×1038 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 w: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.
[edit] Notation
IPv6 addresses are normally written as eight groups of four w:hexadecimal digits. For example, 2001:0db8:85a3:08d3:1319:8a2e:0370:7334 is a valid IPv6 address.
If one or more four-digit group(s) is 0000, the zeros may be omitted and replaced with two colons(::). For example, 2001:0db8:0000:0000:0000:0000:1428:57ab can be shortened to 2001:0db8::1428:57ab. Following this rule, any number of consecutive 0000 groups may be reduced to two colons, as long as there is only one double colon used in an address. Leading zeros in a group can also be omitted (as in ::1 for localhost). Thus, the addresses below are all valid and equivalent:
2001:0db8:0000:0000:0000:0000:1428:57ab 2001:0db8:0000:0000:0000::1428:57ab 2001:0db8:0:0:0:0:1428:57ab 2001:0db8:0:0::1428:57ab 2001:0db8::1428:57ab 2001:db8::1428:57ab
Having more than one double-colon abbreviation in an address is invalid, as it would make the notation ambiguous. 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 x's are the 6 higher order hexadecimal digits whereas d's correspond to the decimal digits of lower order 8 bit pieces of address, as it is the IPv4 format. For example, ::ffff:12.34.56.78 is the same address as ::ffff:0c22:384e and 0:0:0:0:0:ffff:0c22:384e. Usage of this notation is deprecated and unsupported by numerous applications.
Additional information can be found in RFC 4291 - IP Version 6 Addressing Architecture.
[edit] Literal IPv6 addresses in URLs
In a URL the IPv6-Address is enclosed in brackets. Example:
http://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]/
This notation allows w:parsing a URL without confusing the IPv6 address and port number:
https://[2001:0db8:85a3:08d3:1319:8a2e:0370:7344]:443/
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"
[edit] Network notation
IPv6 networks are written using 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, 2001:0db8:1234::/48 stands for the network with addresses 2001:0db8:1234:0000:0000:0000:0000:0000 through 2001:0db8:1234:ffff:ffff:ffff:ffff:ffff
Because a single host can be seen as a network with a 128-bit prefix, you will sometimes see host addresses written followed with /128.
[edit] Kinds of IPv6 addresses
IPv6 addresses are divided into 3 categories:[15]
- 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
- Site-local addresses
- Unique local IPv6 unicast addresses
- Special addresses
w:Multicast addresses are used to define a set of interfaces that typically belong to different nodes instead of just one. When a packet is sent to a multicast address, the protocol delivers the packet to all interfaces identified by that address. Multicast addresses begin with the prefix FF00::/8, and their second octet identifies the addresses' scope, i.e. the range over which the multicast address is propagated. Commonly used scopes include link-local (0x2), site-local (0x5) and global (0xE).
w: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.
[edit] Special addresses
There are a number of addresses with special meaning in IPv6:
- Link local
- ::/128 — the address with all zeros is an unspecified address, and is to be used only in software.
- ::1/128 — the w:loopback address is a w: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 w:127.0.0.1 in IPv4).
- fe80::/10 — The link-local prefix specifies that the address only is valid in the local physical link. This is analogous to the Autoconfiguration IP address 169.254.0.0/16 in IPv4.
- Site local
- fc00::/7 — w:unique local addresses (ULA) are routable only within a set of cooperating sites. They were defined in RFC 4193 as a replacement for site-local addresses (see below). The addresses include a 40-bit w:pseudorandom number that minimizes the risk of conflicts if sites merge or packets somehow leak out.
- IPv4
- ::ffff:0:0/96 — this prefix is used for w:IPv4 mapped addresses (see Transition mechanisms below).
- 2002::/16 — this prefix is used for w:6to4 addressing.
- Multicast
- ff00::/8 — The multicast prefix is used for w:multicast addresses[16] as defined by in "IP Version 6 Addressing Architecture" (RFC 4291).
- Used in examples, deprecated, or obsolete
- ::/96 — the zero prefix was used for w:IPv4-compatible addresses; it is now obsolete.
- 2001:db8::/32 — this prefix is used in documentation (RFC 3849). Anywhere where an example IPv6 address is given, addresses from this prefix should be used.
- fec0::/10 — 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.
There are no address ranges reserved for broadcast in IPv6 — applications use multicast to the all-hosts group instead. IANA maintains the official list of the IPv6 address space. Global unicast assignments can be found at the various RIR's or at the GRH DFP pages.
[edit] 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 subnet, an ambiguity arises that cannot be solved by routing tables.
For example, host A has two interfaces which automatically receive link-local addresses when activated (per RFC 2462): fe80::1/64 and fe80::2/64, only one of which is connected to the same physical network as host B which has address fe80::3/64; if host A attempts to contact fe80::3 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 <address>%<zone_id>, for example: http://[fe80::1122:33ff:fe11:2233%eth0]:80/ - this however may cause its own problems due to clashing with the w:percent-encoding used with URIs. [3]
- Microsoft Windows IPv6 stack uses numeric zone IDs: fe80::3%1
- BSD applications typically use the interface name as a zone ID: fe80::3%pcn0
- Linux applications also typically use the interface name as a zone ID: fe80::3%eth0
Relatively few IPv6-capable applications understand zone ID syntax (with the notable exception of w:OpenSSH), thus rendering link-local addresses unusable within them if multiple interfaces use link-local addresses.
[edit] IPv6 packet
The IPv6 packet is composed of two main parts: the header and the payload.
The header is in the first 40 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 - QoS management (20 bits). Originally created for giving 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 w:time to live field of IPv4 (8 bits).
- Source and destination addresses - 128 bits each.
The payload can be up to 64KiB in size in standard mode, or larger with a "jumbo payload" option.
Fragmentation is handled only in the sending host in IPv6: routers never fragment a packet, and hosts are expected to use w: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 w:IPsec for both IPv4 and IPv6.
[edit] IPv6 and the Domain Name System
IPv6 addresses are represented in the w:Domain Name System by AAAA records (so-called quad-A records) for forward lookups; reverse lookups take place under ip6w:.arpa (previously ip6w:.int), where address space is delegated on w:nibble boundaries. This scheme, which is a straightforward adaptation of the familiar w: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).
| NAME | Domain name |
| TYPE | AAAA (28) |
| CLASS | Internet (1) |
| 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.
[edit] IPv6 and DNS RFCs
- DNS Extensions to support IP version 6 - RFC 1886
- DNS Extensions to Support IPv6 Address Aggregation and Renumbering - RFC 2874
- Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6) - RFC 3364
- Default Address Selection for Internet Protocol version 6 (IPv6) - RFC 3484
- Internet Protocol Version 6 (IPv6) Addressing Architecture - RFC 3513
- DNS Extensions to Support IP Version 6 (Obsoletes 1886 and 3152) - RFC 3596
[edit] 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. [17] contains an overview of the transition mechanisms mentioned below.
[edit] 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.
[edit] Tunneling
In order to reach the IPv6 Internet, an isolated host or network must be able to use the existing IPv4 infrastructure to carry IPv6 packets. This is done using a technique somewhat misleadingly known as tunneling 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 w:AYIYA or GRE.
[edit] 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 w:6to4 tunneling, which uses protocol 41 encapsulation.[18] 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 w:ISATAP.[19] 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 is an automatic tunneling technique that uses UDP encapsulation and is claimed to be able to cross multiple NAT boxes.[20] 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 w:Windows Vista.[21]
[edit] 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 w:tunnel broker.[22] 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 better known as w:6in4.
[edit] Proxying and translation
When an IPv6-only host needs to access an IPv4-only service (for example a web server), some form of translation is necessary. One form of translation that actually works is the use of a dual-stack 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 due to the wide range of functionality required by common application-layer protocols, and are considered by many to be obsolete.
[edit] Major IPv6 announcements and availability
| Year | Announcements and availability |
|---|---|
| 1996 | w:Linux gains alpha quality IPv6 support in kernel development version 2.1.8[23] |
| 1997 | In the end of w:1997 w:IBM's AIX 4.3 was the first commercial platform that supported IPv6.[24][25] |
| 1998 | w:Microsoft Research[26] first released an experimental IPv6 stack in 1998. This support was not intended for use in a production environment. |
| 2000 | Production-quality BSD support for IPv6 has been generally available since early to mid-2000 in w:FreeBSD, w:OpenBSD, and w:NetBSD via the w:KAME project[27]. |
| Sun Solaris has IPv6 support since the Solaris 8 in February 2000[28] | |
| 2002 | w:Microsoft w:Windows NT 4.0 and w:Windows 2000 SP1 had limited IPv6 support for research and testing since at least 2002. |
| Microsoft w:Windows XP (2001) had IPv6 support for developmental purposes. In w:Windows XP SP1 (2002) and w:Windows Server 2003, IPv6 is included as a core networking technology, suitable for commercial deployment.[29] | |
| IBM w:z/OS has supported IPv6 since version 1.4 that has been generally available since September 2002.[30] | |
| 2003 | Apple Mac OS X v10.3 "Panther" (2003) has IPv6 supported and enabled by default.[31] |
| In July, w: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 w: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. | |
| 2007 | Microsoft w:Windows Vista (2007) has IPv6 supported and enabled by default.[29] |
| Apple's w: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.[32] | |
| 2008 | On February 4th 2008, IANA will add the AAAA records for the IPv6 addresses of the four root servers[33]. With this transition, it will be possible for two internet hosts to communicate without using IPv4 at all. |
[edit] Criticism
While IPv6 has been hailed as the future of the internet and is expected to solve many problems, some criticisms have been leveled about this next IP protocol. One criticism is the extremely large address space. With there more than a trillion addresses per square centimeter of surface on the planet, 128-bit addresses have been labeled overkill [4]. This is a common criticism, which does not reflect that the IETF never intended to give static addresses to every possible location. The long length is done for reasons of routing aggregation, address autoconfigurations, and other things much more difficult in IPv4.
These large addresses can take more time to process and may increase the cost of routers. Also, server administrators who have previously required users to remember an IP address rather than pay for a domain name would no longer be able to do this because people cannot easily memorize the larger IPv6 addresses, although it is not well documented that domain cost alone is a significant issue.
The w:IETF and w:IANA have been encouraging the use of unique identifiers contained in all ethernet cards to help make IP assignment easy. However, this practice poses a privacy issue. If IP addresses were all allocated statically, it would be very simple to track all network activity of any computer. Another privacy concern is that IPv6 assigns address hierarchically, as does IPv4. While this practice makes routing much easier, it allows locating an individual in the same way one locates someone using his telephone area code and phone exchange.
[edit] Disabling
Some users disable IPv6 functionality in their operating system to increase their connection speed behind faulty routers or ISP connections. This should not be an issue for most users.
[edit] See also
- ICMP for IPv6
- w:Comparison of IPv6 application support
- w:Miredo - Teredo implementation, allowing IPv6 access from behind NAT.
- w:China Next Generation Internet
- w:IPv9: purported Chinese IPv6-variant from 2004.
- RFC 1924 - April Fool's Joke to encode IPv6 addresses as base 85.
[edit] Notes and references
- ↑ U.S. Census Bureau
- ↑ 2.0 2.1 2.2 RFC 1750
- ↑ History of the IPng Effort
- ↑ IPv6 Stateless Address Autoconfiguration, RFC 2462, December 1998
- ↑ Router Renumbering for IPv6, RFC 2894, M. Crawford, August 2000
- ↑ Exec: No shortage of Net addresses By John Lui, CNETAsia
- ↑ A Pragmatic Report on IPv4 Address Space Consumption by Tony Hain, Cisco Systems
- ↑ IPv4 Address Report
- ↑ August 2005 directive from the Office of Management Budget
- ↑ DOD to allocate its IPv6 addresses
- ↑ Bitten by IPv6 (correction to the first report)
- ↑ Providing the Tools for Information Sharing: Net-Centric Enterprise Services (Department of Defense Chief Information Officer Information Policy Directorate)
- ↑ The IPv6 Forum
- ↑ IPv6 Task Forces
- ↑ RFC 2373 - IP Version 6 Addressing Architecture
- ↑ IP Version 6 multicast address
- ↑ IPv6 Transition Mechanism / Tunneling Comparison
- ↑ RFC 3056
- ↑ RFC 4214
- ↑ RFC 4380
- ↑ The Windows Vista Developer Story: Application Compatibility Cookbook
- ↑ RFC 3053
- ↑ Linux IPv6 Development Project
- ↑ IPv6 support shipping in AIX 3.3
- ↑ Its AIX 4.3.
- ↑ Internet Protocol Version 6 (old Microsoft Research IPv6 release)
- ↑ KAME project
- ↑ Sun Solaris 8 changes from Solaris 7
- ↑ 29.0 29.1 Microsofts main IPv6 site
- ↑ http://www-03.ibm.com/servers/eserver/zseries/announce/zos_r4/
- ↑ Mac OS X 10.3 Using IPv6
- ↑ Apple AirPort Extreme technical specifications.
- ↑ IPv6: coming to a root server near you
[edit] Further reading
[edit] Core specifications
- RFC 2460: Internet Protocol, Version 6 (IPv6) Specification (obsoletes RFC 1883)
- RFC 2461/RFC 4311: Neighbor Discovery for IP Version 6 (IPv6) (4311 updates)
- RFC 2462: IPv6 Stateless Address Autoconfiguration
- RFC 4443: Internet Control Message Protocol (ICMPv6) for the IPv6 Specification (obsoletes RFC 2463)
- RFC 2464: Transmission of IPv6 Packets over Ethernet Networks
- RFC 4291: Internet Protocol Version 6 (IPv6) Addressing Architecture (obsoletes RFC 3513)
- RFC 3041: MAC address use replacement option
- RFC 3587: An IPv6 Aggregatable Global Unicast Address Format
[edit] Stateless autoconfiguration
- RFC 2461: Neighbor Discovery for IP Version 6 (IPv6)
- RFC 2462: IPv6 Stateless Address Autoconfiguration
[edit] 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)
[edit] Books
There are a number of IPv6 books:
- ISBN 0-12-370479-0 IPv6 Advanced Protocols Implementation (April 2007)
- ISBN 0-12-447751-8 IPv6 Core Protocols Implementation (October 2006)
- ISBN 0-471-49892-0 Migrating to IPv6: A Practical Guide to Implementing IPv6 in Mobile and Fixed Networks (2006)
- ISBN 1-59059-527-0 Running IPv6 (2006)
- ISBN 0-596-00934-8 IPv6 Network Administration (2005)
- ISBN 3-9522942-0-9 IPv6 - Grundlagen, Funktionalität, Integration by Silvia Hagen (German Edition, 2004)
- ISBN 0-596-10058-2 IPv6 Essentials, 2nd Edition by Silvia Hagen (English, 2006)
- ISBN 1-55558-318-0 IPv6 network programming by w:Jun-ichiro itojun Hagino (English, 2004)
- ISBN 957-527-727-9 IPv6 network programming by w:Jun-ichiro itojun Hagino (Traditional Chinese, 2004)
- ISBN 4-7561-4236-2 IPv6 network programming by w:Jun-ichiro itojun Hagino (Japanese, 2003)
- ISBN 0-13-241936-X IPv6: The New Internet Protocol by Christian Huitema (1998) (The original IPv6 bible)
[edit] External links
- go6.net The IPv6 Portal Free IPv6 Connectivity with Freenet6
- Hexago IPv6 Deployment Today
- IPv6 News, info and more Daily updated
- Database of IPv6 supporting services, hardware and software
- Everything you need to know about IPv6 from Ars Technica
- IPv6 - The Next Generation Internet Protocol (IATAC IAnewsletter 7-3 (Fall/Winter 2004/2005))
- MOONv6 US-based University-related IPv6 test network
- ECAI6 European Conference on Applied IPv6
- IPv6 Blog IPv6 Blog discussing current issues
[edit] Related IETF working groups
- ipv6 IP Version 6
- multi6 Site Multihoming in IPv6
- shim6 Site Multihoming by IPv6 Intermediation
- v6ops IPv6 Operations
- 6bone IPv6 Backbone (concluded)
- ipng IP Next Generation (concluded)
- ipv6mib IPv6 MIB (concluded)
w:Category:Network layer protocols
w:ar:IPv6 w:bg:IPv6 w:bs:IPv6 w:ca:IPv6 w:da:IPv6 w:de:IPv6 w:es:IPv6 w:eu:IPv6 w:fr:IPv6 w:gl:Protocolo IPv6 w:ko:IPv6 w:id:Alamat IP versi 6 w:is:IPv6 w:it:IPv6 w:he:IPv6 w:hu:IPv6 w:mk:IPv6 w:nl:Internet Protocol Version 6 w:ja:IPv6 w:no:IPv6 w:nn:IPv6 w:pl:IPv6 w:pt:IPv6 w:ru:IPv6 w:sk:IPv6 w:fi:IPv6 w:sv:IPv6 w:tr:IPv6 w:uk:IPv6 w:zh:IPv6

