Request for Comments: 4007 Cisco Systems
Category: Standards Track B. Haberman
Johns Hopkins Univ
T. Jinmei
Toshiba
E. Nordmark
Sun Microsystems
B. Zill
Microsoft
March 2005
IPv6 Scoped Address Architecture
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies the architectural characteristics, expected
behavior, textual representation, and usage of IPv6 addresses of
different scopes. According to a decision in the IPv6 working group,
this document intentionally avoids the syntax and usage of unicast
site-local addresses.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 3
4. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 3
5. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 11
8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 11
9. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Textual Representation . . . . . . . . . . . . . . . . . . . 15
11.1. Non-Global Addresses . . . . . . . . . . . . . . . . 15
11.2. The <zone_id> Part. . . . . . . . . . . . . . . . . . 15
11.3. Examples. . . . . . . . . . . . . . . . . . . . . . . 17
11.4. Usage Examples. . . . . . . . . . . . . . . . . . . . 17
11.5. Related API . . . . . . . . . . . . . . . . . . . . . 18
11.6. Omitting Zone Indices . . . . . . . . . . . . . . . . 18
11.7. Combinations of Delimiter Characters. . . . . . . . . 18
12. Security Considerations . . . . . . . . . . . . . . . . . . 19
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
15.1. Normative References . . . . . . . . . . . . . . . . . 20
15.2. Informative References . . . . . . . . . . . . . . . . 21
Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
Internet Protocol version 6 includes support for addresses of
different "scope"; that is, both global and non-global (e.g., link-
local) addresses. Although non-global addressing has been introduced
operationally in the IPv4 Internet, both in the use of private
address space ("net 10", etc.) and with administratively scoped
multicast addresses, the design of IPv6 formally incorporates the
notion of address scope into its base architecture. This document
specifies the architectural characteristics, expected behavior,
textual representation, and usage of IPv6 addresses of different
scopes.
Though the current address architecture specification [1] defines
unicast site-local addresses, the IPv6 working group decided to
deprecate the syntax and the usage [5] and is now investigating other
forms of local IPv6 addressing. The usage of any new forms of
local addresses will be documented elsewhere in the future. Thus,
this document intentionally focuses on link-local and multicast
scopes only.
2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2].
3. Basic Terminology
The terms link, interface, node, host, and router are defined in [3].
The definitions of unicast address scopes (link-local and global) and
multicast address scopes (interface-local, link-local, etc.) are
contained in [1].
4. Address Scope
Every IPv6 address other than the unspecified address has a specific
scope; that is, a topological span within which the address may be
used as a unique identifier for an interface or set of interfaces.
The scope of an address is encoded as part of the address, as
specified in [1].
For unicast addresses, this document discusses two defined scopes:
o Link-local scope, for uniquely identifying interfaces within
(i.e., attached to) a single link only.
o Global scope, for uniquely identifying interfaces anywhere in the
Internet.
The IPv6 unicast loopback address, ::1, is treated as having link-
local scope within an imaginary link to which a virtual "loopback
interface" is attached.
The unspecified address, ::, is a special case. It does not have any
scope because it must never be assigned to any node according to [1].
Note, however, that an implementation might use an implementation
dependent semantics for the unspecified address and may want to allow
the unspecified address to have specific scopes. For example,
implementations often use the unspecified address to represent "any"
address in APIs. In this case, implementations may regard the
unspecified address with a given particular scope as representing the
notion of "any address in the scope". This document does not
prohibit such a usage, as long as it is limited within the
implementation.
[1] defines IPv6 addresses with embedded IPv4 addresses as being part
of global addresses. Thus, those addresses have global scope, with
regard to the IPv6 scoped address architecture. However, an
implementation may use those addresses as if they had other scopes
for convenience. For instance, [6] assigns link-local scope to IPv4
auto-configured link-local addresses (the addresses from the prefix
169.254.0.0/16 [7]) and converts those addresses into IPv4-mapped
IPv6 addresses in order to perform destination address selection
among IPv4 and IPv6 addresses. This would implicitly mean that the
IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration
link-local addresses have link-local scope. This document does not
preclude such a usage, as long as it is limited within the
implementation.
Anycast addresses [1] are allocated from the unicast address space
and have the same scope properties as unicast addresses. All
statements in this document regarding unicast apply equally to
anycast.
For multicast addresses, there are fourteen possible scopes, ranging
from interface-local to global (including link-local). The
interface-local scope spans a single interface only; a multicast
address of interface-local scope is useful only for loopback delivery
of multicasts within a single node; for example, as a form of inter-
process communication within a computer. Unlike the unicast loopback
address, interface-local multicast addresses may be assigned to any
interface.
There is a size relationship among scopes:
o For unicast scopes, link-local is a smaller scope than global.
o For multicast scopes, scopes with lesser values in the "scop"
subfield of the multicast address (Section 2.7 of [1]) are smaller
than scopes with greater values, with interface-local being the
smallest and global being the largest.
However, two scopes of different size may cover the exact same region
of topology. For example, a (multicast) site may consist of a single
link, in which both link-local and site-local scope effectively cover
the same topological span.
5. Scope Zones
A scope zone, or simply a zone, is a connected region of topology of
a given scope. For example, the set of links connected by routers
within a particular (multicast) site, and the interfaces attached to
those links, comprise a single zone of multicast site-local scope.
Note that a zone is a particular instance of a topological region
(e.g., Alice’s site or Bob’s site), whereas a scope is the size of a
topological region (e.g., a site or a link).
The zone to which a particular non-global address pertains is not
encoded in the address itself but determined by context, such as the
interface from which it is sent or received. Thus, addresses of a
given (non-global) scope may be re-used in different zones of that
scope. For example, two different physical links may each contain a
node with the link-local address fe80::1.
Zones of the different scopes are instantiated as follows:
o Each interface on a node comprises a single zone of interface-
local scope (for multicast only).
o Each link and the interfaces attached to that link comprise a
single zone of link-local scope (for both unicast and multicast).
o There is a single zone of global scope (for both unicast and
multicast) comprising all the links and interfaces in the
Internet.
o The boundaries of zones of a scope other than interface-local,
link-local, and global must be defined and configured by network
administrators.
Zone boundaries are relatively static features, not changing in
response to short-term changes in topology. Thus, the requirement
that the topology within a zone be "connected" is intended to include
links and interfaces that may only be occasionally connected. For
example, a residential node or network that obtains Internet access
by dial-up to an employer’s (multicast) site may be treated as part
of the employer’s (multicast) site-local zone even when the dial-up
link is disconnected. Similarly, a failure of a router, interface,
or link that causes a zone to become partitioned does not split that
zone into multiple zones. Rather, the different partitions are still
considered to belong to the same zone.
Zones have the following additional properties:
o Zone boundaries cut through nodes, not links. (Note that the
global zone has no boundary, and the boundary of an interface-
local zone encloses just a single interface.)
o Zones of the same scope cannot overlap; i.e., they can have no
links or interfaces in common.
o A zone of a given scope (less than global) falls completely within
zones of larger scope. That is, a smaller scope zone cannot
include more topology than would any larger scope zone with which
it shares any links or interfaces.
o Each zone is required to be "convex" from a routing perspective;
i.e., packets sent from one interface to any other in the same
zone are never routed outside the zone. Note, however, that if a
zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link
[8]), a lower layer network of the tunnel can be located outside
the zone without breaking the convexity property.
Each interface belongs to exactly one zone of each possible scope.
Note that this means that an interface belongs to a scope zone
regardless of what kind of unicast address the interface has or of
which multicast groups the node joins on the interface.
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:
o A unique interface index for each interface.
o 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