IPv6 Scoped Address Architecture
updated by
Extracted elements (29)
Routing for multicast requires per-zone conceptual forwarding tables. The most straightforward design creates a distinct forwarding table for each specific zone, ensuring that zone-specific routing information (e.g., site-local multicast groups) does not leak across zone boundaries. The routing section only applies to multicast because unicast site-local is deprecated and link-local does not require routing.
The document deliberately does not specify how the '<address>%<zone_id>' format should be combined with the RFC 2732 preferred format for literal IPv6 addresses in URLs. The '%' character conflicts with URI percent-encoding (so zone 1 would require '%251'), causing parsing problems for applications, URI parsers, and name-to-address libraries. FQDN use is recommended instead of literal addresses in URLs.
The document intentionally avoids the syntax and usage of unicast site-local addresses because the IPv6 working group decided to deprecate them (RFC 3879). Only link-local and multicast scopes are addressed here; future local addressing schemes will be documented separately.
The unicast loopback address ::1 is treated as having link-local scope within an imaginary link attached to a virtual loopback interface. When ::1 is specified without a zone index, it should always be interpreted as belonging to the loopback link-local zone. This allows single-interface nodes to use link-local addresses without zone indices in the common case.
The <zone_id> part of the textual format does not need to encode scope (even though an internal zone index should). Since the <address> part already specifies the scope, the <zone_id> can be a simple integer like '2', which is more readable than a representation that redundantly embeds the scope name. The implementation reconstructs the full zone index from <address> scope + <zone_id>.
Zone boundaries cut through nodes rather than links because a node can have multiple interfaces on the same link (e.g., two Ethernet interfaces on the same Ethernet). If boundaries cut through links, such a node could not belong to the same link-local zone on both interfaces, which is the correct and expected behavior.
Zones are defined to be relatively static, not changing in response to short-term topology changes. A partitioned zone (e.g., due to router failure) is still considered one zone, not two. A residential node that dials up to an employer's site is considered part of that site-local zone even when disconnected, because zones represent administrative policy, not transient connectivity.
Applications such as telnet, ftp, and ssh may not explicitly support address scope. When connecting to a node via a link-local address (e.g., for management during routing failures), the zone must be appended manually using the '%<zone_id>' syntax (e.g., 'telnet fe80::2%3'), because the application cannot determine which link to use without it.
Zone indices are strictly local to each node. Two nodes attached to the same link will generally assign different zone index values to that link. Therefore, '<address>%<zone_id>' textual representations must never be sent on the wire or exchanged between nodes unless all receiving nodes agree on the index-to-zone mapping.
An implementation SHOULD support at least non-negative decimal integers as <zone_id>. An implementation MAY support other non-null strings (such as interface names) as <zone_id>, but these must not conflict with the '%' delimiter character; precise format and semantics are implementation dependent.
The '<address>%<zone_id>' textual format MUST be used only within a single node and MUST NOT be sent on the wire unless every node that will interpret the format agrees on the semantics. Zone indices are strictly local, so the same index value may refer to different zones on different nodes.
To specify an IPv6 non-global address without ambiguity, an implementation SHOULD support the textual format '<address>%<zone_id>' where '%' is the delimiter, <address> is the literal IPv6 address, and <zone_id> is a string identifying the zone. This format applies to all unicast and multicast addresses of non-global scope except the unspecified address.
When a node receives a packet with a Routing Header with more than zero Segments Left and the scope of the next address in the Routing Header is smaller than the scope of the original destination address, the node MUST discard the packet. This prevents using a Routing Header to smuggle a non-global address across its zone boundary as a 'previously used' address.
When a non-global address forms part of an IPv6 prefix and its scope zone should be disambiguated, the address portion of the prefix SHOULD be in the '<address>%<zone_id>' format, with the zone index portion placed before the prefix length: e.g., 'fe80::%2/64'. The zone index must precede the '/' to allow correct parsing by name-to-address library functions.
When a router forwards a packet and transmitting it on the chosen next-hop interface would cause the packet to leave the zone of the source address (cross a source zone boundary), the router MUST discard the packet. If the destination is unicast, an ICMP Destination Unreachable message with Code 2 ('beyond scope of source address') MUST be sent to the original source.
When a routing protocol determines it is operating on a zone boundary, it MUST protect inter-zone integrity and maintain intra-zone connectivity. A router transmitting routing information MUST NOT include information about zones other than the zones assigned to the interface used to transmit.
When an implementation supports a default zone for each scope, 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 encode the scope; the scope is determined by the accompanying address.
When an upper-layer protocol sends a packet to a non-global destination address and the node is attached to more than one zone of that scope, it must have a means of identifying the intended zone to the IPv6 layer. The upper-layer requires the ability to specify a zone index when sending to a non-global, non-loopback destination address.
A scope zone (or simply a zone) is a connected region of topology of a given scope. 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, allowing the same non-global address to be reused in different zones of that scope.
A zone index is a node-local identifier assigned to each zone of the same scope to which a node is attached, allowing internal uses of an address to be qualified by a zone index. Zone indices are strictly local to the node — the node on the other end of a link may use entirely different index values for the same zone.
Default zone index assignment algorithm: by default, an implementation should initially assign a unique interface index for each interface and a unique link index for each interface, producing a one-to-one mapping. Manual configuration is only required for the less common cases of multiple interfaces on the same link or interfaces in multicast-only zones of different scopes.
Every IPv6 address (other than the unspecified address) has a specific scope encoded as part of the address — a topological span within which it may be used as a unique identifier for an interface or set of interfaces. For unicast, two scopes are defined: link-local and global. For multicast, fourteen scopes are defined ranging from interface-local to global.
Zone instantiation rules: each interface forms its own interface-local zone (multicast only); each link and its attached interfaces form a single link-local zone; there is a single global zone; zones of other scopes must be defined and configured by network administrators. Each interface belongs to exactly one zone of each possible scope.
Zones have four structural properties: (1) zone boundaries cut through nodes, not links; (2) zones of the same scope cannot overlap; (3) a zone of a given scope falls completely within zones of larger scope; (4) each zone must be convex from a routing perspective so packets never leave the zone en route to another interface in the same zone.
A link-local address without a zone index cannot be used in certain security contexts. Specifically, a link-local address cannot be used in a traffic selector of an IPsec security association established by IKE when the IKE messages are carried over global addresses. A link-local address without a zone index also cannot be used in access control lists.
A malicious node might send a packet containing a textual IPv6 non-global address with a zone index in its payload, intending to deceive the receiving node about the zone of the non-global address. Implementations should be careful when receiving packets that contain textual non-global addresses as data, since the textual format is only valid within a single node.
Routers operating at zone boundaries must prevent zone-specific routing information from leaking outside each zone. If multicast site boundary routers allow site routing information to be forwarded outside the site, the integrity of the site could be compromised. The zone-specific forwarding table design ensures isolation.
Zone containment hierarchy: if two interfaces are assigned to different zones of scope S, they must also be assigned to different zones of all scopes smaller than S. Thus, manually assigning distinct indices for one scope may trigger automatic creation of distinct indices for all smaller scopes (e.g., assigning distinct multicast site-local indices automatically creates distinct admin-local indices).
The textual representation of a scoped IPv6 address is '<address>%<zone_id>' where <address> is a standard IPv6 address literal, '%' is a single-character delimiter, and <zone_id> is a string (typically a non-negative decimal integer or an interface name). When combined with a prefix length, the format is '<address>%<zone_id>/<prefix-length>'. The format is not defined for URLs due to conflict with URI percent-encoding.