6. Zone Indices
6. Zone Indices
Because the same non-global address may be in use in more than one zone of the same scope (e.g., the use of link-local address fe80::1 in two separate physical links) and a node may have interfaces attached to different zones of the same scope (e.g., a router normally has multiple interfaces attached to different links), a node requires an internal means to identify to which zone a non-global address belongs. This is accomplished by assigning, within the node, a distinct "zone index" to each zone of the same scope to which that node is attached, and by allowing all internal uses of an address to be qualified by a zone index.
The assignment of zone indices is illustrated in the example in the figure below:
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| |
| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link)
Figure 1: Zone Indices Example
This example node has five interfaces:
-
A loopback interface to the imaginary loopback link (a phantom link that goes nowhere).
-
Two interfaces to the same Ethernet link.
-
An interface to a point-to-point link.
-
A tunnel interface (e.g., the abstract endpoint of an IPv6-over-IPv6 tunnel [8], presumably established over either the Ethernet or the point-to-point link).
It is thus attached to five interface-local zones, identified by the interface indices 1 through 5.
Because the two Ethernet interfaces are attached to the same link, the node is only attached to four link-local zones, identified by link indices 1 through 4. Also note that even if the tunnel interface is established over the Ethernet, the tunnel link gets its own link index, which is different from the index of the Ethernet link zone.
Each zone index of a particular scope should contain enough information to indicate the scope, so that all indices of all scopes are unique within the node and zone indices themselves can be used for a dedicated purpose. Usage of the index to identify an entry in the Management Information Base (MIB) is an example of the dedicated purpose. The actual representation to encode the scope is implementation dependent and is out of scope of this document. Within this document, indices are simply represented in a format such as "link index 2" for readability.
The zone indices are strictly local to the node. For example, the node on the other end of the point-to-point link may well use entirely different interface and link index values for that link.
An implementation should also support the concept of a "default" zone for each scope. And, when supported, the index value zero at each scope SHOULD be reserved to mean "use the default zone". Unlike other zone indices, the default index does not contain any scope, and the scope is determined by the address that the default index accompanies. An implementation may additionally define a separate default zone for each scope. Those default indices can also be used as the zone qualifier for an address for which the node is attached to only one zone; e.g., when using global addresses.
At present, there is no way for a node to automatically determine which of its interfaces belong to the same zones; e.g., the same link or the same multicast scope zone larger than interface. In the future, protocols may be developed to determine that information. In the absence of such protocols, an implementation must provide a means for manual assignment and/or reassignment of zone indices. Furthermore, to avoid performing manual configuration in most cases, an implementation should, by default, initially assign zone indices only as follows:
-
A unique interface index for each interface.
-
A unique link index for each interface.
Then manual configuration would only be necessary for the less common cases of nodes with multiple interfaces to a single link or of those with interfaces to zones of different (multicast-only) scopes.
Thus, the default zone index assignments for the example node from Figure 1 would be as illustrated in Figure 2, below. Manual configuration would then be required to, for example, assign the same link index to the two Ethernet interfaces, as shown in Figure 1.
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link)
Figure 2: Example of Default Zone Indices
As well as initially assigning zone indices, as specified above, an implementation should automatically select a default zone for each scope for which there is more than one choice, to be used whenever an address is specified without a zone index (or with a zone index of zero). For instance, in the example shown in Figure 2, the implementation might automatically select intf2 and link2 as the default zones for each of those two scopes. (One possible selection algorithm is to choose the first zone that includes an interface other than the loopback interface as the default for each scope.) A means must also be provided to assign the default zone for a scope manually, overriding any automatic assignment.
The unicast loopback address, ::1, may not be assigned to any interface other than the loopback interface. Therefore, it is recommended that, whenever ::1 is specified without a zone index or with the default zone index, it be interpreted as belonging to the loopback link-local zone, regardless of which link-local zone has been selected as the default. If this is done, then for nodes with only a single non-loopback interface (e.g., a single Ethernet interface), the common case, link-local addresses need not be qualified with a zone index. The unqualified address ::1 would always refer to the link-local zone containing the loopback interface. All other unqualified link-local addresses would refer to the link-local zone containing the non-loopback interface (as long as the default link-local zone was set to be the zone containing the non-loopback interface).
Because of the requirement that a zone of a given scope fall completely within zones of larger scope (see Section 5, above), two interfaces assigned to different zones of scope S must also be assigned to different zones of all scopes smaller than S. Thus, the manual assignment of distinct zone indices for one scope may require the automatic assignment of distinct zone indices for smaller scopes. For example, suppose that distinct multicast site-local indices 1 and 2 are manually assigned in Figure 1 and that site 1 contains links 1, 2, and 3, but site 2 only contains link 4. This configuration would cause the automatic creation of corresponding admin-local (i.e., multicast "scop" value 4) indices 1 and 2, because admin-local scope is smaller than site-local scope.
With the above considerations, the complete set of zone indices for our example node from Figure 1, with the additional configurations here, is shown in Figure 3, below.
---------------------------------------------------------------
| a node |
| |
| |
| |
| |
| |
| /--------------------site1--------------------\ /--site2--\ |
| |
| /-------------------admin1--------------------\ /-admin2--\ |
| |
| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
| |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
---------------------------------------------------------------
: | | | |
: | | | |
: | | | |
(imaginary ================= a point- a
loopback an Ethernet to-point tunnel
link) link)
Figure 3: Complete Zone Indices Example
Although the above examples show the zones being assigned index values sequentially for each scope, starting at one, the zone index values are arbitrary. An implementation may label a zone with any value it chooses, as long as the index value of each zone of all scopes is unique within the node. Zero SHOULD be reserved to represent the default zone. Implementations choosing to follow the recommended basic API [10] will want to restrict their index values to those that can be represented by the sin6_scope_id field of the sockaddr_in6 structure.