Welcome back to this series on IPv6. In the first two articles, we presented an introduction to IPv6 and then went on to describe the different IPv6 address types. Please note that this series is not vendor-specific; i.e., we are discussing IPv6 in general as defined in RFCs and not as implemented by different vendors, e.g., Microsoft or Cisco. In this article, we will be looking at the IPv6 scoped address architecture.

IPv6 Address Scope

IPv6 was designed in such a way that the addresses have a “scope” in which they can be used as unique identifiers. According to the RFC on IPv6 scoped address architecture, a scope is “a topological span within which the address may be used as a unique identifier for an interface or set of interfaces.” For example, a link-local unicast address has a “link-local scope,” meaning that such an address uniquely identifies an interface on a particular link. In the same way, a site-local unicast (deprecated) address has a “site-local scope” and a global unicast address has a “global scope.”

Note: Even though site-local unicast addresses have been deprecated, site-local multicast addresses have not.

Let’s explain the scope concept using a diagram:

The diagram shows a router with multiple interfaces (it could also be any node with multiple interfaces) that is connected to two different links—Link #1 and Link #2. Taking Link #1 into consideration, we have three addresses: fe80::1, fe80::2, and fe80::3. Because these addresses are link-local addresses, it means they have a link-local scope. Therefore, each address on this link must uniquely identify one interface on that link; for example, fe80::2 uniquely identifies the interface of the HOST 1A on Link #1.

In the paragraph above, I made a statement that these addresses are link-local addresses. How do I know they are link-local addresses? Because they begin with fe80::/10. Therefore, by looking at an IPv6 address, we can tell the scope of that address. It is especially easy when dealing with unicast addresses because they are either link-local scope or global scope. You will have to know the values of the scop field of multicast IPv6 addresses to determine their scope.

Note: Unique Local IPv6 unicast addresses are treated as having global scope. Also, the loopback address, ::1, is treated as having link-local scope. Finally, the unspecified address, ::, does not have any scope.

Now, let’s return to our diagram. On Link #2, we also have addresses fe80::1 and fe80::2. This is not a valid configuration in IPv4 because there is IP address conflict but, due to the scoped address architecture in IPv6, it is possible because Link #1 and Link #2 are two separate links, and these addresses have link-local scope.

IP Address Scope Zone

Let’s take it a step further. A scope is an abstract term, e.g., link, site, global. However, when dealing with a specific link, in a specific organization (site), on the planet earth (global), for example, then we use the term scope zone or simple zone. The RFC defines a zone as “a connected region of topology of a given scope.

Let this distinction between scope and zone sink in: A scope can be, say, a “department” but a zone is “HR department of Apple Inc., headquartered in America, located on earth.” Therefore, from our diagram above, I can say Link #1 is the zone of address fe80::2 assigned to HOST 1A while Link #2 is the zone of address fe80::2 assigned to HOST 2A.

What does this tell you? Looking at address fe80::2, for instance, we can tell the scope but we cannot tell the zone. This means that the zone of an address is not encoded in the address itself and that is why we can use the same address in different zones (HR department of Apple, HR department of Microsoft, etc.) of the same scope (“department”).

Zone Indices

Now that we have introduced this concept of zone, let me ask you a question: If the router in our diagram pings fe80::2, where will that traffic be received? HOST 1A or HOST 2A? The answer is that pinging fe80::2 is not sufficient in itself. We need a way to specify something like “ping fe80::2 on Link #1” or “ping fe80::2 on Link #2.” In IPv6, this is accomplished by assigning a zone index to each zone of the same scope to which a node is attached. This zone index must also be distinct to avoid ambiguity. For example, “Link #1” and “Link #2” can be zone indices in our diagram above. Therefore, with zone indices, an IPv6 address can be represented in the format:

A common way to represent the zone_id is through numerals, e.g., 1, 2. Another way will be to use interface names, e.g., eth0. Using our example above, the address fe80::2 can then be represented as fe80::2%1 (HOST 1A) and fe80::2%2 (HOST 2A). Another representation could be fe80::2%eth0 and fe80::2%eth1.Different vendors will implement the zone indices differently. Windows operating systems, for example, use the interface index of the interface as the zone_id for link-local addresses. You can view these interface indexes by issuing the netsh interface ipv6 show interface command in command prompt.

Notice that the index for my Wi-Fi adapter is 12, therefore the link-local address for that interface will have “12” as the zone_id, as shown below.

A few things to note about zones and zone indices:

  1. Zone indices are local to the node; therefore node#1 on a link may use “3” as the zone index for that zone while node#2 on the same link may use “eth0” as the zone index for the same zone.
  2. There is a single zone for the global scope because each global scope address must be unique. Therefore, it is not necessary to specify a zone index for a global scope address.

Let’s now take a practical example. I have a virtual machine running on my laptop with IPv6 enabled.

The Virtual Box interface on my laptop (host) is shown below:

The first thing I want you to notice is that the virtual machine uses a zone index of “5” for this link while my host system uses “39” for the same link. This demonstrates what I said about zone indices being local to the node. Now, let’s try to ping from the virtual machine without specifying a zone index:

Notice that this fails because the system is saying: “I have three interfaces with link-local addresses; what interface should I send this request out through?” I will now try to ping the same address, but this time, I will specify the zone index of 5.

Cool! By specifying the zone_id, we are able to ping that address.

Let’s take one more example that will simulate the diagram we have been using as an example. I will use Cisco routers in GNS3 because I can configure the link-local addresses manually, although link-local addresses are usually automatically assigned.

I have enabled IPv6 on the routers and configured their link-local addresses manually. Notice that both interfaces of R1 have the same link-local address but, because they are on different zones (of the same scope), it is fine. Also, the interfaces of R2 and R3 have the same link-local address of fe80::2.

I will now ping fe80::2 from R1 and see what happens.

As you can see, it asks me for the output interface, i.e., what interface it should send the request through. I will debug icmp for IPv6 (debug ipv6 icmp) on both R2 and R3 so we see the packets.

As expected, when the output interface is “fastethernet0/0,” it reaches R2, which replies, so we have a successful ping. Also, when the output interface is “fastethernet0/1,” then the packets reach R3 as shown below:

Therefore, our example diagram is actually a valid configuration in IPv6.


This brings us to the end of this article where we have looked at the IPv6 scoped addresses architecture. We talked about address scope, scope zone, and the zone indices. We saw that, because of this architecture, it is possible for the same IPv6 address to be used in different zones of the same scope.

In the next article, we will conclude our discussion on IPv6 addresses by looking at the IPv6 unicast address interface identifiers.

References and Further Reading

  1. RFC 4291: IP Version 6 Addressing Architecture: http://tools.ietf.org/html/rfc4291
  2. RFC 4007: IPv6 Scoped Address Architecture: http://tools.ietf.org/html/rfc4007
  3. Test IPv6 connectivity by using the ping command: http://technet.microsoft.com/en-us/library/cc739629(v=ws.10).aspx