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/rfc7371.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc7371.txt (limited to 'doc/rfc/rfc7371.txt') diff --git a/doc/rfc/rfc7371.txt b/doc/rfc/rfc7371.txt new file mode 100644 index 0000000..9eca6d2 --- /dev/null +++ b/doc/rfc/rfc7371.txt @@ -0,0 +1,563 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Boucadair +Request for Comments: 7371 France Telecom +Updates: 3306, 3956, 4291 S. Venaas +Category: Standards Track Cisco +ISSN: 2070-1721 September 2014 + + + Updates to the IPv6 Multicast Addressing Architecture + +Abstract + + This document updates the IPv6 multicast addressing architecture by + redefining the reserved bits as generic flag bits. The document also + provides some clarifications related to the use of these flag bits. + + This document updates RFCs 3956, 3306, 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/rfc7371. + + + + + + + + + + + + + + + + + + + + + +Boucadair & Venaas Standards Track [Page 1] + +RFC 7371 Multicast Flag Bits September 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. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Requirements Language ......................................3 + 2. Addressing Architecture Update ..................................3 + 3. Flag Bits: New Processing Rules .................................4 + 4. RFC Updates .....................................................4 + 4.1. Updates to RFC 3306 ........................................4 + 4.1.1. Update #1 ...........................................4 + 4.1.2. Update #2 ...........................................6 + 4.2. Updates to RFC 3956 ........................................6 + 4.2.1. Update #1 ...........................................6 + 4.2.2. Update #2 ...........................................7 + 4.2.3. Update #3 ...........................................8 + 4.2.4. Update #4 ...........................................9 + 5. Security Considerations .........................................9 + 6. Acknowledgements ................................................9 + 7. References ......................................................9 + 7.1. Normative References .......................................9 + 7.2. Informative References ....................................10 + + + + +Boucadair & Venaas Standards Track [Page 2] + +RFC 7371 Multicast Flag Bits September 2014 + + +1. Introduction + + This document updates the IPv6 addressing architecture [RFC4291] by + redefining reserved bits as generic flag bits (Section 2). The + document also provides some clarifications related to the use of + these flag bits (Section 3). + + This document updates [RFC3956], [RFC3306], and [RFC4291]. These + updates are logical consequences of the new processing rules in + Section 3. + + Textual representation of IPv6 addresses included in the RFC updates + follows the recommendation in [RFC5952]. + +1.1. Requirements Language + + 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 RFC 2119 [RFC2119]. + +2. Addressing Architecture Update + + Bits 17-20 of a multicast address, where bit 1 is the most + significant bit, are defined in [RFC3956] and [RFC3306] as reserved + bits. This document defines these bits as generic flag bits so that + they apply to any multicast address. These bits are referred to as + "ff2" (flag field 2), while the "flgs" bits in [RFC4291] [RFC3956] + are renamed to "ff1" (flag field 1). + + Within this document, flag bits denote both ff1 and ff2. + + Defining the bits 17-20 as flags for all IPv6 multicast addresses + allows addresses to be treated in a more uniform and generic way, and + allows for these bits to be defined in the future for different + purposes, irrespective of the specific type of multicast address. + For the record, this design choice was initially triggered by the + specification in [ADDR-FORMAT], which proposed associating a meaning + with one of the reserved bits. Moreover, [ADDR-FORMAT] also + considered the use of the last remaining flag in ff1, but that + approach was abandoned because it is not clear at this stage whether + there are other usage scenarios of the flag. + + Section 4 specifies the updated structure of the addressing + architecture. + + Further specification documents may define a meaning for these + flag bits. + + + + +Boucadair & Venaas Standards Track [Page 3] + +RFC 7371 Multicast Flag Bits September 2014 + + +3. Flag Bits: New Processing Rules + + Some implementations and specification documents do not treat the + flag bits as separate bits but tend to use their combined value as a + 4-bit integer. This practice is a hurdle for assigning a meaning to + the remaining flag bits. Below are listed some examples for + illustration purposes: + + o The reading of [RFC3306] may lead one to conclude that ff3x::/32 + is the only allowed Source-Specific Multicast (SSM) IPv6 prefix + block. + + o [RFC3956] states that only ff70::/12 applies to Embedded-RP. + Particularly, implementations should not treat the fff0::/12 range + as Embedded-RP. + + To avoid such confusion and to unambiguously associate a meaning with + the remaining flags, the following requirement is made: + + Implementations MUST treat flag bits as separate bits. + +4. RFC Updates + +4.1. Updates to RFC 3306 + +4.1.1. Update #1 + + This document changes Section 4 of [RFC3306] as follows: + + OLD: + + | 8 | 4 | 4 | 8 | 8 | 64 | 32 | + +--------+----+----+--------+--------+----------------+----------+ + |11111111|flgs|scop|reserved| plen | network prefix | group ID | + +--------+----+----+--------+--------+----------------+----------+ + + +-+-+-+-+ + flgs is a set of 4 flags: |0|0|P|T| + +-+-+-+-+ + + o P = 0 indicates a multicast address that is not assigned + based on the network prefix. This indicates a multicast + address as defined in [ADDRARCH]. + + o P = 1 indicates a multicast address that is assigned based + on the network prefix. + + + + + +Boucadair & Venaas Standards Track [Page 4] + +RFC 7371 Multicast Flag Bits September 2014 + + + o If P = 1, T MUST be set to 1, otherwise the setting of the T + bit is defined in Section 2.7 of [ADDRARCH]. + + The reserved field MUST be zero. + + Note: [ADDRARCH] is a reference listed in [RFC3306]. [ADDRARCH] + has been since obsoleted by [RFC4291]. + + NEW: + + | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | + +--------+----+----+----+----+--------+----------------+----------+ + |11111111|ff1 |scop|ff2 |rsvd| plen | network prefix | group ID | + +--------+----+----+----+----+--------+----------------+----------+ + + +-+-+-+-+ + ff1 (flag field 1) is a set of 4 flags: |X|Y|P|T| + +-+-+-+-+ + + X and Y may each be set to 0 or 1. Note that X is for future + assignment, while a meaning is associated with Y in RFC 3956. + + o P = 0 indicates a multicast address that is not assigned + based on the network prefix. This indicates a multicast + address as defined in [RFC4291]. + + o P = 1 indicates a multicast address that is assigned based + on the network prefix. + + o If P = 1, T MUST be set to 1; otherwise, the setting of the + T bit is defined in Section 2.7 of [RFC4291]. + + +-+-+-+-+ + ff2 (flag field 2) is a set of 4 flags: |r|r|r|r| + +-+-+-+-+ + + where "rrrr" are for future assignment as additional flag bits. + r bits MUST each be sent as zero and MUST be ignored on receipt. + + Flag bits denote both ff1 and ff2. + + + + + + + + + + + +Boucadair & Venaas Standards Track [Page 5] + +RFC 7371 Multicast Flag Bits September 2014 + + +4.1.2. Update #2 + + This document changes Section 6 of [RFC3306] as follows: + + OLD: + + These settings create an SSM range of FF3x::/32 (where 'x' is any + valid scope value). The source address field in the IPv6 header + identifies the owner of the multicast address. + + NEW: + + If the flag bits in ff1 are set to 0011, these settings create an + SSM range of ff3x::/32 (where 'x' is any valid scope value). The + source address field in the IPv6 header identifies the owner of + the multicast address. ff3x::/32 is not the only allowed SSM + prefix range. For example, if the most significant flag bit in + ff1 is set, then we would get the SSM range ffbx::/32. + +4.2. Updates to RFC 3956 + +4.2.1. Update #1 + + This document changes Section 2 of [RFC3956] as follows: + + OLD: + + As described in [RFC3306], the multicast address format is + as follows: + + | 8 | 4 | 4 | 8 | 8 | 64 | 32 | + +--------+----+----+--------+----+----------------+----------+ + |11111111|flgs|scop|reserved|plen| network prefix | group ID | + +--------+----+----+--------+----+----------------+----------+ + + Where flgs are "0011". (The first two bits are as yet undefined, + sent as zero and ignored on receipt.) + + + + + + + + + + + + + + +Boucadair & Venaas Standards Track [Page 6] + +RFC 7371 Multicast Flag Bits September 2014 + + + NEW: + + The multicast address format is as follows: + + | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | + +--------+----+----+----+----+----+----------------+----------+ + |11111111|ff1 |scop|ff2 |rsvd|plen| network prefix | group ID | + +--------+----+----+----+----+----+----------------+----------+ + + +-+-+-+-+ + ff1 (flag field 1) is a set of four flags: |X|R|P|T| + +-+-+-+-+ + + where X is for future assignment as an additional flag bit. + X may be set to 0 or 1. + + +-+-+-+-+ + ff2 (flag field 2) is a set of 4 flags: |r|r|r|r| + +-+-+-+-+ + + where "rrrr" are for future assignment as additional flag bits. + r bits MUST each be sent as zero and MUST be ignored + on receipt. + + Flag bits denote both ff1 and ff2. + +4.2.2. Update #2 + + This document changes Section 3 of [RFC3956] as follows: + + OLD: + + | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | + +--------+----+----+----+----+----+----------------+----------+ + |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | + +--------+----+----+----+----+----+----------------+----------+ + +-+-+-+-+ + flgs is a set of four flags: |0|R|P|T| + +-+-+-+-+ + + When the highest-order bit is 0, R = 1 indicates a multicast address + that embeds the address on the RP. Then P MUST be set to 1, and + consequently T MUST be set to 1, as specified in [RFC3306]. In + effect, this implies the prefix FF70::/12. In this case, the last 4 + bits of the previously reserved field are interpreted as embedding + the RP interface ID, as specified in this memo. + + + + + +Boucadair & Venaas Standards Track [Page 7] + +RFC 7371 Multicast Flag Bits September 2014 + + + The behavior is unspecified if P or T is not set to 1, as then the + prefix would not be FF70::/12. Likewise, the encoding and the + protocol mode used when the two high-order bits in "flgs" are set to + 11 ("FFF0::/12") is intentionally unspecified until such time that + the highest-order bit is defined. Without further IETF + specification, implementations SHOULD NOT treat the FFF0::/12 range + as Embedded-RP. + + NEW: + + | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | + +--------+----+----+----+----+----+----------------+----------+ + |11111111|ff1 |scop|ff2 |RIID|plen| network prefix | group ID | + +--------+----+----+----+----+----+----------------+----------+ + +-+-+-+-+ + ff1 is a set of four flags: |X|R|P|T| + +-+-+-+-+ + where X is for future assignment as an additional flag bit. + X may be set to 0 or 1. + + R = 1 indicates a multicast address that embeds the address of the + RP. Then, P MUST be set to 1, and consequently T MUST be set + to 1, according to [RFC3306], as this is a special case of + unicast-prefix-based addresses. This implies that, for instance, + prefixes ff70::/12 and fff0::/12 are embedded RP prefixes. When + the R-bit is set, the last 4 bits of the field that were reserved + in [RFC3306] are interpreted as embedding the RP interface ID, as + specified in this memo. + +4.2.3. Update #3 + + This document changes Section 4 of [RFC3956] as follows: + + OLD: + + o It MUST be a multicast address with "flgs" set to 0111, that is, to + be of the prefix FF70::/12, + + NEW: + + o It MUST be a multicast address with the R-bit set to 1. + + o It MUST have the P-bit and T-bit both set to 1 when using the + embedding in this document as it is a prefix-based address. + + + + + + + +Boucadair & Venaas Standards Track [Page 8] + +RFC 7371 Multicast Flag Bits September 2014 + + +4.2.4. Update #4 + + This document changes Section 7.1 of [RFC3956] as follows: + + OLD: + + To avoid loops and inconsistencies, for addresses in the range + FF70::/12, the Embedded-RP mapping MUST be considered the longest + possible match and higher priority than any other mechanism. + + NEW: + + To avoid loops and inconsistencies, for addresses with the R-bit + set to 1, the Embedded-RP mapping MUST be considered the longest + possible match and higher priority than any other mechanism. + +5. Security Considerations + + The same security considerations as those discussed in [RFC3956], + [RFC3306], and [RFC4291] are to be taken into account. + +6. Acknowledgements + + Special thanks to Brian Haberman for the discussions prior to the + publication of this document. + + Many thanks to Jouni Korhonen, Tatuya Jinmei, Charlie Kaufman, and + Ben Campbell for their review. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 + Multicast Addresses", RFC 3306, August 2002. + + [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous + Point (RP) Address in an IPv6 Multicast Address", + RFC 3956, November 2004. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, August 2010. + + + +Boucadair & Venaas Standards Track [Page 9] + +RFC 7371 Multicast Flag Bits September 2014 + + +7.2. Informative References + + [ADDR-FORMAT] + Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and + M. Xu, "IPv6 Multicast Address With Embedded IPv4 + Multicast Address", Work in Progress, April 2013. + +Authors' Addresses + + Mohamed Boucadair + France Telecom + Rennes 35000 + France + + EMail: mohamed.boucadair@orange.com + + + Stig Venaas + Cisco + USA + + EMail: stig@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Boucadair & Venaas Standards Track [Page 10] + -- cgit v1.2.3