doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

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