idnits 2.17.1 draft-ietf-mboned-admin-ip-space-05.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-20) 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 7 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 8 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 ([RFC1884]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 28 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 1998) is 9441 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) == Missing Reference: 'RFC-1825' is mentioned on line 272, but not defined ** Obsolete undefined reference: RFC 1825 (Obsoleted by RFC 2401) == Missing Reference: 'RFC-1827' is mentioned on line 272, but not defined ** Obsolete undefined reference: RFC 1827 (Obsoleted by RFC 2406) == Unused Reference: 'ASMA' is defined on line 287, 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-05 ** Downref: Normative reference to an Informational draft: draft-ietf-idmr-dvmrp-v3 (ref. 'DVMRP') == Outdated reference: A later version (-06) exists of draft-ietf-mboned-mzap-00 ** Downref: Normative reference to an Historic draft: draft-ietf-mboned-mzap (ref. 'MZAP') -- No information found for draft-ietf-idmr-pim-dm - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'PIMDM' ** Downref: Normative reference to an Experimental draft: draft-ietf-idmr-pim-sm-specv2 (ref. 'PIMSM') ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1884 (Obsoleted by RFC 2373) -- Possible downref: Normative reference to a draft: ref. 'SAP' Summary: 18 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group David Meyer 2 Internet Draft University of Oregon 3 Category Best Current Practice 5 draft-ietf-mboned-admin-ip-space-05.txt June 1998 7 Administratively Scoped IP Multicast 9 1. Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 24 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 25 ftp.isi.edu (US West Coast). 27 2. Abstract 29 This document defines the "administratively scoped IPv4 multicast 30 space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it 31 describes a simple set of semantics for the implementation of 32 Administratively Scoped IP Multicast. Finally, it provides a mapping 33 between the IPv6 multicast address classes [RFC1884] and IPv4 34 multicast address classes. 36 This memo is a product of the MBONE Deployment Working Group (MBONED) 37 in the Operations and Management Area of the Internet Engineering 38 Task Force. Submit comments to or the author. 40 3. Acknowledgments 42 Much of this memo is taken from "Administratively Scoped IP 43 Multicast", Van Jacobson and Steve Deering, presented at the 30th 44 IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and 45 Dave Thaler have also provided insightful comments on earlier 46 versions of this document. 48 4. Introduction 50 Most current IP multicast implementations achieve some level of 51 scoping by using the TTL field in the IP header. Typical MBONE 52 (Multicast Backbone) usage has been to engineer TTL thresholds that 53 confine traffic to some administratively defined topological region. 54 The basic forwarding rule for interfaces with configured TTL 55 thresholds is that a packet is not forwarded across the interface 56 unless its remaining TTL is greater than the threshold. 58 TTL scoping has been used to control the distribution of multicast 59 traffic with the objective of easing stress on scarce resources 60 (e.g., bandwidth), or to achieve some kind of improved privacy or 61 scaling properties. In addition, the TTL is also used in its 62 traditional role to limit datagram lifetime. Given these often 63 conflicting roles, TTL scoping has proven difficult to implement 64 reliably, and the resulting schemes have often been complex and 65 difficult to understand. 67 A more serious architectural problem concerns the interaction of TTL 68 scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The 69 particular problem is that in many common cases, TTL scoping can 70 prevent pruning from being effective. Consider the case in which a 71 packet has either had its TTL expire or failed a TTL threshold. The 72 router which discards the packet will not be capable of pruning any 73 upstream sources, and thus will sink all multicast traffic (whether 74 or not there are downstream receivers). Note that while it might seem 75 possible to send prunes upstream from the point at which a packet is 76 discarded, this strategy can result in legitimate traffic being 77 discarded, since subsequent packets could take a different path and 78 arrive at the same point with a larger TTL. 80 On the other hand, administratively scoped IP multicast can provide 81 clear and simple semantics for scoped IP multicast. The key 82 properties of administratively scoped IP multicast are that (i). 83 packets addressed to administratively scoped multicast addresses do 84 not cross configured administrative boundaries, and (ii). 85 administratively scoped multicast addresses are locally assigned, and 86 hence are not required to be unique across administrative boundaries. 88 5. Definition of the Administratively Scoped IPv4 Multicast Space 90 The administratively scoped IPv4 multicast address space is defined 91 to be the range 239.0.0.0 to 239.255.255.255. 93 6. Discussion 95 In order to support administratively scoped IP multicast, a router 96 should support the configuration of per-interface scoped IP multicast 97 boundaries. Such a router, called a boundary router, does not forward 98 packets matching an interface's boundary definition in either 99 direction (the bi-directional check prevents problems with multi- 100 access networks). In addition, a boundary router always prunes the 101 boundary for dense-mode groups [PIMDM], and doesn't accept joins for 102 sparse-mode groups [PIMSM] in the administratively scoped range. 104 7. The Structure of the Administratively Scoped Multicast Space 106 The structure of the IP version 4 administratively scoped multicast 107 space is loosely based on the IP Version 6 Addressing Architecture 108 described in RFC 1884 [RFC1884]. This document defines two important 109 scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These 110 scopes are described below. 112 7.1. The IPv4 Local Scope -- 239.255.0.0/16 114 239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local 115 Scope is the minimal enclosing scope, and hence is not further 116 divisible. Although the exact extent of a Local Scope is site 117 dependent, locally scoped regions must obey certain topological 118 constraints. In particular, a Local Scope must not span any other 119 scope boundary. Further, a Local Scope must be completely contained 120 within or equal to any larger scope. In the event that scope regions 121 overlap in area, the area of overlap must be in its own local scope. 122 This implies that any scope boundary is also a boundary for the Local 123 Scope. The more general topological requirements for administratively 124 scoped regions are discussed below. 126 7.1.1. Expansion of the IPv4 Local Scope 128 The IPv4 Local Scope space grows "downward". As such, the IPv4 Local 129 Scope may grow downward from 239.255.0.0/16 into the reserved ranges 130 239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not 131 be utilized until the 239.255.0.0/16 space is no longer sufficient. 133 7.2. The IPv4 Organization Local Scope -- 239.192.0.0/14 135 239.192.0.0/14 is defined to be the IPv4 Organization Local Scope, 136 and is the space from which an organization should allocate sub- 137 ranges when defining scopes for private use. 139 7.2.1. Expansion of the IPv4 Organization Local Scope 141 The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are 142 unassigned and available for expansion of this space. These ranges 143 should be left unassigned until the 239.192.0.0/14 space is no longer 144 sufficient. This is to allow for the possibility that future 145 revisions of this document may define additional scopes on a scale 146 larger than organizations. 148 7.3. Other IPv4 Scopes of Interest 150 The other two scope classes of interest, statically assigned link- 151 local scope and global scope already exist in IPv4 multicast space. 152 The statically assigned link-local scope is 224.0.0.0/24. The 153 existing static global scope allocations are somewhat more granular, 154 and include 156 224.1.0.0-224.1.255.255 ST Multicast Groups 157 224.2.0.0-224.2.127.253 Multimedia Conference Calls 158 224.2.127.254 SAPv1 Announcements 159 224.2.127.255 SAPv0 Announcements (deprecated) 160 224.2.128.0-224.2.255.255 SAP Dynamic Assignments 161 224.252.0.0-224.255.255.255 DIS transient groups 162 232.0.0.0-232.255.255.255 VMTP transient groups 164 See [RFC1700] for current multicast address assignments (this list 165 can also be found, possibly in a more current form, on 166 ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses). 168 8. Topological Requirements for Administrative Boundaries 170 An administratively scoped IP multicast region is defined to be a 171 topological region in which there are one or more boundary routers 172 with common boundary definitions. Such a router is said to be a 173 boundary for scoped addresses in the range defined in its 174 configuration. 176 Network administrators may configure a scope region whenever 177 constrained multicast scope is required. In addition, an 178 administrator may configure overlapping scope regions (networks can 179 be in multiple scope regions) where convenient, with the only 180 limitations being that a scope region must be connected (there must 181 be a path between any two nodes within a scope region that doesn't 182 leave that region), and convex (i.e., no path between any two points 183 in the region can cross a region boundary). However, it is important 184 to note that if administratively scoped areas intersect 185 topologically, then the outer scope must consist of its address space 186 minus the address spaces of any intersecting scopes. This requirement 187 prevents the problem that would arise when a path between two points 188 in a convex region crosses the boundary of an intersecting region. 189 For this reason, it is recommended that administrative scopes that 190 intersect topologically should not intersect in address range. 192 Finally, note that any scope boundary is a boundary for the Local 193 Scope. This implies that packets sent to groups covered by 194 239.255.0.0/16 must not be forwarded across any link for which a 195 scoped boundary is defined. 197 9. Partitioning of the Administratively Scoped Multicast Space 199 The following table outlines the partitioning of the IPv4 multicast 200 space, and gives the mapping from IPv4 multicast prefixes to IPv6 201 SCOP values: 203 IPv6 SCOP RFC 1884 Description IPv4 Prefix 204 ================================================================== 205 0 reserved 206 1 node-local scope 207 2 link-local scope 224.0.0.0/24 208 3 (unassigned) 239.255.0.0/16 209 4 (unassigned) 210 5 site-local scope 211 6 (unassigned) 212 7 (unassigned) 213 8 organization-local scope 239.192.0.0/14 214 A (unassigned) 215 B (unassigned) 216 C (unassigned) 217 D (unassigned) 218 E global scope 224.0.1.0-238.255.255.255 219 F reserved 220 (unassigned) 239.0.0.0/10 221 (unassigned) 239.64.0.0/10 222 (unassigned) 239.128.0.0/10 224 10. Structure and Use of a Scoped Region 226 The high order /24 in every scoped region is reserved for relative 227 assignments. A relative assignment is an integer offset from highest 228 address in the scope and represents a 32-bit address (for IPv4). For 229 example, in the Local Scope defined above, 239.255.255.0/24 is 230 reserved for relative allocations. The de-facto relative assignment 231 "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for 232 SAP [SAP]. The next relative assignment, "1", corresponds to the 233 address 239.255.255.254 in the Local Scope. The rest of a scoped 234 region below the reserved /24 is available for dynamic assignment 235 (presumably by an address allocation protocol). 237 In is important to note that a scope discovery protocol [MZAP] will 238 have to be developed to make practical use of scopes other than the 239 Local Scope. In addition, since any use of any administratively 240 scoped region, including the Local Scope, requires dynamically 241 assigned addressing, an Address Allocation Protocol (AAP) will need 242 to be developed to make administrative scoping generally useful. 244 10.1. Relative Assignment Guidelines 246 Requests for relative assignments should be directed to the IANA. In 247 general, relative addresses will be used only for bootstrapping to 248 dynamic address assignments from within the scope. As such, relative 249 assignments should only be made to those services that cannot use a 250 dynamic address assignment protocol to find the address used by that 251 service within the desired scope, such as a dynamic address 252 assignment service itself. 254 11. Security Considerations 256 It is recommended that organizations using the administratively 257 scoped IP Multicast addresses not rely on them to prevent sensitive 258 data from being transmitted outside the organization. Should a 259 multicast router on an administrative boundary be mis-configured, 260 have a bug in the administrative scoping code, or have other problems 261 that would cause that router to forward an administratively scoped IP 262 multicast packet outside of the proper scope, the organizations data 263 would leave its intended transmission region. 265 Organizations using administratively scoped IP Multicasting to 266 transmit sensitive data should use some confidentiality mechanism 267 (e.g. encryption) to protect that data. In the case of many existing 268 video-conferencing applications (e.g. vat), encryption is available 269 as an application feature and merely needs to be enabled (and 270 appropriate cryptographic keys securely distributed). For many other 271 applications, the use of the IP Encapsulating Security Payload (ESP) 272 [RFC-1825, RFC-1827] can provide IP-layer confidentiality though 273 encryption. 275 Within the context of an administratively scoped IP multicast group, 276 the use of manual key distribution might well be feasible. While 277 dynamic key management for IP Security is a research area at the time 278 this note is written, it is expected that the IETF will be extending 279 the ISAKMP key management protocol to support scalable multicast key 280 distribution in the future. 282 It is important to note that the "boundary router" described in this 283 note is not necessarily providing any kind of firewall capability. 285 12. References 287 [ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP 288 Multicast", , presented at the 30th IETF, Toronto, 289 Canada, 25 July 1994. 291 [DVMRP] T. Pusateri, "Distance Vector Multicast Routing 292 Protocol", draft-ietf-idmr-dvmrp-v3-05.txt, 293 October, 1997. 295 [MZAP] M. Handley, "Multicast-Scope Zone Announcement 296 Protocol (MZAP)", draft-ietf-mboned-mzap-00.txt, 297 December, 1997. 299 [PIMDM] Deering, S, et. al., "Protocol Independent Multicast 300 Version 2, Dense Mode Specification", 301 draft-ietf-idmr-pim-dm-05.txt, May, 1997. 303 [PIMSM] Estrin, D, et. al., "Protocol Independent Multicast 304 Sparse Mode (PIM-SM): Protocol Specification", 305 draft-ietf-idmr-pim-sm-specv2-00.txt, 307 September,1997. 309 [RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October, 310 1994. 312 [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing 313 Architecture", RFC1884, December 1995. 315 [SAP] Handley, Mark, "SAP: Session Announcement Protocol", 316 draft-ietf-mmusic-sap-00.txt, November, 1996. 318 13. Author's Address 320 David Meyer 321 Cisco Systems 322 San Jose, CA 323 email: dmm@cisco.com