idnits 2.17.1 draft-ietf-mboned-ssm232-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2119], [SSM], [IANA]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (May 2003) is 7644 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: 'RFC2434' is mentioned on line 200, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Experimental draft: draft-ietf-msdp-spec (ref. 'MSDP') == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-03 ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT David Meyer 3 draft-ietf-mboned-ssm232-05.txt Rob Rockell 4 Greg Shepherd 5 Category Best Current Practice 6 Expires: November 2003 May 2003 8 Source-Specific Protocol Independent Multicast in 232/8 9 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This document is a product of the . Comments should be addressed to 33 the authors, or the mailing list at 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 IP Multicast group addresses in the 232/8 (232.0.0.0 to 42 232.255.255.255) range are designated as source-specific multicast 43 [SSM] destination addresses and are reserved for use by source- 44 specific applications and protocols [IANA]. This document defines 45 operational recommendations to ensure source-specific behavior within 46 the 232/8 range. 48 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 49 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined 50 in RFC 2119 [RFC2119]. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Operational practices in 232/8 . . . . . . . . . . . . . . . . 4 56 2.1. Preventing local sources from sending to shared tree. . . . 4 57 2.2. Preventing remote sources from being learned/joined via MSDP. 4 58 2.3. Preventing receivers from joining the shared tree . . . . . 5 59 2.4. Preventing RP's as candidates for 232/8 . . . . . . . . . . 5 60 3. Intellectual Property. . . . . . . . . . . . . . . . . . . . . 5 61 4. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 6 62 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 6 63 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 6 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7.1. Normative References. . . . . . . . . . . . . . . . . . . . 7 66 7.2. Informative References. . . . . . . . . . . . . . . . . . . 7 67 8. Author's Addresses . . . . . . . . . . . . . . . . . . . . . . 7 68 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 Current PIM Sparse Mode (PIM-SM) [RFC2362] relies on the shared 73 Rendezvous Point (RP) tree to learn about active sources for a group 74 and to support group-generic (not source specific) data distribution. 75 The IP Multicast group address range 232/8 has been designated for 76 source-specific [SSM] applications and protocols [IANA] and SHOULD 77 support source-only trees only, precluding the requirement of an RP 78 and a shared tree; active sources in the 232/8 range will be 79 discovered out of band. PIM Sparse Mode Designated Routers (DR), with 80 local membership, are capable of joining the shortest path tree for 81 the source directly using Source-Specific PIM [SSM]. 83 Operational best common practices in the 232/8 group address range 84 are necessary to ensure shortest path source-only trees across 85 multiple domains in the Internet [SSM], and to prevent data from 86 sources sending to groups in the 232/8 range from arriving via shared 87 trees. This avoids unwanted data arrival, and allows several sources 88 to use the same group address without conflict at the receivers. 90 The operational practices SHOULD 92 o Prevent local sources from sending to shared tree 94 o Prevent remote sources from being learned/joined via MSDP [MSDP] 96 o Prevent receivers from joining the shared tree 98 o Prevent RP's as candidates for 232/8 100 2. Operational practices in 232/8 102 2.1. Preventing local sources from sending to shared tree 104 Eliminating the use of shared trees for groups in 232/8, while 105 maintaining coexistence with PIM-SM, behavior of the RP and/or the DR 106 needs to be modified. This can be accomplished by 108 - preventing data for 232/8 groups from being sent encapsulated to 109 the RP by the DR 111 - preventing the RP from accepting registers for 232/8 groups from 112 the DR 114 - preventing the RP from forwarding accepted data down (*,G) 115 tree for 232/8 groups 117 2.2. Preventing remote sources from being learned/joined via MSDP 119 PIM-SS does not require active source announcements via MSDP. All 120 source announcements are received out of band, the the last hop 121 router is responsible for sending (S,G) joins directly to the source. 122 To prevent propagation of SAs in the 232/8 range, an RP SHOULD 124 - never originate an SA for any 232/8 groups 126 - never accept or forward an SA for any 232/8 groups. 128 2.3. Preventing receivers from joining the shared tree 130 Local PIM domain practices need to be enforced to prevent local 131 receivers from joining the shared tree for 232/8 groups. This can be 132 accomplished by 134 - preventing DR from sending (*,G) joins for 232/8 groups 136 - preventing RP from accepting (*,G) join for 232/8 groups 138 However, within a local PIM domain, any last-hop router NOT 139 preventing (*,G) joins may trigger unwanted (*,G) state toward 140 the RP which intersects an existing (S,G) tree, allowing the 141 receiver on the shared tree to receive the data, breaking the 142 source-specific [SSM] service model. It is therefore recommended 143 that ALL routers in the domain MUST reject AND never originate 144 (*,G) joins for 232/8 groups. 146 In those cases in which an ISP is offering its customers (or 147 others) the use of the ISP's RP, the ISP SHOULD NOT allow (*,G) 148 joins in the 232/8 range. 150 2.4. Preventing RP's as candidates for 232/8 152 Because PIM-SS does not require an RP, all RPs SHOULD NOT offer 153 themselves as candidates in the 232/8 range. This can be accomplished 154 by 156 - preventing RP/BSR from announcing in the 232/8 range 158 - preventing ALL routers from accepting RP delegations in the 159 232/8 range 161 - precluding RP functionality on RP for the 232/8 range 163 3. Intellectual Property 165 The IETF takes no position regarding the validity or scope of any 166 intellectual property or other rights that might be claimed to 167 pertain to the implementation or use of the technology described in 168 this document or the extent to which any license under such rights 169 might or might not be available; neither does it represent that it 170 has made any effort to identify any such rights. Information on the 171 IETF's procedures with respect to rights in standards-track and 172 standards-related documentation can be found in BCP-11. Copies of 173 claims of rights made available for publication and any assurances of 174 licenses to be made available, or the result of an attempt made to 175 obtain a general license or permission for the use of such 176 proprietary rights by implementors or users of this specification can 177 be obtained from the IETF Secretariat. 179 The IETF invites any interested party to bring to its attention any 180 copyrights, patents or patent applications, or other proprietary 181 rights which may cover technology that may be required to practice 182 this standard. Please address the information to the IETF Executive 183 Director. 185 4. Acknowledgments 187 This document is the work of many people in the multicast community, 188 including (but not limited to) Dino Farinacci, John Meylor, John 189 Zwiebel, Tom Pusateri, Dave Thaler, Toerless Eckert, Leonard 190 Giuliano, Mike McBride, and Pekka Savola. 192 5. Security Considerations 194 This document describes operational practices that introduce no new 195 security issues to either PIM-SM or PIM-SSM. 197 6. IANA Considerations 199 This document creates a no new requirements on IANA namespaces 200 [RFC2434]. 202 7. References 204 7.1. Normative References 206 [MSDP] Meyer, D. and B. Fenner (Editors), "The Multicast 207 Source Discovery Protocol (MSDP)", 208 draft-ietf-msdp-spec-20.txt. Work in Progress. 210 [SSM] Holbrook, H., and B. Cain,, "Source-Specific Multicast", 211 draft-ietf-ssm-arch-03.txt. Work in Progress. 213 [RFC2362] D. Estrin, et. al., "Protocol Independent Multicast-Sparse 214 Mode (PIM-SM): Protocol Specification", RFC 2362, June, 215 1998. 217 7.2. Informative References 219 [IANA] http://www.iana.org 221 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 222 Requirement Levels", RFC 2119, March, 1997. 224 8. Author's Addresses 226 David Meyer 227 Email: dmm@1-4-5.net 229 Robert Rockell 230 Sprint 231 Email: rrockell@sprint.net 233 Greg Shepherd 234 Procket 235 Email: shep@procket.com 237 9. Full Copyright Statement 239 Copyright (C) The Internet Society (2003). All Rights Reserved. 241 This document and translations of it may be copied and furnished to 242 others, and derivative works that comment on or otherwise explain it 243 or assist in its implementation may be prepared, copied, published 244 and distributed, in whole or in part, without restriction of any 245 kind, provided that the above copyright notice and this paragraph are 246 included on all such copies and derivative works. However, this 247 document itself may not be modified in any way, such as by removing 248 the copyright notice or references to the Internet Society or other 249 Internet organizations, except as needed for the purpose of 250 developing Internet standards in which case the procedures for 251 copyrights defined in the Internet Standards process must be 252 followed, or as required to translate it into languages other than 253 English. 255 The limited permissions granted above are perpetual and will not be 256 revoked by the Internet Society or its successors or assigns. 258 This document and the information contained herein is provided on an 259 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 260 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 261 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 262 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 263 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.