Internet Protocol version 6

Internet Protocol version 6 (or as it is more commonly known "IPv6") is a method of addressing hosts or nodes on a computer network, using 128 bit addresses. IPv6 was conceived as a "next generation" upgrade from the older Internet addressing scheme IPv4, which relied on a 32-bit address space and is quickly being exhausted by the continued growth of the Internet. The public address space of the Internet is becoming exhausted.

This article deals with how IPv6 works in a pure IPv6 environment, and perhaps also assumng ideal IPv6 implementations. See Internet Protocol version 6 deployment for scenarios where there are IPv4 coexistence and transition issues. At this time, this article does consider IPv6-specific operational issues, such as IPv6 multihoming are in this article, but might well split out to an "Internet Protocol version 6 operations" article that deal with operational issues not related to IPv4 interactions.

Returning to IPv6, it is worth a note or two on the design intent(s) of IPv6, aspects that are recurring ideas that will be seen throughout the underlying protocol operation, and aren't bad things to keep in mind when trying to understand what IPv6 does, how it accomplished those things and why those things are done.

1. More addresses - obviously IPv6 gives us more addresses, 128bits vs 32bits.
2. Flexibility - The ability to readily add "stuff" (capabilities, functions, etc.) to the protocol without needing to rewrite the base protocol or necessarily re-architect our environments.
3. Scalability - Reduce overhead, distribute workload, smoother/easier processing.

One common topic of conversation is whether IPv6 be viewed as an evolutionary next-stop from IPv4, or is IPv6 a disruptive technology, a revolutionary change?

The answer is: It Depends.

In many regards IPv6 is, in fact, just a few tweaks different. This is the "96 More Bits, No Magic" view. From a purely technological perspective, this is (largely) true.

However, moving forward, the more bits may just enable radical changes. Changes in how we use our networks, what we expect (require) them to do, etc. From this "bigger picture" view we could be on the precipice of major change. (I did say "could" ... ) As the old saying goes, "May you live in interesting times".

See also: Internet Protocol version 6 address management

See also: Internet Protocol version 6 deployment

See also: Internet Protocol version 6 laboratory

Goals of IPv6

Internet Protocol version 6 was created in response to a variety of needs. Officially, some basic ones include:

• Greater address space
• More effective space, to avoid some of the workarounds, especially with respect to routing and the generic problem of
• Efficient hardware processing of packet headers: Some IPv4 header fields have been dropped or made optional (e.g., fragmentation), to reduce the processing cost for the most common packets, and to reduce the bandwidth cost of the IPv6 header.
• Improved Support for Extensions and Options: The encoding of headers is more efficient for hardware processing and more flexible in adding new options
• Flow Labeling Capability: the ability to label a packet as belonging to a flow or forwarding equivalent class, such as non-default quality of service or "real-time" service.
• Authentication and Privacy Capabilities: built in authentication, data integrity, and optional content confidentiality are part of the base standard. Discussed further in Internet Protocol version 6 security, this is an area of much confusion. IPv6 is not, without specific enabling and administration of features, especially more secure than IPv4. IPv6, however, brings security features into the basic packet structure, so they can be handled in "mainline" processing rather than as an "add-on" as in IPv4. Both protocols use the Internet Protocol security architecture (IPSec), whose structure and mechanisms must be understood before invoking them in IPv6.

IPv6 packet format

IPv6 is not only a matter of addressing. The packet is structured quite differently than an IPv4 packet; only the first four bits, designating the IP version number, have the same form/function/location.

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |Version| Traffic Class |           Flow Label                  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Payload Length        |  Next Header  |   Hop Limit   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                         Source Address                        +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  +                                                               +
  |                                                               |
  +                      Destination Address                      +
  |                                                               |
  +                                                               +
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

There are fewer fields than in the IPv4 header. Some of the fields that are not part of the header either were not often used, were obsolete, or inefficiently implemented.

Hop Limit is essentially the Time To Live field of IPv4.

Traffic Class is effectively the same as the Type of Service field in IPv4, and Flow Label is a new possible capability, more on that later.

Headers and options

Think about the function of the protocol ID field in a IPv4 packet, or, for that matter, the Ethertype in an Ethernet frame or the SNAP field in IEEE 802.2 LLC headers. Other than for filtering and statistics, a router may not care about this information; it's primarily of interest to end hosts. Think of the function logically, in an IP packet carrying TCP (protocol ID 6), and having no IPv4 options. The effect of that protocol ID is

  +---------------+------------------------
  |  IPv4 header  | TCP header + data
  |               |
  | Protocol =    |
  |      TCP      |
  +---------------+------------------------

The Next Header field serves the function of the protocol identifier field and even uses some of the same values, in RFC1700 and later online IANA lists. In addition, however, this field more efficiently implements the Options mechanism from IPv4. While all IPv4 options are in type-length-value format and encoded into the base header itself, all IPv6 options are not in the base header. Additionally, they are "64 bit aligned" (i.e. - multiple of 8 bytes) - and still making use of TLV encoding.

The next example shows an IPv6 packet, with a next-header field of the protocol identifier for TCP.

  +---------------+------------------------
  |  IPv6 header  | TCP header + data
  |               |
  | Next Header = |
  |      TCP      |
  +---------------+------------------------

By design, most extension headers can be ignored by intermediate nodes (i.e. - all nodes other than the destination ). Hop-by-Hop Options headers, however, do need to be examined by each router on the path. Note that this raises certain security and performance concerns.

  +---------------+----------------+------------------------
  |  IPv6 header  |HopByHop header | TCP header + data
  |               |                |
  | Next Header = |  Next Header = |
  |   HopByHop    |      TCP       |
  +---------------+----------------+------------------------

Additionally, not that the "Routing Header" (Specifically, the "Type 0" RH) is used for "Source Routing" and introduces the possibility of the Destination Address in the base header not being the FINAL destination, but rather the address of the "next intermediate destination".

Fragmentation

If sending hosts use Path MTU Discovery, they set their MTU to the "lowest common denominator" on the end-to-end path, and thus avoids intermediate fragmentation entirely. IPv6 routers do not fragment as do IPv4 routers, so fragmentation is likely to be needed only when the sending host knows that one or more media, somewhere on the path, cannot support the frame size that the sender must use. Nevertheless, if there must be fragmentation, it is supported with header option 44 and MUST be performed by the sending (source) node.

  +---------------+----------------+-----------------+-----------------
  |  IPv6 header  | Routing header | Fragment header | fragment of TCP
  |               |                |                 |  header + data
  | Next Header = |  Next Header = |  Next Header =  |
  |    Routing    |    Fragment    |       TCP       |
  +---------------+----------------+-----------------+-----------------

Routing headers

The "Type 0" Routing Header carries out a function rarely used in IPv4, "Loose Source Record Route" style source routing. "Type 2" Routing Headers are used for Mobile IPv6, and will be discussed therein.

Security headers

Two of the security standards IP version 6 supports fall within the architecture of the security architecture for the Internet Protocol: the authentication header (AH) and encapsulating security payload (ESP). These may look familiar from IPv4, and they should - this is IPsec. The only key difference here is the "mandated support" of IPsec on every IPv6 node ... note that support is not the same as use! In general, IPv6 is no more or less secure than any other protocol (with some valid concerns around the areas of tunneling and "general newness of code").

IPv6 addresses

Notation

IPv6 principally uses hexadecimal notation, rather than the dotted decimal of IPv4. It uses the same prefix length notation as IPv4, so a /56 would mean that the high-order 56 bits need to be examined for routing decisions.

# A sample (unicast) address:
  2001:0db8:0001:1001:0000:0000:0000:0001
  -- Note the use of Hexadecimal (hex; each character == 4 bits)
  ---- 4 character (16 bits) per "chunk", 8 chunks, colon separated

  We can compress this to make our lives easier:
  -- "Drop leading zeroes" (within each chunk)
  ---- 2001:db8:1:1001:0:0:0:1
  -- "Double-colon" (Replace any number of SEQUENTIAL, ALL ZERO chunks ... one time per address)
  ---- 2001:db8:1:1001::1
  (This double-colon technique is also frequently used when representing a Prefix.  
   For example the above address is taken from the 2001:db8::/32 space - the 2001:0db8 piece 
   (the first 32 bits) is fixed ... the rest (all zeroes) is subject to change)   )
 
  Note that something like this is valid as well:
  2001:0db8:0000:0000:0000:0000:0000:0001 --> 2001:db8::1
  (This IS about making your life easier!)

Scope

See locality of networks

Types of address

IPv6 uses some familiar address types - Unicast, Multicast and Anycast.

1. Unicasting: traditional one-to-one communication analogy, in which a standard phone call exists between two (unicast) telephone numbers
2. Multicasting - one-to-many communication (used for efficient delivery of content) analogy - teacher in a class says something one time, everyone who is interested receives it
3. Anycasting - one-to-one-of-many communication, where the one-of-many is the nearest instance analogy - a bit more complicated than unicast or multicast.

Note that IPv6 does not support "broadcast" addresses. Broadcast was really a special case of multicasting; the broadcast group was the group to which every host belonged. Think of broadcast is the kind of private club that Groucho Marx had in mind when he said "I wouldn't belong to any club that would have me as a member.

Everything IPv4 accomplished with broadcast, IPv6 has a form of multicast for. This includes a very much broadcast-like multicast, the "All Nodes" multicast address, FF02::1

Addressing architecture

RFC 4291 defines the IPv6 addressing architecture, which specifies well-known types of addresses.

Identifier structure

Too many people hand-wave and suggest that the identifier part of an IPv6 address "is a MAC address", but that is a dangerous oversimplification. The most fundamental problem, of course, is the IPv6 identifier is 64 bits long, and (traditional, Ethernet) MAC addresses are only 48. Additionally it is perfectly legal, in the IEEE 802 address architecture, to have a locally administered address rather than the "burnt-in address" in the interface read-only memory. Other types of interfaces are not MAC and have no MAC address available.

The general approach, when a MAC address is available, is to follow an algorithm to produce an IEEE-defined, 64-bit EUI64 identifier from a 48 bit IEEE MAC address. In the IETF IPv6 documentation, the general approach is described in RFC2797, although the reference to the detailed IEEE specification is a broken link; the correct link is

When there is no available MAC address, the formation of the identifier is apt to be implementation-dependent. As long as there is no address collision, a lack of standardization may not be a problem, although it makes it even more critical that the assigned address be put into dynamic DNS. Cisco, for example, describes a number of steps it takes to create an IPv6 interface identifier when no MAC addresses are available.

Examples of interfaces where there is no MAC address could include a router with all serial interfaces, using PPP.

Locator-Prefix structures

An earlier document, on the IPv6 aggregatable global unicast address format document, the global routing prefix included two other hierarchically structured fields named Top-Level Aggregator (TLA) and Next-Level Aggregator (NLA). TLA and NLA have been removed because they are controlled by policies beyond the scope of the addressing architecture. The current global unicast addressing is in RFC3587

Special IPv6 unicast addresses / ranges / address formats

Representative address	Function	Structure	Comments; IPv4 equivalent
::	Unspecified_Address		0.0.0.0
::1	Loopback localhost ipv6-localhost ipv6-loopback		127.0.0.1
::<v4 address>	IPv4-Compatible Addresses		Deprecated ; <v4 address>
::ffff:<v4 address>	IPv4-Mapped Addresses		<v4 address> with a particular Route Distinguisher
2000::/3	Global Unicast Addresses	3 bit type, next 45 bits are provider (making a 48bit routing prefix), 16 bit subnet ID/Site-Level Aggregator (SLA), 64 bit interface identifier
2001:0000::/32	Teredo service prefix	32-bit Teredo service prefix, 32 bits of IPv4 address of Teredo server, 16 bits of flags (address and NAT type), 16 bis of extenal (obfuscated) UDP port, 32 bit external (obfuscated) IPv4 client address
2002::/16	6to4 service prefix	16 bit 6to4 prefix followed by 32bit IPv4 address of the 6to4 "Site Router" (Originally defined as Format prefix: 001, TLA value: 0x0002, NLA value: V4ADDR)	Need clarification of deprecated NLA and TLA
fc00::/7	Unique Local Address	FC00::/7 prefix (FD00::/8 being the active, self-assigned range), 41 bit random("statistically likely to be unique") - resulting in a 48bit prefix, to which a 16 bit subnet ID/Site-Level Aggregator (SLA) is appended	RFC 1918 private address space
fe80::/10	Link-Local Unicast	LLU prefix, 54 zero bits, 64-bit identifier	Packet with TTL=1; perhaps APIPA (169.254/16)
fec0::/10	Site-Local Unicast	SLU prefix, 54 subnet bits, 64-bit identifier	Deprecated; was defined in RFC 3513; see arguments against ; RFC 1918 private address space

special IPv6 multicast addresses / address formats

Address	Function	Comments
ff00::/8	ipv6-mcastprefix	Analogous to the "Class E" multicast address space
ff02::1	ipv6-allnodes	Much like the 255.255.255.255 broadcast
ff02::2	ipv6-allrouters
ff02::1:ffXX:XXXX	Solicited-Node-Multicast	used for Neighbor Discovery

Addresses that must be recognized

All hosts

All hosts, be they end systems or router interfaces, must recognize the following addresses as identifying themselves:

• Its required Link-Local address for each interface.
• Any additional Unicast and Anycast addresses that have been configured for the node's interfaces (manually or automatically).
• The loopback address.
• The All-Nodes multicast addresses defined in Section 2.7.1.
• The Solicited-Node multicast address for each of its unicast and anycast addresses.
• Multicast addresses of all other groups to which the node belongs.

Routers

A router is required to recognize all addresses that a host is required to recognize, plus the following addresses as identifying itself:

• The Subnet-Router Anycast addresses for all interfaces for which it is configured to act as a router.
• All other Anycast addresses with which the router has been configured.
• The All-Routers multicast addresses

Hierarchical addressing

Tentatively, this section deals with concepts. Addressing is a sufficiently large issue that I'm inclined to separate it from Internet Protocol version 6 deployment into Internet Protocol version 6 address management Howard C. Berkowitz 11:58, 1 September 2008 (CDT)

Aggregation

While IPv6 creates more addresses, in its basic form, it does nothing to help the workload on routers that need to carry an appreciable amount of the global Internet routing table, or the full default-free zone. Just as CIDR was needed with IPv4, aggregation techniques are needed with IPv6.

If a relatively small number of short top-level, highly aggregated prefixes can be the only things which which major interprovider routers need be concerned, there is a potential benefit for global routing scalability.

IPv6 and DNS

Since the Domain Name Service maps to and from names and addresses, it must be extended to map IPv6 as well as IPv4 names. The most basic requirement is to have a Resource Record (RR) that contains the address of a host. Since the A RR holds a 32-bit IPv4 address, it was reasonable enough to name the record, which holds an address four times longer, AAAA. All other RR types that contain addresses need to be updated so their address fields can hold either an IPv4 or IPv6 address.

It is trivial to change the RR types and to recognize if an address is IPv4 or IPv6. It is decidedly nontrivial to change DNS servers and clients (i.e., resolvers) so they accept both types.

There also need to be extensions to deal with reverse mapping, especially of high-level aggregates. The IP6.ARPA domain was established to hold the reverse mappings.

Learning addresses

An IPv4 host either is manually configured with its IP address, or learns it statefully using the Dynamic Host Configuration Protocol (DHCP). DHCP can also provide a host with the addresses of various infrastructure functions, such as the default router it is to use, a Domain Name Service (DNS) server, a Network Time Protocol server, etc. If DHCP does not provide these addresses, there are assorted, sometimes vendor-dependent techniques to find them.

One's own address

Before a host, including a router interface, can participate meaningfully in any IP services, it must know its own IP address. This is equally true in IPv4 and IPv6. There was no good and general way for an IPv4 router interface to acquire its own address, and, while some additional support is available in IPv6, routers, and some infrastructure servers, may still need manual configuration. The actual configurations, however, should be stored on server(s); while the details tend to be vendor-dependent, there is usually a technique, often using Trivial File Transfer Protocol, to obtain one's configuration.

Stateless Address Autoconfiguration

Known as SLAAC, information routinely transmitted on IPv6 media, along with host-specific information, can let it generate a working address without use of a DHCP server. Stateless autoconfiguration can be harder to manage, especially if the DNS is not dynamically updated when the address is update. If there is no database, in the Domain Name Service (DNS) or Dynamic Host Configuration Protocol (DHCP), how would the network operator send a ping or traceroute to a host in trouble, or query its SNMP MIB? Yes, some DHCP implementations, used without DNS, create databases that let a static host identifier be associated with the DHCP-assigned address, and this is sometimes necessary — albeit cumbersome. A SLAAC host can be configured to update DNS.

A host that uses SLAAC still will have to acquire certain operationally significant request. While the neighbor discovery process will allow default routers to be found, it is more of a challenge to find a Domain Name Service server. With IPv4, there are some mechanisms to discover such information with a local broadcast technique, but that has its own problems.

Within the IPv6 specifications are one that may seem contradictory: "Stateless Dynamic Host Configuration Protocol", but it is not. This specification is of a very restricted subset of DHCP: finding necessary network servers after a host has its own address. The implementation of such a subset is sufficiently lightweight that it could reasonably be implemented on local routers, which would have much more difficulty in supporting full stateful DHCP for all host address assignment.

Stateful Address Acquisition

Many network administrators, for valid reasons of network control, will prefer for hosts to obtain addresses using a stateful process, and DHCP extensions have been defined for IPv6. There are also some changes in the way a DHCP client submits a unique identifier to the DHCP server. Do note that "DHCP Version 4" is not DHCP for IPv4, but the version of DHCP that supports IP version 6.

Subnet-local hosts and routers

IPv6 has a method more general than the Address Resolution Protocol (ARP), which was an often-troublesome mechanism in IPv4, for finding hosts and routers on its own subnet. This is called Neighbor Discovery.

Registering in dynamic DNS

DNS can and should be updated with dynamically acquired addresses. Such an update is an invitation to attack unless secured, so dynamic DNS update should always be associated with a specific secure update mechanism, within the DNS security architecture.

Router renumbering protocol

IPv6 does have a mechanism by which a router may discover not just interface addresses, but also the high-order bits associated with its aggregatable address. Using the Router Renumbering Protocol, a router, potentially, can be plugged into a live network and learn all relevant addresses, including its "upstream" address prefixes. Many network administrators may choose to keep router configuration a manual process, since merely acquiring the interface addresses may not be adequate to update filters, policies, etc. This may, however, be a useful mechanism for the kind of simple router configurations needed in access from homes and small offices (SOHO)

Flows, quality of service, etc.

Some of the material in this section will make sense only if the reader has a reasonable understanding of quality of service and differentiated service, as this is a discussion of how IPv6 implements ways to support these services, which can also exist under IPv4.

Flow labels

In general, a flow is an association between a sending and a receiving address, and usually a protocol identifier and the higher-level source and destination ports (e.g., TCP port numbers). A flow also may be qualified by its quality of service requirements, and sometimes the physical interface it uses. By using flow labels, the idea was that the router could do a single lookup to find the special handling requirements for the flow. Some routing protocol architect disagree with this, and say it is too fine-grained, where a reasonable "common fate" is closer to what MPLS calls a forwarding equivalence class (FEC). While FEC definitions are implementation-specific, a common example would be all traffic (i.e., a wild-carded source address) to a given destination address and protocols, with the same quality of service.

The original 1994 discussion that proposed flow labels in IPv6 included the QoS/priority field in the flow label, but removed it, for reasons including wanting to be less fine-grained than individual flows.

This section identifies three special cases where there may be ambiguity over the use of flow labels, on the premise that it is sometimes most important to know a question exists. The answer will depend both on the particular host and router implementations, and the policies of the network using flow labels.

1. What should a router do if a datagram with a (non-zero) Flow Label arrives and the router has no state for that Flow Label?
2. How does an internet flush old Flow Labels?
3. Which datagrams should carry (non-zero) Flow Labels?

Operational and other protocol issues

Internet Control Message Protocol version 6

An IPv4 implementation is required to support ICMP, and the same is true in IPv6. Some ICMP functionality, however, is under other specifications, such as Neighbor Discovery

Routing

The standard routing protocols have varying levels of support for IPv6, as well as the one common proprietary routing protocol, Cisco's Enhanced Interior Gateway Routing Protocol. More complex issues are involved in Border Gateway Protocol (BGP) IPv6, and multicast routing protocols are outside the immediate scope.

• Routing Information Protocol (RIP), called RIPng for IPv6
• Open Shortest Path First (OSPF), called Open Shortest Path First for IPv6 or OSPF Version 3
• Enhanced Interior Gateway Routing Protocol (EIGRP), running separate IPv4 and IPv6 domains.
• Intermediate System-Intermediate System (ISIS) remains in an IETF draft.

Controversies

Equivalents to RFC 1918 private address space

The use of site-local addresses, analogous to RFC 1918 private address space for IPv4, is deprecated do to defects of two broad categories: ambiguity of addresses, and fuzzy definition of sites.

As currently defined, site local addresses are ambiguous: an address such as FEC0::1 can be present in multiple sites, and the address itself does not contain any indication of the site to which it belongs. This creates pain for developers of applications, for the designers of routers and for the network managers. This pain is compounded by the fuzzy nature of the site concept.

Note that Site Local addresses have been deprecated, and functionally replaced by Unique Local Addresses [1]

IPv6 Multihoming

For a variety of reasons, fault tolerance and load distribution, multihoming is a common, if sometimes troublesome, practice in the IPv4 Internet. Multihoming is relatively clean if a given network uses IPv4 provider-independent address space for all its hosts. With a certain amount of cooperation among multiple IPv4 providers, the current system works with PA addresses, although inducing routing table ("Default Free Zone", or simply DFZ) bloat is a very real impact/concern.

In IPv4 multihoming, things work because all providers, to a enterprise that uses only PA address space, cooperate such that the enterprise's addressing is all in one PA block that is advertised by all its providers. If the enterprise ends its relationship with the assigning providers, not only does the enterprise need to renumber, the other providers may have to change their configurations. While the enterprise obtaining PI space is easier in IPv6, there still may be operational reasons to use PA addresses, in fact this is the default assumption in IPv6 - that a multihomed organization will obtain PA space from EACH provider and use all of them internally. IPv6 autoconfiguration, in that case, causes hosts to acquire several valid addresses, one (or more) from each of these PA blocks..

If connectivity to a host goes through provider 1 to enterprise customer 22, host 33, another host has no easy way to understand that "1-22-33", if provider 1 loses connectivity, that the host association can be kept up by changing the destination address to "2-47-33". It is the multiple-PA-address-per-host issue that challenges IPv6 multihoming, due to a greater flexibility leading to complexity that never existed in IPv4.

Were the site to advertise the host by PI prefix, to several ISPs, there will be little case of a loss of connectivity problem, but the load distribution and traffic flow may be complicated compared to using multiple PA prefixes.

The Site Multihoming by IPv6 Intermediation (SHIM6) Working Group of the Internet Engineering Task Force has been charged with

IPv6-based site multi-homing solution that

inserts a new sub-layer (shim) into the IP stack of end-system hosts. It will enable hosts on multi-homed sites to use a set of provider- assigned IP address prefixes and switch between them without upsetting

transport protocols or applications.

As of August 2008, SHIM6 has developed working drafts, but not yet standards-track documents. One of the main drafts is for the Shim6 protocol, the "Level 3 Multihoming Shim Protocol for IPv6".

To understand the goals of SHIM6, it is worth understanding what its developers explicitly consider "non-goals":

• The problem to be solved is multihoming to a site, with the numbering of that site changing over time
• Changes to the set of locator (think "prefix") will be relatively slow enough to allow updates to the DNS to propagate since SHIM6 ... depends on the DNS to find alternate addresses to the site.
• an explicit non-goal to make communication survive a site renumbering event (which causes all the locators of a host to change to a new set of locators).
• SHIM6 does not address the host mobility problem (see locality of networks), although it may be useful in some host mobility situations

Its goals are limited to:

• Preserve established communications in the presence of certain classes of failures defined between a pair of IPv6 addresses, such as, TCP connections and UDP streams.
• Have minimal impact on upper layer protocols in general and on transport protocols and applications in particular.
• Address the security threats to IPv6 multihoming, with cryptographic techniques described here and by reference to other work in progress
• Not require an extra roundtrip up front to setup shim specific state, bit allow the upper layer traffic (e.g., TCP) to flow as normal and defer the setup of the shim state until some number of packets have been exchanged.
• Allow the use of multiple locators/identifiers on hosts, so that different sets of source-destination address pairs could spread the workload over different network paths associated with different locators. This is "load-spreading" rather than "load balancing", because there is no way to know the load will be identical on all the pairs.

Translation

Of late, there has been something of a resurgence in IPv6-related translation. The so-called children of the now deprecated NAT-PT include, but are not limited to, things such as: CGN, A+P, SNAT-PT, NAT64, NAT46, NAT66, IVI, etc. Which one(s) will be the "winner", if indeed any of them, remains to be seen.