idnits 2.17.1 draft-ietf-6man-multicast-addr-arch-update-01.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 6 characters in excess of 72. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 (May 23, 2013) is 3990 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 214, but not defined == Missing Reference: 'IPv6-UBM' is mentioned on line 380, but not defined == Missing Reference: 'IPv6-MALLOC' is mentioned on line 381, but not defined == Missing Reference: 'I-D.ietf-6man-multicast-addr-arch-update' is mentioned on line 395, but not defined Summary: 1 error (**), 0 flaws (~~), 6 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,4607,4291 (if approved) S. Venaas 5 Intended status: Standards Track Cisco 6 Expires: November 24, 2013 May 23, 2013 8 Updates to the IPv6 Multicast Addressing Architecture 9 draft-ietf-6man-multicast-addr-arch-update-01 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, RFC 4607 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 November 24, 2013. 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 3.2. IANA Assigned SSM Block . . . . . . . . . . . . . . . . . 4 65 4. RFC Updates . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4.1. RFC3306 . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 4.2. RFC3956 . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 4.3. RFC4607 . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 72 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 75 1. Introduction 77 This document updates the IPv6 multicast addressing architecture 78 [RFC4291] by defining the 17-20 reserved bits as generic flag bits 79 (Section 2). The document provides also some clarifications related 80 to the use of these flag bits (Section 3.1) and also about IANA 81 assigned SSM blocks (Section 3.2). 83 This document updates [RFC3956], [RFC3306], [RFC4607] and [RFC4291]. 85 2. Addressing Architecture Update 87 Bits 17-20 of a multicast address are defined in [RFC3956] and 88 [RFC3306] as reserved bits. This document defines these bits as 89 generic flag bits so that they apply to any multicast address. 90 Figure 1 and Figure 2 show the updated structure of the addressing 91 architecture. The first diagram shows the update of the base IPv6 92 addressing architecture, and the second shows the update of so-called 93 Embedded-RP. 95 OLD: 96 | 8 | 4 | 4 | 112 bits | 97 +--------+----+----+----------------------------------------------+ 98 |11111111|flgs|scop| group ID | 99 +--------+----+----+----------------------------------------------+ 101 NEW: 102 | 8 | 4 | 4 | 4 | 108 bits | 103 +--------+----+----+----------------------------------------------+ 104 |11111111|flgs|scop|flgs| group ID | 105 +--------+----+----+----+-----------------------------------------+ 107 Figure 1: Updated IPv6 Multicast Addressing Architecture 109 OLD (RFC3956): 110 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 111 +--------+----+----+----+----+--------+----------------+----------+ 112 |11111111|flgs|scop|rsvd|RIID| plen | network prefix | group ID | 113 +--------+----+----+----+----+--------+----------------+----------+ 115 NEW: 116 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 117 +--------+----+----+----+----+--------+----------------+----------+ 118 |11111111|flgs|scop|flgs|RIID| plen | network prefix | group ID | 119 +--------+----+----+----+----+--------+----------------+----------+ 121 Figure 2: Embedded-RP with Updated IPv6 Multicast Address Arch. 123 Further specification documents may define a meaning for these flag 124 bits. Defining the bits 17-20 as flags for all IPv6 multicast 125 addresses allows addresses to be treated in a more uniform and 126 generic way, and allows for these bits to be defined in the future 127 for different purposes, irrespective of the specific type of 128 multicast address. 130 3. Clarifications 132 3.1. Flag Bits 134 Some implementations and specification documents do not treat the 135 flag bits as separate bits but tend to use their combined value as a 136 4-bit integer. This practice is a hurdle for assigning a meaning to 137 the remaining flag bits. Below are listed some examples for 138 illustration purposes: 140 o the reading of [RFC4607] may lead to conclude that ff3x::/32 is 141 the only allowed SSM IPv6 prefix block. 143 o [RFC3956] states only ff70::/12 applies to Embedded-RP. 144 Particularly, implementations should not treat the fff0::/12 range 145 as Embedded-RP. 147 To avoid such confusion and to unambiguously associate a meaning with 148 the remaining flags, the following recommendation is made 150 Implementations MUST treat flag bits as separate bits. 152 3.2. IANA Assigned SSM Block 154 Another issue related to SSM is the IANA assigned SSM address block. 155 Per [RFC4607], ff3x::4000:0001 through ff3x::7fff:fff is the block 156 for IANA assignments (http://www.iana.org/assignments/ipv6-multicast- 157 addresses/ipv6-multicast-addresses.xml). However, IANA assignments 158 are permanent addresses and should not have the transient bit set. 159 Quoting from [RFC4607]: 161 "T = 1 indicates a non-permanently-assigned ("transient") 162 multicast address.". 164 4. RFC Updates 166 4.1. RFC3306 168 This document changes Section 4 of [RFC3306] as follows: 170 OLD: 172 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 173 +--------+----+----+--------+--------+----------------+----------+ 174 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 175 +--------+----+----+--------+--------+----------------+----------+ 177 +-+-+-+-+ 178 flgs is a set of 4 flags: |0|0|P|T| 179 +-+-+-+-+ 181 o P = 0 indicates a multicast address that is not assigned 182 based on the network prefix. This indicates a multicast 183 address as defined in [ADDRARCH]. 185 o P = 1 indicates a multicast address that is assigned based 186 on the network prefix. 188 o If P = 1, T MUST be set to 1, otherwise the setting of the T 189 bit is defined in Section 2.7 of [ADDRARCH]. 191 The reserved field MUST be zero. 193 NEW: 195 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 196 +--------+----+----+--------+--------+----------------+----------+ 197 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 198 +--------+----+----+--------+--------+----------------+----------+ 200 +-+-+-+-+ 201 flgs is a set of 4 flags: |X|Y|P|T| 202 +-+-+-+-+ 204 X and Y may each be set to 0 or 1. 206 o P = 0 indicates a multicast address that is not assigned 207 based on the network prefix. This indicates a multicast 208 address as defined in [ADDRARCH]. 210 o P = 1 indicates a multicast address that is assigned based 211 on the network prefix. 213 o T is set according to the definition in Section 2.7 214 of [ADDRARCH]. Unicast-Prefix-based addresses would 215 typically not be IANA assigned, so in most cases T would 216 be set to 1. 218 This document changes Section 6 of [RFC3306] as follows: 220 OLD: 222 These settings create an SSM range of FF3x::/32 (where 'x' is any 223 valid scope value). The source address field in the IPv6 header 224 identifies the owner of the multicast address. 226 NEW: 228 T flag is set according to whether the addresses are assigned by 229 IANA. 231 If the flag bits are to 0011, these settings create an SSM range 232 of ff3x::/32 (where 'x' is any valid scope value). The source 233 address field in the IPv6 header identifies the owner of the 234 multicast address. ff3x::/32 is not the only allowed SSM prefix 235 range. For example, ff2x::/32 would be IANA assigned SSM 236 addresses. 238 4.2. RFC3956 240 This document changes Section 2 of [RFC3956] as follows: 242 OLD: 244 As described in [RFC3306], the multicast address format is as 245 follows: 247 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 248 +--------+----+----+--------+----+----------------+----------+ 249 |11111111|flgs|scop|reserved|plen| network prefix | group ID | 250 +--------+----+----+--------+----+----------------+----------+ 252 Where flgs are "0011". (The first two bits are as yet undefined, 253 sent as zero and ignored on receipt.) 255 NEW: 257 As described in [RFC3306], the multicast address format is as 258 follows: 260 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 261 +--------+----+----+---------+----+----------------+----------+ 262 |11111111|flgs|scop|flgs|rsvd|plen| network prefix | group ID | 263 +--------+----+----+---------+----+----------------+----------+ 265 +-+-+-+-+ 266 flgs is a set of four flags: |X|R|P|T| 267 +-+-+-+-+ 269 X may be set to 0 or 1. 271 This document changes Section 3 of [RFC3956] as follows: 273 OLD: 275 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 276 +--------+----+----+----+----+----+----------------+----------+ 277 |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | 278 +--------+----+----+----+----+----+----------------+----------+ 279 +-+-+-+-+ 280 flgs is a set of four flags: |0|R|P|T| 281 +-+-+-+-+ 283 When the highest-order bit is 0, R = 1 indicates a multicast address 284 that embeds the address on the RP. Then P MUST be set to 1, and 285 consequently T MUST be set to 1, as specified in [RFC3306]. In 286 effect, this implies the prefix FF70::/12. In this case, the last 4 287 bits of the previously reserved field are interpreted as embedding 288 the RP interface ID, as specified in this memo. 290 The behavior is unspecified if P or T is not set to 1, as then the 291 prefix would not be FF70::/12. Likewise, the encoding and the 292 protocol mode used when the two high-order bits in "flgs" are set to 293 11 ("FFF0::/12") is intentionally unspecified until such time that 294 the highest-order bit is defined. Without further IETF 295 specification, implementations SHOULD NOT treat the FFF0::/12 range 296 as Embedded-RP. 298 NEW: 300 | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | 301 +--------+----+----+----+----+----+----------------+----------+ 302 |11111111|flgs|scop|flgs|RIID|plen| network prefix | group ID | 303 +--------+----+----+----+----+----+----------------+----------+ 304 +-+-+-+-+ 305 flgs is a set of four flags: |X|R|P|T| 306 +-+-+-+-+ 307 X may be set to 0 or 1. 309 R = 1 indicates a multicast address that embeds the address of the RP. 310 P MUST be set to 1 according to [RFC3306], as this is a special case of 311 unicast-prefix based addresses. This implies that for instance prefixes 312 ff70::/12 and fff0::/12 are embedded RP prefixes, but all multicast 313 addresses with the R-bit set to 1 MUST be treated as Embedded RP 314 addresses. The behavior is unspecified if P is not set to 1. When the 315 R-bit is set, the last 4 bits of the previously reserved field are 316 interpreted as embedding the RP interface ID, as specified in this memo. 318 This document changes Section 4 of [RFC3956] as follows: 320 OLD: 322 It MUST be a multicast address with "flgs" set to 0111, that is, 323 to be of the prefix FF70::/12, 325 NEW: 327 It MUST be a multicast address with R-bit set to 1. 329 It MUST have P-bit set to 1 when using the embedding in this 330 document as it is a prefix-based address. 332 This document changes Section 7.1 of [RFC3956] as follows: 334 OLD: 336 To avoid loops and inconsistencies, for addresses in the range 337 FF70::/12, the Embedded-RP mapping MUST be considered the longest 338 possible match and higher priority than any other mechanism. 340 NEW: 342 To avoid loops and inconsistencies, for addresses with R-bit set 343 to 1, the Embedded-RP mapping MUST be considered the longest 344 possible match and higher priority than any other mechanism. 346 4.3. RFC4607 348 This document changes the abstract of [RFC4607] as follows: 350 OLD: 352 IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 353 232.255.255.255) range are designated as source-specific multicast 354 (SSM) destination addresses and are reserved for use by source- 355 specific applications and protocols. For IP version 6 (IPv6), the 356 address prefix FF3x::/32 is currently reserved for source-specific 357 multicast use but others may be reserved in the future. This 358 document defines an extension to the Internet network service that 359 applies to datagrams sent to SSM addresses and defines the host 360 and router requirements to support this extension. 362 NEW: 364 IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 365 232.255.255.255) range are designated as source-specific multicast 366 (SSM) destination addresses and are reserved for use by source- 367 specific applications and protocols. For IP version 6 (IPv6), the 368 address prefix ff3x::/32 is currently reserved for source-specific 369 multicast use but others may be reserved in the future. This 370 document defines an extension to the Internet network service that 371 applies to datagrams sent to SSM addresses and defines the host 372 and router requirements to support this extension. 374 This document changes Section 1 of [RFC4607] as follows: 376 OLD: 378 For IPv6, the address prefix FF3x::/32 is reserved for source- 379 specific multicast use, where 'x' is any valid scope identifier, 380 by [IPv6-UBM]. Using the terminology of [IPv6-UBM], all SSM 381 addresses must have P=1, T=1, and plen=0. [IPv6-MALLOC] mandates 382 that the network prefix field of an SSM address also be set to 383 zero, hence all SSM addresses fall in the FF3x::/96 range. Future 384 documents may allow a non-zero network prefix field if, for 385 instance, a new IP- address-to-MAC-address mapping is defined. 386 Thus, address allocation should occur within the FF3x::/96 range, 387 but a system should treat all of FF3x::/32 as SSM addresses, to 388 allow for compatibility with possible future uses of the network 389 prefix field. 391 NEW: 393 For IPv6, all SSM addresses must have P=1 and plen=0 while T-bit 394 is set according to whether the addresses are assigned by IANA 395 [I-D.ietf-6man-multicast-addr-arch-update]. In particular, a 396 system should treat all of ff3x::/32 and ff2x::/32 as SSM 397 addresses, to allow for compatibility with possible future uses of 398 the network prefix field. Other SSM prefixes can be defined in 399 the future. 401 5. IANA Considerations 403 This document may require IANA updates. However, at this point it is 404 not clear exactly what these updates may be. 406 6. Security Considerations 408 Security considerations discussed in [RFC3956], [RFC3306], [RFC4607] 409 and [RFC4291] MUST be taken into account. 411 7. Acknowledgements 413 Many thanks to B. Haberman for the discussions prior to the 414 publication of this document. 416 8. Normative References 418 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 419 Requirement Levels", BCP 14, RFC 2119, March 1997. 421 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 422 Multicast Addresses", RFC 3306, August 2002. 424 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 425 Point (RP) Address in an IPv6 Multicast Address", RFC 426 3956, November 2004. 428 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 429 Architecture", RFC 4291, February 2006. 431 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 432 IP", RFC 4607, August 2006. 434 Authors' Addresses 436 Mohamed Boucadair 437 France Telecom 438 Rennes 35000 439 France 441 Email: mohamed.boucadair@orange.com 443 Stig Venaas 444 Cisco 445 USA 447 Email: stig@cisco.com