RFC 7371 PROPOSED STANDARD IPV6 · MULTICAST · ADDRESSING
Updates to the IPv6 Multicast Addressing Architecture
Turns the reserved bits of IPv6 multicast addresses into general flag bits and fixes the older RFCs that assumed otherwise.
RFC EDITOR
Boucadair, M. and S. Venaas, "Updates to the IPv6 Multicast Addressing Architecture", RFC 7371, DOI 10.17487/RFC7371, September 2014, <https://www.rfc-editor.org/info/rfc7371>.
BIBTEX
@misc{rfc7371,
series = {Request for Comments},
number = 7371,
howpublished = {RFC 7371},
publisher = {RFC Editor},
doi = {10.17487/RFC7371},
url = {https://www.rfc-editor.org/info/rfc7371},
author = {M. Boucadair and S. Venaas},
title = {{Updates to the IPv6 Multicast Addressing Architecture}},
pagetotal = 10,
year = 2014,
month = sep,
} RFC text
Contents
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.
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
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.
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.
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.
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.)
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.
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.
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.
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
AI ELI5
On this page
PROBLEMBits 17-20 of an IPv6 multicast address were reserved in RFC 3306 and RFC 3956, and some implementations treat the flag bits as one 4-bit number, which makes it hard to give the remaining flags a meaning.
MECHANISMThe reserved bits become a second flag field, ff2, the original flags become ff1, and implementations MUST treat flag bits as separate bits. Affected text in RFC 3306 and RFC 3956 is rewritten.
WHY IT MATTERSFlag bits now apply to any multicast address and can be defined in the future, and examples such as the ffbx::/32 SSM range and the fff0::/12 Embedded-RP prefix become valid.
§1Introduction
This document updates the IPv6 addressing architecture of RFC 4291 by redefining reserved bits as generic flag bits. It also clarifies how those flags are used. It updates RFC 3956, RFC 3306 and RFC 4291, and these updates are logical consequences of the new processing rules.
IPv6 addresses in the RFC text follow the recommendation of RFC 5952.
This RFC changes the rulebook for special group-mailing addresses so that some unused switches can be used later.
§2The Address Layout Update
Bits 17-20 of a multicast address, counting bit 1 as the most significant, are reserved in RFC 3956 and RFC 3306. This document defines them as generic flag bits for any multicast address and calls them ff2 (flag field 2). The flgs bits in RFC 4291 are renamed ff1 (flag field 1).
This lets addresses be treated uniformly and lets the bits be defined later for different purposes, whatever the type of multicast address. The design was initially triggered by a Work in Progress that proposed giving one reserved bit a meaning. That draft also considered the last remaining flag in ff1, but this was abandoned because it is unclear whether there are other usage scenarios.
The address has two rows of four switches. The first row keeps its job, and the second row is now open for future use.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
PREFIX | 11111111 | 1 byte | Fixed multicast prefix. | |
FF1 | ff1 | 4 bits | Flag field 1, flags XYPT. | |
SCOP | scop | 4 bits | Scope. | |
FF2 | ff2 | 4 bits | Flag field 2, flags rrrr; sent as zero. | |
RSVD | rsvd | 4 bits | Reserved. | |
PLEN | plen | 1 byte | Prefix length. | |
NETWORK-PREFIX | Network prefix | 8 bytes | Network prefix. | |
GROUP-ID | Group ID | 4 bytes | Group identifier. |
§3Flag Bits Are Separate Bits
Some implementations and specifications use the flag bits together as a 4-bit integer, which is a hurdle to giving the remaining bits a meaning. For example, reading RFC 3306 may suggest that ff3x::/32 is the only allowed Source-Specific Multicast (SSM) prefix block. RFC 3956 says only ff70::/12 applies to Embedded-RP.
The new requirement is short: implementations MUST treat flag bits as separate bits.
Look at each switch by itself instead of reading the whole row as one number.
§4Changes to RFC 3306
The address format in section 4 of RFC 3306 becomes: 8 bits of 11111111, ff1 (4 bits), scop (4 bits), ff2 (4 bits), rsvd (4 bits), plen (8 bits), a 64-bit network prefix and a 32-bit group ID.
The ff1 flags are XYPT. X and Y may each be 0 or 1; X is for future assignment and Y has a meaning in RFC 3956. The P and T rules stay: P = 1 means the address is assigned based on the network prefix, and then T MUST be 1. The four ff2 bits are rrrr; they MUST each be sent as zero and MUST be ignored on receipt.
Section 6 changes too. When ff1 is 0011, the SSM range is ff3x::/32, but it is not the only one: if the most significant ff1 bit is set, the range is ffbx::/32.
The old description is rewritten so that the first row has four named switches and the second row is spare and must be left off for now.
§5Changes to RFC 3956 (Embedded-RP)
RFC 3956 embeds the address of a Rendezvous Point (RP) in a multicast address. Its format is updated to use ff1 and ff2, and its ff1 flags are XRPT, where X may be 0 or 1. Before, only ff70::/12 counted as Embedded-RP and fff0::/12 was left unspecified.
Now R = 1 indicates an embedded RP address. P MUST be 1 and so T MUST be 1. This implies that, for instance, ff70::/12 and fff0::/12 are both embedded RP prefixes. When the R bit is set, the last 4 bits of the field reserved in RFC 3306 carry the RP interface ID.
The validity rule in section 4 now says the address MUST have the R-bit set and, for this embedding, P and T both set to 1. The longest-match rule in section 7.1 applies to addresses with the R-bit set to 1, not just FF70::/12.
One of the switches means 'the meeting point is hidden inside this address'. The rule now follows that switch, not a fixed pattern.
| Aspect | RFC 3956 | RFC 7371 |
|---|---|---|
| Embedded-RP prefix THIS RFC | ff70::/12 only | Any address with R-bit set, e.g. ff70::/12 and fff0::/12 |
| Highest flag bit | Undefined, treated as 0 | X, may be 0 or 1 |
§6Security Considerations
This document adds no new security text. The same security considerations as in RFC 3956, RFC 3306 and RFC 4291 are to be taken into account.
It is a Standards Track document, and it assigns no meaning to the new ff2 bits; they must be sent as zero and ignored on receipt.
Nothing new to worry about. The safety rules from the older documents still apply.
§7References
[RFC2119]RFC 2119Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.March 1997[RFC3306]RFC 3306Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.September 2002[RFC3956]RFC 3956Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.November 2004[RFC4291]RFC 4291Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.February 2006[RFC5952]RFC 5952Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010.August 2010