idnits 2.17.00 (12 Aug 2021) /tmp/idnits3977/draft-keyur-mscp-00.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): ---------------------------------------------------------------------------- ** 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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 7) being 120 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 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 33 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 114 has weird spacing: '...essages with ...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '5' on line 186 -- Looks like a reference, but probably isn't: '8' on line 207 -- Possible downref: Non-RFC (?) normative reference: ref. 'PIM-SM' ** Downref: Normative reference to an Informational RFC: RFC 1701 (ref. 'Han94a') ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. 'Han94b') Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Keyur Patel 2 Internet Draft Cisco Systems 3 Expiration Date: December 2003 Radia Perlman 4 Sun Microsystems 5 Dino Farinacci 6 Greg Shepherd 7 Procket Networks 8 Multicast Signaling Conduit Protocol 10 draft-keyur-mscp-00.txt 12 1. Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as ``work in progress.'' 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 2. Abstract 35 This document describes an approach for solving the "last-mile" problem 36 for multicast, especially SSM-style multicast, called Multicast Signaling 37 Conduit Protocol (MSCP). It is intended to facilitate an endnode whose 38 OS does not support IGMPv3, or who resides in a portion of the Internet 39 infrastructure without multicast, to join multicast groups. It is 40 especially intended for SSM-style groups, although it could be adapted 41 for use for other multicast groups. 43 3. Introduction 45 An impediment to getting SSM Multicast deployed is that, as currently 46 specified, it depends on IGMPv3. Since IGMPv3 is in the IP stack, it 47 requires endnodes to upgrade to an OS that supports IGMPv3 and it 48 requires IGMPv3 support on the first hop multicast capable routers as 49 well. This document proposes a new IP protocol known as Multicast 50 Signaling Conduit Protocol (MSCP) which eliminates the requirement of 51 running IGMPv3 both on endnodes as well as first hop multicast capable 52 routers. This draft is solely for the purpose of joining SSM-style 53 groups, i.e., groups in which the IP address of the root is explicitly 54 known by the joining host. This draft allows hosts to join SSM-style 55 groups even if 57 * the host's OS stack does not support IGMPv3 58 * the local routers do not support IGMPv3, or even multicast, and/or 59 * some routers along the path to the root do not support multicast. 61 This is achieved by defining a new user level process that runs MSCP. 62 All that is really required to join an SSM-style group with this 63 mechanism is for the joining host and the root (the "Source") to 64 support this. As more routers are upgraded to supporting this, 65 bandwidth use is minimized by utilizing multicast rather than tunnels. 67 Although in theory this style of host join could be used instead of 68 IGMP to join a non-SSM group, for non-SSM groups this design offers 69 no advantage over IGMP, since only IGMPv2, which is already widely 70 deployed, is required for joining non-SSM groups. 72 However, if an endnode does reside in a portion of the Internet 73 without any support for multicast, this mechanism could be used 74 for non-SSM groups by using an anycast address in place of an 75 explicit root address. 77 A router that does not support the messages in this draft 78 will simply forward such messages towards the destination specified 79 in the messages. The first multicast capable router that supports 80 MSCP will notice these messages and will form a tunnel with the end 81 node that generated the message. 83 4 Multicast Signaling Conduit Protocol 85 We propose a new IP multicast signaling protocol known as Multicast 86 Signaling Conduit protocol (MSCP). This protocol has an ability to 87 form multicast tunnels with specified destination address in the IP 88 header. It runs directly over IP protocol. 90 We also propose new MSCP messages with destination address in the 91 IP header as either "Source" (root of the tree) address or anycast 92 address to direct all the MSCP packets to a specific place within an 93 AS. A wellknown anycast address defined by IANA will be used 94 to transmit MSCP packets to a specified destination within an AS. 96 Multicast routers implementing MSCP should treat the receipt of MSCP 97 messages as intended for them, even though the destination address in 98 the IP header is a unicast of the tree root. To allow a router to 99 recognize a MSCP messages addressed to the unicast root address, and 100 place it on the slow path, rather than simply forwarding it towards 101 the specified destination, the packet will have the router alert option, 102 and the IP protocol type="MSCP" with version 1. 104 Usually a multicast router implementing MSCP that notices an MSCP message 105 would trap the message and create a tunnel to the node that sent the 106 MSCP Host-Join. However, in the case where the IP destination address is 107 "MSCP Anycast", the router should forward the packet towards a router that 108 advertises reachability to that address. 110 Multicast routers with MSCP support receiving MSCP Join/Prune [5] 111 messages will process them in similar way as PIM Join/Prune messages. 112 However, MSCP routers receiving MSCP Join/Prune will send 113 MSCP (Join/Prune)-Ack message back to the sender of MSCP Join/Prune 114 messages with a 4 byte cookie value. Receivers upon receipt of MSCP 115 (Join/Prune)-Ack message will respond back with MSCP Auth-Ack message 116 in which it will re-send the cookie value sent by the router. MSCP 117 routers receiving Auth-Ack for Join/Prune will then create/delete 118 interface state accordingly. 120 MSCP routers will create tunnel interfaces (refer section 6) in 121 their (S, G) oif lists when receiving MSCP Join [5] messages from 122 receivers that are not directly connected. For all the directly 123 connected receivers, MSCP routers will create interfaces in their 124 (S, G) oif lists in the same way as if an IGMP (S,G) join or a PIM 125 Join/Prune message were received. An implementation must have a 126 configured upper bound on number of tunnel interfaces that it can put 127 in oif lists of any multicast route. Multicast routers receiving such 128 MSCP Host-Join/Prune messages will process them and create state in 129 similar way as if a PIM Join/Prune (S, G) message was received. 131 All the non-multicast capable routers will simply forward such packets 132 towards the unicast source address/anycast address. Current routers 133 which receive an IP unicast packet with IP options process these packets 134 and forward them towards the unicast destination address specified in the 135 ip packet if the destination is not one of the ip addresses of the 136 routers. Otherwise, these routers forward these packets up the local 137 stack for local delivery. Therefore, current routers will forward the 138 packets destined for the unicast address of the root, to the root, 139 which is the desired behavior. 141 MSCP Routers maintaining tunnel state for (S, G) will periodically 142 query all its interested receivers by sending MSCP Query [5] messages. 143 All end-hosts willing to subscribe to a particular (S, G) group 144 will be periodically sending MSCP Host-Join [5] messages. All the MSCP 145 Host-Join/Prune [5] messages will be sent with unicast source address 146 as the destination address. All the MSCP Host-Join/Prune messages 147 will be sent with IP Router Alert option. 149 5 MSCP Messages 150 This section defines different message formats for MSCP. MSCP messages 151 are sent either unicast to a particular source or towards anycast address. 152 Each MSCP message has a fixed size header. The layout of this header is 153 shown below: 155 0 1 2 3 156 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Ver | Type | Reserved | Checksum | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 MSCP Ver 162 MSCP Version number is 1. 164 Type 165 Types for specific MSCP messages. MSCP Types are: 167 Message Type Destination 168 ------------------------------------------------------------------------- 169 0 = Query Message Unicast to Source/Anycast 170 1 = Join Message Unicast to Source/Anycast 171 2 = Join-Ack Message Unicast to Source/Anycast 172 3 = Auth Ack Unicast to Source/Anycast 173 4 = Prune Message Unicast to Source/Anycast 174 5 = Prune-Ack Message Unicast to Source/Anycast 175 6 = Data Message Unicast to Source/Anycast 177 Reserved 178 Set to zero on transmission. Ignored upon receipt. 180 Checksum 181 The checksum is a standard IP checksum, i.e. the 16-bit one's 182 complement of the one's complement sum of the entire MSCP message. 183 For computing the checksum, the checksum field is zeroed. 185 For IPv6, the checksum also includes the IPv6 "pseudo-header", as 186 specified in RFC 2460, section 8.1 [5]. This "pseudo-header" is 187 prepended to the MSCP header for the purposes of calculating the 188 checksum. The "Upper-Layer Packet Length" in the pseudo-header is 189 set to the length of the MSCP message. The Next Header value used 190 in the pseudo-header is 103. If the packet's length is not an 191 integral number of 16-bit words, the packet is padded with a byte 192 of zero before performing the checksum. 194 Encoded format for Unicast Source and Group address is shown below: 196 0 1 2 3 197 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Addr Family | Encoding Type | Unicast Address 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... 202 Addr Family 203 The MSCP address family of the 'Unicast Address' field of this 204 address. 206 Values of 0-127 are as assigned by the IANA for Internet Address 207 Families in [8]. Values 128-250 are reserved to be assigned by the 208 IANA for PIM-specific Address Families. Values 251 though 255 are 209 designated for private use. As there is no assignment authority 210 for this space, collisions should be expected. 212 Encoding Type 213 The type of encoding used within a specific Address Family. The 214 value `0' is reserved for this field, and represents the native 215 encoding of the Address Family. 217 Unicast Address 218 The unicast address as represented by the given Address Family and 219 Encoding Type. 221 5.1 MSCP Host Query message format 223 MSCP Prune-Ack messages are sent in reply to Prune message by routers 224 forming tunnels. 226 0 1 2 3 227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Unicast Router address (Encoded-Source format) | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 Unicast Router Address 233 For format description refer to Encoded-Unicast address. 235 5.2 MSCP Host-Join message format 237 MSCP Host-Joins are sent to assist building source/core trees (SPT/CBT). 239 0 1 2 3 240 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Reserved | Num Jn groups | Holdtime | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Tn Format | Multicast Source Address (Encoded format) | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Joined Group Address 1 (Encoded-Group format) | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | . | 249 | . | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Joined Group Address n (Encoded-Group format) | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Reserved 255 Transmitted as zero, ignored on receipt. 257 Number of Join Groups 258 The number of multicast group sets contained in the message. 260 Holdtime 261 The amount of time a receiver must keep the Join state alive, 262 in seconds. If the Holdtime is set to `0xffff', the receiver of 263 this message should hold the state until canceled by the 264 appropriate canceling Join message, or timed out according to 265 local policy. This may be used with dial-on-demand links, to avoid 266 keeping the link up with periodic Join/Prune messages. 268 Note that the Holdtime must be larger than the 269 J/P_Override_Interval(I) (refer to [PIM-SM]). 271 Tunnel Type 272 Specific type of Tunnel that receiver wants Router to create 273 0 (IP-in-IP), 1 (GRE). 275 Multicast Source address 276 For format description refer to Encoded-Unicast address. 278 Join Group Address 1 .. n 279 This list contains the Groups that the sending router will forward 280 multicast datagrams for if received on the interface this message 281 is sent on. 283 See Encoded-Source-Address format. 285 5.3 MSCP Host Join-Ack message format 287 MSCP Join-Ack messages are sent in reply to Join message by routers 288 forming tunnels. 290 0 1 2 3 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Reserved | Num Pr groups | Holdtime | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Tn Format | Multicast Source Address (Encoded format) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Joined Group Address 1 (Encoded-Group format) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | . | 300 | . | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Joined Group Address n (Encoded-Group format) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Cookie Value | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 Reserved 308 Transmitted as zero, ignored on receipt. 310 Number of Prune Groups 311 The number of multicast group sets contained in the message. 313 Holdtime 314 The amount of time a receiver must keep the Join state alive, 315 in seconds. If the Holdtime is set to `0xffff', the receiver of 316 this message should hold the state until canceled by the 317 appropriate canceling Join message, or timed out according to 318 local policy. This may be used with dial-on-demand links, to avoid 319 keeping the link up with periodic Join/Prune messages. 321 Note that the Holdtime must be larger than the 322 J/P_Override_Interval(I) (refer to [PIM-SM]). 324 Tunnel Type 325 Specific type of Tunnel that receiver wants Router to create 326 0 (IP-in-IP), 1 (GRE). 328 Multicast Source address 329 For format description refer to Encoded-Unicast address. 331 Join Group Address 1 .. n 332 This list contains the Groups that the sending router will forward 333 multicast datagrams for if received on the interface this message 334 is sent on. 336 See Encoded-Source-Address format. 338 Fixed four byte Key 339 Cookie value that is reflected back in Auth-Ack message. 341 5.4 MSCP Host-Prune message format 343 MSCP Host-Prunes are sent to prune source trees when members leave groups. 345 0 1 2 3 346 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Reserved | Num Pr groups | Holdtime | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Tn Format | Multicast Source Address (Encoded format) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Joined Group Address 1 (Encoded-Group format) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | . | 355 | . | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Joined Group Address n (Encoded-Group format) | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 Reserved 361 Transmitted as zero, ignored on receipt. 363 Number of Prune Groups 364 The number of multicast group sets contained in the message. 366 Holdtime 367 The amount of time a receiver must keep the Join state alive, 368 in seconds. If the Holdtime is set to `0xffff', the receiver of 369 this message should hold the state until canceled by the 370 appropriate canceling Join message, or timed out according to 371 local policy. This may be used with dial-on-demand links, to avoid 372 keeping the link up with periodic Join/Prune messages. 374 Note that the Holdtime must be larger than the 375 J/P_Override_Interval(I) (refer to [PIM-SM]). 377 Tunnel Type 378 Specific type of Tunnel that receiver is using with the Router 379 0 (IP-in-IP), 1 (GRE). 381 Multicast Source address 382 For format description refer to Encoded-Unicast address. 384 Join Group Address 1 .. n 385 This list contains the Groups that the sending router will forward 386 multicast datagrams for if received on the interface this message 387 is sent on. 389 See Encoded-Source-Address format. 391 5.5 MSCP Host Prune-Ack message format 393 MSCP Host-Prunes are sent to prune source trees when members leave groups. 395 0 1 2 3 396 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Reserved | Num Pr groups | Holdtime | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Tn Format | Multicast Source Address (Encoded format) | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Joined Group Address 1 (Encoded-Group format) | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | . | 405 | . | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Joined Group Address n (Encoded-Group format) | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Cookie Value | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 Reserved 413 Transmitted as zero, ignored on receipt. 415 Number of Prune Groups 416 The number of multicast group sets contained in the message. 418 Holdtime 419 The amount of time a receiver must keep the Join state alive, 420 in seconds. If the Holdtime is set to `0xffff', the receiver of 421 this message should hold the state until canceled by the 422 appropriate canceling Join message, or timed out according to 423 local policy. This may be used with dial-on-demand links, to avoid 424 keeping the link up with periodic Join/Prune messages. 426 Note that the Holdtime must be larger than the 427 J/P_Override_Interval(I) (refer to [PIM-SM]). 429 Tunnel Type 430 Specific type of Tunnel that receiver is using with the Router 431 0 (IP-in-IP), 1 (GRE). 433 Multicast Source address 434 For format description refer to Encoded-Unicast address. 436 Join Group Address 1 .. n 437 This list contains the Groups that the sending router will forward 438 multicast datagrams for if received on the interface this message 439 is sent on. 441 See Encoded-Source-Address format. 443 Fixed four byte Key 444 Cookie value that is reflected back in Auth-Ack message. 446 5.6 MSCP Host Auth-Ack message format 448 MSCP Prune-Ack messages are sent in reply to Prune message by routers 449 forming tunnels. 451 0 1 2 3 452 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Reserved | Prune/Joine | Cookie Value | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Cookie Value | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Reserved 460 Transmitted as zero, ignored on receipt. 462 Prune/Join 463 Auth message sent in respone to 0 (Join-Ack) 1 (Prune-Ack). 465 Fixed four byte Key 466 Cookie value that is reflected back in Auth-Ack message. 468 6. Tunnel Interfaces 469 Because not all intermediate routers support native ip multicast, 470 MSCP requires all the oifs on which it receives MSCP Host-Join/Prunes 471 messages from receivers which are not directly connected to be created 472 as tunnel interfaces. In practice, tunnels typically use either IP-IP 473 [Perk96] or Generic Routing Encapsulation (GRE) [Han94a,Han94b], 474 although, other encapsulation methods are acceptable. 476 7. Security Considerations 478 MSCP does not change any multicast security issues. PIM is open to many 479 types of resource overload. For instance, a node which transmits from 480 many bogus source addresses will cause PIM routers to join to many (S,G) 481 pairs, eventually exhausting state. PIM routers must protect themselves 482 by limiting the amount of state for multicast, so that a denial of 483 service attack on multicast will not destroy unicast. 485 With LAN-based IGMP joins, only nodes on the LAN can initiate a join, 486 so if the LAN is physically protected, and all routers along the 487 path to the RP (or S in an (S,G) join) are trusted, it might be 488 somewhat harder for a node to create join state untraceably than 489 it would with this tunnel proposal. With this tunnel proposal, 490 the join message is sent over a multi-hop path. 492 As stated in the document, a router is configured with a maximum 493 number of tunnels it is willing to accept, so an attack to deplete 494 its tunnel resources will only affect attempts to create tunnels, 495 and not cause any other denial of service. 497 Additionally, the router to whom tunnels will be created is likely 498 to be the entry router at an ISP, and it can consider an entire customer 499 network to be a LAN. If suspiciously many tunnels are being created 500 from that customer network, the router can start discriminating against 501 joins from that customer network, when resources are being depleted. 503 Eventually, cryptographic authentication can be added between the 504 joiner and the router, by having potential joiners obtain a key (or 505 certificate) from the router before they are allowed to join, and 506 having join messages cryptographically authenticated. 508 8. Acknowledgements 510 We express our thanks to Alex Zinin, Dino Farinacci, Lorenzo Vicisano, 511 liming Wei, Tom Pusateri, and Nidhi Bhaskar for their review and comments. 513 9. References 515 [PIM-SM] Bill Fenner, Mark Handley, Hugh Holbrook, Isidor Kouvelas, 516 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 517 Protocol Specification (Revised)". 519 [Han94a] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic 520 Routing Encapsulation", RFC 1701, NetSmiths, Ltd., and 521 cisco Systems, October 1994. 523 [Han94b] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 524 Routing Encapsulation over IPv4 networks", RFC 1702, 525 NetSmiths, Ltd., cisco Systems, October 1994. 527 [Perk96] Perkins, C., "IP Encapsulation within IP", RFC 2003, 528 October 1996. 530 10. Author Information 532 Keyur Patel 533 Cisco Systems. Inc. 534 email: keyur@ayrnetworks.com 536 Radia Perlman 537 Sun Microsystems. Inc. 538 email: Radia.Perlman@sun.com 540 Dino Farinacci 541 Procket Networks Inc. 542 email: dino@procket.com 544 Greg Shepherd 545 Procket Networks Inc. 546 email: shep@procket.com