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