idnits 2.17.1 draft-ietf-mboned-ssm232-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 334. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 311. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 318. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 324. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 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 14, 2006) is 6527 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: 'I-D.pim-sm-v2-new' is mentioned on line 77, but not defined == Missing Reference: 'RFCED' is mentioned on line 144, but not defined == Unused Reference: 'I-D.ietf-pim-sm-v2-new' is defined on line 255, but no explicit reference was found in the text == Unused Reference: 'RFC2028' is defined on line 264, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2028 (Obsoleted by RFC 9281) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 3569 ** Downref: Normative reference to an Experimental RFC: RFC 3618 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Shepherd 3 Internet-Draft Cisco 4 Expires: December 16, 2006 Rockell 5 Sprint 6 Meyer 7 Cisco 8 June 14, 2006 10 Source-Specific Protocol Independent Multicast in 232/8 11 draft-ietf-mboned-ssm232-09 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 16, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 IP Multicast group addresses in the 232/8 (232.0.0.0 to 45 232.255.255.255) range are designated as source-specific multicast 46 destination addresses and are reserved for use by source-specific 47 multicast applications and protocols. This document defines 48 operational recommendations to ensure source-specific behavior within 49 the 232/8 range. 51 Requirements Language 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [RFC2119]. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. BCP, Experimental Protocols and Normative References . . . 3 61 2. Operational practices in 232/8 . . . . . . . . . . . . . . . . 4 62 2.1. Preventing local sources from sending to shared tree . . . 4 63 2.2. Preventing remote sources from being learned/joined 64 via MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.3. Preventing receivers from joining the shared tree . . . . . 5 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 8. Intellectual Property and Copyright Statements . . . . . . . . . . 9 75 1. Introduction 77 Current PIM Sparse Mode (PIM-SM) [I-D.pim-sm-v2-new] relies on the 78 shared Rendezvous Point (RP) tree to learn about active sources for a 79 group and to support group-generic (Any Source Multicast or ASM) data 80 distribution. The IP Multicast group address range 232/8 has been 81 designated for Source-Specific Multicast (SSM) applications and 82 protocols [IANA] and SHOULD support source-only trees only, 83 precluding the requirement of an RP and a shared tree; active sources 84 in the 232/8 range will be discovered out of band. PIM-SM Designated 85 Routers (DR), with local membership, are capable of joining the 86 shortest path tree for the source directly using SSM functionality of 87 PIM-SM. 89 Operational best common practices in the 232/8 group address range 90 are necessary to ensure shortest path source-only trees across 91 multiple domains in the Internet [RFC3569], and to prevent data from 92 sources sending to groups in the 232/8 range from arriving via shared 93 trees. This avoids unwanted data arrival, and allows several sources 94 to use the same group address without conflict at the receivers. 96 The operational practices SHOULD: o Prevent local sources from 97 sending to shared tree o Prevent receivers from joining the shared 98 tree o Prevent RP's as candidates for 232/8 o Prevent remote sources 99 from being learned/joined via MSDP [RFC3618] 101 1.1. BCP, Experimental Protocols and Normative References 103 This document describes the best current practice for a widely 104 deployed Experimental protocol, MSDP. There is no plan to advance 105 the MSDP's status (for example, to Proposed Standard). The reasons 106 for this include: 108 o MSDP was originally envisioned as a temporary protocol to be 109 supplanted by whatever the IDMR working group produced as an 110 inter-domain protocol. However, the IDMR WG (or subsequently, the 111 BGMP WG) never produced a protocol that could be deployed to 112 replace MSDP. 114 o One of the primary reasons given for MSDP to be classified as 115 Experimental was that the MSDP Working Group came up with 116 modifications to the protocol that the WG thought made it better 117 but that implementors didn't see any reasons to deploy. Without 118 these modifications (e.g., UDP or GRE encapsulation), MSDP can 119 have negative consequences to initial packets in datagram streams. 121 o Scalability: Although we don't know what the hard limits might be, 122 readvertising everything you know every 60 seconds clearly limits 123 the amount of state you can advertise. 125 o MSDP reached near ubiquitous deployment as the de-facto standard 126 inter-domain multicast protocol in the IPv4 Internet. 128 o No consensus could be reached regarding the reworking of MSDP to 129 address the many concerns of various constituencies within the 130 IETF. As a result, a decision was taken to document what is 131 (ubiquitously) deployed and move that document to Experimental. 132 While advancement of MSDP to Proposed Standard was considered, for 133 the reasons mentioned above, it was immediately discarded. 135 o The advent of source specific multicast and protocols such as bi- 136 directional PIM, as well as embedded RP techniques for IPv6, have 137 further reduced consensus that a replacement protocol for MSDP for 138 the IPv4 Internet is required. 140 The RFC Editor's policy regarding references is that they be split 141 into two categories known as "normative" and "informative". 142 Normative references specify those documents which must be read to 143 understand or implement the technology in an RFC (or whose technology 144 must be present for the technology in the new RFC to work) [RFCED]. 145 In order to understand this document, one must also understand both 146 the PIM-SM and MSDP documents. As a result, references to these 147 documents are normative. The IETF has adopted the policy that BCPs 148 must not have normative references to Experimental protocols. 149 However, this document is a special case in that the underlying 150 Experimental document (MSDP) is not planned to be advanced to 151 Proposed Standard. The MBONED Working Group requests approval under 152 the Variance Procedure as documented in RFC 2026 [RFC2026]. Note to 153 RFC-Editor: If IETF/IESG approves this, please change the above 154 sentence into: The MBONED Working Group has requested approval under 155 the Variance Procedure as documented in RFC 2026 [RFC2026]. The IESG 156 followed the Variance Procedure, and after an additional 4 week IETF 157 Last Call evaluated the comments and status and has approved this 158 document. 160 2. Operational practices in 232/8 162 2.1. Preventing local sources from sending to shared tree 164 Eliminating the use of shared trees for groups in 232/8, while 165 maintaining coexistence with ASM in PIM-SM, behavior of the RP and/or 166 the DR needs to be modified. This can be accomplished by 167 o preventing data for 232/8 groups from being sent encapsulated to 168 the RP by the DR. 170 o preventing the RP from accepting registers for 232/8 groups from 171 the DR. 173 o preventing the RP from forwarding accepted data down (*,G) tree 174 for 232/8 groups. 176 2.2. Preventing remote sources from being learned/joined via MSDP 178 SSM does not require active source announcements via MSDP. All 179 source announcements are received out of band, the the last hop 180 router being responsible for sending (S,G) joins directly to the 181 source. To prevent propagation of SAs in the 232/8 range, an RP 182 SHOULD 184 o never originate an SA for any 232/8 groups. 186 o never accept or forward an SA for any 232/8 groups. 188 2.3. Preventing receivers from joining the shared tree 190 Local PIM-SM domain practices need to be enforced to prevent local 191 receivers from joining the shared tree for 232/8 groups. This can be 192 accomplished by 232/8 range. 194 o preventing DR from sending (*,G) joins for 232/8 groups. 196 o preventing RP from accepting (*,G) join for 232/8 groups. 198 However, within a local PIM-SM domain, any last-hop router NOT 199 preventing (*,G) joins may trigger unwanted (*,G) state toward the RP 200 which intersects an existing (S,G) tree, allowing the receiver on the 201 shared tree to receive the data, breaking the source-specific 202 [RFC3569] service model. It is therefore recommended that ALL 203 routers in the domain MUST reject AND never originate (*,G) joins for 204 232/8 groups. In those cases in which an ISP is offering its 205 customers (or others) the use of the ISP's RP, the ISP SHOULD NOT 206 allow (*,G) joins in the 232/8 range. 208 Because SSM does not require a PIM-SM RP, all RPs SHOULD NOT offer 209 themselves as candidates in the 232/8 range. This can be 210 accomplished by 212 o preventing RP/BSR from announcing in the 232/8 range 213 o preventing ALL routers from accepting RP delegations in the 232/8 214 range 216 o precluding RP functionality on RP for the 232/8 range 218 Note that in typical practice, RP's announce themselves as candidates 219 for the 224/4 (which obviously includes 232/8). It is still 220 acceptable to allow the advertisement of 224/4 (or any other superset 221 of 232/8); however, this approach relies on the second point, above, 222 namely, that routers silently just ignore the RP delegation in the 223 232/8 range, and prevent sending or receiving using the shared tree, 224 as described previously. Finally, an RP SHOULD NOT be configured as 225 a candidate RP for 232/8 (or more specific range). 227 3. IANA Considerations 229 This document creates no new requirements on IANA namespaces 230 [RFC2434]. 232 4. Security Considerations 234 This document describes operational practices that introduce no new 235 security issues to PIM-SM in either SSM or ASM operation. However, 236 in the event that the operational practices described in this 237 document are not adhered to, some problems may surface. In 238 particular, section 2.3 describes the effects of non-compliance of 239 last-hop routers (or to some degree, rogue hosts sending PIM-SM 240 messages themselves) on the source-specific service model; creating 241 the (*,G) state for source-specific (S,G) could enable a receiver to 242 receive data it should not get. This can be mitigated by host-side 243 multicast source filtering. 245 5. Acknowledgements 247 This document is the work of many people in the multicast community, 248 including (but not limited to) Dino Farinacci, John Meylor, John 249 Zwiebel, Tom Pusateri, Dave Thaler, Toerless Eckert, Leonard 250 Giuliano, Mike McBride, and Pekka Savola. 252 6. References 253 6.1. Normative References 255 [I-D.ietf-pim-sm-v2-new] 256 Fenner, B., "Protocol Independent Multicast - Sparse Mode 257 (PIM-SM): Protocol Specification (Revised)", 258 draft-ietf-pim-sm-v2-new-12 (work in progress), 259 March 2006. 261 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 262 3", BCP 9, RFC 2026, October 1996. 264 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 265 the IETF Standards Process", BCP 11, RFC 2028, 266 October 1996. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", BCP 14, RFC 2119, March 1997. 271 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 272 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 273 October 1998. 275 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 276 Multicast (SSM)", RFC 3569, July 2003. 278 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 279 Protocol (MSDP)", RFC 3618, October 2003. 281 6.2. Informative References 283 [IANA] "http://www.iana.org", 2005. 285 7. Authors' Addresses 287 Greg Shepherd 288 Cisco 290 Email: shep@cisco.com 292 Robert Rockell 293 Sprint 295 Email: rrockell@sprint.net 297 Dave Meyer 298 Cisco 300 Email: dmm@1-4-5.net 302 8. Intellectual Property Statement 304 The IETF takes no position regarding the validity or scope of any 305 Intellectual Property Rights or other rights that might be claimed to 306 pertain to the implementation or use of the technology described in 307 this document or the extent to which any license under such rights 308 might or might not be available; nor does it represent that it has 309 made any independent effort to identify any such rights. Information 310 on the procedures with respect to rights in RFC documents can be 311 found in BCP 78 and BCP 79. 313 Copies of IPR disclosures made to the IETF Secretariat and any 314 assurances of licenses to be made available, or the result of an 315 attempt made to obtain a general license or permission for the use of 316 such proprietary rights by implementers or users of this 317 specification can be obtained from the IETF on-line IPR repository at 318 http://www.ietf.org/ipr. 320 The IETF invites any interested party to bring to its attention any 321 copyrights, patents or patent applications, or other proprietary 322 rights that may cover technology that may be required to implement 323 this standard. Please address the information to the IETF at 324 ietf-ipr@ietf.org. 326 Disclaimer of Validity 328 This document and the information contained herein are provided on an 329 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 330 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 331 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 332 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 333 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 334 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 336 Copyright Statement 338 Copyright (C) The Internet Society (2006). This document is subject 339 to the rights, licenses and restrictions contained in BCP 78, and 340 except as set forth therein, the authors retain all their rights. 342 Acknowledgment 344 Funding for the RFC Editor function is currently provided by the 345 Internet Society.