idnits 2.17.1 draft-ietf-mboned-admin-ip-space-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([DVMRP], [RFC1884], [ASMA], [PIMSM]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 20 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 34 has weird spacing: '..." to be the r...' == Line 99 has weird spacing: '...ate the range...' == Line 108 has weird spacing: '...ms with multi...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1997) is 9872 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ASMA' == Outdated reference: A later version (-11) exists of draft-ietf-idmr-dvmrp-v3-03 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'DVMRP') ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) -- No information found for draft-ietf-idmr-PIM-SM-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIMSM' Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT David Meyer 2 draft-ietf-mboned-admin-ip-space-02.txt University of Oregon 3 Category:Best Current Practice April 1997 5 Administratively Scoped IP Multicast 7 Status of this Memo 9 This document specifies an Internet Best Current Practice for the 10 Internet Community, and requests discussion and suggestions for 11 improvements. Distribution of this memo is unlimited. 13 Internet Drafts 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This document defines the "administratively scoped IPv4 multicast 34 space" to be the range 239.0.0.0 to 239.255.255.255 . In addition, 35 it describes a simple set of semantics for the implementation of 36 Administratively Scoped IP Multicast. Finally, it provides a mapping 37 between the IPv6 multicast address classes [RFC1884] and IPv4 38 multicast address classes. 40 This memo is a product of the MBONE Deployment Working Group (MBONED) 41 in the Operational Requirements area of the Internet Engineering Task 42 Force. Submit comments to or the author. 44 Acknowledgments 46 Much of this memo is taken from "Administratively Scoped IP 47 Multicast", Van Jacobson and Steve Deering, presented at the 30th 48 IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and 49 Dave Thaler also provided insightful comments on earlier versions of 50 this draft. 52 Introduction 54 Most current IP multicast implementations achieve some level of scop- 55 ing by using the TTL field in the IP header. Typical MBONE (Multicast 56 Backbone) usage has been to engineer TTL thresholds that confine 57 traffic to some administratively defined topological region. The 58 basic forwarding rule for interfaces with configured TTL thresholds 59 is that a packet is not forwarded across the interface unless its 60 remaining TTL greater than the threshold. 62 TTL scoping has been used to control the distribution of multicast 63 traffic with the objective of easing stress on scarce resources 64 (e.g., bandwidth), or to achieve some kind of improved privacy or 65 scaling properties. In addition, the TTL is also used in its tradi- 66 tional role to limit datagram lifetime. Given these often conflicting 67 roles, TTL scoping has proven difficult to implement reliably, and 68 the resulting schemes have often been complex and difficult to under- 69 stand. 71 A more serious architectural problem with TTL scoping is that, in 72 many cases, it can prevent pruning from being effective. Consider the 73 case in which a packet either has its TTL expire or does not meet a 74 TTL threshold. The point (e.g., tunnel, interface) at which the 75 packet fails the TTL check will not be capable of pruning upstream 76 and hence will sink all traffic, independent of whether there are 77 downstream group members. Note that without somehow associating prune 78 state and TTL, this problem will persist. For example, while it might 79 seem possible to send a prune upstream from the point where the 80 packet is discarded, this strategy could prevent legitimate traffic 81 from being forwarded (subsequent packets could take a different path 82 and wind up at the same point with a larger TTL). However, if a prune 83 had been sent, the packet may not be forwarded on interfaces that it 84 should have been. 86 On the other hand, by using administratively scoped IP multicast, one 87 can achieve locally scoped multicast with simple, clear semantics. 89 The key properties of any implementation of administratively scoped 90 IP multicast are that (i). packets addressed to administratively 91 scoped multicast addresses do not cross configured administrative 92 boundaries, and (ii). administratively scoped multicast addresses are 93 locally assigned, and hence are not required to be unique across 94 administrative boundaries. These properties are sufficient to imple- 95 ment administrative scoping. 97 Allocation of the Administratively Scoped IPv4 Multicast Address Space 99 IANA should allocate the range 239.0.0.0 to 239.255.255.255 to be 100 the "Administratively Scoped IPv4 Multicast" address space. 102 Discussion 104 In order to support administratively scoped IP multicast, a router 105 should support the configuration of scoped IP multicast boundaries. 106 Such a router, called a boundary router, does not forward packets 107 matching its boundary definition in either direction across its 108 border (the bi-directional check prevents problems with multi-access 109 networks). In addition, a boundary router always prunes the boundary 110 for dense-mode groups, or doesn't accept joins for sparse-mode groups 111 [PIMSM] in the administratively scoped range. 113 Structure of the Administratively Scoped Multicast Space 115 The structure of the IP version 4 administratively scoped multicast 116 space is based on the IP Version 6 Addressing Architecture described 117 in RFC 1884. The following table outlines the partitioning of the 118 IPv4 multicast space, and gives the mapping to IPv6 SCOP values 119 [RFC1884]. 121 IPv6 SCOP RFC 1884 Description IPv4 Prefix 122 ================================================================== 123 0 reserved 124 1 node-local scope 125 2 link-local scope 224.0.0.0/24 126 3 (unassigned) 239.255.0.0/16 127 4 (unassigned) 239.254.0.0/16 128 5 site-local scope 239.253.0.0/16 129 6 (unassigned) 130 7 (unassigned) 131 8 organization-local scope 239.192.0.0/14 132 A (unassigned) 133 B (unassigned) 134 C (unassigned) 135 D (unassigned) 136 E global scope 224.0.1.0-238.255.255.255 137 F reserved 138 (unassigned) 239.0.0.0/10 139 (unassigned) 239.64.0.0/10 140 (unassigned) 239.128.0.0/10 142 The IPv4 Local Scope -- 239.255.0.0/16 144 239.255.0.0/16 is the IPv4 Local Scope. While how local is the Local 145 Scope is site dependent, locally scoped regions must obey certain 146 topological constraints. In particular, a Local Scope must not span 147 any other boundary. That is, it must be completely contained within, 148 or equal to, any larger scope. In the event that two scope regions 149 overlap in area, the area that overlaps must be in it's own local 150 scope. This also means that any scope boundary is also a boundary for 151 the Local Scope. The more general topological requirements for admin- 152 istratively scoped regions are discussed below. 154 Other IPv4 Scopes of Interest 155 The other two scope classes of interest, statically assigned link- 156 local scope and global scope already exist to some extent in IP ver- 157 sion 4 multicast space. In particular, the statically assigned link- 158 local scope is 224.0.0.0/24. The existing global scope allocations 159 are currently somewhat more granular, and include 161 224.1.0.0-224.1.255.255 ST Multicast Groups 162 224.2.0.0-224.2.127.253 Multimedia Conference Calls 163 224.2.127.254 SAPv1 Announcements 164 224.2.127.255 SAPv0 Announcements (deprecated) 165 224.2.128.0-224.2.255.255 SAP Dynamic Assignments 166 224.252.0.0-224.255.255.255 DIS transient groups 167 232.0.0.0-232.255.255.255 VMTP transient groups 169 See ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses 170 for current multicast address assignments. 172 Topological Requirements for Administrative Boundaries 174 An administratively scoped IP multicast region is defined to be a 175 topological region in which there are one or more boundary routers 176 with common boundary definitions. Such a router is said to be a boun- 177 dary for scoped addresses in the range defined in its configuration. 179 Network administrators may configure a scope region whenever local 180 multicast scope is required. In addition, an administrator may con- 181 figure overlapping scope regions (networks can be in multiple scope 182 regions) where convenient, with the only limitations being that a 183 scope region must be connected (there must be a path between any two 184 nodes within a scope region that doesn't leave that region), and con- 185 vex (i.e., no path between any two points in the region can cross a 186 region boundary). Finally, as mentioned above, an important con- 187 straint on the configuration of local scopes is that the local scope 188 must not span any other boundary. 190 Finally, note that any scope boundary is a boundary for the Local 191 Scope. This implies that packets sent to groups in the 239.255/16 192 range must not be forwarded across any link with any scoped boundary 193 defined. That is, setting a boundary on a link for any prefix must 194 also set a boundary on that link for the local scope prefix. 196 Example: DVMRP 198 DVMRP [DVMRP] implementations could be extended to support a boundary 199 attribute in the interface configuration [ASMA]. The boundary attri- 200 bute that includes a prefix and mask, and has the semantics that 201 packets matching the prefix and mask do not not pass the boundary. As 202 mentioned above, the implementation would also prune the boundary. 204 Security Considerations 206 While security considerations are not explicitly discussed in this 207 memo, it is important to note that a boundary router as described 208 here should not be considered to provide any kind of firewall func- 209 tionality. 211 References 213 [ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP 214 Multicast", , presented at the 30th IETF, Toronto, 215 Canada, 25 July 1994. 217 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing 218 Protocol", draft-ietf-idmr-dvmrp-v3-03, September, 219 1996. 221 [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing 222 Architecture", RFC1884, December 1995. 224 [PIMSM] Estrin, D, et. al., "Protocol Independent Multicast 225 Sparse Mode (PIM-SM): Protocol Specification", 226 draft-ietf-idmr-PIM-SM-spec-10.ps, March, 1996. 228 Author's Address 230 David Meyer 231 Advanced Network Technology Center 232 University of Oregon 233 1225 Kincaid St. 235 Eugene, OR 97403 237 phone: +1 541.346.1747 238 email: meyer@antc.uoregon.edu