< draft-ietf-ipngwg-scoping-arch-02.txt   draft-ietf-ipngwg-scoping-arch-03.txt >
IPNGWG Working Group S. Deering IPNGWG Working Group S. Deering
Internet Draft Cisco Systems Internet Draft Cisco Systems
draft-ietf-ipngwg-scoping-arch-02.txt B. Haberman draft-ietf-ipngwg-scoping-arch-03.txt B. Haberman
March 2001 Nortel Networks November 2001 No Affiliation
Expires September 2001 T. Jinmei Expires May 2002 T. Jinmei
Toshiba Toshiba
E. Nordmark E. Nordmark
Sun Microsystems Sun Microsystems
A. Onoe A. Onoe
Sony Sony
B. Zill B. Zill
Microsoft Microsoft
IPv6 Scoped Address Architecture IPv6 Scoped Address Architecture
skipping to change at line 138 skipping to change at line 138
of topology. For example, a site may consist of a single link, in of topology. For example, a site may consist of a single link, in
which both link-local and site-local scope effectively cover the same which both link-local and site-local scope effectively cover the same
topological span. 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 a simply a zone, is a connected region of topology
of a given scope. For example, the set of links connected by routers of a given scope. For example, the set of links connected by routers
within a particular site, and the interfaces attached to those links, within a particular site, and the interfaces attached to those links,
comprise a single zone of site-local scope. Note that a zone is a comprise a single zone of site-local scope. Note that a zone is a
particular instance of a topological region (e.g., AliceÆs site or particular instance of a topological region (e.g., Alice's site or
BobÆs site), whereas a scope is the size of a topological region Bob's site), whereas a scope is the size of a topological region
(i.e., a site or a link or a ...). (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, Alice's site and Bob's site may zones of that scope. For example, Alice's site and Bob's site may
each contain a node with site-local address fec0::1. each contain a node with site-local address fec0::1.
Zones of the different scopes are instantiated as follows: Zones of the different scopes are instantiated as follows:
skipping to change at line 194 skipping to change at line 194
interface-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 o Zones of the same scope cannot overlap, i.e., they can
have no links or interfaces in common. have no links or interfaces in common.
o A zone of a given scope (less than global) falls o A zone of a given scope (less than global) falls
completely within zones of larger scope, i.e., a smaller completely within zones of larger scope, i.e., a smaller
scope zone cannot include more topology than any larger scope zone cannot include more topology than any larger
scope zone with which it shares any links or interfaces. scope zone with which it shares any links or interfaces.
o Each zone is required to be "convex" from a routing
perspective, i.e., packets sent from one interterface to
any other interface in 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.
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 4
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 site-local in more than one zone of the same scope (e.g., the use of site-local
address fec0::1 in both Alice's site and Bob's site), and that a node address fec0::1 in both Alice's site and Bob's site), and that a node
may have interfaces attached to different zones of the same scope may have interfaces attached to different zones of the same scope
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 4
(e.g., having one interface attached to Alice's site and another to (e.g., having one interface attached to Alice's site and another to
Bob's site), a node requires an internal means of identifying to Bob's site), a node requires an internal means of identifying to
which zone a non-global address belongs. This is accomplished by which 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:
skipping to change at line 249 skipping to change at line 253
phantom link that goes nowhere), phantom link that goes nowhere),
o Two interfaces to the same Ethernet, o Two interfaces to the same Ethernet,
o An interface to a point-to-point link, and o An interface to a point-to-point link, and
o A tunnel interface (e.g., the abstract endpoint of an o A tunnel interface (e.g., the abstract endpoint of an
IPv6-over-IPv6 tunnel [RFC 2473], presumably established IPv6-over-IPv6 tunnel [RFC 2473], presumably established
over either the Ethernet or the point-to-point link.) over either the Ethernet or the point-to-point link.)
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 5
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.
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 5
It is attached to two site-local zones: one to which the loopback It is attached to two site-local zones: one to which the loopback
link, the Ethernet, and the point-to-point link belong, and one to link, the Ethernet, and the point-to-point link belong, and one to
which the tunnel belongs (perhaps because it is a tunnel to another which the tunnel belongs (perhaps because it is a tunnel to another
organization). These site-local zones are identified by the site organization). These site-local zones are identified by the site
indices 1 and 2. indices 1 and 2.
Note that each attached zone of the same scope must be assigned a Note that each attached zone of the same scope must be assigned a
different index value, whereas attached zones of different scopes can different index value, whereas attached zones of different scopes can
re-use the same index. re-use the same index.
skipping to change at line 302 skipping to change at line 306
o A unique subnet (multicast "scop" value 3) index for each o A unique subnet (multicast "scop" value 3) index for each
interface 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 a
single subnet, interfaces to different sites, or interfaces to zones single subnet, interfaces to different sites, or 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
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 6
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.
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 6
--------------------------------------------------------------- ---------------------------------------------------------------
| a node | | a node |
| | | |
| | | |
| | | |
| | | |
| | | |
| /-subnet1-\ /-subnet2-\ /-subnet3-\ /-subnet4-\ /-subnet5-\ | | /-subnet1-\ /-subnet2-\ /-subnet3-\ /-subnet4-\ /-subnet5-\ |
| | | |
| /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ | | /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\ |
skipping to change at line 340 skipping to change at line 345
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, link2, and subnet2
as the default zones for each of those three scopes. (Perhaps the as the default zones for each of those three scopes. (Perhaps the
selection algorithm is to choose the first zone that includes an selection algorithm is to choose the first zone that includes an
interface other than the loopback interface as the default for each interface other than the loopback interface as the default for each
scope.) A means must also be provided for manually assigning the scope.) A means must also be provided for manually assigning the
default zone for a scope, overriding any automatic assignment. default zone for a scope, overriding any automatic assignment.
Because the unicast loopback address, ::1, may not be assigned to Because the unicast loopback address, ::1, may not be assigned to any
any interface other than the loopback interface, it is recommended interface other than the loopback interface, it is recommended that
that whenever ::1 is specified without a zone index, or with the whenever ::1 is specified without a zone index, or with the default
default zone index, that it be interpreted as belonging to the zone index, that it be interpreted as belonging to the loopback link-
loopback link-local zone, regardless of which link-local zone has local zone, regardless of which link-local zone has been selected as
been selected as the default. If this is done, then in the common the default. If this is done, then in the common case of nodes with
case of nodes with only a single non-loopback interface (e.g., a only a single non-loopback interface (e.g., a single Ethernet
single Ethernet interface), it becomes possible to avoid any need interface), it becomes possible to avoid any need to qualify link-
to qualify link-local addresses with a zone index: the unqualified local addresses with a zone index: the unqualified address ::1 would
address ::1 would always refer to the link-local zone containing always refer to the link-local zone containing the loopback
the loopback interface, and all other unqualified link-local interface, and all other unqualified link-local addresses would refer
addresses would refer to the link-local zone containing the non- to the link-local zone containing the non-loopback interface (as long
loopback interface (as long as the default link-local zone were set as the default link-local zone were set to be the zone containing the
to be the zone containing the non-loopback interface). non-loopback interface).
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 7
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
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 7
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, the manual assignment of distinct site- smaller scopes. For example, the manual assignment of distinct site-
local indices 1 and 2 in the node in Figure 1 would cause the local indices 1 and 2 in the node in Figure 1 would cause the
automatic creation of corresponding admin-local (i.e. multicast automatic creation of corresponding admin-local (i.e. multicast
"scop" value 4) indices 1 and 2, because admin-local scope is smaller "scop" value 4) indices 1 and 2, because admin-local scope is smaller
than site-local scope. 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
skipping to change at line 406 skipping to change at line 410
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, starting at one, the zone index values are values sequentially, starting at one, the zone index values are
arbitrary. An implementation may use any value it chooses to label a arbitrary. An implementation may use any value it chooses to label a
zone as long as it meets the requirement that the index value of each zone as long as it meets the requirement that the index value of each
attached zone of the same scope be unique within the node. attached zone of the same scope be unique within the node.
Similarly, an implementation may choose an index value other than Similarly, an implementation may choose an index value other than
zero to represent the default zone. Implementations choosing to zero to represent the default zone. Implementations choosing to
follow the recommended basic API [RFC 2553] will want to restrict follow the recommended basic API [BASICAPI] will want to restrict
their index values to those that can be represented by the their index values to those that can be represented by the
sin6_scope_id field of a sockaddr_in6. sin6_scope_id field of a sockaddr_in6.
(Authors' note to selves: The Working Group seemed to be
in favor of allowing all zone indices for all scopes to
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 8 Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 8
have unique values in a sin6 scope id field, e.g., by
using the first four bits of the scope id to identify the
scope [using the same encoding as the scop field in
multicast addresses], and placing the zone id in the
remaining 28 bits. This would probably be best specified
the advanced API spec, rather than here.)
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
more than one zone of each scope), that is more specific than desired more than one zone of each scope), that is more specific than desired
skipping to change at line 461 skipping to change at line 455
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 o The zone of the destination address is determined by the
scope of the address and arrival interface of the packet. scope of the address and arrival interface of the packet.
The next-hop interface is chosen by looking up the The next-hop interface is chosen by looking up the
destination address in a (conceptual) routing table destination address in a (conceptual) routing table
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 9
specific to that zone. That routing table is restricted specific to that zone. That routing table is restricted
to refer only to interfaces belonging to that zone. to refer only to interfaces belonging to that zone.
o After the next-hop interface is chosen, the zone of the o After the next-hop interface is chosen, the zone of the
source address is considered. As with the destination source address is considered. As with the destination
address, the zone of the source address is determined by address, the zone of the source address is determined by
the scope of the address and arrival interface of the the scope of the address and arrival interface of the
packet. If transmitting the packet on the chosen next-hop packet. If transmitting the packet on the chosen next-hop
interface would cause the packet to leave the zone of the interface would cause the packet to leave the zone of the
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 9
source address, i.e., cross a zone boundary of the scope source address, i.e., cross a zone boundary of the scope
of the source address, then the packet is discarded and an of the source address, then the packet is discarded and an
ICMP Destination Unreachable message [RFC 2463] with Code ICMP Destination Unreachable message [RFC 2463] with Code
2 ("beyond scope of source address") is sent to the source 2 ("beyond scope of source address") is sent to the source
of the packet. of the packet.
Note that the above procedure applies for addresses of all scopes, Note that the above procedure applies for addresses of all scopes,
including link-local. Thus, if a router receives a packet with a including link-local. 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 link-local addresses on the arrival link, the router is expected to
skipping to change at line 514 skipping to change at line 508
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 prefixes as well as
for all of the zone prefixes for each of its attached zones. The for all of the zone prefixes for each of its attached zones. The
most straightforward way of doing this is to create (conceptual) most straightforward way of doing this is to create (conceptual)
forwarding tables for each specific zone. forwarding tables for each specific zone.
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 10
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 prefix information that is shared with neighboring routers. Routers
routinely exchange routing information with neighboring routers. routinely exchange routing information with neighboring routers.
When a router is transmitting this routing information, it must not When 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.
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 10
* * * *
* * * *
* =========== Site X * * =========== Site X *
* | | * * | | *
* | | * * | | *
+-*----|-------|------+ * +-*----|-------|------+ *
| * intf1 intf2 | * | * intf1 intf2 | *
| * | * | * | *
| * intf3 --- * | * intf3 --- *
| * | * | * | *
skipping to change at line 565 skipping to change at line 559
o Interface 2 o Interface 2
o All global prefixes o All global prefixes
o All site prefixes learned from Interfaces 1, 2, and 3 o All site prefixes learned from Interfaces 1, 2, and 3
o Interface 3 o Interface 3
o All global prefixes o All global prefixes
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 11
o All site prefixes learned from Interface 1, 2, and 3 o All site prefixes learned from Interface 1, 2, and 3
o Interface 4 o Interface 4
o All global prefixes o All global prefixes
o All site prefixes learned from Interface 4 o All site prefixes learned from Interface 4
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 11
o Interface 5 o Interface 5
o All global prefixes o All global prefixes
o All site prefixes learned from Interfaces 5 o All site prefixes learned from Interfaces 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. Mobility 11. Mobility
A mobile node that moves outside its "home site" must maintain the A mobile node using [MOBILE] that moves outside its "home site"
"home site-local addresses" for continued communication with nodes in should not expect to be able to send and receive packets as if it had
its "home site". This implies that such a mobile node conceptually remained in the zone. In particular, the mobile node MUST NOT try to
will have one interface (for the traffic destined to and from its have a tunnel back into its old zone for the purposes of attempting
home site) which is assigned the home site-local addresses in such communication. This also implies that the mobile node should
addition to its other interfaces which might be part of the visited choose global addresses as home address whenever possible. This
site. restriction should apply whether the scope of the zone is link-local
or site-local.
A mobile node may choose to autoconfigure site-local addresses in the
visited site. However, such addresses add complexity to the mobile
node with little or no benefit. Thus it is recommended that mobile
nodes only autoconfigure global addresses when moving to links
outside its home site.
A mobile node needs to be able to detect when it has moved to a
different site. Thus in addition to the regular movement detection
in [MOBILE] it should inspect the site prefixes in the Router
Advertisement messages to determine when it is outside its home site.
(Authors' note to selves: complete section description on Since there is no standard way to provide an ability to tell whether
mobility aspects) a mobile node is in its home site and/or whether a correspondent node
is in the same site as the mobile node, the mobile node should always
use a global care-of address.
12. Textual Representation 12. 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.
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 12
<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 scope zone of the <zone_id> is a string to identify the scope type and zone of
address, and the address, and
`%' is a delimiter character to distinguish between <address> `%' is a delimiter character to distinguish between <address>
and <zone_id>. and <zone_id>.
The following subsections describe detail definitions, concrete The following subsections describe detail definitions, concrete
examples, and additional notes of the format. examples, and additional notes of the format.
12.1 Non-Global Addresses 12.1 Non-Global Addresses
The format is applied to all kinds of unicast and multicast addresses The format is applied to all kinds of unicast and multicast addresses
of non-global scope. Although the format is meaningless and should of non-global scope. Although the format is meaningless and should
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 12
not be used for global addresses, an implementation which handles not be used for global addresses, an implementation which handles
addresses (e.g. name to address mapping functions) MAY allow users to addresses (e.g. name to address mapping functions) MAY allow users to
use such a notation. use such a notation.
12.2 Zone Indices 12.2 Zone Indices
In the textual representation, a zone index should be able to
identify a particular type of scope and a particular zone of the
scope. Note that the representation contains the type of scope as
well as the identifier within the particular scope type. This can be
useful, for example, when the zone index without an address is used
in a Management Information Base (MIB).
The actual representation of the zone indices, including how to
specify the scope type, is implementation dependent. But one
possible example would be to use an integer in which the upper-most 4
bits specifies the scope type just like the "scop" subfield of
multicast addresses and the rest of the value specifies a particular
zone of the scope. For instance, site zones in Figure 1 of Section 6
can be represented as 32-bit integers 50000001 and 50000002 (in
hexadecimal), which designate site1 and site2, respectively.
When a zone index is used with an address in the form of
<address>%<zone_id>, the scope type of the address MUST be equal to
the scope type of the zone index. An implementation SHOULD check the
consistency when it interprets the format.
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. Positive indices <zone_id>, which are non-negative decimal integers. Positive indices
MUST uniquely specify a single zone for a given address. An MUST uniquely specify a single zone of a single scope type. An
implementation MAY use zero ("0") to specify a "default" zone as implementation MAY use zero ("0") to specify a "default" zone as
described in Section 6 of this document. described in Section 6 of this document. In this case, the
corresponding scope type is the scope type of the <address> part.
Since the identifiers contain scope type values, the decimal integers
may not be intuitive for operators. For example, if the upper-most 4
bits were used for the scope type values, "site1" would be
represented as 1342177281 (which is 50000001 in hexadecimal).
In order to improve the readability, this document also defines
aliases for the decimal representation. The alias is constructed by
concatenating a string and a decimal number, where the string
specifies the scope type and the number identifies a particular zone
of the scope. Today there are five non-global scope types defined;
interface-local, link-local, subnet-local, admin-local, and
organization-local, and this document defines five scope type strings
accordingly; "intf", "link", "sbnt", "admn", "site", and "orgn".
Using this alias, a string "site1" can be used as well as
"1342177281" in the example above. An alias string for the global
scope is intentionally undefined, since there is no ambiguity about
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 13
the global scope and it is practically expected zone indices are
omitted for global addresses.
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 semantics of such additional strings is character or with the aliases. The precise format and semantics of
implementation dependent. such additional 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, if an implementation can assume that there is a one-to- particular, interface names can be used as "default identifiers" for
one mapping between links and interfaces (and the assumption is interfaces, links, and subnets, because there is, by default, a one-
usually reasonable,) using interface names as link indices would be to-one mapping between interfaces and each of those scopes as
natural. 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 larger scopes than subnets, 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
site, a user would be confused about which interface should be used. site, a user would be confused about which interface should be used.
Also, a mapping function from an address to a name would encounter a Also, a mapping function from an address to a name would encounter a
same kind of problem, when it prints an address with an interface same kind of problem, when it prints an address with an interface
name as a zone index. This document does not specify how these cases name as a zone index. This document does not specify how these cases
should be treated and leaves it implementation dependent. should be treated and leaves it implementation dependent.
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 13
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. node and MUST NOT be sent on a wire unless every node that interprets
the format agrees with the semantics.
12.3 Examples 12.3 Examples
Here are examples. The following addresses Here are examples. The following addresses
fe80::1234 (whose link index is 1) fe80::1234 (on the 1st link of the node)
fec0::5678 (whose site index is 2) fec0::5678 (on the 2nd site of the node)
ff02::9abc (whose link index is 5) ff02::9abc (on the 5th link of the node)
ff08::def0 (whose organization index is 10) ff08::def0 (on the 10th organization of the node)
would be represented as follows: would be represented as follows:
fe80::1234%1 fe80::1234%536870913 or fe80::1234%link1
fec0::5678%2 fec0::5678%1342177282 or fec0::5678%site2
ff02::9abc%5 ff02::9abc%536870917 or ff02::9abc%link5
ff08::def0%10 ff08::def0%2147483658 or ff08::def0%orgn10
(Here we assume 32-bit integers as zone indices with the upper-most 4
bits specifying the scope type.)
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:
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 14
fe80::1234%ne0 fe80::1234%ne0
fec0::5678%ether2 fec0::5678%ether2
ff02::9abc%pvc1.3 ff02::9abc%pvc1.3
ff08::def0%interface10 ff08::def0%interface10
where the interface "ne0" belongs to link 1, "ether2" belongs to site where the interface "ne0" belongs to 1st link, "ether2" belongs to
2, and so on. 2nd site, and so on.
12.4 Usage Examples 12.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. are "unnumbered", that is, they 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.
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 14
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 connect. Instead, we
should type the link-local address with the link index as follows: should type the link-local address with the link index as follows:
% telnet fe80::2%3 % telnet fe80::2%link3
where 3 after the delimiter character `%' is the link index of the where "link3" after the delimiter character `%' is the link index of
point-to-point link. the point-to-point link.
Another example is an EBGP peering. When two IPv6 ISPs establish an Another example is an EBGP peering. When two IPv6 ISPs establish an
EBGP peering, using a particular ISP's global addresses for the peer EBGP peering, using a particular ISP's global addresses for the peer
would be unfair, and using their link-local addresses would be better 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 in a neutral IX. In such a case, link-local addresses should be
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 15
specified in a router's configuration file and the link for the specified in a router's configuration file and the link for the
addresses should be disambiguated, since a router usually connects to addresses should be disambiguated, since a router usually connects to
multiple links. multiple links.
12.5 Related API 12.5 Related API
The "Basic Socket API" [BASICAPI] defines how the format for non- The "Basic Socket API" [BASICAPI] defines how the format for non-
global addresses should be treated in library functions that global addresses should be treated in library functions that
translate a nodename to an address, or vice versa. translate a nodename to an address, or vice versa.
12.6 Omitting Zone Indices 12.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 scope index portion. An implementation SHOULD rather provide a the zone index portion. An implementation SHOULD rather provide a
user with a "default" zone of each scope and allow the user to omit user with a "default" zone of each scope and allow the user to omit
zone indices in textual representations. zone indices in textual representations.
Also, when an implementation can assume that there is no ambiguity of Also, when an implementation can assume that there is no ambiguity of
any type of scopes on a node, it MAY even omit the whole any type of scopes on a node, it MAY even omit the whole
functionality to handle the format. An end host with a single functionality to handle the format. An end host with a single
interface would be an example of such a case. interface would be an example of such a case.
12.7 Combinations of Delimiter Characters 12.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.
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 15
The IPv6 addressing architecture [ADDRARCH] also defines the syntax The IPv6 addressing architecture [ADDRARCH] also defines the syntax
of IPv6 prefixes. If the address portion of a prefix is non-global of IPv6 prefixes. If the address portion of a prefix is non-global
and its scope zone should be disambiguated, the address portion and its scope zone should be disambiguated, the address portion
SHOULD be in the format. For example, the prefix fec0:0:0:1::/64 on SHOULD be in the format. For example, the prefix fec0:0:0:1::/64 on
a site whose index is 2 should be represented as follows: the 2nd site should be represented as follows:
fec0:0:0:1::%2/64 fec0:0:0:1::%site2/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 [RFC2553BIS]. That is, we can first name-to-address library function [BASICAPI]. 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 URL's are also
defined [RFC 2732]. When a user types the preferred format for an defined [RFC 2732]. When a user types the preferred format for an
IPv6 non-global address whose zone should be explicitly specified, IPv6 non-global address whose zone should be explicitly specified,
the user could use the format for the non-global address combined the user could use the format for the non-global address combined
with the preferred format. with 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
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 16
before sending. Also, the format for non-global addresses might before sending. Also, the format for non-global addresses might
conflict with the URI syntax [RFC 2396], since the syntax defines the conflict with the URI syntax [RFC 2396], since the syntax defines the
delimiter character (`%') as the escape character. 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.
13. Related Documents 13. Related Documents
The following documents have aspects related to IPv6 address scope, The following documents have aspects related to IPv6 address scope,
but are not cited elsewhere in this document: but are not cited elsewhere in this document:
o Site Prefixes in Neighbor Discovery, draft-ietf-ipngwg-
site-prefixes-06.txt
o Default Address Selection for IPv6, draft-ietf-ipngwg- o Default Address Selection for IPv6, draft-ietf-ipngwg-
default-addr-select-02.txt default-addr-select-06.txt
o Advanced Sockets API for IPv6, draft-ietf-ipngwg-
rfc2292bis-02.txt
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 16
14. Security Considerations 14. Security Considerations
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 that allow routers to prevent zone-specific information from leaking
out of each site. If site boundary routers allow site routing out of each site. If site boundary routers allow site routing
information to be forwarded outside of the site, the integrity of the information to be forwarded outside of the site, the integrity of the
site could be compromised. 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 within a single node, it does not create a security is restricted within a single node, it does not create a security
skipping to change at line 846 skipping to change at line 875
15. References 15. References
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP14, March 1999. Requirement Levels", RFC 2119, BCP14, March 1999.
[ADDRARCH] Hinden, R., and Deering, S., "IP Version 6 Addressing [ADDRARCH] Hinden, R., and Deering, S., "IP Version 6 Addressing
Architecture", Internet Draft, draft-ietf-ipngwg-addr- Architecture", Internet Draft, draft-ietf-ipngwg-addr-
arch-v3-04.txt, February 2001. arch-v3-04.txt, February 2001.
[RFC 2460] Deering, S., and Hinden, R., "Internet Protocol Version [RFC 2460] Deering, S., and Hinden, R., "Internet Protocol Version
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 17
6 (IPv6) Specification", RFC 2460, December 1998. 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC 2473] Conta, A., and Deering, S., "Generic Packet Tunneling in [RFC 2473] Conta, A., and Deering, S., "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC 2463] Conta, A., and Deering, S., "Internet Control Message [RFC 2463] Conta, A., and Deering, S., "Internet Control Message
Protocol (RFC 2463) for Internet Protocol Version 6 Protocol (RFC 2463) for Internet Protocol Version 6
(IPv6)", RFC 2463, December 1998. (IPv6)", RFC 2463, December 1998.
[RFC 2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor [RFC 2461] Narten, T., Nordmark, E., and Simpson, W., "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998. 1998.
[RFC 2553] Gilligan, R., Thomson, S., Bound, J., and Stevens, W.,
"Basic Socket Interface Extensions for IPv6", RFC 2553,
March 1999.
[MOBILE] Johnson, D.B., and Perkins, C., "Mobility Support in [MOBILE] Johnson, D.B., and Perkins, C., "Mobility Support in
IPv6", Internet Draft, draft-ietf-mobileip-ipv6-13.txt, IPv6", Internet Draft, draft-ietf-mobileip-ipv6-14.txt,
November 2000. July 2001.
[BASICAPI] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W., [BASICAPI] Gilligan, R. E., Thomson, S., Bound, J., Stevens, W.,
"Basic Socket Interface Extensions for IPv6", Internet "Basic Socket Interface Extensions for IPv6", Internet
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 17
Draft, draft-ietf-ipngwg-rfc2553bis-03.txt, February 2001. Draft, draft-ietf-ipngwg-rfc2553bis-03.txt, February 2001.
[RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Preferred [RFC 2732] Hinden, R., Carpenter, B., Masinter, L., "Preferred
Format for Literal IPv6 Addresses in URL's", RFC 2732, Format for Literal IPv6 Addresses in URL's", RFC 2732,
December 1999. December 1999.
[RFC 2396] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform [RFC 2396] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396, Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998. August 1998.
skipping to change at line 896 skipping to change at line 921
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
Phone: +1-408-527-8213 Phone: +1-408-527-8213
Fax: +1-408-527-8213 Fax: +1-408-527-8213
Email: deering@cisco.com Email: deering@cisco.com
Brian Haberman Brian Haberman
Nortel Networks No Affiliation
4309 Emperor Blvd.
Suite 200
Durham, NC 27703
USA
Phone: +1-919-992-4439 Phone: +1-919-949-4828
Fax: +1-919-992-9080 Email: haberman@innovationslab.net
Email: haberman@nortelnetworks.com
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 18
Tatuya JINMEI Tatuya JINMEI
Corporate Research & Development Center, Toshiba Corporation Corporate Research & Development Center, Toshiba Corporation
1 Komukai Toshiba-cho, Kawasaki-shi 1 Komukai Toshiba-cho, Kawasaki-shi
Kanagawa 212-8582, JAPAN Kanagawa 212-8582, 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 Sun Microsystems Laboratories, Europe
901 San Antonio Road 29 Chemin du Vieux Chene
Palo Alto, CA 94303 38240 Meylan, France
Deering, Haberman, Jinmei, Nordmark, Onoe, Zill 18
USA
Phone: +1-650-786-5166 Phone: +33 (0)4 76 18 88 03
Fax: +1-650-786-5896 Fax: +33 (0)4 76 18 88 88
Email: nordmark@sun.com Email: Erik.Nordmark@sun.com
Atsushi Onoe Atsushi Onoe
Internet Systems Laboratory, IN Laboratories, Sony Corporation IT Development Division, NSC, Sony Corporation
6-7-35 Kitashinagawa, Shinagawa-ku 6-7-35 Kitashinagawa, Shinagawa-ku
Tokyo 141-0001, JAPAN Tokyo 141-0001, JAPAN
Phone: +81-3-5448-4620 Phone: +81-3-5475-8491
Fax: +81-3-5448-4622 Fax: +81-3-5475-8977
Email: onoe@sm.sony.co.jp 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
 End of changes. 62 change blocks. 
131 lines changed or deleted 149 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/