idnits 2.17.1 draft-ietf-mboned-rfc3171bis-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 draft header indicates that this document obsoletes RFC3138, but the abstract doesn't seem to directly say this. It does mention RFC3138 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (February 3, 2009) is 5559 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 216, 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 3138 (Obsoleted by RFC 5771) -- Obsolete informational reference (is this intentional?): RFC 3171 (Obsoleted by RFC 5771) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 9 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 Obsoletes: 3171, 3138 D. Meyer 5 (if approved) February 3, 2009 6 Intended status: BCP 7 Expires: August 7, 2009 9 IANA Guidelines for IPv4 Multicast Address Assignments 10 draft-ietf-mboned-rfc3171bis-05 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and 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 August 7, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 This document provides guidance for the Internet Assigned Numbers 50 Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes 51 RFC 3171 and RFC 3138. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Definition of Current Assignment Practice . . . . . . . . . . 3 58 4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4 59 4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 4 60 5. Internetwork Control Block (224.0.1/24) . . . . . . . . . . . 5 61 5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 62 6. AD-HOC Blocks (including 224.0.2.0 - 224.0.255.255) . . . . . 5 63 6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 64 7. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 5 65 7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 66 8. Source Specific Multicast Block (232/8) . . . . . . . . . . . 6 67 8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 68 9. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 70 9.2. Extended AD-HOC . . . . . . . . . . . . . . . . . . . . . 6 71 10. Administratively Scoped Address Block (239/8) . . . . . . . . 7 72 10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7 73 11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7 74 11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 8 75 12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8 76 12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8 77 12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8 78 13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 9 79 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 15. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 82 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 17.1. Normative References . . . . . . . . . . . . . . . . . . . 9 84 17.2. Informative References . . . . . . . . . . . . . . . . . . 9 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 87 1. Introduction 89 The Internet Assigned Numbers Authority (IANA) (www.iana.org) is 90 charged with allocating parameter values for fields in protocols 91 which have been designed, created or are maintained by the Internet 92 Engineering Task Force (IETF). RFC 2780 [RFC2780] provides the IANA 93 guidance in the assignment of parameters for fields in newly 94 developed protocols. This memo expands on section 4.4.2 of RFC 2780 95 and attempts to codify existing IANA practice used in the assignment 96 IPv4 multicast addresses. 98 This document is a revision of RFC 3171 [RFC3171], which it 99 obsoletes. It also obsoletes RFC 3138 [RFC3138]. 101 The terms "Specification Required", "Expert Review", "IESG Approval", 102 "IETF Review", and "Standards Action", are used in this memo to refer 103 to the processes described in [RFC5226]. 105 In general, due to the relatively small size of the IPv4 multicast 106 address space, further assignment of IPv4 multicast address space is 107 recommended only in limited circumstances. Specifically, the IANA 108 should only assign addresses in those cases where the dynamic 109 selection (SDP/SAP), GLOP, SSM or Administratively Scoped address 110 spaces cannot be used. The guidelines described below are reflected 111 in . Network operators should also 112 be aware of the availability of IPv6 multicast addresses and consider 113 using them where feasible. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in BCP 14, RFC 2119 120 [RFC2119]. 122 The word "allocation" designates a block of addresses managed by a 123 registry for the purpose of making assignments and allocations. The 124 word "assignment" designates a block of addresses, or a single 125 address, registered to an end-user for use on a specific network, or 126 set of networks. 128 3. Definition of Current Assignment Practice 130 Unlike IPv4 unicast address assignment, where blocks of addresses are 131 delegated to Regional Internet Registries (RIRs), IPv4 multicast 132 addresses are assigned directly by the IANA. Current registration 133 groups appear as follows [IANA]: 135 Address Range Size Designation 136 ------------- ---- ----------- 138 224.0.0.0 - 224.0.0.255 (/24) Local Network Control Block 140 224.0.1.0 - 224.0.1.255 (/24) Internetwork Control Block 142 224.0.2.0 - 224.0.255.255 (65024) AD-HOC Block (1) 144 224.1.0.0 - 224.1.255.255 (/16) RESERVED 146 224.2.0.0 - 224.2.255.255 (/16) SDP/SAP Block 148 224.252.0.0 - 224.255.255.255 (/14) RESERVED 150 225.0.0.0 - 231.255.255.255 (7 /8s) RESERVED 152 232.0.0.0 - 232.255.255.255 (/8) Source Specific Multicast Block 154 233.0.0.0 - 233.251.255.255 (16515072) GLOP Block 156 233.252.0.0 - 233.255.255.255 (/14) AD-HOC Block (2) 158 234.0.0.0 - 238.255.255.255 (5 /8s) RESERVED 160 239.0.0.0 - 239.255.255.255 (/8) Administratively Scoped Block 162 The IANA generally assigns addresses from the Local Network Control, 163 Internetwork Control and AD-HOC blocks. Assignment guidelines for 164 each of these blocks, as well as for the Source Specific Multicast, 165 GLOP and Administratively Scoped Blocks, are described below. 167 4. Local Network Control Block (224.0.0/24) 169 Addresses in the Local Network Control block are used for protocol 170 control traffic that is not forwarded off link. Examples of this 171 type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328]. 173 4.1. Assignment Guidelines 175 Pursuant to section 4.4.2 of [RFC2780], assignments from the Local 176 Network Control block follow an Expert Review, IESG Approval or 177 Standards Action process. See IANA [IANA] for the current set of 178 assignments. 180 5. Internetwork Control Block (224.0.1/24) 182 Addresses in the Internetwork Control block are used for protocol 183 control that MAY be forwarded through the Internet. Examples include 184 224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover [RFC2730]). 186 5.1. Assignment Guidelines 188 Pursuant to section 4.4.2 of [RFC2780], assignments from the 189 Internetwork Control block follow an Expert Review, IESG Approval or 190 Standards Action process. See IANA [IANA] for the current set of 191 assignments. 193 6. AD-HOC Blocks (including 224.0.2.0 - 224.0.255.255) 195 Addresses in the AD-HOC blocks were traditionally used for 196 assignments for those applications that don't fit in either the Local 197 or Internetwork Control blocks. These addresses are globally routed 198 and are typically used by applications that require small blocks of 199 addressing (e.g., less than a /24 ). Future assignments of blocks of 200 addresses that do not fit in the Local or Internetwork block will be 201 made in the Extended block. 203 6.1. Assignment Guidelines 205 In general, the IANA SHOULD NOT assign addressing in the AD-HOC 206 Blocks. However, the IANA MAY under special circumstances, assign 207 addresses from these blocks. Pursuant to section 4.4.2 of [RFC2780], 208 assignments from the AD-HOC blocks follow an Expert Review, IESG 209 Approval or Standards Action process. See IANA [IANA] for the 210 current set of assignments. 212 7. SDP/SAP Block (224.2/16) 214 Addresses in the SDP/SAP block are used by applications that receive 215 addresses through the Session Announcement Protocol [RFC2974] for use 216 via applications like the session directory tool (such as SDR [SDR]). 218 7.1. Assignment Guidelines 220 Since addresses in the SDP/SAP block are chosen randomly from the 221 range of addresses not already in use [RFC2974], no IANA assignment 222 policy is required. Note that while no additional IANA assignment is 223 required, addresses in the SDP/SAP block are explicitly for use by 224 SDP/SAP and MUST NOT be used for other purposes. 226 8. Source Specific Multicast Block (232/8) 228 The Source Specific Multicast (SSM) is an extension of IP Multicast 229 in which traffic is forwarded to receivers from only those multicast 230 sources for which the receivers have explicitly expressed interest, 231 and is primarily targeted at one-to-many (broadcast) applications. 232 Note that this block was initially assigned to the VMTP transient 233 groups [IANA]. 235 8.1. Assignment Guidelines 237 Because the SSM model essentially makes the entire multicast address 238 space local to the host, no IANA assignment policy is required. 239 Note, however, that while no additional IANA assignment is required, 240 addresses in the SSM block are explicitly for use by SSM and MUST NOT 241 be used for other purposes. 243 9. GLOP Block (233/8) 245 Addresses in the GLOP block are globally scoped statically assigned 246 addresses. The assignment is made, for a domain with 16 bit 247 Autonomous System Number (ASN), by mapping a domain's autonomous 248 system number, expressed in octets as X.Y, into the middle two octets 249 of the GLOP block, yielding an assignment of 233.X.Y.0/24. The 250 mapping and assignment is defined in [RFC3180]. Domains with 32 bit 251 ASN should apply for space in the Extended AD-HOC block, or consider 252 using IPv6 multicast addresses. 254 9.1. Assignment Guidelines 256 Because addresses in the GLOP block are algorithmically pre-assigned, 257 no IANA assignment policy is required. 259 9.2. Extended AD-HOC 261 [RFC3138] delegated to the RIRs the assignment of the GLOP sub-block 262 (233.252.0.0 - 233.255.255.255) mapped by the private AS space 263 (64512-65534) and the IANA reserved ASN 65535 [RFC1930]. This space 264 was known as eGLOP. RFC 3138 should not have asked the RIRs to 265 develop policies for the EGLOP space because [RFC2860] reserves that 266 to the IETF. It is important to make this space available for use by 267 network operators and it is therefore appropriate to obsolete RFC 268 3138 and classify this address range as available for AD-HOC 269 assignment as per the guidelines in section 6. 271 The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST- 272 TEST-NET" for use in documentation and example code. It SHOULD be 273 used in conjunction with the [RFC2606] domain names example.com or 274 example.net in vendor and protocol documentation. Addresses within 275 this block MUST NOT appear on the public Internet. 277 10. Administratively Scoped Address Block (239/8) 279 Addresses in the Administratively Scoped Address block are for local 280 use within a domain and are described in [RFC2365]. 282 10.1. Assignment Guidelines 284 Since addresses in this block are local to a domain, no IANA 285 assignment policy is required. 287 10.1.1. Relative Offsets 289 The relative offsets [RFC2365] are used to ensure that a service can 290 be located independent of the extent of the enclosing scope (see 291 [RFC3180] for details). Since there are only 256 such offsets, the 292 IANA should only assign a relative offset to a protocol that provides 293 an infrastructure supporting service. Examples of such services 294 include the Session Announcement Protocol [RFC2974]. Pursuant to 295 section 4.4.2 of [RFC2780], assignments of Relative Offsets follow an 296 Expert Review, IESG Approval or Standards Action process. See IANA 297 [IANA] for the current set of assignments. 299 11. Application Form 301 Requests for multicast address assignments can be submitted through 302 the application form on the IANA web site at: 304 306 It is important to submit sufficient detail to allow the IESG 307 designated expert to review the application. If the details given in 308 the request are not clear, or further information is needed, the IESG 309 designated expert may request additional information before assigning 310 an address. 312 11.1. Size of assignments of IPv4 Multicast Addresses 314 Occasionally, more than one multicast address is required. In these 315 cases multiple addresses are available in the Extended AD-HOC block. 316 Where a very large number of addresses is required, the assignment 317 will be staged, with additional stages only being made after the 318 complete use of the initial assignment(s). 320 A separate document describing the policy governing assignment of 321 addresses in the AD-HOC and Extended AD-HOC blocks will be developed 322 and published. The format, location and content has not yet been 323 decided and so these will be documented in a future version of this 324 document. 326 12. Annual Review 328 Given the dynamic nature of IPv4 multicast and its associated infra- 329 structure, and the previously undocumented IPv4 multicast address 330 assignment guidelines, the IANA should conduct an annual review of 331 currently assigned addresses. 333 12.1. Address Reclamation 335 During the review described above, addresses that were mis-assigned 336 should, where possible, be reclaimed or reassigned. 338 The IANA should also review assignments in the AD-HOC, "DIS Transient 339 Groups", and ST Multicast Groups [RFC1190] blocks and reclaim those 340 addresses that are not in use on the global Internet (i.e, those 341 applications which can use SSM, GLOP, or Administratively Scoped 342 addressing, or are not globally routed). 344 12.2. Positive renewal 346 It is occasionally appropriate to make temporary assignments that can 347 be renewed as necessary. In cases where this happens the registrant 348 needs to positively request an extension to the temporary assignment 349 or the addresses assigned. When the IANA has not received a request 350 to renew the registration of a temporary assignment within 30 days of 351 the expiry of the assignment it MUST be removed from the multicast 352 registry. 354 Addresses returned to the IANA when a temporary assignment ends MUST 355 NOT be assigned for at least one calendar year. 357 13. Use of IANA Reserved Addresses 359 Applications MUST NOT use addressing in the IANA reserved blocks. 361 14. IANA Considerations 363 This document is all about IANA Considerations. 365 15. Security Considerations 367 The assignment guidelines described in this document do not alter the 368 security properties of either the Any Source or Source Specific 369 multicast service models. 371 16. Acknowledgments 373 The authors would like to thank Joe St. Sauver, John Meylor, Randy 374 Bush, Thomas Narten, Marshall Eubanks, Zaid Albanna (co-author of 375 RFC3171), Kevin Almeroth (co-author of RFC3171) and Leo Vegoda for 376 their constructive feedback and comments. 378 17. References 380 17.1. Normative References 382 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 383 Requirement Levels", BCP 14, RFC 2119, March 1997. 385 17.2. Informative References 387 [IANA] IANA, "IANA Matrix for Protocol Parameter Assignment/ 388 Registration Procedures", 389 . 391 [RFC1190] Casner, S., Lynn, C., Park, P., Schroder, K., and C. 392 Topolcic, "Experimental Internet Stream Protocol: Version 393 2 (ST-II)", RFC 1190, October 1990. 395 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 396 selection, and registration of an Autonomous System (AS)", 397 BCP 6, RFC 1930, March 1996. 399 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 400 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 402 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 404 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 405 RFC 2365, July 1998. 407 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 408 Names", BCP 32, RFC 2606, June 1999. 410 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 411 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 412 December 1999. 414 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 415 Values In the Internet Protocol and Related Headers", 416 BCP 37, RFC 2780, March 2000. 418 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 419 Understanding Concerning the Technical Work of the 420 Internet Assigned Numbers Authority", RFC 2860, June 2000. 422 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 423 Announcement Protocol", RFC 2974, October 2000. 425 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 426 June 2001. 428 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 429 "IANA Guidelines for IPv4 Multicast Address Assignments", 430 BCP 51, RFC 3171, August 2001. 432 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 433 BCP 53, RFC 3180, September 2001. 435 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 436 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 437 May 2008. 439 Authors' Addresses 441 Michelle Cotton 442 Internet Corporation for Assigned Names and Numbers 443 4676 Admiralty Way, Suite 330 444 Marina del Rey 90292 445 United States 447 Phone: +310-823-9358 448 Email: michelle.cotton@icann.org 449 URI: http://www.iana.org/ 451 David Meyer 453 Email: dmm@1-4-5.net