From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7346.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc7346.txt (limited to 'doc/rfc/rfc7346.txt') diff --git a/doc/rfc/rfc7346.txt b/doc/rfc/rfc7346.txt new file mode 100644 index 0000000..0075f93 --- /dev/null +++ b/doc/rfc/rfc7346.txt @@ -0,0 +1,339 @@ + + + + + + +Internet Engineering Task Force (IETF) R. Droms +Request for Comments: 7346 Cisco +Updates: 4007, 4291 August 2014 +Category: Standards Track +ISSN: 2070-1721 + + + IPv6 Multicast Address Scopes + +Abstract + + This document updates the definitions of IPv6 multicast scopes and + therefore updates RFCs 4007 and 4291. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7346. + + + + + + + + + + + + + + + + + + + + + + + + +Droms Standards Track [Page 1] + +RFC 7346 IPv6 Multicast Address Scopes August 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +1. Introduction + + RFC 4291 [RFC4291] defines "scop" as "a 4-bit multicast scope value + used to limit the scope of the multicast group" and defines "scop 3" + as "reserved". The multicast protocol specification in [MPL] desires + to use multicast scop 3 to transport multicast traffic scoped to a + network of nodes connected in a mesh. This scop value is used to + accommodate a multicast scope that is greater than Link-Local but is + also automatically determined by the network architecture. + + + + + + + + + + + + + + + +Droms Standards Track [Page 2] + +RFC 7346 IPv6 Multicast Address Scopes August 2014 + + +2. Definition of IPv6 Multicast Address Scopes (Updates RFC 4291) + + The following table updates the definitions in [RFC4291]: + + +------+--------------------------+-------------------------+ + | scop | NAME | REFERENCE | + +------+--------------------------+-------------------------+ + | 0 | Reserved | [RFC4291], RFC 7346 | + | 1 | Interface-Local scope | [RFC4291], RFC 7346 | + | 2 | Link-Local scope | [RFC4291], RFC 7346 | + | 3 | Realm-Local scope | [RFC4291], RFC 7346 | + | 4 | Admin-Local scope | [RFC4291], RFC 7346 | + | 5 | Site-Local scope | [RFC4291], RFC 7346 | + | 6 | Unassigned | | + | 7 | Unassigned | | + | 8 | Organization-Local scope | [RFC4291], RFC 7346 | + | 9 | Unassigned | | + | A | Unassigned | | + | B | Unassigned | | + | C | Unassigned | | + | D | Unassigned | | + | E | Global scope | [RFC4291], RFC 7346 | + | F | Reserved | [RFC4291], RFC 7346 | + +------+--------------------------+-------------------------+ + + The following change is applied to Section 2.7 of [RFC4291]. + + OLD: + + Admin-Local scope is the smallest scope that must be + administratively configured, i.e., not automatically derived from + physical connectivity or other, non-multicast-related + configuration. + + NEW: + + Interface-Local, Link-Local, and Realm-Local scope boundaries are + automatically derived from physical connectivity or other non- + multicast-related configurations. Global scope has no boundary. + The boundaries of all other non-reserved scopes of Admin-Local or + larger are administratively configured. For reserved scopes, the + way of configuring their boundaries will be defined when the + semantics of the scope are defined. + + According to RFC 4007 [RFC4007], the zone of a Realm-Local scope + must fall within zones of larger scope. Because the zone of a + Realm-Local scope is configured automatically while the zones of + larger scopes are configured manually, care must be taken in the + + + +Droms Standards Track [Page 3] + +RFC 7346 IPv6 Multicast Address Scopes August 2014 + + + definition of those larger scopes to ensure that the inclusion + constraint is met. + + Realm-Local scopes created by different network technologies are + considered to be independent and will have different zone indices + (see Section 6 of [RFC4007]). A router with interfaces on links + using different network technologies does not forward traffic + between the Realm-Local multicast scopes defined by those + technologies. + +3. Definition of Realm-Local Scopes + + The definition of any Realm-Local scope for a particular network + technology should be published in an RFC. For example, such a scope + definition would be appropriate for publication in an "IPv6-over-foo" + RFC. + + Any RFCs that include the definition of a Realm-Local scope will be + added to the IANA "IPv6 Multicast Address Scopes" registry under the + Realm-Local scope entry, and those specifications must include such a + request in their IANA Considerations. + + Section 5 of this document gives the definition of scop 3 for IEEE + 802.15.4 [IEEE802.15.4] networks. + +4. Definition of Automatic and Administratively Configured Scopes + (Updates RFC 4007) + + Section 5 of RFC 4007 [RFC4007] and Section 2.7 of RFC 4291 [RFC4291] + disagree on the way in which multicast scop 3 is configured. To + resolve that disagreement, the last bullet in the list in Section 5 + of [RFC4007] is updated as follows: + + OLD: + + o The boundaries of zones of a scope other than interface-local, + link-local, and global must be defined and configured by network + administrators. + + NEW: + + o The boundaries of zones of a scope are defined by the IPv6 + addressing architecture [RFC4291] and updated by RFC 7346. + + + + + + + + +Droms Standards Track [Page 4] + +RFC 7346 IPv6 Multicast Address Scopes August 2014 + + +5. Definition of Realm-Local Scope for IEEE 802.15.4 + + When used in an IP-over-IEEE802.15.4 network, scop 3 is defined to + include all interfaces sharing a Personal Area Network Identifier + (PAN ID). + +6. IANA Considerations + + IANA has established a sub-registry titled "IPv6 Multicast Address + Scopes" in the existing "IPv6 Multicast Address Space Registry". The + new registry has been populated with the scop values given in + Section 2. New definitions for scop values will be made following + the "IETF Review" policy [RFC5226]. + + For each future RFC that defines a Realm-Local scope for new network + technologies (scop 3), IANA will add a reference to the defining + document in the "IPv6 Multicast Address Scopes" registry. Such RFCs + are expected to make an explicit request to IANA for inclusion in the + registry. + + IANA has included a note on the top of the "IPv6 Multicast Address + Scopes" registry: + + The definition of any Realm-Local scope for a particular network + technology should be published in an RFC. For example, such a + scope definition would be appropriate for publication in an 'IPv6- + over-foo' RFC. + + Any RFCs that define a Realm-Local scope will be listed in this + registry as an additional reference in the Realm-Local scope + entry. Such RFCs are expected to make an explicit request to IANA + for inclusion in this registry. + +7. Acknowledgments + + Robert Cragie, Kerry Lynn, Jinmei Tatuya, Dave Thaler, and Stig + Venaas all contributed text and/or review to ensure that the updates + to RFC 4007 and RFC 4291 are correct. + +8. Security Considerations + + This document has no security considerations beyond those in RFC 4007 + [RFC4007] and RFC 4291 [RFC4291]. + + + + + + + + +Droms Standards Track [Page 5] + +RFC 7346 IPv6 Multicast Address Scopes August 2014 + + +9. References + +9.1. Normative References + + [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and + B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, + March 2005. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + +9.2. Informative References + + [IEEE802.15.4] + IEEE Computer Society, "IEEE Std. 802.15.4-2006", October + 2006. + + [MPL] Hui, J. and R. Kelsey, "Multicast Protocol for Low power + and Lossy Networks (MPL)", Work in Progress, April 2014. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + +Author's Address + + Ralph Droms + Cisco + 1414 Massachusetts Avenue + Boxborough, MA 01719 + USA + + Phone: +1 978 936 1674 + EMail: rdroms.ietf@gmail.com + + + + + + + + + + + + + + + + + +Droms Standards Track [Page 6] + -- cgit v1.2.3