idnits 2.17.1 draft-ietf-mboned-rfc3171bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 16 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. -- The abstract seems to indicate that this document updates RFC2780, but the header doesn't have an 'Updates:' line to match this. 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 (November 17, 2009) is 5267 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) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- 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 4330 (Obsoleted by RFC 5905) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Cotton 3 Internet-Draft L. Vegoda 4 Obsoletes: 3171, 3138 ICANN 5 (if approved) D. Meyer 6 Intended status: BCP November 17, 2009 7 Expires: May 21, 2010 9 IANA Guidelines for IPv4 Multicast Address Assignments 10 draft-ietf-mboned-rfc3171bis-08 12 Abstract 14 This document provides guidance for the Internet Assigned Numbers 15 Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes 16 RFC 3171 and RFC 3138 and updates RFC 2780. 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on May 21, 2010. 41 Copyright Notice 43 Copyright (c) 2009 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Definition of Current Assignment Practice . . . . . . . . . . 4 61 4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4 62 4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 63 5. Internetwork Control Block (224.0.1/24) . . . . . . . . . . . 5 64 5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 65 6. AD-HOC blocks (including 224.0.2.0 - 224.0.255.255, 66 224.3.0.0 - 224.4.255.255 and 233.252.0.0 - 67 233.255.255.255) . . . . . . . . . . . . . . . . . . . . . . . 5 68 6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 69 7. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 6 70 7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 71 8. Source Specific Multicast Block (232/8) . . . . . . . . . . . 6 72 8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 73 9. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 6 74 9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 75 9.2. AD-HOC Block III . . . . . . . . . . . . . . . . . . . . . 7 76 10. Administratively Scoped Address Block (239/8) . . . . . . . . 7 77 10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7 78 11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7 79 11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 8 80 12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8 81 12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8 82 12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8 83 13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 9 84 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 85 15. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 87 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 17.1. Normative References . . . . . . . . . . . . . . . . . . . 9 89 17.2. Informative References . . . . . . . . . . . . . . . . . . 9 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 92 1. Introduction 94 The Internet Assigned Numbers Authority (IANA) (www.iana.org) is 95 charged with allocating parameter values for fields in protocols 96 which have been designed, created or are maintained by the Internet 97 Engineering Task Force (IETF). RFC 2780 [RFC2780] provides the IANA 98 guidance in the assignment of parameters for fields in newly 99 developed protocols. This memo expands on section 4.4.2 of RFC 2780 100 and attempts to codify existing IANA practice used in the assignment 101 IPv4 multicast addresses. 103 This document is a revision of RFC 3171 [RFC3171], which it 104 obsoletes. It also obsoletes RFC 3138 [RFC3138] and updates 105 [RFC2780]. 107 The terms "Specification Required", "Expert Review", "IESG Approval", 108 "IETF Review", and "Standards Action", are used in this memo to refer 109 to the processes described in [RFC5226]. 111 In general, due to the relatively small size of the IPv4 multicast 112 address space, further assignment of IPv4 multicast address space is 113 recommended only in limited circumstances. Specifically, the IANA 114 should only assign addresses in those cases where: 115 - the dynamic selection Session Description Protocol/Session 116 Announcement Protocol (SDP/SAP); 117 - GLOP (not an acronym); 118 - Source Specific Multicast (SSM); or 119 - Administratively Scoped address spaces 120 cannot be used. The guidelines described below are reflected in 121 [IANA-protocols]. Network operators should also be aware of the 122 availability of IPv6 multicast addresses and consider using them 123 where feasible. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in BCP 14, RFC 2119 130 [RFC2119]. 132 The word "allocation" designates a block of addresses managed by a 133 registry for the purpose of making assignments and allocations. The 134 word "assignment" designates a block of addresses, or a single 135 address, registered to an end-user for use on a specific network, or 136 set of networks. 138 3. Definition of Current Assignment Practice 140 Unlike IPv4 unicast address assignment, where blocks of addresses are 141 delegated to Regional Internet Registries (RIRs), IPv4 multicast 142 addresses are assigned directly by the IANA. Current registration 143 groups appear as follows [IANA]: 145 Address Range Size Designation 146 ------------- ---- ----------- 148 224.0.0.0 - 224.0.0.255 (/24) Local Network Control Block 150 224.0.1.0 - 224.0.1.255 (/24) Internetwork Control Block 152 224.0.2.0 - 224.0.255.255 (65024) AD-HOC Block I 154 224.1.0.0 - 224.1.255.255 (/16) RESERVED 156 224.2.0.0 - 224.2.255.255 (/16) SDP/SAP Block 158 224.3.0.0 - 224.4.255.255 (2 /16s) AD-HOC Block II 160 224.5.0.0 - 224.255.255.255 (251 /16s) RESERVED 162 225.0.0.0 - 231.255.255.255 (7 /8s) RESERVED 164 232.0.0.0 - 232.255.255.255 (/8) Source Specific Multicast Block 166 233.0.0.0 - 233.251.255.255 (16515072) GLOP Block 168 233.252.0.0 - 233.255.255.255 (/14) AD-HOC Block III 170 234.0.0.0 - 238.255.255.255 (5 /8s) RESERVED 172 239.0.0.0 - 239.255.255.255 (/8) Administratively Scoped Block 174 The IANA generally assigns addresses from the Local Network Control, 175 Internetwork Control and AD-HOC blocks. Assignment guidelines for 176 each of these blocks, as well as for the Source Specific Multicast, 177 GLOP and Administratively Scoped Blocks, are described below. 179 4. Local Network Control Block (224.0.0/24) 181 Addresses in the Local Network Control block are used for protocol 182 control traffic that is not forwarded off link. Examples of this 183 type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328]. 185 4.1. Assignment Guidelines 187 Pursuant to section 4.4.2 of [RFC2780], assignments from the Local 188 Network Control block follow an Expert Review, IESG Approval or 189 Standards Action process. See IANA [IANA] for the current set of 190 assignments. 192 5. Internetwork Control Block (224.0.1/24) 194 Addresses in the Internetwork Control block are used for protocol 195 control traffic that MAY be forwarded through the Internet. Examples 196 include 224.0.1.1 (NTP [RFC4330]) and 224.0.1.68 (mdhcpdiscover 197 [RFC2730]). 199 5.1. Assignment Guidelines 201 Pursuant to section 4.4.2 of [RFC2780], assignments from the 202 Internetwork Control block follow an Expert Review, IESG Approval or 203 Standards Action process. See IANA [IANA] for the current set of 204 assignments. 206 6. AD-HOC blocks (including 224.0.2.0 - 224.0.255.255, 224.3.0.0 - 207 224.4.255.255 and 233.252.0.0 - 233.255.255.255) 209 Addresses in the AD-HOC blocks were traditionally used for 210 assignments for those applications that don't fit in either the Local 211 or Internetwork Control blocks. These addresses MAY be globally 212 routed and are typically used by applications that require small 213 blocks of addressing (e.g., less than a /24 ). Future assignments of 214 blocks of addresses that do not fit in the Local or Internetwork 215 block will be made in the Ad-Hoc Block III. 217 6.1. Assignment Guidelines 219 In general, the IANA SHOULD NOT assign addressing in the AD-HOC 220 Blocks. However, the IANA MAY under special circumstances, assign 221 addresses from these blocks. Pursuant to section 4.4.2 of [RFC2780], 222 assignments from the AD-HOC blocks follow an Expert Review, IESG 223 Approval or Standards Action process. See [IANA] for the current set 224 of assignments. 226 7. SDP/SAP Block (224.2/16) 228 Addresses in the SDP/SAP block are used by applications that receive 229 addresses through the Session Announcement Protocol [RFC2974] for use 230 via applications like the session directory tool (such as SDR [SDR]). 232 7.1. Assignment Guidelines 234 Since addresses in the SDP/SAP block are chosen randomly from the 235 range of addresses not already in use [RFC2974], no IANA assignment 236 policy is required. Note that while no additional IANA assignment is 237 required, addresses in the SDP/SAP block are explicitly for use by 238 SDP/SAP and MUST NOT be used for other purposes. 240 8. Source Specific Multicast Block (232/8) 242 SSM [RFC4607] is an extension of IP Multicast in which traffic is 243 forwarded to receivers from only those multicast sources for which 244 the receivers have explicitly expressed interest, and is primarily 245 targeted at one-to-many (broadcast) applications. Note that this 246 block was initially assigned to the Versatile Message Transaction 247 Protocol (VMTP) transient groups [IANA]. 249 8.1. Assignment Guidelines 251 Because the SSM model essentially makes the entire multicast address 252 space local to the host, no IANA assignment policy is required. 253 Note, however, that while no additional IANA assignment is required, 254 addresses in the SSM block are explicitly for use by SSM and MUST NOT 255 be used for other purposes. 257 9. GLOP Block (233/8) 259 Addresses in the GLOP block are globally scoped statically assigned 260 addresses. The assignment is made, for a domain with 16 bit 261 Autonomous System Number (ASN), by mapping a domain's autonomous 262 system number, expressed in octets as X.Y, into the middle two octets 263 of the GLOP block, yielding an assignment of 233.X.Y.0/24. The 264 mapping and assignment is defined in [RFC3180]. Domains with a 32 265 bit ASN MAY apply for space in AD-HOC Block III, or consider using 266 IPv6 multicast addresses. 268 9.1. Assignment Guidelines 270 Because addresses in the GLOP block are algorithmically pre-assigned, 271 no IANA assignment policy is required. 273 9.2. AD-HOC Block III 275 [RFC3138] delegated to the RIRs the assignment of the GLOP sub-block 276 (233.252.0.0 - 233.255.255.255) mapped by the private Auronomous 277 System (AS) space (64512-65534) and the IANA reserved ASN 65535 278 [RFC1930]. This space was known as Extended GLOP (EGLOP). RFC 3138 279 should not have asked the RIRs to develop policies for the EGLOP 280 space because [RFC2860] reserves that to the IETF. It is important 281 to make this space available for use by network operators and it is 282 therefore appropriate to obsolete RFC 3138 and classify this address 283 range as available for AD-HOC assignment as per the guidelines in 284 section 6. 286 The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST- 287 TEST-NET" for use in documentation and example code. 233.252.0.0/24 288 SHOULD be used in conjunction with the [RFC2606] domain names 289 example.com or example.net in vendor and protocol documentation. 290 Addresses within 233.252.0.0/24 MUST NOT appear on the public 291 Internet. 293 10. Administratively Scoped Address Block (239/8) 295 Addresses in the Administratively Scoped Address block are for local 296 use within a domain and are described in [RFC2365]. 298 10.1. Assignment Guidelines 300 Since addresses in this block are local to a domain, no IANA 301 assignment policy is required. 303 10.1.1. Relative Offsets 305 The relative offsets [RFC2365] are used to ensure that a service can 306 be located independent of the extent of the enclosing scope (see 307 [RFC3180] for details). Since there are only 256 such offsets, the 308 IANA should only assign a relative offset to a protocol that provides 309 an infrastructure supporting service. Examples of such services 310 include the Session Announcement Protocol [RFC2974]. Pursuant to 311 section 4.4.2 of [RFC2780], assignments of Relative Offsets follow an 312 Expert Review, IESG Approval or Standards Action process. See [IANA] 313 for the current set of assignments. 315 11. Application Form 317 Requests for multicast address assignments can be submitted through 318 the application form on the IANA web site at[IANA-registration]. It 319 is important to submit sufficient detail to allow the IESG designated 320 expert to review the application. If the details given in the 321 request are not clear, or further information is needed, the IESG 322 designated expert may request additional information before assigning 323 an address. 325 11.1. Size of assignments of IPv4 Multicast Addresses 327 Occasionally more than one multicast address is required. In these 328 cases multiple addresses are available in AD-HOC Block III. Where 329 there is a requirement for a very large number of addresses, the 330 assignment will be staged. The additional stages will only be made 331 after the complete use of the initial assignment(s). 333 A separate document describing the policy governing assignment of 334 addresses in the AD-HOC blocks I, II and III will be developed and 335 published. The format, location and content has not yet been decided 336 and so these will be documented in a future version of this document. 338 12. Annual Review 340 Given the dynamic nature of IPv4 multicast and its associated 341 infrastructure, and the previously undocumented IPv4 multicast 342 address assignment guidelines, the IANA should conduct an annual 343 review of currently assigned addresses. 345 12.1. Address Reclamation 347 During the review described above, addresses that were mis-assigned 348 should, where possible, be reclaimed or reassigned. 350 The IANA should also review assignments in the AD-HOC, "DIS Transient 351 Groups", and ST Multicast Groups [RFC1819] blocks and reclaim those 352 addresses that are not in use on the global Internet (i.e, those 353 applications which can use SSM, GLOP, or Administratively Scoped 354 addressing, or are not globally routed). 356 12.2. Positive renewal 358 It is occasionally appropriate to make temporary assignments that can 359 be renewed as necessary. In cases where this happens the registrant 360 needs to positively request an extension to the temporary assignment 361 or the addresses assigned. When the IANA has not received a request 362 to renew the registration of a temporary assignment within 30 days of 363 the expiry of the assignment it MUST be removed from the multicast 364 registry. 366 Addresses returned to the IANA when a temporary assignment ends MUST 367 NOT be assigned to anyone other than the last registrant for at least 368 one calendar year. 370 13. Use of IANA Reserved Addresses 372 Applications MUST NOT use addressing in the IANA reserved blocks. 374 14. IANA Considerations 376 IANA is requested to update its IPv4 multicast request and assignment 377 procedures to reflect this document. 379 15. Security Considerations 381 The assignment guidelines described in this document do not alter the 382 security properties of either the Any Source or Source Specific 383 multicast service models. 385 16. Acknowledgments 387 The authors would like to thank Joe St. Sauver, John Meylor, Randy 388 Bush, Thomas Narten, Marshall Eubanks, Zaid Albanna (co-author of 389 RFC3171), Kevin Almeroth (co-author of RFC3171) Pekka Savola and 390 Alfred Hoenes for their constructive feedback and comments. 392 17. References 394 17.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 400 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 401 May 2008. 403 17.2. Informative References 405 [IANA] IANA, "IANA Protocol Registries", . 407 [IANA-protocols] 408 IANA, "IANA Protocol Registries", 409 . 411 [IANA-registration] 412 IANA, "IANA Protocol Registration Forms", 413 . 415 [RFC1819] Delgrossi, L., Berger, L., Duong, D., Jackowski, S., and 416 S. Schaller, "Internet Stream Protocol Version 2 (ST2) 417 Protocol Specification - Version ST2+", RFC 1819, 418 August 1995. 420 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 421 selection, and registration of an Autonomous System (AS)", 422 BCP 6, RFC 1930, March 1996. 424 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 426 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 427 RFC 2365, July 1998. 429 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 430 Names", BCP 32, RFC 2606, June 1999. 432 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 433 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 434 December 1999. 436 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 437 Values In the Internet Protocol and Related Headers", 438 BCP 37, RFC 2780, March 2000. 440 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 441 Understanding Concerning the Technical Work of the 442 Internet Assigned Numbers Authority", RFC 2860, June 2000. 444 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 445 Announcement Protocol", RFC 2974, October 2000. 447 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 448 June 2001. 450 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 451 "IANA Guidelines for IPv4 Multicast Address Assignments", 452 BCP 51, RFC 3171, August 2001. 454 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 455 BCP 53, RFC 3180, September 2001. 457 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 458 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 460 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 461 IP", RFC 4607, August 2006. 463 [SDR] UCL/ISI, "Session Directory Tool", 464 . 466 Authors' Addresses 468 Michelle Cotton 469 Internet Corporation for Assigned Names and Numbers 470 4676 Admiralty Way, Suite 330 471 Marina del Rey 90292 472 United States of America 474 Phone: +310-823-9358 475 Email: michelle.cotton@icann.org 476 URI: http://www.iana.org/ 478 Leo Vegoda 479 Internet Corporation for Assigned Names and Numbers 480 4676 Admiralty Way, Suite 330 481 Marina del Rey 90292 482 United States of America 484 Phone: +310-823-9358 485 Email: leo.vegoda@icann.org 486 URI: http://www.iana.org/ 488 David Meyer 490 Email: dmm@1-4-5.net