draft-ietf-ipv6-scoping-arch-02.txt   rfc4007.txt 
IETF IPv6 Working Group S. Deering Network Working Group S. Deering
Internet-Draft Cisco Systems Request for Comments: 4007 Cisco Systems
Expires: February 18, 2005 B. Haberman Category: Standards Track B. Haberman
Johns Hopkins Univ Johns Hopkins Univ
T. Jinmei T. Jinmei
Toshiba Toshiba
E. Nordmark E. Nordmark
Sun Microsystems Sun Microsystems
B. Zill B. Zill
Microsoft Microsoft
August 20, 2004 March 2005
IPv6 Scoped Address Architecture IPv6 Scoped Address Architecture
draft-ietf-ipv6-scoping-arch-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 18, 2005. 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 Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies the architectural characteristics, expected This document specifies the architectural characteristics, expected
behavior, textual representation, and usage of IPv6 addresses of behavior, textual representation, and usage of IPv6 addresses of
different scopes. According to a decision in the IPv6 working group, different scopes. According to a decision in the IPv6 working group,
this document intentionally avoids using the syntax and usage of this document intentionally avoids the syntax and usage of unicast
unicast site-local addresses. site-local addresses.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 3 3. Basic Terminology . . . . . . . . . . . . . . . . . . . . . 3
4. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 3 4. Address Scope . . . . . . . . . . . . . . . . . . . . . . . 3
5. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Scope Zones . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Zone Indices . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 11 7. Sending Packets . . . . . . . . . . . . . . . . . . . . . . 11
8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 11 8. Receiving Packets . . . . . . . . . . . . . . . . . . . . . 11
9. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11
10. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11. Textual Representation . . . . . . . . . . . . . . . . . . . 15 11. Textual Representation . . . . . . . . . . . . . . . . . . . 15
11.1 Non-Global Addresses . . . . . . . . . . . . . . . . . . 15 11.1. Non-Global Addresses . . . . . . . . . . . . . . . . 15
11.2 The <zone_id> Part . . . . . . . . . . . . . . . . . . . 15 11.2. The <zone_id> Part. . . . . . . . . . . . . . . . . . 15
11.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . 17 11.3. Examples. . . . . . . . . . . . . . . . . . . . . . . 17
11.4 Usage Examples . . . . . . . . . . . . . . . . . . . . . 17 11.4. Usage Examples. . . . . . . . . . . . . . . . . . . . 17
11.5 Related API . . . . . . . . . . . . . . . . . . . . . . 18 11.5. Related API . . . . . . . . . . . . . . . . . . . . . 18
11.6 Omitting Zone Indices . . . . . . . . . . . . . . . . . 18 11.6. Omitting Zone Indices . . . . . . . . . . . . . . . . 18
11.7 Combinations of Delimiter Characters . . . . . . . . . . 18 11.7. Combinations of Delimiter Characters. . . . . . . . . 18
12. Security Considerations . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 20 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 15.1. Normative References . . . . . . . . . . . . . . . . . 20
16.1 Normative References . . . . . . . . . . . . . . . . . . . 20 15.2. Informative References . . . . . . . . . . . . . . . . 21
16.2 Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 24
Intellectual Property and Copyright Statements . . . . . . . 23
1. Introduction 1. Introduction
Internet Protocol version 6 includes support for addresses of Internet Protocol version 6 includes support for addresses of
different "scope", that is, both global and non-global (e.g., different "scope"; that is, both global and non-global (e.g., link-
link-local) addresses. While non-global addressing has been local) addresses. Although non-global addressing has been introduced
introduced operationally in the IPv4 Internet, both in the use of operationally in the IPv4 Internet, both in the use of private
private address space ("net 10", etc.) and with administratively address space ("net 10", etc.) and with administratively scoped
scoped multicast addresses, the design of IPv6 formally incorporates multicast addresses, the design of IPv6 formally incorporates the
the notion of address scope into its base architecture. This notion of address scope into its base architecture. This document
document specifies the architectural characteristics, expected specifies the architectural characteristics, expected behavior,
behavior, textual representation, and usage of IPv6 addresses of textual representation, and usage of IPv6 addresses of different
different scopes. scopes.
Though the current address architecture specification [1] defines Though the current address architecture specification [1] defines
unicast site-local addresses, the IPv6 working group decided to unicast site-local addresses, the IPv6 working group decided to
deprecate the syntax and the usage [5], and is now investigating deprecate the syntax and the usage [5] and is now investigating other
other forms of local IPv6 addressing. The usage of any new forms of forms of local IPv6 addressing. The usage of any new forms of
local addresses will be documented elsewhere in the future. Thus, local addresses will be documented elsewhere in the future. Thus,
this document intentionally focuses on link-local and multicast this document intentionally focuses on link-local and multicast
scopes only. scopes only.
2. Definitions 2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [2]. document are to be interpreted as described in [2].
3. Basic Terminology 3. Basic Terminology
The terms link, interface, node, host, and router are defined in [3]. The terms link, interface, node, host, and router are defined in [3].
The definitions of unicast address scopes (link-local and global) and The definitions of unicast address scopes (link-local and global) and
multicast address scopes (interface-local, link-local, etc.) are multicast address scopes (interface-local, link-local, etc.) are
contained in [1]. contained in [1].
4. Address Scope 4. Address Scope
Every IPv6 address other than the unspecified address has a specific Every IPv6 address other than the unspecified address has a specific
scope, that is, a topological span within which the address may be scope; that is, a topological span within which the address may be
used as a unique identifier for an interface or set of interfaces. 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 The scope of an address is encoded as part of the address, as
specified in [1]. specified in [1].
For unicast addresses, this document discusses two defined scopes: For unicast addresses, this document discusses two defined scopes:
o Link-local scope, for uniquely identifying interfaces within o Link-local scope, for uniquely identifying interfaces within
(i.e., attached to) a single link only. (i.e., attached to) a single link only.
o Global scope, for uniquely identifying interfaces anywhere in the o Global scope, for uniquely identifying interfaces anywhere in the
Internet. Internet.
The IPv6 unicast loopback address, ::1, is treated as having link- The IPv6 unicast loopback address, ::1, is treated as having link-
local scope within an imaginary link to which a virtual "loopback local scope within an imaginary link to which a virtual "loopback
interface" is attached. interface" is attached.
The unspecified address, ::, is a special case. It does not have any The unspecified address, ::, is a special case. It does not have any
scope, because it must never be assigned to any node according to scope because it must never be assigned to any node according to [1].
[1]. Note, however, that an implementation might use an Note, however, that an implementation might use an implementation
implementation dependent semantics for the unspecified address and dependent semantics for the unspecified address and may want to allow
may want to allow the unspecified address to have specific scopes. the unspecified address to have specific scopes. For example,
For example, implementations often use the unspecified address to implementations often use the unspecified address to represent "any"
represent "any" address in APIs. In such a case, implementations may address in APIs. In this case, implementations may regard the
want to regard the address in a particular scope to represent the unspecified address with a given particular scope as representing the
notion of "any addresses in the scope." This document does not notion of "any address in the scope". This document does not
prohibit such a usage, as long as it is limited within the prohibit such a usage, as long as it is limited within the
implementation. implementation.
[1] defines IPv6 addresses with embedded IPv4 addresses as part of [1] defines IPv6 addresses with embedded IPv4 addresses as being part
global addresses. Thus, those addresses have global scope, with of global addresses. Thus, those addresses have global scope, with
regards to the IPv6 scoped address architecture. However, an regard to the IPv6 scoped address architecture. However, an
implementation may use those addresses as if they had other scopes implementation may use those addresses as if they had other scopes
for convenience. For instance, [6] assigns link-local scope to IPv4 for convenience. For instance, [6] assigns link-local scope to IPv4
auto-configured link-local addresses (the addresses from the prefix auto-configured link-local addresses (the addresses from the prefix
169.254.0.0/16 [7]), and converts those addresses into IPv4-mapped 169.254.0.0/16 [7]) and converts those addresses into IPv4-mapped
IPv6 addresses in order to perform destination address selection IPv6 addresses in order to perform destination address selection
among IPv4 and IPv6 addresses. This would implicitly mean the among IPv4 and IPv6 addresses. This would implicitly mean that the
IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration IPv4-mapped IPv6 addresses equivalent to the IPv4 auto-configuration
link-local addresses have link-local scope. This document does not link-local addresses have link-local scope. This document does not
preclude such a usage, as long as it is limited within the preclude such a usage, as long as it is limited within the
implementation. implementation.
Anycast addresses [1] are allocated from the unicast address space Anycast addresses [1] are allocated from the unicast address space
and have the same scope properties as unicast addresses. All and have the same scope properties as unicast addresses. All
statements in this document regarding unicast apply equally to statements in this document regarding unicast apply equally to
anycast. anycast.
For multicast addresses, there are fourteen possible scopes, ranging For multicast addresses, there are fourteen possible scopes, ranging
from interface-local to global (including link-local). The from interface-local to global (including link-local). The
interface-local scope spans a single interface only; a multicast interface-local scope spans a single interface only; a multicast
address of interface-local scope is useful only for loopback delivery address of interface-local scope is useful only for loopback delivery
of multicasts within a single node, for example, as a form of of multicasts within a single node; for example, as a form of inter-
inter-process communication within a computer. Unlike the unicast process communication within a computer. Unlike the unicast loopback
loopback address, interface-local multicast addresses may be assigned address, interface-local multicast addresses may be assigned to any
to any interface. interface.
There is a size relationship among scopes: There is a size relationship among scopes:
o for unicast scopes, link-local is a smaller scope than global. o For unicast scopes, link-local is a smaller scope than global.
o for multicast scopes, scopes with lesser values in the "scop" o For multicast scopes, scopes with lesser values in the "scop"
subfield of the multicast address (Section 2.7 of [1]) are smaller subfield of the multicast address (Section 2.7 of [1]) are smaller
than scopes with greater values, with interface-local being the than scopes with greater values, with interface-local being the
smallest and global being the largest. smallest and global being the largest.
However, two scopes of different size may cover the exact same region However, two scopes of different size may cover the exact same region
of topology. For example, a (multicast) site may consist of a single of topology. For example, a (multicast) site may consist of a single
link, in which both link-local and site-local scope effectively cover link, in which both link-local and site-local scope effectively cover
the same topological span. the same topological span.
5. Scope Zones 5. Scope Zones
skipping to change at page 5, line 23 skipping to change at page 5, line 4
of topology. For example, a (multicast) site may consist of a single of topology. For example, a (multicast) site may consist of a single
link, in which both link-local and site-local scope effectively cover link, in which both link-local and site-local scope effectively cover
the same topological span. the same topological span.
5. Scope Zones 5. Scope Zones
A scope zone, or simply a zone, is a connected region of topology of 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 a given scope. For example, the set of links connected by routers
within a particular (multicast) site, and the interfaces attached to within a particular (multicast) site, and the interfaces attached to
those links, comprise a single zone of multicast site-local scope. those links, comprise a single zone of multicast site-local scope.
Note that a zone is a particular instance of a topological region 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 (e.g., Alice's site or Bob's site), whereas a scope is the size of a
topological region (i.e., a site or a link or a ...). topological region (e.g., a site or a link).
The zone to which a particular non-global address pertains is not The zone to which a particular non-global address pertains is not
encoded in the address itself, but rather is determined by context, encoded in the address itself but determined by context, such as the
such as the interface from which it is sent or received. Thus, interface from which it is sent or received. Thus, addresses of a
addresses of a given (non-global) scope may be re-used in different given (non-global) scope may be re-used in different zones of that
zones of that scope. For example, two different physical links may scope. For example, two different physical links may each contain a
each contain a node with link-local address fe80::1. node with the link-local address fe80::1.
Zones of the different scopes are instantiated as follows: Zones of the different scopes are instantiated as follows:
o Each interface on a node comprises a single zone of o Each interface on a node comprises a single zone of interface-
interface-local scope (for multicast only). local scope (for multicast only).
o Each link, and the interfaces attached to that link, comprises a o Each link and the interfaces attached to that link comprise a
single zone of link-local scope (for both unicast and multicast). single zone of link-local scope (for both unicast and multicast).
o There is a single zone of global scope (for both unicast and o There is a single zone of global scope (for both unicast and
multicast), comprising all the links and interfaces in the multicast) comprising all the links and interfaces in the
Internet. Internet.
o The boundaries of zones of scope other than interface-local, o The boundaries of zones of a scope other than interface-local,
link-local, and global must be defined and configured by network link-local, and global must be defined and configured by network
administrators. administrators.
Zone boundaries are relatively static features, not changing in Zone boundaries are relatively static features, not changing in
response to short-term changes in topology. Thus, the requirement response to short-term changes in topology. Thus, the requirement
that the topology within a zone be "connected" is intended to include that the topology within a zone be "connected" is intended to include
links and interfaces that may be only occasionally connected. For links and interfaces that may only be occasionally connected. For
example, a residential node or network that obtains Internet access example, a residential node or network that obtains Internet access
by dial-up to an employer's (multicast) site may be treated as part 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 of the employer's (multicast) site-local zone even when the dial-up
link is disconnected. Similarly, a failure of a router, interface, link is disconnected. Similarly, a failure of a router, interface,
or link that causes a zone to become partitioned does not split that or link that causes a zone to become partitioned does not split that
zone into multiple zones; rather, the different partitions are still zone into multiple zones. Rather, the different partitions are still
considered to belong to the same zone. considered to belong to the same zone.
Zones have the following additional properties: Zones have the following additional properties:
o Zone boundaries cut through nodes, not links. (Note that the o Zone boundaries cut through nodes, not links. (Note that the
global zone has no boundary, and the boundary of an global zone has no boundary, and the boundary of an interface-
interface-local zone encloses just a single interface.) local zone encloses just a single interface.)
o Zones of the same scope cannot overlap, i.e., they can have no o Zones of the same scope cannot overlap; i.e., they can have no
links or interfaces in common. links or interfaces in common.
o A zone of a given scope (less than global) falls completely within o A zone of a given scope (less than global) falls completely within
zones of larger scope, i.e., a smaller scope zone cannot include zones of larger scope. That is, a smaller scope zone cannot
more topology than any larger scope zone with which it shares any include more topology than would any larger scope zone with which
links or interfaces. it shares any links or interfaces.
o Each zone is required to be "convex" from a routing perspective, o Each zone is required to be "convex" from a routing perspective;
i.e., packets sent from one interface to any other interface in i.e., packets sent from one interface to any other in the same
the same zone are never routed outside the zone. Note, however, zone are never routed outside the zone. Note, however, that if a
that if a zone contains a tunneled link (e.g., an IPv6-over-IPv6 zone contains a tunneled link (e.g., an IPv6-over-IPv6 tunnel link
tunnel link [8]), a lower layer network of the tunnel can be [8]), a lower layer network of the tunnel can be located outside
located outside the zone without breaking the convexity property. the zone without breaking the convexity property.
Each interface belongs to exactly one zone of each possible scope. Each interface belongs to exactly one zone of each possible scope.
Note that this means an interface belongs to a scope zone regardless Note that this means that an interface belongs to a scope zone
of what kind of unicast address the interface has or of which regardless of what kind of unicast address the interface has or of
multicast groups the node joins on the interface. which multicast groups the node joins on the interface.
6. Zone Indices 6. Zone Indices
Considering the fact that the same non-global address may be in use Because the same non-global address may be in use in more than one
in more than one zone of the same scope (e.g., the use of link-local zone of the same scope (e.g., the use of link-local address fe80::1
address fe80::1 in two separate physical links), and that a node may in two separate physical links) and a node may have interfaces
have interfaces attached to different zones of the same scope (e.g., attached to different zones of the same scope (e.g., a router
a router normally has multiple interfaces attached to different normally has multiple interfaces attached to different links), a node
links), a node requires an internal means of identifying to which requires an internal means to identify to which zone a non-global
zone a non-global address belongs. This is accomplished by address belongs. This is accomplished by assigning, within the node,
assigning, within the node, a distinct "zone index" to each zone of a distinct "zone index" to each zone of the same scope to which that
the same scope to which that node is attached, and allowing all node is attached, and by allowing all internal uses of an address to
internal uses of an address to be qualified by a zone index. be qualified by a zone index.
The assignment of zone indices is illustrated in the example in the The assignment of zone indices is illustrated in the example in the
figure below: figure below:
--------------------------------------------------------------- ---------------------------------------------------------------
| a node | | a node |
| | | |
| | | |
| | | |
| | | |
skipping to change at page 7, line 29 skipping to change at page 7, line 32
: | | | | : | | | |
(imaginary ================= a point- a (imaginary ================= a point- a
loopback an Ethernet to-point tunnel loopback an Ethernet to-point tunnel
link) link link) link
Figure 1: Zone Indices Example Figure 1: Zone Indices Example
This example node has five interfaces: This example node has five interfaces:
A loopback interface to the imaginary loopback link (a phantom A loopback interface to the imaginary loopback link (a phantom
link that goes nowhere), link that goes nowhere).
Two interfaces to the same Ethernet link, Two interfaces to the same Ethernet link.
An interface to a point-to-point link, and An interface to a point-to-point link.
A tunnel interface (e.g., the abstract endpoint of an A tunnel interface (e.g., the abstract endpoint of an IPv6-over-
IPv6-over-IPv6 tunnel [8], presumably established over either the IPv6 tunnel [8], presumably established over either the Ethernet
Ethernet or the point-to-point link.) or the point-to-point link).
It is thus attached to five interface-local zones, identified by the It is thus attached to five interface-local zones, identified by the
interface indices 1 through 5. interface indices 1 through 5.
Because the two Ethernet interfaces are attached to the same link, Because the two Ethernet interfaces are attached to the same link,
the node is attached to only four link-local zones, identified by the node is only attached to four link-local zones, identified by
link indices 1 through 4. Also note that even if the tunnel link indices 1 through 4. Also note that even if the tunnel
interface is established over the Ethernet, the tunnel link gets its interface is established over the Ethernet, the tunnel link gets its
own link index, which is different from the index of the Ethernet own link index, which is different from the index of the Ethernet
link zone. link zone.
Each zone index of a particular scope should contain enough Each zone index of a particular scope should contain enough
information to allow the determination of the scope, so that all information to indicate the scope, so that all indices of all scopes
indices of all scopes are unique within the node and zone indices are unique within the node and zone indices themselves can be used
themselves can be used for a dedicated purpose. Usage of the index for a dedicated purpose. Usage of the index to identify an entry in
to identify an entry in the Management Information Base (MIB) is an the Management Information Base (MIB) is an example of the dedicated
example of the dedicated purpose. The actual representation to purpose. The actual representation to encode the scope is
encode the scope is implementation dependent and is out of scope of implementation dependent and is out of scope of this document.
this document. Within this document, indices are simply represented Within this document, indices are simply represented in a format such
like "link index 2" for readability. as "link index 2" for readability.
The zone indices are strictly local to the node. For example, the 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 be using node on the other end of the point-to-point link may well use
entirely different interface and link index values for that link. entirely different interface and link index values for that link.
An implementation should also support the concept of a "default" zone An implementation should also support the concept of a "default" zone
for each scope. And, when supported, the index value zero at each for each scope. And, when supported, the index value zero at each
scope SHOULD be reserved to mean "use the default zone". Unlike scope SHOULD be reserved to mean "use the default zone". Unlike
other zone indices, the default index does not contain any scope, and other zone indices, the default index does not contain any scope, and
the scope is determined by the address which the default index the scope is determined by the address that the default index
accompanies. An implementation may additionally define a separate accompanies. An implementation may additionally define a separate
default zone for each scope. Those default indices can also be used 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 as the zone qualifier for an address for which the node is attached
to only one zone, e.g., when using global addresses. to only one zone; e.g., when using global addresses.
There is at present no way for a node to automatically determine 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 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 or the same multicast scope zone larger than interface. In the
future, protocols may be developed to determine that information. In future, protocols may be developed to determine that information. In
the absence of such protocols, an implementation must provide a means the absence of such protocols, an implementation must provide a means
for manual assignment and/or reassignment of zone indices. for manual assignment and/or reassignment of zone indices.
Furthermore, to avoid the need to perform manual configuration in Furthermore, to avoid performing manual configuration in most cases,
most cases, an implementation should, by default, initially assign an implementation should, by default, initially assign zone indices
zone indices as follows, and only as follows: only as follows:
o A unique interface index for each interface o A unique interface index for each interface.
o A unique link index for each interface o A unique link index for each interface.
Then, manual configuration would be necessary only for the less Then manual configuration would only be necessary for the less common
common cases of nodes with multiple interfaces to a single link or cases of nodes with multiple interfaces to a single link or of those
interfaces to zones of different (multicast-only) scopes. with interfaces to zones of different (multicast-only) scopes.
Thus, the default zone index assignments for the example node from Thus, the default zone index assignments for the example node from
Figure 1 would be as illustrated in Figure 2, below. Manual Figure 1 would be as illustrated in Figure 2, below. Manual
configuration would then be required to, for example, assign the same configuration would then be required to, for example, assign the same
link index to the two Ethernet interfaces as shown in Figure 1. link index to the two Ethernet interfaces, as shown in Figure 1.
--------------------------------------------------------------- ---------------------------------------------------------------
| a node | | a node |
| | | |
| | | |
| | | |
| | | |
| | | |
| /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ |
| | | |
skipping to change at page 9, line 34 skipping to change at page 9, line 34
As well as initially assigning zone indices, as specified above, an As well as initially assigning zone indices, as specified above, an
implementation should automatically select a default zone for each implementation should automatically select a default zone for each
scope for which there is more than one choice, to be used whenever an 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 address is specified without a zone index (or with a zone index of
zero). For instance, in the example shown in Figure 2, the zero). For instance, in the example shown in Figure 2, the
implementation might automatically select intf2 and link2 as the implementation might automatically select intf2 and link2 as the
default zones for each of those two scopes. (One possible selection default zones for each of those two scopes. (One possible selection
algorithm is to choose the first zone that includes an interface algorithm is to choose the first zone that includes an interface
other than the loopback interface as the default for each scope.) A other than the loopback interface as the default for each scope.) A
means must also be provided for manually assigning the default zone means must also be provided to assign the default zone for a scope
for a scope, overriding any automatic assignment. manually, overriding any automatic assignment.
Because the unicast loopback address, ::1, may not be assigned to any The unicast loopback address, ::1, may not be assigned to any
interface other than the loopback interface, it is recommended that, interface other than the loopback interface. Therefore, it is
whenever ::1 is specified without a zone index, or with the default recommended that, whenever ::1 is specified without a zone index or
zone index, it be interpreted as belonging to the loopback link-local with the default zone index, it be interpreted as belonging to the
zone, regardless of which link-local zone has been selected as the loopback link-local zone, regardless of which link-local zone has
default. If this is done, then in the common case of nodes with only been selected as the default. If this is done, then for nodes with
a single non-loopback interface (e.g., a single Ethernet interface), only a single non-loopback interface (e.g., a single Ethernet
it becomes possible to avoid any need to qualify link-local addresses interface), the common case, link-local addresses need not be
with a zone index: the unqualified address ::1 would always refer to qualified with a zone index. The unqualified address ::1 would
the link-local zone containing the loopback interface, and all other always refer to the link-local zone containing the loopback
unqualified link-local addresses would refer to the link-local zone interface. All other unqualified link-local addresses would refer to
containing the non-loopback interface (as long as the default the link-local zone containing the non-loopback interface (as long as
link-local zone were set to be the zone containing the non-loopback the default link-local zone was set to be the zone containing the
interface). non-loopback interface).
Because of the requirement that a zone of a given scope fall Because of the requirement that a zone of a given scope fall
completely within zones of larger scope (see Section 5, above), if completely within zones of larger scope (see Section 5, above), two
two interfaces are assigned to different zones of scope S, they must interfaces assigned to different zones of scope S must also be
also be assigned to different zones of all scopes smaller than S. assigned to different zones of all scopes smaller than S. Thus, the
Thus, the manual assignment of distinct zone indices for one scope manual assignment of distinct zone indices for one scope may require
may require the automatic assignment of distinct zone indices for the automatic assignment of distinct zone indices for smaller scopes.
smaller scopes. For example, suppose that distinct multicast For example, suppose that distinct multicast site-local indices 1 and
site-local indices 1 and 2 are manually assigned in Figure 1 and that 2 are manually assigned in Figure 1 and that site 1 contains links 1,
site 1 contains link 1, 2, and 3, while site 2 only contains link 4. 2, and 3, but site 2 only contains link 4. This configuration would
This configuration would then cause the automatic creation of cause the automatic creation of corresponding admin-local (i.e.,
corresponding admin-local (i.e. multicast "scop" value 4) indices 1 multicast "scop" value 4) indices 1 and 2, because admin-local scope
and 2, because admin-local scope is smaller than site-local scope. is smaller than site-local scope.
Taking all of the above considerations in account, the complete set With the above considerations, the complete set of zone indices for
of zone indices for our example node from Figure 1 with the our example node from Figure 1, with the additional configurations
additional configurations here is shown in Figure 3, below. here, is shown in Figure 3, below.
--------------------------------------------------------------- ---------------------------------------------------------------
| a node | | a node |
| | | |
| | | |
| | | |
| | | |
| | | |
| /--------------------site1--------------------\ /--site2--\ | | /--------------------site1--------------------\ /--site2--\ |
| | | |
skipping to change at page 10, line 46 skipping to change at page 10, line 48
: | | | | : | | | |
: | | | | : | | | |
(imaginary ================= a point- a (imaginary ================= a point- a
loopback an Ethernet to-point tunnel loopback an Ethernet to-point tunnel
link) link link) link
Figure 3: Complete Zone Indices Example Figure 3: Complete Zone Indices Example
Although the above examples show the zones being assigned index Although the above examples show the zones being assigned index
values sequentially for each scope, starting at one, the zone index values sequentially for each scope, starting at one, the zone index
values are arbitrary. An implementation may use any value it chooses values are arbitrary. An implementation may label a zone with any
to label a zone as long as it meets the requirement that the index value it chooses, as long as the index value of each zone of all
value of each zone of all scopes be unique within the node and that scopes is unique within the node. Zero SHOULD be reserved to
zero SHOULD be reserved to represent the default zone. represent the default zone. Implementations choosing to follow the
Implementations choosing to follow the recommended basic API [10] recommended basic API [10] will want to restrict their index values
will want to restrict their index values to those that can be to those that can be represented by the sin6_scope_id field of the
represented by the sin6_scope_id field of the sockaddr_in6 structure. sockaddr_in6 structure.
7. Sending Packets 7. Sending Packets
When an upper-layer protocol sends a packet to a non-global When an upper-layer protocol sends a packet to a non-global
destination address, it must have a means of identifying to the IPv6 destination address, it must have a means of identifying the intended
layer the intended zone, for cases in which the node is attached to zone to the IPv6 layer for cases in which the node is attached to
more than one zone of the destination address's scope. more than one zone of the destination address's scope.
Although identification of an outgoing interface is sufficient to Although identification of an outgoing interface is sufficient to
identify an intended zone (because each interface is attached to no identify an intended zone (because each interface is attached to no
more than one zone of each scope), that is more specific than desired more than one zone of each scope), in many cases that is more
in many cases. For example, when sending to a link-local unicast specific than desired. For example, when sending to a link-local
address, from a node that has more than one interface to the intended unicast address from a node that has more than one interface to the
link (though this is an unusual configuration), the upper layer intended link (an unusual configuration), the upper layer protocol
protocol may not care which of those interfaces is used for the may not care which of those interfaces is used for the transmission.
transmission, but rather would prefer to leave that choice to the Rather, it would prefer to leave that choice to the routing function
routing function in the IP layer. Thus, the upper-layer requires the in the IP layer. Thus, the upper-layer requires the ability to
ability to specify a zone index, rather than an interface identifier, specify a zone index, when sending to a non-global, non-loopback
when sending to a non-global, non-loopback destination address. destination address.
8. Receiving Packets 8. Receiving Packets
When an upper-layer protocol receives a packet containing a non- When an upper-layer protocol receives a packet containing a non-
global source or destination address, the zone to which that address global source or destination address, the zone to which that address
pertains can be determined from the arrival interface, because the pertains can be determined from the arrival interface, because the
arrival interface can be attached to only one zone of the same scope arrival interface can be attached to only one zone of the same scope
as the address under consideration. However, it is recommended that as that of the address under consideration. However, it is
the IP layer convey to the upper layer the correct zone indices for recommended that the IP layer convey to the upper layer the correct
the arriving source and destination addresses, in addition to the zone indices for the arriving source and destination addresses, in
arrival interface identifier. addition to the arrival interface identifier.
9. Forwarding 9. Forwarding
When a router receives a packet addressed to a node other than When a router receives a packet addressed to a node other than
itself, it must take the zone of the destination and source addresses itself, it must take the zone of the destination and source addresses
into account as follows: into account as follows:
o The zone of the destination address is determined by the scope of o The zone of the destination address is determined by the scope of
the address and arrival interface of the packet. The next-hop the address and arrival interface of the packet. The next-hop
interface is chosen by looking up the destination address in a interface is chosen by looking up the destination address in a
(conceptual) routing table specific to that zone (see Section 10). (conceptual) routing table specific to that zone (see Section 10).
That routing table is restricted to refer only to interfaces That routing table is restricted to refer to interfaces belonging
belonging to that zone. to that zone.
o After the next-hop interface is chosen, the zone of the source o After the next-hop interface is chosen, the zone of the source
address is considered. As with the destination address, the zone address is considered. As with the destination address, the zone
of the source address is determined by the scope of the address of the source address is determined by the scope of the address
and arrival interface of the packet. If transmitting the packet and arrival interface of the packet. If transmitting the packet
on the chosen next-hop interface would cause the packet to leave 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 the zone of the source address, i.e., cross a zone boundary of the
scope of the source address, then the packet is discarded. scope of the source address, then the packet is discarded.
Additionally, if the packet's destination address is a unicast Additionally, if the packet's destination address is a unicast
address, an ICMP Destination Unreachable message [4] with Code 2 address, an ICMP Destination Unreachable message [4] with Code 2
("beyond scope of source address") is sent to the source of the ("beyond scope of source address") is sent to the source of the
original packet. Note: Code 2 is currently left as unassigned in original packet. Note that Code 2 is currently left as unassigned
[4]. But the IANA is going to re-assign the value for the new in [4], but the IANA will re-assign the value for the new purpose,
purpose, and [4] will be revised with this change. and [4] will be revised with this change.
Note that even with the decision that unicast site-local addresses Note that even if unicast site-local addresses are deprecated, the
are deprecated, the above procedure still applies to link-local above procedure still applies to link-local addresses. Thus, if a
addresses. Thus, if a router receives a packet with a link-local router receives a packet with a link-local destination address that
destination address that is not one of the router's own link-local is not one of the router's own link-local addresses on the arrival
addresses on the arrival link, the router is expected to try to link, the router is expected to try to forward the packet to the
forward the packet to the destination on that link (subject to destination on that link (subject to successful determination of the
successful determination of the destination's link-layer address via destination's link-layer address via the Neighbor Discovery protocol
the Neighbor Discovery protocol [9]). The forwarded packet may be [9]). The forwarded packet may be transmitted back through the
transmitted back out the arrival interface, or out any other arrival interface, or through any other interface attached to the
interface attached to the same link. same link.
A node that receives a packet addressed to itself and containing a 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]) 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 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 the scope of the next address is smaller than the scope of the
original destination address, the node MUST discard the packet. original destination address, the node MUST discard the packet.
Otherwise, it swaps the original destination address with the next Otherwise, it swaps the original destination address with the next
address in the Routing Header. Then the above forwarding rules apply address in the Routing Header. Then the above forwarding rules apply
as follows: as follows:
o The zone of the new destination address is determined by the scope 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 of the next address and the arrival interface of the packet. The
next-hop interface is chosen just like the first bullet of the next-hop interface is chosen as per the first bullet of the rules
rules above. above.
o After the next-hop interface is chosen, the zone of the source o After the next-hop interface is chosen, the zone of the source
address is considered just like the second bullet of the rules address is considered as per the second bullet of the rules above.
above.
This check about the scope of the next address ensures that when a This check about the scope of the next address ensures that when a
packet arrives at its final destination, if that destination is link- packet arrives at its final destination, if that destination is
local then the receiving node can know that the packet originated on- link-local, then the receiving node can know that the packet
link. As a result, this will help the receiving node send a originated on-link. This will help the receiving node send a
"response" packet with the final destination of the received packet "response" packet with the final destination of the received packet
as the source address without breaking its source zone. as the source address without breaking its source zone.
Note that it is possible, though generally inadvisable, to use a Note that it is possible, though generally inadvisable, to use a
Routing Header to convey a non-global address across its associated Routing Header to convey a non-global address across its associated
zone boundary in the previously-used next address field. For zone boundary in the previously used next address field. For
example, consider a case where a link-border node (e.g., a router) 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, receives a packet with the destination being a link-local address,
and the source address a global address. If the packet contains a and the source address a global address. If the packet contains a
Routing Header where the next address is a global address, the Routing Header where the next address is a global address, the next-
next-hop interface to the global address may belong to a different hop interface to the global address may belong to a different link
link than that of the original destination. This is allowed, because than that of the original destination. This is allowed because the
the scope of the next address is not smaller than the scope of the scope of the next address is not smaller than the scope of the
original destination. original destination.
10. Routing 10. Routing
Note: since unicast site-local addresses are deprecated, and Note that as unicast site-local addresses are deprecated, and link-
link-local addresses do not need routing, the discussion in this local addresses do not need routing, the discussion in this section
section only applies to multicast scoped routing. only applies to multicast scoped routing.
When a routing protocol determines that it is operating on a zone When a routing protocol determines that it is operating on a zone
boundary, it MUST protect inter-zone integrity and maintain intra- boundary, it MUST protect inter-zone integrity and maintain intra-
zone connectivity. zone connectivity.
In order to maintain connectivity, the routing protocol must be able To maintain connectivity, the routing protocol must be able to create
to create forwarding information for the global groups as well as for forwarding information for the global groups and for all the scoped
all of the scoped groups for each of its attached zones. The most groups for each of its attached zones. The most straightforward way
straightforward way of doing this is to create (conceptual) of doing this is to create (conceptual) forwarding tables for each
forwarding tables for each specific zone. specific zone.
To protect inter-zone integrity, routers must be selective in the To protect inter-zone integrity, routers must be selective in the
group information that is shared with neighboring routers. Routers group information shared with neighboring routers. Routers routinely
routinely exchange routing information with neighboring routers. exchange routing information with neighboring routers. When a router
When a router is transmitting this routing information, it must not is transmitting this routing information, it must not include any
include any information about zones other than the zones assigned to information about zones other than the zones assigned to the
the interface used to transmit the information. interface used to transmit the information.
* * * *
* * * *
* =========== Organization X * * =========== Organization X *
* | | * * | | *
* | | * * | | *
+-*----|-------|------+ * +-*----|-------|------+ *
| * intf1 intf2 | * | * intf1 intf2 | *
| * | * | * | *
| * intf3 --- * | * intf3 --- *
skipping to change at page 14, line 30 skipping to change at page 14, line 30
| * * | | * * |
Org. Y --- intf4 * * intf5 --- Org. Z Org. Y --- intf4 * * intf5 --- Org. Z
| * * | | * * |
********************** ********************** ********************** **********************
+---------------------+ +---------------------+
Figure 4: Multi-Organization Multicast Router Figure 4: Multi-Organization Multicast Router
As an example, the router in Figure 4 must exchange routing As an example, the router in Figure 4 must exchange routing
information on five interfaces. The information exchanged is as information on five interfaces. The information exchanged is as
follows (for simplicity, multicast scopes smaller or larger than follows (for simplicity, multicast scopes smaller or larger than the
organization except global are not considered here): organization scope except global are not considered here):
o Interface 1 o Interface 1
* All global groups * All global groups
* All organization groups learned from Interfaces 1, 2, and 3 * All organization groups learned from Interfaces 1, 2, and 3
o Interface 2 o Interface 2
* All global groups * All global groups
* All organization groups learned from Interfaces 1, 2, and 3 * All organization groups learned from Interfaces 1, 2, and 3
o Interface 3 o Interface 3
skipping to change at page 15, line 13 skipping to change at page 15, line 13
* All organization groups learned from Interface 5 * All organization groups learned from Interface 5
By imposing route exchange rules, zone integrity is maintained by By imposing route exchange rules, zone integrity is maintained by
keeping all zone-specific routing information contained within the keeping all zone-specific routing information contained within the
zone. zone.
11. Textual Representation 11. Textual Representation
As already mentioned, to specify an IPv6 non-global address without As already mentioned, to specify an IPv6 non-global address without
ambiguity, an intended scope zone should be specified as well. As a ambiguity, an intended scope zone should be specified as well. As a
common notation to specify the scope zone, an implementation SHOULD common notation to specify the scope zone, an implementation SHOULD
support the following format. support the following format:
<address>%<zone_id> <address>%<zone_id>
where where
<address> is a literal IPv6 address, <address> is a literal IPv6 address,
<zone_id> is a string to identify the zone of the address, and <zone_id> is a string identifying the zone of the address, and
`%' is a delimiter character to distinguish between <address> and `%' is a delimiter character to distinguish between <address> and
<zone_id>. <zone_id>.
The following subsections describe detailed definitions, concrete The following subsections describe detailed definitions, concrete
examples, and additional notes of the format. examples, and additional notes of the format.
11.1 Non-Global Addresses 11.1. Non-Global Addresses
The format applies to all kinds of unicast and multicast addresses of The format applies to all kinds of unicast and multicast addresses of
non-global scope except the unspecified address, which does not have non-global scope except the unspecified address, which does not have
a scope. The format is meaningless and should not be used for global a scope. The format is meaningless and should not be used for global
addresses. The loopback address belongs to the trivial link, i.e., addresses. The loopback address belongs to the trivial link; i.e.,
the link attached to the loopback interface, and thus the format the link attached to the loopback interface. Thus the format should
should not be used for the loopback address either. This document not be used for the loopback address, either. This document does not
does not specify the usage of the format when the <address> is the specify the usage of the format when the <address> is the unspecified
unspecified address, since the address does not have a scope. This address, as the address does not have a scope. This document,
document, however, does not prohibit an implementation from using the however, does not prohibit an implementation from using the format
format for those special addresses for implementation dependent for those special addresses for implementation dependent purposes.
purposes.
11.2 The <zone_id> Part 11.2. The <zone_id> Part
In the textual representation, the <zone_id> part should be able to In the textual representation, the <zone_id> part should be able to
identify a particular zone of the address's scope. Although a zone identify a particular zone of the address's scope. Although a zone
index is expected to contain enough information to determine the index is expected to contain enough information to determine the
scope and to be unique among all scopes as described in Section 6 of scope and to be unique among all scopes as described in Section 6,
this document, the <zone_id> part of this format does not have to the <zone_id> part of this format does not have to contain the scope.
contain the scope because the <address> part should specify the This is because the <address> part should specify the appropriate
appropriate scope. This also means the <zone_id> part does not have scope. This also means that the <zone_id> part does not have to be
to be unique among all scopes. unique among all scopes.
With this loosened property, an implementation can use a convenient With this loosened property, an implementation can use a convenient
representation as <zone_id>. For example, to represent link index 2, representation as <zone_id>. For example, to represent link index 2,
the implementation can simply use "2" as <zone_id>, which would be the implementation can simply use "2" as <zone_id>, which would be
more readable than other representations that contain the "link" more readable than other representations that contain the "link"
scope. scope.
When an implementation interprets the format, it should construct the When an implementation interprets the format, it should construct the
"full" zone index, which contains the scope, from the <zone_id> part "full" zone index, which contains the scope, from the <zone_id> part
and the scope specified by the <address> part. (Remember that a zone and the scope specified by the <address> part. (Remember that a zone
index itself should contain the scope as specified in Section 6.) index itself should contain the scope, as specified in Section 6.)
An implementation SHOULD support at least numerical indices as An implementation SHOULD support at least numerical indices that are
<zone_id>, which are non-negative decimal integers. The default zone non-negative decimal integers as <zone_id>. The default zone index,
index, which should typically be 0 (see Section 6), is included in which should typically be 0 (see Section 6), is included in the
the integers. When <zone_id> is the default, the delimiter integers. When <zone_id> is the default, the delimiter characters
character, "%", and <zone_id> can be omitted. Similarly, if a "%" and <zone_id> can be omitted. Similarly, if a textual
textual representation of an IPv6 address is given without a zone representation of an IPv6 address is given without a zone index, it
index, it should be interpreted as <address>%<default ID> where should be interpreted as <address>%<default ID>, where <default ID>
<default ID> is the default zone index of the scope that <address> is the default zone index of the scope that <address> has.
has.
An implementation MAY support other kinds of non-null strings as An implementation MAY support other kinds of non-null strings as
<zone_id>. However, the strings must not conflict with the delimiter <zone_id>. However, the strings must not conflict with the delimiter
character. The precise format and semantics of such additional character. The precise format and semantics of additional strings is
strings is implementation dependent. implementation dependent.
One possible candidate of such strings would be interface names, One possible candidate for these strings would be interface names, as
since interfaces uniquely disambiguate any scopes. In particular, interfaces uniquely disambiguate any scopes. In particular,
interface names can be used as "default identifiers" for interfaces interface names can be used as "default identifiers" for interfaces
and links, because there is, by default, a one-to-one mapping between and links, because by default there is a one-to-one mapping between
interfaces and each of those scopes as described in Section 6. interfaces and each of those scopes as described in Section 6.
An implementation could also use interface names as <zone_id> for An implementation could also use interface names as <zone_id> for
larger scopes than links, but there might be some confusion in such scopes larger than links, but there might be some confusion in this
use. For example, when more than one interface belongs to the same use. For example, when more than one interface belongs to the same
(multicast) site, a user would be confused about which interface (multicast) site, a user would be confused about which interface
should be used. Also, a mapping function from an address to a name 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 would encounter the same kind of problem when it prints an address
with an interface name as a zone index. This document does not with an interface name as a zone index. This document does not
specify how these cases should be treated and leaves it specify how these cases should be treated and leaves it
implementation dependent. implementation dependent.
It cannot be assumed that indices are common across all nodes in a 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 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 node and MUST NOT be sent on the wire unless every node that
interprets the format agrees on the semantics. interprets the format agrees on the semantics.
11.3 Examples 11.3. Examples
Here are examples. The following addresses The following addresses
fe80::1234 (on the 1st link of the node) fe80::1234 (on the 1st link of the node)
ff02::5678 (on the 5th link of the node) ff02::5678 (on the 5th link of the node)
ff08::9abc (on the 10th organization of the node) ff08::9abc (on the 10th organization of the node)
would be represented as follows: would be represented as follows:
fe80::1234%1 fe80::1234%1
ff02::5678%5 ff02::5678%5
ff08::9abc%10 ff08::9abc%10
(Here we assume a natural translation from a zone index to the (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 <zone_id> part, where the Nth zone of any scope is translated into
"N".) "N".)
If we use interface names as <zone_id>, those addresses could also be If we use interface names as <zone_id>, those addresses could also be
represented as follows: represented as follows:
fe80::1234%ne0 fe80::1234%ne0
ff02::5678%pvc1.3 ff02::5678%pvc1.3
ff08::9abc%interface10 ff08::9abc%interface10
where the interface "ne0" belongs to the 1st link, "pvc1.3" belongs where the interface "ne0" belongs to the 1st link, "pvc1.3" belongs
to the 5th link, and "interface10" belongs to the 10th organization. to the 5th link, and "interface10" belongs to the 10th organization.
11.4 Usage Examples 11.4. Usage Examples
Applications that are supposed to be used in end hosts like telnet, Applications that are supposed to be used in end hosts such as
ftp, and ssh, may not explicitly support the notion of address scope, telnet, ftp, and ssh may not explicitly support the notion of address
especially of link-local addresses. However, an expert user (e.g. a scope, especially of link-local addresses. However, an expert user
network administrator) sometimes has to give even link-local (e.g., a network administrator) sometimes has to give even link-local
addresses to such applications. addresses to such applications.
Here is a concrete example. Consider a multi-linked router, called Here is a concrete example. Consider a multi-linked router called
"R1", that has at least two point-to-point interfaces (links). Each "R1" that has at least two point-to-point interfaces (links). Each
of the interfaces is connected to another router, called "R2" and of the interfaces is connected to another router, "R2" and "R3",
"R3", respectively. Also assume that the point-to-point interfaces respectively. Also assume that the point-to-point interfaces have
have link-local addresses only. link-local addresses only.
Now suppose that the routing system on R2 hangs up and has to be 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 reinvoked. In this situation, we may not be able to use a global
address of R2, because this is a routing trouble and we cannot expect address of R2, because this is routing trouble and we cannot expect
that we have enough routes for global reachability to R2. to have enough routes for global reachability to R2.
Hence, we have to login R1 first, and then try to login R2 using Hence, we have to login R1 first and then try to login R2 by using
link-local addresses. In such a case, we have to give the link-local 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 address of R2 to, for example, telnet. Here we assume the address is
fe80::2. fe80::2.
Note that we cannot just type like Note that we cannot just type
% telnet fe80::2 % telnet fe80::2
here, since R1 has more than one link and hence the telnet command here, since R1 has more than one link and hence the telnet command
cannot detect which link it should try to use for connecting. cannot detect which link it should try to use for connecting.
Instead, we should type the link-local address with the link index as Instead, we should type the link-local address with the link index as
follows: follows:
% telnet fe80::2%3 % telnet fe80::2%3
where "3" after the delimiter character `%' corresponds to the link where "3" after the delimiter character `%' corresponds to the link
index of the point-to-point link. index of the point-to-point link.
11.5 Related API 11.5. Related API
An extension to the recommended basic API defines how the format for An extension to the recommended basic API defines how the format for
non-global addresses should be treated in library functions that non-global addresses should be treated in library functions that
translate a nodename to an address, or vice versa [11]. translate a nodename to an address, or vice versa [11].
11.6 Omitting Zone Indices 11.6. Omitting Zone Indices
The format defined in this document does not intend to invalidate the The format defined in this document does not intend to invalidate the
original format for non-global addresses, that is, the format without original format for non-global addresses; that is, the format without
the zone index portion. As described in Section 6, in some common 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 cases with the notion of the default zone index, there can be no
ambiguity about scope zones. In such an environment, the ambiguity about scope zones. In such an environment, the
implementation can omit the "%<zone_id>" part, and, as a result, it implementation can omit the "%<zone_id>" part. As a result, it can
can act as if it did not support the extended format at all. act as though it did not support the extended format at all.
11.7 Combinations of Delimiter Characters 11.7. Combinations of Delimiter Characters
There are other kinds of delimiter characters defined for IPv6 There are other kinds of delimiter characters defined for IPv6
addresses. In this subsection, we describe how they should be addresses. In this subsection, we describe how they should be
combined with the format for non-global addresses. combined with the format for non-global addresses.
The IPv6 addressing architecture [1] also defines the syntax of IPv6 The IPv6 addressing architecture [1] also defines the syntax of IPv6
prefixes. If the address portion of a prefix is non-global and its prefixes. If the address portion of a prefix is non-global and its
scope zone should be disambiguated, the address portion SHOULD be in scope zone should be disambiguated, the address portion SHOULD be in
the format. For example, a link-local prefix fe80::/64 on the 2nd the format. For example, a link-local prefix fe80::/64 on the second
link can be represented as follows: link can be represented as follows:
fe80::%2/64 fe80::%2/64
In this combination, it is important to place the zone index portion In this combination, it is important to place the zone index portion
before the prefix length, when we consider parsing the format by a before the prefix length when we consider parsing the format by a
name-to-address library function [11]. That is, we can first name-to-address library function [11]. That is, we can first
separate the address with the zone index from the prefix length, and separate the address with the zone index from the prefix length, and
just pass the former to the library function. just pass the former to the library function.
The preferred format for literal IPv6 addresses in URL's are also The preferred format for literal IPv6 addresses in URLs is also
defined [12]. When a user types the preferred format for an IPv6 defined [12]. When a user types the preferred format for an IPv6
non-global address whose zone should be explicitly specified, the non-global address whose zone should be explicitly specified, the
user could use the format for the non-global address combined with user could use the format for the non-global address combined with
the preferred format. the preferred format.
However, the typed URL is often sent on the wire, and it would cause However, the typed URL is often sent on the wire, and it would cause
confusion if an application did not strip the <zone_id> portion confusion if an application did not strip the <zone_id> portion
before sending. Note that the applications should not need to care before sending. Note that the applications should not need to care
about which kind of addresses they're using, much less parse or strip about which kind of addresses they're using, much less parse or strip
out the <zone_id> portion of the address. Also, the format for out the <zone_id> portion of the address.
non-global addresses might conflict with the URI syntax [13], since
the syntax defines the delimiter character (`%') as the escape Also, the format for non-global addresses might conflict with the URI
character. syntax [13], since the syntax defines the delimiter character (`%')
as the escape character. This conflict would require, for example,
that the <zone_id> part for zone 1 with the delimiter be represented
as '%251'. It also means that we could not simply copy a non-escaped
format from other sources as input to the URI parser. Additionally,
if the URI parser does not convert the escaped format before passing
it to a name-to-address library, the conversion will fail. All these
issues would decrease the benefit of the textual representation
described in this section.
Hence, this document does not specify how the format for non-global Hence, this document does not specify how the format for non-global
addresses should be combined with the preferred format for literal addresses should be combined with the preferred format for literal
IPv6 addresses. As for the conflict issue with the URI format, it IPv6 addresses. In any case, it is recommended to use an FQDN
would be better to wait until the relationship between the preferred instead of a literal IPv6 address in a URL, whenever an FQDN is
format and the URI syntax is clarified. In fact, the preferred available.
format for IPv6 literal addresses itself has the same kind of
conflict. In any case, it is recommended to use an FQDN instead of a
literal IPv6 address in a URL, whenever an FQDN is available.
12. Security Considerations 12. Security Considerations
A limited scoped address without its zone index has security A limited scope address without a zone index has security
implications, and cannot be used for some security contexts. For implications and cannot be used for some security contexts. For
example, a link-local address cannot be used in a traffic selector of example, a link-local address cannot be used in a traffic selector of
a security association established by Internet Key Exchange (IKE) a security association established by Internet Key Exchange (IKE)
when the IKE messages are carried over global addresses. Also, a when the IKE messages are carried over global addresses. Also, a
link-local address without its zone index cannot be used in access link-local address without a zone index cannot be used in access
control lists. control lists.
The routing section of this document specifies a set of guidelines The routing section of this document specifies a set of guidelines
that allow routers to prevent zone-specific information from leaking whereby routers can prevent zone-specific information from leaking
out of each zone. If, for example, multicast site boundary routers out of each zone. If, for example, multicast site boundary routers
allow site routing information to be forwarded outside of the site, allow site routing information to be forwarded outside of the site,
the integrity of the site could be compromised. the integrity of the site could be compromised.
Since the use of the textual representation of non-global addresses Since the use of the textual representation of non-global addresses
is restricted to use within a single node, it does not create a is restricted to use within a single node, it does not create a
security vulnerability from outside the node. However, a malicious security vulnerability from outside the node. However, a malicious
node might send a packet that contains a textual IPv6 non-global node might send a packet that contains a textual IPv6 non-global
address with a zone index, intending to deceive the receiving node address with a zone index, intending to deceive the receiving node
about the zone of the non-global address. Thus, an implementation about the zone of the non-global address. Thus, an implementation
should be careful when it receives packets that contain textual should be careful when it receives packets that contain textual non-
non-global addresses as data. global addresses as data.
13. IANA Considerations
This document has no actions for IANA.
14. Contributors 13. Contributors
This document is a combination of several separate efforts. Atsushi This document is a combination of several separate efforts. Atsushi
Onoe took a significant role in one of them, and deeply contributed Onoe took a significant role in one of them and deeply contributed to
to the content of Section 11 as a co-author of a separate proposal. the content of Section 11 as a co-author of a separate proposal.
15. Acknowledgements 14. Acknowledgements
Many members of the IPv6 working group provided useful comments and Many members of the IPv6 working group provided useful comments and
feedback on this document. In particular, Margaret Wasserman and Bob feedback on this document. In particular, Margaret Wasserman and Bob
Hinden led the working group to make a consensus on IPv6 local Hinden led the working group to make a consensus on IPv6 local
addressing. Richard Draves proposed an additional rule to process addressing. Richard Draves proposed an additional rule to process
Routing header containing scoped addresses. Dave Thaler and Francis Routing header containing scoped addresses. Dave Thaler and Francis
Dupont gave valuable suggestions to define semantics of zone indices Dupont gave valuable suggestions to define semantics of zone indices
in terms of related API. Pekka Savola reviewed a draft of the in terms of related API. Pekka Savola reviewed a version of the
document very carefully, and made detailed comments including serious document very carefully and made detailed comments about serious
problems. Steve Bellovin, Ted Hardie, Bert Wijnen, and Timothy problems. Steve Bellovin, Ted Hardie, Bert Wijnen, and Timothy
Gleeson reviewed and helped improve the document during the Gleeson reviewed and helped improve the document during the
preparation for publication. preparation for publication.
16. References 15. References
16.1 Normative References 15.1. Normative References
[1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) [1] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003. Addressing Architecture", RFC 3513, April 2003.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) [3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998. Specification", RFC 2460, December 1998.
[4] Conta, A. and S. Deering, "Internet Control Message Protocol [4] Conta, A. and S. Deering, "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) (ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification", RFC 2463, December 1998. Specification", RFC 2463, December 1998.
16.2 Informative References 15.2. Informative References
[5] Huitema, C. and B. Carpenter, "Deprecating Site Local [5] Huitema, C. and B. Carpenter, "Deprecating Site Local
Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work in Addresses", RFC 3879, September 2004.
progress), March 2004.
[6] Draves, R., "Default Address Selection for Internet Protocol [6] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003. version 6 (IPv6)", RFC 3484, February 2003.
[7] Aboba, B., "Dynamic Configuration of Link-Local IPv4 [7] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration
Addresses", draft-ietf-zeroconf-ipv4-linklocal-17 (work in of Link-Local IPv4 Addresses", Work in Progress.
progress), July 2004.
[8] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 [8] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
Specification", RFC 2473, December 1998. Specification", RFC 2473, December 1998.
[9] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery [9] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998. for IP Version 6 (IPv6)", RFC 2461, December 1998.
[10] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. [10] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493,
3493, February 2003. February 2003.
[11] Gilligan, R., "Scoped Address Extensions to the IPv6 Basic [11] Gilligan, R., "Scoped Address Extensions to the IPv6 Basic
Socket API", draft-ietf-ipv6-scope-api-00 (work in progress), Socket API", Work in Progress, July 2002.
July 2002.
[12] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal [12] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999. IPv6 Addresses in URL's", RFC 2732, December 1999.
[13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform [13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, August Resource Identifiers (URI): Generic Syntax", RFC 3986, January
1998. 2005.
Authors' Addresses Authors' Addresses
Stephen E. Deering Stephen E. Deering
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
USA USA
Brian Haberman Brian Haberman
Johns Hopkins University Applied Physics Laboratory Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Road 11100 Johns Hopkins Road
Laurel, MD 20723-6099 Laurel, MD 20723-6099
USA USA
Phone: +1-443-778-1319 Phone: +1-443-778-1319
EMail: brian@innovationslab.net EMail: brian@innovationslab.net
Tatuya Jinmei Tatuya Jinmei
skipping to change at page 22, line 24 skipping to change at page 22, line 33
Corporate Research & Development Center, Toshiba Corporation Corporate Research & Development Center, Toshiba Corporation
1 Komukai Toshiba-cho, Saiwai-ku 1 Komukai Toshiba-cho, Saiwai-ku
Kawasaki-shi, Kanagawa 212-8582 Kawasaki-shi, Kanagawa 212-8582
Japan Japan
Phone: +81-44-549-2230 Phone: +81-44-549-2230
Fax: +81-44-520-1841 Fax: +81-44-520-1841
EMail: jinmei@isl.rdc.toshiba.co.jp EMail: jinmei@isl.rdc.toshiba.co.jp
Erik Nordmark Erik Nordmark
Sun Microsystems Laboratories, Europe 17 Network Circle
180, avenue de l'Europe Menlo Park, CA 94025
SAINT ISMIER Cedex 38334 USA
France
Phone: +33 (0)4 74 18 88 03 Phone: +1 650 786 2921
Fax: +33 (0)4 76 18 88 88 Fax: +1 650 786 5896
EMail: Erik.Nordmark@sun.com EMail: Erik.Nordmark@sun.com
Brian D. Zill Brian D. Zill
Microsoft Research Microsoft Research
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA USA
Phone: +1-425-703-3568 Phone: +1-425-703-3568
Fax: +1-425-936-7329 Fax: +1-425-936-7329
EMail: bzill@microsoft.com EMail: bzill@microsoft.com
skipping to change at page 23, line 5 skipping to change at page 24, line 5
Brian D. Zill Brian D. Zill
Microsoft Research Microsoft Research
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
USA USA
Phone: +1-425-703-3568 Phone: +1-425-703-3568
Fax: +1-425-936-7329 Fax: +1-425-936-7329
EMail: bzill@microsoft.com EMail: bzill@microsoft.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/