idnits 2.17.1 draft-ietf-mboned-rfc3171bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 441. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 452. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 465. 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 14 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 -- The abstract seems to indicate that this document obsoletes RFC3171, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (June 24, 2008) is 5784 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'SDR' is mentioned on line 203, but not defined -- Obsolete informational reference (is this intentional?): RFC 1190 (Obsoleted by RFC 1819) -- Obsolete informational reference (is this intentional?): RFC 2030 (Obsoleted by RFC 4330) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3138 (Obsoleted by RFC 5771) -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Cotton 3 Internet-Draft ICANN 4 Intended status: BCP D. Meyer 5 Expires: December 26, 2008 June 24, 2008 7 IANA Guidelines for IPv4 Multicast Address Assignments 8 draft-ietf-mboned-rfc3171bis-03 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 26, 2008. 35 Abstract 37 This document obsoletes RFC 3171. It provides guidance for the 38 Internet Assigned Numbers Authority (IANA) in assigning IPv4 39 multicast addresses. 41 Table of Contents 43 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 44 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 3. Definition of Current Assignment Practice . . . . . . . . . . 3 46 4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4 47 4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 4 48 5. Internetwork Control Block (224.0.1/24) . . . . . . . . . . . 5 49 5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 50 6. AD-HOC Blocks (including 224.0.2.0/24 - 224.0.255.0/24) . . . 5 51 6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 52 7. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 5 53 7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 54 8. Source Specific Multicast Block (232/8) . . . . . . . . . . . 6 55 8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 56 9. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 6 57 9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 58 9.2. Extended AD-HOC . . . . . . . . . . . . . . . . . . . . . 6 59 10. Administratively Scoped Address Block (239/8) . . . . . . . . 6 60 10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7 61 11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7 62 11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 7 63 12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8 64 12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8 65 12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8 66 13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 8 67 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 15. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 70 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 17.1. Normative References . . . . . . . . . . . . . . . . . . . 9 72 17.2. Informative References . . . . . . . . . . . . . . . . . . 9 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 74 Intellectual Property and Copyright Statements . . . . . . . . . . 11 76 1. Introduction 78 The Internet Assigned Numbers Authority (IANA) (www.iana.org) is 79 charged with allocating parameter values for fields in protocols 80 which have been designed, created or are maintained by the Internet 81 Engineering Task Force (IETF). RFC 2780 [RFC2780] provides the IANA 82 guidance in the assignment of parameters for fields in newly 83 developed protocols. This memo expands on section 4.4.2 of RFC 2780 84 and attempts to codify existing IANA practice used in the assignment 85 IPv4 multicast addresses. 87 This document is a revision of RFC 3171 [RFC3171], which it 88 obsoletes. It should retain RFC 3171's status as BCP 51. It also 89 obsoletes RFC 3138 [RFC3138]." 91 The terms "Specification Required", "Expert Review", "IESG Approval", 92 "IETF Consensus", and "Standards Action", are used in this memo to 93 refer to the processes described in [RFC2434]. The keywords MUST, 94 MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, 95 SHOULD, SHOULD NOT are to be interpreted as defined in [RFC2119]. 97 In general, due to the relatively small size of the IPv4 multicast 98 address space, further assignment of IPv4 multicast address space is 99 recommended only in limited circumstances. Specifically, the IANA 100 should only assign addresses in those cases where the dynamic 101 selection (SDP/SAP), GLOP, SSM or Administratively Scoped address 102 spaces cannot be used. The guidelines described below are reflected 103 in . 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in BCP 14, RFC 2119 110 [RFC2119]. 112 The word "allocation" is defined as a block of addresses managed by a 113 registry for the purpose of making assignments and allocations. The 114 word "assignment" is defined a block of addresses, or a single 115 address, registered to an end-user for use on a specific network, or 116 set of networks. 118 3. Definition of Current Assignment Practice 120 Unlike IPv4 unicast address assignment, where blocks of addresses are 121 delegated to Regional Internet Registries (RIRs), IPv4 multicast 122 addresses are assigned directly by the IANA. Current registration 123 groups appear as follows [IANA]: 125 224.0.0.0 - 224.0.0.255 224.0.0/24 Local Network Control Block 127 224.0.1.0 - 224.0.1.255 224.0.1/24 Internetwork Control Block 129 224.0.2.0 - 224.0.255.0 64769 AD-HOC Block (1) 131 224.1.0.0 - 224.1.255.255 224.1/16 RESERVED 133 224.2.0.0 - 224.2.255.255 224.2/16 SDP/SAP Block 135 224.252.0.0 - 224.255.255.255 224.252/14 RESERVED 137 225.0.0.0 - 231.255.255.255 7 /8s RESERVED 139 232.0.0.0 - 232.255.255.255 232/8 Source Specific Multicast Block 141 233.0.0.0 - 233.251.255.255 16515072 GLOP Block 143 233.252.0.0 - 233.255.255.255 233.252/14 AD-HOC Block (2) 145 234.0.0.0 - 238.255.255.255 5 /8s RESERVED 147 239.0.0.0 - 239.255.255.255 239/8 Administratively Scoped Block 149 The IANA generally assigns addresses from the Local Network Control, 150 Internetwork Control and AD-HOC blocks. Assignment guidelines for 151 each of these blocks, as well as for the Source Specific Multicast, 152 GLOP and Administratively Scoped Blocks, are described below. 154 4. Local Network Control Block (224.0.0/24) 156 Addresses in the Local Network Control block are used for protocol 157 control traffic that is not forwarded off link. Examples of this 158 type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328]. 160 4.1. Assignment Guidelines 162 Pursuant to section 4.4.2 of [RFC2780], assignments from the Local 163 Network Control block follow an Expert Review, IESG Approval or 164 Standards Action process. See IANA [IANA] for the current set of 165 assignments. 167 5. Internetwork Control Block (224.0.1/24) 169 Addresses in the Internetwork Control block are used for protocol 170 control that MAY be forwarded through the Internet. Examples include 171 224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover [RFC2730]). 173 5.1. Assignment Guidelines 175 Pursuant to section 4.4.2 of [RFC2780], assignments from the 176 Internetwork Control block follow an Expert Review, IESG Approval or 177 Standards Action process. See IANA [IANA] for the current set of 178 assignments. 180 6. AD-HOC Blocks (including 224.0.2.0/24 - 224.0.255.0/24) 182 Addresses in the AD-HOC blocks were traditionally used for 183 assignments for those applications that don't fit in either the Local 184 or Internetwork Control blocks. These addresses are globally routed 185 and are typically used by applications that require small blocks of 186 addressing (e.g., less than a /24 ). Future assignments of blocks of 187 addresses that do not fit in the Local or Internetwork block will be 188 made in the Extended block. 190 6.1. Assignment Guidelines 192 In general, the IANA SHOULD NOT assign addressing in the AD-HOC 193 Block. However, the IANA MAY under special circumstances, assign 194 addresses from this block. Pursuant to section 4.4.2 of [RFC2780], 195 assignments from the AD-HOC block follow an Expert Review, IESG 196 Approval or Standards Action process. See IANA [IANA] for the 197 current set of assignments. 199 7. SDP/SAP Block (224.2/16) 201 Addresses in the SDP/SAP block are used by applications that receive 202 addresses through the Session Announcement Protocol [RFC2974] for use 203 via applications like the session directory tool (such as SDR [SDR]). 205 7.1. Assignment Guidelines 207 Since addresses in the SDP/SAP block are chosen randomly from the 208 range of addresses not already in use [RFC2974], no IANA assignment 209 policy is required. Note that while no additional IANA assignment is 210 required, addresses in the SDP/SAP block are explicitly for use by 211 SDP/SAP and MUST NOT be used for other purposes. 213 8. Source Specific Multicast Block (232/8) 215 The Source Specific Multicast (SSM) is an extension of IP Multicast 216 in which traffic is forwarded to receivers from only those multicast 217 sources for which the receivers have explicitly expressed interest, 218 and is primarily targeted at one-to-many (broadcast) applications. 219 Note that this block as initially assigned to the VMTP transient 220 groups IANA [IANA]. 222 8.1. Assignment Guidelines 224 Because the SSM model essentially makes the entire multicast address 225 space local to the host, no IANA assignment policy is required. 226 Note, however, that while no additional IANA assignment is required, 227 addresses in the SSM block are explicitly for use by SSM and MUST NOT 228 be used for other purposes. 230 9. GLOP Block (233/8) 232 Addresses in the GLOP block are globally scoped statically assigned 233 addresses. The assignment is made, for a domain with 16 bit 234 Autonomous System Number (ASN), by mapping a domain's autonomous the 235 number, expressed in octets as X.Y, system number into the middle two 236 octets of of the GLOP block, yielding an assignment of 233.X.Y.0/24. 237 The mapping and assignment is defined in [RFC3180]. Domains with 32 238 bit ASN should apply for space in the Extended AD-HOC block. 240 9.1. Assignment Guidelines 242 Because addresses in the GLOP block are algorithmically pre-assigned, 243 no IANA assignment policy is required. 245 9.2. Extended AD-HOC 247 [RFC3138] delegated assignment of the GLOP sub-block mapped by the 248 [RFC1930] private AS space (233.252.0.0 - 233.255.255.255) to the 249 RIRs. This space was known as eGLOP. The RIRs did not develop 250 policies or the mechanisms for the assignment of the eGLOP space and 251 it is important to make this space available for use by network 252 operators. It is therefore appropriate to obsolete RFC 3138 and 253 classify this address range as available for AD-HOC assignment as per 254 the guidelines in section 6. 256 10. Administratively Scoped Address Block (239/8) 258 Addresses in the Administratively Scoped Address block are for local 259 use within a domain and are described in [RFC2365]. 261 10.1. Assignment Guidelines 263 Since addresses in this block are local to a domain, no IANA 264 assignment policy is required. 266 10.1.1. Relative Offsets 268 The relative offsets [RFC2365] are used to ensure that a service can 269 be located independent of the extent of the enclosing scope (see 270 [RFC3180] for details). Since there are only 256 such offsets, the 271 IANA should only assign a relative offset to a protocol that provides 272 an infrastructure supporting service. Examples of such services 273 include the Session Announcement Protocol [RFC2974]. Pursuant to 274 section 4.4.2 of [RFC2780], assignments of Relative Offsets follow an 275 Expert Review, IESG Approval or Standards Action process. See IANA 276 [IANA] for the current set of assignments. 278 11. Application Form 280 Requests for multicast address assignments can be submitted through 281 the application form on the IANA web site at: 283 285 It is important to submit sufficient detail to allow the IESG 286 designated expert to review the application. If the details given in 287 the request are not clear, or further information is needed, the IESG 288 designated expert may request additional information before assigning 289 an address. 291 11.1. Size of assignments of IPv4 Multicast Addresses 293 Occasionally, more than one multicast address is required. In these 294 cases multiple addresses are available in the Extended AD-HOC block. 295 Where a very large number of addresses is required, the assignment 296 will be staged, with additional stages only being made after the 297 complete use of the initial assignment(s). 299 A separate document describing the policy governing assignment of 300 addresses in the AD-HOC and Extended AD-HOC blocks will be developed 301 and published. The format, location and content has not yet been 302 decided and so these will be documented in a future version of this 303 document. 305 12. Annual Review 307 Given the dynamic nature of IPv4 multicast and its associated infra- 308 structure, and the previously undocumented IPv4 multicast address 309 assignment guidelines, the IANA should conduct an annual review of 310 currently assigned addresses. 312 12.1. Address Reclamation 314 During the review described above, addresses that were mis-assigned 315 should, where possible, be reclaimed or reassigned. 317 The IANA should also review assignments in the AD-HOC, DIS Transient 318 Groups, and ST Multicast Groups [RFC1190] blocks and reclaim those 319 addresses that are not in use on the global Internet (i.e, those 320 applications which can use SSM, GLOP, or Administratively Scoped 321 addressing, or are not globally routed). 323 12.2. Positive renewal 325 It is occasionally appropriate to make temporary assignments that can 326 be renewed as necessary. In cases where this happens the registrant 327 needs to positively request an extension to the temporary assignment 328 or the addresses assigned. When the IANA has not received a request 329 to renew the registration of a temporary assignment within 30 days of 330 the expiry of the assignment it MUST be removed from the multicast 331 registry. 333 Addresses returned to the IANA when a temporary assignment ends MUST 334 NOT be assigned for at least one calendar year. 336 13. Use of IANA Reserved Addresses 338 Applications MUST NOT use addressing in the IANA reserved blocks. 340 14. IANA Considerations 342 This document is all about IANA Considerations. 344 15. Security Considerations 346 The assignment guidelines described in this document do not alter the 347 security properties of either the Any Source or Source Specific 348 multicast service models. 350 16. Acknowledgments 352 The authors would like to thank Joe St. Sauver, John Meylor, Randy 353 Bush, Thomas Narten, Marshall Eubanks, Zaid Albanna (co-author of 354 RFC3171), Kevin Almeroth (co-author of RFC3171) and Leo Vegoda for 355 their constructive feedback and comments. 357 17. References 359 17.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 17.2. Informative References 366 [IANA] IANA, "IANA Matrix for Protocol Parameter Assignment/ 367 Registration Procedures", 368 . 370 [RFC1190] Casner, S., Lynn, C., Park, P., Schroder, K., and C. 371 Topolcic, "Experimental Internet Stream Protocol: Version 372 2 (ST-II)", RFC 1190, October 1990. 374 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 375 selection, and registration of an Autonomous System (AS)", 376 BCP 6, RFC 1930, March 1996. 378 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 379 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 381 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 383 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 384 RFC 2365, July 1998. 386 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 387 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 388 October 1998. 390 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 391 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 392 December 1999. 394 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 395 Values In the Internet Protocol and Related Headers", 396 BCP 37, RFC 2780, March 2000. 398 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 399 Announcement Protocol", RFC 2974, October 2000. 401 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 402 June 2001. 404 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 405 "IANA Guidelines for IPv4 Multicast Address Assignments", 406 BCP 51, RFC 3171, August 2001. 408 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 409 BCP 53, RFC 3180, September 2001. 411 Authors' Addresses 413 Michelle Cotton 414 Internet Corporation for Assigned Names and Numbers 415 4676 Admiralty Way, Suite 330 416 Marina del Rey 90292 417 United States 419 Phone: +310-823-9358 420 Email: michelle.cotton@icann.org 421 URI: http://www.iana.org/ 423 David Meyer 425 Email: dmm@1-4-5.net 427 Full Copyright Statement 429 Copyright (C) The IETF Trust (2008). 431 This document is subject to the rights, licenses and restrictions 432 contained in BCP 78, and except as set forth therein, the authors 433 retain all their rights. 435 This document and the information contained herein are provided on an 436 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 437 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 438 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 439 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 440 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 441 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 443 Intellectual Property 445 The IETF takes no position regarding the validity or scope of any 446 Intellectual Property Rights or other rights that might be claimed to 447 pertain to the implementation or use of the technology described in 448 this document or the extent to which any license under such rights 449 might or might not be available; nor does it represent that it has 450 made any independent effort to identify any such rights. Information 451 on the procedures with respect to rights in RFC documents can be 452 found in BCP 78 and BCP 79. 454 Copies of IPR disclosures made to the IETF Secretariat and any 455 assurances of licenses to be made available, or the result of an 456 attempt made to obtain a general license or permission for the use of 457 such proprietary rights by implementers or users of this 458 specification can be obtained from the IETF on-line IPR repository at 459 http://www.ietf.org/ipr. 461 The IETF invites any interested party to bring to its attention any 462 copyrights, patents or patent applications, or other proprietary 463 rights that may cover technology that may be required to implement 464 this standard. Please address the information to the IETF at 465 ietf-ipr@ietf.org.