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.
7. Sending Packets
When an upper-layer protocol sends a packet to a non-global
destination address, it must have a means of identifying the intended
zone to the IPv6 layer for cases in which the node is attached to
more than one zone of the destination address’s scope.
Although identification of an outgoing interface is sufficient to
identify an intended zone (because each interface is attached to no
more than one zone of each scope), in many cases that is more
specific than desired. For example, when sending to a link-local
unicast address from a node that has more than one interface to the
intended link (an unusual configuration), the upper layer protocol
may not care which of those interfaces is used for the transmission.
Rather, it would prefer to leave that choice to the routing function
in the IP layer. Thus, the upper-layer requires the ability to
specify a zone index, when sending to a non-global, non-loopback
destination address.
8. Receiving Packets
When an upper-layer protocol receives a packet containing a non-
global source or destination address, the zone to which that address
pertains can be determined from the arrival interface, because the
arrival interface can be attached to only one zone of the same scope
as that of the address under consideration. However, it is
recommended that the IP layer convey to the upper layer the correct
zone indices for the arriving source and destination addresses, in
addition to the arrival interface identifier.
9. Forwarding
When a router receives a packet addressed to a node other than
itself, it must take the zone of the destination and source addresses
into account as follows:
o The zone of the destination address is determined by the scope of
the address and arrival interface of the packet. The next-hop
interface is chosen by looking up the destination address in a
(conceptual) routing table specific to that zone (see Section 10).
That routing table is restricted to refer to interfaces belonging
to that zone.
o After the next-hop interface is chosen, the zone of the source
address is considered. As with the destination address, the zone
of the source address is determined by the scope of the address
and arrival interface of the packet. If transmitting the packet
on the chosen next-hop interface would cause the packet to leave
the zone of the source address, i.e., cross a zone boundary of the
scope of the source address, then the packet is discarded.
Additionally, if the packet’s destination address is a unicast
address, an ICMP Destination Unreachable message [4] with Code 2
("beyond scope of source address") is sent to the source of the
original packet. Note that Code 2 is currently left as unassigned
in [4], but the IANA will re-assign the value for the new purpose,
and [4] will be revised with this change.
Note that even if unicast site-local addresses are deprecated, the
above procedure still applies to link-local addresses. Thus, if a
router receives a packet with a link-local destination address that
is not one of the router’s own link-local addresses on the arrival
link, the router is expected to try to forward the packet to the
destination on that link (subject to successful determination of the
destination’s link-layer address via the Neighbor Discovery protocol
[9]). The forwarded packet may be transmitted back through the
arrival interface, or through any other interface attached to the
same link.
A node that receives a packet addressed to itself and containing a
Routing Header with more than zero Segments Left (Section 4.4 of [3])
first checks the scope of the next address in the Routing Header. If
the scope of the next address is smaller than the scope of the
original destination address, the node MUST discard the packet.
Otherwise, it swaps the original destination address with the next
address in the Routing Header. Then the above forwarding rules apply
as follows:
o The zone of the new destination address is determined by the scope
of the next address and the arrival interface of the packet. The
next-hop interface is chosen as per the first bullet of the rules
above.
o After the next-hop interface is chosen, the zone of the source
address is considered as per the second bullet of the rules above.
This check about the scope of the next address ensures that when a
packet arrives at its final destination, if that destination is
link-local, then the receiving node can know that the packet
originated on-link. This will help the receiving node send a
"response" packet with the final destination of the received packet
as the source address without breaking its source zone.
Note that it is possible, though generally inadvisable, to use a
Routing Header to convey a non-global address across its associated
zone boundary in the previously used next address field. For
example, consider a case in which a link-border node (e.g., a router)
receives a packet with the destination being a link-local address,
and the source address a global address. If the packet contains a
Routing Header where the next address is a global address, the next-
hop interface to the global address may belong to a different link
than that of the original destination. This is allowed because the
scope of the next address is not smaller than the scope of the
original destination.
10. Routing
Note that as unicast site-local addresses are deprecated, and link-
local addresses do not need routing, the discussion in this section
only applies to multicast scoped routing.
When a routing protocol determines that it is operating on a zone
boundary, it MUST protect inter-zone integrity and maintain intra-
zone connectivity.
To maintain connectivity, the routing protocol must be able to create
forwarding information for the global groups and for all the scoped
groups for each of its attached zones. The most straightforward way
of doing this is to create (conceptual) forwarding tables for each
specific zone.
To protect inter-zone integrity, routers must be selective in the
group information shared with neighboring routers. Routers routinely
exchange routing information with neighboring routers. When a router
is transmitting this routing information, it must not include any
information about zones other than the zones assigned to the
interface used to transmit the information.
* *
* *
* =========== Organization X *
* | | *
* | | *
+-*----|-------|------+ *
| * intf1 intf2 | *
| * | *
| * intf3 --- *
| * | *
| ***********************************
| |
| Router |
| |
********************** **********************
| * * |
Org. Y --- intf4 * * intf5 --- Org. Z
| * * |
********************** **********************
+---------------------+
Figure 4: Multi-Organization Multicast Router
As an example, the router in Figure 4 must exchange routing
information on five interfaces. The information exchanged is as
follows (for simplicity, multicast scopes smaller or larger than the
organization scope except global are not considered here):
o Interface 1
* All global groups
* All organization groups learned from Interfaces 1, 2, and 3
o Interface 2
* All global groups
* All organization groups learned from Interfaces 1, 2, and 3
o Interface 3
* All global groups
* All organization groups learned from Interfaces 1, 2, and 3
o Interface 4
* All global groups
* All organization groups learned from Interface 4
o Interface 5
* All global groups
* All organization groups learned from Interface 5
By imposing route exchange rules, zone integrity is maintained by
keeping all zone-specific routing information contained within the
zone.
11. Textual Representation
As already mentioned, to specify an IPv6 non-global address without
ambiguity, an intended scope zone should be specified as well. As a
common notation to specify the scope zone, an implementation SHOULD
support the following format:
<address>%<zone_id>
where
<address> is a literal IPv6 address,
<zone_id> is a string identifying the zone of the address, and
`%’ is a delimiter character to distinguish between <address> and
<zone_id>.
The following subsections describe detailed definitions, concrete
examples, and additional notes of the format.
11.1. Non-Global Addresses
The format applies to all kinds of unicast and multicast addresses of
non-global scope except the unspecified address, which does not have
a scope. The format is meaningless and should not be used for global
addresses. The loopback address belongs to the trivial link; i.e.,
the link attached to the loopback interface. Thus the format should
not be used for the loopback address, either. This document does not
specify the usage of the format when the <address> is the unspecified
address, as the address does not have a scope. This document,
however, does not prohibit an implementation from using the format
for those special addresses for implementation dependent purposes.
11.2. The <zone_id> Part
In the textual representation, the <zone_id> part should be able to
identify a particular zone of the address’s scope. Although a zone
index is expected to contain enough information to determine the
scope and to be unique among all scopes as described in Section 6,
the <zone_id> part of this format does not have to contain the scope.
This is because the <address> part should specify the appropriate
scope. This also means that the <zone_id> part does not have to be
unique among all scopes.
With this loosened property, an implementation can use a convenient
representation as <zone_id>. For example, to represent link index 2,
the implementation can simply use "2" as <zone_id>, which would be
more readable than other representations that contain the "link"
scope.
When an implementation interprets the format, it should construct the
"full" zone index, which contains the scope, from the <zone_id> part
and the scope specified by the <address> part. (Remember that a zone
index itself should contain the scope, as specified in Section 6.)
An implementation SHOULD support at least numerical indices that are
non-negative decimal integers as <zone_id>. The default zone index,
which should typically be 0 (see Section 6), is included in the
integers. When <zone_id> is the default, the delimiter characters
"%" and <zone_id> can be omitted. Similarly, if a textual
representation of an IPv6 address is given without a zone index, it
should be interpreted as <address>%<default ID>, where <default ID>
is the default zone index of the scope that <address> has.
An implementation MAY support other kinds of non-null strings as
<zone_id>. However, the strings must not conflict with the delimiter
character. The precise format and semantics of additional strings is
implementation dependent.
One possible candidate for these strings would be interface names, as
interfaces uniquely disambiguate any scopes. In particular,
interface names can be used as "default identifiers" for interfaces
and links, because by default there is a one-to-one mapping between
interfaces and each of those scopes as described in Section 6.
An implementation could also use interface names as <zone_id> for
scopes larger than links, but there might be some confusion in this
use. For example, when more than one interface belongs to the same
(multicast) site, a user would be confused about which interface
should be used. Also, a mapping function from an address to a name
would encounter the same kind of problem when it prints an address
with an interface name as a zone index. This document does not
specify how these cases should be treated and leaves it
implementation dependent.
It cannot be assumed that indices are common across all nodes in a
zone (see Section 6). Hence, the format MUST be used only within a
node and MUST NOT be sent on the wire unless every node that
interprets the format agrees on the semantics.
11.3. Examples
The following addresses
fe80::1234 (on the 1st link of the node)
ff02::5678 (on the 5th link of the node)
ff08::9abc (on the 10th organization of the node)
would be represented as follows:
fe80::1234%1
ff02::5678%5
ff08::9abc%10
(Here we assume a natural translation from a zone index to the
<zone_id> part, where the Nth zone of any scope is translated into
"N".)
If we use interface names as <zone_id>, those addresses could also be
represented as follows:
fe80::1234%ne0
ff02::5678%pvc1.3
ff08::9abc%interface10
where the interface "ne0" belongs to the 1st link, "pvc1.3" belongs
to the 5th link, and "interface10" belongs to the 10th organization.
11.4. Usage Examples
Applications that are supposed to be used in end hosts such as
telnet, ftp, and ssh may not explicitly support the notion of address
scope, especially of link-local addresses. However, an expert user
(e.g., a network administrator) sometimes has to give even link-local
addresses to such applications.
Here is a concrete example. Consider a multi-linked router called
"R1" that has at least two point-to-point interfaces (links). Each
of the interfaces is connected to another router, "R2" and "R3",
respectively. Also assume that the point-to-point interfaces have
link-local addresses only.
Now suppose that the routing system on R2 hangs up and has to be
reinvoked. In this situation, we may not be able to use a global
address of R2, because this is routing trouble and we cannot expect
to have enough routes for global reachability to R2.
Hence, we have to login R1 first and then try to login R2 by using
link-local addresses. In this case, we have to give the link-local
address of R2 to, for example, telnet. Here we assume the address is
fe80::2.
Note that we cannot just type
% telnet fe80::2
here, since R1 has more than one link and hence the telnet command
cannot detect which link it should try to use for connecting.
Instead, we should type the link-local address with the link index as
follows:
% telnet fe80::2%3
where "3" after the delimiter character `%’ corresponds to the link
index of the point-to-point link.
11.5. Related API
An extension to the recommended basic API defines how the format for
non-global addresses should be treated in library functions that
translate a nodename to an address, or vice versa [11].
11.6. Omitting Zone Indices
The format defined in this document does not intend to invalidate the
original format for non-global addresses; that is, the format without
the zone index portion. As described in Section 6, in some common
cases with the notion of the default zone index, there can be no
ambiguity about scope zones. In such an environment, the
implementation can omit the "%<zone_id>" part. As a result, it can
act as though it did not support the extended format at all.
11.7. Combinations of Delimiter Characters
There are other kinds of delimiter characters defined for IPv6
addresses. In this subsection, we describe how they should be
combined with the format for non-global addresses.
The IPv6 addressing architecture [1] also defines the syntax of IPv6
prefixes. If the address portion of a prefix is non-global and its
scope zone should be disambiguated, the address portion SHOULD be in
the format. For example, a link-local prefix fe80::/64 on the second
link can be represented as follows:
fe80::%2/64
In this combination, it is important to place the zone index portion
before the prefix length when we consider parsing the format by a
name-to-address library function [11]. That is, we can first
separate the address with the zone index from the prefix length, and
just pass the former to the library function.
The preferred format for literal IPv6 addresses in URLs is also
defined [12]. When a user types the preferred format for an IPv6
non-global address whose zone should be explicitly specified, the
user could use the format for the non-global address combined with
the preferred format.
However, the typed URL is often sent on the wire, and it would cause