idnits 2.17.1 draft-ietf-pim-anycast-rp-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. Found some kind of copyright notice around line 34 but it does not match any copyright boilerplate known by this tool. 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 8 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 9 pages 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. 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 21, 2004) is 7248 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: 'RFC2119' is mentioned on line 66, but not defined == Unused Reference: 'I2' is defined on line 341, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2362 (ref. 'N1') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-v2-new-09 -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. 'I3') (Obsoleted by RFC 4301) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dino Farinacci 3 INTERNET-DRAFT Procket Networks 4 Expiration Date: December 2004 Yiqun Cai 5 cisco Systems 6 June 21, 2004 8 Anycast-RP using PIM 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC3668. 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 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This specification allows Anycast-RP (Rendezvous Point) to be used 39 inside a domain, which runs Protocol Independent Multicast (PIM) 40 only. There are no other multicast protocols required to support 41 Anycast-RP, such as MSDP, which has been used traditionally to solve 42 this problem. 44 1.0 Introduction 46 Anycast-RP as described in [I1] is a mechanism ISP-based backbones 47 have used to get fast convergence when a PIM Rendezvous Point (RP) 48 router fails. To allow receivers and sources to Rendezvous to the 49 closest RP, the packets from a source needs to get to all RPs to find 50 joined receivers. 52 This notion of receivers finding sources is the fundamental problem 53 of source discovery which MSDP was intended to solve. However, if one 54 would like to retain the Anycast-RP benefits from [I1] with less 55 protocol machinery, removing MSDP from the solution space is an 56 option. 58 This memo extends the Register mechanism in PIM so Anycast-RP 59 functionality can be retained without using MSDP. 61 1.1 Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 2.0 Requirements 69 o Each router acting as an RP MUST be configured with a loopback 70 interface using the same (shared) IP address. This address is used 71 to tell other routers in the PIM domain what IP address to use 72 for the RP address. 74 o The RP address or a prefix that covers the RP address is injected 75 into the unicast routing system inside of the domain. 77 o Each RP configures all other RPs used in the Anycast-RP set. This 78 must be consistently configured in all RPs in the set. 80 3.0 Mechanism 82 The following diagram illustrates a domain using 3 RPs where 83 receivers are joining to the closest RP according to where unicast 84 routing metrics take them and 2 sources sending packets to their 85 respective RPs. 87 S1-----RP1 RP2 RP3------S3 88 / \ | 89 / \ | 90 R1 R1' R2 92 Assume the above scenario is completely connected where R1, R1', and 93 R2 are receivers for a group, and S1 and S2 send to that group. 94 Assume RP1, RP2 and RP3 are all assigned the same IP address which is 95 used as the Anycast-RP address (let's say the IP address is RPA). 97 Note, the address used for the RP address in the domain (the Anycast- 98 RP address) needs to be a different than the addresses used by the 99 Ancyast-RP routers to communicate with each other. 101 The following procedure is used when S1 starts sourcing traffic: 103 o S1 sends a multicast packet. 105 o The DR directly attached to S1 will form a PIM Register message to 106 send to RP1. The IP address to use is the Anycast-RP address. 108 o RP1 will receive the PIM Register message, decapsulate it, send the 109 packet down the shared-tree to get the packet to receivers R1 and 110 R1'. 112 o RP1 is configured with RP2 and RP3's IP address. It will forward 113 the Register message from S1's DR to both of them. RP1 will 114 use its own IP address as the source address for the PIM Register 115 message. 117 o RP1 sends a Register-Stop back to the DR. 119 o RP1 MAY join back to the source-tree by triggering a (S1,G) Join 120 message toward S1. However, RP1 MUST create (S1,G) state. 122 o RP2 receives the Register message from RP1, decapsulates it, and 123 also sends the packet down the shared-tree to get the packet to 124 receiver R2. 126 o RP2 sends a Register-Stop back to the RP1. RP1 processes the 127 Register-Stop just like it would if it was a DR. 129 o RP2 MAY join back to the source-tree by triggering a (S1,G) Join 130 message toward S1. However, RP2 MUST create (S1,G) state. 132 o RP3 receives the Register message from RP1, decapsulates it, but 133 since there are no receivers joined for the group, it can discard 134 the packet. 136 o RP3 sends a Register-Stop back to the RP1. 138 o RP3 creates (S1,G) state so when a receiver joins after S1 starts 139 sending, RP3 can join quickly to the source-tree for S1. 141 The procedure for S3 sending follows the same as above but it is RP3 142 which forwards the Register originated by S3's DR to RP1 and RP2. 143 Therefore, this example shows how sources anywhere in the domain, 144 associated with different RPs, can reach all receivers, also 145 associated with different RPs, in the same domain. 147 4.0 Observations and Guidelines about this Proposal 149 o An RP will forward a Register only if the Register is received 150 from an IP address not in the Anycast-RP list (i.e. the Register 151 came from a DR and not another RP). 153 o Each DR that PIM registers for a source will send the message to 154 it's closest RP address. Therefore there are no changes to the 155 DR logic. 157 o Packets flow to all receivers no matter what RP they have joined 158 to. 160 o The source gets Registered to a single RP by the DR, it's the 161 responsibility of the RP, the DR selects (based on routing 162 metrics), to get the packet to all other RPs in the Anycast-RP 163 set. 165 o Logic is changed only in the RPs. The logic change is for 166 forwarding Register messages. Register-Stop processing is 167 unchanged. However, an implementation MAY suppress sending 168 Register-Stop messages in response to a Register received from 169 an RP. 171 o The rate-limiting of Register and Register-Stop messages are done 172 end-to-end. That is from DR -> RP1 -> {RP2 and RP3}. There is no 173 need for specific rate-limiting logic between the RPs. 175 o When topology changes occur, the existing source-tree adjusts as it 176 does today according to [N1]. The existing shared-trees, as well, 177 adjust as it does today according to [N1]. 179 o Physical RP changes are as fast as unicast route convergence. 180 Retaining the benefit of [I1]. 182 o An RP that doesn't support this specification can be mixed with RPs 183 that do support this specification. However, the non-supporter RPs 184 should not have sources registering to it but may have receivers 185 joined to it. 187 o If Null Registers are sent (Registers with an IP header and no IP 188 payload), they MUST be replicated to all of the RPs in the Anycast- 189 RP set so that source state remains alive for active sources. 191 o The number of RPs in the Anycast-RP set should remain small so the 192 amount of non-native replication is kept to a minimum. 194 5.0 Interaction with MSDP running in an Anycast-PIM Router 196 The objective of this Anycast-PIM proposal is to remove the 197 dependence on using MSDP. This can be achieved by removing MSDP 198 peering between the Anycast RPs. However, to advertise internal 199 sources to routers outside of a PIM routing domain and to learn 200 external sources from other routing domains, MSDP may still be 201 required. 203 5.1 Anycast-PIM Stub Domain Functionality 205 In this capacity, when there are internal sources that need to be 206 advertised externally, an Anycast-RP which receives a Register 207 message, either from a DR or an Anycast-RP, should process it as 208 described in this specification as well as how to process a Register 209 message as described in [N1]. That means an SA for the same internal 210 source could be originated by multiple Anycast-RPs doing the MSDP 211 peering. There is nothing inherently wrong with this other than the 212 source is being advertised into the MSDP infrastructure from multiple 213 places from the source domain. However, if this is not desirable, 214 configuration of one or more (rather than all) Anycast-RP MSDP 215 routers would allow only those routers to originate SAs for the 216 internal source. And in some situations, there is a good possibility 217 not all Anycast-RPs in the set will have MSDP peering sessions so 218 this issue can be mitigated to a certain extent. 220 From an Anycast-RP perspective, a source should be considered 221 internal to a domain, when it is discovered by an Anycast-RP through 222 a received Register message. Regardless, if the Register message was 223 sent by a DR, another Anycast-RP member, or the router itself. 225 For learning sources external to a domain, the MSDP SA messages could 226 arrive at multiple MSDP-peering Anycast-RPs. The rules for processing 227 an SA, according to [I1], should be followed. That is, if G is joined 228 in the domain, an (S,G) join is sent towards the source. And if data 229 accompanies the SA, each Anycast-PIM RP doing MSDP peering will 230 forward the data down each of their respective shared-trees. 232 The above assumes each Anycast-RP has external MSDP peering 233 connections. If this is not the case, the Anycast-PIM routers with 234 the MSDP peering connections would follow the same procedure as if a 235 Data-Register or Null-Register was received from either a DR or 236 another Anycast-RP. That is, they would send Registers to the other 237 members of the Anycast-RP set. 239 If there is a mix of Anycast-RPs that do and do not have external 240 MSDP peering connections, then the ones that do must be configured 241 with the set that do not. So Register messages are sent only to the 242 members of the Anycast-RP set that do not have external MSDP peering 243 connections. 245 5.2 Anycast-PIM Transit Domain Functionality 247 Within a routing domain, it is recommended that an Anycast-RP set 248 defined in this specification should not be mixed with MSDP peering 249 among the members. In some cases, the source discovery will work but 250 it may not be obvious to the implementations what sources are local 251 to the domain and which are not. This may affect external MSDP 252 advertisement of internal sources. 254 Having said that, this draft makes no attempt to connect MSDP peering 255 domains together by using Anycast-PIM inside a transit domain. 257 6.0 IANA Considerations 259 This document makes no request to IANA. 261 Note to RFC Editor: this section may be removed on publication as an 262 RFC. 264 7.0 Security Consideration 266 This section describes the security consideration for Register and 267 Register-Stop messages between Anycast-RPs. For PIM messages between DR 268 and RP, please see [I3]. 270 7.1 Attack Based On Forged Messages 272 An attacker may forge a Register message using one of the addresses 273 in the Anycast-RP list in order to achieve one or more of the 274 following effects: 276 1. Overwhelm the target RP in a denial-of-service attack 277 2. Inject unauthorized data to receivers served by the RP 278 3. Inject unauthorized data and create bogus SA entries in other 279 PIM domains if the target RP has external MSDP peerings 281 An attacker may also forge a Register-Stop message using one of the 282 addresses in the Anycast-RP list. However, besides denial-of- 283 service, the effect of such an attack is limited because an RP 284 usually ignores Register-Stop messages. 286 7.2 Protect Register and Register-Stop Messages 288 The DOS attack using forged Register or Register-Stop messages can 289 not be prevented. But the RP can still be protected. For example, 290 the RP can rate-limit incoming messages. It can also choose to 291 refuse to process any Register-Stop messages. The actual protection 292 mechansim is implementation specific. 294 The distribution of unauthorized data and bogus SA entries can be 295 prevented using the method recommended in [I3]. That is IPsec [I3] 296 transport mode using the Authentication Header (AH). 298 There are two options a network administrator can choose from. An RP 299 can be configured using a unique SA and SPI for traffic (Registers or 300 Register-Stops) to each member of Anycast-RPs in the list. 301 Alternatively, a single authentication algorithm and associated 302 parameters can be used for the entire Anycast-RP set in order to 303 reduce the overhead of key distribution. 305 8.0 Acknowledgments 307 The authors would like to thank Yiqun Cai and Dino Farinacci for 308 prototyping this draft in the cisco IOS and Procket implementations, 309 respectively. 311 The authors would like to thank John Zwiebel for doing 312 interoperability testing of the two prototype implementations. 314 And finally, the authors would like to thank Greg Shepard from 315 Procket Networks, Lenny Giuliano from Juniper Networks, Prashant 316 Jhingran from Huawei Technologies, and Pekka Savola from CSC/FUNET, 317 for their comments on earlier drafts. 319 9.0 Author Information 321 Dino Farinacci 322 Procket Networks 323 dino@procket.com 325 Yiqun Cai 326 cisco Systems 327 ycai@cisco.com 329 10.0 References 331 10.1 Normative References 333 [N1] Estrin, et al., "Protocol Independent Multicast-Sparse Mode (PIM- 334 SM): Protocol Specification", RFC 2362, June 1998. 336 10.2 Informative References 338 [I1] Kim, Meyer, Kilmer, Farinacci, "Anycast RP mechanism using PIM 339 and MSDP", RFC 3446, January 2003. 341 [I2] Fenner, Handley, Holbrook, Kouvelas, "Protocol Independent 342 Multicast - Sparse Mode (PIM-SM):Protocol Specification 343 (Revised)", Internet Draft draft-ietf-pim-sm-v2-new-09.txt, 344 February 2004. 346 [I3] Kent, "Security Architecture for the Internet Protocol", RFC 347 2401, November 1998. 349 Appendix A - Possible Configuration Language 351 A possible set of commands to be used could be: 353 ip pim anycast-rp 355 Where: 357 describes the Anycast-RP set for the RP which 358 is assigned to the group range. This IP address is the address 359 that first-hop and last-hop PIM routers use to register and join 360 to. 362 describes the IP address where Register messages are 363 forwarded to. This IP address is any address assigned to the RP 364 router not including the . 366 Example: 368 From the illustration above, the configuration commands would be: 370 ip pim anycast-rp RPA RP1 371 ip pim anycast-rp RPA RP2 372 ip pim anycast-rp RPA RP3 374 Comment: 376 It may be useful to include the local router's IP address in the 377 command set so the above lines can be cut-and-pasted or scripted 378 into all the RPs in the Anycast-RP set. 380 But the implementation would have to be aware of it's own address 381 and not inadvertently send a Register to itself.