idnits 2.17.1 draft-ietf-mboned-rfc3171bis-04.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 457. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 468. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 475. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 481. 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 (November 3, 2008) is 5652 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 205, 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: May 7, 2009 November 3, 2008 7 IANA Guidelines for IPv4 Multicast Address Assignments 8 draft-ietf-mboned-rfc3171bis-04 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 May 7, 2009. 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 . . . . . . . . . . 4 46 4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4 47 4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 6 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) . . . . . . . . 7 60 10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7 61 11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7 62 11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 8 63 12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8 64 12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8 65 12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8 66 13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 9 67 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 15. Security Considerations . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . 12 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 . Network operators should also 104 be aware of the availability of IPv6 multicast addresses and consider 105 using them where feasible. 107 2. Terminology 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in BCP 14, RFC 2119 112 [RFC2119]. 114 The word "allocation" is defined as a block of addresses managed by a 115 registry for the purpose of making assignments and allocations. The 116 word "assignment" is defined a block of addresses, or a single 117 address, registered to an end-user for use on a specific network, or 118 set of networks. 120 3. Definition of Current Assignment Practice 122 Unlike IPv4 unicast address assignment, where blocks of addresses are 123 delegated to Regional Internet Registries (RIRs), IPv4 multicast 124 addresses are assigned directly by the IANA. Current registration 125 groups appear as follows [IANA]: 127 224.0.0.0 - 224.0.0.255 224.0.0/24 Local Network Control Block 129 224.0.1.0 - 224.0.1.255 224.0.1/24 Internetwork Control Block 131 224.0.2.0 - 224.0.255.0 64769 AD-HOC Block (1) 133 224.1.0.0 - 224.1.255.255 224.1/16 RESERVED 135 224.2.0.0 - 224.2.255.255 224.2/16 SDP/SAP Block 137 224.252.0.0 - 224.255.255.255 224.252/14 RESERVED 139 225.0.0.0 - 231.255.255.255 7 /8s RESERVED 141 232.0.0.0 - 232.255.255.255 232/8 Source Specific Multicast Block 143 233.0.0.0 - 233.251.255.255 16515072 GLOP Block 145 233.252.0.0 - 233.255.255.255 233.252/14 AD-HOC Block (2) 147 234.0.0.0 - 238.255.255.255 5 /8s RESERVED 149 239.0.0.0 - 239.255.255.255 239/8 Administratively Scoped Block 151 The IANA generally assigns addresses from the Local Network Control, 152 Internetwork Control and AD-HOC blocks. Assignment guidelines for 153 each of these blocks, as well as for the Source Specific Multicast, 154 GLOP and Administratively Scoped Blocks, are described below. 156 4. Local Network Control Block (224.0.0/24) 158 Addresses in the Local Network Control block are used for protocol 159 control traffic that is not forwarded off link. Examples of this 160 type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328]. 162 4.1. Assignment Guidelines 164 Pursuant to section 4.4.2 of [RFC2780], assignments from the Local 165 Network Control block follow an Expert Review, IESG Approval or 166 Standards Action process. See IANA [IANA] for the current set of 167 assignments. 169 5. Internetwork Control Block (224.0.1/24) 171 Addresses in the Internetwork Control block are used for protocol 172 control that MAY be forwarded through the Internet. Examples include 173 224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover [RFC2730]). 175 5.1. Assignment Guidelines 177 Pursuant to section 4.4.2 of [RFC2780], assignments from the 178 Internetwork Control block follow an Expert Review, IESG Approval or 179 Standards Action process. See IANA [IANA] for the current set of 180 assignments. 182 6. AD-HOC Blocks (including 224.0.2.0/24 - 224.0.255.0/24) 184 Addresses in the AD-HOC blocks were traditionally used for 185 assignments for those applications that don't fit in either the Local 186 or Internetwork Control blocks. These addresses are globally routed 187 and are typically used by applications that require small blocks of 188 addressing (e.g., less than a /24 ). Future assignments of blocks of 189 addresses that do not fit in the Local or Internetwork block will be 190 made in the Extended block. 192 6.1. Assignment Guidelines 194 In general, the IANA SHOULD NOT assign addressing in the AD-HOC 195 Blocks. However, the IANA MAY under special circumstances, assign 196 addresses from these blocks. Pursuant to section 4.4.2 of [RFC2780], 197 assignments from the AD-HOC blocks follow an Expert Review, IESG 198 Approval or Standards Action process. See IANA [IANA] for the 199 current set of assignments. 201 7. SDP/SAP Block (224.2/16) 203 Addresses in the SDP/SAP block are used by applications that receive 204 addresses through the Session Announcement Protocol [RFC2974] for use 205 via applications like the session directory tool (such as SDR [SDR]). 207 7.1. Assignment Guidelines 209 Since addresses in the SDP/SAP block are chosen randomly from the 210 range of addresses not already in use [RFC2974], no IANA assignment 211 policy is required. Note that while no additional IANA assignment is 212 required, addresses in the SDP/SAP block are explicitly for use by 213 SDP/SAP and MUST NOT be used for other purposes. 215 8. Source Specific Multicast Block (232/8) 217 The Source Specific Multicast (SSM) is an extension of IP Multicast 218 in which traffic is forwarded to receivers from only those multicast 219 sources for which the receivers have explicitly expressed interest, 220 and is primarily targeted at one-to-many (broadcast) applications. 221 Note that this block as initially assigned to the VMTP transient 222 groups IANA [IANA]. 224 8.1. Assignment Guidelines 226 Because the SSM model essentially makes the entire multicast address 227 space local to the host, no IANA assignment policy is required. 228 Note, however, that while no additional IANA assignment is required, 229 addresses in the SSM block are explicitly for use by SSM and MUST NOT 230 be used for other purposes. 232 9. GLOP Block (233/8) 234 Addresses in the GLOP block are globally scoped statically assigned 235 addresses. The assignment is made, for a domain with 16 bit 236 Autonomous System Number (ASN), by mapping a domain's autonomous 237 system number, expressed in octets as X.Y, into the middle two octets 238 of of the GLOP block, yielding an assignment of 233.X.Y.0/24. The 239 mapping and assignment is defined in [RFC3180]. Domains with 32 bit 240 ASN should apply for space in the Extended AD-HOC block, or consider 241 using IPv6 multicast addresses. 243 9.1. Assignment Guidelines 245 Because addresses in the GLOP block are algorithmically pre-assigned, 246 no IANA assignment policy is required. 248 9.2. Extended AD-HOC 250 [RFC3138] delegated assignment of the GLOP sub-block mapped by the 251 [RFC1930] private AS space (233.252.0.0 - 233.255.255.255) to the 252 RIRs. This space was known as eGLOP. RFC 3138 should not have asked 253 the RIRs to develop policies for the EGLOP space because [RFC2860] 254 reserves that to the IETF. It is important to make this space 255 available for use by network operators and it is therefore 256 appropriate to obsolete RFC 3138 and classify this address range as 257 available for AD-HOC assignment as per the guidelines in section 6. 259 The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST- 260 TEST-NET" for use in documentation and example code. It SHOULD be 261 used in conjunction with the [RFC2606] domain names example.com or 262 example.net in vendor and protocol documentation. Addresses within 263 this block MUST NOT appear on the public Internet. 265 10. Administratively Scoped Address Block (239/8) 267 Addresses in the Administratively Scoped Address block are for local 268 use within a domain and are described in [RFC2365]. 270 10.1. Assignment Guidelines 272 Since addresses in this block are local to a domain, no IANA 273 assignment policy is required. 275 10.1.1. Relative Offsets 277 The relative offsets [RFC2365] are used to ensure that a service can 278 be located independent of the extent of the enclosing scope (see 279 [RFC3180] for details). Since there are only 256 such offsets, the 280 IANA should only assign a relative offset to a protocol that provides 281 an infrastructure supporting service. Examples of such services 282 include the Session Announcement Protocol [RFC2974]. Pursuant to 283 section 4.4.2 of [RFC2780], assignments of Relative Offsets follow an 284 Expert Review, IESG Approval or Standards Action process. See IANA 285 [IANA] for the current set of assignments. 287 11. Application Form 289 Requests for multicast address assignments can be submitted through 290 the application form on the IANA web site at: 292 294 It is important to submit sufficient detail to allow the IESG 295 designated expert to review the application. If the details given in 296 the request are not clear, or further information is needed, the IESG 297 designated expert may request additional information before assigning 298 an address. 300 11.1. Size of assignments of IPv4 Multicast Addresses 302 Occasionally, more than one multicast address is required. In these 303 cases multiple addresses are available in the Extended AD-HOC block. 304 Where a very large number of addresses is required, the assignment 305 will be staged, with additional stages only being made after the 306 complete use of the initial assignment(s). 308 A separate document describing the policy governing assignment of 309 addresses in the AD-HOC and Extended AD-HOC blocks will be developed 310 and published. The format, location and content has not yet been 311 decided and so these will be documented in a future version of this 312 document. 314 12. Annual Review 316 Given the dynamic nature of IPv4 multicast and its associated infra- 317 structure, and the previously undocumented IPv4 multicast address 318 assignment guidelines, the IANA should conduct an annual review of 319 currently assigned addresses. 321 12.1. Address Reclamation 323 During the review described above, addresses that were mis-assigned 324 should, where possible, be reclaimed or reassigned. 326 The IANA should also review assignments in the AD-HOC, DIS Transient 327 Groups, and ST Multicast Groups [RFC1190] blocks and reclaim those 328 addresses that are not in use on the global Internet (i.e, those 329 applications which can use SSM, GLOP, or Administratively Scoped 330 addressing, or are not globally routed). 332 12.2. Positive renewal 334 It is occasionally appropriate to make temporary assignments that can 335 be renewed as necessary. In cases where this happens the registrant 336 needs to positively request an extension to the temporary assignment 337 or the addresses assigned. When the IANA has not received a request 338 to renew the registration of a temporary assignment within 30 days of 339 the expiry of the assignment it MUST be removed from the multicast 340 registry. 342 Addresses returned to the IANA when a temporary assignment ends MUST 343 NOT be assigned for at least one calendar year. 345 13. Use of IANA Reserved Addresses 347 Applications MUST NOT use addressing in the IANA reserved blocks. 349 14. IANA Considerations 351 This document is all about IANA Considerations. 353 15. Security Considerations 355 The assignment guidelines described in this document do not alter the 356 security properties of either the Any Source or Source Specific 357 multicast service models. 359 16. Acknowledgments 361 The authors would like to thank Joe St. Sauver, John Meylor, Randy 362 Bush, Thomas Narten, Marshall Eubanks, Zaid Albanna (co-author of 363 RFC3171), Kevin Almeroth (co-author of RFC3171) and Leo Vegoda for 364 their constructive feedback and comments. 366 17. References 368 17.1. Normative References 370 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 371 Requirement Levels", BCP 14, RFC 2119, March 1997. 373 17.2. Informative References 375 [IANA] IANA, "IANA Matrix for Protocol Parameter Assignment/ 376 Registration Procedures", 377 . 379 [RFC1190] Casner, S., Lynn, C., Park, P., Schroder, K., and C. 380 Topolcic, "Experimental Internet Stream Protocol: Version 381 2 (ST-II)", RFC 1190, October 1990. 383 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 384 selection, and registration of an Autonomous System (AS)", 385 BCP 6, RFC 1930, March 1996. 387 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 388 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 390 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 392 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 393 RFC 2365, July 1998. 395 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 396 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 397 October 1998. 399 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 400 Names", BCP 32, RFC 2606, June 1999. 402 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 403 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 404 December 1999. 406 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 407 Values In the Internet Protocol and Related Headers", 408 BCP 37, RFC 2780, March 2000. 410 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 411 Understanding Concerning the Technical Work of the 412 Internet Assigned Numbers Authority", RFC 2860, June 2000. 414 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 415 Announcement Protocol", RFC 2974, October 2000. 417 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 418 June 2001. 420 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 421 "IANA Guidelines for IPv4 Multicast Address Assignments", 422 BCP 51, RFC 3171, August 2001. 424 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 425 BCP 53, RFC 3180, September 2001. 427 Authors' Addresses 429 Michelle Cotton 430 Internet Corporation for Assigned Names and Numbers 431 4676 Admiralty Way, Suite 330 432 Marina del Rey 90292 433 United States 435 Phone: +310-823-9358 436 Email: michelle.cotton@icann.org 437 URI: http://www.iana.org/ 439 David Meyer 441 Email: dmm@1-4-5.net 443 Full Copyright Statement 445 Copyright (C) The IETF Trust (2008). 447 This document is subject to the rights, licenses and restrictions 448 contained in BCP 78, and except as set forth therein, the authors 449 retain all their rights. 451 This document and the information contained herein are provided on an 452 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 453 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 454 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 455 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 456 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 457 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 459 Intellectual Property 461 The IETF takes no position regarding the validity or scope of any 462 Intellectual Property Rights or other rights that might be claimed to 463 pertain to the implementation or use of the technology described in 464 this document or the extent to which any license under such rights 465 might or might not be available; nor does it represent that it has 466 made any independent effort to identify any such rights. Information 467 on the procedures with respect to rights in RFC documents can be 468 found in BCP 78 and BCP 79. 470 Copies of IPR disclosures made to the IETF Secretariat and any 471 assurances of licenses to be made available, or the result of an 472 attempt made to obtain a general license or permission for the use of 473 such proprietary rights by implementers or users of this 474 specification can be obtained from the IETF on-line IPR repository at 475 http://www.ietf.org/ipr. 477 The IETF invites any interested party to bring to its attention any 478 copyrights, patents or patent applications, or other proprietary 479 rights that may cover technology that may be required to implement 480 this standard. Please address the information to the IETF at 481 ietf-ipr@ietf.org.