INTERNET-DRAFTMBONED Working Group David Meyerdraft-ietf-mboned-admin-ip-space-02.txtInternet Draft University of OregonCategory:BestCategory Best Current PracticeApril 1997Administratively Scoped IP Multicast 1. Status of this Memo This documentspecifies an Internet Best Current Practice for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Internet Drafts This documentis an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 ``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 to239.255.255.255 .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 theOperational Requirements areaOperations and Management Area of the Internet Engineering Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author. 3. 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. Steve Casner, Mark Handley and Dave Thaler have also provided insightful comments on earlier versions of thisdraft.document. 4. Introduction Most current IP multicast implementations achieve some level ofscop- ingscoping 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 a packet is not forwarded across the interface unless its remaining TTL is 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 itstradi- tionaltraditional 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 tounder- stand.understand. A more serious architectural problemwithconcerns the interaction of TTL scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The particular problem isthat,that in many common cases,itTTL scoping can prevent pruning from being effective. Consider the case in which a packeteitherhas either had its TTL expire ordoes not meetfailed a TTL threshold. Thepoint (e.g., tunnel, interface) atrouter which discards the packetfails the TTL checkwill not be capable of pruning any upstream sources, andhencethus will sink alltraffic, independent of whethermulticast traffic (whether or not there are downstreamgroup members.receivers). Note thatwithout somehow associating prune state and TTL, this problem will persist. For example,while it might seem possible to senda pruneprunes upstream from the pointwhere theat which a packet is discarded, this strategycould preventcan result in legitimate trafficfrombeingforwarded (subsequentdiscarded, since subsequent packets could take a different path andwind uparrive at the same point with a largerTTL). However, if a prune had been sent, the packet may not be forwarded on interfaces that it should have been.TTL. On the other hand,by usingadministratively scoped IPmulticast, one can achieve locally scopedmulticastwith simple,can provide clearsemantics.and simple semantics for scoped IP multicast. The key properties ofany implementation ofadministratively 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. Allocation5. Definition of the Administratively Scoped IPv4 MulticastAddressSpaceIANA should allocateThe administratively scoped IPv4 multicast address space is defined to be the range 239.0.0.0 to239.255.255.255 to be the "Administratively Scoped IPv4 Multicast" address space.239.255.255.255. 6. Discussion In order to support administratively scoped IP multicast, a router should support the configuration of per-interface scoped IP multicast boundaries. Such a router, called a boundary router, does not forward packets matchingitsan interface's boundary definition in either directionacross its border(the bi-directional check prevents problems withmulti-accessmulti- access networks). In addition, a boundary router always prunes the boundary for dense-modegroups, orgroups [PIMDM], and doesn't accept joins for sparse-mode groups [PIMSM] in the administratively scoped range. 7. The 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 Addressing Architecture described in RFC1884. The following table outlines the partitioning of1884 [RFC1884]. This document defines two important scopes: the IPv4multicast space,Local Scope andgives the mapping to IPv6 SCOP values [RFC1884]. IPv6 SCOP RFC 1884 DescriptionIPv4Prefix ================================================================== 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/10Organization Local Scope. These scopes are described below. 7.1. The IPv4 Local Scope -- 239.255.0.0/16 239.255.0.0/16 is defined to be the IPv4 Local Scope.While how localThe Local Scope is the minimal enclosing scope, and hence is not further divisible. Although the exact extent of a Local Scope is site dependent, locally scoped regions must obey certain topological constraints. In particular, a Local Scope must not span any other scope boundary.That is, itFurther, a Local Scope must be completely containedwithin,within or equalto,to any larger scope. In the event thattwoscope regions overlap in area, the areathat overlapsof overlap must be init'sits own local scope. Thisalso meansimplies that any scope boundary is also a boundary for the Local Scope. The more general topological requirements foradmin- istrativelyadministratively scoped regions are discussed below. 7.1.1. Expansion of the IPv4 Local Scope 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 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. 7.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, and is the space from which an organization should allocate sub- ranges when defining scopes for private use. 7.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 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 sufficient. This is to allow for the possibility that future revisions of this document may define additional scopes on a scale larger than organizations. 7.3. Other IPv4 Scopes of Interest The other two scope classes of interest, statically assigned link- local scope and global scope already existto some extentinIP ver- sion 4IPv4 multicast space.In particular, theThe statically assignedlink- locallink-local scope is 224.0.0.0/24. The existing static global scope allocations arecurrentlysomewhat 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 Seeftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses[RFC1700] for current multicast addressassignments.assignments (this list can also be found, possibly in a more current form, on ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses). 8. Topological Requirements for Administrative Boundaries An administratively scoped IP multicast region is defined to be a topological region in which there are one or more boundary routers with common boundary definitions. Such a router is said to be aboun- daryboundary for scoped addresses in the range defined in its configuration. Network administrators may configure a scope region wheneverlocalconstrained multicast scope is required. In addition, an administrator maycon- figureconfigure 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), andcon- vexconvex (i.e., no path between any two points in the region can cross a 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 groupsin the 239.255/16 rangecovered by 239.255.0.0/16 must not be forwarded across any linkwith any scoped boundary defined. That is, setting a boundary on a linkforany prefix must also set a boundary on that link for the local scope prefix. Example: DVMRP DVMRP [DVMRP] implementations could be extended to supportwhich a scoped boundaryattribute inis defined. 9. Partitioning of theinterface configuration [ASMA].Administratively Scoped Multicast Space Theboundary attri- bute that includes a prefix and mask, and hasfollowing table outlines thesemantics that packets matchingpartitioning of theprefixIPv4 multicast space, andmask do not not pass the boundary. As mentioned above, the implementation would also prunegives theboundary.mapping from IPv4 multicast prefixes to IPv6 SCOP values: 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) 5 site-local scope 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 10. Security Considerations 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 firewallfunc- tionality.functionality. 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 Protocol",draft-ietf-idmr-dvmrp-v3-03,draft-ietf-idmr-dvmrp-v3-03.txt, September, 1996.[RFC1884] R. Hinden.[PIMDM] Deering, S, et. al.,"IP"Protocol Independent Multicast Version6 Addressing Architecture", RFC1884, December 1995.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,1996.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 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