idnits 2.17.1 draft-ietf-mboned-rfc3171bis-07.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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. 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 (April 15, 2009) is 5490 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 221, 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 (==), 8 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 April 15, 2009 7 Expires: October 17, 2009 9 IANA Guidelines for IPv4 Multicast Address Assignments 10 draft-ietf-mboned-rfc3171bis-07 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 October 17, 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 in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document provides guidance for the Internet Assigned Numbers 49 Authority (IANA) in assigning IPv4 multicast addresses. It obsoletes 50 RFC 3171 and RFC 3138. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Definition of Current Assignment Practice . . . . . . . . . . 3 57 4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4 58 4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 59 5. Internetwork Control Block (224.0.1/24) . . . . . . . . . . . 5 60 5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 61 6. AD-HOC blocks (including 224.0.2.0 - 224.0.255.255, 62 224.3.0.0 - 224.4.255.255 and 233.252.0.0 - 63 233.255.255.255) . . . . . . . . . . . . . . . . . . . . . . . 5 64 6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 65 7. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 5 66 7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 67 8. Source Specific Multicast Block (232/8) . . . . . . . . . . . 6 68 8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 69 9. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 6 70 9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 71 9.2. AD-HOC Block III . . . . . . . . . . . . . . . . . . . . . 7 72 10. Administratively Scoped Address Block (239/8) . . . . . . . . 7 73 10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7 74 11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7 75 11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 8 76 12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8 77 12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8 78 12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8 79 13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 9 80 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 15. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 83 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 17.1. Normative References . . . . . . . . . . . . . . . . . . . 9 85 17.2. Informative References . . . . . . . . . . . . . . . . . . 9 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 The Internet Assigned Numbers Authority (IANA) (www.iana.org) is 91 charged with allocating parameter values for fields in protocols 92 which have been designed, created or are maintained by the Internet 93 Engineering Task Force (IETF). RFC 2780 [RFC2780] provides the IANA 94 guidance in the assignment of parameters for fields in newly 95 developed protocols. This memo expands on section 4.4.2 of RFC 2780 96 and attempts to codify existing IANA practice used in the assignment 97 IPv4 multicast addresses. 99 This document is a revision of RFC 3171 [RFC3171], which it 100 obsoletes. It also obsoletes RFC 3138 [RFC3138]. 102 The terms "Specification Required", "Expert Review", "IESG Approval", 103 "IETF Review", and "Standards Action", are used in this memo to refer 104 to the processes described in [RFC5226]. 106 In general, due to the relatively small size of the IPv4 multicast 107 address space, further assignment of IPv4 multicast address space is 108 recommended only in limited circumstances. Specifically, the IANA 109 should only assign addresses in those cases where the dynamic 110 selection (SDP/SAP), GLOP, SSM or Administratively Scoped address 111 spaces cannot be used. The guidelines described below are reflected 112 in . Network operators should also 113 be aware of the availability of IPv6 multicast addresses and consider 114 using them where feasible. 116 2. Terminology 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in BCP 14, RFC 2119 121 [RFC2119]. 123 The word "allocation" designates a block of addresses managed by a 124 registry for the purpose of making assignments and allocations. The 125 word "assignment" designates a block of addresses, or a single 126 address, registered to an end-user for use on a specific network, or 127 set of networks. 129 3. Definition of Current Assignment Practice 131 Unlike IPv4 unicast address assignment, where blocks of addresses are 132 delegated to Regional Internet Registries (RIRs), IPv4 multicast 133 addresses are assigned directly by the IANA. Current registration 134 groups appear as follows [IANA]: 136 Address Range Size Designation 137 ------------- ---- ----------- 139 224.0.0.0 - 224.0.0.255 (/24) Local Network Control Block 141 224.0.1.0 - 224.0.1.255 (/24) Internetwork Control Block 143 224.0.2.0 - 224.0.255.255 (65024) AD-HOC Block I 145 224.1.0.0 - 224.1.255.255 (/16) RESERVED 147 224.2.0.0 - 224.2.255.255 (/16) SDP/SAP Block 149 224.3.0.0 - 224.4.255.255 (2 /16s) AD-HOC Block II 151 224.5.0.0 - 224.255.255.255 (251 /16s) RESERVED 153 225.0.0.0 - 231.255.255.255 (7 /8s) RESERVED 155 232.0.0.0 - 232.255.255.255 (/8) Source Specific Multicast Block 157 233.0.0.0 - 233.251.255.255 (16515072) GLOP Block 159 233.252.0.0 - 233.255.255.255 (/14) AD-HOC Block III 161 234.0.0.0 - 238.255.255.255 (5 /8s) RESERVED 163 239.0.0.0 - 239.255.255.255 (/8) Administratively Scoped Block 165 The IANA generally assigns addresses from the Local Network Control, 166 Internetwork Control and AD-HOC blocks. Assignment guidelines for 167 each of these blocks, as well as for the Source Specific Multicast, 168 GLOP and Administratively Scoped Blocks, are described below. 170 4. Local Network Control Block (224.0.0/24) 172 Addresses in the Local Network Control block are used for protocol 173 control traffic that is not forwarded off link. Examples of this 174 type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328]. 176 4.1. Assignment Guidelines 178 Pursuant to section 4.4.2 of [RFC2780], assignments from the Local 179 Network Control block follow an Expert Review, IESG Approval or 180 Standards Action process. See IANA [IANA] for the current set of 181 assignments. 183 5. Internetwork Control Block (224.0.1/24) 185 Addresses in the Internetwork Control block are used for protocol 186 control traffic that MAY be forwarded through the Internet. Examples 187 include 224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover 188 [RFC2730]). 190 5.1. Assignment Guidelines 192 Pursuant to section 4.4.2 of [RFC2780], assignments from the 193 Internetwork Control block follow an Expert Review, IESG Approval or 194 Standards Action process. See IANA [IANA] for the current set of 195 assignments. 197 6. AD-HOC blocks (including 224.0.2.0 - 224.0.255.255, 224.3.0.0 - 198 224.4.255.255 and 233.252.0.0 - 233.255.255.255) 200 Addresses in the AD-HOC blocks were traditionally used for 201 assignments for those applications that don't fit in either the Local 202 or Internetwork Control blocks. These addresses MAY be globally 203 routed and are typically used by applications that require small 204 blocks of addressing (e.g., less than a /24 ). Future assignments of 205 blocks of addresses that do not fit in the Local or Internetwork 206 block will be made in the Ad-Hoc Block III. 208 6.1. Assignment Guidelines 210 In general, the IANA SHOULD NOT assign addressing in the AD-HOC 211 Blocks. However, the IANA MAY under special circumstances, assign 212 addresses from these blocks. Pursuant to section 4.4.2 of [RFC2780], 213 assignments from the AD-HOC blocks follow an Expert Review, IESG 214 Approval or Standards Action process. See [IANA] for the current set 215 of assignments. 217 7. SDP/SAP Block (224.2/16) 219 Addresses in the SDP/SAP block are used by applications that receive 220 addresses through the Session Announcement Protocol [RFC2974] for use 221 via applications like the session directory tool (such as SDR [SDR]). 223 7.1. Assignment Guidelines 225 Since addresses in the SDP/SAP block are chosen randomly from the 226 range of addresses not already in use [RFC2974], no IANA assignment 227 policy is required. Note that while no additional IANA assignment is 228 required, addresses in the SDP/SAP block are explicitly for use by 229 SDP/SAP and MUST NOT be used for other purposes. 231 8. Source Specific Multicast Block (232/8) 233 The Source Specific Multicast (SSM) is an extension of IP Multicast 234 in which traffic is forwarded to receivers from only those multicast 235 sources for which the receivers have explicitly expressed interest, 236 and is primarily targeted at one-to-many (broadcast) applications. 237 Note that this block was initially assigned to the VMTP transient 238 groups [IANA]. 240 8.1. Assignment Guidelines 242 Because the SSM model essentially makes the entire multicast address 243 space local to the host, no IANA assignment policy is required. 244 Note, however, that while no additional IANA assignment is required, 245 addresses in the SSM block are explicitly for use by SSM and MUST NOT 246 be used for other purposes. 248 9. GLOP Block (233/8) 250 Addresses in the GLOP block are globally scoped statically assigned 251 addresses. The assignment is made, for a domain with 16 bit 252 Autonomous System Number (ASN), by mapping a domain's autonomous 253 system number, expressed in octets as X.Y, into the middle two octets 254 of the GLOP block, yielding an assignment of 233.X.Y.0/24. The 255 mapping and assignment is defined in [RFC3180]. Domains with 32 bit 256 ASN should apply for space in AD-HOC Block III, or consider using 257 IPv6 multicast addresses. 259 9.1. Assignment Guidelines 261 Because addresses in the GLOP block are algorithmically pre-assigned, 262 no IANA assignment policy is required. 264 9.2. AD-HOC Block III 266 [RFC3138] delegated to the RIRs the assignment of the GLOP sub-block 267 (233.252.0.0 - 233.255.255.255) mapped by the private AS space 268 (64512-65534) and the IANA reserved ASN 65535 [RFC1930]. This space 269 was known as eGLOP. RFC 3138 should not have asked the RIRs to 270 develop policies for the EGLOP space because [RFC2860] reserves that 271 to the IETF. It is important to make this space available for use by 272 network operators and it is therefore appropriate to obsolete RFC 273 3138 and classify this address range as available for AD-HOC 274 assignment as per the guidelines in section 6. 276 The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST- 277 TEST-NET" for use in documentation and example code. 233.252.0.0/24 278 SHOULD be used in conjunction with the [RFC2606] domain names 279 example.com or example.net in vendor and protocol documentation. 280 Addresses within 233.252.0.0/24 MUST NOT appear on the public 281 Internet. 283 10. Administratively Scoped Address Block (239/8) 285 Addresses in the Administratively Scoped Address block are for local 286 use within a domain and are described in [RFC2365]. 288 10.1. Assignment Guidelines 290 Since addresses in this block are local to a domain, no IANA 291 assignment policy is required. 293 10.1.1. Relative Offsets 295 The relative offsets [RFC2365] are used to ensure that a service can 296 be located independent of the extent of the enclosing scope (see 297 [RFC3180] for details). Since there are only 256 such offsets, the 298 IANA should only assign a relative offset to a protocol that provides 299 an infrastructure supporting service. Examples of such services 300 include the Session Announcement Protocol [RFC2974]. Pursuant to 301 section 4.4.2 of [RFC2780], assignments of Relative Offsets follow an 302 Expert Review, IESG Approval or Standards Action process. See [IANA] 303 for the current set of assignments. 305 11. Application Form 307 Requests for multicast address assignments can be submitted through 308 the application form on the IANA web site at: 310 312 It is important to submit sufficient detail to allow the IESG 313 designated expert to review the application. If the details given in 314 the request are not clear, or further information is needed, the IESG 315 designated expert may request additional information before assigning 316 an address. 318 11.1. Size of assignments of IPv4 Multicast Addresses 320 Occasionally more than one multicast address is required. In these 321 cases multiple addresses are available in AD-HOC Block III. Where 322 there is a requirement for a very large number of addresses, the 323 assignment will be staged. The additional stages will only be made 324 after the complete use of the initial assignment(s). 326 A separate document describing the policy governing assignment of 327 addresses in the AD-HOC blocks I, II and III will be developed and 328 published. The format, location and content has not yet been decided 329 and so these will be documented in a future version of this document. 331 12. Annual Review 333 Given the dynamic nature of IPv4 multicast and its associated 334 infrastructure, and the previously undocumented IPv4 multicast 335 address assignment guidelines, the IANA should conduct an annual 336 review of currently assigned addresses. 338 12.1. Address Reclamation 340 During the review described above, addresses that were mis-assigned 341 should, where possible, be reclaimed or reassigned. 343 The IANA should also review assignments in the AD-HOC, "DIS Transient 344 Groups", and ST Multicast Groups [RFC1190] blocks and reclaim those 345 addresses that are not in use on the global Internet (i.e, those 346 applications which can use SSM, GLOP, or Administratively Scoped 347 addressing, or are not globally routed). 349 12.2. Positive renewal 351 It is occasionally appropriate to make temporary assignments that can 352 be renewed as necessary. In cases where this happens the registrant 353 needs to positively request an extension to the temporary assignment 354 or the addresses assigned. When the IANA has not received a request 355 to renew the registration of a temporary assignment within 30 days of 356 the expiry of the assignment it MUST be removed from the multicast 357 registry. 359 Addresses returned to the IANA when a temporary assignment ends MUST 360 NOT be assigned to anyone other than the last registrant for at least 361 one calendar year. 363 13. Use of IANA Reserved Addresses 365 Applications MUST NOT use addressing in the IANA reserved blocks. 367 14. IANA Considerations 369 IANA is requested to update its IPv4 multicast request and assignment 370 procedures to reflect this document. 372 15. Security Considerations 374 The assignment guidelines described in this document do not alter the 375 security properties of either the Any Source or Source Specific 376 multicast service models. 378 16. Acknowledgments 380 The authors would like to thank Joe St. Sauver, John Meylor, Randy 381 Bush, Thomas Narten, Marshall Eubanks, Zaid Albanna (co-author of 382 RFC3171), Kevin Almeroth (co-author of RFC3171) Pekka Savola and 383 Alfred Hoenes for their constructive feedback and comments. 385 17. References 387 17.1. Normative References 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, March 1997. 392 17.2. Informative References 394 [IANA] IANA, "IANA Matrix for Protocol Parameter Assignment/ 395 Registration Procedures", 396 . 398 [RFC1190] Casner, S., Lynn, C., Park, P., Schroder, K., and C. 399 Topolcic, "Experimental Internet Stream Protocol: Version 400 2 (ST-II)", RFC 1190, October 1990. 402 [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, 403 selection, and registration of an Autonomous System (AS)", 404 BCP 6, RFC 1930, March 1996. 406 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 407 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 409 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 411 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 412 RFC 2365, July 1998. 414 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 415 Names", BCP 32, RFC 2606, June 1999. 417 [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address 418 Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, 419 December 1999. 421 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 422 Values In the Internet Protocol and Related Headers", 423 BCP 37, RFC 2780, March 2000. 425 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 426 Understanding Concerning the Technical Work of the 427 Internet Assigned Numbers Authority", RFC 2860, June 2000. 429 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 430 Announcement Protocol", RFC 2974, October 2000. 432 [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, 433 June 2001. 435 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 436 "IANA Guidelines for IPv4 Multicast Address Assignments", 437 BCP 51, RFC 3171, August 2001. 439 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 440 BCP 53, RFC 3180, September 2001. 442 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 443 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 444 May 2008. 446 Authors' Addresses 448 Michelle Cotton 449 Internet Corporation for Assigned Names and Numbers 450 4676 Admiralty Way, Suite 330 451 Marina del Rey 90292 452 United States 454 Phone: +310-823-9358 455 Email: michelle.cotton@icann.org 456 URI: http://www.iana.org/ 458 Leo Vegoda 459 Internet Corporation for Assigned Names and Numbers 460 4676 Admiralty Way, Suite 330 461 Marina del Rey 90292 462 United States 464 Phone: +310-823-9358 465 Email: leo.vegoda@icann.org 466 URI: http://www.iana.org/ 468 David Meyer 470 Email: dmm@1-4-5.net