Quick Notes: IPv6 Overview

** From: Routing TCP/IP, Volume I, 2nd Edition **

• At the time IPv4 was created, a 32-bit address space, yielding almost 4.3 billion addresses, seemed inexhaustible.
• The advent of the World Wide Web changed everything.
• The problem of IPv4 address exhaustion was recognized in the early 1990s the entire address space could be depleted in just a few short years. A new version of IP — known in the development stage as IP Next Generation or IPng, and which is now IPv6 — was the proposed solution. But it was recognized that developing the new standards would take time, and that a short-term solution to IPv4 address depletion also was needed.
• That short-term solution was Network Address Translation (NAT), which allows multiple hosts to share one or a few public IP addresses.
• NAT uses a private IP address space, defined in RFC 1918, to hide hosts behind public IP addresses.
• NAT has been so successful in slowing IPv4 address depletion, and has become such a standard part of most networks, that to this day many still question the need for a new version of IP.
• There are two fundamental drivers behind the growing recognition of the need for IPv6. 
• The first is widespread vision of new applications using core concepts such as mobile IP, service quality guarantees, end-to-end security, grid computing, and peer-to-peer networking. NAT stifles innovation in these areas, and the only way to get NAT out of the way is to make public IP addresses abundant and readily available.
• The second fundamental driver for IPv6 is the rapid modernization of heavily populated countries such as India and China. With its aggressive expansion of its Internet infrastructure, China alone in the near future will represent an unsupportable pressure on an already strained IPv4 address pool.
• IPv6 replaces the 32-bit IPv4 address with a 128-bit address, making 340 trillion trillion trillion IP addresses available. That number will meet the demands for public IP addresses, and answer the needs of the two fundamental drivers discussed here, well into the foreseeable future.
• IPv6 addresses are different from IPv4 addresses in far more ways than just their length.
• 128-bit IPv6 addresses are represented by breaking them up into eight 16-bit segments. 
• Each segment is written in hexadecimal between 0x0000 and 0xFFFF, separated by colons. Example: 3ffe:1944:0100:000a:0000:00bc:2500:0d0b
• There are two rules for reducing the size of written IPv6 addresses:
1. The leading zeroes in any 16-bit segment do not have to be written; if any 16-bit segment has fewer than four hexadecimal digits, it is assumed that the missing digits are leading zeroes. Example: 3ffe:1944:100:a:0:bc:2500:d0b. Trailing zeroes cannot be omitted.
2. Any single, contiguous string of one or more 16-bit segments consisting of all zeroes can be represented with a double colon. Example: ff02:0000:0000:0000:0000:0000:0000:0005 = ff02::5. Using the double colon more than once in an IPv6 address is not allowed.
• IPv6 prefixes are always identified by bitcount, not a subnet mask. Example: 3ffe:1944:100:a::bc:2500:d0b/64. The network prefix would be 3ffe:1944:100:a::/64.
• An IPv6 address consisting of all zeroes can be written simply with a double colon. 
• There are two cases where an all-zeroes address is used:
1. A default address ::/0, in which the address and the prefix length are all 0s.
2. The all-zeroes IPv6 address is an unspecified address ::/128, which is used in some Neighbor Discovery Protocol procedures.
• There are three types of IPv6 addresses: unicast, anycast, and multicast.
• Unlike IPv4, there is no IPv6 broadcast address. There is, however, an “all nodes” multicast address, which serves essentially the same purpose.

IPv6 Address Types

• A unicast address is an address that identifies a single device. 
• A global unicast address is a unicast address that is globally unique. 
• A single interface can have multiple IPv6 addresses, and can have an IPv4 address in addition.
• The Interface ID of the global IPv6 address is, with very few exceptions, 64 bits long.
• Also with very few exceptions, the Subnet ID field is 16 bits.
• A 16-bit Subnet ID field provides for 65,536 separate subnets, which is way too much for most networks.

• Given the overall size of the IPv6 address space, and given the benefits of easy address assignment, design, management, and parsing that comes from using a fixed size, the waste is justified.
• The IANA and the Regional Internet Registries (RIRs) assign IPv6 prefixes — normally /32 or /35 in length—to the Local Internet Registries (LIRs). The LIRs, which are usually large Internet Service Providers, then allocate longer prefixes to their customers. In the majority of cases, the prefixes assigned by the LIRs are /48.
• The first few bits of the address specify the address type. For example, the first three bits of all global unicast addresses currently are 001, which is expected to suffice for global unicast addresses for some time to come. That means they all start with either 2 or 3, depending on the value of the fourth bit in the global routing prefix.
• The majority of leading bit combinations are reserved:
• Unspecified - 00...0 (::/128)
• Loopback - 00...1 (::1/128)
• Multicast - 11111111 (FF00::/8)
• Link-Local Unicast - 1111111010 (FE80::/10)
• Site-Local Unicast (Deprecated) - 1111111011 (FEC0::/10)
• Global Unicast (Currently allocated) - 001 (2xxx::/4 or 3xxx::/4)
• Reserved (Future global unicast allocations) - Everything else
• Global unicast address means that the address is globally unique and can be routed globally with no modification. 
• Link-local unicast address is confined to a single link. Its uniqueness is assured only on one link, and an identical address might exist on another link, so the address is not routable off its link. The first 10 bits of the link-local unicast address are always 1111111010 (FE80::/10).
• A site-local address is unique only within a given site; devices in other sites can use the same address. Therefore a site-local address is routable only within the site to which it is assigned. 
• Functionally the site-local address is similar to IPv4 private addresses defined in RFC 1918. The first 10 bits of site-local unicast addresses is 1111111011 (FEC0::/10). Site-local addresses have been deprecated.
• An anycast address represents a service rather than a device, and the same address can reside on one or more devices providing the same service.
• Some service is offered by three servers, all advertising the service at the IPv6 address 3ffe:205:1100::15. The router, receiving advertisements for the address, does not know that it is being advertised by three different devices; instead, the router assumes that it has three routes to the same destination and chooses the lowest-cost route.
• The advantage of anycast addresses is that a router always routes to the “closest” or “lowest-cost” server.
• So servers providing some commonly used service can be spread across a large network and traffic can be localized or scoped to the nearest server, making traffic patterns in the network more efficient. And if one server becomes unavailable, the router routes to the next nearest server. 
• A multicast address identifies not one device but a set of devices—a multicast group.
• A multicast packet normally has a unicast address as its source address and a multicast address as its destination address. A multicast address never appears in a packet as a source address.
• Examples of well-known IPv6 multicast addresses:
• FF02::1 - All Nodes
• FF02::2 - All Routers
• FF02::5 - OSPFv3 Routers
• FF02::6 - OSPFv3 Designated Routers
• FF02::9 - RIPng Routers
• FF02::A - EIGRP Routers
• FF02::B - Mobile Agents
• FF02::C - DHCP Servers/Relay Agents
• FF02::D - All PIM Routers
• There are several IPv4 to IPv6 transition technologies that require an IPv4 address to be communicated within an IPv6 address.
• Examples of IPv6 addresses with an embedded IPv4 address of 10.23.1.5 are FE80::5EfE:10.23.1.5 (An ISATAP address), ::FFFF:10.23.1.5 and ::FFFF:0:10.23.1.5 (SIIT addresses), and FEC0:0:0:1::10.23.1.5 (TRT address).
• In each of these examples, the IPv4 address is the last 32 bits of the IPv6 address and is represented in dotted decimal.
• Other transition technologies using embedded IPv4 addresses do not use dotted decimal but encode the IPv4 address into hexadecimal. 6to4, for example, does this. 10.23.1.5 in hexadecimal is 0A17:0105. A 6to4 prefix with 10.23.1.5 embedded is then 2002:0A17:0105::/48.

IPv6 Packet Header Format

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

• Version (4 bits) = indicates the IP version, 0110 for IPv6. 
• Traffic Class (8 bits) = corresponds to the IPv4 ToS field. 
• Flow Label (20 bits) = allow labeling of particular flows of traffic; that is, packets that are not just originated by the same source and going to the same destination, but that belong to the same applications at the source and destination. When balancing traffic loads across multiple paths, that packets belonging to the same flow are always forwarded over the same path to prevent possible reordering of packets.
• Payload Length (variable) specifies the length of the payload, in bytes, that the packet is encapsulating.
• Next Header (8 bits) specifies which header follows the IPv6 packet header. In this, it is very similar to the Protocol field in the IPv4 header and, in fact, is used for the same purpose when the next header is an upper-layer protocol header. But in IPv6, the header following the packet header might not be an upper-layer protocol header, but an extension header.
• Hop Limit (8 bits) corresponds exactly to the IPv4 Time to Live (TTL) field.
• Source and Destination Address correspond to the IPv4 Source and Destination fields, except of course these fields are 128 bits each to accommodate IPv6 addresses.
• Given the overall increase in reliability of modern transport media—wireless perhaps being a notable exception—along with the fact that upper-layer protocols usually carry their own error-checking and recovery mechanisms, checksumming of the IPv6 header itself adds little value, and is therefore eliminated.
• Despite the IPv6 address fields being 4 times bigger than IPv4, the IPv6 header itself is not that much larger than an IPv4 header: 40 bytes for IPv6 versus a minimum of 20 bytes for IPv4.
• When an optional function is used in IPv6, an extension header appropriate for the function is added after the packet header. If, for example, source routing, fragmentation, and authentication options are to be used, three extension headers formatted to carry the information needed for each of those functions.
• Because of these headers, efficiency is added to IPv6 packets in two ways:
1. The packet carries only the information required by that individual packet. No unused fields are carried.
2. New optional functions can be added to the IPv6 packet by defining new extension headers.
• Each extension header, like the IPv6 header, has a Next Header field. So each header tells which header follows it.
• The currently defined extension headers and their next header values:
• Hop-By-Hop Options - 0
• Routing - 43
• Fragment - 44
• Encapsulating Security Payload (ESP) - 50
• Authentication Header (AH) - 51
• Destination Options - 60
• TCP/IP Protocols - Protocol number value defined for that protocol (such as TCP = 6, UDP = 17, OSPF = 89, and so on)
• No Next Header - 59
• Hop-By-Hop Options carries information that must be examined by every node along the forwarding path, such as Router Alert and Jumbo Payload options.
• Routing provides source routing functionality by listing nodes that the packet must pass through on the way to its destination.
• Fragment is used when a packet is fragmented, to provide the information necessary for the receiving node to reassemble the packet. A significant difference between IPv4 and IPv6 is that only originating nodes can fragment packets; IPv6 routers do not fragment the packets. So originating nodes must either use Path MTU Discovery (PMD) to find the lowest MTU along a path to the destination, or never produce packets larger than 1280 bytes. PMD is described in the next section. IPv6 specifies that all links on which it runs must be able to support packet sizes of at least 1280 bytes so that originators can use the minimum-size option rather than PMD if they so choose.
• Encapsulating Security Payload (ESP) is used when the payload is encrypted.
• Authentication Header (AH) is used when the packet must be authenticated between the source and destination.
• Destination Options carries information to be examined only by the destination node or possibly by nodes listed in the Routing header.

Neighbor Discovery Protocol

• Neighbor Discovery Protocol (NDP) enables plug-and-play access to the network, using the following functions:
• Router Discovery — A node can discover, when it is connected to an IPv6 link, the local routers without the aid of Dynamic Host Configuration Protocol (DHCP).
• Prefix Discovery — A node can discover, when it is connected to an IPv6 link, the prefix or prefixes assigned to that link.
• Parameter Discovery — A node can discover parameters such as the link MTU and hop limits for its connected link.
• Address Autoconfiguration — A node can determine its full address, again without the aid of DHCP.
• Address Resolution — A node can discover the link-layer addresses of other nodes on the link without the use of Address Resolution Protocol (ARP).
• Next-Hop Determination — A node on a link can determine the link-layer next hop for a destination, either as a local destination or a router to the destination.
• Neighbor Unreachability Detection — A node can determine when a neighbor on a link, either another host or a router, is no longer reachable.
• Duplicate Address Detection — A node can determine if an address it wants to use is already being used by another node on the link.
• Redirect — A router can notify a host of a better next-hop than itself to an off-link destination. The redirect function is a part of basic ICMP functionality in IPv4, but is redefined as part of NDP in IPv6.
• NDP messages should always be link-local in scope, and therefore the packets encapsulating them always use either link-local IPv6 addresses or multicast addresses with a link-local scope.
• The Hop Limit of the IPv6 packet carrying all NDP messages is 255. If one of these packets is received with a Hop Limit less than that value, it means the packet has passed through at least one router, and the packet is dropped.
• NDP uses ICMPv6 to exchange the messages necessary for its functions:
• Router Advertisement (RA) messages are originated by routers to advertise their presence and link-specific parameters such as link prefixes, link MTU, and hop limits. These messages are sent periodically, and also in response to Router Solicitation messages.
• Router Solicitation (RS) messages are originated by hosts to request that a router send an RA.
• Neighbor Solicitation (NS) messages are originated by nodes to request another node’s link layer address and also for functions such as duplicate address detection and neighbor unreachability detection.
• Neighbor Advertisement (NA) messages are sent in response to NS messages. If a node changes its link-layer address, it can send an unsolicited NA to advertise the new address.
• Redirect messages are used the same way that redirects are used in ICMP for IPv4; they have merely been moved from being a part of the base ICMPv6 protocol to being a part of NDP.

Address Autoconfiguration

• When an IPv6 host first becomes active on a link, it can self-configure its own interface address.
• The first step is to determine the 64-bit Interface ID portion of the address.
• A mechanism called MAC-to-EUI64 conversion is used. 
• Quite simply, this mechanism takes the 48-bit Media Access Control (MAC) address of the interface—which can normally be assumed to be globally unique—and converts it into a 64-bit Interface ID by inserting a reserved 16-bit value of 0xFFFE into the middle of the MAC address and “flipping” the Universal/Local (U/L) bit of the MAC address to 1 (Universal).
• Example: MAC address is 0000:0B0A:2D51 is converted. 
• “Split” the MAC address in the middle and insert 0xFFFE between the two 24-bit halves. The address is now 64 bits long.
• Next, the U/L bit of the original MAC address—which is always the 7th bit—is flipped from 0 to 1. The resulting address, 0200:0BFF:FE0A:2D51, is now a valid 64-bit Interface ID.

• The Interface ID is only half of the IPv6 address; a 64-bit prefix is also required.
• The link-local prefix is a reserved, well-known value of 0xFF80::/10. Using this as a full 64-bit prefix (0xFE80::/64), it can be added onto the derived Interface ID, and the host now has a complete IPv6 address FF80::0200:0BFF:FE0A:2D51.
• Using the link-local prefix FE80::/10 and a MAC-to-EUI64 conversion, an IPv6 interface derives its link-local address with no help from any other device:
• If the host only needs to communicate with devices on the link, autoconfiguring its link-local address is sufficient.
• Otherwise, stateful or stateless address autoconfiguration is required.
• If a host uses stateful address autoconfiguration, it consults a DHCPv6 server for the necessary address information.
• With stateless autoconfiguration, the host acquires one or more link prefixes from the RAs it receives. It then adds the prefix to its previously determined Interface ID, and it now has a globally unique IPv6 address. For example, if the host received an RA advertising a prefix of 3FFE: 1104:404:1::/64, it would add that prefix to its Interface ID for a global address of 3FFE:1104: 404:1:0200:0BFF:FE0A:2D51.

Duplicate Address Detection

• Whenever a device acquires a unicast address, it must perform Duplicate Address Detection before using the address.
• It does not matter whether the address was acquired via stateful or stateless configuration, or if the address was statically configured. 
• The only exception to the rule is an anycast address, because anycast addresses by definition can appear on more than one device.
• The node sends an NS with the Target Address field set to the address to be verified. The source address of the NS is the unspecified address, and the destination of the NS is a solicited-node multicast address.
• A solicited-node multicast address is formed by prepending the prefix FF02:0:0:0:0:1:FF00::/104 to the last 24 bits of the target address. For example, given the Interface ID derived previously, the solicited-node multicast address is FF02::1:FF0A:2D51.
• If a node receives an NS and the target address matches one of its assigned addresses, it sends an NA with the Target Address and the destination address set to the tentative address. The node that had originated the NS, on receipt of the NA, knows that the tentative address is duplicate and cannot be used.

Neighbor Address Resolution

• But if the destination is on the local link, the node first looks in its neighbor cache to see if the address is known. The neighbor cache in IPv6 is very similar to the ARP cache in IPv4; it records known network-layer addresses and the link-layer addresses associated with them. 
• The neighbor cache stores known IPv6 addresses and their associated link-layer addresses.
• If the address is not in the neighbor cache, it is entered but tagged Incomplete, indicating that address resolution is in progress. The node then sends an NS to the solicited-node multicast address associated with the target node.
• If no NA is received from the solicited node after three NS transmissions, the neighbor address resolution has failed and an ICMP message of type 1/code 3 (Destination Unreachable/Address Unreachable) is returned for each packet queued for transmission to the now unknown destination.
• A neighbor cache entry can be in one of five states:
• Incomplete—. Neighbor address resolution is in progress. An NS has been sent to the solicited-node multicast address for the entry, but no NA has yet been received.
• Reachable—. The address has been recently confirmed as reachable. “Recently confirmed” means that some indication of its reachability has been received within the time specified in the Reachable Time field of the RAs. If no Reachable Time has been specified in RAs, a default Reachable Time of 30 seconds is used.
• Stale—. The Reachable Time has elapsed since the last positive confirmation of reachability with the destination has been received.
• Probe—. A confirmation of reachability is being sought by sending NS to the destination every Retransmit Time or (if no Retransmit Time has been specified) every 1000 ms.
• Delay—. An address is put into this state when a packet is sent to a destination that was in the Stale state. It stays in the Delay state for 5 seconds, and if no confirmation of reachability is received within that time, the state is changed to Probe. This state is an optimization to give upper-layer protocols a chance to confirm reachability before a probe NS is sent.

Privacy Addresses

• Recording and analyzing packets coming into some part of the network can identify you by your unchanging Interface ID. And by further analyzing the different prefixes prepended to that Interface ID, your employer can infer where you are at all times: at work, at home, traveling, or whatever.
• RFC 3041 addresses this security concern by defining IPv6 privacy addresses. A privacy address is one in which the Interface ID is generated by an algorithm using a pseudo-random number. What is significant about it, and makes it reasonably private, is that the Interface ID changes approximately once a day (or on some configurable period) and also whenever the node acquires a new IPv6 prefix.
• Of course, a constantly changing address is not practical for reachability. Nodes that want to communicate with you, and hence DNS servers, must know you by only one or a few static addresses. 
• So the standard statelessly configured IPv6 address remains your public address. Anyone wanting to send packets to you uses this address as the destination. But when you send packets back, you use the private address. 
• This is a bit like having Caller ID in your home but blocking your number from appearing on anyone else’s Caller ID. You can see who is calling you, but others cannot see your number when you call them.