draft-ietf-mboned-rfc3171bis-02.txt   draft-ietf-mboned-rfc3171bis-03.txt 
INTERNET-DRAFT Z. Albanna Network Working Group M. Cotton
draft-ietf-mboned-rfc3171bis-02.txt K. Almeroth Internet-Draft ICANN
M. Cotton Intended status: BCP D. Meyer
D. Meyer Expires: December 26, 2008 June 24, 2008
Category Best Current Practice
IANA Guidelines for IPv4 Multicast Address Assignments IANA Guidelines for IPv4 Multicast Address Assignments
<draft-ietf-mboned-rfc3171bis-02.txt> draft-ietf-mboned-rfc3171bis-03
Status of this Document Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC2026. 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
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 document is a product of the ABC working group. Comments should This Internet-Draft will expire on December 26, 2008.
be addressed to the authors, or the mailing list at
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
The Internet Assigned Numbers Authority is charged with allocating This document obsoletes RFC 3171. It provides guidance for the
parameter values for fields in protocols which have been designed, Internet Assigned Numbers Authority (IANA) in assigning IPv4
created or are maintained by the Internet Engineering Task Force. multicast addresses.
This document provides guidelines for the assignment of the IPv4 IP
multicast address space.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Current Assignment Practice. . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 5 3. Definition of Current Assignment Practice . . . . . . . . . . 3
3.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . . 5 4. Local Network Control Block (224.0.0/24) . . . . . . . . . . . 4
4. Internetwork Control Block (224.0.1/24). . . . . . . . . . . . 5 4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 4
4.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . . 5 5. Internetwork Control Block (224.0.1/24) . . . . . . . . . . . 5
5. AD-HOC Block (224.0.2/24 - 224.0.255/24) . . . . . . . . . . . 5 5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5
5.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . . 6 6. AD-HOC Blocks (including 224.0.2.0/24 - 224.0.255.0/24) . . . 5
6. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 6 6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5
6.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . . 6 7. SDP/SAP Block (224.2/16) . . . . . . . . . . . . . . . . . . . 5
7. Source Specific Multicast Block (232/8). . . . . . . . . . . . 6 7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 5
7.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . . 6 8. Source Specific Multicast Block (232/8) . . . . . . . . . . . 6
8. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6
8.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . . 7 9. GLOP Block (233/8) . . . . . . . . . . . . . . . . . . . . . . 6
9. Administratively Scoped Address Block (239/8). . . . . . . . . 7 9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 6
9.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . . 7 9.2. Extended AD-HOC . . . . . . . . . . . . . . . . . . . . . 6
9.1.1. Relative Offsets . . . . . . . . . . . . . . . . . . . . 8 10. Administratively Scoped Address Block (239/8) . . . . . . . . 6
10. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Assignment Guidelines . . . . . . . . . . . . . . . . . . 7
10.1. Address Reclamation. . . . . . . . . . . . . . . . . . . . 8 11. Application Form . . . . . . . . . . . . . . . . . . . . . . . 7
11. Usable IPv4 Multicast Addresses . . . . . . . . . . . . . . . 8 11.1. Size of assignments of IPv4 Multicast Addresses . . . . . 7
11.1. IGMP-snooping switches . . . . . . . . . . . . . . . . . . 9 12. Annual Review . . . . . . . . . . . . . . . . . . . . . . . . 8
11.2. Unusable Inter-domain Groups . . . . . . . . . . . . . . . 9 12.1. Address Reclamation . . . . . . . . . . . . . . . . . . . 8
11.2.1. Administratively Scoped Addresses . . . . . . . . . . . 9 12.2. Positive renewal . . . . . . . . . . . . . . . . . . . . . 8
11.2.2. Special Use IPv4 Source Addresses . . . . . . . . . . . 10 13. Use of IANA Reserved Addresses . . . . . . . . . . . . . . . . 8
12. Use of IANA Reserved Addresses. . . . . . . . . . . . . . . . 10 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 15. Security Considerations . . . . . . . . . . . . . . . . . . . 8
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
15. Security Considerations . . . . . . . . . . . . . . . . . . . 11 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
16. Normative References. . . . . . . . . . . . . . . . . . . . . 12 17.1. Normative References . . . . . . . . . . . . . . . . . . . 9
17. Informative References. . . . . . . . . . . . . . . . . . . . 12 17.2. Informative References . . . . . . . . . . . . . . . . . . 9
18. Author's Addresses. . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
19. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 11
20. Intellectual Property . . . . . . . . . . . . . . . . . . . . 14
21. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 14
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
IPv4 multicast addresses. IPv4 multicast addresses.
The key words "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", This document is a revision of RFC 3171 [RFC3171], which it
obsoletes. It should retain RFC 3171's status as BCP 51. It also
obsoletes RFC 3138 [RFC3138]."
The terms "Specification Required", "Expert Review", "IESG Approval",
"IETF Consensus", and "Standards Action", are used in this memo to
refer to the processes described in [RFC2434]. The keywords MUST,
MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT,
SHOULD, SHOULD NOT are to be interpreted as defined in [RFC2119].
In general, due to the relatively small size of the IPv4 multicast
address space, further assignment of IPv4 multicast address space is
recommended only in limited circumstances. Specifically, the IANA
should only assign addresses in those cases where the dynamic
selection (SDP/SAP), GLOP, SSM or Administratively Scoped address
spaces cannot be used. The guidelines described below are reflected
in <http://www.iana.org/numbers.html>.
2. Terminology
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 RFC 2119 [RFC 2119]. document are to be interpreted as described in BCP 14, RFC 2119
[RFC2119].
2. Definition of Current Assignment Practice The word "allocation" is defined as a block of addresses managed by a
registry for the purpose of making assignments and allocations. The
word "assignment" is defined a block of addresses, or a single
address, registered to an end-user for use on a specific network, or
set of networks.
3. Definition of Current Assignment Practice
Unlike IPv4 unicast address assignment, where blocks of addresses are Unlike IPv4 unicast address assignment, where blocks of addresses are
delegated to regional registries, IPv4 multicast addresses are delegated to Regional Internet Registries (RIRs), IPv4 multicast
assigned directly by the IANA. Current assignments appear as follows addresses are assigned directly by the IANA. Current registration
[IANA]: groups appear as follows [IANA]:
224.0.0.0 - 224.0.0.255 (224.0.0/24) Local Network Control Block 224.0.0.0 - 224.0.0.255 224.0.0/24 Local Network Control Block
224.0.1.0 - 224.0.1.255 (224.0.1/24) Internetwork Control Block
224.0.2.0 - 224.0.255.0 AD-HOC Block 224.0.1.0 - 224.0.1.255 224.0.1/24 Internetwork Control Block
224.1.0.0 - 224.1.255.255 (224.1/16) RESERVED
224.2.0.0 - 224.2.255.255 (224.2/16) SDP/SAP Block 224.0.2.0 - 224.0.255.0 64769 AD-HOC Block (1)
224.3.0.0 - 231.255.255.255 RESERVED
232.0.0.0 - 232.255.255.255 (232/8) Source Specific Multicast Block 224.1.0.0 - 224.1.255.255 224.1/16 RESERVED
233.0.0.0 - 233.255.255.255 (233/8) GLOP Block
234.0.0.0 - 238.255.255.255 RESERVED 224.2.0.0 - 224.2.255.255 224.2/16 SDP/SAP Block
239.0.0.0 - 239.255.255.255 (239/8) Administratively Scoped Block
224.252.0.0 - 224.255.255.255 224.252/14 RESERVED
225.0.0.0 - 231.255.255.255 7 /8s RESERVED
232.0.0.0 - 232.255.255.255 232/8 Source Specific Multicast Block
233.0.0.0 - 233.251.255.255 16515072 GLOP Block
233.252.0.0 - 233.255.255.255 233.252/14 AD-HOC Block (2)
234.0.0.0 - 238.255.255.255 5 /8s RESERVED
239.0.0.0 - 239.255.255.255 239/8 Administratively Scoped Block
The IANA generally assigns addresses from the Local Network Control, The IANA generally assigns addresses from the Local Network Control,
Internetwork Control, and AD-HOC blocks. Assignment guidelines for Internetwork Control and AD-HOC blocks. Assignment guidelines for
each of these blocks, as well as for the Source Specific Multicast, each of these blocks, as well as for the Source Specific Multicast,
GLOP and Administratively Scoped Blocks, are described below. GLOP and Administratively Scoped Blocks, are described below.
3. Local Network Control Block (224.0.0/24) 4. Local Network Control Block (224.0.0/24)
Addresses in the Local Network Control block are used for protocol Addresses in the Local Network Control block are used for protocol
control traffic that is not forwarded off link. Examples of this type control traffic that is not forwarded off link. Examples of this
of use include OSPFIGP All Routers (224.0.0.5) [RFC2328]. type of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].
3.1. Assignment Guidelines 4.1. Assignment Guidelines
Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the Pursuant to section 4.4.2 of [RFC2780], assignments from the Local
Local Network Control block follow an Expert Review, IESG Approval or Network Control block follow an Expert Review, IESG Approval or
Standards Action process. See [IANA] for the current set of Standards Action process. See IANA [IANA] for the current set of
assignments. assignments.
4. Internetwork Control Block (224.0.1/24) 5. Internetwork Control Block (224.0.1/24)
Addresses in the Internetwork Control block are used for protocol Addresses in the Internetwork Control block are used for protocol
control that must be forwarded through the Internet. Examples include control that MAY be forwarded through the Internet. Examples include
224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover [RFC2730]). 224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdiscover [RFC2730]).
4.1. Assignment Guidelines 5.1. Assignment Guidelines
Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the Pursuant to section 4.4.2 of [RFC2780], assignments from the
Internetwork Control block follow an Expert Review, IESG Approval or Internetwork Control block follow an Expert Review, IESG Approval or
Standards Action process. See [IANA] for the current set of Standards Action process. See IANA [IANA] for the current set of
assignments. assignments.
5. AD-HOC Block (224.0.2/24 - 224.0.255/24) 6. AD-HOC Blocks (including 224.0.2.0/24 - 224.0.255.0/24)
Addresses in the AD-HOC block have traditionally been assigned for Addresses in the AD-HOC blocks were traditionally used for
those applications that don't fit in either the Local or Internetwork assignments for those applications that don't fit in either the Local
Control blocks. These addresses are globally routed and are typically or Internetwork Control blocks. These addresses are globally routed
used by applications that require small blocks of addressing (e.g., and are typically used by applications that require small blocks of
less than a /24). 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
made in the Extended block.
5.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 special circumstances, Block. However, the IANA MAY under special circumstances, assign
assign addressing from this block. Pursuant to section 4.4.2 of RFC addresses from this block. Pursuant to section 4.4.2 of [RFC2780],
2780 [RFC2780], assignments from the AD-HOC block follow an Expert assignments from the AD-HOC block follow an Expert Review, IESG
Review, IESG Approval or Standards Action process. See [IANA] for the Approval or Standards Action process. See IANA [IANA] for the
current set of assignments. current set of assignments.
6. 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]).
6.1. Assignment Guidelines 7.1. Assignment Guidelines
Since addresses in the SDP/SAP block are chosen randomly from the Since addresses in the SDP/SAP block are chosen randomly from the
range of addresses not already in use [RFC2974], no IANA assignment range of addresses not already in use [RFC2974], no IANA assignment
policy is required. Note that while no additional IANA assignment is policy is required. Note that while no additional IANA assignment is
required, addresses in the SDP/SAP block are explicitly for use by required, addresses in the SDP/SAP block are explicitly for use by
SDP/SAP and MUST NOT be used for other purposes. SDP/SAP and MUST NOT be used for other purposes.
7. Source Specific Multicast Block (232/8) 8. Source Specific Multicast Block (232/8)
The Source Specific Multicast (SSM) is an extension of IP Multicast The Source Specific Multicast (SSM) is an extension of IP Multicast
in which traffic is forwarded to receivers from only those multicast in which traffic is forwarded to receivers from only those multicast
sources for which the receivers have explicitly expressed interest, sources for which the receivers have explicitly expressed interest,
and is primarily targeted at one-to-many (broadcast) applications. and is primarily targeted at one-to-many (broadcast) applications.
Note that this block as initially assigned to the VMTP transient Note that this block as initially assigned to the VMTP transient
groups [IANA]. groups IANA [IANA].
7.1. Assignment Guidelines 8.1. Assignment Guidelines
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. Note, space local to the host, no IANA assignment policy is required.
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.
8. 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 by mapping a domain's autonomous addresses. The assignment is made, for a domain with 16 bit
system number into the middle two octets of 233.X.Y.0/24. The mapping Autonomous System Number (ASN), by mapping a domain's autonomous the
and assignment is defined in [RFC2770]. number, expressed in octets as X.Y, system number into the middle two
octets of of the GLOP block, yielding an assignment of 233.X.Y.0/24.
The mapping and assignment is defined in [RFC3180]. Domains with 32
bit ASN should apply for space in the Extended AD-HOC block.
8.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. In addition, RFC 3138 no IANA assignment policy is required.
[RFC3138] delegates assignment of the GLOP sub-block mapped by the
RFC 1930 [RFC1930] private AS space (233.252.0.0 - 233.255.255.255)
to the Internet Routing Registries. Note that while no additional
IANA assignment is required, addresses in the GLOP block are
assigned for use as defined in RFC 2770 and MUST NOT be used for
other purposes.
9. Administratively Scoped Address Block (239/8) 9.2. Extended AD-HOC
[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
RIRs. This space was known as eGLOP. The RIRs did not develop
policies or the mechanisms for the assignment of the eGLOP space and
it is important to make this space available for use by network
operators. It is therefore appropriate to obsolete RFC 3138 and
classify this address range as available for AD-HOC assignment as per
the guidelines in section 6.
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].
9.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.
9.1.1. Relative Offsets 10.1.1. Relative Offsets
The relative offsets [RFC2365] are used to ensure that a service can The relative offsets [RFC2365] are used to ensure that a service can
be located independent of the extent of the enclosing scope (see RFC be located independent of the extent of the enclosing scope (see
2770 for details). Since there are only 256 such offsets, the IANA [RFC3180] for details). Since there are only 256 such offsets, the
should only assign a relative offset to a protocol that provides an IANA should only assign a relative offset to a protocol that provides
infrastructure supporting service. Examples of such services include an infrastructure supporting service. Examples of such services
the Session Announcement Protocol [RFC2974]. Pursuant to section include the Session Announcement Protocol [RFC2974]. Pursuant to
4.4.2 of RFC 2780 [RFC2780], assignments of Relative Offsets follow section 4.4.2 of [RFC2780], assignments of Relative Offsets follow an
an Expert Review, IESG Approval or Standards Action process. See Expert Review, IESG Approval or Standards Action process. See IANA
[IANA] for the current set of assignments. [IANA] for the current set of assignments.
10. Annual Review 11. Application Form
Given the dynamic nature of IPv4 multicast and its associated Requests for multicast address assignments can be submitted through
infrastructure, and the previously undocumented IPv4 multicast the application form on the IANA web site at:
address assignment guidelines, the IANA should conduct an annual
review of currently assigned addresses.
10.1. Address Reclamation <http://www.iana.org/cgi-bin/multicast.pl>
During the review described above, addresses that were mis-assigned It is important to submit sufficient detail to allow the IESG
should, where possible, be reclaimed or reassigned. designated expert to review the application. If the details given in
the request are not clear, or further information is needed, the IESG
designated expert may request additional information before assigning
an address.
The IANA should also review assignments reclaim those addresses that 11.1. Size of assignments of IPv4 Multicast Addresses
are not in use on the global Internet (i.e, those applications which
can use SSM, GLOP, or Administratively Scoped addressing, or are not
globally routed).
11. Usable IPv4 Multicast Addresses Occasionally, more than one multicast address is required. In these
cases multiple addresses are available in the Extended AD-HOC block.
Where a very large number of addresses is required, the assignment
will be staged, with additional stages only being made after the
complete use of the initial assignment(s).
Multicast datagrams that match the criteria in this section SHOULD A separate document describing the policy governing assignment of
NOT be used, even on local, unrouted subnetworks. addresses in the AD-HOC and Extended AD-HOC blocks will be developed
and published. The format, location and content has not yet been
decided and so these will be documented in a future version of this
document.
11.1. IGMP-snooping switches 12. Annual Review
RFC 1112 [RFC1112] describes the mapping of IPv4 Multicast Group Given the dynamic nature of IPv4 multicast and its associated infra-
addresses to Ethernet MAC addresses, as follows: structure, and the previously undocumented IPv4 multicast address
assignment guidelines, the IANA should conduct an annual review of
currently assigned addresses.
An IP host group address is mapped to an Ethernet multicast 12.1. Address Reclamation
address by placing the low-order 23-bits of the IP address into
the low-order 23 bits of the Ethernet multicast address
01-00-5E-00-00-00 (hex). Because there are 28 significant bits
in an IP host group address, more than one host group address
may map to the same Ethernet multicast address.
Now, note that multicast group addresses in the 224.0.0.0/24 range During the review described above, addresses that were mis-assigned
are used for local subnetwork control (see section 3 above). Under should, where possible, be reclaimed or reassigned.
the RFC 1112 mapping, this maps to the Ethernet multicast address
range 01-00-5E-00-00-XX, where XX is 00 through FF. Ethernet frames
within this range are always processed in the control plane of many
popular network devices, such as IGMP-snooping switches.
Because of the many-to-one mapping of IPv4 Multicast Group Addresses The IANA should also review assignments in the AD-HOC, DIS Transient
to Ethernet MAC addresses, it is possible to overwhelm the control Groups, and ST Multicast Groups [RFC1190] blocks and reclaim those
plane of network devices by sending to group addresses that map into addresses that are not in use on the global Internet (i.e, those
the 01-00-5E-00-00-XX (hex) range. applications which can use SSM, GLOP, or Administratively Scoped
addressing, or are not globally routed).
IGMP-snooping network devices must also flood these frames to all 12.2. Positive renewal
outgoing ports, so the damage may extend to end systems and routers.
11.2. Unusable Inter-domain Groups It is occasionally appropriate to make temporary assignments that can
be renewed as necessary. In cases where this happens the registrant
needs to positively request an extension to the temporary assignment
or the addresses assigned. When the IANA has not received a request
to renew the registration of a temporary assignment within 30 days of
the expiry of the assignment it MUST be removed from the multicast
registry.
Multicast datagrams that match the criteria in this section SHOULD Addresses returned to the IANA when a temporary assignment ends MUST
NOT be routed between administrative domains. NOT be assigned for at least one calendar year.
11.2.1. Administratively Scoped Addresses 13. Use of IANA Reserved Addresses
RFC 2365 [RFC2365] defines 239.0.0.0/8 for use within an Applications MUST NOT use addressing in the IANA reserved blocks.
administrative domain. As such, datagrams with group addresses that
match 239.0.0.0/8 SHOULD NOT be passed between administrative
domains.
11.2.2. Special Use IPv4 Source Addresses 14. IANA Considerations
RFC 1918 [RFC1918] defines certain ranges of IPv4 unicast addresses This document is all about IANA Considerations.
that can be used within an administrative domain. Multicast
datagrams are no exception to the rule that datagrams addressed
within these ranges SHOULD NOT be passed between administrative
domains. Examples include 127.0.0.0/8, which is widely used for
internal host addressing, and is generally not valid on datagrams
passed between hosts. 0.0.0.0/8 and 169.254.0.0/16 are also valid
only in the context of local links. Such source addresses are not
valid for datagrams passed between networks[RFC330]. Finally
192.0.2.0/24 is reserved for documentation and example code.
[RFC3330].
12. Use of IANA Reserved Addresses 15. Security Considerations
Applications MUST NOT use addressing in the IANA reserved blocks. The assignment guidelines described in this document do not alter the
security properties of either the Any Source or Source Specific
multicast service models.
13. IANA Considerations 16. Acknowledgments
This document provides guidelines for the IANA to use in assigning The authors would like to thank Joe St. Sauver, John Meylor, Randy
IPv4 multicast addresses. It does not create any new namespaces for Bush, Thomas Narten, Marshall Eubanks, Zaid Albanna (co-author of
the IANA to manage [RFC2434]. RFC3171), Kevin Almeroth (co-author of RFC3171) and Leo Vegoda for
their constructive feedback and comments.
14. Acknowledgments 17. References
The authors would like to thank Scott Bradner, Randy Bush, John 17.1. Normative References
Meylor, Thomas Narten, Joe St. Sauver, and Beau Williamson for their
constructive feedback and comments. Bill Nickless contributed the
text in section 11 describing IPv4 multicast unusable group and
source addresses.
15. Security Considerations [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
The assignment guidelines described in this document do not alter the 17.2. Informative References
security properties of either the Any Source or Source Specific
multicast service models.
16. Normative References [IANA] IANA, "IANA Matrix for Protocol Parameter Assignment/
Registration Procedures",
<http://www.iana.org/numbers.html>.
[RFC1112] Deering, S., "Host extensions for IP [RFC1190] Casner, S., Lynn, C., Park, P., Schroder, K., and C.
multicasting", RFC 1112, August, 1989. Topolcic, "Experimental Internet Stream Protocol: Version
2 (ST-II)", RFC 1190, October 1990.
[RFC1918] Rekhter, Y. et. al., "Address Allocation for [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation,
Private Internets", RFC 1918, February, 1996. selection, and registration of an Autonomous System (AS)",
BCP 6, RFC 1930, March 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
Indicate Requirement Levels", RFC 2119, March, for IPv4, IPv6 and OSI", RFC 2030, October 1996.
1997.
[RFC2365] Meyer, D., "Administratively Scoped IP [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
Multicast", RFC 2365, July 1998.
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
September, 2002. RFC 2365, July 1998.
17. Informative References [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[IANA] http://www.iana.org/assignments/multicast-addresses [RFC2730] Hanna, S., Patel, B., and M. Shah, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,
December 1999.
[RFC2026] Bradner, S., "The Internet Standards Process -- [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Revision 3", RFC 2026/BCP 9, October, 1996. Values In the Internet Protocol and Related Headers",
BCP 37, RFC 2780, March 2000.
[RFC2028] Hovey, R. and S. Bradner, "The Organizations [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Involved in the IETF Standards Process", RFC Announcement Protocol", RFC 2974, October 2000.
2028/BCP 11, October, 1996.
[RFC2434] Narten, T., and H. Alvestrand, "Guidelines for [RFC3138] Meyer, D., "Extended Assignments in 233/8", RFC 3138,
Writing an IANA Considerations Section in RFCs", June 2001.
RFC 2434/BCP 26, October 1998.
18. Author's Addresses [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper,
"IANA Guidelines for IPv4 Multicast Address Assignments",
BCP 51, RFC 3171, August 2001.
Zaid Albanna [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8",
Email: zaid@juniper.net BCP 53, RFC 3180, September 2001.
Kevin Almeroth Authors' Addresses
Email: almeroth@cs.ucsb.edu
David Meyer Michelle Cotton
Email: dmm@1-4-5.net Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey 90292
United States
Michelle S. Cotton Phone: +310-823-9358
Email: iana@iana.org Email: michelle.cotton@icann.org
URI: http://www.iana.org/
19. Full Copyright Statement David Meyer
Copyright (C) The Internet Society (2004). This document is subject Email: dmm@1-4-5.net
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and translations of it may be copied and furnished to Full Copyright Statement
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright (C) The IETF Trust (2008).
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document is subject to the rights, licenses and restrictions
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING contained in BCP 78, and except as set forth therein, the authors
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
20. Intellectual Property This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
21. Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 91 change blocks. 
253 lines changed or deleted 285 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/