--- 1/draft-ietf-mboned-admin-ip-space-01.txt 2006-02-05 00:19:06.000000000 +0100 +++ 2/draft-ietf-mboned-admin-ip-space-02.txt 2006-02-05 00:19:06.000000000 +0100 @@ -1,14 +1,14 @@ INTERNET-DRAFT David Meyer -draft-ietf-mboned-admin-ip-space-01.txt University of Oregon -Category:Best Current Practice December 1996 +draft-ietf-mboned-admin-ip-space-02.txt University of Oregon +Category:Best Current Practice April 1997 Administratively Scoped IP Multicast Status of this Memo This document specifies an Internet Best Current Practice for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Internet Drafts @@ -24,98 +24,147 @@ 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). Abstract - This document defines the "administratively scoped IP 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 describes a simple set of semantics for the implementation of - Administratively Scoped IP Multicast. + 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 Operational Requirements area of the Internet Engineering Task Force. Submit comments to or the author. Acknowledgments Much of this memo is taken from "Administratively Scoped IP Multicast", Van Jacobson and Steve Deering, presented at the 30th - IETF, Toronto, Canada, 25 July 1994. Mark Handley and Dave Thaler - also made insightful comments on the orignal draft. + IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and + Dave Thaler also provided insightful comments on earlier versions of + this draft. Introduction Most current IP multicast implementations achieve some level of scop- ing by using the TTL field in the IP header. Typical MBONE (Multicast Backbone) usage has been to engineer TTL thresholds that confine traffic to some administratively defined topological region. The basic forwarding rule for interfaces with configured TTL thresholds - is that for a packet is not forwarded across the interface unless its + is that a packet is not forwarded across the interface unless its remaining TTL greater than the threshold. TTL scoping has been used to control the distribution of multicast traffic with the objective of easing stress on scarce resources (e.g., bandwidth), or to achieve some kind of improved privacy or scaling properties. In addition, the TTL is also used in its tradi- tional role to limit datagram lifetime. Given these often conflicting roles, TTL scoping has proven difficult to implement reliably, and the resulting schemes have often been complex and difficult to under- stand. + A more serious architectural problem with TTL scoping is that, in + many cases, it can prevent pruning from being effective. Consider the + case in which a packet either has its TTL expire or does not meet a + TTL threshold. The point (e.g., tunnel, interface) at which the + packet fails the TTL check will not be capable of pruning upstream + and hence will sink all traffic, independent of whether there are + downstream group members. Note that without somehow associating prune + state and TTL, this problem will persist. For example, while it might + seem possible to send a prune upstream from the point where the + packet is discarded, this strategy could prevent legitimate traffic + from being forwarded (subsequent packets could take a different path + and wind up at the same point with a larger TTL). However, if a prune + had been sent, the packet may not be forwarded on interfaces that it + should have been. + On the other hand, by using administratively scoped IP multicast, one can achieve locally scoped multicast with simple, clear semantics. + The key properties of any implementation of administratively scoped IP multicast are that (i). packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries, and (ii). administratively scoped multicast addresses are locally assigned, and hence are not required to be unique across administrative boundaries. These properties are sufficient to imple- ment administrative scoping. -Allocation of the Administratively Scoped IP Multicast Address Space +Allocation of the Administratively Scoped IPv4 Multicast Address Space IANA should allocate the range 239.0.0.0 to 239.255.255.255 to be - the "Administratively Scoped IP Multicast" address space. + the "Administratively Scoped IPv4 Multicast" address space. Discussion In order to support administratively scoped IP multicast, a router should support the configuration of scoped IP multicast boundaries. Such a router, called a boundary router, does not forward packets matching its boundary definition in either direction across its - border (the bi-directional check prevents problems with multicaccess + border (the bi-directional check prevents problems with multi-access networks). In addition, a boundary router always prunes the boundary for dense-mode groups, or doesn't accept joins for sparse-mode groups [PIMSM] in the administratively scoped range. -Structure of the IPv4 Administratively Scoped Multicast Space +Structure of the Administratively Scoped Multicast Space The structure of the IP version 4 administratively scoped multicast - space is loosely based on the IP Version 6 Multicast Addresses - [RFC1884] assignments, and is partitioned into the following scope - classes: + space is based on the IP Version 6 Addressing Architecture described + in RFC 1884. The following table outlines the partitioning of the + IPv4 multicast space, and gives the mapping to IPv6 SCOP values + [RFC1884]. - unassigned 239.0.0.0/10 - unassigned 239.64.0.0/10 - organization-local scope 239.128.0.0/10 - site-local scope 239.192.0.0/10 + IPv6 SCOP RFC 1884 Description IPv4 Prefix + ================================================================== + 0 reserved + 1 node-local scope + 2 link-local scope 224.0.0.0/24 + 3 (unassigned) 239.255.0.0/16 + 4 (unassigned) 239.254.0.0/16 + 5 site-local scope 239.253.0.0/16 + 6 (unassigned) + 7 (unassigned) + 8 organization-local scope 239.192.0.0/14 + 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 - The other two scope classes of interest, link-local scope and global - scope, already exist to some extent in IP version 4 multicast space. - In particular, the link-local scope is 224.0.0.0/24. The existing - global scope allocations are currently somewhat more granular, and - include +The IPv4 Local Scope -- 239.255.0.0/16 + + 239.255.0.0/16 is the IPv4 Local Scope. While how local is the Local + Scope is site dependent, locally scoped regions must obey certain + topological constraints. In particular, a Local Scope must not span + any other boundary. That is, it must be completely contained within, + or equal to, any larger scope. In the event that two scope regions + overlap in area, the area that overlaps must be in it's own local + scope. This also means that any scope boundary is also a boundary for + the Local Scope. The more general topological requirements for admin- + istratively scoped regions are discussed below. + +Other IPv4 Scopes of Interest + The other two scope classes of interest, statically assigned link- + local scope and global scope already exist to some extent in IP ver- + sion 4 multicast space. In particular, the statically assigned link- + local scope is 224.0.0.0/24. The existing global scope allocations + are currently somewhat more granular, and include 224.1.0.0-224.1.255.255 ST Multicast Groups 224.2.0.0-224.2.127.253 Multimedia Conference Calls 224.2.127.254 SAPv1 Announcements 224.2.127.255 SAPv0 Announcements (deprecated) 224.2.128.0-224.2.255.255 SAP Dynamic Assignments 224.252.0.0-224.255.255.255 DIS transient groups 232.0.0.0-232.255.255.255 VMTP transient groups See ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses @@ -128,21 +177,29 @@ with common boundary definitions. Such a router is said to be a boun- dary for scoped addresses in the range defined in its configuration. Network administrators may configure a scope region whenever local multicast scope is required. In addition, an administrator may con- figure 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 con- vex (i.e., no path between any two points in the region can cross a - region boundary). + region boundary). Finally, as mentioned above, an important con- + straint on the configuration of local scopes is that the local scope + must not span any other boundary. + + Finally, note that any scope boundary is a boundary for the Local + Scope. This implies that packets sent to groups in the 239.255/16 + range must not be forwarded across any link with any scoped boundary + defined. That is, setting a boundary on a link for any prefix must + also set a boundary on that link for the local scope prefix. Example: DVMRP DVMRP [DVMRP] implementations could be extended to support a boundary attribute in the interface configuration [ASMA]. The boundary attri- bute that includes a prefix and mask, and has the semantics that packets matching the prefix and mask do not not pass the boundary. As mentioned above, the implementation would also prune the boundary. Security Considerations @@ -160,22 +217,23 @@ [DVMRP] T. Pusateri, "Distance Vector Multicast Routing Protocol", draft-ietf-idmr-dvmrp-v3-03, September, 1996. [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing Architecture", RFC1884, December 1995. [PIMSM] Estrin, D, et. al., "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", - draft-ietf-idmr-PIM-SM-spec-09.ps, October, 1996. + draft-ietf-idmr-PIM-SM-spec-10.ps, March, 1996. 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