idnits 2.17.1 draft-ietf-pim-port-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1060 has weird spacing: '...Capable thi...' -- 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 (August 29, 2011) is 4624 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Duplicate reference: RFC4601, mentioned in 'HELLO-OPT', was also mentioned in 'RFC4601'. -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'HELLO-OPT') (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft IJ. Wijnands 4 Intended status: Experimental S. Venaas 5 Expires: March 1, 2012 cisco Systems 6 M. Napierala 7 AT&T Labs 8 August 29, 2011 10 A Reliable Transport Mechanism for PIM 11 draft-ietf-pim-port-08.txt 13 Abstract 15 This document defines a reliable transport mechanism for the PIM 16 protocol for transmission of Join/Prune messages. This eliminates 17 the need for periodic Join/Prune message transmission and processing. 18 The reliable transport mechanism can use either TCP or SCTP as the 19 transport protocol. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 1, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 57 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 59 3. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 8 61 3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 9 62 3.3. Interface ID . . . . . . . . . . . . . . . . . . . . . . . 10 63 4. Establishing Transport Connections . . . . . . . . . . . . . . 11 64 4.1. Connection Security . . . . . . . . . . . . . . . . . . . 13 65 4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 13 66 4.3. Actions When a Connection Goes Down . . . . . . . . . . . 15 67 4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 15 68 4.5. On-demand versus Pre-configured Connections . . . . . . . 16 69 4.6. Possible Hello Suppression Considerations . . . . . . . . 16 70 4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 17 71 5. PORT Message Definitions . . . . . . . . . . . . . . . . . . . 18 72 5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 19 73 5.2. PORT Keep-alive Message . . . . . . . . . . . . . . . . . 20 74 5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 21 75 5.3.1. PIM IPv4 Join/Prune Option . . . . . . . . . . . . . . 22 76 5.3.2. PIM IPv6 Join/Prune Option . . . . . . . . . . . . . . 22 77 6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 24 78 7. Multiple Address-Family Support . . . . . . . . . . . . . . . 25 79 8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 26 80 9. Manageability Considerations . . . . . . . . . . . . . . . . . 27 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 83 11.1. PORT Port Number . . . . . . . . . . . . . . . . . . . . . 29 84 11.2. PORT Hello Options . . . . . . . . . . . . . . . . . . . . 29 85 11.3. PORT Message Type Registry . . . . . . . . . . . . . . . . 29 86 11.4. PORT Option Type Registry . . . . . . . . . . . . . . . . 29 87 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 88 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 89 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 90 14.1. Normative References . . . . . . . . . . . . . . . . . . . 33 91 14.2. Informative References . . . . . . . . . . . . . . . . . . 33 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 94 1. Introduction 96 The goals of this specification are: 98 o To create a simple incremental mechanism to provide reliable PIM 99 Join/Prune message delivery in PIM version 2 for use with PIM 100 Sparse-Mode [RFC4601] (including Source-Specific Multicast) and 101 Bidirectional PIM [RFC5015]. 103 o When a router supports this specification, it need not use the 104 reliable transport mechanism with every neighbor. It can be 105 negotiated on a per neighbor basis. 107 The explicit non-goals of this specification are: 109 o Changes to the PIM message formats as defined in [RFC4601]. 111 o Provide support for automatic switching between the reliable 112 transport mechanism and the regular PIM mechanism defined in 113 [RFC4601]. Two routers that are PIM neighbors on a link will 114 always use the reliable transport mechanism if and only if both 115 have enabled support for the reliable transport mechanism. 117 This document will specify how periodic Join/Prune message 118 transmission can be eliminated by using TCP [RFC0793] or SCTP 119 [RFC4960] as the reliable transport mechanism for Join/Prune 120 messages. 122 This specification enables greater scalability in terms of control 123 traffic overhead. However, for routers connected to multi-access 124 links that comes at the price of increased PIM state and the overhead 125 required to maintain this state. 127 In many existing and emerging networks, particularly wireless and 128 mobile satellite systems, link degradation due to weather, 129 interference, and other impairments can result in temporary spikes in 130 the packet loss. In these environments, periodic PIM joining can 131 cause join latency when messages are lost causing a retransmission 132 only 60 seconds later. By applying a reliable transport, a lost join 133 is retransmitted rapidly. Furthermore, when the last user leaves a 134 multicast group, any lost prune is similarly repaired and the 135 multicast stream is quickly removed from the wireless/satellite link. 136 Without a reliable transport, the multicast transmission could 137 otherwise continue until it timed out, roughly 3 minutes later. As 138 network resources are at a premium in many of these environments, 139 rapid termination of the multicast stream is critical for maintaining 140 efficient use of bandwidth. 142 This is an experimental extension to PIM. It makes some fundamental 143 changes to how PIM works in that Join/Prune state does not require 144 periodic updates, and partly turns PIM into a hard-state protocol. 145 Also, using reliable delivery for PIM messages is a new concept, and 146 it is likely that experiences from early implementations and 147 deployments will lead to at least minor changes in the protocol. It 148 should be considered making this a standards track protocol once 149 there is some deployment experience. Experiments using this protocol 150 only require support by pairs of PIM neighbors, and need not be 151 constrained to isolated networks. 153 1.1. Requirements Notation 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 1.2. Definitions 161 PORT: Stands for PIM Over Reliable Transport. Which is the short 162 form for describing the mechanism in this specification where PIM 163 can use the TCP or SCTP transport protocol. 165 Periodic Join/Prune message: A Join/Prune message sent periodically 166 to refresh state. 168 Incremental Join/Prune message: A Join/Prune message sent as a 169 result of state creation or deletion events. Also known as a 170 triggered message. 172 Native Join/Prune message: A Join/Prune message that is carried 173 with an IP protocol type of PIM. 175 PORT Join/Prune message: A Join/Prune message using TCP or SCTP for 176 transport. 178 Datagram Mode: The procedures whereby PIM uses by encapsulates 179 Join/Prune messages in IP packets sent either triggered or 180 periodically. 182 PORT Mode: Procedures used by PIM defined in this specification for 183 sending Join/Prune messages over the TCP or SCTP transport layer. 185 2. Protocol Overview 187 PIM Over Reliable Transport (PORT) is a simple extension to PIMv2 for 188 refresh reduction of PIM Join/Prune messages. It involves sending 189 incremental rather than periodic Join/Prune messages over a TCP/SCTP 190 connection between PIM neighbors. 192 PORT only applies to PIM Sparse-Mode [RFC4601] and Bidirectional PIM 193 [RFC5015] Join/Prune messages. 195 This document does not restrict PORT to any specific link types. 196 However, the use of PORT on e.g. multi-access LANs with many PIM 197 neighbors should be carefully evaluated. This due to the fact that 198 there may be a full mesh of PORT connections, and that explicit 199 tracking of all PIM PORT routers is required. 201 PORT can be incrementally used on a link between PORT capable 202 neighbors. Routers that are not PORT capable can continue to use PIM 203 in Datagram Mode. PORT capability is detected using new PORT Capable 204 PIM Hello Options. 206 Once PORT is enabled on an interface and a PIM neighbor also 207 announces that it is PORT enabled, only PORT Join/Prune messages will 208 be used. That is, only PORT Join/Prune messages are accepted from, 209 and sent to, that particular neighbor. Native Join/Prune messages 210 are still used for PIM neighbors that are not PORT enabled. 212 PORT Join/Prune messages are sent using a TCP/SCTP connection. When 213 two PIM neighbors are PORT enabled, both for TCP or both for SCTP, 214 they will immediately, or on-demand, establish a connection. If the 215 connection goes down, they will again immediately, or on-demand, try 216 to reestablish the connection. No Join/Prune messages (neither 217 Native nor PORT) are sent while there is no connection. Also, any 218 received native Join/Prune messages from that neighbor are discarded, 219 even when the connection is down. 221 When PORT is used, only incremental Join/Prune messages are sent from 222 downstream routers to upstream routers. As such, downstream routers 223 do not generate periodic Join/Prune messages for state for which the 224 RPF neighbor is PORT-capable. 226 For Joins and Prunes, which are received over a TCP/SCTP connection, 227 the upstream router does not start or maintain timers on the outgoing 228 interface entry. Instead, it keeps track of which downstream routers 229 have expressed interest. An interface is deleted from the outgoing 230 interface list only when all downstream routers on the interface, no 231 longer wish to receive traffic. If there also are native joins/ 232 prunes from non-PORT neighbor, then one can maintain timers on the 233 outgoing interface entry as usual, while at the same time keep track 234 of each of the downstream PORT joins/prunes. 236 This document does not update the PIM Join/Prune packet format. In 237 the procedures described in this document, each PIM Join/Prune 238 message is included in the payload of a PORT message carried over 239 TCP/SCTP. See section Section 5 for details on the PORT message. 241 3. PIM Hello Options 243 3.1. PIM over the TCP Transport Protocol 245 Option Type: PIM-over-TCP Capable 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Type = 27 | Length = 4 + X | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | TCP Connection ID AFI | Reserved | Exp | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | TCP Connection ID | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Allocated Hello Type values can be found in [HELLO-OPT]. 259 When a router is configured to use PIM over TCP on a given interface, 260 it MUST include the PIM-over-TCP Capable hello option in its Hello 261 messages for that interface. If a router is explicitly disabled from 262 using PIM over TCP, it MUST NOT include the PIM-over-TCP Capable 263 hello option in its Hello messages. 265 All Hello messages containing the PIM-over-TCP Capable hello option, 266 MUST also contain the Interface ID hello option, see section 267 Section 3.3. 269 Implementations MAY provide a configuration option to enable or 270 disable PORT functionality. It is RECOMMENDED that this capability 271 be disabled by default. 273 Length: Length in bytes for the value part of the Type/Length/Value 274 encoding; where X is the number of bytes that make up the 275 Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is 276 used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 if AFI of 277 value 0 is used. 279 TCP Connection ID AFI: The AFI value to describe the address-family 280 of the address of the TCP Connection ID field. When this field is 281 0, a mechanism outside the scope of this document is used to 282 obtain the addresses used to establish the TCP connection. 284 Reserved: Set to zero on transmission and ignored on receipt. 286 Exp: For experimental use [RFC3692]. One expected use of these 287 bits would be to signal experimental capabilities. E.g. if a 288 router supports an experimental feature, it may set a bit to 289 indicate this. The default behavior, unless a router supports a 290 particular experiment, is to ignore the bits on receipt. 292 TCP Connection ID: An IPv4 or IPv6 address used to establish the 293 TCP connection. This field is omitted (length 0) for the 294 Connection ID AFI 0. 296 3.2. PIM over the SCTP Transport Protocol 298 Option Type: PIM-over-SCTP Capable 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type = 28 | Length = 4 + X | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | SCTP Connection ID AFI | Reserved | Exp | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | SCTP Connection ID | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Allocated Hello Type values can be found in [HELLO-OPT]. 312 When a router is configured to use PIM over SCTP on a given 313 interface, it MUST include the PIM-over-SCTP Capable hello option in 314 its Hello messages for that interface. If a router is explicitly 315 disabled from using PIM over SCTP, it MUST NOT include the PIM-over- 316 SCTP Capable hello option in its Hello messages. 318 All Hello messages containing the PIM-over-SCTP Capable hello option, 319 MUST also contain the Interface ID hello option, see section 320 Section 3.3. 322 Implementations MAY provide a configuration option to enable or 323 disable PORT functionality. It is RECOMMENDED that this capability 324 be disabled by default. 326 Length: Length in bytes for the value part of the Type/Length/Value 327 encoding; where X is the number of bytes that make up the 328 Connection ID field. X is 4 when AFI of value 1 (IPv4) [AFI] is 329 used, 16 when AFI of value 2 (IPv6) [AFI] is used, and 0 if AFI of 330 value 0 is used. 332 SCTP Connection ID AFI: The AFI value to describe the address- 333 family of the address of the SCTP Connection ID field. When this 334 field is 0, a mechanism outside the scope of this document is used 335 to obtain the addresses used to establish the SCTP connection. 337 Reserved: Set to zero on transmission and ignored on receipt. 339 Exp: For experimental use [RFC3692]. One expected use of these 340 bits would be to signal experimental capabilities. E.g. if a 341 router supports an experimental feature, it may set a bit to 342 indicate this. The default behavior, unless a router supports a 343 particular experiment, is to ignore the bits on receipt. 345 SCTP Connection ID: An IPv4 or IPv6 address used to establish the 346 SCTP connection. This field is omitted (length 0) for the 347 Connection ID AFI 0. 349 3.3. Interface ID 351 All Hello messages containing PIM-over-TCP Capable or PIM-over-SCTP 352 Capable hello options, MUST also contain the Interface ID hello 353 option [I-D.ietf-pim-hello-intid]. 355 The Interface ID is used to associate a PORT Join/Prune message with 356 the PIM neighbor that it is coming from. When unnumbered interfaces 357 are used or when a single Transport connection is used for sending 358 and receiving Join/Prune messages over multiple interfaces, the 359 Interface ID is used to convey the interface from Join/Prune message 360 sender to Join/Prune message receiver. The value of the Interface ID 361 hello option in Hellos sent on an interface, MUST be the same as the 362 Interface ID value in all PORT Join/Prune messages sent to a PIM 363 neighbor on that interface. 365 The Interface ID need only uniquely identify an interface of a 366 router, it does not need to identify which router the interface 367 belongs to. This means that the Router ID part of the Interface ID 368 MAY be 0. For details on the Router ID and the value 0, see 369 [I-D.ietf-pim-hello-intid]. 371 4. Establishing Transport Connections 373 While a router interface is PORT enabled, a PIM-over-TCP or a PIM- 374 over-SCTP option MUST be included in the PIM Hello messages sent on 375 that interface. When a router on a PORT-enabled interface receives a 376 Hello message containing a PIM-over-TCP/PIM-over-SCTP Option from a 377 new neighbor, or an existing neighbor that did not previously include 378 the option, it switches to PORT mode for that particular neighbor. 380 When a router switches to PORT mode for a neighbor, it stops sending 381 and accepting Native Join/Prune messages for that neighbor. Any 382 state from previous Native Join/Prune messages is left to expire as 383 normal. It will also attempt to establish a Transport connection 384 (TCP or SCTP) with the neighbor. If both the router and its neighbor 385 have announced both PIM-over-TCP and PIM-over-SCTP options, SCTP MUST 386 be used. This resolves the issue where two transports are both 387 offered. The method prefers SCTP over TCP, because SCTP has benefits 388 such as call collision handling and support for multiple streams, as 389 discussed later in this document. 391 When the router is using TCP, it will compare the TCP Connection ID 392 it announced in the PIM-over-TCP Capable Option with the TCP 393 Connection ID in the Hello received from the neighbor. Unless 394 connections are opened on-demand (see below), the router with the 395 lower Connection ID MUST do an active Transport open to the neighbor 396 Connection ID. The router with the higher Connection ID MUST do a 397 passive Transport open. An implementation MAY open connections only 398 on-demand, in that case it may be that the neighbor with the higher 399 Connection ID does the active open, see Section 4.5. If the router 400 with the lower Connection ID chooses to only do an active open on- 401 demand, it MUST do a passive open, allowing for the neighbor to 402 initiate the connection. Note that the source address of the active 403 open MUST be the announced Connection ID. 405 When the router is using SCTP, the IP address comparison need not be 406 done since the SCTP protocol can handle call collision. 408 If PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello 409 messages MUST be sent, both containing PORT Hello options. If two 410 neighbors announce the same transport (TCP or SCTP) and the same 411 Connection ID in the IPv4 and IPv6 Hello messages, then only one 412 connection is established and is shared. Otherwise, two connections 413 are established and are used separately. 415 The PIM router that performs the active open initiates the connection 416 with a locally generated source transport port number and a well- 417 known destination transport port number. The PIM router that 418 performs the passive open listens on the well-known local transport 419 port number and does not qualify the remote transport port number. 420 See Section 5 for well-known port number assignment for PORT. 422 When a Transport connection is established (or reestablished), the 423 two routers MUST both send a full set of Join/Prune messages for 424 state for which the other router is the upstream neighbor. This is 425 needed to ensure that the upstream neighbor has the correct state. 426 When moving from Datagram mode, or when the connection has gone down, 427 the router cannot be sure that all the previous Join/Prune state was 428 received by the neighbor. Any state created before the connection 429 was established (or reestablished) that is not refreshed, MUST be 430 left to expire and be deleted. When the non-refreshed state has 431 expired and been deleted, the two neighbors will be in sync. 433 When not running PORT, a full update is only needed when a router 434 restarts, with PORT it must be done every time a connection is 435 established. This can be costly, although it is expected that it is 436 a rare event for a PORT connection to go up and down. There may be a 437 need for extensions to better handle this. 439 It is possible that a router starts sending Hello messages with a new 440 Connection ID, e.g. due to configuration changes. A router MUST 441 always use the last announced and last seen Connection IDs. A 442 connection is identified by the local Connection ID (the one we are 443 announcing on a particular interface), and the remote Connection ID 444 (the one we are receiving from a neighbor on the same interface). 445 When either the local or remote ID changes, the Connection ID pair we 446 need a connection for changes. There may be an existing connection 447 with the same pair, in which case the router will share that 448 connection. Or a new connection may need to be established. Note 449 that for link-local addresses, the interface should be regarded as 450 part of the ID, so that connection sharing is not attempted when the 451 same link-local addresses are seen on different interfaces. 453 When a Connection ID changes, if the previously used connection is 454 not needed (there are no other PIM neighborships using the same 455 Connection ID pair), both peers MUST attempt to reset the transport 456 connection. Next (even if the old connection is still needed), they 457 MUST, unless a connection already exists with the new Connection ID 458 pair, immediately or on-demand attempt to establish a new connection 459 with the new Connection ID pair. 461 Normally the Interface ID would not change while a connection is up. 462 However, if it does, it does not affect the connection. It just 463 means that when subsequent PORT join/prune messages are received, 464 they should be matched against the last seen Interface ID. 466 Note that, a Join sent over a Transport connection will only be seen 467 by the upstream router, and thus will not cause routers on the link 468 that do not use PIM PORT with the upstream router to possibly delay 469 the refresh of Join state for the same state. Similarly, a Prune 470 sent over a Transport connection will only be seen by the upstream 471 router, and will thus never cause routers on the link that do not use 472 PIM PORT with the upstream router, to send a Join to override this 473 Prune. 475 Note also, that a datagram PIM Join/Prune message for a said (S,G) or 476 (*,G) sent by some router on a link will not cause routers on the 477 same link that use a Transport connection with the upstream router 478 for that state, to suppress the refresh of that state to the upstream 479 router (because they don't need to periodically refresh this state) 480 or to send a Join to override a Prune (as the upstream router will 481 only stop forwarding the traffic when all joined routers that use a 482 Transport connection have explicitly sent a Prune for this state, as 483 explained in Section 6). 485 4.1. Connection Security 487 TCP/SCTP packets used for PORT MUST be sent with a TTL/Hop Limit of 488 255 to facilitate enabling of the Generalized TTL Security Mechanism 489 (GTSM) [RFC5082]. Implementations SHOULD provide a configuration 490 option to enable the GTSM check at the receiver. This means checking 491 that inbound packets from directly connected neighbors have a TTL/Hop 492 Limit of 255, but MAY also allow for a different TTL/Hop Limit 493 threshold to check that the sender is within a certain number of 494 router hops. The GTSM check SHOULD be disabled by default. 496 Implementations SHOULD support the TCP Authentication Option (TCP-AO) 497 [RFC5925] and SCTP Authenticated Chunks [RFC4895]. 499 4.2. Connection Maintenance 501 TCP is designed to keep connections up indefinitely during a period 502 of network disconnection. If a PIM-over-TCP router fails, the TCP 503 connection may stay up until the neighbor actually reboots, and even 504 then it may continue to stay up until you actually try to send the 505 neighbor some information. This is particularly relevant to PIM, 506 since the flow of Join/Prune messages might be in only one direction, 507 and the downstream neighbor might never get any indication via TCP 508 that the other end of the connection is not really there. 510 SCTP has a heart beat mechanism that can be used to detect that a 511 connection is working, even when no data is sent. 513 One can detect that a PORT connection is not working by regularly 514 sending PORT messages. This applies to both TCP and SCTP. E.g., for 515 TCP the connection will be reset if no TCP ACKs are received after a 516 few retries. PORT in itself does not require any periodic signaling. 517 PORT Join/Prune messages are only sent when there is a state change. 518 If the state changes are not frequent enough, a PORT Keep-Alive 519 message (defined in Section 5.2) can be sent instead. E.g., if an 520 implementation wants to send a PORT message, to check that the 521 connection is working, at least every 60 seconds, then whenever there 522 is 60 seconds since the previous message, a Keep-Alive message could 523 be sent. If there were less than 60 seconds between each Join/Prune, 524 no Keep-Alive messages would be needed. Implementations SHOULD 525 support the use of PORT Keep-Alive messages. It is RECOMMENDED that 526 a configuration option is available to network administrators to 527 enable it when needed. Note that Keep-Alives can be used by a peer, 528 independently of whether the other peer supports it. 530 An implementation that supports Keep-Alive messages acts as follows 531 when processing a received PORT message. When processing a Keep- 532 Alive message with a non-zero Holdtime value, it MUST set a timer to 533 the value. We call this timer Connection Expiry Timer (CET). If the 534 CET is already running, it MUST be reset to the new value. When 535 processing a Keep-Alive message with a zero Holdtime value, the CET 536 MUST be stopped if running. When processing a PORT message other 537 than Keep-Alive, the CET MUST be reset to the last received Holdtime 538 value if running. If the CET is not running, no action is taken. If 539 the CET expires, the connection SHOULD be shut down. This 540 specification does not mandate a specific default Holdtime value. 541 However, the dynamic congestion and flow control in TCP and SCTP can 542 result in variable transit delay between the endpoints when capacity 543 varies, there may be loss in the network or variable link 544 performance. Consistent behaviour therefore requires a sufficiently 545 large Holdtime value. E.g., 60 seconds to prevent premature 546 termination. 548 It is possible that a router receives Join/Prune messages for an 549 interface/link that is down. As long as the neighbor has not 550 expired, it is RECOMMENDED processing those messages as usual. If 551 they are ignored, then the router SHOULD ensure it gets a full update 552 for that interface when it comes back up. This can be done by 553 changing the GenID (Generation Identifier, see [RFC4601]), or by 554 terminating and reestablishing the connection. 556 If a PORT neighbor changes its GenID and a connection is established 557 or attempting to be established, the local side should generally tear 558 down the connection and do as described in Section 4.3. However, if 559 the connection is shared by multiple interfaces and the GenID changes 560 only for one of them, the local side SHOULD simply send a full 561 update, similar to other cases when a GenID changes for an upstream 562 neighbor. 564 4.3. Actions When a Connection Goes Down 566 A connection may go down for a variety of reasons. It may be due to 567 an error condition, or a configuration change. A connection SHOULD 568 be shut down as soon as there are no more PIM neighbors using it. 569 That is, for the connection we have associated local and remote 570 Connection IDs. When there is no PIM neighbor with that particular 571 remote connection ID on any interface where we announce the local 572 connection ID, the connection SHOULD be shut down. This may happen 573 when a new connection ID is configured, PORT is disabled, or a PIM 574 neighbor expires. 576 If a PIM neighbor expires, one should free connection state and 577 downstream oif-list state for the neighbor. A downstream router, 578 when an upstream neighboring router has expired, will simply update 579 the RPF neighbor for the corresponding state to a new neighbor where 580 it would trigger Join/Prune messages. This behavior is according to 581 [RFC4601] where also the term RPF neighbor is defined. It is 582 required of a PIM router to clear its neighbor table for a neighbor 583 who has timed out due to neighbor holdtime expiration. 585 When a connection is no longer available between two PORT enabled PIM 586 neighbors, they MUST immediately, or on-demand, try to reestablish 587 the connection following the normal rules for connection 588 establishment. The neighbors MUST also start expiry timers so that 589 all oif-list state for the neighbor using the connection, gets 590 expired after J/P_Holdtime, unless it later gets refreshed by 591 receiving new Join/Prunes. 593 The value of J/P_Holdtime is 215 seconds. This value is based on 594 section 4.11 of [RFC4601] which says that J/P_HoldTime should be 3.5 595 * t_periodic where the default for t_periodic is 60 seconds. 597 4.4. Moving from PORT to Datagram Mode 599 There may be situations where an administrator decides to stop using 600 PORT. If PORT is disabled on a router interface, or a previously 601 PORT enabled neighbor no longer announces any of the PORT Hello 602 options, the router follows the rules in Section 4.3 for taking down 603 connections and starting timers. Next, the router SHOULD trigger a 604 full state update similar to what would be done if the GenID changed 605 in Datagram Mode. The router SHOULD send Join/Prune messages for any 606 state where the router switched from PORT to Datagram Mode for the 607 upstream neighbor. 609 4.5. On-demand versus Pre-configured Connections 611 Transport connections could be established when they are needed or 612 when a router interface to other PIM neighbors has come up. The 613 advantage of on-demand Transport connection establishment is the 614 reduction of router resources. Especially in the case where there is 615 no need for a full mesh of connections on a network interface. The 616 disadvantage is additional delay and queueing when a Join/Prune 617 message needs to be sent and a Transport connection is not 618 established yet. 620 If a router interface has become operational and PIM neighbors are 621 learned from Hello messages, at that time, Transport connections may 622 be established. The advantage is that a connection is ready to 623 transport data by the time a Join/Prune message needs to be sent. 624 The disadvantage is there can be more connections established than 625 needed. This can occur when there is a small set of RPF neighbors 626 for the active distribution trees compared to the total number of 627 neighbors. Even when Transport connections are pre-established 628 before they are needed, a connection can go down and an 629 implementation will have to deal with an on-demand situation. 631 Note that for TCP, it is the router with the lower Connection ID that 632 decides whether to open a connection immediately, or on-demand. The 633 router with the higher Connection ID SHOULD only initiate a 634 connection on-demand. That is, if it needs to send a Join/Prune 635 message and there is no currently established connection. 637 Therefore, this specification RECOMMENDS but does not mandate the use 638 of on-demand Transport connection establishment. 640 4.6. Possible Hello Suppression Considerations 642 Based on this specification, a Transport connection cannot be 643 established until a Hello message is received. One reason for this 644 is to determine if the PIM neighbor supports this specification and 645 the other is to determine the remote address to use to establish the 646 Transport connection. 648 There are cases where it is desirable to suppress entirely the 649 transmission of Hello messages. In this case, it is outside the 650 scope of this document on how to determine if the PIM neighbor 651 supports this specification as well as an out-of-band (outside of the 652 PIM protocol) method to determine the remote address to establish the 653 Transport connection. 655 4.7. Avoiding a Pair of TCP Connections between Neighbors 657 To ensure that there is only one TCP connection between a pair of PIM 658 neighbors, the following set of rules MUST be followed. Note that 659 this section applies only to TCP, for SCTP this is not an issue. Let 660 A and B be two PIM neighbors where A's Connection ID is numerically 661 smaller than B's Connection ID, and each is known to the other as 662 having a potential PIM adjacency relationship. 664 At node A: 666 o If there is already an established TCP connection to B, on the 667 PIM-over-TCP port, then A MUST NOT attempt to establish a new 668 connection to B. Rather it uses the established connection to send 669 Join/Prune messages to B. (This is independent of which node 670 initiated the connection.) 672 o If A has initiated a connection to B, but the connection is still 673 in the process of being established, then A MUST refuse any 674 connection on the PIM-over-TCP port from B. 676 o At any time when A does not have a connection to B which is either 677 established or in the process of being established, A MUST accept 678 connections from B. 680 At node B: 682 o If there is already an established TCP connection to A, on the 683 PIM-over-TCP port, then B MUST NOT attempt to establish a new 684 connection to A. Rather it uses the established connection to send 685 Join/Prune messages to A. (This is independent of which node 686 initiated the connection.) 688 o If B has initiated a connection to A, but the connection is still 689 in the process of being established, then if A initiates a 690 connection too, B MUST accept the connection initiated by A and 691 must release the connection which it (B) initiated. 693 5. PORT Message Definitions 695 It may be desirable for scaling purposes to allow Join/Prune messages 696 from different PIM protocol families to be sent over the same 697 Transport connection. Also, it may be desirable to have a set of 698 Join/Prune messages for one address-family sent over a Transport 699 connection that is established over a different address-family 700 network layer. 702 To be able to do this we need a common PORT message format. This 703 will provide both record boundary and demux points when sending over 704 a stream protocol like TCP/SCTP. 706 A PORT message may contain PORT options, see Section 5.3. We will 707 define two PORT options for carrying PIM Join/Prune messages. One 708 for IPv4 and one for IPv6. For each PIM Join/Prune message to be 709 sent over the Transport connection, we send a PORT Join/Prune message 710 containing exactly one such option. 712 Each PORT message will have the Type/Length/Value format. Multiple 713 different TLV types can be sent over the same Transport connection. 715 To make sure PIM Join/Prune messages are delivered as soon as the TCP 716 transport layer receives the Join/Prune buffer, the TCP Push flag 717 will be set in all outgoing Join/Prune messages sent over a TCP 718 transport connection. 720 PORT messages will be sent using destination TCP port number 8471. 721 When using SCTP as the reliable transport, destination port number 722 8471 will be used. See Section 11 for IANA considerations. 724 PORT messages are error checked. This includes illegal type fields, 725 or a truncated message. If the PORT message contains a PIM Join/ 726 Prune Message, then that is subject to the normal PIM error checks. 727 If any parsing errors occur in a PORT message, it is skipped, and we 728 proceed to any following PORT messages. 730 The TLV type field is 16 bits. The range 65532 - 65535 is for 731 experimental use [RFC3692]. 733 This document defines two message types. 735 5.1. PORT Join/Prune Message 737 PORT Join/Prune Message 739 0 1 2 3 740 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 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Type = 1 | Message Length | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Reserved | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Interface | 747 | ID | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | PORT Option Type | Option Value Length | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Value | 752 | . | 753 | . | 754 | . | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 \ . \ 757 / . / 758 \ . \ 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | PORT Option Type | Option Value Length | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Value | 763 | . | 764 | . | 765 | . | 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 The PORT Join/Prune Message is used for sending a PIM Join/Prune. 770 Message Length: Length in bytes for the value part of the Type/ 771 Length/Value encoding. If no PORT Options were included, the 772 length would be 12. If n PORT Options with Option Value lengths 773 L1, L2, ..., Ln are included, the message length will be 12 + 4*n 774 + L1 + L2 + ... + Ln. 776 Reserved: Set to zero on transmission and ignored on receipt. 778 Interface ID: This MUST be the Interface ID of the Interface ID 779 Hello option contained in the PIM Hello messages the PIM router is 780 sending to the PIM neighbor. It indicates to the PIM neighbor 781 what interface to associate the Join/Prune with. The Interface ID 782 allows us to do connection sharing. 784 PORT Options: The message MUST contain exactly one PIM Join/Prune 785 Port Option, either one PIM IPv4 Join/Prune or one PIM IPv6 Join/ 786 Prune. It MUST NOT contain both. It MAY contain additional 787 options not defined in this document. The behavior when receiving 788 a message containing unknown options depends on the option type. 789 See Section 5.3 for option definitions. 791 5.2. PORT Keep-alive Message 793 PORT Keep-alive Message 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Type = 2 | Message Length | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Reserved | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Holdtime | PORT Option Type | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | Option Value Length | Value | 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . + 806 | . | 807 | . | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 \ . \ 810 / . / 811 \ . \ 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | PORT Option Type | Option Value Length | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Value | 816 | . | 817 | . | 818 | . | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 The PORT Keep-alive Message is used to regularly send PORT messages 822 to verify that a connection is alive. They are used when other PORT 823 messages are not sent at the desired frequency. 825 Message Length: Length in bytes for the value part of the Type/ 826 Length/Value encoding. If no PORT Options were included, the 827 length would be 6. If n PORT Options with Option Value lengths 828 L1, L2, ..., Ln are included, the message length will be 6 + 4*n + 829 L1 + L2 + ... + Ln. 831 Reserved: Set to zero on transmission and ignored on receipt. 833 Holdtime: This specifies a Holdtime in seconds for the connection. 834 A non-zero value means that the connection SHOULD be gracefully 835 shut down if no further PORT messages are received within the 836 specified time. This is measured on the receiving side by 837 measuring the time from one PORT message has been processed until 838 the next has been processed. Note that this MUST be done for any 839 PORT message, not just keep-alive messages. A hold time of 0 840 disables the keep-alive mechanism. 842 PORT Options: A keep-alive message MUST NOT contain any of the 843 options defined in this document. It MAY contain other options 844 not defined in this document. The behavior when receiving a 845 message containing unknown options depends on the option type. 846 See Section 5.3 for option definitions. 848 5.3. PORT Options 850 Each PORT Option is a TLV. The type is 16 bits. The PORT Option 851 type space is split in two ranges. The types in the range 0 - 32767 852 (the most significant bit is not set) are for Critical Options. The 853 types in the range 32768 - 65535 (the most significant bit is set) 854 are for Non-Critical Options. 856 The behavior of a router receiving a message with an unknown PORT 857 Option, is determined by whether the option is a critical option. If 858 the message contains an unknown critical option, the entire message 859 must be ignored. If the option is non-critical, only that particular 860 option is ignored, and the message is processed as if the option was 861 not present. 863 PORT Option types are assigned by IANA, except the ranges 32764 - 864 32767 and 65532 - 65535 that are for experimental use [RFC3692]. The 865 length specifies the length of the value in bytes. Below are the two 866 options defined in this document. 868 5.3.1. PIM IPv4 Join/Prune Option 870 PIM IPv4 Join/Prune Option Format 872 0 1 2 3 873 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 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 | PORT Option Type = 1 | Option Value Length | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | PIMv2 Join/Prune Message | 878 | . | 879 | . | 880 | . | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 The IPv4 Join/Prune Option is used to carry a PIMv2 Join/Prune 884 message that has all IPv4 encoded addresses in the PIM payload. 886 Option Value Length: The number of bytes that make up the PIMv2 887 Join/Prune message. 889 PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with 890 no IP header in front of it. 892 5.3.2. PIM IPv6 Join/Prune Option 894 PIM IPv6 Join/Prune Option Format 896 0 1 2 3 897 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 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | PORT Option Type = 2 | Option Value Length | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | PIMv2 Join/Prune Message | 902 | . | 903 | . | 904 | . | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 The IPv6 Join/Prune Option is used to carry a PIMv2 Join/Prune 908 message that has all IPv6 encoded addresses in the PIM payload. 910 Option Value Length: The number of bytes that make up the PIMv2 911 Join/Prune message. 913 PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with 914 no IP header in front of it. 916 6. Explicit Tracking 918 When explicit tracking is used, a router keeps track of join state 919 for individual downstream neighbors on a given interface. This is 920 done for all PORT joins and prunes. It may also be done for native 921 join/prune messages, if all neighbors on the LAN have set the T bit 922 of the LAN Prune Delay option (see definition in section 4.9.2 of 923 [RFC4601]). In the discussion below we will talk about ET (explicit 924 tracking) neighbors, and non-ET neighbors. The set of ET neighbors 925 MUST include the PORT neighbors. The set of non-ET neighbors 926 consists of all the non-PORT neighbors unless all neighbors have set 927 the LAN Prune Delay T bit. Then the ET neighbors set contains all 928 neighbors. 930 For some link-types, e.g. point-to-point, tracking neighbors is no 931 different than tracking interfaces. It may also be possible for an 932 implementation to treat different downstream neighbors as being on 933 different logical interfaces, even if they are on the same physical 934 link. Exactly how this is implemented and for which link types, is 935 left to the implementer. 937 For (*,G) and (S,G) state, the router starts forwarding traffic on an 938 interface when a Join is received from a neighbor on such an 939 interface. When a non-ET neighbor sends a Prune, as specified 940 [RFC4601], if no Join is sent to override this Prune before the 941 expiration of the Override Timer, the upstream router concludes that 942 no non-ET neighbor is interested. If no ET neighbors are interested, 943 the interface can be removed from the oif-list. When an ET neighbor 944 sends a Prune, one removes the join state for that neighbor. If no 945 other ET or non-ET neighbors are interested, the interface can be 946 removed from the oif-list. When a PORT neighbor sends a prune, there 947 can be no Prune Override, since the Prune is not visible to other 948 neighbors. 950 For (S,G,rpt) state, the router needs to track Prune state on the 951 shared tree. It needs to know which ET neighbors have sent prunes, 952 and whether any non-ET neighbors have sent prunes. Normally one 953 would forward a packet from a source S to a group G out on an 954 interface if a (*,G)-join is received, but no (S,G,rpt)-prune. With 955 ET one needs to do this check per ET neighbor. That is, the packet 956 should be forwarded unless all ET neighbors that have sent 957 (*,G)-joins have also sent (S,G,rpt)-prunes, and if a non-ET neighbor 958 has sent a (*,G)-join, whether there also is non-ET (S,G,rpt)-prune 959 state. 961 7. Multiple Address-Family Support 963 To allow for efficient use of router resources, one can mux Join/ 964 Prune messages of different address families on the same Transport 965 connection. There are two ways this can be accomplished, one using a 966 common message format over a TCP connection and the other using 967 multiple streams over a single SCTP connection. 969 Using the common message format described previously in this 970 specification, using different PORT options, both IPv4 and IPv6 based 971 Join/Prune messages can be encoded within the same Transport 972 connection. 974 When using SCTP multi-streaming, the common message format is still 975 used to convey address family information but an SCTP association is 976 used, on a per-family basis, to send data concurrently for multiple 977 families. When data is sent concurrently, head of line blocking, 978 which can occur when using TCP, is avoided. 980 8. Miscellany 982 There are no changes to processing of other PIM messages like PIM 983 Asserts, Grafts, Graft-Acks, Registers, and Register-Stops. This 984 goes for BSR and Auto-RP type messages as well. 986 This extension is applicable only to PIM-SM, PIM-SSM and Bidir-PIM. 987 It does not take requirements for PIM-DM into consideration. 989 9. Manageability Considerations 991 This document defines using TCP or SCTP transports between pairs of 992 PIM neighbors. It is recommended that this mechanism is disabled by 993 default. An administrator can then enable PORT TCP and/or SCTP on 994 PIM enabled interfaces. If two neighbors both have PORT SCTP (and if 995 not, if both PORT TCP) they will only use SCTP (alternatively TCP) 996 for PIM Join/Prune messages. This is the case even when the 997 connection is down. 999 When PORT support is enabled, a router sends PIM Hello messages 1000 announcing support for TCP and/or SCTP and also Connection IDs. It 1001 should be possible to configure a local Connection ID, and also to 1002 see what PORT capabilities and Connection IDs PIM neighbors are 1003 announcing. Based on these advertisements, pairs of PIM neighbors 1004 will decide whether to try to establish a PORT connection. There 1005 should be a way for an operator to check the current connection 1006 state. Statistics on the number of PORT messages sent and received 1007 (including number of invalid messages) may also be helpful 1009 For connection security (see Section 4.1), it should be possible to 1010 enable a GTSM check to only accept connections (TCP/SCTP packets) 1011 when the sender is within a certain number of router hops. Also one 1012 should be able to configure the use of TCP-AO. 1014 For connection maintenance (see Section 4.2), it is recommended to 1015 support Keep-Alive messages. It should be configurable whether to 1016 send Keep-Alives. In that case, also wheter to use a Holdtime, and 1017 what Holdtime to use. 1019 There should be some way to alert an operator when PORT connections 1020 are going down, or when there is a failure in establishing a PORT 1021 connection. Also information like the number of connection failures, 1022 and how long the connection has been up or down, is useful. 1024 10. Security Considerations 1026 There are several security issues related to the use of TCP or SCTP 1027 transports. The attacks would consist of sending packets with a 1028 spoofed source address. Either establishing a connection, or 1029 injecting packets into an existing connnection. This might allow 1030 someone to send spoofed join/prune messages, and may also allow 1031 someone to reset the connection. Mechanisms that help protect 1032 against this are discussed in Section 4.1). 1034 For authentication one may for TCP use TCP-AO [RFC5925], and for SCTP 1035 use Authenticated Chunks [RFC4895]. Also GTSM [RFC5082] can be used 1036 to help prevent spoofing. 1038 11. IANA Considerations 1040 This specification makes use of a TCP port number and a SCTP port 1041 number for the use of PIM-Over-Reliable-Transport that has been 1042 allocated by IANA. It also makes use of IANA PIM Hello Options 1043 allocations that should be made permanent. 1045 11.1. PORT Port Number 1047 IANA has assigned a port number that is used as a destination port 1048 for PORT TCP and SCTP transports. The assigned number is 8471. 1049 References to this document should be added to the Service Name and 1050 Transport Protocol Port Number Registry. 1052 11.2. PORT Hello Options 1054 In the Protocol Independent Multicast (PIM) Hello Options registry, 1055 the following options are needed for PORT. 1057 Value Length Name Reference 1058 ------- ---------- ----------------------- --------------- 1059 27 Variable PIM-over-TCP Capable this document 1060 28 Variable PIM-over-SCTP Capable this document 1062 11.3. PORT Message Type Registry 1064 A registry for PORT message types is requested. The message type is 1065 a 16-bit integer, with values from 0 to 65535. An RFC is required 1066 for assignments in the range 0 - 65531. This document defines two 1067 PORT message types. Type 1, Join/Prune; and Type 2, Keep-alive. The 1068 type range 65532 - 65535 is for experimental use [RFC3692]. 1070 The initial content of the registry should be as follows: 1072 Type Name Reference 1073 ------------- ------------------------------- --------------- 1074 0 Reserved this document 1075 1 Join/Prune this document 1076 2 Keep-alive this document 1077 3-65531 Unassigned 1078 65532-65535 Experimental this document 1080 11.4. PORT Option Type Registry 1082 A registry for PORT option types is requested. The option type is a 1083 16-bit integer, with values from 0 to 65535. Option types are 1084 assigned by IANA, except the ranges 32764 - 32767 and 65532 - 65535 1085 that are for experimental use [RFC3692]. An RFC is required for the 1086 IANA assignments. This document defines two PORT Option types. Type 1087 1, PIM IPv4 Join/Prune Message; and Type 2, PIM IPv6 Join/Prune 1088 Message. 1090 The initial content of the registry should be as follows: 1092 Type Name Reference 1093 ------------- ---------------------------------- --------------- 1094 0 Reserved this document 1095 1 PIM IPv4 Join/Prune Message this document 1096 2 PIM IPv6 Join/Prune Message this document 1097 3-32763 Unassigned Critical Options 1098 32764-32767 Experimental this document 1099 32768-65531 Unassigned Non-Critical Options 1100 65532-65535 Experimental this document 1102 12. Contributors 1104 In addition to the persons listed as authors, significant 1105 contributions were provided by Apoorva Karan and Arjen Boers. 1107 13. Acknowledgments 1109 The authors would like to give a special thank you and appreciation 1110 to Nidhi Bhaskar for her initial design and early prototype of this 1111 idea. 1113 Appreciation goes to Randall Stewart for his authoritative review and 1114 recommendation for using SCTP. 1116 Thanks also goes to the following for their ideas and commentary 1117 review of this specification, Mike McBride, Toerless Eckert, Yiqun 1118 Cai, Albert Tian, Suresh Boddapati, Nataraj Batchu, Daniel Voce, John 1119 Zwiebel, Yakov Rekhter, Lenny Giuliano, Gorry Fairhurst, Sameer 1120 Gulrajani, Thomas Morin, Dimitri Papadimitriou, Bharat Joshi, Rishabh 1121 Parekh, Manav Bhatia and Pekka Savola. 1123 A special thank you goes to Eric Rosen for his very detailed review 1124 and commentary. Many of his comments are reflected as text in this 1125 specification. 1127 14. References 1129 14.1. Normative References 1131 [I-D.ietf-pim-hello-intid] 1132 Gulrajani, S. and S. Venaas, "An Interface ID Hello Option 1133 for PIM", draft-ietf-pim-hello-intid-01 (work in 1134 progress), June 2011. 1136 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1137 RFC 793, September 1981. 1139 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1140 Requirement Levels", BCP 14, RFC 2119, March 1997. 1142 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1143 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1144 Protocol Specification (Revised)", RFC 4601, August 2006. 1146 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1147 "Authenticated Chunks for the Stream Control Transmission 1148 Protocol (SCTP)", RFC 4895, August 2007. 1150 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1151 RFC 4960, September 2007. 1153 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1154 "Bidirectional Protocol Independent Multicast (BIDIR- 1155 PIM)", RFC 5015, October 2007. 1157 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1158 Pignataro, "The Generalized TTL Security Mechanism 1159 (GTSM)", RFC 5082, October 2007. 1161 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1162 Authentication Option", RFC 5925, June 2010. 1164 14.2. Informative References 1166 [AFI] IANA, "Address Family Numbers", ADDRESS FAMILY NUMBERS htt 1167 p://www.iana.org/assignments/address-family-numbers, 1168 February 2007. 1170 [HELLO-OPT] 1171 IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per 1172 RFC4601 http://www.iana.org/assignments/pim-hello-options, 1173 March 2007. 1175 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1176 Considered Useful", BCP 82, RFC 3692, January 2004. 1178 Authors' Addresses 1180 Dino Farinacci 1181 cisco Systems 1182 Tasman Drive 1183 San Jose, CA 95134 1184 USA 1186 Email: dino@cisco.com 1188 IJsbrand Wijnands 1189 cisco Systems 1190 Tasman Drive 1191 San Jose, CA 95134 1192 USA 1194 Email: ice@cisco.com 1196 Stig Venaas 1197 cisco Systems 1198 Tasman Drive 1199 San Jose, CA 95134 1200 USA 1202 Email: stig@cisco.com 1204 Maria Napierala 1205 AT&T Labs 1206 200 Laurel Drive 1207 Middletown, New Jersey 07748> 1208 USA 1210 Email: mnapierala@att.com