IPv6 Multicast Address Scopes
Extracted elements (13)
Global scope (scop E) has no boundary, and reserved scopes (0 and F) will have their boundary configuration defined when their semantics are defined. This asymmetric treatment reflects that only scopes with defined forwarding behavior require boundary configuration rules.
Scop 3 was defined as 'reserved' in RFC 4291, but the Multicast Protocol for Low-power and Lossy Networks (MPL) requires a multicast scope greater than Link-Local yet automatically determined by network architecture rather than administratively configured. RFC 7346 repurposes scop 3 as 'Realm-Local' to accommodate this need.
Realm-Local scopes created by different network technologies are considered independent and will have different zone indices (per RFC 4007 Section 6). A router with interfaces on links using different network technologies does not forward traffic between the Realm-Local multicast scopes defined by those technologies.
RFC 7346 resolves a disagreement between RFC 4007 Section 5 and RFC 4291 Section 2.7 regarding how multicast scop 3 is configured. RFC 4007's bullet requiring administrative configuration of non-interface-local, non-link-local, non-global scopes is updated to defer to the IPv6 addressing architecture as updated by RFC 7346.
According to RFC 4007, the zone of a Realm-Local scope must fall within zones of larger scope. Because Realm-Local zones are configured automatically while larger-scope zones are configured manually, care must be taken in defining larger scopes to ensure the inclusion constraint is met.
Any RFC that includes the definition of a Realm-Local scope must include an explicit IANA Considerations request to be added to the 'IPv6 Multicast Address Scopes' registry under the Realm-Local scope entry.
Interface-Local, Link-Local, and Realm-Local scope boundaries are automatically derived from physical connectivity or other non-multicast-related configurations. The boundaries of all other non-reserved scopes of Admin-Local or larger are administratively configured.
The definition of any Realm-Local scope for a particular network technology must be published in an RFC. Such a definition would be appropriate for an 'IPv6-over-foo' RFC.
IPv6 multicast addresses include a 4-bit 'scop' field that limits the scope of the multicast group. RFC 7346 updates the scope value table: 0=Reserved, 1=Interface-Local, 2=Link-Local, 3=Realm-Local, 4=Admin-Local, 5=Site-Local, 6-7=Unassigned, 8=Organization-Local, 9-D=Unassigned, E=Global, F=Reserved.
Realm-Local scope (scop 3) for IP-over-IEEE 802.15.4 networks is defined to include all interfaces sharing a Personal Area Network Identifier (PAN ID).
For each future RFC defining a Realm-Local scope for a new network technology, IANA adds a reference to the defining document in the 'IPv6 Multicast Address Scopes' registry under the Realm-Local (scop 3) entry. Such RFCs must explicitly request inclusion.
IANA established the 'IPv6 Multicast Address Scopes' sub-registry within the existing 'IPv6 Multicast Address Space Registry', populated with the 16 scop values (0-F) defined in Section 2. New scop value definitions follow the 'IETF Review' policy (RFC 5226).
RFC 7346 introduces no security considerations beyond those already present in RFC 4007 and RFC 4291.