In 1998, the Internet Engineering Task Force (IETF) released RFC 2460, outlining the technical specifications of IPv6, which addressed the shortcomings of the aging IPv4 protocol. As with any evolution of technology, new elements exist in the protocol that may seem strange and unfamiliar. This certainly includes address representation, space, and so forth, but also includes a number of different types of addresses as well. A subset of these new addressing types has corresponding types in IPv4, but many will seem significantly different. The purpose of this white paper is to examine addressing classifications in detail and outline their functions within the context of the protocol.
To begin with, using the word types immediately implies the existence of numerous possible categories, and that impression is absolutely correct. Since it would be understandable to think of IPv4 addressing as somewhat monolithic, the existence of more than one addressing type can sound daunting to remember and understand. To put this concept into perspective, consider Figure 1 below, depicting various types of cellular telephones. The various "species" of devices displayed have differing colors, form factors, manufacturers, and capabilities, but in reality all are phones. In our discussion of IPv6 addressing types, just think of the different classifications have specific characteristics, but still having the same basic purpose: communication!
Three major addressing classification types exist in IPv6, with some subtypes as well. These consist of multicast, anycast, and unicast addresses, and each is technically worthy of separate consideration.
In the classful addressing world of IPv4, multicast addressing was neatly confined into the Class D range, from 220.127.116.11 to 18.104.22.168. Within this group were specific allocations, such as the 22.214.171.124/8 administratively scoped range. Unicast represented one-to-one communication between hosts, and broadcast represented one-to-every communication. Multicast revolves around the concept not unlike being part of a club; communication and inclusion is a matter of whether or not you belong to that particular group or not. In IPv6, multicast takes on an even greater significance: first, because all broadcasts have been removed from protocol operations, and second, because a variety of protocol functions take place by means of multicast. Understandably, the address itself has several distinct features, as reflected in Figure 2.
Indicator or Prefix
Multicast addresses begin with eight bits, indicating the function involved, composed of all ones (1s), and yielding the hexadecimal characters of FF. The general designation for the entire multicast range is FF00::/8, which is readily recognizable with even casual observation.
While the RFC specifies several values for the flag field, at present only one (the T bit) is in current use and identifies the lifetime of the address. 0 indicates a permanent address, while 1 denotes a temporary one.
The 4-bit scope field describes to what degree the multicast address may be forwarded throughout the network, though not all values of this field have been defined. A partial list of these values is as follows:
4 Admin-Local E Global
The remaining 112 bits of the IPv6 multicast address identify the multicast group itself. In fact, some multicast addresses are already defined, and every network professional should be able to readily identify:
FF02::1 All Hosts
FF02::2 All Routers
FF02::5 OSPFv3 Routers
FF02::6 OSPFv3 Designated Routers
FF02::A EIGRP Routers
The anycast addressing type deserves a special explanation, not only because it may appear unfamiliar, but also because it seems contrary to fundamental networking principles. To begin with, anycast employs the use of identical IP addressing to multiple devices within an internetwork, with nodes relying on routing protocols to determine which is physically closest. While not deployed extensively even in IPv4, this type of approach could be applied to shared resources such as DNS servers, for example. In IPv6, anycast is called out as a distinct addressing type, even though it is still not widely implemented.
No Distinct Format
As if the anycast concept itself is not confusing enough, the issue becomes more complicated by the fact that any IPv6 unicast address can be used as an anycast address. Unlike multicast addresses, there is no easily distinguishable format by which to recognize them. The most obvious distinguishing characteristic of an anycast address is whether it exists on more than one device within a routing domain.
As an engineer, I frankly have had a difficult time really grasping the concept of anycast addressing, though I have read many detailed explanations of the topic. The basic idea is to use identical addressing with shared resources, and have the natural process of IP routing select the closest resource, but that was as far as my understanding went. During the course of using a Global Positioning System program on my Android Phone, I inadvertently discovered a completely new method of understanding this previously ambiguous topic.