draft-ietf-mboned-admin-ip-space-05.txt   rfc2365.txt 
MBONED Working Group David Meyer
Internet Draft University of Oregon
Category Best Current Practice
draft-ietf-mboned-admin-ip-space-05.txt June 1998 Network Working Group D. Meyer
Request for Comments: 2365 University of Oregon
BCP: 23 July 1998
Category: Best Current Practice
Administratively Scoped IP Multicast Administratively Scoped IP Multicast
1. Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document specifies an Internet Best Current Practices for the
documents of the Internet Engineering Task Force (IETF), its areas, Internet Community, and requests discussion and suggestions for
and its working groups. Note that other groups may also distribute improvements. Distribution of this memo is unlimited.
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Copyright Notice
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the Copyright (C) The Internet Society (1998). All Rights Reserved.
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
2. Abstract 1. Abstract
This document defines the "administratively scoped IPv4 multicast This document defines the "administratively scoped IPv4 multicast
space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it
describes a simple set of semantics for the implementation of describes a simple set of semantics for the implementation of
Administratively Scoped IP Multicast. Finally, it provides a mapping Administratively Scoped IP Multicast. Finally, it provides a mapping
between the IPv6 multicast address classes [RFC1884] and IPv4 between the IPv6 multicast address classes [RFC1884] and IPv4
multicast address classes. multicast address classes.
This memo is a product of the MBONE Deployment Working Group (MBONED) This memo is a product of the MBONE Deployment Working Group (MBONED)
in the Operations and Management Area of the Internet Engineering in the Operations and Management Area of the Internet Engineering
Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author. Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
3. Acknowledgments 2. Acknowledgments
Much of this memo is taken from "Administratively Scoped IP Much of this memo is taken from "Administratively Scoped IP
Multicast", Van Jacobson and Steve Deering, presented at the 30th Multicast", Van Jacobson and Steve Deering, presented at the 30th
IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and
Dave Thaler have also provided insightful comments on earlier Dave Thaler have also provided insightful comments on earlier
versions of this document. versions of this document.
4. Introduction 3. Introduction
Most current IP multicast implementations achieve some level of Most current IP multicast implementations achieve some level of
scoping by using the TTL field in the IP header. Typical MBONE scoping by using the TTL field in the IP header. Typical MBONE
(Multicast Backbone) usage has been to engineer TTL thresholds that (Multicast Backbone) usage has been to engineer TTL thresholds that
confine traffic to some administratively defined topological region. confine traffic to some administratively defined topological region.
The basic forwarding rule for interfaces with configured TTL The basic forwarding rule for interfaces with configured TTL
thresholds is that a packet is not forwarded across the interface thresholds is that a packet is not forwarded across the interface
unless its remaining TTL is greater than the threshold. unless its remaining TTL is greater than the threshold.
TTL scoping has been used to control the distribution of multicast TTL scoping has been used to control the distribution of multicast
skipping to change at page 3, line 5 skipping to change at page 2, line 35
arrive at the same point with a larger TTL. arrive at the same point with a larger TTL.
On the other hand, administratively scoped IP multicast can provide On the other hand, administratively scoped IP multicast can provide
clear and simple semantics for scoped IP multicast. The key clear and simple semantics for scoped IP multicast. The key
properties of administratively scoped IP multicast are that (i). properties of administratively scoped IP multicast are that (i).
packets addressed to administratively scoped multicast addresses do packets addressed to administratively scoped multicast addresses do
not cross configured administrative boundaries, and (ii). not cross configured administrative boundaries, and (ii).
administratively scoped multicast addresses are locally assigned, and administratively scoped multicast addresses are locally assigned, and
hence are not required to be unique across administrative boundaries. hence are not required to be unique across administrative boundaries.
5. Definition of the Administratively Scoped IPv4 Multicast Space 4. Definition of the Administratively Scoped IPv4 Multicast Space
The administratively scoped IPv4 multicast address space is defined The administratively scoped IPv4 multicast address space is defined
to be the range 239.0.0.0 to 239.255.255.255. to be the range 239.0.0.0 to 239.255.255.255.
6. Discussion 5. Discussion
In order to support administratively scoped IP multicast, a router In order to support administratively scoped IP multicast, a router
should support the configuration of per-interface scoped IP multicast should support the configuration of per-interface scoped IP multicast
boundaries. Such a router, called a boundary router, does not forward boundaries. Such a router, called a boundary router, does not forward
packets matching an interface's boundary definition in either packets matching an interface's boundary definition in either
direction (the bi-directional check prevents problems with multi- direction (the bi-directional check prevents problems with multi-
access networks). In addition, a boundary router always prunes the access networks). In addition, a boundary router always prunes the
boundary for dense-mode groups [PIMDM], and doesn't accept joins for boundary for dense-mode groups [PIMDM], and doesn't accept joins for
sparse-mode groups [PIMSM] in the administratively scoped range. sparse-mode groups [PIMSM] in the administratively scoped range.
7. The Structure of the Administratively Scoped Multicast Space 6. The Structure of the Administratively Scoped Multicast Space
The structure of the IP version 4 administratively scoped multicast The structure of the IP version 4 administratively scoped multicast
space is loosely based on the IP Version 6 Addressing Architecture space is loosely based on the IP Version 6 Addressing Architecture
described in RFC 1884 [RFC1884]. This document defines two important described in RFC 1884 [RFC1884]. This document defines two important
scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These
scopes are described below. scopes are described below.
7.1. The IPv4 Local Scope -- 239.255.0.0/16 6.1. The IPv4 Local Scope -- 239.255.0.0/16
239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local 239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local
Scope is the minimal enclosing scope, and hence is not further Scope is the minimal enclosing scope, and hence is not further
divisible. Although the exact extent of a Local Scope is site divisible. Although the exact extent of a Local Scope is site
dependent, locally scoped regions must obey certain topological dependent, locally scoped regions must obey certain topological
constraints. In particular, a Local Scope must not span any other constraints. In particular, a Local Scope must not span any other
scope boundary. Further, a Local Scope must be completely contained scope boundary. Further, a Local Scope must be completely contained
within or equal to any larger scope. In the event that scope regions within or equal to any larger scope. In the event that scope regions
overlap in area, the area of overlap must be in its own local scope. overlap in area, the area of overlap must be in its own local scope.
This implies that any scope boundary is also a boundary for the Local This implies that any scope boundary is also a boundary for the Local
Scope. The more general topological requirements for administratively Scope. The more general topological requirements for administratively
scoped regions are discussed below. scoped regions are discussed below.
7.1.1. Expansion of the IPv4 Local Scope 6.1.1. Expansion of the IPv4 Local Scope
The IPv4 Local Scope space grows "downward". As such, the IPv4 Local The IPv4 Local Scope space grows "downward". As such, the IPv4 Local
Scope may grow downward from 239.255.0.0/16 into the reserved ranges Scope may grow downward from 239.255.0.0/16 into the reserved ranges
239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not 239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not
be utilized until the 239.255.0.0/16 space is no longer sufficient. be utilized until the 239.255.0.0/16 space is no longer sufficient.
7.2. The IPv4 Organization Local Scope -- 239.192.0.0/14 6.2. The IPv4 Organization Local Scope -- 239.192.0.0/14
239.192.0.0/14 is defined to be the IPv4 Organization Local Scope, 239.192.0.0/14 is defined to be the IPv4 Organization Local Scope,
and is the space from which an organization should allocate sub- and is the space from which an organization should allocate sub-
ranges when defining scopes for private use. ranges when defining scopes for private use.
7.2.1. Expansion of the IPv4 Organization Local Scope 6.2.1. Expansion of the IPv4 Organization Local Scope
The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are
unassigned and available for expansion of this space. These ranges unassigned and available for expansion of this space. These ranges
should be left unassigned until the 239.192.0.0/14 space is no longer should be left unassigned until the 239.192.0.0/14 space is no longer
sufficient. This is to allow for the possibility that future sufficient. This is to allow for the possibility that future
revisions of this document may define additional scopes on a scale revisions of this document may define additional scopes on a scale
larger than organizations. larger than organizations.
7.3. Other IPv4 Scopes of Interest 6.3. Other IPv4 Scopes of Interest
The other two scope classes of interest, statically assigned link- The other two scope classes of interest, statically assigned link-
local scope and global scope already exist in IPv4 multicast space. local scope and global scope already exist in IPv4 multicast space.
The statically assigned link-local scope is 224.0.0.0/24. The The statically assigned link-local scope is 224.0.0.0/24. The
existing static global scope allocations are somewhat more granular, existing static global scope allocations are somewhat more granular,
and include and include
224.1.0.0-224.1.255.255 ST Multicast Groups 224.1.0.0-224.1.255.255 ST Multicast Groups
224.2.0.0-224.2.127.253 Multimedia Conference Calls 224.2.0.0-224.2.127.253 Multimedia Conference Calls
224.2.127.254 SAPv1 Announcements 224.2.127.254 SAPv1 Announcements
224.2.127.255 SAPv0 Announcements (deprecated) 224.2.127.255 SAPv0 Announcements (deprecated)
224.2.128.0-224.2.255.255 SAP Dynamic Assignments 224.2.128.0-224.2.255.255 SAP Dynamic Assignments
224.252.0.0-224.255.255.255 DIS transient groups 224.252.0.0-224.255.255.255 DIS transient groups
232.0.0.0-232.255.255.255 VMTP transient groups 232.0.0.0-232.255.255.255 VMTP transient groups
See [RFC1700] for current multicast address assignments (this list See [RFC1700] for current multicast address assignments (this list
can also be found, possibly in a more current form, on can also be found, possibly in a more current form, on
ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses). ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
8. Topological Requirements for Administrative Boundaries 7. Topological Requirements for Administrative Boundaries
An administratively scoped IP multicast region is defined to be a An administratively scoped IP multicast region is defined to be a
topological region in which there are one or more boundary routers topological region in which there are one or more boundary routers
with common boundary definitions. Such a router is said to be a with common boundary definitions. Such a router is said to be a
boundary for scoped addresses in the range defined in its boundary for scoped addresses in the range defined in its
configuration. configuration.
Network administrators may configure a scope region whenever Network administrators may configure a scope region whenever
constrained multicast scope is required. In addition, an constrained multicast scope is required. In addition, an
administrator may configure overlapping scope regions (networks can administrator may configure overlapping scope regions (networks can
skipping to change at page 5, line 34 skipping to change at page 5, line 5
prevents the problem that would arise when a path between two points prevents the problem that would arise when a path between two points
in a convex region crosses the boundary of an intersecting region. in a convex region crosses the boundary of an intersecting region.
For this reason, it is recommended that administrative scopes that For this reason, it is recommended that administrative scopes that
intersect topologically should not intersect in address range. intersect topologically should not intersect in address range.
Finally, note that any scope boundary is a boundary for the Local Finally, note that any scope boundary is a boundary for the Local
Scope. This implies that packets sent to groups covered by Scope. This implies that packets sent to groups covered by
239.255.0.0/16 must not be forwarded across any link for which a 239.255.0.0/16 must not be forwarded across any link for which a
scoped boundary is defined. scoped boundary is defined.
9. Partitioning of the Administratively Scoped Multicast Space 8. Partitioning of the Administratively Scoped Multicast Space
The following table outlines the partitioning of the IPv4 multicast The following table outlines the partitioning of the IPv4 multicast
space, and gives the mapping from IPv4 multicast prefixes to IPv6 space, and gives the mapping from IPv4 multicast prefixes to IPv6
SCOP values: SCOP values:
IPv6 SCOP RFC 1884 Description IPv4 Prefix IPv6 SCOP RFC 1884 Description IPv4 Prefix
================================================================== ===============================================================
0 reserved 0 reserved
1 node-local scope 1 node-local scope
2 link-local scope 224.0.0.0/24 2 link-local scope 224.0.0.0/24
3 (unassigned) 239.255.0.0/16 3 (unassigned) 239.255.0.0/16
4 (unassigned) 4 (unassigned)
5 site-local scope 5 site-local scope
6 (unassigned) 6 (unassigned)
7 (unassigned) 7 (unassigned)
8 organization-local scope 239.192.0.0/14 8 organization-local scope 239.192.0.0/14
A (unassigned) A (unassigned)
B (unassigned) B (unassigned)
C (unassigned) C (unassigned)
D (unassigned) D (unassigned)
E global scope 224.0.1.0-238.255.255.255 E global scope 224.0.1.0-238.255.255.255
F reserved F reserved
(unassigned) 239.0.0.0/10 (unassigned) 239.0.0.0/10
(unassigned) 239.64.0.0/10 (unassigned) 239.64.0.0/10
(unassigned) 239.128.0.0/10 (unassigned) 239.128.0.0/10
10. Structure and Use of a Scoped Region 9. Structure and Use of a Scoped Region
The high order /24 in every scoped region is reserved for relative The high order /24 in every scoped region is reserved for relative
assignments. A relative assignment is an integer offset from highest assignments. A relative assignment is an integer offset from highest
address in the scope and represents a 32-bit address (for IPv4). For address in the scope and represents a 32-bit address (for IPv4). For
example, in the Local Scope defined above, 239.255.255.0/24 is example, in the Local Scope defined above, 239.255.255.0/24 is
reserved for relative allocations. The de-facto relative assignment reserved for relative allocations. The de-facto relative assignment
"0", (i.e., 239.255.255.255 in the Local Scope) currently exists for "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for
SAP [SAP]. The next relative assignment, "1", corresponds to the SAP [SAP]. The next relative assignment, "1", corresponds to the
address 239.255.255.254 in the Local Scope. The rest of a scoped address 239.255.255.254 in the Local Scope. The rest of a scoped
region below the reserved /24 is available for dynamic assignment region below the reserved /24 is available for dynamic assignment
(presumably by an address allocation protocol). (presumably by an address allocation protocol).
In is important to note that a scope discovery protocol [MZAP] will In is important to note that a scope discovery protocol [MZAP] will
have to be developed to make practical use of scopes other than the have to be developed to make practical use of scopes other than the
Local Scope. In addition, since any use of any administratively Local Scope. In addition, since any use of any administratively
scoped region, including the Local Scope, requires dynamically scoped region, including the Local Scope, requires dynamically
assigned addressing, an Address Allocation Protocol (AAP) will need assigned addressing, an Address Allocation Protocol (AAP) will need
to be developed to make administrative scoping generally useful. to be developed to make administrative scoping generally useful.
10.1. Relative Assignment Guidelines 9.1. Relative Assignment Guidelines
Requests for relative assignments should be directed to the IANA. In Requests for relative assignments should be directed to the IANA. The
general, relative addresses will be used only for bootstrapping to IANA will be advised by an area expert when making relative address
assignments. The area expert will be appointed by the relevant Area
Director.
In general, relative addresses will be used only for bootstrapping to
dynamic address assignments from within the scope. As such, relative dynamic address assignments from within the scope. As such, relative
assignments should only be made to those services that cannot use a assignments should only be made to those services that cannot use a
dynamic address assignment protocol to find the address used by that dynamic address assignment protocol to find the address used by that
service within the desired scope, such as a dynamic address service within the desired scope, such as a dynamic address
assignment service itself. assignment service itself.
11. Security Considerations 10. Security Considerations
It is recommended that organizations using the administratively It is recommended that organizations using the administratively
scoped IP Multicast addresses not rely on them to prevent sensitive scoped IP Multicast addresses not rely on them to prevent sensitive
data from being transmitted outside the organization. Should a data from being transmitted outside the organization. Should a
multicast router on an administrative boundary be mis-configured, multicast router on an administrative boundary be mis-configured,
have a bug in the administrative scoping code, or have other problems have a bug in the administrative scoping code, or have other problems
that would cause that router to forward an administratively scoped IP that would cause that router to forward an administratively scoped IP
multicast packet outside of the proper scope, the organizations data multicast packet outside of the proper scope, the organizations data
would leave its intended transmission region. would leave its intended transmission region.
skipping to change at page 7, line 36 skipping to change at page 7, line 5
Within the context of an administratively scoped IP multicast group, Within the context of an administratively scoped IP multicast group,
the use of manual key distribution might well be feasible. While the use of manual key distribution might well be feasible. While
dynamic key management for IP Security is a research area at the time dynamic key management for IP Security is a research area at the time
this note is written, it is expected that the IETF will be extending this note is written, it is expected that the IETF will be extending
the ISAKMP key management protocol to support scalable multicast key the ISAKMP key management protocol to support scalable multicast key
distribution in the future. distribution in the future.
It is important to note that the "boundary router" described in this It is important to note that the "boundary router" described in this
note is not necessarily providing any kind of firewall capability. note is not necessarily providing any kind of firewall capability.
12. References 11. References
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP
Multicast", , presented at the 30th IETF, Toronto,
Canada, 25 July 1994.
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing [ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP
Protocol", draft-ietf-idmr-dvmrp-v3-05.txt, Multicast", presented at the 30th IETF, Toronto, Canada, 25
October, 1997. July 1994.
[MZAP] M. Handley, "Multicast-Scope Zone Announcement [DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol",
Protocol (MZAP)", draft-ietf-mboned-mzap-00.txt, Work in Progress.
December, 1997.
[PIMDM] Deering, S, et. al., "Protocol Independent Multicast [MZAP] Handley, M., "Multicast-Scope Zone Announcement Protocol
Version 2, Dense Mode Specification", (MZAP)", Work in Progress.
draft-ietf-idmr-pim-dm-05.txt, May, 1997.
[PIMSM] Estrin, D, et. al., "Protocol Independent Multicast [PIMDM] Deering, S, et. al., "Protocol Independent Multicast
Sparse Mode (PIM-SM): Protocol Specification", Version 2, Dense Mode Specification", Work in Progress.
draft-ietf-idmr-pim-sm-specv2-00.txt,
September,1997. [PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
Wei, "Protocol Independent Multicast Sparse Mode (PIM-SM):
Protocol Specification", RFC 2362, June 1998.
[RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October, [RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1994. 1700, October 1994.
[RFC1884] R. Hinden. et. al., "IP Version 6 Addressing [RFC1884] Hinden. R., and S. Deering, "IP Version 6 Addressing
Architecture", RFC1884, December 1995. Architecture", RFC1884, December 1995.
[SAP] Handley, Mark, "SAP: Session Announcement Protocol", [SAP] Handley, M., "SAP: Session Announcement Protocol", Work in
draft-ietf-mmusic-sap-00.txt, November, 1996. Progress.
13. Author's Address 12. Author's Address
David Meyer David Meyer
Cisco Systems Cisco Systems
San Jose, CA San Jose, CA
email: dmm@cisco.com
EMail: dmm@cisco.com
13. Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
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
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
 End of changes. 37 change blocks. 
88 lines changed or deleted 81 lines changed or added

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