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