Contents

Articles
IPv6 IPv6 address IPv6 packet Mobile IP Neighbor Discovery Protocol Secure Neighbor Discovery Protocol Multicast Router Discovery Site Multihoming by IPv6 Intermediation IPv6 transition mechanisms 4in6 6in4 6over4 6to4 Tunnel broker Teredo tunneling Miredo NAT64 ISATAP SATSIX China Next Generation Internet DoD IPv6 Product Certification Comparison of IPv6 support in routers Comparison of IPv6 application support Comparison of IPv6 support by major transit providers Comparison of IPv6 support in operating systems 1 12 25 31 34 35 36 36 37 41 41 42 44 47 48 55 56 57 59 63 65 67 70 75 77

References
Article Sources and Contributors Image Sources, Licenses and Contributors 80 82

Article Licenses
License 83

IPv6

IPv6
IPv6 (Internet Protocol version 6) is a version of the Internet Protocol (IP) intended to succeed IPv4, which is the protocol currently used to direct almost all Internet traffic.[1] The Internet operates by transferring data between hosts in packets that are routed across networks as specified by routing protocols. These packets require an addressing scheme, such as IPv4 or IPv6, to specify their source and destination addresses. Each host, computer or other device on the Internet requires an IP address in order to communicate. The growth of the Internet has created a need for more addresses than are possible with IPv4. The last top level (/8) block of free IPv4 addresses was assigned in February 2011 by IANA to the 5 RIRs, although many free addresses still remain in most assigned blocks and RIRs will continue with standard policy until it is at its last /8. After that, only 1024 addresses (a /22) are made available from the RIR for each LIR: currently, only APNIC has already reached this stage.[2] IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with this long-anticipated IPv4 address exhaustion, and is described in Internet standard document RFC 2460, published in December 1998.[3] Like IPv4, IPv6 is an internet-layer protocol for packet-switched internetworking and provides end-to-end datagram transmission across multiple IP networks. While IPv4 allows 32 bits for an IP address, and therefore has 232 (4,294,967,296) possible addresses, IPv6 uses 128-bit addresses, for an address space of 2128 (approximately 340 undecillion or 3.41038) addresses. This expansion allows for many more devices and users on the internet as well as extra flexibility in allocating addresses and efficiency for routing traffic. It also eliminates the primary need for network address translation (NAT), which gained widespread deployment as an effort to alleviate IPv4 address exhaustion. IPv6 also implements additional features not present in IPv4. It simplifies aspects of address assignment (stateless address autoconfiguration), network renumbering and router announcements when changing Internet connectivity providers. The IPv6 subnet size has been 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 media addressing information (MAC address). Network security is also integrated into the design of the IPv6 architecture, and the IPv6 specification specifies IPsec as a fundamental interoperability requirement. For the Internet to make use of the advantages of IPv6 over IPv4, most hosts on the Internet, as well as the networks connecting them, will need to deploy this protocol. However, IPv6 deployment is difficult. While deployment of IPv6 is accelerating, especially in the Asia-Pacific region and some European countries, areas such as the Americas and Africa are comparatively lagging in deployment of IPv6. IPv6 does not implement interoperability features with IPv4, and creates essentially a parallel, independent network. Exchanging traffic between the two networks requires special translator gateways, but modern computer operating systems implement dual-protocol software for transparent access to both networks either natively or using a tunneling protocol such as 6to4, 6in4, or Teredo. In December 2010, despite marking its 12th anniversary as a Standards Track protocol, IPv6 was only in its infancy in terms of general worldwide deployment. A 2008 study[4] by Google Inc indicated that penetration was still less than one percent of Internet-enabled hosts in any country at that time.

IPv6

Motivation and origin

IPv4
The first publicly used version of the Internet Protocol Version 4 (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 an internal test within ARPA, and not intended for public use. The decision to put a 32-bit address space on there was the result of a year's battle among a bunch of engineers who couldn't make up their minds about 32, 128, or variable-length. And after a year of fighting, I said--I'm now at ARPA, I'm running the program, I'm paying for this stuff, I'm using American tax dollars, and I wanted some progress because we didn't know if this was going to work. So I said: OK, it's 32-bits. That's enough for an experiment; it's 4.3 billion terminations. Even the Defense Department doesn't need 4.3 billion of everything and couldn't afford to buy 4.3 billion edge devices to do a test anyway. So at the time I thought we were doing an experiment to prove the technology and that if it worked we'd have opportunity to do a production version of it. Well, it just escaped! It got out and people started to use it, and then it became a commercial thing. So this [IPv6] is the production attempt at making the network scalable. Vint Cerf,Google IPv6 Conference 2008[5] During the first decade of operation of the Internet (by the late 1980s), 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 IPv4 address exhaustion, and that further changes to the Internet infrastructure were needed.[6]

Working-group proposal
By the beginning of 1992, several proposals appeared and by the end of 1992, the IETF announced a call for white papers.[7] In September 1993, the IETF created a temporary, ad-hoc IP Next Generation (IPng) area to deal specifically with IPng 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:[6][8] 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 Zhang (Xerox). The Internet Engineering Task Force adopted the IPng model on July 25, 1994, with the formation of several IPng working groups.[6] By 1996, a series of RFCs was released defining Internet Protocol version 6 (IPv6), starting with RFC 1883. (Version 5 was used by the experimental Internet Stream Protocol.) It is widely expected that the Internet will use IPv4 alongside IPv6 for the foreseeable future. IPv4-only and IPv6-only nodes cannot communicate directly, and need assistance from an intermediary gateway or must use other transition mechanisms.

IPv6

Exhaustion of IPv4 addresses

On February 3, 2011, in a ceremony in Miami, the Internet Assigned Numbers Authority (IANA) assigned the last batch of 5 /8 address blocks to the Regional Internet Registries,[9] officially depleting the global pool of completely fresh blocks of addresses.[10] Each of the address blocks represents approximately 16.7 million possible addresses, or over 80 million combined potential addresses. These addresses could well be fully consumed within three to six months of that time at current rates of allocation.[11] APNIC was the first RIR to exhaust its regional pool on 15 April 2011, except for a small amount of address space reserved for the transition to IPv6, which will be allocated in a much more restricted way.[12] In 2003, the director of Asia-Pacific Network Information Centre (APNIC), Paul Wilson, stated that, based on then-current rates of deployment, the available space would last for one or two decades.[13] In September 2005, a report by Cisco Systems suggested that the pool of available addresses would exhaust in as little as 4 to 5 years.[14] In 2008, a policy process started for the end-game and post-exhaustion era.[15] In 2010, a daily updated report projected the global address pool exhaustion by the first quarter of 2011, and depletion at the five regional Internet registries before the end of 2011.[16]

Comparison to IPv4
IPv6 specifies a new packet format, designed to minimize packet header processing by routers.[3][17] Because the headers of IPv4 packets and IPv6 packets are significantly different, the two protocols are not interoperable. However, in most respects, IPv6 is a conservative 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 FTP and NTPv3.

Larger address space

The main advantage of IPv6 over IPv4 is its larger address space. The length of an IPv6 address is 128 bits, compared to 32 bits in IPv4.[3] The address space therefore has 2128 or approximately 3.41038 addresses. By comparison, this amounts to approximately 4.81028 addresses for each of the seven billion people alive in 2011.[18] In addition, the IPv4 address space is poorly allocated, with approximately 14% of all available addresses utilized.[19] While these Decomposition of an IPv6 address into its binary numbers are large, it was not the intent of the designers of the IPv6 form address space to assure geographical saturation 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 (CIDR) methods were developed to make the best use of the small address space. The standard size of a subnet in 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 is 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.[20][21] 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.

IPv6

Multicasting
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.[22] 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 multicast to address 224.0.0.1. 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.[23] In 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 very arcane.[24] 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 applications.[25]

Stateless address autoconfiguration (SLAAC)

IPv6 hosts can configure themselves automatically when connected to a routed IPv6 network using 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; if configured suitably, routers respond to such a request with a router advertisement packet that contains network-layer configuration parameters.[26] If IPv6 stateless address autoconfiguration 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 statically. Routers present a special case of requirements for address configuration, as they often are sources for autoconfiguration information, such as router and prefix advertisements. Stateless configuration for routers can be achieved with a special router renumbering protocol.[27]

Mandatory network-layer security

Internet Protocol Security (IPsec) was originally developed for IPv6, but found widespread deployment first in IPv4, into which it was back-engineered. IPsec is an integral part of the base protocol suite in IPv6.[3] IPsec support is mandatory in IPv6[28] but optional for IPv4.

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 size of IPv4 packet headers, packet processing by routers is generally more efficient,[3][17] thereby extending the end-to-end principle of Internet design. Specifically: The packet header in IPv6 is simpler than that used in IPv4, with many rarely used fields moved to separate optional header extensions. IPv6 routers do not perform fragmentation. IPv6 hosts are required to either perform path MTU discovery, perform end-to-end fragmentation, or to send packets no larger than the IPv6 default minimum MTU size of 1280 octets. The IPv6 header is not protected by a checksum; integrity protection is assumed to be assured by both link-layer and higher-layer (TCP, UDP, etc.) error detection. UDP/IPv4 may actually have a checksum of 0, indicating no

IPv6 checksum; IPv6 requires UDP to have its own checksum. Therefore, IPv6 routers do not need to recompute a checksum when header fields (such as the time to live (TTL) or hop count) change. This improvement may have been made less necessary by the development of routers that perform checksum computation at link speed using dedicated hardware, but it is still relevant for software based routers. The TTL field of IPv4 has been renamed to Hop Limit, reflecting the fact that routers are no longer expected to compute the time a packet has spent in a queue.

Mobility
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 renumbering.[29]

Options extensibility
The IPv6 protocol header has a fixed size (40 octets). Options are implemented as additional extension headers after the IPv6 header, which limits their size only by the size of an entire packet. The extension header mechanism makes the protocol extensible in that it allows future services for quality of service, security, mobility, and others to be added without redesign of the basic protocol.[3]

Jumbograms
IPv4 limits packets to 65535 (2161) octets of payload. An IPv6 node can optionally handle packets over this limit, referred to as jumbograms, which can be as large as 4294967295 (2321) octets. The use of jumbograms may improve performance over high-MTU links. The use of jumbograms is indicated by the Jumbo Payload Option header.[30]

Packet format
The IPv6 packet is composed of two parts: the packet header and the payload. The header consists of a fixed portion with minimal functionality required for all packets and may contain optional extension 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 a pointer for extension headers if any. The Next Header field, present in each extension as well, points to the next element in the chain of extensions. The last field points to the upper-layer protocol that is carried in the packet's payload.

IPv6 packet header

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 IPsec framework. The payload can have a size of up to 64KB without special options, or larger with a jumbo payload option in a Hop-By-Hop Options extension header. Unlike in IPv4, fragmentation is handled only in the end points of a communication session; routers never fragment a packet, and hosts are expected to use Path MTU Discovery to select a packet size that can traverse the entire communications path.

IPv6

Addressing
The most obvious advantage of IPv6 is its much larger address space than in IPv4. IPv6 addresses are 128 bits long, compared to only 32 bits previously.[31] While the IPv4 address space contains only about 4.3109 (4.3 billion) addresses, IPv6 defines approximately 3.41038 (340 undecillion) unique addresses, deemed enough for the foreseeable future.[32] IPv6 addresses are written in eight groups of four hexadecimal digits separated by colons, for example, 2001:0db8:85a3:0000:0000:8a2e:0370:7334. IPv6 unicast addresses other than those that start with binary 000 are logically divided into two parts: a 64-bit (sub-)network prefix, and a 64-bit interface identifier.[33] For stateless address autoconfiguration (SLAAC) to work, subnets require a /64 address block as defined in RFC 4291 section 2.5.1. Local Internet registries get assigned at least /32 blocks, which they divide among ISPs.[34] The obsolete RFC 3177 recommended the assignment of a /48 to end consumer sites. 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 initial trials Comcast customers have been given a single /64 network.[35] 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. Some IPv6 addresses are reserved for special purposes, such as the address for loopback, 6to4 tunneling, Teredo tunneling and several more. See 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 resolution, the 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.

Address format
IPv6 addresses have two logical parts: a 64-bit network prefix, and a 64-bit host address part. (The host address is often automatically generated from the interface MAC address.[36]) An IPv6 address is represented by 8 groups of 16-bit hexadecimal values separated by colons (:) shown as follows: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 The hexadecimal digits are case-insensitive. The 128-bit IPv6 address can be abbreviated with the following rules: Rule one: Leading zeroes within a 16-bit value may be omitted. For example, the address fe80:0000:0000:0000:0202:b3ff:fe1e:8329 may be written as fe80:0:0:0:202:b3ff:fe1e:8329 Rule two: One group of consecutive zeroes within an address may be replaced by a double colon. For example, fe80:0:0:0:202:b3ff:fe1e:8329 becomes fe80::202:b3ff:fe1e:8329 A single IPv6 address can be represented in several different ways, such as 2001:db8::1:0:0:1 and 2001:0DB8:0:0:1::1. RFC 5952 recommends a canonical textual representation.

IPv6

Transition mechanisms
Until IPv6 completely supplants IPv4, a number of transition mechanisms[37] 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. For the period while IPv6 hosts and routers co-exist with IPv4 systems various proposals have been made: RFC 2185, Routing Aspects of IPv6 Transition RFC 2766, Network Address Translation Protocol Translation NAT-PT, obsoleted as explained in RFC 4966 Reasons to Move the Network Address Translator Protocol Translator NAT-PT to Historic Status RFC 3053, IPv6 Tunnel Broker RFC 3056, 6to4. Connection of IPv6 Domains via IPv4 Clouds RFC 3142, An IPv6-to-IPv4 Transport Relay Translator RFC 4213, Basic Transition Mechanisms for IPv6 Hosts and Routers RFC 4380, Teredo: Tunneling IPv6 over UDP through Network Address Translations NATs RFC 4798, Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE) RFC 5214, Intra-Site Automatic Tunnel Addressing Protocol ISATAP RFC 5569, IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) RFC 5572, IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) RFC 6180, Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment RFC 6343, Advisory Guidelines for 6to4 Deployment

Dual IP stack implementation

The dual-stack protocol implementation in an operating system is a fundamental IPv4-to-IPv6 transition technology. It implements IPv4 and IPv6 protocol stacks either independently or in a hybrid form. The hybrid form is commonly implemented in modern operating systems that implement IPv6. Dual-stack hosts are described in RFC 4213. Modern hybrid dual-stack implementations of IPv4 and IPv6 allow programmers to write networking code that works transparently on IPv4 or IPv6. The software may use hybrid sockets designed to accept both IPv4 and IPv6 packets. When used in IPv4 communications, hybrid stacks use an IPv6 application programming interface and represent IPv4 addresses in a special address format, the IPv4-mapped IPv6 address. IPv4-mapped IPv6 addresses Hybrid dual-stack IPv6/IPv4 implementations recognize a special class of addresses, the IPv4-mapped IPv6 addresses. This address type has its first 80 bits set to zero and the next 16 bits are set to one, while its last 32 bits are filled with the IPv4 address. These addresses are commonly represented in the standard IPv6 format, but having the last 32 bits written in the customary dot-decimal notation of IPv4; for example, ::ffff:192.0.2.128 represents the IPv4 address 192.0.2.128. It substitutes the old and deprecated IPv4-compatible IPv6 address formed by ::192.0.2.128.[38] Because of the significant internal differences between IPv4 and IPv6, some of the lower level functionality available to programmers in the IPv6 stack do not work identically with IPv4 mapped addresses. Some common IPv6 stacks do not implement the IPv4-mapped address feature, either because the IPv6 and IPv4 stacks are separate implementations (e.g., Microsoft Windows 2000, XP, and Server 2003), or because of security concerns (OpenBSD).[39] 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.[40]

IPv6

Tunneling
In order to reach the IPv6 Internet, an isolated host or network must use the existing IPv4 infrastructure to carry IPv6 packets. This is done using a technique known as tunneling which consists of encapsulating IPv6 packets within IPv4, in effect using IPv4 as a link layer for IPv6. The direct encapsulation of IPv6 datagrams within IPv4 packets is indicated by IP protocol number 41. IPv6 can also be encapsulated within UDP packets e.g. in order to cross a router or NAT device that blocks protocol 41 traffic. Other encapsulation schemes, such as used in AYIYA or GRE, are also popular. Conversely, on IPv6-only internet links, when access to IPv4 network facilities are needed, tunneling of IPv4 over IPv6 protocol occurs, using the IPv6 as a link layer for IPv4. Automatic tunneling Automatic tunneling refers to a technique where the routing infrastructure automatically determines the tunnel endpoints. 6to4 is recommended by RFC 3056 tunneling method for automatic tunneling, which uses protocol 41 encapsulation.[41] 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. Teredo is an automatic tunneling technique that uses UDP encapsulation and can allegedly cross multiple NAT boxes.[42] IPv6, including 6to4 and Teredo tunneling, are enabled by default in Windows Vista[43] and Windows 7. Most Unix systems implement only 6to4, but Teredo can be provided by third-party software such as Miredo. ISATAP[44] treats 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 tunnelling mechanisms, ISATAP is an intra-site mechanism, meaning that it is designed to provide IPv6 connectivity between nodes within a single organisation. Configured and automated tunneling (6in4) In configured tunneling, the tunnel endpoints are explicitly configured, either by an administrator manually or the operating system's configuration mechanisms, or by an automatic service known as a tunnel broker;[45] 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 behaviour 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 available 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, suitable 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 due to a number of criticisms,[46] however more recently the continued low adoption of IPv6 has prompted a new standardization effort under the name NAT64.

IPv6

Application transition
RFC 4038, Application Aspects of IPv6 Transition, is an informational RFC that covers the topic of IPv4 to IPv6 application transition mechanisms. Other RFCs that pertain IPv6 at the application level are: RFC 3493, Basic Socket Interface Extensions for IPv6 RFC 3542, Advanced Sockets Application Program Interface (API) for IPv6 Similar to the OS-level WAN stack, applications can be: IPv4 only IPv6 only dual set of IPv4 and IPv6 only hybrid IPv4 and IPv6

IPv6 readiness
Compatibility with 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. The American Registry for Internet Numbers (ARIN) suggests that all Internet servers be prepared to serve IPv6-only clients by January 2012.[47]

Software
Most personal computers running recent operating system versions are IPv6-ready. Most popular applications with network capabilities are ready, and most others could be easily upgraded with help from the developers. Java applications adhering to Java 1.4 (February 2002) standards work with IPv6.[48]

Hardware and embedded systems

Low-level equipment such as network adapters and network switches may not be affected by the change, since they transmit link-layer frames without inspecting the contents. However, networking devices that obtain IP addresses or perform routing of IP packets do need to understand IPv6. Most equipment would be IPv6 capable with a software or firmware update if the device has sufficient storage and memory space for the new IPv6 stack. However, manufacturers may be reluctant to spend on software development costs for hardware they have already sold when they are poised for new sales from IPv6-ready equipment. In some cases, non-compliant equipment needs to be replaced because the manufacturer no longer exists or software updates are not possible, for example, because the network stack is implemented in permanent read-only memory. The CableLabs consortium published the 160 Mbit/s DOCSIS 3.0 IPv6-ready specification for cable modems in August 2006. The widely used DOCSIS 2.0 does not support IPv6. The new 'DOCSIS 2.0 + IPv6' standard supports IPv6, which may on the cable modem side require only a firmware upgrade.[49][50] It is expected that only 60% of cable modems' servers and 40% of cable modems will be DOCSIS 3.0 by 2011.[51] However, most ISPs that support DOCSIS 3.0 do not support IPv6 across their networks. Other equipment which are typically not IPv6-ready ranges from Voice over Internet Protocol devices to laboratory equipment and printers.

Deployment
The introduction of Classless Inter-Domain Routing (CIDR) in the Internet routing and IP address allocation methods in 1993 and the extensive use of network address translation (NAT) delayed the inevitable IPv4 address exhaustion, but the final phase of exhaustion started on February 3, 2011.[16] However, despite a decade long development and implementation history as a Standards Track protocol, general worldwide deployment is still in its infancy. As of October 2011, about 3% of domain names and 12% of the networks on the internet have IPv6

IPv6 protocol support.[52] Nevertheless, IPv6 has been implemented on all major operating systems in use in commercial, business, and home consumer environments.[53] Since 2008, the domain name system can be used in IPv6 as major web sites like Google, although sometimes with extra configuration.[54] IPv6 was first used in a major world event during the 2008 Summer Olympic Games,[55] the largest showcase of IPv6 technology since the inception of IPv6.[56] Countries like China or the Federal U.S. Government are also starting to require IPv6 capability on their equipment. Finally, modern cellular telephone specifications mandate IPv6 operation and deprecate IPv4 as an optional capability.[57]

10

Controversy
Privacy extensions are, except for the Windows platform and Mac OS X since 10.7 as well as iOS since version 4.3, not enabled by default. The fact that the unique MAC address is exposed to the Internet and therefore makes devices trackable has led to criticism in various countries. Two actions are necessary to guarantee the same level as with today's IPv4 networks: the client device has the privacy extensions enabled, and the provider dynamically assigns a varying address block to the client device.[58][59][60][61][62]

References
[1] http:/ / www. itwire. com/ business-it-news/ networking/ 46689-ipv6-traffic-volumes-going-backwards [2] eweek.com (http:/ / www. eweek. com/ c/ a/ IT-Infrastructure/ IPv4-Address-Exhaustion-Not-Instant-Cause-for-Concern-with-IPv6-in-Wings-287643/ ) [3] RFC 2460, Internet Protocol, Version 6 (IPv6) Specification, S. Deering, R. Hinden (December 1998) [4] S. H. Gunderson (Google) (October 2008). "Global IPv6 Statistics Measuring the current state of IPv6 for ordinary users" (http:/ / www. ripe. net/ ripe/ meetings/ ripe-57/ presentations/ Colitti-Global_IPv6_statistics_-_Measuring_the_current_state_of_IPv6_for_ordinary_users_. 7gzD. pdf) (PDF). RIPE 57. Dubai. . Retrieved 2012-01-20. [5] Google IPv6 Conference 2008: What will the IPv6 Internet look like? (http:/ / www. youtube. com/ watch?v=mZo69JQoLb8). Event occurs at 13:35. . [6] RFC 1752 The Recommendation for the IP Next Generation Protocol, S. Bradner, A. Mankin, January 1995. [7] RFC 1550, IP: Next Generation (IPng) White Paper Solicitation, S. Bradner, A. Mankin (December 1993) [8] History of the IPng Effort (http:/ / playground. sun. com/ ipv6/ doc/ history. html) [9] "River of IPv4 addresses officially runs dry" (http:/ / arstechnica. com/ tech-policy/ news/ 2011/ 02/ river-of-ipv4-addresses-officially-runs-dry). arsttechnica.com. . [10] Rashid, Fahmida Y. (February 3, 2011). "IPv4 Address Depletion Adds Momentum to IPv6 Transition" (http:/ / www. eweek. com/ c/ a/ IT-Infrastructure/ IPv4-Address-Depletion-Adds-Momentum-to-IPv6-Transition-875751/ ). eWeek.com. . Retrieved February 3, 2011. [11] "Two /8s allocated to APNIC from IANA" (http:/ / www. apnic. net/ publications/ news/ 2011/ delegation). APNIC. 2010-01-01. . Retrieved 2011-02-03. [12] Asia-Pacific Network Information Centre (15 April 2011). "APNIC IPv4 Address Pool Reaches Final /8" (http:/ / www. apnic. net/ publications/ news/ 2011/ final-8). . Retrieved 15 April 2011. [13] Exec: No shortage of Net addresses By John Lui, CNETAsia (http:/ / news. zdnet. com/ 2100-1009_22-1020653. html) [14] A Pragmatic Report on IPv4 Address Space Consumption by Tony Hain, Cisco Systems (http:/ / www. cisco. com/ web/ about/ ac123/ ac147/ archived_issues/ ipj_8-3/ ipv4. html) [15] Proposed Global Policy for the Allocation of the Remaining IPv4 Address Space (http:/ / www. ripe. net/ ripe/ policies/ proposals/ 2008-03. html) [16] "IPv4 Address Report" (http:/ / www. potaroo. net/ tools/ ipv4/ ). Potaroo.net. . Retrieved 2012-01-20. [17] RFC 1726, Technical Criteria for Choosing IP The Next Generation (IPng), Partridge C., Kastenholz F. (December 1994) [18] "U.S. Census Bureau" (http:/ / www. census. gov/ main/ www/ popclock. html). Census.gov. . Retrieved 2012-01-20. [19] "Moving to IPv6: Now for the hard part (FAQ)" (http:/ / news. cnet. com/ 8301-30685_3-20030482-264. html). Deep Tech. CNET News. . Retrieved 2011-02-03. [20] RFC 2071, Network Renumbering Overview: Why would I want it and what is it anyway?, P. Ferguson, H. Berkowitz (January 1997) [21] RFC 2072, Router Renumbering Guide, H. Berkowitz (January 1997) [22] RFC 1112, Host extensions for IP multicasting, S. Deering (August 1989) [23] RFC 3956, Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address, P. Savola, B. Haberman (November 2004) [24] RFC 2908, The Internet Multicast Address Allocation Architecture, D. Thaler, M. Handley, D. Estrin (September 2000) [25] RFC 3306

IPv6
[26] RFC 4862, IPv6 Stateless Address Autoconfiguration, S. Thomson, T. Narten, T. Jinmei (September 2007) [27] RFC 2894, Router Renumbering for IPv6, M. Crawford, August 2000. [28] J. Loughney, Ed. (April 2006). "IPv6 Node Requirements" (http:/ / tools. ietf. org/ html/ rfc4294#section-8). . Retrieved 7 December 2011. "Security Architecture for the Internet Protocol [RFC-4301] MUST be supported." [29] RFC 3963, Network Mobility (NEMO) Basic Protocol Support, V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert (January 2005) [30] RFC 2675, IPv6 Jumbograms, D. Borman, S. Deering, R. Hinden (August 1999) [31] RFC 4291 IP Version 6 Addressing Architecture, R. Hinden, S. Deering (February 2006) [32] "The sheer size of IPv6" (http:/ / pthree. org/ 2009/ 03/ 08/ the-sheer-size-of-ipv6/ ). Pthree.org. 2009-03-08. . Retrieved 2012-01-20. [33] RFC 4291 p. 9 [34] "IPv6 Address Allocation and Assignment Policy" (http:/ / www. ripe. net/ ripe/ docs/ ripe-512). RIPE NCC. 8 February 2011. . Retrieved 27 March 2011. [35] "Comcast Activates First Users With IPv6 Native Dual Stack Over DOCSIS" (http:/ / blog. comcast. com/ 2011/ 01/ comcast-activates-first-users-with-ipv6-native-dual-stack-over-docsis. html). Comcast. 31 January 2011. . [36] To convert a 48-bit MAC address to IPv6 EUI-64 format host address, first the 7th bit (scope bit) is flipped (so, for instance, 00 becomes 02 and vice-versa). Then 2 bytes with the value 0xFFFE are inserted between the vendor portion (the first 3 bytes) and the host portion (the last 3 bytes) of the MAC address. This pads the 48-bit address to 64 bits. "Recipe 25.1. Automatically Generating IPv6 Addresses for an Interface" (http:/ / fengnet. com/ book/ Cisco. IOS. Cookbook. 2nd/ I_0596527225_CHP_25_SECT_2. html). . Retrieved 14 March 2011. [37] "IPv6 Transition Mechanism / Tunneling Comparison" (http:/ / www. sixxs. net/ faq/ connectivity/ ?faq=comparison). Sixxs.net. . Retrieved 2012-01-20. [38] "RFC4291" (http:/ / tools. ietf. org/ html/ rfc4291). Tools.ietf.org. . Retrieved 2012-01-20. [39] "OpenBSD inet6(4) manual page" (http:/ / www. openbsd. org/ cgi-bin/ man. cgi?query=inet6& apropos=0& sektion=0& manpath=OpenBSD+ Current& arch=i386& format=html#PROTOCOLS). Openbsd.org. 2009-12-13. . Retrieved 2012-01-20. [40] "RFC 3493 - Basic Socket Interface Extensions for IPv6" (http:/ / tools. ietf. org/ html/ rfc3493#page-22). Tools.ietf.org. . Retrieved 2012-01-20. [41] RFC 3056 Connection of IPv6 Domains via IPv4 Clouds, B.Carpenter, Februari 2001. [42] RFC 4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs), C.Huitema, Februari 2006 [43] "The Windows Vista Developer Story: Application Compatibility Cookbook" (http:/ / msdn2. microsoft. com/ en-us/ library/ aa480152. aspx). Msdn2.microsoft.com. 2006-04-24. . Retrieved 2012-01-20. [44] RFC 5214 Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), F.Templin, T.Gleeson, D.Thaler, March 2008. [45] RFC 3053, IPv6 Tunnel Broker, A.Durand, P.Fasano, I.Guardini, D.Lento (January 2001) [46] RFC 4966 Reasons to Move the Network Address Translator Protocol Translator (NAT-PT) to Historic Status [47] Web sites must support IPv6 by 2012, expert warns (http:/ / www. networkworld. com/ news/ 2010/ 012110-ipv6-warning. html). Network World. 21 January 2010. . Retrieved 2010-09-30. [48] "Networking IPv6 User Guide for JDK/JRE 5.0" (http:/ / java. sun. com/ j2se/ 1. 5. 0/ docs/ guide/ net/ ipv6_guide/ index. html). . Retrieved 2007-09-30. [49] "DOCSIS 2.0 Interface" (http:/ / www. cablemodem. com/ specifications/ specifications20. html). Cablemodem.com. 2007-10-29. . Retrieved 2009-08-31. [50] "RMV6TF.org" (http:/ / rmv6tf. org/ 2008-IPv6-Summit-Presentations/ Dan Torbet - IPv6andCablev2. pdf) (PDF). . Retrieved 2012-01-20. [51] "DOCSIS 3.0 Network Equipment Penetration to Reach 60% by 2011" (http:/ / www. abiresearch. com/ abiprdisplay. jsp?pressid=710) (Press release). ABI Research. 2007-08-23. . Retrieved 2007-09-30. [52] Mike Leber (2010-10-02). "Global IPv6 Deployment Progress Report" (http:/ / bgp. he. net/ ipv6-progress-report. cgi). Hurricane Electric. . Retrieved 2011-10-19. [53] Comparison of IPv6 support in operating systems Comparison of IPv6 support in operating systems [54] "Google over IPv6" (http:/ / www. google. com/ intl/ en/ ipv6/ ). Google.com. . Retrieved 2012-01-20. [55] "Beijing2008.cn leaps to next-generation Net" (http:/ / en. beijing2008. cn/ news/ official/ preparation/ n214384681. shtml) (Press release). The Beijing Organizing Committee for the Games of the XXIX Olympiad. 2008-05-30. . [56] Das, Kaushik (2008). "IPv6 and the 2008 Beijing Olympics" (http:/ / ipv6. com/ articles/ general/ IPv6-Olympics-2008. htm). IPv6.com. . Retrieved 2008-08-15. "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." [57] Derek Morr (2009-06-09). "Verizon Mandates IPv6 Support for Next-Gen Cell Phones" (http:/ / www. circleid. com/ posts/ 20090609_verizon_mandates_ipv6_support_for_next_gen_cell_phones/ ). CircleID. . [58] T. Narten, R. Draves (2001-01). "Privacy Extensions for Stateless Address Autoconfiguration in IPv6" (http:/ / www. ietf. org/ rfc/ rfc3041. txt). . [59] Statement on IPv6 Address Privacy, Steve Deering & Bob Hinden, Co-Chairs of the IETF's IP Next Generation Working Group , 1999-11-06. (ftp:/ / ftp. cuhk. edu. hk/ pub/ doc/ ipng/ html/ ipv6-address-privacy. html) [60] IPv6: Privacy Extensions einschalten, Reiko Kaps, 2011-04-13 (http:/ / www. heise. de/ netze/ artikel/ IPv6-Privacy-Extensions-einschalten-1204783. html) [61] Privacy Extensions (IPv6), Elektronik Kompendium. (http:/ / www. elektronik-kompendium. de/ sites/ net/ 1601271. htm)

11

IPv6
[62] Neues Internet-Protokoll erschwert anonymes Surfen, Konrad Lischka, Spiegel Online, 2010-11-18. (http:/ / www. spiegel. de/ netzwelt/ web/ 0,1518,729340,00. html)

12

External links
IPv6 (http://www.dmoz.org/Computers/Internet/Protocols/IP/IPv6/) at the Open Directory Project Why IPv6 matters to radio stations (http://radioworld.com/article/why-ipv6-matters-to-your-station/23533) Security implications of implementing IPv6 (http://cert.inteco.es/extfrontinteco/img/File/intecocert/ EstudiosInformes/cert_inf_security_implications_ipv6.pdf) Free Pool of IPv4 Address Space Depleted (http://www.nro.net/news/ipv4-free-pool-depleted)

IPv6 address
An Internet Protocol Version 6 address (IPv6 address) is a numerical label that is used to identify a network interface of a computer or other network node participating in an IPv6-enabled computer network. IP addresses serve the purpose of uniquely identifying the individual network interface(s) of a host, locating it on the network, and thus permitting the routing of IP packets between hosts. For routing, IP addresses are present in fields of the packet header where they indicate source and destination of the packet. IPv6 is the successor to the Internet's first addressing infrastructure, Internet Protocol version 4 (IPv4). In contrast to IPv4, which defined an IP address as a 32-bit number, IPv6 addresses have a size of 128 bits. Therefore, IPv6 has a vastly enlarged address space compared to IPv4.

IPv6 address classes

IPv6 addresses are classified by the primary addressing and routing methodologies common in networking: unicast addressing, anycast addressing, and multicast [1] addressing. A unicast address identifies a single network interface. The Internet Protocol delivers packets sent to a unicast address to that specific interface. An anycast address is assigned to a group Decomposition of an IPv6 address into its binary form. of interfaces, usually belonging to different nodes. A packet sent to an anycast address is delivered to just one of the member interfaces, typically the nearest host, according to the routing protocols definition of distance. Anycast addresses cannot be identified easily, they have the same format of unicast addresses, and differ only by their presence in the network at multiple points. Almost any unicast address can be employed as an anycast address. A multicast address is also used by multiple hosts, which acquire the multicast address destination by participating in the multicast distribution protocol among the network routers. A packet that is sent to a multicast address is delivered to all interfaces that have joined the corresponding multicast group. IPv6 does not implement broadcast addressing. Broadcast's traditional role is subsumed by multicast addressing to the all-nodes link-local multicast group ff02::1. However, the use of the all-nodes group is not recommended, and most IPv6 protocols use a dedicated link-local multicast group to avoid disturbing every interface in the network.

IPv6 address

13

Address formats
An IPv6 address consists of 128 bits.[1] Addresses are classified into various types for applications in the major addressing and routing methodologies: unicast, multicast, and anycast networking. In each of these, various address formats are recognized by logically dividing the 128 address bits into bit groups and establishing rules for associating the values of these bit groups with special addressing features.

Unicast and anycast address format

Unicast and anycast addresses are typically composed of two logical parts: a 64-bit network prefix used for routing, and a 64-bit interface identifier used to identify a host's network interface.

General unicast address format (routing prefix size varies)

bits 48 (or more) 16 (or fewer) subnet id 64 interface identifier

field routing prefix

The network prefix (the routing prefix combined with the subnet id) is contained in the most significant 64 bits of the address. The size of the routing prefix may vary; a larger prefix size means a smaller subnet id size. The bits of the subnet id(entifier) field are available to the network administrator to define subnets within the given network. The 64-bit interface identifier is either automatically generated from the interface's MAC address using the modified EUI-64 format, obtained from a DHCPv6 server, automatically established randomly, or assigned manually. A link-local address is also based on the interface identifier, but uses a different format for the network prefix.

Link-local address format

bits 10 54 64

field prefix zeroes interface identifier

The prefix field contains the binary value 1111111010. The 54 zeroes that follow make the total network prefix the same for all link-local addresses, rendering them non-routable.

Multicast address format

Multicast addresses are formed according to several specific formatting rules, depending on the application.

General multicast address format

bits 8 4 4 112

field prefix flg sc group ID

The prefix holds the binary value 11111111 for any multicast address. Currently, 3 of the 4 flag bits in the flg field are defined;[1] the most-significant flag bit is reserved for future use.

IPv6 address

14

Multicast address flags[2]

bit 8 9 flag reserved R (Rendezvous) Meaning when 0 reserved reserved Meaning when 1

[3] Rendezvous point not embedded Rendezvous point embedded Without prefix information Well-known multicast address Address based on network prefix Dynamically assigned multicast address

10 P (Prefix)[4] 11 T (Transient)[1]

The 4-bit scope field (sc) is used to indicate where the address is valid and unique. There are special multicast addresses, like Solicited Node.

Solicited-Node multicast address format

bits 8 4 4 79 9 24

field prefix flg sc zeroes ones unicast address

The sc(ope) field holds the binary value 0010 (link-local). Solicited-node multicast addresses are computed as a function of a node's unicast or anycast addresses. A solicited-node multicast address is created by copying the last 24 bits of a unicast or anycast address to the last 24 bits of the multicast address.

Unicast-prefix-based multicast address format[4][3]

bits 8 4 4 4 4 8 64 32

field prefix flg sc res riid plen network prefix group ID

Link-scoped multicast addresses use a comparable format.[5]

Presentation
An IPv6 address is represented as eight groups of four hexadecimal digits, each group representing 16 bits (two octets). The groups are separated by colons (:). An example of an IPv6 address is: 2001:0db8:85a3:0000:0000:8a2e:0370:7334 The hexadecimal digits are case-insensitive when used, but should be represented in lower case.[6] The full representation of eight 4-digit groups may be simplified by several techniques, eliminating parts of the representation. Leading zeroes Leading zeroes in a group may be omitted, but each group must contain at least one hexadecimal digit.[1] Thus, the example address may be written as: 2001:db8:85a3:0:0:8a2e:370:7334 Groups of zeroes One or more consecutive groups of zero value may be replaced with a single empty group using two consecutive colons (::).[1] Substitution may only be applied once in an address, because multiple occurrences would create an ambiguous representation. If more than one such substitution could be applied, the substitution that replaces the most groups should be used; if the number of groups are equal then the leftmost substitution should be used.[6] With these rules, the example address is further simplified: 2001:db8:85a3::8a2e:370:7334

IPv6 address The localhost (loopback) address, 0:0:0:0:0:0:0:1, and the IPv6 unspecified address, 0:0:0:0:0:0:0:0, are reduced to ::1 and ::, respectively. Dotted-quad notation During the transition of the Internet from IPv4 to the IPv6 it is typical to operate in a mixed addressing environment, and for this purpose a special notation has been introduced to express IPv4-mapped and IPv4-compatible IPv6 addresses by writing the final 32 bits of an address in the familiar IPv4 dotted-quad notation. For example, the IPv4-mapped IPv6 address ::ffff:c000:280 is usually written as ::ffff:192.0.2.128, thus expressing clearly the original IPv4 address that was mapped to IPv6.

15

Networks
An IPv6 network uses an address block that is a contiguous group of IPv6 addresses of a size that is a power of two. The leading set of bits of the addresses are identical for all hosts in a given network, and are called the network's address or routing prefix. Network address ranges are written in CIDR notation. A network is denoted by the first address in the block (ending in all zeroes), a slash (/), and a decimal value equal to the size in bits of the prefix. For example, the network written as 2001:db8:1234::/48 starts at address 2001:db8:1234:0000:0000:0000:0000:0000 and ends at 2001:db8:1234:ffff:ffff:ffff:ffff:ffff. The routing prefix of an interface address may be directly indicated with the address by CIDR notation. For example, the configuration of an interface with address 2001:db8:a::123 connected to subnet 2001:db8:a::/64 is written as 2001:db8:a::123/64.

Address block sizes

The size of a block of addresses is indicated simply by a slash (/) and the decimal size of the network prefix, without specifying which specific addresses are in the block. For instance, an address block with 48 bits in the prefix is indicated by /48. Such a block contains 2128 48 = 280 addresses. The smaller the size of the network prefix, the larger the block: a /21 block is 8 times larger than a /24 block.

Literal IPv6 addresses in network resource identifiers

Colon (:) characters in IPv6 addresses may conflict with the established syntax of resource identifiers, such as URIs and URLs. The colon has traditionally been used to terminate the host path before a port number.[7] To alleviate this conflict, literal IPv6 addresses are enclosed in square brackets in such resource identifiers, for example: http://[2001:db8:85a3:8d3:1319:8a2e:370:7348]/ When the URL also contains a port number the notation is: https://[2001:db8:85a3:8d3:1319:8a2e:370:7348]:443/

Literal IPv6 addresses in UNC path names

In Microsoft Windows operating systems, IPv4 addresses are valid location identifiers in Uniform Naming Convention (UNC) path names. However, the colon is an illegal character in a UNC path name. Thus, the use of IPv6 addresses is also illegal in UNC names. For this reason, Microsoft implemented a transcription algorithm to represent an IPv6 address in form of a domain name that can be used in UNC paths. For this purpose, Microsoft registered and reserved the second-level domain ipv6-literal.net on the Internet. IPv6 addresses are transcribed as a hostname or subdomain name within this name space, in the following fashion: 2001:db8:85a3:8d3:1319:8a2e:370:7348 is written as

IPv6 address 2001-db8-85a3-8d3-1319-8a2e-370-7348.ipv6-literal.net This notation is automatically resolved by Microsoft software without any queries to DNS name servers. If the IPv6 address contains a zone index, it is appended to the address portion after an 's' character: fe80--1s4.ipv6-literal.net

16

IPv6 address scopes

Every IPv6 address, except the unspecified address (::), has a "scope",[8] which specifies in which part of the network it is valid. In the unicast addressing class, link-local addresses and the loopback address have link-local scope, which means they are to be used in the directly attached network (link). All other addresses, have global (or universal) scope, which means they are globally routable, and can be used to connect to addresses with global scope anywhere, or addresses with link-local scope on the directly attached network. The scope of an anycast address is defined identically to that of a unicast address. For multicasting, the four least-significant bits of the second address octet of a multicast address (ff0s::) identify the address scope, i.e. the span over which the multicast address is propagated. Currently defined scopes[1] are:

Scope values
Value 0x0 0x1 0x2 0x4 Scope name reserved interface-local link-local admin-local Interface-local scope spans only a single interface on a node, and is useful only for loopback transmission of multicast. Link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes. Admin-local scope is the smallest scope that must be administratively configured, i.e., not automatically derived from physical connectivity or other, non- multicast-related configuration. Link-local and site-local multicast scopes span the same topological regions as the corresponding unicast scopes. Notes

0x5 0x8 0xe 0xf

site-local

organization-local Organization-local scope is intended to span multiple sites belonging to a single organization. global reserved

IPv6 address space

General allocation
The management of IPv6 address allocation process is delegated to the Internet Assigned Numbers Authority (IANA)[9] by the Internet Architecture Board and the Internet Engineering Steering Group. Its main function is the assignment of large address blocks to the regional Internet registries (RIRs), which have the delegated task of allocation to network service providers and other local registries. The IANA has maintained the official list of allocations of the IPv6 address space since December 1995.[10] Only one eighth of the total address space is currently allocated for use on the Internet, 2000::/3, in order to provide efficient route aggregation, thereby reducing the size of the Internet routing tables; the rest of the IPv6 address space is reserved for future use or for special purposes. The address space is assigned to the RIRs in large blocks of /23 up to /12.[11] The RIRs assign smaller blocks to Local Internet registries that distributes them to users. These are typically in sizes from /19 to /32.[12][13][14] The addresses are typically distributed in /48 to /56 sized blocks to the end users.[15]

IPv6 address Global unicast assignment records can be found at the various RIRs or other websites.[16] IPv6 addresses are assigned to organizations in much larger blocks as compared to IPv4 address assignmentsthe recommended allocation is a /48 block which contains 280 addresses, being 248 or about 2.81014 times larger than the entire IPv4 address space of 232 addresses and about 7.21016 times larger than the /8 blocks of IPv4 addresses, which are the largest allocations of IPv4 addresses. The total pool, however, is sufficient for the foreseeable future, because there are 2128 or about 3.41038 (340 trillion trillion trillion) unique IPv6 addresses. Each RIR can divide each of its multiple /23 blocks into 512 /32 blocks, typically one for each ISP; an ISP can divide its /32 block into 65536 /48 blocks, typically one for each customer;[17] customers can create 65536 /64 networks from their assigned /48 block, each having a number of addresses that is the square of the number of addresses of the entire IPv4 address space, which only supports 232 or about 4.3109 addresses. By design, only a very small fraction of the address space will actually be used. The large address space ensures that addresses are almost always available, which makes the use of network address translation (NAT) for the purposes of address conservation almost unnecessary. NAT has been increasingly used for IPv4 networks to help alleviate IPv4 address exhaustion.

17

Special allocation
To allow for provider changes without renumbering, Provider-independent address space assigned directly to the end user by the RIRs is taken from the special range 2001:678::/29. Internet Exchange Points (IXPs) are assigned special addresses from the range 2001:7f8::/29 for communication with their connected ISPs.[18] Root name servers have been assigned addresses from the same range.

Reserved anycast addresses

The lowest address within each subnet prefix (the interface identifier set to all zeroes) is reserved as the "subnet-router" anycast address.[1] Applications may use this address when talking to any one of the available routers, as packets sent to this address are delivered to just one router. The 128 highest addresses within each /64 subnet prefix are reserved to be used as anycast addresses.[19] These addresses usually have the 57 first bits of the interface identifier set to 1, followed by the 7-bit anycast ID. Prefixes for the network, including subnets, are required to have a length of 64 bits, in which case the universal/local bit must be set to 0 to indicate the address is not globally unique. The address with value 0x7e in the 7 least-significant bits is defined as a mobile IPv6 home agents anycast address. The address with value 0x7f (all bits 1) is reserved and may not be used. No more assignments from this range are made, so values 0x00 through 0x7d are reserved as well.

Special addresses
There are a number of addresses with special meaning in IPv6:[20]

Unicast Addresses
Unspecified address ::/128 The address with all zero bits is called the unspecified address (corresponding to 0.0.0.0/32 in IPv4). This address must never be assigned to an interface and is to be used only in software before the application has learned its host's source address appropriate for a pending connection. Routers must not forward packets with the unspecified address. Applications may be listening on one or more specific interfaces for incoming connections, which are shown in listings of active internet connections by a specific IP address (and a port number, separated by a colon). When

IPv6 address the unspecified address is shown it means that an application is listening for incoming connections on all available interfaces. Default route ::/0 The default unicast route address (corresponding to 0.0.0.0/0 in IPv4). Local addresses ::1/128 The loopback address is a unicast localhost address. If an application in a host sends packets to this address, the IPv6 stack will loop these packets back on the same virtual interface (corresponding to 127.0.0.0/8 in IPv4). fe80::/10 Addresses in the link-local prefix are only valid and unique on a single link. Within this prefix only one subnet is allocated (54 zero bits), yielding an effective format of fe80::/64. The least significant 64 bits are usually chosen as the interface hardware address constructed in modified EUI-64 format. A link-local address is required on every IPv6-enabled interfacein other words, applications may rely on the existence of a link-local address even when there is no IPv6 routing. These addresses are comparable to the auto-configuration addresses 169.254.0.0/16 of IPv4. Unique local addresses fc00::/7 Unique local addresses (ULAs) are intended for local communication. They are routable only within a set of cooperating sites (analogous to the private address ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 of IPv4).[21] The addresses include a 40-bit pseudorandom number in the routing prefix intended to minimize the risk of conflicts if sites merge or packets are misrouted into the Internet. Transition from IPv4 ::ffff:0:0/96 This prefix designated an IPv4-mapped IPv6 address. With a few exceptions, this address type allows the transparent use of the Transport Layer protocols over IPv4 through the IPv6 networking application programming interface. Server applications only need to open a single listening socket to handle connections from clients using IPv6 or IPv4 protocols. IPv6 clients will be handled natively by default, and IPv4 clients appear as IPv6 clients at their IPv4-mapped IPv6 address. Transmission is handled similarly; established sockets may be used to transmit IPv4 or IPv6 datagram, based on the binding to an IPv6 address, or an IPv4-mapped address. (See also Transition mechanisms.) ::ffff:0:0:0/96 A prefix used for IPv4-translated addresses which are used by the Stateless IP/ICMP Translation (SIIT) protocol. 64:ff9b::/96 The "Well-Known" Prefix. Addresses with this prefix are used for automatic IPv4/IPv6 translation.[22] 2002::/16 This prefix is used for 6to4 addressing. Here, an address from the IPv4 network 192.88.99.0/24 is also used. Special-purpose addresses[23] IANA has reserved a so-called 'Sub-TLA ID' address block for special assignments[24] which consists of 64 network prefixes in the range 2001:0000::/29 through 2001:01f8::/29. Three assignments from this block have been made: 2001::/32 Used for Teredo tunneling (which also falls into the category of IPv6 transition mechanisms). 2001:2::/48 Assigned to the Benchmarking Methodology Working Group (BMWG)[25] for benchmarking IPv6 (corresponding to 198.18.0.0/15 for benchmarking IPv4). 2001:10::/28 ORCHID (Overlay Routable Cryptographic Hash Identifiers).[26] These are non-routed IPv6 addresses used for Cryptographic Hash Identifiers. Documentation

18

IPv6 address 2001:db8::/32 This prefix is used in documentation.[27] The addresses should be used anywhere an example IPv6 address is given or model networking scenarios are described (corresponding to 192.0.2.0/24, 198.51.100.0/24, and 203.0.113.0/24 in IPv4.)[28] Deprecated and obsolete addresses Further information: Historical notes

19

Multicast addresses
The multicast addresses ff00::0/12 are reserved[1] and should not be assigned to any multicast group. The Internet Assigned Numbers Authority (IANA) manages address reservations.[29] Some common IPv6 multicast addresses are the following:
Address ff0X::1 Description All nodes address, identify the group of all IPv6 nodes Available Scopes Available in scope 1 (interface-local) and 2 (link-local): ff01::1 All nodes in the interface-local ff02::1 All nodes in the link-local

ff0X::2

All routers

Available in scope 1 (interface-local), 2 (link-local) and 5 (site-local): ff01::2 All routers in the interface-local ff02::2 All routers in the link-local ff05::2 All routers in the site-local

ff02::5 ff02::6 ff02::9 ff02::a ff02::d ff0X::fb ff0X::101 ff02::1:1 ff02::1:2 ff02::1:3 ff05::1:3

OSPFIGP OSPFIGP Designated Routers RIP Routers EIGRP Routers All PIM Routers mDNSv6 All Network Time Protocol (NTP) servers Link Name All-dhcp-agents Link-local Multicast Name Resolution All-dhcp-servers

2 (link-local) 2 (link-local) 2 (link-local) 2 (link-local) 2 (link-local) Available in all scopes Available in all scopes 2 (link-local) 2 (link-local) 2 (link-local) 5 (site-local) 2 (link-local) 2 (link-local)

ff02::1:ff00:0/104 Solicited-node multicast address. See below ff02::2:ff00:0/104 Node Information Queries

IPv6 address Solicited-node multicast address The least significant 24 bits of the Solicited-node multicast address group ID are filled with the least significant 24 bits of the interface's unicast or anycast address. These addresses allow link-layer address resolution via Neighbor Discovery Protocol (NDP) on the link without disturbing all nodes on the local network. A host is required to join a Solicited-Node multicast group for each of its configured unicast or anycast addresses.

20

Stateless address autoconfiguration

On system startup, a node automatically creates a link-local address on each IPv6-enabled interface, even if globally routable addresses are manually configured or obtained through "configuration protocols" (see below). It does so independently and without any prior configuration by stateless address autoconfiguration (SLAAC),[30] using a component of the Neighbor Discovery Protocol. This address is selected with the prefix fe80::/64. In IPv4, typical "configuration protocols" include DHCP or PPP. Although DHCPv6 exists, IPv6 hosts normally use the Neighbor Discovery Protocol to create a globally routable unicast address: the host sends router solicitation requests and an IPv6 router responds with a prefix assignment.[31] The lower 64 bits of these addresses are populated with a 64-bit interface identifier in modified EUI-64 format. This identifier is usually shared by all automatically configured addresses of that interface, which has the advantage that only one multicast group needs to be joined for neighbor discovery. For this, a multicast address is used, formed from the network prefix ff02::1:ff00:0/104 and the 24 least significant bits of the address.

Modified EUI-64
A 64-bit interface identifier is most commonly derived from its 48-bit MAC address. A MAC address 00:1D:BA:06:37:64 is turned into a 64-bit EUI-64 by inserting FF:FE in the middle: 00:1D:BA:FF:FE:06:37:64. When this EUI-64 is used to form an IPv6 address it is modified:[1] the meaning of the Universal/Local bit (the 7th most significant bit of the EUI-64, starting from 1) is inverted, so that a 1 now means Universal. To create an IPv6 address with the network prefix 2001:db8:1:2::/64 it yields the address 2001:db8:1:2:021d:baff:fe06:3764 (with the underlined U/L bit inverted to a 1, because the MAC address is universally unique). The reason for modifying the U/L bit is that when using manually assigned addresses on an interface it means you can simply assign the address 2001:db8:1:2::1/64 instead of the less appealing and counter-intuitive 2001:db8:1:2:0200::1/64. When manually assigning link-local addresses, the need for this modification is even more apparent: you can assign the short address fe80::1 instead of the long fe80:0:0:0:0200::1.

Duplicate address detection

The assignment of a unicast IPv6 address to an interface involves an internal test for the uniqueness of that address using Neighbor Solicitation and Neighbor Advertisement (ICMPv6 type 135 and 136) messages. While in the process of establishing uniqueness an address has a tentative state. The node joins the solicited-node multicast address for the tentative address (if not already done so) and sends neighbor solicitations, with the tentative address as target address and the unspecified address (::/128) as source address. The node also joins the all-hosts multicast address ff02::1, so it will be able to receive Neighbor Advertisements. If a node receives a neighbor solicitation with its own tentative address as the target address, then that address is not unique. The same is true if the node receives a neighbor advertisement with the tentative address as the source of the advertisement. Only after having successfully established that an address is unique may it be assigned and used by an interface.

IPv6 address

21

Address lifetime
Each IPv6 address that is bound to an interface has a fixed lifetime. Lifetimes are infinite, unless configured to a shorter period. There are two lifetimes that govern the state of an address: the preferred lifetime and the valid lifetime.[32] Lifetimes can be configured in routers that provide the values used for autoconfiguration, or specified when manually configuring addresses on interfaces. When an address is assigned to an interface it gets the status "preferred", which it holds during its preferred-lifetime. After that lifetime expires the status becomes "deprecated" and no new connections should be made using this address. The address becomes "invalid" after its valid-lifetime also expires; the address is removed from the interface and may be assigned somewhere else on the Internet.

Temporary addresses
The globally unique and static MAC addresses, used by stateless address autoconfiguration to create interface identifiers, offer an opportunity to track user equipmentacross time and IPv6 network prefix changesand so users.[33] To reduce the prospect of a user identity being permanently tied to an IPv6 address portion, a node may create temporary addresses with interface identifiers based on time-varying random bit strings[34] and relatively short lifetimes (hours to days), after which they are replaced with new addresses. Temporary addresses may be used as source address for originating connections, while external hosts use a public address by querying the Domain Name System. Network interfaces configured for IPv6 in Windows Vista and Windows 2008 Server or later Microsoft systems use temporary addresses by default.

Default address selection

IPv6-enabled network interfaces usually have more than one IPv6 address, for example, a link-local and a global address, and permanent versus temporary addresses. IPv6 introduces the concepts of address scope and selection preference, yielding multiple choices for source and destination address selections in communication with another host. The preference selection algorithm,[35] which selects the most appropriate address to use in communications with a particular destination (including the use of IPv4-mapped addresses in dual-stack implementations), is based on a user-customizable preference table that associates each routing prefix with a precedence level. The default table is as follows:[35]

Default Prefix Policy Table

Prefix ::1/128 ::/0 2002::/16 ::/96 ::ffff:0:0/96 Precedence Label 50 40 30 20 10 0 1 2 3 4

The default configuration places preference on IPv6, rather than IPv4, and on destination addresses within the smallest possible scope, so that link-local communication is preferred over globally routed paths when otherwise equally suitable. The prefix policy table is similar to a routing table, with the precedence value serving as the role of a link cost, where higher preference is expressed as a larger value. Source addresses are preferred to have the same label value as the destination address. Addresses are matched to prefixes based on the longest matching most-significant bit-sequence. Candidate source addresses are obtained from the operating system and candidate destination addresses may be queried via the Domain Name System (DNS).

IPv6 address

22

Link-local addresses and zone indices

Because all link-local addresses in a host have a common prefix, normal routing procedures cannot be used to choose the outgoing interface when sending packets to a link-local destination. A special identifier, known as a zone index,[8] is needed to provide the additional routing information; in the case of link-local addresses, zone indices correspond to interface identifiers. When an address is written textually, the zone index is appended to the address, separated by a percent sign (%). The actual syntax of zone indices depends on the operating system: the Microsoft Windows IPv6 stack uses numeric zone indexes, e.g., fe80::3%1. The index is determined by the interface number; most Unix-like systems (e.g., BSD, Linux, Mac OS X) use the interface name as a zone index: fe80::3%eth0. Zone index notations cause syntax conflicts when used in Uniform Resource Identifiers (URI), as the '%' character also designates percent-encoding.[36]

IPv6 addresses 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 lookup the 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. As in IPv4, each host is represented in the DNS by two DNS records, an address record and a reverse mapping pointer record. For example, a host computer named derrick in zone example.com has the Unique Local Address fdda:5cc1:23:4::1f. Its quad-A address record is derrick.example.com. and its IPv6 pointer record is
f.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.4.0.0.0.3.2.0.0.1.c.c.5.a.d.d.f.ip6.arpa. IN PTR derrick.example.com.

IN

AAAA

fdda:5cc1:23:4::1f

This pointer record may be defined in a number of zones, depending on the chain of delegation of authority in the zone d.f.ip6.arpa. The DNS protocol is independent of its Transport Layer protocol. Queries and replies may be transmitted over IPv6 or IPv4 transports regardless of the address family of the data requested.

AAAA record fields

NAME TYPE CLASS TTL Domain name AAAA (28) Internet (1) Time to live in seconds

RDLENGTH Length of RDATA field RDATA [1] String form of the IPV6 address

IPv6 address

23

Transition challenges
As of 2009, many DNS resolvers in home-networking NAT devices and routers still handle AAAA records improperly.[37] Some of these simply drop DNS requests for such records, instead of properly returning the appropriate negative DNS response. Because the request is dropped, the host sending the request has to wait for a timeout to trigger. This often causes a perceived slow down when connecting to IPv6 hosts.

Historical notes
Deprecated and obsolete addresses
The site-local prefix fec0::/10 specifies that the address is valid only within the site network of an organization. It was part of the original addressing architecture[38] in December 1995, but its use was deprecated in September 2004[39] because the definition of the term site was ambiguous, which led to confusing routing rules. New networks must not support this special type of address. In October 2005, a new specification[40] replaced this address type with unique local addresses. The address block 0200::/7 was defined as an OSI NSAP-mapped prefix set in August 1996,[41][42] but was deprecated in December 2004.[43] The 96-bit zero-value prefix ::/96, originally known as IPv4-compatible addresses, was mentioned in 1995[38] but first described in 1998.[44] This class of addresses was used to represent IPv4 addresses within an IPv6 transition technology. Such an IPv6 address has its first (most significant) 96 bits set to zero, while its last 32 bits are the IPv4 address that is represented. In February 2006, the Internet Engineering Task Force (IETF) has deprecated the use of IPv4-compatible addresses.[1] The only remaining use of this address format is to represent an IPv4 address in a table or database with fixed size members that must also be able to store an IPv6 address. Address block 3ffe::/16 was allocated for test purposes for the 6bone network in December 1998.[44] Prior to that, the address block 5F00::/8 was used for this purpose. Both address blocks were returned to the address pool in June 2006.[45]

Miscellany
IPv6 addresses were originally registered in the Domain name system (DNS) in the ip6 zone under the int top-level domain for reverse lookups. In 2000, the Internet Architecture Board (IAB) reverted their intentions to retire arpa, and decided in 2001 that the arpa top-level domain should retain its original function. Domains in ip6.int should be moved to ip6.arpa.[46] The ip6.int zone was officially removed on 6 June 2006. In March 2011, the IETF refined their recommendations for allocation of address blocks to end sites.[15] Instead of assigning either a /48, /64, or /128 (according to IAB's and IESG's views of 2001),[47] Internet service providers should assign smaller blocks (up to a /56) to end users, if appropriate.

IPv6 address

24

References
[1] RFC 4291, IP Version 6 Addressing Architecture, R. Hinden, S. Deering (February 2006) [2] Silvia Hagen (May 2006). IPv6 Essentials (Second ed.). O'Reilly. ISBN978-0596100582. [3] RFC 3956, Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address P. Savola, B. Haberman (November 2004) [4] RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, B. Haberman, D. Thaler (August 2002) [5] RFC 4489, A Method for Generating Link-Scoped IPv6 Multicast Addresses, J-S. Park, M-K. Shin; H-J. Kim (April 2006) [6] RFC 5952, "A Recommendation for IPv6 Address Text Representation", S. Kawamura, M. Kawashima, (August 2010) [7] RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter (January 2005) [8] RFC 4007, IPv6 Scoped Address Architecture, S.Deering, B. Haberman, T. Jinmei, E. Nordmark, B. Zill (March 2005) [9] RFC 1881, IPv6 Address Allocation Management, Internet Architecture Board (December 1995) [10] IPv6 address space at IANA (http:/ / www. iana. org/ assignments/ ipv6-address-space). Iana.org (2010-10-29). Retrieved on 2011-09-28. [11] IPv6 unicast address assignments (http:/ / www. iana. org/ assignments/ ipv6-unicast-address-assignments/ ipv6-unicast-address-assignments. xhtml), IANA [12] DE-TELEKOM-20050113 (http:/ / www. db. ripe. net/ whois?form_type=simple& full_query_string=& searchtext=DE-TELEKOM-20050113& do_search=Search). Db.ripe.net. Retrieved on 2011-09-28. [13] "ARIN Number Resource Policy Manual: Initial allocation to ISPs" (https:/ / www. arin. net/ policy/ nrpm. html#four22). . [14] "RIPE NCC IPv6 Address Allocation and Assignment Policy: Minimum allocation" (http:/ / www. ripe. net/ ripe/ docs/ ripe-481#minimum_allocation). . [15] RFC 6177, IPv6 Address Assignment to End Sites, T. Narten, G. Houston, L. Roberts, IETF Trust,(March 2011). [16] for example (http:/ / www. iana. org/ assignments/ ipv6-unicast-address-assignments/ ipv6-unicast-address-assignments. xml). Iana.org. Retrieved on 2011-09-28. [17] "IPv6 Addressing Plans" (http:/ / www. getipv6. info/ index. php?title=IPv6_Addressing_Plans& oldid=2998). ARIN IPv6 Wiki. . Retrieved 2010-08-18. "All customers get one /48 unless they can show that they need more than 65k subnets. [...] If you have lots of consumer customers you may want to assign /56s to private residence sites." [18] "Address Space Managed by the RIPE NCC" (https:/ / www. ripe. net/ ripe/ docs/ ripe-510). . Retrieved 2011-05-22. [19] RFC 2526,Reserved IPv6 Subnet Anycast Addresses, D. Johnson, S. Deering (March 1999) [20] RFC 5156, Special-Use IPv6 Addresses, M. Blanchett (April 2008) [21] RFC 1918, Address Allocation for Private Internets, Y. Rekhter, B. Moskowitz, D. Karrenberg, G.J. De Groot, E. Lear (February 1996) [22] RFC 6052, "IPv6 Addressing of IPv4/IPv6 Translators", C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li, (October 2010) [23] RFC 4773, Administration of the IANA Special Purpose IPv6 Address Block, G. Huston (December 2006) [24] RFC 2928, Initial IPv6 Sub-TLA ID Assignments, R. Hinden, S. Deering, R. Fink, T. Hain (September 2000) The Internet Society [25] RFC 5180, IPv6 Benchmarking Methodology for Network Interconnect Devices, C. Popoviciu, A. Hamza, G. Van de Velde, D. Dugatkin (May 2008) [26] RFC 4843 (experimental), An IPv6 Prefix for Overlay Routable Cryptographic Hash Identifiers (ORCHID), P. Nikander, J. Laganier, F. Dupont (April 2007) [27] RFC 3849, IPv6 Address Prefix Reserved for Documentation, G. Huston, A. Lord, P. Smith (July 2004) [28] RFC 5737, IPv4 Address Blocks Reserved for Documentation, J. Arkko, M. Cotton, L. Vegoda (January 2010), ISSN: 2070-1721 [29] IANA Internet Protocol Version 6 Multicast Addresses (http:/ / www. iana. org/ assignments/ ipv6-multicast-addresses). [30] RFC 4862, IPv6 Stateless Address Autoconfiguration, S. Thomson, T. Narten, T. Jinmei (September 2007) [31] RFC 4861, Neighbor Discovery for IP version 6 (IPv6), T. Narten, E. Nordmark, W. Simpson, H. Holiman (September 2007) [32] Iljitsch van Beijnum (2006). "IPv6 Internals" (http:/ / www. cisco. com/ web/ about/ ac123/ ac147/ archived_issues/ ipj_9-3/ ipv6_internals. html). The Internet Protocol Journal 9 (3): pp.1629. . [33] The privacy implications of stateless IPv6 addressing (http:/ / portal. acm. org/ citation. cfm?id=1852723& dl=GUIDE& coll=GUIDE& CFID=103687796& CFTOKEN=17254293). Portal.acm.org (2010-04-21). Retrieved on 2011-09-28. [34] RFC 4941, Privacy Extensions for Stateless Address Autoconfiguration in IPv6, T. Narten, R. Draves, S. Krishnan (September 2007) [35] RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6), R. Draves, The Internet Society (February 2003) [36] Formats for IPv6 Scope Zone Identifiers in Literal Address Formats (http:/ / tools. ietf. org/ html/ draft-fenner-literal-zone-02). Tools.ietf.org. Retrieved on 2011-09-28. [37] RFC 4074 Common Misbehavior Against DNS Queries for IPv6 Addresses, Y. Morishita, T. Jinmei. May 2005. [38] RFC 1884, IP Version 6 Addressing Architecture, R. Hinden, S. Deering (December 1995) [39] RFC 3879, Deprecating Site Local Addresses, C. Huitema, B. Carpenter (September 2004) [40] RFC 4193, Unique Local IPv6 Unicast Addresses, R. Hinden, B. Haberman (October 2005) [41] RFC 4147, Proposed Changes to the Format of the IANA IPv6 Registry, G. Houston (August 2005) [42] RFC 1888, OSI NSAPs and IPv6, J. Bound, B. Carpenter, D. Harrington, J. Houldsworth, A. Lloyd (August 1996) [43] RFC 4048, RFC 1888 Is Obsolete, B. Carpenter (April 2005) [44] RFC 2471, IPv6 Testing Address Allocation, R. Hinden, R. Fink, J. Postel (December 1998) [45] RFC 3701, 6bone (IPv6 Testing Address Allocation) Phaseout, R. Fink, R. Hinden (March 2004) [46] RFC 3152, Delegation of IP6.ARPA, R. Bush (August 2001)

IPv6 address
[47] RFC 3177, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", IAB, IESG, (September 2001).

25

External links
IP Version 6 multicast addresses (http://www.iana.org/assignments/ipv6-multicast-addresses) Beijnum, van, Iljitsch (2005). Running IPv6. ISBN1-59059-527-0. Elz, Robert (1996-04-01). [RFC 1924 "A Compact Representation of IPv6 Addresses"]. IETF. RFC 1924. "Represent any IPv6 address in 20 octets." This humorous RFC specifies an alternative way of representing IPv6 addresses, using a base-85 encoding.

IPv6 packet
An IPv6 packet is the smallest message entity exchanged via the Internet Protocol across an Internet Protocol version 6 (IPv6) network. Packets consist of control information for addressing and routing, and a payload consisting of user data. The control information in IPv6 packets is subdivided into a mandatory fixed header and optional extension headers. The payload of an IPv6 packet is typically a datagram or segment of the higher-level Transport Layer protocol, but may be data for an Internet Layer (e.g., ICMPv6) or Link Layer (e.g., OSPF) instead. IPv6 packets are typically transmitted over a Link Layer protocol, such as Ethernet which encapsulates each packet in a frame, but this may also be a higher layer tunneling protocol, such as IPv4 when using 6to4 or Teredo transition technologies. Routers do not fragment IPv6 packets, as they do for IPv4. Hosts are "strongly recommended"[1] to implement path MTU discovery to take advantage of MTUs greater than the smallest MTU of 1280 octets. Hosts may use fragmentation to send packets larger than the observed path MTU.

Fixed header
The fixed header of an IPv6 packet consists of its first 40 octets (320 bits).[1] It has the following format:

Fixed header format

Offsets Octet Octet 0 4 8 12 16 20 24 28 32 36 Bit 0 32 64 96 128 160 192 224 256 288 Destination Address 0 1 2 3

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Version Traffic Class Payload Length Flow Label Next Header Source Address Hop Limit

Version (4 bits)

IPv6 packet The constant 6 (bit sequence 0110). Traffic Class (8 bits) The bits of this field hold two values. The 6 most-significant bits are used for DSCP, which is used to classify packets.[2][3] The remaining two bits are used for ECN;[4] priority values subdivide into ranges: traffic where the source provides congestion control and non-congestion control traffic. Flow Label (20 bits) Originally created for giving real-time applications special service.[1] Flow Label specifications and minimum requirements are described,[5][6] and first uses of this field are emerging.[7] Payload Length (16 bits) The size of the payload in octets, including any extension headers. The length is set to zero when a Hop-by-Hop extension header carries a Jumbo Payload option.[8] Next Header (8 bits) Specifies the type of the next header. This field usually specifies the transport layer protocol used by a packet's payload. When extension headers are present in the packet this field indicates which extension header follows. The values are shared with those used for the IPv4 protocol field, as both fields have the same function (see List of IP protocol numbers). Hop Limit (8 bits) Replaces the time to live field of IPv4. This value is decremented by one at each intermediate node the packet visits. When the counter reaches 0 the packet is discarded. Source Address (128 bits) The IPv6 address of the sending node. Destination Address (128 bits) The IPv6 address of the destination node(s). In order to increase performance, and since current link layer technology is assumed to provide sufficient error detection[9], the header has no checksum to protect it.[1]

26

Extension headers
Extension headers carry optional Internet Layer information, and are placed between the fixed header and the upper-layer protocol header.[1] The headers form a chain, using the Next Header fields. The Next Header field in the fixed header indicates the type of the first extension header; the Next Header field of the last extension header indicates the type of the upper-layer protocol header in the payload of the packet. All extension headers are a multiple of 8 octets in size; some extension headers require internal padding to meet this requirement. There are several extension headers defined,[1] and new extension headers may be defined in the future. Extension headers are to be examined and processed at the packet's destination only, except for Hop-by-Hop Options, which need to be processed at every intermediate node on the packet's path, including sending and receiving node. The defined extension headers below are listed in the preferred order, should there be more than one extension header following the fixed header. Note that all extension headers are optional and should only appear at most once, except for the Destination Options header, which may appear twice. If a node does not recognize a specific extension header, it should discard the packet and send an Parameter Problem message (ICMPv6 type 4, code 1).[1] When a Next Header value 0 appears in a header other than the fixed header a node should do the same.

IPv6 packet

27

Extension Header Hop-by-Hop Options Destination Options (before routing header) Routing Fragment Authentication Header (AH) Encapsulating Security Payload (ESP)

Type 0 60 43 44 51 50

Description Options that need to be examined by all devices on the path. Options that need to be examined only by the destination of the packet. Methods to specify the route for a datagram (used with Mobile IPv6). Contains parameters for fragmentation of datagrams. Contains information used to verify the authenticity of most parts of the packet. Carries encrypted data for secure communication. Options that need to be examined only by the destination of the packet. Parameters used with Mobile IPv6.

Destination Options (before upper-layer header) 60 Mobility (currently without upper-layer header) 135

Value 59 (No Next Header) in the Next Header field indicates that there is no next header whatsoever following this one, not even a header of an upper-layer protocol. It means that, from the header's point of view, the IPv6 packet ends right after it: the payload should be empty.[1] There could, however, still be data in the payload if the payload length in the first header of the packet is greater than the length of all extension headers in the packet. This data should be ignored by hosts, but passed unaltered by routers.

Hop-by-hop options and destination options

The Hop-by-Hop Options extension header needs to be examined by all nodes on the packet's path, including sending and receiving nodes. The Destination Options extension header need to be examined by the destination node(s) only. The extension headers are both at least 8 octets in size; if more options are present than will fit in that space, blocks of 8 octets are added to the header repeatedlycontaining options and paddinguntil all options are represented.

Hop-by-Hop Options and Destination Options extension header format

Offsets Octet Octet 0 4 8 12 Bit 0 32 64 96 0 1 2 3

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Next Header Hdr Ext Len Options and Padding Optional: more Options and Padding ... Options and Padding

Next Header (8 bits) Specifies the type of the next header. Hdr Ext Len (8 bits) Length of this header in 8-octet units, not including the first 8 octets. Options (variable) Contains one or more options, and optional padding fields to align options and to make the total header length a multiple of 8 octets. Options are TLV-coded.

IPv6 packet

28

Routing
The Routing extension header is used to direct a packet to one or more intermediate nodes before being sent to its destination. The header is at least 8 octets in size; if more Type-specific Data is needed than will fit in 4 octets, blocks of 8 octets are added to the header repeatedly, until all Type-specific Data is placed.[1]

Routing extension header format

Offsets Octet Octet 0 4 8 12 Bit 0 32 64 96 0 1 2 3

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Next Header Hdr Ext Len Routing Type Type-specific Data Optional: more Type-specific Data ... Segments Left

Next Header (8 bits) Indicates the type of the next header. Hdr Ext Len (8 bits) The length of this header, in multiples of 8 octets, not including the first 8 octets. Routing Type (8 bits) 0, 1, or 2. Segments Left (8 bits) Number of nodes this packet still has to visit before reaching its final destination. Type-specific Data (variable) Data that belongs to this type of routing header. Routing types Due to the fact that with Routing Header type 0 a simple but effective[10] denial-of-service attack could be launched, this header is deprecated[11] and host and routers are required to ignore these headers. Routing Header type 1 is used for the Nimrod[12] project funded by DARPA. Routing Header type 2 is a limited version of type 0 and is used for Mobile IPv6, where it can hold the Home Address of the Mobile Node.

Fragment
In order to send a packet that is larger than the path MTU, the sending node splits the packet into fragments. The Fragment extension header carries the information necessary to reassemble the original (unfragmented) packet.[1]

IPv6 packet

29

Fragment extension header format

Offsets Octet Octet 0 4 Bit 0 32 0 1 2 3

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Next Header Reserved Identification Fragment Offset Res M

Next Header (8 bits) Identifies the type of the next header. Reserved (8 bits) Initialized to all zeroes. Fragment Offset (13 bits) Offset, in 8-octet units, relative to the start of the fragmentable part of the original packet. Res (2 bits) Reserved; initialized to zeroes. M Flag (1 bit) 1 means more fragments follow; 0 means last fragment. Identification (32 bits) Packet identification value, generated by the source node. Needed for reassembly of the original packet.

Authentication Header (AH) and Encapsulating Security Payload (ESP)

The Authentication Header and the Encapsulating Security Payload are part of IPsec and are used identically in IPv6 and in IPv4.[13][14]

Payload
The fixed and optional IPv6 headers are followed with the upper-layer payload, the data provided by the transport layer, for example a TCP segment or a UDP datagram. The Next Header field of the last IPv6 header indicates what type of payload is contained in this packet.

Standard payload length

The payload length field of IPv6 (and IPv4) has a size of 16 bits, capable of specifying a maximum size of 65535 octets for the payload. Most Link Layer protocols cannot process packets larger than 65535 octets.

Jumbogram
An optional feature of IPv6, the jumbo payload option in a Hop-By-Hop Options extension header[8], allows the exchange of packets with payloads of up to one byte less than 4GB (2321= 4294967295 bytes), by making use of a 32-bit length field. Packets with such payloads are called jumbograms. Since both TCP and UDP include fields limited to 16 bits (length, urgent data pointer), support for IPv6 jumbograms requires modifications to the Transport Layer protocol implementation.[8] Jumbograms are only relevant for links that have a MTU larger than 65583 octets (more than 65535 octets for the payload, plus 40 octets for the fixed header, plus 8 octets for the Hop-by-Hop extension header).

IPv6 packet

30

Fragmentation
Unlike in IPv4, IPv6 routers never fragment IPv6 packets. Packets exceeding the size of the maximum transmission unit of the destination link are dropped and this condition is signaled by a Packet too Big ICMPv6 type 2 message to the originating node, similarly to the IPv4 method when the Don't Fragment bit set.[1] End nodes in IPv6 are expected to perform path MTU discovery to determine the maximum size of packets to send, and the upper-layer protocol is expected to limit the payload size. However, if the upper-layer protocol is unable to do so, the sending host may use the Fragment extension header in order to perform end-to-end fragmentation of IPv6 packets. Any data link layer conveying IPv6 data must be capable of delivering an IP packet containing 1280 bytes without the need to invoke end-to-end fragmentation at the IP layer.

Fragmenting
A packet containing a fragment of an original (larger) packet consists of two parts: the unfragmentable part of the original packet (which is the same for all fragments), and a piece of the fragmentable part of the original packet, identified by a fragment offset. The unfragmentable part of a packet consists of the fixed header and some of the extension headers of the original packet (if present): all extension headers up to and including the Routing extension header, or else the Hop-by-Hop extension header. If neither extension headers are present, the unfragmentable part is just the fixed header. The Next Header value of the last (extension) header of the unfragmentable part is set to 44 to indicate that a Fragment extension header follows. After the Fragment extension header a fragment of the rest of the original packet follows. The first fragment(s) hold the rest of the extension headers (if present). After that the rest of the payload follows. Each fragment is a multiple of 8 octets in length, except the last fragment. Each Fragment extension header has its M flag set to 1 (indicating more fragments follow), except the last, whose flag is set to 0.

Reassembly
The original packet is reassembled by the receiving node by collecting all fragments and placing each fragment at the right offset and discarding the Fragment extension headers of the packets that carried them. Packets containing fragments need not arrive in sequence; they will be rearranged by the receiving node. If not all fragments are received within 60 seconds after receiving the first packet with a fragment, reassembly of the original packet is abandoned and all fragments are discarded. If the first fragment was received (which contains the fixed header), a Time Exceeded message (ICMPv6 type 3, code 1) is returned to the node originating the fragmented packet, if the packet was discarded for this reason. Receiving hosts must make a best-effort attempt to reassemble fragmented IP datagrams that, after reassembly, contain up to 1500 bytes. Hosts are permitted to make an attempt to reassemble fragmented datagrams larger than 1500 bytes, but they are also permitted to silently discard any datagram after it becomes apparent that the reassembled packet would be larger than 1500 bytes. Therefore, senders should avoid sending fragmented IP datagrams with a total reassembled size larger than 1500 bytes, unless they have previous assurance that the receiver is capable of reassembling such large datagrams.

IPv6 packet

31

References
[1] Deering, S.; Hinden, R. (December 1998). Internet Protocol, version 6 (IPv6) Specification (http:/ / tools. ietf. org/ html/ rfc2460). IETF. RFC2460. [2] Nickols, K.; Blake, S.; Baker, F.; Black, D. (December 1998) Definition of the Differentiated Service Field (DS Field) in the IPv4 and IPv6 Headers (http:/ / tools. ietf. org/ html/ rfc2474. html), IETF. RFC2474. [3] Grossman, D. (April 2002) New Terminology and Clarifications for DiffServ (http:/ / tools. ietf. org/ html/ rfc3260. html), IETF. RFC3260. [4] Ramakrishnan, K.; Floyd, S.; Black, D. (September 2001) The Addition of Explicit Congestion Notification (ECN) to IP (http:/ / tools. ietf. org/ html/ rfc3168. html), IETF. RFC3168. [5] Wijnen, B. (September 2003) Textual Conventions for IPv6 Flow Label (http:/ / tools. ietf. org/ html/ rfc3595), IETF. RFC3595. [6] Rajahalme, J.; Conta, A.; Carpenter, B.; Deering, S. (March 2004) IPv6 Flow Label Specification (http:/ / tools. ietf. org/ html/ rfc3697), IETF. RFC3697. [7] draft-blake-ipv6-flow-label-nonce-02 (http:/ / tools. ietf. org/ html/ draft-blake-ipv6-flow-label-nonce-02) [8] Borman, D.; Deering, S.; Hinden, R. (August 1999). IPv6 Jumbograms (http:/ / tools. ietf. org/ html/ rfc2675). IETF. RFC2675. [9] RFC 1726 section 6.2 [10] Philippe Biondi, Arnoud Ebalard (April 2007). "IPv6 Routing Header Security" (http:/ / www. secdev. org/ conf/ IPv6_RH_security-csw07. pdf) (pdf). EADS. . Retrieved 3 December 2010. "Type 0: the evil mechanism..." [11] Abley, J.; Savola, P.; Neville-Neil, G. (December 2007). Deprecation of Type 0 Routing Headers in IPv6 (http:/ / tools. ietf. org/ html/ rfc5095). IETF. RFC5095. [12] Castineyra, I.; Chiappa, N.; Steenstrup, M. (Augustus 1996) The Nimrod Routing Architecture (http:/ / tools. ietf. org/ html/ rfc1992)', IETF. RFC1992. [13] Kent, S. (December 2005) IP Authentication Header (http:/ / tools. ietf. org/ html/ rfc4302. html) IETF. RFC4202. [14] Kent, S. (December 2005) IP Encapsulating Security Payload (http:/ / tools. ietf. org/ html/ rfc4303. html) IETF. RFC4203.

Mobile IP
Mobile IP (or IP mobility) is an Internet Engineering Task Force (IETF) standard communications protocol that is designed to allow mobile device users to move from one network to another while maintaining a permanent IP address. Mobile IP for IPv4 is described in IETF RFC 5944, and extensions are defined in IETF RFC 4721. Mobile IPv6, the IP mobility implementation for the next generation of the Internet Protocol, IPv6, is described in RFC 6275.

Introduction
The Mobile IP protocol allows location-independent routing of IP datagrams on the Internet. Each mobile node is identified by its home address disregarding its current location in the Internet. While away from its home network, a mobile node is associated with a care-of address which identifies its current location and its home address is associated with the local endpoint of a tunnel to its home agent. Mobile IP specifies how a mobile node registers with its home agent and how the home agent routes datagrams to the mobile node through the tunnel.

Applications
In many applications (e.g., VPN, VoIP), sudden changes in network connectivity and IP address can cause problems. Mobile IP was designed to support seamless and continuous Internet connectivity. Mobile IP is most often found in wired and wireless environments where users need to carry their mobile devices across multiple LAN subnets. Examples of use are in roaming between overlapping wireless systems, e.g., IP over DVB, WLAN, WiMAX and BWA. Mobile IP is not required within cellular systems such as 3G, to provide transparency when Internet users migrate between cellular towers, since these systems provide their own data link layer handover and roaming mechanisms. However, it is often used in 3G systems to allow seamless IP mobility between different packet data serving node (PDSN) domains.

Mobile IP

32

Operational principles
A mobile node has two addresses - a permanent home address and a care-of address (CoA), which is associated with the network the mobile node is visiting. Two kinds of entities comprise a Mobile IP implementation: A home agent stores information about mobile nodes whose permanent home address is in the home agent's network. A foreign agent stores information about mobile nodes visiting its network. Foreign agents also advertise care-of addresses, which are used by Mobile IP. If there is no foreign agent in the host network, the mobile device has to take care of getting an address and advertising that address by its own means. A node wanting to communicate with the mobile node uses the permanent home address of the mobile node as the destination address to send packets to. Because the home address logically belongs to the network associated with the home agent, normal IP routing mechanisms forward these packets to the home agent. Instead of forwarding these packets to a destination that is physically in the same network as the home agent, the home agent redirects these packets towards the remote address through an IP tunnel by encapsulating the datagram with a new IP header using the care of address of the mobile node. When acting as transmitter, a mobile node sends packets directly to the other communicating node, without sending the packets through the home agent, using its permanent home address as the source address for the IP packets. This is known as triangular routing. If needed, the foreign agent could employ reverse tunneling by tunneling the mobile node's packets to the home agent, which in turn forwards them to the communicating node. This is needed in networks whose gateway routers check that the source IP address of the mobile host belongs to their subnet or discard the packet otherwise.

Performance
A performance evaluation of Mobile IPv6 can be found in [1] Additionally, a performance comparison between Mobile IPv6 and some of its proposed enhancements (Hierarchical Mobile IPv6, Fast Handovers for Mobile IPv6 and their Combination) is available at [2].

Development
Enhancements to the Mobile IP technique, such as Mobile IPv6[3] and Hierarchical Mobile IPv6 (HMIPv6) defined in RFC 5380 [4],[5] are being developed to improve mobile communications in certain circumstances by making the processes more secure and more efficient. HMIPv6 explanation can be found at Hierarchical-Mobile-IPv6 [6]. Researchers create support for mobile networking without requiring any pre-deployed infrastructure as it currently is required by MIP. One such example is Interactive Protocol for Mobile Networking (IPMN) [7] which promises supporting mobility on a regular IP network just from the network edges by intelligent signalling between IP at end-points and application layer module with improved quality of service. Researchers are also working to create support for mobile networking between entire subnets with support from Mobile IPv6. One such example is Network Mobility (NEMO) Network Mobility Basic Support Protocol [8] by the IETF Network Mobility Working Group [9] which supports mobility for entire Mobile Networks that move and to attach to different points in the Internet. The protocol is an extension of Mobile IPv6 and allows session continuity for every node in the Mobile Network as the network moves.

Mobile IP

33

Changes in IPv6 for Mobile IPv6

A set of mobility options to include in mobility messages A new Home Address option for the Destination Options header A new Type 2 Routing header New Internet Control Message Protocol for IPv6 (ICMPv6) messages to discover the set of home agents and to obtain the prefix of the home link Changes to router discovery messages and options and additional Neighbor Discovery options

Definition of terms
Home network The home network of a mobile device is the network within which the device receives its identifying IP address (home address). Home address The home address of a mobile device is the IP address assigned to the device within its home network. Foreign network A foreign network is the network in which a mobile node is operating when away from its home network. Care-of address The care-of address of a mobile device is the network-native IP address of the device when operating in a foreign network. Home agent A home agent is a router on a mobile nodes home network which tunnels datagrams for delivery to the mobile node when it is away from home. It maintains current location (IP address) information for the mobile node. It is used with one or more foreign agents. Foreign agent A foreign agent is a router that stores information about mobile nodes visiting its network. Foreign agents also advertise care-of-addresses which are used by Mobile IP. Binding A binding is the association of the home address with a care-of address.

References
[1] X.Prez-Costa and H.Hartenstein. A Simulation Study on the Performance of Mobile IPv6 in a WLAN-Based Cellular Network. (http:/ / portal. acm. org/ citation. cfm?id=604022. 604035& coll=& dl=ACM). Elsevier Computer Networks Journal (CNJ), special issue on The New Internet Architecture, September 2002. [2] X.Prez-Costa, M.Torrent-Moreno and H.Hartenstein. A Performance Comparison of Mobile IPv6, Hierarchical Mobile IPv6, Fast Handovers for Mobile IPv6 and their Combination. (http:/ / portal. acm. org/ citation. cfm?id=965736) ACM SIGMOBILE Mobile Computing and Communications Review (MC2R), Volume 7, Issue 4, October, 2003. [3] X.Prez-Costa and H.Hartenstein. A Simulation Study on the Performance of Mobile IPv6 in a WLAN-Based Cellular Network (http:/ / portal. acm. org/ citation. cfm?id=604022. 604035& coll=& dl=ACM) Elsevier Computer Networks Journal, special issue on The New Internet Architecture, September 2002 [4] http:/ / tools. ietf. org/ html/ rfc5380 [5] X.Prez-Costa, M.Torrent-Moreno and H.Hartenstein. A Simulation Study on the Performance of Hierarchical Mobile IPv6 (http:/ / dsn. tm. uka. de/ medien/ publication-confs/ perez-itc03-simulation-study. pdf) In Proceedings of the International Teletraffic Congress (ITC), Berlin, Germany, August 2003. [6] http:/ / searchmobilecomputing. techtarget. com/ definition/ Hierarchical-Mobile-IPv6 [7] http:/ / medianet. kent. edu/ ipmn/ main. html [8] http:/ / www. rfc-editor. org/ rfc/ rfc3963. txt [9] http:/ / tools. ietf. org/ wg/ nemo/

Mobile IP

34

External links
RFC 6275 -Mobility support for IPv6 RFC 5944 - IP Mobility Support for IPv4, Revised RFC 4721 - Mobile IPv4 Challenge/Response Extensions RFC 3024 - Reverse Tunneling for Mobile IP Inside Mobile IP (http://www.ddj.com/dept/mobile/184406240) Protocols for Adaptive Mobile and Wireless Networking (http://www.monarch.cs.cmu.edu/) Mobile IP explained (a tutorial) (http://www.tml.tkk.fi/Opinnot/Tik-111.550/1999/Esitelmat/MobileIP/ Mobip.html) Mobility Extensions for IPv6 (mext) IETF Working Group Web site (http://ietf.org/html.charters/ mext-charter.html) Mobile IPv6 -- A short introduction (http://www.hznet.de/ipv6/mipv6-intro.pdf) by Holger Zuleger Linux Mobile IPv6 HOWTO (http://tldp.org/HOWTO/Mobile-IPv6-HOWTO/) on the Linux Documentation Project D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6 (http://tools.ietf.org/html/rfc6275). RFC 6275. June 2011

J. Arkko, V. Devarapalli, F. Dupont. Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents (http://www.ietf.org/rfc/rfc3776.txt). RFC 3776. June 2004

Neighbor Discovery Protocol

The Neighbor Discovery Protocol (NDP) is a protocol in the Internet Protocol Suite used with Internet Protocol Version 6 (IPv6). It operates in the Internet Layer of the Internet model (RFC 1122) and is responsible for address autoconfiguration of nodes, discovery of other nodes on the link, determining the Link Layer addresses of other nodes, duplicate address detection, finding available routers and Domain Name System (DNS) servers, address prefix discovery, and maintaining reachability information about the paths to other active neighbor nodes (RFC 4861).[1] The protocol defines five different ICMPv6 packet types to perform functions for IPv6 similar to the Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) Router Discovery and Router Redirect protocols for IPv4. However, it provides many improvements over its IPv4 counterparts (RFC 4861, section 3.1). For example, it includes Neighbor Unreachability Detection (NUD), thus improving robustness of packet delivery in the presence of failing routers or links, or mobile nodes.

Technical details
The Neighbor Discovery Protocol defines mechanisms for providing the following functionality: Router discovery: hosts can locate routers residing on attached links. Prefix discovery: hosts can discover address prefixes that are on-link for attached links. Parameter discovery: hosts can find link parameters (e.g., MTU). Address autoconfiguration: stateless configuration of addresses of network interfaces. Address resolution: mapping between IP addresses and link-layer addresses. Next-hop determination: hosts can find next-hop routers for a destination. Neighbor unreachability detection (NUD): determine that a neighbor is no longer reachable on the link.

Duplicate address detection (DAD): nodes can check whether an address is already in use. Redirect: router can inform a node about better first-hop routers.

Neighbor Discovery Protocol Recursive DNS Server (RDNSS) and DNS Search List (DNSSL) assignment via a router advertisement (RA) options.[2] This is a new feature and not widely supported by clients. NDP defines the following five ICMPv6 packet types:[3]Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, and Redirect.

35

References
[1] RFC 4861, Neighbor Discovery for IP version 6 (IPv6), T. Narten et al. (September 2007) [2] RFC 6106 (http:/ / tools. ietf. org/ html/ rfc6106), IPv6 Router Advertisement Options for DNS Configuration, J. Jeong (Ed.), S. Park, L. Beloeil, S. Madanapalli (November 2010) [3] RFC 2461, Neighbor Discovery for IP version 6 (IPv6), T. Narten, December 1998

External links
Neighbor Discovery Protocol (http://fengnet.com/book/CCIE Professional Development Routing TCPIP Volume I/ch02lev1sec5.html)

Secure Neighbor Discovery Protocol

The SEcure Neighbor Discovery (SEND) protocol is a security extension of the Neighbor Discovery Protocol (NDP) in IPv6. SEND is defined in RFC 3971 (2005). It is a subject to patent US 2008/0307516 A1 [1] The Neighbor Discovery Protocol (NDP) is responsible in IPv6 for discovery of other network nodes on the local link, to determine the link layer addresses of other nodes, and to find available routers, and maintain reachability information about the paths to other active neighbor nodes (RFC 4861). This protocol is insecure and susceptible to malicious interference. It is the intent of SEcure Neighbor Discovery to provide an alternate mechanism for securing NDP with a cryptographic method that is independent of IPsec, the original and inherent method of securing IPv6 communications. SEND protocol uses Cryptographically Generated Addresses.

Implementations
USL SEND [2] (discontinued), NTT DoCoMo Docomo USL SEND fork [3] NDprotector [4], Telecom SudParis ipv6-send-cga [5], Huawei and Beijing University of Posts and Telecommunications Easy-SEND [6] Native SeND kernel API [7] WinSEND [8] Hasso-Plattner-Institut [9]

Secure Neighbor Discovery Protocol

36

References
RFC 3971, "SEcure Neighbor Discovery (SEND)", J.Arkko (Ed.), et al., March 2005 RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", T.Narten, et al., September 2007

References
[1] [2] [3] [4] [5] [6] [7] [8] [9] http:/ / www. google. com/ patents?id=yzqxAAAAEBAJ http:/ / www. docomolabs-usa. com/ lab_opensource. html http:/ / mobisend. org/ software. html http:/ / amnesiak. org/ NDprotector/ http:/ / code. google. com/ p/ ipv6-send-cga/ http:/ / sourceforge. net/ projects/ easy-send/ http:/ / code. google. com/ p/ google-summer-of-code-2009-freebsd/ downloads/ detail?name=Ana_Kukec. tar. gz http:/ / ipv6sra. rozanak. com/ http:/ / www. hpi. uni-potsdam. de/ meinel/ forschung/ security_engineering/ ipv6_security. html

Multicast Router Discovery

Multicast router discovery (MRD) is an ICMP-based protocol used for to discover multicast routers on an IP network. Multicast router discovery is defined by RFC 4286.

Site Multihoming by IPv6 Intermediation

The SHIM6 protocol is an Internet Layer shim defined in RFC 5533.

Architecture
The SHIM6 architecture defines SHIM6 Failure Detection and Locator Pair Exploration functions. The first is used to detect outages through the path defined by the current locator pair for a communication. To achieve this, hints provided by upper protocols such as TCP are used, or specific SHIM6 packet probes. The second function is used to determine valid locator pairs that could be used when an outage is detected. The ability to change locators while a communication is being held introduces security problems, so mechanisms based on applying cryptography to the address generation process (Cryptographically Generated Addresses, CGA), or on bounding the addresses to the prefixes assigned to a host through a hash (Hash-based addresses, HBA) have been defined. These approaches are not feasible for IPv4 because of the short address length (32 bits). An implementation of shim6 in the Linux kernel called LinShim6 [1] is now available.

Site Multihoming by IPv6 Intermediation

37

References
C. de Launois and M. Bagnulo. The Paths towards IPv6 Multihoming [2]. IEEE Communications Surveys and Tutorials, 8(2), 2006

External links
IETF SHIM6 Working Group status page [3] SHIM6 IPv6 multihoming web page [4]

References
[1] [2] [3] [4] http:/ / inl. info. ucl. ac. be/ softwares/ linshim6 http:/ / inl. info. ucl. ac. be/ publications/ paths-towards-ipv6-multihoming http:/ / tools. ietf. org/ wg/ shim6/ http:/ / www. shim6. org/

IPv6 transition mechanisms

IPv6 transition mechanisms are technologies to facilitate the transitioning of the Internet from its IPv4 infrastructure to the next generation addressing system of IPv6. Specifically, they are methods that allow hosts only connected with either IPv4 or IPv6 to access resources only available using the other protocol. The Internet Engineering Task Force (IETF) conducts working groups and discussions through the IETF Internet Drafts and Requests for Comments processes to develop these methods. Some basic IPv6 transition mechanisms are defined in RFC 4213.

Stateless IP/ICMP Translation (SIIT)

Stateless IP/ICMP Translation translates between the packet header formats in IPv6 and IPv4. The SIIT method defines a class of IPv6 addresses called IPv4-translated addresses. They have the prefix ::ffff:0:0:0/96 and may be written as ::ffff:0:a.b.c.d, in which the IPv4 formatted address a.b.c.d refers to an "IPv6-enabled" node. The prefix was chosen to yield a zero-valued checksum to avoid changes to the transport protocol header checksum.[1] The algorithm can be used in a solution that allows IPv6 hosts, that do not have a permanently assigned IPv4 address, to communicate with IPv4-only hosts. Address assignment and routing details are not addressed by the specification. The specification is a product of the NGTRANS IETF working group, and was initially drafted in February 2000 as RFC 2765 by E. Nordmark of Sun Microsystems. RFC 2765 was obsoleted by RFC 6145 in 2011.[2] The address format part of RFC 2765 is defined in RFC 6052. [3] The framework of IPv4/IPv6 translation is defined in RFC 6144. [4]

IPv6 transition mechanisms

38

6rd
6rd is a mechanism to facilitate rapid deployment of the IPv6 service across IPv4 infrastructures of Internet service providers (ISPs). It uses stateless address mappings between IPv4 and IPv6 addresses, and transmits IPv6 packets across automatic tunnels that follow the same optimized routes between customer nodes as IPv4 packets. It has been used for the first large deployment of an IPv6 service with native addresses at the end of 2007 (RFC 5569 [5] ). The standard-track specification of the protocol is in RFC 5969.[6]

Transport Relay Translation (TRT)

RFC 3142 defines the Transport Relay Translation (TRT) method. This is the most common form of NAT-PT/NAPT-PT but relies on DNS translation between AAAA and A records known as DNS-ALG as defined in RFC 2694.

NAT64
NAT64 is a mechanism to allow IPv6 hosts to communicate with IPv4 servers. The NAT64 server is the endpoint for at least one IPv4 address and an IPv6 network segment of 32-bits (for instance 64:ff9b::/96, see RFC 6052, RFC 6146). The IPv6 client embeds the IPv4 address it wishes to communicate with using these bits, and sends its packets to the resulting address. The NAT64 server then creates a NAT-mapping between the IPv6 and the IPv4 address, allowing them to communicate.[7]

NAT64 and DNS64.

DNS64
DNS64 describes a DNS server that when asked for a domain's AAAA records, but only finds A records, synthesizes the AAAA records from the A records. The first part of the synthesized IPv6 address points to a IPv6/IPv4 translator and the second part embeds the IPv4 address from the A record. The translator in question is usually a NAT64 server. The standard-track specification of DNS64 is in RFC 6147.[8] There are two noticeable issues with the transition mechanism: It only works for cases where DNS is used to find the remote host address, if IPv4 literals are used the DNS64 server will never be involved. Because the DNS64 server needs to return records not specified by the domain owner, DNSSEC validation against the root will fail in cases where the DNS server doing the translation is not the domain owner's server.

Dual-Stack Lite (DS-Lite)

Because of IPv4 address exhaustion, Dual-Stack Lite was designed to let an Internet service provider omit the deployment of any IPv4 address to the customer's Customer-premises equipment (CPE). Instead, only global IPv6 addresses are provided. (Regular Dual-Stack deploys global addresses for both IPv4 and IPv6.) The CPE distributes private IPv4 addresses for the LAN clients, the same as a NAT device. The subnet information is arbitrarily chosen by

DS-Lite

IPv6 transition mechanisms the customer, identically to the NAT model. However, instead of performing the NAT itself, the CPE encapsulates the IPv4 packet inside an IPv6 packet. The CPE uses its global IPv6 connection to deliver the packet to the ISP's Carrier Grade NAT (CGN), which has a global IPv4 address. The IPv6 packet is decapsulated, restoring the original IPv4 packet. NAT is performed upon the IPv4 packet and is routed to the public IPv4 Internet. The CGN uniquely identifies traffic flows by recording the CPE public IPv6 address, the private IPv4 address, and TCP or UDP port number as a session.[9]

39

Drafts
These mechanisms are still being discussed or have been abandoned by the IETF.

4rd
4rd is a mechanism to facilitate residual deployment of the IPv4 service across IPv6 networks. Like 6rd, it uses stateless address mappings between IPv6 and IPv4. It supports an extension of IPv4 address based on transport-layer ports. This is similar to A+P, but with each customer having a port set of up to 4 port ranges, and with port sets algorithmically derived from customer IPv6 prefixes.

Deprecated
These mechanisms have been deprecated by the IETF.

NAT-PT
Network Address Translation/Protocol Translation (or simply NAT-PT) is defined in RFC 2766 but due to numerous problems, it has been obsoleted by RFC 4966 and deprecated to historic status. It is typically used in conjunction with a DNS application-level gateway (DNS-ALG) implementation.

NAPT-PT
While almost identical to NAT-PT, Network Address Port Translation + Protocol Translation which is also described in RFC 2766 adds translation of the ports as well as the address. This is done primarily to avoid two hosts on one side of the mechanism from using the same exposed port on the other side of the mechanism, which could cause application instability and/or security flaws. This mechanism has been deprecated by RFC 4966.

Implementations
stone (software), port translator for Windows & Unix-based systems. faithd, BSD-based static TRT implementation by the KAME project TAYGA [10], a stateless NAT64 implementation for Linux naptd [11], user-level NAT-PT Ecdysis [12], a NAT64 gateway, includes DNS64 Address Family Transition Router [13], a DS-Lite implementation niit [14] IVI [15] (second page [16]) Microsoft Forefront Unified Access Gateway, a reverse proxy and VPN solution that implements DNS64 and NAT64 BIND, Berkeley Internet Name Domain DNS server, implements DNS64 since version 9.8

IPv6 transition mechanisms

40

External links
TRT Howto from 2003 [17] IPv6 - Prospects and problems: a technical and management investigation into the deployment of IPv6 [18] Network World: Understanding Dual-Stack Lite [19] IETF Draft: Framework for IPv4/IPv6 Translation [20] IPv4 and IPv6 Transition and Coexistence [21], 6DEPLOY project, 2011

References
[1] RFC 2765 - Stateless IP/ICMP Translation Algorithm (SIIT), E. Normark (February 2000) [2] RFC 6145 IP/ICMP Translation Algorithm [3] RFC 6052 - IPv6 Addressing of IPv4/IPv6 Translators [4] RFC 6144 - Framework for IPv4/IPv6 Translation [5] RFC 5569 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [6] RFC 5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification [7] RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers [8] RFC 6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers [9] RFC 6333 - Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion [10] http:/ / www. litech. org/ tayga [11] http:/ / tomicki. net/ naptd. php [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] http:/ / ecdysis. viagenie. ca/ https:/ / www. isc. org/ software/ aftr https:/ / dev. dd19. de/ ~alx/ alx-niit/ http:/ / v6s. 6test. edu. cn/ http:/ / www. ivi2. org/ http:/ / www. join. uni-muenster. de/ Dokumente/ Howtos/ Howto_TRT. php?lang=en http:/ / web. archive. org/ web/ 20070928032349/ http:/ / student. grm. hia. no/ master/ ikt03/ ikt6400/ g03/ filer/ Hovedprosjekt_G3. doc http:/ / www. networkworld. com/ community/ node/ 46600 http:/ / tools. ietf. org/ html/ draft-ietf-behave-v6v4-framework http:/ / www. 6deploy. eu/ workshops2/ 20110405_santiago_compostela_spain/ Jordi_130-6deploy_ipv6_transition_v0_8. pdf

IPv6 in Practice, Benedikt Stockebrand (2006), ISBN 3-540-24524-3 RFC 2767, Bump-in-the-Stack RFC 3338, Bump-in-the-API RFC 3089, Socks-based Gateway RFC 6219, The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition

4in6

41

4in6
4in6 refers to tunneling of IPv4 in IPv6. It is an Internet interoperation mechanism allowing Internet Protocol version 4 (IPv4) to be used in an IPv6 only network. 4in6 uses tunneling to encapsulate IPv4 traffic over configured IPv6 tunnels as defined in RFC 2473. 4in6 tunnels are usually manually configured but they can be automated using protocols such as TSP to allow easy connection to a tunnel broker.

References
RFC 2473, Generic Packet Tunneling in IPv6 Specification, A. Conta and S. Deering 1998

6in4
6in4 is an Internet transition mechanism for migrating from Internet Protocol version 4 (IPv4) to IPv6. 6in4 uses tunneling to encapsulate IPv6 traffic over explicitly-configured IPv4 links as defined in RFC 4213 (obsoletes RFC 2893 and RFC 1933). The 6in4 traffic is sent over the IPv4 Internet inside IPv4 packets whose IP headers have the IP protocol number set to 41. This protocol number is specifically designated for IPv6 encapsulation.[1] In 6in4, the IPv4 packet header is immediately followed by the IPv6 packet being carried. This means that the encapsulation overhead is simply the size of the IPv4 header of 20 bytes. With an Ethernet Maximum Transmission Unit (MTU) of 1500 bytes, one can thus send IPv6 packets of 1480 bytes without fragmentation. 6in4 tunneling is also referred to as proto-41 static because the endpoints are configured statically. Although 6in4 tunnels are generally manually configured, for example the utility AICCU can configure tunnel parameters automatically after retrieving information from a Tunnel Information and Control Protocol (TIC) server. There are similarly named methods, namely 6to4 or 6over4, which describe a different mechanism. The method 6to4 makes use of proto-41 too, but instead of static configuration of the endpoints, the endpoint IPv4 address information is derived from the IPv6 addresses within the IPv6 packet header.

Network address translators (NAT)

When an endpoint of a 6in4 tunnel is behind a NAT, one can in some cases still make use of the DMZ feature of a NAT router. The NAT router will then forward all incoming proto-41 packets to the configured host, thus making the tunnel work. Some NAT devices even allow transparent operation of 6in4.

Dynamic 6in4 tunnels and heartbeat

Even though 6in4 tunnels are static in nature, with the help of for example the heartbeat protocol[2] one can still have dynamic tunnel endpoints. The heartbeat protocol signals the other side of the tunnel with its current endpoint location. A tool such as AICCU can then update the endpoints, in effect making the endpoint dynamic while still using the 6in4 protocol. These kind of tunnels are generally called 'proto-41 heartbeat' tunnels.

6in4

42

Security issues
The 6in4 protocol has no security features, thus one can easily inject IPv6 packets by spoofing the source IPv4 address of a tunnel endpoint and sending it to the other endpoint. This problem can partially be solved by implementing network ingress filtering or with IPsec. Another solution is to use a secure protocol such as AYIYA or other tunneling methods that compute digital signatures for each packet thus facilitating verification of packet authenticity. The mentioned packet injection loophole of 6in4 was exploited for a research benefit in a method called IPv6 Tunnel Discovery [3] which allowed the researchers to discover operating IPv6 tunnels around the world.

References
RFC 1933, Transition Mechanisms for IPv6 Hosts and Routers, R. Gilligan and E. Nordmark, 1996
[1] "Protocol Numbers" (http:/ / www. iana. org/ assignments/ protocol-numbers/ protocol-numbers. xml). . [2] Heartbeat Protocol (http:/ / www. sixxs. net/ tools/ heartbeat/ ), J. Massar and P. van Pelt [3] IPv6 Tunnel Discovery (http:/ / www. dia. uniroma3. it/ ~compunet/ tunneldiscovery), L. Colitti, G. Di Battista, and M. Patrignani

External links
How do I configure my machine to setup an IPv6 in IPv4 tunnel (http://www.sixxs.net/faq/connectivity/ ?faq=ossetup) 6in4 and other tunnel setups on Debian (http://wiki.debian.org/DebianIPv6) 6in4 setup on Plan9 OS (http://www.cs.bell-labs.com/magic/man2html/8/6in4)

6over4
6over4 is an IPv6 transition mechanism meant to transmit IPv6 packets between dual-stack nodes on top of a multicast-enabled IPv4 network. IPv4 is used as a virtual data link layer (virtual Ethernet) on which IPv6 can be run.

How 6over4 works

6over4 defines a trivial method for generating a link-local IPv6 address from an IPv4 address, and a mechanism to perform Neighbor Discovery on top of IPv4.

Link-local address generation

Any host wishing to participate in 6over4 over a given IPv4 network can set up a virtual IPv6 network interface. The link-local address is determined as follows : it starts with fe80:0000:0000:0000:0000:0000, or fe80:: for short, the lower-order 32 bits to the binary value must be that of the IPv4 address of the host. For example, host 192.0.2.142 would use fe80:0000:0000:0000:0000:0000:c000:028e as its link-local IPv6 address (192.0.2.142 is c000028e in hexadecimal notation). A shortened notation would be fe80::c000:28e.

6over4

43

Multicast Address Mapping

To perform ICMPv6 Neighbor Discovery, multicast must be used. Any IPv6 multicast packet gets encapsulated in an IPv4 multicast packet with destination 239.192.x.y, where x and y are the penultimate and last bytes of the IPv6 multicast address respectively. Examples All-Nodes Multicast (ff02::1) - 239.192.0.1 All-Routers Multicast (ff02::2) - 239.192.0.2 Solicited Node Multicast for fe80::c000:28e (the link-local address of 192.0.2.142) - 239.192.2.142

Neighbor Discovery
Given a link-local address and a multicast addresses mapping, a host can use ICMPv6 to discover its on-link neighbors and routers, and usually perform stateless autoconfiguration, as it would do on top of, e.g. Ethernet.

Limit of 6over4
6over4 relies on IPv4 multicast availability, which is not very widely supported by IPv4 networking infrastructure (multicast is almost as recent as IPv6), 6over4 is of limited practical use, and is not supported by the most common operating systems. To connect IPv6 hosts on different physical links, IPv4 multicast routing must be enabled on the routers connecting the links. ISATAP is a more complex alternative to 6over4 which does not rely on IPv4 multicast.

References
B. Carpenter & C. Jung Transmission of IPv6 over IPv4 Domains without Explicit Tunnels RFC 2529, March 1999.

6to4

44

6to4
6to4 is an Internet transition mechanism for migrating from IPv4 to IPv6, a system that allows IPv6 packets to be transmitted over an IPv4 network (generally the IPv4 Internet) without the need to configure explicit tunnels. Special relay servers are also in place that allow 6to4 networks to communicate with native IPv6 networks. 6to4 is especially relevant during the initial phases of deployment to full, native IPv6 connectivity, since IPv6 is not required on nodes between the host and the destination. However, it is intended only as transition mechanism and is not meant to be used permanently. 6to4 may be used by an individual host, or by a local IPv6 network. When used by a host, it must have a global IPv4 address connected, and the host is responsible for encapsulation of outgoing IPv6 packets and decapsulation of incoming 6to4 packets. If the host is configured to forward packets for other clients, often a local network, it is then a router. Most IPv6 networks use autoconfiguration, which requires the last 64 bits for the host. The first 64 bits are the IPv6 prefix. The first 16 bits of the prefix are always 2002:, the next 32 bits are the IPv4 address, and the last 16 bits of the prefix are arbitrarily chosen by the router. Since the IPv6 hosts using autoconfiguration already have determined the unique 64 bit host portion of their address, they must simply wait for a Router Advertisement indicating the first 64 bits of prefix to have a complete IPv6 address. A 6to4 router will know to send an encapsulated packet directly over IPv4 if the first 16 bits are 2002, using the next 32 as the destination, or otherwise send the packet to a well-known relay server, which has access to native IPv6. 6to4 does not facilitate interoperation between IPv4-only hosts and IPv6-only hosts. 6to4 is simply a transparent mechanism used as a transport layer between IPv6 nodes. Due to the high levels of misconfigured hosts and poor performance observed, an advisory about how 6to4 should be deployed was published in August 2011.[1]

How 6to4 works

6to4 performs three functions: Assigns a block of IPv6 address space to any host or network that has a global IPv4 address. Encapsulates IPv6 packets inside IPv4 packets for transmission over an IPv4 network using 6in4. Routes traffic between 6to4 and "native" IPv6 networks.

6to4.

Address block allocation

For any 32-bit global IPv4 address that is assigned to a host, a 48-bit 6to4 IPv6 prefix can be constructed for use by that host (and if applicable the network behind it) by appending the IPv4 address to 2002::/16.

6to4 address

For example the global IPv4 address 192.0.2.42 have the corresponding 6to4 prefix 2002:c000:022a::/48. This gives a prefix length of 48 bits, which leaves room for a 16-bit subnet field and 64 bit host addresses within the subnets.

6to4 Any IPv6 address that begins with the 2002::/16 prefix (in other words, any address with the first field 2002) is known as a 6to4 address, as opposed to a native IPv6 address which does not use transition technologies. Note that using a reserved IPv4 address, such as those provided by RFC 1918, is undefined, since these networks are disallowed from being routed on the public Internet. For example, using 192.168.1.1 as the router's WAN address would be invalid since a return packet would determine the correct destination IPv4 address to be unreachable.

45

Encapsulation and transmission

6to4 embeds an IPv6 packet in the payload portion of an IPv4 packet with protocol type 41. To send an IPv6 packet over an IPv4 network to a 6to4 destination address, an IPv4 header with protocol type 41 is prepended to the IPv6 packet. The IPv4 destination address for the prepended packet header is derived from the IPv6 destination address of the inner packet (which is in the format of a 6to4 address), by extracting the 32 bits immediately following the IPv6 destination address's 2002::/16 prefix. The IPv4 source address in the prepended packet header is the IPv4 address of the host or router which is sending the packet over IPv4. The resulting IPv4 packet is then routed to its IPv4 destination address just like any other IPv4 packet.

Routing between 6to4 and native IPv6

To allow hosts and networks using 6to4 addresses to exchange traffic with hosts using "native" IPv6 addresses, "relay routers" have been established. A relay router connects to an IPv4 network and an IPv6 network. 6to4 packets arriving on an IPv4 interface will have their IPv6 payloads routed to the IPv6 network, while packets arriving on the IPv6 interface with a destination address prefix of 2002::/16 will be encapsulated and forwarded over the IPv4 network. There is difference between a "relay router" and "border router" or known as "6to4 border router". A 6to4 border router is an IPv6 router supporting a 6to4 pseudo-interface. It is normally the border router between an IPv6 site and a wide-area IPv4 network, where the IPv6 site uses 2002::/16 co-related to the IPv4 address used later on. On the other hand, a "relay router" is a 6to4 router configured to support transit routing between 6to4 addresses and pure native IPv6 addresses. To allow a 6to4 host to communicate with the native IPv6 Internet, it must have its IPv6 default gateway set to a 6to4 address which contains the IPv4 address of a 6to4 relay router. To avoid the need for users to set this up manually, the anycast address of 192.88.99.1 has been allocated for the purpose of sending packets to a 6to4 relay router. Note that when wrapped in 6to4 with the subnet and hosts fields set to zero this IPv4 address (192.88.99.1) becomes the IPv6 address 2002:c058:6301::. To ensure BGP routing propagation, a short prefix of 192.88.99.0/24 has been allocated for routes pointed at 6to4 relay routers that use this anycast IP address. Providers willing to provide 6to4 service to their clients or peers should advertise the anycast prefix like any other IP prefix, and route the prefix to their 6to4 relay. Packets from the IPv6 Internet to 6to4 systems must be sent to a 6to4 relay router by normal IPv6 routing methods. The specification states that such relay routers must only advertise 2002::/16 and not subdivisions of it to prevent IPv4 routes polluting the routing tables of IPv6 routers. From here they can then be sent over the IPv4 Internet to the destination. An extension of 6to4 called IPv6 rapid deployment ("6rd") removes the requirement of depending upon a possibly misconfigured external relay server.

6to4

46

Reverse DNS delegation

When a site using 6to4 has a fixed global IPv4 address, its 6to4 IPv6 prefix is also fixed. It is then possible to request reverse DNS delegation for an individual 6to4 48-bits prefix inside the 2.0.0.2.ip6.arpa DNS zone from the Number Resource Organization at [2] . The process is entirely automatic.

Security considerations
According to RFC 3964, 6to4 routers and relays should ensure that: either or both the source and destination addresses of any encapsulated packet is within the 6to4 IPv6 prefix 2002::/16, if the source IPv6 address is a 6to4 IPv6 address, its corresponding 6to4 router IPv4 address matches the IPv4 source address in the IPv4 encapsulation header, similarly, if the destination IPv6 address is a 6to4 IPv6 address, its corresponding 6to4 router IPv4 address matches the IPv4 destination address in the IPv4 encapsulation header, any embedded 6to4 router IPv4 address is global unicast.

6to4 relays
Websites and lists
Public 6to4 relay routers [3]: See Archive.org cache [4] 6to4 relay routers on BGPmon.net [5]: Lists autonomous systems (ASs) announcing IPv4 & Ipv6 6to4 anycast prefixes in time

Other hosts
swi6netCE1.switch.ch @ 2001:620:0:c000::1 Comcast operates 6to4 relays as part of their IPv6 trials.[6] The 6to4 relays were turned up on August 17, 2010. These 6to4 relays are available via the standard 6to4 Anycast IP address which according to RFC 3068 is 192.88.99.1. Devices attempting to use 6to4 within the Comcast network should automatically discover and utilize these 6to4 relays, without end user intervention or configuration.

References

[1] [2] [3] [4] [5] [6]

B. Carpenter & K. Moore. Connection of IPv6 Domains via IPv4 Clouds. RFC 3056, February 2001. R. Gilligan & E. Nordmark. Transition Mechanisms for IPv6 Hosts and Routers. RFC 2893, August 2000. C. Huitema. An Anycast Prefix for 6to4 Relay Routers. RFC 3068, June 2001. P. Savola & C. Patel. Security Considerations for 6to4. RFC 3964, December 2004.
RFC 6343 - Advisory Guidelines for 6to4 Deployment http:/ / 6to4. nro. net/ http:/ / www. kfu. com/ ~nsayer/ 6to4/ http:/ / web. archive. org/ web/ 20080112194146/ http:/ / www. kfu. com/ ~nsayer/ 6to4/ http:/ / bgpmon. net/ 6to4. php "Comcast's IPv6 Information Center" (http:/ / www. comcast6. net). .

6to4

47

External links
"Routing IPv6 over IPv4" article by Cisco (http://www.cisco.com/web/about/ac123/ac147/ac174/ac197/ about_cisco_ipj_archive_article09186a00800c830a.html) IPv6 6to4 tunnel configuration example (http://6to4.version6.net/?lang=en_GB)

Tunnel broker
In the context of computer networking, a tunnel broker is a service which provides a network tunnel. These tunnels can provide encapsulated connectivity over existing infrastructure to another infrastructure. There are a variety of tunnel brokers, though most commonly the term is used to refer to an IPv6 tunnel broker, as defined in RFC:3053, but it can also refer to an IPv4 tunnel broker. IPv6 tunnel brokers commonly provide IPv6 tunnels to sites or end users over IPv4. In general tunnel brokers offer so called 'protocol 41' or proto-41 tunnels. These are tunnels where IPv6 is tunneled directly inside IPv4 packets by having the protocol field set to '41' (IPv6) in the IPv4 packet. In the case of IPv4 tunnel brokers IPv4 tunnels are provided to users by encapsulating IPv4 inside IPv6 as defined in RFC:2473.

Automated configuration
Configuration of IPv6 tunnels is usually done using the Tunnel Setup Protocol (TSP), or using Tunnel Information Control protocol (TIC). A client capable of this is AICCU (Automatic IPv6 Connectivity Client Utility). In addition to IPv6 tunnels TSP can also be used to set up IPv4 tunnels.

NAT Issues
Proto-41 tunnels (direct IPv6 in IPv4) may not operate well situated behindNATs. One way around this is to configure the actual endpoint of the tunnel to be the DMZ on the NAT-utilizing equipment. Another method is to either use AYIYA or TSP, both of which send IPv6 inside UDP packets, which is able to cross most NAT setups and even firewalls. A problem that still might occur is that of the timing-out of the state in the NAT machine. As a NAT remembers that a packet went outside to the Internet it allows another packet to come back in from the Internet that is related to the initial proto-41 packet. When this state expires, no other packets from the Internet will be accepted. This therefore breaks the connectivity of the tunnel until the user's host again sends out a packet to the tunnel broker.

Dynamic Endpoints
When the endpoint isn't a static IP address, the user, or a program, has to instruct the tunnel broker to update the endpoint address. This can be done using the tunnel broker's web site or using an automated protocol like TSP or Heartbeat [1], as used by AICCU. In the case of a tunnel broker using TSP, the client automatically restarting the tunnel will cause the endpoint address and port to be updated.

References
[1] http:/ / www. sixxs. net/ tools/ heartbeat/

Teredo tunneling

48

Teredo tunneling
In computer networking, Teredo is a transition technology that gives full IPv6 connectivity for IPv6-capable hosts which are on the IPv4 Internet but which have no direct native connection to an IPv6 network. Compared to other similar protocols its distinguishing feature is that it is able to perform its function even from behind network address translation (NAT) devices such as home routers. Teredo operates using a platform independent tunneling protocol designed to provide IPv6 (Internet Protocol version 6) connectivity by encapsulating IPv6 datagram packets within IPv4 User Datagram Protocol (UDP) packets. These datagrams can be routed on the IPv4 Internet and through NAT devices. Other Teredo nodes elsewhere called Teredo relays that have access to the IPv6 network then receive the packets, unencapsulate them, and route them on. Teredo is designed as a last resort transition technology and is intended to be a temporary measure: in the long term, all IPv6 hosts should use native IPv6 connectivity. Teredo should therefore be disabled when IPv6 connectivity becomes available. Teredo was developed by Christian Huitema at Microsoft, and was standardized in the IETF as RFC 4380. Teredo server listens on UDP port 3544.

Purpose
6to4, the most common IPv6 over IPv4 tunneling protocol, requires the tunnel endpoint to have a public IPv4 address. However, many hosts are currently attached to the IPv4 Internet through one or several NAT devices, usually because of IPv4 address shortage. In such a situation, the only available public IPv4 address is assigned to the NAT device, and the 6to4 tunnel endpoint needs to be implemented on the NAT device itself. Many NAT devices currently deployed, however, cannot be upgraded to implement 6to4, for technical or economic reasons. Teredo alleviates this problem by encapsulating IPv6 packets within UDP/IPv4 datagrams, which most NATs can forward properly. Thus, IPv6-aware hosts behind NATs can be used as Teredo tunnel endpoints even when they don't have a dedicated public IPv4 address. In effect, a host implementing Teredo can gain IPv6 connectivity with no cooperation from the local network environment. Teredo is intended to be a temporary measure: in the long term, all IPv6 hosts should use native IPv6 connectivity. The Teredo protocol includes provisions for a sunset procedure: Teredo implementation should provide a way to stop using Teredo connectivity when IPv6 has matured and connectivity becomes available using a less brittle mechanism.

Overview
For a complete explanation, see Teredo Overview in External links. The Teredo protocol performs several functions: 1. Diagnoses UDP over IPv4 (UDPv4) connectivity and discovers the kind of NAT present (using a simplified replacement to the STUN protocol) 2. Assigns a globally routable unique IPv6 address to each host using it 3. Encapsulates IPv6 packets inside UDPv4 datagrams for transmission over an IPv4 network (this includes NAT traversal) 4. Routes traffic between Teredo hosts and native (or otherwise non-Teredo) IPv6 hosts

Teredo tunneling

49

Node types
Teredo defines several different kinds of node: Teredo client A host which has IPv4 connectivity to the internet from behind a NAT and uses the Teredo tunneling protocol to access the IPv6 Internet. Teredo clients are assigned an IPv6 address that starts with the Teredo prefix (2001:0::/32). Teredo server A well-known host which is used for initial configuration of a Teredo tunnel. A Teredo server never forwards any traffic for the client (apart from IPv6 pings), and has therefore very modest bandwidth requirements (a few hundred bits per second per client at most), which allows a single server to support large numbers of clients. Additionally, a Teredo server can be implemented in a fully stateless manner, thus using the same amount of memory regardless of how many clients it supports. Teredo relay The remote end of a Teredo tunnel. A Teredo relay must forward all of the data on behalf of the Teredo clients it serves, with the exception of direct Teredo client to Teredo client exchanges. Therefore, a relay requires a lot of bandwidth and can only support a limited number of simultaneous clients. Each Teredo relay serves a range of IPv6 hosts (e.g. a single campus/company, an ISP or a whole operator network, or even the whole IPv6 Internet); it forwards traffic between any Teredo clients and any host within said range. Teredo host-specific relay A Teredo relay whose range of service is limited to the very host it runs on. As such, it has no particular bandwidth or routing requirements. A computer with a host-specific relay will use Teredo to communicate with Teredo clients, but it will stick to its main IPv6 connectivity provider to reach the rest of the IPv6 Internet.

IPv6 addressing
Each Teredo client is assigned a public IPv6 address which is constructed as follows (the higher order bit is numbered 0): Bits 0 to 31 are set to the Teredo prefix (normally 2001:0000::/32). Bits 32 to 63 embed the primary IPv4 address of the Teredo server that is used. Bits 64 to 79 can be used to define some flags. Currently only the higher order bit is used; it is set to 1 if the Teredo client is located behind a cone NAT, 0 otherwise. For Microsoft's Windows Vista and Windows Server 2008 implementations, more bits are used. In those implementations, the format for these 16 bits, MSB first, is "CRAAAAUG AAAAAAAA", where "C" remains the "Cone" flag. The "R" bit is reserved for future use. The "U" bit is for the Universal/Local flag (set to 0). The "G" bit is Individual/Group flag (set to 0). The A bits are set to a 12-bit randomly generated number chosen by the Teredo client to introduce additional protection for the Teredo node against IPv6-based scanning attacks. Bits 80 to 95 contains the obfuscated UDP port number. This is the port number that is mapped by the NAT to the Teredo client with all bits inverted. Bits 96 to 127 contains the obfuscated IPv4 address. This is the public IPv4 address of the NAT with all bits inverted. Teredo IPv6 addressing table

Teredo tunneling

50

Bits Length

0 - 31 32 bits

32 - 63 32 bits Teredo server IPv4

64 - 79 16 bits

80 - 95 16 bits

96 - 127 32 bits

Description Prefix

Flags Obfuscated Client UDP port public IPv4

As an example, the IPv6 address 2001:0000:4136:e378:8000:63bf:3fff:fdd2 refers to a Teredo client: using Teredo server at address 65.54.227.120 (4136e378 in hexadecimal), located behind a cone NAT (bit 64 is set), using UDP mapped port 40000 on its NAT (in hexadecimal 63bf xor ffff equals 9c40, or decimal number 40000), whose NAT has public IPv4 address 192.0.2.45 (3ffffdd2 xor ffffffff equals c000022d, which is to say 192.0.2.45).

Teredo IPv6 example table

Bits Length Description 0 - 31 32 bits Prefix 32 - 63 32 bits Teredo server IPv4 4136:e378 64 - 79 16 bits Flags 80 - 95 16 bits 96 - 127 32 bits

Obfuscated Client UDP port public IPv4 63bf 40000 3fff:fdd2 192.0.2.45

Part Decoded

2001:0000

8000

65.54.227.120 cone NAT

Servers
For a list of existing Teredo servers, see the list in External links. Teredo servers are used by Teredo clients to autodetect the kind of NAT behind which they are located (if any), through a simplified STUN-like qualification procedure. Teredo clients also maintain a binding on their NAT toward their Teredo server, by sending a UDP packet at regular time intervals. That ensures that the server can always contact any of its clients, which is required for hole punching to work properly. If a Teredo relay (or another Teredo client) has to send an IPv6 packet to a Teredo client, it will first send a Teredo bubble packet to the client's Teredo server, whose IP address can be inferred from the Teredo IPv6 address of the Teredo client. The server can then forward the bubble to the client, so the Teredo client software knows that hole punching must be done toward the Teredo relay. Teredo servers can also transmit ICMPv6 packet from Teredo clients toward the IPv6 Internet. In practice, when a Teredo client wants to contact a native IPv6 node, it must find out where the corresponding Teredo relay is (i.e. which public IPv4 and UDP port number to send encapsulated IPv6 packets to). To do that, the client crafts an ICMPv6 Echo Request (ping) toward the IPv6 node, and sends it through its configured Teredo server. The Teredo server decapsulates the ping onto the IPv6 Internet, so that the ping should eventually reach the IPv6 node. The IPv6 node should then reply with an ICMPv6 Echo Reply, as mandated by RFC 2460. This reply packet will be routed to the closest Teredo relay, which will finally try to contact the Teredo client. Maintaining a Teredo server requires little bandwidth because they are not involved into the actual transmission and reception of IPv6 traffic packets. Also, it does not involve any access to the Internet routing protocols. The only requirements for a Teredo server are: the ability to emit ICMPv6 packets with a source address belonging to the Teredo prefix two distinct public IPv4 addresses (although not written down in the official specification, Microsoft Windows clients expect both addresses to be consecutive); the second IPv4 address is needed for the purpose of NAT detection

Teredo tunneling Public teredo servers: teredo.remlab.net / teredo-debian.remlab.net (France) teredo.autotrans.consulintel.com (Spain) teredo.ipv6.microsoft.com (USA, Redmond) (default for WindowsXP/2003/Vista/2008 OS) teredo.ngix.ne.kr (South Korea) teredo.managemydedi.com (USA, Chicago) teredo.trex.fi (Finland)

51

Relays
A Teredo relay potentially requires a lot of network bandwidth. Also, it must export (advertise) a route toward the Teredo IPv6 prefix (2001:0::/32) to other IPv6 hosts. That way, the Teredo relay will receive traffic from the IPv6 hosts addressed to any Teredo client, and forward it over UDP/IPv4. Symmetrically, it will receive packets from Teredo clients addressed to native IPv6 hosts over UDP/IPv4 and inject those into the native IPv6 network. In practice, network administrators can set up a private Teredo relay for their company or campus; this will provide a short path between their IPv6 network and any Teredo client. However setting up a Teredo relay on a scale beyond that of a single network requires the ability to export BGP IPv6 routes to the other autonomous systems (AS's). Unlike 6to4, where the two halves of a connection can use different relays, traffic between a native IPv6 and a Teredo host will use the same Teredo relay, namely the one that is closest to the native IPv6 host network-wise. The Teredo host cannot localize a relay by itself (since it cannot send IPv6 packets by itself); if it needs to initiate a connection to a native-v6 host, it will send the first packet through the Teredo server, which sends a packet to the native-v6 host using the client's Teredo IPv6 address. The native-v6 host then responds as usual to the client's Teredo IPv6 address, which will eventually cause the packet to find a Teredo relay, which will initiate a connection to the client (possibly using the Teredo server for NAT piercing). The relay is then used for communication between the two hosts for as long as is needed. This design means that neither the Teredo server nor client needs to know the IPv4 address of any Teredo relays; a suitable one is automatically found by means of the global IPv6 routing table, since all Teredo relays advertise the network 2001:0::/32. For near-realtime information on Teredo and BGP, see the External links. On March 30, 2006, Italian ISP ITGate [1] was the first AS to start advertising a route toward 2001::/32 on the IPv6 Internet, so that RFC 4380-compliant Teredo implementations would be fully usable. As of 16 February 2007, it is not functional. In Q1 2009, IPv6 backbone Hurricane Electric enabled 14 Teredo relays[2] in an anycast implementation and advertising 2001::/32 globally. The relays were located in Seattle, Fremont, Los Angeles, Chicago, Dallas, Toronto, New York, Ashburn, Miami, London, Paris, Amsterdam, Frankfurt and Hong Kong. It is expected that large network operators will be maintaining Teredo relays. As with 6to4, it remains however unclear how well the Teredo service will scale up if a large proportion of Internet hosts start using IPv6 through Teredo in addition to IPv4. While Microsoft has been operating a set of Teredo servers ever since the first Teredo pseudo-tunnel for Windows XP was released, it has never provided a Teredo relay service for the IPv6 Internet as a whole.

Limitations
Teredo is not compatible with all NAT devices. Using the terminology of RFC 3489, full cone, restricted and port-restricted NAT devices are supported, while symmetric NATs are not. National Chiao Tung University proposed SymTeredo [3] which enhanced the original Teredo protocol to support symmetric NATs, and the Microsoft and Miredo implementations implement certain unspecified non-standard extensions to improve support for symmetric NATs. However, connectivity between a Teredo client behind a symmetric NAT, and a Teredo client

Teredo tunneling behind a port-restricted or symmetric NAT remains seemingly impossible. Indeed, Teredo assumes that when two clients exchange encapsulated IPv6 packets, the mapped/external UDP port numbers used will be the same as those that were used to contact the Teredo server (and building the Teredo IPv6 address). Without this assumption, it would not be possible to establish a direct communication between the two clients, and a costly relay would have to be used to perform triangle routing. A Teredo implementation tries to detect the type of NAT at startup, and will refuse to operate if the NAT appears to be symmetric. (This limitation can sometimes be worked around by manually configuring a port forwarding rule on the NAT box, which requires administrative access to the device). Teredo can only provide a single IPv6 address per tunnel endpoint. As such, it is not possible to use a single Teredo tunnel to connect multiple hosts, contrary to 6to4 and some point-to-point IPv6 tunnels. The bandwidth available to all Teredo clients toward the IPv6 Internet is limited by the availability of Teredo relays (which are no different in that respect from 6to4 relays).

52

Alternatives
6to4 requires a public IPv4 address, but provides a large 48-bit IPv6 prefix for each tunnel endpoint, and has a lower encapsulation overhead. Point-to-point tunnels can be more reliable and are more accountable than Teredo, and typically provides permanent IPv6 addresses that do not depend on the IPv4 address of the tunnel endpoint. Some point-to-point tunnel brokers additionally support UDP encapsulation to traverse NATs (for instance, the AYIYA protocol can do this). On the other hand, point-to-point tunnels normally require registration. Automated tools (for instance AICCU) exist to make it easy to use Point-to-Point tunnels.

Security considerations
Exposure
Teredo increases the attack surface by assigning globally routable IPv6 addresses to network hosts behind NAT devices, which are otherwise mostly unreachable from the Internet. By doing so, Teredo potentially exposes any IPv6-enabled application with an open port to the outside. It also exposes the IPv6 stack and the Teredo tunneling software to attacks should they have any remotely exploitable vulnerability. The Microsoft IPv6 stack has a "protection level" socket option. This allows applications to specify whether they are willing to handle traffic coming from the Teredo tunnel, from anywhere except Teredo (the default), or only from the local Intranet.

Firewalling, filtering, and blocking

For a Teredo pseudo-tunnel to operate properly, outgoing UDP packets must not be filtered. Moreover, replies to these packets (i.e. "solicited traffic") must also not be filtered. This corresponds to the typical setup of a NAT and its stateful firewall functionality. Teredo tunneling software will detect a fatal error and stop if outgoing IPv4 UDP traffic is blocked. Also, blocking of outgoing traffic to UDP port 3544 can interfere with Teredo activity.

Teredo tunneling

53

DoS via routing loops

Some new methods to create denial of service attacks via routing loops using Teredo tunnels have been uncovered recently. They are relatively easy to prevent.[4]

Implementations
Several implementations of Teredo are currently available: Windows XP SP2 includes a client and host-specific relay (also in the Advanced Networking Pack for Service Pack 1). Windows Server 2003 has a relay and server provided under the Microsoft Beta program. Windows Vista and Windows 7 have built-in support for Teredo with an unspecified extension for symmetric NAT traversal. However, if there is only a link-local and teredo address present, these operating systems will not attempt to resolve ipv6 DNS AAAA records if a DNS A record is present, in which case IPv4 will be used. Therefore, typically only literal IPv6 URLs will use teredo[5]. In the registry at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Dnscache\Parameters, adding a DWORD value: AddrConfigControl = 0 allows the use of a Teredo tunnel for IPv6 connectivity. Miredo is a client, relay and server for Linux, *BSD and Mac OS X, ng_teredo is a relay and server based on netgraph for FreeBSD from the LIP6 University and 6WIND.[6] NICI-Teredo is a relay for the Linux kernel and a userland Teredo server, developed at the National Chiao Tung University.[7]

Choice of the name

The initial nickname of the Teredo tunneling protocol was shipworm. The idea was that the protocol would pierce holes through NAT devices, much like the shipworms bore tunnels through wood. Shipworms are responsible for the loss of very many wooden hulls, but Christian Huitema in the original draft noted that "the animal only survives in relatively clean and unpolluted water; its recent comeback in several Northern American harbors is a testimony to their newly retrieved cleanliness. Similarly, by piercing holes through NAT, the service would contribute to a newly retrieved transparency of the Internet." Christian Huitema quickly changed the name to Teredo to avoid confusion with computer worms.[8] Teredo navalis is the Latin name of one of the best known species of shipworm.

References
[1] http:/ / www. itgate. net/ [2] Levy, Martin (May 28, 2009). "Hurricane Electric's experience in deploying Teredo and 6to4 relays" (http:/ / www. lacnic. net/ documentos/ lacnicxii/ presentaciones/ flip6/ 08_Martin_Levy. pdf). LACNIC-XII/FLIP6 2009 Conference, Panama City, Panama. . [3] http:/ / ieeexplore. ieee. org/ xpl/ freeabs_all. jsp?arnumber=1633339& fromcon [4] Gont, Fernando (September 8, 2010). "Internet-Draft - Teredo routing loops - Mitigating Teredo Rooting Loop Attacks" (http:/ / tools. ietf. org/ html/ draft-gont-6man-teredo-loops-00#ref-USENIX-WOOT). ietf.org. p. 2. . [5] http:/ / www. potaroo. net/ ispcol/ 2011-04/ teredo. html [6] Kabassanov, Konstantin; Jardin, Vincent. (October 22, 2003). ...Teredo for FreeBSD.... (http:/ / www-rp. lip6. fr/ teredo/ ) www-rp.lip6.fr. [7] "Solomon, Aaron". (November 29, 2004). NICI-Teredo (http:/ / sourceforge. net/ projects/ nici-teredo/ ). Sourceforge. [8] Huitema, Christian (December 19, 2001). "(ngtrans) Renaming Shipworm as Teredo?" (ftp:/ / ftp. ietf. org/ ietf-mail-archive/ ngtrans/ 2001-12. mail). IETF ngtrans wg mailing list. .

Teredo tunneling

54

External links
Teredo Overview (http://technet.microsoft.com/en-us/library/bb457011.aspx) on Microsoft TechNet Teredo relays (http://www.bgpmon.net/teredo.php): list of Teredo relays on BGPmon.net Current anycast Teredo BGP routes (http://www.sixxs.net/tools/grh/lg/?find=2001::/32) TEREDO-MNT (http://www.sixxs.net/tools/whois/?TEREDO-MNT): list of operators advertising the Teredo prefix via BGP List of Teredo servers (http://www.sixxs.net/tools/aiccu/brokers/) maintained by SixXS Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs). RFC 4380, C. Huitema. February 2006.

Miredo

55

Miredo
Miredo
Developer(s) Initial release Stable release Rmi Denis-Courmont 2004 1.2.4 / July 7, 2011

Development status Active Written in Available in Type License Website C Multilingual IP Tunneling GNU General Public License http:/ / www. remlab. net/ miredo/

Miredo is a Teredo tunneling client designed to allow full IPv6 connectivity to computer systems which are on the IPv4-based Internet but which have no direct native connection to an IPv6 network. Miredo is included in many Linux[1][2] and BSD[3][4] distributions and is also available for recent versions of Mac OS X.[5] It includes working implementations of: a Teredo client a Teredo relay a Teredo server Released under the terms of the GNU General Public License, Miredo is free software.

References
[1] [2] [3] [4] [5] "miredo" (http:/ / packages. qa. debian. org/ m/ miredo. html). Debian Package Tracking System. . "Fedora Package Database -- miredo" (https:/ / admin. fedoraproject. org/ pkgdb/ acls/ name/ miredo). . "The FreeBSD Ports Archive" (http:/ / www. freebsdsoftware. org/ net/ miredo. html). . "The NetBSD Packages Collection: net/miredo" (ftp:/ / ftp. netbsd. org/ pub/ pkgsrc/ current/ pkgsrc/ net/ miredo/ README. html). . "Teredo for MacOS X" (http:/ / www. deepdarc. com/ miredo-osx/ ). .

External links
Official website (http://www.remlab.net/miredo/)

NAT64

56

NAT64
NAT64 is a mechanism to allow IPv6 hosts to communicate with IPv4 servers. The NAT64 server is the endpoint for at least one IPv4 address and an IPv6 network segment of 32-bits (for instance 64:ff9b::/96, see RFC 6052, RFC 6146). The IPv6 client embeds the IPv4 address it wishes to communicate with using these bits, and sends its packets to the resulting address. The NAT64 server then creates a NAT-mapping between the IPv6 and the IPv4 address, allowing them to communicate.[1]

NAT64 and DNS64.

Principle of operation
Very simplistic NAT64 setup can be thought as a network device (a router) with at least two interfaces. One of this interfaces is connected to IPv4 network, and another is connected to IPv6 network. The network configured in a way that packets from IPv6 network to the IPv4 network get routed through this router. The router itself performs all the necessary translations needed to transfer packets from IPv6 network into the IPv4 network, and vice versa. The translation isn't symmetric, as IPv6 address space is a lot larger than IPv4 address space (compare: 2128 for IPv6 and 232 for IPv4), so no one-to-one address mapping is possible. Therefore, in order to be able to perform the translation, NAT64 is required to keep the IPv6 to IPv4 address mapping. Such an address mapping is either statically configured by the system administrator (stateless translation), or (more frequently) is created automatically when the first packet from IPv6 network reaches NAT64 to be translated (stateful). After this address binding is created, packets can flow in both directions. Stateless translation is appropriate when NAT64 translator is used in front of legacy IPv4-only servers to allow them to be reached by remote IPv6-only clients. Stateful translation is suitable for deployment at the client side or at the service provider, allowing IPv6-only client hosts to reach remote IPv4-only nodes. In general, NAT64 is designed to be used when the communications are initiated by IPv6 hosts. Some mechanisms (including static address mapping) exist to allow the reverse.

Implementations
TAYGA [10], a stateless NAT64 implementation for Linux Ecdysis [12], a NAT64 gateway, includes DNS64 Microsoft Forefront Unified Access Gateway, a reverse proxy and VPN solution that implements DNS64 and NAT64 Stateless Network Address Translation 64 [2] on Cisco ASR 1000 Stateful NAT64 feature [3] on Juniper MX Series 3D Universal Edge router OpenBSD 5.1 should bring a PF packet filter capable of NAT64 [4]

NAT64

57

References
[1] [2] [3] [4] RFC 6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers http:/ / www. cisco. com/ en/ US/ docs/ ios/ ios_xe/ ipaddr/ configuration/ guide/ iad_stateless_nat64_xe. html http:/ / kb. juniper. net/ InfoCenter/ index?page=content& id=TN123 http:/ / www. viagenie. ca/ pipermail/ ecdysis-discuss/ 2011-October/ 000173. html

ISATAP
ISATAP (Intra-Site Automatic Tunnel Addressing Protocol) is an IPv6 transition mechanism meant to transmit IPv6 packets between dual-stack nodes on top of an IPv4 network. Unlike 6over4 (an older similar protocol using IPv4 multicast), ISATAP uses IPv4 as a virtual nonbroadcast multiple-access network (NBMA) data link layer, so that it does not require the underlying IPv4 network infrastructure to support multicast.

How ISATAP works

ISATAP defines a method for generating a link-local IPv6 address from an IPv4 address, and a mechanism to perform Neighbor Discovery on top of IPv4.

Link-local address generation

Any host wishing to participate in ISATAP over a given IPv4 network can set up a virtual IPv6 network interface. The link-local address is determined by concatenating fe80:0000:0000:0000:0200:5efe: for global unique and fe80:0000:0000:0000:0000:5efe: for private addresses with the 32 bits of the host's IPv4 address. For example, host 192.0.2.143 would use fe80:0000:0000:0000:0200:5efe:192.0.2.143 as its link-local IPv6 address. A shortened notation would be fe80::200:5efe:c000:028f (192.0.2.143 is c000028f in hexadecimal notation).

Neighbor Discovery
Because ISATAP uses IPv4 as a non multicast/broadcast-capable (unlike Ethernet) link layer, ICMPv6 Neighbor Discovery cannot be done in the usual manner. That is why ISATAP is a bit more complex than 6over4. The link layer address associated with a given IPv6 address is contained in the lower-order 32-bits of the IPv6 address, so that Neighbor Discovery is not really needed. However, the lack of multicast support prevents the use of automatic Router Discovery. Therefore, ISATAP hosts must be configured with a potential routers list (PRL). Each of these routers is infrequently probed by an ICMPv6 Router Discovery message, to determine which of them are functioning, and to perform unicast-only autoconfiguration (typically, obtain the list of on-link IPv6 prefixes that can be used). In practice, implementations build their PRL by querying the DNS, e.g. by looking up isatap.example.com if the local domain is example.com. The local domain is typically obtained via DHCP (over IPv4) or statically configured.

ISATAP

58

Criticisms of ISATAP
ISATAP typically builds its PRL by consulting the DNS; hence, it is a lower-layer protocol that relies on a higher layer. A circularity is avoided by relying on an IPv4 DNS server, which does not rely on IPv6 routing being established; however, this is a violation of network design principles, and feels brittle to some network specialists.[1] ISATAP carries the same security risks as 6over4: the IPv4 virtual link must be delimited carefully at the network edge, so that external IPv4 hosts cannot pretend to be part of the ISATAP link. That is normally done by ensuring that proto-41 cannot pass through the firewall.

Implementations of ISATAP
ISATAP is implemented in Microsoft Windows XP, Windows Vista, Windows 7, Windows Mobile, Linux, and in some versions of Cisco IOS. Due to a patent claim, early in-kernel implementations were withdrawn from both KAME (*BSD) and USAGI (Linux). However the IETF IPR disclosure search engine reports that the would-be infringing patents holder requires no license from implementers.[2] ISATAP support has been supported in Linux since kernel version 2.6.25,[3] the tool isatapd [4] provides a userspace helper. For prior kernels, the open source project Miredo provided an incomplete userland ISATAP implementation, which was removed in version 1.1.6.

References
[1] [2] [3] [4] http:/ / www. ops. ietf. org/ lists/ v6ops/ v6ops. 2002/ msg01045. html https:/ / datatracker. ietf. org/ public/ ipr_detail_show. cgi?ipr_id=550 http:/ / git. kernel. org/ ?p=linux/ kernel/ git/ torvalds/ linux-2. 6. git;a=commit;h=c7dc89c0ac8e7c3796bff91becf58ccdbcaf9f18 http:/ / www. saschahlusiak. de/ linux/ isatap. htm

F. Templin, T. Gleeson, D. Thaler Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) RFC 5214, March 2008.

Other External links

http://www.isatap.org/

SATSIX

59

SATSIX
SATSIX is a demonstration of IPv6 integration of hybrid satellite and Wireless local loop (WLL) and is funded by the Sixth Framework Programme through Information Society Technologies. The project will help in the implementation of the European Space Policy and the i2010 European Initiative. [1] The consortium believes satellite systems can drive IPv6 implementation and deployment, providing a native solution for geographically separated users. [1] The consortium is actively participating in the standardization activities and include Broadband Satellite Multimedia (ETSI BSM), Digital Video Broadcasting (DVB), and Internet Engineering Task Force (IETF).

Consortium
Thales Alenia Space, France Telespazio (TPZ), Italy CNRS/LAAS (LAAS), France Sapienza University of Rome, Italy SINTEF (STI), Norway University of Surrey, United Kingdom University of Aberdeen (UoA), United Kingdom Telefnica I+D (TID), Spain Alcatel Alenia Space Espana (AASE), Spain B2I (B2I), France Systek (STK), United Kingdom Hispasat SA (HAS), Spain University of Vallodolid (UVA), Spain Hungaro Digitel Plc (HDT), Hungary

Goals
The project has two goals [1] 1. Lower broadband satellite access costs by development of new satellite access techniques and integrating with wireless local loop (WiFi and WiMax) 2. Develop recommendations, test beds, trial networks, show satellite broadband access with networks based on IPv6, and support new multimedia applications The concept of the project will first be validated in simulation, followed by emulation, live experimentation with end-to-end applications, promoted by information dissemination and training. [1]

Expected Results [1][2]

Impact of integration of IPv6 protocol into DVB-S2/DVB-RCS Integration of dynamic multicast service into satellite networks Security features for satellite network applications (Key management, DRM, ) Definition, selection and validation of header compression techniques Integration of mobility management into satellite networks Integration of innovative applications into satellite network Definition of inter-networking aspects [Sat + WiFi, Sat + WiMax, ] Definition of hybrid satellite systems [OBP + Transparent payload]

Integration of innovative applications into satellite networks Definition of QoS for different scenarios

SATSIX Critical path validation through emulated and live test beds Provide recommendation to standardization bodies

60

Scenarios [1]
The project will leverage existing satellites in the Ku/Ka radio frequency band and will create several application perspectives of space based and terrestrial based systems. [1] 1. Corporate applications on DVB-RCS transparent access platform uses a DVB-RCS star network Multicast support Security implementations Mobility enhancements for telecommuters Quality of Service Collaborative Working Videoconferencing Live/Real-time encoding video and streaming

2. Collective Access Terminal on DVB-RCS transparent access platform sharing of satellite communications with wireless local loop (WiFi or WiMAX). The WiFi and WiMAX connection to a Satellite Termineal (ST) is considered a LAN while any local loops are considered as sub_LAN and therefore all traffic must pass through a Satellite Gateway. [3] eGovernment Internet Banking E-mail Web Audio, video streaming IP phone e-Learning Games Tele-Medicine

3. Corporate applications on DVB-RCS regenerative access platform - uses a DVB-RCS mesh network Enhanced Quality of Service and Multicast functionality Network Address Translation (NAT), security enhancements Multi-conferencing, E-Learning, Video on Demand, Digital TV Virtual Private Network (VPN)

4. Residential applications on DVB-RCS transparent access platform related to the goals to reach residential users and compete with solutions similar to ADSL and cable solutions with three services; Telephonic, internet, and television. [2] Three areas of focus for mobility include; Discrete Mobility The ability for a user to move from one location to another location Continuous Mobility The ability in a rural location Seamless Mobility User moving between satellite and local networks

SATSIX

61

Emulation
The project will emulate a complete DVB-RCS/DVB-S2 satellite system and validate performance, simplicity, and usability along with access. Areas to emulate include encapsulation protocols such as DVB-RCS/DVB-S2/AAL5, Internet Protocol version 4 and 6, Quality of Service including HDLB and SIP proxies, Mobile IPv6 support, and multicasting. [4]

Architecture
Two types of architecture were implemented, the Transparent Star and the Regenerative Mesh/Star while using IPv6/DVB-S. The WiFi and WiMAX terrestrial links access the satellite link at Return Channel Satellite Terminal (RCST). [5]

Quality of Service (QoS)

With the hybrid networks of satellite and Wireless local loop (WLL), proper Quality of Service (QoS) is necessary for SIP negation and the forwarding of the mobile packet streams. Currently, the mobile IP routing decision algorithms do not consider the resources such as network bandwidth and with each node change, the parameters will change. Interaction between the Wireless local loop (WLL) and the satellite links introduce two issues, overriding of QoS parameters previously negotiated by SIP and the second is traffic directed to a satellite node my not accept due to saturated queues. [5] The inclusions of mobility have significant impacts to QoS management and provisions. The mobility architecture can be based on QoS server, agent, or awareness applications alonge with enchancing SIP proxies. Recommendations included active sessions negotiating for QoS along the new route as part of handover procedures.
[6]

Protocols
Several different protocols are used in the network architectures and the consortium is involved in continued development of the standards. Several standards include MIPv6, HMIPv6, Session Initiation Protocol (SIP), Unidirectional Lightweight Encapsulation (ULE), Generic Stream Encapsulation (GSE) Session Initiation Protocol (SIP) This protocol is an application-layer signaling protocol based on a client-server architecture. User agents (UA) originate and terminate sessions. The Localization Servers (LS) locate the User Agents (UA) while the Registrar Servers (RS) provide databases in which the location of the user is stored and modified, then the Proxy Servers (PS) relay requests to another server. [6] ULE/DVB The DVB standard uses the MPEG-2 Transport Stream, 188 bytes plus a 4 byte header, in order to carry audio and video packetized streams. [7] The DVB group has several standards to encapsulate IP datagrams within the MPEG-2 Transports Stream, Multiprotocol Encapsulation (MPE) and Ultra Light Encapsulated (ULE). MPE header totals 8 bytes with an additional 4 byte CRC with an additional LCC/SNAP header which notifies different types of Ethernet payloads. ULE header consists of 4 bytes and the MPE ULE uses a 4 byte CRC. [7]

SATSIX

62

Multicasting
Remote subscription - mobile node joins a multicast group via a local multicast router using a Care-of-Address instead of a Home Address. [6] Home Subscription - mobile node joins the group, send and receive packets from its Home Agent through bidirectional tunneling. [6] Multicast Listener Discovery (MLD) - mix of Remote and Home subscription where a Multicast Agent near the Home Agent network joins the multicast session on behalf of mobile node in the visiting network then forwards traffics to attached mobile nodes. [6]

Related Projects
BRAHMS ICEBERGS IBIS SATIP6 SATLIFE SATNEX

Further reading
RFC 3828 - The Lightweight User Datagram Protocol (UDP-Lite) [8] RFC 4326 - Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS) [9] RFC 4340 - Datagram Congestion Control Protocol (DCCP) [10] SATSIX: A Network Architecture for Next Generation DVB-RCS Systems [11]

References
[1] "D4000-1 Dissemination and Use plan" (http:/ / www. ist-satsix. org/ DOC/ SatSix-4000-v1-0. pdf). Information Society Technologies. . Retrieved 2008-05-21. [2] "3000-11 Exploitation Plan" (http:/ / www. ist-satsix. org/ DOC/ SATSIX - D3000-11_vf-01. pdf). Information Society Technologies. . Retrieved 2008-05-21. [3] "D1000-3 Collective access terminal scenario" (http:/ / www. ist-satsix. org/ DOC/ SATSIX-D1000-3_Final_v1. 0. zip). Information Society Technologies. . Retrieved 2008-05-21. [4] "Emulation testbed implementation (1st Phase) Validation document" (http:/ / www. ist-satsix. org/ DOC/ D3000-2_final_v1. pdf). Information Society Technologies. . Retrieved 2008-05-21. [5] "Interworking Strategy between DVB-RCS and WiMAX" (http:/ / www. ist-satsix. org/ INNSS07/ Interworking Wimax Final. pdf). Telespazio. . Retrieved 2008-05-21. [6] "SATSIX Mobility Architecture and its performance evaluation" (http:/ / www. ist-satsix. org/ INNSS07/ SATSIX_mobility_architecture_performance. pdf). SINTEF. . Retrieved 2008-05-21. [7] "Efficiency of IPv6 Encapsulation with ULE/DVB" (http:/ / www. telenor. no/ broadwan/ BROADWAN_CD/ Publications/ Collini-Nocker_IPv6_ULE_OCG_May2005. pdf). . Retrieved 2008-05-21. [8] http:/ / www. ietf. org/ rfc/ rfc3828. txt/ [9] http:/ / www. ietf. org/ rfc/ rfc4326. txt/ [10] http:/ / www. rfc-editor. org/ rfc/ rfc4340. txt/ [11] http:/ / arjuna. sathiaseelan. googlepages. com/ SATSIXANETWORKARCHITECTUREFORNEXTGEN. doc/

SATSIX

63

External links
SATSIX (http://www.ist-satsix.org/) - official website SINTEF (http://www.sintef.com/) - official website Thales Alenia Space (http://www.thalesaleniaspace.com/) - official website University of Surrey (http://www.surrey.ac.uk/) official website University of Aberdeen (http://www.abdn.ac.uk/) official website Telefonica (http://www.telefonica.com/home_eng.shtml) -company website (English-language pages) Systek (http://www.systek.com/) official website Hispasat (http://www.hispasat.com/default.aspx?sectionsId=1&lang=en/) - official website University of Valladolid (http://www.universityofvalladolid.uva.es/) official website

China Next Generation Internet

The China Next Generation Internet (CNGI) (simplified Chinese: ; traditional Chinese: ; pinyin: Zhnggu Xi Ydi Hlinwng) project is a five year plan initiated by the Chinese government with the purpose of gaining a significant position in the future development of the Internet through the early adoption of IPv6.

Key CNGI goals

According to a brochure entitled "CNGI-CERNET2/61X", the CNGI effort's key tasks were as follows: Construction of China's next generation Internet backbones Development of key network technology and major applications for the next generation Internet Promotion of industrialization and application development of next generation Internet equipment and software Participation in international organizations, and playing an important role in standards setting

IPv6 was selected as key technology. The United States has almost one third of the theoretical maximum IPv4 addresses (about 4.3 billion [255^4 - 19M] ) [1], while China has more high-speed Internet users than IP addresses and the largest Internet user base of any country.[2] With the implementation of IPv6, China planned to avoid imminent problems of IPv4 address exhaustion.

History
The origins of CNGI date to 2001 when 57 members of the Chinese Academy of Science and Chinese Academy of Engineering wrote a letter to the State Council recommending construction of the next generation academic Internet. In 2002 the National Development and Reform Commission (NDRC) organized a study of the topic, and in 2003 the study group submitted a strategic report. After authorization, the CNGI was then launched under the auspices of eight ministries: NDRC as the lead, Ministry of Education, Ministry of Information Industry, the State Council Information Office, Chinese Academy of Science, Chinese Academy of Engineering, and the National Natural Science Foundation.

Current status
As of October 2009, the CNGI effort comprises six nationwide backbone networks and 39 GigaPOPs , which extends the next generation footprint to over 20 major cities and over 300 academic, industrial, and government research campuses within China. Five backbones are commercial (operated by China Telecom, China Unicom, China Netcom/CSTNET, China Mobile, and China Railcom), with an additional academic research network operated by CERNET, which is known as CNGI-CERNET2. CNGI also encompasses two exchange points (IX) in

China Next Generation Internet Beijing (named CNGI-6IX) and Shanghai for interconnecting these backbones and for international links to APAN (Asia Pacific Advanced Network), GEANT, and Internet2. China showcased CNGI and the IPv6 network infrastructure at the 2008 Olympics in Beijing for the website www.beijing2008.cn. The launching of the domain ipv6.beijing2008.cn was witnessed by officials from Tsinghua University, the CERNET, the Technology Department of BOCOG and Sohu.com.[3] Everything from security cameras, taxis, to the Olympic events cameras are networked by IPv6; the events are streamed live over the Internet while networked cars are able to monitor traffic conditions readily.

64

CNGI-CERNET2 backbone
As of October 2009, the CNGI-CERNET2 backbone runs native IPv6 to connect 25 PoPs in 25 cities. Most links run at 2.5 Gbit/s with 10 Gbit/s connections between Beijing-Wuhan-Guangzhou and Wuhan-Nanjing-Shanghai. Access links run at 1 Gbit/s, 2.5 Gbit/s, or 10 Gbit/s.

References
[1] "Overview of Country IP Usage", BGPExperts.com, May 7, 2007 (http:/ / www. bgpexpert. com/ addressespercountry. php) [2] "China Surpasses U.S. In Internet Use", Forbes.com, March 4, 2006 (http:/ / www. forbes. com/ 2006/ 03/ 31/ china-internet-usage-cx_nwp_0403china. html) [3] Beijing2008.cn. " Beijing 2008 (http:/ / en. beijing2008. cn/ news/ official/ preparation/ n214384681. shtml)." Beijing2008.cn leaps to next generation Net. Retrieved on 2008-11-09.

"CNGI-CERNET2/6IX", undated brochure, consulted in October 2009.

External links
Virtual China: IPv6: China's next generation Internet (http://www.virtual-china.org/2007/01/04/ china-ipv6-update/) China Reaps Big Fruits for Future Internet (http://english.people.com.cn/200609/26/eng20060926_306545. html)

DoD IPv6 Product Certification

65

DoD IPv6 Product Certification

Historical Testing Program
As of February 2009, the DoD ceased the requirement for IPv6-only testing for certification and entry into the Unified Capabilities Approved Products List (UC APL). According to Kris Strance, DoD CIO IPv6 Lead, "The testing of IPv6 is a part of all product evaluations it is much broader in scope now." [1]

Background
The Department of Defense (DoD) Internet Protocol version 6 (IPv6) product certification program began as a mandate from the DoD's Assistant Secretary of Defense for Networks & Information Integration (ASD-NII) in 2005. The program mandates the Joint Interoperability Test Command (JITC) in Fort Huachuca, AZ, to test and certify IT products for IPv6 capability according to the Request For Comments (RFCs) outlined in the DoD's IPv6 Standards Profiles for IPv6 Capable Products. Once products are certified for special interoperability, they are added to the DoD's Unified Capabilities Approved Products List (UC APL) for IPv6 [2]. This list is used by procurement offices in the DoD and the U.S. Federal agencies for ongoing purchases and acquisitions of IT equipment.

DoD's IPv6 Standards

The DoD IPv6 Standards Profiles for IPv6 Capable Products (DoD IPv6 Profile) [3] is the singular IPv6 Capable definition in DoD. It is a document that lists the six agreed upon product classes (Host, Router, Layer 3 Switch, Network Appliance, Security Device, and Advanced Server) and their corresponding standards (RFCs). It lists each standard according to its level of requirement: MUST: The standard is required to be implemented in the product now. SHOULD: The standard is optional, but recommended for implementation. SHOULD+: The standard is optional now, but will be required within a short period of time.

DoD's IPv6 Generic Test Plan

The JITC uses its publicly available IPv6 Generic Test Plan (GTP) [4] to test each product for its conformance, performance and interoperability of IPv6 according to the DoD IPv6 Profile. The JITC uses a combination of automated testing tools and manual functional test procedures to conduct this testing.

The Process
1. The vendor, or Program Manager, must make their intentions known to test by providing the JITC with a Letter of Compliance (LoC). This letter will consist of the product to test, the product class it belongs to, a listing of all of the standards that it implements, and a signature from a Vice President or officer of the company. This is the gateway to the testing process. 2. Once the LoC is received, the product is then scheduled for test. 3. Approximately 6 weeks before the start of testing, the vendor must provide the JITC with funding. This funding must be in the form of a check. The amount is only to charge direct labor hours for testing by the contractor labor support. 4. If the product successfully meets the criteria, it will be entered on the DoD's UC APL for IPv6. 5. An IPv6 Capable Special Interoperability Certification Letter and Report will accompany the entry within 3060 days after testing.

DoD IPv6 Product Certification

66

IPv6 Pre-Certification Testing Advocates

There are many companies and organizations that help develop and test products for vendors prior to testing at the JITC. These organizations cannot grant certification, but can conduct pre-testing to ensure a vendor's product will pass the necessary certification. Below is a list of these organizations: Command Information - Command Ready: http://www.commandinformation.com/ipv6/commandready.html
[5]

The University of New Hampshire InterOperability Laboratory - IPv6 Ready Logo testing: [6] Troy Networks, Inc. - Test and Certification Support Services: http://www.troy.net [7]

References
The Unified Capabilities Approved Products List for IPv6: http://jitc.fhu.disa.mil/apl/ipv6.html Official IPv6 Capable Certification Testing Process: http://jitc.fhu.disa.mil/apl/ipv6/pdf/ ipv6_certification_process_ipv6_v2.pdf The DoD IPv6 Standards Profiles for IPv6 Capable Products, Version 4: http://jitc.fhu.disa.mil/apl/ipv6/pdf/ disr_ipv6_product_profile_v4.pdf The DoD IPv6 Generic Test Plan: http://jitc.fhu.disa.mil/adv_ip/register/docs/ipv6v4_may09.pdf The Testing Times, March 2008, Volume 15, Number 1: http://jitc.fhu.disa.mil/tst_time/docs/year/mar08. pdf

References
[1] [2] [3] [4] [5] [6] [7] http:/ / www. fcw. com/ Articles/ 2009/ 02/ 20/ IPv6-testing. aspx http:/ / jitc. fhu. disa. mil/ apl/ ipv6. html http:/ / jitc. fhu. disa. mil/ apl/ ipv6/ pdf/ disr_ipv6_product_profile_v3. pdf http:/ / jitc. fhu. disa. mil/ adv_ip/ register/ docs/ ipv6v4_may09. pdf http:/ / www. commandinformation. com/ ipv6/ commandready. html http:/ / www. iol. unh. edu/ services/ testing/ ipv6/ http:/ / www. troy. net

Comparison of IPv6 support in routers

67

Comparison of IPv6 support in routers

This list is incomplete. This is a comparison of consumer and commercial network routers in regards to their support of the IPv6 protocol.
Manufactururer Model Native IPv6 support? Yes Yes Yes Yes Notes Reference links

Allied Telesis Allied Telesis Allied Telesis Apple

AR415S AR550S / AR750S AR570S / AR770S Airport Extreme Base Station Time Capsule

Supports static and dynamic IPv6 routing Supports static and dynamic IPv6 routing Supports static and dynamic IPv6 routing Supports IPv6 over WAN or via a network tunnel, cannot route IPv6 directly over DSL. Supports IPv6 over WAN or via a network tunnel, cannot route IPv6 directly over DSL. Supports IPv6 over WAN DSL or via a network tunnel. Supports IPv6 over WAN DSL or via a network tunnel. Supported as of firmware version 6.21. Supported as of firmware version 6.21. Supported as of firmware version 6.21. Supported as of firmware version 6.21.

[1] [2] [3]

Apple

Yes

AVM

FRITZ!Box Fon wlan 7390

Yes

[4]

AVM

FRITZ!Box Fon wlan 7270

Yes Yes Yes Yes Yes No Yes No Yes No Yes No Yes Yes Yes No Yes Yes Yes

[5]

Billion Billion Billion Billion Billion Billion Billion Billion Billion Billion Billion Billion Billion Billion Billion Billion Billion Billion

BiPAC 7402XL BiPAC 7402X BiPAC 7402GXL BiPAC 7402GX BiPAC 7402NXL BiPAC 7402NX BiPAC 7402R2 BiPAC 7401VGP-R3 BiPAC 7401VGP-X BiPAC 7404VGP-X BiPAC 7404VGO-M BiPAC 7404VGO-X BiPAC 7404VNP-X BiPAC 7404VNO-X BiPAC 7700N BiPAC 7800 BiPAC 7800N BiPAC 7800NL

[6] [6] [6] [6] [6]

Supported as of firmware version 6.21. Firmware version 5.74 no support for IPv6. The recommended VoIP modem from Internode.

[6] [6] [7] [6] [7]

Firmware version 5.74 no support for IPv6.

[7] [7] [7] [7] [6]

Supported as of firmware version 1.06e. Supported as of firmware version 1.06d.

[6] [6] [6]

Comparison of IPv6 support in routers

68
IPv6 supported by PLUS images of IOS release 12.3(4XG) forward.

Cisco

830 Series

Yes No Yes

[8]

D-Link D-Link D-Link

DIR-300 DIR-601 DIR-615

[9] [9]

Yes

IPv6 supported by hardware revisions C1 and E. Earlier revisions and revision D do not support IPv6.

[9]

D-Link D-Link

DIR-632 DIR-655

Yes Yes No IPv6 supported by hardware revision B. Earlier revisions do not support IPv6. IPV6 traffic unfirewalled. IPv6 supported by hardware revision B. Earlier revisions do not support IPv6.

[9] [9]

D-Link D-Link

DIR-685 DIR-825

[9] [9]

Yes

D-Link D-Link D-Link Draytek Motorola Netgear Netgear

DIR-852 DIR-865 DHP-1320 Vigor 2130n SBG6580 WNR3500L WNDR3700/WNDR37AV

No No Yes Yes Yes Yes Yes IPv6 supported ([11] Firmware Version 1.2.2.30) IPv6 supported ([13] Firmware Version 1.0.7.98), WNDR37AV is identical to a WNDR3700 Supports IPv6 when flashed with D-Link DIR-615 rev. C1 firmware update. dynamic address translation to extend proven dual stack functionality dynamic address translation to extend proven dual stack functionality dynamic address translation to extend proven dual stack functionality dynamic address translation to extend proven dual stack functionality dynamic address translation to extend proven dual stack functionality dynamic address translation to extend proven dual stack functionality dynamic address translation to extend proven dual stack functionality (DSL modem/router)

[9] [9] [9]

[10] [12] [14]

Trendnet

TEW-652BRP

No

vantronix

.vtFW-EM2

Yes

[www.vantronix.com]

vantronix

.vtFW-EM2p

Yes

[www.vantronix.com]

vantronix

.vtFW-C1

Yes

[www.vantronix.com]

vantronix

.vtFW-C2

Yes

[www.vantronix.com]

vantronix

.vtFW-HA1

Yes

[www.vantronix.com]

vantronix

.vtFW-ZL1 and .vtFWZL2

Yes

[www.vantronix.com]

vantronix

.vtRT-ZL1 and .vtRT-ZL2

Yes

[www.vantronix.com]

Comparison of IPv6 support in routers

69

Third-party firmwares with IPv6 support

Name OpenWrt DD-WRT Tomato-USB Version 1.28 or later. Notes 8.09 supports v6 routing with Quagga. 10.03.1 supports v6 routing with Quagga & BIRD. Reference links
[15] [16] [17]

Consumer routers with 6to4 support

Apple's Airport Extreme & Airport Express base station Linksys WRT610N Cisco Linksys E4200 Cisco Linksys E3200 Cisco Linksys E2500 Cisco Linksys E1500 Cisco Linksys E1200 Various Buffalo Technology wireless routers D-Link DIR-615, DIR-655 Rev.B, DIR-825 (V2 firmware; currently available for the DIR-825 Rev. B only!) AVM FRITZ!Box 7270 & 7390 (since firmware 74.04.86) Mikrotik RouterOS software and RouterBoard hardware. Requires v3 and above with the IPv6 package installed Fortinet's FortiGate. Also supports stateful Firewalling, Antivirus, Application-Control and Intrusion-Protection for IPv6 NETGEAR's WNR3500L (since firmware V1.2.2.30) NETGEAR's WNR3700v1 (since firmware V1.0.6.98) NETGEAR's WNDR4000v1 (since firmware V1.0.0.60) NETGEAR's WNDR3800v1 (since firmware V1.0.0.00)

References
[1] http:/ / www. alliedtelesis. com/ p-2007. html [2] http:/ / www. alliedtelesis. com/ pcline-32 [3] http:/ / www. alliedtelesis. com/ pcline-47 [4] http:/ / www. fritzbox. eu [5] http:/ / www. avm. de/ de/ Service/ Datenblaetter/ AVM_FRITZBox_Fon_WLAN_7270_int. pdf [6] http:/ / www. billion. com/ product/ 2011-Billion-Product-Guide. pdf [7] http:/ / au. billion. com/ downloads/ ver6. 21. pdf [8] http:/ / www. cisco. com/ en/ US/ docs/ ios/ 12_3/ 12_3x/ release/ notes/ rn800xg. html#IPv6_Support [9] http:/ / blog. dlink. com/ connect/ d-link-ready-big-switch-ipv6/ [10] http:/ / www. motorola. com/ Video-Solutions/ US-EN/ Products-and-Services/ Voice-and-Data-Consumer-Premise-Equipment/ DOCSIS-Modems-Gateways-and-eMTAs/ Wireless-Cable-Modem-Gateways/ SBG6580?localeId=33 [11] http:/ / kb. netgear. com/ app/ answers/ detail/ a_id/ 16643 [12] http:/ / www. netgear. com/ service-provider/ products/ routers-and-gateways/ gigabit-ethernet-routers-gateways/ WNR3500L. aspx [13] http:/ / kb. netgear. com/ app/ answers/ detail/ a_id/ 18632 [14] http:/ / kb. netgear. com/ app/ products/ model/ a_id/ 11640 [15] http:/ / wiki. openwrt. org/ doc/ howto/ ipv6 [16] http:/ / www. dd-wrt. com/ [17] http:/ / tomatousb. org/ /

Comparison of IPv6 application support

70

Comparison of IPv6 application support

This is a comparison of popular Internet applications in regards to their support of the IPv6 protocol.

Applications
Application Category IPv6 supported? Zone ID supported? Earliest version # with IPv6 support 5.01 Yes No Notes Reference links

AbsoluteTelnet

SSH client, Telnet client, SFTP Client LDAP server

Supports SSH, Telnet, and SFTP

[1]

Active Directory

Yes

2008

Suggest using 2008 R2 - Per Networkworld.com "Virtual hosts on IPv6 addresses are broken in versions until 2.0.28"

[2] [3] [4]

Apache httpd

Web server

Yes Yes Yes Yes

N/A

2.0.14

[5]

Apple Mail BIND BSD Telnet

e-mail client DNS server Console application FTP Server

N/A Yes 1.2? Telnet and telnetd from OpenBSD.

Cerberus FTP Server CUPS cURL

Yes Yes Yes Yes Yes Yes

N/A

3.0

Supports RFC 2428 FTP Extensions for IPv6

[6]

Digital printing File transfer software XMPP server Proxy server FTP, FTPS and SFTP client Console application Web browser Web server Web server

1.2

[7]

ejabberd ffproxy FileZilla

N/A

0.7 or older 1.5 3.1.0-beta1

Jabber server Non-caching proxy.

[8]

[9][10]

ftp.exe

Yes Yes Yes

Yes

5.1 (XP)

Standard Windows FTP client.

Google Chrome Hiawatha IIS

Initial N/A 6.0 6.0 Versions before 7.0 do not support bandwidth throttling, client IP address restrictions, FTP, or NNTP. Versions before 7.0 may not be able to handle numerical addresses. Macintosh versions do not support IPv6.
[11]

Yes

N/A

Internet Explorer

Web browser Yes No

4.01

[12][13][14]

Irssi jabberd2 Java

IRC client XMPP server Programming language Web browser

Yes Yes Yes Yes N/A Yes Yes

0.7.15 2.0 1.4.2 Jabber server Support on Windows XP/2003 was added in Java 1.5.0

[15]

[16][17][18]

Konqueror

2.2

[19]

Comparison of IPv6 application support

71
Yes Yes N/A 1.49 cifs vfs version 1.48 is part of kernel 2.6.21 Standard Linux FTP client.
[20]

lighttpd

Web server

Linux CIFS VFS SMB/CIFS client

Linux NetKit ftp

Console application Console application DNS server DNS server

Yes

Yes

0.17?

Linux NetKit Telnet MaraDNS Microsoft DNS

Yes Partial

Yes N/A

0.17?

Standard Linux telnet client and server.

5.0 (2000) Yes N/A

Windows 2000 DNS can handle AAAA records, but the operating system does not ship with IPv6.

[21]

Microsoft Outlook Microsoft SQL Server mIRC Mozilla / SeaMonkey Mozilla Firefox

e-mail client

Yes

2003?

Database

Yes Yes Yes

2005 (9.0)

[22], [23]

IRC client Web browser

7.1 IPv6 is not preferred by default on Mac OS X. 1.5 IPv6 is not preferred by default on Mac OS X in Firefox 1.5 or 2.0, only in 3.0. Version 2.0 & later appears to work with Mac OS X Version 10.4.9. N/A For example in HTTP streaming.
[24] [25] [14] [14] [25]

Web browser Yes Yes

Mozilla Thunderbird MPlayer

e-mail client

Yes

[26]

Multimedia player Database Web server Console application VPN client

Yes No Yes Yes ?

MySQL nginx Nmap

0.7.36 Yes 3.10ALPHA1

Full support implemented in 0.8.22 Zone ID support since version 4.65

[27] [28] [29]

Nortel Networks VPN client Novell eDirectory OpenLDAP OpenSSH

[30]

LDAP server

LDAP server SSH client/server VPN client

Yes Yes Yes

2.0.0

[31]

OpenVPN

2.0 Planned

Does not support "server mode" in IPv6: multiple tunnels require separate ports. IPv6 support on Macintosh was added in Opera 9.0

[32]

Opera

Web browser

Yes Yes No

No

7.20b

[33] [34] [35] [36] [37]

Oracle Outlook Express

Database e-mail client

11gR1 N/A Windows Mail on the Windows Vista platform has IPv6 support.

[38]

Comparison of IPv6 application support

72
2.0 (GAIM had support in older builds) No 0.8 IPv6 is enabled on Linux builds, but not on Win32 builds.

Pidgin

Instant messenger

Yes

[39]

Polipo

Proxy server

Yes Yes Yes Yes Yes

Can be used for proxying between IPv4 and IPv6 IPv6 broken in AIX version

PostgreSQL Privoxy PuTTY

Database Proxy server SSH client

3.0.13 beta Yes N/A 2.5.0 0.58 Fully functional (also Zone ID's) from 0.59 OSPFv3 area support is incomplete. native IPv6 support since 2.5.0, but hosts allow/deny in rsync.conf didn't work until 2.5.6.

[40] [41] [42]

Quagga rsync

Routing software differential file synchronizer

[43] [44] [45] [46]

Yes

rTorrent RusHub

BitTorrent client Direct Connect server Web browser SMB/CIFS client/server DNS server

No Yes Yes Yes No 3.2.0 2.3.3

[47]

Safari Samba

[14] [48]

Simple DNS Plus Skype SmartFTP

Yes No Yes Yes Yes

N/A

5.0 (Jan 2008)

[49]

VoIP FTP and SFTP client SOCKS server Proxy server

[50]

srelay Squid cache

N/A 3.0STABLE1 Development work has been intermittent from 2001-2007. Standard Windows telnet client.
[51] [52]

telnet.exe

Console application VNC

Yes

Yes

5.1 (XP)

TightVNC

Optional

Protocol version 3.5 1.0

Experimental IPv6 builds were made available in 2004. Defaults to IPv6; can be set to IPv4-only.

[53]

tinc

VPN client

Yes

[54]

Trillian

Instant Messenger Network Speed Test Tool Multimedia player FTP, FTPS and SFTP Client systems management client

No

No 3.05 Unicast, Broadcast, Multicast, Anycast.

[55]

UDP Speed Test 3 VLC

Yes

Yes

[56]

Yes 2.0
[57]

UploadFTP

Yes

VMware vSphere Client

4.0.0 Yes

Performance reports do not support IPv6, but everything else appears to. This was tested using IPv6>IPv4 PT, where the server is on the IPv4 side.

Comparison of IPv6 application support

73

Webmin

Web-based remote administration tool IRC client File transfer software Multimedia player e-mail client

[58]

No

WeeChat Wget

Yes Yes

0.1.3

[59]

[60]

1.9?

May default to IPv4 transfers: use the "-6" option to override.

[61]

Winamp

Yes

5.34

[62]

Windows Live Mail Windows Mail Windows Media Player Windows File and print sharing

Yes Yes Yes

Initial

e-mail client Multimedia player SMB/CIFS client/server

Initial 9.0?
[63]

5.2 (Server 2003) Yes

Windows XP 32-bit does not support IPv6 at the SMB/CIFS layer. The protocol is available for other applications ("ipv6 install" pre-SP1; protocol install afterwards).

[64] [65] [66]

WWWOFFLE XChat xinetd

Proxy server IRC client Networking daemon BitTorrent client BitTorrent client VPN Client

Yes Yes Yes Yes Yes

No

2.6d 1.7.0 1.89 Version 2.3.3 or newer recommended to avoid security issues.

[67] [68] [69]

Torrent Transmission Cisco AnyConnect

1.8 1.5 2.0 No official windows version. No split tunneling allowed in IPv6. ASA 8.4 software required for full IPv6 mode.
[70] [71]

Yes

Yes

[1] http:/ / www. celestialsoftware. net/ [2] http:/ / technet. microsoft. com/ en-us/ library/ dd578336(WS. 10). aspx [3] http:/ / www. networkworld. com/ community/ blog/ configuring-microsoft-active-directory-suppor [4] http:/ / technet. microsoft. com/ en-us/ library/ dd379498(WS. 10). aspx [5] http:/ / tldp. org/ HOWTO/ Linux+ IPv6-HOWTO/ hints-daemons-apache2. . html [6] http:/ / www. cerberusftp. com/ products/ features/ index. html [7] http:/ / www. cups. org/ documentation. php/ whatsnew. html [8] https:/ / github. com/ ivan/ ejabberd/ commit/ 99aac0acce17cb43dbcd333194bf3412d1a39943 [9] http:/ / filezilla-project. org/ client_features. php [10] http:/ / filezilla-project. org/ versions. php#3. 1. 0-beta1 [11] http:/ / blogs. iis. net/ nazim/ archive/ 2008/ 05/ 03/ using-ipv6-with-iis7. aspx [12] http:/ / research. microsoft. com/ msripv6/ ReadMe. htm [13] http:/ / msdn. microsoft. com/ downloads/ sdks/ platform/ tpipv6/ faq. asp [14] http:/ / arstechnica. com/ articles/ paedia/ IPv6. ars/ 4 [15] http:/ / svn. irssi. org/ repos/ irssi/ tags/ r_0_7_16/ NEWS [16] http:/ / java. sun. com/ j2se/ 1. 4. 2/ docs/ relnotes/ features. html#networking [17] http:/ / java. sun. com/ j2se/ 1. 5. 0/ docs/ guide/ net/ enhancements-1. 5. 0. html [18] http:/ / java. sun. com/ j2se/ 1. 5. 0/ docs/ guide/ net/ ipv6_guide/ [19] http:/ / www. kde. org/ announcements/ changelogs/ changelog2_1to2_2. php [20] http:/ / linux-cifs. samba. org/ [21] http:/ / www. microsoft. com/ technet/ network/ deploy/ confeat/ domain. mspx [22] http:/ / msdn. microsoft. com/ en-us/ library/ ms345359(SQL. 90). aspx

Comparison of IPv6 application support

[23] [24] [25] [26] [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39] [40] [41] [42] [43] [44] http:/ / blogs. msdn. com/ b/ sql_protocols/ archive/ 2005/ 10/ 12/ 480192. aspx http:/ / www. mozilla. org/ releases/ mozilla1. 7/ README. html http:/ / kb. mozillazine. org/ Network. dns. disableIPv6 http:/ / slashdot. org/ comments. pl?sid=231405& threshold=0& commentsort=0& mode=thread& pid=18799313#18804565 http:/ / kovyrin. net/ 2010/ 01/ 16/ enabling-ipv6-support-in-nginx/ http:/ / nginx. org/ en/ CHANGES http:/ / insecure. org/ nmap/ changelog. html http:/ / products. nortel. com/ go/ product_content. jsp?segId=0& parId=0& prod_id=34820& locale=en-US http:/ / www. openldap. org/ devel/ cvsweb. cgi/ ~checkout~/ Attic/ CHANGES?rev=1. 5. 2. 9 http:/ / openvpn. net/ faq. html http:/ / www. ipv6tf. org/ index. php?page=news/ newsroom& id=77 http:/ / www. opera. com/ docs/ changelogs/ windows/ 720b/ index. dml http:/ / www. opera. com/ docs/ changelogs/ linux/ 720b7/ index. dml http:/ / www. opera. com/ docs/ changelogs/ mac/ 900/ index. dml http:/ / metalink. oracle. com/ metalink/ plsql/ showdoc?db=Not& id=783570. 1 http:/ / www. ipv6style. jp/ en/ 20070115/ vista_lifehack1. html http:/ / developer. pidgin. im/ ticket/ 1075 http:/ / www. privoxy. org/ announce. txt http:/ / www. privoxy. org/ 3. 0. 13/ user-manual/ whatsnew. html http:/ / www. chiark. greenend. org. uk/ ~sgtatham/ putty/ changes. html http:/ / www. quagga. net/ docs/ docs-multi/ IPv6-Support. html#IPv6-Support http:/ / www. quagga. net/ docs/ docs-multi/ OSPF6-area. html#OSPF6-area

74

[45] http:/ / samba. org/ ftp/ rsync/ old-versions/ rsync-2. 5. 0. NEWS [46] http:/ / samba. org/ ftp/ rsync/ old-versions/ rsync-2. 5. 6-NEWS [47] http:/ / wiki. mydc. ru/ %D0%98%D1%81%D1%82%D0%BE%D1%80%D0%B8%D1%8F_%D0%B8%D0%B7%D0%BC%D0%B5%D0%BD%D0%B5%D0%BD%D0%B8%D0%B9 3. 3. 2C_lua_plugin_v_2. 3 [48] http:/ / samba. org/ samba/ history/ samba-3. 2. 0. html [49] http:/ / www. simpledns. com/ kb. aspx?kbid=1222 [50] http:/ / forum. skype. com/ index. php?showtopic=632023 [51] http:/ / squidproxy. wordpress. com/ [52] http:/ / devel. squid-cache. org/ squid3-ipv6/ [53] http:/ / jungla. dit. upm. es/ ~acosta/ paginas/ vncIPv6. html [54] http:/ / www. tinc-vpn. org/ faq [55] http:/ / bugs. ceruleanstudios. com/ show_bug. cgi?id=11530 [56] http:/ / www. myjavaserver. com/ ~skybuck/ [57] http:/ / www. upload-ftp. com/ features [58] http:/ / readlist. com/ lists/ lists. sourceforge. net/ webadmin-list/ 2/ 12337. html [59] "0.1.3 Changelog" (http:/ / www. weechat. org/ files/ changelog/ ChangeLog-0. 1. 3. html). . Retrieved March 03, 2011. [60] http:/ / www. weechat. org/ features/ [61] http:/ / svn. dotsrc. org/ repo/ wget/ trunk/ src/ ChangeLog [62] http:/ / betas. intercom. net/ index. php?name=News& file=article& sid=1550 [63] http:/ / www. uk6x. com/ applicationservices/ mp3radio. html [64] http:/ / www. microsoft. com/ technet/ network/ ipv6/ ipv6faq. mspx [65] http:/ / www. microsoft. com/ technet/ abouttn/ flash/ promo/ lettertoeditor/ lte041205. mspx [66] http:/ / www. ipv6tf. org/ index. php?page=meet/ faqs& faq_id=2600& q=27 [67] http:/ / www. gedanken. demon. co. uk/ wwwoffle/ version-2. 9/ FAQ. html [68] http:/ / www. xchat. org/ changelog. txt [69] http:/ / tldp. org/ HOWTO/ Linux+ IPv6-HOWTO/ hints-daemons-xinetd. html [70] http:/ / www. cisco. com/ en/ US/ docs/ security/ vpn_client/ anyconnect/ anyconnect25/ administration/ guide/ anyconnectadmin25. html [71] http:/ / www. cisco. com/ en/ US/ docs/ security/ asa/ asa84/ configuration/ guide/ vpn_anyconnect. html#wp1108722

Comparison of IPv6 application support

75

External links
Vendor-Application database (http://www.ipv6-to-standard.org/) "Current Status of IPv6 Support for Networking Applications" (http://www.deepspace6.net/docs/ ipv6_status_page_apps.html): last updated in 7-2007. IPv6 Application and Patch Database (http://6net.iif.hu/ipv6_apps) "IPv6 Enabled Applications" (http://www.ipv6.org/v6-apps.html): last updated in 3-2003. "Hints for IPv6-enabled daemons" (http://tldp.org/HOWTO/Linux+IPv6-HOWTO/chapter-hints-daemons. html): chapter 21 of TLDP's Linux IPv6 HOWTO. Implementing AF-independent application (http://www.kame.net/newsletter/19980604/) by Jun-ichiro itojun Hagino. Porting Applications to IPv6 (http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html) by Eva M. Castro. RFC 4007 - IPv6 Scoped Address Architecture (http://tools.ietf.org/html/rfc4007#section-11), details the textual representation of zone indices.

Comparison of IPv6 support by major transit providers

Internet Protocol Version 6 (IPv6) is not yet universally available as of 2011, but support by major ISPs and transit providers is steadily increasing. Many major transit providers offer an IPv6 service to their customers, but do not have a ubiquitous view of all other IPv6 networks. Other aspects of this service vary widely from one major ISP to the next.
Network ASN Routes [1] Carried 7,613 7018 [7] 174 7922 3549 6939 10913 11537 4739 3356 8218 4436 2914 209 [8] 3561 1239 [9] 6175 [6] Customer [2] Routes Maximum Prefix Length /48 Partitioned [3] From Updated [4]

route-views6 AT&T

[5]

2011-12-31 2011-12-31 AS6939 AS15169 2011-08-09

7,523 5,224 4,648 7,299 7,429 6,807 7,546 7,592 7,307 7,269 7,426 7,424 7,495 4,210 3,936 3,766 1,931 117 150 1,556 218 10 195 /48 /48 /48 /48 /48 /48 /48 /48 671 17 2,267 4,121 /48 /48

Cogent Communications Comcast Global Crossing Hurricane Electric Internap Internet 2 Internode

2011-03-11 2011-12-31 AS174 2012-01-04 2011-08-10 2011-12-31 2011-12-31 2012-01-04 2011-10-31 2011-12-31 2012-01-04 2011-12-31 2010-12-21 2011-01-26 2010-12-22

Level 3 Communications Neotelecoms nLayer Communications NTT Communications Qwest Savvis Sprint Sprint

Comparison of IPv6 support by major transit providers

76
480 274 1,759 /48 /48 2011-04-21 2012-01-04 2012-01-04

Tata Communications Telecom Italia Sparkle TeliaSonera International Carrier Tinet UPC Verizon Business XO Communications [1] [2] [3] [4] [5] [6] [7] [8]

6453 6762 1299

5,033 7,336 7,329

3257 6830 701 2828

7,457 3,875 7,458 3,779

1,652

/48 /48

2012-01-04 2011-09-01 2011-12-05 2010-12-23

253 93

/48 /48

Number of routes advertised to customers Number of routes advertised over non-customer BGP peering sessions Some networks do not have global reach-ability to some other major networks. This data changes frequently as IPv6 adoption progresses. Number of unique IPv6 routes (/48 or shorter) visible on route-views6.routeviews.org MRT, for comparison to transit networks http:/ / archive. routeviews. org/ route-views6/ bgpdata/ 2011. 12/ RIBS/ rib. 20111231. 2200. bz2 As of 2010-JUL-24, in certain regions Cogent charges a $50 per month fee to configure IPv6 for their customers. Savvis has advised their customers that their backbone is IPv6 capable since 2009. However, they do not have an offering for transit service to customers and to look for offerings in 2012. In addition, Savvis managed hosting and cloud services do not support IPv6, with NO roadmap or release plans announced. (February 2011) [9] Sprint has ceased implementing new tunnels on their test network and will begin removing them on January 31, 2011 in favor of dual-stack on AS1239.

References References

Comparison of IPv6 support in operating systems

77

Comparison of IPv6 support in operating systems

This is a comparison of operating systems in regards to their support of the IPv6 protocol.
OS Version Claimed IPv6-ready Installed by Default Yes Yes Yes Yes
[2]

DHCPv6

ND RDNSS

Notes

AIX Android Cisco IOS Fedora FreeBSD HP-UX IBM i iOS

4.3 2.3.4 15.0 13 9.0 11i 7.1 4.1

Yes Partial
[1]

Yes No Yes Yes

[2] [4]

No No Yes Yes Yes

[2] [5] [6] [7]

Yes Yes Yes

[3]

Yes Yes Yes Yes

Addon Yes Yes Yes

Yes Yes Yes

Yes No Yes
[8]

iOS supports stateless DHCPv6 since version 4 and stateful DHCPv6 since 4.3.1. DNS name resolution in versions of Mac OS X 10.6 (Snow Leopard) before 10.6.8 fails for hosts with a CNAME [9][10][11][12] record. (Many publicly-accessible hosts have CNAME records.) No public APIs work to get the IPv6 host address. DHCPv6 and ND RDNSS (RFC 6106) not [13] available before Lion

Mac OS X

10.7 (Lion)
[4]

Yes

Yes

Yes

Yes

MeeGo OpenBSD OpenVMS Red Hat Enterprise Linux Solaris SUSE Linux Enterprise Server Symbian Ubuntu

1.2 4.8 8.3 6

No

[14]

Yes

[15]

No

Yes

[16]

Yes Yes
[17]

Yes Yes No
[4]

No

Yes 10 11 Yes 7.0 10.10 (Maverick Meerkat) 2.1.0 5.1 (XP)

Yes

Yes

Yes

Yes
[18]

Yes

Yes

No

Yes

Yes

Yes

Yes

Yes

No

No

[19]

Yes

Yes

Yes

Yes

webOS Windows NT

No Yes

No No

No
[4]

No No

[20]

Addon

Windows XP users can use Dibbler, an open source [21] DHCPv6 implementation rdnssd-win32 provides an open source implementation of [23] ND RDNSS rdnssd-win32 provides an open source implementation of [23] ND RDNSS

6.0 (Vista) Yes 6.1 (7) Yes

[22]

Yes

Yes

[4]

Addon

[22]

Yes

Yes

[4]

Addon

Comparison of IPv6 support in operating systems

78
If the OEM explicitly unsets the SYSGEN_TCPIP6 pre-processor symbol, the built image will not have any IPv6 capabilities. 7.5 will have some support.
[25]

Windows Phone

6.5 (Mobile)

Yes

Yes

Lite

[24]

No

7.0 z/OS z/VM z/VSE V1R4.0 V5R1.0 V4R2

No Yes Yes Addon

[28]

No Yes Yes No

No No
[26]

No

No

No

[27]

Via a third party TCP/IP stack, IP6/VSE from Barnard Software, Inc.

Notes
Operating systems that do not support either DHCPv6 or ND RDNSS cannot automatically configure name servers in an IPv6-only environment.

External links
ISOC IPv6 FAQ [29] with OS tips

References
[1] Issue 3389: Full IPv6 Android support (http:/ / code. google. com/ p/ android/ issues/ detail?id=3389) [2] "Fedora 9 Installation Guide Chapter 9. Network Configuration" (http:/ / docs. fedoraproject. org/ en-US/ Fedora/ 9/ html/ Installation_Guide/ ch-networkconfig. html#sn-network-manual-ipv6). Fedora Project. . Retrieved 2011-02-04. [3] FreeBSD Handbook (http:/ / www. freebsd. org/ doc/ handbook/ network-ipv6. html). [4] IPv6 Operating Systems (http:/ / ipv6int. net/ systems/ index. html). [5] FreeBSD 9.0-RELEASE Release Notes (http:/ / www. freebsd. org/ releases/ 9. 0R/ relnotes. html). [6] "HP-UX 11i IPv6" (https:/ / h20392. www2. hp. com/ portal/ swdepot/ displayProductInfo. do?productNumber=T1306AA). . [7] "IBM i 7.1 Information Center, Configuring IPv6" (http:/ / publib. boulder. ibm. com/ infocenter/ iseries/ v7r1m0/ index. jsp?topic=/ rzai2/ rzai2configipv6. htm). . [8] iPhone IPv6 Debugging Simplified with Ip6config The IPv6 Experts.net (http:/ / www. theipv6experts. net/ 2011/ iphone-ipv6-debugging-simplified-ip6config/ ) [9] http:/ / lists. apple. com/ archives/ ipv6-dev/ 2010/ Feb/ msg00003. html [10] There is no Plan B: why the IPv4-to-IPv6 transition will be ugly (http:/ / arstechnica. com/ business/ news/ 2010/ 09/ there-is-no-plan-b-why-the-ipv4-to-ipv6-transition-will-be-ugly. ars) [11] Apple fixes broken IPv6 by breaking it some more (http:/ / arstechnica. com/ apple/ news/ 2010/ 11/ apple-fixes-broken-ipv6-by-breaking-it-some-more. ars) [12] http:/ / lists. apple. com/ archives/ ipv6-dev/ 2011/ Jun/ msg00038. html [13] http:/ / seclists. org/ nanog/ 2011/ Jul/ 417 [14] "Bug 10984 - IPv6 Support declaration" (http:/ / bugs. meego. com/ show_bug. cgi?id=10984). . [15] "Bug 10049 - No IPv6 in handset UX" (http:/ / bugs. meego. com/ show_bug. cgi?id=10049). . [16] "rtnl: Receive notification of RDNSS from IPv6 router advertisements" (http:/ / git. kernel. org/ ?p=network/ connman/ connman. git;a=commit;h=75026d7e1c1e95dcbcfaa7d05bc5787da084f4e9). . [17] IPv6 Ready Logo Program Approved List (https:/ / www. ipv6ready. org/ db/ index. php/ public/ logo/ 02-C-000527/ ). [18] Release Notes for SUSE Linux Enterprise Server 11 (http:/ / www. novell. com/ linux/ releasenotes/ x86_64/ SUSE-SLES/ 11/ #IPv6). [19] http:/ / sw. nokia. com/ id/ f9363497-5d96-4354-b071-e212ab204c63/ Nokia_Views_on_IPv6_Transition_v2_0_en. pdf [20] "Palm Pre Plus - IPv6 support" (http:/ / developer. palm. com/ distribution/ viewtopic. php?f=91& t=10028). . [21] DHCPv6: Dibbler - a portable DHCPv6 (http:/ / klub. com. pl/ dhcpv6/ ) [22] IPv6 Ready Logo Program Approved List (https:/ / www. ipv6ready. org/ db/ index. php/ public/ search/ ). [23] (http:/ / sourceforge. net/ projects/ rdnssd-win32/ ) [24] "DHCPv6 Lite Registry Settings" (http:/ / msdn. microsoft. com/ en-us/ library/ aa925828. aspx). . [25] "Update: Mango does support IPv6" (http:/ / www. wpcentral. com/ update-mango-evidently-does-support-ipv6). . [26] "z/OS V1R12.0 Communications Server IPv6 Network and Application Design Guide" (http:/ / publib. boulder. ibm. com/ infocenter/ zos/ v1r12/ topic/ com. ibm. zos. r12. hale001/ ipv6d001999564. htm). . [27] "z/VM IPv6 Support" (http:/ / www. vm. ibm. com/ networking/ ipv6/ ). .

Comparison of IPv6 support in operating systems

[28] "About z/VSE" (http:/ / www-03. ibm. com/ systems/ z/ os/ zvse/ about/ ). . [29] http:/ / wiki. chapters. isoc. org/ tiki-index. php?page=IPv6+ FAQ

79

Article Sources and Contributors

80

Article Sources and Contributors

IPv6 Source: http://en.wikipedia.org/w/index.php?oldid=475556163 Contributors: 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 - hack, 128.107.253.xxx, 2001:db8, 2345us, 49oxen, A3 nm, AJR, Abune, Accountholder, AceJohnny, Adam Conover, Adamthewebman, Adoniscik, Aeluwas, Aeons, Agent00111, Ahoerstemeier, Aigarius, Ajbool, Akamad, Alainkaa, Alansohn, Aldie, AlephGamma, Alex43223, Alexander UA, Alexkon, Alexwcovington, AlistairMcMillan, Allanlw, Amigan, Amybajwa, AnandKumria, Anastrophe, Andareed, Anders Feder, Andonic, Andrei Stroe, Andrew4u, AndyTheGrump, Annesville, AnonMoos, Antonis Christofides, Arbitrary username, Arichnad, ArnoldReinhold, Artemgy, Arthur Rubin, Aschwegmann, Ashley Y, Astronautics, Atakdoug, Auntof6, Avanu, Axelriv, Baa, Badcalculon, Badon, Balachanderk, Barri, Bazsa, Bbpen, Bdesham, Belamp, Beland, Benabik, Benandorsqueaks, Benbest, Bender235, Bentendo24, Beoba, Bertra g, Bgraabek, Big Brother 1984, BioTube, Blaynew, Blubber42, Bobblewik, Bobo192, Boothy m, Borgx, Bornapilot, Bousquf, Bovineone, Brianmaddox, BrokenSegue, Brownsteve, Bruce404, Bsv109, Bugfood, BurnDownBabylon, CKD, CKerr1, CableCat, Calvin 1998, Cameltrader, Cananian, Canterel, Cap'n Refsmmat, Capek, Caper13, CapitalR, Captkirk, Carlosguitar, Centrx, CesarB, Cesarolvera, Cgdallen, ChaosR, Charliel 94, Charu, Charwinger21, Chaser, Chbarts, Chris 73, ChrisErbach, Chrisinspfld, Cinnamondouche, ClamDip, Closedmouth, Cmdrjameson, Cmsb705, Coaxial, Cobi, Cometstyles, ComputinChuck, Confuciou, Conversion script, Corso84, Crazycomputers, Crd Alameda, Credema, Crispmuncher, Crwth, Cst17, Cwolfsheep, Cyan, Cybercobra, Cybjit, Cyp, DARTH SIDIOUS 2, DBooth, DMahalko, DNSstuff, Daev, DalZot, Dale Arnett, Dan100, Dandorid, Daniel Luechtefeld, Daniel.Cardenas, DanielDeGraaf, Darguz Parsilvan, Das7002, DataMatrix, Dave6, David Gerard, Davidhorman, Dawnseeker2000, Deepeedoyle, Defyant, DerekMorr, Dglynch, Diannaa, Dickguertin, Dicklyon, Dispenser, Djschaap, Dlabtot, Dlange13, Dnas, Dnevil, DocKrin, Dolda2000, Don4of4, Donreed, Dontopenyoureyes, Drangon, Drearwig, Drewheasman, Droob, Dwmalone, Dylan Lake, Dylan620, E94mli, EDUBLE, EdBever, EdC, EdoDodo, Edokter, Edward, Ehn, El C, Eldar, Emonk72, Endpoint, Enjoi4586, Enquire, Eradt11, Erc, EthanL, EugeneZelenko, Euphrosyne, Evil Monkey, Extropian314, FGont, FT2, Falcon8765, Falcon9x5, Farncombe, FatalError, Feedmecereal, Feureau, Fewaffles, Figz, Firealwaysworks, FlieGerFaUstMe262, Fluffy 543, Fnagaton, Folajimi, Foobar, Fragglet, Frap, Fredrik, Freeaqingme, Fresheneesz, Frnkblk, Fsterry, Galmicmi, Geekening, GerardM, Ghane, Giftlite, Giraffedata, Glane23, Glen Hein, Glenn burdett, Glenndavies, Glrx, Gmaxwell, Gmedding, Gorffy, GovStuff, Graciella, Graham87, GrahamHardy, GreenReaper, Greg L, Gudeldar, Guiltyspark, Gunnala, Gurch, Gwernol, HAl, Haakon, Hairy Dude, Haleyga, Ham Pastrami, Hankwang, Hannes.nz, HarryHenryGebel, Hashar, Hatu7, Hawaiian717, Hcberkowitz, Hdt83, Helix84, Hfastedge, Hires an editor, HobbesLeviathan, Holizz, Holmwood, HorsePunchKid, Hpa, Husky, Hvn0413, Hypersonic, II MusLiM HyBRiD II, IRedRat, Ihope127, Ilja Lorek, Iluvcapra, Imarsman, Imroy, Imzogelmo, Incnis Mrsi, Incompetence, Infofarmer, Insanity Incarnate, Int21h, InterMa, Intgr, Intrepion, Iromeister, Ironholds, Itojun, Ivolocy, J-D-Cronin, J128, JHunterJ, JTN, Jaizovic, Jamesday, JameySharp, Jan1nad, Jansenguus, Janto, Jarry1250, Jasper Deng, Jclemens, Jddahl, Jec, Jeff G., Jeff02, JeffMorriss, Jeffsw6, Jengelh, Jeremy Visser, JeroenMassar, Jfromcanada, Jhd, Jhwoodyatt, Jithrae, Jj137, Jnc, Jo3sampl, JodyB, JoeKearney, John Maynard Friedman, JohnOwens, Johnsmith4092, Johnuniq, JonDePlume, Jonkerz, Jordandanford, Jordipalet, Joshua Scott, Jtg, Julesd, Justjohn45, K0rana, KDS4444, Kaldari, Karada, Kasperd, Kattmamma, Kaypoh, Kb966k, Kbolino, Kbrose, Kcordina, Keilana, KelleyCook, Kenyon, Kestasjk, Kgfleischmann, Kieff, Kinema, Klaver, Koavf, Konikofi, Kozuch, KrakatoaKatie, Krellis, Kroneage, Kthomas8, Kusma, Kvaks, Kvng, Kynan, LUUSAP, LVXN112, Lagesag, LakeHMM, Latifladid, Laug, Lawrence Cohen, Lightbulbcole, Likestheaction, Logan, Lord Chamberlain, the Renowned, Lotje, Lousyd, Luigiacruz, M. B., Jr., M.O.X, M00dawg, Maalaoui, Macrakis, Madhav208, Madman91, Maduskis, Mahtin, Maian, Majordragon, Manankanchu, Mange01, Mansoor.riz, Marcod'Itri, Marius p, Mark Bergsma, MarkMLl, Markus Kuhn, MarkusWanner, Martarius, Martyvis, Marudubshinki, Matchups, Mathboy965, MaxWilder, Maxim Masiutin, Mdd4696, Meand, Megan at ARIN, Melongrower, Meneth, Mentifisto, Mhd.ashraf, Michael B. Trausch, Michael miceli, Michael.davie, MichaelBillington, Michaelrayw2, Midnightcomm, MihalOrela, Mike Rosoft, Mike Schwartz, MikeWren, Mikm, Mindmatrix, Minghong, Mintleaf, Mitar, MithrasPriest, Mmxx, Mobus, Molerat, Money23, Mordomo, Mormonsareloser, Mr Minchin, MrOllie, Mro, Msiebuhr, Muad, Mukkakukaku, Mulad, MureninC, N328KF, NYMets2000, Nacnud22032, Naff89, Nageh, NameIsRon, Napalm Llama, NapoliRoma, Narellec, Nasa-verve, Nashrul Hakiem, Nate Silva, Naveenpf, Nealmcb, NerdBoy1392, Netrangerrr, Nhandler, Nicd, Ninjagecko, Nixdorf, Nixeagle, No More TV, Noldoaran, Northgrove, Notbyworks, Nsaa, Nubiatech, Nurg, Nwbeeson, Nzseries1, OSborn, Od Mishehu, Ohnoitsjamie, Olipro, OlivierMehani, Oliwan, Omegatron, Omegium, Omicronpersei8, Omniplex, Oneliner, Orchistro, OriumX, Ost316, Ovideon, P.vishnu7, PabloStraub, Paine, Pankkake, Paolopal, Paradox2, Paranoid, Parsmutaf, Pascal666, PassportDude, Pathoschild, Patrickdavidson, Paul1337, PaulHanson, Peak, PedroPVZ, Pekaje, Pengo, Personman, PeterCScott, PeterKz, PeterStJohn, PhilHibbs, Philc 0780, Phoe6, Phoenix-forgotten, PierreAbbat, Pinkgothic, Pjrm, Planetscared, Plasticup, Plau, Pnm, Pointillist, Pontillo, Powerlord, Prabhuhwiki, Prolog, Prunesqualer, Psheld, Psz, Ptmc2112, Public Menace, Puchiko, PuerExMachina, Quaestor23, Quantumobserver, Quebec99, Qwertytech, Qwertyus, RHaworth, Raffen, Raghith, Rait, Ralphcase, Random832, Rchandra, Rcloran, Rd232, Rdenis, RedWolf, Redlazer, Rememberway, ReyBrujo, Reza 2638, Rgaushell, Rich Farmbrough, Richard W.M. Jones, RichiH, Rick Sidwell, RickBeton, Rilesman, Rischmueller, Roadrunner7, Robaire5006, Robert Brockway, Robomaeyhem, Rocketman768, Ronz, Roy.wonder.cohen, RoyBoy, RoySmith, Rps, Rrius, Rwessel, Ryankearney, Rythie, Ryulong, Ryuzaki00, ST47, SWAdair, Sam Hocevar, Samantha of Cardyke, Sandeepsoman, Saran945, Sarutv, SaveTheRbtz, Scientus, Scj2315, Scott.somohano, Scottbadman, Scottywong, Scratchy, Seano1, Sebcastle, Sega381, SelfStudyBuddy, Setherson, Sgeeves, Shadowjams, ShakataGaNai, Shirishag75, Shultz IV, Sibi antony, Sick bug, Sigkill, SillyWilly, Simon J Kissane, Sirmelle, Sjmsteffann, Sjrosen, Skittleys, Skybon, Smallpond, Smarter1, SmilingBoy, Smurfy, Smurrayinchester, Snaxe920, Snorgy, Sobec, Socialservice, SolarWind, Some jerk on the Internet, Sonicsuns, Sosodank, South Bay, Southen, Spearhead, Spicemines, SpuriousQ, Squids and Chips, Stephan Leeds, Stephenb, SteveDavidsen, StuartBrady, Stux, Stwalkerster, Sukenjain, Suruena, Suseno, Svick, SymlynX, Synchrite, Sysy, TJJFV, TJRC, TankMiche, Team4Technologies, Teemu Maki, Teemuk, Template namespace initialisation script, Tenth Plague, Terillius, Terjepetersen, Tfl, ThG, The Anome, The Last Username I Could Think Of, The Nut, TheAnarcat, TheLight, Theant2000, Thehotelambush, Thewallowmaker, Thexchair, Thorpe, Thrindel, Thumperward, ThurnerRupert, Tim Capps, Titoxd, Tjh1234, Tmaufer, Tmh, To Serve Man, Tommy2010, Towel401, Trejrco, Trevor Johns, Tristanb, Trisweb, Trusilver, TwoHundredOk, Tylerl, Ukh, Uncle Milty, UncleDouggie, Unclevinny, Und1sk0, Unitacx, Universalcosmos, Uruiamme, Utility Knife, Vajrallan, Valenciano, Vannessa.beth, Vedantm, Vegaswikian, Verdy p, Veriodbg, Vespristiano, Victor, Viniciustinti, Viperious, Visiting1, Voidxor, Voomoo, WJBscribe, Wahjava, Warren, WarthogDemon, Watain, Wavelength, WayneMokane, Weatherman1126, Weregerbil, Wetman, Weyes, Whatisipv6, Wikimoder, WikipedianYknOK, Wimt, Wisco, Wk muriithi, Wmahan, Wonderstruck, Wrs1864, Ww, Wwoods, X-Fi6, Xandell, Xeltran, Xerces8, Xpclient, Yago, Yama, Yayay, Youssefsan, Yurik, Yurivict, Zachlipton, Zaphraud, Zed5linux, Zeerak88, Zemyla, Zhackwyatt, Zmding, ZorphDark, , 1591 anonymous edits IPv6 address Source: http://en.wikipedia.org/w/index.php?oldid=475005998 Contributors: Alvin-cs, Amore proprio, Avbentem, AviDrissman, AxelBoldt, BobbyPeru, Bryan.burgers, Cybjit, Cyphermox, Cpey, Dandorid, Djflux, EdBever, EoGuy, Fanf, Flopster2, Fredden, GoingBatty, Guenthert, Gunnar Guvararson, HorsePunchKid, Hydrox, IByte, JHunterJ, Jasper Deng, Jec, Jengelh, Kbrose, KenSharp, Kgfleischmann, Klaver, Kvng, L48g, Materialscientist, Mm, Mtorrecilla, Nasa-verve, Nashrul Hakiem, Nealmcb, Netmatician, Nneonneo, Paul Knight, Psheld, R'n'B, Rememberway, Rich Farmbrough, Seanx820, Squids and Chips, Stephan Leeds, The Anome, Theant2000, Thue, Tommy2010, Vanni.T, VernoWhitney, Viniciustinti, Woohookitty, Zundark, 59 anonymous edits IPv6 packet Source: http://en.wikipedia.org/w/index.php?oldid=473183810 Contributors: Closedmouth, Dandorid, Danhash, Eraserhead1, Jec, Kbrose, Kvng, LilHelpa, Mr. Wheely Guy, Mro, Muhandes, Nageh, Nasa-verve, Nick Number, Rischmueller, Rwessel, TheRa'ike, Weylin.piegorsch, Woohookitty, 12 anonymous edits Mobile IP Source: http://en.wikipedia.org/w/index.php?oldid=474054969 Contributors: Adrignola, Aleichem, Alexius08, Alimedany, Altsheikh1, Arkrishna, Audriusa, Bjanders, Bruce1ee, Chrislk02, Danielcohn, Darossetti, Defender of torch, Doprendek, Epbr123, Frap, Fresheneesz, Goarany, Goldom, Infindebula, Isj-wikipedia, J. Spencer, Jeffrey Mall, Jengelh, Johnuniq, JonHarder, Kbrose, Kevinmon, Kinema, Klilidiplomus, Koshoid, Kulin shah, Liangent, Lionking timone, M7amad4, Magioladitis, Mandarax, Mange01, Maryhit, MathsPoetry, Mgarlop, Mgaved, Michael Hardy, Mintleaf, Mlaffs, Mustafaerg, Netrangerrr, Nneuman, Nono64, NortyNort, Oli Filth, Pearle, Plustgarten, Porttikivi, Radiant!, Ranjithsutari, Rchandra, Rdcole, RedWolf, Rkrikorian, Ronhjones, Sandrewh, Schlauf, Sepper, Shadowjams, Shirik, Sietse Snel, Sjlver, Starbois, TelecomNut, TrogdorPolitiks, UninvitedCompany, Vahid talebi, Wequiry4278, Willem, Woohookitty, Wrs1864, Xrgtn, Zil, 140 anonymous edits Neighbor Discovery Protocol Source: http://en.wikipedia.org/w/index.php?oldid=474042860 Contributors: Daronthomas69, Delta041, Dominik78, Enjoi4586, Forton, Ghen, Int21h, Joy, Kbrose, Kinema, Kwi, Leszek Jaczuk, Pdelong, PolarYukon, Ramashray, Rdenis, SensuiShinobu1234, Sjmsteffann, Suruena, Thorano, Tony.cheneau, Wrs1864, Ykanada, , 31 anonymous edits Secure Neighbor Discovery Protocol Source: http://en.wikipedia.org/w/index.php?oldid=470737689 Contributors: ArnoldReinhold, Bryan Derksen, Dcfleck, Feydey, Int21h, John Vandenberg, Kbrose, MER-C, RobertHannah89, Sara1981, Sigzigmoo, Xag, 10 anonymous edits Multicast Router Discovery Source: http://en.wikipedia.org/w/index.php?oldid=427463872 Contributors: Int21h, Kvng, LeoNomis, Malcolma, Muhandes, Rathaus Site Multihoming by IPv6 Intermediation Source: http://en.wikipedia.org/w/index.php?oldid=449143689 Contributors: Alberto garcia, Cwolfsheep, Kbrose, Malcolma, Midgetman843, Minimac, Mro, Nasa-verve, Nikolas Stephan, Phatom87, Pinoakcourt, Rich Farmbrough, Rjwilmsi, Socrates2008, Stefan Bethke, The Anome, 8 anonymous edits IPv6 transition mechanisms Source: http://en.wikipedia.org/w/index.php?oldid=475388977 Contributors: Akerans, Armando, Belamp, Berge, Citrin.ru, Curtbeckmann, Cwolfsheep, Cybjit, Damian Yerrick, Dan Harkless, David dolson, DavidLeeLambert, Digitalsushi, FromOrleans, GS3, Hashar, Hybernator, Ixim dschaefer, Kbrose, Kvng, Mark Martinec, Mitar, Mro, Nasa-verve, PatchesTheCaveman, Pixitha, Rchandra, Rjwilmsi, Sabri76, The Anome, Thumperward, Viniciustinti, Wrs1864, Xing333, 33 anonymous edits 4in6 Source: http://en.wikipedia.org/w/index.php?oldid=443175225 Contributors: Cybjit, E94mli, Hashar, Mxplm, The Anome, 3 anonymous edits 6in4 Source: http://en.wikipedia.org/w/index.php?oldid=455184231 Contributors: Cwolfsheep, Cybjit, Hashar, JeroenMassar, Kbrose, Ronark, The Anome, 7 anonymous edits 6over4 Source: http://en.wikipedia.org/w/index.php?oldid=459006419 Contributors: Alynna Kasmira, Cmdrjameson, Cwolfsheep, DragonflySixtyseven, Grin, Hairy Dude, Hashar, LindsayH, Memodude, Rdenis, Rednectar.chris, RlyehRising, Sango123, Storkk, The Anome, 8 anonymous edits

Article Sources and Contributors

6to4 Source: http://en.wikipedia.org/w/index.php?oldid=473527304 Contributors: BarkerJr, Boulevardier, Bovineone, CambridgeBayWeather, Cbl62, Cros13, Cwolfsheep, Cybjit, Dandorid, Digitalsushi, Egamma, Frap, Fudoreaper, Germste, Gigacephalus, Grin, Hairy Dude, Haseo9999, Hashar, Irchs, JFG, JTN, Jaidev, Jasper Deng, JimGettys, Jlivingood, John of Reading, Keithmoore, LapoLuchini, Laug, Marked, Matthus Wander, Matts Kallioniemi, Mordomo, MrOllie, Mro, Nate Silva, Neo-Vortex, Niqueco, None7, Omniplex, Pheeror, Plugwash, Rchandra, Rdenis, RichiH, Roques, Sebastian Goll, Sietse Snel, Stephan Leeds, TJJFV, The Anome, Thiseye, Titototito, Viniciustinti, Xedaf, 53 anonymous edits Tunnel broker Source: http://en.wikipedia.org/w/index.php?oldid=470911615 Contributors: Bobet, Braaropolis, Brownout, Cnepveu, Cwolfsheep, Dan Harkless, E94mli, Epolk, ErikWarmelink, Frap, Gilliam, Gracefool, Hoof Hearted, Jasper Deng, Jec, JeroenMassar, John of Reading, JonHarder, Mandai, Megapixie, Mindmatrix, Phatom87, Prunk, Rchandra, Ronark, SpellChecker, Stephan Leeds, Storkk, Tagishsimon, Tedp, The Anome, Welsh, Wonderstruck, Xtifr, Yar Kramer, 68 anonymous edits Teredo tunneling Source: http://en.wikipedia.org/w/index.php?oldid=469794982 Contributors: AlistairMcMillan, Alvestrand, Amalthea, AnandKumria, Appraiser, Blade0078, Bovineone, Chris the speller, Colanderman, Cwolfsheep, Cybjit, Deville, DocendoDiscimus, Epbr123, Extraordinary, Flameeyes, Gennaro Prota, Hairy Dude, Hashar, Incnis Mrsi, JHunterJ, JTN, Jasper Deng, Jec, Josh Parris, Julesd, Juliano, Karstbj, Kubieziel, Laug, Lexein, Lord.Quackstar, Lotu, Magioladitis, Mahtin, Mapet, Marcod'Itri, Memodude, Moocha, Nicholsr, Paul A, Pauladin, Peter Karlsen, Pmsyyz, Porttikivi, Psiphiorg, Psz, Rdenis, Rememberway, Reubenhwk, Rmosler2100, Rurik, Sander123, Sanxiyn, Sietse Snel, SpenceCommand, Stephan Leeds, The Anome, Thumperward, Truthanado, Viniciustinti, Vjardin, Whfsdude, Wingman4l7, Wrs1864, Xompanthy, Xtifr, 109 anonymous edits Miredo Source: http://en.wikipedia.org/w/index.php?oldid=474795284 Contributors: Alvin-cs, Cdinesh, Cronholm144, Cybjit, Frap, Free Software Knight, GreyTeardrop, Hervegirod, Iain Cheyne, Laug, Psz, RDailey79, Thumperward, 9 anonymous edits NAT64 Source: http://en.wikipedia.org/w/index.php?oldid=463657888 Contributors: Belamp, Cybjit, Mark Martinec, PatchesTheCaveman, Viniciustinti, 1 anonymous edits ISATAP Source: http://en.wikipedia.org/w/index.php?oldid=462543237 Contributors: CecilWard, Cwolfsheep, Cybjit, DavidBailey, Edcolins, Frap, Gschmidt, Hashar, IceCreamAntisocial, Jec, Kasperd, Kusma, Orlady, Rdenis, Storkk, TuxyQ, 28 anonymous edits SATSIX Source: http://en.wikipedia.org/w/index.php?oldid=454700415 Contributors: .anaconda, Centrx, Nick Number, PigFlu Oink, Rilesman, Shalom Yechiel, 5 anonymous edits China Next Generation Internet Source: http://en.wikipedia.org/w/index.php?oldid=474180931 Contributors: 16@r, Andrei Stroe, Arthur Rubin, Benjwong, Blueyoshi321, CMBJ, Cayenneman, Confuzion, Cwolfsheep, Feureau, Fragglet, Harryzilber, Hat600, Joseph Solis in Australia, Kbrose, Kdar, Lightmouse, Lithium Edit, Loop 9, Maheshkumaryadav, Naniwako, Noisomep, Peyre, RoySmith, Severo, Solidusspriggan, Techfast50, Universalcosmos, VernoWhitney, WereSpielChequers, Zhongxin, 14 anonymous edits DoD IPv6 Product Certification Source: http://en.wikipedia.org/w/index.php?oldid=452485241 Contributors: Addshore, Christian75, CosineKitty, Franktroy, Joulesm, Nacnud22032, Nasa-verve, Pmsyyz, Ysangkok, 3 anonymous edits Comparison of IPv6 support in routers Source: http://en.wikipedia.org/w/index.php?oldid=473081052 Contributors: AlastairIrvine, Binaryblade, ChrisHodgesUK, Cwolfsheep, Cybjit, DGG, Derdikke, Glrx, Gwalker nz, HealthEmail, Jevansen, LVXN112, Leadinggeek, MutantMonkey, Narthollis, Paul foord, Rancher 42, Sinnabor, Tschfer, Vantronix, Woohookitty, ZeDestructor, 17 anonymous edits Comparison of IPv6 application support Source: http://en.wikipedia.org/w/index.php?oldid=445556742 Contributors: Aethedor, Akabdog, Bluezy, Cwolfsheep, DeathByNukes, DerekMorr, Dupuy, Flint McRae, Gudeldar, Harryboyles, Icebraining, JLaTondre, JanMikk, Jec, JeroenMassar, JohnCKirk, Jrouquie, Kbrose, Kjak, MaxMedvedev, Mdavids, Nasa-verve, Pmsyyz, ProbitSoftware, Remember the dot, Robina Fox, Rsocol, Serin13, SkyWalker, Skybuck, Southen, Wiki Fox, Wilsonics, Woohookitty, Wrs1864, Yk4ever, 59 anonymous edits Comparison of IPv6 support by major transit providers Source: http://en.wikipedia.org/w/index.php?oldid=472606675 Contributors: Centauricom, Chzz, Clicklog, Cybjit, Eastlaw, Feezo, Frank be, Frnkblk, Gawul00, Gbrozny, Gigacephalus, Glendale2x, Hvn0413, Jeffsw6, JimVC3, Killiondude, Mahtin, Mtorrecilla, Pheur, Pymaunier, Speculatrix, Tjb95843, Txuspe, UUknight, ZippyCycle, 64 anonymous edits Comparison of IPv6 support in operating systems Source: http://en.wikipedia.org/w/index.php?oldid=472637252 Contributors: BobJones, Bunnyhop11, Cybjit, Dsant, Eastlaw, Eeekster, Ehn, Guy Harris, Ketas, Krusty99, Lanzyg, Olipro, Paulmcdonald, PeterKz, Remaker, Rwessel, Thewikipedian, Xpclient, 64 anonymous edits

81

Image Sources, Licenses and Contributors

82

Image Sources, Licenses and Contributors

file:Ipv6 address leading zeros.svg Source: http://en.wikipedia.org/w/index.php?title=File:Ipv6_address_leading_zeros.svg License: Public Domain Contributors: Ipv6_address.svg: Indeterminate derivative work: BobbyPeru (talk) File:Ipv6 header.svg Source: http://en.wikipedia.org/w/index.php?title=File:Ipv6_header.svg License: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contributors: Mro Image:Ipv6 address leading zeros.svg Source: http://en.wikipedia.org/w/index.php?title=File:Ipv6_address_leading_zeros.svg License: Public Domain Contributors: Ipv6_address.svg: Indeterminate derivative work: BobbyPeru (talk) Image:NAT64.svg Source: http://en.wikipedia.org/w/index.php?title=File:NAT64.svg License: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contributors: Mro Image:DSLite.svg Source: http://en.wikipedia.org/w/index.php?title=File:DSLite.svg License: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contributors: Mro File:6to4.svg Source: http://en.wikipedia.org/w/index.php?title=File:6to4.svg License: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contributors: Mro File:6to4 convert address.svg Source: http://en.wikipedia.org/w/index.php?title=File:6to4_convert_address.svg License: Creative Commons Attribution-Sharealike 3.0,2.5,2.0,1.0 Contributors: 6to4_convert_address.png: none7 derivative work: Cybjit (talk)

License

83

License
Creative Commons Attribution-Share Alike 3.0 Unported //creativecommons.org/licenses/by-sa/3.0/