idnits 2.17.00 (12 Aug 2021) /tmp/idnits60421/draft-ietf-6man-multicast-addr-arch-update-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 21 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3306, updated by this document, for RFC5378 checks: 2000-09-27) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2013) is 3136 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ADDRARCH' is mentioned on line 199, but not defined Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group M. Boucadair 3 Internet-Draft France Telecom 4 Updates: 3306,3956,4291 (if approved) S. Venaas 5 Intended status: Standards Track Cisco 6 Expires: April 21, 2014 October 18, 2013 8 Updates to the IPv6 Multicast Addressing Architecture 9 draft-ietf-6man-multicast-addr-arch-update-02 11 Abstract 13 This document updates the IPv6 multicast addressing architecture by 14 defining the 17-20 reserved bits as generic flag bits. The document 15 provides also some clarifications related to the use of these flag 16 bits. 18 This document updates RFC 3956, RFC 3306 and RFC 4291. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 21, 2014. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Addressing Architecture Update . . . . . . . . . . . . . . . 2 62 3. Clarifications . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Flag Bits . . . . . . . . . . . . . . . . . . . . . . . . 3 64 4. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.1. RFC 3306 . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.2. RFC 3956 . . . . . . . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Normative References . . . . . . . . . . . . . . . . . . . . 8 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 This document updates the IPv6 multicast addressing architecture 76 [RFC4291] by defining the 17-20 reserved bits as generic flag bits 77 (Section 2). The document provides also some clarifications related 78 to the use of these flag bits (Section 3.1). 80 This document updates [RFC3956], [RFC3306], and [RFC4291]. 82 2. Addressing Architecture Update 84 Bits 17-20 of a multicast address are defined in [RFC3956] and 85 [RFC3306] as reserved bits. This document defines these bits as 86 generic flag bits so that they apply to any multicast address. 87 Figure 1 and Figure 2 show the updated structure of the addressing 88 architecture. The first diagram shows the update of the base IPv6 89 addressing architecture, and the second shows the update of so-called 90 Embedded-RP. 92 OLD: 93 | 8 | 4 | 4 | 112 bits | 94 +--------+----+----+----------------------------------------------+ 95 |11111111|flgs|scop| group ID | 96 +--------+----+----+----------------------------------------------+ 98 NEW: 99 | 8 | 4 | 4 | 4 | 108 bits | 100 +--------+----+----+----------------------------------------------+ 101 |11111111|flgs|scop|flgs| group ID | 102 +--------+----+----+----+-----------------------------------------+ 104 Figure 1: Updated IPv6 Multicast Addressing Architecture 106 OLD (RFC 3956): 107 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 108 +--------+----+----+----+----+--------+----------------+----------+ 109 |11111111|flgs|scop|rsvd|RIID| plen | network prefix | group ID | 110 +--------+----+----+----+----+--------+----------------+----------+ 112 NEW: 113 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 114 +--------+----+----+----+----+--------+----------------+----------+ 115 |11111111|flgs|scop|flgs|RIID| plen | network prefix | group ID | 116 +--------+----+----+----+----+--------+----------------+----------+ 118 Figure 2: Embedded-RP with Updated IPv6 Multicast Address Arch. 120 Further specification documents may define a meaning for these flag 121 bits. Defining the bits 17-20 as flags for all IPv6 multicast 122 addresses allows addresses to be treated in a more uniform and 123 generic way, and allows for these bits to be defined in the future 124 for different purposes, irrespective of the specific type of 125 multicast address. 127 3. Clarifications 129 3.1. Flag Bits 131 Some implementations and specification documents do not treat the 132 flag bits as separate bits but tend to use their combined value as a 133 4-bit integer. This practice is a hurdle for assigning a meaning to 134 the remaining flag bits. Below are listed some examples for 135 illustration purposes: 137 o the reading of [RFC3306] may lead to conclude that ff3x::/32 is 138 the only allowed SSM IPv6 prefix block. 140 o [RFC3956] states only ff70::/12 applies to Embedded-RP. 141 Particularly, implementations should not treat the fff0::/12 range 142 as Embedded-RP. 144 To avoid such confusion and to unambiguously associate a meaning with 145 the remaining flags, the following requirement is made 147 Implementations MUST treat flag bits as separate bits. 149 4. RFC Updates 151 4.1. RFC 3306 153 This document changes Section 4 of [RFC3306] as follows: 155 OLD: 157 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 158 +--------+----+----+--------+--------+----------------+----------+ 159 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 160 +--------+----+----+--------+--------+----------------+----------+ 162 +-+-+-+-+ 163 flgs is a set of 4 flags: |0|0|P|T| 164 +-+-+-+-+ 166 o P = 0 indicates a multicast address that is not assigned 167 based on the network prefix. This indicates a multicast 168 address as defined in [ADDRARCH]. 170 o P = 1 indicates a multicast address that is assigned based 171 on the network prefix. 173 o If P = 1, T MUST be set to 1, otherwise the setting of the T 174 bit is defined in Section 2.7 of [ADDRARCH]. 176 The reserved field MUST be zero. 178 NEW: 180 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 181 +--------+----+----+--------+--------+----------------+----------+ 182 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 183 +--------+----+----+--------+--------+----------------+----------+ 185 +-+-+-+-+ 186 flgs is a set of 4 flags: |X|Y|P|T| 187 +-+-+-+-+ 189 X and Y may each be set to 0 or 1. 191 o P = 0 indicates a multicast address that is not assigned 192 based on the network prefix. This indicates a multicast 193 address as defined in [ADDRARCH]. 195 o P = 1 indicates a multicast address that is assigned based 196 on the network prefix. 198 o If P = 1, T MUST be set to 1, otherwise the setting of the T 199 bit is defined in Section 2.7 of [ADDRARCH]. 201 This document changes Section 6 of [RFC3306] as follows: 203 OLD: 205 These settings create an SSM range of FF3x::/32 (where 'x' is any 206 valid scope value). The source address field in the IPv6 header 207 identifies the owner of the multicast address. 209 NEW: 211 If the flag bits are set to 0011, these settings create an SSM 212 range of ff3x::/32 (where 'x' is any valid scope value). The 213 source address field in the IPv6 header identifies the owner of 214 the multicast address. ff3x::/32 is not the only allowed SSM 215 prefix range. For example if the most significant flag bit is 216 set, then we would get the SSM range ffbx::/32. 218 4.2. RFC 3956 220 This document changes Section 2 of [RFC3956] as follows: 222 OLD: 224 As described in [RFC3306], the multicast address format is as 225 follows: 227 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 228 +--------+----+----+--------+----+----------------+----------+ 229 |11111111|flgs|scop|reserved|plen| network prefix | group ID | 230 +--------+----+----+--------+----+----------------+----------+ 232 Where flgs are "0011". (The first two bits are as yet undefined, 233 sent as zero and ignored on receipt.) 235 NEW: 237 The multicast address format is as 238 follows: 240 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 241 +--------+----+----+---------+----+----------------+----------+ 242 |11111111|flgs|scop|flgs|rsvd|plen| network prefix | group ID | 243 +--------+----+----+---------+----+----------------+----------+ 245 +-+-+-+-+ 246 flgs is a set of four flags: |X|R|P|T| 247 +-+-+-+-+ 249 X may be set to 0 or 1. 251 This document changes Section 3 of [RFC3956] as follows: 253 OLD: 255 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 256 +--------+----+----+----+----+----+----------------+----------+ 257 |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | 258 +--------+----+----+----+----+----+----------------+----------+ 259 +-+-+-+-+ 260 flgs is a set of four flags: |0|R|P|T| 261 +-+-+-+-+ 263 When the highest-order bit is 0, R = 1 indicates a multicast address 264 that embeds the address on the RP. Then P MUST be set to 1, and 265 consequently T MUST be set to 1, as specified in [RFC3306]. In 266 effect, this implies the prefix FF70::/12. In this case, the last 4 267 bits of the previously reserved field are interpreted as embedding 268 the RP interface ID, as specified in this memo. 270 The behavior is unspecified if P or T is not set to 1, as then the 271 prefix would not be FF70::/12. Likewise, the encoding and the 272 protocol mode used when the two high-order bits in "flgs" are set to 273 11 ("FFF0::/12") is intentionally unspecified until such time that 274 the highest-order bit is defined. Without further IETF 275 specification, implementations SHOULD NOT treat the FFF0::/12 range 276 as Embedded-RP. 278 NEW: 280 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 281 +--------+----+----+----+----+----+----------------+----------+ 282 |11111111|flgs|scop|flgs|RIID|plen| network prefix | group ID | 283 +--------+----+----+----+----+----+----------------+----------+ 284 +-+-+-+-+ 285 flgs is a set of four flags: |X|R|P|T| 286 +-+-+-+-+ 287 X may be set to 0 or 1. 289 R = 1 indicates a multicast address that embeds the address of the RP. 290 P MUST be set to 1, and consequently T MUST be set to 1, according 291 to [RFC3306], as this is a special case of 292 unicast-prefix based addresses. This implies that for instance prefixes 293 ff70::/12 and fff0::/12 are embedded RP prefixes, but all multicast 294 addresses with the R-bit set to 1 MUST be treated as Embedded RP 295 addresses. The behavior is unspecified if P or T is not set to 1. When the 296 R-bit is set, the last 4 bits of the previously reserved field are 297 interpreted as embedding the RP interface ID, as specified in this memo. 299 This document changes Section 4 of [RFC3956] as follows: 301 OLD: 303 It MUST be a multicast address with "flgs" set to 0111, that is, 304 to be of the prefix FF70::/12, 306 NEW: 308 It MUST be a multicast address with R-bit set to 1. 310 It MUST have P-bit and T-bit both set to 1 when using the 311 embedding in this document as it is a prefix-based address. 313 This document changes Section 7.1 of [RFC3956] as follows: 315 OLD: 317 To avoid loops and inconsistencies, for addresses in the range 318 FF70::/12, the Embedded-RP mapping MUST be considered the longest 319 possible match and higher priority than any other mechanism. 321 NEW: 323 To avoid loops and inconsistencies, for addresses with R-bit set 324 to 1, the Embedded-RP mapping MUST be considered the longest 325 possible match and higher priority than any other mechanism. 327 5. IANA Considerations 328 This document may require IANA updates. However, at this point it is 329 not clear exactly what these updates may be. 331 6. Security Considerations 333 Security considerations discussed in [RFC3956], [RFC3306] and 334 [RFC4291] MUST be taken into account. 336 7. Acknowledgements 338 Many thanks to B. Haberman for the discussions prior to the 339 publication of this document. 341 8. Normative References 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 347 Multicast Addresses", RFC 3306, August 2002. 349 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 350 Point (RP) Address in an IPv6 Multicast Address", RFC 351 3956, November 2004. 353 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 354 Architecture", RFC 4291, February 2006. 356 Authors' Addresses 358 Mohamed Boucadair 359 France Telecom 360 Rennes 35000 361 France 363 Email: mohamed.boucadair@orange.com 365 Stig Venaas 366 Cisco 367 USA 369 Email: stig@cisco.com