GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4007

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:
  1. ————————————————————–

| 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

  1. ————————————————————–

| a node |

    |                                                               |
    |                                                               |
    |                                                               |
    |                                                               |
    |                                                               |
    |  /--link1--\ /--link2--\ /--link3--\ /--link4--\ /--link5--\  |
    |                                                               |
    |  /--intf1--\ /--intf2--\ /--intf3--\ /--intf4--\ /--intf5--\  |
     ---------------------------------------------------------------
            :           |           |           |           |
            :           |           |           |           |
            :           |           |           |           |
        (imaginary    =================      a point-       a
         loopback        an Ethernet         to-point     tunnel
           link)                               link
           Figure 2: Example of Default Zone Indices
 As well as initially assigning zone indices, as specified above, an
 implementation should automatically select a default zone for each
 scope for which there is more than one choice, to be used whenever an
 address is specified without a zone index (or with a zone index of
 zero).  For instance, in the example shown in Figure 2, the
 implementation might automatically select intf2 and link2 as the
 default zones for each of those two scopes.  (One possible selection
 algorithm is to choose the first zone that includes an interface
 other than the loopback interface as the default for each scope.)  A
 means must also be provided to assign the default zone for a scope
 manually, overriding any automatic assignment.
 The unicast loopback address, ::1, may not be assigned to any
 interface other than the loopback interface.  Therefore, it is
 recommended that, whenever ::1 is specified without a zone index or
 with the default zone index, it be interpreted as belonging to the
 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.
  1. ————————————————————–

| 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4007.txt · Last modified: 2005/03/11 20:30 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki