draft-ietf-ipv6-scoping-arch-00.txt   draft-ietf-ipv6-scoping-arch-01.txt 
Internet Engineering Task Force S. Deering IETF IPv6 Working Group S. Deering
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Expires: December 22, 2003 B. Haberman Expires: August 13, 2004 B. Haberman
Caspian Networks Caspian Networks
T. Jinmei T. Jinmei
Toshiba Toshiba
E. Nordmark E. Nordmark
Sun Microsystems Sun Microsystems
A. Onoe
Sony
B. Zill B. Zill
Microsoft Microsoft
June 23, 2003 February 13, 2004
IPv6 Scoped Address Architecture IPv6 Scoped Address Architecture
draft-ietf-ipv6-scoping-arch-00.txt draft-ietf-ipv6-scoping-arch-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that other
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 22, 2003. This Internet-Draft will expire on August 13, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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 using the syntax and usage of
unicast site-local addresses. unicast site-local addresses.
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., link- different "scope", that is, both global and non-global (e.g.,
local) addresses. While non-global addressing has been introduced link-local) addresses. While non-global addressing has been
operationally in the IPv4 Internet, both in the use of private introduced operationally in the IPv4 Internet, both in the use of
address space ("net 10", etc.) and with administratively scoped private address space ("net 10", etc.) and with administratively
multicast addresses, the design of IPv6 formally incorporates the scoped multicast addresses, the design of IPv6 formally incorporates
notion of address scope into its base architecture. This document the notion of address scope into its base architecture. This
specifies the architectural characteristics, expected behavior, document specifies the architectural characteristics, expected
textual representation, and usage of IPv6 addresses of different behavior, textual representation, and usage of IPv6 addresses of
scopes. different scopes.
Though the current specification [1] defines unicast site-local Though the current address architecture specification [1] defines
addresses, the IPv6 working group decided to deprecate the syntax and unicast site-local addresses, the IPv6 working group decided to
the usage and is now investigating other forms of local IPv6 deprecate the syntax and the usage [5], and is now investigating
addressing. The usage of any new forms of local addresses will be other forms of local IPv6 addressing. The usage of any new forms of
documented elsewhere in the future. Thus, this document local addresses will be documented elsewhere in the future. Thus,
intentionally focuses on link-local and multicast scopes only. this document intentionally focuses on link-local and multicast
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].
skipping to change at page 3, line 29 skipping to change at page 3, line 26
represent "any" address in APIs. In such a case, implementations may represent "any" address in APIs. In such a case, implementations may
want to regard the address in a particular scope to represent the want to regard the address in a particular scope to represent the
notion of "any addresses in the scope." This document does not notion of "any addresses 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 part of
global addresses. Thus, those addresses have global scope, with global addresses. Thus, those addresses have global scope, with
regards to the IPv6 scoped address architecture. However, an regards to the IPv6 scoped address architecture. However, an
implementation may use those addresses as if they had other type of implementation may use those addresses as if they had other type of
scopes for convenience. For instance, [7] assigns link-local scope scopes for convenience. For instance, [6] assigns link-local scope to
to IPv4 auto-configuration addresses, and converts those addresses IPv4 auto-configured link-local addresses (the addresses from the
into IPv4-mapped IPv6 addresses in order for destination address 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 selection among IPv4 and IPv6 addresses. This would implicitly mean
IPv4-mapped addresses correspondent to IPv4 auto-configuration the IPv4-mapped IPv6 addresses equivalent to the IPv4
addresses have link-local scope. This document does not preclude auto-configuration link-local addresses have link-local scope. This
such a usage, as long as it is limited within the implementation. 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 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 inter- of multicasts within a single node, for example, as a form of
process communication within a computer. Unlike the unicast loopback inter-process communication within a computer. Unlike the unicast
address, interface-local multicast addresses may be assigned to any loopback address, interface-local multicast addresses may be assigned
interface. to any 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
A scope zone, or a simply a zone, is a connected region of topology A scope zone, or simply a zone, is a connected region of topology of
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 (i.e., a site or a link or a ...).
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 rather is determined by context,
such as the interface from which it is sent or received. Thus, 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 addresses of a given (non-global) scope may be re-used in different
zones of that scope. For example, two different physical links may zones of that scope. For example, two different physical links may
each contain a node with link-local address fe80::1. each contain a node with 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 interface- o Each interface on a node comprises a single zone of
local scope (for multicast only). interface-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, comprises 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, link- o The boundaries of zones of scope other than interface-local,
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 be only 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 interface- global zone has no boundary, and the boundary of an
local zone encloses just a single interface.) 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, i.e., a smaller scope zone cannot include
more topology than any larger scope zone with which it shares any more topology than any larger scope zone with which it shares any
links or interfaces. 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 interface in
the same zone are never routed outside the zone. the same zone are never routed outside the zone.
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
of what kind of unicast address the interface has or of 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 Considering the fact that 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 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 that a node may address fe80::1 in two separate physical links), and that a node may
have interfaces attached to different zones of the same scope (e.g., have interfaces attached to different zones of the same scope (e.g.,
a router normally has multiple interfaces attached to different a router normally has multiple interfaces attached to different
links), a node requires an internal means of identifying to which links), a node requires an internal means of identifying to which
zone a non-global address belongs. This is accomplished by zone a non-global address belongs. This is accomplished by
assigning, within the node, a distinct "zone index" to each zone of assigning, within the node, a distinct "zone index" to each zone of
the same scope to which that node is attached, and allowing all the same scope to which that node is attached, and allowing all
internal uses of an address to be qualified by a zone index. internal uses of an address to 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 |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
| | | |
skipping to change at page 6, line 28 skipping to change at page 6, line 26
--------------------------------------------------------------- ---------------------------------------------------------------
: | | | | : | | | |
: | | | | : | | | |
: | | | | : | | | |
(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, Two interfaces to the same Ethernet link,
An interface to a point-to-point link, and An interface to a point-to-point link, and
A tunnel interface (e.g., the abstract endpoint of an IPv6-over- A tunnel interface (e.g., the abstract endpoint of an
IPv6 tunnel [6], presumably established over either the Ethernet IPv6-over-IPv6 tunnel [8], presumably established over either the
or the point-to-point link.) Ethernet 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 attached to only four link-local zones, identified by
link indices 1 through 4. link indices 1 through 4.
Each zone index of a particular scope should contain an information Each zone index of a particular scope should contain an information
to represent the scope type, so that all indices of all scopes are to represent the scope type, so that all indices of all scopes are
skipping to change at page 7, line 16 skipping to change at page 7, line 11
will be an example of the dedicated purpose. The actual will be an example of the dedicated purpose. The actual
representation to encode the scope type is implementation dependent representation to encode the scope type is implementation dependent
and is out of scope of this document. Within this document, indices and is out of scope of this document. Within this document, indices
are simply represented like "link index 2" for readability. are simply represented like "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 be using
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. It is convenient to reserve the index value zero, at for each scope. And, when supported, the index value zero at each
each scope, to mean "use the default zone". Unlike other zone scope SHOULD be reserved to mean "use the default zone". Unlike other
indices, the default ID does not contain any scope type, and the zone indices, the default ID does not contain any scope type, and the
scope type is determined by the address by which the default ID was scope type is determined by the address by which the default ID was
accompanied. An implementation may additionally define a separate accompanied. An implementation may additionally define a separate
default zone for each scope type. Those default indices can also be default zone for each scope type. Those default indices can also be
used as the zone qualifier for an address for which the node is used as the zone qualifier for an address for which the node is
attached to only one zone, e.g., when using global addresses. attached to only one zone, e.g., when using global addresses.
There is at present no way for a node to automatically determine There is at present 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 the need to perform manual configuration in
most cases, an implementation should, by default, initially assign most cases, an implementation should, by default, initially assign
zone indices as follows, and only as follows: zone indices as follows, and 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
o A unique subnet (multicast "scop" value 3) index for each
interface
Then, manual configuration would be necessary only for the less Then, manual configuration would be necessary only for the less
common cases of nodes with multiple interfaces to a single link or a common cases of nodes with multiple interfaces to a single link or
single subnet, interfaces to different sites, or interfaces to zones interfaces to zones of different (multicast-only) scopes.
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 |
| | | |
| | | |
| | | |
| | | |
| | | |
| /-subnet1-\ /-subnet2-\ /-subnet3-\ /-subnet4-\ /-subnet5-\ |
| |
| /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ |
| | | |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
--------------------------------------------------------------- ---------------------------------------------------------------
: | | | | : | | | |
: | | | | : | | | |
: | | | | : | | | |
(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 2: Example of Default Zone Indices Figure 2: Example of Default Zone Indices
---------------------------------------------------------------------
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, link2, and subnet2 implementation might automatically select intf2 and link2 as the
as the default zones for each of those three scopes. (Perhaps the default zones for each of those three scopes. (Perhaps the selection
selection algorithm is to choose the first zone that includes an algorithm is to choose the first zone that includes an interface
interface other than the loopback interface as the default for each other than the loopback interface as the default for each scope.) A
scope.) A means must also be provided for manually assigning the means must also be provided for manually assigning the default zone
default zone for a scope, overriding any automatic assignment. for a scope, overriding any automatic assignment.
Because the unicast loopback address, ::1, may not be assigned to any Because 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, it is recommended that,
whenever ::1 is specified without a zone index, or with the default whenever ::1 is specified without a zone index, or with the default
zone index, it be interpreted as belonging to the loopback link-local zone index, it be interpreted as belonging to the loopback link-local
zone, regardless of which link-local zone has been selected as the zone, regardless of which link-local zone has been selected as the
default. If this is done, then in the common case of nodes with only default. If this is done, then in the common case of nodes with only
a single non-loopback interface (e.g., a single Ethernet interface), a single non-loopback interface (e.g., a single Ethernet interface),
it becomes possible to avoid any need to qualify link- local it becomes possible to avoid any need to qualify link-local addresses
addresses with a zone index: the unqualified address ::1 would always with a zone index: the unqualified address ::1 would always refer to
refer to the link-local zone containing the loopback interface, and the link-local zone containing the loopback interface, and all other
all other unqualified link-local addresses would refer to the link- unqualified link-local addresses would refer to the link-local zone
local zone containing the non-loopback interface (as long as the containing the non-loopback interface (as long as the default
default link-local zone were set to be the zone containing the non- link-local zone were set to be the zone containing the non-loopback
loopback interface). 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), if
two interfaces are assigned to different zones of scope S, they must two interfaces are assigned to different zones of scope S, they must
also be assigned to different zones of all scopes smaller than S. also be assigned to different zones of all scopes smaller than S.
Thus, the manual assignment of distinct zone indices for one scope Thus, the manual assignment of distinct zone indices for one scope
may require the automatic assignment of distinct zone indices for may require the automatic assignment of distinct zone indices for
smaller scopes. For example, suppose that distinct multicast site- smaller scopes. For example, suppose that distinct multicast
local indices 1 and 2 are manually assigned in Figure 1 and that site site-local indices 1 and 2 are manually assigned in Figure 1 and that
1 contains link 1, 2, and 3, while site 2 only contains link 4. This site 1 contains link 1, 2, and 3, while site 2 only contains link 4.
configuration would then cause the automatic creation of This configuration would then cause the automatic creation of
corresponding admin-local (i.e. multicast "scop" value 4) indices 1 corresponding admin-local (i.e. multicast "scop" value 4) indices 1
and 2, because admin-local scope is smaller than site-local scope. and 2, because admin-local scope is smaller than site-local scope.
Taking all of the above considerations in account, the complete set Taking all of the above considerations in account, the complete set
of zone indices for our example node from Figure 1 with the of zone indices for our example node from Figure 1 with the
additional configurations here is shown in Figure 3, below. additional configurations here is shown in Figure 3, below.
---------------------------------------------------------------------
--------------------------------------------------------------- ---------------------------------------------------------------
| a node | | a node |
| | | |
| | | |
| | | |
| | | |
| | | |
| /--------------------site1--------------------\ /--site2--\ | | /--------------------site1--------------------\ /--site2--\ |
| | | |
| /-------------------admin1--------------------\ /-admin2--\ | | /-------------------admin1--------------------\ /-admin2--\ |
| | | |
| /-subnet1-\ /-------subnet2-------\ /-subnet3-\ /-subnet4-\ |
| |
| /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ | | /--link1--\ /--------link2--------\ /--link3--\ /--link4--\ |
| | | |
| /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ | | /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\ |
--------------------------------------------------------------- ---------------------------------------------------------------
: | | | | : | | | |
: | | | | : | | | |
: | | | | : | | | |
(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 examples above show the zones being assigned index Although the examples above 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 use any value it chooses
to label a zone as long as it meets the requirement that the index to label a zone as long as it meets the requirement that the index
value of each zone of all scopes be unique within the node. value of each zone of all scopes be unique within the node and that
Similarly, an implementation may choose an index value other than zero SHOULD be reserved to represent the default zone.
zero to represent the default zone. Implementations choosing to Implementations choosing to follow the recommended basic API [10]
follow the recommended basic API [5] will want to restrict their will want to restrict their index values to those that can be
index values to those that can be represented by the sin6_scope_id represented by the sin6_scope_id field of a sockaddr_in6 structure.
field of a 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 to the IPv6
layer the intended zone, for cases in which the node is attached to layer the intended zone, 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
skipping to change at page 11, line 44 skipping to change at page 10, line 44
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. That routing (conceptual) routing table specific to that zone. That routing
table is restricted to refer only to interfaces belonging to that table is restricted to refer only to interfaces belonging to that
zone. 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
on the chosen next-hop interface would cause the packet to leave the chosen next-hop interface would cause the packet to leave the
the zone of the source address, i.e., cross a zone boundary of the zone of the source address, i.e., cross a zone boundary of the
scope of the source address, then the packet is discarded and an scope of the source address, then the packet is discarded.
ICMP Destination Unreachable message [4] with Code 2 ("beyond Additionally, if the packet's destination address is a unicast
scope of source address") is sent to the source of the packet. address, an ICMP Destination Unreachable message [4] with Code 2
("beyond scope of source address") is sent to the source of the
original packet. Note: Code 2 is currently left as unassigned in
[4]. But the IANA is going to re-assign the value for the new
purpose, and [4] will be revised with this change.
Note that even with the decision that unicast site-local addresses Note that even with the decision that unicast site-local addresses
are deprecated, the above procedure still applies to link-local are deprecated, the above procedure still applies to link-local
addresses. Thus, if a router receives a packet with a link-local addresses. Thus, if a router receives a packet with a link-local
destination address that is not one of the router's own link-local destination address that is not one of the router's own link-local
addresses on the arrival link, the router is expected to try to addresses on the arrival link, the router is expected to try to
forward the packet to the destination on that link (subject to forward the packet to the destination on that link (subject to
successful determination of the destination's link-layer address via successful determination of the destination's link-layer address via
the Neighbor Discovery protocol [8]). The forwarded packet may be the Neighbor Discovery protocol [9]). The forwarded packet may be
transmitted back out the arrival interface, or out any other transmitted back out the arrival interface, or out any other
interface attached to the same link. interface attached to the 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 in the Routing Header and arrival interface of of the next address and the arrival interface of the packet. The
the packet. The next-hop interface is chosen just like the first next-hop interface is chosen just like the first bullet of the
bullet of the rules above. rules 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 just like 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 link-
local then the receiving node can know that the packet originated on- local then the receiving node can know that the packet originated on-
link. As a result, this will help the receiving node send a link. As a result, 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. For example, consider a case where a link-border node zone boundary in the previously-used next address field. For example,
(e.g., a router) receives a packet with the destination being a link- consider a case where a link-border node (e.g., a router) receives a
local address. If the packet contains a Routing Header where the packet with the destination being a link-local address, and the
next address is a global address, the next-hop interface to the source address a global address. If the packet contains a Routing
global address may belong to a different link than that of the Header where the next address is a global address, the next-hop
original destination. This is allowed, because the scope of the next interface to the global address may belong to a different link than
address is not smaller than the scope of the original destination. that of the original destination. This is allowed, because the scope
of the next address is not smaller than the scope of the original
destination.
10. Routing 10. Routing
Note: since unicast site-local addresses are deprecated, and link- Note: since unicast site-local addresses are deprecated, and
local addresses does not need routing, the discussion in this section link-local addresses do not need routing, the discussion in this
only applies to multicast scoped routing. section 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 In order to maintain connectivity, the routing protocol must be able
to create forwarding information for the global prefixes as well as to create forwarding information for the global groups as well as for
for all of the zone prefixes for each of its attached zones. The all of the scoped groups for each of its attached zones. The most
most straightforward way of doing this is to create (conceptual) straightforward way of doing this is to create (conceptual)
forwarding tables for each specific zone. forwarding tables for each specific zone.
To protect inter-zone integrity, routers must be selective in the To protect inter-zone integrity, routers must be selective in the
prefix information that is shared with neighboring routers. Routers group information that is shared with neighboring routers. Routers
routinely exchange routing information with neighboring routers. routinely exchange routing information with neighboring routers. When
When a router is transmitting this routing information, it must not a router is transmitting this routing information, it must not
include any information about zones other than the zones assigned to include any information about zones other than the zones assigned to
the interface used to transmit the information. the interface used to transmit the information.
---------------------------------------------------------------------
* * * *
* * * *
* =========== Organization X * * =========== Organization X *
* | | * * | | *
* | | * * | | *
+-*----|-------|------+ * +-*----|-------|------+ *
| * intf1 intf2 | * | * intf1 intf2 | *
| * | * | * | *
| * intf3 --- * | * intf3 --- *
| * | * | * | *
skipping to change at page 13, line 47 skipping to change at page 13, line 4
| Router | | Router |
| | | |
********************** ********************** ********************** **********************
| * * | | * * |
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
organization except global are not considered here): organization except global are not considered here):
o Interface 1 o Interface 1
* All global prefixes * All global groups
* All organization prefixes 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 prefixes * All global groups
* All organization prefixes learned from Interfaces 1, 2, and 3 * All organization groups learned from Interfaces 1, 2, and 3
o Interface 3 o Interface 3
* All global prefixes * All global groups
* All organization prefixes learned from Interface 1, 2, and 3 * All organization groups learned from Interfaces 1, 2, and 3
o Interface 4 o Interface 4
* All global prefixes * All global groups
* All organization prefixes learned from Interface 4 * All organization groups learned from Interface 4
o Interface 5 o Interface 5
* All global prefixes * All global groups
* All organization prefixes learned from Interfaces 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
skipping to change at page 15, line 30 skipping to change at page 14, line 32
the link attached to the loopback interface, thus the format should the link attached to the loopback interface, thus the format should
not be used for the loopback address either. This document does not not be used for the loopback address either. This document does not
specify the usage of the format when the <address> is the unspecified specify the usage of the format when the <address> is the unspecified
address, since the address does not have a scope. This document, address, since the address does not have a scope. This document,
however, does not prohibit an implementation from using the format however, does not prohibit an implementation from using the format
for those special addresses for implementation dependent purposes. for those special addresses for implementation dependent purposes.
11.2 Zone Indices 11.2 Zone Indices
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' scope. Although a zone identify a particular zone of the address's scope. Although a zone
index is expected to contain the scope type and to be unique among index is expected to contain the scope type and to be unique among
all scopes as described in Section 6 of this document, the <zone_id> all scopes as described in Section 6 of this document, the <zone_id>
part of this format does not have to contain the scope type because part of this format does not have to contain the scope type because
the <address> part should specify the appropriate scope. This also the <address> part should specify the appropriate scope. This also
means the <zone_id> part does not have to be unique among all scopes. means the <zone_id> part does not have to be unique among all scopes.
With this loosened property, an implementation can use convenient With this loosened property, an implementation can use 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 representation that contains the scope type more readable than other representation that contains the scope type
"link". "link".
When an implementation interprets the format, it should construct the When an implementation interprets the format, it should construct the
"full" zone ID, which contains the scope type, from the <zone_id> "full" zone ID, which contains the scope type, from the <zone_id>
part and the scope type specified by the <address> part. part and the scope type specified by the <address> part. (Remember
that a zone index itself should contain the scope type as specified
in Section 6.)
An implementation SHOULD support at least numerical indices as An implementation SHOULD support at least numerical indices as
<zone_id>, which are non-negative decimal integers. The default zone <zone_id>, which are non-negative decimal integers. The default zone
ID, which is typically expected to be 0, is included in the integers. ID, which should typically be 0 (see Section 6), is included in the
When <zone_id> is the default, the delimiter character, "%", and integers. When <zone_id> is the default, the delimiter character,
<zone_id> can be omitted. Similarly, if a textual representation of "%", and <zone_id> can be omitted. Similarly, if a textual
an IPv6 address is given without a zone ID, it should be interpreted representation of an IPv6 address is given without a zone ID, it
as <address>%<default ID> where <default ID> is the default zone ID should be interpreted as <address>%<default ID> where <default ID> is
of the scope that <address> has. the default zone ID of the scope that <address> 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 such additional
strings is implementation dependent. strings is implementation dependent.
One possible candidate of such strings would be interface names, One possible candidate of such strings would be interface names,
since interfaces uniquely disambiguate any type of scopes. In since interfaces uniquely disambiguate any type of scopes. In
particular, interface names can be used as "default identifiers" for particular, interface names can be used as "default identifiers" for
interfaces, links, and subnets, because there is, by default, a one- interfaces and links, because there is, by default, a one-to-one
to-one mapping between interfaces and each of those scopes as mapping between interfaces and each of those scopes as described in
described in Section 6. 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 subnets, but there might be some confusion in such larger scopes than links, but there might be some confusion in such
use. For example, when more than one interface belongs to a same use. For example, when more than one interface belongs to a 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 a same kind of problem, when it prints an address would encounter a 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 a same index is common to all nodes in a It cannot be assumed that a same index is common to 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 a wire unless every node that interprets node and MUST NOT be sent on a wire unless every node that interprets
the format agrees on the semantics. the format agrees on the semantics.
11.3 Examples 11.3 Examples
Here are examples. The following addresses Here are examples. The following addresses
fe80::1234 (on the 1st link of the node) fe80::1234 (on the 1st link of the node)
ff02::9abc (on the 5th link of the node) ff02::5678 (on the 5th link of the node)
ff08::def0 (on the 10th organization of the node) ff08::9abc (on the 10th organization of the node)
would be represented as follows:
fe80::1234%1
ff02::5678%5
ff08::9abc%10
(Here we assume a natual translation from a zone index to the (Here we assume a natual 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::9abc%pvc1.3 ff02::5678%pvc1.3
ff08::def0%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 like telnet,
ftp, and ssh, may not explicitly support the notion of address scope, ftp, and ssh, may not explicitly support the notion of address scope,
especially of link-local addresses. However, an expert user (e.g. a especially of link-local addresses. However, an expert user (e.g. a
network administrator) sometimes has to give even link-local 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, called "R2" and
"R3", respectively. Also assume that the point-to-point interfaces "R3", respectively. Also assume that the point-to-point interfaces
are "unnumbered", that is, they have link-local addresses only. have 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 a routing trouble and we cannot expect
that we have enough routes for global reachability to R2. that we 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 using
link-local addresses. In such a case, we have to give the link-local link-local addresses. In such a 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 like
% 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 connect. Instead, we cannot detect which link it should try to use for connecting.
should type the link-local address with the link index as follows: Instead, we should type the link-local address with the link index as
follows:
% telnet fe80::2%3 % telnet fe80::2%3
where "3" after the delimiter character `%' conrresponds to the link where "3" after the delimiter character `%' conrresponds to the link
index of the point-to-point link. index of the point-to-point link.
Another example is an EBGP peering. When two IPv6 ISPs establish an
EBGP peering, using a particular ISP's global addresses for the peer
would be unfair, and using their link-local addresses would be better
in a neutral IX. In such a case, link-local addresses should be
specified in a router's configuration file and the link for the
addresses should be disambiguated, since a router usually connects to
multiple links.
11.5 Related API 11.5 Related API
The "Basic Socket API" [5] defines how the format for non-global An extension to the recommended basic API defines how the format for
addresses should be treated in library functions that translate a non-global addresses should be treated in library functions that
nodename to an address, or vice versa. 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 ID, there can be no cases with the notion of the default zone ID, 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, and, as a result, it
can act as if it did not support the extended format at all. can act as if it did not support the extended format at all.
skipping to change at page 18, line 38 skipping to change at page 17, line 39
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 2nd
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 [5]. That is, we can first separate name-to-address library function [11]. That is, we can first separate
the address with the zone index from the prefix length, and just pass the address with the zone index from the prefix length, and just pass
the former to the library function. 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 URL's are also
defined [9]. When a user types the preferred format for an IPv6 non- defined [12]. When a user types the preferred format for an IPv6
global address whose zone should be explicitly specified, the user non-global address whose zone should be explicitly specified, the
could use the format for the non-global address combined with the user could use the format for the non-global address combined with
preferred format. the preferred format.
However, the typed URL is often sent on a wire, and it would cause However, the typed URL is often sent on a 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. Also, the format for non-global addresses might before sending. Note that the applications should not need to care
conflict with the URI syntax [10], since the syntax defines the about which kind of addresses they're using, much less parse or strip
delimiter character (`%') as the escape character. out the <zone_id> portion of the address. Also, the format for
non-global addresses might conflict with the URI syntax [13], since
the syntax defines the delimiter character (`%') as the escape
character.
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. As for the conflict issue with the URI format, it
would be better to wait until the relationship between the preferred would be better to wait until the relationship between the preferred
format and the URI syntax is clarified. In fact, the preferred format and the URI syntax is clarified. In fact, the preferred
format for IPv6 literal addresses itself has same kind of conflict. format for IPv6 literal addresses itself has same kind of conflict.
In any case, it is recommended to use an FQDN instead of a literal In any case, it is recommended to use an FQDN instead of a literal
IPv6 address in a URL, whenever an FQDN is available. IPv6 address in a URL, whenever an FQDN is available.
skipping to change at page 19, line 32 skipping to change at page 18, line 36
Since the use of the textual representation of non-global addresses Since the use of the textual representation of non-global addresses
is restricted within a single node, it does not create a security is restricted within a single node, it does not create a security
vulnerability from outside the node. However, a malicious node might vulnerability from outside the node. However, a malicious node might
send a packet that contains a textual IPv6 non-global address with a send a packet that contains a textual IPv6 non-global address with a
zone index, intending to deceive the receiving node about the zone of zone index, intending to deceive the receiving node about the zone of
the non-global address. Thus, an implementation should be careful the non-global address. Thus, an implementation should be careful
when it receives packets that contain textual non-global addresses as when it receives packets that contain textual non-global addresses as
data. data.
13. Acknowledgements 13. Contributors
This document is a combination of several separate efforts. Atsushi
Onoe took a significant role in one of them, and deeply contributed
to the content of Section 11 as a co-author of a separate proposal.
14. Acknowledgements
Many members the IPv6 working group provided useful comments and Many members 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. in terms of related API. Pekka Savola reviewed a draft of the
document very carefully, and made detailed comments including serious
problems.
Normative References 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", RFC 2119, BCP 14, March 1999. Levels", RFC 2119, BCP 14, March 1999.
[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 (ICMPv6) for [4] Conta, A. and S. Deering, "Internet Control Message (ICMPv6) for
the Internet Protocol Version 6 (IPv6)", Internet Draft draft- the Internet Protocol Version 6 (IPv6) Specification", RFC 2463,
ietf-ipngwg-icmp-v3-02.txt, November 2001. December 1998.
[5] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens,
"Basic Socket Interface Extensions for IPv6", RFC 3493, February
2003.
Informative References Informative References
[6] Conta, A., "Generic Packet Tunneling in IPv6 Specification", [5] Huitema, C. and B. Carpenter, "Deprecating Site Local
RFC 2473, December 1998. Addresses", draft-ietf-ipv6-deprecate-site-local-02.txt (work
in progress), November 2003.
[7] 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.
[8] Narten, T., "Neighbor Discovery for IP Version 6 (IPv6)", RFC [7] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
of Link-Local IPv4 Addresses",
draft-ietf-zeroconf-ipv4-linklocal-12.txt (work in progress),
January 2004.
[8] Conta, A., "Generic Packet Tunneling in IPv6 Specification",
RFC 2473, December 1998.
[9] Narten, T., "Neighbor Discovery for IP Version 6 (IPv6)", RFC
2461, December 1998. 2461, December 1998.
[9] Hinden, R., Carpenter, B. and L. Masinter, "Preferred Format [10] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003.
[11] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W.
Stevens, "Scoped Address Extensions to the IPv6 Basic Socket
API", Internet-Draft <draft-ietf-ipv6-scope-api-00.txt, July
2002.
[12] Hinden, R., Carpenter, B. and L. Masinter, "Preferred Format
for Literal IPv6 Addresses in URL's", RFC 2732, December 1999. for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[10] 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 2396, August
1998. 1998.
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
skipping to change at page 21, line 23 skipping to change at page 21, line 4
Erik Nordmark Erik Nordmark
Sun Microsystems Laboratories, Europe Sun Microsystems Laboratories, Europe
180, avenue de l'Europe 180, avenue de l'Europe
SAINT ISMIER Cedex 38334 SAINT ISMIER Cedex 38334
France France
Phone: +33 (0)4 74 18 88 03 Phone: +33 (0)4 74 18 88 03
Fax: +33 (0)4 76 18 88 88 Fax: +33 (0)4 76 18 88 88
EMail: Erik.Nordmark@sun.com EMail: Erik.Nordmark@sun.com
Atsushi Onoe
IT Development Division, NSC, Sony Corporation
6-7-35 Kitashinagawa, Kawasaki-shi
Tokyo 141-0001
Japan
Phone: +81-3-5475-8491
Fax: +81-3-5475-8977
EMail: onoe@sm.sony.co.jp
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
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any 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 such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement Acknowledgement
 End of changes. 

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