--- 1/draft-ietf-mboned-admin-ip-space-03.txt 2006-02-05 00:19:09.000000000 +0100 +++ 2/draft-ietf-mboned-admin-ip-space-04.txt 2006-02-05 00:19:09.000000000 +0100 @@ -17,22 +17,22 @@ material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``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 - 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 + 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 describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes. This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to or the author. 3. Acknowledgments @@ -171,21 +171,28 @@ boundary for scoped addresses in the range defined in its configuration. Network administrators may configure a scope region whenever constrained multicast scope is required. In addition, an administrator may configure overlapping scope regions (networks can be in multiple scope regions) where convenient, with the only 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 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 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 scoped boundary is defined. 9. Partitioning of the Administratively Scoped Multicast Space The following table outlines the partitioning of the IPv4 multicast space, and gives the mapping from IPv4 multicast prefixes to IPv6 @@ -205,51 +212,110 @@ A (unassigned) B (unassigned) C (unassigned) D (unassigned) E global scope 224.0.1.0-238.255.255.255 F reserved (unassigned) 239.0.0.0/10 (unassigned) 239.64.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 - memo, it is important to note that a boundary router as described - here should not be considered to provide any kind of firewall - functionality. + The high order /24 in every scoped region is reserved for relative + assignments. A relative assignment is an integer offset from highest + 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 + 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 Multicast", , presented at the 30th IETF, Toronto, Canada, 25 July 1994. [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", draft-ietf-idmr-dvmrp-v3-03.txt, September, 1996. [PIMDM] Deering, S, et. al., "Protocol Independent Multicast Version 2, Dense Mode Specification", draft-ietf-idmr-pim-dm-05.txt, April, 1997. [PIMSM] Estrin, D, et. al., "Protocol Independent Multicast 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, 1994. [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing 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 Advanced Network Technology Center University of Oregon 1225 Kincaid St. Eugene, OR 97403 phone: +1 541.346.1747 email: meyer@antc.uoregon.edu