Internet Protocol version 6

Template:TOC-right 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.

A quick 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".

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 function.

Some of the goals of IPv6 included:

• Efficient hardware processing of packet headers: Some IPv4 header fields have been dropped or made optional (e.g., fragmenttion), 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.

  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |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.

The Next Header field, for example, serves the function of the protocol identifier field and even uses the same values, in RFC1700 and later online IANA lists. In addition, however, this field more efficiently implements the Options mechanism from IPv4.

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

Traffic class and flow label are largely new capabilities, which are discussed below.

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. Unicast: traditional one-to-one communication analogy, in which a standard phone call exists between two (unicast) telephone numbers
2. Multicast - 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. Anycast - 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, <code.FF02::1

Addressing architecture

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

Special IPv6 unicast addresses / ranges / address formats

Representative address	Function	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	(Currently active) Global Unicast Addresses		198.0.2.1
2001:0000::/32	Teredo service prefix
2002::/16	6to4 service prefix
fc00::/7	Teredo service prefix		Unique-Local Addresses
2001:0000::/32	Teredo service prefix
fe80::/10	Link-Local Unicast		prefix with all ones host field or packet with TTL=1
fec0::/10	Site-Local Unicast (DEPRECATED)		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

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.

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 DNS or DHCP (i.e., no DHCP is needed with SLAAC), how would the network operator send a ping or traceroute to a host in trouble, or query its SNMP MIB?

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 the autoconfigured address with 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

5340 OSPF for IPv6. R. Coltun, D. Ferguson, J. Moy, A. Lindem. July

    2008.