draft-ietf-mboned-rfc3171bis-03.txt   draft-ietf-mboned-rfc3171bis-04.txt 
Network Working Group M. Cotton Network Working Group M. Cotton
Internet-Draft ICANN Internet-Draft ICANN
Intended status: BCP D. Meyer Intended status: BCP D. Meyer
Expires: December 26, 2008 June 24, 2008 Expires: May 7, 2009 November 3, 2008
IANA Guidelines for IPv4 Multicast Address Assignments IANA Guidelines for IPv4 Multicast Address Assignments
draft-ietf-mboned-rfc3171bis-03 draft-ietf-mboned-rfc3171bis-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 26, 2008. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
This document obsoletes RFC 3171. It provides guidance for the This document obsoletes RFC 3171. It provides guidance for the
Internet Assigned Numbers Authority (IANA) in assigning IPv4 Internet Assigned Numbers Authority (IANA) in assigning IPv4
multicast addresses. multicast addresses.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Current Assignment Practice . . . . . . . . . . 3 3. Definition of Current Assignment Practice . . . . . . . . . . 4
4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4 4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4
4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 4 4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5
5. Internetwork Control Block (224.0.1/24) . . . . . . . . . . . 5 5. Internetwork Control Block (224.0.1/24) . . . . . . . . . . . 5
5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5
6. AD-HOC Blocks (including 224.0.2.0/24 - 224.0.255.0/24) . . . 5 6. AD-HOC Blocks (including 224.0.2.0/24 - 224.0.255.0/24) . . . 5
6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5
7. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 5 7. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 5
7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5 7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6
8. Source Specific Multicast Block (232/8) . . . . . . . . . . . 6 8. Source Specific Multicast Block (232/8) . . . . . . . . . . . 6
8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6
9. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 6 9. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6 9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6
9.2. Extended AD-HOC . . . . . . . . . . . . . . . . . . . . . 6 9.2. Extended AD-HOC . . . . . . . . . . . . . . . . . . . . . 6
10. Administratively Scoped Address Block (239/8) . . . . . . . . 6 10. Administratively Scoped Address Block (239/8) . . . . . . . . 7
10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7 10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7
11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7 11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7
11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 7 11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 8
12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8 12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8 12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8
12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8 12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8
13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 8 13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 9
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
15. Security Considerations . . . . . . . . . . . . . . . . . . . 8 15. Security Considerations . . . . . . . . . . . . . . . . . . . 9
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
17.1. Normative References . . . . . . . . . . . . . . . . . . . 9 17.1. Normative References . . . . . . . . . . . . . . . . . . . 9
17.2. Informative References . . . . . . . . . . . . . . . . . . 9 17.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Introduction 1. Introduction
The Internet Assigned Numbers Authority (IANA) (www.iana.org) is The Internet Assigned Numbers Authority (IANA) (www.iana.org) is
charged with allocating parameter values for fields in protocols charged with allocating parameter values for fields in protocols
which have been designed, created or are maintained by the Internet which have been designed, created or are maintained by the Internet
Engineering Task Force (IETF). RFC 2780 [RFC2780] provides the IANA Engineering Task Force (IETF). RFC 2780 [RFC2780] provides the IANA
guidance in the assignment of parameters for fields in newly guidance in the assignment of parameters for fields in newly
developed protocols. This memo expands on section 4.4.2 of RFC 2780 developed protocols. This memo expands on section 4.4.2 of RFC 2780
and attempts to codify existing IANA practice used in the assignment and attempts to codify existing IANA practice used in the assignment
skipping to change at page 3, line 32 skipping to change at page 3, line 32
refer to the processes described in [RFC2434]. The keywords MUST, refer to the processes described in [RFC2434]. The keywords MUST,
MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT are to be interpreted as defined in [RFC2119]. SHOULD, SHOULD NOT are to be interpreted as defined in [RFC2119].
In general, due to the relatively small size of the IPv4 multicast In general, due to the relatively small size of the IPv4 multicast
address space, further assignment of IPv4 multicast address space is address space, further assignment of IPv4 multicast address space is
recommended only in limited circumstances. Specifically, the IANA recommended only in limited circumstances. Specifically, the IANA
should only assign addresses in those cases where the dynamic should only assign addresses in those cases where the dynamic
selection (SDP/SAP), GLOP, SSM or Administratively Scoped address selection (SDP/SAP), GLOP, SSM or Administratively Scoped address
spaces cannot be used. The guidelines described below are reflected spaces cannot be used. The guidelines described below are reflected
in <http://www.iana.org/numbers.html>. in <http://www.iana.org/numbers.html>. Network operators should also
be aware of the availability of IPv6 multicast addresses and consider
using them where feasible.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119]. [RFC2119].
The word "allocation" is defined as a block of addresses managed by a The word "allocation" is defined as a block of addresses managed by a
registry for the purpose of making assignments and allocations. The registry for the purpose of making assignments and allocations. The
skipping to change at page 5, line 31 skipping to change at page 5, line 38
assignments for those applications that don't fit in either the Local assignments for those applications that don't fit in either the Local
or Internetwork Control blocks. These addresses are globally routed or Internetwork Control blocks. These addresses are globally routed
and are typically used by applications that require small blocks of and are typically used by applications that require small blocks of
addressing (e.g., less than a /24 ). Future assignments of blocks of addressing (e.g., less than a /24 ). Future assignments of blocks of
addresses that do not fit in the Local or Internetwork block will be addresses that do not fit in the Local or Internetwork block will be
made in the Extended block. made in the Extended block.
6.1. Assignment Guidelines 6.1. Assignment Guidelines
In general, the IANA SHOULD NOT assign addressing in the AD-HOC In general, the IANA SHOULD NOT assign addressing in the AD-HOC
Block. However, the IANA MAY under special circumstances, assign Blocks. However, the IANA MAY under special circumstances, assign
addresses from this block. Pursuant to section 4.4.2 of [RFC2780], addresses from these blocks. Pursuant to section 4.4.2 of [RFC2780],
assignments from the AD-HOC block follow an Expert Review, IESG assignments from the AD-HOC blocks follow an Expert Review, IESG
Approval or Standards Action process. See IANA [IANA] for the Approval or Standards Action process. See IANA [IANA] for the
current set of assignments. current set of assignments.
7. SDP/SAP Block (224.2/16) 7. SDP/SAP Block (224.2/16)
Addresses in the SDP/SAP block are used by applications that receive Addresses in the SDP/SAP block are used by applications that receive
addresses through the Session Announcement Protocol [RFC2974] for use addresses through the Session Announcement Protocol [RFC2974] for use
via applications like the session directory tool (such as SDR [SDR]). via applications like the session directory tool (such as SDR [SDR]).
7.1. Assignment Guidelines 7.1. Assignment Guidelines
skipping to change at page 6, line 26 skipping to change at page 6, line 34
Because the SSM model essentially makes the entire multicast address Because the SSM model essentially makes the entire multicast address
space local to the host, no IANA assignment policy is required. space local to the host, no IANA assignment policy is required.
Note, however, that while no additional IANA assignment is required, Note, however, that while no additional IANA assignment is required,
addresses in the SSM block are explicitly for use by SSM and MUST NOT addresses in the SSM block are explicitly for use by SSM and MUST NOT
be used for other purposes. be used for other purposes.
9. GLOP Block (233/8) 9. GLOP Block (233/8)
Addresses in the GLOP block are globally scoped statically assigned Addresses in the GLOP block are globally scoped statically assigned
addresses. The assignment is made, for a domain with 16 bit addresses. The assignment is made, for a domain with 16 bit
Autonomous System Number (ASN), by mapping a domain's autonomous the Autonomous System Number (ASN), by mapping a domain's autonomous
number, expressed in octets as X.Y, system number into the middle two system number, expressed in octets as X.Y, into the middle two octets
octets of of the GLOP block, yielding an assignment of 233.X.Y.0/24. of of the GLOP block, yielding an assignment of 233.X.Y.0/24. The
The mapping and assignment is defined in [RFC3180]. Domains with 32 mapping and assignment is defined in [RFC3180]. Domains with 32 bit
bit ASN should apply for space in the Extended AD-HOC block. ASN should apply for space in the Extended AD-HOC block, or consider
using IPv6 multicast addresses.
9.1. Assignment Guidelines 9.1. Assignment Guidelines
Because addresses in the GLOP block are algorithmically pre-assigned, Because addresses in the GLOP block are algorithmically pre-assigned,
no IANA assignment policy is required. no IANA assignment policy is required.
9.2. Extended AD-HOC 9.2. Extended AD-HOC
[RFC3138] delegated assignment of the GLOP sub-block mapped by the [RFC3138] delegated assignment of the GLOP sub-block mapped by the
[RFC1930] private AS space (233.252.0.0 - 233.255.255.255) to the [RFC1930] private AS space (233.252.0.0 - 233.255.255.255) to the
RIRs. This space was known as eGLOP. The RIRs did not develop RIRs. This space was known as eGLOP. RFC 3138 should not have asked
policies or the mechanisms for the assignment of the eGLOP space and the RIRs to develop policies for the EGLOP space because [RFC2860]
it is important to make this space available for use by network reserves that to the IETF. It is important to make this space
operators. It is therefore appropriate to obsolete RFC 3138 and available for use by network operators and it is therefore
classify this address range as available for AD-HOC assignment as per appropriate to obsolete RFC 3138 and classify this address range as
the guidelines in section 6. available for AD-HOC assignment as per the guidelines in section 6.
The first /24 in this range, 233.252.0.0/24, is assigned as "MCAST-
TEST-NET" for use in documentation and example code. It SHOULD be
used in conjunction with the [RFC2606] domain names example.com or
example.net in vendor and protocol documentation. Addresses within
this block MUST NOT appear on the public Internet.
10. Administratively Scoped Address Block (239/8) 10. Administratively Scoped Address Block (239/8)
Addresses in the Administratively Scoped Address block are for local Addresses in the Administratively Scoped Address block are for local
use within a domain and are described in [RFC2365]. use within a domain and are described in [RFC2365].
10.1. Assignment Guidelines 10.1. Assignment Guidelines
Since addresses in this block are local to a domain, no IANA Since addresses in this block are local to a domain, no IANA
assignment policy is required. assignment policy is required.
skipping to change at page 9, line 45 skipping to change at page 10, line 14
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, July 1998. RFC 2365, July 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999.
[RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
December 1999. December 1999.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000. BCP 37, RFC 2780, March 2000.
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, June 2000.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138, [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138,
June 2001. June 2001.
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments", "IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001. BCP 51, RFC 3171, August 2001.
 End of changes. 16 change blocks. 
27 lines changed or deleted 43 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/