draft-ietf-mboned-iana-ipv4-mcast-guidelines-00.txt   draft-ietf-mboned-iana-ipv4-mcast-guidelines-01.txt 
Network Working Group Zaid Albanna Network Working Group Zaid Albanna
INTERNET DRAFT Worldcom INTERNET DRAFT Juniper Networks
Kevin Almeroth Kevin Almeroth
UCSB UCSB
David Meyer David Meyer
Cisco Systems Cisco Systems
Michelle Schipper Michelle Schipper
IANA IANA
Category Best Current Practices Category Best Current Practices
March, 2001 April, 2001
IANA Guidelines for IPv4 Multicast Address Allocation IANA Guidelines for IPv4 Multicast Address Allocation
<draft-ietf-mboned-iana-ipv4-mcast-guidelines-00.txt> <draft-ietf-mboned-iana-ipv4-mcast-guidelines-01.txt>
1. Status of this Memo 1. Status of this Memo
This document specifies an Internet Best Current Practices for the This document specifies an Internet Best Current Practices for the
Internet Community, and requests discussion and suggestions for Internet Community, and requests discussion and suggestions for
improvements. Distribution of this memo is unlimited. improvements. Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
skipping to change at page 4, line 5 skipping to change at page 4, line 5
control traffic that is not forwarded off link. Examples of this type control traffic that is not forwarded off link. Examples of this type
of use include OSPFIGP All Routers (224.0.0.5) [RFC2328]. of use include OSPFIGP All Routers (224.0.0.5) [RFC2328].
6.1. Allocation Guidelines 6.1. Allocation Guidelines
Allocation of addresses in the Local Network Configuration Block Allocation of addresses in the Local Network Configuration Block
SHOULD BE be accompanied by a specification ("Specification SHOULD BE be accompanied by a specification ("Specification
Required"). This specification will typically take the form of an Required"). This specification will typically take the form of an
internet draft or RFC. internet draft or RFC.
Internet Draf-draft-ietf-mboned-iana-IPv4-mcast-guidelines-01.txt April, 2001
7. Internetwork Control Block (224.0.1/24) 7. 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 must be forwarded through the Internet. Examples include
224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdisover [RFC2730]). 224.0.1.1 (NTP [RFC2030]) and 224.0.1.68 (mdhcpdisover [RFC2730]).
7.1. Allocation Guidelines 7.1. Allocation Guidelines
Allocation of addresses in the Internetwork Control block SHOULD BE Allocation of addresses in the Internetwork Control block SHOULD BE
accompanied by a specification ("Specification Required"). This accompanied by a specification ("Specification Required"). This
skipping to change at page 5, line 21 skipping to change at page 5, line 21
10.1. Allocation Guidelines 10.1. Allocation Guidelines
Since addresses in the MALLOC block are chosen by elements of the Since addresses in the MALLOC block are chosen by elements of the
MALLOC architecture, no IANA allocation policy is required. Note that MALLOC architecture, no IANA allocation policy is required. Note that
while no additional IANA allocation is required, addresses in the while no additional IANA allocation is required, addresses in the
MALLOC block are explicitly for allocation by MALLOC servers and MUST MALLOC block are explicitly for allocation by MALLOC servers and MUST
NOT be used for other purposes. NOT be used for other purposes.
11. Source Specific Multicast Block (232/8) 11. Source Specific Multicast Block (232/8)
The Source Specific Multicast (SSM) block use is outlined in [SSM]. The Source Specific Multicast (SSM) is an extension of IP Multicast
In general, SSM is an extension of IP Multicast in which traffic is in which traffic is forwarded to receivers from only those multicast
forwarded to receivers from only those multicast sources for which sources for which the receivers have explicitly expressed interest,
the receivers have explicitly expressed interest, and is primarily and is primarily targeted at one-to-many (broadcast) applications.
targeted at one-to-many (broadcast) applications where large receiver
audiences require traffic from a small number of well known sources.
11.1. Allocation Guidelines 11.1. Allocation 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 allocation policy is required. Note, space local to the host, no IANA allocation policy is required. Note,
however, that while no additional IANA allocation is required, however, that while no additional IANA allocation 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.
12. GLOP Block (233/8) 12. GLOP Block (233/8)
skipping to change at page 6, line 25 skipping to change at page 6, line 17
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].
13.1. Allocation Guidelines 13.1. Allocation 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
allocation policy is required. allocation policy is required.
13.1.1. Relative Offsets 13.1.1. Relative Offsets
The relative offsets are used to ensure that a service can be located The relative offsets [RFC2365] are used to ensure that a service can
independent of the extent of the enclosing scope (see RFC 2770 for be located independent of the extent of the enclosing scope (see RFC
details). Since there are only 256 such offsets, the IANA should only 2770 for details). Since there are only 256 such offsets, the IANA
assign a relative offset to a protocol that provides an infra- should only assign a relative offset to a protocol that provides an
structure supporting service. See [IANA] for the current set of infra-structure supporting service. Examples of such services include
assignments. the Session Announcement Protocol [RFC2974]. See [IANA] for the
current set of assignments.
14. Annual Review 14. Annual Review
Given the dynamic nature of IPv4 multicast and its associated infra- Given the dynamic nature of IPv4 multicast and its associated infra-
structure, and the previously undocumented IPv4 multicast address structure, and the previously undocumented IPv4 multicast address
assignment guidelines, the IANA should conduct an annual review of assignment guidelines, the IANA should conduct an annual review of
currently assigned addresses. currently assigned addresses.
14.1. Address Reclamation 14.1. Address Reclamation
skipping to change at page 7, line 19 skipping to change at page 7, line 11
that are not in use on the global Internet (i.e, those applications that are not in use on the global Internet (i.e, those applications
which can use SSM, GLOP, or Administratively Scoped addressing, or which can use SSM, GLOP, or Administratively Scoped addressing, or
are not globally routed). are not globally routed).
15. Use of IANA Reserved Addresses 15. Use of IANA Reserved Addresses
Applications MUST NOT use addressing in the IANA reserved blocks. Applications MUST NOT use addressing in the IANA reserved blocks.
16. Appeals Process 16. Appeals Process
An applicant that is denied a multicast assignment may ask for Appleals of this process are to be handled in accordance with Section
additional consideration of its application. Such appeals SHOULD be 6.5 of RFC 2026 [RFC2026].
granted only in those cases in which (i). the applicant did not
provide a specification, or (ii). the applicant believes that the
IANA did not understand the technical basis on which the application
rests (and hence the need for assignment of globally scoped
addressing).
16.1. Requirements [RFC2026]
All appeals must include a detailed and specific description of the
facts of the dispute.
All appeals must be initiated within two months of the public
knowledge of the action or decision to be challenged.
At all stages of the appeals process, the individuals or bodies
responsible for making the decisions have the discretion to define
the specific procedures they will follow in the process of making
their decision.
In all cases a decision concerning the disposition of the dispute,
and the communication of that decision to the parties involved, must
be accomplished within a reasonable period of time.
16.2. Process
When an application is appealed, the application (and specification,
if one was provided) is to be reviewed by the IESG, indicating to the
IANA whether the application should be accepted. The IESG MAY
additionally employ Expert Review of the application.
16.2.1. Process Failure
If an applicant should disagree with an action taken by the IANA and
IESG in this process, that application should first try to clairfy
its position with the IANA. If the IANA is unable to satisfy the
applicant, the applicant may ask for its application (and
specification, if one was provided) to be reviewed by the IAB.
The IAB decision is final with respect to the question of whether an
assignment should be made.
17. Security Considerations 17. Security Considerations
Security issues are not discussed in this memo. The allocation guidelines described in this document do not alter the
security properties of either the Any Source or Source Specific
multicast service models.
18. Acknowledgments 18. Acknowledgments
The authors would like to thank Joe St. Sauver and John Meylor for The authors would like to thank Joe St. Sauver, John Meylor, and
their constructive feedback and comments. Randy Bush for their constructive feedback and comments.
19. Author's Address: 19. Author's Address:
Zaid Albanna Zaid Albanna
Worldcom 1149 N. Mathilda Ave
22001 Loudoun County Parkway Sunnyvale, CA. 94089
Ashburn, VA. 20147 zaid@juniper.net
Email: zaid@mci.net
Kevin Almeroth Kevin Almeroth
UC Santa Barbara UC Santa Barbara
Sata Barbara, CA. Sata Barbara, CA.
Email: almeroth@cs.ucsb.edu Email: almeroth@cs.ucsb.edu
David Meyer David Meyer
Cisco Systems, Inc. Cisco Systems, Inc.
170 Tasman Drive 170 Tasman Drive
San Jose, CA, 95134 San Jose, CA, 95134
Email: dmm@cisco.com Email: dmm@cisco.com
Michelle Schipper Michelle Schipper
IANA IANA Administrator
iana@iana.org iana@iana.org
20. References 20. References
[IANA] http://www.iana.org [IANA] http://www.iana.org
[RFC1190] C. Topolcic, "Experimental Internet Stream [RFC1190] C. Topolcic, "Experimental Internet Stream
Protocol, Version 2 (ST-II)", RFC 1190, October, Protocol, Version 2 (ST-II)", RFC 1190, October,
1990. 1990.
skipping to change at page 9, line 49 skipping to change at page 8, line 43
Dynamic Client Allocation Protocol (MADCAP), December Dynamic Client Allocation Protocol (MADCAP), December
1999. 1999.
[RFC2770] D. Meyer, and P. Lothberg, "GLOP Addressing in 233/8", [RFC2770] D. Meyer, and P. Lothberg, "GLOP Addressing in 233/8",
RFC 2770, February, 2000 RFC 2770, February, 2000
[RFC2780] S. Bradner and V. Paxson, "IANA Allocation Guidelines [RFC2780] S. Bradner and V. Paxson, "IANA Allocation Guidelines
For Values In the Internet Protocol and Related For Values In the Internet Protocol and Related
Headers", RFC2780, March, 2000 Headers", RFC2780, March, 2000
[RFC2908] D. Thaler, M. Handley, D.Estrin, "The Internet Multicast [RFC2908] D. Thaler, M. Handley, D.Estrin, "Theh Internet Multicast
Address Allocation Architecture", RFC 2908, September 2000. Address Allocation Architecture", RFC 2908, September 2000.
[RFC2974] M. Handley, C. Perkins, E. Whelan, "Session [RFC2974] M. Handley, C. Perkins, E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[SDR] http://www.aciri.org/sdr/ [SDR] http://www.aciri.org/sdr/
[SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast
for IP", draft-holbrook-ssm-arch-01.txt, Work in
progress.
21. Full Copyright Statement 21. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/