As a set of specifications defined by the Internet Engineering Task Force (IETF), Internet Protocol version 6 (IPv6) is the next-generation network layer protocol standard and the successor to Internet Protocol version 4 (IPv4). The most obvious difference between IPv6 and IPv4 is that IP addresses are lengthened from 32 bits to 128 bits. In doing so, IPv6 is capable of supporting an increased number of levels of addressing hierarchy, a much greater number of addressable nodes, and simpler auto-configuration of addresses.
The existing IPv4 address range was implemented at a time when such networks as ARPANET and the National Science Foundation Network (NSFNET) represented the mainstream backbone network, and at a time when IPv4 was considered more than ample to support the range of hosts that would connect to these forming networks. The unforeseen evolution of the Internet from these ancestral networks resulted in the rapid consumption of the IPv4 address space of 4.3 billion addresses (of which many are reserved), for which counter measures in the form of NAT and CIDR were put in place to alleviate the expansion, and give time for a more permanent solution to be formed. Additionally, early IPv4 network address allocation was highly discontiguous making it difficult for addressing to be clustered into effective address groups and ease the burden on global IP routing tables used in autonomous system based routing protocols such as BGP.
Eventually however the IP network is expected to shed its IPv4 addressing to make way for IPv6 and provide the addressing capacity of over 340 undecillion unique addresses, considered more than necessary for continued IP network growth. Along with this, address allocation by the Internet Assigned Numbers Authority (IANA) ensures that address allocation for IPv6 is contiguous for efficient future management of IP routing tables.
The IPv6 header required some level of expansion to accommodate the increased size of the IP address, however many other fields that were considered redundant in many cases of packet forwarding were removed in order to simplify the overall design of the IPv6 header, and optimize the level of overhead that is necessary during each packet that is forwarded across the network. In comparison with the IPv4 packet header, the IPv6 packet header no longer contains an Internet Header Length (IHL), identifier, flags, fragment offset, header checksum, options, or padding fields, but instead carries a flow label field.
The term flow can be understood as a continuous stream of unicast, multicast or anycast packets relating to a specific application or process that originate from a given source and are transmitted to a given destination or multiple destinations. The natural behavior of a packet switched network means that such traffic flows may be carried over multiple paths and arrive at the intended destination out of sequence. System resources are then required to re-sequence the packet flow before it can be processed by the upper layers.
The flow label intends to identify such traffic flows, together with the source and destination address fields, to maintain a common path across networks for all packets associated with the traffic flow. In doing so packets are capable of maintaining sequence over the IP network, and this optimizes process efficiency.
As IP network convergence introduces technologies such as voice that relies on a circuit switched traffic flow behavior and near real time performance, the importance of the flow label field becomes more paramount.
Various options can also now be supported without changing the existing packet format, with the inclusion of extension header information fields. These extension header fields are referenced through the Next Header field that replaces the protocol field found in IPv4, in order to provide additional flexibility in IPv6.
The extension header is one of the primary changes to IPv6 for enabling the IPv6 header to be more streamlined. There are a number of extension headers that exist in IPv6 and are referenced directly through a hexadecimal value in the IPv6 Next Header field, in the same way that ICMP, TCP, UDP headers are referenced in the protocol field of the IPv4 header. Each extension header also contains a next header field to reference the next header following the processing of the extension header. Multiple extension headers can be associated with a packet and each referenced in sequence. The list of extension headers and the sequence in which the extension headers are processed are as follows.
- IPv6 header
- Hop-by-Hop Options header
- Destination Options header
- Routing header
- Fragment header
- Authentication header
- Encapsulating Security Payload header
- Destination Options header
- Upper-layer header (as in IPv6 tunneling)
- Each extension header should occur at most once, except for the Destination
Options header which should occur at most twice (once before a Routing header and once before the upper-layer header). Another key aspect of the extension headers is the introduction of IPSec protocols in the form of AH and ESP to enhance the overall security of IPv6.
The IPv6 address is a 128 bit identifier that is associated with an interface or a set of interfaces as (in the case of anycast address assignment covered later). The address notation due to size is commonly defined in hexadecimal format and written in the form of xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, where the xxxx relates to the four hexadecimal digits that translate to a 16 bit binary value. The set of 8*16 bit grouped hexadecimal values comprises the 128 bit IPv6 address.
The address itself is made up of an IPv6 prefix that is used to determine the IPv6 network, followed by an interface ID. The basic addressing scheme represents a two layer architecture of prefix and interface ID, however IPv6 address types may contain many sublevels that enable an extensive hierarchical addressing architecture to be formed in the IPv6 network, to support effective grouping and management of users and domains.
The extensive 128 bit size of the IPv6 address means that the general written notation can be impractical in many cases. Another factor that will remain common for quite some time is the presence of long strings of zero bits, primarily due to the unfathomable enormity of the address scale involved. This however brings a means for simplification and practicality when writing IPv6 addresses that contain zero bits. One initial means of simplification of the address scope is through the removal of any leading zero values that are found in each set of 16 bit hexadecimal values.
A special syntax is available to further compress the zeros and is represented in the form of a double colon or "::“. This value indicates one or more 16 bit groups of zeros. In order to enable the string size to be determinable however, the "::" can only appear once in an address. The double colon "::" can be used to compress leading zeros in an address as displayed in the given example.
The IPv6 address space has yet to be completely defined firstly due to the magnitude of the addressing space, for which it is not likely to be required anytime in the near future, secondly the formulation of addressing schemes is still somewhat in an infancy stage with much discussion occurring with regards to the address types that should be applied.
Currently a fraction of the address range has been sectioned for use in the form of a 2000::/3 address range that represents a global unicast address range. This can be understood to be any address that is routable in the public IP network. The governing body IANA (now a part of ICANN) is responsible for distributing portions of this address range to various Regional Internet Registries (RIR) that manage addressing for one of five regions in the world. Supersets of IPv6 addresses in the form of 2400::/12 (APNIC), 2600::/12 (ARIN), 2800::/12 (LACNIC), 2A00::/12 (RIPE NCC) and 2C00::/12 (AfriNIC) have been allocated, allowing the potential for addressing for a given region to be referenced and managed in the meantime using a single address prefix. Also contained within the 2000::/3 prefix range are reserved address fields, including 2001:0DB8::/32 that is used to reference fictional addressing within documentation.
Multicast addressing is defined within IPv6 as FF00::/8, with much of the addressing scope being reserved to specific address ranges (such as link local) and in support of routing protocols, in a manner similar to how multicast addresses are used in IPv4. One major change to IPv6 is that there are no broadcast addresses, their function being superseded by multicast addresses, which reduces unnecessary processing by end stations at the MAC layer within IPv6 networks, since hosts are able to filter multicast MAC address groups. Some special addresses also exist within IPv6 including the unspecified address ::/128 which represents an interface for which there is no IP address currently assigned. This should not be confused however with the default IP address ::/0 which is used as a default address value for any network in the same way the 0.0.0.0/0 default address is used within IPv4. For the loopback address (127.0.0.1), this is defined in IPv6 as the reserved address ::1/128.
Unicast addressing comprises primarily of global unicast and link local unicast address prefixes, however other forms also exist. All global unicast addresses have a 64-bit interface ID field, with exception to addresses for which the first three bitsin the address are 000. For such addresses there is no constraint on the size or structure of the interface ID field. The address format for global unicast addresses comprise of a hierarchy in the form of a global routing prefix and a subnet identifier, followed by the interface identifier. The global routing prefix is designed to be structured hierarchically by the Regional Internet Registries (RIR) and the Internet Service Providers (ISP) to whom the RIR distribute IP address prefixes. The subnet field is designed to be structured hierarchically by site administrators to provide up to 65’535 individual subnets.
In terms of the Link Local unicast address, the FE80::/10 means that the first 10 bits of the link local address is clearly distinguishable as 1111111010. The 64-bit interface address range is more than sufficient for the addressing of hosts, and therefore the remaining 54bits within the Link Local address are maintained as 0. The example displays the address formats that can be typically associated with each of the common unicast address types.
It should be noted also that a third unicast addressing scheme, referred to as site local addressing (FC00::/7) was originally proposed in RFC3513 and may appear in some implementations of IPv6, however the addressing range has been deprecated as of RFC4291 and should be avoided as part of future implementations.
A multicast address is an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. The multicast address range is determined from a FF00::/8 address prefix and is clearly distinguishable from the first 8 bits which are always set to 11111111. The address architecture for multicast addresses comprises of flags, scope and group ID fields.
The flags field though 4 bits, is currently used to support identification of whether a multicast address is well known (as in assigned and recognized by the global internet numbering authority) or transient, meaning the multicast address is temporarily assigned. A second bit value is used within the flags field to determine whether or not the multicast address is based on the network prefix. The remaining higher order two bits are reserved and remain set to 0.
The scope defines a number of potential ranges to which the multicast is applied. Generally this may refer to a node local scope FF01::, or to the link local scope FF02:: which refers to the listeners within the scope of the link-layer, such as an Ethernet segment for which a gateway defines the boundary. Common well known link local multicast addresses include FF02::1 which is used to forward to all nodes, and FF02::2 that allows multicast transmission to all router addresses.
Anycast represents an identifier for a set of interfaces (typically belonging to different nodes). A packet sent to an anycast address is delivered to one of the interfaces identified by that address (the "nearest" one, according to the routing protocols' measure of distance). The anycast architecture commonly involves an anycast initiator and one or multiple anycast responders.
The anycast initiator may commonly be a host that is enquiring to a service such as in the case of a DNS lookup, or requesting the retrieval of specific data, such as HTTP web page information. Anycast addresses are in no way distinguishable from unicast addresses, with the exception that multiple instances of the same address are applied to a given device.
The application for anycast over traditional methods of addressing brings many potential benefits to enterprise network operation and performance. Service redundancy is one such application for anycast that allows a service such as HTTP to be used across multiple servers, for which the same address is associated with one or more servers that operate as anycast responders. In the event that service failure occurs on one server, clients would need traditionally to search for the address of another server and then restart/reestablish communication.
Using anycast addressing, the anycast initiator automatically establishes communication with another server that is using the same address, providing an effective redundancy solution.
In terms of performance, multi-server access can be applied, where an anycast initiator establishes a connection to the same unicast address, each connection automatically establishes to multiple servers that specify the same anycast address such as in the case of a client browsing a company web page.
The client will download the html file and individual image files from separate mirror servers. As a result, the anycast initiator untilizes bandwidth from multiple servers to download the web page much more quickly than is possible with a unicast approach
Upon physically establishing with an IPv6 network, hosts must establish a unique IPv6 address and associated parameters such as the prefix of the network. Routers send out Router Advertisement messages periodically, and also in response to Router Solicitations (RS) to support router discovery, used to locate a neighboring router and learn the address prefix and configuration parameters for address auto-configuration.
IPv6 supports stateless address auto-configuration (SLAAC) that allows hosts to obtain IPv6 prefixes and automatically generate interface IDs without requiring an external service such as DHCP. Router Discovery is the basis for IPv6 address autoconfiguration and is implemented through two message formats.
Router Advertisement (RA) messages allow each router to periodically send multicast RA messages that contain network configuration parameters, in order to declare the router’s existence to Layer 2 hosts and other routers. An RA message is identified by a value of 134 in the type field of the message. Router Solicitation (RS) messages are generated after a host is connected to the network.
Routers will periodically send out RA messages however should a host wish to prompt for an RA message, the host will send an RS message. Routers on the network will generate an RA message to all nodes to notify the host of the default router on the segment and related configuration parameters. The RS message generated by a host can be distinguished by the type field which contains a value of 133.
In order to facilitate communication over an IPv6 network, each interface must be assigned a valid IPv6 address. The interface ID of the IPv6 address can be defined either through manual configuration by a network administrator, generated through the system software, or generated using the IEEE 64-bit Extended Unique Identifier (EUI-64) format.
Due to practicality, the most common means for IPv6 addressing is to generate the interface ID using the EUI-64 format. IEEE EUI-64 standards use the interface MAC address to generate an IPv6 interface ID. The MAC address however represents a 48-bit address whilst the required interface ID must be composed of a 64-bit value. The first 24 bits (expressed by c) of the MAC address represent the vendor (company) ID, while the remaining 24 bits (expressed by e) represents the unique extension identifier assigned by the manufacturer.
The higher seventh bit in the address represents a universal/local bit to enable interface identifiers with universal scope. Where this value is 0, the MAC address is unique globally. During conversion, the EUI-64 process inserts two octet “0xFF” and “0xFE” values totaling 16 bits between the vendor identifier and extension identifier of the MAC address, and the universal/local bit 0 is changed to 1 to indicate that the interface ID now represents a globally unique address value. A 64-bit interface ID is created and associated with the interface prefix to generate the IPv6 interface address.
Before an IPv6 unicast address is assigned to an interface, Duplicate Address Detection (DAD) is performed to check whether the address is used by another node. DAD is required if IP addresses are configured automatically. An IPv6 unicast address that is assigned to an interface but has not been verified by DAD is called a tentative address. An interface cannot use the tentative address for unicast communication but will join two multicast groups: ALL-nodes multicast group and Solicited-node multicast group.
A Solicited-Node multicast address is generated by taking the last 24 bits of a unicast or anycast address and appending the address to the FF02:0:0:0:0:1:FF00::/104 prefix. In the case where the address 2000::1 is used, the address solicited node multicast address FF02::1:FF00:1 would be generated.
IPv6 DAD is similar to the gratuitous ARP protocol used in IPv4 to detect duplicated IPv4 host addresses upon address assignment or connection of the host to the network. A node sends a neighbor solicitation (NS) message that requests the tentative address be used as the destination address to the Solicitednode multicast group.
If the node receives a neighbor advertisement (NA) reply message, the tentative address is confirmed as being used by another node and the node will not use this tentative address for communication, following which manual assignment of an address by an administrator would be necessary
The address 2001:0DB8:0000:0000:0000:0000:032A:2D70 can be condensed to 2001:DB8::32A:2D70. The double colon can be used to condense strings of zeroes that are often likely to exist due to the unfathomable size of the IPv6 address space, but may only be used once. Leading zero values can be condensed, however trailing zero values in address strings must be maintained.
The 64-bit Extended Unique Identifier (EUI-64) format can be used to generate a unique IPv6 address. This is achieved by inserting two ‘FF’ and ‘FE’ octet values into the existing 48-bit MAC address of the interface, to create a unique 64-bit value that is adopted as the IPv6 address of the end station interface. Validation of the address as a unique value is confirmed through the Duplicate Address Detection (DAD) protocol