idnits 2.17.1 draft-ietf-mboned-admin-ip-space-03.txt: ** The Abstract section seems to be numbered 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-26) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages -- Found 7 instances of the string 'FORMFEED[Page...' -- is this a case of missing nroff postprocessing? 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 ([RFC1884]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 25 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: ---------------------------------------------------------------------------- -- 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 (June 1997) is 9812 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ASMA' is defined on line 227, but no explicit reference was found in the text -- 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') -- No information found for draft-ietf-idmr-pim-dm - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIMDM' -- No information found for draft-ietf-idmr-PIM-SM-spec - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIMSM' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group David Meyer 3 Internet Draft University of Oregon 4 Category Best Current Practice 6 draft-ietf-mboned-admin-ip-space-03.txt June 1997 8 Administratively Scoped IP Multicast 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 2. Abstract 30 This document defines the "administratively scoped IPv4 multicast 31 space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it 32 describes a simple set of semantics for the implementation of 33 Administratively Scoped IP Multicast. Finally, it provides a mapping 34 between the IPv6 multicast address classes [RFC1884] and IPv4 35 multicast address classes. 37 This memo is a product of the MBONE Deployment Working Group (MBONED) 38 in the Operations and Management Area of the Internet Engineering 39 Task Force. Submit comments to or the author. 41 3. Acknowledgments 43 Much of this memo is taken from "Administratively Scoped IP 44 Multicast", Van Jacobson and Steve Deering, presented at the 30th 45 IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and 46 Dave Thaler have also provided insightful comments on earlier 47 versions of this document. 49 4. Introduction 51 Most current IP multicast implementations achieve some level of 52 scoping by using the TTL field in the IP header. Typical MBONE 53 (Multicast Backbone) usage has been to engineer TTL thresholds that 54 confine traffic to some administratively defined topological region. 55 The basic forwarding rule for interfaces with configured TTL 56 thresholds is that a packet is not forwarded across the interface 57 unless its remaining TTL is greater than the threshold. 59 TTL scoping has been used to control the distribution of multicast 60 traffic with the objective of easing stress on scarce resources 61 (e.g., bandwidth), or to achieve some kind of improved privacy or 62 scaling properties. In addition, the TTL is also used in its 63 traditional role to limit datagram lifetime. Given these often 64 conflicting roles, TTL scoping has proven difficult to implement 65 reliably, and the resulting schemes have often been complex and 66 difficult to understand. 68 A more serious architectural problem concerns the interaction of TTL 69 scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The 70 particular problem is that in many common cases, TTL scoping can 71 prevent pruning from being effective. Consider the case in which a 72 packet has either had its TTL expire or failed a TTL threshold. The 73 router which discards the packet will not be capable of pruning any 74 upstream sources, and thus will sink all multicast traffic (whether 75 or not there are downstream receivers). Note that while it might seem 76 possible to send prunes upstream from the point at which a packet is 77 discarded, this strategy can result in legitimate traffic being 78 discarded, since subsequent packets could take a different path and 79 arrive at the same point with a larger TTL. 81 On the other hand, administratively scoped IP multicast can provide 82 clear and simple semantics for scoped IP multicast. The key 83 properties of administratively scoped IP multicast are that (i). 84 packets addressed to administratively scoped multicast addresses do 85 not cross configured administrative boundaries, and (ii). 86 administratively scoped multicast addresses are locally assigned, and 87 hence are not required to be unique across administrative boundaries. 89 5. Definition of the Administratively Scoped IPv4 Multicast Space 91 The administratively scoped IPv4 multicast address space is defined 92 to be the range 239.0.0.0 to 239.255.255.255. 94 6. Discussion 96 In order to support administratively scoped IP multicast, a router 97 should support the configuration of per-interface scoped IP multicast 98 boundaries. Such a router, called a boundary router, does not forward 99 packets matching an interface's boundary definition in either 100 direction (the bi-directional check prevents problems with multi- 101 access networks). In addition, a boundary router always prunes the 102 boundary for dense-mode groups [PIMDM], and doesn't accept joins for 103 sparse-mode groups [PIMSM] in the administratively scoped range. 105 7. The Structure of the Administratively Scoped Multicast Space 107 The structure of the IP version 4 administratively scoped multicast 108 space is loosely based on the IP Version 6 Addressing Architecture 109 described in RFC 1884 [RFC1884]. This document defines two important 110 scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These 111 scopes are described below. 113 7.1. The IPv4 Local Scope -- 239.255.0.0/16 115 239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local 116 Scope is the minimal enclosing scope, and hence is not further 117 divisible. Although the exact extent of a Local Scope is site 118 dependent, locally scoped regions must obey certain topological 119 constraints. In particular, a Local Scope must not span any other 120 scope boundary. Further, a Local Scope must be completely contained 121 within or equal to any larger scope. In the event that scope regions 122 overlap in area, the area of overlap must be in its own local scope. 123 This implies that any scope boundary is also a boundary for the Local 124 Scope. The more general topological requirements for administratively 125 scoped regions are discussed below. 127 7.1.1. Expansion of the IPv4 Local Scope 129 The IPv4 Local Scope space grows "downward". As such, the IPv4 Local 130 Scope may grow downward from 239.255.0.0/16 into the reserved ranges 131 239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not 132 be utilized until the 239.255.0.0/16 space is no longer sufficient. 134 7.2. The IPv4 Organization Local Scope -- 239.192.0.0/14 136 239.192.0.0/14 is defined to be the IPv4 Organization Local Scope, 137 and is the space from which an organization should allocate sub- 138 ranges when defining scopes for private use. 140 7.2.1. Expansion of the IPv4 Organization Local Scope 142 The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are 143 unassigned and available for expansion of this space. These ranges 144 should be left unassigned until the 239.192.0.0/14 space is no longer 145 sufficient. This is to allow for the possibility that future 146 revisions of this document may define additional scopes on a scale 147 larger than organizations. 149 7.3. Other IPv4 Scopes of Interest 151 The other two scope classes of interest, statically assigned link- 152 local scope and global scope already exist in IPv4 multicast space. 153 The statically assigned link-local scope is 224.0.0.0/24. The 154 existing static global scope allocations are somewhat more granular, 155 and include 157 224.1.0.0-224.1.255.255 ST Multicast Groups 158 224.2.0.0-224.2.127.253 Multimedia Conference Calls 159 224.2.127.254 SAPv1 Announcements 160 224.2.127.255 SAPv0 Announcements (deprecated) 161 224.2.128.0-224.2.255.255 SAP Dynamic Assignments 162 224.252.0.0-224.255.255.255 DIS transient groups 163 232.0.0.0-232.255.255.255 VMTP transient groups 165 See [RFC1700] for current multicast address assignments (this list 166 can also be found, possibly in a more current form, on 167 ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses). 169 8. Topological Requirements for Administrative Boundaries 171 An administratively scoped IP multicast region is defined to be a 172 topological region in which there are one or more boundary routers 173 with common boundary definitions. Such a router is said to be a 174 boundary for scoped addresses in the range defined in its 175 configuration. 177 Network administrators may configure a scope region whenever 178 constrained multicast scope is required. In addition, an 179 administrator may configure overlapping scope regions (networks can 180 be in multiple scope regions) where convenient, with the only 181 limitations being that a scope region must be connected (there must 182 be a path between any two nodes within a scope region that doesn't 183 leave that region), and convex (i.e., no path between any two points 184 in the region can cross a region boundary). 186 Finally, note that any scope boundary is a boundary for the Local 187 Scope. This implies that packets sent to groups covered by 188 239.255.0.0/16 must not be forwarded across any link for which a 189 scoped boundary is defined. 191 9. Partitioning of the Administratively Scoped Multicast Space 193 The following table outlines the partitioning of the IPv4 multicast 194 space, and gives the mapping from IPv4 multicast prefixes to IPv6 195 SCOP values: 197 IPv6 SCOP RFC 1884 Description IPv4 Prefix 198 ================================================================== 199 0 reserved 200 1 node-local scope 201 2 link-local scope 224.0.0.0/24 202 3 (unassigned) 239.255.0.0/16 203 4 (unassigned) 204 5 site-local scope 205 6 (unassigned) 206 7 (unassigned) 207 8 organization-local scope 239.192.0.0/14 208 A (unassigned) 209 B (unassigned) 210 C (unassigned) 211 D (unassigned) 212 E global scope 224.0.1.0-238.255.255.255 213 F reserved 214 (unassigned) 239.0.0.0/10 215 (unassigned) 239.64.0.0/10 216 (unassigned) 239.128.0.0/10 218 10. Security Considerations 220 While security considerations are not explicitly discussed in this 221 memo, it is important to note that a boundary router as described 222 here should not be considered to provide any kind of firewall 223 functionality. 225 11. References 227 [ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP 228 Multicast", , presented at the 30th IETF, Toronto, 229 Canada, 25 July 1994. 231 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing 232 Protocol", draft-ietf-idmr-dvmrp-v3-03.txt, 233 September, 1996. 235 [PIMDM] Deering, S, et. al., "Protocol Independent Multicast 236 Version 2, Dense Mode Specification", 237 draft-ietf-idmr-pim-dm-05.txt, April, 1997. 239 [PIMSM] Estrin, D, et. al., "Protocol Independent Multicast 240 Sparse Mode (PIM-SM): Protocol Specification", 241 draft-ietf-idmr-PIM-SM-spec-10.ps, March, 1997. 243 [RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October, 244 1994. 246 [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing 247 Architecture", RFC1884, December 1995. 249 12. Author's Address 251 David Meyer 252 Advanced Network Technology Center 253 University of Oregon 254 1225 Kincaid St. 255 Eugene, OR 97403 257 phone: +1 541.346.1747 258 email: meyer@antc.uoregon.edu