draft-ietf-mboned-iana-ipv4-mcast-guidelines-02.txt   draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.txt 
Network Working Group Zaid Albanna Network Working Group Zaid Albanna
INTERNET DRAFT Juniper Networks INTERNET DRAFT Juniper Networks
Kevin Almeroth Kevin Almeroth
UCSB UCSB
David Meyer David Meyer
Cisco Systems Sprint
Michelle Schipper Michelle Schipper
IANA IANA
Category Best Current Practices Category Best Current Practices
April, 2001 June, 2001
IANA Guidelines for IPv4 Multicast Address Assignments IANA Guidelines for IPv4 Multicast Address Assignments
<draft-ietf-mboned-iana-ipv4-mcast-guidelines-02.txt> <draft-ietf-mboned-iana-ipv4-mcast-guidelines-03.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 3, line 39 skipping to change at page 3, line 39
below. below.
6. Local Network Control Block (224.0.0/24) 6. 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 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. Assignment Guidelines 6.1. Assignment Guidelines
Assignment of addresses in the Local Network Configuration Block Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the
SHOULD BE be accompanied by a specification ("Specification Local Network Control block follow an Expert Review, IESG Approval or
Required"). This specification will typically take the form of an Standards Action process. See [IANA] for the current set of
internet draft or RFC. assignments.
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. Assignment Guidelines 7.1. Assignment Guidelines
Assignment of addresses in the Internetwork Control block SHOULD BE Pursuant to section 4.4.2 of RFC 2780 [RFC2780], assignments from the
accompanied by a specification ("Specification Required"). This Internetwork Control block follow an Expert Review, IESG Approval or
specification will typically take the form of an internet draft or Standards Action process. See [IANA] for the current set of
RFC. assignments.
8. AD-HOC Block (224.0.2.0/24 - 224.0.255.0/24) 8. AD-HOC Block (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 block have traditionally been assigned for
those applications that don't fit in either the Local or Internetwork those applications that don't fit in either the Local or Internetwork
Control blocks. These addresses are globally routed and are typically Control blocks. These addresses are globally routed and are typically
used by applications that require small blocks of addressing (e.g., used by applications that require small blocks of addressing (e.g.,
less than a /24). less than a /24).
8.1. Assignment Guidelines 8.1. Assignment Guidelines
IANA SHOULD NOT assign addressing in the AD-HOC Block unless it is a In general, the IANA SHOULD NOT assign addressing in the AD-HOC
special circumstance accompanied by a specification ("Specification Block. However, the IANA may under special special circumstances,
Required"). This specification will typically take the form of an assign addressing from this block. Pursuant to section 4.4.2 of RFC
Internet-Draft or RFC. 2780 [RFC2780], assignments from the AD-HOC block follow an Expert
Review, IESG Approval or Standards Action process. See [IANA] for the
current set of assignments.
9. SDP/SAP Block (224.2/16) 9. 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]).
9.1. Assignment Guidelines 9.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
skipping to change at page 6, line 22 skipping to change at page 6, line 37
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.
13.1.1. Relative Offsets 13.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 RFC
2770 for details). Since there are only 256 such offsets, the IANA 2770 for details). Since there are only 256 such offsets, the IANA
should only assign a relative offset to a protocol that provides an should only assign a relative offset to a protocol that provides an
infra-structure supporting service. Examples of such services include infra-structure supporting service. Examples of such services include
the Session Announcement Protocol [RFC2974]. See [IANA] for the the Session Announcement Protocol [RFC2974]. Pursuant to section
current set of assignments. 4.4.2 of RFC 2780 [RFC2780], assignments of Relative Offsets follow
an Expert Review, IESG Approval or Standards Action process. 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 11 skipping to change at page 7, line 29
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
Appleals of this process are to be handled in accordance with Section Appeals of this process are to be handled in accordance with Section
6.5 of RFC 2026 [RFC2026]. 6.5 of RFC 2026 [RFC2026].
17. Security Considerations 17. Security Considerations
The assignment guidelines described in this document do not alter the The assignment guidelines described in this document do not alter the
security properties of either the Any Source or Source Specific security properties of either the Any Source or Source Specific
multicast service models. multicast service models.
18. Acknowledgments 18. Acknowledgments
The authors would like to thank Joe St. Sauver, John Meylor, and The authors would like to thank Joe St. Sauver, John Meylor, Randy
Randy Bush for their constructive feedback and comments. Bush, and Thomas Narten for their constructive feedback and comments.
19. Author's Address: 19. Author's Address:
Zaid Albanna Zaid Albanna
1149 N. Mathilda Ave 1149 N. Mathilda Ave
Sunnyvale, CA. 94089 Sunnyvale, CA. 94089
zaid@juniper.net zaid@juniper.net
Kevin Almeroth Kevin Almeroth
UC Santa Barbara UC Santa Barbara
Sata Barbara, CA. Santa Barbara, CA.
Email: almeroth@cs.ucsb.edu Email: almeroth@cs.ucsb.edu
David Meyer David Meyer
Cisco Systems, Inc. Sprint E|Solutions
170 Tasman Drive Email: dmm@sprint.net
San Jose, CA, 95134
Email: dmm@cisco.com
Michelle Schipper Michelle Schipper
IANA Administrator IANA Administrator
Internet Assigned Numbers Authority
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
iana@iana.org iana@iana.org
20. References 20. References
[IANA] http://www.iana.org/assignments/multicast-addresses [IANA] http://www.iana.org/assignments/multicast-addresses
[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.
 End of changes. 

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