draft-ietf-mboned-admin-ip-space-03.txt   draft-ietf-mboned-admin-ip-space-04.txt 
skipping to change at page 1, line 28 skipping to change at page 1, line 28
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
2. Abstract 2. 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 3. Acknowledgments
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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
be in multiple scope regions) where convenient, with the only be in multiple scope regions) where convenient, with the only
limitations being that a scope region must be connected (there must limitations being that a scope region must be connected (there must
be a path between any two nodes within a scope region that doesn't be a path between any two nodes within a scope region that doesn't
leave that region), and convex (i.e., no path between any two points leave that region), and convex (i.e., no path between any two points
in the region can cross a region boundary). in the region can cross a region boundary). However, it is important
to note that if administratively scoped areas intersect
topologically, then the outer scope must consist of its address space
minus the address spaces of any intersecting scopes. This requirement
prevents the problem that would arise when a path between two points
in a convex region crosses the boundary of an intersecting region.
For this reason, it is recommended that administrative scopes that
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 9. 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
skipping to change at page 6, line 8 skipping to change at page 6, line 15
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. Security Considerations 10. Structure and Use of a Scoped Region
While security considerations are not explicitly discussed in this The high order /24 in every scoped region is reserved for relative
memo, it is important to note that a boundary router as described assignments. A relative assignment is an integer offset from highest
here should not be considered to provide any kind of firewall address in the scope and represents a 32-bit address (for IPv4). For
functionality. example, in the Local Scope defined above, 239.255.255.0/24 is
reserved for relative allocations. The de-facto relative assignment
"0", (i.e., 239.255.255.255 in the Local Scope) currently exists for
SAP [SAP]. The next relative assignment, "1", corresponds to the
address 239.255.255.254 in the Local Scope. The rest of a scoped
region below the reserved /24 is available for dynamic assignment
(presumably by an address allocation protocol).
11. References In is important to note that a scope discovery protocol will have to
be developed to make practical use of scopes other that the Local
Scope. In addition, since any use of any administratively scoped
region, including the Local Scope, requires dynamically assigned
addressing, an Address Allocation Protocol (AAP) will need to be
developed to make administrative scoping generally useful.
10.1. Relative Assignment Guidelines
Requests for relative assignments should be directed to the IANA. In
general, relative addresses will be used only for bootstrapping to
dynamic address assignments from within the scope. As such, relative
assignments should only be made to those services that cannot use a
dynamic address assignment protocol to find the address used by that
service within the desired scope, such as a dynamic address
assignment service itself.
11. Security Considerations
It is recommended that organizations using the administratively
scoped IP Multicast addresses not rely on them to prevent sensitive
data from being transmitted outside the organization. Should a
multicast router on an administrative boundary be mis-configured,
have a bug in the administrative scoping code, or have other problems
that would cause that router to forward an administratively scoped IP
multicast packet outside of the proper scope, the organizations data
would leave its intended transmission region.
Organizations using administratively scoped IP Multicasting to
transmit sensitive data should use some confidentiality mechanism
(e.g. encryption) to protect that data. In the case of many existing
video-conferencing applications (e.g. vat), encryption is available
as an application feature and merely needs to be enabled (and
appropriate cryptographic keys securely distributed). For many other
applications, the use of the IP Encapsulating Security Payload (ESP)
[RFC-1825, RFC-1827] can provide IP-layer confidentiality though
encryption.
Within the context of an administratively scoped IP multicast group,
the use of manual key distribution might well be feasible. While
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
the ISAKMP key management protocol [draft-ietf-ipsec-isakmp-*.txt,
draft-ietf-ipsec-ipsec-doi-*.txt] to support scalable multicast key
distribution in the future.
It is important to note that the "boundary router" described in this
note is not necessarily providing any kind of firewall capability.
12. References
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP [ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP
Multicast", , presented at the 30th IETF, Toronto, Multicast", , presented at the 30th IETF, Toronto,
Canada, 25 July 1994. Canada, 25 July 1994.
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing [DVMRP] T. Pusateri, "Distance Vector Multicast Routing
Protocol", draft-ietf-idmr-dvmrp-v3-03.txt, Protocol", draft-ietf-idmr-dvmrp-v3-03.txt,
September, 1996. September, 1996.
[PIMDM] Deering, S, et. al., "Protocol Independent Multicast [PIMDM] Deering, S, et. al., "Protocol Independent Multicast
Version 2, Dense Mode Specification", Version 2, Dense Mode Specification",
draft-ietf-idmr-pim-dm-05.txt, April, 1997. draft-ietf-idmr-pim-dm-05.txt, April, 1997.
[PIMSM] Estrin, D, et. al., "Protocol Independent Multicast [PIMSM] Estrin, D, et. al., "Protocol Independent Multicast
Sparse Mode (PIM-SM): Protocol Specification", Sparse Mode (PIM-SM): Protocol Specification",
draft-ietf-idmr-PIM-SM-spec-10.ps, March, 1997. draft-ietf-idmr-pim-sm-specv2-00.txt, September
9,1997.
[RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October, [RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October,
1994. 1994.
[RFC1884] R. Hinden. et. al., "IP Version 6 Addressing [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing
Architecture", RFC1884, December 1995. Architecture", RFC1884, December 1995.
12. Author's Address [SAP] Handley, Mark, "SAP: Session Announcement Protocol",
draft-ietf-mmusic-sap-00.txt, November, 1996.
13. Author's Address
David Meyer David Meyer
Advanced Network Technology Center Advanced Network Technology Center
University of Oregon University of Oregon
1225 Kincaid St. 1225 Kincaid St.
Eugene, OR 97403 Eugene, OR 97403
phone: +1 541.346.1747 phone: +1 541.346.1747
email: meyer@antc.uoregon.edu email: meyer@antc.uoregon.edu
 End of changes. 

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